Figure 9.36: Interface for time base providers

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Component & Interface Diagram) unter Verwendung des AUTOSAR Adaptive Platform (AP) UML-Profils («aapFunctionalCluster», «aapAPI,aapPortInterface», «aapProvidedPort», «use»).
• Architektonische Einordnung: AUTOSAR Adaptive Platform (Release R24-11), Functional Cluster Time Synchronization (ara::ts).
• Technischer Zweck: Spezifikation der Schnittstelle SynchronizedTimeBaseProvider. Das Diagramm definiert den Service-Vertrag für Adaptive Applications, die als aktive Zeitgeber (Master-Clock-Quellen, z. B. via GNSS/GPS, PTP-Grandmaster oder externe Referenznetzwerke) agieren und Zeitstempel, Frequenzkorrekturen sowie Validierungsereignisse in den zentralen, daemon-basierten Time-Synchronization-Cluster einspeisen.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Komponenten:
  • Adaptive Application (Komponente): Anwendungs- oder Adapterprozess im User Space, der die Rolle des Time Base Providers einnimmt.
  • Time Synchronization (Komponente mit Stereotyp «aapFunctionalCluster», Spezifikation: daemon-based): Zentraler Plattform-Daemon der AP, der synchronisierte Zeitbasen instanziiert, verwaltet und konsumierenden Anwendungen bereitstellt.
  • SynchronizedTimeBaseProvider (Schnittstelle mit Doppel-Stereotyp «aapAPI,aapPortInterface»): Port-Interface bzw. C++ API-Definition zur Steuerung und Aktualisierung einer synchronisierten Zeitbasis.
• Methoden der Schnittstelle SynchronizedTimeBaseProvider:
  • + GetCurrentTime(): Synchrones Auslesen des aktuellen Zeitstempels der Zeitbasis.
  • + GetRateCorrection(): Abfrage des aktiven Raten-/Drift-Korrekturfaktors.
  • + GetUserData(): Abruf von synchron mit der Zeitbasis transportierten anwendungsspezifischen Nutzdaten.
  • + RegisterTimeValidationNotification(): Registrierung eines Callbacks für Benachrichtigungen zur Zeitvalidierung (z. B. Synchronisationsstatus, Plausibilität).
  • + SetRateCorrection(): Vorgeben einer Ratenkorrektur zur Frequenzdrift-Kompensation.
  • + SetTime(): Absolutes Setzen der Zeitbasis (Hard Step / Initialisierung).
  • + SetUserData(): Setzen von applikationsspezifischen Begleitdaten zur Übertragung an verbundene Knoten.
  • + UnregisterTimeValidationNotification(): Deregistrierung des Validierungs-Callbacks.
  • + UpdateTime(): Inkrementelles bzw. kontinuierliches Nachführen der Zeitbasis (Slewing / Drift-Anpassung).
• Beziehungen:
  • Interface Realization (--▷): Der Daemon Time Synchronization implementiert die Schnittstelle SynchronizedTimeBaseProvider.
  • Dependency / Port-Bindung (--> mit «use», «aapProvidedPort»): Die Adaptive Application bindet die Schnittstelle über einen Provided Port des Daemons ein, um Schreib- und Steuerungszugriff auf die Zeitbasis zu erhalten.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungsphase:
  1. Die Adaptive Application bindet die Instanz der Zeitbasis über den konfigurierten Port.
  2. Initiale Zeitsynchronisation über SetTime() (absoluter Startwert).
  3. Konfiguration der Frequenz- und Ganggenauigkeit über SetRateCorrection().
  4. Optional: Hinterlegung von Metadaten über SetUserData().
• Zyklischer Betrieb & Nachführung:
  • Regelmäßige Einspeisung korrigierter Zeitdaten via UpdateTime() zur Vermeidung von Phasensprüngen durch kontinuierliches Slewing.
  • Zyklisches Nachjustieren der Drift mittels SetRateCorrection().
  • Synchrone Statusverifikation über GetCurrentTime(), GetRateCorrection() und GetUserData().
• Asynchroner Validierungspfad:
  • Mittels RegisterTimeValidationNotification() wird ein Notification-Handler im Daemon registriert.
  • Bei Eintritt von Validierungsereignissen (z. B. Verlust der Referenzuhr, Schwellwertüberschreitung von Jitter/Drift) informiert der Daemon die Anwendung asynchron.
  • Beendigung des Überwachungspfades über UnregisterTimeValidationNotification().

4. Normative Relevanz & Entwickler-Hinweise

• Rollen- und Rechte-Restriktion: Im Gegensatz zu SynchronizedTimeBaseConsumer (reiner Lesezugriff) erfordert SynchronizedTimeBaseProvider exklusive Zugriffsrechte. Pro Zeitbasis darf typischerweise nur ein einzelner autorisierter Provider aktiv sein (Single-Writer-Prinzip), um Inkonsistenzen und Zeit-Oszillationen auszuschließen.
• Daemon-basierte IPC-Latenzen: Der Vermerk daemon-based erzwingt Interprozesskommunikation (IPC) zwischen Anwendungs- und Daemon-Kontext. Bei SetTime() und UpdateTime() müssen Latenzzeiten und IPC-Jitter in die Zeitkorrekturrechnung einfließen.
• C++ Interface-Vertrag (ara::core::Result): Sämtliche Methodenaufrufe folgen dem fehlerbasierten AUTOSAR-Rückgabemuster (ara::core::Result<void> bzw. ara::core::Result<T>). Entwickler müssen explizit Fehlerzustände wie ungültige Zeitdomänen, fehlende Autorisierung (IAM), Bereichsverletzungen bei Ratenkorrekturen oder ungültige Zeitstempelsprünge abfangen.
• Safety- & Determinismus-Auswirkungen: Harte Zeitsprünge durch SetTime() wirken sich unmittelbar auf zeitgesteuerte Kommunikationsprotokolle (z. B. TSN / IEEE 802.1AS, SOME/IP-Timestamping), deterministische Schedulings und Logging aus. SetTime() sollte auf Initialisierungs- oder Fehler-Recovery-Phasen beschränkt bleiben; im regulären Regelbetrieb ist UpdateTime() bzw. SetRateCorrection() zwingend vorzuziehen.