Figure 9.39: 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:
    • 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 rufen synchron GetTimeWithStatus() auf, um den aktuellen Zeitstempel gekoppelt mit dem Gültigkeits- und Synchronisationsstatus abzufragen, oder GetRateDeviation() zur Bestimmung von Ratenabweichungen.
   • 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):
   • Konsumenten registrieren Callbacks via Register*Notifier() bzw. RegisterTimeValidationNotification().
   • Bei Zustandsänderungen der Zeitbasis (z. B. Synchronisationsverlust, Time Leaps, Überschreiten von Präzisionsgrenzen) benachrichtigt der TSYN-Daemon die registrierten Callbacks asynchron über Inter-Process Communication (IPC).
   • Bei Deregistrierung (Unregister*Notifier()) werden die Callback-Handles im Daemon freigegeben, um Dangling Callbacks beim Herunterfahren von Prozessen zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Verbindlichkeit: Die Port-Schnittstelle SynchronizedTimeBaseConsumer definiert den verbindlichen ARA-C++-API-Vertrag (ara::tsyn). Konsumenten dürfen Zeitdaten ausschließlich über diesen typisierten Required Port beziehen.
• Implementierungsaspekte & Concurrency:
  • Durch den Entfall von GetCurrentTime() erzwingt die Schnittstelle die synchrone Abfrage ausschließlich über GetTimeWithStatus(). Konsumenten müssen den zurückgegebenen Status (SynchronizedTimeBaseStatus) zwingend vor Weiterverarbeitung des Zeitwerts auf Gültigkeit und Synchronisationsgüte prüfen.
  • Notifier-Callbacks laufen typischerweise im Thread-Pool des ara::core bzw. TSYN-Client-Runtimes ab; zustandsändernde Logik innerhalb der Callbacks muss reentrant und threadsicher implementiert sein.
• Lebenszyklus & Initialisierung: Da Time Synchronization als daemon-based Cluster operiert, müssen konsumierende Prozesse sicherstellen, dass die TSYN-Verbindung initialisiert ist bzw. Time-Leap- und Status-Notifier vor zyklischen Operationen registriert werden.