Figure 11.18: Scenario: Get FileStorage Size

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des Kontrollflusses zur Abfrage der aggregierten Belegungsgröße eines Datei-Containers (FileStorage) im Kontext der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Funktionaler Cluster Persistency (ara::per). Das Szenario demonstriert die Kapselung und Abstraktion des zugrundeliegenden Host-/POSIX-Dateisystems gegenüber der Anwendungsebene zwecks Einhaltung der Resource-Quota- und Sandbox-Grenzen.

2. Komponenten, Entitäten & Schnittstellen

• :Adaptive Application (Akteur / Lifeline):
  • Anwendungsinstanz/Prozess im User Space, agiert als Service-Consumer.
• «aapFunctionalCluster» :Persistency (Architekturbaustein / Lifeline):
  • Standardisierter AUTOSAR Adaptive Platform Functional Cluster (ara::per).
  • Kapselt Persistenzstrategien (Key-Value-Storage und File-Storage).
  • Bereitgestellte Schnittstelle: ara::per::FileStorage::GetCurrentFileStorageSize().
• :Operating System (Akteur / Lifeline):
  • POSIX-konformes Betriebssystem (z. B. QNX Neutrino, Linux RT).
  • Verwaltet Virtual File System (VFS), Inodes und Blocktreiber.
  • Schnittstelle: Native OS-Systemaufrufe, im Diagramm als informativer Aufruf (getSize() mit Stereotyp «aapInformative») abstrahiert.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Die :Adaptive Application setzt den synchronen Aufruf GetCurrentFileStorageSize() auf einer geöffneten Instanz von ara::per::FileStorage ab.
2. OS-Delegation: Der Cluster :Persistency initiiert intern den Aufruf getSize() an das :Operating System. Dies entspricht OS-seitig der Abfrage der physischen Dateigrößen bzw. Verzeichniseinträge (z. B. via stat() / fstat() / statvfs() oder Verzeichnistraversierung über readdir()).
3. Ergebniserfassung & Rückkehr:
   • Das Betriebssystem liefert die File-Metadaten an :Persistency zurück.
   • :Persistency aggregiert die Bytegrößen aller zugeordneten persistenten Dateien und terminiert die synchrone Ausführung mit Rückgabe des akkumulierten Werts als ara::core::Result<std::uint64_t>.
   • Tritt während des OS-Zugriffs ein Fehler auf (z. B. I/O-Fault, unvollständige Metadaten), bricht die Sequenz ab und transformiert den Fehler in einen ara::per::PerErrc (z. B. kPhysicalStorageFailure).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (Applikationsebene):
  • Aufruf ist blockierend/synchron. Entwickler dürfen GetCurrentFileStorageSize() nicht in zeitkritischen Thread-Kontexten oder harten Echtzeitschleifen ausführen, da je nach Dateianzahl und Storage-Typ signifikante I/O-Latenzen entstehen.
  • Der Rückgabewert ist typisiert als ara::core::Result<std::uint64_t> und erzwingt zwingend eine Fehlerbehandlung vor dem Dereferenzieren des Werts.
• Platform- & Stack-Implementierung:
  • Der Persistency-Stack muss sicherstellen, dass nur Dateien erfasst werden, die zum Namespace und Scope des jeweiligen PersistencyFileStorage gehören (Vermeidung von Information Leakage).
  • Zur Latenzoptimierung empfiehlt sich stack-intern ein aggregiertes Tracking bei Schreiboperationen oder Caching der Dateigrößen, um wiederholte Traversierungen des VFS zu minimieren.
• Konfigurationsbezug (Manifeste):
  • Die ermittelte Größe korreliert direkt mit dem im Execution/Platform-Manifest definierten Parameter PersistencyFileStorage.maximumAllowedSize.
  • Dient typischerweise dem präventiven Quota-Monitoring der Applikation, bevor Schreiboperationen via OpenFileWrite() oder Write() mit Quota-Exceeded-Fehlern fehlschlagen.