- Latest available (Revised)
- Original (As adopted by EU)
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)
After exit day there will be three versions of this legislation to consult for different purposes. The legislation.gov.uk version is the version that applies in the UK. The EU Version currently on EUR-lex is the version that currently applies in the EU i.e you may need this if you operate a business in the EU.
The web archive version is the official version of this legislation item as it stood on exit day before being published to legislation.gov.uk and any subsequent UK changes and effects applied. The web archive also captured associated case law and other language formats from EUR-Lex.
There are outstanding changes not yet made to Commission Implementing Regulation (EU) 2016/799. Any changes that have already been made to the legislation appear in the content and are referenced with annotations.
Revised legislation carried on this site may not be fully up to date. Changes and effects are recorded by our editorial team in lists which can be found in the ‘Changes to Legislation’ area. Where those effects have yet to be applied to the text of the legislation by the editorial team they are also listed alongside the legislation in the affected provisions. Use the ‘more’ link to open the changes and effects relevant to the provision you are viewing.
This 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.
Data may be downloaded to an ESM:
from a Vehicle Unit by an Intelligent Dedicated Equipment (IDE) connected to the VU,
from a tachograph card by an IDE fitted with a card interface device (IFD),
from a tachograph card via a vehicle unit by an IDE connected to the VU.
To 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.
Data 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.
This Appendix specifies therefore two types of data downloads from the VU:
Generation 2 type of VU data download, providing the generation 2 data structure, signed using Appendix 11 Common Security Mechanisms Part B,
Generation 1 type of VU data download, providing the generation 1 data structure, signed using Appendix 11 Common Security Mechanisms Part A.
Similarly, 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.]
Textual Amendments
The following acronyms are used in this appendix:
Application Identifier
Answer To Reset
Checksum byte
Dedicated File
Diagnostic Session
Elementary File
External Storage Medium
File Identifier (File ID)
Format Byte (first byte of message header)
Integrated Circuit Card
Intelligent Dedicated Equipment: The equipment used to perform data downloading to the ESM (e.g. Personal Computer)
Interface Device
Keyword Protocol 2000
Length Byte (last byte of message header)
Protocol Parameter Selection
Perform Security Operation
Service Identifier
Source byte
Target Byte
Tag Length Value
Transfer Response Parameter
Transfer Request Parameter
Vehicle Unit
In order to carry on a VU data download, the operator must perform the following operations:
Insert his tachograph card inside a card slot of the VU(1);
Connect the IDE to the VU download connector;
Establish the connection between the IDE and the VU;
Select on the IDE the data to download and send the request to the VU;
Close the download session.
The protocol is structured on a master-slave basis, with the IDE playing the master role and the VU playing the slave role.
The 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).
The 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).
Header composed by a Format byte (FMT), a Target byte (TGT), a Source byte (SRC) and possibly a Length byte (LEN),
Data 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).
Checksum composed by a Checksum byte (CS).
Header | Data field | Checksum | |||||||
---|---|---|---|---|---|---|---|---|---|
FMT | TGT | SRC | LEN | SID | DATA | … | … | … | CS |
4 bytes | Max 255 bytes | 1 byte |
The 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.
The LEN byte is the length of the Data field part.
The Checksum byte is the 8 bit sum series modulo 256 of all the bytes of the message excluding the CS itself.
FMT, SID, DS_, TRTP and TREP bytes are defined later in this document.
Example:
Header | SID | TREP | Message | CS |
---|---|---|---|---|
4 Bytes | Longer than 255 Bytes |
Will be transmitted as:
Header | SID | TREP | 00 | 01 | Sub message 1 | CS |
---|---|---|---|---|---|---|
4 Bytes | 255 Bytes |
Header | SID | TREP | 00 | 02 | Sub message 2 | CS |
---|---|---|---|---|---|---|
4 Bytes | 255 Bytes |
…
Header | SID | TREP | xx | yy | Sub message n | CS |
---|---|---|---|---|---|---|
4 Bytes | Less than 255 Bytes |
or as:
Header | SID | TREP | 00 | 01 | Sub message 1 | CS |
---|---|---|---|---|---|---|
4 Bytes | 255 Bytes |
Header | SID | TREP | 00 | 02 | Sub message 2 | CS |
---|---|---|---|---|---|---|
4 Bytes | 255 Bytes |
…
Header | SID | TREP | xx | yy | Sub message n | CS |
---|---|---|---|---|---|---|
4 Bytes | 255 Bytes |
Header | SID | TREP | xx | yy + 1 | CS |
---|---|---|---|---|---|
4 Bytes | 4 bytes |
The communication protocol for data download between the VU and the IDE requires the exchange of 8 different message types.
The following table summarises these messages.
[F1Message Structure | Max 4 Bytes Header | Max 255 Bytes Data | 1 Byte CheckSum | ||||||
---|---|---|---|---|---|---|---|---|---|
IDE -> | <- VU | FMT | TGT | SRC | LEN | SID | DS_ / TRTP | DATA | CS |
Start Communication Request | 81 | EE | F0 | 81 | E0 | ||||
Positive Response Start Communication | 80 | F0 | EE | 03 | C1 | EA, 8F | 9B | ||
Start Diagnostic Session Request | 80 | EE | F0 | 02 | 10 | 81 | F1 | ||
Positive Response Start Diagnostic | 80 | F0 | EE | 02 | 50 | 81 | 31 | ||
Link Control Service | |||||||||
Verify Baud Rate (stage 1) | |||||||||
9 600 Bd | 80 | EE | F0 | 04 | 87 | 01,01,01 | EC | ||
19 200 Bd | 80 | EE | F0 | 04 | 87 | 01,01,02 | ED | ||
38 400 Bd | 80 | EE | F0 | 04 | 87 | 01,01,03 | EE | ||
57 600 Bd | 80 | EE | F0 | 04 | 87 | 01,01,04 | EF | ||
115 200 Bd | 80 | EE | F0 | 04 | 87 | 01,01,05 | F0 | ||
Positive Response Verify Baud Rate | 80 | F0 | EE | 02 | C7 | 01 | 28 | ||
Transition Baud Rate (stage 2) | 80 | EE | F0 | 03 | 87 | 02,03 | ED | ||
Request Upload | 80 | EE | F0 | 0A | 35 | 00,00,00,00,00,FF,FF, FF,FF | 99 | ||
Positive Response Request Upload | 80 | F0 | EE | 03 | 75 | 00,FF | D5 | ||
Transfer Data Request | |||||||||
Overview | 80 | EE | F0 | 02 | 36 | 01 or 21 | 97 | ||
Activities | 80 | EE | F0 | 06 | 36 | 02 or 22 | Date | CS | |
Events & Faults | 80 | EE | F0 | 02 | 36 | 03 or 23 | Date | 99 | |
Detailed Speed | 80 | EE | F0 | 02 | 36 | 04 or 24 | Date | 9 A | |
Technical Data | 80 | EE | F0 | 02 | 36 | 05 or 25 | Date | 9B | |
Card download | 80 | EE | F0 | 02 | 36 | 06 | Slot | CS | |
Positive Response Transfer Data | 80 | F0 | EE | Len | 76 | TREP | Data | CS | |
Request Transfer Exit | 80 | EE | F0 | 01 | 37 | 96 | |||
Positive Response Request Transfer Exit | 80 | F0 | EE | 01 | 77 | D6 | |||
Stop Communication Request | 80 | EE | F0 | 01 | 82 | E1 | |||
Positive Response Stop Communication | 80 | F0 | EE | 01 | C2 | 21 | |||
Acknowledge sub message | 80 | EE | F0 | Len | 83 | Data | CS | ||
Negative responses | |||||||||
General reject | 80 | F0 | EE | 03 | 7F | Sid Req | 10 | CS | |
Service not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 11 | CS | |
Sub function not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 12 | CS | |
Incorrect Message Length | 80 | F0 | EE | 03 | 7F | Sid Req | 13 | CS | |
Conditions not correct or Request sequence error | 80 | F0 | EE | 03 | 7F | Sid Req | 22 | CS | |
Request out of range | 80 | F0 | EE | 03 | 7F | Sid Req | 31 | CS | |
Upload not accepted | 80 | F0 | EE | 03 | 7F | Sid Req | 50 | CS | |
Response pending | 80 | F0 | EE | 03 | 7F | Sid Req | 78 | CS | |
Data not available | 80 | F0 | EE | 03 | 7F | Sid Req | FA | CS] |
[F2TRTP 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.
TRTP 11 to 19 and 31 to 39 are reserved for manufacturer specific download requests.]
Sid Req = the Sid of the corresponding request.
TREP = the TRTP of the corresponding request.
Dark cells denote that nothing is transmitted.
The 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).
Potential 2-byte sub message counters are not shown in this table.
Slot is the slot number, either “1” (card on driver slot) or “2” (card on co-driver slot)
In 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.
There are six types of data transfer. For VU data download, two different TRTP values can be used for each transfer type:
Data transfer type | TRTP value for generation 1 type of VU data download | TRTP value for generation 2 type of VU data download |
---|---|---|
Overview | 01 | 21 |
Activities of a specified date | 02 | 22 |
Events and faults | 03 | 23 |
Detailed speed | 04 | 24 |
Technical data | 05 | 25 |
Data transfer type | TRTP value |
Card download | 06] |
In the second case (TRTP 02 or 22) the Transfer Data Request message includes the indication of the calendar day ( format) to be downloaded.]
Security certificates,
Vehicle identification,
VU current date and time,
Min and Max downloadable date (VU data),
Indication of cards presence in the VU,
Previous download to a company,
Company locks,
Previous controls.]
MsgC+1 Acknowledges correct receipt of sub message number MsgC.
Request from the IDE to the VU to send next sub message
MsgC indicates a problem with the receipt of sub message number MsgC.
Request from the IDE to the VU to send the sub message again.
FFFF requests termination of the message.
This can be used by the IDE to end the transmission of the VU message for any reason.
The last sub message of a message (LEN byte < 255) may be acknowledged using any of these codes or not acknowledged.
The VU responses that will consist of several sub messages are:
Positive Response Transfer Data (SID 76)
10 general reject
The action cannot be performed for a reason not covered below.
11 service not supported
The SID of the request is not understood.
12 sub function not supported
The DS_ or TRTP of the request is not understood, or there are no further sub messages to be transmitted.
13 incorrect message length
The length of the received message is wrong.
22 conditions not correct or request sequence error
The required service is not active or the sequence of request messages is not correct.
31 Request out of range
The request parameter record (data field) is not valid.
50 upload not accepted
The request cannot be performed (VU in a non appropriate mode of operation or internal fault of the VU).
78 response pending
The action requested cannot be completed in time and the VU is not ready to accept another request.
[F1FA data not available
The 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…).]
A typical message flow during a normal data download procedure is the following:
IDE | VU | |
---|---|---|
Start Communication Request | ⇨ | |
⇦ | Positive Response | |
Start Diagnostic Service Request | ⇨ | |
⇦ | Positive Response | |
Request Upload | ⇨ | |
⇦ | Positive Response | |
Transfer Data Request Overview | ⇨ | |
⇦ | Positive Response | |
Transfer Data Request #2 | ⇨ | |
⇦ | Positive Response #1 | |
Acknowledge Sub Message #1 | ⇨ | |
⇦ | Positive Response #2 | |
Acknowledge Sub Message #2 | ⇨ | |
⇦ | Positive Response #m | |
Acknowledge Sub Message #m | ⇨ | |
⇦ | Positive Response (Data Field < 255 Bytes) | |
Acknowledge Sub Message (optional) | ⇨ | |
… | ||
Transfer Data Request #n | ⇨ | |
⇦ | Positive Response | |
Request Transfer Exit | ⇨ | |
⇦ | Positive Response | |
Stop Communication Request | ⇨ | |
⇦ | Positive Response |
Where:
=
Inter byte time for VU response.
=
Time between end of IDE request and start of VU response, or between end of IDE acknowledge and start of next VU response.
=
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.
=
Inter byte time for IDE request.
=
Extended value of P3 for card downloading.
The 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).
a 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. | ||
Timing Parameter | Lower limitValue (ms) | Upper limitValue (ms) |
---|---|---|
P1 | 0 | 20 |
P2 | 20 | 1 000a |
P3 | 10 | 5 000 |
P4 | 5 | 20 |
P5 | 10 | 20 minutes |
If 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.
In figure 2 and figure 3 the error handling procedures for the VU and the IDE are respectively shown.
Two different error handling areas can be defined:
The VU detects an IDE transmission error.
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).
If the VU detects one of the above errors, then it sends no response and ignores the message received.
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.
The IDE detects a VU transmission error.
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).
The IDE shall detect sequence errors, e.g. incorrect sub message counter increments in successive received messages.
If 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.
The 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.
This paragraph specifies the content of the data fields of the various positive response messages.
Data elements are defined in Appendix 1 data dictionary.
Remark: 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.U.K.
[F1Data structure generation 1 (TREP 01 Hex)] | ||
Data element | Comment | |
---|---|---|
VU Security certificates | ||
Vehicle identification | ||
VU current date and time | ||
Downloadable period | ||
Type of cards inserted in the VU | ||
Previous VU download | ||
All company locks stored. If the section is empty, only noOfLocks = 0 is sent. | ||
All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent | ||
RSA signature of all data (except certificates) starting from VehicleIdentificationNumber down to last byte of last VuControlActivityData. |
[F1Data structure generation 2 (TREP 21 Hex)] | ||
Data element | Comment | |
---|---|---|
Member state certificate | ||
VU certificate | ||
Vehicle identification | ||
Vehicle registration number | ||
VU current date and time | ||
Downloadable period | ||
Type of cards inserted in the VU | ||
Previous VU download | ||
All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent | ||
All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent | ||
ECC signature of all preceding data except the certificates. |
[F1Data structure generation 1 (TREP 02 Hex)] | ||
Data element | Comment | |
---|---|---|
Date of day downloaded | ||
Odometer at end of downloaded day | ||
Cards insertion withdrawal cycles data.
| ||
Slots status at 00:00 and activity changes recorded for the day downloaded. | ||
Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent. | ||
Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent | ||
RSA signature of all data starting from TimeReal down to last byte of last specific condition record. |
[F1Data structure generation 2 (TREP 22 Hex)] | ||
Data element | Comment | |
---|---|---|
Date of day downloaded | ||
Odometer at end of downloaded day | ||
Cards insertion withdrawal cycles data.
| ||
Slots status at 00:00 and activity changes recorded for the day downloaded. | ||
Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent. | ||
[F1 | GNSS 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.] | |
Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent | ||
ECC signature of all preceding data. |
[F1Data structure generation 1 (TREP 03 Hex)] | ||
Data element | Comment | |
---|---|---|
All faults stored or on-going in the VU. If the section is empty, only noOfVuFaults = 0 is sent. | ||
All events (except over speeding) stored or on-going in the VU. If the section is empty, only noOfVuEvents = 0 is sent. | ||
Data related to last over speeding control (default value if no data). | ||
All over speeding events stored in the VU. If the section is empty, only noOfVuOverSpeedingEvents = 0 is sent. | ||
All time adjustment events stored in the VU (outside the frame of a full calibration). If the section is empty, only noOfVuTimeAdjRecords = 0 is sent. | ||
RSA signature of all data starting from noOfVuFaults down to last byte of last time adjustment record |
[F1Data structure generation 2 (TREP 23 Hex)] | ||
Data element | Comment | |
---|---|---|
All faults stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. | ||
All events (except over speeding) stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. | ||
Data related to last over speeding control (default value if no data). | ||
All over speeding events stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. | ||
All time adjustment events stored in the VU (outside the frame of a full calibration). If the section is empty, an array header with noOfRecords = 0 is sent. | ||
[ F3 ] | ||
ECC signature of all preceding data. |
[F1Data structure generation 1 (TREP 04)] | ||
Data element | Comment | |
---|---|---|
All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving) 60 speed values per minute (one per second). | ||
RSA signature of all data starting from noOfSpeedBlocks down to last byte of last speed block. |
[F1Data structure generation 2 (TREP 24)] | ||
Data element | Comment | |
---|---|---|
All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving) 60 speed values per minute (one per second). | ||
ECC signature of all preceding data. |
[F1Data structure generation 1 (TREP 05)] | ||
Data element | Comment | |
---|---|---|
All calibration records stored in the VU. | ||
RSA signature of all data starting from vuManufacturerName down to last byte of last VuCalibrationRecord. |
[F1Data structure generation 2 (TREP 25)] | ||
Data element | Comment | |
---|---|---|
All MS pairings stored in the VU | ||
All external GNSS facility couplings stored in the VU | ||
All calibration records stored in the VU. | ||
All card insertion data stored in the VU. | ||
ECC signature of all preceding data. |
This 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.
:
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).
:
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.
Download the common information of the card in the EFs and This information is optional and is not secured with a digital signature.
(for first and second generation tachograph cards) Download EFs within :
Download the EFs and This information is not secured with a digital signature.
It is mandatory to download these files for each download session.
Download the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part A.
It is mandatory to download at least the EFs and for each download session.
When downloading a driver card it is also mandatory to download the following EFs:
(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 :
Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate (if present). This information is not secured with a digital signature.
It is mandatory to download these files for each download session.
Download the other application data EFs (within ) except EF . This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part B.
It is mandatory to download at least the EFs and for each download session.
When downloading a driver card it is also mandatory to download the following EFs:
When downloading a driver card, update the date in EF , in the and, if applicable, DFs.
When downloading a workshop card, reset the calibration counter in EF in the and, if applicable, DFs.
When downloading a workshop card the EF in the and, if applicable, DFs shall not be downloaded.]
Card | Direction | IDE/IFD | Meaning/Remarks |
---|---|---|---|
⇦ | Hardware reset | ||
ATR | ⇨ |
It is optional to use PPS to switch to a higher baud rate as long as the ICC supports it.
Card | Direction | IDE/IFD | Meaning/Remarks |
---|---|---|---|
⇦ | Select File | Select by File identifiers | |
OK | ⇨ | ||
⇦ | Read Binary | If 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. | |
File Data OK | ⇨ | Store data to ESM | according to 3.4 Data storage format |
Note 1: Before selecting the Card_Certificate (or CardSignCertificate) EF, the Tachograph Application must be selected (selection by AID).U.K.
Note 2: Selecting and reading a file may also be performed in one step using a Read Binary command with a short EF identifier.U.K.
[F1Card | Dir | IDE / IFD | Meaning / Remarks |
---|---|---|---|
Select File | |||
OK | |||
Perform Hash of File | — Calculates 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. | ||
Calculate Hash of File and store Hash value temporarily | |||
OK | |||
Read Binary | If 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. | ||
File Data OK | Store received data to ESM | according to 3.4 Data storage format | |
PSO: Compute Digital Signature | |||
Perform Security Operation ‘ Compute Digital Signature ’ using the temporarily stored Hash value | |||
Signature OK | Append data to the previous stored data on the ESM | according to 3.4 Data storage format] |
Note: 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.U.K.
Card | Dir | IDE/IFD | Meaning/Remarks |
---|---|---|---|
⇦ | Select File EF Card_Download | Select by File identifiers | |
OK | ⇨ | ||
⇦ | Update Binary NoOfCalibrationsSinceDownload = ‘00 00’ | ||
resets card download number | |||
OK | ⇨ |
Note: Selecting and updating a file may also be performed in one step using an Update Binary command with a short EF identifier.U.K.
The 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.
All files of the card downloaded within a download session are stored in one file on the ESM.
Example of data in a download file on an ESM:
Second 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.]
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.
The Whole Regulation you have selected contains over 200 provisions and might take some time to download. You may also experience some issues with your browser, such as an alert box that a script is taking a long time to run.
Would you like to continue?
The Schedules you have selected contains over 200 provisions and might take some time to download. You may also experience some issues with your browser, such as an alert box that a script is taking a long time to run.
Would you like to continue?
Latest Available (revised):The latest available updated version of the legislation incorporating changes made by subsequent legislation and applied by our editorial team. Changes we have not yet applied to the text, can be found in the ‘Changes to Legislation’ area.
Original (As adopted by EU): The original version of the legislation as it stood when it was first adopted in the EU. No changes have been applied to the text.
Geographical Extent: Indicates the geographical area that this provision applies to. For further information see ‘Frequently Asked Questions’.
Show Timeline of Changes: See how this legislation has or could change over time. Turning this feature on will show extra navigation options to go to these specific points in time. Return to the latest available version by using the controls above in the What Version box.
Access essential accompanying documents and information for this legislation item from this tab. Dependent on the legislation item being viewed this may include:
This timeline shows the different versions taken from EUR-Lex before exit day and during the implementation period as well as any subsequent versions created after the implementation period as a result of changes made by UK legislation.
The dates for the EU versions are taken from the document dates on EUR-Lex and may not always coincide with when the changes came into force for the document.
For any versions created after the implementation period as a result of changes made by UK legislation the date will coincide with the earliest date on which the change (e.g an insertion, a repeal or a substitution) that was applied came into force. For further information see our guide to revised legislation on Understanding Legislation.
Use this menu to access essential accompanying documents and information for this legislation item. Dependent on the legislation item being viewed this may include:
Click 'View More' or select 'More Resources' tab for additional information including: