Figure 16.1: Overview Log and Trace

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Komponenten- und Interaktionsdiagramm (funktionales Architektur-Schichtenmodell der AUTOSAR Adaptive Platform).
• Technischer Zweck: Spezifiziert die Systemarchitektur des Functional Clusters Logging and Tracing (ara::log gemäß AUTOSAR_SWS_LogAndTrace) in der Adaptive Platform (Dokument: AUTOSAR_EXP_PlatformDesign, Kapitel 16).
• Funktionale Einordnung: Definiert die Entkopplung zwischen loggenden POSIX-Applikationsprozessen bzw. Plattform-Clustern (ara::tsync), der standardisierten Schnittstellenschicht (Logging APIs), dem systemweiten Vermittlungs-Daemon (Log and Trace backend) und der externen Test-/Diagnoseumgebung (DLT Client) über das DLT-Übertragungsprotokoll.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application: POSIX-Applikationsprozesse im User Space. Fungieren als Erzeuger von Trace- und Log-Ereignissen.
• ara::tsync: Plattform-Cluster für Zeitsynchronisation (ara::tsync gemäß AUTOSAR_SWS_TimeSynchronization). Bindet an die Logging APIs an (z. B. zur Protokollierung von Synchronisationsereignissen bzw. Bereitstellung synchronisierter Zeitbasen für Log-Einträge).
• Logging APIs / Logging and Tracing Functional Cluster [SWS]: Normierte C++-Schnittstellenschicht (ara::log::Logger, ara::log::LogStream). Übernimmt Prozess-lokales Filtern, Formatieren (Verbose/Non-Verbose) und Kontext-Management (AppId, CtxId).
• Log and Trace backend DLT: Plattform-Daemon (z. B. dlt-daemon), der Log-Meldungen prozessübergreifend aggregiert, temporär im Ringpuffer hält, filtert und serialisiert.
• DLT Client: Off-Board-Diagnose- und Entwicklungswerkzeug (z. B. DLT Viewer) zur Analyse und Filterung von Trace-Daten.
• Schnittstellen & Beziehungen:
  • Adaptive Application → Logging APIs / ara::tsync → Logging APIs: Direkte C++-In-Process-API-Aufrufe (unidirektional, synchroner Aufruf aus Sicht der emittierenden Task).
  • Logging APIs ↔ Log and Trace backend: Lokale IPC-Verbindung (bidirektional; Messages fließen ins Backend, Konfigurationsänderungen wie Log-Level-Updates fließen zurück in die Client-Bibliothek).
  • Log and Trace backend → DLT Client: Externe physikalische Verbindung (Ethernet/Serial) über das standardisierte LT Protocol (Diagnostic Log and Trace Protocol gemäß AUTOSAR_PRS_LogAndTraceProtocol / DLT-Standard).

3. Dynamisches Verhalten & Sequenzablauf

• Log-Generierung & Filterung (Fast Path):
  1. API-Aufruf: Applikation instanziiert Kontext und triggert Loglevel-Methoden (LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug(), LogVerbose()).
  2. Early-Discard-Filter: Die lokale ara::log-Instanz prüft das aktuelle Schwellwert-Level des Kontextes atomar. Liegt das Level unter dem Schwellwert, bricht der Aufruf sofort ohne String-Serialisierung oder Puffer-Zuweisung ab.
  3. IPC-Dispatch (Asynchron): Bei aktivem Loglevel wird der Datensatz serialisiert und nicht-blockierend (z. B. via Lock-free Ringbuffer / UNIX Domain Socket) an das Log and Trace backend übergeben.
• Backend-Distribution & Off-Board-Transport:
  1. Pufferung & Paketierung: Der Backend-Daemon empfängt die Rohdaten, versieht sie mit DLT-Standard-Headern (Timestamp, Session-ID, Message-Counter, App-ID, Ctx-ID) und puffert sie.
  2. Streaming via LT Protocol: Asynchrone Übertragung über TCP/UDP/Serial an den DLT Client.
• Rückkanal (Injection & Control Flow):
  • Der DLT Client sendet Kontrollnachrichten (z. B. SetLogLevel, SetTraceStatus, GetLogInfo) über das LT Protocol an das Backend.
  • Das Backend propagiert geänderte Filterkriterien über den bidirektionalen IPC-Kanal an die Logging APIs der laufenden Prozesse, wodurch Filtergrenzen zur Laufzeit dynamisch angepasst werden.

4. Normative Relevanz & Entwickler-Hinweise

• API-Kapselung & Portabilität:
  • Applikationen und Plattform-Services dürfen ausschließlich gegen den normierten Namensraum ara::log linken. Direkte Zugriffe auf DLT-Daemon-Sockets oder native DLT-APIs sind architektonisch unzulässig.
• Laufzeitverhalten & Echtzeit-Restriktionen:
  • Logging-Calls sind deterministisch und blockierungsfrei auszulegen. Bei Überlastung der IPC-Verbindung oder des Backend-Puffers greift ein geregeltes Message-Dropping (im DLT-Header durch inkrementierte Message-Counter nachweisbar).
  • In harten Echtzeit- oder Safety-Threads (ASIL) ist die Zuweisung dynamischen Speichers innerhalb von Logging-Operationen zu vermeiden; statische Payload-Limits und Non-Verbose-Modus (Übertragung von FIBEX/ARXML-IDs statt Klartext-Strings) sind zu bevorzugen.
• Manifest-Konfiguration:
  • LogMode (kRemote, kFile, kConsole), Default-Log-Level und Zuordnungen von ContextId zu ApplicationId müssen im Execution Manifest der Adaptive Application deklariert werden.
• Security-Aspekte:
  • Der Kommunikationskanal des LT Protocol über externe Schnittstellen ist gegen unautorisiertes Mitschneiden oder Manipulation abzusichern (z. B. durch Deaktivierung im Serienbetrieb oder Schutz via TLS/IPsec), da Trace-Dumps sicherheitskritische Payload- und Zustandsdaten exponieren können.