CAN FD¶

This page teaches how CAN FD keeps CAN arbitration while changing payload length and data-phase timing evidence.

A Concrete Artifact¶

# synthetic passive CAN FD frame
0x18daf110  [extended fd brs dlc=9]  10 0a 62 f1 90 12 34 56 78 9a bc de

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

Inspection Trap¶

A CAN FD frame can look like "just a bigger CAN frame." That is only partly true. The identifier still participates in CAN arbitration, but the FD flag, bit-rate switch flag, error-state indicator, and DLC coding add evidence that a Classical CAN decoder can misread or flatten.

The safer claim is frame-level: a passive observer can describe the identifier, FD metadata, DLC-derived payload length, payload bytes, and timing shape. Signal names, diagnostic service meaning, and application truth still require a DBC, diagnostic definition, profile, or other semantic authority.

Worked Decode¶

1. 0x18daf110 is shown as an extended 29-bit identifier in this teaching artifact.
2. The fd marker says the frame is CAN FD, not Classical CAN.
3. The brs marker says the captured metadata indicates a bit-rate switch into the data phase.
4. DLC code 9 maps to 12 payload bytes in the CAN FD DLC table; it is not a literal byte count above eight.
5. The payload begins 10 0a 62 f1 90 ..., which looks diagnostic-shaped in this toy example, but CAN FD itself does not define that application meaning.
6. The frame metadata supports an observer claim about CAN FD use and payload length. It does not prove which node originated the frame, whether a receiver used it, or what machine state the bytes represent.

What The Evidence Supports¶

The artifact supports a frame-level claim: the observer saw an extended CAN FD data frame with bit-rate switch metadata, DLC code 9, and twelve payload bytes. It also supports a bus-load and tooling question: a Classical CAN-only pipeline may truncate, reject, or mislabel this evidence.

The frame can also support a handoff into a higher-layer page. If the surrounding capture shows ISO-TP or UDS context, the payload bytes may become transport or diagnostic evidence there. That authority is not created by the CAN FD frame.

What The Evidence Does Not Support¶

The artifact does not prove signal meaning, diagnostic success, ECU identity, physical state, freshness beyond the observed timestamp, or application consumption. Bit-rate switch metadata is timing evidence, not permission to interact with a bus.

The payload length being larger than Classical CAN does not make a DBC, DID catalog, or vendor profile optional. Larger opaque bytes are still opaque bytes.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

CAN FD separates arbitration-phase evidence from data-phase evidence. Arbitration still decides which frame wins the bus; bit-rate switching changes how long the payload occupies the bus. A bus-load calculation that ignores BRS can overstate or understate observed occupancy.

CAN FD frame metadata is not semantic authority. Payload meaning comes from a DBC, transport/application protocol, vendor profile, or documented integration source.

Failure And Ambiguity¶

• Classical CAN tooling can truncate or mislabel CAN FD frames.
• Treating DLC as a byte count above eight gives the wrong payload length.
• Ignoring BRS changes bus-load and timing interpretations.
• A larger payload can hide transport/application boundaries that still need their own authority.
• A valid frame-level CRC does not prove freshness, physical truth, or application consumption.

Python Model¶

The current package exposes a concrete CAN FD frame model for passive inspection:

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

from schoolbus.protocols.can import CanFdFrame

frame = CanFdFrame(
    identifier=0x18DAF110,
    data=bytes.fromhex("10 0a 62 f1 90 12 34 56 78 9a bc de"),
    extended=True,
    bit_rate_switch=True,
)

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

The model exposes identifier width, DLC mapping, payload length, BRS/ESI metadata, and payload bytes. It does not assign signal meaning or provide bus I/O.

The payload is synthetic. The page omits exact bit stuffing, precise inter-frame spacing, transceiver design, termination, oscillator tolerance, CRC-polynomial detail, 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.
• Bosch
• CAN FD protocol
  • protocol-author overview.
• Kvaser
• CAN protocol tutorial - vendor tutorial.
• Tooling references
• python-can - CAN log inspection and offline lab context.
• can-utils - CAN capture/log-format context.
• cantools - description-file parsing and signal inspection.

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