Legalize
Legalize / European Union / Implementing Regulation

Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)

Type Implementing Regulation
Publication 2018-03-28
State In force
Text As published
Department European Commission, MOVE
Source EUR-Lex
articles 2

This is the act as published. Later amendments are not folded into the text below: each one is a separate act in this repository and an entry in this law's history.

Reform history JSON API
28.3.2018 EN Official Journal of the European Union L 85/1

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 Articles 11 and 12(7) thereof,

Whereas:

HAS ADOPTED THIS REGULATION:

Article 1

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

‘2.   The construction, testing, installation, inspection, operation and repair of smart tachographs and their components, shall comply with the technical requirements set out in Annex IC to this Regulation.

  1. Tachographs other than smart tachographs shall continue, as regards construction, testing, installation, inspection, operation and repair, to comply with the requirements of either Annex I to Regulation (EU) No 165/2014 or Annex IB to Council Regulation (EEC) No 3821/85[^ntr*1-L_2018085EN.01000101-E0004], as applicable;

[^ntr*1-L_2018085EN.01000101-E0004]: Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (OJ L 370, 31.12.1985, p. 8).’;"

  • (b) the following paragraph 5 is added:

‘5.   This Regulation shall be without prejudice to Directive 2014/53/EU of the European Parliament and of the Council[^ntr*2-L_2018085EN.01000101-E0005].

[^ntr*2-L_2018085EN.01000101-E0005]: Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC (OJ L 153, 22.5.2014, p. 62).’;"

  • (2) Article 2 is amended as follows:
  • (a) definition (3) is replaced by the following:
  • ‘(3) “information folder” means the complete folder, in electronic or paper form, containing all the information supplied by the manufacturer or its agent to the type-approval authority for the purpose of the type-approval of a tachograph or a component thereof, including the certificates referred to in Article 12(3) of Regulation (EU) No 165/2014, the performance of the tests defined in Annex IC to this Regulation, as well as drawings, photographs, and other relevant documents;’;
  • ‘(7) “smart tachograph” or “second generation tachograph” means a digital tachograph complying with Articles 8, 9 and 10 of Regulation (EU) No 165/2014 as well as with Annex IC to this Regulation;’;
  • ‘(8) “tachograph component” means any of the following elements: the vehicle unit, the motion sensor, the record sheet, the external GNSS facility and the external remote early detection facility;’;
  • ‘(10) “vehicle unit” means the tachograph excluding the motion sensor and the cables connecting the motion sensor.

It may be a single unit or several units distributed in the vehicle and includes a processing unit, a data memory, a time measurement function, two smart card interface devices for driver and co-driver, a printer, a display, connectors and facilities for entering the user’s inputs, a GNSS receiver and a remote communication facility.

The vehicle unit may be composed of the following components subject to type-approval:

  • — vehicle unit, as a single component (including GNSS receiver and remote communication facility),
  • — vehicle unit main body (including remote communication facility), and external GNSS facility,
  • — vehicle unit main body (including GNSS receiver), and external remote communication facility,
  • — vehicle unit main body, external GNSS facility, and external remote communication facility.

If the vehicle unit is composed of several units distributed in the vehicle, the vehicle unit main body is the unit containing the processing unit, the data memory, and the time measurement function.

“vehicle unit (VU)” is used for “vehicle unit” or “vehicle unit main body” ’;

‘However, Annex IC shall apply from 15 June 2019 with the exception of Appendix 16 which shall apply from 2 March 2016.’;

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.

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

Done at Brussels, 28 February 2018.

For the Commission

The President

Jean-Claude JUNCKER

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

Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of radio equipment and repealing Directive 1999/5/EC (OJ L 153, 22.5.2014, p. 62).

ANNEX I

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

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

‘4.5.3.2.16   Three hours accumulated driving places data’;

‘4.5.4.2.14   Three hours accumulated driving places data’;

‘6.2   Check of new or repaired components’;

  • ‘(ll) “remote communication facility” or “remote early detection facility” means:

the equipment of the vehicle unit which is used to perform targeted roadside checks;’;

  • ‘(tt) “time adjustment” means:

an adjustment of current time; this adjustment can be automatic at regular intervals, using the time provided by the GNSS receiver as a reference, or performed in calibration mode;’;

  • ‘— installed and used only in M1 and N1 type vehicles (as defined in Annex II to Directive 2007/46/EC of the European Parliament and of the Council (*), as last amended),’;
  • ‘(fff) “accumulated driving time” means:

a value representing the total accumulated number of minutes of driving of a particular vehicle.

The accumulated driving time value is a free running count of all minutes regarded as DRIVING by the monitoring of driving activities function of the recording equipment, and is only used for triggering the recording of the vehicle position, every time a multiple of three hours of accumulated driving is reached. The accumulation is started at the recording equipment activation. It is not affected by any other condition, like out of scope or ferry/train crossing.

The accumulated driving time value is not intended to be displayed, printed, or downloaded;’;

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

‘The system security aims at protecting the data memory in such a way as to prevent unauthorised access to and manipulation of the data and detecting any such attempts, protecting the integrity and authenticity of data exchanged between the motion sensor and the vehicle unit, protecting the integrity and authenticity of data exchanged between the recording equipment and the tachograph cards, protecting the integrity and authenticity of data exchanged between the vehicle unit and the external GNSS facility, if any, protecting the confidentiality, integrity and authenticity of data exchanged through the remote early detection communication for control purposes, and verifying the integrity and authenticity of data downloaded.’;

  • ‘— positions where the accumulated driving time reaches a multiple of three hours;’;
  • ‘(49) The first change of activity to BREAK/REST or AVAILABILITY arising within 120 seconds of the automatic change to WORK due to the vehicle stop shall be assumed to have happened at the time of vehicle stop (therefore possibly cancelling the change to WORK).’;
  • ‘(59) The driver shall then enter the current place of the vehicle, which shall be considered as a temporary entry.

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 doesn’t 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 doesn’t enter any place where the work period begins or ended during the manual input according to requirement (61)’;
  • ‘— 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).’;

‘3.9.15   “Time conflict” event
(86) This event shall be triggered, while not in calibration mode, when the VU detects a discrepancy of more than 1 minute between the time of the vehicle unit’s time measurement function and the time originating from the GNSS receiver. This event is recorded together with the internal clock value of the vehicle unit and comes together with an automatic time adjustment. After a time conflict event has been triggered, the VU will not generate other time conflict events for the next 12 hours. This event shall not be triggered in cases where no valid GNSS signal was detectable by the GNSS receiver for 30 days or more.’;
  • (10) in point 3.9.17, the following dash is added:
  • ‘— ITS interface fault (if applicable)’;

‘The recording equipment shall detect faults through self-tests and built-in-tests, according to the following table:’;
‘ITS interface (optional) Proper operation’
  • ‘— 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,’;

‘3.12.5.   Places and positions where daily work periods begin, end and/or where 3 hours accumulated driving time is reached
(108) The recording equipment shall record and store in its data memory: — places and positions where the driver and/or co-driver begins his daily work period; — positions where the accumulated driving time reaches a multiple of three hours; — places and positions where the driver and/or the co-driver ends his daily work period.’;
  • (b) the fourth dash of paragraph (110) is replaced by the following:
  • ‘— The type of entry (begin, end or 3 hours accumulated driving time),’;
  • ‘(111) The data memory shall be able to hold places and positions where daily work periods begin, end and/or where 3 hours accumulated driving time is reached for at least 365 days’;
  • ‘(116) The recording equipment shall record and store in its data memory the instantaneous speed of the vehicle and the corresponding date and time at every second of at least the last 24 hours that the vehicle has been moving’;
‘Communication error with the external GNSS facility — the longest event 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.’
‘Time conflict — the most serious event for each of the 10 last days of occurrence (i.e. the ones with the greatest difference between recording equipment date and time, and GNSS date and time). — the 5 most serious events over the last 365 days. — recording equipment date and time — GNSS date and time, — 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.’
  • ‘(200) The recording equipment may also be equipped with standardised interfaces allowing the data recorded or produced by tachograph to be used in operational or calibration mode, by an external facility.

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:

  • — these data are a set of selected existing data from the tachograph data dictionary (Appendix 1),
  • — a subset of these selected data are marked “personal data”,
  • — the subset of “personal data” is only available if the verifiable consent of the driver, accepting his personal data can leave the vehicle network, is enabled,
  • — At any moment, the driver consent can be enabled or disabled through commands in the menu, provided the driver card is inserted,
  • — the set and subset of data will be broadcasted via Bluetooth wireless protocol in the radius of the vehicle cab, with a refresh rate of 1 minute,
  • — the pairing of the external device with the ITS interface will be protected by a dedicated and random PIN of at least 4 digits, recorded in and available through the display of each vehicle unit,
  • — in any circumstances, the presence of the ITS interface cannot disturb or affect the correct functioning and the security of the vehicle unit.

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) The time setting of the VU internal clock shall be automatically re-adjusted every 12 hours. When this re-adjustment is not possible because the GNSS signal is not available, the time setting shall be done as soon as the VU can access a valid time provided by GNSS receiver, according to the vehicle ignition conditions. The time reference for the automatic time setting of the VU internal clock shall be derived from the GNSS receiver.’;
  • ‘(225) A descriptive plaque shall be affixed to each separate component of the recording equipment and shall show the following details:
  • — name and address of the manufacturer,
  • — manufacturer's part number and year of manufacture,
  • — serial number,
  • — type-approval mark.
  • (226) When physical space is not sufficient to show all above mentioned details, the descriptive plaque shall show at least: the manufacturer's name or logo and the part number.’;

‘

Text of image

‘

’

’

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

‘4.5.3.2.16   Three hours accumulated driving places data
(305) The driver card shall be able to store the following data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours: — the date and time when the accumulated driving time reaches a multiple of three hours, — the position of the vehicle, — the GNSS accuracy, date and time when the position was determined, — the vehicle odometer value.
(306) The driver card shall be able to store at least 252 such records.’;
  • (23) point 4.5.4.2.14 is replaced by the following:

‘4.5.4.2.14   Three hours accumulated driving places data
(353) The workshop card shall be able to store the following data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours: — the date and time when the accumulated driving time reaches a multiple of three hours, — the position of the vehicle, — the GNSS accuracy, date and time when the position was determined, — the vehicle odometer value.
(354) The workshop card shall be able to store at least 18 such records’;
  • (24) in point 5.2, paragraph (396) is replaced by the following:
  • ‘(396) The plaque shall bear at least the following details:
  • — name, address or trade name of the approved fitter or workshop,
  • — characteristic coefficient of the vehicle, in the form “w = … imp/km”,
  • — constant of the recording equipment, in the form “k = … imp/km”,
  • — effective circumference of the wheel tyres in the form “l = … mm”,
  • — tyre size,
  • — the date on which the characteristic coefficient of the vehicle and the effective circumference of the wheel tyres were measured,
  • — the vehicle identification number,
  • — the presence (or not) of an external GNSS facility,
  • — the serial number of the external GNSS facility, if applicable,
  • — the serial number of the remote communication device, if any,
  • — the serial number of all the seals in place,
  • — the part of the vehicle where the adaptor, if any, is installed,
  • — the part of the vehicle where the motion sensor is installed, if not connected to the gear-box or an adaptor is not being used,
  • — a description of the colour of the cable between the adaptor and that part of the vehicle providing its incoming impulses,
  • — the serial number of the embedded motion sensor of the adaptor.’;
  • ‘(398a) The seals mentioned above shall be certified according to the standard EN 16882:2016.’;

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

  • ‘(403) Seals manufacturers shall be registered in a dedicated database when they get a seal model certified according to EN 16882:2016 and shall make their identification seals numbers public through a procedure to be established by the European Commission.’;
  • ‘(404) Approved workshops and vehicle manufacturers shall, in the frame of Regulation (EU) No 165/2014, only use seals certified according to EN 16882:2016 from those of the seals manufacturers listed in the database mentioned above.’;

‘6.2.   Check of new or repaired components
(407) Every individual device, whether new or repaired, shall be checked in respect of its proper operation and the accuracy of its reading and recordings, within the limits laid down in Chapter 3.2.1, 3.2.2, 3.2.3 and 3.3’;
  • (27) in point 6.3, paragraph (408) is replaced by the following:
  • ‘(408) When being fitted to a vehicle, the whole installation (including the recording equipment) shall comply with the provisions relating to maximum tolerances laid down in Chapter 3.2.1, 3.2.2, 3.2.3 and 3.3. The whole installation shall be sealed in accordance with Chapter 5.3 and it shall include a calibration.’;

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

  • ‘(427) Member States type approval authorities will not grant a type approval certificate as long as they do not hold:
  • — a security certificate (if requested by this Annex),
  • — a functional certificate,
  • — and an interoperability certificate (if requested by this Annex)

for the recording equipment or the tachograph card, subject of the request for type approval.’;

‘2.63   Reserved for future use’;

‘2.78   GNSSAccumulatedDriving’;

‘2.79   GNSSAccumulatedDrivingRecord’;

‘2.111   NoOfGNSSADRecords’;

‘2.160   Reserved for future use’;

‘2.203   VuGNSSADRecord’;

‘2.204   VuGNSSADRecordArray’;

‘2.230   Reserved for future use’;

‘2.231   Reserved for future use’;

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

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

Text of image

CardEventData ::= SEQUENCE SIZE(6) OF {

cardEventRecords SET SIZE(NoOfEventsPerType) OF

CardEventRecord

}

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

Text of image

CardEventData ::= SEQUENCE SIZE(11) OF {

cardEventRecords SET SIZE(NoOfEventsPerType) OF

CardEventRecord

}

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

‘2.30.   CardRenewalIndex

A card renewal index (definition i)).

Text of image

CardRenewalIndex::= IA5String(SIZE(1))

Value assignment: (see this Annex chapter 7).
“0” First issue.

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

‘

Text of image

‘DriverCardApplicationIdentification ::= SEQUENCE {

typeOfTachographCardId

EquipmentType,

cardStructureVersion

CardStructureVersion,

noOfEventsPerType

NoOfEventsPerType,

noOfFaultsPerType

NoOfFaultsPerType,

activityStructureLength

CardActivityLengthRange,

noOfCardVehicleRecords

NoOfCardVehicleRecords,

noOfCardPlaceRecords

NoOfCardPlaceRecords,

noOfGNSSADRecords

NoOfGNSSADRecords,

noOfSpecificConditionRecords

NoOfSpecificConditionRecords

noOfCardVehicleUnitRecords

NoOfCardVehicleUnitRecords

}

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

‘2.63.   Reserved for future use’;

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

Text of image

–GNSS Facility

(8),

–Remote Communication Module

(9),

–ITS interface module

(10),

–Plaque

(11),–may be used in SealRecord

–M1/N1 Adapter

(12),–may be used in SealRecord

–European Root CA (ERCA)

(13),

–Member State CA (MSCA)

(14),

–External GNSS connection

(15),–may be used in SealRecord

–Unused

(16),–used in SealDataVu

–Driver Card (Sign)

(17),–only to be used in the CHA field of a signing certificate

–Workshop Card (Sign)

(18), –only to be used in the CHA field of a signing certificate

–Vehicle Unit (Sign)

(19), –only to be used in the CHA field of a signing certificate

–RFU

(20..255)

Note 1: The generation 2 values for the Plaque, Adapter and the External GNSS connection as well as the generation 1 values for the Vehicle Unit and Motion Sensor may be used in SealRecord, i.e. if applicable.

Note 2: In the CardHolderAuthorisation (CHA) field of a generation 2 certificate, the values (1), (2), and (6) are to be interpreted as indicating a certificate for Mutual Authentication for the respective equipment type. For indicating the respective certificate for creating a digital signature, the values (17), (18) or (19) must be used.’;

‘Generation 2:
Image omitted; see official source 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,
Image omitted; see official source 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,
Image omitted; see official source 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,
Image omitted; see official source 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,
Image omitted; see official source Card faults, No further details, RFU,
Image omitted; see official source RFU,
Image omitted; see official source 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).

Text of image

ExtendedSealIdentifier ::= SEQUENCE{

manufacturerCode OCTET STRING (SIZE(2)),

sealIdentifier OCTET STRING (SIZE(8))

}

manufacturerCode is a code of the manufacturer of the seal.

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

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

Text of image

GNSSAccumulatedDriving := SEQUENCE {

gnssADPointerNewestRecord INTEGER(0..NoOfGNSSADRecords -1),

gnssAccumulatedDrivingRecords SET SIZE(NoOfGNSSADRecords) OF

GNSSAccumulatedDrivingRecord

}

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)

Text of image

GNSSAccumulatedDrivingRecord ::= SEQUENCE {

timeStamp TimeReal,

gnssPlaceRecord GNSSPlaceRecord,

vehicleOdometerValue OdometerShort

}

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

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

Text of image

KeyIdentifier ::= CHOICE {

extendedSerialNumber ExtendedSerialNumber,

certificateRequestID CertificateRequestID,

certificationAuthorityKID CertificationAuthorityKID

}

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

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

Text of image

MAC ::= CHOICE {

Mac8 OCTET STRING (SIZE(8)),

Mac12 OCTET STRING (SIZE(12)),

Mac16 OCTET STRING (SIZE(16)),

}’;

’

‘2.111.   NoOfGNSSADRecords

Generation 2:

Number of GNSS accumulated driving records a card can store.

Text of image

NoOfGNSSADRecords ::= INTEGER (0..216-1)

Value assignment: see Appendix 2.’;

‘

Text of image

’16’HVuGNSSADRecord

’;

‘2.160.   Reserved for future use’;

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

Text of image

TimeReal {INTEGER:TimeRealRange} ::= INTEGER (0..TimeRealRange)

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

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

‘2.179   VuCardRecord

Generation 2:

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

Text of image

VuCardRecord ::= SEQUENCE {

cardNumberAndGenerationInformation FullCardNumberAndGeneration,

cardExtendedSerialNumber ExtendedSerialNumber,

cardStructureVersion CardStructureVersion,

cardNumber CardNumber

}

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

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

Text of image

VuGNSSADRecord ::= SEQUENCE {

timeStamp TimeReal,

cardNumberAndGenDriverSlot FullCardNumberAndGeneration,

cardNumberAndGenCodriverSlot FullCardNumberAndGeneration,

gnssPlaceRecord GNSSPlaceRecord,

vehicleOdometerValue OdometerShort

}

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

Text of image

VuGNSSADRecordArray ::= SEQUENCE {

recordType RecordType,

recordSize INTEGER(1..65535),

noOfRecords INTEGER(0..65535),

records SET SIZE(noOfRecords) OF VuGNSSADRecord

}

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

‘2.230.   Reserved for future use

2.231.   Reserved for future use’;

‘

Text of image

‘WorkshopCardApplicationIdentification ::= SEQUENCE {

typeOfTachographCardId EquipmentType,

cardStructureVersion CardStructureVersion,

noOfEventsPerType NoOfEventsPerType,

noOfFaultsPerType NoOfFaultsPerType,

activityStructureLength CardActivityLengthRange,

noOfCardVehicleRecords NoOfCardVehicleRecords,

noOfCardPlaceRecords NoOfCardPlaceRecords,

noOfCalibrationRecords NoOfCalibrationRecords,

noOfGNSSADRecords NoOfGNSSADRecords,

noOfSpecificConditionRecords NoOfSpecificConditionRecords,

noOfCardVehicleUnitRecords NoOfCardVehicleUnitRecords

}

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’;
‘CHA Certificate Holder Authorisation
DO Data Object’;
  • ‘TCS_24 These security conditions can be linked in the following ways:

AND: All security conditions must be fulfilled

OR: At least one security condition must be fulfilled

The access rules for the file system, i.e. the SELECT, READ BINARY and UPDATE BINARY command, are specified in chapter 4. The access rules for the remaining commands are specified in the following tables. The term ‘not applicable’ is used if there is no requirement to support the command. In this case the command may or may not be supported, but the access condition is out of scope.’;

‘Command Driver Card Workshop Card Control Card Company Card
External Authenticate
— For generation 1 authentication ALW ALW ALW ALW
— For generation 2 authentication ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Not applicable Not applicable Not applicable Not applicable
PSO: Compute Digital Signature ALW OR SM-MAC-G2 ALW OR SM-MAC-G2 Not applicable Not applicable
PSO: Hash Not applicable Not applicable ALW Not applicable
PERFORM HASH of FILE ALW OR SM-MAC-G2 ALW OR SM-MAC-G2 Not applicable Not applicable
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Not applicable Not applicable ALW Not applicable
Verify Not applicable ALW Not applicable Not applicable’
‘Command Driver Card Workshop Card Control Card Company Card
External Authenticate
— For generation 1 authentication Not applicable Not applicable Not applicable Not applicable
— For generation 2 authentication ALW PWD ALW ALW
Internal Authenticate Not applicable Not applicable Not applicable Not applicable
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Not applicable ALW ALW Not applicable
PSO: Compute Digital Signature ALW OR SM-MAC-G2 ALW OR SM-MAC-G2 Not applicable Not applicable
PSO: Hash Not applicable Not applicable ALW Not applicable
PERFORM HASH of FILE ALW OR SM-MAC-G2 ALW OR SM-MAC-G2 Not applicable Not applicable
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Not applicable Not applicable ALW Not applicable
Verify Not applicable ALW Not applicable Not applicable’
‘Command Driver Card Workshop Card Control Card Company Card
External Authenticate
— For generation 1 authentication Not applicable Not applicable Not applicable Not applicable
— For generation 2 authentication ALW PWD ALW ALW
Internal Authenticate Not applicable Not applicable Not applicable Not applicable
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Not applicable Not applicable Not applicable Not applicable
PSO: Compute Digital Signature Not applicable Not applicable Not applicable Not applicable
PSO: Hash Not applicable Not applicable Not applicable Not applicable
PERFORM HASH of FILE Not applicable Not applicable Not applicable Not applicable
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Not applicable Not applicable Not applicable Not applicable
Verify Not applicable ALW Not applicable Not applicable’
  • ‘TCS_29 The status words SW1 SW2 are returned in any response message and denote the processing state of the command.
SW1 SW2 Meaning
90 00 Normal processing.
61 XX Normal processing. XX = number of response bytes available.
62 81 Warning processing. Part of returned data may be corrupted
63 00 Authentication failed (Warning)
63 CX Wrong CHV (PIN). Remaining attempts counter provided by “X”.
64 00 Execution error - State of non-volatile memory unchanged. Integrity error.
65 00 Execution error - State of non-volatile memory changed
65 81 Execution error - State of non-volatile memory changed – Memory failure
66 88 Security error : wrong cryptographic checksum (during Secure Messaging) or wrong certificate (during certificate verification) or wrong cryptogram (during external authentication) or wrong signature (during signature verification)
67 00 Wrong length (wrong Lc or Le)
68 83 Last command of the chain expected
69 00 Forbidden command (no response available in T=0)
69 82 Security status not satisfied.
69 83 Authentication method blocked.
69 85 Conditions of use not satisfied.
69 86 Command not allowed (no current EF).
69 87 Expected Secure Messaging Data Objects missing
69 88 Incorrect Secure Messaging Data Objects
6A 80 Incorrect parameters in data field
6A 82 File not found.
6A 86 Wrong parameters P1-P2.
6A 88 Referenced data not found.
6B 00 Wrong parameters (offset outside the EF).
6C XX Wrong length, SW2 indicates the exact length. No data field is returned.
6D 00 Instruction code not supported or invalid.
6E 00 Class not supported.
6F 00 — Other checking errors

Additional status words as defined in ISO/IEC 7816-4 can be returned, if their behaviour is not explicitly mentioned in this appendix.

For example the following status words can be optionally returned:

6881: Logical channel not supported

6882: Secure messaging not supported’;

  • ‘— If the selected application is considered to be corrupted (integrity error is detected within the file attributes), the processing state returned is “6400” or “6500”.’;
  • ‘— If the selected file is considered to be corrupted (integrity error is detected within the file attributes), the processing state returned is “6400” or “6500”.’;
  • ‘— If an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is “6400” or “6500”.’;
‘Byte Length Value Description
#1 1 “81h” TPV: Tag for plain value data
#2 L “NNh” or “81 NNh” LPV: length of returned data (=original Le). L is 2 bytes if LPV>127 bytes.
#(2+L) - #(1+L+NN) NN “XX..XXh” Plain Data value
#(2+L+NN) 1 “99h” Tag for Processing Status (SW1-SW2) – optional for generation 1 secure messaging
#(3+L+NN) 1 “02h” Length of Processing Status – optional for generation 1 secure messaging
#(4+L+NN) - #(5+L+NN) 2 “XX XXh” Processing Status of the unprotected response APDU – optional for generation 1 secure messaging
#(6+L+NN) 1 “8Eh” TCC: Tag for cryptographic checksum
#(7+L+NN) 1 “XXh” LCC: Length of following cryptographic checksum “04h” for Generation 1 secure messaging (see Appendix 11 Part A) “08h”, “0Ch” or “10h” depending on AES key length for Generation 2 secure messaging (see Appendix 11 Part B)
#(8+L+NN)-#(7+M+L+NN) M “XX..XXh” Cryptographic checksum
SW 2 “XXXXh” Status Words (SW1,SW2)’
‘Byte Length Value Description
#1 1 “87h” TPI CG: Tag for encrypted data (cryptogram)
#2 L “MMh” or “81 MMh” LPI CG: length of returned encrypted data (different of original Le of the command due to padding). L is 2 bytes if LPI CG > 127 bytes.
#(2+L)-#(1+L+MM) MM “01XX..XXh” Encrypted Data: Padding Indicator and cryptogram
#(2+L+MM) 1 “99h” Tag for Processing Status (SW1-SW2) – optional for generation 1 secure messaging
#(3+L+MM) 1 “02h” Length of Processing Status – optional for generation 1 secure messaging
#(4+L+MM) - #(5+L+MM) 2 “XX XXh” Processing Status of the unprotected response APDU – optional for generation 1 secure messaging
#(6+L+MM) 1 “8Eh” TCC: Tag for cryptographic checksum
#(7+L+MM) 1 “XXh” LCC: Length of following cryptographic checksum “04h” for Generation 1 secure messaging (see Appendix 11 Part A) “08h”, “0Ch” or “10h” depending on AES key length for Generation 2 secure messaging (see Appendix 11 Part B)
#(8+L+MM)-#(7+N+L+MM) N “XX..XXh” Cryptographic checksum
SW 2 “XXXXh” Status Words (SW1,SW2)’
  • ‘— If an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is “6400” or “6500”.’;
‘Le 1 'XXh' As specified in ISO/IEC 7816-4’

‘In case of T = 0 the card assumes the value Le = “00h” if no secure messaging is applied.

In case of T = 1 the processing state returned is “6700” if Le=“01h”.’;

  • ‘— If an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is “6400” or “6500”.’;
  • ‘— If an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is “6400” or “6500”.’;
  • ‘TCS_72 The PIN entered by the user must be ASCII encoded and right padded with “FFh” bytes up to a length of 8 bytes by the IFD, see also the data type WorkshopCardPIN in Appendix 1.’;
  • ‘TCS_95 If the INTERNAL AUTHENTICATE command is successful, the current generation 1 session key, if existing, is erased and no longer available. In order to have a new generation 1 session key available, the EXTERNAL AUTHENTICATE command for the generation 1 authentication mechanism must be successfully performed.
  • Note: For generation 2 session keys see Appendix 11 CSM_193 and CSM_195. If generation 2 session keys are established and the tachograph card receives the plain INTERNAL AUTHENTICATE command APDU, it aborts the generation 2 secure messaging session and destroys the generation 2 session keys.’;
  • ‘TCS_97 The command variant for the second generation VU-card mutual authentication can be performed in the MF, DF Tachograph and DF Tachograph_G2, see also TCS_34. If this generation 2 EXTERNAL AUTHENTICATE command is successful, the current generation 1 session key, if existing, is erased and no longer available.
  • Note: For generation 2 session keys see Appendix 11 CSM_193 and CSM_195. If generation 2 session keys are established and the tachograph card receives the plain EXTERNAL AUTHENTICATE command APDU, it aborts the generation 2 secure messaging session and destroys the generation 2 session keys.’;
‘5 + L + 1 1 “00h” As specified in ISO/IEC 7816-4’
  • ‘— If the currentAuthenticatedTime of the card is later than the Expiration Date of the selected public key, the processing state returned is “6A88”.

Note: In the case of a MSE: SET AT for VU Authentication command, the referenced key is a VU_MA public key. The card shall set the VU_MA public key for use, if available in its memory, which matches the Certificate Holder Reference (CHR) given in the command data field (the card can identify VU_MA public keys by means of the certificate's CHA field). A card shall return “6A 88” to this command in case only the VU_Sign public key or no public key of the Vehicle Unit is available. See the definition of the CHA field in Appendix 11 and of data type equipmentType in Appendix 1.

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

  • ‘TCS_121 The temporarily stored hash of file value shall be deleted if a new hash of file value is computed by means of the PERFORM HASH of FILE command, if a DF is selected, and if the tachograph card is reset.’;
  • ‘TCS_123 The Tachograph Generation 2 application shall support the SHA-2 algorithm (SHA-256, SHA-384 or SHA-512), specified by the cipher suite in Appendix 11 Part B for the card signature key Card_Sign.’;
‘Byte Length Value Description
CLA 1 “80h” CLA
INS 1 “2Ah” Perform Security Operation
P1 1 “90h” Tag: Hash
P2 1 “00h” Algorithm implicitly known For the Tachograph Generation 1 application: SHA-1 For the Tachograph Generation 2 application: SHA-2 algorithm (SHA-256, SHA-384 or SHA-512) defined by the cipher suite in Appendix 11 Part B for the card signature key Card_Sign’

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.';

‘Byte Length Value Description
CLA 1 “00h” CLA
INS 1 “2Ah” Perform Security Operation
P1 1 “00h”
P2 1 “A8h” Tag: data field contains DOs relevant for verification
Lc 1 “XXh” Length Lc of the subsequent data field
#6 1 “9Eh” Tag for Digital Signature
#7 or #7-#8 L “NNh” or “81 NNh” Length of digital signature (L is 2 bytes if the digital signature is longer than 127 bytes): 128 bytes coded in accordance with Appendix 11 Part A for Tachograph Generation 1 application. Depending on the selected curve for Tachograph Generation 2 application (see Appendix 11 Part B).
#(7+L)-#(6+L+NN) NN “XX..XXh” Digital signature content’
  • ‘— If the selected public key (used to verify the digital signature) has a CHA.LSB (CertificateHolderAuthorisation.equipmentType) that is not suitable for the digital signature verification according to Appendix 11, the processing state returned is “6985”.’;
‘5 + L + 1 1 '00h' As specified in ISO/IEC 7816-4’
  • ‘— “6985” indicates that the 4-byte time stamp provided in the command data field is earlier than cardValidityBegin or later than cardExpiryDate.’;

‘

Text of image

File / Data element

No of Records

Size (bytes)

Default Values

Min

Max

’

Image omitted; see official source

of the table is replaced by the following:
‘Image omitted; see official source Image omitted; see official source 252 336’
  • ‘SC4 For the READ BINARY command with even INS byte:

(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR

(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)

For the READ BINARY command with odd INS byte (if supported): NEV’;

‘ Image omitted; see official source Image omitted; see official source ’
‘Image omitted; see official source Image omitted; see official source 18 24’

‘ Image omitted; see official source Position after 3 hours accumulated driving time’;

‘ Image omitted; see official source Time conflict or time adjustment (by workshop)’;

‘ Image omitted; see official source Absence of position information from GNSS receiver or Communication error with the external GNSS facility;

Image omitted; see official source Communication error with the remote communication facility ’;
‘11.4 Entry of place where a daily work period begins and/or ends Entry of place where a daily work period begins and/or ends
‘11.4 pi=location begin / end pictogram, time, country, region longitude of the recorded position latitude of the recorded position timestamp when position was determined Odometer pihh:mm Cou Reg lon ±DDDoMM.M’ lat ± DDoMM.M’ hh:mm x xxx xxx km’
‘11.5 Positions after 3 hours accumulated driving time pi=position after 3 hours accumulated driving Positions after 3 hours accumulated driving time pi=position after 3 hours accumulated driving
‘11.5 time longitude of the recorded position latitude of the recorded position timestamp when position was determined Odometer Image omitted; see official source’
‘11.5 Positions after 3 hours accumulated driving time in chronological order’

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

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