{
  "url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-13",
  "json_url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-13.json",
  "legislation": "eur/2016/799",
  "legislation_title": "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)",
  "legislation_url": "https://openlegislation.uk/eu-regulation-2016-799",
  "path": "annex/1/appendix/13",
  "kind": "appendix",
  "number": "13",
  "heading": null,
  "text": "ITS INTERFACE\n1.\nINTRODUCTION\nThis 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).\nThe 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:\n(a)the interface does not affect the authenticity and the integrity of the data of the tachograph;\n(b)the interface complies with the detailed provisions of Article 11 of the Regulation;\n(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.\n2.\nSCOPE\nThe 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.\nThe 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.\nThis Appendix specifies:\nThe Data available through the ITS interface\nThe Bluetooth® profile that is used to transfer the data\nThe enquiry and download procedures and sequence of operations\nThe pairing mechanism between the tachograph and the external device\nThe consent mechanism available to the driver\nFor clarification, this Appendix does not specify:\nThe 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).\nThe form of presentation of collected data to application hosted on the external device.\nData 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]).\nThe Bluetooth® protocols used by the ITS interface\n2.1.\nAcronyms, definitions and notations\nThe following acronyms and definitions specific to this Appendix are used in this appendix:\nthe Communicationexchange of information/data between a master unit (i.e. the tachographs) and an external unit through the ITS interface over Bluetooth®.\nthe DataData sets as specified in Annex 1.\nthe RegulationRegulation (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\nBRBasic Rate\nEDREnhanced Data Rate\nGNSSGlobal Navigation Satellite System\nIRKIdentity Resolution Key\nITSIntelligent Transport System\nLELow Energy\nPINPersonal Identification Number\nPUCPersonal Unblocking Code\nSIDService Identifier\nSPPSerial Port Profile\nSSPSecure Simple Pairing\nTRTPTransfer Request Parameter\nTREPTransfer Response Parameter\nVUVehicle Unit\n3.\nREFERENCED REGULATIONS AND STANDARDS\nThe 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.\nRegulations and standards referenced in this Appendix are:\nRegulation (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.\nRegulation (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.\nISO 16844 — 4: Road vehicles — Tachograph systems — Part 4: Can interface\nISO 16844 — 7: Road vehicles — Tachograph systems — Part 7: Parameters\nBluetooth® — Serial Port Profile — V1.2\nBluetooth® — Core Version 4.2\nNMEA 0183 V4.1 protocol\n4.\nINTERFACE WORKING PRINCIPLES\n4.1.\nPreconditions to data transfer via the ITS interface\nThe 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.\n4.1.1\nData provided through the ITS interface\nThe 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.\n4.1.2\nContent of the Data\nThe content of the Data shall be as specified in Annex 1 of this appendix.\n4.1.3\nITS Applications\nITS 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.\n4.2.\nCommunication technology\nThe 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).\nThe 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.\nWhen 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.\nThe overall communication principle is described in the following figure.\nThe SPP (Serial Port Profile) profile of Bluetooth® shall be used to transfer data from the VU to the external device.\n4.3.\nPIN authorization\nFor 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.\nSucceeding 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.\nFailing 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.\nTable 1\nBan duration depending on the number of consecutive failure to provide the correct PIN code\nNumber of consecutive failure\nBan duration\n3\n30 seconds\n6\n5 minutes\n9\n1 hour\n12\n24 hours\n15\nPermanent\nFailing 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.\nThe 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.\nWhile 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.\nFurthermore 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.\nThe 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).\nAny 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.\n4.4.\nMessage Format\nAll 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).\nThe data field composed by a service identifier byte (SID) and a variable amount of data bytes (maximum 255).\nThe checksum byte is the 1 byte sum series modulo 256 of all the bytes of the message excluding the CS itself.\nThe message shall be Big Endian.\nTable 2\nGeneral message format\nHeader\nData Field\nChecksum\nTGT\nSRC\nLEN\nSID\nTRTP\nCC\nCM\nDATA\nCS\n3 bytes\nMax. 255 bytes\n1 byte\nHeader\nTGT 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.\nThe LEN byte shall only take into account the ‘DATA’ part of the Data Field (see Table 2), the 4 first bytes are implicit.\nThe 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.\nData Field\nBesides the SID, the Data Field shall also contain other parameters: a transfer request parameter (TRTP) and Counter bytes.\nIf 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.\nIf not used, CC and CM shall be given the value 0xFF.\nFor instance, the following message\nHEADER\nSID\nTRTP\nCC\nCM\nDATA\nCS\n3 bytes\nLonger than 255 bytes\n1 byte\nShall be transmitted as such:\nHEADER\nSID\nTRTP\n01\nn\nDATA\nCS\n3 bytes\n255 bytes\n1 byte\nHEADER\nSID\nTRTP\n02\nn\nDATA\nCS\n3 bytes\n255 bytes\n1 byte\n…\nHEADER\nSID\nTRTP\nN\nN\nDATA\nCS\n3 bytes\nMax. 255 bytes\n1 byte\nTable 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.\nTable 3\nDetailed message content\nMessage\nHeader\nDATA\nChecksum\nTGT\nSRC\nLEN\nSID\nTRTP\nDATA\nRequestPIN\nITSID\nEE\n00\n01\nFF\nSendITSID\nITSID\nEE\n01\n02\nFF\nITSID\nSendPIN\nEE\nITSID\n04\n03\nFF\n4*INTEGER (0..9)\nPairingResult\nITSID\nEE\n01\n04\nFF\nBOOLEAN (T/F)\nSendPUC\nEE\nITSID\n08\n05\nFF\n8*INTEGER (0..9)\nBanLiftingResult\nITSID\nEE\n01\n06\nFF\nBOOLEAN (T/F)\nRequestRejected\nITSID\nEE\n08\n07\nFF\nTime\nRequestData\nstandardTachData\nEE\nITSID\n01\n08\n01\npersonalTachData\nEE\nITSID\n01\n08\n02\ngnssData\nEE\nITSID\n01\n08\n03\nstandardEventData\nEE\nITSID\n01\n08\n04\npersonalEventData\nEE\nITSID\n01\n08\n05\nstandardFaultData\nEE\nITSID\n01\n08\n06\nmanufacturerData\nEE\nITSID\n01\n08\n07\nResquestAccepted\nITSID\nEE\nLen\n09\nTREP\nData\nDataUnavailable\nNo data available\nITSID\nEE\n02\n0A\nTREP\n10\nPersonal data not shared\nITSID\nEE\n02\n0A\nTREP\n11\nNegativeAnswer\nGeneral reject\nITSID\nEE\n02\n0B\nSID Req\n10\nService not supported\nITSID\nEE\n02\n0B\nSID Req\n11\nSub function not supported\nITSID\nEE\n02\n0B\nSID Req\n12\nIncorrect message length\nITSID\nEE\n02\n0B\nSID Req\n13\nConditions not correct or request sequence error\nITSID\nEE\n02\n0B\nSID Req\n22\nRequest out of range\nITSID\nEE\n02\n0B\nSID Req\n31\nResponse pending\nITSID\nEE\n02\n0B\nSID Req\n78\nITSID Mismatch\nITSID\nEE\n02\n0B\nSID Req\nFC\nITSID Not Found\nITSID\nEE\n02\n0B\nSID Req\nFB\nRequestPIN (SID 01)\nThis message is issued by the VU Interface if a non-blacklisted but non-whitelisted ITS unit is sending any data request.\nSendITSID (SID 02)\nThis 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.\nSendPIN (SID 03)\nThis 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.\nPairingResult (SID 04)\nThis 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.\nSendPUC (SID 05)\nThis 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.\nBanLiftingResult (SID 06)\nThis 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.\nRequestRejected (SID 07)\nThis 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.\nRequestData (SID 08)\nThis 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:\nstandardTachData (TRTP 01): Data available from the tachograph classified as non-personal.\npersonalTachData (TRTP 02): Data available from the tachograph classified as personal.\ngnssData (TRTP 03): GNSS data, always personal.\nstandardEventData (TRTP 04): Recorded event data classified as non-personal.\npersonalEventData (TRTP 05): Recorded event data classified as personal.\nstandardFaultData (TRTP 06): Recorded faults classified as non-personal.\nmanufacturerData (TRTP 07): data made available by the manufacturer.\nSee Annex 3 of this appendix for more information about the content of each data type.\nSee Appendix 12 for more information about the format and content of GNSS data.\nSee Annex IB and IC for more information about event data code and faults.\nResquestAccepted (SID 09)\nThis 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.\nDataUnavailable (SID 0A)\nThis 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:\nNo data available (10): The VU interface can't access the VU data for unspecified reasons.\nPersonal data not shared (11): The ITS Unit tries to retrieve personal data when they are not shared.\nNegativeAnswer (SID 0B)\nThese 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:\nGeneral Reject (code: 10)\nThe action can't be performed for a reason which isn't cited below nor in section (Enter DataUnavailable section number).\nService not supported (code: 11)\nThe request's SID isn't understood.\nSub function not supported (code: 12)\nThe request's TRTP isn't understood. It can be for instance missing or out of accepted values.\nIncorrect message length (code: 13)\nThe length of the received message is wrong (mismatch between the LEN byte and the actual message length).\nConditions not correct or request sequence error (code: 22)\nThe required service is not active or the sequence of request messages is not correct\nRequest out of range (code: 33)\nThe request parameter record (data field) is not valid\nResponse pending (code: 78)\nThe action requested cannot be completed in time and the VU is not ready to accept another request.\nITSID Mismatch (code: FB)\nThe SRC ITSID doesn't match the associated device after comparison with the Bluetooth information.\nITSID Not Found (code: FC)\nThe SRC ITSID isn't associated with any device.\nLines 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.\n4.5.\nDriver consent\nAll 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.\nDriver 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).\nThe consent status (enabled/disabled) is recorded in the memory of the tachograph.\nIn 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.\n4.6.\nStandard data retrieval\nFigure 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.\nAmongst available data, shall be considered standard:\nstandardTachData (TRTP 01)\nStandardEventData (TRTP 04)\nstandardFaultData (TRTP 06)\n4.7.\nPersonal data retrieval\nFigure 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.\nAmongst available data, shall be considered personal:\npersonalTachData (TRTP 02)\ngnssData (TRTP 03)\npersonalEventData (TRTP 05)\nmanufacturerData (TRTP 07)\n4.8.\nEvent and fault data retrieval\nITS 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.",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "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)."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/2016/799/annex/1/appendix/13",
    "retrieved_at": "2026-11-01T14:45:49.686558+00:00"
  },
  "licence": "Open Government Licence v3.0",
  "licence_url": "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/",
  "attribution": "Contains public sector information licensed under the Open Government Licence v3.0. Source: legislation.gov.uk, The National Archives."
}