Figure 10.9: Use Cases for Monitoring

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) mit AUTOSAR-spezifischem Metamodell-Stereotypen-Profil («aap...»).
• Technischer Zweck & Einordnung:
  • Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Persistency (ara::per), Dokumentationsabschnitt Monitoring.
  • Funktionaler Zweck: Spezifikation der Interaktion zur Ermittlung des belegten bzw. allokierten persistenten Speicherplatzes eines Storage-Bereichs (Key-Value-Storage oder File-Storage) durch eine Adaptive Application.
  • Schichten-Kontext: Kapselung des Zugriffs auf Low-Level-Dateisystem- bzw. Speicherstatistiken des zugrundeliegenden POSIX-Betriebssystems gegenüber der anwendungsspezifischen Persistenzschicht.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen & Packages:
  • Adaptive Platform: Übergreifender architektonischer Scope der Laufzeitumgebung (ARA).
  • Persistency: Enthaltenes Subsystem / Functional Cluster (ara::per), welches den Use Case kapselt.
• Akteure (Actors):
  • Adaptive Application (aus Package Actors): Primärer, aktiver Akteur (Konsument der Persistenz-Dienste).
  • Operating System: Sekundärer, passiver bzw. dienstanbietender Akteur (stellt physische Dateisystem- und Block-/Speicherressourcen bereit).
• Anwendungsfall:
  • «aapUseCase» Get Storage Size: Repräsentiert die Ermittlung der aktuellen Speichergröße (belegter/verfügbarer Speicherplatz).
• Beziehungen & Stereotypen:
  • Adaptive Application → Get Storage Size: Gerichtete/assoziierte Kopplung mit Stereotyp «aapTriggers» (Anwendung initiiert den Kontrollfluss).
  • Operating System → Get Storage Size: Assoziation mit Stereotyp «aapParticipates» (Betriebssystem stellt die erforderlichen Low-Level-Ressourcendaten/Kernel-APIs bereit).

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering:
   • Die Adaptive Application ruft an der initialisierten Instanz (ara::per::SharedHandle<KeyValueStorage> oder ara::per::SharedHandle<FileStorage>) die Abfragemethode für die Speichergröße auf (z. B. GetCurrentStorageSize()).
2. Plattform-Verarbeitung & OS-Beteiligung:
   • Der Functional Cluster Persistency fängt den Aufruf ab und aggregiert die Metadaten.
   • «aapParticipates»: Persistency delegiert Low-Level-Abfragen an das Operating System (z. B. POSIX-Systemaufrufe wie stat(), statvfs() oder filesystem-spezifische Quota-APIs).
3. Rückgabe & Fehlerbehandlung:
   • Synchroner oder zukunftsbasierter Pfad: Rückgabe von ara::core::Result<std::uint64_t> (bzw. ara::core::Future).
   • Mögliche Fehlerzustände (ara::per::PerErrc): z. B. kPhysicalStorageFailure, kStorageLocationNotFoundError bei nicht erreichbarem OS-Mountpoint oder Dateisystemkorruption.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::per):
  • Entwickler von Adaptive Applications nutzen diesen Mechanismus für Self-Monitoring und Quota-Überwachung, um Schreibabbrüche durch Speichermangel (kOutOfStorageSpace) präventiv abzufangen.
  • Die Methoden geben die Bruttogröße (Nutzdaten inkl. Persistency-Overhead wie Redundanzdaten, Integrity-Hashes, Validierungsheader) oder Nettogröße zurück, abhängig von der verwendeten Schnittstelle (GetCurrentStorageSize vs. Quota-Limits).
• Integrations- & OS-Anforderungen:
  • Der Plattform-Implementierer (Stack-Vendor) muss sicherstellen, dass das zugrundeliegende OS/BSP Zugriffsrechte und Performance für Größenabfragen auf den persistenten Partitionen bereitstellt, ohne das Echtzeitverhalten des Systems durch blockierende I/O-Scans zu degradieren.
  • Bei aktivierten Verschlüsselungs- und Integritätsmechanismen (z. B. HMAC/CRC im Persistency-Design) fließen kryptografische Metadaten in die von der OS-Ebene gemeldete physische Speicherbelegung ein.