Figure 9.15: TP PDU On-The-Fly Gatewaying

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm) gemäß AUTOSAR-Modellierungskonventionen.
• Funktionale Einordnung: AUTOSAR Classic Platform (CP R23-11), PDU Router (PduR), Kapitel Singlecast Gateway TP I-PDU.
• Technischer Zweck: Spezifikation des ereignis- und schwellenwertgesteuerten „On-The-Fly“-Routings segmentierter Transportprotokoll-PDUs (TP I-PDUs) zwischen zwei CAN-Netzwerken (CAN1 → CAN2) über ein geteiltes Ringpuffer-/FIFO-Prinzip im PduR, ohne dass die vollständige Nachricht vor Beginn der Weitersendung im RAM zwischengespeichert werden muss (Streaming/Cut-through-Verhalten zur Latenz- und Pufferoptimierung gegenüber Store-and-Forward).

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte BSW-Module (Lifelines):
  • «module» PduR: Vermittlerinstanz auf System-/Kommunikationsebene; verwaltet Routing-Tabellen, Pufferallokation (PduRTpThreshold) und Zwischenkopieren von Nutzdaten (copy data()).
  • «module» CanTp: Unterlagerte Transportprotokoll-Schicht (LoTp = Lower Layer TP). Im Diagramm aggregiert dargestellt; fungiert rollenbasiert sowohl als RX-LoTp (Empfang der Segmente von CAN1) als auch als TX-LoTp (Segmentierung und Aussenden auf CAN2).
• Schnittstellen & API-Signaturen:
  • RX-Pfad (LoTp → PduR):
    • PduR_<User:LoTp>StartOfReception(id, *info, TpSduLength, *bufferSizePtr) → BufReq_ReturnType: Initialisierung des Empfangs und Abfrage/Reservierung des internen Puffers.
    • PduR_<User:LoTp>CopyRxData(id, *info, *bufferSizePtr) → BufReq_ReturnType: Bereitstellung empfangener Nutzdatenpakete durch CanTp an den PduR.
    • PduR_<User:LoTp>RxIndication(id, result) → void/Std_ReturnType: Signalisierung des vollständigen Empfangs der Gesamt-N-PDU auf CAN1.
  • TX-Pfad (PduR → LoTp & LoTp → PduR):
    • CanTp_Transmit(id, *info) → Std_ReturnType: Anstoß der Weitersendung auf CAN2 durch den PduR nach Erreichen des Schwellenwerts.
    • PduR_<User:LoTp>CopyTxData(id, *info, *retry, *availableDataPtr) → BufReq_ReturnType: Abfrage von Sendedaten durch CanTp während der Übertragung auf CAN2.
    • PduR_<User:LoTp>TxConfirmation(id, result) → void/Std_ReturnType: Bestätigung des vollständigen Sendens auf CAN2.
  • Interne Operationen:
    • copy data(): Synchrones Schreiben/Umkopieren von Nutzdaten aus dem RX-Buffer in den PduR-Gateway-Puffer.

3. Dynamisches Verhalten & Sequenzablauf

1. Empfangsstart (CAN1):
   • CanTp signalisiert dem PduR den Empfang einer segmentierten PDU (First Frame) via PduR_<User:LoTp>StartOfReception.
   • PduR allokiert den Pufferbereich und gibt BUFREQ_OK samt verfügbarer Puffergröße zurück.
2. Dateneingang & Schwellenwert-Auslösung:
   • CanTp liefert empfangene Daten via PduR_<User:LoTp>CopyRxData.
   • PduR führt intern copy data() in den Gateway-Ringpuffer aus.
   • Trigger: Sobald die im Puffer akkumulierte Datenmenge den konfigurierten Schwellenwert (PduRTpThreshold) erreicht, triggert der PduR asynchron die Sendeseite auf CAN2 über CanTp_Transmit.
3. Paralleles Streaming (Interleaved RX/TX):
   • CanTp fordert für die Übertragung auf CAN2 Daten via PduR_<User:LoTp>CopyTxData an.
   • Gleichzeitig/iterativ fließen weitere RX-Segmente von CAN1 über PduR_<User:LoTp>CopyRxData nach.
   • PduR gleicht die Datennachfrage der Sendeseite mit dem Zufluss der Empfangsseite ab.
4. Empfangsabschluss (CAN1):
   • Nach dem letzten Datenblock via PduR_<User:LoTp>CopyRxData meldet CanTp das vollständige Empfangsende über PduR_<User:LoTp>RxIndication.
5. Sendeabschluss (CAN2):
   • CanTp zieht die letzten verbleibenden Daten über PduR_<User:LoTp>CopyTxData ab.
   • Nach erfolgreicher Übertragung aller Segmente auf dem Bus bestätigt CanTp den Abschluss via PduR_<User:LoTp>TxConfirmation.
   • PduR gibt den allokierten TP-Puffer wieder frei.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Dimensionierung & Konfiguration (PduRTpThreshold):
  • Der Schwellenwert PduRTpThreshold bestimmt die minimale Bytezahl, die im PduR gepuffert sein muss, bevor CanTp_Transmit aufgerufen wird.
  • Vorsicht bei Jitter/Baudraten-Diskrepanzen: Ist CAN2 schneller als CAN1 (z. B. CAN-FD mit 5 Mbit/s zu klassischem CAN mit 500 kbit/s), droht ein Pufferunterlauf (Buffer Underrun). In diesem Fall liefert PduR_<User:LoTp>CopyTxData den Status BUFREQ_E_BUSY, was CanTp-seitig zum Abbruch der Übertragung führen kann, falls kein Tx-Retry konfiguriert/unterstützt wird.
• Reentrancy & Kontexttrennung:
  • Beide Aufrufpfade (CopyRxData und CopyTxData) laufen häufig in unterschiedlichen Interrupt- oder Task-Kontexten (z. B. CanTp-MainFunctions verschiedener CAN-Controller/Channels). Der PduR-Routingpuffer erfordert thread-sichere Verwaltung (Critical Sections / exklusive Bereiche bei Puffer-Pointer-Updates).
• Fehlerbehandlung:
  • Scheitert der RX-Pfad vorzeitig (z. B. PduR_<User:LoTp>RxIndication mit E_NOT_OK), muss der PduR die laufende Übertragung auf CAN2 geordnet abbrechen (Rückgabe von BUFREQ_E_NOT_OK beim nächsten CopyTxData).
  • RetryInfoType: Der PduR unterstützt bei On-The-Fly Gatewaying standardmäßig keine Neubereitstellung bereits konsumierter/überschriebener Daten (TP_DATACONF vs. TP_DATARETRY).