Figure 10.2: Use cases for State Management

1. Diagrammtyp & Architektur-Kontext

UML-Use-Case-Diagramm zur Darstellung der Anwendungsfälle des Functional Clusters State Management innerhalb der AUTOSAR Adaptive Platform. Das Diagramm grenzt den Systemkontext der Plattform und den Teilbereich State Management gegen externe Akteure sowie angrenzende funktionale Cluster ab.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen & Subsysteme:
  • Adaptive Platform: Umfassender Systemrahmen.
  • State Management: Subsystem-/Komponentengrenze, enthält die Kern-Anwendungsfälle.
• Akteure & Komponenten:
  • Adaptive Application: Externer Standard-Akteur (UML-Stickman), der Zustandsänderungen initiiert.
  • Execution Management: Dämonbasiertes Functional Cluster («aapFunctionalCluster», daemon-based), dargestellt als Komponentenbaustein.
  • Platform Health Management: Dämonbasiertes Functional Cluster («aapFunctionalCluster», daemon-based), dargestellt als Komponentenbaustein.
• Anwendungsfälle («aapUseCase»):
  • Change System State: Zentraler Anwendungsfall zur Zustandssteuerung.
  • Recover from Supervision Failure: Anwendungsfall zur Fehlerbehandlung und Wiederherstellung nach Überwachungsfehlern.
• Beziehungen & Stereotypen:
  • Adaptive Application initiiert Change System State via Assoziation mit Stereotyp «aapTriggers».
  • Change System State bindet Execution Management über eine Assoziation mit Stereotyp «aapParticipates» ein.
  • Platform Health Management stößt Recover from Supervision Failure via Assoziation mit Stereotyp «aapTriggers» an.
  • Zwischen den Anwendungsfällen besteht eine gerichtete «include»-Abhängigkeit: Recover from Supervision Failure inkludiert zwingend Change System State (gestrichelter Pfeil zeigt nach oben auf Change System State).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet zwei Hauptauslösepfade für Zustandsänderungen ab:

1. Eine reguläre Adaptive Application triggert den Anwendungsfall Change System State. Das State Management führt die Zustandsänderung unter Beteiligung («aapParticipates») des Execution Management aus.
2. Bei Auftreten eines Überwachungsfehlers stößt das Platform Health Management den Anwendungsfall Recover from Supervision Failure an. Dieser inkludiert («include») als festen Bestandteil seiner Wiederherstellungsstrategie die Ausführung einer Zustandsänderung (Change System State), welche wiederum durch das Execution Management umgesetzt wird.

4. Normative Relevanz & Entwickler-Hinweise

Architekturrelevante Festlegung der Interaktion des State Managements:

• Das Ändern von Systemzuständen (Change System State) erfordert zwingend die Mitwirkung des Execution Management, das für das Starten, Stoppen und Umschalten von Prozessen und Funktionsgruppen zuständig ist.
• Supervision-Fehler aus dem Platform Health Management werden architektonisch so abgebildet, dass die Recovery-Logik den Anwendungsfall der Systemzustandsänderung modular einbindet («include»).
• Beide angebundenen Functional Cluster (Execution Management, Platform Health Management) sind architektonisch als Dämonen spezifiziert.