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)

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 [^E0003] Control card Workshop card Company card Control card Control card Control card Control card [^E0002] Not available Not available Workshop card Workshop card Workshop card Not available Workshop card [^E0002] Not available Company card Company card Company card Not available Not available Company card [^E0002] (¹) 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: ‘ Image omitted; see official source ’;
• (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. Image omitted; see official source Figure 1.

Example of daily rest period interrupted due to ferry/train crossing - (i) ‘reduced daily rest period’ is a continuous rest period of at least 9 hours and less than 11 hours; - (j) ‘split daily rest period’ is a daily rest period taken in two parts: - — the first part shall be a continuous rest period of at least 3 hours and less than 9, - — the second part shall be a continuous rest period of at least 9 hours. As a matter of exception, when a FERRY/TRAIN CROSSING condition is active during one or both of the parts of a split daily rest period, the split daily rest period may be interrupted a maximum of two times by other activities with the accumulated duration of maximal one hour, i.e.: - — the first part of the split daily rest period may be interrupted one or two times, or - — the second part of the split daily rest period may be interrupted one or two times, or - — the first part of the split daily rest period may be interrupted one time and the second part of the split daily rest period may be interrupted one time. The VU shall then compute a split daily rest period when the accumulated rest time computed according to point 3 is: - — at least three hours and less than 11 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has been interrupted by FERRY/TRAIN CROSSING. - — at least three hours and less than 9 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has not been interrupted by FERRY/TRAIN CROSSING. Image omitted; see official source Figure 2.

Example of split daily rest period interrupted due to ferry/train crossing When the split daily rest period is interrupted, the VU: - — shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and - — shall start a new RTM-shift at the end of the split daily rest period that has been interrupted; - (k) ‘week’ is the period in UTC time between 00:00 hours on Monday and 24:00 hours on Sunday; 3.Computation of the rest period when it has been interrupted due to ferry/train crossing For the computation of the rest period when it has been interrupted due to ferry/train crossing, the VU shall calculate the accumulated rest time according to the following steps: - a) Step 1 The VU shall detect interruptions to the rest time occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag, according to figure 3 and in its case figure 4, and shall evaluate for each interruption detected if the following conditions are met: - — the interruption makes the total duration of the interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to exceed more than one hour in total, - — the interruption makes the total number of interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to be bigger than two, - — there is an ‘Entry of place where daily work periods end’ stored after the interruption ended. If none of the above conditions are met, the continuous rest period immediately preceding the interruption shall be added to the accumulated rest time. If at least one of the above conditions is met, the VU shall either stop the computation of the accumulated rest time according to step 2 or detect interruptions to the rest time occurring after the FERRY/TRAIN CROSSING (BEGIN) flag according to step 3. - b) Step 2 For each interruption detected according to step 1, the VU shall evaluate whether the computation of the accumulated rest time should stop. The VU shall stop the computation process when two continuous rest periods occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag have been added to the accumulated rest time, including in its case rest periods added in the first part of a split daily rest period also interrupted by ferry/train crossing. Otherwise, the VU shall proceed according to step 3. - c) Step 3 If after performance of step 2 the VU continues the computation of the accumulated rest time, the VU shall detect interruptions occurring after the deactivation of the FERRY/TRAIN CROSSING condition according to figure 3 and in its case figure 4. For each interruption found, the VU shall evaluate if the interruption makes the accumulated time of all the interruptions detected to exceed more than one hour in total, in which case the computation of the accumulated rest period shall finish at the end of the continuous rest period previous to the interruption. Otherwise, the continuous rest periods occurring after the respective interruptions shall be added to the computation of the daily rest period until the condition in step 4 is fulfilled. - d) Step 4 The computation of the accumulated rest time shall stop when the VU has added, as result of steps 1 and 3, a maximum of two continuous rest periods to the rest period for which the FERRY/TRAIN CROSSING condition is activated, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing. Image omitted; see official source Figure 3.

Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as regular daily rest period or as the first part of a split daily rest period Image omitted; see official source Figure 4.

Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as the second part of a split daily rest period Image omitted; see official source Figure 5.

Example of a daily rest period interrupted more than twice causing rest period H not to be included in the computation Image omitted; see official source Figure 6.

Example of a daily rest period where Ferry/Train Calculation period is commenced at end of work period Image omitted; see official source Figure 7.

Example of a daily rest period interrupted more than twice causing rest period B not to be included in the computation Image omitted; see official source Figure 8.

Example of a split daily rest period interrupted once during the first rest period and once during 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. - 3. MAIN STEPS DURING THE PERIOD BEFORE THE INTRODUCTION DATE MIG_017 Test keys and certificates shall be available to manufacturers at the publication date of this Annex. MIG_018 Interoperability tests shall be ready to start with version 2 of vehicle units and version 2 of tachograph cards if requested by manufacturers at the latest 15 months before the introduction date. MIG_019 For version 2 of generation 2 tachographs, tachograph cards and motion sensors, the same keys and certificates are used as for generation 2 version 1 equipment. MIG_020 Member States shall be able to issue version 2 of second generation workshop cards at the latest 1 month before the introduction date. MIG_021 Member States shall be able to issue all other types of version 2 of second generation tachograph cards at the latest 1 month before the introduction date. - 4. PROVISIONS FOR THE PERIOD AFTER THE INTRODUCTION DATE MIG_022 With effect from the introduction date, Member States shall only issue version 2 of second generation tachograph cards. MIG_023 Vehicle units / motion sensors manufacturers shall be allowed to produce first generation vehicle units / motion sensors as long as they are used in the field, so that malfunctioning components can be replaced. MIG_023a With effect from the introduction date, malfunctioning version 1 of second generation vehicle units or external GNSS facilities shall be replaced with version 2 of second generation vehicle units or external GNSS facilities. MIG_024 Vehicle units / motion sensors manufacturers shall be allowed to request and obtain type approval maintenance of first generation vehicle units / motion sensors types or version 1 of second generation vehicle units already type approved.’; - (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.’