Figure 9.40: Users of the KeyValueStorage interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellen- und Abhängigkeitsbeziehungen (AUTOSAR Adaptive Platform Architecture Model).
• Technischer Zweck: Spezifikation der Architekturbeziehungen zwischen den Kern-Funktionsclustern (Functional Clusters, FCs) der AUTOSAR Adaptive Platform (AP) und dem Persistenz-Dienst (ara::per).
• Architektur-Kontext: Zeigt die zentrale Rolle des KeyValueStorage-Interfaces als standardisierte Abstraktionsschicht für nicht-flüchtige Schlüssel-Wert-Datenhaltung. System-Daemons greifen für Konfigurations-, Diagnose-, Zustands- und Synchronisationsdaten nicht direkt auf das Filesystem zu, sondern kapseln ihre Zustandshaltung über die einheitliche KeyValueStorage-Schnittstelle.

2. Komponenten, Entitäten & Schnittstellen

Bereitstellende Entität (Provider)

• Persistency («aapFunctionalCluster»): Realisiert («realize», geschlossene hohle Pfeilspitze) die Spezifikation und Implementierung des KeyValueStorage.

Schnittstelle (Interface)

• Persistency::KeyValueStorage («aapAPI, aapPortInterface»): C++-API- und Port-Definition im Namespace ara::per.
  • DiscardPendingChanges(): Verwirft ungeschriebene Änderungen im flüchtigen Puffer.
  • GetAllKeys(): Liest die Liste aller persistierten Schlüsselbezeichner aus.
  • GetValue(): Typsicheres, typisiertes Auslesen des zu einem Key hinterlegten Werts.
  • KeyExists(): Prüft die Existenz eines Schlüssels im Storage.
  • RecoverKey(): Rekonstruiert beschädigte oder redundanzgesicherte Schlüsselwerte.
  • RemoveAllKeys(): Löscht alle Schlüssel-Wert-Paare der Storage-Instanz.
  • RemoveKey(): Löscht einen einzelnen Schlüssel.
  • ResetKey(): Setzt einen Schlüssel auf den im Deploy-Manifest definierten Initial-/Auslieferungswert zurück.
  • SetValue(): Schreibt/aktualisiert einen Wert im lokalen Puffer/Cache.
  • SyncToStorage(): Flusht gepufferte Daten atomar auf das physikalische Speichermedium (Flash/NVRAM).

Konsumierende Entitäten (Clients / Daemons)

Alle Clients sind als eigenständige POSIX-Prozesse (daemon-based) mit dem Stereotyp «aapFunctionalCluster» ausgelegt und nutzen die Schnittstelle über gerichtete Abhängigkeiten («use»):

1. Diagnostic Management (DM): Verwendet «use» und explizit «aapRequiredPort» (Persistierung von DTCs, Freeze Frames, Fault Records und Diagnose-Zuständen).
2. Update and Configuration Management (UCM): Verwendet «use» und explizit «aapRequiredPort» (Persistierung von Software-Package-Zuständen, Installationshistorie, Rollback-Metadaten).
3. Time Synchronization (TS): Verwendet «use» (Persistierung von Master/Slave-Offsets, Drift-Kompensationsparametern, Non-Volatile-Time-Bases).
4. State Management (SM): Verwendet «use» (Persistierung von Machine/Function-Group-Zuständen über Power-Cycles hinweg).

Kardinalität/Beziehungstyp: 1:n-Nutzungsbeziehung. Jeder Cluster greift auf eine oder mehrere logisch isolierte Instanzen des KeyValueStorage zu.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Akquisitionsphase:
   • Daemon öffnet die ihm zugewiesene Instanz via ara::per::OpenKeyValueStorage(InstanceSpecifier).
   • Der Mapping-Pfad wird über das Ausführungs- und Persistenz-Manifest aufgelöst.
2. Lese- & Schreibpfad (In-Memory / Synchron):
   • Schreibzugriffe (SetValue, RemoveKey) arbeiten primär auf einem lokalen Memory-Cache.
   • Lesezugriffe (GetValue, KeyExists) werden direkt aus dem RAM-Puffer bedient.
3. Commit- & Flush-Pfad (Storage-Persistierung):
   • Der Client stößt SyncToStorage() an. Dieser Aufruf blockiert typischerweise synchron oder arbeitet intern asynchron bis zum physikalischen Write-Completion-Event.
   • SyncToStorage() erzwingt POSIX-Konformität (z. B. fsync/fdatasync) zur Verhinderung von Inkonsistenzen bei Power-Down/Spannungsabfall.
4. Fehlerbehandlungs- & Recovery-Pfad:
   • CRC-/Validierungsfehler triggern RecoverKey() (Rückgriff auf Redundanzblöcke).
   • Bei Abbruch von Transaktionen (z. B. UCM-Update-Fehler) setzt DiscardPendingChanges() den Puffer zurück; ResetKey() stellt Factory Defaults wieder her.

4. Normative Relevanz & Entwickler-Hinweise

• Dualität von API und Port: Das Stereotyp «aapAPI, aapPortInterface» weist darauf hin, dass KeyValueStorage sowohl direkt als C++-Klassenbibliothek (ara::per) gelinkt als auch modellbasiert über Manifeste (RPortPrototype via «aapRequiredPort») deklariert wird.
• Manifest-Konfiguration: Für Daemons mit «aapRequiredPort» (insbesondere DM und UCM) müssen im ARXML-Deployment-Modell entsprechende PersistencyPortPrototype-, PersistencyKeyValueStorageInterface- und PersistencyDeployment-Elemente konfiguriert werden (Storage-Größe, Redundanzlevel M-out-of-N, CRC-Schutz, Verschlüsselung).
• Crash-Sicherheit & Flash-Wear-Out: Entwickler von Daemons dürfen SyncToStorage() nicht zyklisch aufrufen, sondern ausschließlich nach logisch abgeschlossenen Transaktionen, um Wear-Out-Effekte auf Flash/eMMC-Zellen sowie I/O-Blockaden im Thread-Scheduling zu minimieren.
• Update- & Rollback-Sicherheit: Durch ResetKey() und RecoverKey() stützt sich das Adaptive-Plattform-Konzept beim Partition-Swap oder App-Update (UCM) auf die Fähigkeit von Persistency, Versionskonflikte in den Datensätzen via Manifest-Validierung zu erkennen und bei Inkompatibilität auf Factory-Defaults zurückzufallen.