Figure 9.94: Interfaces required by Update and Configuration Management (part 2)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Komponentendiagramm mit AUTOSAR Adaptive Platform (AP) Metamodell-Stereotypen.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R22-11), Spezifikation AUTOSAR_EXP_SWArchitecture.
• Technischer Zweck: Spezifikation der vom Update and Configuration Management (UCM, Teil des Foundation-/Service-Layers) zwingend benötigten nativen Plattform-C++-Schnittstellen (Required Interfaces, Part 2). Es dokumentiert die Bindung von UCM an das Prozess-Lebenszyklusmanagement (Execution Management, EM) sowie an das Diagnose- und Betriebs-Logging (Log and Trace, LOG).

2. Komponenten, Entitäten & Schnittstellen

Entitäten / Functional Cluster:

• Update and Configuration Management:
  • Stereotyp: «aapFunctionalCluster», Ausprägung: daemon-based
  • Rolle: Konsument (Client) der Plattformdienste.
• Execution Management:
  • Stereotyp: «aapFunctionalCluster», Ausprägung: daemon-based
  • Rolle: Plattformdienst zur Prozesskontrolle, Zustandsverwaltung und State-Client-Überwachung.
• Log and Trace:
  • Stereotyp: «aapFunctionalCluster»
  • Rolle: Plattformdienst zur Aggregation, Formatierung und Weiterleitung von Log- und Tracing-Nachrichten (z. B. via DLT).

Schnittstellen (AP Native Interfaces / APIs):

• Logger («aapAPI,aapNativeInterface», C++-Namespace ara::log):
  • Bereitgestellt durch: Log and Trace (Realisierungsbeziehung, gestrichelte Linie mit geschlossener Dreiecksspitze).
  • Genutzt von: Update and Configuration Management («use»-Abhängigkeit).
  • Methoden:
    • + IsEnabled(): bool: Abfrage mit explizitem booleschem Rückgabetyp, ob das konfigurierte Log-Level aktiv ist.
    • + Log(MsgId, Params): Strukturiertes Logging mit Message-Identifier.
    • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream: Typsichere Methoden zur Erzeugung eines Log-Streams je Severity-Level.
    • + WithLevel(): LogStream: Dynamische Zuweisung des Log-Levels zur Stream-Erzeugung.
• ExecutionClient («aapAPI,aapNativeInterface», C++-Namespace ara::exec):
  • Bereitgestellt durch: Execution Management (Realisierungsbeziehung, gestrichelte Linie mit geschlossener Dreiecksspitze).
  • Genutzt von: Update and Configuration Management («use»-Abhängigkeit).
  • Methoden:
    • + Create(): Statische Factory-Methode zur Erzeugung einer Instanz des ExecutionClient.
    • + ReportExecutionState(ExecutionState): Zustandsmeldung des UCM-Prozesses an den EM-Daemon (ohne explizit ausgewiesenen Rückgabetyp).

3. Dynamisches Verhalten & Sequenzablauf

1. Bootstrap & Lebenszyklus-Meldung:
   • Der UCM-Daemon wird durch das Execution Management gestartet.
   • Nach erfolgreicher interner Initialisierung instanziiert UCM einen ara::exec::ExecutionClient und setzt synchron ReportExecutionState(ExecutionState::kRunning) ab.
   • Bleibt dieser Aufruf innerhalb des im Execution Manifest definierten Start-up-Timeouts aus, leitet EM deterministische Recovery-Maßnahmen ein (Prozessneustart / Safe State Übergang).
2. Laufzeit-Protokollierung:
   • Während Update-Zyklen (Transfer, Verifikation, Software-Paket-Aktivierung, Rollback) erzeugt UCM über den ara::log::Logger kontextbezogene Meldungen.
   • Über Methoden wie LogInfo() oder LogError() wird ein flüchtiger LogStream geöffnet, via C++ Stream-Operatoren (<<) befüllt und beim Verlassen des Scopes (Destruktor) thread-sicher via prozesslokale Shared-Memory-/Socket-IPC an den Log and Trace-Daemon übergeben.

4. Normative Relevanz & Entwickler-Hinweise

• Keine Exceptions / ara::core::Result: Alle Aufrufe an ExecutionClient und Logger folgen der AUTOSAR C++14/C++17 Richtlinie. Fehlerpfade werden ohne C++-Exceptions über ara::core::Result und ara::core::ErrorCode abgewickelt.
• Manifest-Konfiguration:
  • Für UCM muss ein entsprechendes ProcessDesign und ExecutionManifest hinterlegt sein, das den Startup-Pfad, Dependencies und Überwachungs-Timeouts für ReportExecutionState deklariert.
  • Für den Logger ist im Execution/Application Manifest eine LogTraceProcessDesc-Konfiguration mit fester App-ID und Default-Context-IDs zwingend erforderlich.
• Prozessarchitektur (daemon-based): UCM agiert als persistenter System-Daemon im User-Space des POSIX-Betriebssystems. Die Kommunikation zu EM und LOG erfolgt über plattforminterne IPC-Mechanismen, ist jedoch für den UCM-Entwickler vollständig durch die statisch/dynamisch gelinkten Bibliotheken libara_exec.so und libara_log.so gekapselt.