Need a clear and practical understanding of Obdii Protocols?
This guide offers a deep dive into On-Board Diagnostics II (OBDII) protocols, encompassing the OBDII connector, Parameter IDs (PIDs), and their relationship with the Controller Area Network (CAN) bus.
Designed as a comprehensive guide, you’ll not only grasp the fundamentals but also learn how to effectively request and interpret OBDII data, explore key applications in data logging, and gain valuable practical insights.
Discover why this article is becoming a go-to resource for mastering OBDII protocols.
You can also explore our introductory video on OBDII or download this guide in PDF format for offline access.
Understanding OBDII Protocols
OBDII protocols represent the standardized language of your vehicle’s self-diagnostic system. It’s a globally recognized standard that enables the retrieval of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBDII connector.
You’ve likely encountered OBDII in action already:
Ever noticed the check engine light illuminating on your dashboard?
That’s your vehicle signaling a potential issue. When you consult a mechanic, they utilize an OBDII scanner to pinpoint the problem.
The process involves connecting the OBDII scanner to the 16-pin OBDII connector, typically located near the steering wheel. This tool transmits ‘OBDII requests’ to the vehicle, which then responds with ‘OBDII responses’. These responses can contain crucial information such as speed, fuel level, or Diagnostic Trouble Codes (DTCs), significantly streamlining the troubleshooting process.
Understanding OBDII: On-Board Diagnostics and the Malfunction Indicator Light (MIL), often diagnosed with a scan tool.
OBDII Compatibility: Does Your Car Support It?
The short answer is: Most likely, yes!
The vast majority of modern non-electric vehicles are equipped with OBDII support, and many operate on the CAN bus protocol. However, for older vehicles, the presence of a 16-pin OBDII connector doesn’t guarantee OBDII compliance. As scantool.net explains, determining compliance often depends on the vehicle’s origin and purchase date:
Does My Car Have OBD2?
OBDII Compliance Guide: Check your vehicle’s compliance based on purchase location and year in the EU and US markets.
A Look at OBDII Protocol History
The genesis of OBDII protocols can be traced back to California, where the California Air Resources Board (CARB) mandated OBD implementation in all new vehicles from 1991 onwards for enhanced emission control.
The OBDII standard was subsequently refined and recommended by the Society of Automotive Engineers (SAE), leading to standardized DTCs and a universal OBD connector across different vehicle manufacturers (SAE J1962).
From its Californian origins, the OBDII standard was progressively adopted globally:
- 1996: OBDII became mandatory in the USA for cars and light trucks.
- 2001: The European Union mandated OBDII for gasoline cars.
- 2003: OBDII compliance was extended to diesel cars in the EU (known as EOBD).
- 2005: OBDII requirements in the US broadened to include medium-duty vehicles.
- 2008: US vehicle manufacturers were required to adopt ISO 15765-4 (CAN) as the foundation for OBDII protocols.
- 2010: OBDII standardization was completed in the US with its mandate for heavy-duty vehicles.
OBDII History: A timeline of emission control and the evolution of OBDII, EOBD, and integration with CAN bus technology.
OBDII History Timeline: A visual overview of the milestones in the development and standardization of On-Board Diagnostics.
The Future of OBD: OBDIII trends towards remote diagnostics, emissions testing, cloud connectivity, and integration with IoT technologies.
The Future Trajectory of OBDII Protocols
OBDII is firmly established in automotive diagnostics, but its evolution continues.
Here are key trends shaping the future of OBDII protocols:
Initially designed for emissions monitoring and testing, legislated OBDII faces a shifting landscape. Electric vehicles, for instance, are not obligated to support OBDII protocols in their conventional form. This is reflected in the fact that most modern EVs do not support standard OBDII requests. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication. This OEM-specific approach generally restricts access to vehicle data unless decoding methods are reverse-engineered. For examples, explore our case studies on electric vehicles, including insights into Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Recognizing the limitations of current OBDII implementations in terms of data richness and underlying protocols, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These advanced protocols aim to refine OBD communication by building upon the UDS protocol framework. For a deeper understanding of these protocols, refer to our introduction to UDS.
In an era of increasingly connected vehicles, traditional OBDII testing methods can seem outdated. Manual emission checks are time-consuming and costly.
The proposed solution is OBDIII – integrating telematics into all vehicles.
OBDIII envisions equipping vehicles with a small radio transponder (similar to those used for toll collection). This technology would enable vehicles to transmit their Vehicle Identification Number (VIN) and DTCs wirelessly via WiFi to a central server for automated diagnostics.
Many existing devices already facilitate CAN or OBDII data transfer via WiFi/cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While offering cost and convenience benefits, OBDIII also presents political challenges related to data privacy and surveillance concerns.
Originally conceived for stationary emission control, OBDII protocols are now extensively utilized by third-party services for real-time data generation via OBDII dongles, CAN loggers, and similar devices. However, the German automotive industry is seeking to restrict this access:
“OBD was designed to service cars 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 proposition involves deactivating OBDII functionality during driving, centralizing data collection on manufacturer servers instead. This would effectively place vehicle manufacturers in control of the burgeoning field of ‘automotive big data’.
Arguments for this shift often cite security concerns, such as mitigating the risk of vehicle hacking. However, many industry observers view this as a commercially motivated move. Whether this trend gains momentum remains to be seen, but it has the potential to significantly disrupt the market for third-party OBDII-based services.
OBDII Future: The potential trend of electric vehicles restricting data access via the OBDII connector.
Expand Your CAN Bus Expertise
Interested in becoming a CAN bus expert?
Access our comprehensive collection of 12 ‘simple introductions’ in a single 160+ page PDF:
Download now
CAN Bus – The Ultimate Guide Tutorial PDF
OBDII Protocol Standards
On-board diagnostics, OBDII, operates as a higher-layer protocol, similar to a language, while CAN functions as the communication method, akin to a phone line. This places OBDII in the same category as other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
Specifically, OBDII protocol standards define the OBDII connector specifications, lower-layer communication protocols, OBDII Parameter IDs (PIDs), and other critical aspects.
These standards can be visualized within a 7-layer OSI model. The following sections will focus on the most essential standards within this framework.
In the OSI model overview, you’ll notice that several layers are governed by both SAE and ISO standards. This reflects the standardization efforts for OBDII protocols in the USA (SAE) and Europe (ISO). Notably, many SAE and ISO standards are technically equivalent, such as SAE J1979 and ISO 15031-5, as well as SAE J1962 and ISO 15031-3.
OBDII vs. CAN Bus: Illustrating the OSI 7-Layer Model with ISO 15765 and ISO 11898 standards for automotive communication protocols.
OBDII Connector Pinout: Diagram of a Type A female socket, detailing the Data Link Connector (DLC) pin assignments.
The OBDII Connector [SAE J1962 / ISO 15031-3]
The 16-pin OBDII connector, standardized under SAE J1962 and ISO 15031-3, provides a standardized interface for accessing vehicle data. It is also known as the Data Link Connector (DLC).
Key features of the OBDII connector include:
- Its location is typically near the steering wheel, although it may be concealed.
- Pin 16 provides battery power, often even when the ignition is off.
- The OBDII pinout configuration varies depending on the communication protocol in use.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.
OBDII Connector Types: A vs. B
In practical applications, you may encounter both Type A and Type B OBDII connectors. Type A is predominantly used in cars, while Type B is common in medium and heavy-duty vehicles.
While both types share similar OBDII pinouts, they differ in power supply outputs: Type A typically provides 12V, whereas Type B delivers 24V. Baud rates may also vary, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).
A key physical distinction is that the Type B OBDII connector features an interrupted groove in the middle. Consequently, a Type B OBDII adapter cable is universally compatible with both Type A and Type B sockets, while a Type A adapter will not fit into a Type B socket.
OBDII Connector Types A and B: Illustrating the differences in SAE J1962 connectors for cars, vans, and trucks, highlighting 12V and 24V power variations.
OBDII vs. CAN Bus ISO 15765: A comparison highlighting the relationship between OBDII protocols and CAN bus communication standards.
OBDII and CAN Bus Communication [ISO 15765-4]
Since 2008, the Controller Area Network (CAN) bus has been the mandatory lower-layer protocol for OBDII in all vehicles sold in the US, as mandated by ISO 15765.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints applied to the CAN standard (ISO 11898).
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 is limited to a maximum length of 5 meters.
OBDII CAN Identifiers (11-bit and 29-bit)
OBDII communication relies on a request-response message structure.
In most passenger vehicles, 11-bit CAN IDs are used for OBDII communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBDII-compatible Electronic Control Units (ECUs) for data related to the requested parameter (as per ISO 15765-4). Conversely, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, although this is less common.
ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (associated with the Engine Control Module, ECM), followed by 0x7E9 (typically for the Transmission Control Module, TCM).
In certain vehicle types, particularly vans and light, medium, and heavy-duty vehicles, OBDII communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.
For 29-bit CAN, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is designated as ‘Reserved for ISO 15765-2’.
OBDII Protocol Request and Response Frames: Illustrating the structure of OBDII communication with PID data and parameters.
OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0
OBDII vs. Proprietary CAN Bus: Comparing standard OBDII protocols with OEM-specific CAN bus data communication within vehicles.
OBDII vs. Proprietary CAN Protocols
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific proprietary CAN protocols, independent of OBDII. Each Original Equipment Manufacturer (OEM) develops unique CAN protocols tailored to their specific vehicle brands, models, and production years. Accessing and interpreting this OEM-specific CAN data is typically restricted unless you possess OEM tools or can successfully reverse engineer the protocols.
When a CAN bus data logger is connected to your vehicle’s OBDII connector, you might observe OEM-specific CAN data being broadcast, often at a rate of 1000-2000 frames per second. However, many newer vehicles incorporate a ‘gateway’ that restricts access to this raw CAN data through the OBDII port, allowing only standardized OBDII communication.
In essence, OBDII can be considered an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol.
Bit-Rate and ID Validation in OBDII Protocols
As previously mentioned, OBDII protocols can utilize two different bit rates (250 kbps, 500 kbps) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. In contemporary vehicles, the most common configuration is 500 kbps with 11-bit IDs. However, external diagnostic tools should systematically verify these parameters to ensure proper communication.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This method relies on the requirement that OBDII-compliant vehicles must respond to a specific mandatory OBDII request (further detailed in the OBDII PID section) and leverages the fact that incorrect bit rate transmission will result in CAN error frames.
More recent versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than OBDonEDS (OBD on Emission Diagnostic Service). While this article primarily focuses on OBDII/OBDonEDS (as defined in ISO 15031-5/SAE J1979), it’s important to be aware of WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV vehicles today, while WWH-OBD is primarily found in EU trucks and buses.
OBDII Bit-Rate and CAN ID Validation Flowchart: ISO 15765-4 process for systematically validating OBDII communication parameters.
OBDII Standards: An overview of the five lower-layer protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBDII Protocols
While CAN (ISO 15765) is the dominant lower-layer protocol for OBDII in most modern vehicles, particularly those manufactured post-2008, it’s valuable to understand the four alternative protocols used in older vehicles. Examining the OBDII connector pinouts can often help identify the protocol in use.
The five lower-layer OBDII protocols include:
- ISO 15765 (CAN bus): Mandated in US vehicles since 2008 and now the most widely used OBDII protocol.
- ISO 14230-4 (KWP2000): Keyword Protocol 2000, frequently used in vehicles from 2003 onwards, particularly in Asia.
- ISO 9141-2: Common in EU, Chrysler, and Asian vehicles manufactured between 2000 and 2004.
- SAE J1850 (VPW): Predominantly used in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Primarily implemented in older Ford vehicles.
ISO-TP: Transporting OBDII Messages [ISO 15765-2]
All OBDII data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte limit of standard CAN frames, which is essential for OBDII functions such as retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 manages data segmentation, flow control, and reassembly for these larger messages. For a more in-depth explanation, consult our introduction to UDS.
However, much of the OBDII data exchange fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) messages. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBDII-related communication.
ISO 15765-2 ISO-TP OBDII Frame Types: Depicting various frame types used in ISO-TP for OBDII communication.
The OBDII Diagnostic Message Structure [SAE J1979, ISO 15031-5]
To gain a deeper understanding of OBDII over CAN, let’s examine the structure of a raw ‘Single Frame’ OBDII CAN message. In simplified terms, an OBDII message comprises a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload is further divided into Mode, Parameter ID (PID), and data bytes.
OBDII PIDs Message Structure: Breakdown of an OBDII message, explaining the raw frame, mode, PID, ID, and data bytes.
Example: OBDII Request and Response
Before delving into the components of an OBDII message, consider this practical example of a request and response for ‘Vehicle Speed’.
In this scenario, an external tool sends a request message to the vehicle using CAN ID 0x7DF, with a 2-byte payload consisting of Mode 0x01 and PID 0x0D. The vehicle responds with a message using CAN ID 0x7E8 and a 3-byte payload. The vehicle speed value is encoded in the 4th byte, which is 0x32 (decimal 50).
By consulting the decoding specifications for OBDII PID 0x0D, we determine that the physical value is 50 km/h.
In the following sections, we will explore OBDII modes and PIDs in more detail.
OBDII Request and Response: Example of a 7DF request and 7E8 response for vehicle speed data retrieval.
OBDII PID Example: Vehicle Speed PID 0D, illustrating how to request and interpret vehicle speed data.
OBDII Services Modes: Overview of the 10 diagnostic services or modes in OBDII, including current data, freeze frame, and DTC clearing.
The 10 OBDII Diagnostic Services (Modes)
OBDII protocols define 10 diagnostic services, also referred to as modes. Mode 0x01 is used to retrieve real-time data, while other modes are designed for accessing and clearing diagnostic trouble codes (DTCs) or retrieving freeze frame data.
Vehicles are not required to support all 10 standardized OBDII modes, and manufacturers may implement additional OEM-specific modes beyond these standard ones.
In OBDII 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), whereas in a response message, 0x40 is added to the requested mode (resulting in 0x41 for mode 0x01).
OBDII Parameter IDs (PIDs)
Within each OBDII mode, there are Parameter IDs (PIDs).
For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.
One PID holds special significance in OBDII protocols.
If an emissions-related ECU supports any OBDII services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle’s ECU communicates its support for PIDs in the range 0x01-0x20. This makes PID 0x00 a fundamental tool for ‘OBDII compatibility testing’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in subsequent ranges.
OBDII Protocol Request and Response Frames: Further illustration of OBDII communication with PID data and parameters in request-response cycles.
OBD2 PID overview tool
OBDII PID Overview Tool: A visual representation of a tool designed to navigate and understand OBDII Parameter IDs for service 01.
Tip: OBDII PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBDII PIDs, enabling the conversion of raw data into physical values, as detailed in our CAN bus introduction.
For quick lookups of mode 0x01 PIDs, our OBDII PID overview tool is a valuable resource. This tool assists in constructing OBDII request frames and dynamically decoding OBDII responses.
OBDII PID overview tool
Practical Guide: Logging and Decoding OBDII Data
This section provides a practical demonstration of how to log OBDII data using the CANedge CAN bus data logger.
The CANedge’s configurable CAN frame transmission capabilities make it ideal for OBDII data logging.
For easy vehicle connectivity, the CANedge can be paired with our OBDII-DB9 adapter cable.
OBDII PID Data Logger: Illustrating the CANedge data logger requesting PID data using 7DF and receiving responses via 7E8.
OBD2 bit rate test
OBDII Bit Rate Test: Validating bit rate settings for OBDII communication, ensuring successful data transmission.
OBD2 Supported PIDs Test
OBDII Supported PIDs Test: Reviewing responses in asammdf to validate supported Parameter IDs during OBDII data logging.
Review supported PIDs via OBD2 lookup tool
Step #1: Bit-Rate, ID, and Supported PID Validation
As previously discussed, ISO 15765-4 outlines the process for determining the bit rate and CAN IDs used by a specific vehicle. You can utilize the CANedge for this validation process, as outlined below (refer to the CANedge Introduction for detailed instructions):
- Transmit a CAN frame at 500 kbps to test if successful (if not, test at 250 kbps).
- Use the validated bit rate for subsequent communication.
- Send multiple ‘Supported PIDs’ requests and analyze the responses.
- Determine whether 11-bit or 29-bit CAN IDs are used based on response IDs.
- Identify supported PIDs based on the response data.
We provide pre-configured settings to facilitate these validation tests.
Most non-EV vehicles manufactured in 2008 or later typically support 40-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 OBDII request are common. This is because the 0x7DF request ID is used, which polls all ECUs for responses. Since all OBDII/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. As evident, subsequent ‘Supported PIDs’ requests elicit fewer ECU responses. Notice that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. Optimizing communication efficiency can be achieved by directing subsequent requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0.
Step #2: Configuring OBDII PID Requests
Once you have identified the supported OBDII PIDs for your vehicle, along with the appropriate bit rate and CAN IDs, you can configure your transmit list to request the PIDs of interest.
Consider these factors when configuring your PID requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses to each request.
- Spacing: Introduce a delay of 300-500 ms between each OBDII request to prevent overwhelming ECUs and ensure reliable responses.
- Battery Drain: Implement triggers to halt transmission when the vehicle is inactive, preventing unnecessary ECU ‘wake-up’ and battery drain.
- Filters: Apply filters to record only OBDII responses if your vehicle also broadcasts OEM-specific CAN data, streamlining data logging.
With these configurations in place, your CANedge is ready to log raw OBDII data efficiently.
obd2-transmit-list-example-canedge
OBDII Transmit List Example: Configuration of a CANedge transmit list for requesting specific OBDII PIDs.
OBD2 data decoded visual plot asammdf CAN bus DBC file
OBDII Data Decoded in asammdf: Visual plot of decoded OBDII data using asammdf software and a CAN bus DBC file for analysis.
Step #3: DBC Decoding of Raw OBDII Data
To effectively analyze and visualize logged OBDII data, you need to decode the raw data into ‘physical values,’ such as km/h or °C.
Decoding specifications can be found in ISO 15031-5/SAE J1979 and online resources 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 presents unique challenges compared to standard CAN signals. Because different OBDII PIDs are transmitted using the same CAN ID (e.g., 0x7E8), the CAN ID alone is insufficient to identify the signals within the payload.
To address this, decoding requires considering not only the CAN ID but also the OBDII mode and PID. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented using DBC files.
CANedge: Your OBDII Data Logging Solution
The CANedge provides a seamless solution for recording OBDII data directly to an 8-32 GB SD card. Simply connect it to your vehicle to begin logging and utilize free software/APIs and our OBDII DBC file for data decoding and analysis.
OBDII logger intro CANedge
OBDII Multi-Frame Communication Examples [ISO-TP]
While many OBDII interactions are single-frame, certain operations require multi-frame communication using ISO-TP (ISO 15765-2). This section provides examples of multi-frame OBDII communication.
Multi-frame OBDII exchanges necessitate 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 frame, as shown in the CANedge configuration example.
Analyzing multi-frame OBDII responses requires CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.
OBD2-multi-frame-request-message-vehicle-identification-number
OBDII Multi-Frame Request: Example of a multi-frame request message for retrieving the Vehicle Identification Number (VIN).
Example 1: Retrieving the OBDII Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various other applications (refer to our UDS introduction for further details). To retrieve the VIN using OBDII requests, utilize mode 0x09 and PID 0x02:
VIN Vehicle Identification Number OBD2 Example multi-frame
The diagnostic tool initiates a Single Frame request with the PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, indicating 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 represent the VIN and can be converted from hexadecimal to ASCII format using methods described in our UDS introduction.
Example 2: OBDII Multi-PID Request (6x)
External tools can request up to six mode 0x01 OBDII PIDs within a single request frame. The ECU will respond with data for supported PIDs (excluding unsupported ones from the response), potentially using multiple frames as per ISO-TP if necessary.
This capability enhances data collection efficiency and frequency. However, it also introduces complexities in signal encoding specific to the request method, making generic OBDII DBC files less applicable for such use cases. We generally advise against using this method in practice. Below is an example trace illustrating this approach:
Requesting multiple PIDs in one request
The multi-frame response is similar to the VIN example, but with the added complexity of including both the requested PIDs and their corresponding data within the payload. Note that the PIDs in the example are ordered similarly to the request order, which is common practice but not strictly mandated by ISO 15031-5.
Decoding such responses using generic DBC files is challenging in practice. Therefore, we do not recommend this approach for practical data logging unless you are using a tool specifically designed for this purpose. Effectively, you are working with a form of extended multiplexing with multiple instances within the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying supported PIDs. Furthermore, managing multiple multi-PID requests via pure DBC manipulations becomes very complex, as uniquely identifying messages from each other becomes problematic.
Potential workarounds include custom scripts that interpret response messages in conjunction with request messages. However, such approaches are often difficult to scale.
Example 3: OBDII Diagnostic Trouble Codes (DTCs)
OBDII protocols enable the retrieval of emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The target ECU(s) will respond with the number of stored DTCs (potentially zero if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.
The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits represent a 4-digit code (displayed in hexadecimal), as illustrated. 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 six stored DTCs.
OBDII DTC Decoding Example: Interpretation of Diagnostic Trouble Codes (DTCs) within a DBC file, breaking down the structure and categories.
OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example
OBDII Data Logging: Use Case Examples
OBDII data logging from cars and light trucks has diverse applications:
Vehicle Data Logging for Cars
OBDII data from passenger vehicles can be leveraged for fuel efficiency optimization, driving behavior improvement, prototype component testing, and insurance telematics.
OBDII logger
Real-time Vehicle Diagnostics
OBDII interfaces facilitate real-time streaming of human-readable vehicle data, enabling efficient vehicle diagnostics and troubleshooting.
OBDII streaming
Predictive Maintenance Applications
Utilizing IoT-enabled OBDII loggers in the cloud allows for continuous vehicle monitoring and predictive maintenance, helping prevent breakdowns and optimize vehicle uptime.
Predictive maintenance
Vehicle Black Box Recording
An OBDII logger can serve as a ‘black box’ for vehicles and equipment, providing valuable data for incident analysis, dispute resolution, and diagnostic investigations.
CAN bus black box
Do you have a specific OBDII data logging application in mind? Contact us for expert consultation and guidance!
Contact us
Explore our guides section for more introductory resources, or download the comprehensive ‘Ultimate Guide’ PDF for in-depth knowledge.
Need to log or stream OBDII data?
Get your OBDII data logger today!
Buy now Contact us
Recommended Resources
OBDII DATA LOGGER: EASILY LOG & CONVERT OBDII DATA
CANedge2 – Dual CAN Bus Telematics Dongle CANEDGE2 – PRO CAN IoT LOGGER
[
