Understanding OBD2: Your Car's Diagnostic System Explained

Looking for a straightforward and practical introduction to OBD2?

This guide provides a clear explanation of the On-Board Diagnostics version 2 (OBD2) protocol, including the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.

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

Discover why this has become a highly recommended OBD2 tutorial.

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

What Exactly is OBD2?

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

You’ve likely already encountered OBD2 in action:

Have you ever seen the check engine light illuminate on your dashboard?

That’s your vehicle signaling that something is amiss. 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 16-pin OBD2 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 valuable information like speed, fuel level, or Diagnostic Trouble Codes (DTCs), which helps in faster and more accurate troubleshooting.

Is My Vehicle OBD2 Compatible?

In short: Most likely, yes!

The vast majority of modern non-electric vehicles are OBD2 compliant, and many operate on the CAN bus network. However, for older vehicles, even if a 16-pin OBD2 port is present, it might not actually support the OBD2 protocol. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:

A Brief History of OBD2

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

The OBD2 standard was further developed and recommended by the Society of Automotive Engineers (SAE), which standardized DTCs and the OBD connector across different vehicle manufacturers (SAE J1962).

From its Californian roots, the OBD2 standard gradually expanded:

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 in the US expanded to medium-duty vehicles.
2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 mandate in the US finally included heavy-duty vehicles.

The Future of OBD2

OBD2 is firmly established, but its evolution is ongoing. What does the future hold?

Here are some key trends to consider:

Originally conceived for emissions control and testing, regulatory OBD2 requirements have an interesting implication: electric vehicles (EVs) are not obligated to support OBD2 in any form. This is reflected 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 data decoding from EVs challenging, except in cases where reverse engineering efforts have yielded decoding rules. Examples include case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementation varies and faces limitations regarding data richness and underlying communication protocols. To address these issues, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to improve OBD communication by using the UDS protocol as a base. For more information on these protocols, refer to our introduction to UDS.

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

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

OBD3 envisions adding a small radio transponder (similar to those used for toll collection) to every car. This would allow the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks.

Many current devices already facilitate CAN or OBD2 data transfer via WiFi or cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

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

The OBD2 protocol was initially designed for static emissions testing.

However, today, OBD2 is widely used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers, and similar devices. Interestingly, the German car industry is seeking to restrict this access:

OBD was intended for vehicle servicing in repair shops, not for enabling 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 while driving and instead centralizing data collection on manufacturer servers. This would effectively place vehicle manufacturers in control of the burgeoning ‘automotive big data’ market.

The rationale often cited is security, such as mitigating the risk of car hacking, though many view it as a commercially motivated maneuver. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards Explained

On-board diagnostics, or OBD2, operates as a higher-layer protocol, much like a language. In contrast, CAN functions as the communication method, similar to a telephone line. This analogy positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects.

These standards can be mapped to the 7-layer OSI model, and the following sections will focus on the most significant ones.

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

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides straightforward access to your vehicle’s data and is detailed in the SAE J1962 / ISO 15031-3 standard.

The illustration shows a typical Type A OBD2 pin connector, also known as the Data Link Connector (DLC).

Key points about the OBD2 connector:

It’s generally located near the steering wheel, but can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration depends on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: A vs. B

In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is more typical in medium and heavy-duty vehicles.

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

To visually distinguish between the two, Type B OBD2 connectors feature an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable will be compatible with both Type A and 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 rates must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable must be no longer than 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit)

All OBD2 communication is based on request/response message exchanges.

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

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

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

The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.

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

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) do not depend on OBD2 for their core operations. Instead, each Original Equipment Manufacturer (OEM) develops its own proprietary CAN protocols for these functions. These CAN protocols can be unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is typically not possible without reverse engineering it.

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

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol.

Bit Rate and ID Validation

As mentioned, OBD2 can use one of two bit rates (250K, 500K) and either 11-bit or 29-bit CAN IDs, resulting in four potential combinations. In modern vehicles, 500K and 11-bit IDs are most common, but external tools should systematically verify this.

ISO 15765-4 offers guidelines for a systematic 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 mandatory OBD2 request (see the OBD2 PID section for details) and that using an incorrect bit rate will cause CAN error frames.

Newer versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS rather than 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 test for the ‘protocol’ type—OBDonEDS vs. OBDonUDS—a diagnostic tool may 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 must 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 cars 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 as per ISO 15765, especially in vehicles from 2008 onwards, it’s helpful to know the other four protocols used in older vehicles. The pinouts can also help identify which protocol your vehicle might be using.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most common protocol.
ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Primarily used in older General Motors vehicles.
SAE J1850 (PWM): Mostly found in older Ford vehicles.

Transporting OBD2 Messages via ISO-TP: ISO 15765-2

All OBD2 data communication over CAN bus utilizes the ISO-TP transport protocol (ISO 15765-2). This protocol enables the transmission of data payloads exceeding 8 bytes, which is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 manages segmentation, flow control, and reassembly of these larger messages. For more details, consult our introduction to UDS.

However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-related communication.

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

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

Example: OBD2 Request/Response

Before detailing each part of the OBD2 message, consider this example request and response for ‘Vehicle Speed’.

An external tool sends a request message to the vehicle with CAN ID 0x7DF, containing 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (decimal 50).

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

Next, we will explore OBD2 modes and PIDs in more detail.

The 10 OBD2 Services (Modes)

There are 10 defined OBD2 diagnostic services, often referred to as modes. Mode 0x01 is used to access current, real-time data, while others are used to manage diagnostic trouble codes (DTCs) or retrieve freeze frame data.

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

In OBD2 messages, the mode is specified in the second byte. In a request, the mode is included directly (e.g., 0x01), whereas in the 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 example, mode 0x01 contains approximately 200 standardized PIDs providing real-time data such as speed, RPM, and fuel level. However, a vehicle does not have to support all OBD2 PIDs within a given mode. In practice, most vehicles support only a subset of these.

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 ECU reports which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling you to decode the data into physical values (as explained in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data

This section provides a practical guide on 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 data logging.

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

You can send a CAN frame at 500K, then check if it is successfully sent

The responses to ‘Supported PIDs’ can be reviewed in asammdf

#1: Test Bit Rate, IDs, and Supported PIDs

As discussed, ISO 15765-4 outlines how to determine the bit rate and IDs used by a specific vehicle. You can test this with the CANedge as follows (refer to the CANedge Introduction for detailed instructions):

Send a CAN frame at 500K and verify successful transmission (if not, try 250K).
Use the identified bit rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and examine the responses.
Based on response IDs, determine whether 11-bit or 29-bit IDs are in use.
From the response data, identify the supported PIDs.

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

Most non-EV vehicles manufactured from 2008 onwards 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 polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses, especially to this PID. As evident, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Notably, the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by specifically targeting this ECU for responses using the ‘Physical Addressing’ CAN ID 0x7E0 for future communication.

#2: Configure OBD2 PID Requests

Now that you know your vehicle’s supported OBD2 PIDs, bit rate, and CAN IDs, you can configure your transmit list with the PIDs of interest.

Consider these points:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Insert 300-500 ms intervals between OBD2 requests to prevent ECU overload and ensure responses.
Battery Drain: Use triggers to halt transmission when the vehicle is inactive to avoid unnecessary ECU activation and battery drain.
Filters: Apply filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, streamlining data capture.

Once configured, your device is ready to efficiently log raw OBD2 data.

An example list of CANedge OBD2 PID requests

asammdf lets you DBC decode and visualize OBD2 data

#3: DBC Decode Raw OBD2 Data

Finally, to analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ like km/h or °C.

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

Decoding OBD2 data is somewhat more complex than standard CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Thus, the CAN ID alone isn’t sufficient to uniquely identify the signals within the payload.

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

CANedge: Your OBD2 Data Logger

The CANedge makes OBD2 data logging straightforward, recording data to an 8-32 GB SD card. Simply connect it to your vehicle to begin logging and decode the data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples: ISO-TP

All OBD2 data communication leverages the ISO-TP transport protocol (ISO 15765-2). While previous examples focused on single-frame communication, this section provides examples of multi-frame communication.

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

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

Example 1: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction for details). To retrieve the VIN using OBD2 requests, 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 the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for specifics). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

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

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

This efficient feature allows for higher frequency and more efficient OBD2 data collection. However, it also means the signal encoding is specific to your request method, making generic OBD2 DBC files less useful for such applications. We generally advise against this method in practice. Below is an example trace of what this might look like:

The multi-frame response is similar to the VIN example but includes the requested PIDs along with their corresponding data in the payload. Note that the PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by the ISO 15031-5 standard.

Decoding this response via generic DBC files is challenging, which is why we don’t recommend this approach for practical data logging unless you are using a tool with specific built-in support. Effectively, you are dealing with extended multiplexing, but with multiple instances throughout 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 this becomes very complex if you send multiple multi-PID requests, as differentiating these messages from each other becomes problematic.

Workarounds could involve custom scripts and recording the transmit messages from your testing tool. The script could then interpret the response message based on the corresponding request message. However, such approaches are generally hard to scale.

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 targeted ECU(s) will respond with the number of DTCs stored (possibly zero if none), 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 divided 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 code (in hexadecimal), as shown in the visual. Decoded DTC values can be looked up in 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 numerous applications:

Logging Data from Cars

OBD2 data logging in cars can be used for purposes like reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.

OBD2 logger

Real-Time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, crucial for diagnosing vehicle issues on the fly.

OBD2 streaming

Predictive Maintenance

Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud for predictive maintenance, helping to anticipate and prevent breakdowns.

Predictive maintenance

Vehicle Black Box Logger

An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing valuable data for incident analysis, dispute resolution, or advanced diagnostics.

CAN bus blackbox

Do you have an OBD2 data logging application in mind? Reach out for a free consultation!

For more introductory guides, see our tutorials section or download the ‘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

Understanding OBD2: Your Car’s Diagnostic System Explained

In this article