Figure 10.4: Use cases for Time Synchronization Slave

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Use-Case-Diagramm (spezifiziert im AUTOSAR Adaptive Platform Metamodell/Profil via «aapUseCase» und «aapTriggers»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Time Synchronization (ara::tsync, Release R23-11).
• Funktionale Einordnung: Definiert die elementaren Anwendungsfälle einer Adaptive Application (AA) in der Rolle eines synchronisierten Zeitkonsumenten (Time Synchronization Slave). Es grenzt das funktionale API-Verhalten des TSync-Clusters gegenüber der Applikationsschicht ab.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen & Packages:
  • Adaptive Platform: Gesamte Laufzeitumgebung der Adaptive Platform.
  • Time Synchronization: Systemgrenze des Functional Clusters ara::tsync (Daemon/Provider-Instanz für Zeitbasen).
• Akteure:
  • Adaptive Application (Stereotyp: (from Actors)): Ausführender POSIX-Nutzerprozess im User Space, der zeitgesteuerte oder zeitsensitive Funktionen ausführt.
• Anwendungsfälle («aapUseCase»):
  • Get Value of Time Base: Synchrone Abfrage des aktuellen Zeitwerts einer definierten Zeitbasis (z. B. abgeleitet aus IEEE 802.1AS / gPTP, CAN-TSyn oder lokaler monotoner Clock).
  • Receive Notification: Asynchrone Benachrichtigung der Applikation über zeitbezogene Ereignisse und Zustandsänderungen der Zeitbasis.
• Beziehungen & Stereotypen:
  • «aapTriggers»: Gerichtete Assoziationen, ausgehend vom Akteur Adaptive Application. Die AA initiiert sowohl das Auslesen der Zeitbasis als auch die Registrierung für den Benachrichtigungsempfang.

3. Dynamisches Verhalten & Sequenzablauf

• Synchroner Pfad (Get Value of Time Base):
  1. Die AA ruft die Auslesemethode über das C++ Interface auf (z. B. Abfrage via ara::tsync-spezifische Uhren, kompatibel zu std::chrono::time_point).
  2. Der Time Synchronization Cluster liefert den aktuellen Zeitstempel samt Statusflag (z. B. SyncStatus::kSynchronized) deterministisch ohne Inter-ECU-Wartezeit aus dem lokalen Speicher/Hardware-Register zurück.
• Asynchroner Pfad (Receive Notification):
  1. Die AA registriert Callbacks/Handler am TSync-Cluster für spezifische Ereignisse.
  2. Der Cluster überwacht interne Schwellwerte und Protokollstati (z. B. Sync-Loss, Time Leap/Leap Second, Überschreitung der maximalen Drift/Ungenauigkeit).
  3. Bei Eintreten eines Ereignisses triggert der Cluster den registrierten Callback im Kontext des Worker-Threads der Applikation.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::tsync):
  • Applikationsentwickler binden die Zeitbasen über standardisierte C++-Header ein. Zeitabfragen sind strikt lokal implementiert (Laufzeitkomplexität $\mathcal{O}(1)$), um Echtzeitanforderungen nicht zu verletzen.
• Slave-Restriktionen:
  • Keine Schreib- oder Stellrechte: Der Slave-Pfad erlaubt rein lesende Zugriffe; Kalibrierung und Disziplinierung des Hardware-Timers (z. B. via PTP-Hardware-Clock /dev/ptp*) obliegen exklusiv den internen TSync-Plattformtreibern.
• Fehlerbehandlung & Synchronisationsstatus:
  • Entwickler dürfen Zeitwerte niemals ungeprüft verarbeiten: Bei jedem Get Value of Time Base bzw. über die Status-Notifications muss der Gültigkeitsstatus (ara::core::Result, Synchronisations-Flags) ausgewertet werden, um degraded modes bei Bus-Abriss oder Verlust der Grandmaster-Clock abzufangen.