ISO 14229:1998
(Main)Road vehicles — Diagnostic systems — Diagnostic services specification
Road vehicles — Diagnostic systems — Diagnostic services specification
Véhicules routiers — Systèmes de diagnostic — Spécification des services de diagnostic
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14229
First edition
1998-07-15
Road vehicles — Diagnostic systems —
Diagnostic services specification
Véhicules routiers — Systèmes de diagnostic — Spécification des services
de diagnostic
A
Reference number
ISO 14229:1998(E)
---------------------- Page: 1 ----------------------
ISO 14229:1998(E)
Page
Contents
1 Scope . 1
2 Normative reference . 2
3 Definitions and abbreviations . 2
3.1 Terms defined in other standards . 2
Additional definitions .
3.2 2
3.3 Abbreviations . 4
4 Convention . 4
4.1 Interactions . 4
4.2 OSI Service . 5
4.3 Service description . 6
4.4 Functional unit table . 7
5 Parameter specification . 7
5.1 General purpose parameters . 7
5.2 Server identifier . 7
5.3 Client identifier . 8
5.4 Local identifier and common identifier . 8
5.5 Memory address and routine address . 8
Response code .
5.6 8
5.7 Response code handling . 12
6 Diagnostic management functional unit . 12
6.1 General . 12
6.2 StartDiagnosticSession service . 15
6.3 StopDiagnosticSession service . 15
SecurityAccess service .
6.4 16
6.5 TesterPresent service . 17
6.6 ECUReset service . 18
6.7 ReadECUIdentification service . 19
6.8 DisableNormalMessageTransmission service . 19
6.9 EnableNormalMessageTransmission service . 20
Data Transmission functional unit .
7 21
7.1 Service of functional unit . 21
7.2 ReadDataLocalIdentifier service . 23
7.3 ReadDataByCommonIdentifier service . 24
7.4 ReadMemoryByAddress service . 25
7.5 DynamicallyDefineLocalIdentifier service . 26
7.6 WriteDataByLocalIdentifier service . 28
© ISO 1998
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
---------------------- Page: 2 ----------------------
©
ISO ISO 14229:1998(E)
7.7 WriteDataByCommonIdentifier service . 29
7.8 WriteMemoryByAddress service . 29
7.9 SetDataRates service . 30
7.10 StopRepeatedDataTransmission service . 31
8 Stored data transmission functional unit . 32
General .
8.1 32
8.2 ReadDiagnosticTroubleCodes service . 33
8.3 ReadDiagnosticTroubleCodesByStatus service . 34
8.4 ReadStatusOfDiagnosticTroubleCodes service . 35
8.5 ReadFreezeFrameData service . 35
8.6 ClearDiagnosticInformation service . 36
InputOutput Control functional unit .
9 37
9.1 General . 37
9.2 InputOutputControlByLocalIdentifier service . 38
9.3 InputOutputControlByCommonIdentifier service . 38
10 Remote activation of routine functional unit . 39
10.1 General . 39
10.2 StartRoutineByLocalIdentifiers service . 40
10.3 StartRoutineByAddress service . 41
10.4 StopRoutineByLocalIdentifier service . 42
10.5 StopRoutineByAddress service . 43
10.6 RequestRoutineResultsByLocalIdentifier service . 43
10.7 RequestRoutineResultsByLocalAddress service . 44
11 Upload/download functional unit . 45
General .
11.1 45
11.2 RequestDownload service . 45
11.3 RequestUpload service . 46
11.4 TransferData service . 46
11.5 RequestTransferExit service . 47
12 Examples . 48
Annex A (informative) Bibliography . 50
iii
---------------------- Page: 3 ----------------------
©
ISO 14229:1998(E) 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, govermental and non-govermental, 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 committee 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 14229 was prepared by Technical Committee ISO/TC 22, Road vehicles,
Subcommittee SC 3, Electrical and electronic equipment.
Annex A of this International Standard is for information only.
iv
---------------------- Page: 4 ----------------------
©
ISO ISO 14229:1998(E)
Introduction
This International Standard has been established in order to define common requirements for diagnostic
systems, whatever the serial data link is.
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), in accordance with figure 1.
Figure 1 — Mapping of the diagnostic services on the OSI Model
This International Standard contains references to SAE publications, which are regularly
amended/updated without any visible change (neither in the numbering, nor any additive letter, etc.). To
ensure precisely to which particular edition this International Standard refers, annex A gives the precise
dates of the SAE publications used.
v
---------------------- Page: 5 ----------------------
©
INTERNATIONAL STANDARD ISO ISO 14229:1998(E)
Road vehicles — Diagnostic systems — Diagnostic
services specification
1 Scope
This International Standard specifies common requirements of diagnostic services which allow a
diagnostic tester to control diagnostic functions in an on-vehicle electronic control unit (e.g. electronic
fuel injection, automatic gearbox, anti-lock braking system, etc.) connected on a serial data link
embedded in a road vehicle.
It specifies generic services which allow the diagnostic tester to stop or to resume non-diagnostic
message transmission on the data link.
This International Standard does not apply to non-diagnostic message transmission, nor to use of the
communication data link between two electronic control units.
This International Standard neither specifies implementation requirements, numerical values of services
and parameters, nor requirements for the communication services.
The vehicle diagnostic architecture of this International Standard applies 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.
See figure 2.
In vehicle 1, the ECUs are connected over 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
1
---------------------- Page: 6 ----------------------
©
ISO
ISO 14229:1998(E)
2 Normative reference
The following standard contains provisions which, through reference in this text, constitute provisions of
this International Standard. At the time of publication, the edition indicated was valid. All standards are
subject to revision, and parties to agreement based on this International Standard are encouraged to
investigate the possibility of applying the most recent edition of the standard indicated below. Members
of IEC and ISO maintain registers of currently valid International Standards.
ISO/IEC 10731:1994, Information technology — Open Systems Interconnection — Basic Reference
Modal — Conventions for the definition of OSI services.
3 Definitions and abbreviations
3.1 Terms defined in other standards
3.1.1
type
named set of values
3.1.2
bitstring type
type whose values are strings (sequences) of bits
NOTE — The bitstring type is used if no range is defined except the number of bits used (e.g. diagnostic trouble
codes could be represented by a sequence of bits).
3.1.3
integer type
a simple type with distinguished values which are the positive and the negative whole numbers,
including zero
NOTE — The range of type integer is not specified.
3.1.4
diagnostic trouble code
numerical common identifier for a fault condition identified by the on-board diagnostic system
[SAE J 1930]
3.2 Additional definitions
3.2.1
diagnostic service
information exchange initiated by a client in order to require diagnostic information from a server or/and
to modify its behaviour for diagnostic purpose
3.2.2
client
function that is part of the tester and that makes use of the diagnostic services
NOTE — A tester normally makes use of other functions such as data base management, specific interpretation,
man-machine interface.
2
---------------------- Page: 7 ----------------------
©
ISO
ISO 14229:1998(E)
3.2.3
server
function that is part of an ECU and that provides the diagnostic services
NOTE — This International Standard differentiates between the server (i.e. the function) and the ECU so that it
remains independent of the implementation.
3.2.4
tester
system that controls functions such as test, inspection, monitoring, or diagnosis of an on-vehicle ECU
NOTE — Testers may be dedicated to a specific type of operators (e.g. a scan tool dedicated to garage
mechanics or a test tool dedicated to assembly plant agents). They may also be dedicated to several or to all types
of operators.
3.2.5
diagnostic data
data that is located in the memory of an ECU which may be inspected and/or possibly modified by the
tester (diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate
values and various status information)
EXAMPLE — Examples of diagnostic data: vehicle speed, throttle angle, mirror position, system status, etc.
Two types of values are defined for diagnostic data:
— the current value: the value currently used by (or resulting from) the normal operation of the ECU;
— a stored value: an internal copy of the current value made at specific moments (e.g. when a
malfunction occurs or periodically); this copy is made under the control of the ECU. The ECU is not
obliged to keep internal copies of its data for diagnostic purposes, in which case the tester may only
request the current value.
3.2.6
diagnostic session
level of diagnostic functionality provided by the server
EXAMPLE — Defining a repair shop or development testing session selects different ECU functionality (e.g.
access to all memory locations may only be allowed in the development testing session).
3.2.7
diagnostic routine
routine that is embedded in an ECU and that may be started by a Server upon a request from the Client
EXAMPLE — It could either run instead of a normal operating program, or could be enabled in this mode and
executed with the normal operating program. In the first case, normal operation for the Server is not possible. In the
second case, multiple diagnostic routines may be enabled that run while all other parts of the ECU are functioning
normally.
3.2.8
record
one or more diagnostic data elements that are referred to together by a single means of identification
EXAMPLE — A snapshot including various input/output data and trouble codes is an example of a record.
3.2.9
freeze frame
record of datas stored at the occurrence of an event
3
---------------------- Page: 8 ----------------------
©
ISO
ISO 14229:1998(E)
NOTE — Services defined allow the tester to request data stored in a freeze frame.
EXAMPLE — A freeze frame may be used to store the context of the ECU's operation either at periodic moments
or at the occurrence of a malfunction. The Server may maintain several freeze frames (e.g. the same context may
be stored several times as a trace of the N latest malfunctions, or each freeze frame may consist of a different
context).
3.2.10
functional unit
set of functionally close or complementary diagnostic services
The following functional units have been identified:
- diagnostic management: this functional unit allows the initialization and the termination of a
sequence of diagnostic interchanges between a client and a server;
- data transmission: this functional unit allows a client to request the server for the current values of a
record. This functional unit may be used to request identification information;
- stored data transmission: this functional unit allows a client to request the server for the stored
values of a record (for instance, the diagnostic trouble codes). A server may store record values (either
periodically or at the occurrence of a malfunction) in a freeze frame. This freeze frame may be cleared
upon request from the client. If the server supports multiple freeze frames then the client may trace the
server's operation;
- input/output control: this functional unit allows the client to control the input and output peripherals of
the ECU where the server is present;
- remote activation of routine: this functional unit allows the client to control specific diagnostic
routines on the ECU where the server is present;
- upload download : this functional unit allows the client to control the transfer of large blocks of data to
or from the server.
3.3 Abbreviations
OSI Open Systems Interconnection.
ECU Electronic Control Unit.
EXAMPLE — Systems considered as electronic control units: anti-lock braking system (ABS), engine
management system, etc.
PID Parameter IDentifier.
4 Convention
4.1 Interactions
This International Standard is guided by the conventions adopted in the OSI service conventions
(ISO/IEC 10731) as they apply to the diagnostic services. These conventions specify the interactions
between the service user and the service provider. Information is passed between the service user and
the service provider by service primitives, which may convey parameters.
The distinction between service and protocol is shown in figure 3.
4
---------------------- Page: 9 ----------------------
©
ISO
ISO 14229:1998(E)
Figure 3 — Services and protocol
4.2 OSI service
This International Standard makes use of the following conventions defined in ISO/IEC 10731 as they
apply to the diagnostic services:
- Service primitive: a service is transferred to or from the diagnostic layer by passing a service primitive
across the layer interface.
- Service user: the service user is the diagnostic application which requests the service of the
diagnostic layer. For diagnostic services described in this International Standard, it is always the client.
- Service provider: the service provider is the diagnostic application which responds to the service
requested by the service user. For diagnostic services described in this International Standard, it is
always the server.
- Request primitive: the request transfers the service from the service user to the diagnostic layer.
- Indication primitive: the indication transfers the service from the diagnostic layer to the service
provider.
- Response primitive: the response transfers an answer to an indication primitive from the service
provider to the diagnostic layer.
- Confirmation primitive: the confirmation transfers an answer to a request primitive from the
diagnostic layer to the service user.
These conventions are shown in figure 4.
5
---------------------- Page: 10 ----------------------
©
ISO
ISO 14229:1998(E)
Figure 4 — Description of OSI service convention
4.3 Service description
This subclause defines the layout used to describe the diagnostic services. It includes:
- service purpose;
- service table;
- service procedure.
4.3.1 Service purpose
This subclause gives a brief outline of the functionality of the service.
4.3.2 Service table
The description of each service includes a table which lists the parameters of its primitives:
request/indication, response/confirmation for positive or negative result. All have the same structure. For
instance, table 1 shows the ReadDataByCommonIdentifier service table.
Table 1 — Example of service table
ReadDataByCommonIdentifier request M
Record common identifier M
Transmission mode U
ReadDataByCommonIdentifier positive response S
Record common identifier M
Record value M
ReadDataByCommonIdentifier negative response S
Response code M
1)
Record common identifier U
1)
Transmission mode U/C
1) Parameters of the request shall be repeated together.
C = condition: parameter may be present only if it was already in the request.
In all requests and responses, Client and Server Identifiers are mandatory, unless the service was
performed on a point-to-point communication. They are not shown in the table 1.
NOTE — The parameter Server Identifier may be included in the initialization phase for a point-to-point
communication (it will depend on the implementation).
6
---------------------- Page: 11 ----------------------
©
ISO
ISO 14229:1998(E)
Under the "Service name" request are listed the parameters specific to the service request/indication.
Under the "Service name" positive response are listed the parameters specific to the service
response/confirmation in case the requested service has succeeded.
Under the "Service name" negative response are listed the parameters specific to the service
response/confirmation in case the requested service has failed.
Parameters are indented under the service name.
For a given primitive, the presence of each parameter is described by one of the following values:
M mandatory;
U user option: the parameter shall or shall not be supplied, depending on dynamic usage by the
manufacturer;
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.3.3 Service procedure
This subclause provides a description of the actions performed by the client and the server.
4.4 Functional unit table
Similar services are grouped into a functional unit. The description of each functional unit includes a
table which lists its services.
5 Parameter specification
5.1 General purpose parameters
The structure of a service makes reference to parameters exchanged between server and client when
the service is in progress.
The parameters of general purpose are specified in this clause. Parameters specific to a functional unit
are specified in the corresponding clause.
This International Standard gives a list for some parameters (e.g. the response code parameter).
Outside this list, some other parameter may be reserved either for future definition in the revision of this
standard or for the system designer's specific use.
5.2 Server identifier
This parameter identifies a server. This clause neither specifies the list of possible server identifiers, nor
defines a specific means for the client to get this list.
EXAMPLE 1 — Example of server identifiers are : ABS, engine management system.
EXAMPLE 2 — A server (e.g. the engine control) may be implemented in one ECU or distributed in several ECUs.
An ECU may include only one server or several servers. At present, in most cases, a server is implemented in one
ECU, and there is only one server in each ECU.
7
---------------------- Page: 12 ----------------------
©
ISO
ISO 14229:1998(E)
5.3 Client identifier
This parameter identifies a client. This clause neither specifies the list of possible client identifiers, nor
defines a specific means for the server to get this list.
EXAMPLE — Example of client identifier: Scan tool.
5.4 Local identifier and common identifier
This subclause differentiates between local identifiers and common identifiers for the identification of a
record, input/output or routine.
A common identifier is understood in the same way by all servers supporting this identifier.
The interpretation of a local identifier is server-specific.
EXAMPLE — The parameter identifier (PID) used by SAE J2190 and SAE J1979 are a sub-set of the record
common identifier. For instance, in the SAE J1979 Recommended Practice, PID $0B identifies the intake manifold
absolute pressure for every system. This data could be assigned a specific local identifier on some systems.
5.5 Memory address and routine address
This parameter identifies a specific server memory or routine location. It contains all the necessary
information to address any memory or routine location including memory type (e.g. RAM, EEPROM,
etc.) or memory paging.
5.6 Response code
The response code parameter is used within the negative response to indicate that the server could not
complete the request.
The standard list for this parameter is described in the subclauses below.
5.6.1 General reject
The service is rejected but the server does not specify the reason of the rejection.
5.6.2 Service not supported
It indicates that the requested action will not be taken because the server does not support the
requested service.
EXAMPLE — The client requests a service of an advanced functional unit (e.g. data transfer) which is not
supported.
5.6.3 Subfunction not supported or invalid format
It indicates that the server does not support the arguments of the requested service or the format of the
argument bytes do not match the prescribed format for the specified service.
EXAMPLE — The client requests a ReadDataByLocalIdentifier service, but the specified record local identifier
value is not supported by this server.
8
---------------------- Page: 13 ----------------------
©
ISO
ISO 14229:1998(E)
5.6.4 Busy - RepeatRequest
The server has understood the service request, but it cannot execute at this time and will not start. In
order to get a positive response the client should repeat the request later.
EXAMPLE — This response code indicates that the server is temporarily too busy to perform the requested
operation. In this circumstance repetition of the request will eventually result in an affirmative response. This code
may be returned while a server is in the process of clearing stored codes or fetching information.
5.6.5 Conditions not correct or request sequence error
It indicates that the requested action will not be taken because the server prerequisite conditions are not
met. This request may elicit an affirmative response at another time. This code may occur when
sequence-sensitive requests are issued in the wrong order.
5.6.6 Routine Not Complete or Service In Progress
This response code is used to indicate that the message was properly received and the service is in
process, but not yet completed.
EXAMPLE — Whenever completion of the requested operation will exceed the maximum response time limit, it is
appropriate to use the routine Not Complete or Service In Progress response code to lengthen the acceptable
response period.
5.6.7 Request out of range
It indicates that the requested action will not be taken because the server detects the request message
contains a data byte which attempts to substitute a value beyond its range of authority.
EXAMPLE — Attempting to modify a data byte of 111 when the data is only defined to 100.
5.6.8 Security access denied
The service is rejected because the server's security strategy has not been satisfied by the client.
5.6.9 Invalid key
It indicates that security access has not been given because the server's security key was not matched
by the client (this counts as an attempt to gain security access).
5.6.10 Exceed number of attempts
It indicates that the requested action will not be taken because the client has unsuccessfully attempted
to g
...
NORME ISO
INTERNATIONALE 14229
Première édition
1998-07-15
Véhicules routiers — Systèmes de
diagnostic — Spécification des services de
diagnostic
Road vehicles — Diagnostic systems — Diagnostic services specification
A
Numéro de référence
ISO 14229:1998(F)
---------------------- Page: 1 ----------------------
ISO 14229:1998(F)
Sommaire Page
1 Domaine d'application . 1
2 Référence normative . 2
3 Définitions et abréviations . 2
3.1 Termes définis dans d'autres normes . 2
3.2 Définitions supplémentaires . 2
3.3 Abréviations . 4
4 Convention . 5
Interactions .
4.1 5
4.2 Service OSI . 5
4.3 Description du service . 6
4.4 Tableau d'unité fonctionnelle . 7
5 Spécification du paramètre . 7
5.1 Paramètres à usage général . 7
Identificateur de Serveur .
5.2 7
5.3 Identificateur de Client . 8
5.4 Identificateur local et identificateur commun . 8
5.5 Adresse de mémoire et adresse de programme . 8
5.6 Code de réponse . 8
5.7 Gestion des codes de réponse . 12
Unité fonctionnelle de gestion de diagnostic .
6 14
6.1 Généralités . 14
6.2 Service StartDiagnosticSession . 15
6.3 Service StopDiagnosticSession . 16
6.4 Service SecurityAccess . 17
6.5 Service TesterPresent . 18
6.6 Service ECUReset . 19
6.7 Service ReadECUIdentification . 19
6.8 Service DisableNormalMessageTransmission . 20
6.9 Service EnableNormalMessageTransmission . 21
7 Unité fonctionnelle transmission de données . 22
7.1 Services d'unité fonctionnelle . 22
7.2 Service ReadDataByLocalIdentifier . 24
Service ReadDataByCommonIdentifier .
7.3 25
7.4 Service ReadMemoryByAddress . 25
7.5 Service DynamicallyDefineLocalIdentifier . 26
7.6 Service WriteDataByLocalIdentifier . 29
© ISO 1998
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
---------------------- Page: 2 ----------------------
©
ISO ISO 14229:1998(F)
7.7 Service WriteDataByCommonIdentifier . 30
7.8 Service WriteMemoryByAddress . 31
7.9 Service SetDataRates . 31
7.10 Service StopRepeatedDataTransmission . 32
8 Unité fonctionnelle transmission de données enregistrées . 33
Généralités .
8.1 33
8.2 Service ReadDiagnosticTroubleCodes . 34
8.3 Service ReadDiagnosticTroubleCodesByStatus . 35
8.4 Service ReadStatusOfDiagnosticTroubleCodes . 36
8.5 Service ReadFreezeFrameData . 36
8.6 Service ClearDiagnosticInformation . 37
Unité fonctionnelle contrôle d'entrée/sortie .
9 38
9.1 Généralités . 38
9.2 Service InputOutputControlByLocalIdentifier . 39
9.3 Service InputOutputControlByCommonIdentifier . 40
10 Unité fonctionnelle télécommande de programme . 40
10.1 Généralités . 40
10.2 Service StartRoutineByLocalIdentifier . 42
10.3 Service StartRoutineByAddress . 43
10.4 Service StopRoutineByLocalIdentifier . 43
10.5 Service StopRoutineByAddress . 44
10.6 Service RequestRoutineResultsByLocalIdentifier . 45
10.7 Service RequestRoutineResultsByAddress . 45
11 Unité fonctionnelle téléchargement satellite-central/central-satellite . 46
Généralités .
11.1 46
11.2 Service RequestDownload . 47
11.3 Service RequestUpload . 47
11.4 Service TransferData . 48
11.5 Service RequestTransferExit . 49
12 Exemples . 49
Annexe A (informative) Bibliographie . 51
iii
---------------------- Page: 3 ----------------------
©
ISO 14229:1998(F) 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 14229 a été élaborée par le comité technique ISO/TC 22, Véhicules
routiers, sous-comité SC 3, Équipement électrique et électronique.
L'annexe A de la présente Norme internationale est donnée uniquement à titre d'information.
iv
---------------------- Page: 4 ----------------------
©
ISO ISO 14229:1998(F)
Introduction
La présente Norme internationale a été établie afin de définir les prescriptions communes des systèmes
de diagnostic, quelle que soit la 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) conformément à l'ISO 7498 qui structure les systèmes de communication en sept
couches. Lorsqu'ils sont mappés selon ce modèle, les services utilisés par un outil de diagnostic et une
Unité de Contrôle Électronique (UCE) se divisent en
— services de diagnostic (couche 7);
— services de communication (couches 1 à 6), conformément à la figure 1.
Figure 1 — Mappage des services de diagnostic selon le modèle OSI
La présente Norme internationale contient des références aux publications SAE, qui sont régulièrement
amendées/mises à jour, sans changement visible (ni dans la numérotation, ni dans une lettre
supplémentaire, etc.) Pour s'assurer précisément à quelle édition particulière la présente norme se
réfère, l'annexe A donne les dates précises de ces publications SAE.
v
---------------------- Page: 5 ----------------------
©
NORME INTERNATIONALE ISO ISO 14229:1998(F)
Véhicules routiers — Systèmes de diagnostic —
Spécification des services de diagnostic
1 Domaine d'application
La présente Norme internationale spécifie les prescriptions communes des services de diagnostic qui
permettent à un outil de diagnostic de contrôler les fonctions de diagnostic dans une Unité de Contrôle
Électronique (UCE) embarquée (par exemple, injection électronique de carburant, boîte de vitesse
automatique, système de freinage antibloqueur, etc.) connectée à une liaison de données série intégrée
à un véhicule routier.
Elle spécifie les services génériques qui permettent à l'outil de diagnostic d'arrêter ou de reprendre la
transmission de messages non diagnostic sur la liaison de données.
La présente Norme internationale ne s'applique pas à la transmission de messages non relatifs au
diagnostic, ni à l'utilisation de la liaison de données de communication entre deux UCE.
La présente Norme internationale ne spécifie pas non plus les prescriptions de mise en œuvre, les
valeurs numériques des services et paramètres, ni les prescriptions des services de communication.
L'architecture de diagnostic du véhicule de la présente Norme internationale s'applique à
— un outil de diagnostic unique pouvant être, de manière temporaire ou permanente, connecté à la
liaison de données de diagnostic embarquée et
— plusieurs UCE embarquées connectées directement ou indirectement.
Voir la figure 2.
Dans le véhicule 1, les UCE sont connectées sur une liaison de données interne et indirectement connectées à la liaison de
données de diagnostic par le biais d'une passerelle. La présente Norme internationale s'applique aux communications de
diagnostic sur la liaison de données de diagnostic; les communications de diagnostic sur la liaison de données interne peuvent
être conformes à la présente Norme internationale ou à un autre protocole.
Dans le véhicule 2, les UCE sont directement connectées à la liaison de données de diagnostic.
Figure 2 — Architecture de diagnostic d'un véhicule
1
---------------------- Page: 6 ----------------------
©
ISO 14229:1998(F) ISO
2 Référence normative
La norme suivante contient des dispositions qui, par suite de la référence qui en est faite, constituent
des dispositions valables pour la présente Norme internationale. Au moment de la publication, l'édition
indiquée était en vigueur. Toute norme est sujette à révision et les parties prenantes des accords fondés
sur la présente Norme internationale sont invitées à rechercher la possibilité d'appliquer l'édition la plus
récente de la norme indiquée 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/CEI 10731:1994, Technologies de l'information — Interconnexion de systèmes ouverts (OSI) —
Modèle de référence de base — Conventions pour la définition des services OSI.
3 Définitions et abréviations
3.1 Termes définis dans d'autres normes
3.1.1
type
ensemble de valeurs nommé
3.1.2
type de chaîne binaire
type dont les valeurs sont des chaînes (séquences) de bits
NOTE — Le type de chaîne binaire est utilisé si aucune fourchette n'est définie, à l'exception du nombre de
bits utilisés (par exemple les codes d'anomalie de diagnostic peuvent être représentés par une séquence
binaire).
3.1.3
type entier
type simple avec des valeurs distinctes qui sont les nombres entiers positifs et négatifs, incluant zéro
NOTE — La gamme de type entier n'est pas spécifiée.
3.1.4
code d'anomalie de diagnostic
identificateur commun numérique d'une panne identifiée par le système de diagnostic embarqué
[SAE J1930]
3.2 Définitions supplémentaires
3.2.1
service de diagnostic
échange d'informations lancé par un Client afin d'exiger des informations de diagnostic d'un Serveur
et/ou de modifier son comportement à des fins de diagnostic
3.2.2
Client
fonction faisant partie de l'outil de diagnostic et qui utilise les services de diagnostic
NOTE — Normalement, un testeur utilise d'autres fonctions telles que la gestion de base de données,
l'interprétation spécifique, l'interface homme-machine.
3.2.3
Serveur
fonction faisant partie d'une UCE et qui fournit les services de diagnostic
2
---------------------- Page: 7 ----------------------
©
ISO ISO 14229:1998(F)
NOTE — La présente Norme internationale distingue le Serveur (c'est-à-dire la fonction) de l'UCE, de sorte
qu'elle demeure indépendante de la mise en œuvre.
3.2.4
outil de diagnostic
système qui commande les fonctions telles que l'essai, le contrôle, la surveillance ou le diagnostic d'une
UCE embarquée
NOTE — Les outils de diagnostic peuvent être spécialisés pour un type d'opérateurs spécifique (par
exemple un outil d'analyse spécialisé dans la mécanique ou un outil d'essai destiné aux ouvriers de chaîne
de montage). Ils peuvent également être spécialisés pour tout ou partie des types d'opérateurs.
3.2.5
données de diagnostic
données situées dans la mémoire d'une UCE pouvant être contrôlée et/ou éventuellement modifiée par
l'outil de diagnostic (les données de diagnostic comprennent les entrées et sorties analogiques, les
entrées et sorties numériques, les valeurs intermédiaires et les informations de statut varié)
EXEMPLE — Exemples de données de diagnostic: vitesse du véhicule, angle d'accélérateur, position du
rétroviseur, état du système, etc.
Deux types de valeurs sont définis pour les données de diagnostic:
— la valeur en cours: valeur actuellement utilisée par le (ou résultant du) fonctionnement normal de
l'UCE;
— une valeur stockée: copie interne de la valeur en cours à des moments spécifiques (par exemple
lorsqu'un dysfonctionnement intervient ou de manière périodique); cette copie est effectuée sous le
contrôle de l'UCE. L'UCE ne doit pas nécessairement conserver les copies internes de ses données
à des fins de diagnostic et, dans ce cas, l'outil peut uniquement demander la valeur en cours.
3.2.6
session de diagnostic
niveau de fonctionnalité de diagnostic fourni par le Serveur
EXEMPLE — Définir un atelier de réparations où une session d'essai de développement sélectionne une
fonctionnalité UCE différente (par exemple, l'accès à toutes les adresses de mémoire peut uniquement être
autorisé lors d'une session d'essai de développement).
3.2.7
programme de diagnostic
programme intégré à une UCE et pouvant être mis en route par un Serveur à la demande du Client
EXEMPLE — Il peut fonctionner à la place d'un programme de fonctionnement normal, ou peut être activé
dans ce mode et exécuté avec le programme de fonctionnement normal. Dans le premier cas, le
fonctionnement normal du Serveur n'est pas possible. Dans le second cas, des programmes multiples de
diagnostic peuvent être activés de cette façon, alors que toutes les autres parties de l'UCE fonctionnent
normalement.
3.2.8
enregistrement
un ou plusieurs éléments de données de diagnostic désignés ensemble par un moyen unique
d'identification
EXEMPLE — Un instantané comprenant différentes données d'entrée/sortie et des codes d'anomalie est un
exemple d'enregistrement.
3
---------------------- Page: 8 ----------------------
©
ISO 14229:1998(F) ISO
3.2.9
trame fixe
enregistrement de données stockées lors d'un événement
NOTE — Les services définis permettent à l'outil de diagnostic de demander des données mises en
mémoire dans une trame fixe.
EXEMPLE — Une trame fixe peut permettre de stocker le contexte du fonctionnement de l'UCE
périodiquement ou lors d'un dysfonctionnement. Le Serveur peut maintenir plusieurs images fixes (par
exemple le même contexte peut être plusieurs fois mis en mémoire sous forme d'une trace des N
dysfonctionnements les plus récents, ou chaque trame fixe peut se composer d'un contexte différent).
3.2.10
unité fonctionnelle
ensemble de services de diagnostic complémentaires ou fonctionnellement proches
Les unités de fonctionnement suivantes ont été identifiées:
— gestion de diagnostic: cette unité fonctionnelle permet l'initialisation et la fin d'une séquence
d'échanges de diagnostic entre un Client et un Serveur;
— transmission de données: cette unité fonctionnelle permet à un Client de demander au Serveur
les valeurs en cours d'un enregistrement. Cette unité fonctionnelle peut être utilisée pour demander
des informations d'identification;
— transmission de données stockées: cette unité fonctionnelle permet à un Client de demander au
Serveur les valeurs stockées d'un enregistrement (par exemple les codes d'anomalie de diagnostic).
Un Serveur peut stocker des valeurs d'enregistrement (périodiquement ou lors d'un
dysfonctionnement ) dans une trame fixe. Cette trame fixe peut être supprimée à la demande du
Client. Si le Serveur supporte des images fixes multiples, le Client peut analyser le fonctionnement
du Serveur;
— contrôle entrée/sortie: cette unité fonctionnelle permet au Client de contrôler les périphériques
d'entrée et de sortie de l'UCE où le Client est présent;
— activation à distance de programme: cette unité fonctionnelle permet au Client de contrôler les
programmes de diagnostic spécifiques sur l'UCE où le Serveur est présent;
— téléchargement central-satellite/satellite-central: cette unité fonctionnelle permet au Client de
contrôler le transfert de grands blocs de données vers le Serveur, ou à partir du Serveur.
3.3 Abréviations
OSI Interconnexion de systèmes ouverts (Open Systems Interconnection)
UCE Unité de contrôle électronique (Electronic Control Unit)
EXEMPLE — Systèmes considérés comme unités de contrôle électronique: système de freinage
antibloqueur (ABS), système de gestion mécanique, etc.
PID Identificateur de paramètre
4
---------------------- Page: 9 ----------------------
©
ISO ISO 14229:1998(F)
4 Convention
4.1 Interactions
La présente Norme internationale est guidée par les conventions adoptées dans les conventions du
service OSI (ISO/CEI 10731) dans la mesure où elles s'appliquent aux services de diagnostic. Ces
conventions spécifient les interactions entre l'utilisateur et le fournisseur de service. Les informations
circulent entre l'utilisateur et le fournisseur de service par le biais des primitives de service, qui elles-
mêmes peuvent acheminer des paramètres.
La différence entre service et protocole est résumée à la figure 3.
Figure 3 — Services et protocole
4.2 Service OSI
La présente Norme internationale utilise les conventions suivantes définies dans l'ISO/CEI 10731, dans
la mesure où elles s'appliquent aux services de diagnostic:
— primitive de service: un service est transféré vers, ou à partir de la couche de diagnostic en
passant par une primitive de service à travers l'interface de couche;
— utilisateur de service: l'utilisateur de service est l'application de diagnostic qui demande le service
de la couche de diagnostic. Pour les services de diagnostic décrits dans la présente Norme
internationale, il s'agit toujours du Client;
— fournisseur de service: le fournisseur de service est l'application de diagnostic qui répond au
service demandé par l'utilisateur de service. Pour les services de diagnostic décrits dans la présente
Norme internationale, il s'agit toujours du Serveur;
— primitive de demande: la demande transfère le service de l'utilisateur de service à la couche de
diagnostic;
— primitive d'indication: l'indication transfère le service de la couche de diagnostic au fournisseur de
service;
— primitive de réponse: la réponse transfère une réponse à une primitive d'indication du fournisseur
de service à la couche de diagnostic;
— primitive de confirmation: la confirmation transfère un réponse à une primitive de demande de la
couche de diagnostic à l'utilisateur de service.
Ces conventions sont résumées à la figure 4.
5
---------------------- Page: 10 ----------------------
©
ISO 14229:1998(F) ISO
Figure 4 — Description de la convention du service OSI
4.3 Description du service
Ce paragraphe définit le plan utilisé pour décrire les services de diagnostic. Il comprend
— l'objectif du service;
— le tableau du service;
— la procédure du service.
4.3.1 Objectif du service
Ce paragraphe donne un bref aperçu de la fonctionnalité du service.
4.3.2 Tableau du service
La description de chaque service comprend un tableau qui répertorie les paramètres de ses primitives:
demande/indication, réponse/confirmation pour un résultat positif ou négatif. Tous ont la même
structure. Par exemple, le tableau 1 représente le tableau du service ReadDataByCommoIdentifier.
Tableau 1 — Exemple de tableau du service
Demande ReadDataByCommonIdentifier M
(lire données par identificateur commun)
Identificateur commun d'enregistrement M
Mode de transmission U
S
Réponse Positive ReadDataByCommonIdentifier
M
Identificateur commun d'enregistrement
M
Valeur d'enregistrement
S
Réponse Négative ReadDataByCommonIdentifier
M
Code de réponse
1)
Identificateur commun d'enregistrement U
1)
Mode de transmission U/C
1) Les paramètres de la demande doivent être répétés ensemble.
C = condition: le paramètre ne peut être présent que s'il l'était déjà
dans la demande.
6
---------------------- Page: 11 ----------------------
©
ISO ISO 14229:1998(F)
Dans toutes les demandes et réponses, les identificateurs de Client et de Serveur sont obligatoires, à
moins que le service soit exécuté sur une communication point à point. Ils ne sont pas représentés dans
le tableau 1.
NOTE — Le paramètre identificateur de Serveur peut être inclus dans la phase d'initialisation pour une
communication point à point (il dépend de la mise en œuvre).
Sous Demande de "nom de service" sont listés les paramètres spécifiques à la demande/indication du
service.
Sous Réponse positive de "nom de service" sont listés les paramètres spécifiques à la
réponse/confirmation du service si le service demandé a réussi.
Sous Réponse négative de "nom de service" sont listés les paramètres spécifiques à la
réponse/confirmation du service si le service demandé a échoué.
Les paramètres sont inscrits en retrait sous le nom du service.
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 doit ou ne doit pas être fourni, selon l'utilisation dynamique
du constructeur;
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.
4.3.3 Procédure du service
Ce paragraphe donne une description des opérations effectuées par le Client et le Serveur.
4.4 Tableau d'unité fonctionnelle
Des services similaires sont groupés en une unité fonctionnelle. La description de chaque unité
fonctionnelle comprend un tableau qui répertorie ses services.
5 Spécification du paramètre
5.1 Paramètres à usage général
La structure d'un service fait référence aux paramètres échangés entre le Serveur et le Client lorsque le
service est en cours.
Les paramètres à usage général sont spécifiés dans le présent paragraphe. Les paramètres spécifiques
à une unité fonctionnelle sont spécifiés dans le paragraphe correspondant.
La présente Norme internationale donne une liste concernant certains paramètres (par exemple le
paramètre code de réponse). En dehors de cette liste, certains autres paramètres peuvent être réservés
pour une définition ultérieure dans le cadre d'une révision de la présente Norme internationale, ou pour
l'utilisation spécifique du concepteur de système.
7
---------------------- Page: 12 ----------------------
©
ISO 14229:1998(F) ISO
5.2 Identificateur de Serveur
Ce paramètre identifie un Serveur. Le présent paragraphe ne spécifie pas la liste d'éventuels
identificateurs de Serveurs, ni ne définit un moyen d'obtenir cette liste par le Client.
EXEMPLE 1 — Les exemples d'identificateurs de Serveur sont: ABS, système de gestion mécanique.
EXEMPLE 2 — Un Serveur (par exemple la commande du moteur) peut être mis en œuvre dans une UCE
ou distribué dans plusieurs UCE. Une UCE peut uniquement inclure un ou plusieurs Serveurs. A l'heure
actuelle, un Serveur est, dans la plupart des cas, mis en œuvre dans une UCE; il ne peut y avoir qu'un
Serveur dans chaque UCE.
5.3 Identificateur de Client
Ce paramètre identifie un Client. Le présent paragraphe ne spécifie pas la liste d'éventuels
identificateurs de Clients, ni ne définit un moyen d'obtenir cette liste par le Serveur.
EXEMPLE — Exemple d'identificateur de Client: outil d'analyse.
5.4 Identificateur local et identificateur commun
Le présent paragraphe fait une distinction entre les identificateurs locaux et communs pour
l'identification d'un enregistrement, d'une entrée/sortie ou d'un programme.
Un identificateur commun est compris de la même façon par tous les Serveurs supportant cet
identificateur.
L'interprétation d'un identificateur local est spécifique au Serveur.
EXEMPLE — L'identificateur de paramètre (PID) utilisé dans les documents SAE J2190 et SAE J1979 est
un sous-ensemble de l'identificateur commun d'enregistrement. Par exemple, dans le SAE J1979
Recommended Practice, PID $0B identifie la pression absolue du collecteur d'admission pour chaque
système. Un identificateur local peut être attribué à ces données sur certains systèmes.
5.5 Adresse de mémoire et adresse de programme
Ce paramètre identifie une mémoire de Serveur spécifique ou une adresse de programme. Il contient
toutes les informations nécessaires pour accéder à toute adresse de mémoire ou de programme
incluant le type de mémoire (par exemple RAM, EEPROM, etc.) ou l'organisation en page.
5.6 Code de réponse
Le paramètre code de réponse est utilisé dans la réponse négative pour indiquer que le Serveur ne peut
pas terminer la demande.
La liste usuelle concernant ce paramètre est décrite dans les paragraphes ci-dessous.
5.6.1 Refus général
Le service est refusé mais le Serveur n'en précise pas la raison.
8
---------------------- Page: 13 ----------------------
©
ISO ISO 14229:1998(F)
5.6.2 Service non supporté
Il indique que l'opération demandée n'est pas effectuée car le Serveur ne supporte pas le service
demandé.
EXEMPLE — Le Client demande un service d'une unité fonctionnelle évoluée (par exemple transfe
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.