Figure 7.17: Example of a shutdown procedure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Zeitliches Multicore-Ablauf- und Synchronisationsdiagramm (horizontale Ausführungsstränge / Swimlanes über vier Prozessorkerne).
• Technischer Zweck: Visualisierung des deterministischen, koordinierten Multicore-Herunterfahrprozesses im AUTOSAR Classic OS gemäß SRS_Os_80007 via ShutdownAllCores().
• Funktionale Einordnung: AUTOSAR OS (Multicore-Erweiterung, Skalierbarkeitsklassen SC3/SC4). Das Diagramm spezifiziert das koordinierte Abbrechen laufender Tasks über Core-Grenzen hinweg, die zweistufige Hook-Kaskade (lokale OS-Application-Hooks vor globalem Shutdown-Hook) sowie die zwingende Synchronisationsbarriere vor Erreichen des finalen Haltezustands.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Ausführungskerne:
  • Initiierender Core (Master/Caller, oberste Zeile): Führt TASK 3 aus und setzt den Shutdown ab.
  • Ziel-Kerne (Slaves, Zeilen 2 bis 4): Führen asynchron TASK 2, TASK 1 bzw. TASK 4 aus und empfangen den Shutdown-Befehl.
• Tasks (TASK 1 bis TASK 4): Laufende OS-Tasks mit Core-Affinität, die bei Shutdown-Eintritt abgebrochen bzw. nicht mehr weiter disponiert werden.
• Schnittstellen & Steuerungsprimitive:
  • ShutdownAllCores(StatusType Error): Systemaufruf (SWS_Os_00586), ausgelöst durch Anwendung oder BswM.
  • Inter-Core-Benachrichtigung (IPI / Cross-Core-Signal): Vektorisierte Benachrichtigung (distribute shutdown to other cores) zur Triggerung der Shutdown-Sequenz auf entfernten Cores.
  • OsApplicationShutdownHook(): Partitionsspezifische Hooks für jede auf dem jeweiligen Core konfigurierte OsApplication (SWS_Os_00587).
  • Synchronisationsbarriere (synchronize): Hardware-/Software-Rendezvous (z. B. Core-übergreifendes Spinlock-, Flag- oder Barrieren-Register, SWS_Os_00588).
  • ShutdownHook(StatusType Error): Globaler, Core-spezifisch ausgeführter OS-Shutdown-Hook nach der Barriere.
  • Finaler Halt-Zustand (Loop-Symbol): Endlosschleife / Haltezustand pro Core (SWS_Os_00762).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggerung (ShutdownAllCores): Aufruf auf dem initiierenden Core (oberste Swimlane). Der Core leitet seinen lokalen Shutdown ein und signalisiert via Inter-Core-Mechanismus an alle weiteren aktiven Cores (distribute shutdown to other cores, SWS_Os_00586).
2. Task-Terminierung: Die Ziel-Cores empfangen das Signal. Laufende Tasks (TASK 1, TASK 2, TASK 4) werden an der Wellenlinie unmittelbar unterbrochen; das Task-Scheduling wird auf allen Kernen dauerhaft deaktiviert.
3. Phase 1 – OS Application Shutdown Hooks:
   • Jeder Core ruft die OsApplicationShutdownHooks der ihm zugewiesenen OS-Applications auf (SWS_Os_00587).
   • Die Ausführungsdauern variieren pro Core (z. B. benötigt Core 4 signifikant länger als Core 1 bis 3).
4. Wartephase & Synchronisation (wait & synchronize):
   • Kerne, die ihre anwendungsspezifischen Hooks vorzeitig beenden, gehen in einen synchronisierenden Wartezustand (wait).
   • Keinem Core ist es gestattet, die Barriere (synchronize) zu überschreiten, bevor nicht alle Cores ihre OsApplicationShutdownHooks vollständig abgearbeitet haben (SWS_Os_00588).
5. Phase 2 – Globaler ShutdownHook:
   • Nach Passieren der Synchronisationsbarriere führt jeder Core zeitgleich seinen konfigurierten globalen ShutdownHook aus.
6. Terminierung (SWS_Os_00762):
   • Nach Verlassen des ShutdownHook (oder direkt nach der Barriere, falls kein Hook konfiguriert ist) sperrt das OS alle Interrupts und überführt jeden Core in eine Endlosschleife (while(1)) bzw. einen hardware-spezifischen Low-Power/Wait-Zustand (dargestellt durch die Schleifenpfeile am rechten Rand).

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration (OsOS / OsApplication):
  • OsNumberOfCores > 1 erfordert zwingend eine deterministische Inter-Core-Interrupt-Infrastruktur für den OS-Shutdown-Pfad.
  • Trennung der Hook-Ebenen: OsApplicationShutdownHook dient dem partitionslokalen Freigeben/Sichern von Applikationsressourcen; der globale OsShutdownHook dient plattformweiten Hardware-/Treiber-Abschaltungen.
• API-Restriktionen in Shutdown-Hooks:
  • Innerhalb beider Hook-Phasen sind blockierende OS-Dienste (z. B. ActivateTask, SetEvent, Alarme, Ressourcenbelegungen) strikt verboten.
  • Es dürfen nur OS-Services aufgerufen werden, die laut Spezifikation im Kontext ShutdownHook / OS-Application-Hook zulässig sind (z. B. Fehlerauslese, HW-Register-Zugriffe).
• Deterministisches Timing & Deadlock-Vermeidung:
  • Polling an der synchronize-Barriere bedeutet aktives Warten. Lange oder nicht terminierende Operationen in einem OsApplicationShutdownHook (z. B. auf Core 4) blockieren alle anderen Cores im wait-Zustand.
  • Entwickler müssen sicherstellen, dass in Phase 1 keine Inter-Core-Ressourcenabhängigkeiten bestehen, die zu einem Deadlock vor der Barriere führen.
• Fehlerpropagierung: Der an ShutdownAllCores(Error) übergebene Fehlerstatus wird unverändert als Parameter an die lokalen und globalen Shutdown-Hooks auf allen Cores durchgereicht.