Teil 6 hat CAN_V2, CAN_BRIEF_V2 und LIN_V2 als neue, in AUTOSAR nicht enthaltene Formatversionen aus IEEE 1722-2025 genannt. Dieser Teil klärt, was sich bei den V2-Formaten konkret ändert — und korrigiert eine Ungenauigkeit aus Teil 6: CAN_V2 und CAN_BRIEF_V2 sind in Open1722 längst implementiert, nur LIN_V2 nicht.

Korrektur gegenüber Teil 6: dort wurden CAN_V2/CAN_BRIEF_V2/LIN_V2 pauschal als "noch nicht implementiert" bezeichnet. Tatsächlich liefert Open1722 bereits CanV2.h und CanBriefV2.h — nur für LIN_V2 existiert (Stand dieser Recherche) noch keine Implementierung, weder in Open1722 noch in AUTOSAR.

ACF_CAN_V2: derselbe Inhalt, mehr Bus-IDs

ACF_CAN vs. ACF_CAN_V2: Quadlet 0 im Vergleich

Der Unterschied zwischen ACF_CAN (Kapitel 9.4.1, seit 2016) und ACF_CAN_V2 (Kapitel 9.4.3, neu 2025) ist überraschend klein — und genau deshalb praktisch relevant:

FeldACF_CANACF_CAN_V2

bus_id

5 Bit (0-31)

11 Bit (0-2047)

CAN-Identifier

29 Bit

29 Bit (unverändert)

Zeitstempel

64 Bit

64 Bit (unverändert)

BRS/FDF/ESI-Flags

Quadlet 0

Quadlet 3 (verschoben, um Platz für bus_id zu schaffen)

Alle inhaltlichen Fähigkeiten (CAN-Identifier-Breite, Zeitstempel, CAN-FD-Flags) bleiben zwischen ACF_CAN und ACF_CAN_V2 identisch — es handelt sich nicht um ein grundlegend neues Protokoll, sondern um eine gezielte Bit-Layout-Änderung mit genau einem Ziel: mehr adressierbare Bus-IDs.

5 Bit (32 Bus-IDs) reichen für die meisten Einzelfahrzeug-Projekte mit einer überschaubaren Anzahl CAN-Teilnetze. Der Bedarf für 2048 Bus-IDs entsteht eher in Szenarien, in denen ein zentrales Gateway viele unterschiedliche Fahrzeugvarianten oder -plattformen mit jeweils eigener CAN-Teilnetz-Zählung über ein gemeinsames TSN-Backbone bedient — ein Szenario, das mit wachsender Plattformkonsolidierung realistischer wird.

ACF_CAN_BRIEF_V2: die kompakte Variante

Analog zu ACF_CAN_BRIEF gegenüber ACF_CAN verzichtet ACF_CAN_BRIEF_V2 (Kapitel 9.4.4) auf den Zeitstempel — mit derselben erweiterten 11-Bit-Bus-ID wie ACF_CAN_V2. Für ereignisgesteuerte CAN-Nachrichten ohne Zeitbezug (siehe die TSCF/NTSCF-Einordnung in Teil 2) ist das die naheliegende Wahl, sobald mehr als 32 Bus-IDs gebraucht werden.

LIN_V2: definiert, aber noch nirgends umgesetzt

Der Standard sieht mit LIN_V2 (0x23) konsequenterweise auch eine überarbeitete LIN-Formatversion vor — analog zur CAN-Familie. Zum Zeitpunkt dieser Recherche existiert dafür aber weder in Open1722 noch in AUTOSAR eine Implementierung. Das ist ein Unterschied zu CAN_V2/CAN_BRIEF_V2, die zumindest in Open1722 bereits nutzbar sind.

Wer auf LIN_V2 plant, sollte das nicht mit einer bereits verfügbaren Referenzimplementierung verwechseln — anders als bei CAN_XL (Teil 7), wo zumindest Open1722 als Lernumgebung dient, gibt es für LIN_V2 aktuell keinen Code zum Nachvollziehen, nur den Typ-Eintrag im Standard selbst.

Zusammenfassung

AspektKernaussage

ACF_CAN_V2

Identischer Inhalt wie ACF_CAN, aber 11 statt 5 Bit Bus-ID (2048 statt 32 mögliche Werte) — in Open1722 bereits implementiert

ACF_CAN_BRIEF_V2

Wie ACF_CAN_V2, aber ohne Zeitstempel — für ereignisgesteuerte Nachrichten mit vielen Bus-IDs

LIN_V2

Im Standard definiert, aber (Stand dieser Recherche) in keiner der beiden Implementierungen umgesetzt

Praktische Relevanz

Steigt mit der Anzahl unterschiedlicher CAN-Teilnetze, die ein zentrales Gateway gleichzeitig bedienen muss

Weiter in der Serie: IEEE 1722 Teil 9 — Generic & Abbreviated Byte Bus (GBB/ABB)