The On-Board Diagnostics II (OBD2) system is a cornerstone of modern vehicle maintenance and diagnostics. At the heart of this system lies the Obd2 Data Link Connector, a standardized interface that provides access to your vehicle’s internal computer network. This guide delves into the intricacies of the OBD2 data link connector, explaining its purpose, standards, and why it’s crucial for anyone involved in vehicle repair, maintenance, or data analysis.
What is the OBD2 Data Link Connector?
The OBD2 system is essentially your car’s self-reporting mechanism, designed to monitor and diagnose various vehicle systems, primarily emissions-related components. The OBD2 data link connector (DLC), also known as the OBD2 port or OBD2 connector, is the physical gateway that allows external devices, like scan tools or data loggers, to communicate with your vehicle’s OBD2 system.
Think of the malfunction indicator light (MIL), commonly known as the “check engine light,” on your dashboard. When this light illuminates, it signals that the vehicle’s computer has detected an issue. To understand the problem, a mechanic will connect an OBD2 scanner to the OBD2 data link connector, typically located under the dashboard on the driver’s side.
This connection enables the scanner to send ‘OBD2 requests’ to the vehicle’s electronic control units (ECUs) and receive ‘OBD2 responses’. These responses can include a wealth of information, from real-time data like speed and engine temperature to diagnostic trouble codes (DTCs) that pinpoint specific malfunctions. The obd2 data link connector is therefore the critical point of access for retrieving this diagnostic and performance data.
Understanding OBD2: The malfunction indicator light (MIL) signals potential issues, diagnosable via the OBD2 data link connector and a scan tool.
Does Your Car Have an OBD2 Data Link Connector?
The prevalence of the OBD2 data link connector is widespread. In short, the answer is almost certainly yes if you own a non-electric car manufactured in the last few decades.
The implementation of OBD2 became mandatory in phases across different regions:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: Required in the European Union for gasoline cars.
- 2003: Required in the EU for diesel cars as well (EOBD).
- 2005: OBD2 was mandated in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the OBD2 communication basis.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
While most modern non-electric vehicles feature an OBD2 data link connector, it’s worth noting that older cars, even if equipped with a 16-pin connector resembling an OBD2 port, might not fully support the OBD2 protocol. Compliance is generally linked to the vehicle’s manufacturing origin and year of purchase.
OBD2 Compliance Timeline: A visual guide to determine if your car, based on region and fuel type, is likely OBD2 compliant.
A Brief History of the OBD2 Data Link Connector
The story of the OBD2 data link connector is intertwined with the history of emissions regulations. Its origin can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards for emission control.
The OBD2 standard, including the standardization of the OBD2 connector, was further developed and recommended by the Society of Automotive Engineers (SAE). This led to the SAE J1962 standard, which defined the physical characteristics and pin assignments of the OBD2 data link connector, ensuring interoperability across different vehicle manufacturers. This standardization was a crucial step, making vehicle diagnostics more accessible and efficient.
OBD2 History: From emission control origins to standardized diagnostics, the OBD2 data link connector’s evolution is tied to automotive regulation and technology.
The Future of OBD2 and the Data Link Connector
While OBD2 remains relevant, the automotive landscape is evolving. Electric vehicles (EVs), for instance, are not mandated to support OBD2 in the same way as internal combustion engine vehicles, primarily because emissions control is not their primary concern for OBD2 compliance. Many EVs utilize OEM-specific diagnostic protocols like UDS (Unified Diagnostic Services) instead of standard OBD2 through the obd2 data link connector.
However, the concept of standardized vehicle diagnostics is still valuable. Efforts like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to enhance and streamline OBD communication, often leveraging UDS as the underlying protocol. These advancements aim to address the limitations of traditional OBD2 in terms of data richness and communication protocols.
The idea of OBD3, incorporating telematics into vehicles, envisions a future where emission control checks become automated. OBD3 proposes adding a radio transponder to vehicles, enabling automatic transmission of the vehicle identification number (VIN) and DTCs to a central server for monitoring. While convenient, this concept raises privacy concerns.
Interestingly, some automotive industry voices are suggesting limiting third-party access to vehicle data via the OBD2 data link connector during driving. The argument centers on security and data control, with a push towards centralizing data collection through manufacturers’ servers. This could potentially reshape the market for third-party OBD2 services and tools that rely on accessing data through the obd2 data link connector.
OBD2 Future: The future may see changes in OBD2’s role, particularly with electric vehicles and evolving data access paradigms via the OBD2 data link connector.
Expand Your Knowledge with the ‘Ultimate CAN Guide’
Ready to become a CAN bus expert?
Our comprehensive 160+ page PDF offers 12 ‘simple intros’ to the world of CAN bus technology.
Download now
OBD2 Standards and the Data Link Connector
OBD2 operates as a higher-layer protocol, much like a language, built upon lower-layer communication methods such as CAN (Controller Area Network), which functions as the communication channel. The OBD2 data link connector is a key component defined within these standards.
The OBD2 standards framework, encompassing SAE and ISO specifications, defines various aspects, including the OBD2 connector itself, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards can be visualized using the 7-layer OSI model, illustrating how different layers are addressed by both SAE (primarily US) and ISO (international/EU) standards. Notably, certain standards are technically very similar, such as SAE J1979 and ISO 15031-5 (application layer), and SAE J1962 and ISO 15031-3 (physical connector).
OBD2 and CAN Bus in the OSI Model: Illustrating how OBD2 protocols and CAN bus standards relate within the 7-layer OSI model, highlighting the role of the OBD2 data link connector.
SAE J1962: Defining the OBD2 Data Link Connector
The OBD2 data link connector, standardized under SAE J1962 and ISO 15031-3, is a 16-pin interface designed for easy access to vehicle data. SAE J1962 specifically outlines the physical characteristics, pinout, and electrical specifications of the obd2 data link connector.
This 16-pin connector, often referred to as a Type A OBD2 pin connector or Data Link Connector (DLC), is usually located within easy reach near the steering wheel, although its exact placement can sometimes be hidden.
Key features of the OBD2 data link connector include:
- Pin 16: Provides battery power (often active even when the ignition is off), crucial for powering external diagnostic tools.
- Pinout Variation: The specific pin assignments within the OBD2 data link connector depend on the communication protocol used by the vehicle.
- CAN Bus Integration: In modern vehicles, CAN bus is the predominant lower-layer protocol, meaning pins 6 (CAN-High) and 14 (CAN-Low) of the obd2 data link connector are typically connected to the vehicle’s CAN bus network.
Understanding the SAE J1962 standard is essential for anyone working with vehicle diagnostics, as it ensures compatibility and proper communication through the OBD2 data link connector.
OBD2 Connector Types: A and B
In practice, you may encounter two main types of OBD2 data link connectors: Type A and Type B. Type A is most commonly found in passenger cars and light-duty vehicles, while Type B is typical in medium and heavy-duty vehicles.
While both types share a similar 16-pin layout and pin assignments, they differ primarily in their power supply output. Type A connectors typically provide 12V power, whereas Type B connectors supply 24V, reflecting the different electrical systems in cars versus larger vehicles. Baud rates may also vary, with passenger cars commonly using 500K, while heavy-duty vehicles often use 250K (though 500K support is increasing).
A key visual differentiator is the OBD2 connector Type B has an interrupted groove in the middle of the connector face. This physical difference means that 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 A and B: A comparison highlighting the differences in power supply (12V vs 24V) and physical characteristics of Type A and Type B OBD2 data link connectors.
OBD2 Communication via CAN Bus and the Data Link Connector
Since 2008, CAN bus has become the mandated lower-layer protocol for OBD2 in US vehicles, as per ISO 15765. This means that communication through the OBD2 data link connector in most modern vehicles is based on CAN bus.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies how OBD2 protocols are implemented over a CAN network. It defines constraints on the CAN standard (ISO 11898) for diagnostic purposes, particularly focusing on the physical, data link, and network layers. These specifications ensure reliable and standardized communication through the obd2 data link connector.
Key aspects of ISO 15765-4 related to the OBD2 data link connector and CAN communication include:
- CAN Bit-rate: Standardized at either 250K or 500K.
- CAN Identifiers: Supports both 11-bit and 29-bit CAN IDs.
- OBD2 Specific CAN IDs: Defines specific CAN IDs reserved for OBD requests and responses.
- Data Length: Diagnostic CAN frames are restricted to 8 bytes of data.
- Cable Length: The OBD2 adapter cable connected to the obd2 data link connector must not exceed 5 meters.
These specifications ensure that diagnostic tools communicating through the OBD2 data link connector can reliably interact with the vehicle’s CAN network using a standardized approach.
OBD2 CAN Identifiers (11-bit, 29-bit) and the Data Link Connector
OBD2 communication, accessed via the OBD2 data link connector, relies on a request-response message exchange. In most passenger cars, 11-bit CAN IDs are used for OBD2 communication.
- Functional Addressing (11-bit): The CAN ID 0x7DF is used for ‘Functional Addressing’, broadcasting a request to all OBD2-compliant ECUs to check if they have data relevant to the requested parameter.
- Physical Addressing (11-bit): CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’, targeting specific ECUs with requests (less common in typical OBD2 usage).
- Response IDs (11-bit): ECUs respond with 11-bit IDs in the range 0x7E8 to 0x7EF. 0x7E8 is the most common response ID, typically originating from the ECM (Engine Control Module), and 0x7E9 often comes from the TCM (Transmission Control Module).
In some vehicles, particularly vans, light, medium, and heavy-duty vehicles, extended 29-bit CAN identifiers may be used for OBD2 communication through the obd2 data link connector instead of 11-bit IDs.
- Functional Addressing (29-bit): The 29-bit CAN ID 0x18DB33F1 serves as the ‘Functional Addressing’ ID in these systems.
- Response IDs (29-bit): Responses are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (common examples include 0x18DAF110 and 0x18DAF11E). These response IDs are sometimes represented in the J1939 PGN (Parameter Group Number) format, specifically PGN 0xDA00 (55808), which J1939-71 standard designates as ‘Reserved for ISO 15765-2’.
Understanding these CAN identifiers is crucial for correctly interpreting OBD2 communication data obtained through the OBD2 data link connector.
OBD2 Request and Response Frames: Illustrating the request-response framework of OBD2 communication and a table summarizing common OBD2 CAN bus identifiers used via the data link connector.
OBD2 vs. OEM-Specific CAN Protocols and the Data Link Connector
It’s important to recognize that while OBD2 communication is accessible through the OBD2 data link connector, vehicle ECUs primarily operate using proprietary CAN protocols defined by the Original Equipment Manufacturer (OEM). These OEM-specific protocols are essential for the vehicle’s core functions and are often unique to the vehicle brand, model, and year. Typically, these OEM protocols are not publicly documented, making direct interpretation challenging without reverse engineering efforts.
When you connect a CAN bus data logger to the OBD2 data link connector, you might observe both OBD2 communication and OEM-specific CAN data. OEM data is often broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a ‘gateway’ system restricts access to this OEM CAN data through the OBD2 data link connector, allowing only standardized OBD2 communication to pass through.
Therefore, it’s helpful to think of OBD2 as a standardized, ‘add-on’ higher-layer protocol that operates in parallel with the vehicle’s essential OEM-specific communication network, both potentially accessible via the OBD2 data link connector.
Bit-rate and ID Validation via the OBD2 Data Link Connector
As previously mentioned, OBD2 communication via the OBD2 data link connector can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern vehicles commonly use 500K and 11-bit IDs, but diagnostic tools should systematically validate these parameters.
ISO 15765-4 provides a recommended initialization sequence for automatically determining the correct bit-rate and CAN ID combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (Mode 0x01 PID 0x00). Sending requests with an incorrect bit-rate will result in CAN error frames, allowing the tool to identify the correct setting.
Newer versions of ISO 15765-4 also consider vehicles that may support OBD communication through OBDonUDS rather than the more traditional OBDonEDS (OBD on Emission Diagnostic Service). While this article primarily focuses on OBDonEDS (often referred to as OBD2, SAE OBD, EOBD, or ISO OBD), OBDonUDS (or WWH-OBD) is becoming more prevalent, especially in EU trucks and buses.
To differentiate between OBDonEDS and OBDonUDS support, diagnostic tools can send additional UDS requests using 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.
OBD2 Bit-rate and CAN ID Validation Flowchart: A diagram illustrating the systematic process defined in ISO 15765-4 for validating bit-rate and CAN ID settings for OBD2 communication via the data link connector.
Five Lower-Layer OBD2 Protocols and the Data Link Connector
While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles manufactured after 2008, older vehicles may utilize one of five lower-layer protocols through the OBD2 data link connector. Understanding these protocols and their associated pinouts on the OBD2 connector can be helpful when working with older vehicles:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today. Pins 6 & 14 on the OBD2 data link connector are key for CAN communication.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ Asian vehicles. Pin 7 (K-line) is relevant on the OBD2 data link connector.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars in 2000-2004. Pins 7 (K-line) and 15 (L-line) are used on the OBD2 data link connector.
- SAE J1850 (VPW): Variable Pulse Width Modulation, primarily used in older GM vehicles. Pin 2 on the OBD2 data link connector is used for VPW.
- SAE J1850 (PWM): Pulse Width Modulation, mainly used in older Ford vehicles. Pins 2 & 10 on the OBD2 data link connector are used for PWM.
ISO 15765-2: Transporting OBD2 Messages via ISO-TP
All OBD2 communication, accessed through the OBD2 data link connector, utilizes the ISO-TP (ISO 15765-2) transport protocol over CAN. ISO-TP is essential for transmitting OBD2 messages that exceed the 8-byte payload limit of a standard CAN frame. This is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO-TP provides mechanisms for segmentation, flow control, and reassembly of these larger messages.
However, many OBD2 data requests and responses fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In a Single Frame, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes available for the OBD2-specific message content within the CAN frame transmitted via the obd2 data link connector.
ISO-TP Frame Types for OBD2: An overview of ISO-TP frame types used in OBD2 communication, illustrating single-frame and multi-frame message structures transmitted via the OBD2 data link connector.
SAE J1979, ISO 15031-5: The OBD2 Diagnostic Message Structure
To understand OBD2 communication via CAN, consider a simplified ‘Single Frame’ OBD2 CAN message transmitted and received through the OBD2 data link connector. An OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The payload is further structured into Mode, parameter ID (PID), and data bytes.
Example: OBD2 Request/Response via the Data Link Connector
Let’s examine a practical example: requesting ‘Vehicle Speed’ using OBD2 through the OBD2 data link connector.
- Request: An external tool sends a request message via the OBD2 data link connector with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D.
- Response: The vehicle responds, sending a message back through the OBD2 data link connector with CAN ID 0x7E8 and a 3-byte payload. This payload includes the requested vehicle speed data in the 4th byte (data byte 1), in this case, 0x32 (decimal 50).
By consulting OBD2 PID documentation for PID 0x0D, we can determine that the value 0x32 represents a vehicle speed of 50 km/h. This example illustrates the basic request-response mechanism and data interpretation involved in OBD2 communication via the obd2 data link connector.
OBD2 Request and Response Example: Illustrating a request for Vehicle Speed (PID 0x0D) and the corresponding response, showing CAN IDs and payload structure in communication via the OBD2 data link connector.
The 10 OBD2 Services (Modes) Accessed via the Data Link Connector
OBD2 defines 10 diagnostic services, also known as modes, accessible via the OBD2 data link connector. These services cover various diagnostic and data retrieval functions:
- Mode 0x01: Show current data: Provides real-time data parameters.
- Mode 0x02: Show freeze frame data: Displays data captured when a DTC was set.
- Mode 0x03: Show stored DTCs: Retrieves currently stored Diagnostic Trouble Codes.
- Mode 0x04: Clear DTCs and stored values: Resets DTCs and clears related stored data.
- Mode 0x05: Oxygen sensor monitoring test results: Displays results from oxygen sensor tests.
- Mode 0x06: On-board monitoring test results for non-continuously monitored systems: Shows test results for specific systems.
- Mode 0x07: Show pending DTCs: Retrieves DTCs that are pending confirmation.
- Mode 0x08: Control operation of on-board component/system: Allows control of certain vehicle components for testing.
- Mode 0x09: Request vehicle information: Used to request vehicle-specific information like VIN.
- Mode 0x0A: Show permanent DTCs: Retrieves DTCs that cannot be cleared by normal means.
It’s important to note that vehicles are not required to support all 10 OBD2 modes, and manufacturers may also implement OEM-specific modes beyond these standardized ones. In OBD2 messages, the mode is indicated in the second byte of the payload. In a request, the mode is directly included (e.g., 0x01), while in a response, 0x40 is added to the mode value (e.g., resulting in 0x41 for a response to mode 0x01).
OBD2 Parameter IDs (PIDs) and the Data Link Connector
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the data being requested. Mode 0x01, for example, includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level, all accessible via the OBD2 data link connector. However, a vehicle may not support all PIDs within a given mode; in practice, most vehicles support only a subset of the standardized PIDs.
One PID, PID 0x00 in Mode 0x01, holds special significance. If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. Responding to this PID, the ECU indicates which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for verifying OBD2 compatibility through the obd2 data link connector. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of Mode 0x01 PIDs.
OBD2 PID Overview Tool
For detailed information on standard OBD2 PIDs, including scaling and decoding rules, refer to SAE J1979 and ISO 15031-5 appendices. These resources provide the necessary information to convert raw OBD2 data into meaningful physical values.
To simplify working with Mode 0x01 PIDs, consider using an OBD2 PID overview tool. This tool can assist in constructing OBD2 request frames and dynamically decoding OBD2 responses received through the OBD2 data link connector.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data via the Data Link Connector
This section provides a practical example of logging OBD2 data using a CANedge CAN bus data logger connected to the OBD2 data link connector. The CANedge can be configured to transmit custom CAN frames, enabling it to send OBD2 requests.
To connect the CANedge to your vehicle’s OBD2 data link connector, use an OBD2-DB9 adapter cable.
Supported PIDs Validation: Reviewing responses in asammdf software to ‘Supported PIDs’ requests sent via the OBD2 data link connector.
Step #1: Bit-rate, ID, and Supported PID Validation via the Data Link Connector
As outlined in ISO 15765-4, determining the correct bit-rate and CAN IDs for OBD2 communication is crucial. You can use the CANedge to perform these validation steps via the OBD2 data link connector:
- Bit-rate Test: Send a CAN frame at 500K via the OBD2 data link connector. If successful, proceed; otherwise, try 250K.
- Bit-rate Confirmation: Use the identified bit-rate for subsequent communication.
- Supported PID Request: Send multiple ‘Supported PIDs’ requests via the OBD2 data link connector and analyze the responses.
- CAN ID Determination: Based on response IDs, determine if the vehicle uses 11-bit or 29-bit CAN IDs for OBD2 communication through the OBD2 data link connector.
- PID Support Discovery: Analyze response data to identify which PIDs are supported by the vehicle.
Pre-configured settings are available for CANedge to simplify these validation tests. Most non-EV vehicles manufactured after 2008 typically support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OB
