OBD2 is a core topic in automotive data logging - from car diagnostics to vehicle fleet optimization.
WHAT IS OBD2?
On-Board Diagnostics (OBD) is your vehicle’s built-in self-diagnostic system
You've probably encountered OBD2 already:
Ever noticed that malfunction indicator light pop up on your dashboard?
That’s your car telling you there’s an issue and you should visit a mechanic.
In the past, this would just indicate an issue - but no further guidance!
Today, your mechanic will use an OBD2 scanner to identify the cause.
To do so, he'll connect the OBD2 reader to the OBD2 16 pin connector near the driver’s wheel (see below).
This let's him read the OBD2 codes AKA Diagnostic Trouble Codes (DTCs) and understand the issue. Without taking the car apart!
The OBD2 Connector
The OBD2 connector lets you access data from your car easily - but what is it really?
The OBD2 standard (SAE J1962) specifies two female OBD2 16-pin connector types (A & B).
Below is an example of a Type A OBD2 pin connector (also sometimes referred to as the Data Link Connector, DLC):
Key things to note:
- The OBD2 connector is near your steering wheel, but may be hidden behind covers/panels
- Not all male connectors fit all OBD2 female sockets - check the type and OBD pin-outs
- Pin 16 supplies power via the car's battery - often also while the ignition is off
- Pins 6 (CAN-H) & 14 (CAN-L) are most relevant as CAN (ISO 15765-4) is standard in most modern cars (incl. EVs)
OBD2 vs. CAN Bus - What’s the Difference?
For those of you confused:
OBD2 is a ‘higher layer protocol’ (think of it as a language) while CAN bus is a method for communication (like a telephone).
The OBD2 standard specifies the OBD2 connector, incl. a set of five protocols that it can run on.
Since 2008, CAN bus (ISO 15765) has been the mandatory protocol for OBD2 in all cars sold in the US,
which basically eliminates the other 4 protocols over time.
Note here that ISO 15765 refers to a set of restrictions applied to the CAN standard, which is defined via ISO 11898.
One might say that ISO 15765 is like "CAN for cars".
Also, OBD2 may be compared to other higher layer protocols like J1939 and CANopen.
Does My Car Have OBD2?
In short: Probably!
Almost all newer cars use the OBD2 protocol and most run on CAN (ISO 15765) as outlined above.
For older cars, be aware that even if a 16 pin OBD2 connector is present, it may still not support OBD2.
The best way to determine if it's compliant is to identify where & when it was bought new.
To help you out, we've made a simple flow chart below:
OBD2 History - A Step-By-Step Roll-Out
The system 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 was made mandatory across USA for cars and 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 were required to use ISO 15765-4 (a variant of CAN) as basis for OBD2
- 2010: Finally, OBD2 was required in US heavy duty vehicles
Today, the OBD2 standard is vital in facilitating easy error resolution.
The Future of OBD2
OBD2 is here to stay - but in what form?
Two potential routes may radically change OBD2 - click below to learn more:
In today's world of connected cars, OBD2 is a bit old fashioned:
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's 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 CL3000 WiFi CAN logger.
This saves cost and is definitely convenient - but it is also politically a challenge due to the 'big brother' aspect.
For a nice detailing of this, see this overview by AutoTap.
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 PIDs: HOW TO LOG & READ OBD2 DATA
In this section we explain:
- OBD2 Parameter IDs (PIDs)
- How to interpret the OBD2 message
- How to record OBD2 data in practice
Why should you care about OBD2 data?
Mechanics obviously care about the DTCs (maybe you do too), while regulatory entities need it to control emission.
But OBD2 actually supports a broad range of standard parameter IDs (PIDs) that can be logged across most cars.
This means that you can e.g. get human-readable live OBD2 data from your car on speed, RPM, throttle position and more!
But, can't you just get this data directly from the CAN bus?
Not necessarily since the raw CAN data in most cars is proprietary - for details, expand the below:
In principle it is simple enough to log the raw CAN frames from your car.
If you e.g. connect a CAN logger to the OBD2 connector, you'll start receiving broadcasted CAN bus data easily.
However, the raw CAN messages need to be decoded via a database of conversion rules/parameters, which is typically proprietary.
And without these rules, the CAN data is not readable.
Car hackers may try to reverse engineer the rules, though this is technically rather advanced.
CAN is, however, still the only method to get "full access" to your cars data - making car hacking a global sport.
OBD2 is the simplest way to get basic human-readable data from your vehicle.
Wikipedia has an excellent article on the standardized OBD2 PIDs.
We also offer a OBD2 online converter tool where you can enter a message to return the PID info and converted data.
Finally, you can also check out some of our customer OBD2 use cases.
OBD2 PIDs & Messages Explained
To get started recording OBD2 data, it’s helpful to understand the basics of the 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 Ah, Bh, Ch, Dh (in hexadecimal values) - cf. the figure below.
An example of a request/response CAN message for the PID 'Vehicle Speed' with a value of 50 km/h can look like this:
Request: 7DF 02 01 0D 55 55 55 55 55
Response: 7E8 03 41 0D 32 aa aa aa aa
(Here the 32 is the hexadecimal value of 50).
Try to enter the response message (excl. 7e8 03) in our OBD2 message converter to confirm the result.
Below, each part of the OBD2 message is explained:
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 the aforementioned Wikipedia OBD2 PID overview. Each PID has a description and some have a specified minimum/maximum and conversion formula.
The formula for speed is e.g. simply A, meaning that the Ah 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.
>Ah, Bh, Ch, Dh: 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.
How to Log OBD2 Data?
OBD2 data logging works as follows:
- You connect a OBD2 scanner or OBD2 data logger to the OBD2 16 pin connector
- Via the tool, you enter “request messages” (queries) transmitted via the CAN-bus
- The relevant ECUs react and send “response messages” via the CAN-bus
This stuff is important:
It means that you will not see OBD2 data if you just plug in a "passive" logger or interface to your car.
(This would however yield raw CAN data since this is "broadcasted").
To log OBD2 response messages, your OBD2 data logger needs to be able to send the request messages.
For an example of requests/responses, check out a practical OBD2 PID logging example with the CL2000.
The above example is deliberately manual - we also have a simpler way to log OBD2 data.
What OBD2 recorder do I need?
Several options exist - below we outline the main OBD2 analyzer categories:
OBD2 SCANNERS / CODE READERS: Used mainly in static reading/clearing of diagnostic trouble codes. They are e.g. used by mechanics to look up the underlying issue behind a malfunction indicator lamp (MIL). Various types exist.
OBD2 DATA LOGGERS: Used to log OBD2 data from a car over time onto e.g. an SD card - this can be helpful for post analysis and to e.g. analyse patterns, correlations etc. Further, for diagnostic / optimization purposes a data logger provides a “black box” view of data patterns before and after a diagnostic code has kicked in.
OBD2 data loggers with Bluetooth or WiFi are also used in e.g. vehicle fleet management to improve fuel efficiency, prevent unsafe driving, and allow proactive remote diagnostics via the OBD2 supported parameters.
OBD2 DATA INTERFACES: Used to provide live real-time data on various OBD2 parameters. Applications can include visual displays/apps that guide the driver on fuel or performance efficiency, or as a live health check.
More advanced OBD2 interfaces can also be used to stream OBD2 data along with proprietary CAN bus data, which can be useful for CAN sniffing and car hacking.
Further, hybrids also exist - the CLX000 series can e.g. act as both an OBD2 data logger & interface.
Where can I learn more?
Check out our GUIDES section for more intros, guides & use cases - incl. our J1939 telematics intro below.
Want to log OBD2 data from your car?
Then learn more about our CLX000 CAN logger below!
Liked this article? Please share!
RECOMMENDED FOR YOU