DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_PlatformDesign FIG-166629c1f00adf68 933 × 1105 px 3 Release(s)

Figure 13.10: State Management during an update process

SHA-256 Inhalts-Fingerabdruck: 166629c1f00adf6893639657d0e522aa8d7bc6c93945d78a0f9bd877392ea426

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm zur Orchestrierung des State Management (SM) während eines Update-Prozesses in der AUTOSAR Adaptive Platform (AP). Das Diagramm stellt das Zusammenspiel zwischen Update and Config Management (UCM Master / UCM Sub), State Management, Execution Management (EM), einer Benutzeranwendung (Application) und dem Functional Cluster Persistency über verschiedene Aktualisierungsphasen (Ready, Activating, Verifying, Activated, Cleaning-up) dar.

2. Komponenten, Entitäten & Schnittstellen

  • Lebenslinien / Akteure:
    • UCM master (from Actors): Übergeordneter Koordinator des Update-Vorgangs.
    • UCM sub 1 (from Actors): Lokale Instanz zur Durchführung der SoftwareCluster-Aktualisierung.
    • SM (from Actors): State Management, verwaltet Zustandsübergänge der Funktionsgruppen und initiiert Maschinenaktionen.
    • EM: Execution Management, steuert Prozesslebenszyklen und Zustandswechsel auf Betriebssystem-/Prozessebene.
    • Application: Ausführende Benutzerapplikation bzw. betroffener Prozess.
    • Persistency: Functional Cluster für persistente Datenspeicherung und Datenmigration/Backup.
  • Schnittstellen / Aufrufe:
    • Activate(), :Activate success: Aktivierungsbefehl und Quittierung zwischen UCM Master und UCM Sub.
    • DependencyCheck(): Interne Prüfung auf UCM-Ebene.
    • StartUpdateSession(), StopUpdateSession(): Session-Verwaltung zwischen UCM und SM.
    • PrepareUpdate(vector<FunctionGroup>), :Prepared: Update-Vorbereitung der Funktionsgruppen.
    • SetState(Off), SetState(Verify), SetState(): Zustandssteuerungsaufrufe von SM an EM.
    • SIGTERM(), :exitstatus: Prozessbeendigung durch EM.
    • ara::core::Deinitialize(), Close storages & Free resources(): Geordnetes Herunterfahren und Freigabe von Persistenzressourcen durch die Applikation.
    • ResetMachine(): Maschinenreset-Anforderung von UCM an SM.
    • Symlinks or A/B switch(): Umschalten der Software-Partitionen/Verzeichnisse.
    • Reparse Manifests(): Lokales Neueinlesen der Manifeste.
    • VerifyUpdate(vector<FunctionGroup>), :Verified: Verifikationsanforderung an SM.
    • Spawn process(): Prozessstart durch EM.
    • UpdatePersistency(), Data backup(), Install and/or update persisten data(): Datenaktualisierungs- und Migrationsroutinen der Persistenz.
    • Finish(): Abschlusskoordination zwischen UCM Master und UCM Sub.
    • Normal(), OpenXXX(), CleanUp backup data(): Wiederanlauf der Applikation und Bereinigung temporärer Backup-Daten.

3. Dynamisches Verhalten & Sequenzablauf

  1. Activating: UCM Master sendet Activate() an UCM Sub 1. UCM Sub 1 führt DependencyCheck() aus und öffnet mit StartUpdateSession() eine Session bei SM (:ReadyForUpdate).
  2. loop for each SoftwareCluster (Prepare): UCM Sub 1 sendet PrepareUpdate(vector<FunctionGroup>) an SM. SM beauftragt EM via SetState(Off) mit dem Herunterfahren betroffener Prozesse. EM sendet SIGTERM() an die Application. Diese ruft ara::core::Deinitialize() auf, schließt Speicher/Ressourcen via Persistency (Close storages & Free resources()) und meldet :exitstatus an EM zurück, woraufhin SM das :Prepared an UCM Sub 1 zurückliefert. UCM Sub 1 meldet :Activate success an UCM Master.
  3. Verifying: UCM Sub 1 schaltet Versionen um (Symlinks or A/B switch()).
    • alt ReparseManifest:
      • Zweig [Reset]: UCM Sub 1 ruft ResetMachine() an SM auf.
      • Zweig [No Reset]: UCM Sub 1 führt intern Reparse Manifests() aus.
  4. loop for each SoftwareCluster (Verify): UCM Sub 1 ruft VerifyUpdate(vector<FunctionGroup>) an SM auf. SM signalisiert EM SetState(Verify), worauf EM mit Spawn process() die Application startet. Diese stößt UpdatePersistency() an Persistency an (beinhaltet Data backup() sowie Install and/or update persisten data()). Nach Rückkehr meldet SM :Verified an UCM Sub 1.
  5. Activated & Cleaning-up: UCM Master koordiniert mit Finish() die Aktivierung. UCM Sub 1 ruft StopUpdateSession() an SM auf. SM setzt via EM mit SetState() den Normalbetrieb; EM startet oder versetzt die Application via Normal() in Betrieb, woraufhin Persistenz geöffnet (OpenXXX()) und Sicherungsdaten entfernt werden (CleanUp backup data()).

4. Normative Relevanz & Entwickler-Hinweise

  • Das Persistency-Manifest muss zusammen mit der Applikation installiert oder aktualisiert werden.
  • ara::core::Deinitialize() muss zwingend der letzte Funktionsaufruf vor Prozessbeendigung sein, um geordnete Speicherschließung und Ressourcenfreigabe sicherzustellen.
  • Ein Machine Reset ist optional und wird im SWP-Manifest (Software Package Manifest) spezifiziert.
  • Das Reparsing von Manifesten ist implementationsspezifisch. UCM muss gegebenenfalls mit weiteren Functional Clustern interagieren, um das Gelingen des Verifikationsschritts abzusichern; verweigern diese eine positive Rückmeldung, muss UCM einen Rollback auslösen.
  • Die Aktivierung mehrerer UCM Subs wird vom UCM Master über Finish() synchronisiert.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R23-11 → R24-11 normative Änderung Nachfolger: FIG-9ba085fdb2e9d37f
  • Akteure / Lebenslinien:
    • UCM master umbenannt zu V-UCM (Stereotyp geändert von (from Actors) zu (from V-UCM sequences)).
    • UCM sub 1 umbenannt zu UCM 1 (Stereotyp geändert von (from Actors) zu (from V-UCM sequences)).
    • Bei SM entfällt der Stereotyp (from Actors).
  • Sitzungsaufbau:
    • StartUpdateSession() zwischen UCM 1 und SM ersetzt durch RequestUpdateSession().
  • Maschinen-Reset & Neustart:
    • Aufruf ResetMachine() von UCM 1 an SM löst nun den asynchronen/rückwärtigen Aufruf Machine restarts() an EM/SM aus sowie die Benachrichtigung ResetMachineNotifier(): kSucessful zurück an UCM 1.
    • Notiztext zu Machine Reset ergänzt um: „After Reset, UCM continues from where the reset“.
  • Verifikationsphase:
    • Signal von EM an die Anwendung bei SetState(Verify) umbenannt von Spawn process() zu FG = Verify().
    • Notiz/Typo-Korrektur: Install and/or update persisten data() korrigiert zu Install and/or update persistent data().

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Activating | Verifying | Activated | Ready | Cleaning-up | EM UCM master | (from Actors) | UCM sub 1 | (from Actors) | SM | (from Actors) | loop for each SoftwareCluster | loop for each SoftwareCluster | alt ReparseManifest | [Reset] | [No Reset] | Persistency Application | Reparsing is implementation specific. UCM might have to interact with other Functional Clusters to make sure the Verify step will not fail. If no positive response is returned from those FCs, it should be reason for UCM to trigger a rollback. | Machine reset is optional and defined in SWP Manifest | UCM waiting for other UCM subs to get activated, coordinated by UCM Master with finish() | persistency manifest installed or updated with the application | ara::core::Deinitialize should be the last call | ara::core::Deinitialize() | VerifyUpdate(vector<FunctionGroup>) | OpenXXX() | :Prepared | Data backup() | ResetMachine() | StopUpdateSession() | PrepareUpdate(vector<FunctionGroup>) | SIGTERM() | Close storages & Free resources() | Spawn process() | Normal() | CleanUp backup data() | Finish() | StartUpdateSession() | SetState() | :ReadyForUpdate | Reparse Manifests() | Install and/or update persisten data() | :Activate success | UpdatePersistency() | :Verified | :exitstatus | Activate() | DependencyCheck() | Symlinks or A/B switch() | SetState(Verify) | SetState(Off)

Vorkommen in AUTOSAR-Releases (4)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R21-11 AUTOSAR_EXP_PlatformDesign S. 64 13.10 Figure 13.10: State Management during an update process
R21-11 AUTOSAR_EXP_PlatformDesign S. 64 13.10 Figure 13.10: State Management during an update process
R22-11 AUTOSAR_EXP_PlatformDesign S. 68 13.10 Figure 13.10: State Management during an update process
R23-11 AUTOSAR_AP_EXP_PlatformDesign S. 72 13.10 Figure 13.10: State Management during an update process