Figure 11.4: Scenario: Change System State

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm zur Interaktion im AUTOSAR Adaptive Platform Architektur-Szenario „Change System State“ (Abschnitt 11.1.2.1.1). Es beschreibt die koordinierte Zustandsänderung zwischen einer Anwendung, dem Functional Cluster State Management und dem Functional Cluster Execution Management.

2. Komponenten, Entitäten & Schnittstellen

• Akteur / Lifeline: app: Adaptive Application (Instanz einer Adaptive Application).
• Functional Cluster Lifeline: «aapFunctionalCluster» :State Management (Verwaltung von System- und Funktionsgruppenzuständen).
• Functional Cluster Lifeline: «aapFunctionalCluster» :Execution Management (Ausführungskontrolle und Umschaltung von Function Group States).
• Schnittstellen und Methoden:
  • TriggerIn_{StateGroup}::Set(value): Service-Interface-Aufruf von der Adaptive Application an State Management zur Anforderung einer Zustandsänderung.
  • «aapInformative» determineDesiredFGSate(): desiredState: Interner, informativer Selbstaufruf von State Management zur Bestimmung der Ziel-Funktionsgruppenzustände.
  • SetState(desiredState): Synchroner Steuerungsaufruf von State Management an Execution Management.
  • Unbeschriftete gestrichelte Antwortnachricht: Quittierung des Abschlusses von SetState von Execution Management an State Management.
  • «aapInformative» handleNewFGState(): Interner, informativer Selbstaufruf von State Management nach Empfang der Zustandsquittierung.
  • TriggerOut_{StateGroup}::notify(value): Benachrichtigung über das Service-Interface von State Management an die Adaptive Application über den erreichten Zustand.

3. Dynamisches Verhalten & Sequenzablauf

1. Die Adaptive Application leitet den Wechsel über TriggerIn_{StateGroup}::Set(value) an State Management ein.
2. State Management führt einen internen Aufruf determineDesiredFGSate(): desiredState aus, um den Satz gewünschter Function Group States zu berechnen.
3. State Management ruft SetState(desiredState) auf Execution Management auf; während Execution Management den Zustandsübergang verarbeitet, ist dessen Aktivierungsbalken aktiv.
4. Execution Management bestätigt den Abschluss des Zustandswechsels an State Management über eine gestrichelte Rückkehrnachricht.
5. State Management verarbeitet das Ergebnis lokal via handleNewFGState().
6. State Management informiert die Adaptive Application abschließend über TriggerOut_{StateGroup}::notify(value).

4. Normative Relevanz & Entwickler-Hinweise

Die Kennzeichnung mit «aapInformative» stellt formal klar, dass die internen Operationen determineDesiredFGSate() und handleNewFGState() reinen Informationscharakter besitzen und keine normativ vorgeschriebenen Schnittstellennamen des Functional Clusters darstellen. Verbindlich vorgegeben sind die Interaktionen über die Service-Schnittstellen (TriggerIn, TriggerOut) sowie die funktionale Interaktion mit Execution Management über SetState. Der Schreibfehler determineDesiredFGSate bleibt im informativen Methodennamen bestehen.