This article describes the OBD2 (On Board Diagnostic) protocol, which includes the OBD2 connector, the OBD2 PIDs (parameter IDs) in relation to 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.

What is OBD2?

In short, OBD2 – On Board Diagnosticsll is your car’s self-diagnostic system.

You may have been exposed to OBD2 for a long time:

Try to remember if you noticed the malfunction indicator light suddenly popping up on your dashboard?

This means that your car is giving you feedback that something is wrong with it. If you go to a mechanic for help, he will use an OBD2 scanner to diagnose it.

Usually, he will connect the OBD2 scanner to your vehicle through the OBD2 16-pin connector so that the mechanic can read the OBD2 codes one by one diagnostic trouble codes to determine what the trouble problem is.

OBD2 Connector

You can easily access the data in your vehicle through the OBD2 connector.Two OBD2 female 16-pin connector types (A and B) are specified in the SAE J1962 standard.

An example of a Type A OBD2311 pin connector, sometimes referred to as a DLC (Data Link Connector), is shown.

Note:

Do our car have OBD in?

Basically all of cars

Almost all cars built in the last few years support OBD2 and most are CAN (ISO 15765) based. For older vehicles, be aware that even if there is a 16-pin OBD2 connector, it may not support OBD2.One way to determine if OBD2 is present on your vehicle is to look at when and where you purchased the product.

The chart below shows the countries and years where OBD2 is adapted:

Connecting OBD2 and CAN

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 stating that the OBD2 standard specifies the OBD2 connector that can be run by 5 protocols. However, since 2008, the CAN bus (ISO 15764) has mandated the mandatory application of OBD2 to all cars sold in the US, which essentially eliminates the other 4 protocols.

ISO 15765 refers to a set of CAN standards for restricted applications, which are defined by 1 ISO 11898. ISO 11898 is also known as CAN depending on the automobile.

In addition, OBD2 is similar to other high-level protocols such as J1939 and CANopen.

The histor of OBD2

OBD2 originated in California, where the California Air Resources Board (CARB) has required the use of OBD on all new vehicles since 1991 for emission control purposes.

The Society of Automotive Engineers (SAE) and the manufacturers of standardized adapters and OBD adapters (SAE 1j1962) jointly recommend the use of the OBD2 standard.

The OBD2 standard is being introduced step by step in the following order:

The Future of OBD2

What form will OBD2 take in the future?

The following two potential pathways may fundamentally change OBD2:

OBD3 wireless transmission test

In today’s age of smart, connected cars, the OBD2 test seems a bit cumbersome: emissions controls need to be performed manually, which makes the check both time-consuming and expensive.

OBD3 can solve these problems by adding telematics to all cars.

Basically, OBD3 adds a small radio transponder (like a gateway) to all cars. In this way, vehicle identification numbers (CVINs) and DTCs can be sent via WiFi to a central server for checking.

Nowadays, many CAN and OBD2 devices can accomplish data transfer via witi/mobile networks one example is the CANedge2 Wifl version of the CAN logger.

This is convenient and cost effective, but politically it is a challenge for regulatory reasons.

Reduction of 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 type data one by one via OBD2 encryption software and CAN loggers, etc. However, the German automotive industry is looking for ways to change this. However, the German automotive industry is looking for ways to change this.

Eliminating third-party OBD2 services and suggesting that OBD2 services be stopped while driving and that the relevant data be collected on a centralized server would allow automakers to control the “big data.”

While many identify OBD2 third-party services as commercial, this argument is based on security concerns (e.g., eliminating the risk of car hacking). Whether this will become a definite trend remains to be seen but it could really disrupt the market for OBD2 third party services.

OBD2’ PID

Why do we care about OBD2 data?

Engineers are obviously more concerned about OBD2 DTCS (and users probably are as well), yet regulatory agencies need 0BD2 to control emissions.

But OBD2 also supports a wide range of standard parameters that can be recorded by most cars.

This means you can easily get readable OBD2 data from your car, including speed, RPM, throttle position, and more.

In other words, OBD2 makes it easy for you to analyze your car’s relevant data – OEM-specific proprietary raw data.

Decoding OBD2 and CAN bus data

In principle, it is simple to record the original CAN frames from the car. If a CAN logger is connected to the OBD2 connector, it will immediately start recording the broadcast data from the CAN bus. However, the raw CAN messages need to be decoded by means of a conversion rule database and such databases are usually proprietary, thus no useful information can be obtained from the raw CAN data.

Car hackers can attempt to reverse engineer the conversion rules, although this is technically quite advanced. However, CAN is still the only way to get “full access” to a car’s data, while OBD2 only provides access to a limited portion of the data.

How to record OBD2 data

OBD2 data logging works as follows:

In other words, a CAN logger capable of sending custom CAN frames can also be used as an OBD2 logger.

Please note that cars vary by model/year in terms of supported OBD2 PIDs. See our OBD2 Data Logger Guide for more information.

CANedge OBD2 Data Logger

CANedge allows you to easily log OBD2 data to an 8-32 GB SD card. All you need to do is specify the OBD2 PID you want to request and connect it to your car via the OBD2 adapter to start logging. Finally the data is processed by the free software / AP1 and our OBD2 DBC.

Raw OBD2 message details

If you want to start logging OBD2 data, it would be very helpful for yo to understand the basics of the original OBD2 message structure first.

In short, OBD2 messages contain identifiers and data. In addition, the data is broken down by service, PID, and data node (A, B, C, D) and is shown in the figure below:

OBD2 Information Segment Explanation

Identifier: For OBD2 messages, the identifier is a standard 11-bit number that distinguishes between a “request message” (D 7DF) and a “response message” (D 7E8 to 7EF). Note that 7E8 is usually the D of the host or ECU response.

Valid bits: The number of bytes (03 through 06) used to reflect the data for this frame only. For this example of “Car Speed”, the valid bit of the request frame is 02 (because it follows only 01 and OD), while the valid bit of the response frame is 03, because it follows 41, 0D and 32.

Service: For requests, this will be asked in 01-0A. For responses, replace the port with 4 (i.e., 41, 42, ……, 4A). There are 10 services as described in the SAE J1979 0BD2 standard. Mode 1 displays current data, e.g. for viewing real-time speed, RPM, etc. Other modes are used e.g. to display or clear stored diagnostic trouble codes and to display freeze frame data.

PID: For each service, a list of standard OBD2 PIDs exists, e.g., in 01 service, PID OD is vehicle speed. For a complete list, see the Wikipedia OBD2 PID overview. Each PID has a description, and some PIDs have specified minimum or maximum values and conversion formulas.

For example, with only the parameter A, the formula for speed is to convert the hexadecimal A to decimal to get the km / h converted value (i.e. 32 becomes 50km/ hl or more) Then, for example, for RPM (PID OC), the formula is (256*A + B) 14.

A, B, C, D: These are data bytes in hexadecimal that 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.

Example of OBD2 data logging

OBD2 data from cars and light trucks can be applied to a variety of cases:

Recording of automotive data

OBD2 data from cars can be used to reduce fuel consumption, improve driving behavior, test new parts and insurance matters

Real-time automotive diagnostics

The OBD2 interface can be used for real-time transmission of human-readable OBD2

Predictive maintenance

Cars and light trucks can be monitored via loTOBD2 loggers in the cloud to predict and avoid breakdowns

Vehicle black box recorders

The OBD2 logger can be used as a “black box” for vehicles or equipment, e.g. to provide data for disputes or diagnostics.

What kind of OBD2 logger is needed?

Below we have outlined the most common OBD2 analyzer categories:

OBD2 Diagnostics: used by the repairman to statically read or clear DTCs when troubleshooting a vehicle (e.g., possibly MIL light related). various conditions exist.

OBD2 Recorder: For recording OBD2 data from the vehicle to an SD card, ideal for e.g. black box or new parts field testing. The WiFi enabled version can also be used for e.g. in-vehicle telematics.

OBD2 interface: Provides real-time OBD2 data via USB, for example, and is typically used in professional diagnostics and OEM vehicle development.

The more specialized OBD2 interface can also be used to transfer OBD2 data as well as dedicated CAN bus data, which is useful for CAN sniffing and car hacking.

J&B

Lastest news View all