02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc

Date: 09/04/2008 Classification level 1- Internal
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
This document is the property of PSA Peugeot Citroën; it may not be communicated to third parties and/or reproduced without the prior written consent of PSA Peugeot Citroën and
its content may not be disclosed.
Reference:
96 463 229 99 Ind. F
Applicable to projects:
Generic
Effective date: 09/04/2008
Page 1 of 40
TS_Implementation_of_the_network_layer_for_the_diag
nostic_CAN_and_LIN_networks
PURPOSE: This document gives details on the implementation of the standard ISO 15765-2
(Diagnostic on Can) on the CAN networks, as well as the conversion for the LIN ECUs
diagnostic.
WRITTEN BY VERIFIED BY APPROVED BY
A.PROVO
DTI/DITV/AEEV/AESV/AERE
J. D.BAUDREUIL
DTI/DITV/AEEV/AESV/AERE
This document is managed under DocInfo
No printed copy is managed. PSA breakdown: 98B
PSA PEUGEOT CITROËN

Generic 96 463 229 99 Ind. F TS_Implementation_of_the_network_layer_for_the_diagno
stic_CAN_and_LIN_networks
Page 2 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
History of the document
Version Index Date Detail of modifications
9A A June 2001 First diffusion
9B B October
2001
5.3.1 “After-sales diagnostic session” renamed” Active diagnostic communication session”
Removal of the “Programming session”.
6.3.1 Setting of the BS to 0 for the Active diagnostic session; removal of N-Wtmax (no
longer used).
7.3 Details concerning the long execution requests.
9.1 Addition of format example of the diagnostic service and of the segmenting timing with
the gateway.
9C C January
2002
Insertion of the requirement numbers in the document.
6.3.3 Details on the timings values
99 OR February
2003
The requirement numbers have been updated by removing the “9C” index from the
numbering. All requirements modified in the future will have an index number after their
number.
Example: 463.229-9C-0005-01A becomes 463.229-0005-01A
Example with future index: 463.229-0005-01A.2
§4: Removal of the paragraph. The following paragraphs are consequently renumbered
Modifying the requirement 463.229-0005-01A: No stuffing of the frames shorter than 8
bytes.
§4.3: Note on the different implementation of the diagnostic sessions on the ECU diagnostic
sessions on the Inter-Systems networks, of the ECU on the Comfort and Body networks
Addition of §4.4 and 4.5, depending on whether we address to the CAN Inter-Systems or to
the CAN Comfort and Body.
Requirements 463.229-0003-01C and 463.229-0011-01N removed.
Requirement 463.229-0011-01P added.
Removal of the note in §463.229-0012
Addition of paragraphs §§463.229-0020 to –0023 and of the associated requirements.
Addition of the requirement 463.229-0030-01D
Removal of the requirements 463.229-0110-01A, -01C.
Addition of the requirement 463.229-0110-01D.
Modification of the timing values on the requirements 463.229-0112-01A to –01F. Addition
of –01G and of –01H.
Adding the requirement 463.229-0205-01D.
§463.229-0110: Removal of the comment on the average value of the delays between 2
segments.
Removal of the operation mode 2 from §463.229-0205.
99 Ind. A September
2004
The diagnostic of ECUs on the LIN network is added.
Modification of the document title to acknowledge the LIN acknowledgement.
Modification of the copywriter and verifier and addition of a verifier.

Page 3 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Page layout modified (1st
page, headers and footers).
Details on the exchange types (master - slave, half-duplex, gateways) (§ 5.1.1) and the
authorized and prohibited interlacing (§ 5.2.3.3.)
Addition of the chapter § 5.1.2.3 ECU connected to the LIN networks: addition of the CAN
identifiers requirements for routing, on the CAN networks, the diagnostic messages for a
LIN ECU.
§ 5.2.1 “Frames size” now has 2 chapters “ECU connected on the CAN networks” and
“ECU connected on the LIN networks.”
No segmentation on the LIN (§ 5.2.1.2.)
Stuffing of the LIN frames if needed to obtain 8 byte frames (§ 5.2.1.2.)
§ 5.2.2: addition of the requirement 463.229-0006-01B concerning the LIN frames
format.
§ 5.2.3.3 : Addition of the requirement on the interlacing of the diagnostic requests
463.229-0007-03A to 463.229-0007-03F.
Details on the timings P2, P3max, T_Ret et T_Diag (§ 5.2.4.)
Details on the management of the LIN networks if the CAN networks of the LIN
master is in Com_Off status. ( § 5.4.3.)
Details on using the maximum delays T_Ret et T_Diag ( § 5.6.)
Addition of requirement 463.229-0030-01E on the T_Diag for the LIN ECU ( § 5.6.)
§ 6.1.4 Flow Control: Addition of the management of the “Overflow” value of the FS field
in the FlowControl message of the segmentation protocol for CAN.
The old chapter 6 “Accessible services” is removed and transferred in document [5]
“Keyword Protocol 2000 - 3F Implementation of the diagnostic services” (requirements
463.229-0204-01A, 463.229-0205-01A, 463.229-0205-01B, 463.229-0205-01C &
463.229-0205-01D removed.)
Details on the requirements concerning the error management (§ 7 “Strategy for error
recovery 463.229-0300”.)
99 Ind. B 22/12/04 Written by: C.MARCHAND
Details on the field of application of the LIN ECUs (only those who implement a
diagnostic session are covered).
Details on the requirement 463.229-0005-02A.
Addition of requirements 463.229-0005-02E, 463.229-0005-02F, 463.229-0005-02G
that more accurately describe the diagnostic implementation on the LIN concerning
padding bytes.
Modification of requirements 463.229-0006-01B, 463.229-0006-01C, 463.229-0006-
01D.
Hosting of the diagnostic requirements initially in the document Specification of the
LIN communication rules (STE 96.459.907.9C), in order to regroup the diagnostic in
the same document; requirements renumbered in 463.229-0006-01E to 463.229-0006-
01M.
463.229-0112-01H must also be applied to the BSI.
Addition of chapter 8 “by ECU type” which indicates which requirement is applied to
each of the following types: Diagnostic tool, BSI, ECU diagnosed on Powertrain CAN,
ECU diagnosed on body CAN, ECU diagnosed on the LIN, CAN/CAN diagnostic
gateway ECU, CAN/LIN diagnostic gateway ECU.

Page 4 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
99 C 04/07/05 Written by: C.MARCHAND
463.229-0005-02H added (except from the LIN Com rules document: 459.907-C.O-
0302.01C).
The requirement 463.229-0007-03E is inserted in the application matrix (omitted in
version B).
463.229-0012-01E added (except from the LIN Com rules document: 459.907-C.A-
0302.01A): network life phase in which the BSI diagnostic gateway must operate.
463.229-0030-01E modified: for the LIN master, the maximum delay that separates the
emission of the request from the reception switches from 90 ms to 150 ms (level 1
master (BSI) or level 2 (CAN LS ECU))
Details on the overflow management for the body ECUs (Chapter 6.1.4, requirements
463.229-0105-01A to F): All tools must be able to receive a message with the
maximum size of 4095 bytes; it therefore must not generate an overflow. Consequently,
an ECU must not manage the overflow of a tool (namely a tool which sends to it an
overflow status) => stopping of the sending and error upload. On the other hand the
ECU must generate the emission of the overflow status if it receive a block whose size
exceeds his capacity (the tool must then stop its emission).
§8 Allocation matrix updated after creating the requirements.
The requirements 463.229-0112-01C and 463.229-0112-01E are modified to specify
that the delays N_Bs and N_Cr differ from for the CAN_IS ECUs (1000 ms), and are
250 ms for the body side (in the previous version, it was erroneously set to 250 ms for
all ECUs).
99 D 21/12/2006 Written by: C. MEUNIER
Modifications linked to the implementation of the UDS and LIN 2.1 protocol.
Addition of a glossary.
Addition of the conventions for writing requirements.
Modification of the paragraphs' numbering.
Paragraph 6.1.1: modifications and comments.
Requirements 463.229-0003-01A, 463.229-0003-01B, 463.229-0003-02A 463.229-
0003-02B modified for handling of the CAN LAS and of the Hybrids.
Addition of the requirements 463.229-0003-02C and 463.229-0003-02D.
Paragraph 6.2.1.1: modifications and comments.
Requirement 463.229-0005-01C modified, applicable to KWP only
Requirement 463.229-0005-01D added
Adding of chapter 6.2.1.3
Modification of the chapter structure 6.2.2
Requirement 463.229-0006-01F modified.
Addition of the the chapter 6.2.2.3 and of the associated requirements: 463.229-0006-
02B, 463.229-0006-02C, 463.229-0006-02D, 463.229-0006-02E, 463.229-0006-02F,
463.229-0006-02G, 463.229-0006-02H and 463.229-0006-02I.

Page 5 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Modification of the comments in chapter 6.2.3.
Modification of the comments in chapter 6.3.1
Deletion of the requirement 463.229-0012-01E.
Modification of the requirement 463.229-0030-01E, this parameter is described in the
CAN/LIN gateways documents
Modification of the comments in the chapter.
Adding of chapter 8
Modification of the requirements 463.229-0300-01A and 463.229-0300-01A. They are
only applicable to the body.
Requirements 463.229-0300-01G: insertion of T_Diag LIN.
The chapter concerning the segmentation mechanisms is applicable to the KWP
protocol only. Concerning the UDS, these requirements are included in the document
Error! Reference source not found..
Modification of chapter 11
99 E 26/04/2007 Written by: C. MEUNIER
Update of the reference documents.
Modification of chapter 6.2.1.1 for handling of the ECUs respecting the communication
rules of the document[10]
Handling of some LIN ECUs in the requirement 463.229-0005-01B
Deletion of the requirement 463.229-0007-03F
Details on the handling of the requirements 463.229-0108-01A, 463.229-0108-01B,
463.229-0108-01C, 463.229-0108-01D, 463.229-0108-01E and 463.229-0108-01F by
LIN ECus.
Minor modifications of the requirements 463.229-0300-01A, 463.229-0300-01B,
463.229-0300-01C, 463.229-0300-01D and 463.229-0300-01E.
The note is placed as a footnote for requirement 463.229-0006-01M.1
Addition of the requirement 463.229-0005-01
Deletion of the requirement 463.229-0006-01A.
Deletion of the requirements 463.229-0012-01A.1 463.229-0012-01B.1 463.229-0012-
01C.1
Addition of the requirement 463.229-0012-01E.1
Modification of the requirements 463.229-0112-01C, 463.229-0112-01E and 463.229-
0112-01H and 463.229-0110-01B.1
Addition of the requirements 463.229-0112-01I and 463.229-0110-01E to solve the
"jitter" problems in the gateways.
99 F 09/04/08 Written by: A. PROVO
Update of the reference documents.

Page 6 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
§6.2.1.1: Rephrasing of the requirement 463.229-0005-01A (replaced empty bytes by
stuffing bytes)
Correction of the requirement 463.229-0005-0E (max byte number is 7 for a
single_frame CAN)
Addition of the requirement 463.229-0005-0F (max byte number is 6 for a segmented
single_frame LIN)
§6.2.2.3: Modification of the requirement 463.229-0006-02B (replaced format by
protocol)
§6.4 : Modification of the requirement 463.229-0030-01A (T_Ret)
Addition of the requirement 463.229-0030-01F (T_Ret_LIN)
§7.1.4.1 : Deletion of the requirement 463.229-0105-01D (confusing)
§7.2.2.2 : Rephrasing of the requirement 463.229-0108-01E
§7.4 : Modification of the requirements 463.229-0112-01F, 463.229-0112-01G (N_Cs),
463.229-0112-01D and deletion of the requirement 463.229-0112-01H (copied out in
the previous requirements)
§8.1: More detailed description of the LIN frames from document [10]
Moving of the requirements 463.229-0006-02F and 463.229-0006-02H
Rephrasing of the requirement 463.229-0006-02G
Addition of the requirements 463.229-0006-02J, 463.229-0006-02K, 463.229-0006-
02L, 463.229-0006-02M, 463.229-0006-02N and 463.229-0006-02O
§8.4 : Correction of the requirement 463.229-0113-01C
Modification of the requirement 463.229-0113-01E (max value N_Cs_LIN)
§9: Modification of the requirement 463.229-0300-01F (T_Ret_LIN)
§10 : Deletion of the paragraph on maintaining the diagnostic sessions, refer to the
protocol Spécification
§11 : Deletion of appendixes

Page 7 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Contents
History of the document........................................................................................................................ 2
Contents................................................................................................................................................. 7
1 Purpose ........................................................................................................................................... 9
2 Scope ............................................................................................................................................. 10
3 Reference documents.................................................................................................................... 11
3.1 Internal PSA justification file ...........................................................................................................11
3.2 PSA internal documents....................................................................................................................11
3.3 Standards and procedures.................................................................................................................11
4 Terminology.................................................................................................................................. 12
4.1 Glossary ..............................................................................................................................................12
4.2 Glossary...............................................................................................................................................12
4.3 Abbreviations and acronyms ............................................................................................................12
5 Agreements ................................................................................................................................... 13
5.1 Presenting a requirement ..................................................................................................................13
5.2 Numbering a requirement.................................................................................................................13
6 Communication protocol.............................................................................................................. 14
6.1 Principles of communication.............................................................................................................14
6.1.1 Exchange Type ............................................................................................................................................14
6.1.2 Addressing mode and Identifier...................................................................................................................15
6.1.2.1 ECU connected to the CAN Comfort, Body and Entertainment networks ..............................................15
6.1.2.2 ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid network.................................15
6.1.2.3 ECU connected to the LIN networks that implement the protocol described in the document [3] or [14]
15
6.1.2.4 ECU connected to the LIN networks that implement the protocol described in the document [10]........16
6.1.2.5 ECU connected to the CAN-DIAG network............................................................................................16
6.2 Request/response mode......................................................................................................................16
6.2.1 Requests and replies size and frame size .....................................................................................................16
6.2.1.1 ECU not being a LIN ECU and that respects the communication rules of the document [3] or [14] ......16
6.2.1.2 ECU connected on the LIN sub-networks respecting the communication rules from document [3] or [14]
17
6.2.1.3 ECU connected to the LIN sub-networks respecting the communication rules from document [10]......18
6.2.2 Frames format..............................................................................................................................................18
6.2.2.1 ECU connected to the CAN networks .....................................................................................................18
6.2.2.2 ECU connected to LIN sub- networks that implement the protocol described in the document [3] or [14]
19
6.2.2.3 ECU connected to LIN sub- networks that implement the protocol described in the document [10]......20
6.2.3 Mechanisms .................................................................................................................................................21
6.2.3.1 Content of the requests.............................................................................................................................21
6.2.3.2 Content of the replies...............................................................................................................................21
6.2.3.3 Interlacing ................................................................................................................................................21
6.3 Diagnostic sessions .............................................................................................................................22
6.3.1 Generalities..................................................................................................................................................22

Page 8 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
6.3.2 Influence of the vehicle life phases on the opening of the sessions and of the diagnostic communications 22
6.3.3 Timings........................................................................................................................................................23
6.4 Values of the communication parameters........................................................................................24
7 ”Diagnostics On CAN” specifications......................................................................................... 25
7.1 Composition of the CAN frames.......................................................................................................25
7.1.1 SINGLE_FRAME .......................................................................................................................................25
7.1.2 FIRST FRAME............................................................................................................................................25
7.1.3 CONSECUTIVE_FRAME..........................................................................................................................26
7.1.4 FLOW_CONTROL .....................................................................................................................................26
7.1.4.1 Overflow management for the body ECUs (CAN LS CAR, DIV & CONF, LIN)..................................27
7.1.4.2 Management of the overflow for the powertrain ECUs (CAN_IS) .........................................................28
7.2 Segmenting..........................................................................................................................................29
7.2.1 Sequence......................................................................................................................................................29
7.2.2 Identifiers.....................................................................................................................................................29
7.2.2.1 Emission of a segmented request .............................................................................................................29
7.2.2.2 Emission of a segmented response...........................................................................................................29
7.3 Parameters and timings.....................................................................................................................30
7.3.1 Segmenting parameters for diagnostic.........................................................................................................30
7.3.2 Segmenting parameters for the programming..............................................................................................30
7.4 Timing.................................................................................................................................................31
8 Specificities of the CAN frames sent for a LIN network that implements the protocol described
in document [10] ................................................................................................................................. 33
8.1 Constitution of the frames.................................................................................................................33
8.1.1 SINGLE_FRAME .......................................................................................................................................33
8.1.2 FIRST FRAME............................................................................................................................................34
8.1.3 CONSECUTIVE_FRAME..........................................................................................................................34
8.1.4 FLOW_CONTROL .....................................................................................................................................35
8.1.4.1 Management of the overflow for the ECUs (LIN master) .......................................................................36
8.2 Segmenting..........................................................................................................................................37
8.3 Parameters and timings.....................................................................................................................39
8.4 Timing.................................................................................................................................................39
9 Strategy of error recovery strategy............................................................................................... 40

Page 9 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
1 Purpose
This document describes our implementation of the network layer of the Diagnostics on Can standard (ISO 15765-2).
The purpose of this document is to specify the various exchange parameters and mechanisms which are implemented in
our ECUs. These mechanisms allow us to convey the information necessary to the download and diagnostic services.
These information transfers concern the diagnostic exchanges (between the tool and an ECU or between 2 ECU). These
exchanges can be made accross hardware or software gateways which allow a change of the network or of the network
type.
In addition to the ECUs on the CAN High Speed and CAN LOW Speed networks, this document takes into account the
diagnostic for the ECUs on the LIN network (not processed in the Diagnostics on Can standard ISO 15765-2).
This document does not cover the OBD communication protocol.

Page 10 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
2 Scope
This document is applicable to all PSA vehicles whose architecture is based on the protocol “Diagnostics on Can” (ISO
15765-2).
Therefore all the following ECUs are targeted:
 ECUs connected on the CAN network whose diagnostic, download, coding, calibration is executed via a CAN
Low Speed network (CAR, DIV, CONF & DIAG Body) or CAN High Speed network (IS)
 ECU connected on a LIN network, managing diagnostic services.
 After Sales, factory and engineering tools
The ECUs diagnosed only via a K line are therefore excluded from this specification.

Page 11 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
3 Reference documents
3.1 Internal PSA justification file
NA
3.2 PSA internal documents
Titre Réf.
[1] Spécification des règles de communication CAN 96.431.967.99
[2] Spécification des phases de vie réseau CAN 96.431.966.99
[3] Spécification des règles de communication LIN 96.459.907.99
[4] Spécification des phases de vie réseau LIN STE 96.459.904.99
[5] Keyword Protocol 2000 – 3F Implémentation des services de diagnostic 96.253.521.99
[6] STD Passerelle Diagnostic CAN_LS - LIN 96.587.833.99
[7] STD BSI Passerelle CANDiag LIN 96.574.560.99
[8] TS CAN - LIN diagnostic gateway 96 649 678 9A
[9] TS Implementation of UDS 96.646.970.99
[10] ST Réseau LIN - Règles de communication LIN 2.1 96 648 782 9B
[11] ST Règles de communication CAN LS 96 649 897 9B
[12] ST Phases de vie CAN LS 96 649 896 9B
[13] ST Réseau LIN - Phases de vie réseau LIN 2.1 96.648.783.9B
[14] ST d’Interfaces Réseaux Pour le domaine « Règles de communication du
réseau LIN (basée sur LIN 1.3)
96.622.355.9A
3.3 Standards and procedures
[N1] CAN Standard
-Low Speed (up to 125 KTS/s) ISO 11 519 Part 2
-High Speed (up to 1MTS/s) ISO 11 898
[N2] Diagnosis on CAN Standard ISO 15 765 Part 1, 2 and 4
ISO/DIS 15765-2 :2004 Network layer services October 2004
[N3] LIN specification package revision 1.2 and 1.3
[N4] LIN specification package revision 2.1

Page 12 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
4 Terminology
4.1 Glossary
4.2 Glossary
Gateway : Object that transfers the message from a network (or subnet) to another network (or subnet).
Inactive mode: Operating mode allowing, from the diagnostic tool, to request to the ECUs to stop their network
communication and the storage of their fault, but to carry on responding to the diagnostic requests.
4.3 Abbreviations and acronyms
b0 to b7: bit 0 to bit 7
B0 to Bx: Byte 0 to Byte no. 7
BSI: Boîtier de Servitude Intelligent (Vehicle main ECU)
CAN: Controller Area Network
CAR: CAN Body network
CONF: CAN Comfort network
DIV: CAN LS INFO DIV Entertainment network
EEPROM: Electrically Erasable Programmable Read Only Memory (non volatile memory type)
IS: CAN Inter-Systems network (CAN IS)
OBD: On Board Diagnostic
JDD: Fault Log
LIN: Local Interconnect Network
STD: Detailed Technical Specification
TS: Technical Specification
ECU: Electronic Control Unit
NAD: Node Address (Address of a LIN slave)

Page 13 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
5 Agreements
5.1 Presenting a requirement
The requirements are submitted in a table that contains the following information:
- Requirement number (see the applicable numbering below)
- The description of the requirement
Requirement no. Description Input requirement
AAA.BBB-
CCCC-NNN.Y
Requirement description
XX.YY.ZZ
5.2 Numbering a requirement
To facilitate the reading of the requirement, we agreed to number the requirements as follows:
AAA.BBB-CCCC-NNN.Y
where:
AAA.BBB : Reference of the document
CCC-NNN : Number of the requirement
Y : Requirement evolution index
Important: As this requirement numbering corresponds to traceability needs, a requirement number that was created may
not be destroyed, because of the risk of reusing it for a future requirement unrelated to the previous one. For a
requirement that has become irrelevant, the number is kept, and the corresponding text is "Deleted":
Example:
AAA.BBB-
CCCC-NNN.Y
Deleted

Page 14 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
6 Communication protocol
6.1 Principles of communication
The diagnostic frame exchanges are based on the communication protocol Diagnostics on Can (ISO15765-2).
6.1.1 Exchange Type
The data exchanges between equipments use the request/response principle, also called client/server (the client issues a
request, to which the server replies), or master - slave, in which there is only one request initiator.
More accurately, we use a Half-Duplex protocol, namely the sender can only send a new request to the same recipient
when the response to its previous request has been received or when a fixed delay has expired (time out notion to avoid
locking if the receiver does not reply).
However, the protocol authorizes the simultaneous emission of several requests toward different ECUs without waiting
for the response from the first request (the ECU must be on the same LIN sub-network).
The diagnostic tool issues a request toward an ECU. The ECU sends back a response to the tool.
In the simplest case, the sender is the diagnostic tool, and the receiver is the diagnosed ECU:
Diagnostic
tool
request
Diagnosed
UCE
response
sender
receiver
In the more complicated case when the diagnosed ECU is not directly linked to the tool, and is located behind one or
several gateways, each gateway receives the request (from the tool or the previous gateway) and transmits it on the
network to the following recipient (the next gateway or the diagnosed ECU):
Outil de
diagnostic Gateway#
1
UCE
diagnosed
Response
Gateway#
2
Response
Gateway#
N
Response
…
Response
Response
…
Récepteur
Émetteur
Request Request Request Request
Request
Sender
Gateway#1 : BSI or any other LIN master directly accessible by the tool
Receiver
Each gateway can execute a more or less complex processing:
1. simple switch on the proper network (CAN  CAN)
2. or changing the protocol or network type (Line K  CAN or CAN  LIN for example).
A gateway cannot initiate a diagnostic request without first receiving it from another gateway (gateways #1 to #N) or
directly from a tool (gateway #1).

Page 15 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Note:
Various designs of a CAN - LIN diagnostic gateway are possible (non exhaustive list):
 diagnostic gateway via frame insertion (the LIN request frame is issued on each reception of a CAN request)
 diagnostic gateway with reserved location (an “empty” LIN request frame is issued periodically; it is used or
non-empty with each reception of a CAN request frame)
The same operations by insertion or allocation are authorized for the response; in the “by allocation” case, a response
request is issued by the master, but no LIN slave replies.
The diagnostic tool is plugged on the single diagnostic socket available in the vehicle; this socket allows the simultaneous
communication on several CAN type communication channels.
Two CAN networks can be simultaneously accessible on the diagnostic socket (the CAN IS network (Inter-Systems
(Powertrain domain), the CAN DIAG network...). The BSI gateway does not operate in diffusion and is not symmetrical:
 Downward gateway: a request received on the CAN DIAG of the BSI is transferred on one of its sub-networks
(LIN, CAR, DIV, CONF or IS).
 Upward gateway: a response received on one of the sub-networks is transferred on the CAN DIAG toward the
tool.
In the case of the downward gateway, the recipient sub-network choice is made depending on the identifier of the frame
received.
For the upward gateway, all response frames received from one of the sub-networks is transferred on the CAN DIAG.
6.1.2 Addressing mode and Identifier
The addressing mode implemented is the physical mode, as described in the Diagnostics on Can standard (point to point
mode).
Each ECU has an identifier reserved for emission and at least one identifier reserved for reception.
6.1.2.1 ECU connected to the CAN Comfort, Body and Entertainment networks
463.229-0003-
01A.1
Each ECU connected to the CAN INFO DIV, CAN CONF or CAN CAR
networks has a CAN identifier used to receive requests.
GEN-VHL-DC-
DIAG.263 (0)
463.229-0003-
01B.1
Each ECU connected to the CAN INFO DIV, CAN CONF or CAN CAR
networks has a CAN identifier used to issue responses.
GEN-VHL-DC-
DIAG.263 (0)
463.229-0003-
01C
Requirement deleted
6.1.2.2 ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid network
Requirement
no.
Description Input requirement
463.229-0003-
02A.1
Each ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid
network has a CAN identifier used to receive requests.
GEN-VHL-DC-
DIAG.284 (0)
463.229-0003-
02B.1
Each ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid
network has a CAN identifier used to send requests.
GEN-VHL-DC-
DIAG.284 (0)
6.1.2.3 ECU connected to the LIN networks that implement the protocol described in the document [3] or [14]
In order to ensure the routing of the diagnostic requests to the LIN ECU, two CAN identifiers are assigned to each LIN
ECU.

Page 16 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Each master of the LIN sub-network has the responsibility to execute the gateway, from and to the CAN network, for the
requests and diagnostic replies of its LIN slaves.
On the LIN network, the diagnostic request frames are being broadcasted with the same identifier (0x3C); Each slave
must analyze the first data byte of this request frame to identify if the LIN slave targeted by the request is itself.
See [3] or [14]
Requirement
no.
463.229-0003-
03A
Each ECU connected to a LIN network or sub-network has a CAN identifier
used by the master to receive requests on the CAN network.
GEN-VHL-DC-
DIAG.465 (1)
GEN-VHL-DC-
DIAG.439 (0)
GEN-VHL-DC-
DIAG.264 (1)
463.229-0003-
03B
Each ECU connected to a LIN network or sub-network has a CAN identifier
used by the master to send responses on the CAN network..
GEN-VHL-DC-
DIAG.439 (0)
GEN-VHL-DC-
DIAG.264 (1)
6.1.2.4 ECU connected to the LIN networks that implement the protocol described in the document [10]
For this LIN ECU type, the CAN identifiers used are associated to the network
Each master of the LIN sub-network has the responsibility to execute the gateway, from and to the CAN network, for the
diagnostic requests and replies of its LIN slaves.
On the LIN network, the diagnostic request frames are being broadcasted with the same identifier (0x3C); Each slave
must analyze the first data byte of this request frame to identify if the LIN slave targeted by the request is itself.
Requirement
no.
Description Input
requirement
463.229-0003-
03C
Each LIN network or sub-network has a CAN identifier used by the master to
receive the requests on the CAN network and to send them on the corresponding
network.
GEN-VHL-DC-
DIAG.465 (1)
GEN-VHL-DC-
DIAG.439 (0)
463.229-0003-
03D
Each LIN network or sub-network has a CAN identifier used by the master to
send the corresponding requests on the CAN network.
GEN-VHL-DC-
DIAG.439 (0)
6.1.2.5 ECU connected to the CAN-DIAG network
463.229-0003-
04A.1
Each ECU connected to the CAN DIAG network has at least a CAN
identifier to receive requests.
GEN-VHL-DC-
DIAG.284 (0)
463.229-0003-04B Each ECU connected to the CAN DIAG network has a CAN identifier to
issue responses.
GEN-VHL-DC-
DIAG.284 (0)
6.2 Request/response mode
6.2.1 Requests and replies size and frame size
6.2.1.1 ECU not being a LIN ECU and that respects the communication rules of the document [3] or [14]
The Diagnostics on Can protocol allows the transmission on a CAN network of a message with the maximum size of
4095 bytes (informative data, excluding the bytes of the Diagnostics On Can protocol itself). The ECU connected on a
network that respects the communication rules of the document [10] also support this maximum size for a message.
When the diagnostic tools refers to a CAN or a LIN ECU, the requests and responses are segmented, if needed, in
maximum 8 byte frames according to the process described in chapter 7.2 .

Page 17 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Requirement
no.
463.229-
0005-01C.1
For the ECUs that implement the KWP2000 protocol described in
document [5] The maximum size of a diagnostic request or response on a
CAN network is limited to 255 informative data bytes (excluding NPCI
bytes of the segmentation protocol).
GEN-VHL-DC-DIAG.261 (1)
463.229-
0005-01D
For the ECUs that implement the UDS protocol described in document
Error! Reference source not found. The maximum size of a diagnostic
request or response on a CAN network is limited to 4095 informative data
bytes (excluding NPCI bytes of the segmentation protocol).
Requirement
no.
463.229-
0005-01B.1
The requests and responses too long to fit in one frame are segmented in
frames having at most 8 bytes, according to the process described in
chapter 7.2.
463.229-
0005-01A0.1
On the CAN networks, if a Single_Frame, a FlowControl frame, or the
last Consecutive_Frame (last segment in the case of a segmented
message) does not have enough data bytes to be filled up to 8 bytes, it
must not be filled with stuffing bytes. Therefore, the can frames are
optimized: the DLC parameter present in the CAN frames header reflects
the exact number of informative data bytes sent. See document [1]
Spécification des règles de communication CAN.
463.229-
0005-01E.1
The requests and the responses for a CAN communication with a size
lower than or equal to 7 informative data bytes use the Single_Frame
frame format.
463.229-
0005-01F
The requests and the responses for a CAN communication intended for the
LIN components or in the case of a LIN communication with the size
lower than or equal to 6 informative data bytes use the Single_Frame
frame format.
6.2.1.2 ECU connected on the LIN sub-networks respecting the communication rules from document [3] or [14]
Segmenting is not managed for this type of LIN sub-networks.
Requirement
no.
463.229-
0005-02B
All diagnostic requests or replies targeted to or coming from a LIN ECU
must use a SingleFrame frame of the Diagnostics On Can protocol (ISO
15765-2) on the CAN networks, between the diagnostic tool and the
master of the LIN sub-network to which the LIN ECU diagnosed is
connected.
A diagnostic frame will therefore have at most 8 bytes of data, including the protocol byte; There are at most 7
informative data bytes available to implement a KWP2000 request.
The protocol byte regroups the station number of the diagnosed LIN part, as well as the informative data number among
the 7 with data.
The KWP2000-3F services available are therefore limited, and an adapted use of the KWP2000-3F application diagnostic
services allows the execution of the diagnostic replies and requests. See document [5] Keyword Protocol 2000 – 3F
Implémentation des services de diagnostic.

Page 18 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
We have decided to use the 0x3C identifiers for the diagnostic request frames and 0x3D for the diagnostic response
frames on the LIN networks. These identifiers correspond to 8 bytes long frames; This means all 8 bytes of the
informative data of the CAN frame must be filled, in order to fill in all bytes of the LIN frame with “useless” bytes, called
“stuffing” or “padding”.
The 1st
data byte of the LIN frame includes the number of data bytes actually used (3 bits). This number corresponds to
the SF_DL (Data Length) field of the NPCI from the Diagnostics on CAN protocol.
Reciprocally, the master receives the number of informative data bytes in the LIN response frame (lower than or equal to
7), and creates a CAN response frame that includes this informative data and the NPCI byte of the SingleFrame.
Requirement
no.
463.229-
0005-02A
The master of the LIN sub-network (which executes the CAN  LIN
diagnostic gateway function) completes data of the diagnostic CAN
frames addressed to a LIN ECU (SingleFrame frames with the identifier
0x3C) with stuffing bytes. These stuffing bytes must be set to 0xFF, in
order to obtain 8 bytes long LIN frames.
(Note: only bytes 2 to 8 of the diagnostic request frame on the LIN
network can be filled with this value)
See document [3] or [14]
463.229-
0005-02C
The master of the LIN sub-network (which executes the CAN  LIN
gateway function) fills in, in the first byte of the LIN frame, the
informative data size of the frame. This number corresponds to the SF_DL
parameter of the request SingleFrame frame on the CAN network.
463.229-
0005-02D
Reciprocally, the master of the LIN sub-network (which executes the LIN
 CAN gateway function) sends, on the CAN network, only the
informative data from the 7 bytes received in the LIN response frame. The
informative data bytes size is extracted from the first byte of the LIN
frame and is used for the SF_DL parameter of the response SingleFrame
frame on the CAN network.
463.229-
0005-02E
All LIN slaves must fill in their diagnostic replies (Single Frame identified
as 0x3D) with stuffing bytes. These bytes must be set to 0xFF, in order to
obtain 8 bytes long LIN frames.
463.229-
0005-02F
All slaves that receive a diagnostic request frame (identified as 0x3C)
must only consider the "informative data" bytes of this frame and must
ignore the "padding" byte values.
463.229-
0005-02G
The master of the LIN sub-network that receives a diagnostic request
frame (identified as 0x3D) must only consider the "informative data"
bytes of this frame and must ignore the "padding" byte values.
463.229-
0005-02H
For each diagnostic request issued by the tool, toward one of its LIN
slaves, the master of a LIN sub-network issues the request (originating
from the tool) only once on the LIN network of the recipient slave.
N/A
6.2.1.3 ECU connected to the LIN sub-networks respecting the communication rules from document [10]
The requirement concerning the size of the frames and of the messages that travel on this LIN bus type is described in the
document [10].
The requirements specific to the diagnostic communications are described in chapter 6.2.2.3
6.2.2 Frames format
6.2.2.1 ECU connected to the CAN networks
The identifiers of the CAN frames chosen within the standard 11 bits addressing used by PSA integrate the notion of
destination, of source and functional or physical addressing mode.

Page 19 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
463.229-0006-01A.2 Deleted N/A
6.2.2.2 ECU connected to LIN sub- networks that implement the protocol described in the document [3] or [14]
Requirement
no.
463.229-0006-
01B
The headers of the LIN request and response frames have a specific
identifier, 0x3C for the request, and 0x3D for the response.
463.229-0006-
01C
The low-order 4 bits of the first byte of the diagnostic request LIN frame
contains the LIN station number of the ECU that receives this request.
The 1.0 bit contains the low-order bit of the station number (20
).
463.229-0006-
01D
Reciprocally, the low-order 4 bits of the first byte of the LIN response
frame contain the number of the LIN station that issues the response.
The 1.0 bit contains the low-order bit of the station number (20
).
The diagnostic request frames are broadcasted on the LIN network by the master, with the identifier 0x3C.
A diagnostic request issued by tool is only sent once by the master to the slave targeted by the request; These frames are
not repeated by the master that executes the diagnostic gateway.
The master of the LIN network gets the response to the previous diagnostic request on a 0x3D identifier frame.
Requirement
no.
463.229-
0006-01E
A diagnostic tool communicates with a LIN slave using the diagnostic
services format defined by the KWP2000 (request/response).
463.229-
0006-01F.1
In order not to generate segmentation on the LIN, the diagnostic services in
the KWP2000 format (request/response) intended for the LIN slaves are
“single frames” limited to 7 data bytes (byte 1 of the CAN is reserved to
the NPCI byte that manages the segmentation).
463.229-
0006-01G
All LIN slaves receive diagnostic request frames and analyze the first byte
which contains the number of the LIN slave, recipient of the request frame;
only the ECU whose station number corresponds to the 4 low-order bits of
the first byte executes the request.
463.229-
0006-01H
Only the LIN slave that is the recipient of the last 0x3C request is
authorized to response in the 0x3D response frame.
463.229-
0006-01I
All the slave equipment on the LIN network whose response is not ready
after receiving a request must systematically respond by using the most
adequate response according to KWP2000 (to be defined in the STE
diagnostic messaging).
463.229-
0006-01J
The high order bit of the first byte (bit 1.7) of the LIN diagnostic request
frames is always set to 1 (corresponds to the free of use frames in the LIN
standard).
463.229-
0006-01K
The high order bit of the first byte (bit 1.7) of the diagnostic response
frames on the LIN is always set to 1 (corresponds to the free of use frames
in the LIN standard).
463.229-
0006-01L
The encoding of the informative data size in the LIN diagnostic request
and response frames is set on the bits 1.6 to 1.4 of the first byte of these
frames.
The values that this field can take are 1 to 7.
Bit 1.4 contains the low-order of the size (20
).
To summarize, here is the content of byte 1 of the diagnostic request and response frames on the LIN network:

Page 20 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Content of byte 1
DIAG_REQUETE (0x3C) and
DIAG_REPONSE (0x3D)
1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0
Reserved
(=1)
Frame informative data
Possible values: 1 to 7
N_ECU_LIN_diag
Station number of the LIN slave
(4 bits)
Requirement
no.
Description
Input
requirement
463.229-0006-
01M.1
If the master must send a LIN diagnostic request (0x3C) when there is no request issued
by the tool, the request frame sent by the diagnostic tool contains 0 informative byte and
the 1st
byte is the following:1
- byte 1: 0x8F
1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0
Reserved
(=1)
0 0 0 1 1 1 1
Size = 0 Diagnosed station number = 0xF
GEN-VHL-DC-
DIAG.261 (1)
Requirement
no.
Description
Input
requirement
463.229-0006-
01N
A LIN slave must ignore all diagnostic request frames received with an informative data
size equal to 0; the slave must not consider itself to be the recipient of this request.
GEN-VHL-DC-
DIAG.261 (1)
6.2.2.3 ECU connected to LIN sub- networks that implement the protocol described in the document [10]
Requireme
nt no.
Description
Input
requirement
463.229-
0006-02A
The headers of the LIN request and response frames have a specific identifier, 0x3C for the
request, and 0x3D for the response.
GEN-VHL-
DC-DIAG.264
(1)
Note: The first byte of the diagnostic request LIN frame contains the LIN station number of the ECU that receives this
request, the NAD.
Reciprocally, the first byte of the LIN response contains the number of the sender station.
The diagnostic request frames are broadcasted by the master on the LIN network, with the 0x3C identifier.
A diagnostic request issued by the tool is only sent once by the master to the slave targeted by the request; These frames
are not repeated by the master that executes the diagnostic gateway.
The master of the LIN network gets the response to the previous diagnostic request on a 0x3D identifier frame.
Requirement
no.
Description Input
requirement
463.229-0006-
02B.1
A diagnostic tool communicates with a LIN slave using the diagnostic services
defined in the UDS protocol (request/response).
GEN-VHL-DC-
DIAG.264 (1)
463.229-0006-
02C
All LIN slaves receive diagnostic request frames and analyze the first byte which
contains the number of the LIN slave, recipient of the request frame. Only the ECU
whose station number corresponds to the first byte executes the request.
This byte is the NAD.
GEN-VHL-DC-
DIAG.264 (1)
463.229-0006-
02D
Only the LIN slave that is the recipient of the last request with the identifier 0x3C is
authorized to reply in the response frame with the identifier 0x3D.
GEN-VHL-DC-
DIAG.264 (1)
1
It is the case when the master design is such that it systematically issues a 0x3C frame without having a diagnostic
request.
This means the diagnosed station number 0xF is reserved if the master uses such a schedule table.

Page 21 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
463.229-0006-
02E
Every slave ECU on the LIN network whose response is not ready after receiving a
request must not fill in the corresponding slot.1
GEN-VHL-DC-
DIAG.264 (1)
Requirement
no.
463.229-0006-
02I
The diagnostic frames with the 0x3C or 0x3D header that travel on the LIN
always contain 8 bytes. 2
GEN-VHL-DC-
DIAG.264 (1)
1
This operation is the opposite of the one expected for the slaves that comply with the protocol described in document [3]
or [14]
2
A message that does not contain enough data bytes to fill an 8 bytes frame is completed. These added bytes are called
padding bytes in contrast with the informative data bytes. These bytes are therefore not handled in the PCI
6.2.3 Mechanisms
The data bytes of the CAN frames respect the services defined by the documents [5] or Error! Reference source not
found..
A request is issued by the tool with the request identifier.
After processing, the response is sent by the ECU using its response identifier.
For example, a service will be divided in the following manner:
service Parameter 1 … Parameter n
6.2.3.1 Content of the requests
The request contains a service code followed by parameters. This content allows the ECU to interpret what the tool it is
requirering.
Example of data contained in a diagnostic request for KWP2000:
service parameter 1
21 80 system identification request
RDBLID LID (2 bytes)
6.2.3.2 Content of the replies
After interpretation of the request, the ECU sends a response which can be either positive or negative.
In the event of a positive response, it contains the positive response code, followed by the informative data for the tool.
In the event of a negative response, it contains the negative response code, followed by the code indicating the error type.
Example of data contained in a diagnostic response for KWP2000:
service parameter 1 … parameter
N
61 80 … xx reply to a system identification request
RDBLID LID … App. type (24 bytes)

Page 22 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
6.2.3.3 Interlacing
The tool has the possibility to send a new request without waiting for the response to the previous request if these
requests have different ECU destinations (simultaneous requests on multiple sessions). On the contrary the interlacing of
the requests towards the same ECU is not authorized.
Requirement
no.
Description Input
requirement
463.229-0007-
03A
The interlacing of several requests having the same ECU as destination is
prohibited.
N/A
463.229-0007-
03B
The interlacing of requests toward several ECUs connected to the same LIN
network is prohibited.
N/A
463.229-0007-
03C
The interlacing of request toward several ECUs, each connected to a different LIN
network, must be handled.
N/A
463.229-0007-
03D
The interlacing of requests toward several CAN ECUs must be handled, whether
they are on the same CAN network or not.
N/A
463.229-0007-
03E
The interlacing of requests toward several ECUs connected to different networks
must be handled.
N/A
463.229-0007-
03F
Deleted N/A
6.3 Diagnostic sessions
6.3.1 Generalities
For the KWP 2000 ECUs, the sessions mechanisms are described in document [5].
For the UDS ECUs, these mechanisms are described in document Error! Reference source not found..
The communication sessions for the diagnostic are implemented differently on the ECU connected to the CAN Inter-
Systems networks and on the ECU connected to the CAN Comfort, Body and Entertainment networks.
For each communication session, the diagnostic tool must comply with the requirements corresponding to the addressed
ECUs, whether they are on the Inter-Systems, Comfort, Body or Entertainment network or on the LIN sub-networks.
6.3.2 Influence of the vehicle life phases on the opening of the sessions and of the diagnostic
communications
According to the ECU life phase, it is possible or impossible to open a diagnostic session and to communicate.
This table gives the possible cases:
Requirement
no.
Description Input
requirement
Network life phase
Session type
Standby Normal Standby Alarm Mode
inactive
Defect
mode
463.229-0012-
01A.1
Deleted N/A
463.229-0012-
01B.1
Deleted N/A
463.229-0012-
01C.1
Deleted N/A
463.229-0012-
01F
All sessions No Yes No No Yes Yes GEN-VHL-
DC-
DIAG.278 (1)
463.229-0012-
01D
If it is impossible to open a diagnostic session in one of the situations above, the ECU
does not response to the tool request.
GEN-VHL-
DC-
DIAG.278 (1)

Page 23 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
The timings that are specific to network life phases are defined in the PSA document "Spécification des phases de vie
réseau ".
Requirement no. Description Input
requirement
463.229-0012-
01E.1
Deleted N/A
6.3.3 Timings
The synchronization of the exchanges is ensured by a certain number of maximum and minimum delays that must not be
exceeded, defined at the level of the application layer and at the level of the network layer.
At the application level:
- Diagnostic session delay (P3max delay)
- Delay between the end of the request and the start of the response (delay P2), on the tool side and ECU side
At the level of the network layer (see document [N2] part 2):
Various delays are defined in the standard. They are resumed in this document with the authorized value ranges (see
chapter 7.4)
P2 = Tdiag for the ECU queried by the tool (via the gateway)
P2 = Tret for the tool
sender receiver
request
response
T-Ret T-Diag
The T_Ret delay corresponds to a time-out on the tool side. Beyond this delay, the tool considers that it will not receive
the answer from the ECU. The tool is authorized to repeat its request.
The T_Diag delay corresponds to a time delay during which the ECU must send its response. Beyond this T_Diag delay,
the ECU must no longer response to avoid interlacing a request with a previous response.

Page 24 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
6.4 Values of the communication parameters
The following values are valid for all ECUs and all Diagnostic tools, whether they are connected to the CAN HS (Inter-
Systems or Diagnostic), CAN LS (Body or Comfort) or LIN (LIN BSI 1 and 2, or any other LIN ECU) networks.
The application timings and their management are defined in the document [5] Keyword Protocol 2000 – 3F
Implémentation des services de diagnostic.
requireme
nt
Parameter Description Value
463.229-0030-01A.1 T_Ret Return time to the tool of a request
intended for an CAN or a LIN ECU
using the protocol in document [3]
or [14].
In case the receiver does not
response, the sender cannot issue a
new request towards the same ECU
before the T_Ret return time.
250 ms GEN-VHL-
DC-
DIAG.430
(0)
463.229-0030-01F T_Ret_LIN Return time to the tool of a request
intended for an LIN ECU using the
protocol in document [10].
In the absence of a receiver
response, the sender cannot issue a
new request towards the same ECU
before the T_Ret_LIN return time.
1000 ms GEN-VHL-
DC-
DIAG.430
(0)
463.229-0030-01B T_Diag
CAN
Maximum delay that separates the
receiving of a request and the start of
the emission of its response for
ECUs on the CAN network.
200 ms GEN-VHL-
DC-
DIAG.430
(0)
463.229-0030-01E.1 T_Diag
LIN or
P2_LIN
Maximum delay that separates the
receiving of a request and the start of
the emission of its response for the
ECUs on the LIN network.
See document [6] or
document [8] according to
the protocol used
GEN-VHL-
DC-
DIAG.430
(0)
463.229-0030-01C Deleted N/A
463.229-0030-01D Deleted N/A

Page 25 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
7 ”Diagnostics On CAN” specifications
The Diagnostics on Can protocol is specified by the standard ISO15765-2 and ISO15765-3. The purpose of this chapter
is to make a summary and to specify the value of the parameters which do not have their value set in the standard.
The Diagnostics On Can protocol allows the transmission of data blocks with a size that can be equal up to 4095 bytes.
These blocks are issued by using a segmenting mechanism whose sequencing and timings are defined.
7.1 Composition of the CAN frames
Each request or response therefore includes encoded information that allows the transmission of 1 to 4095 informative
data bytes.
This encoded information is called NPCI in Diagnostics on CAN standard (Network Protocol Control Information). The
NPCI is located in the first frame bytes. The other frame data are called “informative data”.
Description of the frame data bytes:
Byte 1 byte n byte 8
NPCI (Network Protocol Control
Information)
Informative data
This NPCI characterizes four message types:
 The simple messages: SINGLE_FRAME
 The first message: FIRST_FRAME
 The consecutive messages: CONSECUTIVE_FRAME
 The Flow Control messages: FLOW_CONTROL
7.1.1 SINGLE_FRAME
The SINGLE_FRAME message is used for issuing a block of maximum 7 bytes of informative data.
Description:
4 bits 4 bits 7 Bytes
SF DL Informative Data
NPCI
SF is the code for SINGLE_FRAME; its value is 0.
DL indicates the informative data size contained in the frame
7.1.2 FIRST FRAME
The FIRST_FRAME message is used for issuing a block of more than 7 bytes of informative data. This message includes
the length of the informative data packet, coded in the NPCI. The first informative data bytes are also included in this
message.
Description:

Page 26 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
FF DL Informative Data
NPCI
FF is the code for FIRST_FRAME; its value is 1.
DL indicates the total informative data size which will be sent. This size includes the 6 bytes contained in this frame and
also all the bytes which will be issued in the CONSECUTIVE_FRAME.
It is encoded on 12 bits.
7.1.3 CONSECUTIVE_FRAME
The CONSECUTIVE_FRAME message is used during the sending of a block of more than 7 bytes of informative data.
This message contains a segment of the data block to issue.
Description:
CF SN Informative Data
NPCI
CF is the code for CONSECUTIVE_FRAME; its value is 2.
SN indicates the number of the segment sent. The first segment sent carries the number 1. This number is increased with
each transmission until reaching the value 15. The following segment will carry the number 0. The incrementation
sequencing is repeated.
7.1.4 FLOW_CONTROL
The FLOW_CONTROL message is used to manage the exchange flow during the sending of the segments. This message
is issued by the data receiver.
Description:
FC FS STmin
NPCI
Block Size
FC is the code for FLOW_CONTROL; its value is 3.
FS is the status (Flow_status); the status can take one of the following values:
 OVERFLOW (FS = 2) to indicate that the message length (FF_DL) sent by the sender is over the size of the receiver
buffer. The sender must then stop the emission.The request is therefore not manageable by the receiver. This
“overflow” is therefore a request error or a design error because the receiver is not able to process the request.
 WAIT (FS = 1) to temporarily stop the segments transmission: The sender must wait for a new
FLOW_CONTROL message. As long as the Flow_status of the FLOW_CONTROL message equals WAIT, the
sender continues to wait for a new FLOW_CONTROL message; The transmission resumes when the sender receives

Page 27 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
a FLOW_CONTROL with Flow_status equal to CLEAR_TO_SEND, and the sender returns a
CONSECUTIVE_FRAME message block.
 CLEAR_TO_SEND (FS = 0) to restart or confirm the transmission of the following segments.
The other values [0x3…0xF] are reserved (RESERVED) and must not be used (generate an error case).
Block Size (BS) indicates the number of CONSECUTIVE_FRAME after which the sender must wait for the
FLOW_CONTROL message from the receiver before continuing to send its CONSECUTIVE_FRAME; This
FLOW_CONTROL message indicates to the sender whether it can continue to send or if it must wait. This flow control
mechanism is repeated until all CONSECUTIVE_FRAME have been sent.
If BS equals 0, only the first FLOW_CONTROL message of the response to FIRST_FRAME is sent by the receiver; no
other FLOW_CONTROL message must be sent by the receiver as a response to CONSECUTIVE_FRAME; the sender
therefore sends all its CONSECUTIVE_FRAME in a single burst (complying with STmin); The receiver must therefore be
designed to accept the maximum number of bytes that must be sent to it (depending on the diagnostic, remote encoding
and download of each ECU).
STmin specifies the minimum delay that must separate the sending of two consecutive CONSECUTIVE_FRAME
messages.
The use of these parameters is described in the following requirements.
7.1.4.1 Overflow management for the body ECUs (CAN LS CAR, DIV & CONF, LIN)
Management of the ECU resource overrun:
In case the ECU is not able to receive, in its receive buffer, the entire message sent by the tool (FF_DL size indicated by
the tool in the FIRST_FRAME frame); the ECU must then response with a FLOW_CONTROL frame containing a
Flow_status equal to OVERFLOW ; the tool must then stop sending its message.
Requirement
no.
Description Input
requirement
463.229-0105-
01A
An ECU must handle the standardized operations OVERFLOW, WAIT and
CLEAR_TO_SEND, associated with the sending of the frame FLOW_CONTROL, with
a Flow_status at OVERFLOW (0010b), WAIT (0001b) and CLEAR_TO_SEND
(0000b). Only these three values must be managed.
N/A
463.229-0105-
01B
A tool must stop issuing its message if it receives a FLOW_CONTROL frame
containing a Flow_status equal to OVERFLOW (0010b) from the receiver ECU.
N/A
Management of the tool resource overrun:
This refers to the case when the tool is not able to receive the entire message in its receiver buffer (FF_DL size indicated
for the ECU in the FIRST_FRAME frame).
A tool must always be able to accept the maximum size authorized by the protocol (4095 bytes).
Requirement
no.
Description Input
requirement
463.229-0105-
01C
A diagnostic tool must be able to receive messages with the maximum possible size of
4095 bytes, without generating a FLOW_CONTROL frame with a Flow_status equal
to OVERFLOW; consequently, a tool will never generate a FLOW_CONTROL with a
Flow_status equal to OVERFLOW.
N/A
463.229-0105-
01D.1
Deleted N/A
Errors management:

Page 28 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Requirement
no.
Description Input
requirement
463.229-0105-
01E
If the tool receives a FLOW_CONTROL frame containing a Flow_control whose
value is higher than or equal to 3 (and lower than or equal to 0xF) (namely different
from OVERFLOW, WAIT and CLEAR_TO_SEND), it must:
 stop the emission of tool message,
 Notify the upper layer of the error.
N/A
463.229-0105-
01F
If an ECU receives a FLOW_CONTROL frame containing a Flow_control whose
 stop the emission of ECU message,
N/A
7.1.4.2 Management of the overflow for the powertrain ECUs (CAN_IS)
All ECUs connected on the CAN_IS are designed so as to be able to manage the maximum possible size of a KWP2000
protocol request (255 byes).
Therefore the CAN_IS ECUs are not required to manage a FLOW_CONTROL frame with a Flow_status equal to
OVERFLOW.
Therefore there is no specific requirement concerning the management of the ECU resource overrun.
This refers to the case where the tool is not capable of receiving the entire message in its receiver buffer (FF_DL size
indicated for the ECU in the FIRST_FRAME frame).
We consider that a tool must always be able to accept the maximum size authorized by the protocol (4095 bytes).
Therefore the IS ECUs must not necessarily be able to manage this overrun.
Therefore there is no specific requirement concerning the management by an IS ECU of a tool resource overrun.

Page 29 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
7.2 Segmenting
7.2.1 Sequence
In the case when a request or a response is segmented, the sequencing is as follow:
Sender Receiver
Sending of the data
packet size.
Sending of : STmin
BS=0
Clear_To_Send.
STmin
Sending of the first
segment (SN=1) of
the first block.
Sending of the
second segment
(SN=2) of the first
block.
Sending of the thrid
segment (SN=3) of
the first block.
STmin
Ack_transmission
Ack_transmission
Ack_transmission
Ack_transmission
Ack_transmission
Bus
First Frame
Flow Control Frame
Consecutive Frame
Consecutive Frame
Consecutive Frame
Block
Size
7.2.2 Identifiers
The identifiers used for the segmented exchanges are the same as those used for the requests and replies.
7.2.2.1 Emission of a segmented request
Requirement
no.
Description Input
requirement
463.229-0108-
01A.1
The tool sends its FIRST_FRAME to a CAN or LIN ECU using the request
identifier of this ECU.
GEN-VHL-DC-
DIAG.262 (0)
463.229-0108-
01B.1
The ECU sends its FLOW_CONTROL frame to the tool using its response
identifier. If the recipient ECU of the segmented frame is a LIN slave, its master
sends the FLOW_CONTROL frame according to document [8]
GEN-VHL-DC-
DIAG.262 (0)
463.229-0108-
01C.1
The tool then sends all its CONSECUTIVE_FRAME to the CAN or LIN ECU,
using the request identifier.
GEN-VHL-DC-
DIAG.262 (0)
7.2.2.2 Emission of a segmented response
Requirement
no.
Description Input
requirement
463.229-0108-
01D.1
The ECU sends its FIRST_FRAME to the tool using its response identifier or, if
the ECU is a LIN slave, the response identifier of the network to which it
belongs.
GEN-VHL-DC-
DIAG.262 (0)

Page 30 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
463.229-0108-
01E.2
The tool sends its FLOW_CONTROL frame to the CAN ECU using the request
identifier of this ECU.
If the ECU sending the segmented frame is a LIN slave, the tool sends the
FLOW_CONTROL frame using the request identifier of the network to which it
belongs.
GEN-VHL-DC-
DIAG.262 (0)
463.229-0108-
01F.1
The ECU then issues all its CONSECUTIVE_FRAME frames to the tool using
its response identifier.
GEN-VHL-DC-
DIAG.262 (0)
7.3 Parameters and timings
7.3.1 Segmenting parameters for diagnostic
Receiving of the segmented message:
The ECU and the tools are responsible for sending their FLOW_CONTROL messages with the parameters set in the
following manner:
requirement
Session type Block Size Stmin (minimal
surface tension)
463.229-0110-01A Requirement deleted
463.229-0110-
01B.1
All sessions except programming session
FOR A ECU.
0 10 ms N/A
463.229-0110-01E Every session FOR A DIAGNOSTIC
TOOL.
0 0 ms N/A
463.229-0110-01C Requirement deleted
Sending of a segmented message:
requirement
463.229-0110-01D An ECU and a tool must handle, for the sending of the CONSECUTIVE_FRAME,
the STmin value received in the FLOW_CONTROL frame as a response to its
FIRST_FRAME.
GEN-VHL-
DC-
DIAG.262 (0)
Note: The possible routers are likely to modify the STmin value of the FLOW_CONTROL frames that pass through these
routers.
7.3.2 Segmenting parameters for the programming
To receive the programmed data, the ECU connected to the CAN Inter-Systems network must comply with the
requirements expressed in the specification 96.435.787.99.
Requirement
no.
Type of data transfer Block
Size
STmin
463.229-0111-
01A
Receiving download data for body ECUs (CAN Inter-
Systems ECUs are not concerned)
0 0 ms GEN-VHL-DC-
DIAG.19 (0)
GEN-VHL-DC-
DIAG.20 (1)
GEN-VHL-DC-
DIAG.360 (0)
GEN-VHL-DC-
DIAG.21 (0)

Page 31 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
7.4 Timing
Sender Receiver
Sending of FF_DL
Sending of: FS, BS and
STmin
STmin
Sending of SN
Ack_transmission
Ack_transmission
Ack_transmission
Ack_transmission
Bus
Sending of SN
N_As
N_Bs
N_Br
N_Ar
N_Cs
N_Cr
First Frame
Flow Control Frame
Consecutive Frame
STmin
Ack_transmission
Sending of SN
N_Cs
N_Cr
Sending of: FS
Ack_transmission
N_Bs
N_Br
Flow Control Frame
N_As
N_As
N_As
N_Ar
N_Cr
Consecutive Frame
Consecutive Frame
N_Cs
s = sender r = receiver
All the ECU and tools connected to the Inter-Systems, Diagnostic, Comfort and Body networks must comply with the
minimum and maximum timings for the parameters defined in the Diagnostics on Can standard, as well as with the
performance criteria specified.
Requirement
no.
Timing Description Minimum
period
Maximum
period
Performance Input requirement
463.229-
0112-01A.1 N_As
Bus transfert delay of
a CAN frame issued
by the sender
For the ECUs connected to the CAN
Inter-systems and CAN Diag networks,
these two parameters are not relevant.
For the ECUs connected to the CAN
CONF, CAR and INFO DIV networks,
see document [1]
463.229-
0112-01B.1 N_Ar
Bus transfert delay of
a CAN frame issued
by the receiver
463.229-
0112-01C.1
N_Bs
Delay until receiving
the next
Flow_Control
message
Not
applicable
250 ms for
Body
networks
(CAN LS
CAR, DIV
and CONF)

Page 32 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
Requirement
no.
Timing Description Minimum
period
Maximum
period
Performance Input requirement
1000 ms for
Powertrain
networks
(CAN_IS)
463.229-
0112-01D.1
N_Br
Delay until sending
the next
Flow_Control
message
0 ms
200 ms for
Powertrain
networks
(CAN_IS) (N_Br +
N_Ar)
< 0.9
N_Bs_max
30 ms for
Body
networks
(CAN LS,
CAN DIAG)
463.229-
0112-01E.1
N_Cr
Delay until reception
of the first segment of
the current block
Not
applicable
250 ms for
Body
networks
(CAN LS
CAR, DIV
and CONF)
1000 ms for
the
powertrain
(CAN_IS)
463.229-
0112-01F.2
N_Cs
Delay until
transmission of the
first segment of the
current block
EXCEPTING
PORGRAMMING
Stmin
200 ms for
Powertrain
networks
(CAN_IS) (N_Cs +
N_As)
< 0.9
N_Cr_max
STmin + 10
ms for Body
networks
(CAN LS,
CAN DIAG)
463.229-
0112-01G.1
N_Cs
Delay until
transmission of the
first segment of the
current block
FOR
PROGRAMMING
STmin
(CAN network inter
frame delay)
STmin
The programming tools attempts to use the entire network transmission capacities to obtain the fastest possible
programming while respecting all the ECU constraints
463.229-0112-01H.2 Deleted N/A
Note: For ECUs connected to the Comfort and Body networks, PSA recommends the following implementation:
N_Cs = STmin + 5 ms.

Page 33 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
8 Specificities of the CAN frames sent for a LIN network that implements the protocol described in
document [10]
8.1 Constitution of the frames
The content of the frames traveling on a CAN network is not modified by its transfer through a gateway.
The content of the frames traveling on a LIN network is not modified by its transfer through a gateway.
Each request or response therefore includes encoded information that allows the transmission of 1 to 4095 informative
data bytes.
This encoded information is called PCI + LEN in the LIN specification, equivalent to NPCI CAN. The first frame byte is
NAD. The data called “informative data” are other than the bytes contained in the (SID + N_DATA) frame.
Format of the CAN and LIN frames sent to or received from a LIN.
LIN
format
on
the
CAN
network
N_PDU type Identifier Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
SingleFrame (SF) N_AI/E – N_AI/R NAD PCI SID N_Data N_Data N_Data N_Data N_Data
FirstFrame( FF) N_AI/E – N_AI/R NAD PCI LEN SID N_Data N_Data N_Data N_Data
ConsecutiveFrame (CF) N_AI/E – N_AI/R NAD PCI N_Data N_Data N_Data N_Data N_Data N_Data
FlowControl (FC) N_AI/E – N_AI/R NAD PCI PCI PCI N/A N/A N/A N/A
LIN
format
SingleFrame (SF) 0x3C - 0x3D NAD PCI SID N_Data N_Data N_Data N_Data N_Data
FirstFrame( FF) 0x3C - 0x3D NAD PCI LEN SID N_Data N_Data N_Data N_Data
ConsecutiveFrame (CF) 0x3C - 0x3D NAD PCI N_Data N_Data N_Data N_Data N_Data N_Data
FlowControl (FC) N/A N/A N/A N/A N/A N/A N/A N/A N/A
N_AI/E: Address of the LIN network for sending.
N_AI/R: Address of the LIN network for receiving.
NAD: Address of the LIN slave.
PCI: Protocol information.
LEN: Protocol information.
SID: Diagnostic service identifier.
N_DATA: Network data (Informative Data)
8.1.1 SINGLE_FRAME
The SINGLE_FRAME message is used for issuing a block of maximum 6 bytes of informative data.
LIN format
on the CAN
network
SingleFrame (SF) N_AI/E – N_AI/R NAD PCI SID N_Data N_Data N_Data N_Data N_Data
LIN format
SingleFrame (SF) 0x3C - 0x3D NAD PCI SID N_Data N_Data N_Data N_Data N_Data
 PCI: protocol information. This byte is defined as follows:
Type PCI type Additional information
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
SF: 0 0 0 0 Length

Page 34 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
463.229-
0006-02F
The frames going through the CAN network and sent to a LIN slave, in the case of a SF
type frame, must respect the following:
 The encoding of the number of informative data (PCI) in the diagnostic
requests and responses frames on the LIN network is done on the 4 low order
bits of the second byte.
The second byte high order nibble is set to 0.
 Byte 3 contains the SID
 The following bytes contain data.
GEN-VHL-DC-
DIAG.264 (1)
8.1.2 FIRST FRAME
The FIRST_FRAME message is used for issuing a block of more than 6 bytes of informative data. This message includes
the length of the informative data packet, coded in the PCI+LEN parameter. The first informative data bytes are also
included in this message.
LIN format
on the CAN
network
FirstFrame( FF) N_AI/E – N_AI/R NAD PCI LEN SID N_Data N_Data N_Data N_Data
LIN format
FirstFrame( FF) 0x3C - 0x3D NAD PCI LEN SID N_Data N_Data N_Data N_Data
FF 0 0 0 1 Length/256 (highest order)
 LEN: protocol information. This byte is defined as follows:
Type Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
FF length (Lowest order)
463.229-
0006-02G.1
For the frames on the CAN network and sent to a LIN slave, in the case of a FF type
frame:
 The encoding of the number of informative data in the diagnostic requests and
responses frames on the LIN network is done on the 4 low order bits of the
second byte (PCI) associated with the third byte (LEN) for a total length of 12
bits.
The second byte high order nibble is set to 1
 Byte 4 contains the SID.
GEN-VHL-DC-
DIAG.264 (1)
8.1.3 CONSECUTIVE_FRAME
The CONSECUTIVE_FRAME message is used during the sending of a block of more than 6 bytes of informative data
(SID + N_DATA). This message contains a segment of the data block to issue.
LIN format
on the CAN
ConsecutiveFrame (CF) N_AI/E – N_AI/R NAD PCI N_Data N_Data N_Data N_Data N_Data N_Data
LIN format
ConsecutiveFrame (CF) 0x3C - 0x3D NAD PCI N_Data N_Data N_Data N_Data N_Data N_Data

Page 35 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
CF 0 0 1 0 Frame counter
463.229-
0006-02H
For the frames on the CAN network and sent to a LIN slave, in the case of a CF type frame:
 The second byte low order nibble (PCI) represents the frame counter. When
sending a segmented frame, this counter is set to 1 for the first CF. It is then
incremented with each new CF. In case of an overflow; this counter takes the value
0 and is incremented for the following frames.
The second byte high order nibble is set to 2
GEN-VHL-
DC-DIAG.264
(1)
8.1.4 FLOW_CONTROL
The FLOW_CONTROL message is used to manage the exchange flow during the sending of the segments. This message
is issued by the data receiver. (LIN master or tool, the slave does not manage this frame)
LIN format
on the CAN
FlowControl (FC) N_AI/E – N_AI/R NAD PCI PCI PCI N/A N/A N/A N/A
LIN format
FlowControl (FC) N/A N/A N/A N/A N/A N/A N/A N/A N/A
 PCI byte 2: protocol information. This byte is defined as follows:
FC 0 0 1 1 FS
Type Additional information
FC BS
Type Additional information
FC STmin

Page 36 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
463.229-
0006-02J
For the frames on the CAN network and sent to a LIN slave, in the case of a FC type frame
(sent by the tool or the LIN master):
 The second byte high order nibble is set to 3
 The second byte low order nibble (PCI) FS represents the Flow_Status:
- OVERFLOW (FS = 2) to indicate that the message length (FF_DL) sent by the
sender is higher than the size of the receive buffer. The sender must then stop the
emission; the request is therefore not manageable by the receiver. This “overflow”
is therefore a request error or a design error because the receiver is not able to
process the request.
- WAIT (FS = 1) to temporarily stop the sending of the segments: The sender must
wait for a new FLOW_CONTROL message. As long as the Flow_status of the
FLOW_CONTROL message equals WAIT, the sender keeps on waiting for a new
FLOW_CONTROL message; When the sender receives a Flow_status equal to
CLEAR_TO_SEND, the sender resumes the transmission and sends a
CONSECUTIVE_FRAME message block.
- CLEAR_TO_SEND (FS = 0) to restart or confirm the transmission of the
following segments.
- The other values [3..0xF] are reserved (RESERVED) and must not be used
(generate an error case).
 The third byte (PCI) BS represents the Block Size (BS), BS indicates the number of
CONSECUTIVE_FRAME after which the sender must wait for the
FLOW_CONTROL message from the receiver before continuing to send its
CONSECUTIVE_FRAME; This FLOW_CONTROL message indicates to the sender
whether it can continue to send or if it must wait. This flow control mechanism is
repeated until all CONSECUTIVE_FRAME have been sent. If BS equals 0, only the
first FLOW_CONTROL message of the response to FIRST_FRAME is sent by the
receiver; no other FLOW_CONTROL message must be sent by the receiver as a
response to CONSECUTIVE_FRAME; the sender therefore sends all its
CONSECUTIVE_FRAME in a single burst (complying with STmin); The receiver
must therefore be designed to accept the maximum number of bytes that must be sent
to it (depending on the diagnostic, coding and programming of each ECU).
 The fourth byte (PCI) STmin specifies the minimum delay that must separate two
CONSECUTIVE_FRAME messages.
GEN-VHL-
DC-
DIAG.264
(1)
The use of these parameters is described in the following requirements.
8.1.4.1 Management of the overflow for the ECUs (LIN master)
This refers to the case where the ECU is not able to receive, in its receive buffer, the entire message sent by the tool
(FF_DL size indicated by the tool in the FIRST_FRAME); the master ECU of the LIN ECU must then response with a
FLOW_CONTROL frame containing a Flow_status equal to OVERFLOW ; the tool must then stop sending its message.
Requirement
no.
Description Input
requirement
463.229-0006-
02K
The master ECU must handle the standardized operations OVERFLOW, WAIT and
CLEAR_TO_SEND, associated with the sending of the frame FLOW_CONTROL, with
a Flow_status at OVERFLOW (0010b), WAIT (0001b) and CLEAR_TO_SEND
(0000b). Only these three values must be managed.
N/A
463.229-0006-
02L
A tool must stop issuing its message if it receives a FLOW_CONTROL frame
containing a Flow_status equal to OVERFLOW (0010b) from the receiver ECU.
N/A

Page 37 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
This refers to the case where the tool is not able to receive the entire message in its receiver buffer (FF_DL size indicated
for the ECU in the FIRST_FRAME frame).
A tool must always be able to accept the maximum size authorized by the protocol (4095 bytes).
Requirement
no.
Description Input
requirement
463.229-0006-
02M
A diagnostic tool must be able to receive messages with the maximum possible size of
4095 bytes, without generating a FLOW_CONTROL frame with a Flow_status equal to
OVERFLOW; consequently, a tool will never generate a FLOW_CONTROL with a
Flow_status equal to OVERFLOW.
N/A
Errors management:
Requirement
no.
Description Input
requirement
463.229-0006-
02N
If the tool receives a FLOW_CONTROL frame containing a Flow_status whose value
is higher than or equal to 3 (and lower than or equal to 0xF) (namely different from
OVERFLOW, WAIT and CLEAR_TO_SEND), it must:
 stop the emission of tool message,
N/A
463.229-0006-
02O
If a master ECU receives a FLOW_CONTROL frame containing a Flow_status whose
 stop the emission of ECU message,
 Notify the upper layer of the error
N/A
8.2 Segmenting
The segmentation of the messages coming from a LIN to a CAN network and vice versa is organized as follows:

Page 38 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
N_Cr
N_As
N_Cs
Tester Master Slave
FF
FC
CF
FC
CF
CF
FF
STmin_LIN
STmin_LIN
STmin_LIN
Bus Driver Transport
Network view Slave computer view
Waiting for a slot
Waiting for a slot
0x3C
0x3C
0x3D
0x3D
0x3D
0x3D
0x3D
P2
Transport Driver Bus
N_As
N_Cs
Master computer view
Waiting for a slot
Waiting for a slot
N_Cr
N_Cs
N_As

Page 39 of 40
PSA/DPTA/ use
2 - Confidential
PSA/DPTA/
3 –
PSA/DPTA/restricted
confidential
8.3 Parameters and timings
A LIN ECU does not manage the Flow Control (FC) frame. The LIN network master manages these parameters for its
slave, for sending and receiving.
The content of the FC frame concerning the exchange between a LIN ECU and a CAN ECU is the following:
requirement
Session type Block Size LIN STmin_LIN
463.229-0113-01A Extended diagnostic session 0 10 ms GEN-VHL-DC-
DIAG.264 (1)
463.229-0113-01B Specific programming session 0 0 ms GEN-VHL-DC-
DIAG.264 (1)
8.4 Timing
The timing parameter to comply with on the CAN network for the exchanges between a CAN ECU and a LIN slave are
the same as for the exchanges between 2 CAN ECUs, with the exception of the following parameters:
Requirement
no.
Timing
Description Minimum
period
Maximum
period
Performance
Input
requirement
463.229-0113-
01C.1
N_As_LIN
Bus transfert delay of a LIN
frame sent by the sender
See document [1]
GEN-VHL-
DC-DIAG.264
(1)
463.229-0113-
01D
N_Cr_LIN
Delay until the reception of
the first segment of the
current block
Not
applicable
200ms Not applicable
GEN-VHL-
DC-DIAG.264
(1)
463.229-0113-
01E.1
N_Cs_LIN
Delay until the transmission
of the first segment of the
current block
EXCEPTING
PROGRAMMING
Not
applicable
130ms
(N_Cs_LIN +
N_As_LIN)
< 0.9
N_Cr_LIN_max
GEN-VHL-
DC-DIAG.264
(1)
463.229-0113-
01F
N_Cs_LIN
Delay until transmission of
the first segment of the
current block
FOR PROGRAMMING
0ms
GEN-VHL-
DC-DIAG.360
(0)

02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc

02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc

Recommended

Recommended

More Related Content

Similar to 02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc

Similar to 02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc (20)

More from azrfdstgdgdfh

More from azrfdstgdgdfh (20)

Recently uploaded

Recently uploaded (18)

02016_11_11302_9646322999_Ind_F_TS_Implementation_of_the_network_layer_for_the_diagnostic_CAN_et_LIN_networks.doc