Figure 4.1: State Machine of the ECU State Management

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsdiagramm (State Machine Diagram, stm EcuM States).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Basissoftware (BSW) System Services, Spezifikation AUTOSAR_CP_RS_ModeManagement.
• Funktionaler Zweck: Definition des standardisierten globalen Lebenszyklus und der Makro-Zustände eines Steuergeräts (ECU State Management, EcuM). Das Diagramm spezifiziert die obersten Kontrollphasen von Kaltstart bis Abschaltung sowie das Zusammenspiel zwischen Normalbetrieb (UP), Energiesparmodi (SLEEP) und kontrolliertem Herunterfahren (SHUTDOWN).

2. Komponenten, Entitäten & Schnittstellen

• Hauptzustände (Top-Level States):
  • STARTUP: Phase der Hardware- und Treiberinitialisierung vor und während des Betriebssystem-Starts.
  • UP (Composite State): Übergeordneter Betriebszustand bei laufendem OS und voll initialisierten BSW-Stacks.
  • SLEEP: Zustand reduzierter Leistungsaufnahme (Microcontroller im Sleep/Halt/Stop-Modus, Peripherie/Transceiver auf Wake-up konfiguriert).
  • SHUTDOWN: Phase des kontrollierten Herunterfahrens, der De-Initialisierung von Treibern/Modulen und Vorbereitung auf Power-Off oder Reset.
• Sub-Zustände innerhalb UP (Optionale EcuM-Unterstützung):
  • RUN: Regulärer Ausführungszustand für Applikations-SWCs und Netzwerkkommunikation.
  • POST_RUN: Nachlaufphase (z. B. für NvM-WriteAll, Diagnose-Nachlauf, Aktordiagnose oder Sensorkalibrierung).
• Pseudo-Zustände:
  • Initial State (Top-Level) → Eintritt in STARTUP.
  • Initial State (Composite UP) → Eintritt in RUN.
  • Final State (Composite UP) → Ende der aktiven Betriebsphase nach Freigabe.
  • Final State OFF → Vollständiges Abschalten der Spannungsversorgung (Power Latch Open).
• Schnittstellen & Entitäten:
  • Anforderer/Nutzer: BswM (Basic Software Mode Manager), Applikations-SWCs (via RTE/Schaltkontakte/RTE-Ports), COMM (Communication Manager).
  • Hardware-Abstraktion: MCU-Treiber (Mcu_SetMode), WDG-Treiber, Wake-up-Quellen (EcuM_WakeupSourceType).

3. Dynamisches Verhalten & Sequenzablauf

1. Kaltstart & Initialisierung:
   • Eintritt über Top-Level Initial-Knoten in STARTUP.
   • Transition STARTUP → UP: Wächterbedingung [Initialization of OS and low level driver modules complete] (Abschluss von EcuM_Init(), Starten des OS via StartOS()).
2. Normalbetrieb (UP) & Phasenwechsel:
   • Nach OS-Start Eintritt in den Sub-Zustand RUN.
   • RUN → POST_RUN: Trigger/Guard [POST_RUN state requested] (z. B. Zündung AUS, Applikation signalisiert Übergang in den Nachlauf).
   • POST_RUN → RUN: Trigger RUN state requested (z. B. Zündung EIN während Nachlauf, erneute Kommunikationsanforderung).
   • POST_RUN → Final State (innerhalb UP): Bedingung [RUN and POST_RUN state released] (alle SWCs/Module haben ihre RUN-/POST_RUN-Anforderungen freigegeben).
3. Energiesparmodus (SLEEP) & Wake-up:
   • UP → SLEEP: Trigger/Guard Shutdown state SLEEP requested [UP state released].
   • SLEEP → UP: Event Valid Wake-up detected (Validierung einer konfigurierten EcuM-WakeupSource via Peripherie/CAN/LIN/Timer).
4. Herunterfahren (SHUTDOWN):
   • UP → SHUTDOWN: Trigger/Guard Shutdown state RESET or OFF requested [UP state released].
   • SHUTDOWN → STARTUP: Event/Guard Reset requested (Vorbereitung und Ausführung eines Software- oder Hardware-Resets via Mcu_PerformReset).
   • SHUTDOWN → OFF: Bedingung [Power Off requested] (Abschaltung der Halteleitung/Power-Supply via SBC/PMIC).

4. Normative Relevanz & Entwickler-Hinweise

• **Zustandsfreigabe-Pflicht (Mode Arbitration):**
  • Eine Transition aus UP nach SLEEP oder SHUTDOWN ist normativ blockiert, solange [UP state released] nicht erfüllt ist. Entwickler müssen sicherstellen, dass alle registrierten Mode-User (SWCs via BswM/RTE sowie Systemdienste) ihre RUN Requests aktiv zurücknehmen (EcuM_ReleaseRUN() / BswM-Regeln).
• EcuM Fixed vs. EcuM Flex:
  • Die explizite hierarchische Modellierung der Sub-Zustände RUN und POST_RUN innerhalb von UP ist im Schaubild als optional deklariert. In modernen Architekturen (EcuM Flex) obliegt die Granularität und Arbitrierung dieser Applikationsmodi vollständig dem BswM; der EcuM fungiert primär als Treiber- und Phasen-Koordinator für Start, Sleep, Reset und Shutdown.
• NvM-Persistenz im Shutdown:
  • Im Pfad SHUTDOWN muss garantiert sein, dass das NvM_WriteAll() vor dem Verlassen des OS bzw. vor der finalen De-Initialisierung der Peripherie vollständig abgeschlossen ist (Synchronisation über BswM/EcuM-Callouts).
• Wake-up-Validierung:
  • Nach einem Wake-up aus SLEEP muss der Übergang zurück nach UP robust gegen Störimpulse sein. Ungültige Wake-ups führen über standardisierte Timeout- und Validierungsmechanismen (EcuM_CheckValidation()) zurück in den SLEEP.