Decoding the OBD2 Protocol: Your Comprehensive Guide to Automotive Diagnostics

Looking for a straightforward and in-depth understanding of the Obd2 Protocol?

This guide provides a comprehensive introduction to the On-Board Diagnostics 2 (OBD2) protocol, covering everything from the OBD2 connector and Parameter IDs (PIDs) to its connection with the CAN bus.

This is more than just an introduction—it’s a practical guide. You’ll learn how to request and interpret OBD2 data, understand key logging applications, and gain valuable practical tips to effectively utilize this powerful diagnostic tool.

Discover why this guide is becoming recognized as a leading resource for understanding the OBD2 protocol.

You can also watch our introductory video on OBD2 above – or download the PDF version for offline access.

Article Contents

Author: Martin Falch (Updated January 2025)

Download PDF Icon

Download this guide as a PDF

What Exactly is the OBD2 Protocol?

OBD2, or On-Board Diagnostics 2, serves as your vehicle’s integrated self-diagnostic system. It’s a standardized protocol designed to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector.

You’ve likely already encountered OBD2 in action:

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

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

To do this, the mechanic connects the OBD2 scanner to the 16-pin OBD2 connector, typically located near the steering wheel. The scanner transmits ‘OBD2 requests’ to the vehicle, and the vehicle responds with ‘OBD2 responses’. These responses can contain crucial information like speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling faster and more efficient troubleshooting.

Alt: OBD2 system overview showing the Malfunction Indicator Light (MIL) and a mechanic using an OBD2 scanner to diagnose a vehicle.

OBD2 Protocol Compatibility: Does Your Car Support It?

In most cases: Yes, it probably does!

The vast majority of modern non-electric vehicles are OBD2 compliant, and many operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 support. As scantool.net explains, compliance depends on the vehicle’s origin and year of manufacture:

OBD2 Compliance Guide by Region and Year
Alt: OBD2 compliance timeline infographic for US and EU vehicles, highlighting mandatory implementation years for cars and light trucks.

A Brief History of the OBD2 Protocol

The OBD2 protocol has its roots in California. The California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards to monitor and control emissions.

The Society of Automotive Engineers (SAE) further developed the OBD2 standard, standardizing DTCs and the OBD connector itself through SAE J1962 across different vehicle manufacturers.

The implementation of the OBD2 standard was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU required OBD2 for gasoline cars.
2003: The EU extended the requirement to diesel cars (EOBD – European On-Board Diagnostics).
2005: OBD2 compliance was mandated in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory in the US for heavy-duty vehicles.

Alt: Infographic illustrating the history of OBD2 protocol, emphasizing its origin in emission control and evolution through different years and vehicle types.

Alt: Detailed timeline infographic summarizing the historical milestones of OBD2 protocol development and implementation across different regions.

Alt: Conceptual infographic depicting the future of OBD2 with OBD3, remote diagnostics, cloud connectivity, and IoT integration for enhanced vehicle monitoring.

The Future of OBD2 Protocol

While firmly established, the OBD2 protocol is evolving. But what does the future hold?

Here are key trends shaping the future of OBD2:

Originally designed for emissions monitoring and testing, legislated OBD2 faces new challenges. Notably, electric vehicles (EVs) are not mandated to support OBD2 in any form. In practice, most modern EVs largely forgo standard OBD2 requests, opting instead for OEM-specific UDS communication. This shift often makes data retrieval from EVs difficult, except in cases where reverse engineering efforts have yielded decoding rules. Examples include our case studies on electric vehicles, covering brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

The limitations of current OBD2 implementations, particularly in data richness and lower-layer protocols, have spurred the development of modern alternatives. These include WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both aim to improve OBD communication by utilizing the UDS protocol as a foundation. For a deeper dive into these protocols, refer to our introduction to UDS.

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

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

OBD3 envisions adding a small radio transponder (similar to those used for toll roads) to all cars. This would enable vehicles to transmit their Vehicle Identification Number (VIN) and DTCs wirelessly via WiFi to a central server for automated checks.

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

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

The OBD2 protocol was initially intended for stationary emission controls.

However, today, OBD2 is widely used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and more. Interestingly, the German car industry is seeking to restrict this access:

“OBD has been designed to service cars in repair shops. It was never 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 suggests disabling OBD2 functionality during driving, collecting data centrally by manufacturers instead. This would effectively give manufacturers control over ‘automotive big data’.

Arguments for this shift include security enhancements (e.g., mitigating the risk of car hacking). However, many perceive this as a commercially motivated move. Whether this trend gains momentum remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Alt: Conceptual image illustrating the potential removal of the OBD2 connector in electric vehicles, symbolizing restricted data access in future EVs.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

Access our 12 ‘simple introductions’ in a comprehensive 160+ page PDF:

Download the Ultimate CAN Bus Guide Now

CAN Bus – The Ultimate Guide PDF Cover

OBD2 Protocol Standards

On-board diagnostics, OBD2, is a higher-layer protocol, functioning like a language. CAN, on the other hand, is a communication method, akin to a telephone line. This makes OBD2 comparable to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

These standards can be visualized within a 7-layer OSI model. The following sections will focus on the most crucial aspects.

In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standards defined for OBD in the USA (SAE) and the EU (ISO). Many standards are technically very similar, for example, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

Alt: OSI 7-layer model diagram illustrating how OBD2 and CAN bus protocols fit within the framework, highlighting relevant ISO and SAE standards.

Alt: Detailed pinout diagram of a Type A OBD2 connector socket (female), showing pin assignments for various signals and power.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, provides easy access to your vehicle’s data.

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

Key points to note:

The connector is typically near the steering wheel, but its exact location may be hidden.
Pin 16 provides battery power (often even when the ignition is off).
The OBD2 pinout varies depending on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.

OBD2 Connector Types: A vs. B

In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is more typical in medium and heavy-duty vehicles.

As shown in the illustration, 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 differ, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

Type B OBD2 connectors feature an interrupted groove in the middle, allowing for physical distinction. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A connector will not fit into a Type B socket.

Alt: Comparison diagram of OBD2 Connector Type A and Type B, highlighting differences in physical structure, voltage supply (12V vs 24V), and typical vehicle applications (cars vs trucks).

Alt: Diagram illustrating the relationship between OBD2 protocol and CAN bus, emphasizing ISO 15765 as the standard for OBD2 over CAN.

OBD2 Protocol and CAN Bus: 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 and standards applied to the CAN standard (ISO 11898).

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

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

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication relies on request/response message exchanges.

In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs to check if they have data for the requested parameter (refer to ISO 15765-4). CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs (less common).

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

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

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

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

Alt: Diagram illustrating the structure of OBD2 request and response frames, highlighting the positions of Mode, PID, and data parameters within the CAN frame.

OBD2 CAN Bus Identifiers Table Overview

Alt: Diagram contrasting OBD2 protocol with OEM-specific proprietary CAN protocols, emphasizing OBD2 as a standardized diagnostic layer separate from OEM’s control systems.

OBD2 Protocol vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific proprietary CAN protocols, independent of OBD2. These protocols are unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is generally not possible without reverse engineering.

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

Think of OBD2 as a separate, ‘add-on’ higher-layer protocol that runs alongside the OEM’s proprietary communication network.

Bit Rate and ID Validation for OBD2 Protocol

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

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This process relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit rate transmissions will generate CAN error frames.

Newer versions of ISO 15765-4 consider vehicles that might support OBD communication via OBDonUDS instead of 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, diagnostic tools may send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

In practice, OBDonEDS (also termed 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.

Alt: Flowchart illustrating the process of OBD2 bit rate and CAN ID validation as per ISO 15765-4, guiding diagnostic tools through protocol detection.

Alt: Diagram listing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000 (ISO 14230-4), ISO 9141-2, SAE J1850 VPW, and SAE J1850 PWM, highlighting CAN as the dominant modern standard.

Five Lower-Layer OBD2 Protocols

While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2 in most vehicles, especially post-2008, it’s helpful to be aware of the other four protocols used in older vehicles. The OBD2 connector pinout can sometimes indicate which protocol is in use.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008; now the most common protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages [ISO 15765-2]

All OBD2 data communication over CAN bus utilizes the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte CAN frame limit, which is essential for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For more details, see our introduction to UDS.

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

Alt: Diagram illustrating different ISO-TP frame types used in OBD2 communication: Single Frame, First Frame, Consecutive Frame, and Flow Control Frame, as defined in ISO 15765-2.

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

To better grasp OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message comprises a CAN identifier, a data length indicator (PCI field), and the actual data. The data section is further structured into Mode, Parameter ID (PID), and data bytes.

Alt: Diagram breaking down the structure of a raw OBD2 message frame, showing the position and function of CAN ID, PCI field, Mode, PID, and Data Bytes.

OBD2 Request/Response Example

Before detailing each component of the OBD2 message, consider this example of a request and response for ‘Vehicle Speed’.

An external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF, containing two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and three payload bytes, including the vehicle speed value in the 4th byte, 0x32 (which is 50 in decimal).

By consulting the OBD2 PID specifications for PID 0x0D, we can determine that the physical value corresponds to 50 km/h.

Next, we’ll delve into OBD2 modes and PIDs in more detail.

Alt: Example diagram showing an OBD2 request frame (CAN ID 0x7DF, Mode 0x01, PID 0x0D) and the corresponding response frame (CAN ID 0x7E8) for Vehicle Speed.

Alt: Detailed breakdown of OBD2 PID 0x0D (Vehicle Speed) example, showing the hexadecimal value 0x32 being converted to a decimal value of 50 km/h.

Alt: Diagram outlining the 10 standardized OBD2 service modes (or modes), including Current Data, Freeze Frame Data, Clear DTCs, and others, with Mode 0x01 highlighted for real-time data.

The 10 OBD2 Services (Modes)

The OBD2 protocol defines 10 diagnostic services, commonly referred to as modes. Mode 0x01 is used to access current real-time data, while other modes are used to retrieve and clear diagnostic trouble codes (DTCs) or access freeze frame data.

Vehicles are not required to support all 10 standardized OBD2 modes, and manufacturers may implement additional OEM-specific modes beyond these.

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

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the data being requested or provided.

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

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a crucial ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, 0x60, …, 0xC0 can be used to determine support for the remaining Mode 0x01 PIDs.

Alt: Diagram emphasizing the role of Parameter IDs (PIDs) in OBD2 request and response frames, showing how PIDs specify the data parameter being accessed.

OBD2 PID Overview Tool Screenshot
Alt: Screenshot of an OBD2 PID overview tool, displaying Service 01 PIDs and their descriptions, aiding in OBD2 data interpretation and request construction.

Tip: 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, utilize our OBD2 PID overview tool. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

Access the OBD2 PID Overview Tool

Practical Guide: Logging and Decoding OBD2 Data

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

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

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

Alt: Diagram showing a CANedge data logger connected to a vehicle’s OBD2 port via an OBD2-DB9 adapter, illustrating a typical OBD2 data logging setup.

OBD2 Bit Rate Validation Test Screenshot
Alt: Screenshot demonstrating bit rate validation for OBD2 communication, showing successful CAN frame transmission at 500K during initial setup.

OBD2 Supported PIDs Test in asammdf GUI
Alt: Screenshot from asammdf GUI displaying responses to ‘Supported PIDs’ requests, showing results of OBD2 PID validation and ECU responses.

OBD2 Supported PIDs Review in OBD2 Lookup Tool

Step #1: Validate Bit Rate, IDs, and Supported PIDs

As previously discussed, ISO 15765-4 outlines how to determine the bit rate and IDs used by a specific vehicle. You can perform this validation using the CANedge as follows (refer to the CANedge Introduction for detailed instructions):

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 or 29-bit CAN ID usage based on response IDs.
Identify supported PIDs based on response data.

We offer plug-and-play configurations to streamline these validation 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 illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This occurs because we use the 0x7DF request ID, which polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support Service 0x01 PID 0x00, numerous responses to this PID are frequently observed. As evident, the number of responding ECUs gradually decreases for subsequent ‘Supported PIDs’ requests. Notably, the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

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

Consider these factors when configuring your PID requests:

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

With these configurations in place, your CANedge is ready to log raw OBD2 data!

CANedge OBD2 PID Request Transmit List Example
Alt: Example transmit list configuration for CANedge, showing a set of OBD2 PID requests configured for data logging, demonstrating practical PID selection and request setup.

OBD2 Data Visualization in asammdf with DBC Decoding
Alt: Screenshot of OBD2 data visualized in asammdf software, showing decoded signals plotted over time after applying a DBC file, demonstrating practical OBD2 data analysis.

Step #3: DBC Decode Raw OBD2 Data

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

The necessary decoding information is found in ISO 15031-5/SAE J1979 (and readily available on 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 is slightly more complex than standard CAN signal decoding. This is because multiple OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Thus, the CAN ID alone is insufficient to uniquely identify the signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to correctly identify each signal. This multiplexing technique is known as ‘extended multiplexing‘, and it can be implemented in formats like DBC files.

CANedge: Your OBD2 Data Logger Solution

The CANedge provides a streamlined solution for recording OBD2 data directly to an SD card (8-32 GB). Simply connect it to your vehicle (car, truck, etc.) to begin logging, and then decode the data using free software/APIs and our OBD2 DBC file.

Explore the OBD2 Logger Introduction Learn more about CANedge

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

All OBD2 data is transmitted using the ISO-TP transport protocol (ISO 15765-2). While many examples so far have focused on single-frame communication, this section provides examples of multi-frame communication scenarios.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

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

OBD2 Multi-Frame Request Message for VIN Retrieval
Alt: Example of an OBD2 multi-frame request message used for Vehicle Identification Number (VIN) retrieval, highlighting the structure and parameters for VIN requests.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various other applications (detailed in our UDS introduction). To retrieve the VIN using OBD2 requests, you use Mode 0x09 and PID 0x02:

VIN Retrieval Example using OBD2 Multi-Frame Communication

The diagnostic tool initiates 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 the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for further details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII as discussed in our UDS introduction.

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

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

This feature enhances data collection efficiency, but it also means that signal encoding is specific to the request method, complicating the use of generic OBD2 DBC files for such scenarios. We generally advise against using this method in practice. Below is an example trace illustrating this approach:

Example Trace of Multi-PID Request in OBD2 Communication

The multi-frame response is similar to the VIN example but includes the requested PIDs along with their corresponding data. In this example, the PIDs in the response are ordered similarly to their request order, which is common but not strictly mandated by the ISO 15031-5 standard.

Decoding such responses using generic DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless you are using a tool specifically designed for multi-PID requests. This approach involves extended multiplexing with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying supported PIDs. Furthermore, managing this via DBC manipulation becomes very complex, especially if you send multiple multi-PID requests, as differentiating messages from each other becomes difficult.

Workarounds might include custom scripts that interpret response messages in conjunction with request messages. However, such methods are generally difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

You can use OBD2 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 (possibly 0 if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are 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 form a 4-digit hexadecimal code, as shown in the visual. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

Alt: Diagram illustrating OBD2 Diagnostic Trouble Code (DTC) decoding, showing the 2-byte DTC structure and how it is interpreted into category and code for error identification.

OBD2 DTC Request and Response Example Trace

OBD2 Data Logging: Use Case Examples

OBD2 data from cars and light trucks is valuable in a range of applications:

Alt: Illustration of an OBD2 data logger connected in a car, representing the application of OBD2 logging in vehicle monitoring and diagnostics.

Vehicle Data Logging

OBD2 data logging in cars can be used to optimize fuel efficiency, improve driving habits, test prototype components, and for insurance purposes.

Explore OBD2 Loggers

Alt: Illustration depicting real-time OBD2 data streaming via USB, used for live vehicle diagnostics and monitoring with software interfaces.

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data for immediate diagnostics of vehicle issues.

Learn about OBD2 Streaming

Alt: Illustration of OBD2 data logger used for predictive maintenance, showing data being transmitted to the cloud for analysis and breakdown prediction in vehicles.

Predictive Maintenance

Cars and light trucks can be monitored via IoT-connected OBD2 loggers to predict and prevent potential breakdowns.

Discover Predictive Maintenance Applications

Alt: Illustration of a CAN bus data logger serving as a ‘black box’ in a vehicle, recording data for insurance, warranty, and accident analysis purposes.

Vehicle Black Box Logging

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

Explore CAN Bus Black Box Loggers

Do you have an OBD2 data logging use case in mind? Contact us for expert consultation!

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Purchase OBD2 Data Loggers Contact Us for Support