Legalize / European Union / Implementing Regulation

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)

Type Implementing Regulation

Publication 2021-07-16

Last updated 2023-08-21

State In force

Department European Commission, MOVE

Source EUR-Lex

articles 2

Reform history JSON API

(30) Appendix 1 is amended as follows: (a) the Table of Content is amended as follows: (i) the following points 2.11a and 2.11b are inserted: ‘2.11a. CardBorderCrossing 2.11b. CardBorderCrossingRecord’; (ii) the following points 2.24a, 2.24b, 2.24c and 2.24d are inserted: ‘2.24a. CardLoadTypeEntries 2.24b. CardLoadTypeEntryRecord 2.24c. CardLoadUnloadOperations 2.24d. CardLoadUnloadRecord’; (iii) the following point 2.26a is inserted: ‘2.26a. CardPlaceAuthDailyWorkPeriod’; (iv) the following point 2.48a is inserted: ‘2.48a. CompanyCardApplicationIdentificationV2’; (v) the following point 2.50a is inserted: ‘2.50a. ControlCardApplicationIdentificationV2’; (vi) the following point 2.60a is inserted: ‘2.60a. DownloadInterfaceVersion’; (vii) the following point 2.61a is inserted: ‘2.61a. DriverCardApplicationIdentificationV2’; (viii) the following points 2.79a, 2.79b and 2.79c are inserted: ‘2.79a. GNSSAuthAccumulatedDriving 2.79b. GNSSAuthStatusADRecord 2.79c. GNSSPlaceAuthRecord’; (ix) point 2.84 is replaced by the following: ‘2.84. Reserved for future use’; (x) the following point 2.89a is inserted: ‘2.89a. LengthOfFollowingData’; (xi) the following point 2.90a is inserted: ‘2.90a. LoadType’; (xii) the following point 2.101a is inserted: ‘2.101a. NoOfBorderCrossingRecords’; (xiii) the following point 2.111a is inserted: ‘2.111a. NoOfLoadUnloadRecords’; (xiv) the following point 2.112a is inserted: ‘2.112a. NoOfLoadTypeEntryRecords’; (xv) the following point 2.114a is inserted: ‘2.114a. OperationType’; (xvi) the following points 2.116a and 2.116b are inserted: ‘2.116a. PlaceAuthRecord 2.116b. PlaceAuthStatusRecord’; (xvii) the following point 2.117a is inserted: ‘2.117a. PositionAuthenticationStatus’; (xviii) the following point 2.158a is inserted: ‘2.158a. TachographCardsGen1Suppression’; (xix) the following point 2.166a is inserted: ‘2.166a. VehicleRegistrationIdentificationRecordArray’; (xx) the following point 2.185a is inserted: ‘2.185a. VuConfigurationLengthRange’; (xxi) the following point 2.192a is inserted: ‘2.192a. VuDigitalMapVersion’; (xxii) the following points 2.203a and 2.203b are inserted: ‘2.203a. VuBorderCrossingRecord 2.203b. VuBorderCrossingRecordArray’; (xxiii) the following point 2.204a is inserted: ‘2.204a. VuGnssMaximalTimeDifference’; (xxiv) the following points 2.208a and 2.208b are inserted: ‘2.208a. VuLoadUnloadRecord 2.208b. VuLoadUnloadRecordArray’; (xxv) the following point 2.222a is inserted: ‘2.222a. VuRtcTime’; (xxvi) the following points 2.234a, 2.234b and 2.234c are inserted: ‘2.234a. WorkshopCardApplicationIdentificationV2 2.234b. WorkshopCardCalibrationAddData 2.234c. WorkshopCardCalibrationAddDataRecord’; (b) in point 2, the text before point 2.1 is replaced by the following: ‘For any of the following data types, the default value for an ‘unknown’ or a ‘not applicable’ content will consist in filling the data element with Hex ‘FF’ bytes, unless otherwise specified. All data types are used for Generation 1 and Generation 2 applications unless otherwise specified. Data types only used for Generation 2, version 2 applications are indicated. For card data types used for Generation 1 and Generation 2 applications, the size specified in this Appendix is the one for Generation 2 application. The size for Generation 1 application is supposed to be already known by the reader. The Annex IC requirement numbers related to such data types cover both Generation 1 and Generation 2 applications. Card data types not defined for Generation 1 cards are not stored in Generation 1 application of Generation 2 cards. In particular: — Type approval numbers stored in Generation 1 application of Generation 2 cards are truncated to the 8 first characters where needed, — Only the ‘FERRY / TRAIN CROSSING begin’ of a ‘FERRY / TRAIN CROSSING’ specific condition is stored in Generation 1 application of Generation 2 cards.’; (c) the following points 2.11a and 2.11b are inserted: ‘2.11a. CardBorderCrossings Generation 2, version 2: Information, stored in a driver or workshop card, related to the border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirements 306f and 356f). borderCrossingPointerNewestRecord is the index of the last updated card border crossing record. Value assignment is the number corresponding to the numerator of the card border crossing record, beginning with ‘0’ for the first occurrence of the card border crossing record in the structure. cardBorderCrossingRecords is the set of card border crossing records. 2.11b. CardBorderCrossingRecord Generation 2, version 2: Information, stored in a driver or workshop card, related to the border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirements 147b, 306e and 356e). countryLeft is the country which was left by the vehicle, or ‘no information available’ according to Annex IC requirement 147b. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps). countryEntered is the country into which the vehicle has entered, or the country in which the vehicle is located at card insertion time. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps). gnssPlaceAuthRecord contains information related to the position of the vehicle, when the vehicle unit has detected that the vehicle has crossed the border of a country, or ‘no information available’ according to requirement 147b of Annex IC, and its authentication status. vehicleOdometerValue is the odometer value when the vehicle unit has detected that the vehicle has crossed the border of a country, or ‘no information available’ according to requirement 147b of Annex IC.’; (d) the following points 2.24a, 2.24b, 2.24c and 2.24d are inserted: ‘2.24a. CardLoadTypeEntries Generation 2, version 2: Information, stored in a driver or workshop card, related to the load type entries when the card is inserted in a vehicle unit (Annex IC requirements 306j and 356j). loadTypeEntryPointerNewestRecord is the index of the last updated card load type entry record. Value assignment: number corresponding to the numerator of the card load type entry record, beginning with '0' for the first occurrence of the card load type entry record in the structure. cardLoadTypeEntryRecords is the set of records containing the date and time of the entry and the load type entered. 2.24b. CardLoadTypeEntryRecord Generation 2, version 2: Information, stored in a driver or workshop card, related to the load type changes entered when the card is inserted in a vehicle unit (Annex IC requirements 306i and 356i). timeStamp is the date and time when the load type was entered. loadTypeEntered is the load type entered. 2.24c. CardLoadUnloadOperations Generation 2, version 2: Information, stored in a driver or workshop card, related to load/unload operations of the vehicle (Annex IC requirements 306h and 356h). loadUnloadPointerNewestRecord is the index of the last updated card load/unload record. Value assignment: is the number corresponding to the numerator of the card load/unload record, beginning with '0' for the first occurrence of the card load/unload record in the structure. cardLoadUnloadRecords is the set of records containing the indication of the type of operation performed (load, unload, or simultaneous load and unload), the date and time the load/unload operation has been entered, information about the position of the vehicle, and the vehicle odometer value. 2.24d. CardLoadUnloadRecord Generation 2, version 2: Information, stored in a driver or workshop card, related to load/unload operations of the vehicle (Annex IC requirements 306g and 356g). timeStamp is the date and time at the beginning of the load/unload operation. operationType is the type of operation entered (load, unload, or simultaneous load/unload). gnssPlaceAuthRecord contains information related to the position of the vehicle. vehicleOdometerValue is the odometer value related to the beginning of the load/unload operation.’; (e) the following point 2.26a is inserted: ‘2.26a. CardPlaceAuthDailyWorkPeriod Generation 2, version 2: Information, stored in a driver or a workshop card, providing the authentication status of places where daily work periods begin and/or end (Annex IC requirements 306b and 356b). placeAuthPointerNewestRecord is the index of the last updated place authentication status record. Value assignment: Number corresponding to the numerator of the place authentication status record, beginning with ‘0’ for the first occurrence of the place authentication status records in the structure. placeAuthStatusRecords is the set of records containing the place authentication status of the places entered.’; (f) in point 2.36, the text corresponding to the value assignment ‘bbH’ is replaced by the following: ‘ ‘bb’H Index for changes concerning the use of the data elements defined for the structure given by the high byte. ‘00’H for Generation 1 applications ‘00’H for version 1 of Generation 2 applications ‘01’H for version 2 of Generation 2 applications’; (g) in point 2.40, the paragraph between the header and the code is replaced by the following: ‘Generation 2: Information, stored in a driver or workshop card, related to the vehicle units used by the card holder (Annex IC requirements 304 and 352).’; (h) the following point 2.48a is inserted: ‘2.48a. CompanyCardApplicationIdentificationV2 Generation 2, version 2: Information, stored in a company card related to the identification of the application of the card (Annex IC requirement 375a). lengthOfFollowingData is the number of bytes following in the record. vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’; (i) the following point 2.50a is inserted: ‘2.50a. ControlCardApplicationIdentificationV2 Generation 2, version 2: Information, stored in a control card related to the identification of the application of the card (Annex IC requirement 363a). lengthOfFollowingData is the number of bytes following in the record. vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’; (j) the following point 2.60a is inserted: ‘2.60a. DownloadInterfaceVersion Generation 2, version 2: Code indicating the version of the download interface of a vehicle unit. Value assignment: ‘aabb’H: ‘aa’H ‘00’H: not used, ‘01’H: Generation 2 vehicle unit, ‘bb’H ‘00’H: not used, ‘01’H: version 2 of Generation 2 vehicle unit.’; (k) the following point 2.61a is inserted: ‘2.61a. DriverCardApplicationIdentificationV2 Generation 2, version 2: Information, stored in a driver card related to the identification of the application of the card (Annex IC requirement 278a). lengthOfFollowingData is the number of bytes following in the record. noOfBorderCrossingRecords is the number of border crossing records the driver card can store. noOfLoadUnloadRecords is the number of load/unload records the driver card can store. noOfLoadTypeEntryRecords is the number of load type entry records the driver card can store. vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’; (l) point 2.63 is replaced by the following: ‘2.63. DSRCSecurityData Generation 2: For the definition of this data type, see Appendix 11.’; (m) in point 2.66, the text corresponding to generation 2 is replaced by the following: ‘Generation 2 Value assignment: according to ISO/IEC8824-1.’; (n) point 2.70 is amended as follows: (i) the header corresponding to Generation 2 is replaced by the following: ‘Generation 2, version 1:’; (ii) the following text is added: ‘Generation 2, version 2: ‘0x’H General events, ‘00’H No further details, ‘01’H Insertion of a non valid card, ‘02’H Card conflict, ‘03’H Time overlap, ‘04’H Driving without an appropriate card, ‘05’H Card insertion while driving, ‘06’H Last card session not correctly closed, ‘07’H Over speeding, ‘08’H Power supply interruption, ‘09’H Motion data error, ‘0A’H Vehicle Motion Conflict, ‘0B’H Time conflict (GNSS versus VU internal clock), ‘0C’H Communication error with the remote communication facility, ‘0D’H Absence of position information from GNSS receiver, ‘0E’H Communication error with the external GNSS facility, ‘0F’H GNSS anomaly, ‘1x’H Vehicle unit related security breach attempt events, ‘10’H No further details, ‘11’H Motion sensor authentication failure, ‘12’H Tachograph card authentication failure, ‘13’H Unauthorised change of motion sensor, ‘14’H Card data input integrity error, ‘15’H Stored user data integrity error, ‘16’H Internal data transfer error, ‘17’H Unauthorised case opening, ‘18’H Hardware sabotage, ‘19’H Tamper detection of GNSS, ‘1A’H External GNSS facility authentication failure, ‘1B’H External GNSS facility certificate expired, ‘1C’H Inconsistency between motion data and stored driver activity data, ‘1D’H to ‘1F’H RFU, ‘2x’H Sensor related security breach attempt events, ‘20’H No further details, ‘21’H Authentication failure, ‘22’H Stored data integrity error, ‘23’H Internal data transfer error, ‘24’H Unauthorised case opening, ‘25’H Hardware sabotage, ‘26’H to ‘2F’H RFU, ‘3x’H Recording equipment faults, ‘30’H No further details, ‘31’H VU internal fault, ‘32’H Printer fault, ‘33’H Display fault, ‘34’H Downloading fault, ‘35’H Sensor fault, ‘36’H Internal GNSS receiver, ‘37’H External GNSS facility, ‘38’H Remote communication facility, ‘39’H ITS interface, ‘3A’H Internal Sensor Fault, ‘3B’H to ‘3F’H RFU, ‘4x’H Card faults, ‘40’H No further details, ‘41’H to ‘4F’H RFU, ‘50’H to ‘7F’H RFU, ‘80’H to ‘FF’H Manufacturer specific.’; (o) point 2.71 is replaced by the following: ‘2.71. ExtendedSealIdentifier Generation 2: The extended seal identifier uniquely identifies a seal (Annex IC requirement 401). manufacturerCode is a code of the manufacturer of the seal. Value assignment: see database registration to be managed by the European Commission (see https://dtc.jrc.ec.europa.eu). sealIdentifier is an identifier for the seal which is unique for the manufacturer. Value assignment: alpha-numeric number, unique in the manufacturer domain according to [ISO8859-1].’; (p) in point 2.76, the paragraph between the header and the code is replaced by the following: ‘Generation 2: The geo-coordinates are encoded as integers. These integers are multiples of the ±DDMM.M encoding for the latitude and ±DDDMM.M for the longitude. Here ±DD respectively ±DDD denotes the degrees and MM.M the minutes. Longitude and latitude of an unknown position shall be represented as Hex ‘7FFFFF’ (Decimal 8388607).’; (q) the following points 2.79a, 2.79b and 2.79c are inserted: ‘2.79a. GNSSAuthAccumulatedDriving Generation 2, version 2: Information, stored in a driver or workshop card, providing the authentication status of GNSS positions of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirements 306d and 356d). gnssAuthADPointerNewestRecord is the index of the last updated GNSS position authentication status record. Value assignment is the number corresponding to the numerator of the GNSS position authentication status record, beginning with '0' for the first occurrence of the GNSS position authentication status record in the structure. gnssAuthStatusADRecords is the set of records containing the date and time the accumulated driving reaches a multiple of three hours and the authentication status of the GNSS position. 2.79b. GNSSAuthStatusADRecord Generation 2, version 2: Information, stored in a driver or workshop card, providing the authentication status of a GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirements 306c and 356c). Other information related to the GNSS position itself is stored in another record (see 2.79 GNSSAccumulatedDrivingRecord). timeStamp is the date and time when the accumulated driving time reaches a multiple of three hours (which is the same date and time as in the corresponding GNSSAccumulatedDrivingRecord). authenticationStatus is the authentication status of the GNSS position when the accumulated driving time reaches a multiple of three hours. 2.79c. GNSSPlaceAuthRecord Generation 2, version 2: Information related to the GNSS position of the vehicle (Annex IC requirements 108, 109, 110, 296, 306a, 306c, 306e, 306g, 356a, 356c, 356e and 356g). timeStamp is the date and time when the GNSS position of the vehicle was determined. gnssAccuracy is the accuracy of the GNSS position data. geoCoordinates is the recorded location using GNSS. authenticationStatus is the authentication status of the GNSS position when it was determined.’; (r) point 2.84 is replaced by the following: ‘2.84. Reserved for future use’; (s) the following point 2.89a is inserted: ‘2.89a. LengthOfFollowingData Generation 2, version 2: Length indicator for extensible records. Value assignment: See Appendix 2.’; (t) the following point 2.90a is inserted: ‘2.90a. LoadType Generation 2, version 2: Code identifying a load type entered. Value assignment: ‘00’H Undefined load type, ‘01’H Goods, ‘02’H Passengers, ‘03’H .. ‘FF’H RFU.’; (u) the following point 2.101a is inserted: ‘2.101a. NoOfBorderCrossingRecords Generation 2, version 2: Number of border crossing records a driver or workshop card can store. Value assignment: see Appendix 2.’; (v) the following point 2.111a is inserted: ‘2.111a. NoOfLoadUnloadRecords Generation 2, version 2: Number of load/unload records a card can store. Value assignment: see Appendix 2.’; (w) the following point 2.112a is inserted: ‘2.112a. NoOfLoadTypeEntryRecords Generation 2, version 2: Number of load type entry records a driver or workshop card can store. Value assignment: see Appendix 2.’; (x) the following point 2.114a is inserted: ‘2.114a. OperationType Generation 2, version 2: Code identifying a type of operation entered. Value assignment: ‘00’H RFU, ‘01’H Load operation, ‘02’H Unload operation, ‘03’H Simultaneous load/unload operation, ‘04’H .. ‘FF’H RFU.’; (y) the following points 2.116a and 2.116b are inserted: ‘2.116a. PlaceAuthRecord Information related to a place where a daily work period begins or ends (Annex IC requirements 108, 271, 296, 324 and 347). Generation 2, version 2: entryTime is a date and time related to the entry. entryTypeDailyWorkPeriod is the type of entry. dailyWorkPeriodCountry is the country entered. dailyWorkPeriodRegion is the region entered. vehicleOdometerValue is the odometer value at the time of place entry. entryGNSSPlaceAuthRecord is the recorded location, GNSS authentication status and time. 2.116b. PlaceAuthStatusRecord Generation 2, version 2: Information, stored in a driver or workshop card, providing the authentication status of a place where a daily work period begins or ends (Annex IC requirements 306a and 356a). Other information related to the place itself is stored in another record (see 2.117 PlaceRecord). entryTime is a date and time related to the entry (which is the same date and time as in the corresponding PlaceRecord). authenticationStatus is the authentication status of the recorded GNSS position.’; (z) the following point 2.117a is inserted: ‘2.117a. PositionAuthenticationStatus Generation 2, version 2: Value assignment (see Appendix 12): ‘00’H Not Authenticated (see Appendix 12, requirement GNS_39), ‘01’H Authenticated (see Appendix 12, requirement GNS_39), ‘02’H .. ‘FF’H RFU.’; (aa) in point 2.120, value assignments ‘22’H to ‘7F’H are replaced by the following: ‘‘22’H VuBorderCrossingRecord, ‘23’H VuLoadUnloadRecord, ‘24’H VehicleRegistrationIdentification, ‘25’H to ‘7F’H RFU.’; (bb) the following point 2.158a is inserted: ‘2.158a. TachographCardsGen1Suppression Generation 2, version 2: Ability of a second generation VU to use first generation of driver, control and company cards (see Appendix 15, MIG_002). Value assignment: ‘0000’H The VU is able to use the generation 1 of tachograph cards (default value), ‘A5E3’H The VU is not able to use the tachograph cards generation 1, All other values Not used.’; (cc) the following point 2.166a is inserted: ‘2.166a. VehicleRegistrationIdentificationRecordArray Generation 2, version 2: The Vehicle Registration Identification plus metadata as used in the download protocol. recordType denotes the type of the record (VehicleRegistrationIdentification). Value assignment: see RecordType. recordSize is the size of the VehicleRegistrationIdentification in bytes. noOfRecords is the number of records in the set records. records is the set of vehicle registration identification.’; (dd) in point 2.168, the first line after the header is replaced by the following: ‘Generation 2, version 1:’; (ee) point 2.174 is amended as follows: (i) the header for Generation 2 is replaced by the following: ‘Generation 2, version 1:’; (ii) the following text is added: ‘Generation 2, version 2: In addition to generation 1 the following data element is used: sensorSerialNumber is the serial number of the motion sensor paired with the vehicle unit at the end of the calibration, sensorGNSSSerialNumber is the serial number of the external GNSS facility coupled with the vehicle unit at the end of the calibration (if any), rcmSerialNumber is the serial number of the remote communication facility coupled with the vehicle unit at the end of the calibration (if any), sealDataVu gives information about the seals that are attached to different components of the vehicle. byDefaultLoadType is the by-default load type of the vehicle (only present in version 2). calibrationCountry is the country in which the calibration has been performed. calibrationCountryTimestamp is the date and time when the position used to determine the country in which the calibration has been performed was provided by the GNSS receiver.’; (ff) the following point 2.185a is inserted: ‘2.185a. VuConfigurationLengthRange Generation 2, version 2: Number of bytes in a tachograph card, available to store VU configurations. Value assignment: see Appendix 2.’; (gg) the following point 2.192a is inserted: ‘2.192a. VuDigitalMapVersion Generation 2, version 2: Version of the digital map stored in the vehicle unit (Annex IC requirement 133j). Value assignment: as specified on the dedicated secured website made available by the European Commission (Annex IC requirement 133k).’; (hh) point 2.203 is amended as follows: (i) the header corresponding to Generation 2 is replaced by the following: ‘Generation 2, version 1:’; (ii) the following text is added: ‘Generation 2, version 2: Information, stored in a vehicle unit, related to the GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirement 108, 110). In Generation 2 version 2, instead of gnssPlaceRecord, the gnssPlaceAuthRecord is used, which contains the GNSS authentication status in addition.’; (ii) the following points 2.203a and 2.203b are inserted: ‘2.203a. VuBorderCrossingRecord Generation 2, version 2: Information, stored in a vehicle unit, related to border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirement 133a and 133b). cardNumberAndGenDriverSlot identifies the card including its generation which is inserted in the driver slot. cardNumberAndGenCodriverSlot identifies the card including its generation which is inserted in the co-driver slot. countryLeft is the country which was left by the vehicle, based on the last available position before the border crossing has been detected. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps). countryEntered is the country into which the vehicle has entered. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps). gnssPlaceAuthRecord contains information related to the position of the vehicle when the border crossing was detected, and its authentication status. vehicleOdometerValue is the odometer value when the vehicle unit has detected that the vehicle has crossed the border of a country. 2.203b. VuBorderCrossingRecordArray Generation 2, version 2: Information, stored in a vehicle unit, related to border crossings of the vehicle (Annex IC requirement 133c). recordType denotes the type of the record (VuBorderCrossingRecord). Value assignment: see RecordType. recordSize is the size of the VuBorderCrossingRecord in bytes. noOfRecords is the number of records in the set records. records is a set of border crossing records.’; (jj) the following point 2.204a is inserted: ‘2.204a. VuGnssMaximalTimeDifference Generation 2, version 2: The maximal difference between true time and the VU Real Time Clock time, based on the maximal time drift specified in Annex IC requirement 041, transmitted by the vehicle unit to an external GNSS Facility, see Appendix 12 requirement GNS_3g. ’; (kk) in point 2.205, the text corresponding to Generation 2 is replaced by the following: ‘Generation 2: In addition to generation 1 the following data elements are used: vuGeneration identifies the generation of the vehicle unit. vuAbility provides information whether the VU supports generation 1 tachograph cards or not. vuDigitalMapVersion is the version of the digital map stored in the vehicle unit (only present in version 2).’; (ll) the following points 2.208a and 2.208b are inserted: ‘2.208a. VuLoadUnloadRecord Generation 2, version 2: Information, stored in the vehicle unit, related to a load/unload operation entered (Annex IC requirements 133e, 133f and 133g). timeStamp is the date and time when the load/unload operation was entered. operationType is the type of the operation entered (load, unload, or simultaneous load/unload). cardNumberAndGenDriverSlot identifies the card including its generation which is inserted in the driver slot. cardNumberAndGenCodriverSlot identifies the card including its generation which is inserted in the co-driver slot. gnssPlaceAuthRecord contains information related to the position of the vehicle, and its authentication status. vehicleOdometerValue is the odometer value related to the load/unload operation. 2.208b. VuLoadUnloadRecordArray Generation 2, version 2: Information, stored in a vehicle unit, related to a load/unload operation vehicle entered (Annex IC requirement 133h). recordType denotes the type of the record (VuLoadUnloadRecord).Value Assignment: See RecordType. recordSize is the size of the VuLoadUnloadRecord in bytes. noOfRecords is the number of records in the set records. records is a set of load/unload operation records.’; (mm) point 2.219 is amended as follows: (i) the header for Generation 2 is replaced by the following: ‘Generation 2, version 1:’; (ii) the following text is added: ‘Generation 2, version 2: Information, stored in a vehicle unit, related to a place where a driver begins or ends a daily work period (Annex 1B requirement 087 and Annex 1C requirement 108 and 110). Instead of placeRecord, the generation 2 version 2 data structure makes use of the following data element: placeAuthRecord contains the information related to the place entered, the recorded position, GNSS authentication status and position determination time.’; (nn) the following point is inserted after point 2.222: ‘2.222a. VuRtcTime Generation 2, version 2: The time of the VU RTC clock, transmitted by the VU to an External GNSS Facility, see Appendix 12 requirement GNS_3f. ’; (oo) the following points 2.234a, 2.234b and 2.234c are inserted: ‘2.234a. WorkshopCardApplicationIdentificationV2 Generation 2, version 2: Information, stored in a workshop card related to the identification of the application of the card (Annex IC requirement 330a). lengthOfFollowingData is the number of bytes following in the record. noOfBorderCrossingRecords is the number of border crossing records the workshop card can store. noOfLoadUnloadRecords is the number of load/unload records the workshop card can store. noOfLoadTypeEntryRecords is the number of load type entry records the workshop card can store. vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations. 2.234b. WorkshopCardCalibrationAddData Generation 2, version 2: Information, stored in a workshop card, related to the additional data (i.e. by-default load type) entered during a calibration (Annex IC requirement 356l). calibrationPointerNewestRecord is the index of the last updated calibration additional data record. Value assignment is the number corresponding to the numerator of the calibration additional data record, beginning with '0' for the first occurrence of the calibration additional data record in the structure. workshopCardCalibrationAddDataRecords is the set of records containing the old date and time value, the vehicle identification value and the by-default load type of the vehicle. 2.234c. WorkshopCardCalibrationAddDataRecord Generation 2, version 2: Information, stored in a workshop card, related to the by-default load type entered during a calibration (Annex IC requirement 356k). oldTimeValue is the old value of date and time contained in the corresponding WorkshopCardCalibrationRecord, vehicleIdentificationNumber is the vehicle identification number of the vehicle, also contained in the corresponding WorkshopCardCalibrationRecord, byDefaultLoadType is the by-default load type of the vehicle (only present in version 2). calibrationCountry is the country in which the calibration has been performed, calibrationCountryTimestamp is the date time when the position used to determine this country was provided by the GNSS receiver.’;

(31) Appendix 2 is amended as follows: (a) in point 2.5, the second sub-paragraph in paragraph TCS_09 is replaced by the following: ‘Operation state while executing commands or interfacing with Vehicle Unit,’; (b) point 3 is amended as follows: (i) in point 3.2.1, the fourth indent in paragraph TCS_16 is deleted. (ii) point 3.5.7.2 is amended as follows: (1) paragraph TCS_86 is replaced by the following: ‘TCS_86 The command can be performed in the MF, DF Tachograph and DF Tachograph_G2, see also TCS_34.’; (2) paragraphs TCS_88 and TCS_89 are replaced by the following: ‘TCS_88 For short length APDUs the following provisions apply: the IFD shall use the minimum number of APDUs required to transmit the command payload and transmit the maximum number of bytes in the first command APDU. However any value of ‘Lc’ up to 255 bytes must be supported by the card. TCS_89For extended length APDUs the following provisions apply: if the certificate does not fit into a single APDU, the card shall support command chaining. The IFD shall use the minimum number of APDUs required to transmit the command payload and transmit the maximum number of bytes in the first command APDU. If chaining is needed, any value of ‘Lc’ up to the maximum extended length size indicated must be supported by the card. Note: According to Appendix 11 the card stores the certificate or the relevant contents of the certificate and updates its currentAuthenticatedTime. The response message structure and status words are as defined in TCS_85.’; (iii) in point 3.5.10, the last row of the table in paragraph TCS_101 is replaced by the following: ‘Le 1 ‘00h’ As specified in ISO/IEC 7816-4’ ; (iv) in point 3.5.16, the last row of the table in paragraph TCS_138 is replaced by the following: ‘Le 1 ‘00h’ As specified in ISO/IEC 7816-4’ ; (c) point 4 is amended as follows: (i) in paragraph TCS_141, the second subparagraph is replaced by the following: ‘The maximum and minimum numbers of records are specified in this chapter for the different applications. In version 2 of generation 2 driver and workshop cards, the generation 1 application shall support the maximum number of records specified in TCS_150 and TCS_158.’; (ii) in point 4.2.1, the table in paragraph TCS_150 is amended as follows: (1) the row corresponding to cardIssuingAuthorityName is replaced by the following: ‘ ’; (2) the row corresponding to LastCardDownload is replaced by the following: ‘ ’; (iii) point 4.2.2 is amended as follows: (1) paragraph TCS_152 is replaced by the following: ‘TCS_152 After its personalisation, the driver card application generation 2 shall have the following permanent file structure and file access rules: Notes: — The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary. — EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration and EF Load_Type_Entries are only present in version 2 of the generation 2 driver card. — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 driver card, while it was equal to {01 00} for version 1 of the generation 2 driver card. The following abbreviations for the security condition are used in this table: SC1 ALW OR SM-MAC-G2 SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2 For the Read Binary command with odd INS byte (if supported): NEV’; (2) paragraph TCS_154 is replaced by the following: ‘TCS_154 The driver card application generation 2 shall have the following data structure: ’; (3) in paragraph TCS_155, the table is replaced by the following: ‘ Min Max n1 NoOfEventsPerType 12 12 n2 NoOfFaultsPerType 24 24 n3 NoOfCardVehicleRecords 200 200 n4 NoOfCardPlaceRecords 112 112 n6 CardActivityLengthRange 13776 Bytes (56 days * 117 activity changes) 13776 Bytes (56 days * 117 activity changes) n7 NoOfCardVehicleUnitRecords 200 200 n8 NoOfGNSSADRecords 336 336 n9 NoOfSpecificConditionRecords 112 112 n10 NoOfBorderCrossingRecords 1120 1120 n11 NoOfLoadUnloadRecords 1624 1624 n12 NoOfLoadTypeEntryRecords 336 336 n13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes ’; (iv) point 4.3.2 is amended as follows: (1) paragraph TCS_160 is replaced by the following: ‘TCS_160 After its personalisation, the workshop card application generation 2 shall have the following permanent file structure and file access rules. Notes: — The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary. — EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration and EF Calibration_Add_Data are only present in version 2 of the generation 2 workshop card. — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 workshop card, while it was equal to {01 00} for version 1 of the generation 2 workshop card. The following abbreviations for the security conditions are used in this table: SC1 ALW OR SM-MAC-G2 SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2 For the Read Binary command with odd INS byte (if supported): NEV’; (2) in paragraph TCS_162, the table is replaced by the following: ‘ ’; (3) in paragraph TCS_163, the table is replaced by the following: ‘ Min Max n1 NoOfEventsPerType 3 3 n2 NoOfFaultsPerType 6 6 n3 NoOfCardVehicleRecords 8 8 n4 NoOfCardPlaceRecords 8 8 n5 NoOfCalibrationRecords 255 255 n6 CardActivityLengthRange 492 bytes (1 day * 240 activity changes) 492 bytes (1 day * 240 activity changes) n7 NoOfCardVehicleUnitRecords 8 8 n8 NoOfGNSSADRecords 24 24 n9 NoOfSpecificConditionRecords 4 4 n10 NoOfBorderCrossingRecords 4 4 n11 NoOfLoadUnloadRecords 8 8 n12 NoOfLoadTypeEntryRecords 4 4 n13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes ’; (v) point 4.4.2 is amended as follows: (1) paragraph TCS_168 is replaced by the following: ‘TCS_168 After its personalisation, the control card application generation 2 shall have the following permanent file structure and file access rules. Notes: — the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary, — EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 control card, — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 control card, while it was equal to {01 00} for version 1 of the generation 2 control card. The following abbreviations for the security condition are used in this table: SC1 ALW OR SM-MAC-G2 SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2 For the Read Binary command with odd INS byte (if supported): NEV’; (2) in paragraph TCS_170, the table is replaced by the following: ‘ ’; (3) in paragraph TCS_171, the table is replaced by the following: ‘ Min Max n7 NoOfControlActivityRecords 230 520 n13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes ’; (vi) point 4.5.2 is amended as follows: (1) paragraph TCS_176 is replaced by the following: ‘TCS_176 After its personalisation, the company card application generation 2 shall have the following permanent file structure and file access rules. Notes: — the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary, — EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 company card, — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 company card, while it was equal to {01 00} for version 1 of the generation 2 company card. The following abbreviations for the security condition are used in this table: SC1 ALW OR SM-MAC-G2 SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2 For the Read Binary command with odd INS byte (if supported):NEV’; (2) in paragraph TCS_178, the table is replaced by the following: ‘ ’; (3) in paragraph TCS_179, the table is replaced by the following: ‘ Min Max n8 NoOfCompanyActivityRecords 230 520 n13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes ’;

(32) Appendix 3 is amended as follows: (a) point 1 is amended as follows: (i) the paragraph on specific conditions is replaced by the following: ‘ Specific conditions, manual entries Out of scope Ferry/train crossing Load operation Unload operation Simultaneous load/unload operation Load type: passengers Load type: goods Load type: undefined load type’; (ii) the pictograms for miscellaneous are amended as follows: (1) the security pictogram is replaced by the following: ‘ Security/authenticated data/seals’; (2) the following pictogram is added ‘ Digital map/border crossing’; (b) point 2 is amended as follows: (i) the following pictogram combinations are added to the pictograms for miscellaneous: ‘ Position where the vehicle has crossed the border between two countries Position where a load operation has occurred Position where an unload operation has occurred Position where a simultaneous load/unload operation has occurred’; (ii) the following pictogram combination is added to the pictograms for printouts: ‘ Historic of inserted cards printout’; (iii) the following pictogram combination is added to the pictograms for events: ‘ GNSS anomaly’;

(33) Appendix 4 is amended as follows: (a) in point 1, paragraph PRT_005 is replaced by the following: ‘PRT_005 String data fields are printed left aligned and filled up with spaces to data item length, or truncated to data item length when needed. Names and addresses may be printed in two lines.’; (b) point 2 is amended as follows: (i) the following indents are added after the table and before paragraph PRT_007: ‘- In a data block, the text after ‘pi=’ refers to the corresponding pictogram or pictogram combination defined in Appendix 3, - When printed after the longitude and the latitude of a recorded position, or after the timestamp when the position was determined, the pictogram indicates that this position has been computed from authenticated navigation messages, - * data only available in GEN2 tachographs (all versions), - ** data only available in GEN2 version 2.’; (ii) blocks 2 and 3 are replaced by the following: ‘ In the case where the card is a non-personal card, and holds no card holder surname, the company or workshop or control body name shall be printed instead.’; (iii) before block 4, the sentence preceded by an asterisk is deleted. (iv) the following block is inserted after block 4: ‘ ’; (v) block 5 is replaced by the following: ‘ ’; (vi) before block 6, the sentence preceded by an asterisk is deleted. (vii) the following block is inserted after block 8a: ‘ ’; (viii) block 8.2 is replaced by the following: ‘ ’; (ix) block 10.2 is replaced by the following: ‘ ’; (x) before block 11, the sentence preceded by an asterisk is deleted. (xi) blocks 11.4 and 11.5 are replaced by the following: ‘ ’; (xii) block 14 is replaced by the following: ‘ ’; (xiii) block 15.1 is replaced by the following: ‘ ’; (xiv) blocks 16 and 16.1 are replaced by the following: ‘ 16GNSS identification* ’; (xv) block 17.1 is replaced by the following: ‘ The calibration purpose (p) is a numerical code explaining why these calibration parameters were recorded, coded in accordance with the data element CalibrationPurpose.’; (xvi) block 23 is replaced by the following: ‘ ’; (c) point 3 is amended as follows: (i) in point 3.1, paragraph PRT_008 is replaced by the following: ‘PRT_008 The driver activities from card daily printout shall be in accordance with the following format: ’; (ii) in point 3.2, paragraph PRT_009 is replaced by the following: ‘PRT_009 The driver activities from VU daily printout shall be in accordance with the following format: ’; (iii) in point 3.5, paragraph PRT_012 is replaced by the following: ‘PRT_012 The technical data printout shall be in accordance with the following format: ’; (iv) in point 3.7, paragraph PRT_014 is replaced by the following: ‘PRT_014 The historic of inserted cards printout shall be in accordance with the following format: ’;

(34) Appendix 7 is amended as follows: (a) the Table of Content is amended as follows: (i) points 2.2.6.1 to 2.2.6.5 are replaced by the following: ‘2.2.6.1 Positive Response Transfer Data Download Interface Version 2.2.6.2 Positive Response Transfer Data Overview 2.2.6.3 Positive Response Transfer Data Activities 2.2.6.4 Positive Response Transfer Data Events and Faults 2.2.6.5 Positive Response Transfer Data Detailed Speed’; (ii) the following point is added: ‘2.2.6.6 Positive Response Transfer Data Technical Data’; (b) point 2 is amended as follows: (i) in point 2.2.2, the message structure table and the notes after the table are replaced by the following: ‘ Message Structure Max 4 Bytes Max 255 Bytes 1 Byte Header Data CheckSum IDE -> <- VU FMT TGT SRC LEN SID DS_ / TRTP DATA CS Start Communication Request 81 EE F0

E0 Positive Response Start Communication 80 F0 EE 03 C1

EA, 8F 9B Start Diagnostic Session Request 80 EE F0 02 10 81

F1 Positive Response Start Diagnostic 80 F0 EE 02 50 81

31 Link Control Service Verify Baud Rate (stage 1) 9 600 Bd 80 EE F0 04 87 01 01,01 EC 19 200 Bd 80 EE F0 04 87 01 01,02 ED 38 400 Bd 80 EE F0 04 87 01 01,03 EE 57 600 Bd 80 EE F0 04 87 01 01,04 EF 115 200 Bd 80 EE F0 04 87 01 01,05 F0 Positive Response Verify Baud Rate 80 F0 EE 02 C7 01

28 Transition Baud Rate (stage 2) 80 EE F0 03 87 02 03 ED Request Upload 80 EE F0 0A 35

00,00,00,00,00,FF,FF, FF,FF 99 Positive Response Request Upload 80 F0 EE 03 75

00,FF D5 Transfer Data Request Download interface version 80 EE F0 02 36 00

96 Overview 80 EE F0 02 36 01, 21 or 31

CS Activities 80 EE F0 06 36 02, 22 or 32 Date CS Events & Faults 80 EE F0 02 36 03, 23 or 33 Date CS Detailed Speed 80 EE F0 02 36 04 or 24 Date CS Technical Data 80 EE F0 02 36 05, 25 or 35 Date CS Card download 80 EE F0 02 or 03 36 06 Slot CS Positive Response Transfer Data 80 F0 EE Len 76 TREP Data CS Request Transfer Exit 80 EE F0 01 37

96 Positive Response Request Transfer Exit 80 F0 EE 01 77

D6 Stop Communication Request 80 EE F0 01 82

E1 Positive Response Stop Communication 80 F0 EE 01 C2

21 Acknowledge sub message 80 EE F0 Len 83

Data CS Negative responses General reject 80 F0 EE 03 7F Sid Req 10 CS Service not supported 80 F0 EE 03 7F Sid Req 11 CS Sub function not supported 80 F0 EE 03 7F Sid Req 12 CS Incorrect Message Length 80 F0 EE 03 7F Sid Req 13 CS Conditions not correct or Request sequence error 80 F0 EE 03 7F Sid Req 22 CS Request out of range 80 F0 EE 03 7F Sid Req 31 CS Upload not accepted 80 F0 EE 03 7F Sid Req 50 CS Response pending 80 F0 EE 03 7F Sid Req 78 CS Data not available 80 F0 EE 03 7F Sid Req FA CS Notes: — Sid Req = the Sid of the corresponding request. — TREP = the TRTP of the corresponding request. — Dark cells denote that nothing is transmitted. — The term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as download (as seen from the VU). — Potential 2-byte sub message counters are not shown in this table. — Slot is the slot number, either ‘1’ (card on driver slot) or ‘2’ (card on co-driver slot). — In case the slot is not specified, the VU shall select slot 1 if a card is inserted in this slot and it shall select slot 2 only in case it is specifically selected by the user. — TRTP 24 is used for Generation 2, for version 1 and version 2 type of VU data download requests. — TRTP 00, 31, 32, 33 and 35 are used for Generation 2 version 2 type of VU data download requests. — TRTP 21, 22, 23, and 25 are used for Generation 2 version 1 type of VU data download requests. — TRTP 01 to 05 are used for Generation 1 type of VU data download requests. They can optionally be accepted by Generation 2 type of VU, but only in the frame of drivers' control performed by a non-EU control authority, using a first generation control card. — TRTP 11 to 1F are reserved for manufacturer specific download requests.’; (ii) point 2.2.2.9 is amended as follows: (1) in paragraph DDP_011, the second subparagraph and the first table are replaced by the following: ‘There are seven types of data transfer. For VU data download, two different TRTP values can be used for each transfer type: Data transfer type TRTP value for generation 1 type of VU data download TRTP value for generation 2, version 1 type of VU data download TRTP value for generation 2, version 2 type of VU data download Download interface version Not used Not used 00 Overview 01 21 31 Activities of a specified date 02 22 32 Events and faults 03 23 33 Detailed speed 04 24 24 Technical data 05 25 35 ’; (2) paragraph DDP_054 is replaced by the following: ‘DDP_054 It is mandatory for the IDE to request the overview data transfer (TRTP 01, 21 or 31) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature). In the third case (TRTP 02, 22 or 32) the Transfer Data Request message includes the indication of the calendar day (TimeReal format) to be downloaded.’; (iii) in point 2.2.2.10, the text before the indents in paragraph DDP_055 is replaced by the following: ‘DDP_055 In the first case (TREP 01, 21 or 31), the VU will send data helping the IDE operator to choose the data he wants to download further. The information contained within this message is:’; (iv) in point 2.2.5.2, Figure 2 is replaced by the following: ‘Figure 2

VU error handling ’; (v) points 2.2.6.1 to 2.2.6.5 are replaced by the following: ‘2.2.6.1 Positive Response Transfer Data Download Interface Version DDP_028a The data field of the ‘Positive Response Transfer Data Download Interface Version’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 00 Hex: Data structure generation 2, version 2 (TREP 00 Hex)

Data element

Comment DownloadInterfaceVersion

Generation and version of the VU: 02,02 Hex for Generation 2, version 2. Not supported by Generation 1 and Generation 2, version 1 VU, which shall respond negatively (Sub function not supported, see DDP_018) 2.2.6.2 Positive Response Transfer Data Overview DDP_029 The data field of the ‘Positive Response Transfer Data Overview’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 01, 21 or 31 Hex and appropriate sub message splitting and counting: Data structure generation 1 (TREP 01 Hex)

Data element

Comment MemberStateCertificate

VU Security certificates VUCertificate VehicleIdentificationNumber

Vehicle identification VehicleRegistrationIdentification CurrentDateTime

VU current date and time VuDownloadablePeriod

Downloadable period CardSlotsStatus

Type of cards inserted in the VU VuDownloadActivityData

Previous VU download VuCompanyLocksData

All company locks stored. If the section is empty, only noOfLocks = 0 is sent.

VuControlActivityData

All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent

Signature

RSA signature of all data (except certificates) starting from VehicleIdentificationNumber down to last byte of last VuControlActivityData. Data structure generation 2, version 1 (TREP 21 Hex)

Data element

Comment MemberStateCertificateRecordArray

Member state certificate VUCertificateRecordArray

VU certificate VehicleIdentificationNumberRecordArray

Vehicle identification VehicleRegistrationIdentificationRecordArray

Vehicle registration number CurrentDateTimeRecordArray

VU current date and time VuDownloadablePeriodRecordArray

Downloadable period CardSlotsStatusRecordArray

Type of cards inserted in the VU VuDownloadActivityDataRecordArray

Previous VU download VuCompanyLocksRecordArray

All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent VuControlActivityRecordArray

All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent SignatureRecordArray

ECC signature of all preceding data except the certificates. Data structure generation 2, version 2 (TREP 31 Hex)

Data element

Comment MemberStateCertificateRecordArray

Member state certificate VUCertificateRecordArray

VU certificate VehicleIdentificationNumberRecordArray

Vehicle identification VehicleRegistrationNumberRecordArray

Vehicle registration number CurrentDateTimeRecordArray

VU current date and time VuDownloadablePeriodRecordArray

Downloadable period CardSlotsStatusRecordArray

Type of cards inserted in the VU VuDownloadActivityDataRecordArray

Previous VU download VuCompanyLocksRecordArray

All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent VuControlActivityRecordArray

All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent SignatureRecordArray

ECC signature of all preceding data except the certificates. 2.2.6.3 Positive Response Transfer Data Activities DDP_030 The data field of the ‘Positive Response Transfer Data Activities’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 02, 22 or 32 Hex and appropriate sub message splitting and counting: Data structure generation 1 (TREP 02 Hex)

Data element

Comment TimeReal

Date of day downloaded OdometerValueMidnight

Odometer at end of downloaded day VuCardIWData

Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.

VuActivityDailyData

Slots status at 00:00 and activity changes recorded for the day downloaded.

VuPlaceDailyWorkPeriodData

Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.

VuSpecificConditionData

Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent

Signature

RSA signature of all data starting from TimeReal down to last byte of last specific condition record. Data structure generation 2, version 1 (TREP 22 Hex)

Data element

Comment DateOfDayDownloadedRecordArray

Date of day downloaded OdometerValueMidnightRecordArray

Odometer at end of downloaded day VuCardIWRecordArray

Cards insertion withdrawal cycles data. — If this section contains no available data, an array header with noOfRecords = 0 is sent. — When a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved. VuActivityDailyRecordArray

Slots status at 00:00 and activity changes recorded for the day downloaded. VuPlaceDailyWorkPeriodRecordArray

Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent. VuGNSSADRecordArray

GNSS positions of the vehicle if the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent. VuSpecificConditionRecordArray

Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent SignatureRecordArray

ECC signature of all preceding data. Data structure generation 2, version 2 (TREP 32 Hex)

Data element

Comment DateOfDayDownloadedRecordArray

Date of day downloaded OdometerValueMidnightRecordArray

Odometer at end of downloaded day VuCardIWRecordArray

Slots status at 00:00 and activity changes recorded for the day downloaded. VuPlaceDailyWorkPeriodRecordArray

Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent. VuGNSSADRecordArray

Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent VuBorderCrossingRecordArray

Border crossings for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent. VuLoadUnloadRecordArray

Load/unload operations for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent. SignatureRecordArray

ECC signature of all preceding data. 2.2.6.4 Positive Response Transfer Data Events and Faults DDP_031 The data field of the ‘Positive Response Transfer Data Events and Faults’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 03, 23 or 33 Hex and appropriate sub message splitting and counting: Data structure generation 1, (TREP 03 Hex)

Data element

Comment VuFaultData

All faults stored or on-going in the VU. If the section is empty, only noOfVuFaults = 0 is sent. VuEventData

All events (except over speeding) stored or on-going in the VU. If the section is empty, only noOfVuEvents = 0 is sent. VuOverSpeedingControlData

Data related to last over speeding control (default value if no data). VuOverSpeedingEventData

All over speeding events stored in the VU. If the section is empty, only noOfVuOverSpeedingEvents = 0 is sent. VuTimeAdjustmentData

All time adjustment events stored in the VU (outside the frame of a full calibration). If the section is empty, only noOfVuTimeAdjRecords = 0 is sent. Signature

RSA signature of all data starting from noOfVuFaults down to last byte of last time adjustment record Data structure generation 2, version 1 (TREP 23 Hex)

Data element

Comment VuFaultRecordArray

All faults stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuEventRecordArray

All events (except over speeding) stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuOverSpeedingControlDataRecordArray

Data related to last over speeding control (default value if no data). VuOverSpeedingEventRecordArray

All over speeding events stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuTimeAdjustmentRecordArray

All time adjustment events stored in the VU (outside the frame of a full calibration). If the section is empty, an array header with noOfRecords = 0 is sent. SignatureRecordArray

ECC signature of all preceding data. Data structure generation 2, version 2 (TREP 33 Hex)

Data element

Comment VuFaultRecordArray

All faults stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuEventRecordArray

All events (except over speeding) stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuOverSpeedingControlDataRecordArray

Data related to last over speeding control (default value if no data). VuOverSpeedingEventRecordArray

All over speeding events stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. VuTimeAdjustmentRecordArray

All time adjustment events stored in the VU (outside the frame of a full calibration). If the section is empty, an array header with noOfRecords = 0 is sent. SignatureRecordArray

ECC signature of all preceding data. 2.2.6.5 Positive Response Transfer Data Detailed Speed DDP_032 The data field of the ‘Positive Response Transfer Data Detailed Speed’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 04 or 24 Hex and appropriate sub message splitting and counting: Data structure generation 1 (TREP 04 Hex)

Data element

Comment VuDetailedSpeedData

All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving) 60 speed values per minute (one per second). Signature

RSA signature of all data starting from noOfSpeedBlocks down to last byte of last speed block. Data structure generation 2 (TREP 24 Hex)

Data element

Comment VuDetailedSpeedBlockRecordArray

All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving) 60 speed values per minute (one per second). SignatureRecordArray

ECC signature of all preceding data. ’; (vi) the following point is added: ‘2.2.6.6 Positive Response Transfer Data Technical Data DDP_033 The data field of the ‘Positive Response Transfer Data Technical Data’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 05, 25 or 35 Hex and appropriate sub message splitting and counting: Data structure generation 1 (TREP 05 Hex) Data element

Comment VuIdentification SensorPaired VuCalibrationData

All calibration records stored in the VU.

Signature

RSA signature of all data starting from vuManufacturerName down to last byte of last VuCalibrationRecord. Data structure generation 2, version 1 (TREP 25 Hex) Data element

Comment VuIdentificationRecordArray VuSensorPairedRecordArray

All MS pairings stored in the VU VuSensorExternalGNSSCoupledRecordArray

All external GNSS facility couplings stored in the VU VuCalibrationRecordArray

All calibration records stored in the VU. VuCardRecordArray

All card insertion data stored in the VU. VuITSConsentRecordArray VuPowerSupplyInterruptionRecordArray SignatureRecordArray

ECC signature of all preceding data. Data structure generation 2, version 2 (TREP 35 Hex) Data element

Comment VuIdentificationRecordArray VuSensorPairedRecordArray

All MS pairings stored in the VU VuSensorExternalGNSSCoupledRecordArray

All external GNSS facility couplings stored in the VU VuCalibrationRecordArray

All calibration records stored in the VU. VuCardRecordArray

inputOutputControlByIdentifier Request SId 31 RC

7

responseCode=[ sub-functionNotSupported incorrectMessageLengthOrInvalidFormat conditionsNotCorrect requestOutOfRange ] 12 13 22 31 SFNS IMLOIF CNC ROOR

8

Checksum 00-FF CS Table 37f RoutineControl, routine (TimeAdjustment), routineInfo routineInfo Hex Value Description NormalExitWithResultAvailable 61 The routine was executed completely; additional routine results available. RoutineExecutionOngoing 78 The requested routine is still executed. Table 37g RoutineControl, routine (TimeAdjustment), routineStatus Hex Value Test result Description 01 positive The time adjustment successfully finished. 02..0F

RFU 10 negative No GNSS signal reception. 11..7F

RFU 80..FF

Manufacturer specific’ ; (e) the following point 9 is added: ‘9. DATARECORDS FORMATS This section details: — general rules that shall be applied to ranges of parameters transmitted by the vehicle unit to the tester, — formats that shall be used for data transferred via the Data Transmission Services described in section 6. CPR_067 All parameters identified shall be supported by the VU. CPR_068 Data transmitted by the VU to the tester in response to a request message shall be of the measured type (i.e. current value of the requested parameter as measured or observed by the VU). 9.1. Transmitted parameter ranges CPR_069 Table 38 defines the ranges used to determine the validity of a transmitted parameter. CPR_070 The values in the range «error indicator» provide a means for the vehicle unit to immediately indicate that valid parametric data is not currently available due to some type of error in the tachograph. CPR_071 The values in the range «not available» provide a means for the vehicle unit to transmit a message which contains a parameter that is not available or not supported in that module. The values in the range «not requested» provide a means for a device to transmit a command message and identify those parameters where no response is expected from the receiving device. CPR_072 If a component failure prevents the transmission of valid data for a parameter, the error indicator as described in Table 38 should be used in place of that parameter’s data. However, if the measured or calculated data has yielded a value that is valid yet exceeds the defined parameter range, the error indicator should not be used. The data should be transmitted using the appropriate minimum or maximum parameter value.

Table 38 dataRecords ranges Range Name 1 byte (Hex value) 2 bytes (Hex value) 4 bytes (Hex Value) ASCII Valid signal 00 to FA 0000 to FAFF 00000000 to FAFFFFFF 1 to 254 Parameter specific indicator FB FB00 to FBFF FB000000 to FBFFFFFF none Reserved range for future indicator bits FC to FD FC00 to FDFF FC000000 to FDFFFFFF none Error indicator FE FE00 to FEFF FE000000 to FEFFFFFF 0 Not available or not requested FF FF00 to FFFF FF000000 to FFFFFFFF FF CPR_073 For parameters coded in ASCII, the ASCII character ‘’ is reserved as a delimiter. 9.2. dataRecords formats* Table 39 to Table 42 below detail the formats that shall be used via the ReadDataByIdentifier and WriteDataByIdentifier Services. CPR_074 Table 39 provides the length, resolution and operating range for each parameter identified by its recordDataIdentifier:

Table 39 Format of dataRecords Parameter Name Data length (bytes) Resolution Operating range TimeDate 8 See details in Table 40 HighResolutionTotalVehicleDistance 4 5 m/bit gain, 0 m offset 0 to +21 055 406 km Kfactor 2 0.001 pulse/m /bit gain, 0 offset 0 to 64.255 pulse/m LfactorTyreCircumference 2 0.125 10^-3 m /bit gain, 0 offset 0 to 8.031 m WvehicleCharacteristicFactor 2 0.001 pulse/m /bit gain, 0 offset 0 to 64.255 pulse/m TyreSize 15 ASCII ASCII NextCalibrationDate 3 See details in Table 41 SpeedAuthorised 2 1/256 km/h/bit gain, 0 offset 0 to 250.996 km/h RegisteringMemberState 3 ASCII ASCII VehicleRegistrationNumber 14 See details in Table 42 VIN 17 ASCII ASCII SealDataVu 55 See details in Table 43 ByDefaultLoadType 1 See details in Table 44 VuSerialNumber 8 See details in Table 45 SensorSerialNumber 8 See details in Table 45 SensorGNSSSerialNumber 8 See details in Table 45 RemoteCommunicationModuleSerialNumber 8 See details in Table 45 TachographCardsGen1Suppression 2 See details in Table 46 VehiclePosition 14 See details in Table 47 CalibrationCountry 3 ASCII NationAlpha as defined in Appendix 1 CPR_075 Table 40 details the formats of the different bytes of the TimeDate parameter:

Table 40 Detailed format of TimeDate (recordDataIdentifier value # F90B) Byte Parameter definition Resolution Operating range 1 Seconds 0.25 s/bit gain, 0 s offset 0 to 59.75s 2 Minutes 1 min/bit gain, 0 min offset 0 to 59 min 3 Hours 1 h/bit gain, 0 h offset 0 to 23 h 4 Month 1 month/bit gain, 0 month offset 1 to 12 month 5 Day 0.25 day/bit gain, 0 day offset (see NOTE below Table 41) 0.25 to 31.75 day 6 Year 1 year/bit gain, +1985 year offset (see NOTE below Table 41) 1985 to 2235 year 7 Local Minute Offset 1 min/bit gain, -125 min offset -59 to +59 min 8 Local Hour Offset 1 h/bit gain, -125 h offset - 23 to +23 h CPR_076 Table 41 details the formats of the different bytes of the NextCalibrationDate parameter:

Table 41 Detailed format of NextCalibrationDate (recordDataIdentifier value # F922) Byte Parameter definition Resolution Operating range 1 Month 1 month/bit gain, 0 month offset 1 to 12 month 2 Day 0.25 day/bit gain, 0 day offset (see NOTE below) 0.25 to 31.75 day 3 Year 1 year/bit gain, +1985 year offset (see NOTE below) 1985 to 2235 year NOTE concerning the use of the ‘Day’ parameter: 1) A value of 0 for the date is null. The values 1, 2, 3, and 4 are used to identify the first day of the month; 5, 6, 7, and 8 identify the second day of the month; etc. 2) This parameter does not influence or change the hours parameter above. NOTE concerning the use of the ‘Year’ parameter: A value of 0 for the year identifies the year 1985; a value of 1 identifies 1986; etc. CPR_078 Table 42 details the formats of the different bytes of the VehicleRegistrationNumber parameter:

Table 42 Detailed format of VehicleRegistrationNumber (recordDataIdentifier value # F97E) Byte Parameter definition Resolution Operating range 1 Code Page (as defined in Appendix 1) not applicable VehicleRegistrationNumber 2 – 14 Vehicle Registration Number (as defined in Appendix 1) not applicable VehicleRegistrationNumber CPR_090 Table 43 details the formats of the different bytes of the SealDataVu parameter:

Table 43 Detailed format of SealDataVu (recordDataIdentifier value # F9D3) Byte Parameter definition Resolution Operating range 1 – 11 sealRecord1. Format SealRecord as defined in Appendix 1. not applicable SealRecord 12 - 22 sealRecord2. Format SealRecord as defined in Appendix 1. not applicable SealRecord 23 – 33 sealRecord3. Format SealRecord as defined in Appendix 1. not applicable SealRecord 34 – 44 sealRecord4. Format SealRecord as defined in Appendix 1. not applicable SealRecord 45 – 55 sealRecord5. Format SealRecord as defined in Appendix 1. not applicable SealRecord NOTE: If there are less than 5 seals available the value of the EquipmentType in all unused sealRecords shall be set to 15, i.e. unused. CPR_091 Table 44 details the formats of the different bytes of the ByDefaultLoadType parameter:

Table 44 Detailed format of ByDefaultLoadType (recordDataIdentifier value # F9D5) Byte Parameter definition Resolution Operating range 1 loadType '00'H: Undefined load type '01'H: Goods '02'H: Passengers not applicable '00'H to '02'H CPR_092 Table 45 details the formats of the different bytes of the VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber parameters:

Table 45 Detailed format of VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber (recordDataIdentifier values # F9D4, F9D0, F9D2, F9D1) Byte Parameter definition Resolution Operating range 1 VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber: format ExtendedSerialNumber as defined in Appendix 1. not applicable ExtendedSerialNumber CPR_093 Table 46 details the formats of the different bytes of the TachographCardsGen1Suppression parameter:

Table 46 Detailed format of TachographCardsGen1Suppression (recordDataIdentifier value # F9D6) Byte Parameter definition Resolution Operating range 1-2 TachographCardsGen1Suppression. Format TachographCardsGen1Suppression as defined in Appendix 1. not applicable '0000'H, 'A5E3'H CPR_094 Table 47 details the formats of the different bytes of the VehiclePosition parameter.

Table 47 Detailed format of VehiclePosition (recordDataIdentifier value # F9D7) Byte Parameter definition Resolution Operating range 1 - 4 Time stamp of the vehicle position was determined. Not applicable TimeReal 5 GNSS accuracy Not applicable GNSSAccuracy 6 - 11 Vehicle position Not applicable GeoCoordinates 12 Authentication status Not applicable PositionAuthenticationStatus 13 Current country Not applicable NationNumeric 14 Current region Not applicable RegionNumeric Note: after vehicle position update, the update of current country and region may be delayed.’;

(36) Appendix 9 is amended as follows: (a) in the Table of Content, the following point 9 is added: ‘9. OSNMA TESTS’; (b) point 1 is amended as follows: (i) in point 1.1, the following sub-paragraph is added: ‘The Member States authority in charge of the functional tests of a vehicle unit or an external GNSS facility must make sure that the embedded GNSS receiver has successfully passed the OSNMA tests specified in this Appendix. These tests are considered to be a part of the functional tests of the vehicle unit or the external GNSS facility.’; (ii) in point 1.2, the following reference is added: ‘RGODP JRC Technical Report - Receiver guidelines for OSNMA data processing’; (c) in point 2, rows 3.1 to 3.41 are replaced by the following: ‘3.1 Functions provided 02, 03, 04, 05, 07, 382, 3.2 Modes of operation 09 to 11, 134, 135 3.3 Functions and data access rights 12, 13, 382, 383, 386 to 389 3.4 Monitoring cards insertion and withdrawal 15, 16, 17, 18, 19, 20, 134 3.5 Speed, position and distance measurement 21 to 37 3.6 Time measurement (test performed at 20°C) 38 to 43 3.7 Monitoring driver activities 44 to 53, 134 3.8 Monitoring driving status 54, 55, 134 3.9 Driver’s entries 56 to 62c 3.10 Company locks management 63 to 68 3.11 Monitoring control activities 69, 70 3.12 Detection of events and/or faults 71 to 88a, 134 3.13 Equipment identification data 93, 94, 97, 100 3.14 Driver or workshop card insertion and withdrawal data 102 to 104 3.15 Driver activity data 105 to 107 3.16 Places and positions data 108 to 112 3.17 Odometer data 113 to 115 3.18 Detailed speed data 116 3.19 Events data 117 3.20 Faults data 118 3.21 Calibration data 119 to 121 3.22 Time adjustment data 124, 125 3.23 Control activity data 126, 127 3.24 Company locks data 128 3.25 Download activity data 129 3.26 Specific conditions data 130, 131 3.27 Tachograph cards data 132, 133 3.28 Border crossings 133a to 133d 3.29 Load/unload operation 133e to 133i 3.30 Digital map 133j to 133t 3.31 Recording and storing on tachographs cards 136, 137, 138, 139, 141, 142, 143 144, 145, 146, 147, 147a, 147b, 148, 149, 150, 150a 3.32 Displaying 90, 134, 151 to 168, PIC_001, DIS_001 3.33 Printing 90, 134, 169 to 181, PIC_001, PRT_001 to PRT_014 3.34 Warning 134, 182 to 191, PIC_001 3.35 Data downloading to external media 90, 134, 192 to 196 3.36 Remote communication for targeted roadside checks 197 to 199 3.37 Data exchanges with additional external devices 200, 201 3.38 Calibration 202 to 206, 383, 384, 386 to 391 3.39 Roadside calibration checking 207 to 209 3.40 Time adjustment 210 to 212 3.41 Monitoring border crossings 226a to 226c 3.42 Software update 226d to 226f 3.43 Non-interference of additional functions 06, 425 3.44 Motion sensor interface 02, 122 3.45 External GNSS facility 03, 123 3.46 Verify that the VU detects, records and stores the event(s) and/or fault(s) defined by the VU manufacturer when a paired motion sensor reacts to magnetic fields disturbing vehicle motion detection. 217 3.47 Cypher suite and standardized domain parameters CSM_48, CSM_50’ (d) the following point 9 is added: ‘9. OSNMA TESTS 9.1. Introduction This chapter describes the tests to prove the correct implementation of OSNMA in the GNSS receiver. Since satellite signal authentication is carried out solely by the GNSS receiver with independence of any other component of the tachograph, the tests set out in this chapter may be performed on the GNSS receiver as a stand-alone element. In this case, the tachograph manufacturer shall present a report to the type-approval authorities providing details about the development and results of the tests that are performed under the responsibility of the GNSS receiver manufacturer. 9.2 Applicable conditions — The pass/fail criteria defined in the OSNMA tests shall be considered valid only for the identified testing conditions. — The criteria might be revised at the moment of the Galileo OSNMA service declaration and considering the associated service performance commitments. 9.3. Definitions and acronyms 9.3.1 Definitions GNSS cold/warm/hot start : refers to the start condition of a GNSS receiver based on the availability of time (T), current almanac (A) and ephemeris (E), position (P): — GNSS Cold Start: none — GNSS Warm Start: T, A, P — GNSS Hot Start: T, A, E, P OSNMA cold/warm/hot start : refers to the start condition of the OSNMA function based on the availability of the Public Key (P) and DSM-KROOT (K) information (as defined in the OSNMA Receiver Guidelines referred to in Appendix 12): — OSNMA Cold Start: none — OSNMA Warm Start: P — OSNMA Hot Start: P, K 9.3.2 Acronyms ADKD Authentication Data & Key Delay DSM-KROOT Digital Signature Message KROOT GNSS Global Navigation Satellite System KROOT Root Key of the TESLA key chain MAC Message Authentication Code NMACK Number of MAC & key blocks (per 30 seconds) OSNMA Galileo Open Service Navigation Message Authentication SLMAC Slow MAC TESLA Timed Efficient Stream Loss-tolerant Authentication (Protocol used in OSNMA) 9.4. Equipment for the generation of the GNSS signals The generation of the GNSS signals can be carried out using a multi-constellation GNSS simulator supporting OSNMA message transmission. Alternatively, a radiofrequency signal re-player capable of playing back GNSS signal samples from files can be used. Typical bit depth and sampling rate are respectively 4 bits I/Q and 10MHz. It is assumed that the GNSS receiver has interfaces to command the clearing of the receiver memory (to independently erase the public key, KROOT, clock information, position information, ephemeris and almanac), to set the receiver local time realisation for the OSNMA timing verification requirement, and to load the cryptographic information. These commands may be limited to test purposes and therefore may not be available for the receiver nominal operation. 9.5 Test conditions 9.5.1 GNSS conditions The simulated or replayed GNSS signals will have the following features: — Static user receiver scenario; — At least GPS and Galileo constellations; — E1/L1 frequency; — At least 4 Galileo satellites with elevation angle greater than 5°; — Duration as required for each test; — Constant navigation ephemerides from the satellites during the test. 9.5.2 OSNMA conditions The OSNMA message transmitted in the RF signal will have the following features: — An HKROOT message with OSNMA Status set to Operational or Test and a fixed DSM-KROOT of 8 blocks for the chain in force; — At least 4 Galileo satellites transmitting OSNMA; — A MACK message with one MACK block (i.e. NMACK=1), and at least one ADKD=0 and one ADKD=12 per satellite and MACK block; — A tag size of 40 bits; — The minimum equivalent tag length as required in the OSNMA Receiver Guidelines (currently 80 bits). Except when noted, the internal receiver time realisation shall be known with sufficient accuracy and properly aligned with the simulated time. This guarantees that the OSNMA initial time synchronisation requirement is fulfilled for each test condition, i.e., nominal synchronization for all but the SLMAC test. See the OSNMA Receiver Guidelines for more details on the time initialization. Note that the identified pass/fail criteria are conservative and do not represent the expected Galileo OSNMA performance. 9.6. Tests specification No Test Description Related requirements

Administrative examination

1.1 Documentation Correctness of documentation 2 General Tests 2.1 OSNMA hot start Objective: verify that the GNSS receiver computes a position with OSNMA after a hot start. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites. The receiver authenticates the Galileo navigation data with OSNMA (ADKD = 0) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated position fix within 160 seconds. Appendix 12, GNS_3b 2.2 OSNMA warm start Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start. Procedure: Before starting the test, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start. The GNSS receiver starts and acquires the signals of the visible Galileo satellites. The DSM-KROOT is received and verified. The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated valid position fix within 430 seconds. Appendix 12, GNS_3b 2.3 OSNMA warm start with SLMAC Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start with a time initialisation requiring SLMAC mode, as defined in the OSNMA Receiver Guidelines. Procedure: The internal receiver time realisation shall be configured in order to have an initial time uncertainty of a value between 2 and 2.5 minutes so that, according to OSNMA Receiver Guidelines, the Slow MAC mode is activated. Before starting the tests, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start. The GNSS receiver starts and acquires the signals of the visible Galileo satellites. The DSM-KROOT is received and verified. The receiver authenticates the Galileo navigation data with only OSNMA Slow MAC (ADKD=12) and provides a position with authenticated data. Pass/fail criteria: the receiver computes an authenticated valid position fix within 730 seconds. Appendix 12, GNS_3b 2.4 OSNMA hot start with replayed signal Objective: verify that the GNSS receiver detects a replayed signal. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites. The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data. Once the receiver provides PVT solution with authenticated data, it is switched off. A replayed signal with a delay of 40 seconds with respect to the previous one is simulated, and the receiver is switched on. The receiver detects that the Galileo System Time from the signal-in-space time and the local timing realisation do not meet the synchronisation requirement and it stops processing OSNMA data as defined in OSNMA Receiver Guidelines. Pass/fail criteria: the receiver detects the replay and does not compute an authenticated valid position since the start of the replay until the end of the test. Appendix 12, GNS_3b 2.5 OSNMA hot start with false data Objective: Verify that OSNMA detects false data. Procedure: The GNSS receiver starts in GNSS and OSNMA hot start conditions. The GNSS receiver shall be able to acquire the signal of all the visible Galileo satellites and verify the authenticity of their navigation messages by means of OSNMA. At least one bit of the ephemeris data provided by each Galileo satellite does not correspond with the original and authenticated data, but the Galileo I/NAV message must be coherent, including CRC. Pass/fail criteria: the receiver detects the false data within 160 seconds and does not compute an authenticated valid position until the end of the test. Appendix 12, GNS_3b ’;

(37) Appendix 12 is amended as follows: (a) the Table of Content is amended as follows: (i) the following point 1.1.1 is inserted after point 1.1: ‘1.1.1 References’; (ii) point 2 is replaced by the following: ‘2. BASIC CHARACTERISTICS OF THE GNSS RECEIVER’; (iii) point 3 is replaced by the following: ‘3. SENTENCES PROVIDED BY THE GNSS RECEIVER’; (iv) the following points 4.2.4 and 4.2.5 are inserted: ‘4.2.4 Structure of the WriteRecord command 4.2.5 Other commands’; (v) point 5.2 is replaced by the following: ‘5.2. Transfer of information from the GNSS receiver to the VU’; (vi) point 5.2.1 is deleted; (vii) the following points 5.3, 5.4 and 5.4.1 are inserted: ‘5.3. Transfer of information from the VU to the GNSS receiver 5.4. Error handling 5.4.1 Absence of position information from GNSS receiver’; (viii) points 6 and 7 are replaced by the following: ‘6. POSITION DATA PROCESSING AND RECORDING BY THE VU

GNSS TIME CONFLICT’;

Reading this document does not replace reading the official text published in the Official Journal of the European Union. We assume no responsibility for any inaccuracies arising from the conversion of the original to this format.

This text is published under EUR-Lex's own terms of reuse, not a Legalize or public-domain licence. EUR-Lex
Creative Commons Attribution 4.0 International (CC BY 4.0)
© European Union, https://eur-lex.europa.eu — Source: EUR-Lex (Publications Office of the European Union). Reused under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. Only EU legislation published in the printed Official Journal of the European Union is deemed authentic; consolidated texts are reproduced here for documentation purposes and have been reformatted to Markdown.