CAN XL¶

Third-generation CAN family member with much larger payloads and service-oriented aspirations.

Identity¶

Third-generation CAN family member with much larger payloads and service-oriented aspirations.

What This Protocol Teaches¶

• CAN XL is CAN after the software-defined vehicle starts making data demands.
• It teaches how to inspect XL frame shape, payload length up to 2048 bytes, service data unit concept without mistaking field extraction for meaning.
• It keeps observer inference separate from system truth.

Operational Context¶

CAN XL appears in automotive contexts and is modeled in the atlas at the physical, data-link layer(s). The binder treats it as an inspection surface: what evidence appears, what timing matters, and what outside authority is required before assigning meaning.

draft-structure-only: this is not yet a final-copy binder page. It has an atlas-grounded teaching hook and source notes, but still needs a stronger worked trace, page-specific ambiguity case, and reviewer-validated visual before promotion.

A Concrete Artifact¶

# synthetic CAN XL frame summary
prio=0x123 vcid=2 sdt=0x05 payload_len=128 acceptance=teaching-only

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

Worked Decode¶

1. Treat prio=0x123 as arbitration-priority-like evidence in the synthetic frame summary.
2. vcid=2 and sdt=0x05 are classification fields, not engineering values.
3. payload_len=128 teaches that CAN XL changes payload scale relative to Classical CAN and CAN FD.
4. acceptance=teaching-only explicitly prevents the artifact from becoming a conformance claim.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

Timing and authority depend on the data-bus role: scheduled, polled, arbitrated, transmitted, or logged evidence should not be read as the same kind of truth. Semantic authority is external to the raw artifact unless the artifact is itself a description or capture format; even then, provenance determines whether the description should be trusted.

Bytes rarely explain themselves. Name the source that defines meaning before naming engineering values: standard metadata, label table, DBC, PGN/SPN definition, object dictionary, register map, DID catalog, LDF, ARXML, channel metadata, or vendor profile.

Failure And Ambiguity¶

• CAN XL fields can be mistaken for CAN FD extensions when the frame family is not established.
• Payload length and service-data type do not name application values.
• Public summaries can confirm scope but not substitute for standard authority.

Observer Lesson¶

A passive observer can usually infer artifact boundaries, repeated structure, cadence, missingness, and candidate state transitions. The observer usually cannot prove physical truth, application intent, complete system state, or engineering-unit meaning without semantic authority and timing provenance.

Python Model¶

No current runtime example is claimed for this draft page. Keep reader claims at the artifact and source level until a separate implementation plan adds a tested model.

Local Teaching Notes¶

The artifact and diagrams are synthetic teaching material. The page intentionally omits conformance timing tables, electrical design detail, proprietary configuration, and exhaustive standard behavior.

Source Confidence¶

Source confidence is medium for scope and terminology, with semantic claims limited to public metadata, public source notes, and synthetic teaching artifacts.

Source Notes¶

References¶

Public Sources¶

• ISO
• ISO 11898-1 Road vehicles — Controller area network (CAN) — Data link layer and physical coding sublayer — canonical-standard.
• CAN in Automation
• CAN XL overview — official-public.
• Kvaser
• CAN protocol tutorial — vendor-tutorial.
• Tooling references
• python-can — CAN log inspection and offline lab context.