Understanding OBD2: Your Comprehensive Guide to On-Board Diagnostics

Want to truly understand OBD2?

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

Note: This is designed to be a comprehensive guide, ensuring you gain a deep understanding of OBD2, how it works, and its crucial role in modern vehicle diagnostics and data access.

Discover why this is becoming the go-to resource for anyone seeking to master Understanding Obd2.

You can also check out our introductory OBD2 video above – or download the PDF version for offline reading.

What Exactly is OBD2?

OBD2, or On-Board Diagnostics version 2, is essentially your car’s internal health monitoring system. It’s a standardized system that allows access to your vehicle’s diagnostic trouble codes (DTCs) and a wealth of real-time operational data through a universal OBD2 connector.

You’ve likely already encountered OBD2 in action, perhaps without even realizing it:

Ever seen the check engine light illuminate on your dashboard?

That light is your car signaling that something is amiss. When you take your vehicle to a mechanic, they utilize an OBD2 scanner to pinpoint the problem.

The process involves connecting an OBD2 reader to the OBD2 16-pin connector, typically located beneath the steering wheel. This tool transmits ‘OBD2 requests’ to the car’s computer, and the car responds with ‘OBD2 responses’. These responses can contain vital information like speed, fuel level, and those crucial Diagnostic Trouble Codes (DTCs). This efficient data exchange dramatically speeds up the process of troubleshooting vehicle issues.

Understanding OBD2: Illustration of the Malfunction Indicator Light (MIL), commonly known as the check engine light, highlighting the OBD2 system’s role in vehicle diagnostics.

Is My Car OBD2 Compliant?

The short answer: Almost certainly!

The vast majority of modern, non-electric vehicles are equipped with OBD2 systems, and most of these operate on the CAN bus protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. As scantool.net explains, visual inspection alone isn’t sufficient. A reliable way to check for compliance is based on where and when the vehicle was originally purchased as new:

Understanding OBD2 Compliance: A chart showing the general timelines for OBD2 adoption in the US and EU, helping determine if a vehicle is likely to be compliant based on its region and year of purchase.

A Look at OBD2’s History

The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated the inclusion of OBD systems in all new vehicles starting from 1991 to monitor and control emissions.

The OBD2 standard itself was developed based on recommendations from the Society of Automotive Engineers (SAE). A key aspect of this standardization was the establishment of uniform DTCs and a standardized OBD connector across all vehicle manufacturers (SAE J1962).

From its Californian inception, the OBD2 standard was progressively implemented globally:

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

OBD2 History and Emission Control: An infographic illustrating the historical progression of OBD2, emphasizing its initial focus on emission control and its evolution over time.

Timeline of OBD2 History: A visual timeline summarizing the key milestones in OBD2’s development and mandatory implementation across different regions and vehicle types.

The Future of OBD: A conceptual illustration depicting OBD3 and its potential integration with cloud and IoT technologies for remote diagnostics and emissions testing.

The Future Trajectory of OBD2

OBD2 is firmly established in automotive diagnostics, but its future form is evolving. Let’s examine some significant trends:

Initially, legislative OBD2 was primarily designed for emissions monitoring and testing. Interestingly, this means electric vehicles are not inherently required to support OBD2 in any form. This is reflected in the fact that most modern EVs do not support standard OBD2 requests. Instead, many utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This OEM-specific approach often makes it challenging to access and decode data from EVs, except in cases where reverse engineering efforts have successfully deciphered the communication rules. Examples of successful reverse engineering and data access can be seen in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Currently, OBD2 implementation varies significantly and faces limitations in data richness and underlying communication protocols. In response, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to enhance and streamline OBD communication by using 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 emission tests can seem outdated. Manually performing emission checks is both time-consuming and costly.

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

OBD3 essentially envisions adding a small radio transponder (similar to those used for toll roads) to every car. This transponder would enable the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted via WiFi to a central server for automated checks.

Many devices already facilitate the wireless transmission of CAN or OBD2 data via WiFi or cellular networks – for example, the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While this offers cost savings and convenience, it also raises political and social challenges related to surveillance and data privacy.

The OBD2 protocol was originally conceived for stationary emission control assessments.

However, today, OBD2 is widely used by third-party services to generate real-time vehicle data through OBD2 dongles, CAN loggers, and similar devices. Interestingly, the German car industry is advocating for changes that could significantly impact this:

“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 suggests “deactivating” OBD2 functionality during driving and instead channeling vehicle data to a central server controlled by the manufacturer. This would effectively place automotive manufacturers in control of the burgeoning ‘automotive big data’ landscape.

Arguments for this shift often cite security concerns, such as mitigating the risk of car hacking. However, many industry observers perceive this as a commercially motivated move. Whether this trend gains momentum remains to be seen, but it has the potential to disrupt the market for third-party OBD2-based services.

OBD2 Future and Electric Vehicles: An illustration depicting the potential trend of electric vehicles limiting or blocking OBD2 data access, highlighting the shift in data control.

Get Our ‘Ultimate CAN Guide’

Eager to become a CAN bus expert?

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

Download now

Decoding OBD2 Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol, analogous to a language, while CAN functions as the communication method, similar to a telephone line. This places OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

The OBD2 standards meticulously define the OBD2 connector, the lower-layer communication protocols, OBD2 parameter IDs (PIDs), and much more.

These standards can be categorized within a 7-layer OSI model framework. The following sections will focus on the most critical aspects of these standards.

In the OSI model overview, you might notice that both SAE and ISO standards cover several layers. This generally reflects the standardization of OBD in the US (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

OBD2 and CAN Bus within the OSI Model: A diagram illustrating how OBD2 and CAN bus protocols fit into the 7-layer OSI model, highlighting the relevant ISO and SAE standards for each layer.

OBD2 Connector Pinout Type A: A detailed pinout diagram of a Type A OBD2 connector socket, commonly found in passenger vehicles.

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector serves as the gateway to access your car’s data and is precisely defined by the SAE J1962 / ISO 15031-3 standard.

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

Key points to remember about the OBD2 connector:

It’s typically located near the steering wheel, although it can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration 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 usually connected.

OBD2 Connector Types: A vs. B

In practical applications, you may encounter both Type A and Type B OBD2 connectors. Type A is generally standard in cars, while Type B is more common in medium and heavy-duty vehicles.

As shown in the illustration, both types have similar OBD2 pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates may also differ, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

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

OBD2 Connector Types A and B: A comparative illustration highlighting the differences between Type A and Type B OBD2 connectors, including voltage specifications and physical characteristics.

OBD2 vs. CAN Bus ISO 15765: A diagram visually representing the relationship between OBD2 as a protocol and CAN bus (ISO 15765) as its underlying communication network.

OBD2 and CAN Bus Integration [ISO 15765-4]

Since 2008, CAN bus has been mandated as the primary 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 (DoCAN), specifies a set of constraints 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:

The 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.
The OBD2 adapter cable must not exceed 5 meters in length.

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

All OBD2 communication is based on a request-response message exchange.

In most cars, 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 (as defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 are used for ‘Physical Addressing’ requests to specific ECUs, though this is less common.

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

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

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

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

OBD2 Request and Response Frames: An illustration of the request-response communication model in OBD2, showing the structure of frames and the roles of PIDs and data parameters.

OBD2 vs. Proprietary CAN Bus Data: A conceptual diagram distinguishing between standardized OBD2 data and OEM-specific proprietary CAN bus data within a vehicle’s network.

OBD2 vs. OEM-Specific CAN Protocols

It is important to understand that your vehicle’s electronic control units (ECUs) do not depend on OBD2 for their primary functions. Instead, each original equipment manufacturer (OEM) develops and implements its own proprietary CAN protocols for internal vehicle communication. These OEM-specific CAN protocols can vary significantly between vehicle brands, models, and production years. Typically, access to and interpretation of this proprietary data is restricted unless you are the OEM or have the ability to reverse engineer it.

When you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe OEM-specific CAN data, often broadcast at high rates of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ module acts as a filter, blocking access to this raw CAN data and only allowing OBD2 communication through the OBD2 port.

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol. It’s a standardized layer for diagnostics, not the fundamental communication network of the vehicle itself.

Bit-Rate and ID Validation

As previously mentioned, OBD2 can utilize two different bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. In contemporary vehicles, 500K bit rate and 11-bit IDs are most common. However, external diagnostic tools should systematically verify these parameters.

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

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

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-EV cars today, while WWH-OBD is more commonly found in EU trucks and buses.

OBD2 Bit-Rate and CAN ID Validation Flowchart: A flowchart outlining the process for validating the correct bit-rate and CAN ID configuration for OBD2 communication as per ISO 15765-4.

OBD2 Lower-Layer Protocol Standards: An overview of the five main lower-layer protocols used in OBD2, including CAN (ISO 15765), KWP2000, ISO9141, and SAE J1850 (VPW and PWM).

Five Lower-Layer OBD2 Protocols

While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2 in most vehicles, especially those manufactured post-2008, it’s helpful to be aware of the four other protocols that were previously used, particularly when working with older vehicles. The OBD2 connector pinouts can sometimes provide clues about which protocol a car might be using.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most widely used protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, commonly used in 2003+ vehicles, especially in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from approximately 2000-2004.
SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM – Pulse Width Modulation): Predominantly found in older Ford vehicles.

ISO-TP for OBD2 Message Transport [ISO 15765-2]

All OBD2 data exchange over CAN bus relies on a transport protocol called ISO-TP (ISO 15765-2). This protocol is crucial because it enables the transmission of data payloads larger than the standard 8-byte CAN frame limit. This capability is essential in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 handles segmentation of larger messages, flow control to manage data transfer, and reassembly of segmented messages. More details on ISO-TP can be found in our introduction to UDS.

However, a significant amount of OBD2 data fits 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 (known as the PCI field – Protocol Control Information) indicates the payload length (excluding padding), leaving 7 bytes available for the actual OBD2 communication content.

ISO-TP Frame Types for OBD2: A diagram illustrating the different frame types defined in ISO 15765-2 (ISO-TP) for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To gain a deeper understanding of OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload itself. The data payload is further structured into a Mode byte, a parameter ID (PID), and subsequent data bytes.

OBD2 Message Structure Breakdown: A visual breakdown of the components within an OBD2 message frame, highlighting the positions of the Mode byte, PID, and data bytes.

Example: OBD2 Request and Response

Before we delve into the specifics of each part of the OBD2 message, let’s consider a practical example: requesting and receiving the ‘Vehicle Speed’ parameter.

In this scenario, an external diagnostic tool sends a request message to the vehicle. This message uses CAN ID 0x7DF and contains a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle then responds with a message using CAN ID 0x7E8. This response includes a 3-byte payload, with the vehicle speed value encoded in the 4th byte, which is 0x32 (equivalent to 50 in decimal).

By consulting the OBD2 PID documentation for PID 0x0D, we can determine the decoding rules and convert the raw data value (0x32) into a physical value of 50 km/h.

Next, we will explore the OBD2 modes and PIDs in more detail.

OBD2 Request and Response Example (Vehicle Speed): A CAN bus trace example showing an OBD2 request frame (ID 0x7DF) for vehicle speed and the corresponding response frame (ID 0x7E8) from the vehicle.

OBD2 PID Example – Vehicle Speed (0x0D): An example illustrating the OBD2 PID 0x0D (Vehicle Speed), detailing the request and response parameters and the data interpretation.

OBD2 Service Modes Overview: A visual overview of the 10 standardized OBD2 service modes (or modes), outlining their functions, from retrieving current data to clearing diagnostic trouble codes.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also commonly referred to as modes. Mode 0x01 is used to access current, real-time data parameters, while other modes are designed for retrieving and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data (snapshots of data recorded when a DTC was set).

It’s important to note that vehicles are not required to support all 10 OBD2 modes. Manufacturers may also implement additional, non-standardized modes beyond these 10 for OEM-specific diagnostics.

Within OBD2 messages, the mode is specified in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode value (e.g., a response to mode 0x01 will have a mode value of 0x41).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs).

For example, mode 0x01 encompasses approximately 200 standardized PIDs that provide real-time data on various vehicle parameters, such as speed, RPM, and fuel level. However, a vehicle is not obligated to support every PID within a given mode. In practice, most vehicles only support a subset of the available PIDs.

One PID holds a special significance:

Specifically, if an emissions-related ECU supports any OBD2 services at all, then it must support mode 0x01 PID 0x00. When PID 0x00 is requested in mode 0x01, the vehicle ECU responds by indicating which PIDs in the range of 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for performing an ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs (0x21-0x40, 0x41-0x60, etc.).

(Re-used image – already described above)

OBD2 PID Overview Tool Screenshot: A screenshot of an OBD2 PID overview tool interface, demonstrating how such tools can aid in exploring and understanding OBD2 service 01 PIDs.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain comprehensive scaling information for standard OBD2 PIDs. This information is crucial for decoding the raw data values received from the vehicle into meaningful physical units (as explained in our CAN bus introduction).

If you need to quickly look up details for a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

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

The CANedge’s flexible configuration allows you to define custom CAN frames for transmission, making it ideal for OBD2 logging applications.

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

OBD2 Data Logger Setup: An illustration showing the connection of an OBD2 data logger to a vehicle’s OBD2 port, highlighting the data flow for PID requests and responses.

OBD2 Bit Rate Validation: Screenshot showing the successful validation of the CAN bit rate for OBD2 communication, ensuring correct data transmission.

OBD2 Supported PIDs Test in asammdf: A screenshot from asammdf software showing responses to ‘Supported PIDs’ requests, used to identify which PIDs a vehicle supports.

Step #1: Bit-Rate, ID, and Supported PID Testing

As discussed earlier, ISO 15765-4 outlines the process for determining the correct bit rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests as follows (refer to the CANedge Introduction for detailed instructions):

Bit Rate Test: Transmit a CAN frame at 500K and check for successful transmission (if unsuccessful, try 250K).
Bit Rate Configuration: Use the identified bit rate for all subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Determination: Based on the response IDs, determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2.
Supported PID Identification: Analyze the response data to identify the specific PIDs supported by the vehicle.

We provide ready-to-use configuration files to simplify these initial tests.

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

As shown in the asammdf GUI screenshot, it is common to receive multiple responses to a single OBD request. This is because we use the functional addressing request ID (0x7DF), which queries all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often multiple responses, particularly to this PID. As evident, for subsequent ‘Supported PIDs’ requests, the number of responding ECUs gradually decreases. Notice also that the ECM ECU (0x7E8) itself supports all the PIDs supported by other ECUs in this example. This means that bus load could be reduced by directing subsequent requests specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests

Once you have identified the supported OBD2 PIDs for your vehicle, along with the correct bit rate and CAN IDs, you can proceed to configure your transmit list with the PIDs you wish to log.

Consider these factors when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request and reduce bus load.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly rapid requests may overwhelm the ECUs and lead to dropped responses.
Battery Drain Management: Implement triggers to stop PID requests when the vehicle is inactive to prevent unnecessary battery drain and avoid ‘waking up’ ECUs when the vehicle is off.
Data Filtering: Configure filters to record only OBD2 response messages, especially if your vehicle also broadcasts OEM-specific CAN data, to keep your logs focused and manageable.

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

Example CANedge OBD2 PID Transmit List: A screenshot showing an example configuration of a CANedge transmit list for sending OBD2 PID requests, demonstrating how to set up specific PIDs for logging.

Decoded OBD2 Data Visualization in asammdf: A screenshot from asammdf showing decoded and visualized OBD2 data, plotted from a CAN bus log file using a DBC file for signal interpretation.

Step #3: DBC Decoding of Raw OBD2 Data

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

The necessary decoding information is specified in ISO 15031-5/SAE J1979 and is also often 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 analysis software tools.

Decoding OBD2 data is somewhat more complex than decoding standard CAN signals. This complexity arises because multiple OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to uniquely identify the signals within the payload.

To address this, decoding must consider not only the CAN ID but also the OBD2 mode and PID to correctly identify each signal. This form of multiplexing is known as ‘extended multiplexing‘, and it can be effectively implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge offers a straightforward solution for recording OBD2 data directly to a removable 8-32 GB SD card. Simply connect it to your vehicle’s OBD2 port to start logging data. For data analysis, use our free software and APIs along with our OBD2 DBC file to decode and interpret your logs.

OBD2 logger intro
CANedge product page

OBD2 Multi-Frame Communication Examples [ISO-TP]

All OBD2 data communication, as per ISO 15765-2, utilizes the ISO-TP (transport protocol). While many examples discussed so far involve single-frame communication, this section presents examples of multi-frame communication scenarios.

Multi-frame OBD2 communication necessitates the use of flow control frames to manage the data exchange (refer to our UDS introduction for details on flow control). In practice, a common approach is to transmit a static flow control frame approximately 50 ms after the initial request frame, as illustrated in the CANedge configuration example.

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

OBD2 Multi-Frame Request Example (VIN): A CAN bus trace example showing a multi-frame request message for retrieving the Vehicle Identification Number (VIN) using OBD2.

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

The Vehicle Identification Number (VIN) is often a crucial piece of information for telematics, diagnostics, and various automotive applications (see our UDS introduction for more on VIN retrieval via UDS). To retrieve the VIN using OBD2 requests, you use mode 0x09 and PID 0x02:

The diagnostic tester tool initiates the process by sending a Single Frame request. This frame includes the PCI field (0x02), the request service identifier (0x09), and the PID (0x02).

The vehicle responds with a First Frame. This First Frame contains the PCI field, the total length of the multi-frame response (0x014 = 20 bytes), the 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 (see ISO 15031-5 / SAE J1979 for detailed specifications). The subsequent 17 bytes contain the VIN itself, which can be converted from HEX to ASCII format using methods described in our UDS introduction.

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

OBD2 allows diagnostic tools to request up to six mode 0x01 OBD2 PIDs within a single request frame. The ECU is expected to respond with data for all supported PIDs from the request (omitting data for any unsupported PIDs), potentially using multi-frame responses via ISO-TP if the data exceeds a single CAN frame.

This multi-PID request feature can enhance data collection efficiency and frequency. However, it also introduces complexities because the signal encoding becomes specific to the request method used, making the use of generic OBD2 DBC files challenging for these scenarios. Therefore, we generally advise against using this method in practice. Below is an example trace illustrating what a multi-PID request and response might look like:

The multi-frame response structure is similar to the VIN example, but with the added complexity that the payload includes not only the data values but also identifiers for each of the requested PIDs. In this example, the PIDs in the response are ordered similarly to their order in the request, which is common practice but not strictly mandated by the ISO 15031-5 standard.

Decoding these multi-PID responses using standard DBC files is very challenging and is generally not recommended for practical data logging, unless you are using specialized tools that offer built-in support for this specific approach. Effectively, you are dealing with a complex case of extended multiplexing, compounded by the fact that the payload structure depends on the specific PIDs requested and their order. Creating a generalized DBC file that can handle variations in supported PIDs across different vehicles becomes exceedingly difficult. Furthermore, managing multiple such multi-PID requests and distinguishing between their responses solely through DBC manipulation becomes impractical, if not impossible.

Workarounds could involve custom scripting and recording both request and response messages. A script could then be developed to interpret response messages in the context of their corresponding request messages. However, such approaches are complex to scale and manage for large-scale data analysis.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, specifically the ‘Show stored Diagnostic Trouble Codes’ service. No PID is included in the request for this mode. The targeted ECU(s) will respond with the number of DTCs currently stored (which could be zero if no DTCs are active), with each DTC code occupying 2 data bytes. Multi-frame responses become necessary when more than two DTCs are stored, as they will exceed the 7-byte payload capacity of a single CAN frame.

The 2-byte DTC value is structured into two parts, as defined by ISO 15031-5 and ISO 15031-6. The first two bits of the first byte define the ‘category’ of the DTC (e.g., Powertrain, Body, Chassis, Network), while the remaining 14 bits form a 4-digit code (displayed in hexadecimal format), as shown in the visual. Decoded DTC values can be looked up in various online OBD2 DTC lookup tools, such as repairpal.com.

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

OBD2 DTC Decoding Example: An illustration detailing how to interpret the 2-byte DTC values received in OBD2 responses, including the category bits and the 4-digit DTC code.

OBD2 Data Logging: Real-World Use Cases

OBD2 data from cars and light trucks has a wide range of applications across various industries:

Vehicle Data Logging for Cars

OBD2 data logging in passenger cars is used for diverse purposes, including fuel efficiency optimization, driver behavior analysis, prototype testing, and insurance telematics.

Explore OBD2 Loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data in a human-readable format, essential for on-the-spot vehicle diagnostics and troubleshooting.

Learn about OBD2 Streaming

Predictive Vehicle Maintenance

Cloud-connected IoT OBD2 loggers enable continuous vehicle monitoring for predictive maintenance, helping to anticipate and prevent potential breakdowns and reduce downtime.

Discover Predictive Maintenance Solutions

Vehicle Black Box Recording

An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing critical data for incident analysis, warranty validation, and diagnostic forensics.

Explore CAN Bus Black Box Loggers

Do you have a specific OBD2 data logging application in mind? Contact us for a free consultation to discuss your needs!

For more in-depth introductions to related topics, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN