Zeitsynchronisierung

Die Software Defined Vehicle (SDV)-Plattform von AAOS definiert Standardmechanismen für die Meldung von Zeitquellen von elektronischen Steuergeräten (Electronic Control Units, ECUs) und Standardschnittstellen für die Bereitstellung von Zeitinformationen in SDV-Instanzen. Auf dieser Seite finden Sie Details und Anleitungen zum SDV-Standard.

Taktarchitektur

Die SDV-Plattform hat zwei Standardtakte:

  • UTC-Takt:Dies ist der Standardtakt für die koordinierte Weltzeit. SOME/IP stellt diesen in der Regel von ECUs an die Plattformlaufzeit bereit. Anwendungsfälle sind z. B. die Aktualität von Zertifikaten, die Diagnose und V2X.

  • Monotoner Netzwerktakt:Dies ist ein nicht abnehmendes, hochgenaues Taktsignal von ECUs, das von der umfassenderen Fahrzeugarchitektur verwendet wird, um die Koordination von Ereignissen zu gewährleisten. ECUs stellen diesen über gPTP für die SDV-Plattform bereit. Dieser Takt wird auch als konstanter Takt bezeichnet.

Für Takte in der SDV-Plattform gelten bestimmte architektonische Anforderungen:

  • Taktbereitstellung:Jede VM-Instanz erhält Zugriff auf dasselbe monotone Taktsignal, das von den ECUs bereitgestellt wird.

  • Taktintegrität:Der monotone Netzwerktakt sollte eine zuverlässige Quelle für die Koordination von Ereignissen über verschiedene Dienste hinweg sein. Der Schutz vor möglichen Systemschwachstellen wie Replay-Angriffen oder Zeitumkehr basiert auf der Integrität des monotonen Takts.

  • Verwendung von Alarmen:Die Takt-APIs der SDV-Plattform sollten nicht für Ereignisse mit hoher Frequenz (> 100 Hz) oder einer Latenz von < 10 ms zwischen Planung und Ereigniszeit verwendet werden. Für APIs mit hoher Frequenz oder niedriger Latenz sollte ein Kerneltreiber verwendet werden.

Uhr-APIs

Der monotone Netzwerktakt wird über die Standard-API clock_gettime(3) bereitgestellt:

// Network monotonic clock uses standard Linux API.
// This is represented as a dynamic clock in clock_gettime(3)
clock_gettime(clockid_t id, &timespec)

Dieser Takt wird über einen PTP-Netzwerkmechanismus für alle VMs bereitgestellt und als dynamischer Takt für clock_gettime(3) registriert.

Der UTC-Takt wird in clock_gettime(3) durch CLOCK_REALTIME dargestellt.

Optionaler Gerätetreiber

OEMs haben die Möglichkeit, einen Linux-Geräteblock für zusätzliche Zeiteigenschaften bereitzustellen. Dies kann mit der Berechtigungsverwaltung über sepolicy erfolgen:

# in device/OEM/target/sepolicy/time/file_contexts
/dev/sdvtime u:object_r:time_device:s0

OEMs sind für die Entwicklung und die Funktionen des benutzerdefinierten Linux-Gerätetreibers verantwortlich, der APIs für den Geräteblock bereitstellt.

Benachrichtigungen und Callbacks

Benachrichtigungen und Callbacks für Zeitkomponenten in SDV sind Userland-Funktionen, die vom OEM bereitgestellt werden. Die SDV-Plattform bietet keine spezifischen APIs für diese Funktionen.

Pro VM, die eine Zeitsynchronisierungsfunktion benötigt, sollte maximal ein OEM-Dienst vorhanden sein, der alle relevanten Zeitänderungen überwacht. Ein Beispiel: Wenn sich der vertrauenswürdige Status für die aktuelle Zeitquelle ändert:

  • Änderungen an Zeitquellenstatus sind Ereignisse mit niedriger Frequenz. Ein OEM-Dienst kann Änderungen daher beispielsweise einmal pro Minute durch Polling prüfen.

  • ECUs kommunizieren den vertrauenswürdigen Status des UTC-Takts über das Netzwerk, z. B. über SOME/IP.

  • Ein OEM-Dienst veröffentlicht bestimmte Data Tunnel-Themen , um diese Änderungen für Abonnenten bereitzustellen.

  • OEMs passen die Autorisierungsrichtlinie für Dienste an, um festzulegen, welche Dienste diese Data Tunnel-Themen abonnieren können, um Änderungen am vertrauenswürdigen Zeitstatus zu verfolgen.

Fehlerstatus und -behandlung

Fehlercodes folgen den Konventionen der beteiligten Standard-Linux-APIs, z. B.:

  • Wenn clock_gettime() fehlschlägt, wird -1 zurückgegeben und errno wird festgelegt. Das bedeutet, dass der Taktvorgang nicht unterstützt wird oder die zugrunde liegende Taktquelle nicht bereit ist.

  • Wenn fopen() fehlschlägt, wird ein Nullzeiger zurückgegeben und errno wird festgelegt. Das bedeutet, dass das Blockgerät nicht verfügbar ist.

  • Wenn ein ioctl()-Aufruf fehlschlägt, wird -1 zurückgegeben und errno wird festgelegt. Das bedeutet, dass der angegebene Anforderungscode keine passende Antwort vom zugrunde liegenden Treiber hat.