You may have come across the terms “OBD” or “OBDII” when reading about connected vehicles and devices like Geotab GO. These features are integral parts of modern car computer systems and possess a history that might be less known. In this article, we aim to provide a comprehensive overview of OBDII and explore the timeline of its development.
Understanding OBD (On-Board Diagnostics)
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 performance and diagnose repair needs efficiently.
OBD is the standard protocol predominantly used in light-duty vehicles to retrieve vehicle 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 car’s computers or brain, constantly monitoring and controlling various functions.
Alt text: Close-up of an OBD II port connector, a 16-pin female connector, typically located under the dashboard of a car, used to access vehicle diagnostic information.
Why is OBD So Important?
OBD plays a pivotal role in telematics and fleet management, as it enables the measurement and management of vehicle health and driving behavior. Its importance stems from the wealth of data it provides, which can be leveraged for various benefits.
Thanks to OBD, fleets can effectively:
- Track wear and tear trends: Identify which vehicle parts are wearing out faster than expected, allowing for preventative maintenance scheduling.
- Diagnose vehicle issues proactively: Instantly identify potential vehicle problems before they escalate, facilitating a proactive maintenance approach instead of reactive repairs.
- Measure driving behavior: Monitor speed, idling time, harsh braking, and other driving habits to improve driver safety and fuel efficiency.
This data-driven approach leads to reduced downtime, lower maintenance costs, improved vehicle lifespan, and enhanced operational efficiency for fleets and individual car owners alike.
Where is the OBDII Port Located?
In a typical passenger vehicle, the OBDII port is usually located on the underside of the dashboard on the driver’s side of the car. While this is the most common location, it can sometimes be found in other areas depending on the vehicle model. These alternative locations might include under the steering column, in the glove compartment, or even in the center console. It’s designed to be easily accessible, generally without needing any tools to reach it. Depending on the vehicle type, the port may have a 16-pin, 6-pin, or 9-pin configuration. The 16-pin connector is the standardized shape for OBDII in most modern cars.
Alt text: Illustration showing a hand pointing to the OBDII port located under the dashboard on the driver’s side of a car, highlighting its typical and easily accessible placement.
OBD vs. OBDII: Understanding the Difference
Simply put, OBDII is the second generation of OBD, or OBD I. The original OBD, or OBD I, was often connected externally to a car’s console, whereas OBDII is integrated directly into the vehicle itself. OBD I systems were in use until OBDII was developed and standardized in the early 1990s.
The key differences between OBD and OBDII are:
- Standardization: OBD-I was largely manufacturer-specific, meaning each car maker could implement their own diagnostic systems and codes. OBD-II brought about standardization in terms of connector type, communication protocols, and diagnostic trouble codes (DTCs). This standardization made it easier for technicians to diagnose and repair vehicles from different manufacturers using a single tool.
- Data Availability: OBD-II provides a more comprehensive set of diagnostic data compared to OBD-I. It monitors emissions-related components and engine parameters more extensively.
- Location and Connector: OBD-I connectors varied widely in shape and location. OBD-II mandated a standardized 16-pin Diagnostic Link Connector (DLC), usually located within easy reach of the driver’s seat.
- Communication Protocol: OBD-II utilizes standardized communication protocols such as CAN (Controller Area Network), ISO 9141-2, and SAE J1850, ensuring interoperability between diagnostic tools and vehicles.
The History of OBDII: A Timeline of Development
The journey of on-board diagnostics began in the 1960s, with various organizations playing crucial roles in laying the groundwork for the standard we know today. These organizations include 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 efforts, vehicle manufacturers developed their proprietary systems. Diagnostic tools from each manufacturer, and sometimes even across different models from the same manufacturer, had unique connector types, electronic interface requirements, and custom codes for reporting issues. This lack of uniformity presented significant challenges for vehicle repair and maintenance.
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, though it had limited, non-standardized capabilities. This illustrated the growing interest in on-board diagnostics within the automotive industry.
- 1979: The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and a uniform set of diagnostic test signals. This was a significant step towards industry-wide standardization.
- 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 early adoption of digital communication for diagnostics.
- 1988: Standardization of on-board diagnostics gained momentum in the late 1980s following the 1988 SAE recommendation, which called for a standard connector and diagnostic set. This laid the foundation for OBD standardization.
- 1991: The state of California mandated that all vehicles sold in the state should have some form of basic on-board diagnostics. This requirement, known as OBD I, was a crucial regulatory push for diagnostics.
- 1994: California Air Resources Board (CARB) mandated OBDII for 1996 model year vehicles and onwards sold in California, based on SAE recommendations. OBDII was designed to broadly support emissions testing and included a set of standardized Diagnostic Trouble Codes (DTCs). This was a pivotal moment, setting the stage for nationwide adoption.
- 1996: OBD-II became mandatory for all cars manufactured for sale in the United States. This marked the nationwide standardization of OBDII in the US market.
- 2001: EOBD (European On-Board Diagnostics), the European equivalent of OBDII, became mandatory for all gasoline vehicles in the European Union. This expanded the reach of standardized diagnostics to Europe.
- 2003: EOBD became mandatory for all diesel vehicles in the EU. This further broadened the application of EOBD across different engine types in Europe.
- 2008: Starting in 2008, all vehicles in the United States were required to implement OBDII using a Controller Area Network (CAN), as specified in ISO standard 15765-4. CAN became the dominant protocol for OBDII communication, offering faster and more reliable data transfer.
What Data Can Be Accessed From OBDII?
OBDII provides access to a wealth of status information and Diagnostic Trouble Codes (DTCs) related to:
- Powertrain (Engine and Transmission): This includes data from the engine control system and the transmission control system, covering aspects like engine speed, load, fuel system, ignition system, and transmission performance.
- Emissions Control Systems: OBDII is primarily focused on monitoring emissions-related components to ensure vehicles comply with environmental regulations. It monitors components like oxygen sensors, catalytic converters, evaporative emission control systems, and more.
In addition, the following vehicle information can be accessed via OBDII:
- Vehicle Identification Number (VIN): A unique identifier for each vehicle, used for vehicle tracking and identification.
- Calibration Identification Number: Identifies the software calibration version used by the vehicle’s computer.
- Ignition Counter: Counts the number of ignition cycles, which can be useful for tracking engine usage and maintenance intervals.
- Emissions Control System Counters: Specific counters related to the operation and performance of emissions control systems.
When you take your car to a service shop for maintenance or repair, a mechanic can connect a scan tool to the OBD port, read the fault codes, and quickly pinpoint the problem. This capability means mechanics can accurately diagnose malfunctions, inspect vehicles efficiently, and address issues before they escalate into major problems.
Examples of OBDII Data (Modes and PIDs):
OBDII data is organized into different “Modes,” each providing a specific type of diagnostic information. Within each mode, “Parameter IDs” (PIDs) are used to request specific data points.
Mode 1 (Show current data): This mode provides real-time data parameters, including:
- PID 12 — Engine RPM: Revolutions Per Minute of the engine crankshaft.
- PID 13 — Vehicle Speed: Current speed of the vehicle.
… and many more parameters related to engine performance, temperatures, pressures, sensor readings, etc.
Mode 3 (Show Diagnostic Trouble Codes – DTCs): This mode displays stored DTCs that indicate detected malfunctions. DTCs are standardized five-character codes:
- First character: Indicates the system affected:
- P = Powertrain (Engine, Transmission)
- C = Chassis (Brakes, Suspension, Steering)
- B = Body (Interior, Airbags, Comfort/Convenience)
- U = Network/Communication (Communication bus systems)
- Second character: Indicates code type (Generic or Manufacturer Specific).
- Remaining characters (three): Specific fault number.
Examples of DTCs:
- P0201 — Injector Circuit Malfunction – Cylinder 1: Indicates an electrical issue with the fuel injector in cylinder 1.
- P0217 — Engine Overtemperature Condition: Signals that the engine is overheating.
- P0219 — Engine Overspeed Condition: Indicates that the engine is running faster than its designed limit.
- C0128 — Brake Fluid Low Circuit: Indicates a problem with the brake fluid level sensor circuit.
- C0710 — Steering Position Malfunction: Signals an issue with the steering position sensor.
- B1671 — Battery Module Voltage Out of Range: Indicates that the battery voltage is outside the acceptable range.
- U2021 — Invalid/Faulty Data Received: Indicates a communication error where invalid or corrupted data was received on the vehicle network.
These are just a few examples; OBDII provides access to hundreds of different parameters and diagnostic codes, offering a comprehensive view of vehicle health.
OBD and Telematics: Powering Connected Fleets
The presence of OBDII allows telematics devices to seamlessly process critical information like engine RPM, vehicle speed, diagnostic trouble codes, fuel consumption, and much more. A telematics device can utilize this data to determine trip start and end times, instances of over-revving, speeding, excessive idling, fuel usage, and other key performance indicators. All this information is then uploaded to a software interface, enabling fleet management teams to monitor vehicle usage and performance effectively.
Alt text: Image depicting a telematics device plugged into an OBDII port in a vehicle, illustrating the direct connection for data acquisition in fleet management systems.
Given the multitude of OBD protocols and vehicle makes and models, not all telematics solutions are designed to work universally. Geotab telematics overcomes this challenge by intelligently translating diagnostic codes from various manufacturers and models, including electric vehicles. This broad compatibility ensures comprehensive fleet visibility, regardless of vehicle type.
With the standardized OBD-II port, connecting a fleet tracking solution to your vehicle becomes a quick and straightforward process. In the case of Geotab, setup can be achieved in under five minutes.
If your vehicle or truck lacks a standard OBDII port, adapters can be used to bridge the connection. In any case, the installation process remains rapid and doesn’t require specialized tools or professional installer assistance, making it highly accessible for fleet deployment.
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, developed under the United Nations as part of the Global Technical Regulation (GTR) framework. WWH-OBD aims to standardize and enhance vehicle diagnostics globally, encompassing monitoring of vehicle data such as emissions output and engine fault codes.
Advantages of WWH-OBD: A More Technical Look
Moving to WWH-OBD offers several technical advantages that enhance diagnostic capabilities:
Access to More Data Types
Current 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 PID capabilities, potentially also for other OBD-II modes transitioned to WWH via UDS (Unified Diagnostic Services) modes. Adopting WWH standards allows for more data availability and future expansion possibilities.
More Detailed Fault Information
Another key advantage of WWH-OBD is the expanded fault information. Traditional OBDII uses a 2-byte Diagnostic Trouble Code (DTC) to indicate a fault (e.g., P0070 indicates “Ambient Air Temperature Sensor ‘A’ Circuit Malfunction”).
Unified Diagnostic Services (UDS) expands the 2-byte DTC to a 3-byte DTC. The third byte indicates the “failure mode.” This failure mode is similar to the Failure Mode Indicator (FMI) used in the J1939 protocol.
Example: In OBDII, you might have separate DTCs like:
- 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 can be consolidated under a single base code, P0070, with different failure modes indicated in the third byte of the DTC. For example, P0071 could become P0070-1C.
WWH-OBD also provides additional fault information, such as severity/class and status. Severity indicates the urgency of addressing the fault, while the fault class categorizes the fault based on GTR specifications. Fault status indicates if a fault is pending, confirmed, or if testing for the fault in the current driving cycle is complete.
In summary, WWH-OBD expands upon the existing OBDII framework to offer richer diagnostic information.
Geotab’s WWH-OBD Compatibility
Geotab has already implemented the WWH-OBD protocol in our firmware. Geotab employs a sophisticated protocol detection system that safely examines what is available in the vehicle to determine if OBD-II or WWH-OBD (or in some cases, both) is available.
At Geotab, we are continuously enhancing our firmware to expand the insights our customers gain. We have already begun supporting 3-byte DTC information and are continuously adding more detailed fault information generated by vehicles. When new information becomes available through OBDII or WWH-OBD (like a new PID 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 new firmware to our devices over-the-air, ensuring our customers always benefit from the most comprehensive data available from their vehicles.
Growing Beyond OBDII: Embracing UDS
OBDII includes 10 standard modes designed to provide the diagnostic information required for emissions standards compliance. However, these 10 modes have become insufficient for accessing the full range of vehicle data.
Over time, since the implementation of OBDII, various UDS (Unified Diagnostic Services) modes have been developed to enrich available data. Vehicle manufacturers utilize their own proprietary PIDs and implement them using these additional UDS modes. Information not initially considered essential under OBDII data (such as odometer readings and seat belt usage) became accessible through UDS modes.
UDS offers over 20 additional modes beyond the standard 10 modes of OBDII, significantly expanding data access. WWH-OBD seeks to integrate UDS modes with OBDII to enhance diagnostic data availability while maintaining a standardized process. This evolution ensures that diagnostic systems can keep pace with the increasing complexity and data richness of modern vehicles.
Conclusion: The Enduring Importance of OBD2
In the 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 is increasing, not all devices provide and track the same information. Furthermore, compatibility and security can vary across devices.
Given the multitude of OBD protocols, it’s evident that not all telematics solutions are created equal in terms of vehicle compatibility. Effective telematics solutions, like Geotab, must be capable of understanding and translating a comprehensive set of vehicle diagnostic codes across diverse makes and models. This broad compatibility and robust data interpretation are essential for providing truly valuable insights into vehicle performance and fleet operations. As vehicles become more complex and data-driven, the role of OBD and its evolving standards like WWH-OBD will only become more critical in ensuring efficient vehicle maintenance, optimized performance, and a safer, more sustainable transportation ecosystem.
