EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 02016R0799-20200226

Consolidated text: 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)Text with EEA relevance

ELI: http://data.europa.eu/eli/reg_impl/2016/799/2020-02-26

02016R0799 — EN — 26.02.2020 — 002.001


This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex. Those official texts are directly accessible through the links embedded in this document

►B

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)

(OJ L 139 26.5.2016, p. 1)

Amended by:

 

 

Official Journal

  No

page

date

►M1

COMMISSION IMPLEMENTING REGULATION (EU) 2018/502 of 28 February 2018

  L 85

1

28.3.2018

►M2

COMMISSION IMPLEMENTING REGULATION (EU) 2020/158 of 5 February 2020

  L 34

20

6.2.2020


Corrected by:

►C1

Corrigendum, OJ L 146, 3.6.2016, p.  31 (2016/799)




▼B

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)



Article 1

Subject matter and scope

1.  This Regulation lays down the provisions necessary for the uniform application of the following aspects regarding tachographs:

(a) 

recording of the position of the vehicle at certain points during the daily working period of the driver;

(b) 

remote early detection of possible manipulation or misuse of smart tachographs;

(c) 

interface with intelligent transport systems;

(d) 

the administrative and technical requirements for the type-approval procedures of tachographs, including the security mechanisms.

▼M1

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.

3.  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 ( 1 ), as applicable.

▼B

4.  Pursuant to Article 10d of Directive 96/53/EC, the remote early detection facility shall also transmit the weight data provided by an internal on-board weighing system, for the purpose of early fraud detection.

▼M1

5.  This Regulation shall be without prejudice to Directive 2014/53/EU of the European Parliament and of the Council ( 2 ).

▼B

Article 2

Definitions

For the purposes of this Regulation, the definitions laid down in Article 2 of Regulation (EU) No 165/2014 shall apply.

In addition, the following definitions shall apply:

(1) 

‘digital tachograph’ or ‘first generation tachograph’ means a digital tachograph other than a smart tachograph;

(2) 

‘external GNSS facility’ means a facility which contains the GNSS receiver when the vehicle unit is not a single unit, as well as other components needed to protect the communication of data about position to the rest of the vehicle unit;

▼M1

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

▼B

(4) 

‘information package’ means the information folder, in electronic or paper form, accompanied by any other documents added by the type-approval authority to the information folder in the course of carrying out their functions including, at the end of the type-approval process, the EC type-approval certificate of the tachograph or a component thereof;

(5) 

‘index to the information package’ means the document listing the numbered contents of the information package identifying all the relevant parts of this package. The format of that document shall distinguish the successive steps in the EC type-approval process, including the dates of any revisions and updating of that package;

(6) 

‘remote early detection facility’ means the equipment of the vehicle unit which is used to perform targeted roadside checks;

▼M1

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

▼B

(9) 

‘type-approval authority’ means the authority of a Member State competent to carry out the type-approval of the tachograph or of its components, the authorisation process, the issuing and, if appropriate, withdrawing of type-approval certificates, acting as the contact point for the type-approval authorities of other Member States and ensuring that the manufacturers meet their obligations relating to the conformity with the requirement of this Regulation;

▼M1

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

▼B

Article 3

Location-based services

1.  Manufacturers shall ensure that smart tachographs are compatible with the positioning services provided by the Galileo and the European Geostationary Navigation Overlay Service (‘EGNOS’) systems.

2.  In addition to the systems referred to in paragraph 1, manufacturers may also choose to ensure compatibility with other satellite navigation systems.

Article 4

Procedure for type-approval of a tachograph and tachograph components

1.  A manufacturer or its agent shall submit an application for type-approval of a tachograph or any of its components, or group of components, to the type-approval authorities designated by each Member State. It shall consist of an information folder containing the information for each of the components concerned including, where applicable, the type-approval certificates of other components necessary to complete the tachograph, as well as any other relevant documents.

2.  A Member State shall grant type-approval to any tachograph, component or group of components that conforms to the administrative and technical requirements referred to in Article 1(2) or (3), as applicable. In that case, the type-approval authority shall issue to the applicant a type-approval certificate that shall conform to the model laid down in Annex II to this Regulation.

3.  The type-approval authority may request the manufacturer or its agent to supply any additional information.

4.  The manufacturer or its agent shall make available to the type-approval authorities, as well as to the entities responsible for issuing the certificates referred to in Article 12(3) of Regulation (EU) No 165/2014, as many tachographs or tachograph components as are necessary to enable the type-approval procedure to be conducted satisfactorily.

5.  Where the manufacturer or its agent seeks a type-approval of certain components or groups of components of a tachograph, he shall provide the type-approval authorities with the other components, already type-approved, as well as other parts necessary for the construction of the complete tachograph, in order for those authorities to conduct the necessary tests.

Article 5

Modifications to type-approvals

1.  The manufacturer or its agent shall inform without delay the type-approval authorities that granted the original type-approval, about any modification in software or hardware of the tachograph or in the nature of the materials used for its manufacture which are recorded in the information package and shall submit an application for the modification of the type-approval.

2.  The type-approval authorities may revise or extend an existing type-approval, or issue a new type-approval according to the nature and characteristics of the modifications.

A ‘revision’ shall be made where the type-approval authority considers that the modifications in software or hardware of the tachograph or in the nature of materials used for its manufacture are minor. In such cases, the type-approval authority shall issue the revised documents of the information package, indicating the nature of the modifications made and the date of their approval. An updated version of the information package in a consolidated form, accompanied by a detailed description of the modifications made, shall be sufficient to meet this requirement.

An ‘extension’ shall be made where the type-approval authority considers that the modifications in software or hardware of the tachograph or in the nature of materials used for its manufacture are substantial. In such cases, it may request that new tests be conducted and inform the manufacturer or its agent accordingly. If those tests prove satisfactory, the type-approval authority shall issue a revised type-approval certificate containing a number referring to the extension granted. The type-approval certificate shall mention the reason of the extension and its date of issue.

3.  The index to the information package shall indicate the date of the most recent extension or revision of the type-approval, or the date of the most recent consolidation of the updated version of the type-approval.

4.  A new type-approval shall be necessary when the requested modifications to the type-approved tachograph or its components would lead to the issuance of a new security or interoperability certificate.

Article 6

Entry into force

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

It shall apply from 2 March 2016.

▼M1

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

▼B

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




ANNEX I C

Requirements for construction, testing, installation, and inspection

INTRODUCTION

1.

DEFINITIONS

2.

GENERAL CHARACTERISTICS AND FUNCTIONS OF THE RECORDING EQUIPMENT

2.1

General characteristics

2.2

Functions

2.3

Modes of operation

2.4

Security

3.

CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR RECORDING EQUIPMENT

3.1

Monitoring cards insertion and withdrawal

3.2

Speed, position and distance measurement

3.2.1

Measurement of distance travelled

3.2.2

Measurement of speed

3.2.3

Measurement of position

3.3

Time measurement

3.4

Monitoring driver activities

3.5

Monitoring driving status

3.6

Driver's entries

3.6.1

Entry of places where daily work periods begin and/or end

3.6.2

Manual entry of driver activities and driver consent for ITS interface

3.6.3

Entry of specific conditions

3.7

Company locks management

3.8

Monitoring control activities

3.9

Detection of events and/or faults

3.9.1

‘Insertion of a non-valid card’ event

3.9.2

‘Card conflict’ event

3.9.3

‘Time overlap’ event

3.9.4

‘Driving without an appropriate card’ event

3.9.5

‘Card insertion while driving’ event

3.9.6

‘Last card session not correctly closed’ event

3.9.7

‘Over speeding’ event

3.9.8

‘Power supply interruption’ event

3.9.9

‘Communication error with the remote communication facility’ event

3.9.10

‘Absence of position information from GNSS receiver’ event

3.9.11

‘Communication error with the external GNSS facility’ event

3.9.12

‘Motion data error’ event

3.9.13

‘Vehicle motion conflict’ event

3.9.14

‘Security breach attempt’ event

3.9.15

‘Time conflict’ event

3.9.16

‘Card’ fault

3.9.17

‘Recording equipment’ fault

3.10

Built-in and self-tests

3.11

Reading from data memory

3.12

Recording and storing in the data memory

3.12.1

Equipment identification data

3.12.1.1

Vehicle unit identification data

3.12.1.2

Motion sensor identification data

3.12.1.3

Global Navigation Satellite Systems identification data

3.12.2

Keys and certificates

3.12.3

Driver or workshop card insertion and withdrawal data

3.12.4

Driver activity data

▼M1

3.12.5

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

▼B

3.12.6

Odometer data

3.12.7

Detailed speed data

3.12.8

Events data

3.12.9

Faults data

3.12.10

Calibration data

3.12.11

Time adjustment data

3.12.12

Control activity data

3.12.13

Company locks data

3.12.14

Download activity data

3.12.15

Specific conditions data

3.12.16

Tachograph card data

3.13

Reading from tachograph cards

3.14

Recording and storing on tachograph cards

3.14.1

Recording and storing in first generation tachograph cards

3.14.2

Recording and storing in second generation tachograph cards

3.15

Displaying

3.15.1

Default display

3.15.2

Warning display

3.15.3

Menu access

3.15.4

Other displays

3.16

Printing

3.17

Warnings

3.18

Data downloading to external media

3.19

Remote communication for targeted roadside checks

3.20

Output data to additional external devices

3.21

Calibration

3.22

Roadside calibration checking

3.23

Time adjustment

3.24

Performance characteristics

3.25

Materials

3.26

Markings

4.

CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR TACHOGRAPH CARDS

4.1

Visible data

4.2

Security

4.3

Standards

4.4

Environmental and electrical specifications

4.5

Data storage

4.5.1

Elementary files for identification and card management

4.5.2

IC card identification

4.5.2.1

Chip identification

4.5.2.2

DIR (only present in second generation tachograph cards)

4.5.2.3

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

4.5.2.4

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

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

4.5.3.1.2

Key and certificates

4.5.3.1.3

Card identification

4.5.3.1.4

Card holder identification

4.5.3.1.5

Card download

4.5.3.1.6

Driving licence information

4.5.3.1.7

Events data

4.5.3.1.8

Faults data

4.5.3.1.9

Driver activity data

4.5.3.1.10

Vehicles used data

4.5.3.1.11

Places where daily work periods start and/or end

4.5.3.1.12

Card session data

4.5.3.1.13

Control activity data

4.5.3.1.14

Specific conditions data

4.5.3.2

Tachograph generation 2 application (not accessible to first generation vehicle unit)

4.5.3.2.1

Application identification

4.5.3.2.2

Keys and certificates

4.5.3.2.3

Card identification

4.5.3.2.4

Card holder identification

4.5.3.2.5

Card download

4.5.3.2.6

Driving licence information

4.5.3.2.7

Events data

4.5.3.2.8

Faults data

4.5.3.2.9

Driver activity data

4.5.3.2.10

Vehicles used data

4.5.3.2.11

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

4.5.3.2.12

Card session data

4.5.3.2.13

Control activity data

4.5.3.2.14

Specific conditions data

4.5.3.2.15

Vehicle units used data

▼M1

4.5.3.2.16

Three hours accumulated driving places data

▼B

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

4.5.4.1.2

Keys and certificates

4.5.4.1.3

Card identification

4.5.4.1.4

Card holder identification

4.5.4.1.5

Card download

4.5.4.1.6

Calibration and time adjustment data

4.5.4.1.7

Events and faults data

4.5.4.1.8

Driver activity data

4.5.4.1.9

Vehicles used data

4.5.4.1.10

Daily work periods start and/or end data

4.5.4.1.11

Card session data

4.5.4.1.12

Control activity data

4.5.4.1.13

Specific conditions data

4.5.4.2

Tachograph generation 2 application (not accessible to first generation vehicle unit)

4.5.4.2.1

Application identification

4.5.4.2.2

Keys and certificates

4.5.4.2.3

Card identification

4.5.4.2.4

Card holder identification

4.5.4.2.5

Card download

4.5.4.2.6

Calibration and time adjustment data

4.5.4.2.7

Events and faults data

4.5.4.2.8

Driver activity data

4.5.4.2.9

Vehicles used data

4.5.4.2.10

Daily work periods start and/or end data

4.5.4.2.11

Card session data

4.5.4.2.12

Control activity data

4.5.4.2.13

Vehicle units used data

▼M1

4.5.4.2.14

Three hours accumulated driving places data

▼B

4.5.4.2.15

Specific conditions data

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

4.5.5.1.2

Keys and certificates

4.5.5.1.3

Card identification

4.5.5.1.4

Card holder identification

4.5.5.1.5

Control activity data

4.5.5.2

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

4.5.5.2.1

Application identification

4.5.5.2.2

Keys and certificates

4.5.5.2.3

Card identification

4.5.5.2.4

Card holder identification

4.5.5.2.5

Control activity data

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

4.5.6.1.2

Keys and certificates

4.5.6.1.3

Card identification

4.5.6.1.4

Card holder identification

4.5.6.1.5

Company activity data

4.5.6.2

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

4.5.6.2.1

Application identification

4.5.6.2.2

Keys and certificates

4.5.6.2.3

Card identification

4.5.6.2.4

Card holder identification

4.5.6.2.5

Company activity data

5.

INSTALLATION OF RECORDING EQUIPMENT

5.1

Installation

5.2

Installation plaque

5.3

Sealing

6.

CHECKS, INSPECTIONS AND REPAIRS

6.1

Approval of fitters, workshops and vehicle manufacturers

▼M1

6.2

Check of new or repaired components

▼B

6.3

Installation inspection

6.4

Periodic inspections

6.5

Measurement of errors

6.6

Repairs

7.

CARD ISSUING

8.

TYPE-APPROVAL OF RECORDING EQUIPMENT AND TACHOGRAPH CARDS

8.1

General points

8.2

Security certificate

8.3

Functional certificate

8.4

Interoperability certificate

8.5

Type-approval certificate

8.6

Exceptional procedure: first interoperability certificates for 2nd generation recording equipment and tachograph cards

INTRODUCTION

The first generation digital tachograph system has been deployed since 1 May 2006. It may be used until its end of life for domestic transportation. For international transportation, instead, 15 years after the entry into force of this Commission Regulation, all vehicles shall be equipped with a compliant second generation smart tachograph, introduced by this Regulation.

This Annex contains second generation recording equipment and tachograph cards requirements. Starting from its introduction date, second generation recording equipment shall be installed in vehicles registered for the first time, and second generation tachograph cards shall be issued.

In order to foster a smooth introduction of the second generation tachograph system:

— 
second generation tachograph cards shall be designed to be also used in first generation vehicle units,
— 
replacement of valid first generation tachograph cards at the introduction date shall not be requested.

This will allow drivers to keep their unique driver card and use both systems with it.

Second generation recording equipment shall however only be calibrated using second generation workshop cards.

This Annex contains all requirements related to the interoperability between the first and the second generation tachograph system.

Appendix 15 contains additional details about how the coexistence of the two systems shall be managed.

List of Appendixes

App 1:

DATA DICTIONARY

App 2:

TACHOGRAPH CARDS SPECIFICATION

App 3:

PICTOGRAMS

App 4:

PRINTOUTS

App 5:

DISPLAY

App 6:

FRONT CONNECTOR FOR CALIBRATION AND DOWNLOAD

App 7:

DATA DOWNLOADING PROTOCOLS

App 8:

CALIBRATION PROTOCOL

App 9:

TYPE-APPROVAL AND LIST OF MINIMUM REQUIRED TESTS

App 10:

SECURITY REQUIREMENTS

App 11:

COMMON SECURITY MECHANISMS

App 12:

POSITIONING BASED ON GLOBAL NAVIGATION SATELLITE SYSTEM (GNSS)

App 13:

ITS INTERFACE

App 14:

REMOTE COMMUNICATION FUNCTION

App 15:

MIGRATION: MANAGING THE COEXISTENCE OF EQUIPMENT GENERATIONS

App 16:

ADAPTOR FOR M1 AND N1 CATEGORY VEHICLES

1.   DEFINITIONS

In this Annex:

(a) 

‘activation’ means:

the phase in which the tachograph becomes fully operational and implements all functions, including security functions, through the use of a workshop card;

(b) 

‘authentication’ means:

a function intended to establish and verify a claimed identity;

(c) 

‘authenticity’ means:

the property that information is coming from a party whose identity can be verified;

(d) 

‘built-in test (BIT)’ means:

tests run at request, triggered by the operator or by external equipment;

(e) 

‘calendar day’ means:

a day ranging from 00:00 hours to 24:00 hours. All calendar days relate to UTC time (Universal Time Coordinated);

(f) 

‘calibration’ of a smart tachograph means:

updating or confirming vehicle parameters to be held in the data memory. Vehicle parameters include vehicle identification (VIN, VRN and registering Member State) and vehicle characteristics (w, k, l, tyre size, speed-limiting device setting (if applicable), current UTC time, current odometer value); during the calibration of a recording equipment, the types and identifiers of all type-approval relevant seals in place shall also be stored in the data memory;

any update or confirmation of UTC time only, shall be considered as a time adjustment and not as a calibration, provided it does not contradict Requirement 409;

calibrating recording equipment requires the use of a workshop card;

(g) 

‘card number’ means:

a 16-alphanumerical character number that uniquely identifies a tachograph card within a Member State. The card number includes a card consecutive index (if applicable), a card replacement index and a card renewal index;

a card is therefore uniquely identified by the code of the issuing Member State and the card number;

(h) 

‘card consecutive index’ means:

the 14th alphanumerical character of a card number that is used to differentiate the different cards issued to a company, a workshop or a control authority entitled to be issued several tachograph cards. The company, the workshop or the control authority is uniquely identified by the 13 first characters of the card number;

(i) 

‘card renewal index’ means:

the 16th alphanumerical character of a card number which is incremented each time a tachograph card is renewed;

(j) 

‘card replacement index’ means:

the 15th alpha-numerical character of a card number which is incremented each time a tachograph card is replaced;

(k) 

‘characteristic coefficient of the vehicle’ means:

the numerical characteristic giving the value of the output signal emitted by the part of the vehicle linking it with the recording equipment (gearbox output shaft or axle) while the vehicle travels a distance of one kilometre under standard test conditions as defined under requirement 414. The characteristic coefficient is expressed in impulses per kilometre (w = … imp/km);

(l) 

‘company card’ means:

a tachograph card issued by the authorities of a Member State to a transport undertaking needing to operate vehicles fitted with a tachograph, which identifies the transport undertaking and allows for the displaying, downloading and printing of the data, stored in the tachograph, which have been locked by that transport undertaking;

(m) 

‘constant of the recording equipment’ means:

the numerical characteristic giving the value of the input signal required to show and record a distance travelled of one kilometre; this constant shall be expressed in impulses per kilometre (k = … imp/km);

(n) 

‘continuous driving time’ is computed within the recording equipment as ( 3 ):

the continuous driving time is computed as the current accumulated driving times of a particular driver, since the end of his last AVAILABILITY or BREAK/REST or UNKNOWN ( 4 ) period of 45 minutes or more (this period may have been split according to Regulation (EC) No 561/2006 of the European Parliament and of the Council ( 5 )). The computations involved take into account, as needed, past activities stored on the driver card. When the driver has not inserted his card, the computations involved are based on the data memory recordings related to the current period where no card was inserted and related to the relevant slot;

(o) 

‘control card’ means:

a tachograph card issued by the authorities of a Member State to a national competent control authority which identifies the control body and, optionally, the control officer, and which allows access to the data stored in the data memory or in the driver cards and, optionally, in the workshop cards for reading, printing and/or downloading;

It shall also give access to the roadside calibration checking function and to data on the remote early detection communication reader;

(p) 

‘cumulative break time’ is computed within the recording equipment as (3) :

the cumulative break from driving time is computed as the current accumulated AVAILABILITY or BREAK/REST or UNKNOWN (4)  times of 15 minutes or more of a particular driver, since the end of his last AVAILABILITY or BREAK/REST or UNKNOWN (4)  period of 45 minutes or more (this period may have been split according to Regulation (EC) No 561/2006).

The computations involved take into account, as needed, past activities stored on the driver card. Unknown periods of negative duration (start of unknown period > end of unknown period) due to time overlaps between two different sets of recording equipment, are not taken into account for the computation.

When the driver has not inserted his card, the computations involved are based on the data memory recordings related to the current period where no card was inserted and related to the relevant slot;

(q) 

‘data memory’ means:

an electronic data storage device built into the recording equipment;

(r) 

‘digital signature’ means:

data appended to, or a cryptographic transformation of, a block of data that allows the recipient of the block of data to prove the authenticity and integrity of the block of data;

(s) 

‘downloading’ means:

the copying, together with the digital signature, of a part, or of a complete set, of data files recorded in the data memory of the vehicle unit or in the memory of a tachograph card, provided that this process does not alter or delete any stored data;

manufacturers of smart tachograph vehicle units and manufacturers of equipment designed and intended to download data files shall take all reasonable steps to ensure that the downloading of such data can be performed with the minimum delay by transport undertakings or drivers;

The downloading of the detailed speed file may not be necessary to establish compliance with Regulation (EC) No 561/2006, but may be used for other purposes such as accident investigation;

(t) 

‘driver card’ means:

a tachograph card, issued by the authorities of a Member State to a particular driver, which identifies the driver and allows for the storage of driver activity data;

(u) 

‘effective circumference of the wheels’ means:

the average of the distances travelled by each of the wheels moving the vehicle (driving wheels) in the course of one complete rotation. The measurement of these distances shall be made under standard test conditions as defined under requirement 414 and is expressed in the form ‘l = … mm’. Vehicle manufacturers may replace the measurement of these distances by a theoretical calculation which takes into account the distribution of the weight on the axles, vehicle unladen in normal running order ( 6 ). The methods for such theoretical calculation are subject to approval by a competent Member State authority and can take place only before tachograph activation;

(v) 

‘event’ means:

an abnormal operation detected by the smart tachograph which may result from a fraud attempt;

(w) 

‘external GNSS facility’ means

a facility which contains the GNSS receiver when the vehicle unit is not a single unit as well as other components needed to protect the communication of position data to the rest of the vehicle unit;

(x) 

‘fault’ means:

abnormal operation detected by the smart tachograph which may come from an equipment malfunction or failure;

(y) 

‘GNSS receiver’ means:

an electronic device that receives and digitally processes the signals from one or more Global Navigation Satellite System(s) (GNSS in English) in order to provide position, speed and time information;

(z) 

‘installation’ means:

the mounting of a tachograph in a vehicle;

(aa) 

‘interoperability’ means:

the capacity of systems and the underlying business processes to exchange data and to share information;

(bb) 

‘interface’ means:

a facility between systems which provides the media through which they can connect and interact;

(cc) 

‘position’ means:

geographical coordinates of the vehicle at a given time;

(dd) 

‘motion sensor’ means:

a part of the tachograph, providing a signal representative of vehicle speed and/or distance travelled;

(ee) 

‘non-valid card’ means:

a card detected as faulty, or which initial authentication failed, or whose start of validity date is not yet reached, or whose expiry date has passed;

(ff) 

‘open standard’ means:

a standard set out in a standard specification document available freely or at a nominal charge which it is permissible to copy, distribute or use for no fee or for a nominal fee;

(gg) 

‘out of scope’ means:

when the use of the recording equipment is not required, according to the provisions of Regulation (EC) No 561/2006;

(hh) 

‘over speeding’ means:

exceeding the authorised speed of the vehicle, defined as any period of more than 60 seconds during which the vehicle's measured speed exceeds the limit for setting the speed limitation device laid down in Council Directive 92/6/EEC ( 7 ), as last amended;

(ii) 

‘periodic inspection’ means:

a set of operations performed to check that the tachograph works properly, that its settings correspond to the vehicle parameters, and that no manipulation devices are attached to the tachograph;

(jj) 

‘printer’ means:

component of the recording equipment which provides printouts of stored data;

(kk) 

‘remote early detection communication’ means:

communication between the remote early detection communication facility and the remote early detection communication reader during targeted roadside checks with the aim of remotely detecting possible manipulation or misuse of recording equipment;

▼M1

(ll) 

‘remote communication facility’ or ‘remote early detection facility’ means:

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

▼B

(mm) 

‘remote early detection communication reader’ means:

the system used by control officers for targeted roadside checks.

(nn) 

‘renewal’ means:

issue of a new tachograph card when an existing card reaches its expiry date, or is malfunctioning and has been returned to the issuing authority. Renewal always implies the certainty that two valid cards do not coexist;

(oo) 

‘repair’ means:

any repair of a motion sensor or of a vehicle unit or of a cable that requires the disconnection of its power supply, or its disconnection from other tachograph components, or the opening of the motion sensor or vehicle unit;

(pp) 

‘card replacement’ means:

issue of a tachograph card in replacement of an existing card, which has been declared lost, stolen or malfunctioning and has not been returned to the issuing authority. Replacement always implies a risk that two valid cards may coexist;

(qq) 

‘security certification’ means:

process to certify, by a common criteria certification body, that the recording equipment (or component) or the tachograph card under investigation fulfils the security requirements defined in the relative protection profiles;

(rr) 

‘self test’ means:

tests run cyclically and automatically by the recording equipment to detect faults;

(ss) 

‘time measurement’ means:

a permanent digital record of the coordinated universal date and time (UTC);

▼M1

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

▼B

(uu) 

‘tyre size’ means:

the designation of the dimensions of the tyres (external driving wheels) in accordance with Council Directive 92/23/EEC ( 8 ) as last amended;

(vv) 

‘vehicle identification’ means:

numbers identifying the vehicle: vehicle registration number (VRN) with indication of the registering Member State and vehicle identification number (VIN) ( 9 );

(ww) 

for computing sake in the recording equipment ‘week’ means:

the period between 00:00 hours UTC on Monday and 24:00 UTC on Sunday;

(xx) 

‘workshop card’ means:

a tachograph card issued by the authorities of a Member State to designated staff of a tachograph manufacturer, a fitter, a vehicle manufacturer or a workshop, approved by that Member State, which identifies the cardholder and allows for the testing, calibration and activation of tachographs, and/or downloading from them;

(yy) 

‘adaptor’ means:

a device, providing a signal permanently representative of vehicle speed and/or distance travelled, other than the one used for the independent movement detection, and which is:

▼M1

— 
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 ( 10 ), as last amended),

▼B

— 
installed where it is not mechanically possible to install any other type of existing motion sensor which is otherwise compliant with the provisions of this Annex and its Appendixes 1 to 15,
— 
installed between the vehicle unit and where the speed/distance impulses are generated by integrated sensors or alternative interfaces,
— 
seen from a vehicle unit, the adaptor behaviour is the same as if a motion sensor, compliant with the provisions of this Annex and its Appendixes 1 to 16, was connected to the vehicle unit;

use of such an adaptor in those vehicles described above shall allow for the installation and correct use of a vehicle unit compliant with all the requirements of this Annex,

for those vehicles, the smart tachograph includes cables, an adaptor, and a vehicle unit;

(zz) 

‘data integrity’ means:

the accuracy and consistency of stored data, indicated by an absence of any alteration in data between two updates of a data record. Integrity implies that the data is an exact copy of the original version, e.g. that it has not been corrupted in the process of being written to, and read back from, a tachograph card or a dedicated equipment or during transmission via any communications channel;

(aaa) 

‘data privacy’ means:

the overall technical measures taken to ensure the proper implementation of the principles laid down in Directive 95/46/EC of the European Parliament and of the Council ( 11 ) as well as of those laid down in Directive 2002/58/EC of the European Parliament and of the Council ( 12 );

(bbb) 

‘smart tachograph’ system means:

the recording equipment, tachograph cards and the set of all directly or indirectly interacting equipment during their construction, installation, use, testing and control, such as cards, remote communication reader and any other equipment for data downloading, data analysis, calibration, generating, managing or introducing security elements, etc.;

(ccc) 

‘introduction date’:

36 months after the entry into force of the detailed provisions referred to in Article 11 of Regulation (EU) No 165/2014 of the European Parliament and of the Council ( 13 )

This is the date after which vehicles registered for the first time:

— 
shall be fitted with a tachograph connected to a positioning service based on a satellite navigation system,
— 
shall be able to communicate data for targeted roadside checks to competent control authorities while the vehicle is in motion,
— 
and may be equipped with standardised interfaces allowing the data recorded or produced by tachographs to be used in operational mode, by an external device.
(ddd) 

‘protection profile’ means:

a document used as part of certification process according Common Criteria, providing implementation independent specification of information assurance security requirements;

(eee) 

‘GNSS accuracy’:

in the context of recording the position from a Global Navigation Satellite System (GNSS) with tachographs, means the value of the horizontal dilution of precision (HDOP) calculated as the minimum of the HDOP values collected on the available GNSS systems;

▼M1

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

▼B

2.   GENERAL CHARACTERISTICS AND FUNCTIONS OF THE RECORDING EQUIPMENT

2.1    General characteristics

The purpose of the recording equipment is to record, store, display, print, and output data related to driver activities.

Any vehicle fitted with the recording equipment complying with the provisions of this Annex, must include a speed display and an odometer. These functions may be included within the recording equipment.

(1) The recording equipment includes cables, a motion sensor, and a vehicle unit.

(2) The interface between motion sensors and vehicle units shall comply with the requirements specified in Appendix 11.

(3) The vehicle unit shall be connected to global navigation satellite system(s), as specified in Appendix 12.

(4) The vehicle unit shall communicate with remote early detection communication readers, as specified in Appendix 14.

(5) The vehicle unit may include an ITS interface, which is specified in Appendix 13

The recording equipment may be connected to other facilities through additional interfaces and/or through the optional ITS interface.

(6) Any inclusion in or connection to the recording equipment of any function, device, or devices, approved or otherwise, shall not interfere with, or be capable of interfering with, the proper and secure operation of the recording equipment and the provisions of this Regulation.

Recording equipment users identify themselves to the equipment via tachograph cards.

(7) The recording equipment provides selective access rights to data and functions according to user's type and/or identity.

The recording equipment records and stores data in its data memory, in the remote communication facility and in tachograph cards.

This is done in accordance with Directive 95/46/EC of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data ( 14 ), with Directive 2002/58/EC of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector ( 15 ) and in compliance with Article 7 of Regulation (EU) No. 165/2014.

2.2    Functions

(8) The recording equipment shall ensure the following functions:

— 
monitoring cards insertions and withdrawals,
— 
speed, distance and position measurement,
— 
time measurement,
— 
monitoring driver activities,
— 
monitoring driving status,
— 
drivers manual entries:
— 
entry of places where daily work periods begin and/or end,
— 
manual entry of driver activities,
— 
entry of specific conditions,
— 
company locks management,
— 
monitoring control activities,
— 
detection of events and/or faults,
— 
built-in and self-tests,
— 
reading from data memory,
— 
recording and storing in data memory,
— 
reading from tachograph cards,
— 
recording and storing in tachograph cards,
— 
displaying,
— 
printing,
— 
warning,
— 
data downloading to external media,
— 
remote communication for targeted roadside checks,
— 
output data to additional facilities,
— 
calibration,
— 
roadside calibration check,
— 
time adjustment.

2.3    Modes of operation

(9) The recording equipment shall possess four modes of operation:

— 
operational mode,
— 
control mode,
— 
calibration mode,
— 
company mode.

(10) The recording equipment shall switch to the following mode of operation according to the valid tachograph cards inserted into the card interface devices. In order to determine the mode of operation, the tachograph card generation is irrelevant, provided the inserted card is valid. A first generation workshop card shall always be considered as non-valid when it is inserted in a second generation VU.



Mode of operation

Driver slot

No card

Driver card

Control card

Workshop card

Company card

Co-driver slot

No card

Operational

Operational

Control

Calibration

Company

Driver card

Operational

Operational

Control

Calibration

Company

Control card

Control

Control

Control (*1)

Operational

Operational

Workshop card

Calibration

Calibration

Operational

Calibration (*1)

Operational

Company card

Company

Company

Operational

Operational

Company (*1)

(*1)   In these situations the recording equipment shall use only the tachograph card inserted in the driver slot.

(11) The recording equipment shall ignore non-valid cards inserted, except displaying, printing or downloading data held on an expired card which shall be possible.

(12) All functions listed in 2.2. shall work in any mode of operation with the following exceptions:

— 
the calibration function is accessible in the calibration mode only,
— 
the roadside calibration checking function is accessible in the control mode only,
— 
the company locks management function is accessible in the company mode only,
— 
the monitoring of control activities function is operational in the control mode only,
— 
The downloading function is not accessible in the operational mode (except as provided for in requirement 193), and except downloading a driver card when no other card type is inserted into the VU.

(13) The recording equipment can output any data to display, printer or external interfaces with the following exceptions:

— 
in the operational mode, any personal identification (surname and first name(s)) not corresponding to a tachograph card inserted shall be blanked and any card number not corresponding to a tachograph card inserted shall be partially blanked (every odd character — from left to right — shall be blanked),
— 
in the company mode, driver related data (requirements 102, 105 and 108) can be output only for periods where no lock exists or no other company holds a lock (as identified by the first 13 digits of the company card number),
— 
when no card is inserted in the recording equipment, driver related data can be output only for the current and 8 previous calendar days,
— 
personal data originating from the VU shall not be output through ITS interface of the VU unless the consent of the driver to whom the data relates is verified,

▼M1

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

▼B

2.4    Security

▼M1

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.

▼B

(14) In order to achieve the system security, the following components shall meet the security requirements specified in their Protection Profiles, as required in Appendix 10:

— 
vehicle unit,
— 
tachograph card,
— 
motion sensor,
— 
external GNSS facility (this Profile is only needed and applicable for the external GNSS variant).

3.   CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR RECORDING EQUIPMENT

3.1    Monitoring cards insertion and withdrawal

(15) The recording equipment shall monitor the card interface devices to detect card insertions and withdrawals.

(16) Upon card insertion the recording equipment shall detect whether the card inserted is a valid tachograph card and in such a case identify the card type and the card generation.

If a card with the same card number and a higher renewal index has already been inserted in the recording equipment, the card shall be declared as non-valid.

If a card with the same card number and renewal index but with a higher replacement index has already been inserted in the recording equipment, the card shall be declared as non-valid.

(17) First generation tachograph cards shall be considered as non-valid by the recording equipment, after the possibility of using first generation tachograph cards has been suppressed by a workshop, in compliance with Appendix 15 (req. MIG003).

(18) First generation workshop cards which are inserted in the second generation recording equipment shall be considered as non-valid.

(19) The recording equipment shall be so designed that the tachograph cards are locked in position on their proper insertion into the card interface devices.

(20) The release of tachograph cards may function only when the vehicle is stopped and after the relevant data have been stored on the cards. The release of the card shall require positive action by the user.

3.2    Speed, position and distance measurement

(21) The motion sensor (possibly embedded in the adaptor) is the main source for speed and distance measurement.

(22) This function shall continuously measure and be able to provide the odometer value corresponding to the total distance travelled by the vehicle using the pulses provided by the motion sensor.

(23) This function shall continuously measure and be able to provide the speed of the vehicle using the pulses provided by the motion sensor.

(24) The speed measurement function shall also provide the information whether the vehicle is moving or stopped. The vehicle shall be considered as moving as soon as the function detects more than 1 imp/sec for at least 5 seconds from the motion sensor, otherwise the vehicle shall be considered as stopped.

(25) Devices displaying speed (speedometer) and total distance travelled (odometer) installed in any vehicle fitted with a recording equipment complying with the provisions of this Regulation, shall comply with the requirements relating to maximum tolerances (see 3.2.1 and 3.2.2) laid down in this Annex.

(26) To detect manipulation of motion data, information from the motion sensor shall be corroborated by vehicle motion information derived from the GNSS receiver and optionally by other source(s) independent from the motion sensor.

(27) This function shall measure the position of the vehicle in order to allow for the automatic recording of:

— 
positions where the driver and/or the co-driver begins his daily work period;

▼M1

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

▼B

— 
positions where the driver and/or the co-driver ends his daily work period.

3.2.1    Measurement of distance travelled

(28) The distance travelled may be measured either:

— 
so as to cumulate both forward and reverse movements, or
— 
so as to include only forward movement.

(29) The recording equipment shall measure distance from 0 to 9 999 999,9  km.

(30) Distance measured shall be within the following tolerances (distances of at least 1 000  m.):

— 
± 1 % before installation,
— 
± 2 % on installation and periodic inspection,
— 
± 4 % in use.

(31) Distance measured shall have a resolution better than or equal to 0,1 km.

3.2.2    Measurement of speed

(32) The recording equipment shall measure speed from 0 to 220 km/h.

(33) To ensure a maximum tolerance on speed displayed of ± 6 km/h in use, and taking into account:

— 
a ± 2 km/h tolerance for input variations (tyre variations, …),
— 
a ± 1 km/h tolerance in measurements made during installation or periodic inspections,

the recording equipment shall, for speeds between 20 and 180 km/h, and for characteristic coefficients of the vehicle between 4 000 and 25 000 imp/km, measure the speed with a tolerance of ± 1 km/h (at constant speed).

Note: The resolution of data storage brings an additional tolerance of ± 0,5 km/h to speed stored by the recording equipment.

(34) The speed shall be measured correctly within the normal tolerances within 2 seconds of the end of a speed change when the speed has changed at a rate up to 2 m/s2.

(35) Speed measurement shall have a resolution better than or equal to 1 km/h.

3.2.3    Measurement of position

(36) The recording equipment shall measure the absolute position of the vehicle using the GNSS receiver.

(37) The absolute position is measured in geographical coordinates of latitude and longitude in degrees and minutes with a resolution of 1/10 of a minute.

3.3    Time measurement

(38) The time measurement function shall measure permanently and digitally provide UTC date and time.

(39) UTC date and time shall be used for dating data inside the recording equipment (recordings, data exchange) and for all printouts specified in Appendix 4 ‘Printouts’.

(40) In order to visualise the local time, it shall be possible to change the offset of the time displayed, in half hour steps. No other offsets than negative or positive multiples of half hours shall be allowed;

(41) Time drift shall be within ± 2 seconds per day in type approval conditions, in the absence of any time adjustment.

(42) Time measured shall have a resolution better than or equal to 1 second.

(43) Time measurement shall not be affected by an external power supply cut-off of less than 12 months in type approval conditions.

3.4    Monitoring driver activities

(44) This function shall permanently and separately monitor the activities of one driver and one co-driver.

(45) Driver activity shall be DRIVING, WORK, AVAILABILITY or BREAK/REST.

(46) It shall be possible for the driver and/or the co-driver to manually select WORK, AVAILABILITY or BREAK/REST.

(47) When the vehicle is moving, DRIVING shall be selected automatically for the driver and AVAILABILITY shall be selected automatically for the co-driver.

(48) When the vehicle stops, WORK shall be selected automatically for the driver.

▼M1

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

▼B

(50) This function shall output activity changes to the recording functions at a resolution of one minute.

(51) Given a calendar minute, if DRIVING is registered as the activity of both the immediately preceding and the immediately succeeding minute, the whole minute shall be regarded as DRIVING.

(52) Given a calendar minute that is not regarded as DRIVING according to requirement 051, the whole minute shall be regarded to be of the same type of activity as the longest continuous activity within the minute (or the latest of the equally long activities).

(53) This function shall also permanently monitor the continuous driving time and the cumulative break time of the driver.

3.5    Monitoring driving status

(54) This function shall permanently and automatically monitor the driving status.

(55) The driving status CREW shall be selected when two valid driver cards are inserted in the equipment, the driving status SINGLE shall be selected in any other case.

3.6    Driver's entries

3.6.1    Entry of places where daily work periods begin and/or end

(56) This function shall allow for the entry of places where, according to the driver and/or the co-driver, his daily work periods begin and/or end.

(57) Places are defined as the country and, in addition where applicable, the region, which are entered or confirmed manually.

(58) At the time of a driver card withdrawal, the recording equipment shall prompt the (co-)driver to enter a ‘place where the daily work period ends’.

▼M1

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

▼B

(60) It shall be possible to input places where daily work periods begin and/or end through commands in the menus. If more than one such input is done within one calendar minute, only the last begin place input and the last end place input done within that time shall be kept recorded.

3.6.2    Manual entry of driver activities and driver consent for ITS interface

(61) Upon driver (or workshop) card insertion, and only at this time, the recording equipment shall allow manual entries of activities. Manual entries of activities shall be performed using local time and date values of the time zone (UTC offset) currently set for the vehicle unit.

At driver or workshop card insertion the cardholder shall be reminded of:

— 
the date and time of his last card withdrawal;
— 
optionally: the local time offset currently set for the vehicle unit.

At the first insertion of a given driver card or workshop card currently unknown to the vehicle unit, the cardholder shall be invited to express his consent for tachograph related personal data output through the optional ITS interface.

At any moment, the driver (resp. workshop) consent can be enabled or disabled through commands in the menu, provided the driver (resp. workshop) card is inserted.

It shall be possible to input activities with the following restrictions:

— 
Activity type shall be WORK, AVAILABILITY or BREAK/REST;
— 
Start and end times for each activity shall be within the period of the last card withdrawal — current insertion only;
— 
Activities shall not be allowed to overlap mutually in time.

It shall be possible to make manual entries, if required, at the first insertion of a previously unused driver (or workshop) card.

The procedure for manual entries of activities shall include as many consecutive steps as necessary to set a type, a start time and an end time for each activity. For any part of the time period between last card withdrawal and current card insertion, the cardholder shall have the option not to declare any activity.

During the manual entries associated with card insertion and if applicable, the card holder shall have the opportunity to input:

▼M1

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

▼B

If the card holder doesn't enter any place where the work period begins or ended, during the manual entries associated with card insertion, this shall be considered as a declaration that his work period has not changed since the last card withdrawal. The next entry of a place where a previous daily work period ends shall then overwrite the temporary entry made at the last card withdrawal.

If a place is entered, it shall be recorded in the relevant tachograph card.

Manual entries shall be interrupted if:

— 
the card is withdrawn or,
— 
the vehicle is moving and the card is in the driver slot.

Additional interruptions are allowed, e.g. a timeout after a certain period of user inactivity. If manual entries are interrupted, the recording equipment shall validate any complete place and activity entries (having either unambiguous place and time, or activity type, begin time and end time) already made.

If a second driver or workshop card is inserted while manual entries of activities are in progress for a previously inserted card, the manual entries for this previous card shall be allowed to be completed before manual entries start for the second card.

The cardholder shall have the option to insert manual entries according to the following minimum procedure:

— 
Enter activities manually, in chronological order, for the period last card withdrawal — current insertion.
— 
Begin time of the first activity shall be set to card withdrawal time. For each subsequent entry, the start time shall be preset to immediately follow the end time of the previous entry. Activity type and end time shall be selected for each activity.

The procedure shall end when the end time of a manually entered activity equals the card insertion time. The recording equipment may then optionally allow the card holder to modify any activity manually entered, until validation by selection of a specific command. Thereafter, any such modification shall be forbidden.

3.6.3    Entry of specific conditions

(62) The recording equipment shall allow the driver to enter, in real time, the following two specific conditions:

— 
‘OUT OF SCOPE’ (begin, end)
— 
‘FERRY / TRAIN CROSSING’ (begin, end).

A ‘FERRY / TRAIN CROSSING’ may not occur if an ‘OUT OF SCOPE’ condition is opened.

An opened ‘OUT OF SCOPE’ condition must be automatically closed, by the recording equipment, if a driver card is inserted or withdrawn.

An opened ‘OUT OF SCOPE’ condition shall inhibit the following events and warnings:

— 
Driving without an appropriate card,
— 
Warnings associated with continuous driving time.

The FERRY / TRAIN CROSSING begin flag shall be set before shutting down the engine on the ferry/train.

An opened FERRY / TRAIN CROSSING must end when any of following options occurs:

— 
The driver manually ends the FERRY/TRAIN CROSSING
— 
The driver ejects his card

An opened FERRY/TRAIN CROSSING shall end when it is no longer valid based on the rules stated in Regulation (EC) No. 561/2006.

3.7    Company locks management

(63) This function shall allow the management of the locks placed by a company to restrict data access in company mode to itself.

(64) Company locks consist in a start date/time (lock-in) and an end date/time (lock-out) associated with the identification of the company as denoted by the company card number (at lock-in).

(65) Locks may be turned ‘in’ or ‘out’ in real time only.

(66) Locking-out shall only be possible for the company whose lock is ‘in’ (as identified by the first 13 digits of the company card number), or,

(67) Locking-out shall be automatic if another company locks in.

(68) In the case where a company locks in and where the previous lock was for the same company, then it will be assumed that the previous lock has not been turned ‘out’ and is still ‘in’.

3.8    Monitoring control activities

(69) This function shall monitor DISPLAYING, PRINTING, VU and card DOWNLOADING, and ROADSIDE CALIBRATION check activities carried while in control mode.

(70) This function shall also monitor OVER SPEEDING CONTROL activities while in control mode. An over speeding control is deemed to have happened when, in control mode, the ‘over speeding’ printout has been sent to the printer or to the display, or when ‘events and faults’ data have been downloaded from the VU data memory.

3.9    Detection of events and/or faults

(71) This function shall detect the following events and/or faults:

3.9.1    ‘Insertion of a non-valid card’ event

(72) This event shall be triggered at the insertion of any non-valid card, at the insertion of a driver card already replaced and/or when an inserted valid card expires.

3.9.2    ‘Card conflict’ event

(73) This event shall be triggered when any of the valid cards combination noted X in the following table arises:



Card conflict

Driver slot

No card

Driver card

Control card

Workshop card

Company card

Co-driver slot

No card

 

 

 

 

 

Driver card

 

 

 

X

 

Control card

 

 

X

X

X

Workshop card

 

X

X

X

X

Company card

 

 

X

X

X

3.9.3    ‘Time overlap’ event

(74) This event shall be triggered when the date / time of last withdrawal of a driver card, as read from the card, is later than the current date / time of the recording equipment in which the card is inserted.

3.9.4    ‘Driving without an appropriate card’ event

(75) This event shall be triggered for any valid tachograph cards combination noted X in the following table, when driver activity changes to DRIVING, or when there is a change of the mode of operation while driver activity is DRIVING:



Driving without an appropriate card

Driver slot

No (or non-valid) card

Driver card

Control card

Workshop card

Company card

Co-driver slot

No (or non-valid) card

X

 

X

 

X

Driver card

X

 

X

X

X

Control card

X

X

X

X

X

Workshop card

X

X

X

 

X

Company card

X

X

X

X

X

3.9.5    ‘Card insertion while driving’ event

(76) This event shall be triggered when a tachograph card is inserted in any slot, while driver activity is DRIVING.

3.9.6    ‘Last card session not correctly closed’ event

(77) This event shall be triggered when at card insertion the recording equipment detects that, despite the provisions laid down in paragraph 3.1., the previous card session has not been correctly closed (the card has been withdrawn before all relevant data have been stored on the card). This event shall be triggered by driver and workshop cards only.

3.9.7    ‘Over speeding’ event

(78) This event shall be triggered for each over speeding.

3.9.8    ‘Power supply interruption’ event

(79) This event shall be triggered, while not in calibration or control mode, in case of any interruption exceeding 200 milliseconds of the power supply of the motion sensor and/or of the vehicle unit. The interruption threshold shall be defined by the manufacturer. The drop in power supply due to the starting of the engine of the vehicle shall not trigger this event.

3.9.9    ‘Communication error with the remote communication facility’ event

(80) This event shall be triggered, while not in calibration mode, when the remote communication facility does not acknowledge the successful reception of remote communication data sent from the vehicle unit for more than three attempts.

3.9.10    ‘Absence of position information from GNSS receiver’ event

(81) This event shall be triggered, while not in calibration mode, in case of absence of position information originating from the GNSS receiver (whether internal or external) for more than three hours of accumulated driving time.

3.9.11    ‘Communication error with the external GNSS facility’ event

(82) This event shall be triggered, while not in calibration mode, in case of interruption of the communication between the external GNSS facility and the vehicle unit for more than 20 continuous minutes, when the vehicle is moving.

3.9.12    ‘Motion data error’ event

(83) This event shall be triggered, while not in calibration mode, in case of interruption of the normal data flow between the motion sensor and the vehicle unit and/or in case of data integrity or data authentication error during data exchange between the motion sensor and the vehicle unit.

3.9.13    ‘Vehicle motion conflict’ event

(84) This event shall be triggered, while not in calibration mode, in case motion information calculated from the motion sensor is contradicted by motion information calculated from the internal GNSS receiver or from the external GNSS facility and optionally by other independent sources, as specified in Appendix 12. This event shall not be triggered during a ferry/train crossing, an OUT OF SCOPE condition, or when the position information from the GNSS receiver is not available.

3.9.14    ‘Security breach attempt’ event

(85) This event shall be triggered for any other event affecting the security of the motion sensor and/or of the vehicle unit and/or the external GNSS facility as required in Appendix 10, while not in calibration mode.

▼M1

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.

▼B

3.9.16    ‘Card’ fault

(87) This fault shall be triggered when a tachograph card failure occurs during operation.

3.9.17    ‘Recording equipment’ fault

(88) This fault shall be triggered for any of these failures, while not in calibration mode:

— 
VU internal fault
— 
Printer fault
— 
Display fault
— 
Downloading fault
— 
Sensor fault
— 
GNSS receiver or external GNSS facility fault
— 
Remote Communication facility fault

▼M1

— 
ITS interface fault (if applicable)

▼B

3.10    Built-in and self-tests

(89)  ►M1  The recording equipment shall detect faults through self-tests and built-in-tests, according to the following table: ◄



Sub-assembly to test

Self-test

Built-in-test

Software

 

Integrity

Data memory

Access

Access, data integrity

Card interface devices

Access

Access

Keyboard

 

Manual check

Printer

(up to manufacturer)

Printout

Display

 

Visual check

Downloading

(performed only during downloading)

Proper operation

 

Sensor

Proper operation

Proper operation

Remote communication facility

Proper operation

Proper operation

GNSS facility

Proper operation

Proper operation

▼M1

ITS interface (optional)

Proper operation

 

▼B

3.11    Reading from data memory

(90) The recording equipment shall be able to read any data stored in its data memory.

3.12    Recording and storing in the data memory

For the purpose of this paragraph,

— 
‘365 days’ is defined as 365 calendar days of average drivers' activity in a vehicle. The average activity per day in a vehicle is defined as at least 6 drivers or co-drivers, 6 card insertion withdrawal cycles, and 256 activity changes. ‘365 days’ therefore include at least 2 190 (co-)drivers, 2 190 card insertion withdrawal cycles, and 93 440 activity changes,

▼M1

— 
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 6 570 positions,

▼B

— 
times are recorded with a resolution of one minute, unless otherwise specified,
— 
odometer values are recorded with a resolution of one kilometre,
— 
speeds are recorded with a resolution of 1 km/h,
— 
positions (latitudes and longitudes) are recorded in degrees and minutes, with a resolution of 1/10 of minute, with the associated GNSS accuracy and acquisition time.

(91) Data stored into the data memory shall not be affected by an external power supply cut-off of less than twelve months in type approval conditions. In addition, data stored in the external remote communication facility, as defined in Appendix 14, shall not be affected by power-supply cut-off of less than 28 days.

(92) The recording equipment shall be able to record and store implicitly or explicitly in its data memory the following:

3.12.1    Equipment identification data

3.12.1.1    Vehicle unit identification data

(93) The recording equipment shall be able to store in its data memory the following vehicle unit identification data:

— 
name of the manufacturer,
— 
address of the manufacturer,
— 
part number,
— 
serial number,
— 
VU generation,
— 
ability to use first generation tachograph cards,
— 
software version number,
— 
software version installation date,
— 
year of equipment manufacture,
— 
approval number,

(94) Vehicle unit identification data are recorded and stored once and for all by the vehicle unit manufacturer, except the software related data and the approval number which may be changed in case of software upgrade and the ability to use first generation tachograph cards.

3.12.1.2    Motion sensor identification data

(95) The motion sensor shall be able to store in its memory the following identification data:

— 
name of the manufacturer,
— 
serial number,
— 
approval number,
— 
embedded security component identifier (e.g. internal chip/processor part number),
— 
operating system identifier (e.g. software version number).

(96) Motion sensor identification data are recorded and stored once and for all in the motion sensor, by the motion sensor manufacturer.

(97) The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent pairing of motion sensors (if several pairings happen within one calendar day, only the first and the last one of the day shall be stored):

The following data shall be recorded for each of these pairings:

— 
motion sensor identification data:
— 
serial number
— 
approval number
— 
motion sensor pairing data:
— 
pairing date.

3.12.1.3    Global Navigation Satellite Systems identification data

(98) The external GNSS facility shall be able to store in its memory the following identification data:

— 
name of the manufacturer,
— 
serial number,
— 
approval number,
— 
embedded security component identifier (e.g. internal chip/processor part number),
— 
operating system identifier (e.g. software version number).

(99) The identification data are recorded and stored once and for all in the external GNSS facility, by the external GNSS facility manufacturer.

(100) The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent couplings of external GNSS facilities (if several couplings happen within one calendar day, only the first and the last one of the day shall be stored).

The following data shall be recorded for each of these couplings:

— 
external GNSS facility identification data:
— 
serial number,
— 
approval number,
— 
external GNSS facility coupling data:
— 
coupling date

3.12.2    Keys and certificates

(101) The recording equipment shall be able to store a number of cryptographic keys and certificates, as specified in Appendix 11 part A and part B.

3.12.3    Driver or workshop card insertion and withdrawal data

(102) For each insertion and withdrawal cycle of a driver or workshop card in the equipment, the recording equipment shall record and store in its data memory:

— 
the card holder's surname and first name(s) as stored in the card,
— 
the card's number, issuing Member State and expiry date as stored in the card,
— 
the card generation,
— 
the insertion date and time,
— 
the vehicle odometer value at card insertion,
— 
the slot in which the card is inserted,
— 
the withdrawal date and time,
— 
the vehicle odometer value at card withdrawal,
— 
the following information about the previous vehicle used by the driver, as stored in the card:
— 
VRN and registering Member State,
— 
VU generation (when available),
— 
card withdrawal date and time,
— 
a flag indicating whether, at card insertion, the card holder has manually entered activities or not.

(103) The data memory shall be able to hold these data for at least 365 days.

(104) When storage capacity is exhausted, new data shall replace oldest data.

3.12.4    Driver activity data

(105) The recording equipment shall record and store in its data memory whenever there is a change of activity for the driver and/or the co-driver, and/or whenever there is a change of driving status, and/or whenever there is an insertion or withdrawal of a driver or workshop card:

— 
the driving status (CREW, SINGLE),
— 
the slot (DRIVER, CO-DRIVER),
— 
the card status in the relevant slot (INSERTED, NOT INSERTED),
— 
the activity (DRIVING, AVAILABILITY, WORK, BREAK/REST),
— 
the date and time of the change.

INSERTED means that a valid driver or workshop card is inserted in the slot. NOT INSERTED means the opposite i.e. no valid driver or workshop card is inserted in the slot (e.g. a company card is inserted or no card is inserted)

Activity data manually entered by a driver are not recorded in the data memory.

(106) The data memory shall be able to hold driver activity data for at least 365 days.

(107) When storage capacity is exhausted, new data shall replace oldest data.

▼M1

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

(109) When the position of the vehicle is not available from the GNSS receiver at these times, the recording equipment shall use the latest available position, and the related date and time.

(110) Together with each place or position, the recording equipment shall record and store in its data memory:

— 
the (co-)driver card number and card issuing Member State,
— 
the card generation,
— 
the date and time of the entry,

▼M1

— 
the type of entry (begin, end or 3 hours accumulated driving time),

▼B

— 
the related GNSS accuracy, date and time if applicable;
— 
the vehicle odometer value.

▼M1

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

▼B

(112) When storage capacity is exhausted, new data shall replace oldest data.

3.12.6    Odometer data

(113) The recording equipment shall record in its data memory the vehicle odometer value and the corresponding date at midnight every calendar day.

(114) The data memory shall be able to store midnight odometer values for at least 365 calendar days.

(115) When storage capacity is exhausted, new data shall replace oldest data.

3.12.7    Detailed speed data

▼M1

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

▼B

3.12.8    Events data

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

(117) The recording equipment shall record and store in its data memory the following data for each event detected according to the following storage rules:



Event

Storage rules

Data to be recorded per event

Insertion of a non-valid card

— the 10 most recent events.

— date and time of event,

— card(s) type, number, issuing Member State and generation of the card creating the event.

— number of similar events that day

Card conflict

— the 10 most recent events.

— date and time of beginning of event,

— date and time of end of event,

— card(s) type, number, issuing Member State and generation of the two cards creating the conflict.

Driving without an appropriate card

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

Card insertion while driving

— the last event for each of the 10 last days of occurrence,

— date and time of the event,

— card(s) type, number, issuing Member State and generation,

— number of similar events that day

Last card session not correctly closed

— the 10 most recent events.

— date and time of card insertion,

— card(s) type, number, issuing Member State and generation,

— last session data as read from the card:

— 

— date and time of card insertion,

— VRN, Member State of registration and VU generation.

Over speeding (1)

— the most serious event for each of the 10 last days of occurrence (i.e. the one with the highest average speed),

— the 5 most serious events over the last 365 days.

— the first event having occurred after the last calibration

— date and time of beginning of event,

— date and time of end of event,

— maximum speed measured during the event,

— arithmetic average speed measured during the event,

— card type, number, issuing Member State and generation of the driver card (if applicable),

— number of similar events that day.

Power supply interruption (2)

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

Communication error with the remote communication 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.

Absence of position information from GNSS receiver

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

▼M1

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.

▼B

Motion data error

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

Vehicle motion conflict

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

Security breach attempt

— the 10 most recent events per type of event.

— date and time of beginning of event,

— date and time of end of event (if relevant),

— card(s) type, number, issuing Member State and generation of any card inserted at beginning and/or end of the event,

— type of event.

▼M1

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.

▼B

(1) 

The recording equipment shall also record and store in its data memory:

— 
the date and time of the last OVER SPEEDING CONTROL,
— 
the date and time of the first over speeding following this OVER SPEEDING CONTROL,
— 
the number of over speeding events since the last OVER SPEEDING CONTROL.
(2) 

These data may be recorded at power supply reconnection only, times may be known with an accuracy to the minute.

3.12.9    Faults data

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

(118) The recording equipment shall attempt to record and store in its data memory the following data for each fault detected according to the following storage rules:



Fault

Storage rules

Data to be recorded per fault

Card fault

— the 10 most recent driver card faults.

— date and time of beginning of fault,

— date and time of end of fault,

— card(s) type, number, issuing Member State and generation.

Recording equipment faults

— the 10 most recent faults for each type of fault,

— the first fault after the last calibration.

— date and time of beginning of fault,

— date and time of end of fault,

— type of fault,

— card(s) type, number and issuing Member State and generation of any card inserted at beginning and/or end of the fault.

3.12.10    Calibration data

(119) The recording equipment shall record and store in its data memory data relevant to:

— 
known calibration parameters at the moment of activation,
— 
its very first calibration following its activation,
— 
its first calibration in the current vehicle (as identified by its VIN),
— 
the 20 most recent calibrations (if several calibrations happen within one calendar day, only the first and the last one of the day shall be stored).

(120) The following data shall be recorded for each of these calibrations:

— 
purpose of calibration (activation, first installation, installation, periodic inspection),
— 
workshop name and address,
— 
workshop card number, card issuing Member State and card expiry date,
— 
vehicle identification,
— 
parameters updated or confirmed: w, k, l, tyre size, speed limiting device setting, odometer (old and new values), date and time (old and new values),
— 
the types and identifiers of all the seals in place.

(121) In addition, the recording equipment shall record and store in its data memory its ability to use first generation tachograph cards (still activated or not).

(122) The motion sensor shall record and store in its memory the following motion sensor installation data:

— 
first pairing with a VU (date, time, VU approval number, VU serial number),
— 
last pairing with a VU (date, time, VU approval number, VU serial number).

(123) The external GNSS facility shall record and store in its memory the following external GNSS facility installation data:

— 
first coupling with a VU (date, time, VU approval number, VU serial number),
— 
last coupling with a VU (date, time, VU approval number, VU serial number).

3.12.11    Time adjustment data

(124) The recording equipment shall record and store in its data memory data relevant to time adjustments performed in calibration mode outside the frame of a regular calibration (def. f)):

— 
the most recent time adjustment,
— 
the 5 largest time adjustments.

(125) The following data shall be recorded for each of these time adjustments:

— 
date and time, old value,
— 
date and time, new value,
— 
workshop name and address,
— 
workshop card number, card issuing Member State, card generation and card expiry date.

3.12.12    Control activity data

(126) The recording equipment shall record and store in its data memory the following data relevant to the 20 most recent control activities:

— 
date and time of the control,
— 
control card number, card issuing Member State and card generation,
— 
type of the control (displaying and/or printing and/or VU downloading and/or card downloading and/or roadside calibration checking).

(127) In case of downloading, the dates of the oldest and of the most recent days downloaded shall also be recorded.

3.12.13    Company locks data

(128) The recording equipment shall record and store in its data memory the following data relevant to the 255 most recent company locks:

— 
lock-in date and time,
— 
lock-out date and time,
— 
company card number, card issuing Member State and card generation,
— 
company name and address.

Data previously locked by a lock removed from memory due to the limit above, shall be treated as not locked.

3.12.14    Download activity data

(129) The recording equipment shall record and store in its data memory the following data relevant to the last data memory downloading to external media while in company or in calibration mode:

— 
date and time of downloading,
— 
company or workshop card number, card issuing Member State and card generation,
— 
company or workshop name.

3.12.15    Specific conditions data

(130) The recording equipment shall record in its data memory the following data relevant to specific conditions:

— 
date and time of the entry,
— 
type of specific condition.

(131) The data memory shall be able to hold specific conditions data for at least 365 days (with the assumption that on average, 1 condition is opened and closed per day). When storage capacity is exhausted, new data shall replace oldest data.

3.12.16    Tachograph card data

(132) The recording equipment shall be able to store the following data related to the different tachograph cards in which had been used in the VU:

— 
the tachograph card number and its serial number,
— 
the manufacturer of the tachograph card,
— 
the tachograph card type,
— 
the tachograph card version.

(133) The recording equipment shall be able to store at least 88 such records.

3.13    Reading from tachograph cards

(134) The recording equipment shall be able to read from first and second generation tachograph cards, where applicable, the necessary data:

— 
to identify the card type, the card holder, the previously used vehicle, the date and time of the last card withdrawal and the activity selected at that time,
— 
to check that last card session was correctly closed,
— 
to compute the driver's continuous driving time, cumulative break time and cumulated driving times for the previous and the current week,
— 
to print requested printouts related to data recorded on a driver card,
— 
to download a driver card to external media.

This requirement only applies to first generation tachograph cards if their use has not been suppressed by a workshop.

(135) In case of a reading error, the recording equipment shall try again, three times maximum, the same read command, and then if still unsuccessful, declare the card faulty and non-valid.

3.14    Recording and storing on tachograph cards

3.14.1    Recording and storing in first generation tachograph cards

(136) Provided first generation tachograph cards use has not been suppressed by a workshop, the recording equipment shall record and store data exactly in the same way as a first generation recording equipment would do.

(137) The recording equipment shall set the ‘card session data’ in the driver or workshop card right after the card insertion.

(138) The recording equipment shall update data stored on valid driver, workshop, company and/or control cards with all necessary data relevant to the period while the card is inserted and relevant to the card holder. Data stored on these cards are specified in Chapter 4.

(139) The recording equipment shall update driver activity and places data (as specified in 4.5.3.1.9 and 4.5.3.1.11), stored on valid driver and/or workshop cards, with activity and places data manually entered by the cardholder.

(140) All events not defined for the first generation recording equipment, shall not be stored on the driver and workshop cards.

(141) Tachograph cards data update shall be such that, when needed and taking into account card actual storage capacity, most recent data replace oldest data.

(142) In the case of a writing error, the recording equipment shall try again, three times maximum, the same write command and then if still unsuccessful, declare the card faulty and non-valid.

(143) Before releasing a driver card and after all relevant data have been stored on the card, the recording equipment shall reset the ‘card session data’.

3.14.2    Recording and storing in second generation tachograph cards

(144) Second generation tachograph cards shall contain 2 different card applications, the first of which shall be exactly the same as the TACHO application of first generation tachograph cards, and the second the ‘TACHO_G2’ application, as specified in Chapter 4 and Appendix 2.

(145) The recording equipment shall set the ‘card session data’ in the driver or workshop card right after the card insertion.

(146) The recording equipment shall update data stored on the 2 card applications of valid driver, workshop, company and/or control cards with all necessary data relevant to the period while the card is inserted and relevant to the card holder. Data stored on these cards are specified in Chapter 4.

(147) The recording equipment shall update driver activity places and positions data (as specified in 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 and 4.5.3.2.11), stored on valid driver and/or workshop cards, with activity and places data manually entered by the cardholder.

(148) Tachograph cards data update shall be such that, when needed and taking into account card actual storage capacity, most recent data replace oldest data.

(149) In the case of a writing error, the recording equipment shall try again, three times maximum, the same write command and then if still unsuccessful, declare the card faulty and non-valid.

(150) Before releasing a driver card and after all relevant data have been stored on the 2 card applications of the card, the recording equipment shall reset the ‘card session data’.

3.15    Displaying

(151) The display shall include at least 20 characters.

(152) The minimum character size shall be 5 mm high and 3.5 mm wide.

(153) The display shall support the characters specified in Appendix 1 Chapter 4 ‘Character sets’. The display may use simplified glyphs (e.g. accented characters may be displayed without accent, or lower case letters may be shown as upper case letters).

(154) The display shall be provided with adequate non-dazzling lighting.

(155) Indications shall be visible from outside the recording equipment.

(156) The recording equipment shall be able to display:

— 
default data,
— 
data related to warnings,
— 
data related to menu access,
— 
other data requested by a user.

Additional information may be displayed by the recording equipment, provided that it is clearly distinguishable from information required above.

(157) The display of the recording equipment shall use the pictograms or pictograms combinations listed in Appendix 3. Additional pictograms or pictograms combinations may also be provided by the display, if clearly distinguishable from the aforementioned pictograms or pictograms combinations.

(158) The display shall always be ON when the vehicle is moving.

(159) The recording equipment may include a manual or automatic feature to turn the display OFF when the vehicle is not moving.

Displaying format is specified in Appendix 5.

3.15.1    Default display

(160) When no other information needs to be displayed, the recording equipment shall display, by default, the following:

— 
the local time (as a result of UTC time + offset as set by the driver),
— 
the mode of operation,
— 
the current activity of the driver and the current activity of the co-driver,
— 
information related to the driver:
— 
if his current activity is DRIVING, his current continuous driving time and his current cumulative break time,
— 
if his current activity is not DRIVING, the current duration of this activity (since it was selected) and his current cumulative break time.

(161) Display of data related to each driver shall be clear, plain and unambiguous. In the case where the information related to the driver and the co-driver cannot be displayed at the same time, the recording equipment shall display by default the information related to the driver and shall allow the user to display the information related to the co-driver.

(162) In the case where the display width does not allow displaying by default the mode of operation, the recording equipment shall briefly display the new mode of operation when it changes.

(163) The recording equipment shall briefly display the card holder name at card insertion.

(164) When an ‘OUT OF SCOPE’ or FERRY/TRAIN condition is opened, then the default display must show using the relevant pictogram that the particular condition is opened (it is acceptable that the driver's current activity may not be shown at the same time).

3.15.2    Warning display

(165) The recording equipment shall display warning information using primarily the pictograms of Appendix 3, completed where needed by additional numerically coded information. A literal description of the warning may also be added in the driver's preferred language.

3.15.3    Menu access

(166) The recording equipment shall provide necessary commands through an appropriate menu structure.

3.15.4    Other displays

(167) It shall be possible to display selectively on request:

— 
the UTC date and time, and local time offset,
— 
the content of any of the six printouts under the same formats as the printouts themselves,
— 
the continuous driving time and cumulative break time of the driver,
— 
the continuous driving time and cumulative break time of the co-driver,
— 
the cumulated driving time of the driver for the previous and the current week,
— 
the cumulated driving time of the co-driver for the previous and the current week,

optional:

— 
the current duration of co-driver activity (since it was selected),
— 
the cumulated driving time of the driver for current week,
— 
the cumulated driving time of the co-driver for the current daily work period,
— 
the cumulated driving time of the driver for the current daily work period.

(168) Printout content display shall be sequential, line by line. If the display width is less than 24 characters the user shall be provided with the complete information through an appropriate mean (several lines, scrolling, …).

Printout lines devoted to hand-written information may be omitted for display.

3.16    Printing

(169) The recording equipment shall be able to print information from its data memory and/or from tachograph cards in accordance with the seven following printouts:

— 
driver activities from card daily printout,
— 
driver activities from Vehicle Unit daily printout,
— 
events and faults from card printout,
— 
events and faults from Vehicle Unit printout,
— 
technical data printout,
— 
over speeding printout.
— 
tachograph card data history for a given VU (see chapter 3.12.16)

The detailed format and content of these printouts are specified in Appendix 4.

Additional data may be provided at the end of the printouts.

Additional printouts may also be provided by the recording equipment, if clearly distinguishable from the seven aforementioned printouts.

(170) The ‘driver activities from card daily printout’ and ‘Events and faults from card printout’ shall be available only when a driver card or a workshop card is inserted in the recording equipment. The recording equipment shall update data stored on the relevant card before starting printing.

(171) In order to produce the ‘driver activities from card daily printout’ or the ‘events and faults from card printout’, the recording equipment shall:

— 
either automatically select the driver card or the workshop card if one only of these cards is inserted,
— 
or provide a command to select the source card or select the card in the driver slot if two of these cards are inserted in the recording equipment.

(172) The printer shall be able to print 24 characters per line.

(173) The minimum character size shall be 2.1 mm high and 1.5 mm wide.

(174) The printer shall support the characters specified in Appendix 1 Chapter 4 ‘Character sets’.

(175) Printers shall be so designed as to produce these printouts with a degree of definition likely to avoid any ambiguity when they are read.

(176) Printouts shall retain their dimensions and recordings under normal conditions of humidity (10-90 %) and temperature.

(177) The type approved paper used by the recording equipment shall bear the relevant type approval mark and an indication of the type(s) of recording equipment with which it may be used.

(178) Printouts shall remain clearly legible and identifiable under normal conditions of storage, in terms of light intensity, humidity and temperature, for at least two years.

(179) Printouts shall conform at least to the test specifications defined in Appendix 9.

(180) It shall also be possible to add hand-written notes, such as the driver's signature, to these documents.

(181) The recording equipment shall manage ‘paper out’ events while printing by, once paper has been re-loaded, restarting printing from printout beginning or by continuing printing and providing an unambiguous reference to previously printed part.

3.17    Warnings

(182) The recording equipment shall warn the driver when detecting any event and/or fault.

(183) Warning of a power supply interruption event may be delayed until the power supply is reconnected.

(184) The recording equipment shall warn the driver 15 minutes before and at the time of exceeding the maximum allowed continuous driving time.

(185) Warnings shall be visual. Audible warnings may also be provided in addition to visual warnings.

(186) Visual warnings shall be clearly recognisable by the user, shall be situated in the driver's field of vision and shall be clearly legible both by day and by night.

(187) Visual warnings may be built into the recording equipment and/or remote from the recording equipment.

(188) In the latter case it shall bear a ‘T’ symbol.

(189) Warnings shall have a duration of at least 30 seconds, unless acknowledged by the user by hitting one or more specific keys of the recording equipment. This first acknowledgement shall not erase warning cause display referred to in next paragraph.

(190) Warning cause shall be displayed on the recording equipment and remain visible until acknowledged by the user using a specific key or command of the recording equipment.

(191) Additional warnings may be provided, as long as they do not confuse drivers in relation to previously defined ones.

3.18    Data downloading to external media

(192) The recording equipment shall be able to download on request data from its data memory or from a driver card to external storage media via the calibration/downloading connector. The recording equipment shall update data stored on the relevant card before starting downloading.

(193) In addition and as an optional feature, the recording equipment may, in any mode of operation, download data through any another means to a company authenticated through this channel. In such a case, company mode data access rights shall apply to this download.

(194) Downloading shall not alter or delete any stored data.

(195) The calibration/downloading connector electrical interface is specified in Appendix 6.

(196) Downloading protocols are specified in Appendix 7.

3.19    Remote communication for targeted roadside checks

(197) When the ignition is on, the Vehicle Unit shall store every 60 seconds in the remote communication facility the most recent data necessary for the purpose of targeted roadside checks. Such data shall be encrypted and signed as specified in Appendix 11 and Appendix 14.

(198) Data to be checked remotely shall be available to remote communication readers through wireless communication, as specified in Appendix 14.

(199) Data necessary for the purpose of targeted roadside checks shall be related to:

— 
the latest security breach attempt,
— 
the longest power supply interruption,
— 
sensor fault,
— 
motion data error,
— 
vehicle motion conflict,
— 
driving without a valid card,
— 
card insertion while driving,
— 
time adjustment data,
— 
calibration data including the dates of the two latest stored calibration records,
— 
vehicle registration number,
— 
speed recorded by the tachograph.

3.20    Output data to additional external devices

▼M1

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

▼B

(201) The serial link interface as specified in Annex 1B to Regulation (EEC) No. 3821/85, as last amended, can continue to equip tachographs for back compatibility. Anyhow, the driver consent is still required in case personal data are transmitted.

3.21    Calibration

(202) The calibration function shall allow:

— 
to automatically pair the motion sensor with the VU,
— 
to automatically couple the external GNSS facility with the VU if applicable,
— 
to digitally adapt the constant of the recording equipment (k) to the characteristic coefficient of the vehicle (w),
— 
to adjust the current time within the validity period of the inserted workshop card,
— 
to adjust the current odometer value,
— 
to update motion sensor identification data stored in the data memory,
— 
to update, if applicable, external GNSS facility identification data stored in the data memory,
— 
to update the types and identifiers of all the seals in place,
— 
to update or confirm other parameters known to the recording equipment: vehicle identification, w, l, tyre size and speed limiting device setting if applicable.

(203) In addition, the calibration function shall allow to supress the use of first generation tachograph cards in the recording equipment, provided the conditions specified in Appendix 15 are met.

(204) Pairing the motion sensor to the VU shall consist, at least, in:

— 
updating motion sensor installation data held by the motion sensor (as needed),
— 
copying from the motion sensor to the VU data memory the necessary motion sensor identification data.

(205) Coupling the external GNSS facility to the VU shall consist, at least, in:

— 
updating external GNSS facility installation data held by the external GNSS facility (as needed),
— 
copying from the external GNSS facility to the VU data memory the necessary external GNSS facility identification data including the serial number of the external GNSS facility,

The coupling shall be followed by the verification of the GNSS position information.

(206) The calibration function shall be able to input necessary data through the calibration/downloading connector in accordance with the calibration protocol defined in Appendix 8. The calibration function may also input necessary data through other means.

3.22    Roadside calibration checking

(207) The roadside calibration checking function shall allow reading the motion sensor serial number (possibly embedded in the adaptor) and the external GNSS facility serial number (when applicable), connected to the vehicle unit, at the time of the request.

(208) This reading shall at least be possible on the vehicle unit display through commands in the menus.

(209) The roadside calibration checking function shall also allow controlling the selection of the I/O mode of the calibration I/O signal line specified in Appendix 6, via the K-line interface. This shall be done through the ECUAdjustmentSession, as specified in Appendix 8, section 7 Control of Test Pulses — Input output control functional unit.

3.23    Time adjustment

(210) The time adjustment function shall allow for automatically adjusting the current time. Two time sources are used in the recording equipment for time adjustment: 1) the internal VU clock, 2) the GNSS receiver.

▼M1

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

▼B

(212) The time adjustment function shall also allow for triggered adjustment of the current time, in calibration mode.

3.24    Performance characteristics

(213) The Vehicle Unit shall be fully operational in the temperature range – 20 °C to 70 °C, the external GNSS facility in the temperature range – 20 °C to 70 °C, and the motion sensor in the temperature range – 40 °C to 135 °C. Data memory content shall be preserved at temperatures down to – 40 °C.

(214) The tachograph shall be fully operational in the humidity range 10 % to 90 %.

(215) The seals used in the smart tachograph shall withstand the same conditions than those applicable to the tachograph components to which they are affixed.

(216) The recording equipment shall be protected against over-voltage, inversion of its power supply polarity, and short circuits.

(217) Motion sensors shall either:

— 
react to a magnetic field disturbing vehicle motion detection. In such circumstances, the vehicle unit will record and store a sensor fault (requirement 88) or,
— 
have a sensing element that is protected from, or immune to, magnetic fields.

(218) The recording equipment and the external GNSS facility shall conform to international regulation UN ECE R10 and shall be protected against electrostatic discharges and transients.

3.25    Materials

(219) All the constituent parts of the recording equipment shall be made of materials of sufficient stability and mechanical strength and with stable electrical and magnetic characteristics.

(220) For normal conditions of use, all the internal parts of the equipment shall be protected against damp and dust.

(221) The Vehicle Unit and the external GNSS facility shall meet the protection grade IP 40 and the motion sensor shall meet the protection grade IP 64, as per standard IEC 60529:1989 including A1:1999 and A2:2013.

(222) The recording equipment shall conform to applicable technical specifications related to ergonomic design.

(223) The recording equipment shall be protected against accidental damage.

3.26    Markings

(224) If the recording equipment displays the vehicle odometer value and speed, the following details shall appear on its display:

— 
near the figure indicating the distance, the unit of measurement of distance, indicated by the abbreviation ‘km’,
— 
near the figure showing the speed, the entry ‘km/h’.

The recording equipment may also be switched to display the speed in miles per hour, in which case the unit of measurement of speed shall be shown by the abbreviation ‘mph’. The recording equipment may also be switched to display the distance in miles, in which case the unit of measurement of distance shall be shown by the abbreviation ‘mi’.

▼M1

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

▼B

4.   CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR TACHOGRAPH CARDS

4.1    Visible data

The front page shall contain:

(227) the words ‘Driver card’ or ‘Control card’ or ‘Workshop card’ or ‘Company card’ printed in capital letters in the official language or languages of the Member State issuing the card, according to the type of the card.

(228) the name of the Member State issuing the card (optional);

(229) the distinguishing sign of the Member State issuing the card, printed in negative in a blue rectangle and encircled by 12 yellow stars. The distinguishing signs shall be as follows:



B

BG

CZ

CY

Belgium

Bulgaria

Czech Republic

Cyprus

LV

L

LT

M

Latvia

Luxembourg

Lithuania

Malta

DK

Denmark

NL

The Netherlands

D

EST

Germany

Estonia

A

PL

Austria

Poland

GR

Greece

P

RO

SK

SLO

Portugal

Romania

Slovakia

Slovenia

E

Spain

FIN

Finland

F

HR

H

France

Croatia

Hungary

S

Sweden

IRL

Ireland

UK

The United Kingdom

I

Italy

 

 

(230) information specific to the card issued, numbered as follows:



 

Driver card

Control Card

Company or Workshop card

1.

surname of the driver

control body name

company or workshop name

2.

first name(s) of the driver

surname of the controller

(if applicable)

surname of card holder

(if applicable)

3.

birth date of the driver

first name(s) of the controller

(if applicable)

first name(s) of card holder

(if applicable)

4.a

card start of validity date

4.b

card expiry date

4.c

the name of the issuing authority (may be printed on reverse page)

4.d

a different number from the one under heading 5, for administrative purposes (optional)

5. a

Driving licence number

(at the date of issue of the driver card)

5. b

Card number

6.

Photograph of the driver

photograph of the controller (optional)

photograph of the fitter (optional)-

7.

Signature of the holder (optional)

8.

Normal place of residence, or postal address of the holder (optional).

Postal address of control body

postal address of company or workshop

(231) dates shall be written using a ‘dd/mm/yyyy’ or ‘dd.mm.yyyy’ format (day, month, year).

The reverse page shall contain:

(232) an explanation of the numbered items which appear on the front page of the card;

(233) with the specific written agreement of the holder, information which is not related to the administration of the card may also be added, such addition will not alter in any way the use of the model as a tachograph card.

(234) Tachograph cards shall be printed with the following background predominant colours:

driver card : white,

control card : blue,

workshop card : red,

company card : yellow.

(235) Tachograph cards shall bear at least the following features for protection of the card body against counterfeiting and tampering:

— 
a security design background with fine guilloche patterns and rainbow printing,
— 
in the area of the photograph, the security design background and the photograph shall overlap,
— 
at least one two-coloured microprint line.

image ►(1) M1  

(236) After consulting the Commission, Member States may add colours or markings, such as national symbols and security features, without prejudice to the other provisions of this Annex.

(237) Temporary cards referred to in Article 26.4 of Regulation (EU) No. 165/2014 shall comply with the provisions of this Annex.

4.2    Security

The system security aims at protecting integrity and authenticity of data exchanged between the cards and the recording equipment, protecting the integrity and authenticity of data downloaded from the cards, allowing certain write operations onto the cards to recording equipment only, decrypting certain data, ruling out any possibility of falsification of data stored in the cards, preventing tampering and detecting any attempt of that kind.

(238) In order to achieve the system security, the tachograph cards shall meet the security requirements defined in Appendixes 10 and 11.

(239) Tachograph cards shall be readable by other equipment such as personal computers.

4.3    Standards

(240) Tachograph cards shall comply with the following standards:

— 
ISO/IEC 7810 Identification cards — Physical characteristics,
— 
ISO/IEC 7816 Identification cards — Integrated circuit cards:
— 
Part 1: Physical characteristics,
— 
Part 2: Dimensions and position of the contacts (ISO/IEC 7816-2:2007),
— 
Part 3: Electrical interface and transmission protocols (ISO/IEC 7816-3:2006),
— 
Part 4: Organisation, security and commands for interchange (ISO/IEC 7816-4:2013 + Cor 1:2014),
— 
Part 6: Interindustry data elements for interchange (ISO/IEC 7816-6:2004 + Cor 1:2006),
— 
Part 8: Commands for security operations (ISO/IEC 7816-8:2004).
— 
Tachograph cards shall be tested in accordance to ISO/IEC 10373-3:2010 Identification cards — Test methods — Part 3: Integrated circuit cards with contacts and related interface devices.

4.4    Environmental and electrical specifications

(241) Tachograph cards shall be capable of operating correctly in all the climatic conditions normally encountered in Community territory and at least in the temperature range – 25 °C to + 70 °C with occasional peaks of up to + 85 °C, ‘occasional’ meaning not more than 4 hours each time and not over 100 times during the life time of the card.

(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 that may be stored on tachograph cards, related to other applications possibly borne by the card, shall be stored in accordance with Directive 95/46/EC and with Directive 2002/58/EC and in compliance with Article 7 of Regulation (EU) No. 165/2014.

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

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:

▼M1

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

▼B

— 
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 unit)

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.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 six most recent events of each type (i.e. 66 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:

▼M1

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

▼B

— 
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 twelve most recent faults of each type (i.e. 24 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 at least 28 days (the average activity of a driver is defined as 93 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 at least 84 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 at least 84 pairs of 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 at least 56 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 at least 84 such records.

▼M1

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.

▼B

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

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.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 at least 88 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 at least 1 day of average driver activity.

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 at least 4 such records.

4.5.4.2.10   Daily work periods start and/or end data

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

(348) The workshop card shall be able to hold at least 3 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 at least 4 such records.

▼M1

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.

▼B

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 at least 2 such records.

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

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

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 by points 3.12.3, 3.12.9 and 3.12.12 to 3.12.15 inclusive.

(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 number (VRN), 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 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.) ( 16 ). 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 to the doorframe on the driver's side 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.

▼M1

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

▼B

(397) For M1 and N1 vehicles only, and which are fitted with an adaptor in conformity with Commission Regulation (EC) No 68/2009 ( 17 ) 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.

▼M1

(398a) The seals mentioned above shall be certified according to the standard EN 16882:2016.

▼B

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

▼M1

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.

▼B

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

▼M1

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

▼B

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

▼M1

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.

▼B

6.3    Installation inspection

▼M1

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

▼B

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

(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

▼M1

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

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

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

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

▼B

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

▼M1

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

▼B

(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 upgrade in-situ recording equipment software shall be approved by the authority which granted type approval for the recording equipment. Software upgrade must not alter nor delete any driver activity data stored in the recording equipment. Software may be upgraded only under the responsibility of the equipment manufacturer.

(430) Type approval of software modifications aimed to upgrade a previously type approved recording equipment may not be refused if such modifications only apply to functions not specified in this Annex. Software upgrade 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 been granted a security certificate and a functional certificate, 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 delivered by the laboratory to the manufacturer only after all required interoperability tests have been successfully passed.

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

(458) If at the end of this period, interoperability problems still remain, the laboratory in charge of interoperability tests, with the collaboration of the manufacturers concerned and with the type approval authorities who delivered the corresponding functional certificates shall find out the causes of the interoperability faults and establish which modifications should be made by each of the manufacturers concerned. The search for technical solutions shall last for a maximum of two months, after which, if no common solution is found, the Commission, after having consulted the laboratory in charge of interoperability tests, shall decide which equipment(s) and cards get a definitive interoperability certificate and state the reasons why.

(459) Any request for interoperability tests, registered by the laboratory between the end of the four month period after the first provisional interoperability certificate has been delivered and the date of the decision by the Commission referred to in requirement 455, shall be postponed until the initial interoperability problems have been solved. Those requests are then processed in the chronological order of their registration.




Appendix 1

DATA DICTIONARY

TABLE OF CONTENT

1.

INTRODUCTION

1.1.

Approach for definitions of data types

1.2.

References

2.

DATA TYPE DEFINITIONS

2.1.

ActivityChangeInfo

2.2.

Address

2.3.

AESKey

2.4.

AES128Key

2.5.

AES192Key

2.6.

AES256Key

2.7.

BCDString

2.8.

CalibrationPurpose

2.9.

CardActivityDailyRecord

2.10.

CardActivityLengthRange

2.11.

CardApprovalNumber

2.12.

CardCertificate

2.13.

CardChipIdentification

2.14.

CardConsecutiveIndex

2.15.

CardControlActivityDataRecord

2.16.

CardCurrentUse

2.17.

CardDriverActivity

2.18.

CardDrivingLicenceInformation

2.19.

CardEventData

2.20.

CardEventRecord

2.21.

CardFaultData

2.22.

CardFaultRecord

2.23.

CardIccIdentification

2.24.

CardIdentification

2.25.

CardMACertificate

2.26.

CardNumber

2.27.

CardPlaceDailyWorkPeriod

2.28.

CardPrivateKey

2.29.

CardPublicKey

2.30.

CardRenewalIndex

2.31.

CardReplacementIndex

2.32.

CardSignCertificate

2.33.

CardSlotNumber

2.34.

CardSlotsStatus

2.35.

CardSlotsStatusRecordArray

2.36.

CardStructureVersion

2.37.

CardVehicleRecord

2.38.

CardVehiclesUsed

2.39.

CardVehicleUnitRecord

2.40.

CardVehicleUnitsUsed

2.41.

Certificate

2.42.

CertificateContent

2.43.

CertificateHolderAuthorisation

2.44.

CertificateRequestID

2.45.

CertificationAuthorityKID

2.46.

CompanyActivityData

2.47.

CompanyActivityType

2.48.

CompanyCardApplicationIdentification

2.49.

CompanyCardHolderIdentification

2.50.

ControlCardApplicationIdentification

2.51.

ControlCardControlActivityData

2.52.

ControlCardHolderIdentification

2.53.

ControlType

2.54.

CurrentDateTime

2.55.

CurrentDateTimeRecordArray

2.56.

DailyPresenceCounter

2.57.

Datef

2.58.

DateOfDayDownloaded

2.59.

DateOfDayDownloadedRecordArray

2.60.

Distance

2.61.

DriverCardApplicationIdentification

2.62.

DriverCardHolderIdentification

▼M1

2.63.

Reserved for future use

▼B

2.64.

EGFCertificate

2.65.

EmbedderIcAssemblerId

2.66.

EntryTypeDailyWorkPeriod

2.67.

EquipmentType

2.68.

EuropeanPublicKey

2.69.

EventFaultRecordPurpose

2.70.

EventFaultType

2.71.

ExtendedSealIdentifier

2.72.

ExtendedSerialNumber

2.73.

FullCardNumber

2.74.

FullCardNumberAndGeneration

2.75.

Generation

2.76.

GeoCoordinates

2.77.

GNSSAccuracy

▼M1

2.78.

GNSSAccumulatedDriving

2.79.

GNSSAccumulatedDrivingRecord

▼B

2.80.

GNSSPlaceRecord

2.81.

HighResOdometer

2.82.

HighResTripDistance

2.83.

HolderName

2.84.

InternalGNSSReceiver

2.85.

K-ConstantOfRecordingEquipment

2.86.

KeyIdentifier

2.87.

KMWCKey

2.88.

Language

2.89.

LastCardDownload

2.90.

LinkCertificate

2.91.

L-TyreCircumference

2.92.

MAC

2.93.

ManualInputFlag

2.94.

ManufacturerCode

2.95.

ManufacturerSpecificEventFaultData

2.96.

MemberStateCertificate

2.97.

MemberStateCertificateRecordArray

2.98.

MemberStatePublicKey

2.99.

Name

2.100.

NationAlpha

2.101.

NationNumeric

2.102.

NoOfCalibrationRecords

2.103.

NoOfCalibrationsSinceDownload

2.104.

NoOfCardPlaceRecords

2.105.

NoOfCardVehicleRecords

2.106.

NoOfCardVehicleUnitRecords

2.107.

NoOfCompanyActivityRecords

2.108.

NoOfControlActivityRecords

2.109.

NoOfEventsPerType

2.110.

NoOfFaultsPerType

▼M1

2.111.

NoOfGNSSADRecords

▼B

2.112.

NoOfSpecificConditionRecords

2.113.

OdometerShort

2.114.

OdometerValueMidnight

2.115.

OdometerValueMidnightRecordArray

2.116.

OverspeedNumber

2.117.

PlaceRecord

2.118.

PreviousVehicleInfo

2.119.

PublicKey

2.120.

RecordType

2.121.

RegionAlpha

2.122.

RegionNumeric

2.123.

RemoteCommunicationModuleSerialNumber

2.124.

RSAKeyModulus

2.125.

RSAKeyPrivateExponent

2.126.

RSAKeyPublicExponent

2.127.

RtmData

2.128.

SealDataCard

2.129.

SealDataVu

2.130.

SealRecord

2.131.

SensorApprovalNumber

2.132.

SensorExternalGNSSApprovalNumber

2.133.

SensorExternalGNSSCoupledRecord

2.134.

SensorExternalGNSSIdentification

2.135.

SensorExternalGNSSInstallation

2.136.

SensorExternalGNSSOSIdentifier

2.137.

SensorExternalGNSSSCIdentifier

2.138.

SensorGNSSCouplingDate

2.139.

SensorGNSSSerialNumber

2.140.

SensorIdentification

2.141.

SensorInstallation

2.142.

SensorInstallationSecData

2.143.

SensorOSIdentifier

2.144.

SensorPaired

2.145.

SensorPairedRecord

2.146.

SensorPairingDate

2.147.

SensorSCIdentifier

2.148.

SensorSerialNumber

2.149.

Signature

2.150.

SignatureRecordArray

2.151.

SimilarEventsNumber

2.152.

SpecificConditionRecord

2.153.

SpecificConditions

2.154.

SpecificConditionType

2.155.

Speed

2.156.

SpeedAuthorised

2.157.

SpeedAverage

2.158.

SpeedMax

2.159.

TachographPayload

▼M1

2.160.

Reserved for future use

▼B

2.161.

TDesSessionKey

2.162.

TimeReal

2.163.

TyreSize

2.164.

VehicleIdentificationNumber

2.165.

VehicleIdentificationNumberRecordArray

2.166.

VehicleRegistrationIdentification

2.167.

VehicleRegistrationNumber

2.168.

VehicleRegistrationNumberRecordArray

2.169.

VuAbility

2.170.

VuActivityDailyData

2.171.

VuActivityDailyRecordArray

2.172.

VuApprovalNumber

2.173.

VuCalibrationData

2.174.

VuCalibrationRecord

2.175.

VuCalibrationRecordArray

2.176.

VuCardIWData

2.177.

VuCardIWRecord

2.178.

VuCardIWRecordArray

2.179.

VuCardRecord

2.180.

VuCardRecordArray

2.181.

VuCertificate

2.182.

VuCertificateRecordArray

2.183.

VuCompanyLocksData

2.184.

VuCompanyLocksRecord

2.185.

VuCompanyLocksRecordArray

2.186.

VuControlActivityData

2.187.

VuControlActivityRecord

2.188.

VuControlActivityRecordArray

2.189.

VuDataBlockCounter

2.190.

VuDetailedSpeedBlock

2.191.

VuDetailedSpeedBlockRecordArray

2.192.

VuDetailedSpeedData

2.193.

VuDownloadablePeriod

2.194.

VuDownloadablePeriodRecordArray

2.195.

VuDownloadActivityData

2.196.

VuDownloadActivityDataRecordArray

2.197.

VuEventData

2.198.

VuEventRecord

2.199.

VuEventRecordArray

2.200.

VuFaultData

2.201.

VuFaultRecord

2.202.

VuFaultRecordArray

▼M1

2.203.

VuGNSSADRecord

2.204.

VuGNSSADRecordArray

▼B

2.205.

VuIdentification

2.206.

VuIdentificationRecordArray

2.207.

VuITSConsentRecord

2.208.

VuITSConsentRecordArray

2.209.

VuManufacturerAddress

2.210.

VuManufacturerName

2.211.

VuManufacturingDate

2.212.

VuOverSpeedingControlData

2.213.

VuOverSpeedingControlDataRecordArray

2.214.

VuOverSpeedingEventData

2.215.

VuOverSpeedingEventRecord

2.216.

VuOverSpeedingEventRecordArray

2.217.

VuPartNumber

2.218.

VuPlaceDailyWorkPeriodData

2.219.

VuPlaceDailyWorkPeriodRecord

2.220.

VuPlaceDailyWorkPeriodRecordArray

2.221.

VuPrivateKey

2.222.

VuPublicKey

2.223.

VuSerialNumber

2.224.

VuSoftInstallationDate

2.225.

VuSoftwareIdentification

2.226.

VuSoftwareVersion

2.227.

VuSpecificConditionData

2.228.

VuSpecificConditionRecordArray

2.229.

VuTimeAdjustmentData

▼M1

2.230.

Reserved for future use

2.231.

Reserved for future use

▼B

2.232.

VuTimeAdjustmentRecord

2.233.

VuTimeAdjustmentRecordArray

2.234.

WorkshopCardApplicationIdentification

2.235.

WorkshopCardCalibrationData

2.236.

WorkshopCardCalibrationRecord

2.237.

WorkshopCardHolderIdentification

2.238.

WorkshopCardPIN

2.239.

W-VehicleCharacteristicConstant

2.240.

VuPowerSupplyInterruptionRecord

2.241.

VuPowerSupplyInterruptionRecordArray

2.242.

VuSensorExternalGNSSCoupledRecordArray

2.243.

VuSensorPairedRecordArray

3.

VALUE AND SIZE RANGE DEFINITIONS

4.

CHARACTER SETS

5.

ENCODING

6.

OBJECT IDENTIFIERS UND APPLICATION IDENTIFIERS

6.1.

Object Identifiers

6.2.

Application Identifiers

1.   INTRODUCTION

This appendix specifies data formats, data elements, and data structures for use within the recording equipment and tachograph cards.

1.1.    Approach for definitions of data types

This appendix uses Abstract Syntax Notation One (ASN.1) to define data types. This enables simple and structured data to be defined without implying any specific transfer syntax (encoding rules) which will be application and environment dependent.

ASN.1 type naming conventions are done in accordance with ISO/IEC 8824-1. This implies that:

— 
where possible, the meaning of the data type is implied through the names being selected,
— 
where a data type is a composition of other data types, the data type name is still a single sequence of alphabetical characters commencing with a capital letter, however capitals are used within the name to impart the corresponding meaning,
— 
in general, the data types names are related to the name of the data types from which they are constructed, the equipment in which data is stored and the function related to the data.

If an ASN.1 type is already defined as part of another standard and if it is relevant for usage in the recording equipment, then this ASN.1 type will be defined in this appendix.

To enable several types of encoding rules, some ASN.1 types in this appendix are constrained by value range identifiers. The value range identifiers are defined in paragraph 3 and Appendix 2.

1.2.    References

The following references are used in this Appendix:

ISO 639

Code for the representation of names of languages. First Edition: 1988.

ISO 3166

Codes for the representation of names of countries and their subdivisions — Part 1: Country codes, 2013

ISO 3779

Road vehicles — Vehicle identification number (VIN) — Content and structure. 2009

ISO/IEC 7816-5

Identification cards — Integrated circuit cards — Part 5: Registration of application providers.

Second edition: 2004.

ISO/IEC 7816-6

Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for interchange, 2004 + Technical Corrigendum 1: 2006

ISO/IEC 8824-1

Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation. 2008 + Technical Corrigendum 1: 2012 and Technical Corrigendum 2: 2014.

ISO/IEC 8825-2

Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). 2008.

ISO/IEC 8859-1

Information technology — 8 bit single-byte coded graphic character sets — Part 1: Latin alphabet No.1. First edition: 1998.

ISO/IEC 8859-7

Information technology — 8 bit single-byte coded graphic character sets — Part 7: Latin/Greek alphabet. 2003.

ISO 16844-3

Road vehicles — Tachograph systems — Motion Sensor Interface. 2004 + Technical Corrigendum 1: 2006..

TR-03110-3

BSI / ANSSI Technical Guideline TR-03110-3, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token — Part 3 Common Specifications, version 2.20, 3. February 2015

2.   DATA TYPE DEFINITIONS

For any of the following data types, the default value for an ‘unknown’ or a ‘not applicable’ content will consist in filling the data element with ‘FF’ bytes.

All data types are used for Generation 1 and Generation 2 applications unless otherwise specified.

▼M1

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.

▼B

2.1.    ActivityChangeInfo

This data type enables to code, within a two bytes word, a slot status at 00:00 and/or a driver status at 00:00 and/or changes of activity and/or changes of driving status and/or changes of card status for a driver or a co-driver. This data type is related to Annex 1C requirements 105, 266, 291, 320, 321, 343, and 344.

image

Value assignment — Octet Aligned: ‘scpaattttttttttt’B (16 bits)

For Data Memory recordings (or slot status):

‘s’B

Slot:

‘0’B: DRIVER,
‘1’B: CO-DRIVER,

‘c’B

Driving status:

‘0’B: SINGLE,
‘1’B: CREW,

‘p’B

Driver (or workshop) card status in the relevant slot:

‘0’B: INSERTED, a card is inserted,
‘1’B: NOT INSERTED, no card is inserted (or a card is withdrawn),

‘aa’B

Activity:

‘00’B: BREAK/REST,
‘01’B: AVAILABILITY,
‘10’B: WORK,
‘11’B: DRIVING,

‘ttttttttttt’B

Time of the change: Number of minutes since 00h00 on the given day.

For Driver (or Workshop) card recordings (and driver status):

‘s’B

Slot (not relevant when ‘p’=1 except note below):

‘0’B: DRIVER,
‘1’B: CO-DRIVER,

‘c’B

Driving status (case ‘p’=0) or

Following activity status (case ‘p’=1):

‘0’B: SINGLE,
‘0’B: UNKNOWN
‘1’B: CREW,
‘1’B: KNOWN (=manually entered)

‘p’B

Card status:

‘0’B: INSERTED, the card is inserted in a recording equipment,
‘1’B: NOT INSERTED, the card is not inserted (or the card is withdrawn),

‘aa’B

Activity (not relevant when ‘p’=1 and ‘c’=0 except note below):

‘00’B: BREAK/REST,
‘01’B: AVAILABILITY,
‘10’B: WORK,
‘11’B: DRIVING,

‘ttttttttttt’B

Time of the change: Number of minutes since 00h00 on the given day.

Note for the case ‘card withdrawal’:

When the card is withdrawn:

— 
‘s’ is relevant and indicates the slot from which the card is withdrawn,
— 
‘c’ must be set to 0,
— 
‘p’ must be set to 1,
— 
‘aa’ must code the current activity selected at that time,

As a result of a manual entry, the bits ‘c’ and ‘aa’ of the word (stored in a card) may be overwritten later to reflect the entry.

2.2.    Address

An address.

image

codePage specifies a character set defined in Chapter 4,

address is an address encoded using the specified character set.

2.3.    AESKey

Generation 2:

An AES key with a length of 128, 192 or 256 bits.

image

Value assignment: not further specified.

2.4.    AES128Key

Generation 2:

An AES128 key.

image

length denotes the length of the AES128 key in octets.

aes128Key is an AES key with a length of 128 bits.

Value assignment:

The length shall have the value 16.

2.5.    AES192Key

Generation 2:

An AES192 key.

image

length denotes the length of the AES192 key in octets.

aes192Key is an AES key with a length of 192 bits.

Value assignment:

The length shall have the value 24.

2.6.    AES256Key

Generation 2:

An AES256 key.

image

length denotes the length of the AES256 key in octets.

aes256Key is an AES key with a length of 256 bits.

Value assignment:

The length shall have the value 32.

2.7.    BCDString

BCDString is applied for Binary Code Decimal (BCD) representation. This data type is used to represent one decimal digit in one semi octet (4 bits). BCDString is based on the ISO/IEC 8824-1 ‘CharacterStringType’.

image

BCDString uses an ‘hstring’ notation. The leftmost hexadecimal digit shall be the most significant semi octet of the first octet. To produce a multiple of octets, zero trailing semi octets shall be inserted, as needed, from the leftmost semi octet position in the first octet.

Permitted digits are: 0, 1, .. 9.

2.8.    CalibrationPurpose

Code explaining why a set of calibration parameters was recorded. This data type is related to Annex 1B requirements 097 and 098 and Annex 1C requirements 119.

image

Value assignment:

Generation 1:

‘00’H

reserved value,

‘01’H

activation: recording of calibration parameters known, at the moment of the VU activation,

‘02’H

first installation: first calibration of the VU after its activation,

‘03’H

installation: first calibration of the VU in the current vehicle,

‘04’H

periodic inspection.

Generation 2:
In addition to generation 1 the following values are used:

‘05’H

entry of VRN by company,

‘06’H

time adjustment without calibration,

‘07’H to ‘7F’H

RFU,

‘80’H to ‘FF’H

Manufacturer specific.

2.9.    CardActivityDailyRecord

Information, stored in a card, related to the driver activities for a particular calendar day. This data type is related to Annex 1C requirements 266, 291, 320 and 343.

image

activityPreviousRecordLength is the total length in bytes of the previous daily record. The maximum value is given by the length of the OCTET STRING containing these records (see CardActivityLengthRange Appendix 2 paragraph 4). When this record is the oldest daily record, the value of activityPreviousRecordLength must be set to 0.

activityRecordLength is the total length in bytes of this record. The maximum value is given by the length of the OCTET STRING containing these records.

activityRecordDate is the date of the record.

activityDailyPresenceCounter is the daily presence counter for the card this day.

activityDayDistance is the total distance travelled this day.

activityChangeInfo is the set of ActivityChangeInfo data for the driver this day. It may contain at maximum 1440 values (one activity change per minute). This set always includes the activityChangeInfo coding the driver status at 00:00.

2.10.    CardActivityLengthRange

Number of bytes in a driver or a workshop card, available to store driver activity records.

image

Value assignment: see Appendix 2.

2.11.    CardApprovalNumber

Type approval number of the card.

image

Value assignment:

The approval number shall be provided as published on the corresponding European Commission web site, i.e. for example including hyphens if any. The approval number shall be left-aligned.

2.12.    CardCertificate

Generation 1:

Certificate of the public key of a card.

image

2.13.    CardChipIdentification

Information, stored in a card, related to the identification of the card's Integrated Circuit (IC) (Annex 1C requirement 249). The icSerialNumber together with the icManufacturingReferences identifies the card chip uniquely. The icSerialNumber alone does not uniquely identify the card chip.

image

icSerialNumber is the IC serial number.

icManufacturingReferences is the IC manufacturer specific identifier.

2.14.    CardConsecutiveIndex

A card consecutive index (definition h)).

image

Value assignment: (see Annex 1C chapter 7)

Order for increase: ‘0, …, 9, A, …, Z, a, …, z’

2.15.    CardControlActivityDataRecord

Information, stored in a driver or workshop card, related to the last control the driver has been subject to (Annex 1C requirements 274, 299, 327, and 350).

image

controlType is the type of the control.

controlTime is the date and time of the control.

controlCardNumber is the FullCardNumber of the control officer having performed the control.

controlVehicleRegistration is the VRN and registering Member State of the vehicle in which the control happened.

controlDownloadPeriodBegin and controlDownloadPeriodEnd is the period downloaded, in case of downloading.

2.16.    CardCurrentUse

Information about the actual usage of the card (Annex 1C requirement 273, 298, 326, and 349).

image

sessionOpenTime is the time when the card is inserted for the current usage. This element is set to zero at card removal.

sessionOpenVehicle is the identification of the currently used vehicle, set at card insertion. This element is set to zero at card removal.

2.17.    CardDriverActivity

Information, stored in a driver or a workshop card, related to the activities of the driver (Annex 1C requirements 267, 268, 292, 293, 321 and 344).

image

activityPointerOldestDayRecord is the specification of the begin of the storage place (number of bytes from the beginning of the string) of the oldest complete day record in the activityDailyRecords string. The maximum value is given by the length of the string.

activityPointerNewestRecord is the specification of the begin of the storage place (number of bytes from the beginning of the string) of the most recent day record in the activityDailyRecords string. The maximum value is given by the length of the string.

activityDailyRecords is the space available to store the driver activity data (data structure: CardActivityDailyRecord) for each calendar day where the card has been used.

Value assignment: this octet string is cyclically filled with records of CardActivityDailyRecord. At the first use storing is started at the first byte of the string. All new records are appended at the end of the previous one. When the string is full, storing continues at the first byte of the string independently of a break being inside a data element. Before placing new activity data in the string (enlarging current activityDailyRecord, or placing a new activityDailyRecord) that replaces older activity data, activityPointerOldestDayRecord must be updated to reflect the new location of the oldest complete day record, and activityPreviousRecordLength of this (new) oldest complete day record must be reset to 0.

2.18.    CardDrivingLicenceInformation

Information, stored in a driver card, related to the card holder driver licence data (Annex 1C requirement 259 and 284).

image

drivingLicenceIssuingAuthority is the authority responsible for issuing the driving licence.

drivingLicenceIssuingNation is the nationality of the authority that issued the driving licence.

drivingLicenceNumber is the number of the driving licence.

▼M1

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

image

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

image

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

▼B

2.20.    CardEventRecord

Information, stored in a driver or a workshop card, related to an event associated to the card holder (Annex 1C requirements 261, 286, 318 and 341).

image

eventType is the type of the event.

eventBeginTime is the date and time of beginning of event.

eventEndTime is the date and time of end of event.

eventVehicleRegistration is the VRN and registering Member State of vehicle in which the event happened.

2.21.    CardFaultData

Information, stored in a driver or a workshop card, related to the faults associated to the card holder (Annex 1C requirements 263, 288, 318, and 341).

image

CardFaultData is a sequence of Recording Equipment faults set of records followed by card faults set of records.

cardFaultRecords is a set of fault records of a given fault category (Recording Equipment or card).

2.22.    CardFaultRecord

Information, stored in a driver or a workshop card, related to a fault associated to the card holder (Annex 1C requirement 264, 289, 318, and 341).

image

faultType is the type of the fault.

faultBeginTime is the date and time of beginning of fault.

faultEndTime is the date and time of end of fault.

faultVehicleRegistration is the VRN and registering Member State of vehicle in which the fault happened.

2.23.    CardIccIdentification

Information, stored in a card, related to the identification of the integrated circuit (IC) card (Annex 1C requirement 248).

image

clockStop is the Clockstop mode as defined in appendix 2.

cardExtendedSerialNumber is the IC card unique serial number as further specified by the ExtendedSerialNumber data type.

cardApprovalNumber is the type approval number of the card.

cardPersonaliserID is the card personaliser ID encoded as ManufacturerCode.

embedderIcAssemblerId provides information about the embedder/IC assembler.

icIdentifier is the Identifier of the IC on the card and its IC manufacturer as defined in ISO/IEC 7816-6.

2.24.    CardIdentification

Information, stored in a card, related to the identification of the card (Annex 1C requirements 255, 280, 310, 333, 359, 365, 371, and 377).

image

cardIssuingMemberState is the code of the Member State issuing the card.

cardNumber is the card number of the card.

cardIssuingAuthorityName is the name of the authority having issued the Card.

cardIssueDate is the issue date of the Card to the current holder.

cardValidityBegin is the first date of validity of the card.

cardExpiryDate is the date when the validity of the card ends.

2.25.    CardMACertificate

Generation 2:

Certificate of the card public key for mutual authentication with a VU. The structure of this certificate is specified in Appendix 11.

image

2.26.    CardNumber

A card number as defined by definition g).

image

driverIdentification is the unique identification of a driver in a Member State.

ownerIdentification is the unique identification of a company or a workshop or a control body within a member state.

cardConsecutiveIndex is the card consecutive index.

cardReplacementIndex is the card replacement index.

cardRenewalIndex is the card renewal index.

The first sequence of the choice is suitable to code a driver card number, the second sequence of the choice is suitable to code workshop, control, and company card numbers.

2.27.    CardPlaceDailyWorkPeriod

Information, stored in a driver or a workshop card, related to the places where daily work periods begin and/or end (Annex 1C requirements 272, 297, 325, and 348).

image

placePointerNewestRecord is the index of the last updated place record.

Value assignment: Number corresponding to the numerator of the place record, beginning with ‘0’ for the first occurrence of the place records in the structure.

placeRecords is the set of records containing the information related to the places entered.

2.28.    CardPrivateKey

Generation 1:

The private key of a card.

image

2.29.    CardPublicKey

The public key of a card.

image

▼M1

2.30.    CardRenewalIndex

A card renewal index (definition i)).

image

Value assignment: (see this Annex chapter 7).

‘0’

First issue.

Order for increase: ‘0, …, 9, A, …, Z’

▼B

2.31.    CardReplacementIndex

A card replacement index (definition j)).

image

Value assignment: (see this Annex chapter VII).

‘0’

Original card.

Order for increase: ‘0, …, 9, A, …, Z’

2.32.    CardSignCertificate

Generation 2:

Certificate of the card public key for signature. The structure of this certificate is specified in Appendix 11.

image

2.33.    CardSlotNumber

Code to distinguish between the two slots of a Vehicle Unit.

image

Value assignment: not further specified.

2.34.    CardSlotsStatus

Code indicating the type of cards inserted in the two slots of the vehicle unit.

image

Value assignment — Octet Aligned: ‘ccccdddd’B

‘cccc’B

Identification of the type of card inserted in the co-driver slot,

‘dddd’B

Identification of the type of card inserted in the driver slot,

with the following identification codes:

‘0000’B

no card is inserted,

‘0001’B

a driver card is inserted,

‘0010’B

a workshop card is inserted,

‘0011’B

a control card is inserted,

‘0100’B

a company card is inserted.

2.35.    CardSlotsStatusRecordArray

Generation 2:

The CardSlotsStatus plus metadata as used in the download protocol.

image

recordType denotes the type of the record (CardSlotsStatus). Value Assignment: See RecordType

recordSize is the size of the CardSlotsStatus in bytes.

noOfRecords is the number of records in the set records.

records is the set of CardSlotsStatus records.

2.36.    CardStructureVersion

Code indicating the version of the implemented structure in a tachograph card.

image

Value assignment: ‘aabb’H:

‘aa’H

Index for changes of the structure.

‘00’H for Generation 1 applications
‘01’H for Generation 2 applications

‘bb’H

Index for changes concerning the use of the data elements defined for the structure given by the high byte.

‘00’H for this version of Generation 1 applications
‘00’H for this version of Generation 2 applications

2.37.    CardVehicleRecord

Information, stored in a driver or workshop card, related to a period of use of a vehicle during a calendar day (Annex 1C requirements 269, 294, 322, and 345).

Generation 1:
image
vehicleOdometerBegin is the vehicle odometer value at the beginning of the period of use of the vehicle.
vehicleOdometerEnd is the vehicle odometer value at the end of the period of use of the vehicle.
vehicleFirstUse is the date and time of the beginning of the period of use of the vehicle.
vehicleLastUse is the date and time of the end of the period of use of the vehicle.
vehicleRegistration is the VRN and the registering Member State of the vehicle.
vuDataBlockCounter is the value of the VuDataBlockCounter at last extraction of the period of use of the vehicle.
Generation 2:
image
In addition to generation 1 the following data element is used:
VehicleIdentificationNumber is the vehicle identification number referring to the vehicle as a whole.

2.38.    CardVehiclesUsed

Information, stored in a driver or workshop card, related to the vehicles used by the card holder (Annex 1C requirements 270, 295, 323, and 346).

image

vehiclePointerNewestRecord is the index of the last updated vehicle record.

Value assignment: Number corresponding to the numerator of the vehicle record, beginning with ‘0’ for the first occurrence of the vehicle records in the structure.

cardVehicleRecords is the set of records containing information on vehicles used.

2.39.    CardVehicleUnitRecord

Generation 2:

Information, stored in a driver or workshop card, related to a vehicle unit that was used (Annex 1C requirement 303 and 351).

image

timeStamp is the beginning of the period of use of the vehicle unit (i.e. first card insertion in the vehicle unit for the period).

manufacturerCode identifies the manufacturer of the Vehicle Unit.

deviceID identifies the Vehicle Unit type of a manufacturer. The value is manufacturer specific.

vuSoftwareVersion is the software version number of the Vehicle Unit.

2.40.    CardVehicleUnitsUsed

Generation 2:

Information, stored in a driver or workshop card, related to the vehicle units used by the card holder (Annex 1C requirement 306 and 352).

image

vehicleUnitPointerNewestRecord is the index of the last updated vehicle unit record.

Value assignment: Number corresponding to the numerator of the vehicle unit record, beginning with ‘0’ for the first occurrence of the vehicle unit records in the structure.

cardVehicleUnitRecords is the set of records containing information on vehicle units used.

2.41.    Certificate

The certificate of a public key issued by a Certification Authority.

Generation 1:
image
Value assignment: digital signature with partial recovery of a CertificateContent according to Appendix 11 common security mechanisms: Signature (128 bytes) || Public Key remainder (58 bytes) || Certification Authority Reference (8 bytes).
Generation 2:
image
Value assignment: See Appendix 11

2.42.    CertificateContent

Generation 1:

The (clear) content of the certificate of a public key according to Appendix 11 common security mechanisms.

image

certificateProfileIdentifier is the version of the corresponding certificate.

Value assignment: ‘01h’ for this version.

certificationAuthorityReference identifies the Certification Authority issuing the certificate. It also references the Public Key of this Certification Authority.

certificateHolderAuthorisation identifies the rights of the certificate holder.

certificateEndOfValidity is the date when the certificate expires administratively.

certificateHolderReference identifies the certificate holder. It also references his Public Key.

publicKey is the public key that is certified by this certificate.

2.43.    CertificateHolderAuthorisation

Identification of the rights of a certificate holder.

image

Generation 1:
tachographApplicationID is the application identifier for the tachograph application.
Value assignment: ‘FFh’‘54h’‘41h’‘43h’‘48h’‘4Fh’. This AID is a proprietary non registered application identifier in accordance with ISO/IEC 7816-5.
equipmentType is the identification of the type of equipment to which the certificate is intended.
Value assignment: in accordance with EquipmentType data type. 0 if certificate is the one of a Member State.
Generation 2:
tachographApplicationID denotes the 6 most significant bytes of the generation 2 tachograph card application identifier (AID). The AID for the tachograph card application is specified in chapter 6.2.
Value assignment:‘FF 53 4D 52 44 54’.
equipmentType is the identification of the type of equipment as specified for generation 2 to which the certificate is intended.
Value assignment: in accordance with EquipmentType data type.

2.44.    CertificateRequestID

Unique identification of a certificate request. It can also be used as a Vehicle Unit Public Key Identifier if the serial number of the vehicle Unit to which the key is intended is not known at certificate generation time.

image

requestSerialNumber is a serial number for the certificate request, unique for the manufacturer and the month below.

requestMonthYear is the identification of the month and the year of the certificate request.

Value assignment: BCD coding of Month (two digits) and Year (two last digits).

crIdentifier: is an identifier to distinguish a certificate request from an extended serial number.

Value assignment: ‘FFh’.

manufacturerCode: is the numerical code of the manufacturer requesting the certificate.

2.45.    CertificationAuthorityKID

Identifier of the Public Key of a Certification Authority (a Member State or the European Certification Authority).

image

nationNumeric is the numerical nation code of the Certification Authority.

nationAlpha is the alphanumerical nation code of the Certification Authority.

keySerialNumber is a serial number to distinguish the different keys of the Certification Authority in the case keys are changed.

additionalInfo is a two byte field for additional coding (Certification Authority specific).

caIdentifier is an identifier to distinguish a Certification Authority Key Identifier from other Key Identifiers.

Value assignment: ‘01h’.

2.46.    CompanyActivityData

Information, stored in a company card, related to activities performed with the card (Annex 1C requirement 373 and 379).

image

companyPointerNewestRecord is the index of the last updated companyActivityRecord.

Value assignment: Number corresponding to the numerator of the company activity record, beginning with ‘0’ for the first occurrence of the company activity record in the structure.

companyActivityRecords is the set of all company activity records.

companyActivityRecord is the sequence of information related to one company activity.

companyActivityType is the type of the company activity.

companyActivityTime is the date and time of the company activity.

cardNumberInformation is the card number and the card issuing Member State of the card downloaded, if any.

vehicleRegistrationInformation is the VRN and registering Member State of the vehicle downloaded or locked in or out.

downloadPeriodBegin and downloadPeriodEnd is the period downloaded from the VU, if any.

2.47.    CompanyActivityType

Code indicating an activity carried out by a company using its company card.

image

2.48.    CompanyCardApplicationIdentification

Information, stored in a company card related to the identification of the application of the card (Annex 1C requirement 369 and 375).

image

typeOfTachographCardId is specifying the implemented type of card.

cardStructureVersion is specifying the the version of the structure that is implemented in the card.

noOfCompanyActivityRecords is the number of company activity records the card can store.

2.49.    CompanyCardHolderIdentification

Information, stored in a company card, related to the cardholder identification (Annex 1C requirement 372 and 378).

image

companyName is the name of the holder company.

companyAddress is the address of the holder company.

cardHolderPreferredLanguage is the preferred language of the card holder.

2.50.    ControlCardApplicationIdentification

Information, stored in a control card related to the identification of the application of the card (Annex 1C requirement 357 and 363).

image

typeOfTachographCardId is specifying the implemented type of card.

cardStructureVersion is specifying the version of the structure that is implemented in the card.

noOfControlActivityRecords is the number of control activity records the card can store.

2.51.    ControlCardControlActivityData

Information, stored in a control card, related to control activity performed with the card (Annex 1C requirement 361 and 367).

image

controlPointerNewestRecord is the index of the last updated control activity record.

Value assignment: Number corresponding to the numerator of the control activity record, beginning with ‘0’ for the first occurrence of the control activity record in the structure.

controlActivityRecords is the set of all control activity records.

controlActivityRecord is the sequence of information related to one control.

controlType is the type of the control.

controlTime is the date and time of the control.

controlledCardNumber is the card number and the card issuing Member State of the card controlled.

controlledVehicleRegistration is the VRN and registering Member State of the vehicle in which the control happened.

controlDownloadPeriodBegin and controlDownloadPeriodEnd is the period eventually downloaded.

2.52.    ControlCardHolderIdentification

Information, stored in a control card, related to the identification of the cardholder (Annex 1C requirement 360 and 366).

image

controlBodyName is the name of the control body of the card holder.

controlBodyAddress is the address of the control body of the card holder.

cardHolderName is the name and first name(s) of the holder of the Control Card.

cardHolderPreferredLanguage is the preferred language of the card holder.

2.53.    ControlType

Code indicating the activities carried out during a control. This data type is related to Annex 1C requirements 126, 274, 299, 327, and 350.

image

Generation 1:
Value assignment — Octet aligned: ‘cvpdxxxx’B (8 bits)

‘c’B

card downloading:

‘0’B: card not downloaded during this control activity,
‘1’B: card downloaded during this control activity

‘v’B

VU downloading:

‘0’B: VU not downloaded during this control activity,
‘1’B: VU downloaded during this control activity

‘p’B

printing:

‘0’B: no printing done during this control activity,
‘1’B: printing done during this control activity

‘d’B

display:

‘0’B: no display used during this control activity,
‘1’B: display used during this control activity

‘xxxx’B

Not used.

Generation 2:
Value assignment — Octet aligned: ‘cvpdexxx’B (8 bits)

‘c’B

card downloading:

‘0’B: card not downloaded during this control activity,
‘1’B: card downloaded during this control activity

‘v’B

VU downloading:

‘0’B: VU not downloaded during this control activity,
‘1’B: VU downloaded during this control activity

‘p’B

printing:

‘0’B: no printing done during this control activity,
‘1’B: printing done during this control activity

‘d’B

display:

‘0’B: no display used during this control activity,
‘1’B: display used during this control activity

‘e’B

roadside calibration checking:

‘0’B: calibration parameters not checked during this control activity,
‘1’B: calibration parameters checked during this control activity

‘xxx’B

RFU.

2.54.    CurrentDateTime

The current date and time of the recording equipment.

image

Value assignment: not further specified.

2.55.    CurrentDateTimeRecordArray

Generation 2:

The current date and time plus metadata as used in the download protocol.

image

recordType denotes the type of the record (CurrentDateTime). Value Assignment: See RecordType

recordSize is the size of the CurrentDateTime in bytes.

noOfRecords is the number of records in the set records.

records is a set of current date and time records.

2.56.    DailyPresenceCounter

Counter, stored in a driver or workshop card, increased by one for each calendar day the card has been inserted in a VU. This data type is related to Annex 1C requirements 266, 299, 320, and 343.

image

Value assignment: Consecutive Number with maximum value = 9 999, starting again with 0. At the time of first issuing of the card the number is set to 0.

2.57.    Datef

Date expressed in a readily printable numeric format.

image

Value assignment:

yyyy

Year

mm

Month

dd

Day

‘00000000’H

denotes explicitly no date.

2.58.    DateOfDayDownloaded

Generation 2:

The date and time of the download.

image

Value assignment: not further specified.

2.59.    DateOfDayDownloadedRecordArray

Generation 2:

The date and time of the download plus metadata as used in the download protocol.

image

recordType denotes the type of the record (DateOfDayDownloaded). Value Assignment: See RecordType

recordSize is the size of the CurrentDateTime in bytes.

noOfRecords is the number of records in the set records.

records is the set of date and time of the download records.

2.60.    Distance

A distance travelled (result of the calculation of the difference between two vehicle's odometer values in kilometers).

image

Value assignment: Unsigned binary. Value in km in the operational range 0 to 9 999  km.

2.61.    DriverCardApplicationIdentification

Information, stored in a driver card related to the identification of the application of the card (Annex 1C requirement 253 and 278).

Generation 1:
image
typeOfTachographCardId is specifying the implemented type of card.
cardStructureVersion is specifying the the version of the structure that is implemented in the card.
noOfEventsPerType is the number of events per type of event the card can record.
noOfFaultsPerType is the number of faults per type of fault the card can record.
activityStructureLength indicates the number of bytes available for storing activity records.
noOfCardVehicleRecords is the number of vehicle records the card can contain.
noOfCardPlaceRecords is the number of places the card can record.
Generation 2:

▼M1

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

▼B

2.62.    DriverCardHolderIdentification

Information, stored in a driver card, related to the identification of the cardholder (Annex 1C requirement 256 and 281).

image

cardHolderName is the name and first name(s) of the holder of the Driver Card.

cardHolderBirthDate is the date of birth of the holder of the Driver Card.

cardHolderPreferredLanguage is the preferred language of the card holder.

▼M1

2.63.    Reserved for future use

▼B

2.64.    EGFCertificate

Generation 2:

Certificate of the external GNSS facility public key for mutual authentication with a VU. The structure of this certificate is specified in Appendix 11.

image

2.65.    EmbedderIcAssemblerId

Provides information about the IC embedder.

image

countryCode is the 2 letter country code of the module embedder according to ISO 3166.

moduleEmbedder identifies the module embedder.

manufacturerInformation for manufacturer internal usage.

2.66.    EntryTypeDailyWorkPeriod

Code to distinguish between begin and end for an entry of a daily work period place and condition of the entry.

Generation 1
image
Value assignment: according to ISO/IEC8824-1.
Generation 2
image
Value assignment: according to ISO/IEC8824-1.

2.67.    EquipmentType

Code to distinguish different types of equipment for the tachograph application.

image

Generation 1:
image
Value assignment: According to ISO/IEC8824-1.
Value 0 is reserved for the purpose of designating a Member State or Europe in the CHA field of certificates.
Generation 2:

▼M1

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

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.

▼B

2.68.    EuropeanPublicKey

Generation 1:

The European public key.

image

2.69.    EventFaultRecordPurpose

Code explaining why an event or a fault has been recorded.

image

Value assignment:



image

one of the 10 most recent (or last) events or faults

the longest event for one of the last 10 days of occurrence

one of the 5 longest events over the last 365 days

the last event for one of the last 10 days of occurrence

the most serious event for one of the last 10 days of occurrence

one of the 5 most serious events over the last 365 days

the first event or fault having occurred after the last calibration

an active/on-going event or fault

RFU

manufacturer specific

2.70.    EventFaultType

Code qualifying an event or a fault.

image

Value assignment:

Generation 1:



image

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,

RFU,

image

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,

RFU,

image

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

Recording equipment faults,

No further details,

VU internal fault,

Printer fault,

Display fault,

Downloading fault,

Sensor fault,

RFU,

image

Card faults,

No further details,

RFU,

image

RFU,

image

Manufacturer specific.

▼M1

Generation 2:



image

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

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

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

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

Card faults,

No further details,

RFU,

image

RFU,

image

Manufacturer specific.

2.71.    ExtendedSealIdentifier

Generation 2:

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

image

manufacturerCode is a code of the manufacturer of the seal.

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

▼B

2.72.    ExtendedSerialNumber

Unique identification of an equipment. It can also be used as an equipment Public Key Identifier.

Generation 1:
image
serialNumber is a serial number for the equipment, unique for the manufacturer, the equipment's type and the month and year below.
monthYear is the identification of the month and the year of manufacturing (or of serial number assignment).
Value assignment: BCD coding of Month (two digits) and Year (two last digits).
type is an identifier of the type of equipment.
Value assignment: manufacturer specific, with ‘FFh’ reserved value.
manufacturerCode: is the numerical code identifying a manufacturer of type approved equipment.
Generation 2:
image
serialNumber see Generation 1
monthYear see Generation 1
type indicates the type of equipment
manufacturerCode: see Generation 1.

2.73.    FullCardNumber

Code fully identifying a tachograph card.

image

cardType is the type of the tachograph card.

cardIssuingMemberState is the code of the Member State having issued the card.

cardNumber is the card number.

2.74.    FullCardNumberAndGeneration

Generation 2:

Code fully identifying a tachograph card and its generation.

image

fullcardNumber identifies the tachograph card.

generation indicates the generation of the tachograph card used.

2.75.    Generation

Generation 2:

Indicates the generation of tachograph used.

image

Value assignment:

‘00’H

RFU

‘01’H

Generation 1

‘02’H

Generation 2

‘03’H .. ‘FF’H

RFU

2.76.    GeoCoordinates

Generation 2:

The geo-coordinates are encoded as integers. These integers are multiples of the ±DDMM.M encoding for the latitude and ±DDDMM.M for the longitude. Here ±DD respectively ±DDD denotes the degrees and MM.M the minutes.

image

latitude is encoded as a multiple (factor 10) of the ±DDMM.M representation.

longitude is encoded as a multiple (factor 10) of the ±DDDMM.M representation.

2.77.    GNSSAccuracy

Generation 2:

The accuracy of the GNSS position data (definition eee)). This accuracy is encoded as integer and is a multiple (factor 10) of the X.Y value provided by the GSA NMEA sentence.

image

▼M1

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

image

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)

image

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.

▼B

2.80.    GNSSPlaceRecord

Generation 2:

Information related to the GNSS position of the vehicle (Annex 1C requirements 108, 109, 110, 296, 305, 347, and 353).

image

timeStamp is the date and time when the GNSS position of the vehicle was determined.

gnssAccuracy is the accuracy of the GNSS position data.

geoCoordinates is the recorded location using GNSS.

2.81.    HighResOdometer

Odometer value of the vehicle: Accumulated distance travelled by the vehicle during its operation.

image

Value assignment: Unsigned binary. Value in 1/200 km in the operating range 0 to 21 055 406  km.

2.82.    HighResTripDistance

A distance travelled during all or part of a journey.

image

Value assignment: Unsigned binary. Value in 1/200 km in the operating range 0 to 21 055 406  km.

2.83.    HolderName

The surname and first name(s) of a card holder.

image

holderSurname is the surname (family name) of the holder. This surname does not include titles.

Value assignment: When a card is not personal, holderSurname contains the same information as companyName or workshopName or controlBodyName.

holderFirstNames is the first name(s) and initials of the holder.

2.84.    InternalGNSSReceiver

Generation 2:

Information if the GNSS receiver is internal or external to the vehicle unit. True means that the GNSS receiver is internal to the VU. False means that the GNSS receiver is external.

image

2.85.    K-ConstantOfRecordingEquipment

Constant of the recording equipment (definition m)).

image

Value assignment: Pulses per kilometer in the operating range 0 to 64 255 pulses/km.

▼M1

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.

image

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.

▼B

2.87.    KMWCKey

Generation 2:

AES key and its associated key version used for VU — Motion Sensor pairing. For details see Appendix 11.

image

kMWCKey is the length of the AES key concatenated with the key which is used for VU — Motion Sensor pairing.

keyVersion denotes the key version of the AES key.

2.88.    Language

Code identifying a language.

image

Value assignment: Two-letter lower-case coding according to ISO 639.

2.89.    LastCardDownload

Date and time, stored on a driver card, of last card download (for other purposes than control) Annex 1C requirement 257 and 282. This date is updateable by a VU or any card reader.

image

Value assignment: not further specified.

2.90.    LinkCertificate

Generation 2:

The link certificate between European Root CA key pairs.

image

2.91.    L-TyreCircumference

Effective circumference of the wheel tyres (definition u)).

image

Value assignment: Unsigned binary, value in 1/8 mm in the operating range 0 to 8 031  mm.

▼M1

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.

image

▼B

2.93.    ManualInputFlag

Code identifying whether a cardholder has manually entered driver activities at card insertion or not (Annex 1B requirement 081 and Annex 1C requirement 102).

image

Value assignment: not further specified.

2.94.    ManufacturerCode

Code identifying a manufacturer of type approved equipment.

image

The laboratory competent for interoperability tests maintains and publishes the list of manufacturer codes on its web site (Annex 1C requirement 454).

ManufacturerCodes are provisionally assigned to developers of tachograph equipment on application to the laboratory competent for interoperability tests.

2.95.    ManufacturerSpecificEventFaultData

Generation 2:

Manufacturer specific error codes simplify the error analysis and maintenance of vehicle units.

image

manufacturerCode identifies the manufacturer of the Vehicle Unit.

manufacturerSpecificErrorCode is an error code specific to the manufacturer.

2.96.    MemberStateCertificate

The certificate of the public key of a member state issued by the European certification authority.

image

2.97.    MemberStateCertificateRecordArray

Generation 2:

The member state certificate plus metadata as used in the download protocol.

image

recordType denotes the type of the record (MemberStateCertificate). Value Assignment: See RecordType

recordSize is the size of the MemberStateCertificate in bytes.

noOfRecords is the number of records in the set records. The value shall be set to 1 as the certficates may have different lengths.

records is the set of member state certificates.

2.98.    MemberStatePublicKey

Generation 1:

The public key of a Member State.

image

2.99.    Name

A name.

image

codePage specifies a character set defined in Chapter 4,

name is a name encoded using the specified character set.

2.100.    NationAlpha

Alphabetic reference to a country shall be in accordance with the distinguishing signs used on vehicles in international traffic (United Nations Vienna Convention on Road Traffic, 1968).

image

The Nation Alpha and Numeric codes shall be held on a list maintained on the website of the laboratory appointed to carry out interoperability testing, as set out in Annex 1C requirement 440.

2.101.    NationNumeric

Numerical reference to a country.

image

Value assignment: see data type 2.100 (NationAlpha).

Any amendment or updating of the Nation Alpha or Numeric specification described in the above paragraph shall only be made out after the appointed laboratory has obtained the views of type approved digital and smart tachograph vehicle unit manufacturers.

2.102.    NoOfCalibrationRecords

Number of calibration records, a workshop card can store.

Generation 1:
image
Value assignment: see Appendix 2.
Generation 2:
image
Value assignment: see Appendix 2.

2.103.    NoOfCalibrationsSinceDownload

Counter indicating the number of calibrations performed with a workshop card since its last download (Annex 1C requirement 317 and 340).

image

Value assignment: Not specified further.

2.104.    NoOfCardPlaceRecords

Number of place records a driver or workshop card can store.

Generation 1:
image
Value assignment: see Appendix 2.
Generation 2:
image
Value assignment: see Appendix 2.

2.105.    NoOfCardVehicleRecords

Number of vehicles used records a driver or workshop card can store.

image

Value assignment: see Appendix 2.

2.106.    NoOfCardVehicleUnitRecords

Generation 2:

Number of vehicle units used records a driver or workshop card can store.

image

Value assignment: see Appendix 2.

2.107.    NoOfCompanyActivityRecords

Number of company activity records, a company card can store.

image

Value assignment: see Appendix 2.

2.108.    NoOfControlActivityRecords

Number of control activity records, a control card can store.

image

Value assignment: see Appendix 2.

2.109.    NoOfEventsPerType

Number of events per type of event a card can store.

image

Value assignment: see Appendix 2.

2.110.    NoOfFaultsPerType

Number of faults per type of fault a card can store.

image

Value assignment: see Appendix 2.

▼M1

2.111.    NoOfGNSSADRecords

Generation 2:

Number of GNSS accumulated driving records a card can store.

image

Value assignment: see Appendix 2.

▼B

2.112.    NoOfSpecificConditionRecords

Generation 2:

Number of specific condition records a card can store.

image

Value assignment: see Appendix 2.

2.113.    OdometerShort

Odometer value of the vehicle in a short form.

image

Value assignment: Unsigned binary. Value in km in the operating range 0 to 9 999 999  km.

2.114.    OdometerValueMidnight

The vehicle's odometer value at midnight on a given day (Annex 1B requirement 090 and Annex 1C requirement 113).

image

Value assignment: not further specified.

2.115.    OdometerValueMidnightRecordArray

Generation 2:

The OdometerValueMidnight plus metadata used in the download protocol.

image

recordType denotes the type of the record (OdometerValueMidnight). Value Assignment: See RecordType

recordSize is the size of the OdometerValueMidnight in bytes.

noOfRecords is the number of records in the set records.

records is the set of OdometerValueMidnight records.

2.116.    OverspeedNumber

Number of over speeding events since the last over speeding control.

image

Value assignment: 0 means that no over speeding event has occurred since the last over speeding control, 1 means that one over speeding event has occurred since the last over speeding control …255 means that 255 or more over speeding events have occurred since the last over speeding control.

2.117.    PlaceRecord

Information related to a place where a daily work period begins or ends (Annex 1C requirements 108, 271, 296, 324, and 347).

Generation 1:
image
entryTime is a date and time related to the entry.
entryTypeDailyWorkPeriod is the type of entry.
dailyWorkPeriodCountry is the country entered.
dailyWorkPeriodRegion is the region entered.
vehicleOdometerValue is the odometer value at the time of place entry.
Generation 2:
image
In addition to Generation 1 the following component is used:
entryGNSSPlaceRecord is the recorded location and time.

2.118.    PreviousVehicleInfo

Information related to the vehicle previously used by a driver when inserting his card in a vehicle unit (Annex 1B requirement 081 and Annex 1C requirement 102).

Generation 1:
image
vehicleRegistrationIdentification is the VRN and the registering Member State of the vehicle.
cardWithdrawalTime is the card withdrawal date and time.
Generation 2:
image
In addition to generation 1 the following data element is used:
vuGeneration identifies the generation of the vehicle unit.

2.119.    PublicKey

Generation 1:

A public RSA key.

image

rsaKeyModulus is the Modulus of the key pair.

rsaKeyPublicExponent is the public exponent of the key pair.

2.120.    RecordType

Generation 2:

Reference to a record type. This data type is used in RecordArrays.

image

Value assignment:



image ►(1) M1  
‘01’H
‘02’H
‘03’H
‘04’H
‘05’H
‘06’H
‘07’H
‘08’H
‘09’H
‘0A’H
‘0B’H
‘0C’H
‘0D’H
‘0E’H
‘0F’H
‘10’H
‘11’H
‘12’H
‘13’H
‘14’H
‘15’H
‘16’H
‘17’H
‘18’H
‘19’H
‘1A’H
‘1B’H
‘1C’H
‘1D’H
‘1E’H
‘1F’H
‘20’H
‘21’H
‘22’H to ‘7F’H
‘80’H to ‘FF’H

ActivityChangeInfo,

CardSlotsStatus,

CurrentDateTime,

MemberStateCertificate,

OdometerValueMidnight,

DateOfDayDownloaded,

SensorPaired,

Signature,

SpecificConditionRecord,

VehicleIdentificationNumber,

VehicleRegistrationNumber,

VuCalibrationRecord,

VuCardIWRecord,

VuCardRecord,

VuCertificate,

VuCompanyLocksRecord,

VuControlActivityRecord,

VuDetailedSpeedBlock,

VuDownloadablePeriod,

VuDownloadActivityData,

VuEventRecord,

►M1  VuGNSSADRecord, ◄

VuITSConsentRecord,

VuFaultRecord,

VuIdentification,

VuOverSpeedingControlData,

VuOverSpeedingEventRecord,

VuPlaceDailyWorkPeriodRecord,

VuTimeAdjustmentGNSSRecord,

VuTimeAdjustmentRecord,

VuPowerSupplyInterruptionRecord,

SensorPairedRecord,

SensorExternalGNSSCoupledRecord,

RFU,

Manufacturer specific.

2.121.    RegionAlpha

Alphabetic reference to a region within a specified country.

image

Generation 1:
Value assignment:
image
Generation 2:
The RegionAlpha codes shall be held on a list maintained on the website of the laboratory appointed to carry out interoperability testing.

2.122.    RegionNumeric

Numerical reference to a region within a specified country.

image

Generation 1:
Value assignment:
image
Generation 2:
The RegionNumeric codes shall be held on a list maintained on the website of the laboratory appointed to carry out interoperability testing.

2.123.    RemoteCommunicationModuleSerialNumber

Generation 2:

Serial number of the Remote Communication Module.

image

2.124.    RSAKeyModulus

Generation 1:

The modulus of a RSA key pair.

image

Value assignment: Unspecified.

2.125.    RSAKeyPrivateExponent

Generation 1:

The private exponent of a RSA key pair.

image

Value assignment: Unspecified.

2.126.    RSAKeyPublicExponent

Generation1:

The public exponent of a RSA key pair.

image

Value assignment: Unspecified.

2.127.    RtmData

Generation2:

For the definition of this data type see Appendix 14.

2.128.    SealDataCard

Generation 2:

This data type stores information about the seals that are attached to the different components of a vehicle and is intended for storage on a card. This data type is related to Annex 1C requirement 337.

image

noOfSealRecords is the number of records in sealRecords.

sealRecords is a set of seal records.

2.129.    SealDataVu

Generation 2:

This data type stores information about the seals that are attached to the different components of a vehicle and is intended for storage in a Vehicle Unit.

image

sealRecords is a set of seal records. If there are less than 5 seals available the value of the EquipmentType in all unused sealRecords shall be set to 16, i.e. unused.

2.130.    SealRecord

Generation 2:

This data type stores information about a seal that is attached to a component. This data type is related to Annex 1C requirement 337.

image

equipmentType identifies the type of equipment the seal is attached to.

extendedSealIdentifier is the identifier of the seal attached to the equipment.

2.131.    SensorApprovalNumber

Type approval number of the sensor.

Generation 1:
image
Value assignment: Unspecified.
Generation 2:
image
Value assignment:
The approval number shall be provided as published on the corresponding European Commission web site, i.e. for example including hyphens if any. The approval number shall be left-aligned.

2.132.    SensorExternalGNSSApprovalNumber

Generation 2:

Type approval number of the external GNSS facility.

image

Value assignment:

The approval number shall be provided as published on the corresponding European Commission web site, i.e. for example including hyphens if any. The approval number shall be left-aligned.

2.133.    SensorExternalGNSSCoupledRecord

Generation 2:

Information, stored in a vehicle unit, related to the identification of the external GNSS facility coupled with the vehicle unit (Annex 1C requirement 100).

image

sensorSerialNumber is the serial number of the external GNSS facility coupled with the vehicle unit.

sensorApprovalNumber is the approval number of this external GNSS facility.

sensorCouplingDate is a date of coupling of this external GNSS facility with the vehicle unit.

2.134.    SensorExternalGNSSIdentification

Generation 2:

Information related to the identification of the external GNSS facility (Annex 1C requirement 98).

image

sensorSerialNumber is the extended serial number of the external GNSS facility.

sensorApprovalNumber is the approval number of the external GNSS facility.

sensorSCIdentifier is the identifier of the security component of the external GNSS facility.

sensorOSIdentifier is the identifier of the operating system of the external GNSS facility.

2.135.    SensorExternalGNSSInstallation

Generation 2:

Information, stored in an external GNSS facility, related to the installation of the external GNSS sensor (Annex 1C requirement 123).

image

sensorCouplingDateFirst is the date of the first coupling of external GNSS facility with a vehicle unit.

firstVuApprovalNumber is the approval number of the first vehicle unit coupled with the external GNSS facility.

firstVuSerialNumber is the serial number of the first vehicle unit paired with the external GNSS facility.

sensorCouplingDateCurrent is the date of the current coupling of external GNSS facility with a vehicle unit.

currentVuApprovalNumber is the approval number of the vehicle unit currently coupled with the external GNSS facility.

currentVUSerialNumber is the serial number of the vehicle unit currently coupled with the external GNSS facility.

2.136.    SensorExternalGNSSOSIdentifier

Generation 2:

Identifier of the operating system of the external GNSS facility.

image

Value assignment: manufacturer specific.

2.137.    SensorExternalGNSSSCIdentifier

Generation 2:

This type is used e.g. to identify the cryptographic module of the external GNSS facility.

Identifier of the security component of the external GNSS facility.

image

Value assignment: component manufacturer specific.

2.138.    SensorGNSSCouplingDate

Generation 2:

Date of a coupling of the external GNSS facility with a vehicle unit.

image

Value assignment: Unspecified.

2.139.    SensorGNSSSerialNumber

Generation 2:

This type is used to store the serial number of the GNSS receiver both when it is inside the VU and when it is outside the VU.

Serial number of the GNSS receiver.

image

2.140.    SensorIdentification

Information, stored in a motion sensor, related to the identification of the motion sensor (Annex 1B requirement 077 and Annex 1C requirement 95).

image

sensorSerialNumber is the extended serial number of the motion sensor (includes part number and manufacturer code).

sensorApprovalNumber is the approval number of the motion sensor.

sensorSCIdentifier is the identifier of the security component of the motion sensor.

sensorOSIdentifier is the identifier of the operating system of the motion sensor.

2.141.    SensorInstallation

Information, stored in a motion sensor, related to the installation of the motion sensor (Annex 1B requirement 099 and Annex 1C requirement 122).

image

sensorPairingDateFirst is the date of the first pairing of the motion sensor with a vehicle unit.

firstVuApprovalNumber is the approval number of the first vehicle unit paired with the motion sensor.

firstVuSerialNumber is the serial number of the first vehicle unit paired with the motion sensor.

sensorPairingDateCurrent is the date of the current pairing of the motion sensor with the vehicle unit.

currentVuApprovalNumber is the approval number of the vehicle unit currently paired with the motion sensor.

currentVUSerialNumber is the serial number of the vehicle unit currently paired with the motion sensor.

2.142.    SensorInstallationSecData

Information, stored in a workshop card, related to the security data needed for pairing motion sensors to vehicle units (Annex 1C requirement 308 and 331).

Generation 1:
image
Value assignment: in accordance with ISO 16844-3.
Generation 2:
As described in Appendix 11 a workshop card shall store up to three keys for VU Motion Sensor pairing. These keys have different key versions.
image

2.143.    SensorOSIdentifier

Identifier of the operating system of the motion sensor.

image

Value assignment: manufacturer specific.

2.144.    SensorPaired

Generation 1:

Information, stored in a vehicle unit, related to the identification of the motion sensor paired with the vehicle unit (Annex 1B requirement 079).

image

sensorSerialNumber is the serial number of the motion sensor currently paired with the vehicle unit.

sensorApprovalNumber is the approval number of the motion sensor currently paired with the vehicle unit.

sensorPairingDateFirst is the date of the first pairing with a vehicle unit of the motion sensor currently paired with the vehicle unit.

2.145.    SensorPairedRecord

Generation 2:

Information, stored in a vehicle unit, related to the identification of a motion sensor paired with the vehicle unit (Annex 1C requirement 97).

image

sensorSerialNumber is the serial number of a motion sensor paired with the vehicle unit.

sensorApprovalNumber is the approval number of this motion sensor.

sensorPairingDate is a date of pairing of this motion sensor with the vehicle unit.

2.146.    SensorPairingDate

Date of a pairing of the motion sensor with a vehicle unit.

image

Value assignment: Unspecified.

2.147.    SensorSCIdentifier

Identifier of the security component of the motion sensor.

image

Value assignment: component manufacturer specific.

2.148.    SensorSerialNumber

Serial number of the motion sensor.

image

2.149.    Signature

A digital signature.

Generation 1:
image
Value assignment: in accordance with Appendix 11 Common security mechanisms.
Generation 2:
image
Value assignment: in accordance with Appendix 11 Common security mechanisms.

2.150.    SignatureRecordArray

Generation 2:

A set of signatures plus metadata used in the download protocol.

image

recordType denotes the type of the record (Signature). Value Assignment: See RecordType

recordSize is the size of the Signature in bytes.

noOfRecords is the number of records in the set records. The value shall be set to 1 as the signatures may have different lengths.

records is the set of signatures.

2.151.    SimilarEventsNumber

The number of similar events for one given day (Annex 1B requirement 094 and Annex 1C requirement 117).

image

Value assignment: 0 is not used, 1 means that only one event of that type has occurred and has been stored on that day, 2 means that 2 events of that type has occurred on that day (one only has been stored), …255 means that 255 or more events of that type have occurred on that day.

2.152.    SpecificConditionRecord

Information, stored in a driver card, a workshop card or a vehicle unit, related to a specific condition (requirements Annex 1C 130, 276, 301, 328, and 355).

image

entryTime is the date and time of the entry.

specificConditionType is the code identifying the specific condition.

2.153.    SpecificConditions

Information, stored in a driver card, a workshop card or a vehicle unit, related to a specific condition (Annex 1C requirement 131, 277, 302, 329, and 356).

Generation 2:

image

conditionPointerNewestRecord is the index of the last updated specific condition record.

Value assignment: Number corresponding to the numerator of the specific condition record, beginning with ‘0’ for the first occurrence of the specific condition record in the structure.

specificConditionRecords is the set of records containing information on the specific conditions recorded.

2.154.    SpecificConditionType

Code identifying a specific condition (Annex 1B requirements 050b, 105a, 212a and 230a and Annex 1C requirements 62).

image

Generation 1:
Value assignment:

‘00’H

RFU

‘01’H

Out of scope — Begin

‘02’H

Out of scope — End

‘03’H

Ferry / Train crossing

‘04’H .. ‘FF’H

RFU

Generation 2:
Value assignment:

‘00’H

RFU

‘01’H

Out of scope — Begin

‘02’H

Out of scope — End

‘03’H

Ferry / Train crossing — Begin

‘04’H

Ferry / Train crossing — End

‘05’H .. ‘FF’H

RFU

2.155.    Speed

Speed of the vehicle (km/h).

image

Value assignment: kilometers per hour in the operational range 0 to 220 km/h.

2.156.    SpeedAuthorised

Maximum authorised Speed of the vehicle (definition hh)).

image

2.157.    SpeedAverage

Average speed in a previously defined duration (km/h).

image

2.158.    SpeedMax

Maximum speed measured in a previously defined duration.

image

2.159.    TachographPayload

Generation 2:

For the definition of this data type see Appendix 14.

▼M1

2.160.    Reserved for future use

▼B

2.161.    TDesSessionKey

Generation 1:

A triple DES session key.

image

Value assignment: not further specified.

▼M1

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.

image

Value assignmentOctet aligned: Number of seconds since midnight 1 January 1970 UTC.

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

▼B

2.163.    TyreSize

Designation of tyre dimensions.

image

Value assignment: in accordance with Directive 92/23 (EEC) 31/03/92 O.J. L129 p.95.

2.164.    VehicleIdentificationNumber

Vehicle Identification Number (VIN) referring to the vehicle as a whole, normally chassis serial number or frame number.

image

Value assignment: As defined in ISO 3779.

2.165.    VehicleIdentificationNumberRecordArray

Generation 2:

The Vehicle Idenification Number plus metadata as used in the download protocol.

image

recordType denotes the type of the record (VehicleIdentificationNumber). Value Assignment: See RecordType

recordSize is the size of the VehicleIdentificationNumber in bytes.

noOfRecords is the number of records in the set records.