Article 1

Annex IC to Implementing Regulation (EU) 2016/799 is amended in accordance with the Annex to this Regulation.

Article 2

Entry into force

This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.

It shall apply from 21 August 2023.

However, from 25 May 2023, national authorities shall not refuse to grant EU type approval for a new type of tachograph, tachograph component, or tachograph card, or grant extension for an existing type of tachograph, tachograph component, or tachograph card, or prohibit registration, placing on the market or entry into service of a new tachograph, tachograph component, or tachograph card where the equipment concerned complies with Implementing Regulation (EU) 2016/799 as amended by this Regulation, if a manufacturer so requests.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

ANNEX

Annex IC to Implementing Regulation (EU) 2016/799 is amended as follows:

(1) the table of content is amended as follows: (a) the following point 3.6.4 is inserted: ‘3.6.4 Entry of load/unload operation’; (b) the following point 3.9.18 is inserted: ‘3.9.18 ‘GNSS anomaly’ event’; (c) the following points 3.12.17, 3.12.18 and 3.12.19 are inserted: ‘3.12.17 Border crossings 3.12.18 Load/unload operations 3.12.19 Digital map’; (d) point 3.20 is replaced by the following: ‘3.20 Data exchanges with additional external devices’; (e) the following points 3.27 and 3.28 are inserted: ‘3.27 Monitoring border crossings 3.28 Software update’; (f) the following point 4.5.3.2.1.1 is inserted: ‘4.5.3.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units)’; (g) the following points 4.5.3.2.17 to 4.5.3.2.22 are inserted: ‘4.5.3.2.17 Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units) 4.5.3.2.18 Authentication status for positions where three hours accumulated driving time are reached (not accessed by version 1 of second generation vehicle units) 4.5.3.2.19 Border crossings (not accessed by version 1 of second generation vehicle units) 4.5.3.2.20 Load/unload operations (not accessed by version 1 of second generation vehicle units) 4.5.3.2.21 Load type entries (not accessed by version 1 of second generation vehicle units) 4.5.3.2.22 VU configurations (not accessed by version 1 of second generation vehicle units)’; (h) the following point 4.5.4.2.1.1 is inserted: ‘4.5.4.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units)’; (i) the following points 4.5.4.2.16 to 4.5.4.2.22 are inserted: ‘4.5.4.2.16 Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units) 4.5.4.2.17 Authentication status for positions where three hours accumulated driving are reached (not accessed by version 1 of second generation vehicle units) 4.5.4.2.18 Border crossings (not accessed by version 1 of second generation vehicle units) 4.5.4.2.19 Load/unload operations (not accessed by version 1 of second generation vehicle units) 4.5.4.2.20 Load type entries (not accessed by version 1 of second generation vehicle units) 4.5.4.2.21 Calibration Additional Data (not accessed by version 1 of second generation vehicle units) 4.5.4.2.22 VU configurations (not accessed by version 1 of second generation vehicle units)’; (j) the following point 4.5.5.2.1.1 is inserted after point 4.5.5.2.1: ‘4.5.5.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units)’; (k) the following point 4.5.5.2.6 is inserted: ‘4.5.5.2.6 VU configurations (not accessed by version 1 of second generation vehicle units)’; (l) the following point 4.5.6.2.1.1 is inserted after point 4.5.6.2.1: ‘4.5.6.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units)’; (m) the following point 4.5.6.2.6 is inserted: ‘4.5.6.2.6 VU configurations (not accessed by version 1 of second generation vehicle units)’;

(2) the introductory text before the List of Appendixes is replaced by the following: ‘INTRODUCTION This Annex contains second generation recording equipment and tachograph cards requirements. Since June 15^th 2019, second generation recording equipment is being installed in vehicles registered in the Union for the first time, and second generation tachograph cards are being issued. In order to smoothly implement the second generation tachograph system, second generation tachograph cards have been designed to be also used in first generation vehicle units built in accordance with Annex IB to Regulation (EEC) No 3821/85. Reciprocally, first generation tachograph cards may be used in second generation vehicle units. Nevertheless, second generation vehicle units can only be calibrated using second generation workshop cards. The requirements regarding the interoperability between the first and the second generation tachograph systems are specified in this Annex. In this respect, Appendix 15 contains additional details on the management of the co-existence of both generations. In addition, due to the implementation of new functions such as the use of Galileo Open Signal Navigation Messages Authentication, detection of border crossings, entry of load and unload operations, and also to the need to increase the driver card capacity to 56 days of driver activities, this Regulation introduces the technical requirements for the second version of the second generation recording equipment and tachograph cards.’;

(3) section 1, is amended as follows: (a) point (f) is replaced by the following: ‘(f) ‘calibration of a smart tachograph’ means: updating or confirming vehicle parameters to be held in the data memory. Vehicle parameters include vehicle identification (VIN, VRN and registering Member State) and vehicle characteristics (w, k, l, tyre size, speed-limiting device setting (if applicable), current UTC time, current odometer value, by-default load type); during the calibration of a recording equipment, the types and identifiers of all type-approval relevant seals in place shall also be stored in the data memory; any update or confirmation of UTC time only, shall be considered as a time adjustment and not as a calibration, provided it does not contradict requirement 409 set out in point 6.4. calibrating a recording equipment requires the use of a workshop card;’; (b) point (g) is replaced by the following: ‘(g) ‘card number’ means: a 16-alpha-numerical characters number that uniquely identifies a tachograph card within a Member State. The card number includes an identification, which consists in a driver identification, or in a card owner identification together with a card consecutive index, a card replacement index and a card renewal index; a card is therefore uniquely identified by the code of the issuing Member State and the card number;’; (c) points (i) and (j) are replaced by the following: ‘(i) ‘card renewal index’ means: the 16th alpha-numerical character of a card number which is incremented each time a tachograph card corresponding to a given identification, i.e. driver identification or owner identification together with consecutive index, is renewed; (j) ‘card replacement index’ means: the 15^th alpha-numerical character of a card number which is incremented each time a tachograph card corresponding to a given identification, i.e. driver identification or owner identification together with consecutive index, is replaced;’; (d) point (ee) is replaced by the following: ‘(ee) ‘non-valid card’ means: a card detected as faulty, or which authentication failed, or whose start of validity date is not yet reached, or which expiry date has passed; a card is also considered as non-valid by the vehicle unit: — if a card with the same card issuing Member State, the same identification, i.e. driver identification or owner identification together with consecutive index, and a higher renewal index has already been inserted in the vehicle unit, or — if a card with the same card issuing Member State, the same identification, i.e. driver identification or owner identification together with consecutive index and renewal index but with a higher replacement index has already been inserted in the vehicle unit;’; (e) point (ll) is replaced by the following: ‘(ll) ‘remote communication facility’, ‘remote communication module’ or ‘remote early detection facility’ means: the equipment of the vehicle unit which is used to perform targeted roadside checks;’; (f) point (nn) is replaced by the following: ‘(nn) ‘card renewal’ means: issue of a new tachograph card when an existing card reaches its expiry date, or is malfunctioning and has been returned to the issuing authority;’; (g) point (pp) is replaced by the following: ‘(pp) ‘card replacement’ means: issue of a new tachograph card in replacement of an existing card, which has been declared as lost, stolen or malfunctioning and has not been returned to the issuing authority;’; (h) point (tt) is replaced by the following: ‘(tt) ‘time adjustment’ means: an adjustment of current time; this adjustment can be automatic, using the time provided by the GNSS receiver as a reference, or performed in calibration mode;’; (i) in point (yy), the first indent is replaced by the following: ‘- installed and used only in M1 and N1 type vehicles, as defined in Article 4 of Regulation (EU) 2018/858 of the European Parliament and of the Council (¹),’; (j) point (aaa) is replaced by the following: ‘(aaa) reserved for future use;’; (k) point (ccc) is replaced by the following: ‘(ccc) ‘introduction date’ means: the date set out in Regulation (EU) No 165/2014 as from which vehicles registered for the first time shall be fitted with a tachograph in accordance with this Regulation.’;

(4) point 2.1 is amended as follows: (a) paragraph (5) is replaced by the following: ‘(5) The vehicle unit shall include an ITS interface, which is specified in Appendix 13. The recording equipment may be connected to other facilities through additional interfaces and/or through the ITS interface.’; (b) in paragraph (7), the last subparagraph is replaced by the following: ‘This is done in accordance with the applicable Union legislation regarding data protection and in compliance with Article 7 of Regulation (EU) No 165/2014.’;

(5) point 2.2 is amended as follows: (a) the sixth indent is replaced by the following: ‘- drivers manual entries: — entry of places where daily work periods begin and/or end, — manual entry of driver activities and driver consent for ITS interface, — entry of specific conditions, — entry of load/unload operations,’; (b) the following indents are added ‘— monitoring border crossings, — software update.’;

(6) point 2.3 is amended as follows (a) in paragraph (12), the fifth indent is replaced by the following: ‘- The downloading function is not accessible in the operational mode, except: (a) as provided for in requirement 193, (b) downloading a driver card when no other card type is inserted into the VU.’; (b) paragraph (13) is amended as follows: (i) the second indent is replaced by the following: ‘- in the company mode, driver related data (requirements 102, 105, 108, 133a and 133e) can be output only for periods where no lock exists or no other company holds a lock (as identified by the first 13 digits of the company card number),’; (ii) the fourth indent is replaced by the following: ‘- personal data recorded and produced by either the tachograph or the tachograph cards shall not be output through the ITS interface of the VU unless the consent of the driver to whom the data relates is verified.’;

(7) in point 2.4(14), the fourth indent is replaced by the following: ‘- external GNSS facility (this Profile is only needed and applicable for the external GNSS facility variant).’;

(8) point 3.1 is amended as follows: (a) paragraph (16) is replaced by the following: ‘(16) Upon card insertion (or remote card authentication) the recording equipment shall detect whether the card is a valid tachograph card in accordance with definition (ee) in section 1, and in such a case identify the card type and the card generation. For checking if a card has already been inserted, the recording equipment shall use the tachograph card data stored in its data memory, as set out in requirement 133.’; (b) paragraph (20) is replaced by the following: ‘(20) The withdrawal of tachograph cards may function only when the vehicle is stopped and after the relevant data have been stored on the cards. The withdrawal of the card shall require positive action by the user.’;

(9) point 3.2 is amended as follows: (a) paragraphs (26) and (27) are replaced by the following: ‘(26) To detect manipulation of motion data, information from the motion sensor shall be corroborated by vehicle motion information derived from the GNSS receiver and by other source(s) independent from the motion sensor. At least another independent vehicle motion source shall be inside the VU without the need of an external interface. (27) This function shall measure the position of the vehicle in order to allow for the recording of: — positions where the driver and/or the co-driver begins his daily work period; — positions where the accumulated driving time reaches a multiple of three hours; — positions where the vehicle has crossed the border of a country; — positions where operations of load/unload have been carried out; — positions where the driver and/or the co-driver ends his daily work period.’; (b) in point 3.2.1, the following sentence is added in paragraph (30): ‘The tolerances shall not be used to intentionally alter the distance measured.’; (c) in point 3.2.2, paragraph (33) is replaced by the following: ‘(33) To ensure a maximum tolerance on speed displayed of ± 6 km/h in use, and taking into account: — a ± 2 km/h tolerance for input variations (tyre variations, …), — a ± 1 km/h tolerance in measurements made during installation or periodic inspections, the recording equipment shall, for speeds between 20 and 180 km/h, and for characteristic coefficients of the vehicle between 2 400 and 25 000 imp/km, measure the speed with a tolerance of ± 1 km/h (at constant speed). Note: The resolution of data storage brings an additional tolerance of ± 0,5 km/h to speed stored by the recording equipment.’; (d) in point 3.2.3, paragraph (37) is replaced by the following: ‘(37) The absolute position shall be measured in geographical coordinates of latitude and longitude in degrees and minutes with a resolution of 1/10 of a minute.’;

(10) point 3.3 is amended as follows (a) paragraph (41) is replaced by the following: ‘(41) Time drift shall be ± 1 second per day or less, in temperature conditions in accordance with requirement 213, in the absence of any time adjustment.’; (b) the following paragraphs (41a), (41b) and (41c) are inserted: ‘(41a) Time accuracy when time is adjusted by workshops in accordance with requirement 212 shall be 3 seconds or better. (41b) The vehicle unit shall include a drift counter, which computes the maximal time drift since the last time adjustment in accordance with point 3.23. The maximal time drift shall be defined by the vehicle unit manufacturer and shall not exceed 1 second per day, as set out in requirement 41. (41c) The drift counter shall be reset to 1 second after each time adjustment of the recording equipment in accordance with point 3.23. This includes: — automatic time adjustments, — time adjustments performed in calibration mode.’;

(11) point 3.6 is amended as follows: (a) point 3.6.1 is amended as follows: (i) paragraphs (57) to (59) are replaced by the following: ‘(57) Places are defined as the country and, in addition where applicable, the region. (58) Upon driver (or workshop) card withdrawal, the recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map in accordance with point 3.12.19, and shall request the cardholder to confirm or to manually rectify the place. (59) The place entered in accordance with requirement 58 shall be considered as the place where the daily work period ends. It shall be recorded in the relevant driver (or workshop) card as a temporary record, and may therefore be later overwritten. Under the following conditions temporary entry made at last card withdrawal is validated (i.e. shall not be overwritten anymore): — entry of a place where the current daily work period begins during manual entry according to requirement (61); — the next entry of a place where the current daily work period begins if the card holder does not enter any place where the work period begins or ended during the manual entry according to requirement (61). Under the following conditions temporary entry made at last card withdrawal is overwritten and the new value is validated: — the next entry of a place where the current daily work period ends if the card holder does not enter any place where the work period begins or ended during the manual input according to requirement (61).’; (ii) the following subparagraph is added in paragraph (60): ‘The recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map(s) in accordance with point 3.12.19 and shall request the driver to confirm or to manually rectify the place.’; (b) in point 3.6.2, paragraph (61) is replaced by the following: ‘(61) Upon driver (or workshop) card insertion, and only at this time, the recording equipment shall allow manual entries of activities. Manual entries of activities shall be performed using local time and date values of the time zone (UTC offset) currently set for the vehicle unit. At driver or workshop card insertion the cardholder shall be reminded of: — the date and time of his last card withdrawal; — optionally: the local time offset currently set for the vehicle unit. At the first insertion of a given driver card or workshop card currently unknown to the vehicle unit, the cardholder shall be invited to express his consent for tachograph related personal data output through the ITS interface. For checking if a card has already been inserted, the recording equipment shall use the tachograph card data stored in its data memory, as set out in requirement 133. At any moment, the driver (resp. workshop) consent can be enabled or disabled through commands in the menu, provided the driver (resp. workshop) card is inserted. It shall be possible to input activities with the following restrictions: — Activity type shall be WORK, AVAILABILITY or BREAK/REST; — Start and end times for each activity shall be within the period of the last card withdrawal – current insertion only; — Activities shall not be allowed to overlap mutually in time. It shall be possible to make manual entries, if required, at the first insertion of a previously unused driver (or workshop) card. The procedure for manual entries of activities shall include as many consecutive steps as necessary to set a type, a start time and an end time for each activity. For any part of the time period between last card withdrawal and current card insertion, the cardholder shall have the option not to declare any activity. During the manual entries associated with card insertion and if applicable, the card holder shall have the opportunity to input: — a place where a previous daily work period ended, associated to the relevant time (thus overwriting and validating the entry made at the last card withdrawal), — a place where the current daily work period begins, associated to the relevant time (thus validating a temporary entry made at last card withdrawal). For the place where the current daily work period begins entered at the current card insertion, the recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map(s) in accordance with point 3.12.19, and shall request the driver to confirm or to manually rectify the place. If the card holder does not enter any place where the work period begins or ended, during the manual entries associated with card insertion, this shall be considered as a declaration that his work period has not changed since the last card withdrawal. The next entry of a place where a previous daily work period ends shall then overwrite the temporary entry made at the last card withdrawal. If a place is entered, it shall be recorded in the relevant tachograph card. Manual entries shall be interrupted if: — the card is withdrawn or, — the vehicle is moving and the card is in the driver slot. Additional interruptions are allowed, e.g. a timeout after a certain period of user inactivity. If manual entries are interrupted, the recording equipment shall validate any complete place and activity entries (having either unambiguous place and time, or activity type, begin time and end time) already made. If a second driver or workshop card is inserted while manual entries of activities are in progress for a previously inserted card, the manual entries for this previous card shall be allowed to be completed before manual entries start for the second card. The cardholder shall have the option to insert manual entries according to the following minimum procedure: — Enter activities manually, in chronological order, for the period last card withdrawal – current insertion. — Begin time of the first activity shall be set to card withdrawal time. For each subsequent entry, the start time shall be preset to immediately follow the end time of the previous entry. Activity type and end time shall be selected for each activity. The procedure shall end when the end time of a manually entered activity equals the card insertion time. The recording equipment shall allow drivers and workshops to alternately upload manual entries that need to be entered during the procedure through the ITS interface specified in Appendix 13 and, optionally, through other interfaces. The recording equipment shall allow the card holder to modify any activity manually entered, until validation by selection of a specific command. Thereafter, any such modification shall be forbidden.’; (c) in point 3.6.3, paragraph (62) is replaced by the following: ‘(62) The recording equipment shall allow the driver to enter, in real time, the following two specific conditions: — ‘OUT OF SCOPE’ (begin, end), — ‘FERRY / TRAIN CROSSING’ (begin, end). A ‘FERRY / TRAIN CROSSING’ shall not occur if an ‘OUT OF SCOPE’ condition is opened. If an ‘OUT OF SCOPE’ condition is opened, the recording equipment shall not allow users to enter a ‘FERRY / TRAIN CROSSING’ begin flag. An opened ‘OUT OF SCOPE’ condition must be automatically closed, by the recording equipment, if a driver card is inserted or withdrawn. An opened ‘OUT OF SCOPE’ condition shall inhibit the following events and warnings: — Driving without an appropriate card, — Warnings associated with continuous driving time. The driver shall enter the FERRY / TRAIN CROSSING begin flag immediately after selecting BREAK/REST on the ferry or train. An opened FERRY / TRAIN CROSSING must be ended by the recording equipment when any of the following options occurs: — the driver manually ends the FERRY/TRAIN CROSSING, which shall occur upon arrival to destination of the ferry/train, before driving off the ferry/train, — an ‘OUT OF SCOPE’ condition is opened, — the driver ejects his card, — driver activity is computed as DRIVING during a calendar minute in accordance with point 3.4. If more than one specific conditions entry of the same type is done within one calendar minute, only the last one shall be kept recorded.’; (d) the following point 3.6.4 is added: ‘3.6.4 Entry of load/unload operation (62a) The recording equipment shall allow the driver to enter and confirm, in real time, information indicating that the vehicle is being loaded, unloaded or that simultaneous load/unload operation is being performed. If more than one load/unload operation entry of the same type is done within one calendar minute, only the last one shall be kept recorded. (62b) Load, unload or simultaneous load/unload operations shall be recorded as separate events. (62c) The load/unload information shall be entered before the vehicle leaves the place where the load/unload operation is carried out.’;

(12) point 3.9 is amended as follows: (a) in point 3.9.12, paragraph (83) is replaced by the following: ‘(83) This event shall be triggered, while not in calibration mode, in case of interruption of the normal data flow between the motion sensor and the vehicle unit and/or in case of data integrity or data authentication error during data exchange between the motion sensor and the vehicle unit. This event shall also be triggered, while not in calibration mode, in case the speed calculated from the motion sensor pulses increases from 0 to more than 40 km/h within 1 second, and then stays above 40km/h during at least 3 seconds.’; (b) in point 3.9.13, paragraph (84) is replaced by the following: ‘(84) This event shall be triggered, as specified in Appendix 12, while not in calibration mode, in case motion information calculated from the motion sensor is contradicted by motion information calculated from the internal GNSS receiver or from the external GNSS facility or by other independent source(s) in accordance with requirement 26. This event shall not be triggered during a ferry/train crossing.’; (c) in point 3.9.15, paragraph (86) is replaced by the following: ‘(86) This event shall be triggered, while not in calibration mode, when the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the authenticated positions transmitted by the GNSS receiver or the external GNSS facility. A ‘time discrepancy’ is detected if the time difference exceeds ±3 seconds corresponding to the time accuracy set out in requirement 41a, the latter increased by the maximal time drift per day. This event shall be recorded together with the internal clock value of the recording equipment. The VU shall perform the check for triggering the ‘time conflict’ event right before the VU automatically re-adjusts the VU internal clock, in accordance with requirement 211.’; (d) in point 3.9.17, the eighth indent is replaced by the following: ‘- ITS interface fault.’; (e) the following point is added: ‘3.9.18 ‘GNSS anomaly’ event (88a) This event shall be triggered, while not in calibration mode, when the GNSS receiver detects an attack, or when authentication of navigation messages has failed, as specified in Appendix 12. After a GNSS anomaly event has been triggered, the VU shall not generate other GNSS anomaly events for the next 10 minutes.’;

(13) in point 3.10, the last row in the table is replaced by the following: ‘ITS interface Proper operation’

(14) point 3.12 is amended as follows: (a) the first paragraph is replaced by the following: ‘For the purpose of this point, — ‘365 days’ is defined as 365 calendar days of average drivers’ activity in a vehicle. The average activity per day in a vehicle is defined as at least 6 drivers or co-drivers, 6 card insertion withdrawal cycles, and 256 activity changes. ‘365 days’ therefore include at least 2 190 drivers or co-drivers, 2 190 card insertion withdrawal cycles, and 93 440 activity changes, — the average number of place entries per day is defined as at least 6 entries where the daily work period begins and 6 entries where the daily work period ends, so that ‘365 days’ include at least 4 380 place entries, — the average number of positions per day when the accumulated driving time reaches a multiple of three hours is defined as at least 6 positions, so that ‘365 days’ include at least 2 190 such positions, — the average number of border crossings per day is defined as at least 20 crossings, so that ‘365 days’ include at least 7 300 border crossings, — the average number of load/unload operations per day is defined as at least 25 operations (irrespective of the type), so that ‘365 days’ include at least 9 125 load/unload operations, — times are recorded with a resolution of one minute, unless otherwise specified, — odometer values are recorded with a resolution of one kilometre, — speeds are recorded with a resolution of 1 km/h, — positions (latitudes and longitudes) are recorded in degrees and minutes, with a resolution of 1/10 of minute, with the associated GNSS accuracy and acquisition time, and with a flag indicating whether the position has been authenticated.’; (b) point 3.12.1.1 is amended as follows: (i) in paragraph (93), the following indent is added: ‘- digital map version identifier (requirement 133l).’; (ii) paragraph (94) is replaced by the following: ‘(94) Vehicle unit identification data are recorded and stored once and for all by the vehicle unit manufacturer, except data which may be changed in case of software update in accordance with this Regulation, and the ability to use first generation tachograph cards.’; (c) in point 3.12.1.2, the first subparagraph of paragraph (97) is replaced by the following: ‘(97) The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent successful pairings of motion sensors (if several pairings happen within one calendar day, only the first and the last one of the day shall be stored):’; (d) in point 3.12.1.3, the first subparagraph of paragraph (100) is replaced by the following: ‘(100) The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent successful couplings of external GNSS facilities (if several couplings happen within one calendar day, only the first and the last one of the day shall be stored).’; (e) point 3.12.5 is amended as follows: (i) paragraph (110) is amended as follows: (1) the first indent is replaced by the following: ‘- the driver and/or co-driver card number and card issuing Member State’; (2) the following indent is added: ‘- a flag indicating whether the position has been authenticated.’; (ii) the following paragraph (110a) is inserted: ‘(110a) For places where the daily work period begins or ends entered during the manual entry procedure at card insertion in accordance with requirement 61, the current odometer value and position of the vehicle shall be stored.’; (f) in point 3.12.8, the table in paragraph (117) is amended as follows: (i) the fifth row is replaced by the following: ‘Last card session not correctly closed — the 10 most recent events. — date and time of card insertion, — card(s) type, number, issuing Member State and generation, — last session data as read from the card: — date and time of card insertion.’ (ii) the following row is added: ‘GNSS anomaly — the longest events for each of the 10 last days of occurrence, — the 5 longest events over the last 365 days. — date and time of beginning of event, — date and time of end of event, — card(s) type, number, issuing Member State and generation of any card inserted at beginning and/or end of the event, — number of similar events that day.’ (g) in point 3.12.10, the following indents are added in paragraph (120): ‘- the serial numbers of the motion sensor, the external GNSS facility (if any), and the external remote communication facility (if any), - the by-default load type associated to the vehicle (load of either goods or passengers), - the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver.’; (h) the following points are added: ‘3.12.17   Border crossings (133a) The recording equipment shall record and store in its data memory the following information about border crossings: — the country that the vehicle is leaving, — the country that the vehicle is entering, — the position where the vehicle has crossed the border. (133b) Together with countries and position, the recording equipment shall record and store in its data memory: — the driver and/or co-driver card number and card issuing Member State, — the card generation, — the related GNSS accuracy, date and time, — a flag indicating whether the position has been authenticated — the vehicle odometer value at the time of border crossing detection. (133c) The data memory shall be able to hold border crossings for at least 365 days. (133d) When storage capacity is exhausted, new data shall replace oldest data. 3.12.18   Load/unload operations (133e) The recording equipment shall record and store in its data memory the following information about load and unload operations of the vehicle: — the type of operation (load, unload or simultaneous load/unload), — the position where the load/unload operation has occurred. (133f) When the position of the vehicle is not available from the GNSS receiver at the time of the load/unload operation, the recording equipment shall use the latest available position, and the related date and time. (133g) Together with the type of operation and position, the recording equipment shall record and store in its data memory: — the driver and/or co-driver card number and card issuing Member State, — the card generation, — the date and time of the load/unload operation, — the related GNSS accuracy, date and time if applicable, — a flag indicating whether the position has been authenticated, — the vehicle odometer value. (133h) The data memory shall be able to store load/unload operations for at least 365 calendar days. (133i) When storage capacity is exhausted, new data shall replace oldest data. 3.12.19   Digital map (133j) For the purpose of recording the position of the vehicle when the border of a country is crossed, the recording equipment shall store in its data memory a digital map. (133k) Allowed digital maps for supporting the border crossing monitoring function of the recording equipment shall be made available by the European Commission for download from a dedicated secured website, under various formats. (133l) For each of these maps, a version identifier and a hash value shall be available on the website. (133m) The maps shall feature: — a level of definition corresponding to NUTS level 0, according to the Nomenclature of Territorial Units for Statistics, — a scale of 1:1 million. (133n) Tachograph manufacturers shall select a map from the website and download it securely. (133o) Tachograph manufacturers shall only use a downloaded map from the website after having verified its integrity using the hash value of the map. (133p) The selected map shall be imported in the recording equipment by its manufacturer, under an appropriate format, but the semantic of the imported map shall remain unchanged. (133q) The manufacturer shall also store the version identifier of the map used in the recording equipment. (133r) It shall be possible to update or replace the stored digital map by a new one made available by the European Commission. (133s) Digital map updates shall be made using the software update mechanisms set up by the manufacturer, in application of requirements 226d and 226e, so that the recording equipment can verify the authenticity and integrity of a new imported map, before storing it and replacing the previous one. (133t) Tachograph manufacturers may add additional information to the basic map referred to in requirement (133m), for purposes other than recording border crossings, such as the borders of the EU regions, provided that the semantic of the basic map is not changed.’;

(15) point 3.13 is amended as follows: (a) in paragraph (134), the third indent is replaced by the following: ‘- to compute the driver's continuous driving time, cumulative break time and accumulated driving times for the previous and the current week,’; (b) the following paragraph (135a) is added: ‘(135a) The structure in the ‘TACHO_G2’ application depends on the version. Version 2 cards contain additional Elementary Files to the ones of version 1 cards, in particular: — in driver and workshop cards: — EF Places_Authentication shall contain the authentication status of the vehicle positions stored in EF Places. A timestamp shall be stored with each authentication status, which shall be exactly the same as the date and time of the entry stored with the corresponding position in EF Places. — EF GNSS_Places_Authentication shall contain the authentication status of the vehicle positions stored in EF GNSS_Places. A timestamp shall be stored with each authentication status, which shall be exactly the same as the date and time of the entry stored with the corresponding position in EF Places. — EF Border_Crossings, EF Load_Unload_Operations and EF Load_Type_Entries shall contain data related to border crossings, load/unload operations and load types. — in workshop cards: — EF Calibration_Add_Data shall contain additional calibration data to the ones stored in EF Calibration. The old date and time value and the vehicle identification number shall be stored with each additional calibration data record, which shall be exactly the same as the old date and time value and the vehicle identification number stored with the corresponding calibration data in EF Calibration. — in all tachograph cards: — EF VU_Configuration shall contain the cardholder tachograph specific settings. The vehicle unit shall ignore any authentication status found in EF Places_Authentication or EF GNSS_Places_Authentication, when no vehicle position with the same timestamp is found in EF Places or EF GNSS_Places. The vehicle unit shall ignore the elementary file EF VU_Configuration in all cards insofar as no specific rules have been provided with respect to the use of such elementary file. Those rules shall be set out through an amendment of Annex IC, which shall include the modification or deletion of this paragraph.’;

(16) point 3.14 is amended as follows: (a) point 3.14.1 is amended as follows: (i) paragraph (140) is replaced by the following: ‘(140) All events and faults not defined for the first generation recording equipment shall not be stored on the first generation driver and workshop cards.’; (ii) paragraph (143) is replaced by the following: ‘(143) Before releasing a driver or workshop card and after all relevant data have been stored on the card, the recording equipment shall reset the ‘card session data’.’; (b) point 3.14.2 is amended as follows: (i) in paragraph (144), the following sub-paragraph is added: ‘The structure in the ‘TACHO_G2’ application depends on the version. Version 2 cards contain additional Elementary Files to the ones of version 1 cards.’; (ii) the following paragraphs (147a) and (147b) are inserted: ‘(147a) On insertion of a driver or workshop card, the recording equipment shall store on the card the by-default load type of the vehicle. (147b) On insertion of a driver or workshop card, and after the manual entry procedure, the recording equipment shall check the last place where the daily work period begins or ends stored on the card. This place may be temporary, as specified in requirement 59. If this place is in a different country from the current one in which the vehicle is located, the recording equipment shall store on the card a border crossing record, with: — the country that the driver left: not available, — the country that the driver is entering: the current country in which the vehicle is located, — the date and time when the driver has crossed the border: the card insertion time, — the position of the driver when the border has been crossed: not available, — the vehicle odometer value: not available.’; (iii) the following paragraph (150a) is added: ‘(150a) The vehicle unit shall ignore the elementary file EF VU_Configuration in all cards insofar as no specific rules have been provided with respect to the use of such elementary file. Those rules shall be set out through an amendment of Annex IC, which shall include the modification or deletion of this paragraph.’;

(17) in point 3.15.4, paragraph (167) is amended as follows: (a) the second indent is replaced by the following: ‘- the content of any of the printouts listed in requirement 169 under the same formats as the printouts themselves,’; (b) the fifth and sixth indents are replaced by the following: ‘- the accumulated driving time of the driver for the previous and the current week, - the accumulated driving time of the co-driver for the previous and the current week,’; (c) the eighth, ninth and tenth indents are replaced by the following: ‘- the accumulated driving time of the driver for the current week, - the accumulated driving time of the co-driver for the current daily work period, - the accumulated driving time of the driver for the current daily work period.’;

(18) point 3.18 is amended as follows: (a) paragraph (193) is replaced by the following: ‘(193) In addition and as an optional feature, the recording equipment may, in any mode of operation, download data through any other interface to a company authenticated through this channel. In such a case, company mode data access rights shall apply to this download.’; (b) the following paragraphs (196a) and (196b) are added: ‘(196a) A transport undertaking which uses vehicles that are fitted with recording equipment complying with this Annex and fall within the scope of Regulation (EC) No 561/2006, shall ensure that all data are downloaded from the vehicle unit and driver cards. The maximum period within which the relevant data are downloaded shall not exceed: — 90 days for data from vehicle unit; — 28 days for data from the driver card. (196b) Transport undertakings shall keep the data downloaded from the vehicle unit and driver cards for at least twelve months following recording.’;

(19) in point 3.19, the following indents are added in paragraph (199): ‘- vehicle position, - an indication if the driver may currently infringe the driving times.’;

(20) point 3.20 is amended as follows: (a) the header is replaced by the following: ‘3.20 Data exchanges with additional external devices’; (b) paragraph (200) is replaced by the following: ‘(200) The recording equipment shall also be equipped with an ITS interface in accordance with Appendix 13, allowing the data recorded or produced by either the tachograph or the tachograph cards to be used by an external facility. In operational mode, the driver consent shall be needed for the transmission of personal data through the ITS interface. Nevertheless, the driver consent shall not apply to tachograph or card data accessed in control, company or calibration mode. The data and functional access rights for these modes are specified in requirements 12 and 13. The following requirements shall apply to ITS data made available through that interface: — personal data shall only be available after the verifiable consent of the driver has been given, accepting that personal data can leave the vehicle network. A set of selected existing data that can be available via the ITS interface, and the classification of the data as personal or not personal are specified in Appendix 13. Additional data may also be output in addition to the set of data provided in Appendix 13. The VU manufacturer shall classify those data as ‘personal’ or ‘not personal’, being the driver consent applicable to those data classified as ‘personal’, — at any moment, the driver consent can be enabled or disabled through commands in the menu, provided the driver card is inserted, — in any circumstances, the presence of the ITS interface shall not disturb or affect the correct functioning and the security of the vehicle unit. Additional vehicle unit interfaces may co-exist, provided they fully comply with the requirements of Appendix 13 in terms of driver consent. The recording equipment shall have the capacity to communicate the driver consent status to other platforms in the vehicle network and to external devices. For personal data injected in the vehicle network, which are further processed outside the vehicle network, it shall not be the responsibility of the tachograph manufacturer to have that personal data process compliant with the applicable Union legislation regarding data protection. The ITS interface shall also allow for data entry during the manual entry procedure in accordance with requirement 61, for both the driver and the co-driver. The ITS interface may also be used to enter additional information, in real time, such as: — driver activity selection, in accordance with requirement 46, — places in accordance with requirement 56, — specific conditions, in accordance with requirement 62, — load/unload operations, in accordance with requirement 62a. This information may also be entered through other interfaces.’; (c) paragraph (201) is replaced by the following: ‘(201) The serial link interface as specified in Annex IB to Regulation (EEC) No 3821/85, as last amended, can continue to equip tachographs for back compatibility. The serial link is classified as a part of the vehicle network, in accordance with requirement 200.’;

(21) point 3.21 is amended as follows, (a) paragraph (202) is amended as follows: (i) the ninth indent is replaced by the following: ‘- to update or confirm other parameters known to the recording equipment: vehicle identification, w, l, tyre size and speed limiting device setting if applicable, and by-default load type,’; (ii) the following indent is added: ‘- to automatically store the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver.’; (b) paragraph (205) is replaced by the following: ‘(205) Coupling the external GNSS facility to the VU shall consist, at least, in: — updating external GNSS facility installation data held by the external GNSS facility (as needed), — copying from the external GNSS facility to the VU data memory the necessary external GNSS facility identification data including the serial number of the external GNSS facility.’;

(22) in point 3.22, the following sub-paragraph is added in paragraph (209): ‘When the I/O mode of the calibration I/O signal line is active according to this requirement, the ‘Driving without an appropriate card’ warning (requirement 75) shall not be triggered by the vehicle unit.’;

(23) point 3.23 is amended as follows: (a) paragraph (211) is replaced by the following: ‘(211) The time setting of the VU internal clock shall be automatically re-adjusted at variable time intervals. The next automatic time re-adjustment shall be triggered between 72h and 168h after the previous one, and after the VU can access to GNSS time through a valid authenticated position message in accordance with Appendix 12. Nevertheless, the time adjustment shall never be bigger than the accumulated maximal time drift per day, as calculated by the VU manufacturer in accordance with requirement 41b. If the difference between internal VU clock time and GNSS receiver time is bigger than the accumulated maximum time drift per day, then the time adjustment shall bring the VU internal clock as close as possible to the GNSS receiver time. The time setting may only be done if the time provided by the GNSS receiver is obtained using authenticated position messages as set out in Appendix 12. The time reference for the automatic time setting of the VU internal clock shall be the time provided in the authenticated position message.’; (b) paragraph (212) is replaced by the following: ‘(212) The time adjustment function shall also allow for triggered adjustment of the current time, in calibration mode. Workshops may adjust time: — either by writing a time value in the VU, using the WriteDataByIdentifier service in accordance with section 6.2 of Appendix 8, — or by requesting an alignment of the VU clock to the time provided by the GNSS receiver. This may only be done if the time provided by the GNSS receiver is obtained using authenticated position messages. In this latter case, the RoutineControl service shall be used in accordance with section 8 of Appendix 8.’;

(24) the following points 3.27 and 3.28 are inserted: ‘3.27 Monitoring border crossings (226a) This function shall detect when the vehicle has crossed the border of a country, which country has been left and which country has been entered. (226b) The border crossing detection shall be based on the position measured by the recording equipment, and stored digital map in accordance with point 3.12.19. (226c) Border crossings related to the presence of the vehicle in a country for a shorter period than 120s shall not be recorded. 3.28 Software update (226d) The vehicle unit shall incorporate a function for the implementation of software updates whenever such updates do not involve the availability of additional hardware resources beyond the resources set out in requirement 226f, and the type-approval authorities give their authorisation to the software updates based on the existing type-approved vehicle unit, in accordance with Article 12(5) of Regulation (EU) No 165/2014. (226e) The software update function shall be designed for supporting the following functional features, whenever they are legally required: — modification of the functions referred to in point 2.2, except the software update function itself, — the addition of new functions directly related to the enforcement of Union legislation on road transport, — modification of the modes of operation in point 2.3, — modification of the file structure such as the addition of new data or the increase of the file size, — deployment of software patches to address software as well as security defects or reported attacks on the functions of the recording equipment. (226f) The vehicle unit shall provide free hardware resources of at least 35% for software and data needed for the implementation of requirement 226e and free hardware resources of at least 65% for the update of the digital map based on the hardware resources required for the NUTS 0 map version 2021.’;

(25) in point 4.1, after paragraph (235), the image ‘Community model tachograph cards’, the reverse side of the control card is replaced by the following: ‘ ’;

(26) point 4.5 is amended as follows: (a) paragraph (246) is replaced by the following: ‘(246) Any additional data may be stored on tachograph cards, provided that the storage of those data complies with the applicable legislation regarding data protection.’; (b) in paragraph (247), the following note is inserted after the second indent: ‘Note: version 2 of second generation cards contains additional Elementary Files in DF Tachograph_G2.’; (c) point 4.5.3.2 is amended as follows: (i) the header is replaced by the following: ‘4.5.3.2 Tachograph generation 2 application (not accessible to first generation vehicle units, accessible to version 1 and version 2 of second generation vehicle units)’; (ii) the following point 4.5.3.2.1.1 is inserted after point 4.5.3.2.1: ‘4.5.3.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units) (278a) The driver card shall be able to store additional application identification data only applicable for version 2.’; (iii) in point 4.5.3.2.7, paragraph (287) is replaced by the following: ‘(287) The driver card shall be able to store data for the 12 most recent events of each type (i.e. 132 events).’; (iv) in point 4.5.3.2.8, paragraph (290) is replaced by the following: ‘(290) The driver card shall be able to store data for the 24 most recent faults of each type (i.e. 48 faults).’; (v) in point 4.5.3.2.9, paragraph (292) is replaced by the following: ‘(292) The driver card memory shall be able to hold driver activity data for 56 days (the average activity of a driver is defined for this requirement as 117 activity changes per day).’; (vi) in point 4.5.3.2.10, paragraph (295) is replaced by the following: ‘(295) The driver card shall be able to store 200 such records.’; (vii) in point 4.5.3.2.11, paragraph (297) is replaced by the following: ‘(297) The driver card memory shall be able to hold 112 such records.’; (viii) in point 4.5.3.2.14, paragraph (302) is replaced by the following: ‘(302) The driver card shall be able to store 112 such records.’; (ix) in point 4.5.3.2.15, paragraph (304) is replaced by the following: ‘(304) The driver card shall be able to store 200 such records.’; (x) in point 4.5.3.2.16, paragraph (306) is replaced by the following: ‘(306) The driver card shall be able to store 336 such records.’; (xi) the following points 4.5.3.2.17 to 4.5.3.2.22 are added: ‘4.5.3.2.17 Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units) (306a) The driver card shall be able to store additional data related to places where daily work periods begin and/or end, entered by the driver in accordance with point 4.5.3.2.11: — the date and time of the entry, which shall be exactly the same date and time as the one stored in EF Places under the DF Tachograph_G2, — a flag indicating whether the position has been authenticated. (306b) The driver card memory shall be able to hold 112 such records. 4.5.3.2.18 Authentication status for positions where three hours accumulated driving time are reached (not accessed by version 1 of second generation vehicle units) (306c) The driver card shall be able to store additional data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours in accordance with point 4.5.3.2.16: — the date and time when the accumulated driving time reaches a multiple of three hours, which shall be exactly the same date and time as the one stored in EF GNSS_Places under the DF Tachograph_G2, — a flag indicating whether the position has been authenticated. (306d) The driver card shall be able to store 336 such records. 4.5.3.2.19 Border crossings (not accessed by version 1 of second generation vehicle units) (306e) The driver card shall be able to store the following data related to border crossings either upon card insertion in accordance with requirement 147b or with the card already inserted: — the country that the vehicle is leaving, — the country that the vehicle is entering, — the date and time when the vehicle has crossed the border, — the position of the vehicle when the border was crossed, — the GNSS accuracy, — a flag indicating whether the position has been authenticated, — the vehicle odometer value. (306f) The driver card memory shall be able to store 1120 such records. 4.5.3.2.20 Load/unload operations (not accessed by version 1 of second generation vehicle units) (306g) The driver card shall be able to store the following data related to load/unload operations: — operation type (load, unload or simultaneous load/unload), — the date and time of the load/unload operation, — the position of the vehicle, — the GNSS accuracy, date and time when the position was determined, — a flag indicating whether the position has been authenticated, — the vehicle odometer value. (306h) The driver card shall be able to store 1624 load/unload operations. 4.5.3.2.21 Load type entries (not accessed by version 1 of second generation vehicle units) (306i) The driver card shall be able to store the following data related to load type automatically entered by the VU at each card insertion: — the load type entered (goods or passengers), — the date and time of the entry. (306j) The driver card shall be able to store 336 such records. 4.5.3.2.22 VU configurations (not accessed by version 1 of second generation vehicle units) (306k) The driver card shall be able to store the cardholder tachograph specific settings. (306l) The driver card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’; (d) point 4.5.4.2 is amended as follows: (i) the header is replaced by the following: ‘4.5.4.2 Tachograph Generation 2 application (not accessible to first generation vehicle units, accessible to version 1 and version 2 of second generation vehicle units)’; (ii) the following point 4.5.4.2.1.1 is inserted after point 4.5.4.2.1: ‘4.5.4.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units) (330a) The workshop card shall be able to store additional application identification data only applicable for version 2.’; (iii) in point 4.5.4.2.6, paragraph (338) is replaced by the following: ‘(338) The workshop card shall be able to store 255 such records.’; (iv) in point 4.5.4.2.8, paragraph (344) is replaced by the following: ‘(344) The workshop card shall be able to hold driver activity data for 1 day containing 240 activity changes.’; (v) in point 4.5.4.2.9, paragraph (346) is replaced by the following: ‘(346) The workshop card shall be able to store 8 such records.’; (vi) point 4.5.4.2.10 is replaced by the following: ‘4.5.4.2.10 Places and positions where daily work periods start and/or end data (347) The workshop card shall be able to store places and positions where daily work periods begin and/or end data records in the same manner as a driver card. (348) The workshop card shall be able to store 4 pairs of such records.’; (vii) in point 4.5.4.2.13, paragraph (352) is replaced by the following: ‘(352) The workshop card shall be able to store 8 such records.’; (viii) in point 4.5.4.2.14, paragraph (354) is replaced by the following: ‘(354) The workshop card shall be able to store 24 such records.’; (ix) in point 4.5.4.2.15, paragraph (356) is replaced by the following: ‘(356) The workshop card shall be able to store 4 such records.’; (x) the following points 4.5.4.2.16 to 4.5.4.2.22 are added: ‘4.5.4.2.16 Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units) (356a) The workshop card shall be able to store additional data related to places where daily work periods start and/or end in the same manner as a driver card. (356b) The workshop card memory shall be able to store 4 pairs of such records. 4.5.4.2.17 Authentication status for positions where three hours accumulated driving are reached (not accessed by version 1 of second generation vehicle units) (356c) The workshop card shall be able to store additional data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours in the same manner as a driver card. (356d) The workshop card shall be able to store 24 such records. 4.5.4.2.18 Border crossings (not accessed by version 1 of second generation vehicle units) (356e) The workshop card shall be able to store the border crossings in the same manner as a driver card. (356f) The workshop card memory shall be able to store 4 such records. 4.5.4.2.19 Load/unload operations (not accessed by version 1 of second generation vehicle units) (356g) The workshop card shall be able to store the load/unload operations in the same manner as a driver card. (356h) The workshop card shall be able to store 8 load, unload or simultaneous load/unload operations. 4.5.4.2.20 Load type entries (not accessed by version 1 of second generation vehicle units) (356i) The workshop card shall be able to store the load type entries in the same manner as a driver card. (356j) The workshop card shall be able to store 4 such records. 4.5.4.2.21 Calibration Additional Data (not accessed by version 1 of second generation vehicle units) (356k) The workshop card shall be able to store additional calibration data only applicable for version 2: — the old date and time and the vehicle identification number, which shall be exactly the same values as the one stored in EF Calibration under the DF Tachograph_G2, — the by-default load type entered during this calibration, — the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver. (356l) The workshop card shall be able to store 255 such records. 4.5.4.2.22 VU configurations (not accessed by version 1 of second generation vehicle units) (356m) The workshop card shall be able to store the cardholder tachograph specific settings. (356n) The workshop card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’; (e) point 4.5.5 is amended as follows: (i) in point 4.5.5.1.5 the second indent is replaced by the following: ‘- type of the control (displaying and/or printing and/or VU downloading and/or card downloading),’; (ii) the following point 4.5.5.2.1.1 is inserted after point 4.5.5.2.1: ‘4.5.5.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units) (363a) The control card shall be able to store additional application identification data only applicable for version 2.’; (iii) the following point is inserted after point 4.5.5.2.5: ‘4.5.5.2.6 VU configurations (not accessed by version 1 of second generation vehicle units) (368a) The control card shall be able to store the cardholder tachograph specific settings. (368b) The control card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’; (f) point 4.5.6.2 is amended as follows: (i) the following point is inserted after point 4.5.6.2.1: ‘4.5.6.2.1.1 Additional application identification (not accessed by version 1 of second generation vehicle units) (375a) The company card shall be able to store additional application identification data only applicable for version 2.’; (ii) the following point 4.5.6.2.6 is added: ‘4.5.6.2.6 VU configurations (not accessed by version 1 of second generation vehicle units) (380a) The company card shall be able to store the cardholder tachograph specific settings. (380b) The company card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’;

(27) point 5 is amended as follows: (a) point 5.1 is amended as follows: (i) paragraph (383) is replaced by the following: ‘(383) Before its activation, the recording equipment shall neither record nor store data referred to by the requirements 102 to 133 inclusive. Nevertheless, before its activation, the recording equipment may record and store the security breach attempt events in accordance with requirement 117, and the recording equipment faults in accordance with requirement 118.’; (ii) paragraph (392) is replaced by the following: ‘(392) Installation shall be followed by a calibration. The first calibration may not necessarily include entry of the vehicle registration identification (VRN and Member State), when it is not known by the approved workshop having to undertake this calibration. In these circumstances, it shall be possible, for the vehicle owner, and at this time only, to enter the VRN and the Member State using his company card prior to using the vehicle in scope of Regulation (EC) No 561/2006 (e.g by using commands through an appropriate menu structure of the vehicle unit's man-machine interface). Any update or confirmation of this entry shall only be possible using a workshop card.’; (b) point 5.2 is amended as follows: (i) the first subparagraph in paragraph (395) is replaced by the following: ‘After the recording equipment has been checked on installation, an installation plaque, engraved or printed in a permanent way, which is clearly visible and easily accessible shall be affixed onto the recording equipment. In cases where this is not possible, the plaque shall be affixed to the vehicle's ‘B’ pillar so that it is clearly visible. For vehicles that do not have a ‘B’ pillar, the installation plaque should be affixed in the area of the door of the vehicle and be clearly visible in all cases.’; (ii) paragraph (396) is amended as follows: (1) the tenth indent is replaced by the following: ‘- the serial number of the remote communication facility, if any,’; (2) the following sixteenth indent is added: ‘- the by-default load type associated to the vehicle.’;

(28) point 6.4 is amended as follows: (a) paragraph (409) is replaced by the following: ‘(409) Periodic inspections of the equipment fitted to the vehicles shall take place after any repair of the equipment, or after any alteration of the characteristic coefficient of the vehicle or of the effective circumference of the tyres, or after equipment UTC time is wrong by more than 5 minutes, or when the VRN has changed, and at least once within two years (24 months) of the last inspection.’; (b) in paragraph (410), the following ninth indent is added: ‘- that the version identifier of the stored digital map is the most recent one.’; (c) the following paragraph (410a) is inserted: ‘(410a) In case of detection of a manipulation by the competent national authorities, the vehicle may be sent to an authorised workshop for a recalibration of the recording equipment.’;

(29) point 8 is amended as follows: (a) in point 8.1, paragraphs (429) and (430) are replaced by the following: ‘(429) Procedures to update in-situ recording equipment software shall be approved by the authority which granted type approval for the recording equipment. Software update must not alter nor delete any driver activity data stored in the recording equipment. Software may be updated only under the responsibility of the equipment manufacturer. (430) Type approval of software modifications aimed to update a previously type approved recording equipment may not be refused if such modifications only apply to functions not specified in this Annex. Software update of a recording equipment may exclude the introduction of new character sets, if not technically feasible.’; (b) point 8.4 is amended as follows: (i) paragraph (443) is replaced by the following: ‘(443) No interoperability tests shall be carried out by the laboratory, for recording equipment or tachograph cards that have not passed the vulnerability analysis of their security evaluation and a functional evaluation, except in the exceptional circumstances described in requirement 432.’; (ii) paragraph (447) is replaced by the following: ‘(447) The interoperability certificate shall be issued by the laboratory to the manufacturer only after all required interoperability tests have been successfully passed and after the manufacturer has shown that both a valid functional certificate and a valid security certificate for the product has been granted, except in the exceptional circumstances described in requirement 432.’;

(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

81

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

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 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

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

ECC signature of all preceding data. ’; (c) in point 3.3, paragraph DDP_035 is replaced by the following ‘DDP_035 The download of a tachograph card includes the following steps: — Download the common information of the card in the EFs ICC and IC. This information is optional and is not secured with a digital signature. — For first and second generation tachograph cards — Download EFs within Tachograph DF: — Download the EFs Card_Certificate and CA_Certificate. This information is not secured with a digital signature. It is mandatory to download these files for each download session. — Download the other application data EFs (within Tachograph DF) except EF Card_Download. This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part A. — It is mandatory to download at least the EFs Application_Identification and Identification for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions. — For second generation tachograph cards only: — Except when a download of a driver card inserted in a VU is performed during drivers' control by a non EU control authority, using a first generation control card, download EFs within Tachograph_G2 DF: — Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate. This information is not secured with a digital signature. — It is mandatory to download these files for each download session. — Download the other application data EFs (within Tachograph_G2 DF) except EF Card_Download. This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part B. — It is mandatory to download at least the EFs Application_Identification, Application_Identification_V2 (if present) and Identification for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS_Places, Places_Authentication, if present, GNSS_Places_Authentication, if present, Border_Crossings, if present, Load_Unload_Operations, if present, Load_Type_Entries, if present. — When downloading a driver card, update the LastCardDownload date in EF Card_Download, in the Tachograph and, if applicable, Tachograph_G2 DFs. — When downloading a workshop card, reset the calibration counter in EF Card_Download in the Tachograph and, if applicable, Tachograph_G2 DFs. — When downloading a workshop card the EF Sensor_Installation_Data in the Tachograph and, if applicable, Tachograph_G2 DFs shall not be downloaded.’;

(35) Appendix 8 is amended as follows: (a) the Table of Content is amended as follows: (i) points 8, 8.1 and 8.2 are replaced by the following: ‘8. ROUTINECONTROL SERVICE (TIME ADJUSTMENT) 8.1. Message description 8.2. Message format’; (ii) the following points 9, 9.1 and 9.2 are added: ‘9. DATARECORDS FORMATS 9.1. Transmitted parameter ranges 9.2. dataRecords formats’; (b) in point 3.1, the following row is added to Table 1: ‘ Diagnostic Sessions RoutineControl 8 31 ’; (c) in point 6.1.3, paragraph CPR_053 is replaced by the following: ‘CPR_053 recordDataIdentifier values defined by this document are shown in the table below. The recordDataIdentifier table consists of five columns and multiple lines. — The 1^st column (Hex) includes the ‘Hex Value’ assigned to the recordDataIdentifier specified in the 3^rd column. — The 2^nd column (Data element) specifies the data element of Appendix 1 on which the recordDataIdentifier is based (transcoding is sometimes necessary). — The 3^rd column (Description) specifies the corresponding recordDataIdentifier name. — The 4^th column (Access rights) specifies the access rights to this recordDataIdentifier. — The 5^th column (Mnemonic) specifies the mnemonic of this recordDataIdentifier. Table 28 Definition of recordDataIdentifier values Hex Data element recordDataIdentifier Name (see format in Section 8.2) Access rights (Read/Write) Mnemonic F90B CurrentDateTime TimeDate R/W RDI_TD F912 HighResOdometer HighResolutionTotalVehicleDistance R/W RDI_HRTVD F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF F921 TyreSize TyreSize R/W RDI_TS F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN F190 VehicleIdentificationNumber VIN R/W RDI_ VIN F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN F9D1 RemoteCommunicationModuleSerialNumber RemoteCommunicationFacilitySerialNumber R RDI_RCSN F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerialNumber R RDI_GSSN F9D3 SealDataVu SmartTachographSealsSerialNumber R/W RDI_SDV F9D4 VuSerialNumber VuSerialNumber R RDI_VSN F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppression R/W RDI_TCG1S F9D7 VehiclePosition VehiclePosition R RDI_VP F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC ’; (d) point 8 is replaced by the following: ‘8. ROUTINECONTROL SERVICE (TIME ADJUSTMENT) 8.1. Message description CPR_065a The service RoutineControl (TimeAdjustment) provides the ability to trigger an alignment of the VU clock to the time provided by the GNSS receiver. For the service RoutineControl (TimeAdjustment) execution the VU must be in CALIBRATION mode. Precondition: it is ensured that the VU is able to receive authenticated position messages from the GNSS receiver. As long the time adjustment is ongoing, the VU shall respond to the request RoutineControl, subfunction requestRoutineResults, with routineInfo = 0x78. Note: the time adjustment may take some time. The diagnostic tester shall request the time adjustment status by using the sub-function requestRoutineResults. 8.2. Message format CPR_065b The message formats for the service RoutineControl (TimeAdjustment) and its primitives are detailed in the following tables. Table 37a RoutineControl, routine (TimeAdjustment) Request Message, subfunction startRoutine Byte # Parameter Name Hex Value Mnemonic

1

Format byte - physical addressing 80 FMT

2

Target address byte EE TGT

3

Source address byte tt SRC

4

Additional length byte xx LEN #5 RoutineControl Request Sid 31 RC

6

routineControlType = [startRoutine] 01 RCTP_STR

7 and #8

routineIdentifier = [TimeAdjustment] 0100 RI_TA

9

Checksum 00-FF CS Table 37b RoutineControl, routine (TimeAdjustment), subfunction startRoutine, Positive Response Message Byte # Parameter Name Hex Value Mnemonic

1

Format byte – physical addressing 80 FMT

2

Target address byte tt TGT

3

Source address byte EE SRC

4

Additional length byte xx LEN #5 RoutineControl Positive Response Sid 71 RCPR

6

routineControlType = [startRoutine] 01 RCTP_STR

7 and #8

routineIdentifier= [TimeAdjustment] 0100 RI_TA

9

Checksum 00-FF CS Table 37c RoutineControl, routine (TimeAdjustment) Request Message, subfunction requestRoutineResults Byte # Parameter Name Hex Value Mnemonic

1

Format byte - physical addressing 80 FMT

2

Target address byte EE TGT

3

Source address byte tt SRC

4

Additional length byte xx LEN #5 RoutineControl Request Sid 31 RC

6

routineControlType = [requestRoutineResults] 03 RCTP_RRR

7 and #8

routineIdentifier= [TimeAdjustment] 0100 RI_TA

9

Checksum 00-FF CS Table 37d RoutineControl, routine (TimeAdjustment), subfunction requestRoutineResults, Positive Response Message Byte # Parameter Name Hex Value Mnemonic

1

Format byte – physical addressing 80 FMT

2

Target address byte tt TGT

3

Source address byte EE SRC

4

Additional length byte xx LEN #5 RoutineControl Positive Response Sid 71 RCPR

6

routineControlType = [requestRoutineResults] 03 RCTP_RRR

7 and #8

routineIdentifier= [TimeAdjustment] 0100 RI_TA

9

routineInfo (see Table 37f) XX RINF_TA

10

routineStatusRecord[] = routineStatus#1 (see Table 37g) XX RS_TA

11

Checksum 00-FF CS Table 37e RoutineControl, routine (TimeAdjustment) Negative Response Message Byte # Parameter Name Hex Value Mnemonic

1

Format byte – physical addressing 80 FMT

2

Target address byte tt TGT

3

Source address byte EE SRC

4

Additional length byte 03 LEN #5 negativeResponse Service Id 7F NR

6

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

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

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

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

Structure of the AMC sentence $--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,ahh (1)Time (UTC) (2)Status, A=Authenticated position (established using at least 4 satellites from which the authenticity of the navigation messages has been successfully verified), J=jamming or O=other GNSS attack in the absence of failed authentication of navigation messages (by implemented consistency checks according to GNS_3a), F=failed authentication of navigation messages (as detected by OSNMA verifications specified in the documents referred to in GNS_3b), V=Void (authenticated position is not available for any other reason) (3)Latitude (4)N or S (5)Longitude (6)E or W (7)Speed over ground in knots (8)Track made good, degrees true (9)Date, ddmmyy (10)Magnetic Variation, degrees (11)E or W (12)FAA Mode Indicator (13)Navigational status (14)Checksum The Navigational status is optional and may not be present in the AMC sentence. The Status gives indication if an authenticated GNSS position is available, if an attack on the GNSS signals has been detected, if authentication of navigation messages has failed, or if GNSS position is void. When the value of the Status is not set to ‘A’, the received data (e.g. Time or Latitude/Longitude) are considered to be not valid, and may not be used to record the position of the vehicle in the VU. When the value of the Status is set to ‘J’ (jamming), ‘O’ (other GNSS attack), or ‘F’ (failed authentication of navigation messages), a GNSS anomaly event shall be recorded in the VU, as defined in Annex IC and Appendix 1 (EventFaultCode). GNS_5 The Vehicle Unit shall store in the VU database the position information for latitude and longitude with a resolution of 1/10 of minute or 1/600 of a degree as described in Appendix 1 for type GeoCoordinates. The GPS DOP and active satellites (GSA) command, as from NMEA V4.11 standard, can be used by the VU to determine and record the signal availability and accuracy of standard positions. In particular the HDOP is used to provide an indication on the level of accuracy of the recorded location data (see 4.2.2). The VU will store the value of the Horizontal Dilution of Precision (HDOP) calculated as the minimum of the HDOP values collected on the available GNSS systems. The GNSS Id. indicates the corresponding NMEA Id. for every GNSS constellation and Satellite-Based Augmentation System (SBAS). Figure 4*

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

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

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

552 1031 EF.ICC sensorGNSSSerialNumber

8 8

DF GNSS Facility

612 1023 EF EGF_MACertificate

204 341 EGFCertificate

204 341 {00..00} EF CA_Certificate

204 341 MemberStateCertificate

204 341 {00..00} EF Link_Certificate

204 341 LinkCertificate

204 341 {00..00}

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

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

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

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

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

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

Consistent Authenticated and Standard (non-authenticated) positions GNS_40 When the value of the Status in a received AMC sentence is set to ‘J’ or ‘O’ or ‘F’ in accordance with requirement GNS_4a, the VU shall generate and record a GNSS anomaly event, as defined in requirement 88a of Annex IC and Appendix 1 (EventFaultType). The vehicle unit may perform additional checks before storing a GNSS anomaly event following the reception of a ‘J’ or ‘O’ setting.

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

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

1.1. Scope 1.2. Acronyms and definitions

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

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

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

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

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

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

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

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

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

Example of split daily rest period interrupted due to ferry/train crossing When the split daily rest period is interrupted, the VU: — shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and — shall start a new RTM-shift at the end of the split daily rest period that has been interrupted; (k) ‘week’ is the period in UTC time between 00:00 hours on Monday and 24:00 hours on Sunday; 3.Computation of the rest period when it has been interrupted due to ferry/train crossing For the computation of the rest period when it has been interrupted due to ferry/train crossing, the VU shall calculate the accumulated rest time according to the following steps:

The VU shall detect interruptions to the rest time occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag, according to figure 3 and in its case figure 4, and shall evaluate for each interruption detected if the following conditions are met: — the interruption makes the total duration of the interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to exceed more than one hour in total, — the interruption makes the total number of interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to be bigger than two, — there is an ‘Entry of place where daily work periods end’ stored after the interruption ended. If none of the above conditions are met, the continuous rest period immediately preceding the interruption shall be added to the accumulated rest time. If at least one of the above conditions is met, the VU shall either stop the computation of the accumulated rest time according to step 2 or detect interruptions to the rest time occurring after the FERRY/TRAIN CROSSING (BEGIN) flag according to step 3.

For each interruption detected according to step 1, the VU shall evaluate whether the computation of the accumulated rest time should stop. The VU shall stop the computation process when two continuous rest periods occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag have been added to the accumulated rest time, including in its case rest periods added in the first part of a split daily rest period also interrupted by ferry/train crossing. Otherwise, the VU shall proceed according to step 3.

If after performance of step 2 the VU continues the computation of the accumulated rest time, the VU shall detect interruptions occurring after the deactivation of the FERRY/TRAIN CROSSING condition according to figure 3 and in its case figure 4. For each interruption found, the VU shall evaluate if the interruption makes the accumulated time of all the interruptions detected to exceed more than one hour in total, in which case the computation of the accumulated rest period shall finish at the end of the continuous rest period previous to the interruption. Otherwise, the continuous rest periods occurring after the respective interruptions shall be added to the computation of the daily rest period until the condition in step 4 is fulfilled.

The computation of the accumulated rest time shall stop when the VU has added, as result of steps 1 and 3, a maximum of two continuous rest periods to the rest period for which the FERRY/TRAIN CROSSING condition is activated, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing. Figure 3.

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

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

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

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

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

Example of a split daily rest period interrupted once during the first rest period and once during 2^nd rest period 4.Computation of daily, weekly and fortnightly- driving times The VU shall compute the daily driving time(s) for the ongoing and previous RTM-shifts. The driving time occurring during the interruptions of the daily rest periods shall not be added to the computation of the daily driving time, when such interruptions are due to ferry/train crossing and the requirements provided for in paragraphs (h) and (j) of point 2 and in point 3 have been fulfilled. Nevertheless, insofar as a complete regular or split daily rest period has not been computed by the VU according to point 3, the driving times occurring during the interruptions shall be added to the daily driving time for the ongoing RTM-shift. The VU shall also compute the weekly and the fortnightly driving times. The driving time occurring during the interruptions of the daily rest periods due to ferry/train crossing shall be added to the computation of the weekly and the fortnightly driving times.

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

MIGRATION: MANAGING THE CO-EXISTENCE OF EQUIPMENT GENERATIONS AND VERSIONS; (b) the Table of Content is amended as follows: (i) point 2.2 is replaced by the following: ‘2.2. Interoperability between VU and cards’; (ii) the following point 5 is added: ‘5. RECORDING OF BORDER CROSSINGS IN FIRST GENERATION AND FIRST VERSION OF SECOND GENERATION TACHOGRAPHS’; (c) points 2 to 4 are replaced by the following: ‘2. GENERAL PROVISIONS 2.1. Overview of the transition The introduction of this Annex provides an overview of the transition between the first and the second generation tachograph systems, and of the introduction of the second version of second generation recording equipment and tachograph cards. In addition to the provisions of this introduction, the following information can be reminded: — first generation motion sensors are not interoperable with any version of second generation vehicle units, — only second generation motion sensors can be installed in vehicles equipped with any version of second generation vehicle units, — data download and calibration equipment need to support use of both generations or versions of recording equipment and tachograph cards. 2.2. Interoperability between VU and cards It is understood that first generation tachograph cards are interoperable with first generation vehicle units (in compliance with Annex IB of Regulation (EEC) No 3821/85), any version of second generation tachograph cards are interoperable with any version of second generation vehicle units (in compliance with Annex IC of this Regulation). In addition, the requirements below shall apply. MIG_001 Except as provided for in requirement MIG_004 and MIG_005, first generation tachograph cards may continue to be used in any version of second generation vehicle units until their end of validity date. Their holders may however ask for their replacement by second generation tachograph cards as soon as they are available. MIG_002 Any version of second generation vehicle units shall be able to use any valid first generation driver, control and company card inserted. MIG_003 This capability may be suppressed once and forever in such vehicle units by workshops, so that first generation tachograph cards cannot be accepted anymore. This may only be done after the European Commission has launched a procedure aiming to request workshops to do so, for example during each periodic inspection of tachograph. MIG_004 Second generation vehicle units shall only be able to use second generation workshop cards. MIG_005 For determining the mode of operation, any version of second generation vehicle units shall only consider the types of the valid cards inserted, regardless of their generations or versions. MIG_006 Any version of valid second generation tachograph card shall be able to be used in first generation vehicle units exactly the same manner as a first generation tachograph card of the same type. 2.3. Interoperability between VU and MS It is understood that first generation motion sensors are interoperable with first generation vehicle units, while second generation motion sensors are interoperable with any version of second generation vehicle units. In addition, the requirements below shall apply. MIG_007 Any version of second generation vehicle units shall not be able to be paired and used with first generation motion sensors. MIG_008 Second generation motion sensors may be paired and used with second generation vehicle units only, whichever the version, or with both generations of vehicle units. 2.4. Interoperability between vehicle units, tachograph cards and equipment for data download MIG_009 Equipment for data download may be compatible with all generations and versions of vehicle units and tachograph cards. 2.4.1 Direct card download by IDE MIG_010 Data shall be downloaded by IDE from tachograph cards of one generation inserted in their card readers, using the security mechanisms and the data download protocol of this generation, and downloaded data shall have the format defined for this generation and version. MIG_011 To allow drivers’ control by non EU control authorities, it shall also be possible to download second generation driver (and workshop) cards, whichever the version, in exactly the same manner as first generation drivers (and workshop) cards. Such download shall include: — non signed EFs IC and ICC (optional), — non signed EFs (first generation) Card_Certificate and CA_Certificate, — the other application data EFs (within DF Tachograph) requested by the first generation card download protocol. This information shall be secured with a digital signature, according to the first generation security mechanisms. Such download shall not include application data EFs only present in version 1 or version 2 second generation driver (and workshop) cards (application data EFs within DF Tachograph_G2). 2.4.2 Card download through a vehicle unit MIG_012 Data shall be downloaded from any version of second generation card, inserted in a first generation vehicle unit using the first generation data download protocol. The card shall answer to the vehicle unit commands exactly the same manner as a first generation card and downloaded data shall have the same format as data downloaded from a first generation card. MIG_013 Data shall be downloaded from a first generation card inserted in any version of second generation vehicle unit using the data download protocol defined in Appendix 7 of this Annex. The vehicle unit shall send commands to the card exactly the same manner as a first generation vehicle unit, and downloaded data shall respect the format defined for first generation cards. 2.4.3 Vehicle unit download MIG_014 Outside of the frame of drivers' control by non EU control authorities, data shall be downloaded from second generation vehicle units using the second generation security mechanisms, and the data download protocol specified in Appendix 7 of this Annex for the relevant version. MIG_015 To allow drivers' control by non EU control authorities, it may optionally also be possible to download data from any version of second generation vehicle units using the first generation security mechanisms. Downloaded data shall then have the same format as data downloaded from a first generation vehicle unit. This capability may be selected through commands in the menu. 2.5. Interoperability between VU and calibration equipment MIG_016 Calibration equipment shall be able to perform calibration of each generation or version of tachograph, using the calibration protocol of this generation or version. Calibration equipment may be compatible with all generations and versions of vehicle units.

MIG_017 Test keys and certificates shall be available to manufacturers at the publication date of this Annex. MIG_018 Interoperability tests shall be ready to start with version 2 of vehicle units and version 2 of tachograph cards if requested by manufacturers at the latest 15 months before the introduction date. MIG_019 For version 2 of generation 2 tachographs, tachograph cards and motion sensors, the same keys and certificates are used as for generation 2 version 1 equipment. MIG_020 Member States shall be able to issue version 2 of second generation workshop cards at the latest 1 month before the introduction date. MIG_021 Member States shall be able to issue all other types of version 2 of second generation tachograph cards at the latest 1 month before the introduction date.

MIG_022 With effect from the introduction date, Member States shall only issue version 2 of second generation tachograph cards. MIG_023 Vehicle units / motion sensors manufacturers shall be allowed to produce first generation vehicle units / motion sensors as long as they are used in the field, so that malfunctioning components can be replaced. MIG_023a With effect from the introduction date, malfunctioning version 1 of second generation vehicle units or external GNSS facilities shall be replaced with version 2 of second generation vehicle units or external GNSS facilities. MIG_024 Vehicle units / motion sensors manufacturers shall be allowed to request and obtain type approval maintenance of first generation vehicle units / motion sensors types or version 1 of second generation vehicle units already type approved.’; (d) the following point 5 is added: ‘5. RECORDING OF BORDER CROSSINGS IN FIRST GENERATION AND FIRST VERSION OF SECOND GENERATION TACHOGRAPHS MIG_025 The symbol of the country and, if applicable, the region that the driver enters after crossing a border of a Member State in application of Article 34(7) of Regulation (EU) No 165/2014, shall be entered as a place where the daily work period begins in accordance with the manual entry of places set out in requirements 60 of Annex IC to Regulation (EU) No 165/2014 and 50 of Annex IB to Regulation (EEC) No 3821/85.’;

(41) in appendix 16, paragraph ADA_012 is replaced by the following: ‘ADA_012 The adaptor input interface shall be able, if applicable, to multiply or divide the frequency pulses of the incoming speed pulses by a fixed factor, to adapt the signal to the k factor range defined by this Annex (2 400 to 25 000 pulses/km). This fixed factor may only be programmed by the adaptor manufacturer, and the approved workshop performing the adaptor installation.’