Die vorherigen Teile haben AVTP, ACF und die ARXML-Konfiguration konzeptionell und strukturell behandelt. Dieser Teil zeigt zwei komplette End-to-End-Beispiele — beide nachvollziehbar mit den echten Beispielprogrammen aus Open1722.

Beispiel 1: Ein Kamera-Stream von der Aufnahme bis zur Auslieferung

Kamera-Stream: Aufnahme bis deterministische Auslieferung

Wie in Teil 1 festgehalten: das AUTOSAR-Modul IEEE1722Tp implementiert für Video-Streaming den Subtype IEEE1722TpStreamIIDC (IEC 61883/IIDC), nicht CVF. Open1722 bietet aktuell kein eigenes IIDC-Beispiel, sondern nur cvf-talker/cvf-listener für den allgemeinen CVF-Subtype des IEEE-1722-Standards. Das End-to-End-Prinzip (PTP-Synchronisation, TSN-Determinismus, zeitstempelbasierte Präsentation) ist identisch — der konkrete Payload-Subtype im Wire-Format unterscheidet sich. Die folgende Anleitung nutzt daher cvf-talker/cvf-listener als konzeptionelle Nachvollzieh-Übung, nicht als 1:1-Abbild des AUTOSAR-Moduls.

Sender-Seite: Video einlesen und als AVTPDU senden

cvf-talker liest einen H.264-Byte-Stream von stdin und verpackt ihn in CVF-AVTPDUs. In der Praxis kombiniert man das mit GStreamer, um eine echte Videoquelle (oder zum Testen ein synthetisches Testbild) einzuspeisen:

gst-launch-1.0 -e -q videotestsrc pattern=ball \
  ! video/x-raw,width=192,height=144 ! x264enc \
  ! video/x-h264,stream-format=byte-stream ! filesink location=/dev/stdout \
  | cvf-talker <args>

Voraussetzung für einen sauberen Stream: der Systemtakt muss mit der PTP-Hardware-Uhr (PHC) der NIC synchronisiert sein, und diese wiederum mit der PTP-Zeit im Netzwerk (ptp4l, phc2sys) — sonst stimmt der AVTP-Zeitstempel nicht mit den anderen Netzteilnehmern überein und die "deterministische" Zustellung verliert ihre Grundlage.

Switch-Seite: Stream Identification + Time-Aware Shaping

Damit der Stream im Switch überhaupt deterministisch weitergeleitet wird, braucht es die bereits in der EthSwt-Serie behandelten Mechanismen:

Ohne diese beiden Mechanismen im Switch bleibt der Stream ein normales Best-Effort-Paket — die deterministische Zustellung ist eine Switch-Eigenschaft, keine reine Endpunkt-Eigenschaft.

Empfänger-Seite: Präsentation zum richtigen Zeitpunkt

cvf-listener empfängt die CVF-AVTPDUs, wartet bis zur im Zeitstempel codierten Presentation Time und gibt die Videodaten erst dann aus:

cvf-listener <args> | gst-launch-1.0 filesrc location=/dev/stdin \
  ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

Das bewusste Abwarten der Presentation Time ist der eigentliche Witz an AVTP-Streaming: der Empfänger zeigt das Bild nicht sofort bei Ankunft, sondern exakt zu dem im Header codierten Zeitpunkt — das ist, was mehrere synchron laufende Streams (z. B. Surround-View aus vier Kameras) überhaupt erst synchron hält.

Beispiel 2: Ein CAN-Teilnetz transparent per ACF.CAN tunneln

CAN-Teilnetz transparent per ACF.CAN über TSN-Backbone tunneln

Dieses Beispiel ist — anders als das Kamera-Beispiel — eine direkte Entsprechung zum AUTOSAR-Subtype ACF_CAN aus Teil 2, da Open1722 hierfür ein eigenes, passendes Beispiel mitbringt: acf-can-talker, acf-can-listener und acf-can-bridge.

Sender-Seite: CAN-Frame einlesen und tunneln

# Liest CAN-Frames von einem SocketCAN-Interface (z. B. can0) und tunnelt
# sie als ACF_CAN-Nachrichten über das angegebene Ethernet-Interface
acf-can-talker <ethernet-interface> <can-interface> <destination-mac>

Empfänger-Seite: ACF_CAN wieder in CAN zurückverwandeln

# Empfängt ACF_CAN-Nachrichten und spielt sie auf einem lokalen
# SocketCAN-Interface wieder ein
acf-can-listener <ethernet-interface> <can-interface>

Beide Kommandos zusammen ergeben eine unidirektionale Brücke (CAN-Bus A → CAN-Bus B). Für bidirektionalen Verkehr bietet Open1722 zusätzlich acf-can-bridge, das ein lokales CAN-Interface direkt und in beide Richtungen an einen ACF-Stream koppelt — näher an dem, was ein reales Zonal-Gateway tatsächlich braucht.

Mit candump auf beiden Seiten und tcpdump/Wireshark auf dem Ethernet-Interface dazwischen lässt sich das Tunneling in Echtzeit mitverfolgen: derselbe CAN-Frame erscheint einmal auf dem CAN-Bus und einmal als ACF_CAN-Payload im IEEE-1722-Frame. Genau dieses Setup wird in Teil 5 dieser Serie auf zwei physischen BeagleBone Black nachgebaut — dort aber mit dem Open1722-Linux-Kernel-Modul statt der User-Space-Beispielanwendungen.

Zusammenfassung

BeispielKernaussage

Kamera-Stream (Video)

AUTOSAR nutzt IIDC, Open1722 demonstriert dasselbe Prinzip nur über CVF — End-to-End-Ablauf (PTP-Sync, Stream Identification, Time-Aware Shaping, Presentation Time) ist trotzdem übertragbar

CAN-Tunnel (ACF_CAN)

Direkte Entsprechung zum AUTOSAR-Subtype — acf-can-talker/-listener/ -bridge bilden das reale ACF_CAN-Verhalten 1:1 nach

Determinismus

Kommt in beiden Fällen aus dem Switch (Stream Identification
Time-Aware Shaping), nicht aus dem Endpunkt allein

Nächster Schritt

Teil 5 baut das CAN-Tunnel-Beispiel als Praxisprojekt auf zwei echten BeagleBone Black nach — mit dem Open1722-Kernel-Modul statt User-Space-Apps

Weiter in der Serie: IEEE 1722 Teil 5 — Praxisprojekt: ACF-CAN-Kernel-Modul zwischen zwei echten BeagleBone Black