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.
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.
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.
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.
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.
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.
The OBD II provides access to status information and Diagnostic Trouble Codes (DTCs) for:
Additionally, you can access the following vehicle Information via the OBD-II:
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):
Mode 3 (Trouble Codes: P = Powertrain, C = Chassis, B = Body, U = Network):
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.
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:
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.
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.
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.
Here’s a look at the benefits of moving toward WWH in more technical terms:
1. Access to More Data Types
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:
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:
In summary, WWH-OBD expands on current OBD-II framework to give even more diagnostic information to the user.
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.
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!