Dieser Post eröffnet die Serie zum AUTOSAR-Modul AUTOSAR_CP_SWS_IEEE1722Transport
und richtet sich an alle, die bereits mit den bestehenden
EthSwt-/EthTrcv-Serien vertraut sind
und jetzt verstehen wollen, was AVTP-Streaming über ein TSN-Ethernet-Backbone
konkret bedeutet.
Der vollständige IEEE-1722-2025-Text ist kostenpflichtig (IEEE Standards Store) und nicht frei zugänglich. Als verlässliche, frei zugängliche Sekundärquelle dient in dieser Serie COVESA/Open1722 — eine BSD-lizenzierte Open-Source-Referenzimplementierung, die im README explizit gegen konkrete Tabellen des Standards zitiert. |
Was ist AVTP?
AVTP (Audio Video Transport Protocol) ist das Kernprotokoll aus IEEE 1722 — ursprünglich für professionelles Audio/Video-Streaming über Ethernet entwickelt (AVB/TSN-Umfeld), inzwischen aber auch als Transportmechanismus für Feldbus-Tunneling (ACF, siehe Teil 2 dieser Serie) im automotive Kontext relevant.
Der Grundgedanke: statt Audio-, Video- oder Sensordaten über klassische IP-basierte Protokolle zu übertragen, definiert AVTP ein schlankes, auf Layer 2 aufsetzendes Rahmenformat mit eingebautem Zeitstempel — genau das, was für deterministische, latenzarme Übertragung in einem TSN-Netz gebraucht wird.
AVTP ist kein Ersatz für TSN selbst, sondern baut auf den TSN-Mechanismen auf. Stream Identification (Teil aus der EthSwt-Serie) und Time-Aware Shaping/Frame Preemption (ebenfalls dort behandelt) sorgen dafür, dass ein AVTP-Stream im Switch überhaupt deterministisch weitergeleitet wird — AVTP selbst definiert nur das Rahmenformat und den Zeitstempel-Mechanismus auf Sender-/Empfängerseite. |
AVTPDU-Formate im Überblick
Alle AVTP-Pakete (AVTPDUs — AVTP Data Units) teilen sich einen gemeinsamen Header, unterscheiden sich aber im nachfolgenden Payload-Format:
| Format | Zweck |
|---|---|
AAF (Audio AVTP Format) | Unkomprimierte Audiosamples (PCM), z. B. für Mikrofon-/Lautsprecher-Streams im Fahrzeug |
CRF (Clock Reference Format) | Verteilt eine Taktreferenz zwischen Sender und Empfänger — wichtig, wenn Audio-/Video-Streams synchron zueinander laufen müssen, aber keine gemeinsame Hardware-Uhr haben |
IIDC (61883_IIDC — IEC 61883/IIDC über AVTP) | Videodaten nach IEC 61883/IIDC-Kapselung, z. B. für Kamera-Streams (Rückfahrkamera, Surround-View) |
RVF (Raw Video Format) | Unkomprimierte Rohvideodaten — anderes Kapselungsformat als IIDC, ohne Kompressions-Latenz und -Artefakte |
Das AUTOSAR-Modul |
Für ein automotive Projekt sind IIDC (Kamera-Streams) und AAF (Audio) die in
der Praxis am häufigsten relevanten Formate. CRF wird meist implizit über den
|
Ein weiteres AVTPDU-Format, das für automotive Anwendungen besonders relevant ist, aber nicht in diese vier Kategorien fällt, ist ACF (AVTP Control Format) — der Mechanismus zum Tunneln von Feldbus-Daten (CAN, CAN-XL, FlexRay, LIN, MOST) über ein TSN-Backbone. ACF bekommt in Teil 2 dieser Serie einen eigenen, ausführlichen Abschnitt.
Natives Ethernet-Framing vs. optionale UDP-Kapselung
AVTPDUs können auf zwei Arten transportiert werden:
| Nativ (EtherType 0x22F0) | UDP-Kapselung | |
|---|---|---|
Overhead | Minimal — nur Ethernet-Header + AVTPDU | Zusätzlich IP- und UDP-Header |
Routbarkeit | Nur innerhalb desselben L2-Segments | Über IP-Netze hinweg routbar |
Determinismus | Direkt von TSN-Mechanismen (Stream Identification, Time-Aware Shaping) profitierend | TSN-Garantien gehen an einer L3-Grenze verloren, sofern das IP-Netz selbst nicht TSN-fähig ist |
Typischer Einsatz | Innerhalb eines TSN-Backbones (der Normalfall im Fahrzeug) | Wenn ein Stream eine geroutete Grenze überqueren muss (z. B. Richtung Diagnose-Tester außerhalb des Fahrzeugs) |
Innerhalb eines Fahrzeug-TSN-Backbones ist natives Framing der Normalfall — UDP-Kapselung sollte nicht standardmäßig gewählt werden, nur weil sie „flexibler wirkt". Jede zusätzliche Kapselungsschicht kostet Determinismus, den die vorgelagerten TSN-Mechanismen gerade aufgebaut haben. |
Zusammenspiel mit TSN
AVTP-Streaming funktioniert nur zuverlässig im Zusammenspiel mit den bereits in der EthSwt-Serie behandelten TSN-Mechanismen:
| Mechanismus | Rolle für AVTP |
|---|---|
Ordnet einem AVTP-Stream (identifiziert über die | |
Reserviert Zeitfenster im Switch, in denen der AVTP-Stream garantiert weitergeleitet wird — der eigentliche Mechanismus hinter der „deterministischen" Zustellung |
Ohne diese beiden TSN-Bausteine bleibt AVTP ein reines Rahmenformat ohne Echtzeit-Garantie — die eigentliche Determinismus-Zusage kommt aus dem Switch, nicht aus dem AVTPDU-Header selbst.
Überblick über die Serie
Dieser Post legt das Fundament. Die folgenden Teile bauen darauf auf:
| Teil | Thema |
|---|---|
1 (dieser Post) | Grundlagen — was AVTP ist, AVTPDU-Formate, natives Framing vs. UDP, Zusammenspiel mit TSN |
ACF_CAN und ACF_LIN im AUTOSAR-Modul | |
Container-Struktur des | |
Ein Kamera-Stream (IIDC) und ein CAN-Teilnetz per ACF.CAN über einen TSN-Backbone tunneln — nachvollziehbar mit Open1722 | |
5 — Praxisprojekt: ACF-CAN-Kernel-Modul zwischen zwei echten BeagleBone Black | Das Open1722-ACF-CAN-Kernel-Modul cross-kompilieren, laden und zwischen zwei physischen BeagleBone Black über Ethernet testen |
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
AVTP | Schlankes, Layer-2-basiertes Rahmenformat mit eingebautem Zeitstempel für deterministisches Audio-/Video-/Sensor-Streaming |
AVTPDU-Formate | AAF (Audio), CRF (Taktreferenz), IIDC (Video), RVF (Rohvideo) — plus ACF als eigener Subtype für Feldbus-Tunneling (Teil 2) |
Framing | Natives Ethernet-Framing (EtherType 0x22F0) ist der Normalfall im Fahrzeug-Backbone, UDP-Kapselung nur bei Bedarf für Routing über IP-Grenzen |
Zusammenspiel mit TSN | Stream Identification und Time-Aware Shaping liefern die eigentliche Determinismus-Garantie — AVTP definiert nur das Rahmenformat |
Nächster Schritt | Teil 2 zeigt ACF im Detail — den Mechanismus zum Tunneln von CAN/LIN (im AUTOSAR-Modul) bzw. weiteren Feldbussen (im allgemeinen Standard) über dasselbe TSN-Backbone |
Weiter in der Serie: IEEE 1722 Teil 2 — ACF (AVTP Control Format)