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 R24-11 / R25-11).
• 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 zum L-SDU Router (LSduR) der oberen Schicht (Upper Layer).

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: Empfangendes BSW-Modul, standardisiert an den L-SDU Router (LSduR) angebunden.
• Datenspeicher («datastore»):
  • Temporary buffer in CAN Driver: Treiber-interner Zwischenpuffer zur PDU-Restrukturierung/Normalisierung.
  • Copy data to L-PDU buffer: Zielpuffer der oberen Schicht (im Kontext des L-SDU Routers).
• 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.
  • LSduR_CanIfRxIndication(): Spezifische Schnittstellenfunktion des L-SDU Routers zur Weiterleitung empfangener L-PDUs.

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 den L-SDU Router.
     • [No]: Direkte Weiterleitung ohne Längenvalidierung.
6. Upper Layer Notifikation & Pufferung:
   • Aufruf von Call LSduR_CanIfRxIndication().
   • Ablegen/Kopieren der empfangenen Daten in den Zielpuffer («datastore» Copy data to L-PDU buffer).
7. Abschluss & Rückkehr:
   • Synchronisation an der Join-Bar aus den drei Pfaden (verworfen bei Software-Filterung, verworfen bei DLC-Check-Fehler, erfolgreicher Aufruf von LSduR_CanIfRxIndication()).
   • Synchroner Rücksprung: LSduR_CanIfRxIndication() returns gefolgt von CanIf_RxIndication() returns bis zum Aktivitätsendknoten.

4. Normative Relevanz & Entwickler-Hinweise

• Echtzeit & Interrupt-Kontext: Da der gesamte Kontrollfluss synchron im Kontext des MCAL Receive Interrupt ablaufen kann, müssen sowohl die Software-Filterung im CanIf als auch der Callback LSduR_CanIfRxIndication() streng laufzeitoptimiert und nicht-blockierend ausgeführt werden.
• Standardisierung der Oberschicht-Anbindung: Durch die Einführung des L-SDU Routers (LSduR) wird der Empfangspfad vereinheitlicht; CanIf übergibt empfangene PDUs direkt an LSduR_CanIfRxIndication(), welches das Routing an übergeordnete Module übernimmt.
• Filterungsstrategie: Für BasicCAN-Objekte erfordert das CanIf konfigurierte Filterbereiche (CanIfHrhRangeConfig) oder Software-Filtermasken. Nicht passende PDUs werden stillschweigend verworfen.
• Längenprüfung (DLC-Check): Bei aktiviertem CanIfPrivateDataLengthCheck führt eine unzureichende PDU-Länge zum Abbruch und zur Fehlermeldung CANIF_E_INVALID_DATA_LENGTH via DET. Die fehlerhafte PDU erreicht den LSduR nicht.
• Pufferung & Nebenläufigkeit: Das Kopieren in den L-PDU-Zielpuffer (Copy data to L-PDU buffer) muss thread-sicher erfolgen, falls nachgelagerte Module oder Tasks asynchron auf die PDU-Puffer zugreifen.