Commission Implementing Regulation (EU) 2021/1228 of 16 July 2021 amending Implementing Regulation (EU) 2016/799 as regards the requirements for the construction, testing, installation, operation and repair of smart tachographs and their components (Text with EEA relevance)

(ix) the following point 8 is added: ‘8. VEHICLE MOTION CONFLICT’; (b) point 1 is amended as follows (i) the text before Figure 1 is replaced by the following: ‘1.   INTRODUCTION This Appendix provides the technical requirements for the GNSS receiver and GNSS data used by the Vehicle Unit, including the protocols that must be implemented to assure the secure and correct data transfer of the positioning information. 1.1.   Scope GNS_1 The Vehicle Unit shall collect location data from at least one GNSS satellite network. The Vehicle Unit may be with or without an external GNSS facility as described in Figure 1:’; (ii) the following point 1.1.1 is inserted after point 1.1: ‘1.1.1 References The following references are used in this part of this Appendix. NMEA NMEA (National Marine Electronics Association) 0183 Interface Standard, V4.11’; (iii) in point 1.2, the following acronyms are added: ‘OSNMA Galileo Open Service Navigation Messages Authentication RTC Real Time Clock ’; (c) point 2 is amended as follows: (i) the header is replaced by the following: ‘2. BASIC CHARACTERISTICS OF THE GNSS RECEIVER’; (ii) paragraph GNS_3 is replaced by the following: ‘GNS_3 The GNSS receiver shall have the capability to support Navigation Messages Authentication on the Open Service of Galileo (OSNMA).’; (iii) the following paragraphs GNS_3a to GNS_3g are added: ‘GNS_3a The GNSS receiver shall perform a number of consistency checks in order to verify that the measurements computed by the GNSS receiver on the basis of the OSNMA data have resulted in the correct information about the position, velocity and data of the vehicle, and have therefore not been influenced by any external attack such as meaconing. These consistency checks shall consist, for instance, of: — detection of abnormal power emissions by means of combined monitoring of the Automatic Gain Control (AGC) and Carrier-to-Noise density ratio (C/N0), — pseudorange measurement consistency and Doppler measurement consistency over time, including the detection of abrupt measurement jumps, — receiver autonomous integrity monitoring (RAIM) techniques, including the detection of inconsistent measurements with the estimated position, — position and velocity checks, including abnormal position and velocity solutions, sudden jumps and behaviour not consistent with the dynamics of the vehicle, — time and frequency consistency, including clock jumps and drifts that are not consistent with the receiver clock characteristics. GNS_3b The European Commission shall develop and approve the following documents: — A Signal in Space Interface Control Document (SIS ICD), specifying in detail the OSNMA information transmitted in the Galileo signal. — OSNMA Receiver Guidelines, providing the requirements and processes in the receivers to guarantee a secure implementation of OSNMA, as well as recommendations to enhance OSNMA performance. GNSS receivers fitted in tachographs, either internal or external, shall be constructed in accordance with the SIS ICD and the OSNMA receiver guidelines. GNS_3c The GNSS receiver shall provide position messages, called authenticated position messages in this Annex and its Appendixes, which are elaborated using only satellites from which the authenticity of the navigation messages has been successfully verified. GNS_3d The GNSS receiver shall also provide standard position messages, elaborated using the satellites in view, regardless whether they are authenticated or not. GNS_3e The GNSS receiver shall use the VU Real Time Clock (RTC) as time reference for the time synchronisation necessary for OSNMA. GNS_3f The VU RTC time shall be provided to the GNSS receiver by the VU. GNS_3g The maximal time drift specified in requirement 41 of Annex IC, shall be provided to the GNSS receiver by the VU, along with the VU RTC time.’; (d) point 3 is replaced by the following: ‘3. SENTENCES PROVIDED BY THE GNSS RECEIVER This section describes the sentences used in the functioning of the Smart Tachograph, for transmitting standard and authenticated position messages. This section is valid both for the configuration of the Smart Tachograph with or without an external GNSS facility. GNS_4 The standard position data is based on the NMEA sentence Recommended Minimum Specific (RMC) GNSS Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values. The format of the RMC sentence is the following (as from NMEA V4.11 standard): Figure 2

Structure of the RMC sentence $--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,ahh (1)Time (UTC) (2)Status, A= Valid position, V= Warning (3)Latitude (4)N or S (5)Longitude (6)E or W (7)Speed over ground in knots (8)Track made good, degrees true (9)Date, ddmmyy (10)Magnetic Variation, degrees (11)E or W (12)FAA Mode Indicator (13)Navigational status (14)Checksum The Navigational status is optional and may not be present in the RMC sentence. The Status gives indication if the GNSS signal is available. Until the value of the Status is not set to ‘A’, the received data (e.g., on Time or Latitude/Longitude) cannot be used to record the position of the vehicle in the VU. 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/1 000 of minute or 1/60 000 of degree (because one minute is 1/60 of a degree). GNS_4a The authenticated position data is based on a NMEA-like sentence, Authenticated Minimum Specific (AMC) Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values. The format of the AMC sentence is the following (as from NMEA V4.11 standard, except for value number 2): Figure 3*

Structure of the AMC sentence $--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,ahh (1)Time (UTC) (2)Status, A=Authenticated position (established using at least 4 satellites from which the authenticity of the navigation messages has been successfully verified), J=jamming or O=other GNSS attack in the absence of failed authentication of navigation messages (by implemented consistency checks according to GNS_3a), F=failed authentication of navigation messages (as detected by OSNMA verifications specified in the documents referred to in GNS_3b), V=Void (authenticated position is not available for any other reason) (3)Latitude (4)N or S (5)Longitude (6)E or W (7)Speed over ground in knots (8)Track made good, degrees true (9)Date, ddmmyy (10)Magnetic Variation, degrees (11)E or W (12)FAA Mode Indicator (13)Navigational status (14)Checksum The Navigational status is optional and may not be present in the AMC sentence. The Status gives indication if an authenticated GNSS position is available, if an attack on the GNSS signals has been detected, if authentication of navigation messages has failed, or if GNSS position is void. When the value of the Status is not set to ‘A’, the received data (e.g. Time or Latitude/Longitude) are considered to be not valid, and may not be used to record the position of the vehicle in the VU. When the value of the Status is set to ‘J’ (jamming), ‘O’ (other GNSS attack), or ‘F’ (failed authentication of navigation messages), a GNSS anomaly event shall be recorded in the VU, as defined in Annex IC and Appendix 1 (EventFaultCode). 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, as from NMEA V4.11 standard, can be used by the VU to determine and record the signal availability and accuracy of standard positions. 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 4*

Structure of the GSA sentence (standard positions) $--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,ahh (1)Selection mode (2)Mode (3)ID of 1^st satellite used for fix (4)ID of 2^nd satellite used for fix … (14)ID of 12th satellite used for fix (15)PDOP (16)HDOP (17)VDOP (18)System ID (19)Checksum The System ID is optional and may not be present in the GSA sentence. Similarly, the NMEA-like sentence authenticated active satellites (ASA) command can be used by the VU to determine and record the signal availability and accuracy of authenticated positions. Values 1 to 18 are defined in NMEA V4.11 standard. Figure 5*

Structure of the ASA sentence (authenticated positions) $--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,ahh (1)Selection mode (2)Mode (3)ID of 1^st satellite used for fix (4)ID of 2^nd satellite used for fix … (14)ID of 12^th satellite used for fix (15)PDOP (16)HDOP (17)VDOP (18)System ID (19)Checksum The System ID is optional and may not be present in the ASA sentence. GNS_6 When an external GNSS facility is used, the GSA* sentence shall be stored in the GNSS Secure Transceiver with record number ’02’ to ’06’, and the ASA sentence shall be stored with record number ‘12’ to ‘16’. GNS_7 The maximum size of the sentences (e.g., RMC, AMC, GSA, ASA or others), which can be used for the sizing of the read record command shall be 85 bytes (see Table 1).’; (e) point 4 is amended as follows: (i) in point 4.1.1, paragraph GNS_9 is amended as follows: (1) the text before sub-paragraph (b) is replaced by the following: ‘GNS_9 The external GNSS facility shall consist of the following components (see Figure 6): (a) A commercial GNSS receiver to provide the position data through the GNSS data interface. For example, the GNSS data interface can be NMEA standard V4.11 where the GNSS receiver acts as a talker and transmits NMEA sentences to the GNSS Secure Transceiver with a frequency of 1Hz for the pre-defined set of NMEA and NMEA-like sentences, which must include at least the RMC, AMC, GSA and ASA sentences. The implementation of the GNSS data interface is a choice of the manufacturers of the external GNSS facility.’; (2) subparagraph (c) is replaced by the following: ‘(c) An enclosure system with tamper detection function, which encapsulates both the GNSS receiver and the GNSS Secure Transceiver. The tamper detection function shall implement the security protection measures as requested in the Protection Profile of the Smart Tachograph.’; (ii) point 4.2.1 is amended as follows: (1) paragraph GNS_14 is replaced by the following: ‘GNS_14 The communication protocol between the external GNSS facility and the vehicle unit shall support the following functions:

(2) the following paragraph is inserted after paragraph GNS_18: ‘GNS_18a Regarding the function 4) the transmission to the external GNSS facility of the VU RTC time and of the maximal difference between true time and the VU RTC time, the GNSS Secure Transceiver shall use an EF (EF VU) in the same DF with file identifier equal to ‘2F30’ as described in Table 1.’; (3) the following paragraph is inserted after paragraph GNS_19: ‘GNS_19a The GNSS Secure Transceiver shall store the data coming from the VU in the EF VU. This is a linear, fixed-length record file with an identifier equal to ‘2F30’ in hexadecimal format.’; (4) in paragraph GNS_20, the first subparagraph is replaced by the following: ‘GNS_20 The GNSS Secure Transceiver shall use a memory to store the data and be able to perform as many read/write cycles as needed during a lifetime of at least 15 years. Apart from this aspect, the internal design and implementation of the GNSS Secure Transceiver is left to the manufacturers.’; (5) in GNS_21, Table 1 is replaced by the following: ‘ Table 1 File Structure Access conditions File File ID Read Update Encrypted MF 3F00 EF.ICC 0002 ALW NEV (by VU) No DF GNSS Facility 0501 ALW NEV No EF EGF_MACertificate C100 ALW NEV No EF CA_Certificate C108 ALW NEV No EF Link_Certificate C109 ALW NEV No EF EGF 2F2F SM-MAC NEV (by VU) No EF VU 2F30 SM-MAC SM-MAC No File / Data element Record no Size (bytes) Default values Min Max MF

552 1031 EF.ICC sensorGNSSSerialNumber

8 8

DF GNSS Facility

612 1023 EF EGF_MACertificate

204 341 EGFCertificate

204 341 {00..00} EF CA_Certificate

204 341 MemberStateCertificate

204 341 {00..00} EF Link_Certificate

204 341 LinkCertificate

204 341 {00..00}

EF EGF RMC NMEA Sentence '01' 85 85 1st GSA NMEA Sentence '02' 85 85 2nd GSA NMEA Sentence '03' 85 85 3rd GSA NMEA Sentence '04' 85 85 4th GSA NMEA Sentence '05' 85 85 5th GSA NMEA Sentence '06' 85 85 Extended serial-number of the external GNSS facility defined in Appendix 1 as SensorGNSSSerialNumber. '07' 8 8 Operating system identifier of the GNSS Secure Transceiver defined in Appendix 1 as SensorOSIdentifier. '08' 2 2 Type approval number of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSApprovalNumber. '09' 16 16 Identifier of the security component of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSSCIdentifier '10' 8 8 AMC Sentence '11' 85 85 1st ASA Sentence '12' 85 85 2nd ASA Sentence '13' 85 85 3rd ASA Sentence '14' 85 85 4th ASA Sentence '15' 85 85 5th ASA Sentence '16' 85 85 RFU – Reserved for Future Use From '17' to 'FD' EF VU VuRtcTime (see Appendix 1) '01' 4 4 {00..00} VuGnssMaximalTimeDifference (see Appendix 1) '02' 2 2 {00..00}’ ; (iii) point 4.2.2 is amended as follows: (1) in paragraph GNS_22, the first subparagraph is replaced by the following: ‘GNS_22 The secure transfer of GNSS position data, VU RTC time and maximal time difference between true time and the VU RTC time shall be allowed only in the following conditions:’; (2) paragraph GNS_23 is replaced by the following: ‘GNS_23 Every T seconds, where T is a value lower or equal to 20, unless coupling or mutual authentication and session key agreement takes place, the VU requests from the external GNSS facility the position information on the basis of the following flow:

GNS_23a The VU shall also write VU RTC time and maximal time difference between true time and the VU RTC time as needed, by using the ISO/IEC 7816-4:2013 SELECT and WRITE RECORD(S) commands in secure messaging authentication-only mode as described in section 11.5 of Appendix 11 with the file identifier ‘2F30’ and RECORD number equal to ‘01’ for VuRtcTime and ‘02’ for MaximalTimeDifference.’; (iv) point 4.2.3 is amended as follows: (1) in paragraph GNS_26, the fourth and fifth indents are replaced by the following: ‘- If the record is not found, the GNSS secure transceiver returns ‘6A83’. - If the external GNSS facility has detected tampering, it shall return status words ‘6690’.’; (2) paragraph GNS_27 is deleted; (v) the following points 4.2.4 and 4.2.5 are inserted: ‘4.2.4 Structure of the WriteRecord command This section describes in detail the structure of the Write Record command. Secure messaging (authentication-only mode) is added as described in Appendix 11 Common security mechanisms. GNS_26a The command shall support the Secure Messaging authentication-only-mode, see Appendix 11. GNS_26b Command Message

Byte Length Value Description CLA 1 ‘0Ch’ Secure messaging asked. INS 1 ‘D2h’ Write Record P1 1 ‘XXh’ Record number ('00' references the current record) P2 1 ‘04h’ Write the record with the record number indicated in P1 Data X ‘XXh’ Data GNS_26c The record referenced in P1 becomes the current record.

Byte Length Value Description SW 2 ‘XXXXh’ Status Words (SW1,SW2) — If the command is successful, the GNSS secure transceiver returns ‘ 9000 ’. — If the current file is not record oriented, the GNSS secure transceiver returns '6981'. — If the command is used with P1 = '00' but there is no current EF the GNSS secure transceiver returns '6986' (command not allowed). — If the record is not found, the GNSS secure transceiver returns '6A83'. — If the external GNSS facility has detected tampering, it shall return status words ’6690’. 4.2.5 Other commands GNS_27 The GNSS Secure Transceiver shall support the following tachograph generation 2 commands specified in Appendix 2:

Command Reference Select Appendix 2 chapter 3.5.1 Read Binary Appendix 2 chapter 3.5.2 Get Challenge Appendix 2 chapter 3.5.4 PSO: Verify Certificate Appendix 2 chapter 3.5.7 External Authenticate Appendix 2 chapter 3.5.9 General Authenticate Appendix 2 chapter 3.5.10 MSE:SET Appendix 2 chapter 3.5.11 ’; (vi) in point 4.4.1, paragraph GNS_28 is replaced by the following: ‘GNS_28 A communication error with the external GNSS facility event shall be recorded in the VU, as defined in requirement 82 of Annex IC and Appendix 1 (EventFaultType). In this context, a communication error is triggered when the VU Secure Transceiver does not receive a response message after a request message as described in 4.2.’; (vii) in point 4.4.2, paragraph GNS_29 is replaced by the following: ‘GNS_29 If the external GNSS facility has been breached, the GNSS Secure Transceiver shall ensure that cryptographic material is unavailable. As described in GNS_25 and GNS_26, the VU shall detect tampering if the Response has status ‘6690’. The VU shall then generate and record a security breach attempt event as defined in requirement 85 of Annex IC and Appendix 1 (EventFaultType for tamper detection of GNSS). Alternately, the external GNSS facility may respond to VU requests without secure messaging and with status ‘6A88’.’; (viii) in point 4.4.3, paragraph GNS_30 is replaced by the following: ‘GNS_30 If the GNSS Secure Transceiver does not receive data from the GNSS receiver, the GNSS Secure Transceiver shall generate a response message to the READ RECORD command with RECORD number equal to ‘01’ with a Data Field of 12 bytes all set to 0xFF. Upon reception of the Response message with this value of the data field, the VU shall generate and record an absence of position information from GNSS receiver event, as defined in requirement 81 of Annex IC and Appendix 1 (EventFaultType).’; (ix) point 4.4.4 is amended as follows: (1) paragraph GNS_31 is replaced by the following: ‘GNS_31 If the VU detects that the EGF certificate used for mutual authentication is not valid any longer, the VU shall generate and record a security breach attempt event as defined in requirement 85 of Annex IC and Appendix 1 (EventFaultType for external GNSS facility certificate expired). The VU shall still use the received GNSS position data.’; (2) the header of figure 4 is replaced by the following: ‘ Figure 6 Schema of the external GNSS facility ’; (f) point 5 is amended as follows: (i) in point 5.1, paragraph GNS_32 is replaced by the following: ‘GNS_32 For transmitting position, DOP and satellites data, the GNSS receiver shall act as a talker and transmit NMEA or NMEA-like sentences to the VU processor, which shall act as a listener with a frequency of 1/10 Hz or faster for the pre-defined set of sentences, which shall include at least the RMC, GSA, AMC and ASA sentences. Alternatively, the VU processor and the internal GNSS receiver may use other data formats to exchange the data contained in the NMEA or NMEA-like sentences specified in GNS_4, GNS_4a and GNS_5.’; (ii) point 5.2 is replaced by the following: ‘5.2. Transfer of information from the GNSS receiver to the VU GNS_34 The VU processor checks the received data extracting the information (e.g., latitude, longitude, time) from the RMC NMEA sentence and the AMC sentence. GNS_35 The RMC NMEA sentence includes the information if the non-authenticated position is valid. If the non-authenticated position is not valid, the position data is not available and it cannot be used to record the position of the vehicle. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from GSA NMEA. GNS_36 The VU processor also extracts the information (e.g. latitude, longitude, time) from the AMC sentence. The AMC sentence includes the information if the non-authenticated position is valid according to GNS_4a. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from ASA sentences. 5.3. Transfer of information from the VU to the GNSS receiver GNS_37 The VU processor provides to the GNSS receiver the VU RTC time and the maximal difference between true time and the VU RTC time, in accordance with GNS_3f and GNS_3g. 5.4. Error handling 5.4.1 Absence of position information from GNSS receiver GNS_38 The VU shall generate and record an absence of position information from GNSS receiver event, as defined in requirement 81 of Annex IC and Appendix 1 (EventFaultType).’; (g) points 6 and 7 are replaced by the following: ‘6. POSITION DATA PROCESSING AND RECORDING BY THE VU This section is valid both for the configuration of the Smart Tachograph with or without an external GNSS facility. GNS_39 Position data shall be stored in the VU, together with a flag indicating if the position has been authenticated. When position data need to be recorded in the VU, the following rules shall apply: (a) If both authenticated and standard positions are valid and consistent, the standard position and its accuracy shall be recorded in the VU and the flag shall be set to ‘authenticated’. (b) If both authenticated and standard positions are valid but not consistent, the VU shall store the authenticated position and its accuracy, and the flag shall be set to ‘authenticated’. (c) If the authenticated position is valid and the standard position is not valid, the VU shall record the authenticated position and its accuracy, and the flag shall be set to ‘authenticated’. (d) If the standard position is valid and the authenticated position is not valid, the VU shall record the standard position and its accuracy, and the flag shall be set to ‘not authenticated’. Authenticated and standard positions are considered as consistent, as shown in Figure 7, when the horizontal authenticated position can be found in a circle centered at the horizontal standard position, which radius results of rounding up to the nearest upper whole number the value of R_H calculated according to the following formula:

R_H = 1.74 • σUERE • HDOP where: — R_H is the relative radius of a circle around the estimated horizontal position, in meters. It is an indicator that is used to check consistency between standard and authenticated positions. — σUERE is the standard deviation for the user equivalent range error (UERE), which models all measurement errors for the target application, including urban environments. A constant value of σUERE = 10 meters shall be used. — HDOP is the horizontal dilution of precision calculated by the GNSS receiver. — σUERE. HDOP is the estimation of the root mean squared error in the horizontal domain. Figure 7

Consistent Authenticated and Standard (non-authenticated) positions GNS_40 When the value of the Status in a received AMC sentence is set to ‘J’ or ‘O’ or ‘F’ 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.

GNS_41 If the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the GNSS signals, it shall generate and record a time conflict event, as defined in requirement 86 of Annex IC and Appendix 1 (EventFaultType).’; (h) the following point 8 is added: ‘8. VEHICLE MOTION CONFLICT GNS_42 The VU shall trigger and record a Vehicle Motion Conflict event in accordance with requirement 84 of Annex IC, in case motion information calculated from the motion sensor is contradicted by motion information calculated from the internal GNSS receiver, from the external GNSS facility, or by other independent motion source(s) as set out in requirement 26 of Annex IC. The vehicle motion conflict event shall be triggered upon occurrence of one of the following trigger conditions: Trigger condition 1: The trimmed mean value of the speed differences between these sources shall be used, when the position information from the GNSS receiver is available and when the ignition of the vehicle is switched on, as specified below: — every 10 seconds maximum, the absolute value of the difference between the vehicle speed estimated from the GNSS and the one estimated from the motion sensor shall be computed. — all the computed values in a time window containing the last 5 minutes of vehicle movement shall be used to compute the trimmed mean value. — the trimmed mean value shall be computed as the average of 80% of the remaining values, after having eliminated the highest ones in absolute values. The Vehicle Motion Conflict event shall be triggered if the trimmed mean value is above 10 km/h for five uninterrupted minutes of vehicle movement. (Note: the use of the trimmed mean on the last 5 minutes is applied to mitigate the risk of measurement outliers and transient values). For the trimmed mean computation, the vehicle shall be considered as moving if at least one vehicle speed value estimated either from motion sensor or from GNSS receiver is not equal to zero. Trigger condition 2: The vehicle motion conflict event shall also be triggered if the following condition is true: GnssDistance>[OdometerDifference×OdometerToleranceFactor+Minimum(SlipDistanceUpperlimit;(OdometerDifference×SlipFactor))+GnssTolerance+FerryTrainDistance] where: — GnssDistance is the distance between the current position of the vehicle and the previous one, both obtained from valid authenticated position messages, without considering the height, — OdometerDifference is the difference between the current odometer value and the odometer value corresponding to the previous valid authenticated position message, — OdometerToleranceFactor is equal to 1.1 (worst case tolerance factor for all measurement tolerances of the vehicle odometer), — GnssTolerance is equal to 1 km (worst case GNSS tolerance), — Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) is the minimum value between: — SlipDistanceUpperLimit which is equal to 10 km (upper limit of the slip distance caused by slipping effects during braking), — and OdometerDifference * SlipFactor, in which SlipFactor is equal to 0.2 (maximal influence of slipping effects during breaking), — FerryTrainDistance is computed as: FerryTrainDistance =200km/h * tFerryTrain, where tFerryTrain is the sum of the durations in hours of the ferry/train crossings in the considered time interval. The duration of a ferry/train crossings is defined as the time difference between its end flag and its beginning flag. The preceding verifications shall be performed every 15 minutes if the necessary position data are available, otherwise as soon as the position data are available. For this trigger condition: — date and time of beginning of event shall be equal to the date and time when the previous position message was received, — date and time of end of event shall be equal to the date and time when the checked condition becomes false again. Trigger condition 3: The vehicle unit encounters a discrepancy consisting of the motion sensor not detecting any movement and the independent motion source detecting movement for a specific period. The conditions to record a discrepancy as well as the period of detection of the discrepancy shall be set out by the vehicle unit manufacturer, although the discrepancy shall be detected in no more than three hours.’;

(38) Appendix 13 is replaced by the following: Appendix 13 ITS INTERFACE TABLE OF CONTENTS

1.1. Scope 1.2. Acronyms and definitions

3.1. Communication technology 3.2. Available services 3.3. Access through the ITS interface 3.4. Data available and need of driver consent

1.1.   Scope ITS_01 This Appendix specifies the basics of the communication through the tachograph interface with Intelligent Transport Systems (ITS), requested in Articles 10 and 11 of Regulation (EU) No 165/2014. ITS_02 The ITS interface shall allow external devices to obtain data from the tachograph, to use tachograph services and also to provide data to the tachograph. Other tachograph interfaces (e.g. CAN bus) may also be used for that purpose. This Appendix does not specify: — how data provided through the ITS interface are collected and managed within the tachograph, — the form of presentation of collected data to applications hosted on the external device, — the ITS security specification in addition to what provides Bluetooth®, — the Bluetooth® protocols used by the ITS interface. 1.2.   Acronyms and definitions The following acronyms and definitions specific to this Appendix are used: GNSS Global Navigation Satellite System ITS Intelligent Transport System OSI Open Systems Interconnection VU Vehicle Unit ITS unit an external device or application using the VU ITS interface.

ITS_03 This Appendix refers to and depends upon all or parts of the following regulations and standards. Within the clauses of this Appendix, the relevant standards, or relevant clauses of standards, are referred to. In the event of any contradiction the clauses of this Appendix shall take precedence. Standards referenced to in this Appendix are: — Bluetooth® – Core Version 5.0. — ISO 16844-7: Road vehicles -Tachograph systems - Part 7: Parameters — ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection - Basic Reference Model, the Basic Model

ITS_04 The VU shall be responsible to keep updated and maintain tachograph data transmitted through the ITS interface, without any involvement of the ITS interface. 3.1.   Communication technology ITS_05 Communication through the ITS interface shall be performed via Bluetooth® interface and be compatible to Bluetooth® Low Energy according to Bluetooth version 5.0 or newer. ITS_06 The communication between the VU and the ITS unit shall be established after a Bluetooth® pairing process has been completed. ITS_07 A secure and encrypted communication shall be established between the VU and the ITS unit, in accordance with the Bluetooth® specification mechanisms. This Appendix does not specify encryption or other security mechanisms in addition to what Bluetooth® provides. ITS_08 Bluetooth® is using a server/client model to control the transmission of data between devices, in which the VU shall be the server and the ITS unit shall be the client. 3.2.   Available services ITS_09 The data to be transmitted through the ITS interface in accordance with point 4 shall be made available through the services specified in Appendix 7 and Appendix 8. In addition, the VU shall make available to the ITS unit the services that are necessary for manual data entry in accordance with requirement 61 of Annex IC, and optionally, for other data entries in real time. Figure 1

partition of the communication through the ITS interface according to the OSI Model layers ITS_10 When the download interface is used via the front connector, the VU shall not provide the download services specified in Appendix 7 via ITS Bluetooth® connection. ITS_11 When the calibration interface is used via the front connector, the VU shall not provide the calibration services specified in Appendix 8 via ITS Bluetooth® connection. 3.3.   Access through the ITS interface ITS_12 The ITS interface shall provide a wireless access to all services specified in Appendix 7 and Appendix 8, in replacement of a cable connection to the front connector for calibration and download specified in Appendix 6. ITS_13 The VU shall make the ITS interface available to the user according to the combination of valid tachograph cards inserted in the VU, as specified in Table 1. Table 1 Availability of ITS interface depending on the type of card inserted in the tachograph Availability of the ITS interface Driver slot No card Driver card Control card Workshop card Company card Co-driver slot No card Not available Available Available Available Available Driver card Available Available Available Available Available Control card Available Available Available Not available Not available Workshop card Available Available Not available Available Not available Company card Available Available Not available Not available Available ITS_14 After a successful ITS Bluetooth® pairing, the VU shall assign the ITS Bluetooth® connection to the specific inserted tachograph card according to Table 2: Table 2 Assignment of the ITS connection depending on the type of card inserted in the tachograph Assignment of the ITS Bluetooth® connection Driver slot No card Driver card Control card Workshop card Company card Co-driver slot No card Not available Driver card Control card Workshop card Company card Driver card Driver card Driver card (²) Control card Workshop card Company card Control card Control card Control card Control card (1) Not available Not available Workshop card Workshop card Workshop card Not available Workshop card (¹) Not available Company card Company card Company card Not available Not available Company card (1) (¹) The ITS Bluetooth® connection shall be assigned to the tachograph card in the driver slot of the VU. (2) The user shall select the card to which the ITS Bluetooth® connection shall be assigned (inserted in the driver or in the co-driver slot). ITS_15 If a tachograph card is withdrawn, then the VU shall terminate the ITS Bluetooth® connection which is assigned to this card. ITS_16 The VU shall support the ITS connection to at least one ITS unit and may support connections to multiple ITS units at the same time. ITS_17 The access rights to the data and services available via the ITS interface shall comply with requirements 12 and 13 of Annex IC, in addition to the driver consent specified in section 3.4 of this Appendix. 3.4.   Data available and need of driver consent ITS_18 All tachograph data available via the services referred to in point 3.3 shall be classified as either personal or not personal for the driver, co-driver or both. ITS_19 At least the list of data classified as mandatory in section 4 shall be made available through the ITS interface. ITS_20 The data in section 4 that are classified as ‘personal’ shall only be accessible upon driver consent, accepting therefore that the personal data can leave the vehicle network, except in the case set out in requirement ITS_25, for which the driver consent is not needed. ITS_21 Data additional to those gathered in point 4 and considered as mandatory may be made available through the ITS interface. Additional data which are not included in point 4 shall be classified as ‘personal’ or not ‘personal’ by the VU manufacturer, being the driver consent requested for those data that have been classified as personal, except in the case set out in requirement ITS_25, for which the driver consent is not needed. ITS_22 Upon insertion of a driver card which is unknown to the vehicle unit, the cardholder shall be prompted by the tachograph to enter the consent for transmission of personal data output through the ITS interface, in accordance with requirement 61 of Annex IC. ITS_23 The consent status (enabled/disabled) shall be recorded in the data memory of the vehicle unit. ITS_24 In case of multiple drivers, only the personal data related to the drivers who gave their consent shall be accessible through the ITS interface. For instance, in a crew situation, if only the driver has given his/her consent, personal data related to the co-driver shall not be accessible. ITS_25 When the VU is in control, company or calibration modes, the access rights through the ITS interface shall be managed according to requirements 12 and 13 of Annex IC, hence the driver consent not being needed.

Data name Data format Source Data classification (personal/ not personal) Consent for the availability of the data Availability driver co-driver VehicleIdentificationNumber Appendix 8 VU not personal not personal no need of consent mandatory CalibrationDate ISO 16844-7 VU not personal not personal no need of consent mandatory TachographVehicleSpeed ISO 16844-7 VU personal N/A driver consent mandatory Driver1WorkingState ISO 16844-7 VU personal N/A driver consent mandatory Driver2WorkingState ISO 16844-7 VU N/A personal co-driver consent mandatory DriveRecognize ISO 16844-7 VU not personal not personal no need of consent mandatory Driver1TimeRelatedStates ISO 16844-7 VU personal N/A driver consent mandatory Driver2TimeRelatedStates ISO 16844-7 VU N/A personal co-driver consent mandatory DriverCardDriver1 ISO 16844-7 VU personal N/A driver consent mandatory DriverCardDriver2 ISO 16844-7 VU N/A personal co-driver consent mandatory OverSpeed ISO 16844-7 VU personal N/A driver consent mandatory TimeDate Appendix 8 VU not personal not personal no need of consent mandatory HighResolutionTotalVehicleDistance ISO 16844-7 VU not personal not personal no need of consent mandatory HighResolutionTripDistance ISO 16844-7 VU not personal not personal no need of consent mandatory ServiceComponentIdentification ISO 16844-7 VU not personal not personal no need of consent mandatory ServiceDelayCalendarTimeBased ISO 16844-7 VU not personal not personal no need of consent mandatory Driver1Identification ISO 16844-7 Driver Card personal N/A driver consent mandatory Driver2Identification ISO 16844-7 Driver Card N/A personal co-driver consent mandatory NextCalibrationDate Appendix 8 VU not personal not personal no need of consent mandatory Driver1ContinuousDrivingTime ISO 16844-7 VU personal N/A driver consent mandatory Driver2ContinuousDrivingTime ISO 16844-7 VU N/A personal co-driver consent mandatory Driver1CumulativeBreakTime ISO 16844-7 VU personal N/A driver consent mandatory Driver2CumulativeBreakTime ISO 16844-7 VU N/A personal co-driver consent mandatory Driver1CurrentDurationOfSelectedActivity ISO 16844-7 VU personal N/A driver consent mandatory Driver2CurrentDurationOfSelectedActivity ISO 16844-7 VU N/A personal co-driver consent mandatory SpeedAuthorised Appendix 8 VU not personal not personal no need of consent mandatory TachographCardSlot1 ISO 16844-7 VU not personal N/A no need of consent mandatory TachographCardSlot2 ISO 16844-7 VU N/A not personal no need of consent mandatory Driver1Name ISO 16844-7 Driver Card personal N/A driver consent mandatory Driver2Name ISO 16844-7 Driver Card N/A personal co-driver consent mandatory OutOfScopeCondition ISO 16844-7 VU not personal not personal no need of consent mandatory ModeOfOperation ISO 16844-7 VU not personal not personal no need of consent mandatory Driver1CumulatedDrivingTimePreviousAndCurrentWeek ISO 16844-7 VU personal N/A driver consent mandatory Driver2CumulatedDrivingTimePreviousAndCurrentWeek ISO 16844-7 VU N/A personal co-driver consent mandatory EngineSpeed ISO 16844-7 VU personal N/A driver consent optional RegisteringMemberState Appendix 8 VU not personal not personal no need of consent mandatory VehicleRegistrationNumber Appendix 8 VU not personal not personal no need of consent mandatory Driver1EndOfLastDailyRestPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2EndOfLastDailyRestPeriod ISO 16844-7 VU N/A personal co-driver consent optional Driver1EndOfLastWeeklyRestPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2EndOfLastWeeklyRestPeriod ISO 16844-7 VU N/A personal co-driver consent optional Driver1EndOfSecondLastWeeklyRestPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2EndOfSecondLastWeeklyRestPeriod ISO 16844-7 VU N/A Personal co-driver consent optional Driver1TimeLastLoadUnloadOperation ISO 16844-7 VU personal N/A driver consent optional Driver2TimeLastLoadUnloadOperation ISO 16844-7 VU N/A personal co-driver consent optional Driver1CurrentDailyDrivingTime ISO 16844-7 VU personal N/A driver consent optional Driver2CurrentDailyDrivingTime ISO 16844-7 VU N/A personal co-driver consent optional Driver1CurrentWeeklyDrivingTime ISO 16844-7 VU personal N/A driver consent optional Driver2CurrentWeeklyDrivingTime ISO 16844-7 VU N/A personal co-driver consent optional Driver1TimeLeftUntilNewDailyRestPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2TimeLeftUntilNewDailyRestPeriod ISO 16844-7 VU N/A personal co-driver consent optional Driver1CardExpiryDate ISO 16844-7 Driver Card personal N/A driver consent optional Driver2CardExpiryDate ISO 16844-7 Driver Card N/A personal co-driver consent optional Driver1CardNextMandatoryDownloadDate ISO 16844-7 VU personal N/A driver consent optional Driver2CardNextMandatoryDownloadDate ISO 16844-7 VU N/A personal co-driver consent optional TachographNextMandatoryDownloadDate ISO 16844-7 VU not personal not personal no need of consent optional Driver1TimeLeftUntilNewWeeklyRestPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2TimeLeftUntilNewWeeklyRestPeriod ISO 16844-7 VU N/A personal co-driver consent optional Driver1NumberOfTimes9hDailyDrivingTimesExceeded ISO 16844-7 VU personal N/A driver consent optional Driver2NumberOfTimes9hDailyDrivingTimesExceeded ISO 16844-7 VU N/A personal co-driver consent optional Driver1CumulativeUninterruptedRestTime ISO 16844-7 VU personal N/A driver consent optional Driver2CumulativeUninterruptedRestTime ISO 16844-7 VU N/A personal co-driver consent optional Driver1MinimumDailyRest ISO 16844-7 VU personal N/A driver consent optional Driver2MinimumDailyRest ISO 16844-7 VU N/A personal co-driver consent optional Driver1MinimumWeeklyRest ISO 16844-7 VU personal N/A driver consent optional Driver2MinimumWeeklyRest ISO 16844-7 VU N/A personal co-driver consent optional Driver1MaximumDailyPeriod ISO 16844-7 VU personal N/A driver consent optional Driver2MaximumDailyPeriod ISO 16844-7 VU N/A personal co-driver consent optional Driver1MaximumDailyDrivingTime ISO 16844-7 VU personal N/A driver consent optional Driver2MaximumDailyDrivingTime ISO 16844-7 VU N/A personal co-driver consent optional Driver1NumberOfUsedReducedDailyRestPeriods ISO 16844-7 VU personal N/A driver consent optional Driver2NumberOfUsedReducedDailyRestPeriods ISO 16844-7 VU N/A personal co-driver consent optional Driver1RemainingCurrentDrivingTime ISO 16844-7 VU personal N/A driver consent optional Driver2RemainingCurrentDrivingTime ISO 16844-7 VU N/A personal co-driver consent optional VehiclePosition Appendix 8 VU personal personal driver and co-driver consent mandatory ByDefaultLoadType Appendix 8 VU personal personal driver and co-driver consent mandatory

(39) Appendix 14 is amended as follows: (a) in the Table of Contents, the following point is inserted after point 5.4.8: ‘5.5 Reserved for future use’; (b) in point 4.1.1.5, paragraph DCS_17 is replaced by the following: ‘DSC_17 Security data (DSRCSecurityData), comprising the data required by the REDCR to complete its ability to decrypt the Data shall be supplied as defined in Appendix 11 Common Security Mechanisms, for temporary storage in the DSRC-VU as the current version of DSRCSecurityData, in the form defined in section 5.4.4 of this Appendix.’; (c) point 5 is amended as follows: (i) in point 5.4.4, the TachographPayload sequence in the ASN.1 module definition for the DSRC data within the RTM application, is replaced by the following: ‘ ’; (ii) in point 5.4.5, Table 14.3 is replaced by the following: ‘ Table 14.3 Elements of RtmData, actions performed and definitions (1) RTM Data Element (2) Action performed by the VU

(3) ASN.1 definition of data RTM1 Vehicle Registration Plate The VU shall set the value of the tp15638VehicleRegistrationPlate data element RTM1 from the recorded value of the data type VehicleRegistrationIdentification as defined in Appendix 1 VehicleRegistrationIdentification Vehicle Registration Plate expressed as a string of characters tp15638VehicleRegistrationPlate LPN, --Vehicle RegistrationPlate using the data structure from ISO 14906, but with the following limitation for the RTM application: the SEQUENCE starts with the Country Code, followed by an alphabet indicator, followed by the plate number itself, which is always 14 octets (padded with zero's) so the LPN type length is always 17 octets (no length determinant needed), of which 14 are the ‘real’ plate number. RTM2 Speeding Event The VU shall generate a Boolean value for data element RTM2 tp15638SpeedingEvent. The tp15638SpeedingEvent value shall be calculated by the VU from the over speeding events recorded in the VU within the last 10 days, as defined in Annex IC. 1 (TRUE): if the most recent over speeding event ended within the last 10 days or is still ongoing; 0 (FALSE): in any other case. tp15638SpeedingEvent BOOLEAN, RTM3 Driving Without Valid Card The VU shall generate a Boolean value for data element RTM3 tp15638DrivingWithoutValidCard. The VU shall assign a value of TRUE to the tp15638DrivingWithoutValidCard variable if at least one driving without an appropriate card event has been recorded in the VU within the last 10 days as defined in Annex IC. 1 (TRUE): if the most recent driving without an appropriate card event ended within the last 10 days or is still ongoing; 0 (FALSE): in any other case. tp15638DrivingWithoutValidCard BOOLEAN, RTM4 Valid Driver Card The VU shall generate a Boolean value for data element RTM4 tp15638DriverCard on the basis of the inserted valid driver card in the driver slot. 1 (TRUE): if no valid driver card is present in the driver slot of the VU; 0 (FALSE): if a valid driver card is present in the driver slot of the VU. tp15638DriverCard BOOLEAN, RTM5 Card Insertion while Driving The VU shall generate a Boolean value for data element RTM5 tp15638CardInsertion. The VU shall assign a value of TRUE to the tp15638CardInsertion variable if at least one card insertion while driving event has been recorded in the VU within the last 10 days as defined in Annex IC. 1 (TRUE): if the most recent card insertion while driving event has occurred within the last 10 days; 0 (FALSE): in any other case. tp15638CardInsertion BOOLEAN, RTM6 Motion Data Error The VU shall generate a Boolean value for data element RTM6. The VU shall assign a value of TRUE to the tp15638MotionDataError variable if at least one motion data error event has been recorded in the VU within the last 10 days as defined in Annex IC. 1 (TRUE): if the most recent motion data error event ended within the last 10 days or is still ongoing; 0 (FALSE): in any other case. tp15638MotionDataError BOOLEAN, RTM7 Vehicle Motion Conflict The VU shall generate a Boolean value for data element RTM7. The VU shall assign a value of TRUE to the tp15638VehicleMotionConflict variable if at least one vehicle motion conflict event has been recorded in the VU within the last 10 days. 1 (TRUE): if the most recent vehicle motion conflict event ended within the last 10 days or is still ongoing; 0 (FALSE): in any other case. tp15638VehicleMotionConflict BOOLEAN, RTM8 2nd Driver Card The VU shall generate a Boolean value for data element RTM8 on the basis of Annex IC (Driver Activity Data CREW and CO-DRIVER). If a valid co-driver card is present the VU shall set the value of RTM8 to TRUE. 1 (TRUE): if a valid co-driver card is present in the VU; 2 (FALSE): if no valid co-driver card is present in the VU. tp156382ndDriverCard BOOLEAN, RTM9 Current Activity The VU shall generate a Boolean value for data element RTM9. If the current activity is recorded in the VU as any activity other than DRIVING as defined in Annex IC the VU shall set the value of RTM9 to TRUE. 1 (TRUE): other activity selected; 0 (FALSE): driving selected tp15638CurrentActivityDriving BOOLEAN RTM10 Last Session Closed The VU shall generate a Boolean value for data element RTM10. If the last card session was not properly closed as defined in Annex IC the VU shall set the value of RTM10 to TRUE. 1 (TRUE): at least one of the inserted cards has triggered a last card session not correctly closed event; 0 (FALSE): None of the inserted cards has triggered a last card session not correctly closed event. tp15638LastSessionClosed BOOLEAN RTM11 Power Supply Interruption The VU shall generate an integer value for data element RTM11. The VU shall assign a value for the tp15638PowerSupplyInterruption variable equal to the number of the recorded power supply interruption events stored in the VU within last 10 days as defined in Annex IC. If no power supply interruption event has been recorded in the VU within the last 10 days, it shall set the value of RTM11 to 0. Number of the recorded power supply interruption events within the last 10 days. tp15638PowerSupplyInterruption INTEGER (0..127), RTM12 Sensor Fault The VU shall generate an integer value for data element RTM12. The VU shall assign to the variable sensorFault a value of: — 1 if an event of type ‘35’H Sensor — fault ended during the last 10 days or is still ongoing. — 2 if an event of type GNSS receiver fault (either internal or external with enum values ‘36’H or — ‘37’H) ended during the last 10 days or is still ongoing. — 3 if an event of type ‘0E’H Communication error with the external GNSS facility event ended during the last 10 days or is still ongoing. — 4 If both Sensor Fault and GNSS receiver faults ended during the last 10 days or are still ongoing. — 5 If both Sensor Fault and Communication error with the external GNSS facility event ended during the last 10 days or are still ongoing. — 6 If both GNSS receiver fault and Communication error with the external GNSS facility event ended during the last 10 days or are still ongoing. — 7 If all three sensor faults ended during the last 10 days or are still ongoing. If no event have ended during the last 10 days or is still ongoing, the VU shall set the value of RTM12 to 0. --sensor fault one octet as per data dictionary tp15638SensorFault INTEGER (0..255), RTM13 Time Adjustment The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM13 on the basis of the presence of Time Adjustment data as defined in Annex IC. The VU shall set the value of RTM13 to the time at which the last time adjustment data event has occurred. If no time adjustment event as defined in Annex IC is present in the VU data, it shall set the value of RTM13 to 0. oldTimeValue of the most recent time adjustment. tp15638TimeAdjustment INTEGER(0..4294967295), RTM14 Security Breach Attempt The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM14 on the basis of the presence of a security breach attempt event as defined in Annex IC. The VU shall set the value of the time of the latest security breach attempt event recorded by the VU. If no security breach attempt event as defined in Annex IC is present in the VU data, it shall set the value of RTM14 to 0. Beginning time of the latest stored security breach attempt event. tp15638LatestBreachAttempt INTEGER(0..4294967295), RTM15 Last Calibration The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM15 on the basis of the presence of Last Calibration data as defined in Annex IC and Appendix 1. The VU shall set the value of RTM15 to the oldTimeValue of the latest calibration record. If there has been no calibration, the VU shall set the value of RTM15 to 0. oldTimeValue of the most recent calibration record. tp15638LastCalibrationData INTEGER(0..4294967295), RTM16 Previous Calibration The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM16 on the basis of the calibration record preceding the last calibration. The VU shall set the value of RTM16 to the oldTimeValue of the calibration record preceding the last calibration. If there has been no previous calibration, the VU shall set the value of RTM16 to 0. oldTimeValue of the calibration record preceding the most recent calibration record. tp15638PrevCalibrationData INTEGER(0..4294967295), RTM17 Date Tachograph Connected The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM17. The VU shall set the value of RTM17 to the date of first calibration of the VU in the current vehicle. The VU shall extract this data from the VuCalibrationData (Appendix 1) from the vuCalibrationRecords with CalibrationPurpose equal to: ‘03’H If there has been no previous calibration, the VU shall set the value of RTM17 to 0. Date of first calibration of the VU in the current vehicle. tp15638DateTachoConnected INTEGER(0..4294967295), RTM18 Current Speed The VU shall generate an integer value for data element RTM18. The VU shall set the value of RTM18 to the last current recorded speed at the time of the latest update of the RtmData. Last current recorded speed tp15638CurrentSpeed INTEGER (0..255), RTM19 Timestamp The VU shall generate an integer value for data element RTM19 (timeReal from Appendix 1). The VU shall set the value of RTM19 to the time of the latest update of the RtmData. Timestamp of current TachographPayload record tp15638Timestamp INTEGER(0..4294967295), RTM20 Time at which the latest authenticated vehicle position was available 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 authenticated vehicle position was available from the GNSS receiver. If no authenticated vehicle position was available ever from the GNSS receiver the VU shall set the value of RTM20 to 0. Timestamp of the latest authenticated vehicle position tp15638LatestAuthenticatedPosition INTEGER(0..4294967295), RTM21 Continuous driving time The VU shall generate an integer value for data element RTM21. The VU shall set the value of RTM21 to the ongoing continuous driving time of the driver. Continuous driving time of the driver, encoded as an integer value. Length: 1 byte Resolution: 2 minutes/bit No offset Data range: 0 to 250 A value of 250 shall indicate that the continuous driving time of the driver is equal or greater than 500 minutes. Values 251 to 254 are not used. Value 255 indicates that the information is not available. tp15638ContinuousDrivingTime INTEGER(0..255), RTM22 Longest daily driving time for the ongoing and previous RTM-shift, calculated in accordance with the Addendum to Appendix 14 The VU shall generate an integer value for data element RTM22. The VU shall set the value of RTM22 to the longer of the two daily driving times of the driver, being either the ongoing or the previous RTM-shift. Daily driving time of the driver, encoded as an integer value. Length: 1 byte Resolution: 4 minutes/bit No offset Data range: 0 to 250 A value of 250 shall indicate that the daily driving time of the driver is equal or greater than 1 000 minutes. Values 251 to 254 are not used. Value 255 indicates that the information is not available. tp15638DailyDrivingTimeShift INTEGER(0..255), RTM23 Longest daily driving time within the ongoing week, calculated in accordance with the Addendum to Appendix 14 The VU shall generate an integer value for data element RTM23. The VU shall set the value of RTM23 to the longest daily driving time of the driver, being either the ongoing RTM-shift or any completed RTM-shift having started or finished in the ongoing week. Daily driving time of the driver, encoded as an integer value. Length: 1 byte Resolution: 4 minutes/bit No offset Data range: 0 to 250 A value of 250 shall indicate that the daily driving time of the driver is equal or greater than 1 000 minutes. Values 251 to 254 are not used. Value 255 indicates that the information is not available. tp15638DailyDrivingTimeWeek INTEGER(0..255), RTM24 Weekly driving time, calculated in accordance with the Addendum to Appendix 14 The VU shall generate an integer value for data element RTM24. The VU shall set the value of RTM24 to the weekly driving time of the driver. Weekly driving time of the driver, encoded as an integer value. Length: 1 byte Resolution: 20 minutes/bit No offset Data range: 0 to 250 A value of 250 shall indicate that the weekly driving time of the driver is equal or greater than 5 000 minutes. Values 251 to 254 are not used. Value 255 indicates that the information is not available. tp15638WeeklyDrivingTime INTEGER(0..255), RTM25 Fortnightly driving time, calculated in accordance with the Addendum to Appendix 14 The VU shall generate an integer value for data element RTM25. The VU shall set the value of RTM25 to the fortnightly driving time of the driver. Fortnightly driving time of the driver, encoded as an integer value. Length: 1 byte Resolution: 30 minutes/bit No offset Data range: 0 to 250 A value of 250 shall indicate that the fortnightly driving time of the driver is equal or greater than 7 500 minutes. Values 251 to 254 are not used. Value 255 indicates that the information is not available. tp15638FortnightlyDrivingTime INTEGER(0..255), Note: RTM22, RTM23, RTM24 and RTM25 shall be computed according to the Addendum to this Appendix’; (iii) in point 5.4.7, Table 14.9 is replaced by the following: ‘Table 14.9 Initialisation – VST frame contents example Octet # Attribute/Field Bits in octet Description 1 FLAG 0111 1110 Start flag 2 Private LID xxxx xxxx Link address of the specific DSRC-VU 3 xxxx xxxx 4 xxxx xxxx 5 xxxx xxxx 6 MAC Control field 1100 0000 Command PDU 7 LLC Control field 0000 0011 UI command 8 Fragmentation header 1xxx x001 No fragmentation 9 VST SEQUENCE { Fill BIT STRING (SIZE(4)) 1001 Initialisation response 0000 Unused and set to 0 10 Profile INTEGER (0..127,...) Applications SEQUENCE OF { 0000 0000 No extension. Example profile 0 No extension, 1 application 11 0000 0001 12 SEQUENCE { OPTION indicator OPTION indicator AID DSRCApplicationEntityID 1 EID present 1 Parameter present 00 0010 No extension. AID= 2 Freight&Fleet 13 EID Dsrc-EID xxxx xxxx Defined within the OBU and identifying the application instance. 14 Parameter Container { 0000 0010 No extension, Container Choice = 02, Octet string 15 0000 0110 No extension, Rtm Context Mark length = 6 16 Rtm-ContextMark ::= SEQUENCE { StandardIdentifier 0000 0101 First octet is 05H, which is its length. Subsequent 5 octets encode the Object Identifier of the supported standard, part and version. {ISO (1) Standard (0) TARV (15638) part9(9) Version2 (2)} 17 standardIdentifier 0010 1000 18 1111 1010 19 0001 0110 20 0000 1001 21 0000 0010 22 ObeConfiguration Sequence { OPTION indicator 0 ObeStatus not present EquipmentClass INTEGER (0..32767) xxx xxxx This field shall be used to carry 23 xxxx xxxx manufacturer’s indications about the software/hardware version of the DSRC interface 24 ManufacturerId INTEGER (0..65535) xxxx xxxx Manufacturer identifier for the DSRC-VU as described in ISO 14816 Register 25 xxxx xxxx 26 FCS xxxx xxxx Frame check sequence 27 xxxx xxxx 28 Flag 0111 1110 End Flag ’; (iv) the following point 5.5 is inserted: ‘5.5 Reserved for future use’; (v) in point 5.7, paragraphs DSC_77 and DSC_78 are replaced by the following: ‘DSC_77 The Data shall be provided, already secured, by the VUSM function to the DSRC-VU. The VUSM shall verify that data recorded in the DSRC-VU has been transmitted successfully to the DSRC-VU. The recording and reporting of any errors in the transfer of data from the VU to the memory of the DSRC-VU shall be recorded with type EventFaultType and enum value set to ‘0C’H Communication error with the remote communication facility event together with the timestamp. The VUSM shall verify that the data has been transmitted successfully to the DSRC-VU. DSC_78 Reserved for future use.’; (d) the following addendum is added: 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. 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. 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:

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.

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.

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.

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. 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 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 Figure 5.

Example of a daily rest period interrupted more than twice causing rest period H not to be included in the computation Figure 6.

Example of a daily rest period where Ferry/Train Calculation period is commenced at end of work period Figure 7.

Example of a daily rest period interrupted more than twice causing rest period B not to be included in the computation Figure 8.

Example of a split daily rest period interrupted once during the first rest period and once during 2^nd 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.

(40) Appendix 15 is amended as follows: (a) the header is replaced by the following: Appendix 15

MIGRATION: MANAGING THE CO-EXISTENCE OF EQUIPMENT GENERATIONS AND VERSIONS; (b) the Table of Content is amended as follows: (i) point 2.2 is replaced by the following: ‘2.2. Interoperability between VU and cards’; (ii) the following point 5 is added: ‘5. RECORDING OF BORDER CROSSINGS IN FIRST GENERATION AND FIRST VERSION OF SECOND GENERATION TACHOGRAPHS’; (c) points 2 to 4 are replaced by the following: ‘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.

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.

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.’; (d) the following point 5 is added: ‘5. 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.’;

(41) in appendix 16, paragraph ADA_012 is replaced by the following: ‘ADA_012 The 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.’