Home > automotive-insights > What is On-Board Diagnostics (OBD) 2 Software Stack?

What is On-Board Diagnostics (OBD)?

On-Board Diagnostics (OBD), as the name suggests, refers to the in-vehicle system that detects and reports the status of vehicle health. With the help of an OBD port (fitted in a vehicle) and OBD connector, the repair technician/after-sales service provider gets access to critical vehicle parameters like vehicle speed, engine data, emission data and more in the form of Diagnostic Trouble Codes (DTC)

OBD protocol has been upgraded a few times both in terms of standardization and capability. The latest version is called On-board diagnostics 2.

What is OBD II software stack?

In order to facilitate a standardized method of vehicle ECU diagnosis and correction of vehicle emission related malfunctions across the geographies, International Standards Organization (ISO) introduced ISO 15031 standard for automotive industry.

ISO 15031 is a standard for Communication between vehicle (OBD port/connecter, defined by SAE J1962) and external equipment (Diagnostic Tester) for emissions-related diagnostics

On-board diagnostics 2 stack is a set of software specifications or services implemented based on ISO 15031 standard. This OBD II software stack is best suited for passenger car and light commercial vehicle applications

OBD II stack can be implemented over five signaling protocols or physical layers, as shown in the diagram:

OBD Stack

Types of in-vehicle communications

Vehicle communication can be broadly classified into two:

In-vehicle networking: This refers to exchange of data between various automotive electronic control units (ECU) which are part of the vehicle network.

Automotive Protocols like CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, MOST (Media Oriented Systems Transport) are defined for in-vehicle network communication.

Usually this is a broadcast network and one can add listen-only nodes easily.

Vehicle Diagnostics/External communication: Vehicle Diagnostics communication is used for diagnosis and repair of vehicle sub-systems or ECU.

This type of communication is useful for monitoring and reporting of system malfunction monitoring and vehicle parameters. An external tool may be used to re-configure and re-flash the ECU to rectify the malfunction.

Vehicle Diagnostics is a query-response communication. The external tool asks for a particular information (diagnostic request) and the ECU (the control unit to which the query is directed) responds with the answer (diagnostic response)

For diagnostic communication, the physical medium (also known as the signaling protocol) is same as the medium used for in-vehicle communication – CAN, LIN, Flexray, MOST.

Additionally, there are also dedicated protocols like K-Line, J1850 (VPW, PWM) and more that work on serial link. Over these physical layers, diagnostics applications are implemented as per the protocol standards like KWP2000 (ISO 14230), UDS (ISO 14229).

In passenger cars protocols like KWP2000 (ISO 14230) and UDS (ISO 14229) are used as signaling protocols/physical layers, but what data is sent and what conversion factors are used is proprietary to the vehicle OEM (Original Equipment Manufacturer).

Thus, it is not easy to get access to the vehicle data unless one has been granted access by the automotive OEM.

OBD2 protocol and Vehicle Diagnostics Communication:

OBD2 qualifies as a protocol for vehicle diagnostics communication (query-response communication).

OBD2 is a part of emission legislation. Hence it follows the CARB (California Air Resources Board) initiated protocol mandates. OBD2 protocol monitors parameters in emission relevant ECUs as per the guidelines of CARB.

On-board diagnostics 2 also follows CARB guidelines for data storage and data accessibility to be provided to the external scan tools.

Diagnostic protocols like UDS and KWP2000 support re-configuration and re-flashing of ECU (writing to EEPROM and Flash), but OBD2 supports only read access.

The external scan tool requirements (defined in ISO 15031) mandate that the following modes should be supported:

Diagnostic services ISO 15031

Using Mode $01 and $09, several vehicle parameters become accessible to any external scan tool and the data format is also standardized.

Details of On-board diagnostics 2 implementation over physical layers/signaling protocols

OBD protocol has witnessed several revisions (versions update) over the years. Hence OBD protocol still supports various legacy physical layers.

Most of the modern vehicle models implement OBD2 over CAN.

Legacy protocols are J1850 (2 variants – PWM, VPW), K-Line and ISO9141-2. Once communication is established in one of the medium, OBD supports query-response communication.

Following are the hardware and software modules for OBD implementation:

OBD module Hardware Software
OBD services NA ISO 15031
OBD over CAN CAN support in microcontroller

CAN transceiver

ISO15765 (CAN TP layer)
OBD over J1850 (VPW/PWM) PWM support in microcontroller

J1850 transceiver

PWM driver

VPW/PWM driver based on J1850 standard

OBD over K-Line UART support in microcontroller

K-Line/ISO9141 transceiver

UART driver

K-Line driver (based on ISO14230)

OBD over ISO9141-2 UART support in microcontroller

K-Line/ISO9141 transceiver

UART driver

ISO9141-2 driver


Auto protocol detection is possible to identify which protocol is supported by the vehicle

OBD Challenges/Limitations

  • Data available over OBD port (OBD connector) is related to powertrain and emission ECUs’. Hence access to body control data like seat belt status, airbag status and more is not available
  • Data is available only in query-response mechanism
  • OEMs have option to define proprietary DTCs (Diagnostic Trouble Codes) and not make it available in the public domain. It is also observed that some vehicle parameters are not supported in certain vehicle models. These can lead to compatibility issues
  • OBD supports only read-access to emission relevant data (vehicle parameters, DTCs). There is no support for write-access to data for reprogramming or test sensors/actuators. Hence it is not easy to monitor and rectify malfunction related to vehicle functionality (for example engine immobilizer) using OBD communication.

Despite the limitations, OBD is the only option to support vehicle diagnostics applications for a wide range of passenger cars/after-market products already on road.

OBD2 is very critical for integrating connected car and telematics solutions for millions of vehicles already on road.


On-board diagnostics 2 software development:


On-board Diagnostics 2 Software development for ECU applications

  • CAN, J1850. K-Line based OBD2 implementation
  • PID and OBD modes implementation
  • OBD2 diagnostic software integration with ECU software

OBD2 diagnostic solutions for After-market products

  • OBD2 diagnostic software development and integration services
  • OBD2 diagnostic services development for vehicle data access

OBD2 solutions for vehicle parameter collections

  • OBD2 software design and development services for on-road vehicles

to Help!