Figure 13.8: Overview of Processing and Activation of Software Package

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 & Phasen-Submachines (PackageManagerStatus):
  • Preparation phase: Kapselt die Bereitstellung und Vorbereitung von Software-Paketen als Submachine (UML-Symbol oo). Verfügt über die Entry-Points Preparation und Activation failure sowie die Exit-Points Reverting und Activating.
  • Activation Phase: Kapselt Abhängigkeitsprüfung, Laufzeitverifikation und Rollback als Submachine (UML-Symbol oo). Verfügt über den Entry-Point Activating sowie die Exit-Points Finishing und Failure.
  • CleaningUp phase: Kapselt die Aufräum- und Bereinigungsprozesse als Submachine (UML-Symbol oo). Verfügt über den Entry-Point CleaningUp und den Exit-Point Preparation.
• Zustände und Do-Aktivitäten:
  • kPreparing (in Preparation phase): Zentraler Vorbereitungs- und Transferzustand (ersetzt die vormaligen Zustände kIdle, kProcessing, kReady).
  • kActivating (in Activation Phase, do / DependencyCheck): Validierung statischer und dynamischer Abhängigkeiten, Kompatibilität der Manifeste und Vorbereitung der Partitionsumschaltung.
  • kVerifying (in Activation Phase, do / MonitorApplicationRestart): Überwachung des Anwendungsneustarts in Kooperation mit State Management (SM) und Execution Management (EM).
  • kActivated (in Activation Phase): Zielversion erfolgreich aktiviert und verifiziert; wartet auf Finalisierung (Finish) oder manuellen Rollback.
  • kRollingBack (in Activation Phase, do / roll back to old version): Wiederherstellung der ursprünglichen Software-Version bzw. passive Partition.
  • kRolledBack (in Activation Phase): Rollback erfolgreich abgeschlossen; wartet auf Finish.
  • kRollingBackFailed (in Activation Phase): Kritischer Fehlerzustand bei fehlgeschlagenem Rollback; ermöglicht erneuten Retry via Rollback.
  • kCleaningUp (in CleaningUp phase, do / clean up): Bereinigung temporärer Artefakte, alter Paketbestände und Cache-Bereiche.
• Service-Methoden / Trigger (ara::ucm::pkgmgr::PackageManager):
  • TransferStart, TransferData, TransferExit: Blockweises Streaming / Übertragung des Software-Pakets als Selbsttransition an kPreparing.
  • ProcessSwPackage, Cancel: Start bzw. Abbruch der Paketprüfung/-dekompression als Selbsttransition an kPreparing.
  • Activate: Initiiert Aktivierungssequenz; verlässt Preparation phase über Exit-Point Activating.
  • RevertProcessedSwPackages: Verwirft vorbereitete Pakete; verlässt Preparation phase über Exit-Point Reverting.
  • Rollback: Initiiert Rollback-Vorgang aus kVerifying, kActivated oder kRollingBackFailed.
  • Finish: Schließt Aktivierung (kActivated) oder Rollback (kRolledBack) verbindlich ab; verlässt Activation Phase über Exit-Point Finishing.
• Pseudozustände & Interne Signale:
  • Initial: Startpseudozustand der Gesamt-State-Machine.
  • Entry-Points (offener Kreis): Preparation, Activation failure, Activating, CleaningUp.
  • Exit-Points (Kreis mit Kreuz X): Preparation, Reverting, Activating, Failure, Finishing.
  • Interne Signale: OnSuccess, OnFailure.

3. Dynamisches Verhalten & Sequenzablauf

Nominaler Update-Ablauf (Happy Path)

1. Initialisierung & Pakettransfer:
   • Der Startknoten (Initial) führt über den Entry-Point Preparation direkt in den Zustand kPreparing der Preparation phase.
   • Die Übertragung von Software-Paketen erfolgt blockweise über TransferStart, TransferData und TransferExit als Selbsttransitionen auf kPreparing.
   • Die Dekompression und Signatur-/Integritätsprüfung wird über ProcessSwPackage (ebenfalls als Self-Transition an kPreparing) ausgeführt.
2. Aktivierungsphase:
   • Nach erfolgreicher Vorbereitung löst Activate das Verlassen der Preparation phase über den Exit-Point Activating aus.
   • Der Übergang verbindet zum Entry-Point Activating der Activation Phase, welcher direkt in den Zustand kActivating mündet (do / DependencyCheck).
3. Verifikation & Zielzustand:
   • Verläuft der Dependency-Check erfolgreich (OnSuccess), wechselt der Automat nach kVerifying (do / MonitorApplicationRestart). UCM überwacht in Kooperation mit State Management und Execution Management das Hochlaufen der aktualisierten Prozesse.
   • Melden alle überwachten Instanzen fehlerfreien Betrieb (OnSuccess), geht das System in den Zustand kActivated.
4. Finalisierung & Bereinigung:
   • Der Aufruf Finish aus kActivated verlässt die Activation Phase über den Exit-Point Finishing.
   • Die Transition führt zum Entry-Point CleaningUp der CleaningUp phase in den Zustand kCleaningUp (do / clean up).
   • Nach erfolgreicher Bereinigung führt die Transition über den Exit-Point Preparation und den Entry-Point Preparation zurück in den Zustand kPreparing der Preparation phase, womit UCM für neue Paketübertragungen bereit ist.

Abbruch- und Revert-Pfade

• Cancel in kPreparing: Der Methodenaufruf Cancel verbleibt als Self-Transition im Zustand kPreparing und bricht laufende Parsing- oder Transferoperationen ab.
• Revert: Vor Beginn der Aktivierung verwirft RevertProcessedSwPackages alle gepufferten Paketdaten und verlässt die Preparation phase über den Exit-Point Reverting. Die Transition führt direkt zum Entry-Point CleaningUp der CleaningUp phase. Nach Durchlauf von kCleaningUp kehrt der Automat via Exit-Point Preparation nach kPreparing zurück.

Fehler- und Rollback-Pfade

• Aktivierungsfehler (Dependency Check): Schlägt der DependencyCheck in kActivating fehl (OnFailure), verlässt der Ablauf die Activation Phase über den Exit-Point Failure und kehrt über den Entry-Point Activation failure der Preparation phase zurück nach kPreparing.
• Fehlschlag der Verifikation / Manuelles Rollback:
  • Schlägt MonitorApplicationRestart in kVerifying fehl (OnFailure) oder wird aus kVerifying bzw. kActivated die Methode Rollback getriggert, wechselt der Automat nach kRollingBack (do / roll back to old version).
  • Verläuft der Rollback erfolgreich (OnSuccess), wird der Zustand kRolledBack eingenommen. Von dort überführt Finish über den Exit-Point Finishing in die CleaningUp phase und anschließend zurück nach kPreparing.
  • Schlägt die Wiederherstellung fehl (OnFailure), wechselt UCM nach kRollingBackFailed. Über einen erneuten Aufruf von Rollback kann ein weiterer Wiederherstellungsversuch nach kRollingBack unternommen werden.

4. Normative Relevanz & Entwickler-Hinweise

• Streaming- und Transfer-Protokoll: Die Einführung der Service-Methoden TransferStart, TransferData und TransferExit bindet das blockweise Chunk-Streaming von Software-Paketen normativ an den Zustand kPreparing. Clients müssen die Übertragungssequenz vollständig durchlaufen und mit TransferExit abschließen, bevor ProcessSwPackage oder Activate ausgeführt werden darf.
• Phasenkapselung & Statusabfrage: Durch die Kapselung in Preparation phase, Activation Phase und CleaningUp phase mit hierarchischen Entry-/Exit-Points werden Teilzustände modularisiert. Die vormaligen Einzelzustände kIdle, kProcessing und kReady sind im übergeordneten Statusmodell zu kPreparing verschmolzen; detaillierte Verarbeitungszustände müssen von UCM intern oder über spezifische Fortschritts-Felder signalisiert werden.
• API-Vertrag & Fehlersignalisierung: Jeder Methodenaufruf an das Interface ara::ucm::pkgmgr::PackageManager außerhalb des im Modell erlaubten Kontexts bzw. Phasenzustands muss nach AUTOSAR-Spezifikation mit UcmErrorDomain::kInvalidPackageStatus bzw. kOperationNotAllowed zurückgewiesen werden.
• Transaktionale Persistenz & A/B-Umschaltung: Bis zum erfolgreichen Erreichen von kActivated verbleiben alle Änderungen in inaktiven Banken/Verzeichnissen. Ein Fehlschlag des Dependency-Checks (Failure -> Activation failure) setzt die Bereitstellung ohne Systemneustart auf kPreparing zurück.
• Verbindlicher Aufruf von Finish(): Speicherbereinigung und Freigabe alter Software-Versionen erfolgen ausschließlich in der CleaningUp phase. Nach erfolgreicher Verifikation (kActivated) oder erfolgreichem Rollback (kRolledBack) ist der explizite Aufruf von Finish() verpflichtend, da das System andernfalls in der Activation Phase verharrt und keine neuen Pakete für nachfolgende Updates entgegennehmen kann.