Figure 10.1: Typical usage of Persistency within an Adaptive Application

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Kompositionsstruktur- / Komponentendiagramm (Nested Component Architecture).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Functional Cluster Persistency (ara::per), Spezifikationsdokument AUTOSAR_EXP_PlatformDesign (Kapitel 10).
• Technischer Zweck: Darstellung der logischen Kapselung und Partitionierung nicht-flüchtiger Speicherressourcen innerhalb der Betriebssystem-Prozessgrenze einer Adaptive Application (AA). Das Modell illustriert die Koexistenz und Mehrfachinstanziierung von strukturierten (Key-Value) und unstrukturierten (File-basierten) Persistenzentitäten innerhalb eines einheitlichen Anwendungs- und Plattform-Kontexts.

2. Komponenten, Entitäten & Schnittstellen

• «process» Adaptive Application:
  • Repräsentiert die POSIX-Prozessgrenze und den Ausführungskontext der Applikation im User Space. Bildet die Sicherheits- und Ressourcen-Isolationsdomäne.
• «subsystem,entity» Persistency:
  • Der funktionale Cluster ara::per als logisches Subsystem innerhalb des Prozesses (Library-/Client-Bindung zur Plattform). Verwaltet den Zugriff auf NVRAM, Flash oder blockbasierte Dateisysteme.
• «entity» Key-Value Storage A & Key-Value Storage B:
  • Instanzen des Typs ara::per::KeyValueStorage.
  • Gekapselte, voneinander isolierte logische Schlüssel-Wert-Datenbanken (Key_A1..An → Value_A1..An, Key_B1..Bn → Value_B1..Bn).
  • Ermöglichen typisierte Serialisierung und Deserialisierung von Elementardaten und komplexen C++-Datentypen ohne Kenntnis des physischen Ablageformats.
• «entity» File Storage C & File Storage D:
  • Instanzen des Typs ara::per::FileStorage.
  • Gekapselte Namensräume für unstrukturierte Dateien (File_C1..Cn, File_D1..Dn), die über Stream-basierte Zugriffsmodi verwaltet werden.
• Beziehungen & Kardinalitäten:
  • Containment (1 : 1): Die Adaptive Application enthält genau eine logische Bindung an das Persistency-Subsystem.
  • Containment (1 : n bzw. 1 : m): Das Persistency-Subsystem aggregiert parallel mehrere disjunkte KeyValueStorage- und FileStorage-Entitäten (n ≥ 1, m ≥ 1). Es existieren keine Querbeziehungen oder geteilten Namespaces zwischen den Storages.

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Strukturmodell beschreibt das Diagramm keinen direkten Signalfluss; das korrespondierende Laufzeitverhalten nach ara::per-Spezifikation folgt diesen Phasen:

1. Instanziierung & Binding:
   • AA instanziiert Speicher-Handles über Manifest-konfigurierte Identifier (InstanceSpecifier):
     • ara::core::Result<ara::per::SharedHandle<ara::per::KeyValueStorage>> ara::per::OpenKeyValueStorage(...)
     • ara::core::Result<ara::per::SharedHandle<ara::per::FileStorage>> ara::per::OpenFileStorage(...)
2. Datenzugriff:
   • KVS: Synchrone Methodenaufrufe GetValue<T>(key) und SetValue(key, value).
   • File Storage: Öffnen von Dateien via OpenFileReadWrite(...) oder OpenFileReadOnly(...) zur Rückgabe von Stream-Read-/Write-Accessors (ReadAccessor, ReadWriteAccessor).
3. Persistierung & Konsistenzgrenzen:
   • Datenmodifikationen verbleiben zunächst im In-Memory-Cache.
   • Expliziter Aufruf von SyncToStorage() auf Instanzebene zur atomaren Sicherung auf das physische Speichermedium (Block-Device/Flash).

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung: Jeder Speicherbereich erfordert eine explizite Modellierung im AUTOSAR-Manifest (PersistencyKeyValueDatabase bzw. PersistencyFileProxyInterface / PersistencyFileStorage), verknüpft über entsprechende PortGroups und PortPrototypes der AdaptiveApplication.
• Transaktions- und Atomaritätsgrenzen:
  • SyncToStorage() wirkt nur lokal auf die aufrufende Instanz (z. B. nur auf Key-Value Storage A).
  • Keine plattformübergreifende 2PC-Transaktionssicherheit über mehrere Storages hinweg; Applikationscode muss Konsistenz zwischen separaten KVS-/FS-Instanzen selbst orchestrationsseitig sicherstellen.
• Dateisystem-Restriktion: Entwickler dürfen für File Storage keine nativen POSIX-Dateisystemaufrufe (open(), read(), write()) mit festen Pfaden nutzen. Der Zugriff muss strikt über die abstrahierten ara::per-APIs erfolgen, um Plattformportabilität, Access Control (SE-Linux/POSIX ACLs) und UCM-Kompatibilität zu wahren.
• Lifecycle & UCM-Migration: Die Partitionierung in Storages A/B bzw. C/D dient als Entwurfsmuster für Software-Updates. Sie erlaubt die Entkopplung statischer Konfigurationsdaten (die bei Updates überschrieben werden) von dynamischen Laufzeit- oder Kalibrierdaten (die migriert oder beibehalten werden müssen).