OBD2 Protocol Documentation: Your In-Depth Guide to On-Board Diagnostics

Looking for comprehensive Obd2 Protocol Documentation?

This guide provides an in-depth exploration of the On-Board Diagnostics (OBD2) protocol, encompassing the OBD2 connector, OBD2 Parameter IDs (PIDs), and its integration with the CAN bus.

Note: This is an in-depth guide designed to elevate your understanding of OBD2. You’ll learn about requesting and interpreting OBD2 data, essential logging applications, and valuable practical insights.

Discover why this is becoming the go-to resource for OBD2 protocol documentation.

You can also watch our OBD2 intro video above – or get the PDF

Understanding the OBD2 Protocol: An Overview

OBD2, short for On-Board Diagnostics version 2, serves as your vehicle’s inherent self-diagnostic system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time operational data through the OBD2 connector.

You’ve likely encountered OBD2 in action without realizing it:

Ever noticed the check engine light illuminating on your dashboard?

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

To do this, the mechanic connects an OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. This tool transmits ‘OBD2 requests’ to the vehicle, which responds with ‘OBD2 responses’ containing valuable information such as speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly streamlines issue diagnosis and repair.

OBD2 Compatibility: Is Your Car Supported?

In most cases, yes!

The vast majority of modern non-electric vehicles are OBD2 compliant and predominantly operate on the CAN bus protocol. For older vehicles, it’s important to note that the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 support. Verification is crucial. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:

A Look at OBD2 History and Evolution

The genesis of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD implementation in all new vehicles from 1991 onwards, primarily for emission control.

The Society of Automotive Engineers (SAE) played a pivotal role in recommending the OBD2 standard, leading to the standardization of DTCs and the OBD connector across different manufacturers (SAE J1962).

The OBD2 standard was progressively implemented:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: OBD2 requirement extended to gasoline cars in the EU.
2003: EU mandate expanded to include diesel cars (EOBD).
2005: OBD2 became compulsory in the US for medium-duty vehicles.
2008: US vehicles were required to adopt ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 mandate finalized in the US for heavy-duty vehicles.

The Future Trajectory of OBD2

OBD2 is firmly established, but its evolution is ongoing.

Key trends shaping the future of OBD2 include:

Initially conceived for emission control and testing, legislative OBD2 requirements have not extended to electric vehicles. Consequently, most modern EVs do not inherently support standard OBD2 requests. Instead, they often employ OEM-specific UDS communication protocols. This typically restricts data decoding from EVs, except in cases where reverse engineering efforts have yielded decoding rules. Examples include case studies for electric cars such as Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations exhibit variations and limitations, particularly in data richness and lower-layer protocols. To address these, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to refine OBD communication by utilizing the UDS protocol as a foundation. For deeper insights, refer to our introduction to UDS.

In today’s interconnected automotive landscape, conventional OBD2 testing methods can appear inefficient. Manual emission control checks are both time-intensive and costly.

The proposed solution? OBD3: Integrating telematics into all vehicles.

OBD3 envisions incorporating a compact radio transponder (similar to those used in bridge toll systems) into every car. This would enable the wireless transmission of the car’s vehicle identification number (VIN) and DTCs to a central server for automated checks.

Many contemporary devices already facilitate CAN or OBD2 data transfer via WiFi/cellular networks – for instance, the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While offering convenience and cost savings, OBD3 raises political challenges concerning surveillance and data privacy.

The original purpose of the OBD2 protocol was for stationary emission controls.

However, OBD2 is now widely utilized by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers, and similar devices. The German car industry is advocating for changes in this regard:

OBD was intended for vehicle servicing in repair shops. It was never designed to allow third parties to build a data-driven economy on the access through this interface.“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves deactivating OBD2 functionality during driving, centralizing data collection on manufacturer servers. This would effectively place automotive manufacturers in control of ‘automotive big data’.

Arguments center on security enhancements (e.g., mitigating car hacking risks), although many view it as a commercially motivated move. The future adoption of this trend remains uncertain, but it could significantly disrupt the landscape of third-party OBD2 services.

Enhance Your CAN Bus Expertise

Eager to become a CAN bus expert?

Access our 12 ‘simple intros’ consolidated into a comprehensive 160+ page PDF:

Download now

Decoding OBD2 Standards and Specifications

On-board diagnostics, OBD2, operates as a higher-layer protocol, akin to a language. CAN bus serves as the communication medium, similar to a telephone line. This positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards delineate the OBD2 connector specifications, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.

These standards can be structured within a 7-layer OSI model. The following sections will emphasize the most critical aspects.

In the OSI model overview, you’ll observe that both SAE and ISO standards cover multiple layers. This reflects the standards framework for OBD defined in the USA (SAE) and EU (ISO). Several standards are technically near-identical, for instance, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides straightforward access to vehicle data and is detailed in the SAE J1962 / ISO 15031-3 standard.

The illustration depicts a Type A OBD2 pin connector (sometimes referred to as the Data Link Connector, DLC).

Key aspects to consider:

The connector is generally near the steering wheel but may be concealed.
Pin 16 supplies battery power, often even when the ignition is off.
The OBD2 pinout configuration varies based on the communication protocol.
CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L).

OBD2 Connector Types: A vs. B

In practical applications, you may encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is prevalent in medium and heavy-duty vehicles.

As illustrated, both types share similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates can also vary, with cars typically using 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K in newer models).

Type B OBD2 connectors feature an interrupted groove in the middle, aiding in physical differentiation. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus Integration: ISO 15765-4

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

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898).

Specifically, it standardizes the CAN interface for test 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 designated for OBD requests/responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable must not exceed 5 meters in length.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication relies on request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs for data related to the requested parameter (refer to ISO 15765-4). Conversely, CAN IDs 0x7E0-0x7E7 facilitate ‘Physical Addressing’ requests to specific ECUs (less commonly used).

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

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

In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Vehicle responses will be observed with CAN IDs ranging 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. Proprietary CAN Protocols: Understanding the Difference

It’s crucial to understand that your vehicle’s electronic control units (ECUs) operate independently of OBD2. Each original equipment manufacturer (OEM) implements its own proprietary CAN protocols for core vehicle functions. These protocols are often specific to the vehicle brand, model, and year. This OEM-specific CAN data is generally inaccessible to external parties unless reverse engineering techniques are employed.

Connecting a CAN bus data logger to your vehicle’s OBD2 connector may capture OEM-specific CAN data, typically broadcast at a rate of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ system restricts access to this CAN data, exclusively enabling OBD2 communication through the OBD2 connector.

In essence, OBD2 functions as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol.

Bit-rate and ID Validation Process

As previously mentioned, OBD2 can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles commonly use 500K and 11-bit IDs, but external tools should systematically verify this.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This method relies on the principle that OBD2-compliant vehicles must respond to a mandatory OBD2 request (detailed in the OBD2 PID section) and the fact that transmitting data at an incorrect bit-rate will trigger CAN error frames.

Recent versions of ISO 15765-4 acknowledge that vehicles may support OBD communication through OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) as opposed 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 ‘protocols’, testing tools can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID.

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

Five Lower-Layer OBD2 Protocols: A Historical Perspective

While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 today, especially in vehicles manufactured post-2008, older vehicles (pre-2008) may utilize one of four alternative protocols. Understanding these protocols and their corresponding pinouts can be helpful when working with older vehicles:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most widely used protocol.
ISO14230-4 (KWP2000): Keyword Protocol 2000, commonly used in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Utilized in EU, Chrysler, and Asian vehicles between 2000-2004.
SAE J1850 (VPW): Predominantly found in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages via ISO 15765-2

All OBD2 data transmission over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte CAN frame limit. This capability is essential in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 facilitates segmentation, flow control, and reassembly of larger data packets. For more detailed information, consult our introduction to UDS.

However, in many instances, OBD2 data can fit within a single CAN frame. In such cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

Deciphering the OBD2 Diagnostic Message: SAE J1979, ISO 15031-5

To gain a deeper understanding of OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises an identifier, data length (PCI field), and data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 Request and Response Example: Vehicle Speed

Before delving into each component of the OBD2 message, consider this practical request/response example for the ‘Vehicle Speed’ parameter.

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

By consulting the decoding rules for OBD2 PID 0x0D, we determine that the physical value represents 50 km/h.

In the following sections, we will focus on OBD2 modes and PIDs in detail.

The 10 OBD2 Diagnostic Services (Modes)

The OBD2 protocol defines 10 diagnostic services, also referred to as modes. Mode 0x01 is used for retrieving current real-time data, while other modes are designed for displaying and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

It’s important to note that vehicles are not required to support all 10 OBD2 modes. They may also support modes beyond the 10 standardized modes, which are considered OEM-specific OBD2 modes.

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

OBD2 Parameter IDs (PIDs): Accessing Specific Data Points

Each OBD2 mode encompasses a set of Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles are not obligated to support all OBD2 PIDs within a given mode. In practice, most vehicles support only a limited subset of available PIDs.

One PID holds special significance in this context.

Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID request, the vehicle ECU communicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Tip: Utilizing the OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling the conversion of raw data into physical values (as explained in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Practical Guide to Logging and Decoding OBD2 Data

This section provides a hands-on example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge’s configurable CAN frame transmission feature allows its use for OBD2 logging and similar applications.

Once configured, the device can be easily connected to your vehicle using our OBD2-DB9 adapter cable.

Testing CAN frame transmission at 500K to validate bit rate

Reviewing ‘Supported PIDs’ responses using asammdf software

Step 1: Bit-rate, ID, and Supported PID Validation

As discussed, ISO 15765-4 outlines the procedure to determine the bit-rate and IDs used by a specific vehicle. The CANedge can be used to perform these tests (refer to the CANedge Intro for setup details):

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

We provide ready-to-use configurations to streamline these tests.

Most non-EV vehicles 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. This is because the 0x7DF request ID broadcasts the request to all ECUs, prompting responses from all OBD2/OBDonEDS-compliant ECUs that support service 0x01 PID 0x00. Consequently, responses to this PID are particularly numerous. As evident, subsequent ‘Supported PIDs’ requests elicit fewer ECU responses. Notably, the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. Optimizing communication by specifically targeting the ECM ECU (using the ‘Physical Addressing’ CAN ID 0x7E0 for subsequent requests) can reduce bus load.

Step 2: Configuring OBD2 PID Requests for Data Logging

With knowledge of your vehicle’s supported OBD2 PIDs, bit-rate, and CAN IDs, you can configure your transmit list to request specific PIDs of interest.

Consider these points when configuring PID requests:

CAN IDs: Transition to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses.
Request Spacing: Introduce a delay of 300-500 ms between OBD2 requests to prevent overwhelming ECUs and ensure reliable responses.
Battery Drain Management: Implement triggers to halt transmission when the vehicle is inactive, preventing unnecessary ECU wake-up and battery drain.
Data Filtering: Apply filters to record only relevant OBD2 responses if your vehicle also outputs OEM-specific CAN data, streamlining data analysis.

Once configured, your device is ready to log raw OBD2 data efficiently.

Example configuration list for CANedge OBD2 PID requests

asammdf software enables DBC decoding and visualization of OBD2 data

Step 3: DBC Decoding of Raw OBD2 Data for Analysis

To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data into ‘physical values’ (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data presents slightly more complexity than standard CAN signal decoding. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to uniquely identify the signals within the payload.

To overcome this, decoding requires considering both the CAN ID, OBD2 mode, and OBD2 PID to accurately identify the signal. This form of multiplexing, known as ‘extended multiplexing‘, can be implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to your car or truck to initiate logging and decode data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Communication Examples: ISO-TP in Action

All OBD2 data communication utilizes the ISO-TP (transport protocol) as per ISO 15765-2. While many examples involve single-frame communication, multi-frame communication is essential for larger data payloads. This section provides examples of multi-frame OBD2 communication.

Multi-frame OBD2 communication necessitates flow control frames (refer to our UDS introduction). In practice, this can be achieved by transmitting a static flow control frame approximately 50 ms after the initial request frame, as illustrated in the CANedge configuration example.

Furthermore, analyzing multi-frame OBD2 responses requires CAN software/API tools with ISO-TP support, such as the CANedge MF4 decoders.

Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD2

The Vehicle Identification Number (VIN) is crucial for various applications including telematics and diagnostics (refer to our UDS introduction for more details). To retrieve the VIN using OBD2 requests, utilize mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame containing the 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), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for detailed specifications). The subsequent 17 bytes constitute the VIN and can be converted from HEX to ASCII using methods outlined in our UDS introduction.

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

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU should respond with data for supported PIDs (excluding unsupported PIDs from the response), potentially across multiple frames as per ISO-TP.

This feature enhances data collection efficiency and frequency. However, the signal encoding becomes specific to the request method, making generic OBD2 DBC files less suitable for these use cases. We generally advise against this method in practice. Below is an example trace illustrating this scenario:

The multi-frame response structure is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. In the example, PIDs are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding such responses using generic DBC files is challenging. Thus, we don’t recommend this approach for practical data logging unless you are using tools with specific built-in support. This scenario represents extended multiplexing with multiple instances within the payload. Your DBC file would need to account for the payload position of each PID, complicating generalization across vehicles with varying PID support. Managing this complexity via DBC manipulation becomes increasingly difficult when sending multiple multi-PID requests, as uniquely identifying messages becomes problematic.

Workarounds might involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages based on the corresponding request messages. However, such approaches are difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (potentially zero), with each DTC occupying 2 data bytes. Multi-frame responses become necessary when more than 2 DTCs are stored.

The 2-byte DTC value is typically structured as per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits define a 4-digit code (displayed in hexadecimal), as shown in the visual. 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 Applications

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging Applications

OBD2 data logging in cars can be used for fuel efficiency improvements, driving behavior analysis, prototype testing, and insurance telematics.

obd2 logger

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data for diagnosing vehicle issues effectively.

obd2 streaming

Predictive Maintenance Solutions

Cars and light trucks can be remotely monitored via IoT OBD2 loggers to predict and prevent breakdowns, enhancing vehicle uptime.

predictive maintenance

Vehicle Black Box Logging

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution and diagnostics.

can bus blackbox

Do you have an OBD2 data logging use case? Reach out for free consultation!

For further introductory guides, explore our guides section or download the ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN