{
  "url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-7",
  "json_url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-7.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/7",
  "kind": "appendix",
  "number": "7",
  "heading": null,
  "text": "DATA DOWNLOADING PROTOCOLS\n1.\nINTRODUCTION\nThis appendix specifies the procedures to follow in order to perform the different types of data download to an External Storage Medium, together with the protocols that must be implemented to assure the correct data transfer and the full compatibility of the downloaded data format to allow any controller to inspect these data and be able to control their authenticity and their integrity before analysing them.\n1.1.\nScope\nData may be downloaded to an ESM:\nfrom a Vehicle Unit by an Intelligent Dedicated Equipment (IDE) connected to the VU,\nfrom a tachograph card by an IDE fitted with a card interface device (IFD),\nfrom a tachograph card via a vehicle unit by an IDE connected to the VU.\nTo give the possibility to verify the authenticity and integrity of downloaded data stored on an ESM, data is downloaded with a signature appended in accordance with Appendix 11 Common Security Mechanisms. The source equipment (VU or card) identification and its security certificates (Member state and equipment) are also downloaded. The verifier of the data must possess independently a trusted European public key.\nData downloaded from a VU are signed using Appendix 11 Common Security Mechanisms Part B (Second-generation tachograph system), except when drivers' control is performed by a non EU control authority, using a first generation control card, in which case data are signed using Appendix 11 Common Security Mechanisms Part A (First-generation tachograph system), as requested by Appendix 15 Migration, requirement MIG_015.\nThis Appendix specifies therefore two types of data downloads from the VU:\nGeneration 2 type of VU data download, providing the generation 2 data structure, signed using Appendix 11 Common Security Mechanisms Part B,\nGeneration 1 type of VU data download, providing the generation 1 data structure, signed using Appendix 11 Common Security Mechanisms Part A.\nSimilarly, there are two types of data downloads from second generation driver cards inserted in a VU, as specified in paragraphs 3 and 4 of this Appendix.\n1.2.\nAcronyms and notations\nThe following acronyms are used in this appendix:\nAIDApplication Identifier\nATRAnswer To Reset\nCSChecksum byte\nDFDedicated File\nDS_Diagnostic Session\nEFElementary File\nESMExternal Storage Medium\nFIDFile Identifier (File ID)\nFMTFormat Byte (first byte of message header)\nICCIntegrated Circuit Card\nIDEIntelligent Dedicated Equipment: The equipment used to perform data downloading to the ESM (e.g. Personal Computer)\nIFDInterface Device\nKWPKeyword Protocol 2000\nLENLength Byte (last byte of message header)\nPPSProtocol Parameter Selection\nPSOPerform Security Operation\nSIDService Identifier\nSRCSource byte\nTGTTarget Byte\nTLVTag Length Value\nTREPTransfer Response Parameter\nTRTPTransfer Request Parameter\nVUVehicle Unit\n2.\nV.U. DATA DOWNLOADING\n2.1.\nDownload procedure\nIn order to carry on a VU data download, the operator must perform the following operations:\nInsert his tachograph card inside a card slot of the VU;\nConnect the IDE to the VU download connector;\nEstablish the connection between the IDE and the VU;\nSelect on the IDE the data to download and send the request to the VU;\nClose the download session.\n2.2.\nData download protocol\nThe protocol is structured on a master-slave basis, with the IDE playing the master role and the VU playing the slave role.\nThe message structure, types and flow are principally based on the Keyword Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diagnostic systems — Keyword protocol 2000 — Part2: Data link layer).\nThe application layer is principally based on the current draft to date of ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services, version 6 of 22 February 2001).\n2.2.1\nMessage structure\nDDP_002\nAll the messages exchanged between the IDE and the VU are formatted with a structure consisting of three parts:\nHeader composed by a Format byte (FMT), a Target byte (TGT), a Source byte (SRC) and possibly a Length byte (LEN),\nData field composed by a Service Identifier byte (SID) and a variable number of data bytes, which can include an optional diagnostic session byte (DS_) or an optional transfer parameter byte (TRTP or TREP).\nChecksum composed by a Checksum byte (CS).\nHeader\nData field\nChecksum\nFMT\nTGT\nSRC\nLEN\nSID\nDATA\n…\n…\n…\nCS\n4 bytes\nMax 255 bytes\n1 byte\nThe TGT and SRC byte represent the physical address of the recipient and originator of the message. Values are F0 Hex for the IDE and EE Hex for the VU.\nThe LEN byte is the length of the Data field part.\nThe Checksum byte is the 8 bit sum series modulo 256 of all the bytes of the message excluding the CS itself.\nFMT, SID, DS_, TRTP and TREP bytes are defined later in this document.\nDDP_003\nIn the case where the data to be carried by the message is longer than the space available in the data field part, the message is actually sent in several sub messages. Each sub message bears a header, the same SID, TREP and a 2-byte sub message counter indicating the sub message number within the total message. To enable error checking and abort the IDE acknowledges every sub message. The IDE can accept the sub message, ask for it to be re-transmitted, request the VU to start again or abort the transmission.\nDDP_004\nIf the last sub message contains exactly 255 bytes in the data field, a final sub message with an empty (except SID TREP and sub message counter) data field must be appended to show the end of the message.\nExample:\nHeader\nSID\nTREP\nMessage\nCS\n4 Bytes\nLonger than 255 Bytes\nWill be transmitted as:\nHeader\nSID\nTREP\n00\n01\nSub message 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n02\nSub message 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSub message n\nCS\n4 Bytes\nLess than 255 Bytes\nor as:\nHeader\nSID\nTREP\n00\n01\nSub message 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n02\nSub message 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSub message n\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\nxx\nyy + 1\nCS\n4 Bytes\n4 bytes\n2.2.2\nMessage types\nThe communication protocol for data download between the VU and the IDE requires the exchange of 8 different message types.\nThe following table summarises these messages.\nMessage Structure\nMax 4 Bytes Header\nMax 255 Bytes Data\n1 Byte CheckSum\nIDE ->\n<- VU\nFMT\nTGT\nSRC\nLEN\nSID\nDS_ / TRTP\nDATA\nCS\nStart Communication Request\n81\nEE\nF0\n81\nE0\nPositive Response Start Communication\n80\nF0\nEE\n03\nC1\nEA, 8F\n9B\nStart Diagnostic Session Request\n80\nEE\nF0\n02\n10\n81\nF1\nPositive Response Start Diagnostic\n80\nF0\nEE\n02\n50\n81\n31\nLink Control Service\nVerify Baud Rate (stage 1)\n9 600 Bd\n80\nEE\nF0\n04\n87\n01,01,01\nEC\n19 200 Bd\n80\nEE\nF0\n04\n87\n01,01,02\nED\n38 400 Bd\n80\nEE\nF0\n04\n87\n01,01,03\nEE\n57 600 Bd\n80\nEE\nF0\n04\n87\n01,01,04\nEF\n115 200 Bd\n80\nEE\nF0\n04\n87\n01,01,05\nF0\nPositive Response Verify Baud Rate\n80\nF0\nEE\n02\nC7\n01\n28\nTransition Baud Rate (stage 2)\n80\nEE\nF0\n03\n87\n02,03\nED\nRequest Upload\n80\nEE\nF0\n0A\n35\n00,00,00,00,00,FF,FF,\nFF,FF\n99\nPositive Response Request Upload\n80\nF0\nEE\n03\n75\n00,FF\nD5\nTransfer Data Request\nOverview\n80\nEE\nF0\n02\n36\n01 or 21\n97\nActivities\n80\nEE\nF0\n06\n36\n02 or 22\nDate\nCS\nEvents & Faults\n80\nEE\nF0\n02\n36\n03 or 23\nDate\n99\nDetailed Speed\n80\nEE\nF0\n02\n36\n04 or 24\nDate\n9 A\nTechnical Data\n80\nEE\nF0\n02\n36\n05 or 25\nDate\n9B\nCard download\n80\nEE\nF0\n02\n36\n06\nSlot\nCS\nPositive Response Transfer Data\n80\nF0\nEE\nLen\n76\nTREP\nData\nCS\nRequest Transfer Exit\n80\nEE\nF0\n01\n37\n96\nPositive Response Request Transfer Exit\n80\nF0\nEE\n01\n77\nD6\nStop Communication Request\n80\nEE\nF0\n01\n82\nE1\nPositive Response Stop Communication\n80\nF0\nEE\n01\nC2\n21\nAcknowledge sub message\n80\nEE\nF0\nLen\n83\nData\nCS\nNegative responses\nGeneral reject\n80\nF0\nEE\n03\n7F\nSid Req\n10\nCS\nService not supported\n80\nF0\nEE\n03\n7F\nSid Req\n11\nCS\nSub function not supported\n80\nF0\nEE\n03\n7F\nSid Req\n12\nCS\nIncorrect Message Length\n80\nF0\nEE\n03\n7F\nSid Req\n13\nCS\nConditions not correct or Request sequence error\n80\nF0\nEE\n03\n7F\nSid Req\n22\nCS\nRequest out of range\n80\nF0\nEE\n03\n7F\nSid Req\n31\nCS\nUpload not accepted\n80\nF0\nEE\n03\n7F\nSid Req\n50\nCS\nResponse pending\n80\nF0\nEE\n03\n7F\nSid Req\n78\nCS\nData not available\n80\nF0\nEE\n03\n7F\nSid Req\nFA\nCS\nNotes:\nTRTP 21 to 25 are used for Generation 2 type of VU data download requests, TRTP 01 to 05 are used for Generation 1 type of VU data download requests, which can only be accepted by the VU in the frame of drivers' control performed by a non EU control authority, using a first generation control card.\nTRTP 11 to 19 and 31 to 39 are reserved for manufacturer specific download requests.\nSid Req = the Sid of the corresponding request.\nTREP = the TRTP of the corresponding request.\nDark cells denote that nothing is transmitted.\nThe term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as download (as seen from the VU).\nPotential 2-byte sub message counters are not shown in this table.\nSlot is the slot number, either “1” (card on driver slot) or “2” (card on co-driver slot)\nIn case the slot is not specified, the VU shall select slot 1 if a card is inserted in this slot and it shall select slot 2 only in case it is specifically selected by the user.\n2.2.2.1\nStart Communication Request (SID 81)\nDDP_005\nThis message is issued by the IDE to establish the communication link with the VU. Initial communications are always performed at 9 600 baud (until baud rate is eventually changed using the appropriate Link control services).\n2.2.2.2\nPositive Response Start Communication (SID C1)\nDDP_006\nThis message is issued by the VU to answer positively to a start communication request. It includes the 2 key bytes ‘EA’‘8F’ indicating that the unit supports protocol with header including target source and length information.\n2.2.2.3\nStart Diagnostic Session Request (SID 10)\nDDP_007\nThe Start Diagnostic Session request message is issued by the IDE in order to request a new diagnostic session with the VU. The sub function ‘default session’ (81 Hex) indicates a standard diagnostic session is to be opened.\n2.2.2.4\nPositive Response Start Diagnostic (SID 50)\nDDP_008\nThe Positive Response Start Diagnostic message is sent by the VU to answer positively to Diagnostic Session Request.\n2.2.2.5\nLink Control Service (SID 87)\nDDP_052\nThe Link Control Service is used by the IDE to initiate a change in baud rate. This takes place in two steps. In step one the IDE proposes the baud rate change, indicating the new rate. On receipt of a positive message from the VU the IDE sends out confirmation of the baud rate change to the VU (step two). The IDE then changes to the new baud rate. After receipt of the confirmation the VU changes to the new baud rate\n2.2.2.6\nLink Control Positive Response (SID C7)\nDDP_053\nThe Link Control Positive Response is issued by the VU to answer positively to Link Control Service request (step one). Note that no response is given to the confirmation request (step two).\n2.2.2.7\nRequest Upload (SID 35)\nDDP_009\nThe Request Upload message is issued by the IDE to specify to the VU that a download operation is requested. To meet the requirements of ISO14229 data is included covering address, the size and format details for the data requested. As these are not known to the IDE prior to a download, the memory address is set to 0, format is unencrypted and uncompressed and the memory size is set to the maximum.\n2.2.2.8\nPositive Response Request Upload (SID 75)\nDDP_010\nThe Positive Response Request Upload message is sent by the VU to indicate to the IDE that the VU is ready to download data. To meet the requirements of ISO 14229 data is included in this positive response message, indicating to the IDE that further Positive Response Transfer Data messages will include 00FF hex bytes maximum.\n2.2.2.9\nTransfer Data Request (SID 36)\nDDP_011\nThe Transfer Data Request is sent by the IDE to specify to the VU the type of data that are to be downloaded. A one byte Transfer Request Parameter (TRTP) indicates the type of transfer.\nThere are six types of data transfer. For VU data download, two different TRTP values can be used for each transfer type:\nData transfer type\nTRTP value for generation 1 type of VU data download\nTRTP value for generation 2 type of VU data download\nOverview\n01\n21\nActivities of a specified date\n02\n22\nEvents and faults\n03\n23\nDetailed speed\n04\n24\nTechnical data\n05\n25\nData transfer type\nTRTP value\nCard download\n06\nDDP_054\nIt is mandatory for the IDE to request the overview data transfer (TRTP 01 or 21) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature).\nIn the second case (TRTP 02 or 22) the Transfer Data Request message includes the indication of the calendar day ( format) to be downloaded.\n2.2.2.10\nPositive Response Transfer Data (SID 76)\nDDP_012\nThe Positive Response Transfer Data is sent by the VU in response to the Transfer Data Request. The message contains the requested data, with a Transfer Response Parameter (TREP) corresponding to the TRTP of the request.\nDDP_055\nIn the first case (TREP 01 or 21), the VU will send data helping the IDE operator to choose the data he wants to download further. The information contained within this message is:\nSecurity certificates,\nVehicle identification,\nVU current date and time,\nMin and Max downloadable date (VU data),\nIndication of cards presence in the VU,\nPrevious download to a company,\nCompany locks,\nPrevious controls.\n2.2.2.11\nRequest Transfer Exit (SID 37)\nDDP_013\nThe Request Transfer Exit message is sent by the IDE to inform the VU that the download session is terminated.\n2.2.2.12\nPositive Response Request Transfer Exit (SID 77)\nDDP_014\nThe Positive Response Request Transfer Exit message is sent by the VU to acknowledge the Request Transfer Exit.\n2.2.2.13\nStop Communication Request (SID 82)\nDDP_015\nThe Stop Communication Request message is sent by the IDE to disconnect the communication link with the VU.\n2.2.2.14\nPositive Response Stop Communication (SID C2)\nDDP_016\nThe Positive Response Stop Communication message is sent by the VU to acknowledge the Stop Communication Request.\n2.2.2.15\nAcknowledge Sub Message (SID 83)\nDDP_017\nThe Acknowledge Sub Message is sent by the IDE to confirm receipt of each part of a message that is being transmitted as several sub messages. The data field contains the SID received from the VU and a 2-byte code as follows:\nMsgC+1 Acknowledges correct receipt of sub message number MsgC.\nRequest from the IDE to the VU to send next sub message\nMsgC indicates a problem with the receipt of sub message number MsgC.\nRequest from the IDE to the VU to send the sub message again.\nFFFF requests termination of the message.\nThis can be used by the IDE to end the transmission of the VU message for any reason.\nThe last sub message of a message (LEN byte < 255) may be acknowledged using any of these codes or not acknowledged.\nThe VU responses that will consist of several sub messages are:\nPositive Response Transfer Data (SID 76)\n2.2.2.16\nNegative Response (SID 7F)\nDDP_018\nThe Negative Response message is sent by the VU in response to the above request messages when the VU cannot satisfy the request. The data fields of the message contains the SID of the response (7F), the SID of the request, and a code specifying the reason of the negative response. The following codes are available:\n10 general reject\nThe action cannot be performed for a reason not covered below.\n11 service not supported\nThe SID of the request is not understood.\n12 sub function not supported\nThe DS_ or TRTP of the request is not understood, or there are no further sub messages to be transmitted.\n13 incorrect message length\nThe length of the received message is wrong.\n22 conditions not correct or request sequence error\nThe required service is not active or the sequence of request messages is not correct.\n31 Request out of range\nThe request parameter record (data field) is not valid.\n50 upload not accepted\nThe request cannot be performed (VU in a non appropriate mode of operation or internal fault of the VU).\n78 response pending\nThe action requested cannot be completed in time and the VU is not ready to accept another request.\nFA data not available\nThe data object of a data transfer request are not available in the VU (e.g. no card is inserted, generation 1 type of VU data download requested outside the frame of a driver’s control by a non EU control authority…).\n2.2.3\nMessage flow\nA typical message flow during a normal data download procedure is the following:\nIDE\nVU\nStart Communication Request\n⇨\n⇦\nPositive Response\nStart Diagnostic Service Request\n⇨\n⇦\nPositive Response\nRequest Upload\n⇨\n⇦\nPositive Response\nTransfer Data Request Overview\n⇨\n⇦\nPositive Response\nTransfer Data Request #2\n⇨\n⇦\nPositive Response #1\nAcknowledge Sub Message #1\n⇨\n⇦\nPositive Response #2\nAcknowledge Sub Message #2\n⇨\n⇦\nPositive Response #m\nAcknowledge Sub Message #m\n⇨\n⇦\nPositive Response (Data Field < 255 Bytes)\nAcknowledge Sub Message (optional)\n⇨\n…\nTransfer Data Request #n\n⇨\n⇦\nPositive Response\nRequest Transfer Exit\n⇨\n⇦\nPositive Response\nStop Communication Request\n⇨\n⇦\nPositive Response\n2.2.4\nTiming\nDDP_019\nDuring normal operation the timing parameters shown in the following figure are relevant:\nFigure 1\nMessage flow, timing\nWhere:\nP1Inter byte time for VU response.\nP2Time between end of IDE request and start of VU response, or between end of IDE acknowledge and start of next VU response.\nP3Time between end of VU response and start of new IDE request, or between end of VU response and start of IDE acknowledge, or between end of IDE request and start of new IDE request if VU fails to respond.\nP4Inter byte time for IDE request.\nP5Extended value of P3 for card downloading.\nThe allowed values for the timing parameters are showed in the following table (KWP extended timing parameters set, used in case of physical addressing for faster communication).\nIf the VU responds with a Negative Response containing a code meaning ‘request correctly received, response pending’, this value is extended to the same upper limit value of P3.\nTiming Parameter\nLower limitValue (ms)\nUpper limitValue (ms)\nP1\n0\n20\nP2\n20\n1 000\nP3\n10\n5 000\nP4\n5\n20\nP5\n10\n20 minutes\n2.2.5\nError handling\nIf an error occurs during the message exchange, the message flow scheme is modified depending on which equipment has detected the error and on the message generating the error.\nIn figure 2 and figure 3 the error handling procedures for the VU and the IDE are respectively shown.\n2.2.5.1\nStart Communication phase\nDDP_020\nIf the IDE detects an error during the Start Communication phase, either by timing or by the bit stream, then it will wait for a period P3 min before issuing again the request.\nDDP_021\nIf the VU detects an error in the sequence coming from the IDE, it shall send no response and wait for another Start Communication Request message within a period P3 max.\n2.2.5.2\nCommunication phase\nTwo different error handling areas can be defined:\n1..The VU detects an IDE transmission error.\nDDP_022For every received message the VU shall detect timing errors, byte format errors (e.g. start and stop bit violations) and frame errors (wrong number of bytes received, wrong checksum byte).\nDDP_023If the VU detects one of the above errors, then it sends no response and ignores the message received.\nDDP_024The VU may detect other errors in the format or content of the received message (e.g. message not supported) even if the message satisfies the length and checksum requirements; in such a case, the VU shall respond to the IDE with a Negative Response message specifying the nature of the error.\nFigure 2\nVU error handling\n2..The IDE detects a VU transmission error.\nDDP_025For every received message the IDE shall detect timing errors, byte format errors (e.g. start and stop bit violations) and frame errors (wrong number of bytes received, wrong checksum byte).\nDDP_026The IDE shall detect sequence errors, e.g. incorrect sub message counter increments in successive received messages.\nDDP_027If the IDE detects an error or there was no response from the VU within a P2 max period, the request message will be sent again for a maximum of three transmissions in total. For the purposes of this error detection a sub message acknowledge will be considered as a request to the VU.\nDDP_028The IDE shall wait at least for a period of P3 min before beginning each transmission; the wait period shall be measured from the last calculated occurrence of a stop bit after the error was detected.\nFigure 3\nIDE error handling\n2.2.6\nResponse Message content\nThis paragraph specifies the content of the data fields of the various positive response messages.\nData elements are defined in Appendix 1 data dictionary.\nRemark: For generation 2 downloads, each top-level data element is represented by a record array, even if it contains only one record. A record array starts with a header; this header contains the record type, the record size and the number of records. Record arrays are named by ‘…RecordArray’ (with header) in the following tables.\n2.2.6.1\nPositive Response Transfer Data Overview\nDDP_029\nThe data field of the ‘Positive Response Transfer Data Overview’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 01 or 21 Hex and appropriate sub message splitting and counting:\nData structure generation 1 (TREP 01 Hex)\nData element\nComment\nVU Security certificates\nVehicle identification\nVU current date and time\nDownloadable period\nType of cards inserted in the VU\nPrevious VU download\nAll company locks stored. If the section is empty, only noOfLocks = 0 is sent.\nAll control records stored in the VU. If the section is empty, only noOfControls = 0 is sent\nRSA signature of all data (except certificates) starting from VehicleIdentificationNumber down to last byte of last VuControlActivityData.\nData structure generation 2 (TREP 21 Hex)\nData element\nComment\nMember state certificate\nVU certificate\nVehicle identification\nVehicle registration number\nVU current date and time\nDownloadable period\nType of cards inserted in the VU\nPrevious VU download\nAll company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent\nAll control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent\nECC signature of all preceding data except the certificates.\n2.2.6.2\nPositive Response Transfer Data Activities\nDDP_030\nThe data field of the ‘Positive Response Transfer Data Activities’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 02 or 22 Hex and appropriate sub message splitting and counting:\nData structure generation 1 (TREP 02 Hex)\nData element\nComment\nDate of day downloaded\nOdometer at end of downloaded day\nCards insertion withdrawal cycles data.\nIf this section contains no available data, only noOfVuCardIWRecords = 0 is sent.\nWhen a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.\nSlots status at 00:00 and activity changes recorded for the day downloaded.\nPlaces related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.\nSpecific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent\nRSA signature of all data starting from TimeReal down to last byte of last specific condition record.\nData structure generation 2 (TREP 22 Hex)\nData element\nComment\nDate of day downloaded\nOdometer at end of downloaded day\nCards insertion withdrawal cycles data.\nIf this section contains no available data, an array header with noOfRecords = 0 is sent.\nWhen a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.\nSlots status at 00:00 and activity changes recorded for the day downloaded.\nPlaces related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.\nGNSS positions of the vehicle when the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent.\nSpecific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent\nECC signature of all preceding data.\n2.2.6.3\nPositive Response Transfer Data Events and Faults\nDDP_031\nThe data field of the ‘Positive Response Transfer Data Events and Faults’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 03 or 23 Hex and appropriate sub message splitting and counting:\nData structure generation 1 (TREP 03 Hex)\nData element\nComment\nAll faults stored or on-going in the VU.\nIf the section is empty, only noOfVuFaults = 0 is sent.\nAll events (except over speeding) stored or on-going in the VU.\nIf the section is empty, only noOfVuEvents = 0 is sent.\nData related to last over speeding control (default value if no data).\nAll over speeding events stored in the VU.\nIf the section is empty, only noOfVuOverSpeedingEvents = 0 is sent.\nAll time adjustment events stored in the VU (outside the frame of a full calibration).\nIf the section is empty, only noOfVuTimeAdjRecords = 0 is sent.\nRSA signature of all data starting from noOfVuFaults down to last byte of last time adjustment record\nData structure generation 2 (TREP 23 Hex)\nData element\nComment\nAll faults stored or on-going in the VU.\nIf the section is empty, an array header with noOfRecords = 0 is sent.\nAll events (except over speeding) stored or on-going in the VU.\nIf the section is empty, an array header with noOfRecords = 0 is sent.\nData related to last over speeding control (default value if no data).\nAll over speeding events stored in the VU.\nIf the section is empty, an array header with noOfRecords = 0 is sent.\nAll time adjustment events stored in the VU (outside the frame of a full calibration).\nIf the section is empty, an array header with noOfRecords = 0 is sent.\nECC signature of all preceding data.\n2.2.6.4\nPositive Response Transfer Data Detailed Speed\nDDP_032\nThe data field of the ‘Positive Response Transfer Data Detailed Speed’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 04 or 24 Hex and appropriate sub message splitting and counting:\nData structure generation 1 (TREP 04)\nData element\nComment\nAll detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving)\n60 speed values per minute (one per second).\nRSA signature of all data starting from noOfSpeedBlocks down to last byte of last speed block.\nData structure generation 2 (TREP 24)\nData element\nComment\nAll detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving)\n60 speed values per minute (one per second).\nECC signature of all preceding data.\n2.2.6.5\nPositive Response Transfer Data Technical Data\nDDP_033\nThe data field of the ‘Positive Response Transfer Data Technical Data’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 05 or 25 Hex and appropriate sub message splitting and counting:\nData structure generation 1 (TREP 05)\nData element\nComment\nAll calibration records stored in the VU.\nRSA signature of all data starting from vuManufacturerName down to last byte of last VuCalibrationRecord.\nData structure generation 2 (TREP 25)\nData element\nComment\nAll MS pairings stored in the VU\nAll external GNSS facility couplings stored in the VU\nAll calibration records stored in the VU.\nAll card insertion data stored in the VU.\nECC signature of all preceding data.\n2.3.\nESM File storage\nDDP_034\nWhen a download session has included a VU data transfer, the IDE shall store within one single physical file all data received from the VU during the download session within Positive Response Transfer Data messages. Data stored excludes message headers, sub-message counters, empty sub-messages and checksums but include the SID and TREP (of the first sub-message only if several sub-messages).\n3.\nTACHOGRAPH CARDS DOWNLOADING PROTOCOL\n3.1.\nScope\nThis paragraph describes the direct card data downloading of a tachograph card to an IDE. The IDE is not part of the secure environment; therefore no authentication between the card and the IDE is performed.\n3.2.\nDefinitions\nDownload sessionEach time a download of the ICC data is performed. The session covers the complete procedure from the reset of the ICC by an IFD until the deactivation of the ICC (withdraw of the card or next reset).\nSigned Data FileA file from the ICC. The file is transferred to the IFD in plain text. On the ICC the file is hashed and signed and the signature is transferred to the IFD.\n3.3.\nCard Downloading\nDDP_035\nThe download of a tachograph card includes the following steps:\nDownload the common information of the card in the EFs and This information is optional and is not secured with a digital signature.\n(for first and second generation tachograph cards) Download EFs within :\nDownload the EFs and This information is not secured with a digital signature.\nIt is mandatory to download these files for each download session.\nDownload the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part A.\nIt is mandatory to download at least the EFs and for each download session.\nWhen downloading a driver card it is also mandatory to download the following EFs:\n(for second generation tacograph cards only) Except when a download of a driver card inserted in a VU is performed during drivers' control by a non EU control authority, using a first generation control card, download EFs within :\nDownload the EFs CardSignCertificate, CA_Certificate and Link_Certificate (if present). This information is not secured with a digital signature.\nIt is mandatory to download these files for each download session.\nDownload the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part B.\nIt is mandatory to download at least the EFs and for each download session.\nWhen downloading a driver card it is also mandatory to download the following EFs:\nWhen downloading a driver card, update the date in EF , in the and, if applicable, DFs.\nWhen downloading a workshop card, reset the calibration counter in EF in the and, if applicable, DFs.\nWhen downloading a workshop card the EF in the and, if applicable, DFs shall not be downloaded.\n3.3.1\nInitialisation sequence\nDDP_036\nThe IDE shall initiate the sequence as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\n⇦\nHardware reset\nATR\n⇨\nIt is optional to use PPS to switch to a higher baud rate as long as the ICC supports it.\n3.3.2\nSequence for un-signed data files\nDDP_037\nThe sequence to download EFs ICC, IC, Card_Certificate (or CardSignCertificate for DF Tachograph_G2), CA_Certificate and Link_Certificate (for DF Tachograph_G2 only) is as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\n⇦\nSelect File\nSelect by File identifiers\nOK\n⇨\n⇦\nRead Binary\nIf the file contains more data than the buffer size of the reader or the card the command has to be repeated until the complete file is read.\nFile Data\nOK\n⇨\nStore data to ESM\naccording to 3.4 Data storage format\nNote 1: Before selecting the Card_Certificate (or CardSignCertificate) EF, the Tachograph Application must be selected (selection by AID).\nNote 2: Selecting and reading a file may also be performed in one step using a Read Binary command with a short EF identifier.\n3.3.3\nSequence for Signed data files\nDDP_038\nThe following sequence shall be used for each of the following files that has to be downloaded with their signature:\nCard\nDir\nIDE / IFD\nMeaning / Remarks\nSelect File\nOK\nPerform Hash of File\n—\nCalculates the hash value over the data content of the selected file using the prescribed hash algorithm in accordance with Appendix 11, part A or B. This command is not an ISO-Command.\nCalculate Hash of File and store Hash value temporarily\nOK\nRead Binary\nIf the file contains more data than the buffer of the reader or the card can hold, the command has to be repeated until the complete file is read.\nFile Data\nOK\nStore received data to ESM\naccording to 3.4 Data storage format\nPSO: Compute Digital Signature\nPerform Security Operation ‘ Compute Digital Signature ’ using the temporarily stored Hash value\nSignature\nOK\nAppend data to the previous stored data on the ESM\naccording to 3.4 Data storage format\nNote: Selecting and reading a file may also be performed in one step using a Read Binary command with a short EF identifier. In this case the EF may be selected and read before the command Perform Hash of File is applied.\n3.3.4\nSequence for resetting the calibration counter.\nDDP_039\nThe sequence to reset the counter in the EF in a workshop card is the following:\nCard\nDir\nIDE/IFD\nMeaning/Remarks\n⇦\nSelect File EF Card_Download\nSelect by File identifiers\nOK\n⇨\n⇦\nUpdate Binary\nNoOfCalibrationsSinceDownload = ‘00 00’\nresets card download number\nOK\n⇨\nNote: Selecting and updating a file may also be performed in one step using an Update Binary command with a short EF identifier.\n3.4.\nData storage format\n3.4.1\nIntroduction\nDDP_040\nThe downloaded data has to be stored according to the following conditions:\nThe data shall be stored transparent. This means that the order of the bytes as well as the order of the bits inside the byte that are transferred from the card has to be preserved during storage.\nAll files of the card downloaded within a download session are stored in one file on the ESM.\n3.4.2\nFile format\nDDP_041\nThe file format is a concatenation of several TLV objects.\nDDP_042\nThe tag for an EF shall be the FID plus the appendix „00“.\nDDP_043\nThe tag of an EF's signature shall be the FID of the file plus the appendix „01“.\nDDP_044\nThe length is a two byte value. The value defines the number of bytes in the value field. The value „FF FF“ in the length field is reserved for future use.\nDDP_045\nWhen a file is not downloaded nothing related to the file shall be stored (no tag and no zero length).\nDDP_046\nA signature shall be stored as the next TLV object directly after the TLV object that contains the data of the file.\nDefinition\nMeaning\nLength\nFID (2 Bytes) || ‘ 00 ’\nTag for EF (FID) in the or for common information of the card\n3 Bytes\nFID (2 Bytes) || ‘ 01 ’\nTag for Signature of EF (FID) in the DF\n3 Bytes\nFID (2 Bytes) || ‘ 02 ’\nTag for EF (FID) in the DF\n3 Bytes\nFID (2 Bytes) || ‘ 03 ’\nTag for Signature of EF (FID) in the DF\n3 Bytes\nxx xx\nLength of Value field\n2 Bytes\nExample of data in a download file on an ESM:\nTag\nLength\nValue\n—\nData of EF ICC\n—\nData of EF Card_Certificate\n—\n…\nData of EF (in the DF)\nSignature of EF (in the DF)\nData of EF in the DF\nSignature of EF in the DF\n4.\nDOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT.\nDDP_047\nThe VU must allow for downloading the content of a driver card inserted to a connected IDE.\nDDP_048\nThe IDE shall send a ‘Transfer Data Request Card Download’ message to the VU to initiate this mode (see 2.2.2.9).\nDDP_049\nFirst generation driver cards: Data shall be downloaded using the first generation data download protocol, and downloaded data shall have the same format as data downloaded from a first generation vehicle unit.\nSecond generation driver cards: the VU shall then download the whole card, file by file, in accordance with the card downloading protocol defined in paragraph 3, and forward all data received from the card to the IDE within the appropriate TLV file format (see 3.4.2) and encapsulated within a ‘Positive Response Transfer Data’ message.\nDDP_050\nThe IDE shall retrieve card data from the ‘Positive Response Transfer Data’ message (stripping all headers, SIDs, TREPs, sub message counters, and checksums) and store them within one single physical file as described in paragraph 2.3.\nDDP_051\nThe VU shall then, as applicable, update the or the file of the driver card.",
  "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)."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Inserted 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)."
    },
    {
      "type": "F",
      "label": "F3",
      "text": "Deleted 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)."
    },
    {
      "type": "footnote",
      "label": "f1",
      "text": "The card inserted will trigger the appropriate access rights to the downloading function and to the data. It shall, however, be possible to download data from a driver card inserted into one of the VU slots when no other card type is inserted in the other slot."
    },
    {
      "type": "footnote",
      "label": "f2",
      "text": "If the VU responds with a Negative Response containing a code meaning ‘request correctly received, response pending’, this value is extended to the same upper limit value of P3."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/2016/799/annex/1/appendix/7",
    "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."
}