(a)

point 3.12.5 is replaced by the following:

‘3.12.5.   Places and positions where daily work periods begin, end and/or where 3 hours accumulated driving time is reached’;

(b)

point 4.5.3.2.16 is replaced by the following:

‘4.5.3.2.16   Three hours accumulated driving places data’;

(c)

point 4.5.4.2.14 is replaced by the following:

‘4.5.4.2.14   Three hours accumulated driving places data’;

(d)

point 6.2 is replaced by the following:

‘6.2   Check of new or repaired components’;

(a)

definition (ll) is replaced by the following:

(b)

definition (tt) is replaced by the following:

(c)

the first dash of definition (yy) is replaced by the following:

(d)

a new definition (fff) is added:

‘—

the vehicle units have a normal operations validity period of 15 years, starting with the vehicle unit certificates effective date, but vehicle units can be used for additional 3 months, for data downloading only.’;

‘—

positions where the accumulated driving time reaches a multiple of three hours;’;

‘(49)

‘(59)

Under the following conditions temporary entry made at last card withdrawal is validated (i.e. shall not be overwritten anymore):

Under the following conditions temporary entry made at last card withdrawal is overwritten and the new value is validated:

‘—

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

(86)

‘—

ITS interface fault (if applicable)’;

(i)

the text before the table in paragraph (89) is replaced by the following:

‘The recording equipment shall detect faults through self-tests and built-in-tests, according to the following table:’;

(ii)

The following row is added to the table:

‘—

the average number of positions per day is defined as at least 6 positions where the daily work period begins, 6 positions when the accumulated driving time reaches a multiple of three hours, and 6 positions where the daily work period ends, so that “365 days” include at least 6570 positions,’;

(a)

the heading and paragraph (108) are replaced by the following:

‘3.12.5.   Places and positions where daily work periods begin, end and/or where 3 hours accumulated driving time is reached

(b)

the fourth dash of paragraph (110) is replaced by the following:

(c)

paragraph (111) is replaced by the following:

‘(116)

(a)

the following item is inserted between the items ‘Absence of position information from GNSS receiver’ and ‘Motion data error’:

(b)

The item ‘Time conflict’ is replaced by the following:

‘(200)

In Appendix 13, an optional ITS interface is specified and standardized. Other vehicle unit interfaces may co-exist, provided they fully comply with the requirements of Appendix 13 in term of minimum list of data, security and driver consent.

The driver consent doesn’t apply to data transmitted by the recording equipment to the vehicle network. In case the personal data injected in the vehicle network are further processed outside the vehicle network, it is the responsibility of the vehicle manufacturer to have that personal data process compliant with Regulation (EU) 2016/679 (“General Data Protection Regulation”).

The driver consent doesn’t apply either to tachograph data downloaded to a remote company (requirement 193), as this scenario is monitored by the company card access right.

The following requirements apply to ITS data made available through that interface:

Other data may also be output in addition to the set of selected existing data, considered as the minimum list, provided they cannot be considered as personal data.

The recording equipment shall have the capacity to communicate the driver consent status to other platforms in the vehicle network.

When the ignition of the vehicle is ON, these data shall be permanently broadcasted.’;

‘(211)

‘(225)

(226)

‘—

Card fault (where this card is the subject of the fault),’;

‘—

Card fault (where this card is the subject of the fault),’;

(305)

(306)

(353)

(354)

‘(396)

(a)

a new paragraph (398a) is inserted after paragraph (398):

(b)

in paragraph (401), the second sub-paragraph is replaced by the following:

‘This unique identification number is defined as: MMNNNNNNNN by non-removable marking, with MM as unique manufacturer identification (database registration to be managed by EC) and NNNNNNNN seal alpha-numeric number, unique in the manufacturer domain.’;

(c)

paragraph (403) is replaced by the following:

(d)

paragraph (404) is replaced by the following:

(407)

‘(408)

(a)

in point 8.1, the introduction text before paragraph (425) is replaced by the following:

‘For the purpose of this chapter, the words “recording equipment” mean “recording equipment or its components”. No type approval is required for the cable(s) linking the motion sensor to the VU, the external GNSS facility to the VU or the external remote communication facility to the VU. The paper, for use by the recording equipment, shall be considered as a component of the recording equipment.

Any manufacturer may ask for type approval of recording equipment component(s) with any other recording equipment component(s), provided each component complies with the requirements of this annex. Alternately, manufacturers may also ask for type approval of recording equipment.

As described in definition (10) in Article 2 of this Regulation, vehicle units have variants in components assembly. Whatever the vehicle unit components assembly, the external antenna and (if applicable) the antenna splitter connected to the GNSS receiver or to the remote communication facility are not part of the vehicle unit type approval.

Nevertheless, manufacturers having obtained type approval for recording equipment shall maintain a publicly available list of compatible antennas and splitters with each type approved vehicle unit, external GNSS facility and external remote communication facility.’;

(b)

paragraph (427) is replaced by the following:

(a)

the Table of Content is amended as follows:

(b)

in point 2, the following text is added before point 2.1:

‘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.’;

(c)

point 2.19 is replaced by the following:

‘2.19.   CardEventData

Generation 1:

Information, stored in a driver or workshop card, related to the events associated with the card holder (Annex IC requirements 260 and 318).

CardEventData is a sequence, ordered by ascending value of EventFaultType, of cardEventRecords (except security breach attempts related records which are gathered in the last set of the sequence).

cardEventRecords is a set of event records of a given event type (or category for security breach attempts events).

Generation 2:

Information, stored in a driver or workshop card, related to the events associated with the card holder (Annex IC requirements 285 and 341).

CardEventData is a sequence, ordered by ascending value of EventFaultType, of cardEventRecords (except security breach attempts related records which are gathered in the last set of the sequence).

cardEventRecords is a set of event records of a given event type (or category for security breach attempts events).’

(d)

point 2.30 is replaced by the following:

‘2.30.   CardRenewalIndex

A card renewal index (definition i)).

Value assignment: (see this Annex chapter 7).

Order for increase: “0, …, 9, A, …, Z” ’;

(e)

in point 2.61, the text after the heading Generation 2 is replaced by the following:

In addition to generation 1 the following data elements are used:

noOfGNSSADRecords is the number of GNSS accumulated driving records the card can store.

noOfSpecificConditionRecords is the number of specific condition records the card can store.

noOfCardVehicleUnitRecords is the number of vehicle units used records the card can store.’;

(f)

point 2.63 is replaced by the following:

‘2.63.   Reserved for future use’;

(g)

in point 2.67, the text under the heading ‘Generation 2’ is replaced by the following:

‘The same values as in generation 1 are used with the following additions:

(h)

in point 2.70, the text under the heading ‘Generation 2’ is replaced by the following:

‘Generation 2:

	General events, No further details, Insertion of a non valid card, Card conflict, Time overlap, Driving without an appropriate card, Card insertion while driving, Last card session not correctly closed, Over speeding, Power supply interruption, Motion data error, Vehicle Motion Conflict, Time conflict (GNSS versus VU internal clock), Communication error with the remote communication facility, Absence of position information from GNSS receiver, Communication error with the external GNSS facility, RFU,
	Vehicle unit related security breach attempt events, No further details, Motion sensor authentication failure, Tachograph card authentication failure, Unauthorised change of motion sensor, Card data input integrity error Stored user data integrity error, Internal data transfer error, Unauthorised case opening, Hardware sabotage, Tamper detection of GNSS, External GNSS facility authentication failure, External GNSS facility certificate expired, RFU,
	Sensor related security breach attempt events, No further details, Authentication failure, Stored data integrity error, Internal data transfer error, Unauthorised case opening, Hardware sabotage, RFU,
	Recording equipment faults, No further details, VU internal fault, Printer fault, Display fault, Downloading fault, Sensor fault, Internal GNSS receiver, External GNSS facility, Remote communication facility, ITS interface, RFU,
	Card faults, No further details, RFU,
	RFU,
	Manufacturer specific.’;

(i)

Point 2.71 is replaced by the following:

‘2.71.   ExtendedSealIdentifier

Generation 2:

The extended seal identifier uniquely identifies a seal (Annex IC requirement 401).

manufacturerCode is a code of the manufacturer of the seal.

sealIdentifier is an identifier for the seal which is unique for the manufacturer.’;

(j)

points 2.78 and 2.79 are replaced by the following:

‘2.78   GNSSAccumulatedDriving

Generation 2:

Information, stored in a driver or workshop card, related to the GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirement 306 and 354).

gnssADPointerNewestRecord is the index of the last updated GNSS accumulated driving record.

Value assignment is the number corresponding to the numerator of the GNSS accumulated driving record, beginning with '0' for the first occurrence of the GNSS accumulated driving record in the structure.

gnssAccumulatedDrivingRecords is the set of records containing the date and time the accumulated driving reaches a multiple of three hours and information on the position of the vehicle.

2.79.   GNSSAccumulatedDrivingRecord

Generation 2:

Information, stored in a driver or workshop card, related to the GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirement 305 and 353)

timeStamp is the date and time when the accumulated driving time reaches a multiple of three hours.

gnssPlaceRecord contains information related to the position of the vehicle.

vehicleOdometerValue is the odometer value when the accumulated driving time reaches a multiple of three hours.’;

(k)

point 2.86 is replaced by the following:

‘2.86.   KeyIdentifier

A unique identifier of a Public Key used to reference and select the key. It also identifies the holder of the key.

The first choice is suitable to reference the public key of a Vehicle Unit, of a tachograph card or of an external GNSS facility.

The second choice is suitable to reference the public key of a Vehicle Unit (in cases where the serial number of the Vehicle Unit cannot be known at certificate generation time).

The third choice is suitable to reference the public key of a Member State.’;

(l)

point 2.92 is replaced by the following:

‘2.92.   MAC

Generation 2:

A cryptographic check sum of 8, 12 or 16 bytes length corresponding to the cipher suites specified in Appendix 11.

(m)

point 2.111 is replaced by the following:

‘2.111.   NoOfGNSSADRecords

Generation 2:

Number of GNSS accumulated driving records a card can store.

Value assignment: see Appendix 2.’;

(n)

in point 2.120, the value assignment ‘16H’ is replaced by the following:

(o)

point 2.160 is replaced by the following:

‘2.160.   Reserved for future use’;

(p)

point 2.162 is replaced by the following:

‘2.162.   TimeReal

Code for a combined date and time field, where the date and time are expressed as seconds past 00h.00m.00s. on 1 January 1970 UTC.

Value assignment – Octet aligned: Number of seconds since midnight 1 January 1970 UTC.

The max. possible date/time is in the year 2106.’;

(q)

point 2.179 is replaced by the following:

‘2.179   VuCardRecord

Generation 2:

Information, stored in a vehicle unit, about a tachograph card used (Annex IC requirement 132).

cardNumberAndGenerationInformation is the full card number and generation of the card used (data type 2.74).

cardExtendedSerialNumber as read from the file EF_ICC under the MF of the card.

cardStructureVersion as read from the file EF_Application_Identification under the DF_Tachograph_G2.

cardNumber as read from the file EF_Identification under the DF_Tachograph_G2.’;

(r)

points 2.203 and 2.204 are replaced by the following:

‘2.203   VuGNSSADRecord

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

timeStamp is the date and time when the accumulated driving time reaches a multiple of three hours.

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.

gnssPlaceRecord contains information related to the position of the vehicle.

vehicleOdometerValue is the odometer value when the accumulated driving time reaches a multiple of three hours.

2.204   VuGNSSADRecordArray

Generation 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 and 110).

recordType denotes the type of the record (VuGNSSADRecord).

Value Assignment: See RecordType.

recordSize is the size of the VuGNSSADRecord in bytes.

noOfRecords is the number of records in the set records.

records is a set of GNSS accumulated driving records.’;

(s)

points 2.230 and 2.231 are replaced by the following:

‘2.230.   Reserved for future use

2.231.   Reserved for future use’;

(t)

in point 2.234, the text under the heading ‘Generation 2’ is replaced by the following:

In addition to generation 1 the following data elements are used:

noOfGNSSADRecords is the number of GNSS accumulated driving records the card can store.

noOfSpecificConditionRecords is the number of specific condition records the card can store.

noOfCardVehicleUnitRecords is the number of vehicle units used records the card can store’;

(a)

in point 1.1, the following abbreviations are added:

(b)

point 3.3 is amended as follows:

(c)

in point 3.4, paragraph TCS_29 is replaced by the following:

(d)

in point 3.5.1.1, the last indent in paragraph TCS_38 is replaced by the following:

(e)

in point 3.5.1.2, the last indent in paragraph TCS_41 is replaced by the following:

(f)

in point 3.5.2.1, the sixth indent in paragraph TCS_43 is replaced by the following:

(g)

point 3.5.2.1.1 is amended as follows:

(h)

in point 3.5.2.2, the sixth indent in paragraph TCS_50 is replaced by the following:

(i)

in point 3.5.2.3, paragraph TCS_52 is amended as follows:

(j)

in point 3.5.2.3, the sixth indent in paragraph TCS_53 is replaced by the following:

(k)

in point 3.5.3.2, the sixth indent in paragraph TCS_63 is replaced by the following:

(l)

in point 3.5.5, paragraph TCS_72 is replaced by the following:

(m)

in point 3.5.8, paragraph TCS_95 is replaced by the following:

(n)

in point 3.5.9, paragraph TCS_97 is replaced by the following:

(o)

in point 3.5.10, the following row is added to the table in paragraph TCS_101:

(p)

in point 3.5.11.2.3, the following paragraphs are added in paragraph TCS_114:

Similarly, in case an MSE: SET DST command referencing an EQT (i.e. a VU or a card) is sent to a control card, according to CSM_234 the referenced key is always an EQT_Sign key that has to be used for the verification of a digital signature. According to Figure 13 in Appendix 11, the control card will always have stored the relevant EQT_Sign public key. In some cases, the control card may have stored the corresponding EQT_MA public key. The control card shall always set the EQT_Sign public key for use when it receives an MSE: SET DST command.’;

(q)

point 3.5.13 is amended as follows:

(r)

point 3.5.14 is amended as follows:

the text below the heading and until paragraph TCS_126 is replaced by the following:

'This command is used to compute the digital signature of previously computed hash code (see PERFORM HASH of FILE, §3.5.13).

Only the driver card and the workshop card are required to support this command in the DF Tachograph and DF Tachograph_G2.

Other types of tachograph cards may or may not implement this command. In case of the Generation 2 tachograph application, only the driver card and the workshop card have a generation 2 signature key, other cards are not able to successfully perform the command and terminate with a suitable error code.

The command may or may not be accessible in the MF. If the command is not accessible in the MF, it shall terminate with a suitable error code.

This command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.';

(s)

point 3.5.15 is amended as follows:

(t)

point 3.5.16 is amended as follows:

(u)

point 4.2.2 is amended as follows:

(i)	in the data structure in paragraph TCS_154, the lines from DF Tachograph G2 to EF CardMA_Certificate, and the lines from EF GNSS_Places to the end of this paragraph are replaced by the following: ‘ Text of image File / Data element No of Records Size (bytes) Default Values Min Max ’

(ii)	in paragraph TCS_155, the item of the table is replaced by the following: ‘ 252 336’

(v)

in point 4.3.1, the text corresponding to the abbreviation SC4 in paragraph TCS_156 is replaced by the following:

(w)

point 4.3.2 is amended as follows:

(i)	in the data structure in paragraph TCS_162, the lines from DF Tachograph G2 to EF CardMA_Certificate, the lines from EF Calibration to extendedSealIdentifier and the lines from EF GNSS_Places to vehicleOdometerValue are replaced by the following: ‘ ’

(ii)	the item NoOfGNSSCDRecords of the table in paragraph TCS_163 is replaced by the following: ‘ 18 24’

(a)

the following line is inserted after the line with the pictograms ‘Location start of daily work period’ and ‘Location end of daily work period’:

‘

(b)

the pictogram combination ‘time adjustment (by workshop)’, is replaced by the following:

‘

(c)

the following pictogram combinations are added to the Events list:

‘

(a)

point 2 is amended as follows:

(ii)	block number 11.5 is replaced by the following: ‘11.5 Positions after 3 hours accumulated driving time pi=position after 3 hours accumulated driving time longitude of the recorded position latitude of the recorded position timestamp when position was determined Odometer ’

(b)

in point 3.1, position 11.5 of the daily printout format is replaced by the following:

(c)

in point 3.2, the daily printout format is replaced by the following:

(d)

in point 3.7, paragraph PRT_014 is replaced by the following:

(a)

point 1.1 is replaced by the following:

‘1.1.   Scope

Data may be downloaded to an ESM:

To give the possibility to verify the authenticity and integrity of downloaded data stored on an ESM, data is downloaded with a signature appended in accordance with Appendix 11 Common Security Mechanisms. The source equipment (VU or card) identification and its security certificates (Member state and equipment) are also downloaded. The verifier of the data must possess independently a trusted European public key.

Data downloaded from a VU are signed using Appendix 11 Common Security Mechanisms Part B (Second-generation tachograph system), except when drivers' control is performed by a non EU control authority, using a first generation control card, in which case data are signed using Appendix 11 Common Security Mechanisms Part A (First-generation tachograph system), as requested by Appendix 15 Migration, requirement MIG_015.

This Appendix specifies therefore two types of data downloads from the VU:

Similarly, there are two types of data downloads from second generation driver cards inserted in a VU, as specified in paragraphs 3 and 4 of this Appendix.’;

(b)

point 2.2.2 is amended as follows:

(c)

point 2.2.2.9 is amended as follows:

(ii)

paragraph DDP_054 is replaced by the following: ‘DDP_054 It is mandatory for the IDE to request the overview data transfer (TRTP 01 or 21) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature). In the second case (TRTP 02 or 22) the Transfer Data Request message includes the indication of the calendar day ( format) to be downloaded.’;

(d)

in point 2.2.2.10, paragraph DDP_055 is replaced by the following:

(e)

in point 2.2.2.16, the last dash in paragraph DDP_018 is replaced by the following:

(f)

point 2.2.6.1 is amended as follows:

(g)

point 2.2.6.2 is amended as follows:

(iv)

the item VuGNSSCDRecordArray under the heading ‘Data structure generation 2 (TREP 22 Hex)’, is replaced by the following: ‘   GNSS positions of the vehicle when the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent.’

(h)

point 2.2.6.3 is amended as follows:

(i)

point 2.2.6.4 is amended as follows:

(j)

point 2.2.6.5 is amended as follows:

(k)

in point 3.3, paragraph DDP_035 is replaced by the following:

‘DDP_035

The download of a tachograph card includes the following steps: — Download the common information of the card in the EFs and This information is optional and is not secured with a digital signature. — (for first and second generation tachograph cards) Download EFs within : — Download the EFs and This information is not secured with a digital signature. It is mandatory to download these files for each download session. — Download the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part A. — It is mandatory to download at least the EFs and for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Text of image Events_Data, Faults_Data, Text of image Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, — (for second generation tacograph cards only) Except when a download of a driver card inserted in a VU is performed during drivers' control by a non EU control authority, using a first generation control card, download EFs within : — Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate (if present). This information is not secured with a digital signature. It is mandatory to download these files for each download session. — Download the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part B. — It is mandatory to download at least the EFs and for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Text of image Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS Places. — When downloading a driver card, update the date in EF , in the and, if applicable, DFs. — When downloading a workshop card, reset the calibration counter in EF in the and, if applicable, DFs. — When downloading a workshop card the EF in the and, if applicable, DFs shall not be downloaded.’;

(l)

in point 3.3.2, the first subparagraph in paragraph DDP_037 is replaced by the following:

‘The sequence to download EFs ICC, IC, Card_Certificate (or CardSignCertificate for DF Tachograph_G2), CA_Certificate and Link_Certificate (for DF Tachograph_G2 only) is as follows:’;

(m)

in point 3.3.3, the table is replaced by the following:

‘Card	Dir	IDE / IFD	Meaning / Remarks
		Select File
OK
		Perform Hash of File	— Calculates the hash value over the data content of the selected file using the prescribed hash algorithm in accordance with Appendix 11, part A or B. This command is not an ISO-Command.
Calculate Hash of File and store Hash value temporarily
OK
		Read Binary	If the file contains more data than the buffer of the reader or the card can hold, the command has to be repeated until the complete file is read.
File Data OK		Store received data to ESM	according to 3.4 Data storage format
		PSO: Compute Digital Signature
Perform Security Operation “Compute Digital Signature” using the temporarily stored Hash value
Signature OK		Append data to the previous stored data on the ESM	according to 3.4 Data storage format’

(n)

in point 3.4.2, paragraph DDP_046 is replaced by the following:

‘DDP_046

A signature shall be stored as the next TLV object directly after the TLV object that contains the data of the file. Definition Meaning Length FID (2 Bytes) || “00” Tag for EF (FID) in the or for common information of the card 3 Bytes FID (2 Bytes) || “01” Tag for Signature of EF (FID) in the DF 3 Bytes FID (2 Bytes) || “02” Tag for EF (FID) in the DF 3 Bytes FID (2 Bytes) || “03” Tag for Signature of EF (FID) in the DF 3 Bytes xx xx Length of Value field 2 Bytes Example of data in a download file on an ESM: Tag Length Value — Data of EF ICC — Data of EF Card_Certificate     — … Data of EF (in the DF) Signature of EF (in the DF) Data of EF in the DF Signature of EF in the DF’