Figure 10.3: Persistency File Storage Configuration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Metamodell-Klassendiagramm / Parametrisierungs- und Konfigurationsmodell (AUTOSAR Adaptive Platform Model Configuration, APMC).
• Funktionale Einordnung: Spezifikation der Manifest-Konfiguration des Functional Clusters Persistency (ara::per) für die dateibasierte Speicherung (File Storage). Es definiert die standardisierte Baumstruktur der Konfigurationscontainer und -parameter, mit denen Persistency-Dateispeicher und darin verwaltete Dateien im Ausführungs- bzw. Software-Paket-Manifest deklariert werden.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert eine kompositionelle Hierarchie ausgehend vom funktionalen Cluster bis hin zu einzelnen Dateiparametern und Update-Strategien:

• Persistency (ApmcFunctionalClusterDef, Mult.: 0..*): Wurzel-Definition des Functional Clusters für Persistenz-Konfigurationen auf Plattformebene.
  • +container → PersistencyFileStorageCollection (ApmcParamConfContainerDef, Mult.: 0..1): Optionaler Sammelcontainer zur Aggregation aller dateibasierten Speicherinstanzen.
• PersistencyFileStorage (ApmcParamConfContainerDef, Mult.: 0..*): Repräsentiert eine konkrete Instanz eines logischen Dateispeichers (File Storage), der über die C++ API (ara::per::OpenFileStorage) adressiert wird.
  • +container → PersistencyCommon (ApmcParamConfContainerDef, Mult.: 1..1): Obligatorischer Basis-Container für allgemeine Speichereigenschaften (z. B. Redundanz, Integritätsprüfungen oder generelle Zugriffsattribute).
    • +container → PersistencyCryptoKeySlotProps (ApmcParamConfContainerDef, Mult.: 0..1): Optionale Verknüpfung zu Crypto-Key-Slots zur Verschlüsselung/Signierung auf Storage-Ebene.
  • +container → PersistencyFileCollection (ApmcParamConfContainerDef, Mult.: 0..1): Optionaler Container zur Auflistung vorab konfigurierter/initialer Dateien innerhalb des Speichers.
• PersistencyFile (ApmcParamConfContainerDef, Mult.: 0..*): Beschreibt eine spezifische, im Manifest deklarierte Datei innerhalb des PersistencyFileStorage.
  • +container → PersistencyCryptoKeySlotProps (ApmcParamConfContainerDef, Mult.: 0..1): Optionale dateispezifische Krypto-Konfiguration (Verschlüsselung/Integritätssicherung für die einzelne Datei).
  • +element → FileName (ApmcStringParamDef, Mult.: 1..1): Eindeutiger logischer Name bzw. Pfadbezeichner der Datei innerhalb des File Storage.
  • +element → ContentUri (ApmcStringParamDef, Mult.: 0..1): Optionale URI auf ein initial bereitzustellendes Daten-Image bzw. Initial-Content im Auslieferungszustand (z. B. Paket-Payload).
  • +element → ElementUpdateStrategy (ApmcEnumerationParamDef, Mult.: 1..1): Pflicht-Steuerung des Verhaltens bei Software-Updates/FOTA. Aggregiert als +literal:
    • KEEP_EXISTING (ApmcEnumerationLiteralDef): Bestehende Datei auf dem Target-Dateisystem bleibt unverändert erhalten; neue Version im Paket wird verworfen.
    • OVERWRITE (ApmcEnumerationLiteralDef): Datei wird bedingungslos durch den neuen Stand aus dem Update-Paket überschrieben.
    • DELETE (ApmcEnumerationLiteralDef): Datei wird im Rahmen des Updates gelöscht bzw. nicht mehr vorgehalten.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Statisches Metamodell: Das Diagramm bildet keine Laufzeit-Sequenzen ab.
• Lebenszyklusbezug (Update & Manifest-Auswertung):
  1. Deployment / Installation: Die Manifest-Engine parst PersistencyFileStorage und legt das Speicherverzeichnis/die Metadaten an. Falls ContentUri angegeben ist, wird die initiale Nutzlast kopiert.
  2. Software-Update: Das Update and Configuration Management (UCM) bzw. die Persistency-Initialisierungsroutine evaluiert ElementUpdateStrategy:
     • Bei OVERWRITE wird die Zieldatei mit der Payload aus ContentUri überschrieben.
     • Bei KEEP_EXISTING werden persistierte Benutzer-/Anwendungsdaten geschützt.
     • Bei DELETE wird die Datei entfernt.
  3. Laufzeit: Der C++ API-Aufruf ara::per::OpenFileStorage(...) bindet an die über PersistencyFileStorage konfigurierte Instanz; Zugriffe über ara::per::File nutzen die über PersistencyCryptoKeySlotProps und FileName deklarierten Eigenschaften.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Autoren & Integratoren:
  • Jede im Manifest deklarierte persistente Datei (PersistencyFile) erfordert zwingend einen FileName und eine ElementUpdateStrategy. Fehlt die Angabe, ist das Manifest schema-ungültig.
  • Das Vorhandensein von PersistencyCommon mit Multiplizität 1..1 erzwingt die Definition von Basiseigenschaften pro File-Storage-Instanz.
• Applikations-Entwickler (ara::per):
  • Vorab im Manifest deklarierte Dateien stehen der Applikation sofort zur Verfügung. Dynamisch zur Laufzeit erzeugte Dateien, die nicht im Manifest deklariert wurden, unterliegen nicht zwingend den im Modell deklarierten Krypto-Slots oder Standard-Update-Strategien.
  • Krypto-Absicherung (PersistencyCryptoKeySlotProps) kann hierarchisch erfolgen: global auf Storage-Ebene (PersistencyCommon) oder granular überschrieben pro Einzeldatei (PersistencyFile).
• Update- & FOTA-Sicherheit:
  • Die Wahl von ElementUpdateStrategy ist architekturkritisch: Falsch deklariertes OVERWRITE bei Konfigurationsdateien führt zum Verlust gelernter/kalibrierter Laufzeitdaten; fälschliches KEEP_EXISTING verhindert Bugfixes an statischen Konfigurationstabellen.