Figure 9.33: Users of Time Synchronization interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Strukturdiagramm nach AUTOSAR Adaptive Platform Meta-Modell / EXP_SWArchitecture).
• Technischer Zweck: Spezifikation der Port- und API-Abhängigkeiten zwischen dem Plattform-Daemon Time Synchronization (TSYN) und den konsumierenden Functional Clustern (FCs) der AUTOSAR Adaptive Platform (ARA).
• Architektonische Einordnung: Darstellung des architektonischen Musters „Provider/Consumer“ für synchronisierte Zeitbasen (z. B. nach IEEE 802.1AS / gPTP) innerhalb der Adaptive-Plattform-Schicht. Das Diagramm dokumentiert, welche Kern-Cluster der Plattform die standardisierte C++-API von TSYN über Required Ports binden.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Provider:
  • «aapFunctionalCluster» Time Synchronization (daemon-based): Zentraler Plattformdienst, der externe Bus-Zeitbasen (z. B. via Ethernet/CAN) synchronisiert und lokal bereitstellt.
• Konsumenten (Clients):
  • «aapFunctionalCluster» Log and Trace (LT): Konsumiert Zeitbasen zur global korrelierten Zeitstempelung von Log-Meldungen und Traces über Steuergerätegrenzen hinweg.
  • «aapFunctionalCluster» Persistency (PER): Verwendet Zeitdaten für zeitstempelbasierte Key-Value-Speicher, Dateiversionierung und Backup-/Restore-Validierung.
  • «aapFunctionalCluster» Intrusion Detection System Manager (IdsM, daemon-based): Nutzt Zeitbasen zur forensischen zeitlichen Korrelation von Security-Events (SEv), Time-Validation und Replay-Angriffserkennung.
  • «aapFunctionalCluster» Update and Configuration Management (UCM, daemon-based): Nutzt Zeitbasen zur Validierung von Software-Paket-Zertifikaten, Ablaufdaten von Manifesten sowie zur zeitlichen Protokollierung von Aktualisierungsvorgängen.
  • «aapFunctionalCluster» Vehicle Update and Configuration Management (VUCM, daemon-based): Koordiniert fahrzeugweite Update-Kampagnen und benötigt synchronisierte Zeitdaten für fahrzeugweite Rollout-Zeitfenster und Kampagnen-Protokollierung.
• Port-Interface / API-Klasse:
  • «aapAPI, aapPortInterface» SynchronizedTimeBaseConsumer: Standardisiertes C++ API-Interface (ara::tsyn).
• Methoden der Schnittstelle:
  • Synchrone Leseoperationen:
    • GetCurrentTime()
    • GetRateDeviation()
    • GetTimeWithStatus(): SynchronizedTimeBaseStatus
  • Notifier-Registrierung (Observer-Pattern):
    • RegisterStatusChangeNotifier()
    • RegisterSynchronizationStateChangeNotifier()
    • RegisterTimeLeapNotifier()
    • RegisterTimePrecisionMeasurementNotifier()
    • RegisterTimeValidationNotification()
  • Notifier-Deregistrierung:
    • UnregisterStatusChangeNotifier()
    • UnregisterSynchronizationStateChangeNotifier()
    • UnregisterTimeLeapNotifier()
    • UnregisterTimePrecisionMeasurementNotifier()
    • UnregisterTimeValidationNotification()

Beziehungen & Abhängigkeiten

• Schnittstellen-Realisierung: Time Synchronization realisiert/implementiert SynchronizedTimeBaseConsumer (hollow inheritance triangle / Provider-Port).
• Port-Abhängigkeiten: Die fünf Functional Cluster besitzen jeweils eine gerichtete Abhängigkeit «use» via «aapRequiredPort» auf das Interface SynchronizedTimeBaseConsumer.

3. Dynamisches Verhalten & Sequenzablauf

Kommunikationsmuster

1. Synchroner Abfragepfad (Pull-Prinzip):
   • Konsumenten (z. B. LT oder IdsM) rufen GetCurrentTime() oder GetTimeWithStatus() direkt synchron im eigenen Ausführungskontext auf.
   • Rückgabe erfolgt ohne Blockieren des Client-Threads, typischerweise realisiert über Shared-Memory-Segmente oder lock-free Kernel-/vDSO-Mappings des TSYN-Daemons.
2. Asynchroner Event-/Notification-Pfad (Push-Prinzip / Observer):
   • Phase 1 (Registrierung): Während der Initialisierung registriert der Konsument Funktionszeiger / Callbacks via Register*Notifier().
   • Phase 2 (Ereigniseintritt): Der TSYN-Daemon detektiert Statusänderungen auf dem Bus oder im lokalen Clock-Drift (z. B. Verlust des Grandmasters, Time Leap bei Resynchronisation, Drift-Überschreitung von Schwellwerten via TimePrecisionMeasurementNotifier).
   • Phase 3 (Callback-Ausführung): TSYN triggert die registrierten Notifier der Konsumenten asynchron.
   • Phase 4 (Teardown): Vor dem Beenden einer Applikation oder Deinitialisierung des Moduls müssen alle Notifier explizit über Unregister*Notifier() abgemeldet werden, um Dangling References zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• Status-Verifikation vor Zeitnutzung: Der Aufruf von GetCurrentTime() allein garantiert keine gültige Synchronisation. Entwickler zeit- und sicherheitskritischer Funktionen (EM, IdsM) müssen zwingend GetTimeWithStatus() auswerten und den Rückgabewert SynchronizedTimeBaseStatus auf Gültigkeit (TIMEOUT, SYNC, UNSYNC) prüfen, bevor Zeitstempel für funktionale Entscheidungen genutzt werden.
• Handhabung von Zeitsprüngen (Time Leap Handling): Persistency und Log/Trace dürfen nicht von monoton wachsenden Systemzeiten ohne Sprünge ausgehen. Bei Netzwerk-Resynchronisationen treten diskontinuierliche Zeitsprünge auf; Konsumenten müssen via RegisterTimeLeapNotifier() auf Vorwärts- und Rückwärtssprünge reagieren, um Datenkorruption oder Endlosschleifen zu verhindern.
• Sicherheitsrelevanz (Time Validation): RegisterTimeValidationNotification() ist primär für die Cyber-Security-Architektur (IdsM) bindend: TSYN validiert CAN/Ethernet-Zeitsynchronisationsnachrichten (z. B. SecOC für Sync-Frames). Manipulationsversuche oder ungültige Zeitabstände führen zu Time-Validation-Events, die an das IdsM gemeldet werden.
• Daemon-Entkopplung: Da TSYN als eigenständiger Prozess (daemon-based) spezifiziert ist, erfordert die Interaktion zwischen den Clustern optimierte IPC-Mechanismen (z. B. POSIX Clocks oder IPC-Shared-Memory). Entwickler dürfen innerhalb der registrierten Notifier-Callbacks keine langwierigen oder blockierenden Operationen ausführen.