How Do I Know What OBD2 Interface My Car Has? A Comprehensive Guide

Understanding your car’s On-Board Diagnostics 2 (OBD2) interface is crucial for anyone interested in vehicle maintenance, diagnostics, or performance monitoring. Whether you’re a seasoned mechanic or a car owner curious about that mysterious port under your dashboard, knowing your OBD2 interface is the first step. This guide provides a simple yet detailed introduction to OBD2 interfaces, helping you understand what it is, how to identify it in your car, and why it’s important.

What Exactly is OBD2?

OBD2 is essentially your car’s self-diagnostic system. Think of it as a built-in doctor for your vehicle. It’s a standardized protocol that allows access to your car’s computer to retrieve diagnostic trouble codes (DTCs) and real-time data. This data is accessed through the OBD2 connector, a 16-pin port typically located within easy reach of the driver’s seat.

Ever seen the check engine light, also known as the malfunction indicator light (MIL), illuminate on your dashboard? That’s OBD2 in action, signaling that your car has detected an issue. Mechanics use OBD2 scanners, which plug into the OBD2 connector, to read these codes and diagnose problems. These scanners send ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ containing valuable data like speed, fuel level, and those all-important DTCs. This system significantly streamlines troubleshooting and repair processes.

Understanding OBD2: The malfunction indicator light (MIL) signals potential issues, diagnosable via the OBD2 interface.

Does My Car Have an OBD2 Interface?

The good news is, if you own a relatively recent non-electric car, the answer is almost certainly yes. OBD2 has become a standard in the automotive industry. Most modern cars are not only OBD2 compliant but also utilize the Controller Area Network (CAN) bus for communication.

However, it’s essential to verify, especially for older vehicles. Just because you spot a 16-pin connector doesn’t automatically mean it’s OBD2 compliant. Some older cars might have a similar-looking connector that doesn’t support the OBD2 protocol.

A key indicator of OBD2 compliance is the car’s year and the market where it was originally sold:

OBD2 Compliance Guide: Check your vehicle’s origin and year of manufacture to determine OBD2 compliance.

Here’s a simple guideline:

USA: If your car was bought new in the USA in 1996 or later (for cars and light trucks), it’s mandated to be OBD2 compliant. For medium-duty vehicles, the mandate started in 2005, and for heavy-duty vehicles in 2010.
Europe: For gasoline cars purchased new in the EU from 2001 onwards and diesel cars from 2003 onwards, OBD2 (or EOBD, the European version) is mandatory.

If your car falls within these timelines, it’s highly likely to have an OBD2 interface. For vehicles outside these regions or older models, further investigation might be needed. Resources like scantool.net offer additional guidance on determining OBD2 compliance.

A Brief History of OBD2

The story of OBD2 begins in California. The California Air Resources Board (CARB) pioneered the concept, requiring OBD systems in all new cars from 1991 onwards for emission control. The Society of Automotive Engineers (SAE) then standardized the protocol, leading to OBD2. This standardization included diagnostic trouble codes (DTCs) and the OBD connector itself, ensuring consistency across different manufacturers (SAE J1962).

The adoption of OBD2 was a phased process:

1996: OBD2 becomes mandatory in the USA for cars and light trucks.
2001: The EU mandates OBD2 for gasoline cars.
2003: The EU extends the mandate to diesel cars (EOBD).
2005: OBD2 becomes required in the US for medium-duty vehicles.
2008: US cars are required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 is mandated for heavy-duty vehicles in the US.

OBD2 Evolution: From emission control origins to standardized diagnostics, tracing the history of OBD2.

OBD2 Timeline: A visual overview of the key milestones in the development and implementation of OBD2.

The Future of OBD: Exploring the trends towards OBD3, remote diagnostics, and integration with IoT.

The Future Landscape of OBD2

While OBD2 remains relevant, the automotive world is evolving, and so is OBD. Here are some key trends shaping the future of OBD:

Electric Vehicles (EVs) and OBD2: Interestingly, the original intent of legislated OBD2 was emissions control. As a result, EVs, having no tailpipe emissions, are not obliged to support OBD2 in its traditional form. In practice, many modern EVs don’t support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This makes accessing data from EVs challenging without specific reverse-engineered solutions, such as those explored in case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.
Modern Alternatives: WWH-OBD and OBDonUDS: Recognizing the limitations of current OBD2 in terms of data richness and protocol flexibility, newer standards like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to modernize OBD communication by using the UDS protocol as a foundation. Learn more about UDS in this introduction to UDS.
OBD3 and Telematics: The future might bring OBD3, envisioning telematics integration in all vehicles. OBD3 could incorporate a small radio transponder in cars, enabling wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated emission checks and diagnostics. While convenient and cost-saving, this raises privacy and surveillance concerns. Technologies already exist to facilitate data transfer via WiFi/cellular, like the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.
OEM Control over Data Access: There’s a growing debate about third-party access to vehicle data via OBD2. Concerns from car manufacturers, particularly in Germany, suggest a move to limit OBD2 functionality during driving, centralizing data collection within manufacturer-controlled servers. This is argued as a security measure to prevent car hacking but is also seen by some as a move to control the burgeoning ‘automotive big data’ market. This potential shift could significantly impact third-party OBD2 service providers.

EVs and Data Access: The trend of electric vehicles potentially limiting access to data via traditional OBD2 interfaces.

Enhance Your CAN Bus Expertise

Want to dive deeper into CAN bus technology?

Our comprehensive ‘Ultimate CAN Guide’ offers 12 simple introductions in a 160+ page PDF.

Download now

Understanding OBD2 Standards

OBD2 operates as a higher-layer protocol on top of communication methods like CAN bus. Think of OBD2 as the language and CAN bus as the communication channel. This is similar to other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define various aspects, including the OBD2 connector, lower-layer protocols, and OBD2 Parameter IDs (PIDs). These standards can be categorized within the 7-layer OSI model. Notably, both SAE (primarily US standards) and ISO (international standards) contribute to OBD2 specifications, often with technically equivalent standards like SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.

OBD2 and CAN Bus in the OSI Model: Illustrating how OBD2 and CAN bus protocols fit within the 7-layer OSI model.

OBD2 Connector Pinout: Diagram of a Type A OBD2 connector, detailing the pin assignments.

Decoding the OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector is your physical interface to your car’s diagnostic data. Standardized under SAE J1962 / ISO 15031-3, it provides easy access to vehicle data. This connector is also known as the Data Link Connector (DLC).

Key features of the OBD2 connector:

Location: Typically found near the steering wheel, though sometimes it might be hidden under a panel (check common locations).
Pin 16: Provides battery power, often even when the ignition is off.
Pinout Variation: The specific pinout depends on the communication protocol used by the vehicle.
CAN bus connection: In most modern cars, pins 6 (CAN-H) and 14 (CAN-L) are connected for CAN bus communication, the most common lower-layer protocol.

OBD2 Connector Types: A vs. B

You might encounter two main types of OBD2 connectors: Type A and Type B. Type A is standard in cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles.

While both types share similar pinouts, they differ primarily in power supply output (12V for Type A, 24V for Type B) and often baud rates (500K for cars, typically 250K for heavy-duty vehicles, though 500K support is increasing in heavy-duty vehicles).

Visually, Type B connectors have a distinguishing interrupted groove in the middle. This physical difference means a Type B OBD2 adapter cable is generally compatible with both Type A and Type B sockets, but a Type A adapter will not fit into a Type B socket.

OBD2 Connector Types: Type A and Type B connectors, highlighting differences in power supply and application.

OBD2 and CAN Bus Relationship: Illustrating how OBD2 protocol utilizes the CAN bus for communication according to ISO 15765.

OBD2 Communication via CAN bus [ISO 15765-4]

Since 2008, CAN bus (ISO 15765) has been the mandatory lower-layer protocol for OBD2 in US vehicles. ISO 15765-4, also known as Diagnostics over CAN (DoCAN), standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers. It’s essentially a set of rules applied to the CAN standard (ISO 11898).

Key specifications of OBD2 over CAN (ISO 15765-4):

Bit-rate: Must be 250K or 500K.
CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
Specific CAN IDs: Defined for OBD requests and responses.
Data Length: Diagnostic CAN frames must have a data length of 8 bytes.
Adapter Cable Length: OBD2 adapter cables should not exceed 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit)

OBD2 communication is based on request and response messages. In most cars, 11-bit CAN IDs are used. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs (Electronic Control Units) for data related to a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, can target specific ECUs but are less commonly used.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (from the Engine Control Module, ECM), followed by 0x7E9 (from the Transmission Control Module, TCM).

In some vehicles, particularly vans and medium to heavy-duty vehicles, OBD2 communication might use extended 29-bit CAN identifiers. Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses in this format use CAN IDs from 0x18DAF100 to 0x18DAF1FF, often 0x18DAF110 and 0x18DAF11E. These 29-bit IDs are also sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

OBD2 Request and Response Framework: Illustrating the exchange of request and response frames in OBD2 communication.

OBD2 vs. Proprietary CAN: Contrasting OBD2 protocol with OEM-specific CAN protocols used within vehicles.

OBD2 vs. OEM-Specific CAN Protocols

It’s important to understand that OBD2 is not the primary communication system within your car. Vehicle ECUs rely on OEM-specific CAN protocols for their core functions. These proprietary protocols are unique to each vehicle manufacturer, model, and year. Unless you are the OEM, interpreting this data is generally not possible without reverse engineering (learn about reverse engineering).

When you connect a CAN bus data logger to your OBD2 port, you might observe OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, many newer vehicles have a ‘gateway’ that restricts access to this OEM CAN data through the OBD2 port, allowing only OBD2 communication.

Think of OBD2 as an additional, parallel higher-layer protocol operating alongside the OEM-specific protocols.

Bit-rate and ID Validation

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs. Tools should systematically verify these parameters.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method utilizes the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (PID 0x00 in mode 0x01, detailed in the OBD2 PID section) and detects CAN error frames caused by incorrect bit-rate transmissions.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS instead of OBDonEDS. This article mainly focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To test for OBDonEDS vs. OBDonUDS, tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-supporting vehicles should have ECUs responding to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is primarily used in EU trucks/buses.

OBD2 Bit-rate and CAN ID Validation Flowchart: A systematic approach to validating bit-rate and CAN ID configurations for OBD2 communication.

Five Lower-Layer OBD2 Protocols: Illustrating the five primary lower-layer protocols used for OBD2 communication, including CAN and older standards.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is dominant today, older vehicles might use one of four other lower-layer protocols for OBD2. Understanding these can be helpful when diagnosing older cars. Pinouts can sometimes indicate the protocol in use.

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

ISO-TP for OBD2 Message Transport [ISO 15765-2]

OBD2 data on CAN bus is transported using ISO-TP (ISO 15765-2), a transport protocol enabling payloads larger than 8 bytes. This is essential for OBD2 functions like retrieving the VIN or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly of messages. For detailed information, refer to this UDS protocol introduction.

For smaller OBD2 data, a ‘Single Frame’ (SF) format is used. Here, the first byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.

ISO-TP Frame Types for OBD2: Diagram illustrating different frame types used in ISO-TP for OBD2 communication.

Dissecting the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

Let’s examine a simplified ‘Single Frame’ OBD2 CAN message. It consists of an identifier, data length (PCI field), and data. The data itself is structured into Mode, Parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of an OBD2 message, showing Mode, PID, and data byte components.

OBD2 Request/Response Example

Consider a request for ‘Vehicle Speed’. An external tool sends a request to the car (CAN ID 0x7DF) with 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds (CAN ID 0x7E8) with 3 payload bytes, including the speed value in the 4th byte, 0x32 (decimal 50).

Using OBD2 PID 0x0D decoding rules, we find that 0x32 corresponds to 50 km/h.

OBD2 Request and Response Example: Illustrating a CAN trace of an OBD2 request for vehicle speed and the corresponding response.

OBD2 PID Example – Vehicle Speed: Detailed look at PID 0x0D (Vehicle Speed), showing request and response parameters.

OBD2 Services (Modes): Overview of the 10 standardized OBD2 diagnostic services or modes.

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services or modes. Mode 0x01 provides real-time data, while others are used for DTCs or freeze frame data. Vehicles aren’t required to support all 10 modes and may include OEM-specific modes. In OBD2 messages, the mode is the 2nd byte. In responses, 0x40 is added to the request mode value (e.g., request 0x01 becomes response 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs). For instance, mode 0x01 has ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs.

One PID is particularly important: mode 0x01 PID 0x00. If an emissions-related ECU supports OBD2, it must support this PID. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. Thus, PID 0x00 acts as a fundamental OBD2 compatibility test. Similarly, PIDs 0x20, 0x40, and so on, reveal support for subsequent PID ranges within mode 0x01.

OBD2 Request and Response Structure with PIDs: Emphasizing the role of Parameter IDs (PIDs) in OBD2 requests and responses.

OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool, useful for exploring service 01 PIDs.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling data decoding into physical values. Our OBD2 PID overview tool helps construct OBD2 requests and decode responses dynamically.

Logging and Decoding OBD2 Data: A Practical Guide

Let’s walk through logging OBD2 data using a CANedge CAN bus data logger. The CANedge allows custom CAN frame transmission, making it suitable for OBD2 logging. Connect it to your vehicle using an OBD2-DB9 adapter cable.

OBD2 Data Logger Setup: Illustrating the connection of an OBD2 data logger for capturing PID data.

OBD2 Bit Rate Validation: Example of validating bit rate for OBD2 communication.

OBD2 Supported PIDs Test Responses: Reviewing responses to ‘Supported PIDs’ requests using asammdf software.

Step #1: Bit-rate, ID & PID Validation

ISO 15765-4 outlines how to determine the bit-rate and IDs for a vehicle. Here’s how to test using CANedge (refer to the CANedge Intro for details):

Bit-rate Test: Send a CAN frame at 500K and check for successful transmission. If unsuccessful, try 250K.
Bit-rate Confirmation: Use the identified bit-rate for subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests and analyze the responses.
ID Type Determination: Response IDs will indicate 11-bit or 29-bit IDs.
PID Support Verification: Response data reveals supported PIDs.

Plug & play configurations are available to simplify these tests. Most post-2008 non-EV cars support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request (using 0x7DF) are common because it polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses may occur for this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs tend to respond. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, allowing for reduced busload by directing future requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

Once you know your vehicle’s supported PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs. Consider these points:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
Request Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
Battery Conservation: Implement triggers to stop transmissions when the vehicle is inactive to prevent battery drain.
Data Filtering: Apply filters to record only OBD2 responses, especially if OEM-specific CAN data is also present.

With these configurations, your device is set to log raw OBD2 data.

CANedge OBD2 PID Request List Example: An example configuration of OBD2 PID requests for a CANedge data logger.

Decoded OBD2 Data Visualization in asammdf: Visual plot of decoded OBD2 data using asammdf software and a DBC file.

Step #3: DBC Decode Raw OBD2 Data

To analyze and visualize logged data, decode the raw OBD2 data into physical values. Decoding information is in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, a free OBD2 DBC file is available to simplify DBC decoding in most CAN bus software tools.

OBD2 data decoding is more complex than standard CAN signals because different PIDs share the same CAN ID (e.g., 0x7E8). Therefore, decoding requires considering the CAN ID, OBD2 mode, and PID. This ‘extended multiplexing’ approach can be implemented in DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge simplifies OBD2 data recording to SD cards (8-32 GB). Connect it to your vehicle to start logging and use free software/APIs with our OBD2 DBC for data analysis.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

While most examples have been single-frame, OBD2 also uses multi-frame communication via ISO-TP (ISO 15765-2). Multi-frame communication requires flow control frames. CANedge configurations can handle this by transmitting a static flow control frame ~50 ms after the initial request. Tools like CANedge MF4 decoders are needed for processing multi-frame OBD2 responses.

OBD2 Multi-Frame Request Example: Request message for Vehicle Identification Number (VIN), showcasing multi-frame communication.

Example 1: OBD2 Vehicle Identification Number (VIN)

The VIN is important for telematics and diagnostics. Retrieve it using OBD2 mode 0x09 and PID 0x02.

The tool sends a Single Frame request. The vehicle responds with a First Frame indicating a 20-byte length, mode (0x49), and PID (0x02), followed by the VIN. The VIN (17 bytes) is encoded after the PID and Number Of Data Items (NODI), which is 1 in this case. Convert the HEX VIN to ASCII as detailed in our UDS intro.

Example 2: OBD2 Multi-PID Request (6x)

Tools can request up to 6 mode 0x01 PIDs in a single request frame. The ECU responds with data for supported PIDs across multiple frames if needed. This enhances data collection efficiency but complicates signal encoding, making generic DBC files less effective. We generally don’t recommend this method.

The multi-frame response is similar to the VIN example but includes requested PIDs and their data. PIDs are often ordered as requested, but this isn’t strictly required by ISO 15031-5. Decoding this using DBC files is complex. This method involves extended multiplexing, making generic DBC use difficult and scaling challenging. Custom scripts and recording transmit messages can help interpret responses by correlating them with requests, but these approaches are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

Request emissions-related DTCs using mode 0x03 (‘Show stored Diagnostic Trouble Codes’). No PID is needed in the request. ECUs respond with the number of stored DTCs (potentially zero) and each DTC uses 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs.

The 2-byte DTC value is categorized and coded (4-digit hexadecimal), as per ISO 15031-5/ISO 15031-6. Decoded DTCs can be looked up using OBD2 DTC lookup tools like repairpal.com.

OBD2 DTC Decoding Example: Breakdown of how Diagnostic Trouble Codes (DTCs) are encoded and interpreted.

OBD2 Data Logging Use Cases

OBD2 data logging has diverse applications for cars and light trucks:

Car Data Logging

OBD2 data helps reduce fuel costs, improve driving habits, test prototype parts, and optimize insurance models.

obd2 logger

Real-time Car Diagnostics

OBD2 interfaces stream human-readable data in real-time for diagnosing vehicle issues efficiently.

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers monitor vehicles in the cloud for predictive maintenance, preventing breakdowns.

predictive maintenance

Vehicle Black Box Logger

OBD2 loggers serve as ‘black boxes’ for vehicles, providing crucial data for disputes and diagnostics.

can bus blackbox

Have an OBD2 data logging application? Contact us for expert advice!

Explore our guides section for more introductions, or download the ‘Ultimate Guide’ PDF.

Ready to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended for You

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN