Figure 9.38: Users of the FileStorage interfaces

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Strukturdiagramm / Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform, SWS-spezifische Modellierungsnotation).
• Architektur-Kontext: Veranschaulicht die architektonische Entkopplung und Standardisierung der dateibasierten Persistenz (ara::per::FileStorage) innerhalb der AUTOSAR Adaptive Platform (Release R21-11). Dargestellt ist die Bereitstellung des Port-Interfaces durch den Functional Cluster Persistency (PER) sowie dessen konsumierende Nutzung durch zentrale, plattforminterne System-Dämonen (Diagnostic Management [DM] und Update and Configuration Management [UCM]).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Functional Cluster

• «aapFunctionalCluster» Persistency: Bereitstellende Plattform-Komponente (Library/Driver-Layer). Implementiert die physische Ablage, Integritätsprüfungen (CRC/Redundanz) und Zugriffssicherheit auf dem zugrundeliegenden POSIX-Dateisystem.
• «aapFunctionalCluster» Diagnostic Management (daemon-based): Dämon-basierter Systemdienst für Diagnoseprotokolle (UDS, DoIP), Fehlerspeicherverwaltung und Snapshot/Extended-Data-Records.
• «aapFunctionalCluster» Update and Configuration Management (daemon-based): Dämon-basierter Systemdienst für Software-Paket-Handling, A/B-Partition-Swapping, Rollback-Szenarien und Delta-Updates.

Schnittstellen & Ports

• «aapAPI,aapPortInterface» Persistency::FileStorage: Port-Interface und C++-Klassenschnittstelle im Namespace ara::per. Kapselt dateibasierte CRUD-, Inspektions- und Wiederherstellungs-Operationen:
  • Metadaten & Status:
    • + FileExists()
    • + GetAllFileNames()
    • + GetCurrentFileSize()
    • + GetFileInfo()
  • Datenzugriff & Stream-Accessor:
    • + OpenFileReadOnly(): ReadAccessor (liefert RAII-gekapselten Lese-Stream)
    • + OpenFileWriteOnly(): ReadWriteAccessor (liefert schreibenden Accessor)
    • + OpenFileReadWrite(): ReadWriteAccessor (liefert bidirektionalen Lese-/Schreib-Accessor)
  • Lifecycle & Integrität:
    • + DeleteFile()
    • + RecoverFile() (Wiederherstellung bei Korruption via redundante Kopien/CRCs)
    • + ResetFile() (Zurücksetzen auf den Auslieferungs-/Manifest-Zustand)
• Stereotypen & Beziehungen:
  • Realisierung (--▷): Persistency implementiert das Interface Persistency::FileStorage.
  • Verwendung («use», «aapRequiredPort»): Sowohl Diagnostic Management als auch Update and Configuration Management interagieren ausschließlich über typisierte Client-Ports (RPortPrototype) mit der FileStorage-Schnittstelle.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Schnittstellendiagramm handelt, bestimmt die Interface-Definition folgendes Laufzeit-Zugriffsmuster:

1. Port-Lookup / Proxy-Erzeugung: Konsumenten (DM/UCM) öffnen den konfigurierten Speicherbereich über das Port-Binding mittels ara::per::OpenFileStorage(instanceSpecifier).
2. Dateihandling & Stream-Zugriff:
   • Existenz- und Größenprüfung via FileExists() / GetFileInfo().
   • Dateizugriff erfolgt nicht über rohe POSIX-File-Descriptors (fd), sondern synchron über polymorphe Accessor-Klassen (ReadAccessor, ReadWriteAccessor).
   • Schreiboperationen werden über Puffer abgewickelt; die Persistierung auf dem Flash/Storage-Medium erfolgt erst durch Zerstörung des Accessors (RAII) oder expliziten Flush (SyncToFile()).
3. Integritäts- & Recovery-Pfade:
   • Detektiert Persistency einen Prüfsummen- oder M-out-of-N-Redundanzfehler beim Öffnen, initiiert der Dämon RecoverFile().
   • Bei irreparabler Beschädigung oder Factory-Reset-Anforderungen ruft der Konsument ResetFile() auf, um die Datei aus dem initialen Deployment-Package wiederherzustellen.
4. Bereinigung: UCM nutzt DeleteFile() nach erfolgreicher Aktivierung oder Verwerfen von temporären Update-Containern.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Vorgabe (POSIX-Verbot): Direkte Systemaufrufe (open(), read(), write(), std::fstream) auf Host-Betriebssystem-Ebene sind für Adaptive Applications und Functional Cluster unzulässig. Jeder persistente Dateizugriff muss port-basiert über ara::per geroutet werden, um Plattformunabhängigkeit, Sandbox-Isolation und Access-Control-Listen (ACLs/Security) zu gewährleisten.
• Manifest-Modellierung (ARXML):
  • Entwickler müssen für jede FileStorage-Nutzung ein PersistencyFileStorageInterface, ein entsprechendes PersistencyPortPrototype und ein PersistencyDeployment anlegen.
  • In den Deployment-Deskriptoren sind Pfad-Mappings, maximale Quotas (maximumAllowedSize), Redundanzstufen (z. B. CRC32, MOutOfN) und optionale Initial-Dateien (PersistencyFileElement) normativ festzulegen.
• Fehlerbehandlung (ara::core::Result<T>): Sämtliche Methoden liefern standardmäßig ara::core::Result (Exceptions sind in der AUTOSAR Adaptive Core API optional bzw. per Guideline deaktiviert). Rückgabewerte müssen zwingend gegen ara::per::PerErrc (z. B. kFileNotFound, kOutOfMemory, kPhysicalStorageFailure, kValidationFailed) geprüft werden.
• Plattform-Spezifika für DM und UCM:
  • UCM: Nutzt FileStorage primär für Staging-Areas von Software-Paketen, Rollback-Snapshots und Manifest-Validierungen.
  • DM: Speichert DTC-Historien, freeze frames und UDS-Konfigurationen ab. Erfordert deterministisches Schreibverhalten bei anstehendem Power-Down (PrepareStorageShutdown).