Figure 7.4: Example program flow of ara::log/Trace

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Programmablaufplan / Aktivitätsdiagramm (Control Flow Diagram) mit Differenzierung zwischen Compile-Time- und Runtime-Entscheidungsebenen.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Log and Trace (ara::log).
• Funktionaler Zweck: Darstellung des internen Kontroll- und Filterflusses beim Absetzen eines Log-/Trace-Aufrufs (logger.Log). Visualisiert wird die Verzweigung zwischen dem klassischen DLT-Pfad (Diagnostic Log and Trace, Serialisierung & IPC/Sink) und der ARTI-Schnittstelle (AUTOSAR Run-Time Interface für Tracing/Profiling) unter Berücksichtigung statischer C++-Template-Spezialisierung und dynamischer Filtermasken.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Funktionseinheiten:
  • logger.Log(msg_id, params): Öffentliche C++-API-Einstiegsfunktion des Loggers.
  • TraceSwitch: Statische Compile-Time-Verzweigung via C++-Template-Spezialisierung.
  • loggerimpl.Log(msg_id, params): Interne Laufzeit-Implementierungsklasse der Logging-Engine (blauer Bereich).
  • TraceArti: ARTI-Trace-Hook / Backend-Schnittstelle zur Erfassung von Timing- und Laufzeitdaten ohne vorherige DLT-Filterung.
  • buildDltMessage(): Serialisierungs-Engine zur Generierung der standardisierten DLT-Nachrichtenstruktur (Standard/Extended Header, Payload).
  • sendDltMessageToSink(): IPC-/Transport-Abstraktion zum Versenden der DLT-PDU an den DLT-Daemon oder direkt an eine konfigurierte Log-Senke (z. B. Konsole, Dateisystem, Netzwerk/SOME/IP).
  • end: Terminierung des Logging-Aufrufs.
• Datenstrukturen & Kontrollvariablen:
  • msg_id: Nachrichtenidentifikator, enthält u. a. das Bitfeld mstp_mtin (DLT Message Type & Message Type Info: Log-Level bzw. Trace-Subtyp).
  • params: Variadische Nutzdaten / Log-Argumente.
  • DltLogSink.category: Kategorie der Ziel-Log-Senke (Gegenprüfung auf Konstante/Enumerator DLT_LOGSINK_ARTI).
  • logmask: Konfigurierte Bitmaske der aktiven Log-Level bzw. Trace-Typen.

3. Dynamisches Verhalten & Sequenzablauf

1. API-Aufruf (Synchron): Die Applikation ruft logger.Log(msg_id, params) auf.
2. Compile-Time-Evaluation (TraceSwitch):
   • Zweig „No“: Direkte Ausleitung an TraceArti. Umgeht zur Compile-Zeit die Laufzeit-Logger-Engine vollständig (Zero-Overhead-Pfad).
   • Zweig „Yes“: Weiterleitung an die Laufzeit-Instanz loggerimpl.Log(msg_id, params).
3. Evaluation Senken-Kategorie (DLT_LOGSINK_ARTI == DltLogSink.category?):
   • Zweig „Yes“: Verzweigt vor der DLT-Filterung direkt zu TraceArti. Die Filterung erfolgt in ARTI autonom auf Basis der msg_id.
   • Zweig „No“: Eintritt in die DLT-Verarbeitungskette.
4. DLT-Laufzeit-Filterung:
   • Bedingung: (0 == msg_id.mstp_mtin & logmask)
   • Evaluation true (Ergebnis 0): Die Nachricht ist durch die Bitmaske maskiert/inaktiv → Sprung zu end (Drop/Frühzeitiger Abbruch ohne Payload-Generierung).
   • Evaluation false (Schnittmenge vorhanden): Die Nachricht ist aktiv.
5. Nachrichtenkonstruktion & Dispatch:
   • Aufruf von buildDltMessage() zur Formatierung der DLT-Frames.
   • Aufruf von sendDltMessageToSink() zur Weiterleitung an das Backend.
   • Terminierung bei end.

4. Normative Relevanz & Entwickler-Hinweise

• Compile-Time-Optimierung (TraceSwitch): Durch Template-Spezialisierung kann der Trace-Pfad deterministisch fest verdrahtet werden. Entwickler müssen sicherstellen, dass bei aktivierten Low-Overhead-Traces keine unnötige Instanziierung von loggerimpl erfolgt.
• Separater ARTI-Filterpfad: ARTI-Meldungen dürfen nicht durch die DLT-Logmaske gefiltert werden. Das DLT-Laufzeit-Filtering (logmask) greift ausschließlich für den DLT-Nachrichtenpfad. ARTI filtert eigenständig über msg_id.
• Performance & Dead-Code-Elimination: Die Filterbedingung (0 == msg_id.mstp_mtin & logmask) erfolgt strikt vor buildDltMessage(). Dadurch wird teure Serialisierung, Puffer-Allokation oder String-Formatierung für deaktivierte Log-Ebenen vollständig vermieden (Early Exit).