Figure 11.15: Scenario: Read Persistent Data with Unique ID

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt und ref).
• Technischer Zweck & Einordnung: Spezifikation des standardisierten Leseablaufs für persistente Schlüssel-Wert-Daten (Key-Value Storage, KVS) in der AUTOSAR Adaptive Platform (AP, Release R23-11). Das Szenario zeigt das Zusammenwirken zwischen der Anwendungsschicht (ara::per), dem Betriebssystem (POSIX-Dateisystem/Storage) sowie den optionalen Manifest-gesteuerten Mechanismen zur Fehlererkennung/-korrektur (Redundanz) und transparenten Entschlüsselung via ara::crypto.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • :Adaptive Application (Akteur/Prozess): Aufrufende funktionale Instanz im User-Space der Adaptive Platform.
  • «aapFunctionalCluster» :Persistency (Funktionaler Cluster): Implementierung der ara::per-Spezifikation, fungiert als Vermittler, Cache- und Speicher-Manager.
  • :Operating System (Akteur/Infrastruktur): Unterlagerte POSIX-kompatible Betriebssystem-Schnittstelle (Dateisystem-/Blocktreiber-Ebene).
  • «aapFunctionalCluster» :Cryptography (Funktionaler Cluster): Kryptografiesubsystem (ara::crypto) zur sicheren Schlüsselverwaltung und symmetrischen Block-/Stream-Entschlüsselung.
• Stereotypen:
  • «aapFunctionalCluster»: Kennzeichnet standardisierte funktionale Cluster der AUTOSAR Adaptive Platform.
  • «aapInformative»: Kennzeichnet Interaktionen bzw. Methodenaufrufe explizit als informativ und nicht-normativ.
• Schnittstellen & Interaktionspunkte:
  • OpenKeyValueStorage(): KeyValueStorage: Statische Factory-Methode der C++-API (ara::per::OpenKeyValueStorage) zur Instanziierung/Bindung eines Storage-Handles basierend auf dem Applikations-Manifest.
  • GetValue(key): Typsichere Abfragemethode am KeyValueStorage-Objekt zum Auslesen des Werts für einen eindeutigen Identifier (key).
  • OS-Systemaufrufe: «aapInformative» open() zum Öffnen des korrespondierenden Storage-Deskriptors und «aapInformative» read() zum Laden der Rohdatenblöcke, explizit mit dem Stereotyp «aapInformative» versehen.
  • Krypto-Schnittstelle: Interaktionsreferenz Initialize Cipher und synchrone Blocktransformation ProcessBlock() über den Cipher-Kontext von ara::crypto.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung des Storage-Handles:
   • Die :Adaptive Application setzt den synchronen Aufruf OpenKeyValueStorage() an :Persistency ab.
   • :Persistency öffnet die zugrundeliegende Persistenzdatei/Datenbank über den OS-Systemaufruf open(). Ein Handle auf KeyValueStorage wird an die Applikation zurückgegeben.
2. Datenanforderung:
   • Die Applikation triggert GetValue(key) an :Persistency.
   • :Persistency führt einen synchronen Blocklesevorgang über read() am :Operating System aus.
3. Bedingte Datenintegritätsprüfung & Fehlerkorrektur (alt [Redundancy enabled in the Manifest]):
   • Falls Redundanzmechanismen (z. B. M-out-of-N-Replikation, Prüfsummen/ECC) im Manifest konfiguriert sind, verzweigt der Ablauf in die Referenz Detect and Correct Data Errors. Etwaige Bitkipper oder Dateikorruptionen werden intern repariert.
4. Bedingte Entschlüsselung (alt [KeySlotMapping exists in Manifest and keySlotUsage = encryption]):
   • Ist dem Storage oder dem Key im Manifest ein KeySlot mit Verwendungszweck encryption zugeordnet, initiiert :Persistency über die Referenz Initialize Cipher den passenden Entschlüsselungskontext in :Cryptography.
   • Über ProcessBlock() werden die verschlüsselten Rohdaten synchron an :Cryptography übergeben und im Speicher dechiffriert.
5. Rückgabe:
   • :Persistency deserialisiert die validierten bzw. entschlüsselten Nutzdaten und liefert den Wert synchron an die :Adaptive Application zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Einstufung: Das Sequenzdiagramm entstammt dem erläuternden Konzeptdokument AUTOSAR_AP_EXP_SWArchitecture. Während die anwendungsseitigen Methoden (ara::per::OpenKeyValueStorage, GetValue) normative C++-API-Vorgaben der SWS Persistency sind, stellt die Ergänzung des Stereotyps «aapInformative» an den Aufrufen open() und read() formal klar, dass die konkrete Interaktion mit dem Betriebssystem nicht normiert ist.
• Entwickler- & Integrationshinweise:
  • Plattform-Implementierern steht die konkrete Wahl der Betriebssystemmechanismen frei (z. B. Dateisystem-I/O, Datenbank-Engines, Speicherabbildungen), solange das kontraktuelle Verhalten der ara::per-Schnittstellen eingehalten wird.
  • Anwendungsentwickler dürfen sich nicht auf konkrete POSIX-Dateideskriptoren oder dateisystemspezifische Blocklesevorgänge verlassen.
  • Manifestgesteuerte Mechanismen für Redundanz (Detect and Correct Data Errors) und Krypto-Transformation (ProcessBlock()) bleiben integrale, standardisierte Plattformdienste.