Understanding the OBDII Standard: A Comprehensive Guide for Automotive Diagnostics

Need a clear and practical understanding of the Obdii Standard?

This guide provides an in-depth introduction to the On-Board Diagnostics II (OBDII) standard, covering everything from the OBDII connector and Parameter IDs (PIDs) to its connection with the Controller Area Network (CAN) bus.

This is a comprehensive guide designed for both beginners and experienced professionals, offering practical knowledge on requesting and interpreting OBDII data, exploring key applications, and providing valuable tips for effective utilization.

Discover why this is becoming the definitive resource for mastering the OBDII standard.

You can also watch our introductory video on OBDII above – or download this guide in PDF format.

What is the OBDII Standard?

The OBDII standard represents a vehicle’s integrated self-diagnostic system. It is a globally recognized and standardized protocol enabling access to crucial diagnostic trouble codes (DTCs) and real-time vehicle data through the OBDII connector.

You’ve likely already encountered the OBDII standard in action:

Have you ever noticed the malfunction indicator light, often referred to as the “check engine light,” illuminating on your dashboard?

This light is your vehicle signaling a potential issue. When you take your car to a mechanic, they utilize an OBDII scanner to accurately diagnose the problem.

This process involves connecting the OBDII reader to the OBDII 16-pin connector, typically located near the steering wheel. The diagnostic tool then transmits ‘OBDII requests’ to the vehicle’s computer, and the car responds with ‘OBDII responses’. These responses can contain a wealth of information, including parameters like speed, fuel level, and Diagnostic Trouble Codes (DTCs), significantly streamlining the troubleshooting and repair process.

Understanding the OBDII Standard: The Malfunction Indicator Light (MIL) is a key component, signaling when an OBDII scanner should be used for diagnostics.

OBDII Standard Compliance: Does Your Car Support It?

In short: Very likely!

The vast majority of modern, non-electric vehicles are OBDII standard compliant, and most of these operate on the CAN bus protocol. For older vehicles, it’s important to note that even if a 16-pin OBDII connector is present, it might not fully support the OBDII standard. A reliable way to determine OBDII compliance is to consider the vehicle’s original point of sale and manufacturing date:

OBDII Standard Compliance Guide: Check your vehicle’s manufacturing location and date to determine if it adheres to the OBDII standard.

A Brief History of the OBDII Standard

The OBDII standard has its roots in California, where the California Air Resources Board (CARB) mandated the inclusion of On-Board Diagnostics (OBD) in all new vehicles starting from 1991 to monitor and control emissions.

The Society of Automotive Engineers (SAE International) played a crucial role in recommending the OBDII standard. This led to the standardization of DTCs and the OBD connector across different vehicle manufacturers through the SAE J1962 specification.

From its Californian origin, the OBDII standard progressively expanded its reach:

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

OBDII Standard Evolution: Tracing the history of the OBDII standard and its impact on emission control and vehicle diagnostics.

Timeline of the OBDII Standard: A visual representation of the key milestones in the development and implementation of the OBDII standard.

The Future of OBDII Standard: Exploring the potential evolution towards OBDIII and remote diagnostics in connected vehicles.

The Future Trajectory of the OBDII Standard

The OBDII standard is firmly established in automotive diagnostics, but its future form is subject to change.

Here are some significant trends shaping the OBDII standard’s evolution:

Initially, legislated OBDII was primarily designed for emission control and testing. Consequently, electric vehicles (EVs) are not obligated to support the OBDII standard in any form. This is evident in the fact that most modern EVs do not support standard OBDII requests. Instead, many utilize OEM-specific Unified Diagnostic Services (UDS) communication protocols. This often makes standard OBDII data extraction from EVs challenging, except in cases where decoding methods have been reverse-engineered. Examples include case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

The OBDII standard today is implemented in diverse ways and faces limitations in data richness and lower-layer protocols. To address these, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to enhance OBD communication by using the UDS protocol as a foundation. More information on these protocols can be found in our introduction to UDS.

In today’s increasingly connected automotive landscape, traditional OBDII testing methods can seem inefficient. Manual emission control checks are time-consuming and costly.

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

OBDIII essentially envisions adding a small radio transponder to all cars, similar to those used in bridge toll systems. This would enable vehicles to transmit their Vehicle Identification Number (VIN) and DTCs wirelessly via WiFi to a central server for automated diagnostics and monitoring.

Many devices currently facilitate the transfer of CAN or OBDII data via WiFi/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While offering convenience and potential cost savings, OBDIII also presents political challenges related to data privacy and surveillance concerns.

The OBDII protocol was originally intended for stationary emission controls.

However, today, OBDII is widely utilized by third parties for real-time data generation through OBDII dongles, CAN loggers and similar devices. However, the German automotive industry is seeking to change this landscape:

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

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal is to deactivate OBDII functionality during normal driving, centralizing data collection in manufacturer-controlled servers. This would effectively place automotive manufacturers in control of the ‘automotive big data’.

The rationale is often based on security concerns, such as mitigating the risk of vehicle hacking). However, many perceive this as a commercially motivated move. Whether this becomes a widespread trend remains to be seen, but it could significantly disrupt the market for third-party OBDII services.

OBDII Standard Challenges: Electric vehicles and industry proposals may limit third-party access to OBDII data in the future.

Enhance Your CAN Bus Expertise with Our ‘Ultimate CAN Guide’

Aspiring to become a CAN bus expert?

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

Download now

Understanding OBDII Standards and Protocols

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

The OBDII standards meticulously define specifications for the OBDII connector, lower-layer protocols, OBDII Parameter IDs (PIDs), and more.

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

In the OSI model framework, it’s notable that both SAE and ISO standards cover multiple layers. This reflects the standardization of OBDII in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

OBDII and CAN Bus in the OSI Model: Illustrating how OBDII and CAN bus standards align within the 7-layer OSI model for automotive communication.

OBDII Connector Pinout: Diagram of a Type A OBDII connector socket, detailing pin assignments as per the OBDII standard.

The OBDII Connector: SAE J1962 Standard

The 16-pin OBDII connector provides straightforward access to vehicle data and is rigorously defined by the SAE J1962 / ISO 15031-3 standard.

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

Key features of the OBDII connector include:

Typically located near the steering wheel, but may be concealed.
Pin 16 provides battery power, often remaining active even when the ignition is off.
The OBDII pinout configuration is protocol-dependent.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-High) and 14 (CAN-Low) are commonly connected.

OBDII Connector Types: A vs. B

In practice, you may encounter both Type A and Type B OBDII connectors. Type A is generally found in passenger cars, while Type B is more common in medium and heavy-duty vehicles.

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

Type B OBDII connectors are distinguished by an interrupted groove in the middle, which helps in physical identification. Consequently, a Type B OBDII adapter cable is compatible with both Type A and Type B sockets, whereas a Type A connector will not fit into a Type B socket.

OBDII Connector Types A and B: A comparative illustration of Type A and Type B OBDII connectors as defined by SAE J1962, highlighting differences in power supply and application.

OBDII and CAN Bus Integration: Visual representation of the relationship between OBDII standards and the CAN bus protocol as per ISO 15765.

OBDII Standard and CAN Bus: ISO 15765-4

Since 2008, the CAN bus has been mandated as the lower-layer protocol for OBDII in all vehicles sold in the US, according to 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:

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

OBDII CAN Identifiers: 11-bit and 29-bit

All OBDII communication utilizes request/response message exchanges.

In most passenger vehicles, 11-bit CAN IDs are employed for OBDII communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBDII-compatible Electronic Control Units (ECUs) about the availability of data for a requested parameter (refer to ISO 15765-4). Conversely, CAN IDs in the range of 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, although this is less frequently used.

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

In some vehicle types, particularly vans and medium to heavy-duty vehicles, OBDII communication may utilize extended 29-bit CAN identifiers instead of 11-bit identifiers.

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

When the vehicle responds, you will observe responses with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

OBDII Request and Response Frames: Illustrating the structure of OBDII communication frames for requests and responses, including PID data parameters.

OBDII vs. Proprietary CAN Bus Protocols: Comparing OBDII standard CAN protocols with OEM-specific proprietary CAN bus data communication within vehicles.

OBDII Standard vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate independently of the OBDII standard. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for core vehicle functions. These CAN protocols are often unique to the vehicle brand, model, and production 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 vehicle’s OBDII connector may reveal OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a gateway module restricts access to this CAN data, only enabling OBDII communication through the OBDII connector.

In essence, OBDII can be considered as an ‘additional’ higher-layer protocol functioning in parallel with the OEM-specific protocol.

Bit-rate and ID Validation in the OBDII Standard

As discussed, the OBDII standard allows for two bit-rates (250 kbps, 500 kbps) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential protocol combinations. Modern vehicles commonly use 500 kbps and 11-bit IDs, but external diagnostic tools should systematically verify these parameters.

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

Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBDII/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, diagnostic tools can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and Data Identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

In practice, OBDonEDS (also referred to as OBDII, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-electric vehicles today, while WWH-OBD is primarily used in EU trucks and buses.

OBDII Bit-rate and CAN ID Validation Flowchart: A visual guide to the process of validating bit-rate and CAN ID combinations according to the ISO 15765-4 standard.

Five Lower-Layer OBDII Protocols: Illustrating the five primary lower-layer protocols used in OBDII communication, including CAN (ISO 15765), KWP2000, and SAE J1850 variants.

Five Lower-Layer OBDII Protocols

While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBDII in most vehicles, especially post-2008 models, it’s important to be aware of the other four protocols used in older vehicles. The pinout configurations can also help determine which protocol is in use in older cars.

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

ISO-TP: Transporting OBDII Messages – ISO 15765-2

All OBDII data transmitted over the CAN bus utilizes a transport protocol known as ISO-TP (ISO 15765-2). This protocol facilitates the communication of data payloads exceeding the 8-byte limit of standard CAN frames. ISO-TP is essential in OBDII for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). It manages segmentation, flow control, and reassembly of larger messages. For a detailed explanation, refer to our introduction to UDS.

However, much of OBDII data communication 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 available for OBDII-related communication.

ISO-TP and OBDII Frame Types: A breakdown of ISO 15765-2 frame types used in OBDII communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

Decoding the OBDII Diagnostic Message: SAE J1979, ISO 15031-5

To better understand OBDII communication over CAN, let’s examine a raw ‘Single Frame’ OBDII CAN message. In simplified terms, an OBDII message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload is further structured into a Mode byte, a Parameter ID (PID), and data bytes.

OBDII Message Structure Breakdown: A detailed explanation of the structure of an OBDII message, showing the arrangement of Mode, PID, and data bytes within a CAN frame.

Example of OBDII Request/Response

Before we delve into each component of the OBDII message, consider this example of a request and response for the ‘Vehicle Speed’ parameter.

In this scenario, an external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF, containing 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with 3 payload bytes. The vehicle speed value is encoded in the 4th byte, 0x32 (which is 50 in decimal).

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

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

OBDII Request and Response Example: Illustrating a typical OBDII request (CAN ID 0x7DF) and response (CAN ID 0x7E8) for vehicle speed.

OBDII PID Example: Vehicle Speed (PID 0x0D) – Detailing the structure and data bytes for the vehicle speed PID in an OBDII message.

OBDII Service Modes: An overview of the 10 standardized OBDII service modes, including modes for current data, freeze frame data, and DTC management.

The 10 OBDII Services (Modes)

The OBDII standard defines 10 diagnostic services, also known as modes. Mode 0x01 is used to retrieve current real-time data, while other modes are used to display or clear Diagnostic Trouble Codes (DTCs) and access freeze frame data.

Vehicles are not required to support all 10 OBDII modes and may also implement OEM-specific modes beyond the standardized set.

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

OBDII Parameter IDs (PIDs)

Each OBDII mode contains a set of Parameter IDs (PIDs).

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

One PID holds special significance in the OBDII standard.

Specifically, if an emissions-related ECU supports any OBDII services, it must support Mode 0x01 PID 0x00. In response to this PID request, the vehicle’s ECU reports whether it supports PIDs 0x01-0x20. This makes PID 0x00 a fundamental tool for verifying OBDII compatibility. Furthermore, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining PIDs within Mode 0x01.

OBDII Request and Response Frames for PIDs: Again illustrating OBDII request and response frames, this time emphasizing the role of Parameter IDs (PIDs) in data retrieval.

OBDII PID Overview Tool: Screenshot of an OBDII PID overview tool, designed to help users navigate and understand OBDII Parameter IDs within service mode 01.

Tip: OBDII PID Overview Tool

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

For quick lookup of Mode 0x01 PIDs, our OBDII PID overview tool is an invaluable resource. It aids in constructing OBDII request frames and dynamically decoding OBDII responses.

OBDII PID overview tool

Practical Guide: How to Log and Decode OBDII Data

This section offers a practical example of logging OBDII data using the CANedge CAN bus data logger.

The CANedge allows users to configure custom CAN frames for transmission, making it suitable for OBDII data logging.

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

OBDII PID Data Logger Setup: Diagram showing the setup for OBDII data logging, with a data logger sending requests and receiving responses via OBDII PIDs.

Validating Bit-rate for OBDII: An example of testing and validating the correct bit-rate for OBDII communication.

Supported PIDs Validation with asammdf: Using asammdf software to review and validate responses to ‘Supported PIDs’ requests, ensuring proper OBDII communication.

Step #1: Validate Bit-rate, IDs & Supported PIDs

As previously mentioned, ISO 15765-4 details how to determine the correct bit-rate and IDs for a specific vehicle. You can use the CANedge for this validation process, as outlined below (refer to the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500 kbps and check for successful transmission. If unsuccessful, try 250 kbps.
Use the successfully identified bit-rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine whether 11-bit or 29-bit IDs are in use based on response IDs.
Identify the supported PIDs from the response data.

We provide ready-to-use configurations to simplify these initial tests.

Most non-electric vehicles manufactured post-2008 support between 40 to 80 PIDs, utilizing a 500 kbps bit-rate, 11-bit CAN IDs, and the OBDII/OBDonEDS protocol.

As illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This is because the 0x7DF request ID is used, which polls all ECUs for a response. Since all OBDII/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are often received for this PID. As you proceed with subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Note also that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to this ECU using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBDII PID Requests

Once you’ve identified the supported OBDII PIDs for your vehicle, along with the appropriate bit-rate and CAN IDs, you can proceed to configure your transmit list with the PIDs of interest.

Consider these points when setting up your configuration:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Introduce a delay of 300-500 ms between each OBDII request to prevent overwhelming the ECUs, which may lead to non-responsiveness.
Battery Drain: Implement triggers to halt transmission when the vehicle is inactive to prevent unnecessary ECU wake-ups and battery drain.
Filters: Set up filters to record only OBDII responses if your vehicle also broadcasts OEM-specific CAN data, reducing data clutter.

With these configurations in place, your device is ready to log raw OBDII data effectively.

Example OBDII PID Request List for CANedge: A sample configuration showing a list of OBDII PID requests set up for a CANedge data logger.

Decoded OBDII Data Plot in asammdf: Visual representation of decoded OBDII data in asammdf software, utilizing a CAN bus DBC file for signal interpretation.

Step #3: DBC Decode Raw OBDII Data

Finally, to analyze and visualize your logged OBDII data, you need to decode the raw data into physical values, such as km/h or °C.

The necessary decoding information is available in ISO 15031-5/SAE J1979 and also on platforms like Wikipedia. For convenience, we offer a free OBDII DBC file that simplifies DBC decoding of raw OBDII data in most CAN bus software tools.

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

To address this, it’s essential to use the CAN ID, OBDII mode, and OBDII PID together to accurately identify the signal. This method of multiplexing is termed ‘extended multiplexing‘, which can be implemented in formats like DBC files.

CANedge: Your OBDII Data Logging Solution

The CANedge provides an easy solution for recording OBDII data directly to an SD card (8-32 GB). Simply connect it to your vehicle to start logging and utilize free software/APIs and our OBDII DBC file for data decoding.

OBDII logger intro CANedge

OBDII Multi-Frame Examples: ISO-TP in Action

All OBDII data communication is managed using the ISO-TP (transport protocol) as per ISO 15765-2. While many examples discussed so far involve single-frame communication, this section will explore multi-frame communication scenarios.

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

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

OBDII Multi-Frame Request Example: Requesting Vehicle Identification Number (VIN) using a multi-frame OBDII message.

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

The Vehicle Identification Number (VIN) is frequently essential for telematics, diagnostics, and more (detailed in our UDS introduction). To retrieve the VIN from a vehicle using OBDII requests, you use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this instance (refer to ISO 15031-5 / SAE J1979 for further details). The subsequent 17 bytes constitute the VIN and can be converted from HEX to ASCII using methods described in our UDS introduction.

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

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

This feature allows for efficient collection of OBDII data at higher frequencies. However, it also means that signal encoding is request-specific, making the use of generic OBDII DBC files challenging for such applications. We generally advise against this method for most practical uses. Below is an example trace of such a communication sequence:

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

Decoding such responses using generic DBC files is practically very difficult. Therefore, we do not recommend this approach for routine data logging unless you are using a tool specifically designed to support it. This scenario effectively represents an instance of extended multiplexing, but with multiple instances within a single payload. Furthermore, your DBC file would need to account for the specific payload position of each PID, which complicates generalization across vehicles with varying supported PIDs. Handling this becomes even more complex if you are sending multiple multi-PID requests, as uniquely identifying messages from each other becomes challenging.

Workarounds might include custom scripts and recording transmit messages from your diagnostic tool. The script could then interpret response messages in conjunction with the corresponding request messages. However, such approaches are generally difficult to scale.

Example 3: OBDII Diagnostic Trouble Codes (DTCs)

OBDII can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using Mode 0x03, i.e., ‘Show stored Diagnostic Trouble Codes’. No PID is included in this request. The targeted ECU(s) will respond with the number of DTCs stored (which may be 0 if no DTCs are present), with each DTC occupying 2 data bytes. Consequently, multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is typically structured into two parts, as per ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits form a 4-digit code (displayed in hexadecimal), as shown in the visual. Decoded DTC values can be looked up using various OBDII DTC lookup tools, such as repairpal.com.

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

OBDII DTC Decoding Example: Illustrating the structure and decoding process for OBDII Diagnostic Trouble Codes (DTCs), including category and code interpretation.

OBDII Data Logging: Use Case Examples

OBDII data from cars and light trucks has diverse applications across various sectors:

Data Logging for Cars

OBDII data logging in cars can be instrumental in reducing fuel consumption, enhancing driving habits, testing prototype components, and optimizing insurance models.

OBDII logger

Real-Time Vehicle Diagnostics

OBDII interfaces enable real-time streaming of vehicle data in a human-readable format, crucial for diagnosing vehicle issues promptly and efficiently.

OBDII streaming

Predictive Maintenance Applications

Monitoring cars and light trucks via IoT-enabled OBDII loggers in the cloud facilitates predictive maintenance, helping to anticipate and prevent potential breakdowns.

Predictive maintenance

Vehicle Black Box Recording

An OBDII logger can function as a ‘black box’ for vehicles or equipment, providing essential data for dispute resolution, accident analysis, and detailed diagnostics.

CAN bus black box

Do you have an OBDII data logging use case you’d like to discuss? Contact us for a free consultation!

For more educational content, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.

Need to log or stream OBDII data?

Acquire your OBDII data logger today!

Buy now Contact us

Recommended Resources

OBDII DATA LOGGER: EASILY LOG & CONVERT OBDII DATA

CANEDGE2 – PRO CAN IoT LOGGER

[