Commission Implementing Regulation (EU) 2016/799Show full title

4. INTERFACE WORKING PRINCIPLES U.K.

4.1. Preconditions to data transfer via the ITS interface U.K.

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.1 Data provided through the ITS interface U.K.

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.2 Content of the Data U.K.

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

4.1.3 ITS Applications U.K.

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

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.

[F1 When 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.]

Textual Amendments

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

The overall communication principle is described in the following figure.

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

[F1 For 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 1

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

[F1 While 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 U.K.

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 2

General message format

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

Header U.K.

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

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

[F1 If 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 3

Detailed message content

Message	Header			DATA			Checksum
	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) U.K.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.