UDS¶

This page teaches how to inspect observed diagnostic service exchanges without turning a request/response pair into a claim about the whole ECU.

A Concrete Artifact¶

# synthetic observed UDS exchange after transport reassembly
observed tester -> ECU: 22 f1 90
observed ECU -> tester: 62 f1 90 12 34

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

Inspection Trap¶

UDS can make a captured diagnostic exchange feel authoritative because the service bytes have recognizable names. The exchange still only shows what an observed tester asked and how an observed ECU responded in that context.

The safer claim is interaction-relative: a passive observer can describe the service shape, positive or negative response shape, DID echo, payload bytes, and timing. DID names, value meaning, session/security context, and ECU-specific truth require source authority beyond the captured bytes.

Worked Decode¶

1. Request byte 0x22 is treated as a ReadDataByIdentifier-shaped service in this teaching model.
2. f1 90 is a DID-shaped value. DID catalogs are ECU-specific authority; the bytes alone do not name the value.
3. Response byte 0x62 has the positive-response shape associated with request service 0x22.
4. The response echoes DID f1 90, which supports pairing this response with the observed request.
5. Response data bytes 12 34 are returned payload evidence. Their engineering meaning is outside the page artifact.

What The Evidence Supports¶

The artifact supports a diagnostic-exchange claim: an observed tester emitted a ReadDataByIdentifier-shaped request for DID 0xf190, and an observed ECU returned a positive-response-shaped payload that echoes the DID and includes two data bytes.

It also supports timing and pairing questions when the surrounding capture is available: response latency, missing responses, repeated requests, negative responses, and tester behavior can all matter to a passive observer.

What The Evidence Does Not Support¶

The artifact does not prove VIN, calibration identity, ECU health, regulatory state, security state, session capability, or physical machine truth. It does not prove that another ECU, another session, or another time would expose the same data.

The page does not teach readers to initiate sessions, bypass protected access, run routines, reset fault memory, program software, or interact with a real vehicle.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

UDS authority is stateful and source-bound. Sessions, security access, timing, routines, and ECU-specific DID catalogs shape what may appear in a captured exchange. A passive observer sees observed tester choice and observed ECU response, not unrequested state.

DID catalogs, service definitions, session context, and ECU-specific documentation are semantic authority for UDS values. Public explainers can teach the shape, but they do not identify proprietary DIDs or prove physical truth.

Failure And Ambiguity¶

• A DID catalog can be ECU-specific, stale, or mismatched to the observed ECU.
• Negative responses may indicate timing, conditions, session state, or authorization, not simple absence.
• Transport reassembly can hide application boundaries when ISO-TP is ignored.
• Gateway or tester behavior can change what a passive observer sees.
• A positive-response shape does not prove value freshness or engineering truth.

Python Model¶

The current package exposes a small observed-message model for passive UDS payload inspection:

"""Runnable UDS observed exchange example for the schoolbus binder."""

from schoolbus.protocols.uds import UdsExchange, UdsMessage

request = UdsMessage.from_hex("request", "22 f1 90")
response = UdsMessage.from_hex("response", "62 f1 90 12 34")
exchange = UdsExchange(request=request, response=response)

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

The model describes request-shaped, positive-response-shaped, and negative-response evidence without initiating sessions, naming proprietary DIDs, or providing diagnostic operation helpers.

The observed request and response are synthetic. The page omits service tables, security-access workflows, programming sequences, routine-control details, response-pending timing, transport addressing variants, and operational vehicle procedures.

Source Notes¶

References¶

Public Sources¶

• ISO
• ISO 14229-1 Unified diagnostic services (UDS) - Application layer
  • canonical-standard metadata.
• Vector
• UDS overview - vendor tutorial.
• Tooling references
• udsoncan - UDS message-structure library context.
• Scapy automotive layers
  • automotive layer structure and packet inspection docs.
• python-can - CAN log inspection and offline lab context.

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