Figure 9.1: Service Interface of the Remote Persistency

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (Service Interface Model nach AUTOSAR Adaptive Platform).
• Architektur-Kontext: Spezifiziert das Service Interface für die Remote-Persistenz (AUTOSAR_AP_SWS_RemotePersistency, Anforderung RS_PER_00022). Es definiert den standardisierten, dienstbasierten Remote-Zugriff (via ara::com über IPC oder Ethernet/SOME/IP) auf ausgelagerte, zentrale Key-Value-Speicher für Adaptive Applications.

2. Komponenten, Entitäten & Schnittstellen

• «service» RemotePersistency: Service-Komponente (Server-Instanz), die die Funktionalität eines persistenten Remote-Speichers kapselt und über die Middleware bereitstellt.
• RemotePersistencyPort_{port}: Provided Port (P-Port) der Service-Komponente; parametrisiert nach dem konfigurierten Port-Namen {port}.
• «interface» RemotePersistency_{storage}: Typisiertes Service Interface, parametrisiert nach dem logischen Speicherbezeichner {storage}. Realisiert über den P-Port via Lollipop-Notationsbindung (Interface Realization).
  • Data Element (Field / Event):
    • + DataElement_{entry}: ElementDataType_{type}: Direkt adressierbares, typisiertes Feldelement für strukturierte persistente Datenpunkte.
  • Methoden (RPC Operations):
    • + GetAllKeys(): Vector<String>: Liest alle im Zielspeicher vorhandenen Schlüsselbezeichner aus.
    • + GetValue_{type}(String): ElementDataType_{type}: Typisierte Leseoperation für den Wert eines übergebenen Schlüssels.
    • + KeyExists(String): bool: Prüft die Existenz eines Schlüssels ohne Datenübertragung der Payload.
    • + RemoveAllKeys(): void: Löscht alle Schlüssel-Wert-Paare im adressierten Speicherbereich {storage}.
    • + RemoveKey(String): void: Entfernt das angegebene Schlüssel-Wert-Paar.
    • + SetValue_{type}(String, ElementDataType_{type}): void: Typisierte Schreib-/Aktualisierungsoperation für einen Schlüssel.
• «dataType» ElementDataType_{type}: Im AUTOSAR-Modell typisiertes Datenmodell-Element; fungiert als Payload-Typ für Rückgabe- und Übergabeparameter der typisierten Zugriffsmethoden sowie des Feldelements.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Kommunikationsmuster: Request-Response-Methodenaufrufe und Field-Zugriffe über ara::com.
  • Client-seitige Abbildung über Proxy-Methoden mit asynchronen Rückgabewerten (ara::core::Future<...>).
• Sequenzpfade:
  1. Metadaten- & Integritätsprüfung: Vor Lese-/Schreibzugriffen erfolgt optional KeyExists(key) zur Payload-Vermeidung oder GetAllKeys() zur Validierung des Schemas.
  2. Lese-/Schreibzyklus: SetValue_{type}(key, value) überträgt serialisierte Daten an den Remote-Server; GetValue_{type}(key) deserialisiert das Ergebnis.
  3. Bereinigung: RemoveKey(key) oder atomares Rücksetzen via RemoveAllKeys().
• Fehlerbehandlung: Methoden liefern bei Verbindungsabbrüchen, ungültigen Schlüsseln oder Speicherfehlern typisierte Fehlercodes (ara::core::ErrorCode, z. B. PerErrc::kKeyNotFound oder PerErrc::kPhysicalStorageFailure).

4. Normative Relevanz & Entwickler-Hinweise

• Template-Instanziierung & Codegenerierung: Die Platzhalter {storage}, {port}, {entry} und {type} zeigen, dass das Service Interface generativ abgeleitet wird:
  • Für jeden in ARXML konfigurierten logischen Speicherbereich entsteht ein diskretes Service Interface RemotePersistency_<StorageName>.
  • Für jeden unterstützten Datentyp werden typspezifische Getter/Setter (GetValue_UInt32, SetValue_UInt32 etc.) generiert, um typsichere Marshalling-Routinen in SOME/IP zu gewährleisten.
• API-Vertrag & Performance:
  • GetAllKeys() erzeugt bei großen Key-Value-Stores erhebliche PDU-Größen (Vector<String>); Serialisierungs- und Fragmentierungs-Overhead über Netzwerk-Links (SOME/IP-TP) einplanen.
  • Operationen wie RemoveAllKeys() müssen im Server transaktionssicher implementiert sein, um Inkonsistenzen bei Spannungsabfall abzusichern.
• Einsatzbereich: Dient als standardisierter Backend-Transportmechanismus für ara::per-Clients, wenn persistente Daten nicht lokal auf Flash/eMMC der eigenen ECU, sondern auf einem zentralen Storage-Server/HPC persistiert werden müssen.