Figure 6: Block Diagram on ECU Level

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hardware-/Software-Architekturdiagramm auf Steuergeräte-Ebene (ECU Level Block Diagram) mit funktionaler Sicherheitsallokation gemäß ISO 26262 und AUTOSAR Classic Platform Schichtenmodell.
• Funktionale Einordnung: Sicherheitsarchitekturmuster zur ISO 26262-Dekomposition der Sicherheitsanforderung „Headlight“ (ASIL B) in zwei redundante Teilsysteme (2 × ASIL A(B)) innerhalb eines Front Light Module (FLM-ECU). Demonstriert das Zusammenspiel von sicherheitsrelevanten Feedback-Pfaden, Mischkritikalität (Mixed-Criticality) auf BSW-/HW-Ebene und die Rückstufung eines gemeinsamen Ansteuerkanals (SPI) auf QM.

2. Komponenten, Entitäten & Schnittstellen

Hardware-Entitäten (ECU- & Peripherie-Ebene)

• Power Supply (ASIL B): Mehrkanalige Spannungsversorgung mit Multiple Logic Supply und Voltage Regulator zur Speisung des Mikrocontrollers sowie getrennten Versorgungspfaden für Daytime Running Lights und Endstufen.
• Microcontroller ($\mu\text{C}$, ASIL B): Integriert Rechenkerne, Speicher (RAM, ROM, NVM) und Peripheriemodule (DIO, ADC, SPI, CAN-Transceiver/-Controller).
• Smart High Side Driver (2x): Intelligente Leistungstreiber für linken und rechten Scheinwerfer (PWM_headlight left, PWM_headlight right). Verfügen über integrierte analoge Stromspiegelung (* provides current feedback).
• Sicherheitshardware (extern):
  • Window-Watchdog (WD): Anbindung an $\mu\text{C}$ via SPI zur zeitlichen Programmablaufüberwachung.
  • Emergency Light Hardware / Clock: Notfall-Bypass-Hardware zur direkten Notansteuerung der Treiber (Limp-Home, gestrichelt).

Software-Architektur (AUTOSAR Classic)

• Application Layer (SWCs, ASIL B Kontext):
  • Sensor-SWC: Vorverarbeitung, Entprellung und Plausibilisierung externer Schalter- und Bus-Eingangssignale.
  • Appl.-SWCs: Zentrale Lichtsteuerungslogik, Zustandsüberwachung und Dekompositionslogik.
  • Actuator-SWC: Sollwertberechnung für die Scheinwerferintensität und Auswertung des Ist-Stromfeedbacks.
• RTE (Runtime Environment): Signal- und Funktions-Routing zwischen SWCs und dem Basissoftware-Stack via standardisierter Sender/Receiver- bzw. Client/Server-Ports.
• BSW-Module:
  • System & Memory Services: WdgM, NvM, EcuM/BswM.
  • I/O-Stack: IoHwAb, Spi, Pwm, Adc, Dio.
  • COM - Stack: Can, CanIf, PduR, Com, E2E-Protection.

Signale, Busse & ASIL-Allokation

• Eingangssignale:
  • HW_LB_OFF / LB_OFF (ASIL B): Diskreter Schaltereingang über DIO (Low Beam Off).
  • CAN_CL15 / CL15_01.CL15ON (ASIL B): Klemmenstatus (Zündung) vom Body Controller via CAN-Transceiver/-Controller.
• Ansteuerung & Aktorik:
  • set_pwm (QM): Gemeinsamer SPI-Kanal vom I/O-Stack an beide Smart High Side Driver. Die QM-Einstufung resultiert aus der Fehlerannahme, dass der Verlust von set_pwm nicht direkt zum unbeherrschbaren Totalausfall beider Scheinwerfer führt bzw. durch den Rücklesepfad beherrscht wird.
• Rücklese- & Diagnosepfade (Redundanz):
  • read_current_L / read_current_R (ASIL A(B)): Getrennte analoge Strommessleitungen der High-Side-Treiber an separate ADC-Eingänge des $\mu\text{C}$.
• Externe Diagnose/HMI:
  • LightStatus_01.LBFailure (ASIL A): Fehlersignal via COM-Stack auf den CAN-Bus zur Ausgabe an die HMI.

3. Dynamisches Verhalten & Sequenzablauf

1. Signalerfassung & Arbitrierung:
   • Klemmen- und Schalterzustände (CL15_01.CL15ON, LB_OFF) treffen zyklisch bzw. interruptgetrieben über CAN und DIO ein.
   • Der COM - Stack validiert die CAN-Botschaft (E2E/Timeout); der I/O-Stack liest den DIO-Pin ein. Die Daten werden über die RTE an die Sensor-SWC übergeben.
2. Sollwertberechnung & Aktoransteuerung (Open-Loop):
   • Die Appl.-SWCs aggregieren die Anforderungen und übergeben Steuerparameter an die Actuator-SWC.
   • Die Actuator-SWC generiert Tastverhältnis-Vorgaben für den linken und rechten Scheinwerfer.
   • Der I/O-Stack serialisiert die Daten via SPI-Master (set_pwm, QM) an die Smart High Side Driver, welche die MOSFET-Ausgänge takten.
3. Plausibilisierung & Stromüberwachung (Closed-Loop, ASIL A(B)):
   • Die Smart High Side Driver spiegeln den Laststrom proportional zurück (HW_current left/right).
   • Der I/O-Stack (Adc) sampelt synchron zur PWM-Einschaltphase die Signale read_current_L und read_current_R.
   • Die Appl.-SWCs vergleichen Ist-Strom mit Soll-Tastverhältnis zur Erkennung von Open Load, Kurzschluss oder Treiber-Fehlfunktion.
4. Fehlerreaktion & Degradation:
   • Bei Diskrepanz auf einem Kanal (z. B. linker Scheinwerfer defekt): Erkennung des Einzelausfalls innerhalb des FTTI (Fault Tolerant Time Interval).
   • Generierung der Statusmeldung LightStatus_01.LBFailure (ASIL A) via COM - Stack an das Kombiinstrument (HMI).
   • Bei Ausfall des gesamten Microcontrollers: Der externe Window-Watchdog registriert ausbleibende SPI-Trigger und aktiviert über die Emergency Light Hardware ein Hardware-Fallback.

4. Normative Relevanz & Entwickler-Hinweise

• Freedom from Interference (FFI) & Speicherschutz: Da der $\mu\text{C}$ auf ASIL B eingestuft ist, jedoch ein QM-SPI-Kanal existiert, müssen BSW und RTE strikte Partitionierung gewährleisten (OS-Applications mit Speicherschutz via MPU). QM-Treiberroutinen dürfen ASIL-A(B)- bzw. ASIL-B-Kontexte (RAM/Hardware-Register) weder korrumpieren noch blockieren.
• ADC-Triggerung vs. PWM-Phase: Treiber-Entwickler müssen die ADC-Abtastung hardwarenah an das PWM-Signal synchronisieren (Cross-Triggering Timer/PWM → ADC), um Messwerte ausschließlich im stabilen Leitend-Zustand des High-Side-Switches zu erfassen.
• Unabhängigkeit der Feedback-Pfade: Zur Erfüllung der 2 × ASIL A(B) Dekomposition müssen Common-Cause-Ausfälle (CCF) auf HW- und Treiberebene minimiert werden (z. B. getrennte ADC-Sample-and-Hold-Kanäle, galvanische/räumliche Trennung auf dem PCB-Layout, getrennte Pin-Gruppen).
• E2E-Absicherung: Das Eingangssignal CAN_CL15 (ASIL B) erfordert zwingend eine E2E-Absicherung (CRC, Sequence Counter) im COM - Stack gemäß AUTOSAR E2E Library. Die HMI-Statusmeldung LightStatus_01.LBFailure erfordert mindestens Schutz nach ASIL A.
• SPI-BUS-QM-Rechtfertigung: Die QM-Einstufung des SPI-Busses ist im Safety Concept nur zulässig, wenn ein Hängenbleiben des Busses durch die unabhängigen Rücklesepfade (read_current_*) innerhalb des sicherheitskritischen Zeitintervalls detektiert und an die HMI gemeldet werden kann.