DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_PlatformDesign FIG-7f6e0aab02be3112 930 × 657 px 1 Release(s)

Figure 13.8: Overview of Processing and Activation of Software Package

SHA-256 Inhalts-Fingerabdruck: 7f6e0aab02be3112ad4f3a65ec4c286169aa7c002d7b91e9e1ce6ba3e3d6ef3a

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-description@2 · erstellt am 2026-10-07

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML-Zustandsdiagramm (State Machine Diagram / Statechart) des Composite-Zustandsraums PackageManagerStatus.
  • Technischer Zweck & Einordnung: Spezifiziert den zentralen Lebenszyklus der Paketverarbeitung im Functional Cluster Update and Configuration Management (UCM) der AUTOSAR Adaptive Platform (Interface ara::ucm::pkgmgr::PackageManager). Es definiert die formalen Zustandsübergänge bei OTA- und Werkstatt-Updates von Software-Paketen über die Phasen Bereitstellung, Validierung, Aktivierung, Laufzeitverifikation, Rollback und Ressourcenfreigabe.

2. Komponenten, Entitäten & Schnittstellen

  • Zustandsautomat / Typ: PackageManagerStatus (korrespondierend zum Datentyp ara::ucm::pkgmgr::PackageManagerStatusType).
  • Zustände und Do-Aktivitäten:
    • kIdle: Ruhezustand; keine Update-Aktivität aktiv, bereit für neue Aufträge.
    • kProcessing (do / process SW package): Dekompression, Signatur-, Hash- und Integritätsprüfung des übergebenen Software-Pakets.
    • kReady: Mindestens ein Paket erfolgreich prozessiert (ProcessedPackages > 0); bereit zur Aktivierung, Revertierung oder Weiterverarbeitung.
    • kActivating (do / DependencyCheck): Validierung statischer/dynamischer Paketabhängigkeiten, Kompatibilität der Execution-/Service-Manifeste und Vorbereitung der Partitions-/Dateisystemumschaltung.
    • kVerifying (do / MonitorApplicationRestart): Überwachung des Anwendungsneustarts und der Funktionsfähigkeit des Gesamtsystems in Kooperation mit State Management (SM) und Execution Management (EM).
    • kActivated: Neue Software-Version erfolgreich aktiv und verifiziert; wartet auf Finalisierung oder manuellen Rollback.
    • kRollingBack (do / roll back to old version): Wiederherstellung der vorherigen Software-Stände / Umschaltung auf die passive Systempartition.
    • kRolledBack: Rollback erfolgreich durchgeführt; System befindet sich wieder auf Vorversion.
    • kRollingBackFailed: Fehler beim Wiederherstellen der Vorversion (kritischer Fehlerzustand).
    • kCleaningUp (do / clean up): Bereinigung temporärer Artefakte, alter Paketbestände und Cache-Bereiche.
  • Service-Methoden / Trigger (ara::ucm::pkgmgr):
    • ProcessSwPackage: Startet/fortsetzt die sequentielle Paketverarbeitung.
    • Cancel: Bricht laufenden Verarbeitungsprozess ab.
    • Activate: Initiiert Aktivierungssequenz der im Puffer liegenden Pakete.
    • Rollback: Erzwingt Rückkehr zur Vorversion.
    • RevertProcessedSwPackages: Verwirft prozessierte Pakete vor Aktivierung.
    • Finish: Schließt Aktivierungs- oder Rollback-Vorgang verbindlich ab.
  • Interne Ereignisse & Guards:
    • Guards: [ProcessedPackages=0], [ProcessedPackages>0].
    • Interne Signale: PackageProcessed, OnSuccess, OnFailure.

3. Dynamisches Verhalten & Sequenzablauf

Nominaler Update-Ablauf (Happy Path)
  1. Initialisierung: Startknoten (Initial) setzt UCM initial auf kIdle.
  2. Paketverarbeitung: Aufruf ProcessSwPackage führt nach kProcessing. Nach Verarbeitung des Pakets (PackageProcessed [ProcessedPackages>0]) Übergang nach kReady.
  3. Multi-Package-Staging: Aus kReady kann über erneutes ProcessSwPackage zyklisch nach kProcessing gewechselt werden, um mehrere Teilpakete transaktional zu bündeln.
  4. Aktivierung: Aus kReady löst Activate den Übergang nach kActivating aus (do / DependencyCheck).
  5. Verifikation: Bei erfolgreichem Dependency-Check (OnSuccess) Übergang nach kVerifying (do / MonitorApplicationRestart). UCM signalisiert SM/EM den Neustart betroffener Prozesse oder das Umschalten von Function Groups.
  6. Commit & Cleanup: Melden alle Instanzen fehlerfreien Hochlauf (OnSuccess), geht das System nach kActivated. Der Aufruf von Finish überführt nach kCleaningUp (do / clean up), gefolgt von einer automatischen Transition zurück nach kIdle.
Abbruch- und Revert-Pfade
  • Cancel in kProcessing:
    • Cancel als Self-Transition initiiert den Abbruch.
    • Sind keine Pakete verarbeitet (Cancelled [ProcessedPackages=0]), fällt das System direkt nach kIdle zurück.
    • Existieren bereits zuvor verarbeitete Pakete (Cancelled, PackageProcessed [ProcessedPackages>0]), geht das System nach kReady.
  • Revert: Aus kProcessing sowie kReady verwirft RevertProcessedSwPackages alle gepufferten Pakete, wechselt nach kCleaningUp und kehrt nach kIdle zurück.
Fehler- und Rollback-Pfade
  • Fehlschlag bei Aktivierung: Schlägt der DependencyCheck in kActivating fehl (OnFailure), kehrt UCM unschädlich nach kReady zurück.
  • Fehlschlag bei Verifikation / Manuelles Rollback:
    • Schlägt MonitorApplicationRestart fehl (OnFailure) oder wird aus kVerifying bzw. kActivated die Methode Rollback getriggert, wechselt der Automat nach kRollingBack.
    • kRollingBack führt bei Erfolg (OnSuccess) nach kRolledBack. Ein anschließendes Finish räumt via kCleaningUp auf und führt nach kIdle.
    • Schlägt der Rollback fehl (OnFailure), wechselt UCM in den Fehlerzustand kRollingBackFailed. Aus diesem kann über einen erneuten Rollback-Aufruf ein Retry erzwungen werden.

4. Normative Relevanz & Entwickler-Hinweise

  • API-Vertrag & Fehlersignalisierung: Jeder Methodenaufruf an das UCM-Interface (ara::ucm::pkgmgr::PackageManager) außerhalb des im Diagramm definierten Ursprungszustands muss mit dem Fehlercode UcmErrorDomain::kInvalidPackageStatus bzw. kOperationNotAllowed abgewiesen werden.
  • Transaktionale Persistenz & A/B-Partitionierung:
    • Im Zustand kProcessing verarbeitete Daten müssen bis zu kCleaningUp isoliert gehalten werden (Shadow-Tree, Inactive Bank).
    • Der Systemzustand vor Activate darf erst nach vollständigem Durchlauf von kCleaningUp nach kActivated freigegeben bzw. überschrieben werden.
  • Kopplung an State Management & Watchdogs: Die Phase kVerifying ist zeit- und sicherheitskritisch. Schlägt das Erreichen der Zielzustände in ara::exec oder ara::sm innerhalb konfigurierter Timeouts fehl, muss der UCM-Treiber zwingend den Pfad OnFailure nach kRollingBack triggern, um Deadlocks der Machine zu verhindern.
  • Ressourcenfreigabe: Weder kActivated noch kRolledBack geben Speicherplatz frei. Applikations- oder Backend-Entwickler müssen sicherstellen, dass nach erfolgreicher Bestätigung zwingend Finish() aufgerufen wird, da persistenter Flash-Speicher andernfalls bis zum Erreichen von kCleaningUp durch Altversionen blockiert bleibt.

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

R23-11 → R24-11 normative Änderung Nachfolger: FIG-5423a621f11923ac
  • PackageManagerStatus: Hierarchische Reorganisation des Zustandsautomaten durch Einführung dreier Submachine-Zustände (Preparation phase, Activation Phase, CleaningUp phase) mit UML-Entry- und Exit-Points.
  • Zustände kIdle, kProcessing und kReady: Entfallen als eigenständige Zustände; konsolidiert und ersetzt durch den Zustand kPreparing innerhalb der Preparation phase.
  • kPreparing: Neue Service-Methoden TransferStart, TransferData, TransferExit als Selbsttransitionen zur Datenübertragung hinzugefügt.
  • kPreparing: Methoden ProcessSwPackage und Cancel zu einer gemeinsamen Selbsttransition zusammengefasst; Guards [ProcessedPackages=0] und [ProcessedPackages>0] sowie Signal PackageProcessed entfallen.
  • Entry- und Exit-Points:
    • Preparation phase: Entry-Points Preparation und Activation failure; Exit-Points Reverting und Activating neu eingeführt.
    • Activation Phase: Entry-Point Activating; Exit-Points Finishing und Failure neu eingeführt.
    • CleaningUp phase: Entry-Point CleaningUp; Exit-Point Preparation neu eingeführt.
  • Transitionen & Pfade:
    • Initial: Zielt nun auf den Entry-Point Preparation der Preparation phase statt direkt auf kIdle.
    • Activate: Führt aus kPreparing über Exit-Point Activating und Entry-Point Activating nach kActivating.
    • RevertProcessedSwPackages: Führt aus kPreparing über Exit-Point Reverting und Entry-Point CleaningUp nach kCleaningUp.
    • OnFailure in kActivating: Führt über Exit-Point Failure und Entry-Point Activation failure zurück nach kPreparing (statt direkt nach kReady).
    • Finish: Führt aus kActivated und kRolledBack über Exit-Point Finishing und Entry-Point CleaningUp in die CleaningUp phase.
    • kCleaningUp: Führt nach Abschluss über Exit-Point Preparation und Entry-Point Preparation zurück in die Preparation phase (nach kPreparing).

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

PackageManagerStatus | kProcessing | do / process SW package | kReady | kVerifying | do / MonitorApplicationRestart | Initial | kIdle | kActivated kRollingBack | do / roll back to old version | kRolledBack kCleaningUp | do / clean up | kActivating | do / DependencyCheck | kRollingBackFailed | OnSuccess | Rollback | RevertProcessedSwPackages | OnSuccess | ProcessSwPackage | Cancelled [ProcessedPackages=0] | Cancelled, PackageProcessed [ProcessedPackages>0] | Cancel | Rollback | Finish | ProcessSwPackage RevertProcessedSwPackages | Finish | OnFailure | OnFailure | OnSuccess | Rollback OnFailure | Activate

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_EXP_PlatformDesign S. 66 13.8 Figure 13.8: Overview of Processing and Activation of Software Package