Figure 9.35: Functional Clusters in category Storage

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm (Strukturdiagramm / Architekturebene).
• Architektonische Einordnung: Darstellung des funktionalen Spektrums der AUTOSAR Adaptive Platform (AP) innerhalb der Domänen-Kategorie Storage gemäß AUTOSAR_AP_EXP_SWArchitecture.
• Technischer Zweck: Definition und formale Zuordnung des Functional Clusters (FC) Persistency (ara::per) als zentrale Plattforminstanz für nicht-flüchtige Datenspeicherung (Non-Volatile Data Management) auf POSIX-basierten Adaptive-ECUs.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten & Stereotypen:
  • Persistency: Spezifiziert als «aapFunctionalCluster» (AUTOSAR Adaptive Platform Functional Cluster). Bildet die alleinige Entität der Kategorie Storage.
• Schnittstellen & Namensräume (C++ API):
  • ara::per::KeyValueStorage: Typsicherer Zugriff auf strukturierte Schlüssel-Wert-Paare (skalare Typen, Arrays, komplexe Datenobjekte) mit integrierter Serialisierung/Deserialisierung.
  • ara::per::FileStorage: Unstrukturierter blockorientierter Stream-Zugriff über Reader-/Writer-Accessoren (ReadAccessor, ReadWriteAccessor) auf partitionierte Dateistrukturen.
• Plattformbeziehungen & OS-Bindung:
  • Kapselt die darunterliegenden POSIX-Dateisystemtreiber (z. B. ext4, Flash-Dateisysteme) und NVRAM-Hardwaretreiber gegenüber Adaptive Applications (AA).
  • Logische Kopplung an Update and Configuration Management (UCM) zur Unterstützung konsistenter Daten- und Schemamigrationen bei Software-Updates.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Statischer Charakter: Das Diagramm modelliert die Klassenzugehörigkeit; kein dynamischer Sequenzablauf im Schaubild enthalten.
• Laufzeit- und Ausführungsmodell:
  • Bibliotheksmodell: Typischerweise als In-Process-Library realisiert; Methodenaufrufe von ara::per laufen direkt im Thread-Kontext der aufrufenden Adaptive Application.
  • Synchronisation & Atomizität: Datei- und Key-Value-Modifikationen erfolgen standardmäßig im Cache/Puffer; die persistente Sicherung wird über explizite Synchronisationsaufrufe (z. B. SyncToStorage()) transaktional und atomar gegen Stromausfall abgesichert.
  • Fehlerpfade: Rückgabe über ara::core::Result<T, ara::per::PerErrc> ohne C++-Exceptions.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration (ARXML):
  • Zugriff auf Persistency-Ressourcen muss im Execution- und Service-Instance-Manifest explizit deklariert werden (PersistencyPortPrototype, PersistencyFileProxyInterface, PersistencyKeyValueDatabaseInterface).
  • Deklarative Definition von Quotas (maxAllowedSize), Redundanzstufen (z. B. CRC32, M-aus-N-Redundanz) sowie Verschlüsselungsparametern (unter Einbindung des Crypto-Stacks).
• Entwickler-Restriktionen:
  • Direkte POSIX-I/O-Aufrufe (open, read, write) auf Persistenzpfade verstoßen gegen die Plattformkonformität; der Zugriff hat zwingend über ara::per zu erfolgen, um Konsistenzprüfungen, automatische Wiederherstellung (Data Corruption Recovery) und Migrationspfade nicht zu kompromittieren.
  • Applikationen müssen Persistenz-Zugriffe auf deterministische Ausführungsphasen beschränken, um I/O-Blockaden in echtzeitkritischen Verarbeitungszyklen zu verhindern.