You may have come across the terms “OBD” or “OBDII” when reading about connected vehicles and telematics devices. These functionalities are integral parts of your car’s on-board computer and possess a history that is perhaps less known. In this article, we provide a detailed overview of OBDII and a timeline of its evolution, with a focus on OBD2 connector location.
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.
OBD is the standard protocol used 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 car’s computers or brain.
Alt: OBD2 port location under the dashboard of a car, driver’s side.
Why is OBD So Important?
OBD is a critical component in telematics and fleet management, as it enables the measurement and management of vehicle health and driving behavior.
Thanks to OBD, fleets can:
- Track wear and tear trends to identify vehicle parts that degrade faster than others.
- Instantly diagnose vehicle issues before they escalate, supporting proactive rather than reactive maintenance.
- Measure driving behavior, speed, idling time, and much more.
Where is the OBDII Port Located?
In a typical passenger vehicle, the OBD2 connector location is usually found on the underside of 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. Finding the OBDII port is generally straightforward, as it is designed for easy access.
Alt: Locating the OBD2 port under the car dashboard, driver’s side, for vehicle diagnostics.
What is the Difference Between OBD and OBDII?
OBDII is simply the second generation of OBD, or OBD I. OBD I was initially connected externally to a car’s console, whereas OBDII is now integrated within the vehicle itself. The original OBD was used until OBDII was developed in the early 1990s. The key improvement in OBDII was standardization, making diagnostic processes more uniform across different car manufacturers.
History 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 before standardization, manufacturers created their own systems. Each manufacturer’s tools (and sometimes even models from the same manufacturer) had their own connector types and electronic interface requirements. They also used 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 scan capability. This was a pioneering step towards modern vehicle diagnostics.
1978 — Datsun introduced a simple OBD system with limited, non-standardized capabilities. Early OBD systems were manufacturer-specific and lacked universal protocols.
1979 — The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and 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 through an RS-232 interface or, more simply, by flashing the check engine light. The “check engine light” became a common indicator for vehicle issues.
1988 — Standardization of on-board diagnostics arrived in the late 1980s following the SAE’s 1988 recommendation, which called for a standard connector and diagnostic set. This marked a significant shift towards uniform diagnostic practices.
1991 — The state of California mandated that all vehicles have some form of basic on-board diagnostics. This became known as OBD I. California’s regulations often lead the way in automotive emission standards and diagnostics.
1994 — The state of California 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). Standardized DTCs were a major improvement, allowing technicians to understand fault codes across different vehicles.
1996 — OBD-II became mandatory for all cars manufactured in the United States. This was a pivotal moment, making OBDII a standard feature in all US vehicles.
2001 — EOBD (the European version of OBD) became mandatory for all gasoline vehicles in the European Union. OBD standardization expanded globally to meet environmental and diagnostic needs.
2003 — EOBD became mandatory for all diesel vehicles in the EU. The mandate extended to diesel vehicles, ensuring comprehensive diagnostic coverage across vehicle types.
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. CAN bus integration improved data communication speed and reliability in OBDII systems.
What Data Can Be Accessed From OBDII?
OBDII provides access to status information and Diagnostic Trouble Codes (DTCs) for:
- Powertrain (engine and transmission)
- Emission control systems
In addition, the following vehicle information can be accessed via OBDII:
- Vehicle Identification Number (VIN)
- Calibration Identification number
- Ignition counter
- Emission control system counters
When you take your car to a service shop, a mechanic can connect to the OBD port with a scan tool, read the fault codes, and pinpoint the problem. This means mechanics can accurately diagnose faults, inspect vehicles quickly, and fix any issues before they become major problems. The OBDII port streamlines the diagnostic process, saving time and improving repair accuracy.
Examples:
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
OBD and Telematics
The presence of OBDII allows telematics devices to silently process information such as engine RPM, vehicle speed, fault codes, fuel consumption, and much more. The telematics device can use this information to determine trip start and end, over-revving, speeding, excessive idling, fuel consumption, etc. All this information is uploaded to a software interface and allows fleet management teams to monitor vehicle usage and performance. Telematics leverages OBDII data to provide valuable insights for fleet optimization and vehicle management.
With 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. Compatibility across various vehicle types is a key feature of advanced telematics systems.
With the OBD-II port, you can quickly and easily connect a fleet tracking solution to your vehicle. In the case of Geotab, it can be set up in under five minutes. The ease of installation makes OBDII-based telematics solutions highly practical for fleet deployment.
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 quick and does not require any special tools or help from a professional installer. Adapters ensure that even vehicles without standard OBDII ports can benefit from telematics technology.
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 Regulation (GTR) mandate, which includes monitoring vehicle data, such as emission output and engine fault codes. WWH-OBD represents the next evolution in standardized vehicle diagnostics.
Advantages of WWH-OBD
Below are the advantages of moving to WWH in more technical terms:
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. The expansion of PIDs could also be applied to other OBD-II modes that have been transitioned to WWH via UDS modes. Adopting WWH standards allows for more data and offers the potential for future expansion. Expanded data capabilities are crucial for more detailed vehicle monitoring and diagnostics.
More Detailed Fault Data
Another advantage of WWH is the expansion of the information contained in a fault. Currently, OBDII uses a 2-byte Diagnostic Trouble Code (DTC) to indicate when a fault has occurred (e.g., P0070 indicates that the ambient air temperature sensor “A” has a general electrical fault).
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 could 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. More granular fault codes in WWH-OBD allow for more precise diagnosis and repair strategies.
WWH also offers more information on the fault, such as severity/class and status. Severity will indicate how quickly the fault should be reviewed, while the fault class will indicate which group the fault belongs to per GTR specifications. Additionally, the fault status will indicate if it is pending, confirmed, or if the test for this fault has been completed in the current driving cycle. Enhanced fault information provides technicians with a more complete picture for effective troubleshooting.
In summary, WWH-OBD expands upon the current OBDII framework to offer even more diagnostic information to the user.
Geotab Supports WWH-OBD
Geotab has already implemented the WWH protocol in our firmware. Geotab employs a complex protocol detection system, where we safely probe what is available in the vehicle, to find out if OBD-II or WWH is available (in some cases, both are). Proactive support for WWH-OBD ensures Geotab remains at the forefront of telematics technology.
At Geotab, we are constantly improving our firmware to further expand the information that our customers obtain. We have already begun supporting 3-byte DTC information and continue to add more fault information being generated in vehicles. When new information becomes available via OBDII or WWH (such as a new PID or fault data), or if a new protocol is implemented in the vehicle, Geotab prioritizes quickly and accurately adding it to the firmware. We then immediately push the new firmware to our units over the cloud so our customers always get the most benefit from their devices. Over-the-air firmware updates ensure Geotab users always have access to the latest diagnostic data and features.
Growth Beyond OBDII
OBDII contains 10 standard modes for obtaining the diagnostic information required by emissions regulations. The problem is that these 10 modes have not been sufficient.
Over the years since OBDII implementation, several UDS modes have been developed to enrich the available data. Each vehicle manufacturer uses their own PIDs and implements them via additional UDS modes. Information that was not required via OBDII data (like odometer and seat belt usage) became available via UDS modes. UDS modes expand the diagnostic capabilities beyond the original OBDII standards.
The reality is that UDS contains more than 20 additional modes, on top of the current 10 standard modes available via OBDII, meaning UDS has more information available. But that is where WWH-OBD comes in, seeking to incorporate UDS modes with OBDII to enrich the data available for diagnostics, while still maintaining a standardized process. WWH-OBD aims to combine the benefits of UDS with the standardization of OBDII for a more comprehensive diagnostic approach.
Conclusion
In the growing world of IoT, the OBD port remains important for vehicle health, safety, and sustainability. While the number and variety of connected devices for vehicles are increasing, not all devices give and track the same information. Furthermore, compatibility and security can vary from device to device. The OBD port is a foundational element in the automotive IoT ecosystem.
With the multitude of OBD protocols, not all telematics solutions are designed to work with every type of vehicle currently on the road. Good telematics solutions should be able to understand and translate a comprehensive set of vehicle diagnostic codes. Choosing a robust telematics solution ensures broad vehicle compatibility and reliable diagnostic data interpretation.
