Figure 9.13: Overview of Persistency

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellenrealisierung (Interface Realization) und Nutzungsabhängigkeiten («use» Dependencies).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R20-11), Functional Cluster Persistency (ara::per) innerhalb der Adaptive Foundation (vgl. AUTOSAR_EXP_SWArchitecture, Kap. 9.4 / Fig. 9.13).
• Technischer Zweck: Darstellung der strukturellen Kapselung von persistentem Datenzugriff für Adaptive Applications (AA) gegenüber dem zugrunde liegenden Betriebssystem (POSIX OS) sowie der kryptografischen Absicherung über den Functional Cluster Cryptography (ara::crypto).

2. Komponenten, Entitäten & Schnittstellen

Komponenten (UML Components)

• Persistency (grün): Zentraler Functional Cluster (ara::per) der AUTOSAR Adaptive Platform.
• Cryptography (gelb): Plattform-interner Functional Cluster (ara::crypto) zur kryptografischen Absicherung (Integritätsschutz, Ver-/Entschlüsselung).
• Operating System (rosa/grau): Plattform-externes POSIX-Betriebssystem inklusive Dateisystem-, NVRAM- und Flash-Treibern.

Bereitgestellte Schnittstellen durch Persistency (Interface Realization)

Alle oberen Interfaces tragen den Stereotyp «applicationInterface» (standardisierte C++-API für Adaptive Applications):

• Key-Value Storage: Strukturierter Zugriff auf typisierte Schlüssel-Wert-Paare (ara::per::KeyValueStorage).
• File Storage: Unstrukturierter, dateibasierter Zugriff über Streams/Dateihandles (ara::per::FileStorage).
• Redundancy Handling:
  • + RegisterRecoveryReportCallback(): Registrierung eines Callbacks zur Benachrichtigung bei aufgetretenen und durch Redundanzmechanismen korrigierten Dateninkonsistenzen/Bitflips.
• Data Management:
  • + RegisterApplicationDataUpdateCallback(): Hook für die Applikation zur Migration/Aktualisierung anwendungsspezifischer Schemata bei Updates.
  • + ResetPersistency(): Zurücksetzen von Persistenz-Instanzen auf Werks-/Initialzustand.
  • + UpdatePersistency(): Triggerung des Migrations- und Update-Zyklus persistierter Datenstände nach Software-Aktualisierungen.

Genutzte Schnittstellen durch Persistency («use» Dependency)

• «applicationInterface» Crypto Stack: Konsumiert durch Persistency, realisiert durch den Functional Cluster Cryptography. Dient zur transparenten Authentisierung (HMAC/Signatur) und Verschlüsselung (AEAD) persistierter Datenblöcke.
• «externalInterface» Non-volatile Storage: Konsumiert durch Persistency, realisiert durch das Operating System. Abstrahiert physische Blockgeräte, NVRAM oder POSIX-Dateisystempfade.

3. Dynamisches Verhalten & Sequenzablauf

1. Laufzeit-Datenzugriff (CRUD-Pfad):
   • Eine Adaptive Application greift synchron oder asynchron via Key-Value Storage oder File Storage auf persistente Speicherbereiche zu.
   • Persistency leitet Schreiboperationen bei aktivierter Sicherheitskonfiguration zunächst an Crypto Stack weiter (Generierung von Hash/MAC, Chiffrierung) und schreibt das Ergebnis via Non-volatile Storage synchron/gepuffert ins POSIX-Dateisystem.
2. Redundanz- und Wiederherstellungs-Zyklus:
   • Beim Lesen verifiziert Persistency Prüfsummen/M-aus-N-Redundanzen (z. B. CRC, Replikation).
   • Schlägt die Validierung einer Datenkopie fehl, wird die redundante Kopie restauriert.
   • Asynchroner Trigger: Wurde ein Fehler korrigiert, feuert der über RegisterRecoveryReportCallback() registrierte Callback, um die Applikation oder das Diagnostics/State-Management über Degradation oder Silent Data Corruptions zu informieren.
3. Lifecycle- & Update-Sequenz (Persistency Update/Reset):
   • Ein Software-Update über den Update and Configuration Management (UCM)-Cluster initiiert UpdatePersistency().
   • Persistency prüft Versions-Tags des Persistency-Deployments. Stimmen Schemaversionen nicht überein, wird der via RegisterApplicationDataUpdateCallback() registrierte Callback der Applikation aufgerufen, um Nutzdaten deklarativ oder prozedural zu migrieren.
   • ResetPersistency() löscht Datenbereiche und stellt den Auslieferungszustand (Init-Files aus dem Manifest/Deployment) wieder her.

4. Normative Relevanz & Entwickler-Hinweise

• API-Kapselung: Applikationen dürfen zu keinem Zeitpunkt direkte POSIX-File-IO-Aufrufe (open, read, write) auf persistierte Anwendungsdaten durchführen. Der Zugriff muss strikt über ara::per::OpenKeyValueStorage() bzw. ara::per::OpenFileStorage() erfolgen, da sonst Redundanz- und Verschlüsselungslayer umgangen und Daten korrumpiert werden.
• Manifest-Modellierung (AUTOSAR ARXML):
  • Entwickler müssen PersistencyPortPrototype, PersistencyKeyValueDatabase und PersistencyFileProxyInterface im Execution- und Service-Instance-Manifest modellieren.
  • Redundanzalgorithmen (CRC32, M-out-of-N) und Verschlüsselungsanforderungen (CryptoKeySlots via CryptoProvider) werden deklarativ im Manifest verknüpft und zur Laufzeit durch Persistency instanziiert.
• Callback-Restriktionen:
  • Der ApplicationDataUpdateCallback muss zwingend idempotent und deterministisch ausgelegt sein; schlägt die Datenmigration fehl, scheitert der Update-Prozess der Partition/Executable im State Management.
  • Im RecoveryReportCallback dürfen keine blockierenden Aufrufe oder Schreibzugriffe auf dieselbe Persistency-Instanz ausgeführt werden (Deadlock-Gefahr im Stack).