Understanding All OBD2 Protocols: A Comprehensive Guide for Automotive Diagnostics

The On-Board Diagnostics (OBD2) system is a cornerstone of modern vehicle maintenance and repair. As a standardized protocol, OBD2 allows technicians and enthusiasts alike to access a wealth of information about a vehicle’s health and performance. This guide provides a detailed introduction to All Obd2 Protocols, ensuring you grasp the essentials for effective automotive diagnostics.

What is OBD2 and Why is it Important?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector. You’ve likely encountered OBD2 in action whenever the malfunction indicator light, commonly known as the “check engine light,” illuminates on your dashboard. This light signals that the vehicle’s self-diagnostic system has detected an issue.

Mechanics rely on OBD2 scanners, which connect to the 16-pin OBD2 connector typically located near the steering wheel, to pinpoint these issues. These scanners send requests based on OBD2 protocols to the car’s computer, and the car responds with data encompassing parameters like speed, fuel level, and DTCs. This streamlined communication significantly accelerates the troubleshooting and repair process.

Alt text: OBD2 system displaying malfunction indicator light and diagnostic scan tool.

OBD2 Compatibility: Does Your Car Support It?

The chances are high that your vehicle is OBD2 compliant. Virtually all non-electric vehicles manufactured in recent decades support OBD2, and many utilize the CAN bus communication standard. However, it’s crucial to note that the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 support, particularly in older models.

To ascertain OBD2 compliance, consider the vehicle’s origin and year of purchase:

Alt text: Chart illustrating OBD2 compliance by region and vehicle type (EU, US, Cars, Light Trucks, CAN).

A Look at OBD2 History and Evolution

The genesis of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards for emission control.

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

The OBD2 standard adoption unfolded gradually:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU mandated OBD2 for gasoline cars.
2003: The EU extended the mandate to include diesel cars (EOBD).
2005: OBD2 became a requirement in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 compliance extended to heavy-duty vehicles in the US.

Alt text: OBD2 history timeline emphasizing emission control, exhaust regulations, EOBD2, and EOBDII.

Alt text: Timeline overview of OBD2 history and on-board diagnostics development.

Alt text: Visualizing the future of OBD2 including OBD3, remote diagnostics, emissions testing, cloud, and IoT integration.

The Future Trajectory of OBD2

OBD2 is firmly entrenched in automotive diagnostics, but its future is evolving.

Initially conceived for emissions control, legislated OBD2 requirements don’t extend to electric vehicles (EVs). Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often employ OEM-specific UDS communication, making data retrieval challenging unless decoding methods are reverse-engineered. Notable exceptions are emerging through reverse engineering efforts for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations face limitations regarding data richness and underlying communication protocols. In response, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are gaining traction. These protocols aim to enhance OBD communication by utilizing the UDS protocol as a base.

In the era of connected vehicles, traditional OBD2 emission checks appear inefficient. The envisioned solution is OBD3 – integrating telematics into all vehicles. OBD3 proposes adding a radio transponder to vehicles, enabling wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated checks.

While devices already exist for transmitting CAN or OBD2 data via WiFi/cellular networks, the OBD3 concept raises privacy concerns, presenting political hurdles.

The original purpose of OBD2 was for stationary emission testing. However, third-party applications now widely use OBD2 for real-time data generation through OBD2 dongles and CAN loggers. However, the automotive industry is considering measures to limit this third-party access.

The proposition involves restricting OBD2 functionality during driving, centralizing data collection with manufacturers. This shift aims to grant manufacturers control over automotive big data, citing security concerns like car hacking risks. However, some perceive this as a commercially motivated move that could disrupt the OBD2 third-party service market.

Alt text: OBD2 future with electric vehicles potentially blocking data access through connector removal.

Deep Dive into OBD2 Standards

OBD2 operates as a higher-layer protocol built upon communication methods like CAN. It shares similarities with other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

OBD2 standards comprehensively define the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards can be visualized using the 7-layer OSI model, with SAE and ISO standards covering various layers. SAE standards are predominantly US-centric, while ISO standards are prevalent in the EU. Many standards are technically parallel, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

Alt text: OSI 7-layer model comparing OBD2 and CAN bus protocols, highlighting ISO 15765 and ISO 11898 standards.

Alt text: OBD connector pinout diagram for socket female type A DLC.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector is the physical interface for accessing vehicle data. It’s standardized under SAE J1962 / ISO 15031-3.

Key aspects of the OBD2 connector include:

Location: Usually near the steering wheel, though sometimes concealed.
Pin 16: Provides battery power, often even when the ignition is off.
Pinout: Varies based on the communication protocol employed.
CAN bus: The most common lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L).

OBD2 Connector Types: A vs. B

Two primary OBD2 connector types exist: Type A and Type B. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles.

While pinouts are similar, Type A and Type B connectors differ in power supply outputs (12V for Type A, 24V for Type B) and often baud rates (500K for cars, 250K for heavy-duty vehicles, with increasing 500K support).

Type B connectors feature an interrupted groove in the middle for physical differentiation. Type B OBD2 adapter cables are compatible with both Type A and B sockets, whereas Type A adapters only fit Type A sockets.

Alt text: Comparison of OBD2 connector Type A and Type B, highlighting SAE J1962 standard, 12V/24V, car, van, and truck applications.

Alt text: Diagram contrasting OBD2 and CAN bus, referencing ISO 15765 standard.

OBD2 and CAN Bus: ISO 15765-4 Protocol

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

ISO 15765-4 (Diagnostics over CAN or DoCAN) imposes specific constraints on the CAN standard (ISO 11898), standardizing the CAN interface for diagnostic equipment, particularly at the physical, data link, and network layers:

CAN bus bit-rate: Must be 250K or 500K.
CAN IDs: Can be 11-bit or 29-bit.
CAN IDs: Specific IDs are reserved for OBD requests/responses.
Diagnostic CAN frame data length: Fixed at 8 bytes.
OBD2 adapter cable: Limited to a maximum length of 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication relies on request/response message exchanges.

Most vehicles utilize 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID, 0x7DF, queries all OBD2-compatible ECUs for data on the requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs use CAN IDs 0x7E0-0x7E7, though less common.

ECU responses use 11-bit IDs 0x7E8-0x7EF, with 0x7E8 (ECM, Engine Control Module) and 0x7E9 (TCM, Transmission Control Module) being the most frequent.

Some vehicles, especially vans and medium/heavy-duty vehicles, may employ extended 29-bit CAN identifiers for OBD2 communication.

The 29-bit ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). These response IDs are sometimes represented in J1939 PGN format, specifically PGN 0xDA00 (55808), designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

Alt text: OBD2 protocol request and response frames illustrating PID data parameters.

Alt text: Contrasting OBD2 and proprietary CAN bus data protocols.

OBD2 vs. Proprietary CAN Protocols

Vehicle ECUs function independently of OBD2, relying on OEM-specific proprietary CAN protocols. These protocols are unique to vehicle brands, models, and years. Interpreting this proprietary data is generally restricted to OEMs, unless reverse engineering techniques are applied.

Connecting a CAN bus data logger to the OBD2 connector might capture OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, newer vehicles often employ a gateway that restricts access to this data via the OBD2 connector, permitting only OBD2 communication.

Essentially, OBD2 acts as a parallel, higher-layer protocol alongside the OEM-specific protocol.

Bit-rate and ID Validation

OBD2 can operate at two bit-rates (250K, 500K) and with two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern vehicles commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination. This method leverages the mandatory OBD2 response to a specific request (see OBD2 PID section) and the occurrence of CAN error frames when using an incorrect bit-rate.

Current versions of ISO 15765-4 consider OBD communication via OBDonUDS and OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).

Protocol testing (OBDonEDS vs. OBDonUDS) can involve sending UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-compliant vehicles must have ECUs that respond to this DID.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV vehicles, while WWH-OBD is mainly used in EU trucks/buses.

Alt text: Flowchart illustrating OBD2 bit-rate and CAN ID validation process according to ISO 15765-4.

Alt text: OBD2 standards diagram highlighting five protocols: CAN ISO-15765, KWP2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBD2 Protocols

While CAN is the dominant lower-layer protocol for OBD2 today (ISO 15765), older vehicles (pre-2008) might use one of four other protocols. Pinouts can help identify the protocol in use.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008, widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly 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 for OBD2 Messaging: ISO 15765-2

OBD2 data transmission over CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol that enables payloads exceeding 8 bytes. This is essential for OBD2 functions like retrieving VINs or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly.

For smaller OBD2 data, single CAN frames are often sufficient. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the first data byte (PCI field) denotes payload length (excluding padding), leaving 7 bytes for OBD2 communication.

Alt text: ISO 15765-2 ISO-TP OBD2 frame types diagram.

Decoding the OBD2 Diagnostic Message: SAE J1979, ISO 15031-5

A simplified OBD2 CAN message consists of an identifier, data length (PCI field), and data. The data field is further structured into Mode, parameter ID (PID), and data bytes.

Alt text: OBD2 PIDs OBD-ii Message Structure Breakdown Explained diagram.

OBD2 Request/Response Example

Consider the example of requesting ‘Vehicle Speed’.

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

Using OBD2 PID 0x0D decoding rules, 0x32 translates to a physical value of 50 km/h.

Alt text: OBD2 request 7DF and response 7e8 example for vehicle speed.

Alt text: OBD2 PID example for Vehicle Speed with code 0D.

Alt text: OBD2 services modes including current data, freeze frame, and clear DTC.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services or modes. Mode 0x01 provides real-time data, while others handle DTCs and freeze frame data.

Vehicles aren’t required to support all OBD2 modes and may include OEM-specific modes beyond the standard 10.

In OBD2 messages, the mode is in the second byte. In requests, the mode is directly included (e.g., 0x01), and in responses, 0x40 is added to the mode value (e.g., 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains parameter IDs (PIDs). Mode 0x01, for example, has approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs.

PID 0x00 in mode 0x01 is crucial. If an emissions-related ECU supports OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates support for PIDs 0x01-0x20. PID 0x00 serves as a fundamental OBD2 compatibility test. PIDs 0x20, 0x40, …, 0xC0 similarly indicate support for subsequent PID ranges in mode 0x01.

Alt text: OBD2 protocol request and response frames illustrating PID data parameters.

Alt text: OBD2 PID overview tool interface for service 01.

OBD2 PID Overview Tools

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling data decoding into physical values.

Online OBD2 PID overview tools can assist in constructing OBD2 request frames and dynamically decoding responses.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

This section demonstrates logging OBD2 data using a CANedge CAN bus data logger. CANedge’s configurable CAN frame transmission capability makes it suitable for OBD2 logging. Connecting it to a vehicle involves using an OBD2-DB9 adapter cable.

Alt text: OBD2 PID data logger request 7df 7e8 setup diagram.

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

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

Alt text: Reviewing supported PIDs via OBD2 lookup tool interface.

Step #1: Bit-rate, ID, and Supported PID Testing

ISO 15765-4 provides guidelines for determining vehicle-specific bit-rate and IDs. CANedge can be used for testing:

Test 500K bit-rate CAN frame transmission (if unsuccessful, try 250K).
Use the identified bit-rate for subsequent communication.
Send ‘Supported PIDs’ requests and analyze responses.
Response IDs indicate 11-bit or 29-bit usage.
Response data reveals supported PIDs.

Pre-configured settings for these tests are available for CANedge. Most post-2008 non-EV vehicles support 40-80 PIDs, using 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

Multiple responses to a single OBD request (using 0x7DF) are common due to polling all ECUs. ECU 0x7E8 (ECM) often supports all PIDs supported by other ECUs in this example. Switching to ‘Physical Addressing’ CAN ID 0x7E0 for specific ECU requests can reduce busload.

Step #2: Configuring OBD2 PID Requests

Once supported PIDs, bit-rate, and CAN IDs are identified, configure a transmit list with desired PIDs.

Considerations include:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
Battery drain: Use triggers to stop transmission during vehicle inactivity.
Filters: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present.

asammdf lets you DBC decode and visualize OBD2 data

Step #3: DBC Decoding of Raw OBD2 Data

For data analysis and visualization, raw OBD2 data needs to be decoded into physical values. Decoding information is in ISO 15031-5/SAE J1979 and online resources like Wikipedia. A free OBD2 DBC file simplifies DBC decoding in CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signals due to multiplexing. Different OBD2 PIDs share the same CAN ID (e.g., 0x7E8). Signal identification requires both CAN ID, OBD2 mode, and OBD2 PID. This ‘extended multiplexing’ is handled in DBC files.

CANedge: Your OBD2 Data Logger

The CANedge facilitates easy OBD2 data recording to an 8-32 GB SD card. Connect to a vehicle to start logging and decode data using free software/APIs and the OBD2 DBC file.

OBD2 logger intro
CANedge

Multi-Frame OBD2 Examples: ISO-TP in Action

OBD2 communication utilizes ISO-TP (ISO 15765-2). While single-frame examples are common, multi-frame communication is necessary for larger data sets.

Multi-frame OBD2 requires flow control frames. A static flow control frame transmitted ~50 ms after the initial request frame can be used (as in CANedge configuration examples). Multi-frame OBD2 responses require ISO-TP-capable CAN software/API tools like CANedge MF4 decoders.

Alt text: OBD2 multi-frame request message example for vehicle identification number.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

VIN retrieval via OBD2 (mode 0x09, PID 0x02) is relevant for telematics and diagnostics.

The tool sends a Single Frame request. The vehicle responds with a First Frame containing PCI, length, mode (0x49), and PID (0x02), followed by NODI (Number Of Data Items, in this case 1), and the 17-byte VIN (HEX to ASCII conversion needed).

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

Tools can request up to 6 mode 0x01 OBD2 PIDs in a single frame, eliciting multi-frame responses for supported PIDs. This increases data collection efficiency but complicates signal encoding, making generic OBD2 DBC files less usable. This method is generally not recommended for practical use.

Decoding multi-PID responses with DBC files is challenging due to extended multiplexing and PID-specific payload positions. Custom scripts combined with request message logging could be used, but are complex to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 mode 0x03 retrieves emissions-related DTCs. The request contains only the mode (0x03). Responses include the number of DTCs and 2-byte DTC values, often requiring multi-frame responses for more than 2 DTCs.

The 2-byte DTC is categorized (first 2 bits) and includes a 4-digit hexadecimal code. Decoded DTC values can be looked up in OBD2 DTC lookup tools.

Alt text: OBD2 DTC Diagnostic Trouble Code DBC Interpretation Example diagram.

OBD2 Data Logging: Real-World Use Cases

OBD2 data logging from cars and light trucks has diverse applications:

Alt text: OBD2 data logger application in on-board diagnostics for car vehicles.

Car Data Logging

Used for fuel efficiency improvement, driving behavior analysis, prototype testing, and insurance telematics.
obd2 logger

Alt text: OBD2 real-time streaming diagnostics via USB interface.

Real-time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable data for diagnosing vehicle issues.
obd2 streaming

Alt text: OBD2 data logger for predictive maintenance and telematics applications.

Predictive Maintenance

IoT-connected OBD2 loggers facilitate cloud-based vehicle monitoring for predicting and preventing breakdowns.
predictive maintenance

Alt text: Black box CAN logger for insurance and warranty purposes.

Vehicle Blackbox Logger

OBD2 loggers serve as ‘black boxes’ for vehicles, providing data for incident analysis and diagnostics.
can bus blackbox

Explore OBD2 data logging applications and reach out for expert consultation.
Contact us

For further learning, explore our guides or download the ‘Ultimate Guide’ PDF.

Ready to Log or Stream OBD2 Data?

Get Your OBD2 Data Logger Today!

Buy now
Contact us