Figure 17: Mapping of N-PDUs to N-PDU-Pools An FrTpTxPduPool could be referenced by different FrTpConnections (see also chapter 7.3.2.2). Depending on the number of currently active FrTpConnections the bandwidth (N-PDUs) is shared between them 24 . By supporting dynamic bandwidth assignment, a support of different communication scenarios is possible. Figure 18 depicts two different scenarios which could be supported with only one FrTp configuration. From gateway’s point of view different communication scenarios are possible:

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Strukturelles Architektur- und PDU-Mapping-Diagramm (Schichten- und Ressourcen-Allokationsmodell).
• Technischer Zweck: Visualisierung des Tx-PDU-Poolings (FrTpTxPduPool) im AUTOSAR FlexRay Transport Layer (ISO 10681-2 / FrTp) zur dynamischen Bandbreitenzuweisung (Dynamic Bandwidth Assignment) sowie des Mappings von Transport-Layer-Einheiten (N-PDUs) auf Data-Link-Layer-Einheiten (L-PDUs) im FlexRay Interface (FrIf) entlang des statischen oder dynamischen FlexRay-Bussegments.
• Funktionale Einordnung: Entkopplung logischer Punkt-zu-Punkt-Transportverbindungen (FrTpConnection) von statisch reservierten FlexRay-Busressourcen. Mehrere Verbindungen teilen sich gemeinsame Sende-PDU-Pools, um den Kommunikationsdurchsatz (z. B. für parallele Diagnose-Sessions, Flashing oder Gateway-Routing) bei begrenzter Slot-Anzahl dynamisch zu maximieren.

2. Komponenten, Entitäten & Schnittstellen

• FrTp-Schicht (Transport Layer):
  • FrTpConnection (0, 1, 2): Repräsentiert logische Transportkanäle zwischen Sender und Empfänger.
  • FrTpTxPduPool (0, 1): Abstrahierte Ressourcenpools zur Gruppierung von Sende-N-PDUs.
  • Kardinalitäten / Relationen:
    • FrTpConnection → FrTpTxPduPool: n:1-Beziehung (Mehrere Verbindungen können denselben Pool referenzieren, z. B. Connection 0 und Connection 1 → Pool 0; Connection 2 → Pool 1). Eine Verbindung referenziert genau einen Pool.
    • FrTpTxPduPool → N-PDU: 1:m-Zuordnung über konfigurierte N-PDU-IDs (Pool 0 steuert N-PDU 0, 1, 2; Pool 1 steuert N-PDU 3, 4).
• FrIf-Schicht (FlexRay Interface):
  • N-PDU (0 bis 4): Network Protocol Data Units des FrTp (Payload inkl. FrTp-PCI).
  • L-PDU (0 bis 3): Link Layer Protocol Data Units des FlexRay-Treibers (Payload in FlexRay-Frames).
  • Mapping-Relationen:
    • Direktes 1:1-Mapping: N-PDU 0 → L-PDU 0, N-PDU 1 → L-PDU 1, N-PDU 4 → L-PDU 3.
    • PDU-Multiplexing / Slot-Sharing: N-PDU 2 (aus Pool 0) und N-PDU 3 (aus Pool 1) mappen auf denselben L-PDU 2 (zeitliches Multiplexing über Cycle-Repetition oder alternatives Triggern je nach Übertragungsszenario).
• Hardware- / Busebene (Channel n):
  • Physikalischer FlexRay-Kanal mit Zeitfortschritt t im statischen oder dynamischen Segment bis zum Segmentende (End of segment).

3. Dynamisches Verhalten & Sequenzablauf

• Dynamische Bandbreitenallokation (Bandwidth Sharing):
  • Single-Active: Ist nur eine Verbindung aktiv (z. B. FrTpConnection 0), beansprucht sie exklusiv alle N-PDUs ihres Pools (N-PDU 0, 1, 2) und erreicht maximale Übertragungsrate.
  • Multi-Active: Werden FrTpConnection 0 und 1 parallel betrieben, arbitriert der FrTp die verfügbaren N-PDUs des Pools dynamisch (z. B. Round-Robin pro Segment/Zyklus).
• Sendeablauf (Tx-Pfad):
  1. FrTp fordert Senden über FrIf_Transmit(NPduId, ...) an.
  2. FrIf leitet die Daten an den FlexRay-Treiber (Fr) weiter und belegt die zugeordnete L-PDU.
  3. Nach erfolgreichem Bustransfer im entsprechenden FlexRay-Slot meldet der Treiber den Tx-Event; das FrIf benachrichtigt FrTp via Callback FrTp_TxConfirmation(NPduId).
  4. Die Bestätigung gibt die N-PDU im Pool für die nächste Übertragung frei.
• Konkurrierender Zugriff auf L-PDU 2:
  • Da N-PDU 2 und N-PDU 3 denselben Frame L-PDU 2 nutzen, erfolgt die Zugriffssteuerung entweder durch statische Sendezyklen (Cycle Multiplexing in der FIBEX/ARXML) oder durch gegenseitigen Ausschluss der übergeordneten FrTp-Pool-Nutzung.

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration (Ecuc / BSW):
  • Im Modul FrTp muss der Container FrTpTxPduPool konfiguriert und mit den zugehörigen FrTpTxPdu-Referenzen verknüpft werden.
  • Die Verbindungskonfiguration FrTpConnection bindet über den Parameter FrTpTxPduPoolRef an den jeweiligen Pool.
  • Im FrIf müssen die FrIfTxPdu-Objekte exakt auf die entsprechenden FlexRay-Slots (FrIfFrame, Channel A/B, statisch vs. dynamisch) abgebildet werden.
• API-Vertrag & PduR:
  • Jede N-PDU besitzt eine eindeutige globale PduId (PduIdType). Die FrTp-Logik muss die Rückmeldung via FrTp_TxConfirmation thread-sicher und reentrant dem korrekten Verbindungsstatus zuordnen.
• Einschränkungen & Risiken:
  • Jitter & Latenz: Shared Pools reduzieren den statischen Speicher- und Slot-Footprint, führen jedoch bei simultanem Verbindungstransfer zu variablen Segmentierungsabständen (N_As-/N_Bs-Timer-Überwachung zwingend erforderlich).
  • Shared L-PDU Kollisionsvermeidung: Die Multiplex-Nutzung von L-PDU 2 durch zwei unterschiedliche Pools (FrTpTxPduPool 0 und 1) erfordert zwingend eine kollisionsfreie Scheduler-Konfiguration im FlexRay-Cluster (z. B. disjunkte Zyklusfilter oder striktes Single-Use-Gateway-Design).