Figure 6.1: Persistency functionality overview

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Block-/Strukturdiagramm (Container- und Schachtelungsmodell zur funktionalen Abgrenzung).
• Technischer Zweck & Einordnung:
  • Spezifiziert den logischen Geltungsbereich und die funktionale Struktur des Functional Clusters Persistency (ara::per) innerhalb einer Adaptive Application (AA) der AUTOSAR Adaptive Platform (AP).
  • Zeigt die Koexistenz und Entkopplung der zwei orthogonalen Persistierungsmechanismen: Key-Value Storage (strukturierte, schlüsselbasierte Datenablage) und File Storage (unstrukturierter, datei-/stream-basierter Zugriff).
  • Etabliert das Multi-Storage-Konzept: Eine Applikation kann mehrere isolierte Speicherinstanzen beider Typen parallel verwalten (Partitionierung nach Lebenszyklus, Update-Strategie oder Zugriffshäufigkeit).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (AdaptiveApplication):
  • OS-Prozess- bzw. Ausführungskontext der Applikation auf POSIX-Ebene. Bildet die Sicherheits- und Berechtigungsgrenze für persistente Daten.
• Persistency Subsystem / Functional Cluster (ara::per):
  • Standardisierte Middleware-Schicht, die Hardware- und Dateisystemdetails (Flash, eMMC, NVRAM, POSIX-FS) abstrahiert und Persistenzdienste bereitstellt.
• Key-Value Storage Entitäten (Key-Value Storage A, Key-Value Storage B, …):
  • Logisch getrennte Schlüssel-Wert-Datenbanken (PersistencyKeyValueStorage im Manifest, C++-Repräsentation: ara::per::KeyValueStorage).
  • Inhalte: Diskrete Key-Value-Paare (Key_A1 = Value_A1, etc.).
  • Typisierung: Typsichere Speicherung und Abfrage fundamentaler Datentypen sowie serialisierbarer C++-Objekte über Template-Methoden (GetValue<T>(), SetValue<T>()).
• File Storage Entitäten (File Storage C, File Storage D, …):
  • Logisch getrennte Dateinamenräume/Verzeichnisse (PersistencyFileStorage im Manifest, C++-Repräsentation: ara::per::FileStorage).
  • Inhalte: Binäre oder textuelle Dateien (File_C1, File_C2, etc.).
  • Zugriff: Strombasierter Zugriff über ara::per::ReadAccessor und ara::per::ReadWriteAccessor.
• Kardinalitäten & Relationen:
  • Adaptive Application → Persistency: 1 : 1 (lokaler Scope der Applikation).
  • Persistency → Key-Value Storage: 1 : n (n ≥ 0; Multi-Instance-Fähigkeit).
  • Persistency → File Storage: 1 : n (n ≥ 0; Multi-Instance-Fähigkeit).
  • Key-Value Storage → Key-Value Pair: 1 : m (m ≥ 0).
  • File Storage → File: 1 : k (k ≥ 0).

3. Dynamisches Verhalten & Sequenzablauf

Das statische Schaubild impliziert für Entwickler folgende standardisierte Interaktionsmuster zur Laufzeit (ara::per API):

1. Instanziierung / Öffnen (Design-to-Runtime Binding):
   • Bindung über ara::core::InstanceSpecifier (Modell-Port):
     • ara::per::OpenKeyValueStorage(ara::core::InstanceSpecifier portSpecifier)
     • ara::per::OpenFileStorage(ara::core::InstanceSpecifier portSpecifier)
   • Liefert synchron ein ara::core::Result<ara::per::SharedHandle<...>>.
2. Datenzugriff & Pufferung:
   • Key-Value: Modifikationen via SetValue() erfolgen zunächst im In-Memory-Cache des Clusters.
   • File: Öffnen über OpenFileReadWrite() oder OpenFileReadOnly(), byteweises Lesen/Schreiben über Stream-Operatoren.
3. Persistierung & Synchronisation:
   • Expliziter Aufruf von SyncToStorage() stößt das synchrone Flashen auf das physische Speichermedium an (Gewährleistung von Konsistenz und Crash-Sicherheit/Power-Fail-Safe).
4. Fehlerbehandlung:
   • Keine DET/DEM-Mechanismen (Classic Platform); stattdessen feingranulare Fehlercodes über das ara::core::Result-Pattern (z. B. PerErrc::kStorageNotFound, PerErrc::kKeyNotFound, PerErrc::kPhysicalStorageFailure, PerErrc::kQuotaExceeded).

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration & Deployment:
  • Jedes im Diagramm dargestellte Storage (A, B, C, D) erfordert im AUTOSAR-Modell ein eigenes PersistencyKeyValueStorageInterface bzw. PersistencyFileStorageInterface sowie das zugehörige Deployment (PersistencyKeyValueStorage / PersistencyFileStorage).
  • Quotas (maximaler Speicherplatz pro Storage) und Redundanzlevel (z. B. CRC-Checks, Hash-Verifikation, M-von-N-Kopien) werden pro Storage-Instanz im Manifest konfiguriert.
• Update & Migration (UCM-Lifecycle):
  • Die Aufteilung in mehrere Storages (A vs. B, C vs. D) ist die funktionale Voraussetzung für differenzierte Update-Strategien. Bestimmte Storages können bei Software-Updates erhalten bleiben (kKeepExisting), migriert werden (über ara::per Migrations-Hooks) oder auf Werkseinstellungen zurückgesetzt werden (kOverwrite).
• Echtzeit-Restriktionen:
  • SyncToStorage() und Dateizugriffe unterliegen den I/O-Latenzen des zugrundeliegenden Dateisystems/Flash-Treibers (Flash Garbage Collection, Wear-Leveling-Latenzen). Sie dürfen nicht in zeitkritischen/zyklischen Control-Loops ausgeführt werden, sondern müssen in asynchrone Worker-Threads ausgelagert werden.
• Sicherheit & Integrität:
  • Falls Integritätsschutz oder Verschlüsselung (Kopplung an ara::crypto) erforderlich ist, wird dies transparent pro Storage im Deployment-Manifest parametriert, ohne dass der C++-Anwendungscode geändert werden muss.