Figure 7.6: Receive data flow

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Aktivitätsdiagramm (Kontroll- und Datenfluss) mit vertikaler Schichtenzuordnung (Swimlane-Konzept über Layer-Tags).
• Architektur-Kontext: AUTOSAR Classic Platform (SWS CAN Interface, Release 4.3.1).
• Funktionaler Zweck: Modellierung des synchronen Empfangsdatenpfads (Rx-Datenfluss) von der Hardware-Ebene (CAN Controller) über den MCAL-Treiber (CAN Driver), die Abstraktionsschicht (CAN Interface / CanIf) bis zu den Kommunikationsmodulen der oberen Schicht (Upper Layer, z. B. PduR, CanTp, CanNm).

2. Komponenten, Entitäten & Schnittstellen

• Architektur-Schichten / Akteure:
  • CAN Controller: Hardware-Einheit, Quelle des physikalischen Bus-Ereignisses.
  • CAN Driver (MCAL): Hardware-nahe Abstraktion, verarbeitet Interrupts und Mailbox-Puffer.
  • CAN Interface (CanIf): Hardware-unabhängige PDU-Filterung, Validierung und Routing.
  • Upper Layer: Empfangende BSW-Module (z. B. PduR_CanIfRxIndication, CanTp_RxIndication, CanNm_RxIndication).
• Datenspeicher («datastore»):
  • Temporary buffer in CAN Driver: Treiber-interner Zwischenpuffer zur PDU-Restrukturierung/Normalisierung.
  • Copy data to L-PDU buffer: Zielpuffer der oberen Schicht (z. B. Routing-Buffer im PduR oder Reassembly-Buffer im CanTp).
• Entscheidungsknoten & Mailbox-Konzepte:
  • BasicCAN: Hardware-Objekt empfängt mehrere CAN-IDs → zwingende Software-Filterung im CanIf.
  • FullCAN: Hardware-Objekt ist exakt einer CAN-ID fest zugeordnet → Hardware-Filterung ausreichend.
• APIs & Callbacks:
  • CanIf_RxIndication(): Standard-MCAL-zu-CanIf-Schnittstelle.
  • Det_ReportRuntimeError(): Fehlerberichterstattung an das Development Error Tracer-Modul.
  • <User_RxIndication>(): Modul-spezifischer Callback der oberen Schicht (konfiguriert via CanIfRxPduUserRxIndicationName).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Asynchroner Receive Interrupt des CAN Controller signalisiert vollständigen Empfang eines CAN-Frames.
2. Normalisierung (CAN Driver):
   • Verzweigung Data normalization necessary?:
     • [Yes]: PDU-Nutzdaten/Header werden im MCAL-Puffer (Temporary buffer in CAN Driver) angepasst (z. B. DLC-to-Length-Mapping, CAN FD Padding/Alignment).
     • [No]: Direkter Durchstich.
3. Übergang zum CanIf: Treiber ruft synchron CanIf_RxIndication() auf.
4. Filterung (CAN Interface):
   • Verzweigung Rx L-PDU received in BasicCAN?:
     • [Yes]: Ausführung von Software filtering gegen konfigurierte HRH-Filtermasken/Bereiche.
       • [L-PDU not passed]: Frame wird verworfen; Pfad mündet direkt in die Join-Bar (keine Benachrichtigung).
       • [L-PDU passed]: Weiterleitung zur Längenprüfung.
     • [No] (FullCAN): Überspringen der Software-Filterung.
5. Data Length Check (DLC-Check):
   • Verzweigung Data Length Check enabled? (konfiguriert über CanIfPrivateDataLengthCheck):
     • [Yes] → Data Length Check failed?:
       • [Yes] (Empfangene Länge < konfigurierte Mindestlänge CanIfRxPduDataLength): Aufruf von Det_ReportRuntimeError(..., CANIF_E_INVALID_DATA_LENGTH). Abbruch der Weiterleitung; PDU wird verworfen, Synchronisation an Join-Bar.
       • [No]: Weiterleitung an Upper Layer.
     • [No]: Direkte Weiterleitung ohne Längenvalidierung.
6. Upper Layer Notifikation & Pufferung:
   • Aufruf von <User_RxIndication>().
   • Obere Schicht führt synchron Copy data to L-PDU buffer aus.
7. Terminierung: Nach Rückkehr von <User_RxIndication>() terminiert CanIf_RxIndication() an der Join-Bar und beendet die Interrupt-Behandlung.

4. Normative Relevanz & Entwickler-Hinweise

• Ausführungskontext (ISR vs. Task): Die gesamte dargestellte Kette durchläuft typischerweise den Interrupt-Kontext des CAN-Treibers (sofern CanRxProcessing nicht auf POLLING konfiguriert ist). Upper-Layer-Callbacks dürfen keine blockierenden Mechanismen oder aufwendige Berechnungen enthalten.
• Zeiger-Persistenz & Gültigkeit: Der an <User_RxIndication>() übergebene Datenzeiger (SduDataPtr) verweist auf flüchtigen Treiberspeicher/Hardware-Register. Der Upper Layer muss die Daten zwingend synchron kopieren («datastore» Copy data), bevor die Callback-Funktion zurückkehrt.
• DLC-Prüfsemantik: Der DLC-Check meldet bei Fehlschlag einen Laufzeitfehler (CANIF_E_INVALID_DATA_LENGTH) an das DET, führt jedoch zu keinem DEM-Fehlereintrag und verwirft die PDU geräuschlos gegenüber der Applikation/COM-Schicht.
• Performance-Trade-off (BasicCAN vs. FullCAN): BasicCAN spart Hardware-Mailboxen (HRHs), verlagert jedoch die Such- und Maskierungszeit (Software filtering) vollständig in den CPU-Interruptpfad des CanIf.