OBDII Specifications: A Detailed Guide for Automotive Experts

As a car repair expert at autelfrance.com, this guide provides a comprehensive overview of Obdii Specifications, essential for diagnosing and repairing modern vehicles. Building upon a practical introduction to OBD2, we delve deeper into the technical details and standards that define this critical automotive system.

Understanding OBDII: More Than Just a Connector

OBDII, or On-Board Diagnostics II, is the standardized system in your vehicle that monitors and reports on its health. It’s not just about the malfunction indicator light (MIL), also known as the check engine light. OBDII provides access to a wealth of data, from diagnostic trouble codes (DTCs) to real-time parameters, all through the standardized OBDII connector. Mechanics use OBDII scanners to interface with this system, sending requests and receiving responses containing vital information like speed, engine temperature, and emission levels. This data is crucial for efficient troubleshooting and repair.

Understanding OBDII: On-Board Diagnostics and the Malfunction Indicator Light.

OBDII Compliance: Is Your Vehicle Compatible?

The question of OBDII support is usually a simple one for modern vehicles: Yes, almost certainly. For gasoline cars sold in the US from 1996 onwards, and in Europe from 2001, OBDII is mandatory. Diesel cars in the EU followed suit in 2004. While most cars with a 16-pin diagnostic connector are OBDII compliant, older models might have the connector without fully supporting the OBDII protocol. Compliance often depends on the vehicle’s original market and year of manufacture.

Does My Car Have OBD2?
OBDII Compliance by Region and Vehicle Type: Check if your car is OBDII compatible based on purchase location and date.

A Brief History of OBDII and its Specifications

OBDII’s origins are in California, driven by the California Air Resources Board (CARB)’s need for improved emission control in 1991. The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBDII, defining DTCs and the physical OBD connector (SAE J1962).

The OBDII mandate expanded progressively:

1996: OBDII becomes mandatory for cars and light trucks in the USA.
2001: OBDII required for gasoline vehicles in the European Union.
2004: European Union extends OBDII requirement to diesel vehicles (EOBD).
2005: OBDII mandated for medium-duty vehicles in the US.
2008: US vehicles must use ISO 15765-4 (CAN) as the communication basis for OBDII.
2010: OBDII becomes mandatory for heavy-duty vehicles in the US.

OBDII History: Evolution of emission control standards and the role of OBDII.

OBDII Timeline: Key milestones in the development and implementation of On-Board Diagnostics.

OBDII Future: Trends towards OBDIII, remote diagnostics, and cloud-based emission testing.

The Future of OBDII Specifications

While OBDII remains relevant, the automotive landscape is evolving. Electric vehicles (EVs), for instance, are not legally obliged to support OBDII, and most current EVs don’t. They often use manufacturer-specific UDS protocols instead, making data access challenging without reverse engineering efforts.

Modern OBDII alternatives are emerging to address limitations in data richness and communication protocols. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) aim to enhance OBD communication using the UDS protocol.

The concept of OBDIII introduces telematics for remote emission monitoring. OBDIII envisions vehicles equipped with radio transponders to transmit VIN and DTCs wirelessly to central servers for automated checks. While technologies like CANedge2 and CANedge3 already enable data transfer via WiFi/cellular, privacy concerns pose political hurdles for widespread OBDIII adoption.

There’s also debate within the automotive industry about controlling access to vehicle data through the OBDII port. Some manufacturers propose limiting OBDII functionality during driving, centralizing data collection for security and commercial reasons. This could potentially disrupt the aftermarket OBDII service industry.

OBDII Future Challenges: Electric Vehicles and potential restrictions on data access.

Enhance Your Expertise with Our CAN Bus Guide

Become a CAN bus expert with our comprehensive guide!

Our 160+ page PDF provides 12 simple introductions to CAN bus technology, essential for understanding OBDII and modern vehicle communication.

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

Core OBDII Specifications and Standards

OBDII operates as a higher-layer protocol on communication networks like CAN. It shares similarities with other CAN-based protocols such as J1939, CANopen, and NMEA 2000.

OBDII specifications define the connector, lower-layer protocols, Parameter IDs (PIDs), and more. These specifications are structured using the 7-layer OSI model, with both SAE and ISO standards contributing to different layers, reflecting US (SAE) and EU (ISO) standardization efforts. Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5 (diagnostic services) and SAE J1962 and ISO 15031-3 (connector specifications).

OBDII and CAN Bus in the OSI Model: Layered architecture of OBDII communication standards.

OBDII Connector Pinout: Type A 16-pin Data Link Connector (DLC) specifications.

The OBDII Connector: SAE J1962 Specifications

The 16-pin OBDII connector, standardized under SAE J1962 / ISO 15031-3, provides easy access to vehicle data. This connector, also known as the Data Link Connector (DLC), is typically located near the steering wheel, although its exact location can vary and may sometimes be hidden.

Key features of the OBDII connector specifications:

Pin 16: Supplies battery power, often active even when the ignition is off.
Pinout Variability: The OBDII pinout configuration depends on the communication protocol used by the vehicle.
CAN Bus Dominance: CAN bus is the most prevalent lower-layer protocol, utilizing pins 6 (CAN-High) and 14 (CAN-Low).

OBDII Connector Types: Type A vs. Type B

Two main OBDII connector types exist: Type A, common in cars, and Type B, often found in medium and heavy-duty vehicles. While both share similar pinouts, Type A provides 12V power, and Type B offers 24V. Baud rates can also differ, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

Type B connectors have a distinguishing interrupted groove, making Type B adapter cables compatible with both Type A and Type B sockets, whereas Type A adapters only fit Type A sockets.

OBDII Connector Types A and B: Differences in power supply and application based on SAE J1962 specifications.

OBDII and CAN Bus Relationship: ISO 15765 standards for OBDII over CAN.

OBDII and CAN Bus: ISO 15765-4 Specifications

Since 2008, ISO 15765 mandates CAN bus as the lower-layer protocol for OBDII in US vehicles. ISO 15765-4, also known as Diagnostics over CAN (DoCAN), outlines specific restrictions and standards for using CAN with OBDII, focusing on the physical, data link, and network layers:

Bit-rate: CAN bus bit-rate must be 250K or 500K.
CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
OBDII CAN IDs: Specifies dedicated CAN IDs for OBDII requests and responses.
Data Length: Diagnostic CAN frames must have a data length of 8 bytes.
Cable Length: OBDII adapter cables are limited to a maximum length of 5 meters.

OBDII CAN Identifiers: 11-bit and 29-bit Addressing

OBDII communication relies on request/response message exchanges. 11-bit CAN IDs are common in cars. Functional addressing uses ID 0x7DF to query all OBDII-compatible ECUs. Physical addressing, less frequently used, employs IDs 0x7E0-0x7E7 for specific ECU requests.

ECU responses typically use 11-bit IDs in the range 0x7E8-0x7EF, with 0x7E8 (Engine Control Module – ECM) being the most common response ID.

Some vehicles, particularly vans and medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBDII. Functional addressing in this case uses CAN ID 0x18DB33F1. Responses are found in the range 0x18DAF100 to 0x18DAF1FF, often using ID 0x18DAF110 or 0x18DAF11E. The response ID is sometimes represented as the J1939 PGN 0xDA00 (55808), reserved for ISO 15765-2 in the J1939-71 standard.

OBDII Request and Response Frames: Structure of OBDII communication packets.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBDII vs. Proprietary CAN Bus Protocols: Differentiating between standard OBDII and OEM-specific data.

OBDII vs. Proprietary CAN Protocols: Understanding the Difference

Vehicle ECUs primarily rely on OEM-specific CAN protocols for their internal operations, not OBDII. These proprietary protocols are unique to vehicle brands, models, and years. Interpreting this OEM-specific data typically requires reverse engineering, unless you are the OEM.

Connecting a CAN bus data logger to the OBDII connector might reveal OEM-specific CAN data alongside OBDII data. However, newer vehicles often employ a gateway that restricts OBDII connector access to OBDII communication only, blocking OEM-specific data.

OBDII functions as a supplementary higher-layer protocol, operating in parallel with the OEM-specific communication network.

Bit-rate and ID Validation: Ensuring Correct Communication

OBDII specifications allow for two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically validate these parameters.

ISO 15765-4 provides a validation sequence to determine the correct combination. This process leverages the mandatory support for a specific OBDII request (mode 0x01 PID 0x00) in OBDII-compliant vehicles and detects CAN error frames caused by incorrect bit-rate transmission.

Current versions of ISO 15765-4 consider both OBDonEDS (OBD on Emission Diagnostic Service) and OBDonUDS (OBD on Unified Diagnostic Service) communication methods. OBDonEDS (or OBD2, SAE OBD, EOBD, ISO OBD) is prevalent in most non-EVs, while WWH-OBD is primarily used in EU trucks and buses. Diagnostic tools can test for OBDonUDS support by sending UDS requests with specific IDs (service 0x22, DID 0xF810).

OBDII Bit-rate and CAN ID Validation Flowchart: Systematic process to determine communication parameters according to ISO 15765-4.

OBDII Lower-Layer Protocols: Five protocols used for OBDII communication, including CAN (ISO 15765).

Five Lower-Layer OBDII Protocols: Beyond CAN

While CAN (ISO 15765) is dominant today, older vehicles (pre-2008) may use one of four other lower-layer protocols for OBDII. Understanding these protocols and their pinouts can be useful when working with older vehicles:

ISO 15765 (CAN bus): Mandatory in US cars since 2008, widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ Asian vehicles.
ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBDII Messages [ISO 15765-2 Specifications]

OBDII data transmission over CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol that enables payloads exceeding the 8-byte CAN frame limit. This is essential for transmitting larger OBDII data like VIN or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly of messages.

For smaller OBDII data that fits within a single CAN frame, ISO 15765-2 specifies the ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates payload length, leaving 7 bytes for OBDII communication.

ISO-TP Frame Types for OBDII: Single Frame, First Frame, Consecutive Frame, and Flow Control Frame specifications.

The OBDII Diagnostic Message Structure [SAE J1979, ISO 15031-5 Specifications]

A simplified OBDII CAN message consists of an identifier, data length (PCI field), and data payload. The data payload is further structured into Mode, Parameter ID (PID), and data bytes.

OBDII Message Structure: Breakdown of an OBDII frame into Mode, PID, and Data Bytes.

OBDII Request/Response Example: Vehicle Speed

Consider a request for ‘Vehicle Speed’. A diagnostic tool sends a request message (CAN ID 0x7DF) with two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds (CAN ID 0x7E8) with three payload bytes, including the speed value in the fourth byte, 0x32 (decimal 50). Looking up PID 0x0D’s decoding rules reveals the physical value is 50 km/h.

OBDII Request and Response Example: Communication flow for requesting vehicle speed data.

OBDII PID 0D for Vehicle Speed: Decoding process for PID 0x0D to obtain vehicle speed.

OBDII Service Modes: Overview of the 10 standardized OBDII service modes (modes 01-0A).

The 10 OBDII Services (Modes): Diagnostic Functions

OBDII defines 10 diagnostic services or modes. Mode 0x01 provides real-time data, while others handle DTCs, freeze frame data, and more. Not all vehicles support all OBDII modes, and manufacturers may implement OEM-specific modes beyond the 10 standard ones.

In OBDII messages, the mode is the second byte. In requests, the mode is directly included (e.g., 0x01). In responses, 0x40 is added to the mode value (e.g., 0x41).

OBDII Parameter IDs (PIDs): Accessing Specific Data

Each OBDII mode contains Parameter IDs (PIDs). Mode 0x01, for example, includes approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of PIDs within a mode.

PID 0x00 in mode 0x01 is a special case. If an emissions-related ECU supports any OBDII services, it must support mode 0x01 PID 0x00. Responding to this PID indicates support for PIDs 0x01-0x20. PID 0x00 serves as a fundamental OBDII compatibility test. PIDs 0x20, 0x40, and so on, similarly indicate support for subsequent PID ranges in mode 0x01.

OBDII Request and Response with PIDs: How PIDs are used in OBDII communication to request specific parameters.

OBD2 PID overview tool
OBDII PID Overview Tool: Resource for exploring and understanding OBDII Parameter IDs.

OBDII PID Overview Tool: Decoding Data

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBDII PIDs, enabling conversion of raw data to physical values. Our OBDII PID overview tool simplifies this process, aiding in constructing request frames and dynamically decoding responses.

OBDII PID overview tool

Logging and Decoding OBDII Data: A Practical Guide

This section demonstrates OBDII data logging using the CANedge CAN bus data logger. The CANedge allows custom CAN frame transmission for OBDII requests. Connecting it to a vehicle via an OBDII-DB9 adapter cable enables easy data logging.

OBDII Data Logger Setup: Connecting an OBDII data logger to request and record PID data.

OBD2 bit rate test
OBDII Bit-rate Validation Test: Verifying the correct bit-rate for OBDII communication.

OBD2 Supported PIDs Test
OBDII Supported PIDs Test Results: Reviewing responses to identify supported PIDs using software like asammdf.

Review supported PIDs via OBD2 lookup tool

Step 1: Bit-rate, ID, and Supported PID Validation

ISO 15765-4 outlines a process to determine the vehicle’s bit-rate and IDs. The CANedge can automate this:

Test 500K bit-rate and verify successful transmission (if not, try 250K).
Use the validated bit-rate for subsequent communication.
Send ‘Supported PIDs’ requests and analyze responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs from response data.

Plug-and-play configurations for these tests are available. Most post-2008 non-EVs support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and OBDonEDS. Multiple responses to a single OBD request (using 0x7DF) are common due to polling all ECUs. The ECM ECU (0x7E8) often supports all PIDs, allowing for reduced busload by directly requesting from this ECU (using physical addressing ID 0x7E0).

Step 2: Configuring OBDII PID Requests

With validated parameters and supported PIDs, configure your transmit list with desired PIDs. Consider:

CAN IDs: Use physical addressing request IDs (e.g., 0x7E0) to minimize responses.
Spacing: Add 300-500 ms delay between requests to avoid ECU overload.
Battery Drain: Use triggers to stop transmission when the vehicle is inactive.
Filters: Filter for OBDII responses if OEM-specific CAN data is also present.

With these configurations, the CANedge is ready for raw OBDII data logging.

obd2-transmit-list-example-canedge
CANedge OBDII PID Request Example: Configuration for transmitting OBDII PID requests using CANedge.

OBD2 data decoded visual plot asammdf CAN bus DBC file
OBDII Data Visualization in asammdf: Decoded and visualized OBDII data using asammdf software and a DBC file.

Step 3: DBC Decoding of Raw OBDII Data

To analyze logged data, decode raw OBDII data into physical values. ISO 15031-5/SAE J1979 and resources like Wikipedia provide decoding information. Our free OBDII DBC file simplifies DBC decoding in CAN bus software tools.

Decoding OBDII data is more complex than standard CAN signals due to multiplexing. Different OBDII PIDs share the same CAN ID (e.g., 0x7E8). Signal identification requires considering CAN ID, OBDII mode, and PID. This ‘extended multiplexing’ is manageable using DBC files.

CANedge: Your OBDII Data Logging Solution

The CANedge offers straightforward OBDII data recording to SD cards (8-32 GB). Connect to a vehicle to start logging and use free software/APIs and our OBDII DBC for data decoding.

OBDII logger intro
CANedge

OBDII Multi-Frame Examples: ISO-TP in Action

OBDII communication, including multi-frame exchanges, uses ISO-TP (ISO 15765-2). Multi-frame communication requires flow control frames. CANedge configurations can incorporate static flow control frames (e.g., 50 ms after the initial request). Software supporting ISO-TP, like CANedge MF4 decoders, is necessary for multi-frame response handling.

OBD2-multi-frame-request-message-vehicle-identification-number
OBDII Multi-Frame Request Example: Requesting Vehicle Identification Number (VIN) using multi-frame communication.

Example 1: OBDII Vehicle Identification Number (VIN) Retrieval

VIN retrieval (mode 0x09, PID 0x02) is relevant for telematics and diagnostics.

VIN Vehicle Identification Number OBD2 Example multi-frame

The diagnostic tool sends a Single Frame request. The vehicle responds with a First Frame indicating the total data length, mode, and PID, followed by Consecutive Frames containing the VIN data, which can be converted from HEX to ASCII.

Example 2: OBDII Multi-PID Request (6x) – Not Recommended

Requesting up to 6 mode 0x01 PIDs in a single request is possible, but generally not recommended for practical data logging due to decoding complexity and DBC file limitations. While it can increase data collection efficiency, the signal encoding becomes request-specific, complicating generic DBC file usage.

Requesting multiple PIDs in one request

Multi-frame responses are similar to VIN retrieval but include requested PIDs and their data. Decoding these responses with generic DBC files is challenging. While custom scripts combining request and response messages can be used, they are less scalable.

Example 3: OBDII Diagnostic Trouble Codes (DTCs) – Emissions Related

Mode 0x03 retrieves emissions-related DTCs. The request contains no PID. The ECU responds with the number of stored DTCs (potentially zero) and the DTCs themselves (2 bytes per DTC). Multi-frame responses are needed for more than 2 DTCs.

DTCs are 2-byte values, categorized and coded as per ISO 15031-5/ISO 15031-6. Decoded DTC values can be looked up in OBDII DTC lookup tools like repairpal.com.

OBDII DTC Decoding Example: Structure and interpretation of Diagnostic Trouble Code data.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

The example shows a request to an ECU with 6 DTCs stored, demonstrating multi-frame response for DTC data.

OBDII Data Logging: Practical Applications

OBDII data logging in cars and light trucks has diverse applications:

Car Data Logging

OBDII data can optimize fuel consumption, improve driving habits, test prototype parts, and inform insurance models.

OBDII logger

Real-time Vehicle Diagnostics

OBDII interfaces enable real-time streaming of human-readable data for diagnosing vehicle issues.

OBDII streaming

Predictive Maintenance

IoT-connected OBDII loggers can monitor vehicle health in the cloud, predicting and preventing breakdowns.

Predictive maintenance

Vehicle Black Box Logging

OBDII loggers serve as vehicle ‘black boxes’ for incident data recording, dispute resolution, and advanced diagnostics.

CAN bus black box

Have an OBDII data logging application in mind? Contact us for expert consultation!

Explore our guides for more introductory resources or download our comprehensive ‘Ultimate Guide’ PDF.

Ready to log or stream OBDII data?

Get your OBDII data logger now!

Buy now
Contact us