You may have come across the terms “OBD” or “OBDII” when reading about connected vehicles and devices like the Geotab GO. These features are integral parts of modern car computer systems and have a history that is perhaps less known. This article provides a detailed overview of OBDII and a timeline of its evolution.
Understanding OBD (On-Board Diagnostics)
On-Board Diagnostics (OBD) refers to the automotive electronic system that provides self-diagnosis and reporting capabilities for repair technicians. An OBD system allows technicians to access subsystem information to monitor vehicle performance and diagnose repair needs efficiently.
OBD is the standard protocol employed in most light-duty vehicles to retrieve diagnostic information. This information is generated by Engine Control Units (ECUs), often referred to as the ‘brain’ or computer of the vehicle.
The Importance of OBDII
OBDII is a critical component in telematics and fleet management, enabling the measurement and management of vehicle health and driving behavior.
Thanks to OBDII, fleet managers can:
- Track wear and tear trends: Identify vehicle parts that are wearing out faster than expected, allowing for predictive maintenance.
- Diagnose vehicle issues proactively: Instantaneously diagnose potential problems before they escalate, supporting a proactive rather than reactive maintenance approach.
- Measure driving behavior: Monitor speed, idling time, and other driving habits to optimize fuel efficiency and safety.
Locating the OBDII Port
In a typical passenger vehicle, the OBDII port is usually located under the dashboard on the driver’s side. Depending on the vehicle type, the port can have a 16-pin, 6-pin, or 9-pin configuration.
OBD vs. OBDII: Key Differences
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 integrated directly into the vehicle itself. The original OBD system was used until OBDII was developed in the early 1990s.
The Evolution of OBDII: A Historical Perspective
The history of on-board diagnostics dates back to the 1960s. Several organizations played a foundational role in establishing 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 developed their own proprietary systems. Diagnostic tools from each manufacturer, and sometimes even across different models from the same manufacturer, had unique connector types and electronic interface requirements. They also used custom codes to report issues, creating significant challenges for repair technicians.
Key Milestones in OBD History
1968 — Volkswagen introduces the first computer-based OBD system with scanning capabilities.
1978 — Datsun presents a simple OBD system with limited, non-standardized capabilities.
1979 — The Society of Automotive Engineers (SAE) recommends a standardized diagnostic connector and a set of diagnostic test signals.
1980 — GM introduces a proprietary interface and protocol capable of providing engine diagnostics via an RS-232 interface, or more simply, by flashing the check engine light.
1988 — Standardization of on-board diagnostics gains momentum in the late 1980s following the 1988 SAE recommendation, which called for a standard connector and set of diagnostics.
1991 — The state of California mandates that all vehicles must have some form of basic on-board diagnostics, known as OBD I.
1994 — California mandates that all vehicles sold in the state from 1996 onwards must have OBD as recommended by SAE, now termed OBDII, to facilitate widespread 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 (the European version of OBD) becomes mandatory for all gasoline vehicles in the European Union.
2003 — EOBD becomes mandatory for all diesel vehicles in the EU.
2008 — Starting in 2008, all vehicles in the United States are required to implement OBDII via a Controller Area Network, as specified in ISO standard 15765-4.
Data Accessibility via OBDII
OBDII provides access to both status information and Diagnostic Trouble Codes (DTCs) for:
- Powertrain (Engine and Transmission): Monitors the performance and health of the engine and transmission systems.
- Emission Control Systems: Tracks the efficiency and functionality of systems designed to reduce vehicle emissions.
In addition, the following vehicle information can be accessed through OBDII:
- Vehicle Identification Number (VIN): A unique identifier for the vehicle.
- Calibration Identification Number: Identifies the software calibration version used by the ECU.
- Ignition Counter: Tracks the number of engine start cycles.
- Emission Control System Counters: Provides data related to the performance and testing of emission control components.
When a car is taken to a service center, a mechanic can connect a scan tool to the OBD port to read fault codes and pinpoint problems. This capability allows mechanics to accurately diagnose issues, quickly inspect vehicles, and address malfunctions before they become critical problems.
Examples of OBDII Data:
Mode 1 (Vehicle Information):
- PID 12 — Engine RPM: Revolutions Per Minute of the engine.
- PID 13 — Vehicle Speed: The current speed of the vehicle.
Mode 3 (Fault Codes: P= Powertrain, C= Chassis, B= Body, U= Network):
- P0201 — Injector Circuit Malfunction – Cylinder 1: Indicates an issue with the fuel injector circuit in cylinder 1.
- P0217 — Engine Overtemperature Condition: Signals that the engine is running too hot.
- P0219 — Engine Overspeed Condition: Indicates that the engine is exceeding its maximum safe RPM.
- C0128 — Brake Fluid Low Circuit: Alerts to a low brake fluid level condition.
- C0710 — Steering Position Malfunction: Indicates a problem with the steering position sensor.
- B1671 — Battery Module Voltage Out of Range: Signals that the battery module voltage is outside the acceptable range.
- U2021 — Invalid/Faulty Data Received: Indicates corrupted or invalid data received over the vehicle network.
OBDII and Telematics Integration
The presence of OBDII enables telematics devices to seamlessly process information such as engine RPM, vehicle speed, fault codes, fuel consumption, and much more. A telematics device utilizes this data to determine trip start and end times, instances of over-revving, speeding, excessive idling, fuel usage, etc. All this information is then uploaded to a software interface, allowing 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 across various makes and models, including electric vehicles.
With the OBD-II port, integrating a fleet tracking solution into your vehicle is quick and straightforward. For example, Geotab devices can be set up in under five minutes.
For vehicles or trucks without a standard OBDII port, an adapter can be used. In any case, the installation process is generally fast and does not require specialized tools or professional installation assistance.
What is WWH-OBD?
WWH-OBD stands for World Wide Harmonized On-Board Diagnostics. It is an international standard for vehicle diagnostics implemented 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.
Advantages of WWH-OBD
Transitioning to WWH-OBD offers several technical advantages:
Expanded 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. The expansion of PIDs could also be applied to other OBD-II modes transitioned to WWH through UDS modes. Adopting WWH standards allows for more extensive data and provides room for future expansion.
More Detailed Fault Information
Another advantage of WWH-OBD is the expanded information contained within a fault code. Currently, OBDII uses a two-byte Diagnostic Trouble Code (DTC) to indicate when a fault has occurred (e.g., P0070 indicates a general electrical fault with the ambient air temperature sensor “A”).
Unified Diagnostic Services (UDS) expands the two-byte DTC into a three-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 separate fault codes:
- 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 consolidated under a single code P0070, with 5 different failure modes indicated in the third byte of the DTC. For instance, P0071 now becomes P0070-1C.
WWH-OBD also offers more fault information, such as severity/class and status. Severity indicates how urgently the fault needs attention, while the fault class categorizes the fault according to GTR specifications. Additionally, fault status indicates whether the fault is pending, confirmed, or if the test for this fault has been completed in the current driving cycle.
In summary, WWH-OBD extends the current OBDII framework to provide even richer diagnostic information to the user.
Geotab’s Compatibility with WWH-OBD
Geotab has already implemented the WWH protocol in our firmware. Geotab employs a sophisticated protocol detection system that securely examines what is available in the vehicle to determine whether OBD-II or WWH-OBD (and in some cases, both) are supported.
At Geotab, we are continuously enhancing our firmware to expand the information available to our customers. We have already begun supporting three-byte DTC information and continue to add more detail about vehicle-generated faults. When new information becomes available through OBDII or WWH-OBD (such as new PIDs or fault data), or if a new protocol is implemented in vehicles, Geotab prioritizes quickly and accurately adding it to our firmware. We then immediately deploy the updated firmware to our devices over-the-air, ensuring our customers always benefit from the most comprehensive data available.
Growing Beyond OBDII Limitations
OBDII includes 10 standard modes for accessing the diagnostic information required by emissions standards. However, these 10 modes have proven to be insufficient for the expanding data needs of modern vehicles.
Over the years since OBDII’s implementation, several UDS modes have been developed to enrich the available data. Each vehicle manufacturer uses proprietary PIDs and implements them using additional UDS modes. Information not essential for OBDII emissions data (such as odometer readings and seat belt usage) became accessible through these UDS modes.
UDS actually contains more than 20 additional modes beyond the 10 standard modes available through OBDII, meaning UDS has access to a significantly greater range of information. This is where WWH-OBD comes in, aiming to incorporate UDS modes with OBDII to enrich diagnostic data while maintaining a standardized process.
Conclusion
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 significantly from one device to another.
Given the diversity of OBD protocols, it’s essential to recognize that not all telematics solutions are equipped to function with every vehicle type. Effective telematics solutions must be capable of understanding and translating a comprehensive set of vehicle diagnostic codes to provide reliable and actionable insights.
