Figure 10: OffPostOS Sequence

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm mit kombiniertem Fragment (alt / Alternative).
• Architektur-Kontext: AUTOSAR Classic Platform (Release R4.0.3), BSW System Services Schicht.
• Funktionaler Zweck: Spezifikation der finalen Shutdown-Phase (OffPostOS) innerhalb des ECU State Managers (EcuM). Die Sequenz greift unmittelbar nach Beendigung des AUTOSAR OS (ShutdownOS()) bzw. im Kontext des OS-Shutdown-Hooks, um das Steuergerät hardwarenah stromlos zu schalten (ECUM_SHUTDOWN_TARGET_OFF) oder einen gezielten Mikrocontroller-Reset auszuführen (ECUM_SHUTDOWN_TARGET_RESET).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Stereotypen:
  • «module» EcuM: Standardisiertes AUTOSAR-Basissofwaredienst-Modul (ECU State Manager), Sequenz-Koordinator.
  • Integration Code: Plattform- und hardwarespezifischer Integrationscode (ECU-Integrator Callouts / Hardware Abstraction Layer).
• Schnittstellen & Callouts:
  • EcuM_OnGoOffTwo(): Synchroner Integrations-Callout vor Einleitung der finalen Hardware-Abschaltung.
  • EcuM_AL_Reset(EcuM_ResetType): Hardware-Abstraktions-Callout (AL = Abstraction Layer) zur Ausführung eines Resets mit Übergabe des Ziel-Reset-Typs (EcuM_ResetType, z. B. Software-Reset via MCU-Treiber).
  • EcuM_AL_SwitchOff(): Hardware-Abstraktions-Callout zur Trennung der Spannungsversorgung (z. B. Rücknahme der Power-Hold-Leitung / PMIC-Ansteuerung).
• Interaktionsoperatoren:
  • alt Shutdown Target: Verzweigung anhand des zuvor konfigurierten/angeforderten Shutdown-Ziels mit den Guards [Reset] und [Off].

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / Einstieg: Die Sequenz startet nach dem regulären Herunterfahren des OS (ShutdownOS()), wenn kein Scheduling und keine Standard-OS-Dienste mehr aktiv sind.
2. Synchroner Hook: EcuM ruft EcuM_OnGoOffTwo() im Integration Code auf. Hier erfolgen letzte applikations- bzw. plattformspezifische Bereinigungen im Post-OS-Zustand. Der Aufruf blockiert synchron, bis der Integrationscode zurückkehrt.
3. Auswertung des Shutdown-Targets:
   • Pfad [Reset]: Ist das Shutdown-Target auf Reset gesetzt, ruft EcuM synchron EcuM_AL_Reset(EcuM_ResetType) auf.
   • Pfad [Off]: Ist das Shutdown-Target auf Abschaltung gesetzt, ruft EcuM synchron EcuM_AL_SwitchOff() auf.
4. Terminierung: Beide Zweige stellen funktionale Einbahnstraßen dar (No-Return-Semantik). Ein regulärer Kontrollfluss zurück zu EcuM ist nicht vorgesehen, da das System entweder unmittelbar neu startet oder stromlos wird.

4. Normative Relevanz & Entwickler-Hinweise

• Kontext-Restriktionen (Post-OS): In den Callouts EcuM_OnGoOffTwo(), EcuM_AL_Reset() und EcuM_AL_SwitchOff() dürfen keinerlei OS-Dienste (Tasks, Events, Alarme), keine RTE-Kommunikation und keine blockierenden BSW-Treiber (z. B. NvM-Schreibzyklen) aufgerufen werden. Sämtliche Peripherie muss bereits im Vorfeld deinitialisiert sein.
• Implementierungsverpflichtung: Alle drei Funktionen sind Integrations-Stubs/Callouts und müssen vom Tier-1/ECU-Integrator hardwareabhängig implementiert werden.
• Hardware-Anbindung bei EcuM_AL_SwitchOff(): Typischerweise wird hier die Power-Hold-Verriegelung (SBC/PMIC-Hold-Pin) auf Low gezogen. Falls Transceiver Wake-up-fähig bleiben müssen (z. B. CAN-Partial-Networking oder LIN-Wakeup), muss der Integrationscode vor dem Signalpegelwechsel sicherstellen, dass die SBC-Standby-Modi stabil eingenommen wurden.
• Fehlerbehandlung / Deadlock-Trap: Falls EcuM_AL_SwitchOff() fehlschlägt (z. B. Klemme 15 weiterhin aktiv oder Hardware-Defekt), darf die Funktion nicht undefiniert zurückkehren. Der Integrationscode muss in eine Endlosschleife (Fail-Safe Trap / Watchdog-Reset) übergehen, um undefinierte Zustände des Controllers zu verhindern.