Modul ara::tsync — Time Synchronization

Der funktionale Cluster Time Synchronization stellt der AUTOSAR Adaptive Platform konsistente und netzwerkweit synchronisierte Zeitbasen zur Verfügung (AUTOSAR_AP_SWS_TimeSynchronization S. 16). Über standardisierte Schnittstellen rufen adaptive Anwendungen atomare Zeitzustände ab oder speisen als aktive Zeitgeber neue Zeit- und Ratenkorrekturen in das Gesamtsystem ein. Zugleich überwachen registrierte Notifier-Callbacks kontinuierlich Zustandswechsel sowie Zeitsprünge der zugrundeliegenden Uhren ([SWS_TS_01009]). Erweiterte Mechanismen zur Validierung von Messdaten und Frischewerten sichern dabei die zeitliche Integrität gegen Übertragungsfehler und Manipulationen ab.

mehr ›

Der funktionale Cluster Time Synchronization (tsync) stellt auf der AUTOSAR Adaptive Platform konsistente und netzwerkweit synchronisierte Zeitbasen bereit (AUTOSAR_AP_SWS_TimeSynchronization S. 16). Als daemon-basierter Hintergrunddienst abstrahiert er hardware- und busspezifische Synchronisationsmechanismen (wie IEEE 802.1AS gPTP) und beliefert Kerncluster wie Log and Trace, den Intrusion Detection System Manager (IdsM) sowie Update-Dienste über standardisierte Schnittstellen (AUTOSAR_AP_EXP_SWArchitecture S. 83).

Kontextdiagramm: Einbettung des daemon-basierten Time-Synchronization-Clusters in die AUTOSAR Adaptive Platform und seine Schnittstellenbeziehungen zu konsumierenden Clustern und Applikationen. Quellen: AUTOSAR_AP_SWS_TimeSynchronization S. 16, AUTOSAR_AP_EXP_SWArchitecture S. 83, AUTOSAR_AP_EXP_SWArchitecture S. 83

Für den Lesezugriff nutzen Applikationen die Schnittstelle SynchronizedTimeBaseConsumer ([SWS_TS_01001]). Die Methode GetTimeWithStatus() liefert einen atomaren Snapshot des Typs SynchronizedTimeBaseStatus zurück, aus dem sich die globale Zeit, die lokale stetige Erstellungszeit, der Synchronisationszustand sowie empfangene UserData abrufen lassen ([SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176]). Zur Vermeidung von Polling registrieren sich Anwendungen über Notifier-Callbacks für Statuswechsel und Zeitsprünge ([SWS_TS_01010], [SWS_TS_01014]).

Sequenzdiagramm: Ablauf einer synchronen Zeitabfrage über die Consumer-Schnittstelle und Auslesen atomarer Snapshot-Eigenschaften. Quellen: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture S. 225

Zeitgebende Anwendungen steuern über SynchronizedTimeBaseProvider das Systemverhalten: SetTime() stößt sofortige Bus-Übertragungen an, während UpdateTime() die Uhr zunächst lokal anpasst ([SWS_TS_01101], [SWS_TS_01107], [SWS_TS_01108]). Begleitende Mechanismen wie Time Validation ([SWS_TS_00420], [SWS_TS_00421]) und das native Freshness Value Management (FVM) schützen gegen Drift- und Replay-Fehler ([SWS_TS_14198]). Im Fehlerfall signalisieren TsyncErrc-Codes (z. B. kDaemonConnectionLost) Verbindungsabbrüche, während ein Ausbleiben von Synchronisationsbotschaften als kTimeOut im Statusobjekt angezeigt wird ([SWS_TS_00901], [SWS_TS_01050]).

mehr ›

Der funktionale Cluster Time Synchronization (tsync) stellt auf der AUTOSAR Adaptive Platform koordinierte, netzwerkweit synchronisierte Zeitbasen bereit und entkoppelt anwendende Prozesse von hardware- sowie busspezifischen Zeitsynchronisationsprotokollen (AUTOSAR_AP_SWS_TimeSynchronization S. 16). Das System bildet das informationstechnische Fundament für verteilte Systeme, bei denen Steuergerätegrenzen hinweg konsistente Ereignisabfolgen, reproduzierbare Trace-Protokolle und deterministische Berechnungszyklen gewährleistet sein müssen (AUTOSAR_AP_EXP_SWArchitecture S. 83).

Kontextdiagramm: Einbettung des daemon-basierten Time-Synchronization-Clusters in die AUTOSAR Adaptive Platform und seine Schnittstellenbeziehungen zu konsumierenden Clustern und Applikationen. Quellen: AUTOSAR_AP_SWS_TimeSynchronization S. 16, AUTOSAR_AP_EXP_SWArchitecture S. 83, AUTOSAR_AP_EXP_SWArchitecture S. 83

Systemgrenzen und Rolle des daemon-basierten Time-Synchronization-Clusters

Die funktionale Architektur von Time Synchronization ist als daemon-basierter Cluster (daemon-based) ausgeführt, welcher im Hintergrund als zentraler Plattformdienst operiert (AUTOSAR_AP_SWS_TimeSynchronization S. 16). Dieser Daemon interagiert direkt mit den Schnittstellen des zugrundeliegenden Betriebssystems und verarbeitet netzwerkbasierte Zeitsynchronisationsdaten wie gPTP (IEEE 802.1AS) oder klassische Bus-Zeitsynchronisationen (AUTOSAR_FO_PRS_TimeSyncProtocol S. 68). Gegenüber dem Anwendungskontext kapselt der Cluster die mathematische Drift- und Offset-Kompensation der Hardware-Uhren vollständig ab.

Zahlreiche funktionale Kerncluster der Adaptive Platform greifen über standardisierte Service-Schnittstellen auf tsync zu (AUTOSAR_AP_EXP_SWArchitecture S. 83). Beispielsweise stützt sich Log and Trace auf die synchronisierte Zeitbasis, um systemweite Log- und DLT-Ereignisse mit verlässlichen globalen Zeitstempeln zu versehen (AUTOSAR_AP_EXP_SWArchitecture S. 59; AUTOSAR_AP_SWS_LogAndTrace S. 15). Auch sicherheitsrelevante Module wie der Intrusion Detection System Manager (IdsM) sowie Update-Dienste (UCM und Vehicle UCM) setzen zwingend auf die C++-Schnittstelle von SynchronizedTimeBaseConsumer, um forensisch belastbare Reports und konsistente Update-Transaktionen über Steuergerätegrenzen hinweg zu steuern (AUTOSAR_AP_EXP_SWArchitecture S. 125; AUTOSAR_AP_SWS_UpdateAndConfigurationManagement S. 16; AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement S. 11).

Konsumierende Schnittstellen und zustandsbehaftete Zeitabfragen

Für den Lesezugriff auf eine synchronisierte Zeitbasis verwenden Anwendungen die Schnittstellenklasse SynchronizedTimeBaseConsumer ([SWS_TS_01001]). Die Klasse implementiert Move-Semantik ([SWS_TS_01003], [SWS_TS_01004]), schließt aber jegliches Kopieren explizit aus ([SWS_TS_01005], [SWS_TS_01006]). Zur Laufzeit erlaubt GetRateDeviation() das direkte Auslesen der aktuellen Frequenzabweichung der Uhr ([SWS_TS_01008]).

Zentrales Element jeder synchronen Abfrage ist die Operation GetTimeWithStatus() ([SWS_TS_01009]). Anstatt isolierte Rohzeitwerte zurückzuliefern, generiert die Methode einen in sich konsistenten Snapshot des Typs SynchronizedTimeBaseStatus (EXP_SWArchitecture S. 81). Dieser Snapshot friert den genauen Erstellungszeitpunkt in globaler Zeit ([SWS_TS_01055]) sowie in lokaler stetiger Zeit über GetCreationLocalTime() ein ([SWS_TS_14176]). Zeitpunkte werden hierbei im standardisierten C++-Chrono-Typ Timestamp mit Nanosekunden-Auflösung auf Basis von std::int64_t abgebildet ([SWS_TS_01251], [SWS_TS_01261], [SWS_TS_01262]).

Aus dem Snapshot lassen sich neben der Zeit auch der Kommunikations- und Synchronisationszustand via GetSynchronizationStatus() ([SWS_TS_01053]), ein eventuell erfolgter Zeitsprung via GetLeapJump() ([SWS_TS_01054]) sowie applikationsspezifische Anwenderdaten über GetUserData() ([SWS_TS_01056]) ermitteln. Ein Standardkonstruktor für das Statusobjekt existiert nicht ([SWS_TS_01061]), während Move- und Copy-Konstruktoren dessen thread-sichere Übergabe an aufrufende Anwendungsroutinen sicherstellen ([SWS_TS_01057], [SWS_TS_01058]).

Sequenzdiagramm: Ablauf einer synchronen Zeitabfrage über die Consumer-Schnittstelle und Auslesen atomarer Snapshot-Eigenschaften. Quellen: [SWS_TS_01009], [SWS_TS_01055], [SWS_TS_14176], AUTOSAR_AP_EXP_SWArchitecture S. 225

Ereignisgestützte Notifizierungen und Synchronisationsüberwachung

Um Polling-Schleifen zu vermeiden, stellt SynchronizedTimeBaseConsumer ein ereignisgesteuertes Observer-Muster über Notifier-Callbacks zur Verfügung (AUTOSAR_AP_EXP_SWArchitecture S. 226). Anwendungen registrieren sich mit typsicheren Callbacks für spezifische Zustandsänderungen ([SWS_TS_14221], [SWS_TS_14222]). Bei jeder erneuten Registrierung überschreibt der neue Notifier den zuvor registrierten Handler ([SWS_TS_01010]).

Für aggregierte Zustandsänderungen existiert RegisterStatusChangeNotifier() ([SWS_TS_01010]), ergänzt durch UnregisterStatusChangeNotifier() ([SWS_TS_01011]). Reagiert eine Applikation primär auf den Wechsel des Synchronisationsstatus (z. B. Verlust der Grandmaster-Verbindung), kommt RegisterSynchronizationStateChangeNotifier() ([SWS_TS_01012]) zum Einsatz. Zeitsprünge in die Zukunft (kTimeLeapFuture) oder Vergangenheit (kTimeLeapPast), die einen konfigurierten Schwellwert überschreiten, werden über RegisterTimeLeapNotifier() gemeldet ([SWS_TS_01014], [SWS_TS_01051]).

Für mechatronische Hochpräzisionsanwendungen steht ferner RegisterTimePrecisionMeasurementNotifier() bereit ([SWS_TS_01018]). Der Callback übergibt eine Struktur TimePrecisionMeasurement, die exakte Sekunden- und Nanosekundenwerte direkt vor (locSeconds, locNanoSeconds) und nach der Synchronisation (glbSeconds, glbNanoSeconds), die berechnete Pfadverzögerung pathDelay sowie die Bitmaske timeBaseStatus enthält ([SWS_TS_01401], [SWS_TS_01403], [SWS_TS_01406], [SWS_TS_01408]). Der Time-Synchronization-Cluster führt hierbei keine Warteschlangenverwaltung (Queuing) durch; Pufferungen müssen bei Bedarf innerhalb des Applikations-Callbacks realisiert werden ([SWS_TS_01018]).

Sequenzdiagramm: Registrierung und asynchroner Benachrichtigungsfluss bei Synchronisationsänderungen und Zeitsprüngen. Quellen: [SWS_TS_01010], [SWS_TS_01012], [SWS_TS_01014], AUTOSAR_AP_EXP_SWArchitecture S. 226

Zustandsdiagramm: Lebenszyklus des Synchronisationsstatus einer Zeitbasis nach SWS_TS_01050. Quellen: [SWS_TS_01050], AUTOSAR_SWS_TimeSync S. 25

Bereitstellung von Zeitbasen und Frequenzanpassung durch Provider

Tritt eine Adaptive Application als aktiver Zeitgeber (Time Master) auf – beispielsweise durch Anbindung an einen GNSS-Empfänger oder eine externe Referenzuhr –, nutzt sie die Klasse SynchronizedTimeBaseProvider ([SWS_TS_01101]). Die Schnittstelle erlaubt das explizite Setzen neuer Zeitwerte über zwei unterschiedliche Semantiken: SetTime() und UpdateTime() (EXP_SWArchitecture S. 80).

Der Aufruf von SetTime() setzt nicht nur den internen Uhrenstand neu, sondern forciert die sofortige Aussendung der aktualisierten Synchronisationsnachrichten auf dem Fahrzeugbus ([SWS_TS_01107]). Demgegenüber aktualisiert UpdateTime() die Uhrzeit zunächst ausschließlich lokal; die Übertragung auf den Bus erfolgt verzögert im regulären Folgezyklus des Zeitübertragungsprotokolls ([SWS_TS_01108]). Beide Methoden nehmen neben dem Zeitstempel strukturierte UserData entgegen, um synchronisationsbegleitende Zusatzinformationen netzwerkweit zu verteilen ([SWS_TS_01112], [SWS_TS_01113]).

Zur Feinjustierung von Quarzoszillatoren und Vermeidung abrupter Phasensprünge ermöglicht SetRateCorrection() das Einprägen eines relativen Frequenzkorrekturfaktors ([SWS_TS_01110]). Ergänzend liefert GetRateDeviation() die aktuell anliegende Taktabweichung ([SWS_TS_01111]), während GetCurrentTime() den absoluten Zeitwert der Uhr unabhängig vom gegenwärtigen Synchronisationsstatus ausliest ([SWS_TS_01109]).

Integritätssicherung über Time Validation und Freshness Value Management

In sicherheitskritischen und hochautomatisierten Fahrumgebungen genügt die bloße Übernahme von Zeitwerten nicht; die Korrektheit und Manipulationssicherheit der Zeitstempel muss kontinuierlich validiert werden (AUTOSAR_AP_SWS_TimeSynchronization S. 38). Hierfür bietet tsync Callback-Schnittstellen für Time Validation: Konsumenten registrieren sich über RegisterTimeValidationNotification() ([SWS_TS_01016]), Provider analog über die provider-spezifische Methode ([SWS_TS_01114]).

Die Validierungsschnittstellen ConsumerTimeBaseValidationNotification und ProviderTimeBaseValidationNotification übergeben detaillierte Messdatensätze an spezialisierte Überwachungsapplikationen ([SWS_TS_01300], [SWS_TS_01301]). An der Master-Station liefert SetMasterTimingData() den Egress-Zeitstempel (syncEgressTimestamp) und die Sequenznummer (sequenceId) der gesendeten Sync-Frames ([SWS_TS_00421], [SWS_TS_14141], [SWS_TS_14142]). Auf Slave-Ebene übergibt SetSlaveTimingData() die korrespondierenden Ingress-Zeitstempel (syncIngressTimestamp), das empfangene Korrekturfeld (correctionField) sowie die gemessene Pfadverzögerung (pDelay) ([SWS_TS_00420], [SWS_TS_14152], [SWS_TS_14153], [SWS_TS_14155]). Für Peer-to-Peer-Verzögerungsmessungen stellen SetPdelayInitiatorData() und SetPdelayResponderData() die Ein- und Ausgangszeitpunkte der Anforderungs- und Antwortpakete vollständig bereit ([SWS_TS_00422], [SWS_TS_00423], [SWS_TS_14160], [SWS_TS_14170]).

Zum Schutz gegen Replay-Angriffe und zur Absicherung übertragener Zeitnachrichten integriert die Plattform das Freshness Value Management (FVM) über native Schnittstellen im Namensraum apext::tsync ([SWS_TS_14198], EXP_SWArchitecture S. 83). Beim Hochfahren initialisiert Initialize() das zuständige FVM-Plugin ([SWS_TS_14200]). Vor dem Senden ruft der Stack GetTxFreshness() auf, um frische Zählerwerte abzurufen ([SWS_TS_14199]), während beim Empfang GetRxFreshness() zur Verifikation und Authentifizierung herangezogen wird ([SWS_TS_14198]). Daten werden hierbei über den standardisierten FVContainer transportiert ([SWS_TS_14195], [SWS_TS_14196]).

Sequenzdiagramm: Validierungsfluss von Timing-Messdaten zwischen Master, Slave und externer Validator-Applikation. Quellen: [SWS_TS_00420], [SWS_TS_00421], AUTOSAR_AP_SWS_TimeSynchronization S. 38

Konfiguration, Prozessbindung und Manifest-Modellierung

Die Allokation und funktionale Bindung des Clusters erfolgt deklarativ in den AUTOSAR-Modellmanifesten (AUTOSAR_AP_TPS_ManifestSpecification S. 590). Im Machine Manifest wird der Plattform-Daemon über das Metamodell-Element TimeSyncModuleInstantiation auf einer konkreten Machine instanziiert und verwaltet dort die physischen sowie virtuellen TimeBaseResource-Objekte (AUTOSAR_AP_TPS_ManifestSpecification S. 590).

Auf Applikationsebene deklarieren Prozesse über Port-Prototypen (RPortPrototype für Consumer bzw. PPortPrototype für Provider) ihren Bedarf an Zeitbasen (AUTOSAR_AP_TPS_ManifestSpecification S. 599). Das Metamodell-Konstrukt TimeSyncPortPrototypeToTimeBaseMapping verknüpft diese Ports prozessindividuell mit den auf der Maschine definierten Zeitbasen (TPS_ManifestSpecification S. 599; AUTOSAR_AP_TPS_ManifestSpecification S. 600). Zur Laufzeit wird die Instanziierung im Code über den typsicheren ara::core::InstanceSpecifier vorgenommen, wodurch der Stack die korrekte konfigurierte Zeitbasis bindet ([SWS_TS_01001], [SWS_TS_01101]).

Verhalten im Fehlerfall

Fehlersituationen im Time-Synchronization-Cluster werden über das standardisierte Fehlermodell der Adaptive Platform (ara::core::Result und ara::core::ErrorCode) signalisiert ([SWS_TS_00910]). Für reguläre Zeitbasisoperationen definiert die Enumeration TsyncErrc die Fehlercodes ([SWS_TS_00901]). Bricht beispielsweise die Interprozesskommunikation zum Plattform-Daemon ab, wird der Fehlercode kDaemonConnectionLost zurückgegeben ([SWS_TS_00901]).

Über die globale Fehlerdomäne TsyncErrorDomain können Fehlercodes inspeziert ([SWS_TS_00905], [SWS_TS_00906], [SWS_TS_00907]) oder bei aktivierten C++-Exceptions über ThrowAsException() als TsyncException geworfen werden ([SWS_TS_00903], [SWS_TS_00908], [SWS_TS_00909]). Für das Freshness Value Management existiert eine eigenständige Fehlerdomäne TsyncFvmErrorDomain mit der Enumeration TsyncFvmErrc ([SWS_TS_14201], [SWS_TS_14202]). Schlägt die Initialisierung fehl, liefert Initialize() den Fehler kFVInitializeFailed ([SWS_TS_14200]), während bei nicht verfügbaren Zählern für Authentifizierungsprüfungen kFVNotAvailable gemeldet wird ([SWS_TS_14202]).

Auf funktionaler Ebene signalisiert der Cluster den Verlust von Zeitnachrichten nicht zwingend über synchrone API-Fehler, sondern markiert die Zeitbasis im Statusobjekt mit dem Kommunikationsstatus kTimeOut ([SWS_TS_01050]) bzw. setzt das entsprechende Bit in timeBaseStatus ([SWS_TS_01403]). Interpretation: Die Applikation dürfte somit stets in der Pflicht stehen, nach GetTimeWithStatus() den Gültigkeitsstatus des Snapshots aktiv zu prüfen, bevor Messwerte für sicherheitskritische Regelschleifen herangezogen werden. Frage Q-0cd9bb48452ae3db (offen)

Weiterführende Detailbelege

Die Kernanforderungen und Spezifikationspunkte des Moduls tsync lassen sich folgenden Schwerpunkten zuordnen:

• Laufzeitschnittstellen für Consumer und Provider: Die Lebenszyklus- und Abrufoperationen basieren auf [SWS_TS_01001] bis [SWS_TS_01019] sowie den Provider-Funktionen [SWS_TS_01101] bis [SWS_TS_01115] (EXP_SWArchitecture S. 80, EXP_SWArchitecture S. 81).
• Statusstrukturen und Zeitrepräsentation: Definition von SynchronizedTimeBaseStatus, SynchronizationStatus und LeapJump nach [SWS_TS_01050] bis [SWS_TS_01062] sowie Standard-Chrono-Typen gemäß [SWS_TS_01251] bis [SWS_TS_01265].
• Time Validation und Messdatenerfassung: Definition der Messstrukturen und Notifizierungs-Callbacks gemäß [SWS_TS_00420] bis [SWS_TS_00423] sowie [SWS_TS_14140] bis [SWS_TS_14174] (AUTOSAR_AP_SWS_TimeSynchronization S. 38).
• Sicherheitserweiterung FVM: Authentifizierung und Frischeprüfung über Schnittstellen [SWS_TS_14195] bis [SWS_TS_14213] (AUTOSAR_AP_EXP_SWArchitecture S. 83).
• Manifest-Modellierung: Deklarative Konfiguration und Zuordnung von Prozessen und Port-Prototypen zu Zeitbasen gemäß AUTOSAR_AP_TPS_ManifestSpecification S. 590 und AUTOSAR_AP_TPS_ManifestSpecification S. 599.