Figure 7.2: Example layout of the OS/ara::log Adapter

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Block- und Komponenten-Architekturdiagramm (Funktionale Dekomposition und Datenflussarchitektur).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP Release R23-11), Spezifikation Operating System Interface (AUTOSAR_AP_SWS_OperatingSystemInterface).
• Technischer Zweck: Darstellung des Integrationsmusters zur Erfassung, Übersetzung und Weiterleitung nativer Betriebssystem-Trace-Puffer (POSIX/OS) in die standardisierte Logging- und Tracing-Infrastruktur (ara::log) sowie das AUTOSAR Run-Time Interface (ARTI). Das Diagramm illustriert, wie OS-interne Metriken (Task-/Prozess-Kontextwechsel, Scheduling-Zustände) ohne direkte Kernel-Kopplung an ara::log über einen entkoppelten Adapter-Daemon modelliert und mit Applikations- und Cluster-Logs synchronisiert werden.

2. Komponenten, Entitäten & Schnittstellen

• Domäne OSI (Operating System Interface):
  • POSIX/OS: Low-Level-Betriebssystemschicht (Kernel, POSIX-PSE51-Subset, native Ringpuffer/Trace-Backends wie ftrace, LTTng oder QNX tracelogger).
  • OS/ara::log Adapter: Vermittelnder System-Daemon / Daemon-Prozess. Liest proprietäre OS-Trace-Puffer aus, wandelt diese in standardisierte, modellierte Nachrichten um und fungiert als Brücke zur Adaptive-Middleware.
• Erzeuger-Ebene (Ingress):
  • Application Level (AA): Adaptive Applications im User-Space, die Log-/Trace-Ereignisse über die Standard-C++-API emittieren.
  • System Level (FC): Functional Clusters der Adaptive Platform (z. B. Execution Management, State Management), die Plattform-Events einspeisen.
• Domäne Log- and Trace (Functional Cluster):
  • ara::log API: Standardisierte C++-Frontendschnittstelle für Log- und Trace-Ereignisse.
  • ara::log: Zentraler Logging-Cluster/Daemon zur Filterung, Pufferung und Verteilung eingehender Nachrichtenströme.
  • Standard-Sinks (Egress):
    • DLT: Diagnostic Log and Trace (Protokoll-/Netzwerk-Export an DLT-Dämon/Testsysteme).
    • Console: Standard-Ausgabe (stdout/stderr).
    • File: Persistenter Dateisystem-Sink.
  • ara::log/ARTI API (TraceArti): Brückenschnittstelle zur Weiterleitung selektierter Trace-Meldungen in die ARTI-Toolkette.
• Domäne Trace Tool:
  • ARTI (light weight C API): AUTOSAR Run-Time Interface C-API. Bietet eine latenzarme, minimal-invasive Schnittstelle zur Anbindung externer Hardware- oder Software-Trace-Werkzeuge (z. B. Lauterbach, Timing-Analysatoren).

3. Dynamisches Verhalten & Sequenzablauf

1. Trace-Generierung im Kernel/OS: Das Basissystem (POSIX/OS) zeichnet Scheduler-Events, Thread-Erzeugungen, Kontextwechsel und Signal-Ereignisse in internen Trace-Puffern auf.
2. Puffer-Auslesen & Modellierung: Der OS/ara::log Adapter fragt die OS-Trace-Puffer ab (Event-gesteuert via Netlink/Interrupts oder zyklisch gepuffert). Er serialisiert die Rohdaten in formatierte Modeled Messages (inkl. Initialzustandsabbildung via OsProcessInfo und OsTaskInfo).
3. Ingestion über ara::log API: Der Adapter sendet die Nachrichten über den Standard-Pfad der ara::log API ein (roter Signalpfad), gleichrangig zu Meldungen aus AA und FC.
4. Multiplexing & Distribution:
   • ara::log verarbeitet die Nachrichtenströme anhand der konfigurierten Filter- und Severity-Regeln.
   • Standardausgabe: Parallelisierung auf die konfigurierten Senken DLT, Console und File.
5. ARTI-Weiterleitung & External Trace:
   • Trace-spezifische Nachrichten werden synchron oder entkoppelt über ara::log/ARTI API (TraceArti) in die ARTI (light weight C API) übergeben.
   • ARTI emittiert die Daten minimal-invasiv (z. B. über Hardware-Trace-Ports wie ETM/AURORA oder Shared Memory) an das externe Analyse-Tool.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Referenzen: RS_OSI_00211, SWS_OSI_10100.
• Prozess- und Task-Metadaten (SWS_OSI_10100): Beim Aktivieren des OS-Tracings muss der OS/ara::log Adapter zwingend den aktuellen Initialzustand aller bereits laufenden Tasks und Prozesse mittels OsProcessInfo- und OsTaskInfo-Nachrichten loggen. Ohne diese Initialisierung können nachfolgende Thread-IDs und PIDs zur Laufzeit nicht den realen Executables zugeordnet werden.
• Echtzeit- und Puffer-Design:
  • Der OS/ara::log Adapter darf das Kernel-Laufzeitverhalten nicht blockieren. Es sind Lock-free-Queue-Mechanismen bzw. Ringspeicher zwischen OS-Puffer und Adapter vorzusehen.
  • Tritt ein Pufferüberlauf im OS-Trace auf, muss der Adapter dies detektieren und als Discontinuitäts-Marker einspeisen, um fehlerhafte Timing-Analysen in ARTI zu verhindern.
• Entkopplung & Architektur-Freiheit:
  • Die OS-Schicht benötigt keine C++14/17-Runtime oder Abhängigkeiten zu ara::core / ara::log.
  • Das Versenden modellierter Nachrichten kann architektonisch an einen separaten Functional Cluster delegiert werden, falls OSI im konkreten System keinen permanenten Runtime-Daemon besitzt.
• Tool-Synchronisation: Die Kombination aus ara::log und ARTI über TraceArti erlaubt es externen Timing-Werkzeugen, Anwendungs-Events (AA), System-Events (FC) und Low-Level-OS-Scheduling-Metriken auf einer gemeinsamen Zeitbasis korreliert darzustellen.