ISO 22901-2:2011

INTERNATIONAL ISO
STANDARD 22901-2
First edition
2011-07-01
Road vehicles — Open diagnostic data
exchange (ODX) —
Part 2:
Emissions-related diagnostic data
Véhicules routiers — Échange de données de diagnostic ouvert
(ODX) —
Partie 2: Données de diagnostic relatives aux émissions

Reference number
©
ISO 2011
©  ISO 2011
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 either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms, abbreviated terms and definitions.1
3.1 Terms and definitions .2
3.2 Abbreviated terms .2
4 Conventions.2
5 ODX data in the ECU life cycle.2
6 Emissions-related OBD ODX use cases .3
6.1 Use case 1 — OBD Scan Tool based on a Modular VCI architecture and ODX.3
6.2 Use case 2 — Conversion of emissions-related OBD data to ODX format .4
7 Emissions-related OBD ODX application examples .6
7.1 OBD conformance tester according to SAE J1699-3.6
7.2 Usage of ODX as a configuration for standardized ECU software.7
7.3 Usage of ODX checker rules for ECU development .8
8 Specification release version information.9
8.1 Specification release version location .9
8.2 Specification release version.9
9 OBD authoring in ODX.9
9.1 ODX layering .9
9.2 Service implementation in ODX .13
9.3 ODX PARAMs implementation.17
9.4 Conversion of PIDs to ODX .23
9.5 Conversion of DTCs to ODX.27
9.6 ODX samples of ISO 15031-5 services and authored data.29
Bibliography.72

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22901-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 22901 consists of the following parts, under the general title Road vehicles — Open diagnostic data
exchange (ODX):
⎯ Part 1: Data model specification
⎯ Part 2: Emissions-related diagnostic data
iv © ISO 2011 – All rights reserved

Introduction
This International Standard has been established in order to define the data format for transferring
standardized emissions-related diagnostic data of the vehicle's OBD system between system supplier, vehicle
manufacturer and service dealerships and diagnostic tools of different vendors.
The standardized information is contained in the following standards:
⎯ Diagnostic protocol information:
⎯ ISO 9141-2:1994, Road vehicles — Diagnostic systems — Part 2: CARB requirements for
interchange of digital information,
⎯ ISO 9141-2:1994/Amd.1:1996, Road vehicles — Diagnostic systems — Part 2: CARB requirements
for interchange of digital information — Amendment 1,
⎯ ISO 14230-4:2000, Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4:
Requirements for emissions-related systems,
⎯ ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network (CAN) —
Part 4: Requirements for emissions-related systems,
⎯ SAE J1850, Class B Data Communications Network Interface
⎯ ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 5: Emissions-related diagnostic services;
⎯ Emissions-related OBD data:
⎯ ISO 15031-4, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 4: External test equipment,
⎯ ISO 15031-5, Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics — Part 5: Emissions-related diagnostic services,
⎯ ISO 15031-6, Road vehicles — Communication between vehicle and external test equipment for
emissions-related diagnostics — Part 6: Diagnostic trouble code definitions,
⎯ SAE J1979-DA, Digital Annex of E/E Diagnostic Test Modes,
⎯ SAE J2012-DA, Digital Annex of Diagnostic Trouble Code Definition;
⎯ OBD Conformance test cases:
⎯ SAE J1699-3, OBD II Compliance Test Cases.
The automotive industry mostly utilizes an informal description to document diagnostic data stream
information of vehicle ECUs. Each user, who desires to use the ECU diagnostic data stream documentation to
setup development tools or service diagnostic test equipment, has a requirement for a manual transformation
of this documentation into a format readable by these tools. This effort will no longer be required if the
diagnostic data stream information is provided in ODX format and if those tools support the ODX format.

INTERNATIONAL STANDARD ISO 22901-2:2011(E)

Road vehicles — Open diagnostic data exchange (ODX) —
Part 2:
Emissions-related diagnostic data
1 Scope
This part of ISO 22901 is intended to ensure that diagnostic data stream information is available to diagnostic
tool application manufacturers to simplify the support of the aftermarket automotive service industry. The ODX
modelled diagnostic data are compatible with the software requirements of the Modular Vehicle
Communication Interface (MVCI) (ISO 22900-2 and ISO 22900-3). The ODX modelled diagnostic data can
enable an MVCI device to communicate with the vehicle [ECU(s)] and interpret the diagnostic data contained
in the messages exchanged between the external test equipment and the ECU(s). For ODX-compliant
external test equipment, no software programming is necessary to convert diagnostic data into technician-
readable information for display by the external test equipment.
This part of ISO 22901 contains emissions-related OBD data examples described in ODX. The data examples
derive from ISO 15031 (all parts).
EXAMPLES Diagnostic trouble codes, data parameters, identification data and communication parameters.
The emissions-related OBD ODX modelled diagnostic data describe
⎯ the protocol specification from diagnostic communication of emissions-related ECUs;
⎯ the communication parameters for the emissions-related OBD protocols and data link layers and for
emissions-related ECU software;
⎯ the related vehicle interface description (connectors and pin-out);
⎯ the functional description of diagnostic capabilities of a network of ECUs.
This part of ISO 22901 is based on emissions-related diagnostic data derived and formatted according to the
ISO 15765-4 DoCAN protocol. The definitions and XML representation is exemplary for all other protocols that
are referenced in ISO 15031-5.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 15031 (all parts), Road vehicles — Communication between vehicle and external equipment for
emissions-related diagnostics
ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network (CAN) — Part 4:
Requirements for emissions-related systems
ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification
3 Terms and definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22901-1 apply.
3.2 Abbreviated terms
MVCI Modular Vehicle Communication Interface
ODX-RT Open Diagnostic data eXchange — Run-Time format
4 Conventions
This part of ISO 22901 is based on the conventions discussed in the OSI Service Conventions
[11]
(ISO/IEC 10731 ) as they apply for diagnostic services.
5 ODX data in the ECU life cycle
Figure 1 shows the usage of ODX in the ECU life cycle. Engineering, manufacturing, and service specify that
communication protocol and data should be implemented in the ECU. This information is documented in a
structured format utilizing the XML standard and by an appropriate ODX authoring tool. There is potential to
generate ECU software from the ODX file. Furthermore, the same ODX file is used to set up the diagnostic
engineering tools to verify proper communication with the ECU and to perform functional verification and
compliance testing. Once all quality goals are met, the ODX file may be released to a diagnostic database.
Diagnostic information is now available to manufacturing, service, OEM franchised dealers and aftermarket
service outlets via Intranet and Internet.

Figure 1 — Usage of ODX data in the ECU life cycle
2 © ISO 2011 – All rights reserved

The objective of this specification is to ensure that diagnostic data from any vehicle manufacturer is
independent of the testing hardware and protocol software supplied by any test equipment manufacturer.
6 Emissions-related OBD ODX use cases
6.1 Use case 1 — OBD Scan Tool based on a Modular VCI architecture and ODX
This use case describes the usage of an OBD scan tool in accordance with ISO 15031-4 / SAE J1978 and
implemented according to the Modular VCI specification (see ISO 22900, parts 1, 2 and 3) and ODX (see
ISO 22901-1).
The benefits of an emissions-related OBD scan tool that is based on the Modular VCI and ODX standard are
the following:
⎯ no software programming to support the implementation of
⎯ new diagnostic trouble codes (see ISO 15031-6 / SAE J2012-DA),
⎯ new PIDs, Test IDs, Monitor IDs, Info Type IDs, and Scaling IDs (see ISO 15031-5 / SAE J1979-DA);
⎯ OBD scan tool applications in accordance with ISO 15031-4 are developed only once and are not
impacted by modifications / changes in the definition of emissions-related OBD data and formats;
⎯ separation of application, communication logic and data items.
NOTE The Modular VCI software architecture supports the emissions-related OBD scan tool requirements as well as
enhanced diagnostic protocols, data streams and applications.
Figure 2 illustrates external test equipment connected to the vehicle's diagnostic connector. The OBD scan
tool's software architecture is compliant to the Modular VCI specifications. The diagnostic kernel is the key
software component of the Modular VCI system. It implements the D-PDU API (see ISO 22900-2), the
D-Server API (see ISO 22900-3) and the interface to the ODX derived runtime data.
The OBD scan tool application depends on standardized names or naming conventions as defined by this part
of ISO 22901. These names are defined in the emissions-related ODX data and utilized by the OBD scan tool
application to address logical links, services, and emission-related data. Using the standardized names and
structures from this part of ISO 22901, the interface to implement the scan tool application against is clearly
defined. This is indicated by the dashed line in Figure 2.
The D-PDU API is a software component of the tool supplier's Modular VCI protocol module. It connects the
diagnostic kernel with any Modular VCI compatible vehicle communication interface.
The D-Server API of the diagnostic kernel provides a standardized interface to the OBD scan tool applications.
These applications shall be in accordance with ISO 15031-4, which implements the standardized data and
messages of ISO 15031-5 and ISO 15031-6.
The emissions-related ODX runtime data format is tool supplier specific. The runtime format is not contained
in the ODX standard (see ISO 22901-1). Based on the use cases supported by the diagnostic tool, the content
and structure of the ODX runtime data format and content may differ. However, for emissions-related OBD the
OBD scan tool applications and ODX runtime data shall support the full scope of ISO 15031 (all parts) and the
respective SAE J documents.
All emissions-related OBD data as specified in ISO 15031-5 and SAE J1979-DA, ISO 15031-6 and
SAE J2012-DA shall be authored according to the requirements established in this part of ISO 22901.
This use case requires the unique and complete definition of all elements necessary for any OBD scan tool
application compliant to ISO 22900.
Figure 2 — OBD scan tool based on Modular VCI architecture and ODX
6.2 Use case 2 — Conversion of emissions-related OBD data to ODX format
This use case describes the conversion of emissions-related OBD data into the ODX format in order to
provide various applications of external test equipment with emissions-related OBD data in an ODX-RT
(runtime) format.
It is assumed that the external test equipment is based on ISO 22900.
The emissions-related OBD data files derive from the Registration Authority installation for ISO 15031.
4 © ISO 2011 – All rights reserved

The applicable emissions-related OBD data files are
⎯ SAE J1979-DA,
⎯ SAE J2012-DA.
Figure 3 illustrates the process to be followed in order to convert SAE J2012-DA, and SAE J1979-DA data file
[1],[2]
information (i.e. Excel or equivalent format) into a standardized ODX format which enrich the emissions-
[3]
related OBD data with template information. The dotted line depicts the interface that this part of ISO 22901
defines. ODX data providers can deliver ODX data in the format defined here, while tester and scan tool
developers can create their tools in accordance with this part of ISO 22901. Thus, both parties can work
independently and their products will work together.
How far the converter processes can be automated depends solely on the concrete format of the digital annex.
This part of ISO 22901 defines the target format of these processes.

Key
1 SAE J2012-DA DTC converter into ODX format
2 SAE J1979-DA PIDs, OBDMIDs, . converter into ODX format
3 ODX converter templates to determine standardized ODX parts i.e. PROTOCOLS, COMPARAMS, . and ODX
usage as defined by this part of ISO 22901
Figure 3 — Emissions-related OBD data converter to ODX-RT format
The benefits of implementing this use case are
⎯ the setup/update of an ISO 22900 Modular VCI based OBD test equipment utilizing a SAE J2534-1
compliant vehicle communication interface or an MVCI compliant Protocol Module with emissions-related
OBD data (ODX-RT format) that derive from a conversion of the applicable SAE Digital Annexes;
⎯ the setup/update of an ISO 22900 Modular VCI based OBD conformance tester with emissions-related
OBD data (ODX-RT format) that implements the test cases as specified in SAE J1699-3.
7 Emissions-related OBD ODX application examples
7.1 OBD conformance tester according to SAE J1699-3
This application example describes the implementation of an OBD conformance tester in accordance with
SAE J1699-3 and based on the Modular VCI software architecture. The base architecture as shown in use
case 1 applies. The major difference between the emissions-related OBD scan tool and the OBD
conformance tester is implemented in the test applications. While the emissions-related OBD scan tool is in
accordance with ISO 15031-4, the OBD conformance tester is in accordance with SAE J1699-3. This
specification describes very specific test cases in order to achieve vehicle emissions-related system
compliance. These test cases have been introduced and referenced by legislation in order to reduce
emissions-related diagnostic software implementation deviations in the ECUs from ISO 15031 (all parts) and
the respective SAE J documents.
The benefits of an OBD conformance tester based on the Modular VCI and ODX standard are
⎯ no software programming to support the implementation of
⎯ new diagnostic trouble codes (see ISO 15031-6 / SAE J2012-DA),
⎯ new PIDs, Test IDs, Monitor IDs, Info Type IDs and Scaling IDs (see ISO 15031-5 / SAE J1979-DA);
⎯ conformance test applications implement the test logic but not the data items (derive from emissions-
related ODX runtime);
⎯ clear separation of application and communication logic as well as from all data items.
Figure 4 is based on the architecture as shown in use case 1.
6 © ISO 2011 – All rights reserved

Figure 4 — ODX emissions OBD Modular VCI based OBD conformance tester
7.2 Usage of ODX as a configuration for standardized ECU software
This application example describes how to drive the implementation of the emissions-related OBD diagnostic
software module of the ECU by the OBD ODX data. This may be done either by using the OBD ODX data as
configuration for a generic diagnostic software module or by utilizing a software generation process, which is
controlled by the OBD ODX configuration data.
Once the OBD behaviour of an ECU is defined in ODX format, this file can be used to configure a
standardized software part in the ECU.
The benefits of implementing this use case are that
⎯ it is necessary to test standardized ECU software modules only once;
⎯ standardized ECU software modules can be reused in different projects;
⎯ ECU behaviour fits exactly to the behaviour described in the ODX file (because the software as well as
the documentation are derived from the same data source).
Figure 5 depicts an example of an ECU diagnostic software module and configuration data derived from ODX.

Figure 5 — Example of an ECU diagnostic software module and configuration data derived from ODX
7.3 Usage of ODX checker rules for ECU development
This application example describes the usage of ODX checker rules, which represent a subset of the
SAE J1699-3 test cases.
For ODX, adaptable checkers exist. These allow to check for ODX compliance and may be extended with
individual checker rules. With these, OBD compliance may be checked before the ECU is implemented, only if
the emissions-related OBD ODX data follow the requirements of this part of ISO 22901.
EXAMPLE When specifying the behaviour of an individual ECU in ODX, the support of Infotype 0x0A (ECU-name)
for model year 2010 and later can be checked before the ECU code is implemented.
The benefits of implementing this application example are:
⎯ early check for errors (before ECU is implemented in the vehicle);
⎯ checker rules may be provided by a third party and made available to interested users.
Figure 6 depicts an emissions-related OBD compliance test during ECU specification phase.
8 © ISO 2011 – All rights reserved

Figure 6 — Emissions-related OBD compliance test during ECU specification phase
8 Specification release version information
8.1 Specification release version location
The release version of the ODX standard can be obtained from every ODX file instance. It is contained in the
MODEL-VERSION attribute.

8.2 Specification release version
The specification release version of this document is: 2.2.0
9 OBD authoring in ODX
9.1 ODX layering
9.1.1 Relationship between ODX layers
Figure 7 illustrates the partitioning of the emissions-related OBD protocols and their associated
ComParamSpec from the ECU-Shared-Data and Functional Groups 1 and 2. The Vehicle-Info specifies the
Logical Links to the Protocols and Functional Groups. The light and dotted parts are user extensions that can
be integrated, if protocols other than ISO 15765-4 are to be supported.
This part of ISO 22901 covers only the ISO 15765-4 DoCAN case. If other physical layers are modelled in
ODX as well, the naming as defined in this part of ISO 22901 are to be used.

Figure 7 — ComParam-Specs for emissions-related OBD protocols and data
Each DIAG-LAYER should reside in a DIAG-LAYER-CONTAINER of its own.
9.1.2 Authoring of Functional Groups
Functional Groups specify data for a group of emissions-related ECUs, i.e. Engine Control Module and
Transmission Control Module which contain all required information to enable the Modular VCI compliant
emissions-related OBD test equipment to perform functional communication.
A Functional Group named “FG_OBD_II” specifies the data relevant to the OBD message protocol for all of
the available and supported physical link layers (ISO_OBD_on_ISO_15765_4 and also
ISO_OBD_on_SAE_J1850, ISO_OBD_on_K_Line, if present). The ComParamSpec as defined by
ISO 22900-2 specifies the protocol specific message framing, message timing and message addressing
information. For SAE J1993-73, this part of ISO 22901 defines only the name for the protocol layer.
9.1.3 Authoring of emissions-related protocols
The PROTOCOL class in ODX is used to capture communication data like message layout, parameters in
diagnostic requests and responses, conversion information to convert from coded values to physical values
and vice versa.
10 © ISO 2011 – All rights reserved

For emission-related data, three ODX protocol layers named “PR_ISO_15031_5_on_ISO_15765_4”,
“PR_ISO_15031_5_on_SAE_J1850” and “PR_ISO_15031_5_on_K_Line” are defined.
“PR_ISO_15031_5_on_ISO_15765_4” is covered by this part of ISO 22901. They capture the physical layer
and transport layer specific protocol information.
EXAMPLE Name tags of protocol PR_ISO_15031_5_on_ISO_15765_4

PR_ISO_15031_5_on_ISO_15765_4
ISO OBD on CAN
REF="ID_ISO_OBD_on_ISO_15765_4"/>

Table 1 defines SHORT-NAME and LONG-NAME of the OBD protocols.
Table 1 — Definition of SHORT-NAME and LONG-NAME of OBD protocols
SHORT-NAME LONG-NAME
PR_ISO_15031_5_on_ISO_15765_4 ISO OBD on CAN
PR_ISO_15031_5_on_SAE_J1850 ISO OBD on J1850 VPW and J1850 PWM
PR_ISO_15031_5_on_K_Line ISO OBD on 9141-2 K-Line and KWP2000 K-Line

In order to identify and group OBD services effectively, all OBD Services are members of the Functional Class
“OBD.PROTOCOL.OBDonCAN.FUNCT-CLASS.emissionRelatedDiagnosticServices”.
EXAMPLE FUNCT-CLASSS


ISO_15031_5
ISO 15031-5


9.1.4 Authoring of emissions-related ECU-SHARED-DATA
Several named ECU-SHARED-DATA ODX containers capture OBDII relevant services as well as parameter
encoding and decoding information.
“OBDII_DOPS” hold the encoding and decoding description of a response and request parameter as well as
units and dimension specifications.
“OBDII_Common_Services” holds OBDII services definitions for modes 0x01-0x04, 0x06-0x09.
“OBDII_ModeA_Service” holds OBDII services definitions for mode 0x0A. Mode 0x0A service is separated out
because it is not used for OBD other than on CAN.
“OBDII_Mode5_Service” holds OBDII service definitions for mode 0x05. Mode 0x05 service is separated out
because it is not used for OBD on CAN.
EXAMPLE Ecu-Shared-Data

OBDII_DOPS
DTCS for the OBD protocol



J2012DTC
J2012DTC

16



IDENTICAL



P0000
0
ISO/SAE reserved - Use Not Allowed

…



…


9.1.5 Authoring of VEHICLE-INFO
The VEHICLE-INFO-SPECIFICATION “VI_OBDII” specifies the logical links to be supported by the Modular
VCI (see ISO 22900).
All OBDII logical links refer to Functional Group “FG_OBD_II”. However, for different physical layers, the
respective predefined protocol of 9.1.3 is referenced.
There shall be three Logical Links defined, named “LL_OBD_on_ISO_15765_4”, “LL_OBD_on_SAE_J1850”
and “LL_OBD_on_K_Line”:
a) LL_OBD_on_ISO_15765_4 references FG_OBD_II and PR_OBD_on_ISO_15765_4;
b) LL_OBD_on_SAE_J1850 references FG_OBD_II and PR_OBD_on_SAE_J1850;
c) LL_OBD_on_K_Line references FG_OBD_II and PR_OBD_on_K_Line.
12 © ISO 2011 – All rights reserved

This technique ensures that selecting a logical link is sufficient to establish ECU communication using the
correct protocol, communication parameters and services.
IMPORTANT — OBD communication initialization is specified in ISO 22900-2.
9.2 Service implementation in ODX
9.2.1 General
ISO 22901-1 provides at least two alternatives to author diagnostic data:
a) dedicated diagnostic service related data authoring, i.e. the same data (PIDS, INFOTYPES, .) are used
by all emissions-related OBD protocols and authored for each protocol redundantly;
b) diagnostic service independent related data authoring, also called “table based authoring”, i.e. the same
data (PIDS, INFOTYPES, .), are used by all emissions-related OBD protocols but authored only once
and referenced by each protocol.
IMPORTANT — Emissions-related OBD data as specified in ISO 15031-5, ISO 15031-6 / SAE J1979 and
SAE J1979-DA (Digital Annex) shall be authored according to b).
9.2.2 OBD Services authoring
9.2.2.1 ODX IDs of OBD services
The ID of the OBD services shall be generated by the following rule: .DS_SHORT-NAME
ID="ES_OBDIICommonServices.DS_Service01RequestCurrentPowertrainDiagnosticDataPID13">
Service01RequestCurrentPowertrainDiagnosticDataPID13
Service 0x01 - Request current powertrain diagnostic data (PID 0x13) NAME>
…

9.2.2.2 ODX DESCription of OBD services
The text of the ISO 15031-5 “Functional description” subclause of the particular OBD service shall be used.
9.2.2.3 ODX LONG-NAMEs of OBD services
The LONG-NAME of the DIAG-SERVICE shall use the complete wording of the service description in the
headlines of ISO 15031-5. This document distinguishes between services for ISO 9141-2, ISO 14230-4,
SAE J1850 and services for ISO 15765-4, but the descriptions of the headlines are the same as the services
in both cases; this circumstance has to be considered in the LONG-NAME or later on in the description of the
services itself. Request and POS-/NEG-RESPONSES have to be kept in mind in this case.
Table 2 defines the LONG-NAMEs for OBD services regarding ISO 15765-4.
Table 2 — LONG-NAMEs for OBD services regarding ISO 15765-4
Headline used in ISO 15031-5 and LONG-NAME
ISO 15765-4
Service 0x01 – Request current Service 0x01 – Request current powertrain diagnostic data
powertrain diagnostic data
Service 0x02 – Request powertrain Service 0x02 – Request powertrain freeze frame data
freeze frame data
Service 0x03 – Request emission- Service 0x03 – Request emission-related diagnostic trouble codes
related diagnostic trouble codes
Service 0x04 – Clear/reset Service 0x04 – Clear/reset emission-related diagnostic information
emission-related diagnostic
information
Service 0x05 – Request oxygen Service 0x05 – Request oxygen sensor monitoring test results
sensor monitoring test results
Service 0x06 – Request on-board Service 0x06 – Request on-board monitoring test results for specific monitored
monitoring test results for specific systems
monitored systems
Service 0x07 – Request emission- Service 0x07 – Request emission-related diagnostic trouble codes detected during
related diagnostic trouble codes current or last completed driving cycle
detected during current or last
completed driving cycle
Service 0x08 – Request control of Service 0x08 – Request control of on-board system, test or component
on-board system, test or component
Service 0x09 – Request vehicle Service 0x09 – Request vehicle information
information
Service 0x0A – Request emissions- Service 0x0A – Request emissions-related diagnostic trouble codes with
related diagnostic trouble codes with permanent status
permanent status
It is necessary to consider the following exceptions. With service 0x01, the behaviour for PID 0x13 and PID
0x1D shall be distinguished. Therefore, it is necessary to define two services for service 0x01. The LONG-
NAME of both services are extended by the marker (PID 0x13) and (PID 0x1D), respectively.
Table 3 defines the LONG-NAMEs for OBD service 0x01 distinguishing PID 0x13 and PID 0x1D.
Table 3 — LONG-NAMEs for OBD service 0x01 distinguishing PID 0x13 and PID 0x1D
Headline used in ISO 15031-5 and ISO 15765-4 LONG-NAME
Service 0x01 – Request current powertrain diagnostic Service 0x01 – Request current powertrain diagnostic data
data (PID 0x13)
Service 0x01 – Request current powertrain diagnostic Service 0x01 – Request current powertrain diagnostic data
data (PID 0x1D)
14 © ISO 2011 – All rights reserved

9.2.2.4 ODX SHORT-NAMEs of OBD services
Table 4 defines the SHORT-NAMEs for OBD services regarding ISO 15765-4.
Table 4 — SHORT-NAMEs for OBD services regarding ISO 15765-4
LONG-NAME SHORT-NAME
Service 0x01 – Request current powertrain diagnostic Service01RequestCurrentPowertrainDiagnosticData
data
Service 0x02 – Request powertrain freeze frame data Service02RequestPowertrainFreezeFrameData
Service 0x03 – Request emissions-related diagnostic Service03RequestEmissionRelatedDiagnosticTroubleCodes
trouble codes
Service 0x04 – Clear/reset emissions-related diagnostic Service04ClearResetEmissionRelatedDiagnosticInformation
information
Service 0x05 – Request oxygen sensor monitoring test Service05RequestOxygenSensorMonitoringTestResults
results
Service 0x06 – Request on-board monitoring test results Service06RequestOnBoardMonitoringTestResults
for specific monitored systems ForSpecificMonitoredSystems
Service 0x07 – Request emissions-related diagnostic Service07RequestEmissionRelatedDiagnosticTroubleCodesD
trouble codes detected during current or last completed etectedDuringCurrentOrLastCompletedDrivingCycle
driving cycle
Service 0x08 – Request control of on-board system, test Service08RequestControlOfOnBoardSystemTestOrComponent
or component
Service 0x09 – Request vehicle information Service09RequestVehicleInformation
Service 0x0A – Request emissions-related diagnostic Service0ARequestEmissionRelatedDiagnosticTroubleCodes
trouble codes with permanent status WithPermanentStatus

IMPORTANT — The addressing method shall be FUNCTIONAL.
Table 5 defines two different service 0x01 LONG-NAME and SHORT-NAME because the interpretation of the
respective response impacts the interpretation of, for example, PID 0x1B.
Table 5 — SHORT-NAMEs for OBD service 0x01 distinguishing PID 0x13 and PID 0x1D
LONG-NAME SHORT-NAME
Service 0x01 – Request current powertrain diagnostic Service01RequestCurrentPowertrainDiagnosticDataPID13
data (PID 0x13)
Service 0x01 – Request current powertrain diagnostic Service01RequestCurrentPowertrainDiagnosticDataPID1D
data (PID 0x1D)
9.2.3 ODX request implementation
9.2.3.1 ODX IDs of requests
For the ID of an OBD request the prefix REQ_ shall be combined with the SHORT-NAME of the request.
9.2.3.2 LONG-NAMEs and SHORT-NAMEs of requests
The LONG-NAME of the request shall be the same as the LONG-NAME of the DIAG-SERVICE that the
request belongs to. The SHORT-NAME of the request shall be the same as the SHORT-NAME of the DIAG-
SERVICE that the request belongs to.
Table 6 defines the LONG-NAMEs and SHORT-NAMEs of requests.
Table 6 — LONG-NAMEs and SHORT-NAMEs of requests
LONG-NAME of request SHORT-NAME of request
Service 0x01 – Request current powertrain diagnostic Service01RequestCurrentPowertrainDiagnosticData
data
Service 0x02 – Request powertrain freeze frame data Service02RequestPowertrainFreezeFrameData
Service 0x03 – Request emission-related diagnostic Service03RequestEmissionRelatedDiagnosticTroubleCodes
trouble codes
Service 0x04 – Clear/reset emission-related diagnostic Service04ClearResetEmissionRelatedDiagnosticInformation
information
Service 0x05 – Request oxygen sensor monitoring test Service05RequestOxygenSensorMonitoringTestResults
results
Service 0x06 – Request on-board monitoring test results Service06RequestOnBoardMonitoringTestResultsForSpecific
for specific monitored systems MonitoredSystems
Service 0x07 – Request emission-related diagnostic Service07RequestEmissionRelatedDiagnosticTroubleCodes
trouble codes detected during current or last completed DetectedDuringCurrentOrLastCompletedDrivingCycle
driving cycle
Service 0x08 – Request control of on-board system, test Service08RequestControlOfOnBoardSystemTestOr
or component Component
Service 0x09 – Request vehicle information Service09RequestVehicleInformation
Service 0x0A – Request emissions-related diagnostic Service0ARequestEmissionRelatedDiagnosticTroubleCodes
trouble codes with permanent status WithPermanentStatus

9.2.4 ODX POS-RESPONSE implementation
9.2.4.1 ODX IDs of POS-RESPONSES
For the ID of an OBD POS-RESPONSE the prefix PRE_ shall be combined with the SHORT-NAME of the
POS-RESPONSE.
9.2.4.2 LONG-NAMEs of POS-RESPONSES
The LONG-NAME of the POS-RESPONSE shall be the same as the LONG-NAME of the DIAG-SERVICE that
the POS-RESPONSE belongs to.
16 © ISO 2011 – All rights reserved

9.2.4.3 SHORT-NAMEs of POS-RESPONSES
The SHORT-NAME of the POS-RESPONSE shall be the same as the SHORT-NAME of the DIAG-SERVICE
that the POS-RESPONSE belongs to.
Table 7 defines the LONG-NAMEs and SHORT-NAMEs of POS-RESPONSES.
Table 7 — LONG-NAMEs and SHORT-NAMEs of POS-RESPONSES
LONG-NAME of POS-RESPONSE SHORT-NAME of POS-RESPONSE
Service 0x01 – Request current powertrain diagnostic Service01RequestCurrentPowertrainDiagnosticData
data
Service 0x02 – Request powertrain freeze frame data Service02RequestPowertrainFreezeFrameData
Service 0x03 – Request emission-related diagnostic Service03RequestEmissionRelatedDiagnosticTroubleCodes
trouble codes
Service 0x04 – Clear/reset emission-related diagnostic Service04ClearResetEmissionRelatedDiagnosticInformation
information
Service 0x05 – Request oxygen sensor monitoring test Service05RequestOxygenSensorMonitoringTestResults
results
Service 0x06 – Request on-board monitoring test results Service06RequestOnBoardMonitoringTestResultsForSpecific
for specific monitored systems MonitoredSystems
Service 0x07 – Request emission-related diagnostic Service07RequestEmissionRelatedDiagnosticTroubleCodesD
trouble codes detected during current or last completed etectedDuring
driving cycle CurrentOrLastCompletedDrivingCycle
Service 0x08 – Request control of on-board system, test Service08RequestControlOfOnBoardSystemTestOrComponent
or component
Service 0x09 – Request vehicle information Service09RequestVehicleInformation
Service 0x0A – Request emissions-related diagnostic Service0ARequestEmissionRelatedDiagnosticTroubleCodes
trouble codes with permanent status WithPermanentStatus

9.2.5 ODX NEG-RESPONSE implementation
A GLOBAL-NEG-RESPONSE in the ECU-SHARED-DATA “OBDII_Common_Services” defines the negative
responses according to ISO 15031-5 for OBD communication based on ISO 15765-4, SAE J1850. The ID of
the GLOBAL-NEG-RESPONSE is “GNR_OBDIIServicesNegativeResponse”. Its LONG-NAME is “OBDII
Services – Negative Response”. Its SHORT-NAME is “OBDIIServicesNegativeResponse”.
No DIAG-SERVICE specific NEG-RESPONSEs are used for the OBD Modes 0x01-0x0A.
9.3 ODX PARAMs implementation
As a general rule, the ODX names of a parameter shall be derived from the “Description” of the parameter as
specified in ISO 15031-5. The LONG-NAME shall be copied from the description in ISO 15031-5. The
SHORT-NAME shall be generated by removing all characters from the LONG-NAME disallowed by the ODX
specification.
In case a parameter in ISO 15031-5 has no description or when the description is not favourable for a specific
parameter, the naming convention shall be as detailed in this part of ISO 22901.
The second parameter at the POS-RESPONSE shall describe the PID of the request. This shall be done with
the use of MATCHING-REQUEST-PARAM. The LONG-NAME of this parameter is “Matching PID”. The
SHORT-NAME shall be MatchingParameterID.
9.3.1 Service IDs (SID)
9.3.1.1 LONG-NAMEs and SHORT-NAMEs of request SIDs
The general rule shall be applied, however, the words “request SID” shall be appended to the LONG-NAME of
the SID parameter. The SHORT-NAME is then derived from the LONG-NAME as described in the general rule.
Table 8 defines the LONG-NAMEs and SHORT-NAMEs of PARAMs of the request SID.
Table 8 — LONG-NAMEs and SHORT-NAMEs of PARAMs of the request SID
Request SID LONG-NAME of PARAM SHORT-NAME of PARAM
Service 0x01 Request current powertrain RequestCurrentPowertrainDiagnosticDataRequestSID
diagnostic data request SID
Service 0x02 Request powertrain freeze frame RequestPowertrainFreezeFrameDataRequestSID
data request SID
Service 0x03 Request emission-related diagnostic RequestEmissionRelatedDiagnosticTroubleCodesRequestSID
trouble codes request SID
Service 0x04 Clear/reset emission-related ClearResetEmissionRelatedDiagnosticInformationRequestSID
diagnostic information request SID
Service 0x05 Request oxygen sensor monitoring RequestOxygenSensorMonitoringTestResultsRequestSID
test results request SID
Service 0x06 Request on-board monitoring test RequestOnBoardMonitoringTestResults
results for specific monitored ForSpecificMonitoredSystemsRequestSID
systems request SID
Service 0x07 Request emission-related diagnostic RequestEmissionRelatedDiagnosticTroubleCodesDetected
trouble codes detected during DuringCurrentOrLastCompletedDrivingCycleRequestSID
current or last completed driving
cycle request SID
Service 0x08 Request control of on-board system, RequestControlOfOnBoardSystemTestOrComponent
test or component request SID RequestSID
Service 0x09 Request vehicle information request RequestVehicleInformationRequestSID
SID
Service 0x0A Request emissions-related RequestEmissionsRelatedDiagnosticTroubleCodesWithPerman
diagnostic trouble codes with entStatusRequestSID
permanent status request SID
The request SID parameters shall be of type CODED-CONST defined as DIAG-CODED-TYPE, i.e. an 8 bit
unsigned integer value. The SEMANTIC of the parameter shall be “SERVICE-ID”.
9.3.1.2 LONG-NAMEs and SHORT-NAMEs of response SIDs
The general rule shall be applied, however, the words “response SID” shall be appended to the LONG-NAME
of the SID parameter. The SHORT-NAME is then derived from the LONG-NAME as described in the general
rule.
18 © ISO 2
...