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

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten loop und horizontalen Phasen-Separatoren).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation State Management (SWS_StateManagement, Releases R24-11, R25-11), Kapitel Update session within StateMachine approach.
• Funktionale Einordnung: Koordination zwischen dem Update and Configuration Management (UCM) und dem State Management (SM) während einer Software-Aktualisierung (OTA/Flashing). Das Diagramm visualisiert Teil 1 von 2 des Ablaufs: Session-Start, Vorbereitung betroffener Funktionsgruppen/Zustandsautomaten (Überführung in einen inaktiven Zustand zur Freigabe von Ressourcen und Binaries) sowie die Verifikation nach dem Einspielen der Softwarepakete.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Service-Instanzen (Lifelines):
  • «Service» UpdateAllowedService: Service-Schnittstelle (bereitgestellt von SM bzw. genutzt durch Diagnose/Applikation), über die externe Bedingungen signalisiert werden, ob System-Updates zulässig sind (z. B. Fahrzeug im Stillstand, Parkbremse aktiv).
    • Feld: UpdateAllowed (Typ: Enum, z. B. kUpdateAllowed, kUpdateNotAllowed).
  • State Management: Zentrale funktionale Einheit der Adaptive Platform zur Orchestrierung von Funktionsgruppen (Function Groups), Prozessen und Ausführungszuständen über konfigurierte interne Zustandsautomaten (State Machines).
  • «Service» UpdateRequest: Service-Schnittstelle zwischen UCM (Client) und State Management (Server) zur Ablaufsteuerung des Update-Lebenszyklus (RequestUpdateSession, PrepareUpdate, VerifyUpdate, Rollback, Finish).
    • Feld: ResetMachineNotifier (Statusmeldung für System-Resets, initial kIdle).
• Datenstrukturen & Attribute:
  • Variable "active update session": Boolesches internes SM-Flag zur Aktivierung des Update-Modus.
  • Parameter functionGroupList: Liste der vom Update betroffenen Funktionsgruppen/StateMachines zur selektiven Deaktivierung und Verifikation.
  • Statusmarkierung "ImpactedByUpdate": Dynamische Kennzeichnung aller von den Ziel-Softwarepaketen betroffenen internen Zustandsautomaten.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: UCM starts update session

1. Berechtigung setzen: Über UpdateAllowed::Set(kUpdateAllowed) signalisiert der autorisierende Kontext der Schnittstelle UpdateAllowedService, dass ein Update zulässig ist. Das Feld UpdateAllowed wechselt auf kUpdateAllowed.
2. Session anfordern: UCM ruft die synchrone/asynchrone Methode RequestUpdateSession() auf UpdateRequest auf.
3. Session-Aktivierung ([SWS_SM_0659]):
   • SM setzt internes Flag "active update session" = true.
   • SM initialisiert das Feld ResetMachineNotifier auf kIdle.
4. Quittierung: SM antwortet UCM mit OK (Result/Promise resolved).

Phase 2: Preparing affected software for update (Innerhalb loop [UCM method calls can be performed several times])

1. Vorbereitungs-Trigger: UCM sendet PrepareUpdate(functionGroupList).
2. SM-Interne Isolierung:
   • Ermittlung aller StateMachines, die mit den in functionGroupList übergebenen Einträgen korrespondieren.
   • Markierung dieser Automaten als "ImpactedByUpdate".
   • Sperrung deren StateMachineService-Interfaces gegen externe State-Requests.
   • Unterdrückung/Blockade der assoziierten Recovery Actions (um fehlerhafte Wiederanläufe während des Updates zu verhindern).
3. Zustandsübergänge (pro markiertem Automat):
   • [SWS_SM_0633]: Transition in den Zustand PrepareUpdate (z. B. kontrolliertes Sichern von NV-Daten, Cache-Flush).
   • [SWS_SM_0634]: Nachfolgende Transition in den Zustand Off (Terminierung der zugehörigen Prozesse durch Execution Management).
4. Quittierung ([SWS_SM_0636]): Sobald alle betroffenen Automaten erfolgreich im Off-Zustand sind, sendet SM ein OK an UCM zurück.

Phase 3: UCM deploys new SoftarePackage(s) [sic]

• Artefakt-Bereitstellung: Asynchroner Schritt außerhalb von SM; UCM schreibt die neuen Binaries/Dateien in das Ziel-Dateisystem (da Prozesse gestoppt und Handles freigegeben sind).

Phase 4: Verifying updated software

1. Verifikations-Trigger: UCM ruft VerifyUpdate(functionGroupList) auf.
2. Manifest-/Konfigurations-Reload: SM lädt die geänderten Konfigurationsdateien (ARXML/Manifest-Fragmente bezüglich Execution- und State-Management).
3. Isolierungs-Erneuerung: SM identifiziert erneut betroffene StateMachines, markiert sie als "ImpactedByUpdate", blockiert weiterhin externe Service-Interfaces und Recovery Actions.
4. Verifikations-Zustandsübergang ([SWS_SM_0638]):
   • Transition der betroffenen StateMachines in den Zustand VerifyUpdate (Prozessanlauf im Verifikations-/Diagnosemodus).
5. Abschluss Quittierung ([SWS_SM_0640]): SM bestätigt die erfolgreiche Verifikation mit OK an UCM. Der loop-Block gestattet mehrere iterative Paketbearbeitungen innerhalb einer aktiven Session.

4. Normative Relevanz & Entwickler-Hinweise

• Exklusive Schnittstellensperre (State Management Implementierer): Sobald ein Automat als "ImpactedByUpdate" deklariert ist, müssen Aufrufe auf seinem jeweiligen StateMachineService abgewiesen oder gepuffert werden. Zeitgleich muss die Überwachung durch Recovery Actions (z. B. Health Channel / Supervised Entities in Execution Management) ausgesetzt werden, um falsche Deadman-/Alive-Fehlerreaktionen während des Prozess-Stopps zu unterbinden.
• Konfigurations-Reload-Integrität: Bei VerifyUpdate muss das SM fähig sein, Manifest-Updates im laufenden Betrieb ohne vollständigen POSIX-Reboot neu einzulesen (Hot-Reloading relevanter Prozess-/Funktionsgruppen-Zuordnungen).
• Applikations-Design: Benutzerapplikationen innerhalb einer betroffenen Funktionsgruppe müssen den State PrepareUpdate implementieren, um innerhalb des Timeout-Fensters offene Dateiressourcen, Netzwerk-Sockets und flüchtige Zustände geordnet freizugeben, bevor Off erzwungen wird.
• Typo-Hinweis im Standarddokument: Das Phasen-Banner enthält den Spezifikations-Tippfehler "SoftarePackage(s)" (Originaltext in SWS_StateManagement Figure 7.30).