Figure 9.10: Local PDU transmission on Transport Protocol from Dcm to CAN, FlexRay and LIN

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des 1:n-Multicast-Sendepfads für segmentierte I-PDUs über Transportprotokolle (TP) gemäß AUTOSAR Classic Platform SWS PDU Router (Kapitel 9.2.5).
• Architektur-Einordnung: Horizontale und vertikale Entkopplung im AUTOSAR-Kommunikationsstack. Das Diagramm modelliert das Routing einer Diagnose- oder Groß-PDU von einem einzelnen oberen Modul (Dcm, System Services) an mehrere parallele untere Kommunikations-Interfaces/Transportprotokolle (CanTp, FrTp, LinIf/LinTp, Communication Hardware Abstraction Layer) via PduR.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Module («module»):
  • Dcm: Upper Layer / Datenquelle (stellt Diagnosedaten via PDU-Buffer bereit).
  • PduR: Zentraler Router (verwaltet Routing-Table, PDU-ID-Mapping, Status der Zielkanäle und Aggregation der Bestätigungen).
  • CanTp: Lower Layer TP für CAN (ISO 15765-2).
  • FrTp: Lower Layer TP für FlexRay (ISO 10681-2).
  • LinIf: Beinhaltet das LinTp (ISO 17987-2).
• Verwendete Schnittstellen & Signaturen:
  • Initiierung (Up → PduR):
    • PduR_<User:Up>Transmit(PduIdType TxPduId, const PduInfoType* PduInfoPtr) → Std_ReturnType (konkret PduR_DcmTransmit).
  • Initiierung (PduR → LoTp):
    • <LoTp>_Transmit(PduIdType TxPduId, const PduInfoType* PduInfoPtr) → Std_ReturnType (hier: CanTp_Transmit, FrTp_Transmit, LinTp_Transmit).
  • Datentransfer / Puffer-Abruf (LoTp → PduR → Up):
    • PduR_<User:LoTp>CopyTxData(PduIdType id, const PduInfoType* info, RetryInfoType* retry, PduLengthType* availableDataPtr) → BufReq_ReturnType.
    • Dcm_CopyTxData(PduIdType id, const PduInfoType* info, RetryInfoType* retry, PduLengthType* availableDataPtr) → BufReq_ReturnType.
  • Sende-Bestätigung (LoTp → PduR):
    • PduR_<User:LoTp>TxConfirmation(PduIdType TxPduId, Std_ReturnType result) → void.
  • Aggregierte Bestätigung (PduR → Up):
    • Dcm_TpTxConfirmation(PduIdType TxPduId, Std_ReturnType result) → void.

3. Dynamisches Verhalten & Sequenzablauf

1. Sendeinitiierung (Synchron):
   • Dcm triggert PduR_<User:Up>Transmit(...).
   • PduR leitet den Request sequenziell und synchron an alle konfigurierten Ziel-Transportprotokolle weiter (CanTp_Transmit, FrTp_Transmit, LinTp_Transmit).
   • Nach Rückkehr der Aufrufe quittiert PduR den Sendeauftrag synchron an das Dcm.
2. Asynchroner Datentransfer (Interleaved Polling):
   • Die Ziel-TPs fordern unabhängig und asynchron Datensegmente an (CopyTxData).
   • Jedes PduR_<User:LoTp>CopyTxData(...) wird direkt als synchroner Durchstich zu Dcm_CopyTxData(...) geroutet.
   • Die Reihenfolge der Abrufe (FrTp → CanTp → LinIf) ist nicht deterministisch festgelegt, sondern hängt von Buszyklen, Frame-Größen und Flow-Control-Frames der jeweiligen Busse ab.
3. Quittierung & Aggregation:
   • Jedes TP-Modul meldet den Abschluss seiner Übertragung via PduR_<User:LoTp>TxConfirmation(id, result).
   • PduR blockiert die Weiterleitung an das Dcm, bis die letzte TxConfirmation aller gestarteten unteren TP-Ziele eingetroffen ist.
4. Ergebnisbildung:
   • Nach Eingang der letzten Quittierung ruft PduR Dcm_TpTxConfirmation(id, result) auf.
   • Aggregationsregel: Meldet mindestens ein Lower-Layer-Modul E_OK, wird E_OK an das Dcm propagiert. Nur wenn alle Ziele fehlschlagen, wird E_NOT_OK gemeldet.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Management im Upper Layer (Dcm):
  • Da die Übertragungen auf den Bussen asynchron und mit unterschiedlichen Bandbreiten laufen, greifen mehrere LoTP-Module zeitlich versetzt auf denselben linearen Datenstrom zu.
  • Das Dcm darf den Sendepuffer erst nach Empfang von Dcm_TpTxConfirmation() freigeben oder überschreiben.
• Retry-Handling (RetryInfoType):
  • Bei Multicast-TP-Verbindungen unterstützt der PduR in der Regel keine Wiederholung einzelner Segmente (TP_DATARETRY). Der Parameter retry muss von den Lower Layers entsprechend gehandhabt bzw. vom Dcm mit BUFREQ_E_NOT_OK abgelehnt werden, falls inkonsistente Wiederholungsversuche eintreffen.
• Fehlerbehandlung während Transmit:
  • Schlägt bereits ein <LoTp>_Transmit()-Aufruf synchron fehl, muss der PduR gemäß SWS-Spezifikation entscheiden, ob die verbleibenden Ziele dennoch bedient werden und wie der synchrone Rückgabewert an das Dcm gebildet wird.
• Konfigurationsaspekte (PduR_PBcfg.c / ARXML):
  • Definition eines PduRSrcPdu (Source: Dcm) mit mehreren PduRDestPdu-Referenzen (CanTp, FrTp, LinTp).
  • PduRDestPduDataProvision ist auf das Verhalten von TP-Gateways/Routings abzustimmen; RoutingPath-Flags steuern die Aggregationssemantik.