Teil 1 und Teil 2 haben AVTP und ACF konzeptionell eingeführt. Dieser Teil zeigt die ARXML-Seite — mit den tatsächlichen Container- und Parameternamen aus Kapitel 10 der AUTOSAR_CP_SWS_IEEE1722TransportLayer.pdf (R24-11), nicht mit vereinfachten Platzhaltern.

Die Container-Hierarchie

IEEE1722Tp: Container-Hierarchie
IEEE1722Tp
 ├── IEEE1722TpGeneral                       (0..1)
 │    ├── IEEE1722TpDevErrorDetect
 │    ├── IEEE1722TpVersionInfoApi
 │    ├── IEEE1722TpMainFunctionTx           (Period, PartitionRef)
 │    └── IEEE1722TpMainFunctionRx           (Period, PartitionRef)
 └── IEEE1722TpConfig                        (0..1)
      ├── IEEE1722TpLowerLayerPduPool        (1..*)
      │    ├── IEEE1722TpLowerLayerTxPduPoolEntry (0..*)
      │    │    ├── IEEE1722TpLowerLayerTxPduId
      │    │    └── IEEE1722TpLowerLayerTxPduRef   → Pdu
      │    └── IEEE1722TpLowerLayerRxPduPoolEntry (0..*)
      │         ├── IEEE1722TpLowerLayerRxPduId
      │         └── IEEE1722TpLowerLayerRxPduRef   → Pdu
      └── IEEE1722TpStream                   (1..*)
           ├── IEEE1722TpStreamIdUniquePart
           ├── IEEE1722TpStreamIdMacAddress   (0..1)
           ├── IEEE1722TpStreamIndex
           ├── IEEE1722TpStreamMaxTransitTime
           ├── IEEE1722TpStreamVersion
           ├── IEEE1722TpEthIfClkUnitRef
           ├── IEEE1722TpStbMSynchronizedTimeBaseRef
           ├── IEEE1722TpStreamLowerLayerPduPoolRef  → IEEE1722TpLowerLayerPduPool
           ├── IEEE1722TpStreamDirection      (Choice: Tx | Rx, je mit TxQueue/RxQueue)
           └── IEEE1722TpStreamSubtype        (Choice, genau 1)
                ├── IEEE1722TpStreamAAF
                ├── IEEE1722TpStreamCRF
                ├── IEEE1722TpStreamIIDC
                ├── IEEE1722TpStreamRVF
                └── IEEE1722TpStreamACF
                     ├── IEEE1722TpStreamAcfHeaderType (TIME_SYNCHRONOUS | NON_TIME_SYNCHRONOUS)
                     ├── IEEE1722TpAcfCollectionThreshold
                     ├── IEEE1722TpAcfCollectionTimeout
                     ├── IEEE1722TpStreamAcfMixedBusTypeCollection
                     └── IEEE1722TpStreamAcfPayload (Choice, 1..*)
                          ├── IEEE1722TpStreamAcfCan   → IEEE1722TpStreamAcfCanPdu (1..*)
                          └── IEEE1722TpStreamAcfLin

Das Modul unterstützt alle drei Post-Build-Varianten (VARIANT-PRE-COMPILE, VARIANT-LINK-TIME, VARIANT-POST-BUILD) — die meisten Parameter sind also erst zur Build- oder sogar erst zur Post-Build-Zeit endgültig festgelegt, nicht zwingend beim ersten Anlegen der ARXML-Struktur.

Die wichtigsten Parameter von IEEE1722TpStream

ParameterBedeutung

IEEE1722TpStreamIdUniquePart / IEEE1722TpStreamIdMacAddress

Zusammen ergeben sie die Stream-ID nach IEEE 1722 (MAC-Adresse + eindeutiger Teil) — IEEE1722TpStreamIdMacAddress ist optional (0..1), wenn die Ableitung aus der Board-MAC-Adresse ausreicht

IEEE1722TpStreamIndex

Handle-Index für den API-Zugriff im Kommunikations-Stack — ausdrücklich nicht identisch mit der eigentlichen Stream-ID aus den beiden Parametern oben (siehe Warnhinweis unten)

IEEE1722TpStreamMaxTransitTime

Maximale Transitzeit des Streams in Sekunden

IEEE1722TpStreamLowerLayerPduPoolRef

Referenz auf genau einen IEEE1722TpLowerLayerPduPool — darüber wird der Stream mit einem generischen Pdu für Tx/Rx verknüpft

IEEE1722TpEthIfClkUnitRef / IEEE1722TpStbMSynchronizedTimeBaseRef

Referenzen auf die Zeitquelle, aus der der avtp_timestamp für die Übertragung abgeleitet wird

Die Spezifikation weist explizit darauf hin: IEEE1722TpStreamIndex „is NOT related to the stream id combined out of IEEE1722TpStreamIdUniquePart and IEEE1722TpStreamIdMacAddress". Ein häufiger Konfigurationsfehler in der Praxis ist die Annahme, beide Werte müssten übereinstimmen oder ließen sich gegenseitig ableiten — sie sind vollständig unabhängige Identifikatoren mit unterschiedlichem Zweck (API-Handle vs. Wire-Format-ID).

Stream-Zuordnung zu Switch-Ports: indirekt, nicht direkt

Ein naheliegender Gedanke wäre, dass ein IEEE1722TpStream direkt auf einen Switch-Port referenziert (analog zu EthSwtPortIdx in der EthSwt-ARXML-Konfiguration). Das ist nicht der Fall:

Stream zu Switch-Port: kein direkter Parameter im IEEE1722Tp-Modul

IEEE1722TpStreamLowerLayerPduPoolRef referenziert nur einen IEEE1722TpLowerLayerPduPool, dessen Einträge (Tx-/RxPduPoolEntry) wiederum nur ein generisches Pdu referenzieren — es gibt keinen EthSwtPortRef oder Ähnliches direkt im IEEE1722Tp-Modul. Die Weiterleitung dieses Pdu läuft über den PduR, der es an SoAd übergibt — nicht über eine „PDU-Routing-Konfiguration" in EthIf oder EthSwt, die es so nicht gibt. Welcher physische Switch-Port am Ende bedient wird, ist eine reine Layer-2-Weiterleitungsentscheidung des Switch-Chips (Ziel-MAC-Adresse, ggf. VLAN) — unabhängig von der AUTOSAR-PDU-Identität. IEEE1722Tp selbst „weiß" nichts von Switch-Ports, und auch PduR/SoAd kennen keinen „Switch-Port" als Konfigurationsgröße.

Für die praktische Konfigurationsarbeit bedeutet das: die Stream-zu-Port-Frage lässt sich nicht innerhalb des IEEE1722Tp-ARXML beantworten. PduR routet das Pdu zu SoAd, SoAd bildet es auf eine Socket-Verbindung (SoAdSocketConnection) ab, die wiederum an EthIf/Eth gebunden ist — erst auf dem fertigen Ethernet-Frame entscheidet der Switch anhand der Ziel-MAC-Adresse (und ggf. VLAN-Zugehörigkeit), über welchen Port er weitergeleitet wird. Das ist eine vom IEEE1722Tp-ARXML komplett getrennte Konfigurationsebene.

Beispielkonfiguration: ein ACF_CAN-Sende-Stream

Illustrativ (Parameter- und Containernamen real, konkrete Werte frei gewählt) — ein Stream, der CAN-Nachrichten per NTSCF sendet:

<IEEE1722TP-STREAM>
  <SHORT-NAME>Stream_AcfCan_Tx_Zone1</SHORT-NAME>
  <IEEE1722TP-STREAM-ID-UNIQUE-PART>1</IEEE1722TP-STREAM-ID-UNIQUE-PART>
  <IEEE1722TP-STREAM-INDEX>0</IEEE1722TP-STREAM-INDEX>
  <IEEE1722TP-STREAM-MAX-TRANSIT-TIME>0.002</IEEE1722TP-STREAM-MAX-TRANSIT-TIME>
  <IEEE1722TP-STREAM-VERSION>0</IEEE1722TP-STREAM-VERSION>
  <IEEE1722TP-STREAM-LOWER-LAYER-PDU-POOL-REF DEST="IEEE1722TP-LOWER-LAYER-PDU-POOL">
    /IEEE1722Tp/IEEE1722TpConfig/PduPool_Zone1_Tx
  </IEEE1722TP-STREAM-LOWER-LAYER-PDU-POOL-REF>
  <IEEE1722TP-STREAM-DIRECTION>
    <IEEE1722TP-STREAM-TX/>
  </IEEE1722TP-STREAM-DIRECTION>
  <IEEE1722TP-STREAM-SUBTYPE>
    <IEEE1722TP-STREAM-ACF>
      <IEEE1722TP-STREAM-ACF-HEADER-TYPE>NON_TIME_SYNCHRONOUS</IEEE1722TP-STREAM-ACF-HEADER-TYPE>
      <IEEE1722TP-ACF-COLLECTION-THRESHOLD>256</IEEE1722TP-ACF-COLLECTION-THRESHOLD>
      <IEEE1722TP-ACF-COLLECTION-TIMEOUT>0.001</IEEE1722TP-ACF-COLLECTION-TIMEOUT>
      <IEEE1722TP-STREAM-ACF-MIXED-BUS-TYPE-COLLECTION>false</IEEE1722TP-STREAM-ACF-MIXED-BUS-TYPE-COLLECTION>
      <IEEE1722TP-STREAM-ACF-PAYLOAD>
        <IEEE1722TP-STREAM-ACF-CAN>
          <IEEE1722TP-STREAM-ACF-BUS-ID>1</IEEE1722TP-STREAM-ACF-BUS-ID>
          <IEEE1722TP-STREAM-ACF-CAN-MESSAGE-TYPE>CAN</IEEE1722TP-STREAM-ACF-CAN-MESSAGE-TYPE>
        </IEEE1722TP-STREAM-ACF-CAN>
      </IEEE1722TP-STREAM-ACF-PAYLOAD>
    </IEEE1722TP-STREAM-ACF>
  </IEEE1722TP-STREAM-SUBTYPE>
</IEEE1722TP-STREAM>

IEEE1722TpStreamAcfMixedBusTypeCollection = false in diesem Beispiel bedeutet: dieser Stream sammelt ausschließlich CAN-Nachrichten — für einen gemischten CAN+LIN-Stream (siehe Teil 2) müsste der Wert auf true gesetzt und zusätzlich ein IEEE1722TpStreamAcfLin-Container konfiguriert werden.

Typische Konfigurationsfehler

FehlerAuswirkung

IEEE1722TpStreamIndex mit der Stream-ID verwechselt

API-Zugriffe schlagen fehl oder greifen auf den falschen Stream zu, obwohl die Wire-Format-ID korrekt konfiguriert ist

IEEE1722TpStreamLowerLayerPduPoolRef zeigt auf einen Pool ohne passende Tx/RxPduPoolEntry für die gewählte IEEE1722TpStreamDirection

Stream lässt sich nicht senden/empfangen — Fehler taucht oft erst zur Laufzeit auf, nicht schon bei der ARXML-Validierung

IEEE1722TpEthIfClkUnitRef/IEEE1722TpStbMSynchronizedTimeBaseRef nicht konsistent mit dem tatsächlich synchronisierten Zeitbasis-Modul

avtp_timestamp wird gesetzt, ist aber nicht mit den Zeitstempeln anderer Steuergeräte im Netz synchron — TSN-Determinismus geht verloren, ohne dass ein offensichtlicher Konfigurationsfehler vorliegt

Downstream-Konfiguration (PduR-Routing zu SoAd, SoAdSocketConnection) nicht mit der IEEE1722Tp-Seite abgeglichen

Stream wird korrekt erzeugt, aber gar nicht oder mit falscher Ziel-MAC-Adresse ausgeliefert — da IEEE1722Tp selbst keine Sicht auf PduR/SoAd/Switch-Ports hat, fällt das nur beim Review der Gesamtkette auf

Zusammenfassung

AspektKernaussage

Container-Hierarchie

IEEE1722Tp → IEEE1722TpGeneral/IEEE1722TpConfig → IEEE1722TpLowerLayerPduPool + IEEE1722TpStream (mit Subtype-Choice)

Stream-ID vs. Stream-Index

Zwei unabhängige Identifikatoren — Verwechslung ist ein häufiger, von der Spezifikation explizit benannter Stolperstein

Switch-Port-Zuordnung

Kein direkter Parameter im IEEE1722Tp-Modul selbst: PduR routet das generische Pdu zu SoAd, der physische Switch-Port ergibt sich erst als reine Layer-2-Weiterleitungsentscheidung anhand der Ziel-MAC-Adresse auf dem fertigen Ethernet-Frame

Nächster Schritt

Teil 4 zeigt End-to-End-Praxisbeispiele mit Open1722 zum Nachvollziehen

Weiter in der Serie: IEEE 1722 Teil 4 — Praxisbeispiele end-to-end mit Open1722