Figure 7.34: Verify and prepare rollback within StateMachine approach - part 1/2

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit Interaktionsfragmenten (loop, alt) und Zustandsinvarianten.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_StateManagement, Releases R24-11 / R25-11). Spezifikation des Zusammenspiels zwischen Update and Configuration Management (UCM) und dem Functional Cluster State Management (SM) unter Verwendung des zustandsbasierten Ansatzes (StateMachine approach).
• Technischer Zweck: Modellierung der Verifikationsphase (VerifyUpdate) im Software-Update-Workflow. Das Diagramm definiert das Verhalten zur Verifikation aktualisierter Software-Cluster bzw. Function Groups vor einem finalen Commit bzw. die Fehlerindikation als Auslöser für den Rollback-Pfad (Part 1/2).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lebenslinien:
  • «Service» UpdateRequest: Service-Schnittstelle (ara::sm::UpdateRequest), über die UCM als Client standardisierte Kontroll- und Update-Befehle an State Management richtet.
  • State Management: Der funktionale Cluster, welcher die Systemzustände, Function Groups, Execution States und die interne Zustandsautomaten-Logik auf der Adaptive-Instanz orchestriert.
• Schnittstellen & Methoden:
  • VerifyUpdate(functionGroupList): Service-Methode von UpdateRequest. Übergibt die Liste der durch das Update betroffenen Function Groups an SM.
  • Rückgabewerte / Statusmeldungen: OK (positive Bestätigung) bzw. kFailed (Fehlerstatus / Abbruch).
• Entitäten & Interne Strukturen:
  • functionGroupList: Parameter mit den Bezeichnern der betroffenen Funktionsgruppen (FunctionGroup).
  • "ImpactedByUpdate" StateMachine: Zustandsautomaten-Instanzen innerhalb von SM, die direkt durch die modifizierten Softwarepakete/Funktionsgruppen beeinflusst werden.
  • VerifyUpdate StateMachine State: Spezifischer Verifikationszustand der StateMachine zur Validierung des fehlerfreien Anlaufs und der Integrität.

3. Dynamisches Verhalten & Sequenzablauf

• Vorbedingungen (Pre-conditions / Invarianten):
  1. UCM deploys SoftwarePackage(s): UCM hat die Softwarepakete auf dem Zielspeicher abgelegt bzw. entpackt.
  2. Invariante "active update session" == true: Es existiert eine autorisierte, aktive Update-Sitzung.
• Ablaufschritte & Verifikation:
  1. Trigger: UpdateRequest initiiert die Prüfung über den Methodenaufruf VerifyUpdate(functionGroupList).
  2. Rekonfiguration: SM führt intern ein reload configuration durch, um die aktualisierten Manifeste und Zustandsbeschreibungen einzulesen.
  3. Iterative Prüfung (loop): Für jede als "ImpactedByUpdate" identifizierte StateMachine triggert SM die Transition transition to VerifyUpdate StateMachine State.
  4. Verzweigung im Fehlerfall (alt [verification fails]):
     • Schlägt die Prüfung einer StateMachine fehl, wird die Schleife sofort abgebrochen (Fail-Fast).
     • [SWS_SM_00639]: SM bricht den Vorgang ab und antwortet synchron/asynchron mit kFailed an UpdateRequest.
     • Der Kontrollfluss verzweigt in den Rollback-Abschnitt (Part 2/2: PrepareRollback()).
  5. Verzweigung bei Gesamterfolg (alt [verification from all "ImpactedByUpdate" StateMachines successful]):
     • Konnten alle betroffenen StateMachines fehlerfrei in den Verifikationszustand überführt und validiert werden:
     • [SWS_SM_00640]: SM quittiert den Aufruf VerifyUpdate erfolgreich mit OK an UpdateRequest.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Fehlerbehandlung:
  • Gemäß SWS_SM_00639 gilt strikte Fehleratomarität: Ein Einzelfehler in einer StateMachine invalidiert das gesamte Update-Set. Entwickler von UCM-Client-Modulen müssen bei Erhalt von kFailed zwingend den Rollback-Pfad (PrepareRollback) einleiten; ein partieller Commit ist normativ unzulässig.
  • Gemäß SWS_SM_00640 darf OK erst zurückgemeldet werden, wenn ausnahmslos alle in functionGroupList referenzierten Automaten die Verifikation positiv abgeschlossen haben.
• Konfiguration & Manifest-Modellierung:
  • Für den StateMachine approach müssen in den ARXML-Beschreibungen die Zustände VerifyUpdate sowie die zugehörigen Transitionen für alle updatefähigen Function Groups explizit modelliert sein.
  • Das State Management muss zur Laufzeit fähig sein, Konfigurationsänderungen (reload configuration) ohne Neustart des gesamten FC State Management sicher zu verarbeiten.
• Applikations- & Stack-Integration:
  • Prozesse innerhalb der betroffenen Function Groups müssen im Zustand VerifyUpdate deterministische Self-Tests und Anlaufprüfungen durchführen und ihren Status (z. B. via Execution Management Reporting / Health Monitoring) an SM melden, damit SM den Zustandstransitions-Erfolg bewerten kann.