The on-board diagnostics protocol (OBD) is a standardized system that has revolutionized automotive diagnostics. Originally created by different vendors, it was mandated by the California Air Resources Board in 1988 for monitoring vehicle emissions. Later, with technological advancements, the OBD 2 protocol was defined along with the connector specification in 1994 by the CARB and has since become the globally adapted standard. With the ability to retrieve real-time data and diagnose potential issues, the on-board diagnostics protocol has become an essential tool for vehicle diagnostics. In this comprehensive guide, we will explore the various aspects of the OBD 2 protocol, from its standard connector interface to the advanced monitoring capabilities it offers. Our cross-domain embedded engineering services cover on-board diagnostics protocol integration across automotive, commercial vehicle, and connected IoT domains.
As the on-board diagnostics protocol is expected to support various OEMs, each with their many proprietary protocols, while ensuring global standardization, there was a need to create a standard yet flexible connector interface. The OBD 2 protocol defines a standardized 16-pin female connector interface called the J1962 connector, which is typically located near the driver's side dashboard. This connector, commonly known as the OBD2 port, provides access to the vehicle's diagnostic system.
The below diagram captures the pinout of the same:
As can be seen, the same connector supports multiple protocols and provides options to expand to OEM-defined proprietary interfaces as well. In fact, some manufacturers support Automotive Ethernet interface over these pins.
There are two types of interfaces — type A (for regular vehicles at 12V) and type B (for heavy-duty vehicles at 24V). With an elongated notch in the middle, it is impossible to insert a type A cable into a type B socket.
The OBD-II protocol supports multiple signal protocols, which determine how data is transferred between the vehicle and the diagnostic tool. The most commonly used protocols are ISO 9141-2, KWP2000, J1850 VPW, J1850 PWM, and ISO 15765 CAN (Controller Area Network).
Each protocol has its own specifications and capabilities. ISO 9141-2 is an older protocol used mainly by Asian vehicles, while KWP2000 is commonly found in later Asian vehicles. J1850 VPW and J1850 PWM are used in older American vehicles.
ISO 15765 CAN, on the other hand, is the most advanced and widely used protocol in modern vehicles, offering faster data transmission and increased diagnostic capabilities. This protocol is used to communicate various parameters of the vehicle over an 8-byte CAN packet.
By simply plugging in a compatible OBD-II protocol scanner or tool, users can retrieve valuable information about the vehicle's performance and health over any of these supported interfaces.
Among the various on-board diagnostics protocol signal protocols, the CAN (Controller Area Network) protocol stands out as the most advanced and widely adopted. As CAN protocol allows for fast and reliable communication between various electronic control units (ECUs) in the vehicle, it enables the exchange of data related to engine performance, emissions, transmission, and more.
In the context of OSI layers, the CAN protocols on OBD 2 can be captured below:
The lower layers up to the Transport layer leverage the specification of ISO15765-4 as it is well defined and widely adopted. The higher-level application protocol is defined as the SAE J1979 protocol. Later the ISO 15031-5 was defined based on the SAE J1979 and they are technically the same.
Various ECUs in the network typically transmit data continuously that can be decoded with the DBC files specific to that vehicle model.
On top of that, the on-board diagnostics protocol (OBD 2) defines a request/response mechanism as follows:
The request frame in the ISO15765-4 / SAE J1979 protocol has the modes/service identifier in the first byte while the rest of the frame carries parameter information with respect to that service.
The positive response packet has the mode ID OR'ed with 0x40 along with the rest of the data corresponding to that service. For a negative response, 0x7F is sent as the first byte followed by the request service ID and error code.
As a convention, request packets are transmitted over the broadcast CAN ID 0x7DF and ECUs respond with CAN IDs from 0x7E8 to 0x7EF.
The following services are supported by the J1979 OBD-II protocol:
| Service ID | Description |
|---|---|
| 01 | Request Current Diagnostic Data |
| 02 | Request Freeze Frame Data |
| 03 | Request Diagnostic Trouble Codes |
| 04 | Clear/Reset Diagnostic Trouble Codes and information |
| 05 | Request Oxygen Sensor Monitoring Test Results |
| 06 | Request On-Board Monitoring Test Results for Specific Monitored Systems |
| 07 | Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle |
| 08 | Request Control of On-Board System, Test or Component |
| 09 | Request Vehicle Information |
Each of these services has a well-defined packet format through which the vehicle information can be obtained. In addition to these, the OBD 2 protocol also defines a set of parameters and corresponding IDs that can be used to retrieve specific information from the vehicle. For example, PID 05 provides Engine Coolant Temperature, PID 0x0C gives Engine RPM data, and PID 0x14 gives Oxygen Sensor 1 information. An example communication to read Engine RPM data is given below.
With this level of standardization, a common framework is achieved across all vehicles from different manufacturers.
OBD-II Diagnostic Trouble Codes (DTCs) are alphanumeric codes that indicate specific issues within the vehicle's systems. When a problem is detected, the vehicle's onboard computer generates a DTC and stores it in memory. By utilizing an OBD 2 protocol scanner or tool, users can retrieve these codes and decipher their meaning. Each DTC corresponds to a specific fault or malfunction, providing valuable insights into the root cause of the problem.
The DTCs are made up of 5 characters with the first character being one of:
The second character varies from 0 to 3, representing 4 sets of these systems.
The last 3 characters refer to the actual DTC code which conveys the exact error information. With these 5-digit codes, it is possible to pinpoint the originator of the trouble.
On the OBD 2 protocol, the 5 characters are encoded to a 16-bit code as follows:
The MSB 2 bits are encoded as shown above. The next 2 bits identify the body while the following 3 nibbles represent the DTC codes. These DTC codes can be read and cleared using the services described in the preceding section.
An OBD2 protocol stack covers multiple layers: the ISO15765-4 transport layer for CAN, the SAE J1979 (ISO 15031-5) application layer for service framing, and the physical layer adapter for K-line, J1850 VPW/PWM, or CAN. A production-quality OBD2 protocol stack must handle multi-ECU broadcast requests, timing supervision, and graceful error recovery. The OBD2 protocol stack is typically a subset of a broader UDS stack, with on-board diagnostics protocol services mapped to Mode 01–09 service IDs. For teams building secure ECU bootloaders that also support on-board diagnostics protocol access, refer to our secure bootloader support for RH850.
The OBD CAN bus uses the ISO15765-4 specification, which defines the CAN bitrate (250 kbps or 500 kbps), frame format (11-bit or 29-bit identifiers), and addressing scheme (functional ID 0x7DF / physical IDs 0x7E0–0x7E7) for the on-board diagnostics protocol. Configuring the OBD CAN bus correctly is a prerequisite for any compliant OBD 2 protocol tool. Engineers implementing OBD CAN bus interfaces must also account for bus load from concurrent IVN traffic and ensure proper termination and isolation of the diagnostic channel.
One of the key advantages of the on-board diagnostics protocol is its ability to provide valuable diagnostic data in real-time. By connecting an OBD-II protocol scanner or tool to the vehicle's OBD2 port, users can access information such as engine RPM, vehicle speed, coolant temperature, oxygen sensor readings, and much more. This data can be instrumental in identifying potential issues and monitoring the overall health of the vehicle. With the help of OBD-II protocol diagnostic data, users can make informed decisions regarding maintenance and repairs, resulting in improved performance and increased longevity of the vehicle.
The on-board diagnostics protocol has come a long way since its inception, and its future looks promising. With advancements in technology and vehicle connectivity, the power of OBD 2 is set to expand even further. Here are some key areas where OBD 2 is expected to evolve:
Wireless Connectivity: As vehicles become increasingly connected, wireless communication protocols such as Bluetooth and Wi-Fi are being integrated into OBD 2 systems. This allows for seamless communication with smartphones, tablets, and other devices, enhancing the accessibility and convenience of on-board diagnostics protocol diagnostics.In conclusion, the on-board diagnostics protocol is a powerful tool that unlocks a wealth of diagnostic information about your vehicle. From the standard connector interface to the OBD 2 protocol signal protocols, OBD-II protocol diagnostic trouble codes, and advanced monitoring capabilities, understanding the nuances of the on-board diagnostics protocol provides valuable insights into your vehicle's performance, health, and potential issues.
Embien Technologies specializes in on-board diagnostics protocol development, OBD 2 protocol integration, and connected vehicle diagnostics solutions for automotive OEMs and Tier 1s.
Embien's cybersecurity services protect on-board diagnostics protocol interfaces against unauthorized access and OBD-II protocol exploitation in modern connected vehicles.
An IoT-based remote monitoring solution demonstrating sensor-to-cloud communication architecture applicable to on-board diagnostics protocol data aggregation use cases.