[F1 [F2ANNEX I B U.K. REQUIREMENTS FOR CONSTRUCTION, TESTING, INSTALLATION AND INSPECTION

Textual Amendments

Appendix 7 DATA DOWNLOADING PROTOCOLS

1. INTRODUCTION U.K.

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.

1.1. Scope U.K.

Data may be downloaded to an ESM:

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.

[DDP_001] Data downloaded during one download session must be stored in the ESM within one file.

1.2. Acronyms and notations U.K.

The following acronyms are used in this appendix:

AID

application identifier

ATR

answer to reset

CS

checksum byte

DF

dedicated file

DS_

diagnostic session

EF

elementary file

ESM

external storage medium

FID

file identifier (File ID)

FMT

format byte (first byte of message header)

ICC

integrated circuit card

IDE

intelligent dedicated equipment: The equipment used to perform data downloading to the ESM (e.g. personal computer)

IFD

interface device

KWP

keyword protocol 2000

LEN

length byte (last byte of message header)

PPS

protocol parameter selection

PSO

perform security operation

SID

service identifier

SRC

source byte

TGT

target byte

TLV

tag length value

TREP

transfer response parameter

TRTP

transfer request parameter

VU

vehicle unit.

2. VU DATA DOWNLOADING U.K.

2.1. Download procedure U.K.

In order to carry on a VU data download, the operator must perform the following operations:

2.2. Data download protocol U.K.

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 — Part 2: 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 ).

2.2.1. Message structure U.K.

[DDP_002] All the messages exchanged between the IDE and the VU are formatted with a structure consisting of three parts:

Header Data field Checksum
FMT TGT SRC LEN SID DATA … … … CS
4 bytes Max 225 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.

[DDP_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.

[DDP_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.

Example:

Header SID TREP Message CS
4 Bytes Longer than 255 Bytes

Will be transmitted as:

Header SID TREP 00 01 Submessage 1 CS
4 Bytes 255 Bytes
Header SID TREP 00 01 Submessage 2 CS
4 Bytes 255 Bytes

…

Header SID TREP xx yy Submessage n CS
4 Bytes Less than 255 Bytes

or as:

Header SID TREP 00 01 Submessage 1 CS
4 Bytes 255 Bytes
Header SID TREP 00 02 Submessage 2 CS
4 Bytes 255 Bytes

…

Header SID TREP xx yy Submessage n CS
4 Bytes 255 Bytes
Header SID TREP xx yy+1 CS
4 Bytes 4 bytes
2.2.2. Message types U.K.

The communication protocol for data download between the VU and the IDE requires the exchange of eight different message types.

The following table summarises these messages.

Notes:

  • Sid Req = the Sid of the corresponding request.

  • TREP = the TRTP of the corresponding request.

  • Dark cells denotes 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 submessage counters are not shown in this Table.

Message Structure Maximum 4 bytes Header Maximum 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 [F3EA 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 [X1EE]
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 97
Activities 80 EE F0 06 36 02 Date CS
Events and faults 80 EE F0 02 36 03 99
Detailed speed 80 EE F0 02 36 04 9A
Technical data 80 EE F0 02 36 05 9B
Card download 80 EE F0 02 36 06 9C
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
Subfunction 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

Editorial Information

Textual Amendments

2.2.2.1. Start communication request (SID 81) U.K.

[DDP_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).

2.2.2.2. Positive response start communication (SID C1) U.K.

[DDP_006] This message is issued by the VU to answer positively to a start communication request. It includes the 2 key bytes [F3′EA′ ′8F′] indicating that the unit supports protocol with header including target source and length information.

2.2.2.3. Start diagnostic session request (SID 10) U.K.

[DDP_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.

2.2.2.4. Positive response start diagnostic (SID 50) U.K.

[DDP_008] The positive response start diagnostic message is sent by the VU to answer positively to Diagnostic Session Request.

2.2.2.5. Link control service (SID 87) U.K.

[DDP_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

2.2.2.6. Link control positive response (SID C7) U.K.

[DDP_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).

2.2.2.7. Request upload (SID 35) U.K.

[DDP_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.

2.2.2.8. Positive response request upload (SID 75) U.K.

[DDP_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.

2.2.2.9. Transfer data request (SID 36) U.K.

[DDP_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.

There are six types of data transfer:

[DDP_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).

In the second case (TRTP 02) the transfer data request message includes the indication of the calendar day TimeReal format) to be downloaded.

2.2.2.10. Positive response transfer data (SID 76) U.K.

[DDP_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.

[DDP_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:

2.2.2.11. Request transfer exit (SID 37) U.K.

[DDP_013] The request transfer exit message is sent by the IDE to inform the VU that the download session is terminated.

2.2.2.12. Positive response request transfer exit (SID 77) U.K.

[DDP_014] The positive response request transfer exit message is sent by the VU to acknowledge the Request Transfer Exit.

2.2.2.13. Stop communication request (SID 82) U.K.

[DDP_015] The stop communication request message is sent by the IDE to disconnect the communication link with the VU.

2.2.2.14. Positive response stop communication (SID C2) U.K.

[DDP_016] The positive response stop communication message is sent by the VU to acknowledge the stop communication request.

2.2.2.15. Acknowledge submessage (SID 83) U.K.

[DDP_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:

The last submessage 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:

2.2.2.16. Negative Response (SID 7F) U.K.

[DDP_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:

2.2.3. Message flow U.K.

A typical message flow during a normal data download procedure is the following:

IDE [X1VU]
Start communication request

Positive response
Start diagnostic service request

Positive response
Request upload

Positive response
Transfer data request overview

[X1Positive response]
Data request #2

Positive response #1
Acknowledge submessage #1

Positive response #2
Acknowledge submessage #2

Positive response #m
Acknowledge submessage #m

Positive response (Data field < 255 Bytes)
Acknowledge submessage (optional)

…
Transfer data request #n

Positive response
Request transfer exit

Positive response
Stop communication request

Positive response
2.2.4. Timing U.K.

[DDP_019] During normal operation the timing parameters shown in the following figure are relevant:

Where:

P1

=

Inter byte time for VU response.

P2

=

Time between end of IDE request and start of VU response, or between end of IDE acknowledge and start of next VU response.

P3

=

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.

P4

=

Inter byte time for IDE request.

P5

=

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 limit Value (ms) Upper limit value (ms)
P1 0 20
P2 20 1 000 a
P3 10 5 000
P4 5 20
P5 10 20 minutes
2.2.5. Error handling U.K.

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.

2.2.5.1. Start communication phase U.K.

[DDP_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.

[DDP_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.

2.2.5.2. Communication phase U.K.

Two different error handling areas can be defined:

1.

The VU detects an IDE transmission error.

[DDP_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).

[DDP_023] If the VU detects one of the above errors, then it sends no response and ignores the message received.

[DDP_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.

2.

The IDE detects a VU transmission error.

[DDP_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).

[DDP_026] The IDE shall detect sequence errors, e.g. incorrect sub message counter increments in successive received messages.

[DDP_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.

[DDP_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.

2.2.6. Response message content U.K.

This paragraph specifies the content of the data fields of the various positive response messages.

Data elements are defined in Appendix 1 data dictionary.

2.2.6.1. Positive response transfer data overview U.K.

[DDP_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:

2.2.6.2. Positive response transfer data activities U.K.

[DDP_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:

2.2.6.3. Positive response transfer data events and faults U.K.

[DDP_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:

2.2.6.4. Positive response transfer data detailed speed U.K.

[DDP_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:

2.2.6.5. Positive response transfer data technical data U.K.

[DDP_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:

2.3. ESM File storage U.K.

[DDP_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).

3. TACHOGRAPH CARDS DOWNLOADING PROTOCOL U.K.

3.1. Scope U.K.

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.

3.2. Definitions U.K.
Download 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).

Signed 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.

3.3. Card downloading U.K.

[DDP_035] The download of a tachograph card includes the following steps:

3.3.1. Initialisation sequence U.K.

[DDP_036] The IDE shall initiate the sequence as follows:

Card Direction IDE/IFD Meaning/Remarks

Hardware reset
ATR

It is optional to use PPS to switch to a higher baudrate as long as the ICC supports it.

3.3.2. Sequence for unsigned data files U.K.

[DDP_037] The sequence to download the ICC , IC , Card_Certificate and CA_Certificate is as follows:

Card Direction IDE/IFD Meaning/Remarks

Select file 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: Before selecting the Card_Certificate EF, the Tachograph Application must be selected (selection by AID). U.K.

3.3.3. Sequence for signed data files U.K.

[DDP_038] The following sequence shall be used for each of the following files that has to be downloaded with their signature:

Card Direction 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. 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)
3.3.4. Sequence for resetting the calibration counter U.K.

[DDP_039] The sequence to reset the NoOfCalibrationsSinceDownload counter in the EF Card_Download in a workshop card is the following:

Card Direction IDE/IFD Meaning/Remarks

Select File EF Card_Download Select by file identifiers
OK

Update Binary

NoOfCalibrationsSinceDownload = ′00 00′

Resets card download number
OK

3.4. Data storage format U.K.
3.4.1. Introduction U.K.

[DDP_040] The downloaded data has to be stored according to the following conditions:

3.4.2. File format U.K.

[DDP_041] The file format is a concatenation of several TLV objects.

[DDP_042] The tag for an EF shall be the FID plus the appendix ‘ 00 ’ .

[DDP_043] The tag of an EF's signature shall be the FID of the file plus the appendix ‘ 01 ’ .

[DDP_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.

[DDP_045] When a file is not downloaded nothing related to the file shall be stored (no tag and no zero length).

[DDP_046] A signature shall be stored as the next TLV object directly after the TLV object that contains the data of the file.

Definition Meaning Length
FID (2 Bytes) || ‘ 00 ’ Tag for EF (FID) 3 Bytes
FID (2 Bytes) || ‘ 01 ’ Tag for Signature of EF(FID) 3 Bytes
xx xx Length of value field 2 Bytes

Example of data in a download file on an ESM:

Tag Length Value
00 02 00 00 11 Data of EF ICC
C1 00 00 00 C2 Data of EF Card_Certificate
…
05 05 00 0A 2E Data of EF Vehicles_Used
05 05 01 00 80 Signature of EF Vehicles_Used

4. DOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT U.K.

[DDP_047] The VU must allow for downloading the content of a driver card inserted to a connected IDE.

[DDP_048] The IDE shall send a ‘ transfer data request card download ’ message to the VU to initiate this mode (see 2.2.2.9).

[DDP_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.

[DDP_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.

[DDP_051] The VU shall then, as applicable, update the Control_Activity_Data or the Card_Download file of the driver card.] ]

(1)

[F1 [F2 [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.] ] ]

Textual Amendments