Figure 10.18: Use cases for activating and rolling-back SW packages

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) mit AUTOSAR Adaptive Platform-spezifischem Profil («aap...»).
• Technischer Zweck: Spezifikation der Anwendungsfälle Aktivierung und Rollback von Software-Paketen innerhalb des Functional Clusters Update and Configuration Management (UCM) auf Instanzebene sowie Darstellung der Interaktion mit fahrzeugweiten Update-Diensten (VUCM) und kooperierenden Plattform-Clustern (State Management, Log and Trace, Cryptography).
• Funktionale Einordnung: Verortet in der AUTOSAR Adaptive Platform (AP) Architecture (AUTOSAR_AP_EXP_SWArchitecture, Kap. 10 / UCM). Zeigt die funktionale Abgrenzung des lokalen UCM-Daemons bei Lifecycle-kritischen A/B-Partitionierungs- oder In-Place-Aktualisierungsphasen (Activation & Rollback) gemäß ISO 22901 / ISO 26262 Sicherheitsanforderungen.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Systemgrenzen:

• Systemgrenze Adaptive Platform: Umfasst alle beteiligten Functional Cluster (FC).
• Cluster-Grenze Update and Configuration Management: Kapselt die primären Use Cases des lokalen UCM.
• Akteur / Initiator:
  • «aapFunctionalCluster» Vehicle Update and Configuration Management (VUCM, stereotypt als daemon-based): Flotten- bzw. fahrzeugweites Update-Orchestrierungselement, welches als externer Trigger für die lokale UCM-Instanz fungiert.
• Anwendungsfälle (Use Cases):
  • «aapUseCase» Activate SW Package: Überführung transferierter und verarbeiteter Software-Pakete in den aktiven Ausführungszustand.
  • «aapUseCase» Perform Rollback: Wiederherstellung des zuvor konsistenten Software- und Konfigurationsstandes bei Validierungs- oder Aktivierungsfehlern.
• Partizipierende Functional Cluster:
  • «aapFunctionalCluster» State Management (daemon-based): Zuständig für die Koordination von Function Groups, Execution States und Plattform-Reboots (Target States).
  • «aapFunctionalCluster» Log and Trace (Library-basiert): Audit-Logging, Security-Logging und Tracing der Update-Operationen.
  • «aapFunctionalCluster» Cryptography (daemon-based): Kryptografische Validierung (Signaturprüfung, Authentizitätsnachweis, Dekodierung/Entschlüsselung von Software-Payloads).

Beziehungen & Abhängigkeiten:

• «aapTriggers»:
  • VUCM → Activate SW Package
  • VUCM → Perform Rollback (VUCM steuert die Phasen über ara::com/SOME/IP bzw. lokale IPC-Schnittstellen des PackageManagement-Servicevertrags an).
• «aapParticipates»:
  • Beide Use Cases unterhalten gerichtete Partizipationsbeziehungen zu allen drei Support-Clustern:
    • → State Management: Anforderung von Neustarts, Umschaltung von Function Group States (kVerifyState, kActiveState).
    • → Log and Trace: Konsistente Protokollierung jedes Phasenwechsels und Fehlers (ara::log).
    • → Cryptography: Integritäts- und Zertifikatsprüfung (ara::crypto) vor/während Aktivierung bzw. Rollback.

3. Dynamisches Verhalten & Sequenzablauf

Ablauf Activate SW Package:

1. Trigger: VUCM ruft die UCM-Aktivierungsmethode auf (z. B. ara::ucm::pkgmgr::PackageManagement::Activate()).
2. Kryptografische Verifikation: Interaktion mit Cryptography zur finalen Prüfung von Paket-Zertifikatsketten und Prüfsummen vor dem Switch.
3. Audit-Trail: Persistierung des Übergangs über Log and Trace.
4. State Transition: UCM koordiniert mit State Management das Beenden betroffener Prozesse/Function Groups, das Aktualisieren der Execution-Manifeste und das Einleiten eines kontrollierten Reboots oder State-Wechsels (Umschaltung in Verifikations-/Produktivumgebung).

Ablauf Perform Rollback:

1. Trigger: Expliziter Aufruf durch VUCM (Rollback()) oder interner Fallback-Trigger (z. B. Time-out der Selbstüberwachung, fehlschlagende ara::sm-Validierung nach Aktivierung).
2. Wiederherstellung des Zustands:
   • Abstimmung mit State Management: Herunterfahren instabiler Function Groups, Umschalten auf die vorherige Partitions-/Manifest-Referenz (Inactive/Golden Image Bank).
   • Einbindung von Cryptography: Validierung des Ziel-Rollback-Zustands zur Vermeidung von Anti-Rollback-Verletzungen (Security Downgrade Protection).
   • Einbindung von Log and Trace: Diagnosegerechte Erfassung des Rollback-Grundes (z. B. DTC-Generierung via DM/Dem oder Failure Log).

4. Normative Relevanz & Entwickler-Hinweise

• Prozessarchitektur (Daemon vs. Library): UCM, VUCM, State Management und Crypto laufen als eigenständige OS-Prozesse (daemon-based). Entwickler müssen IPC-Latenzen, asynchrone Schnittstellenmuster (ara::core::Future/Promise) und Zugriffsrechte (IAM / Access Control Lists) beachten.
• Rollback-Sicherheit & Downgrade Prevention: Bei der Implementierung von Perform Rollback mit Cryptography muss zwingend die Hardware-Security-Schnittstelle (z. B. Secure Boot Key Storage, Monotonic Counters) eingebunden werden, um unautorisierte Rollbacks auf veraltete, verwundbare Softwareversionen normativ auszuschließen.
• State Management Handshake: Die Aktivierung erfordert einen strikten Zustandsvertrag: Applikationsprozesse dürfen während der Aktivierung nicht unkoordiniert durch UCM terminiert werden; dies muss ausschließlich über State Management und dessen Function Group State Transitions (ara::sm) orchestriert werden.
• Logging-Pflicht: Sämtliche Übergänge beider Use Cases müssen manipulationssicher über ara::log aufgezeichnet werden, um die Nachvollziehbarkeit nach UN R156 (Software Update Management Systems, SUMS) nachzuweisen.