Figure 19: Connection Handler for different connections The bandwidth assignment can change each communication cycle depending on the active communication links. Especially a gateway could have multiple active communication links in parallel. Hence there are some additional requirements for

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Schichtenmodell mit PDU-Scheduling- und Timing-/Bus-Abbildungsdiagramm (Schichtenarchitektur kombiniert mit Buszyklus-Zeitleiste).
• Technischer Zweck: Visualisierung des Bandbreiten-Managements und Multiplexings mehrerer paralleler Transportverbindungen (Connections 1–4) durch den internen ConnectionHandler des FlexRay ISO Transport Layers (FrTp, ISO 10681-2) im AUTOSAR Classic BSW-Stack.
• Architektonische Einordnung:
  • **Obere Schicht (Upper Layer):** PDU Router (PduR) bzw. Diagnostic Communication Manager (Dcm), die segmentierte N-SDUs bereitstellen.
  • Transportschicht (FrTp): Vermittlung, Segmentierung, Flusskontrolle und dynamische Bandbreitenzuteilung zwischen logischen Kanälen.
  • Untere Schicht (FrIf): FlexRay Interface zur hardwarenahen PDU-Weiterleitung an den FlexRay-Treiber (Fr).
  • Bus-Ebene: Zuordnung von Transportprotokoll-PDUs (FrTp N-PDUs / L-PDUs) zu den statischen (Static Segment) und dynamischen (Dynamic Segment) Segmenten der aufeinanderfolgenden FlexRay-Kommunikationszyklen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten:
  • Upper Layer TxBuffer: Bereitstellende Sendepuffer der oberen Schicht je Verbindung (Connection 1 bis 4), gepuffert mit FrTp N-PDUs (z. B. Segmente 1A–1D, 2A, 3A–3B, 4A–4D).
  • FrTpChannel (Kanal 1 bis 4): Konfigurierte logische Instanzen (FrTpChannel) zur Verwaltung jeweils einer aktiven Punkt-zu-Punkt- oder 1:n-Verbindung.
  • Tx-Pdu Pending-Counter: Kanalinterner Zustandszähler, der die Anzahl der an das FrIf übergebenen, aber noch nicht über TxConfirmation bestätigten Sende-PDUs überwacht (Flusssteuerungs- und Überlastschutz-Mechanismus gemäß ISO 10681-2).
  • ConnectionHandler: Zentrale Arbitrierungs- und Scheduling-Instanz innerhalb des FrTp, die die Sendeanforderungen über aktive Kanäle priorisiert, Bandbreitenkontingente zuteilt und Concurrent Transmissions synchronisiert.
  • FlexRay Interface (FrIf): Abstraktionsschicht unterhalb des FrTp.
• Schnittstellen (APIs):
  • FrIf_Transmit(PduIdType TxPduId, const PduInfoType* PduInfoPtr): Asynchroner Sendeaufruf des FrTp an das FrIf.
  • FrTp_TxConfirmation(PduIdType TxPduId): Asynchroner Callback des FrIf an das FrTp zur Bestätigung der erfolgten Frame-Übertragung auf dem Bus.
• Beziehungen & Kardinalitäten:
  • 1:1-Beziehung zwischen logischer Verbindung (Connection), oberem Sendepuffer und zugewiesenem FrTpChannel.
  • N:1-Aggregation aller aktiven Kanäle durch den ConnectionHandler.
  • Duales Mapping auf den FlexRay-Bus:
    • Verbindung 4 ist festen Slots im statischen Segment zugewiesen (zyklisch deterministisch: 4A, 4B in Zyklus k; 4C, 4D in Zyklus k+1).
    • Verbindungen 1, 2 und 3 teilen sich dynamisch per Minislotting das dynamische Segment (interleaved: 1A → 2A → 3A → 1B → 3B in Zyklus k; verbleibende Segmente 1C, 1D in Zyklus k+1).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggerung & Pufferung: Die obere Schicht übergibt Sendedaten für mehrere Verbindungen parallel an die TxBuffer des FrTp.
2. Kanalzuteilung & Arbitrierung:
   • Der ConnectionHandler evaluiert zyklisch den Füllstand der TxBuffer und die Grenzwerte der Tx-Pdu Pending-Counter.
   • Pro Kanal wird geprüft, ob das Sendekontingent für den aktuellen FlexRay-Kommunikationszyklus ausgeschöpft ist und ob Flow-Control-Parameter (z. B. BS - Block Size, ST_min - Separation Time) eingehalten werden.
3. PDU-Dispensierung (FrIf_Transmit):
   • Der ConnectionHandler stößt für berechtigte Kanäle FrIf_Transmit(..) an.
   • Der jeweilige Tx-Pdu Pending-Counter des Kanals wird inkrementiert.
   • Statische PDUs (4A, 4B) werden für die reservierten statischen FlexRay-Slots eingesteuert; dynamische PDUs (1A, 2A, 3A, etc.) werden für Übertragungen im dynamischen Segment asynchron registriert.
4. Busübertragung (FlexRay Cycle Execution):
   • Zyklus k: Übertragung statischer Frames (4A, 4B), gefolgt von dynamischer Arbitrierung im Dynamic Segment (1A, 2A, 3A, 1B, 3B).
   • Zyklus k+1: Fortsetzung im nächsten Zyklus mit Restdaten (4C, 4D im statischen Segment, 1C, 1D im dynamischen Segment).
5. Quittierung (FrTp_TxConfirmation):
   • Nach erfolgreichem Versand meldet das FrIf via FrTp_TxConfirmation(..) Vollzug.
   • Der ConnectionHandler dekrementiert den Tx-Pdu Pending-Counter des zugehörigen Kanals, gibt Pufferkapazitäten frei und schaltet nachfolgende N-PDUs frei.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer- und Zählerdimensionierung (FrTpChannel):
  • Der Grenzwert für den Tx-Pdu Pending-Counter (FRTP_TX_PDU_PENDING_MAX bzw. kanalspezifische Konfiguration) muss zwingend auf die Sende-Mailboxen im FrIf/Fr-Treiber abgestimmt sein, um BUFREQ_E_BUSY-Zustände oder Frame-Drops bei asynchronen Gateway-Bursts zu verhindern.
• Mischbetrieb Statisches/Dynamisches Segment:
  • Wird ein FrTp-Kanal auf das dynamische Segment konfiguriert, muss beachtet werden, dass die tatsächliche Übertragungsbandbreite vom Slot-ID-Wettbewerb und der Minislot-Verfügbarkeit abhängt (Gefahr von Timeouts bei hoher Buslast im dynamischen Segment).
  • Kanäle im statischen Segment garantieren Latenz und Bandbreite, binden aber exklusive FlexRay-Payload unabhängig von der tatsächlichen TP-Aktivität.
• Gateway-Betrieb & Reentrancy:
  • Da ein Gateway mehrere FrTp-Verbindungen gleichzeitig bedient (wie im Diagramm dargestellt), muss die Implementierung des ConnectionHandler reentrant gegen Pufferanforderungen (FrTp_Transmit) und interrupt-getriebene Bestätigungen (FrTp_TxConfirmation) ausgeführt sein.
• Fehlerbehandlung:
  • Bleibt FrTp_TxConfirmation innerhalb des Timeouts N_Ar / N_As aus, läuft der Kanal in einen Timeout-Fehler, der Tx-Pdu Pending-Counter muss bereinigt und der Fehler über Dem_ReportErrorStatus bzw. Det_ReportRuntimeError gemeldet werden.