ISSN 1977-0677

Official Journal

of the European Union

L 273

European flag  

English edition

Legislation

Volume 64
30 July 2021


Contents

 

II   Non-legislative acts

page

 

 

REGULATIONS

 

*

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

1

 


 

(1)   Text with EEA relevance.

EN

Acts whose titles are printed in light type are those relating to day-to-day management of agricultural matters, and are generally valid for a limited period.

The titles of all other Acts are printed in bold type and preceded by an asterisk.


II Non-legislative acts

REGULATIONS

30.7.2021   

EN

Official Journal of the European Union

L 273/1


COMMISSION IMPLEMENTING REGULATION (EU) 2021/1228

of 16 July 2021

amending Implementing Regulation (EU) 2016/799 as regards the requirements for the construction, testing, installation, operation and repair of smart tachographs and their components

(Text with EEA relevance)

THE EUROPEAN COMMISSION,

Having regard to the Treaty on the Functioning of the European Union,

Having regard to Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport (1), and in particular Article 11 thereof,

Whereas:

(1)

Regulation (EU) No 165/2014 has introduced smart tachographs, which include a connection to the global navigation satellite system (‘GNSS’) facility, a remote early detection communication facility, and an interface with intelligent transport systems.

(2)

The technical requirements for the construction, testing, installation, operation and repair of tachographs and their components are set out in Commission Implementing Regulation (EU) 2016/799 (2).

(3)

Regulation (EU) No 165/2014 and Regulation (EC) No 561/2006 of the European Parliament and of the Council (3) have been amended by Regulation (EU) 2020/1054 of the European Parliament and of the Council (4). Regulation (EU) 2020/1054 requires additional features to be implemented in the smart tachograph. Consequently, a new version of the smart tachograph needs to be defined by amending Implementing Regulation (EU) 2016/799.

(4)

In accordance with Article 8(1) of Regulation (EU) No 165/2014, the position of the vehicle should be recorded automatically every time the vehicle crosses the border of a Member State and every time the vehicle performs loading or unloading activities.

(5)

The interface with Intelligent Transport Systems, which is optional in the version of the smart tachograph implemented as of 15 June 2019, should be mandatory for the new version of the smart tachograph.

(6)

The new version of the smart tachograph should be prepared to authenticate the Galileo Satellite signal as soon as the Galileo system becomes operational.

(7)

In order to avoid the physical replacement of the recording equipment whenever a modification to the technical specifications of the tachograph is adopted, it is necessary to ensure that future tachograph functionalities can be implemented and improved through software updates.

(8)

Implementing Regulation (EU) 2016/799 allows for an adaptor to be installed between the motion sensor and the tachograph for vehicles that, whilst having a weight below 3,5 tons, may occasionally overcome that threshold, for instance when towing a trailer. Following the amendment to Regulation (EC) No 561/2006, the obligation to fit a tachograph has been extended to vehicles above 2,5 tons. The mandatory fitting of the smart tachograph in light commercial vehicles makes necessary to enhance the level of security provided by the adaptor by fitting an internal sensor inside the tachograph, which is independent of the motion sensor signal.

(9)

The measures provided for in this Regulation are in accordance with the opinion of the committee established by Article 42(1) of Regulation (EU) No 165/2014,

HAS ADOPTED THIS REGULATION:

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.

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

Done at Brussels, 16 July 2021.

For the Commission

The President

Ursula VON DER LEYEN


(1)  OJ L 60, 28.2.2014, p. 1.

(2)  Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (OJ L 139, 26.5.2016, p. 1).

(3)  Regulation (EC) No 561/2006 of the European Parliament and of the Council of 15 March 2006 on the harmonisation of certain social legislation relating to road transport and amending Council Regulations (EEC) No 3821/85 and (EC) No 2135/98 and repealing Council Regulation (EEC) No 3820/85 (OJ L 102, 11.4.2006, p. 1).

(4)  Regulation (EU) 2020/1054 of the European Parliament and of the Council of 15 July 2020 amending Regulation (EC) No 561/2006 as regards minimum requirements on maximum daily and weekly driving times, minimum breaks and daily and weekly rest periods and Regulation (EU) No 165/2014 as regards positioning by means of tachographs (OJ L 249, 31.7.2020, p. 1).


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 15th 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 15th 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 (1),’;

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

Image 1

’;

(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).

Image 2

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

Image 3

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

Image 4

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

Image 5

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

Image 6

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

Image 7

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

Image 8

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

Image 9

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

Image 10

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.

Image 11

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

Image 12

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

Image 13

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

Image 14

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

Image 15

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

Image 16

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

Image 17

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.

Image 18

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.

Image 19

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.

Image 20

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.

Image 21

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.

Image 22

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.

Image 23

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:

Image 24

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

Image 25

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:

Image 26

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

Image 27 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.

Image 28

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:

Image 29

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.

Image 30

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

Image 31

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

Image 32

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

Image 33

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

Image 34

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.

Image 35

’;

(kk)

in point 2.205, the text corresponding to Generation 2 is replaced by the following:

‘Generation 2:

Image 36

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

Image 37

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

Image 38

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

Image 39

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.

Image 40

’;

(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).

Image 41

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

Image 42

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

Image 43

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_89 For 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:

Image 44

’;

(2)

the row corresponding to LastCardDownload is replaced by the following:

Image 45

’;

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

Image 46

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:

Image 47

Image 48

Image 49

’;

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

Image 50

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:

Image 51

Image 52

Image 53

Image 54

’;

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

Image 55

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:

Image 56

Image 57

’;

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

Image 58

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:

Image 59

’;

(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

Image 60

Out of scope

Image 61

Ferry/train crossing

Image 62

Load operation

Image 63

Unload operation

Image 64

Simultaneous load/unload operation

Image 65

Load type: passengers

Image 66

Load type: goods

Image 67

Load type: undefined load type’;

(ii)

the pictograms for miscellaneous are amended as follows:

(1)

the security pictogram is replaced by the following:

Image 68

Security/authenticated data/seals’;

(2)

the following pictogram is added

Image 69

Digital map/border crossing’;

(b)

point 2 is amended as follows:

(i)

the following pictogram combinations are added to the pictograms for miscellaneous:

 

Image 70

Position where the vehicle has crossed the border between two countries

Image 71

Position where a load operation has occurred

Image 72

Position where an unload operation has occurred

Image 73

Position where a simultaneous load/unload operation has occurred’;

(ii)

the following pictogram combination is added to the pictograms for printouts:

Image 74

Historic of inserted cards printout’;

(iii)

the following pictogram combination is added to the pictograms for events:

Image 75

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 Image 76 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:

Image 77

Image 78

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:

Image 79

’;

(v)

block 5 is replaced by the following: