ISO/PAS 27145-3:2006

PUBLICLY ISO/PAS
AVAILABLE 27145-3
SPECIFICATION
First edition
2006-09-15
Road vehicles — Implementation of
WWH-OBD communication
requirements —
Part 3:
Common message dictionary
Véhicules routiers — Mise en application des exigences de
communication WWH-OBD —
Partie 3: Dictionnaire de messages communs

Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2006
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 2006 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions. 2
4 Symbols and abbreviated terms . 2
5 Conventions . 3
6 General requirements. 4
6.1 Overview of unified diagnostic services . 4
6.2 Message byte order . 4
7 Emissions-related diagnostic services implementation. 5
7.1 ReadProtocolIdentification (12 hex) service. 5
7.1.1 Service description. 5
7.1.2 Request message . 5
7.1.3 Positive response message. 6
7.1.4 Supported negative response codes (NRC_) . 6
7.1.5 Message flow example ReadProtocolIdentification . 7
7.2 ClearDiagnosticInformation (14 hex) service . 7
7.2.1 Service description. 7
7.2.2 Request message . 9
7.2.3 Positive response message. 10
7.2.4 Supported negative response codes (NRC_) . 10
7.2.5 Message flow examples of ClearDiagnosticInformation . 10
7.3 ReadDTCInformation (19 hex) service. 15
7.3.1 Service description. 15
7.3.2 Request message definition . 16
7.3.3 Positive response message. 19
7.3.4 Supported negative response codes (NRC_) . 24
7.3.5 Message flow examples – ReadDTCInformation. 24
7.4 ReadDataByDataIdentifier (0x22) service.30
7.4.1 Service requirements . 30
7.4.2 Supported negative response codes (NRC_) . 34
7.4.3 Message flow example ReadDataByDataIdentifier. 34
7.5 RoutineControl (0x31) service. 41
7.5.1 Request message . 41
7.5.2 Positive response message. 42
7.5.3 Supported negative response codes (NRC_) . 43
7.5.4 Message flow examples RoutineControl. 43
Annex A (normative) DTC attribute definition. 45
Bibliography . 49

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.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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/PAS 27145-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO/PAS 27145 consists of the following parts, under the general title Road vehicles — Implementation of
WWH-OBD communication requirements:
⎯ Part 1: General information and use case definition
⎯ Part 2: Common emissions-related data dictionary
⎯ Part 3: Common message dictionary
⎯ Part 4: Connection between vehicle and test equipment
NOTE ISO/PAS 27145-4 will be extended as necessary due to introduction of additional communication media.

iv © ISO 2006 – All rights reserved

Introduction
This document set includes the communication between the vehicle's OBD systems and test equipment
implemented across vehicles within the scope of the WWH-OBD GTR (World Wide Harmonized On-Board
Diagnostics Global Technical Regulations).
It has been established in order to apply the unified diagnostic services (specified in ISO 14229-1) to WWH
OBD systems.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance
with ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When
mapped on this model, the services specified by ISO/PAS 27145 are broken into:
⎯ Presentation layer (layer 7), specified in ISO/PAS 27145-3;
⎯ Application services (layer 6), specified in ISO/PAS 27145-2;
⎯ Session layer services (layer 5), specified in ISO/PAS 27145-4;
⎯ Transport layer services (layer 4), specified in ISO/PAS 27145-4;
⎯ Network layer services (layer 3), specified in ISO/PAS 27145-4;
⎯ Data link layer (layer 2), specified in ISO/PAS 27145-4; and
⎯ Physical layer (layer 1), specified in ISO/PAS 27145-4;
in accordance with Table 1.
Table 1 — Enhanced and legislated OBD diagnostic specifications applicable to the OSI layers
Implementation of WWH-OBD communication
Applicability OSI 7 layers
requirements, e.g. emissions-related UDS
Application (layer 7) ISO/PAS 27145-3
Presentation (layer 6) ISO/PAS 27145-2 / ISO 14229-1
Session (layer 5)
Seven layers
according to
Transport (layer 4)
ISO/IEC 7498-1 and
ISO/IEC 10731
ISO/PAS 27145-4
Network (layer 3)
Data link (layer 2)
Physical (layer 1)
PUBLICLY AVAILABLE SPECIFICATION ISO/PAS 27145-3:2006(E)

Road vehicles — Implementation of WWH-OBD communication
requirements —
Part 3:
Common message dictionary
1 Scope
ISO/PAS 27145 is intended to become the single communication standard for access to OBD-related
information. To allow for a smooth migration from the existing communication standards to this future
worldwide standardized communication standard, the initial communication concept will be based on CAN. In
a second step, ISO/PAS 27145 will be extended to define the world-wide harmonized OBD communication
standard based on existing industry communications standards (e.g. Internet Protocol) over Ethernet. Due to
the usage of standard network layer protocols, future extensions to optional physical layers (e.g. wireless) are
possible.
This part of ISO/PAS 27145 specifies the implementation of a subset of unified diagnostic services (UDS) as
specified in ISO 14229-1. The diagnostic services are used to communicate all diagnostic data as defined in
ISO/PAS 27145-2.
The subset of unified diagnostic services derives from the requirements stated in the WWH-OBD GTR (World
Wide Harmonised Global Technical Regulations). The common message set defined in this part is
independent of the underlying Transport, Network, Data Link and Physical Layer. This document does not
specify any requirements for the in-vehicle network architecture.
This part of ISO/PAS 27145 includes a superset of a modified version of ISO 14229-1. Several significant
modifications are included in this part in order to support the data set of SAE J1939, ISO 15031-5 and
ISO 15031-6:
⎯ ISO/PAS 27145-3 supports a 3-byte Unified Data Identifier format in all services which support a 2-byte
data identifier format in the ISO 14229-1.
⎯ ISO/PAS 27145-3 supports a 4-byte Diagnostic Trouble Code format in all services which support a
3-byte Diagnostic Trouble Code format in the ISO 14229-1.
⎯ ISO/PAS 27145-3 supports a separation of BaseDTC number from a FailureTypeByte including the
symptom of the Diagnostic Trouble Code.
This part of ISO/PAS 27145 is designed to provide the basis of unified diagnostic services for future GTR
modules provided by legislation.
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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model — Part 1:
The Basic Model
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —
Conventions for the definition of OSI services
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements
ISO 15031-5, Road vehicles — Communication between vehicle and external test 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 definition
ISO/PAS 27145-1, Road vehicles — Implementation of WWH-OBD communication requirements — Part 1:
General information and use case definition
ISO/PAS 27145-2, Road vehicles — Implementation of WWH-OBD communication requirements — Part 2:
Common emissions-related data dictionary
ISO/PAS 27145-4, Road vehicles — Implementation of WWH-OBD communication requirements — Part 4:
Connection between vehicle and test equipment
SAE J1939-21, Recommended Practice for a Serial Control and Communication Vehicle Network — Data link
layer
SAE J1939-71, Recommended Practice for a Serial Control and Communication Vehicle Network — Vehicle
application layer
SAE J1939-73, Recommended Practice for a Serial Control and Communication Vehicle Network —
Application layer — Diagnostics
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/PAS 27145-1, ISO/PAS 27145-2
and ISO 14229-1 apply.
4 Symbols and abbreviated terms
ASCII American Standard Code for Information Interchange
CALID Calibration Identification
CVN Calibration Verification Number
DID Diagnostic Data Identifier
DTC Diagnostic Trouble Code
2 © ISO 2006 – All rights reserved

ECM Engine Control Module
ECU Electronic Control Unit
GTR Global Technical Regulations
LDTC Legacy Diagnostic Trouble Code
LITID Legacy InfoType Identifier
LMID Legacy Monitor Identifier
LPID Legacy Parameter Identifier
LRID Legacy Routine Identifier
MI Malfunction Indicator
OTL OBD threshold limit
PGN Parameter Group Number
SFID Sub-function Identifier
SID Service Identifier
SPN Suspect Parameter Number
SUDID Supported Unified Data Identifier
UCID Unified Control (Input/Output) Identifier
UDID Unified Data Identifier
UDTC Unified Diagnostic Trouble Code
UITID Unified InfoType Identifier
UMID Unified Monitor Identifier
UPID Unified Parameter Identifier
URID Unified Routine Identifier
VIN Vehicle Identification Number
VOBD Vehicle On-Board Diagnostics
WWH-OBD Word Wide Harmonized On-Board Diagnostics
5 Conventions
ISO/PAS 27145 is based on the conventions discussed in the O.S.I. Service Conventions (ISO/IEC 10731:1994)
as they apply for diagnostic services.
6 General requirements
6.1 Overview of unified diagnostic services
ISO/PAS 27145-3 implements applicable diagnostic services of ISO 14229-1.
This part of ISO/PAS 27145 defines the diagnostic services as defined in ISO 14229-1 that are applicable to
systems which are required to be compliant to the GTR. For each applicable service the applicable sub-
function and data parameters are defined.
Table 2 — Overview of applicable ISO 14229-1 Unified diagnostic services and data ranges
Diagnostic service name SID SFID Comment
This service provides server implemented
ReadProtocolIdentification 0x12 —
protocol version information.
ClearDiagnosticInformation 0x14 — This service clears all diagnostic information.
⎯ groupOfDTC — Emissions system group identifier.
This service provides read capabilities for all
ReadDTCInformation 0x19
diagnostic trouble code related information.
⎯ reportDTCSnapshotRecordByDTCNumber 0x04
⎯ reportDTCExtendedDataRecordByDTCNumber 0x06
Unified DTC range:
⎯ reportDTCWithPermanentStatus 0x15
ISO/PAS 27145-2: 0x200000 – 0x27FFFF
⎯ reportNumberOfOBDDTCByMaskRecord 0x16
⎯ reportOBDDTCByMaskRecord 0x17
This service provides read capabilities for
ReadDataByIdentifier 0x22 —
static and dynamic data.
⎯ Legacy SAE SPN range — SAE J1939: 0x000000 – 0x07FFFF
⎯ Legacy SAE PGN range — SAE J1939: 0x080000 – 0x0BFFFF
⎯ Legacy ISO DTC range — ISO 15031-6: 0x100000 – 0x10FFFF

⎯ Legacy ISO DID range — ISO 15031-5: 0x180000 – 0x18FFFF
⎯ Unified BaseDTC range — ISO/PAS 27145-2: 0x200000 – 0x27FFFF
⎯ Unified DID range — ISO/PAS 27145-2: 0x280000 – 0x2FFFFF
This service provides control capability for
RoutineControl 0x31 —
routines.
⎯ StartRoutine 0x01 Sub-function starts a routine.

⎯ RequestRoutineResults 0x03 Sub-function stops a routine.
NOTE The sub-function parameter (SFID) definitions take into account that the most significant bit of the parameter
suppressPosRspMsgIndicationBit is always set to logic state '0' to always force the vehicle server(s) to send a response
message.
6.2 Message byte order
Alphanumeric data will be transmitted with the most significant byte first. Unless otherwise specified,
alphanumeric characters will conform to the ISO Latin 1 ASCII character set as specified in ISO/PAS 27145-2.
4 © ISO 2006 – All rights reserved

7 Emissions-related diagnostic services implementation
7.1 ReadProtocolIdentification (12 hex) service
7.1.1 Service description
The ReadProtocolIdentification service is used by the client to identify the ISO 14229-1 UDS implementation
version. This service shall always be the first service to be expected by the vehicle's emissions-related
systems if an ISO/PAS 27145-5 compliant external test equipment is connected. The response message of
this service provides ISO 14229-1 UDS implementation version information to the external test equipment.
The initial version of ISO 14229-1 publication supports 2-byte data identifiers and 3-byte diagnostic trouble
codes. The harmonisation of the SAE J1939, ISO 15031-5, ISO 14229-1 protocols and the requirements
derived from the GTR provided the need for 3-byte data parameters and 4-byte diagnostic trouble codes.
Which version of the ISO 14229-1 UDS is implemented in the WWH-OBD GTR compliant system in the
vehicle is reported in the response message of this service. The external test equipment requires this
information to properly interpret the data identifiers and diagnostic trouble codes.
IMPORTANT — The server and the client shall meet the request and response message behaviour as
specified in ISO 14229-1.
7.1.2 Request message
7.1.2.1 Request message definition
Table 3 — Request message definition
A_Data byte Parameter Name Cvt Hex Value Mnemonic
#1 ReadProtocolIdentification Request Service Id M 0x12 RPROTID
#2 FunctionalGroupID M 0x00-0xFF FGID
7.1.2.2 Request message sub-function parameter $Level (LEV_) definition
This service does not use a sub-function parameter.
7.1.2.3 Request message data parameter definition
The following data parameter is defined for this service.
Table 4 — Request message data parameter definition
Definition
FunctionalGroupID
The FunctionalGroupIdentifier contains the functional system group e.g. emissions, brakes, all functional system groups, etc. According
to the FunctionalGroupID included in the request message the server shall provide the UDSVersionRecord information in the response
message. The FunctionalGroupIDs are specified in Annex A.1.
7.1.3 Positive response message
7.1.3.1 Positive response message definition
Table 5 — Positive response message definition
A_Data byte Parameter Name Cvt Hex Value Mnemonic
#1 ReadProtocolIdentification Positive Response Service Id M 0x52 RPROTIDPR
#2 FunctionalGroupID M 0x00-0xFF FGID
UDSVersionRecord[] = [  UDSVREC_
#3 Data byte #1 M 0x00-0xFF DB#1
: : : : :
#n Data byte #m ] C 0x00-0xFF DB#m
7.1.3.2 Positive response message data parameter definition
The following data parameters are defined for this service:
Table 6 — Response message data parameter definition
Definition
UDSVersionRecord[]
The UDSVersionRecord consists of an ASCII string according to the ISO/PAS 27145-2 specification (see section: ISO LATIN 1 ASCII
character set). The ASCII string defines the UDS protocol version implemented by the server according to the FunctionalGroupID. The
ASCII string is termined by ASCII character 0x00.
EXAMPLE Differences between ISO 14229-1 publication and version 2.0.0 and beyond:
⎯ 2-byte data identifiers versus 3-byte unified data identifier,
⎯ 3-byte DTC format versus 4-byte DTC format.
ASCII Data byte #1 Data byte #2 Data byte #3 Data byte #4 Data byte #5 Data byte #6
2.0.0 0x32 0x2E 0x30 0x2E 0x30 0x00
7.1.4 Supported negative response codes (NRC_)
The following negative response codes shall be implemented for this service. The circumstances under which
each response code would occur are documented in Table 7.
Table 7 — Supported negative response codes
A_Data byte Description Cvt Mnemonic
0x11 serviceNotSupported SNS
This response code indicates that the requested action will not be taken because the server
does not support the requested service.
The server shall send this response code in case the client has sent a request message with a
service identifier, which is either unknown or not supported by the server.
This response code indicates that service 0x12 is not supported and that the ISO 14229-1 UDS
specification implemented in the server supports the version < 2.0.0.
0x13 incorrectMessageLengthOrInvalidFormat M IMLOIF
The length of the message is wrong
6 © ISO 2006 – All rights reserved

7.1.5 Message flow example ReadProtocolIdentification
The client sends a ReadProtocolIdentification request message to retrieve the UDS version number from the
servers. The emissions-related system consists of two (2) servers. The FunctionalGroupID is set to emissions.
Both servers send a positive response to report the UDSVersionRecord.
Table 8 — ReadProtocolIdentification request message flow example
Message direction: client → server
Message Type: Request
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ReadProtocolIdentification request SID 0x12 RPROTID
#2 FunctionalGroupID (FunctionalGroupID=emissions=0x33) 0x33 FGID
Table 9 — ReadProtocolIdentification positive response message flow example from server#1
Message direction: Server#1 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ReadProtocolIdentification request SID 0x52 RPROTIDPR
#2 FunctionalGroupID (FunctionalGroupID=emissions=0x33) 0x33 FGID
#3 UDSVersionRecord[] = [ ] data byte #1 (2) 0x32 UDSVREC_DB#1
#4 UDSVersionRecord[] = [ ] data byte #2 (.) 0x2E UDSVREC_DB#2
#5 UDSVersionRecord[] = [ ] data byte #3 (0) 0x30 UDSVREC_DB#3
#6 UDSVersionRecord[] = [ ] data byte #4 (.) 0x2E UDSVREC_DB#4
#7 UDSVersionRecord[] = [ ] data byte #5 (0) 0x30 UDSVREC_DB#5
#8 UDSVersionRecord[] = [ ] data byte #6 (ASCII termination byte) 0x00 UDSVREC_DB#6
Table 10 — ReadProtocolIdentification negative response message flow example from server#2
Message direction: Server#2 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 Negative Response SID 0x7F SIDRSIDNRQ
#2 ReadProtocolIdentification request SID 0x12 RPROTID
#3 Negative Response Code: serviceNotSupported 0x11 SNS
Server#2 sends a neagtive response message with NRC 0x11 serviceNotSupported to indicate that the
ISO 14229-1 UDS specification implemented supports the version < 2.0.0.
7.2 ClearDiagnosticInformation (14 hex) service
7.2.1 Service description
The ClearDiagnosticInformation service is used by the client to clear diagnostic information in one or multiple
servers’ memory.
The server shall send a positive response when the ClearDiagnosticInformation service is completely
processed. The server shall send a positive response even if no DTCs are stored. The server shall support an
additional copy of permanentDTC status information in memory. Individual DTCs are erased by the server
DTC monitoring logic if successfully executed with a 'pass' result. The permanentDTC status information
within a server's memory shall neither be possible to be cleared by an external test equipment nor by a battery
disconnect. Additional copies, e.g. backup copy in long-term memory, are updated according to the
appropriate backup strategy (e.g. in the power-latch phase).
NOTE In case the power-latch phase is disturbed (e.g., a battery disconnect during the power-latch phase) this may
cause data inconsistency.
The request message of the client contains the parameter groupOfDTC which allows the client to clear a
functional system group of DTCs (e.g., emissions), or a specific DTC.
This service provides means for the external test equipment to command servers to clear all diagnostic
information related to the functional group identifier included in the request message.
For the emissions functional system group the following diagnostic information shall be cleared:
⎯ MIL and number of diagnostic trouble codes,
⎯ I/M (Inspection/Maintenance) readiness bits,
⎯ Confirmed diagnostic trouble codes,
⎯ Pending diagnostic trouble codes,
⎯ Diagnostic trouble code for snapshot record data,
⎯ Snapshot record data,
⎯ Status of system monitoring tests,
⎯ On-board monitoring test results,
⎯ Distance travelled while MIL is activated,
⎯ Number of warm-ups since DTCs cleared,
⎯ Distance travelled since DTCs cleared,
⎯ Time run by the engine while MIL is activated,
⎯ Time since diagnostic trouble codes cleared,
⎯ Reset misfire counts of standardized Test ID 0x0B to zero,
⎯ DTC status byte,
⎯ captured DTC extended data (DTCExtendedData, ReadDTCInformationX),
⎯ other DTC related data such as first/most recent DTC, flags, counters, timers, etc. specific to DTCs.
Other manufacturer specific “clearing/resetting” actions may also occur in response to this request message. If
any of the above requirements is in conflict with the applicable local regulation the legislated requirements
supersede.
8 © ISO 2006 – All rights reserved

DTC information reset / cleared via this service includes but is not limited to the following:
⎯ Permanent DTCs shall be stored in non-volatile memory. These DTCs cannot be cleared by any test
equipment (e.g. on-board tester, off-board tester) or by simply disconnecting the vehicle's battery. The
OBD system shall clear these DTCs itself by completing and passing the on-board monitor.
⎯ Permanent DTCs shall be erasable if the server is reprogrammed and the readiness status for all
monitored components and systems are set to “not complete.”
IMPORTANT — The server and the client shall meet the request and response message behaviour as
specified in ISO 14229-1.
7.2.2 Request message
7.2.2.1 Request message definition
Table 11 — Request message definition
A_Data byte Parameter Name Cvt Hex Value Mnemonic
#1 ClearDiagnosticInformation Request Service Id M 0x14 CDTCI
groupOfDTC[] = [  GODTC_
#2 groupOfDTCHighByte M 0x00-0xFF HB
#3 groupOfDTCMiddleHighByte M 0x00-0xFF MHB
#4 groupOfDTCMiddleLowByte M 0x00-0xFF MLB
#5 groupOfDTCLowByte ] M 0x00-0xFF LB
7.2.2.2 Request message sub-function parameter definition
There are no sub-function parameters used by this service.
7.2.2.3 Request message data parameter definition
The following data parameter is defined for this service.
The groupOfDTC parameter is compatible to the DTC format in the DTCHighByte, DTCMiddleHighByte
and DTCMiddleLowByte. Depending on the value contained in these bytes the DTCLowByte either contains
the FunctionalGroupIdentifier or the FailureTypeByte/FailureModeIdentifier (see Table 12). The
FunctionalGroupIdentifier contains the functional system group e.g. emissions, brakes, all functional system
groups, etc. If a server supports multiple functional system groups in a single server the external test
equipment can clear the DTCs of the selected functional system group. The FunctionalGroupID has been
introduced to distinguish commands send by the test equipment between different functional system groups
within an electrical architecture which consists of many different ECUs. If an ECU has implemented software
of the emissions system as well as other systems which may be inspected during a an I/M test it is important
that only the DTC information of the requested functional system group is reported. An I/M test should not be
failed because another functional system group has DTC information stored.
NOTE While there is not a complete list of FunctionalGroupIdentifiers at the time the specification is published, this
will be a growing list influenced by future legislation (e.g. future defined WWH-OBD GTR modules).
Table 12 — Request message data parameter definition
Definition
groupOfDTC
This parameter contains a 4-byte value indicating the group of DTCs or the particular DTC to be cleared. The groupOfDTC parameter is
compatible to the decoding of the 4-byte DTC format as defined in ISO/PAS 27145-2.
'x' = {0b,1b}, defines either bit state.
Bit 31 … 28 Bit 27 DTC format Bit 26 … 8 (BaseDTC#) Bit 7 … 0 groupOfDTC description
0000b 0b Legacy SAE J1939 111 11111111 11111111b
Clears all DTCs related to functional
0001b 0b Legacy ISO 15031-6 111 11111111 11111111b
Functional-
group e.g. emissions or all functional
GroupID
0010b 0b Unified DTC 111 11111111 11111111b
system groups (see Annex A.1)
1010b 0b Manufacturer DTC 111 11111111 11111111b
Clears individual DTC. Legacy
0000b 0b Legacy SAE J1939 XXX XXXXXXXX XXXXXXXXb 000XXXXXb
FailureModeIdentifier of SAE J1939.
Clears individual DTC. Always include
0001b 0b Legacy ISO 15031-6 000 XXXXXXXX XXXXXXXXb 00000000b
0x00.
Clears individual DTC. Legacy
0001b 0b Legacy ISO 14229-1 000 XXXXXXXX XXXXXXXXb XXXXXXXXb
FailureTypeByte of ISO 15031-6.
Clears individual DTC. Unified
0010b 0b Unified DTC XXX XXXXXXXX XXXXXXXXb XXXXXXXXb
FailureTypeByte of ISO/PAS 27145-2.
Clears individual DTC. Unified
1010b 0b Manufacturer DTC XXX XXXXXXXX XXXXXXXXb XXXXXXXXb
FailureTypeByte of ISO/PAS 27145-2.
7.2.3 Positive response message
7.2.3.1 Positive response message definition
Table 13 — Positive response message definition
A_Data byte Parameter Name Cvt Hex Value Mnemonic
#1 ClearDiagnosticInformation Positive Response Service Id M 0x54 CDTCIPR
7.2.3.2 Positive response message data parameter definition
There are no data parameters used by this service in the positive response message.
7.2.4 Supported negative response codes (NRC_)
The negative response codes for this service shall be implemented as specified in ISO 14229-1.
7.2.5 Message flow examples of ClearDiagnosticInformation
7.2.5.1 Clear SAE J1939-73, ISO 15031-6, ISO/PAS 27145-2 DTC information
7.2.5.1.1 SAE J1939 to ISO/PAS 27145-2 mapping example
The first part of this example maps an SAE J1939-73 defined SPN in the ISO/PAS 27145-2 defined legacy
DTC format. The SAE J1939-73 defined SPN 1208d represents the “Pre-Filter Oil Pressure”.
10 © ISO 2006 – All rights reserved

Table 14 — SAE J1939-73 defined DTC example
DTC description Mnemonic Decimal Hexadecimal Binary
000 00000100 10111000 (19 bits)
Suspect Parameter Number SPN 1208 0x04B8
00011 (5 bits)
Failure Mode Identifier FMI 3 0x3
0001010 (7 bits)
Occurrence Count OC 10 0xA
Conversion Method CM — — 0 (1 bit)
The example shows:
⎯ The server defined SAE J1939-73 DTC format and values,
⎯ The reformatted DTC data bytes in the SAE J1939-73 CAN frame and values,
⎯ The reformatted DTC data bytes in the ISO/PAS 27145-2 defined unified DTC format and values.
All fields in the SAE J1939-73 CAN frame are sent in Intel Format (least significant byte first).
Table 15 — SAE J1939-73 defined DTC representation in CAN data frame for Diagnostic Mode 1
SAE J1939-73 defined DTC
CAN frame data byte #3 CAN frame data byte #4 CAN frame data byte #5 CAN frame data byte #6
3 most significant bits of
8 least significant bits of Second byte of SPN
SPN and the FMI
SPN
(bit 7 SPN MSB and bit 4
(bit 7 most significant) (bit 7 most significant)
FMI MSB
C
SPN FMI OC
M
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
1 0 1 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 0 1 0
Figure 1 — Mapping example from native SAE J1939-73 SPN & FMI to ISO/PAS 27145-2 UDTC format
shows an example about mapping a native SAE J1939-73 defined DTC into an ISO/PAS 27145-2 defined
unified DTC format.
SAE J1939 DTC format (32 bits)
SPN 1208 0x4B8 000 00000100 10111000 b (19 bits)
FMI 3 0x3 00011 b (5 bits)
OC 10 0xA 0001010 b (7 bits)
CM 0b (1 bit)
SAE J1939-73 DTC Number Format
C
19 bits SPN / BaseDTC 5 bits FMI OC
M
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 0 1 0
Byte 5
Byte 3 Byte 4
3 most
Byte 6
(8 least significant bits of SPN) (2nd byte of SPN)
significant 5 bit
Bits of SPN
C
SPN FMI OC
M
SAE J1939-73 DTC CAN Frame Format (0xB8, 0x04, 0x03, 0x0A)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 0 1 0
ISO 27145 Unified DTC Format (0x00, 0x04, 0xB8, 0x03)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1
DTCHighByte DTCMiddleHighByte DTCMiddleLowByte DTCLowByte
4 bits x 19 bits BaseDTC Number 8 bits Unified FailureTypeByte
Page Select
Category Bit:
= 0000b
Unified DTC format (32 bits)
0 = BaseDTC/SPN
Figure 1 — Mapping example from native SAE J1939-73 SPN & FMI to ISO/PAS 27145-2 UDTC format
12 © ISO 2006 – All rights reserved

msb
lsb
msb
lsb
7.2.5.1.2 Erase all emissions-related system DTCs/SPNs in all functional system groups example
The client sends a ClearDiagnosticInformation request message to erase all emissions-related system
DTCs/SPNs. The emissions-related system consists of two (2) servers. The FunctionalGroupID is set to
emissions. Both servers send a positive response to confirm that they have cleared all emissions system DTC
information.
Table 16 — ClearDiagnosticInformation request message flow example
Message direction: client → server
Message Type: Request
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation request SID 0x14 CDTCI
#2 groupOfDTC [ DTCHighByte ] DTCHB
⎯ SAE J1939-73: page '0' (0000 0111b) 0x07
⎯ ISO 15031-6: page '1' (0001 0111b) 0x17
⎯ ISO/PAS 27145-2: page '2' (0010 0111b) 0x27
#3 groupOfDTC [ DTCMiddleHighByte ] 0xFF DTCMHB
#4 groupOfDTC [ DTCMiddleLowByte ] 0xFF DTCMLB
#5 groupOfDTC [ DTCLowByte ] (FunctionalGroupID=emissions=0x33) 0x33 DTCLB
Table 17 — ClearDiagnosticInformation positive response message flow example from server#1
Message direction: Server#1 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation response SID 0x54 CDTCIPR
Table 18 — ClearDiagnosticInformation positive response message flow example from server#2
Message direction: Server#2 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation response SID 0x54 CDTCIPR
7.2.5.2 Clear individual SAE J1939-73, ISO 15031-6, ISO/PAS 27145-2 DTC information
The client sends a ClearDiagnosticInformation request message to erase an individual emissions-related
system DTC/SPN. The emissions-related system consists of two (2) servers. Both servers send a positive
response to confirm that they have cleared the emissions system DTC information.
Table 19 — ClearDiagnosticInformation request message flow example
Message direction: client → server
Message Type: Request
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation request SID 0x14 CDTCI
#2 groupOfDTC [ DTCHighByte ] DTCHB
⎯ SAE J1939-73: page '0' (0000 0000b) 0x00
⎯ ISO 15031-6: page '1' (0001 0000b) 0x10
⎯ ISO/PAS 27145-2: page '2' (0010 0111b) 0x27
#3 groupOfDTC [ DTCMiddleHighByte ] DTCMHB
⎯ SAE J1939-73: SPN 1208 (0x4B8) Pre-Filter Oil Pressure 0x04
⎯ ISO 15031-6: P0486 Exhaust Gas Recirculation Sensor 'B' Circuit 0x04
⎯ ISO/PAS 27145-2: page '2', DTC name to be defined in future release 0x12
#4 groupOfDTC [ DTCMiddleLowByte ] DTCMLB
⎯ SAE J1939-73: SPN 1208 (0x4B8) Pre-Filter Oil Pressure 0xB8
⎯ ISO 15031-6: P0486 Exhaust Gas Recirculation Sensor 'B' Circuit 0x86
⎯ ISO/PAS 27145-2: page '2', DTC name to be defined in future release 0x34
#5 groupOfDTC [ DTCLowByte ] FMI/FTB: e.g. Voltage Above Normal (SAE J1939) 0x03 DTCLB
Table 20 — ClearDiagnosticInformation positive response message flow example from server#1
Message direction: Server#1 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation response SID 0x54 CDTCIPR
Table 21 — ClearDiagnosticInformation positive response message flow example from server#2
Message direction: Server#2 → client
Message Type: Response
A_Data Byte Description (all values are in hexadecimal) Byte Value Mnemonic
#1 ClearDiagnosticInformation response SID 0x54 CDTCIPR
14 © ISO 2006 – All rights reserved

7.3 ReadDTCInformation (19 hex) service
7.3.1 Service description
This service allows a client to read the status of server resident Diagnostic Trouble Code (DTC) information
from any server, or group of servers within a vehicle.
This service allows the client to do the following:
⎯ Retrieve the number of system DTCs matching a client defined DTC status mask.
⎯ Retrieve the list of all system DTCs matching a client defined DTC status mask.
⎯ Retrieve all DTCs with “permanentDTC” status from the emissions-related system. These DTCs have
been previously cleared by the ClearDiagnosticInformation service but remain in the non-volatile memory
of the server until the appropriate monitors for each DTC have successfully passed.
⎯ Retrieve DTCSnapshot data (one or multiple Freeze Frames) associated with a client defined DTC and
status mask combination: DTC Snapshots are specific data records associated with a DTC, that are
stored in the server's memory. The typical usage of DTC Snapshots is to store data upon detection of a
system malfunction. The DTC Snapshots will act as a snapshot of data values from the time of the
system malfunction occurrence. The data parameters stored in the DTC Snapshot shall be associated to
the DTC. The DTC specific data parameters are intended to ease the fault isolation process by the
technician. The whole DTCSnapshor data record is defined in ISO/PAS 27145-2 but consists of different
parts which are separately defined in ISO/PAS 27145-2. A standard and a DTC specific set of parameters
shall be included in each DTC specific DTCSnapshot data record.
⎯ Retrieve DTCExtendedData associated with a client defined DTC and status mask combination out of the
DTC memory or the DTC mirror memory. DTCExtendedData consist of extended status information
associated with a DTC. DTCExtendedData contains DTC parameter values, which have been identified at
the time of the request. A typical use of DTCExtendedData is to store dynamic data associated with the
DTC, e.g.
⎯ DTC B1 Malfunction Indicator counter which conveys the amount of time (number of engine
operating hours) during which the OBD system has operated while a malfunction is active,
⎯ DTC Occurrence Counter, counts number of driving cycles in which “testFailed” has been reported,
⎯ DTC aging counter, counts number of driving cycles since the fault was latest failed excluding the
driving cycles in which the test has not reported “testPassed” or “testFailed”,
⎯ specific counters for OBD (e.g. number of remaining driving cycles until the “check engine” lamp is
switched off if driving cycle can be performed in a fault free mode),
⎯ time of last occurrence (etc.),
⎯ test failed counter, counts number of reported “test failed” and possible other counters if the
validation is performed in several steps,
⎯ uncompleted test counter, counts number of driving cycles since the test was latest c
...