OBD2: What Is It? - Your Guide to On-Board Diagnostic Systems

Looking for a straightforward and practical explanation of OBD2?

This guide provides a comprehensive introduction to the On-Board Diagnostic (OBD2) protocol, covering everything from the OBD2 connector and OBD2 Parameter IDs (PIDs) to its connection with the CAN bus.

Note: This is designed as a practical introduction, so you’ll also learn how to request and interpret OBD2 data, explore key use cases for logging, and gain valuable practical tips.

Discover why this is considered the go-to OBD2 tutorial.

You can also watch our introductory OBD2 video above – or download it as a PDF.

Decoding OBD2: What is This Vehicle Diagnostic System?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that enables access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 port.

You’ve likely already encountered OBD2 in action:

Ever seen the check engine light illuminate on your dashboard?

That’s your vehicle signaling a potential issue. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem.

To do this, the mechanic connects the OBD2 reader to the OBD2 16-pin connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain a wealth of information, including speed, fuel level, and Diagnostic Trouble Codes (DTCs), which significantly speeds up the troubleshooting process.

OBD2 Compatibility: Does Your Car Have It?

In most cases, yes!

The vast majority of modern non-electric vehicles are equipped with OBD2 and typically operate on the CAN bus system. However, for older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 protocol. A reliable way to check for OBD2 compliance is based on where and when your car was originally purchased as new:

A Look at OBD2 History and Evolution

The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emissions monitoring.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, defining DTCs and the OBD connector across different vehicle manufacturers through the SAE J1962 standard.

The implementation of the OBD2 standard unfolded gradually:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline-powered cars.
2003: Extended to diesel cars in the EU (known as EOBD).
2005: OBD2 requirement expanded to medium-duty vehicles in the US.
2008: US vehicles were required to adopt ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 mandate extended to heavy-duty vehicles in the US.

The Future Landscape of OBD2

OBD2 is expected to remain relevant, but its form and function are evolving.

Here are some significant trends to consider:

Initially designed for emissions control and testing, legislated OBD2 has a notable exception: electric vehicles. EVs are not obligated to support OBD2 in any form. This is evident in the fact that most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This generally makes accessing data from electric vehicles challenging, except in cases where decoding methods have been reverse-engineered. Examples include our case studies on electric cars such as Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary and have limitations in data richness and lower-layer protocols. In response, newer alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to modernize OBD communication by using the UDS protocol as a base. For more on these protocols, see our introduction to UDS.

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

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

OBD3 concept involves adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.

Many current devices already support CAN or OBD2 data transfer via WiFi/cellular, like the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.

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

Originally designed for stationary emission controls, OBD2 is now widely used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is seeking to restrict this access:

OBD was intended for car servicing in repair shops, not for third parties to build a data-driven economy based on access through this interface.

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests disabling OBD2 functionality during driving and instead centralizing data collection through manufacturer servers. This would give manufacturers control over the burgeoning field of ‘automotive big data’.

Arguments for this shift often cite security benefits, such as reducing the risk of car hacking), although many view it 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 OBD2 services.

Deep Dive into CAN Bus – Get Our Ultimate Guide

Eager to become a CAN bus expert?

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

Download now

Understanding OBD2 Standards

On-board diagnostics, OBD2, is a higher-layer protocol – think of it as a language. CAN, on the other hand, is a communication method, similar to a phone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector, the underlying communication protocols, OBD2 Parameter IDs (PIDs), and more.

These standards can be organized using the 7-layer OSI model. In the following sections, we will focus on the most critical aspects.

In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standards defined for OBD in the USA (SAE) and Europe (ISO). Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides easy access to your vehicle’s data and is standardized under SAE J1962 / ISO 15031-3. It’s also sometimes called the Data Link Connector (DLC).

The illustration shows a typical Type A OBD2 pin connector. Key points to note:

The connector is usually located near the steering wheel, but it might be hidden from plain sight.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration varies depending on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.

OBD2 Connector Types: A vs. B

You might encounter both Type A and Type B OBD2 connectors. Type A is typically found in cars, while Type B is more common in medium and heavy-duty vehicles.

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

Visually, the Type B OBD2 connector has a distinctive interrupted groove in the middle, which helps differentiate it from Type A. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus: ISO 15765-4

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as per ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or 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-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.
OBD2 adapter cable length must not exceed 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication always involves a request-response message exchange.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs to see if they have data to report for the requested parameter (defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, though this is less common.

ECUs respond using 11-bit IDs from 0x7E8 to 0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

In some vehicles, especially vans and light, medium, and heavy-duty vehicles, OBD2 communication may use extended 29-bit CAN identifiers instead of 11-bit IDs.

For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses are sent with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is marked as ‘Reserved for ISO 15765-2’.

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your vehicle’s electronic control units (ECUs) operate using proprietary CAN protocols defined by the original equipment manufacturer (OEM), independently of OBD2. These OEM-specific CAN protocols are tailored to the specific vehicle brand, model, and year. Generally, this OEM data is inaccessible to those outside the manufacturer unless it is reverse engineered.

If you connect a CAN bus data logger to your car’s OBD2 port, you might observe OEM-specific CAN data, typically broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles employ a ‘gateway’ that restricts access to this CAN data through the OBD2 port, only allowing OBD2 communication.

In essence, think of OBD2 as a supplementary higher-layer protocol that operates alongside the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles commonly use 500K with 11-bit IDs. External tools should systematically verify these parameters.

ISO 15765-4 provides guidelines for an initialization sequence to determine the correct combination, illustrated in the flowchart. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rate transmissions will cause CAN error frames.

Newer versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, test tools may send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

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

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 (ISO 15765), older vehicles (pre-2008) may use one of four other protocols. Understanding these protocols and their pinouts can be useful for diagnosing older systems:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages (ISO 15765-2)

All OBD2 data is communicated over CAN bus using the ISO-TP transport protocol (ISO 15765-2). This protocol allows for the transmission of data payloads exceeding 8 bytes, which is necessary for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. More details can be found in 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). The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.

The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5

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

Example: OBD2 Request and Response

Before diving into the details of OBD2 messages, let’s consider a request-response example for ‘Vehicle Speed’.

An external diagnostic tool sends a request to the car with CAN ID 0x7DF, containing two payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and three payload bytes, including the vehicle speed value in the 4th byte, 0x32 (which is 50 in decimal).

By consulting the decoding rules for OBD2 PID 0x0D, we find that the physical value is 50 km/h.

Next, we’ll delve into OBD2 modes and PIDs in more detail.

The 10 OBD2 Services (Modes)

OBD2 includes 10 diagnostic services, also known as modes. Mode 0x01 is used to retrieve current real-time data, while others are used to access or clear diagnostic trouble codes (DTCs) or view freeze frame data.

Vehicles are not required to support all OBD2 modes and may also implement OEM-specific modes beyond these 10 standardized ones.

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

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs).

For instance, mode 0x01 contains approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle doesn’t have to support all PIDs within a mode. In practice, most vehicles support only a subset of the available PIDs.

One PID is particularly significant:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle’s ECU communicates which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental test for ‘OBD2 compatibility’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for the remaining mode 0x01 PIDs in ranges 0x21-0x40, 0x41-0x60, and so on, up to 0xE1-0x100.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which is essential for decoding the raw data into meaningful physical values (as explained in our CAN bus introduction).

If you need to look up a mode 0x01 PID, our OBD2 PID overview tool is a helpful resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Practical Guide: How to Log and Decode OBD2 Data

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

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging.

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

Verifying successful CAN frame transmission at 500K bit rate.

Reviewing responses to ‘Supported PIDs’ requests in asammdf.

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

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. You can perform these tests using the CANedge as follows (refer to the CANedge Intro for detailed instructions):

Send a CAN frame at 500K and check for successful transmission (if unsuccessful, try 250K).
Use the identified bit-rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine whether the vehicle uses 11-bit or 29-bit IDs based on the response IDs.
Identify supported PIDs from the response data.

We offer plug-and-play configurations to simplify these tests.

Most non-EV vehicles manufactured in 2008 or later support 40-80 PIDs, using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

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

Step #2: Configuring OBD2 PID Requests

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

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Introduce a delay of 300-500 ms between OBD2 requests to prevent overwhelming the ECUs.
Battery Drain: Utilize triggers to stop transmissions when the vehicle is inactive to avoid unnecessary ECU wake-up and battery drain.
Filters: Implement filters to record only OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data.

With these configurations in place, your CANedge device is ready to log raw OBD2 data.

Example CANedge OBD2 PID request list.

asammdf enabling DBC decoding and visualization of OBD2 data.

Step #3: DBC Decoding of Raw OBD2 Data

To effectively analyze and visualize your logged data, you’ll need to decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file to simplify DBC decoding of raw OBD2 data in most CAN bus software tools.

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

To address this, it’s necessary to use the CAN ID, OBD2 mode, and OBD2 PID together to identify the signal. This is a form of multiplexing, known as ‘extended multiplexing‘, which can be implemented using DBC files.

CANedge: Your OBD2 Data Logger

The CANedge simplifies recording OBD2 data onto an 8-32 GB SD card. Simply connect it to a vehicle to start logging and decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

OBD2 communication relies on the ISO-TP (transport protocol) as per ISO 15765-2. While most examples discussed so far involve single-frame communication, multi-frame communication is also crucial. Here are examples of multi-frame scenarios.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Analyzing multi-frame OBD2 responses necessitates CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.

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

The Vehicle Identification Number (VIN) is important for telematics, diagnostics, and more (see our UDS introduction for further information). To retrieve the VIN using OBD2 requests, you use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is 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 constitute the VIN, which can be converted from HEX to ASCII as described in our UDS introduction.

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

Diagnostic tools can request up to six mode 0x01 OBD2 PIDs in a single request frame. The ECU should respond with data for supported PIDs (omitting data for unsupported PIDs), possibly using multiple frames as per ISO-TP.

This feature enhances data collection efficiency and frequency, but the signal encoding becomes specific to the request method. This makes using generic OBD2 DBC files challenging for such cases. We generally advise against this method in practice. Below is an example trace of such communication:

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

Decoding these responses using generic DBC files is difficult. Thus, we do not recommend this approach for practical data logging unless using tools with specific built-in support. This scenario represents extended multiplexing with multiple instances throughout the payload, compounded by the challenge of creating a DBC file that accounts for PID-specific payload positions across different vehicles.

While custom scripts and recording of transmit messages could offer workarounds, such approaches are complex to scale. A script could interpret response messages in conjunction with request messages, but managing this at scale is generally difficult.

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. The target ECU(s) will respond with the number of stored DTCs (possibly zero if none are stored), 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 typically structured into two parts, as per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, while the remaining 14 bits form a 4-digit hexadecimal code, as shown in the visual. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

OBD2 Data Logging: Use Case Examples

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

OBD2 data from cars can be used to reduce fuel consumption, improve driving habits, test prototype components, and optimize insurance models.

OBD2 logger

Real-Time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data, useful for immediate vehicle issue diagnosis.

OBD2 streaming

Predictive Maintenance

Vehicles and light trucks can be monitored via IoT-enabled OBD2 loggers in the cloud to predict and prevent potential breakdowns.

Predictive maintenance

Vehicle Black Box Logger

An OBD2 logger can act as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution or detailed diagnostics.

CAN bus black box

Do you have an OBD2 data logging application? Contact us for a free consultation!

Explore more introductory guides in our guides section or download our ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN

OBD2: What Is It? – Your Guide to On-Board Diagnostic Systems

In this article