Teil 6 hat CAN_XL als die praktisch relevanteste Lücke zwischen IEEE 1722-2025 und dem AUTOSAR-Modul IEEE1722Tp benannt. Dieser Teil geht in die Tiefe: was genau bietet ACF_CANXL (Kapitel 9.4.18) gegenüber klassischem ACF_CAN, und warum lohnt sich der Mehraufwand für moderne Zonal-Architekturen?

Warum CAN-XL überhaupt?

CAN-XL ist die dritte Generation der CAN-Bus-Familie (nach klassischem CAN und CAN FD) — mit bis zu 2048 Byte Nutzdaten pro Frame, gegenüber 8 Byte bei klassischem CAN bzw. 64 Byte bei CAN FD. Die Motivation: in zonalen Architekturen müssen Zonal Controller zunehmend Daten bündeln, die früher über mehrere einzelne CAN-Frames verteilt waren (z. B. aggregierte Sensordaten) — CAN-XL schließt die Bandbreitenlücke zwischen klassischem CAN und Ethernet, ohne gleich auf natives Ethernet migrieren zu müssen.

CAN-XL ist selbst eine Bosch-Spezifikation, kein IEEE-1722-Konzept — IEEE 1722-2025 definiert lediglich ACF_CANXL als Tunnel-Format, um CAN-XL-Frames über ein AVTP/TSN-Backbone zu transportieren, analog zu ACF_CAN für klassisches CAN.

Neue Header-Felder gegenüber ACF_CAN

ACF_CAN vs. ACF_CANXL: neue Header-Felder
FeldBreiteBedeutung

bus_id

11 Bit (statt 5 Bit bei ACF_CAN)

Direkt der gleiche Sprung wie bei CAN_V2 (siehe Teil 8) — 2048 statt 32 mögliche Bus-IDs

VCID (Virtual CAN Network ID)

8 Bit

CAN-XL-spezifisches Konzept zur virtuellen Netzsegmentierung — mehrere logische CAN-XL-Netze können denselben physischen Bus teilen

SDT (Service Data Unit Type)

8 Bit

Beschreibt, wie die Nutzlast zu interpretieren ist — CAN-XL selbst ist bewusst nutzlast-agnostisch gehalten, SDT macht das für den Empfänger explizit

RRS, SEC

je 1 Bit

Reservierte/Kontrollbits aus dem CAN-XL-Rahmenformat selbst

priority_id

11 Bit

Priorisierung — Nachfolgekonzept der klassischen CAN-Arbitrierung, die bei CAN-XL anders funktioniert

acceptance_field

32 Bit

Ersetzt die klassische CAN-Arbitrierungs-ID als Filter-/Adressierungsfeld

transaction_num, MS, segment_num

8 / 1 / 12 Bit

Fragmentierung — ein CAN-XL-Frame mit bis zu 2048 Byte Nutzlast kann größer sein, als in ein einzelnes AVTPDU passt, und muss dann über mehrere ACF-Nachrichten segmentiert werden (MS = "More Segments", segment_num zur Reihenfolge)

Die Segmentierungsfelder (transaction_num, MS, segment_num) sind bei klassischem ACF_CAN schlicht nicht vorhanden — dort passt jeder Frame immer vollständig in eine ACF-Nachricht. Bei CAN-XL mit seiner deutlich größeren maximalen Nutzlast ist Fragmentierung ein Kernbestandteil des Formats, nicht eine Ausnahme.

ACF_CAN_XL_BRIEF: dieselbe Logik wie CAN_BRIEF

Analog zum Verhältnis ACF_CAN → ACF_CAN_BRIEF gibt es auch für CAN-XL eine Brief-Variante (ACF_CAN_XL_BRIEF, Kapitel 9.4.19): identische Feldstruktur, aber ohne den 64-Bit-Zeitstempel — VCID rückt direkt hinter den Common-Header. Für Anwendungen ohne Zeitstempel-Bedarf spart das 8 Byte pro Nachricht.

Die Faustregel aus der klassischen CAN/CAN_BRIEF-Wahl (siehe Teil 2) gilt hier unverändert: Brief-Varianten lohnen sich, wenn der Zeitstempel auf Empfängerseite ohnehin nicht ausgewertet wird — bei hochfrequenten, bandbreitenintensiven CAN-XL-Nachrichten macht sich der Unterschied stärker bemerkbar als bei klassischem CAN.

Warum das für AUTOSAR fehlt

Wie in Teil 6 eingeordnet: CAN_XL und CAN_XL_BRIEF sind neue Ergänzungen aus IEEE 1722-2025 selbst — ein AUTOSAR-Release, das vor der finalen Standardisierung dieser Kapitel spezifiziert wurde, kann sie schlicht noch nicht enthalten. Für ein Projekt, das CAN-XL-Teilnetze per ACF tunneln möchte, bleibt aktuell nur der Weg über eine proprietäre Erweiterung oder das Warten auf ein zukünftiges AUTOSAR-Release.

Zusammenfassung

AspektKernaussage

CAN-XL

Dritte CAN-Generation, bis zu 2048 Byte Nutzlast — schließt die Bandbreitenlücke zwischen CAN und Ethernet

Neue Felder gegenüber ACF_CAN

bus_id (11 statt 5 Bit), VCID, SDT, priority_id, acceptance_field, Segmentierungsfelder

Segmentierung

Kernbestandteil des Formats, nicht optional — CAN-XL-Frames können größer sein als eine einzelne ACF-Nachricht

CAN_XL_BRIEF

Gleiche Logik wie CAN_BRIEF — kein Zeitstempel, kompakterer Header

Status in AUTOSAR

Nicht spezifiziert (Stand R24-11) — reine Frage des Release-Timings, keine grundsätzliche Unvereinbarkeit

Weiter in der Serie: IEEE 1722 Teil 8 — CAN_V2, CAN_BRIEF_V2 & LIN_V2