Figure 11.2: Scenario: Shutdown Adaptive Platform with Supervision of Adaptive Applications

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm mit Interaktionsreferenz (ref-Fragment).
• Technischer Zweck: Spezifikation des standardisierten, geordneten Herunterfahrprozesses (Graceful Shutdown) der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Koordination zwischen den Basissystem-Funktionsclustern (State Management, Execution Management, Platform Health Management), dem zugrundeliegenden POSIX-Betriebssystem und einer plattformspezifischen Shutdown-Applikation (shutdownApp), um Race Conditions, fehlerhafte Health-Reaktionen und Datenverlust beim ECU-Power-Down zu vermeiden.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Entitäten:
  • «aapFunctionalCluster» :State Management (SM): Entscheidet über systemweite Zustandsübergänge und initiiert den Plattform-Shutdown.
  • «aapFunctionalCluster» :Execution Management (EM): Verantwortlich für das Prozess-Lifecycle-Management sowie die Signalisierung auf Betriebssystemebene.
  • «aapFunctionalCluster» :Platform Health Management (PHM): Überwacht Applikationszustände (Alive/Deadline/Logical Supervision).
  • :Operating System: POSIX-konformes Betriebssystem (Prozess- und Signalverwaltung, Systemaufrufe).
  • shutdownApp: Spezifische, kurzlebige Adaptive Application zur Ausführung dedizierter Abschlussroutinen (z. B. NVM-Flush, Bus-Deinitialisierung).
• Stereotypen: «aapFunctionalCluster» (Standardisierter Kern-Cluster der Adaptive Platform Foundation).
• Schnittstellen & Interaktionsprimitive:
  • StopOffer(): Service-Deregistrierung (ara::com / Service Discovery) des PHM.
  • ref Change Function Group State (Shutdown): Gekapseltes Sequenzfragment zur Überführung einer Function Group in den Target State Off/Shutdown.
  • SIGTERM(): Standardisiertes POSIX-Terminierungssignal (Graceful Termination).
  • exec(): POSIX-Systemaufruf zur Prozessinstanziierung.
  • main(): Einstiegspunkt der Shutdown-Applikation.
  • shutdown(): Systemaufruf zur Einleitung des hardwarenahen Kernel-/OS-Shutdowns.

3. Dynamisches Verhalten & Sequenzablauf

1. Deaktivierung der Überwachung (Pre-Shutdown):
   • :State Management sendet StopOffer() an :Platform Health Management. Das PHM stellt seinen Service ein, um zu verhindern, dass das reguläre Beenden von Applikationen fälschlicherweise als Deadline-/Alive-Supervision-Verletzung interpretiert wird.
2. Zustandsübergang der Funktionsgruppe (ref):
   • Eintritt in das Interaktionsfragment Change Function Group State (Shutdown) unter Leitung des :Execution Management.
   • EM sendet SIGTERM() an :Platform Health Management; PHM terminiert (X).
   • EM startet über das :Operating System mittels exec() die dedizierte shutdownApp.
   • OS übergibt die Kontrolle über main() an shutdownApp.
3. Plattform-Abschluss & finale Beendigung:
   • Nach Abarbeitung der Shutdown-Aufgaben ruft shutdownApp shutdown() auf dem :Operating System auf.
   • Das :Operating System übernimmt die finale Phasenterminierung und sendet parallel bzw. sequenziell SIGTERM() an die verbleibenden Prozesse:
     • :State Management (terminiert X)
     • :Execution Management (terminiert X)
     • shutdownApp (terminiert sich nach Abschluss via Signal X)
   • Alle Plattform-Dienste sind beendet; das OS kann die CPU stromlos schalten oder in den Standby versetzen.

4. Normative Relevanz & Entwickler-Hinweise

• Signal-Handling (SIGTERM): Alle Adaptive Applications sowie Platform Clusters müssen zwingend einen non-blocking Signal-Handler für SIGTERM registrieren. Nach Signaleingang muss der Prozess alle Ressourcen freigeben und sich vor Ablauf des im Manifest konfigurierten terminationTimeout beenden; andernfalls erzwingt EM/OS die Beendigung via SIGKILL.
• PHM-Supervision-Lifecycle: Entwickler müssen sicherstellen, dass PHM vor den zu überwachenden Applikationen oder synchron mit der Deaktivierung der jeweiligen Function Group deregistriert wird (StopOffer), um Fehlereinträge im Diagnostic Event Manager (Dem/DM) oder unberechtigte Recovery-Aktionen (z. B. Watchdog-Reset) während des Herunterfahrens zu unterbinden.
• Rolle der shutdownApp: Die Applikation dient als definierter Synchronisationspunkt. Sie darf keine Abhängigkeiten zu bereits beendeten Functional Clustern (z. B. PHM) aufweisen und muss zustandslose Hardware-Deinitialisierungen oder persistente Speicheroperationen synchron vor dem shutdown()-Call abschließen.