OBD-II PIDs


OBD-II PIDs are codes used to request data from a vehicle, used as a diagnostic tool.
SAE standard J1979 defines many OBD-II PIDs. All on-road vehicles and trucks sold in North America are required to support a subset of these codes, primarily for state mandated emissions inspections. Manufacturers also define additional PIDs specific to their vehicles. Though not mandated, many motorcycles also support OBD-II PIDs.
In 1996, light duty vehicles were the first to be mandated followed by medium duty vehicles in 2005. They are both required to be accessed through a standardized data link connector defined by SAE J1962.
Heavy duty vehicles made after 2010, for sale in the US are allowed to support OBD-II diagnostics through SAE standard J1939-13 according to CARB in title 13 CCR 1971.1. Some heavy duty trucks in North America use the SAE J1962 OBD-II diagnostic connector that is common with passenger cars, notably Mack and Volvo Trucks, however they use 29 bit CAN identifiers.

Services / Modes

There are 10 diagnostic services described in the latest OBD-II standard SAE J1979. Before 2002, J1979 referred to these services as "modes". They are as follows:
Service / Mode Description
#Service 01|Show current data
#Service 02|Show freeze frame data
#Service 03|Show stored Diagnostic Trouble Codes
#Service 04|Clear Diagnostic Trouble Codes and stored values
#Service 05|Test results, oxygen sensor monitoring
Test results, other component/system monitoring
Show pending Diagnostic Trouble Codes
Control operation of on-board component/system
#Service 09|Request vehicle information
Permanent Diagnostic Trouble Codes

Vehicle manufacturers are not required to support all services. Each manufacturer may define additional services above #9 for other information e.g. the voltage of the traction battery in a hybrid electric vehicle.
The nonOBD UDS services start at 0x10 to avoid overlap of ID-range.

Standard PIDs

The table below shows the standard OBD-II PIDs as defined by SAE J1979. The expected response for each PID is given, along with information on how to translate the response into meaningful data. Again, not all vehicles will support all PIDs and there can be manufacturer-defined custom PIDs that are not defined in the OBD-II standard.
Note that services 01 and 02 are basically identical, except that service 01 provides current information, whereas service 02 provides a snapshot of the same data taken at the point when the last diagnostic trouble code was set. The exceptions are PID 01, which is only available in service 01, and PID 02, which is only available in service 02. If service 02 PID 02 returns zero, then there is no snapshot and all other service 02 data is meaningless.
When using Bit-Encoded-Notation, quantities like C4 means bit 4 from data byte C. Each bit is numbered from 0 to 7, so 7 is the most significant bit and 0 is the least significant bit.

Service - Show current data

Service - Show freeze frame data

Service accepts the same PIDs as service, with the same meaning, but information given is from when the freeze frame was created. Note that PID is used to obtain the DTC that triggered the freeze frame.
A person has to send the frame number in the data section of the message.

Service - Show stored Diagnostic Trouble Codes (DTCs)

Service - Clear Diagnostic Trouble Codes and stored values

Service - Test results, oxygen sensor monitoring (non CAN only)

Service - Request vehicle information

Bitwise encoded PIDs

Some of the PIDs in the above table cannot be explained with a simple formula. A more elaborate explanation of these data is provided here:

Service 01 PID - Show PIDs supported

A request for this PID returns 4 bytes of data. Each bit, from MSB to LSB, represents one of the next 32 PIDs and specifies whether that PID is supported.
For example, if the car response is, it can be decoded like this:
So, supported PIDs are:,,,,,,,,,,,,,,, and

Service 01 PID - Monitor status since DTCs cleared

A request for this PID returns 4 bytes of data, labeled A, B, C and D.
The first byte contains two pieces of information. Bit indicates whether or not the MIL is illuminated. Bits through represent the number of diagnostic trouble codes currently flagged in the ECU.
The second, third, and fourth bytes give information about the availability and completeness of certain on-board tests. The third and fourth bytes are to be interpreted differently depending upon whether the engine is spark ignition or compression ignition. In the second byte, bit indicates the engine type and thus how to interpret bytes C and D, with being spark and being compression. Bits to and to are used for information about tests that not engine-type specific, and thus termed common tests. Note that for bits indicating test availability a bit set to indicates available, whilst for bits indicating test completeness a bit set to indicates complete.
BitsDefinition
State of the CEL/MIL.
-Number of confirmed emissions-related DTCs available for display.
Reserved
-Bitmap indicating completeness of common tests.
Indication of engine type
= Spark ignition
= Compression ignition
-Bitmap indicating availability of common tests.
-Bitmap indicating availability of engine-type specific tests.
-Bitmap indicating completeness of engine-type specific tests.

Bits from byte B representing common test indicators are mapped as follows:
Test availabilityTest completeness
Components
Fuel System
Misfire

Bytes C and D are mapped as follows for spark ignition engine types :
Test availabilityTest completeness
EGR and/or VVT System
Oxygen Sensor Heater
Oxygen Sensor
Gasoline Particulate Filter
Secondary Air System
Evaporative System
Heated Catalyst
Catalyst

Bytes C and D are alternatively mapped as follows for compression ignition engine types :
Test availabilityTest completeness
EGR and/or VVT System
PM filter monitoring
Exhaust Gas Sensor
- Reserved -
Boost Pressure
- Reserved -
NOx/SCR Monitor
NMHC Catalyst

Service 01 PID - Monitor status this drive cycle

A request for this PID returns 4 bytes of data. The data returned is of an identical form to that returned for PID, with one exception - the first byte is always zero.

Service 01 PID 78 and 79 - Exhaust Gas temperature (EGT) Bank 1 and Bank 2

A request for one of these two PIDs will return 9 bytes of data. PID returns data relating to EGT sensors for bank 1, whilst PID similarly returns data for bank 2. The first byte is a bit encoded field indicating which EGT sensors are supported for the respective bank.
BytesDescription
EGT sensor support
-Temperature read by EGT sensor 1
-Temperature read by EGT sensor 2
-Temperature read by EGT sensor 3
-Temperature read by EGT sensor 4

The first byte is bit-encoded as follows:
BitsDescription
-Reserved
EGT sensor 4 supported?
EGT sensor 3 supported?
EGT sensor 2 supported?
EGT sensor 1 supported?

Bytes B through I provide 16-bit integers indicating the temperatures of the sensors. The temperature values are interpreted in degrees Celsius in the range -40 to 6513.5, using the usual formula. Only values for which the corresponding sensor is supported are meaningful.

Service 03 (no PID required) - Show stored Diagnostic Trouble Codes

A request for this service returns a list of the DTCs that have been set. The list is encapsulated using the ISO 15765-2 protocol.
If there are two or fewer DTCs then they are returned in an ISO-TP Single Frame. Three or more DTCs in the list are reported in multiple frames, with the exact count of frames dependent on the communication type and addressing details.
Each trouble code requires 2 bytes to describe. Encoded in these bytes are a category and a number. It is typically shown decoded into a five-character form like "", where the first character represents the category the DTC belongs to, and the remaining four characters are a hexadecimal representation of the number under that category. The first two bits of the first byte represent the category. The remaining 14 bits represent the number. Of note is that since the second character is formed from only two bits, it can thus only be within the range -.
BitsDefinition
-Category
: - Powertrain
: - Chassis
: - Body
: - Network
-Number

An example DTC of "" would be decoded as follows:
The resulting five-character code, e.g. "", can be looked up in a table of OBD-II DTCs to get an actual description of what it represents. Of note, whilst some blocks of DTC code ranges have generic meanings that apply to all vehicles and manufacturers, the meanings of others can vary per manufacturer or even model.
It is also worth noting that DTCs may sometimes be encountered in a four-character form, e.g. "", which is simply the plain hexadecimal representation of the two bytes, with proper decoding with respect to the category not having been performed.