Figure 9.43: Functional Clusters in category Storage

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm (Strukturdiagramm / Architekturebene).
• Architektonische Einordnung: Darstellung des funktionalen Spektrums der AUTOSAR Adaptive Platform (AP) innerhalb der Domänen-Kategorie Storage gemäß AUTOSAR_AP_EXP_SWArchitecture.
• Technischer Zweck: Definition und formale Zuordnung der Functional Clusters (FC) der Kategorie Storage. Neben dem lokalen Persistency (ara::per) wird mit Remote Persistency ein daemon-basierter Plattformdienst zur Verwaltung persistenter Daten über Maschinengrenzen hinweg (z. B. Remote Storage, Cloud-Anbindung, stellvertretende Speicherung) spezifiziert.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten & Stereotypen:
  • Persistency: Spezifiziert als «aapFunctionalCluster» (AUTOSAR Adaptive Platform Functional Cluster). Bildet die lokale In-Process-Komponente der Kategorie Storage.
  • Remote Persistency: Spezifiziert als «aapFunctionalCluster» mit der Eigenschaftsnotation daemon-based. Repräsentiert die dienstorientierte Plattformkomponente für ausgelagerte bzw. verteilte Persistenzdienste.
• Schnittstellen & Namensräume (C++ API):
  • Persistency (ara::per): Bietet ara::per::KeyValueStorage (strukturierte Schlüssel-Wert-Speicherung) und ara::per::FileStorage (block- und dateiorientierter Stream-Zugriff via Reader-/Writer-Accessoren).
  • Remote Persistency: Service-orientierte Schnittstelle (über ara::com) primär für Key-Value-basierte persistente Datenverwaltung auf entfernten Speichermedien oder zentralen Speicherknoten.
• Plattformbeziehungen & OS-Bindung:
  • Persistency bindet direkt an lokale POSIX-Dateisysteme bzw. NVRAM-Hardwaretreiber an.
  • Remote Persistency setzt als Daemon-Prozess auf der Kommunikationsinfrastruktur (ara::com) und dem Netzwerk-Stack auf, um Speicheroperationen prozess- oder maschinenübergreifend an Remote-ECUs oder externe Speicherdienste weiterzuleiten.

3. Dynamisches Verhalten & Sequenzablauf

• Statischer Charakter: Das Diagramm modelliert die Komponenten- und Clusterzuordnung; kein expliziter Sequenzablauf enthalten.
• Laufzeit- und Ausführungsmodell:
  • Koexistenz zweier Ausführungsmodelle:
    • Persistency: Bibliotheksmodell (In-Process-Library), ausgeführt im Thread-Kontext der aufrufenden Adaptive Application ohne IPC-Overhead.
    • Remote Persistency: Explizit daemon-based, ausgeführt als eigenständiger Hintergrundprozess (Daemon) im Adaptive-Betriebssystem.
  • Kommunikation & Nebenläufigkeit: Interaktionen mit Remote Persistency bedingen Inter-Process-Communication (IPC) oder Netzwerkübertragungen (via ara::com), wodurch asynchrone Kommunikationsmuster, Latenzen und Nebenläufigkeitssteuerung über Prozessgrenzen hinweg zum Tragen kommen.
  • Synchronisation & Fehlerbehandlung: Transaktionale Absicherung erfolgt lokal über Sync-Mechanismen (SyncToStorage()), bei Remote Persistency über verteilte Bestätigungspfade und service-orientierte Fehlercodes (ara::core::Result).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration (ARXML):
  • Für Persistency: Manifestierung lokaler Zugriffe über PersistencyPortPrototype (PersistencyKeyValueDatabaseInterface, PersistencyFileProxyInterface) sowie Definition lokaler Quotas und Redundanzen.
  • Für Remote Persistency: Modellierung im Execution-Manifest als separater Prozess (Startup-Konfiguration, Resource-Group) sowie Service-Deployment- und Service-Instance-Manifeste für die Bereitstellung und den Konsum der Remote-Storage-Services via ara::com.
• Entwickler-Restriktionen:
  • Architektonische Trennung beachten: Latenzkritische, ECU-lokale Persistenzanforderungen zwingend über ara::per (In-Process) abwickeln; netzwerkweite, geteilte oder Cloud-ausgelagerte Datensätze über Remote Persistency anbinden.
  • Bei Remote Persistency müssen Applikationen netzwerkbedingte Latenzen, asynchrone Antwortzeiten und Verbindungsausfälle architektonisch entkoppeln und fehlertolerant behandeln.