Figure 9.16: Users of the Log and Trace interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Component Dependency & Interface Realization).
• Technischer Zweck: Spezifikation der AUTOSAR Adaptive Platform (AP) Querschnittsarchitektur für das Protokollierungs- und Trace-Subsystem. Das Diagramm dokumentiert die zentrale Rolle des Functional Clusters Log and Trace (ara::log) und dessen einheitliche C++ Native API (Logger), die von allen wesentlichen Foundation- und Service-Clustern als Basisinfrastruktur konsumiert wird.

2. Komponenten, Entitäten & Schnittstellen

Zentrale Schnittstelle

• Logger («aapAPI, aapNativeInterface»):
  • Bereitgestellte Operationen:
    • + IsEnabled(): bool: Dynamische Prüfung mit explizitem Rückgabetyp bool, ob eine Protokollierung für den gewählten Kontext/Level aktiv ist.
    • + Log(MsgId, Params): Strukturierte, ID-basierte Protokollierung zur Vermeidung von Runtime-String-Interpolation.
    • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream: Typsichere Fluent-/Streaming-Methoden nach Severity-Level.
    • + WithLevel(): LogStream: Generischer Einstiegspunkt für parametrisierte Loglevel.

Bereitstellende Entität (Realization)

• Log and Trace («aapFunctionalCluster»): Realisiert das Interface Logger (gestrichelte Linie mit geschlossener Dreiecksspitze). Stellt sowohl die In-Process-Client-Bibliothek (ara::log) als auch die Anbindung an den DLT-Logging-Daemon (Diagnostic Log and Trace) bereit.

Konsumierende Entitäten («use»-Abhängigkeiten)

Insgesamt 11 funktionale Cluster greifen direkt auf die Logger-Schnittstelle zu:

• Daemon-basierte Functional Clusters (daemon-based):
  • Execution Management (ara::exec)
  • State Management (ara::sm)
  • Time Synchronization (ara::tsync)
  • Network Management (ara::nm)
  • Diagnostic Management (ara::diag)
  • Platform Health Management (ara::phm)
  • Intrusion Detection System Manager (ara::idsm)
  • Communication Management (ara::com)
  • Vehicle Update and Configuration Management (ara::vucm)
  • Update and Configuration Management (ara::ucm)
• Bibliotheksbasierte / Service-basierte Functional Clusters:
  • Persistency (ara::per)

3. Dynamisches Verhalten & Sequenzablauf

Obwohl das Diagramm primär statische Abhängigkeiten modelliert, erzwingt die Methodensignatur von Logger ein deterministisches Streaming- und RAII-Aufrufmuster:

[Caller / FC]                 [Logger API]               [LogStream (Temp)]             [DLT / ara::log Backend]
      |                             |                             |                                 |
      |--- 1. IsEnabled()? -------->|                             |                                 |
      |<-- (bool: true/false) ------|                             |                                 |
      |                                                           |                                 |
      |--- 2. LogInfo() ----------->|                             |                                 |
      |                             |-- ctor() ------------------>|                                 |
      |<-- returns LogStream ref ---------------------------------|                                 |
      |                                                           |                                 |
      |--- 3. operator<< (data) --------------------------------->| (Serialisierung in Ringpuffer)  |
      |                                                           |                                 |
      |--- 4. Statement-Ende (RAII-Destruktion) ----------------->|                                 |
                                                                  |-- dtor(): flush() ------------->|
                                                                                                    | (Lock-free IPC/Shared Memory)

• Filterung (Short-Circuit): Mittels IsEnabled() bzw. internem Level-Vergleich wird die Evaluierung von Parametern bei inaktivem Loglevel frühzeitig abgebrochen (Minimal-Overhead-Garantie).
• Thread-Safety & Non-Blocking Flush: Die Serialisierung erfolgt synchron im Aufrufer-Thread in einen thread-lokalen oder sperrfreien Ringpuffer; der finale Transport zum Log-Daemon erfolgt entkoppelt/asynchron via IPC.

4. Normative Relevanz & Entwickler-Hinweise

• Bootstrapping & Initialisierungs-Reihenfolge: Da sicherheitskritische Early-Boot-Dienste wie Execution Management (ara::exec) und Platform Health Management (ara::phm) Protokollausgaben erzeugen, muss die Logging-Client-Bibliothek vor oder während der Daemon-Startphase aufrufbar sein. Unverarbeitete Logs müssen gepuffert werden (Early-Logging-Buffer), bevor der DLT-Kommunikationskanal etabliert ist.
• Echtzeit- und Determinismus-Vorgaben: Für zeitkritische Cluster (Time Synchronization, PHM) dürfen Aufrufe an LogStream keine dynamischen Heap-Allokationen (malloc/new) im Hot-Path auslösen.
• Zirkuläre Abhängigkeiten: Log and Trace darf zur Erfüllung seiner Basisfunktion keine blockierenden Abhängigkeiten zu Clustern eingehen, die es selbst loggen (z. B. keine synchrone Nutzung von Persistency oder Platform Health Management innerhalb des Core-Logging-Pfads).
• Sicherheits- und Zugriffskontrolle: Wenn Identity and Access Management (IAM) oder Crypto den Logger nutzen, müssen sensible Daten (Schlüssel, Tokens) vor dem Streamen geschwärzt oder über strukturierte IDs maskiert werden (Log(MsgId, Params)), um Secret-Leakage im Trace-Stream zu verhindern.