OBDII MESSAGE STRUCTURE

This page defines the standard format for OBDII messages. The request sent from the diagnostic tool and the response from the vehicle computer (ECU) both have the same basic structure, although the length may vary for a given function. Each message frame has several parts. The first 3 bytes are the header. Then, one to seven data bytes follow. These are the meat of the request and response messages, discussed later. Note that not all data bytes are present for any given message. Some, in fact have only one data byte. The maximum is 7. Finally, there is an error check byte. Each byte consists of 8 bits. Schematically, it looks like this:

Header 1 Header 2 Header 3 Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 CRC

Note: This is the basic OBDII message frame format required by SAE J1979, and it does not include additional bytes which are neccesary to control the interface. In particular, most messages will have a control byte sent before the OBDII message frame, and for the case of VPW or PWM request messages, an additional byte (the frame number) is sent after the OBDII message frame. These additional bytes vary depending on protocol used, and whether the message is a request sent to the vehicle, or a response from it. For information on these bytes, please study the pdf data sheet carefully.


HEADER BYTES

The header bytes are different, depending upon the protocol and whether it is a request from the scan tool, or a response from the vehicle.

VPW (GM) or ISO9141 (Asian)

Byte 1 (priority/type) Byte 2 (Tgt address) Byte 3 (Source address)
Scantool Request 104 (68 hex) 106 (6A hex) 241 (F1 hex) Scantool address
Vehicle response 72 (48 hex) 107 (6B hex) ECU address byte

PWM (Ford)

Byte 1 (priority/type) Byte 2 (Tgt address) Byte 3 (Source address)
Scantool Request 97 (61 hex) 106 (6A hex) 241 (F1 hex) Scantool address
Vehicle response 65 (41 hex) 107 (6B hex) ECU address byte

ISO 14230 (Keyword protocol 2000)

Byte 1 (Length byte) Byte 2 (Tgt address) Byte 3 (Source address)
Scantool Request 11LL LLLL binary 51 (33 hex) 241 (F1 hex) Scantool address
Vehicle response 10LL LLLL (binary) 241 (F1 hex) Scantool address ECU address byte

Where LL LLLL is a 6 bit number representing the length of the Data byte section of the message.

DATA BYTES

Mode byte: The first byte in the stream is the mode number. There are 9 modes for diagnostic requests, so this first byte is from 1 to 9. The first byte in the response data bytes is this same number plus 64. For example, a mode 1 request would have the first data byte = 1, and the response would have the first data byte = 65. Here is a brief description of the modes:
MODE 1: This mode is used to obtain current diagnostic data, and is probably the most useful: Number of Trouble codes set, status of on-board tests,vehicle data such as engine RPM, temperatures, ignition advance, speed, air flow rates, whether or not the fuel system is in closed loop operation.
MODE 2: This mode is very similar to mode one, except it pertains to freeze frame data. This is basically the same data as in mode 1, but it was captured and stored at some point in time when a malfunction occurred and a trouble code was set. Many of the PIDs for mode one are not implemented in this mode.
MODE 3: This mode has no associated PIDs. It simply requests all diagnostic trouble codes from the vehicle. There may be more than one response message if there are more trouble codes than will fit in the data bytes of the response message, or if there are more than one ECU computer responding.
MODE4: Mode 4 is also a very simple mode, with no PID bytes. It simply instructs the vehicle to clear all diagnostic trouble codes that may be set.
MODE 5: This is an optional mode which requests results of oxygen sensor test results. There are a number of Test IDs (similar in function to PIDs) which may be used to obtain the results of various tests. Some vehicles do not use this mode, but report the data under mode 6.
MODE 6: This mode is for obtaining test results for non continuously monitored systems. This data is optional, and it is defined by a given vehicle maker if its used.
MODE 7: This mode is an optional mode. If implemented, it is similar to mode 3, which returns trouble codes, but these are codes which may be set after a single driving cycle (also known as "pending" trouble codes). They can be useful for checking the results after repair work.
MODE 8: This mode can be used to request control of an on board system, and is manufacturer defined.
MODE 9: This optional mode is used to report vehicle information such as the VIN number, and possibly calibration information stored in the vehicle ECU.


PID bytes (Parameter Identification): The second data byte is the "parameter identification" or PID. This is basically a number which indicates what data is requested. The PID is also the second byte in the corresponding response from the vehicle. PIDs for the more important modes are listed in the links below.

Other bytes: The remaining data bytes, if used, are for further specification of what data is requested, or if it is a response message, they are the actual data returned from the vehicle. The latter is the usual case.


ERROR DETECTION BYTE:

The last byte is used to verify that there are no errors in the message. For SAE defined systems like VPW or PWM, this is a type of cyclic redundancy check (CRC) byte. For ISO protocols, it is simply a checksum byte. All the preceeding bytes are used in the calculation of this byte (the 3 header bytes, and all the data bytes.




Back to OBDII Programmer's Index
Back to OBDII Automotive Diagnostics Home page