ISO 27145-2:2012 – WWH-OBD Common Data Dictionary for Vehicle Diagnostics

Standardized data definitions, diagnostic trouble codes, and presentation layer specifications for global OBD systems

Introduction to ISO 27145-2:2012

ISO 27145-2:2012 defines the common data dictionary for the World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements. As Part 2 of the ISO 27145 series, this standard plays a critical role in the presentation layer (Layer 6) of the WWH-OBD OSI-based communication architecture, specifying how diagnostic data is identified, encoded, and interpreted by both vehicle on-board systems and external test equipment.

Prepared by ISO/TC 22 Subcommittee SC 3, this first edition cancels and replaces ISO/PAS 27145-2:2006. The standard references several SAE digital annexes including SAE J1930-DA (terms and definitions), SAE J1979-DA (diagnostic test modes), SAE J2012-DA (diagnostic trouble code definitions), and the SAE J1939 Companion Spreadsheet (SPNs and FMIs).

ISO 27145-2 is the key reference for anyone implementing WWH-OBD diagnostic software. It defines the actual data payload format that travels across the communication stack — understanding this standard is essential for correctly encoding and decoding diagnostic messages.

Data Identifier Architecture

The core of ISO 27145-2 is its comprehensive data identifier architecture, which provides a structured framework for categorizing and accessing all diagnostic data elements within the WWH-OBD system. The standard defines five categories of data identifiers.

Identifier Type Acronym Purpose Example
Data Identifier DID General vehicle data parameters Vehicle speed, engine RPM, coolant temperature
Parameter Identifier PID Emissions-related powertrain data Oxygen sensor voltage, fuel trim values
Monitor Identifier MID OBD monitor status information Catalyst monitor, EVAP system monitor
InfoType Identifier ITID Vehicle information and identification VIN, ECU software version, calibration ID
Routine Identifier RID On-vehicle diagnostic routines Actuator tests, on-board component tests

The standard defines the data range layout for each identifier type, specifying the bit-level encoding of parameters, scaling factors, and unit conventions. This ensures that the same diagnostic parameter (e.g., engine coolant temperature) is interpreted identically regardless of which vehicle manufacturer or test equipment supplier is involved.

The use of separate identifier categories (DID, PID, MID, ITID, RID) provides a logical organization that simplifies both implementation and troubleshooting. When diagnosing a fault, the technician can quickly determine which category of data is relevant — monitor status (MID) for system readiness, parameter data (PID) for live sensor values, or diagnostic routines (RID) for component testing.

Diagnostic Trouble Code (DTC) Framework

ISO 27145-2 establishes a comprehensive framework for Diagnostic Trouble Codes (DTCs) that integrates two major DTC definition systems: the SAE J2012-DA format (commonly used in light-duty vehicles) and the SAE J1939-73 format (typically used in heavy-duty vehicles).

DTC Structure and Presentation

Component SAE J2012-DA Format SAE J1939-73 Format
Code structure 1 letter + 4 digits (e.g., P0301) SPN (Suspect Parameter Number) + FMI (Failure Mode Identifier)
Code range Powertrain (P), Chassis (C), Body (B), Network (U) SPN range: 0-524287, FMI range: 0-31
Failure type FTB (Failure Type Byte) FMI directly encodes failure type
Resolution Standardized by SAE J2012-DA committee Standardized in SAE J1939-73 Appendix A
Extended data DTCExtendedDataRecord (per Annex D) SPN-specific extended data

The standard specifies a DTC range layout that allocates specific code ranges for different fault categories and provides a mechanism for OEM-specific DTCs alongside globally standardized codes. This balanced approach ensures that universally recognized fault codes exist for common emissions-related failures while allowing manufacturers to define codes for proprietary systems.

WWH-OBD requires support for both J2012-DA and J1939-73 DTC formats. Test equipment must be capable of interpreting both formats and presenting them in a unified manner to the technician. Failure to handle both formats correctly can result in missed diagnostic information, particularly in mixed vehicle fleets.

Presentation Layer Requirements

As the presentation layer (Layer 6) standard for WWH-OBD, ISO 27145-2 specifies how data from higher-layer diagnostic services (ISO 14229-1) is encoded into the format transmitted over the network. This includes:

Data encoding rules — specifying how diagnostic parameters are converted between their physical representation (e.g., 100.5 kPa) and their on-the-wire format (e.g., a 16-bit integer with specific scaling). The encoding rules cover signed and unsigned integers, bit-mapped status fields, ASCII strings, and manufacturer-specific data formats.

DID and RID data record definitions — providing templates for how each data identifier and routine identifier is structured, including byte ordering, update rates, and conversion formulas. Annex A of the standard provides normative definitions for supported DIDs and RIDs, while Annex B defines mandatory DIDs that all WWH-OBD-compliant server/ECU implementations must support.

GTR WWH-OBD emissions system parameters — Annex C (informative) catalogs the emissions-related system parameters required by the WWH-OBD Global Technical Regulations, mapping regulatory requirements to specific DID/PID/MID definitions in the data dictionary.

A common source of interoperability issues in WWH-OBD implementations is incorrect byte ordering in multi-byte parameters. ISO 27145-2 follows the network byte order (big-endian) convention for all multi-byte data elements. Little-endian implementations in embedded ECUs must properly convert data before transmission.

Engineering Design Insights

Implementing the ISO 27145-2 common data dictionary requires careful attention to several engineering considerations. The standard references the SAE digital annex revision procedure, which allows new data items to be defined through a change request process. This means that the data dictionary is a living document that evolves with automotive technology — electric vehicle parameters, advanced driver assistance system (ADAS) diagnostics, and connected vehicle data are continually being added.

For ECU developers, the mandatory DID requirements in Annex B define a baseline set of diagnostic data that all WWH-OBD-compliant ECUs must support. This includes vehicle identification information, OBD system status, and emissions-related data. Designing for compliance requires implementing at least these mandatory DIDs, with optional DIDs added based on the specific ECU functionality.

The DTC Extended Data Record definition (Annex D) provides a standardized format for attaching environmental data (freeze frame) to diagnostic trouble codes. This is critical for effective diagnosis — when a fault is detected, the system captures the vehicle operating conditions at the time of the failure, enabling technicians to understand the circumstances that triggered the code.

When designing a WWH-OBD test tool, implement a flexible data parsing engine that can handle both the current and future DID definitions. Since the SAE digital annexes evolve independently of the ISO standard, your tool should be able to download and incorporate updated data dictionaries without requiring a complete software update.

Frequently Asked Questions

Q1: What is the difference between a DID and a PID in ISO 27145-2?
A: A Data Identifier (DID) is a general category for vehicle data parameters, while a Parameter Identifier (PID) is a specific subtype of DID used for emissions-related powertrain data. In practice, PIDs are typically associated with live sensor data (oxygen sensor voltage, fuel trim, etc.) while DIDs cover a broader range of vehicle data including non-powertrain systems.
Q2: How does ISO 27145-2 handle manufacturer-specific diagnostic data?
A: The standard defines a range of identifier values reserved for manufacturer-specific use. OEMs can define proprietary DIDs, PIDs, and DTCs within these ranges. The standard also provides mechanisms for encoding manufacturer-specific data within the generic data record format, ensuring that external test equipment can at minimum identify the presence of proprietary data even if it cannot interpret the specific meaning.
Q3: What is the role of the SAE digital annexes in ISO 27145-2?
A: The SAE digital annexes (J1979-DA, J2012-DA, J1930-DA) contain the actual definitions of data identifiers, diagnostic trouble codes, and terms referenced by ISO 27145-2. Rather than duplicating this content, ISO 27145-2 references these annexes as the authoritative sources. This separation allows SAE to update the data definitions through their established revision process without requiring revision of the ISO standard itself.
Q4: Can ISO 27145-2 support future vehicle technologies like fuel cell vehicles?
A: Yes. The data dictionary architecture is extensible. New PIDs, DIDs, and MIDs can be defined through the SAE digital annex revision process to cover emerging technologies such as fuel cell stack diagnostics, hydrogen storage system monitoring, and solid-state battery management parameters.

Leave a Reply

Your email address will not be published. Required fields are marked *