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.

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

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.

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.

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

Shall be transmitted as such:

…

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.