Figure 9.16: Interfaces of Log and Trace

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Realisierungsdiagramm (AUTOSAR Adaptive Platform UML-Profil für funktionale Cluster).
• Architektur-Kontext: Spezifiziert die native C++-Programmierschnittstelle («aapNativeInterface») des funktionalen Clusters Log and Trace (LOG) («aapFunctionalCluster») gemäß AUTOSAR_SWS_LogAndTrace innerhalb der AUTOSAR Adaptive Platform (Namespace ara::log).
• Funktionaler Zweck: Bereitstellung standardisierter Logging- und Tracing-Dienste (strukturierte Nachrichten, Loglevel-Filterung, Streaming, DLT-Anbindung) für Adaptive Applications zur Laufzeit.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• Adaptive Application: Client-Komponente im User-Space, greift über «use»-Abhängigkeiten auf die drei logischen Schnittstellen zu.
• «aapFunctionalCluster» Log and Trace: Plattform-Instanz (Server/Daemon), die die drei Schnittstellen realisiert (Darstellung via UML-Realisierungspfeile mit gestrichelter Linie und geschlossener, nicht ausgefüllter Pfeilspitze).

Schnittstellen & Klassen

• «aapAPI, aapNativeInterface» Log and Trace (Namespace-Ebene / Factory):
  • Enthält statische Utility- und Factory-Methoden (unterstrichen im Klassendiagramm):
    • CreateLogger(...): Factory zur Erzeugung oder Abfrage einer Logger-Instanz für eine spezifische Context-ID.
    • Arg(...), BinFormat(...), HexFormat(...): Formatierungs-Helfer für typsichere binäre/hexadezimale Formatierung im Stream.
    • remoteClientState(): Statusabfrage bzgl. aktiver Verbindung zu externen Diagnose-/DLT-Clients.
• «aapAPI, aapNativeInterface» Log and Trace::Logger (ara::log::Logger):
  • Kapselt den Logging-Kontext (spezifische Context-ID und Log-Level-Konfiguration).
  • IsEnabled(): Abfrage, ob ein bestimmter Log-Level aktiv geschaltet ist (Filter-Preflight).
  • Log(MsgId, Params): Strukturierte, ID-basierte Protokollierung.
  • LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug(), LogVerbose(): Loglevel-spezifische Erzeugungsmethoden, die jeweils ein temporäres LogStream-Objekt zurückgeben.
  • WithLevel(): Parametrisierte Erzeugung eines LogStream für dynamische Loglevel.
• «aapAPI, aapNativeInterface» Log and Trace::LogStream (ara::log::LogStream):
  • Stream-Pufferobjekt zur Verkettung von Lognachrichten-Fragmenten.
  • operator<<(): Überladener Streaming-Operator für Basistypen, Strings und Formatierer.
  • WithLocation(): Injektion von Quellcode-Metadaten (Dateiname, Zeilennummer, Funktionsname).
  • Flush(): Expliziter Flush zur Übergabe der serialisierten Lognachricht an den Cluster-Daemon.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung: Die Adaptive Application fordert via ara::log::CreateLogger(ctxId, ctxDesc) eine Logger-Instanz vom Functional Cluster an.
2. Pre-Filtering (optional/implizit): Prüfung mittels IsEnabled(), um unnötige Formatierungs- und Auswertungs-Overheads bei deaktivierter Severity zu vermeiden.
3. Stream-Instanziierung (RAII-Muster):
   • Aufruf von z. B. logger.LogInfo() erzeugt ein stackallokiertes, kurzlebiges LogStream-Objekt.
4. Payload-Zusammenstellung:
   • Über mehrfache operator<<-Aufrufe werden Nutzdaten und Formatierer (HexFormat(), BinFormat()) sequenziell in den internen Puffer serialisiert.
   • WithLocation() annotiert Dateiname und Zeile.
5. Abschluss & Übertragung:
   • Am Ende des Statements (Zerstörung des temporären LogStream-Objekts am Sequence Point) oder bei explizitem Flush() wird die Lognachricht finalisiert.
   • Der Puffer wird atomar über IPC/Shared Memory an den Logging-Daemon übergeben und je nach Plattform-Konfiguration in den DLT-Stream (Diagnostic Log and Trace, IEEE 802.3 / SOME/IP-Konsolen) oder Filesystem-Ringspeicher eingesteuert.

4. Normative Relevanz & Entwickler-Hinweise

• Echtzeitfähigkeit & Allokationsverbot: LogStream arbeitet im Streaming-Pfad mit vorallokierten, thread-lokalen Stack-/Ringpuffern. Dynamische Heap-Allokationen (new/malloc) sind im Aufruf von operator<< gemäß Autosar Adaptive Richtlinien strikt untersagt.
• RAII-Semantik: Die atomare Dispatch-Garantie einer Lognachricht hängt an der Lebensdauer des temporären LogStream. Das Caching von LogStream-Objekten über Anweisungsblöcke hinweg ist unzulässig, da der Flush an den Destruktor gekoppelt ist.
• API-Vertrag (ara::log): Reine In-Process-C++-Schnittstelle. Es ist kein ARA-COM-Manifest erforderlich; die Bindung an den Logging-Daemon erfolgt über plattformspezifische IPC-Mechanismen des Runtime-Clusters.
• DLT-Konformität: Lognachrichten werden intern in DLT-Standard-Frames überführt (Standardized Header, Extended Header mit Session-ID, App-ID, Context-ID und Payload). Die IDs müssen im AUTOSAR-Modell (Execution Management / Application Manifest) konsistent definiert sein.