Figure 9.53: Interfaces required by Remote Persistency

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Model).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R25-11), Spezifikation AUTOSAR_AP_EXP_SWArchitecture.
• Funktionaler Zweck: Modellierung der Schnittstellenbeziehungen zwischen dem daemon-basierten Funktionscluster Remote Persistency und dem Basis-Funktionscluster Persistency (ara::per). Das Diagramm spezifiziert die API-Menge, über welche der Remote-Persistency-Daemon auf lokale Key-Value-Storage-Instanzen zugreift, um persistente Daten netzwerkweit bereitzustellen, zu spiegeln oder abzugleichen.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Funktionscluster

• «aapFunctionalCluster» Remote Persistency:
  • Ausprägung: daemon-based (wird als autonomer Hintergrund-Prozess/Daemon im Adaptive-Betriebssystem ausgeführt).
  • Rolle: Konsument (client) der Persistency-Schnittstellen.
• «aapFunctionalCluster» Persistency:
  • Basis-Cluster (ara::per).
  • Rolle: Bereitsteller (provider/Implementierung) der Persistenzdienste und physischen Speicherabstraktionen.

Schnittstellen (Interfaces) & Methoden

1. «aapAPI,aapNativeInterface» (Global/Static Management-API von ara::per):
   • Realisiert freie Funktionen bzw. statische Einstiegspunkte des Namensraums ara::per:
     • + GetCurrentKeyValueStorageSize(): Ermittelt den aktuellen Speicherverbrauch des Storages.
     • + OpenKeyValueStorage(): KeyValueStorage: Factory-Methode; öffnet einen konfigurierten Speicherbereich und liefert ein Handle/Referenz auf das KeyValueStorage-Objekt zurück.
     • + RecoverKeyValueStorage(): Stellt einen inkonsistenten oder korrumpierten Speicherbereich aus Redundanz-/Backup-Daten wieder her.
     • + ResetKeyValueStorage(): Setzt den gesamten Key-Value-Storage auf den Auslieferungs-/Init-Zustand (Init-Werte aus dem Manifest) zurück.
2. «aapAPI,aapPortInterface» KeyValueStorage:
   • Objektorientiertes Interface für granularen Datenzugriff auf Einzelschlüssel-Ebene:
     • Lese-/Abfrageoperationen: GetAllKeys(), GetCurrentValueSize(), GetValue(), KeyExists().
     • Schreib-/Modifikationsoperationen: SetValue(), RemoveKey(), RemoveAllKeys().
     • Transaktions- & Konsistenzsteuerung:
       • SyncToStorage(): Flusht transiente/gepufferte Änderungen synchron auf das nichtflüchtige Speichermedium.
       • DiscardPendingChanges(): Verwirft noch nicht persistierte Modifikationen im Cache.
     • Wiederherstellungsoperationen: RecoverKey(), ResetKey().

Beziehungen & Abhängigkeiten

• Interface Realization («realize», gestrichelte Pfeile mit geschlossener, nicht ausgefüllter Dreiecksspitze): Persistency implementiert beide Schnittstellen (KeyValueStorage und das native Management-Interface).
• Usage Dependency («use», gestrichelte offene Pfeile): Remote Persistency nutzt beide Schnittstellen zur Interaktion mit dem lokalen Persistenz-Subsystem.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Handle-Akquise:
   • Der Remote Persistency-Daemon ruft OpenKeyValueStorage() über das aapNativeInterface auf, um Zugriff auf die konfigurierte Instanz zu erhalten.
   • Schlägt das Öffnen aufgrund von Integritätsfehlern fehl, triggert der Daemon RecoverKeyValueStorage() oder meldet Persistenzfehler an das Health Management (ara::phm) / Diagnostic Management (ara::diag).
2. Datenaustausch & Remote-Synchronisation:
   • Leseanfragen aus dem Netzwerk (z. B. via ara::com) führen zur Prüfung via KeyExists() und anschließendem Auslesen über GetValue().
   • Eingehende Remote-Aktualisierungen rufen SetValue() auf.
3. Persistierung & Transaktionsgrenzen:
   • Änderungen liegen zunächst im RAM-Puffer von ara::per.
   • Der Daemon initiiert explizit SyncToStorage(), um NVRAM/Flash-Write-Cycles zu bündeln und Atomizität sicherzustellen.
   • Bei Abbruchbedingungen oder Übertragungsfehlern sichert DiscardPendingChanges() den vorherigen konsistenten Zustand.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von nativer C++-API und Port-Interface:
  • Das Management-Interface ist als aapNativeInterface typisiert und repräsentiert direkte C++-Header-Bindings (ara::per::*), die prozesslokal gelinkt werden.
  • KeyValueStorage ist als «aapPortInterface» modelliert, was eine modellierte Bindung über Software-Ports (Service-Orientierung) ermöglicht.
• Kein direkter Treiberzugriff:
  • Remote Persistency greift unter keinen Umständen direkt auf Block-Devices, Dateisysteme oder Flash-Treiber zu; sämtliche I/O-Operationen müssen ausnahmslos über die ara::per-Abstraktion geschleust werden.
• Lebenszyklus- & Thread-Safety-Anforderungen:
  • Da Remote Persistency als Daemon parallel zu lokalen Applikationsprozessen laufen kann, muss der Stack-Entwickler für das zugrundeliegende ara::per-Backend prozessübergreifende Synchronisationsmechanismen (File-Locks, Shared Memory Semaphoren oder IPC-Proxys) sicherstellen, falls dieselbe KeyValueStorage-Instanz von mehreren Prozessen parallel geöffnet wird.
• Ausfallsicherheit (Redundancy & Storage Integrity):
  • Entwickler von Remote-Persistenz-Adaptern müssen Fehlerzustände über die ara::core::Result<T>-Rückgaben abfangen und vor Destruktion offener Handles stets SyncToStorage() oder DiscardPendingChanges() deterministisch aufrufen.