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.

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:
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 numerated from 0 to 7, so 7 is the most significant bit and 0 is the least significant bit.

Service

Service

Service accepts the same PIDs as service, with the same meaning, but information given is from when the freeze frame was created.
You have to send the frame number in the data section of the message.
PID
Data bytes returnedDescriptionMin valueMax valueUnitsFormula
2DTC that caused freeze frame to be stored.BCD encoded. Decoded as in service 3

Service

Service

Service

Service

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

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

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. Note that test availability is indicated by set bit and completeness is indicated by reset bit.
BitNameDefinition
MILOff or On, indicates if the CEL/MIL is on
-DTC_CNTNumber of confirmed emissions-related DTCs available for display.
RESERVEDReserved
NO NAME = Spark ignition monitors supported
= Compression ignition monitors supported

Here are the common bit B definitions, they are test based.
Test availableTest incomplete
Components
Fuel System
Misfire

The third and fourth bytes are to be interpreted differently depending on if the engine is spark ignition or compression ignition. In the second byte, bit 3 indicates how to interpret the C and D bytes, with being spark and being compression.
The bytes C and D for spark ignition monitors :
Test availableTest incomplete
EGR System
Oxygen Sensor Heater
Oxygen Sensor
A/C Refrigerant
Secondary Air System
Evaporative System
Heated Catalyst
Catalyst

And the bytes C and D for compression ignition monitors :
Test availableTest incomplete
EGR and/or VVT System
PM filter monitoring
Exhaust Gas Sensor
- Reserved -
Boost Pressure
- Reserved -
NOx/SCR Monitor
NMHC Catalyst

Service 01 PID

A request for this PID returns 4 bytes of data.
The first byte is always zero. The second, third, and fourth bytes give information about the availability and completeness of certain on-board tests. As with PID 01, the third and fourth bytes are to be interpreted differently depending on the ignition type – with being spark and being compression. Note again that test availability is represented by a set bit and completeness is represented by a reset bit.
Here are the common bit B definitions, they are test based.
Test availableTest incomplete
Components
Fuel System
Misfire

The bytes C and D for spark ignition monitors :
Test availableTest incomplete
EGR System
Oxygen Sensor Heater
Oxygen Sensor
A/C Refrigerant
Secondary Air System
Evaporative System
Heated Catalyst
Catalyst

And the bytes C and D for compression ignition monitors :
Test availableTest incomplete
EGR and/or VVT System
PM filter monitoring
Exhaust Gas Sensor
- Reserved -
Boost Pressure
- Reserved -
NOx/SCR Monitor
NMHC Catalyst

Service 01 PID 78

A request for this PID will return 9 bytes of data.
The first byte is a bit encoded field indicating which EGT sensors are supported:
ByteDescription
Supported EGT sensors
-Temperature read by EGT11
-Temperature read by EGT12
-Temperature read by EGT13
-Temperature read by EGT14

The first byte is bit-encoded as follows:
BitDescription
-Reserved
EGT bank 1, sensor 4 Supported?
EGT bank 1, sensor 3 Supported?
EGT bank 1, sensor 2 Supported?
EGT bank 1, sensor 1 Supported?

The remaining bytes are 16 bit integers indicating the temperature 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.
The same structure applies to PID, but values are for sensors of bank 2.

Service 03 (no PID required)

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 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. The text description of a trouble code may be decoded as follows. The first character in the trouble code is determined by the first two bits in the first byte:
-First DTC character
00 - Powertrain
01 - Chassis
10 - Body
11 - Network

The two following digits are encoded as 2 bits. The second character in the DTC is a number defined by the following table:
-Second DTC character
00
01
10
11

The third character in the DTC is a number defined by
-Third DTC character
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

The fourth and fifth characters are defined in the same way as the third, but using bits - and -. The resulting five-character code should look something like "" and can be looked up in a table of OBD-II DTCs. Hexadecimal characters, while relatively rare, are allowed in the last 3 positions of the code itself.

Service 09 PID 08

It provides information about track in-use performance for catalyst banks, oxygen sensor banks, evaporative leak detection systems, EGR systems and secondary air system.
The numerator for each component or system tracks the number of times that all conditions necessary for a specific monitor to detect a malfunction have been encountered.
The denominator for each component or system tracks the number of times that the vehicle has been operated in the specified conditions.
The count of data items should be reported at the beginning.
All data items of the In-use Performance Tracking record consist of two bytes and are reported in this order.
MnemonicDescription
OBDCONDOBD Monitoring Conditions Encountered Counts
IGNCNTRIgnition Counter
CATCOMP1Catalyst Monitor Completion Counts Bank 1
CATCOND1Catalyst Monitor Conditions Encountered Counts Bank 1
CATCOMP2Catalyst Monitor Completion Counts Bank 2
CATCOND2Catalyst Monitor Conditions Encountered Counts Bank 2
O2SCOMP1O2 Sensor Monitor Completion Counts Bank 1
O2SCOND1O2 Sensor Monitor Conditions Encountered Counts Bank 1
O2SCOMP2O2 Sensor Monitor Completion Counts Bank 2
O2SCOND2O2 Sensor Monitor Conditions Encountered Counts Bank 2
EGRCOMPEGR Monitor Completion Condition Counts
EGRCONDEGR Monitor Conditions Encountered Counts
AIRCOMPAIR Monitor Completion Condition Counts
AIRCONDAIR Monitor Conditions Encountered Counts
EVAPCOMPEVAP Monitor Completion Condition Counts
EVAPCONDEVAP Monitor Conditions Encountered Counts
SO2SCOMP1Secondary O2 Sensor Monitor Completion Counts Bank 1
SO2SCOND1Secondary O2 Sensor Monitor Conditions Encountered Counts Bank 1
SO2SCOMP2Secondary O2 Sensor Monitor Completion Counts Bank 2
SO2SCOND2Secondary O2 Sensor Monitor Conditions Encountered Counts Bank 2

Service 09 PID 0B

It provides information about track in-use performance for NMHC catalyst, NOx catalyst monitor, NOx adsorber monitor, PM filter monitor, exhaust gas sensor monitor, EGR/ VVT monitor, boost pressure monitor and fuel system monitor.
All data items consist of two bytes and are reported in this order :
MnemonicDescription
OBDCONDOBD Monitoring Conditions Encountered Counts
IGNCNTRIgnition Counter
HCCATCOMPNMHC Catalyst Monitor Completion Condition Counts
HCCATCONDNMHC Catalyst Monitor Conditions Encountered Counts
NCATCOMPNOx/SCR Catalyst Monitor Completion Condition Counts
NCATCONDNOx/SCR Catalyst Monitor Conditions Encountered Counts
NADSCOMPNOx Adsorber Monitor Completion Condition Counts
NADSCONDNOx Adsorber Monitor Conditions Encountered Counts
PMCOMPPM Filter Monitor Completion Condition Counts
PMCONDPM Filter Monitor Conditions Encountered Counts
EGSCOMPExhaust Gas Sensor Monitor Completion Condition Counts
EGSCONDExhaust Gas Sensor Monitor Conditions Encountered Counts
EGRCOMPEGR and/or VVT Monitor Completion Condition Counts
EGRCONDEGR and/or VVT Monitor Conditions Encountered Counts
BPCOMPBoost Pressure Monitor Completion Condition Counts
BPCONDBoost Pressure Monitor Conditions Encountered Counts
FUELCOMPFuel Monitor Completion Condition Counts
FUELCONDFuel Monitor Conditions Encountered Counts

Enumerated PIDs

Some PIDs are to be interpreted specially, and aren't necessarily exactly bitwise encoded, or in any scale.
The values for these PIDs are enumerated.

Service 01 PID

A request for this PID returns 2 bytes of data.
The first byte describes fuel system #1.
ValueDescription
1Open loop due to insufficient engine temperature
2Closed loop, using oxygen sensor feedback to determine fuel mix
4Open loop due to engine load OR fuel cut due to deceleration
8Open loop due to system failure
16Closed loop, using at least one oxygen sensor but there is a fault in the feedback system

Any other value is an invalid response.
The second byte describes fuel system #2 and is encoded identically to the first byte.

Service 01 PID

A request for this PID returns a single byte of data which describes the secondary air status.
ValueDescription
1Upstream
2Downstream of catalytic converter
4From the outside atmosphere or off
8Pump commanded on for diagnostics

Any other value is an invalid response.

Service 01 PID

A request for this PID returns a single byte of data which describes which OBD standards this ECU was designed to comply with. The different values the data byte can hold are shown below, next to what they mean:
ValueDescription
1OBD-II as defined by the CARB
2OBD as defined by the EPA
3OBD and OBD-II
4OBD-I
5Not OBD compliant
6EOBD
7EOBD and OBD-II
8EOBD and OBD
9EOBD, OBD and OBD II
10JOBD
11JOBD and OBD II
12JOBD and EOBD
13JOBD, EOBD, and OBD II
14Reserved
15Reserved
16Reserved
17Engine Manufacturer Diagnostics
18Engine Manufacturer Diagnostics Enhanced
19Heavy Duty On-Board Diagnostics
20Heavy Duty On-Board Diagnostics
21World Wide Harmonized OBD
22Reserved
23Heavy Duty Euro OBD Stage I without NOx control
24Heavy Duty Euro OBD Stage I with NOx control
25Heavy Duty Euro OBD Stage II without NOx control
26Heavy Duty Euro OBD Stage II with NOx control
27Reserved
28Brazil OBD Phase 1
29Brazil OBD Phase 2
30Korean OBD
31India OBD I
32India OBD II
33Heavy Duty Euro OBD Stage VI
34-250Reserved
251-255Not available for assignment

Fuel Type Coding

Service 01 PID returns a value from an enumerated list giving the fuel type of the vehicle. The fuel type is returned as a single byte, and the value is given by the following table:
ValueDescription
0Not available
1Gasoline
2Methanol
3Ethanol
4Diesel
5LPG
6CNG
7Propane
8Electric
9Bifuel running Gasoline
10Bifuel running Methanol
11Bifuel running Ethanol
12Bifuel running LPG
13Bifuel running CNG
14Bifuel running Propane
15Bifuel running Electricity
16Bifuel running electric and combustion engine
17Hybrid gasoline
18Hybrid Ethanol
19Hybrid Diesel
20Hybrid Electric
21Hybrid running electric and combustion engine
22Hybrid Regenerative
23Bifuel running diesel

Any other value is reserved by ISO/SAE. There are currently no definitions for flexible-fuel vehicle.

Non-standard PIDs

The majority of all OBD-II PIDs in use are non-standard. For most modern vehicles, there are many more functions supported on the OBD-II interface than are covered by the standard PIDs, and there is relatively minor overlap between vehicle manufacturers for these non-standard PIDs.
There is very limited information available in the public domain for non-standard PIDs. The primary source of information on non-standard PIDs across different manufacturers is maintained by the US-based Equipment and Tool Institute and only available to members. The price of ETI membership for access to scan codes varies based on company size defined by annual sales of automotive tools and equipment in North America:
Annual Sales in North AmericaAnnual Dues
Under $10,000,000$5,000
$10,000,000 - $50,000,000$7,500
Greater than $50,000,000$10,000

However, even ETI membership will not provide full documentation for non-standard PIDs. ETI state:

Some OEMs refuse to use ETI as a one-stop source of scan tool information. They prefer to do business with each tool company separately. These companies also require that you enter into a contract with them. The charges vary but here is a snapshot as of April 13th, 2015 of the per year charges:
GM$50,000
Honda$5,000
Suzuki$1,000
BMW$25,500 plus $2,000 per update. Updates occur annually.

CAN (11-bit) bus format

The PID query and response occurs on the vehicle's CAN bus. Standard OBD requests and responses use functional addresses. The diagnostic reader initiates a query using CAN ID 7DFh, which acts as a broadcast address, and accepts responses from any ID in the range 7E8h to 7EFh. ECUs that can respond to OBD queries listen both to the functional broadcast ID of 7DFh and one assigned ID in the range 7E0h to 7E7h. Their response has an ID of their assigned ID plus 8 e.g. 7E8h through 7EFh.
This approach allows up to eight ECUs, each independently responding to OBD queries. The diagnostic reader can use the ID in the ECU response frame to continue communication with a specific ECU. In particular, multi-frame communication requires a response to the specific ECU ID rather than to ID 7DFh.
CAN bus may also be used for communication beyond the standard OBD messages. Physical addressing uses particular CAN IDs for specific modules with proprietary frame payloads.

Query

The functional PID query is sent to the vehicle on the CAN bus at ID 7DFh, using 8 data bytes. The bytes are:

Response

The vehicle responds to the PID query on the CAN bus with message IDs that depend on which module responded. Typically the engine or main ECU responds at ID 7E8h. Other modules, like the hybrid controller or battery controller in a Prius, respond at 07E9h, 07EAh, 07EBh, etc. These are 8h higher than the physical address the module responds to. Even though the number of bytes in the returned value is variable, the message uses 8 data bytes regardless.
The bytes are: