Figure 9.47: Users of the FileStorage interface

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Strukturdiagramm nach AUTOSAR Adaptive Platform Metamodell).
• Technischer Zweck: Spezifikation der Architekturbeziehungen und Abhängigkeiten zwischen der AUTOSAR Adaptive Platform (AP) Basiskomponente Persistency (PER) und ihren primären Plattform-Konsumenten auf Basis der dateibasierten Speicherabstraktion (FileStorage).
• Funktionale Einordnung: Innerhalb der AP Foundation/Services stellt das Functional Cluster Persistency standardisierte C++-Schnittstellen (ara::per) bereit. Während Anwendungen typischerweise KeyValueStorage nutzen, benötigen koordinierende System-Daemons (DM, UCM, VUCM) direkte Datei-Semantik (FileStorage) zur persistenten Ablage großer, strukturierter oder binärer Datenmengen (z. B. DTC-Event-Speicher, Software-Update-Pakete, Kampagnen-Metadaten).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Persistency: Bereitstellendes Functional Cluster (Library-/Treiber-Implementierung), das physischen NVRAM/Flash-Speicher kapselt und Integrität/Redundanz absichert.
• «aapAPI,aapPortInterface» FileStorage: Zentrales Schnittstellenelement (ara::per::FileStorage), das sowohl als formales Port-Interface im Metamodell als auch als C++-API typisiert ist.
• Konsumierende Functional Clusters (daemon-based):
  • Diagnostic Management (DM): Diagnose-Server zur Persistierung von Diagnosezuständen, Freeze Frames, Extended Data Records und DTC-Statusinformationen.
  • Update and Configuration Management (UCM): Lokaler Update-Manager für Software-Cluster; persistiert Transfer-Puffer, Package-Manifeste und Rollback-Images.
  • Vehicle Update and Configuration Management (VUCM): Flotten- und Fahrzeug-Update-Orchestrator; persistiert globale Kampagnenzustände, Rollout-Logs und Sicherheitsnachweise.

Schnittstellenmethoden (FileStorage)

• Lebenszyklus & Metadaten: DeleteFile(), FileExists(), GetAllFileNames(), GetCurrentFileSize(), GetFileInfo().
• Datenzugriff:
  • OpenFileReadOnly(): ReadAccessor (Gibt zeiger-/strombasierte Leseabstraktion zurück).
  • OpenFileReadWrite(): ReadWriteAccessor (Gibt Schreib-/Leseabstraktion mit atomaren/transaktionalen Garantien zurück).
  • OpenFileWriteOnly(): ReadWriteAccessor (Gibt reine Schreibabstraktion zurück).
• Fehlertoleranz & Integrität: RecoverFile(), ResetFile() (Wiederherstellung redundanter Kopien oder Werkszustände bei Korruption).

Beziehungen

• Realisierung («aapFunctionalCluster» Persistency ⇢ FileStorage): Das Cluster Persistency implementiert das Interface vollständig.
• Abhängigkeiten («use», «aapRequiredPort»): DM, UCM und VUCM besitzen jeweils einen Required Port, der über die «use»-Beziehung an die Operationen von FileStorage bindet.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl rein strukturell modelliert, diktiert die Schnittstellensignatur folgende Abläufe zur Laufzeit:

1. Dateizugriff & Handle-Allokation:
   • Ein Daemon ruft synchron OpenFileReadOnly(), OpenFileWriteOnly() oder OpenFileReadWrite() auf.
   • Persistency validiert Zugriffsrechte (Manifest-Konfiguration/POSIX-UID/GID) und liefert ein ara::core::Result<ReadAccessor> bzw. ReadWriteAccessor (RAII-gesteuertes Proxy-Objekt) zurück.
2. I/O-Verarbeitung & Persistierung:
   • Operationen über ReadAccessor bzw. ReadWriteAccessor streamen Datenblöcke.
   • Pufferung und Flush-Semantik (z. B. fsync-Äquivalente) werden durch Persistency kapselnd gesteuert.
3. Integritätsverletzung & Recovery:
   • Tritt bei Dateioperationen ein CRC-/Kryptofehler auf (z. B. Erkennung im ReadAccessor), kann der Daemon RecoverFile() initiieren (Fallback auf Backup-Cluster/Redundanz) oder über ResetFile() die Standardwerte aus dem Package-Manifest wiederherstellen.
4. Verwaltung:
   • Nach Abschluss von Updates löscht UCM temporäre Dateien via DeleteFile(); der Dateiindex wird über GetAllFileNames() synchronisiert.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::per):
  • Rückgabewerte folgen dem ara::core::Result<T>-Fehlerbehandlungsmodell (keine C++-Exceptions).
  • Accessoren (ReadAccessor, ReadWriteAccessor) sind non-copyable, move-only RAII-Typen. Ein Zuklappen der Datei erfolgt deterministisch beim Zerstören des Accessor-Objekts.
• Port- und Manifest-Konfiguration:
  • Daemons deklarieren in ihrem ARXML-Execution-Manifest einen RPortPrototype mit FileStorage-Interface.
  • Das Persistency-Manifest muss die FileStorage-Port-Verbindung mit konkreten Storage-Pfaden, Quotas (maximaler Speicherplatz), Redundanzgrad (kNone, kMrc, kCrc) und Reinitialisierungsstrategien verknüpfen.
• Parallelität & Thread-Sicherheit:
  • Der gleichzeitige schreibende Zugriff (OpenFileWriteOnly/OpenFileReadWrite) auf denselben Dateinamen innerhalb desselben oder über verschiedene Prozesse hinweg führt ohne explizite Synchronisation zu PerErrc::kFileLocked. Daemons müssen Schreibzugriffe prozessintern serialisieren.
• Einschränkung für Applikations-Entwickler:
  • FileStorage ist für strukturierte Großdaten gedacht. Standard-Anwendungsdaten, Parameter und Einzelvariablen sind aus Performance- und Portabilitätsgründen zwingend über KeyValueStorage zu persistieren.