Are you looking for a clear and practical understanding of the Iso Obd2 Protocol? As a crucial standard in modern automotive diagnostics, On-Board Diagnostics II (OBD2) provides unparalleled access to your vehicle’s health and performance data. This guide offers an in-depth look at the OBD2 protocol, with a special focus on the ISO standards that underpin its functionality, ensuring you gain expertise in this essential automotive technology.
This article serves as your comprehensive introduction to the On-Board Diagnostic (OBD2) protocol, encompassing the OBD2 connector, OBD2 Parameter IDs (PIDs), and its integration with the CAN bus system. We’ll go beyond a basic overview to equip you with the knowledge to request and interpret OBD2 data effectively. Discover practical applications, key logging scenarios, and expert tips that elevate this guide to the premier resource for understanding OBD2.
For a quick visual overview, check out our introductory OBD2 video above, or download this guide in PDF format.
Article Contents:
Author: Martin Falch (Updated January 2025)
Download as PDF
Delving into the ISO OBD2 Protocol: What Is It?
At its core, OBD2 is your car’s integrated self-diagnostic system. It’s an internationally standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and live data through the OBD2 connector. The ISO OBD2 protocol ensures uniformity across vehicle manufacturers, making diagnostics and repairs more accessible and efficient.
You’ve likely already encountered OBD2 in action. The malfunction indicator light on your dashboard—often referred to as the “check engine light”—is a primary indicator of an issue detected by the OBD2 system.
When you take your car to a mechanic, they utilize an OBD2 scanner to pinpoint the problem. This process involves connecting the OBD2 reader to the OBD2 16-pin connector, typically located beneath the steering wheel. The scanner transmits ‘OBD2 requests’ to the vehicle’s computer, and the car responds with ‘OBD2 responses.’ These responses contain valuable data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), which significantly speed up the troubleshooting and repair process.
Understanding OBD2: The malfunction indicator light and a mechanic using a scan tool to diagnose a vehicle.
OBD2 Compatibility: Is Your Car Supported by the ISO Standard?
The answer is likely yes for most modern vehicles!
Nearly all contemporary non-electric cars are equipped with OBD2 support, and a majority of these operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 compliance. Some may not fully adhere to the ISO OBD2 protocol. To ascertain compatibility, consider the vehicle’s origin and purchase date:
OBD2 Compliance Guide: A chart indicating OBD2 adoption timelines in the EU and US.
A Look at OBD2 History and the ISO OBD2 Protocol Evolution
The genesis of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards for enhanced emission control.
The ISO OBD2 protocol, as we know it today, was significantly shaped by the Society of Automotive Engineers (SAE). They recommended standardized DTCs and the OBD connector, culminating in the SAE J1962 standard, which ISO later adopted and integrated into the ISO 15031 series. This standardization was crucial for ensuring that diagnostic tools could effectively communicate with any OBD2-compliant vehicle, regardless of the manufacturer.
The rollout of the ISO OBD2 protocol 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: OBD2 was also mandated in the EU for diesel cars under the European On-Board Diagnostics (EOBD) regulation, which is largely aligned with ISO OBD2 protocol standards.
- 2005: OBD2 compliance extended to medium-duty vehicles in the US.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the communication basis for OBD2, solidifying the ISO OBD2 protocol’s reliance on CAN.
- 2010: OBD2 mandates were completed in the US with requirements for heavy-duty vehicles.
OBD2 Historical Context: Emission control and the evolution of OBD2 standards.
OBD2 Timeline: A visual representation of the historical milestones in OBD2 development and implementation.
The Future of OBD: Envisioning OBD3, remote diagnostics, and cloud integration.
The Future Trajectory of ISO OBD2 Protocol
OBD2 is firmly established in automotive diagnostics, but its future is evolving.
Key trends shaping its future include:
Initially designed for emissions control and testing, legislated OBD2, particularly the ISO OBD2 protocol, faces challenges with electric vehicles. EVs, not having combustion engines, are not legally bound to support OBD2 in its traditional form. Consequently, most modern EVs do not support standard OBD2 requests. Instead, many utilize OEM-specific UDS communication protocols. This shift complicates data retrieval from EVs, often requiring reverse engineering to decode vehicle data. Our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, illustrate these complexities.
The ISO OBD2 protocol, while robust, has limitations in data richness and the variety of lower-layer protocols it supports. In response, advanced protocols like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to modernize OBD communication by basing it on the UDS protocol, enhancing efficiency and data capabilities. For a deeper understanding of these advancements, our introduction to UDS provides further insights.
In an era of connected vehicles, traditional OBD2 testing methods appear outdated. Manual emission checks are increasingly seen as inefficient and costly.
The proposed solution is OBD3 – integrating telematics into every vehicle.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for toll collection. This would enable cars to transmit their vehicle identification number (VIN) and DTCs wirelessly to a central server for automated diagnostics and monitoring.
Many current devices already facilitate data transfer from CAN or OBD2 via WiFi/cellular networks. Examples include the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While offering cost savings and convenience, OBD3 raises political and privacy concerns related to surveillance.
The ISO OBD2 protocol was initially conceived for stationary emission testing.
However, its utility has expanded significantly, with third-party applications leveraging OBD2 for real-time data generation through OBD2 dongles, CAN loggers, and similar devices. This widespread use has prompted reactions from the automotive industry. The German car industry, for instance, is considering restricting third-party access to OBD2 data.
Christoph Grote, SVP Electronics at BMW, stated in 2017: “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.”
The industry proposal involves deactivating OBD2 functionality during vehicle operation and centralizing data collection within manufacturer-controlled servers. This would give manufacturers control over the burgeoning field of ‘automotive big data’.
Arguments for this change cite security improvements, such as reducing the risk of car hacking. However, critics view it as a commercially motivated move to monopolize vehicle data, as discussed in Navixy’s blog on the future of OBD trackers. The outcome of these discussions will significantly impact the market for third-party OBD2 services.
EV Data Access: The potential removal of OBD2 connectors in electric vehicles and its implications.
Enhance Your Expertise with Our ‘Ultimate CAN Guide’
Aspiring to become a CAN bus expert?
Our comprehensive 160+ page PDF consolidates 12 ‘simple intros’ into one resource:
Download now
ISO OBD2 Protocol Standards: A Layered Approach
On-board diagnostics, OBD2, functions as a higher-layer protocol, akin to a language, while CAN serves as the communication medium, similar to a telephone line. This places OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
Specifically, the ISO OBD2 protocol standards define the OBD2 connector specifications, lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and more. These standards are meticulously documented to ensure interoperability and consistency across different vehicle systems and diagnostic tools.
These standards are often represented using the 7-layer OSI model, which helps visualize the different aspects of communication protocol stack. The following sections will focus on the most crucial standards within this model.
In the OSI model context, it’s important to note the dual influence of SAE and ISO standards. SAE standards are predominantly used in the US, while ISO standards are more common in Europe. Many of these standards are technically very similar, for example, SAE J1979 is nearly equivalent to ISO 15031-5, and SAE J1962 mirrors ISO 15031-3. These equivalences are key to the global applicability of the ISO OBD2 protocol.
OSI Model for OBD2 and CAN Bus: Illustrating the layered communication protocol stack with ISO and SAE standards.
OBD2 Connector Pinout: Diagram of a Type A OBD2 connector socket, detailing pin assignments.
The OBD2 Connector: SAE J1962 and ISO 15031-3 Standards
The 16-pin OBD2 connector is your physical gateway to accessing vehicle data, meticulously defined by the SAE J1962 / ISO 15031-3 standards. These standards ensure that every OBD2 compliant vehicle has a uniform connector, simplifying diagnostic processes worldwide.
The illustration above shows a standard Type A OBD2 pin connector, also known as the Data Link Connector (DLC).
Key features of the OBD2 connector include:
- It is typically located near the steering wheel but can sometimes be hidden from plain sight.
- Pin 16 provides battery power, often remaining active even when the ignition is off.
- The OBD2 pinout configuration varies based on the communication protocol used.
- CAN bus, the most prevalent lower-layer protocol, typically utilizes pins 6 (CAN-High) and 14 (CAN-Low).
OBD2 Connector Types: Type A vs. Type B
In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is standard in most cars, while Type B is more common in medium and heavy-duty vehicles.
As shown in the illustration, both types share similar OBD2 pinouts but differ primarily in power supply output: Type A provides 12V, whereas Type B is designed for 24V systems. Baud rates can also vary, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).
Visually distinguishing them is straightforward: the Type B OBD2 connector features an interrupted groove in the center. This design means a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, but a Type A adapter will not fit into a Type B socket.
Connector Types: Differentiating between OBD2 Type A and Type B connectors based on SAE J1962 standards.
OBD2 and CAN Bus: Illustrating the relationship and standards like ISO 15765 that govern their interaction.
Integrating OBD2 with CAN Bus: ISO 15765-4 Standards
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765. This ISO OBD2 protocol standard ensures reliable and high-speed communication for diagnostic data.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints and guidelines for using CAN (ISO 11898) in diagnostic applications.
This standard focuses on standardizing the CAN interface for diagnostic equipment at the physical, data link, and network layers:
- CAN bus bit-rates are specified at either 250K or 500K.
- CAN IDs can be either 11-bit or 29-bit.
- Specific CAN IDs are reserved for OBD requests and responses to maintain protocol clarity.
- Diagnostic CAN frame data length is fixed at 8 bytes for efficiency and consistency.
- The OBD2 adapter cable length is limited to a maximum of 5 meters to ensure signal integrity.
OBD2 CAN Identifiers: 11-bit and 29-bit
OBD2 communication over CAN bus is structured around request and response messages.
In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is commonly used to query all OBD2-compatible ECUs for data related to a requested parameter, as detailed in ISO 15765-4. Conversely, CAN IDs ranging from 0x7E0 to 0x7E7 are available for ‘Physical Addressing’ requests, allowing direct communication with specific ECUs, though this is less frequently used.
ECUs respond using 11-bit IDs in the range of 0x7E8 to 0x7EF. The most common response ID is 0x7E8, typically from the Engine Control Module (ECM), with 0x7E9 from the Transmission Control Module (TCM) also being relatively common.
In some vehicle types, particularly vans and medium to heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.
For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses in this format are sent with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF, typically 18DAF110 and 18DAF11E. The response ID is sometimes also represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard designates as ‘Reserved for ISO 15765-2’.
OBD2 Request-Response Frames: Illustrating the structure of OBD2 communication frames with PID data.
OBD2 vs. Proprietary CAN: Contrasting standardized OBD2 data with OEM-specific CAN bus protocols.
OBD2 vs. Proprietary CAN Protocols: Understanding the Difference
It is important to recognize that your vehicle’s Electronic Control Units (ECUs) operate independently of OBD2 for their primary functions. Original Equipment Manufacturers (OEMs) implement their proprietary CAN protocols for core vehicle operations. These OEM-specific CAN protocols are often unique to the vehicle’s brand, model, and year. Accessing and interpreting this proprietary data is typically restricted unless you have OEM-level diagnostic tools or are capable of reverse engineering it.
When you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at high frequencies (1000-2000 frames per second). However, many newer vehicles incorporate a ‘gateway’ system that restricts access to this CAN data, allowing only OBD2 communication through the OBD2 port.
In essence, think of OBD2 as a supplementary, higher-layer protocol functioning in parallel with the OEM-specific protocol. It’s designed primarily for diagnostics and emissions monitoring, rather than accessing the full spectrum of vehicle operational data.
Bit-rate and ID Validation According to ISO 15765-4
As previously mentioned, OBD2 over CAN can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential protocol combinations. Modern vehicles commonly use 500K with 11-bit IDs. Diagnostic tools should systematically validate these settings to ensure proper communication.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct protocol combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a mandatory OBD2 request (further detailed in the OBD2 PID section). Incorrect bit-rate transmissions will result in CAN error frames, signaling a mismatch.
More recent versions of ISO 15765-4 account for 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.
Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-electric vehicles, while WWH-OBD is mainly found in EU trucks and buses.
Bit-rate and ID Validation Flowchart: A systematic approach to validating OBD2 communication parameters according to ISO 15765-4.
Five OBD2 Protocols: Illustrating the five main lower-layer protocols used in OBD2, including CAN and older standards.
Five Lower-Layer OBD2 Protocols: Beyond CAN
While CAN is now the dominant lower-layer protocol for OBD2 under ISO 15765, particularly in vehicles post-2008, older vehicles may utilize one of four other protocols. Understanding these legacy protocols and their pinouts can be helpful when working with older automotive systems.
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used in most modern cars.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
- SAE J1850 (VPW): Predominantly used in older General Motors vehicles.
- SAE J1850 (PWM): Primarily found in older Ford vehicles.
ISO 15765-2: Transporting OBD2 Messages via ISO-TP
All OBD2 data communication over CAN bus relies on the ISO Transport Protocol (ISO-TP), defined by ISO 15765-2. This protocol is essential for transmitting data payloads larger than the 8-byte limit of a standard CAN frame. ISO-TP is crucial in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often exceed this limit. It manages data segmentation, flow control, and reassembly to ensure reliable transmission of larger datasets. For a more detailed explanation, refer to our introduction to UDS.
However, much of the OBD2 data exchanged fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In an SF, the first data byte (the PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-specific communication.
ISO-TP Frame Types: Diagram illustrating the different frame types defined by ISO 15765-2 for OBD2 communication.
SAE J1979 and ISO 15031-5: The OBD2 Diagnostic Message Structure
To fully understand OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message comprises an identifier, a data length indicator (PCI field), and the data payload itself. The payload is further structured into a Mode byte, a Parameter ID (PID), and the actual data bytes. These components are defined by the ISO OBD2 protocol standards to ensure uniform data interpretation across different tools and systems.
OBD2 Message Structure: Breakdown of an OBD2 message frame, showing the arrangement of Mode, PID, and data bytes.
Example: OBD2 Request and Response Cycle
Before dissecting each part of the OBD2 message, consider this practical example of a request and response for ‘Vehicle Speed’.
In this scenario, an external diagnostic tool sends a request message to the vehicle. This message uses CAN ID 0x7DF and contains 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle’s ECU responds using CAN ID 0x7E8 and 3 payload bytes. These include the value for Vehicle Speed in the 4th byte, which is 0x32 (decimal 50).
By consulting the OBD2 PID specifications for 0x0D, we can determine that this value corresponds to a physical value of 50 km/h.
Next, we will explore the OBD2 modes and PIDs in detail.
OBD2 Request-Response Example: A sequence showing a request for Vehicle Speed (PID 0x0D) and the corresponding response.
Vehicle Speed PID 0x0D: Detailed look at the Vehicle Speed PID, illustrating its data representation and decoding.
OBD2 Service Modes: Overview of the 10 standardized OBD2 service modes, including real-time data and DTC management.
The 10 OBD2 Services (Modes): Accessing Diagnostic Functions
The ISO OBD2 protocol defines 10 diagnostic services, also referred to as modes, each designed for specific diagnostic functions. Mode 0x01 is used to retrieve current, real-time data parameters, while other modes are dedicated to displaying and clearing diagnostic trouble codes (DTCs), accessing freeze frame data, and more.
Vehicles are not required to support all 10 OBD2 modes, and manufacturers may also implement additional, OEM-specific modes beyond these standardized ones.
In OBD2 messages, the mode is indicated in the second byte of the data payload. In a request message, the mode is specified directly (e.g., 0x01). In the response, 0x40 is added to the requested mode value (e.g., a response to mode 0x01 would start with 0x41).
OBD2 Parameter IDs (PIDs): Identifying Specific Data Points
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify particular data points or diagnostic information.
For example, Mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on various vehicle parameters such as speed, RPM, and fuel level. However, vehicles are not obligated to support every PID within a given mode. In practice, most vehicles support only a subset of the available PIDs.
One PID, in particular, holds a special status.
Specifically, if an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds by indicating which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 a fundamental tool for ‘OBD2 compatibility testing’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of Mode 0x01 PIDs (0x21-0x40, 0x41-0x60, and so on).
PID Request-Response: Diagram showing the structure of PID requests and responses in OBD2 communication.
OBD2 PID Tool: Screenshot of an OBD2 PID overview tool, highlighting Service 01 PID functionalities.
Tip: Utilizing an OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 contain essential scaling information for standard OBD2 PIDs. This data is crucial for converting raw PID values into meaningful physical units, as detailed in our CAN bus introduction.
For quick and easy lookup of Mode 0x01 PIDs, our OBD2 PID overview tool is an invaluable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, streamlining the diagnostic process.
OBD2 PID overview tool
Practical Guide: How to Log and Decode ISO OBD2 Protocol Data
This section provides a hands-on example of logging OBD2 data using the CANedge CAN bus data logger.
The CANedge is designed to allow configuration of custom CAN frames for transmission, making it ideally suited for OBD2 data logging.
Once configured, the CANedge can be easily connected to your vehicle via our OBD2-DB9 adapter cable, providing a seamless interface for data capture.
OBD2 Data Logging Setup: Illustrating the CANedge data logger connected for OBD2 PID data request.
Bit-rate Validation: Example of sending a CAN frame at 500K to validate bit-rate settings.
Supported PIDs Responses: Reviewing responses to ‘Supported PIDs’ requests in asammdf software.
Step #1: Bit-rate, ID, and Supported PIDs Validation
As outlined by ISO 15765-4, determining the correct bit-rate and CAN IDs is crucial. The CANedge facilitates this process as follows (see the CANedge Intro for detailed instructions):
- Test Bit-rate: Send a CAN frame at 500K and verify successful transmission. If unsuccessful, try 250K.
- Bit-rate Configuration: Use the validated bit-rate for all subsequent communication.
- Supported PIDs Inquiry: Transmit multiple ‘Supported PIDs’ requests and analyze the responses.
- ID Type Determination: Based on response IDs, determine whether 11-bit or 29-bit IDs are in use.
- PID Support Assessment: Analyze response data to identify which PIDs are supported by the vehicle.
We provide pre-configured settings to streamline these initial tests.
Most non-EV vehicles manufactured from 2008 onwards support between 40 to 80 PIDs, typically using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which queries all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are frequently observed. Subsequent ‘Supported PIDs’ requests usually elicit fewer responses as not all ECUs support every PID. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in the system. Optimizing communication by directing requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0 can reduce bus load.
Step #2: Configuring OBD2 PID Requests for Logging
Once you have identified the supported OBD2 PIDs and the correct communication parameters for your vehicle, configure your transmit list to request the PIDs of interest.
Consider these factors for optimal logging:
- CAN ID Addressing: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses.
- Request Spacing: Implement a delay of 300-500 ms between each OBD2 request to prevent ECU overload and ensure reliable responses.
- Power Management: Utilize triggers to halt transmissions when the vehicle is inactive, preventing unnecessary battery drain by ‘waking up’ ECUs.
- Data Filtering: Apply filters to record only OBD2 responses, especially if OEM-specific CAN data is also present on the bus, to manage data volume effectively.
With these configurations in place, your CANedge is ready to efficiently log raw OBD2 data.
CANedge Transmit List: Example configuration of a CANedge transmit list for OBD2 PID requests.
Decoded OBD2 Data in asammdf: Visual representation of DBC decoded OBD2 data in asammdf software.
Step #3: DBC Decoding of Raw OBD2 Data for Analysis
To effectively analyze and visualize logged OBD2 data, decoding the raw data into ‘physical values’ (e.g., km/h, °C) is essential.
The necessary decoding specifications are found in ISO 15031-5/SAE J1979 and are also available on platforms like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus analysis tools.
Decoding OBD2 data is more intricate than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to determine the encoded signals within the payload.
To accurately decode OBD2 data, it’s necessary to consider the CAN ID, the OBD2 mode, and the specific OBD2 PID. This method of signal identification is known as ‘extended multiplexing‘, which can be effectively managed using DBC files.
CANedge: Your OBD2 Data Logging Solution
The CANedge provides an easy-to-use solution for recording OBD2 data directly to an SD card (8-32 GB). Simply connect it to your vehicle to begin logging and utilize free software and APIs, along with our OBD2 DBC file, for data analysis.
OBD2 logger intro CANedge
ISO-TP in Action: OBD2 Multi-Frame Examples
All OBD2 communication leverages ISO-TP (Transport Protocol) as per ISO 15765-2. While many examples are single-frame based, multi-frame communication is crucial for transmitting larger datasets. This section presents examples of multi-frame OBD2 communication, highlighting the role of ISO-TP.
Multi-frame OBD2 exchanges require flow control frames, as detailed in our UDS introduction. In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request, as illustrated in the CANedge configuration examples.
Analyzing multi-frame OBD2 responses necessitates CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.
Example 1: Retrieving the OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is essential for telematics, diagnostics, and vehicle management, as discussed in our UDS introduction. To retrieve the VIN using OBD2 requests, you would use mode 0x09 and PID 0x02:
The diagnostic tool initiates the process with a Single Frame request, specifying the PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame, which includes the PCI, total message length (0x014 = 20 bytes), mode (0x49, derived from 0x09 + 0x40), and PID (0x02). Following the PID, the byte 0x01 represents the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for detailed specifications). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.
Example 2: Multi-PID Request (6x) in OBD2
OBD2 allows diagnostic tools to request up to six Mode 0x01 PIDs in a single request frame. The ECU is expected to respond with data for all supported PIDs from the request (omitting unsupported ones in the response), possibly using multi-frame responses via ISO-TP if the data exceeds a single frame.
This capability enhances data collection efficiency and frequency. However, it also complicates signal encoding, making generic OBD2 DBC files less effective for these scenarios. Practical use of this method is generally not recommended unless highly specialized tools are in use. Below is an example of a multi-PID request trace:
The multi-frame response structure is similar to the VIN example but includes the requested PIDs alongside their corresponding data. The PIDs in the response are typically ordered as requested, though this is not strictly mandated by ISO 15031-5.
Decoding these complex responses using standard DBC files is challenging, and therefore, this approach is not advised for general data logging unless you are working with tools specifically designed to handle multi-PID requests. This scenario represents a form of extended multiplexing, compounded by multiple instances within a single payload. A DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across different vehicles with varying PID support. Furthermore, managing multiple such multi-PID requests via DBC manipulations becomes exceedingly complex, lacking a method to uniquely identify messages from each other.
Workarounds might involve custom scripts that interpret response messages in conjunction with request messages, but these solutions are difficult to scale and manage.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is required in the request. Responding ECUs will report the number of DTCs stored (possibly zero if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary if more than two DTCs are stored.
Each 2-byte DTC value is structured into two parts, according to ISO 15031-5 and ISO 15031-6. The first 2 bits define the DTC ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code, as illustrated below. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.
The example below shows a response from an ECU reporting 6 stored DTCs.
DTC Decoding Example: Illustrating the structure and interpretation of OBD2 Diagnostic Trouble Codes.
Real-World Applications: OBD2 Data Logging Use Cases
OBD2 data logging from cars and light trucks is valuable in numerous applications:
Vehicle Data Logging
OBD2 data is used for diverse purposes such as reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.
obd2 logger
Real-time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of vehicle data for immediate diagnostics of vehicle issues and performance monitoring.
obd2 streaming
Predictive Maintenance
IoT-connected OBD2 loggers facilitate cloud-based vehicle monitoring for predictive maintenance, helping to anticipate and prevent breakdowns.
predictive maintenance
Vehicle Black Box Recording
An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for incident analysis, warranty claims, and diagnostic forensics.
can bus blackbox
Do you have an OBD2 data logging application in mind? Contact us for expert consultation!
Contact us
Explore our guides section for more introductory articles, or download our comprehensive ‘Ultimate Guide’ PDF.
Ready to start logging or streaming OBD2 data?
Acquire your OBD2 data logger today!
Buy now Contact us
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
[
