DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Persistency FIG-f14d6d93fe3a5938 669 × 586 px 1 Release(s)

Figure 7.1: Typical usage of Persistency within an Adaptive Application

SHA-256 Inhalts-Fingerabdruck: f14d6d93fe3a59385352f7d3570603f5ba59a5026644fd392ca0877607e7f7bd

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: UML-Komponentendiagramm (formales Architektur- und Kapselungsmodell der AUTOSAR Adaptive Platform).
  • Technischer Zweck & Einordnung: Illustration der Speicherabstraktion innerhalb des Functional Clusters Persistency (ara::per) für eine Adaptive Application (AdaptiveApplicationSwComponentType). Es visualisiert die Kapselung der beiden komplementären Persistenzmechanismen – schlüsselbasierter strukturierter Datenzugriff (Key-Value Storage) und dateibasierter Bytestream-Zugriff (File Storage) – unter formaler UML-Stereotypisierung von Prozess- und Entitätsgrenzen.

2. Komponenten, Entitäten & Schnittstellen

  • Adaptive Application («process»): Der ausführende Anwendungsprozess im Userspace des POSIX-Betriebssystems, der die Persistenzinstanzen umschließt und ausführt.
  • Persistency («subsystem,entity»): Das funktionale Persistenz-Cluster, das als anwendungslokales Subsystem realisiert ist und die Low-Level-Interaktion mit dem Dateisystem kapselt.
  • Key-Value Storage A & B («entity»):
    • Diskrete Schlüssel-Wert-Datenbanken (ara::per::KeyValueStorage), modelliert als Entitäts-Komponenten.
    • Zugriff über PortPrototype, typisiert durch ein PersistencyKeyValueDatabaseInterface.
    • Verwalten typisierte Schlüssel-Wert-Paare mit expliziter Public-Sichtbarkeit (+ Key_A1 = Value_A1, + Key_A2 = Value_A2 bis + Key_An = Value_An bzw. entsprechend für Storage B).
    • Kardinalität: Mehrere Key-Value-Datenbanken pro Softwarekomponente (1 … n); jede Datenbank verwaltet 0 … m Schlüssel-Wert-Paare.
  • File Storage C & D («entity»):
    • Isolierte Dateispeicher-Container (ara::per::FileStorage), modelliert als Entitäts-Komponenten.
    • Zugriff über PortPrototype, typisiert durch ein PersistencyFileStorageInterface.
    • Verwalten raw Byte-Streams bzw. diskrete Dateien mit Public-Sichtbarkeit (+ File_C1, + File_C2 bis + File_Cn bzw. entsprechend für Storage D).
    • Kardinalität: Mehrere File Storages pro Softwarekomponente (1 … n); jeder Speicher kapselt 0 … k Dateien.

3. Dynamisches Verhalten & Sequenzablauf

  • Initialisierung & Pre-Deployment:
    • Vordefinierte Key-Value-Paare und Init-Dateien werden während der Installations- bzw. Updatephase durch das Update and Configuration Management (UCM) auf Basis des Deployments und Manifests auf dem persistenten Speicher bereitgestellt.
  • Laufzeit-Zugriff (CRUD-Operationen):
    • Key-Value Storage: Synchrone/asynchrone API-Calls (GetValue, SetValue, SyncToStorage). Modifikationen im RAM-Cache werden synchron oder verzögert über SyncToStorage() redundant und transaktionssicher (Crash-Konsistenz) auf den persistenten Speicher geflusht.
    • File Storage: Öffnen und Modifizieren via Stream-Operatoren (OpenFileReadStream, OpenFileWriteStream). Sperren/Locks auf File-Ebene verhindern nebenläufige Konflikte innerhalb desselben Prozesses.
  • Fehler- und Abbruchverhalten:
    • Fehler (z. B. I/O-Fehler, Quota-Überschreitung, Korruption) werden über ara::core::Result<T> mit spezifischen PerErrc-Fehlercodes zurückgegeben.
    • Bei Datenkorruption greifen persistenzspezifische Integritätsprüfungen (CRC/Redundanz gemäß Redundancy Handling).

4. Normative Relevanz & Entwickler-Hinweise

  • Architektur- und Spezifikationsbezug: Das Diagramm veranschaulicht die funktionale Kapselung persistenter Datenzugriffe auf Anwendungsebene. Es besitzt informativen Charakter und definiert die logische Koexistenz von KeyValueStorage und FileStorage innerhalb eines Prozesses.
  • Port- und Manifest-Modellierung: Entwickler müssen jede Key-Value-Datenbank und jedes File-Storage im Software-Component-Description-Manifest über separate PortPrototype-Elemente mit PersistencyKeyValueDatabaseInterface bzw. PersistencyFileStorageInterface deklarieren.
  • Ressourcenallokation & Isolation: Persistente Speicherbereiche sind pro Instanz streng isoliert; Zugriffe erfordern die Konfiguration entsprechender Speicher- und Quota-Limits im Deployment-Manifest.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-6ae974a265f9870e

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«process» Adaptive Application | «subsystem,entity» | Persistency | «entity» Key-Value Storage A | + Key_A1 = Value_A1 + Key_A2 = Value_A2 + Key_An = Value_An | «entity» Key-Value Storage B | + Key_B1 = Value_B1 + Key_B2 = Value_B2 + Key_Bn = Value_Bn | «entity» File Storage D | + File_D1 + File_D2 + File_Dn | «entity» File Storage C | + File_C1 + File_C2 + File_Cn

Begleitender Spezifikationstext:

Specification of Persistency AUTOSAR AP R25-11 7 Functional Specification 7.1 The Architecture of Persistency The Persistency offers two different mechanisms to access persistent memory: Key-Value Storages offer access to a set of keys with associated values (similar to a database), while File Storages offer access to a set of files (similar to a directory of a file system). The typical usage of the Persistency within an Adaptive Application is depicted in Figure 7.1. As shown there, an Adaptive Application can use a combination of multiple Key-Value Storages and multiple File Storages. Of course, the same applies to other Functional Clusters using Persistency. «process» Adaptive Application «subsystem,entity» Persistency «entity» Key-Value Storage A + Key_A1 = Value_A1 + Key_A2 = Value_A2 + Key_An = Value_An «entity» Key-Value Storage B + Key_B1 = Value_B1 + Key_B2 = Value_B2 + Key_Bn = Value_Bn «entity» File Storage D + File_D1 + File_D2 + File_Dn «entity» File Storage C + File_C1 + File_C2 + File_Cn Figure 7.1: Typical usage of Persistency within an Adaptive Application Persistency can also be used directly by other Functional Clusters without involvement of the Adaptive Application. The library part of these Functional Clusters will use dedicated Target Configuration information of Persistency, while Daemons of Functional Clusters can be modeled similarly to Adaptive Applications. 7.1.1 Configuration of Persistency The usage of Persistency by an Adaptive Application is mo

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_AP_SWS_Persistency S. 35 7.1 Figure 7.1: Typical usage of Persistency within an Adaptive Application