Modul ara::log — Log and Trace

Das funktionale Cluster Log and Trace stellt die zentrale Infrastruktur für die Protokollierung und Ablaufverfolgung auf der AUTOSAR Adaptive Platform bereit AUTOSAR AP SWS LogAndTrace S. 13. Anwendungen und Plattform-Daemons erstellen Protokollnachrichten flexibel über typsichere Datenströme oder über hocheffiziente modellierte Funktionsaufrufe mit minimalem Prüf-Overhead [SWS_LOG_00204]. Die Nachrichtenfilterung erfolgt über konfigurierbare Detaillierungsgrade je Kontext, während die Weiterleitung an das DLT-Backend, ARTI-Werkzeuge oder die lokale Konsole erfolgt [SWS_LOG_00021].

mehr ›

Das funktionale Cluster Log and Trace (ara::log) stellt die universelle Basisinfrastruktur für strukturierte Protokollierung, Diagnoseausgaben und hardwarenahe Ablaufverfolgung in der AUTOSAR Adaptive Platform dar AUTOSAR AP SWS LogAndTrace S. 13. Jede Logger-Instanz repräsentiert einen eigenen Kontext innerhalb eines Prozesses und registriert sich bei ihrer Entstehung automatisch am zentralen Logging-Backend EXP SWArchitecture S. 57. Neben Applikationen binden auch grundlegende Plattformdienste wie Execution Management, Platform Health Management und Persistency die Logger-Schnittstelle verbindlich zur Betriebsdokumentation ein AUTOSAR AP EXP SWArchitecture S. 58.

Kontextdiagramm: Einbettung des Clusters Log and Trace als zentrale Protokollierungs- und Tracing-Infrastruktur für adaptive Anwendungen und funktionale Plattform-Cluster. Quellen: AUTOSAR AP SWS LogAndTrace S. 13, AUTOSAR AP EXP SWArchitecture S. 58, SWS LogAndTrace S. 21, AUTOSAR AP SWS OperatingSystemInterface S. 21

Das Modul differenziert zwischen zwei grundlegenden Interaktionsformen:

• Unmodellierte Protokollierung: Ein Fluent-Builder-Muster erzeugt über schweregradbezogene Methoden (wie LogInfo() oder LogError()) ein temporäres LogStream-Objekt, das skalare Typen, Zeichenketten, Fehlercodes und Format-Modifikatoren typsicher verkettet und den Puffer spätestens im Destruktor oder über Flush() übermittelt [SWS_LOG_00067], [SWS_LOG_00039], [SWS_LOG_00262].
• Modellierte Protokollierung: Über die Single-Call-Schnittstelle Logger::Log(id, args...) werden vorab im Manifest deklarierte Nachrichten abgesetzt, was bei inaktivem Schwellwert eine hocheffiziente Ausfilterung ohne Objektinstanziierung ermöglicht [SWS_LOG_00204], PlatformDesign S. 74.

Sequenzdiagramm: Ablauf der unmodellierten Stream-Protokollierung über LogStream bis zur Pufferübermittlung an das Logging-Backend. Quellen: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign S. 74

Zur Vermeidung unnötiger Rechenzeit lässt sich das aktive Meldeniveau vorab mittels IsEnabled(logLevel) verifizieren oder zur Laufzeit via SetThreshold(threshold) anpassen [SWS_LOG_00070], [SWS_LOG_00255]. Neben der Weiterleitung an DLT-Kanäle über Ethernet oder an ARTI-Werkzeuge fungiert bei fehlender Modellkonfiguration die Konsole als Ausfallsicherung [SWS_LOG_00021], während der externe Diagnose-Verbindungsstatus über RegisterConnectionStateHandler asynchron überwacht werden kann [SWS_LOG_00098], [SWS_LOG_00205].

mehr ›

Systemarchitektur und funktionale Rolle von Log and Trace

Das funktionale Cluster Log and Trace (ara::log) bildet das zentrale, querschnittliche Subsystem für die standardisierte Erfassung, Weiterleitung und Filterung von Diagnose-, Tracing- und Protokollmeldungen auf der AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace S. 13. Die Programmierschnittstelle Logger stellt die einheitliche C++-Plattform-API bereit, welche sowohl von anwendungsspezifischen Prozessen (Adaptive Applications) als auch von den grundlegenden funktionalen Plattform-Clustern als Basisinfrastruktur konsumiert wird AUTOSAR AP EXP SWArchitecture S. 58. Zu diesen konsumierenden System-Daemons gehören unter anderem das Execution Management zur Prozesslebenszyklus-Dokumentation AUTOSAR AP EXP SWArchitecture S. 50, das Platform Health Management zur Zustandsüberwachung AUTOSAR AP SWS PlatformHealthManagement S. 16, Time Synchronization für hochpräzise Zeitbezüge AUTOSAR AP SWS TimeSynchronization S. 17 sowie das Update and Configuration Management während Software-Aktualisierungen AUTOSAR AP EXP SWArchitecture S. 141.

Architektonisch kapselt jede Logger-Instanz einen eindeutigen Kontext (Context ID) innerhalb eines Anwendungs- oder Prozessbereichs, wobei sich dieser Kontext bei der Erzeugung selbsttätig beim Logging-Backend registriert und beim Herunterfahren der Anwendung automatisch deregistriert wird EXP SWArchitecture S. 57. Das Logging-Backend leitet formatierte Meldungen an projektierte Ausgabekanäle (z. B. DLT-Protokollsenken über Ethernet gemäß Machine-Manifest) oder an lokale Puffer weiter, wobei bei fehlendem Bereitstellungsmodell standardmäßig auf die Betriebssystem-Konsole zurückgegriffen wird [SWS_LOG_00021], SWS LogAndTrace S. 21. Darüber hinaus gestattet eine entkoppelte Adapter-Architektur dem Betriebssystem (POSIX/OS), interne Kernel- und Scheduling-Metriken über das AUTOSAR Run-Time Interface (ARTI) synchronisiert mit den Meldungen von ara::log bereitzustellen AUTOSAR AP SWS OperatingSystemInterface S. 21.

Kontextdiagramm: Einbettung des Clusters Log and Trace als zentrale Protokollierungs- und Tracing-Infrastruktur für adaptive Anwendungen und funktionale Plattform-Cluster. Quellen: AUTOSAR AP SWS LogAndTrace S. 13, AUTOSAR AP EXP SWArchitecture S. 58, SWS LogAndTrace S. 21, AUTOSAR AP SWS OperatingSystemInterface S. 21

Instanziierung, Kontextverwaltung und Schwellwertsteuerung

Die Bereitstellung eines Logger-Kontexts erfolgt über die Fabrikfunktionen ara::log::CreateLogger, da der Standardkonstruktor der Klasse Logger gelöscht ist [SWS_LOG_00259]. Anwendungen können Logger entweder programmatisch unter Angabe einer Kontext-ID (ctxId), einer Beschreibung (ctxDescription) und optional eines Standard-Loglevels instanziieren [SWS_LOG_00021], [SWS_LOG_00263], oder instanzbasiert über ein Modell-Element mittels ara::core::InstanceSpecifier ableiten [SWS_LOG_00256]. Der Zerstörer von Logger wickelt die Entregistrierung thread-sicher ab [SWS_LOG_00260].

Die Granularität und Priorität von Meldungen wird durch die Aufzählung LogLevel hierarchisch abgebildet: kFatal (nicht behebbarer Systemfehler), kError (Fehler mit Funktionsbeeinträchtigung), kWarn (Warnung bei gefährdetem Sollverhalten), kInfo (allgemeine Betriebsinformation), kDebug (Detaildiagnose) und kVerbose (ausführliche Ablaufverfolgung) [SWS_LOG_00018], ManifestSpecification S. 416. Zur Laufzeitoptimierung können rechenintensive Vorbereitungen von Protokolldaten vermieden werden, indem vorab über die Abfrage IsEnabled(logLevel) geprüft wird, ob das betreffende Loglevel am Kontext aktuell aktiv geschaltet ist [SWS_LOG_00070]. Der aktive Meldeschwellwert einer Logger-Instanz lässt sich bei Bedarf zur Laufzeit über SetThreshold(threshold) dynamisch anpassen [SWS_LOG_00255].

Unmodellierte Protokollierung und Stream-basierte Nachrichtenkomposition

Für unmodellierte Meldungen stellt ara::log ein an das Builder-Entwurfsmuster angelehntes Fluent-Interface bereit PlatformDesign S. 74. Der Einstieg erfolgt über Schweregrad-spezifische Elementfunktionen der Logger-Instanz, namentlich LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug() und LogVerbose(), oder über WithLevel(logLevel), welche ein temporäres, leichtgewichtiges LogStream-Objekt zurückgeben [SWS_LOG_00064], [SWS_LOG_00065], [SWS_LOG_00066], [SWS_LOG_00067], [SWS_LOG_00068], [SWS_LOG_00069], [SWS_LOG_00131]. Daten werden anschließend über den typsicheren Stream-Einfügeoperator (operator<<) verkettet an den internen Nachrichtenpuffer angehängt [SWS_LOG_00040].

Die Stream-Schnittstelle unterstützt eine breite Palette nativer C++- und AUTOSAR-Typen ohne manuelle Formatierungsfehler:

• Ganzzahlige Typen (vorzeichenbehaftet und vorzeichenlos von 8 bis 64 Bit) sowie boolesche Werte [SWS_LOG_00040], [SWS_LOG_00041], [SWS_LOG_00042], [SWS_LOG_00043], [SWS_LOG_00044], [SWS_LOG_00045], [SWS_LOG_00046], [SWS_LOG_00047], [SWS_LOG_00048].
• Gleitkommatypen einfacher und doppelter Genauigkeit (float, double) [SWS_LOG_00049], [SWS_LOG_00050].
• Nullterminierte UTF-8-Zeichenketten und ara::core::StringView [SWS_LOG_00051], [SWS_LOG_00062].
• Spezifische Plattformtypen wie LogLevel in Textform [SWS_LOG_00063], Fehlerobjekte ara::core::ErrorCode [SWS_LOG_00124], Zeitspannen std::chrono::duration [SWS_LOG_00125], Modellreferenzen ara::core::InstanceSpecifier [SWS_LOG_00126], Rohzeiger [SWS_LOG_00127] und Byte-Sequenzen via ara::core::Span<const ara::core::Byte> [SWS_LOG_00128].

Metadaten und Formatierungen lassen sich präzise steuern: Über WithLocation(file, line) wird der Quellcode-Ursprung erfasst [SWS_LOG_00129], WithTag(tag) ergänzt funktionale Schlagworte [SWS_LOG_00132], und WithPrivacy(value) legt eine Vertraulichkeitsstufe über die untersten 8 Bit fest [SWS_LOG_00258]. Formatierte Argumente mit Name und physikalischer Einheit werden über das Hilfstemplate Arg gekapselt [SWS_LOG_00201], [SWS_LOG_00203], unterstützt durch die Formatierungshilfen Dflt, Hex, Dec, Oct, Bin, DecFloat, EngFloat, HexFloat und AutoFloat aus der Aufzählung Fmt [SWS_LOG_00206], [SWS_LOG_00208], [SWS_LOG_00209], [SWS_LOG_00211], [SWS_LOG_00217], [SWS_LOG_00225], [SWS_LOG_00226].

Hinsichtlich des Lebenszyklus ist LogStream ein Move-only-Objekt: Kopierkonstruktor und Kopierzuweisungsoperator sind gelöscht [SWS_LOG_00174], [SWS_LOG_00175], während der Move-Konstruktor zur Unterstützung der Return Value Optimization (RVO) deklariert ist [SWS_LOG_00176]; der Move-Zuweisungsoperator ist gelöscht [SWS_LOG_00177]. Der Pufferinhalt wird beim Verlassen des Gültigkeitsbereichs automatisch über den Zerstörer ~LogStream() an das Logging-Framework gesendet [SWS_LOG_00262]. Soll ein LogStream-Objekt innerhalb desselben Gültigkeitsbereichs für mehrere Meldungen nacheinander genutzt werden, muss die Pufferübertragung explizit via Flush() ausgelöst werden, wodurch ein frischer Meldungsstrom initialisiert wird [SWS_LOG_00039]. Interpretation: Die interne Pufferverwaltung von LogStream dürfte nach Aufruf von Flush() den Puffer für nachfolgende Streaming-Operatoren im selben Gültigkeitsbereich leeren und neu initialisieren, ohne dass eine Zerstörung der Objektidentität erforderlich ist. Frage Q-17b076f8fd54e421 (offen)

Sequenzdiagramm: Ablauf der unmodellierten Stream-Protokollierung über LogStream bis zur Pufferübermittlung an das Logging-Backend. Quellen: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign S. 74

Modellierte Protokollierung und Verzweigung zu ARTI-Tracing

Im Gegensatz zum stufenweisen Aufbau unmodellierter Nachrichten definiert ara::log für im Manifest modellierte Nachrichten eine hocheffiziente Single-Call-Schnittstelle über Logger::Log(id, args...) sowie Logger::LogWith(attrs, msgId, params...) [SWS_LOG_00204], [SWS_LOG_00133]. Alle Argumente werden in einem einzigen Funktionsaufruf übergeben, wodurch der Laufzeit-Overhead im Falle unterdrückter Meldungen auf ein Minimum reduziert wird: Direkt nach Parameterübergabe prüft eine einzelne Bedingung den Schwellwert und kehrt sofort zurück, falls das konfigurierte Loglevel nicht erreicht ist PlatformDesign S. 74.

Innerhalb des Aufrufs von Log spaltet sich der Verarbeitungspfad auf: Neben dem klassischen Pfad der DLT-Serialisierung (buildDltMessage(), Filterung via Logmaske und Übergabe an die Senke) existiert ein dedizierter Pfad zur hardwarenahen Ablaufverfolgung über das AUTOSAR Run-Time Interface (ARTI) mittels TraceArti(msg_id, params...) [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace S. 42. Vermutlich wird die Weiterschaltung an TraceArti über statische Template-Spezialisierungen zur Übersetzungszeit aufgelöst, um den geforderten minimalen Laufzeit-Overhead sicherzustellen. Frage (offen) Das ARTI-Backend filtert nach eigenen Kriterien basierend auf der MsgId und umgeht die DLT-Pufferung vollständig, was echtzeitkritisches Tracing ohne Störung des regulären Logging-Subsystems gestattet AUTOSAR AP SWS LogAndTrace S. 42.

Aktivitätsdiagramm: Kontroll- und Filterfluss beim Absetzen modellierter Nachrichten zwischen DLT-Backend und ARTI-Tracing. Quellen: [SWS_LOG_00204], [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace S. 42, PlatformDesign S. 74

Client-Verbindungsüberwachung und Diagnoseanbindung

Log and Trace stellt nicht nur lokale Ausgabekanäle bereit, sondern überwacht auch den Zustand externer Diagnose-Clients (z. B. DLT-Viewer über Ethernet), repräsentiert durch die Aufzählung ClientState: kUnknown (-1, DLT-Backend noch nicht bereit), kNotConnected (kein entfernter Client erkannt) und kConnected (Verbindung zu externem Client aktiv) [SWS_LOG_00098]. Dies erlaubt Anwendungen, aufwendiges Tracing an die physische Anwesenheit eines Analysetools zu koppeln.

Zur asynchronen Zustandsverfolgung registrieren Anwendungen eine Rückruffunktion über ara::log::RegisterConnectionStateHandler unter Verwendung des Funktionsaliasing ConnectionStateHandler = std::function<void(ClientState)> [SWS_LOG_00205], [SWS_LOG_00265]. Das Logging-Framework unterstützt hierbei exakt eine aktive Handler-Registrierung: Ein erneuter Aufruf von RegisterConnectionStateHandler überschreibt einen zuvor installierten Callback uneingeschränkt [SWS_LOG_00205].

Zustandsdiagramm: Zustandsübergänge des externen Clients gemäß ClientState. Quellen: [SWS_LOG_00098], [SWS_LOG_00205], [SWS_LOG_00265]

Verhalten im Fehlerfall

Das Modul erzwingt funktionale Sicherheit und Robustheit primär durch statische Typprüfungen zur Übersetzungszeit und strikte Ausnahmegarantien:

• Übersetzungszeitfehler (ill-formed): Der Aufruf von Logger::Log(id, args...) ist unzulässig (ill-formed), wenn die übergebenen Argumente nicht exakt mit der im Manifest deklarierten Nachrichtensignatur übereinstimmen [SWS_LOG_00204]. Ebenso führt die Verwendung von Arg() mit Typen, die weder arithmetisch noch boolesch oder zu StringView bzw. Span<const Byte> konvertierbar sind, zu einem Übersetzungsabbruch [SWS_LOG_00201]. Die Funktion WithPrivacy(value) erzwingt zudem, dass der Parametertyp ein ganzzahliger Typ oder eine Aufzählung ist [SWS_LOG_00258].
• Konstruktions- und Zuweisungsverbote: Um unbeabsichtigte Pufferduplizierungen oder Ressourcenkonflikte auszuschließen, sind Kopierkonstruktor und Kopierzuweisungsoperator von LogStream sowie der Move-Zuweisungsoperator explizit gelöscht [SWS_LOG_00174], [SWS_LOG_00175], [SWS_LOG_00177].
• Laufzeitintegrität bei Instanziierung: Schlägt die Auflösung des ara::core::InstanceSpecifier im Maschinen- oder Anwendungsmodell bei CreateLogger(is) fehl oder verweist dieser nicht auf ein zulässiges Modellelement, meldet das System eine InstanceSpecifierMappingIntegrityViolation [SWS_LOG_00256].
• Ausfallsichere Fallback-Senken: Steht zur Laufzeit kein Bereitstellungsmodell oder keine Netzwerkanbindung zum DLT-Dienst bereit, wechselt das Framework automatisch auf die lokale Konsole als Standard-Ausgabesenke, sodass keine Diagnoseinformationen lautlos verloren gehen [SWS_LOG_00021], [SWS_LOG_00263]. Bei Ausgabe eines core::ErrorCode auf der Konsole erfolgt die Darstellung über den Domänennamen und den numerischen Fehlerwert [SWS_LOG_00124].
• Exception-Sicherheit: Sämtliche Streaming-Operatoren, Schwellwertabfragen und der Destruktor ~LogStream() sind als noexcept deklariert, um sicherzustellen, dass die Protokollierung zu keinem Zeitpunkt unbehandelte Ausnahmen in anwendende Funktionsblöcke propagiert [SWS_LOG_00040], [SWS_LOG_00070], [SWS_LOG_00262]; der Zerstörer ~Logger() ist hingegen formal nicht als noexcept spezifiziert [SWS_LOG_00260].

Weiterführende Detailbelege

Die Architektur und das Verhalten des Moduls Log and Trace sind in folgenden Referenzstellen der AUTOSAR-Spezifikation verankert:

• Cluster-Schnittstellenspezifikation: Die normativen C++-Signaturen, Stream-Operatoren und Kontextmethoden von Logger und LogStream sind in der Spezifikation von Log and Trace definiert [SWS_LOG_00021], [SWS_LOG_00039], [SWS_LOG_00064], [SWS_LOG_00204], AUTOSAR AP SWS LogAndTrace S. 13.
• Plattformdesign und Performance: Der architektonische Vergleich zwischen Builder-Muster und hocheffizientem Single-Call-Aufruf für modellierte Nachrichten wird im Platform Design dargelegt PlatformDesign S. 74.
• Plattformweite Abhängigkeiten: Die verbindliche Nutzung der Logger-Schnittstelle durch funktionale Plattform-Cluster wird in den jeweiligen Architekturdokumenten geführt AUTOSAR AP EXP SWArchitecture S. 58, AUTOSAR AP EXP SWArchitecture S. 50, AUTOSAR AP SWS PlatformHealthManagement S. 16.
• Manifest- und Bereitstellungsmodell: Die Konfiguration von DLT-Logkanälen, Prozesszuordnungen und Maschinen-Endpunkten ist in der Manifest-Spezifikation geregelt SWS LogAndTrace S. 21, ManifestSpecification S. 416.
• Betriebssystem-Adapter und ARTI: Die Anbindung nativer Betriebssystem-Tracepuffer an ara::log und die hardwarenahe Erfassung über TraceArti sind in der OSI- und Trace-Architektur spezifiziert [SWS_LOG_20000], AUTOSAR AP SWS OperatingSystemInterface S. 21, AUTOSAR AP SWS LogAndTrace S. 42.