OBD-II PIDs are codes used to request data from a vehicle, used as a diagnostic tool.
SAE standard J/1979 defines many PIDs, but manufacturers also define many more PIDs specific
to their vehicles.
All light duty vehicles sold in North America since 1996, as well as medium duty vehicles
beginning in 2005, and heavy duty vehicles beginning in 2010, are required to support
OBD-II diagnostics, using a standardized data link connector, and a subset of the SAE J/1979
defined PIDs, primarily for state mandated emissions inspections.
Typically, an automotive technician will use PIDs with a scan tool connected to the vehicle's
OBD-II connector.
The technician enters the PID The scan tool sends it to the vehicle's controller–area
network-bus, VPW, PWM, ISO, KWP.
A device on the bus recognizes the PID as one it is responsible for, and reports the
value for that PID to the bus The scan tool reads the response, and displays
it to the technician
Modes There are ten modes of operation described
in the latest OBD-II standard SAE J1979.
They are as follows: Vehicle manufacturers are not required to
support all modes.
Each manufacturer may define additional modes above #9 for other information e.g. the voltage
of the traction battery in a hybrid electric vehicle.
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 modes 1 and 2 are basically identical, except that Mode 1 provides current information,
whereas Mode 2 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 Mode 1, and PID 02, which is only available
in Mode 2.
If Mode 2 PID 02 returns zero, then there is no snapshot and all other Mode 2 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.
Mode 01 Mode 02
Mode 02 accepts the same PIDs as mode 01, 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.
Mode 03 Mode 04
Mode 05 Mode 09
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:
Mode 1 PID 00 A request for this PID returns 4 bytes of
data.
Each bit, from MSB to LSB, represents one of the next 32 PIDs and is giving information
about if it is supported.
For example, if the car response is BE1FA813, it can be decoded like this:
So, supported PIDs are: 01, 03, 04, 05, 06, 07, 0C, 0D, 0E, 0F, 10, 11, 13, 15, 1C, 1F
and 20 Mode 1 PID 01
A request for this PID returns 4 bytes of data.
The first byte contains two pieces of information.
Bit A7 indicates whether or not the MIL is illuminated.
Bits A6 through A0 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.
Here are the common bit B definitions, they are test based.
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 0 being
spark and 1 being compression.
The bytes C and D for spark ignition monitors: And the bytes C and D for compression ignition
monitors:
Mode 1 PID 41 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.
Note that test availability is represented by a set bit and completeness is represented
by a reset bit: Mode 1 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:
The first byte is bit-encoded as follows: 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 79, but values are for sensors of bank 2.
Mode 3 A request for this mode 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: The four following digits are encoded as 2
bits.
The second character in the DTC is a number defined by the following table:
The third character in the DTC is a number defined by
The fourth and fifth characters are defined in the same way as the third, but using bits
B7-B4 and B3-B0.
The resulting five-character code should look something like "U0158" 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.
Mode 9 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.
All data items of the In-use Performance Tracking record consist of two bytes and are reported
in this order: Mode 9 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:
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.
Mode 1 PID 03 A request for this PID returns 2 bytes of
data.
The first byte describes fuel system #1.
Any other value is an invalid response.
There can only be one bit set at most.
The second byte describes fuel system #2 and is encoded identically to the first byte.
Mode 1 PID 12 A request for this PID returns a single byte
of data which describes the secondary air status.
Any other value is an invalid response.
There can only be one bit set at most.
Mode 1 PID 1C 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:
Fuel Type Coding Mode 1 PID 51 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:
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 starts from US$7,500.
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 of today's per year charges as we know them:
GM $50,000 Honda $5,000
Suzuki $1,000 BMW $17,500 plus $1,000 per update.
Updates occur every quarter.
CAN 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 $7DF, which acts as a broadcast address,
and accepts responses from any ID in the range $7E8 to $7EF.
ECUs that can respond to OBD queries listen both to the functional broadcast ID of $7DF
and one assigned ID in the range $7E0 to $7E7.
Their response has an ID of their assigned ID plus 8 e.g. $7E8 through $7EF.
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 $7DF.
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: See also
On-board diagnostics Engine control unit
References
External links OBD II Error Codes Definition and Lookup,
including manufacturer-specific codes.
OBD-II Error Codes Definition, description and repair information for most makes of vehicles.
Generic/Manufacturer OBD2 Codes and Their Meanings
Directive 98EC of the European Parliament and of the Council of 13 October 1998.
CAN Bus Vehicles Partial list of 2003-2007 vehicles which support the OBD-II CAN bus
standard.
Fault Code Examples Sample fault code data read using the OBDKey Bluetooth, OBDKey USB
and OBDKey WLAN vehicle interface units.