Figure 5.1: Interfaces required by Remote Persistency from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Schnittstellenmodellierung gemäß AUTOSAR-UML-Profil).
• Technischer Zweck & Einordnung: Spezifikation der Abhängigkeiten des funktionalen Clusters Remote Persistency von der lokalen Persistency (ara::per) innerhalb der AUTOSAR Adaptive Platform (AP R25-11). Es definiert die erforderlichen öffentlichen Schnittstellen (Required Interfaces) für den schlüsselbasierten Datenspeicher (KeyValueStorage), über die der Remote Persistency Daemon persistente Daten lokal ablegt, synchronisiert und wiederherstellt.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Funktionscluster

• «aapFunctionalCluster» Remote Persistency:
  • Konsument der Schnittstellen.
  • Eigenschaft: daemon-based (wird als Plattform-Daemon-Prozess im Betriebssystem ausgeführt).
• «aapFunctionalCluster» Persistency:
  • Provider/Realisierer der lokalen Persistenz-Mechanismen (entspricht ara::per).

Schnittstellen (Interfaces) & Signaturen

• «aapAPI,aapNativeInterface» (Globale / Namespace-Funktionen der Persistency):
  • Enthält statische Initialisierungs- und Lifecycle-Funktionen (unterstrichen notiert):
    • + GetCurrentKeyValueStorageSize()
    • + OpenKeyValueStorage(): KeyValueStorage (Fabrikmethode / Handle-Instanziierung)
    • + RecoverKeyValueStorage()
    • + ResetKeyValueStorage()
• «aapAPI,aapPortInterface» KeyValueStorage:
  • Objekt-Schnittstelle zur Manipulation des geöffneten Speichers:
    • Schreib-/Änderungsoperationen: SetValue(), RemoveKey(), RemoveAllKeys(), DiscardPendingChanges(), SyncToStorage()
    • Lese-/Abfrageoperationen: GetValue(), KeyExists(), GetAllKeys(), GetCurrentValueSize()
    • Wiederherstellungsoperationen: RecoverKey(), ResetKey()

Beziehungen & Abhängigkeiten

• Abhängigkeit («use»): Gerichtete Verwendungsbeziehung (gestrichelte Pfeile mit offener Spitze) von Remote Persistency auf KeyValueStorage sowie auf das native globale Interface.
• Realisierung (Interface Realization): Gestrichelte Pfeile mit geschlossener, nicht ausgefüllter Dreiecksspitze von Persistency auf beide Interfaces (KeyValueStorage und das native Interface). Persistency implementiert den normativen C++-Vertrag.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl statisch modelliert, impliziert der Schnittstellenvertrag folgende Aufrufsequenz für den Remote-Persistency-Daemon:

1. Initialisierung & Akquisition:
   • Aufruf von OpenKeyValueStorage() über das native Interface. Bei erfolgreicher Validierung Rückgabe eines Handles/Shared-Pointers auf die KeyValueStorage-Instanz.
2. Laufzeit-Transaktionen (CRUD / Sync):
   • Write Path: Aufrufe von SetValue() oder RemoveKey() modifizieren den internen Arbeitsstand (In-Memory/Staging).
   • Commit Path: SyncToStorage() flusht transaktional modifizierte Keys auf das physikalische Medium.
   • Abort Path: DiscardPendingChanges() verwirft alle seit dem letzten Flush vorgenommenen Änderungen.
   • Read Path: KeyExists() prüft das Vorhandensein, gefolgt von GetValue() zur Deserialisierung von Nutzdaten.
3. Fehlerbehandlung & Recovery:
   • Erkennung korrupter Blöcke triggert RecoverKey() bzw. RecoverKeyValueStorage() (Wiederherstellung aus redundanten Backups).
   • Bei irreparablen Fehlern setzt ResetKey() oder ResetKeyValueStorage() die Datenbasis auf Initial-/Factory-Werte zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Informativer Charakter der Cluster-Interaktion: Gemäß AP-Architekturrichtlinie werden rein interne Schnittstellen zwischen zwei Functional Clustern nicht binärfest standardisiert, um OS- und plattformspezifische IPC-/Daemon-Optimierungen der Stack-Hersteller zu ermöglichen.
• Wiederverwendung von Standard-APIs: Anstatt ein proprietäres Backend zu definieren, nutzt der Remote Persistency Daemon den regulären ara::per-Standardvertrag für Key-Value-Storage.
• Transaktionale Konsistenz: Entwickler von Remote-Persistency-Diensten müssen sicherstellen, dass Netzwerkdaten erst nach erfolgreichem SyncToStorage() als persistent quittiert werden.
• Fehlerkapselung: Fehlerzustände (ara::core::Result<T, PerErrc>) beim Öffnen oder Schreiben müssen auf Remote-Ebene in entsprechende Transport-/Protokollfehler übersetzt werden; die Recovery-Methoden sind synchron und blockierend auszulegen bzw. gemäß Threading-Modell des Daemons zu entkoppeln.