Figure 9.52: Interface for accessing KeyValueStorage

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm nach AUTOSAR Adaptive Platform (AP) Metamodell-Konventionen (AUTOSAR_AP_EXP_SWArchitecture).
• Architektur-Kontext:
  • Modelliert das serviceorientierte Mapping von persistenter Schlüssel-Wert-Speicherung (KeyValueStorage) auf ein ara::com-Service-Interface.
  • Dient der Entkopplung der Anwendungslogik (Adaptive Application) von der physischen Speicherschicht über einen zentralen Prozess/Dienst (Remote Persistency), wodurch KVS über Prozess- und Netzwerkgrenzen (ECU-übergreifend via SOME/IP oder lokal via IPC) ansprechbar wird.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten & Functional Clusters:
  • Adaptive Application (Stereotyp: UML-Komponente): Service-Konsument (Client/Proxy-Rolle).
  • Remote Persistency (Stereotyp: «aapFunctionalCluster», Annotation: daemon-based): Service-Provider (Server/Skeleton-Rolle), ausgeführt als eigenständiger System-Daemon im Adaptive Platform Stack.
• Schnittstelle («aapAraComServiceInterface, aapAPI»):
  • RemotePersistency_{storage}: Parametrisiertes Service-Interface; {storage} dient als Platzhalter für die logische Instanz/Datenbank des jeweiligen KeyValueStorage.
• Interface-Elemente & Stereotypen:
  • Felder («aapAccessControlled, aapServiceField»):
    • + DataElement_{key}: Repräsentiert ein ara::com-Field (Getter, Setter, Notifier) für atomare Lese-/Schreibzugriffe und Wertänderungs-Events einzelner Schlüssel ({key}).
  • Methoden («aapAccessControlled, aapServiceMethod»):
    • + GetAllKeys(): Abfrage sämtlicher im {storage} hinterlegter Schlüsselbezeichner.
    • + GetValue_{type}(): Typisierte Leseoperation für den spezifizierten Datentyp {type}.
    • + KeyExists(): Boolesche Existenzprüfung für einen Schlüssel.
    • + RemoveAllKeys(): Löschen aller Schlüssel/Werte innerhalb der Storage-Instanz.
    • + RemoveKey(): Selektives Löschen eines spezifischen Schlüssels.
    • + SetValue_{type}(): Typisierte Schreib-/Aktualisierungsoperation für Datentyp {type}.
  • Sicherheits-Stereotyp:
    • «aapAccessControlled»: Kennzeichnet, dass jeder Feld- und Methodenzugriff der AUTOSAR Identity and Access Management (IAM)-Prüfung unterliegt.
• Beziehungen:
  • Remote Persistency → RemotePersistency_{storage}: Interface-Realisierung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
  • Adaptive Application → RemotePersistency_{storage}: Abhängigkeit / Servicenutzung («use», gestrichelte offene Pfeillinie).

3. Dynamisches Verhalten & Sequenzablauf

1. Service Discovery & Binding:
   • Die Adaptive Application initiiert FindService via ara::com für die instanziierte Service-ID von RemotePersistency_{storage}.
   • Nach erfolgreichem Matching erzeugt die Anwendung eine Service-Proxy-Instanz.
2. Operationsabwicklung (Asynchroner Pfad):
   • Methodenaufrufe (GetValue_{type}(), SetValue_{type}(), etc.) erfolgen asynchron und liefern clientseitig ein ara::core::Future<T> zurück.
   • Der Aufruf wird serialisiert (z. B. via SOME/IP-Binding oder shared memory IPC) an den Remote Persistency-Daemon übertragen.
3. Zugriffskontrolle & IAM-Validierung:
   • Vor Ausführung validiert das IAM-Subsystem die Prozess-Credentials der anfordernden Adaptive Application gegen die Policy für die angefragte Methode bzw. das Field («aapAccessControlled»).
   • Bei fehlenden Rechten wird der Aufruf mit einem IAM-spezifischen ara::core::ErrorCode abgebrochen.
4. Event-/Field-Handling:
   • Für DataElement_{key} kann die Applikation den Notifier abonnieren (Subscribe()), um bei externer Aktualisierung des Schlüssels über den Remote Persistency-Daemon ereignisgesteuert benachrichtigt zu werden.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung & Code-Generierung:
  • Die Platzhalter {storage}, {key} und {type} müssen in der System Description / Service Interface Description konkret instanziiert werden. Für jeden Speicherbereich und jeden Typ werden spezialisierte Proxies/Skeletons generiert.
• IAM-Konfiguration (Security):
  • Jede Applikation benötigt ein explizites Security Grant Model (Access Control Lists / Manifest-Deklaration), um Zugriff auf die einzelnen Methoden und Fields von RemotePersistency_{storage} zu erhalten. Unkonfigurierte Endpunkte werden zur Laufzeit durch die IAM-Engine abgewiesen.
• Laufzeit- & Performance-Implikationen:
  • Im Gegensatz zum lokalen ara::per::OpenKeyValueStorage() bedingt Remote Persistency Inter-Process Communication (IPC) bzw. Netzwerk-Roundtrips samt Datenserialisierung.
  • Best Practice: Häufig abgefragte Einzelwerte über «aapServiceField» mit lokalem Proxy-Caching abwickeln; Massenänderungen nicht über iterative SetValue_{type}()-Aufrufe serialisieren, sondern Cache-Kohärenz und Latenzen im Systemdesign berücksichtigen.