DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_Persistency FIG-9c4eedaae28a5c54 638 × 542 px 1 Release(s)

Figure 5.1: Interfaces Provided by Persistency to Other Functional Clusters

SHA-256 Inhalts-Fingerabdruck: 9c4eedaae28a5c54d5a82fdfe2278c61fc88dc5e4c2376d9e19c0e23725ddd69
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

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.

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 R25-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 [4]. 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
R25-11 AUTOSAR_AP_SWS_Persistency S. 20 5.1 Figure 5.1: Interfaces Provided by Persistency to Other Functional Clusters