Figure 5.1: Interfaces Provided by Persistency to Other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Metamodell-Projektion).
• Technischer Zweck: Spezifikation der durch das Functional Cluster Persistency (ara::per) bereitgestellten Key-Value-Storage-Schnittstelle gegenüber Plattform-Daemons im Rahmen der Software-Architektur nach AUTOSAR AP R23-11.
• Architektur-Einordnung: Persistency stellt grundlegende NV-Datenspeicherung für zentrale Plattformdienste bereit, um zustandsbehaftete Betriebsdaten, Diagnosezustände, Zeitstempel/Offset-Parameter und Update-Metadaten prozessübergreifend und manipulationssicher über System-Resets hinweg zu sichern.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten (Functional Clusters)

• Bereitstellendes Cluster:
  • Persistency («aapFunctionalCluster»): Realisiert das Persistenz-Subsystem (Bibliotheks-basiert in den Adressräumen der Clients oder als vermittelnde Plattforminstanz).
• Konsumierende Cluster (alle als daemon-based klassifiziert, eigenständige OS-Prozesse):
  • Diagnostic Management («aapFunctionalCluster»): Speichert DTCs, Freeze Frames, Fault Records und Snapshot-Daten.
  • Time Synchronization («aapFunctionalCluster»): Speichert Drift-Parameter, historische Zeitstempel und Synchronisations-Offsets.
  • State Management («aapFunctionalCluster»): Speichert zuletzt aktive Function-Group-Zustände, Safe-State-Flags und Wiederanlauf-Konfigurationen.
  • Update and Configuration Management («aapFunctionalCluster»): Hält Rollback-Zustände, Kampagnen-Metadaten, Software-Cluster-Versionen und Paketstatus.

Schnittstelle & Stereotypen

• Persistency::KeyValueStorage («aapAPI,aapPortInterface»):
  • Formales Port-Interface sowie typisierte C++-Klassenabstraktion (ara::per::KeyValueStorage).
• Operationen:
  • DiscardPendingChanges(): Verwirft alle Modifikationen im Transaktions-/RAM-Puffer seit dem letzten Synchronisationspunkt.
  • GetAllKeys(): Abfrage aller im konfigurierten Namespace/Container registrierten Schlüssel.
  • GetValue(): Typsicherer Lesezugriff auf einen spezifischen Schlüssel.
  • KeyExists(): Vorabprüfung auf Existenz eines Schlüssels ohne Payload-Deserialisierung.
  • RecoverKey(): Manuelle Wiederherstellung eines korrupten Eintrags aus Redundanz-/Backup-Speichern.
  • RemoveAllKeys(): Löschen des gesamten Inhalts der Datenbank-Instanz.
  • RemoveKey(): Atomares Entfernen eines dedizierten Schlüssels.
  • ResetKey(): Rücksetzen eines Werts auf die im Manifest/Init-Image definierten Werks-/Defaultwerte.
  • SetValue(): Typisiertes Schreiben eines Werts in den Cache/Staging-Bereich.
  • SyncToStorage(): Erzwingt den synchronen/persistierten Flush des In-Memory-Status auf das nichtflüchtige Speichermedium (z. B. eMMC, UFS, NOR-Flash via OS-Dateisystem).

Beziehungen

• Interface-Realisierung: Persistency realisiert Persistency::KeyValueStorage (gestrichelte Linie mit geschlossener Dreiecksspitze).
• Nutzungsabhängigkeit: Die Daemons greifen über «aapRequiredPort» via «use»-Abhängigkeit auf das Interface zu.

3. Dynamisches Verhalten & Sequenzablauf

• Zugriffsparadigma (Staging & Commit):
  • Modifizierende Operationen (SetValue(), RemoveKey(), RemoveAllKeys()) arbeiten primär auf einem Prozess-lokalen Cache oder Staging-Puffer.
  • Änderungen sind bis zum Aufruf von SyncToStorage() nicht zwingend spannungsausfallsicher (kein automationsfreier Flush).
  • Bei Fehlern vor dem Persistieren dient DiscardPendingChanges() als Rollback-Mechanismus.
• Synchronisation & Blockierverhalten:
  • SyncToStorage() ist eine blockierende, I/O-intensive Operation, die synchrone Dateisystem-Barrieren (fsync() / fdatasync()) auslöst.
• Integritäts- und Redundanzpfad:
  • Schlägt GetValue() aufgrund von Prüfsummen- oder CRC-Fehlern fehl (Rückgabe von PerErrc::kIntegrityCorrupted), initiiert der jeweilige Daemon über RecoverKey() die Wiederherstellung oder über ResetKey() das Revertieren auf den Initialzustand.

4. Normative Relevanz & Entwickler-Hinweise

• Port-Konfiguration im Execution/Instance-Manifest:
  • Jeder konsumierende Daemon erfordert im ARXML-Manifest einen dedizierten RPortPrototype typisiert über das PersistencyKeyValueDatabaseInterface.
  • Das Deployment erfordert ein explizites Binding (PersistencyPortPrototypeToKeyValueDatabaseMapping) an eine physische PersistencyKeyValueDatabase.
• Prozess-Isolation & Concurrency:
  • Da alle vier Konsumenten als separate Daemons (daemon-based) laufen, muss die ara::per-Implementierung Dateisystem-Locks (Multi-Process Access Serialization) sicherstellen oder der Zugriff auf unterschiedliche, isolierte Storage-Pfade/Dateien partitioniert sein.
• Fehlerbehandlung (ara::core::Result):
  • Sämtliche Operationen liefern Fehlertypen nach ara::per::PerErrc zurück (z. B. kKeyNotFound, kPhysicalStorageFailure, kStorageConfigurationExhausted). Daemons dürfen keine unbehandelten Exceptions werfen und müssen I/O-Fehler defensiv auffangen.
• Einschränkungen für Plattform-Entwickler:
  • Während Time Synchronization und State Management harte Echtzeitanforderungen haben, darf SyncToStorage() niemals im zyklischen Echtzeit-Thread aufgerufen werden; Persistierungsoperationen müssen asynchron oder in dedizierten Hintergrund-Worker-Threads ausgeführt werden.