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.
  • determineDesiredFGSate(): desiredState: Interner Selbstaufruf von State Management zur Bestimmung der Ziel-Funktionsgruppenzustände.
  • SetState(desiredState): Synchroner Steuerungsaufruf von State Management an Execution Management.
  • Unbeschriftete gestrichelte Antwortnachricht: Asynchrone oder synchrone Quittierung des Abschlusses von SetState von Execution Management an State Management.
  • handleNewFGState(): Interner 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

Normativ verbindlich ist die Schnittstellenabfolge zwischen Anwendung, State Management und Execution Management: Zustandsänderungen erfolgen über standardisierte Service-Felder bzw. -Methoden (TriggerIn, TriggerOut) sowie den Plattform-Aufruf SetState. Die internen Methoden determineDesiredFGSate() und handleNewFGState() illustrieren die interne Logik von State Management. Der Tippfehler determineDesiredFGSate (fehlendes 't') ist im Diagrammtext exakt so spezifiziert.