Heim >Technologie-Peripheriegeräte >KI >Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

WBOY
WBOYnach vorne
2023-04-29 20:55:051410Durchsuche

Das autonome Fahrsystem der nächsten Generation muss verschiedene Sensoren wie Multi-Lidar, Multi-Millimeter-Wellenradar, Multi-Kamera usw. verwenden. Es gibt eine Verzögerung von der Datenerfassung über die Verarbeitung bis hin zum Senden an die Domänencontroller und die Länge der Verzögerung ist instabil. Um die Leistung des autonomen Fahrens wie Sensorfusion, Entscheidungsplanung und Fusionspositionierung zu verbessern, müssen der Advanced Domain Controller HPC und die zugehörigen Sensoren zeitlich synchronisiert werden. Der eigentliche Prozess besteht darin, die Zeitstempelinformationen des Sensors klar zu definieren Eingabedaten (einschließlich der Zeit- und Genauigkeitsanforderungen) und müssen außerdem den gesamten Zeitsynchronisierungsplan und die Anforderungen an die Synchronisierungsgenauigkeit definieren.

1 Überblick

Um das Prinzip der Uhrensynchronisation klar zu erklären, müssen wir zunächst die beiden erklären Arten der Uhrensynchronisation: Datenuhr und Verwaltungsuhr.

Zunächst wird die von der kombinierten Trägheitsnavigation bereitgestellte UTC-Zeit verwendet, um den Zeitsynchronisationsserver über PPS+GPRMC zu messen. Der Zeitsynchronisationsserver stellt über das PTP-Protokoll und das zentrale Gateway entsprechende Zeitinformationen für verschiedene Sensordatenerfassungshosts bereit. HPC muss den Zeitsynchronisierungsprozess zwischen dem internen SOC und der MCU implementieren.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Die Datenebenenzeit zwischen dem SOC und der MCU von HPC wird über die gPTP-Protokollzeit synchronisiert, wobei der SOC der ist Master ;

Die Managementebenenzeit zwischen HPCs SOC und MCU wird über das HPC-Privatprotokoll synchronisiert. Das SOC ist der Master und wird über die Ethernet-Verbindung synchronisiert.

Während des Synchronisierungsprozesses zwischen SOC und MCU werden die Verwaltungsuhr und die Datenuhr synchronisiert. Die Datenebene verwendet das gPTP-Protokoll und die Verwaltungsuhr befindet sich innerhalb der Anforderung an die Zeitsynchronisationsgenauigkeit von 250 Mikrosekunden. Bei Verwendung eines proprietären Protokolls, auch über Ethernet, beträgt die Genauigkeit 10 ms. Die interne Verwaltungszeit und die Datenebenenzeit müssen aufeinander abgestimmt sein. HPC muss die Kontinuität der Datenuhr gewährleisten und darf keine abnormalen Sprünge zulassen. Denn abnormale Sprünge können zu schwerwiegenden Datenfehlkommunikationen und Fehlinterpretationen führen.

Bei jedem Kaltstart des Domänencontrollers versucht der Domänencontroller für einen bestimmten Zeitraum (dieser Zeitraum kann ...) mit dem Knoten zu kommunizieren, der die Hauptuhr bereitstellt (bei Bedarf entsprechend der tatsächlichen Situation kalibriert) Kommunikation für die anfängliche Synchronisierung. Bei erfolgreicher Synchronisierung synchronisiert die Datenuhr mit der aktuellen Verwaltungszeit die ermittelte Absolutzeit; der entsprechende Treiber kann damit gestartet werden und die entsprechende Anwendungssoftware zur Berechnung aufrufen. Wenn die Synchronisierung nicht erfolgreich ist, versucht der Domänencontroller weiterhin, eine Synchronisierung durchzuführen.

2 Synchronisationsprozess von HPC und VDC

Die gesamte Synchronisationskategorie umfasst hauptsächlich den zentralen Domänencontroller und Gateway, Synchronisation zwischen verschiedenen Sensoren und Aktoren. Die absolute Zeit von HPC stellt in der Regel eine einheitliche Zeitquelle für alle Controller des Fahrzeugs über das zentrale Gateway CGW bereit und gibt den gesamten Synchronisationszeitstempel an alle zugehörigen Controller aus (z. B. Body Domain Controller PDC, Vehicle Domain Controller VDC, Cockpit Domain Controller CSC). , usw.). In der Architektur des autonomen Fahrsystems der nächsten Generation übernimmt der Fahrzeugdomänencontroller VDC nicht nur die Funktion der Steuerung des Betriebs des Fahrzeugaktuators, sondern dient auch als zentrales Gateway CGW, das die Informationsinteraktion und Protokolle zwischen HPC und anderen Domänencontrollern überträgt. Transformationsfunktion.

Die folgende Abbildung zeigt die Verbindungsbeziehung zwischen dem automatischen Fahrcontroller HPC und dem zugehörigen Domänencontroller.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Wie oben erwähnt, kann VDC als zentrales Gateway fungieren, also als HPC-zentrierter Synchronisationsprozess zwischen Controllern Der Schwerpunkt liegt auf dem Synchronisierungsprozess zwischen HPC und VDC. Synchronisierungs- und Kommunikationsfunktionen zwischen Domänencontrollern können durch VDC-Informationsübertragung realisiert werden. Jeder Controller ist hauptsächlich direkt über Ethernet verbunden, wobei das Ethernet-basierte gPTP-Protokoll verwendet wird. Der Synchronisationsprozess zwischen HPC und VDC muss die absolute Zeit des direkt mit dem HPC verbundenen GNSS-Eingangs als Hauptuhr berücksichtigen, und der Zeitfehler ist relativ gering (normalerweise innerhalb von 10 ms). In Anbetracht der Genauigkeit der Smart-Driving-Big-Data-Cloud-Analyse und der Tatsache, dass die Genauigkeit des gPTP-Protokolls normalerweise innerhalb von 250 Mikrosekunden liegen muss, können feste HPC- und VDC-Zyklen mit ganzzahligen Vielfachen der Genauigkeit (z. B. 125 Millisekunden) synchronisiert werden.

3 Synchronisierungsprozess des lokalen HPC-Netzwerkknotens

Der Synchronisierungsprozess des lokalen HPC-Netzwerkknotens bezieht sich auf den Synchronisierungsprozess zwischen ihm und dem Sensor. Im privaten internen Netzwerk für autonomes Fahren wird der Domänencontroller als Masterknoten und die entsprechende Datenendzeit als Zeitquelle verwendet. HPC bietet über das lokale Intranet eine einheitliche Zeitquelle für Sensoren (Lidar, Millimeterwellenradar, Fahrkamera, Rundumsichtkamera, kombinierte Trägheitsnavigation usw.). Dabei werden Lidar und kombinierte Trägheitsnavigation über Ethernet (1PPS reserviert), Millimeterwellenradar und Ultraschallbox PDC über CANFD/Ethernet und Kameras (einschließlich Fahr-/Rundumsichtkameras) über GSML/LVDS verbunden. Derartige unterschiedliche Netzwerkverbindungsformen werden als Slave-Knoten zur Zeitsynchronisation mit dem Gateway verwendet.

Es umfasst hauptsächlich drei Hauptsensoren wie folgt:

Visueller Sensor

Unterteilt durch Kameras für die Fahrkontrolle und die Parkkontrolle.

Zu den Fahrkameras gehören hauptsächlich Frontkameras, Seitenkameras und Rückfahrkameras, bei denen es sich in der Regel nicht mehr um All-in-One-Kameras handelt, die zentralisierte Lösungen verwenden einfache Sensoren, die Eingabe ist das Originalbild.

HPC und Kamera übertragen Daten über Videodatenkabel wie GSML oder LVDS. HPC verwendet seine Datenuhr (d. h. die Systemzeit, nicht die absolute Zeit) als Zeitquelle, um regelmäßig Triggersignale an die Kamera zu senden basiert auf Echtzeit. Das Triggersignal passt die Belichtungszeit an. Da der entsprechende Zeitstempel nicht direkt in einer einzelnen Kamera aufgezeichnet werden kann, wird zur Synchronisierung die Synchronisationstriggerung mehrerer Kameras verwendet, und der Zeitpunkt, zu dem das Triggersignal im Domänencontroller aufgezeichnet wird, wird als anfänglicher Zeitstempel des Bildes verwendet.

Die Kamera versieht den Bildgebungsprozess immer mit einem Zeitstempel (Berechnungsmethode unten), und die Zeitgenauigkeit muss innerhalb von 10 ms liegen.

Tmidtime Imaging Mitte = Ttrigger (Triggerzeit) + 1/2*Texposure (Belichtungszeit);

Die Belichtungszeit in der obigen Formel ist festgelegt.

Da der Auslösezeitpunkt am Ende der Belichtung des gesamten Einzelbildes liegt, muss zur Verbesserung der Genauigkeit des Zeitstempels die Belichtungsdauer kompensiert werden, um den Belichtungsendpunktzeitpunkt der mittleren Reihe zu erhalten um den mittleren Belichtungszeitpunkt des gesamten Bildes darzustellen; normalerweise wie folgt: Formel für die Zeitkompensation.

Tcompensate (Kompensationszeit) = Länge jeder Zeile × Gesamtzahl der Zeilen/2

 Die Aufzeichnungszeit des Domänencontrollers umfasst die folgenden fünf Zeiten: die Zwischenzeit der Kameraaufnahme und die Zeit, zu der das Bild eintritt Das Erfassungsmodul und das Bilderfassungsergebnis Die Zeit des Fusionsmoduls, die Sendezeit des Wahrnehmungsfusionsergebnisses und die Empfangszeit des Downstream-Moduls.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Lidar

Derzeit wird hauptsächlich halbfestes Lidar verwendet.

HPC und Lidar basieren normalerweise auf dem Ethernet-gPTP-Protokoll in Kombination mit einer Gigabit-Ethernet-Direktverbindung. HPC ist der Master-Knoten und Lidar der Slave-Knoten. Die HPC-Synchronisationszeitquelle verwendet die absolute Zeit (d. h. Systemzeit) als Datenuhr, und die Anforderung an die Genauigkeit der Zeitsynchronisation liegt immer noch innerhalb von 250 Mikrosekunden. HPC und Lidar verwenden für die Synchronisation ein ganzzahliges Vielfaches der Synchronisationszeitgenauigkeit (sie kann beispielsweise 125 Millisekunden oder 250 Millisekunden betragen). Das Lidar muss die Zeit entsprechend diesem Synchronisationsprozess in Echtzeit aktualisieren. Darüber hinaus muss das Lidar die Zeit jedes Punkts in jedem Frame der Punktwolke als Zeitanforderung für den Zeitstempel des Sensors ausgeben (die Genauigkeitsanforderung liegt innerhalb von 1 ms).

In ähnlicher Weise muss der Domänencontroller den Moment aufzeichnen, in dem die Laserpunktwolke gesendet wird, basierend auf der Lidar-Rückkehrzeit (d. h. den Moment, in dem der Lidar jeden Punkt aufzeichnen kann, wenn er das reflektierte Signal empfängt). ; Geben Sie den Zeitstempel des Domänencontrollers ein (normalerweise verfügt der Lidar zu diesem Zeitpunkt bereits über entsprechende Zeitinformationen, HPC muss den Zeitstempel des Lasererfassungsmoduls nicht stempeln (im Allgemeinen verarbeitet der Lidar-Anbieter die ursprünglichen Punktwolkeninformationen, falls vorhanden). Eine zentralisierte Lösung: Das SOC in HPC ist für die Front-End-Punktwolkenerfassung verantwortlich, und das proprietäre SOC führt die Erfassung und Back-End-Fusion durch. Die Erfassungsergebnisse werden mit einem Zeitstempel für den Empfang und dem letzten Zeitstempelbedarf gesendet zu diesem Zeitpunkt abgestempelt werden. Bei der Laser-Punktwolkenerfassung wird der Datentakt des Domänencontrollers hauptsächlich für das Design von Erfassungsalgorithmen verwendet (solche Algorithmen können sich im Auto oder in der Wolke befinden), während die absolute Zeit hauptsächlich die Ortszeit umfasst und hauptsächlich zur Datenaufzeichnung und -erfassung verwendet wird Speicherdienste.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Millimeter-Radar#🎜 🎜 #

bezieht sich hauptsächlich auf Front-Millimeterwellenradar und Winkel-Millimeterwellenradar.

Normalerweise synchronisiert das vordere Millimeterwellenradar die Informationen separat, während die Winkel-Millimeterwellenradargruppe selbst über ein Hauptradar verfügt, um alle ihre Informationen weiter zu synchronisieren. Im Allgemeinen verwenden Millimeterwellenradar-Eingabedaten für die vorherige Generation normalerweise Daten auf Zielebene. Nachdem der Domänencontroller der nächsten Generation jedoch eine zentralisierte Lösung übernommen hat, wird dies bei der Aufrüstung des 3D-Millimeterwellenradars auf das 4D-Millimeterwellenradar der Fall sein Der Ruf nach Millimeterwellenradar-Punktwolken wird immer lauter. Dabei verfügt das Millimeterwellenradar nicht mehr über eine Recheneinheit, sondern gibt lediglich Punktwolkendaten ein.

Aufgrund der hohen Schwierigkeit der Mikrowellensignalverarbeitung von Millimeterwellenradaren verwenden viele OEMs jedoch für die nächste Generation autonomer Fahrsysteme immer noch Daten auf Zielebene Direkte Verarbeitung Auch wenn die Genauigkeit der Zeitsynchronisation normalerweise als LIDAR bezeichnet wird, ist die Anforderung breiter und liegt normalerweise innerhalb von 1 ms. Die Zeit zwischen dem Aussenden des Punktwolken-Millimeterwellenradars und dem Empfang des Echos wird als Zeitstempel markiert und die Genauigkeit muss innerhalb von 1 ms liegen.

Gleichzeitig werden HPC und Millimeterwellenradar synchronisiert, indem ein Periodenintervall von 1-2 Sekunden eingestellt wird. Während dieses Zeitraums aktualisiert das Millimeterwellenradar die entsprechende Zeit in Echtzeit. In ähnlicher Weise unterstützt der Domänencontroller die Aufzeichnung von Zeitstempeln, die die folgenden fünf Momente basierend auf der Millimeterwellenradar-Rückkehrzeit enthalten:

Echo-Reflexionspunkt-Erzeugungs-Zeitstempel, Echoeingabe in den Domänencontroller Zeitstempel (für Datensätze auf Zielebene verfügt das Millimeterwellenradar natürlich über Zeitstempelinformationen, und die vom Millimeterwellenradar ausgegebenen Zielinformationen werden durch Clustering und Filterung der ursprünglichen Reflexionspunkte erhalten.) Um einen genaueren Zeitstempel zu erhalten, ist es normalerweise erforderlich, den Zeitstempel des Zeitpunkts zu erhalten, zu dem der ursprüngliche Reflexionspunkt generiert wurde, wie im roten Teil der folgenden Abbildung dargestellt.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Die Erfassungsergebnisse werden an einen dedizierten SOC/MCU gesendet und mit anderen Sensoren für große Zeitstempel zusammengeführt. Ebenso wird die Datenzeit (oder lokale Zeit) des Domänencontrollers für Algorithmusentwurfsvorgänge verwendet, während die absolute Zeit für Datenaufzeichnungs- und Speichervorgänge verwendet wird.

HPC muss die Pakete von intelligenten Kameras und Radargeräten mit einem zusätzlichen Zeitstempel versehen, der dem Zeitpunkt entspricht, an dem die Pakete eintreffen, und die Daten überhaupt mit einem Zeitstempel im Erfassungsmodul versehen Zeiten als Backup. Bestätigen Sie mit Millimeterwellenradar, insbesondere Winkelradar. Nur durch Zeitsynchronisationsinformationen können Sie feststellen, ob das Winkelradar das Ziel starten kann.

Kombiniertes Trägheitsnavigationssystem/unabhängiges Trägheitsnavigationssystem#🎜 🎜#

Im autonomen Fahrsystem der nächsten Generation verwenden verschiedene OEMs unterschiedliche Arten der Trägheitsnavigation. Sie werden normalerweise in zwei Typen unterteilt: kombinierte Trägheitsnavigation und unabhängige Trägheitsnavigation, basierend auf ihren Selbstforschungsfähigkeiten. Da die kombinierte Trägheitsnavigation über einen integrierten Satelliten-Trägheits-Kombinationsalgorithmus verfügt, der auf der tatsächlichen Anwendungssituation basiert, erläutern wir hier nur die direkte Verbindung der einfacheren kombinierten Trägheitsnavigation. HPC fungiert als Master-Knoten und das kombinierte Trägheitsnavigationssystem als Slave-Knoten. Es ist über 100M Ethernet direkt mit dem kombinierten Trägheitsnavigationssystem verbunden.

Unter diesen basiert Ethernet immer noch auf dem gPTP-Protokoll. Die HPC-Synchronisationszeitquelle verwendet weiterhin die Datenuhr (d. h. die Systemzeit, nicht die absolute Zeit) zur Synchronisation. Erforderliche Anforderungen an die Zeitsynchronisierungsgenauigkeit: Innerhalb von 250 Mikrosekunden ist der Synchronisierungszeitraum ein ganzzahliges Vielfaches der Anforderungen an die Synchronisierungsgenauigkeit (z. B. 1 Millisekunde oder 125 Millisekunden). Während dieses Zeitraums stempelt die kombinierte Trägheitsnavigation die neueste IMU-Probenahme basierend auf RTK- und IMU-Informationen mit einem Zeitstempel. Seine Genauigkeit ist auf 1 ms begrenzt.

Darüber hinaus werden die Probenahmezeit der IMU, die Zeit des Eintritts in das HPC und die Zeit des Eintritts in das Back-End-Fusionsmodul alle mit einem Zeitstempel versehen.

4 Zeitsynchronisationsprozess externer HPC-Netzwerkknoten

Zusätzlich zur internen Netzwerkknotenzeitsynchronisation, Für das autonome Fahrsystem der nächsten Generation gibt es eine große Menge externer Informationsinteraktion zwischen ihm und den zugehörigen Aktoren (wie dem integrierten Bremssteuersystem EPBi, dem elektronischen Lenksystem EPS und dem Leistungssteuersystem VCU). In Bezug auf die Methode der phasengesteuerten zentralen Steuerung wird diese Art von Fahrzeugsteuerungsanschluss normalerweise über die Fahrzeugsteuerung VDC angeschlossen und synchron gesteuert. Wie oben erwähnt, kann das VDC eigentlich als zentrales Gateway betrachtet werden. Neben der Weiterleitung von Informationen an verschiedene Domänencontroller ist es auch für die Definition und den Versand des gesamten Synchronisationszeitstempels verantwortlich. Denn für das gesamte Fahrzeugsystem wird die gesamte absolute Zeit vom GNSS/GPS bezogen, das mit dem Domänencontroller HPC des autonomen Fahrsystems verbunden ist.

Das zugehörige System führt normalerweise eine unabhängige Zeitsynchronisationssteuerung über den Vehicle Domain Control Port (VDC) durch, sodass normalerweise keine Verbindung zwischen HPC und ESP, EPS und VCU besteht Bei einer direkten Master-Slave-Knoten-Zeitsynchronisierungsbeziehung werden die jeweiligen Zeitstempel während der Ausführung von Anweisungen direkt an den VDC-Controller gesendet und während der Ausführung wird ein Zeitabgleich durchgeführt.

5 Zeitsynchronisationsprozess im HPC-Sicherheitsredundanzkontrollprozess

Für das gesamte autonome Fahrsystem Das heißt , muss die entsprechende Fehlerkontrolllogik während des Zeitsynchronisierungsprozesses noch berücksichtigt werden. Unter Berücksichtigung der unterschiedlichen Funktionen des darin enthaltenen KI-Chips SOC und Logikchips MCU. Normalerweise kommt es zu unterschiedlichen Zeitpunkten, wenn beide ausfallen, zu einem gewissen Grad an Funktionseinbußen. Diese Art des Funktionsabbaus wird als partieller Funktionsabbau bezeichnet. Wenn während einer teilweisen Funktionsverschlechterung ein Teil des SOC ausfällt, synchronisiert sich die MCU über die Wartungszeit des Quarzoszillators mit dem Sensor. Während dieser Zeit können die von Radar und anderen SOCs übermittelten Kamerazieldateninformationen weiterhin empfangen werden und der Ausgabezeitstempel bleibt stabil. Daher kann gesagt werden, dass das System nach einer teilweisen Funktionsherabstufung in kurzer Zeit immer noch den ursprünglichen Zeitstempel für die Reaktion verwendet und die MCU weiterhin die Stabilität der ursprünglichen Zeitdaten aufrechterhalten kann (der Zeitsynchronisationsprozess kann durchgeführt werden). bezogen auf den internen Takt in der MCU), was den Betrieb der Funktion unterstützt. Da der Fehler in einem kurzen Zeitraum sehr gering ist, ist auch das Risiko, dass die Zeit innerhalb dieses Zeitraums nicht synchronisiert wird, sehr gering.

Ein Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem

Wenn der gesamte HPC ausfällt, ist natürlich ein anderer Backup-Controller erforderlich (es kann sich um einen weiteren Low-Profile-Controller handeln). Version) HPC kann auch eine zusätzliche Smart-Kamera (Smart Camera) zur Sicherheitskontrolle sein. Während dieses Vorgangs muss die Zeitsynchronisationsbeziehung zwischen dem Backup-Controller und dem entsprechenden Sensor wiederhergestellt werden.

Ein weiterer Fehlermodus ist die Funktionsbeeinträchtigung durch Stromausfall. Hierbei ist zu beachten, dass es für Domänencontroller zwei Schlafmodi gibt: Tiefschlaf und Leichtschlaf. Dieser Schlafmodus hängt hauptsächlich davon ab, ob die gesamte Stromversorgung unterbrochen werden soll. Befindet sich der Controller im Tiefschlaf, verwendet die Datenuhr direkt die beim letzten Ausschalten gespeicherte Verwaltungsuhr ohne Neuzeitung. Befindet sich der Controller im leichten Ruhezustand, wird die Verwaltungsuhr dieses Ausschaltens direkt für die Zeitmessung verwendet. Im Vergleich zum Tiefschlaf sind die Uhrergebnisse der Leichtschlafsynchronisation genauer. Unabhängig davon, wie tief oder leicht der Schlaf ist, ist die Controller-Uhr in diesem Zeitraum natürlich immer ungültig und die gesamte Software kann nicht normal ausgeführt werden. Natürlich kann die gesamte Umstellungszeit vom Leichtschlaf in den Tiefschlaf individuell angepasst werden (z. B. 12 Stunden).

6 Zusammenfassung

In diesem Artikel wird das Timing jeder Steuereinheit der nächsten Generation ausführlich erläutert Das Synchronisationsprinzip des autonomen Fahrsystems stellt Genauigkeitsanforderungen für jedes Modul im Synchronisationsprozess vor, einschließlich der Synchronisation lokaler Netzwerkknoten und der Synchronisation globaler Netzwerkknoten. Unter diesen zielt die lokale Netzwerkknotensynchronisation hauptsächlich auf die Synchronisationsbeziehung zwischen den Sensoren und der Domänensteuerung innerhalb des autonomen Fahrsystems ab. Die globale Netzwerkknotensynchronisation zielt hauptsächlich auf die Zeitsynchronisationsbeziehung zwischen dem autonomen Fahrsystem und externen zugehörigen Systemen ab (z. B. Steuerung von Bremsen, Lenkung, Leistung, Türen, Lichtern, Gateways usw.).

Für die Gesamtberechnungsgenauigkeit ist die Synchronisierung lokaler Netzwerkknoten von entscheidender Bedeutung, da viele Sensoreinheiten beteiligt sind und jede basierend auf ihrer tatsächlichen Situation einen entsprechenden Zeitstempel haben muss und letztendlich der Domänencontroller die Gesamtsynchronisierung durchführt. Für die Synchronisierung globaler Netzwerkknoten können Zeitinformationen einfach ausgetauscht werden, indem auf die Informationsinteraktion zwischen jedem Subdomänencontroller und dem HPC verwiesen wird. Dabei ist zu beachten, dass die absolute Zeit des gesamten Systems aus dem GNSS-System stammt, das in der Regel per HPC oder CSC angebunden und eingegeben werden kann.

Das obige ist der detaillierte Inhalt vonEin Artikel zur Überprüfung des Designs einer äußerst umfassenden Systemzeitsynchronisierungslösung für das autonome Fahrsystem. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:51cto.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen