Figure 9.101: Users of the Registry interfaces

1. Diagrammtyp & Architektur-Kontext

UML-Komponentendiagramm zur Darstellung der statischen Abhängigkeiten und Schnittstellennutzer innerhalb der AUTOSAR Adaptive Platform-Architektur. Das Diagramm modelliert die funktionale Komponente Registry und die von ihr bereitgestellte interne Schnittstelle sowie die funktionalen Cluster der Plattform, die als Klienten auf diese Schnittstelle zugreifen.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert eine zentrale Schnittstellenkomponente sowie elf nutzende und bereitstellende Cluster bzw. Komponenten:

• Bereitgestellte Schnittstelle:
  • ManifestAccessor: Stereotypisiert als «aapInternal,aapNativeInterface», fungiert als nativer Zugriffspunkt auf Manifestinformationen.
  • Bereitgestellt durch die funktionale Komponente Registry über eine Realisierungsbeziehung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).
• Nutzende Funktionale Cluster (Stereotyp «aapFunctionalCluster» bzw. abgekürzt «aapFunctionalClust...»), jeweils über eine gerichtete Abhängigkeit «use» (gestrichelter Pfeil mit offener Pfeilspitze) an ManifestAccessor angebunden:
  • Obere Reihe:
    • Communication Management (daemon-based)
    • Network Management (daemon-based)
    • Time Synchronization (daemon-based)
    • Update and Configuration Management (daemon-based)
    • Cryptography (daemon-based)
    • Diagnostic Management (daemon-based)
    • Vehicle Update and Configuration Management (daemon-based)
    • Platform Health Management (daemon-based)
  • Untere Reihe:
    • Persistency
    • Execution Management (daemon-based)
    • Log and Trace

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm zeigt eine rein statische Nutzungs- und Realisierungsstruktur ohne Sequenzabläufe, Nachrichtenflüsse oder Zustandsübergänge. Die funktionale Komponente Registry realisiert die interne Schnittstelle ManifestAccessor. Zur Laufzeit greifen die zehn abhängigen funktionalen Cluster synchron über native Aufrufe («aapNativeInterface») auf die Funktionen von ManifestAccessor zu, um Manifest- und Konfigurationsdaten abzufragen.

4. Normative Relevanz & Entwickler-Hinweise

• ManifestAccessor ist als plattforminterne Schnittstelle («aapInternal») deklariert; sie ist nicht für Standard-Anwendungsapplikationen bestimmt, sondern dient ausschließlich der plattforminternen Cluster-Interaktion.
• Die Interaktion erfolgt als native Programmierschnittstelle («aapNativeInterface»), typischerweise über C++-APIs innerhalb desselben Prozesskontexts oder IPC-Bindings.
• Sowohl Bibliothekscluster als auch daemon-basierte Cluster (daemon-based) hängen direkt von ManifestAccessor ab, was die Schnittstelle zu einer zentralen Basisabhängigkeit für das Bootstrapping und die Konfiguration der funktionalen Cluster macht.