Figure 23.1: Architecture of Remote Persistency

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Verteilungsdiagramm (Deployment Diagram) mit Hardware-Knoten («device») und geschachtelten Software-Komponenten/Subsystemen.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R25-11), Functional Cluster Persistency (ara::per) erweitert um das Konzept der Remote Persistency.
• Technischer Zweck: Darstellung der Entkopplung und standortunabhängigen Bereitstellung von persistenten Speichern (Key-Value Storages). Das Diagramm illustriert, wie persistente Speicherbereiche entweder exklusiv lokal (Storage A durch App 1) oder knotenübergreifend geteilt (Storage B durch lokale App 1 & App 3 sowie remote App 2 auf ECU 2) über einen Vermittlungsdienst (Remote Persistency) adressiert werden.

2. Komponenten, Entitäten & Schnittstellen

Hardware-Knoten («device»)

• ECU 1: Primäres Steuergerät / Host-Knoten, auf dem der physische persistente Speicher und der Server-Stack der Remote Persistency angesiedelt sind.
• ECU 2: Satelliten-/Client-Steuergerät ohne lokalen Host-Dienst für Storage B.

Komponenten & Funktionscluster

• App 1, App 3 (auf ECU 1): Lokale Adaptive Applications.
• App 2 (auf ECU 2): Entfernte Adaptive Application.
• Remote Persistency: Gateway-/Server-Komponente auf ECU 1, die Anfragen auf persistente Ressourcen kapselt, vermittelt und netzwerkweit transparent macht.
• Persistency (ara::per): Standardisierter AUTOSAR Adaptive Functional Cluster zur Verwaltung nicht-flüchtiger Speicherzugriffe.
• Key-Value Storage A & Key-Value Storage B: Logische Speicherinstanzen (KVS-Artefakte) innerhalb von Persistency.

Ports & Schnittstellenbeziehungen

• Interface A:
  • Provider: Remote Persistency (Lollipop A), delegiert an Key-Value Storage A.
  • Consumer: App 1 über Required Interface (Socket A).
  • Kardinalität/Bindung: 1:1, exklusiver lokaler Zugriff.
• Interface B:
  • Provider: Remote Persistency (Lollipop B), delegiert an Key-Value Storage B.
  • Consumer:
    • App 1 (ECU 1, Socket B) via logischem Zugriffspfad (gestrichelte Abhängigkeit).
    • App 3 (ECU 1, Socket B) via lokalem IPC/Zugriffspfad.
    • App 2 (ECU 2, Socket B) via netzwerkübergreifender RPC/Transport-Verbindung.
  • Kardinalität/Bindung: n:1 (Multi-Client-Access auf dieselbe Speicherinstanz).

3. Dynamisches Verhalten & Interaktionspfade

• Lokaler Pfad (Synchron/Blockierend oder Asynchron via ara::core::Future):
  • App 1 greift direkt über Interface A auf Storage A zu; Latenz entspricht dem lokalen Flash/NVRAM-Treiberstack (POSIX-Dateisystem / eMMC / UFS).
• Geteilter lokaler Pfad:
  • App 1 und App 3 greifen nebenläufig über Interface B auf Storage B zu. Die Remote Persistency-Schicht bzw. ara::per muss lokalen Locking-, Konsistenz- und Transaktionsmechanismen (Read/Write-Locks, atomare KVS-Updates) bereitstellen.
• Remote-/Netzwerkpfad (Asynchroner RPC):
  • App 2 (ECU 2) initiiert Read-/Write-/Sync-Operationen auf Storage B über Interface B.
  • Transport & Vermittlung: Der Aufruf wird serialisiert und über einen Kommunikationsmechanismus (z. B. ara::com via SOME/IP oder IPC) an die Remote Persistency-Instanz auf ECU 1 übermittelt.
  • Fehlerbehandlung: Zusätzliche Fehlerszenarien gegenüber lokalem ara::per (Netzwerk-Timeouts, Kommunikationsabbruch, ara::core::ErrorCode für Remoting-Fehler).

4. Normative Relevanz & Entwickler-Hinweise

• API-Transparenz:
  • Für App 1, App 2 und App 3 ist die Schnittstelle (KeyValueStorage) funktional identisch konzipiert (ara::per::OpenKeyValueStorage). Die Lokalisierung (lokal vs. remote) wird primär über das ARXML-Deployment-Modell und Manifeste (PersistencyPortPrototypeMapping, PersistencyDeployment) konfiguriert.
• Nebenläufigkeit & Datenkonsistenz:
  • Entwickler müssen bei geteilten Speichern (Storage B) Race Conditions berücksichtigen: Parallele Schreibzugriffe von App 2 (remote) und App 3 (lokal) erfordern serverseitige Serialisierung (SyncKeyValues()) oder definierte Kollisionsauflösung.
• Echtzeit- & Performance-Restriktionen:
  • Zugriffe über ECU-Grenzen (App 2 → Storage B) sind nicht echtzeitfähig (Non-Deterministic Latency). Zeitkritische Daten dürfen nicht in Remote-Storages abgelegt werden.
• Sicherheit & Zugriffsschutz (Security):
  • Da Interface B ECU-Grenzen überschreitet, müssen IAM-Policies (Identity and Access Management) und Authentifizierung/Verschlüsselung (z. B. SecOC, TLS) auf Transportebene für den Remote Persistency-Endpunkt konfiguriert sein, um unautorisierte Manipulationen an Storage B zu unterbinden.