Standard OBD2 PIDs

The table below shows the standard OBD-II PIDs as defined by SAE J1979. The expected response for each PID is given, along with information on how to translate the response into meaningful data. Again, not all vehicles will support all PIDs and there can be manufacturer-defined custom PIDs that are not defined in the OBD-II standard.

Note that modes 1 and 2 are basically identical, except that Mode 1 provides current information, whereas Mode 2 provides a snapshot of the same data taken at the point when the last diagnostic trouble code was set. The exceptions are PID 01, which is only available in Mode 1, and PID 02, which is only available in Mode 2. If Mode 2 PID 02 returns zero, then there is no snapshot and all other Mode 2 data is meaningless.

Please, note that when using Bit-Encoded-Notation, quantities like C4 means bit 4 from data byte C. Each bit is numerated from 0 to 7, so 7 is the most significant bit and 0 is the least significant bit.

OBD-II PIDs Modes

There are ten OBD-II PIDs modes of operation described in the latest OBD-II standard SAE J1979. They are as follows (the $ prefix indicates a hexadecimal radix):
$01. Show current data
$02. Show freeze frame data
$03. Show stored Diagnostic Trouble Codes
$04. Clear Diagnostic Trouble Codes and stored values
$05. Test results, oxygen sensor monitoring (non CAN only)
$06. Test results, other component/system monitoring (Test results, oxygen sensor monitoring for CAN only)
$07. Show pending Diagnostic Trouble Codes (detected during current or last driving cycle)
$08. Control operation of on-board component/system
$09. Request vehicle information
$0A. Permanent DTC’s (Cleared DTC’s)

Vehicle manufacturers are not required to support all modes.

Each manufacturer may define additional modes above #9 (e.g.: mode 22 as defined by SAE J2190 for Ford/GM, mode 21 for Toyota) for other information (e.g.: the voltage of the Traction Batter

OBD-II PIDs

OBD-II PIDs (On-board diagnostics Parameter IDs) are codes used to request data from a vehicle, used as a diagnostic tool. SAE standard J/1979 defines many PIDs, but manufacturers also define many more PIDs specific to their vehicles. All light duty vehicles (i.e. less than 8,500 pounds) sold in North America since 1996, as well as medium duty vehicles (i.e. 8,500-14,000 pounds) beginning in 2005, and heavy duty vehicles (i.e. greater than 14,000 pounds) beginning in 2010, are required to support OBD-II diagnostics, using a standardized data link connector, and a subset of the SAE J/1979 defined PIDs (or SAE J/1939 as applicable for medium/heavy duty vehicles), primarily for state mandated emissions inspections.

Typically, an automotive technician will use PIDs with a scan tool connected to the vehicle’s OBD-II connector.

  • The technician enters the PID
  • The scan tool sends it to the vehicle’s bus (CAN, VPW, PWM, ISO, KWP. After 2008, CAN only)
  • A device on the bus recognizes the PID as one it is responsible for, and reports the value for that PID to the bus
  • The scan tool reads the response, and displays it to the technician

OBD Security issues

OBD Security issues:

Researchers at the University of Washington and University of California examined the security around OBD, and found that they were able to gain control over many vehicle components via the interface. Furthermore, they were able to upload new firmware into the engine control units. Their conclusion is that vehicle embedded systems are not designed with security in mind.

 

There have been reports of thieves using specialist OBD reprogramming devices to enable them to steal cars without the use of a key.The primary causes of this vulnerability lie in the tendency for vehicle manufacturers to extend the bus for purposes other than those for which it was designed, and the lack of authentication and authorization in the OBD specifications, which instead rely largely on security through obscurity.

OBD Standards documents

SAE standards documents on OBD-II

  • J1962 – Defines the physical connector used for the OBD-II interface.
  • J1850 – Defines a serial data protocol. There are 2 variants- 10.4 kbit/s (single wire, VPW) and 41.6 kbit/s (2 wire, PWM). Mainly used by US manufacturers, also known as PCI (Chrysler, 10.4K), Class 2 (GM, 10.4K), and SCP (Ford, 41.6K)
  • J1978 – Defines minimal operating standards for OBD-II scan tools
  • J1979 – Defines standards for diagnostic test modes
  • J2012 – Defines standards trouble codes and definitions.
  • J2178-1 – Defines standards for network message header formats and physical address assignments
  • J2178-2 – Gives data parameter definitions
  • J2178-3 – Defines standards for network message frame IDs for single byte headers
  • J2178-4 – Defines standards for network messages with three byte headers*
  • J2284-3 – Defines 500K CAN Physical and Data Link Layer
  • J2411 – Describes the GMLAN (Single-Wire CAN) protocol, used in newer GM vehicles. Often accessible on the OBD connector as PIN 1 on newer GM vehicles.

SAE standards documents on HD (Heavy Duty) OBD

  • J1939 – Defines a data protocol for heavy duty commercial vehicles

ISO standards

  • ISO 9141: Road vehicles — Diagnostic systems. International Organization for Standardization, 1989.
    • Part 1: Requirements for interchange of digital information
    • Part 2: CARB requirements for interchange of digital information
    • Part 3: Verification of the communication between vehicle and OBD II scan tool
  • ISO 11898: Road vehicles — Controller area network (CAN). International Organization for Standardization, 2003.
    • Part 1: Data link layer and physical signalling
    • Part 2: High-speed medium access unit
    • Part 3: Low-speed, fault-tolerant, medium-dependent interface
    • Part 4: Time-triggered communication
  • ISO 14230: Road vehicles — Diagnostic systems — Keyword Protocol 2000, International Organization for Standardization, 1999.
    • Part 1: Physical layer
    • Part 2: Data link layer
    • Part 3: Application layer
    • Part 4: Requirements for emission-related systems
  • ISO 15031: Communication between vehicle and external equipment for emissions-related diagnostics, International Organization for Standardization, 2010.
    • Part 1: General information and use case definition
    • Part 2: Guidance on terms, definitions, abbreviations and acronyms
    • Part 3: Diagnostic connector and related electrical circuits, specification and use
    • Part 4: External test equipment
    • Part 5: Emissions-related diagnostic services
    • Part 6: Diagnostic trouble code definitions
    • Part 7: Data link security
  • ISO 15765: Road vehicles — Diagnostics on Controller Area Networks (CAN). International Organization for Standardization, 2004.
    • Part 1: General information
    • Part 2: Network layer services ISO 15765-2
    • Part 3: Implementation of unified diagnostic services (UDS on CAN)
    • Part 4: Requirements for emissions-related systems

OBD Loggers

Data Loggers

obd log

Data loggers are designed to capture vehicle data while the vehicle is in normal operation, for later analysis.

Data logging uses include:

  • Engine and vehicle monitoring under normal operation, for the purpose of diagnosis or tuning.
  • Some US auto insurance companies offer reduced premiums if OBD-II vehicle data loggers[18][19] or cameras[20] are installed – and if the driver’s behaviour meets requirements. This is a form of auto insurance risk selection
  • Monitoring of driver behaviour by fleet vehicle operators.

Analysis of vehicle black box data may be performed on a periodic basis, automatically transmitted wirelessly to a third party or retrieved for forensic analysis after an event such as an accident, traffic infringement or mechanical fault.

Emission Testing

In the United States, many states now use OBD-II testing instead of tailpipe testing in OBD-II compliant vehicles (1996 and newer). Since OBD-II stores trouble codes for emissions equipment, the testing computer can query the vehicle’s onboard computer and verify there are no emission related trouble codes and that the vehicle is in compliance with emission standards for the model year it was manufactured.

In the Netherlands, 2006 and later vehicles get a yearly EOBD emission check.[21]

Driver’s Supplementary Vehicle Instrumentation

Driver’s supplementary vehicle instrumentation is instrumentation installed in a vehicle in addition to that provided by the vehicle manufacturer and intended for display to the driver during normal operation. This is opposed to scanners used primarily for active fault diagnosis, tuning, or hidden data logging.

Auto enthusiasts have traditionally installed additional gauges such as manifold vacuum, battery current etc. The OBD standard interface has enabled a new generation of enthusiast instrumentation accessing the full range of vehicle data used for diagnostics, and derived data such as instantaneous fuel economy.

Instrumentation may take the form of dedicated trip computers,[22] carputer or interfaces to PDAs,[23] smartphones, or a Garmin navigation unit.

As a carputer is essentially a PC, the same software could be loaded as for PC-based scan tools and vice-versa, so the distinction is only in the reason for use of the software.

These enthusiast systems may also include some functionality similar to the other scan tools.

Vehicle Telematics

OBD II is no longer only used by professionals and hobbyists to repair vehicles. OBD II information is commonly used by vehicle telematics devices that perform fleet tracking, monitor fuel efficiency, prevent unsafe driving, as well as for remote diagnostics and by Pay-As-You-Drive insurance. Although originally not intended for the above purposes, commonly supported OBD II data such as Vehicle Speed, RPM, and Fuel Level allow GPS based fleet tracking devices to monitor vehicle idling times, speeding, and over-revving. By monitoring OBD II DTCs a company can know immediately if one of its vehicles has an engine problem and by interpreting the code the nature of the problem. OBD II is also monitored to block mobile phones when driving and to record trip data for insurance purposes

OBD Applications

Various tools are available that plug into the OBD connector to access OBD functions. These range from simple generic consumer level tools to highly sophisticated OEM dealership tools to vehicle telematic devices.

Hand-held Scan Tools

A range of rugged hand-held scan tools is available.

  • Simple fault code readers/reset tools are mostly aimed at the consumer level.
  • Professional hand-held scan tools may possess more advanced functions
    • Access more advanced diagnostics
    • Set manufacturer- or vehicle-specific ECU parameters
    • Access and control other control units, such as air bag or ABS
    • Real-time monitoring or graphing of engine parameters to facilitate diagnosis or tuning

Mobile Device Based Tools and Analysis

Mobile device applications allow mobile devices such as cell phones and tablets to display and manipulate the OBD-II data accessed via USB adaptor cables or bluetooth adapters plugged into the car’s OBD II connector.

PC-based Scan Tools and Analysis Platforms

obd usb scanner

A PC-based OBD analysis tool that converts the OBD-II signals to serial data (USB or serial port) standard to PCs or Macs. The software then decodes the received data to a visual display. Many popular interfaces are based on the ELM or STN1110OBD Interpreter ICs, both of which read all five generic OBD-II protocols. Some adapters now use the J2534 API allowing them to access OBD-II Protocols for both cars and trucks.

In addition to the functions of a hand-held scan tool, the PC-based tools generally offer:

  • Large storage capacity for data logging and other functions
  • Higher resolution screen than handheld tools
  • The ability to use multiple software programs adding flexibility

The extent that a PC tool may access manufacturer or vehicle-specific ECU diagnostics varies between software products as it does between hand-held scanners.

OBD-II diagnostic data available

OBD2 provides access to data from the engine control unit (ECU) and offers a valuable source of information when troubleshooting problems inside a vehicle. The SAE J1979 standard defines a method for requesting various diagnostic data and a list of standard parameters that might be available from the ECU. The various parameters that are available are addressed by “parameter identification numbers” or PIDs which are defined in J1979. For a list of basic PIDs, their definitions, and the formula to convert raw OBD-II output to meaningful diagnostic units, see OBD-II PIDs. Manufacturers are not required to implement all PIDs listed in J1979 and they are allowed to include proprietary PIDs that are not listed. The PID request and data retrieval system gives access to real time performance data as well as flagged DTCs. For a list of generic OBD-II DTCs suggested by the SAE, see Table of OBD-II Codes. Individual manufacturers often enhance the OBD-II code set with additional proprietary DTCs.

Mode of operation

Here is a basic introduction to the OBD communication protocol according to ISO 15031:

Mode $01 is used to identify what powertrain information is available to the scan tool.

Mode $02 displays Freeze Frame data.

Mode $03 lists the emission-related “confirmed” diagnostic trouble codes stored. It displays exact numeric, 4 digit codes identifying the faults.

Mode $04 is used to clear emission-related diagnostic information. This includes clearing the stored pending/confirmed DTCs and Freeze Frame data.

Mode $05 displays the oxygen sensor monitor screen and the test results gathered about the oxygen sensor.

There are ten numbers available for diagnostics:

  1. $01 Rich-to-Lean O2 sensor threshold voltage
  2. $02 Lean-to-Rich O2 sensor threshold voltage
  3. $03 Low sensor voltage threshold for switch time measurement
  4. $04 High sensor voltage threshold for switch time measurement
  5. $05 Rich-to-Lean switch time in ms
  6. $06 Lean-to Rich switch time in ms
  7. $07 Minimum voltage for test
  8. $08 Maximum voltage for test
  9. $09 Time between voltage transitions in ms

Mode $06 is a Request for On-Board Monitoring Test Results for Continuously and Non-Continuously Monitored System. There are typically a minimum value, a maximum value, and a current value for each non-continuous monitor.

Mode $07 is a Request for emission-related diagnostic trouble codes detected during current or last completed driving cycle. It enables the external test equipment to obtain “pending” diagnostic trouble codes detected during current or last completed driving cycle for emission-related components/systems. This is used by service technicians after a vehicle repair, and after clearing diagnostic information to see test results after a single driving cycle to determine if the repair has fixed the problem.

Mode $08 could enable the off-board test device to control the operation of an on-board system, test, or component.

Mode $09 is used to retrieve vehicle information. Among others, the following information is available:

  • VIN (Vehicle Identification Number): Vehicle ID
  • CALID (Calibration Identification): ID for the software installed on the ECU
  • CVN (Calibration Verification Number): Number used to verify the integrity of the vehicle software. The manufacturer is responsible for determining the method of calculating CVN(s), e.g. using checksum.
  • In-use performance counters
    • Gasoline engine : Catalyst, Primary oxygen sensor, Evaporating system, EGR system, VVT system, Secondary air system, and Secondary oxygen sensor
    • Diesel engine : NMHC catalyst, NOx reduction catalyst, NOx absorber Particulate matter filter, Exhaust gas sensor, EGR system, VVT system, Boost pressure control, Fuel system.

Mode $0A lists emission-related “permanent” diagnostic trouble codes stored. As per CARB, any diagnostic trouble codes that is commanding MIL on and stored into non-volatile memory shall be logged as a permanent fault code.