http://www.legislation.gov.uk/id/eur/2016/799

ANNEX I CRequirements for construction, testing, installation, and inspection

Appendix 13

ITS INTERFACE

1.INTRODUCTION

This Appendix specifies the design and the procedures to follow in order to implement the interface with Intelligent Transport Systems (ITS) as required in Article 10 of Regulation (EU) No. 165/2014 (the Regulation).

The Regulation specifies that the tachographs of vehicles may be equipped with standardised interfaces allowing the data recorded or produced by tachograph to be used in operational mode, by an external device, provided that the following conditions are met:

(a)
the interface does not affect the authenticity and the integrity of the data of the tachograph;
(b)
the interface complies with the detailed provisions of Article 11 of the Regulation;
(c)
the external device connected to the interface has access to personal data, including geopositioning data, only after the verifiable consent of the driver to whom the data relates.

2.SCOPE

The scope of this Appendix is to specify how applications hosted on external devices can via a Bluetooth® connection obtain data (the Data) from a tachograph.

The Data available via this interface is described in the Annex 1 of the present document. This interface does not prohibit the implementation of other interfaces (e.g. via the CAN bus) to transmit the data of the VU to other vehicle processing units.

This Appendix specifies:

The Data available through the ITS interface
The Bluetooth® profile that is used to transfer the data
The enquiry and download procedures and sequence of operations
The pairing mechanism between the tachograph and the external device
The consent mechanism available to the driver

F1For clarification, this Appendix does not specify:

The collection of the Data operation and management within the VU (which shall be specified elsewhere within the Regulation or otherwise shall be a function of product design).
The form of presentation of collected data to application hosted on the external device.
Data security provisions above what provides Bluetooth® (such as encryption) concerning the content of the Data (which shall be specified elsewhere within the Regulation [Appendix 11 Common Security Mechanisms]).
The Bluetooth® protocols used by the ITS interface

2.1.Acronyms, definitions and notations

The following acronyms and definitions specific to this Appendix are used in this appendix:

the Communication: exchange of information/data between a master unit (i.e. the tachographs) and an external unit through the ITS interface over Bluetooth®.
the Data: Data sets as specified in Annex 1.
the Regulation: Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport, repealing Council Regulation (EEC) No 3821/85 on recording equipment in road transport and amending Regulation (EC) No 561/2006 of the European Parliament and of the Council on the harmonisation of certain social legislation relating to road transport
BR: Basic Rate
EDR: Enhanced Data Rate
GNSS: Global Navigation Satellite System
IRK: Identity Resolution Key
ITS: Intelligent Transport System
LE: Low Energy
PIN: Personal Identification Number
PUC: Personal Unblocking Code
SID: Service Identifier
SPP: Serial Port Profile
SSP: Secure Simple Pairing
TRTP: Transfer Request Parameter
TREP: Transfer Response Parameter
VU: Vehicle Unit

3.REFERENCED REGULATIONS AND STANDARDS

The specification defined in this Appendix refers to and depends upon all or parts of the following regulations and standards. Within the clauses of this Appendix the relevant standards, or relevant clauses of standards, are specified. In the event of any contradiction the clauses of this Appendix shall take precedence.

Regulations and standards referenced in this Appendix are:

Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport, repealing Council Regulation (EEC) No 3821/85 on recording equipment in road transport and amending Regulation (EC) No 561/2006 of the European Parliament and of the Council on the harmonisation of certain social legislation relating to road transport.
Regulation (EC) No 561/2006 of the European Parliament and of the Council of 15 March 2006 on the harmonisation of certain social legislation relating to road transport and amending Council Regulations (EEC) No 3821/85 and (EC) No 2135/98 and repealing Council Regulation (EEC) No 3820/85.
ISO 16844 — 4: Road vehicles — Tachograph systems — Part 4: Can interface
ISO 16844 — 7: Road vehicles — Tachograph systems — Part 7: Parameters
Bluetooth® — Serial Port Profile — V1.2
Bluetooth® — Core Version 4.2
NMEA 0183 V4.1 protocol

4.INTERFACE WORKING PRINCIPLES

4.1.Preconditions to data transfer via the ITS interface

The VU shall be responsible to keep updated and maintain the data to be stored in the VU, without any involvement of the ITS interface. The means by which this is achieved is internal to the VU, specified elsewhere in the Regulation, and is not specified in this Appendix.

4.1.1Data provided through the ITS interface

The VU shall be responsible to update the data that will be available through the ITS interface at a frequency determined within VU procedures, without any involvement of ITS interface. The VU data shall be used as a basis to populate and update the Data, the means by which this is achieved is specified elsewhere in the Regulation or if there is no such specification is a function of product design and is not specified in this Appendix.

4.1.2Content of the Data

The content of the Data shall be as specified in Annex 1 of this appendix.

4.1.3ITS Applications

ITS applications will be using the data made available through the ITS interface for instance to optimize driver activities management while respecting the Regulation, to detect possible faults of the tachograph or to use the GNSS data. The specification of the applications is not within the scope of this Appendix.

4.2.Communication technology

The Data exchange using the ITS interface shall be performed via a Bluetooth® interface compatible via version 4.2 or later. Bluetooth® operates in the unlicensed industrial, scientific and medical (ISM) band at 2.4 to 2.485 GHz. Bluetooth® 4.2 offers enhanced privacy and security mechanisms and increases speed and reliability of data transfers. For the purpose of this specification is Bluetooth® class 2 radio used with a range up to 10 meters. More information on Bluetooth® 4.2 is available on www.bluetooth.com (https://www.bluetooth.org/en-us/specification/adopted-specifications?_ga=1.215147412.2083380574.1435305676).

The Communication shall be established with the communications equipment after a pairing process has been completed by an authorized device. As Bluetooth® is using a master/slave model to control when and where devices can send data, the tachograph will play the role of master while the external device will be the slave.

F1When an external device comes within range of the VU for the first time, the Bluetooth® pairing process can be initiated (see also annex 2). The devices share their addresses, names, and profiles and common secret key, which allows them to bond whenever they are together in the future. Once this step is completed, the external device is trusted and is in state to initiate requests to download data from the tachograph. It is not foreseen to add encryption mechanisms beyond what Bluetooth® provides. However, if additional security mechanisms are needed, this will be done in accordance with Appendix 11 Common Security Mechanisms.

The overall communication principle is described in the following figure.

Image_r00663

The SPP (Serial Port Profile) profile of Bluetooth® shall be used to transfer data from the VU to the external device.

4.3.PIN authorization

F1For security reasons, the VU will require a PIN code authorization system separated from the Bluetooth pairing. Each VU shall be able to generate PIN codes for authentication purposes composed of at least 4 digits. Every time an external device pairs with the VU, it must provide the correct PIN code before receiving any data.

Succeeding entering the PIN shall result in putting the device on the whitelist. The whitelist shall store at least 64 devices paired with the particular VU.

Failing to provide the correct PIN code three times in a row shall result in putting temporarily the device on the blacklist. While blacklisted, every new attempt from the device shall be rejected. Further failure to provide the correct PIN code three times in a row shall result in increasingly longer ban duration (See table 1). Providing the correct PIN code shall reset the ban duration and the number of attempt. Figure 1 in Annex 2 represents the sequence diagram of a PIN validation attempt.

Table 1Ban duration depending on the number of consecutive failure to provide the correct PIN code

Number of consecutive failure	Ban duration
3	30 seconds
6	5 minutes
9	1 hour
12	24 hours
15	Permanent

Failing to provide the correct PIN code fifteen times (5×3) in a row shall result in a permanent blacklisting of the ITS Unit. Only providing the correct PUC code shall overturn this permanent ban.

The PUC code shall be composed of 8 digits and provided by the manufacturer with the VU. Failing to provide the correct PUC code ten times in a row will irrevocably blacklist the ITS Unit.

F1While the manufacturer may offer an option to change the PIN code directly through the VU, the PUC code shall not be alterable. Modifying the PIN code, if possible, shall require to enter the current PIN code directly in the VU.

Furthermore any devices stored in the whitelist shall be kept until manual removal of by the user (e.g. via the man-machine-interface of the VU or other means). By doing so lost or stolen ITS-units may be removed from the whitelist. Also, any ITS Unit leaving the Bluetooth connection range for more than 24 hours shall be automatically removed from the VU whitelist and must provide the correct PIN code again when the connection is established again.

The format of the messages between the VU interface and the VU are not provided but left to the discretion of the manufacturer. Said manufacturer shall however ensure the message format between the ITS Unit and the VU interface is respected (see ASN.1 specifications).

Any data request shall thus be met with the proper verification of the sender's credential before any form of treatment. Figure 2 of Annex 2 represents the sequence diagram for this procedure. Any blacklisted device shall receive an automatic rejection, any non-blacklisted non-whitelisted device shall receive a PIN request it needs to fulfill before resending its data request.

4.4.Message Format

All messages exchanged between the ITS Unit and the VU interface shall be formatted with a structure consisting of three parts: A header composed by a target byte (TGT), a source byte (SRC) and a length byte (LEN).

The data field composed by a service identifier byte (SID) and a variable amount of data bytes (maximum 255).

The checksum byte is the 1 byte sum series modulo 256 of all the bytes of the message excluding the CS itself.

The message shall be Big Endian.

Table 2General message format

Header			Data Field					Checksum
TGT	SRC	LEN	SID	TRTP	CC	CM	DATA	CS
3 bytes			Max. 255 bytes					1 byte

Header

TGT and SRC: the ID of the Target (TGT) and Source (SRC) devices of the message. The VU Interface shall have the default ID “EE”. This ID cannot be changed. The ITS Unit shall use the default ID “A0” for its first message of the communication session. The VU Interface shall then assign an unique ID to the ITS Unit and informs it of this ID for future messages during the session.

The LEN byte shall only take into account the ‘DATA’ part of the Data Field (see Table 2), the 4 first bytes are implicit.

The VU Interface shall confirm the authenticity of the message's sender by cross-checking its own IDList with the Bluetooth data by checking the ITS Unit listed at the provided ID is currently in the range of the Bluetooth connection.

Data Field

Besides the SID, the Data Field shall also contain other parameters: a transfer request parameter (TRTP) and Counter bytes.

F1If the data to be handled is larger than the available space in one message, it will be split in several submessages. Each submessage shall have the same Header and SID, but will contain a 2-bytes counter, Counter Current (CC) and Counter Max (CM), to indicate the submessage number. To enable error checking and abort the receiving device acknowledges every submessage. The receiving device can accept the submessage, ask for it to be re-transmitted, request the sending device to start again or abort the transmission.

If not used, CC and CM shall be given the value 0xFF.

For instance, the following message

HEADER	SID	TRTP	CC	CM	DATA	CS
3 bytes	Longer than 255 bytes					1 byte

Shall be transmitted as such:

HEADER	SID	TRTP	01	n	DATA	CS
3 bytes	255 bytes					1 byte

HEADER	SID	TRTP	02	n	DATA	CS
3 bytes	255 bytes					1 byte

…

HEADER	SID	TRTP	N	N	DATA	CS
3 bytes	Max. 255 bytes					1 byte

Table 3 contains the messages the VU and the ITS Unit shall be able to exchange. The content of each parameter is given in hexadecimal. Aren't represented in the table CC and CM for clarity, see above for complete format.

Table 3Detailed message content

Message	Header			DATA
Message	TGT	SRC	LEN	SID	TRTP	DATA
RequestPIN	ITSID	EE	00	01	FF
SendITSID	ITSID	EE	01	02	FF	ITSID
SendPIN	EE	ITSID	04	03	FF	4*INTEGER (0..9)
PairingResult	ITSID	EE	01	04	FF	BOOLEAN (T/F)
SendPUC	EE	ITSID	08	05	FF	8*INTEGER (0..9)
BanLiftingResult	ITSID	EE	01	06	FF	BOOLEAN (T/F)
RequestRejected	ITSID	EE	08	07	FF	Time
RequestData
standardTachData	EE	ITSID	01	08	01
personalTachData	EE	ITSID	01	08	02
gnssData	EE	ITSID	01	08	03
standardEventData	EE	ITSID	01	08	04
personalEventData	EE	ITSID	01	08	05
standardFaultData	EE	ITSID	01	08	06
manufacturerData	EE	ITSID	01	08	07
ResquestAccepted	ITSID	EE	Len	09	TREP	Data
DataUnavailable
No data available	ITSID	EE	02	0A	TREP	10
Personal data not shared	ITSID	EE	02	0A	TREP	11
NegativeAnswer
General reject	ITSID	EE	02	0B	SID Req	10
Service not supported	ITSID	EE	02	0B	SID Req	11
Sub function not supported	ITSID	EE	02	0B	SID Req	12
Incorrect message length	ITSID	EE	02	0B	SID Req	13
Conditions not correct or request sequence error	ITSID	EE	02	0B	SID Req	22
Request out of range	ITSID	EE	02	0B	SID Req	31
Response pending	ITSID	EE	02	0B	SID Req	78
ITSID Mismatch	ITSID	EE	02	0B	SID Req	FC
ITSID Not Found	ITSID	EE	02	0B	SID Req	FB

RequestPIN (SID 01)

This message is issued by the VU Interface if a non-blacklisted but non-whitelisted ITS unit is sending any data request.

SendITSID (SID 02)

This message is issued by the VU Interface whenever a new device is sending a request. This device shall use the default ID “A0” before getting assigned an unique ID for the communication session.

SendPIN (SID 03)

This message is issued by the ITS Unit to be whitelisted from the VU interface. The content of this message is a 4 INTEGER between 0 and 9 code.

PairingResult (SID 04)

This message is issued by the VU Interface to inform the ITS Unit if the PIN code it sent was correct. The content of this message shall be a BOOLEAN with the value ‘True’ if the PIN code was correct and ‘False’ otherwise.

SendPUC (SID 05)

This message is issued by the ITS Unit to lift a blacklist sanction from the VU interface. The content of this message is a 8 INTEGER between 0 and 9 code.

BanLiftingResult (SID 06)

This message is issued by the VU Interface to inform the ITS Unit if the PUC code it sent was correct. The content of this message shall be a BOOLEAN with the value ‘True’ if the PUC code was correct and ‘False’ otherwise.

RequestRejected (SID 07)

This message is issued by the VU Interface as a reply to any message from a blacklisted ITS Unit except ‘SendPUC’. The message shall contain the remaining time the ITS Unit is blacklisted, following the ‘Time’ sequence format as defined in Annex 3.

RequestData (SID 08)

This message for data accessing is issued by the ITS Unit. A one byte transfer request parameter (TRTP) indicates the type of data required. There are several types of data:

standardTachData (TRTP 01): Data available from the tachograph classified as non-personal.
personalTachData (TRTP 02): Data available from the tachograph classified as personal.
gnssData (TRTP 03): GNSS data, always personal.
standardEventData (TRTP 04): Recorded event data classified as non-personal.
personalEventData (TRTP 05): Recorded event data classified as personal.
standardFaultData (TRTP 06): Recorded faults classified as non-personal.
manufacturerData (TRTP 07): data made available by the manufacturer.

See Annex 3 of this appendix for more information about the content of each data type.

See Appendix 12 for more information about the format and content of GNSS data.

See Annex IB and IC for more information about event data code and faults.

ResquestAccepted (SID 09)

This message is issued by the VU Interface if a ITS Unit ‘RequestData’ message has been accepted. This message contains a 1-byte TREP, which is the TRTP byte of the associated RequestData message, and all the data of the requested type.

DataUnavailable (SID 0A)

This message is issued by the VU Interface if, for a certain reason, the requested data aren't available to be sent to a whitelisted ITS Unit. The message contains a 1byte TREP which is the TRTP of the required data and a 1 byte error code specified in the table 3. The Following codes are available:

No data available (10): The VU interface can't access the VU data for unspecified reasons.
Personal data not shared (11): The ITS Unit tries to retrieve personal data when they are not shared.

NegativeAnswer (SID 0B)

These messages are issued by the VU Interface if a request cannot be completed for any other reason than the unavailability of the data. These messages are typically the result of a bad request format (Length, SID, ITSID…) but aren't limited to that. The TRTP in the Data Field contains the SID of the request. The Data Field contains a code identifying the reason of the negative answer. The following codes are available:

General Reject (code: 10)
The action can't be performed for a reason which isn't cited below nor in section (Enter DataUnavailable section number).
Service not supported (code: 11)
The request's SID isn't understood.
Sub function not supported (code: 12)
The request's TRTP isn't understood. It can be for instance missing or out of accepted values.
Incorrect message length (code: 13)
The length of the received message is wrong (mismatch between the LEN byte and the actual message length).
Conditions not correct or request sequence error (code: 22)
The required service is not active or the sequence of request messages is not correct
Request out of range (code: 33)
The request parameter record (data field) is not valid
Response pending (code: 78)
The action requested cannot be completed in time and the VU is not ready to accept another request.
ITSID Mismatch (code: FB)
The SRC ITSID doesn't match the associated device after comparison with the Bluetooth information.
ITSID Not Found (code: FC)
The SRC ITSID isn't associated with any device.

Lines 1 through 72 (FormatMessageModule) of the ASN.1 code in Annex 3 specify the messages format as described in table 3. More details about the messages content is given below.

4.5.Driver consent

All the data available are classified as either standard or personal. Personal data shall only be accessible if the driver gave his/her consent, accepting his/her tachograph personal data can leave the vehicle network for third party applications.

Driver consent is given when, at first insertion of a given driver card or workshop card currently unknown to the vehicle unit, the cardholder is invited to express his consent for tachograph related personal data output through the optional ITS interface. (see also Annex I C paragraph 3.6.2).

The consent status (enabled/disabled) is recorded in the memory of the tachograph.

In case of multiple drivers, only the personal data about the drivers who gave their consent shall be shared with the ITS interface. For instance, if there's two drivers in the vehicle, and only the first driver accepted to share his personal data, the ones concerning the second driver shall not be shared.

4.6.Standard data retrieval

Figure 3 of Annex 2 represents the sequence diagrams of a valid request sent by the ITS Unit to access standard data. The ITS Unit is properly whitelisted and isn't requesting personal data, no further verification is required. The diagrams consider the proper procedure illustrated in Figure 2 of Annex 2 has already been followed. They can be equated to the REQUEST TREATMENT gray box of Figure 2.

Amongst available data, shall be considered standard:

standardTachData (TRTP 01)
StandardEventData (TRTP 04)
standardFaultData (TRTP 06)

4.7.Personal data retrieval

Figure 4 of Annex 2 represents the sequence diagram for personal data request processing. As previously stated, the VU interface shall only send personal data if the driver has given his explicit consent (see also 4.5). Otherwise, the request must be automatically rejected.

Amongst available data, shall be considered personal:

personalTachData (TRTP 02)
gnssData (TRTP 03)
personalEventData (TRTP 05)
manufacturerData (TRTP 07)

4.8.Event and fault data retrieval

ITS units shall be able to request events data containing the list of all the unexpected events. These data are considered standard or personal, see Annex 3. The content of each event is in accordance with the documentation provided in Annex 1 of this appendix.

ANNEX 1

F1(1)LIST OF AVAILABLE DATA THROUGH THE ITS INTERFACE

Data	Source	Data classification (personal/not personal)
VehicleIdentificationNumber	Vehicle Unit	not personal
CalibrationDate	Vehicle Unit	not personal
TachographVehicleSpeed speed instant t	Vehicle Unit	personal
Driver1WorkingState Selector driver	Vehicle Unit	personal
Driver2WorkingState	Vehicle Unit	personal
DriveRecognize Speed Threshold detected	Vehicle Unit	not personal
Driver1TimeRelatedStates Weekly day time	Driver Card	personal
Driver2TimeRelatedStates	Driver Card	personal
DriverCardDriver1	Vehicle Unit	not personal
DriverCardDriver2	Vehicle Unit	not personal
OverSpeed	Vehicle Unit	personal
TimeDate	Vehicle Unit	not personal
HighResolutionTotalVehicleDistance	Vehicle Unit	not personal
ServiceComponentIdentification	Vehicle Unit	not personal
ServiceDelayCalendarTimeBased	Vehicle Unit	not personal
Driver1Identification	Driver Card	personal
Driver2Identification	Driver Card	personal
NextCalibrationDate	Vehicle Unit	not personal
Driver1ContinuousDrivingTime	Driver Card	personal
Driver2ContinuousDrivingTime	Driver Card	personal
Driver1CumulativeBreakTime	Driver Card	personal
Driver2CumulativeBreakTime	Driver Card	personal
Driver1CurrentDurationOfSelectedActivity	Driver Card	personal
Driver2CurrentDurationOfSelectedActivity	Driver Card	personal
SpeedAuthorised	Vehicle Unit	not personal
TachographCardSlot1	Driver Card	not personal
TachographCardSlot2	Driver Card	not personal
Driver1Name	Driver Card	personal
Driver2Name	Driver Card	personal
OutOfScopeCondition	Vehicle Unit	not personal
ModeOfOperation	Vehicle Unit	not personal
Driver1CumulatedDrivingTimePreviousAndCurrentWeek	Driver Card	personal
Driver2CumulatedDrivingTimePreviousAndCurrentWeek	Driver Card	personal
EngineSpeed	Vehicle Unit	personal
RegisteringMemberState	Vehicle Unit	not personal
VehicleRegistrationNumber	Vehicle Unit	not personal
Driver1EndOfLastDailyRestPeriod	Driver Card	personal
Driver2EndOfLastDailyRestPeriod	Driver Card	personal
Driver1EndOfLastWeeklyRestPeriod	Driver Card	personal
Driver2EndOfLastWeeklyRestPeriod	Driver Card	personal
Driver1EndOfSecondLastWeeklyRestPeriod	Driver Card	personal
Driver2EndOfSecondLastWeeklyRestPeriod	Driver Card	personal
Driver1CurrentDailyDrivingTime	Driver Card	personal
Driver2CurrentDailyDrivingTime	Driver Card	personal
Driver1CurrentWeeklyDrivingTime	Driver Card	personal
Driver2CurrentWeeklyDrivingTime	Driver Card	personal
Driver1TimeLeftUntilNewDailyRestPeriod	Driver Card	personal
Driver2TimeLeftUntilNewDailyRestPeriod	Driver Card	personal
Driver1CardExpiryDate	Driver Card	personal
Driver2CardExpiryDate	Driver Card	personal
Driver1CardNextMandatoryDownloadDate	Driver Card	personal
Driver2CardNextMandatoryDownloadDate	Driver Card	personal
TachographNextMandatoryDownloadDate	Vehicle Unit	not personal
Driver1TimeLeftUntilNewWeeklyRestPeriod	Driver Card	personal
Driver2TimeLeftUntilNewWeeklyRestPeriod	Driver Card	personal
Driver1NumberOfTimes9hDailyDrivingTimesExceeded	Driver Card	personal
Driver2NumberOfTimes9hDailyDrivingTimesExceeced	Driver Card	personal
Driver1CumulativeUninterruptedRestTime	Driver Card	personal
Driver2CumulativeUninterruptedRestTime	Driver Card	personal
Driver1MinimumDailyRest	Driver Card	personal
Driver2MinimumDailyRest	Driver Card	personal
Driver1MinimumWeeklyRest	Driver Card	personal
Driver2MinimumWeeklyRest	Driver Card	personal
Driver1MaximumDailyPeriod	Driver Card	personal
Driver2MaximumDailyPeriod	Driver Card	personal
Driver1MaximumDailyDrivingTime	Driver Card	personal
Driver2MaximumDailyDrivingTime	Driver Card	personal
Driver1NumberOfUsedReducedDailyRestPeriods	Driver Card	personal
Driver2NumberOfUsedReducedDailyRestPeriods	Driver Card	personal
Driver1RemainingCurrentDrivingTime	Driver Card	personal
Driver2RemainingCurrentDrivingTime	Driver Card	personal
GNSS position	Vehicle Unit	personal

(2)CONTINUOUS GNSS DATA AVAILABLE AFTER DRIVER CONSENT

See Appendix 12 — GNSS.

(3)EVENT CODES AVAILABLE WITHOUT DRIVER CONSENT

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.
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.
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.
F2Communication 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.
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.
Time conflict	the longest event for each of the 10 last days of occurrence, the 5 longest 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.

(4)EVENT CODES AVAILABLE WITH DRIVER CONSENT

Event	Storage rules	Data to be recorded per event
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
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.

(5)FAULT DATA CODES AVAILABLE WITHOUT DRIVER CONSENT

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.