On-board diagnostics: what OBD and OBD2 actually do
Vehicle diagnostics

On-board diagnostics: what OBD and OBD2 actually do

When a dashboard warning light comes on, that is on-board diagnostics at work. OBD is the system a vehicle uses to watch its own subsystems, record faults and report them through a standard socket. This guide explains what OBD and OBD2 are, how a tool talks to the car over CAN and how to read the parameters and fault codes it returns.

9 min read2 demosUpdated 2026
1996
OBD2 required on US cars
16-pin
the J1962 connector
10 modes
standard OBD services
CAN
carries OBD2 since 2008
The short answer

On-board diagnostics is a vehicle's built-in ability to watch its own systems, record faults and report them through a standard socket. The control units monitor the engine, the emissions system and much else. When something is wrong they store a fault code, and if it matters they light the warning lamp on the dashboard. A technician plugs a tool into the OBD socket to read live readings and those stored codes, which turns a vague warning light into a specific place to look. OBD2 is the standardised second generation: required on cars sold in the United States from 1996, with a common connector, common fault codes and, on modern vehicles, CAN underneath.

OBD-I and OBD-II at a glance
FeatureOBD-IOBD-II
Eraearly 1980s1996 onward in the US
Connectormaker-specificstandard 16-pin J1962
Fault codesmaker-specificstandardised DTCs
How it was readoften a blinking warning lampa scan tool over a data link
Lower layermaker-specificCAN since 2008, under ISO 15765
Scopeemissions basicsemissions plus many subsystems
Why OBD exists

Built for emissions, useful for everything

The reason OBD exists at all is emissions. Regulators needed a way to be sure a car's emissions controls kept working across its whole life, not just on the day it left the factory. So cars were required to monitor themselves and raise a flag whenever a fault appeared that could push emissions up. That is why the same warning lamp that means so many things is, underneath, an emissions watchdog.

The happy side effect is that this self-diagnosis turned out to be useful far beyond the tailpipe. The same channel gives a technician, or a data logger, a standard window into the engine, the transmission and other systems. Instead of guessing at a fault, you read what the vehicle already knows. It helps to keep two terms apart. On-board diagnostics runs inside the vehicle while it operates and watches continuously. Off-board diagnostics is the separate workshop equipment connected afterwards to dig deeper. OBD is the on-board half that everything else builds on.

It grew up in stages. Early systems in the late 1970s and 1980s were used to test the engine control module on the assembly line, and the only output was a blinking lamp whose flash pattern stood for a basic fault. In 1988 California's Air Resources Board required all new cars in the state to have some basic capability, but the connector, the protocol and even the socket location were left open. That first generation became known as OBD-I after the fact. The Society of Automotive Engineers then recommended a standard connector and set of test signals, and in 1996 OBD-II was made mandatory for cars sold in the United States, with a common socket and common codes. Europe followed for petrol cars from 2001. From 2008, CAN became the required layer underneath OBD2 in the US.

The connector and CAN

One socket, riding on CAN

The part everyone has seen is the socket. OBD2 uses a standard 16-pin connector, known by its standard number J1962, usually tucked under the dashboard within reach of the driver's seat. Some of its pins are fixed by the standard, including the CAN pins on a modern car, and the rest are left to the vehicle maker. Plug a compatible tool into that socket and you have a standard way in, whatever the brand of car.

What travels through it is worth being precise about, because it is the same split this series keeps returning to. OBD2 is a higher-layer protocol, a language. CAN is the lower layer that physically carries the messages. OBD2 defines the requests you can make, the parameters you can ask for and the codes that come back, while CAN moves the bytes. That makes OBD2 a sibling of J1939, CANopen and the other higher-layer protocols that all ride on CAN. Since 2008, CAN under the ISO 15765 standard, sometimes called diagnostics over CAN, has been the required lower layer for OBD2 in the United States. Older vehicles used other links such as ISO 9141, Keyword Protocol 2000 or J1850.

The exchange itself is simple in shape. A tool sends a request in, the control unit that owns the answer responds, and the tool reads it back. The next two sections open up the two things those messages carry: the live parameters, and the fault codes.

Scan tool or logger OBD port 16-pin J1962 CAN bus Engine ECM Gearbox TCM ABS unit
The tool plugs into the standard OBD socket, which sits on the same CAN bus as the control units. One connection reaches every unit that answers OBD requests.
Asking for data

PIDs and modes

Two ideas run the request side of OBD2: modes and parameter IDs. A mode, also called a service, groups requests by the kind of information you want. There are ten standard ones. The handful you meet most: mode 01 gives current live data, mode 02 returns a freeze frame, a snapshot of the conditions when a fault was set, mode 03 lists the stored fault codes, mode 04 clears those codes and the warning lamp, and mode 09 reports vehicle information such as the VIN.

Within a mode, a Parameter ID, or PID, names the exact value. In mode 01, PID 0x0C is engine speed, PID 0x0D is vehicle speed, and so on through a long standard list. The important part is that the standard, SAE J1979, defines not just the PID numbers but the formula that turns the raw bytes an ECU returns into a real value. A reading therefore has three steps: the tool asks for a mode and a PID, the ECU replies with a few data bytes, and a formula converts them into something with units. The calculator below runs that last step for the common parameters, and shows the request and response frames around it.

OBD2 PID calculator

Pick a mode 01 parameter, then enter the raw data byte or bytes the ECU returned, as hex like 0x1A or as a number. The value is decoded with the standard formula.

Request0x7DF
Response0x7E8
0

The request asks all OBD2 units on the bus with the functional ID 0x7DF. The unit that owns the value replies on 0x7E8, with the mode echoed back as mode plus 0x40, so 0x41 for a mode 01 reply.

The fault codes

Diagnostic trouble codes

When a control unit stores a fault, it stores it as a Diagnostic Trouble Code, or DTC, and every DTC has the same shape: a letter followed by four characters. The structure is worth knowing, because it tells you a lot before you even look the code up. The letter says which system raised it. P is powertrain, the engine and transmission. C is chassis. B is body. U is network and communication between units.

The first character after the letter says where the code is defined. A 0 means a generic code, set by the standard and the same across every maker. A 1 means a manufacturer-specific code, defined by that carmaker. The remaining characters point at the specific fault. So P0301 is a powertrain, generic code for a misfire on cylinder 1, while P0300 is a random or multiple-cylinder misfire. These are the codes that mode 03 reads back and mode 04 clears. Break one apart below.

DTC decoder

Enter a five-character code such as P0301 to see what each part means.

The decoder reads the structure of the code, the system and whether it is generic or manufacturer-specific. The exact meaning of the last digits comes from a DTC list for that system or vehicle.

In practice

Reading OBD in the real world

Reading OBD comes down to plugging a tool into the socket and choosing what to ask for. The tools span a wide range. At one end is a cheap handheld reader that simply shows stored codes and clears them. At the other are PC applications and data loggers that record live PIDs across a whole drive, so you can see how a value behaved over time rather than just its reading at one moment.

Underneath, the exchange on CAN has a neat trick. A request goes out on a functional identifier, 0x7DF, that every OBD2 unit on the bus listens to. Rather than the tool needing to know which unit holds a value, whichever one owns the answer simply replies on its own identifier, most often 0x7E8 for the engine controller. The illustration below follows one request and its reply.

Tool Engine 0x7E8 Gearbox 0x7E9 0x7DF request: mode 01, PID 0C every OBD2 unit hears 0x7DF 0x7E8 response: 41 0C 1A F8 no data, stays quiet 41 0C 1A F8 maps to RPM = (256 x 0x1A + 0xF8) / 4 = 1726
The tool broadcasts one request. The unit that owns the value answers on its own identifier, here the engine unit on 0x7E8, and the response bytes decode to a real reading.
The takeaway

OBD is the standard way a vehicle reports on itself. Plug into the J1962 socket, speak OBD2 over CAN, ask for a parameter by its mode and PID, and read fault codes as DTCs. One socket, one language, the same across nearly every modern vehicle.

Common questions

OBD and OBD2 FAQ

What is the difference between OBD and OBD2?

OBD is the general idea of a vehicle diagnosing itself and reporting faults. OBD2 is the standardised second generation, with a common 16-pin connector, common fault codes and, on modern cars, CAN underneath. It has been required on cars sold in the United States since 1996, which is why almost any modern vehicle can be read with the same tool.

Where is the OBD2 port?

Usually under the dashboard, within reach of the driver's seat, though the exact spot varies by vehicle. It is a 16-pin connector known by its standard number, J1962. Some of its pins are fixed by the standard and the rest are left to the maker.

Is OBD2 the same as CAN?

No. OBD2 is a higher-layer protocol, the language of requests, parameters and codes. CAN is the lower layer that physically carries the messages. Since 2008, CAN under ISO 15765 has been the required layer beneath OBD2 in the United States, but the two are different things working together.

What is a PID?

A Parameter ID, a number that names a specific value such as engine speed or coolant temperature. The SAE J1979 standard defines the common PIDs and the formula to turn the raw bytes into a real reading. A tool requests a PID by its mode and number, and the control unit returns the data to decode.

What does a code like P0301 mean?

The letter is the system, here P for powertrain. The first digit shows whether the code is generic or manufacturer-specific, here 0 for generic. The remaining characters identify the fault, here a misfire on cylinder 1. So P0301 is a standard powertrain code for a cylinder-1 misfire, while P0300 is a random or multiple-cylinder misfire.

Can Influx Technology loggers read OBD2?

Yes. The data loggers from Influx Technology support OBD2 logging, and with the Module Analyser software they work as a PC scan tool across the OBD modes, preloaded with standard PIDs and DTCs.

Written by the engineering team at Influx Technology. OBD2 behaviour follows the SAE J1979 and ISO 15765 standards. Confirm details for the vehicle you are working on.

Log it yourself

Log OBD2 data with the REBEL range

The data loggers from Influx Technology log OBD2 over CAN, and with the Module Analyser software they double as a PC scan tool across the OBD modes. Standard PIDs and DTCs come preloaded.