How scan tools ask a car for live readings, stored faults and emissions readiness, and why most of the useful codes stay private.
OBD-II PIDs are numbered data requests that a scan tool sends to a car to read values such as speed, temperature, stored faults and readiness status. SAE J1979 defines the common codes, emissions rules require a shared subset in North America, and manufacturers add private codes beyond it.
OBD-II PIDs are numbered requests that let a scan tool read one value from a car, such as engine speed or a stored fault. SAE J1979 defines the common codes, and North American rules require a shared subset. Manufacturers add many private codes on top of that list.
What are OBD-II PIDs?
An OBD-II PID is a request for one piece of data from a vehicle. A scan tool sends the request, and the vehicle replies in a fixed format that the tool decodes into a readable value. The system is used as a diagnostic tool, and the codes behind it are defined mainly by SAE standard J1979.
Each PID has a number of its own, and the reply arrives as raw bytes. The tool converts those bytes with a formula, a bitmap or a lookup table, depending on the PID. Some results are plain quantities such as speed or temperature, while others are single bits that switch a warning on or off.
Every on-road vehicle sold in North America must answer a common set of questions, while manufacturers keep most of the rest to themselves.
Which vehicles must support OBD-II?
Light-duty vehicles under 8,500 lb (3,900 kg) were the first to be covered, from 1996. Medium-duty vehicles followed in 2005. Every vehicle in those two groups must support a subset of the standard codes, and both use the same standard connector.
| Vehicle class | Weight | Year | Connector |
|---|---|---|---|
| Light-duty | Under 8,500 lb (3,900 kg) | 1996 | SAE J1962 |
| Medium-duty | 8,500-14,000 lb (3,900-6,400 kg) | 2005 | SAE J1962 |
| Heavy-duty | Over 14,000 lb (6,400 kg) | Made after 2010 | SAE J1939-13 round connector, or J1962 on some trucks |
Heavy-duty vehicles over 14,000 lb (6,400 kg) made after 2010 may use SAE J1939-13 for diagnostics, and CARB cites title 13 CCR 1971.1 for that allowance. Some heavy trucks, notably Mack and Volvo Trucks models, still use the passenger-car connector. They run 29-bit CAN identifiers, while passenger cars use 11-bit identifiers.
How do the diagnostic services work?
SAE J1979 describes ten diagnostic services, and before 2002 the same standard called them modes. Manufacturers do not have to support every service, and they can add their own above the standard list. Ford and General Motors use service 22 under SAE J2190, while Toyota uses service 21.
Service 01 shows current data, while service 02 gives a freeze-frame snapshot taken when the last trouble code was set. Service 02 accepts the same PIDs as service 01, and PID 02 inside it returns the code that triggered the snapshot. PID 01 exists only in service 01 and PID 02 only in service 02, so the two services overlap without matching exactly. A frame number must be sent in the data section to select which snapshot is wanted. If service 02 PID 02 returns zero, there is no snapshot, and the rest of the service 02 data means nothing.
The other services cover the rest of the work. Service 03 lists stored trouble codes, service 04 clears them along with stored values, and service 05 reports oxygen sensor test results on non-CAN vehicles. Service 09 requests general vehicle information. Extra data such as the voltage of a hybrid traction battery is carried in manufacturer-defined services.
How are standard PIDs read?
Standard PIDs are listed in a table in SAE J1979. Each entry gives the expected response and the way to turn that response into a meaningful value. Not every vehicle supports every PID, and manufacturers can define custom codes that never appear in the standard.
Bit positions are written in shorthand, so C4 means bit 4 of data byte C. Bits are numbered from 0 to 7, with 7 as the most significant. PID 00 returns four bytes, read big-endian, and each bit says whether one of the next 32 PIDs is supported. A worked example in the standard lists supported PIDs such as 01, 03, 04, 05, 06 and 07.
PID 01 packs two kinds of information into its first byte. Bit A7 shows whether the malfunction indicator light, the check engine light, is illuminated. Bits A6 to A0 give the number of trouble codes flagged in the engine computer. The next three bytes cover readiness checks, and bit 3 of byte B tells the reader whether the engine is spark ignition or compression ignition. That bit changes how the last two bytes are read. For availability bits, a 1 means the test is available. For completeness bits, a 0 means the test is complete. PID 41 returns the same layout for the current drive cycle, except that its first byte is always zero.
PIDs 78 and 79 report exhaust gas temperature for bank 1 and bank 2. The first byte is a bitmap showing which sensors are fitted, and the 16-bit values that follow convert with the formula A x 256 + B, divided by 10, minus 40. The range runs from minus 40 to 6513.5 degrees Celsius at a scale of 0.1. Some other PIDs are enumerated rather than scaled. PID 03 reports fuel system status across two bytes, PID 1C says which OBD standard the control unit was designed for, and PID 51 gives the fuel type as one coded byte. No definition exists yet for flexible-fuel vehicles.
What do trouble codes look like?
A stored trouble code takes two bytes, and its first two bits give the category. The remaining 14 bits form a number, which is shown as a five-character code such as U0158. Service 03 returns the codes stored in the vehicle, and each one is then looked up in a table for its meaning.
The first character is the category letter. The second character can only be 0 to 3, because it is built from two bits, and the rest is a hexadecimal number. Some codes appear in a four-character form, such as C158, which is the raw two bytes without the category decoding applied. Blocks of codes have the same meaning on every vehicle, while others depend on the manufacturer or model.
Two or fewer codes fit in a single ISO-TP frame. Three or more codes are spread across several frames, and the count depends on the communication type and addressing. Service 09 also carries in-use performance tracking. PID 08 covers spark ignition engines and tracks catalysts, oxygen sensors, evaporative leak detection, EGR and secondary air. PID 0B covers compression ignition engines, including NOx and particulate filter monitors. Each item is a pair of counts: a numerator for malfunction conditions met, and a denominator for times the vehicle ran under those conditions.
Why are most PIDs non-standard?
Most OBD-II PIDs in use are non-standard, because modern vehicles expose far more functions than the standard list covers. Each manufacturer adds codes of its own, and very few overlap between brands. Public documentation is thin, so independent tool makers have to rely on paid sources.
The main reference for non-standard codes is kept by the Equipment and Tool Institute, a US body whose material is available only to members. Membership fees depend on company size, judged by annual sales of automotive tools and equipment. Even paying members do not get full documentation, and some manufacturers insist on a separate contract with each tool company. The per-year charges were recorded as a snapshot as of 13 April 2015.
How does OBD-II travel over the CAN bus?
OBD-II uses the CAN bus, and emissions protocols including OBD-II, EOBD and Unified Diagnostic Services (UDS) share the ISO-TP transport layer from ISO 15765-2. Each frame carries an 8-byte data length, with unused bytes padded, and the query goes out to every module on the bus at once.
The query is a functional broadcast, and up to eight engine control units can each listen on an identifier of their own. Each module replies on an identifier eight higher than its own address, so a reader can follow up with one specific unit when a conversation runs over several frames. The engine or main computer usually responds first. A Prius hybrid controller replies on its own identifier in the same way.
CAN can also carry traffic beyond the standard requests. Physical addressing uses particular CAN identifiers for specific modules, and a Ford instrument cluster, for instance, uses a physical address with proprietary payloads. A reader that understands only the standard requests will miss that traffic entirely.
Who developed and maintains the standard?
SAE International publishes the standard through its Vehicle E/E Diagnostic Standards Committee. The J1979 revision is dated 16 February 2017, and its digital annex, SAE J1979-DA, carries the same date. The standard sits beside the ISO work on emissions protocols, which is covered by ISO 15765-4.
Related pieces are the ELM327, a common microcontroller and multi-protocol interpreter used in many OBD-II interfaces, and the engine control unit, the computer that answers most requests. Unified Diagnostic Services is the broader ISO standard, and its services sit in a separate number range to avoid overlap with the OBD-II ones.
What are the advantages and drawbacks of OBD-II PIDs?
The chief advantage is a shared way to read a car's health that works across brands and supports emissions testing. The chief drawback is that only a small standard set is openly documented, while the rest sits behind fees and contracts. The standard also cannot cover every fault or every manufacturer-specific value.
Among the benefits, a single reader can check readiness status, read stored and frozen faults, and gather live values without needing a separate tool for each make. Because emissions checks rely on the standard, inspectors get consistent results. The ELM327 interpreter is one reason inexpensive interfaces can handle several protocols.
Gaps remain. Non-standard functions depend on paid or private material, and the meanings of some trouble codes shift between makes or models. Readiness bits and freeze frames help only when a reader interprets them correctly, and a long list of codes can take several frames to deliver.
