ANNEX I

General PROVISIONS for on-board weighing equipment (‘OBW’)

1.    General provisions

1.1.    The following types of OBW systems are included in the scope of this Regulation:

a)    dynamic system: OBW system that determines the weight by collecting and processing information from parameters that are captured while the vehicle is in motion, such as accelerations, traction or braking forces, and which do not take place when the vehicle is standing still;

b)    static system: OBW system that determines the weight with information obtained from parameters that are captured while the vehicle is standing still, such as the pressure in an air bellow.

1.2.    The implementation of this Regulation follows two stages :

   (a)    stage 1 OBW referred to in point 5.2;

   (b)    stage 2 OBW referred to in point 5.3.

1.3.    The OBW shall calculate the total weight and, optionally, the axle weight. 

1.4.    The OBW shall comprise the following elements:

a)    a motor vehicle unit (‘MVU’) placed in the motor vehicle;

b)    optionally, a TU in the trailer or semi-trailer;

c)    sensors; 

d)    for stage 2, a C-ITS station in each of the vehicles featuring either a MVU or a TU.

1.5.    MVU and Trailer Unit  may each consist of a single processing unit or be split into different units.

2.        Motor vehicle unit (‘MVU’)

       The MVU shall:

a)receive the axle load from the TU, if the latter is present;

b)collect weight data from the sensors in the motor vehicle;

   c)    process the available information and calculate the corresponding weight values;

3.        Trailer unit (‘TU’)

       Where present, the TU shall: 

a)    collect weight data from the sensors in the trailer or semi-trailer, process the available information and calculate the axle weights resulting from those data;

   b)    transfer the axle weight values to the motor vehicle.

4.            Calculation of weight

4.1.            For dynamic systems, a first weight value shall be calculated at the latest 15 minutes after the vehicle starts to move forward and shall be recalculated, every 10 minutes henceforth or faster.

4.2.            For static systems, weight values shall be calculated every minute when ignition is on and the vehicle is standing still.

4.3.        The resolution of the calculated weight shall be 100 kg or better.

5.        Exchange of information between the motor vehicle and the trailers or semi-trailers of a vehicle combination

5.1.        Each trailer or semi-trailer shall make available to the motor vehicle the weight values calculated by the former in accordance with points 5.2 or 5.3, as applicable.

5.2.            Stage 1 OBW

5.2.1        Each trailer or semi-trailer shall be assigned a position within the vehicle combination in the frame of a dynamic address assignment as set out in ISO 11992-2:2014.

5.2.2.        After the address assignment phase is carried out, the TU of each trailer or semi-trailer shall transfer to the MVU the axle load sum or the axle load in accordance with the description provided in points 6.5.4.7 and 6.5.5.42 of ISO 11992-2:2014.

5.2.3.        The messages on axle load sum or axle load shall follow the specifications set out in ISO 11992-2:2014 for the message types EBS22 and RGE22.

5.2.4.        The format, routing and general parameter ranges of the messages shall be in accordance with points 6.1, 6.3 and 6.4 of ISO 11992-2:2014.

5.3.        Stage 2 OBW

       The information between motor vehicle and the trailers or semi-trailers being towed shall be exchanged by means of C-ITS stations as set out in Annex II.

5.4.        For both stage 1 and stage 2 OBW, different specifications may be used, provided that the OBW equipment in the motor vehicle and in the trailers or semi-trailers are compatible with them.

6.    Data preparation and transfer to the DSRC-VU

       The MVU for stage 1 or the C-ITS station in the motor vehicle for stage 2, shall transmit to the DSRC-VU module the on-board weighing system (‘OWS’) data in accordance with Annex III.

Figure 1.    Example of layout for OBW in a stage 1 truck/semi-trailer vehicle combination

Figure 2.    Example of layout for OBW in a stage 2 truck/semi-trailer vehicle combination

7.    Weight information to the driver

   The driver shall be informed by a display of, at least, the total weight.

8.        Accuracy

8.1.        The accuracy of the calculated weight shall be ± 5% or better when the vehicle is loaded at greater than 90% of its maximum authorised weight. 

8.2.        Notwithstanding point 8.1, for stage 1 OBW the accuracy may be ±10% or better.

ANNEX II

SPECIFIC PROVISIONS FOR STAGE 2 OBW

1.    This Annex applies exclusively to stage 2 OBW.

2.    The motor vehicle and the trailers or semi-trailers of the vehicle combination featuring a TU shall be fitted with a C-ITS station connected to the motor vehicle unit (‘MVU’) or the trailer unit (‘TU’) of the corresponding vehicle. The MVU and the TU may be integrated in their respective C-ITS stations. 

3.    The MVU and the TU shall transmit to the C-ITS stations to which they are connected the necessary information for the transmission of the messages in accordance with point 4.3 of this Annex.

Figure 3. Example of flow of messages in a stage 2 OBW

4.    Exchange of information between motor vehicle and trailer or semi-trailer 

4.1    The information on weight between motor vehicle and the trailers or semi-trailers being towed shall be exchanged through a wireless link set up between the C-ITS stations of the motor vehicle and those of the trailers or semi-trailers, in accordance with the the standards EN 302 663-V1.1.1, with the exemption of clause 4.2.1, EN 302 636-4-1-V1.3.1, EN 302 636-5.1-V2.1.1 and with the European standard on the OBW application for C-ITS that shall be developed by ETSI.

4.2.    Messages exchanged by the C-ITS stations shall be secured as laid down in point 5.1.

4.3.    the following information shall be transmitted between the C-ITS stations:

   -        a) axle weight of the trailers or semi-trailers being towed;

   -    b) messages containing “OBW communication error” events: a OBW communication error event shall be triggered when the C-ITS stations fail to establish a mutual secured communication in accordance with point 5.1 for more than three attempts;

-c) messages containing a “security breach attempt” event: a security breach attempt event shall be triggered when an attempt to manipulate the OBW as set out in point 5.2 and in the Appendix has been detected by the OBW.

4.4.    The format of the messages needed for the address assignment phase and for the transmission of the information referred to in point 4.3 shall be set out in the standard on the OBW application referred to in point 4.1.

5.    Security provisions

5.1.    Secure communication between C-ITS stations

5.1.1.    The communication between C-ITS stations shall be secured in accordance with the European standard ETSI TS 103 097-V1.3.1 and with the European standard on the OBW application for C-ITS referred to in point 4.1.

5.1.2.    In accordance with the Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport Systems, adopted by the Commission, the C-ITS stations shall get:

a)    An enrolment credential from an enrolment authority, authorizing them to operate as C-ITS stations for the purpose of on-board weighing.

b)    A number of authorisation tickets from an authorisation authority allowing them to operate within the C-ITS environment as part of the OBW.

5.2.    Protection against security breach attempts

   The protection of stage 2 OBW against security breach attempts shall be implemented in accordance with the Appendix to this Annex.

APPENDIX TO ANNEX II

Security certification for stage 2 obw

1.    The MVU and the TU shall be security certified according to the Common Criteria Scheme. In this Appendix, the MVU and the TU are hereafter referred to as ‘OBW-VU’.

2.    The minimum security requirements to be met by OBW-VU shall be defined in a Security Target (‘ST’) according to the Common Criteria Scheme.

3.    The ST shall be drafted by the manufacturer of the equipment to be certified, and approved by a governmental IT security certification body organised within the Join Interpretation Working Group (‘JIWG’) which is supporting the mutual recognition of certificates under the umbrella of the European SOGIS-MRA (Agreement on Mutual Recognition of Information Technology Security Evaluation Certificates).

4.    The V2X gateway and the Hardware Security Module of the C-ITS stations shall be security certified against the V2X Gateway and Hardware Security Module protection profiles developed by the Car2Car consortium.

5.    The assurance level for the security certification of the OBW-VU shall be EAL2. However, if the tachograph is used as MVU, the former shall be certified against an assurance level EAL4 augmented by the assurance components ATE_DPT.2 and AVA_VAN.5, as set out in Appendix 11 to Annex IC to Regulation (EU) 2016/799.

6.    Assets to be protected by the ST

The following assets shall be protected:

a)    OBW-VU message: any message which is sent or received by a relevant OBW-VU module bearing information that is necessary for the calculation of the weight.

The relevant OBW modules are those hardware and software units of the OBW-VU which process information that, if attacked, may result in a miscalculation by the OBW of the total or axle weight.

A OBW-VU may be a single relevant module or be composed of different relevant modules, in accordance with point 1.5 of Annex I, in which case the ST shall identify them.

b)    Weight message: message containing the total or axle weight calculated by the OBW-VU.

c)    Calibration data: information that is entered in the OBW-VU memory in order to calibrate the OBW.

d)    Audit information: information on security breach attempts corresponding to the threats addressed in this Appendix.

e)    OBW-VU software: software used within the OBW-VU to implement and support OBW functions which is relevant for the calculation of the weight and the detection of security breach attempts.

Figure 4. Example of OBW-VU messages and Weight messages to be protected in a MVU composed of two relevant modules

7.    Threats to be addressed in the ST

The ST shall address the following threats:

a) T.OBW-VU_message_spoof: an attacker could spoof OBW-VU messages so that the OBW-VU miscalculates the weight.

b) T.OBW-VU_message_tamper: an attacker could tamper OBW-VU messages so that the OBW-VU miscalculates the total or axle weight.

c) T.Weight_message_spoof: an attacker could spoof weight messages so that the weight calculated by the OBW-VU is modified.

d) T.Weight_message_tamper: an attacker could tamper weight messages so that the weight calculated by the OBW-VU is modified.

e) T.Audit_spoof: an attacker could spoof audit information messages.

f) T.Audit_tamper: an attacker could tamper audit information messages.

g) T.Calibration_tamper: an attacker could enter wrong values as calibration data in order to induce the OBW-VU to miscalculate the weight.

h) T.Software_tamper: an attacker could modify or replace the OBW-VU software in order to alter the normal calculation of the weight.

i) T.Stored_Data_tamper: an attacker could try to modify or delete the relevant information stored in the OBW-VU, including audit information.

8.    The security objectives for the OBW-VU shall be the following:

a) O.Plausibility_validation: the OBW-VU shall verify that information from an incoming message to a relevant module, either from the sensors or from another module, can be trusted on the basis of its plausibility.

b)    O.OBW-VU_stored_information_protection: the OBW-VU shall be able to protect stored software and data from tampering.

c)    O.Notification: the OBW-VU shall be able to notify a security breach attempt.

9.    Rationale

a) T.OBW-VU_message_spoof is addressed by O.Plausibility_validation and by O.Notification.

b) T.OBW-VU_message_tamper is addressed by O.Plausibility_validation and by O.Notification.

c)T.Weight_message_spoof is addressed by O.Plausibility_validation and by O.Notification.

d)T.Weight_message_tamper is addressed by O.Plausibility_validation and by O.Notification.

e)T.Audit_spoof is addressed by O.Plausibility_validation and by O.Notification.

f)T.Calibration_tamper is addressed by O.Plausibility_validation and by O.Notification.

g)T.Software_tamper is addressed by O.OBW-VU_stored_information_protection and by O.Notification.

e)T.Stored_data_tamper is addressed by O.OBW-VU_stored_information_protection and by O.Notification.

Table 1 – Security objectives rationale

ANNEX III

Data preparation and transfer OF INFORMATION to the REDCR

1.    This Annex, complementary to Appendix 14 to Annex IC to Regulation (EU) 2016/799 (henceforth Appendix 14), specifies the requirements for the preparation and transfer of OWS data from the motor vehicle to the Remote Early Detection Communication Reader (‘REDCR’).

2.    On-board weighing system (‘OWS’) data transfer for stage 1 OBW

2.1.    OWS data shall be provided to the digital short range communication vehicle unit (‘DSRC-VU’) by the MVU.

2.2.    The MVU shall:

2.2.1.    Build up the OWS data with the information received from the motor vehicle unit (‘MVU’) and the trailer unit (‘TU’), according to the structure set out in point 6; 

2.2.2.    forward the OWS data to the DSRC-VU for further transmission to the (‘REDCR’).

Figure 5. Transmission of OWS data from the MVU to the REDCR for stage 1 OBW

3.    OWS data transfer for stage 2 OBW

3.1.    OWS data shall be provided to the DSRC-VU by the C-ITS station in the motor vehicle.

Figure 6. Transmission of OWS data from the C-ITS station to the REDCR for stage 2 OBW

3.2.    The C-ITS station in the motor vehicle shall:

3.2.1.    Build up the OWS data with the information received from the MVU and the C-ITS stations of the trailers or semi-trailers being towed, according to the structure set out in point 6; 

3.2.2.    secure the OWS data as laid down in point 8, and

3.2.3.    forward the OWS data to the DSRC-VU for further transmission to the REDCR.

4.    Physical connection and interfaces sequences between the DSRC-VU and either the MVU (stage 1) or the C-ITS station in the motor vehicle (stage 2) shall be implemented as set out in point 5.6 of Appendix 14, where VU shall be understood as being either the MVU or the C-ITS station, depending on the stage.

5.    Communication between the DSRC-VU and the REDCR

5.1.    The communication between the DSRC-VU and the REDCR shall be carried out through the interface defined by the CEN DSRC standards EN 12253, EN 12795, EN 12834, EN 13372 and ISO 14906, as referred to in Council Directive 96/53/EC.

5.2.    The transaction protocol to download OWS data across the 5.8 GHz DSRC interface link shall be the same as the one used for the RTM data in point 5.4.1 of Appendix 14, the only difference being that the Object Identifier that relates to the TARV standard shall be addressing the ISO 15638 standard (TARV) Part 20 related to WOB/OWS.

5.3.    The commands used for an OWS transaction shall be the same as those set out in point 5.4.2 of Appendix 14 for a RTM transaction.

5.4.    The interrogation command sequence for OWS data shall be the same as the one set out in point 5.4.3 of Appendix 14 for RTM data.

5.5.    Data transfer mechanism and DSRC transaction description shall be the same as set out in points 5.4.6 and 5.4.7 of Appendix 14. The Vehicle Service Table shall be however adapted for the transmission of OWS data. Consequently, the Rtm-ContextMark shall be replaced by an Ows-ContextMark, which object identifier shall refer to the ISO 15638 standard (TARV) Part 20 related to WOB/OWS.

5.6.    The DSRC physical interface parameters, shall be the same as those set out in point 5.3 of Appendix 14.

6.    Data structure

   The ASN.1 module definition for the DSRC data within the OWS application is defined as follows:

TarvOws {iso(1) standard(0) 15638 part20(20) version1(1)} DEFINITIONS AUTOMATIC TAGS

::= BEGIN

IMPORTS

-- Imports data attributes and elements from EFC which are used for OWS

LPN

FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)}

-- Imports function parameters from the EFC Application Interface Definition

SetMMIRq

FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)}

-- Imports the L7 DSRCData module data from the EFC Application Interface Definition

Action-Request, Action-Response, ActionType, ApplicationList, AttributeIdList, AttributeList, Attributes,

BeaconID, BST, Dsrc-EID, DSRCApplicationEntityID, Event-Report-Request, Event-Report- Response,

EventType, Get-Request, Get-Response, Initialisation-Request, Initialisation-Response,

ObeConfiguration, Profile, ReturnStatus, Time, T-APDUs, VST

FROM EfcDsrcGeneric {iso(1) standard(0) 14906 generic(1) version5(5)};

-- Definitions of the OWS functions:

OWS-InitialiseComm-Request ::= BST

OWS-InitialiseComm-Response::= VST

OWS-DataRetrieval-Request::= Get-Request (WITH COMPONENTS {fill (SIZE(1)), eid, accessCredentials ABSENT, iid ABSENT, attrIdList})

OWS-DataRetrieval-Response::= Get-Response {OwsContainer} (WITH COMPONENTS {..., eid, iid ABSENT})

OWS-TerminateComm::= Event-Report-Request {OwsContainer}(WITH COMPONENTS {mode (FALSE), eid (0),

eventType (0)})

OWS-TestComm-Request::= Action-Request {OwsContainer} (WITH COMPONENTS {..., eid (0), actionType

(15), accessCredentials ABSENT, iid ABSENT})

OWS-TestComm-Response::= Action-Response {OwsContainer} (WITH COMPONENTS {..., fill (SIZE(1)), eid

(0), iid ABSENT})

-- Definitions of the OWS attributes:

OwsData :: = SEQUENCE {

   OWSPayload SignedDataPayload, -- SignedData in accordance with ETSI 103097 v1.3.1, only for Stage 2 OBW  

   }

OwsPayload :: = SEQUENCE {

   recordedWeight INTEGER (0..65535),    -- 0= Total measured weight of the  heavy goods vehicle                    -- with 10 Kg resolution.

   axlesConfiguration OCTET STRING SIZE (4),    -- 0= 20 bits allowed for the number                    -- of axles for 10 axles.

   axlesRecordedWeight OCTET STRING SIZE (26),    -- 0= Recorded Weight for each axle

               -- with 10 Kg resolution.

   tp15638Timestamp    INTEGER(0..4294967295)    -- Timestamp of current record

   tp15638DSRCcommunicationError            BOOLEAN,    -- Record of a communication error between MVU and DSRC within last 10 days

               tp15638OBWCommunicationError    BOOLEAN,    -- Record of a communication error

       tp15638SecurityBreachAttempt    BOOLEAN,    -- Record of a security breach attempt

       }

Ows-ContextMark ::= SEQUENCE {

   standardIdentifier StandardIdentifier, -- identifier of the TARV part and its version

       }

StandardIdentifier ::= OBJECT IDENTIFIER

OwsContainer ::= CHOICE {

   integer [0] INTEGER,

   bitstring [1] BIT STRING,

   octetstring [2] OCTET STRING (SIZE (0..127, ...)),

   universalString [3] UniversalString,

   beaconId [4] BeaconID,

   t-apdu [5] T-APDUs,

   dsrcApplicationEntityId [6] DSRCApplicationEntityID,

   dsrc-Ase-Id [7] Dsrc-EID,

   attrIdList [8] AttributeIdList,

   attrList [9] AttributeList{RtmContainer},

   reserved10 [10] NULL,

   OwsContextmark [11] Ows-ContextMark,

   OwsData [12] OwsData,

   reserved13 [13] NULL,

   reserved14 [14] NULL,

   time [15] Time,

-- values from 16 to 255 reserved for ISO/CEN usage

   }}

END

7.    Elements of OWS data, actions performed and definitions:

   The OWS data shall be calculated by either the MVU (stage 1) or the C-ITS station in the motor vehicle (stage 2) according to table 1

Table 1: Elements of OWS data, actions performed and definitions

where

a)    recordedWeight represents the total measured weight of the heavy goods vehicle with a resolution of 10 kg as defined in EN ISO 14906. For example, a value of 2500 represents a weight of 25 ton.

b)    axlesConfiguration represents the configuration of the heavy goods vehicle as number of axles.

The configuration is defined with the bit mask of 20 bits (extended from EN ISO 14906).

A bit mask of 2 bits represents the configuration of an axle with the following format:

-    Value 00B means that value is ‘non available’ because the vehicle does not have equipment to collect the weight on the axle.

-    Value 01B means that the axle is not present.

-    Value 10B means that the axle is present and the weight has been calculated and collected and it is provided in the axlesRecordedWeight field.

-    Value 11B is reserved for future uses.

       The last 6 bits are reserved for future uses.

Table 2. Bit distribution for OWS2

c)    axlesRecordedWeight represent the specific weight recorded for each axle with a resolution of 10 Kg. Two octets are used for each axle. For example, a value of 150, represent a weight of 1.500 Kgs.

8.    OWS data signature

8.1.    For stage 1, the OWS data shall not be signed; the plaintext of the OWS data shall be transferred from the MVU to the DSRC-VU.

8.2.    For stage 2, the OWS data shall be signed in the C-ITS station of the motor vehicle and transferred from the latter to the DSRC-VU, in accordance with the following provisions:

8.2.1.    The secured data structure shall be constructed as set out in points 5.1 and 5.2 of ETSI TS 103 097

8.2.2.    The type SignedData referred to in point 5.2 of ETSI TS 103 097-V1.3.1 shall have the following constraints:

   a)    The type HashAlgorithm shall be set at sha256.

-    b)    The type SignerIdentifier shall be set at “digest”.

   c)    The type SignedDataPayload shall be the OWS data as laid down in point 7.

   d)    The type HeaderInfo shall be constrained to have the following security headers:

       -    The component psid shall be set equal to 0.

       -    The component generationTime as defined in IEEE Std 1609.2.

       -    The component expiryTime shall be absent.

       -    The component generationLocation shall be absent.

       -    The component p2pcdLearningRequest shall be absent.

       -    The component missingCrlIdentifier shall be absent.

       -    The component encryptionKey shall be absent.

       -    The component inlineP2pcdRequest shall be absent.

       -    The component requestedCertificate shall be absent.

8.2.3.    The ASN.1 module definition for the type Signature shall be as follows:

Signature ::= CHOICE {

ecdsaNistP256Signature EcdsaP256Signature,

ecdsaBrainpoolP256r1Signature EcdsaP256Signature,

...,

ecdsaBrainpoolP384r1Signature EcdsaP384Signature

}

EcdsaP256Signature ::= SEQUENCE {

rSig EccP256CurvePoint,

sSig OCTET STRING (SIZE (32))

}

EccP256CurvePoint ::= CHOICE {

x-only OCTET STRING (SIZE (32)),

fill NULL, -- consistency with 1363 / X9.62

compressed-y-0 OCTET STRING (SIZE (32)),

compressed-y-1 OCTET STRING (SIZE (32)),

uncompressedP256 SEQUENCE {

x OCTET STRING (SIZE (32)),

y OCTET STRING (SIZE (32))

}

       }

8.2.4    The signing certificate shall be the certificate in the authorization ticket that the C-ITS station is using for the transaction between the C-ITS station and the REDCR, in accordance with point 6 of ETSI TS 103 097-V1.3.1.

8.2.5.    When receiving the message, the REDCR shall verify the certificate and shall use the public key included in that certificate to read the OWS data signature. 

9.    The application protocol and error handling for OWS data shall be the same as set out in points 5.6.2 and 5.7 of Appendix 14.

10.    For stage 2, OWS data may also be served directly to the REDCR of the enforcer via the C-ITS in the motor vehicle instead of via the DSRC-VU. In that case, the REDCR will also be a C-ITS station.

ANNEX IV

PERIODIC INSPECTIONS

1.    On-board weighing equipment (‘OBW’) shall undergo regular periodic inspections by weighing the vehicle or vehicle combination on certified weighing devices in accordance with Article 5(2)(b) of this Regulation, such as portable weigh pads or a weighbridge.

2.    The inclination of the certified weighing device shall not exceed 1%.

3.    The following vehicles shall be subject to inspection:

a)    motor vehicles;

b)    trailers and semi-trailers featuring a trailer unit (‘TU’).

4.    Trailers and semi-trailers subject to inspection according to point 3 shall undergo the inspection attached to a motor vehicle. Motor vehicles intended to tow semi-trailers shall undergo the inspection attached to a semi-trailer. 

5.    The periodic inspection shall consist of:

a)    a three-load test, which shall be carried out two years after the registration of the vehicle and every four years thereafter; 

b)    a single-load test, which shall be carried out two years after the first three-load test and every four years thereafter.

Table 3. Sequence of performance of the periodic inspections

6.    Three-load test

   A three-load test shall be performed by loading the vehicle with three different loads, which values shall be calculated as follows:

a)    a load between 45% and 55% of the technically permissible maximum laden mass of the vehicle;

b)    a load between 65% and 75% of the technically permissible maximum laden mass of the vehicle;

c)    A load between 90% and 100% of the technically permissible maximum laden mass of the vehicle.

7.    The single load test shall be performed by loading the vehicle with a load which is at least 90% of the technically permissible maximum laden mass of the vehicle.

8.    For trailers and semi-trailers featuring a TU and for motor vehicles intended to tow a semi-trailer, the loads in points 6 and 7 shall be calculated in respect of the technically permissible maximum laden mass of the vehicle combination.

9.    Specific provisions for dynamic OBWs

9.1.    If the technically permissible maximum laden mass of the vehicle or vehicle combination exceeds the maximum authorised weight, the loads in points 6 and 7 shall be calculated in respect of the maximum authorized weight.

9.2    In order to get a load value from the OBW, the vehicle or vehicle combination shall be driven over a certain distance under specific conditions to be specified in the manufacturer’s guidelines.

10.    The inspection shall be deemed to have failed when

a)    the load value displayed by the OBW corresponding to the load between 90% to 100% of the technically permissible maximum laden mass referred to in point 6(c) do not conform to the values measured by the certified weighing device, with the level of accuracy set out in point 8 of Annex I, and

b)    the load values displayed by the OBW corresponding to the loads between 45% and 55%, and between 65% and 75% of the technically permissible maximum laden mass as referred to in points 6(a) and 6(b), do not conform to the values measured by the certified weighing device with a level or accuracy of ±15%.

11.    When the inspection fails the OBW shall undergo a new inspection no later than two months after the previous one.

12.    Flexibilities for periodic inspections:

In order to facilitate the performance of periodic inspections for specific types of vehicles, and in order to reduce the impact of periodic inspections on the regular activities of drivers and hauliers, Member States may consider the application of the following flexibilities for vehicles registered in their territory:

a)    the three load values referred to in point 6 may be obtained over a period of three months;

b)    the actual weighing of the vehicle may be carried out on certified weighing devices not belonging to the facilities of the approved workshops referred to in Article 6 of this Regulation. The owner of the vehicle shall provide evidence to the authorised workshop that the weighing has been performed on a certified weighing device; 

c)    for vehicles or vehicle combinations which specific configuration makes technically impossible to exceed the maximum authorised weight during normal use (e.g. road tankers) the loads referred to in points 6 and 7 may have other values; in the case of the three-load test, the difference between two consecutive loads shall be at least 15% of the maximum authorised weight.