OBD-II¶

This page teaches how OBD-II exposes a narrow regulatory diagnostic view rather than a complete vehicle telemetry model.

draft-core-lab: This page is not yet promoted to final copy. The synthetic runtime example is available, but the exact service/PID formula still lacks a redistributable claim-level source. The formula below is a project-local teaching profile, not a claim that standards metadata substantiates detailed behavior.

A Concrete Artifact¶

# synthetic observed OBD-II service 01 PID 0C exchange
observed tester -> vehicle: 01 0c
observed vehicle -> tester: 41 0c 1a f8

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Inspection Trap¶

OBD-II data can feel like whole-vehicle truth because common PIDs have familiar names. The captured exchange is narrower: it shows one regulatory diagnostic view exposed through a service/PID definition and observed through a particular adapter or transport path.

The safer claim is PID-relative. A passive observer can describe the observed service, PID, response shape, raw bytes, and formula result. That does not prove full vehicle state, proprietary ECU state, or freshness outside the observed exchange.

Worked Decode¶

1. Service 0x01 is treated as a current-data-shaped byte in this project-local teaching profile.
2. PID 0x0c is treated as the engine-speed-shaped parameter in that profile.
3. Response 41 0c has the profile's positive-response shape for service 01, PID 0c.
4. Raw bytes 1a f8 combine into 0x1af8, decimal 6904.
5. The project-local teaching formula divides by four, producing 1726 rpm.
6. The formula is an explicit assumption for this artifact. It is not source authority or a general rule for other bytes.

What The Evidence Supports¶

The artifact supports a narrow diagnostic claim: under the service 01 PID 0c teaching formula, the observed response bytes render as 1726 rpm. It also supports an observer claim that the capture contains a request-shaped payload and a positive-response-shaped payload for the same service/PID.

This is useful precisely because it is bounded. The page teaches how a familiar value should remain attached to its service, PID, formula, and capture context.

What The Evidence Does Not Support¶

The artifact does not prove the whole vehicle network state, proprietary ECU signals, regulatory readiness, DTC context, adapter freshness, or physical truth beyond the observed exchange. It does not prove that all engine-speed-like values on the vehicle would agree.

The page does not teach live diagnostic operation, adapter setup, fault clearing, or vehicle interaction procedures.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

OBD-II visibility is request/response-shaped. Adapter behavior, transport timing, and repeated observations control freshness evidence. The project-local teaching profile supplies the formula assumption, while the capture supplies timing and pairing evidence. Final-copy promotion requires a redistributable source that supports the detailed claim.

Applicable OBD-II service/PID definitions are the eventual authority for public diagnostic values. This draft does not claim its metadata-only standard citation proves the exact formula.

Failure And Ambiguity¶

• A service/PID formula is not interchangeable with other PIDs or proprietary data.
• Adapter smoothing, caching, or slow observations can make values stale.
• A DTC code without readiness, freeze-frame, and service context can be overinterpreted.
• A positive response does not prove that the value matches every internal ECU estimate or physical measurement.
• Proprietary diagnostics may expose different values through different authorities.

Python Model¶

The current package exposes a narrow observed-message model for passive OBD-II service 01 PID 0c inspection:

"""Runnable OBD-II service 01 PID 0C example for the schoolbus binder."""

from schoolbus.protocols.obdii import ObdIiExchange, ObdIiMessage

request = ObdIiMessage.from_hex("request", "01 0c")
response = ObdIiMessage.from_hex("response", "41 0c 1a f8")
exchange = ObdIiExchange(request=request, response=response)

print(request.show_fields())
print(response.show_fields())
print(exchange.observation.show_fields())
print(exchange.explain())

The model decodes one PID teaching formula and keeps the result as captured payload evidence, not whole-vehicle state or proof of physical truth.

The exchange is synthetic. The page omits full service tables, DTC encoding, readiness monitors, freeze-frame context, adapter behavior, transport variants, and operational vehicle procedures.

Source Notes¶

References¶

Public Sources¶

• SAE International
• SAE J1979 E/E Diagnostic Test Modes / OBD communication
  • canonical-standard metadata.
• Tooling references
• Scapy automotive layers
  • automotive layer structure and packet inspection docs.
• python-can - CAN log inspection and offline lab context.
• cantools - description-file parsing and signal inspection.

Project posture is aggregated in the protocol support policy, source policy, and project charter.