OBD2 Explained - A Simple Intro 
Need a simple, practical intro to OBD2?
In this guide we introduce the On Board Diagnostic (OBD2) protocol incl. the OBD2 connector, OBD2 parameter IDs (PID) and the link to CAN bus.
Note: This is a practical intro so you will also learn how to request and decode OBD2 data, key logging use cases and practical tips.
Learn below why this has become the #1 OBD2 tutorial.
You can also watch our OBD2 intro video above - or get the PDF
In this article
What is OBD2?
In short, OBD2 is your vehicle's built-in self-diagnostic system.
You've probably encountered OBD2 already:
Ever noticed the malfunction indicator light on your dashboard?
That is your car telling you there is an issue. If you visit a mechanic, he will use an OBD2 scanner to diagnose the issue.
To do so, he will connect the OBD2 reader to the OBD2 16 pin connector near the steering wheel.
This lets him read OBD2 codes aka Diagnostic Trouble Codes (DTCs) to review and troubleshoot the issue.
The OBD2 connector
The OBD2 connector lets you access data from your car easily. The standard SAE J1962 specifies two female OBD2 16-pin connector types (A & B).
In the illustration is an example of a Type A OBD2 pin connector (also sometimes referred to as the Data Link Connector, DLC).
A few things to note:
- The OBD2 connector is near your steering wheel, but may be hidden behind covers/panels
- Pin 16 supplies battery power (often while the ignition is off)
- The OBD2 pinout depends on the communication protocol
- The most common protocol is CAN (via ISO 15765), meaning that pins 6 (CAN-H) and 14 (CAN-L) will typically be connected
OBD2 connector - type A vs. B
In practice, you may encounter both the type A and type B OBD2 connector. Typically, type A will be found in cars, while type B is common in medium and heavy duty vehicles.
As evident from the illustration, the two types share similar OBD2 pinouts, but provide two different power supply outputs (12V for type A and 24V for type B). Often the baud rate will differ as well, with cars typically using 500K, while most heavy duty vehicles use 250K (more recently with support for 500K).
To help physically distinguish between the two types of OBD2 sockets, note that the type B OBD2 connector has an interrupted groove in the middle. As a result, a type B OBD2 adapter cable will be compatible with both types A and B, while a type A will not fit into a type B socket.
Does my car have OBD2?
In short: Probably!
Almost all newer cars support OBD2 and most run on CAN (ISO 15765). For older cars, be aware that even if a 16 pin OBD2 connector is present, it may still not support OBD2. One way to determine compliance is to identify where & when it was bought new:
Link between OBD2 and CAN bus
On board diagnostics, OBD2, is a 'higher layer protocol' (like a language). CAN is a method for communication (like a phone).
In particular, the OBD2 standard specifies the OBD2 connector, incl. a set of five protocols that it can run on (see below). Further, since 2008, CAN bus (ISO 15765) has been the mandatory protocol for OBD2 in all cars sold in the US.
What is the ISO 15765 standard?
ISO 15765 refers to a set of restrictions applied to the CAN standard (which is itself defined in ISO 11898). One might say that ISO 15765 is like "CAN for cars".
In particular, ISO 15765-4 describes the physical, data link layer and network layers, seeking to standardize the CAN bus interface for external test equipment. ISO 15765-2 in turn describes the transport layer (ISO TP) for sending CAN frames with payloads that exceed 8 bytes. This sub standard is also sometimes referred to as Diagnostic Communication over CAN (or DoCAN). See also the 7 layer OSI model illustration.
OBD2 can also be compared to other higher layer protocols (e.g. J1939, CANopen).
The five OBD2 protocols
As explained above, CAN bus today serves as the basis for OBD2 communication in the vast majority of cars through ISO 15765.
However, if you're inspecting an older car (pre 2008), it is useful to know the other four protocols that have been used as basis for OBD2. Note also the pinouts, which can be used to determine which protocol may be used in your car.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and is today used in the vast majority of cars
- ISO14230-4 (KWP2000): The Keyword Protocol 2000 was a common protocol for 2003+ cars in e.g. Asia
- ISO9141-2: Used in EU, Chrysler & Asian cars in 2000-04
- SAE J1850 (VPW): Used mostly in older GM cars
- SAE J1850 (PWM): Used mostly in older Ford cars
Below we list some of the most relevant SAE/ISO standards related to OBD2:
SAE J1962: This standard defindes the physical connector used for the OBD2 interfacing, i.e. the OBD2 connector. The standard describes both the vehicle OBD2 connector and the connector used by the external test equipment (e.g. an OBD2 scanner or OBD2 data logger). In particular, the standard dictates the location and access to the OBD2 connector.
SAE J1979: The SAE J1979 standard describes the methods for requesting diagnostic information via the OBD2 protocol. It also includes a list of standardized public OBD2 parameter IDs (OBD2 PIDs) that automotive OEMs may implement in cars (though they are not required to do so). Vehicle OEMs may also decide to implement additional proprietary OBD2 PIDs beyond those outlined by the SAE J1979 standard.
SAE J1939: The J1939 standard describes the data protocol used for heavy-duty vehicle communication. While OBD2 PID information is only available on-request by OBD2 test equipment, the J1939 protocol is used in most heavy-duty vehicles as the basic means for communicating CAN traffic - meaning data is broadcast continuously.
ISO 11898: This standard describes the CAN bus data link layer and physical layer, serving as the basis for OBD2 communication in most cars today
ISO 15765-2: The ISO-TP standard describes the 'Transport Layer', i.e. how to send data packets exceeding 8 bytes via CAN bus. This standard is important as it forms the basis for Unified Diagnostic Services (UDS) communication, which relies on sending multiframe CAN data packets.
ISO 14229: This describes UDS communication in detail
It can be useful to compare the OBD2 protocol vs. other request/response protocols on CAN.
In our intro to Unified Diagnostic Services (UDS) we compare UDS vs. OBD2, WWH-OBD and OBDonUDS.
In our intro to CCP/XCP on CAN we compare the CAN Calibration Protocol (CCP) and the Universal Measurement and Calibration Protocol (XCP) on CAN vs. UDS.
OBD2 is generally focused on emission control, while UDS is focused on diagnostics and read/write access to ECUs - primarily for production-stage vehicles. CCP and XCP are focused on measurement and calibration of ECUs within prototype vehicle ECUs and they are less oriented towards diagnostics.
OBD2 originates from California where the California Air Resources Board (CARB) required OBD in all new cars from 1991+ for emission control purposes.
The OBD2 standard was recommended by the Society of Automotive Engineers (SAE) and standardized DTCs and the OBD connector across manufacturers (SAE J1962).
From there, the OBD2 standard was rolled out step-by-step:
- 1996: OBD2 made mandatory in USA for cars/light trucks
- 2001: Required in EU for gasoline cars
- 2003: Required in EU also for diesel cars (EOBD)
- 2005: OBD2 was required in US for medium duty vehicles
- 2008: US cars must use ISO 15765-4 (CAN) as OBD2 basis
- 2010: Finally, OBD2 was required in US heavy duty vehicles
OBD2 is here to stay - but in what form?
Two potential routes may radically change OBD2:
In today's world of connected cars, OBD2 tests can seem cumbersome: Manually doing emission control checks is time-consuming and expensive.
The solution? OBD3 - adding telematics to all cars.
Basically, OBD3 adds a small radio transponder (as in e.g. bridge tolls) to all cars. Using this, the car vehicle identification number (VIN) and DTCs can be sent via WiFi to a central server for checks.
Many devices today already facilitate transfer of CAN or OBD2 data via WiFi/cellular - e.g. the CANedge2 WiFi CAN logger.
This saves cost and is convenient, but it is also politically a challenge due to surveillance concerns.
The OBD2 protocol was originally designed for stationary emission controls.
Yet, today OBD2 is used extensively for generating real-time data by 3rd parties - via OBD2 dongles, CAN loggers etc. However, the German car industry is looking to change this:
OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface"
- Christoph Grote, SVP Electronics, BMW (2017)
The proposal is to "turn off" the OBD2 functionality while driving - and instead collect the data in a central server. This would effectively put the manufacturers in control of the automotive 'big data'.
The argumentation is based in security (e.g. removing the risk of car hacking), though many see it as a commercial move. Whether this becomes a real trend is to be seen - but it may truly disrupt the market for OBD2 3rd party services.
OBD2 parameter IDs (PID)
Why should you care about OBD2 data?
Mechanics obviously care about OBD2 DTCs (maybe you do too), while regulatory entities need OBD2 to control emission.
But the OBD2 protocol also supports a broad range of standard parameter IDs (PIDs) that can be logged across most cars.
This means that you can easily get human-readable OBD2 data from your car on speed, RPM, throttle position and more.
In other words, OBD2 lets you analyze data from you car easily - in contrast to the OEM specific proprietary raw CAN data.
In principle it is simple to log the raw CAN frames from your car. If you e.g. connect a CAN logger to the OBD2 connector, you'll start logging broadcasted CAN bus data out-the-box. However, the raw CAN messages need to be decoded via a database of conversion rules (DBC) and a suitable CAN software that supports DBC decoding (like e.g. asammdf). The challenge is that these CAN DBC files are typically proprietary, making the raw CAN data unreadable unless you're the automotive OEM.
Car hackers may try to reverse engineer the rules, though this can be difficult. CAN is, however, still the only method to get "full access" to your car data - while OBD2 only provides access to a limited subset of data.
How to log OBD2 data?
OBD2 data logging works as follows:
- You connect an OBD2 logger to the OBD2 connector
- Using the tool, you send 'request frames' via CAN
- The relevant ECUs send 'response frames' via CAN
- Decode the raw OBD2 responses via e.g. an OBD2 DBC
In other words, a CAN logger that is able to transmit custom CAN frames can also be used as an OBD2 logger.
Note that cars differ by model/year in what OBD2 PIDs they support. For details, see our OBD2 data logger guide.
CANedge OBD2 data logger
The CANedge lets you easily log OBD2 data to an 8-32 GB SD card. Simply specify what OBD2 PIDs you wish to request, then connect it to your car via an OBD2 adapter to start logging. Process the data via free software/APIs and our OBD2 DBC.obd2 data logger
Raw OBD2 frame details
To get started recording OBD2 data, it is helpful to understand the basics of the raw OBD2 message structure. In simplified terms, an OBD2 message is comprised of an identifier and data. Further, the data is split in Mode, PID and data bytes (A, B, C, D) as below.
Identifier: For OBD2 messages, the identifier is standard 11-bit and used to distinguish between "request messages" (ID 7DF) and "response messages" (ID 7E8 to 7EF). Note that 7E8 will typically be where the main engine or ECU responds at.
Length: This simply reflects the length in number of bytes of the remaining data (03 to 06). For the Vehicle Speed example, it is 02 for the request (since only 01 and 0D follow), while for the response it is 03 as both 41, 0D and 32 follow.
Mode: For requests, this will be between 01-0A. For responses the 0 is replaced by 4 (i.e. 41, 42, … , 4A). There are 10 modes as described in the SAE J1979 OBD2 standard. Mode 1 shows Current Data and is e.g. used for looking at real-time vehicle speed, RPM etc. Other modes are used to e.g. show or clear stored diagnostic trouble codes and show freeze frame data.
PID: For each mode, a list of standard OBD2 PIDs exist - e.g. in Mode 01, PID 0D is Vehicle Speed. For the full list, check out our OBD2 PID overview. Each PID has a description and some have a specified min/max and conversion formula.
The formula for speed is e.g. simply A, meaning that the A data byte (which is in HEX) is converted to decimal to get the km/h converted value (i.e. 32 becomes 50 km/h above). For e.g. RPM (PID 0C), the formula is (256*A + B) / 4.
A, B, C, D: These are the data bytes in HEX, which need to be converted to decimal form before they are used in the PID formula calculations. Note that the last data byte (after Dh) is not used.
OBD2 request/response example
An example of a request/response CAN message for the PID 'Vehicle Speed' with a value of 50 km/h can be seen in the illustration.
Note in particular how the formula for the OBD2 PID 0D (Vehicle Speed) simply involves taking the 4th byte (0x32) and converting it to decimal form (50).
In some vehicles (e.g. vans and light/medium/heavy duty vehicles), you may find that the raw CAN data uses extended 29-bit CAN identifiers instead of 11-bit CAN identifiers.
In this case, you will typically need to modify the OBD2 PID requests to use the CAN ID 18DB33F1 instead of 7DF. The data payload structure is kept identical to the examples for 11-bit CAN IDs.
If the vehicle responds to the requests, you'll typically see responses with CAN IDs 18DAF100 to 18DAF1FF (in practice, typically 18DAF110 and 18DAF11E). The response identifier is also sometimes shown in the 'J1939 PGN' form, specifically the PGN 0xDA00 (55808), which in the J1939-71 standard is marked as 'Reserved for ISO 15765-2'.
We provide an OBD2 DBC file for both the 11-bit and 29-bit responses, enabling simple decoding of the data in most CAN software tools.
The 10 OBD2 services (aka modes)
There are 10 OBD2 diagnostic services (or modes) as described in the SAE J1979 OBD2 standard. Mode 1 shows Current Data and is used for looking at real-time parameters like vehicle speed, RPM, throttle position etc. Other modes are e.g. used to show/clear diagnostic trouble codes (DTCs) and show freeze frame data.
Manufacturers do not have to support all diagnostic services - and they may support modes outside these 10 services (i.e. manufacturer specific OBD2 services).
OBD2 data logging - use case examples
OBD2 data from cars and light trucks can be used in various use cases:
Logging data from cars
OBD2 data from cars can e.g. be used to reduce fuel costs, improve driving, test prototype parts and insuranceobd2 logger
Real-time car diagnostics
OBD2 interfaces can be used to stream human-readable OBD2 data in real-time, e.g. for diagnosing vehicle issuesobd2 streaming
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and avoid breakdownspredictive maintenance
Vehicle blackbox logger
An OBD2 logger can serve as a 'blackbox' for vehicles or equipment, providing data for e.g. disputes or diagnosticscan bus blackbox
Do you have an OBD2 data logging use case? Reach out for free sparring!Contact us
Below we outline the most common OBD2 analyzer categories:
OBD2 scanners: Used as car diagnostic tools in static reading/clearing of DTCs by e.g. mechanics. An OBD2 scan tool is typically used in diagnosing vehicle issues e.g. indicated by an activated MIL. Various types exist and some private persons use low cost variants as simple car code readers for self-diagnosing their car health.
Bluetooth OBD2 dongles: Many OBD2 bluetooth dongles exist, which let you view car data directly on your smartphone via an app. Typically OBDII bluetooth dongles are low cost and easy-to-use, though also limited in terms of their usability outside the bluetooth-to-app visualization purpose. The purpose of an OBD2 bluetooth dongle is typically to monitor personal driving behavior and vehicle health.
OBD2 interfaces: Provide real-time OBD2 data to a PC via USB streaming. OBD2 interfaces are typically used in advanced car diagnostics and OEM vehicle development. Further, CAN interfaces that support OBD2 requests can be useful as part of reverse engineering proprietary CAN bus parameters.
OBD2 loggers: Used to log OBD2 data from a car to an SD card - ideal for e.g. blackbox use cases or prototype field tests by automotive OEMs. As an example, the CANedge1 lets you log CAN bus data, as well as request OBD2 data by sending custom frame requests to the CAN bus.
WiFi OBD2 logger: WiFi OBD2 loggers and WiFi OBD2 dongles enable the automated transfer of OBD2 data via WiFi (incl. 3G/4G) to a server/cloud. WiFi OBD2 loggers are typically used for OBD2 telematics use cases, where car fleet data needs to be collected automatically and visualized via OBD2 data dashboards. For example, the CANedge2 lets you log CAN/OBD2 data and auto-push it via a WiFi accces point to your own server. The data can be processed in free software tools and e.g. visualized in Grafana dashboards.
The CANedge2 makes it easy to log OBD2 data to an SD card - and upload it via WiFi to your own server.
For more intros, see our guides section - or download the 'Ultimate Guide' PDF.
Need to log/stream OBD2 data?
Get your OBD2 data logger today!