Teil 1 hat AVTP als Rahmenformat für Audio/Video-Streaming eingeführt. Dieser Teil widmet sich einem eigenen AVTPDU-Subtype, der für automotive Anwendungen mindestens genauso relevant ist: ACF (AVTP Control Format).
Der ursprüngliche Zuschnitt dieser Serie ging von ACF als generischem
Feldbus-Tunneling-Mechanismus für praktisch beliebige Bussysteme aus — diese
Annahme stammte aus der Open1722-Referenzimplementierung. Ein Blick in die
tatsächliche AUTOSAR-Spezifikation
( |
Die ACF-Formatfamilie: AUTOSAR-Modul vs. allgemeiner Standard
| ACF-Format | Im AUTOSAR-Modul IEEE1722Tp (R24-11) spezifiziert? |
|---|---|
ACF_CAN (inkl. CAN_BRIEF-Variante) | Ja — Container |
ACF_LIN | Ja — Container |
CAN-XL / CAN-XL Brief, FlexRay, MOST, Sensor, GPC, Generic Byte Bus, GISF | Nein — diese Formate kennt der allgemeine IEEE-1722-Standard bzw. die
Open1722-Referenzimplementierung, aber die Konfigurationsspezifikation des
AUTOSAR-Moduls |
Das heißt nicht, dass FlexRay- oder MOST-Tunneling über TSN generell
unmöglich wäre — nur eben nicht über den AUTOSAR-Standardmechanismus
|
Open1722 bleibt trotzdem die richtige Wahl als Lernumgebung: es implementiert den allgemeinen IEEE-1722-Standard direkt (nicht die AUTOSAR-Abstraktion darüber) und eignet sich damit hervorragend, um ACF-CAN- und ACF-LIN-Tunneling hands-on nachzuvollziehen — siehe Teile 4 und 5 dieser Serie. Es ist aber wichtig, die beiden Ebenen (allgemeiner Standard/Open1722 vs. konkretes AUTOSAR-BSW-Modul) nicht zu verwechseln. |
TSCF vs. NTSCF: der zentrale Framing-Unterschied
ACF-Nachrichten werden nicht direkt als AVTPDU verschickt, sondern in einem
von zwei Control-Format-Rahmen transportiert. Im ARXML wird das über den
Enumerations-Parameter IEEE1722TpStreamAcfHeaderType gewählt:
TIME_SYNCHRONOUS (TSCF) | NON_TIME_SYNCHRONOUS (NTSCF) | |
|---|---|---|
Ausgeschrieben | Time Sensitive Control Format | None Time Sensitive Control Format |
AVTP Stream Data Subtype |
|
|
Zeitstempel | Trägt einen gültigen | Kein Zeitstempel (Feld reserviert/ignoriert) |
Typischer Einsatz | Zeitkritische Daten — z. B. taktsynchrone Sensor-/Steuerdaten | Ereignisgesteuerte Daten — z. B. sporadische CAN-/LIN-Nachrichten ohne Zeitbezug |
Overhead | Etwas höher (Zeitstempel-Feld + dessen Pflege im Sender) | Minimal |
Die Wahl zwischen TSCF und NTSCF ist keine Format-Eigenschaft der Feldbus-Nachricht selbst, sondern eine Konfigurationsentscheidung pro ACF-Stream: dieselbe CAN-Nachricht kann je nach Projekt per TSCF oder NTSCF getunnelt werden — TSCF lohnt sich nur, wenn der Zeitstempel auf der Empfängerseite tatsächlich ausgewertet wird. |
Mehrere Feldbus-Nachrichten in einem AVTPDU bündeln
Ein einzelnes TSCF- oder NTSCF-Paket kann mehrere ACF-Nachrichten bündeln —
im AUTOSAR-Modul konkret über drei Parameter am IEEE1722TpStreamACF-Container
gesteuert:
| Parameter | Bedeutung |
|---|---|
| Boolescher Schalter: dürfen CAN- und LIN-Nachrichten gemischt in einem
ACF-Stream gesammelt werden ( |
| Größen-Schwellwert in Byte — wird er überschritten, löst das den Versand des gesammelten ACF-Pakets aus |
| Timeout in Sekunden — löst ebenfalls den Versand aus, unabhängig davon, ob der Schwellwert erreicht wurde |
Das Open1722-Beispiel aus dem README zeigt dasselbe Prinzip auf API-Ebene (vereinfacht, aus der allgemeinen Referenzimplementierung, nicht der AUTOSAR-API selbst):
Avtp_Tscf_Init(&tscf_pdu);
Avtp_Tscf_SetTv(&tscf_pdu, 1);
Avtp_Tscf_SetAvtpTimestamp(&tscf_pdu, timestamp);
/* erste ACF-Nachricht: CAN-Frame */
Avtp_Can_Init(&can_msg);
Avtp_Can_SetCanBusId(&can_msg, 1);
/* ... CAN-Payload befüllen ... */
/* zweite ACF-Nachricht: LIN-Frame, im selben AVTPDU */
Avtp_Lin_Init(&lin_msg);
/* ... LIN-Payload befüllen ... */
/* beide Nachrichten werden hintereinander in dieselbe TSCF-Nutzlast
geschrieben, bevor das Paket verschickt wird */Die Bündelung reduziert den Ethernet-Overhead pro Feldbus-Frame deutlich —
gerade bei kleinen LIN-/CAN-Nutzlasten wäre ein eigenes Ethernet-Frame pro
Feldbus-Nachricht unverhältnismäßig ineffizient. Die Kehrseite: ein zu hoher
|
Warum das für zonale Architekturen relevant ist
Der eigentliche Anwendungsfall für ACF im Fahrzeug: eine zonale
Architektur, in der nicht jedes Steuergerät sofort auf natives TSN-Ethernet
migriert wird. Legacy-Teilnetze (CAN, LIN — im Rahmen dessen, was
IEEE1722Tp heute abdeckt) bleiben lokal in einer Zone bestehen, aber der
Zonal Controller tunnelt ihren Verkehr transparent über das zentrale
TSN-Backbone zu einem Domain-Controller oder einer zentralen Recheneinheit —
ohne dass die Feldbus-Steuergeräte selbst geändert werden müssen.
| Migrationsstufe | Rolle von ACF |
|---|---|
Vollständig migriert | Steuergerät spricht direkt natives Ethernet/AVTP — kein ACF nötig |
Teilmigriert (typischer Fall heute) | Zonal Controller tunnelt CAN-/LIN-Teilnetze per ACF über TSN — Feldbus-Steuergeräte bleiben unverändert |
Nicht migriert | Klassischer Feldbus ohne jede Ethernet-Anbindung |
Diese Zwischenstufe ("teilmigriert") ist in der Praxis über Jahre hinweg der Regelfall, weil eine vollständige Migration aller Steuergeräte einer Fahrzeugplattform auf einmal wirtschaftlich selten sinnvoll ist. Teil 5 dieser Serie zeigt genau dieses Szenario konkret nachvollziehbar an zwei physischen BeagleBone Black.
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
ACF im AUTOSAR-Modul |
|
TSCF vs. NTSCF | Korrekt ausgeschrieben: Time Sensitive Control Format (Subtype |
Bündelung |
|
Zonale Relevanz | ACF ist der Mechanismus, mit dem teilmigrierte Fahrzeugarchitekturen CAN-/LIN-Teilnetze transparent über ein zentrales TSN-Backbone einbinden |
Nächster Schritt | Teil 3 zeigt die vollständige ARXML-Konfiguration des |
Weiter in der Serie: IEEE 1722 Teil 3 — ARXML-Konfiguration des IEEE1722Tp-Moduls