Introduction to OBD 2 Protocol

The On-Board Diagnostics (OBD) 2 protocol 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 the emission of vehicles. Later with technological advancements the OBD-2 protocol was defined along with the connector specification in 1994 by the CARB and since become the globally adapted standard. With the ability to retrieve real-time data and diagnose potential issues, the OBD 2 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.

Understanding the OBD2 Standard Connector Interface

As the On-Board Diagnostics OBD2 protocol is expected to support various OEM’s each with their many proprietary protocols while ensuring global standardization, there was a need to create a standard yet flexible connector interfaces. The OBD2 protocol defines a standardized 16 bin 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 pin out of the same.

OBD2 Connector

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 of the manufacturers support Automotive Ethernet interface as well over these pins.

It can also be noted that 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 to a type B socket.

Exploring OBD-II Signal Protocols

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 latest 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 visited earlier in our article is used to communicate various parameters of the vehicle over 8-byte CAN packet.

By simply plugging in a compatible OBD-II scanner or tool, users can retrieve valuable information about the vehicle's performance and health over any of these supported interfaces.

Deep Dive into the OBD2 CAN Communication Protocol

Among the various On-Board Diagnostics OBD2 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 easily.

In the context of OSI layers, the CAN protocols on OBD can be captured below.

OBD2 OSI Layer Mapping

The lower layers till Transport layer leverages the specification of ISO15765-4 as it is well defined and adopted. The higher-level application protocol is defined as the SAE J1979 protocol. Later the ISO 15031-5 is defined based on the SAE J1979 and 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 OBD 2 protocol defines a request/response mechanism as follows.

OBD2 Request Response Packet

The request frame in the ISO15765-4/ SAE J1979 protocol has the modes/service identifier in the first byte while rest of the frame can have 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 negative response, the 0x7F is sent as the first byte followed by the request service ID and error code.

As a convention, the request packets are transmitted over the broadcast CAN ID 0x7DF and the ECUs respond with the CAN ID from 0x7E8 to 0x7EF.

OBD-II Services

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 well defined packet format over which the vehicle information can be obtained. In addition to these, the OBD2 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 information, PID 0x0C gives Engine RPM data and PID 0x14 gives Oxygen Sensor 1 information. An example communication to read the Engine RPM data is given below.

OBD2 Read RPM Request

With this level of standardization, a common framework is achieved across all vehicles from different manufacturers.

Decoding OBD-II Diagnostic Trouble Codes (DTCs)

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 its memory. By utilizing an OBD2 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

  • B - Body
  • C - Chassis
  • P - Powertrain
  • U - Network

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. So, with these 5-digit code, it is possible to pinpoint to the originator of the trouble.

On the OBD2 protocol, the 5 characters are encoded to a 16-bit code as follows:

OBD2 DTC 16 Bit Encoding

The MSB 2 bits are encoded as shown above. The next 2 bits are used to 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.

Leveraging OBD-II Diagnostic Data

One of the key advantages of the OBD 2 protocol is its ability to provide valuable diagnostic data in real-time. By connecting an OBD2 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 OBD2 diagnostic data, users can make informed decisions regarding maintenance and repairs, resulting in improved performance and increased longevity of the vehicle.

The Future of OBD 2: Innovations and Advancements

The OBD 2 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 OBD 2 diagnostics. Dedicated wireless protocol standards are also being explored.
Enhanced Data Analysis: With the advent of big data analytics and machine learning, OBD 2 data can be analyzed in more sophisticated ways. This enables predictive maintenance, anomaly detection, and proactive diagnostics, leading to improved reliability and reduced downtime.
Integration with Vehicle Systems: OBD 2 is being integrated more closely with other vehicle systems, such as infotainment and telematics. This integration enables enhanced user experiences, such as real-time performance monitoring, personalized recommendations, and remote diagnostics.
Cybersecurity: As vehicles become more connected, ensuring the security of OBD 2 systems is paramount. While the specification and more importantly the implementation are currently not matching today's threats, manufacturers are actively working on implementing robust cybersecurity measures to protect against potential threats and unauthorized access.

Conclusion: Unleashing the Power of OBD 2

In conclusion, the OBD 2 protocol is a powerful tool that unlocks a wealth of diagnostic information about your vehicle. From the standard connector interface to the signal protocols, diagnostic trouble codes, and advanced monitoring capabilities, understanding the nuances of OBD 2 can provide valuable insights into your vehicle's performance, health, and potential issues.

Subscribe to our Insights