Figure 10.5: Use cases for Time Synchronization Master

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) mit AUTOSAR-spezifischer Metamodell-Stereotypisierung («aapUseCase», «aapTriggers»).
• Technischer Zweck: Spezifikation der Interaktionen zwischen einer externen Applikationsentität und dem AUTOSAR Adaptive Platform Functional Cluster Time Synchronization (Teil von ara::ts / ara::time), fokussiert auf die Master-Rolle (Zeitgeber / Master-Knoten).
• Funktionale Einordnung: In verteilten Systemen synchronisiert der Time Synchronization Cluster lokale Clocks netzwerkweit (z. B. via IEEE 802.1AS / gPTP, CAN-TSyn). Das Diagramm grenzt die Use Cases ab, bei denen eine Adaptive Application nicht als passiver Zeitempfänger (Slave/Consumer), sondern als autorisierte Referenzzeitquelle agiert.

2. Komponenten, Entitäten & Schnittstellen

• Akteure (Actors):
  • Adaptive Application: Repräsentiert einen Plattform-Nutzerprozess, welcher als Master bzw. Sensor-Datenquelle fungiert (z. B. GNSS-Daemon, PTP-Grandmaster-Interface oder Hardware-Uhren-Treiber-Adapter).
• System- & Clustergrenzen:
  • Systemgrenze: Adaptive Platform (Laufzeitumgebung).
  • Subsystem / Functional Cluster: Time Synchronization (zuständig für Uhrenverwaltung, Drift-Kompensation, Ratenanpassung und Verteilung synchronisierter Zeitbasen).
• Use Cases («aapUseCase»):
  • Set Value of Time Base: Setzen bzw. direktes Nachjustieren des absoluten/relativen Zeitwertes einer dedizierten Zeitbasis (z. B. Initialisierung oder Sprungkorrektur einer Pure Local Time Base oder Synchronized Time Base).
  • Provide Measurement Data: Kontinuierliche Einspeisung von Messwerten (z. B. Zeitstempel, Taktflanken, GNSS-Empfängerdaten oder Drift-Messungen) zur Filterung und kontinuierlichen Regelung (z. B. via Software-PLL/Kalman-Filter).
• Beziehungen:
  • Gerichtet mit Stereotyp «aapTriggers»: Die Adaptive Application initiiert beide Use Cases aktiv; die Kontrolle geht von der Applikation auf das Plattform-Cluster über.

3. Dynamisches Verhalten & Sequenzablauf

• Pfad Set Value of Time Base:
  1. Trigger: Die Master-Applikation ruft eine synchrone/asynchrone API-Methode auf, um eine konfigurierte Zeitbasis explizit zu setzen.
  2. Validierung & Ausführung: Prüfung der Aufrufer-Privilegien (IAM/Access Control). Bei Erfolg wird die Basiszeit inkrementiert/korrigiert und der Zeitbasen-Status (z. B. Time Base Status Flags wie TIMEOUT, SYNC_TO_GATEWAY) aktualisiert.
  3. Verbreitung: Der geänderte Zeitwert wird an angeschlossene Netzwerkteilnehmer (Slaves) propagiert.
• Pfad Provide Measurement Data:
  1. Trigger: Zyklische oder ereignisbasierte Übergabe von Rohmesswerten durch die Applikation.
  2. Kompensation: Der Time-Sync-Cluster verarbeitet die Messwerte intern zur Frequenznachführung (Rate Correction) und Phasensynchronisation, ohne sprunghafte Zeitverschiebungen zu erzeugen.
• Fehlerpfade: Abweisung bei unzureichenden Rechten, Inkonsistenz zu laufenden Synchronisationsprotokollen oder unplausiblen Zeitstempeln (Out-of-Bounds).

4. Normative Relevanz & Entwickler-Hinweise

• Berechtigungskonzept & IAM: Schreibende Zugriffe auf Zeitbasen stellen kritische Systemoperationen dar (Einfluss auf Fristen, Scheduler, Protokollierungs- und Tracing-Validität). Applikationen benötigen im Execution/Service-Manifest explizite Berechtigungen, um Methoden dieser Master-Use-Cases binden zu dürfen.
• Manifest-Konfiguration (ARXML):
  • Die zugehörige Zeitbasis muss im Manifest als Master-fähig (TimeBaseType / Synchronized Master) deklariert sein.
  • Zuweisung, ob eine Zeitbasis sprunghaft modifizierbar (Set Value) oder ausschließlich stetig nachgeregelt werden darf.
• API-Design (ara::ts):
  • Standard-Konsumenten nutzen rein lesende Schnittstellen (GetCurrentTime()).
  • Master-Applikationen müssen deterministische Latenzen bei der Erfassung und Übergabe der Measurement Data sicherstellen, da Jitter auf Applikationsebene direkt die netzwerkweite Synchronisationsgenauigkeit verschlechtert.