Figure 9.1: CanIf to COM I-PDU reception

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des synchronen 1:1-Empfangspfads einer unfragmentierten Kommunikations-PDU (I-PDU) von der unteren Abstraktionsschicht (Communication Interface) zur oberen Kommunikationsschicht (COM).
• Architektur-Einordnung: AUTOSAR Classic Platform (CP), Schichtenmodell der Basissoftware (BSW). Veranschaulicht die Rolle des PDU Routers (PduR) als zustandsloser Dispatcher bei direkter Routing-Beziehung ohne Gateway-Kopplung und ohne Zwischenpufferung (PduRBuffer = 0).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / BSW-Module (Stereotyp «module»):
  • CanIf (CAN Interface, Lower Layer / <User:Lo>): Treiberabstraktion für CAN-Controller/Transceiver, Initiator des Empfangsevents.
  • PduR (PDU Router): Zentraler BSW-Router im Service Layer zur Entkopplung und Weiterleitung von PDUs.
  • Com (AUTOSAR COM, Upper Layer / <User:Up>): Signalorientierte Verarbeitungsschicht (Signal-Extraktion, Filterung, Benachrichtigung der Applikation via RTE).
• Schnittstellen & Signaturen:
  • PduR_<User:Lo>RxIndication(PduIdType RxPduId, const PduInfoType* PduInfoPtr):
    • Konkrete Instanz: PduR_CanIfRxIndication(...).
    • Parameter: RxPduId (Quell-ID aus Sicht des CanIf), PduInfoPtr (Zeiger auf SduDataPtr, MetaDataPtr, SduLength).
  • Com_RxIndication(PduIdType RxPduId, const PduInfoType* PduInfoPtr):
    • Ziel-API des COM-Moduls, aufgerufen mit der konfigurierten Ziel-PDU-ID (ComRxPduId).
• Interne Aktionen & Notizen:
  • copy buffer(): Lokale Pufferoperation innerhalb des Com-Moduls (Kopieren der Nutzdaten aus dem temporären RX-Treiberpuffer in interne COM-Signalpuffer).
  • Annotation: "Reception of IPDU going directly to COM. No buffering in PduR is needed."

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: CanIf detektiert den erfolgreichen Empfang eines CAN-Frames (entweder via RX-Interrupt des CAN-Controllers oder zyklisch im Kontext von Can_MainFunction_Read() / CanIf_MainFunction_RxIndication()).
2. Aufruf PduR: CanIf ruft synchron PduR_<User:Lo>RxIndication(CanIfRxPduId, PduInfoPtr) auf.
3. PduR-Routing:
   • PduR führt ein O(1)-Tabellen-Lookup (Array-Indexierung anhand CanIfRxPduId) durch.
   • PduR validiert den PDU-Zustand (sofern Initialisierung und Det aktiviert sind; Det-Prüfungen auf PDUR_E_UNINIT, PDUR_E_PDU_ID_INVALID, PDUR_E_PARAM_POINTER).
   • Da es sich um Direktrouting zu Com handelt, allokiert PduR keinen Speicher und blockiert nicht.
4. Weiterleitung an Com: PduR ruft synchron Com_RxIndication(TargetComRxPduId, PduInfoPtr) auf.
5. Verarbeitung in Com (copy buffer()):
   • Das COM-Modul kopiert die Nutzdaten (PduInfoPtr->SduDataPtr) sofort synchron in seinen eigenen internen Puffer, um Signalinkonsistenzen bei nachfolgenden Re-Entrancies oder dem Überschreiben der Hardware-/Treiber-Mailbox zu verhindern.
   • Aktualisierung der Empfangs-Deadline-Überwachung (Reception Deadline Monitoring) und Auswertung von Rx-Filtern.
6. Rückkehr: Synchroner Stack-Unwind (return void) von Com über PduR zurück zu CanIf.

4. Normative Relevanz & Entwickler-Hinweise

• Ausführungskontext & Latenz:
  • Der gesamte Calltree läuft synchron im Ausführungskontext des Aufrufers (CanIf).
  • Achtung bei Interrupt-Kontext: Ist CanIfRxIndication in einem ISR-Kontext konfiguriert (CANIF_RX_INDICATION_INTERRUPT), blockiert Com_RxIndication samt Signal-Entpackung und Pufferkopie den Interrupt-Service. Bei komplexen PDUs sollte im CanIf/CAN-Treiber Polling (CanIf_MainFunction_Read) gewählt oder in Com eine signalbasierte Deferred-Verarbeitung (COM_DEFERRED) parametriert werden.
• PduR-Konfiguration:
  • Erfordert eine PduRRoutingPath-Konfiguration mit PduRSrcPdu (Referenz auf CanIf-PDU) und genau einem PduRDestPdu (Referenz auf Com-PDU).
  • PduRDestPduDataProvision muss auf DIRECT (nicht GATEWAY) konfiguriert sein; PduRQueueDepth bleibt unkonfiguriert (0), da kein TP- oder Gateway-FIFO-Puffer erforderlich ist.
• Puffer-Lebenszyklus:
  • Der Speicherbereich hinter PduInfoPtr->SduDataPtr ist nur für die Dauer des Funktionsaufrufs gültig. Der Upper-Layer (Com) muss die Daten zwingend synchron abziehen (copy buffer()); ein Speichern des Zeigers ist nach AUTOSAR-SWS unzulässig.