Die vorherigen fünf Teile haben AVTP, ACF und die ARXML-Konfiguration des AUTOSAR-Moduls IEEE1722Tp behandelt — und dabei wiederholt festgestellt, dass AUTOSAR nur einen Ausschnitt dessen implementiert, was der allgemeine IEEE-1722-2025-Standard tatsächlich beschreibt. Dieser Teil macht diesen Ausschnitt explizit: welche AVTPDU-Subtypes und ACF-Nachrichtentypen kennt der Standard, die im AUTOSAR-Modul (Stand R24-11) schlicht nicht vorkommen?

Grundlage sind die Header-Dateien aus COVESA/Open1722 (include/avtp/CommonHeader.h, include/avtp/acf/AcfCommon.h und die einzelnen ACF-Format-Header), die jeweils explizit gegen konkrete Kapitel des IEEE-1722-2025-Texts zitieren — die zuverlässigste frei zugängliche Quelle, da der Volltext des Standards selbst kostenpflichtig ist (siehe Teil 1).

AVTPDU-Subtypes: voller Standard vs. AUTOSAR-Modul

AVTPDU-Subtypes: voller Standard vs. AUTOSAR-Modul
SubtypeWertIm AUTOSAR-Modul?

61883_IIDC

0x00

Ja — IEEE1722TpStreamIIDC

MMA_STREAM

0x01

Nein

AAF

0x02

Ja — IEEE1722TpStreamAAF

CVF

0x03

Nein — siehe Teil 1: AUTOSAR nutzt für Video ausschließlich 61883_IIDC

CRF

0x04

Ja — IEEE1722TpStreamCRF

TSCF

0x05

Ja — als Rahmen für ACF-Nachrichten (siehe Teil 2)

SVF

0x06

Nein

RVF

0x07

Ja — IEEE1722TpStreamRVF

AEF_CONTINUOUS / VSF_STREAM / EF_STREAM

0x6E / 0x6F / 0x7F

Nein

NTSCF

0x82

Ja — als Rahmen für ACF-Nachrichten (siehe Teil 2)

ESCF / EECF / AEF_DISCRETE

0xEC / 0xED / 0xEE

Nein

ADP / AECP / ACMP / MAAP

0xFA / 0xFB / 0xFC / 0xFE

Nein

ADP, AECP, ACMP und MAAP sind keine Streaming-Formate, sondern die AVDECC-Steuerprotokolle (Discovery, Enumeration/Control, Connection Management, MAC-Adressvergabe) aus dem Consumer-AV-Umfeld (professionelles Audio/Video-Networking). Dass AUTOSAR diese nicht abbildet, ist keine Lücke im eigentlichen Sinn — automotive Steuergeräte werden nicht per AVDECC-Discovery konfiguriert, sondern über ARXML zur Entwurfszeit. Die übrigen Lücken (CVF, SVF, MMA_STREAM, AEF_*, VSF_STREAM, EF_STREAM, ESCF, EECF) sind dagegen echte Streaming-Formate, die AUTOSAR schlicht (noch) nicht spezifiziert.

ACF-Nachrichtentypen: Table 22 im Detail

ACF-Typen: AUTOSAR-Subset vs. voller Standard

Die ACF-Typenliste (Avtp_AcfMsgType_t in AcfCommon.h, zitiert gegen "IEEE Std 1722-2025 table 22") ist deutlich umfangreicher, als Teil 2 vermuten ließ. Vier Gruppen lassen sich unterscheiden:

Im AUTOSAR-Modul

TypWert

CAN (+ CAN_BRIEF)

0x1 (+ 0x2)

LIN

0x3

Schon in IEEE 1722-2016, aber nicht in AUTOSAR

TypWertBemerkung

FLEXRAY

0x0

Von Open1722 implementiert (FlexRay.h), von AUTOSAR IEEE1722Tp nicht

MOST

0x4

Ebenfalls seit 2016 im Standard, ebenfalls nicht in AUTOSAR

GPC (Generic Pipe Content)

0x5

Generischer Tunnel für beliebige Pipe-/Stream-Daten ohne eigenes Format

SENSOR / SENSOR_BRIEF

0x8 / 0x9

Generisches Sensor-Datenpaket-Tunneling

Neu in IEEE 1722-2025, nicht in AUTOSAR

Das sind die eigentlich interessanten Ergänzungen — Formate, die es in der 2016er-Fassung noch gar nicht gab:

TypWertBemerkung

CAN_XL (Kapitel 9.4.18)

0x11

Tunnelt CAN-XL-Frames — inklusive VCID (Virtual CAN Network ID) und SEC-Feld, beides CAN-XL-spezifische Konzepte, die es bei klassischem CAN/CAN FD nicht gibt (Details in Teil 7)

CAN_XL_BRIEF (Kapitel 9.4.19)

0x12

Reduzierter Header für CAN-XL, analog zu CAN_BRIEF bei klassischem CAN

CAN_V2 (Kapitel 9.4.3) / CAN_BRIEF_V2 (Kapitel 9.4.4)

0x21 / 0x22

Neue, überarbeitete Formatversionen mit deutlich breiterem Bus-ID-Feld (11 statt 5 Bit) — von Open1722 bereits implementiert (CanV2.h, CanBriefV2.h), siehe Teil 8

LIN_V2

0x23

Im Typ-Enum des Standards vorgesehen, aber (Stand dieser Recherche) noch in keiner der beiden Implementierungen (Open1722, AUTOSAR) umgesetzt

BYTE_BUS / GBB (Kapitel 9.4.14)

0xD

Generic Byte Bus — Tunnel für beliebige Byte-Array-Protokolle mit Request/Response-Semantik (siehe Teil 9)

BYTE_BUS_BRIEF / ABB (Kapitel 9.4.15)

0xE

Abbreviated Byte Bus — Variante von GBB ohne Zeitstempel-Feld (siehe Teil 9)

GISF (Kapitel 18)

0xC

Generic Image Sensor Format — eigenes Kapitel im Standard, für Rohbilddaten direkt vom Bildsensor (nicht zu verwechseln mit RVF oder 61883_IIDC, die bereits komprimierte/aufbereitete Videoframes transportieren)

CAN_XL ist die praktisch relevanteste Lücke für ein modernes Zonal-Architektur-Projekt: CAN-XL selbst (bis zu 2048 Byte Nutzdaten pro Frame, VCID für virtuelle Netzsegmentierung) gewinnt in neuen E/E-Architekturen an Bedeutung, gerade weil es die Brücke zwischen klassischem CAN und Ethernet-Bandbreiten schlägt. Ein AUTOSAR-Projekt, das CAN-XL-Teilnetze per ACF tunneln will, kann das aktuell nicht über den Standardmechanismus IEEE1722Tp tun.

Weder in Open1722 noch in AUTOSAR implementiert

TypWert

SERIAL

0x6

PARALLEL

0x7

AECP (als ACF-Typ, zu unterscheiden von der gleichnamigen AVTPDU-Subtype-Nutzung)

0xA

ANCILLARY

0xB

I2C / I2C_BRIEF

0xF / 0x10

CHECKSUM / CRC

0x76 / 0x77

Herstellerspezifisch (USER_FIRST–USER_LAST)

0x78–0x7F

Der herstellerspezifische Bereich (0x78–0x7F) ist genau dort, wo Community-Erweiterungen jenseits des Standards ansetzen — COVESA pflegt in Open1722 z. B. ein eigenes VSS-ACF-Format (Vehicle Signal Specification, unter include/avtp/acf/custom/) für das Tunneln von VSS-Signalen. Das ist explizit kein Teil von IEEE 1722-2025 selbst, sondern eine COVESA-eigene Konvention innerhalb des dafür vorgesehenen Custom-Bereichs.

Warum diese Lücken (wahrscheinlich) bestehen

Keine der genannten Lücken ist überraschend, wenn man sich den Entstehungskontext von AUTOSAR CP R24-11 vor Augen führt:

GrundBetrifft

Release-Timing

CAN_XL, CAN_XL_BRIEF, GBB, ABB, GISF sind Ergänzungen aus IEEE 1722-2025 — ein AUTOSAR-Release, das vor der endgültigen Standardisierung dieser Kapitel spezifiziert wurde, kann sie schlicht noch nicht enthalten

Fehlender automotive Anwendungsfall (bisher)

SERIAL, PARALLEL, I2C adressieren eher generische Embedded-Bus-Tunnel als etablierte Fahrzeug-Feldbusse — geringerer Druck, sie kurzfristig in ein automotive BSW-Modul aufzunehmen

Kein automotive Anwendungsfall (grundsätzlich)

ADP/AECP/ACMP/MAAP gehören zum AVDECC-Ökosystem für Consumer-AV-Geräte-Discovery — ARXML-basierte Entwurfszeit-Konfiguration macht Laufzeit-Discovery in einem Steuergerät überflüssig

Nichts davon ist eine Garantie, dass ein zukünftiges AUTOSAR-Release diese Formate ergänzt — es ist lediglich eine plausible Einordnung, warum sie aktuell fehlen. Wer auf einen dieser Typen (allen voran CAN_XL) angewiesen ist, sollte das explizit bei AUTOSAR als Erweiterungswunsch adressieren, nicht auf eine automatische Aufnahme im nächsten Release hoffen.

Zusammenfassung

AspektKernaussage

AVTPDU-Subtypes

AUTOSAR deckt 6 von ~19 Subtypes ab (61883_IIDC, AAF, CRF, TSCF, RVF, NTSCF) — die AVDECC-Subtypes sind für automotive irrelevant, die übrigen (CVF, SVF, MMA_STREAM, …​) echte Lücken

ACF-Typen

AUTOSAR deckt nur CAN/CAN_BRIEF/LIN ab — FlexRay/MOST/GPC/ Sensor (seit 2016) und CAN-XL/GBB/ABB/GISF (neu seit 2025) fehlen komplett

Praktisch relevanteste Lücke

CAN_XL — für moderne Zonal-Architekturen mit höherem Bandbreitenbedarf pro Feldbus-Nachricht

Was AUTOSAR nicht braucht

Die AVDECC-Steuerprotokolle (ADP/AECP/ACMP/MAAP) — Discovery zur Laufzeit widerspricht dem ARXML-Entwurfszeit-Modell

Die folgenden drei Teile gehen auf die praktisch relevantesten Lücken im Detail ein: CAN-XL, CAN_V2/LIN_V2 und Generic/Abbreviated Byte Bus.

Weiter in der Serie: IEEE 1722 Teil 7 — CAN-XL & CAN-XL Brief