What is OBD II? History of on-board diagnostics
A quick overview of OBD II (on-board diagnostics), how the standard was established and what vehicle information can be accessed from the port.
You may have seen OBD or OBD II mentioned when reading about connected vehicles and the Geotab GO device. Read this post for an overview of OBD II and a timeline of developments.
History of GPS satellites and commercial GPS tracking
The Geotab GO saved my RV vacation
What is an OBD (On-Board Diagnostics)?
OBD is an abbreviation of On-Board Diagnostics and refers to the automotive electronic system that provides vehicle self-diagnosis and reporting capabilities for repair technicians to access subsystem information for the purpose of performance monitoring and repair.
OBD (On-Board Diagnostics) is the standard protocol used across most light-duty vehicles to retrieve vehicle diagnostic information. Information is generated by the engine control unit (ECU or also called engine control module) within a vehicle. It’s like the vehicle’s brain or computer.
Where is the OBD II port located?
The OBD II port is located inside the vehicle. In a typical passenger vehicle, you can find the OBD II 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.
If you want to know how to connect your Geotab GO device to your on-board diagnostics port, you can start by reading this post on device installation.
History of OBD II
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).
The following is a short timeline of the major milestones in the development of OBD.
Origins of OBD
The first OBD computer system with scanning capability was introduced by Volkswagen in 1968. Ten years later Datsun introduced a simple OBD system with limited non standardized capabilities.
In 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. Other manufacturers were introducing their own versions of on board diagnostics.
It’s important to note that before standardization, manufacturers were creating their own systems. The tools from each manufacturer (and sometimes in between models of the same manufacturer) had their own connector type, electronic interface requirements, and they used their own custom codes for reporting problems.
OBD I and II standards
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 — Three years later, California mandated that all vehicles sold in the state starting in 1996 must have OBD as recommended by SAE — now referred to as OBD II. This stems from the desire to perform across the board emissions testing. OBD II included a series of standardized diagnostic trouble codes (DTCs), some examples being
1996 — OBD-II becomes mandatory for all cars manufactured or sold in the United States.
OBD around the world
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 OBD-II through a Controller Area Network as specified by ISO 15765-4.
What data as accessible from the OBD II?
The OBD II 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
There are trouble codes covering different areas of the vehicle, such as the powertrain (e.g. engine, transmission, and emissions), body (lighting), chassis (antilock brakes), and network (CAN BUS). If you look up a list of all the standard diagnostic trouble codes, you will find pages and pages of codes for all the issues that could occur.
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.
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 GPS fleet tracking
The presence of the OBD II allows GPS fleet tracking (telematics) devices to silently collect information such as engine revolutions, vehicle speed, fault codes, fuel usage. The telematics device can the 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 OBD-II port, a fleet tracking solution can be connected to your vehicle quickly and easily. This is often referred to a plug and play installation. In the case of Geotab, it can be set up in under five minutes.
If your vehicle or truck doesn’t have a standard OBD II, and adapter can be used instead. Either way, the installation process is quick and doesn’t require any specials tools or the assistance of a professional installer.
Why OBD is important
The OBD is what makes telematics and fleet solutions possible. Without it, there would be no way to send all of the valuable data that your car collects. It’s because of the OBD that you can:
- Track wear trends and see what vehicle parts are wearing out faster than others.
- Instantly diagnose vehicle problems before they occur. Allowing you to become proactive rather than reactive.
- Measure driving behavior, speed, idling time, and more.
In the expanding world of IoT, the number of connected devices for vehicles is increasing. It’s important to understand the difference between telematics devices. Not all devices report and track the same information. And compatibility and security can vary among devices.
Find out how to choose the right GPS vehicle tracking device in this article: Not All OBD Plug-In Fleet Management Devices Are Made Equal
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.
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.
Growth beyond the OBD-II
OBD II contains 10 standard modes to achieve the required diagnostic information for emission standards.
The problem is that these 10 modes haven’t been enough. What are called Unified Diagnostic Services (UDS), these have been developed over the years since OBD-II was implemented to enrich the data available. Each vehicle manufacturer uses their own proprietary PIDs (parameter IDs) and implemented them via extra UDS modes. Information that was not required via OBD-II data (such as odometer and seatbelt use) was made available via UDS modes instead.
The reality is that UDS contain upwards of 20+ additional modes to the current 10 standard modes available via OBD-II. In the end, UDS has more information available.
That’s where WWH-OBD comes in. It looks to incorporate the UDS modes with OBD-II to enrich the data available for diagnostics, while continuing to keep a standardized process.
Advantages of WWH-OBD
Here’s a look at the benefits of moving toward WWH in more technical terms:
1. Access to more data types
- Currently, the OBD-II PIDs used in Mode 1 are only 1 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.
So in other words, WWH will allow for more available data and provides the possibility of future expansion.
2. More detailed fault data
Another advantage with WWH is the expansion of information contained in a fault. Currently, OBD-II uses a 2-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).
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 OBD-II, you could have the following 5 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
Now with WWH, these are all consolidate to 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 us 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.
- The class of the fault will indicate which group the fault falls under according to GTR specifications.
- The status of the fault will indicate things such as if 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 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 there (and 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 OBD II 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.
More information on standards
- All information regarding UDS modes is defined in the ISO-14229-1 standard.
- The implementation of WWH is defined in the ISO-27145 standards.
- The definition of the standard PIDs used for OBD-II and WWH are defined in the latest J1979 documentation while the standardized faults for OBD-II and WWH are defined in the latest J2012 documentation.
Security recommendations for OBD
Verifying the security of any third-party devices connected to the OBD II port is extremely important. To learn more about cybersecurity best practices in telematics for fleet tracking, read these 15 Security Recommendations.
Engine diagnostics or GPS only tracking: Which is better?
Diagnostics with Geotab: From port to report
Immobilization, driver identification, and safety
Originally published Aug 19, 2017. Updated May 25, 2018.
If you liked this post, let us know!
Victor Barreto is a Senior Embedded Systems Engineer, Team Lead for Geotab.
Geotab's blog posts are intended to provide information and encourage discussion on topics of interest to the telematics community at large. Geotab is not providing technical, professional or legal advice through these blog posts. While every effort has been made to ensure the information in this blog post is timely and accurate, errors and omissions may occur, and the information presented here may become out-of-date with the passage of time.
Geotab | Blog
Sign up for monthly news and tips from our award-winning fleet management blog. You can unsubscribe at any time.
Other posts you might like
Are connected car regulations up to date?
An open system for vehicle data will help protect innovation and competition.
August 31, 2020
What you need to know about the FBI notification on electronic logging
Learn about ELD cybersecurity and how to manage risk.
August 7, 2020