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 Interaktionen (mit expliziter Kennzeichnung informativer Anteile):

• SetState(FunctionGroupState): Normative Anforderung des Zustandswechsels an EM.
• «aapInformative» startStateTransition(old, new): Informative Ankündigung des Zustandswechsels an PHM.
• «aapInformative» determineObsoleteProcesses(): Informativer EM-interner Aufruf zur Bestimmung zu beendender Prozesse.
• processTerminating(process) «aapInformative»: Informative Benachrichtigung an PHM vor Beendigung eines Prozesses.
• «aapInformative» stopSupervision(): Informativer PHM-interner Aufruf zur Deaktivierung der Überwachung.
• SIGTERM(): Normatives POSIX-Terminierungssignal an die alte Anwendung.
• Deinitialize(): Normatives Herunterfahren der Core-Komponenten durch die Anwendung.
• «aapInformative» determineProcessesToStart(): Informativer EM-interner Aufruf zur Ermittlung der neu zu startenden Prozesse.
• exec() «aapInformative»: Informativer Betriebssystemaufruf zum Starten des neuen Prozesses.
• main() «aapInformative»: Informativer Programmeinstiegspunkt der neuen Anwendung.
• Initialize(): Normative Initialisierung der Core-Komponenten.
• ReportExecutionState(kRunning): Normative Ausführungsstatusmeldung der Anwendung an EM.
• processStarted(process, timestamp) «aapInformative»: Informative Benachrichtigung an PHM über den gestarteten Prozess.
• «aapInformative» startAliveSupervision(): Informativer PHM-interner Aufruf zur Aktivierung der Alive-Überwachung.
• ReportCheckpoint(): Normative 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

• Explizite Trennung zwischen normativen Schnittstellenanforderungen und informativen Implementierungsdetails («aapInformative»):
  • Normativ verbindlich sind die Schnittstellenaufrufe SetState, SIGTERM, Deinitialize, Initialize, ReportExecutionState(kRunning) und ReportCheckpoint.
  • Als informativ («aapInformative») deklariert sind die internen Kontrollflüsse (determineObsoleteProcesses, determineProcessesToStart, stopSupervision, startAliveSupervision) sowie die Interaktionen mit dem OS (exec, main) und die internen Interaktionsnachrichten zwischen EM und PHM (startStateTransition, processTerminating, processStarted).
• Die zeitliche Reihenfolge (PHM-Benachrichtigung vor SIGTERM, Überwachung nach ReportExecutionState(kRunning)) bleibt für eine fehlerfreie Koordination architektonisch maßgeblich.