Figure 9.6: Com to FrIf I-PDU transmission

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit Modul-Lebenslinien und synchronen Funktionsaufrufen).
• Technischer Zweck: Spezifikation des asynchronen, zweistufigen Sendeablaufs via TriggerTransmit für FlexRay im AUTOSAR Classic Platform Communication Stack (BSW).
• Funktionale Einordnung: Entkopplung der oberen Kommunikationsschicht (Com) vom zeitsynchronen FlexRay-Übertragungszyklus über den PduR und das FrIf. Vermeidung von PDU-Pufferung im PDU-Router durch bedarfsgesteuertes (Pull-)Abrufen der Nutzdaten unmittelbar vor dem FlexRay-Sende-Slot.

2. Komponenten, Entitäten & Schnittstellen

• Module / Lifelines («module»):
  • Com (AUTOSAR COM Module): Oberer BSW-Nutzer, puffert Signale/I-PDUs und bedient den Datentransfer auf Abruf.
  • PduR (PDU Router): Vermittlungsinstanz, zuständig für 1:1- oder 1:n-Routing von I-PDUs ohne Nutzdatenpufferung (zero-buffering gateway/router in diesem Pfad).
  • FrIf (FlexRay Interface): Untere Kommunikationsschnittstelle, interfaced zum FlexRay-Treiber (Fr) und dem globalen TDMA-Zeitplan.
• Schnittstellen & Datenstrukturen:
  • PduIdType: Konfigurierter, lokaler Handle-Identifier der I-PDU (Modul-spezifisch gemappt via PduR).
  • PduInfoType*: Struktur (SduDataPtr, SduLength) zur Referenzierung von Sende- und Zielpuffern.
  • Std_ReturnType: Rückgabewert (E_OK, E_NOT_OK).
  • Schnittstellen-Signaturen laut Diagramm:
    • PduR_ComTransmit(...) / FrIf_Transmit(...)
    • PduR_<User:Lo>TriggerTransmit(...) / Com_TriggerTransmit(...)
    • PduR_<User:Lo>TxConfirmation(...) / Com_TxConfirmation(...) (wobei <User:Lo> zur Laufzeit/Generierung durch das konkrete Interface, hier FrIf, ersetzt wird).
• Beziehungen & Kardinalitäten:
  • Hierarchische Schichtung: Com (Upper Layer) → PduR (Routing Engine) → FrIf (Lower Layer).
  • Keine Modul-Pufferung im PduR (1:1-Forwarding; PduR-Buffering ist für diesen Pfad deaktiviert).

3. Dynamisches Verhalten & Sequenzablauf

sequenceDiagram
    autonumber
    participant Com as «module» Com
    participant PduR as «module» PduR
    participant FrIf as «module» FrIf

    Note over Com,FrIf: Phase 1: Sendeanforderung (Synchroner Trigger)
    Com->>+PduR: PduR_ComTransmit(TxPduId, &PduInfo)
    PduR->>+FrIf: FrIf_Transmit(FrIfTxPduId, &PduInfo)
    FrIf->>FrIf: set flag() [Markierung für Sende-Slot; kein Puffer-Kopieren]
    FrIf-->>-PduR: E_OK / E_NOT_OK
    PduR-->>-Com: E_OK / E_NOT_OK

    Note over Com,FrIf: Phase 2: Pull-Übertragung im TDMA-Slot (Asynchron)
    FrIf->>+PduR: PduR_<User:Lo>TriggerTransmit(PduRRxPduId, &PduInfo)
    PduR->>+Com: Com_TriggerTransmit(ComTxPduId, &PduInfo)
    Com->>Com: copy buffer() [Payload in FrIf-Puffer kopieren]
    Com-->>-PduR: E_OK
    PduR-->>-FrIf: E_OK

    Note over Com,FrIf: Phase 3: Sende-Bestätigung (Nach erfolgreichem Frame-Tx)
    FrIf->>+PduR: PduR_<User:Lo>TxConfirmation(PduRRxPduId, E_OK)
    PduR->>+Com: Com_TxConfirmation(ComTxPduId, E_OK)
    Com-->>-PduR: void / return
    PduR-->>-FrIf: void / return

1. Sendeinitiierung (Phase 1):
   • Com stößt die Übertragung synchron mittels PduR_ComTransmit() an.
   • Der PduR leitet den Aufruf ohne Datenkopie an FrIf_Transmit() weiter.
   • FrIf setzt intern ein Sendeflag (set flag()) für den entsprechenden FlexRay-Slot/Frame.
   • Wichtig: Es findet in FrIf und PduR keine Kopie der PDU-Nutzdaten statt (Will not copy PDU buffer). Der Call kehrt synchron mit Bestätigung der Annahme (E_OK) zurück.
2. Datenabruf via TriggerTransmit (Phase 2):
   • Sobald der FlexRay-TDMA-Slot im Kommunikationszyklus erreicht ist, fordert FrIf die Nutzdaten per PduR_<User:Lo>TriggerTransmit() an.
   • PduR routet den Aufruf zu Com_TriggerTransmit().
   • Com kopiert synchron die aktuellen I-PDU-Daten in den von FrIf bereitgestellten Speicherbereich (copy buffer()) und signalisiert E_OK.
3. Sendequittierung (Phase 3):
   • Nach erfolgreichem Senden des FlexRay-Frames meldet FrIf die Bestätigung über PduR_<User:Lo>TxConfirmation().
   • PduR transformiert die ID und ruft Com_TxConfirmation() auf, um interne Timer (z. B. Transmission Deadline Monitoring) im Com zurückzusetzen.
4. Fehler- und Abbruchpfade:
   • Liefert FrIf_Transmit() nicht E_OK (z. B. Controller im falschen Zustand / Buffer voll), bricht PduR ab und gibt den Fehler direkt an Com zurück; es folgt kein TriggerTransmit.
   • Schlägt Com_TriggerTransmit() fehl (z. B. Daten noch ungültig / Längenmismatch), sendet das FlexRay-Interface keinen gültigen Frame bzw. reagiert gemäss FlexRay-Tx-Konfiguration (Null-Frame oder letzter konsistenter Stand).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsanforderungen (BSW-Generierung):
  • Im PduR muss der Routing-Pfad als Direktdurchleitung (PduRTransmissionMode: DIRECT) ohne Puffer (PduRQueueDepth = 0) konfiguriert sein.
  • Das Routing-Ziel muss das Flag bzw. den Callout für TriggerTransmit aktiviert haben (PduRTriggertransmit = true).
  • Im Com muss für diese I-PDU die Eigenschaft ComIPduTriggerTransmit = true gesetzt sein.
• Puffer- und Reentrancy-Verträge:
  • Com_TriggerTransmit() läuft im Interrupt-Kontext des FlexRay-Treibers bzw. der FrIf_MainFunction_Tx(). Entwickler müssen sicherstellen, dass die Datenkopie in Com atomar und minimal gehalten wird (Vermeidung von Priority Inversion und Lock-Contention auf BSW-Locks).
  • Der übergebene Zeiger in PduInfoType->SduDataPtr muss während der Ausführung von Com_TriggerTransmit() exklusiv beschrieben werden und darf von der oberen Schicht nach dem Return nicht weiter referenziert werden.
• Aktualitätsgarantie (Data Freshness):
  • Vorteil dieses Musters gegenüber klassischem CAN-Transmit: Die übertragenen I-PDU-Daten besitzen die geringstmögliche Latenz (Just-In-Time Serialization), da sie erst unmittelbar beim Sende-Slot aus den Signalspeichern in Com serialisiert werden.