What is OBDII? The history of the onboard diagnostics board

Discover the use cases, purpose and history of on-board diagnostics and OBDII.

You may have come across the terms “OBD” or “OBDII” when reading about connected vehicles and the Geotab GO device. These features are part of a car’s on-board computers and have a history not many know about. Read this post for an overview of OBDII and a timeline of its development.

What is an OBD (on-board diagnostics)?

On-board diagnostics (OBD) refers to the automotive electronic system that provides vehicle self-diagnosis and reporting capabilities for repair technicians. An OBD gives technicians access to subsystem information for the purpose of performance monitoring and analysing repair needs.

OBD is the standard protocol used across most light-duty vehicles to retrieve vehicle diagnostic information. Information is generated by engine control units (ECUs or engine control modules) within a vehicle. They are like the vehicle’s brain or computers.

Why is OBD so important?

OBD is an important part of telematics and fleet management, making it possible to measure and manage vehicle health and driving.

Thanks to the OBD, fleets can:

• track wear trends and see what vehicle parts are wearing out faster than others
• instantly diagnose vehicle problems before they occur, supporting proactive rather than reactive management
• measure driving behaviour, speed, idling time and so much more

Where is the OBDII port located?

In a typical passenger vehicle, you can find the OBDII port on the underside of the dashboard on the driver’s side of the car. Depending on the type of vehicle, the port could have a 16-pin, 6-pin or 9-pin configuration.

What’s the difference between an OBD and OBDII?

An OBDII is, simply put, the second generation of an OBD or OBD I. The OBD I was initially externally connected to the console of a car, while the OBDII is now integrated within the vehicle itself. The original OBD was used until OBDII was invented in the early 1990s.

History of OBDII

The history of on-board diagnostics goes back to the 1960s. Several organisations set the groundwork for the standard, but it’s important to note that before standardisation, manufacturers were creating their own systems. The tools from each manufacturer (and sometimes models from the same manufacturer) had their own connector type, electronic interface requirements. They also used their own custom codes for reporting problems.

Highlights in OBD history:

1968 — The first OBD computer system with scanning capability was introduced by Volkswagen.

1978 — Datsun introduced a simple OBD system with limited non-standardised capabilities.

1979 — The Society of Automotive Engineers (SAE) recommends a standardised diagnostic connector and set of diagnostic test signals.

1980 — GM introduced a proprietary interface and protocol capable of providing engine diagnostics through an RS-232 interface or more simply, by flashing the Check Engine Light.

1988 — Standardisation of on-board diagnostics came in the late 1980s after the 1988 SAE recommendation that called for a standard connector and set of diagnostics.

1991 — The state of California required all vehicles to have some form of basic on-board diagnostics. This is referred to as OBD I.

1994 — The state of California mandated that all vehicles sold in the state starting in 1996 must have OBD as recommended by SAE — now referred to as OBDII. This stems from the desire to perform across the board emissions testing. OBDII included a series of standardised diagnostic trouble codes (DTCs).

1996 — OBD-II becomes mandatory for all cars manufactured in the United States.

2001 — EOBD (European version of OBD) becomes mandatory for all petrol vehicles in the European Union (EU).

2003 — EOBD becomes mandatory for all diesel vehicles in the EU.

2008 — Starting in 2008, all vehicles in the US are required to implement OBDII through a Controller Area Network as specified by ISO 15765-4.

What data can be accessed from the OBDII?

The OBDII provides access to status information and Diagnostic Trouble Codes (DTCs) for:

• Powertrain (Engine and transmission)
• Emission Control Systems

Additionally, you can access the following vehicle information via the OBD II:

• Vehicle Identification Number (VIN)
• Calibration Identification Number
• Ignition counter
• Emissions Control System counters

When a car is taken to a shop for service, a mechanic can connect to the OBD port with a scanning tool, read the trouble codes and identify the problem. This means mechanics can accurately diagnose malfunctions, inspect the vehicle quickly, and fix any malfunctions before they become a major problem.

Examples: 

Mode 1 (Vehicle Information):

• Pid 12 — Engine RPM
• Pid 13 — Vehicle Speed

Mode 3 (Trouble Codes: P = Powertrain, C = Chassis, B = Body, U = Network):

• P0201 — Injector circuit malfunction – Cylinder 1
• P0217 — Engine over temperature condition
• P0219 — Engine overspeed condition
• C0128 — Low brake fluid circuit
• C0710 — Steering position malfunction
• B1671 — Battery Module Voltage Out of Range
• U2021 — Invalid/ fault data received

OBD and telematics

The presence of the OBDII allows telematics devices to silently process information such as engine revolutions, vehicle speed, fault codes, fuel usage and more. The telematics device can then use this information to determine trip start and finish, over revving, speeding, excessive idling, fuel consumption, etc. All this information is uploaded to a software interface and allows fleet managers to monitor vehicle use and performance.

With the multitude of OBD protocols, not all telematics solutions are designed to work with all vehicle types that exist today. Geotab telematics overcomes this challenge by translating the vehicle diagnostic codes from different makes and models, and even electric vehicles.

With the OBD-II port, a fleet tracking solution can be connected to your vehicle quickly and easily.

If your vehicle doesn’t have a standard OBDII port, an adaptor can be used instead. Either way, the installation process is quick and doesn’t require any special tools or the assistance of a professional installer.

What is WWH-OBD?

WWH-OBD stands for Worldwide Harmonised on-board diagnostics. It is an international standard used for vehicle diagnostics, implemented by the United Nations as part of the Global Technical Regulations (GTR) mandate, which includes vehicle data monitoring such as emissions output and engine fault codes.

Advantages of WWH-OBD

Here’s a look at the benefits of moving toward WWH in more technical terms:

Access to more data types

Currently, the OBDII PIDs used in Mode 1 are only one byte long, meaning that only up to 255 unique data types are available. Expansion of the PIDs could also be applied to other OBD-II modes that have been ported over to WWH via UDS modes. Adapting WWH standards will allow for more available data and provides the possibility of future expansion.

More detailed fault data

Another advantage with WWH is the expansion of information contained in a fault. Currently, OBDII uses a two-byte diagnostic trouble code (DTC) to indicate when a fault occurred (for example, P0070 indicates Ambient Air Temperature Sensor “A” has a general electrical failure).

Unified Diagnostic Services (UDS) expands the 2-byte DTC into a 3-byte DTC, in which the third byte indicates the failure “mode.” This failure mode is similar to the failure mode indicator (FMI) used in the J1939 protocol. For example, previously on OBDII, you could have the following five faults:

• P0070 Ambient Air Temperature Sensor Circuit
• P0071 Ambient Air Temperature Sensor Range/Performance
• P0072 Ambient Air Temperature Sensor Circuit Low Input
• P0073 Ambient Air Temperature Sensor Circuit High Input
• P0074 Ambient Air Temperature Sensor Circuit Intermittent

With WWH, these are all consolidated into one P0070 code, with 5 different failure modes indicated in the third byte of the DTC. For example, P0071 now becomes P0070-1C.

WWH also gives more information on the fault such as severity/class and the status. The severity will indicate how soon you need to have the fault checked, while the class of the fault will indicate which group the fault falls under according to GTR specifications. Additionally, the status of the fault will indicate whether it is pending, confirmed or if the test for this fault has been completed in the current driving cycle.

In summary, WWH-OBD expands on the current OBD II framework to give even more diagnostic information to the user.

Geotab supports WWH-OBD

Geotab has already implemented the WWH protocol into our firmware. Geotab employs a complex protocol detection system, in which we safely examine what is available on the vehicle to find out whether OBD-II or WWH is available (in some cases, both are available).

At Geotab, we are constantly improving our firmware to further enhance the information our customers obtain. We’ve already started to support 3-byte DTC information and are continuing to add more information about the faults generated in vehicles. When new information becomes available through either OBDII or WWH (such as a new PID or fault data), or if a new protocol is implemented on the vehicle, Geotab makes it a priority to quickly and accurately add it into the firmware. We then immediately send the new firmware to our units over the cloud so that our customers always achieve the greatest benefit from their devices.

Growth beyond OBDII

OBDII contains 10 standard modes to achieve the required diagnostic information for emission standards. The problem is that these 10 modes have not been enough.

Various UDS modes have been developed over the years since OBDII was implemented to enrich the available data. Each vehicle manufacturer uses their own proprietary PIDs (parameter IDs) and implements them via extra UDS modes. Information that was not required via OBDII data (such as odometer and seatbelt use) was made available via UDS modes instead.

The reality is that UDS contains upwards of 20 additional modes to the current 10 standard modes available via OBDII, meaning that UDS has more information available. But that’s where WWH-OBD comes in. It looks to incorporate the UDS modes with OBDII to enrich the data available for diagnostics, while continuing to keep a standardised process.

Conclusion

In the expanding world of IoT, the OBD port remains important to vehicle health, safety and sustainability. Although the number and variety of connected devices for vehicles increases, not all devices report and track the same information. Additionally, compatibility and security can vary among devices.

With the multitude of OBD protocols, not all telematics solutions are designed to work with all vehicle types that exist today. Good telematics solutions should be able to understand and translate a comprehensive set of vehicle diagnostic codes. Additionally, verifying the security of third-party devices connected to the OBDII port is extremely important.