Figure 11.12: Scenario: Set Value Of Time Base

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11; Domäne Communication, Subcluster Time Synchronization (ara::tsync).
• Funktionaler Zweck: Veranschaulichung des Master-Szenarios zur manuellen/programmatischen Aktualisierung einer Zeitbasis (Time Base). Es spezifiziert die Entkopplung zwischen der modifizierenden Applikationsebene (Adaptive Application), dem autoritativen Zeitgeber (Master: Time Synchronization) und den abhängigen Zeitempfängern (Slaves: Time Synchronization) über ein Master-Slave-Verteilungsmodell (z. B. gPTP / IEEE 802.1AS oder CAN-TSync).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • :Adaptive Application: Nutzer- oder Plattform-Applikation (Instanz), die als Zeitautorität agiert (z. B. Anbindung an GNSS oder externe Master-Clock).
  • Master: Time Synchronization (Stereotyp «aapFunctionalCluster»): Funktionaler Cluster der Adaptive Platform in der Rolle des Zeit-Masters für eine dedizierte Time Base.
  • Slave 1: Time Synchronization & Slave 2: Time Synchronization (Stereotyp «aapFunctionalCluster»): Funktionale Cluster bzw. TSync-Instanzen auf verbundenen Knoten/Maschinen in der Rolle von Zeit-Slaves.
• Schnittstellen & Interaktionen:
  • SetTime(): Synchrone Kontrollschnittstelle (ARA-C++-API) zwischen Applikation und Master-Cluster zur Modifikation des Zeitbasiswerts.
  • sync(): Asynchrone Verteilungsmeldungen (Netzwerk-PDUs/Frames, z. B. PTP Sync / Follow_Up), gerichtet vom Master an die registrierten bzw. am Bus lauschenden Slave-Instanzen.
• Kardinalitäten & Topologie:
  • 1:1-Beziehung zwischen steuernder Applikation und Time Master.
  • 1:n-Topologie (Multicast/Broadcast) zwischen Master-Cluster und beliebig vielen Time Slaves im Netzwerkverbund.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / Setzen der Zeit:
   • Die :Adaptive Application stößt synchron die Methode SetTime() auf dem lokalen Master: Time Synchronization an.
   • Der Master aktualisiert intern die lokale Repräsentation der spezifischen Time Base (inkl. Statusbits, z. B. Sync-Status, UserData, Drift-/Offset-Kompensation).
2. Propagation / Verteilung:
   • Der Master initiiert unmittelbar nach Übernahme des neuen Zeitwerts asynchrone sync()-Zyklen.
   • sync() wird parallel bzw. sequenziell über das zugrundeliegende Kommunikationsmedium an Slave 1 und Slave 2 emittiert (z. B. Generierung von Egress-Timestamps und Follow-Up-Nachrichten gemäß IEEE 802.1AS).
3. Slave-seitige Aktualisierung:
   • Die Slaves empfangen sync(), berechnen die Laufzeitkorrektur (Propagation Delay) und passen ihre lokalen virtuellen Zeitbasen an.

4. Normative Relevanz & Entwickler-Hinweise

• API & Zugriffsrechte:
  • SetTime() erfordert typischerweise spezifische IAM-Berechtigungen (Identity and Access Management) im Execution Management; unberechtigte Applikationen dürfen keine globalen Zeitbasen manipulieren.
  • Das Setzen erfolgt nicht atomar über alle Netzknoten, sondern unterliegt der netzwerkbedingten Propagation-Latenz.
• Jitter, Sprünge & Monotonie:
  • Das Setzen einer Zeitbasis via SetTime() kann zu diskontinuierlichen Zeitschritten (Vorwärts- oder Rückwärtssprünge) führen. Applikationen auf Slave-Knoten, die monoton steigende Clocks voraussetzen (ara::core::SteadyClock), dürfen nicht an sprunghafte Synchronized Time Bases gekoppelt werden.
  • Time Synchronization-Treiber/Stacks müssen entsprechende Rate-Adaption- oder Slew-Algorithmen konfigurieren, falls harte Zeitsprünge vermieden werden müssen.
• Konfiguration (Manifeste):
  • Im ARXML-Modell müssen TimeBaseResource, TimeMasterConfiguration und TimeSlaveConfiguration exakt zueinander referenziert sein.
  • Zuweisung der Netzwerk-Bindings (Ethernet / CAN) und Zuordnung der Hardware-Timestamping-Fähigkeiten der Netzwerkadapter für deterministische Synchronisationsgenauigkeit.