Figure 9.2: LIN Frame Receiving Sequence Chart for LIN Slave

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt, loop, opt).
• Technischer Zweck: Spezifikation des Empfangsablaufs (Rx) für einen LIN-Slave-Knoten im AUTOSAR Classic Platform MCAL LIN-Treiber (AUTOSAR_CP_SWS_LINDriver).
• Funktionale Einordnung: Detaillierung des Signal- und Kontrollflusses zwischen Hardware-Peripherie (LinController/UART), dem MCAL-Treibermodul (Lin) und der überlagerten Schnittstelle (LinIf, abstrahiert als User) unter Berücksichtigung unterschiedlicher Mikrocontroller-Hardwarefähigkeiten (dedizierter LIN-Hardware-Controller vs. generischer UART).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Stereotypen:
  • «Peripheral» LinController/UART: On-Chip-Kommunikationshardware (dedizierte LIN-IP mit integriertem Protokoll-Handling oder einfacher UART-Transceiver).
  • «module» Lin: AUTOSAR MCAL LIN Driver. Kapselt die hardware-spezifischen Registerzugriffe, ISRs, Zustandsmaschinen und Puffer.
  • User: Repräsentiert das übergeordnete AUTOSAR-Modul, normativ das LIN Interface (LinIf).
• Schnittstellen & Interaktionssignaturen:
  • Interrupt(): Asynchroner Hardware-Interrupt der Peripherie an den Treiber.
  • LinIf_RxIndication(Lin_SduPtr): Standardisierter Upstream-Callback zur Übergabe der empfangenen SDU an die LinIf. Parameter Lin_SduPtr ist ein Zeiger auf das Datenfeld (uint8*) der empfangenen LIN-Payload.
  • Treiber-interne Operationen:
    • Copy Data from Hardware to frame buffer in RAM() (Guard: [If HW Buffer is not accessible from COM])
    • Copy byte from UART Hardware to buffer()
    • Set flag() (Guard: [Complete frame for this ECU has been received])

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm verzweigt über das Fragment alt Hardware support in zwei deterministische Pfade:

Pfad 1: Dedizierter Hardware-Controller ([Hardware LIN Controller])

1. Trigger: Hardware verarbeitet Frame-Synchronisation, Identifier, Nutzdaten sowie Checksumme autonom und signalisiert den vollständigen Empfang per Interrupt() an den Lin-Treiber.
2. Datenbereitstellung: Falls der Peripheriepuffer nicht direkt aus dem Host-Speicherraum adressierbar ist (z. B. dedizierter FIFO/Register-SRAM), kopiert der Treiber die Nutzdaten in einen RAM-Puffer (Copy Data from Hardware to frame buffer in RAM()).
3. Upstream-Benachrichtigung: Der Treiber ruft synchron den Callback LinIf_RxIndication(Lin_SduPtr) auf.
4. Abschluss: Nach Rückkehr des Callbacks wird die Interrupt-Behandlung in der Hardware quittiert/beendet.

Pfad 2: Standard-UART-Betrieb ([Simple UART])

1. Byte-Empfangsschleife (loop Per received byte):
   • Jedes eintreffende Byte löst einen Interrupt() aus.
   • Der Treiber liest das Datenregister aus und sichert das Byte im Software-Puffer (Copy byte from UART Hardware to buffer()).
   • Protokoll-Auswertung: Sobald alle erwarteten Bytes des für dieses Steuergerät bestimmten Frames vorliegen, setzt der Treiber den Frame-Status ([Complete frame for this ECU has been received]:Set flag()).
2. Frame-Abschluss (opt Last byte received):
   • Beim Empfang des letzten Bytes (inkl. Checksumme) wird innerhalb des Interrupt-Kontexts LinIf_RxIndication(Lin_SduPtr) aufgerufen.
   • Quittierung und Verlassen der ISR.

4. Normative Relevanz & Entwickler-Hinweise

• CPU-Last & ISR-Latenz:
  • Im UART-Modus erzeugt der LIN-Slave eine erhebliche Interrupt-Last (ein ISR-Einsprung pro Frame-Byte). Timing-kritische Tasks müssen gegen UART-ISRs abgesichert werden.
  • Da LinIf_RxIndication direkt im ISR-Kontext aufgerufen wird, müssen Callbacks im LinIf minimal gehalten werden (keine blockierenden Aufrufe, Entkopplung via PDU-Router/COM-Queues).
• Speicher- und Zeigervalidität:
  • Der übergebene Zeiger Lin_SduPtr referenziert den internen Treiber-Puffer. Dieser Puffer ist nur während der Ausführung von LinIf_RxIndication garantiert gültig und wird beim nächsten Frame-Header überschrieben. Die überlagerte Schicht muss Nutzdaten synchron kopieren.
• Treiber-Konfiguration (BSW-Design):
  • Die Wahl zwischen Pfad 1 und 2 ist hardware- und konfigurationsabhängig (LinChannel-Architektur des jeweiligen Mikrocontroller-Derivats).
  • Bei einfachen UARTs muss der Treiber die gesamte Frame-Validierung (Break-Detection, Sync-Field 0x55, PID-Paritätsprüfung und Enhanced/Classic Checksum) komplett softwarebasiert im ISR-Zustandsautomaten abbilden.