Figure 6.81: Modeling of IEEE1722TpAafConnection

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Metamodell-Ausschnitt aus dem AUTOSAR System Template, AUTOSAR_CP_TPS_SystemTemplate).
• Funktionale Einordnung: Beschreibt das deklarative Metamodell für den IEEE 1722 Transport Protocol Stack (AVTP – Audio Video Transport Protocol) innerhalb des AUTOSAR Ethernet/TSN-Subsystems. Konkret wird die Modellierung der AVTP Audio Format (AAF) Verbindungen spezifiziert, welche PCM- und AES3-Audioströme über Ethernet-Netzwerke deterministisch kapseln und übertragen.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Vererbungshierarchie

• IEEE1722TpConnection (abstrakt, spezialisiert ARElement):
  • Basisklasse aller IEEE 1722 Transport-Verbindungen.
  • Attribute:
    • destinationMacAddress: MacAddressString [0..1] – Ziel-MAC-Adresse des AVTP-Datenstroms (Unicast oder standardisierte IEEE 1722 AVB-Multicast-Adresse).
    • macAddressStreamId: MacAddressString [0..1] – Obere 48 Bit der standardisierten 64-Bit IEEE 1722 Stream-ID (entspricht typischerweise der EUI-48 der Source-MAC).
    • uniqueStreamId: PositiveInteger [0..1] – Untere 16 Bit der 64-Bit Stream-ID zur Unterscheidung mehrerer Ströme eines Endknotens.
    • version: PositiveInteger [0..1] – AVTP-Protokollversion (Default 0x00).
    • vlanPriority: PositiveInteger [0..1] – IEEE 802.1Q Priority Code Point (PCP) für TSN Stream Reservation (SR Class A oder B).
  • Assoziation zu PduTriggering:
    • Rolle +pdu [0..1]: Referenziert das resultierende AVTP-Transport-Frame (Lower Layer PDU auf Ethernet/VLAN-Ebene).
• IEEE1722TpAvConnection (abstrakt, erbt von IEEE1722TpConnection):
  • Spezialisierung für Audio/Video-Ströme mit Zeitstempelanforderungen.
  • Attribute:
    • maxTransitTime: TimeValue [0..1] – Maximale Netzwerkübertragungsverzögerung (Presentation Time Offset) zur Ermittlung der IEEE 1722 Presentation Time (avtp_timestamp = current_gptp_time + maxTransitTime).
  • Assoziation zu PduTriggering:
    • Rolle +sdu [0..*]: Referenziert die oberen Nutzdaten-PDUs (SDUs, z. B. unkomprimierte Audiokanäle oder gemultiplexte Audiodatenströme).
• IEEE1722TpAafConnection (konkret, erbt von IEEE1722TpAvConnection):
  • Ausprägung für AVTP Audio Format (AAF).
  • Attribute:
    • aafFormat: IEEE1722TpAafFormatEnum [0..1] – Grundlegendes Datenkodierungsformat.
    • aafNominalRate: IEEE1722TpAafNominalRateEnum [0..1] – Audio-Abtastrate (Sampling-Frequenz).
    • aafAes3DataType: IEEE1722TpAafAes3DataTypeEnum [0..1] – Datentyp-Klassifikation bei AES3-Frames.
    • aes3DataTypeH: PositiveInteger [0..1] & aes3DataTypeL: PositiveInteger [0..1] – High-/Low-Subtyp-Indikatoren gemäß AES3-Spezifikation.
    • channelsPerFrame: PositiveInteger [0..1] – Anzahl der interleaved Audiokanäle je Sample-Intervall.
    • eventDefaultValue: PositiveInteger [0..1] – Initial- bzw. Ruhewert für das AVTP-Event-Bitfeld.
    • pcmBitDepth: PositiveInteger [0..1] – Effektive Bittiefe des PCM-Audio-Samples (z. B. 16, 24, 32 Bit).
    • sparseTimestampEnabled: Boolean [0..1] – Aktiviert "Sparse Timestamps" (Zeitstempelung nur für jedes n-te Datenpaket zur Bandbreitenoptimierung).
    • streamsPerFrame: PositiveInteger [0..1] – Anzahl redundanter oder parallel gekapselter Sub-Streams je Frame.
• PduTriggering (spezialisiert Identifiable):
  • Verknüpfungspunkt im AUTOSAR System Template zwischen Signalen/PDUs und dem physikalischen Kommunikationskanal (Cluster/Frame).

Enumerationen

• IEEE1722TpAafFormatEnum: user, float_32bit, int_32bit, int_24bit, int_16bit, aes3_32bit.
• IEEE1722TpAafNominalRateEnum: user, 8kHz, 16kHz, 32kHz, 44_1kHz, 48kHz, 88_2kHz, 96kHz, 176_4kHz, 192kHz, 24kHz.
• IEEE1722TpAafAes3DataTypeEnum: vendor, unspecified, pcm, smpte338, iec61937.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet ein statisches Konfigurations-Metamodell ab. Zur Laufzeit steuern diese Instanzen die Protokollverarbeitung im BSW-Stack (Ieee1722Tp / AVTP):

[Audio SDU(s) via PduR] 
       │ 
       ▼ (1:N Multiplex / Serialisierung)
[Ieee1722Tp_Transmit] 
       │ ──> Liest gPTP-Referenzzeit via StbM (IEEE 802.1AS)
       │ ──> Addiert maxTransitTime -> generiert avtp_timestamp
       │ ──> Kapselt PCM/AES3-Payload gemäß aafFormat & channelsPerFrame
       │ ──> Setzt 64-Bit Stream-ID (macAddressStreamId + uniqueStreamId)
       ▼ 
[EthIf / SoAd -> PduTriggering (PDU)]

• Sende-Pfad (TX):
  1. PduR übergibt Audio-SDUs an das IEEE 1722 TP-Modul.
  2. Entsprechend aafFormat, channelsPerFrame und pcmBitDepth werden die Bytes gepackt.
  3. Bei aktiviertem sparseTimestampEnabled wird der avtp_timestamp nur in definierten Intervallen aktualisiert; andernfalls wird jeder Frame mit TimeValue = Current_gPTP_Time + maxTransitTime getaggt.
  4. Die fertige Ethernet-PDU (+pdu) wird an SoAd/EthIf mit priorisiertem VLAN-Header (vlanPriority) übergeben.
• Empfangs-Pfad (RX):
  1. Ethernet-PDU trifft über EthIf ein; Filterung erfolgt über Ziel-MAC und 64-Bit-StreamID.
  2. AAF-Header-Validierung (Abtastrate aafNominalRate, Format, Kanalanzahl).
  3. Entpacken der Audio-Samples und Übergabe via +sdu an den oberen Layer bzw. Wiedergabepuffer unter Berücksichtigung der Presentation Time (Jitter-Kompensation).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationskonsistenz (ARXML-Validierung):
  • Die 64-Bit StreamID muss systemweit eindeutig sein: Verkettung aus macAddressStreamId (Hex-String, EUI-48) und uniqueStreamId (16-Bit Integer) muss zwingend mit der Konfiguration der TSN-Talker/Listener harmonieren.
  • Das Paar pcmBitDepth und aafFormat unterliegt Plausibilitätsregeln (z. B. pcmBitDepth = 16 zwingend gekoppelt an aafFormat = int_16bit oder generisches Packing).
• Zeitsynchronisation (StbM / gPTP):
  • Die Auswertung von maxTransitTime erfordert eine synchronisierte Zeitbasis via StbM (Synchronized Time-Base Manager) und EthTSyn (IEEE 802.1AS). Fehlt die Synchronisation, schlägt die Validierung der Presentation Time im Listener fehl (Verwerfen von Frames wegen Timestamp-Mismatch).
• BSW-Generierung:
  • Der BSW-Code-Generator nutzt die Relation IEEE1722TpAafConnection → PduTriggering (+pdu / +sdu) zur Generierung der internen Routing-Tabellen zwischen PduR-PDU-IDs und Ethernet-Frame-PDU-IDs. Fehlt die +pdu-Referenz, kann kein Sende- oder Empfangskontext im Ethernet-Interface allokiert werden.