Legalize
Legalize / European Union / Implementing Regulation

Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)

Type Implementing Regulation
Publication 2018-03-28
State In force
Text As published
Department European Commission, MOVE
Source EUR-Lex
articles 2

This is the act as published. Later amendments are not folded into the text below: each one is a separate act in this repository and an entry in this law's history.

Reform history JSON API
‘1 ‘1 ‘1 Date and time at which the document is printed
2 2 2 Type of printout
3 3 3 Card holder identification (for all cards inserted in VU + GEN)
4 4 4 Vehicle identification (vehicle from which printout is taken)
5 5 5 VU identification (VU from which printout is taken + GEN)
6 6 6 Last calibration of this VU
7 7 7 Last control on this tachograph
9 9 9 Driver activities delimiter
10 10 10 Driver slot delimiter (slot 1)
10a 10a 10a Out of scope condition in the beginning of this day
10.1 / 10.2 / 10.3 / 10.3a / 10.4 10.1 / 10.2 / 10.3 / 10.3a / 10.4 10.1 / 10.2 / 10.3 / 10.3a / 10.4 Activities in chronological order (driver slot)
10 10 10 Co-driver slot delimiter (slot 2)
10a 10a 10a Out of scope condition in the beginning of this day
10.1 / 10.2 / 10.3 / 10.3a / 10.4 10.1 / 10.2 / 10.3 / 10.3a / 10.4 10.1 / 10.2 / 10.3 / 10.3a / 10.4 Activities in chronological order (co-driver slot)
11 11 11 Daily summary delimiter
11.1 11.1 11.1 Summary of periods without card in driver slot
11.4 11.4 11.4 Places entered in chronological order
11.5 11.5 11.5 Positions after 3 hours accumulated driving time in chronological order
11.7 11.7 11.7 Activity totals
11.2 11.2 11.2 Summary of periods without card in co-driver slot
11.4 11.4 11.4 Places entered in chronological order
11.5 11.5 11.5 Positions after 3 hours accumulated driving time in chronological order
11.8 11.8 11.8 Activity totals
11.3 11.3 11.3 Summary of activities for a driver both slots included
11.4 Places entered by this driver in chronological order
11.5 Positions after 3 hours accumulated driving time in chronological order
11.9 11.9 11.9 Activity totals for this driver
13.1 13.1 13.1 Events faults delimiter
13.4 13.4 13.4 Event/Fault records (Last 5 events or faults stored or on-going in the VU)
22.1 22.1 22.1 Control place
22.2 22.2 22.2 Controller’s signature
22.3 22.3 22.3 From time (space available for a driver without a card to indicate
22.4 22.4 22.4 To time which periods are relevant to himself)
22.5 22.5 22.5 Driver's signature’
  • ‘PRT_014 The historic of inserted cards printout shall be in accordance with the following format:
1 Date and time at which the document is printed
2 Type of printout
3 Card holder identifications (of all cards inserted in the VU)
23 Most recent card inserted in the VU
23.1 Inserted cards (up to 88 records)
12.3 Faults delimiter’
  • (33) Appendix 7 is amended as follows:
  • (a) point 1.1 is replaced by the following:

‘1.1.   Scope

Data may be downloaded to an ESM:

— from a Vehicle Unit by an Intelligent Dedicated Equipment (IDE) connected to the VU,

— from a tachograph card by an IDE fitted with a card interface device (IFD),

— from a tachograph card via a vehicle unit by an IDE connected to the VU.

To give the possibility to verify the authenticity and integrity of downloaded data stored on an ESM, data is downloaded with a signature appended in accordance with Appendix 11 Common Security Mechanisms. The source equipment (VU or card) identification and its security certificates (Member state and equipment) are also downloaded. The verifier of the data must possess independently a trusted European public key.

Data downloaded from a VU are signed using Appendix 11 Common Security Mechanisms Part B (Second-generation tachograph system), except when drivers' control is performed by a non EU control authority, using a first generation control card, in which case data are signed using Appendix 11 Common Security Mechanisms Part A (First-generation tachograph system), as requested by Appendix 15 Migration, requirement MIG_015.

This Appendix specifies therefore two types of data downloads from the VU:

— Generation 2 type of VU data download, providing the generation 2 data structure, signed using Appendix 11 Common Security Mechanisms Part B,

— Generation 1 type of VU data download, providing the generation 1 data structure, signed using Appendix 11 Common Security Mechanisms Part A.

Similarly, there are two types of data downloads from second generation driver cards inserted in a VU, as specified in paragraphs 3 and 4 of this Appendix.’;

‘Message Structure ‘Message Structure Max 4 Bytes Header Max 4 Bytes Header Max 4 Bytes Header Max 4 Bytes Header Max 255 Bytes Data Max 255 Bytes Data Max 255 Bytes Data 1 Byte CheckSum
IDE -> <- VU FMT TGT SRC LEN SID DS_ / TRTP DATA CS
Start Communication Request Start Communication Request 81 EE F0 81 E0
Positive Response Start Communication Positive Response Start Communication 80 F0 EE 03 C1 EA, 8F 9B
Start Diagnostic Session Request Start Diagnostic Session Request 80 EE F0 02 10 81 F1
Positive Response Start Diagnostic Positive Response Start Diagnostic 80 F0 EE 02 50 81 31
Link Control Service Link Control Service
Verify Baud Rate (stage 1) Verify Baud Rate (stage 1)
9 600 Bd 9 600 Bd 80 EE F0 04 87 01,01,01 EC
19 200 Bd 19 200 Bd 80 EE F0 04 87 01,01,02 ED
38 400 Bd 38 400 Bd 80 EE F0 04 87 01,01,03 EE
57 600 Bd 57 600 Bd 80 EE F0 04 87 01,01,04 EF
115 200 Bd 115 200 Bd 80 EE F0 04 87 01,01,05 F0
Positive Response Verify Baud Rate Positive Response Verify Baud Rate 80 F0 EE 02 C7 01 28
Transition Baud Rate (stage 2) Transition Baud Rate (stage 2) 80 EE F0 03 87 02,03 ED
Request Upload Request Upload 80 EE F0 0A 35 00,00,00, 00,00,FF,FF, FF,FF 99
Positive Response Request Upload Positive Response Request Upload 80 F0 EE 03 75 00,FF D5
Transfer Data Request Transfer Data Request
Overview Overview 80 EE F0 02 36 01 or 21 97
Activities Activities 80 EE F0 06 36 02 or 22 Date CS
Events & Faults Events & Faults 80 EE F0 02 36 03 or 23 Date 99
Detailed Speed Detailed Speed 80 EE F0 02 36 04 or 24 Date 9A
Technical Data Technical Data 80 EE F0 02 36 05 or 25 Date 9B
Card download Card download 80 EE F0 02 36 06 Slot CS
Positive Response Transfer Data Positive Response Transfer Data 80 F0 EE Len 76 TREP Data CS
Request Transfer Exit Request Transfer Exit 80 EE F0 01 37 96
Positive Response Request Transfer Exit Positive Response Request Transfer Exit 80 F0 EE 01 77 D6
Stop Communication Request Stop Communication Request 80 EE F0 01 82 E1
Positive Response Stop Communication Positive Response Stop Communication 80 F0 EE 01 C2 21
Acknowledge sub message Acknowledge sub message 80 EE F0 Len 83 Data CS
Negative responses Negative responses
General reject General reject 80 F0 EE 03 7F Sid Req 10 CS
Service not supported Service not supported 80 F0 EE 03 7F Sid Req 11 CS
Sub function not supported Sub function not supported 80 F0 EE 03 7F Sid Req 12 CS
Incorrect Message Length Incorrect Message Length 80 F0 EE 03 7F Sid Req 13 CS
Conditions not correct or Request sequence error Conditions not correct or Request sequence error 80 F0 EE 03 7F Sid Req 22 CS
Request out of range Request out of range 80 F0 EE 03 7F Sid Req 31 CS
Upload not accepted Upload not accepted 80 F0 EE 03 7F Sid Req 50 CS
Response pending Response pending 80 F0 EE 03 7F Sid Req 78 CS
Data not available Data not available 80 F0 EE 03 7F Sid Req FA CS’
  • ‘— TRTP 21 to 25 are used for Generation 2 type of VU data download requests, TRTP 01 to 05 are used for Generation 1 type of VU data download requests, which can only be accepted by the VU in the frame of drivers' control performed by a non EU control authority, using a first generation control card,

— TRTP 11 to 19 and 31 to 39 are reserved for manufacturer specific download requests.’;

  • ‘DDP_011 The Transfer Data Request is sent by the IDE to specify to the VU the type of data that are to be downloaded. A one byte Transfer Request Parameter (TRTP) indicates the type of transfer.

There are six types of data transfer. For VU data download, two different TRTP values can be used for each transfer type:

Data transfer type TRTP value for generation 1 type of VU data download TRTP value for generation 2 type of VU data download
Overview 01 21
Activities of a specified date 02 22
Events and faults 03 23
Detailed speed 04 24
Technical data 05 25
Data transfer type TRTP value
Card download 06’
  • (ii) paragraph DDP_054 is replaced by the following:
  • ‘DDP_054 It is mandatory for the IDE to request the overview data transfer (TRTP 01 or 21) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature).

In the second case (TRTP 02 or 22) the Transfer Data Request message includes the indication of the calendar day ( Image omitted; see official source format) to be downloaded.’;

  • ‘DDP_055 In the first case (TREP 01 or 21), the VU will send data helping the IDE operator to choose the data he wants to download further. The information contained within this message is:
  • — Security certificates,
  • — Vehicle identification,
  • — VU current date and time,
  • — Min and Max downloadable date (VU data),
  • — Indication of cards presence in the VU,
  • — Previous download to a company,
  • — Company locks,
  • — Previous controls.’;
  • ‘— FA data not available

The data object of a data transfer request are not available in the VU (e.g. no card is inserted, generation 1 type of VU data download requested outside the frame of a driver’s control by a non EU control authority…).’;

‘The data field of the “Positive Response Transfer Data Overview” message shall provide the following data in the following order under the SID 76 Hex, the TREP 01 or 21 Hex and appropriate sub message splitting and counting:’;

‘Data structure generation 1 (TREP 01 Hex)’;

‘Data structure generation 2 (TREP 21 Hex)’;

‘The data field of the “Positive Response Transfer Data Activities” message shall provide the following data in the following order under the SID 76 Hex, the TREP 02 or 22 Hex and appropriate sub message splitting and counting:’;

‘Data structure generation 1 (TREP 02 Hex)’;

‘Data structure generation 2 (TREP 22 Hex)’;
‘Image omitted; see official source GNSS positions of the vehicle when the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent.’

‘The data field of the “Positive Response Transfer Data Events and Faults” message shall provide the following data in the following order under the SID 76 Hex, the TREP 03 or 23 Hex and appropriate sub message splitting and counting:’;

‘Data structure generation 1 (TREP 03 Hex)’;

‘Data structure generation 2 (TREP 23 Hex)’;

‘The data field of the “Positive Response Transfer Data Detailed Speed” message shall provide the following data in the following order under the SID 76 Hex, the TREP 04 or 24 Hex and appropriate sub message splitting and counting:’;

‘Data structure generation 1 (TREP 04)’;

‘Data structure generation 2 (TREP 24)’;

‘The data field of the “Positive Response Transfer Data Technical Data” message shall provide the following data in the following order under the SID 76 Hex, the TREP 05 or 25 Hex and appropriate sub message splitting and counting:’;

‘Data structure generation 1 (TREP 05)’;

‘Data structure generation 2 (TREP 25)’;

  • ‘DDP_035 The download of a tachograph card includes the following steps:

It is mandatory to download these files for each download session.

  • — When downloading a driver card it is also mandatory to download the following EFs:

Text of image

Events_Data,

Faults_Data,

Text of image

Driver_Activity_Data,

Vehicles_Used,

Places,

Control_Activity_Data,

Specific_Conditions,

  • — (for second generation tacograph cards only) Except when a download of a driver card inserted in a VU is performed during drivers' control by a non EU control authority, using a first generation control card, download EFs within Image omitted; see official source :
  • — Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate (if present). This information is not secured with a digital signature.

It is mandatory to download these files for each download session.

  • — When downloading a driver card it is also mandatory to download the following EFs:

Text of image

Events_Data,

Faults_Data,

Driver_Activity_Data,

Vehicles_Used,

Places,

Control_Activity_Data,

Specific_Conditions,

VehicleUnits_Used,

GNSS Places.

‘The sequence to download EFs ICC, IC, Card_Certificate (or CardSignCertificate for DF Tachograph_G2), CA_Certificate and Link_Certificate (for DF Tachograph_G2 only) is as follows:’;

‘Card Dir IDE / IFD Meaning / Remarks
Image omitted; see official source Select File
OK Image omitted; see official source
Image omitted; see official source Perform Hash of File — Calculates the hash value over the data content of the selected file using the prescribed hash algorithm in accordance with Appendix 11, part A or B. This command is not an ISO-Command.
Calculate Hash of File and store Hash value temporarily
OK Image omitted; see official source
Image omitted; see official source Read Binary If the file contains more data than the buffer of the reader or the card can hold, the command has to be repeated until the complete file is read.
File Data OK Image omitted; see official source Store received data to ESM according to 3.4 Data storage format
Image omitted; see official source PSO: Compute Digital Signature
Perform Security Operation “Compute Digital Signature” using the temporarily stored Hash value
Signature OK Image omitted; see official source Append data to the previous stored data on the ESM according to 3.4 Data storage format’
  • ‘DDP_046 A signature shall be stored as the next TLV object directly after the TLV object that contains the data of the file.
Definition Meaning Length
FID (2 Bytes) || “00” Tag for EF (FID) in the Image omitted; see official source or for common information of the card 3 Bytes
FID (2 Bytes) || “01” Tag for Signature of EF (FID) in the Image omitted; see official source DF 3 Bytes
FID (2 Bytes) || “02” Tag for EF (FID) in the Image omitted; see official source DF 3 Bytes
FID (2 Bytes) || “03” Tag for Signature of EF (FID) in the Image omitted; see official source DF 3 Bytes
xx xx Length of Value field 2 Bytes

Example of data in a download file on an ESM:

Tag Length Value
Image omitted; see official source Image omitted; see official source — Data of EF ICC
Image omitted; see official source Image omitted; see official source — Data of EF Card_Certificate
— …
Image omitted; see official source Image omitted; see official source Data of EF Image omitted; see official source (in the Image omitted; see official source DF)
Image omitted; see official source Image omitted; see official source Signature of EF Image omitted; see official source (in the Image omitted; see official source DF)
Image omitted; see official source Image omitted; see official source Data of EF Image omitted; see official source in the Image omitted; see official source DF
Image omitted; see official source Image omitted; see official source Signature of EF Image omitted; see official source in the Image omitted; see official source DF’
  • (o) in point 4, paragraph DDP_049 is replaced by the following:
  • ‘DDP_049 First generation driver cards: Data shall be downloaded using the first generation data download protocol, and downloaded data shall have the same format as data downloaded from a first generation vehicle unit.

Second generation driver cards: the VU shall then download the whole card, file by file, in accordance with the card downloading protocol defined in paragraph 3, and forward all data received from the card to the IDE within the appropriate TLV file format (see 3.4.2) and encapsulated within a “Positive Response Transfer Data” message.’;

‘ISO 14230-2: Road Vehicles -Diagnostic Systems — Keyword Protocol 2000- Part 2: Data Link Layer.

First edition: 1999.’;

  • ‘6. EXTERNAL REMOTE COMMUNICATION FACILITY TESTS’;
  • ‘— a security certification, based on Common Criteria specifications, against a security target fully compliant with Appendix 10 to this Annex,’;
‘No Test Description Related requirements
1 Administrative examination Administrative examination Administrative examination
1.1 Documentation Correctness of documentation
1.2 Manufacturer test results Results of manufacturer test performed during integration. Paper demonstrations. 88, 89,91
2 Visual inspection Visual inspection Visual inspection
2,1 Compliance with documentation Compliance with documentation
2.2 Identification / markings Identification / markings 224 to 226
2.3 Materials Materials 219 to 223
2.4 Sealing Sealing 398, 401 to 405
2.5 External interfaces External interfaces
3 Functional tests Functional tests Functional tests
3.1 Functions provided Functions provided 02, 03, 04, 05, 07, 382
3.2 Modes of operation Modes of operation 09 to 11*, 134, 135
3.3 Functions and data access rights Functions and data access rights 12 13, 382, 383, 386 to 389
3.4 Monitoring cards insertion and withdrawal Monitoring cards insertion and withdrawal 15, 16, 17, 18, 19, 20, 134
3.5 Speed and distance measurement Speed and distance measurement 21 to 31
3.6 Time measurement (test performed at 20 °C) Time measurement (test performed at 20 °C) 38 to 43
3.7 Monitoring driver activities Monitoring driver activities 44 to 53, 134
3.8 Monitoring driving status Monitoring driving status 54, 55, 134
3.9 Manual entries Manual entries 56 to 62
3.10 Company locks management Company locks management 63 to 68
3.11 Monitoring control activities Monitoring control activities 69, 70
3.12 Detection of events and/or faults Detection of events and/or faults 71 to 88, 134
3.13 Equipment identification data Equipment identification data 93, 94, 97, 100
3.14 Driver card insertion and withdrawal data Driver card insertion and withdrawal data 102 to 104
3.15 Driver activity data Driver activity data 105 to 107
3.16 Places and positions data Places and positions data 108 to 112
3.17 Odometer data Odometer data 113 to 115
3.18 Detailed speed data Detailed speed data 116*
3.19 Events data Events data 117*
3.20 Faults data Faults data 118*
3.21 Calibration data Calibration data 119 to 121
3.22 Time adjustment data Time adjustment data 124, 125
3.23 Control activity data Control activity data 126, 127
3.24 Company locks data Company locks data 128*
3.25 Download activity data Download activity data 129*
3.26 Specific conditions data Specific conditions data 130, 131
3.27 Recording and storing on tachographs cards Recording and storing on tachographs cards 136, 137, 138, 139, 141, 142, 143 144, 145, 146, 147, 148, 149, 150
3.28 Displaying Displaying 90, 134, 151 to 168, PIC_001, DIS_001
3.29 Printing Printing 90, 134, 169 to 181, PIC_001, PRT_001 to PRT_014
3.30 Warning Warning 134, 182 to 191, PIC_001
3.31 Data downloading to external media Data downloading to external media 90, 134, 192 to 196
3.32 Remote communication for targeted roadside checks Remote communication for targeted roadside checks 197 to 199
3.33 Output data to additional external devices Output data to additional external devices 200, 201
3.34 Calibration Calibration 202 to 206*, 383, 384, 386 to 391
3.35 Roadside calibration checking Roadside calibration checking 207 to 209
3.36 Time adjustment Time adjustment 210 to 212*
3.37 Non-interference of additional functions Non-interference of additional functions 06, 425
3.38 Motion sensor interface Motion sensor interface 02, 122
3.39 External GNSS facility External GNSS facility 03, 123
3.40 Verify that the VU detects, records and stores the event(s) and/or fault(s) defined by the VU manufacturer when a paired motion sensor reacts to magnetic fields disturbing vehicle motion detection. Verify that the VU detects, records and stores the event(s) and/or fault(s) defined by the VU manufacturer when a paired motion sensor reacts to magnetic fields disturbing vehicle motion detection. 217
3.41 Cypher suite and standardized domain parameters Cypher suite and standardized domain parameters CSM_48, CSM_50
4 Environmental tests Environmental tests Environmental tests
4.1 Temperature Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h at 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 2h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles 213
4.2 Humidity Verify that the vehicle unit can withstand a cyclic damp (heat test) through IEC 60068-2-30, test Db, six 24 hours cycles, each temperature varying from +25 °C to + 55 °C and a relative humidity of 97 % at + 25 °C and equal to 93 % at +55 °C 214
4.3 Mechanical 1. Sinusoidal vibrations. verify that the vehicle unit can withstand sinusoidal vibrations with the following characteristics: constant displacement between 5 and 11 Hz: 10mm peak constant acceleration between 11 and 300 Hz: 5g This requirement is verified through IEC 60068-2-6, test Fc, with a minimum test duration of 3 × 12 hours (12 hours per axis) ISO 16750-3 does not require a sinusoidal vibration test for devices located in the decoupled vehicle cab. 2. Random vibrations: Test according to ISO 16750-3: Chapter 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab Random vibration test, 10…2000 Hz, RMS vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 axes, 32 h per axis, including temperature cycle – 20…70 °C. This test refers to IEC 60068-2-64: Environmental testing - Part 2-64: Tests - Test Fh: Vibration, broadband random and guidance 3. Shocks: mechanical shock with 3 g half sinus according ISO 16750. The tests described above are performed on different samples of the equipment type being tested. 219
4.4 Protection against water and foreign bodies Test according to ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (No change in parameters); Minimum value IP 40 220, 221
4.5 Over-voltage protection Verify that the vehicle unit can withstand a power supply of: 24 V versions : 34V at + 40 °C 1 hour 12V versions : 17V at + 40 °C 1 hour (ISO 16750-2) 216
4.6 Reverse polarity protection Verify that the vehicle unit can withstand an inversion of its power supply (ISO 16750-2) 216
4.7 Short-circuit protection Verify that input output signals are protected against short circuits to power supply and ground (ISO 16750-2) 216
5 EMC tests EMC tests EMC tests
5.1 Radiated emissions and susceptibility Compliance with Regulation ECE R10 218
5.2 Electrostatic discharge Compliance with ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014: +/– 4 kV for contact and +/– 8 kV for air discharge 218
5.3 Conducted transient susceptibility on power supply For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs=450V Ri=50 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+20V Ri=0,05 ohms pulse 3a: Vs=– 150V Ri=50 ohms pulse 3b: Vs=+150V Ri=50 ohms pulse 4: Vs=– 16V Va=– 12V t6=100ms pulse 5: Vs=+120V Ri=2,2 ohms td=250ms For 12V versions: compliance with ISO 7637– 1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs=– 75V Ri=10 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+10V Ri=0,05 ohms pulse 3a: Vs=– 112V Ri=50 ohms pulse 3b: Vs=+75V Ri=50 ohms pulse 4: Vs=– 6V Va=– 5V t6=15ms pulse 5: Vs=+65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4. 218’

‘6.   EXTERNAL REMOTE COMMUNICATION FACILITY TEST

No Test Test Description Related requirements
1. Administrative examination Administrative examination Administrative examination Administrative examination
1.1 Documentation Documentation Correctness of documentation
2. Visual inspection Visual inspection Visual inspection Visual inspection
2.1. Compliance with documentation Compliance with documentation Compliance with documentation
2.2. Identification / markings Identification / markings Identification / markings 225, 226
2.3 Materials Materials Materials 219 to 223
3. Functional tests Functional tests Functional tests Functional tests
3.1 Remote communication for targeted roadside checks Remote communication for targeted roadside checks Remote communication for targeted roadside checks 4, 197 to 199
3.2 Recording and storing in data memory Recording and storing in data memory Recording and storing in data memory 91
3.3 Communication with Vehicle Unit Communication with Vehicle Unit Communication with Vehicle Unit Appendix 14 DSC_66 to DSC_70, DSC_71 to DSC_76
4. Environmental tests Environmental tests Environmental tests Environmental tests
4.1 Temperature Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles Verify functionality through: Test according to ISO 16750-4, Chapter 5.1.1.2: Low temperature operation test (72 h @ – 20 °C) This test refers to IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold Test according to ISO 16750-4: Chapter 5.1.2.2: High temperature operation test (72 h @ 70 °C) This test refers to IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat Test according to ISO 16750-4: Chapter 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cycles, dwell time 1 h at each temperature) A reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles 213
4.2 Protection against water and foreign bodies Test according to ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (targeted value IP40) Test according to ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (targeted value IP40) 220, 221
5 EMC tests EMC tests EMC tests EMC tests
5.1 Radiated emissions and susceptibility Compliance with Regulation ECE R10 Compliance with Regulation ECE R10 218
5.2 Electrostatic discharge Compliance with ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014: +/– 4 kV for contact and +/– 8 kV for air discharge Compliance with ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014: +/– 4 kV for contact and +/– 8 kV for air discharge 218
5.3 Conducted transient susceptibility on power supply For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs=– 450V Ri=50 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+20V Ri=0,05 ohms pulse 3a: Vs=– 150V Ri=50 ohms pulse 3b: Vs=+150V Ri=50 ohms pulse 4: Vs=– 16V Va=-12V t6=100ms pulse 5: Vs=+120V Ri=2,2 ohms td=250ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs=-75V Ri=10 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+10V Ri=0,05 ohms pulse 3a: Vs=– 112V Ri=50 ohms pulse 3b: Vs=+75V Ri=50 ohms pulse 4: Vs=– 6V Va=– 5V t6=15ms pulse 5: Vs=+65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4. For 24V versions: compliance with ISO 7637-2 + ECE Regulation No. 10 Rev. 3: pulse 1a: Vs=– 450V Ri=50 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+20V Ri=0,05 ohms pulse 3a: Vs=– 150V Ri=50 ohms pulse 3b: Vs=+150V Ri=50 ohms pulse 4: Vs=– 16V Va=-12V t6=100ms pulse 5: Vs=+120V Ri=2,2 ohms td=250ms For 12V versions: compliance with ISO 7637-1 + ECE Regulation No. 10 Rev. 3: pulse 1: Vs=-75V Ri=10 ohms pulse 2a: Vs=+37V Ri=2 ohms pulse 2b: Vs=+10V Ri=0,05 ohms pulse 3a: Vs=– 112V Ri=50 ohms pulse 3b: Vs=+75V Ri=50 ohms pulse 4: Vs=– 6V Va=– 5V t6=15ms pulse 5: Vs=+65V Ri=3ohms td=100ms Pulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented For load dump proposal, refer to ISO 16750-2, 4th edition, chapter 4.6.4. 218’
  • (e) the table in point 8 on interoperability tests is replaced by the following:
‘No Test Description
8.1   Interoperability tests between vehicle units and tachograph cards 8.1   Interoperability tests between vehicle units and tachograph cards 8.1   Interoperability tests between vehicle units and tachograph cards
1 Mutual authentication Check that the mutual authentication between the vehicle unit and the tachograph card runs normally
2 Write/read tests Execute a typical activity scenario on the vehicle unit. The scenario shall be adapted to the type of card being tested and involve writings in as many EFs as possible in the card Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through daily printouts that all corresponding recordings can be properly read
8.2   Interoperability tests between vehicle units and motion sensors 8.2   Interoperability tests between vehicle units and motion sensors 8.2   Interoperability tests between vehicle units and motion sensors
1 Pairing Check that the pairing between the vehicle units and the motion sensors runs normally
2 Activity tests Execute a typical activity scenario on the motion sensor. The scenario shall involve a normal activity and creating as many events or faults as possible. Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through a daily printout that all corresponding recordings can be properly read
8.3   Interoperability tests between vehicle units and external GNSS facilities (when applicable) 8.3   Interoperability tests between vehicle units and external GNSS facilities (when applicable) 8.3   Interoperability tests between vehicle units and external GNSS facilities (when applicable)
1 Mutual authentication Check that the mutual authentication (coupling) between the vehicle unit and the external GNSS module runs normally.
2 Activity tests Execute a typical activity scenario on the external GNSS facility. The scenario shall involve a normal activity and creating as many events or faults as possible. Verify through a vehicle unit downloading that all corresponding recordings have been properly made Verify through a card downloading that all corresponding recordings have been properly made Verify through a daily printout that all corresponding recordings can be properly read’
  • (36) Appendix 11 is amended as follows:
  • (a) in point 8.2.3, paragraph CSM_49 is replaced by the following:
  • ‘CSM_49 Vehicle units, tachograph cards and external GNSS facilities shall support the SHA-256, SHA-384 and SHA-512 algorithms specified in [SHS].’;
  • ‘CSM_58 Whenever it generates a new European root key pair, the ERCA shall create a link certificate for the new European public key and sign it with the previous European private key. The validity period of the link certificate shall be 17 years plus 3 months. This is shown in Figure 1 in section 9.1.7 as well.’;
  • ‘CSM_72 Two unique ECC key pairs shall be generated for each vehicle unit, designated as VU_MA and VU_Sign. This task is handled by VU manufacturers. Whenever a VU key pair is generated, the party generating the key shall send the public key to its MSCA, in order to obtain a corresponding VU certificate signed by the MSCA. The private key shall be used only by the vehicle unit.’;
  • ‘CSM_83 One unique ECC key pair, designated as Card_MA, shall be generated for each tachograph card. A second unique ECC key pair, designated as Card_Sign, shall additionally be generated for each driver card and each workshop card. This task may be handled by card manufacturers or card personalisers. Whenever a card key pair is generated, the party generating the key shall send the public key to its MSCA, in order to obtain a corresponding card certificate signed by the MSCA. The private key shall be used only by the tachograph card.’;
  • ‘CSM_88 The validity period of a Card_MA certificate shall be as follows:
  • — For driver cards: 5 years
  • — For company cards: 5 years
  • — For control cards: 2 years
  • — For workshop cards: 1 year’;
  • ‘— Additionally, for control cards, company cards and workshop cards only, and only if such cards are issued during the first three months of the validity period of a new EUR certificate: the EUR certificate that is two generations older, if existing.

Note to last bullet: For example, in the first three months of the ERCA(3) certificate (see Figure 1), the mentioned cards shall contain the ERCA(1) certificate. This is needed to ensure that these cards can be used to perform data downloads from ERCA(1) VUs whose normal 15-year life period plus the 3-months data downloading period expires during these months; see the last bullet of requirement 13) in Annex IC.’;

  • ‘CSM_93 One unique ECC key pair shall be generated for each external GNSS facility, designated as EGF_MA. This task is handled by external GNSS facility manufacturers. Whenever an EGF_MA key pair is generated, the party generating th e key shall send the public key to its MSCA in order to obtain a corresponding EGF_MA certificate signed by the MSCA. The private key shall be used only by the external GNSS facility.’;
  • ‘CSM_95 An external GNSS facility shall use its EGF_MA key pair, consisting of private key EGF_MA.SK and public key EGF_MA.PK, exclusively to perform mutual authentication and session key agreement towards vehicle units, as specified in section 11.4 of this Appendix.’;

‘ Figure 1

Issuance and usage of different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment certificates

Text of image

Legend

Private key usage period / Remaining certificate validity

Second generation ERCA certificate and certificates based on it

Third generation ERCA certificate and certificates based on it

First generation ERCA certificate and certificates based on it

Year

Year

Year

’

  • ‘6. To save space, the difference in validity period between the Card_MA and Card_Sign certificates is shown only for the first generation.’;
  • ‘— For 128-bit motion sensor master keys: CV = “B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83” ’;

‘Each Motion sensor manufacturer shall generate a random and unique pairing key KP for every motion sensor, and shall send each pairing key to its Member State Certificate Authority. The MSCA shall encrypt each pairing key separately with the motion sensor master key KM and shall return the encrypted key to the motion sensor manufacturer. For each encrypted key, the MSCA shall notify the motion sensor manufacturer of the version number of the associated KM.’;

  • ‘CSM_108 Each motion sensor manufacturer shall generate a unique serial number for every motion sensor, and shall send all serial numbers to its Member State Certificate Authority. The MSCA shall encrypt each serial number separately with the identification key KID and shall return the encrypted serial number to the motion sensor manufacturer. For each encrypted serial number, the MSCA shall notify the motion sensor manufacturer of the version number of the associated KID.’;
  • ‘CSM_123 For every vehicle unit, the vehicle unit manufacturer shall create a unique VU serial number and shall send this number to its Member State Certificate Authority in a request to obtain a set of two VU-specific DSRC keys. The VU serial number shall have data type Image omitted; see official source .

Note:

  • — This VU serial number shall be identical to the vuSerialNumber element of VuIdentification, see Appendix 1 and to the Certificate Holder Reference in the VU’s certificates.
  • — The VU serial number may not be known at the moment a vehicle unit manufacturer requests the VU-specific DSRC keys. In this case, the VU manufacturer shall send instead the unique certificate request ID it used when requesting the VU’s certificates; see CSM_153. This certificate request ID shall therefore be equal to the Certificate Holder Reference in the VU’s certificates.’;

‘info = VU serial number or certificate request ID, as specified in CSM_123’;

  • ‘CSM_128 The MSCA shall keep records of all VU-specific DSRC keys it generated, their version number and the VU serial number or certificate request ID used in deriving them.’;

‘The Distinguished Encoding Rules (DER) according to [ISO 8825-1] shall be used to encode the data objects within certificates. Table 4 shows the full certificate encoding, including all tag and length bytes.’;

  • ‘CSM_141 The Certificate Holder Authorisation shall be used to identify the type of certificate. It consists of the six most significant bytes of the Tachograph Application ID, concatenated with the equipment type, which indicates the type of equipment for which the certificate is intended. In the case of a VU certificate, a driver card certificate or a workshop card certificate, the equipment type is also used to differentiate between a certificate for Mutual Authentication and a certificate for creating digital signatures (see section 9.1 and Appendix 1, data type EquipmentType).’;

‘ Note: For a card certificate, the value of the CHR shall be equal to the value of the cardExtendedSerialNumber in EF_ICC; see Appendix 2. For an EGF certificate, the value of the CHR shall be equal to the value of the sensorGNSSSerialNumber in EF_ICC; see Appendix 14. For a VU certificate, the value of the CHR shall be equal to the vuSerialNumber element of VuIdentification, see Appendix 1, unless the manufacturer does not know the manufacturer-specific serial number at the time the certificate is requested.’;

  • ‘CSM_148 The Certificate Effective Date shall indicate the starting date and time of the validity period of the certificate.’;

‘When requesting a certificate, an MSCA shall send the following data to the ERCA:’;

  • ‘CSM_153 An equipment manufacturer shall send the following data in a certificate request to an MSCA, allowing the MSCA to create the Certificate Holder Reference of the new equipment certificate:
  • — If known (see CSM_154), a serial number for the equipment, unique for the manufacturer, the equipment's type and the month of manufacturing. Otherwise, a unique certificate request identifier.
  • — The month and the year of equipment manufacturing or of the certificate request.

The manufacturer shall ensure that this data is correct and that the certificate returned by the MSCA is inserted in the intended equipment.’;

‘Vehicle units shall use the protocol depicted in Figure 4 for verifying a tachograph card’s certificate chain. For every certificate it reads from the card, the VU shall verify that the Certificate Holder Authorisation (CHA) field is correct:

— The CHA field of the Card certificate shall indicate a card certificate for mutual authentication (see Appendix 1, data type EquipmentType).

— The CHA of the Card.CA certificate shall indicate an MSCA.

— The CHA of the Card.Link certificate shall indicate the ERCA.’;

‘Whereas storing of all other types of certificate is optional, it is mandatory for a VU to store a new link certificate presented by a card.’;

‘Tachograph cards shall use the protocol depicted in Figure 5 for verifying a VU's certificate chain. For every certificate presented by the VU, the card shall verify that the Certificate Holder Authorisation (CHA) field is correct:

— The CHA of the VU.Link certificate shall indicate the ERCA.

— The CHA of the VU.CA certificate shall indicate an MSCA.

— The CHA field of the VU certificate shall indicate a VU certificate for mutual authentication (see Appendix 1, data type EquipmentType).’;

  • ‘CSM_165 If the MSE: Set AT command is successful, the card shall set the indicated VU.PK for subsequent use during Vehicle Authentication, and shall temporarily store Comp(VU.PKeph). In case two or more successful MSE: Set AT commands are sent before session key agreement is performed, the card shall store only the last Comp(VU.PKeph) received. The card shall reset Comp(VU.PKeph) after a successful GENERAL AUTHENTICATE command.’;

‘Next to the card challenge, the VU shall include in the signature the certificate holder reference taken from the card certificate.’;

‘ Figure 6

VU Authentication protocol

Image omitted; see official source ’

  • ‘CSM_174 Upon receiving the VU’s signature in an EXTERNAL AUTHENTICATE command, the card shall
  • — Calculate the authentication token by concatenating Card.CHR, the card challenge rcard and the identifier of the VU ephemeral public key Comp(VU.PKeph),
  • — Verify the VU’s signature using the ECDSA algorithm, using the hashing algorithm linked to the key size of the VU’s VU_MA key pair as specified in CSM_50, in combination with VU.PK and the calculated authentication token.’;
  • ‘2. The VU sends the public point VU.PKeph of its ephemeral key pair to the card. The public point shall be converted to an octet string as specified in [TR-03111]. The uncompressed encoding format shall be used. As explained in CSM_164, the VU generated this ephemeral key pair prior to the verification of the VU certificate chain. The VU sent the identifier of the ephemeral public key Comp(VU.PKeph) to the card, and the card stored it.’;
  • ‘6. Using KMAC, the card computes an authentication token over the VU ephemeral public point: TPICC = CMAC(KMAC, VU.PKeph). The public point shall be in the format used by the VU (see bullet 2 above). The card sends NPICC and TPICC to the vehicle unit.’;
  • ‘CSM_191 Any data object to be encrypted shall be padded according to [ISO 7816-4] using padding-content indicator ‘01’. For the calculation of the MAC, data objects in the APDU shall be padded according to [ISO 7816-4].

Note: Padding for Secure Messaging is always performed by the secure messaging layer, not by the CMAC or CBC algorithms.

Summary and Examples

A command APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured command (DO is data object):
Case 1 : CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
Case 2 : CLA INS P1 P2 || Lc' || DO ‘97’ || DO‘8E’ || Le
Case 3 (even INS byte) : CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘8E’ || Le
Case 3 (odd INS byte) : CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘8E’ || Le
Case 4 (even INS byte) : CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘97’ || DO‘8E’ || Le
Case 4 (odd INS byte) : CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘97’ || DO‘8E’ || Le

where Le = ‘00’ or ‘00 00’ depending on whether short length fields or extended length fields are used; see [ISO 7816-4].

A response APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured response:
Case 1 or 3 : DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (even INS byte) without encryption : DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (even INS byte) with encryption : DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (odd INS byte) without encryption : DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2

Note: Case 2 or 4 (odd INS byte) with encryption is never used in the communication between a VU and a card.

Below are three example APDU transformations for commands with even INS code. Figure 8 shows an authenticated Case 4 command APDU, Figure 9 shows an authenticated Case 1/Case 3 response APDU, and Figure 10 shows an encrypted and authenticated Case 2/Case 4 response APDU.

Figure 8

Transformation of an authenticated Case 4 Command APDU

Image omitted; see official source

Figure 9

Transformation of an authenticated Case 1 / Case 3 Response APDU

Image omitted; see official source

Figure 10

Transformation of an encrypted and authenticated Case 2/Case 4 Response APDU

Image omitted; see official source ’

  • ‘CSM_193 A tachograph card shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:
  • — it receives a plain command APDU,
  • — it detects a Secure Messaging error in a command APDU:
  • — An expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included.
  • — A Secure Messaging data object is incorrect, e.g. the MAC value is incorrect or the TLV structure is incorrect.
  • — it is depowered or reset,
  • — the VU starts the VU Authentication process,
  • — the limit for the number of commands and associated responses within the current session is reached. For a given card, this limit shall be defined by its manufacturer, taking into account the security requirements of the hardware used, with a maximum value of 240 SM commands and associated responses per session’;

‘During the coupling to a VU, an external GNSS facility shall use the protocol depicted in Figure 5 (section 10.2.2) for verifying the VU's certificate chain’;

  • ‘CSM_210 Once it has verified the VU_MA certificate, the external GNSS facility shall store this certificate for use during normal operation; see section 11.3.3.’;

‘During normal operation, a vehicle unit and an EGF shall use the protocol depicted in Figure 11 for verifying the temporal validity of the stored EGF_MA certificate and for setting the VU_MA public key for subsequent VU Authentication. No further mutual verification of the certificate chains shall take place during normal operation.’;

‘Table 6

Number of plaintext and encrypted data bytes per instruction defined in [ISO 16844-3]

Instruction Request / reply Description of data # of plaintext data bytes according to [ISO 16844-3] # of plaintext data bytes using AES keys # of encrypted data bytes when using AES keys of bitlength # of encrypted data bytes when using AES keys of bitlength # of encrypted data bytes when using AES keys of bitlength
Instruction Request / reply Description of data # of plaintext data bytes according to [ISO 16844-3] # of plaintext data bytes using AES keys 128 192 256
10 request Authentication data + file number 8 8 16 16 16
11 reply Authentication data + file contents 16 or 32, depend on file 16 or32, depend on file 32 / 48 32 / 48 32 / 48
41 request MoS serial number 8 8 16 16 16
41 reply Pairing key 16 16 / 24 / 32 16 32 32
42 request Session key 16 16 / 24 / 32 16 32 32
43 request Pairing information 24 24 32 32 32
50 reply Pairing information 24 24 32 32 32
70 request Authentication data 8 8 16 16 16
80 reply MoS counter value + auth. data 8 8 16 16 16’
  • (w) in point 13.1, the requirement on the VU serial number in subparagraph CSM_224 is replaced by the following:
‘VU serial number the VU’s serial number or certificate request ID (data type VuSerialNumber or CertificateRequestID) – see CSM_123’;
  • (x) in point 13.3, the second indent in paragraph CSM_228 is replaced by the following:
  • ‘2. The control card shall use the indicated DSRC master key in combination with the VU serial number or the certificate request ID in the DSRC security data to derive the VU-specific DSRC keys K_VUDSRC_ENC and K_VUDSRC_MAC, as specified in CSM_124.’;

‘An IDE may perform verification of a signature over downloaded data itself or it may use a control card for this purpose. In case it uses a control card, signature verification shall take place as shown in Figure 13. For verifying the temporal validity of a certificate presented by the IDE, the control card shall use its internal current time, as specified in CSM_167. The control card shall update its current time if the Effective Date of an authentic ‘valid source of time’ certificate is more recent than the card’s current time. The card shall accept only the following certificates as a valid source of time:

In case it performs signature verification itself, the IDE shall verify the authenticity and validity of all certificates in the certificate chain in the data file, and it shall verify the signature over the data following the signature scheme defined in [DSS]. In both cases, for every certificate read from the data file, it is necessary to verify that the Certificate Holder Authorisation (CHA) field is correct:

‘ Figure 13

Protocol for verification of the signature over a downloaded data file

Image omitted; see official source ’

‘The resolution of the position is based on the format of the RMC sentence described above. The first part of the fields 3) and 5) are used to represent the degrees. The rest are used to represent the minutes with three decimals. So the resolution is 1/1000 of minute or 1/60000 of degree (because one minute is 1/60 of a degree).’;

  • ‘GNS_5 The Vehicle Unit shall store in the VU database the position information for latitude and longitude with a resolution of 1/10 of minute or 1/600 of a degree as described in Appendix 1 for type GeoCoordinates.

The GPS DOP and active satellites (GSA) command can be used by the VU to determine and record the signal availability and accuracy. In particular the HDOP is used to provide an indication on the level of accuracy of the recorded location data (see 4.2.2). The VU will store the value of the Horizontal Dilution of Precision (HDOP) calculated as the minimum of the HDOP values collected on the available GNSS systems.

The GNSS Id. indicates the corresponding NMEA Id. for every GNSS constellation and Satellite-Based Augmentation System (SBAS).

Figure 3

Structure of the GSA sentence

Image omitted; see official source ’

  • ‘GNS_6 The GSA sentence shall be stored with record number ‘02’ to ‘06’’;
  • ‘GNS_16 In the communication protocol, extended length fields shall not be supported.’;
  • ‘GNS_18 Regarding the functions 1) the collection and distribution of GNSS data and 2) the collection of the configuration data of the external GNSS facility and 3) management protocol, the GNSS Secure Transceiver shall simulate a smart card with a file system architecture composed by a Master File (MF), a Dedicated File (DF) with Application Identifier specified in Appendix 1 chapter 6.2 (‘FF 44 54 45 47 4D’) and with 3 EFs containing certificates and one single Elementary File (EF.EGF) with file identifier equal to ‘2F2F’ as described in Table 1.’;
  • ‘GNS_20 The GNSS Secure Transceiver shall use a memory to store the data and be able to perform at least 20 millions write/read cycles. Apart from this aspect, the internal design and implementation of the GNSS Secure Transceiver is left to the manufacturers.

The mapping of record numbers and data is provided in Table 1. Note that there are five GSA sentences for the GNSS constellations and Satellite-Based Augmentation System (SBAS).’;

  • ‘5. The VU processor checks the received data extracting the information (e.g., latitude, longitude, time) from the RMC NMEA sentence. The RMC NMEA sentence includes the information if the position is valid. If the position is not valid, the location data is not available yet and it cannot be used to record the position of the vehicle. If the position is valid, the VU processor also extracts the values of HDOP from GSA NMEA sentences and calculate the minimum value on the available satellite systems (i.e., when the fix is available).’;

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.