Figure 11.3: Scenario: Change Function Group State

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm zur Spezifikation des dynamischen Verhaltens beim Zustandswechsel einer Funktionsgruppe (Change Function Group State) im Architektur-Kontext der AUTOSAR Adaptive Platform (AP). Das Szenario veranschaulicht das Zusammenspiel zwischen Steuerungslogik, Prozesslebenszyklus-Verwaltung und Plattform-Überwachung.

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Lebenslinien und Entitäten:

• «aapFunctionalCluster» :State Management (SM): Initiator des Zustandswechsels.
• «aapFunctionalCluster» :Execution Management (EM): Zentrale Steuerungsinstanz für Prozessstarts, Terminierung und Statusverwaltung.
• :Operating System: POSIX-basiertes Betriebssystem zur Prozessinstanziierung und Signalverarbeitung.
• old: Adaptive Application 0..*: Bestehende, zu terminierende Anwendungsprozesse der vorherigen Konfiguration.
• new: Adaptive Application 0..*: Neu zu startende Anwendungsprozesse der Zielkonfiguration.
• «aapFunction...» :Core (ara::core): Basislaufzeitbibliothek der Adaptive Platform.
• «aapFunctionalCluster» :Platform Health Management (PHM): Plattformgesundheits- und Überwachungsinstanz.

Schnittstellen und Nachrichten:

• SetState(FunctionGroupState): Anforderung des Zustandswechsels an EM.
• startStateTransition(old, new): Ankündigung des Zustandswechsels an PHM.
• determineObsoleteProcesses(): EM-interne Bestimmung zu beendender Prozesse.
• processTerminating(process): Benachrichtigung an PHM vor Beendigung eines Prozesses.
• stopSupervision(): PHM-interne Deaktivierung der Überwachung.
• SIGTERM(): POSIX-Terminierungssignal an die alte Anwendung.
• Deinitialize(): Herunterfahren der Core-Komponenten durch die Anwendung.
• determineProcessesToStart(): EM-interne Ermittlung der neu zu startenden Prozesse.
• exec(): POSIX-Systemaufruf zum Starten des neuen Prozesses.
• main(): Einstiegspunkt der neuen Anwendung.
• Initialize(): Initialisierung der Core-Komponenten.
• ReportExecutionState(kRunning): Ausführungsstatusmeldung der Anwendung an EM.
• processStarted(process, timestamp): Benachrichtigung an PHM über den gestarteten Prozess.
• startAliveSupervision(): PHM-interne Aktivierung der Alive-Überwachung.
• ReportCheckpoint(): Regelmäßige Checkpoint-Meldung der Anwendung an PHM.
• Asynchrone/synchrone Rückmeldung (gestrichelter Pfeil) an SM nach Abschluss des Übergangs.

3. Dynamisches Verhalten & Sequenzablauf

1. Initiierung: State Management ruft synchron SetState(FunctionGroupState) am Execution Management auf. EM informiert PHM über startStateTransition(old, new) und ermittelt intern über determineObsoleteProcesses() die obsoleten Prozesse.
2. Terminierung (loop Terminate obsolete Processes):
   • Für jeden obsoleten Prozess sendet EM processTerminating(process) an PHM, woraufhin PHM intern stopSupervision() ausführt.
   • EM sendet SIGTERM() an den Prozess old: Adaptive Application 0..*.
   • Der Prozess ruft vor dem Beenden Deinitialize() an :Core auf und terminiert anschließend (gekennzeichnet durch das Löschkreuz X).
3. Prozessstart (loop Start Processes):
   • EM ermittelt über determineProcessesToStart() die zu startenden Prozesse.
   • Für jeden Prozess führt EM einen Systemaufruf exec() an das :Operating System aus.
   • Das Betriebssystem erzeugt die Instanz new: Adaptive Application 0..* und ruft deren main() auf.
   • Die Anwendung führt Initialize() an :Core aus und meldet ihren Status via ReportExecutionState(kRunning) an EM.
   • EM meldet an PHM processStarted(process, timestamp), woraufhin PHM intern startAliveSupervision() startet.
   • Die laufende Anwendung meldet periodisch ihren Fortschritt über ReportCheckpoint() an PHM.
4. Abschluss: Nach Abarbeitung aller Starts und Terminierungen sendet EM eine Antwort an SM zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Der Ablauf definiert das Standard-Zusammenspiel bei Zustandsübergängen von Funktionsgruppen gemäß Manifest-Konfiguration (StartupConfig).
• Kritische Sequenzierung: PHM muss vor dem Senden von SIGTERM benachrichtigt werden (processTerminating), um Fehlalarme bei der Überwachung während des Shutdowns zu verhindern.
• Die Überwachung des Shutdowns erfolgt über EM-seitig konfigurierte Timeouts (StartupConfig.timeout).
• Neue Anwendungen müssen sich nach dem Start explizit via ReportExecutionState(kRunning) bei EM melden, bevor die Alive-Überwachung durch PHM aktiv wird.