Want to understand how your car communicates diagnostic information? The On-Board Diagnostics (OBD2) system is the key. This guide provides a comprehensive introduction to the Obd2 Communication Protocol, covering everything from the connector and parameter IDs (PIDs) to its relationship with the CAN bus and practical applications.
Whether you’re a seasoned mechanic or a car enthusiast, this in-depth exploration will empower you to understand and utilize OBD2 for vehicle diagnostics, data logging, and more. Let’s dive into why this has become a leading resource for understanding OBD2 technology.
You can also watch our OBD2 intro video above – or get the PDF
What is OBD2?
OBD2 is essentially your car’s internal health monitoring system. It’s a standardized communication protocol that allows you to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector.
You’ve likely encountered OBD2 in action without even realizing it. Ever seen the check engine light illuminate on your dashboard? That’s your car using the OBD2 system to alert you to a potential issue.
When you take your car to a mechanic for a diagnosis, they use an OBD2 scanner. This tool connects to the 16-pin OBD2 connector, typically located near the steering wheel. The scanner sends ‘OBD2 requests’ to your car, and the car responds with ‘OBD2 responses’. These responses can contain valuable information such as speed, fuel level, and, most importantly, Diagnostic Trouble Codes (DTCs). This streamlined communication process significantly speeds up troubleshooting and repair.
Understanding OBD2: The malfunction indicator light and a scan tool being connected to the OBD2 port for diagnostics.
Does My Car Support OBD2?
The short answer is: Almost certainly!
The vast majority of modern non-electric vehicles are equipped with OBD2 systems, and most of these systems operate on the CAN bus network. However, with older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some older cars may have the connector but not fully implement the OBD2 protocol.
A key factor in determining OBD2 compliance is the vehicle’s year of manufacture and where it was originally sold. Refer to the guidelines below to ascertain if your car is OBD2 compliant:
OBD2 Compliance Guide: A visual guide showing OBD2 adoption timelines for vehicles sold in the EU and US.
OBD2 History
The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting from 1991 to monitor and control emissions.
The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, recommending the protocol and standardizing DTCs and the OBD connector across different vehicle manufacturers through the SAE J1962 standard.
From its Californian inception, the OBD2 standard progressively rolled out across the globe:
- 1996: OBD2 became compulsory in the USA for cars and light trucks.
- 2001: OBD2 became mandatory in the EU for gasoline cars.
- 2003: The EU extended the mandate to diesel cars (EOBD – European On-Board Diagnostics).
- 2005: OBD2 was required in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication protocol.
- 2010: OBD2 was finally mandated in US heavy-duty vehicles.
OBD2 Historical Context: An illustration linking OBD2 history to emission control and the evolution of vehicle diagnostics.
OBD2 Timeline: A visual timeline summarizing the key milestones in the history of On-Board Diagnostics.
The Future of OBD: Depicting OBD3 trends towards remote diagnostics, emissions testing, and cloud integration.
OBD2 Future
OBD2 is firmly established, but its evolution continues. Let’s explore some key trends shaping the future of OBD2:
Originally designed for emissions monitoring, legislated OBD2 faces new challenges with the rise of electric vehicles. Electric vehicles, due to their different powertrain, are not obligated to support OBD2 in its traditional form. In fact, most modern EVs largely bypass standard OBD2 requests, opting instead for OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift often makes accessing and interpreting data from EVs challenging, except in cases where reverse engineering efforts have yielded decoding methods. Examples of successful reverse engineering include studies on Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Recognizing the limitations of current OBD2 implementations in terms of data richness and lower-layer protocols, modern alternatives are emerging. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are designed to modernize and enhance OBD communication by building upon the UDS protocol. To delve deeper into these protocols, refer to our introduction to UDS.
In an increasingly connected world, manual OBD2 testing for emission control seems outdated. Performing manual emission checks is both time-consuming and costly.
The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions equipping all cars with a small radio transponder, similar to those used for electronic toll collection. This would enable vehicles to wirelessly transmit their vehicle identification number (VIN) and DTCs via WiFi to a central server for automated monitoring.
Many devices today already facilitate CAN or OBD2 data transfer via WiFi/cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While this offers convenience and cost savings, it also raises political and privacy concerns related to surveillance.
The original intent of the OBD2 protocol was for stationary emission control testing.
However, OBD2 is now widely used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and similar devices. This trend is facing pushback from the German car industry, as highlighted in a report:
OBD was designed for car servicing in repair shops, not to enable a third-party data-driven economy based on access through this interface.
– Christoph Grote, SVP Electronics, BMW (2017)
The industry proposal suggests disabling OBD2 functionality during driving, centralizing data collection within manufacturer servers. This move would give manufacturers control over the burgeoning field of ‘automotive big data’.
Arguments for this change often cite security concerns, such as mitigating the risk of car hacking. However, many observers view this as a commercially motivated strategy to control valuable vehicle data, as discussed in this analysis. Whether this shift becomes widespread remains to be seen, but it has the potential to significantly disrupt the market for third-party OBD2 services.
OBD2 Data Access in EVs: Visual representation of electric vehicles potentially restricting access to data via the OBD2 port.
Get our ‘Ultimate CAN Guide’
Want to become a CAN bus expert?
Get our 12 ‘simple intros’ in one 160+ page PDF:
Download now
OBD2 Standards
On-board diagnostics, or OBD2, operates as a higher-layer protocol, similar to a language used for communication. In contrast, CAN (Controller Area Network) serves as the communication method, akin to a telephone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
The OBD2 standards comprehensively define the OBD2 connector, the underlying communication protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be effectively represented using the 7-layer OSI model. The following sections will focus on the most critical aspects of these standards.
In the OSI model context, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standardization efforts for OBD originating in the USA (SAE) and the EU (ISO). Many of these standards are technically very similar, for example, SAE J1979 is nearly equivalent to ISO 15031-5, and SAE J1962 closely mirrors ISO 15031-3.
OBD2 and CAN Bus in OSI Model: Diagram illustrating the relationship between OBD2 and CAN bus within the 7-layer OSI model.
OBD2 Connector Pinout: Illustration of a Type A OBD2 connector pinout, detailing each pin’s function.
The OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector provides a standardized and easy way to access your car’s diagnostic data. It is formally specified in the standard SAE J1962 / ISO 15031-3.
The illustration above shows a typical Type A OBD2 pin connector, often referred to as the Data Link Connector (DLC).
Key points to remember about the OBD2 connector:
- It’s usually located near the steering wheel but can sometimes be hidden from plain sight.
- Pin 16 provides battery power, often even when the ignition is turned off.
- The specific OBD2 pinout configuration depends on the communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected in OBD2 implementations.
OBD2 Connector – Type A vs. B
In practice, you may encounter both Type A and Type B OBD2 connectors. Type A connectors are predominantly used in cars and light-duty vehicles, while Type B connectors are more common in medium and heavy-duty vehicles.
As shown in the illustration, Type A and Type B connectors share similar OBD2 pinouts but differ in their power supply outputs: Type A typically provides 12V, while Type B delivers 24V. Baud rates can also vary, with cars commonly using 500K baud and heavy-duty vehicles often using 250K baud (though 500K support is becoming more prevalent).
A visual distinction between the two types is the interrupted groove in the middle of the Type B OBD2 connector. This design feature means that a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.
OBD2 Connector Types: Comparison of OBD2 Connector Type A and Type B, highlighting differences in voltage and application.
OBD2 and CAN Bus Relationship: Diagram illustrating the relationship between OBD2 and CAN bus, referencing the ISO15765 standard.
OBD2 and CAN Bus [ISO 15765-4]
Since 2008, CAN bus has been the mandatory lower-layer communication protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints and guidelines applied to the CAN standard (ISO 11898) to ensure interoperability and standardization for diagnostic communication.
Specifically, ISO 15765-4 standardizes the CAN interface for diagnostic test equipment, focusing on the physical, data link, and network layers of the OSI model:
- 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 maximum length for an OBD2 adapter cable is 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
All OBD2 communication relies on a request-response message structure.
In most passenger cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs (Electronic Control Units) to see if they have data to report for the requested parameter (as defined in ISO 15765-4). In contrast, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, although this is less commonly used in typical OBD2 diagnostics.
ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (used by the ECM, Engine Control Module), followed by 0x7E9 (used by the TCM, Transmission Control Module) to a lesser extent.
In some vehicle types, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication protocol may utilize extended 29-bit CAN identifiers instead of the standard 11-bit IDs.
In these 29-bit implementations, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses from the vehicle will typically use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF, with 0x18DAF110 and 0x18DAF11E being commonly observed. The response ID is sometimes also represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is reserved for ISO 15765-2.
OBD2 Request-Response Framework: Diagram illustrating the request and response frames within the OBD2 protocol, including PIDs and data parameters.
OBD2 vs Proprietary CAN: Illustration contrasting OBD2 communication with OEM-specific proprietary CAN bus protocols.
OBD2 vs. Proprietary CAN Protocols
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) do not rely on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) develops and implements their own proprietary CAN protocols for internal vehicle communication. These proprietary CAN protocols are often specific to the vehicle brand, model, and year. Typically, this OEM-specific CAN data is inaccessible to those outside the manufacturer unless it can be reverse engineered.
If you connect a CAN bus data logger to your car’s OBD2 connector, you might observe the OEM-specific CAN data being broadcast, often at a high rate of 1000-2000 frames per second. However, many newer vehicles incorporate a ‘gateway’ module that restricts access to this raw CAN data through the OBD2 port, only allowing standardized OBD2 communication.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific communication protocols. It’s a standardized layer specifically for diagnostics and emissions-related data access.
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 potential combinations for the OBD2 communication protocol. In modern cars, the combination of 500K bit-rate and 11-bit IDs is the most prevalent. However, external diagnostic tools should systematically verify these parameters to ensure correct communication.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This process relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (refer to the OBD2 PID section for details) and that transmitting data at an incorrect bit-rate will generate CAN error frames.
More recent versions of ISO 15765-4 acknowledge that some vehicles may implement OBD communication via OBDonUDS rather than the traditional OBDonEDS. While 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), it’s important to be aware of this distinction.
To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool can send additional request messages. Specifically, it can transmit UDS requests using 11-bit or 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 specific DID.
In practical terms, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is the dominant protocol in most non-electric vehicles today. WWH-OBD is mainly used in EU trucks and buses.
OBD2 Bit-rate and CAN ID Validation Flowchart: A flowchart outlining the process for validating OBD2 bit-rate and CAN ID configurations as per ISO 15765-4.
OBD2 Protocol Standards: Visual representation of the five lower-layer protocols used in OBD2 communication, including CAN, KWP2000, SAE J1850, and ISO9141.
Five Lower-Layer OBD2 Protocols
While CAN bus is now the predominant lower-layer foundation for OBD2 as per ISO 15765, particularly in vehicles manufactured after 2008, it’s helpful to be aware of the other four lower-layer protocols used in older vehicles. Examining the OBD2 connector pinouts can sometimes provide clues about the protocol used in your car.
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most widely used communication protocol for OBD2.
- ISO14230-4 (KWP2000): Keyword Protocol 2000 was commonly used in vehicles manufactured around 2003, particularly in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian vehicles manufactured between 2000 and 2004.
- SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily used in older General Motors (GM) vehicles.
- SAE J1850 (PWM – Pulse Width Modulation): Primarily used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]
All OBD2 data is transmitted over the CAN bus using a transport protocol called ISO-TP (ISO 15765-2). This protocol is essential because it enables the transmission of data payloads exceeding the 8-byte limit of standard CAN frames. This capability is necessary 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, flow control, and reassembly of these larger messages. For a more detailed explanation, refer to our introduction to UDS.
However, much of the time, 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). This leaves 7 bytes within the CAN frame’s data field for the actual OBD2-related communication.
ISO-TP Frame Types for OBD2: Diagram illustrating different frame types in ISO 15765-2 for OBD2 communication, including Single Frame and Multi-Frame types.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To fully grasp 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 actual data payload. The data payload is further structured into Mode, Parameter ID (PID), and data bytes.
OBD2 Message Structure: Breakdown of an OBD2 message structure, showing the arrangement of Mode, PID, Identifier, and Data bytes.
Example: OBD2 Request/Response
Before we delve into each component of the OBD2 message, let’s consider a practical example: requesting and receiving ‘Vehicle Speed’.
In this example, an external diagnostic tool sends a request message to the vehicle. This request message uses CAN ID 0x7DF and contains 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with a message using CAN ID 0x7E8 and a 3-byte payload. This response includes the vehicle speed value in the 4th byte, which is 0x32 (50 in decimal).
By consulting the OBD2 PID specifications for PID 0x0D, we can determine that the physical value represented by 0x32 corresponds to a vehicle speed of 50 km/h.
In the following sections, we will explore OBD2 modes and PIDs in more detail.
OBD2 Request and Response Example: Illustration of an OBD2 request (ID 7DF) and response (ID 7E8) for vehicle speed (PID 0D).
OBD2 PID Example – Vehicle Speed: Detailed view of OBD2 PID 0D (Vehicle Speed), showing the data bytes and their interpretation.
OBD2 Service Modes: Visual overview of the 10 OBD2 service modes, including functionalities like current data, freeze frame, and DTC clearing.
The 10 OBD2 Services (aka modes)
The OBD2 standard defines 10 diagnostic services, often referred to as modes. Mode 0x01 is used to retrieve current, real-time data parameters, while other modes are designed to access and manage Diagnostic Trouble Codes (DTCs), retrieve freeze frame data, and perform other diagnostic functions.
It’s important to note that vehicles are not required to support all 10 standardized OBD2 modes. Furthermore, manufacturers may implement additional, non-standardized modes beyond these 10 for OEM-specific diagnostics.
Within OBD2 messages, the mode is indicated in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). However, in a response message, 0x40 is added to the mode value (e.g., a response to mode 0x01 will have a mode value of 0x41).
OBD2 Parameter IDs (PID)
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the specific data parameter being requested or reported.
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 all PIDs defined within a given mode. In practice, most vehicles only support a subset of the available PIDs.
One PID holds a special significance in OBD2.
Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When queried with PID 0x00 in mode 0x01, the vehicle’s ECU responds by indicating which PIDs within the range 0x01-0x20 it supports. This makes PID 0x00 a valuable tool for initial ‘OBD2 compatibility testing’. 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, and so on).
OBD2 Request-Response with PIDs: Diagram re-emphasizing the request and response framework of OBD2 protocol, focusing on the role of PIDs in data parameters.
OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool, showing service 01 and available PIDs for selection and analysis.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide detailed scaling and decoding information for standardized OBD2 PIDs. This information is essential for converting the raw data bytes into meaningful physical values, as explained in our CAN bus introduction.
If you need a quick reference for mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. This tool helps you construct OBD2 request frames and dynamically decode OBD2 responses, streamlining the process of working with OBD2 data.
OBD2 PID overview tool
How to Log and Decode OBD2 Data
In this section, we’ll walk through a practical 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 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: Diagram illustrating an OBD2 data logger making a PID request (7DF) and receiving a response (7E8) in a vehicle.
Bit-rate Validation: Screenshot showing a bit-rate validation test for OBD2 communication.
Supported PIDs Test Responses: Screenshot from asammdf showing responses to ‘Supported PIDs’ requests for OBD2.
#1: Test Bit-rate, IDs & Supported PIDs
As discussed earlier, ISO 15765-4 outlines a procedure to determine the correct bit-rate and CAN IDs for OBD2 communication in a specific vehicle. You can perform these tests using the CANedge as described below (refer to the CANedge Intro for detailed instructions):
- Bit-rate Test: Send a CAN frame at 500K bit-rate. Check if the transmission is successful. If not, try 250K.
- Bit-rate Confirmation: Use the successfully tested bit-rate for all subsequent communication.
- Supported PIDs Request: Send multiple ‘Supported PIDs’ requests (Mode 0x01 PID 0x00) and analyze the responses.
- CAN ID Determination: Based on the response IDs (e.g., 0x7E8, 0x7E9), determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2.
- Supported PID Discovery: Analyze the response data to identify the specific PIDs supported by the vehicle’s ECUs.
We provide pre-configured CANedge configurations 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 communication protocol.
As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD2 request. This is because using the functional address request ID (0x7DF) polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs are required to support service 0x01 PID 0x00, there are often numerous responses, particularly to this PID. As evident, the number of responding ECUs gradually decreases for subsequent ‘Supported PIDs’ requests. Note also that the ECM ECU (0x7E8) in this example supports all the PIDs supported by other ECUs. This suggests that bus load could be reduced by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.
#2: Configure OBD2 PID Requests
Once you have determined the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can proceed to configure your CANedge to request the specific PIDs you are interested in logging.
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 consecutive OBD2 requests. Sending requests too rapidly (spamming) may cause ECUs to stop responding.
- Battery Drain Management: Implement triggers to stop PID transmissions when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
- Data Filtering: Configure filters to record only OBD2 responses. This is particularly useful if your vehicle also transmits OEM-specific CAN data that you are not interested in logging.
With these configurations in place, your CANedge is ready to efficiently log raw OBD2 data from your vehicle.
CANedge OBD2 Request Configuration: Example of a CANedge transmit list configured for OBD2 PID requests.
Decoded OBD2 Data Visualization: asammdf screenshot showing DBC decoded and visualized OBD2 data, plotted for analysis.
#3: DBC Decode Raw OBD2 Data
To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data bytes into human-readable ‘physical values’ (e.g., km/h, °C, RPM).
The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available in resources like Wikipedia. For convenience, we provide a free OBD2 DBC file. This DBC file simplifies the process of DBC decoding raw OBD2 data within most CAN bus software tools.
Decoding OBD2 data is somewhat more complex than decoding typical CAN signals. This is because different OBD2 PIDs are often 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, you must use a combination of the CAN ID, the OBD2 mode, and the OBD2 PID to correctly identify each signal. This technique is a form of multiplexing known as ‘extended multiplexing‘. It can be effectively implemented using DBC files, allowing software tools to correctly interpret the multiplexed OBD2 data.
CANedge: OBD2 Data Logger
The CANedge provides an easy and robust solution for recording OBD2 data directly to an 8-32 GB SD card. Simply connect the CANedge to your car, truck, or other vehicle to begin logging. You can then decode and analyze the logged data using free software and APIs in conjunction with our OBD2 DBC file.
OBD2 logger intro
CANedge Product Page
OBD2 Multi-Frame Examples [ISO-TP]
As mentioned earlier, all OBD2 data communication relies on the ISO-TP (Transport Protocol) as defined in ISO 15765-2. Most examples we’ve discussed so far have involved single-frame communication. In this section, we’ll explore examples of multi-frame communication scenarios.
Multi-frame OBD2 communication necessitates the use of flow control frames (refer to our UDS introduction for details on flow control in transport protocols). In practice, a common approach is to transmit a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.
Furthermore, processing multi-frame OBD2 responses requires CAN software or API tools that support ISO-TP, such as the CANedge MF4 decoders.
OBD2 Multi-Frame Request: Example of an OBD2 multi-frame request message, specifically for requesting the Vehicle Identification Number (VIN).
Example 1: OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is a crucial piece of information for telematics, diagnostics, and various other automotive applications (see our UDS introduction for more context). To retrieve the VIN from a vehicle using OBD2 requests, you use mode 0x09 and PID 0x02:
In this example, the diagnostic tester tool sends a Single Frame request. The PCI field is set to 0x02, indicating a Single Frame. The request includes the service identifier for mode 0x09 (Request Vehicle Information) and the PID 0x02 (Request VIN).
The vehicle responds with a First Frame. The PCI field indicates a First Frame. The length field (0x014 = 20 bytes) specifies the total length of the multi-frame response. The mode is 0x49 (0x09 + 0x40), indicating a positive response to mode 0x09. The PID is 0x02, confirming the VIN response. Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN itself, encoded in HEX. These HEX values can be converted to ASCII characters using methods described in our UDS introduction to obtain the human-readable VIN.
Example 2: OBD2 Multi-PID Request (6x)
OBD2 allows external diagnostic tools to request up to 6 mode 0x01 PIDs in a single request frame. The ECU is then expected to respond with data for all supported PIDs from the requested set (omitting data for any unsupported PIDs). If necessary, the ECU may use multi-frame responses as per ISO-TP to accommodate all the requested data.
This multi-PID request feature can improve data collection efficiency by allowing you to retrieve multiple parameters with a single request. However, it also introduces complexities in signal encoding, potentially making the use of generic OBD2 DBC files challenging. For this reason, we generally do not recommend using multi-PID requests in practical OBD2 data logging scenarios unless you have specific tools designed to handle this method.
Below is an example trace illustrating a multi-PID request and response:
The multi-frame response structure is similar to the VIN example, but with the added complexity that the payload includes both the requested PIDs and the data values for each of them. In the example trace, 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 multi-PID responses using generic DBC files is practically very difficult. Therefore, we advise against using this approach for general data logging unless you are using specialized tools that explicitly support it. Effectively, you are dealing with a case of extended multiplexing, but compounded by multiple multiplexed signals within the payload. Your DBC file would need to account for the specific payload position of each PID, making it challenging to create a generalized DBC that works across different vehicles with varying PID support. Furthermore, managing this becomes increasingly complex if you send multiple multi-PID requests, as you lose a straightforward method for uniquely identifying messages from each other based on CAN ID alone.
Possible workarounds could involve custom scripting and recording the transmit messages from your diagnostic tool. A script could then be designed to interpret the response message in the context of the preceding request message. However, such approaches become complex to manage at scale and are generally not ideal for widespread deployment.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, “Show stored Diagnostic Trouble Codes”. 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). Each DTC is represented by 2 data bytes. Consequently, multi-frame responses are necessary when more than 2 DTCs are stored.
The 2-byte DTC value is typically structured into two parts, as defined by ISO 15031-5 and ISO 15031-6. The first 2 bits indicate the ‘category’ of the DTC (e.g., Powertrain, Body, Chassis, Network), while the remaining 14 bits form a 4-digit code (displayed in hexadecimal). 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: Diagram illustrating how OBD2 Diagnostic Trouble Codes (DTCs) are structured and interpreted within the DBC file format.
OBD2 Data Logging – Use Case Examples
OBD2 data from cars and light trucks is valuable for a wide range of applications:
Logging data from cars
OBD2 data logging in cars can be used to achieve goals such as reducing fuel consumption, improving driving habits, validating prototype components, and optimizing insurance risk assessments.
OBD2 Logger Product Link
Real-time car diagnostics
OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data, which is crucial for diagnosing vehicle issues and monitoring vehicle health.
OBD2 Streaming Interface
Predictive maintenance
Cars and light trucks equipped with IoT-enabled OBD2 loggers can be remotely monitored in the cloud to predict potential breakdowns and enable proactive maintenance, reducing downtime and repair costs.
Predictive Maintenance Solutions
Vehicle blackbox logger
An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, continuously recording critical data that can be invaluable for resolving disputes, accident analysis, and in-depth diagnostics.
CAN Bus Blackbox Loggers
Do you have an OBD2 data logging use case you’d like to discuss? Reach out for a free consultation!
Contact us
For more in-depth introductions to related topics, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
Get your OBD2 data logger today!
Buy now
Contact us for support
Recommended for you
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
