Figure 11.8: Scenario: Get Value of Time Base

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Veranschaulichung des Entkopplungs- und Abfrageszenarios für synchronisierte Zeitbasen innerhalb der AUTOSAR Adaptive Platform (AP). Es stellt dar, wie eine Adaptive Application über den lokalen Time-Synchronization-Slave eine standardisierte Zeitbasis abfragt, während die Zeitsynchronisation über das Netzwerk (sync()) transparent im Hintergrund durch den Time-Synchronization-Functional-Cluster abgewickelt wird.
• Funktionale Einordnung: AUTOSAR AP Foundation / Services – Functional Cluster Time Synchronization (ara::ts gemäß SWS Time Synchronization).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten / Lifelines:
  • :Adaptive Application: Anwendungsinstanz im User Space (POSIX-Prozess), agiert als Konsument der synchronisierten Zeit.
  • «aapFunctionalCluster» Slave: Time Synchronization: Instanz des Functional Clusters Time Synchronization auf der lokalen Adaptive Platform Machine in der Rolle des Time Slaves (lokaler Provider der Zeitbasis).
  • «aapFunctionalCluster» Master: Time Synchronization: Zeitgebende Entität (Time Master) im Bordnetz (kann auf einer entfernten Classic- oder Adaptive-ECU liegen, z. B. Grandmaster Clock).
• Stereotypen:
  • «aapFunctionalCluster»: Kennzeichnet die architektonische Kernkomponente der AUTOSAR Adaptive Platform Architecture (AAP).
• Schnittstellen & Interaktionspunkte:
  • sync(): Netzwerkbasierte Synchronisationsnachricht / Protokollinteraktion (z. B. gPTP / IEEE 802.1AS über Ethernet oder CAN-TSyn / FlexRay-TSyn).
  • GetCurrentTime(): Synchroner API-Methodenaufruf der ARA-Schnittstelle (ara::ts), über den die Applikation den aktuellen Zeitstempel (inkl. Status / Synchronisationsgüte) der referenzierten Zeitbasis anfordert.

3. Dynamisches Verhalten & Sequenzablauf

1. Asynchrone Hintergrund-Synchronisation (sync()):
   • Der Master: Time Synchronization übermittelt zyklisch oder ereignisgesteuert Synchronisationsmeldungen (sync()) an den Slave: Time Synchronization.
   • Der Slave korrigiert lokal Drift und Offset der Hardware-/OS-Clocks, aktualisiert die interne Zeitbasis und führt die Zustandsverwaltung (z. B. Synchronisationsstatus, Timeout-Überwachung).
2. Applikative Zeitabfrage (GetCurrentTime()):
   • Die :Adaptive Application triggert synchron den Aufruf GetCurrentTime() am lokalen Slave: Time Synchronization.
3. Ergebnisrückgabe:
   • Der lokale Functional Cluster liest die aktuelle extrapolierte/korrigierte Zeit aus und liefert das Zeitergebnis (Zeitstempel bzw. ara::core::Result<ara::ts::TimeStamp>) unmittelbar per Return-Pfeil an die Applikation zurück.
   • Keine direkte Blockierung durch laufende Netzwerkübertragungen; Abfrage erfolgt entkoppelt vom Netzwerkzyklus auf Basis des lokalen Schätz-/Regelungszustands.

4. Normative Relevanz & Entwickler-Hinweise

• API-Design (ara::ts): Der Zugriff auf die Zeitbasis erfolgt nicht über direkte OS-Systemaufrufe (clock_gettime), sondern über die typisierten C++-Klassen von ara::ts (z. B. abgeleitet von std::chrono::Clock-Konzepten bzw. spezifischen TimeBase-Klassen), um synchronisierte automobile Zeitdomänen abzubilden.
• Fehlerbehandlung & Synchronisationsstatus: GetCurrentTime() liefert neben Nanosekunden-Zeitwerten Metadaten über den Status der Zeitbasis (z. B. TIMEOUT, SYNC, UNSYNC). Applikationsentwickler müssen prüfen, ob die Zeitbasis aktuell als synchronisiert gilt, bevor zeitkritische Aktionen (z. B. Sensorfusion, Event-Logging) ausgeführt werden.
• Laufzeitverhalten & Performance: Der Aufruf von GetCurrentTime() ist für deterministische, latenzarme Ausführung ausgelegt. Er greift auf lokale Interpolationsregister/OS-Timer zu und wartet nicht auf die nächste sync()-PDU des Netzwerks.
• Konfiguration (Manifest): Die Zuordnung der Applikation zu einer konkreten Zeitbasis (z. B. Global Time Base, Pure Local Time Base) wird deklarativ im Execution- und Service-Instance-Manifest modelliert.