Figure 9.10: Local PDU transmission on transport protocol from Dcm to CAN, FlexRay and LIN

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm aus der AUTOSAR Classic Platform Spezifikation des PDU Routers (AUTOSAR_SWS_PDURouter, Abschnitt 9.2.5 „Multicast transmission of I-PDU on transport protocol modules“). Dargestellt ist der architektonische Ablauf einer 1:n-Multicast-Übertragung eines diagnosebezogenen I-PDUs über Transportprotokolle (TP) innerhalb des AUTOSAR Communication Stacks. Der Diagnostic Communication Manager (Dcm) fungiert als quellendes Upper-Layer-Modul, der PduR als Vermittlungs- und Verteilerinstanz, und CanTp, FrTp sowie LinIf (mit integriertem LinTp) fungieren als unterlagerte Transportprotokoll-Module (Lower Layer TP). Das Diagramm spezifiziert die Koordination von Sendeanforderung, asynchronem Datenabruf (CopyTxData) und aggregierter Sende-Bestätigung (TxConfirmation).

2. Komponenten, Entitäten & Schnittstellen

Beteiligte BSW-Komponenten (Lifelines):

• «module» Dcm: Diagnostic Communication Manager als oberes Schichtmodul (Upper Layer, Datenquelle).
• «module» PduR: PDU Router als zentrale Routing- und Koordinierungsinstanz.
• «module» CanTp: CAN Transport Layer (unterlagertes TP-Modul).
• «module» FrTp: FrTp: FlexRay Transport Layer (unterlagertes TP-Modul).
• «module» LinIf: LIN Interface mit integriertem LIN Transport Layer (LinTp).

Schnittstellen und Funktionsaufrufe:

• Sendeinitiierung:
  • PduR_<User:Up>Transmit(Std_ReturnType, PduIdType, const PduInfoType*) (vom Dcm an den PduR aufgerufen).
  • CanTp_Transmit(Std_ReturnType, PduIdType, const PduInfoType*)
  • FrTp_Transmit(Std_ReturnType, PduIdType, const PduInfoType*)
  • LinTp_Transmit(Std_ReturnType, PduIdType, const PduInfoType*) (Aufruf an das Modul LinIf).
• Pufferabfrage und Datenübertragung:
  • PduR_<User:LoTp>CopyTxData(BufReq_ReturnType, PduIdType, const PduInfoType*, RetryInfoType*, PduLengthType*) (von LoTp-Modulen an PduR).
  • Dcm_CopyTxData(BufReq_ReturnType, PduIdType, const PduInfoType*, RetryInfoType*, PduLengthType*) (von PduR an Dcm).
• Sendebestätigung:
  • PduR_<User:LoTp>TxConfirmation(PduIdType, Std_ReturnType) (von LoTp-Modulen an PduR).
  • Dcm_TpTxConfirmation(PduIdType, Std_ReturnType) (vom PduR an Dcm).

3. Dynamisches Verhalten & Sequenzablauf

Der Sequenzablauf gliedert sich in drei aufeinanderfolgende Phasen:

1. Multicast-Sendeinitiierung:

Dcm ruft synchron PduR_<User:Up>Transmit(...) auf. Der PduR verteilt die Anforderung nacheinander an alle konfigurierten unterlagerten Transportprotokolle: Zunächst wird synchron CanTp_Transmit(...) aufgerufen, gefolgt von FrTp_Transmit(...) und anschließend LinTp_Transmit(...) an LinIf. Nach Erhalt der synchronen Rückgabewerte (Std_ReturnType) kehrt der Aufruf an Dcm zurück.

1. Asynchroner Datentransfer (CopyTxData):

Jedes unterlagerte TP-Modul fordert entsprechend seinem eigenen Übertragungstakt und seiner Segmentierung Sendedaten an. Im dargestellten Ablauf ruft zuerst FrTp: FrTp via PduR_<User:LoTp>CopyTxData(...) beim PduR an, welcher dies direkt per Dcm_CopyTxData(...) an den Dcm weiterleitet und die Daten zurückliefert. Anschließend erfolgen analoge Anforderungen separat durch CanTp und danach durch LinIf.

1. Aggregierte Sendebestätigung (TxConfirmation):

Nach Abschluss der jeweiligen Busübertragung signalisieren die LoTp-Module ihre Fertigstellung asynchron per PduR_<User:LoTp>TxConfirmation(...) an den PduR (im Diagramm in der Reihenfolge FrTp, CanTp, LinIf). Der PduR wartet das Eintreffen aller Bestätigungen ab. Erst beim Empfang der letzten TxConfirmation (hier von LinIf) aggregiert der PduR das Ergebnis und ruft Dcm_TpTxConfirmation(PduIdType, Std_ReturnType) auf. Laut expliziter Diagrammnote meldet der PduR dem Dcm genau dann E_OK, wenn mindestens eine der unterlagerten TxConfirmations E_OK gemeldet hat.

4. Normative Relevanz & Entwickler-Hinweise

Entwicklungs- und Integrationshinweise zur Multicast-Transportprotokollabwicklung:

• Pufferkonsistenz im Quellmodul: Da Dcm_CopyTxData mehrfach und zeitlich versetzt von verschiedenen Zielmodulen (CanTp, FrTp, LinTp) mit potenziell unterschiedlichen Blockgrößen und Übertragungsgeschwindigkeiten aufgerufen wird, muss der Dcm-Sendepuffer bis zum Eintreffen der finalen Dcm_TpTxConfirmation unverändert und gesperrt bleiben.
• Fehleraggregation: Die logische ODER-Verknüpfung der TxConfirmations (E_OK an Dcm, wenn mindestens ein unterlagertes Modul erfolgreich übertragen hat) bedeutet im Umkehrschluss, dass Teilausfälle einzelner Busse auf Dcm-Ebene nicht als Gesamtabbruch signalisiert werden, sofern wenigstens ein Pfad erfolgreich war. Entwickler müssen für deterministische Fehleranalysen zusätzliche Diagnose- oder Bus-Monitoring-Mechanismen auf BSW-/LoTp-Ebene berücksichtigen.
• Modulabstraktion LinIf: Das LIN Transportprotokoll besitzt kein eigenständiges BSW-Modul, sondern ist Bestandteil des LIN Interface (LinIf). Die Ziel-API lautet daher LinTp_Transmit, adressiert jedoch die LinIf-Instanz.
• Parameterverwaltung: Auf die korrekte Handhabung des Parameters RetryInfoType* in den TP-Copy-Aufrufen ist zu achten, falls LoTp-Module Wiederholungen oder Puffer-Offsets anfordern.