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.

See also:

History of GPS satellites and commercial GPS tracking

The Geotab GO saved my RV vacation

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 analyzing 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 behavior, 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

Diagram showing where the OBDII is located inside a vehicle

If you want to connect a Geotab GO device to your on-board diagnostics port, you can start by reading How to install a Geotab GO vehicle tracking device.

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.

To learn more about the value of the OBD port, read this white paper: Preserving privacy and security in the connected vehicle: The OBD port on the road ahead.

History of OBDII

The history of on-board diagnostics goes back to the 1960s. Several organizations set the groundwork for the standard, including the California Air Resources Board (CARB), the Society of Automotive Engineers (SAE), the International Organization for Standardization (ISO) and the Environmental Protection Agency (EPA).

It’s important to note that before standardization, 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-standardized capabilities.

1979 — The Society of Automotive Engineers (SAE) recommends a standardized 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 — Standardization 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 standardized 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 gasoline 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

A man extracting vehicle data from an OBDII port

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

To discover even more codes, you can refer to this list of standard diagnostic trouble codes.

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.

See also: Data normalization and why it matters

With the OBD-II port, a fleet tracking solution can be connected to your vehicle quickly and easily. In the case of Geotab, it can be set up in under five minutes.

If your vehicle or truck doesn’t have a standard OBDII port, an adapter 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 World Wide Harmonized 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 achieve the greatest benefit from their devices at all times.

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 standardized process.

Conclusion

In the expanding world of IoT, the OBD port still 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.

To find out how to choose a GPS vehicle tracking device, read: Not All OBD Plug-In Fleet Management Devices Are Made Equal.

Additionally, verifying the security of third-party devices connected to the OBDII port is extremely important. To learn more about cybersecurity best practices in telematics for fleet tracking, read these 15 security recommendations.