DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Persistency FIG-82cb45f8e0c16cc0 638 × 542 px 1 Release(s)

Figure 5.1: Interfaces Provided by Persistency to Other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: 82cb45f8e0c16cc006b209e0a638a69b8626281c644bdae456ee58edc5daa115
✦ 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

UML-Klassendiagramm und Komponentendiagramm der AUTOSAR Adaptive Platform (Releases R24-11 und R25-11, AUTOSAR_AP_SWS_Persistency). Das Diagramm stellt die Bereitstellung des schlüsselwertbasierten Persistenzdienstes (KeyValueStorage) durch den Functional Cluster Persistency für eine erweiterte Gruppe daemon-basierter Plattform-Funktionscluster dar. Es spezifiziert die statische Architektur zur standardisierten Speicherung strukturierter Konfigurations-, Diagnose- und Zustandsdaten über funktionale Ports.

2. Komponenten, Entitäten & Schnittstellen

Zentrale Entität ist die Schnittstelle «aapAPI,aapPortInterface» KeyValueStorage (ohne Namensraum-Präfix). Sie deklariert elf Operationen:

  • DiscardPendingChanges()
  • GetAllKeys()
  • GetCurrentValueSize()
  • GetValue()
  • KeyExists()
  • RecoverKey()
  • RemoveAllKeys()
  • RemoveKey()
  • ResetKey()
  • SetValue()
  • SyncToStorage()

Der bereitstellende Funktionscluster ist «aapFunctionalCluster» Persistency (Realisierungsbeziehung). Fünf daemon-basierte funktionale Cluster nutzen die Schnittstelle über gerichtete Abhängigkeiten mit «use» und «aapRequiredPort»:

  1. «aapFunctionalCluster» Diagnostic Management,
  2. «aapFunctionalCluster» State Management,
  3. «aapFunctionalCluster» Vehicle Update and Configuration Management,
  4. «aapFunctionalCluster» Time Synchronization,
  5. «aapFunctionalCluster» Update and Configuration Management.

3. Dynamisches Verhalten & Sequenzablauf

Statisches Architekturdiagramm ohne dynamische Interaktionspfade. Das Zusammenspiel der Operationen bildet einen transaktional gepufferten Schlüssel-Wert-Zugriff ab: Konsumenten prüfen Schlüssel mit KeyExists(), listen Schlüssel über GetAllKeys() auf, fragen Wertegrößen über GetCurrentValueSize() ab und lesen bzw. schreiben Daten mittels GetValue() und SetValue(). Änderungen werden durch SyncToStorage() persistent und konsistent auf das Speichermedium geschrieben oder mittels DiscardPendingChanges() verworfen. Löschoperationen erfolgen einzeln (RemoveKey()) oder global (RemoveAllKeys()). Bei Datenkorruption oder Reset-Szenarien bieten RecoverKey() und ResetKey() Mechanismen zur Rekonstruktion bzw. Wiederherstellung von Initialwerten.

4. Normative Relevanz & Entwickler-Hinweise

Normativ bindende Spezifikation des KeyValueStorage als universeller Konfigurations- und Statusspeicher für die Basisinfrastruktur der Adaptive Platform. Gegenüber reinen Dateischnittstellen integriert KeyValueStorage State Management (persistente Betriebs- und Fehlermodi), Time Synchronization (persistente Synchronisations- und Driftparameter) sowie Vehicle Update and Configuration Management (flottenweite Update-Stati). Entwickler müssen das zweistufige Schreibmodell (SetValue() gefolgt von explizitem SyncToStorage() oder Rollback über DiscardPendingChanges()) zwingend berücksichtigen, um Atomizität und Konsistenz bei Spannungsausfällen sicherzustellen.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«aapFunctionalCluster» | Persistency | «aapFunctionalCluster» | Time Synchronization | daemon-based | «aapFunctionalCluster» Diagnostic Management | daemon-based | «aapFunctionalCluster» | State Management | daemon-based | «aapAPI,aapPortInterface» | KeyValueStorage | + DiscardPendingChanges() + GetAllKeys() + GetCurrentValueSize() + GetValue() + KeyExists() + RecoverKey() + RemoveAllKeys() + RemoveKey() + ResetKey() + SetValue() + SyncToStorage() | «aapFunctionalCluster» Update and Configuration | Management | daemon-based | «aapFunctionalCluster» | Vehicle Update and Configuration Management | daemon-based | «use» «aapRequiredPort» | «use» «aapRequiredPort» | «use» «aapRequiredPort» «use» «aapRequiredPort» | «use» «aapRequiredPort»

Begleitender Spezifikationstext:

Specification of Persistency AUTOSAR AP R24-11 5 Dependencies to Other Functional Clusters This chapter defines the dependencies of this functional cluster to other functional clusters. AUTOSAR decided not to standardize interfaces which are exclusively used between functional clusters to allow efficient implementations which might depend e.g., on the used operating system. The goal of this chapter is to provide an informative guideline for the interactions between functional clusters without specifying syntactical details. This ensures compatibility between documents specifying different functional clusters and supports parallel implementation of different functional clusters. Details of internal interfaces are up to the platform provider. Additional internal interfaces, parameters, and return values can be added. A detailed technical architecture documentation of the overall AUTOSAR Adaptive Platform is provided in [3]. 5.1 Provided Interfaces This section provides an overview of the public interfaces provided by this functional cluster towards other functional clusters. «aapFunctionalCluster» Persistency «aapFunctionalCluster» Time Synchronization daemon-based «aapFunctionalCluster» Diagnostic Management daemon-based «aapFunctionalCluster» State Management daemon-based «aapAPI,aapPortInterface» KeyValueStorage + DiscardPendingChanges() + GetAllKeys() + GetCurrentValueSize() + GetValue() + KeyExists() + RecoverKey() + RemoveAllKeys() + RemoveKey() + ResetKey() + SetValue()

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_Persistency S. 17 5.1 Figure 5.1: Interfaces Provided by Persistency to Other Functional Clusters