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 (Text with EEA relevance)

Type Implementing Regulation
Publication 2016-05-26
Last updated 2023-08-21
State In force
Department European Commission
Source EUR-Lex
articles 6
Reform history JSON API
  • (242)Tachograph cards shall be capable of operating correctly in the humidity range 10 % to 90 %.
  • (243)Tachograph cards shall be capable of operating correctly for a five-year period if used within the environmental and electrical specifications.
  • (244)During operation, tachograph cards shall conform to ECE R10, related to electromagnetic compatibility, and shall be protected against electrostatic discharges.
4.5   Data storage

For the purpose of this paragraph,

  • — 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.

The tachograph cards functions, commands and logical structures, fulfilling data storage requirements are specified in Appendix 2.

If not otherwise specified, data storage on tachograph cards shall be organized in such a way, that new data replaces stored oldest data in case the foreseen memory size for the particular records is exhausted.

  • (245)This paragraph specifies minimum storage capacity for the various application data files. Tachograph cards shall be able to indicate to the recording equipment the actual storage capacity of these data files.
  • (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.
  • (247)Each Master File (MF) of any tachograph card shall contain up to five Elementary Files (EF) for card management, application and chip identifications, and two Dedicated Files (DF):
  • — DF Tachograph, which contains the application accessible to first generation vehicle units, which is also present in first generation tachograph cards,
  • — DF Tachograph_G2, which contains the application only accessible to second generation vehicle units, which is only present in second generation tachograph cards.
  • Note: version 2 of second generation cards contains additional Elementary Files in DF Tachograph_G2.
  • The full details of the tachograph cards structure are specified in Appendix 2.
4.5.1   Elementary files for identification and card management
4.5.2   IC card identification
  • (248)Tachograph cards shall be able to store the following smart card identification data:
  • — clock stop,
  • — card serial number (including manufacturing references),
  • — card type approval number,
  • — card personaliser identification (ID),
  • — embedder ID,
  • — IC identifier.

4.5.2.1   Chip identification

  • (249)Tachograph cards shall be able to store the following Integrated Circuit (IC) identification data:
  • — IC serial number,
  • — IC manufacturing references.

4.5.2.2   DIR (only present in second generation tachograph cards)

  • (250)Tachograph cards shall be able to store the application identification data objects specified in Appendix 2.

4.5.2.3   ATR information (conditional, only present in second generation tachograph cards)

  • (251)Tachograph cards shall be able to store the following extended length information data object:
  • — in the case the tachograph card supports extended length fields, the extended length information data object specified in Appendix 2.

4.5.2.4   Extended length information (conditional, only present in second generation tachograph cards)

  • (252)Tachograph cards shall be able to store the following extended length information data objects:
  • — in the case the tachograph card supports extended length fields, the extended length information data objects specified in Appendix 2.
4.5.3   Driver card

4.5.3.1   Tachograph application (accessible to first and second generation vehicle units)

4.5.3.1.1   Application identification

  • (253)The driver card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

4.5.3.1.2   Key and certificates

  • (254)The driver card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part A.

4.5.3.1.3   Card identification

  • (255)The driver card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date.

4.5.3.1.4   Card holder identification

  • (256)The driver card shall be able to store the following card holder identification data:
  • — surname of the holder,
  • — first name(s) of the holder,
  • — date of birth,
  • — preferred language.

4.5.3.1.5   Card download

  • (257)The driver card shall be able to store the following data related to card download:
  • — date and time of last card download (for other purposes than control).
  • (258)The driver card shall be able to hold one such record.

4.5.3.1.6   Driving licence information

  • (259)The driver card shall be able to store the following driving licence data:
  • — issuing Member State, issuing authority name,
  • — driving licence number (at the date of the issue of the card).

4.5.3.1.7   Events data

For the purpose of this subparagraph, time shall be stored with a resolution of 1 second.

  • (260)The driver card shall be able to store data related to the following events detected by the recording equipment while the card was inserted:
  • — Time overlap (where this card is the cause of the event),
  • — Card insertion while driving (where this card is the subject of the event),
  • — Last card session not correctly closed (where this card is the subject of the event),
  • — Power supply interruption,
  • — Motion data error,
  • — Security breach attempts.
  • (261)The driver card shall be able to store the following data for these events:
  • — Event code,
  • — Date and time of beginning of the event (or of card insertion if the event was on-going at that time),
  • — Date and time of end of the event (or of card withdrawal if the event was on-going at that time),
  • — VRN and registering Member State of vehicle in which the event happened.

Note: For the ‘Time overlap’ event:

  • — Date and time of beginning of the event shall correspond to the date and time of the card withdrawal from the previous vehicle,
  • — Date and time of end of the event shall correspond to the date and time of card insertion in current vehicle,
  • — Vehicle data shall correspond to the current vehicle raising the event.

Note: For the ‘Last card session not correctly closed’ event:

  • — date and time of beginning of event shall correspond to the card insertion date and time of the session not correctly closed,
  • — date and time of end of event shall correspond to the card insertion date and time of the session during which the event was detected (current session),
  • — Vehicle data shall correspond to the vehicle in which the session was not correctly closed.
  • (262)The driver card shall be able to store data for the six most recent events of each type (i.e. 36 events).

4.5.3.1.8   Faults data

For the purpose of this subparagraph, time shall be recorded with a resolution of 1 second.

  • (263)The driver card shall be able to store data related to the following faults detected by the recording equipment while the card was inserted:
  • — Card fault (where this card is the subject of the fault),
  • — Recording equipment fault.
  • (264)The driver card shall be able to store the following data for these faults:
  • — Fault code,
  • — Date and time of beginning of the fault (or of card insertion if the fault was on-going at that time),
  • — Date and time of end of the fault (or of card withdrawal if the fault was on-going at that time),
  • — VRN and registering Member State of vehicle in which the fault happened.
  • (265)The driver card shall be able to store data for the twelve most recent faults of each type (i.e. 24 faults).

4.5.3.1.9   Driver activity data

  • (266)The driver card shall be able to store, for each calendar day where the card has been used or for which the driver has entered activities manually, the following data:
  • — the date,
  • — a daily presence counter (increased by one for each of these calendar days),
  • — the total distance travelled by the driver during this day,
  • — a driver status at 00:00,
  • — whenever the driver has changed of activity, and/or has changed of driving status, and/or has inserted or withdrawn his card: — the driving status (CREW, SINGLE), — the slot (DRIVER, CO-DRIVER), — the card status (INSERTED, NOT INSERTED), — the activity (DRIVING, AVAILABILITY, WORK, BREAK/REST), — the time of the change.
  • (267)The driver card memory shall be able to hold driver activity data for at least 28 days (the average activity of a driver is defined as 93 activity changes per day).
  • (268)The data listed under requirements 261, 264 and 266 shall be stored in a way allowing the retrieval of activities in the order of their occurrence, even in case of a time overlap situation.

4.5.3.1.10   Vehicles used data

  • (269)The driver card shall be able to store, for each calendar day where the card has been used, and for each period of use of a given vehicle that day (a period of use includes all consecutive insertion / withdrawal cycle of the card in the vehicle, as seen from the card point of view), the following data:
  • — date and time of first use of the vehicle (i.e. first card insertion for this period of use of the vehicle, or 00h00 if the period of use is on-going at that time),
  • — vehicle odometer value at that time,
  • — date and time of last use of the vehicle, (i.e. last card withdrawal for this period of use of the vehicle, or 23h59 if the period of use is on-going at that time),
  • — vehicle odometer value at that time,
  • — VRN and registering Member State of the vehicle.
  • (270)The driver card shall be able to store at least 84 such records.

4.5.3.1.11   Places where daily work periods start and/or end

  • (271)The driver card shall be able to store the following data related to places where daily work periods begin and/or end, entered by the driver:
  • — the date and time of the entry (or the date/time related to the entry if the entry is made during the manual entry procedure),
  • — the type of entry (begin or end, condition of entry),
  • — the country and region entered,
  • — the vehicle odometer value.
  • (272)The driver card memory shall be able to hold at least 42 pairs of such records.

4.5.3.1.12   Card session data

  • (273)The driver card shall be able to store data related to the vehicle which opened its current session:
  • — date and time the session was opened (i.e. card insertion) with a resolution of one second,
  • — VRN and registering Member State.

4.5.3.1.13   Control activity data

  • (274)The driver card shall be able to store the following data related to control activities:
  • — date and time of the control,
  • — control card number and card issuing Member State,
  • — type of the control (displaying and/or printing and/or VU downloading and/or card downloading (see note)),
  • — Period downloaded, in case of downloading,
  • — VRN and registering Member State of the vehicle in which the control happened.

Note: card downloading will only be recorded if performed through a recording equipment.

  • (275)The driver card shall be able to hold one such record.

4.5.3.1.14   Specific conditions data

  • (276)The driver card shall be able to store the following data related to specific conditions entered while the card was inserted (whatever the slot):
  • — Date and time of the entry,
  • — Type of specific condition.
  • (277)The driver card shall be able to store at least 56 such records.

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)

4.5.3.2.1   Application identification

  • (278)The driver card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

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.

4.5.3.2.2   Keys and certificates

  • (279)The driver card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part B.

4.5.3.2.3   Card identification

  • (280)The driver card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date.

4.5.3.2.4   Card holder identification

  • (281)The driver card shall be able to store the following card holder identification data:
  • — surname of the holder,
  • — first name(s) of the holder,
  • — date of birth,
  • — preferred language.

4.5.3.2.5   Card download

  • (282)The driver card shall be able to store the following data related to card download:
  • — date and time of last card download (for other purposes than control).
  • (283)The driver card shall be able to hold one such record.

4.5.3.2.6   Driving licence information

  • (284)The driver card shall be able to store the following driving licence data:
  • — issuing Member State, issuing authority name,
  • — driving licence number (at the date of the issue of the card).

4.5.3.2.7   Events data

For the purpose of this subparagraph, time shall be stored with a resolution of 1 second.

  • (285)The driver card shall be able to store data related to the following events detected by the recording equipment while the card was inserted:
  • — Time overlap (where this card is the cause of the event),
  • — Card insertion while driving (where this card is the subject of the event),
  • — Last card session not correctly closed (where this card is the subject of the event),
  • — Power supply interruption,
  • — Communication error with the remote communication facility,
  • — Absence of position information from GNSS receiver event,
  • — Communication error with the external GNSS facility
  • — Motion data error,
  • — Vehicle motion conflict,
  • — Security breach attempts,
  • — Time conflict.
  • (286)The driver card shall be able to store the following data for these events:
  • — Event code,
  • — Date and time of beginning of the event (or of card insertion if the event was on-going at that time),
  • — Date and time of end of the event (or of card withdrawal if the event was on-going at that time),
  • — VRN and registering Member State of vehicle in which the event happened.

Note: For the ‘Time overlap’ event:

  • — Date and time of beginning of the event shall correspond to the date and time of the card withdrawal from the previous vehicle,
  • — Date and time of end of the event shall correspond to the date and time of card insertion in current vehicle,
  • — Vehicle data shall correspond to the current vehicle raising the event.

Note: For the ‘Last card session not correctly closed’ event:

  • — date and time of beginning of event shall correspond to the card insertion date and time of the session not correctly closed,
  • — date and time of end of event shall correspond to the card insertion date and time of the session during which the event was detected (current session),
  • — Vehicle data shall correspond to the vehicle in which the session was not correctly closed.
  • (287)The driver card shall be able to store data for the 12 most recent events of each type (i.e. 132 events).

4.5.3.2.8   Faults data

For the purpose of this subparagraph, time shall be recorded with a resolution of 1 second.

  • (288)The driver card shall be able to store data related to the following faults detected by the recording equipment while the card was inserted:
  • — Card fault (where this card is the subject of the fault),
  • — Recording equipment fault.
  • (289)The driver card shall be able to store the following data for these faults:
  • — Fault code,
  • — Date and time of beginning of the fault (or of card insertion if the fault was on-going at that time),
  • — Date and time of end of the fault (or of card withdrawal if the fault was on-going at that time),
  • — VRN and registering Member State of vehicle in which the fault happened.
  • (290)The driver card shall be able to store data for the 24 most recent faults of each type (i.e. 48 faults).

4.5.3.2.9   Driver activity data

  • (291)The driver card shall be able to store, for each calendar day where the card has been used or for which the driver has entered activities manually, the following data:
  • — the date,
  • — a daily presence counter (increased by one for each of these calendar days),
  • — the total distance travelled by the driver during this day,
  • — a driver status at 00:00,
  • — whenever the driver has changed of activity, and/or has changed of driving status, and/or has inserted or withdrawn his card: — the driving status (CREW, SINGLE) — the slot (DRIVER, CO-DRIVER), — the card status (INSERTED, NOT INSERTED), — the activity (DRIVING, AVAILABILITY, WORK, BREAK/REST). — the time of the change,
  • (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).
  • (293)The data listed under requirements 286, 289 and 291 shall be stored in a way allowing the retrieval of activities in the order of their occurrence, even in case of a time overlap situation.

4.5.3.2.10   Vehicles used data

  • (294)The driver card shall be able to store, for each calendar day where the card has been used, and for each period of use of a given vehicle that day (a period of use includes all consecutive insertion / withdrawal cycle of the card in the vehicle, as seen from the card point of view), the following data:
  • — date and time of first use of the vehicle (i.e. first card insertion for this period of use of the vehicle, or 00h00 if the period of use is on-going at that time),
  • — vehicle odometer value at that first use time,
  • — date and time of last use of the vehicle, (i.e. last card withdrawal for this period of use of the vehicle, or 23h59 if the period of use is on-going at that time),
  • — vehicle odometer value at that last use time,
  • — VRN and registering Member State of the vehicle,
  • — VIN of the vehicle.
  • (295)The driver card shall be able to store 200 such records.

4.5.3.2.11   Places and positions where daily work periods start and/or end

  • (296)The driver card shall be able to store the following data related to places where daily work periods begin and/or end, entered by the driver:
  • — the date and time of the entry (or the date/time related to the entry if the entry is made during the manual entry procedure),
  • — the type of entry (begin or end, condition of entry),
  • — the country and region entered,
  • — the vehicle odometer value,
  • — the vehicle position,
  • — the GNSS accuracy, date and time when the position was determined.
  • (297)The driver card memory shall be able to hold 112 such records.

4.5.3.2.12   Card session data

  • (298)The driver card shall be able to store data related to the vehicle which opened its current session:
  • — date and time the session was opened (i.e. card insertion) with a resolution of one second,
  • — VRN and registering Member State.

4.5.3.2.13   Control activity data

  • (299)The driver card shall be able to store the following data related to control activities:
  • — date and time of the control,
  • — control card number and card issuing Member State,
  • — type of the control (displaying and/or printing and/or VU downloading and/or card downloading (see note)),
  • — Period downloaded, in case of downloading,
  • — VRN and registering Member State of the vehicle in which the control happened.

Note: security requirements imply that card downloading will only be recorded if performed through a recording equipment.

  • (300)The driver card shall be able to hold one such record.

4.5.3.2.14   Specific conditions data

  • (301)The driver card shall be able to store the following data related to specific conditions entered while the card was inserted (whatever the slot):
  • — Date and time of the entry,
  • — Type of specific condition.
  • (302)The driver card shall be able to store 112 such records.

4.5.3.2.15   Vehicle units used data

  • (303)The driver card shall be able to store the following data related to the different vehicle units in which the card was used:
  • — the date and time of the beginning of the period of use of the vehicle unit (i.e. first card insertion in the vehicle unit for the period),
  • — the manufacturer of the vehicle unit,
  • — the vehicle unit type,
  • — the vehicle unit software version number.
  • (304)The driver card shall be able to store 200 such records.

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 336 such records.

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.
4.5.4   Workshop card

4.5.4.1   Tachograph application (accessible to first and second generation vehicle units)

4.5.4.1.1   Application identification

  • (307)The workshop card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

4.5.4.1.2   Keys and certificates

  • (308)The workshop card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part A.
  • (309)The workshop card shall be able to store a Personal Identification Number (PIN code).

4.5.4.1.3   Card identification

  • (310)The workshop card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date.

4.5.4.1.4   Card holder identification

  • (311)The workshop card shall be able to store the following card holder identification data:
  • — workshop name,
  • — workshop address,
  • — surname of the holder,
  • — first name(s) of the holder,
  • — preferred language.

4.5.4.1.5   Card download

  • (312)The workshop card shall be able to store a card download data record in the same manner as a driver card.

4.5.4.1.6   Calibration and time adjustment data

  • (313)The workshop card shall be able to hold records of calibrations and/or time adjustments performed while the card is inserted in a recording equipment.
  • (314)Each calibration record shall be able to hold the following data:
  • — Purpose of calibration (activation, first installation, installation, periodic inspection,),
  • — Vehicle identification,
  • — Parameters updated or confirmed (w, k, l, tyre size, speed limiting device setting, odometer (new and old values), date and time (new and old values)),
  • — Recording equipment identification (VU part number, VU serial number, motion sensor serial number).
  • (315)The workshop card shall be able to store at least 88 such records.
  • (316)The workshop card shall hold a counter indicating the total number of calibrations performed with the card.
  • (317)The workshop card shall hold a counter indicating the number of calibrations performed since its last download.

4.5.4.1.7   Events and faults data

  • (318)The workshop card shall be able to store events and faults data records in the same manner as a driver card.
  • (319)The workshop card shall be able to store data for the three most recent events of each type (i.e. 18 events) and the six most recent faults of each type (i.e. 12 faults).

4.5.4.1.8   Driver activity data

  • (320)The workshop card shall be able to store driver activity data in the same manner as a driver card.
  • (321)The workshop card shall be able to hold driver activity data for at least 1 day of average driver activity.

4.5.4.1.9   Vehicles used data

  • (322)The workshop card shall be able to store vehicles used data records in the same manner as a driver card.
  • (323)The workshop card shall be able to store at least 4 such records.

4.5.4.1.10   Daily work periods start and/or end data

  • (324)The workshop card shall be able to store daily works period start and/or end data records in the same manner as a driver card.
  • (325)The workshop card shall be able to hold at least 3 pairs of such records.

4.5.4.1.11   Card session data

  • (326)The workshop card shall be able to store a card session data record in the same manner as a driver card.

4.5.4.1.12   Control activity data

  • (327)The workshop card shall be able to store a control activity data record in the same manner as a driver card.

4.5.4.1.13   Specific conditions data

  • (328)The workshop card shall be able to store data relevant to specific conditions in the same manner as the driver card.
  • (329)The workshop card shall be able to store at least 2 such records.

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)

4.5.4.2.1   Application identification

  • (330)The workshop card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

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.

4.5.4.2.2   Keys and certificates

  • (331)The workshop card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part B.
  • (332)The workshop card shall be able to store a Personal Identification Number (PIN code).

4.5.4.2.3   Card identification

  • (333)The workshop card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date.

4.5.4.2.4   Card holder identification

  • (334)The workshop card shall be able to store the following card holder identification data:
  • — workshop name,
  • — workshop address,
  • — surname of the holder,
  • — first name(s) of the holder,
  • — preferred language.

4.5.4.2.5   Card download

  • (335)The workshop card shall be able to store a card download data record in the same manner as a driver card.

4.5.4.2.6   Calibration and time adjustment data

  • (336)The workshop card shall be able to hold records of calibrations and/or time adjustments performed while the card is inserted in a recording equipment.
  • (337)Each calibration record shall be able to hold the following data:
  • — purpose of calibration (activation, first installation, installation, periodic inspection,),
  • — vehicle identification,
  • — parameters updated or confirmed (w, k, l, tyre size, speed limiting device setting, odometer (new and old values), date and time (new and old values),
  • — recording equipment identification (VU part number, VU serial number, motion sensor serial number, remote communication facility serial number and external GNSS facility serial number, if applicable),
  • — seal type and identifier of all seals in place,
  • — ability of the VU to use first generation tachograph cards (enabled or not).
  • (338)The workshop card shall be able to store 255 such records.
  • (339)The workshop card shall hold a counter indicating the total number of calibrations performed with the card.
  • (340)The workshop card shall hold a counter indicating the number of calibrations performed since its last download.

4.5.4.2.7   Events and faults data

  • (341)The workshop card shall be able to store events and faults data records in the same manner as a driver card.
  • (342)The workshop card shall be able to store data for the three most recent events of each type (i.e. 33 events) and the six most recent faults of each type (i.e. 12 faults).

4.5.4.2.8   Driver activity data

  • (343)The workshop card shall be able to store driver activity data in the same manner as a driver card.
  • (344)The workshop card shall be able to hold driver activity data for 1 day containing 240 activity changes.

4.5.4.2.9   Vehicles used data

  • (345)The workshop card shall be able to store vehicles used data records in the same manner as a driver card.
  • (346)The workshop card shall be able to store 8 such records.

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.

4.5.4.2.11   Card session data

  • (349)The workshop card shall be able to store a card session data record in the same manner as a driver card.

4.5.4.2.12   Control activity data

  • (350)The workshop card shall be able to store a control activity data record in the same manner as a driver card.

4.5.4.2.13   Vehicle units used data

  • (351)The workshop card shall be able to store the following data related to the different vehicle units in which the card was used:
  • — the date and time of the beginning of the period of use of the vehicle unit (i.e. first card insertion in the vehicle unit for the period),
  • — the manufacturer of the vehicle unit,
  • — the vehicle unit type,
  • — the vehicle unit software version number.
  • (352)The workshop card shall be able to store 8 such records.

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 24 such records.

4.5.4.2.15   Specific conditions data

  • (355)The workshop card shall be able to store data relevant to specific conditions in the same manner as the driver card.
  • (356)The workshop card shall be able to store 4 such records.

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.
4.5.5   Control card

4.5.5.1   Tachograph application (accessible to first and second generation vehicle units)

4.5.5.1.1   Application identification

  • (357)The control card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

4.5.5.1.2   Keys and certificates

  • (358)The control card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part A.

4.5.5.1.3   Card identification

  • (359)The control card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date (if any).

4.5.5.1.4   Card holder identification

  • (360)The control card shall be able to store the following card holder identification data:
  • — control body name,
  • — control body address,
  • — surname of the holder,
  • — first name(s) of the holder,
  • — preferred language.

4.5.5.1.5   Control activity data

  • (361)The control card shall be able to store the following control activity data:
  • — date and time of the control,
  • — type of the control (displaying and/or printing and/or VU downloading and/or card downloading),
  • — period downloaded (if any),
  • — VRN and Member State registering authority of the controlled vehicle,
  • — card number and card issuing Member State of the driver card controlled.
  • (362)The control card shall be able to hold at least 230 such records.

4.5.5.2   Tachograph G2 application (not accessible to first generation vehicle unit)

4.5.5.2.1   Application identification

  • (363)The control card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

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.

4.5.5.2.2   Keys and certificates

  • (364)The control card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part B.

4.5.5.2.3   Card identification

  • (365)The control card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date (if any).

4.5.5.2.4   Card holder identification

  • (366)The control card shall be able to store the following card holder identification data:
  • — control body name,
  • — control body address,
  • — surname of the holder,
  • — first name(s) of the holder,
  • — preferred language.

4.5.5.2.5   Control activity data

  • (367)The control card shall be able to store the following control activity data:
  • — date and time of the control,
  • — type of the control (displaying and/or printing and/or VU downloading and/or card downloading and/or roadside calibration checking)
  • — period downloaded (if any),
  • — VRN and Member State registering authority of the controlled vehicle,
  • — card number and card issuing Member State of the driver card controlled.
  • (368)The control card shall be able to hold at least 230 such records.

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.
4.5.6   Company card

4.5.6.1   Tachograph application (accessible to first and second generation vehicle units)

4.5.6.1.1   Application identification

  • (369)The company card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

4.5.6.1.2   Keys and Certificates

  • (370)The company card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part A.

4.5.6.1.3   Card identification

  • (371)The company card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date (if any).

4.5.6.1.4   Card holder identification

  • (372)The company card shall be able to store the following card holder identification data:
  • — company name,
  • — company address.

4.5.6.1.5   Company activity data

  • (373)The company card shall be able to store the following company activity data:
  • — date and time of the activity,
  • — type of the activity (VU locking in and/or out, and/or VU downloading and/or card downloading)
  • — period downloaded (if any),
  • — VRN and Member State registering authority of vehicle,
  • — card number and card issuing Member State (in case of card downloading).
  • (374)The company card shall be able to hold at least 230 such records.

4.5.6.2   Tachograph G2 application (not accessible to first generation vehicle unit)

4.5.6.2.1   Application identification

  • (375)The company card shall be able to store the following application identification data:
  • — tachograph application identification,
  • — type of tachograph card identification.

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.

4.5.6.2.2   Keys and certificates

  • (376)The company card shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part B.

4.5.6.2.3   Card identification

  • (377)The company card shall be able to store the following card identification data:
  • — card number,
  • — issuing Member State, issuing authority name, issue date,
  • — card beginning of validity date, card expiry date (if any).

4.5.6.2.4   Card holder identification

  • (378)The company card shall be able to store the following card holder identification data:
  • — company name,
  • — company address.

4.5.6.2.5   Company activity data

  • (379)The company card shall be able to store the following company activity data:
  • — date and time of the activity,
  • — type of the activity (VU locking in and/or out, and/or VU downloading and/or card downloading)
  • — period downloaded (if any),
  • — VRN and Member State registering authority of vehicle,
  • — card number and card issuing Member State (in case of card downloading).
  • (380)The company card shall be able to hold at least 230 such records.

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.

5. INSTALLATION OF RECORDING EQUIPMENT

5.1   Installation
  • (381)New recording equipment shall be delivered non-activated to fitters or vehicle manufacturers, with all calibration parameters, as listed in Chapter 3.21, set to appropriate and valid default values. Where no particular value is appropriate, literal parameters shall be set to strings of ‘?’ and numeric parameters shall be set to ‘0’. Delivery of security relevant parts of the recording equipment can be restricted if required during security certification.
  • (382)Before its activation, the recording equipment shall give access to the calibration function even if not in calibration mode.
  • (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.
  • (384)During installation, vehicle manufacturers shall pre-set all known parameters.
  • (385)Vehicle manufacturers or fitters shall activate the installed recording equipment at the latest before the vehicle is used in scope of Regulation (EC) No 561/2006.
  • (386)The activation of the recording equipment shall be triggered automatically by the first insertion of a valid workshop card in either of its card interface devices.
  • (387)Specific pairing operations required between the motion sensor and the vehicle unit, if any, shall take place automatically before or during activation.
  • (388)In a similar way, specific coupling operations between the external GNSS facility and the vehicle unit, if any, shall take place automatically before or during activation.
  • (389)After its activation, the recording equipment shall fully enforce functions and data access rights.
  • (390)After its activation, the recording equipment shall communicate to the remote communication facility the secured data necessary for the purpose of targeted roadside checks.
  • (391)The recording and storing functions of the recording equipment shall be fully operational after its activation.
  • (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.
  • (393)The installation of an external GNSS facility requires the coupling with the vehicle unit and the subsequent verification of the GNSS position information.
  • (394)The recording equipment must be positioned in the vehicle in such a way as to allow the driver to access the necessary functions from his seat.
5.2   Installation plaque
  • (395) 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.
  • After every inspection by an approved fitter or workshop, a new plaque shall be affixed in place of the previous one.
  • (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 facility, 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.
  • — the by-default load type associated to the vehicle.
  • (397)For M1 and N1 vehicles only, and which are fitted with an adaptor in conformity with Commission Regulation (EC) No 68/2009 ([^E0012]) as last amended and where it is not possible to include all the information necessary, as described in Requirement 396, a second, additional, plaque may be used. In such cases, this additional plaque shall contain at least the last four indents described in Requirement 396.
  • This second, additional plaque, if used, shall be affixed next to or beside the first primary plaque described in Requirement 396, and shall have the same protection level. Furthermore the secondary plaque shall also bear the name, address or trade name of the approved fitter or workshop that carried out the installation, and the date of installation.
5.3   Sealing
  • (398)The following parts shall be sealed:
  • — Any connection which, if disconnected, would cause undetectable alterations to be made or undetectable data loss (this may e.g. apply for the motion sensor fitting on the gearbox, the adaptor for M1/N1 vehicles, the external GNSS connection or the vehicle unit);
  • — The installation plaque, unless it is attached in such a way that it cannot be removed without the markings thereon being destroyed.
  • (398a)The seals mentioned above shall be certified according to the standard EN 16882:2016.
  • (399)The seals mentioned above may be removed:
  • — In case of emergency,
  • — To install, to adjust or to repair a speed limitation device or any other device contributing to road safety, provided that the recording equipment continues to function reliably and correctly and is resealed by an approved fitter or workshop (in accordance with Chapter 6) immediately after fitting the speed limitation device or any other device contributing to road safety or within seven days in other cases.
  • (400)On each occasion that these seals are broken a written statement giving the reasons for such action shall be prepared and made available to the competent authority.
  • (401)Seals shall hold an identification number, allocated by its manufacturer. This number shall be unique and distinct from any other seal number allocated by any other seals manufacturer.
  • 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.
  • (402)The seals shall have a free space where approved fitters, workshops or vehicle manufacturers can add a special mark according the Article 22(3) of Regulation (EU) No 165/2014.
  • This mark shall not cover the seal identification number.
  • (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.
  • (405)Seal manufacturers and their distributors shall maintain full traceability records of the seals sold to be used in the frame of Regulation (EU) No 165/2014 and shall be prepared to produce them to competent national authorities whenever need be.
  • (406)Seals unique identification numbers shall be visible on the installation plaque.

6. CHECKS, INSPECTIONS AND REPAIRS

Requirements on the circumstances in which seals may be removed, as referred to in Article 22(5) of Regulation (EU) No 165/2014, are defined in Chapter 5.3 of this annex.

6.1   Approval of fitters, workshops and vehicle manufacturers

The Member States approve, regularly control and certify the bodies to carry out:

  • — installations,
  • — checks,
  • — inspections,
  • — repairs.

Workshop cards shall be issued only to fitters and/or workshops approved for the activation and/or the calibration of recording equipment in conformity with this annex and, unless duly justified:

  • — who are not eligible for a company card;
  • — and whose other professional activities do not present a potential compromise of the overall security of the system as required in Appendix 10.
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.
6.3   Installation inspection
  • (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.
6.4   Periodic inspections
  • (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.
  • (410)These inspections shall include the following checks:
  • — that the recording equipment is working properly, including the data storage in tachograph cards function and the communication with remote communication readers,
  • — that compliance with the provisions of chapter 3.2.1 and 3.2.2 on the maximum tolerances on installation is ensured,
  • — that compliance with the provisions of chapter 3.2.3 and 3.3 is ensured,
  • — that the recording equipment carries the type approval mark,
  • — that the installation plaque, as defined by Requirement 396, and the descriptive plaque, as defined by Requirement 225, are affixed,
  • — the tyre size and the actual circumference of the tyres,
  • — that there are no manipulation devices attached to the equipment,
  • — that seals are correctly placed, in good state, that their identification numbers are valid (referenced seal manufacturer in the EC database) and that their identification numbers correspond to the installation plaque markings (see requirement 401).
  • — that the version identifier of the stored digital map is the most recent one.
  • (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.
  • (411)If one of the events listed in Chapter 3.9 (Detection of Events and/or Faults) is found to have occurred since the last inspection and is considered by tachograph manufacturers and/or national authorities as potentially putting the security of the equipment at risk, the workshop shall:
  • a. make a comparison between the motion sensor identification data of the motion sensor plugged into the gearbox with that of the paired motion sensor registered in the vehicle unit;
  • b. check if the information recorded on the installation plaque matches with the information contained within the vehicle unit record;
  • c. check if the motion sensor serial number and approval number, if printed on the body of the motion sensor, matches the information stored in the recording equipment data memory;
  • d. compare identification data marked on the descriptive plaque of the external GNSS facility, if any, to the ones stored in the vehicle unit data memory;
  • (412)Workshops shall keep traces in their inspection reports of any findings concerning broken seals or manipulations devices. These reports shall be kept by workshops for at least 2 years and made available to the Competent Authority whenever requested to do so.
  • (413)These inspections shall include a calibration and a preventive replacement of the seals whose fitting is under the responsibility of workshops.
6.5   Measurement of errors
  • (414)The measurement of errors on installation and during use shall be carried out under the following conditions, which are to be regarded as constituting standard test conditions:
  • — vehicle unladen, in normal running order,
  • — tyre pressures in accordance with the manufacturer's instructions,
  • — tyre wear, within the limits allowed by national law,
  • — vehicle movement:
  • — the vehicle shall advance under its own engine power in a straight line on level ground and at a speed of 50 ± 5 km/h. The measuring distance shall be at least 1 000  m.
  • — provided that it is of comparable accuracy, alternative methods, such as a suitable test bench, may also be used for the test.
6.6   Repairs
  • (415)Workshops shall be able to download data from the recording equipment to give the data back to the appropriate transport company.
  • (416)Approved workshops shall issue to transport companies a certificate of data un-downloadability where the malfunction of the recording equipment prevents previously recorded data to be downloaded, even after repair by this workshop. The workshops will keep a copy of each issued certificate for at least two years.

7. CARD ISSUING

The card issuing processes set-up by the Member States shall conform to the following:

  • (417)The card number of the first issue of a tachograph card to an applicant shall have a consecutive index (if applicable) and a replacement index and a renewal index set to ‘0’.
  • (418)The card numbers of all non-personal tachograph cards issued to a single control body or a single workshop or a single transport company shall have the same first 13 digits, and shall all have a different consecutive index.
  • (419)A tachograph card issued in replacement of an existing tachograph card shall have the same card number than the replaced one except the replacement index which shall be raised by ‘1’ (in the order 0, …, 9, A, …, Z).
  • (420)A tachograph card issued in replacement of an existing tachograph card shall have the same card expiry date as the replaced one.
  • (421)A tachograph card issued in renewal of an existing tachograph card shall have the same card number as the renewed one except the replacement index which shall be reset to ‘0’ and the renewal index which shall be raised by ‘1’ (in the order 0, …, 9, A, …, Z).
  • (422)The exchange of an existing tachograph card, in order to modify administrative data, shall follow the rules of the renewal if within the same Member State, or the rules of a first issue if performed by another Member State.
  • (423)The ‘card holder surname’ for non-personal workshop or control cards shall be filled with workshop or control body name or with the fitter or control officer's name would Member States so decide.
  • (424)Member States shall exchange data electronically in order to ensure the uniqueness of driver cards that they issue in accordance with Article 31 of Regulation (EU) No 165/2014.

8. TYPE-APPROVAL OF RECORDING EQUIPMENT AND TACHOGRAPH CARDS

8.1   General points

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.

  • (425)Recording equipment shall be submitted for approval complete with any integrated additional devices.
  • (426)Type approval of recording equipment and of tachograph cards shall include security related tests, functional tests and interoperability tests. Positive results to each of these tests are stated by an appropriate certificate.
  • (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.
  • (428)Any modification in software or hardware of the equipment or in the nature of materials used for its manufacture shall, before being used, be notified to the authority which granted type-approval for the equipment. This authority shall confirm to the manufacturer the extension of the type approval, or may require an update or a confirmation of the relevant functional, security and/or interoperability certificates.
  • (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.
8.2   Security certificate
  • (431)The security certificate is delivered in accordance with the provisions of Appendix 10 of this Annex. Recording equipment components to be certified are vehicle unit, motion sensor, external GNSS facility and tachograph cards.
  • (432)In the exceptional circumstance that the security certification authorities refuse to certify new equipment on the ground of obsolescence of the security mechanisms, type approval shall continue to be granted only in these specific and exceptional circumstances, and when no alternative solution, compliant with the Regulation, exists.
  • (433)In this circumstance the Member State concerned shall, without delay, inform the European Commission, which shall, within twelve calendar months of the grant of the type approval, launch a procedure to ensure that the level of security is restored to its original levels.
8.3   Functional certificate
  • (434)Each candidate for type approval shall provide the Member State's type approval authority with all the material and documentation that the authority deems necessary.
  • (435)Manufacturers shall provide the relevant samples of type approval candidate products and associated documentation required by laboratories appointed to perform functional tests, and within one month of the request being made. Any costs resulting from this request shall be borne by the requesting entity. Laboratories shall treat all commercially sensitive information in confidence.
  • (436)A functional certificate shall be delivered to the manufacturer only after all functional tests specified in Appendix 9, at least, have been successfully passed.
  • (437)The type approval authority delivers the functional certificate. This certificate shall indicate, in addition to the name of its beneficiary and the identification of the model, a detailed list of the tests performed and the results obtained.
  • (438)The functional certificate of any recording equipment component shall also indicate the type approval numbers of the other type approved compatible recording equipment components tested for its certification.
  • (439)The functional certificate of any recording equipment component shall also indicate the ISO or CEN standard against which the functional interface has been certified.
8.4   Interoperability certificate
  • (440)Interoperability tests are carried out by a single laboratory under the authority and responsibility of the European Commission.
  • (441)The laboratory shall register interoperability test requests introduced by manufacturers in the chronological order of their arrival.
  • (442)Requests will be officially registered only when the laboratory is in possession of:
  • — the entire set of material and documents necessary for such interoperability tests,
  • — the corresponding security certificate,
  • — the corresponding functional certificate,
  • The date of the registration of the request shall be notified to the manufacturer.
  • (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.
  • (444)Any manufacturer requesting interoperability tests shall commit to leave to the laboratory in charge of these tests the entire set of material and documents which he provided to carry out the tests.
  • (445)The interoperability tests shall be carried out, in accordance with the provisions of Appendix 9 of this Annex, with respectively all the types of recording equipment or tachograph cards:
  • — for which type approval is still valid or,
  • — for which type approval is pending and that have a valid interoperability certificate.
  • (446)The interoperability tests shall cover all generations of recording equipment or tachograph cards still in use.
  • (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.
  • (448)If the interoperability tests are not successful with one or more of the recording equipment or tachograph card(s), the interoperability certificate shall not be delivered, until the requesting manufacturer has realised the necessary modifications and has succeeded the interoperability tests. The laboratory shall identify the cause of the problem with the help of the manufacturers concerned by this interoperability fault and shall attempt to help the requesting manufacturer in finding a technical solution. In the case where the manufacturer has modified its product, it is the manufacturer's responsibility to ascertain from the relevant authorities that the security certificate and the functional certificates are still valid.
  • (449)The interoperability certificate is valid for six months. It is revoked at the end of this period if the manufacturer has not received a corresponding type approval certificate. It is forwarded by the manufacturer to the type approval authority of the Member State who has delivered the functional certificate.
  • (450)Any element that could be at the origin of an interoperability fault shall not be used for profit or to lead to a dominant position.
8.5   Type-approval certificate
  • (451)The type approval authority of the Member State may deliver the type approval certificate as soon as it holds the three required certificates.
  • (452)The type approval certificate of any recording equipment component shall also indicate the type approval numbers of the other type approved interoperable recording equipment.
  • (453)The type approval certificate shall be copied by the type approval authority to the laboratory in charge of the interoperability tests at the time of deliverance to the manufacturer.
  • (454)The laboratory competent for interoperability tests shall run a public web site on which will be updated the list of recording equipment or tachograph cards models:
  • — for which a request for interoperability tests have been registered,
  • — having received an interoperability certificate (even provisional),
  • — having received a type approval certificate.
8.6   Exceptional procedure: first interoperability certificates for 2nd generation recording equipment and tachograph cards
  • (455)Until four months after a first couple of 2nd generation recording equipment and 2nd generation tachograph cards (driver, workshop, control and company cards) have been certified to be interoperable, any interoperability certificate delivered (including the first ones), regarding requests registered during this period, shall be considered provisional.
  • (456)If at the end of this period, all products concerned are mutually interoperable, all corresponding interoperability certificates shall become definitive.
  • (457)If during this period, interoperability faults are found, the laboratory in charge of interoperability tests shall identify the causes of the problems with the help of all manufacturers involved and shall invite them to realize the necessary modifications.

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.