Figure 10.8: Persistency Redundancy Handling Configuration

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Metamodell-Klassendiagramm / Konfigurationsmodell nach dem AUTOSAR Adaptive Platform Module Configuration (APMC) Parameter Definition Metamodell (Apmc*Def).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_Persistency), Release R25-11. Das Diagramm definiert die formale Konfigurationsstruktur (ARXML-Schema) zur Absicherung persistierter Daten (KeyValueStorage und FileStorage) gegen Datenverlust und Bit-Corruption mittels Redundanzmechanismen (M-aus-N-Replikation) und Prüfsummen (CRC / Hash).

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Elemente & Hierarchie (Top-Down):

• PersistencyCommon (ApmcParamConfContainerDef, [1..1]): Wurzel- bzw. Eltern-Container für gemeinsame Persistenzkonfigurationen.
  • Aggregiert über Rolle +container: PersistencyRedundancyHandlingCollection (ApmcParamConfContainerDef, [0..1]).
• PersistencyRedundancyHandlingCollection:
  • Aggregiert über Rolle +container: PersistencyRedundancyHandling (ApmcParamConfContainerDef, [0..*]). Erlaubt die Definition mehrerer unabhängiger Redundanzrichtlinien.
• PersistencyRedundancyHandling:
  • PersistencyRedundancyHandlingScope (ApmcEnumerationParamDef, [0..1]): Bestimmt die Granularität der Absicherung.
    • Literale (ApmcEnumerationLiteralDef, via +literal):
      • SCOPE_ELEMENT: Absicherung auf Einzelelement-Ebene (z. B. einzelner Key-Value-Eintrag oder einzelne Datei).
      • SCOPE_STORAGE: Globale Absicherung des gesamten Speichers (z. B. gesamter Datenbank-/Storage-Block).
  • Aggregiert über Rolle +container: PersistencyRedundancyHandlingChoice (ApmcChoiceContainerDef, [0..1]). Exklusives Auswahlkonstrukt zwischen zwei Strategien via +choice:
    1. PersistencyRedundancyMOutOfN (ApmcParamConfContainerDef, [0..1]): Fehlertolerante Mehrheits- oder Spiegelungsreplikation (M aus N).
       • RedundancyM (ApmcIntegerParamDef, [1..1], min = 1): Minimale Anzahl intakter Replikate, die für einen gültigen Lesezugriff erforderlich sind.
       • RedundancyN (ApmcIntegerParamDef, [1..1], min = 2): Gesamtzahl der gespeicherten physischen Kopien (N > M).
    2. PersistencyRedundancyChecksum (ApmcParamConfContainerDef, [0..1]): Integritätsprüfung via Prüfsumme.
       • RedundancyChecksumLength (ApmcIntegerParamDef, [0..1], min = 0): Länge der Prüfsumme in Bits/Bytes.
       • RedundancyChecksumAlgorithmFamily (ApmcStringParamDef, [0..1]): Bezeichner der Algorithmenfamilie (z. B. "CRC", "SHA2").
       • Aggregiert über Rolle +container: PersistencyRedundancyChecksumChoice (ApmcChoiceContainerDef, [0..1]):
         • PersistencyRedundancyCrc (ApmcParamConfContainerDef, [0..1]): Standardisierte zyklische Redundanzprüfung (Hardware-/Software-CRC).
         • PersistencyRedundancyHash (ApmcParamConfContainerDef, [0..*]): Kryptografische oder nicht-kryptografische Hashfunktionen.
           • Aggregiert via +element: InitializationVectorLength (ApmcIntegerParamDef, [0..1], min = 0): Bit-/Byte-Länge des Initialisierungsvektors (IV/Salt) bei hashbasierten Integritätsprüfungen.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Als rein statisches Parameterdefinitionsschema enthält das Diagramm keine Laufzeitsequenzen; das abgeleitete Laufzeitverhalten des Persistenz-Stacks gestaltet sich wie folgt:

• Schreibpfad (Persistierung):
  1. Applikationsaufruf (SetValue(), WriteFile()).
  2. Prüfung der konfigurierten Policy (SCOPE_ELEMENT vs. SCOPE_STORAGE).
  3. Bei Checksum-Choice: Berechnung von CRC oder Hash (ggf. unter Einbeziehung des Initialisierungsvektors mit Länge InitializationVectorLength) und Anhängen/Mitführen der Signatur/Prüfsumme.
  4. Bei M-aus-N-Choice: Paralleles/sequenzielles Schreiben auf N disjunkte physische Speicherbereiche/Sektoren.
• Lesepfad (Wiederherstellung & Integritätsprüfung):
  1. Applikationsaufruf (GetValue(), ReadFile()).
  2. Bei Checksum: Neuberechnung und Vergleich; bei Diskrepanz Rückgabe eines Integritätsfehlers (PersistencyErrc::kIntegrityCorrupted).
  3. Bei M-aus-N: Auslesen aller N Replikate und Voting. Wenn mindestens M Kopien konsistent übereinstimmen, erfolgt die Rückgabe der Nutzdaten; andernfalls Fehlerabbruch oder automatischer Recovery-Versuch (Self-Healing der korrumpierten Replikate).

4. Normative Relevanz & Entwickler-Hinweise

• Speicher-Overhead & Flash-Wear:
  • Die Festlegung von RedundancyN multipliziert den Flash-/NVM-Speicherverbrauch exakt um den Faktor N. Bei N=2 (Mirroring) oder N=3 (Triple Modular Redundancy) ist die Sektorlebensdauer (Endurance) des Flash-Treibers entsprechend zu dimensionieren.
• Laufzeit- und CPU-Budget:
  • Hashverfahren (PersistencyRedundancyHash) erzeugen signifikanten CPU-Jitter und Durchsatzverlust gegenüber tabellenbasierten oder hardwarebeschleunigten CRCs (PersistencyRedundancyCrc). Für Echtzeit-relevante Storage-Keys ist CRC oder reine M-aus-N-Redundanz zu bevorzugen.
• Scope-Auswahl (SCOPE_ELEMENT vs. SCOPE_STORAGE):
  • SCOPE_STORAGE schützt gegen inkonsistente Gesamtzustände des Storage-Containers, erzwingt jedoch bei jedem Schreibzugriff eine vollständige Neuberechnung des Containers.
  • SCOPE_ELEMENT erlaubt granulare Absicherung einzelner Keys/Dateien mit feinerer Fehlereingrenzung, führt jedoch zu Metadaten-Overhead je Record.
• Konfigurationsvalidierung (ARXML):
  • Validatoren müssen zwingend prüfen: N > M ≥ 1. Ein Konfigurationszustand mit M ≥ N widerspricht der M-aus-N-Fehlertoleranzsemantik.