Figure 9.48: Users of the KeyValueStorage interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodell-Profil: Stereotypen «aapFunctionalCluster», «aapAPI,aapPortInterface», «aapRequiredPort»).
• Technischer Zweck: Darstellung der Abhängigkeitsbeziehungen zwischen zentralen Plattform-Dämonen (daemon-based Functional Clusters) der AUTOSAR Adaptive Platform (AP) und der Persistenz-Schnittstelle KeyValueStorage.
• Funktionale Einordnung: Veranschaulicht, wie Basisfunktionscluster die funktionale Abstraktionsschicht von Persistency (PER, ara::per) zur nicht-flüchtigen Datenhaltung (Non-Volatile Storage) nutzen, anstatt proprietäre Dateisystemzugriffe zu implementieren.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Provider-Komponente:
  • «aapFunctionalCluster» Persistency: Realisiert die Speicherabstraktion.
• Schnittstelle (API / PortInterface):
  • «aapAPI,aapPortInterface» KeyValueStorage: C++-Typschnittstelle (ara::per::KeyValueStorage) für schlüsselbasierte Ablage typsicherer Werte.
  • Exponierte Operationen:
    • DiscardPendingChanges(): Verwirft im RAM gepufferte, noch nicht synchronisierte Modifikationen.
    • GetAllKeys(): Ruft alle vorhandenen Schlüsselbezeichner des Storage-Containers ab.
    • GetCurrentValueSize(): Ermittelt die Bytegröße eines serialisierten Werts für einen Schlüssel.
    • GetValue(): Liest den typisierten Wert zu einem Schlüssel aus dem Storage.
    • KeyExists(): Prüft auf Vorhandensein eines Schlüssels.
    • RecoverKey(): Stellt einen korrumpierten Schlüssel/Wert aus Redundanzdaten wieder her.
    • RemoveAllKeys(): Löscht sämtliche Einträge des Containers.
    • RemoveKey(): Löscht einen spezifischen Schlüssel inkl. Wert.
    • ResetKey(): Setzt den Schlüssel auf den im Manifest konfigurierten Initial-/Defaultwert zurück.
    • SetValue(): Schreibt/aktualisiert einen typisierten Wert (gepuffert).
    • SyncToStorage(): Flusht gepufferte Änderungen atomar/persistent auf das physische Speichermedium.
• Consumer-Komponenten (Plattform-Dämonen, jeweils daemon-based»):
  • «aapFunctionalCluster» Diagnostic Management (DM): Persistierung von Fehlerspeicher (DTCs, Freeze Frames, Extended Data Records, Debounce-Stände).
  • «aapFunctionalCluster» State Management (SM): Speicherung von Systemzuständen, Reset-Gründen, Startkonfigurationen.
  • «aapFunctionalCluster» Time Synchronization (TS): Sicherung von Drift-/Offset-Kompensationen, Leap-Second-Offsets und Master-Clock-Parametern.
  • «aapFunctionalCluster» Update and Configuration Management (UCM): Transaktionssichere Software-Cluster-Zustände, Rollback-Metadaten, Manifeste lokaler Packages.
  • «aapFunctionalCluster» Vehicle Update and Configuration Management (VUCM): Flotten- und fahrzeugweite Update-Kampagnen-Zustände und Transferstatus.

Beziehungen & Kardinalitäten

• Interface Realization: Persistency implementiert KeyValueStorage (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
• Usage Dependencies: Alle 5 Plattform-Dämonen binden KeyValueStorage über gerichtete Abhängigkeiten ein («use», «aapRequiredPort»), was im Deployment einem PRPortPrototype bzw. RPortPrototype entspricht.

3. Dynamisches Verhalten & Sequenzablauf

• Aufrufmodell: Synchrone bzw. blockierende lokale C++-API-Aufrufe innerhalb des jeweiligen Dämon-Prozesskontextes (In-Process Library Linkage von ara::per).
• Zweistufiger Schreibzyklus (Transactional Caching):
  1. SetValue() modifiziert den internen Arbeitsbereich (In-Memory Shadow Cache).
  2. Modifikationen können via DiscardPendingChanges() verworfen werden.
  3. Erst der explizite Aufruf von SyncToStorage() triggert den synchronen Flush / fsync auf das zugrunde liegende Flash-/Block-Storage-Backend (ACID-Konformität auf Container-Ebene).
• Ausfall- und Integritätspfade:
  • Erkennen CRC-/Integritätsprüfungen Fehler bei GetValue(), greift RecoverKey() auf redundante Persistenz-Kopien (M-of-N-Redundanz gemäß Manifest-Konfiguration) zurück.
  • ResetKey() holt Defaults direkt aus dem read-only Deployment-Manifest.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Constraint (Library vs. Dämon): Obwohl Persistency als Functional Cluster modelliert ist, agiert es zur Laufzeit als statische/dynamische Bibliothek im Adressraum des aufrufenden Dämon-Prozesses. Jeder Dämon greift direkt über den OS-Kernel auf sein ihm zugewiesenes Dateisystem-/Speicherkontingent zu.
• Manifest-Konfiguration & Port-Mapping:
  • Für jeden Dämon muss im Execution/Instance-Manifest ein PersistencyKeyValueStorageInterface und ein entsprechender PersistencyPortPrototype modelliert sein.
  • Verpflichtende Definition des Resource-Budgets (Quota in Bytes), der Redundanzstrategie (RedundancyHandlingScopeEnum) und der Default-Schlüsselwerte im Storage-Manifest.
• Fehlerbehandlung: Alle Methoden geben ara::core::Result<void> bzw. ara::core::Result<T> zurück. Entwickler müssen Fehlercodes aus ara::per::PerErrc (z. B. kKeyNotFound, kPhysicalStorageFailure, kStorageConfigurationError, kIntegrityCorrupted) zwingend behandeln.
• Power-Loss-Sicherheit: Unvollständige Schreibzugriffe vor SyncToStorage() sind flüchtig. Kritische Dämonen (insb. UCM bei Swap/Rollback und DM bei Crash-DTCs) müssen SyncToStorage() zeitkritisch vor Power-Down / State-Transitions triggern.