Figure 9.5: Users of the ExecutionClient interface

1. Diagrammtyp & Architektur-Kontext

UML-Komponentendiagramm / Klassendiagramm im Kontext der AUTOSAR Adaptive Platform (Execution Management). Das Diagramm stellt die Schnittstelle ExecutionClient dar, über die daemon-basierte funktionale Cluster der Plattform ihren Ausführungsstatus an das Execution Management melden.

2. Komponenten, Entitäten & Schnittstellen

• Execution Management: Funktionaler Cluster («aapFunctionalCluster», daemon-based), realisiert die Schnittstelle ExecutionClient via Interface-Realisierung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze).
• ExecutionClient: C++-API bzw. natives Interface («aapAPI,aapNativeInterface») mit den Operationen:
  • + Create() (statische Erzeugungsmethode / Factory, unterstrichen)
  • + ReportExecutionState(ExecutionState): Result
• Nutzende funktionale Cluster (alle als «aapFunctionalCluster», daemon-based typisiert):
  • State Management
  • Platform Health Management
  • Diagnostic Management
  • Update and Configuration Management
  • Time Synchronization Jeder dieser Cluster besitzt eine gerichtete Abhängigkeitsbeziehung («use», gestrichelter Pfeil mit offener Spitze) auf ExecutionClient.

3. Dynamisches Verhalten & Sequenzablauf

Statische Schnittstellen- und Verwendungsbeziehung. Daemon-basierte funktionale Cluster instanziieren den Client über die Factory-Methode Create() und melden ihren Prozesszustand an das Execution Management mittels ReportExecutionState(ExecutionState) unter Rückgabe eines Result.

4. Normative Relevanz & Entwickler-Hinweise

Für die Implementierung von Plattform-Daemon-Clustern normativ: Der Lebenszyklus der Client-Instanz wird über die statische Factory-Methode Create() initiiert. Die Zustandsmeldung an das Execution Management erfolgt über ReportExecutionState(...).