ISO-TP¶

This page teaches how ISO-TP turns several observed CAN payloads into one larger transport message without deciding what that message means.

A Concrete Artifact¶

# synthetic passive ISO-TP exchange over CAN identifiers 0x7e0 and 0x7e8
0x7e0  10 0a 22 f1 90 12 34 56
0x7e8  30 00 00
0x7e0  21 78 9a bc de

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

Inspection Trap¶

A complete ISO-TP reassembly can look like a complete diagnostic interpretation. It is not. ISO-TP explains how bytes crossed CAN frame boundaries; UDS, OBD-II, or another application authority explains what the reassembled bytes mean.

The safer claim is transport-relative: a passive observer can describe first frame length, flow-control evidence, consecutive-frame sequence, and the reassembled byte string. Application semantics stay outside ISO-TP.

Worked Decode¶

1. 10 0a is a first-frame-shaped PCI: high nibble 1 means first frame, and the teaching length is 0x00a, or ten application bytes.
2. The first frame contributes six data bytes: 22 f1 90 12 34 56.
3. 30 00 00 is a flow-control-shaped payload. In this teaching model, it means continue-to-send with block size 0 and separation-time byte 0.
4. 21 78 9a bc de is a consecutive-frame-shaped payload with sequence number 1 and four more data bytes.
5. The reassembled transport payload is:

22 f1 90 12 34 56 78 9a bc de

That byte string can be handed to a UDS page or another application decoder, but ISO-TP itself stops at transport reconstruction.

What The Evidence Supports¶

The artifact supports a transport claim: three observed CAN payloads form a complete ten-byte ISO-TP teaching message with one first frame, one flow-control frame, and one consecutive frame. The sequence and length are internally consistent in the current toy model.

It also supports timing questions: the flow-control response and subsequent consecutive frame are part of the evidence for request/response pairing and transport pacing.

What The Evidence Does Not Support¶

The artifact does not prove UDS service meaning, DID meaning, ECU identity, tester intent, physical state, session state, or whether the same exchange would work in another context. Reassembly completeness is not application truth.

The page does not teach live diagnostic operation. It describes already-observed transport evidence.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

ISO-TP authority is conversational. Flow control lets the receiver shape how the sender continues, so timing gaps and missing consecutive frames are part of the transport evidence.

ISO-TP does not name diagnostic services, parameters, or engineering values. Those claims require the application layer carried inside the transport payload, such as UDS service definitions and DID catalogs.

Failure And Ambiguity¶

• A missing consecutive frame can make an incomplete application payload look like a smaller complete one if length is ignored.
• Wrong addressing context can pair the wrong sender and receiver.
• STmin and block-size evidence affect timing interpretation.
• Sequence-number gaps can indicate loss, capture gaps, or mixed conversations.
• A valid reassembly can still carry proprietary or unknown application bytes.

Python Model¶

The current package exposes small ISO-TP frame and reassembly models for passive transport inspection:

"""Runnable ISO-TP transport reassembly example for the schoolbus binder."""

from schoolbus.protocols.isotp import IsoTpFrame, IsoTpReassembly

payloads = [
    "10 0a 22 f1 90 12 34 56",
    "30 00 00",
    "21 78 9a bc de",
]

frames = [IsoTpFrame.from_hex(payload) for payload in payloads]
reassembly = IsoTpReassembly(tuple(frames))

print([frame.show_fields() for frame in frames])
print(reassembly.show_fields())
print(reassembly.explain())

The model reconstructs transport bytes from observed payload fragments. It does not interpret UDS services, parameters, or live-system behavior.

The exchange is synthetic. It omits extended/mixed addressing variants, exact timer values, padding policy, normal-fixed addressing, and conformance behavior.

Source Notes¶

References¶

Public Sources¶

• ISO
• ISO 15765-2 Diagnostic communication over CAN - Transport protocol and network layer services
  • canonical-standard metadata.
• Linux kernel
• Linux ISO-TP documentation
  • kernel documentation.
• Tooling references
• Scapy automotive layers
  • automotive layer structure and packet inspection docs.
• python-can - CAN log inspection and offline lab context.
• can-utils - CAN capture/log-format context.
• udsoncan - UDS message-structure library context.

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