Figure 1.1: Architecture overview

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Architektur-Blockschaltbild / Komponentendiagramm (AUTOSAR Functional Cluster Architecture Scope).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_SWS_LogAndTrace (ara::log).
• Funktionaler Zweck: Festlegung der Standardisierungsgrenzen (gelb umrandeter Block mit SWS-Kennzeichnung) des Functional Clusters Log and Trace gegenüber aufrufenden Applikationen, plattforminternen Clustern (ara::com), dem lokalen DLT-Daemon (Backend) sowie externen Test-/Diagnose-Clients.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (n-Instanzen):
  • Nutzerprozesse im POSIX-User-Space.
  • Binden die statische/dynamische Bibliothek von ara::log ein.
  • Beziehung: Unidirektionale synchrone Nutzung der Logging APIs über typsichere C++-Schnittstellen (Log-Streams / formatierte Ausgabe).
• Logging APIs / Logging and Tracing Functional Cluster (SWS-Scope):
  • Normativer Kern des Dokuments.
  • Enthält Frontend-APIs (ara::log::Logger, ara::log::LogStream), Kontext- und Applikations-ID-Verwaltung (ContextId, ApplicationId), lokales Severity-Filtering (LogLevel) sowie Pufferungs- und Serialisierungsmechanismen.
  • Kapselt IPC-Mechanismen zum Log-Daemon.
• ara::com:
  • AUTOSAR Adaptive Communication Management Functional Cluster.
  • Nutzt den Log-and-Trace-Cluster analog zu Applikationen zur Protokollierung interner Zustände sowie zum Tracing von Service-orientierter Kommunikation (z. B. SOME/IP-Nachrichten-Traces).
• Log and Trace backend / GENIVI DLT:
  • Plattformspezifischer Hintergrunddienst / Daemon (üblicherweise GENIVI/COVESA Diagnostic Log and Trace Daemon, dlt-daemon).
  • Beziehung zum SWS-Cluster: Bidirektionaler Kommunikationskanal (gelber Doppelpfeil). Transportiert aggregierte Log-Meldungen/Traces vom Frontend zum Daemon (IPC/Shared Memory/Sockets) und empfängt Laufzeit-Steuerbefehle (z. B. dynamische Änderung des Log-Levels via Injection-Messages) vom Daemon zurück in das Frontend.
• GENIVI DLT Client:
  • Externe Off-Board-Entität (z. B. DLT Viewer, Testautomatisierungswerkzeuge).
  • Verbindung: Physisches Netzwerk / Diagnose-Link via LT Protocol (DLT-Protokoll nach standardisiertem Header-/Payload-Format, typischerweise über TCP/UDP oder serielle Schnittstelle).

3. Dynamisches Verhalten & Sequenzablauf

• 1. Initialisierung & Registrierung:
  • Applikation/ara::com instanziiert Logger via ara::log::CreateLogger(ctxId, ctxDesc, defaultLogLevel).
  • Das SWS-Frontend registriert Kontext und Applikationskennung beim lokalen DLT-Backend (Handshake/IPC).
• 2. Log-Message-Emission (Fast Path / Filtering):
  • Applikation ruft z. B. logger.LogInfo() << ... auf.
  • Early Filtering: Liegt das Severity-Level unterhalb des konfigurierten Schwellwerts, bricht der Aufruf ohne Formatierung/IPC-Kosten synchron ab.
  • Serialisierung & Forwarding: Gültige Meldungen werden non-blocking/asynchron (je nach IPC-Pufferstrategie) an das GENIVI DLT-Backend übergeben.
• 3. External Dispatch (LT Protocol):
  • Das DLT-Backend puffert, versieht Nachrichten mit globalen Timestamps/Sequenznummern und serialisiert sie in DLT-Pakete.
  • Asynchroner Versand über Ethernet/IP an verbundene GENIVI DLT Clients.
• 4. Dynamische Rückkanal-Steuerung (Control Request):
  • DLT-Client sendet Steuerbefehl (z. B. SetLogLevel) via LT-Protokoll an das Backend.
  • Backend propagiert Änderung an den Cluster weiter; das SWS-Frontend passt die Severity-Masken der betroffenen Kontexte atomar zur Laufzeit an.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Abgrenzung (SWS-Grenze):
  • Nur die API-Signatur (ara::log) und das Verhalten der Frontend-Bibliothek innerhalb der Applikationsgrenze sind durch die AUTOSAR AP SWS normiert.
  • Die konkrete IPC-Implementierung zwischen SWS-Cluster und Log and Trace backend ist herstellerspezifisch (üblicherweise UNIX Domain Sockets oder Lockless Ringbuffers im Shared Memory).
• Echtzeit- & Determinismus-Restriktionen:
  • Logging darf nicht blockieren. Entwickler müssen Puffergrößen im Backend und Frontend so dimensionieren, dass bei hoher Buslast/Burst-Logging kein unkontrollierter Speicherüberlauf (OOM) oder Drop von Meldungen im Safety-Pfad auftritt.
• Dynamische Rekonfigurierbarkeit:
  • Applikationen müssen darauf ausgelegt sein, dass Filter-Levels extern ohne Neustart modifiziert werden können.
• Off-Board-Interoperabilität:
  • Da das Protokoll (LT Protocol) auf dem GENIVI/COVESA-Standard basiert, sind Werkzeuge herstellerunabhängig kompatibel, sofern standardkonforme DLT-Storage-Header und Verbose/Non-Verbose-Payloads verwendet werden.