ISO 14230-2:1999

Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 2: Data link layer

Véhicules routiers — Systèmes de diagnostic — Protocole "Keyword 2000" — Partie 2: Couche de liaison de données

General Information

• Status: Withdrawn
• Publication Date: 17-Mar-1999
• Withdrawal Date: 17-Mar-1999
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31 - Data communication
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 15-Mar-2013

Relations

• Revised: ISO 14230-2:2013 - Road vehicles — Diagnostic communication over K-Line (DoK-Line) — Part 2: Data link layer
• Effective Date: 14-Nov-2009

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14230-2
First edition
1999-03-15
Road vehicles — Diagnostic systems —
Keyword Protocol 2000 —
Part 2:
Data link layer
Véhicules routiers — Systèmes de diagnostic — Protocole «Keyword
2000» —
Partie 2: Couche de liaison de données
A
Reference number
ISO 14230-2:1999(E)

---------------------- Page: 1 ----------------------
ISO 14230-2:1999(E)
Contents Page
1 Scope . 1
2 Normative references . 1
3 Physical topology . 2
4 Message structure . 2
4.1 General . 2
4.2 Header . 3
Data bytes .
4.3 5
4.4 Checksum byte . 6
4.5 Timing . 6
5 Communication services . 9
5.1 General . 9
5.2 StartCommunication Service . 9
5.3 StopCommunication Service . 16
5.4 AccessTimingParameter Service . 18
5.5 SendData Service . 23
6 Error handling . 23
6.1 StartCommunication Service . 23
6.2 Mainstream Communications . 24
Annex A  ECU/tester addresses for 5 Baud initialization . 26
Annex B  ECU/tester addresses for fast initialization . 27
Annex C  Bibliography . 28
©  ISO 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet [e-mail]
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
© ISO
ISO 14230-2:1999(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
International Standard ISO 14230-2 was prepared by Technical Committee ISO/TC 22, Road vehicles,
subcommittee SC 3, Electrical and electronic equipment.
ISO 14230 consists of the following parts, under the general title Road vehicles — Diagnostic systems — Keyword
Protocol 2000 :
 Part 1: Physical layer
 Part 2: Data link layer
 Part 3: Application layer
 Part 4: Requirements for emissions-related systems
Annex A forms an integral part of this part of ISO 14230. Annexes B and C are for information only.
iii

---------------------- Page: 3 ----------------------
© ISO
ISO 14230-2:1999(E)
Introduction
ISO 14230 has been established in order to define common requirements for diagnostic systems implemented on a
serial data link.
To achieve this, it is based on the Open System Interconnection (OSI) Basic Reference Model in accordance with
ISO 7498 which structures communication systems into seven layers. When mapped on this model, the services
used by a diagnostic tester and an Electronic Control Unit (ECU) are broken into:
 diagnostic services (layer 7);
 communication services (layers 1 to 6),
in accordance with figure 1.
Figure 1 — Mapping of diagnostic services on OSI Model
iv

---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD  © ISO ISO 14230-2:1999(E)
Road vehicles — Diagnostic systems — Keyword Protocol 2000 —
Part 2:
Data link layer
1 Scope
This part of ISO 14230 specifies common requirements of diagnostic services which allow a tester to control
diagnostic functions in an on-vehicle Electronic Control Unit (for example, electronic fuel injection, automatic
gearbox, antilock braking system, etc.) connected on a serial data link embedded in a road vehicle.
It specifies only layer 2 (data link layer). Included are all definitions which are necessary to implement the services
(described in ISO 14230-3) on a serial link (described in ISO 14230-1). Also included are some communication
services which are needed for communication/session management and a description of error handling.
This part of ISO 14230 does not specify the requirements for the implementation of diagnostic services.
The physical layer may be used as a multiuser-bus, so a kind of arbitration or bus management is necessary. There
are several proposals which are not part of this part of ISO 14230. The car manufacturers are responsible for the
correct working of bus management.
Communication between ECUs are not part of this part of ISO 14230.
The vehicle diagnostic architecture of this part of ISO 14230 applies (see figure 2) to
 a single tester that may be temporarily or permanently connected to the on-vehicle diagnostic data link, and
 several on-vehicle electronic control units connected directly or indirectly.
Figure 2 — Vehicle diagnostic architecture
1

---------------------- Page: 5 ----------------------
© ISO
ISO 14230-2:1999(E)
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of
ISO 14230. All the time of publication, the editions were indicated were valid. All standards are subject to revision,
and parties to agreement based on this part of ISO 14230 are encouraged to investigate the possibility of applying
the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently
valid International Standards.
ISO 9141:1989, Road vehicles — Diagnostic systems — Requirements for interchange of digital information.
ISO 9141-2:1994, Road vehicles — Diagnostic systems — Part 2: CARB requirements for interchange of digital
information.
ISO 14230-3:1999, Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 3: Application layer.
ISO 14230-4:1999, Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4: Requirements for
emission related systems.
SAE J 1979: 1996, E/E diagnostic test modes.
3 Physical topology
Keyword Protocol 2000 is a bus concept. Figure 3 shows the general form of this serial link.
ECU 1
ECU 2 ECU n Tester
K-Line
L-Line (opt.)
Figure 3 — Topology
The K-line is used for communication and initialization; the L-line (optional) is used for initialization only. Special
cases are node-to-node-connection, which means there is only one ECU on the line which also can be a bus
converter.
4 Message structure
4.1 General
The message structure consists of three parts:
 header;
 data bytes;
 checksum.
See figure 4.
2

---------------------- Page: 6 ----------------------
© ISO
ISO 14230-2:1999(E)
Header and checksum bytes are described in this part of ISO 14230. The area of data bytes always begins with a
Service Identification.
The data bytes and their use are described in ISO 14230-3 and this part of ISO 14230.
Header Data bytes Checksum
1) 1) 1) 2) 2)
Fmt Tgt Src Len SId . . Data . . CS
max . 4 byte max. 255 byte 1 byte
1) bytes are optional, depending on format byte.
2) Service Identification, part of data bytes.
NOTE — The shaded area (header, checksum) are described in this part of ISO 14230.
Figure 4 — Message structure
4.2 Header
The header consists of a maximum of 4 bytes. A format byte includes information about the form of the messages,
target and source address bytes are optional for use with multinode connections, an optional separate length byte
allows message lengths up to 255 bytes.
4.2.1 Format byte
The format byte contains 6 bit length information and 2 bit address mode information. The tester is informed about
use of header bytes by key bytes (see 4.2.2).
A1 A0 L5 L4 L3 L2 L1 L0
where
A1 and A0 define the form of header which will be used by the message in accordance with table 1;
L5.L0 define the length of a message from the beginning of the data fields (ServiceIdentification
byte included) to checksum byte (not included). A message length of 1 to 63 bytes is
possible. If L0 to L5 = 0 then the additional length byte is included (see 4.2.5).
3

---------------------- Page: 7 ----------------------
© ISO
ISO 14230-2:1999(E)
Table 1 — Header message form
A1 A0 Mode
0 0 no address information
0 1 Exception mode (CARB)
1 0 with address information, physical addressing
1 1 with address information, functional addressing
A.1,A.0=01 (CARB mode) is an exception mode. The CARB mode is not specified in this part of ISO 14230. CARB
uses format bytes $68 (0110 1000) and $48 (0100 1000). For more details refer to ISO 9141-2 and SAE J1979.
4.2.2 Target address byte
This is the target address for the message and is always used together with the source adress byte. The target
address in the request messages sento to the ECU may be a physical or a functional address. The target address
in the response messages sent to the tester shall be the physical address of the tester. Physical addresses may be
the 5 baud address byte (see annex A) or addresses according to SAE J 2178-1 (see annex B). The target address
byte is optional and only necessary on multimode bus topologies. For node-to-node connections it may be omitted.
For CARB messages this byte is defined in ISO 9141-2 or ISO 14230-4.
4.2.3 Source address byte
This is the address of the transmitting device. It shall be a physical address. There are the same possibilities for the
values as described for physical target address bytes. Addresses for testers are listed in SAE J2178-1 (see annex
B). This byte is optional (always used together with target address byte) and only necessary on multinode bus
topologies. For node-to-node connections it may be omitted.
4.2.4 Length byte
This byte is provided if the length in the header byte (L0 to L5) is set to 0 as shown in table 2. It allows the user to
transmit messages with data fields longer then 63 bytes. With shorter messages it may be omitted. This byte
defines the length of a message from the beginning of the data field (service identification byte included) to
checksum byte (not included). A data length of 1 byte to 255 bytes is possible. The longest message consists of a
maximum of 260 bytes. For messages with data fields of less than 64 bytes there are two possibilities: length may
be included in the format byte or in the additional length byte. An ECU does not need to support both possibilities,
the tester is informed about the capability of an ECU through the keybytes (see 6.1.2.1).
Table 2 — Presence of a length byte
Length Length provided in
1)
Fmt byte
Length byte
< 64 XX00 0000 present
< 64 XXLL LLLL not present
≥ 64 XX00 0000 present
1) XX : 2 bits address mode information (see 4.2.1)
LL LLLL : 6 bits length information.
4.2.5 Use of header bytes
With the above definitions there are four different forms of message. These are shown diagramatically in figure 5.
4

---------------------- Page: 8 ----------------------
© ISO
ISO 14230-2:1999(E)
Length
Fmt SId Data CS
Checksum
a) Header with address information, no additional length byte
Length
Fmt Tgt Src SId Data CS
Checksum
b) Header with address information, no additional length byte
Length
Fmt Len SId Data CS
Checksum
c) Header without address information, additional length byte
Length
Fmt Tgt Src Len SId Data CS
Checksum
d) Header with address information, with additional length byte
Fmt Format byte SId Service Identification Byte
Tgt Target address (optional) Data (depending on service)
Src Source address (optional) CS Checksum byte
Len additional length byte (optional)
NOTE — The unshaded area is defined in ISO 14230-3.
Figure 5 — Header messages
4.3 Data bytes
The data field may contain up to 63 or up 255 bytes of information, depending on the use of length information. The
first byte of the data field is the Service Identification Byte. It may be followed by parameters and data depending on
the selected service. These bytes are defined in ISO 14230-3 (for diagnostic services) and in clause 5 (for
communication services).
5

---------------------- Page: 9 ----------------------
© ISO
ISO 14230-2:1999(E)
4.4 Checksum byte
The checksum byte (CS) inserted at the end of the message block is defined as the simple 8 bit sum series of all
bytes in the message, excluding the checksum.
If the message is
〈1〉 〈2〉 〈3〉 . 〈N〉, 〈CS〉
the two following cases may occur:
th
〈i〉 ≤ i ≤ i
when (1  N) is the numerical value of the message byte, then :
〈CS〉 = 〈CS〉
N
when 〈CS〉 (2 ≤ i ≤ N):
i
when 〈CS〉i = { 〈CS〉 + 〈i〉 } mod256 et
i-1
〈 〉 〈 〉
CS = 1
1
Additional security may be included in the data field as defined by the manufacturer.
4.5 Timing
4.5.1 Value entering
During normal operation the timing parameters as shown in figure 6 are relevant.
Tester ECU 1 ECU 2 Tester
request response response request
. . . . . . . . .
. . .
P
2
P P P P
P
4 2 1 2 3
Value Description
P1 Inter byte time for ECU response
P2 Time between tester request and ECU response or two ECU responses
P3 Time between end of ECU responses and start of new tester request
P4 Inter byte time for tester request
Figure 6 — Timing
There are two sets of default timing parameters :
a) one set for normal functional and physical addressed communication. Longer timings are necessary to allow
any technics of bus management;
b) one set restricted to physical addressing to allow faster communication.
The tester is informed about the capability of an ECU through the keybytes (see 5.2.4.1).
Timing parameters may be changed with the communication service "AccessTimingParameters" (see 5.4).
6

---------------------- Page: 10 ----------------------
© ISO
ISO 14230-2:1999(E)
Users shall take note of limits listed below and the following restrictions:
P3 > P4
min min
Pi < Pi for i = 1, ., 4
min max
There may be further restrictions, when the tester and listening ECUs detect the end of a message by timeout. In
this case the following restrictions are valid:
P2 > P4
min max
P2 > P1
min max
In case of functional addressing, i.e. that there may be more than one response to one request, further restrictions
may be added.
It is in the designers' responsibility to ensure proper communication in the case of changing the timing parameters
from the default values.They shall also ensure that the chosen communication parameters are possible for all ECUs
which participate in the session.
The possible values depend on the capabilities of the ECU. In some cases the ECU may need to leave its normal
operation mode to switch over to a session with different communication parameters.
Tables 3 and 4 show the timing parameters which are used as default, the limits within which they can be changed
and the resolution which may be used to set a new value (with the communication service AccessTimingParameter:
see 5.4).
Table 3 — Normal Timing Parameters Set (for functional and physical addressing)
Values in milliseconds
Timing Minimum values Maximum values
Parameter
Lower limit Default Resolution Default Upper limit Resolution
P1 0 0 - 20 20 -
P2 0 25 0,5 50 See table 5
P3 0 55 0,5 5 000 250
` ($FF)
P4 0 5 0,5 20 20 -
Table 4 — Extended Timing Parameters Set (for physical addressing only)
Values in milliseconds
Timing Minimum values Maximum values
Parameter
Lower limit Default Resolution Default Upper limit Resolution
P1 0 0 - 20 20 -
P2 0 25 0,5 50 See table 5
P3 0 55 0,5 5 000 250
` ($FF)
P4 0 5 0,5 20 20 -
7

---------------------- Page: 11 ----------------------
© ISO
ISO 14230-2:1999(E)
Table 5 — P2max Timing Parameter calculation
Hex. Resolution Maximum Maximum value calculation method
value value
ms
ms
01 to F0 25 25 to 6 000 (hex. value) x (Resolution)
F1 6 400
F2 12 800
F3 19 200
F4 25 600
F5 32 000 (low nibble of hex. value) x 256 x 25
F6 see maximum 38 400
value
F7 44 800
calculation
F8 51 200 Example of $FA :
method
F9 57 600 ($0A x $0100) x 25 = 64 000
FA 64 000
FB 70 400
FC 76 800
FD 83 200
FE 83 600
FF - Not applicable
`
The P2max timing parameter value shall always be a single byte value in the
AccessTimingParameter service. The timing modifications shall be activated by
implementation of the AccessTimingParameter service.
Proposed P2 timing parameter calculation method (values > 6 000 ms):
max
The P2 timing parameter calculation uses 25 ms resolution in the range of $01 to $F0. Beginning with $F1, a
max
different calculation method shall be used by the server and the client in order to reach P2 timing values greater
max
than 6 000 ms.
Calculation Formula P2 values > $F0
max
Calculation_Of_P2 = (low nibble of P2 ) × 256 × 25 (ms)
max max
The P2max timing parameter value shall always be a single byte value in the AccessTimingParameter service. The
timing modifications shall be activated by implementation of the AccessTimingParameter service.
4.5.2 Timing exceptions
The extended P2 timing window is a possibility for (a) server(s) to extend the time to respond on a request
message. A P2max timing exception is only allowed with the use of one or multiple negative response message(s)
with response code $78 (RequestCorrectlyReceived-ResponsePending) by the server(s). This response code shall
only be used by a server in case it cannot send a positive or negative response message based on the client's
request message within the active P2 timing window. This response code shall manipulate the P2max timing
parameter value in the verver and the client. The P2max timing parameter is set to the value (in ms) of the P3max
timing parameter. The client shall remain in the receive mode. The server(s) shall send multiple negative response
messages with the negative response code $78 if required.
As soon as the server has completed the task (ourtine) initiated by the request message it shall send either a
positive or negative response message (negative response message with a response code other than $78 ) based
on the last request message received. When the client has received the response message which has been
preceeded by the negative response message(s) with response code $78, the client and the server shall reset the
P2max timing parameter to the previous timing value. The client shall not repeat the request message after the
reception of a negative response message with response $78 .
8

---------------------- Page: 12 ----------------------
© ISO
ISO 14230-2:1999(E)
5 Communication services
5.1 General
Some services are necessary to establish and maintain communication. Those are not diagnostic services because
they do not appear on the application layer. They are described in the same formal way and with the same
conventions (CVT) as the Diagnostic Services (see ISO 14229): a service table and a verbal description of the
service procedure. The existence of parameters is shown as follows:
 mandatory: M,
 selectable: S,
 conditional: C,
 user-optional: U.
A description of implementation on the physical layer of Keyword Protocol 2000 is added.
In general services are not mandatory: only StartCommunication Service shall be implemented.
The StartCommunication Service and the AccessTimingParameters Service are used for starting a diagnostic
communication. In order to perform any diagnostic service, communication shall be initialized and the
communication parameters need to be appropriate to the desired diagnostic mode. A chart describing this is shown
in figure 7.
5.2 StartCommunication Service
5.2.1 Service definition
The purpose of this KWP 2000 communication layer service is to initialize the communication link for the exchange
of diagnostic data.
5.2.2 Service table
See table 6.
Table 6 — StartCommunication Service
StartCommunication Request
M
1)
M
Initialization Mode Identifier
Target Initialization Address M
2)
Source Initialization Address
C1
StartCommunication Positive Response M
3)
Target Address
C2
3)
Source Adress
C2
Key bytes
M2
Keybytes M2
1) The way of initialization is determined by the Initialization Mode Identifier, the
value of this parameter may be CARB-initialization, 5-baud initialization or fast
initialization.
2) C1 : Source initialization address is added if initialization Mode Identifier = Fast
Initialization.
3) C2 : Target and source address are added if addresss information is used in
the header (three or four byte header).
9

---------------------- Page: 13 ----------------------
© ISO
ISO 14230-2:1999(E)
1) Communication Service
2) Diagnostic Service
Figure 7 — Use of communication services
5.2.3 Service procedure
Upon receiving a StartCommunication indication primitive, the ECU shall check if the requested communication link
can be initialized under the present conditions. Valid conditions for the initialization of a diagnostic communication
link are described in 5.3.2.
Then the ECU shall perform all actions necessary to initialize the communication link and send a
StartCommunication response primitive with the Positive Response parameters selected.
If the communication link cannot be initialized for any reason, the ECU shall maintain its normal operation (see 6.1).
10

---------------------- Page: 14 ----------------------
© ISO
ISO 14230-2:1999(E)
5.2.4 Implementation
The StartCommunication Service is used to initialize a communication on the K-line. There are different possibilities
to initialize:
a) CARB initialization;
b) 5-Baud initialization;
c) fast initialization.
Figure 8 shows three possibilities and the ECU status after each kind of initialization. After finishing the initialization,
the ECUs are in the same status, regardless of the initialization mode:
 all communication parameters are set to default values according to the key bytes;
 ECU is waiting for the first request of the tester for a time period of P3;
 ECU is in the default diagnostic mode (i.e., it has a well defined functionality).
Start
Communication
No Yes
Initialisation
Mode = CARB?
  Initialisation
5Baud fast
Mode =fast or
5 Baud?
5 Baud Initialisation
with
Fast Initialisation CARB Initialisation
5Bd-Address =
Target init.address
Default Timing
CARB Timing
acc. to keybytes
CARB Mode
Default Diag. Mode
End of
"Start
Communication"
Figure 8 — Initialization modes
11

---------------------- Page: 15 ----------------------
© ISO
ISO 14230-2:1999(E)
There are general facts that are common to all modes of initialization:
 prior to any activity there shall be a bus-idle time;
 then the tester sends an initialization pattern;
 all information which is necessary to establish communication is contained in the response of the ECU.
5.2.4.1 Key bytes
With these bytes an ECU informs the tester about the supported header, timing and length information. So an ECU
does not necessarily have to support all possibilities.
The decoding of the key bytes is defined in ISO 9141.
Graphical representation of the keybytes is given in figure 9, and meanings of each of their bit values in table 7.
Table 8 gives possible keybyte values.
Figure 9 — Keybytes
Table 7 — Meaning of bit values in keybytes
Bit Value
01
AL0 length inf. in format byte not supported length inf. in format byte supported
AL1 add. length byte not supported add. length byte supported
HB0 1 byte header not supported 1 byte header supported
HB1 Tgt/Src address in heater not supported Tgt/Src address in heater supported
1)
normal timing parameter set extended timing parameter set
TP0
1)
extented timing parameter set normal timing parameter set
TP1
1) Only TP0, TP1 = 0,1 and 1,0 allowed.
12

---------------------- Page: 16 ----------------------
© ISO
ISO 14230-2:1999(E)
Table 8 — Possible values of Keybytes
Keybytes Supported Time
1)
Binary Hex Dec. Length information Type of header
KB2 KB1
2)
1000 1111 1101 0000 $8FD0 2000
1000 1111 1101 0101 $8FD5 2005 format byte Header
1000 1111 1101 0110 $8FD6 2006 additional length byte without
1000 1111 0101 0111 $8F57 2007 both modes possible address information
1000 1111 1101 1001 $8FD9 2009 format byte Header with Extended
1000 1111 1101 1010 $8FDA 2010 additional length byte target and source timing
1000 1111 0101 1011 $8F5B 2011 both modes possible address information.
1000 1111 0101 1101 $8F5D 2013 format byte both types
1000 1111 0101 1110 $8F5E 2014 additional length byte of header
1000 1111 1101 1111 $8FDF 2015 both mode possible supported
1000 1111 1110 0101 $8FE5 2021 format byte Header
1000 1111 1110 0110 $8FE6 2022 additional length byte without
1000 1111 0110 0111 $8F67 2023 both mode possible address information
1000 1111 1110 1001 $8FE9 2025 format byte Header with normal
1000 1111 1110 1010 $8FEA 2026 additional length byte target and source timing
1000 1111 0110 1011 $8F6B 2027 both modes possible address information
1000 1111 0110 1101 $8F6D 2029 format byte Both types
1000 1111 0110 1110 $8F6E 2030 additional length byte of header
1000 1111 1110 1111 $8FEF 2031 both modes possible supported
7
1)To calculate the decimal value, clear the parity bit of both keybytes and then multiply keybyte 2 by 2 and
add keybyte 1.
2) With value 2 000, the ECU does not give information about which options of the standard are supported.
These options concern use of normal or extended timing, additional length byte, header with or without
address information.
In case of 5 Baud initialization the tester should know what options are implemented. In case of fast
initialization the use of header and lenght byte will be the same as in the StartCommunicationSession
positive response of the ECU.
13

---------------------- Page: 17 ----------------------
© ISO
ISO 14230-2:1999(E)
5.2.4.2 Initialization with 5 Baud address word
5.2.4.2.1 CARB initialization
For CARB purposes 5 Baud initialization is used only. It is a functional initialization.Messages are send to all
emission related ECUs (see ISO 9141-2 and ISO 14230-4).
5.2.4.2.2 Baud initialization
5.2.4.2.2.1 General
The general form of a 5 Baud initialization is shown in figure 10. The 5 Baud address byte is transferred from the
tester on K-line and on L-line. After sending the 5 Baud address byte the tester will maintain L-line on high level.
After receiving the 5 Baud address byte the ECU will transmit the synchronization pattern "$55" and the two key
bytes with the actual communication baud rate. The tester transmits key byte 2 (inverse), then the ECU transmits
the address byte (inverse).
In the case of physical initialization, the ECU shall answer as shown in figure 10.
Using functional information (i.e. more than one ECU is initialized), the vehicle manufacturer shall take care that all
ECUs use the same option of the protocol. Only one ECU shall perform the sequence of initialization (figure 10).
Figure 10 — 5 Baud initialization
Table 9 shows timing values for 5 Baud initialization. These are fixed values. They cannot be changed by the
AccessCommunicationParameter service.
Table 9 — Timing values for 5 Baud initialization
Timing Values
Description
parameters ms
min. max.
W1 60 300 Time from end of the address byte to start of synchronization pattern.
W2 5 20 Time from end of the synchronization pattern to the start of key byte 1.
W3 0 20 Time between key byte 1 and key b
...

NORME ISO
INTERNATIONALE 14230-2
Première édition
1999-03-15
Véhicules routiers — Systèmes de
diagnostic — Protocole «Keyword 2000» —
Partie 2:
Couche de liaison de données
Road vehicles — Diagnostic systems — Keyword Protocol 2000 —
Part 2: Data link layer
A
Numéro de référence
ISO 14230-2:1999(F)

---------------------- Page: 1 ----------------------
ISO 14230-2:1999(F)
Sommaire Page
1 Domaine d’application . 1
2 Références normatives . 2
3 Topologie physique . 2
Structure d’un message .
4 3
4.1 Généralités . 3
4.2 Message d’en-tête . 3
4.3 Octets d’information . 5
4.4 Octet de total de contrôle . 5
4.5 Paramètres de temps . 6
5 Services de communication . 9
5.1 Généralités . 9
5.2 Service strartCommunication . 9
5.3 Service StopCommunication . 17
5.4 Service AccessTimingParameter . 18
5.5 Service SendData . 23
6 Gestion des erreurs . 23
6.1 Service StartCommunication . 23
6.2 Communications de données . 24
Annexe A  Adresses de l’UCE et de l’équipement de diagnostic pour l’initialisation à 5 Bd . 26
Annexe B  Adresses de l’UCE et de l’équipement de diagnostic pour l’initialisation rapide . 27
Annexe C  Bibliographie . 28
©  ISO 1999
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet [e-mail]
Imprimé en Suisse
ii

---------------------- Page: 2 ----------------------
©
ISO ISO 14230-2:1999(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales,
en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 14230-2 a été élaborée par le comité technique ISO/TC 22, Véhicules routiers, sous-
comité SC 3, Équipement électrique et électronique.
L'ISO 14230 comprend les parties suivantes, présentées sous le titre général Véhicules routiers — Systèmes de
diagnostic — Protocole «Keyword 2000»:
 Partie 1: Couche physique
 Partie 2: Couche de liaison de données
 Partie 3: Couche application
 Partie 4: Exigences pour les systèmes relatifs aux émissions
L'annexe A fait partie intégrante de la présente partie de l’ISO 14230. Les annexes B et C sont données
uniquement à titre d'information.
iii

---------------------- Page: 3 ----------------------
©
ISO 14230-2:1999(F) ISO
Introduction
L’ISO 14230 a été élaborée afin de définir les exigences communes aux systèmes de diagnostic mis en œuvre sur
une liaison de données série.
Pour ce faire, elle est fondée sur le modèle de référence de base de l'interconnexion de systèmes ouverts (OSI)
conforme à l'ISO 7498, qui structure les systèmes de communication en sept couches. Lorsqu'ils sont appliqués
selon ce modèle, les services utilisés par un équipement de diagnostic et une unité de contrôle électronique (UCE)
se divisent en:
 services de diagnostic (couche 7);
 services de communication (couches 1 à 6).
Voir la figure 1.
Application
Données de diagnostic
Demande Réponse
de service Confirmation de service Indication
de service de service
Définition du service
Couche
Services de diagnostic
d'application
Liaison de Liaison de Liaison de Liaison de
Mise en œuvre
données .
(couche 7) données données données
(ISO 14230-3)
série 1 série 2 série 3 série n
Couche de présentation (couche 6)
Les couches 6 à 3
Couche de session (couche 5)
ne sont pas définies
Couche de transport  (couche 4)
dans l'ISO 14230
Couche de réseau (couche 3)
Couche de
Communication
liaison de données
(ISO 14230-2)
(couche 2)
Couche physique
Couche physique
(couche 1)
(ISO 14230-1)
Exemple de liaisons de données série: KWP 2000, VAN, CAN, J1850, etc.
Figure 1 — Application des services de diagnostic selon le modèle OSI
iv

---------------------- Page: 4 ----------------------
NORME INTERNATIONALE  © ISO ISO 14230-2:1999(F)
Véhicules routiers — Systèmes de diagnostic — Protocole
«Keyword 2000» —
Partie 2:
Couche de liaison de données
1 Domaine d'application
La présente partie de l’ISO 14230 fixe les exigences communes des services de diagnostic qui permettent à un
équipement de diagnostic de contrôler les fonctions de diagnostic dans une unité de contrôle électronique
embarquée (par exemple injection électronique de carburant, boîte de vitesses automatique, système de freinage
antiblocage, etc.) connectée à une liaison de données série intégrée à un véhicule.
Elle ne prescrit que la couche 2 (couche de liaison de données). Elle contient toutes les définitions nécessaires
pour mettre en œuvre les services (décrits dans l'ISO 14230-3) sur une liaison série (décrite dans l'ISO 14230-1).
Elle mentionne également certains services de communication nécessaires à la gestion de la communication et/ou
des sessions, ainsi qu'une description de la gestion des erreurs.
Elle ne prescrit pas les exigences de mise en œuvre des services de diagnostic.
La couche physique peut servir de bus multi-utilisateur; une espèce d'arbitrage ou une gestion de bus est donc
nécessaire. Il existe plusieurs propositions, qui ne font pas partie de la présente partie de l’ISO 14230. Les
constructeurs d’automobiles sont responsables du bon fonctionnement de la gestion du bus.
La présente partie de l’ISO 14230 ne traite pas la communication entre les UCE.
L'environnement du véhicule auquel la présente partie de l’ISO 14230 s'applique comprend (voir la figure 2):
 un équipement de diagnostic unique pouvant être connecté, de manière temporaire ou permanente, à la liaison
de données de diagnostic embarquée et,
 plusieurs unités de contrôle électronique embarquées connectées directement ou indirectement.
Dans le domaine Dans le domaine
d'application de la d'application de la
Véhicule 1
Véhicule 2
présente partie de présente partie de
l'ISO 14230 l'ISO 14230
UCE
UCE
UCE
UCE
Outil de
Outil de
diagnostic
diagnostic
UCE
UCE
Passerelle
UCE
UCE
Peut être compris
dans le domaine
d'application de la
présente partie de
l'ISO 14230
Figure 2 — Architecture de diagnostic d'un véhicule
1

---------------------- Page: 5 ----------------------
© ISO
ISO 14230-2:1999(F)
2 Références normatives
Les normes suivantes contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des
dispositions valables pour la présente partie de l’ISO 14230. Au moment de la publication, les éditions indiquées
étaient en vigueur. Toute norme est sujette à révision, et les parties prenantes des accords fondés sur la présente
partie de l’ISO 14230 sont invitées à rechercher la possibilité d'appliquer les éditions les plus récentes des normes
indiquées ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur
à un moment donné.
ISO 9141:1989, Véhicules routiers — Systèmes de diagnostic — Caractéristiques de l'échange de données
numériques.
ISO 9141-2:1994, Véhicules routiers — Systèmes de diagnostic — Partie 2: Caractéristiques CARB de l'échange
de données numériques.
ISO 14230-3:1999, Véhicules routiers — Systèmes de diagnostic — Protocole «Keyword 2000» — Partie 3:
Couche application.
ISO 14230-4:1999, Véhicules routiers — Systèmes de diagnostic — Protocole «Keyword 2000» — Partie 4:
Exigences pour les systèmes relatifs aux émissions.
SAE J 1979:1996, E/E diagnostic test modes [Modes d'essais de diagnostic électriques et électroniques].
3 Topologie physique
Le protocole «Keyword 2000» est une conception en bus. La figure 3 représente la forme générale de cette liaison
série.
Équipement de
UCE 1 UCE 2 UCE n
diagnostic
Ligne K
Ligne L (facultative)
Figure 3 — Topologie
La ligne K est utilisée pour la communication et l'initialisation, la ligne L (facultative) pour l'initialisation uniquement.
Des cas particuliers sont des connexions nœud à nœud, ce qui signifie qu'il n'y a qu'une UCE sur la ligne qui peut
également être un convertisseur de bus.
2

---------------------- Page: 6 ----------------------
© ISO
ISO 14230-2:1999(F)
4 Structure d'un message
4.1 Généralités
Un message se compose de trois parties:
 le message d'en-tête;
 les octets d'information;
 le total de contrôle.
Voir la figure 4.
Les octets de message d'en-tête et de total de contrôle sont décrits dans la présente partie de l’ISO 14230. La zone
des octets d'information commence toujours par un identificateur du service.
Les octets d'information et leur utilisation sont décrits dans l'ISO 14230-3 et dans la présente partie de l’ISO 14230.
Message d'en-tête Octets d'information Total de
contrôle
1) 1) 1) 2) 2)
Tgt Src Len SId Données
Fmt . . CS
4 octets max. 255 octets max. 1 octet
1)  Octets optionnels, en fonction de l'octet de format.
2)  Identificateur du service, partie des octets d'information.
NOTE —  Les zones grisées (en-tête, total de contrôle) sont décrites dans la présente partie de l’ISO 14230.
Figure 4 — Structure d'un message
4.2 Message d'en-tête
Le message d'en-tête se compose d’au plus 4 octets. Un octet de format contient des informations sur la forme des
messages, les octets d'adresse cible et source étant facultatifs en cas d'utilisation de connexions multinœuds et un
octet de longueur séparé facultatif autorisant des messages d’au plus 255 octets.
4.2.1 Octet de format
L'octet de format contient des informations de 6 bits de longueur et des informations de 2 bits en mode adresse.
Les octets-clés informent l'équipement de diagnostic de l'utilisation d'octets de message d'en-tête (voir 4.2.2).
L’octet de format à la structure suivante:
A1 A0 L5 L4 L3 L2 L1 L0
où
A1 et A0 définissent la forme de l'en-tête que le message utilisera, conformément au tableau 1;
L5, ., L0 définissent la longueur d'un message depuis le début des champs de données (y compris l'octet
serviceIdentification) jusqu'à l'octet de total de contrôle (exclu). Un message d'une longueur de
1 octet à 63 octets est possible. Si les valeurs de L0 à L5 sont égales à 0, un octet de longueur
supplémentaire est inclus (voir 4.2.5).
3

---------------------- Page: 7 ----------------------
© ISO
ISO 14230-2:1999(F)
Tableau 1 — Forme du message d’en-tête
A1 A0 Mode
0 0 Aucune information d'adresse
0 1 Mode d'exception (CARB)
1 0 Avec information d'adresse, adressage physique
1 1 Avec information d'adresse, adressage fonctionnel
A1,A0 = 01 (mode CARB) est un mode d'exception. Le mode CARB n'est pas prescrit dans la présente partie de
l’ISO 14230. Le CARB utilise des octets de format $68 (0110 1000) et $48 (0100 1000). Pour de plus amples
détails, se reporter à l’ISO 9141-2 et à la SAE J 1979.
4.2.2 Octet d'adresse cible
Il s'agit de l'adresse cible du message qui est toujours associée à l'octet d'adresse source. L'adresse cible dans les
messages de demande adressés à l'UCE peut être une adresse physique ou fonctionnelle. L'adresse cible dans les
messages de réponse adressés à l'outil de diagnostic doit être l'adresse physique de l'outil de diagnostic. Les
adresses physiques peuvent être l'octet d'adresse à 5 Bd (voir annexe A) ou des adresses conformes à la
SAE J 2178-1 (voir annexe B). Cet octet facultatif n'est nécessaire que sur les topologies de bus multinœud. Il est
inutile pour les connexions nœud à nœud. Pour les messages CARB, cet octet est défini dans l'ISO 9141-2 ou dans
l'ISO 14230-4.
4.2.3 Octet d'adresse source
Il s'agit de l'adresse du dispositif émetteur qui doit être une adresse physique. Les possibilités de valeurs sont les
mêmes que celles décrites pour les octets d'adresse cible physique. La liste des adresses pour les outils de
diagnostic figure dans la SAE J 2178-1 (voir annexe B). Cet octet facultatif (toujours associé à un octet d'adresse
cible) n'est nécessaire que sur les topologies de bus multinœud. Il est inutile pour les connexions nœud à nœud.
4.2.4 Octet de longueur
Cet octet est prévu si la longueur dans l'octet de message d'en-tête (L0 à L5) est fixée à 0, conformément aux
indications du tableau 2. Il permet à l'utilisateur de transmettre des messages avec des champs de données de plus
63 octets. Il est inutile avec des messages plus courts. Cet octet définit la longueur d'un message depuis le début
du champ de données (y compris l'octet d'identification de service) jusqu'à l'octet de total de contrôle (exclu). Les
données peuvent avoir une longueur de 1 octet à 255 octets. Le message le plus long se compose d'un maximum
de 260 octets. Pour les messages ayant des champs de données de moins de 64 octets, la longueur peut être
comprise dans l'octet de format ou dans l'octet de longueur supplémentaire. Il est inutile qu'une UCE ait les deux
possibilités; l'équipement de diagnostic est informé de la capacité d'une UCE par l'intermédiaire des octets-clés
(voir 6.1.4.1).
Tableau 2 — Présence de l’octet de longueur
Longueur fournie en
Longueur des
champs de
1)
octet de longueur
octet Fmt
données
< 64 octets XX00 0000 présent
< 64 octets XXLL LLLL absent
≥ 64 octets XX00 0000 présent
1)
XX: information de 2 bits en mode adresse (voir 4.2.1)
LL LLLL: information d'une longueur de 6 bits
4

---------------------- Page: 8 ----------------------
© ISO
ISO 14230-2:1999(F)
4.2.5 Utilisation des octets de message d'en-tête
Il existe quatre formes différentes de message d’en-tête avec les définitions ci-dessus. Elles sont représentées
graphiquement à la figure 5.
Longueur
Fmt SId Données CS
Total de contrôle
a)  Message d'en-tête sans information d'adresse, pas d'octet de longueur supplémentaire
Longueur
Fmt Tgt Src SId Données CS
Total de contrôle
b)  Message d'en-tête avec information d'adresse, pas d'octet de longueur supplémentaire
Longueur
Fmt Len SId Données CS
Total de contrôle
c)  Message d'en-tête sans information d'adresse ni octet de longueur supplémentaire
Longueur
Fmt Tgt Src Len SId Données CS
Total de contrôle
d)  Message d'en-tête avec information d'adresse et octet de longueur supplémentaire
Légende
Fmt Octet de format SId Octet d'identification de service
Tgt Adresse cible (optionnelle) Données (fonction du service)
Src Adresse source (optionnelle) CS Octet de total de contrôle
Len Octet de longueur supplémentaire
(optionnel)
NOTE — Les zones non ombrées sont définies dans l'ISO 14230-3.
Figure 5 — Messages d’en-tête
4.3 Octets d'information
Le champ de données peut contenir jusqu'à 63 octets ou 255 octets d'information, en fonction de l'utilisation de
l'information de longueur. Le premier octet du champ de données est l'octet d’identification de service. Il peut être
suivi de paramètres et de données dépendant du service sélectionné. Ces octets sont définis dans l'ISO 14230-3
(pour les services de diagnostic) et à l’article 5 (pour les services de communication).
4.4 Octet de total de contrôle
L'octet de total de contrôle (CS), inséré à la fin du bloc message, est défini comme la somme simple des huit
valeurs binaires de tous les octets du message, total de contrôle exclu.
Si le message est
〈1〉 〈2〉 〈3〉 . 〈N〉, 〈CS〉
5

---------------------- Page: 9 ----------------------
© ISO
ISO 14230-2:1999(F)
on peut avoir les deux cas de figure suivants:
ème
 lorsque 〈i〉 (1 ≤ i ≤ N) est la valeur numérique du i octet du message:
〈CS〉 = 〈CS〉
N
 lorsque 〈CS〉 (2 ≤ i ≤ N):
i
〈CS〉 = {〈CS〉 + 〈i〉}mod256, et
i i – 1
〈CS〉 = 〈1〉
1
Une protection supplémentaire, définie par le constructeur, peut être prévue dans le champ de données.
4.5 Paramètres de temps
4.5.1 Mise en œuvre
Les paramètres de temps conformes à la figure 6 s'appliquent lors du fonctionnement normal.
Demande de Demande de
l'équipement Réponse Réponse l'équipement
de diagnostic de l'UCE 1 de l'UCE 2 de diagnostic
. . . . . . . . .
. . .
P2
P1 P2
P4 P2
P3
Légende
P1 Temps écoulé entre les octets pour la réponse de l'UCE
P2 Temps écoulé entre la demande de l'équipement de diagnostic et la
réponse de l'UCE ou entre deux réponses de l'UCE
P3 Temps écoulé entre la fin des réponses de l'UCE et le début d'une nouvelle
demande de l'équipement de diagnostic
P4 Temps écoulé entre les octets pour la demande de l'équipement de
diagnostic
Figure 6 — Paramètres de temps
Il existe deux ensembles de paramètres de temps par défaut:
a) un ensemble pour la communication normale à adressage fonctionnel ou physique pour lequel des temps plus
longs sont nécessaires pour permettre toutes les techniques de gestion de bus;
b) un ensemble limité à l'adressage physique pour permettre une communication plus rapide.
L'équipement de diagnostic est informé de la capacité d'une UCE par l'intermédiaire des octets-clés (voir 5.2.4.1).
Les paramètres de temps peuvent varier avec le service de communication AccessTimingParameters (voir 5.4).
Les utilisateurs doivent tenir compte des limites et des restrictions suivantes:
P3 > P4
min min
Pi < Pi pour i = 1, ., 4
min max
6

---------------------- Page: 10 ----------------------
© ISO
ISO 14230-2:1999(F)
Il peut y avoir d'autres restrictions si l'équipement de diagnostic et les UCE à l'écoute détectent la fin d'un message
par temporisation. Dans ce cas, les restrictions suivantes s'appliquent:
P2 > P4
min max
P2 > P1
min max
En cas d'adressage fonctionnel, c’est-à-dire qu'il peut y avoir plus d'une réponse à une demande, quelques
restrictions peuvent s'ajouter.
Il incombe aux concepteurs d'assurer une communication correcte en cas de changement des paramètres de
temps par rapport aux valeurs par défaut. Ils doivent également s'assurer que les paramètres de communication
choisis sont possibles pour toutes les UCE intervenant dans une session.
Les valeurs possibles dépendent des capacités de l'UCE. Dans certains cas, l'UCE peut devoir abandonner son
mode de fonctionnement normal pour passer à une session ayant des paramètres de communication différents.
Les tableaux 3 et 4 présentent les paramètres de temps utilisés par défaut, les limites dans lesquelles ils peuvent
être modifiés et la résolution qui peut être utilisée pour fixer une nouvelle valeur (avec le service de communication
AccessTimingParameters — voir 5.4).
Tableau 3 — Ensemble normal de paramètres de temps (pour l'adressage fonctionnel ou physique)
Valeurs en millisecondes
Valeurs minimales Valeurs maximales
Paramètre
de temps
Limite la plus Valeur par Valeur par Limite la plus
Résolution Résolution
basse défaut défaut haute
P1 0 0 — 20 20 —
P2 0 25 0,5 50 Voir tableau 5
P3 0 55 0,5 5 000 ∞ ($FF) 250
P4 0 5 0,5 20 20 —
Tableau 4 — Ensemble étendu de paramètres de temps (pour l'adressage physique uniquement)
Valeurs en millisecondes
Valeurs minimales Valeurs maximales
Paramètre
de temps
Limite la plus Valeur par Valeur par Limite la plus
Résolution Résolution
basse défaut défaut haute
P1 0 0 — 20 20 —
P2 0 0 0,5 1 000 Voir tableau 5
P3 0 0 0,5 5 000 ∞ ($FF) 250
P4 0 5 0,5 20 20 —
7

---------------------- Page: 11 ----------------------
© ISO
ISO 14230-2:1999(F)
Tableau 5 — Calcul du paramètre de temps P2
max
Valeur Valeur
Résolution Calcul de la valeur maximale
hexadécimale maximale
ms ms
01 à F0 25 25 à 6 000 (valeur hexadécimale) x (résolution)
F1 Voir la 6 400 (quartet de poids faible de valeur hexadécimale) x
méthode de 256 x 25
F2 12 800
calcul de la
Exemple de $FA: ($0A x $0100) x 25 = 64 000
F3 19 200
valeur
maximale
F4 25 600
F5 32 000
F6 38 400
F7 44 800
F8 51 200
F9 57 600
FA 64 000
FB 70 400
FC 76 800
FD 83 200
FE 83 600
FF — ∞ Non applicable
La valeur du paramètre de temps P2 doit toujours être une valeur d'octet unique dans le
max
service AccessTimingParameter. Les modifications de temps doivent être activées par la
mise en œuvre du service AccessTimingParameter.
Méthode proposée de calcul de la valeur du paramètre de temps P2 (valeur > 6 000 ms):
max
Le calcul du paramètre de temps P2 utilise une résolution de 25 ms dans la gamme $01 à $F0. À partir de $F1,
max
le serveur et le client doivent utiliser une autre méthode de calcul, de manière à obtenir des valeurs de paramètre
de temps supérieures à 6 000 ms.
Formules de calcul des valeurs de P2 > $F0
max
calcul_de_P2 = (quartet de poids faible de P2 ) × 256 × 25 (ms)
max max
La valeur du paramètre de temps P2 doit toujours être une valeur unique d'octet dans le service
max
AccessTimingParameter. Les modifications de temps doivent être activées par la mise en œuvre du service
AccessTimingParameter.
4.5.2 Exceptions de temps
La fenêtre de temps étendue P2 est une possibilité pour un (des) serveur(s) d'étendre le délai de réponse à un
message de demande. Une exception de temps P2 n'est autorisée qu'avec l'emploi d'un ou plusieurs
max
message(s) de réponse négative avec le code de réponse $78 (RequestCorrectlyReceived-ResponsePending)
émis par le ou les serveur(s). Ce code de réponse ne doit être utilisé par un serveur que s'il ne peut pas envoyer un
message de réponse positive ou négative sur la base du message de demande du client dans le délai de la fenêtre
de temps active P2. Ce code de réponse doit manipuler la valeur du paramètre de temps P2 dans le serveur et
max
le client. Le paramètre de temps P2 est fixé à la valeur (en millisecondes) du paramètre de temps P3 . Le
max max
client doit rester sur le mode réception. Le (les) serveur(s) doit (doivent) envoyer des messages de réponse
négative multiples avec le code de réponse négative $78, si c'est nécessaire.
Dès que le serveur a exécuté la tâche (routine) déclenchée par le message de demande, il doit envoyer soit un
message de réponse positive, soit un message de réponse négative (le message de réponse négative avec un
code de réponse autre que $78) sur la base du dernier message de demande reçu. Lorsque le client a reçu le
message de réponse qui a été précédé par un (des) message(s) de réponse négative avec le code de réponse $78,
8

---------------------- Page: 12 ----------------------
© ISO
ISO 14230-2:1999(F)
le client et le serveur doivent remettre le paramètre de temps P2 à la valeur de temps antérieure. Le client ne
max
doit pas répéter le message de demande après réception d'un message de réponse négative avec le code de
réponse $78.
5 Services de communication
5.1 Généralités
Certains services sont nécessaires pour établir et maintenir la communication. Il ne s'agit pas de services de
diagnostic car ils n'apparaissent pas sur la couche d'application. Ils sont décrits sous la même forme et avec les
mêmes conventions (CVT) que les services de diagnostic (voir ISO 14229): tableau du service et description de la
procédure du service. La présence des paramètres est indiquée comme suit:
 obligatoire: M,
 à sélection obligatoire: S,
 conditionnel: C,
 sur demande de l'utilisateur: U.
Une description de la mise en œuvre sur la couche physique du protocole «Keyword 2000» est ajoutée.
En général, les services ne sont pas obligatoires, seul le service StartCommunication doit être mis en œuvre.
Les services StartCommunication et AccessTimingParameter sont utilisés pour démarrer une communication de
diagnostic. Pour assurer tout service de diagnostic, la communication doit être initialisée et il est nécessaire que les
paramètres de communication conviennent au mode de diagnostic souhaité. La figure 7 présente un graphique le
décrivant.
5.2 Service StartCommunication
5.2.1 Objectif du service
L'objectif de ce service de la couche communication KWP 2000 est d'initialiser la liaison de communication pour
l'échange des données de diagnostic.
5.2.2 Tableau du service
Voir le tableau 6.
Tableau 6 — Service StartCommunication
Demande StartCommunication M
1)
M
Identificateur du mode d'initialisation
Adresse d'initialisation cible M
2)
Adresse d'initialisation source
C1
Réponse positive StartCommunication M
3)
Adresse cible
C2
3)
Adresse source
C2
Octets-clés
M2
Octets-clés M2
1) L'identificateur de mode d'initialisation détermine la manière d'initialiser. La valeur de
ce paramètre peut correspondre à une initialisation CARB, une initialisation à 5 Bd ou une
initialisation rapide.
2) C1: L'adresse d'initialisation source est ajoutée si l’identificateur du mode
d'initialisation correspond à l’initialisation rapide.
3) C2: L'adresse cible et l'adresse source sont ajoutées si l'information d'adresse est
utilisée dans le message d'en-tête (en-tête à trois ou quatre octets).
9

---------------------- Page: 13 ----------------------
© ISO
ISO 14230-2:1999(F)
1) Service de communication
2) Service de diagnostic
Figure 7 — Utilisation des services de communication
5.2.3 Procédure du service
À la réception d'une primitive d'indication StartCommunication, l'UCE doit vérifier si la liaison de communication
demandée peut être initialisée dans les conditions actuelles. Le paragraphe 5.3.2 décrit les bonnes conditions pour
l'initialisation d'une liaison de communication de diagnostic.
L'UCE doit ensuite effectuer toutes les opérations nécessaires pour initialiser la liaison de communication et émettre
une primitive de réponse StartCommunication avec les paramètres de réponse positive sélectionnés.
Si la liaison de communication ne peut être initialisée pour une raison quelconque, l'UCE doit continuer à
fonctionner normalement (voir 6.1).
10

---------------------- Page: 14 ----------------------
© ISO
ISO 14230-2:1999(F)
5.2.4 Mise en œuvre
Le service StartCommunication est utilisé pour initialiser une communication sur la ligne K. Il existe différentes
possibilités d'initialisation:
a) initialisation CARB;
b) initialisation à 5 Bd;
c) initialisation rapide.
La figure 8 présente les trois possibilités et l'état des UCE après chaque type d'initialisation. À l'issue de
l'initialisation, les UCE sont dans le même état, indépendamment du mode d'initialisation:
tous les paramètres de communication reçoivent des valeurs par défaut selon les octets-clés;

 l'UCE attend la première demande de l'équipement de diagnostic pendant un laps de temps P3;
 l'UCE est en mode de diagnostic par défaut (c’est-à-dire a une fonctionnalité bien définie).
Figure 8 — Modes d'initialisation
11

---------------------- Page: 15 ----------------------
© ISO
ISO 14230-2:1999(F)
Les éléments généraux suivants doivent être communs à tous les modes d'initialisation:
 il doit y avoir un état de repos du bus avant toute activité;
 l'équipement de diagnostic émet ensuite un motif d'initialisation;
 toutes les informations nécessaires à l'établissement de la communication sont contenues dans la réponse de
l'UCE.
5.2.4.1 Octets-clés
Ces octets permettent à une UCE de communiquer à l'équipement de diagnostic les informations de message d'en-
tête, de temps et de longueur prises en charge. Une UCE n'a donc pas obligatoirement à prendre en charge toutes
les possibilités.
Le décodage des octets-clés est défini dans l'ISO 9141.
Une représentation graphique des octets-clés est donnée à la figure 9 et la signification des valeurs de cha
...