Decoding the OBD2 Specification: A Comprehensive Guide for Automotive Diagnostics

Need a detailed, expert-level understanding of the Obd2 Specification?

This guide provides an in-depth exploration of the On-Board Diagnostics version 2 (OBD2) specification, essential for anyone working with modern vehicle diagnostics, data logging, or automotive engineering. We will dissect the OBD2 connector, Parameter IDs (PIDs), communication protocols, and the critical link to the Controller Area Network (CAN) bus, all within the framework of the official OBD2 specifications.

This is not just a basic introduction; this is a deep dive into the OBD2 specification, designed to elevate your understanding and practical application of this vital automotive standard.

You can also explore our video introduction to OBD2 or download our comprehensive CAN bus guide in PDF format.

Article Contents

Author: Martin Falch (Updated January 2025)

Download as PDF

Understanding the Core of OBD2: The Specification

OBD2, or On-Board Diagnostics Second Generation, is fundamentally defined by its specification. It’s not just a system; it’s a detailed set of rules and standards that dictate how vehicles should monitor their systems, report issues, and provide diagnostic data. The OBD2 specification ensures uniformity across manufacturers, allowing for standardized diagnostic tools and procedures. At its heart, OBD2 is a vehicle’s self-diagnostic and reporting capability, standardized to ensure accessibility and consistency. This standardization, defined by the OBD2 specification, is what allows a single diagnostic tool to interface with a wide range of vehicles, extracting diagnostic trouble codes (DTCs) and real-time operational data through the OBD2 connector.

You’ve likely encountered the results of the OBD2 specification in action: the malfunction indicator light (MIL) on your dashboard. This light, triggered according to the OBD2 specification, signals that the vehicle’s self-diagnostic system has detected an issue. When a mechanic uses an OBD2 scanner, they are leveraging the OBD2 specification. The scanner connects to the OBD2 16-pin connector, typically located near the steering wheel. This connection allows the diagnostic tool to send standardized ‘OBD2 requests’ and receive ‘OBD2 responses’. These responses, structured according to the OBD2 specification, contain critical data such as vehicle speed, fuel level, and Diagnostic Trouble Codes (DTCs). This standardized communication, dictated by the OBD2 specification, is crucial for efficient and accurate troubleshooting.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL), illustrating the core function of the system.

OBD2 Compliance: Checking the Specification for Your Vehicle

The OBD2 specification has become a near-universal standard for non-electric vehicles. If you own a newer car that isn’t electric, it almost certainly supports OBD2 and likely operates on the CAN bus protocol, as mandated by the OBD2 specification in many regions. However, it’s important to verify compliance, especially with older vehicles. Even if a 16-pin OBD2 connector is present, it doesn’t guarantee full OBD2 specification compliance. Some older vehicles may have the connector but not implement the complete OBD2 protocol. To confirm OBD2 specification compliance, consider the vehicle’s purchase location and year:

OBD2 Compliance Guide: A visual aid to determine OBD2 compliance based on vehicle origin and manufacturing year in the EU and US.

A Look into OBD2 History: Evolution of the Specification

The OBD2 specification has its roots in California, driven by the California Air Resources Board (CARB). In 1991, CARB mandated OBD in all new vehicles sold in California for emission control. This initial requirement laid the groundwork for the standardized OBD2 specification we know today.

The Society of Automotive Engineers (SAE) played a pivotal role in developing the OBD2 specification, recommending the standard and crucially standardizing DTCs and the physical OBD connector (SAE J1962). This standardization was a major step, ensuring interoperability across different vehicle manufacturers and diagnostic tools.

The OBD2 specification rollout was a phased process, reflecting its growing importance and regulatory adoption:

1996: OBD2 became mandatory in the USA for all cars and light trucks, marking a significant step in widespread adoption driven by environmental regulations.
2001: The European Union mandated OBD2 for gasoline cars, expanding the geographical reach of the OBD2 specification.
2003: The EU extended the mandate to diesel cars (EOBD), further solidifying OBD2 as a standard in Europe.
2005: OBD2 was required in the US for medium-duty vehicles, broadening its application beyond passenger vehicles.
2008: A critical update to the OBD2 specification in the US mandated the use of ISO 15765-4 (CAN) as the communication foundation for OBD2, modernizing the protocol.
2010: OBD2 became mandatory in the US for heavy-duty vehicles, completing its implementation across virtually all vehicle classes.

OBD2 Historical Context: Illustrating the history of OBD2 in relation to emission control, exhaust regulations, and the evolution from EOBD to EOBDII.

OBD2 Timeline: A visual timeline summarizing key milestones in the history and development of On-Board Diagnostics.

Future of OBD: Envisioning OBD3 with remote diagnostics, emissions testing, cloud connectivity, and IoT integration for advanced vehicle monitoring.

The Future of OBD2: Trends and Specification Evolution

While OBD2 remains a cornerstone of vehicle diagnostics, its future and the evolution of its specification are subjects of ongoing development.

Initially designed for emissions control and testing, the legislated OBD2 specification faces challenges with the rise of electric vehicles. Electric vehicles (EVs) are not obligated to support OBD2 in its traditional form. In practice, most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift makes standard OBD2 diagnostic tools less effective for EVs, requiring specialized knowledge and tools to access vehicle data. Decoding data from EVs often relies on reverse engineering efforts, as seen in case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

Recognizing the limitations of the current OBD2 specification in terms of data richness and protocol flexibility, modern alternatives are emerging. These include WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both are designed to enhance OBD communication by basing it on the more versatile UDS protocol. These next-generation specifications aim to streamline diagnostics and data access while accommodating the increasing complexity of vehicle systems. For a deeper understanding of these evolving protocols, refer to our introduction to UDS.

In the era of connected cars, traditional OBD2 testing methods can be inefficient. Manual emission control checks are time-consuming and costly. The proposed solution is OBD3, which envisions integrating telematics into all vehicles. OBD3 would add a small radio transponder to vehicles, enabling wireless transmission of the vehicle identification number (VIN) and DTCs via WiFi to a central server for automated monitoring and diagnostics. Technologies to facilitate this data transfer already exist, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger. While offering convenience and cost savings, OBD3 raises political and privacy concerns related to vehicle surveillance.

The original OBD2 specification was tailored for stationary emission controls. However, its use has expanded significantly to include real-time data generation for third-party services via OBD2 dongles, CAN loggers, and similar devices. This expanded use is now being challenged by the automotive industry, particularly in Germany. Concerns are being raised about third-party access to vehicle data through the OBD2 interface, with some manufacturers proposing to restrict OBD2 functionality while driving. Data would instead be collected centrally by the manufacturers, potentially giving them greater control over ‘automotive big data’. While security benefits, such as reducing the risk of car hacking, are cited, many view this as a commercially motivated move to control vehicle data access, potentially disrupting the market for third-party OBD2 services. The future direction of OBD2 specification and data access remains uncertain but is crucial for the automotive aftermarket and data-driven services.

OBD2 in the EV Era: Depicting the potential removal of the OBD2 connector in electric vehicles, signaling a shift in diagnostic access and data protocols.

Enhance Your Expertise: The Ultimate CAN Guide

Ready to become a CAN bus expert and deepen your OBD2 knowledge?

Our comprehensive ‘Ultimate CAN Guide’ offers 12 detailed introductions in a single, extensive 160+ page PDF.

Download now

Delving into OBD2 Standards: Defining the Specification

On-board diagnostics, OBD2, operates as a higher-layer protocol, functioning like a language built upon a communication method. CAN bus serves as this communication method, analogous to a phone line. This hierarchical structure positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

The OBD2 specification meticulously defines various aspects, including the OBD2 connector itself, the underlying lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and more. These standards are critical for ensuring interoperability and consistent diagnostic practices across the automotive industry.

These standards can be organized within the 7-layer OSI model, providing a structured view of the OBD2 specification. The following sections will focus on the most critical aspects of these standards, particularly as they relate to the OBD2 specification. Notably, the OSI model reveals that both SAE and ISO standards cover multiple layers of the OBD2 system. This dual standardization reflects the origins of OBD2 development in the USA (SAE standards) and its subsequent adoption and evolution in Europe (ISO standards). Many of these standards are technically equivalent, such as SAE J1979 and ISO 15031-5 (defining diagnostic services), and SAE J1962 and ISO 15031-3 (specifying the OBD connector).

OSI Model of OBD2 and CAN Bus: A 7-layer OSI model illustrating the relationship between OBD2 and CAN Bus, highlighting ISO 15765 and ISO 11898 standards.

OBD2 Connector Pinout: Diagram of a Type A OBD2 connector socket (female), detailing pin assignments for the Data Link Connector (DLC).

The OBD2 Connector: SAE J1962 Specification

The 16-pin OBD2 connector is the physical interface that provides access to your vehicle’s diagnostic data. Its design and pin assignments are rigorously defined by the SAE J1962 / ISO 15031-3 standard, which is a core component of the OBD2 specification.

The illustration above shows a Type A OBD2 pin connector, also known as a Data Link Connector (DLC). Key characteristics and considerations according to the OBD2 specification include:

Location: The connector is typically located within reach of the driver, often near the steering wheel, though its exact placement can vary and may sometimes be hidden behind a panel. Resources like klavkarr.com can help locate it in different vehicle models.
Power Supply: Pin 16 is designated to supply battery power, often remaining active even when the ignition is off. This constant power supply allows for certain diagnostic and monitoring functions to operate continuously.
Pinout Variability: The specific OBD2 pinout is not fixed but depends on the communication protocol used by the vehicle. Different protocols assign different functions to specific pins.
CAN Bus Integration: The most prevalent lower-layer protocol in modern vehicles is CAN bus. In CAN-based OBD2 systems, pins 6 (CAN-High) and 14 (CAN-Low) are typically connected, facilitating CAN communication through the OBD2 connector.

OBD2 Connector Types: A vs. B – Specification Differences

The OBD2 specification defines two primary connector types: Type A and Type B. Type A is predominantly found in passenger cars and light-duty vehicles, while Type B is more common in medium and heavy-duty vehicles.

While both Type A and Type B connectors share a similar OBD2 pinout structure, crucial differences exist, primarily in power supply and communication parameters, as dictated by the OBD2 specification:

Power Supply: Type A connectors typically provide a 12V power supply, suitable for cars and light vehicles. Type B connectors, on the other hand, are designed for 24V systems common in trucks and heavy-duty vehicles.
Baud Rate: Communication speed, or baud rate, often differs. Cars using Type A connectors commonly operate at 500 Kbps, while heavy-duty vehicles with Type B connectors often use 250 Kbps, although newer heavy-duty vehicles may also support 500 Kbps.
Physical Keying: To prevent accidental mismatches, the Type B OBD2 connector features an interrupted groove in the middle, physically differentiating it from Type A. This keying ensures that Type A connectors cannot be mistakenly inserted into Type B sockets. However, a Type B OBD2 adapter cable is generally designed to be compatible with both Type A and Type B sockets, providing versatility.

OBD2 Connector Types A and B: A comparative illustration of OBD2 Connector Type A and Type B as per SAE J1962, highlighting differences for cars, vans, and trucks, including voltage specifications (12V vs. 24V).

OBD2 and CAN Bus Relationship: Visual representation of the relationship between OBD2 and CAN bus, emphasizing the ISO 15765 standard for CAN-based diagnostics.

OBD2 and CAN Bus: ISO 15765-4 Specification

Since 2008, the OBD2 specification, particularly as implemented in the US (and increasingly globally), mandates CAN bus as the primary lower-layer communication protocol for all vehicles. This mandate is formalized under ISO 15765, specifically ISO 15765-4, often referred to as Diagnostics over CAN (DoCAN).

ISO 15765-4, as part of the OBD2 specification, outlines a set of constraints and guidelines for using CAN bus in diagnostic applications. It standardizes the CAN interface for diagnostic test equipment, focusing on the physical layer, data link layer, and network layer aspects of communication. Key specifications include:

Bit Rate: The CAN bus bit rate must be either 250 Kbps or 500 Kbps, providing flexibility while ensuring compatibility.
CAN Identifiers: Both 11-bit (standard) and 29-bit (extended) CAN identifiers are permitted, accommodating different network architectures and addressing needs.
CAN ID Allocation: Specific CAN IDs are reserved and standardized for OBD request and response messages, ensuring that diagnostic tools can reliably communicate with vehicle ECUs.
Data Frame Length: Diagnostic CAN frames must adhere to a maximum data payload length of 8 bytes, a standard CAN limitation.
Cable Length Limit: The OBD2 adapter cable connecting the diagnostic tool to the vehicle is limited to a maximum length of 5 meters to maintain signal integrity and reliable communication.

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

OBD2 communication over CAN bus, as specified in ISO 15765-4, relies on a request-response message structure.

In most passenger vehicles, 11-bit CAN identifiers are used for OBD2 communication. Functional addressing is commonly employed using the CAN ID 0x7DF. This ID acts as a broadcast request, querying all OBD2-compliant Electronic Control Units (ECUs) on the network to respond if they have data relevant to the requested parameter, as defined in ISO 15765-4. In contrast, physical addressing can be used with CAN IDs in the range 0x7E0-0x7E7. These IDs target specific ECUs for requests, although functional addressing (0x7DF) is more frequently used for general OBD2 queries.

ECUs respond to OBD2 requests using 11-bit CAN IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8, typically originating from the Engine Control Module (ECM). Another frequently used response ID is 0x7E9, often from the Transmission Control Module (TCM).

In some vehicle categories, particularly vans and medium to heavy-duty vehicles, the OBD2 specification allows for the use of extended 29-bit CAN identifiers instead of the standard 11-bit IDs.

When 29-bit identifiers are used, the functional addressing CAN ID is 0x18DB33F1. Correspondingly, responses from vehicles using 29-bit IDs are typically found in the CAN ID range 0x18DAF100 to 0x18DAF1FF, with common specific response IDs being 0x18DAF110 and 0x18DAF11E. These 29-bit response IDs are also sometimes represented in the ‘J1939 PGN’ format. Specifically, the PGN 0xDA00 (55808) is used, which the J1939-71 standard designates as ‘Reserved for ISO 15765-2’, further linking OBD2 over CAN to established automotive networking standards.

OBD2 Request and Response Frames: Illustrating the structure of OBD2 protocol request and response frames, emphasizing PID data and parameter flow.

OBD2 vs. Proprietary CAN Bus Data: A comparison between OBD2 and OEM-specific proprietary CAN bus data, highlighting differences in accessibility and standardization.

OBD2 vs. Proprietary CAN Protocols: Specification Scope

It’s crucial to understand that while OBD2 provides a standardized diagnostic interface, a vehicle’s core electronic control units (ECUs) operate using proprietary CAN protocols defined by the Original Equipment Manufacturer (OEM). These OEM-specific protocols are essential for the vehicle’s fundamental functions and are typically unique to the vehicle brand, model, and production year. Unless you are the OEM or have access to their proprietary documentation, interpreting this OEM-specific CAN data is generally not possible without significant reverse engineering efforts.

When a CAN bus data logger is connected to a vehicle’s OBD2 connector, you might observe OEM-specific CAN data alongside OBD2 communication. This OEM data is often broadcast at high rates (1000-2000 frames/second). However, increasingly, modern vehicles incorporate a ‘gateway’ module that restricts access to this OEM CAN data through the OBD2 port, allowing only standardized OBD2 communication.

In essence, OBD2 should be considered an ‘additional’ higher-layer protocol that operates in parallel with the OEM-specific protocol. It’s a diagnostic overlay, not the fundamental communication system of the vehicle.

Bit-rate and ID Validation: Protocol Determination as per Specification

As per the OBD2 specification and ISO 15765-4, OBD2 communication may utilize one of two bit rates (250 Kbps or 500 Kbps) and either 11-bit or 29-bit CAN IDs. This results in four potential protocol combinations. Modern vehicles most commonly use 500 Kbps and 11-bit CAN IDs. However, diagnostic tools must systematically determine the correct combination for each vehicle to ensure proper communication.

ISO 15765-4 provides a recommended initialization sequence to automatically determine the appropriate combination. This process, illustrated in the flowchart below, relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (detailed in the OBD2 PID section). The validation also leverages the fact that transmitting data at an incorrect bit rate will result in CAN error frames, which can be detected by the diagnostic tool.

Current versions of ISO 15765-4 also account for vehicles that may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than the traditional OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS, which is based on ISO 15031-5/SAE J1979, as it is the dominant standard in non-EV vehicles today. WWH-OBD/OBDonUDS, based on ISO 14229 and ISO 27145-3/SAE J1979-2, is more prevalent in EU trucks and buses.

To differentiate between OBDonEDS and OBDonUDS protocols, diagnostic tools may send additional request messages. Specifically, UDS requests using 11-bit or 29-bit functional address IDs for service 0x22 and Data Identifier (DID) 0xF810 (protocol identification) can be used. Vehicles supporting OBDonUDS are required to have ECUs that respond to this DID, allowing for protocol detection.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) remains the standard in most non-electric vehicles, while WWH-OBD is primarily used in heavy-duty commercial vehicles, particularly in Europe.

OBD2 Bit-rate and CAN ID Validation Flowchart: A flowchart illustrating the ISO 15765-4 compliant process for OBD2 bit-rate and CAN ID validation, ensuring correct communication parameters.

Five Lower-Layer OBD2 Protocols: An overview of the five lower-layer protocols used in OBD2 standards, including CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO 9141.

Five Lower-Layer OBD2 Protocols: Historical Specification Context

While CAN bus (ISO 15765) is the dominant lower-layer protocol for OBD2 in modern vehicles, particularly since the 2008 mandate, it’s important to recognize the historical context and other protocols that have been part of the OBD2 specification, especially when working with older vehicles (pre-2008). Inspecting the OBD2 connector pinout of older vehicles can help determine which of these legacy protocols might be in use. These older protocols include:

ISO 15765 (CAN bus): As discussed, the current standard, mandatory in US cars since 2008 and now globally prevalent.
ISO 14230-4 (KWP2000): The Keyword Protocol 2000 was widely used in vehicles manufactured around 2003 and later, particularly in Asian markets.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles produced roughly between 2000 and 2004.
SAE J1850 VPW (Variable Pulse Width Modulation): Primarily used in older General Motors (GM) vehicles.
SAE J1850 PWM (Pulse Width Modulation): Predominantly used in older Ford vehicles.

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

All OBD2 data communication over CAN bus relies on the ISO Transport Protocol (ISO-TP), formally specified in ISO 15765-2. ISO-TP is crucial because it enables the transmission of data payloads that exceed the 8-byte limit of a standard CAN frame. This capability is essential for OBD2 functionalities that require larger data transfers, such as retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often cannot fit within a single CAN frame. ISO 15765-2 provides mechanisms for segmentation (dividing large messages into smaller CAN frames), flow control (managing the data transfer rate), and reassembly (reconstructing the original message from the segmented frames). For a more detailed explanation of ISO-TP and its functionalities, refer to our introduction to UDS, as UDS also commonly uses ISO-TP for message transport.

However, many OBD2 data requests and responses are concise enough to fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In a Single Frame, the first data byte of the CAN frame, known as the Protocol Control Information (PCI) field, indicates the payload length (excluding any padding). This leaves up to 7 bytes within the CAN frame’s data field available for the actual OBD2-related communication content, such as mode and PID information, and data values.

ISO-TP Frame Types for OBD2: Illustrating various ISO-TP frame types used in OBD2 communication as per ISO 15765-2, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To fully understand OBD2 communication over CAN, it’s essential to examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message, when transported over CAN, consists of a CAN identifier, a data length indicator (PCI field), and the actual data payload. The data payload itself is structured into distinct components: Mode, Parameter ID (PID), and data bytes. These components are defined by the OBD2 specification, specifically SAE J1979 and ISO 15031-5.

OBD2 Message Structure Breakdown: An explanation of the OBD2 message structure, breaking down the frame into Mode, Parameter ID (PID), Identifier (ID), and Data Bytes.

Example: OBD2 Request and Response – Vehicle Speed

To illustrate the OBD2 message structure in practice, consider a request for the ‘Vehicle Speed’ parameter and the corresponding response.

In this example, an external diagnostic tool initiates communication by sending a request message to the vehicle. This request is sent with CAN ID 0x7DF (functional addressing) and contains a 2-byte payload: Mode 0x01 and PID 0x0D. Mode 0x01 signifies ‘Show current data’, and PID 0x0D is the specific code for ‘Vehicle Speed’ within Mode 0x01, as defined in the OBD2 specification.

Upon receiving this request, the vehicle’s ECU (typically the ECM) responds with a message using CAN ID 0x7E8. The response payload consists of 3 bytes. The first byte indicates the response Mode, which is 0x41. In OBD2 responses, 0x40 is added to the requested Mode value, so 0x41 corresponds to a response to Mode 0x01. The subsequent bytes contain the requested data, in this case, the vehicle speed. The example shows the 4th byte as 0x32.

To interpret this hexadecimal value 0x32, we consult the OBD2 PID decoding rules for PID 0x0D (Vehicle Speed). These rules, part of the OBD2 specification, define how raw data bytes translate into physical values. For Vehicle Speed (PID 0x0D), the value 0x32 (decimal 50) directly corresponds to a speed of 50 km/h. This decoding process is essential to convert the raw data bytes from the OBD2 response into meaningful physical units.

OBD2 Request and Response Example (7DF-7E8): A request (ID 7DF) and response (ID 7E8) sequence for OBD2 communication, illustrating a typical PID data exchange.

OBD2 PID Example – Vehicle Speed (0D): An example focusing on OBD2 PID 0D, representing vehicle speed, and how it is interpreted within the OBD2 framework.

OBD2 Service Modes: An overview of the 10 OBD2 service modes (diagnostic services), including current data, freeze frame, and clear DTCs, highlighting the range of diagnostic capabilities.

The 10 OBD2 Services (Modes): Diagnostic Functions Defined by Specification

The OBD2 specification defines 10 diagnostic services, also commonly referred to as OBD2 modes. Each service or mode corresponds to a specific type of diagnostic information or action. Mode 0x01, for example, is used to request and display current, real-time data parameters. Other modes are designed to access and manage Diagnostic Trouble Codes (DTCs), retrieve freeze frame data (snapshots of data when a DTC was set), and clear DTCs.

It is important to note that vehicles are not required to support all 10 OBD2 modes. The OBD2 specification mandates support for certain core modes related to emissions diagnostics, but manufacturers have flexibility in implementing the full range of services. Furthermore, vehicle manufacturers may also implement OEM-specific OBD2 modes beyond the 10 standardized modes, allowing for extended diagnostic capabilities specific to their vehicles.

In the structure of OBD2 messages, the mode is always indicated in the second byte of the data payload. In a request message, the mode is directly included (e.g., 0x01 for Mode 1). However, in a response message, as per the OBD2 specification, 0x40 is added to the requested mode value. For example, a response to a Mode 0x01 request will have a mode byte of 0x41 (0x01 + 0x40). This offset helps to clearly distinguish between request and response messages and to identify the service mode to which the response pertains.

OBD2 Parameter IDs (PIDs): Data Points within the Specification

Within each OBD2 mode, the OBD2 specification defines a set of Parameter IDs (PIDs). PIDs are codes used to request specific pieces of information or data points within a particular diagnostic service mode.

For instance, Mode 0x01 (Show current data) includes approximately 200 standardized PIDs. These PIDs cover a wide range of real-time vehicle parameters, such as vehicle speed, engine RPM, coolant temperature, and fuel level. However, it’s crucial to understand that while the OBD2 specification defines these PIDs, a specific vehicle is not obligated to support all PIDs within a given mode. In practice, most vehicles only implement a subset of the standardized PIDs, focusing on those relevant to emissions monitoring and basic diagnostics. The actual set of supported PIDs can vary significantly between vehicle makes, models, and years.

Among the PIDs defined in the OBD2 specification, one PID holds a special significance: Mode 0x01 PID 0x00 (Supported PIDs [01-20]). If an emissions-related ECU supports any OBD2 services at all, the OBD2 specification mandates that it must support Mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds by indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. By querying PID 0x00, a diagnostic tool can quickly determine if an ECU is OBD2 compliant and what basic set of PIDs it offers. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of Mode 0x01 PIDs (0x21-0x40, 0x41-0x60, and so on), allowing a diagnostic tool to systematically discover the full range of supported PIDs in Mode 0x01.

OBD2 Request and Response Frames: Illustrating the structure of OBD2 protocol request and response frames, emphasizing PID data and parameter flow.

OBD2 PID Overview Tool: A screenshot of an OBD2 PID overview tool, demonstrating the interface for Service 01 and PID selection and data interpretation.

Practical Resource: OBD2 PID Overview Tool

The OBD2 specification documents, SAE J1979 and ISO 15031-5, include appendices that detail the scaling and conversion formulas for standard OBD2 PIDs. This scaling information is essential for accurately decoding the raw data bytes received in OBD2 responses into meaningful physical values, as explained in our CAN bus introduction.

To simplify the process of working with Mode 0x01 PIDs, we offer a dedicated OBD2 PID overview tool. This tool assists in constructing OBD2 request frames for specific PIDs and dynamically decodes the OBD2 responses, applying the correct scaling and units to display the data in a human-readable format. It’s a valuable resource for anyone working with OBD2 data and needing to quickly look up PID information and understand data interpretation.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

This section provides a practical example of how to log OBD2 data using the CANedge CAN bus data logger. The CANedge is configurable to transmit custom CAN frames, making it suitable for sending OBD2 requests and logging the responses.

To begin, connect the CANedge to your vehicle’s OBD2 port using an OBD2-DB9 adapter cable. Once connected, and configured, the CANedge can be set up to automatically log OBD2 data.

OBD2 Data Logger Setup: Illustrating an OBD2 data logger requesting PID data using CAN IDs 7DF and 7E8, depicting a typical OBD2 logging configuration.

Supported PIDs Validation: Reviewing responses to ‘Supported PIDs’ requests in asammdf, a tool for analyzing CAN bus data.

Step #1: Bit-rate, ID, and Supported PID Discovery

As outlined in ISO 15765-4, determining the correct bit-rate and CAN IDs is crucial for OBD2 communication. The CANedge can be used to systematically test and identify these parameters. The process is as follows (refer to the CANedge Introduction for detailed setup instructions):

Bit-rate Test: Start by attempting to send a CAN frame at 500 Kbps. Check if the transmission is successful (e.g., by monitoring for CAN error frames). If unsuccessful, repeat the test at 250 Kbps.
Bit-rate Confirmation: Use the successfully tested bit-rate for all subsequent OBD2 communication.
Supported PIDs Query: Send multiple ‘Supported PIDs’ requests (Mode 0x01 PID 0x00, PID 0x20, etc.) to the vehicle.
Response Analysis: Review the responses received from the vehicle’s ECUs.
CAN ID Determination: Based on the response CAN IDs (0x7E8-0x7EF range for 11-bit, 0x18DAF1xx range for 29-bit), determine whether the vehicle is using 11-bit or 29-bit CAN identifiers for OBD2 communication.
PID Support Identification: Analyze the data bytes in the responses to ‘Supported PIDs’ requests. These bytes indicate which PIDs within each 32-PID range are supported by the vehicle.

We provide pre-configured CANedge configurations to automate these initial tests, simplifying the setup process.

In most non-electric vehicles manufactured after 2008, you can typically expect to find support for 40-80 OBD2 PIDs, using a 500 Kbps bit-rate, 11-bit CAN IDs, and the standard OBD2/OBDonEDS protocol.

As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD2 request, particularly when using the functional addressing ID 0x7DF. This is because 0x7DF is a broadcast request, and multiple OBD2-compliant ECUs may respond. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, responses to this PID are often numerous. For subsequent ‘Supported PIDs’ requests (PID 0x20, etc.), the number of responding ECUs typically decreases. Notice that in the example, the ECM (0x7E8) supports all PIDs that are supported by other ECUs. Therefore, to reduce bus load, you could switch to ‘Physical Addressing’ using CAN ID 0x7E0 for subsequent requests, targeting only the ECM for responses.

Step #2: Configuring OBD2 PID Requests for Logging

Once you have identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can configure the CANedge to log specific PIDs of interest. To optimize your OBD2 data logging configuration, consider the following:

CAN Addressing: Transition from functional addressing (0x7DF) to ‘Physical Addressing’ request IDs (e.g., 0x7E0, 0x7E1, etc.) to target specific ECUs. This avoids receiving redundant responses from multiple ECUs for each request, reducing CAN bus load and simplifying data analysis.
Request Spacing: Implement a delay of 300-500 milliseconds between consecutive OBD2 requests. Aggressively spamming the ECUs with rapid requests can sometimes cause them to become unresponsive or to limit their response rate. Proper spacing ensures reliable communication.
Power Management: To prevent battery drain, especially during extended logging sessions when the vehicle is inactive, use triggers in your CANedge configuration to stop transmitting OBD2 requests when the vehicle is turned off or inactive. This prevents unnecessary ‘wake-up’ calls to the ECUs.
Data Filtering: To manage the volume of logged data, especially if your vehicle also broadcasts OEM-specific CAN data alongside OBD2, configure filters on the CANedge to selectively record only OBD2 response messages (e.g., messages with CAN IDs in the 0x7E8-0x7EF range). This reduces data storage requirements and simplifies post-processing.

With these configurations in place, the CANedge is ready to efficiently and reliably log raw OBD2 data from your vehicle.

CANedge OBD2 Request List Example: An example configuration list for CANedge, showing a set of OBD2 PID requests configured for transmission.

OBD2 Data Visualization in asammdf: Visual plot of decoded OBD2 data in asammdf, demonstrating data interpretation using a CAN bus DBC file.

Step #3: DBC Decoding of Raw OBD2 Data

To effectively analyze and visualize the logged raw OBD2 data, you need to decode it into physical values (e.g., km/h, °C, RPM). This decoding process involves converting the raw hexadecimal data bytes into human-readable units using scaling factors and offsets defined in the OBD2 specification (ISO 15031-5/SAE J1979) and related documentation (e.g., Wikipedia).

For convenience, we provide a free OBD2 DBC file. This DBC file simplifies the DBC decoding of raw OBD2 data within most standard CAN bus software tools, including asammdf, Vector CANalyzer, and Wireshark with CAN bus plugins.

Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This complexity arises because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8 for ECM responses). Therefore, the CAN ID alone is not sufficient to uniquely identify the signals encoded in the payload.

To correctly decode OBD2 data, you must consider not only the CAN ID but also the OBD2 mode and the specific OBD2 PID. This form of multiplexing is known as ‘extended multiplexing‘. It can be effectively implemented in DBC files using multiplexer definitions, allowing software tools to correctly interpret the payload content based on the combination of CAN ID, mode, and PID. Our provided OBD2 DBC file is structured to handle this extended multiplexing, enabling seamless decoding of your logged OBD2 data.

CANedge: Your OBD2 Data Logging Solution

The CANedge offers a user-friendly solution for recording OBD2 data directly to an 8-32 GB SD card. Simply connect the CANedge to your vehicle’s OBD2 port to begin logging. The logged data can then be easily accessed and decoded using free software and APIs in conjunction with our OBD2 DBC file.

OBD2 logger intro CANedge product details

OBD2 Multi-Frame Examples: ISO-TP in Action

As previously discussed, OBD2 communication utilizes ISO-TP (ISO 15765-2) for transporting messages, particularly when data exceeds 8 bytes and requires multi-frame transmission. While many examples so far have focused on single-frame communication, this section provides examples of multi-frame OBD2 communication scenarios.

Multi-frame OBD2 exchanges necessitate the use of flow control frames, as detailed in our UDS introduction. In practice, a common approach is to transmit a static flow control frame approximately 50 milliseconds after the initial request frame, as illustrated in the CANedge configuration example below.

Analyzing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP message handling. The CANedge MF4 decoders are designed to handle ISO-TP and can reconstruct multi-frame OBD2 messages for analysis.

OBD2 Multi-Frame Request Example: An example of an OBD2 multi-frame request message, specifically for retrieving the Vehicle Identification Number (VIN).

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is a crucial piece of vehicle information for telematics, diagnostics, and various automotive applications (see our UDS introduction for more context on VIN usage in diagnostics). OBD2 provides a standardized method to retrieve the VIN using mode 0x09 (Request Vehicle Information) and PID 0x02 (Vehicle Identification Number). The sequence is as follows:

The diagnostic tool initiates the VIN retrieval process by sending a Single Frame request. This request frame contains the PCI field (0x02, indicating a Single Frame), the request service identifier (0x09 for Mode 0x09), and the PID (0x02 for VIN).

The vehicle ECU responds with a multi-frame response. The first frame of this response is a First Frame, indicated by the PCI field. This First Frame contains the total length of the multi-frame message (0x014 = 20 bytes), the response mode (0x49, which is 0x09 + 0x40), and the PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case, indicating a single VIN is being returned (see ISO 15031-5 / SAE J1979 for NODI details). The remaining 17 bytes of the multi-frame message constitute the VIN itself. This VIN data is encoded in HEX ASCII format and can be converted to a human-readable ASCII string using methods discussed in our UDS introduction.

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

The OBD2 specification allows diagnostic tools to request up to 6 Mode 0x01 OBD2 PIDs within a single request frame. When a multi-PID request is made, the ECU is expected to respond with data for all supported PIDs from the request list (omitting data for any unsupported PIDs). The response may span multiple frames, using ISO-TP if necessary, to accommodate the data for multiple PIDs.

This multi-PID request feature is a powerful mechanism to increase data acquisition efficiency and frequency. However, it introduces complexities in data interpretation. The signal encoding within the multi-frame response becomes tightly coupled to the specific PIDs requested and their order in the request. This makes the use of generic OBD2 DBC files challenging for decoding multi-PID responses.

Therefore, while technically feasible, we do not generally recommend using multi-PID requests in practice, especially for generic data logging and analysis scenarios.

Below is an example trace illustrating a multi-PID request and response exchange:

The multi-frame response structure is similar to the VIN example, but with the added complexity that the payload includes both the requested PIDs and the data values for each. In this example, the PIDs in the response are ordered in the same sequence as they were requested, which is a common practice but not strictly mandated by the ISO 15031-5 standard.

Decoding such multi-PID responses using generic DBC files is very difficult due to the variable data layout and PID ordering. For practical data logging and analysis, we advise against using multi-PID requests unless you are working with specialized tools that have built-in support for this specific request method and the corresponding response structure. Effectively, you are dealing with a complex case of extended multiplexing, where the data layout within the payload is dynamically determined by the PIDs requested. Creating a generic DBC file that can handle all possible combinations of multi-PID requests and responses across different vehicles becomes exceptionally challenging, if not impossible. Furthermore, if you send multiple different multi-PID requests, distinguishing between their responses solely based on CAN IDs becomes problematic.

Workarounds could involve custom scripting and recording both request and response messages. A script could then be developed to interpret the response payload based on the preceding request message, effectively linking request and response data. However, such approaches are complex to implement and scale for large-scale data analysis.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 provides a standardized method to retrieve emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. The request for DTCs in Mode 0x03 does not include a PID. When an ECU receives a Mode 0x03 request, it responds with the number of DTCs currently stored in its memory (which could be zero if no DTCs are active). Each DTC is represented by 2 data bytes. If more than 2 DTCs are stored, the response will require multi-frame transmission using ISO-TP to accommodate the data.

The 2-byte DTC value encoding is defined in ISO 15031-5 and ISO 15031-6. The first 2 bits of the first byte indicate the ‘category’ of the DTC (e.g., Powertrain, Chassis, Body, Network). The remaining 14 bits of the 2-byte DTC value form a 4-digit code, typically displayed in hexadecimal format. The decoded DTC values can be looked up in various OBD2 DTC lookup tools and databases, such as repairpal.com, to obtain a textual description and potential causes of the fault.

The example below illustrates a request to an ECU that has 6 DTCs stored:

OBD2 DTC Decoding Example: Illustrating the decoding process for OBD2 Diagnostic Trouble Codes (DTCs), including category bits and the 4-digit code interpretation.

OBD2 Data Logging: Use Case Examples

OBD2 data logging from cars and light trucks has numerous applications across various industries and use cases:

Vehicle Data Logging

OBD2 data logging in passenger vehicles can be used for diverse purposes, including fuel efficiency analysis, driver behavior monitoring, prototype component testing, and usage-based insurance models.

OBD2 Logger Solutions

Real-time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data. This capability is invaluable for mechanics and technicians for diagnosing vehicle issues, monitoring system performance during repairs, and conducting live tests.

OBD2 Real-time Streaming Interfaces

Predictive Maintenance and Telematics

Cloud-connected IoT OBD2 loggers facilitate remote vehicle monitoring for predictive maintenance applications. By continuously analyzing OBD2 data, potential breakdowns and maintenance needs can be predicted and addressed proactively, minimizing downtime and repair costs.

Predictive Maintenance Solutions

Vehicle Black Box Recording

An OBD2 logger can function as a ‘black box’ for vehicles and equipment. Recording OBD2 data provides valuable evidence in case of accidents, disputes, or warranty claims. The logged data can be used for incident reconstruction, performance analysis, and diagnostic forensics.

CAN Bus Black Box Loggers

Do you have a specific OBD2 data logging application in mind? Contact us for a free consultation and expert guidance!

Explore our guides section for more in-depth introductions to CAN bus and related technologies, or download our comprehensive ‘Ultimate Guide’ PDF for a complete resource.

Need to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Explore OBD2 Loggers Contact us for assistance