This article introduces the OBD2 (On Board Diagnostic) protocol, which includes the OBD2 connector, OBD2 PID (parameter IDs) and the relationship with the CAN bus.
Note: This is a practical introduction, so you will also learn how to request and decode OBD2 data, key logging use cases, and application tips.
In short, OBD2 - On Board Diagnostics II is a self-diagnosis system for your car.
You may have already been exposed to OBD2:
Try to recall, did you notice that the malfunction indicator light suddenly popped up on your dashboard?
This means your car is reporting to you that there is something wrong with it. If you go to a repairman, he will use an OBD2 scanner to diagnose.
Usually, he will connect the OBD2 scanner to your vehicle through the OBD2 16-pin connector, so that the mechanic can read the OBD2 code - the diagnostic trouble code to determine the problem.
You can easily access the data in the car through the OBD2 connector. Two OBD2 female 16-pin connector types (A and B) are specified in the SAE J1962 standard.
Pictured is an example of a Type A OBD2 pin connector (sometimes called DLC (Data Link Connector)).
have to be aware of is:
The OBD2 connector is around the steering wheel, but may also be under the pads or behind the dash
· Not all male headers fit all OBD2 female headers, check the connector type and OBD pins
· Pin 16 is connected to the car battery, which is usually connected after the flame is turned off
Pin 6 (CAN - H) and pin 14 (CAN-L) are the most important as CAN (ISO 15765-4) is standard on most modern cars (including EVs)
Basically there are!
Almost all cars produced in recent years support OBD2 and most are CAN (ISO 15765) based. For older cars, be aware that even though there is a 16-pin OBD2 connector, it may not support OBD2. One way to determine if you have OBD2 on your vehicle is to see where and when you purchased the product.
The following figure shows the countries and years that are compatible with OBD2:
CAN bus is a telephone-like communication method, while OBD2 is a high-level protocol that can be understood as a language.
It is worth noting that the OBD2 connector specified by the OBD2 standard can be run by 5 protocols. However, since 2008, the CAN bus (ISO 15764) mandates OBD2 for all cars sold in the US, essentially eliminating the other 4 protocols.
ISO 15765 refers to a set of CAN standards with limited application, which is defined by ISO 11898. ISO11898 is also known as CAN for cars.
In addition, OBD2 is similar to other high-level protocols such as J1939 and CANopen.
OBD2 originated in California, and the California Air Resources Board (CARB) has required all new cars to use OBD since 1991 to achieve the purpose of controlling emissions.
The Society of Automotive Engineers (SAE) and the Standardized Transition and OBD Adapter Manufacturers (SAE j1962) jointly recommend the use of the OBD2 standard.
The OBD2 standard was introduced step by step in the following order:
1996: OBD2 was made mandatory for cars/light trucks in the US
2001: Applied to EU gasoline vehicles
2003: Diesel vehicles in the EU
2005: U.S. requires OBD2 for medium-duty vehicles
2008: US cars must use ISO 15765-4 (CAN) as OBD2 basis
2010: U.S. requires OBD2 for heavy-duty vehicles
What form will OBD2 take in the future?
The following two potential pathways could fundamentally alter OBD2:
OBD3 wireless transmission test
In this age of connected cars, OBD2 testing can seem a bit cumbersome: manual emissions controls are required, making inspections time-consuming and expensive.
OBD3 can add telematics to all cars to solve the above problems.
Basically, OBD3 adds a small radio transponder (like a gateway) to all cars. In this way, Vehicle Identification Numbers (VINs) and DTCs can be sent via WiFi to a central server for checking.
Nowadays, many CAN and OBD2 devices can complete data transmission via Wifi/mobile network - such as the CANedge2 Wifi version of the CAN logger .
This is convenient and cost-effective, but it is also a challenge from a political point of view due to regulatory concerns.
Reduce third-party OBD2 services
As mentioned above, the OBD2 protocol was originally designed to control emissions.
However, OBD2 is now widely used by third-party developers to generate real-time data - via OBD2 encryption software, CAN loggers, etc. However, the German auto industry is looking for ways to change that.
Eliminating third-party OBD2 services, it is recommended to stop OBD2 services while driving, and instead collect relevant data on a central server, which allows automakers to control "big data".
While many consider OBD2's third-party services to be commercial, this argument is based on security considerations (eg, eliminating the risk of car hacking). It remains to be seen whether this will become a certain trend - but it could really disrupt the market for OBD2 third-party services.
Why do we care about OBD2 data?
Engineers are obviously more concerned with OBD2 DTCs (and users may be too), yet regulatory agencies need OBD2 to control emissions.
But OBD2 also supports an extensive set of standard parameters that can be recorded by most cars.
This means you can easily get readable OBD2 data from your car including speed, revs, throttle position and more.
In other words, OBD2 makes it easy to analyze data about your car - OEM specific and proprietary raw data.
Decode OBD2 and CAN bus data
In principle, recording raw CAN frames from the car is simple. If you connect a CAN recorder to the OBD2 connector, it will start recording broadcast data from the CAN bus immediately. However, the raw CAN messages need to be decoded through a database of transformation rules, and such databases are often proprietary, so that no useful information can be obtained from the raw CAN data.
Car hackers can try to reverse engineer the conversion rules, although this is quite technically advanced. However, CAN is still the only way to "completely get" the car's data, and OBD2 only provides access to a limited portion of the data.
How to record OBD2 data
OBD2 data logging works as follows:
You connect the OBD2 recorder to the OBD2 connector
With the tool you can send a "request frame" over CAN
The relevant ECU sends a "response frame" via CAN
In other words, a CAN logger capable of sending custom CAN frames can also be used as an OBD2 logger.
Note that cars vary by model/year in terms of supported OBD2 PIDs. See our OBD2 data logger guide for details.
Autel MaxiCOM MK808BT diagnostic scan tool enables wireless vehicle diagnostics up to 33 feet (10 meters). Connecting the MK808BT with the MaxiVCI Mini, Autel MK808BT scanner can communicate with the vehicle’s data link connector(DLC) wirelessly for vehicle data and run diagnostic.
If you want to start recording OBD2 data, it is very helpful to understand the basics of the original OBD2 message structure first.
In short, OBD2 messages contain identifiers and data. Additionally, the data is split by service, PID, and data bytes (A, B, C, D) and shown in the following diagram:
Identifier : For OBD2 messages, the identifier is the standard 11 bits used to distinguish between "request messages" (ID 7DF) and "response messages" (IDs 7E8 to 7EF). Note that 7E8 is usually the ID the host or ECU responds to.
Valid bits : Only used to reflect the number of bytes (03 to 06) of this frame of data. For this example of "vehicle speed", the valid bits of the request frame are 02 (because only 01 and 0D follow), and the valid bits of the response frame are 03, since 41, 0D and 32 follow.
Service : For requests, this will be between 01-0A. For the response, replace 0 with 4 (i.e. 41, 42, ..., 4A). There are 10 services as described in the SAE J1979 OBD2 standard. Mode 1 displays current data, for example for viewing real-time vehicle speed, RPM, etc. Other modes are used, for example, to display or clear stored DTCs and display freeze frame data.
PID : For each service, there is a list of standard OBD2 PIDs, for example, in the 01 service, PID 0D is the vehicle speed. For a complete list, check out the Wikipedia OBD2 PID overview. Each PID has a description, and some PIDs have a specified minimum or maximum value and a conversion formula.
For example, there is only parameter A, the formula for speed is to convert A in hexadecimal to decimal to get the value after km/h conversion (ie 32 becomes more than 50 km/h) For another example, for RPM (PID 0C), the formula is (256*A+B)/4.
A, B, C, D : These are the data bytes in hexadecimal and need to be converted to decimal form before they can be used in PID formula calculations. Note that the last data byte (after Dh) is not used.
OBD2 data record example
OBD2 data from cars and light trucks can be used in a variety of cases:
record car data
OBD2 data from cars can be used to reduce fuel consumption, improve driving behavior, test new parts and insurance matters
real-time car diagnostics
The OBD2 interface can be used to transmit human-readable OBD2 data in real time, e.g. for vehicle diagnostics
predictive maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and avoid failures
vehicle black box recorder
OBD2 recorders can be used as a "black box" for a vehicle or device, for example to provide data for disputes or diagnostics
Below we outline the most common categories of OBD2 analyzers :
OBD2 diagnostic instrument : It is used to statically read or clear DTC when the maintenance technician diagnoses vehicle faults (for example, it may be related to MIL lights). Various situations exist.
OBD2 Logger : Used to record OBD2 data in the car to SD card, ideal for example black box or field testing of new parts. A WiFi-enabled version is also available, for example, for in-vehicle telematics.
OBD2 interface : provides real-time OBD2 data via USB for example, typically used in professional diagnostics and OEM vehicle development.
The more specialized OBD2 interface can also be used to transmit OBD2 data as well as dedicated CAN bus data, which is useful for CAN sniffing and car hacking.
Leave a comment