Part 6 called out CAN_XL as the practically most relevant gap between IEEE 1722-2025 and the AUTOSAR module IEEE1722Tp. This part goes deeper: what exactly does ACF_CANXL (chapter 9.4.18) offer over classic ACF_CAN, and why is the extra complexity worth it for modern zonal architectures?

Why CAN-XL in the first place?

CAN-XL is the third generation of the CAN bus family (after classic CAN and CAN FD) — with up to 2048 bytes of payload per frame, compared to 8 bytes for classic CAN or 64 bytes for CAN FD. The motivation: in zonal architectures, zonal controllers increasingly need to bundle data that used to be spread across multiple individual CAN frames (e.g. aggregated sensor data) — CAN-XL closes the bandwidth gap between classic CAN and Ethernet, without having to migrate straight to native Ethernet.

CAN-XL itself is a Bosch specification, not an IEEE 1722 concept — IEEE 1722-2025 merely defines ACF_CANXL as a tunnel format for transporting CAN-XL frames over an AVTP/TSN backbone, analogous to ACF_CAN for classic CAN.

New header fields compared to ACF_CAN

ACF_CAN vs. ACF_CANXL: new header fields
FieldWidthMeaning

bus_id

11 bits (vs. 5 bits for ACF_CAN)

The exact same jump as for CAN_V2 (see Part 8) — 2048 instead of 32 possible bus IDs

VCID (Virtual CAN Network ID)

8 bits

A CAN-XL-specific concept for virtual network segmentation — multiple logical CAN-XL networks can share the same physical bus

SDT (Service Data Unit Type)

8 bits

Describes how to interpret the payload — CAN-XL itself is deliberately payload-agnostic, SDT makes that explicit for the receiver

RRS, SEC

1 bit each

Reserved/control bits from the CAN-XL frame format itself

priority_id

11 bits

Prioritization — the successor concept to classic CAN arbitration, which works differently for CAN-XL

acceptance_field

32 bits

Replaces the classic CAN arbitration ID as the filter/addressing field

transaction_num, MS, segment_num

8 / 1 / 12 bits

Segmentation — a CAN-XL frame with up to 2048 bytes of payload can be larger than what fits into a single AVTPDU, and then has to be segmented across multiple ACF messages (MS = "More Segments", segment_num for ordering)

The segmentation fields (transaction_num, MS, segment_num) simply don’t exist for classic ACF_CAN — there, every frame always fits completely into one ACF message. For CAN-XL, with its considerably larger maximum payload, segmentation is a core part of the format, not an edge case.

ACF_CAN_XL_BRIEF: the same logic as CAN_BRIEF

Analogous to the ACF_CAN → ACF_CAN_BRIEF relationship, there’s also a Brief variant for CAN-XL (ACF_CAN_XL_BRIEF, chapter 9.4.19): identical field structure, but without the 64-bit timestamp — VCID moves directly behind the common header. For applications that don’t need a timestamp, that saves 8 bytes per message.

The rule of thumb from the classic CAN/CAN_BRIEF choice (see Part 2) still applies unchanged: Brief variants pay off when the timestamp isn’t evaluated on the receiving side anyway — for high-frequency, bandwidth-intensive CAN-XL messages, that difference is felt more strongly than for classic CAN.

Why this is missing from AUTOSAR

As classified in Part 6: CAN_XL and CAN_XL_BRIEF are new additions from IEEE 1722-2025 itself — an AUTOSAR release specified before these chapters were finally standardized simply can’t contain them yet. For a project that wants to tunnel CAN-XL subnets via ACF, the only current option is a proprietary extension or waiting for a future AUTOSAR release.

Summary

AspectKey takeaway

CAN-XL

Third CAN generation, up to 2048 bytes of payload — closes the bandwidth gap between CAN and Ethernet

New fields vs. ACF_CAN

bus_id (11 vs. 5 bits), VCID, SDT, priority_id, acceptance_field, segmentation fields

Segmentation

A core part of the format, not optional — CAN-XL frames can be larger than a single ACF message

CAN_XL_BRIEF

Same logic as CAN_BRIEF — no timestamp, more compact header

Status in AUTOSAR

Not specified (as of R24-11) — purely a matter of release timing, not a fundamental incompatibility

Next in the series: IEEE 1722 Part 8 — CAN_V2, CAN_BRIEF_V2 & LIN_V2