Figure 7.31: Overview of update session within StateMachine approach (part 2 of 2)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit formalem Interaktionsrahmen (Interaction Use / Frame: Stop update session), darstellend Teil 2 von 2 des Update-Session-Ablaufs (Update session - part 2/2).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) gemäß AUTOSAR_AP_SWS_StateManagement (Releases R24-11, R25-11).
• Technischer Zweck: Spezifikation des deterministischen De-Initialisierungs- und Freigabepfads bei Beendigung einer Software-Aktualisierung (Software Cluster Update via UCM). Das Diagramm definiert das Zurücksetzen globaler Update-Sperren, die Reaktivierung suspendierter State-Machines/Recovery-Mechanismen und den geordneten Übergang des SM-Controllers in die Nachbereitungsphase (AfterUpdate).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • «Service» UpdateRequest: Service-Interface der Adaptive Platform (bereitgestellt durch State Management, konsumiert durch den Update and Configuration Management (UCM) bzw. Update Client). Dient der Transaktionssteuerung von Updates.
  • State Management: Lokale Instanz des Functional Clusters SM (zuständig für State Machines, Function Groups, Machine Life Cycle und Recovery Handling).
  • «Service» UpdateAllowedService: Service-Interface zur Abfrage von Update-Berechtigungen bei Applikationen (in Teil 1 aktiv eingebunden, hier als inaktiver Kontextteilnehmer aufgeführt).
• Zustandsvariablen & Datenstrukturen:
  • Flag "active update session": Boolescher Zustandsspeicher innerhalb von SM zur Kennzeichnung einer laufenden Update-Transaktion.
  • field ResetMachineNotifier: Field-Element der UpdateRequest-Serviceschnittstelle. Besitzt Enumerationszustände, hier aktualisiert auf kIdle.
  • Status-Attribut "ImpactedByUpdate": Dynamisches Metadaten-Tag für StateMachines, deren Ausführung und Transitionen durch die Aktualisierung tangiert sind.
  • StateMachineService: Service-Schnittstelle der einzelnen StateMachines zur Entgegennahme externer Zustandsanforderungen.
  • Zielzustand "AfterUpdate": Normativer Folgezustand des SM-internen Controllers.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger StopUpdateSession():
   • Der Update-Client (UCM) initiiert das Ende der Update-Phase über den synchronen Methodenaufruf StopUpdateSession() an der Schnittstelle UpdateRequest.
2. Session-Status-Rücksetzung ([SWS_SM_00660]):
   • SM setzt die interne Kontrollvariable "active update session" = false.
3. Notifier-Aktualisierung:
   • SM setzt das Interface-Field ResetMachineNotifier auf den Statuswert kIdle (set Notifier to kIdle), um registrierte Listener über das Ende von Reset- und Update-Aktivitäten zu informieren.
4. Methoden-Rückmeldung:
   • SM bestätigt den Aufruf an UpdateRequest synchron mit dem Statuswert OK (StopUpdateSession() :: OK).
5. Reaktivierung betroffener StateMachines ([SWS_SM_00646]):
   • SM ermittelt alle StateMachines mit gesetztem Attribut "ImpactedByUpdate".
   • Das Attribut "ImpactedByUpdate" wird gelöscht.
   • Das StateMachineService-Interface der betroffenen StateMachines wird deblockiert (Zustandswechselanforderungen von außen werden wieder angenommen).
   • Zuvor maskierte oder ausgesetzte Recovery Actions (Fehlerbehandlungsmaßnahmen des SM) werden deblockiert und wieder scharfgeschaltet.
6. Controller-Transition:
   • SM-interner Zustandsübergang: Der Controller wechselt via Self-Transition in den Zustand "AfterUpdate" zur Einleitung des regulären Nach-Update-Betriebs.

4. Normative Relevanz & Entwickler-Hinweise

• API- und Servicevertrag (UpdateRequest):
  • StopUpdateSession() darf erst aufgerufen werden, wenn UCM alle Verifikations- und Bereitstellungsschritte (Payload-Ablage, Partition-Sync) vollständig abgeschlossen hat. Der Rückgabewert OK garantiert, dass SM keine update-spezifischen Sperren mehr hält.
• Verhalten von Applikationen & Function Groups:
  • Während einer aktiven Update-Session abgewiesene oder gepufferte Requests auf StateMachineService werden erst nach Abarbeitung von SWS_SM_00646 wieder verarbeitet. Applikationsentwickler müssen Timeouts und Retry-Logiken an StateMachineService-Proxies auf diesen Verriegelungszeitraum auslegen.
• Sicherheits- & Fehlerbehandlungsrelevanz (Recovery Actions):
  • Während des Updates unterdrückte Sicherheits- und Recovery-Reaktionen (z. B. Prozess-Neustarts via Execution Management oder Machine Resets bei Watchdog-/Dem-Events) greifen ab Schritt 5 unmittelbar wieder. Liegen latente Fehlerbedingungen vor, werden diese direkt nach Aufhebung der Blockade wirksam.
• Konfiguration & Modellierung (ARXML):
  • State-Machine-Modellierer müssen im Manifest sicherstellen, dass Transitionen aus dem Zustand "AfterUpdate" in den regulären Operational-Zustand wohldefiniert sind und alle notwendigen Nachprüfungen (z. B. Versionsquittierung, Health-Checks) abbilden.