Figure 9.48: Interfaces for installation and update of persistent data

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm mit Schnittstellenspezifikation (Realisierungs- und Nutzungsbeziehung).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP, Release R23-11), Functional Cluster Persistency (ara::per).
• Technischer Zweck: Definition der nativen C++-Applikationsschnittstelle (InstallationAndUpdateOperations) zur Verwaltung des Persistenz-Lebenszyklus. Dient der Initialisierung, Aktualisierung, Migration und Bereinigung von persistenten Datenstrukturen (KeyValueStorage, FileStorage) im Kontext von Software-Updates (z. B. getrieben durch den Update and Configuration Management Cluster, UCM) oder Werksresets.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten:
  • Adaptive Application: Software-Komponente / Applikationsprozess auf der Adaptive Platform, agiert als Konsument (Client).
  • «aapFunctionalCluster» Persistency: Plattform-Cluster (ara::per), stellt die Implementierung der Persistenzmechanismen und des Datenspeicherzugriffs bereit.
  • «aapAPI, aapNativeInterface»: Logische Schnittstellendefinition (im Dokument als InstallationAndUpdateOperations typisiert). Enthält folgende statische Operationen/Funktionen (im Namensraum ara::per):
    • + CleanUpPersistency(): Entfernt persistente Backup- und Übergangsdaten nach erfolgreichem Update.
    • + RegisterApplicationDataUpdateCallback(): Registriert anwendungsspezifische Migrations-Callbacks für Speicher-Updates.
    • + ResetPersistency(): Setzt persistente Speicher auf initial konfigurierte Auslieferungszustände zurück.
    • + UpdatePersistency(): Führt die Migration/Initialisierung von KeyValueStorage und FileStorage auf die Zielversion durch.
• Beziehungen:
  • Adaptive Application $\xrightarrow{\text{«use»}}$ «aapAPI, aapNativeInterface»: Direkte Nutzungsabhängigkeit (Client bindet und ruft die C++-API auf).
  • Persistency $\dashrightarrow \triangle$ «aapAPI, aapNativeInterface»: Realisierungsbeziehung (Interface Realization); der Functional Cluster implementiert die spezifizierten Methoden.

3. Dynamisches Verhalten & Sequenzablauf

1. Registrierung (Pre-Update Phase):
   • Die Adaptive Application registriert beim Start via RegisterApplicationDataUpdateCallback() eine Callback-Funktion (ApplicationDataUpdateCallback), um anwendungsseitige Datenmigrationen (Schema-Updates von Key-Value-Paaren oder Dateiinhalten) zu steuern.
2. Update-Trigger (Update Execution):
   • Nach dem Deployment eines Software-Pakets ruft die Applikation (oder ein Update-Agent) UpdatePersistency() auf.
   • ara::per vergleicht die Version der vorhandenen persistenten Daten mit der Konfiguration im aktuellen Manifest.
   • Falls Datenstrukturen migriert werden müssen, erzeugt ara::per Backups und feuert den zuvor registrierten Callback.
3. Abschluss & Bereinigung (Post-Update Phase):
   • Nach verifiziertem Update-Erfolg ruft die Applikation CleanUpPersistency() auf. Dies löscht nicht mehr benötigte Altdaten und Rollback-Backups aus dem Flash/Storage.
4. Fehlerbehandlung & Rollback:
   • Schlägt das Update fehl oder wird ein Werksreset angefordert, erzwingt ResetPersistency() das Zurücksetzen der Daten auf den initialen Bereitstellungszustand (Init-Werte aus dem Manifest).

4. Normative Relevanz & Entwickler-Hinweise

• API-Design: Gemäß AUTOSAR AP C++-Konventionen werfen diese Operationen keine Exceptions, sondern geben typischerweise ein ara::core::Result<void> bzw. entsprechende Fehlercodes (ara::per::PerErrc) zurück.
• Lebenszyklus-Restriktionen: CleanUpPersistency() darf erst ausgeführt werden, wenn die Konsistenz der neuen Datenbasis vollständig validiert ist, da dadurch der lokale Rollback-Pfad irreversibel gelöscht wird.
• Manifest-Abhängigkeit: Voraussetzung für funktionierende UpdatePersistency()- und ResetPersistency()-Operationen ist ein vollständig modelliertes PersistencyDeploymentElement im ARXML-Manifest inklusive Versionsdeklaration und Default-Init-Data-Definitionen.
• Thread-Safety & Blocking: UpdatePersistency() und ResetPersistency() operieren direkt auf blockierenden I/O-Treibern (Flash, eMMC/UFS-Filesystem) und müssen synchron oder asynchron innerhalb thread-sicherer Kontexte ausgeführt werden, um Deadlocks mit regulären KeyValueStorage-Lese-/Schreibzugriffen zu vermeiden.