- Latest available (Revised)
- Original (As adopted by EU)
Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport
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 currently no known outstanding effects for the Council Regulation (EEC) No 3821/85, Division 2. .
Revised legislation carried on this site may not be fully up to date. At the current time any known changes or effects made by subsequent legislation have been applied to the text of the legislation you are viewing by the editorial team. Please see ‘Frequently Asked Questions’ for details regarding the timescales for which new effects are identified and recorded on this site.
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 — 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 ).
[DDP_002] All the messages exchanged between the IDE and the VU are formatted with a structure consisting of three parts:
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 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 |
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: | |||||||||
| |||||||||
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
X1 Substituted by Corrigendum to Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Official Journal of the European Communities L 207 of 5 August 2002).
Textual Amendments
[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).
[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.
[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.
[DDP_008] The positive response start diagnostic message is sent by the VU to answer positively to Diagnostic Session Request.
[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
[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).
[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.
[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.
[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:
overview (TRTP 01),
activities of a specified date (TRTP 02),
events and faults (TRTP 03),
detailed speed (TRTP 04),
technical data (TRTP 05),
card download (TRTP 06).
[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.
[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:
security certificates,
vehicle identification,
VU current date and time,
minimum and maximum downloadable date (VU data),
indication of cards presence in the VU,
previous download to a company,
company locks,
previous controls.
[DDP_013] The request transfer exit message is sent by the IDE to inform the VU that the download session is terminated.
[DDP_014] The positive response request transfer exit message is sent by the VU to acknowledge the Request Transfer Exit.
[DDP_015] The stop communication request message is sent by the IDE to disconnect the communication link with the VU.
[DDP_016] The positive response stop communication message is sent by the VU to acknowledge the stop communication request.
[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:
MsgC +1 Acknowledges correct receipt of submessage number MsgC.
Request from the IDE to the VU to send next submessage,
MsgC indicates a problem with the receipt of submessage number MsgC.
Request from the IDE to the VU to send the submessage 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 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:
positive response transfer Data (SID 76)
[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:
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
FA data not available
The data object of a data transfer request are not available in the VU (e.g. no card is inserted, …)
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 |
[DDP_019] During normal operation the timing parameters shown in the following figure are relevant:
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 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 |
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.
[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.
Two different error handling areas can be defined:
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.
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.
This paragraph specifies the content of the data fields of the various positive response messages.
Data elements are defined in Appendix 1 data dictionary.
[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:
[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:
[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:
[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:
[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:
[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).] ]
Textual Amendments
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: