Figure 10.1: Top-level Persistency Configuration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Strukturdiagramm für die Adaptive Platform Parameter Configuration (Apmc).
• Funktionale Einordnung: Definiert die hierarchische Top-Level-Konfigurationsarchitektur des Functional Clusters Persistency (ara::per) der AUTOSAR Adaptive Platform (AP). Es spezifiziert die formale Struktur der Manifest-Modellierung zur deklarativen Beschreibung von persistenten Speicherressourcen (Key-Value-Storage und File-Storage) auf Maschinenebene (ApmcFunctionalClusterDef).

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Container-Definitionen

• Persistency (ApmcFunctionalClusterDef):
  • Root-Container der Persistency-Cluster-Konfiguration.
  • Multiplizität: [0..*] (pro Maschine bzw. Systemkonfiguration instanziierbar).
• PersistencyGeneral (ApmcParamConfContainerDef):
  • Cluster-globale Parameterdefinitionen (z. B. Logging-Attribute, Versionsprüfung, generelle Initialisierungs-Policies).
  • Multiplizität: [1..1] (Pflichtcontainer).
• PersistencyKeyValueStorageCollection (ApmcParamConfContainerDef):
  • Sammelcontainer für alle typisierten Key-Value-Datenbanken / Schlüssel-Wert-Speicher.
  • Multiplizität: [0..1] (optional, falls nur File-Storage oder keine KVS genutzt wird).
• PersistencyFileStorageCollection (ApmcParamConfContainerDef):
  • Sammelcontainer für dateibasierte Speicherbereiche (virtuelle Dateisystem-Volumes).
  • Multiplizität: [0..1] (optional, falls nur KVS genutzt wird).
• PersistencyKeyValueStorage (ApmcParamConfContainerDef):
  • Konfigurationsknoten für eine konkrete KVS-Instanz (wird im Application-Manifest referenziert / gemappt).
  • Multiplizität: [0..*] aggregiert unterhalb von PersistencyKeyValueStorageCollection.
• PersistencyFileStorage (ApmcParamConfContainerDef):
  • Konfigurationsknoten für eine konkrete File-Storage-Instanz.
  • Multiplizität: [0..*] aggregiert unterhalb von PersistencyFileStorageCollection.
• PersistencyCommon (ApmcParamConfContainerDef):
  • Standardisierter gemeinsamer Konfigurationsrumpf für Speicherinstanzen (beinhaltet persistenzübergreifende Attribute wie Redundanzmechanismen, CRC-/Integritätsprüfungen, Sync-Strategien, Verschlüsselungsreferenzen).
  • Multiplizität: [1..1].

Beziehungen & Kardinalitäten

• Kompositionen (Black Diamond Aggregation, Rollenname +container):
  • Persistency ──1──◆ [1..1] ──> PersistencyGeneral
  • Persistency ──1──◆ [0..1] ──> PersistencyKeyValueStorageCollection
  • Persistency ──1──◆ [0..1] ──> PersistencyFileStorageCollection
  • PersistencyKeyValueStorageCollection ──1──◆ [0..*] ──> PersistencyKeyValueStorage
  • PersistencyFileStorageCollection ──1──◆ [0..*] ──> PersistencyFileStorage
  • PersistencyKeyValueStorage ──1──◆ [1..1] ──> PersistencyCommon
  • PersistencyFileStorage ──1──◆ [1..1] ──> PersistencyCommon

3. Dynamisches Verhalten & Sequenzablauf (Konfigurations- und Initialisierungskontext)

Da es sich um ein statisches Konfigurationsmetamodell handelt, existiert kein PDU-/Laufzeit-Call-Sequenzablauf innerhalb des Modells. Das dynamische Mapping im Lifecycle gestaltet sich wie folgt:

1. Design-/Build-Time: Die Modellierungs-Tools instanziieren anhand dieser Metamodell-Regeln das Execution- / Machine-Manifest bzw. die Persistency-Cluster-Konfigurationsartefakte.
2. Deployment/Startup: Der Adaptive-Core-/Persistency-Daemon (oder die verlinkte ara::per-Bibliothek) parst die instanziierten Container beim Prozessstart.
3. Instanziierung der Storage-Handles:
   • Jeder konfigurierte PersistencyKeyValueStorage-Knoten initialisiert interne In-Memory-Indizes, Shared-Memory-Segmente oder relationale/NoSQL-Backends.
   • Jeder PersistencyFileStorage-Knoten bindet die zugewiesenen Pfade (Flash-Partitionen, NVM, emulierte POSIX-Dateisystempfade) ein.
4. Applikatorischer Zugriff: Applikationen fordern zur Laufzeit über ara::per::OpenKeyValueStorage() bzw. ara::per::OpenFileStorage() via InstanceSpecifier exakt die Instanzen an, die über diese Top-Level-Containerstruktur deklariert und verknüpft sind.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung der Speicherparadigmen: Die Top-Level-Architektur erzwingt eine strikte Trennung zwischen strukturiertem Schlüssel-Wert-Zugriff (ara::per::KeyValueStorage) und unstrukturiertem Byte-Stream-/Datei-Zugriff (ara::per::FileStorage).
• Zwingende PersistencyCommon-Präsenz: Sowohl KVS als auch File-Storage müssen zwingend ([1..1]) die Attribute von PersistencyCommon instanziieren. Treiber- und Stack-Implementierer müssen sicherstellen, dass Sicherheits-, Redundanz- und Update-/Reset-Strategien für beide Speichertypen identisch über diese gemeinsame Struktur validiert werden.
• Manifest-Validierung & Generatoren:
  • Schema-Validatoren (z. B. ARXML-Parser) müssen abbrechen, wenn PersistencyGeneral fehlt oder wenn eine Storage-Instanz ohne zugehörigen PersistencyCommon-Subcontainer definiert ist.
  • Das Fehlen der Collections ([0..1]) erlaubt minimale Footprint-Konfigurationen für ECUs, die ausschließlich eine der beiden Speicherformen (oder nur volatile Daten) benötigen.
• Sicherheit & Zugriffsschutz: Die Konfiguration spannt die Basis auf, über die im weiteren Deployment Zugriffsrechte (Access Control Lists / POSIX-UIDs/GIDs) und Quota-Limits (maximale Storage-Größe pro KVS/File-Storage) an die jeweiligen Adaptive Applications gebunden werden.