Figure 9.14: Gateway of I-PDU from CAN to CAN and Com

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektonische Einordnung: AUTOSAR Classic Platform (CP), Schichten Communication Services (Com, PduR) und Communication Hardware Abstraction (CanIf).
• Technischer Zweck: Spezifikation eines synchronen 1:N-Multicast-Routingpfads (Fan-Out). Eine auf Buskanal CAN1 eingehende I-PDU wird durch den PDU Router (PduR) simultan an die lokale Applikationsebene (Com) zugestellt und parallel als Direkt-Gateway auf Buskanal CAN2 via CanIf weitergeleitet.

2. Komponenten, Entitäten & Schnittstellen

• Module («module»):
  • CanIf: CAN Interface. Tritt in dualer Rolle auf: Ingress-Abstraktion für CAN1 (Rx) und Egress-Abstraktion für CAN2 (Tx).
  • PduR: PDU Router. Protokollagnostische Routing-Engine zur statischen Weiterleitung von I-PDUs.
  • Com: AUTOSAR Communication Module. Lokale Senke zur Entpackung von Signalen für die RTE / SW-Cs.
• Schnittstellen & Service-APIs:
  • PduR_<User:Lo>RxIndication(PduIdType, const PduInfoType*): Generischer Rx-Callback des unteren Interface-Layers (hier instanziiert als PduR_CanIfRxIndication).
  • Com_RxIndication(PduIdType, const PduInfoType*): Synchroner Upcall zur lokalen Signaldistribution in das COM-Modul.
  • CanIf_Transmit(PduIdType, const PduInfoType*): Downcall zur Sendeanforderung auf CAN2 (Hinweis zur Spezifikationsgrafik: Der Rückgabewert Std_ReturnType ist im Diagramm fälschlich als erster Aufrufparameter visualisiert).
  • PduR_<User:Lo>TxConfirmation(PduIdType, Std_ReturnType): Asynchroner Sende-Bestätigungs-Callback von CanIf an den PduR.
• Kardinalitäten & Routing-Struktur:
  • 1:2 Fan-Out: Ein Quell-Routing-Pfad (PduRSrcPdu) verzweigt auf zwei Ziel-Pfade (PduRDestPdu), aufgeteilt in eine lokale Oberschicht (Com) und ein unteres Kommunikationsinterface (CanIf).

3. Dynamisches Verhalten & Sequenzablauf

1. Ingress-Trigger (CAN1):
   • CanIf empfängt eine CAN-PDU auf Kanal CAN1 und meldet diese synchron über PduR_<User:Lo>RxIndication(RxPduId, PduInfoPtr) an den PduR.
2. Priorisiertes Fan-Out-Routing:
   • Der PduR evaluiert die Zielpfade. Gemäß Routing-Regel wird das Ziel mit der niedrigeren PduRDestPduDataId / Routing-Path-ID zuerst bedient (hier Com).
3. Lokale Zustellung (Com):
   • Synchroner Aufruf von Com_RxIndication(RxPduId, PduInfoPtr). Com liest bzw. übernimmt die I-PDU-Daten in den lokalen Puffer; Steuerung kehrt unverzüglich zum PduR zurück.
4. Gateway-Direktweiterleitung (CAN2):
   • Im selben Kontext ruft der PduR die Schnittstelle CanIf_Transmit(TxPduId, PduInfoPtr) auf.
   • CanIf führt eine interne Datenpufferung durch (copy data()) in den Hardware-/Treiber-Mailbox-Bereich von CAN2.
   • CanIf_Transmit kehrt mit E_OK zum PduR zurück.
5. Abschluss Ingress-Kontext:
   • PduR_<User:Lo>RxIndication kehrt zu CanIf zurück. Der Rx-Kontext (Interrupt oder Task) auf CAN1 ist abgeschlossen.
6. Asynchrone Tx-Quittierung (CAN2):
   • Nach erfolgreicher physischer Übertragung auf CAN2 signalisiert der CAN-Treiber via CanIf die Sendebestätigung an den PduR mittels PduR_<User:Lo>TxConfirmation(TxPduId, E_OK).
   • Terminierung: Da Com die PDU rein empfangend konsumiert hat und kein Upper-Layer-Tx-Puffer existiert, terminiert die TxConfirmation im PduR (kein Weitertransport an Com).

4. Normative Relevanz & Entwickler-Hinweise

• Deterministische Abarbeitungsreihenfolge: Bei 1:N-Multicasts bestimmt die Reihenfolge der Zielkonfigurationen (PduRDestPdu) die Ausführungsreihenfolge der Up- und Downcalls. Zeitkritische Pfade müssen gezielt über die Routing-Path-ID bzw. Konfigurationsreihenfolge priorisiert werden.
• Ausführungskontext & Latenzkette (Synchronous Direct Gatewaying): Die Weiterleitung via CanIf_Transmit erfolgt ohne zwischengeschaltete Queue (PduRQueueDepth = 0) direkt im Thread/Interrupt-Kontext der CanIf-Rx-Indication von CAN1. Entwickler müssen sicherstellen, dass blockierende Operationen oder Mailbox-Engpässe in CAN2 nicht die Rx-Performance von CAN1 degradieren. Bei abweichenden Buszyklen oder Burst-Risiken ist ein FIFO-Puffer im PduR (PduRQueueDepth > 0) zwingend erforderlich.
• Gültigkeit des Datenzeigers (PduInfoType): Der Zeiger PduInfoPtr->SduDataPtr ist ausschließlich für die Dauer des synchronen Aufrufs gültig. Wie im Diagramm explizit durch copy data() hervorgehoben, muss das sendende Interface (CanIf) die Payload sofort in eigene Mailboxen kopieren, da der Ingress-Puffer nach Rückkehr von PduR_<Lo>RxIndication freigegeben wird.
• Reentrancy-Anforderung: CanIf wird im Rx-Pfad aufgerufen und fungiert im identischen Stackframe als Aufrufer von CanIf_Transmit. Der Treiber- und Abstraction-Layer muss reentrant für unterschiedliche Kanäle/PDU-IDs implementiert und konfiguriert sein.