Figure 10.5: Persistency Common Configuration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR Metamodell-Klassendiagramm / Konfigurationsmodell auf Basis des Parameter-Konfigurationsmetamodells der Adaptive Platform (Apmc – Adaptive Platform Module Configuration).
• Technischer Zweck: Spezifikation der gemeinsamen Konfigurationsstruktur (PersistencyCommon) für persistente Speicherinstanzen im Functional Cluster Persistency (ara::per).
• Funktionale Einordnung: Dient als zentraler Konfigurationsknoten für beide persistente Speicherparadigmen der Adaptive Platform:
  • Key-Value-Datenbanken (PersistencyKeyValueStorage)
  • Dateibasierte Persistenz (PersistencyFileStorage) Bündelt generische Metadaten zu Quotas, Update-Verhalten, physischer Pfadabbildung, Integrität/Verschlüsselung sowie zur Port- bzw. Plattform-Cluster-Autorisierung.

2. Komponenten, Entitäten & Schnittstellen

Übergeordnete Speicher-Container

• PersistencyKeyValueStorage (ApmcParamConfContainerDef, Multiplizität 0..*): Konfigurationscontainer für Key-Value-Stores.
• PersistencyFileStorage (ApmcParamConfContainerDef, Multiplizität 0..*): Konfigurationscontainer für Datei-Stores.
• Beziehung: Beide aggregieren über die Kompositionsrolle +container zwingend genau eine Instanz (1..1) von PersistencyCommon.

Zentraler Container: PersistencyCommon (ApmcParamConfContainerDef, Multiplizität 1..1)

Definiert die gemeinsamen Parameter und Subcontainer:

1. Größenbegrenzung (Storage Quota):
   • MinimumSustainedSize (ApmcIntegerParamDef, 1..1): Mindestens garantierter/zu reservierender Speicherplatz in Bytes. Wertebereich: [0, 18446744073709551615] (2^64-1, uint64).
   • MaximumAllowedSize (ApmcIntegerParamDef, 1..1): Harte Speicherobergrenze (Quota) in Bytes. Wertebereich: [0, 18446744073709551615].
2. Lebenszyklus & Versionierung:
   • Version (ApmcStrongRevisionLabelParamDef, 1..1): Semantisches Revisionslabel des persistenten Speicherinhalts zur Konsistenzprüfung über Software-Updates hinweg.
   • ContractVersion (ApmcStrongRevisionLabelParamDef, 0..1): Revisionslabel des Schnittstellen- bzw. Integrationsvertrags.
   • UpdateStrategy (ApmcEnumerationParamDef, 1..1): Definiert das Verhalten des Persistency-Stacks bei Revisionsänderungen der Software (Version).
     • DELETE (ApmcEnumerationLiteralDef): Löschen und Neuinitialisieren des Speichers bei Versionsdiskrepanz.
     • KEEP_EXISTING (ApmcEnumerationLiteralDef): Beibehalten bestehender Daten (erfordert applikationsseitige Migrationslogik).
3. Zugriffskonfiguration & Binding (XOR-Bedingungen):
   • FunctionalClusterPersistencyAccess (ApmcEnumerationParamDef, 0..1): Zugriffskonfiguration für interne AUTOSAR Adaptive Functional Clusters (z. B. UCM, State Management).
     • Literale: READ, WRITE, READ_WRITE.
   • PortPrototypeInstanceRef (ApmcUriInstanceReferenceDef, 0..1): Bindung des Speichers an den Port-Prototyp einer Adaptive Application.
     • destinationType = PORT-PROTOTYPE
     • destinationContext = ROOT-SW-COMPONENT-PROTOTYPE SW-COMPONENT-PROTOTYPE
   • Bedingung (XOR 1): FunctionalClusterPersistencyAccess und PortPrototypeInstanceRef schließen sich gegenseitig aus (XOR). Ein Storage dient entweder exklusiv einem System-Cluster oder einer Applikations-SWC via Port.
   • Bedingung (XOR 2): Kopplung/Abhängigkeit zwischen PortPrototypeInstanceRef und ContractVersion.
4. Dateisystem, Sicherheit & Redundanz (Subcontainer):
   • UriCollection (ApmcParamConfContainerDef, 0..1):
     • Aggregiert Uri (ApmcStringParamDef, 0..*): Konkrete Pfad- bzw. Resource-Identifikatoren im zugrundeliegenden POSIX-Dateisystem.
   • PersistencyCryptoKeySlotProps (ApmcParamConfContainerDef, 0..1): Referenz auf Crypto KeySlots (ara::crypto) für transparente Verschlüsselung und Integritätsschutz.
   • PersistencyRedundancyHandlingCollection (ApmcParamConfContainerDef, 0..1): Konfiguration von Redundanzmechanismen (z. B. M-out-of-N-Kopien, CRC-Prüfsummen).

3. Dynamisches Verhalten & Sequenzablauf

Als statisches APMC-Metamodell modelliert das Diagramm Konfigurationsstrukturen; die Elemente steuern jedoch folgende deterministische Laufzeit- und Initialisierungssequenzen im ara::per-Stack:

1. Storage-Initialisierung (OpenKeyValueStorage / OpenFileStorage):
   • Auflösung des logischen Port-Bezeichners (InstanceSpecifier) zur Entwurfs-/Deployment-Zeit über PortPrototypeInstanceRef.
   • Bindung an den durch UriCollection::Uri adressierten POSIX-Speicherpfad.
   • Prüfung der Zugriffsrechte gemäß FunctionalClusterPersistencyAccess bzw. PortInterface-Rolle (Provided/Required Port).
2. Update- & Deploy-Sequenz (UCM-Interaktion):
   • Beim Start der Applikation vergleicht ara::per die im Manifest hinterlegte Version mit dem im Speicher abgelegten Revisions-Header.
   • Fall Version ungleich:
     • Wenn UpdateStrategy == DELETE: Atomares Löschen aller Keys/Dateien, Rücksetzen auf Initialzustand.
     • Wenn UpdateStrategy == KEEP_EXISTING: Öffnen des Speichers im vorgefundenen Zustand; Übergabe der Migrationsverantwortung an die Applikationslogik.
3. Runtime-Quota-Enforcement:
   • Jeder Schreib- bzw. Allokationsversuch (SetValue, Datei-Schreiboperationen) durchläuft eine Verifikationsstufe gegen MaximumAllowedSize.
   • Bei Überschreitung: Synchrone Rückgabe des Fehlers ara::per::PerErrc::kPhysicalStorageFailure / Quota-Exceeded ohne Datenkorrumpierung.
   • MinimumSustainedSize wird vom Plattform-Integrator bei der Partitionsdimensionierung statisch reserviert.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und Rollentrennung:
  • Entwickler müssen im Manifest zwingend festlegen, ob der Speicher für eine Standard-SWC bestimmt ist (PortPrototypeInstanceRef) oder für Infrastruktur-Cluster (FunctionalClusterPersistencyAccess). Eine gemischte Nutzung ist metamodellseitig über die XOR-Bedingung invalid.
• Speicher-Dimensionierung:
  • MinimumSustainedSize und MaximumAllowedSize sind als 64-Bit-Ganzzahlen (uint64_t) ausgelegt. Die Plattform-Integration muss sicherstellen, dass die durch MinimumSustainedSize geforderte Mindestkapazität auf dem Zielmedium (Flash/eMMC/NVMe) permanent garantiert ist (Schutz vor Speicherverdrängung).
• Risiko bei UpdateStrategy = DELETE:
  • Bei aktivierter DELETE-Strategie führt jedes Inkrement von Version beim Update über den Update and Configuration Management Cluster (UCM) zur vollständigen, irreversiblen Löschung der Persistent-Daten. Für applikationskritische Bestandsdaten (z. B. Kalibrierdaten, Fahrthistorie) ist zwingend KEEP_EXISTING zu wählen.
• Kryptographie und Integrität:
  • Bei Einsatz von PersistencyCryptoKeySlotProps muss sichergestellt sein, dass der referenzierte KeySlot im Crypto-Manifest korrekt deployed und der zugrundeliegende Crypto-Treiber vor der ersten Persistency-Initialisierung betriebsbereit ist.