Entwurf einer äußerst umfassenden Systemzeitsynchronisationslösung für das autonome Fahrsystem der nächsten Generation

Das autonome Fahrsystem der nächsten Generation muss verschiedene Sensoren wie mehrere Laserradare, mehrere Millimeterwellenradare und mehrere Kameras verwenden. Es gibt eine Verzögerung von der Datenerfassung bis zur Verarbeitung und dem Senden an die Domäne Controller 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.

Übersicht

Um das Prinzip der Uhrensynchronisation klar zu erklären, müssen wir zunächst die beiden Typen erklären der Uhrensynchronisation: Datenuhren und Uhrenverwaltung. Zunächst wird die vom kombinierten Trägheitsnavigationssystem bereitgestellte UTC-Zeit verwendet, um dem Zeitsynchronisierungsserver über PPS+GPRMC Zeitmessung bereitzustellen. 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.

Die Datenebene zwischen HPCs SOC und MCU Die Zeit wird über das gPTP-Protokoll synchronisiert, wobei der SOC der Master ist. Die Managementebenenzeit zwischen dem HPC-SOC und der MCU wird über das HPC-Privatprotokoll synchronisiert, und der SOC ist der Master und wird über die Ethernet-Verbindung synchronisiert.

Während des Synchronisationsprozesses zwischen SOC und MCU werden die Datenebene im Rahmen ihrer Zeitsynchronisationsgenauigkeitsanforderungen synchronisiert 250 Mikrosekunden, der Verwaltungstakt. 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 kalibriert bei Bedarf entsprechend der tatsächlichen Situation) 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.

HPC- und VDC-Synchronisationsprozess

Die gesamte Synchronisationskategorie umfasst hauptsächlich zentrale Domänencontroller und Gateways, 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.

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. Durch die Informationsübertragung von VDC können Synchronisations- und Kommunikationsfunktionen zwischen Domänencontrollern 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 die festen HPC- und VDC-Zeiträume mit ganzzahligen Vielfachen der Genauigkeit (z. B. 125 Millisekunden) synchronisiert werden.

HPC-Lokalnetzwerkknoten-Synchronisationsprozess

HPC-Lokalnetzwerkknoten-Synchronisationsprozess bezieht sich auf den Synchronisationsprozess 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 dienen als Slave-Knoten zur Zeitsynchronisation mit dem Gateway.

Es umfasst hauptsächlich drei Hauptsensoren wie folgt:

• Visuell Sensor: Unterscheidet sich durch Kameras zur Fahrkontrolle und Parkkontrolle.

Fahrkameras umfassen hauptsächlich Frontkameras, Seitenkameras und Rückfahrkameras beziehen sich hauptsächlich auf Surround-View-Kameras; Es wird eine zentralisierte Lösung übernommen. Die neueste Kamera ist normalerweise kein All-in-One-Gerät mehr, sondern ein einfacher Sensor, und die Eingabe ist das Originalbild.

HPC und Kamera übertragen Daten über Videodatenkabel wie GSML oder LVDS. HPC verwendet seine Datenuhr (d. h. Systemzeit, nicht absolute Zeit) als Zeitquelle. Das Triggersignal wird in regelmäßigen Abständen an die Kamera gesendet und die Kamera passt die Belichtungszeit basierend auf dem Echtzeit-Triggersignal 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 (wird wie folgt berechnet), und die Zeitgenauigkeit muss innerhalb von 10 ms liegen. Tmidtime Imaging Center = 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 die Belichtungsdauer angepasst werden, um die Genauigkeit des Zeitstempels zu verbessern kompensiert, um den Belichtungsendpunkt der mittleren Reihe zu erhalten. Stellt den mittleren Belichtungszeitpunkt des gesamten Bildes dar. Für die Zeitkompensation wird normalerweise die folgende Formel verwendet.

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

Domäne Controller-Aufzeichnung Die Zeit umfasst die folgenden fünf Momente: die Zwischenzeit der Kamerabildgebung, die Zeit, zu der das Bild in das Wahrnehmungsmodul eintritt, die Zeit, zu der das Bildwahrnehmungsergebnis in das Fusionsmodul eintritt, die Zeit, zu der das Wahrnehmungsfusionsergebnis gesendet wird, und der Zeitpunkt, zu dem das Downstream-Modul es empfängt.

• # 🎜 🎜#Lidar: Derzeit wird hauptsächlich halbfestes Laserradar 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 Sklave. 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 ms betragen). Der Lidar muss die Zeit entsprechend diesem Synchronisationsprozess in Echtzeit aktualisieren. Darüber hinaus muss das Lidar die Zeit jedes Punkts in der Punktwolke jedes Frames als Zeitanforderung für den Zeitstempel des Sensors ausgeben (die Genauigkeitsanforderung liegt innerhalb von 1 ms). #?? Es empfängt die reflektierte Signalzeit.) Geben Sie den Zeitstempel des Domänencontrollers ein (normalerweise verfügt der Lidar zu diesem Zeitpunkt bereits über die entsprechenden Zeitinformationen, und HPC muss den Zeitstempel des Lasererfassungsmoduls nicht eingeben (normalerweise führt der Lidar-Anbieter dies durch). Ursprüngliche Punktwolken-Informationsverarbeitung: Wenn es sich um eine zentralisierte Lösung handelt, ist das SOC in HPC für die Front-End-Punktwolkenerfassung verantwortlich, und das proprietäre SOC führt die Erfassung und die Back-End-Fusion durch. Die Erfassungsergebnisse werden an das Downstream-Modul gesendet ein Zeitstempel für den Empfang; und dieser ist erforderlich. Setzen Sie den letzten Zeitstempel. 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.

• Millimeterwellenradar: bezieht sich hauptsächlich auf Vorwärts-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 weiter zu synchronisieren Informationen. Prozesssynchronisation. 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. Da die Mikrowellensignalverarbeitung von Millimeterwellenradar jedoch immer noch sehr schwierig ist, verwenden viele OEMs für die nächste Generation autonomer Fahrsysteme immer noch Daten auf Zielebene für die direkte Verbindung. Die Zeitsynchronisationsgenauigkeit erfordert normalerweise einen größeren Bereich von Lidar 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.

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 ihnen 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.

Zeitsynchronisationsprozess von HPC-externen Netzwerkknoten

Zusätzlich zur internen Netzwerkknotenzeitsynchronisation, z 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-Zeitsynchronisationsbeziehung 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.

Zeitsynchronisationsprozess im HPC-Sicherheitsredundanzkontrollprozess

Für das gesamte autonome Fahrsystem muss die entsprechende Fehlerkontrolllogik während des Zeitsynchronisationsprozesses 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.

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

Ein weiterer Fehlermodus ist eine Funktionsbeeinträchtigung, die durch einen Ausfall der Stromversorgung verursacht wird. 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. Wenn sich der Controller im leichten Ruhezustand befindet, 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).

Zusammenfassung

In diesem Artikel wird das Zeitsynchronisationsprinzip jeder Steuereinheit des autonomen Fahrsystems der nächsten Generation ausführlich erläutert und die Genauigkeitsanforderungen für jedes Modul im Synchronisationsprozess dargelegt, einschließlich der lokalen Netzwerkknotensynchronisation und globale 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. Hierbei 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 vonEntwurf einer äußerst umfassenden Systemzeitsynchronisationslösung für das autonome Fahrsystem der nächsten Generation. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!