Figure 11.14: Scenario: Read Persistent Data from File

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt, loop und ref).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R23-11), Spezifikation AUTOSAR_AP_EXP_SWArchitecture (Doc-ID 982), Kapitel 11.3 Storage / Persistency.
• Technischer Zweck: Darstellung des synchronen Standardablaufs beim sequenziellen, zeilenbasierten Lesen persistenter Daten über die ara::per-Dateischnittstelle (FileStorage / ReadAccessor). Es visualisiert die Kapselung von Low-Level-OS-Dateizugriffen, hardware- bzw. dateibasierter Redundanz/Fehlerkorrektur und transparenter Krypto-Entschlüsselung (ara::crypto) unterhalb der Persistency-Clustergrenze.

2. Komponenten, Entitäten & Schnittstellen

• Lifelines & Funktionale Einheiten:
  • :Adaptive Application: Anwendungsinstanz im User-Space, die typisierte Persistenzdienste konsumiert.
  • «aapFunctionalCluster» :Persistency: AUTOSAR Adaptive Platform Functional Cluster (ara::per), verantwortlich für Datenhaltung, Caching, Integritätssicherung und Krypto-Orchestrierung.
  • :Operating System: POSIX-kompatibles Betriebssystem / Kernel mit VFS/Dateisystemtreiber.
  • «aapFunctionalCluster» :Cryptography: AUTOSAR Adaptive Platform Functional Cluster (ara::crypto), zuständig für kryptografische Operationen und Schlüsselverwaltung.
• Schnittstellen & Methodenaufrufe:
  • Application-to-Persistency API:
    • OpenFileStorage(): FileStorage: Öffnet den logischen Speicherraum anhand der Manifest-Konfiguration.
    • reader = OpenFileReadOnly(): ReadAccessor: Erzeugt ein schreibgeschütztes Stream-/Accessor-Objekt auf einer dedizierten Datei (Rückgabeinstanz reader).
    • line = ReadLine(): Synchroner Lesevorgang einer textuellen Zeile bis zum Delimiter/EOF.
    • reader.IsEof(): Abfrage der Abbruchbedingung (End of File) über das Reader-Objekt.
  • Persistency-to-OS (POSIX Syscalls):
    • open() («aapInformative»): Öffnen des Dateideskriptors im zugrunde liegenden Filesystem (als informativer Aufruf gekennzeichnet).
    • read() («aapInformative»): Blockweises/gepuffertes Einlesen von Binärdaten vom Festspeicher (als informativer Aufruf gekennzeichnet).
  • Persistency-to-Crypto API:
    • ProcessBlock(): Symmetrische Blockentschlüsselung des eingelesenen Ciphertexts im flüchtigen Speicher.
• Manifest-Artefakte & Konfigurations-Prädikate:
  • Redundancy enabled in Manifest: Steuert aktivierte Mechanismen zur Datenintegrität (z. B. CRC, Checksums, M-out-of-N-Replikation).
  • KeySlotMapping exists in Manifest and keySlotUsage = encryption: Deklariert die Zuordnung eines CryptoKeySlot zur Persistenzdatei zwecks transparenter In-Flight-Entschlüsselung.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Öffnungsphase:
   • :Adaptive Application ruft synchron OpenFileStorage() auf :Persistency auf und erhält eine Referenz auf FileStorage.
   • Die Applikation fordert über reader = OpenFileReadOnly() den Lese-Zugriff an.
   • :Persistency delegiert die Anforderung per open() an das :Operating System.
2. Integritäts- & Redundanzprüfung (alt [Redundancy enabled in Manifest]):
   • Bedingung: Redundanz ist im Manifest konfiguriert.
   • Ausführung: Sub-Sequenz ref Detect and Correct Data Errors wird durchlaufen. Persistency prüft Prüfsummen/Spiegeldateien und korrigiert etwaige Bitkipper/Datenkorruptionen vor der Freigabe.
3. Cipher-Initialisierung (alt [KeySlotMapping exists in Manifest and keySlotUsage = encryption]):
   • Bedingung: Datei ist im Manifest als verschlüsselt deklariert und besitzt ein valides Key-Slot-Mapping.
   • Ausführung: Sub-Sequenz ref Initialize Cipher interagiert mit :Cryptography (Laden des symmetrischen Schlüssels, Allokation des Cipher-Kontexts, z. B. AES-CBC/GCM, IV/Nonce-Initialisierung).
4. Iterative Lese-Schleife (loop [not reader.IsEof()]):
   • Äußere Schleife: Die Applikation ruft zyklisch line = ReadLine() am Reader (ReadAccessor) auf, bis reader.IsEof() == true signalisiert wird.
   • Innere Pufferung & Entschlüsselung (loop):
     • :Persistency triggert read() gegen das :Operating System, um Raw-Blöcke in interne Zwischenpuffer einzulesen.
     • alt [KeySlotMapping exists in Manifest and keySlotUsage = encryption]: Liegt Verschlüsselung vor, übergibt Persistency den Block via ProcessBlock() an :Cryptography zur synchronen Entschlüsselung.
   • Rückgabe: Die assemblierte Klartext-Zeile wird als line synchron an :Adaptive Application zurückgegeben.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenz & Abstraktion: Weder Krypto-Handling (ara::crypto) noch Integritätschecks (Redundanz) sind in der Applikationslogik sichtbar. Die Adaptive Application interagiert ausschließlich gegen die abstrakte ara::per::ReadAccessor-Schnittstelle.
• Manifest-Abhängigkeit: Die funktionale Tiefe von OpenFileReadOnly() und ReadLine() wird zur Deployment-Zeit im Execution-/Instance-Manifest festgelegt (PersistencyFileProxy, KeySlotMapping, Redundanz-Attribute). Fehlt das Key-Mapping bei verschlüsselten Dateien, schlägt das Öffnen fehl (kConfigError / kSecurityError).
• Performance & Blockgrenzen: Obwohl die Applikation zeilenbasiert (ReadLine()) liest, operiert das Back-End blockbasiert (read(), ProcessBlock()). Bei harten Latenzanforderungen muss beachtet werden, dass ReadLine() bei Puffer-Misses synchrone OS-I/O und synchrone Krypto-Berechnungen blockierend im Thread-Kontext des Aufrufers ausführt.
• Fehlersemantik: Entwickler müssen die standardisierten Fehlercodes (über ara::core::Result<...>) abfangen, da I/O-Fehler, Validierungsfehler der Redundanzschicht oder Fehlschläge bei ProcessBlock() unmittelbar zum Scheitern von ReadLine() bzw. OpenFileReadOnly() führen.