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)

• — 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.

• — FA 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…).

2.2.3   Message flow

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

2.2.4   Timing

• DDP_019During normal operation the timing parameters shown in the following figure are relevant:

Figure 1

Message flow, timing

Image omitted; see official source

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

Timing Parameter	Lower limit Value (ms)	Upper limit Value (ms)
P1	0	20
P2	20	1 000  [^E0014]
P3	10	5 000
P4	5	20
P5	10	20 minutes

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.

2.2.5   Error handling

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

• DDP_020If 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_021If 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

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. Figure 2

VU error handling Image omitted; see official source

• 1. 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 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.
• DDP_028 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. Figure 3

IDE error handling Image omitted; see official source

2.2.6   Response Message content

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.

2.2.6.1   Positive Response Transfer Data Download Interface Version

• DDP_028aThe data field of the ‘Positive Response Transfer Data Download Interface Version’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 00 Hex:

• Data structure generation 2, version 2 (TREP 00 Hex)

Data element		Comment
DownloadInterfaceVersion		Generation and version of the VU: 02,02 Hex for Generation 2, version 2. Not supported by Generation 1 and Generation 2, version 1 VU, which shall respond negatively (Sub function not supported, see DDP_018)

2.2.6.2   Positive Response Transfer Data Overview

• DDP_029The 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, 21 or 31 Hex and appropriate sub message splitting and counting:

• Data structure generation 1 (TREP 01 Hex)

Data element		Comment
MemberStateCertificate		VU Security certificates
VUCertificate
VehicleIdentificationNumber		Vehicle identification
VehicleRegistrationIdentification
CurrentDateTime		VU current date and time
VuDownloadablePeriod		Downloadable period
CardSlotsStatus		Type of cards inserted in the VU
VuDownloadActivityData		Previous VU download
VuCompanyLocksData		All company locks stored. If the section is empty, only noOfLocks = 0 is sent.
		All company locks stored. If the section is empty, only noOfLocks = 0 is sent.
VuControlActivityData		All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent
		All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent
		All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent
Signature		RSA signature of all data (except certificates) starting from VehicleIdentificationNumber down to last byte of last VuControlActivityData.

Data structure generation 2, version 1 (TREP 21 Hex)

Data element		Comment
MemberStateCertificateRecordArray		Member state certificate
VUCertificateRecordArray		VU certificate
VehicleIdentificationNumberRecordArray		Vehicle identification
VehicleRegistrationIdentificationRecordArray		Vehicle registration number
CurrentDateTimeRecordArray		VU current date and time
VuDownloadablePeriodRecordArray		Downloadable period
CardSlotsStatusRecordArray		Type of cards inserted in the VU
VuDownloadActivityDataRecordArray		Previous VU download
VuCompanyLocksRecordArray		All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent
VuControlActivityRecordArray		All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent
SignatureRecordArray		ECC signature of all preceding data except the certificates.

Data structure generation 2, version 2 (TREP 31 Hex)

Data element		Comment
MemberStateCertificateRecordArray		Member state certificate
VUCertificateRecordArray		VU certificate
VehicleIdentificationNumberRecordArray		Vehicle identification
VehicleRegistrationNumberRecordArray		Vehicle registration number
CurrentDateTimeRecordArray		VU current date and time
VuDownloadablePeriodRecordArray		Downloadable period
CardSlotsStatusRecordArray		Type of cards inserted in the VU
VuDownloadActivityDataRecordArray		Previous VU download
VuCompanyLocksRecordArray		All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent
VuControlActivityRecordArray		All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent
SignatureRecordArray		ECC signature of all preceding data except the certificates.

2.2.6.3   Positive Response Transfer Data Activities

• DDP_030The 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, 22 or 32 Hex and appropriate sub message splitting and counting:

• Data structure generation 1 (TREP 02 Hex)

Data element		Comment
TimeReal		Date of day downloaded
OdometerValueMidnight		Odometer at end of downloaded day
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuCardIWData		Cards insertion withdrawal cycles data. — If this section contains no available data, only noOfVuCardIWRecords = 0 is sent. — When 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.
VuActivityDailyData		Slots status at 00:00 and activity changes recorded for the day downloaded.
		Slots status at 00:00 and activity changes recorded for the day downloaded.
VuPlaceDailyWorkPeriodData		Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.
VuPlaceDailyWorkPeriodData		Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.
VuPlaceDailyWorkPeriodData		Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.
VuSpecificConditionData		Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent
VuSpecificConditionData		Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent
VuSpecificConditionData		Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent
VuSpecificConditionData		Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent
Signature		RSA signature of all data starting from TimeReal down to last byte of last specific condition record.

Data structure generation 2, version 1 (TREP 22 Hex)

Data element		Comment
DateOfDayDownloadedRecordArray		Date of day downloaded
OdometerValueMidnightRecordArray		Odometer at end of downloaded day
VuCardIWRecordArray		Cards insertion withdrawal cycles data. — If this section contains no available data, an array header with noOfRecords = 0 is sent. — When 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.
VuActivityDailyRecordArray		Slots status at 00:00 and activity changes recorded for the day downloaded.
VuPlaceDailyWorkPeriodRecordArray		Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
VuGNSSADRecordArray		GNSS positions of the vehicle if 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.
VuSpecificConditionRecordArray		Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent
SignatureRecordArray		ECC signature of all preceding data.

Data structure generation 2, version 2 (TREP 32 Hex)

Data element		Comment
DateOfDayDownloadedRecordArray		Date of day downloaded
OdometerValueMidnightRecordArray		Odometer at end of downloaded day
VuCardIWRecordArray		Cards insertion withdrawal cycles data. — If this section contains no available data, an array header with noOfRecords = 0 is sent. — When 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.
VuActivityDailyRecordArray		Slots status at 00:00 and activity changes recorded for the day downloaded.
VuPlaceDailyWorkPeriodRecordArray		Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
VuGNSSADRecordArray		GNSS positions of the vehicle if 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.
VuSpecificConditionRecordArray		Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent
VuBorderCrossingRecordArray		Border crossings for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
VuLoadUnloadRecordArray		Load/unload operations for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
SignatureRecordArray		ECC signature of all preceding data.

2.2.6.4   Positive Response Transfer Data Events and Faults

• DDP_031The 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, 23 or 33 Hex and appropriate sub message splitting and counting:

• Data structure generation 1, (TREP 03 Hex)

| Data element | | Comment |

| --- | --- | --- | | VuFaultData | | All faults stored or on-going in the VU. If the section is empty, only noOfVuFaults = 0 is sent. | | VuEventData | | All events (except over speeding) stored or on-going in the VU. If the section is empty, only noOfVuEvents = 0 is sent. | | VuOverSpeedingControlData | | Data related to last over speeding control (default value if no data). | | VuOverSpeedingEventData | | All over speeding events stored in the VU. If the section is empty, only noOfVuOverSpeedingEvents = 0 is sent. | | VuTimeAdjustmentData | | 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. | | Signature | | RSA signature of all data starting from noOfVuFaults down to last byte of last time adjustment record | | | | |

• Data structure generation 2, version 1 (TREP 23 Hex)

| Data element | | Comment |

| --- | --- | --- | | VuFaultRecordArray | | All faults stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. | | VuEventRecordArray | | 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. | | VuOverSpeedingControlDataRecordArray | | Data related to last over speeding control (default value if no data). | | VuOverSpeedingEventRecordArray | | All over speeding events stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent. | | VuTimeAdjustmentRecordArray | | 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. | | SignatureRecordArray | | ECC signature of all preceding data. | | | | |

- Data structure generation 2, version 2 (TREP 33 Hex)

Data element		Comment
VuFaultRecordArray		All faults stored or on-going in the VU. If the section is empty, an array header with noOfRecords = 0 is sent.
VuEventRecordArray		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.
VuOverSpeedingControlDataRecordArray		Data related to last over speeding control (default value if no data).
VuOverSpeedingEventRecordArray		All over speeding events stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent.
VuTimeAdjustmentRecordArray		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.
SignatureRecordArray		ECC signature of all preceding data.

2.2.6.5   Positive Response Transfer Data Detailed Speed

• DDP_032The 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:

• Data structure generation 1 (TREP 04 Hex)

| Data element | | Comment |

| --- | --- | --- | | VuDetailedSpeedData | | 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). | | Signature | | RSA signature of all data starting from noOfSpeedBlocks down to last byte of last speed block. | | | | |

• Data structure generation 2 (TREP 24 Hex)

Data element		Comment
VuDetailedSpeedBlockRecordArray		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).
SignatureRecordArray		ECC signature of all preceding data.

2.2.6.6   Positive Response Transfer Data Technical Data

• 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, 25 or 35 Hex and appropriate sub message splitting and counting:

Data structure generation 1 (TREP 05 Hex)

Data element		Comment
VuIdentification
SensorPaired
VuCalibrationData		All calibration records stored in the VU.
		All calibration records stored in the VU.
Signature		RSA signature of all data starting from vuManufacturerName down to last byte of last VuCalibrationRecord.

Data structure generation 2, version 1 (TREP 25 Hex)

Data element		Comment
VuIdentificationRecordArray
VuSensorPairedRecordArray		All MS pairings stored in the VU
VuSensorExternalGNSSCoupledRecordArray		All external GNSS facility couplings stored in the VU
VuCalibrationRecordArray		All calibration records stored in the VU.
VuCardRecordArray		All card insertion data stored in the VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray		ECC signature of all preceding data.

Data structure generation 2, version 2 (TREP 35 Hex)

Data element		Comment
VuIdentificationRecordArray
VuSensorPairedRecordArray		All MS pairings stored in the VU
VuSensorExternalGNSSCoupledRecordArray		All external GNSS facility couplings stored in the VU
VuCalibrationRecordArray		All calibration records stored in the VU.
VuCardRecordArray		All card insertion data stored in the VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray		ECC signature of all preceding data.

2.3.   ESM File storage

• DDP_034When 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).

3.1.   Scope

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

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

• DDP_035The download of a tachograph card includes the following steps:

• — Download the common information of the card in the EFs ICC and IC. This information is optional and is not secured with a digital signature.

- — For first and second generation tachograph cards

— Download EFs within Tachograph DF: — Download the EFs Card_Certificate and CA_Certificate. 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 Tachograph DF) except EF Card_Download. 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 Application_Identification and Identification for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions.

- — For second generation tachograph 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 Tachograph_G2 DF: — Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate. 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 Tachograph_G2 DF) except EF Card_Download. 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 Application_Identification, Application_Identification_V2 (if present) and Identification for each download session. — When downloading a driver card it is also mandatory to download the following EFs: Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS_Places, Places_Authentication, if present, GNSS_Places_Authentication, if present, Border_Crossings, if present, Load_Unload_Operations, if present, Load_Type_Entries, if present. — When downloading a driver card, update the LastCardDownload date in EF Card_Download, in the Tachograph and, if applicable, Tachograph_G2 DFs. — When downloading a workshop card, reset the calibration counter in EF Card_Download in the Tachograph and, if applicable, Tachograph_G2 DFs. — When downloading a workshop card the EF Sensor_Installation_Data in the Tachograph and, if applicable, Tachograph_G2 DFs shall not be downloaded.

3.3.1   Initialisation sequence

• DDP_036The 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 baud rate as long as the ICC supports it.

3.3.2   Sequence for un-signed data files

• DDP_037 The 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:

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

Note 2: Selecting and reading a file may also be performed in one step using a Read Binary command with a short EF identifier.

3.3.3   Sequence for Signed data files

• DDP_038The following sequence shall be used for each of the following files that has to be downloaded with their signature:

Card	Dir	IDE / IFD	Meaning / Remarks
	Image omitted; see official source	Select File
OK	Image omitted; see official source
	Image omitted; see official source	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	Image omitted; see official source
	Image omitted; see official source	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	Image omitted; see official source	Store received data to ESM	according to 3.4 Data storage format
	Image omitted; see official source	PSO: Compute Digital Signature
Perform Security Operation ‘Compute Digital Signature’ using the temporarily stored Hash value
Signature OK	Image omitted; see official source	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.

3.3.4   Sequence for resetting the calibration counter.

• DDP_039The sequence to reset the Image omitted; see official source counter in the EF Image omitted; see official source in a workshop card is the following:

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.

3.4.   Data storage format

3.4.1   Introduction

• DDP_040The downloaded data has to be stored according to the following conditions:

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

3.4.2   File format

- DDP_041The file format is a concatenation of several TLV objects.

• DDP_042The tag for an EF shall be the FID plus the appendix ‘00’.

• DDP_043The tag of an EF's signature shall be the FID of the file plus the appendix ‘01’.

• DDP_044The 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_045When a file is not downloaded nothing related to the file shall be stored (no tag and no zero length).

• DDP_046A 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) in the Image omitted; see official source or for common information of the card	3 Bytes
FID (2 Bytes) || ‘01’	Tag for Signature of EF (FID) in the Image omitted; see official source DF	3 Bytes
FID (2 Bytes) || ‘02’	Tag for EF (FID) in the Image omitted; see official source DF	3 Bytes
FID (2 Bytes) || ‘03’	Tag for Signature of EF (FID) in the Image omitted; see official source DF	3 Bytes
xx xx	Length of Value field	2 Bytes

• Example of data in a download file on an ESM:

Tag	Length	Value
Image omitted; see official source	Image omitted; see official source	—  Data of EF ICC
Image omitted; see official source	Image omitted; see official source	—  Data of EF Card_Certificate
		—  …
Image omitted; see official source	Image omitted; see official source	Data of EF Image omitted; see official source (in the Image omitted; see official source DF)
Image omitted; see official source	Image omitted; see official source	Signature of EF Image omitted; see official source (in the Image omitted; see official source DF)
Image omitted; see official source	Image omitted; see official source	Data of EF Image omitted; see official source in the Image omitted; see official source DF
Image omitted; see official source	Image omitted; see official source	Signature of EF Image omitted; see official source in the Image omitted; see official source DF

- DDP_047The VU must allow for downloading the content of a driver card inserted to a connected IDE.

• DDP_048The IDE shall send a ‘Transfer Data Request Card Download’ message to the VU to initiate this mode (see 2.2.2.9).

• DDP_049First 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.

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

• DDP_050The 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.

• DDP_051The VU shall then, as applicable, update the Image omitted; see official source or the Image omitted; see official source file of the driver card.

Appendix 8

CALIBRATION PROTOCOL

TABLE OF CONTENT	TABLE OF CONTENT
1.	INTRODUCTION
2.	TERMS, DEFINITIONS AND REFERENCES
3.	OVERVIEW OF SERVICES
3.1.	Services available
3.2.	Response codes
4.	COMMUNICATION SERVICES
4.1.	StartCommunication Service
4.2.	StopCommunication Service
4.2.1	Message description
4.2.2	Message format
4.2.3	Parameter Definition
4.3.	TesterPresent Service
4.3.1	Message description
4.3.2	Message format
5.	MANAGEMENT SERVICES
5.1.	StartDiagnosticSession service
5.1.1	Message description
5.1.2	Message format
5.1.3	Parameter definition
5.2.	SecurityAccess service
5.2.1	Message Description
5.2.2	Message format — SecurityAccess — requestSeed
5.2.3	Message format — SecurityAccess — sendKey
6.	DATA TRANSMISSION SERVICES
6.1.	ReadDataByIdentifier service
6.1.1	Message description
6.1.2	Message format
6.1.3	Parameter Definition
6.2.	WriteDataByIdentifier service
6.2.1	Message description
6.2.2	Message format
6.2.3	Parameter definition
7.	CONTROL OF TEST PULSES — INPUT/OUTPUT CONTROL FUNCTIONAL UNIT
7.1.	InputOutputControlByIdentifier service
7.1.1	Message description
7.1.2	Message format
7.1.3	Parameter definition
8.	ROUTINECONTROL SERVICE (TIME ADJUSTMENT)
8.1.	Message description
8.2.	Message format
9.	DATARECORDS FORMATS
9.1.	Transmitted parameter ranges
9.2.	dataRecords formats

1. INTRODUCTION

This appendix describes how data is exchanged between a vehicle unit and a tester via the K-line which forms part of the calibration interface described in Appendix 6. It also describes control of the input/output signal line on the calibration connector.

Establishing K-line communications is described in Section 4 ‘Communication Services’.

This appendix uses the idea of diagnostic ‘sessions’ to determine the scope of K-line control under different conditions. The default session is the ‘StandardDiagnosticSession’ where all data can be read from a vehicle unit but no data can be written to a vehicle unit.

Selection of the diagnostic session is described in Section 5 ‘Management Services’.

This appendix has to be considered as relevant for both generations of VUs and of workshop cards, in compliance with the interoperability requirements laid down in this Regulation.

• CPR_001The ‘ECUProgrammingSession’ allows data entry into the vehicle unit. In the case of entry of calibration data, the vehicle unit must, in addition be in the CALIBRATION mode of operation.

• Data transfer via K-line is described in Section 6 ‘Data Transmission Services’. Formats of data transferred are detailed in Section 8 ‘dataRecords formats’.

• CPR_002The ‘ECUAdjustmentSession’ allows the selection of the I/O mode of the calibration I/O signal line via the K-line interface. Control of the calibration I/O signal line is described in section 7 ‘Control of Test Pulses — Input/Output Control functional unit’.

• CPR_003Throughout this document the address of the tester is referred to as ‘tt’. Although there may be preferred addresses for testers, the VU shall respond correctly to any tester address. The physical address of the VU is 0xEE.

2. TERMS, DEFINITIONS AND REFERENCES

The protocols, messages and error codes are principally based on a draft of ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services, version 6 of 22 February 2001).

Byte encoding and hexadecimal values are used for the service identifiers, the service requests and responses, and the standard parameters.

The term ‘tester’ refers to the equipment used to enter programming/calibration data into the VU.

The terms ‘client’ and ‘server’ refer to the tester and the VU respectively.

The term ECU means ‘Electronic Control Unit’ and refers to the VU.

References:

ISO 14230-2: Road Vehicles -Diagnostic Systems — Keyword Protocol 2000- Part 2: Data Link Layer.

First edition: 1999.

3.1.   Services available

The following table provides an overview of the services that will be available in the tachograph and are defined in this document.

• CPR_004The table indicates the services that are available in an enabled diagnostic session.

• — The 1st column lists the services that are available.

• — The 2nd column includes the section number in this appendix where of service is further defined.

• — The 3rd column assigns the service identifier values for request messages.

• — The 4th column specifies the services of the ‘StandardDiagnosticSession’ (SD) which must be implemented in each VU.

• — The 5th column specifies the services of the ‘ECUAdjustmentSession’ (ECUAS) which must be implemented to allow control of the I/O signal line in the front panel calibration connector of the VU.

• — The 6th column specifies the services of the ‘ECUProgrammingSession’ (ECUPS) which must be implemented to allow for programming of parameters in the VU.

Table 1

Service Identifier value summary table

			Diagnostic Sessions	Diagnostic Sessions	Diagnostic Sessions
Diagnostic Service Name	Section No.	SId Req.Value	SD	ECUAS	ECUPS
StartCommunication	4.1	81	■	■	■
StopCommunication	4.2	82	■
TesterPresent	4.3	3E	■	■	■
StartDiagnosticSession	5.1	10	■	■	■
SecurityAccess	5.2	27	■	■	■
ReadDataByIdentifier	6.1	22	■	■	■
WriteDataByIdentifier	6.2	2E			■
InputOutputControlByIdentifier	7.1	2F		■
RoutineControl	8	31		Image omitted; see official source	Image omitted; see official source
■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.	■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.	■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.	■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.	■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.	■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.

3.2.   Response codes

Response codes are defined for each service.

Some services are necessary to establish and maintain communication. They do not appear on the application layer. The services available are detailed in the following table:

Table 2

Communication Services

Service name	Description
StartCommunication	The client requests to start a communication session with a server(s).
StopCommunication	The client requests to stop the current communication session.
TesterPresent	The client indicates to the server that it is still present.

• CPR_005The StartCommunication Service is used for starting a communication. In order to perform any service, communication must be initialised and the communication parameters need to be appropriate for the desired mode.

4.1.   StartCommunication Service

• CPR_006Upon receiving a StartCommunication indication primitive, the VU shall check if the requested communication link can be initialised under the present conditions. Valid conditions for the initialisation of a communication link are described in document ISO 14230-2.

• CPR_007Then the VU shall perform all actions necessary to initialise the communication link and send a StartCommunication response primitive with the Positive Response parameters selected.

- CPR_008If a VU that is already initialised (and has entered any diagnostic session) receives a new StartCommunication Request (e.g. due to error recovery in the tester) the request shall be accepted and the VU shall be reinitialised.

- CPR_009If the communication link cannot be initialised for any reason, the VU shall continue operating as it was immediately prior to the attempt to initialise the communication link..

• CPR_010The StartCommunication Request message must be physically addressed.

- CPR_011Initialising the VU for services is performed through a ‘fast initialisation’ method,

- — There is a bus-idle time prior to any activity.

• — The tester then sends an initialisation pattern.

• — All information which is necessary to establish communication is contained in the response of the VU.

- CPR_012After completion of the initialisation,

- — All communication parameters are set to values defined in Table 4 according to the key bytes.

• — The VU is waiting for the first request of the tester.

- — The VU is in the default diagnostic mode, i.e. StandardDiagnosticSession.

- — The calibration I/O signal line is in the default state, i.e. disabled state.

• CPR_014The data rate on the K-line shall be 10 400 Baud.

• CPR_016The fast initialisation is started by the tester transmitting a Wake up pattern (Wup) on the K-line. The pattern begins after the idle time on K-line with a low time of Tinil. The tester transmits the first bit of the StartCommunication Service after a time of Twup following the first falling edge.

- Image omitted; see official source

- CPR_017The timing values for the fast initialisation and communications in general are detailed in the tables below. There are different possibilities for the idle time:

• — First transmission after power on, Tidle = 300 ms.

• — After completion of a StopCommunication Service, Tidle = P3 min.

• — After stopping communication by time-out P3 max, Tidle = 0.

Table 3

Timing values for fast initialisation

| Parameter | Parameter | min value | max value |

| --- | --- | --- | --- | | Tinil | 25 ± 1 ms | 24 ms | 26 ms | | Twup | 50 ± 1 ms | 49 ms | 51 ms |

Table 4

Communication timing values

| Timing Parameter | Parameter Description | lower limit values [ms] | upper limit values [ms] |

| --- | --- | --- | --- | | Timing Parameter | Parameter Description | min. | max. | | P1 | Inter byte time for VU response | 0 | 20 | | P2 | Time between tester request and VU response or two VU responses | 25 | 250 | | P3 | Time between end of VU responses and start of new tester request | 55 | 5 000 | | P4 | Inter byte time for tester request | 5 | 20 |

• CPR_018The message format for fast initialisation is detailed in the following tables. (NOTE: Hex means hexadecimal)

Table 5

StartCommunication Request Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	81	FMT
#2	Target address byte	EE	TGT
#3	Source address byte	tt	SRC
#4	StartCommunication Request Service Id	81	SCR
#5	Checksum	00-FF	CS

Table 6

StartCommunication Positive Response Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	tt	TGT
#3	Source address byte	EE	SRC
#4	Additional length byte	03	LEN
#5	StartCommunication Positive Response Service Id	C1	SCRPR
#6	Key byte 1	EA	KB1
#7	Key byte 2	8F	KB2
#8	Checksum	00-FF	CS

- CPR_019There is no negative response to the StartCommunication Request message, if there is no positive response message to be transmitted then the VU is not initialised, nothing is transmitted and it remains in its normal operation.

4.2.   StopCommunication Service

4.2.1   Message description

The purpose of this communication layer service is to terminate a communication session.

• CPR_020Upon receiving a StopCommunication indication primitive, the VU shall check if the current conditions allow to terminate this communication. In this case the VU shall perform all actions necessary to terminate this communication.

- CPR_021If it is possible to terminate the communication, the VU shall issue a StopCommunication response primitive with the Positive Response parameters selected, before the communication is terminated.

• CPR_022If the communication cannot be terminated by any reason, the VU shall issue a StopCommunication response primitive with the Negative Response parameter selected.

- CPR_023If time-out of P3 max is detected by the VU, the communication shall be terminated without any response primitive being issued.

4.2.2   Message format

• CPR_024The message formats for the StopCommunication primitives are detailed in the following tables.

Table 7

StopCommunication Request Message

| Byte # | Parameter Name | Hex Value | Mnemonic |

| --- | --- | --- | --- | | #1 | Format byte — physical addressing | 80 | FMT | | #2 | Target address byte | EE | TGT | | #3 | Source address byte | tt | SRC | | #4 | Additional length byte | 01 | LEN | | #5 | StopCommunication Request Service Id | 82 | SPR | | #6 | Checksum | 00-FF | CS |

Table 8

StopCommunication Positive Response Message

| Byte # | Parameter Name | Hex Value | Mnemonic |

| --- | --- | --- | --- | | #1 | Format byte — physical addressing | 80 | FMT | | #2 | Target address byte | tt | TGT | | #3 | Source address byte | EE | SRC | | #4 | Additional length byte | 01 | LEN | | #5 | StopCommunication Positive Response Service Id | C2 | SPRPR | | #6 | Checksum | 00-FF | CS |

Table 9

StopCommunication Negative Response Message

| Byte # | Parameter Name | Hex Value | Mnemonic |

| --- | --- | --- | --- | | #1 | Format byte — physical addressing | 80 | FMT | | #2 | Target address byte | tt | TGT | | #3 | Source address byte | EE | SRC | | #4 | Additional length byte | 03 | LEN | | #5 | negative Response Service Id | 7F | NR | | #6 | StopCommunication Request Service Identification | 82 | SPR | | #7 | responseCode = generalReject | 10 | RC_GR | | #8 | Checksum | 00-FF | CS |

4.2.3   Parameter Definition

This service does not require any parameter definition.

4.3.   TesterPresent Service

4.3.1   Message description

The TesterPresent service is used by the tester to indicate to the server that it is still present, in order to prevent the server from automatically returning to normal operation and possibly stopping the communication. This service, sent periodically, keeps the diagnostic session/communication active by resetting the P3 timer each time a request for this service is received.

4.3.2   Message format

• CPR_079The message formats for the TesterPresent primitives are detailed in the following tables.

Table 10

TesterPresent Request Message

Byte #	Parameter Name	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	Format byte — physical addressing	80	FMT
#2	Target address byte	Target address byte	EE	TGT
#3	Source address byte	Source address byte	tt	SRC
#4	Additional length byte	Additional length byte	02	LEN
#5	TesterPresent Request Service Id	TesterPresent Request Service Id	3E	TP
#6	Sub Function = responseRequired =	[ yes	01	RESPREQ_Y
#6	Sub Function = responseRequired =	no ]	02	RESPREQ_NO
#7	Checksum	Checksum	00-FF	CS

• CPR_080If the responseRequired parameter is set to ‘yes’, then the server shall respond with the following positive response message. If set to ‘no’, then no response is sent by the server.

Table 11

TesterPresent Positive Response Message

| Byte # | Parameter Name | Hex Value | Mnemonic |

| --- | --- | --- | --- | | #1 | Format byte — physical addressing | 80 | FMT | | #2 | Target address byte | tt | TGT | | #3 | Source address byte | EE | SRC | | #4 | Additional length byte | 01 | LEN | | #5 | TesterPresent Positive Response Service Id | 7E | TPPR | | #6 | Checksum | 00-FF | CS |

• CPR_081The service shall support the following negative responses codes:

Table 12

TesterPresent Negative Response Message

Byte #	Parameter Name	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	Format byte — physical addressing	80	FMT
#2	Target address byte	Target address byte	tt	TGT
#3	Source address byte	Source address byte	EE	SRC
#4	Additional length byte	Additional length byte	03	LEN
#5	negative Response Service Id	negative Response Service Id	7F	NR
#6	TesterPresent Request Service Identification	TesterPresent Request Service Identification	3E	TP
#7	responseCode =	[SubFunctionNotSupported-InvalidFormat	12	RC_SFNS_IF
#7	responseCode =	incorrectMessageLength]	13	RC_IML
#8	Checksum	Checksum	00-FF	CS

5. MANAGEMENT SERVICES

The services available are detailed in the following table:

Table 13

Management Services

| Service name | Description |

| --- | --- | | StartDiagnosticSession | The client requests to start a diagnostic session with a VU. | | SecurityAccess | The client requests access to functions restricted to authorised users. |

5.1.   StartDiagnosticSession service

5.1.1   Message description

• CPR_025The service StartDiagnosticSession is used to enable different diagnostic sessions in the server. A diagnostic session enables a specific set of services according to Table 17. A session can enable vehicle manufacturer specific services which are not part of this document. Implementation rules shall conform to the following requirements:

• — There shall be always exactly one diagnostic session active in the VU,

- — The VU shall always start the StandardDiagnosticSession when powered up. If no other diagnostic session is started, then the StandardDiagnosticSession shall be running as long as the VU is powered,

• — If a diagnostic session which is already running has been requested by the tester, then the VU shall send a positive response message,

- — Whenever the tester requests a new diagnostic session, the VU shall first send a StartDiagnosticSession positive response message before the new session becomes active in the VU. If the VU is not able to start the requested new diagnostic session, then it shall respond with a StartDiagnosticSession negative response message, and the current session shall continue.

- CPR_026A diagnostic session shall only be started if communication has been established between the client and the VU.

• CPR_027The timing parameters defined in Table 4 shall be active after a successful StartDiagnosticSession with the diagnosticSession parameter set to ‘StandardDiagnosticSession’ in the request message if another diagnostic session was previously active.

5.1.2   Message format

• CPR_028The message formats for the StartDiagnosticSession primitives are detailed in the following tables.

Table 14

StartDiagnosticSession Request Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	EE	TGT
#3	Source address byte	tt	SRC
#4	Additional length byte	02	LEN
#5	StartDiagnosticSession Request Service Id	10	STDS
#6	diagnosticSession = [one value from Table 17]	xx	DS_…
#7	Checksum	00-FF	CS

Table 15

StartDiagnosticSession Positive Response Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	tt	TGT
#3	Source address byte	EE	SRC
#4	Additional length byte	02	LEN
#5	StartDiagnosticSession Positive Response Service Id	50	STDSPR
#6	diagnosticSession = [same value as in byte #6 Table 14]	xx	DS_…
#7	Checksum	00-FF	CS

Table 16

StartDiagnosticSession Negative Response Message

Byte #	Parameter Name	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	Format byte — physical addressing	80	FMT
#2	Target address byte	Target address byte	tt	TGT
#3	Source address byte	Source address byte	EE	SRC
#4	Additional length byte	Additional length byte	03	LEN
#5	Negative Response Service Id	Negative Response Service Id	7F	NR
#6	StartDiagnosticSession Request Service Id	StartDiagnosticSession Request Service Id	10	STDS
#7	ResponseCode =	[subFunctionNotSupported [^E0015]	12	RC_SFNS
#7	ResponseCode =	incorrectMessageLength [^E0016]	13	RC_IML
#7	ResponseCode =	conditionsNotCorrect [^E0017]	22	RC_CNC
#8	Checksum	Checksum	00-FF	CS

– the value inserted in byte #6 of the request message is not supported, i.e. not in Table 17,

– the length of the message is wrong,

– the criteria for the request StartDiagnosticSession are not met.

5.1.3   Parameter definition

• CPR_029The parameter diagnosticSession (DS_) is used by the StartDiagnosticSession service to select the specific behaviour of the server(s). The following diagnostic sessions are specified in this document:

Table 17

Definition of diagnosticSession Values

Hex	Description	Mnemonic
81	StandardDiagnosticSession This diagnostic session enables all services specified in Table 1 column 4 ‘SD’. These services allow reading of data from a server (VU). This diagnostic Session is active after the initialisation has been successfully completed between client (tester) and server (VU). This diagnostic session may be overwritten by other diagnostic sessions specified in this section.	SD
85	ECUProgrammingSession This diagnostic session enables all services specified in Table 1 column 6 ‘ECUPS’. These services support the memory programming of a server (VU) This diagnostic session may be overwritten by other diagnostic sessions specified in this section..	ECUPS
87	ECUAdjustmentSession This diagnostic session enables all services specified in Table 1 column 5 ‘ECUAS’. These services support the input/output control of a server (VU). This diagnostic session may be overwritten by other diagnostic sessions specified in this section.	ECUAS

5.2.   SecurityAccess service

Writing of calibration data is not possible unless the VU is in CALIBRATION mode. In addition to insertion of a valid workshop card into the VU, it is necessary to enter the appropriate PIN into the VU before access to the CALIBRATION mode is granted.

When the VU is in CALIBRATION or CONTROL mode, access to the calibration input/output line is also possible.

The SecurityAccess service provides a means to enter the PIN and to indicate to the tester whether or not the VU is in CALIBRATION mode.

It is acceptable that the PIN may be entered through alternative methods.

5.2.1   Message Description

The SecurityAccess service consists of a SecurityAccess ‘requestSeed’ message, eventually followed by a SecurityAccess ‘sendKey’ message. The SecurityAccess service must be carried out after the StartDiagnosticSession service.

• CPR_033The tester shall use the SecurityAccess ‘requestSeed’ message to check if the vehicle unit is ready to accept a PIN.

- CPR_034If the vehicle unit is already in CALIBRATION mode, it shall answer the request by sending a ‘seed’ of 0x0000 using the service SecurityAccess Positive Response.

- CPR_035If the vehicle unit is ready to accept a PIN for verification by a workshop card, it shall answer the request by sending a ‘seed’ greater than 0x0000 using the service SecurityAccess Positive Response.

• CPR_036If the vehicle unit is not ready to accept a PIN from the tester, either because the workshop card inserted is not valid, or because no workshop card has been inserted, or because the vehicle unit expects the PIN from another method, it shall answer the request with a Negative Response with a response code set to conditionsNotCorrectOrRequestSequenceError.

- CPR_037The tester shall then, eventually, use the SecurityAccess ‘sendKey’ message to forward a PIN to the Vehicle Unit. To allow time for the card authentication process to take place, the VU shall use the negative response code requestCorrectlyReceived-ResponsePending to extend the time to respond. However, the maximum time to respond shall not exceed 5 minutes. As soon as the requested service has been completed, the VU shall send a positive response message or negative response message with a response code different from this one. The negative response code requestCorrectlyReceived-ResponsePending may be repeated by the VU until the requested service is completed and the final response message is sent.

• CPR_038The vehicle unit shall answer to this request using the service SecurityAccess Positive Response only when in CALIBRATION mode.

- CPR_039In the following cases, the vehicle unit shall answer to this request with a Negative Response with a response code set to:

- — subFunctionNot supported: Invalid format for the subfunction parameter (accessType),

• — conditionsNotCorrectOrRequestSequenceError: Vehicle unit not ready to accept a PIN entry,

- — invalidKey: PIN not valid and number of PIN checks attempts not exceeded,

- — exceededNumberOfAttempts: PIN not valid and number of PIN checks attempts exceeded,

• — generalReject: Correct PIN but mutual authentication with workshop card failed.

5.2.2   Message format — SecurityAccess — requestSeed

- CPR_040The message formats for the SecurityAccess ‘requestSeed’ primitives are detailed in the following tables.

Table 18

SecurityAccess Request- requestSeed Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	EE	TGT
#3	Source address byte	tt	SRC
#4	Additional length byte	02	LEN
#5	SecurityAccess Request Service Id	27	SA
#6	accessType — requestSeed	7D	AT_RSD
#7	Checksum	00-FF	CS

Table 19

SecurityAccess — requestSeed Positive Response Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	tt	TGT
#3	Source address byte	EE	SRC
#4	Additional length byte	04	LEN
#5	SecurityAccess Positive Response Service Id	67	SAPR
#6	accessType — requestSeed	7D	AT_RSD
#7	Seed High	00-FF	SEEDH
#8	Seed Low	00-FF	SEEDL
#9	Checksum	00-FF	CS

Table 20

SecurityAccess Negative Response Message

Byte #	Parameter Name	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	Format byte — physical addressing	80	FMT
#2	Target address byte	Target address byte	tt	TGT
#3	Source address byte	Source address byte	EE	SRC
#4	Additional length byte	Additional length byte	03	LEN
#5	negativeResponse Service Id	negativeResponse Service Id	7F	NR
#6	SecurityAccess Request Service Id	SecurityAccess Request Service Id	27	SA
#7	responseCode =	[conditionsNotCorrectOrRequestSequenceError	22	RC_CNC
#7	responseCode =	incorrectMessageLength]	13	RC_IML
#8	Checksum	Checksum	00-FF	CS

5.2.3   Message format — SecurityAccess — sendKey

• CPR_041The message formats for the SecurityAccess ‘sendKey’ primitives are detailed in the following tables.

Table 21

SecurityAccess Request — sendKey Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	EE	TGT
#3	Source address byte	tt	SRC
#4	Additional length byte	m+2	LEN
#5	SecurityAccess Request Service Id	27	SA
#6	accessType — sendKey	7E	AT_SK
#7 to #m + 6	Key #1 (High)	xx	KEY
#7 to #m + 6	…	…
#7 to #m + 6	Key #m (low, m must be a minimum of 4, and a maximum of 8)	xx
#m + 7	Checksum	00-FF	CS

Table 22

SecurityAccess — sendKey Positive Response Message

Byte #	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	80	FMT
#2	Target address byte	tt	TGT
#3	Source address byte	EE	SRC
#4	Additional length byte	02	LEN
#5	SecurityAccess Positive Response Service Id	67	SAPR
#6	accessType — sendKey	7E	AT_SK
#7	Checksum	00-FF	CS

Table 23

SecurityAccess Negative Response Message

Byte #	Parameter Name	Parameter Name	Hex Value	Mnemonic
#1	Format byte — physical addressing	Format byte — physical addressing	80	FMT
#2	Target address byte	Target address byte	tt	TGT
#3	Source address byte	Source address byte	EE	SRC
#4	Additional length byte	Additional length byte	03	LEN
#5	NegativeResponse Service Id	NegativeResponse Service Id	7F	NR
#6	SecurityAccess Request Service Id	SecurityAccess Request Service Id	27	SA
#7	ResponseCode =	[generalReject	10	RC_GR
#7	ResponseCode =	subFunctionNotSupported	12	RC_SFNS
#7	ResponseCode =	incorrectMessageLength	13	RC_IML
#7	ResponseCode =	conditionsNotCorrectOrRequestSequenceError	22	RC_CNC
#7	ResponseCode =	invalidKey	35	RC_IK
#7	ResponseCode =	exceededNumberOfAttempts	36	RC_ENA
#7	ResponseCode =	requestCorrectlyReceived-ResponsePending]	78	RC_RCR_RP
#8	Checksum	Checksum	00-FF	CS

6. DATA TRANSMISSION SERVICES

The services available are detailed in the following table:

Table 24