AUTOSAR_AP_SWS_Persistency FIG-f040c892db68f6ac 669 × 587 px 3 Release(s)

Figure 7.1: Typical usage of Persistency within an Adaptive Application

SHA-256 Inhalts-Fingerabdruck: f040c892db68f6ac77399074abee68e3197ee31662eccd7cc891df9bf0ec690f

✦ 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)

R20-11 → R21-11 redaktionell Vorgänger: FIG-08c78db8ef539276

UML-2-Komponentenmodellierung: Überführung der informellen Blockgrafik in ein UML-2-Komponentendiagramm mit standardisierten Komponentensymbolen in den oberen rechten Ecken aller Rahmen.
Stereotyp «process»: Der Rahmen „Adaptive Application“ wurde mit dem Stereotyp «process» annotiert.
Stereotyp «subsystem,entity»: Der Rahmen „Persistency“ wurde mit dem Stereotyp «subsystem,entity» versehen.
Stereotyp «entity»: Alle Storage-Blöcke („Key-Value Storage A/B“, „File Storage C/D“) wurden mit dem Stereotyp «entity» klassifiziert.
Attributnotation & Sichtbarkeit: Schlüssel-Wert-Paare und Dateieinträge wurden als UML-Attribute mit vorangestelltem Sichtbarkeitsindikator + (public) formatiert (z. B. + Key_A1 = Value_A1, + File_C1).
Abschluss der Auflistungen: Die informellen Auslassungszeichen ... innerhalb der Attributlisten wurden durch n-te Elemente ersetzt (+ Key_An = Value_An, + File_Cn etc.); die vertikalen Auslassungspunkte zwischen den Komponentenblöcken wurden entfernt.

R23-11 → R24-11 keine inhaltliche Änderung Nachfolger: FIG-6ae974a265f9870e

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Begleitender Spezifikationstext:

Specification of Persistency AUTOSAR AP R23-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 application. The library part of these Functional Clusters will use dedicated deployment information of Persistency, while Daemons of Functional Clusters can be modeled similarly to Adaptive Applications. 7.1.1 Persistency in the Manifest The Persistency usage of an Adaptive Application is modeled in the Execution

Vorkommen in AUTOSAR-Releases (4)

Release	Dokument	Seite	Nr.	Bildunterschrift im Dokument
R21-11	AUTOSAR_SWS_Persistency	S. 25	7.1	Figure 7.1: Typical usage of Persistency within an Adaptive Application
R21-11	AUTOSAR_SWS_Persistency	S. 25	7.1	Figure 7.1: Typical usage of Persistency within an Adaptive Application
R22-11	AUTOSAR_SWS_Persistency	S. 28	7.1	Figure 7.1: Typical usage of Persistency within an Adaptive Application
R23-11	AUTOSAR_AP_SWS_Persistency	S. 32	7.1	Figure 7.1: Typical usage of Persistency within an Adaptive Application