{
  "url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-7",
  "json_url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-7.json",
  "legislation": "eur/1985/3821",
  "legislation_title": "Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport",
  "legislation_url": "https://openlegislation.uk/eu-regulation-1985-3821",
  "path": "annex/2/appendix/7",
  "kind": "appendix",
  "number": "7",
  "heading": "DATA DOWNLOADING PROTOCOLS",
  "text": "1.\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.\nDDP_001 Data downloaded during one download session must be stored in the ESM within one file.\n1.2.\nAcronyms and notations\nThe following acronyms are used in this appendix:\nAID application identifier\nATR answer to reset\nCS checksum byte\nDF dedicated file\nDS_ diagnostic session\nEF elementary file\nESM external storage medium\nFID file identifier (File ID)\nFMT format byte (first byte of message header)\nICC integrated circuit card\nIDE intelligent dedicated equipment: The equipment used to perform data downloading to the ESM (e.g. personal computer)\nIFD interface device\nKWP keyword protocol 2000\nLEN length byte (last byte of message header)\nPPS protocol parameter selection\nPSO perform security operation\nSID service identifier\nSRC source byte\nTGT target byte\nTLV tag length value\nTREP transfer response parameter\nTRTP transfer request parameter\nVU vehicle unit.\n2.\nVU 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 — Part 2: 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 All 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 225 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 In 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 submessages. Each submessage bears a header, the same SID, TREP and a 2-byte submessage counter indicating the submessage number within the total message. To enable error checking and abort the IDE acknowledges every submessage. The IDE can accept the submessage, ask for it to be re-transmitted, request the VU to start again or abort the transmission.\nDDP_004 If the last submessage contains exactly 255 bytes in the data field, a final submessage with an empty (except SID TREP and submessage 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\nSubmessage 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n01\nSubmessage 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSubmessage n\nCS\n4 Bytes\nLess than 255 Bytes\nor as:\nHeader\nSID\nTREP\n00\n01\nSubmessage 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n02\nSubmessage 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSubmessage 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 eight different message types.\nThe following table summarises these messages.\nNotes:\nSid Req = the Sid of the corresponding request.\nTREP = the TRTP of the corresponding request.\nDark cells denotes 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 submessage counters are not shown in this Table.\nMessage Structure\nMaximum 4 bytes Header\nMaximum 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,FF,FF\n99\nPositive response request upload\n80\nF0\nEE\n03\n75\n00,FF\nD5\nTransfer data request\nOverview\n80\nEE\nF0\n02\n36\n01\n97\nActivities\n80\nEE\nF0\n06\n36\n02\nDate\nCS\nEvents and faults\n80\nEE\nF0\n02\n36\n03\n99\nDetailed speed\n80\nEE\nF0\n02\n36\n04\n9A\nTechnical data\n80\nEE\nF0\n02\n36\n05\n9B\nCard download\n80\nEE\nF0\n02\n36\n06\n9C\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\nSubfunction 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\n2.2.2.1.\nStart communication request (SID 81)\nDDP_005 This 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 This 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 The 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 The 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 The 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 The 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 The 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 The 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 The 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:\noverview (TRTP 01),\nactivities of a specified date (TRTP 02),\nevents and faults (TRTP 03),\ndetailed speed (TRTP 04),\ntechnical data (TRTP 05),\ncard download (TRTP 06).\nDDP_054 It is mandatory for the IDE to request the overview data transfer (TRTP 01) 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) the transfer data request message includes the indication of the calendar day TimeReal format) to be downloaded.\n2.2.2.10.\nPositive response transfer data (SID 76)\nDDP_012 The 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 In the first case (TREP 01), 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,\nminimum and maximum 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 The 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 The 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 The 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 The positive response stop communication message is sent by the VU to acknowledge the stop communication request.\n2.2.2.15.\nAcknowledge submessage (SID 83)\nDDP_017 The acknowledge sub message is sent by the IDE to confirm receipt of each part of a message that is being transmitted as several submessages. The data field contains the SID received from the VU and a 2-byte code as follows:\nMsgC +1 Acknowledges correct receipt of submessage number MsgC.\nRequest from the IDE to the VU to send next submessage,\nMsgC indicates a problem with the receipt of submessage number MsgC.\nRequest from the IDE to the VU to send the submessage 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 submessage 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 The 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, …)\n2.2.3.\nMessage flow\nA typical message flow during a normal data download procedure is the following:\nIDE\nVU\nStart communication request\nPositive response\nStart diagnostic service request\nPositive response\nRequest upload\nPositive response\nTransfer data request overview\nPositive response\nData request #2\nPositive response #1\nAcknowledge submessage #1\nPositive response #2\nAcknowledge submessage #2\nPositive response #m\nAcknowledge submessage #m\nPositive response (Data field < 255 Bytes)\nAcknowledge submessage (optional)\n…\nTransfer data request #n\nPositive response\nRequest transfer exit\nPositive response\nStop communication request\nPositive response\n2.2.4.\nTiming\nDDP_019 During normal operation the timing parameters shown in the following figure are relevant:\nWhere:\nP1 Inter byte time for VU response.\nP2 Time between end of IDE request and start of VU response, or between end of IDE acknowledge and start of next VU response.\nP3 Time 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.\nP4 Inter byte time for IDE request.\nP5 Extended 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 limit Value (ms)\nUpper limit value (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 If 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 If 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_022 For 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_023 If the VU detects one of the above errors, then it sends no response and ignores the message received.\nDDP_024 The 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.\n2.. The IDE detects a VU transmission error.\nDDP_025 For 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_026 The IDE shall detect sequence errors, e.g. incorrect sub message counter increments in successive received messages.\nDDP_027 If the IDE detects an error or there was no response from the VU within a P2max period, the request message will be sent again for a maximum of three transmissions in total. For the purposes of this error detection a submessage acknowledge will be considered as a request to the VU.\nDDP_028 The IDE shall wait at least for a period of P3min before beginning each transmission; the wait period shall be measured from the last calculated occurrence of a stop bit after the error was detected.\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.\n2.2.6.1.\nPositive response transfer data overview\nDDP_029 The 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 Hex and appropriate sub message splitting and counting:\n2.2.6.2.\nPositive response transfer data activities\nDDP_030 The 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 Hex and appropriate sub message splitting and counting:\n2.2.6.3.\nPositive response transfer data events and faults\nDDP_031 The 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 Hex and appropriate sub message splitting and counting:\n2.2.6.4.\nPositive response transfer data detailed speed\nDDP_032 The 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 Hex and appropriate sub message splitting and countering:\n2.2.6.5.\nPositive response transfer data technical data\nDDP_033 The 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 Hex and appropriate sub message splitting and counting:\n2.3.\nESM File storage\nDDP_034 When a download session has included a VU data transfer, the IDE shall store within one 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 session Each 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 file A 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 The download of a tachograph card includes the following steps:\ndownload the common information of the card in the EFs ICC and IC . This information is optional and is not secured with a digital signature,\nDownload the EFs Card_Certificate and CA_Certificate. 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 Tachograph DF) except EF Card_Download. This information is secured with a digital signature,\nit is mandatory to download at least the EFs Application_Identification and ID for each download session,\nwhen downloading a driver card it is also mandatory to download the following EFs:\nEvents_Data,\nFaults_Data,\nDriver_Activity_Data,\nVehicles_Used,\nPlaces,\nControl_Activity_Data,\nSpecific_Conditions.\nWhen downloading a driver card, update the LastCardDownload date in EF Card_Download,\nWhen downloading a workshop card, reset the calibration counter in EF Card_Download.\n3.3.1.\nInitialisation sequence\nDDP_036 The IDE shall initiate the sequence as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nHardware reset\nATR\nIt is optional to use PPS to switch to a higher baudrate as long as the ICC supports it.\n3.3.2.\nSequence for unsigned data files\nDDP_037 The sequence to download the ICC , IC , Card_Certificate and CA_Certificate is as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect file\nSelect file select by file identifiers\nOK\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\nStore data to ESM\naccording to 3.4, (Data storage format)\nNote: Before selecting the Card_Certificate EF, the Tachograph Application must be selected (selection by AID).\n3.3.3.\nSequence for signed data files\nDDP_038 The following sequence shall be used for each of the following files that has to be downloaded with their signature:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect File\nOK\nPerform hash of File\nCalculates the hash value over the data content of the selected file using the prescribed hash algorithm in accordance with Appendix 11. 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)\n3.3.4.\nSequence for resetting the calibration counter\nDDP_039 The sequence to reset the NoOfCalibrationsSinceDownload counter in the EF Card_Download in a workshop card is the following:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect File EF Card_Download\nSelect by file identifiers\nOK\nUpdate Binary\nNoOfCalibrationsSinceDownload = ′00 00′\nResets card download number\nOK\n3.4.\nData storage format\n3.4.1.\nIntroduction\nDDP_040 The 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 The file format is a concatenation of several TLV objects.\nDDP_042 The tag for an EF shall be the FID plus the appendix ‘ 00 ’ .\nDDP_043 The tag of an EF's signature shall be the FID of the file plus the appendix ‘ 01 ’ .\nDDP_044 The 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 When a file is not downloaded nothing related to the file shall be stored (no tag and no zero length).\nDDP_046 A 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)\n3 Bytes\nFID (2 Bytes) || ‘ 01 ’\nTag for Signature of EF(FID)\n3 Bytes\nxx xx\nLength of value field\n2 Bytes\nExample of data in a download file on an ESM:\nTag\nLength\nValue\n00 02 00\n00 11\nData of EF ICC\nC1 00 00\n00 C2\nData of EF Card_Certificate\n…\n05 05 00\n0A 2E\nData of EF Vehicles_Used\n05 05 01\n00 80\nSignature of EF Vehicles_Used\n4.\nDOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT\nDDP_047 The VU must allow for downloading the content of a driver card inserted to a connected IDE.\nDDP_048 The IDE shall send a ‘ transfer data request card download ’ message to the VU to initiate this mode (see 2.2.2.9).\nDDP_049 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 The IDE shall retrieve card data from the ‘ positive response transfer data ’ message (stripping all headers, SIDs, TREPs, submessage counters, and checksums) and store them within one physical file as described in paragraph 2.3.\nDDP_051 The VU shall then, as applicable, update the Control_Activity_Data or the Card_Download file of the driver card.",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Inserted by Council Regulation (EC) No 2135/98 of 24 September 1998 amending Regulation (EEC) No 3821/85 on recording equipment in road transport and Directive 88/599/EEC concerning the application of Regulations (EEC) No 3820/85 and (EEC) No 3821/85."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Substituted by Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F3",
      "text": "Substituted by Commission Regulation (EC) No 432/2004 of 5 March 2004 adapting for the eighth time to technical progress Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "X",
      "label": "X1",
      "text": "Substituted by Corrigendum to Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Official Journal of the European Communities L 207 of 5 August 2002)."
    },
    {
      "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 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/1985/3821/annex/2/appendix/7",
    "retrieved_at": "2026-11-01T15:05:16.849228+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."
}