Looking for a clear and practical understanding of the OBD2 protocol?
This guide offers a detailed introduction to the On-Board Diagnostic (OBD2) protocol, encompassing the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.
Note: This is designed as a hands-on introduction, equipping you with the knowledge to request and interpret OBD2 data, explore key logging applications, and gain valuable practical insights.
Discover why this is becoming the go-to OBD2 tutorial.
You can also view our introductory OBD2 video above – or download the PDF version
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
What is the OBD2 Protocol?
The OBD2 protocol is essentially your vehicle’s built-in health monitoring system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and live data through the OBD2 connector.
You’ve likely already encountered OBD2 in action:
Ever seen the malfunction indicator light illuminate on your dashboard?
That’s your vehicle signaling a problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
They connect this OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. The scanner sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly speeds up troubleshooting.
Is OBD2 Protocol Supported by My Vehicle?
The short answer: Most likely!
The vast majority of modern non-electric vehicles support the OBD2 protocol, and many operate on the CAN bus system. For older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A reliable way to check compliance is based on the vehicle’s purchase location and year:
A Brief History of the OBD2 Protocol
The OBD2 protocol originated in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control.
The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which standardized DTCs and the OBD connector across different manufacturers (SAE J1962).
The OBD2 standard was progressively implemented:
- 1996: OBD2 became compulsory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline vehicles.
- 2003: Extended to diesel vehicles in the EU (EOBD).
- 2005: OBD2 became mandatory in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2.
- 2010: OBD2 mandate extended to heavy-duty vehicles in the US.
The Future of OBD2 Protocol
OBD2 is set to remain relevant, but its form is evolving.
Here are key trends to consider:
Originally designed for emissions control and testing, legislated OBD2 has an interesting implication: electric vehicles (EVs) aren’t obligated to support OBD2 in any form. This is evident as most modern EVs don’t support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication, making data decoding challenging unless reverse engineering is applied. However, there are successful cases of reverse engineering, as seen in studies for electric cars like Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.
OBD2 implementations today vary and have limitations, particularly in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to address these issues. They aim to enhance OBD communication by using the UDS protocol as a foundation. For a deeper dive into these protocols, refer to our introduction to UDS.
In our connected world, manual OBD2 emission checks feel outdated and inefficient.
The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would enable vehicles to transmit their vehicle identification number (VIN) and DTCs via WiFi to a central server for automated checks.
Many current devices already facilitate CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.
While cost-effective and convenient, OBD3 raises political concerns due to potential surveillance implications.
The OBD2 protocol was initially intended for stationary emission controls.
However, third parties now widely use OBD2 to generate real-time data through OBD2 dongles, CAN loggers, etc. Interestingly, the German car industry is considering limiting this access:
“OBD was designed for servicing cars in repair shops. It was never intended to allow third parties to build a data-driven economy based on access through this interface.”
– Christoph Grote, SVP Electronics, BMW (2017)
The proposal involves deactivating OBD2 functionality during driving, centralizing data collection on manufacturer servers instead. This would give manufacturers control over ‘automotive big data’.
Arguments for this shift include security improvements (e.g., mitigating the risk of car hacking), though many view it as a commercially motivated move. 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
Interested in becoming a CAN bus expert?
Access our 12 ‘simple introductions’ in a comprehensive 160+ page PDF:
Download Now
OBD2 Protocol Standards
On-board diagnostics, or OBD2, is a higher-layer protocol (like a language), while CAN is a communication method (like a phone line). This places 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 more.
These standards can be viewed within a 7-layer OSI model framework. The following sections will focus on the most critical standards.
In the OSI model, you’ll notice that SAE and ISO standards cover several layers. This reflects OBD standards defined in the USA (SAE) and EU (ISO). Many standards are technically very similar, for example, SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.
The OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector facilitates easy access to vehicle data and is standardized under SAE J1962 / ISO 15031-3.
The illustration shows a Type A OBD2 pin connector (also known as Data Link Connector, or DLC).
Key points to note:
- The connector is usually near the steering wheel but can be hidden from plain sight.
- 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 common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.
OBD2 Connector Types: A vs. B
You’ll likely encounter both Type A and Type B OBD2 connectors. Type A is typical in cars, while Type B is common in medium and heavy-duty vehicles.
As shown, both types share similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates often differ as well, with cars typically using 500K, and heavy-duty vehicles often using 250K (though 500K support is increasing).
To visually distinguish them, Type B OBD2 connectors have an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is 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 mandated as the lower-layer protocol for OBD2 in all US vehicles, as per ISO 15765.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) defines restrictions applied to the CAN standard (ISO 11898).
Specifically, it standardizes the CAN interface for test 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 used for OBD requests/responses.
- Diagnostic CAN frame data length must be 8 bytes.
- The OBD2 adapter cable should be max 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
All OBD2 communication relies on request/response message exchanges.
Most cars use 11-bit CAN IDs for OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF, which is used to query all OBD2-compatible ECUs if they have data to report on the requested parameter (refer to ISO 15765-4). CAN IDs 0x7E0-0x7E7, in contrast, can be used for ‘Physical Addressing’ requests to specific ECUs (less common).
ECUs can respond using 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), and to a lesser extent 0x7E9 (TCM, Transmission Control Module).
Some vehicles, like vans and light/medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit CAN IDs.
The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.
Vehicle responses will be seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes shown in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is marked in the J1939-71 standard 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 rely on OBD2 for their core functionality. Each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for vehicle operation. These CAN protocols are often specific to the vehicle brand, model, and year. This OEM-specific data is generally undecipherable to outsiders without reverse engineering.
Connecting a CAN bus data logger to your vehicle’s OBD2 connector may reveal OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that blocks access to this raw CAN data and only enables 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 two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern vehicles most commonly use 500K and 11-bit IDs, but external tools should systematically verify this.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This method leverages the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rate transmission will cause CAN error frames.
Newer ISO 15765-4 versions account for vehicles potentially supporting 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 differentiate between OBDonEDS and OBDonUDS protocols, a test tool can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.
In practice, OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks/buses.
Five Lower-Layer OBD2 Protocols
While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles post-2008, older vehicles may use other protocols. Knowing these can be helpful when dealing with pre-2008 models. Pinout configurations can also indicate the protocol in use.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and 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 around 2000-2004.
- SAE J1850 (VPW): Primarily used in older GM vehicles.
- SAE J1850 (PWM): Mainly used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]
All OBD2 data communication over CAN bus utilizes a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for transmitting payloads larger than 8 bytes, 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, see our introduction to UDS.
However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies using a ‘Single Frame’ (SF) format. Here, the first data byte (PCI field) contains the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To better grasp OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises an identifier, data length (PCI field), and data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.
Example: OBD2 Request/Response
Before detailing each part of the OBD2 message, consider this example request/response for ‘Vehicle Speed’.
An external tool sends a request message to the vehicle with CAN ID 0x7DF and 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).
Consulting OBD2 PID 0x0D decoding rules reveals that the physical value is 50 km/h.
Next, we’ll explore OBD2 modes and PIDs in more detail.
The 10 OBD2 Services (aka Modes)
There are 10 standardized OBD2 diagnostic services, or modes. Mode 0x01 is used to retrieve real-time data, while others are used for diagnostic trouble codes (DTCs) or freeze frame data.
Vehicles are not required to support all OBD2 modes and may implement modes beyond these 10 standard modes (OEM-specific OBD2 modes).
In OBD2 messages, the mode is located in the second byte. In a request, the mode is included directly (e.g., 0x01), while in a response, 0x40 is added to the mode value (e.g., resulting in 0x41).
OBD2 Parameter IDs (PIDs)
Each OBD2 mode contains Parameter IDs (PIDs).
For example, Mode 0x01 includes approximately 200 standardized PIDs providing real-time data like speed, RPM, and fuel level. However, vehicles aren’t required to support all PIDs within a mode, and most vehicles support only a subset.
One PID is particularly important:
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle ECU indicates whether it supports PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining Mode 0x01 PIDs.
Tip: OBD2 PID Overview Tool
SAE J1979 and ISO 15031-5 appendices contain scaling information for standard OBD2 PIDs, enabling you to decode data into physical values (as explained in our CAN bus introduction).
For quick lookups of Mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It aids 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 example of logging OBD2 data using the CANedge CAN bus data logger.
The CANedge allows configuration of custom CAN frame transmissions, making it suitable for OBD2 logging.
Once configured, the CANedge easily connects to your vehicle via our OBD2-DB9 adapter cable.
Example of sending a CAN frame at 500K and verifying successful transmission
Reviewing responses to ‘Supported PIDs’ requests in asammdf software
#1: Test Bit-rate, IDs & Supported PIDs
As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. The CANedge can be used to test this process (see 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.
- Response IDs will indicate 11-bit vs. 29-bit CAN ID usage.
- Response data reveals supported PIDs.
We provide plug-and-play configurations to perform these tests.
Most non-EV vehicles from 2008 onwards support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
As illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This is because the 0x7DF request ID polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses, particularly to this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs tend to respond. Notice also that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. Busload can be reduced by specifically requesting responses from only this ECU by switching to ‘Physical Addressing’ CAN ID 0x7E0 for future communication.
#2: Configure OBD2 PID Requests
Once you know your vehicle’s supported OBD2 PIDs, bit-rate, and CAN IDs, you can configure your transmit list with desired PIDs.
Consider these points when configuring:
- CAN IDs: Shift to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
- Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
- Battery Drain: Use triggers to halt transmissions when the vehicle is inactive to prevent ECU ‘wake-up’ and battery drain.
- Filters: Implement filters to record only OBD2 responses if OEM-specific CAN data is also present.
With these configurations, your device is ready to log raw OBD2 data!
Example list of CANedge OBD2 PID requests
asammdf allows DBC decoding and visualization of 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).
Decoding information can be found in ISO 15031-5/SAE J1979 (and online resources like Wikipedia). For convenience, we offer a free OBD2 DBC file to facilitate 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). The CAN ID alone isn’t enough to identify the encoded signals in the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together for signal identification. This multiplexing approach, known as ‘extended multiplexing‘, is implementable in formats like DBC files.
CANedge: OBD2 Data Logger
The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Simply connect it to a vehicle to begin logging and decode data using free software/APIs and our OBD2 DBC.
OBD2 Logger Intro
CANedge Product Page
OBD2 Multi-Frame Examples [ISO-TP]
OBD2 data communication always uses ISO-TP (transport protocol) as per ISO 15765-2. Most examples so far have been single-frame communications. This section illustrates multi-frame communication examples.
Multi-frame OBD2 communication necessitates flow control frames (see our UDS introduction). In practice, this can be achieved by transmitting a static flow control frame about 50 ms after the initial request frame, as in the CANedge configuration example shown earlier.
Furthermore, multi-frame OBD2 responses require CAN software/API tools that support ISO-TP, like CANedge MF4 decoders.
Example 1: OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is essential 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 tester 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), in this case, 1 (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 detailed in our UDS introduction.
Example 2: OBD2 Multi-PID Request (6x)
External tools can request up to 6 Mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for supported PIDs (excluding unsupported ones in the response), potentially spanning multiple frames as per ISO-TP.
This feature enables higher frequency and efficiency data collection, but it also means signal encoding is specific to your request method, making generic OBD2 DBC files less useful. We generally advise against this method in practice. Below is an example trace:
The multi-frame response resembles the VIN example, but the payload includes the requested PIDs and their corresponding data. The PIDs in the example are ordered similarly to the request order, which is common practice (though not strictly mandated by ISO 15031-5).
Decoding this response via DBC files is complex and not recommended for practical data logging unless you are using tools with built-in support for this specific method. It involves extended multiplexing with multiple instances throughout the payload. Your DBC file would need to account for each PID’s specific payload position, making it difficult to generalize across vehicles with varying PID support. Handling this via pure DBC manipulations becomes nearly impossible, especially when sending multiple multi-PID requests, as you lose a method to uniquely identify messages.
Workarounds might involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages in conjunction with request messages, but these approaches are challenging 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. Targeted ECU(s) respond with the number of stored DTCs (possibly 0 if none), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 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’, and the remaining 14 bits define a 4-digit code (in hexadecimal), as shown visually. 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 6 stored DTCs.
OBD2 Data Logging – Use Case Examples
OBD2 data from cars and light trucks has numerous applications:
Logging Data from Cars
OBD2 data from cars can be used to reduce fuel costs, improve driving habits, test prototype parts, and for insurance purposes.
OBD2 Logger Product Link
Real-time Car Diagnostics
OBD2 interfaces can stream human-readable OBD2 data in real-time, useful for diagnosing vehicle issues.
OBD2 Streaming Product Link
Predictive Maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud for predictive maintenance and breakdown prevention.
Predictive Maintenance Product Link
Vehicle Blackbox Logger
An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing data for disputes or diagnostics.
CAN Bus Blackbox Product Link
Do you have an OBD2 data logging use case? Contact us for free consultation!
Contact Us
For more introductory guides, visit our guides 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 Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
