standards, toolbox

OBDII diagnostic codes

In order to get familiar with CANBus and OBD standard it is essential to understand underlying data formats and protocols. Covering this topic in detail and depth can take much time, especially when all possible variations of manufacturer specific or otherwise proprietary get taken into account. However, good news is that one doesn’t necessarily need to go to that lengths to get a gist of what can be expected. Aim of the article is to introduce fundamentals of data structuring and bring closer features available with OBD protocol.

 

On-board diagnostics Parameter IDs

OBDII PIDs (On-board diagnostics Parameter IDs) are codes used to request data from a vehicle or, 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 (i.e. less than 8,500 pounds) sold in North America since 1996, as well as medium duty vehicles (i.e. 8,500-14,000 pounds) beginning in 2005, and heavy duty vehicles (i.e. greater than 14,000 pounds) 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 (or SAE J/1939 as applicable for medium/heavy duty vehicles), primarily for state mandated emissions inspections.

Latest OBD-II standard SAE J1979 describes 10 modes of operation. They are as follows:

Mode (hex) Description
01 Show current data
02 Show freeze frame data
03 Show stored Diagnostic Trouble Codes
04 Clear Diagnostic Trouble Codes and stored values
05 Test results, oxygen sensor monitoring (non CAN only)
06 Test results, other component/system monitoring (Test results, oxygen sensor monitoring for CAN only)
07 Show pending Diagnostic Trouble Codes (detected during current or last driving cycle)
08 Control operation of on-board component/system
09 Request vehicle information
0A Permanent Diagnostic Trouble Codes (DTCs) (Cleared DTCs)

 

Vehicle manufacturers are not required to support all modes. Each manufacturer may define additional modes above #9 (e.g.: mode 22 as defined by SAE J2190 for Ford/GM, mode 21 for Toyota) for other information e.g. the voltage of the traction battery in a hybrid electric vehicle (HEV)

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[clarification needed], 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 (e.g., 720h for the instrument cluster in Fords) with proprietary frame payloads.

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

Byte
PID Type 0 1 2 3 4 5 6 7
SAE Standard Number of
additional
data bytes:
2
Mode
01 = show current data;
02 = freeze frame;
etc.
PID code
(e.g.: 05 = Engine coolant temperature)
not used
(may be 55h)
Vehicle specific Number of
additional
data bytes:
3
Custom mode: (e.g.: 22 = enhanced data) PID code
(e.g.: 4980h)
not used
(may be 00h or 55h)

 

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 (CAN bus protocol form Frameformat with 8 data bytes). The bytes are:

Custom mode: (e.g.: 22h = enhanced diagnostic data by PID, 21h = enhanced data by offset)

value of the specified parameter, byte 0value, byte 1 (optional)value, byte 2 (optional)value, byte 3 (optional)value of the specified parameter, byte 0value, byte 1 (optional)value, byte 2 (optional)value, byte 3 (optional)

Byte
PID Type 0 1 2 3 4 5 6 7
SAE Standard
7E8h,
7E9h,
7EAh,
etc.
Number of
additional
data bytes:
3 to 6
Custom mode
Same as query, except that 40h is added to the mode value. So:
41h = show current data;
42h = freeze frame;
etc.
PID code
(e.g.: 05 = Engine coolant temperature)
not used
(may be 00h or 55h)
Vehicle specific
7E8h, or 8h + physical ID of module.
Number of
additional
data bytes:
4to 7
Custom mode: same as query, except that 40h is added to the mode value.(e.g.: 62h = response to mode 22h request) PID code
(e.g.: 4980h)
Vehicle specific
7E8h, or 8h + physical ID of module.
Number of
additional
data bytes:
3
7Fh this a general response usually indicating the module doesn’t recognize the request. 31h not used
(may be 00h)

 

There are publicly accessible lists of generic PIDs as well as ones defined by many manufacturers. At the moment, TinyO community is making an effort to collect thousands of codes and present them on this portal as a part of the documentation and service API which will be available for developers. Stay tuned.

Leave a Reply