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
- Status
- Withdrawn
- Publication Date
- 15-Jul-1998
- Withdrawal Date
- 15-Jul-1998
- Technical Committee
- ISO/TC 22 - Road vehicles
- Drafting Committee
- ISO/TC 22 - Road vehicles
- Current Stage
- 9599 - Withdrawal of International Standard
- Start Date
- 28-Nov-2006
- Completion Date
- 13-Dec-2025
Relations
- Effective Date
- 15-Apr-2008
- Effective Date
- 15-Apr-2008
ISO 14229:1998 - Road vehicles -- Diagnostic systems -- Diagnostic services specification
ISO 14229:1998 - Véhicules routiers -- Systemes de diagnostic -- Spécification des services de diagnostic
Frequently Asked Questions
ISO 14229:1998 is a standard published by the International Organization for Standardization (ISO). Its full title is "Road vehicles - Diagnostic systems - Diagnostic services specification". This standard covers: Road vehicles - Diagnostic systems - Diagnostic services specification
Road vehicles - Diagnostic systems - Diagnostic services specification
ISO 14229:1998 is classified under the following ICS (International Classification for Standards) categories: 43.180 - Diagnostic, maintenance and test equipment. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 14229:1998 has the following relationships with other standards: It is inter standard links to ISO/PRF 14229-1, ISO 14229-1:2006. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO 14229:1998 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
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
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
©
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
©
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
©
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
©
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
©
ISO
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.
©
ISO
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
©
ISO
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.
©
ISO
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.
©
ISO
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).
©
ISO
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.
©
ISO
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.
©
ISO
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 gain security access more times than the server's security strategy will allow.
5.6.11 Required time delay not expired
It indicates that the requested action will not be taken because the client’s latest attempt to gain security
access was initiated before the server’s required time-out period had elapsed.
5.6.12 Download not accepted
This response code indicates that an attempt to download to a server's memory cannot be accomplished
due to some fault condition.
©
ISO
5.6.13 Improper download type
This response code indicates that an attempt to download to a server's memory cannot be accomplished
because the server does not support the type of download being attempted.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.14 Can’t Download to specified address
This response code indicates that an attempt to download to a server's memory cannot be accomplished
because the server does not recognise the target address for the download as being available.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload / download protocol.
5.6.15 Can’t download number of bytes requested
This response code indicates that an attempt to download to a server's memory cannot be accomplished
because the server does not recognise the number of bytes requested for the download as being
available.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.16 Upload not accepted
This response code indicates that an attempt to upload from a server's memory cannot be accomplished
due to some fault condition.
5.6.17 Improper upload type
This response code indicates that an attempt to upload from a server's memory cannot be accomplished
because the server does not support the type of upload being attempted.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.18 Can’t upload from specified address
This response code indicates that an attempt to upload from a server's memory cannot be accomplished
because the server does not recognise the target address for the upload as being available.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.19 Can’t upload number of bytes requested
This response code indicates that an attempt to upload from an server's memory cannot be
accomplished because the server does not recognise the number of bytes requested for the upload as
being available.
©
ISO
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.20 Transfer suspended
This response code indicates that a block transfer operation was halted due to some fault, but will be
completed later.
5.6.21 Transfer aborted
This response code indicates that a block transfer operation was halted due to some fault, and will not
be completed later.
5.6.22 Illegal address in block transfer
This response code indicates that the starting address included in the block transfer request message is
either out of range, protected, the wrong type of memory for receiving data, or cannot be written to for
some reason.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.23 Illegal byte count in block transfer
This response code indicates that the number of data bytes included in the block transfer request
message is either more than the block transfer can accommodate, requires more memory than is
available at the requested starting address, or cannot be handled by the block transfer software.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.24 Illegal block transfer type
This response code is used to indicate that the block transfer type included in the request for block
transfer is not valid for this application.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.25 Block transfer data checksum error
This response code is used to indicate that the block transfer data checksum calculated for the block
transfer message does not agree with the expected value.
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.26 Incorrect byte count during block transfer
This response code indicates that the number of bytes that was expected to be sent was not the same
as the number of bytes received.
©
ISO
This code corresponds to parameters of the upload/download functional unit which are not defined in
this International Standard but which are likely to be used by manufacturers. Its definition shall therefore
be completed by the manufacturer depending on its specific upload/download protocol.
5.6.27 Request correctly received - Response pending
This response code is used to indicate that the message was received correctly, and that any
parameters included in the message were valid, but the action to be performed may not be completed
yet. This response code can be used to indicate that the message was properly received and shall not
be re-transmitted, but the receiving device is not yet ready to receive another request message.
5.6.28 Manufacturer specific codes
These response codes are reserved to be specified by the vehicle manufacturer.
5.7 Response code handling
Figure 5 specifies the server behaviour on a client request message. This figure shows the logic as
specified in the description of the response codes and to be implemented in the server and client as
appropriate.
6 Diagnostic management functional unit
6.1 General
6.1.1 Table 2 describes the diagnostic management functional unit.
Table 2 — Diagnostic management functional unit
Service name Description
StartDiagnosticSession The client requests to start a diagnostic session with a
specific server
StopDiagnosticSession The client requests to stop the current diagnostic
session
SecurityAccess The client requests to unlock a secured server
TesterPresent The client indicates to the server that it is still present
ECUReset The client forces the server to perform a reset.
ReadECUIdentification The client requests identification data from the server
DisableNormalMessageTransmission The client requests the server to stop transmitting non-
diagnostic messages
EnableNormalMessageTransmission The client requests the server to resume transmitting
non-diagnostic messages
NOTE — It is recalled that:
- the client is the function of the tester that makes use of the diagnostic services.
- the server is the function of the on-vehicle ECU that provides the diagnostic services.
6.1.2 The services of this functional unit make use of the following parameters:
Diagnostic mode
This parameter is used by the StartDiagnosticSession service to select the diagnostic session (specific
behaviour of the server). This International Standard neither specifies the list for this parameter, nor
defines a specific means for the server to get this list.
EXAMPLES — Repair shop, on-line, manufacturer specific, regulation, etc.
©
ISO
Figure 5 — Server positive and negative response message behaviour
©
ISO
Access mode
This parameter is used in the SecurityAccess service. It indicates to the server the step in progress for
this service, the level of security the client wants to access and the format of seed and key. Two values
are defined for the step in progress: Request seed and Send key.
Key
This parameter is used by the SecurityAccess service to unlock a server.
The key is computed by the client from the seed and sent to the server which compares it to its own
calculation result.
Seed
This parameter is used by the SecurityAccess service to unlock a server.
The seed is supplied by the server in response to a request for security access by the client.
Security Access status
This parameter is used by the SecurityAccess service to indicate positive response to a request. It
indicates that the server’s security strategy has been satisfied by the client.
One value is defined for this parameter: Security access allowed along with a range of manufacturer-
specific-values.
Response required
This parameter is used in the TesterPresent service.
Two values are defined: Yes, No.
Reset mode
This parameter is used by the ECUReset service to describe how the server has to perform the reset.
The possible values are:
Power on: the state of the server after the performance of the reset shall be the same as if the
power supply is switched off and on again.
Power on while maintaining the communication: the state of the server after the performance of the
reset shall be the same as if the power supply is switched off and on again; furthermore the
communication link between the client and the server is maintained.
Manufacturer-specific: this reset mode value is manufacturer defined.
Reset status
This parameter is used by the ECUReset service to give to the client information about the status of the
requested reset.
Identification option
This parameter is used by the ReadECUIdentification service to describe the kind of identification data
requested by the client.
Transmission level
This parameter is used by the DisableNormalMessageTransmission service. The structure of this
parameter is manufacturer specific.
©
ISO
6.2 StartDiagnosticSession service
6.2.1 Service purpose
The purpose of this service is to switch the server from the previous operating mode (normal operation
or previous diagnostic mode) to a new diagnostic mode (e.g. repair shop, on-line, manufacturer, etc.).
6.2.2 Service table
Table 3 defines the StartDiagnosticSession service
Table 3 — StartDiagnosticSession service
M
StartDiagnosticSession request
Diagnostic mode M
S
StartDiagnosticSession positive response
Diagnostic mode U
S
StartDiagnosticSession negative response
Response code M
Diagnostic mode U
6.2.3 Service procedure
Upon receiving a StartDiagnosticSession service indication primitive, the server shall check that the
conditions for starting the diagnostic session are valid. These conditions are not specified.
If valid, it will issue a StartDiagnosticSession response primitive with the positive response parameters.
If not, the server will issue a StartDiagnosticSession response primitive with the negative response
parameters.
The following is valid:
— System designers have the flexibility to use a StartDiagnosticSession service to stop a previous
session and start a new one. If the diagnostic mode requested by the client is the same as the
current one, the server shall continue the active diagnostic session.
— The on-board devices may need to alter their normal operation in order for the diagnostic
procedures to be effective. One example is that the system may need to reduce the amount of data
being sent on the data link to make more time available for the diagnostic messages. Another
possibility is that the system may need to degrade its normal operation in order to be able to process
the diagnostic requests. Systems that rely on data from modules being diagnosed may not receive
data from those modules as frequently as normal.
— This mechanism may be used to prevent a diagnostic session from timing-out.
6.3 StopDiagnosticSession service
6.3.1 Service purpose
The purpose of this service is to allow the server to terminate correctly the current diagnostic session
(e.g. to perform some preventive actions) and to switch to the normal operation.
©
ISO
6.3.2 Service table
Table 4 defines the StopDiagnosticSession service.
Table 4 — StopDiagnosticSession service
StopDiagnosticSession request M
S
StopDiagnosticSession positive response
StopDiagnosticSession negative response S
Response code M
6.3.3 Service procedure
Upon receiving a StopDiagnosticSession service indication primitive, the server shall check if a
diagnostic session is currently running. In this case, it shall stop the current diagnostic session, that is,
perform the necessary action to return to a state in which it may restore its normal operating conditions.
Then it shall issue a StopDiagnosticSession response primitive with the positive response parameters
selected.
If it is not possible to execute the service, the server shall issue a StopDiagnosticSession response
primitive with the negative response parameters selected.
EXAMPLE — Restoring the normal operating conditions of the server may include:
— resuming normal message transmission if they have been stopped by the client du
...
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
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
©
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
©
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
©
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
©
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
©
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
©
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.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
©
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.
©
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.
©
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.
©
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.
©
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 transfert de
données) qui n'est pas supporté.
5.6.3 Sous-fonction non supportée ou format incorrect
Il indique que le Serveur ne supporte pas les arguments du service demandé ou que le format des
octets d'argument ne correspond pas au format prescrit pour le service spécifié.
EXEMPLE — Le Client demande un service ReadDataByLocalIdentifier, mais la valeur spécifiée de
l'identificateur local d'enregistrement n'est pas supportée par ce Serveur.
5.6.4 Occupé - Répéter demande
Le Serveur a compris la demande de service, mais ne peut pas l'exécuter à ce moment-là et ne veut
pas démarrer. Pour obtenir une réponse positive, le Client doit répéter la demande plus tard.
EXEMPLE — Ce code de réponse indique que le Serveur est temporairement trop occupé pour effectuer
l'opération demandée. Dans ce cas-là, la répétition de la demande finit par se transformer en une réponse
affirmative. Ce code peut être renvoyé pendant que le Serveur est en cours d'effacement des codes mis en
mémoire ou de recherche d'information.
5.6.5 Conditions non correctes ou erreur de séquence de demande
Il indique que l'opération demandée n'est pas effectuée car les conditions préalables ne sont pas
remplies. Cette demande peut obtenir une réponse affirmative à un autre moment. Ce code peut
intervenir lorsque des demandes confidentielles de séquence sont émises dans le désordre.
5.6.6 Programme non terminé ou service en cours
Ce code de réponse est utilisé pour indiquer que le message a été correctement reçu et que le service
est en cours, mais n'est pas encore terminé.
EXEMPLE — Chaque fois que la fin de l'opération demandée dépasse la limite maximale du temps de
réponse, il est pertinent d'utiliser le code de réponse Programme non terminé ou Service en cours, afin de
prolonger la période de réponse acceptable.
5.6.7 Demande hors de portée
Il indique que l'opération demandée n'est pas effectuée car le Serveur détecte que le message de
demande contient un octet de données qui essaie de substituer une valeur au-delà de ses
compétences.
EXEMPLE — Tenter de modifier un octet de données de 111 lorsque les données sont uniquement définies
jusqu'à 100.
5.6.8 Accès sécurité refusé
Ce service est refusé car la stratégie de sécurité du Serveur n'a pas été satisfaite par le Client.
5.6.9 Clé incorrecte
Il indique que l'accès de sécurité n'a pas été donné car la clé de sécurité du Serveur ne correspond pas
à celle du Client (cela compte comme tentative d'obtenir un accès de sécurité).
©
5.6.10 Nombre excessif de tentatives
Il indique que l'opération demandée n'est pas effectuée car le Client n'a pas réussi à obtenir un accès
de sécurité plus souvent que ne l'autorise la stratégie de sécurité du Serveur.
5.6.11 Retard requis non expiré
Il indique que l'opération demandée n'est pas effectuée car la dernière tentative du Client pour obtenir
un accès de sécurité a été lancée avant la fin de la période de temporisation requise du Serveur.
5.6.12 Téléchargement (central-satellite) non accepté
Ce code de réponse indique qu'une tentative de téléchargement vers une mémoire de Serveur ne peut
être effectuée pour cause de défaillance.
5.6.13 Type de téléchargement (central-satellite) incorrect
Ce code de réponse indique qu'une tentative de téléchargement vers une mémoire de Serveur ne peut
être effectuée car le Serveur ne supporte pas ce type de téléchargement.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.14 Téléchargement (central-satellite) impossible vers l'adresse spécifiée
Ce code de réponse indique qu'une tentative de téléchargement central-satellite vers une mémoire de
Serveur ne peut être effectuée car le Serveur ne reconnaît pas l'adresse cible comme disponible pour le
téléchargement.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.15 Téléchargement (central-satellite) du nombre d'octets requis impossible
Ce code de réponse indique qu'une tentative de téléchargement central-satellite vers une mémoire de
Serveur ne peut être effectuée car le Serveur ne reconnaît pas le nombre d'octets requis comme
disponible pour le téléchargement.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.16 Téléchargement (satellite-central) non accepté
Ce code de réponse indique qu'une tentative de téléchargement satellite-central à partir d'une mémoire
de Serveur ne peut être effectuée en raison d'une anomalie.
5.6.17 Type de téléchargement (satellite-central) incorrect
Ce code de réponse indique qu'une tentative de téléchargement satellite-central à partir d'une mémoire
de Serveur ne peut être effectuée car le Serveur ne supporte pas ce type de téléchargement.
©
ISO ISO 14229:1998(F)
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.18 Téléchargement impossible (satellite-central) à partir de l'adresse spécifiée
Ce code de réponse indique qu'une tentative de téléchargement satellite-central à partir d'une mémoire
de Serveur ne peut être effectuée car le Serveur ne reconnaît pas l'adresse cible comme disponible
pour le téléchargement.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.19 Téléchargement (satellite-central) du nombre d'octets requis impossible
Ce code de réponse indique qu'une tentative de téléchargement satellite-central à partir d'une mémoire
de Serveur ne peut être effectuée car le Serveur ne reconnaît pas le nombre d'octets requis comme
disponible pour le téléchargement.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.20 Transfert suspendu
Ce code de réponse indique qu'une opération de transfert par blocs a été arrêtée en raison d'une
défaillance, mais sera terminée plus tard.
5.6.21 Transfert interrompu
Ce code de réponse indique qu'une opération de transfert par blocs a été arrêtée en raison d'une
défaillance et ne sera pas terminée ultérieurement.
5.6.22 Adresse illégale dans le transfert par blocs
Ce code de réponse indique que l'adresse de départ incluse dans le message de demande de transfert
par blocs est hors de portée, protégée, le mauvais type de mémoire pour recevoir des données, ou ne
peut pas être enregistrée pour une raison quelconque.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.23 Compte d'octets illégal dans le transfert par blocs
Ce code de réponse indique que le nombre d'octets de données inclus dans le message de demande
de transfert par blocs est supérieur à ce que le transfert par blocs peut recevoir, nécessite davantage de
mémoire que celle disponible au niveau de l'adresse de départ, ou ne peut pas être acheminé par le
logiciel de transfert par blocs.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
©
5.6.24 Type de transfert par blocs illégal
Ce code de réponse permet d'indiquer que le type de transfert par blocs inclus dans la demande de
transfert par blocs n'est pas correct pour cette application.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.25 Erreur de total de contrôle de transfert par blocs
Ce code de réponse permet d'indiquer que le total de contrôle de données de transfert par blocs calculé
pour le message de transfert par blocs ne correspond pas à la valeur prévue.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.26 Compte d'octets incorrect au cours du transfert par blocs
Ce code de réponse indique que le nombre d'octets prévus pour l'émission n'est pas le même que le
nombre d'octets reçus.
Ce code correspond aux paramètres de l'unité fonctionnelle de téléchargement satellite-central/central-
satellite qui ne sont pas définis dans la présente Norme internationale, mais qui sont susceptibles d'être
utilisés par les constructeurs. Sa définition doit, par conséquent, être complétée par le constructeur en
fonction de son protocole spécifique de téléchargement satellite-central/central-satellite.
5.6.27 Demande correctement reçue - Réponse en attente
Ce code de réponse permet d'indiquer que le message a été reçu correctement et que tous les
paramètres inclus dans le message sont corrects, mais que l'opération à effectuer ne peut pas encore
être terminée. Ce code de réponse peut permettre d'indiquer que le message est correctement reçu et
qu'il ne doit pas être transmis de nouveau, mais que le dispositif de réception n'est pas encore prêt à
recevoir un autre message de demande.
5.6.28 Codes spécifiques au constructeur
Ces codes de réponse sont réservés pour être spécifiés par le constructeur de véhicules.
5.7 Gestion des codes de réponse
La figure 5 spécifie le comportement du serveur en cas de message de demande du client. Cette figure
présente la logique telle qu'elle est spécifiée dans la description des codes de réponse et telle qu'elle
doit être mise en œuvre dans le serveur et le client, selon le cas.
©
ISO ISO 14229:1998(F)
Figure 5 — Comportement du serveur en cas de message de réponse positif ou négatif
©
6 Unité fonctionnelle de gestion de diagnostic
6.1 Généralités
6.1.1 Le tableau 2 décrit l'unité fonctionnelle de gestion de diagnostic.
Tableau 2 — Unité fonctionnelle de gestion de diagnostic
Nom de service Description
StartDiagnosticSession Le Client demande de commencer une session de
(démarrer session de diagnostic) diagnostic avec un Serveur spécifique
StopDiagnosticSession Le Client demande d'arrêter la session de diagnostic
(arrêter session de diagnostic) en cours
SecurityAccess Le Client demande de déverrouiller un Serveur
(accès sécurité) protégé
TesterPresent Le Client indique au Serveur qu'il est toujours
(boîtier présent) présent
ECUReset Le Client force le Serveur à effectuer une remise à
(remise à zéro UCE) zéro
ReadECUIdentification Le Client demande une identification de données à
(lire identification UCE) partir du Serveur
DisableNormalMessageTransmission Le Client demande au Serveur de cesser de
(désactiver transmission normale de transmettre des messages non relatifs au diagnostic
message)
EnableNormalMessageTransmission Le Client demande au Serveur de reprendre la
(activer transmission normale de message) transmission de messages non relatifs au diagnostic
NOTE — Il est rappelé que
— le Client est la fonction de l'outil de diagnostic qui utilise les services de diagnostic;
— le Serveur est la fonction de l'UCE embarquée qui assure les services de diagnostic.
6.1.2 Les services de cette unité fonctionnelle utilisent les paramètres suivants:
Mode de diagnostic
Ce paramètre est utilisé par le service StartDiagnosticSession afin de sélectionner la session de
diagnostic (comportement spécifique du Serveur). La présente Norme internationale ne spécifie pas de
liste pour ce paramètre, ni ne définit un moyen spécifique d'obtenir cette liste par le Serveur.
EXEMPLES — Atelier de réparations, en ligne, spécifique au constructeur, réglementation, etc.
Mode d'accès
Ce paramètre est utilisé dans le service SecurityAccess. Il indique au Serveur l'étape en cours du
service, le niveau de sécurité auquel le Client veut accéder et le format de la valeur de départ et de la
clé. Deux valeurs sont définies pour l'étape en cours: REQUEST SEED (demande de valeur de départ)
et SEND KEY (envoyer clé).
Clé
Ce paramètre est utilisé par le service SecurityAccess pour déverrouiller un S
...
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...