You might have come across the terms “OBD” or “OBDII” when reading about connected vehicles and car diagnostics. These features are integral parts of modern car computer systems and have a history that’s more involved than many realize. In this article, we’ll provide a comprehensive overview of OBDII and explore its evolution.
What is 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 system allows technicians to access subsystem information to monitor performance and diagnose repair needs effectively.
OBD is the standard protocol predominantly used in light-duty vehicles to retrieve diagnostic information. This information is generated by Engine Control Units (ECUs), also known as engine control modules, within a vehicle. Think of ECUs as the computers or the ‘brain’ of your car.
Alt text: Close-up view of an OBDII port connector located beneath the dashboard of a vehicle, highlighting its typical placement in the driver’s side area.
Why is OBD2 So Important?
OBD is a critical component for vehicle owners, mechanics, and especially for telematics and fleet management. It provides essential data for assessing vehicle health and driving behavior.
Thanks to OBD2, fleets and individuals can:
- Track wear and tear trends, identifying vehicle parts that degrade faster than others.
- Instantly diagnose vehicle issues before they escalate, enabling proactive maintenance rather than reactive repairs.
- Measure driving behavior, including speed, idling time, and more, to improve efficiency and safety.
OBD vs. OBD2: Key Differences Explained
OBD2 is essentially the second generation of OBD, or OBD I. The original OBD I systems were often external add-ons to a car’s console, whereas OBD2 is integrated directly into the vehicle itself. OBD I was the standard until OBD2 was developed in the early 1990s, offering significant improvements in standardization and capabilities.
A Look into the History of OBD2
The history of on-board diagnostics dates back to the 1960s. Several organizations played a crucial role in establishing the standard we know today, 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, vehicle manufacturers developed their own proprietary systems. Each manufacturer’s tools, and sometimes even different models from the same manufacturer, had unique connector types and electronic interface requirements. They also used custom codes to report problems, making diagnostics complex and inefficient.
Alt text: Infographic timeline illustrating key milestones in OBD history from 1968 to 2008, highlighting Volkswagen’s first OBD system and the mandatory OBD-II implementation in the USA.
Key Milestones in OBD History
1968 — Volkswagen introduced the first computer-based OBD system with scanning capabilities.
1978 — Datsun launched a simple, non-standardized OBD system with limited capabilities.
1979 — The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and a set of diagnostic test signals.
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.
1988 — Standardization of on-board diagnostics began in the late 1980s following the SAE’s 1988 recommendation for a standard connector and set of diagnostics.
1991 — The state of California mandated that all vehicles have some form of basic on-board diagnostics, known as OBD I.
1994 — California required that all vehicles sold in the state from 1996 onwards must have OBD compliant with SAE recommendations, now termed OBDII, to facilitate widespread emissions testing. OBDII included a set of standardized Diagnostic Trouble Codes (DTCs).
1996 — OBD-II became mandatory for all cars manufactured in the United States.
2001 — EOBD (European version of OBD) became mandatory for all gasoline vehicles in the European Union.
2003 — EOBD became mandatory for all diesel vehicles in the EU.
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.
Where is the OBD2 Port Located?
In a typical passenger vehicle, the OBD2 port is usually located under 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 16-pin port is the most common type found in modern cars and is standardized for OBD2 systems.
Alt text: A mechanic is shown connecting an OBDII diagnostic scan tool to a vehicle’s OBDII port during a routine check-up in an auto repair shop.
What Data Can You Access from OBD2?
OBD2 provides access to both status information and Diagnostic Trouble Codes (DTCs) for:
- Powertrain (engine and transmission)
- Emission control systems
Additionally, the following vehicle information is accessible via OBD2:
- Vehicle Identification Number (VIN)
- Calibration Identification Number
- Ignition counter
- Emission control system counters
When you take your car to a service center, a mechanic can connect to the OBD port with a scan tool, read the fault codes, and pinpoint the problem. This capability allows mechanics to accurately diagnose malfunctions, quickly inspect vehicles, and address issues before they become severe problems.
Examples of OBD2 Data:
Mode 1 (Vehicle Information):
- PID 12 — Engine RPM
- PID 13 — Vehicle Speed
Mode 3 (Fault 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
OBD2 and Telematics Integration
The presence of OBD2 allows telematics devices to seamlessly process information such as engine RPM, vehicle speed, fault codes, fuel consumption, and much more. A telematics device can use this data 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 available. Geotab telematics overcomes this challenge by translating diagnostic codes from different makes and models, including electric vehicles.
With the OBD-II port, connecting a fleet tracking solution to your vehicle is quick and easy. For example, Geotab devices 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 any case, the installation process is generally fast and does not require special tools or professional installer 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, aiming for a more comprehensive diagnostic approach.
Advantages of WWH-OBD
Transitioning to WWH-OBD offers several technical advantages:
Access to More Data Types
Currently, OBDII PIDs (Parameter IDs) used in Mode 1 are only one byte, meaning only up to 255 unique data types are available. Expanding PIDs, applicable also to other OBD-II modes transitioned to WWH through UDS modes, allows for more data and future scalability. Adopting WWH standards makes more data accessible, providing opportunities for future expansion.
More Detailed Fault Information
Another benefit of WWH is the expanded information contained within a fault. Currently, OBDII uses a two-byte Diagnostic Trouble Code (DTC) to indicate when a fault has occurred (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, these are all consolidated into one code, P0070, with 5 different failure modes indicated in the third byte of the DTC. For example, P0071 now becomes P0070-1C.
WWH also provides more fault information, such as severity/class and status. Severity indicates how urgently the fault needs to be reviewed, while the fault class indicates which group the fault belongs to as per GTR specifications. Additionally, fault status indicates 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 the current OBDII framework to offer even more diagnostic insights to the user.
Geotab’s Support for WWH-OBD
Geotab has already implemented the WWH protocol in our firmware. Geotab employs a complex protocol detection system, securely examining what is available in the vehicle to determine if OBD-II or WWH is available (in some cases, both are).
At Geotab, we are continuously enhancing our firmware to 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 (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 send the new firmware to our devices over the cloud, ensuring our customers always benefit from the most comprehensive data from their devices.
Growing Beyond OBD2
OBDII contains 10 standard modes for accessing the diagnostic information required by emissions standards. However, these 10 modes have proven insufficient over time.
Since the implementation of OBDII, several UDS modes have been developed to enrich available data. Each vehicle manufacturer uses proprietary PIDs and implements them via additional UDS modes. Information not initially required via OBDII data (like odometer readings and seat belt usage) became available through UDS modes.
UDS includes more than 20 additional modes beyond the current 10 standard modes available through OBDII, meaning UDS offers a richer data set. WWH-OBD aims to incorporate UDS modes with OBDII to enhance the diagnostic data available while maintaining a standardized process.
Conclusion
In the growing world of IoT, the OBD port remains vital for vehicle health, safety, and sustainability. While the number and variety of connected devices for vehicles increase, not all devices provide and track the same information. Moreover, compatibility and security can vary across devices.
With the multitude of OBD protocols, it’s essential to choose telematics solutions that are capable of understanding and translating a comprehensive set of vehicle diagnostic codes. Good telematics solutions should be versatile and adaptable, ensuring they can provide valuable insights across a wide range of vehicle types and diagnostic systems.
