Figure 5.2: Interfaces required by Log and Trace from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Architekturmodell).
• Architektur-Kontext: AUTOSAR Adaptive Platform R23-11, Spezifikation AUTOSAR_AP_SWS_LogAndTrace (Kapitel 5.2 Required Interfaces).
• Technischer Zweck: Spezifiziert die normativen und plattforminternen Abhängigkeiten des Functional Clusters (FC) Log and Trace gegenüber anderen Komponenten der Adaptive Platform und dem Basisbetriebssystem:
  • Bezug hochpräziser, global synchronisierter Zeitstempel für DLT-Logging-Pakete (Diagnostic Log and Trace).
  • Socket-basierter Export von DLT-Streams an externe Clients/Tester über das Netzwerk.
  • Lokale Persistierung von Trace- und Log-Puffern in nicht-flüchtigen Speichern.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Functional Clusters

• «aapFunctionalCluster» Log and Trace: Konsumenten-Cluster; aggregiert, filtert und serialisiert standardisierte Log-Meldungen von Applikationen und Plattform-Clustern.
• «aapFunctionalCluster» Time Synchronization (mit Annotation daemon-based): Stellt über einen Hintergrunddienst (Daemon) synchronisierte Zeitbasen (z. B. IEEE 802.1AS / gPTP) bereit.
• Operating System: Host-Betriebssystem (POSIX PSE51/52/53-kompatibel), welches grundlegende System- und I/O-Dienste bereitstellt.

Schnittstellen & Stereotypen

• «aapAPI,aapPortInterface» Time Synchronization::SynchronizedTimeBaseConsumer:
  • Normative Schnittstelle des Required Ports («aapRequiredPort») von Log and Trace.
  • Synchrone Methoden:
    • + GetRateDeviation()
    • + GetTimeWithStatus(): SynchronizedTimeBaseStatus
  • Asynchrone Registrierungen / Deregistrierungen:
    • + RegisterStatusChangeNotifier() / + UnregisterStatusChangeNotifier()
    • + RegisterSynchronizationStateChangeNotifier() / + UnregisterSynchronizationStateChangeNotifier()
    • + RegisterTimeLeapNotifier() / + UnregisterTimeLeapNotifier()
    • + RegisterTimePrecisionMeasurementNotifier() / + UnregisterTimePrecisionMeasurementNotifier()
    • + RegisterTimeValidationNotification() / + UnregisterTimeValidationNotification()
• «aapInternal» TCP/IP Stack: Plattform-/OS-interne Netzwerkschnittstelle (Standard-Socket-Interface).
• «aapInternal» Non-volatile Storage: Plattform-/OS-interne Schnittstelle für nicht-flüchtigen Speicher (Dateisystem/Flash-Storage).

Beziehungen

• Log and Trace → SynchronizedTimeBaseConsumer: Abhängigkeitsbeziehung «use» über einen «aapRequiredPort».
• Time Synchronization → SynchronizedTimeBaseConsumer: Realisierungsbeziehung (gestrichelte Linie mit geschlossener Dreiecksspitze).
• Log and Trace → TCP/IP Stack & Non-volatile Storage: Abhängigkeitsbeziehungen «use».
• Operating System → TCP/IP Stack & Non-volatile Storage: Realisierungsbeziehungen des Basisbetriebssystems.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase:
   • Log and Trace bindet den Port SynchronizedTimeBaseConsumer.
   • Registrierung relevanter Notifier (RegisterSynchronizationStateChangeNotifier, RegisterTimeLeapNotifier), um Statusübergänge der Synchronisation oder Sprünge der Zeitbasis (Leaps) asynchron zu erfassen.
2. Laufzeit / Log-Generierung (Synchroner Pfad):
   • Beim Eintreffen eines Log-Events liest Log and Trace synchron via GetTimeWithStatus() den Zeitstempel und dessen Synchronisationsstatus aus.
   • Der Zeitstempel wird in den DLT-Standard-Header eingebettet.
3. Ausnahme-/Drift-Handling (Asynchroner Callback):
   • Tritt ein Zeitsprung auf, feuert der Callback von RegisterTimeLeapNotifier(). Log and Trace aktualisiert intern die Referenzzeit oder vermerkt den Synchronisationsverlust im Metadaten-Stream, um Monotoniebrüche im Trace analysierbar zu machen.
4. Export & Speicherung:
   • DLT-Streams werden über POSIX-Sockets des TCP/IP Stack (UDP/TCP) an externe Logging-Tools gestreamt.
   • Bei konfigurierter lokaler Protokollierung schreibt der DLT-Daemon die Log-Dateien blockweise oder ringgepuffert direkt auf den Non-volatile Storage.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung über Port vs. Intern:
  • Der Zugriff auf Time Synchronization erfolgt streng über das AUTOSAR Adaptive Port-Modell (ara::ts). Dies erfordert ein entsprechendes Service-Deployment und Port-Mapping im ARXML-Manifest.
  • Der Zugriff auf TCP/IP Stack und Non-volatile Storage ist als «aapInternal» deklariert. Dies bedeutet, dass Log and Trace nicht zwingend andere funktionale Cluster wie ara::com oder ara::per nutzt, sondern performanzkritisch direkt über native OS-Sockets und Standard-POSIX-Dateisystemaufrufe arbeiten darf/muss.
• Timing & Performance im Logging-Pfad:
  • GetTimeWithStatus() liegt im direkten Ausführungspfad des Logging-APIs (ara::log). Implementierungen müssen sicherstellen, dass dieser Aufruf atomar, sperrarm (Lock-free/Shared Memory) und ohne Inter-Process-Context-Switches bedient wird, um Logging-Jitter zu minimieren.
• Fallback-Mechanismus bei Synchronisationsverlust:
  • Liefert GetTimeWithStatus() einen ungültigen Status (SynchronizedTimeBaseStatus != SYNC) oder ist der Time Synchronization Daemon noch nicht initialisiert, muss die Implementierung auf eine lokale, monotone OS-Uhr (z. B. CLOCK_MONOTONIC) zurückfallen und das Flag im DLT-Header entsprechend kennzeichnen.
• Plattform- und Prozessrechte:
  • Im POSIX-Prozessmodell müssen dem Log and Trace-Daemon ausreichende Dateisystem-Schreibrechte (Quota für NV-Speicher) sowie Socket-Berechtigungen (z. B. Binden an DLT-Port 3490) über die OS-Access-Control-Konfiguration zugewiesen werden.