Figure 9.18: Interfaces required by LogAndTrace

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Schnittstellendiagramm (AUTOSAR Adaptive Platform Profil mit stereotypspezifischen Abhängigkeiten und Port-Schnittstellen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R21-11), Spezifikation AUTOSAR_EXP_SWArchitecture.
• Funktionaler Zweck: Modellierung der externen Abhängigkeiten und benötigten Schnittstellen (Required Interfaces) des Functional Clusters Log and Trace (ara::log) gegenüber anderen Plattform-Instanzen:
  • Hochpräzise Zeitstempelung von Log-Ereignissen über den Functional Cluster Time Synchronization (ara::tsync).
  • Netzwerkübertragung von DLT-Frames (Diagnostic Log and Trace) via TCP/IP Stack.
  • Persistierung lokaler Trace-/Log-Daten über Non-volatile Storage (Flash/Dateisystem).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Komponenten

• «aapFunctionalCluster» Log and Trace: Adaptive Core Functional Cluster (Dienstnutzer). Verantwortlich für Logging, Tracing, Filterung und Formatierung von Applikations- und Plattform-Meldungen.
• «aapFunctionalCluster» Time Synchronization (daemon-based): Anbieter hochgenauer, netzwerksynchronisierter Zeitbasen (z. B. IEEE 802.1AS / PTP, CAN-TSyn).
• Operating System: POSIX-konformes Host-Betriebssystem als Basisplattform.

Schnittstellen & Ports

• «aapAPI,aapPortInterface» Time Synchronization::SynchronizedTimeBaseConsumer:
  • Stereotyp: Standardisierte AUTOSAR Adaptive C++ API und Port-Schnittstelle.
  • Methoden/Operationen:
    • Polling & Zustandsabfrage:
      • + GetCurrentTime()
      • + GetRateDeviation()
      • + GetTimeWithStatus(): SynchronizedTimeBaseStatus
    • Asynchrone Notifier-Registrierung (Callbacks / Event-Subscriptions):
      • + RegisterStatusChangeNotifier() / + UnregisterStatusChangeNotifier()
      • + RegisterSynchronizationStateChangeNotifier() / + UnregisterSynchronizationStateChangeNotifier()
      • + RegisterTimeLeapNotifier() / + UnregisterTimeLeapNotifier()
      • + RegisterTimePrecisionMeasurementNotifier() / + UnregisterTimePrecisionMeasurementNotifier()
      • + RegisterTimeValidationNotification() / + UnregisterTimeValidationNotification()
• «aapInternal» TCP/IP Stack:
  • Betriebssystem-interne Netzwerkschnittstelle (Sockets/POSIX OS API) für Transportprotokolle (TCP/UDP) zur externen DLT-Kommunikation.
• «aapInternal» Non-volatile Storage:
  • Dateisystem- oder persistente Blocktreiber-Schnittstelle des Host-OS zur Speicherung nichtflüchtiger Log-Puffer (NVRAM/Storage).

Beziehungen & Abhängigkeiten

• Log and Trace → SynchronizedTimeBaseConsumer: Abhängigkeit «use» über Port-Rolle «aapRequiredPort».
• Time Synchronization → SynchronizedTimeBaseConsumer: Realisierung (InterfaceRealization, gestrichelte Pfeillinie mit geschlossener, weißer Dreiecksspitze). Der Daemon implementiert den Service-Vertrag.
• Log and Trace → TCP/IP Stack: Abhängigkeit «use» (Nutzung der OS-Transportprotokolle).
• Log and Trace → Non-volatile Storage: Abhängigkeit «use» (Nutzung von Persistenzmechanismen).
• Operating System → TCP/IP Stack & Non-volatile Storage: Realisierungs-/Generalisierungsbeziehungen; OS stellt diese Stacks als plattforminterne Dienste bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Registrierung:
   • Beim Hochfahren bindet sich Log and Trace an den Port SynchronizedTimeBaseConsumer.
   • Registrierung von Event-Handlern (RegisterStatusChangeNotifier, RegisterTimeLeapNotifier, RegisterSynchronizationStateChangeNotifier), um Taktsprünge (Time Leaps) und Statusänderungen der Synchronisation zu überwachen.
2. Laufzeit - Zeitstempelung (Synchroner Pfad):
   • Bei jedem Log-Ereignis ruft der Log-Dienst synchron GetCurrentTime() bzw. GetTimeWithStatus() ab, um den DLT-Nachrichten-Header mit einem netzwerkweit korrelierten Zeitstempel zu versehen.
3. Laufzeit - Asynchrone Benachrichtigung bei Zeitsprüngen:
   • Ändert sich der Status der Zeitbasis (z. B. Synchronisation verloren oder Zeitkorrektur erfolgt), triggert der Time-Sync-Daemon den registrierten Callback. Log and Trace annotiert nachfolgende Logs entsprechend oder setzt interne Sequenz-Flags.
4. Log-Ausgabe & Persistierung:
   • Online-Tracing: Formatierte Log-Pakete werden über den TCP/IP Stack (Socket-Write) an ein externes Analysewerkzeug gestreamt.
   • Offline-/Crash-Logging: Tritt ein Pufferüberlauf oder Shutdown auf, werden Logs über Non-volatile Storage synchron/asynchron in den persistenten Speicher gespiegelt.

4. Normative Relevanz & Entwickler-Hinweise

• Deterministisches Logging & Zeitkorrelation: Entwickler müssen sicherstellen, dass ara::log erst dann global gültige Zeitstempel garantiert, wenn SynchronizedTimeBaseStatus den Zustand kSynchronized meldet. Vor der Synchronisation fallen Zeitstempel auf lokale monotonic OS-Ticks zurück.
• Nicht-blockierende Aufrufe: Das Auslesen der Zeit (GetCurrentTime()) im Log-Pfad liegt im kritischen Pfad von Applikations-Threads. Der Aufruf muss Lock-free bzw. minimal-invasiv (z. B. via Shared Memory / vDSO-Mechanismen des Daemons) ausgeführt werden, um Jitter in Anwendungs-Threads zu vermeiden.
• Abgrenzung Standard-API vs. Platform Internal:
  • Time Synchronization wird über standardisierte ARA-Ports angesprochen (ara::tsync).
  • TCP/IP und Non-volatile Storage sind als «aapInternal» klassifiziert: Log and Trace greift hierfür im klassischen Integrationsszenario direkt auf OS-Level-APIs (BSD-Sockets, POSIX-Dateisystemaufrufe) zurück, anstelle von ara::com oder dem vollwertigen ara::per (Persistency Cluster), um zirkuläre Abhängigkeiten während des Plattform-Bootstrappings zu verhindern.
• Leap-Handling (Zeitsprünge): Bei Nutzung von PTP/NTP können Zeitsprünge auftreten. Logging-Stacks müssen mit rückwärtslaufenden Zeitstempeln robust umgehen können (Auswertung über RegisterTimeLeapNotifier).