CAN¶

This page teaches how Classical CAN exposes priority, cadence, and frame shape before it exposes signal meaning.

A Concrete Artifact¶

# synthetic passive capture fragment
t=0.000000  0x080  01
t=0.000006  0x123  10 27 20 27 18 27 22 27
t=0.020005  0x123  20 27 21 27 19 27 22 27
t=0.040006  0x123  1f 27 20 27 18 27 23 27
t=0.050000  0x321  5a 00

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

Inspection Trap¶

A CAN frame can look complete while its payload is still semantically opaque. The identifier participates in arbitration and names a message shape; it is not automatically a sender address, an engineering value, or proof that an application used the data.

The safer claim is layered: a passive observer can first describe identifiers, payload length, payload bytes, timing, ACK/error evidence, and arbitration pressure. Signal names and units require a DBC, J1939 vocabulary, CANopen object dictionary, or OEM convention layered over the shared differential bus evidence.

Worked Decode¶

1. 0x080, 0x123, and 0x321 fit the standard 11-bit identifier space in this teaching example.
2. The identifier is treated as message identity plus arbitration priority. It is not automatically a sender address.
3. If 0x080 and 0x123 begin together, the lower numeric identifier wins because dominant 0 bits override recessive 1 bits during arbitration.
4. The repeated 0x123 observations add timing evidence: this identifier appears roughly every 20 ms in the synthetic trace.
5. 0x123 carries eight payload bytes, so the Classical CAN DLC is 8 in this simplified frame.
6. Under the page-local toy dictionary, 10 27 20 27 18 27 22 27 contains four little-endian unsigned values scaled by 0.01 km/h: 100.00, 100.16, 100.08, and 100.18 km/h.
7. Under a different DBC, J1939 vocabulary, CANopen object dictionary, or OEM agreement, the same bytes could decode differently or not at all. A wrong DBC could still produce a plausible but false wheel speed, temperature, or actuator state.

What The Evidence Supports¶

The artifact supports a frame-level observer claim: the synthetic trace contains standard identifiers 0x080, 0x123, and 0x321; identifier 0x123 appears near 20 ms intervals; its first payload can be split into four toy little-endian values; and lower numeric identifiers would win arbitration in the simplified dominant/recessive model.

The trace also supports cadence hypotheses: 0x080 at 10 ms and 0x123 at 20 ms are plausible scheduler rhythms when the pattern repeats in a longer passive capture. Those are freshness and priority clues, not signal truth.

What The Evidence Does Not Support¶

The artifact does not prove sender identity, receiver intent, physical state, freshness beyond the observed timestamps, or application consumption. A valid CRC does not prove the payload value is fresh, physically plausible, or used by an application.

The toy wheel-speed-like values are synthetic. Without a trusted DBC, J1939 PGN/SPN definition, CANopen object dictionary, or OEM source, the payload bytes remain bytes with cadence and frame integrity evidence.

Field Layout / Anatomy¶

Visual Model¶

0x080: 00010000000
0x123: 00100100011
      ^ first differing arbitration bit; dominant 0 continues

Timing And Authority¶

Bus authority is resolved during arbitration, one bit at a time. Arbitration pressure can delay low-priority frames and distort naive period estimates. A recurring 0x080 at 10 ms and 0x123 at 20 ms may reveal scheduler rhythm even if the payload is opaque.

Payload bytes need semantic authority before they become engineering values. DBC files, J1939 PGN/SPN definitions, CANopen object dictionaries, or OEM conventions turn payload bits into signal names, units, and state labels.

Failure And Ambiguity¶

• A missing identifier may mean sleep, failure, capture loss, bus-off, or simply a system state where the message is not scheduled.
• A valid CRC does not prove the payload value is fresh, physically plausible, or consumed by an application.
• A stale or wrong DBC can produce plausible false values.
• Arbitration pressure can delay low-priority frames and distort naive period estimates.
• Remote frames, error frames, bit stuffing, and physical-layer details are intentionally outside the page artifact.

Python Model¶

The current package exposes a concrete CAN example:

"""Runnable CAN inspection example for the schoolbus binder."""

from schoolbus.protocols.can import CanFrame

frame = CanFrame(identifier=0x123, data=bytes.fromhex("10 27 20 27 18 27 22 27"))

print(frame.show_fields())
print(frame.explain())

The binder keeps that model intentionally small: identifier, payload, field display, and explanation before any semantic dictionary. For a remote frame, requested_dlc records the expected length of the corresponding data frame; the remote artifact itself has no payload and does not establish that a response occurred.

The first workbook sample pack includes a passive synthetic CAN fixture under samples/first-workbook/ that mirrors this style of identifier, DLC, and payload inspection without assigning unsupported signal truth.

The brake/status, wheel-speed, and temperature/status meanings are synthetic. The packet diagram is a field-boundary view. It omits bit stuffing, exact inter-frame spacing, electrical design, termination, cable-length limits, and conformance timing.

Source Notes¶

References¶

Public Sources¶

• ISO
• ISO 11898-1 Road vehicles — Controller area network (CAN) — Data link layer and physical coding sublayer — canonical-standard metadata.
• Kvaser
• CAN protocol tutorial — vendor tutorial.
• Linux kernel
• SocketCAN documentation — kernel documentation.
• Tooling references
• python-can — CAN log inspection and offline lab context.
• can-utils — CAN capture/log-format context.
• SocketCAN kernel documentation — Linux CAN networking model.
• cantools — description-file parsing and signal inspection.
• canmatrix — CAN matrix conversion and inspection.
• Scapy automotive layers — automotive layer structure and packet inspection docs.

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