Figure 9.79: Interfaces required by Registry

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Struktur- und Abhängigkeitsdiagramm (Component & Interface Dependency Diagram).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R21-11), Spezifikation AUTOSAR_EXP_SWArchitecture.
• Technischer Zweck: Dokumentation der minimalen externen Plattform- und Betriebssystemabhängigkeiten des Functional Clusters Registry. Das Diagramm definiert, dass die Registry zur Zustandssicherung nicht auf andere High-Level-Cluster (wie ara::per), sondern direkt auf eine interne, vom zugrundeliegenden Betriebssystem bereitgestellte nicht-flüchtige Speicherschnittstelle aufsetzt.

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Registry:
  • Logischer Funktionscluster der AUTOSAR Adaptive Platform (Plattformebene).
  • Verwaltet Registrierungs- und Zuordnungsdaten (z. B. Service-/Instanzregistrierungen, Konfigurations- oder Identitätsmappings).
• «aapInternal» Non-volatile Storage:
  • Stereotyp «aapInternal»: Markiert eine plattforminterne Schnittstellenabstraktion, die nicht als öffentliches C++-API (ara::*) für reguläre Adaptive Applications exponiert ist.
  • Stellt Abstraktionen für nicht-flüchtigen Speicherzugriff bereit (Schreiben, Lesen, Persistieren von Registry-Datensätzen).
• Operating System:
  • Basiskomponente der Adaptive-Laufzeitumgebung (in der Regel POSIX-konformes PSE51/PSE52/PSE53-kompatibles Betriebssystem inkl. Hardware-Treiber).
• Beziehungen:
  • Registry → Non-volatile Storage: UML-Abhängigkeit («use», gestrichelte Linie mit offener Pfeilspitze). Die Registry konsumiert die Speicherschnittstelle.
  • Operating System → Non-volatile Storage: UML-Schnittstellenrealisierung (Interface Realization, gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze). Das Betriebssystem implementiert die geforderte nicht-flüchtige Speicherfunktionalität (z. B. über POSIX-Dateisysteme, Flash-/NVRAM-Treiber oder Blockdevices).

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammcharakter: Rein statisches Struktur- und Schnittstellenmodell; enthält keine explizite zeitliche Sequenzabfolge.
• Impliziter Laufzeitablauf:
  1. Boot-/Initialisierungsphase: Die Registry liest während des Startups (orchestriert durch Execution Management) zuvor persistierte Datensätze synchron über die interne OS-Speicherschnittstelle ein, um den Registry-Zustand wiederherzustellen.
  2. Laufzeitaktualisierung: Bei Zustandsänderungen, Neuregistrierungen oder Updates persistiert die Registry kritische Daten über synchrone oder asynchrone OS-Storage-Aufrufe (z. B. File-I/O mit anschließendem fsync() / Flush), um Power-Fail-Sicherheit über Boot-Zyklen hinweg zu gewährleisten.

4. Normative Relevanz & Entwickler-Hinweise

• Keine ara::per-Zirkularität: Die Registry nutzt bewusst nicht den Persistency-Cluster (ara::per), um Henne-Ei-Probleme und zirkuläre Initialisierungsabhängigkeiten beim Platform-Bootstrap zu vermeiden.
• Plattform- & OS-Integratoren:
  • Das eingesetzte POSIX-Betriebssystem muss eine robuste, ausfallsichere Speicherpartition (Flash/eMMC/SSD) bereitstellen, auf die der Registry-Prozess zugreifen kann.
  • Zugriffsrechte (DAC/MAC, z. B. SELinux-Policies) müssen so konfiguriert werden, dass der Registry-Daemon Lese- und Schreibberechtigung auf die zugehörigen Pfade/Block-Devices besitzt.
• Applikations-Entwickler:
  • Die Schnittstelle Non-volatile Storage ist intern («aapInternal») und für Adaptive Applications weder sichtbar noch direkt bindbar.
  • Standard-Applikationen interagieren ausschließlich über die standardisierten Service-Interfaces mit der Registry.