You might have come across the terms “OBD” or “OBDII” when reading about connected vehicles and devices like Geotab GO. These functionalities are integral parts of your car’s onboard computers and have a history that is perhaps not widely known. In this article, we’ll provide a comprehensive overview of OBDII and a timeline of its development.
Decoding OBD: On-Board Diagnostics Explained
On-Board Diagnostics (OBD) refers to the automotive electronic system that offers vehicle self-diagnosis and reporting capabilities for repair technicians. An OBD system allows technicians to access subsystem information to monitor vehicle performance and analyze repair needs.
OBD is the standard protocol employed in most light-duty vehicles to retrieve vehicle diagnostic information. This information is generated by Engine Control Units (ECUs), or engine control modules, within a vehicle. Think of them as the computers or the ‘brain’ of your car.
Why is OBD2 So Important?
OBD is a critical component in telematics and fleet management because it enables the measurement and management of vehicle health and driving behavior.
Thanks to OBD, fleets are empowered to:
- Track wear and tear trends and identify vehicle parts that are wearing out faster than others.
- Instantly diagnose vehicle issues before they escalate, supporting proactive rather than reactive maintenance management.
- Measure driving behavior, including speed, idling time, and much more.
Locating the OBDII Port in Your Vehicle
In a typical passenger vehicle, the OBDII port is usually located beneath the dashboard on the driver’s side of the car. Depending on the vehicle type, the port may have a 16-pin, 6-pin, or 9-pin configuration. The most common and standardized port is the 16-pin connector, which is mandated for OBDII systems.
OBD vs. OBDII: Understanding the Key Difference
Simply put, OBDII is the second generation of OBD, or OBD I. OBD I was initially connected externally to a car’s console, whereas OBDII is now integrated directly within the vehicle itself. The original OBD system was in use until OBDII was developed in the early 1990s.
The transition to OBDII marked a significant leap in standardization and the amount of diagnostic data available. OBD-II provided a more comprehensive and standardized approach to vehicle diagnostics compared to the varied and often proprietary OBD-I systems.
The Historical Journey of OBDII
The history of on-board diagnostics dates back to the 1960s. Several organizations laid 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 prior to standardization, vehicle manufacturers created their own proprietary systems. Each manufacturer’s tools (and sometimes even different models from the same manufacturer) had their own connector types and electronic interface requirements. They also utilized their own custom codes to report problems. This lack of uniformity made vehicle diagnostics complex and inefficient.
Key Milestones in OBD History
1968 — Volkswagen introduced the first computer-based OBD system with scanning capability. This pioneering system marked the beginning of computerized vehicle diagnostics.
1978 — Datsun presented a simple OBD system with limited, non-standardized capabilities. This system, though basic, demonstrated the growing interest in on-board diagnostics.
1979 — The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and a set of diagnostic test signals. This recommendation was a crucial step towards OBD standardization.
1980 — GM introduced a proprietary interface and protocol capable of providing engine diagnostics via an RS-232 interface or, more simply, by flashing the check engine light. This system represented a significant advancement in accessible engine diagnostics.
1988 — Standardization of on-board diagnostics began in the late 1980s following the SAE’s 1988 recommendation, which called for a standard connector and diagnostic set. This was a pivotal moment in the push for OBD standardization.
1991 — The state of California mandated that all vehicles have some form of basic on-board diagnostics. This mandate is known as OBD I and marked the first regulatory push for OBD systems.
1994 — California Air Resources Board (CARB) mandated that all vehicles sold in the state from 1996 onwards must have OBD as recommended by SAE, now termed OBDII, to enable widespread emissions testing. OBDII included a set of standardized Diagnostic Trouble Codes (DTCs). This regulation was a major driver for the adoption of OBDII.
1996 — OBD-II became mandatory for all cars manufactured in the United States. This federal mandate ensured nationwide standardization of OBDII systems.
2001 — EOBD (the European version of OBD) became mandatory for all gasoline vehicles in the European Union. This expanded the reach of standardized on-board diagnostics to Europe.
2003 — EOBD became mandatory for all diesel vehicles in the EU. This further broadened the scope of EOBD across different engine types in Europe.
2008 — Starting in 2008, all vehicles in the United States were required to implement OBDII via a Controller Area Network, as specified in ISO standard 15765-4. This update incorporated CAN bus technology into OBDII, increasing data transfer speeds and capabilities.
What Data Can You Access Through OBDII?
OBDII provides access to both status information and Diagnostic Trouble Codes (DTCs) for:
- Powertrain (engine and transmission)
- Emission control systems
In addition, the following vehicle information is also accessible via OBDII:
- Vehicle Identification Number (VIN)
- Calibration Identification Number
- Ignition counter
- Emission control system counters
When you take your car to a service center for a check-up, a mechanic can connect to the OBD port with a scan tool, read the fault codes, and pinpoint the problem. This capability means mechanics can accurately diagnose malfunctions, quickly inspect vehicles, and fix any issues before they escalate into serious problems.
Examples of OBDII Data:
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 Overtemperature Condition
- P0219 — Engine Overspeed Condition
- C0128 — Brake Fluid Low Circuit
- C0710 — Steering Position Malfunction
- B1671 — Battery Module Voltage Out of Range
- U2021 — Invalid/Faulty Data Received
OBD and Telematics: A Powerful Combination
The presence of OBDII allows telematics devices to seamlessly process information such as engine RPM, vehicle speed, fault codes, fuel consumption, and much more. The telematics device can utilize this information to determine trip start and end times, over-revving, speeding, excessive idling, fuel usage, etc. All this information is then uploaded to a software interface, enabling fleet management teams to monitor vehicle usage and performance effectively.
Given the multitude of OBD protocols, not all telematics solutions are designed to work with every type of vehicle currently on the road. Geotab telematics overcomes this challenge by translating diagnostic codes from different makes and models, and even electric vehicles.
With the OBD-II port, connecting a fleet tracking solution to your vehicle is quick and straightforward. In the case of Geotab, it can be set up in under five minutes.
If your vehicle or truck does not have a standard OBDII port, an adapter can be used instead. In either case, the installation process is rapid and does not require any special tools or the assistance of a professional installer.
What is WWH-OBD? Expanding Diagnostic Capabilities
WWH-OBD stands for World Wide Harmonized On-Board Diagnostics. It is an international standard for vehicle diagnostics, established by the United Nations as part of the Global Technical Regulation (GTR) mandate. WWH-OBD includes monitoring vehicle data such as emissions output and engine fault codes, aiming for a globally unified diagnostic approach.
Advantages of WWH-OBD: Stepping into the Future of Diagnostics
Transitioning to WWH-OBD offers several technical advantages, notably:
Enhanced Data Access
Currently, OBDII Parameter IDs (PIDs) used in Mode 1 are limited to one byte, meaning only up to 255 unique data types are available. WWH-OBD expands PIDs, potentially also applying this expansion to other OBD-II modes transitioned to WWH through UDS modes. Adopting WWH standards allows for more data and offers scalability for future diagnostic needs.
More Granular Fault Data
Another key benefit of WWH is the enhanced information embedded within a fault. Currently, OBDII uses a 2-byte Diagnostic Trouble Code (DTC) to indicate a fault occurrence (e.g., P0070 indicates “Ambient Air Temperature Sensor ‘A’ Circuit Malfunction”).
Unified Diagnostic Services (UDS) expands the 2-byte DTC into a 3-byte DTC, where 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 in OBDII, you might 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-OBD, these are all consolidated into a single code P0070, with 5 different failure modes indicated in the third byte of the DTC. For example, P0071 now becomes P0070-1C.
WWH-OBD also provides additional fault information such as severity/class and status. Severity indicates the urgency for addressing the fault, while the fault class indicates the fault’s group according to GTR specifications. Furthermore, the fault status indicates 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 the current OBDII framework to offer even richer diagnostic information to the user.
Geotab’s Commitment to WWH-OBD
Geotab has already implemented the WWH protocol in our firmware. Geotab employs a sophisticated protocol detection system, where we safely examine what is available on the vehicle to determine if OBD-II or WWH-OBD is available (in some cases, both are).
At Geotab, we are continuously enhancing our firmware to further expand the information our customers receive. We have already begun supporting 3-byte DTC information and continue to add more fault information generated in vehicles. When new information becomes available through OBDII or WWH-OBD (such as a new PID or fault data), or if a new protocol is implemented in vehicles, Geotab prioritizes quickly and accurately adding it to the firmware. We then immediately push the new firmware to our devices over-the-air, ensuring our customers always benefit from the most comprehensive data from their devices.
Growing Beyond OBDII: Embracing UDS and WWH-OBD
OBDII contains 10 standard modes for accessing the diagnostic information required by emissions standards. However, these 10 modes have proven insufficient for the expanding diagnostic needs of modern vehicles.
Over the years since OBDII implementation, several UDS modes have been developed to enrich available data. Each vehicle manufacturer uses their own PIDs and implements them using additional UDS modes. Information not required through OBDII data (such as odometer readings and seat belt usage) became available through UDS modes.
UDS contains more than 20 additional modes beyond the current 10 standard modes available through OBDII, meaning UDS offers a wealth of additional information. This is where WWH-OBD steps in, aiming to incorporate UDS modes with OBDII to enhance available diagnostic data while maintaining a standardized process.
Conclusion: The Enduring Importance of OBD2
In the ever-expanding world of IoT, the OBD port remains crucial for vehicle health, safety, and sustainability. While the number and variety of connected devices for vehicles are increasing, not all devices provide and track the same information. Furthermore, compatibility and security can vary from device to device.
Given the multitude of OBD protocols, not all telematics solutions are designed to function with every type of vehicle currently available. Effective telematics solutions must be capable of understanding and translating a comprehensive set of vehicle diagnostic codes, ensuring broad compatibility and reliable data acquisition. OBD2, and its evolution through WWH-OBD, continues to be a cornerstone of vehicle diagnostics and connected car technology.
