ISO 14230-3:1999
(Main)Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 3: Application layer
Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 3: Application layer
This part of ISO 14230 specifies the requirements for the Keyword Protocol 2000 data link on which one or several on-vehicle Electronic Control Units are connected to an off-board tester in order to perform diagnostic functions. This part of ISO 14230 specifies the requirements of the implementation of the Diagnostic Services specified in ISO 14229, including - byte-encoding and hexadecimal values for the service identifiers; - byte-encoding for the parameters of the diagnostic service requests and responses; - hexadecimal values for the standard parameters. The vehicle environment to which this part of ISO 14230 applies may consist of a single tester that may be temporarily connected to the on-vehicle diagnostic data link and several on-vehicle Electronic Control Units connected directly or indirectly.
Véhicules routiers — Systèmes de diagnostic — Protocole "Keyword 2000" — Partie 3: Couche application
La présente partie de l’ISO 14230 fixe les exigences relatives à la liaison de données du protocole «Keyword 2000» sur laquelle une ou plusieurs unités de contrôle électronique embarquées sont connectées à un équipement non embarqué afin d'effectuer des fonctions de diagnostic. Elle fixe les prescriptions de mise en oeuvre des services de diagnostic spécifiés dans l'ISO 14229, y compris: - le codage en octets et les valeurs hexadécimales pour les identificateurs du service; - le codage en octets pour les paramètres des demandes et réponses du service de diagnostic; - les valeurs hexadécimales pour les paramètres normalisés. L'environnement du véhicule auquel la présente partie de l’ISO 14230 s'applique comprend 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.
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14230-3
First edition
1999-03-15
Road vehicles — Diagnostic systems —
Keyword Protocol 2000 —
Part 3:
Application layer
Véhicules routiers — Systèmes de diagnostic —
Protocole «Keyword 2000» —
Partie 3: Couche application
A
Reference number
Contents
1 Scope .1
2 Normative references .1
3 Definitions .2
4 Conventions .2
4.1 General.2
4.2 Service description convention .3
4.3 Functional unit table.6
4.4 Service Identifier value summary table .6
4.5 Response Code value summary table .6
4.6 Response handling.8
5 General implementation rules .9
5.1 Parameter definitions .9
5.2 Functional and physical addressed service requests .10
5.3 Message flow examples of physical/functional addressed services.10
6 Diagnostic Management functional unit.16
6.1 StartDiagnosticSession service .16
6.2 StopDiagnosticSession service .17
6.3 SecurityAccess service.19
6.4 TesterPresent service.22
6.5 ECUReset service .23
6.6 ReadECUIdentification service.25
7 Data Transmission functional unit.26
7.1 ReadDataByLocalIdentifier service.27
© 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 iso@iso.ch
Printed in Switzerland
ii
© ISO
7.2 ReadDataByCommonIdentifier service . 29
7.3 ReadMemoryByAddress service. 31
7.4 DynamicallyDefineLocalIdentifier service. 32
7.5 WriteDataByLocalIdentifier service . 37
7.6 WriteDataByCommonIdentifier service . 38
7.7 WriteMemoryByAddress service. 39
7.8 SetDataRates service . 41
8 Stored Data Transmission functional unit . 42
8.1 ReadDiagnosticTroubleCodes service. 42
8.2 ReadDiagnosticTroubleCodesByStatus service . 44
8.3 ReadStatusOfDiagnosticTroubleCodes service. 45
8.4 ReadFreezeFrameData service. 46
8.5 ClearDiagnosticInformation service . 51
9 InputOutput Control functional unit . 52
9.1 InputOutputControlByLocalIdentifier service. 52
9.2 InputOutputControlByCommonIdentifier service . 53
10 Remote Activation Of Routine functional unit. 55
10.1 StartRoutineByLocalIdentifier service. 55
10.2 StartRoutineByAddress service. 56
10.3 StopRoutineByLocalIdentifier service. 57
10.4 StopRoutineByAddress service. 59
10.5 RequestRoutineResultsByLocalIdentifier service . 60
10.6 RequestRoutineResultsByAddress service. 62
11 Upload Download functional unit . 63
11.1 RequestDownload service. 63
11.2 RequestUpload service. 65
11.3 TransferData service . 66
11.4 RequestTransferExit service . 68
12 Keyword Protocol 2000 extended service. 70
12.1 EscapeCode service. 70
iii
© ISO
13 Application examples.71
13.1 Description of on-vehicle ECUs .71
13.2 Functional initialization and functional addressed communication .73
13.3 Single and multiple response and termination of communication.73
13.4 SecurityAccess, data transfer and modification of timing parameters.74
13.5 ReadDataByLocalIdentifier service with dynamicallyDefineLocalIdentifier .77
Annex A (informative) Bibliography .81
iv
© ISO
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-1 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 of this part of ISO 14230 is for information only.
v
© ISO
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 Systems 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).
See figure 1.
Application
Diagnostic Data
Service request Service response
Service.conf. Service.ind. Diagnostic Services
Specification
Application
Diagnostic Services
Layer
Implementation
(Layer #7) KEYWORD PROTOCOL 2000
(Part 3)
Presentation Layer (Layer #6) Layer #6 to #3
Session Layer (Layer #5) are not defined
Transport Layer (Layer #4) within this
Network Layer (Layer #3) document
Data Link Layer Data Link Layer
(Layer #2) (Part 2)
KEYWORD PROTOCOL 2000
Physical Layer Physical Layer
(Layer #1) (Part 1)
Example of serial data links: KWP2000, VAN, CAN, J1850, etc.
Figure 1 — Mapping of Diagnostic Services and Keyword Protocol 2000 on OSI Model
vi
INTERNATIONAL STANDARD © ISO ISO 14230-3:1999(E)
Road vehicles — Diagnostic systems — Keyword Protocol 2000 —
Part 3:
Application layer
1 Scope
This part of ISO 14230 specifies the requirements for the Keyword Protocol 2000 data link on which one or several
on-vehicle Electronic Control Units are connected to an off-board tester in order to perform diagnostic functions.
This part of ISO 14230 specifies the requirements of the implementation of the Diagnostic Services specified in
ISO 14229, including
byte-encoding and hexadecimal values for the service identifiers;
byte-encoding for the parameters of the diagnostic service requests and responses;
hexadecimal values for the standard parameters.
The vehicle environment to which this part of ISO 14230 applies may consist of a single tester that may be
temporarily connected to the on-vehicle diagnostic data link and several on-vehicle Electronic Control Units
connected directly or indirectly (see figure 2).
Vehicle 1 within the scope
Vehicle 2
within the scope
of the proposal
of the proposal
ECU
ECU
ECU
ECU
Tester
Tester
ECU
ECU
Gateway
may or may not be
ECU
ECU
within the scope
of the proposal
In vehicle 1, the ECUs are connected by an internal data link and indirectly connected to the
diagnostic data link through a gateway. This standard applies to the diagnostic communications
over the diagnostic data link; the diagnostic communications over the internal data link may conform
to this standard or to another protocol.
In vehicle 2, the ECUs are directly connected to the diagnostic data link.
Figure 2 — Vehicle diagnostic architecture
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
document. All standards are subject to revision, and parties to agreement based on this document are encouraged
© ISO
to investigate the possibility of applying the most recent editions of the standards listed below. Members of ISO
maintain registers of currently valid International Standards.
1)
ISO 14229:— , Road vehicles — Diagnostic systems — Diagnostic services specification.
1)
ISO 14230-2:— , Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 2 : Data link layer.
SAE J 1930: 1995, Electrical/electronic systems diagnostic — Terms, definitions, abbreviations and acronyms.
SAE J 1979: 1997, E/E diagnostic test modes— Terms, definitions, abbreviations and acronyms.
3 Definitions
For the purposes of this part of ISO 14230, the definitions given in ISO 14229 and SAE J 1930 apply.
4 Conventions
4.1 General
4.1.1 This part of ISO 14230 is guided by the OSI service conventions (CVT; see ISO 8509) to the extent that they
are applicable to the diagnostic services. These conventions define the interactions between the service use and
the service provider by the supplier through service primitives which themselves may convey parameters.
4.1.2 Table 1 indicates the different ranges of service identifier values, which are defined in SAE J 1979, ISO
14230 or by the vehicle manufacturer.
Table 1 — Service Identifier value convention table
1)
Service Identifier Where defined
Service type
Hex Value
(bit 6)
00 - 0F Request SAE J 1979
10 - 1F
20 - 2F Request (bit 6 = 0) ISO 14230-3
30 - 3E
3F Not applicable reserved
40 - 4F Response SAE J1979
50 - 5F Positive Response
60 - 6F to Services ($10 - $3E)
70 - 7E (bit 6 = 1) ISO 14230-3
7F Negative Response
80 Request 'ESC' - Code
81 - 8F Request (bit 6 = 0) ISO 14230-2
90 - 9F Request (bit 6 = 0) reserved for future exp. as needed
A0 - BF Request (bit 6 = 0) defined by vehicle manufacturer
C0 Positive Resp. 'ESC' - Code ISO 14230-3
C1 - CF Positive Response (bit 6 = 1) ISO 14230-2
D0 - DF Positive Response (bit 6 = 1) reserved for future exp. as needed
E0 - FF Positive Response (bit 6 = 1) defined by vehicle manufacturer
1) There is a one-to-one correspondence between request messages and positive response messages, with
"bit 6" of the service identifier hex value indicating the service type.
1)
To be published.
© ISO
4.1.3 The table content consists of the following:
under the Request Message are listed the parameters specific to the service
request/indication;
under the Positive Response Message are listed the parameters specific to the service
response/confirmation in case the requested service was successful;
under the Negative Response Message are listed the parameters specific to the service
response/confirmation in case the requested service has failed or could not be completed in time.
4.1.4 For a given primitive, the presence of each parameter is described by one of the following values:
M: mandatory;
U: user option; the parameter may or may not be supplied, depending on dynamic usage by the user;
C: conditional; the presence of the parameter depends upon other parameters within the service;
S: mandatory (unless specified otherwise) selection of a parameter from a parameter list.
4.2 Service description convention
This clause defines the layout used to describe the diagnostic services. It includes
Parameter Definition;
Message Data Bytes;
Message Description;
Message Flow Example.
4.2.1 Parameter definition
This section defines the use and the values of parameters used by the service.
4.2.2 Message data bytes
The definition of each message includes a table which lists the parameters of its primitives: request/indication
("Req/Ind"), response/confirmation ("Rsp/Cnf") for positive or negative result. All have the same structure. Table 2
describes the request message, table 3 the positive response message and table 4 the negative response
message.
A positive response message shall be given by the server if it can carry out all the operations requested. It shall
otherwise give a negative response.
The response messages are listed in separate tables because the list of parameters differs between positive and
negative response messages.
© ISO
Table 2 — Request message
1)
Type Parameter Name Hex Value Mnemonic
CVT
Header Format Byte M xx FMT
2) 3)
Target Byte xx TGT
Bytes C
3)
Source Byte xx SRC
C
Length Byte xx LEN
4)
C
Request Service Identifier M xx SN
5)
= [ xx=[ PN
C
Type> xx
: : :
xx
Type> ] ]
2)
Checksum Byte M xx CS
CS
1) See 4.1.4
2) Defined in ISO 14230-2.
3) The header bytes "Target" and "Source" depend on the content of the "Format Byte" which is specified in ISO 14230-
2 (KWP 2000 Part 2: Data Link Layer) document. Both either exist or do not exist in the header of each message.
4): The header byte "Length" depends on the content of the "Format Byte" which is specified in ISO DIS 14230-2.
5): These parameters may be either mandatory (M) or user optional (U), depending on the individual message.
Table 3 — Positive response message
1)
Type Parameter Name Hex Value Mnemonic
CVT
Header Format Byte M xx FMT
2) 3)
Target Byte xx TGT
Bytes C
3)
Source Byte xx SRC
C
Length Byte xx LEN
4)
C
Positive Response Service Identifier M xx SNPR
= [ xx=[ PN
C
Type> xx
: : :
xx
Type> ] ]
2)
Checksum Byte M xx CS
CS
1) See 4.1.4
2) Defined in ISO 14230-2.
3) The header bytes "Target" and "Source" depend on the content of the "Format Byte" which is specified in ISO 14230-
2 (KWP 2000 Part 2: Data Link Layer) document. Both either exist or do not exist in the header of each message.
4): The header byte "Length" depends on the content of the "Format Byte" which is specified in ISO DIS 14230-2.
5): These parameters may be either mandatory (M) or user optional (U), depending on the individual message.
© ISO
Table 4 — Negative response message
1)
Type Parameter Name Hex Value Mnemonic
CVT
Header Format Byte M xx FMT
2) 3)
TGT
Target Byte xx
Bytes C
3)
Source Byte xx SRC
C )
Length Byte 4) xx LEN
C
NegativeResponse Service Identifier M xx NACK
Request Service Identifier M xx SN
Type> KWP2000ResponseCode, 00-7F,
ManufacturerSpecific 80-FF
] ]
2)
Checksum Byte M xx CS
CS
1) See 4.1.4
2) Defined in ISO 14230-2.
3) The header bytes "Target" and "Source" depend on the content of the "Format Byte" which is specified in ISO 14230-
2 (KWP 2000 Part 2: Data Link Layer) document. Both either exist or do not exist in the header of each message.
4): The header byte "Length" depends on the content of the "Format Byte" which is specified in ISO DIS 14230-2.
4.2.3 Message description
This section"Message description" provides a description of the actions performed by the client and the server which
are specific to the KWP 2000 Protocol (see ISO 14230-2).
The response condition is service specific and defined separately for each service.
4.2.4 Message flow examples
This section provides message flow descriptions presented in a table format (see table 5). The table consists of
three columns:
column 1: includes the relevant inter-message timing which is specified in the document ISO/DIS 14230-2. The
message shall be started within the relevant inter-message timing;
column 2: includes all requests send by the client to the server;
column 3: includes all responses send by the server to the client.
Sending of a message shall start during the period of time between appropriate messages.
Time relates to the table in a top to bottom sequence. The reading entry of the message flow table always starts
with the first item in the time column "P3" (1st column) followed by a request message of the client (2nd column)
The next entry is the timing parameter "P2" (1st column) for the server to send the positive or negative response
message (3rd column).
For simplification all messages are described without any identifiers and/or data values. Details of messages are
always specified in the section: Message data bytes.
The message flow example above is not documented for each service. Only services, which call for more detailed
message flow description shall have their own message flow section.
Table 5 — Message flow example of physical addressed service
time client (tester) server (ECU)
P3 Request[.]
P2 PositiveResponse[.]
© ISO
4.3 Functional unit table
The intention of specifying functional unit tables is to group similar Keyword Protocol (KWP) 2000 services into a
functional unit. The definition of each functional unit includes a table such as table 6 which lists its services.
Table 6 — Keyword Protocol 2000 functional units
Functional Unit Description
Diagnostic Management This functional unit includes Keyword Protocol 2000 services which
are used to realise diagnostic management functions between the
client (tester) and the server (ECU).
Data Transmission This functional unit includes Keyword Protocol 2000 services which
are used to realise data transmission functions between the client
(tester) and the server (ECU).
Stored Data Transmission This functional unit includes Keyword Protocol 2000 services which
are used to realise stored data transmission functions between the
client (tester) and the server (ECU).
Input / Output Control This functional unit includes Keyword Protocol 2000 services which
are used to realise input / output control functions between the client
(tester) and the server (ECU).
Remote Activation of Routine This functional unit includes Keyword Protocol 2000 services which
are used to realise remote activation of routine functions between
the client (tester) and the server (ECU).
Upload / Download This functional unit includes Keyword Protocol 2000 services which
are used to realise upload / download functions between the client
(tester) and the server (ECU).
4.4 Service Identifier value summary table
The left column of table 7 lists all services of the Diagnostic Services Specification, the middle column assigns the
KWP 2000 Implementation "Request Hex Value" and the right column assigns the KWP 2000 Implementation
"Positive Response Hex Value". The positive response service identifier values are built from the request service
identifier values by setting "bit 6 = 1".
4.5 Response Code value summary table
Table 8 lists and assigns hex values for all response codes used in KWP 2000. The definition of each response
code is described in ISO 14229.
© ISO
Table 7 — Service Identifier value summary table
KWP 2000 Implementation
Request Hex Value Response Hex Value
Diagnostic Service Name
StartDiagnosticSession 10 50
ECUReset 11 51
ReadFreezeFrameData 12 52
ReadDiagnosticTroubleCodes 13 53
ClearDiagnosticInformation 14 54
ReadStatusOfDiagnosticTroubleCodes 17 57
ReadDiagnosticTroubleCodesByStatus 18 58
ReadECUIdentification 1A 5A
StopDiagnosticSession 20 60
ReadDataByLocalIdentifier 21 61
ReadDataByCommonIdentifier 22 62
ReadMemoryByAddress 23 63
SetDataRates 26 66
SecurityAccess 27 67
DynamicallyDefineLocalIdentifier 2C 6C
WriteDataByCommonIdentifier 2E 6E
InputOutputControlByCommonIdentifier 2F 6F
InputOutputControlByLocalIdentifier 30 70
StartRoutineByLocalIdentifier 31 71
StopRoutineByLocalIdentifier 32 72
RequestRoutineResultsByLocalIdentifier 33 73
RequestDownload 34 74
RequestUpload 35 75
TransferData 36 76
RequestTransferExit 37 77
StartRoutineByAddress 38 78
StopRoutineByAddress 39 79
RequestRoutineResultsByAddress 3A 7A
WriteDataByLocalIdentifier 3B 7B
WriteMemoryByAddress 3D 7D
TesterPresent 3E 7E
1)
80 C0
EscCode
1) Does not form part of diagnostic services specification but only of KWP Protocol 2000.
© ISO
Table 8 —Response Code value summary table
Hex Value Response Code
10 GeneralReject
11 ServiceNotSupported
12 SubFunctionNotSupported-invalidFormat
21 Busy-RepeatRequest
22 ConditionsNotCorrect or requestSequenceError
23 RoutineNotComplete
31 RequestOutOfRange
33 SecurityAccessDenied
35 InvalidKey
36 ExceedNumberOfAttempts
37 RequiredTimeDelayNotExpired
40 DownloadNotAccepted
41 ImproperDownloadType
42 Can'tDownloadToSpecifiedAddress
43 Can'tDownloadNumberOfBytesRequested
50 UploadNotAccepted
51 ImproperUploadType
52 Can'tUploadFromSpecifiedAddress
53 Can'tUploadNumberOfBytesRequested
71 TransferSuspended
72 TransferAborted
74 IllegalAddressInBlockTransfer
75 IllegalByteCountInBlockTransfer
76 IllegalBlockTransferType
77 BlockTransferDataChecksumError
78 ReqCorrectlyRcvd-RspPending
79 IncorrectByteCountDuringBlockTransfer
80 - FF ManufacturerSpecificCodes
1) RequestCorrectlyReceived-ResponsePending
4.6 Response handling
Figure 3 specifies the server behaviour on a client request message. It shows the logic as specified in the
description of the response codes and to be implemented in the server and client as appropriate.
The use of (a) negative response message(s) by the server shall be in case the server can not respond with a
positive response message on a client (tester) request message. In such case the server shall send one of the
response codes listed as specified in figure 3.
© ISO
Start of service
NO
No Response Message
Valid Message?
YES
NO
Request Message
supported?
YES
case #1
YES RC=$78
Extended P2
timing window?
NO
case #2
YES
RC=$23
Service in
progress?
NO
NO
Positive Response
case #3
Message Ready?
YES
RC=$21
Server busy?
YES
NO
case #4
YES
RC=$10
General reject?
NO
RC=$xx
Negative Response Negative Response
Negative Response
Message RC=$10, Message RC=$23,
general reject routineNotComplete Message RC=$11,
serviceNotSupported or
Negative Response Negative Response
RC=$12,
Negative Response
Positive Response Message Message RC=$21, Message RC=$78,
Message RC=$xx subFunctionNotSupported
busyRepeatRequest responsePending
End of service
Figure 3 — Server positive and negative response message behaviour
5 General implementation rules
5.1 Parameter definitions
The following rules in regard to parameter definitions shall apply:
clauses 6 to 12 define the services of each functional unit. In these clauses, the service structure makes
reference to parameters, in order to describe the allowable values for such parameters. The parameters of
general purpose are defined in ISO 14229. Parameters which are specific to a functional unit are described in
the corresponding clause;
this part of ISO 14230 lists and defines response codes and values. Negative response codes are specified in
4.4. Other response codes may be reserved either for future definition by this part of ISO 14230 or for the
system designer's specific use;
this part of ISO 14230 specifies the parameters which shall be used within each KWP 2000 service;
© ISO
the sequence of parameters within a service shall not be changed during an implementation;
this part of ISO 14230 specifies the parameter MemoryAddress based on a three (3) byte address (High Byte,
Middle Byte and Low Byte). Additional bytes of specifying the MemoryAddress (e.g. memory type identifier,
larger address range) may be implemented and is the responsibility of the vehicle manufacturer. This applies to
all services which use the MemoryAddress parameter.
5.2 Functional and physical addressed service requests
Two different addressing methods are specified in KWP 2000 to send a service request to a server(s).
Functional addressing with a three byte header is used by the client if it does not know the physical address of the
server that shall respond to a service request or if more than one server can respond to the request.
Functional addressing with a one byte header is not possible.
Physical addressing with a three byte header shall always be a dedicated message to one server. The header of
the service request message indicates (target address) which server shall respond to the service request message.
Physical addressing with a one byte header is possible.
Only those server(s) which are initialized and in a diagnostic session which support the service request message
shall send a response message.
Functional and Physical addressing methods are specified in detail in ISO 14230-2.
The data link shall always be initialized prior to sending any of the KWP 2000 services.
5.3 Message flow examples of physical/functional addressed services
5.3.1 Physical addressed services
5.3.1.1 Physical addressed service with positive/negative response message
Table 9 shows a typical service request followed by a positive response message and a service request followed by
a negative response message.
Table 9 — Message flow example of physical addressed service
time client (tester) server (ECU)
P3 Request[.]
P2 PositiveResponse[.]
P3 Request[.]
P2 NegativeResponse[RC]
P3 Request[.]
P2 PositiveResponse[.]
5.3.1.2 Physical addressed service with periodic transmissions
Table 10 shows a message flow which describes a physical addressed service request with multiple positive
response messages.
© ISO
Table 10 — Message Flow example of physical addressed service with periodic transmissions
time client (tester) server (ECU)
P3
Request[RLI,TXM]
P2
PositiveResponse#1[RLI, .]
P2
:
P2
P3*
PositiveResponse#k[RLI, .]
P2
Req.[RCI,TXM]
P2
PosResp#1[RCI,
P2
...]
P3
:
P2
PosResp#k[RCI,
P2 .]
Request[MA,MS,TXM]
P2
P3* PosResp#1[RECVAL]
P2 :
P3 PosResp#1[RECVAL]
Request[.]
P2
< Any Other Service Name > PositiveResponse[.]
Request[RLI]
PositiveResponse[RLI,]
1) The values of the "P3" timing parameters shall be less than the value of "P2min" in order to allow the client (tester)
to send a new request message.
The message flow in table 10 describes a physical addressed service request ReadDataByLocal/Common-Identifier
or ReadMemoryByAddress with the periodic transmission mode enabled. The request message is followed by
multiple positive response messages from the physically addressed server. The periodically transmitted response
messages are terminated by the client with any request message not including the optional TransmissionMode
parameter. This request message shall be send to the server within the "P3*" timing window.
5.3.1.3 Physical addressed service and negative response message(s) with "RoutineNotComplete" and
"Busy-RepeatRequest"
Table 11 shows a message flow which describes a physical addressed service request followed by a negative
response message with the response code set to "RoutineNotComplete".
Table 11 — Physical addressing and negative response with "RoutineNotComplete" and "Busy-
RepeatRequest"
time client (tester) server (ECU)
1)
P3 Request [.] NegativeResponse[RoutineNotComplete]
P2
P3 Request[.] NegativeResponse[Busy-RepeatRequest]
P2 :
:
P3 Request[.] NegativeResponse[Busy-RepeatRequest]
P2 PositiveResponse[.]
2)
P3 Request[.] OR
P2 Service Name> NegativeResponse[RC != Busy-RepeatRequest]
P2
1) server has started routine.
2) server has completed routine.
© ISO
The message flow example in table 11 is based on a request message from the client which cause the server to
respond with a negative response message including the negative response code "RoutineNotComplete". This
response code indicates that the request message was properly received by the server and the routine/task/function
(initiated by the request message) is in process, but not yet completed. If the client repeats or sends another
request message the server shall "not reinitiate the task" (in case of the same request message) if the initial task
has not been completed. The server shall send another negative response message with the response code "Busy-
RepeatRequest". The negative response message shall be sent on each request message as long as the server
has not yet completed the initial routine/task/function. If the server has finished the routine/task/function it shall
respond with either a positive response message or a negative response message with a response code not equal
to "Busy-RepeatRequest".
The communication timing is not affected.
Applications which may require this message flow are as follows:
ClearDiagnosticInformation;
execution of routines;
SecurityAccess.
5.3.1.4 Implementation example of "server can not send a positive response within required timing"
5.3.1.4.1 Example of physical addressed service and negative response message with "ReqCorrectlyRcvd-
RspPending within Normal or Extended Timing"
Table 12 shows a message flow which describes a physical addressed service request followed by a negative
response message with the response code set to "RequestCorrectlyReceived-ResponsePending".
Table 12 — Example of physical addressing and negative response with "ReqCorrectlyRcvd-RspPending"
time client (ester) server (ECU)
P3 Request[.]
P2 NegRsp#1[ReqCorrectlyRcvd-
RspPending]
1)
:
P2
1)
NegRsp#n[ReqCorrectlyRcvd-
P2
RspPending]
Request[.]
P3
PositiveResponse[.]
P2
PositiveResponse[.]
1) P2min to P3max (refer to ISO 14230-2).
The message flow example in table 12 is based on a request message from the client which causes the server to
respond with one or multiple negative response message(s) including the negative response code
"RequestCorrectlyReceived-ResponsePending". This response code indicates that the request message was
received correctly, and that any parameters in the request message were valid, but the action to be performed may
not be completed yet. This response code may be used to indicate that the request message was properly received
and does not need to be retransmitted, but the server is not yet ready to receive another request.
The negative response message may be sent once or multiple times within a service if required by the server.
During the period of (a) negative response message(s) the TesterPresent service shall be disabled in the client.
This response code shall only be used in a negative response message if the server will not be able to receive
further request messages from the client within the P3 timing window. This may be the case if the server does data
processing or executes a routine which does not allow any attention to serial communication.
NOTE — The communication timing method is specified in ISO 14230-2:—, clause 5.
© ISO
Applications which may require above message flow are as follows:
ClearDiagnosticInformation;
execution of routines;
TransferData request messages including up to 255 data bytes;
Flash EEPROM or EEPROM memory programming.
5.3.1.4.2 Implementation of "Server can not send a positive response within Default Timing"
Table 13 shows a message flow which describes a physical addressed service request followed by a positive
response message sent with previously modified timing.
Table 13 — Physical addressing and modified timing with AccessTimingParameter service
Time
1) Client (tester) Server (ECU)
P3 StartDiagnosticSession.Request[.]
P2 StartDiagnosticSession.PosRsp[.]
P3 AccessTimingParameter.Request[ReadLimits]
P2 AccessTimingParameter.PosRsp[ReadLimits, P2-
P4]
P3 AccessTimingParameter.Request[setValues, P2-P4]
P2 { e.g. P2max = $F2 (18850 ms) }
2)
AccessTimingParameter.PosRsp[setValues]
{ Modified Timing is active! }
P3 Request[.]
PositiveResponse[.]
P2
P3 Request[]
PositiveResponse[]
P2 OR
OR
P3 Request[.]
3)
PositiveResponse[.]
P2
{ Default Timing is active! }
P3 Request[.]
PositiveResponse[.]
P2
1) New timing parameter values are active.
2) Modified Timing is active.
3) Default Timing is active.
The message flow example in table 13 describes the method of modifying the timing parameter values in the server
and the client by using the AccessTimingParameter service as specified in ISO 14230-2.
This method shall be used in case a server does not support a negative response message with the response code
($78) "RequestCorrectlyReceived-ResponsePending".
5.3.2 Functional addressed services
5.3.2.1 Functional addressed service with positive/negative response message
Table 14 shows a message flow example which describes a functional addressed service request followed by
response messages of multiple servers (ECU#1, ECU#2 . ECU#n-1, ECU#n).
© ISO
Table 14 — Message flow example of functional addressed service
Time client (tester) server (ECU)
P3 Request[.]
P2 PositiveResponse[.] {ECU#1}
P2 NegativeResponse[.] {ECU#2}
: :
P2 PositiveResponse[.] {ECU#n-1}
P2 PositiveResponse[.] {ECU#n}
P3 Other Request[.]
P2 Other PositiveRsponse[.] {ECU}
The message flow example in table 14 is based on a functional request message send by the client. An unknown
number of servers has been initialized previously (e.g. fast initialization by wake up pattern) which send positive and
negative response messages.
5.3.2.2 Functional addressed service and negative response messages with "RoutineNotComplete" and
"Busy-RepeatRequest"
Table 15 shows a message flow which describes a functional addressed service request followed by a negative
response message with the response code set to "RoutineNotComplete" from one server. All other servers send
positive response messages.
Table 15 — Functional addressing and negative response with "Busy-RepeatRequest"
Time client (tester) server (ECU)
1), 2)
P3 Request[.]
P2 NegRsp[RoutineNotComplete] {ECU#1}
P2 PositiveResponse[.] {ECU#2}
P2 PositiveResponse[.] {ECU#3}
1)
P3 Request[.] { Functional }
P2 NegRsp[Busy-RepeatRequest] {ECU#1}
P2 PositiveResponse[.] {ECU#2}
P2 PositiveResponse[.] {ECU#3}
1), 3)
P3 Request[.] { Functional}
P2 PositiveResponse[.] {ECU#1}
P2 PositiveResponse[.] {ECU#2}
P2 PositiveResponse[.] {ECU#3}
1) Functional.
2) Server has started routine.
3) Server has completed routine.
The message flow example in table 15 is based on a functional request message from the client which cause one
server (ECU#1) to respond with a negative response message including the negative response code
"RoutineNotComplete" The other servers (ECU#2, ECU#3) send a positive response message.
The response code indicates that the request message was properly received by the server and the
routine/task/function (initiated by the request message) is in process, but not yet completed. If the client repeats or
sends another functional request message the server shall "not reinitiate the task" (in case of the same request
message) if the initial task has not been completed. The server shall send another negative response message with
the response code "Busy-RepeatRequest". The negative response message shall be sent on each functional
© ISO
request message as long as the server has not yet completed the initial routine/task/function. If the server (ECU#1)
has finished the routine/task/function it shall respond with either a positive response message or a negative
response message with a response code not equal to "Busy-RepeatRequest".
The communication timing is not affected.
Applications which may require above message flow are as follows:
ClearDiagnosticInformation;
execution of routines;
SecurityAccess.
5.3.2.3 Implementation example of functional addressed service and negative response message with
"RequestCorrectlyReceived-ResponsePending"
Table 16 shows a message flow example which describes a functional addressed request message followed by a
negative response message with the response code set to "RequestCorrectlyReceived-ResponsePending" from
one server (ECU#1) and positive response messages from the other servers (ECU#2, ECU#3).
Table 16 — Example of functional addressing and negative response with "ReqCorrectlyRcvd-RspPending"
Time Client (tester) Server (ECU)
1)
P3 Req[.]
P2 NegRsp#1[ReqCorrectlyRcvd-RspPendg]
{ECU#1}
2)
PositiveResponse[.] {ECU#2}
P2
2)
PositiveResponse[.] {ECU#3}
P2
2)
NegRsp#2[ReqCorrectlyRcvd-RspPendg]
P2
{ECU#1}
2)
:
P2
2)
NegRsp#n[ReqCorrectlyRcvd-RspPendg]
P2 R
...
NORME ISO
INTERNATIONALE 14230-3
Première édition
1999-03-15
Véhicules routiers — Systèmes de
diagnostic — Protocole «Keyword 2000» —
Partie 3:
Couche application
Road vehicles — Diagnostic systems — Keyword Protocol 2000 —
Part 3: Application layer
A
Numéro de référence
Sommaire
1 Domaine d'application.1
2 Références normatives .2
3 Définitions .2
4 Conventions .2
4.1 Généralités .2
4.2 Convention de description des services.4
4.3 Tableau d'unité fonctionnelle .6
4.4 Récapitulatif des valeurs de l’identificateur de service.7
4.5 Récapitulatif des valeurs du code de réponse .7
4.6 Traitement du code de réponse .7
5 Règles générales de mise en œuvre.10
5.1 Définitions des paramètres.10
5.2 Demandes de services à adressage fonctionnel ou physique.11
5.3 Exemples de flux de messages de service à adressage physique ou fonctionnel.11
6 Unité fonctionnelle de gestion de diagnostic .19
6.1 Service StartDiagnosticSession.19
6.2 Service StopDiagnosticSession.21
6.3 Service SecurityAccess .22
6.4 Service TesterPresent .25
6.5 Service ECUReset.27
6.6 Service ReadECUIdentification .29
7 Unité fonctionnelle de transmission de données.30
7.1 Service ReadDataByLocalIdentifier .30
© 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 iso@iso.ch
Imprimé en Suisse
ii
© ISO
7.2 Service ReadDataByCommonIdentifier. 33
7.3 Service ReadMemoryByAddress . 35
7.4 Service DynamicallyDefineLocalIdentifier . 36
7.5 Service WriteDataByLocalIdentifier. 42
7.6 Service WriteDataByCommonIdentifier. 44
7.7 Service WriteMemoryByAddress . 45
7.8 Service SetDataRates. 46
8 Unité fonctionnelle de transmission de données enregistrées . 47
8.1 Service ReadDiagnosticTroubleCodes. 48
8.2 Service ReadDiagnosticTroubleCodesByStatus. 50
8.3 Service ReadStatusOfDiagnosticTroubleCodes . 52
8.4 Service ReadFreezeFrameData . 53
8.5 Service ClearDiagnosticInformation. 58
9 Unité fonctionnelle de contrôle d'entrée/sortie . 60
9.1 Service InputOutputControlByLocalIdentifier . 60
9.2 Service InputOutputControlByCommonIdentifier. 61
10 Unité fonctionnelle de télécommande de routines . 63
10.1 Service StartRoutineByLocalIdentifier . 63
10.2 Service StartRoutineByAddress . 64
10.3 Service StopRoutineByLocalIdentifier . 66
10.4 Service StopRoutineByAddress. 68
10.5 Service RequestRoutineResultsByLocalIdentifier . 69
10.6 Service RequestRoutineResultsByAddress . 71
11 Unité fonctionnelle de téléchargement vers l’amont ou l’aval. 72
11.1 Service RequestDownload. 72
11.2 Service RequestUpload. 74
11.3 Service TransferData. 76
11.4 Service RequestTransferExit. 78
12 Extension de service du protocole «Keyword 2000». 80
12.1 Service EscapeCode . 80
13 Exemples d'application. 81
iii
© ISO
13.1 Description des UCE embarquées .81
13.2 Initialisation fonctionnelle et communication à adressage fonctionnel .82
13.3 Messages de réponse uniques et multiples et achèvement de la communication.83
13.4 Paramètre SecurityAccess, transfert des données et modification des paramètres de temps.84
13.5 Service ReadDataByLocalIdentifier avec DynamicallyDefineLocalIdentifier.87
Annexe A (informative) Bibliographie .92
iv
© ISO
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-3 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 de la présente partie de l’ISO 14230 est donnée uniquement à titre d'information.
v
© 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
Confirmation
de service de service Indication
de service de service
Définition du service
Couche
Services de diagnostic
d'application
Mise en œuvre
(couche 7)
Protocole Keyword 2000
(ISO 14230-3)
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
Protocole Keyword 2000
(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 et du protocole «Keyword 2000» selon le modèle OSI
vi
NORME INTERNATIONALE © ISO ISO 14230-3:1999(F)
Véhicules routiers — Systèmes de diagnostic — Protocole
«Keyword 2000» —
Partie 3:
Couche application
1 Domaine d'application
La présente partie de l’ISO 14230 fixe les exigences relatives à la liaison de données du protocole «Keyword 2000»
sur laquelle une ou plusieurs unités de contrôle électronique embarquées sont connectées à un équipement non
embarqué afin d'effectuer des fonctions de diagnostic.
Elle fixe les prescriptions de mise en œuvre des services de diagnostic spécifiés dans l'ISO 14229, y compris:
le codage en octets et les valeurs hexadécimales pour les identificateurs du service;
le codage en octets pour les paramètres des demandes et réponses du service de diagnostic;
les valeurs hexadécimales pour les paramètres normalisés.
L'environnement du véhicule auquel la présente partie de l’ISO 14230 s'applique comprend 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 (voir la figure 2).
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
© ISO
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é.
1)
ISO 14229:— , Véhicules routiers — Systèmes de diagnostic — Spécification des services de diagnostic.
1)
ISO 14230-2:— , Véhicules routiers — Systèmes de diagnostic — Protocole «Keyword 2000» — Partie 2: Couche
de liaison de données.
SAE J 1930:1995, Electrical/electronic systems diagnostic — Terms, definitions, abbreviations and acronyms.
[Systèmes de diagnostic électriques et électroniques — Termes, définitions, abréviations et acronymes].
SAE J 1979:1996, E/E diagnostic test modes [Modes d'essai de diagnostic E/E].
3 Définitions
Pour les besoins de la présente partie de l’ISO 14230, les définitions données dans l'ISO 14229 et dans la
SAE J 1930 s'appliquent.
4 Conventions
4.1 Généralités
4.1.1 La présente partie de l’ISO 14230 est guidée par les conventions du service OSI (CVT; voir l’ISO 8509) dans
la mesure où elles s'appliquent aux services de diagnostic. Ces conventions définissent les interactions entre
l'utilisateur et le fournisseur de service par le biais de primitives de service, qui elles-mêmes peuvent acheminer des
paramètres.
4.1.2 Le tableau 1 indique les différentes plages des valeurs d’identificateur de services définies dans la
SAE J 1979, dans l'ISO 14230 ou par le constructeur du véhicule.
À publier.
1)
© ISO
Tableau 1 — Table des conventions d'écriture des valeurs d’identificateur de service
1)
Identificateur de service Défini dans (par)
Type du service
(valeur hexadécimale)
(bit 6)
00 à 0F Demande SAE J 1979
10 à 1F
20 à 2F Demande (bit 6 = 0) la présente partie de l’ISO 14230
30 à 3E
3F Sans objet (réservé)
40 à 4F Réponse SAE J 1979
50 à 5F Réponse positive
60 à 6F aux services ($10 à $3E)
70 à 7E (bit 6 = 1) la présente partie de l’ISO 14230
7F Réponse négative
80 Demande code ESC
81 à 8F Demande (bit 6 = 0) ISO 14230-2
90 à 9F Demande (bit 6 = 0) (réservé pour exploitation éventuelle future)
A0 à BF Demande (bit 6 = 0) le constructeur du véhicule
C0 Réponse positive Code ESC la présente partie de l’ISO 14230
C1 à CF Réponse positive (bit 6 = 1) ISO 14230-2
D0 à DF Réponse positive (bit 6 = 1) (réservé pour exploitation éventuelle future)
E0 à FF Réponse positive (bit 6 = 1) le constructeur du véhicule
1) Il existe une correspondance bijective entre les messages de demande et les messages de réponse positive, le
bit 6 de la valeur hexadécimale de l’identificateur de service indiquant le type de service.
4.1.3 Le contenu d'un tableau se décompose comme suit:
sous «Message de demande du service » sont listés les paramètres spécifiques à la
demande ou à l’indication du service;
sous «Message de réponse positive de » sont listés les paramètres spécifiques à la réponse
ou à la confirmation du service si le service demandé a réussi;
sous «Message de réponse négative de » sont listés les paramètres spécifiques à la réponse
ou à la confirmation du service si le service demandé a échoué ou ne pouvait être assuré en temps voulu.
4.1.4 Pour une primitive donnée, la présence de chaque paramètre est décrite par une des valeurs suivantes:
M: obligatoire;
U: option de l’utilisateur; le paramètre peut ou ne peut pas être fourni, selon l'usage dynamique qu'en fait
l'utilisateur;
C: conditionnelle; la présence du paramètre dépend d'autres paramètres du service;
S: sélection obligatoire (sauf spécification contraire) d'un paramètre dans une liste de paramètres.
© ISO
4.2 Convention de description des services
Le présent paragraphe définit le plan utilisé pour décrire les services de diagnostic dans la présente partie de
l’ISO 14230. Il comprend les catégories suivantes:
la définition des paramètres;
les octets des données de message;
la description du message;
des exemples de flux de messages.
4.2.1 Définition des paramètres
Le paragraphe «Description du message» définit l'utilisation et les valeurs des paramètres employés par le service.
4.2.2 Octets des données de message
Le paragraphe «Octets des données de message» donne la définition de chaque message à l’aide de tableaux qui
répertorient les paramètres des primitives du message: demande/indication, réponse/confirmation pour un résultat
positif ou négatif. Ils ont tous la même structure. Le tableau 2 donne la structure du message de demande, le
tableau 3 du message de réponse positive et le tableau 4 du message de réponse négative.
Un message de réponse positive doit être émis par le serveur s'il est en mesure d'effectuer la totalité des opérations
demandées. Dans le cas contraire, il doit émettre un message de réponse négative.
NOTE — Ils sont tous deux énumérés dans des tableaux séparés car la liste des paramètres diffère selon que le message
donne une réponse positive ou négative.
Tableau 2 — Message de demande
Pré- Valeur
Type Nom du paramètre Mnémonique
1)
hexadécimale
sence
Octets de Octet de format M xx FMT
message
3)
Octet cible xx TGT
C
2)
d'en-tête
3)
Octet source xx SRC
C
4)
Octet de longueur xx LEN
C
M xx SN
du service>
5)
= [, ., C xx = [xx, ., PN
paramètres> ] xx]
2)
Octet de total de contrôle M xx CS
CS
1) Voir 4.1.4.
2) Défini dans l’ISO 14230-2.
3) Les octets cible et source du message d'en-tête dépendent du contenu de l'octet de format prescrit dans l’ISO 14230-2.
Mais tous les deux existent ou n'existent pas dans l'en-tête de chaque message.
4) L'octet de longueur du message d'en-tête dépend du contenu de l'octet de format prescrit dans l’ISO 14230-2.
5) Ces paramètres peuvent être obligatoires (M) ou au choix de l'utilisateur (U), en fonction du message particulier.
© ISO
Tableau 3 — Message de réponse positive
Pré- Valeur
Type Nom du paramètre Mnémonique
1)
hexadécimale
sence
Octets de Octet de format M xx FMT
message
3)
Octet cible xx TGT
C
2)
d'en-tête
3)
Octet source xx SRC
C
4)
Octet de longueur xx LEN
C
du service> service>
5)
= [, ., xx = [xx, ., PN
C
paramètres> ] xx]
2)
CS Octet de total de contrôle M xx CS
1) Voir 4.1.4.
2) Défini dans l’ISO 14230-2.
3) Les octets cible et source du message d'en-tête dépendent du contenu de l'octet de format prescrit dans l’ISO 14230-2.
Mais tous les deux existent ou n'existent pas dans l'en-tête de chaque message.
4) L'octet de longueur du message d'en-tête dépend du contenu de l'octet de format prescrit dans l’ISO 14230-2.
5) Ces paramètres peuvent être obligatoires (M) ou au choix de l'utilisateur (U), en fonction du message particulier.
Tableau 4 — Message de réponse négative
Pré- Valeur
Type Nom du paramètre Mnémonique
1)
hexadécimale
sence
Octets de Octet de format M xx FMT
message
3)
Octet cible xx TGT
C
2)
d'en-tête
3)
Octet source xx SRC
C
4)
Octet de longueur xx LEN
C
du service> service>
M xx SN
du service>
paramètres> ManufacturerSpecific] 80 à FF]
2)
Octet de total de contrôle M xx CS
CS
1) Voir 4.1.4.
2) Défini dans l’ISO 14230-2.
3) Les octets cible et source du message d'en-tête dépendent du contenu de l'octet de format prescrit dans l’ISO 14230-2.
Mais tous les deux existent ou n'existent pas dans l'en-tête de chaque message.
4) L'octet de longueur du message d'en-tête dépend du contenu de l'octet de format prescrit dans l’ISO 14230-2.
© ISO
4.2.3 Description du message
Le paragraphe «Description du message» fournit une description des opérations effectuées par le client et le
serveur et spécifiques à la liaison de données du protocole KWP 2000 (voir l’ISO 14230-2).
La condition de la réponse est spécifique au service et définie séparément pour chacun.
4.2.4 Exemples de flux de messages
Le paragraphe «Exemples de flux de messages» fournit des descriptions de flux de messages présentés en format
tabulaire (voir tableau 5). Le tableau se compose de trois colonnes:
la colonne 1 contient le laps de temps entre les messages, prescrit dans l’ISO 14230-2;
la colonne 2 contient toutes les demandes transmises par le client au serveur;
la colonne 3 contient toutes les réponses transmises par le serveur au client.
L’émission du message doit débuter dans le laps de temps entre les messages approprié.
Le temps est donné dans le tableau suivant une séquence chronologique de haut en bas. La lecture du tableau du
ère
flux de messages commence toujours par le premier élément P3 dans la colonne intitulée «Temps» (1 colonne),
e ère
suivi d'un message de demande du client (2 colonne). L'entrée suivante est le paramètre de temps P2 (1
e
colonne) permettant au serveur d'émettre le message de réponse positive ou négative (3 colonne).
Pour simplifier, tous les messages sont décrits sans identificateur ni valeur pour les données. Les détails des
messages sont prescrit dans le paragraphe «Octets des données de message».
L'exemple ci-dessus de flux de messages n'est pas documenté pour chaque service. Seuls les services qui
demandent une description plus détaillée du flux de messages ont leur propre dans le paragraphe «Exemples de
flux de messages».
Tableau 5 — Exemple de flux de messages d'un service à adressage physique
Temps Client (équipement de diagnostic) Serveur (UCE)
P3 Demande de [.]
P2 Réponse positive [.]
4.3 Tableau d'unité fonctionnelle
La spécification de tableaux d'unités fonctionnelles a pour but de grouper des services similaires du protocole
KWP 2000 en une unité fonctionnelle. La définition de chaque unité fonctionnelle comprend un tableau comme le
tableau 6 qui répertorie ses services.
© ISO
Tableau 6 — Unités fonctionnelles du protocole «Keyword 2000»
Unité fonctionnelle Description
Gestion de diagnostic Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions de gestion de
diagnostic entre le client (équipement de diagnostic) et le serveur (UCE).
Transmission des données Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions de transmission des
données entre le client (équipement de diagnostic) et le serveur (UCE).
Transmission des données stockées Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions de transmission des
données stockées entre le client (équipement de diagnostic) et le serveur
(UCE).
Commande d'entrée/sortie Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions de commande
d'entrée/sortie entre le client (équipement de diagnostic) et le serveur
(UCE).
Activation à distance d’une routine Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions d’activation à distance
des fonctions de routine entre le client (équipement de diagnostic) et le
serveur (UCE).
Téléchargement vers l’amont ou l’aval Cette unité fonctionnelle comprend les services du protocole
«Keyword 2000» utilisés pour assurer les fonctions de téléchargement vers
l’amont ou l’aval entre le client (équipement de diagnostic) et le serveur
(UCE).
4.4 Récapitulatif des valeurs de l’identificateur de service
Le tableau 7 répertorie tous les services de la spécification des services de diagnostic, avec la valeur hexadécimale
de la demande de la mise en œuvre du protocole KWP 2000 et celle de la réponse positive de la mise en œuvre du
protocole KWP 2000. Les valeurs de l’identificateur du service de réponse positive sont établies à partir des valeurs
d’identificateur du service de demande en posant bit 6 = 1.
4.5 Récapitulatif des valeurs du code de réponse
Le tableau 8 répertorie et attribue des valeurs hexadécimale à tous les codes de réponse utilisés dans le protocole
KWP 2000. La définition de chaque code de réponse est décrite dans l’ISO 14229.
4.6 Traitement du code de réponse
La figure 3 prescrit le comportement du serveur en cas de message de demande du client. Elle présente la logique
telle qu'elle est prescrite dans la description des codes de réponse et telle qu'elle doit être mise en œuvre par le
serveur et le client, selon le cas.
L'emploi d'un ou de plusieurs message(s) de réponse négative par le serveur doit intervenir lorsque le serveur ne
peut pas répondre par un message de réponse positive à un message de demande du client (équipement de
diagnostic). En pareil cas, le serveur doit émettre l'un des codes de réponse donnés dans la présente partie de
l’ISO 14230, comme prescrit à la figure 3.
© ISO
Tableau 7 — Récapitulatif des valeurs de l’identificateur de service
Mise en œuvre du protocole
KWP 2000
Valeur Valeur
Nom du service de diagnostic
hexadécimale de hexadécimale de
la demande la réponse
StartDiagnosticSession 10 50
ECUReset 11 51
ReadFreezeFrameData 12 52
ReadDiagnosticTroubleCodes 13 53
ClearDiagnosticInformation 14 54
ReadStatusOfDiagnosticTroubleCodes 17 57
ReadDiagnosticTroubleCodesByStatus 18 58
ReadECUIdentification 1A 5A
StopDiagnosticSession 20 60
ReadDataByLocalIdentifier 21 61
ReadDataByCommonIdentifier 22 62
ReadMemoryByAddress 23 63
SetDataRates 26 66
SecurityAccess 27 67
DynamicallyDefineLocalIdentifier 2C 6C
WriteDataByCommonIdentifier 2E 6E
InputOutputControlByCommonIdentifier 2F 6F
InputOutputControlByLocalIdentifier 30 70
StartRoutineByLocalIdentifier 31 71
StopRoutineByLocalIdentifier 32 72
RequestRoutineResultsByLocalIdentifier 33 73
RequestDownload 34 74
RequestUpload 35 75
TransferData 36 76
RequestTransferExit 37 77
StartRoutineByAddress 38 78
StopRoutineByAddress 39 79
RequestRoutineResultsByAddress 3A 7A
WriteDataByLocalIdentifier 3B 7B
WriteMemoryByAddress 3D 7D
TesterPresent 3E 7E
1)
80 C0
ESCCode
1) Ne fait pas partie de la spécification des services de diagnostic mais du protocole KWP 2000 seulement.
© ISO
Tableau 8 — Récapitulatif des valeurs de code de réponse
Valeur
Code de réponse
hexadécimale
10 GeneralReject
11 ServiceNotSupported
12 SubFunctionNotSupported-invalidFormat
21 Busy-RepeatRequest
22 ConditionsNotCorrect ou requestSequenceError
23 RoutineNotComplete
31 RequestOutOfRange
33 SecurityAccessDenied
35 InvalidKey
36 ExceedNumberOfAttempts
37 RequiredTimeDelayNotExpired
40 DownloadNotAccepted
41 ImproperDownloadType
42 Can'tDownloadToSpecifiedAddress
43 Can'tDownloadNumberOfBytesRequested
50 UploadNotAccepted
51 ImproperUploadType
52 Can'tUploadFromSpecifiedAddress
53 Can'tUploadNumberOfBytesRequested
71 TransferSuspended
72 TransferAborted
74 IllegalAddressInBlockTransfer
75 IllegalByteCountInBlockTransfer
76 IllegalBlockTransferType
77 BlockTransferDataChecksumError
1)
ReqCorrectlyRcvd-RspPending
79 IncorrectByteCountDuringBlockTransfer
80 à FF ManufacturerSpecificCodes
1) RequestCorrectlyReceived-ResponsePending
© ISO
Démarrage du service
Non
Message de réponse
Message valide ?
négative
Oui
Message de
Non
demande pris en
charge ?
Oui
Cas 1
Oui RC = $78
Fenêtre de temps
étendu P2 ?
Non
Cas 2
Oui
RC = $23
Service en
cours ?
Non
Message de
Non
Cas 3
réponse positive
Oui
RC = $21
prêt ?
Serveur occupé ?
Oui
Non
Cas 4
Oui
RC = $10
Refus général ?
Non
RC = $xx
Message de réponse Message de réponse
Message de réponse
négative RC = $10, négative RC = $23,
négative RC = $11,
generalReject RoutineNotComplete
ServiceNotSupported ou
Message de réponse
Message de réponse
Message de réponse RC = $12,
Message de réponse positive négative RC = $21,
négative RC = $78,
SubFunctionNotSupported
négative RC = $xx
Busy-RepeatRequest
responsePending
Fin du service
Figure 3 — Comportement du serveur en cas de message de demande du client
5 Règles générales de mise en œuvre
5.1 Définitions des paramètres
Les règles suivantes doivent s'appliquer en ce qui concerne les définitions des paramètres:
les articles 6 à 12 définissent les services de chaque unité fonctionnelle. Dans ces articles, la structure du
service fait référence aux paramètres et donne leurs valeurs admissibles. Les paramètres à usage général
sont définis dans l'ISO 14229. Les paramètres spécifiques d'une unité fonctionnelle sont décrits dans l’article
correspondant;
© ISO
la présente partie de l’ISO 14230 répertorie et définit les codes et les valeurs des réponses. Les codes de
réponse négative sont prescrits en 4.4. D'autres codes de réponse peuvent être réservés pour être définis
ultérieurement par la présente partie de l’ISO 14230 ou à l'usage spécifique du concepteur de systèmes;
la présente partie de l’ISO 14230 prescrit les paramètres qui doivent être utilisés dans chaque service du
protocole KWP 2000;
la suite des paramètres d'un service ne doit pas être modifiée au cours d'une mise en œuvre;
la présente partie de l’ISO 14230 prescrit le paramètre MemoryAddress fondé sur une adresse de trois octets
(octet de poids le plus fort, octet de poids moyen et octet de poids le plus faible). Des octets supplémentaires
destinés à spécifier le paramètre MemoryAddress (par exemple identificateur du type de mémoire, plage
d'adresses plus grande) peuvent être mis en œuvre sous la responsabilité du constructeur du véhicule. Cela
s'applique à tous les services utilisant le paramètre MemoryAddress.
5.2 Demandes de services à adressage fonctionnel ou physique
Deux méthodes différentes d'adressage sont spécifiées dans le protocole KWP 2000 pour transmettre une
demande de service à un (des) serveur(s).
L'adressage fonctionnel avec message d'en-tête de trois octets est utilisé par le client s'il ne connaît pas l'adresse
physique du serveur qui doit répondre à la demande de service ou si plusieurs serveurs peuvent répondre à cette
demande.
L'adressage fonctionnel avec un en-tête de un octet n'est pas possible.
L'adressage physique avec un en-tête de trois octets doit toujours être un message destiné à un serveur précis.
L'en-tête du message de demande de service (adresse cible) indique quel serveur doit répondre au message de
demande de service.
L'adressage physique avec un en-tête de un octet est possible.
Seul(s) le (les) serveur(s) initialisé(s) et se trouvant dans une session de diagnostic prenant en charge le message
de demande de service doit (doivent) émettre un message de réponse.
Les méthodes d'adressage physique et fonctionnel sont prescrites dans l'ISO 14230-2.
La liaison de données doit toujours être initialisée avant d'émettre un service du protocole KWP 2000 quelconque.
5.3 Exemples de flux de messages de service à adressage physique ou fonctionnel
5.3.1 Services à adressage physique
5.3.1.1 service à adressage physique avec message de réponse positive ou négative
Le tableau 9 présente une demande de service type suivie d'un message de réponse positive et une demande de
service suivie d'un message de réponse négative.
5.3.1.2 service à adressage physique avec transmissions périodiques
Le tableau 10 présente une flux de messages qui décrit une demande de service à adressage physique avec
messages de réponse positive multiples.
Le flux de messages indiqué dans le tableau 10 décrit une demande de service à adressage physique
ReadDataByLocalIdentifier, ReadDataByCommonIdentifier ou ReadMemoryByAddress avec activation du mode
périodique de transmission. Le message de demande est suivi de messages de réponse positive multiples du
serveur faisant l'objet d'un adressage physique. Le client termine les messages de réponse transmis
périodiquement par un message de demande qui ne comporte pas le paramètre facultatif TransmissionMode. Ce
message de demande doit être envoyé au serveur dans le créneau de la fenêtre de temps P3, avec la condition
indiquée dans la note 1) en bas du tableau 10.
© ISO
Tableau 9 — Exemple de flux de messages d'un service à adressage physique
Temps Client (équipement de diagnostic) Serveur (UCE)
P3 Demande de [.]
P2 Réponse positive [.]
P3 Demande de [.]
P2 Réponse négative [RC]
P3 Demande de [.]
P2 Réponse positive [.]
Tableau 10 — Exemple de flux de messages d'un service à adressage physique avec transmissions
périodiques
Temps Client (équipement de diagnostic) Serveur (UCE)
P3 Demande [RLI, TXM]
P2 Réponse positive 1 [RLI,
...]
P2 .
P2 Réponse positive k [RLI,
...]
1)
Demande [RCI, TXM]
P3
P2 Réponse positive 1
[RCI, .]
P2 .
P2 Réponse positive k
[RCI, .]
1)
Demande [MA, MS, TXM]
P3
P2 Réponse positive 1
[RECVAL]
P2 .
P2 Réponse positive k
[RECVAL]
1)
Demande [.]
P3
P2 Réponse positive [.]
P3 Demande [RLI]
P2 Réponse positive [RLI, .]
1) Les valeurs de P3 doivent être inférieures à la valeur de P2 afin de permettre au client (équipement de diagnostic)
min
d'envoyer un nouveau message de demande.
5.3.1.3 service à adressage physique et message(s) de réponse négative avec «RoutineNotComplete» et
«Busy-RepeatRequest»
Le tableau 11 présente un flux de messages décrivant une demande de service faisant l'objet d'un adressage
physique, suivie d'un message de réponse négative, le code de réponse étant «RoutineNotComplete».
© ISO
Tableau 11 — Adressage physique et réponse négative avec «RoutineNotComplete» et «Busy-
RepeatRequest»
Temps Client (équipement de diagnostic) Serveur (UCE)
1)
P3
Demande [.]
P2 Réponse négative
[RoutineNotComplete]
P3 Demande [.]
P2 Réponse négative [Busy-
RepeatRequest]
P3 .
P2 .
P3 Demande [.]
P2 Réponse négative [Busy-
RepeatRequest]
2)
P3
Demande [.]
P2 Réponse positive [.], ou
service> [RC = Busy-RepeatRequest]
1) Le serveur débute la routine.
2) Le serveur termine la routine.
L'exemple de flux de messages indiqué dans le tableau 11 repose sur un message de demande du client qui
entraîne de la part du serveur un message de réponse négative incluant le code de réponse négative
«RoutineNotComplete». Ce code de réponse indique que le message de demande a été correctement reçu par le
serveur et que la routine, la tâche ou la fonction déclenchée par le message de demande est en cours, mais pas
encore terminée. Si le client répète le message de demande ou en envoie un autre alors que la tâche initiale n'est
pas entièrement exécutée, le serveur ne doit pas redéclencher la tâche (s'il s'agit du même message de demande).
Le serveur doit envoyer un autre message de réponse négative avec le code de réponse «Busy-RepeatRequest».
Le message de réponse négative doit être envoyé en réponse à chaque message de demande tant que le serveur
n'a pas entièrement exécuté la routine, la tâche ou la fonction initiale. Si le serveur a terminé la routine, la tâche ou
la fonction, il doit répondre par un message de réponse positive ou par un message de réponse négative avec un
code de réponse autre que «Busy-RepeatRequest».
Le minutage de la communication n'est pas affecté.
Les applications suivantes peuvent nécessiter le flux de messages ci-dessus:
ClearDiagnosticInformation;
exécution de routines;
SecurityAccess.
5.3.1.4 Exemple de mise en œuvre de «le serveur ne peut pas envoyer une réponse positive dans le temps
requis»
5.3.1.4.1 Exemple de service à adressage physique et de message de réponse négative avec
«ReqCorrectlyRcvd-RspPending» dans le temps normal ou le temps étendu
Le tableau 12 présente un flux de messages qui décrit une demande de service faisant l'objet d'un adressage
physique, suivie d'un message de réponse négative avec le code de réponse «ReqCorrectlyRcvd-RspPending»
(RequestCorrectlyReceived-ResponsePending).
© ISO
Tableau 12 — Exemple d'adressage physique et de réponse négative avec «ReqCorrectlyRcvd-
RspPending»
Temps Client (équipement de diagnostic) Serveur (UCE)
P3 Demande [.]
P2 Réponse négative 1
[ReqCorrectlyRcvd-RspPending]
1)
...
P2
1)
Réponse négative n
P2
[ReqCorrectlyRcvd-RspPending]
P3 Demande [.]
P2 Réponse positive [.]
1) De P2 à P3 (se reporter à l'ISO 14230-2).
min max
L'exemple de flux de messages indiqué dans le tableau 12 repose sur un message de demande du client qui
entraîne de la part du serveur une réponse par un ou plusieurs message(s) de réponse négative incluant le code de
réponse négative «ReqCorrectlyRcvd-RspPending». Ce code de réponse indique que le message de demande a
été correctement reçu et que tous les paramètres du message de demande étaient valides mais que l'action à
exécuter peut ne pas être encore terminée. Ce code de réponse peut également être utilisé pour indiquer que le
message de demande a été correctement reçu et n'a pas à être retransmis, mais que le serveur n'est pas encore
prêt à recevoir une autre demande.
Le message de réponse négative peut être envoyé une fois ou plusieurs fois dans un même service si cela est
exigé par le serveur.
Pendant la période d'un ou de plusieurs messages de réponse négative, le service TesterPresent doit être
désactivé dans le client.
Ce code de réponse ne doit être utilisé dans un message de réponse négative que si le serveur n'est pas en
mesure de recevoir d'autres messages de demande du client dans la fenêtre de temps P3. Cela peut être le cas si
le serveur effectue un traitement de données ou exécute une routine qui ne permet pas d'accorder de l'attention aux
communications série.
La méthode de minutage de la communication est prescrite dans l'ISO 14230-2:—, article 5.
Les applications suivantes peuvent nécessiter le flux de messages ci-dessus:
ClearDiagnosticInformation;
exécution de routines;
messages de demande TransferData jusqu’à, et y compris, 255 octets d'information;
programmation de la mémoire EEPROM ou flash EEPROM.
5.3.1.4.2 Mise en œuvre de «le serveur ne peut pas envoyer une réponse positive dans le temps par
défaut»
Le tableau 13 présente un flux de messages qui décrit une demande de service faisant l'objet d'un adressage
physique suivie d'un message de réponse positive envoyé avec modification antérieure du minutage.
© ISO
Tableau 13 — Adressage physique et minutage modifié avec le service AccessTimingParameters
1)
Client (équipement de diagnostic) Serveur (UCE)
Temps
P3 Demande StartDiagnosticSession [.]
P2 Réponse positive StartDiagnosticSession [.]
P3 Demande AccessTimingParameters [ReadLimits]
P2 Réponse positive AccessTimingParameters
[ReadLimits, P2 à P4]
P3 Demande AccessTimingParameters [setValues, P2 à
P4]
P2 Réponse positive AccessTimingParameters
2)
[setValues]
P3 Demande [.]
P2 Réponse positive [.]
P3 Demande [.], ou demande
[.]
P2 Réponse positive [.], ou
3)
réponse positive [.]
P3 Demande [.]
P2 Réponse positive [.]
1) Les nouvelles valeurs du paramètre de temps sont actives.
2) Le temps modifié est actif.
3) Le temps par défaut est actif.
L'exemple de flux de messages indiqué dans le tableau 13 décrit la méthode de modification des valeurs du
paramètre de temps dans le serveur et le client en utilisant le service AccessTimingParameters prescrit dans
l'ISO 14230-2.
Cette méthode doit être utilisée lorsqu'un serveur ne prend pas en charge un message de réponse négative avec le
code de réponse ($78) «ReqCorrectlyRcvd-RspPending».
5.3.2 Services à adressage fonctionnel
5.3.2.1 service à adressage fonctionnel avec message de réponse positive ou négative
Le tableau 14 présente un exemple de flux de messages décrivant une demande de service faisant l'objet d'un
adressage fonctionnel, suivie de messages de réponse de serveurs multiples (UCE 1, UCE 2, ., UCE n–1, UCE n).
© ISO
Tableau 14 — Exemple de flux de messages d'un service à adressage fonctionnel
Temps Client (équipement de diagnostic) Serveur (UCE)
P3 Demande [.]
P2 Réponse positive de UCE 1 [.]
P2 Répo
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...