Figure 7.1: Log mode

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Funktionales Architektur-, Komponenten- und Datenflussdiagramm (Blockschaltbild der Logging-Topologie).
• Technischer Zweck: Spezifikation der Topologie und Verteilungsmechanismen für das funktionale Cluster Logging and Tracing (ara::log) auf der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Das Diagramm trennt deklarative Konfigurationsebenen (Manifeste) von den Laufzeitkomponenten (Applikationen, API-Bibliothek, Backend-Daemon) sowie den Zielsenken (Log-Sinks). Es definiert die Grenze zwischen On-Board-Ressourcen (Maschinen-/Knotengrenze, symbolisiert durch den äußeren Begrenzungsrahmen) und externen Off-Board-Diagnosetools (Network – LT Log Viewer).

2. Komponenten, Entitäten & Schnittstellen

Konfigurationsartefakte (ARXML / Manifest-Ebene)

• Execution Manifest – LogMode: Prozessbezogene Konfiguration pro Adaptive Application. Spezifiziert das Metamodell-Attribut logMode (Kombination aus kConsole, kFile, kRemote), welches steuert, welche Zielsenken von den prozesslokalen Logging-APIs bedient werden.
• Machine Manifest – Network, LogStorage, etc.: Plattformweite Konfiguration für die Maschine/Knoteninstanz. Definiert Parameter für das LT Backend (Netzwerk-Endpunkte, IP/Port-Bindings, Transportprotokolle wie UDP/TCP sowie Speicherbegrenzungen und Pfade für persistentes Logging).

Ausführungskomponenten & Schnittstellen

• Adaptive Application: POSIX-User-Space-Prozess, der über Instanzen von ara::log::Logger strukturierte Log-Streams absetzt.
• Logging APIs / Logging and Tracing Functional Cluster («SWS»): Normierter C++-API-Layer (ara::log), der prozesslokal gelinkt wird. Übernimmt Client-seitige Log-Level-Filterung (Verbose, Debug, Info, Warn, Error, Fatal), Formatierung und das Dispatching an die konfigurierten Senken.
• LT Backend: Zentraler Plattform-Daemon (typischerweise DLT-Daemon gemäß Diagnostic Log and Trace). Aggregiert Logs sämtlicher lokaler Applikationen über plattformspezifische IPC (Shared Memory oder Unix Domain Sockets).

Senken / Log-Sinks

• Prozesslokale Senken (direkt via Logging APIs):
  • Console: Ausgabe unformatiert/formatiert über stdout/stderr (primär für interaktives Debugging während der Entwicklung).
  • File – Development Purposes: Lokale Dateiausgabe im Applikationskontext ohne Einbindung des zentralen Daemons.
• Zentralisierte Senken (via LT Backend):
  • File – LogStorage: Persistierung im standardisierten Binärformat (DLT-Storage-Format) auf nicht-flüchtigem Speicher (eMMC, NVRAM) unter Beachtung von Ringpuffer- und Quota-Vorgaben.
  • Network – LT Log Viewer: Übertragung via Ethernet/IP (DLT-Protokoll-Frames) über die Maschinengrenze hinweg an externe Analysewerkzeuge (z. B. DLT Viewer).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase:
   • Execution Management (EM) instanziiert die Applikationsprozesse; die ara::log-Laufzeit wertet das zugeordnete Execution Manifest bezüglich des aktiven LogMode aus.
   • Das LT Backend wird initialisiert und liest Netzwerk- und Storage-Parameter aus dem Machine Manifest.
2. Erzeugung & Filterung (Synchron im Applikationskontext):
   • Applikation ruft Log-Makro/Methode auf (z. B. logger.LogInfo() << ...;).
   • Die API prüft den Schwellwert des Log-Levels gegen den konfigurierten Mindest-Level (lokal oder via DLT-Injektion dynamisch angepasst). Liegt der Level unter dem Schwellwert, bricht die Verarbeitung sofort ab (Zero-Cost / minimaler Overhead).
3. Dispatching gemäß LogMode:
   • Pfad Console: Synchrones/asynchrones Schreiben in den Standardausgabe-Stream.
   • Pfad File (Development): Direktes Schreiben in lokale Log-Dateien.
   • Pfad Remote: Kapselung der Nachricht in DLT-Header-Strukturen (App-ID, Context-ID, Session-ID, Timestamp) und asynchrone Weiterleitung via IPC an das LT Backend.
4. Backend-Verarbeitung & Persistierung (Asynchron im Daemon-Kontext):
   • Das LT Backend nimmt Nachrichten über den IPC-Kanal entgegen und puffert diese in internen Ringpuffern (Entkopplung zur Vermeidung von Backpressure auf echtzeitkritische Applikationen).
   • Verteilung parallel an:
     • LogStorage: Schreiben auf Massenspeicher nach definierten Sync- und Rotationsstrategien.
     • Network: Serialisierung über TCP/UDP-Sockets an verbundene externe Log-Viewer-Clients.
5. Fehler- und Überlaufverhalten:
   • Bei Pufferüberlauf im Backend oder Netzwerkabriss greifen Drop-Policies; im DLT-Header wird der Message-Loss-Counter inkrementiert, um Paketverlust für den Log-Viewer auditierbar zu machen.

4. Normative Relevanz & Entwickler-Hinweise

• API-Kapselung (ara::log): Applikationscode darf weder direkt auf das Dateisystem (/var/log/...), stdout (std::cout, printf) noch auf Netzwerk-Sockets zugreifen. Die Entscheidung über das Ausgabeziel obliegt rein dem Deployment-Manifest (Execution Manifest).
• Performance- und Echtzeiteinfluss:
  • Die Modi Console und File – Development Purposes können synchrone I/O-Blockaden verursachen und sind für Serienstände (Production Deployments) im Manifest zwingend zu deaktivieren.
  • Im Serienbetrieb ist LogMode = Remote (kRemote) vorzusehen, da IPC-Ringpuffer des LT Backend deterministische Latenzen im aufrufenden Thread gewährleisten.
• Manifest-Konfiguration & Packaging:
  • Integratoren müssen im Execution Manifest pro Prozess die Ziel-Modi deklarieren.
  • Im Machine Manifest müssen Storage-Pfade (LogStorage), maximale Dateigrößen, Rotationsintervalle und Socket-Port-Zuweisungen (Standard DLT: Port 3490) konfliktfrei konfiguriert werden.
• Security & Traceability:
  • Externe Netzwerkanbindung (Network – LT Log Viewer) erfordert auf Produktions-ECUs restriktive Zugriffskontrollen (z. B. Authentifizierung/TLS oder Deaktivierung des Remote-Loggings über UDS/Diagnostic Service bzw. Machine-State-Management), um das Ausleiten sensibler Laufzeitdaten über offene Diagnose-Ports zu verhindern.