Figure 7.1: Architecture of the Remote Persistency

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Verteilungs- und Komponentendiagramm (Deployment & Component Diagram) mit Ball-and-Socket-Schnittstellendarstellung (Lollipop / Port-Notation).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation Remote Persistency (R25-11).
• Funktionaler Zweck: Veranschaulichung der logischen und physischen Verteilungstopologie für Persistenzzugriffe über Maschinengrenzen hinweg. Das Diagramm demonstriert die Kapselung lokaler Persistenz-Engines (ara::per) durch eine zentrale Remote Persistency-Instanz sowie den simultanen lokalen (Inter-Process / Intra-ECU) und netzwerkweiten (Inter-ECU) Zugriff mehrerer Applikationen auf identische oder getrennte Key-Value-Speicher (KVS).

2. Komponenten, Entitäten & Schnittstellen

• Knoten / Ausführungsumgebungen («device»):
  • ECU 1: Host-/Server-Steuergerät mit physischem nicht-flüchtigem Speicher (NVM) und lokaler Persistenz-Infrastruktur.
  • ECU 2: Satelliten-/Client-Steuergerät ohne zwingend eigenen NVM-Speicher für diese Domäne; greift remote über das Bordnetz auf ECU 1 zu.
• Applikations-Komponenten:
  • App 1 (auf ECU 1): Lokaler Client mit dualem Zugriff; nutzt Socket A (exklusiv auf KVS A) und Socket B (geteilt auf KVS B).
  • App 3 (auf ECU 1): Lokaler Client; bindet Socket B an KVS B.
  • App 2 (auf ECU 2): Remote-Client; bindet Socket B über die ECU-Grenze an KVS B.
• Persistenz-Subsystem (auf ECU 1):
  • Remote Persistency: Gateway-/Service-Komponente (Daemon), die eingehende Zugriffe abwickelt, serialisiert und an die lokale Persistenz delegiert. Stellt die bereitgestellten Schnittstellen (Balls) A und B bereit.
  • Persistency: Standard AUTOSAR Adaptive Platform Functional Cluster (ara::per), zuständig für das lokale Dateisystem- und Block-Handling.
  • Key-Value Storage A & Key-Value Storage B: Instanziierte Persistenz-Container innerhalb des Persistency-Clusters.
• Schnittstellen & Kopplung:
  • Schnittstelle A: 1:1-Bindung (App 1 → Key-Value Storage A). Exklusiver Zugriffspfad.
  • Schnittstelle B: n:1-Bindung (App 1, App 3, App 2 → Key-Value Storage B). Geteilter Persistenzkontext über Knoten- und Prozessgrenzen.

3. Dynamisches Verhalten & Sequenzablauf

• Zugriffskanäle (Transportpfade):
  • Intra-ECU (App 1, App 3 → ECU 1): Der Zugriff auf KVS A bzw. B erfolgt über lokale Interprozesskommunikation (IPC) oder direkte In-Process-Abstraktion an den Remote Persistency-Endpunkt.
  • Inter-ECU (App 2 → ECU 1): Der Zugriff von ECU 2 erfolgt asynchron über das Fahrzeugnetzwerk (z. B. SOME/IP über Ethernet via ara::com).
• Synchronisation & Locking:
  • Da App 1, App 2 und App 3 zeitgleich auf Key-Value Storage B zugreifen können, übernimmt die Komponente Remote Persistency auf ECU 1 die Serialisierung, atomare Lese-/Schreibzugriffe (Transactions) und Konsistenzsicherung (Concurrency Control / Mutex-Mechanismen vor Übergabe an das lokale ara::per).
• Rückmeldungen & Fehlerpfade:
  • Synchrone oder asynchrone Rückmeldung (ara::core::Future / ara::core::Result) an die Applikationen über den Erfolg von Operationen (Get, Set, SyncKeyValues).
  • Tritt ein Übertragungs- oder Timeout-Fehler auf der Inter-ECU-Strecke auf, meldet der Client-Proxy von App 2 netzwerkspezifische Fehlercodes, während lokale Clients vorwiegend speicherspezifische Fehler (PerErrc) erhalten.

4. Normative Relevanz & Entwickler-Hinweise

• API-Transparenz:
  • Applikationen (App 1, App 2, App 3) interagieren standardmäßig gegen die einheitliche ara::per-API. Die Verlagerung von KVS B auf ein entferntes Steuergerät (ECU 1) muss für den Applikations-Quellcode von App 2 weitgehend transparent bleiben und wird über das Deployment/Manifest gesteuert.
• Manifest-Konfiguration:
  • Execution Manifest & Service Instance Manifest: Auf Client-Seite (ECU 2) muss ein Remote-Service-Mapping für Key-Value Storage B konfiguriert werden; auf Server-Seite (ECU 1) wird der Remote Persistency-Server für die Freigabe von KVS B (und KVS A lokal) instanziiert.
• Latenz- und Determinismus-Vorgaben:
  • Inter-ECU-Zugriffe unterliegen Netzwerkjitter, Serialisierungs-Overhead und Buslast. Zeitkritische Schlüsselwerte dürfen nicht über Remote-KVS synchron blockierend im Kontrollpfad abgerufen werden.
• Sicherheits- & Zugriffsrechte (Access Control):
  • Da KVS B von mehreren Prozessen und ECUs geteilt wird, müssen im Manifest strikte Zugriffsrichtlinien (Read-Only vs. Read-Write) sowie Authentifizierungs-/Integritätsmechanismen (z. B. SecOC, TLS/E2E) für den Inter-ECU-Kanal konfiguriert werden, um Speicherbeschädigung durch fehlerhafte/kompromittierte Satelliten-Knoten zu verhindern.