Figure 11.18: Scenario: Store Persistent Data with Unique ID

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Interaktions- und Ablauf-Szenario).
• Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11, Spezifikation AUTOSAR_AP_EXP_SWArchitecture, Kapitel 11.3.1 (Persistency).
• Technischer Zweck: Detaillierung des Standard-Persistierungsablaufs für schlüsselwertbasierte Daten (Store Persistent Data with Unique ID via KeyValueStorage). Es visualisiert das zweistufige Commit-Modell (RAM-Pufferung vs. synchronisierter NVRAM-/Disk-Flush) sowie die optionale, manifestgesteuerte Krypto-Integration vor der Übergabe an das Betriebssystem.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Stereotypen:
  • :Adaptive Application (Akteur / Prozess-Instanz): Nutzt die standardisierte funktionale C++-API von ara::per.
  • «aapFunctionalCluster» :Persistency (Plattform-Basisdienst): Realisiert den Functional Cluster ara::per; verwaltet In-Memory-Caches, Serialisierung, Redundanzprüfungen und Persistierungslogik.
  • :Operating System (Akteur / POSIX-Subsystem): Abstrahiert Dateisystem-, VFS- und Blocktreiberzugriffe über standardisierte POSIX-Systemschnittstellen.
  • «aapFunctionalCluster» :Cryptography (Plattform-Basisdienst): Realisiert den Functional Cluster ara::crypto; stellt kryptographische Transformationen, Algorithmen und Schlüsselkontexte bereit.
  • «aapInformative»: Stereotyp zur Kennzeichnung nicht-normativer bzw. betriebssystemspezifischer Interaktionen (open(), write()).
• Schnittstellen & Operationen:
  • OpenKeyValueStorage(): KeyValueStorage: Fabrikmethode/Getter am Persistency-Cluster zur Erlangung eines typisierten Storage-Handles (ara::per::KeyValueStorage).
  • SetValue(): Typisierte Schreiboperation auf den lokalen In-Memory-Puffer des Key-Value-Speichers.
  • SyncToStorage(): Synchronisationsbefehl zum physischen Flush der gepufferten Änderungen in den permanenten Speicher.
  • open(), write() (mit Stereotyp «aapInformative»): Low-Level-POSIX-Systemaufrufe zur Interaktion mit dem Dateisystem/Persistent Storage.
  • ProcessBlock(): Symmetrische Blockverschlüsselungs- bzw. Transformationsoperation der Krypto-Pipeline.
  • Store Redundant Data (referenzierte Interaktion / ref): Sub-Ablauf zur Speicherung redundanter Datenstrukturen zur Erkennung und Korrektur von Speicherfehlern.
• Konfigurations- und Manifestelemente:
  • KeySlotMapping: ARXML-Manifest-Zuordnung zwischen einem logischen Persistency-Port/Storage und einem konkreten physischen/logischen Crypto-KeySlot (ara::crypto::keys).
  • keySlotUsage = encryption: Manifest-Attribut, welches die kryptographische Verschleierung vor dem Dateisystem-Schreibvorgang erzwingt.
  • Redundancy enabled in Manifest: Manifest-Bedingung zur Aktivierung redundanter Datenspeicherung in Persistency.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung des Storage-Handles:
   • :Adaptive Application ruft synchron OpenKeyValueStorage() auf. :Persistency instanziiert bzw. bindet die KeyValueStorage-Ressource und gibt das Handle zurück.
2. In-Memory-Modifikation (Entkoppelter Schreibvorgang):
   • Die Applikation ruft SetValue() auf. :Persistency aktualisiert den Wert ausschließlich im flüchtigen Prozess-Arbeitsspeicher (Cache). Zu diesem Zeitpunkt findet keinerlei I/O-Interaktion mit dem Filesystem oder Krypto-Cluster statt.
3. Flush-Trigger (SyncToStorage):
   • Die Applikation stößt über SyncToStorage() die eigentliche Persistierungskette an.
4. Storage-Öffnung:
   • :Persistency initiiert den I/O-Kanal über den informativen POSIX-Aufruf open() («aapInformative») am :Operating System.
5. Konditionale Verschlüsselung (alt-Fragment):
   • Guard-Bedingung: [KeySlotMapping exists in Manifest and keySlotUsage = encryption].
   • Sub-Interaktion (ref): Ausführung des referenzierten Krypto-Setups Initialize Cipher (Allokation des Krypto-Kontextes, Import/Bindung des Schlüssels aus dem definierten KeySlot via ara::crypto).
   • Transformation: :Persistency übergibt die serialisierten Nutzdatenblöcke via ProcessBlock() synchron an :Cryptography und erhält den Chiffretext zurück.
6. Persistenter I/O-Schreibzugriff:
   • :Persistency schreibt den Datenstrom über den informativen POSIX-Aufruf write() («aapInformative») an das :Operating System.
7. Konditionale Redundanzspeicherung (alt-Fragment):
   • Guard-Bedingung: [Redundancy enabled in Manifest].
   • Sub-Interaktion (ref): :Persistency führt die referenzierte Interaktion Store Redundant Data aus, um redundante Daten zur Fehlererkennung und -korrektur im persistenten Speicher abzulegen. Nach Abschluss terminiert SyncToStorage().

4. Normative Relevanz & Entwickler-Hinweise

• Pufferungs- & Transaktionssemantik:
  • SetValue() garantiert keine Ausfallsicherheit gegen Power-Loss oder Crash. Persistenz wird erst mit dem erfolgreichen Abschluss von SyncToStorage() sichergestellt.
  • SyncToStorage() ist ein blockierender, I/O- und rechenintensiver Aufruf. In harten Echtzeitkontexten darf SyncToStorage() nicht hochfrequent/zyklisch aufgerufen werden; Modifikationen sind per SetValue() zu aggregieren und gezielt transaktionsorientiert zu flashen.
• Transparente Verschlüsselung via Manifest:
  • Die Anwendungssoftware interagiert rein mit Klartextdaten über SetValue(). Die Verschlüsselung ist vollkommen entkoppelt und wird ausschließlich über die Manifest-Modellierung gesteuert (KeySlotMapping).
• Fehler- und Determinismusbehandlung:
  • Schlägt open(), ProcessBlock() oder write() fehl (z. B. Speicher voll, Krypto-Schlüssel im Slot ungültig/gesperrt, I/O-Fehler), propagiert SyncToStorage() einen entsprechenden ara::core::Result<void>-Fehlercode (ara::per::PerErrc). Die Applikation muss diesen Rückgabewert zwingend auswerten, um Datenverlust zu detektieren.