Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)
Read failure may be because the antennas were not paired properly (failure of ‘aiming’); because one of the antennas is shielded — this may be deliberate, but also can be caused by the physical presence of another vehicle; radio interference, especially from circa 5.8 GHz WIFI or other public access wireless communications, or may be caused by radar interference, or difficult atmospheric conditions (e.g. during a thunderstorm); or simply by moving out of the range of the DSRC communication. Individual instances of read failures, by their nature, cannot be recorded, simply because the communication simply did not occur.
However, if the agent of the competent control authority targets a vehicle and attempts to interrogate its DSRC-VU, but no successful transfer of data ensues, this failure could have occurred because of deliberate tampering, and therefore the agent of the competent control authority needs a means to log the failure, and alert colleagues downstream that there may be a violation. The colleagues can then stop the vehicle and carry out a physical inspection. However, as no successful communication has taken place, the DSRC-VU cannot provide data concerning the failure. Such reporting shall therefore be a function of REDCR equipment design.
‘Failure to read’ is technically different to an ‘error’. In this context an ‘error’ is the acquisition of a wrong value.
Data transferred to the DSRC-VU is supplied already secured, therefore must be verified by the supplier of the data (see 5.4).
Data subsequently transferred across the air interface is checked by cyclic redundancy checks at the communications level. If the CRC validates, then the data is correct. If the CRC does not validate, the data is retransmitted. The probability that data could successfully pass through a CRC incorrectly is statistically so highly improbable that it may be discounted.
If the CRC does not validate and there is no time to retransmit and receive the correct data, then the result will not be an error, but an instantiation of a specific type of read failure.
The only meaningful ‘failure’ data that can be recorded is that of the number of successful initiations of transactions that occur, that do not result in a successful transfer of data to the REDCR.
- DSC_82The REDCR shall therefore record, time-stamped, the number of occasions where the ‘initialisation’ phase of a DSRC interrogation is successful, but the transaction terminated before the Data was successfully retrieved by the REDCR. This data shall be available to agent of the competent control authority and shall be stored in the memory of the REDCR equipment. The means by which this is achieved shall be a matter of product design or the specification of a competent control authority.
- The only meaningful ‘error’ data that can be recorded is the number of occasions where the REDCR fails to decrypt the Data received. However, it should be noted that this will only relate to the efficiency of the REDCR software. Data may be technically decrypted, but make no semantic sense.
- DSC_83The REDCR shall therefore record, time-stamped, the number of occasions where it has attempted but failed to decipher data received across the DSRC interface.
COMMISSIONING AND PERIODIC INSPECTION TESTS FOR THE REMOTE COMMUNICATION FUNCTION
6.1 General
- DSC_84Two type of tests are foreseen for the remote communication function:
- 1) An ECHO test to validate the DSRC-REDCR >>-:-<DSRC-VU wireless communication channel.
- 2) A End-to-end security test to ensure that a workshop card is able to access the encrypted and signed data content created by the VU and transmitted over the wireless communication channel.
6.2 ECHO
This clause contains provisions specifically made to test only that the DSRC-REDCR >>-:-<DSRC-VU is functionally active.
The objective of the ECHO command is to enable workshops or type approval test facilities to test that the DSRC link is working without needing access to security credentials. The tester's equipment therefore only needs to be able to initialise a DSRC communication (sending a BST with AID=2) and then send the ECHO command, and, assuming the DSRC is working, will receive the ECHO response. See 5.4.8 for details. Assuming it receives this response correctly, the DSRC link (DSRC-REDCR >>-:-<DSRC-VU) may be validated as functioning correctly.
6.3 Tests to validate the secure data content
- DSC_85This test is execute to validate the end-to-end security flow of data. A DSRC test reader is needed for such test. The DSRC test reader performs the same functionality and it is implemented with the same specifications of the reader used by the law enforcers, with the difference that a workshop card shall be used to authenticate the user of the DSRC test reader rather than a control card. The test can be executed after the initial activation of a Smart Tachograph or at the end of the calibration procedure. After the activation, the vehicle unit shall generate and communicate to the DSRC-VU the secured early detection data.
- DSC_86The workshop personnel must position the DSRC test reader at a distance between 2 and 10 metres in front of the vehicle.
- DSC_87Then the workshop personnel will insert a workshop card in the DSRC test reader to request the interrogation of the early detection data to the vehicle unit. After a successful interrogation, the workshop personnel will access the received data to ensure that it has been successfully validated for integrity and decrypted.
Addendum
Rules for the computation of daily, weekly and fortnightly driving time
- 1.Basic computation rules
- The VU shall compute the daily driving time, the weekly driving time and the fortnightly driving time using relevant data stored in a driver (or workshop) card inserted in the driver slot (slot 1, card reader #1) of the Vehicle Unit, and selected driver’s activities while this card is inserted in the VU.
- The driving times shall not be calculated while no driver (or workshop) card is inserted.
- UNKNOWN period(s) found during the time period needed for computations shall be assimilated to BREAK/REST.
- UNKNOWN periods and activities of negative duration (i.e. start of the activity occurs later than the end of the activity) due to time overlaps between two different VUs or due to time adjustment, are not taken into account.
- Activities recorded in the driver card corresponding to ‘OUT OF SCOPE’ periods in accordance with definition (gg) of Annex IC, shall be interpreted as follows:
- — BREAK/REST shall be computed as ‘BREAK’ or ‘REST’
- — WORK and DRIVING shall be considered as ‘WORK’
- — AVAILABILITY shall be considered as ‘AVAILABILITY’
- In the context of this Addendum, the VU shall assume to have a daily rest period at the beginning of the card activities records.
- 2.Concepts
- The following concepts apply exclusively to this appendix, and are intended to specify the computation of driving times by the VU and its later transmission by the remote communication facility.
- (a) ‘RTM-shift’ is the period between the end of a daily rest period and the end of the directly following daily rest period. The VU shall start a new RTM-shift after a daily rest period has finished. The ongoing RTM-shift is the period since the end of last daily rest period;
- (b) ‘accumulated driving time’ is the sum of the duration of all DRIVING activities of the driver within a period while not in OUT OF SCOPE;
- (c) ‘daily driving time’ is the accumulated driving time within a RTM-shift;
- (d) ‘weekly driving time’ is the accumulated driving time for the ongoing week;
- (e) ‘continuous rest period’ is any uninterrupted period of BREAK/REST;
- (f) ‘fortnightly driving time’ is the accumulated driving time for the previous and the ongoing week;
- (g) ‘daily rest period’ is a period of BREAK/REST, which can be either
- — a regular daily rest period,
- — a split daily rest period or
- — a reduced daily rest period In the context of Appendix 14, when a VU is computing weekly rest periods, those weekly rest periods shall be considered as daily rest periods;
- (h) ‘regular daily rest period’ is a continuous rest period of at least 11 hours. As a matter of exception, when a FERRY/TRAIN CROSSING condition is active the regular daily rest period may be interrupted a maximum of two times by activities other than rest, with a maximal accumulated duration of one hour, i.e. the regular daily rest period containing ferry/train crossing period(s) may be split into two or three parts. The VU shall then compute a regular daily rest period when the accumulated rest time computed according to point 3 is at least 11 hours. When a regular daily rest period has been interrupted the VU:
- — shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and
- — shall start a new RTM-shift at the end of the regular daily rest period that has been interrupted. Image omitted; see official source Figure 1.
Example of daily rest period interrupted due to ferry/train crossing
- (i) ‘reduced daily rest period’ is a continuous rest period of at least 9 hours and less than 11 hours;
- (j) ‘split daily rest period’ is a daily rest period taken in two parts:
- — the first part shall be a continuous rest period of at least 3 hours and less than 9,
- — the second part shall be a continuous rest period of at least 9 hours. As a matter of exception, when a FERRY/TRAIN CROSSING condition is active during one or both of the parts of a split daily rest period, the split daily rest period may be interrupted a maximum of two times by other activities with the accumulated duration of maximal one hour, i.e.:
- — the first part of the split daily rest period may be interrupted one or two times, or
- — the second part of the split daily rest period may be interrupted one or two times, or
- — the first part of the split daily rest period may be interrupted one time and the second part of the split daily rest period may be interrupted one time. The VU shall then compute a split daily rest period when the accumulated rest time computed according to point 3 is:
- — at least three hours and less than 11 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has been interrupted by FERRY/TRAIN CROSSING.
- — at least three hours and less than 9 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has not been interrupted by FERRY/TRAIN CROSSING. Image omitted; see official source Figure 2.
Example of split daily rest period interrupted due to ferry/train crossing When the split daily rest period is interrupted, the VU: - — shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and - — shall start a new RTM-shift at the end of the split daily rest period that has been interrupted;
- (k) ‘week’ is the period in UTC time between 00:00 hours on Monday and 24:00 hours on Sunday;
- 3.Computation of the rest period when it has been interrupted due to ferry/train crossing
- For the computation of the rest period when it has been interrupted due to ferry/train crossing, the VU shall calculate the accumulated rest time according to the following steps:
- a) Step 1 The VU shall detect interruptions to the rest time occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag, according to figure 3 and in its case figure 4, and shall evaluate for each interruption detected if the following conditions are met:
- — the interruption makes the total duration of the interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to exceed more than one hour in total,
- — the interruption makes the total number of interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to be bigger than two,
- — there is an ‘Entry of place where daily work periods end’ stored after the interruption ended. If none of the above conditions are met, the continuous rest period immediately preceding the interruption shall be added to the accumulated rest time. If at least one of the above conditions is met, the VU shall either stop the computation of the accumulated rest time according to step 2 or detect interruptions to the rest time occurring after the FERRY/TRAIN CROSSING (BEGIN) flag according to step 3.
- b) Step 2 For each interruption detected according to step 1, the VU shall evaluate whether the computation of the accumulated rest time should stop. The VU shall stop the computation process when two continuous rest periods occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag have been added to the accumulated rest time, including in its case rest periods added in the first part of a split daily rest period also interrupted by ferry/train crossing. Otherwise, the VU shall proceed according to step 3.
- c) Step 3 If after performance of step 2 the VU continues the computation of the accumulated rest time, the VU shall detect interruptions occurring after the deactivation of the FERRY/TRAIN CROSSING condition according to figure 3 and in its case figure 4. For each interruption found, the VU shall evaluate if the interruption makes the accumulated time of all the interruptions detected to exceed more than one hour in total, in which case the computation of the accumulated rest period shall finish at the end of the continuous rest period previous to the interruption. Otherwise, the continuous rest periods occurring after the respective interruptions shall be added to the computation of the daily rest period until the condition in step 4 is fulfilled.
- d) Step 4
The computation of the accumulated rest time shall stop when the VU has added, as result of steps 1 and 3, a maximum of two continuous rest periods to the rest period for which the FERRY/TRAIN CROSSING condition is activated, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing.
- Image omitted; see official source Figure 3.
Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as regular daily rest period or as the first part of a split daily rest period
- Image omitted; see official source Figure 4.
Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as the second part of a split daily rest period
- Image omitted; see official source Figure 5.
Example of a daily rest period interrupted more than twice causing rest period H not to be included in the computation
- Image omitted; see official source
Figure 6.
Example of a daily rest period where Ferry/Train Calculation period is commenced at end of work period
- Image omitted; see official source Figure 7.
Example of a daily rest period interrupted more than twice causing rest period B not to be included in the computation
- Image omitted; see official source
Figure 8.
Example of a split daily rest period interrupted once during the first rest period and once during 2nd rest period
- 4.Computation of daily, weekly and fortnightly- driving times
- The VU shall compute the daily driving time(s) for the ongoing and previous RTM-shifts. The driving time occurring during the interruptions of the daily rest periods shall not be added to the computation of the daily driving time, when such interruptions are due to ferry/train crossing and the requirements provided for in paragraphs (h) and (j) of point 2 and in point 3 have been fulfilled. Nevertheless, insofar as a complete regular or split daily rest period has not been computed by the VU according to point 3, the driving times occurring during the interruptions shall be added to the daily driving time for the ongoing RTM-shift.
- The VU shall also compute the weekly and the fortnightly driving times. The driving time occurring during the interruptions of the daily rest periods due to ferry/train crossing shall be added to the computation of the weekly and the fortnightly driving times.
Appendix 15
MIGRATION: MANAGING THE CO-EXISTENCE OF EQUIPMENT GENERATIONS AND VERSIONS
| | |
| --- | --- | | TABLE OF CONTENT | TABLE OF CONTENT | | 1. | DEFINITIONS | | 2. | GENERAL PROVISIONS | | 2.1. | Overview of the transition | | | | | 2.2. | Interoperability between VU and cards | | | | | 2.3. | Interoperability between VU and MS | | 2.4. | Interoperability between vehicle units, tachograph cards and equipment for data download | | 2.4.1 | Direct card download by IDE | | 2.4.2 | Card download through a vehicle unit | | 2.4.3 | Vehicle unit download | | 2.5. | Interoperability between VU and calibration equipment | | 3. | MAIN STEPS DURING THE PERIOD BEFORE THE INTRODUCTION DATE | | 4. | PROVISIONS FOR THE PERIOD AFTER THE INTRODUCTION DATE | | | | | 5. | RECORDING OF BORDER CROSSINGS IN FIRST GENERATION AND FIRST VERSION OF SECOND GENERATION TACHOGRAPHS | | | |
DEFINITIONS
For the purposes of this Appendix, the following definitions are used.
smart tachograph systemas defined by this Annex (chapter 1: definition bbb);
first generation tachograph systemas defined by this Regulation (article 2: definition 1);
second generation tachograph systemas defined by this Regulation (article 2: definition 7);
introduction dateas defined by this Annex (chapter 1: definition ccc);
Intelligent Dedicated Equipment (IDE)equipment used to perform data downloading, as defined in Appendix 7 of this Annex.
2. GENERAL PROVISIONS
2.1. Overview of the transition
The introduction of this Annex provides an overview of the transition between the first and the second generation tachograph systems, and of the introduction of the second version of second generation recording equipment and tachograph cards.
In addition to the provisions of this introduction, the following information can be reminded:
- — first generation motion sensors are not interoperable with any version of second generation vehicle units,
- — only second generation motion sensors can be installed in vehicles equipped with any version of second generation vehicle units,
- — data download and calibration equipment need to support use of both generations or versions of recording equipment and tachograph cards.
2.2. Interoperability between VU and cards
It is understood that first generation tachograph cards are interoperable with first generation vehicle units (in compliance with Annex IB of Regulation (EEC) No 3821/85), any version of second generation tachograph cards are interoperable with any version of second generation vehicle units (in compliance with Annex IC of this Regulation). In addition, the requirements below shall apply.
- MIG_001 Except as provided for in requirement MIG_004 and MIG_005, first generation tachograph cards may continue to be used in any version of second generation vehicle units until their end of validity date. Their holders may however ask for their replacement by second generation tachograph cards as soon as they are available.
- MIG_002 Any version of second generation vehicle units shall be able to use any valid first generation driver, control and company card inserted.
- MIG_003 This capability may be suppressed once and forever in such vehicle units by workshops, so that first generation tachograph cards cannot be accepted anymore. This may only be done after the European Commission has launched a procedure aiming to request workshops to do so, for example during each periodic inspection of tachograph.
- MIG_004 Second generation vehicle units shall only be able to use second generation workshop cards.
- MIG_005 For determining the mode of operation, any version of second generation vehicle units shall only consider the types of the valid cards inserted, regardless of their generations or versions.
- MIG_006 Any version of valid second generation tachograph card shall be able to be used in first generation vehicle units exactly the same manner as a first generation tachograph card of the same type.
2.3. Interoperability between VU and MS
It is understood that first generation motion sensors are interoperable with first generation vehicle units, while second generation motion sensors are interoperable with any version of second generation vehicle units. In addition, the requirements below shall apply.
- MIG_007 Any version of second generation vehicle units shall not be able to be paired and used with first generation motion sensors.
- MIG_008 Second generation motion sensors may be paired and used with second generation vehicle units only, whichever the version, or with both generations of vehicle units.
2.4. Interoperability between vehicle units, tachograph cards and equipment for data download
- MIG_009 Equipment for data download may be compatible with all generations and versions of vehicle units and tachograph cards.
2.4.1 Direct card download by IDE
- MIG_010 Data shall be downloaded by IDE from tachograph cards of one generation inserted in their card readers, using the security mechanisms and the data download protocol of this generation, and downloaded data shall have the format defined for this generation and version.
- MIG_011 To allow drivers’ control by non EU control authorities, it shall also be possible to download second generation driver (and workshop) cards, whichever the version, in exactly the same manner as first generation drivers (and workshop) cards. Such download shall include:
- — non signed EFs IC and ICC (optional),
- — non signed EFs (first generation) Card_Certificate and CA_Certificate,
- — the other application data EFs (within DF Tachograph) requested by the first generation card download protocol. This information shall be secured with a digital signature, according to the first generation security mechanisms. Such download shall not include application data EFs only present in version 1 or version 2 second generation driver (and workshop) cards (application data EFs within DF Tachograph_G2).
2.4.2 Card download through a vehicle unit
- MIG_012 Data shall be downloaded from any version of second generation card, inserted in a first generation vehicle unit using the first generation data download protocol. The card shall answer to the vehicle unit commands exactly the same manner as a first generation card and downloaded data shall have the same format as data downloaded from a first generation card.
- MIG_013 Data shall be downloaded from a first generation card inserted in any version of second generation vehicle unit using the data download protocol defined in Appendix 7 of this Annex. The vehicle unit shall send commands to the card exactly the same manner as a first generation vehicle unit, and downloaded data shall respect the format defined for first generation cards.
2.4.3 Vehicle unit download
- MIG_014 Outside of the frame of drivers' control by non EU control authorities, data shall be downloaded from second generation vehicle units using the second generation security mechanisms, and the data download protocol specified in Appendix 7 of this Annex for the relevant version.
- MIG_015 To allow drivers' control by non EU control authorities, it may optionally also be possible to download data from any version of second generation vehicle units using the first generation security mechanisms. Downloaded data shall then have the same format as data downloaded from a first generation vehicle unit. This capability may be selected through commands in the menu.
2.5. Interoperability between VU and calibration equipment
- MIG_016 Calibration equipment shall be able to perform calibration of each generation or version of tachograph, using the calibration protocol of this generation or version. Calibration equipment may be compatible with all generations and versions of vehicle units.
MAIN STEPS DURING THE PERIOD BEFORE THE INTRODUCTION DATE
- MIG_017 Test keys and certificates shall be available to manufacturers at the publication date of this Annex.
- MIG_018 Interoperability tests shall be ready to start with version 2 of vehicle units and version 2 of tachograph cards if requested by manufacturers at the latest 15 months before the introduction date.
- MIG_019 For version 2 of generation 2 tachographs, tachograph cards and motion sensors, the same keys and certificates are used as for generation 2 version 1 equipment.
- MIG_020 Member States shall be able to issue version 2 of second generation workshop cards at the latest 1 month before the introduction date.
- MIG_021 Member States shall be able to issue all other types of version 2 of second generation tachograph cards at the latest 1 month before the introduction date.
PROVISIONS FOR THE PERIOD AFTER THE INTRODUCTION DATE
- MIG_022 With effect from the introduction date, Member States shall only issue version 2 of second generation tachograph cards.
- MIG_023 Vehicle units / motion sensors manufacturers shall be allowed to produce first generation vehicle units / motion sensors as long as they are used in the field, so that malfunctioning components can be replaced.
- MIG_023a With effect from the introduction date, malfunctioning version 1 of second generation vehicle units or external GNSS facilities shall be replaced with version 2 of second generation vehicle units or external GNSS facilities.
- MIG_024 Vehicle units / motion sensors manufacturers shall be allowed to request and obtain type approval maintenance of first generation vehicle units / motion sensors types or version 1 of second generation vehicle units already type approved.
RECORDING OF BORDER CROSSINGS IN FIRST GENERATION AND FIRST VERSION OF SECOND GENERATION TACHOGRAPHS
- MIG_025 The symbol of the country and, if applicable, the region that the driver enters after crossing a border of a Member State in application of Article 34(7) of Regulation (EU) No 165/2014, shall be entered as a place where the daily work period begins in accordance with the manual entry of places set out in requirements 60 of Annex IC to Regulation (EU) No 165/2014 and 50 of Annex IB to Regulation (EEC) No 3821/85.
Appendix 16
ADAPTOR FOR M1 AND N1 CATEGORY VEHICLES
| TABLE OF CONTENTS | TABLE OF CONTENTS |
| 1. | ABBREVIATIONS AND REFERENCE DOCUMENTS |
| 1.1. | Abbreviations |
| 1.2. | Reference standards |
| 2. | GENERAL CHARACTERISTICS AND FUNCTIONS OF THE ADAPTOR |
| 2.1. | Adaptor general description |
| 2.2. | Functions |
| 2.3. | Security |
| 3. | REQUIREMENTS FOR THE RECORDING EQUIPMENT WHEN AN ADAPTOR IS INSTALLED |
| 4. | CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR THE ADAPTOR |
| 4.1. | Interfacing and adapting incoming speed pulses |
| 4.2. | Inducing the incoming pulses to the embedded motion sensor |
| 4.3. | Embedded motion sensor |
| 4.4. | Security requirements |
| 4.5. | Performance characteristics |
| 4.6. | Materials |
| 4.7. | Markings |
| 5. | INSTALLATION OF THE RECORDING EQUIPMENT WHEN AN ADAPTOR IS USED |
| 5.1. | Installation |
| 5.2. | Sealing |
| 6. | CHECKS, INSPECTIONS AND REPAIRS |
| 6.1. | Periodic inspections |
| 7. | TYPE APPROVAL OF RECORDING EQUIPMENT WHEN AN ADAPTOR IS USED |
| 7.1. | General points |
| 7.2. | Functional certificate |
1. ABBREVIATIONS AND REFERENCE DOCUMENTS
1.1. Abbreviations
- TBD To Be Defined
- VU Vehicle Unit
1.2. Reference standards
ISO16844-3 Road vehicles — Tachograph systems — Part 3: Motion sensor interface
2. GENERAL CHARACTERISTICS AND FUNCTIONS OF THE ADAPTOR
2.1. Adaptor general description
- ADA_001The adaptor shall provide a connected VU with secured motion data permanently representative of vehicle speed and distance travelled.
- The adaptor is only intended for those vehicles that are required to be equipped with recording equipment in compliance with this Regulation.
- It shall be installed and used only in those types of vehicle defined in definition yy) ‘adaptor’ of Annex IC where it is not mechanically possible to install any other type of existing motion sensor which is otherwise compliant with the provisions of this Annex and its Appendixes 1 to 16.
- The adaptor shall not be mechanically interfaced to a moving part of the vehicle, but connected to the speed/distance impulses which are generated by integrated sensors or alternative interfaces.
- ADA_002A type approved motion sensor (according to the provisions of this Annex IC, section 8, Type approval of recording equipment and tachograph cards) shall be fitted into the adaptor housing, which shall also include a pulse converter device inducing the incoming pulses to the embedded motion sensor. The embedded motion sensor itself shall be connected to the VU, so that the interface between the VU and the adaptor shall be compliant with the requirements set out in ISO16844-3.
2.2. Functions
- ADA_003The adaptor shall include the following functions:
- — interfacing and adapting the incoming speed pulses,
- — inducing the incoming pulses to the embedded motion sensor,
- — all functions of the embedded motion sensor, providing secured motion data to the VU.
2.3. Security
- ADA_004The adaptor shall not be security certified according to the motion sensor generic security target defined in Appendix 10 of this Annex. Security related requirements specified in section 4.4 of this Appendix shall apply instead.
REQUIREMENTS FOR THE RECORDING EQUIPMENT WHEN AN ADAPTOR IS INSTALLED
The requirements in the following Chapters indicate how the requirements of this Annex shall be understood when an adaptor is used. The related requirement numbers of Annex IC are provided between brackets.
- ADA_005The recording equipment of any vehicle fitted with an adaptor must comply with all the provisions of this Annex, except otherwise specified in this Appendix.
- ADA_006When an adaptor is installed, the recording equipment includes cables, the adaptor (including a motion sensor), and a VU [01].
- ADA_007The detection of events and/or faults function of the recording equipment is modified as follows:
- — the ‘power supply interruption’ event shall be triggered by the VU, while not in calibration mode, in case of any interruption exceeding 200 milliseconds of the power supply of the embedded motion sensor [79]
- — the ‘motion data error’ event shall be triggered by the VU in case of interruption of the normal data flow between the embedded motion sensor and the VU and/or in case of data integrity or data authentication error during data exchange between the embedded motion sensor and the VU [83]
- — the ‘security breach attempt’ event shall be triggered by the VU for any other event affecting the security of the embedded motion sensor, while not in calibration mode [85]
- — the ‘recording equipment’ fault shall be triggered by the VU, while not in calibration mode, for any fault of the embedded motion sensor [88]
- ADA_008The adaptor faults detectable by the recording equipment shall be those related with the embedded motion sensor [88].
- ADA_009The VU calibration function shall allow to automatically pair the embedded motion sensor with the VU [202, 204].
CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR THE ADAPTOR
4.1. Interfacing and adapting incoming speed pulses
- ADA_011The adaptor input interface shall accept frequency pulses representative of the vehicle speed and distance travelled. Electrical characteristics of the incoming pulses are: TBD by the manufacturer. Adjustments accessible to only the adaptor manufacturer, and to the approved workshop performing the adaptor installation shall allow the correct interfacing of the adaptor input to the vehicle, if applicable.
- ADA_012The adaptor input interface shall be able, if applicable, to multiply or divide the frequency pulses of the incoming speed pulses by a fixed factor, to adapt the signal to the k factor range defined by this Annex (2 400 to 25 000 pulses/km). This fixed factor may only be programmed by the adaptor manufacturer, and the approved workshop performing the adaptor installation.
4.2. Inducing the incoming pulses to the embedded motion sensor
- ADA_013The incoming pulses, possibly adapted as specified above, shall be induced to the embedded motion sensor, so that each incoming pulse shall be detected by the motion sensor.
4.3. Embedded motion sensor
- ADA_014The embedded motion sensor shall be stimulated by the induced pulses, thus allowing it to generate motion data accurately representing the vehicle movement, as if it was mechanically interfaced to a moving part of the vehicle.
- ADA_015The identification data of the embedded motion sensor shall be used by the VU to identify the adaptor [95].
- ADA_016The installation data stored in the embedded motion sensor shall be considered to represent the adaptor installation data [122].
4.4. Security requirements
- ADA_017The adaptor housing shall be designed so that it cannot be opened. It shall be sealed, so that physical tampering attempts can be easily detected (e.g. through visual inspection, see ADA_035). Seals shall follow the same requirements of motion sensor seals [398 to 406]
- ADA_018It shall not be possible to remove the embedded motion sensor from the adaptor without breaking the seal(s) of the adaptor housing, or breaking the seal between the sensor and the adaptor housing (see ADA_034).
- ADA_019The adaptor shall ensure that motion data may only been processed and derived from the adaptor input.
4.5. Performance characteristics
- ADA_020The adaptor shall be fully operational in the temperature range defined by the manufacturer.
- ADA_021The adaptor shall be fully operational in the humidity range 10 % to 90 % [214].
- ADA_022The adaptor shall be protected against over-voltage, inversion of its power supply polarity, and short circuits [216].
- ADA_023The adaptor shall either:
- — react to a magnetic field disturbing vehicle motion detection. In such circumstances, the vehicle unit will record and store a sensor fault [88] or,
- — have a sensing element that is protected from, or immune to, magnetic fields [217].
- ADA_024The adaptor shall conform to international regulation UN ECE R10, related to electromagnetic compatibility, and shall be protected against electrostatic discharges and transients [218].
4.6. Materials
- ADA_025The adaptor shall meet the protection grade (TBD by the manufacturer, depending on the installation position) [220, 221].
- ADA_026The colour of the adaptor housing shall be yellow.
4.7. Markings
- ADA_027A descriptive plaque shall be affixed to the adaptor and shall show the following details:
- — name and address of the manufacturer of the adaptor,
- — manufacturer's part number and year of manufacture of the adaptor,
- — approval mark of the adaptor type or of the recording equipment type including the adaptor,
- — the date on which the adaptor has been installed,
- — the vehicle identification number of the vehicle on which it has been installed.
- ADA_028The descriptive plaque shall also show the following details (if not directly readable from the outside on the embedded motion sensor):
- — name of the manufacturer of the embedded motion sensor,
- — manufacturer's part number and year of manufacture of the embedded motion sensor,
- — approval mark for the embedded motion sensor.
INSTALLATION OF THE RECORDING EQUIPMENT WHEN AN ADAPTOR IS USED
5.1. Installation
- ADA_029Adaptors to be installed in vehicles shall only be installed by vehicle manufacturers, or by approved workshops, authorised to install, activate and calibrate digital and smart tachographs.
- ADA_030Such approved workshop installing the adaptor shall adjust the input interface and select the division ratio of the input signal (if applicable).
- ADA_031Such approved workshop installing the adaptor shall seal the adaptor housing.
- ADA_032The adaptor shall be fitted as close as possible to that part of the vehicle which provides its incoming pulses.
- ADA_033The cables for providing the adaptor power supply shall be red (positive supply) and black (ground).
5.2. Sealing
- ADA_034The following sealing requirements shall apply:
- — the adaptor housing shall be sealed (see ADA_017),
- — the housing of the embedded sensor shall be sealed to the adaptor housing, unless it is not possible to remove the sensor from the adaptor housing without breaking the seal(s) of the adaptor housing (see ADA_018),
- — the adaptor housing shall be sealed to the vehicle,
- — the connection between the adaptor and the equipment which provides its incoming pulses shall be sealed on both ends (to the extent of what is reasonably possible).
CHECKS, INSPECTIONS AND REPAIRS
6.1. Periodic inspections
- ADA_035When an adaptor is used, each periodic inspection (periodic inspections means in compliance with Requirement [409] through to Requirement [413] of Annex 1C) of the recording equipment shall include the following checks:
- — that the adaptor carries the appropriate type approval markings,
- — that the seals on the adaptor and its connections are intact,
- — that the adaptor is installed as indicated on the installation plaque,
- — that the adaptor is installed as specified by the adapter and/or vehicle manufacturer,
- — that mounting an adaptor is authorised for the inspected vehicle.
- ADA_036These inspections shall include a calibration and a replacement of all seals, whatever their state.
TYPE APPROVAL OF RECORDING EQUIPMENT WHEN AN ADAPTOR IS USED
7.1. General points
- ADA_037Recording equipment shall be submitted for type approval complete, with the adaptor [425].
- ADA_038Any adaptor may be submitted for its own type approval, or for type approval as a component of a recording equipment.
- ADA_039Such type approval shall include functional tests involving the adaptor. Positive results to each of these tests are stated by an appropriate certificate [426].
7.2. Functional certificate
- ADA_040A functional certificate of an adaptor or of recording equipment including an adaptor shall be delivered to the adaptor manufacturer only after all the following minimum functional tests have been successfully passed.
| No | Test | Description | Related requirements |
|---|---|---|---|
| 1. | Administrative examination | Administrative examination | Administrative examination |
| 1.1 | Documentation | Correctness of documentation of the adaptor | |
| 2. | Visual inspection | Visual inspection | Visual inspection |
| 2.1. | Compliance of the adaptor with documentation | Compliance of the adaptor with documentation | |
| 2.2. | Identification / markings of the adaptor | Identification / markings of the adaptor | ADA_027, ADA_028 |
| 2.3 | Materials of the adaptor | Materials of the adaptor | [219] to [223] ADA_026 |
| 2.4. | Sealing | Sealing | ADA_017, ADA_018, ADA_034 |
| 3. | Functional tests | Functional tests | Functional tests |
| 3.1 | Inducing the speed pulses to the embedded motion sensor | Inducing the speed pulses to the embedded motion sensor | ADA_013 |
| 3.2 | Interfacing and adapting incoming speed pulses | Interfacing and adapting incoming speed pulses | ADA_011, ADA_012 |
| 3.3 | Motion measurement accuracy | Motion measurement accuracy | [30] to [35], [217] |
| 4. | Environmental tests | Environmental tests | Environmental tests |
| 4.1 | Manufacturer test results | Results of manufacturer environment tests. | ADA_020, ADA_021, ADA_022, ADA_024 |
| 5. | EMC | EMC | EMC |
| 5.1 | radiated emissions and susceptibility | Verify compliance with Directive 2006/28/EC | ADA_024 |
| 5.2 | Manufacturer test results | Results of manufacturer environment tests. | ADA_024 |
Appendix 17
TRANSITIONAL PROVISIONS RELATED TO THE USE OF OSNMA BY TACHOGRAPHS
DEFINITIONS AND ACRONYMS
1.1. Definitions
Service Declaration of Galileo Open Service Navigation Message Authentication (OSNMA) means the declaration of the European Commission that Galileo OSNMA enters its operational phase.
Transitional vehicle unit: Vehicle unit complying with the provisions of this Appendix.
Transitional vehicle units are constructed in accordance with the SIS ICD and the OSNMA receiver guidelines applicable to the OSNMA public test phase. They contain a GNSS receiver which is capable of using OSNMA available during its public test phase.
Transitional vehicle units are however unable to authenticate the navigation messages available after the Service Declaration of OSNMA, due to a necessary update of the cryptographic material in the vehicle unit. An appropriate software update needs to be applied, so that they can start to use OSNMA, and comply with all the requirements of Annex IC and its Appendixes 1 to 16. Before being updated, transitional vehicle units implement the OSNMA related functionalities as specified in this Appendix. Functionalities unrelated to OSNMA remain unchanged.
If the appropriate software update is applied, transitional vehicle units implement the SIS ICD and the OSNMA receiver guidelines applicable to the OSNMA operational phase, and comply with all the requirements of Annex IC and its Appendixes 1 to 16, using OSNMA available during the operational phase.
Transitional tachograph: tachograph including a transitional vehicle unit.
1.2. Acronyms
| ICD | Interface Control Document |
| OSNMA | Galileo Open Service Navigation Message Authentication |
| SIS | Signal in Space |
| VU | Vehicle Unit |
GENERAL CONSIDERATIONS RELATED TO OSNMA
In order to allow vehicles registered for the first time to be fitted with version 2 of second generation tachographs, starting from the requested introduction date as defined in point (ccc) of Section 1 of Annex I C to Implementing Regulation (EU) 2016/799, there is a need to type-approve, produce and commercialize vehicle units before the Service Declaration of OSNMA. For these vehicle units, referred to as transitional vehicle units, OSNMA-related requirements of Annex IC and its Appendixes 1 to 16 need to be adapted, so that they can be type approved and used in the field.
The provisions laid down in this Appendix define the specific requirements applicable to transitional vehicle units. They only apply to vehicle units with an internal GNSS receiver.
REQUIREMENTS APPLICABLE TO THE GNSS RECEIVER OF TRANSITIONAL TACHOGRAPHS
- TRA_001 Transitional vehicle units shall include a GNSS receiver capable of using OSNMA available during its public test phase.
- TRA_002 Appendix 12 requirements apply to the GNSS receiver included in transitional vehicle units, with the following interpretations:
- — SIS ICD and OSNMA Receiver Guidelines referred to are the documents available for the public test phase: — Galileo Open Service Navigation Message Authentication (OSNMA) User ICD for the Test Phase, Issue 1.0, November 2021, — Galileo Open Service Navigation Message Authentication (OSNMA) Receiver Guidelines for the Test Phase, Issue 1.0, November 2021,
- — OSNMA is the service available during the public test phase,
- — SIS is the Signal In Space available during the public test phase.
- TRA_003 The GNSS receiver included in transitional vehicle units shall be so designed that after an update of its software, applied through a vehicle unit software update, it fully complies with Annex 12 requirements, using OSNMA available during its operational phase.
REQUIREMENTS APPLICABLE TO TRANSITIONAL VEHICLE UNITS
Transitional vehicle units may process the OSNMA signal available during its public test phase, but are not able to report the Navigation Messages Authentication Status from the SIS available during OSNMA operational phase, until an appropriate software update is applied. They therefore assume that the standard positions provided by the GNSS receiver are always authenticated.
The requirements of Annex IC and its Appendixes 1 to 16 apply, with the following interpretations.
- TRA_004 Annex IC, 3.9.15 ‘Time conflict’ event, requirement 86, shall be understood as:
- This event shall be triggered, while not in calibration mode, when the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the standard positions transmitted by the GNSS receiver or the external GNSS facility. A ‘ time discrepancy’ is detected if the time difference exceeds ± 3 seconds corresponding to the time accuracy set out in requirement 41a, the latter increased by the maximal time drift per day. This event shall be recorded together with the internal clock value of the recording equipment. The VU shall perform the check for triggering the ‘time conflict’ event right before the VU automatically re-adjusts the VU internal clock, in accordance with requirement 211.
- TRA_005 Annex IC, 3.9.18 ‘GNSS anomaly’ event, requirement 88a, shall be understood as:
- This event shall be triggered, while not in calibration mode, when the GNSS receiver detects an attack , as specified in Appendix 12. After a GNSS anomaly event has been triggered, the VU shall not generate other GNSS anomaly events for the next 10 minutes.
- TRA_006 Annex IC, 3.12.5 Recording and storing in the data memory, Places and positions where daily work periods begin, end, and/or where 3 hours accumulated driving time is reached, requirement 110, shall be understood as:
- Together with each place or position, the recording equipment shall record and store in its data memory:
- — the driver and/or co-driver card number and card issuing Member State,
- — the card generation,
- — the date and time of the entry,
- — the type of entry (begin, end or 3 hours accumulated driving time),
- — the related GNSS accuracy, date and time if applicable,
- — the vehicle odometer value,
- — a flag indicating that the position has been assumed as authenticated.
- TRA_007 Annex IC, 3.12.17 Recording and storing in the data memory, Border crossings, requirement 133b, shall be understood as:
- Together with countries and position, the recording equipment shall record and store in its data memory:
- — the driver and/or co-driver card number and card issuing Member State,
- — the card generation,
- — the related GNSS accuracy, date and time,
- — a flag indicating that the position has been assumed as authenticated,
- — the vehicle odometer value at the time of border crossing detection.
- TRA_008 Annex IC, 3.12.18 Recording and storing in the data memory, Load/unload operations, requirement 133g, shall be understood as:
- Together with the type of operation and position, the recording equipment shall record and store in its data memory:
- — the driver and/or co-driver card number and card issuing Member State,
- — the card generation,
- — the date and time of the load/unload operation,
- — the related GNSS accuracy, date and time if applicable,
- — a flag indicating that the position has been assumed as authenticated,
- — the vehicle odometer value.
- TRA_009 Annex IC, 3.23 Time adjustment, requirement 211, shall be understood as:
- The time setting of the VU internal clock shall be automatically re-adjusted, at variable time intervals. The next automatic time re-adjustment shall be triggered between 72h and 168h after the previous one, and after the VU can access to GNSS time through a valid standard position message in accordance with Appendix 12. Nevertheless, the time adjustment shall never be bigger than the accumulated maximal time drift per day, as calculated by the VU manufacturer in accordance with requirement 41b. If the difference between internal VU clock time and GNSS receiver time is bigger than the accumulated maximum time drift per day, then the time adjustment shall bring the VU internal clock as close as possible to the GNSS receiver time. The time setting may only be done if the time provided by the GNSS receiver is obtained using standard position messages as set out in Appendix 12. The time reference for the automatic time setting of the VU internal clock shall be the time provided in the standard position message.
- TRA_010 Annex IC, 3.23 Time adjustment, requirement 212, shall be understood as:
- The time adjustment function shall also allow for triggered adjustment of the current time, in calibration mode.
- Workshops may adjust time:
- — either by writing a time value in the VU, using the WriteDataByIdentifier service in accordance with section 6.2 of Appendix 8,
- — or by requesting an alignment of the VU clock to the time provided by the GNSS receiver. This may only be done if the time provided by the GNSS receiver is obtained using standard position messages. In this latter case, the RoutineControl service shall be used in accordance with section 8 of Appendix 8.
- TRA_011 Appendix 4, 2. Data blocks specification, first paragraph, seventh indent, shall be understood as:
- When printed after the longitude and the latitude of a recorded position, or after the timestamp when the position was determined, the Image omitted; see official source pictogram indicates that this position has been assumed as authentic.
- TRA_012
Appendix 8, 8.1 RoutineControl service (Time adjustment), Message description, requirement CPR_065a, shall be understood as:
- The service RoutineControl (TimeAdjustment) provides the ability to trigger an alignment of the VU clock to the time provided by the GNSS receiver.
- For the service RoutineControl (TimeAdjustment) execution the VU must be in CALIBRATION mode.
- Precondition: it is ensured that the VU is able to receive standard position messages from the GNSS receiver.
- As long the time adjustment is ongoing, the VU shall respond to the request RoutineControl, subfunction requestRoutineResults, with routineInfo = 0x78.
- Note: the time adjustment may take some time. The diagnostic tester shall request the time adjustment status by using the sub-function requestRoutineResults.
- TRA_013 In Appendix 12, 3 Sentences provided by the GNSS receiver, requirement GNS_4a:
- Data contained in the AMC sentences provided by the GNSS receiver, if any, shall not be used by the vehicle unit, except for the following values of the Status:
J = jamming or O = other GNSS attack (by implemented consistency checks according to GNS_3a),
V = Void (authenticated position is not available for any other reason).
- TRA_014
In Appendix 12, 3 Sentences provided by the GNSS receiver, requirement GNS_5:
- Data contained in the ASA sentences provided by the GNSS receiver, if any, shall not be used by the vehicle unit.
- TRA_015 In Appendix 12, 5.2 Vehicle Unit without an external GNSS facility, Transfer of information from the GNSS receiver to the VU, requirements GNS_34 and 36:
- The VU processor shall not use information extracted from the AMC sentence, except for the following values of the Status:
J = jamming or O = other GNSS attack (by implemented consistency checks according to GNS_3a),
V = Void (authenticated position is not available for any other reason).
- The VU processor shall not use information extracted from the ASA sentence.
- TRA_016 Appendix 12, 6 Position data processing and recording by the VU, requirement GNS_39, shall be understood as:
- Position data shall be stored in the VU, together with a flag indicating if the position has been assumed as authenticated. When position data need to be recorded in the VU, the following rule shall apply:
- (a) If the standard position is valid, the standard position and its accuracy shall be recorded in the VU and the flag shall be set to ‘authenticated’.
- TRA_017 Appendix 12, 6 Position data processing and recording by the VU, requirement GNS_40, shall be understood as:
- When the value of the Status in a received AMC sentence is set to ‘J’ or ‘O’ in accordance with requirement GNS_4a, the VU shall generate and record a GNSS anomaly event, as defined in requirement 88a of Annex IC and Appendix 1 (EventFaultType), The vehicle unit may perform additional checks before storing a GNSS anomaly event following the reception of a ‘J’ or ‘O’ setting.
- TRA_018 Appendix 12, 8 Vehicle motion conflict, requirement GNS_42, Trigger condition 2, the first and second indents after the formula shall be understood as:
- — GnssDistance is the distance between the current position of the vehicle and the previous one, both obtained from valid standard position messages, without considering the height,
- — OdometerDifference is the difference between the current odometer value and the odometer value corresponding to the previous valid standard position message.
- TRA_019 Appendix 14, 5.4.5 DSRC Protocol requirements for RTMElements of RtmData, actions performed and definitions, requirement DSC_41, Table 14.3, second cell in the RTM20 row, shall be understood as:
- The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM20.
- The VU shall set the value of RTM20 to the time at which the latest standard vehicle position was available from the GNSS receiver.
- If no standard vehicle position was available ever from the GNSS receiver the VU shall set the value of RTM20 to 0.
- TRA_020 The manufacturer of a type approved transitional vehicle unit shall inform the Commission of its software versions. The Commission shall publish these software versions on a publicly available website.
SPECIFIC PROVISIONS FOR TYPE APPROVAL AND USE OF TRANSITIONAL TACHOGRAPHS
- TRA_021 Transitional vehicle units shall be type approved according to the requirements of Annex IC and its Annexes 1 to 16, supplemented by the provisions of this Appendix.
- TRA_022 Type approval certificates of transitional vehicle units and transitional tachographs may only be requested until 31 December 2023 or the Service Declaration date of OSNMA, whichever is the latest.
- TRA_023 Transitional vehicle units may be fitted in vehicles registered for the first time only until 31 May 2024 or 5 months after the Service Declaration date of OSNMA, whichever is the latest.
ANNEX II
APPROVAL MARK AND CERTIFICATE
I. APPROVAL MARK
- 1.The approval mark shall be made up of:
- (a) a rectangle, within which shall be placed the letter ‘e’ followed by a distinguishing number or letter for the country which has issued the approval in accordance with the following conventional signs: Belgium 6, Bulgaria 34, Czech Republic 8, Denmark 18, Germany 1, Estonia 29, Ireland 24, Greece 23, Spain 9, France 2, Croatia 25, Italy 3, Cyprus CY, Latvia 32, Lithuania 36, Luxembourg 13, Hungary 7, Malta MT, Netherlands 4, Austria 12, Poland 20, Portugal 21, Romania 19, Slovenia 26, Slovakia 27, Finland 17, Sweden 5, United Kingdom 11, and
- (b) an approval number corresponding to the number of the approval certificate drawn up for the prototype of the recording equipment or the record sheet or the tachograph card, placed at any point within the immediate proximity of that rectangle.
- 2.The approval mark shall be shown on the descriptive plaque of each set of equipment and on each record sheet and on each tachograph card. It must be indelible and must always remain clearly legible.
- 3.The dimensions of the approval mark drawn below ([^E0025]) are expressed in millimetres, these dimensions being minima. The ratios between the dimensions must be maintained.
II. APPROVAL CERTIFICATE FOR ANALOGUE TACHOGRAPHS
A Member State which has granted approval shall issue the applicant with an approval certificate, the model of which is given below. When informing other Member States of approvals issued or, if the occasion should arise, withdrawn, a Member State shall use copies of that certificate.
APPROVAL CERTIFICATE
Name of competent administration …
Notification concerning ([^E0026]):
- — approval of a type of recording equipment
- — withdrawal of approval of a type of recording equipment
- — approval of a model record sheet
- — withdrawal of approval of a model record sheet
Approval No:
….
-
- Trade mark or name …
-
- Name of type or model …
-
- Name of manufacturer …
-
- Address of manufacturer …
-
- Submitted for approval on …
-
- Tested at …
-
- Date and number of the test(s) …
-
- Date of approval …
-
- Date of withdrawal of approval …
-
- Type or types of recording equipment in which sheet is designed to be used
- 11. Place …
-
- Date …
- 13. Descriptive documents annexed …
-
- Remarks (including the position of seals if applicable)
(Signature)
III. APPROVAL CERTIFICATE FOR DIGITAL TACHOGRAPHS
A Member State which has granted approval shall issue the applicant with an approval certificate, the model of which is given below. When informing other Member States of approvals issued or, if the occasion should arise, withdrawn, a Member State shall use copies of that certificate.
APPROVAL CERTIFICATE FOR DIGITAL TACHOGRAPHS
Name of competent administration …
Notification concerning ([^E0027]):
- □approval of:
- □withdrawal of approval of:
- □ recording equipment model
- □ recording equipment component ([^E0028])
- □ a driver's card
- □ a workshop card
- □ a company card
- □ a controller's card
Approval No:
….
-
- Manufacturing brand or trademark …
-
- Name of model …
-
- Name of manufacturer …
-
- Address of manufacturer …
-
- Submitted for approval on …
-
- Laboratory(-ies) …
-
- Date and number of test report …
-
- Date of approval …
-
- Date of withdrawal of approval …
-
- Model of recording equipment(s) with which the component is designed to be used
-
- Place …
-
- Date …
-
- Descriptive documents annexed …
-
- Remarks (including the position of seals if applicable)
(Signature)
IV. APPROVAL CERTIFICATE FOR SMART TACHOGRAPHS
A Member State which has granted approval shall issue the applicant with an approval certificate, the model of which is given below. When informing other Member States of approvals issued or, if the occasion should arise, withdrawn, a Member State shall use copies of that certificate.
APPROVAL CERTIFICATE FOR SMART TACHOGRAPHS
Name of competent administration …
Notification concerning ([^E0029]):
- □approval of:
- □withdrawal of approval of:
- □ recording equipment model
- □ recording equipment component ([^E0030])
- □ a driver's card
- □ a workshop card
- □ a company card
- □ a controller's card
Approval No:
….
-
- Manufacturing brand or trademark …
-
- Name of model …
-
- Name of manufacturer …
-
- Address of manufacturer …
-
- Submitted for approval on …
-
-
- (a) Test laboratory for functional certification …
-
- (b) Test laboratory for security certification …
- (c) Test laboratory for interoperability certification …
-
-
- (a) Date and number of functional certificate …
-
- (b) Date and number of security certificate …
- (c) Date and number of interoperability certificate …
-
- Date of approval …
-
- Date of withdrawal of approval …
-
- Model of recording equipment(s) with which the component is designed to be used
-
- Place …
-
- Date …
-
- Descriptive documents annexed …
-
- Remarks (including the position of seals if applicable)
(Signature)
[^E0001]: Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (OJ L 370, 31.12.1985, p. 8).
[^E0002]: Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC (OJ L 153, 22.5.2014, p. 62).
[^E0003]: This way of computing the continuous driving time and the cumulative break time serves in the recording equipment for computing the continuous driving time warning. It does not prejudge the legal interpretation to be made of these times. Alternative ways of computing the continuous driving time and the cumulative break time may be used to replace these definitions if they have been made obsolete by updates in other relevant legislation.
[^E0004]: UNKNOWN periods correspond to periods where the driver card was not inserted in the recording equipment and for which no manual entry of driver activities was made.
[^E0005]: Regulation (EC) No 561/2006 of the European Parliament and of the Council of 15 March 2006 on the harmonisation of certain social legislation relating to road transport and amending Council Regulations (EEC) No 3821/85 and (EC) No 2135/98 and repealing Council Regulation (EEC) No 3820/85 (OJ L 102, 11.4.2006, p. 1).
[^E0006]: Commission Regulation (EU) No 1230/2012 of 12 December 2012 implementing Regulation (EC) No 661/2009 of the European Parliament and of the Council with regard to type-approval requirements for masses and dimensions of motor vehicles and their trailers and amending Directive 2007/46/EC of the European Parliament and of the Council (OJ L 353, 21.12.2012, p. 31) as last amended.
[^E0007]: Council Directive 92/6/EEC of 10 February 1992 on the installation and use of speed limitation devices for certain categories of motor vehicles in the Community (OJ L 57, 2.3.1992, p. 27).
[^E0008]: Council Directive 92/23/EEC of 31 March 1992 relating to tyres for motor vehicles and their trailers and to their fitting (OJ L 129, 14.5.1992, p. 95).
[^E0009]: Council Directive 76/114/EEC of 18 December 1975 on the approximation of the laws of the Member States relating to statutory plates and inscriptions for motor vehicles and their trailers, and their location and method of attachment (OJ L 24, 30.1.1976, p. 1).
[^E0012]: Commission Regulation (EC) No 68/2009 of 23 January 2009 adapting for the ninth time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (OJ L 21, 24.1.2009, p. 3).
[^E0013]: The card inserted will trigger the appropriate access rights to the downloading function and to the data. It shall, however, be possible to download data from a driver card inserted into one of the VU slots when no other card type is inserted in the other slot.
[^E0019]: Note that the generation-1, generation-2 and generation-3 pairing keys may actually be the same key, or may be three different keys having different lengths, as explained in CSM_117.
[^E0020]: Regulation (EU) No 1285/2013 of the European Parliament and of the Council of 11 December 2013 on the implementation and exploitation of European satellite navigation systems and repealing Council Regulation (EC) No 876/2002 and Regulation (EC) No 683/2008 of the European Parliament and of the Council (OJ L 347, 20.12.2013, p. 1).
[^E0025]: These figures are shown for guidance only.
[^E0026]: Delete items not applicable.
[^E0027]: Tick the relevant boxes.
[^E0028]: Specify the component dealt with in the notification.
[^E0029]: Tick the relevant boxes.
[^E0030]: Specify the component dealt with in the notification.
Reading this document does not replace reading the official text published in the Official Journal of the European Union. We assume no responsibility for any inaccuracies arising from the conversion of the original to this format.
This text is published under EUR-Lex's own terms of reuse, not a Legalize or public-domain licence.
EUR-Lex
Creative Commons Attribution 4.0 International (CC BY 4.0)
© European Union, https://eur-lex.europa.eu — Source: EUR-Lex (Publications Office of the European Union). Reused under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. Only EU legislation published in the printed Official Journal of the European Union is deemed authentic; consolidated texts are reproduced here for documentation purposes and have been reformatted to Markdown.