OBD2 Spec: Your Comprehensive Guide to On-Board Diagnostics

Looking for a deep dive into the Obd2 Specification?

This expert guide provides an in-depth look at the On-Board Diagnostic (OBD2) specification, covering everything from the OBD2 connector and OBD2 parameter IDs (PIDs) to the intricacies of the CAN bus integration.

This is more than just an introduction; it’s a detailed exploration of the OBD2 spec, designed to help you understand how to request and interpret OBD2 data, explore key applications, and gain practical insights.

Discover why this guide is becoming a go-to resource for understanding the OBD2 spec.

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

Understanding the OBD2 Specification

OBD2, or On-Board Diagnostics version 2, is a critical specification for vehicle self-diagnostic capabilities. It’s a standardized protocol that dictates how diagnostic trouble codes (DTCs) and real-time vehicle data are accessed through the OBD2 connector. The OBD2 spec is essential for mechanics, automotive enthusiasts, and anyone involved in vehicle maintenance and diagnostics.

You’re likely already familiar with OBD2 in some form:

Have you ever seen the check engine light illuminate on your dashboard?

That’s your car signaling a potential issue. To diagnose this, a mechanic uses an OBD2 scanner, a tool designed to communicate with your vehicle based on the OBD2 spec.

The mechanic connects the OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ according to the OBD2 spec, and the car responds with ‘OBD2 responses’ that include data like speed, fuel level, or DTCs. This standardized communication, defined by the OBD2 spec, allows for faster and more accurate troubleshooting.

Illustration of a dashboard malfunction indicator light (MIL), commonly known as the check engine light, highlighting its role as a key indicator within the On-Board Diagnostics system.

OBD2 Spec Compliance: Does Your Car Support It?

The question of OBD2 support is simple for most modern vehicles: Almost certainly, yes!

Nearly all contemporary non-electric vehicles are OBD2 compliant, and most utilize the CAN bus protocol as defined in the OBD2 spec. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 spec compliance. As scantool.net explains, verification is needed. A key factor is the vehicle’s original point of sale and manufacturing date:

Informative graphic showing timelines for OBD2 compliance mandates in the US and EU, assisting in determining OBD2 support based on vehicle origin and date.

A Look at the OBD2 Spec History

The OBD2 spec has its roots in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control. This initial requirement laid the groundwork for the comprehensive OBD2 spec we know today.

The Society of Automotive Engineers (SAE) played a crucial role in formalizing the OBD2 spec, recommending the standard and standardizing both DTCs and the OBD connector across different manufacturers through SAE J1962. This standardization is a cornerstone of the OBD2 spec.

The OBD2 spec rollout was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU mandated OBD2 for gasoline cars.
2003: The mandate extended to diesel cars in the EU (EOBD), further solidifying the OBD2 spec in Europe.
2005: OBD2 was required in the US for medium duty vehicles, broadening the OBD2 spec application.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2, emphasizing CAN bus in the OBD2 spec.
2010: OBD2 became mandatory for heavy duty vehicles in the US, completing the phased implementation of the OBD2 spec across vehicle classes.

Graphical timeline illustrating the history of OBD2, from its emission control origins to its standardization and global adoption in vehicles.

Visual timeline summarizing key milestones in OBD2 history, including dates of mandates and expansions across different vehicle types and regions.

Conceptual graphic representing the future of OBD3, highlighting trends like remote diagnostics, cloud connectivity, and advancements in emissions testing.

Future Trends in the OBD2 Spec

The OBD2 spec is not static; it’s evolving. But what does the future hold?

While OBD2 was initially designed for emissions control, its role is changing, especially with the rise of electric vehicles. Interestingly, electric vehicles aren’t mandated to support OBD2 in its traditional form. Most modern EVs bypass standard OBD2 requests, opting for OEM-specific UDS communication. This shift poses challenges for accessing EV data, requiring reverse engineering efforts, as seen in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

The OBD2 spec faces limitations in data richness and lower-layer protocols. In response, alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to improve OBD communication using the UDS protocol. Explore our introduction to UDS for more on these advancements.

In our increasingly connected world, traditional OBD2 testing seems outdated. Manual emission checks are costly and time-consuming.

The answer? OBD3 – integrating telematics into 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 via WiFi for automated checks.

Technologies already exist to facilitate CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While convenient and cost-saving, OBD3 raises privacy concerns and faces political hurdles.

Originally for stationary emission controls, the OBD2 spec is now widely used by third parties for real-time data via OBD2 dongles, CAN loggers and similar tools. However, the German automotive industry is pushing for changes, as reported by eenewsautomotive.com:

“OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal is to disable OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.

Security concerns, like car hacking risks, are cited, but many view this as a commercial maneuver, as navixy.com discusses. The future of third-party OBD2 services remains uncertain, but these trends could significantly disrupt the market.

Visual representation of the trend where electric vehicles are moving away from traditional OBD2 access, indicating a shift in data accessibility.

Get Our ‘Ultimate CAN Guide’

Ready to become a CAN bus expert and deepen your understanding of the OBD2 spec?

Access our comprehensive collection of 12 ‘simple intros’ in a detailed 160+ page PDF:

Download now

Decoding the OBD2 Spec Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol – essentially a language. CAN, in contrast, is the communication method, akin to a phone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000. The OBD2 spec meticulously defines these protocols.

Specifically, the OBD2 spec standards detail the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards ensure interoperability and consistency across vehicle diagnostics.

These standards can be mapped to a 7-layer OSI model. The following sections will focus on the most crucial aspects of the OBD2 spec.

In the OSI model, notice the overlap between SAE and ISO standards. This reflects the dual origin of OBD2 spec standards – SAE in the USA and ISO in the EU. Many standards are technically near-identical, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3, highlighting the global harmonization efforts in the OBD2 spec.

Diagram illustrating the OBD2 and CAN bus relationship within the 7-layer OSI model, highlighting relevant ISO and SAE standards at each layer.

Detailed pinout diagram of a Type A OBD2 connector, essential for understanding physical connections and signal assignments according to the OBD2 spec.

The OBD2 Connector: SAE J1962 Spec

The 16-pin OBD2 connector is your gateway to vehicle data, precisely defined by the SAE J1962 / ISO 15031-3 standard within the OBD2 spec. This standardization ensures that diagnostic tools can universally interface with vehicles.

The illustration shows a Type A OBD2 pin connector (also known as the Data Link Connector, or DLC). The OBD2 spec ensures consistency in this physical interface.

Key points about the OBD2 connector as per the OBD2 spec:

It’s typically located near the steering wheel, though it may be hidden from plain sight depending on the vehicle model.
Pin 16 provides battery power, often active even when the ignition is off, as per the OBD2 spec for continuous diagnostic readiness.
The OBD2 pinout configuration is protocol-dependent, but the OBD2 spec standardizes the pin assignments for each protocol.
CAN bus is the most prevalent lower-layer protocol today, meaning pins 6 (CAN-H) and 14 (CAN-L) are usually connected, reflecting the OBD2 spec preference for CAN.

OBD2 Connector Types: A vs. B – SAE J1962 Spec

In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is more common in medium and heavy-duty vehicles, a distinction outlined in the OBD2 spec.

As the illustration shows, both types have similar OBD2 pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B, as dictated by the OBD2 spec to accommodate different vehicle electrical systems. Baud rates often vary too, with cars typically using 500K and heavy-duty vehicles often at 250K (with increasing 500K support), reflecting application-specific adaptations within the OBD2 spec.

Visually, a Type B OBD2 connector has a distinguishing interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is versatile, compatible with both Type A and B sockets, whereas a Type A adapter will only fit Type A sockets, a practical consideration when working with the OBD2 spec.

Comparative diagram highlighting the physical differences between OBD2 Connector Type A and Type B, including voltage specifications and application contexts.

Diagram visually differentiating OBD2 as a diagnostic protocol from CAN bus as a communication medium, crucial for understanding the OBD2 spec’s underlying layers.

OBD2 and CAN Bus Integration: ISO 15765-4 Spec

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765. This standard is a key component of the OBD2 spec, ensuring modern vehicles use CAN for diagnostics.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies constraints on the CAN standard (ISO 11898). This part of the OBD2 spec defines how diagnostics are implemented over CAN.

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers, all within the OBD2 spec framework:

CAN bus bit-rate must be either 250K or 500K, as defined by the OBD2 spec for diagnostic communication speeds.
CAN IDs can be 11-bit or 29-bit, offering flexibility while adhering to the OBD2 spec.
Specific CAN IDs are reserved for OBD requests and responses, a crucial aspect of the OBD2 spec for message routing.
Diagnostic CAN frame data length is fixed at 8 bytes, as per the OBD2 spec for efficient data handling.
The OBD2 adapter cable is limited to a maximum length of 5 meters, a practical constraint within the OBD2 spec.

OBD2 CAN Identifiers: 11-bit and 29-bit Specs

All OBD2 communication involves a request-response message exchange. The OBD2 spec clearly defines these message types and identifiers.

In most cars, 11-bit CAN IDs are used for OBD2 communication. Here, the ‘Functional Addressing’ ID is 0x7DF. This ID, as per the OBD2 spec, is used to query all OBD2-compatible ECUs about data for a requested parameter (see ISO 15765-4). CAN IDs 0x7E0-0x7E7 are for ‘Physical Addressing’ requests to specific ECUs, less frequently used but part of the OBD2 spec.

ECUs respond with 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module), as standardized in the OBD2 spec.

Some vehicles, particularly vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication. This is an alternative defined within the OBD2 spec.

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

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

Diagram illustrating the request-response framework of the OBD2 protocol, showing data flow and parameter identification within OBD2 communication.

Table summarizing common CAN identifiers used in OBD2 communication, including functional and physical addressing IDs, crucial for developers working with the OBD2 spec.

Conceptual graphic contrasting OBD2 standard CAN bus data with OEM-specific proprietary CAN bus data, highlighting differences in accessibility and interpretation.

OBD2 vs. Proprietary CAN Protocols: Specifying Data Access

It’s crucial to understand that your vehicle’s electronic control units (ECUs) operate using OEM-specific proprietary CAN protocols, independently of OBD2. OBD2 is an additional protocol for diagnostics, while OEM protocols manage vehicle functions. These OEM CAN protocols vary by brand, model, and year. Interpreting this proprietary data is typically impossible without OEM tools or reverse engineering, as explained in our guide to CAN bus sniffing.

Connecting a CAN bus data logger to your OBD2 connector might capture OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, newer cars often use a ‘gateway’ to block access to this OEM CAN data, allowing only OBD2 communication via the OBD2 connector, thus enforcing the intended scope of the OBD2 spec.

In essence, OBD2 is an ‘extra’ higher-layer protocol running alongside the OEM-specific protocol. This distinction is vital for anyone working with vehicle data and the OBD2 spec.

Bit-rate and ID Validation: Conforming to OBD2 Spec

As outlined in the OBD2 spec, OBD2 may use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 possible combinations. Modern cars commonly use 500K with 11-bit IDs, but tools must systematically verify this, adhering to the OBD2 spec validation process.

ISO 15765-4 provides a systematic initialization sequence to determine the correct combination. This method leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section). Incorrect bit-rate transmissions will cause CAN error frames, aiding in identification.

Newer ISO 15765-4 versions consider OBD communication via OBDonUDS versus OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2), reflecting different implementations within the broader OBD2 spec.

To test for OBDonEDS vs OBDonUDS, tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-supporting vehicles’ ECUs must respond to this DID, allowing for protocol differentiation within the OBD2 spec framework.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in non-EV cars, while WWH-OBD is mainly in EU trucks/buses, showing geographical and vehicle-type variations in OBD2 spec implementation.

Flowchart detailing the systematic process of OBD2 bit-rate and CAN ID validation as per ISO 15765-4, crucial for diagnostic tool initialization.

Infographic illustrating the five lower-layer OBD2 protocols, including CAN and older standards, showing the evolution of communication methods within the OBD2 spec over time.

Five Lower-Layer OBD2 Protocols: Historical Spec Context

While CAN is dominant today as the lower-layer for OBD2 (ISO 15765), older vehicles (pre-2008) may use other protocols. Understanding these is useful when working with older systems, providing historical context to the OBD2 spec. Pinouts can help identify the protocol in older cars.

The five lower-layer protocols historically used in the OBD2 spec are:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common worldwide.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler & Asian cars from 2000-04.
SAE J1850 (VPW): Predominantly used in older GM vehicles.
SAE J1850 (PWM): Mainly used in older Ford vehicles.

ISO-TP for OBD2 Messaging: ISO 15765-2 Spec

All OBD2 data communication over CAN bus uses ISO-TP (ISO 15765-2), a transport protocol. This is a key part of the OBD2 spec when dealing with data larger than 8 bytes. ISO-TP enables payloads exceeding CAN’s 8-byte limit, necessary for OBD2 functions 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, as detailed in our UDS protocol introduction.

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

Diagram illustrating various ISO-TP frame types used in OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control, essential for understanding message segmentation and reassembly.

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

To fully grasp OBD2 over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message comprises an identifier, data length (PCI field), and data. The data section is further broken down into Mode, parameter ID (PID), and data bytes, all structured by the OBD2 spec.

Detailed breakdown of an OBD2 message structure, showing the arrangement of Mode, PID, and Data Bytes within a CAN frame, crucial for interpreting raw OBD2 data.

OBD2 Request/Response Example: Spec in Action

Consider a request/response example for ‘Vehicle Speed’. This illustrates the OBD2 spec in practical terms.

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

Using OBD2 PID 0x0D decoding rules, we find that 0x32 corresponds to 50 km/h, demonstrating how the OBD2 spec allows for data interpretation.

Next, we’ll detail OBD2 modes and PIDs, core components of the OBD2 spec.

Example CAN bus trace showing an OBD2 request for vehicle speed (PID 0x0D) and the corresponding response, demonstrating the request-response mechanism defined by the OBD2 spec.

Detailed view of OBD2 PID 0x0D for Vehicle Speed, showing the data encoding and interpretation as per the OBD2 spec, essential for data decoding.

Graphical overview of the 10 OBD2 service modes, including their functions like showing current data, freeze frame, and clearing DTCs, providing a functional context for OBD2 services.

The 10 OBD2 Services (Modes): Specifying Diagnostic Functions

The OBD2 spec defines 10 diagnostic services, also known as modes. Mode 0x01 provides real-time data, while others display/clear diagnostic trouble codes (DTCs) or show freeze frame data. These modes are fundamental to the OBD2 spec‘s diagnostic capabilities.

Vehicles aren’t required to support all OBD2 modes and may include OEM-specific modes beyond the 10 standardized ones. The OBD2 spec provides a base, but allows for OEM extensions.

In OBD2 messages, the mode is in the 2nd byte. In requests, the mode is direct (e.g., 0x01). In responses, 0x40 is added to the mode (e.g., resulting in 0x41), a consistent response formatting rule in the OBD2 spec.

OBD2 Parameter IDs (PIDs): Data Parameters Spec

Each OBD2 mode contains parameter IDs (PIDs). The OBD2 spec standardizes many PIDs for accessing various vehicle parameters.

For example, mode 0x01 includes ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles don’t have to support all PIDs within a mode; most support only a subset, depending on the vehicle and its systems, reflecting implementation choices within the OBD2 spec framework.

One PID is particularly important: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates support for PIDs 0x01-0x20. PID 0x00 is thus a fundamental ‘OBD2 compatibility test’ as per the OBD2 spec. PIDs 0x20, 0x40, …, 0xC0 similarly indicate support for subsequent PID ranges in mode 0x01, allowing for comprehensive PID discovery.

Diagram re-emphasizing the OBD2 request-response mechanism, focusing on the role of PIDs in requesting specific data parameters and the structure of data bytes within OBD2 frames.

Screenshot of an OBD2 PID overview tool, highlighting its utility in exploring and understanding available PIDs for Service 01, aiding in practical OBD2 data analysis and interpretation.

Tip: OBD2 PID Overview Tool – Spec Resource

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling data decoding into physical values, as explained in our CAN bus introduction. These documents are essential resources for understanding the OBD2 spec.

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It helps construct OBD2 request frames and dynamically decode responses, simplifying interaction with the OBD2 spec.

OBD2 PID overview tool

Practical OBD2 Data Logging and Decoding

This section provides a practical guide to logging OBD2 data using the CANedge CAN bus data logger. This illustrates the practical application of the OBD2 spec.

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging. This flexibility is key to interacting with vehicles using the OBD2 spec.

Connect the CANedge to your vehicle via our OBD2-DB9 adapter cable to start logging.

Diagram illustrating the setup for OBD2 data logging using a CANedge data logger, showing connections and data flow for PID requests and responses.

Screenshot from asammdf software displaying OBD2 ‘Supported PIDs’ test responses, showcasing data received from a vehicle’s ECU.

#1: Bit-rate, ID & Supported PID Testing – Spec Verification

ISO 15765-4 outlines how to determine vehicle-specific bit-rates and IDs. Use CANedge for this, as follows (see CANedge Intro for details):

Send a CAN frame at 500K; if successful (check for errors), use 500K. Otherwise, try 250K, aligning with OBD2 spec bit-rate options.
Use the identified bit-rate for all subsequent OBD2 communication.
Send multiple ‘Supported PIDs’ requests and examine the responses.
Response IDs indicate 11-bit or 29-bit CAN ID usage.
Response data reveals supported PIDs, identifying vehicle-specific OBD2 spec implementations.

We provide plug-and-play configurations for these tests, simplifying the process of OBD2 spec verification.

Most 2008+ non-EV cars support 40-80 PIDs via 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 due to the use of the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. Subsequent ‘Supported PIDs’ requests receive fewer responses as fewer ECUs support the full range. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example, meaning busload can be reduced by targeting only this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for later communication, optimizing data retrieval within the OBD2 spec.

#2: Configuring OBD2 PID Requests – Spec-Based Requests

After identifying supported OBD2 PIDs, bit-rate, and CAN IDs, configure your transmit list with relevant PIDs.

Consider these points when setting up PID requests according to the OBD2 spec:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple ECU responses per request, streamlining data.
Spacing: Add 300-500 ms between OBD2 requests. Overly rapid requests may cause ECU response failures; respect ECU processing limits.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent ECU ‘wake-up’ and battery drain, especially during prolonged logging.
Filters: Filter to record only OBD2 responses if OEM-specific CAN data is also present, focusing data capture on relevant OBD2 spec communication.

With configuration complete, the CANedge is ready to log raw OBD2 data, capturing vehicle diagnostics as per the OBD2 spec!

Example CANedge configuration showing a transmit list setup for OBD2 PID requests, demonstrating practical tool configuration for OBD2 data acquisition.

Screenshot from asammdf software showing OBD2 data decoded and visualized, demonstrating data interpretation and analysis post-logging.

#3: DBC Decoding of Raw OBD2 Data – Spec-Compliant Interpretation

To analyze and visualize logged data, decode raw OBD2 data into ‘physical values’ (e.g., km/h or °C). This decoding process is defined by the OBD2 spec.

Decoding information is in ISO 15031-5/SAE J1979 (and online resources like Wikipedia). We offer a free OBD2 DBC file for easy DBC decoding in most CAN bus software tools, streamlining OBD2 spec data interpretation.

Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify payload signals.

Therefore, signal identification requires CAN ID, OBD2 mode, and OBD2 PID. This is ‘extended multiplexing’, implementable in DBC files. Our OBD2 DBC accounts for this, facilitating accurate OBD2 spec data decoding.

CANedge: Your OBD2 Data Logger – Spec-Focused Logging

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect to a car/truck to start logging and decode data using free software/APIs and our OBD2 DBC. CANedge is designed for efficient OBD2 spec data capture.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples: ISO-TP Spec in Detail

OBD2 data uses ISO-TP (ISO 15765-2) for all communication, including multi-frame exchanges. Most examples so far have been single-frame. This section illustrates multi-frame communication, a crucial aspect of the OBD2 spec for larger data sets.

Multi-frame OBD2 requires flow control frames (see our UDS intro). A static flow control frame transmitted ~50 ms after the initial request suffices, as shown in the CANedge configuration example.

Multi-frame OBD2 responses need CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders, to properly handle data segmentation and reassembly according to the OBD2 spec.

Example 1: OBD2 Vehicle Identification Number (VIN) – Multi-Frame Spec Example

The Vehicle Identification Number (VIN) is vital for telematics and diagnostics (see our UDS intro). Extract 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). After the PID is byte 0x01 (Number Of Data Items – NODI), here 1 (see ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASCII, demonstrating multi-frame data handling as per the OBD2 spec.

Example 2: OBD2 Multi-PID Request (6x) – Advanced Spec Usage

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (omitting unsupported ones), using multi-frame responses if needed, per ISO-TP. This illustrates advanced capabilities within the OBD2 spec.

This efficiently collects OBD2 data but complicates signal encoding, making generic OBD2 DBC files less useful. We advise against this method practically. Below is an example trace:

The multi-frame response is similar to the VIN example, but includes requested PIDs and their data. PIDs are often ordered as requested (common but not ISO 15031-5 standard requirement).

Decoding this via DBC files is complex. We don’t recommend this approach for data logging unless your tool specifically supports it. It’s a form of extended multiplexing, challenging to generalize DBCs across vehicles with varying PID support. Managing this via DBC manipulations is very difficult, especially with multiple multi-PID requests, making message identification hard.

Workarounds include custom scripts, recording transmit messages, and interpreting responses based on requests. However, these are hard to scale. This method, while technically within the OBD2 spec, presents practical challenges for general use.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) – DTC Spec Interpretation

Use OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, to request emissions-related DTCs. No PID is in the request. Responding ECU(s) report the number of stored DTCs (possibly 0), with each DTC being 2 data bytes. Multi-frame responses are needed for more than 2 DTCs, showcasing ISO-TP in action for DTC reporting as per the OBD2 spec.

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

Example below shows a request to an ECU with 6 DTCs stored, demonstrating real-world DTC retrieval within the OBD2 spec.

Diagram illustrating the structure and decoding process of OBD2 Diagnostic Trouble Codes (DTCs), showing the bit allocation for category and code, vital for DTC interpretation.

Example CAN bus trace demonstrating the request and response sequence for OBD2 Diagnostic Trouble Codes (DTCs), showing multi-frame responses for multiple DTCs.

OBD2 Data Logging Use Cases – Spec Applications

OBD2 data from cars and light trucks has diverse applications:

Logging Data from Cars – Spec for Data Acquisition

OBD2 data helps reduce fuel costs, improve driving, test prototype parts, and in insurance applications. The OBD2 spec facilitates a wide range of data-driven services.

obd2 logger

Real-Time Car Diagnostics – Spec for Live Data

OBD2 interfaces stream human-readable data in real-time, aiding vehicle issue diagnosis. Real-time access is a core benefit of the OBD2 spec.

obd2 streaming

Predictive Maintenance – Spec for Vehicle Health Monitoring

IoT OBD2 loggers monitor cars/trucks in the cloud to predict and prevent breakdowns. Predictive maintenance leverages the OBD2 spec for proactive vehicle management.

predictive maintenance

Vehicle Blackbox Logger – Spec for Event Recording

OBD2 loggers serve as ‘black boxes’ for vehicles or equipment, providing data for disputes or diagnostics. Black box functionality is an important application of the OBD2 spec.

can bus blackbox

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

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

Need to log/stream OBD2 data based on the spec?

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

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN