Figure 5.1: Interfaces provided by Log and Trace to other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Architektur-Abhängigkeitsdiagramm (Component & Interface Dependency Diagram) gemäß AUTOSAR-Metamodell für die Adaptive Platform (AP).
• Technischer Zweck: Spezifikation der durch den Functional Cluster (FC) Log and Trace bereitgestellten nativen Programmierschnittstelle (Logger) und deren querschnittlicher Abhängigkeiten («use») zu allen übrigen Standard-Functional-Clustern der AUTOSAR Adaptive Platform (Release R23-11, Kapitel 5.1).
• Systemeinordnung: Log and Trace stellt das fundamentale Diagnose-, Tracing- und Protokollierungs-Rückgrat (ara::log) für Plattform-Daemons und Bibliotheken bereit, typischerweise mit Anbindung an das DLT-Protokoll (Diagnostic Log and Trace).

2. Komponenten, Entitäten & Schnittstellen

• Bereitgestellte Schnittstelle:
  • «aapAPI, aapNativeInterface» Logger: Zentrale C++ Abstraktion (ara::log::Logger) zur strukturierten und unstrukturierten Protokollierung.
    • + IsEnabled(): Abfrage des aktiven Log-Zustands zur Vermeidung unnötiger Formatierungs-Overheads.
    • + Log(MsgId, Params): Direktes, ID-basiertes Logging für formatfreie oder vorkompilierte DLT-Nachrichten.
    • + LogDebug(): LogStream, + LogError(): LogStream, + LogFatal(): LogStream, + LogInfo(): LogStream, + LogVerbose(): LogStream, + LogWarn(): LogStream: Severity-spezifische Factory-Methoden zur Erzeugung typsicherer Streaming-Objekte (ara::log::LogStream).
    • + WithLevel(): LogStream: Dynamische Festlegung des Log-Levels zur Laufzeit.
• Realisierende Komponente:
  • «aapFunctionalCluster» Log and Trace: Implementiert das Logger-Interface (Realization-Pfeil mit geschlossener, nicht ausgefüllter Spitze).
• Konsumierende Functional Clusters («use»-Beziehung):
  • Daemon-basierte Cluster (daemon-based):
    • Execution Management (Prozesslebenszyklus, POSIX-Initialisierung)
    • State Management (Systemzustandssteuerung)
    • Diagnostic Management (UDS/DoIP-Stack)
    • Platform Health Management (Watchdog, Alive-/Deadline-Supervision)
    • Time Synchronization (gPTP / IEEE 802.1AS)
    • Intrusion Detection System Manager (Security Event Logging)
    • Communication Management (Service-Oriented Communication via SOME/IP, IPC)
    • Vehicle Update and Configuration Management (Fahrzeugweite Update-Orchestrierung)
    • Update and Configuration Management (Lokales Software-Package-Handling)
  • Bibliotheks-/Nicht-Daemon-basierte Cluster:
    • Network Management (Partielle Netzwerke, State Handling)
    • Persistency (Flash/EEPROM File & Key-Value Storage)

3. Dynamisches Verhalten & Sequenzablauf

• Synchroner Aufrufkontext: Der aufrufende Functional Cluster instanziiert oder referenziert thread-lokal ein Logger-Objekt (gebunden an Application-ID/Context-ID).
• Filterung & Stream-Generierung:
  1. Interner oder expliziter Check via IsEnabled() gegen den aktuell konfigurierten Log-Level.
  2. Bei Freigabe Erzeugung des temporären LogStream-Objekts (Stack-basiert).
  3. Formatierung/Serialisierung der Parameter über den überladenen Shift-Operator operator<<.
• Asynchroner Flush & IPC:
  • Mit Zerstörung des temporären LogStream-Objekts am Ende des Full-Expressions (RAII) erfolgt die Commit-Operation.
  • Übergabe der Nachricht an den lokalen Puffer bzw. Shared-Memory-Ringpuffer.
  • Der Log and Trace-Hintergrund-Daemon holt die Daten asynchron ab und routet sie über Netzwerk (DLT over IP) oder UART, ohne den Aufrufer-Thread zu blockieren.

4. Normative Relevanz & Entwickler-Hinweise

• Nicht-blockierendes Verhalten (Real-Time Safety): Da echtzeitkritische Cluster wie Platform Health Management und Time Synchronization denselben Logger nutzen, darf das Logging unter keinen Umständen blockieren (Zero-Allocation-Policy im Hot-Path, strikte Trennung von Erfassung und serialisiertem I/O-Transport).
• Bootstrap-Dilemma & Early Logging:
  • Execution Management startet als erster Plattform-Daemon und muss bereits loggen können, bevor der Log and Trace-Daemon betriebsbereit ist.
  • Treiber- und Stack-Entwickler müssen einen Ringpuffer-Fallback (Local Buffer) für Plattform-Starts vorsehen, der nach Initialisierung von Log and Trace geleert wird.
• Reentrancy & Thread-Safety: Alle Methoden der Logger-Schnittstelle müssen reentrant und threadsicher implementiert sein, da Cluster wie Communication Management massiv nebenläufig agieren.
• Traceability & ASIL-Einstufung: Wenn Security- (IDSM) oder Safety-relevante (PHM) Cluster über Logger auditieren, müssen Datenverluste bei Pufferüberläufen (Buffer Overflow / Message Drop Counters) normativ erfasst und meldbar sein.