Need a clear understanding of the OBD2 connector diagram?
This guide provides a detailed explanation of the OBD2 connector, focusing on the “OBD2 connector diagram” and its crucial role in automotive diagnostics. We’ll explore the OBD2 pinout, its relation to vehicle communication protocols, and how to use this knowledge for effective car repairs.
This is your go-to resource for mastering the OBD2 connector diagram and applying it in practical scenarios.
You can also watch our OBD2 intro video above – or get the PDF
In this article
Author: Martin Falch (updated January 2025)
Download as PDF
Understanding the OBD2 Connector and its Diagram
OBD2, or On-Board Diagnostics version 2, is a standardized system in vehicles that allows access to self-diagnostic and reporting capabilities. At the heart of this system is the OBD2 connector, a 16-pin interface that serves as the gateway to your vehicle’s data. Understanding the OBD2 connector diagram is essential for anyone involved in automotive repair, diagnostics, or data logging.
You’ve likely encountered the OBD2 system when you see the malfunction indicator light, often called the “check engine light,” illuminate on your dashboard. This light signals an issue detected by your car’s computer. Mechanics use OBD2 scanners, which connect to the OBD2 16 pin connector, to read diagnostic trouble codes (DTCs) and access real-time vehicle parameters. This connector, typically located near the steering wheel, follows a standardized OBD2 connector diagram, ensuring compatibility across most modern vehicles.
Image showing an OBD2 scanner connected to a car’s OBD2 port, illustrating the diagnostic process.
OBD2 Connector Diagram: Is Your Car Compatible?
The question of OBD2 compatibility is easily answered for most modern vehicles: Almost certainly, yes!
Nearly all gasoline cars manufactured after 2001 and diesel cars after 2004 in Europe, and cars in the USA post-1996, are OBD2 compliant. While an OBD2 16-pin connector is a strong indicator, older vehicles might have the connector without full OBD2 support. To confirm compliance, consider the vehicle’s origin and manufacturing date:
Infographic illustrating OBD2 compliance by region and vehicle type, highlighting compatibility timelines.
The History and Evolution of the OBD2 Connector Diagram
The OBD2 standard and its OBD2 connector diagram originated in California, driven by the California Air Resources Board (CARB) requirements for emission control in new cars from 1991 onwards.
The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, including the DTCs and the OBD connector, through standards like SAE J1962. This standardization ensured that the OBD2 connector pinout diagram would be consistent across different manufacturers, simplifying diagnostics.
The OBD2 rollout was gradual but comprehensive:
- 1996: OBD2 mandated in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline cars.
- 2003: EU mandate extended to diesel cars (EOBD).
- 2005: OBD2 required in the US for medium-duty vehicles.
- 2008: US vehicles required to use ISO 15765-4 (CAN) as the OBD2 communication protocol.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
Visual timeline depicting the history of OBD2 implementation, emphasizing emission control and standardization milestones.
Timeline graphic summarizing the key dates and events in the history of OBD2 development and adoption.
Conceptual image representing the future of OBD, including OBD3, remote diagnostics, and IoT integration.
Future Trends and the OBD2 Connector
While OBD2 remains relevant, its future is evolving. Electric vehicles (EVs), for instance, are not obligated to support OBD2, and many utilize OEM-specific UDS communication, making standard OBD2 access limited. However, efforts like WWH-OBD and OBDonUDS are emerging to enhance OBD communication using the UDS protocol.
The concept of OBD3, incorporating telematics for remote emission checks, is also being discussed. This would involve adding a radio transponder to vehicles for automatic VIN and DTC transmission. While convenient, this raises privacy concerns.
Furthermore, the automotive industry is debating the role of third-party access to OBD2 data. Proposals to restrict OBD2 functionality during driving and centralize data collection by manufacturers could reshape the landscape of aftermarket OBD2 services and devices.
Illustration symbolizing the potential shift in data access for electric vehicles, moving away from traditional OBD2.
Get our ‘Ultimate CAN Guide’
Want to deepen your knowledge of vehicle communication?
Download our comprehensive 160+ page PDF guide to CAN bus technology:
Download now
OBD2 Standards and the Connector Diagram
OBD2 operates as a higher-layer protocol on communication networks like CAN bus. Understanding the OBD2 connector diagram is crucial as it is standardized by SAE J1962 / ISO 15031-3. These standards define not only the physical connector but also the communication protocols, OBD2 parameter IDs (PIDs), and more.
The OBD2 standards can be viewed within the 7-layer OSI model, with both SAE and ISO standards contributing to various layers, reflecting US and EU standardization efforts respectively. Key standards include SAE J1979 (similar to ISO 15031-5) for diagnostic services and SAE J1962 (similar to ISO 15031-3) for the OBD2 connector diagram itself.
OSI model diagram contrasting OBD2 and CAN bus standards, highlighting the layered communication architecture.
The OBD2 Connector [SAE J1962 / ISO 15031-3] and Pinout Diagram
The 16-pin OBD2 connector, detailed in SAE J1962 / ISO 15031-3, is your primary access point for vehicle data. The OBD2 connector diagram, also known as the OBD2 pinout diagram, specifies the function of each pin.
The illustration shows a Type A OBD2 connector pinout. Key aspects of the OBD2 connector diagram include:
- Location: Usually near the steering wheel, but sometimes hidden.
- Pin 16: Provides battery power, even when the ignition is off.
- Pinout Variation: The function of certain pins depends on the communication protocol used.
- CAN bus: Pins 6 (CAN-H) and 14 (CAN-L) are typically used for CAN bus communication, the most common protocol.
Understanding the OBD2 connector diagram is crucial for correctly interfacing with the vehicle’s diagnostic system.
OBD2 Connector Types: Type A vs. Type B and their Pinout Diagrams
In practice, you’ll encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles. Both types share a similar OBD2 connector pinout diagram, but differ mainly in power supply output (12V for Type A, 24V for Type B) and sometimes baud rates.
Type B connectors are physically distinguishable by an interrupted groove in the center. Type B OBD2 adapters are compatible with both Type A and Type B sockets, but Type A adapters only fit Type A sockets. The OBD2 connector diagram for both types will show similar pin assignments for data communication, but power pins will reflect the voltage difference.
Comparison diagram illustrating OBD2 Connector Type A and Type B, highlighting physical differences and voltage specifications.
Diagram visually differentiating OBD2 as a protocol and CAN bus as a communication medium, emphasizing their relationship.
OBD2, CAN Bus, and the ISO 15765-4 Standard
Since 2008, CAN bus has been the mandated lower-layer protocol for OBD2 in US vehicles, as per ISO 15765-4. This standard, also known as Diagnostics over CAN (DoCAN), specifies how OBD2 communication is implemented over CAN bus.
ISO 15765-4 standardizes the CAN interface for diagnostic tools, focusing on:
- Bit-rate: 250K or 500K CAN bus bit-rate.
- CAN IDs: 11-bit or 29-bit CAN identifiers.
- CAN IDs for OBD2: Specific CAN IDs for OBD requests and responses.
- Data Length: 8-byte diagnostic CAN frame data length.
- Cable Length: Max 5-meter OBD2 adapter cable length.
Understanding the OBD2 connector diagram in conjunction with CAN bus standards is key to diagnosing modern vehicles.
OBD2 CAN Identifiers (11-bit, 29-bit) and the Connector Diagram
OBD2 communication relies on request/response message exchanges via the OBD2 connector diagram pins designated for CAN communication.
In most cars, 11-bit CAN IDs are used. Functional addressing uses ID 0x7DF to query all OBD2-compatible ECUs. Physical addressing uses IDs 0x7E0-0x7E7 for specific ECU requests. Responses typically use 11-bit IDs 0x7E8-0x7EF, with 0x7E8 (ECM) being the most common.
Some vehicles, particularly vans and trucks, use 29-bit CAN identifiers for OBD2. Functional addressing ID here is 0x18DB33F1, with responses using IDs 0x18DAF100 to 0x18DAF1FF (often PGN 0xDA00 in J1939 terminology).
The OBD2 connector diagram facilitates these communication exchanges by providing the physical interface for CAN bus access.
Diagram illustrating the OBD2 request-response communication flow, highlighting PID data parameters within frames.
Visual comparison of OBD2 standardized CAN bus data versus OEM-specific proprietary CAN bus data within a vehicle.
OBD2 vs. Proprietary CAN Protocols and the Diagnostic Connector
Vehicle ECUs primarily use OEM-specific CAN protocols for their internal operations, not OBD2. These proprietary protocols vary by manufacturer, model, and year. While connecting a CAN bus data logger to the OBD2 connector might reveal OEM-specific CAN data, newer vehicles often use gateways to restrict access to this data, allowing only OBD2 communication through the connector.
Think of OBD2 as an additional protocol running alongside the OEM-specific protocol, both accessible through the OBD2 connector diagram‘s physical interface.
Bit-rate and ID Validation via the OBD2 Connector
OBD2 over CAN can use 250K or 500K bit-rates and 11-bit or 29-bit CAN IDs, resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs. Diagnostic tools should systematically validate these parameters, following ISO 15765-4 recommendations.
The validation process involves sending specific OBD2 requests and checking for responses, leveraging the fact that OBD2-compliant vehicles must respond to certain mandatory requests. The OBD2 connector diagram remains consistent regardless of the bit-rate or ID length used.
Flowchart illustrating the process of OBD2 bit-rate and CAN ID validation according to ISO 15765-4 standards.
Diagram showing the five lower-layer OBD2 protocols, including CAN, KWP2000, SAE J1850, and ISO9141, and their respective standards.
Five Lower-Layer OBD2 Protocols and Connector Pinouts
While CAN (ISO 15765) is prevalent today, older vehicles may use other lower-layer protocols for OBD2. Understanding these protocols and their pin assignments in the OBD2 connector diagram is helpful for diagnosing older cars.
The five protocols include:
- ISO 15765 (CAN bus): Predominant in modern vehicles (2008+ US).
- ISO14230-4 (KWP2000): Common in 2003+ Asian vehicles.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars (2000-04).
- SAE J1850 (VPW): Primarily in older GM vehicles.
- SAE J1850 (PWM): Mainly in older Ford vehicles.
The OBD2 connector diagram‘s pinout can sometimes indicate the protocol used, especially in older vehicles.
ISO-TP [ISO 15765-2] for OBD2 Message Transport
OBD2 data communication over CAN bus utilizes ISO-TP (ISO 15765-2), a transport protocol enabling payloads exceeding 8 bytes. This is crucial for transmitting larger OBD2 messages like VIN or DTCs. ISO-TP handles segmentation, flow control, and reassembly of these larger messages.
For smaller OBD2 data, ISO 15765-2 uses ‘Single Frame’ (SF) format, where the first byte indicates payload length, leaving 7 bytes for OBD2 data. The OBD2 connector diagram remains the same regardless of whether single or multi-frame messages are used.
Diagram illustrating ISO-TP frame types used in OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.
The OBD2 Diagnostic Message Structure and the Connector
An OBD2 message, transmitted via the OBD2 connector, comprises an identifier, data length (PCI field), and data. The data portion is further divided into Mode, Parameter ID (PID), and data bytes.
Breakdown of the OBD2 message structure, detailing the components of a raw OBD2 frame including Mode, PID, and data bytes.
Example: OBD2 Request/Response via the Connector
Consider a request for ‘Vehicle Speed’. A diagnostic tool sends a request message via the OBD2 connector with CAN ID 0x7DF, containing Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8, including the speed value in byte 4 (e.g., 0x32, representing 50 km/h).
By referencing OBD2 PID documentation, you can decode the raw data into meaningful physical values. The OBD2 connector diagram facilitates this data exchange by providing the physical pathway.
Example of an OBD2 request and response sequence for vehicle speed, showing CAN IDs and data bytes exchanged.
Detailed example of OBD2 PID 0x0D for Vehicle Speed, illustrating the data encoding and decoding process.
Diagram outlining the 10 OBD2 service modes (or modes), including descriptions of their diagnostic functions.
The 10 OBD2 Services (Modes) and the Diagnostic Connector
OBD2 defines 10 diagnostic services, or modes, accessible through the OBD2 connector. Mode 0x01 provides real-time data, while others manage 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 second byte. In requests, the mode is directly included (e.g., 0x01). In responses, 0x40 is added to the mode value (e.g., 0x41). The OBD2 connector diagram ensures consistent access to these services across vehicles.
OBD2 Parameter IDs (PIDs) and Data Access via the Connector
Each OBD2 mode contains Parameter IDs (PIDs). Mode 0x01, for example, includes ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs.
PID 0x00 in mode 0x01 is crucial. If an ECU supports OBD2, it must support mode 0x01 PID 0x00. Responding to this PID indicates support for PIDs 0x01-0x20, making it an OBD2 compatibility test. PIDs 0x20, 0x40, and so on, similarly indicate support for subsequent PID ranges. Accessing these PIDs is done through the standardized OBD2 connector.
Diagram reiterating the OBD2 request-response mechanism, focusing on PID data parameters and their role in diagnostics.
Tip: OBD2 PID Overview Tool for Connector Diagnostics
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 simplifies working with mode 0x01 PIDs, aiding in constructing request frames and decoding responses, directly relevant to diagnostics via the OBD2 connector.
OBD2 PID overview tool
Logging and Decoding OBD2 Data via the Connector
Let’s explore logging OBD2 data using a CANedge data logger connected via the OBD2 connector. The CANedge allows configuration of custom CAN frames for OBD2 requests.
Simply connect the CANedge to your vehicle using an OBD2-DB9 adapter cable to begin logging.
Diagram illustrating an OBD2 data logger setup, showing the connection via the OBD2 port and request/response flow.
Screenshot of asammdf software showing OBD2 PID test responses, used for validating supported PIDs.
#1: Bit-rate, ID, and Supported PID Testing via the Connector
ISO 15765-4 outlines how to determine the bit-rate and IDs for a vehicle. Use CANedge for testing:
- Test 500K CAN frame transmission (if successful, use 500K; else, try 250K).
- Use the validated bit-rate for communication via the OBD2 connector.
- Send ‘Supported PIDs’ requests and review responses.
- Response IDs indicate 11-bit or 29-bit IDs.
- Response data reveals supported PIDs.
Plug & play configs are available for these tests. Most post-2008 non-EV cars support 40-80 PIDs using 500K, 11-bit IDs, and OBD2/OBDonEDS protocol.
Asammdf GUI screenshots often show multiple responses to PID 0x00 requests due to the 0x7DF ID polling all ECUs. ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, reducing busload by targeting requests to this ECU using ‘Physical Addressing’ CAN ID 0x7E0. All communication occurs through the OBD2 connector.
#2: Configuring OBD2 PID Requests for Data Logging via the Connector
Once you know your vehicle’s supported PIDs, bit-rate, and CAN IDs, configure your transmit list with relevant PIDs. Consider:
- CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses, sent via the OBD2 connector.
- Spacing: Add 300-500 ms between requests to prevent ECU overload.
- Battery Drain: Use triggers to stop transmissions when inactive.
- Filters: Filter for OBD2 responses if OEM-specific CAN data is also present.
With this configuration, your device is set to log raw OBD2 data accessed via the OBD2 connector.
Example CANedge configuration for OBD2 PID requests, showing a transmit list setup.
Visualization of decoded OBD2 data in asammdf, plotted from a CAN bus DBC file.
#3: DBC Decoding of Raw OBD2 Data from the Connector
To analyze logged OBD2 data, decode it into physical values. ISO 15031-5/SAE J1979 and resources like Wikipedia provide decoding information. Use our free OBD2 DBC file for easy DBC decoding in CAN bus software tools.
Decoding OBD2 data is more complex due to multiplexing. Different PIDs use the same CAN ID (e.g., 0x7E8). Therefore, decoding requires using the CAN ID, OBD2 mode, and PID. This ‘extended multiplexing’ can be implemented in DBC files. All data accessed initially through the OBD2 connector.
CANedge: OBD2 Data Logger for Connector-Based Diagnostics
The CANedge simplifies OBD2 data recording to an SD card. Connect it to your vehicle’s OBD2 connector to start logging. Use free software/APIs and our OBD2 DBC for data decoding.
OBD2 logger intro CANedge
OBD2 Multi-Frame Examples [ISO-TP] and Connector Use
OBD2 uses ISO-TP for all communication, including multi-frame messages. Multi-frame communication requires flow control frames. CANedge configurations can include static flow control frames for multi-frame OBD2 requests via the OBD2 connector.
Software tools supporting ISO-TP, like CANedge MF4 decoders, are needed for multi-frame OBD2 responses. All data is initially accessed via the OBD2 connector.
Example 1: OBD2 Vehicle Identification Number (VIN) Extraction via the Connector
Extracting the VIN using OBD2 mode 0x09 and PID 0x02 involves multi-frame communication via the OBD2 connector.
The tool sends a Single Frame request. The vehicle responds with a First Frame containing length, mode (0x49), and PID (0x02), followed by the VIN in subsequent bytes. The VIN is then translated from HEX to ASCII. All communication passes through the OBD2 connector diagram‘s interface.
Example 2: OBD2 Multi-PID Request (6x) and Connector Limitations
OBD2 allows requesting up to 6 mode 0x01 PIDs in a single request, potentially resulting in multi-frame responses. While efficient, this method complicates data decoding and isn’t generally recommended. Data access still relies on the OBD2 connector.
Decoding multi-PID responses is complex, especially with generic DBC files. It requires custom solutions and is difficult to scale across vehicles. While technically feasible via the OBD2 connector, practical data logging often avoids this method.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) and Connector Diagnostics
Requesting DTCs using OBD2 mode 0x03 involves multi-frame responses when multiple DTCs are stored. Communication is initiated and received through the OBD2 connector.
DTCs are 2-byte values, with categories and 4-digit codes. Decoded DTC values can be looked up using OBD2 DTC lookup tools. The example shows a request to an ECU with 6 DTCs, requiring multi-frame responses transmitted and received via the OBD2 connector.
OBD2 Data Logging Use Cases via the Connector
OBD2 data logging, accessed through the OBD2 connector, has diverse applications:
Car Data Logging via the OBD2 Connector
OBD2 data helps reduce fuel costs, improve driving habits, test prototype parts, and for insurance purposes.
obd2 logger
Real-Time Car Diagnostics via the OBD2 Connector
OBD2 interfaces stream human-readable data in real-time for diagnosing vehicle issues.
obd2 streaming
Predictive Maintenance via OBD2 Connector Data
IoT OBD2 loggers monitor vehicles for predictive maintenance, preventing breakdowns.
predictive maintenance
Vehicle Black Box Logging via the OBD2 Connector
OBD2 loggers serve as ‘black boxes’ for vehicles, providing data for disputes or diagnostics.
can bus blackbox
Do you have an OBD2 data logging use case? Contact us for free consultation!
Contact us
For more guides, see our guides section or download the ‘Ultimate Guide’ PDF.
Need to log/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
[
