Figure 27: FrTp Retry Scenarios Only for case (b) Retry of PDU transfer a global switch for enabling and disabling is defined (FrTpAckType). All other cases depend on the configuration of the different counters for the API calls: FRTP_MAX_FCWAIT, FRTP_MAX_AR.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturelles Schichten- und Interaktionsdiagramm (AUTOSAR Classic Platform BSW).
• Technischer Zweck: Systematische Differenzierung zweier grundlegend verschiedener Retry-Mechanismen innerhalb des FlexRay Transport Layers gemäß Kapitel 10.4.1 und SWS_FrTp_00598:
  • Szenario (a): Lokale, vertikale BSW-Schnittstellen-Wiederholungen (API-Retries) zwischen FrTp und den angrenzenden Schichten (PduR, FrIf) bei temporären Pufferengpässen oder blockiertem Treiber.
  • Szenario (b): Horizontale, protokollbasierte End-to-End-Wiederholung (PDU-Retransmission) über das FlexRay-Netzwerk zwischen zwei FrTp-Peer-Instanzen gemäß ISO 10681-2.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte BSW-Module:
  • PduR (PDU Router): Obere Schicht (Upper Layer); Übergabe segmentierter Nutzdaten (z. B. aus Dcm oder Com) an FrTp sowie Pufferverwaltung (CopyTxData, CopyRxData).
  • FrTp (FlexRay ISO Transport Layer): Vermittlungsschicht für Segmentierung, Reassembly, Flusskontrolle, Timings und Fehlerwiederholung.
  • FrIf (FlexRay Interface): Untere Schicht (Lower Layer); Hardware-Abstraktionsschicht zur Weiterleitung der FrTp-N-PDUs an den FlexRay-Treiber (Fr).
• Schnittstellen & Interaktionspfade:
  • Vertikale Schnittstellen (Szenario a):
    • FrTp ↔ PduR: Funktionsaufrufe zur Pufferanforderung (PduR_FrTpStartOfReception, PduR_FrTpCopyRxData, PduR_FrTpCopyTxData) sowie Statusrückmeldungen (PduR_FrTpTxConfirmation, PduR_FrTpRxIndication).
    • FrTp ↔ FrIf: Sendeanforderungen via FrIf_Transmit() und Bestätigungen via FrTp_TxConfirmation().
  • Horizontale Peer-Schnittstelle (Szenario b):
    • FlexRay Bus (ISO 10681-2 Protokollrahmen): Austausch von N-PDUs (Single Frame [SF], First Frame [FF], Consecutive Frame [CF], Flow Control [FC], Acknowledgment Frame [AF]).

3. Dynamisches Verhalten & Sequenzablauf

Pfad (a): Lokale API-Wiederholungsaufrufe (Busy/Error Handling)

1. Trigger: Rückgabewert BUFREQ_E_BUSY oder E_NOT_OK beim Datenaustausch mit der PduR (Puffer temporär nicht verfügbar) oder E_NOT_OK beim Aufruf von FrIf_Transmit().
2. Ablauf: FrTp bricht die Übertragung nicht sofort ab, sondern initiiert in nachfolgenden Zyklen der FrTp_MainFunction() erneute API-Aufrufe.
3. Abbruchkriterien & Zähler:
   • FRTP_MAX_AR / Parameter FrTpMaxAr: Begrenzt die maximale Anzahl lokaler Sendeversuche (FrIf_Transmit) bei Fehlschlägen.
   • FRTP_MAX_FCWAIT / Parameter FrTpMaxFcWait: Begrenzt die Anzahl zulässiger FC(WAIT)-Rahmen bei Pufferengpässen der Gegenstelle.
   • Bei Überschreitung: Abbruch der Übertragung, Freigabe der Ressourcen und Benachrichtigung an PduR mit NTFRSLT_E_NOT_OK.

Pfad (b): PDU-Retransmission (Transportprotokoll-Ebene)

1. Trigger: Verlust eines Consecutive Frames (CF), Empfang eines negativen Acknowledgments (NACK) oder Timeout des Bestätigungstimers im Acknowledged Mode.
2. Ablauf: Die Sender-FrTp wiederholt das Senden eines oder mehrerer bereits übertragener Frames über den FlexRay-Cluster.
3. Steuerung & Aktivierung: Ausschließlich über den globalen Konfigurationsparameter FrTpAckType aktivierbar (FRTP_ACK_WITH_RT). Ist unquittierter Modus konfiguriert (FRTP_NO_ACK), unterbleibt jede netzwerkseitige PDU-Wiederholung.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsverifikation (SWS_FrTp_00598):
  • Konfiguratoren/Generatoren müssen semantisch strikt zwischen Bus-Retries (FrTpAckType) und lokalen API-Retries (FrTpMaxAr, FrTpMaxFcWait) unterscheiden.
  • FrTpAckType erfordert zwingend gepufferte Tx-PDUs im FrTp, um Segmente für einen Retransmit bereitzuhalten.
• API-Vertrag für PduR & Treiber:
  • PduR-Pufferbereitstellung darf BUFREQ_E_BUSY zurückgeben, muss jedoch innerhalb der durch FRTP_MAX_FCWAIT definierten Zeitspanne bereit sein, um Verbindungsabbrüche zu vermeiden.
  • Temporäre E_NOT_OK-Rückgaben von FrIf_Transmit() (z. B. Slot-Mangel im Kommunikationszyklus) werden über FrTpMaxAr abgefangen; der Stack bricht erst nach Überschreitung der konfigurierten Zählerschwelle ab.
• Laufzeit- und Speicher-Trade-off:
  • Aktivierung von Szenario (b) erhöht die Pufferanforderungen im FrTp signifikant (Tx-Puffer-Vorhaltung bis zum Empfang des AF/FC), während Szenario (a) rein zustands- und zählerbasiert im Stack abläuft.