Understanding OBDII CAN Bus: A Comprehensive Guide for Automotive Diagnostics

Need a simple, practical intro to OBDII and its relation to CAN bus?

In this guide, we delve into the On-Board Diagnostics II (OBDII) protocol, with a particular focus on its integration with the Controller Area Network (CAN bus). We’ll explore the OBDII connector, OBDII Parameter IDs (PIDs), and how they link to the CAN bus system.

This is designed to be a practical introduction, providing you with the knowledge to understand how OBDII data is requested and decoded, key use cases for data logging, and valuable practical tips.

Discover why this is becoming a go-to resource for understanding OBDII and CAN bus in modern vehicles.

You can also watch our OBDII introduction video above – or get the PDF

What is OBDII? Is it CAN Bus Based?

OBDII, or On-Board Diagnostics II, is your car’s essential built-in self-diagnostic system. It operates as a standardized protocol that enables the extraction of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBDII connector. A crucial aspect of modern OBDII systems is their reliance on CAN bus for communication. So, is OBDII CAN bus? In many modern vehicles, the answer is yes. OBDII often utilizes CAN bus as its communication network, making CAN bus an integral part of how you interact with your vehicle’s diagnostics.

You’ve likely already encountered OBDII in action:

Have you ever noticed the malfunction indicator light, commonly known as the “check engine light,” illuminate on your dashboard?

This light is your car signaling that an issue has been detected. When you take your vehicle to a mechanic, they will typically use an OBDII scanner to diagnose the problem.

To perform a diagnosis, the mechanic connects an OBDII reader to the OBDII 16-pin connector, usually located near the steering wheel. This tool sends ‘OBDII requests’ to the car’s computer system. The car then responds with ‘OBDII responses’, which can include data such as speed, fuel level, or Diagnostic Trouble Codes (DTCs). This communication, often over CAN bus, allows for quicker and more efficient troubleshooting of vehicle issues. Understanding OBDII CAN bus integration is key to effective vehicle diagnostics.

Understanding OBDII: On-Board Diagnostics and the Malfunction Indicator Light (MIL) as seen with a scan tool.

Does My Car Use OBDII CAN Bus?

In short: Most likely!

Nearly all newer non-electric vehicles are equipped with OBDII, and a significant majority of these systems operate on CAN bus. However, for older vehicles, it’s important to note that even if a 16-pin OBDII connector is present, it might not actually support the OBDII protocol. To determine if your vehicle is OBDII compliant, consider the vehicle’s origin and the year it was first purchased as new:

Does My Car Have OBD2?
Determining OBDII Compliance: A guide based on vehicle origin (EU/US) and CAN bus support.

A Brief History of OBDII and CAN Bus in Automotive Diagnostics

The story of OBDII begins in California, where the California Air Resources Board (CARB) mandated the inclusion of On-Board Diagnostics in all new vehicles starting from 1991 for the purpose of emission control. This early OBD system paved the way for the more standardized OBDII.

The OBDII standard we know today was largely shaped and recommended by the Society of Automotive Engineers (SAE). They played a crucial role in standardizing Diagnostic Trouble Codes (DTCs) and the physical OBD connector across different vehicle manufacturers (SAE J1962). This standardization was a critical step in making vehicle diagnostics more accessible and uniform.

From its Californian origins, the OBDII standard was progressively implemented across the automotive industry:

1996: OBDII became mandatory in the USA for cars and light trucks. This marked a significant expansion of OBDII’s reach.
2001: The European Union followed suit, requiring OBDII for gasoline cars. This extended the standard globally.
2003: The EU mandate expanded to include diesel cars as well (EOBD or European On-Board Diagnostics), further solidifying OBDII’s importance.
2005: OBDII requirements in the US broadened again to encompass medium-duty vehicles, demonstrating the growing scope of OBDII application.
2008: A pivotal year for OBDII CAN bus integration, as US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBDII communication. This mandate cemented CAN bus as the primary communication protocol for OBDII in the US market.
2010: Finally, OBDII became mandatory in the US for heavy-duty vehicles, completing the rollout across all major vehicle categories and reinforcing the role of OBDII CAN bus in vehicle diagnostics.

OBDII History: Tracing the evolution of On-Board Diagnostics, emission control, and the integration of CAN bus.

OBDII History Timeline: A visual overview of the milestones in On-Board Diagnostics development.

The Future of OBD: OBDIII, remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future of OBDII and the Role of CAN Bus

OBDII is firmly established in automotive diagnostics and is expected to remain relevant. However, its future form is evolving, particularly in relation to electric vehicles and advanced communication protocols.

Here are some key trends shaping the future of OBDII:

Originally conceived for emissions control and testing, legislated OBDII has a different relevance for electric vehicles. Interestingly, electric vehicles are not obligated to support OBDII in its traditional form. This is reflected in the fact that most modern EVs do not support standard OBDII requests. Instead, many electric vehicles utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift often makes accessing and decoding data from EVs challenging, except in cases where reverse engineering efforts have revealed the decoding rules. For examples, you can explore case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Recognizing the limitations of current OBDII implementations, particularly in data richness and lower-layer protocols, modern alternatives are emerging. These include WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both of these advanced protocols aim to enhance and streamline OBD communication by using the UDS protocol as a foundation. To gain a deeper understanding of these protocols, refer to introductions to UDS.

In our increasingly connected world, traditional OBDII testing methods can seem outdated. Manual emission control checks are time-consuming and costly.

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

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

Many devices already facilitate the wireless transfer of CAN or OBDII data, such as WiFi CAN loggers and 3G/4G CAN loggers.

While this approach offers cost savings and convenience, it also raises political and privacy concerns related to surveillance.

The original design of the OBDII protocol focused on stationary emission controls.

However, today, OBDII is widely used by third parties to generate real-time vehicle data through OBDII dongles, CAN loggers and similar devices. Interestingly, the German car industry is considering a change to this landscape.

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 proposal is to potentially “turn off” OBDII functionality while the vehicle is in motion and instead centralize data collection on manufacturer servers. This would effectively place vehicle manufacturers in control of the burgeoning ‘automotive big data’.

Security concerns, such as reducing the risk of car hacking), are cited as a rationale, although many perceive this as a commercially motivated move. Whether this trend gains traction remains to be seen, but it has the potential to significantly disrupt the market for third-party OBDII services.

OBDII Future: Electric Vehicles and potential restrictions on data access through the OBDII connector.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

Our comprehensive ‘Ultimate CAN Guide’ provides 12 simple introductions in one 160+ page PDF:

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBDII Standards and CAN Bus Integration

On-board diagnostics, specifically OBDII, functions as a higher-layer protocol, similar to a language used for communication. In contrast, CAN bus is the communication method, analogous to a telephone line. This places OBDII in a category with other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

The OBDII standards specifically define the OBDII connector, the lower-layer communication protocols, OBDII Parameter IDs (PIDs), and other critical aspects of the diagnostic system. Understanding how OBDII uses CAN bus is essential, as CAN bus is the most prevalent physical layer for OBDII communication in modern vehicles.

These standards can be visualized using the 7-layer OSI model, which helps to organize the different aspects of communication. In the following sections, we will focus on the most pertinent standards within this framework.

Looking at the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in both the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5, as well as SAE J1962 and ISO 15031-3. These ISO and SAE standards ensure that OBDII over CAN bus communication is standardized and reliable.

OBDII vs. CAN Bus: Illustrating the OSI 7-Layer Model, ISO 15765, and ISO 11898 standards in automotive communication.

OBDII Connector Pinout: Socket Female Type A DLC (Data Link Connector) diagram.

The OBDII Connector [SAE J1962 / ISO 15031-3] and CAN Bus Pins

The 16-pin OBDII connector is the gateway to accessing your car’s diagnostic data. It is meticulously defined by the SAE J1962 / ISO 15031-3 standards. For OBDII CAN bus systems, specific pins on this connector are dedicated to CAN communication.

The illustration provides an example of a Type A OBDII pin connector, also often referred to as the Data Link Connector (DLC).

Key aspects of the OBDII connector to note:

The connector is generally located near the steering wheel, but it can sometimes be hidden within the dashboard or console area.
Pin 16 is designed to supply battery power, often remaining active even when the ignition is turned off. This constant power supply is crucial for certain diagnostic functions and data logging.
The specific OBDII pinout configuration is dependent on the communication protocol used by the vehicle.
In systems utilizing CAN bus as the lower-layer protocol, which is increasingly common, pins 6 (CAN-High, CAN-H) and 14 (CAN-Low, CAN-L) are typically the designated pins for CAN bus communication. These pins are essential for OBDII CAN bus data exchange.

OBDII Connector Types: A vs. B and CAN Bus Considerations

In practical applications, you may encounter both Type A and Type B OBDII connectors. Type A connectors are most commonly found in passenger cars and light-duty vehicles, while Type B connectors are more prevalent in medium and heavy-duty vehicles. Understanding the differences is important, especially when working with OBDII CAN bus systems in different vehicle classes.

As shown in the illustration, both connector types share a similar OBDII pinout structure but differ primarily in their power supply outputs. Type A typically provides a 12V power supply, whereas Type B is designed for 24V systems, common in trucks and buses. Furthermore, the CAN bus baud rate can also vary. Cars generally use 500K baud, while heavy-duty vehicles often use 250K baud, although newer heavy-duty vehicles may also support 500K. Therefore, when dealing with OBDII CAN bus, always verify the correct baud rate for the vehicle type.

A key physical difference to distinguish between the two types of OBDII sockets is that the Type B OBDII connector features an interrupted groove in the middle. This design feature ensures that a Type B OBDII adapter cable is universally compatible with both Type A and Type B sockets, while a Type A adapter will only fit into a Type A socket. This physical incompatibility is a crucial safety and compatibility feature in OBDII CAN bus applications across different vehicle types.

OBDII Connector Types A and B: Illustrating differences, voltage (12V/24V), and SAE J1962 standards for cars, vans, and trucks.

OBDII vs. CAN Bus: Highlighting the ISO 15765 standard for CAN bus integration in On-Board Diagnostics.

OBDII and CAN Bus: ISO 15765-4 Standards

Since 2008, CAN bus has become the mandatory lower-layer protocol for OBDII in all vehicles sold in the US, as mandated by ISO 15765. This standard is fundamental to understanding OBDII CAN bus communication.

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 reliable diagnostic communication. These specifications are crucial for interoperability in OBDII CAN bus systems.

Specifically, ISO 15765-4 standardizes the CAN interface for diagnostic test equipment, focusing on the physical layer, data link layer, and network layer. The key specifications include:

The CAN bus bit rate must be either 250K or 500K. This standardized bit rate ensures compatibility across different diagnostic tools and vehicle ECUs.
Both 11-bit and 29-bit CAN identifiers are permitted. This flexibility allows for both standard and extended CAN addressing schemes within OBDII implementations.
Specific CAN IDs are reserved and utilized for OBD requests and responses. These standardized IDs ensure that diagnostic tools can correctly address and communicate with the vehicle’s diagnostic system.
The diagnostic CAN frame data length is fixed at 8 bytes. This fixed length simplifies data handling and processing in diagnostic communication.
The OBDII adapter cable connecting the diagnostic tool to the vehicle must not exceed 5 meters in length. This limitation helps maintain signal integrity and reliable communication.

OBDII CAN Identifiers: 11-bit and 29-bit Addressing

All OBDII communication, especially OBDII CAN bus communication, is structured around a request and response message exchange.

In most passenger vehicles, 11-bit CAN IDs are employed for OBDII communication. Within this framework, the ‘Functional Addressing’ ID is 0x7DF. This ID is used for broadcasting a request to all OBDII-compatible Electronic Control Units (ECUs) in the vehicle, asking if they have data to report for the requested parameter, as defined in ISO 15765-4. In contrast, CAN IDs in the range of 0x7E0 to 0x7E7 are reserved for ‘Physical Addressing’ requests. These are used for direct communication with specific ECUs, although they are less commonly used in typical OBDII diagnostics.

ECUs respond using 11-bit IDs in the range of 0x7E8 to 0x7EF. The most frequently used response ID is 0x7E8, typically originating from the ECM (Engine Control Module). Another common response ID is 0x7E9, often from the TCM (Transmission Control Module). These standardized CAN IDs are fundamental to OBDII CAN bus communication and diagnostics.

In some vehicle categories, particularly vans and light, medium, and heavy-duty vehicles, OBDII communication may utilize extended 29-bit CAN identifiers instead of the standard 11-bit IDs. This is an important distinction in OBDII CAN bus implementations across different vehicle types.

In 29-bit CAN systems, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

When a vehicle responds in a 29-bit CAN system, the response IDs range from 0x18DAF100 to 0x18DAF1FF, with typical examples being 0x18DAF110 and 0x18DAF11E. The response ID is also sometimes represented in the ‘J1939 PGN’ format. Specifically, PGN 0xDA00 (55808) is used, which in the J1939-71 standard is reserved for ISO 15765-2. This illustrates the interrelation of different automotive communication standards and protocols in OBDII CAN bus systems.

OBDII Protocol Request and Response Frames: Illustrating PID data parameter exchange in OBDII communication.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBDII vs. Proprietary CAN Bus: Contrasting standardized OBDII CAN data with OEM-specific CAN bus data.

OBDII CAN Bus vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) do not fundamentally depend on OBDII for their operational functions. Instead, each Original Equipment Manufacturer (OEM) develops and implements their own proprietary CAN protocols for internal vehicle communication. These OEM-specific CAN protocols are often unique to a particular vehicle brand, model, and production year. If you are not the OEM, interpreting this proprietary CAN data is typically not possible without significant reverse engineering efforts. Understanding the distinction between OBDII CAN bus and proprietary CAN is vital for advanced automotive diagnostics and data analysis.

If you connect a CAN bus data logger to your vehicle’s OBDII connector, you might observe the OEM-specific CAN data being transmitted. This data is usually broadcast at a high rate, often 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ module is implemented. This gateway restricts access to the proprietary CAN data through the OBDII connector and primarily enables standardized OBDII communication. Therefore, while the OBDII connector physically interfaces with the CAN bus, it often provides a filtered view, primarily for OBDII diagnostic data, not the full spectrum of proprietary vehicle CAN data. This is a key aspect of modern OBDII CAN bus architecture.

In essence, think of OBDII as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol. It’s a standardized diagnostic interface layered on top of the vehicle’s underlying communication network, which is often CAN bus but may also include proprietary protocols.

Bit-rate and CAN ID Validation in OBDII CAN Bus Systems

As previously discussed, OBDII CAN bus systems may utilize one of two bit rates (250K or 500K) and either 11-bit or 29-bit CAN ID lengths. This results in a total of four potential combinations for communication settings. In contemporary vehicles, the most common configuration is 500K bit rate and 11-bit CAN IDs. However, external diagnostic tools should systematically verify these parameters to ensure correct communication. Proper bit rate and CAN ID validation is crucial for reliable OBDII CAN bus diagnostics.

ISO 15765-4 provides recommendations for establishing a systematic initialization sequence to determine the correct combination of bit rate and CAN ID length for a given vehicle. This process is illustrated in a flowchart. The method relies on the fact that OBDII-compliant vehicles are required to respond to a specific mandatory OBDII request (details in the OBDII PID section). It also leverages the principle that transmitting data at an incorrect bit rate will result in CAN error frames, which can be detected by diagnostic tools. This validation process is essential for establishing robust OBDII CAN bus communication.

More recent versions of ISO 15765-4 acknowledge that vehicles might support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than the traditional OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBDII/OBDonEDS (defined by ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (defined by ISO 14229, ISO 27145-3/SAE J1979-2). Understanding the distinction between OBDonEDS and OBDonUDS is important for advanced OBDII CAN bus diagnostics, especially in newer vehicle models.

To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool may send additional request messages. Specifically, it can send UDS requests using 11-bit or 29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles that support OBDonUDS are required to have ECUs that respond to this specific DID. This test helps to accurately identify the OBD communication protocol in use.

In practice, OBDonEDS (also known as OBDII, SAE OBD, EOBD, or ISO OBD) is predominantly used in most non-electric vehicles today. WWH-OBD, on the other hand, is primarily found in EU trucks and buses. This protocol landscape is important to consider when working with OBDII CAN bus systems across different vehicle types and regions.

OBDII Bit-rate and CAN ID Validation: Flowchart illustrating the ISO 15765-4 validation process for OBDII CAN bus communication parameters.

OBDII Standards: Overview of five lower-layer protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBDII Protocols: Including CAN Bus

Today, CAN bus (ISO 15765) serves as the primary lower-layer protocol for OBDII in the vast majority of vehicles. This is a critical point when considering is OBDII CAN bus. For most modern cars, the answer is yes, CAN bus is the underlying communication network for OBDII.

However, when examining older vehicles (pre-2008), it’s beneficial to be aware of the other four lower-layer protocols that were previously used as the basis for OBDII. It’s also useful to note the pinouts of the OBDII connector, which can sometimes indicate the protocol used in older vehicles. While OBDII CAN bus is dominant now, these older protocols represent the history of OBDII communication.

The five lower-layer OBDII protocols include:

ISO 15765 (CAN bus): As mentioned, this is mandatory in US vehicles since 2008 and is now the most prevalent protocol in use globally. When people ask is OBDII CAN bus, they are usually referring to vehicles using this standard.
ISO14230-4 (KWP2000): The Keyword Protocol 2000 was commonly used in vehicles manufactured around 2003, particularly in Asia.
ISO 9141-2: This protocol was used in European, Chrysler, and Asian vehicles in the period of 2000-2004.
SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM – Pulse Width Modulation): Predominantly found in older Ford vehicles.

Transporting OBDII Messages via ISO-TP [ISO 15765-2] over CAN Bus

All OBDII data, when transmitted over CAN bus, utilizes a transport protocol known as ISO-TP (ISO 15765-2). This protocol is essential for OBDII CAN bus communication as it enables the transmission of data payloads that exceed the standard 8-byte limit of a CAN frame. This capability is particularly necessary in OBDII for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 provides mechanisms for segmentation, flow control, and reassembly of these larger messages. For a more detailed understanding of ISO-TP, refer to introductions to UDS.

However, it’s important to note that in many cases, OBDII data can fit within a single CAN frame. In such scenarios, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In a Single Frame, the first data byte, known as the PCI (Protocol Control Information) field, contains the payload length (excluding any padding). This leaves 7 bytes within the CAN frame’s data field for the actual OBDII-related communication. Therefore, even in OBDII CAN bus, not all communication requires multi-frame transport, and Single Frame messages are frequently used for shorter data exchanges.

ISO 15765-2 ISO-TP OBDII Frame Types: Illustrating Single Frame, First Frame, Consecutive Frame, and Flow Control frame types used in OBDII communication over CAN bus.

The OBDII Diagnostic Message Structure [SAE J1979, ISO 15031-5] in CAN Bus

To better grasp how OBDII functions over CAN bus, let’s examine a raw ‘Single Frame’ OBDII CAN message. In a simplified view, an OBDII message is composed of a CAN identifier, a data length indicator (PCI field), and the actual data payload. The data payload is further structured into components: Mode, Parameter ID (PID), and data bytes. Understanding this structure is key to deciphering OBDII CAN bus communication.

OBDII PIDs: OBDII Message Structure Breakdown Explained, showing Mode, PID, Identifier, and Data Bytes.

Example: OBDII Request and Response Sequence over CAN Bus

Before we delve into each component of the OBDII message, let’s consider a practical example: requesting and receiving the ‘Vehicle Speed’ parameter. This example illustrates the request-response nature of OBDII CAN bus communication.

In this scenario, an external diagnostic tool initiates communication by sending a request message to the vehicle. This request message is transmitted with CAN ID 0x7DF and contains 2 payload bytes: Mode 0x01 and PID 0x0D. The Mode 0x01 indicates a request for current data, and PID 0x0D specifically requests vehicle speed.

The vehicle’s ECU then responds to this request. The response message is sent with CAN ID 0x7E8 and contains 3 payload bytes. These bytes include the response to the requested mode (0x41, which is 0x01 + 0x40) and the vehicle speed data. In this example, the 4th byte of the CAN data field is 0x32. Converting 0x32 from hexadecimal to decimal gives 50.

By consulting the OBDII PID decoding rules for PID 0x0D, we can determine that this value represents the vehicle speed in km/h. Therefore, the physical value of 50 corresponds to a vehicle speed of 50 km/h. This example clearly demonstrates the request-response mechanism and data interpretation in OBDII CAN bus diagnostics.

OBDII Request 7DF and Response 7E8: Example of CAN bus communication for vehicle speed data.

OBDII PID Example: Vehicle Speed PID 0D, illustrating the data bytes and their interpretation.

OBDII Services Modes: Overview of the 10 OBDII diagnostic services (modes) including current data, freeze frame, and clear DTC.

The 10 OBDII Services (or Modes) in CAN Bus Diagnostics

There are a total of 10 standardized OBDII diagnostic services, often referred to as modes. These services define the type of diagnostic information being requested or provided in OBDII CAN bus communication. Mode 0x01 is used to request current, real-time data parameters, while other modes are designed for accessing and managing Diagnostic Trouble Codes (DTCs) or retrieving freeze frame data.

It’s important to note that vehicles are not required to support all 10 OBDII modes. Furthermore, manufacturers may implement additional modes beyond these 10 standardized ones, known as OEM-specific OBDII modes. This variability is something to consider when working with OBDII CAN bus across different vehicle makes and models.

In OBDII messages, the mode is identified in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01 for Mode 1). However, in a response message, a value of 0x40 is added to the requested mode (e.g., a response to Mode 0x01 will start with 0x41). This systematic approach helps in easily distinguishing between requests and responses in OBDII CAN bus data streams.

OBDII Parameter IDs (PIDs) and CAN Bus Data

Within each OBDII mode, there are Parameter IDs (PIDs). PIDs are codes used to specify the particular data parameter being requested or reported within a given mode. Understanding PIDs is crucial for effective OBDII CAN bus diagnostics and data interpretation.

For instance, Mode 0x01, which is used for requesting current data, includes approximately 200 standardized PIDs. These PIDs cover a wide range of real-time vehicle data, such as speed, RPM, engine load, and fuel level. However, it’s important to recognize that a vehicle is not obligated to support all of the standardized OBDII PIDs within a mode. In practice, most vehicles only support a subset of the available PIDs. The specific PIDs supported can vary based on vehicle manufacturer, model, and year.

In this context, one PID stands out as particularly significant: PID 0x00 in Mode 0x01.

Specifically, if an emissions-related ECU supports any OBDII services at all, it is mandated to support Mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds by providing information on whether it supports PIDs in the range of 0x01 to 0x20. This makes PID 0x00 invaluable as a fundamental ‘OBDII compatibility test’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine the support status for the remaining PIDs within Mode 0x01, in sequential blocks of 32 PIDs. This systematic approach enables diagnostic tools to efficiently discover the range of supported PIDs in a vehicle’s OBDII CAN bus system.

OBDII Protocol Request and Response Frames: Detailed view of PID data parameters in OBDII communication.

OBD2 PID overview tool
OBDII PID Overview Tool: Interface of a tool displaying OBDII PID service 01 parameters.

Tip: Using an OBDII PID Overview Tool for CAN Bus Diagnostics

The appendices of both SAE J1979 and ISO 15031-5 standards provide essential scaling information for standard OBDII PIDs. This scaling data is crucial as it enables you to convert the raw data bytes received from the vehicle into meaningful physical values. This process of converting raw data to physical values is fundamental to interpreting OBDII CAN bus data and is explained in detail in introductions to CAN bus.

If you need to quickly look up the details of a Mode 0x01 PID, consider using an OBDII PID overview tool. These tools are designed to assist you in constructing OBDII request frames and in dynamically decoding the OBDII responses you receive from the vehicle. This can significantly simplify the process of working with OBDII CAN bus data.

OBDII PID overview tool
Link to an OBDII PID overview tool for quickly accessing OBDII parameter information.

How to Log and Decode OBDII Data from CAN Bus

In this section, we will provide a practical example of how to log OBDII data using a CANedge CAN bus data logger. The CANedge is a versatile tool that allows you to configure custom CAN frames for transmission, making it well-suited for OBDII logging in OBDII CAN bus systems.

Once configured, the CANedge device can be easily connected to your vehicle via an OBDII-DB9 adapter cable. This setup enables you to capture and record OBDII data directly from your vehicle’s CAN bus network.

OBDII PID Data Logger Request: Illustrating request CAN ID 7DF and response 7E8 in an OBDII data logging setup.

OBD2 Supported PIDs Test Supported PIDs Test: Reviewing responses to ‘Supported PIDs’ requests using asammdf software.

Review supported PIDs via OBD2 lookup tool

Step #1: Testing Bit-rate, CAN IDs, and Supported PIDs in your OBDII CAN Bus System

As previously discussed, ISO 15765-4 outlines a procedure to determine the correct bit rate and CAN IDs used by a specific vehicle’s OBDII CAN bus system. You can use the CANedge data logger to perform these tests, as described below (refer to the CANedge Intro for detailed instructions):

Test Bit Rate: Begin by sending a CAN frame at a bit rate of 500K. Check if the transmission is successful. If not, retry with 250K. Successful transmission at one of these rates indicates the correct bit rate for the vehicle’s CAN bus.
Use Identified Bit Rate: Once you have determined the correct bit rate, use this rate for all subsequent OBDII communication with the vehicle.
Send ‘Supported PIDs’ Requests: Transmit multiple ‘Supported PIDs’ requests (Mode 0x01 PID 0x00) and carefully review the responses received from the vehicle.
Determine CAN ID Type: Based on the response IDs, you can determine whether the vehicle is using 11-bit or 29-bit CAN identifiers for OBDII communication.
Identify Supported PIDs: Analyze the response data to ascertain which OBDII PIDs are supported by the vehicle’s ECUs.

We provide pre-configured settings (‘plug & play configs’) to streamline these initial tests, making it easier to set up your CANedge for OBDII CAN bus diagnostics.

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

As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request, especially when using the functional addressing request ID 0x7DF. This is because the 0x7DF request polls all ECUs for a response. Since all OBDII/OBDonEDS-compliant ECUs are mandated to support service 0x01 PID 0x00, you often see numerous responses to this particular PID. As you proceed with subsequent ‘Supported PIDs’ requests (e.g., for PID ranges 0x20-0x3F, 0x40-0x5F, etc.), you will typically observe fewer ECUs responding. It’s also worth noting that the ECM ECU (0x7E8), in the example shown, supports all the PIDs that are supported by other ECUs. This observation suggests that to reduce CAN bus load, you could specifically target the ECM for subsequent communication by switching to ‘Physical Addressing’ CAN IDs (e.g., 0x7E0) for future requests. This targeted approach is beneficial for efficient OBDII CAN bus data acquisition.

Step #2: Configuring OBDII PID Requests for CAN Bus Logging

After successfully testing and identifying the supported OBDII PIDs, bit rate, and CAN IDs for your vehicle, you are ready to configure your CANedge device to specifically request the PIDs of interest. This step involves setting up a transmit list with the desired PIDs. Effective configuration is key to focused OBDII CAN bus data logging.

Here are some important considerations for configuring your OBDII PID requests:

CAN IDs: To minimize bus load and avoid receiving multiple responses for each request, consider switching to ‘Physical Addressing’ request IDs, such as 0x7E0, for subsequent PID requests. This targets specific ECUs, reducing unnecessary responses on the OBDII CAN bus.
Spacing: Implement a delay of 300-500 milliseconds between each OBDII request transmission. Sending requests too rapidly (spamming the ECUs) can lead to communication issues, potentially causing the ECUs to not respond. Proper spacing ensures reliable OBDII CAN bus communication.
Battery Drain: To prevent excessive battery drain, particularly during prolonged logging sessions, utilize triggers to stop PID requests when the vehicle is inactive. This avoids continuously ‘waking up’ ECUs and consuming vehicle battery power when no data is needed.
Filters: If your vehicle also outputs OEM-specific CAN data alongside OBDII data, it’s advisable to add filters to your CANedge configuration. Filters will ensure that you only record OBDII responses, streamlining your data logs and focusing on the relevant diagnostic information. Filtering is crucial for managing data in complex OBDII CAN bus environments.

Once these configurations are in place, your CANedge device is fully prepared to log raw OBDII data from your vehicle’s CAN bus efficiently and effectively.

obd2-transmit-list-example-canedge
OBDII Transmit List Example: Configuration example of an OBDII PID request transmit list for CANedge.

OBD2 data decoded visual plot asammdf CAN bus DBC file
OBDII Data Decoded: Visual plot of decoded OBDII data using asammdf software and a CAN bus DBC file.

Step #3: DBC Decoding of Raw OBDII CAN Bus Data

Finally, to make your logged OBDII data usable for analysis and visualization, you need to decode the raw CAN bus data into ‘physical values’. This involves converting the raw hexadecimal data into meaningful units like kilometers per hour (km/h) or degrees Celsius (°C). DBC decoding is essential for interpreting OBDII CAN bus data effectively.

The necessary decoding information is specified in the ISO 15031-5/SAE J1979 standards and is also available in resources like Wikipedia. For convenience, a free OBDII DBC file is provided. This DBC file simplifies the process of DBC decoding raw OBDII data in most CAN bus software tools.

It’s important to note that decoding OBDII data is somewhat more complex than decoding standard CAN signals. This complexity arises because different OBDII PIDs are often transmitted using the same CAN ID (e.g., 0x7E8 for responses from the ECM). Consequently, the CAN ID alone is not sufficient to uniquely identify the specific signals encoded in the payload.

To address this, the decoding process must consider not only the CAN ID but also the OBDII mode and OBDII PID to accurately identify each signal. This technique is a form of multiplexing known as ‘extended multiplexing‘, which can be effectively implemented using DBC files. DBC files allow you to define decoding rules that take into account the CAN ID, mode, and PID, enabling accurate interpretation of OBDII CAN bus data.

CANedge: Your OBDII CAN Bus Data Logger

The CANedge provides a user-friendly solution for recording OBDII data directly to an 8-32 GB SD card. To start logging, simply connect the CANedge to your vehicle, such as a car or truck. For data analysis and decoding, you can utilize free software tools and APIs in conjunction with the provided OBDII DBC file. CANedge simplifies OBDII CAN bus data logging and analysis.

OBDII logger intro CANedge
Links to OBDII logger introduction and CANedge product information for OBDII CAN bus data logging solutions.

OBDII Multi-Frame Examples [ISO-TP over CAN Bus]

All OBDII data communication, especially over CAN bus, relies on the ISO-TP (transport protocol) as defined in ISO 15765-2. The examples discussed so far have primarily focused on single-frame communication. In this section, we will explore examples of multi-frame communication, which is essential for transmitting larger OBDII messages over OBDII CAN bus.

Multi-frame OBDII communication necessitates the use of flow control frames. For a detailed explanation of flow control in ISO-TP, refer to introductions to UDS. In practical OBDII implementations, flow control can often be managed by transmitting a static flow control frame approximately 50 milliseconds after the initial request frame. An example of this configuration is shown in the CANedge configuration settings.

Furthermore, handling multi-frame OBDII responses requires CAN software and API tools that are ISO-TP aware, such as the CANedge MF4 decoders. These tools are capable of correctly processing and reassembling multi-frame messages in OBDII CAN bus data streams.

OBD2-multi-frame-request-message-vehicle-identification-number
OBDII Multi-Frame Request: Example of a multi-frame request message for Vehicle Identification Number (VIN) retrieval in OBDII.

Example 1: Retrieving Vehicle Identification Number (VIN) via OBDII CAN Bus

The Vehicle Identification Number (VIN) is a crucial piece of information for various automotive applications, including telematics and diagnostics. For a deeper understanding of VIN and its uses in diagnostics, refer to introductions to UDS. To retrieve the VIN from a vehicle using OBDII requests over CAN bus, you typically use Mode 0x09 and PID 0x02. This process involves multi-frame communication in OBDII CAN bus systems.

VIN Vehicle Identification Number OBD2 Example multi-frame

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

In response, the vehicle’s ECU sends a First Frame message. This First Frame contains the PCI, the total length of the multi-frame message (0x014, which is 20 bytes in decimal), the mode (0x49, indicating a response to Mode 0x09), and the PID (0x02). Following the PID, the First Frame includes the byte 0x01, which represents the Number Of Data Items (NODI). In this case, NODI is 1, indicating a single VIN is being returned (refer to ISO 15031-5 / SAE J1979 for more details on NODI). The subsequent 17 bytes in the multi-frame message constitute the VIN itself. These VIN bytes are typically in hexadecimal format and need to be converted to ASCII characters to obtain the human-readable VIN. The methods for this HEX to ASCII conversion are discussed in introductions to UDS. This example demonstrates the multi-frame request-response sequence for VIN retrieval in OBDII CAN bus.

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

OBDII standard allows external diagnostic tools to request up to 6 Mode 0x01 OBDII PIDs in a single request frame. This capability can enhance data acquisition efficiency in OBDII CAN bus systems. The vehicle’s ECU is expected to respond with data for all supported PIDs from the requested set, omitting data for any unsupported PIDs. If necessary, the response may span multiple frames as per ISO-TP.

This multi-PID request feature is a powerful way to collect a larger volume of OBDII data in a more efficient manner. However, it also introduces complexities in data interpretation. The signal encoding in the response is specific to the method of request, which can make the use of generic OBDII DBC files challenging for these use cases. Therefore, while technically feasible, using multi-PID requests is generally not recommended for standard OBDII data logging practices.

Below is an example trace illustrating a multi-PID request and response scenario in OBDII CAN bus:

Requesting multiple PIDs in one request

The multi-frame response structure in a multi-PID request is similar to the VIN example. However, with multi-PID responses, the payload includes not only the data values but also the PIDs corresponding to each data value. In the example shown, the PIDs in the response are ordered in a sequence that mirrors their order in the request. While this ordering is common in practice, it is not strictly mandated by the ISO 15031-5 standard.

Decoding multi-PID responses using generic DBC files is practically very difficult. Therefore, it is generally not recommended to use this approach for standard data logging unless you are working with a specialized tool that has built-in support specifically designed for handling multi-PID responses. In essence, you would be dealing with a more complex form of extended multiplexing, where multiple instances of multiplexing occur within the payload. Further complicating matters, your DBC file would need to account for the specific payload position of each PID, which makes it very challenging to create a generalized DBC file that works across different vehicles that may vary in their supported PIDs.

The complexity escalates further if you are sending multiple such multi-PID requests, as you would then lack a straightforward method to uniquely identify different response messages from each other.

Workarounds could involve using custom scripts in conjunction with recording the transmit messages from your testing tool. In such a setup, a script could be designed to interpret the response message in context with the preceding request message. However, such script-based approaches are generally difficult to manage and scale, especially when dealing with large volumes of data or multiple vehicle types in OBDII CAN bus data logging scenarios.

Example 3: Retrieving OBDII Diagnostic Trouble Codes (DTCs) over CAN Bus

OBDII provides a standardized way to request emissions-related Diagnostic Trouble Codes (DTCs). This is achieved using Mode 0x03, which corresponds to ‘Show stored Diagnostic Trouble Codes’. When requesting DTCs, no PID is included in the request message. The targeted ECU(s) will respond with the number of DTCs currently stored in their memory, which could be zero if no DTCs are present. Each DTC is represented by 2 data bytes. When more than two DTCs are stored, multi-frame responses become necessary due to the 8-byte payload limit of a CAN frame. This example illustrates DTC retrieval in OBDII CAN bus systems.

The 2-byte DTC value is typically structured into two parts, as defined in ISO 15031-5 and ISO 15031-6. The first 2 bits of the first byte define the ‘category’ of the DTC (e.g., Powertrain, Chassis, Body, Network). The remaining 14 bits of the 2-byte DTC code define a 4-digit code, which is usually displayed in hexadecimal format. For decoding and interpretation, the 4-digit hexadecimal code needs to be converted. Once decoded, the DTC values can be looked up in various OBDII DTC lookup tools, such as repairpal.com, to understand the specific fault indicated by each DTC.

The example below illustrates a scenario where a request for DTCs is sent to an ECU that has 6 DTCs stored. The response is a multi-frame message containing the 6 DTC codes, each represented by 2 bytes, following the ISO-TP protocol for OBDII CAN bus communication.

OBDII DTC Decoding: Example of Diagnostic Trouble Code (DTC) decoding and DBC interpretation.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

OBDII Data Logging – Use Case Examples for CAN Bus Applications

OBDII data, particularly when accessed and logged via CAN bus, offers valuable insights and data for a wide range of applications, especially for cars and light trucks. OBDII CAN bus data logging is utilized across various sectors for diverse purposes.

[

Logging Data from Cars for CAN Bus Analysis

OBDII data logged from cars can be instrumental in various applications, including fuel efficiency optimization, driving behavior analysis, prototype component testing, and insurance telematics. Analyzing OBDII CAN bus data provides valuable insights for these use cases.

obd2 logger
OBDII Data Logger: Link to OBDII data logger solutions for car and vehicle applications.

[

Real-Time Car Diagnostics via OBDII CAN Bus Streaming

OBDII interfaces, especially those capable of CAN bus communication, can be used to stream human-readable OBDII data in real-time. This real-time data streaming is invaluable for diagnosing vehicle issues, monitoring performance, and conducting live tests. Real-time OBDII CAN bus data is crucial for immediate diagnostics.

obd2 streaming
OBDII Streaming: Link to OBDII streaming interfaces for real-time car diagnostics.

[

Predictive Maintenance Using OBDII CAN Bus Data

Cars and light trucks equipped with IoT-enabled OBDII loggers can be continuously monitored via the cloud. Analyzing the logged OBDII CAN bus data allows for predictive maintenance, helping to anticipate and prevent potential breakdowns. Predictive maintenance based on OBDII CAN bus data minimizes downtime and maintenance costs.

predictive maintenance
Predictive Maintenance: Link to predictive maintenance solutions using OBDII CAN bus data and IoT.

[

Vehicle Black Box Logger with OBDII CAN Bus

An OBDII logger, functioning as a ‘black box’ for vehicles or equipment, can provide critical data for various purposes, including dispute resolution, accident analysis, and in-depth diagnostics. In this context, OBDII CAN bus logging serves as a reliable source of vehicle data.

can bus blackbox
CAN Bus Black Box: Link to CAN bus black box data logger solutions for vehicle data recording.

Do you have a specific OBDII data logging use case in mind? Feel free to reach out for a free consultation!

For more introductory guides and tutorials, explore our guides section or download the comprehensive ‘Ultimate Guide’ PDF.

Need to log or stream OBDII data?

Get your OBDII data logger today!

Buy now Contact us
Buy Now / Contact Us: Call to action buttons to purchase OBDII data loggers or contact for further assistance.

Recommended for you

[ OBDII DATA LOGGER: EASILY LOG & CONVERT OBDII DATA

[ CANedge2 – Dual CAN Bus Telematics Dongle CANEDGE2 – PRO CAN IoT LOGGER

[ [