Understanding OBD2 ISO Standards in Automotive Diagnostics

Need a straightforward and practical guide to OBD2?

This article offers an in-depth introduction to the On-Board Diagnostics (OBD2) protocol, with a specific focus on Obd2 Iso standards. We’ll explore the OBD2 connector, OBD2 Parameter IDs (PIDs), and its crucial link to the Controller Area Network (CAN) bus, all while emphasizing the relevance of OBD2 ISO in modern vehicle diagnostics.

This is more than just a basic overview; it’s a practical intro. You’ll learn how to request and interpret OBD2 data, understand essential logging applications, and gain actionable tips for working with OBD2 ISO compliant systems.

Discover why this has become a highly regarded resource for understanding OBD2 ISO and automotive diagnostics.

You can also watch our OBD2 introduction video above – or download the PDF guide

Article Contents:

Author: Martin Falch (Updated January 2025)

Download as PDF

What is OBD2 and Why is OBD2 ISO Important?

OBD2, or On-Board Diagnostics II, is essentially your car’s internal health monitoring system. It’s a standardized protocol that, importantly, is underpinned by OBD2 ISO standards. These standards are crucial because they ensure consistency and interoperability across different vehicle manufacturers when it comes to accessing diagnostic trouble codes (DTCs) and real-time vehicle data via the OBD2 connector.

You’ve likely already encountered OBD2 in action:

Ever seen the malfunction indicator light, often called the “check engine light,” illuminate on your dashboard?

That’s your vehicle signaling a potential problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.

To do this, the mechanic connects the OBD2 reader to the standardized OBD2 16-pin connector, typically located near the steering wheel. The tool then sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain valuable information such as speed, fuel level, or Diagnostic Trouble Codes (DTCs). This standardized communication, defined by OBD2 ISO, allows for faster and more efficient troubleshooting.

OBD2 Compatibility: Does Your Car Support OBD2 ISO?

The short answer is: Most likely, yes!

The vast majority of modern non-electric vehicles are OBD2 compliant, and most operate using the CAN bus protocol, which is a key component of OBD2 ISO standards. However, for older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A reliable way to check for compliance is to consider the vehicle’s market and year of manufacture:

A Brief History of OBD2 and the Role of OBD2 ISO

The origins of OBD2 trace back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emissions monitoring.

The OBD2 ISO standard, crucial for global adoption, was developed based on recommendations from the Society of Automotive Engineers (SAE). These standards, including SAE J1962 for the connector, aimed to standardize DTCs and the OBD connector across all manufacturers.

The implementation of OBD2 ISO standards was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Extended to diesel cars in the EU (known as EOBD – European On-Board Diagnostics).
2005: OBD2 was mandated in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2, solidifying OBD2 ISO‘s role.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

The Future of OBD2: Trends and OBD2 ISO Evolution

OBD2, and by extension OBD2 ISO, is expected to remain a cornerstone of vehicle diagnostics. However, its form and application are evolving.

Key trends shaping the future of OBD2 include:

Initially, legislated OBD2 was primarily for emissions control and testing. Consequently, electric vehicles (EVs) aren’t mandated to support OBD2 in its traditional form. In fact, most modern EVs largely bypass standard OBD2 requests, opting for OEM-specific UDS communication. This shift often makes it challenging to access data from EVs unless decoding methods are reverse-engineered, as demonstrated in our case studies for electric cars including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Recognizing the limitations of current OBD2 implementations in terms of data richness and lower-layer protocols, advancements like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These modern alternatives aim to improve OBD communication by building upon the UDS protocol. For a deeper understanding, refer to our introduction to UDS.

In our increasingly connected world, traditional OBD2 emission checks can seem inefficient. Manual inspections are both time-consuming and costly.

The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to all cars, similar to those used for bridge tolls. This would allow for the wireless transmission of the car’s vehicle identification number (VIN) and DTCs to a central server for automated checks.

Many existing devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate CAN or OBD2 data transfer via WiFi/cellular networks.

While offering cost savings and convenience, OBD3 raises political concerns related to surveillance.

Originally intended for stationary emission controls, OBD2 is now widely used by third parties to access real-time vehicle data via OBD2 dongles, CAN loggers and similar tools. However, the German automotive industry is considering changes that could restrict this access German car industry plans close OBD interface:

OBD was designed for car servicing in repair shops, not for third parties to build a data-driven economy on its access.

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves disabling OBD2 functionality while driving and centralizing data collection with manufacturers. This would give manufacturers control over automotive big data.

Security concerns, such as reducing the risk of car hacking, are cited as justification, although many view it as a commercially motivated move. The future of this trend remains uncertain but could significantly impact the market for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

Our comprehensive ‘Ultimate CAN Guide’ consolidates 12 ‘simple intros’ into a 160+ page PDF:

Download now

Delving into OBD2 ISO Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol, much like a language. CAN functions as the communication method, similar to a telephone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Crucially, OBD2 ISO standards define critical aspects of OBD2, including the OBD2 connector, lower-layer protocols, and OBD2 Parameter IDs (PIDs).

These standards can be categorized using the 7-layer OSI model. The following sections will focus on the most significant OBD2 ISO standards.

In the OSI model, note the overlap between SAE and ISO standards. This reflects the development of OBD standards in the USA (SAE) and Europe (ISO). Several standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

The OBD2 Connector: SAE J1962 and OBD2 ISO 15031-3

The 16-pin OBD2 connector is the physical interface for accessing vehicle data and is specified by both SAE J1962 and OBD2 ISO 15031-3.

The illustration shows a Type A OBD2 pin connector (also known as Data Link Connector, or DLC).

Key points to remember about the OBD2 connector:

It’s typically located near the steering wheel, but can be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout varies depending on the communication protocol used.
CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are usually connected.

OBD2 Connector Types: A vs. B

You may encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles.

Both types share similar OBD2 pinouts but differ in power supply output: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Type B OBD2 connectors have a distinguishing interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, while a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus: ISO 15765-4 and OBD2 ISO Integration

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as dictated by OBD2 ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) is a set of specifications based on the CAN standard (ISO 11898).

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are reserved for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
OBD2 adapter cable length is limited to 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit)

OBD2 communication always involves request/response message pairs.

Most cars use 11-bit CAN IDs for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data on a requested parameter (as per ISO 15765-4). CAN IDs from 0x7E0 to 0x7E7 are for ‘Physical Addressing’ requests to specific ECUs, which is less common.

ECUs respond using 11-bit IDs from 0x7E8 to 0x7EF. The most frequent response ID is 0x7E8 (ECM – Engine Control Module), followed by 0x7E9 (TCM – Transmission Control Module).

Some vehicles, particularly vans and medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.

In 29-bit CAN, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses will use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 vs. OEM-Specific CAN Protocols

It’s essential to understand that your vehicle’s electronic control units (ECUs) operate using OEM-proprietary CAN protocols, independent of OBD2. Each OEM develops unique CAN protocols specific to vehicle brand, model, and year. This OEM-specific data is generally inaccessible to third parties without reverse engineering (reverse engineer CAN bus data).

Connecting a CAN bus data logger to the OBD2 connector may reveal OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts access to this CAN data, allowing only OBD2 communication through the OBD2 connector.

In essence, OBD2 is an additional, higher-layer protocol functioning alongside the OEM-specific protocol.

Bit-Rate and ID Validation in OBD2 ISO Systems

As outlined by OBD2 ISO, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential combinations. Modern vehicles commonly use 500K and 11-bit IDs. External diagnostic tools should systematically verify these parameters.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method utilizes the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rate transmissions will cause CAN error frames.

Newer versions of ISO 15765-4 acknowledge that vehicles might support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) compared to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS, testing tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks and buses.

Five Lower-Layer OBD2 Protocols

CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 in modern vehicles.

However, older vehicles (pre-2008) might use one of four other lower-layer protocols. Pinouts can help determine the protocol used in these vehicles:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ Asian cars.
ISO 9141-2: Used in EU, Chrysler, and Asian cars (2000-04).
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages (ISO 15765-2) within OBD2 ISO Framework

All OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol, a key part of the OBD2 ISO framework. ISO-TP enables the transmission of data payloads exceeding the 8-byte CAN frame limit. This is crucial in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For detailed information, see our introduction to UDS.

However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) messages. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related data.

The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5, and OBD2 ISO Standards

To understand OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message comprises an identifier, a data length indicator (PCI field), and the data itself. The data is further structured into Mode, Parameter ID (PID), and data bytes. These elements are all defined within OBD2 ISO standards.

Example: OBD2 Request/Response Sequence

Consider a request/response example for ‘Vehicle Speed’.

An external tool sends a request message to the vehicle with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

Using OBD2 PID 0x0D decoding rules, we find the physical value is 50 km/h.

Next, we’ll detail OBD2 modes and PIDs, crucial components within OBD2 ISO specifications.

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, or modes. Mode 0x01 provides current real-time data, while others are used to access and clear diagnostic trouble codes (DTCs) or retrieve freeze frame data. These modes are integral to the OBD2 ISO framework.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes outside of these standardized ones.

In OBD2 messages, the mode is located in the second byte. In a request, the mode is included directly (e.g., 0x01). In the response, 0x40 is added to the mode value (e.g., resulting in 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

For example, mode 0x01 includes ~200 standardized PIDs providing real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of the available OBD2 PIDs within each mode. The standardization of PIDs is a key aspect of OBD2 ISO.

One PID holds a special significance.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the ECU indicates its support for PIDs 0x01-0x20. PID 0x00 is therefore a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Practical Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 (core OBD2 ISO documents) detail the scaling information needed to decode standard OBD2 PIDs into physical values (decode CAN data).

For quick lookups of mode 0x01 PIDs, utilize our OBD2 PID overview tool. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data Compliant with OBD2 ISO

This section provides a practical guide on logging OBD2 data using the CANedge CAN bus data logger, ensuring adherence to OBD2 ISO principles.

The CANedge allows configuration of custom CAN frame transmissions, making it suitable for OBD2 logging.

Once set up, connect the device to your vehicle using our OBD2-DB9 adapter cable.

Analyze responses to ‘Supported PIDs’ in asammdf

Step #1: Bit-rate, ID, and Supported PID Validation (OBD2 ISO Compliance Check)

As per ISO 15765-4, determine the correct bit-rate and IDs for your vehicle. Use the CANedge to test as follows (refer to the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500K and confirm successful transmission (if unsuccessful, try 250K).
Use the validated bit-rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and review the responses.
Determine 11-bit vs. 29-bit IDs based on response IDs.
Identify supported PIDs from the response data.

We provide plug-and-play configurations to simplify these tests, ensuring OBD2 ISO compliance from the outset.

Most non-EV cars manufactured in 2008 or later support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common when using the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. Subsequent ‘Supported PIDs’ requests typically elicit fewer ECU responses. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, potentially reducing busload by directing subsequent communication to this specific ECU using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests for OBD2 ISO Logging

Once you’ve identified supported OBD2 PIDs, bit-rate, and CAN IDs, configure your transmit list with the desired PIDs.

Consider these factors for efficient OBD2 ISO compliant logging:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload and ensure reliable responses.
Battery Drain: Implement triggers to halt transmission when the vehicle is inactive, preventing ECU ‘wake-up’ and battery drain.
Filters: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present.

With these configurations, your device is ready to log raw OBD2 data in accordance with OBD2 ISO standards!

Example CANedge OBD2 PID request list

Visualize DBC-decoded OBD2 data using asammdf

Step #3: DBC Decoding of Raw OBD2 Data for OBD2 ISO Analysis

To analyze and visualize logged data, decode the raw OBD2 data into physical values (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools, ensuring OBD2 ISO compatibility.

Decoding OBD2 data is more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). The CAN ID alone is insufficient to identify the payload signals.

Therefore, signal identification requires using the CAN ID, OBD2 mode, and OBD2 PID. This form of multiplexing, termed ‘extended multiplexing‘, can be implemented in DBC files.

CANedge: Your OBD2 ISO Compliant Data Logger

The CANedge enables easy OBD2 data recording to an 8-32GB SD card. Connect it to a car or truck to begin logging and decode data using free software/APIs and our OBD2 DBC, all while adhering to OBD2 ISO standards.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples and OBD2 ISO ISO-TP

All OBD2 data transmission utilizes ISO-TP (transport protocol) as per ISO 15765-2, a critical part of the OBD2 ISO suite. While previous examples focused on single-frame communication, this section explores multi-frame examples.

Multi-frame OBD2 communication requires flow control frames (UDS intro). A static flow control frame transmitted approximately 50 ms after the initial request frame can manage this, as demonstrated in the CANedge configuration example.

Analyzing multi-frame OBD2 responses requires CAN software/API tools that support ISO-TP, such as CANedge MF4 decoders, ensuring full OBD2 ISO compatibility.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is essential for telematics and diagnostics (UDS intro). Retrieve the VIN using OBD2 mode 0x09 and PID 0x02:

The tester tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, representing the Number Of Data Items (NODI), in this case 1 (ISO 15031-5 / SAE J1979). The subsequent 17 bytes are the VIN, convertible from HEX to ASCII.

Example 2: OBD2 Multi-PID Request (6x)

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. ECUs respond with data for supported PIDs (omitting unsupported ones) potentially across multiple frames via ISO-TP, always within OBD2 ISO guidelines.

This method enhances data collection efficiency, but signal encoding becomes request-specific, complicating the use of generic OBD2 DBC files. We generally advise against this method. Here’s an example trace:

The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. PIDs are often ordered as requested, though not strictly mandated by ISO 15031-5.

Decoding this response via generic DBC files is challenging. We don’t recommend this approach for practical data logging unless using tools with built-in support. It involves extended multiplexing, requiring a DBC file to account for PID-specific payload positions, which is difficult to generalize across vehicles with varying PID support. Handling multiple multi-PID requests further complicates DBC management.

Custom scripts, potentially combined with recording transmit messages, could offer a workaround by interpreting responses based on requests. However, such methods are difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) and OBD2 ISO DTC Standards

OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) retrieves emissions-related DTCs. No PID is included in the request. Responding ECUs indicate the number of stored DTCs (potentially zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs. OBD2 ISO standards define DTC formats and categories.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

The example below illustrates a request to an ECU with 6 stored DTCs.

OBD2 Data Logging: Use Case Examples in Line with OBD2 ISO

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

OBD2 data helps reduce fuel costs, improve driving habits, test prototype parts, and optimize insurance models.

obd2 logger

Real-Time Car Diagnostics

OBD2 interfaces stream human-readable data in real-time for diagnosing vehicle issues.

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers monitor cars and light trucks in the cloud to predict and prevent breakdowns.

predictive maintenance

Vehicle Black Box Logger

OBD2 loggers serve as ‘black boxes’ for vehicles or equipment, providing data for disputes or diagnostics.

can bus blackbox

Have an OBD2 data logging use case? Contact us for expert consultation!

Explore our guides section for more introductions or download the ‘Ultimate Guide’ PDF.

Need to log/stream OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us

Recommended for You

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[