You might 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’s not widely known. This article provides a comprehensive overview of OBDII and a timeline of its development, with a special focus on the OBD2 port and its significance in vehicle diagnostics and telematics.
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 information from various vehicle subsystems to monitor performance and diagnose repair needs.
OBD is the standard protocol used in most light-duty vehicles to retrieve diagnostic information. This data is generated by the Engine Control Units (ECUs), often referred to as the “brain” or computer of the vehicle. These ECUs monitor and control various aspects of the car’s operation, and the OBD system provides a standardized way to access this information.
Why is OBD Important?
OBD is a crucial component in telematics and fleet management because it enables the measurement and management of vehicle health and driving behavior. The data accessed through the OBD2 port is invaluable for various applications.
Thanks to OBD, fleets can:
- Track wear and tear trends to identify vehicle parts that are wearing out faster than expected.
- Instantly diagnose vehicle problems before they escalate, facilitating proactive rather than reactive maintenance.
- Measure driving behavior, including speed, idling time, and much more, to improve efficiency and safety.
Where is the OBD2 Port Located?
In a typical passenger vehicle, the OBD2 port is usually located 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. The 16-pin connector is the most common type for OBDII in passenger vehicles and is standardized for easy access and diagnostic procedures.
Alt text: Locating the OBD2 port beneath the car dashboard on the driver’s side, a standard access point for vehicle diagnostics.
OBD vs. OBD2: Understanding the Difference
Simply put, OBDII is the second generation of OBD, or OBD I. The original OBD was often connected externally to a car’s console, whereas OBDII is integrated directly into the vehicle itself. OBD I was utilized until OBDII was developed in the early 1990s.
The key difference lies in standardization and capability. OBD-I systems were manufacturer-specific, lacking uniformity in diagnostic codes and connector types. OBD-II brought standardization in both the connector, the diagnostic trouble codes (DTCs), and the communication protocols. This standardization made vehicle diagnostics more accessible and efficient for technicians. The OBD2 port is the physical manifestation of this standardized system, allowing any compliant scan tool to interface with any OBDII compliant vehicle.
A Brief History of OBD2 Development
The history of on-board diagnostics dates back to the 1960s. Several organizations played a foundational role in establishing the standards, 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 crucial 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 issues. This lack of standardization made vehicle diagnostics complex and costly.
Key Milestones in OBD History
1968 — Volkswagen introduced the first computer-based OBD system with scanning capabilities. This marked an early step towards electronic vehicle diagnostics.
1978 — Datsun (now Nissan) presented a simple OBD system with limited, non-standardized capabilities. This was another early attempt, albeit proprietary, at on-board diagnostics.
1979 — The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and a set of diagnostic test signals. This was a significant move towards standardization in the automotive industry.
1980 — General Motors (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. This showed a growing recognition of the need for accessible diagnostic information.
1988 — Standardization of on-board diagnostics gained momentum in the late 1980s following the 1988 SAE recommendation that called for a standard connector and set of diagnostics. This set the stage for mandatory OBD systems.
1991 — The state of California mandated that all vehicles have some form of basic on-board diagnostics. This is known as OBD I, and it was the first regulatory push for standardized vehicle diagnostics.
1994 — 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). This was a pivotal moment, making OBDII a requirement for emissions compliance.
1996 — OBD-II became mandatory for all cars manufactured in the United States. This federal mandate solidified OBDII as the standard for vehicle diagnostics in the US market.
2001 — EOBD (European version of OBD) became mandatory for all gasoline vehicles in the European Union. Europe followed suit in standardizing on-board diagnostics for emissions control.
2003 — EOBD became mandatory for all diesel vehicles in the EU. Expanding the mandate to diesel vehicles further strengthened the role of standardized diagnostics 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 advanced the communication protocol for OBDII systems to CAN, improving data transfer rates and reliability.
Data You Can Access Through the OBD2 Port
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 can be accessed via the OBD2 port:
- Vehicle Identification Number (VIN)
- Calibration Identification number
- Ignition counter
- Emission control system counters
When you take your car to a service center for maintenance, a mechanic can connect to the OBD2 port with a scan tool, read the fault codes, and pinpoint the problem. This means mechanics can accurately diagnose malfunctions, quickly inspect the vehicle, and address any issues before they become major problems. The OBD2 port is therefore an essential tool for efficient vehicle repair and maintenance.
Examples of data accessible through the OBD2 port:
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 Overtemp Condition
- P0219 — Engine Overspeed Condition
- C0128 — Brake Fluid Low Circuit
- C0710 — Steering Position Malfunction
- B1671 — Battery Module Voltage Out of Range
- U2021 — Data Received Invalid/Error
Alt text: A mechanic using an OBD2 scanner tool connected to the OBDII port for vehicle diagnostics, illustrating the practical application of the port.
OBD2 Port and Telematics Applications
The presence of the OBD2 port allows telematics devices to seamlessly process information such as engine RPM, vehicle speed, fault codes, fuel consumption, and much more. The telematics device uses 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, allowing fleet management teams to monitor vehicle usage and performance effectively. The OBD2 port thus acts as a critical data conduit for telematics systems.
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. The versatility of Geotab’s devices ensures comprehensive vehicle data capture through the OBD2 port, regardless of vehicle type.
With the standardized OBD2 port, connecting a fleet tracking solution to your vehicle is quick and easy. In the case of Geotab, setup can be completed in under five minutes. This plug-and-play nature of the OBD2 port simplifies the integration of telematics into vehicle fleets.
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 fast and doesn’t require any special tools or professional installer assistance. This adaptability ensures that even vehicles without a standard OBD2 port can benefit from telematics solutions.
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. WWH-OBD encompasses the monitoring of vehicle data, such as emissions output and engine fault codes, aiming for a globally consistent diagnostic approach.
Advantages of WWH-OBD
Here are the advantages of transitioning to WWH in more technical detail:
Access to More Data Types
Currently, OBDII Parameter IDs (PIDs) used in Mode 1 are only one byte long, meaning only up to 255 unique data types are available. Expanding PIDs could also be applied to other OBD-II modes that have transitioned to WWH via UDS modes. Adopting WWH standards allows for more data availability and offers future expansion potential. This enhanced data access through WWH-OBD provides richer insights into vehicle operation.
More Detailed Fault Data
Another advantage of WWH is the expansion of the 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. This level of detail in fault reporting, facilitated by WWH-OBD, greatly improves diagnostic accuracy.
WWH also offers more fault information, 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. The enhanced fault information available through WWH-OBD provides a more comprehensive understanding of vehicle issues.
In summary, WWH-OBD expands 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 on the vehicle to find out if OBD-II or WWH is available (in some cases, both are). Geotab’s proactive support for WWH-OBD ensures future-proof telematics solutions.
At Geotab, we are continuously improving our firmware to further expand the information our customers receive. We have already started supporting the 3-byte DTC information and continue to add more information on faults being 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 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. This commitment to continuous improvement ensures that Geotab devices remain at the forefront of vehicle diagnostic technology, leveraging the full potential of the OBD2 port and evolving standards like WWH-OBD.
Growing Beyond OBD2
OBDII contains 10 standard modes for getting the diagnostic information required by emissions regulations. The issue is that these 10 modes have not been sufficient for all diagnostic needs.
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 that was not required through OBDII data (such as odometer and seat belt usage) became available through UDS modes.
The reality is that UDS contains more than 20 additional modes on top of the current 10 standard modes available through 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 represents the future of standardized vehicle diagnostics, building upon the foundation of the OBD2 port and expanding its capabilities.
Conclusion
In the growing world of IoT, the OBD2 port remains vital for vehicle health, safety, and sustainability. While the number and variety of connected devices for vehicles increase, not all devices give and track the same information. Moreover, compatibility and security can vary from device to device. The standardized OBD2 port provides a consistent and reliable interface for accessing critical vehicle data.
Given 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 must be able to understand and translate a comprehensive set of vehicle diagnostic codes. Choosing a robust telematics solution that effectively utilizes the OBD2 port is essential for comprehensive vehicle management and data insights.
