11 11302 9646322999 Ind F TS Implementation of The Network Layer For The Diagnostic CAN Et LIN Networks

Reference: Applicable to projects:
96 463 229 99 Ind. F Generic

PSA PEUGEOT CITROËN
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 J. D.BAUDREUIL
DTI/DITV/AEEV/AESV/AERE DTI/DITV/AEEV/AESV/AERE
This document is managed under DocInfo

No printed copy is managed. PSA breakdown: 98B
Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

PSA/DPTA/ use PSA/DPTA/ 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.
Generic 96 463 229 99 Ind. F TS_Implementation_of_the_network_layer_for_the_diagno Page 2 of 40
stic_CAN_and_LIN_networks
History of the document
Version Index Date Detail of modifications
9A A June 2001 First diffusion
9B B October 5.3.1 “After-sales diagnostic session” renamed” Active diagnostic communication session”
2001
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 Insertion of the requirement numbers in the document.
2002
6.3.3 Details on the timings values
99 OR February The requirement numbers have been updated by removing the “9C” index from the
2003 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 The diagnostic of ECUs on the LIN network is added.
2004
Modification of the document title to acknowledge the LIN acknowledgement.
Modification of the copywriter and verifier and addition of a verifier.

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

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.

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

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..................................................................................................................................................22
6.3 Diagnostic sessions..............................................................................................................................22
6.3.1 Generalities....................................................................................................................................................22

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

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.

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.

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 96.622.355.9A
réseau LIN (basée sur LIN 1.3)
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

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)

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- XX.YY.ZZ
Requirement description
CCCC-NNN.Y
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-
Deleted
CCCC-NNN.Y

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

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- Each ECU connected to the CAN INFO DIV, CAN CONF or CAN CAR GEN-VHL-DC-
01A.1 networks has a CAN identifier used to receive requests. DIAG.263 (0)
463.229-0003- Each ECU connected to the CAN INFO DIV, CAN CONF or CAN CAR GEN-VHL-DC-
01B.1 networks has a CAN identifier used to issue responses. DIAG.263 (0)
463.229-0003- Requirement deleted
01C
6.1.2.2 ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid network
Requirement Description Input requirement

no.
463.229-0003- Each ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid GEN-VHL-DC-
02A.1 network has a CAN identifier used to receive requests. DIAG.284 (0)
463.229-0003- Each ECU connected to the CAN Inter-Systems, CAN LAS and CAN Hybrid GEN-VHL-DC-
02B.1 network has a CAN identifier used to send requests. 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.

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]

no.
463.229-0003- Each ECU connected to a LIN network or sub-network has a CAN identifier GEN-VHL-DC-
03A used by the master to receive requests on the CAN network. DIAG.465 (1)
GEN-VHL-DC-
DIAG.439 (0)
GEN-VHL-DC-
DIAG.264 (1)
463.229-0003- Each ECU connected to a LIN network or sub-network has a CAN identifier GEN-VHL-DC-
03B used by the master to send responses on the CAN network.. 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 Description Input

no. requirement
463.229-0003- Each LIN network or sub-network has a CAN identifier used by the master to GEN-VHL-DC-
03C receive the requests on the CAN network and to send them on the corresponding DIAG.465 (1)
network. GEN-VHL-DC-
DIAG.439 (0)
463.229-0003- Each LIN network or sub-network has a CAN identifier used by the master to GEN-VHL-DC-
03D send the corresponding requests on the CAN network. DIAG.439 (0)
6.1.2.5 ECU connected to the CAN-DIAG network

463.229-0003- Each ECU connected to the CAN DIAG network has at least a CAN GEN-VHL-DC-
04A.1 identifier to receive requests. DIAG.284 (0)
463.229-0003-04B Each ECU connected to the CAN DIAG network has a CAN identifier to GEN-VHL-DC-
issue responses. 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 .

confidential

no.
463.229- For the ECUs that implement the KWP2000 protocol described in GEN-VHL-DC-DIAG.261 (1)
0005-01C.1 document [5] The maximum size of a diagnostic request or response on a GEN-VHL-DC-DIAG.13 (1)
CAN network is limited to 255 informative data bytes (excluding NPCI GEN-VHL-DC-DIAG.359 (0)
GEN-VHL-DC-DIAG.14 (1)
bytes of the segmentation protocol).
463.229- For the ECUs that implement the UDS protocol described in document GEN-VHL-DC-DIAG.261 (1)
0005-01D Error: Reference source not found The maximum size of a diagnostic GEN-VHL-DC-DIAG.13 (1)
request or response on a CAN network is limited to 4095 informative data GEN-VHL-DC-DIAG.359 (0)
bytes (excluding NPCI bytes of the segmentation protocol).
Requiremen Description Input requirement

t no.
463.229- The requests and responses too long to fit in one frame are segmented in GEN-VHL-DC-DIAG.261 (1)
0005-01B.1 frames having at most 8 bytes, according to the process described in GEN-VHL-DC-DIAG.13 (1)
chapter 7.2. GEN-VHL-DC-DIAG.359 (0)
463.229- On the CAN networks, if a Single_Frame, a FlowControl frame, or the GEN-VHL-DC-DIAG.261 (1)
0005-01A0.1 last Consecutive_Frame (last segment in the case of a segmented GEN-VHL-DC-DIAG.13 (1)
message) does not have enough data bytes to be filled up to 8 bytes, it GEN-VHL-DC-DIAG.359 (0)
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- The requests and the responses for a CAN communication with a size GEN-VHL-DC-DIAG.261 (1)
0005-01E.1 lower than or equal to 7 informative data bytes use the Single_Frame GEN-VHL-DC-DIAG.13 (1)
frame format. GEN-VHL-DC-DIAG.359 (0)
463.229- The requests and the responses for a CAN communication intended for the GEN-VHL-DC-DIAG.261 (1)
0005-01F LIN components or in the case of a LIN communication with the size GEN-VHL-DC-DIAG.13 (1)
lower than or equal to 6 informative data bytes use the Single_Frame GEN-VHL-DC-DIAG.359 (0)
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.

t no.
463.229- All diagnostic requests or replies targeted to or coming from a LIN ECU GEN-VHL-DC-DIAG.264 (1)
0005-02B 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.

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.

t no.
463.229- The master of the LIN sub-network (which executes the CAN  LIN GEN-VHL-DC-DIAG.466 (1)
0005-02A diagnostic gateway function) completes data of the diagnostic CAN GEN-VHL-DC-DIAG.264 (1)
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- The master of the LIN sub-network (which executes the CAN  LIN GEN-VHL-DC-DIAG.466 (1)
0005-02C gateway function) fills in, in the first byte of the LIN frame, the GEN-VHL-DC-DIAG.264 (1)
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- Reciprocally, the master of the LIN sub-network (which executes the LIN GEN-VHL-DC-DIAG.263 (0)
0005-02D  CAN gateway function) sends, on the CAN network, only the GEN-VHL-DC-DIAG.284 (0)
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- All LIN slaves must fill in their diagnostic replies (Single Frame identified GEN-VHL-DC-DIAG.264 (1)
0005-02E as 0x3D) with stuffing bytes. These bytes must be set to 0xFF, in order to
obtain 8 bytes long LIN frames.
463.229- All slaves that receive a diagnostic request frame (identified as 0x3C) GEN-VHL-DC-DIAG.264 (1)
0005-02F must only consider the "informative data" bytes of this frame and must
ignore the "padding" byte values.
463.229- The master of the LIN sub-network that receives a diagnostic request GEN-VHL-DC-DIAG.264 (1)
0005-02G frame (identified as 0x3D) must only consider the "informative data"
bytes of this frame and must ignore the "padding" byte values.
463.229- For each diagnostic request issued by the tool, toward one of its LIN N/A
0005-02H 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.
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.

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]

no.
463.229-0006- The headers of the LIN request and response frames have a specific GEN-VHL-DC-DIAG.439 (0)
01B identifier, 0x3C for the request, and 0x3D for the response.
463.229-0006- The low-order 4 bits of the first byte of the diagnostic request LIN frame GEN-VHL-DC-DIAG.439 (0)
01C 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- Reciprocally, the low-order 4 bits of the first byte of the LIN response GEN-VHL-DC-DIAG.439 (0)
01D 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.

t no.
463.229- A diagnostic tool communicates with a LIN slave using the diagnostic GEN-VHL-DC-DIAG.261 (1)
0006-01E services format defined by the KWP2000 (request/response).
463.229- In order not to generate segmentation on the LIN, the diagnostic services in GEN-VHL-DC-DIAG.264 (1)
0006-01F.1 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- All LIN slaves receive diagnostic request frames and analyze the first byte GEN-VHL-DC-DIAG.261 (1)
0006-01G 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- Only the LIN slave that is the recipient of the last 0x3C request is GEN-VHL-DC-DIAG.264 (1)
0006-01H authorized to response in the 0x3D response frame.
463.229- All the slave equipment on the LIN network whose response is not ready GEN-VHL-DC-DIAG.261 (1)
0006-01I 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- The high order bit of the first byte (bit 1.7) of the LIN diagnostic request GEN-VHL-DC-DIAG.264 (1)
0006-01J frames is always set to 1 (corresponds to the free of use frames in the LIN
standard).
463.229- The high order bit of the first byte (bit 1.7) of the diagnostic response GEN-VHL-DC-DIAG.439 (0)
0006-01K frames on the LIN is always set to 1 (corresponds to the free of use frames
in the LIN standard).
463.229- The encoding of the informative data size in the LIN diagnostic request GEN-VHL-DC-DIAG.439 (0)
0006-01L 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:

confidential
Content of byte 1 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0
DIAG_REQUETE (0x3C) and Reserved Frame informative data N_ECU_LIN_diag
DIAG_REPONSE (0x3D) (=1)
Possible values: 1 to 7 Station number of the LIN slave
(4 bits)
Requirement Input
Description
no. requirement
If the master must send a LIN diagnostic request (0x3C) when there is no request issued GEN-VHL-DC-
by the tool, the request frame sent by the diagnostic tool contains 0 informative byte and DIAG.261 (1)
the 1st byte is the following:1
463.229- - byte 1: 0x8F
0006-01M.1 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0
Reserved
0 0 0 1 1 1 1
(=1)
Size = 0 Diagnosed station number = 0xF
Requirement Input
Description
no. requirement
463.229- A LIN slave must ignore all diagnostic request frames received with an informative data GEN-VHL-DC-
0006-01N size equal to 0; the slave must not consider itself to be the recipient of this request. DIAG.261 (1)
6.2.2.3 ECU connected to LIN sub- networks that implement the protocol described in the document [10]
Requireme Input
Description
nt no. requirement
463.229- GEN-VHL-
The headers of the LIN request and response frames have a specific identifier, 0x3C for the DC-DIAG.264
0006-02A
request, and 0x3D for the response. (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.

no. requirement
463.229-0006- A diagnostic tool communicates with a LIN slave using the diagnostic services GEN-VHL-DC-
02B.1 defined in the UDS protocol (request/response). DIAG.264 (1)
463.229-0006- All LIN slaves receive diagnostic request frames and analyze the first byte which GEN-VHL-DC-
02C contains the number of the LIN slave, recipient of the request frame. Only the ECU DIAG.264 (1)
whose station number corresponds to the first byte executes the request.
This byte is the NAD.
463.229-0006- Only the LIN slave that is the recipient of the last request with the identifier 0x3C is GEN-VHL-DC-
02D authorized to reply in the response frame with the identifier 0x3D. DIAG.264 (1)
463.229-0006- Every slave ECU on the LIN network whose response is not ready after receiving a 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.
confidential

no. requirement
02E request must not fill in the corresponding slot.2

no.
463.229-0006- The diagnostic frames with the 0x3C or 0x3D header that travel on the LIN GEN-VHL-DC-
02I always contain 8 bytes. 3 DIAG.264 (1)
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)
2
This operation is the opposite of the one expected for the slaves that comply with the protocol described in document [3]
or [14]
3
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
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.

no. requirement
463.229-0007- The interlacing of several requests having the same ECU as destination is N/A
03A prohibited.
463.229-0007- The interlacing of requests toward several ECUs connected to the same LIN N/A
03B network is prohibited.
463.229-0007- The interlacing of request toward several ECUs, each connected to a different LIN N/A
03C network, must be handled.
463.229-0007- The interlacing of requests toward several CAN ECUs must be handled, whether N/A
03D they are on the same CAN network or not.
463.229-0007- The interlacing of requests toward several ECUs connected to different networks N/A
03E must be handled.
463.229-0007- Deleted N/A
03F
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:

no. requirement
Network life phase Standby Normal Standby Alarm Mode Defect
Session type inactive mode
463.229-0012- Deleted N/A
01A.1
463.229-0012- Deleted N/A
01B.1
463.229-0012- Deleted N/A
01C.1
463.229-0012- All sessions No Yes No GEN-VHL-
No Yes Yes
01F DC-
DIAG.278 (1)
463.229-0012- If it is impossible to open a diagnostic session in one of the situations above, the ECU GEN-VHL-
01D does not response to the tool request. DC-
DIAG.278 (1)

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

requiremen
t
463.229-0012- Deleted N/A
01E.1
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
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.

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 250 ms GEN-VHL-
intended for an CAN or a LIN ECU DC-
using the protocol in document [3] DIAG.430
(0)
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.
463.229-0030-01F T_Ret_LIN Return time to the tool of a request 1000 ms GEN-VHL-
intended for an LIN ECU using the DC-
protocol in document [10]. DIAG.430
(0)
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.
463.229-0030-01B T_Diag Maximum delay that separates the 200 ms GEN-VHL-
CAN receiving of a request and the start of DC-
the emission of its response for DIAG.430
(0)
ECUs on the CAN network.
463.229-0030-01E.1 T_Diag Maximum delay that separates the See document [6] or GEN-VHL-
LIN or receiving of a request and the start of document [8] according to DC-
P2_LIN the emission of its response for the the protocol used DIAG.430
(0)
ECUs on the LIN network.
463.229-0030-01C Deleted N/A
463.229-0030-01D Deleted N/A

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 Informative data
Information)
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:
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:

confidential
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 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 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

confidential
sender continues to wait for a new FLOW_CONTROL message; The transmission resumes when the sender receives
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.

no. requirement
463.229-0105- An ECU must handle the standardized operations OVERFLOW, WAIT and N/A
01A 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.
463.229-0105- A tool must stop issuing its message if it receives a FLOW_CONTROL frame N/A
01B containing a Flow_status equal to OVERFLOW (0010b) from the receiver ECU.
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).

no. requirement
463.229-0105- A diagnostic tool must be able to receive messages with the maximum possible size of N/A
01C 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.
463.229-0105- Deleted N/A
01D.1
Errors management:

no. requirement
463.229-0105- If the tool receives a FLOW_CONTROL frame containing a Flow_control whose N/A
confidential

no. requirement
01E 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.
463.229-0105- If an ECU receives a FLOW_CONTROL frame containing a Flow_control whose N/A
01F value is higher than or equal to 2 (and lower than or equal to 0xF) (namely different
 stop the emission of ECU message,
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.

confidential
7.2 Segmenting
7.2.1 Sequence
In the case when a request or a response is segmented, the sequencing is as follow:
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

no. requirement
463.229-0108- The tool sends its FIRST_FRAME to a CAN or LIN ECU using the request GEN-VHL-DC-
01A.1 identifier of this ECU. DIAG.262 (0)
463.229-0108- The ECU sends its FLOW_CONTROL frame to the tool using its response GEN-VHL-DC-
01B.1 identifier. If the recipient ECU of the segmented frame is a LIN slave, its master DIAG.262 (0)
sends the FLOW_CONTROL frame according to document [8]
463.229-0108- The tool then sends all its CONSECUTIVE_FRAME to the CAN or LIN ECU, GEN-VHL-DC-
01C.1 using the request identifier. DIAG.262 (0)
7.2.2.2 Emission of a segmented response

no. requirement
463.229-0108- The ECU sends its FIRST_FRAME to the tool using its response identifier or, if GEN-VHL-DC-
01D.1 the ECU is a LIN slave, the response identifier of the network to which it DIAG.262 (0)
belongs.
463.229-0108- The tool sends its FLOW_CONTROL frame to the CAN ECU using the request GEN-VHL-DC-
confidential

no. requirement
01E.2 identifier of this ECU. DIAG.262 (0)
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.
463.229-0108- The ECU then issues all its CONSECUTIVE_FRAME frames to the tool using GEN-VHL-DC-
01F.1 its response identifier. 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- All sessions except programming session 0 10 ms N/A
01B.1 FOR A ECU.
463.229-0110-01E Every session FOR A DIAGNOSTIC 0 0 ms N/A
TOOL.
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, GEN-VHL-
the STmin value received in the FLOW_CONTROL frame as a response to its DC-
FIRST_FRAME. 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.

no.
Type of data transfer Block STmin
Size
463.229-0111- Receiving download data for body ECUs (CAN Inter- 0 0 ms GEN-VHL-DC-
01A Systems ECUs are not concerned) DIAG.19 (0)
GEN-VHL-DC-
DIAG.20 (1)
GEN-VHL-DC-
DIAG.360 (0)
GEN-VHL-DC-
DIAG.21 (0)

confidential
7.4 Timing
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 Timing Description Minimum Maximum Performance Input requirement

no. period period
463.229- Bus transfert delay of For the ECUs connected to the CAN GEN-VHL-DC-DIAG.262 (0)
0112-01A.1 N_As a CAN frame issued Inter-systems and CAN Diag networks,
by the sender these two parameters are not relevant.
463.229- Bus transfert delay of For the ECUs connected to the CAN GEN-VHL-DC-DIAG.262 (0)
0112-01B.1 N_Ar a CAN frame issued CONF, CAR and INFO DIV networks,
by the receiver see document [1]
463.229- N_Bs Delay until receiving Not 250 ms for GEN-VHL-DC-DIAG.430 (0)
0112-01C.1 the next applicable Body
Flow_Control networks
message (CAN LS
CAR, DIV
and CONF)

confidential
Requirement Timing Description Minimum Maximum Performance Input requirement

no. period period
1000 ms for GEN-VHL-DC-DIAG.262 (0)
Powertrain
networks
(CAN_IS)
463.229- Delay until sending 200 ms for GEN-VHL-DC-DIAG.262 (0)
0112-01D.1 the next Powertrain
Flow_Control networks
message (CAN_IS) (N_Br +
N_Ar)
N_Br 0 ms 30 ms for < 0.9
Body N_Bs_max
networks
(CAN LS,
CAN DIAG)
463.229- Delay until reception 250 ms for GEN-VHL-DC-DIAG.262 (0)
0112-01E.1 of the first segment of Body
the current block networks
(CAN LS
Not CAR, DIV
N_Cr and CONF)
applicable
1000 ms for GEN-VHL-DC-DIAG.262 (0)
the
powertrain
(CAN_IS)
463.229- Delay until 200 ms for GEN-VHL-DC-DIAG.262 (0)
0112-01F.2 transmission of the Powertrain
first segment of the networks
current block (CAN_IS) (N_Cs +
EXCEPTING N_As)
N_Cs Stmin STmin + 10
PORGRAMMING < 0.9
ms for Body N_Cr_max
networks
(CAN LS,
CAN DIAG)
463.229- Delay until GEN-VHL-DC-DIAG.19 (0)
0112-01G.1 transmission of the
STmin GEN-VHL-DC-DIAG.360 (0)
first segment of the
N_Cs STmin GEN-VHL-DC-DIAG.21 (0)
current block (CAN network inter
frame delay)
FOR
PROGRAMMING
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.

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.
N_PDU type Identifier Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
LIN format on
SingleFrame (SF) N_AI/E – N_AI/R NAD PCI SID N_Data N_Data N_Data N_Data N_Data
the CAN
network
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 N_PDU type Identifier Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
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

confidential
463.229- The frames going through the CAN network and sent to a LIN slave, in the case of a SF GEN-VHL-DC-
0006-02F type frame, must respect the following: DIAG.264 (1)
 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.
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.
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- For the frames on the CAN network and sent to a LIN slave, in the case of a FF type GEN-VHL-DC-
0006-02G.1 frame: DIAG.264 (1)
 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.
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.
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

confidential

CF 0 0 1 0 Frame counter
463.229- For the frames on the CAN network and sent to a LIN slave, in the case of a CF type frame: GEN-VHL-DC-
0006-02H  The second byte low order nibble (PCI) represents the frame counter. When DIAG.264 (1)
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
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)
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

confidential
463.229- For the frames on the CAN network and sent to a LIN slave, in the case of a FC type frame GEN-VHL-
0006-02J (sent by the tool or the LIN master): DC-
 The second byte high order nibble is set to 3 DIAG.264
(1)
 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.
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.

no. requirement
463.229-0006- The master ECU must handle the standardized operations OVERFLOW, WAIT and N/A
02K 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.
463.229-0006- A tool must stop issuing its message if it receives a FLOW_CONTROL frame N/A
02L containing a Flow_status equal to OVERFLOW (0010b) from the receiver ECU.

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

no. requirement
463.229-0006- A diagnostic tool must be able to receive messages with the maximum possible size of N/A
02M 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.
Errors management:

no. requirement
463.229-0006- If the tool receives a FLOW_CONTROL frame containing a Flow_status whose value N/A
02N 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,
463.229-0006- If a master ECU receives a FLOW_CONTROL frame containing a Flow_status whose N/A
02O value is higher than or equal to 2 (and lower than or equal to 0xF) (namely different
 stop the emission of ECU message,
 Notify the upper layer of the error
8.2 Segmenting
The segmentation of the messages coming from a LIN to a CAN network and vice versa is organized as follows:

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 Description Minimum Maximum Input
Timing Performance
no. period period requirement
463.229-0113- Bus transfert delay of a LIN GEN-VHL-
01C.1 frame sent by the sender DC-DIAG.264
N_As_LI (1)
See document [1]
N
463.229-0113- Delay until the reception of GEN-VHL-

01D the first segment of the DC-DIAG.264
Not (1)
N_Cr_LIN current block 200ms Not applicable
applicable
463.229-0113- Delay until the transmission GEN-VHL-

01E.1 of the first segment of the (N_Cs_LIN + DC-DIAG.264
current block Not N_As_LIN) (1)
N_Cs_LIN 130ms
applicable < 0.9
EXCEPTING PROGRAM- N_Cr_LIN_max
MING
463.229-0113- Delay until transmission of GEN-VHL-
01F the first segment of the 0ms DC-DIAG.360
N_Cs_LIN current block (0)
FOR PROGRAMMING
9 Strategy of error recovery strategy
For ECUs able to communicate with a diagnostic tool, if the appropriate error handling strategy is not defined in this
document, the default choice is to abandon the transmission.

no. requirement
463.229-0300- For the ECUs connected to the CAN Comfort, Body and Entertainment networks, N/A
01A.2 the overrunning of the maximum time N_Asmax triggers the abort of the sending of
the request by the sender.
463.229-0300- For the ECUs connected to the CAN Comfort, Body and Entertainment networks, N/A
01B.2 the overrunning of the maximum time N_Ar max triggers the abort of the reception of
the request by the receiver.
463.229-0300- The overrunning of the maximum time N_Bs max triggers the abort of the sending of N/A
01C.1 the request by the sender
463.229-0300- The overrunning of the maximum time N_Cr max triggers the abort of the reception of N/A
01D.1 the request by the receiver.
463.229-0300- The receiving of an unexpected frame interrupts the segmented exchange in N/A
01E.1 progress.
For the receiver, a frame is considerer unexpected in the following cases:
 length different from the expected one
 reception of a ConsecutiveFrame without preceding FirstFrame.
 Invalid sequence SN of a ConsecutiveFrame (SN of the current frame
differs from the SN of the previous frame + 1, modulo 15)
For the sender, a frame is considerer unexpected in the following cases:
 length different from the expected one
 reception of a FlowControl frame before the number of ConsecutiveFrame
specified by the BS parameter has been reached
463.229-0300- The reception of a response after T_Ret or T_Ret_LIN must be ignored. N/A
01F.1
463.229-0300- The reception of a request before T_Diag or T_Diag LIN, while the previous request N/A
01G.1 received has not been completely processed must be ignored.

11 11302 9646322999 Ind F TS Implementation of The Network Layer For The Diagnostic CAN Et LIN Networks

Uploaded by

Copyright:

Available Formats

You might also like

11 11302 9646322999 Ind F TS Implementation of The Network Layer For The Diagnostic CAN Et LIN Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11 11302 9646322999 Ind F TS Implementation of The Network Layer For The Diagnostic CAN Et LIN Networks

Uploaded by

Copyright:

Available Formats

Reference: Applicable to projects:

96 463 229 99 Ind. F Generic

WRITTEN BY VERIFIED BY APPROVED BY

This document is managed under DocInfo

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

History of the document

Version Index Date Detail of modifications

9A A June 2001 First diffusion

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Version Index Date Detail of modifications

Page layout modified (1st page, headers and footers).

Version Index Date Detail of modifications

99 C 04/07/05 Written by: C.MARCHAND

99 D 21/12/2006 Written by: C. MEUNIER

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Version Index Date Detail of modifications

Modification of the comments in chapter 6.2.3.

99 E 26/04/2007 Written by: C. MEUNIER

99 F 09/04/08 Written by: A. PROVO

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Version Index Date Detail of modifications

§6.2.1.1: Rephrasing of the requirement 463.229-0005-01A (replaced empty bytes by

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

History of the document........................................................................................................................2

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

3.1 Internal PSA justification file

3.2 PSA internal documents

3.3 Standards and procedures

[N1] CAN Standard

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

4.3 Abbreviations and acronyms

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

5.1 Presenting a requirement

Requirement no. Description Input requirement

5.2 Numbering a requirement

Requirement no. Description Input requirement

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

6.1 Principles of communication

6.1.1 Exchange Type

Each gateway can execute a more or less complex processing:

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

6.1.2 Addressing mode and Identifier

Requirement no. Description Input requirement

Requirement Description Input requirement

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

See [3] or [14]

Requirement Description Input requirement

Requirement Description Input

6.1.2.5 ECU connected to the CAN-DIAG network

Requirement no. Description Input requirement

6.2 Request/response mode

6.2.1 Requests and replies size and frame size

Date: 09/04/2008 Classification level 1- Internal 2 - Confidential 3–

Requirement Description Input requirement

Requiremen Description Input requirement