DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_FlexRayISOTransportLayer FIG-d935b3e72a20f856 910 × 740 px 4 Release(s)

Figure 15: Transmit data overview in ‘Decoupled Buffer Access’ mode Step 01 - 10 Step 01 - 10 in ‘decoupled access mode’ are equal to step 01 – 10 in ‘immediate access mode’. Please refer chapter 7.5.2.1. For step 09 it is recommended to set the address information and PCI to a local buffer because the service primitive FrTp_TriggerTransmit is called in interrupt

SHA-256 Inhalts-Fingerabdruck: d935b3e72a20f856b25d8284e25660708eb7e009d4a38719020dc856e07c936e

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: UML-Sequenzdiagramm (Interaktionsübersicht mit Kontrollfluss- und Verzweigungskonstrukten / Inline-Bedingungen).
  • Architektur-Kontext: AUTOSAR Classic Platform (CP), Communication Stack (ComStack).
  • Funktionale Einordnung: Datenübertragung über das FlexRay ISO Transport Layer (FrTp, gem. ISO 10681-2) im Betriebsmodus „Decoupled Buffer Access“ (im Gegensatz zum Immediate Buffer Access).
  • Technischer Zweck: Entkopplung der Datenbereitstellung (Assembly von N-PDUs im Pufferkontext des FrTp_MainFunction) vom tatsächlichen Sendezeitpunkt des FlexRay-Kommunikationszyklus (FrIf_TriggerTransmit im Interrupt- bzw. Timer-Kontext des FlexRay Interface/Treibers).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Module (Lebenslinien)
  • PduR (PDU Router): Übergeordnete Vermittlungsschicht; stellt I-SDUs bereit und nimmt Abschlussbestätigungen entgegen.
  • FrTp (FlexRay Transport Layer): Transportprotokollinstanz; zuständig für Segmentierung, Flusssteuerung (Flow Control), PCI-Generierung (Protocol Control Information) und Verbindungs-/Kanalverwaltung.
  • FrIf (FlexRay Interface): Unterlagerte Schnittstelle zum FlexRay-Treiber (Fr); taktet die N-PDU-Übertragung im statischen/dynamischen FlexRay-Segment.
Schnittstellen & Service-Primitive
  • Sync Calldown:
    • FrTp_Transmit(TxSDU-ID, PduInfoPtr): Sendestartanforderung durch PduR.
    • FrIf_Transmit(TxPDU-ID, PduInfoPtr): Übergabe der N-PDU-Sendeanforderung an FrIf.
  • Async / Inter-Layer Callbacks & Data-Pull:
    • PduR_FrTpCopyTxData(TxSDU-ID, ...): Pull-Mechanismus zum Kopieren von Nutzdaten aus dem Upstream-Puffer in den FrTp-N-PDU-Puffer.
    • FrTp_TriggerTransmit(TxPDU-ID, PduInfoPtr): Unterlagertes Polling/Triggering durch FrIf zur Pufferübergabe kurz vor dem FlexRay-Slot.
    • FrTp_TxConfirmation(TxPDU-ID): Bestätigung des erfolgreichen Frame-Versands durch FrIf.
    • PduR_TxConfirmation(TxSDU-ID, Std_ReturnType): End-to-End-Bestätigung des vollständigen SDU-Versands an die PduR.
Interne Entitäten & Zustandsvariablen
  • TxSDU-ID / TxPDU-ID: Identifikatoren für logische Transport-SDU bzw. physikalische Frame-N-PDU.
  • Flag TX_SDU_AVAILABLE: Blockierschutz / Kanalstatusindikator für anstehende SDU-Daten.
  • Variable TxPduState: Zustandsüberwachung der N-PDU (wird nach FrTp_TxConfirmation auf Idle zurückgesetzt).
  • Channel / Connection Allocation: Exklusive Bindung einer logischen FrTp-Verbindung an einen FrTp-Kanal.

3. Dynamisches Verhalten & Sequenzablauf

  1. Initiierungsphase (Kontext: Aufrufer-Task via PduR):
    • 01: PduR stößt die Übertragung über FrTp_Transmit(TxSDU-ID, ...) synchron an.
    • 02–04: FrTp validiert die TxSDU-ID, alloziert einen freien internen Kanal, initialisiert den Verbindungszustand und setzt das Flag TX_SDU_AVAILABLE. Rückkehr zu PduR (asynchroner Sendestart).
  2. Puffer-Bereitstellung & PDU-Zusammenbau (Kontext: FrTp_Main):
    • 05: Eintritt in den zyklischen Task-Aufruf FrTp_Main.
    • 06–08: Abfrage und Kopieren der Nutzdaten via PduR_FrTpCopyTxData(...), Zuweisung einer freien TxPDU-ID aus dem PDU-Pool und vollständiges Einlesen des Payloads.
    • 09–10: Lokale Vorbereitung von Adressinformationen und N-PCI (Start/Consecutive Frame); Übergabe der Sendeanforderung an die untere Schicht via FrIf_Transmit(TxPDU-ID).
  3. Hardwarenaher Sendeabruf (Kontext: FrIf / ISR):
    • 11–12: FrIf ruft kurz vor dem Slot-Sendezeitpunkt FrTp_TriggerTransmit auf; FrTp kopiert die vorbereitete N-PDU direkt in den vom Treiber bereitgestellten Puffer.
    • 13–14: Nach erfolgreichem Bus-Transfer meldet FrIf den Abschluss via FrTp_TxConfirmation; FrTp dekrementiert/resettet TxPduState = "Idle".
  4. Segmentierungs-, Flusskontroll- & Abschlusslogik (Kontext: Folgender FrTp_Main):
    • 15: Nächste Ausführung von FrTp_Main.
    • 16–18 (IF Flow Control): Falls das Protokoll ein Flow Control Frame erwartet (z. B. nach First Frame oder blockweisem Transfer), verbleibt der Kanal im Wartezustand (Wait until FlowControl is received), bis der Empfang quittiert wird.
    • 19–23 (IF Segmentierung/Abschluss):
      • Fall A (SDU unvollständig, Schritt 23): Rücksprung zu Schritt 06 zur Segmentierung der nächsten N-PDU.
      • Fall B (Alle SDU-Daten übertragen, Schritte 20–22): Freigabe des FrTp-Kanals, Rücksetzen von TX_SDU_AVAILABLE und finaler Aufruf von PduR_TxConfirmation(TxSDU-ID, E_OK) zur Benachrichtigung der oberen Schichten.

4. Normative Relevanz & Entwickler-Hinweise

  • Interrupt-Kontext-Beschränkung (FrTp_TriggerTransmit): FrTp_TriggerTransmit wird üblicherweise im FlexRay-Timer-/ISR-Kontext aufgerufen. Es darf darin keine aufwendige Datenmanipulation oder Upstream-Pufferabfrage (PduR_FrTpCopyTxData) stattfinden. Die PCI und Adressdaten müssen zwingend in Schritt 09 in einem lokalen Zwischenspeicher vorassembliert vorliegen (Execution-Time-Minimierung im ISR-Pfad).
  • Puffer-Lebensdauer & PDU-Pools: Im Modus Decoupled Buffer Access muss der FrTp über dedizierte interne N-PDU-Buffer verfügen (Konfiguration via FrTpTxPduPool). Ein geteiltes Puffer-Design erfordert strikte Exklusivität zwischen FrIf_Transmit und FrTp_TxConfirmation.
  • Reentrancy & Task-Scheduling:
    • FrTp_Transmit (Taskkontext) vs. FrTp_MainFunction (Zyklischer Task) vs. FrTp_TriggerTransmit (ISR-Kontext) erfordern reentrante Schutzmechanismen (kritische Abschnitte / Schutzzonen via SchM_FrTp), insbesondere bezüglich Kanalallokation, TxPduState und Pufferindizes.
  • PduR-Kopiersemantik: Da PduR_FrTpCopyTxData bereits in FrTp_Main vor der eigentlichen Hardwareübertragung aufgerufen wird, müssen die Daten in oberen Schichten (z. B. DCM, COM) stabil gehalten bzw. direkt in den FrTp-Zwischenpuffer übergeben werden; ein Puffer-Overrun oder verfrühtes Überschreiben im oberen Layer führt zu Dateninkonsistenzen.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

06. Call routine PduR_FrTpCopyTxData(TxSDU-ID,..) 07. Allocate free TxPDU-ID | PduR | FrTp | FrIf | 01. FrTp_Transmit (TxSDU-ID,..) | 02. Evaluate TxSDU-ID 03. Allocate free channel and set connection 04. Set Flag TX_SDU_AVAILABLE (TxSDU-ID) | 05. FrTp_Main | IF: 16. FlowControl reception is expected THEN: 17. Wait until FlowControl is received ELSE: 18. Continue at step 18 | 13. FrTp_TxConfirmation | 14. Set TxPduState = „Idle“ | IF: 19. All SDU data transmitted THEN: 20. Free Channel | 21. Reset Flag TX_SDU_AVAILABLE 22. Call PduR_TxConfirmation(TxSDU-ID,..) ELSE: 23. Continue at step 6 | 15. FrTp_Main | 11. FrTp_TriggerTransmit | 12. Copy N-PDU to provided buffer | 08. Call routine PduR_FrTpCopyTxData(TxSDU-ID,..) 09. Prepare Address Information and PCI 10. Call routine FrIf_Transmit (TxPDU-ID)

Begleitender Spezifikationstext:

Figure 15 depicts the internal processing for data transmission in principle 16 if “Decoupled Buffer Access” mode is configured17. Below there is a description of the different steps which are necessary to transmit data via FrTp. … 16 Figure 15 depicts only the overview of data transmission for a single channel without further functionality (e.g. transmit cancellation) or internal behaviour (e.g. internal control data handling, return values etc.). Also a schedule for data transfer in concurrent channels is not described here. 17 Buffer access mode is configured for each N-PDU (refer to FrIf) and is referenced via the PDU-Pool.

Vorkommen in AUTOSAR-Releases (4)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R20-11 AUTOSAR_SWS_FlexRayISOTransportLayer S. 51 15 Figure 15: Transmit data overview in ‘Decoupled Buffer Access’ mode Step 01 - 10 Step 01 - 10 in ‘decoupled access mode’ are equal to step 01 – 10 in ‘immediate access mode’. Please refer chapter 7.5.2.1. For step 09 it is recommended to set the address information and PCI to a local buffer because the service primitive FrTp_TriggerTransmit is called in interrupt
R21-11 AUTOSAR_SWS_FlexRayISOTransportLayer S. 51 15 Figure 15: Transmit data overview in ‘Decoupled Buffer Access’ mode Step 01 - 10 Step 01 - 10 in ‘decoupled access mode’ are equal to step 01 – 10 in ‘immediate access mode’. Please refer chapter 7.5.2.1. For step 09 it is recommended to set the address information and PCI to a local buffer because the service primitive FrTp_TriggerTransmit is called in interrupt
R22-11 AUTOSAR_SWS_FlexRayISOTransportLayer S. 52 15 Figure 15: Transmit data overview in ‘Decoupled Buffer Access’ mode Step 01 - 10 Step 01 - 10 in ‘decoupled access mode’ are equal to step 01 – 10 in ‘immediate access mode’. Please refer chapter 7.5.2.1. For step 09 it is recommended to set the address information and PCI to a local buffer because the service primitive FrTp_TriggerTransmit is called in interrupt
R23-11 AUTOSAR_CP_SWS_FlexRayISOTransportLayer S. 50 15 Figure 15: Transmit data overview in ‘Decoupled Buffer Access’ mode Step 01 - 10 Step 01 - 10 in ‘decoupled access mode’ are equal to step 01 – 10 in ‘immediate access mode’. Please refer chapter 7.5.2.1. For step 09 it is recommended to set the address information and PCI to a local buffer because the service primitive FrTp_TriggerTransmit is called in interrupt