Figure 10.4: Persistency Key Value Storage Configuration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Metamodell-Ausschnitt der Parameter-Konfiguration (AUTOSAR Adaptive Platform Parameter Configuration Metamodel, APMC) als UML-Klassendiagramm.
• Technischer Zweck: Formale Definition des Konfigurationsschemas für Key-Value-Storage-Instanzen (KVS) innerhalb des Funktionsclusters Persistency (ara::per).
• Architektur-Einordnung: Brückenelement zwischen SWC-Design (PersistencyDataRequiredComSpec) und der physischen Maschinen- bzw. Deployment-Konfiguration. Es definiert die Speicherabbildung, Datentypen, kryptografische Schlüsselslots, Initialwerte und Lifecycle-Update-Strategien auf Maschinenebene.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Container-Hierarchie (APMC)

• Persistency (ApmcFunctionalClusterDef) [0..*]: Wurzelcontainer für die Konfiguration des funktionalen Clusters Persistency.
• PersistencyKeyValueStorageCollection (ApmcParamConfContainerDef) [0..1]: Bündelt alle KVS-Instanzen einer Deployment-Einheit.
• PersistencyKeyValueStorage (ApmcParamConfContainerDef) [0..*]: Repräsentiert einen logischen Key-Value-Speicher.
• PersistencyCommon (ApmcParamConfContainerDef) [1..1]: Spezifiziert übergeordnete Storage-Eigenschaften (z. B. Redundanz, Synchronisationsverhalten, Backing-Store-Pfade).
• PersistencyKeyValuePairCollection (ApmcParamConfContainerDef) [0..1]: Gruppiert die persistenten Schlüssel-Wert-Paare eines Speichers.
• PersistencyKeyValuePair (ApmcParamConfContainerDef) [0..*]: Konfiguration eines atomaren Schlüssel-Wert-Eintrags.

Kindelemente & Parameter von PersistencyKeyValuePair

• PersistencyCryptoKeySlotProps (ApmcParamConfContainerDef) [0..1]: Optionale Bindung an ara::crypto zur hardware-/softwarebasierten Authentifizierung oder Verschlüsselung des Eintrags.
• InitValueRef (ApmcForeignReferenceDef) [1..1]: Referenziert ein ARElement vom Typ ConstantSpecification. Definiert den Default-Wert bei Erstinbetriebnahme oder Reset.
• ValueDataTypeRef (ApmcForeignReferenceDef) [1..1]: Referenziert den Datentyp im Software-Design (AbstractImplementationDataType, annotiert mit «AtpBlueprint», «AtpBlueprintable», AutosarDataType).
• ElementUpdateStrategy (ApmcEnumerationParamDef) [1..1]: Bestimmt das Verhalten während eines Software-Updates. Aggregiert drei Literale (ApmcEnumerationLiteralDef):
  • KEEP_EXISTING: Bestehender Wert im NVM bleibt erhalten; Initialwert wird ignoriert.
  • DELETE: Schlüssel und Wert werden beim Update aus dem Speicher entfernt.
  • OVERWRITE: Persistierter Wert wird zwingend durch den Wert aus InitValueRef überschrieben.

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Konfigurationsmetamodell besitzt das Diagramm keinen direkten Laufzeit-Callstack, steuert aber zwei deterministische Abläufe:

1. Konfigurations- und Generierungszeitpunkt (Design-to-Machine Binding):
   • Der Zielwert der InitValueRef kann ursprünglich aus PersistencyDataRequiredComSpec.initValue abgeleitet werden.
   • Durch die Entkopplung als eigenständige ConstantSpecification in der Machine Configuration kann der Initialwert maschinenspezifisch überschrieben werden, ohne das Software-Component-Design zu modifizieren.
2. Lifecycle- & Update-Verhalten (UCM / Start-up Phase):
   • Boot/Erststart: Fehlt der Key im persistenten Storage, alloziiert die Persistency-Laufzeit den Key und persistiert den Inhalt von InitValueRef gemäß ValueDataTypeRef.
   • SW-Paket-Update (UCM): Der Update-Manager bzw. die Persistency-Initialisierungsroutine evaluiert ElementUpdateStrategy:
     • Bei OVERWRITE erfolgt ein Write-Through mit dem neuen ConstantSpecification-Wert.
     • Bei DELETE wird der Record aus der Key-Tabelle bereinigt.
     • Bei KEEP_EXISTING erfolgt keine Mutation des NVM-Zustands.

4. Normative Relevanz & Entwickler-Hinweise

• API-Typkonsistenz (ara::per):
  • ValueDataTypeRef bindet die Konfiguration strikt an den C++-Typ (AbstractImplementationDataType).
  • Applikativer Zugriff über kvs.GetValue<T>(key) bzw. kvs.SetValue<T>(key, value) erfordert exakte Typrübereinstimmung mit ValueDataTypeRef, andernfalls resultiert dies in Laufzeitfehlern (z. B. ara::per::PerErrc::kDataTypeMismatch bzw. Deserialisierungsabbruch).
• Entkopplung Machine- vs. Design-Ebene:
  • Der Hinweisblock dokumentiert normativ, dass InitValueRef nicht direkt auf das Component-Design verweisen muss. Kalibrier- oder länderspezifische Defaults können auf Integratorebene via Machine Configuration angepasst werden.
• Risiko von Datenverlust bei SW-Updates:
  • Die fehlerhafte Parametrierung von ElementUpdateStrategy (z. B. OVERWRITE statt KEEP_EXISTING für persistente Benutzerdaten oder Lernwerte) führt zur irreversiblen Überschreibung von Felddaten beim Over-the-Air-Update (OTA).
• Kryptografische Absicherung:
  • Fehlt PersistencyCryptoKeySlotProps (upperMultiplicity = 1, optional), wird das Schlüssel-Wert-Paar im Klartext ohne Signatur/Verschlüsselung abgelegt. Für sicherheitskritische Daten (z. B. Diagnosesperren, Zertifikate) muss der Slot zwingend konfiguriert werden.