Figure 7.3: Overview of Tracing

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturschichten- und Datenflussdiagramm (Blockschaltbild) mit Spezifikations- und Implementierungs-Mapping.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Log and Trace (ara::log). Das Diagramm visualisiert die Integration von Tracing-Mechanismen auf Anwendungs-, System- und Betriebssystemebene sowie die Anbindung des AUTOSAR Run-Time Interface (ARTI) zur Erfassung von Timing- und Ausführungsdaten neben den klassischen Logging-Senken.
• Technischer Zweck: Gegenüberstellung normativ spezifizierter Schnittstellen (grün) und beispielhafter herstellerspezifischer Adapter/Komponenten (orange) zur Verdeutlichung der Entkopplung zwischen ara::log, dem zugrunde liegenden POSIX-OS und der leichtgewichtigen ARTI-C-Tracing-Infrastruktur.

2. Komponenten, Entitäten & Schnittstellen

Datenquellen / Architekturebenen (Links)

• Application Level (AA): Adaptive Applications, die Tracing-Hooks und Kontextdaten über die C++-API emittieren.
• System Level (FC): Functional Clusters der Adaptive Platform (z. B. Execution Management, Communication Management, State Management), die systemrelevante Zustands- und Ablaufereignisse protokollieren.
• POSIX/OS Level: Betriebssystem-Kernel- und Threading-Ebene (POSIX OS), welche Prozesskontexte, Context-Switches, Thread-Zustände, CPU-Zyklen und Syscalls liefert.

Schnittstellen & Spezifikationskomponenten (Normativ / Grün)

• ara::log/trace API (enhancement of ara::log): Normative C++-API-Erweiterung des ara::log-Clusters zur Erfassung strukturierter Trace-Punkte (Trace Events, State Changes, Duration Markers).
• OS/ARTI API: Normativ definierte Schnittstelle zur Einspeisung von Low-Level-Betriebssystem-Hooks in das ARTI-Framework.
• ara::log/ARTI API: Normierte Adapter-Schnittstelle, die es dem ara::log-Cluster ermöglicht, Trace-Events synchron oder asynchron an die ARTI-Engine weiterzuleiten.

Implementierungs- & Adapterkomponenten (Sample Implementation / Orange & Grau)

• ara::log (Kern-Cluster, grau): Zentrale Logging- und Tracing-Engine zur Pufferung, Filterung (Log-Level, Context-IDs) und Formatierung.
• OS/ara::log Adapter (orange): OS-spezifischer Wrapper, der native Betriebssystem-Events (z. B. POSIX-Signale, Tracing-Hooks) in Aufrufe der ara::log/trace API transformiert.
• OS/ARTI Adapter (orange): Low-Level-Adapter zur direkten Abbildung von Kernel-/OS-Trace-Events auf die OS/ARTI API unter Umgehung des Overhead-behafteten ara::log-Stacks.
• ARTI (light weight C API) (orange): AUTOSAR Run-Time Interface Implementierung als C-Schnittstelle mit minimalem Overhead und deterministischer Latenz für Tracing- und Profiling-Tools.

Senken / Exporteure (Rechts)

• DLT (Diagnostic Log and Trace): Standardisiertes Logging-Protokoll (automotive-spezifisch via Ethernet/Serial zu Logging-Daemons/External Viewers).
• Console: Ausgabe auf Standard-Streams (stdout/stderr).
• File: Persistierung auf dem lokalen Dateisystem / Non-Volatile Memory.
• ARTI Outgoing Stream: Deterministischer, binärer Exportkanal (z. B. Hardware-Trace, Ring-Puffer, Debug-Sonde) für Timing-Analysen und Profiler (z. B. Lauterbach, Vector, Percepio).

3. Dynamisches Verhalten & Sequenzablauf

1. High-Level Application & Cluster Trace-Pfad (Blau/Schwarz):
   • AA und FC injizieren Tracing-Events direkt in die C++-basierte ara::log/trace API.
   • ara::log verarbeitet, filtert und dispatcht die Events parallel an die konfigurierten Standard-Senken (DLT, Console, File).
2. OS-Level Logging-Pfad via Adapter (Rot → Schwarz):
   • Ereignisse der POSIX/OS-Ebene werden durch den OS/ara::log Adapter erfasst und ebenfalls als ara::log-Nachrichten in die ara::log/trace API eingespeist.
3. Low-Overhead & Timing Trace-Pfad via ARTI (Rot):
   • Pfad A (OS-Direct): Timing-kritische POSIX-Events werden über den OS/ARTI Adapter und die OS/ARTI API direkt in die ARTI-C-Engine geleitet. Dies vermeidet C++-Laufzeit-Overhead (kein dynamischer Speicher, keine String-Formatierung).
   • Pfad B (ara::log Forwarding): ara::log leitet ausgewählte, ARTI-relevante Events über die ara::log/ARTI API an ARTI weiter, um eine Korrelation zwischen Anwendungs-Events und Low-Level-Scheduling-Informationen zu ermöglichen.
   • ARTI emittiert diese Daten gesammelt über seinen High-Speed-Trace-Sink.

4. Normative Relevanz & Entwickler-Hinweise

• API-Trennung & Laufzeit-Kosten: Die ara::log/trace API nutzt C++-Paradigmen und eignet sich für semantisches Tracing in AAs und FCs. Für latenzkritische Abschnitte (Interrupts, Fast-Path Threads, harte Echtzeitanforderungen) muss das Schlankheitsgebot gewahrt werden: Direkte ARTI-Nutzung über C-APIs vermeidet dynamische Allokationen und Serialisierungs-Jitter.
• Dualer Logging-/Tracing-Kanal: Das System unterstützt redundante bzw. komplementäre Pfade: Ein Event kann sowohl über DLT für Funktions- und Flottendiagnose als auch über ARTI für Worst-Case Execution Time (WCET)-Analysen und Scheduling-Verifikation ausgegeben werden.
• Portabilität von OS-Hooks: Da POSIX-Betriebssysteme (z. B. QNX Neutrino, Linux/PREEMPT_RT, PikeOS) proprietäre Kernel-Tracing-Schnittstellen (z. B. traceevent, perf/ftrace, eBPF) nutzen, sind OS/ara::log Adapter und OS/ARTI Adapter plattformspezifisch bereitzustellen. Der Stack-Integrator muss sicherstellen, dass die Trace-IDs zwischen ara::log und ARTI konsistent zugeordnet werden.
• Konfigurationsaspekte: Senken (DLT, Console, File, ARTI) sind entkoppelt aktivierbar. In Serien-Builds wird der Console-Pfad typischerweise deaktiviert, während DLT und ARTI basierend auf Filtermasken (App-ID, Context-ID, Log-Level) konditioniert werden.