Understanding OBD2 Frame Format and Message Structure

The OBD2 (On-Board Diagnostics 2) frame structure facilitates communication between a vehicle’s onboard computer system (ECU) and an OBD2 diagnostic tool or scanner. It’s composed of several fields designed to organize and transmit data effectively.

The standard OBD2 frame structure, specific to the CAN protocol, is illustrated below:

These fields are crucial for organizing and conveying information pertaining to the vehicle’s performance and diagnostic data. Let’s explore the common fields found in an OBD2 message:

Common OBD2 Message Fields

• Identifier: In OBD2 messages, the identifier is a standard 11-bit field used to differentiate between “request messages” (ID 7DF) and “response messages” (ID 7E8 to 7EF). Typically, the main engine or ECU responds at ID 7E8.

• Length (#bytes): This field indicates the length, in number of bytes, of the remaining data (ranging from 03 to 06). For instance, in the Vehicle Speed example, the request has a length of 02 (as only 01 and 0D follow), while the response has a length of 03 (with 41, 0D, and 32 following).

• Mode: The mode field specifies the type of request or command being sent. Common modes include:

  • Mode 01: Show current data (real-time data)
  • Mode 02: Show freeze frame data
  • Mode 03: Show stored Diagnostic Trouble Codes (DTCs)
  • Mode 04: Clear DTCs
  • Mode 05: Show oxygen sensor monitoring test results
  • Mode 06: Show On-Board Monitoring Test Results
  • Mode 09: Request vehicle information
  • Mode 0A: Permanent DTCs (not supported by all vehicles)

• PID (Parameter ID): The PID field designates the specific data parameter or sensor value being requested or reported. PIDs are used to identify the type of data in the message, such as engine RPM, vehicle speed, or oxygen sensor voltage.

• Data Bytes: This field contains the actual data values corresponding to the PID. The number and meaning of data bytes depend on the specific PID and the mode. For example, the engine coolant temperature might be reported as a single data byte representing the temperature in degrees Celsius.

• Checksum: The checksum field verifies the integrity of the message. It’s calculated based on the other fields in the message to ensure accurate reception.

• Header and Footer: OBD2 messages typically include a header and footer to mark the start and end of each message. These elements help the OBD2 scanner and the vehicle’s ECU properly identify and separate individual messages.

• A, B, C, D: As shown in the image, these represent data bytes in hexadecimal (HEX) format. These values need to be converted to decimal form before being used in PID formula calculations. Note that the last data byte (after Dh) is typically not used.

The specific format and structure of OBD2 messages can vary depending on the communication protocol used (e.g., ISO 9141-2, ISO 14230-4, ISO 15765-4). However, the fields mentioned above are common elements in OBD2 messages. The format may also include additional fields for addressing and control purposes, depending on the communication protocol.

OBD2 diagnostic tools and scanners manage message formatting and interpretation, simplifying access to and understanding of vehicle diagnostic information for users.

Table of OBD2 PIDs

OBD2 (On-Board Diagnostics 2) Parameter IDs (PIDs) are unique codes used to request real-time data from various sensors and systems within a vehicle. These PIDs allow diagnostic tools to access and display information about the vehicle’s performance and condition.

While the specific PIDs available can differ between vehicles, there’s a standardized set defined by the OBD2 protocol.

PID requests and responses are essential for OBD2 diagnostics, as they deliver real-time data valuable for monitoring, troubleshooting, and vehicle maintenance.