Figure 9: 2: LIN Frame Receiving Sequence Chart for LIN Slave

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm zur Spezifikation des AUTOSAR Classic Platform LIN-Treibers (AUTOSAR_SWS_LINDriver). Das Diagramm visualisiert das dynamische Verhalten und den Steuerfluss beim Empfang eines LIN-Frames auf einem LIN-Slave-Knoten (LIN Frame Receiving Sequence Chart for LIN Slave). Es verortet den Treiber auf der MCAL-Ebene (Microcontroller Abstraction Layer) an der Schnittstelle zwischen der physischen Hardwareperipherie («Peripheral» LinController/UART) und der oberen Softwareschicht (User, typischerweise das AUTOSAR LIN Interface LinIf). Architektonisch wird zwischen zwei Hardware-Betriebsmodi differenziert: autonomer Hardware-LIN-Controller versus softwaregestützter Empfang über eine Standard-UART-Schnittstelle.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Lebenslinien / Entitäten:
  • User: Obere Kommunikationsschicht (AUTOSAR LinIf / LIN Interface) als Empfänger der indizierten Daten.
  • «module» Lin: MCAL-Treibermodul des LIN-Subsystems zur Kapselung der Hardware und Zustandskontrolle.
  • «Peripheral» LinController/UART: Mikrocontroller-Hardwareperipherie (integrierter LIN-Hardware-Controller oder UART-Einheit).
• Nachrichten & Schnittstellen:
  • Interrupt(): Asynchrones Hardware-Interruptsignal von der Peripherie an den Treiber (Lin).
  • Copy Data from Hardware to frame buffer in RAM(): Interne Kopiermethode des Treibers zur Verlagerung empfangener Frame-Daten aus Controller-Registern/Hardware-Puffern in den RAM.
  • Copy byte from UART Hardware to buffer(): Treiberspezifische Transferoperation zum Auslesen einzelner Bytes aus dem UART-Empfangsregister in den lokalen Puffer.
  • Set flag(): Interne Zustandsaktualisierung zur Kennzeichnung eines vollständig für die eigene ECU empfangenen Frames.
  • LinIf_RxIndication(Lin_SduPtr): Normative Callback-Schnittstelle des LinIf zur Übergabe des Datenzeigers Lin_SduPtr auf die empfangene Service Data Unit (SDU).
  • Synchrone Rückkehrpfeile (gestrichelt): Signalflüsse zur Quittierung und Beendigung der jeweiligen Ausführungskontexte (ISR-Rücksprung).

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf wird durch einen übergeordneten Alternativblock (alt Hardware support) in zwei hardwareabhängige Pfade verzweigt:

1. Zweig [Hardware LIN Controller]:
   • Nach erfolgreichem Empfang und Autonomprüfung des Frames löst die Peripherie einen Frame-Interrupt() aus.
   • Guard [If HW Buffer is not accessible from COM]: Falls der Hardwarepuffer für die oberen Schichten nicht direkt lesbar ist, kopiert der Treiber die Daten über Copy Data from Hardware to frame buffer in RAM().
   • Der Treiber ruft synchron LinIf_RxIndication(Lin_SduPtr) auf der Lebenslinie User auf.
   • Nach der Rückkehr quittiert der Treiber die Bearbeitung und die ISR kehrt zur Hardware zurück.
2. Zweig [Simple UART]:
   • Gekapselt in einer Schleife loop Per received byte: Pro eintreffendem Byte generiert die UART-Peripherie einen Interrupt().
   • Der Treiber liest das Byte mittels Copy byte from UART Hardware to buffer() aus.
   • Guard [Complete frame for this ECU has been received]: Sobald alle Bytes eines für dieses Steuergerät bestimmten Rahmens vorliegen, erfolgt ein internes Set flag().
   • Optionaler Block opt Last byte received: Beim Eintreffen des letzten Bytes meldet der Treiber die Vollständigkeit synchron via LinIf_RxIndication(Lin_SduPtr) an den User.
   • Mit dem ISR-Rücksprung wird die Byte-Behandlung abgeschlossen.

4. Normative Relevanz & Entwickler-Hinweise

• Interrupt-Laufzeit & Latenzanforderungen: Im UART-Betriebsmodus resultiert der Frame-Empfang in einer dichten Folge von Einzelbyte-Interrupts. Die Treiber-ISR muss minimal gehalten werden, um Buffer-Overruns bei hohen Baudraten sicher auszuschließen.
• Kontext von LinIf_RxIndication: Der Aufruf der oberen Schicht (LinIf) erfolgt direkt im Interrupt-Kontext des MCAL-Treibers. Der Empfangscallback darf daher keine blockierenden Operationen durchführen.
• Pufferzugriff & RAM-Kopierlogik: Die Bedingung [If HW Buffer is not accessible from COM] verlangt eine hardwareabhängige Implementierungsentscheidung: Besitzt der LIN-Controller keinen direkt adressierbaren Dual-Port- bzw. Message-RAM, muss zwingend ein softwaregestützter Zwischentransfer in einen RAM-Puffer erfolgen, bevor der Zeiger Lin_SduPtr an LinIf übergeben werden darf.
• Slave-Frame-Filterung: Bei UART-Lösungen muss der LIN-Treiber die Identifier-Filterung (PID-Auswertung) und Längenüberprüfung softwareseitig abbilden, um das Vollständigkeits-Flag und die Indikation nur für eigene Botschaften auszulösen.