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

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten / Interaction Frames loop und Phasen-Separatoren).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_SWS_StateManagement (Releases R24-11, R25-11).
• Funktionale Einordnung: Dargestellt ist Teil 2/2 des Rollback- und Verifikationsablaufs im Rahmen des Software-Update-Prozesses via Update and Configuration Management (UCM) unter Nutzung des standardisierten StateMachine-Ansatzes (StateMachine approach) von State Management (SM). Das Diagramm spezifiziert die kontrollierte Außerbetriebnahme betroffener Funktionsgruppen (Function Groups) vor dem physischen Rollback durch das UCM sowie die anschließende Wiederaufnahme der Zustandsverwaltung nach Wiederherstellung des Softwarestands.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • «Service» UpdateRequest: Service-Schnittstelle (ara::com-Dienst), über welche der UCM-Client Methodenaufrufe zur Update- und Rollback-Steuerung an das State Management richtet.
  • State Management: Funktionale Kernkomponente (Platform Health & State Management), welche den Lebenszyklus, Funktionsgruppen und Ausführungszustände auf der Adaptive Core Plattform orchestriert.
• Schnittstellen & Methoden:
  • PrepareRollback(functionGroupList): Service-Methode von UpdateRequest, aufgerufen durch UCM mit der Liste aller vom Rollback betroffenen Funktionsgruppen (functionGroupList).
  • VerifyUpdate(functionGroupList): Service-Methode zur Verifikation des neu aktivierten bzw. wiederhergestellten Software-Zustands.
  • StateMachineService: Lokale/interne Schnittstelle der jeweiligen SM-Zustandsautomaten zur Entgegennahme regulärer Zustandswechselanforderungen.
• Zustände, Flags & Datenstrukturen:
  • functionGroupList: Eingangsvektor von Funktionsgruppen-Identifikatoren.
  • Status-Flag "ImpactedByUpdate": Markierung für alle Zustandsautomaten, die funktionale Abhängigkeiten zu den gelisteten Funktionsgruppen aufweisen.
  • Zielzustände der Zustandsautomaten: PrepareRollback und Off.

3. Dynamisches Verhalten & Sequenzablauf

1. Phase: Rollback-Vorbereitung (Rollback)
   • Trigger: UCM ruft synchron/asynchron PrepareRollback(functionGroupList) an der Schnittstelle UpdateRequest des State Managements auf.
   • Isolation & Blockade (SM-intern):
     • SM identifiziert alle betroffenen Zustandsautomaten anhand der functionGroupList.
     • Markierung dieser Automaten mit dem Zustand/Flag "ImpactedByUpdate".
     • Blockade der StateMachineService-Schnittstellen dieser Automaten, um konkurrierende Zustandsanforderungen von Applikationen während des Rollbacks abzuweisen.
     • Deaktivierung von Recovery Actions (z. B. durch Platform Health Management / PHM ausgelöste Wiederanläufe oder Fehlerreaktionen), um definierte Shutdowns nicht zu korrumpieren.
   • Iterative Abschaltung (loop [for each "ImpactedByUpdate" StateMachine]):
     • [SWS_SM_00642]: Transition des Zustandsautomaten in den Zustand PrepareRollback. Ermöglicht Applikationen der Funktionsgruppe, flüchtige Zustände zu sichern und Verbindungen kontrolliert abzubauen.
     • [SWS_SM_00643]: Nachfolgende Transition in den Zustand Off. Das SM signalisiert Execution Management (EM) das Terminieren der zugeordneten Prozesse.
   • Abschluss Rollback-Vorbereitung:
     • [SWS_SM_00645]: Sobald alle markierten Automaten den Zustand Off erreicht haben, quittiert SM den Aufruf mit OK an UCM via UpdateRequest.
2. Phase: Physisches Rollback (UCM deploys original SoftwarePackage(s))
   • Außerhalb des SM-Kontexts: UCM stellt die vorherigen Software-Pakete, Executables und Manifeste im Ziel-Dateisystem wieder her.
3. Phase: Verifikation des wiederhergestellten Stands (Verifying rollbacked software)
   • Trigger: UCM triggert nach Paketwiederherstellung VerifyUpdate(functionGroupList).
   • Rekonfiguration: SM lädt die wiederhergestellten Konfigurationsdaten (Execution Manifests, SM-Regel-/Zustandsbeschreibungen) neu in den Arbeitsspeicher (Reload restored StateManagement related configuration).
   • Fortführung: Übergang in die reguläre Verifikationssequenz (Anlauf der Funktionsgruppen im Verifikationsmodus, Validierung der Health-Status).

4. Normative Relevanz & Entwickler-Hinweise

• Deterministischer Shutdown vor I/O-Zugriffen: Das UCM darf Dateisysteme/Partitionen erst überschreiben, nachdem die Quittung OK gemäß [SWS_SM_00645] empfangen wurde. Dies garantiert, dass alle zu den Software-Paketen gehörenden Prozesse durch EM beendet sind (Off) und keine offenen File-Deskriptoren oder inkonsistente Shared-Memory-Segmente existieren.
• Verhinderung von Race Conditions: Entwickler von SM-Zustandslogiken müssen sicherstellen, dass während des gesetzten Flags "ImpactedByUpdate" externe Aufrufe an StateMachineService abgewiesen bzw. gepuffert werden (RD-SCOPE-LOCK) und PHM-Überwachungen für terminierende Prozesse suspendiert sind.
• Applikations-Design: Applikationen innerhalb einer betroffenen Funktionsgruppe müssen das State-Change-Signal nach PrepareRollback zwingend behandeln, um persistente Daten konsistent zurückzuschreiben, bevor die Off-Transition die SIGTERM/SIGKILL-Kaskade über EM initiiert.
• Konfigurationssynchronizität: Der Schritt Reload restored StateManagement related configuration erzwingt, dass SM nach einem Rollback keine veralteten In-Memory-Modelle (Zustandsdefinitionen, Timeouts, Prozesszuordnungen) der fehlgeschlagenen Update-Version mehr hält, sondern die geparsten Manifeste atomar re-initialisiert.