DE112019001605T5 - Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen - Google Patents

Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen Download PDF

Info

Publication number
DE112019001605T5
DE112019001605T5 DE112019001605.9T DE112019001605T DE112019001605T5 DE 112019001605 T5 DE112019001605 T5 DE 112019001605T5 DE 112019001605 T DE112019001605 T DE 112019001605T DE 112019001605 T5 DE112019001605 T5 DE 112019001605T5
Authority
DE
Germany
Prior art keywords
data
sensor
virtual
vehicle
simulation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019001605.9T
Other languages
English (en)
Inventor
Clement FARABET
John Zedlewski
Zachary Taylor
Greg Heinrich
Claire Delauney
Mark Daly
Matthew Campbell
Curtis Beeson
Gary Hicok
Michael Cox
Rev Lebaredian
Tony Tamasi
David Auld
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE112019001605T5 publication Critical patent/DE112019001605T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
    • G06F18/2413—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches based on distances to training or reference patterns
    • G06F18/24133—Distances to prototypes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/40—Extraction of image or video features
    • G06V10/44—Local feature extraction by analysis of parts of the pattern, e.g. by detecting edges, contours, loops, corners, strokes or intersections; Connectivity analysis, e.g. of connected components
    • G06V10/443—Local feature extraction by analysis of parts of the pattern, e.g. by detecting edges, contours, loops, corners, strokes or intersections; Connectivity analysis, e.g. of connected components by matching or filtering
    • G06V10/449—Biologically inspired filters, e.g. difference of Gaussians [DoG] or Gabor filters
    • G06V10/451—Biologically inspired filters, e.g. difference of Gaussians [DoG] or Gabor filters with interaction between the filter responses, e.g. cortical complex cells
    • G06V10/454—Integrating the filters into a hierarchical structure, e.g. convolutional neural networks [CNN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/764—Arrangements for image or video recognition or understanding using pattern recognition or machine learning using classification, e.g. of video objects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/82—Arrangements for image or video recognition or understanding using pattern recognition or machine learning using neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Computing Systems (AREA)
  • Biomedical Technology (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Multimedia (AREA)
  • Molecular Biology (AREA)
  • Biophysics (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Neurology (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Automation & Control Theory (AREA)
  • Traffic Control Systems (AREA)

Abstract

In verschiedenen Beispielen können Daten physischer Sensoren von einem Fahrzeug in einer realen Umgebung erzeugt werden. Die Daten physischer Sensoren können dazu verwendet werden, tiefe neuronale Netzwerke (DNNs) zu trainieren. Die DNNs können dann in einer simulierten Umgebung getestet werden - in einigen Beispielen unter Verwendung von Hardware, die für den Einbau in ein Fahrzeug konfiguriert ist, um einen Software-Stack für autonomes Fahren auszuführen - um ein virtuelles Fahrzeug in der simulierten Umgebung zu steuern oder um die Ausgaben der DNNs auf andere Weise zu testen, zu verifizieren oder zu validieren. Vor der Verwendung durch die DNNs können die von virtuellen Sensoren innerhalb der simulierten Umgebung erzeugten Daten virtueller Sensoren in ein Format codiert werden, das mit dem Format der von dem Fahrzeug erzeugten Daten physischer Sensoren konsistent ist.

Description

  • HINTERGRUND DER ERFINDUNG
  • Autonome Fahrzeuge und halbautonome Fahrzeuge stützen sich auf maschinelles Lernen und insbesondere auf tiefe neuronale Netze (deep neural networks, DNNs), um eine beliebige Anzahl von Operationen für den Betrieb, die Steuerung und die Navigation des Fahrzeugs durchzuführen. DNNs können beispielsweise zur Objekterfassung, Erfassung von Fahrspur- und Straßenbegrenzungen, Sicherheitsanalyse, Analyse befahrbaren freien Raums, Steuerungserzeugung während Fahrzeugmanövern und dergleichen verwendet werden. Um jedoch die Verwendung der DNNs in autonomen oder halbautonomen Fahrzeugen zu verifizieren und zu validieren, müssen die DNNs auf einer großen Datenmenge trainiert werden, was einen enormen Aufwand an Zeit und Arbeit erfordert und dennoch nicht immer universell genaue oder verwendbare Ergebnisse garantiert.
  • Beispielsweise stützen sich konventionelle Systeme häufig auf Daten, die von physischen Fahrzeugen generiert werden, die in realen Umgebungen navigieren, um die DNNs vor dem Einsatz in funktionierenden Modellen zu trainieren. Dieser Ansatz hat jedoch mehrere Beschränkungen. Zum Beispiel können Fahrzeuge nur an eine begrenzte Anszahl von Orten navigieren, die Nachbildung gefährlicher oder einzigartiger Situationen ist in der realen Umgebung schwierig, und das Testen der DNNs in diesen realen Umgebungen kann gefährlich sein. Insbesondere dann, wenn ein DNN zur Hindernisvermeidung oder für andere Sicherheitsmaßnahmen verwendet wird, kann das Testen der DNNs in der realen Umgebung nicht praktikabel sein. Andererseits wird ein Autohersteller ein autonomes Fahrzeug nicht in der realen Welt einsetzen, bis ein akzeptables Sicherheitsniveau erreicht worden ist. Infolgedessen machen diese konkurrierenden Interessen die Entwicklung eines soliden, sicheren, genauen und zuverlässigen autonomen Fahrsystems immer schwieriger.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Ausführungsformen der Erfindung beziehen sich auf das Training, das Testen und das Verifizieren autonomer Maschinen unter Verwendung simulierter Umgebungen. Systeme und Verfahren zum Trainieren, Testen und/oder Verifizieren eines oder mehrerer Merkmale eines realen Systems - wie z.B. ein Software-Stack zur Verwendung in autonomen Fahrzeugen und/oder Robotern - werden offenbart.
  • Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, nutzen die erfindungsgemäßen Systeme eine simulierte Umgebung, um einen oder mehrere Software-Stacks für autonomes Fahren zu testen, die eine Vielzahl von DNNs beinhalten. Beispielsweise können Daten physischer Sensoren, Daten virtueller Sensoren oder eine Kombination derselben verwendet werden, um die DNNs des/der Software-Stacks zu trainieren. Nach dem Training können die DNNs in einem Simulationssystem getestet, verifiziert und validiert werden, das eine simulierte Umgebung zur Steuerung eines virtuellen Objekts unter Verwendung des/der Softwarestacks erzeugt. Simulationsdaten aus der simulierten Umgebung können in die DNNs der Software-Stacks eingegeben werden, und die DNNs können Ausgaben erzeugen. In einigen Beispielen können die Ausgaben dazu verwendet werden, das virtuelle Objekt innerhalb der simulierten Umgebung zu steuern, um zu bestimmen, wie sich das virtuelle Objekt (und damit ein physisches Objekt, das dem virtuellen Objekt entspricht) in beliebig vielen verschiedenen Situationen verhalten kann. In anderen Beispielen können die Ausgaben dazu verwendet werden, die Genauigkeit der DNNs zu testen, und können die Ergebnisse dazu verwendet werden, weitere Daten für weiteres Training zu generieren (z.B. Daten, die die DNNs am wenigsten konsistent präzise verarbeiten), eine Feinabstimmung der DNNs vorzunehmen, die DNNs zu verifizieren und/oder die DNNs zu validieren. In jedem Beispiel kann die simulierte Umgebung erzeugt werden, um schwer zu navigierende, gefährliche, unsichere und/oder anderweitig unvorhersehbare Situationen für das zu navigierende virtuelle Objekt zu schaffen. Infolgedessen können zuvor (z.B. aufgrund von Sicherheitsbedenken, Schwierigkeiten bei der Reproduktion usw.) nicht getestete Szenarien innerhalb der simulierten Umgebung getestet, wiederholt und verbessert werden.
  • In einigen Beispielen kann Fahrzeug-Hardware, die für den Einbau in ein autonomes Fahrzeug konfiguriert ist, zur Ausführung des/der Softwarestack(s) innerhalb der simulierten Umgebung verwendet werden. Darüber hinaus können die Daten virtueller Sensoren bzw. virtuellen Sensordaten in ein Format codiert werden, das dem/den Softwarestack(s) vertraut ist (z.B. Bit für Bit identisch mit den Daten physischer Sensoren bzw. physischen Sensordaten, die zum Trainieren der DNNs verwendet werden). Infolgedessen kann das Testen, das Trainieren, das Verifizieren und/oder das Validieren der DNNs im Wesentlichen identisch zu dem Einsatz der Hardware-/Software-Komponenten in einem physischen Fahrzeug in einer realen Umgebung sein.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zum Trainieren, Testen und Verifizieren von autonomen Maschinen unter Verwendung simulierter Umgebungen werden nachstehend unter Bezugnahme auf die beigefügte Zeichnung ausführlich beschrieben, wobei:
    • 1 ein beispielhaftes System für eine Re-Simulation ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 2 ein Datenflussdiagramm für einen Prozess des Testens, Trainierens, Verifizierens und/oder Validierens neuronaler Netzwerke beinhaltet, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 3A-3D Arbeitsabläufe beinhalten, die zum Trainieren von DNNs verwendet werden, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 4A-4F beispielhafte Darstellungen eines Simulationssystems sind, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 5 ein Ablaufdiagramm ist, das ein Verfahren zur Erzeugung einer simulierten Umgebung unter Verwendung eines Hardware-in-the-Loop-Objekts zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6A eine beispielhafte Darstellung eines Simulationssystems zur Laufzeit ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6B eine Cloud-basierte Architektur für ein Simulationssystem beinhaltet, in Übereinstimmung mit einer Ausführungsform der Erfindung;
    • 7 ein Datenflussdiagramm beinhaltet, das einen Prozess 700 zur Re-Simulation oder Simulation unter Verwendung eines oder mehrerer Codecs veranschaulicht, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 8 ein Datenflussdiagramm für die Analyse und Beobachtung wichtiger Leistungsindikatoren (key performance indicator, KPI) beinhaltet, in Übereinstimmung mit einigen Ausführungsformender Erfindung;
    • 9 ein Ablaufdiagramm ist, das ein Verfahren zur Steuerung eines virtuellen Objekts in einer simulierten Umgebung zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 10 ein Ablaufdiagramm ist, das ein Verfahren zur Steuerung eines virtuellen Objekts in einer simulierten Umgebung unter Verwendung von Modellen maschinellen Lernens, die an physischen Sensordaten trainiert wurden, zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 11A eine Darstellung eines Beispiels eines autonomen Fahrzeugs ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 11B ein Beispiel für Kamerastandorte und Sichtfelder für das beispielhafte autonome Fahrzeug von 11A ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 11C ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 11A ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 11D ein Systemdiagramm zur Kommunikation zwischen Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug von 11A ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung; und
    • 12 ein Blockdiagramm einer beispielhaften Computervorrichtung ist, die zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Die offenbarten Systeme und Verfahren beziehen sich auf das Training, Testen und Verifizieren autonomer Maschinen oder Objekte in simulierten Umgebungen. Die Erfindung kann allgemein in Bezug auf ein Beispiel für ein autonomes oder halbautonomes Fahrzeug 102 (hierin alternativ als „Fahrzeug 102“ oder „autonomes Fahrzeug 102“ bezeichnet) beschrieben werden, für welches ein Beispiel hierin in Bezug auf 11A-11D ausführlicher beschrieben wird. Dies soll jedoch nicht beschränkend sein. Zum Beispiel, und ohne vom Umfang der Erfindung abzuweichen, können die hierin beschriebenen Systeme, Verfahren und/oder Prozesse auf nicht-autonome Fahrzeuge, Roboter, unbemannte Luftfahrzeuge und/oder jede andere Art von Fahrzeug oder Objekt anwendbar sein.
  • System zur Re-Simulation
  • Nun auf 1 Bezug nehmend, ist 1 ein beispielhaftes System 100 zur Re-Simulation, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Zum Beispiel kann das System 100 zum Trainieren, Testen, Verifizieren, Einsetzen, Aktualisieren, erneuten Verifizieren und/oder Einsetzen eines oder mehrerer neuronaler Netze zur Verwendung in einem autonomen Fahrzeug, einem halbautonomen Fahrzeug, einem Roboter und/oder einem anderen Objekt verwendet werden. In einigen Beispielen kann das System 100 einige oder alle der Komponenten, Merkmale und/oder Funktionen eines Systems 1176 aus 11D beinhalten, und/oder kann zusätzliche und/oder alternative Komponenten, Merkmale und Funktionen des Systems 1176 beinhalten. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele aufgeführt sind. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich zu den oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen sein. Ferner sind viele der hierin beschriebenen Elemente funktionelle Entitäten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Lage implementiert sein können. Verschiedene hierin beschriebene Funktionen, die von Entitäten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Befehle ausführt.
  • Ein oder mehrere Fahrzeuge 102 können Sensordaten von einem oder mehreren Sensoren des Fahrzeugs/der Fahrzeuge 102 in realen (z.B. physischen) Umgebungen sammeln. Die Sensoren des Fahrzeugs (der Fahrzeuge) 102 können unter anderem beinhalten: Sensor(en) für globale Satellitennavigationssysteme 1158 (z.B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 1160, Ultraschallsensor(en) 1162, LIDAR-Sensor(en) 1164, Inertialmesseinheit (IMU)-Sensor(en) 1166 (z.B. Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 1196, Stereokamera(s) 1168, Weitwinkelkamera(s) 1170 (z.B. Fisheye-Kameras), Infrarotkamera(s) 1172, Surround-Kamera(s) 1174 (z.B. 360-Grad-Kameras), Fern- und/oder Mittelstreckenkamera(s) 1198, Geschwindigkeitssensor(en) 1144 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 102), Vibrationssensor(en) 1142, Lenksensor(en) 1140, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1146) und/oder andere Sensortypen. Das (die) Fahrzeug(e) 102 kann (können) autonome Fahrzeuge, halbautonome Fahrzeuge, nicht-autonome Fahrzeuge beinhalten, und/oder andere Objekte als das Fahrzeug 102 umfassen, wie z.B. Roboter, Drohnen, unbemannte Luftfahrzeuge (unmanned aerial vehicles; UAVs) usw.
  • Das (die) Fahrzeug(e) 102 kann (können) Fahrzeug-Hardware 104 beinhalten. Zum Beispiel kann die Fahrzeug-Hardware 104 für die Verwaltung der von den Sensoren erzeugten Sensordaten verantwortlich sein (z.B. unter Verwendung eines Sensor-Managers eines Software-Stacks für autonomes Fahren, der von der Fahrzeug-Hardware 104 ausgeführt wird). Der Software-Stack für autonomes Fahren, der unter Verwendung der Fahrzeug-Hardware 104 ausgeführt wird, kann ferner einen Weltzustandsmanager beinhalten, der die Welt unter Verwendung einer oder mehrerer Karten (z.B. 3D-Karten), Lokalisierungskomponente(n), Wahrnehmungskomponente(n) und/oder dergleichen verwaltet. Darüber hinaus kann der Software-Stack für autonomes Fahren Planungskomponente(n) (z.B. als Teil einer Planungsschicht), Steuerungskomponente(n) (z.B. als Teil einer Steuerungsschicht), Betätigungskomponente(n) (z.B. als Teil einer Betätigungsschicht), Hindernisvermeidungskomponente(n) (z.B. als Teil einer Hindernisvermeidungsschicht) und/oder andere Komponente(n) beinhalten. In jedem Beispiel kann die Fahrzeug-Hardware 104 die Hardware des Fahrzeugs 102 beinhalten, die zur Steuerung des Fahrzeugs 102 durch reale Umgebungen auf der Grundlage der Sensordaten, eines oder mehrerer Modelle maschinellen Lernens (z.B. neuronale Netze) und/oder dergleichen verwendet wird. Als solche kann die Fahrzeug-Hardware 104 für den Einbau in das Fahrzeug 102 und zur Verwendung durch das Fahrzeug 102 bei der Ausführung eines Software-Stacks für autonomes Fahren konfiguriert sein, um das Fahrzeug 102 zumindest teilweise durch eine oder mehrere reale physische Umgebungen zu steuern.
  • Die von den Sensoren des Fahrzeugs (der Fahrzeuge) 102 gesammelten Sensordaten können zusätzlich zu vorhandenen Sensordaten (z.B. in dem/den Datenspeicher(n) 110 gespeicherte Sensordaten) von einem Trainingssubsystem 106 verwendet werden. Das Trainingssubsystem 106 kann eine Cloud-basierte Deep Learning-Infrastruktur beinhalten, die künstliche Intelligenz zur Analyse der von dem Fahrzeug/den Fahrzeugen 102 empfangenen und/oder in dem/den Datenspeicher(n) 110 gespeicherten Sensordaten verwendet und aktuelle neuronale Echtzeit-Netze (und/oder andere Modelle maschinellen Lernens) für intelligente Echtzeit-Inferenzierung einbezieht oder trainiert. In einigen Beispielen kann das Trainingssubsystem 106 einen oder mehrere Grafikverarbeitungseinheit (graphics processing unit; GPU)-Server 108 beinhalten. Beispielsweise kann das Trainings-Subsystem 106 ein Rechenzentrum mit GPUs, TPUs, CPUs und/oder anderen Prozessortypen beinhalten. Die Verwendung von GPUs in Bezug auf den/die GPU-Server 108 soll als solche nicht beschränkend sein, und in einigen Beispielen brauchen der/die GPU-Server 108 keine GPU(s) beinhalten.
  • Das Trainingssubsystem 106 kann eine beliebige Anzahl von Modellen maschinellen Lernens trainieren und/oder testen, einschließlich tiefer neuronaler Netze (DNNs), wie z.B. neuronale Netze zur Durchführung von Operationen, die einer oder mehreren Schichten des Software-Stacks für autonomes Fahren und/oder einem Software-Stack für kabineninterne Erfahrung (IX) zugeordnet sind. Beispielsweise können ein oder mehrere DNNs für Wahrnehmung in autonomen Fahrzeugen (autonomous vehicle (AV) perception DNNs) trainiert und/oder getestet werden, wobei die DNNs für die AV-Wahrnehmung zum Erfassen von Fahrspuren und Begrenzungen auf Fahrflächen, zum Erfassen von frei befahrbarem Raum, zum Erfassen von Verkehrsmasten oder -schildern, zum Erfassen von Ampeln, zum Erfassen von Objekten in der Umgebung (z.B. Fahrzeuge, Fußgänger, Tiere, unbelebte Objekte usw.), zum Erfassen von Wartebedingungen und Kreuzungen und/oder dergleichen verwendet werden können. Als weiteres Beispiel können ein oder mehrere DNNs für die kabineninterne Erfahrung (IX) trainiert und/oder getestet werden, wobei die IX-Wahrnehmungs-DNNs zur Überwachung von Fahrgästen und Fahrern innerhalb des Fahrzeugs 102 verwendet werden können. Zum Beispiel können eine oder mehrere IX-Wahrnehmungs-DNNs darauf trainiert werden, einen Zustand des Fahrers zu bestimmen - wie z.B., aber nicht beschränkt auf, eine Blickverfolgung, eine Verfolgung der Kopfhaltung, eine Erfassung von Benommenheit, Schläfrigkeit, Augenoffenheit, eine Emotionserfassung, eine Herzfrequenzüberwachung, die Lebendigkeit des Fahrers, eine Beeinträchtigung des Fahrers und/oder dergleichen.
  • Nach dem Training und/oder Test können die IX-Wahrnehmungs-DNNs, die AV-Wahrnehmungs-DNNs und/oder andere DNNs durch ein Validierungs-/Verifikations-Subsystem 112 validiert und/oder verifiziert werden. Das Validierungs-/Verifikations-Subsystem 112 kann ähnliche Komponenten und/oder Merkmale wie das Trainings-Subsystem 106 beinhalten. In einigen Beispielen können das Trainings-Subsystem 106 und das Validierungs-/Verifikations-Subsystem 112 die gleichen Hardware-Komponenten beinhalten, während sich die Hardware-Komponenten in anderen Beispielen unterscheiden können. Das Validierungs-/Verifikations-Teilsystem 112 kann Leistung, Genauigkeit und/oder andere Kriterien, die den DNNs zugeordnet sind, verifizieren und/oder validieren. Nach der Verifizierung und/oder Validierung können die validierten AV-Wahrnehmungs-DNNs und/oder die validierten IX-Wahrnehmungs-DNNs in den/die Software-Stack(s) 116 (z.B. den IX-Software-Stack und/oder den Software-Stack für autonomes Fahren) integriert werden. Nach der Integration in den/die Software-Stack(s) 116 kann/können das/die Fahrzeug(e) 102 den/die Softwarestack(s) unter Verwendung der Fahrzeug-Hardware 104 ausführen, um das/die Fahrzeug(e) 102 in realen Umgebungen zu steuern. Obwohl das/die Fahrzeug(e) 102 in 1 als Daten erfassend und die eingesetzten DNNs verwendend dargestellt sind, soll dies nicht beschränkend sein. Beispielsweise können einige Fahrzeuge 102 für die Datenerfassung verwendet werden, während andere Fahrzeuge 102 für Anwendungen autonomen Fahrens unter Verwendung der eingesetzten DNNs verwendet werden können. Als solche können in einigen Beispielen erste Fahrzeuge 102 die Daten erfassen, und können zweite Fahrzeuge 102 den/die Software-Stack(s) 116 verwenden, sobald die von den ersten Fahrzeugen 102 gesammelten Daten zum Trainieren der eingesetzten DNNs verwendet worden sind.
  • Als solches kann das System 100 ein Re-Simulations-System beinhalten, das Daten physischer Sensoren verwendet, die von Fahrzeug(en) 102 in realen Umgebungen erzeugt wurden, um eine oder mehrere DNNs zur Verwendung in dem/den Software-Stack(s) 116 zu trainieren, zu testen, zu verifizieren und/oder zu validieren. In einigen Beispielen, wie hier beschrieben wurde, kann sich das Re-Simulations-System 100 mit Simulationssystem(en) 400A, 400B, 400C und/oder 400D insofern überschneiden, als zumindest ein Teil des Testens, des Trainierend, der Verifizierung und/oder der Validierung in einer simulierten Umgebung durchgeführt werden kann.
  • Nun auf 2 Bezug nehmend, beinhaltet 2 ein Datenflussdiagramm für einen Prozess 118 des Testens, Trainierens, Verifizierens und/oder Validierens neuronaler Netze, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Der Prozess 118 kann die Datenaufnahme neuer Fahrdaten (z.B. Sensordaten) beinhalten, die von einem oder mehreren Fahrzeugen 102 in realen Umgebungen erfasst und/oder erzeugt wurden, und/oder simulierte oder virtuelle Sensordaten bzw. Daten virtueller Sensoren aus einer oder mehreren simulierten Umgebungen. Der Prozess 118 kann ferner eine Datenindexierung und -kuration 124, Datenkennzeichnungsdienste 126, ein Modelltraining 128, eine Modellverfeinerung, - beschneidung und/oder -feinabstimmung 130, eine Modellvalidierung 132 und/oder eine Aktualisierung globaler Abdeckungskarten 134 beinhalten. Der Prozess 118 kann eine Trainingsschleife beinhalten, bei der neue Daten von dem/den Fahrzeug(en) 102 erzeugt werden, die zum Trainieren, Testen, Verifizieren und/oder Validieren eines oder mehrerer Wahrnehmungs-DNNs verwendet werden, und die trainierten oder eingesetzten DNNs werden dann von dem/den Fahrzeug(en) 102 zur Navigation in realen Umgebungen verwendet.
  • Der (die) Datenspeicher 120 kann (können) Sensordaten und/oder virtuelle Sensordaten, die von einem oder mehreren realen Sensoren eines oder mehrerer Fahrzeuge 102 und/oder virtuellen Sensoren eines oder mehrerer virtueller Fahrzeuge erzeugt wurden, speichern.
  • Die Datenaufnahme 122 kann die Generierung und/oder Aufzeichnung der von der (den) autonomen Fahrzeugplattform(en) des (der) Fahrzeuge 102 (z.B. der Fahrzeug-Hardware 104 und/oder dem (den) Softwarestack(s) 116) ausgegebenen Daten beinhalten. Für ein nicht beschränkendes Beispiel können die Daten auf Festkörperlaufwerke (SSDs) ausgeschrieben und/oder drahtgebunden und/oder drahtlos in den/die Datenspeicher 120 heruntergeladen werden.
  • Eine Datenindizierung und Kuratierung 124 kann ein Indizieren von Metadaten beinhalten, die den von dem/den Fahrzeug(en) 102 ausgegebenen Daten für eine weitere Suche und/oder einen weiteren Abruf zugeordnet sind. Suchindizes können verwendet werden, um bestimmte Segmente der Daten abzurufen, die dann zur weiteren Verarbeitung getaggt bzw. markiert und/oder geflaggt bzw. gekennzeichnet werden können. In einigen Beispielen können Rohdaten in einem verlustfreien Format gespeichert werden, um eine weitere Vorverarbeitung und/oder Quantisierung zu ermöglichen. In solchen Beispielen kann ein On-Demand-Transcodierungsdienst die Rohdaten in verschiedene Zielformate (z.B. MPEG, JPEG, FP16 usw.) umwandeln und kann die umgewandelten Daten in eine oder mehrere Verarbeitungspipelines (z.B. Etikettierung, DNN-Training, Re-Simulation usw.) einspeisen oder eingeben. Exportierte Datensätze können in einem Datensatzspeicher gespeichert werden, welcher ein Dienst sein kann, der unveränderliche Datensätze zur weiteren Verarbeitung handhabt. Sobald die Datensätze gespeichert sind, können die Datensätze verwendet und wiederverwendet werden, um Trainingsergebnisse exakt zu reproduzieren oder Simulationsjobs auszuführen und erneut auszuführen.
  • Datenkennzeichnungsdienste 126 können zur Kennzeichnung und/oder Etikettierung der Daten, der Rohdaten, der transformierten Daten und/oder aller anderen in dem Prozess verwendeten Daten 118 verwendet werden. In Beispielen kann die Kennzeichnung und/oder Etikettierung von einem Menschen, einer Maschine oder einer Kombination derselben durchgeführt werden.
  • Ein Modelltraining 128 kann eine Deep-Learning-Plattform verwenden, um Trainingsanwendungen zu definieren und die Trainingsanwendung auf einem Compute- bzw. Rechen-Cluster auszuführen (z.B. unter Verwendung des Trainingssubsystems 106 von 1). Der Rechen-Cluster kann einen oder mehrere GPU-betriebene Server beinhalten, die jeweils eine Vielzahl von GPUs, PCIe-Switches und/oder CPUs beinhalten können, die mit schnellen Zwischenverbindungen bzw. Hochgeschwindigkeitsverbindungen wie NVLink- und PCIe-Verbindungen miteinander verbunden sind. In einigen Beispielen kann ein lokaler Cache (ein Dateisystem mit skalierter hoher Bandbreite) neben dem Rechen-Cluster verfügbar sein und zur Zwischenspeicherung von Datensätzen neben den Rechenknoten verwendet werden. Das System kann das Caching übernehmen und dem Rechenjob einen lokalen Datensatz zur Verfügung stellen. Die Trainingsanwendungen können trainierte Modelle und experimentelle Metadaten erzeugen, die in einem Modelldatenspeicher zur weiteren Verwendung gespeichert werden können.
  • Eine Modellverfeinerung, Beschneidung und/oder Feinabstimmung 130 kann ein Aktualisieren der DNNs beinhalten, um die Genauigkeit und Wirksamkeit der DNNs weiter zu verfeinern und zu verbessern. Beispielsweise kann eine Hyperparameter-Erfassung durch einen Experimentdienst ermöglicht sein, der Informationen über den Hyperparameterraum nachverfolgt, um Hyperparameter-Konfigurationen, Metriken und Modellversionen, die durch jedes Experiment erzeugt werden, zu untersuchen. Ein Workflow-Manager kann zum Planen und Versenden von Experimenten an mehrere Knoten parallel verwendet werden. Maximale Berechnungseffizienz kann durch Heuristiken mit frühzeitiger Beendigung ermöglicht werden, die es ermöglichen, Experimente zu beenden, die relativ zu anderen Experimenten eine schlechte Leistung aufweisen. Der Workflow-Manager kann für die Erstellung von Binärdateien aus Source Configuration Management (SCM)-Repositorys verantwortlich sein, um sicherzustellen, dass keine nicht nachverfolgten Informationen von Benutzern zu den generierten Modellen gelangen. Als solche kann die Plattform eine systematische Nachverfolgung aller zu Experimenten gehörender Informationen ermöglichen und dadurch reproduzierbare Experimente ermöglichen. Ein Pruning bzw. Beschneiden kann, beispielhaft und nicht beschränkend, ähnlich wie zu den Pruning-Verfahren, -Prozessen und -Systemen ausgeführt werden, die in der provisorischen US-Patentanmeldung Nr. 62/630,445 und der US-Patentanmeldung Nr. 16/246,414 offenbart sind und die hiermit jeweils durch Bezugnahme in ihrer Gesamtheit einbezogen werden.
  • Eine Modellvalidierung 132 kann ein Verifizieren und/oder Validieren der DNNs beinhalten, wie beispielsweise durch Verwenden des Validierungs-/Verifikations-Subsystems 112 von 1. Sobald Modelle validiert sind, kann eine globale Abdeckungskarte aktualisiert werden (bei 134). Sobald beispielsweise die erforderlichen Teile des/der Softwarestack(s) 116 für eine neue Region trainiert sind und/oder der/die Softwarestack(s) 116 für eine bereits abgedeckte Region aktualisiert sind, kann die globale Abdeckungskarte aktualisiert werden. Wenn die globale Abdeckungskarte größer wird, kann (können) das (die) Fahrzeug(e) 102, das (die) den (die) Software-Stack(s) 116 verwendet (verwenden), in der Lage sein, durch zusätzliche Regionen zu navigieren. Sobald die Modelle trainiert sind, können die Modelle neu in eine größere Anwendung geladen werden und andere Testdatensätze ausführen. In solchen Beispielen kann ein ähnliches Modell wie das, das für das Training verwendet wird, für diesen Neutrainings-, Test- oder Feinabstimmungs-Prozess verwendet werden.
  • In einigen Beispielen kann aktives Lernen eingesetzt werden. Beispielsweise können vorhandene trainierte Modelle (z.B. DNNs) verwendet werden, um weitere Trainingsdaten zu gewinnen. Das System kann vorhandene Modelle verwenden, um neu gesammelte Daten und/oder Rohdaten zu bewerten (oder abzuleiten) und einen Vertrauenswert bzw. Konfidenz-Score für jedes Datenelement zu berechnen. Der Vertrauenswert kann repräsentativ dafür sein, wie informativ oder nützlich die Daten für das Training sein können. Beispielsweise können bereits verwendete Daten, die durch ein vorhandenes Modell modelliert werden, nicht viel oder irgendeinen inkrementellen Wert liefern, während neue Daten, die das Modell schlecht vorhersagt, wiederverwendet werden können, um das Modell für reale Fahranwendungen zu verbessern. Mit anderen Worten sind Daten, für deren genaue Verarbeitung die DNNs bereits trainiert sind, möglicherweise nicht so nützlich wie Daten, für deren genaue Verarbeitung die DNNs nicht trainiert sind. Aktives Lernen kann verwendet werden, um die Daten zu identifizieren, die verwendet werden können, um eine gesteigerte Leistung für die DNNs in zusätzlichen oder alternativen Situationen oder Umgebungen bereitzustellen.
  • Nun auf 3A-3E Bezug nehmend, beinhalten 3A-3E Arbeitsabläufe, die zum Trainieren von DNNs verwendet werden. 3A beinhaltet einen Arbeitsablauf 300A. Der Arbeitsablauf 300A kann eine Datenaufnahme 122, eine Übergabe der Daten an den/die Datensatzspeicher 302 (z.B. einen Dienst, der unveränderliche Datensätze zur weiteren Verarbeitung verarbeitet), eine Kennzeichnung der Daten unter Verwendung von Datenkennzeichnungsdiensten 126 und ein Training von DNNs unter Verwendung eines Modelltrainings 128 umfassen. Die zum Kennzeichnen ausgewählten Rahmen bzw. Frames können in einigen Beispielen zufällig ausgewählt werden. Der Arbeitsablauf 300A kann z.B. ein Kennzeichnen von 300.000 bis 600.000 Frames (z.B. Frames, die durch die Daten repräsentiert werden) beinhalten. Sobald die DNNs trainiert sind, können die DNNs in Simulations- und/oder Re-Simulations-Anwendungen 304 verwendet werden. Die Modelle können dann beschnitten, optimiert, verfeinert und dann als eingesetzte DNNs in dem Fahrzeug (den Fahrzeugen) 102 (z.B. in dem Software-Stack (in den Software-Stacks) 116) eingesetzt werden. Sobald die DNNs bis zu einem akzeptablen Genauigkeitsgrad (z.B. 90%, 95%, 97% usw.) trainiert sind, kann der Trainings- und Verfeinerungsprozess zu einem zweiten Workflow übergehen, z.B. zu einem Workflow 300B.
  • 3B beinhaltet den Workflow 300B. Der Arbeitsablauf 300B kann einen Modellspeicher 306 beinhalten, der vortrainierte oder zuvor trainierte Modelle (z.B. DNNs) beinhalten kann. Die vortrainierten Modelle können zur Bewertung neuer Daten verwendet werden, und die Bewertung kann zur Priorisierung zu etikettierender Daten verwendet werden. So kann z.B. ein vortrainiertes DNN verwendet werden, um einen Score bzw. Bewertungswert für jeden neu ausgewählten Frame zu berechnen, wobei der Score ein Vertrauen in die Vorhersage des DNN repräsentieren kann. Wenn der Vertrauenswert bzw. Konfidenz-Score hoch ist (bedeutend beispielsweise, dass das Modell in der Lage ist, den Frame exakt zu handhaben), kann der Frame für die Kennzeichnung depriorisiert werden. Wenn der Score niedrig ist, kann der Frame priorisiert werden. Wenn also ein Frame für das DNN verwirrend ist (d.h. wenn der Konfidenz-Score niedrig ist), dann kann der Frame gekennzeichnet werden, so dass das DNN aus dem Frame lernen kann, wodurch das vortrainierte DNN weiter verfeinert wird.
  • In einigen Beispielen kann eine Bewertungsfunktion eine Unsicherheits-Pseudo-Wahrscheinlichkeit aus der Netzwerkausgabe abschätzen. In solchen Beispielen kann ein Dropout durch mehrfaches Berechnen einer Ausgabe des DNN und jedes Mal zufälliges Ausfällen (z.B. Nullsetzen) von Neuronen der vorletzten Schicht zum Vorteil genutzt werden. Die Varianz der Vorhersagen des DNN kann dann zum Vorteil genutzt werden, und die Varianz kann die Unsicherheit in der Vorhersage codieren und dadurch zu einem Score bzw. Bewertungswert führen.
  • Wichtige Leistungsindikatoren bzw. Key Performance Indicators (KPIs) und/oder Metriken können für eines oder mehrere der aktuellen DNNs (z.B. die leistungsstärksten DNNs) in dem Modellspeicher 306 berechnet werden, um Bedingungen oder Kombinationen von Bedingungen zu bestimmen, die die aktuellen DNNs möglicherweise nicht ausreichend gut erfüllen. Eine Zustandsdimension kann z.B. Eigenschaften des gesamten Bilds oder Frames beinhalten, wie z.B., aber nicht beschränkt auf, Beleuchtung oder Ausleuchtung (z.B. Tag, Nacht, bewölkt, Dämmerung, Gegenlicht usw.), Wetter (z.B. klar, Regen, Schnee, Nebel usw.), Umgebung (z.B. ländlich, städtisch, vorstädtisch, Autobahn, usw.), Topographie (z.B. flach, Kurve, Hügel, usw.), geographische Region (z.B. Europa, Nordamerika, China, usw.), Sensor (z.B. Kamera)-Eigenschaften wie beispielsweise Position und/oder Objektivtyp und/oder eine Kombination davon. Die Bedingungen oder eine Kombination der Bedingungen, unter denen die aktuellen DNNs als nicht ausreichend leistungsfähig angesehen werden (z.B. eine Genauigkeit unter einem gewünschten oder erforderlichen Niveau haben), können verwendet werden, um ein Mining bzw. Auffinden und ein Kennzeichnen von Daten (z.B. zusätzlichen Daten), die die Genauigkeit der DNNs in Bezug auf die Bedingungen oder die Kombination der Bedingungen erhöhen können, zu dirigieren bzw. zu steuern. In einigen Beispielen kann das Auffinden der Daten durch Verwendungstags erleichtert werden, die während der Datenindizierung und/oder Kuration 124 (1) hinzugefügt worden sein können.
  • Der Arbeitsablauf 300B kann eine Feinabstimmung und/oder ein Transferlernen bereitstellen. Beispielsweise kann das System Modelle aus dem Modellspeicher 306 (wie durch die gestrichelte Linie 310 in 3B gezeigt) neu laden und damit fortfahren, sie zu trainieren. Dies kann z.B. für eine Kameraanpassung und schnelle Experimente verwendet werden.
  • 3C beinhaltet einen Arbeitsablauf 300C. Der Arbeitsablauf 300C kann aktives Lernen bereitstellen. Beispielsweise können die Arbeitsabläufe 300A und 300B möglicherweise nicht unbegrenzt fortgesetzt werden, da dies zu viele Daten zur Folge haben kann, die selbst von den größten Systemen nicht gespeichert und verarbeitet werden können. Eine Datensammlung von etwa 10.000 Stunden kann beispielsweise in 30-50 Petabyte an Daten resultieren, abhängig von der Anzahl von Sensoren des Fahrzeugs/der Fahrzeuge 102. Darüber hinaus sollten die DNNs nach den Arbeitsabläufen 300A und 300B mit hoher Genauigkeit arbeiten und bei fast allen Offline-Benchmarks eine gute Leistung erbringen. Insoweit kann der Arbeitsablauf 300C eine Verwirrungs- bzw. Irritationsbewertung auf Kanten- bzw. Randniveau bereitstellen, die dem Arbeitsablauf 300B ähnlich sein kann, jedoch am Rand durchgeführt wird. Im Allgemeinen kann dies bedeuten, dass alles, was das DNN während der Fahrt auf der Fahrzeugebene nicht versteht, protokolliert und über eine API veröffentlicht und zur weiteren Untersuchung (z.B. Beschriftung bzw. Kennzeichnung) gekennzeichnet werden kann.
  • In einigen Beispielen können vorbestimmte Bedingungen oder Kombinationen von Bedingungen (wie die hierin beschriebenen), die die DNNs nicht genau genug erfüllen, auch dazu verwendet werden, die Datenerfassung an den Rand zu lenken und dorthin zu fokussieren. Das Fahrzeug (die Fahrzeuge) 102 kann (können) z.B. nicht alle Daten sammeln, sondern können nur dann Daten sammeln, wenn bestimmte Bedingungen oder Kombinationen von Bedingungen erfüllt sind (z.B. bei Nacht, im Regen, in bestimmten Tunneltypen usw.).
  • 3D beinhaltet einen Arbeitsablauf 300D. Der Arbeitsablauf 300D kann ein Training und eine Verfeinerung der DNNs bereitstellen. In einigen Beispielen kann der Arbeitsablauf 300D auf den Arbeitsablauf 300C folgen. Letztendlich kann das Ziel darin bestehen, Vorhersagewerte zu verwenden und diese auf einer Karte (z.B. einer GPS- oder GNSS-Karte) zu aggregieren, um Orte oder Regionen zu darzustellen, an denen die DNNs gute Leistungen erbringen und an denen die DNNs weniger gute Leistungen erbringen (z.B. unter dem gewünschten Genauigkeitsgrad). Eine Wärmekarte bzw. Heatmap 312 kann erstellt werden, um die Gebiete mit geringerer Leistung anzuzeigen, und das Fahrzeug/die Fahrzeuge 102 kann/können an diese Orte geschickt werden (z.B. bei Aussendung 308). In einigen Beispielen können die KPIs und/oder Metriken zur direkten Planung von Routen für das/die Fahrzeug(e) 102 zum Vorteil genutzt werden, um Daten zu erfassen, die für Bedingungen oder Kombinationen von Bedingungen repräsentativ sind, für die das DNN bei der Generierung von Vorhersagen nicht so genau ist.
  • Simulationssystem
  • Ein Simulationssystem 400 - z.B. repräsentiert durch hierin näher beschriebene Simulationssysteme 400A, 400B, 400C und 400D - kann eine globale Simulation erzeugen, die eine virtuelle Welt oder Umgebung (z.B, eine simulierte Umgebung) simuliert, die Fahrzeuge mit künstlicher Intelligenz (KI) oder andere Objekte (z.B. Fußgänger, Tiere usw.), Hardware-in-the-Loop-Fahrzeuge (HIL) oder andere Objekte, Software-in-the-Loop-Fahrzeuge (SIL) oder andere Objekte und/oder Person-in-the-Loop-Fahrzeuge (PIL) oder andere Objekte beinhalten kann. Die globale Simulation kann innerhalb einer Engine (z.B. einer Spiele-Engine) oder einer anderen Software-Entwicklungsumgebung verwaltet werden, die eine Rendering-Engine (z.B. für 2D- und/oder 3D-Grafiken), eine Physik-Engine (z.B. für Kollisionserfassung, Kollisionsreaktion usw.), Ton, Skripting, Animation, KI, Vernetzung, Streaming, Speicherverwaltung, Threading, Lokalisierungsunterstützung, Szenengrafiken, Kinematik und/oder andere Funktionen umfassen kann. In einigen Beispielen, wie hierin beschrieben, können ein oder mehrere Fahrzeuge oder Objekte innerhalb des Simulationssystems 400 (z.B. HIL-Objekte, SIL-Objekte, PIL-Objekte, KI-Objekte usw.) innerhalb ihrer eigenen Instanz der Engine verwaltet werden. In solchen Beispielen kann jeder virtuelle Sensor jedes virtuellen Objekts seine eigene Instanz der Engine (z.B. eine Instanz für eine virtuelle Kamera, eine zweite Instanz für einen virtuellen LIDAR-Sensor, eine dritte Instanz für einen weiteren virtuellen LIDAR-Sensor usw.) beinhalten. Insoweit kann eine Instanz der Engine zur Verarbeitung von Sensordaten für jeden Sensor in Bezug auf die Wahrnehmung der globalen Simulation durch den Sensor verwendet werden. Insoweit kann bei einer virtuellen Kamera diese Instanz zur Verarbeitung von Bilddaten in Bezug auf das Sichtfeld der Kamera in der simulierten Umgebung verwendet werden. Als ein weiteres Beispiel kann bei einem IMU-Sensor die Instanz zur Verarbeitung von IMU-Daten (z.B. repräsentativ für die Orientierung) für das Objekt in der simulierten Umgebung verwendet werden.
  • AI bzw. KI (z.B. Bot)-Fahrzeuge oder andere Objekte können Fußgänger, Tiere, Fahrzeuge Dritter, Fahrzeuge und/oder andere Objekttypen beinhalten. Die KI-Objekte in der simulierten Umgebung können unter Verwendung künstlicher Intelligenz (z.B. maschinelles Lernen wie beispielsweise neuronale Netze, regelbasierte Steuerung, eine Kombination davon usw.) in einer Weise gesteuert werden, die simuliert, oder emuliert, wie sich entsprechende Objekte der realen Welt verhalten würden. In einigen Beispielen können die Regeln, oder Aktionen, für KI-Objekte von einem oder mehreren HIL-Objekten, SIL-Objekten und/oder PIL-Objekten gelernt werden. In einem Beispiel, in dem ein KI-Objekt (z.B. ein Bot) in der simulierten Umgebung einem Fußgänger entspricht, kann der Bot dazu trainiert werden, sich in einer Reihe verschiedener Situationen oder Umgebungen (z.B. Laufen, Gehen, Joggen, Unaufmerksamkeit, am Telefon, bei Regen, Schnee, in einer Stadt, in einem Vorort, in einer ländlichen Gemeinde usw.) wie ein Fußgänger zu verhalten. Wenn die simulierte Umgebung zum Testen der Fahrzeugleistung verwendet wird (z.B. für HIL- oder SIL-Ausführungsformen), kann sich der Bot (z.B. der Fußgänger) so verhalten, wie sich ein Fußgänger in der realen Welt verhalten würde (z.B. indem er bei Regen oder Dunkelheit bei Rot über die Straße geht, Stoppschilder oder Ampeln nicht beachtet, usw.), um eine Umgebung in der realen Welt genauer zu simulieren. Dieses Verfahren kann für alle KI-Bots in der simulierten Umgebung verwendet werden, wie z.B. für Fahrzeuge, Fahrradfahrer oder Motorräder, deren KI-Bots auch darauf trainiert werden können, sich so zu verhalten, wie sich Objekte in der realen Welt verhalten würden (z.B. Ein- und Ausscheren in den/aus dem Verkehr, Ausweichen, Spurwechsel ohne Signal oder plötzliches, unerwartetes Bremsen usw.).
  • Die KI-Objekte, die vom interessierenden Fahrzeug (z.B. dem eigenen Fahrzeug in der simulierten Umgebung) entfernt sein können, können in vereinfachter Form dargestellt sein - wie z.B. eine radiale Abstandsfunktion oder eine Liste von Punkten an bekannten Positionen in einer Ebene, mit zugehörigen momentanen Bewegungsvektoren. Somit können die KI-Objekte ähnlich dazu modelliert werden, wie KI-Agenten in Videospiel-Engines modelliert werden können.
  • HIL-Fahrzeuge oder -Objekte können Hardware verwenden, die in den physischen Fahrzeugen oder Objekten verwendet wird, um zumindest einen Teil der Steuerung der HIL-Fahrzeuge oder -Objekte in der simulierten Umgebung zu unterstützen. Beispielsweise kann ein in einer HIL-Umgebung gesteuertes Fahrzeug ein oder mehrere SoCs 1104 (11C), CPU(s) 1118, GPU(s) 1120 usw. in einer Datenflussschleife zur Steuerung des Fahrzeugs in der simulierten Umgebung verwenden. In einigen Beispielen kann die Hardware der Fahrzeuge eine NVIDIA DRIVE AGX Pegasus®-Rechenplattform und/oder eine NVIDIA DRIVE PX Xavier®-Rechenplattform sein. Beispielsweise kann die Fahrzeug-Hardware (z.B. die Fahrzeug-Hardware 104) einige oder alle der Komponenten und/oder Funktionen beinhalten, die in der am 9. November 2018 eingereichten, nicht provisorischen US-Anmeldung Nr. 16/186,473 beschrieben sind, die hiermit durch Bezugnahme in ihrer Gesamtheit einbezogen wird. In solchen Beispielen können zumindest einige der Steuerungsentscheidungen unter Verwendung der Hardware generiert werden, die für den Einbau in ein reales autonomes Fahrzeug (z.B. das Fahrzeug 102) konfiguriert ist, um zumindest einen Teil eines oder mehrerer Software-Stacks 116 (z.B. einen Software-Stack für autonomes Fahren) auszuführen.
  • SIL-Fahrzeuge oder -Objekte können Software verwenden, um die Hardware der HIL-Fahrzeuge oder -Objekte zu simulieren oder zu emulieren. Zum Beispiel kann anstelle der tatsächlichen Hardware, die für die Verwendung in physischen Fahrzeugen (z.B. das Fahrzeug 102) konfiguriert sein kann, Software, Hardware oder eine Kombination davon verwendet werden, um die tatsächliche Hardware zu simulieren oder zu emulieren (z.B. die SoC(s) 1104 zu simulieren).
  • PIL-Fahrzeuge oder -Objekte können eine oder mehrere Hardware-Komponenten verwenden, die es einem entfernten Bediener (z.B. einem Menschen, einem Roboter usw.) ermöglichen, das PIL-Fahrzeug oder -Objekt innerhalb der simulierten Umgebung zu steuern. Zum Beispiel kann eine Person oder ein Roboter das PIL-Fahrzeug unter Verwendung eines Fernsteuerungssystems (z.B. mit einem oder mehreren Pedalen, einem Lenkrad, einem VR-System usw.) steuern, wie z.B. das Fernsteuerungssystem, das in der am 27. März 2019 eingereichten, nicht provisorischen US-Anmeldung Nr. 16/366,506 beschrieben ist und die hiermit durch Bezugnahme in ihrer Gesamtheit einbezogen wird. In einigen Beispielen kann der entfernte Bediener virtuelle Fahrzeuge der Level 0, 1 oder 2 (z.B. gemäß Dokument J3016 der Society of Automotive Engineers) autonomen Fahrens unter Verwendung eines VR-Headsets und einer oder mehreren CPU(s) (z.B. eines X86-Prozessors), einer oder mehrerer GPU(s) oder eine Kombination davon steuern. In anderen Beispielen kann der entfernte Bediener fortgeschrittene KI-unterstützte Fahrzeuge der Level 2, 3 oder 4 steuern, die unter Verwendung einer oder mehrerer fortgeschrittener SoC-Plattformen modelliert wurden. In einigen Beispielen können die PIL-Fahrzeuge oder - Objekte aufgezeichnet und/oder nachverfolgt werden, und die Aufzeichnungen und/oder Nachverfolgungsdaten können dazu verwendet werden, die Steuerung von KI-Objekten, wie den hierin beschriebenen, zu trainieren oder anderweitig zumindest teilweise dazu beizutragen.
  • Nunmehr auf 4A Bezug nehmend, ist 4A eine beispielhafte Darstellung eines Simulationssystems 400A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Simulationssystem 400A kann eine simulierte Umgebung 410 erzeugen, die KI-Objekte 412 (z.B. KI-Objekte 412A und 412B), HIL-Objekte 414, SIL-Objekte 416, PIL-Objekte 418 und/oder andere Objekttypen beinhalten kann. Die simulierte Umgebung 410 kann Merkmale einer Fahrumgebung wie beispielsweise Straßen, Brücken, Tunnel, Straßenschilder, Bremslichter, Zebrastreifen, Gebäude, Bäume und Laub, die Sonne, den Mond, Reflexionen, Schatten usw. beinhalten, in dem Bemühen, eine reale Umgebung innerhalb der simulierten Umgebung 410 genau zu simulieren. In einigen Beispielen können die Merkmale der Fahrumgebung innerhalb der simulierten Umgebung 410 durch Einbeziehung von Chips, Farbe, Graffiti, Abnutzung, Schäden usw. realitätsnäher sein. Obwohl in Bezug auf eine Fahrumgebung beschrieben, soll dies nicht beschränkend sein, und kann die simulierte Umgebung eine Innenraumumgebung (z.B. für einen Roboter, eine Drohne usw.), eine Luftumgebung (z.B. für ein UAV, eine Drohne, ein Flugzeug usw.), eine aquatische Umgebung (z.B. für ein Boot, ein Schiff, ein U-Boot usw.) und/oder einen anderen Umgebungstyp beinhalten.
  • Die simulierte Umgebung 410 kann unter Verwendung virtueller Daten, Daten der realen Welt oder einer Kombination davon erzeugt werden. Zum Beispiel kann die simulierte Umgebung Daten der realen Welt beinhalten, die unter Verwendung virtueller Daten ergänzt oder verändert sind, um kombinierte Daten zu erzeugen, die zur Simulation bestimmter Szenarien oder Situationen mit unterschiedlichen und/oder hinzugefügten Elementen (z.B. zusätzlichen KI-Objekten, Umgebungsmerkmalen, Wetterbedingungen usw.) verwendet werden können. Beispielsweise kann voraufgezeichnetes Video so erweitert oder geändert werden, dass es zusätzliche Fußgänger, Hindernisse und/oder Dergleichen beinhaltet, so dass die virtuellen Objekte (z.B. die Ausführung des/der Softwarestack(s) 116 als HIL-Objekte und/oder SIL-Objekte) gegen Abweichungen in den Daten der realen Welt getestet werden können.
  • Die simulierte Umgebung kann mittels Rasterung, Ray-Tracing, unter Verwendung von DNNs wie z.B. generativen kontradiktorischen Netzwerken (generative adversarial networks; GANs), einer anderen Rendering-Technik und/oder einer Kombination daraus, erzeugt werden. Um beispielsweise lebensechtere, realistischere Lichtverhältnisse (z.B. Schatten, Reflexionen, Blendung, Globalbeleuchtung, Raumverdunkelung usw.) zu schaffen, kann das Simulationssystem 400A Echtzeit-Raytracing verwenden. In einer oder mehreren Ausführungsformen kann das Simulationssystem 400A einen oder mehrere Hardware-Beschleuniger verwenden, um ein Echtzeit-Raytracing durchzuführen. Das Raytracing kann zur Simulation eines LIDAR-Sensors zur genauen Erzeugung von LIDAR-Daten verwendet werden. Beispielsweise kann Ray-Casting zur Simulation von LIDAR-Reflektivität verwendet werden. In jedem Beispiel können die von dem Simulationssystem 400A verwendeten Ray-Tracing-Techniken eine oder mehrere Techniken beinhalten, die in der provisorischen US-Patentanmeldung Nr. 62/644,385 , eingereicht am 17. März 2018, der provisorischen US-Patentanmeldung Nr. 62/644,386 , eingereicht am 17. März 2018, der provisorischen US-Patentanmeldung Nr. 62/644,601 , eingereicht am 19. März 2018, und der provisorischen US-Anmeldung Nr. 62/644,806 , eingereicht am 19. März 2018, der nicht provisorischen US-Patentanmeldung Nr. 16/354,983 , eingereicht am 15. März 2019, und/oder der nicht provisorischen US-Patentanmeldung Nr. 16/355,214 , eingereicht am 15. März 2019, beschrieben sind, von denen jede hiermit durch Bezugnahme in ihrer Gesamtheit einbezogen wird.
  • In einigen Beispielen kann die simulierte Umgebung zumindest teilweise unter Verwendung eines oder mehrerer DNNs, wie z.B. generativen kontradiktorischen neuronalen Netzen (GANs), gerendert werden. Zum Beispiel können Daten der realen Welt gesammelt werden, wie z.B. Daten der realen Welt, die von autonomen Fahrzeugen (z.B. Kamera(s), LIDAR-Sensor(en), RADAR-Sensor(en), etc.), Robotern und/oder anderen Objekten erfasst werden, sowie Daten der realen Welt, die von beliebigen Sensoren erfasst werden können (z.B. Bilder oder Videos, die aus Datenspeichern, Online-Ressourcen wie Suchmaschinen, gezogen werden, etc.). Die Daten der realen Welt können dann segmentiert, klassifiziert und/oder kategorisiert werden, wie beispielsweise durch Kennzeichnung unterschiedlicher Teile der Daten der realen Welt auf der Grundlage von Klassen (z.B. können bei einem Bild einer Landschaft Teile des Bilds - wie beispielsweise Pixel oder Pixelgruppen - als Auto, Himmel, Baum, Straße, Gebäude, Wasser, Wasserfall, Fahrzeug, Bus, LKW, Limousine usw. gekennzeichnet werden). Ein GAN (oder ein anderes DNN) kann dann unter Verwendung der segmentierten, klassifizierten und/oder kategorisierten Daten trainiert werden, um neue Versionen der verschiedenen Arten von Objekten, Landschaften und/oder anderen Merkmalen als Grafiken innerhalb der simulierten Umgebung zu erzeugen.
  • Die Simulatorkomponente(n) 402 des Simulationssystems 400 kann/können mit der/den Fahrzeugsimulatorkomponente(n) 406 über eine drahtgebundene und/oder drahtlose Verbindung kommunizieren. In einigen Beispielen kann die Verbindung eine drahtgebundene Verbindung unter Verwendung eines oder mehrerer Sensorschalter 408 sein, wobei die Sensorschalter einen Low-Voltage Differential Signaling (LVDS)-Ausgang bereitstellen können. Beispielsweise können die Sensordaten (z.B. Bilddaten) über eine HDMI-zu-LVDS-Verbindung zwischen der/den Simulatorkomponente(n) 402 und der/den Fahrzeugsimulatorkomponente(n) 406 übertragen werden. Die Simulatorkomponente(n) 402 kann/können eine beliebige Anzahl von Rechenknoten (z.B. Computer, Server usw.) beinhalten, die miteinander verbunden sind, um Synchronisation des Weltstatus zu gewährleisten. In einigen Beispielen, wie hierin beschrieben, kann die Kommunikation zwischen jedem der Rechenknoten (z.B. den Rechenknoten der Fahrzeugsimulatorkomponente(n) und den Rechenknoten der Simulatorkomponente(n)) durch ein System mit verteiltem gemeinsamen Speicher (distributed shared memory; DSM) (z.B. ein DSM 424 von 4C) unter Verwendung eines Protokolls für verteilten gemeinsamen Speicher (z.B. ein Kohärenzprotokoll) verwaltet werden. Das DSM kann eine Kombination aus Hardware (Cachekohärenzschaltungen, Netzwerkschnittstellen usw.) und Software beinhalten. Diese Architektur gemeinsam genutzten Speichers kann Speicher in gemeinsam genutzte Teile, die zwischen Knoten und Hauptspeicher verteilt sind, trennen oder den gesamten Speicher auf alle Knoten verteilen. In einigen Beispielen können InfiniBand (IB)-Schnittstellen und zugehörige Kommunikationsstandards verwendet werden. Zum Beispiel kann die Kommunikation zwischen und unter verschiedenen Knoten des Simulationssystems 400 (und/oder 600) IB verwenden.
  • Die Simulatorkomponente(n) 402 kann/können eine oder mehrere GPUs 404 beinhalten. Das virtuelle Fahrzeug, das simuliert wird, kann eine beliebige Anzahl von Sensoren (z.B. virtuelle oder simulierte Sensoren) beinhalten, die einem oder mehreren der hierin zumindest in Bezug auf die 11A-11C beschriebenen Sensoren entsprechen können. In einigen Beispielen kann jeder Sensor des Fahrzeugs einer der GPUs 404 entsprechen oder in einer solchen untergebracht sein. Beispielsweise kann die Verarbeitung für einen LIDAR-Sensor auf einer ersten GPU 404 ausgeführt werden, die kann die Verarbeitung für eine Weitwinkelkamera auf einer zweiten GPU 404, die Verarbeitung für einen RADAR-Sensor auf einer dritten GPU ausgeführt werden, und so weiter. Somit kann die Verarbeitung jedes Sensors in Bezug auf die simulierte Umgebung unter Verwendung einer Vielzahl von GPUs 404 parallel zu jedem anderen Sensor ausgeführt werden, um eine Echtzeitsimulation zu ermöglichen. In anderen Beispielen können zwei oder mehr Sensoren einer der GPUs 404 entsprechen oder auf einer dieser GPUs 404 gehostet werden. In solchen Beispielen können die zwei oder mehr Sensoren durch separate Threads auf der GPU 404 verarbeitet werden, und können parallel verarbeitet werden. In anderen Beispielen kann die Verarbeitung für einen einzelnen Sensor auf mehr als eine GPU verteilt sein. Zusätzlich zu oder alternativ gegenüber der/den GPU(s) 404 können eine oder mehrere TPUs, CPUs und/oder andere Prozessortypen zur Verarbeitung der Sensordaten verwendet werden.
  • Fahrzeugsimulatorkomponente(n) 406 kann (können) einen Rechenknoten des Simulationssystems 400A beinhalten, der einem einzelnen Fahrzeug entspricht, das in der simulierten Umgebung 410 repräsentiert wird. Jedes andere Fahrzeug (z.B. 414, 418, 416 usw.) kann einen jeweiligen Knoten des Simulationssystems beinhalten. Infolgedessen kann das Simulationssystem 400A auf eine beliebige Anzahl von Fahrzeugen oder Objekten skalierbar sein, da jedes Fahrzeug oder Objekt von seinem eigenen Knoten im System 400A gehostet oder verwaltet werden kann. In der Darstellung von 4A kann/können die Fahrzeugsimulatorkomponente(n) 406 einem HIL-Fahrzeug entsprechen (z.B. weil die Fahrzeug-Hardware 104 verwendet wird). Dies soll jedoch nicht beschränkend sein, und wie in 4B und 4C dargestellt kann das Simulationssystem 400 SIL-Fahrzeuge, HIL-Fahrzeuge, PIL-Fahrzeuge und/oder KI-Fahrzeuge beinhalten. Die Simulatorkomponente(n) 402 (z.B. eine Simulator-HostVorrichtung) kann/können einen oder mehrere Rechenknoten des Simulationssystems 400A beinhalten und kann/können die Simulation der Umgebung in Bezug auf jeden Aktor (z.B. in Bezug auf jeden HIL-, SIL-, PIL- und KI-Aktor) hosten, sowie das Rendering und die Verwaltung der Umgebung oder des Weltzustands (z.B. der Straße, von Schildern, Bäumen, Laub, Himmel, Sonne, Beleuchtung usw.) beinhalten. In einigen Beispielen kann/können die Simulatorkomponente(n) 402 einen oder mehrere Server und zugehörige Komponenten (z.B. CPU(s), GPU(s), Computer usw.) beinhalten, die einen Simulator (z.B. NVIDIAs DRIVE® Constellation AV Simulator) hosten können.
  • Die Fahrzeug-Hardware 104 wie hierin beschrieben kann der Fahrzeug-Hardware 104 aus 1 entsprechen, die in dem physischen Fahrzeug 102 verwendet werden kann. In dem Simulationssystem 400A kann die Fahrzeug-Hardware 104 jedoch in die Fahrzeugsimulatorkomponente(n) 406 integriert sein. Weil die Fahrzeug-Hardware 104 für den Einbau innerhalb des Fahrzeugs 102 konfiguriert sein kann, kann das Simulationssystem 400A speziell so konfiguriert werden, dass es die Fahrzeug-Hardware 104 innerhalb eines Knotens (z.B. einer Server-Plattform) des Simulationssystems 400A verwendet. Beispielsweise können ähnliche Schnittstellen, die in dem physischen Fahrzeug 102 verwendet werden, von der/den Fahrzeugsimulatorkomponente(n) 406 verwendet werden müssen, um mit der Fahrzeug-Hardware 104 zu kommunizieren. In einigen Beispielen können die Schnittstellen beinhalten: (1) CAN-Schnittstellen, einschließlich eines PCAN-Adapters, (2) Ethernet-Schnittstellen, einschließlich RAW-UDP-Buchsen mit IP-Adresse, wobei Ursprung, VLA und/oder Quell-IP alle erhalten bleiben, (3) serielle Schnittstellen, mit einem USB-zu-seriell-Adapter, (4) Kameraschnittstellen, (5) InfiniBand (IB)-Schnittstellen und/oder andere Schnittstellentypen.
  • In beliebigen Beispielen können, sobald die Sensordaten, die für ein Sichtfeld (Sichtfelder) des/der Sensoren des Fahrzeugs in der simulierten Umgebung repräsentativ sind, erzeugt und/oder verarbeitet wurden (z.B. unter Verwendung eines oder mehrerer Codecs, wie hierin beschrieben), die Sensordaten (und/oder codierte Sensordaten) von dem/den Software-Stack(s) 116 (beispielsweise dem Software-Stack für autonomes Fahren), auf der Fahrzeug-Hardware 104 ausgeführt werden, um eine oder mehrere Operationen (z.B. Generieren einer oder mehrerer Steuerungen, Routenplanung, Erfassen von Objekten, Identifizieren von befahrbarem freiem Raum, Überwachen der Umgebung zur Hindernisvermeidung usw.) durchzuführen. Infolgedessen können die identischen, oder im Wesentlichen identischen, Hardware-Komponenten, die von dem Fahrzeug 102 (z.B. einem physischen Fahrzeug) zur Ausführung des Software-Stacks für autonomes Fahren in realen Umgebungen verwendet werden, zur Ausführung des Software-Stacks für autonomes Fahren in der simulierten Umgebung 410 verwendet werden. Die Verwendung der Fahrzeug-Hardware 104 in dem Simulationssystem 400A stellt somit eine genauere Simulation davon dar, wie sich das Fahrzeug 102 in realen Situationen, Szenarien und Umgebungen verhalten wird, ohne dass das Fahrzeug 102 in der realen Welt tatsächlich gefunden und getestet werden muss. Dies kann die für das Testen der in dem physischen Fahrzeug 102 verwendeten Hardware-/Software-Kombination erforderliche Fahrzeit reduzieren und kann Sicherheitsrisiken verringern, da ein Testen in der realen Welt (insbesondere für gefährliche Situationen, wie z.B. andere Fahrzeuge, die unregelmäßig oder mit unsicherer Geschwindigkeit fahren, Kinder, die auf der Straße spielen, Eis auf einer Brücke usw.) nicht erforderlich ist.
  • Zusätzlich zu der Fahrzeug-Hardware 104 kann/können die Fahrzeugsimulatorkomponente(n) 406 die Simulation des Fahrzeugs (oder eines anderen Objekts) unter Verwendung zusätzlicher Hardware, wie z.B. einem Computer - z.B. einer X86-Box - verwalten. In einigen Beispielen kann zusätzliche Verarbeitung für virtuelle Sensoren des virtuellen Objekts unter Verwendung der Fahrzeugsimulationskomponente(n) 406 ausgeführt werden. In solchen Beispielen kann zumindest ein Teil der Verarbeitung von der (den) Simulatorkomponente(n) 402 durchgeführt werden, und kann ein anderer Teil der Verarbeitung von der (den) Fahrzeugsimulatorkomponente(n) 406 (oder 420 oder 422, wie hierin beschrieben) ausgeführt werden. In anderen Beispielen kann die Verarbeitung der virtuellen Sensoren vollständig von der (den) Fahrzeugsimulatorkomponente(n) 406 ausgeführt werden.
  • Nun auf 4B Bezug nehmend, ist 4B eine weitere beispielhafte Darstellung eines Simulationssystems 400B, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Simulationssystem 400B kann die Simulatorkomponente(n) 402 (als ein oder mehrere Berechnungsknoten), die Fahrzeugsimulatorkomponente(n) 406 (als ein oder mehrere Berechnungsknoten) für ein oder mehrere HIL-Objekte, die Fahrzeugsimulatorkomponente(n) 420 (als ein oder mehrere Berechnungsknoten) für ein oder mehrere SIL-Objekte, die Fahrzeugsimulatorkomponente(n) 406 (als ein oder mehrere Berechnungsknoten) für ein oder mehrere PIL-Objekte und/oder eine oder mehrere zusätzliche Komponente(n) (oder Berechnungsknoten) für KI-Objekte und/oder andere Objekttypen beinhalten. Jeder der PIL-, HIL-, SIL-, KI- und/oder anderen Objekttyp-Berechnungsknoten kann mit der (den) Simulatorkomponente(n) 402 kommunizieren, um aus der globalen Simulation zumindest Daten zu erfassen, die dem jeweiligen Objekt innerhalb der Simulationsumgebung 410 entsprechen.
  • Beispielsweise kann (können) die Fahrzeugsimulatorkomponente(n) 422 von der globalen Simulation (z.B. repräsentiert durch die simulierte Umgebung 410), die von der (den) Simulatorkomponente(n) 402 gehostet wird (werden), Daten empfangen (z.B. abrufen, erhalten usw.), die der (den) Fahrzeugsimulatorkomponente(n) 422 entsprechen, ihr zugeordnet sind und/oder von ihr (ihnen) benötigt werden, um eine oder mehrere Operationen durch die Fahrzeugsimulatorkomponente(n) 422 für das PIL-Objekt durchzuführen. In einem solchen Beispiel können Daten (z.B. virtuelle Sensordaten, die einem Sichtfeld (Sichtfeldern) der virtuellen Kamera(s) des virtuellen Fahrzeugs entsprechen, virtuelle LIDAR-Daten, virtuelle RADAR-Daten, virtuelle Standortdaten, virtuelle IMU-Daten usw.), die jedem Sensor des PIL-Objekts entsprechen, von der (den) Simulatorkomponente(n) 402 empfangen werden. Diese Daten können verwendet werden, um eine Instanz der simulierten Umgebung zu erzeugen, die dem Sichtfeld eines entfernten Bedieners des virtuellen Fahrzeugs, das durch den entfernten Bediener gesteuert wird, entspricht, und der Teil der simulierten Umgebung kann auf eine Anzeige (z.B. eine Anzeige eines VR-Headsets, einen Computer- oder Fernsehbildschirm usw.) projiziert werden, um den entfernten Bediener bei der Steuerung des virtuellen Fahrzeugs über die simulierte Umgebung 410 zu unterstützen. Die von dem entfernten Bediener unter Verwendung der Fahrzeugsimulatorkomponente(n) 422 erzeugten oder eingegebenen Steuerungen können zum Aktualisieren eines Zustands des virtuellen Fahrzeugs innerhalb der simulierten Umgebung 410 an die Simulatorkomponente(n) 402 übertragen werden.
  • Als ein weiteres Beispiel kann/können die Fahrzeugsimulatorkomponente(n) 420 von der globalen Simulation, die von der (den) Simulatorkomponente(n) 402 gehostet wird, Daten empfangen (z.B. abrufen, erhalten usw.), die der (den) Fahrzeugsimulatorkomponente(n) 420 entsprechen, mit ihr verknüpft sind und/oder von ihr (ihnen) 420 benötigt werden, um eine oder mehrere Operationen durch die Fahrzeugsimulatorkomponente(n) 420 für das SIL-Objekt durchzuführen. In einem solchen Beispiel können von der (den) Simulatorkomponente(n) 402 Daten (z.B. virtuelle Sensordaten, die einem Sichtfeld (Sichtfeldern) der virtuellen Kamera(s) des virtuellen Fahrzeugs entsprechen, virtuelle LIDAR-Daten, virtuelle RADAR-Daten, virtuelle Standortdaten, virtuelle IMU-Daten usw.), die jedem Sensor des SIL-Objekts entsprechen, empfangen werden. Diese Daten können verwendet werden, um eine Instanz der simulierten Umgebung für jeden Sensor zu erzeugen (z.B. eine erste Instanz aus einem Sichtfeld einer ersten virtuellen Kamera des virtuellen Fahrzeugs, eine zweite Instanz aus einem Sichtfeld einer zweiten virtuellen Kamera, eine dritte Instanz aus einem Sichtfeld eines virtuellen LIDAR-Sensors usw.). Die Instanzen der simulierten Umgebung können somit zur Erzeugung von Sensordaten für jeden Sensor durch die Fahrzeugsimulatorkomponente(n) 420 verwendet werden. In einigen Beispielen können die Sensordaten unter Verwendung eines oder mehrerer Codecs codiert werden (z.B. kann jeder Sensor seinen eigenen Codec verwenden, oder kann jeder Sensortyp seinen eigenen Codec verwenden), um codierte Sensordaten zu erzeugen, die einem Software-Stack für autonomes Fahren, der von der/den Fahrzeugsimulatorkomponente(n) 420 simuliert oder emuliert wird, verständlich oder vertraut sein können. Zum Beispiel kann ein erster Fahrzeughersteller einen ersten Typ von LIDAR-Daten verwenden, kann ein zweiter Fahrzeughersteller einen zweiten Typ von LIDAR-Daten usw., und können somit die Codecs die Sensordaten an die von den Herstellern verwendeten Typen von Sensordaten anpassen. Infolgedessen kann das Simulationssystem 400 universell, anpassbar und/oder von eine beliebigen Anzahl verschiedener Sensortypen verwendbar sein, abhängig von den Sensortypen und den entsprechenden Datentypen, die von verschiedenen Herstellern verwendet werden. In jedem Beispiel können die Sensordaten und/oder die codierten Sensordaten von einem Software-Stack für autonomes Fahren verwendet werden, um eine oder mehrere Operationen (z.B. Objekterfassung, Pfadplanung, Steuerungsbestimmungen, Betätigungsarten usw.) durchzuführen. Beispielsweise können die Sensordaten und/oder codierten Daten als Eingänge für ein oder mehrere DNNs des Software-Stacks für autonomes Fahren verwendet werden, und können die Ausgaben des einen oder der mehreren DNNs zum Aktualisieren eines Zustands des virtuellen Fahrzeugs innerhalb der simulierten Umgebung 410 verwendet werden. Somit kann die Zuverlässigkeit und Wirksamkeit des Software-Stacks für autonomes Fahren, einschließlich eines oder mehrerer DNNs, innerhalb der simulierten Umgebung getestet, feinabgestimmt, verifiziert und/oder validiert werden.
  • In einem nochmals weiteren Beispiel können die Fahrzeugsimulatorkomponente(n) 406 von der globalen Simulation, die von der/den Simulatorkomponente(n) 402 gehostet wird, Daten empfangen (z.B. abrufen, erhalten usw.), die der/den Fahrzeugsimulatorkomponente(n) 406 entsprechen, mit ihr verknüpft sind und/oder von ihr/ihnen benötigt werden, um eine oder mehrere Operationen der Fahrzeugsimulatorkomponente(n) 406 für das HIL-Objekt durchzuführen. In einem solchen Beispiel können von der (den) Simulatorkomponente(n) 402 Daten (z.B. virtuelle Sensordaten, die einem Sichtfeld (Sichtfeldern) der virtuellen Kamera(s) des virtuellen Fahrzeugs entsprechen, virtuelle LIDAR-Daten, virtuelle RADAR-Daten, virtuelle Standortdaten, virtuelle IMU-Daten usw.), die jedem Sensor des HIL-Objekts entsprechen, empfangen werden. Diese Daten können verwendet werden, um eine Instanz der simulierten Umgebung für jeden Sensor zu erzeugen (z.B. eine erste Instanz aus einem Sichtfeld einer ersten virtuellen Kamera des virtuellen Fahrzeugs, eine zweite Instanz aus einem Sichtfeld einer zweiten virtuellen Kamera, eine dritte Instanz aus einem Sichtfeld eines virtuellen LIDAR-Sensors usw.). Die Instanzen der simulierten Umgebung können somit von der/den Fahrzeugsimulatorkomponente(n) 420 zur Erzeugung von Sensordaten für jeden Sensor verwendet werden. In einigen Beispielen können die Sensordaten unter Verwendung eines oder mehrerer Codecs codiert werden (z.B. kann jeder Sensor seinen eigenen Codec verwenden, oder kann jeder Sensortyp seinen eigenen Codec verwenden), um codierte Sensordaten zu erzeugen, die für einen Software-Stack für autonomes Fahren, der auf der Fahrzeug-Hardware 104 der Fahrzeugsimulatorkomponente(n) 420 ausgeführt wird, verständlich oder vertraut sein können. Ähnlich zu dem hierin beschriebenen SIL-Objekt können die Sensordaten und/oder die codierten Sensordaten von einem Software-Stack für autonomes Fahren verwendet werden, um eine oder mehrere Operationen (z.B. Objekterfassung, Wegplanung, Steuerbestimmungen, Betätigungsarten usw.) durchzuführen.
  • Nun auf 4C Bezug nehmend, ist 4C eine weitere beispielhafte Darstellung für ein Simulationssystem 400C, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Simulationssystem 400C kann das System mit verteiltem gemeinsamem Speicher (DSM) 242, die Simulatorkomponente(n) 402 (als einen oder mehrere Rechenknoten), die Fahrzeugsimulatorkomponente(n) 406 (als ein oder mehrere Rechenknoten) für ein oder mehrere HIL-Objekte, die Fahrzeugsimulatorkomponente(n) 420 (als ein oder mehrere Berechnungsknoten) für ein SIL-Objekt (SIL-Objekte), die Fahrzeugsimulatorkomponente(n) 406 (als ein oder mehrere Berechnungsknoten) für ein PIL-Objekt (PIL-Objekte) und/oder zusätzliche Komponente(n) (oder Berechnungsknoten) für KI-Objekte und/oder andere Objekttypen (nicht gezeigt) beinhalten. Das Simulationssystem 400C kann eine beliebige Anzahl von HIL-Objekten (z.B. jedes mit seiner/seinen eigenen Fahrzeugsimulatorkomponente(n) 406), eine beliebige Anzahl von SIL-Objekten (z.B. jedes mit seiner/seinen eigenen Fahrzeugsimulatorkomponente(n) 420), eine beliebige Anzahl von PIL-Objekten (z.B. jedes mit seiner/seinen eigenen Fahrzeugsimulatorkomponente(n) 422) und/oder eine beliebige Anzahl von KI-Objekten (nicht gezeigt, kann aber je nach Ausführungsform von der/den Simulationskomponente(n) 402 und/oder separaten Rechenknoten gehostet werden) beinhalten.
  • Die Fahrzeugsimulatorkomponente(n) 406 kann/können ein oder mehrere SoC(s) 1104 (oder andere Komponenten) beinhalten, die für den Einbau und die Verwendung innerhalb eines physischen Fahrzeugs konfiguriert sein können. Wie hierin beschrieben wurde, kann das Simulationssystem 400C dazu konfiguriert sein, das (die) SoC(s) 1104 und/oder andere Fahrzeug-Hardware 104 zu verwenden, indem spezifische Schnittstellen für die Kommunikation mit dem (den) SoC(s) 1104 und/oder anderer Fahrzeug-Hardware verwendet werden. Die Fahrzeugsimulatorkomponente(n) 420 kann/können eine oder mehrere Software-Instanzen 430 beinhalten, die auf einer oder mehreren GPUs und/oder CPUs gehostet sein können, um das (die) SoC(s) 1104 zu simulieren oder zu emulieren. Die Fahrzeugsimulatorkomponente(n) 422 kann/können ein oder mehrere SoC(s) 426, eine oder mehrere CPU(s) 428 (z.B. X86-Boxen) und/oder eine Kombination davon beinhalten, zusätzlich zu der/den Komponente(n), die von dem entfernten Bediener verwendet werden kann/können (z.B. Tastatur, Maus, Joystick, Monitore, VR-Systeme, Lenkrad, Pedale, fahrzeugeigene Komponenten wie Lichtschalter, Blinker, HMI-Display(s) usw. und/oder andere Komponente(n)).
  • Die Simulationskomponente(n) 402 kann/können eine beliebige Anzahl von CPU(s) 432 (z.B. X86-Boxen), GPU(s) und/oder eine Kombination davon beinhalten. Die CPU(s) 432 kann/können die Simulationssoftware zur Aufrechterhaltung der globalen Simulation beinhalten, und der/die Grafikprozessor(en) 434 kann/können für das Rendering, die Physik und/oder andere Funktionen zur Erzeugung der simulierten Umgebung 410 verwendet werden.
  • Wie hier beschrieben wurde, kann das Simulationssystem 400C das DSM 424 beinhalten. Das DSM 424 kann ein oder mehrere verteilte Shared-Memory-Protokolle verwenden, um den Zustand der globalen Simulation unter Verwendung des Zustands jedes der Objekte (z.B. HIL-Objekte, SIL-Objekte, PIL-Objekte, KI-Objekte usw.) aufrechtzuerhalten. Somit kann jeder der Rechenknoten, der der (den) Fahrzeugsimulatorkomponente(n) 406, 420 und/oder 422 entspricht, über das DSM 424 mit der (den) Simulationskomponente(n) 402 in Verbindung stehen. Durch Verwenden des DSM 424 und der zugehörigen Protokolle kann eine Echtzeitsimulation möglich sein. Im Gegensatz dazu, wie Netzwerkprotokolle (z.B. TCP, UDP usw.) in Massive Multiplayer Online (MMO)-Spielen verwendet werden, kann das Simulationssystem 400 beispielsweise ein Protokoll für verteilten gemeinsamen Speicher verwenden, um den Zustand der globalen Simulation und jeder Instanz der Simulation (z.B. durch jedes Fahrzeug, Objekt und/oder Sensor) in Echtzeit aufrechtzuerhalten.
  • Nun auf 4D Bezug nehmend, ist 4D ein Beispiel für eine Hardware-in-the-Loop-Konfiguration, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Die Fahrzeugsimulatorkomponente(n) 406 kann/können die Fahrzeug-Hardware 104, wie hierin beschrieben, beinhalten, und kann/können einen oder mehrere Computer 436, eine oder mehrere GPU(s) (nicht gezeigt) und/oder eine oder mehrere CPU(s) (nicht gezeigt) beinhalten. Der (die) Computer 436, der (die) Grafikprozessor(en) und/oder die CPU(s) können die Simulationssoftware 438 oder eine Instanz davon verwalten oder hosten, die auf der (den) Fahrzeugsimulatorkomponente(n) 406 ausgeführt wird. Die Fahrzeug-Hardware 104 kann den/die Softwarestack(s) 116 ausführen (z.B. einen Software-Stack für autonomes Verfahren, einen IX-Software-Stack usw.).
  • Wie hierin beschrieben wurde, kann es bei Verwendung der Fahrzeug-Hardware 104 erforderlich sein, die andere(n) Fahrzeugsimulatorkomponente(n) 406 innerhalb der Simulationsumgebung 400 für die Kommunikation mit der Fahrzeug-Hardware 104 zu konfigurieren. Beispielsweise kann, weil die Fahrzeug-Hardware 104 z.B. für den Einbau in ein physisches Fahrzeug (z.B. das Fahrzeug 102) konfiguriert werden kann, die Fahrzeug-Hardware 104 so konfiguriert werden, dass sie über einen oder mehrere Verbindungstypen und/oder Kommunikationsprotokolle kommuniziert, die in Rechenumgebungen (z.B. in serverbasierten Plattformen, in Allzweckrechnern usw.) nicht Standard sind. Beispielsweise können eine CAN-Schnittstelle, eine LVDS-Schnittstelle, eine USB-Schnittstelle, eine Ethernet-Schnittstelle, eine InfiniBand (IB) - Schnittstelle und/oder andere Schnittstellen von der Fahrzeug-Hardware 104 verwendet werden, um Signale mit anderen Komponenten des physischen Fahrzeugs zu kommunizieren. Daher müssen in dem Simulationssystem 400 die Fahrzeugsimulatorkomponente(n) 406 (und/oder andere Komponente(n) des Simulationssystems 400 zusätzlich zu oder alternativ zu der/den Fahrzeugsimulatorkomponente(n) 406) möglicherweise für die Verwendung mit der Fahrzeug-Hardware 104 konfiguriert werden. Um dies zu erreichen, können eine oder mehrere CAN-Schnittstellen, LVDS-Schnittstellen, USB-Schnittstellen, Ethernet-Schnittstellen und/oder andere Schnittstellen verwendet werden, um die Kommunikation (z.B. über ein oder mehrere Kommunikationsprotokolle, wie beispielsweise LVDS) zwischen der Fahrzeug-Hardware 104 und der/den anderen Komponente(n) des Simulationssystems 400 zu ermöglichen.
  • In einigen Beispielen kann das virtuelle Fahrzeug, das der/den Fahrzeugsimulatorkomponente(n) 406 innerhalb des Simulationssystems 400 entsprechen kann, als ein Spielobjekt innerhalb einer Instanz einer Spiele-Engine modelliert werden. Darüber hinaus kann jeder der virtuellen Sensoren des virtuellen Fahrzeugs über Sockets innerhalb der/des Softwarestack(s) 116 des virtuellen Fahrzeugs, der auf der Fahrzeug-Hardware 104 ausgeführt wird, angeschlossen werden. In einigen Beispielen kann jeder der virtuellen Sensoren des virtuellen Fahrzeugs zusätzlich zu der Instanz der Spiele-Engine, die der Simulationssoftware 438 für das virtuelle Fahrzeug zugehörig ist, eine Instanz der Spiele-Engine beinhalten. In Beispielen, in denen die Fahrzeugsimulatorkomponente(n) 406 eine Vielzahl von GPUs beinhalten, kann jeder der Sensoren auf einer einzelnen GPU ausgeführt werden. In anderen Beispielen können mehrere Sensoren, oder zumindest so viele Sensoren wie zur Gewährleistung einer Echtzeit-Generierung der virtuellen Sensordaten möglich, auf einer einzelnen GPU ausgeführt werden.
  • Die Verwendung von HIL-Objekten in dem Simulatorsystem 400 kann eine skalierbare Lösung bereitstellen, die verschiedene Fahrbedingungen für autonome Software- und Hardwaresysteme (z.B. NVIDIAs DRIVE AGX Pegasus® Rechenplattform und/oder DRIVE PX Xavier® Rechenplattform) simulieren oder emulieren kann. Zu den Vorteilen von HIL-Objekten gehören u. a. die Möglichkeit, DNNs schneller als in Echtzeit zu testen, die Möglichkeit, die Verifikation mit Rechenressourcen (z.B. anstelle von Fahrzeugen oder Teststrecken) zu skalieren, die Möglichkeit, deterministische Regressionstests durchzuführen (z.B. ist die Umgebung in der realen Welt nie zweimal die gleiche, aber eine simulierte Umgebung kann es sein), optimales Ground Truth Labeling (z.B. keine Beschriftung von Hand erforderlich), die Möglichkeit, Szenarien zu testen, die in der realen Welt schwer zu produzieren sind, die schnelle Generierung von Testpermutationen und die Möglichkeit, im Vergleich zur realen Welt einen größeren Raum von Permutationen in der Simulation zu testen.
  • Nun auf 4E Bezug nehmend, ist 4E eine beispielhafte Darstellung eine Hardware-in-the-Loop-Konfiguration, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Die HIL-Konfiguration von 4E kann Fahrzeugsimulatorkomponente(n) 406 beinhalten, einschließlich des/der SoC(s) 1104, eines oder mehrerer Chassislüfter 456 und/oder eines Wasserkühlungssystems. Die HIL-Konfiguration kann eine Zwei-Box-Lösung (z.B. die Simulatorkomponente(n) 402 in einer ersten Box und die Fahrzeugsimulatorkomponente(n) 406 in einer zweiten Box) beinhalten. Die Verwendung dieses Ansatzes kann den Platzbedarf des Systems verringern sowie die Anzahl externer Kabel in Datenzentren reduzieren (z.B. durch Einbeziehen mehrerer Komponenten zusammen mit dem/den SoC(s) 1104 in die Fahrzeugsimulatorkomponente(n) 406 - z.B. die erste Box). Die Fahrzeugsimulatorkomponente(n) 406 kann/können eine oder mehrere GPUs 452 (z.B. NVIDIA QUADRO GPU(s)) beinhalten, die, in einer beispielhaften, nicht beschränkenden Ausführungsform, 8 DP/HDMI-Videoströme bereitstellen können, die unter Verwendung einer bzw. von Sync-Komponente(n) 454 (z.B. durch eine QUADRO Sync II-Karte) synchronisiert werden können. Diese GPU(s) 452 (und/oder andere GPU-Typen) können die Sensoreingabe in die SoC(s) 1104 (z.B. in die Fahrzeug-Hardware 104) bereitstellen. In einigen Beispielen kann/können die Fahrzeugsimulatorkomponente(n) 406 eine Netzwerkschnittstelle (z.B. eine oder mehrere Netzwerkschnittstellenkarten (NICs) 450) beinhalten, die RADAR-Sensoren, LIDAR-Sensoren und/oder IMU-Sensoren simulieren oder emulieren kann (z.B. durch Bereitstellen von 8 Gigabit-Ports mit Precision Time Protocol (PTP)-Unterstützung). Darüber hinaus kann/können die Fahrzeugsimulatorkomponente(n) 406 eine analoge integrierte Eingabe-/Ausgabe (E/A)-Schaltung beinhalten. Registered Jack (RJ)-Schnittstellen (z.B. RJ45), Hochgeschwindigkeits-Daten-(HSD)-Schnittstellen, USB-Schnittstellen, Puls pro Sekunde (PPS)-Taktgeber, Ethernet (z.B. 10Gb Ethernet (GbE))-Schnittstellen, CAN-Schnittstellen, HDMI-Schnittstellen und/oder andere Schnittstellen-typen können zur effektiven Übertragung und Kommunikation von Daten zwischen und unter den verschiedenen Komponenten des Systems verwendet werden.
  • Nun auf 4F Bezug nehmend, ist 4F eine beispielhafte Darstellung einer Software-in-the-Loop-Konfiguration, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Die Fahrzeugsimulatorkomponente(n) 420 kann/können Computer 440, GPU(s) (nicht gezeigt), CPU(s) (nicht gezeigt) und/oder andere Komponenten beinhalten. Der/die Computer 440, der/die Grafikprozessor(en) und/oder die CPU(s) können die Simulationssoftware 438 oder eine Instanz davon verwalten oder hosten, die auf der/den Fahrzeugsimulatorkomponente(n) 420 ausgeführt wird, und können den/die Softwarestack(s) 116 hosten. Beispielsweise kann/können die Fahrzeugsimulator-komponente(n) 420 die Fahrzeug-Hardware 104 unter Verwendung von Software simulieren oder emulieren, um den/die Softwarestack(s) 116 so genau wie möglich auszuführen.
  • Um die Genauigkeit in SIL-Ausführungsformen zu erhöhen, können die Fahrzeugsimulatorkomponente(n) 420 so konfiguriert werden, dass sie über einen oder mehrere virtuelle Verbindungstypen und/oder ein oder mehrere Kommunikationsprotokolle kommunizieren, die in Computerumgebungen nicht Standard sind. Beispielsweise können eine virtuelle CAN-Schnittstelle, eine virtuelle LVDS-Schnittstelle, eine virtuelle USB-Schnittstelle, eine virtuelle Ethernet-Schnittstelle und/oder andere virtuelle Schnittstellen von dem/den Computer(n) 440, der/den CPU(s) und/oder der/den GPU(s) der Fahrzeugsimulatorkomponente(n) 420 verwendet werden, um eine Kommunikation (z.B. über ein oder mehrere Kommunikationsprotokolle, wie beispielsweise LVDS) zwischen dem/den Softwarestack(s) 116 und der Simulationssoftware 438 innerhalb des Simulationssystems 400 bereitzustellen. Die virtuellen Schnittstellen können z.B. Middleware beinhalten, die dazu verwendet werden kann, eine kontinuierliche Rückkopplungsschleife mit dem/den Softwarestack(s) 116 bereitzustellen. Als solche können die virtuellen Schnittstellen die Kommunikation zwischen der Fahrzeug-Hardware 104 und dem physischen Fahrzeug simulieren oder emulieren, indem sie ein oder mehrere Softwareprotokolle, Hardware (z.B. CPU(s), GPU(s), Computer 440 usw.) oder eine Kombination davon verwenden.
  • Der/die Computer 440 kann/können in einigen Beispielen X86-CPU-Hardware beinhalten, und eine oder mehrere X86-CPUs können sowohl die Simulationssoftware 438 als auch den/die Software-Stack(s) 116 ausführen. In anderen Beispielen kann der/die Computer 440 GPU-Hardware (z.B. ein NVIDIA DGX-System und/oder Cloud-basierte NVIDIA Tesla-Server) beinhalten.
  • In einigen Beispielen kann das virtuelle Fahrzeug, das der/den Fahrzeugsimulatorkomponente(n) 420 innerhalb des Simulationssystems 400 entsprechen kann, als ein Spielobjekt innerhalb einer Instanz einer Spiele-Engine modelliert werden. Darüber hinaus kann jeder der virtuellen Sensoren des virtuellen Fahrzeugs über Sockets innerhalb des/der auf der/den Fahrzeugsimulatorkomponente(n) 420 ausgeführten Software-Stacks 116 des virtuellen Fahrzeugs verbunden werden. In einigen Beispielen kann jeder der virtuellen Sensoren des virtuellen Fahrzeugs zusätzlich zu der Instanz der Spiele-Engine, die der Simulationssoftware 438 für das virtuelle Fahrzeug zugeordnet ist, eine Instanz der Spiele-Engine beinhalten. In Beispielen, in denen die Fahrzeugsimulatorkomponente(n) 406 eine Vielzahl von GPUs beinhalten, kann jeder der Sensoren auf einer einzelnen GPU ausgeführt werden. In anderen Beispielen können mehrere Sensoren oder zumindest so viele Sensoren wie möglich sind, um eine Echtzeit-Generierung der virtuellen Sensordaten zu gewährleisten, auf einer einzelnen GPU ausgeführt werden.
  • Nun auf 5 Bezug nehmend, umfasst jeder Block eines hierin beschriebenen Verfahrens 500 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch als computerverwendbare Befehle, die auf Computerspeichermedien gespeichert sind, ausgebildet sein. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) bereitgestellt sein, oder als ein Plug-in für ein anderes Produkt, um nur einige zu nennen. Darüber hinaus wird das Verfahren 500 beispielhaft in Bezug auf das Simulationssystem 400 von 4A-4C beschrieben. Das Verfahren kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen, einschließlich der, aber nicht beschränkt auf die, hierin beschriebenen Systeme ausgeführt werden.
  • 5 ist ein Ablaufdiagramm, das ein Verfahren 500 zum Erzeugen einer simulierten Umgebung unter Verwendung eines Hardware-in-the-Loop-Objekts zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 500 beinhaltet in einem Block B502 die Übertragung von Simulationsdaten von einer ersten Hardware-Komponente zu einer zweiten Hardware-Komponente. Zum Beispiel kann (können) die Simulationskomponente(n) 402 Simulationsdaten an eine oder mehrere der Fahrzeugsimulatorkomponente(n) 406, der Fahrzeugsimulatorkomponente(n) 420 und/oder der Fahrzeugsimulatorkomponente(n) 422 übertragen. In einigen Beispielen können die Simulationsdaten repräsentativ sein für zumindest einen Teil der simulierten Umgebung 410, die von der (den) Simulationskomponente(n) 402 gehostet wird, und können der simulierten Umgebung 410 in Bezug auf zumindest einen virtuellen Sensor eines virtuellen Objekts (z.B. eines HIL-Objekts, eines SIL-Objekts, eines PIL-Objekts und/oder eines KI-Objekts) entsprechen. In einem Beispiel, in dem der virtuelle Sensor eine virtuelle Kamera ist, können die Simulationsdaten zumindest den Daten aus der Simulation entsprechen, die erforderlich sind, um ein Sichtfeld der virtuellen Kamera innerhalb der simulierten Umgebung 410 zu erzeugen.
  • Das Verfahren 500 beinhaltet in einem Block B504 ein Empfangen eines Signals durch die erste Hardware-Komponente und von der zweiten Hardware-Komponente. Zum Beispiel kann/können die Simulatorkomponente(n) 402 ein Signal von einer der Fahrzeugsimulatorkomponente(n) 406, der Fahrzeugsimulatorkomponente(n) 420 und/oder der Fahrzeugsimulatorkomponente(n) 422 empfangen. Das Signal kann repräsentativ sein für eine Operation (z.B. Steuerung, Wegplanung, Objekterfassung usw.) entsprechend einem virtuellen Objekt (z.B. einem HIL-Objekt, einem SIL-Objekt, einem PIL-Objekt und/oder einem KI-Objekt), wie es durch einen oder mehrere Software-Stack(s) 116 bestimmt wird. In einigen Beispielen, in denen z.B. das virtuelle Objekt ein HIL-Objekt ist, kann das Signal (oder dadurch repräsentierte Daten) von der Fahrzeug-Hardware 104 zu einer oder mehreren anderen Fahrzeugsimulatorkomponente(n) 406 übertragen werden, und dann kann/können die Fahrzeugsimulatorkomponente(n) 406 das Signal zu der/den Simulatorkomponente(n) 402 übertragen. In solchen Beispielen können die Signale zwischen der (den) Fahrzeugsimulatorkomponente(n) 406 (z.B. zwischen der Fahrzeug-Hardware 104 und einer oder mehreren GPU(s), CPU(s) und/oder einem oder mehreren Computer(n) 436) über eine CAN-Schnittstelle, eine USB-Schnittstelle, eine LVDS-Schnittstelle, eine Ethernet-Schnittstelle und/oder eine andere Schnittstelle übertragen werden. In einem anderen Beispiel, z.B. wenn das virtuelle Objekt ein SIL-Objekt ist, kann das Signal (oder dadurch repräsentierte Daten) von der (den) Fahrzeugsimulatorkomponente(n) 420 zu der (den) Simulatorkomponente(n) 402 übertragen werden, wobei die in dem Signal beinhalteten Daten durch den (die) Softwarestack(s) 116 erzeugt werden können, der (die) auf simulierter oder emulierter Fahrzeug-Hardware 104 ausgeführt wird (werden). In solchen Beispielen kann (können) die Fahrzeugsimulatorkomponente(n) 420 eine virtuelle CAN-, eine virtuelle LVDS-Schnittstelle, eine virtuelle USB-Schnittstelle, eine virtuelle Ethernet-Schnittstelle und/oder andere virtuelle Schnittstellen verwenden.
  • Das Verfahren 500 beinhaltet in einem Block B506 ein Aktualisieren eines oder mehrerer Attribute eines virtuellen Objekts innerhalb einer simulierten Umgebung durch die erste Hardware-Komponente. Zum Beispiel kann/können, zumindest teilweise basierend auf dem Signal, das von der (den) Fahrzeugsimulatorkomponente(n) 406, der (den) Fahrzeugsimulatorkomponente(n) 420 und/oder der (den) Fahrzeugsimulatorkomponente(n) 422 empfangen wird, die Simulatorkomponente(n) 402 die globale Simulation aktualisieren (und die simulierte Umgebung kann entsprechend aktualisiert werden). In einigen Beispielen können die durch das Signal repräsentierten Daten dazu verwendet werden, die Position, die Orientierung, die Geschwindigkeit und/oder andere Attribute des virtuellen Objekts zu aktualisieren, das von der (den) Fahrzeugsimulatorkomponente(n) 406, der (den) Fahrzeugsimulatorkomponente(n) 420 und/oder der (den) Fahrzeugsimulatorkomponente(n) 422 gehostet wird.
  • Nun auf 6A Bezug nehmend, ist 6A eine beispielhafte Darstellung eines Simulationssystems 600 zur Laufzeit, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Einige oder alle der Komponenten des Simulationssystems 600 können in dem Simulationssystem 400 verwendet werden, und einige oder alle Komponenten des Simulationssystems 400 können in dem Simulationssystem 600 verwendet werden. Als solche können Komponenten, Merkmale und/oder Funktionen, die in Bezug auf das Simulationssystem 400 beschrieben werden, dem Simulationssystem 600 zugehörig sein und umgekehrt. Darüber hinaus kann jedes der Simulationssysteme 600A und 600B (6B) ähnliche und/oder gemeinsame Komponenten, Merkmale und/oder Funktionen beinhalten.
  • Das Simulationssystem 600A (das z.B. ein Beispiel des Simulationssystems 600 repräsentiert) kann die Simulatorkomponente(n) 402, einen oder mehrere Codec(s) 614, einen oder mehrere Inhaltsdatenspeicher 602, einen oder mehrere Szenariodatenspeicher 604, die Fahrzeugsimulatorkomponente(n) 420 (z.B. für ein SIL-Objekt) und die Fahrzeugsimulatorkomponente(n) 406 (z.B. für ein HIL-Objekt) beinhalten. Der/die Inhaltsdatenspeicher 602 können detaillierte Inhaltsinformationen zum Modellieren von Autos, Lastwagen, Personen, Radfahrern, Schildern, Gebäuden, Bäumen, Bordsteinkanten und/oder anderen Merkmalen der simulierten Umgebung beinhalten. Der/die Szenario-Datenspeicher 604 können Szenario-Informationen beinhalten, die Informationen über gefährliche Szenarios beinhalten können (z.B. die in der realen Umgebung nicht sicher zu testen sind), wie z.B. ein Kind in einer Kreuzung.
  • Die Simulatorkomponente(n) 402 kann/können eine KI-Engine 608 beinhalten, die Verkehr, Fußgänger, Wetter und/oder andere KI-Merkmale der simulierten Umgebung simuliert. Die Simulatorkomponente(n) 402 kann/können einen virtuelle Welt-Manager bzw. Virtual World Manager 610 beinhalten, der den Weltstatus für die globale Simulation verwaltet. Die Simulatorkomponente(n) 402 kann/können ferner einen virtueller Sensor-Manager 612 beinhalten, der die virtuellen Sensoren verwaltet. Die KI-Engine 608 kann Verkehr ähnlich dazu, wie Verkehr in einem Automobil-Videospiel modelliert wird, modellieren und kann, wie hierin beschrieben, unter Verwendung einer Spiele-Engine ausgeführt werden. In anderen Beispielen kann eine benutzerdefinierte KI dazu verwendet werden, den Determinismus und ein rechnerisches Detailniveau zu erreichen, die für eine groß angelegte, reproduzierbare Fahrzeugsimulation erforderlich sind. In einigen Beispielen kann Verkehr unter Verwendung von SIL-Objekten, HIL-Objekten, PIL-Objekten, KI-Objekten und/oder einer Kombination davon modelliert werden. Das System 600 kann eine Unterklasse eines KI-Controllers erstellen, der Kartendaten untersucht, eine Route berechnet und die Route unter Vermeidung anderer Fahrzeuge abfährt. Der KI-Controller kann gewünschtes Lenken, gewünschte Beschleunigung und/oder gewünschtes Bremsen berechnen, und kann diese Werte auf virtuelle Objekte anwenden. Die verwendeten Fahrzeugeigenschaften können Masse, maximale Drehzahl, Drehmomentkurven und/oder andere Eigenschaften beinhalten. Eine Physik-Engine kann dazu verwendet werden, Zustände von KI-Objekten zu bestimmen. Wie hierin beschrieben, kann sich das System bei Fahrzeugen oder anderen Objekten, die weit entfernt sein können und keinen Einfluss auf einen oder mehrere Stromsensoren haben, dafür entscheiden, Physik auf diese Objekte nicht anzuwenden und nur Orte und/oder momentane Bewegungsvektoren zu bestimmen. Ray-Casting kann für jedes Rad verwendet werden, um sicherzustellen, dass die Räder der Fahrzeuge in Kontakt sind. In einigen Beispielen kann eine Verkehrs-KI in Übereinstimmung mit einem Skript (z.B. regelbasiertem Verkehr) arbeiten. Manöver der Verkehrs-KI für virtuelle Objekte können seitliche Fahrspurwechsel (z.B. Richtung, Abstand, Dauer, Form usw.), Längsbewegung (z.B. Anpassung der Geschwindigkeit, relatives Ziel, Delta zum Ziel, absoluter Wert), Routenverfolgung und/oder Pfad- bzw. Wegverfolgung beinhalten. Die Auslöser für die Manöver der Verkehrs-KI können zeitbasiert (z.B. drei Sekunden), geschwindigkeitsbasiert (z.B. bei sechzig Mph), nähenbasiert zur Karte (z.B. innerhalb von zwanzig Fuß von einer Kreuzung), nähenbasiert zu einem Aktor (z.B. innerhalb von zwanzig Fuß von einem anderen Objekt), spurfrei und/oder andere sein.
  • Die KI-Engine 608 kann eine Fußgänger-KI ähnlich zu der hierin beschriebenen Verkehrs-KI modellieren, jedoch für Fußgänger. Die Fußgänger können ähnlich wie echte Fußgänger modelliert werden, und das System 600 kann auf der Grundlage gelernten Verhaltens auf das Verhalten von Fußgängern schließen.
  • Die Simulatorkomponente(n) 402 kann/können dazu verwendet werden, die Tageszeit so einzustellen, dass Straßenlampen einschalten und ausschalten, Scheinwerfer einschalten und ausschalten, Schatten, Blendungen und/oder Sonnenuntergänge berücksichtigt werden, usw. In einigen Beispielen können zur Effizienzsteigerung nur Lichter innerhalb eines Schwellenabstands zu dem virtuellen Objekt berücksichtigt werden.
  • Wetter kann durch die Simulatorkomponente(n) 402 (z.B. durch den Virtual World Manager 610) berücksichtigt werden. Das Wetter kann dazu verwendet werden, die Reibungskoeffizienten für die Fahroberflächen zu aktualisieren, und Temperaturinformationen können dazu verwendet werden, eine Interaktion der Reifen mit den Fahroberflächen zu aktualisieren. Wenn Regen oder Schnee vorhanden sind, kann das System 600 Maschen erzeugen, um zu beschreiben, wo sich Regenwasser und Schnee akkumulieren können, basierend auf der Struktur der Szene, und die Maschen können verwendet werden, wenn Regen oder Schnee in der Simulation vorhanden sind.
  • In einigen Beispielen, wie hierin beschrieben, kann zumindest ein Teil der Simulatorkomponente(n) 402 alternativ in der/den Fahrzeugsimulatorkomponente(n) 420 und/oder 406 beinhaltet sein. Beispielsweise können die Fahrzeugsimulatorkomponente(n) 420 und/oder die Fahrzeugsimulatorkomponente(n) 406 den virtueller Sensor-Manager 612 zum Verwalten jedes der Sensoren des zugehörigen virtuellen Objekts beinhalten. Darüber hinaus kann einer oder mehrere der Codecs 614 in der (den) Fahrzeugsimulatorkomponente(n) 420 und/oder der (den) Fahrzeugsimulatorkomponen-te(n) 406 beinhalten sein. In solchen Beispielen kann der virtueller Sensor-Manager 612 Sensordaten erzeugen, die einem Sensor des virtuellen Objekts entsprechen, und können die Sensordaten vom einem Sensoremulator 616 des/der Codecs 614 dazu verwendet werden, die Sensordaten in Übereinstimmung mit dem Sensordatenformat oder -typ, das bzw. der von dem/den Software-Stack(s) (z.B. dem/den Softwarestack(s) 116, der/die auf der/den Fahrzeugsimulatorkomponente(n) 420 und/oder der/den Fahrzeugsimulatorkomponente(n) 406 ausgeführt wird/werden) verwendet wird, zu codieren.
  • Der (die) Codec(s) 614 kann (können) eine Schnittstelle zu dem (den) Software-Stack(s) 116 bereitstellen. Der/die Codec(s) 614 (und/oder andere hierin beschriebene Codec(s)) können ein Codierungs-/Decodierungs-Framework beinhalten. Der/die Codec(s) 614 kann/können CAN-Lenkung, Drosselklappenanforderungen beinhalten und/oder kann/können dazu verwendet werden, Sensordaten an den/die Software-Stack(s) 116 in SIL- und HIL-Ausführungsformen zu senden. Der/die Codec(s) 614 kann/können für die hierin beschriebenen Simulationssysteme (z.B. 400 und 600) von Vorteil sein. Beispielsweise können, da die Daten von den Re-Simulationssystemen 100 und den Simulationssystemen 400 und 600 erzeugt werden, die Daten derart an den/die Softwarestack(s) 116 übertragen werden, dass die folgenden Standards erfüllt werden können. Die Daten können derart an den/die Softwarestack(s) 116 übertragen werden, dass minimale Auswirkungen auf den/die Softwarestack(s) 116 und/oder die Fahrzeug-Hardware 104 (in HIL-Ausführungsformen) entstehen. Dies kann in genaueren Simulationen resultieren, da der/die Softwarestack(s) 116 und/oder die Fahrzeug-Hardware 104 in einer Umgebung betrieben werden können, die dem Einsatz in einer realen Umgebung sehr ähnlich ist. Die Daten können derart an den/die Softwarestack(s) 116 übertragen werden, dass der Simulator und/oder der Re-Simulator der tatsächlichen Hardware-Konfiguration des zu testenden Systems gegenüber agnostisch sein kann. Dies kann den Entwicklungsüberhang aufgrund von Bugs oder separaten Codepfaden je nach Simulationskonfiguration verringern. Die Daten können derart an den/die Softwarestack(s) 116 übertragen werden, dass die Daten (z.B. Bit-zu-Bit) mit den von einem physischen Sensor eines physischen Fahrzeugs (z.B. dem Fahrzeug 102) gesendeten Daten übereinstimmen können. Die Daten können sowohl in SIL- als auch in HIL-Ausführungsformen effizient übertragen werden.
  • Der Sensor-Emulator 616 kann zumindest Kameras, LIDAR-Sensoren und/oder RADAR-Sensoren emulieren. In Bezug auf LIDAR-Sensoren melden einige LIDAR-Sensoren nachverfolgte Objekte. Daher kann/können die Simulatorkomponente(n) 402 für jeden von den virtuellen Sensordaten repräsentierten Frame eine Liste aller nachverfolgten Objekte (z.B. Bäume, Fahrzeuge, Fußgänger, Laub usw.) in Reichweite des virtuellen Objekts mit den virtuellen LIDAR-Sensoren erstellen, und können virtuelle Strahlen auf die nachverfolgten Objekte werfen. Wenn eine signifikante Anzahl von Strahlen auf ein nachverfolgtes Objekt trifft, kann dieses Objekt in den Bericht der LIDAR-Daten aufgenommen werden. In einigen Beispielen können die LIDAR-Sensoren unter Verwendung einfachen Ray-Castings ohne Reflexion, einstellbares Sichtfeld, einstellbares Rauschen und/oder einstellbare Drop-Outs modelliert werden. LIDAR mit sich bewegenden Teilen, begrenzten Sichtfeldern und/oder variablen Auflösungen kann simuliert werden. Die LIDAR-Sensoren können zum Beispiel als Festkörper-LIDAR und/oder als Optix-basiertes LIDAR modelliert werden. Bei der Verwendung von Optixbasiertem LIDAR können in Bespielen die Strahlen von Wasser, reflektierenden Materialien und/oder Fenstern reflektiert werden. Den Straßen, Schildern und/oder Fahrzeugen können Texturen zugewiesen werden, um eine Laserreflexion bei den Wellenlängen zu modellieren, die den Texturen entsprechen. RADAR kann ähnlich wie LIDAR implementiert werden. Wie hierin beschrieben, kann RADAR und/oder LIDAR unter Verwendung von Raytracing-Techniken simuliert werden.
  • In einigen Beispielen können die Fahrzeugsimulatorkomponente(n) 406, 420 und/oder 422 eine Rückkopplungsschleife mit der/den Simulatorkomponente(n) 402 (und/oder der/den Komponente(n), die die virtuellen Sensordaten erzeugt/erzeugen) beinhalten. Die Rückkopplungsschleife kann dazu verwendet werden, Informationen zum Aktualisieren der Erfassung oder Erzeugung der virtuellen Sensordaten bereitzustellen. Bei virtuellen Kameras kann beispielsweise die Rückkopplungsschleife auf Sensorrückkopplung basieren, wie z.B. Änderungen der Belichtung in Abhängigkeit von Lichtverhältnissen (z.B. Erhöhung der Belichtung bei schwachen Lichtverhältnissen, so dass die Bilddaten von den DNNs korrekt verarbeitet werden können). Als ein weiteres Beispiel kann bei virtuellen LIDAR-Sensoren die Rückkopplungsschleife repräsentativ für Änderungen des Energieniveaus (z.B. zur Erhöhung der Energie, um besser nutzbare oder genauere LIDAR-Daten zu erzeugen) sein.
  • GNNS-Sensoren (z.B. GPS-Sensoren) können innerhalb des Simulationsraumes simuliert werden, um reale Koordinaten zu erzeugen. Dazu können Rauschfunktionen zur Näherung einer Ungenauigkeit verwendet werden. Wie bei allen hierin beschriebenen virtuellen Sensoren können die virtuellen Sensordaten unter Verwendung des/der Codecs 614 an den/die Softwarestack(s) 116 übertragen werden, um in ein Bit-zu-Bit korrektes Signal umgewandelt zu werden (z.B. genau den Signalen entsprechend, die von den physischen Sensoren der physischen Fahrzeuge erzeugt werden).
  • Eine oder mehrere Plugin Application Programming Interfaces (APIs) 606 können verwendet werden. Die Plugin-APIs 606 können Erstanbieter- bzw. First-Party- und/oder Drittanbieter- bzw. Third-Party-Plugins beinhalten. Beispielsweise können Drittanbieter das Simulationssystem 600B unter Verwendung ihrer eigenen Plugin-APIs 606 anpassen, um kundenspezifische Informationen, wie z.B. Leistungszeitpunkte, Aufhängungsdynamik, Reifendynamik usw., bereitzustellen.
  • Das Plugin-APIs 606 können eine oder mehrere eigendynamische Komponente(n) (nicht gezeigt) beinhalten, die Informationen von der/den Simulatorkomponente(n) 402 empfangen kann/können, einschließlich Position, Geschwindigkeit, Fahrzeugzustand und/oder anderen Informationen, und können die Informationen für die Simulatorkomponente(n) 402 bereitstellen, einschließlich Leistungszeitpunkten, Aufhängungsdynamik, Reifendynamik und/oder anderen Informationen. Beispielsweise kann (können) die Simulatorkomponente(n) 402 der (den) eigendynamischen Komponente(n) CAN-Drosselklappen-, Lenk- und Fahroberflächen-Informationen bereitstellen. In einigen Beispielen kann/können die eigendynamische(n) Komponente(n) ein standardmäßiges Fahrdynamik-Paket (z.B. IPG CARMAKER oder VIRTUAL TEST DRIVE) beinhalten, während in anderen Beispielen die eigendynamische(n) Komponente(n) angepasst und/oder empfangen werden können (z.B. von einem Erstanbieter und/oder einem Drittanbieter).
  • Die Plugin-APIs 606 können eine Key Performance Indicator (KPI)-API beinhalten. Die KPI-API kann CAN-Daten, Ground Truth und/oder Informationen über den Zustand eines virtuellen Objekts (z.B. von dem/den Softwarestack(s) 116) von der/den Simulatorkomponente(n) 402 empfangen und können einen Bericht (in Echtzeit) generieren und/oder bereitstellen, der KPIs und/oder Befehle zum Speichern des Zustands, zur Wiederherstellung des Zustands und/oder zur Anwendung von Änderungen beinhaltet.
  • Nun auf 6B Bezug nehmend, beinhaltet 6B eine Cloud-basierte Architektur für ein Simulationssystem 600B, in Übereinstimmung mit einer Ausführungsform der Erfindung. Das Simulationssystem 600B kann sich zumindest teilweise in der Cloud befinden und kann über ein oder mehrere Netzwerke, wie z.B., aber nicht beschränkt auf, die hierin beschriebenen (z.B. in Bezug auf ein Netzwerk 1190 von 1D), mit einer oder mehreren GPU-Plattformen 624 (die z.B. GPUs, CPUs, TPUS und/oder andere Prozessortypen beinhalten können) und/oder einer oder mehreren HIL-Plattformen 626 (die z.B. einige oder alle der Komponenten der hierin beschriebenen Fahrzeugsimulatorkomponente(n) 406 beinhalten können) kommunizieren.
  • Eine simulierte Umgebung 628 (welche z.B. zu der hierin beschriebenen simulierten Umgebung 410 ähnlich sein kann) kann durch miteinander verbundene Komponenten, einschließlich einer Simulations-Engine 630, einer KI-Engine 632, einer Global Illumination (GI)-Engine 634, eines oder mehrere Asset-Datenspeicher 636 und/oder anderer Komponenten, modelliert werden. In einigen Beispielen kann/können diese Komponente(n) verwendet werden, um eine simulierte Umgebung (z.B. eine virtuelle Welt) in einer virtualisierten interaktiven Plattform (z.B. ähnlich einer Massive Multiplayer Online (MMO)-Spielumgebung) zu modellieren. Die simulierte Umgebung kann ferner Physik, eine Verkehrssimulation, eine Wettersimulation und/oder andere Merkmale und Simulationen für die simulierte Umgebung beinhalten. Die GI-Engine 634 kann GI einmal berechnen und die Berechnung mit jedem der Knoten 618(1)-618(N) und 620(1)-620(N) teilen (z.B. kann die Berechnung von GI unabhängig von der Ansicht erfolgen). Die simulierte Umgebung 628 kann ein KI-Universum 622 beinhalten, das Daten für GPU-Plattformen 624 (z.B. GPU-Server) bereitstellt, die Renderungen für jeden Sensor des Fahrzeugs erzeugen können (z.B. an dem virtuellen Sensor/dem/den Codec(s) 618 für ein erstes virtuelles Objekt und an dem virtuellen Sensor Codec(s) 620 für ein zweites virtuelles Objekt). Die GPU-Plattform 624 kann z.B. Daten über die simulierte Umgebung 628 empfangen und kann Sensoreingaben für jeden von 618(1)-618(N), 620(1)-620(N) erzeugen, und/oder kann virtueller Sensor/Codec-Paare erzeugen, die anderen virtuellen Objekten entsprechen (abhängig von der Ausführungsform). In Beispielen, in denen die virtuellen Objekte unter Verwendung von HIL-Objekten simuliert werden, können die Sensoreingaben der Fahrzeug-Hardware 104 zur Verfügung gestellt werden, die den/die Softwarestack(s) 116 verwenden kann, um eine oder mehrere Operationen durchzuführen und/oder einen oder mehrere Befehle, wie die hierin beschriebenen, zu erzeugen. In einigen Beispielen, wie hierin beschrieben, können die virtuellen Sensordaten von jedem der virtuellen Sensoren unter Verwendung eines Codecs codiert werden, bevor sie von dem (den) Softwarestack(s) 116 verwendet (oder an diese(n) übertragen) werden. Darüber hinaus kann in einigen Beispielen jeder der Sensoren auf einem eigenen Grafikprozessor innerhalb der GPU-Plattform 624 ausgeführt werden, während in anderen Beispielen zwei oder mehr Sensoren dieselbe GPU innerhalb der GPU-Plattform 624 verwenden.
  • Die eine oder mehreren Operationen oder der eine oder mehreren Befehle können an die Simulations-Engine 630 übertragen werden, welche das Verhalten eines oder mehrerer der virtuellem Objekte auf der Grundlage der Operationen und/oder Befehle aktualisieren kann. Beispielsweise kann die Simulationsengine 630 die KI-Engine 632 verwenden, um das Verhalten der KI-Agenten sowie der virtuellen Objekte in der simulierten Umgebung 628 zu aktualisieren. Die Simulationsengine 630 kann dann die Objektdaten und Eigenschaften aktualisieren (z.B. innerhalb des/der Asset-Datenspeicher(s) 636), kann die GI (und/oder andere Aspekte wie Reflexionen, Schatten usw.) aktualisieren, und kann dann aktualisierte Sensoreingaben für die GPU-Plattform 624 erzeugen und bereitstellen. Dieser Prozess kann sich wiederholen, bis eine Simulation abgeschlossen ist.
  • Nun auf 7 Bezug nehmend, beinhaltet 7 ein Datenflussdiagramm, das einen Prozess 700 zur Re-Simulation oder Simulation unter Verwendung eines oder mehrerer Codecs darstellt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Der Prozess 700 kann einen aktuellen Zustand und/oder von der Simulation und/oder der Re-Simulation an einen oder mehrere Codecs 704 zu übertragende Sensordaten beinhalten. Zumindest einige der Daten (z.B. die Sensordaten) können dann unter Verwendung des/der Codec(s) 704 codiert und dem/den Softwarestack(s) 706 (z.B. ähnlich wie der/die Softwarestack(s) 116) für eine aktuelle Zeitscheibe zur Verfügung gestellt werden. Die Fahrbefehle und ein neuer Sensorzustand können dann (z.B. über CAN oder V-CAN) an den/die Codec(s) 704 und zurück zu der Simulation und/oder der Re-Simulation übertragen werden. Die Fahrbefehle, die ursprünglich von dem/den Softwarestack(s) 706 (z.B. von einem Software-Stack für autonomes Fahren) erzeugt wurden, können dann an die Eigenobjekt-Dynamik weitergegeben werden, welche eine benutzerdefinierte oder eingebaute Dynamik verwenden kann, um den Objektzustand für den bestimmten Typ des simulierten virtuellen Objekts zu aktualisieren, und der aktualisierte Objektzustand kann an die Simulation und/oder die Re-Simulation zurückgegeben werden. Das Simulationssystem kann den Objektzustand, Befehle und/oder Informationen des Objekts zusätzlich zur Verwendung einer Verkehrs-KI, Fußgänger-KI und/oder anderer Funktionen der Simulationsplattform verwenden, um die simulierte Umgebung zu erzeugen oder zu aktualisieren (z.B. auf einen aktuellen Stand). Der aktuelle Stand kann an das KPI-Rahmenwerk übergeben werden (z.B. gleichzeitig mit der Übergabe der Fahrbefehle an die Eigenobjekt-Dynamik 708, in einigen Ausführungsformen), und das KPI-Rahmenwerk 710 kann die aktuelle Simulation und/oder die Re-Simulation überwachen und auswerten. In einigen Beispielen kann/können der/die Codec(s) 704 Simulationsdaten puffern, um die Leistung zu erhöhen und/oder die Latenz des Systems zu verringern.
  • Nun auf 8 Bezug nehmend, beinhaltet 8 ein Datenflussdiagramm zur Analyse und Beobachtung wichtiger Leistungsindikatoren (KPI), in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Eine KPI-Evaluierungskomponente kann die Leistung des/der virtuellen Objekte(s) (z.B. Fahrzeuge, Roboter usw.) auswerten. Protokolle 806 können generiert und an den Re-Simulator/Simulator 804 übergeben werden. Der Re-Simulator/Simulator 804 kann Sensordaten für den/die Software-Stack(s) 116 bereitstellen, die unter Verwendung von HIL, SIL oder einer Kombination davon ausgeführt werden können. Die KPI-Evaluierungskomponente 802 kann für jede Simulations- oder Re-Simulations-Instanz unterschiedliche Metriken verwenden. Beispielsweise kann die KPI-Evaluierungskomponente für die Re-Simulation einen Zugriff auf die ursprünglichen, wieder abgespielten CAN-Daten und/oder die neu generierten CAN-Daten von dem/den Software-Stack(s) 116 (z.B. aus HIL oder SIL) bereitstellen. In einigen Beispielen könnte das Leistungsvermögen so einfach sein wie ein Überprüfen, dass die neuen CAN-Daten keine falsch positiven Ergebnisse erzeugen - wie beispielsweise durch Auslösen einer automatischen Notbremsung (AEB) oder einer anderen ADAS-Funktionalität. Beispielsweise kann die KPI-Evaluierungskomponente 802 bestimmen, ob die neuen CAN-Daten eine Warnung vor dem toten Winkel oder eine Spurverlassenswarnung auslösen. Infolgedessen kann das System dazu beitragen, Fehlalarme zu reduzieren, die herkömmliche ADAS-Systeme plagen. Die KPI-Evaluierungskomponente 802 kann auch bestimmen, ob die neuen CAN-Daten keine Warnung auslösen, die hätte implementiert werden müssen.
  • In einigen Beispielen kann die KPI-Evaluierungskomponente 802 auch komplexere Vergleiche ermöglichen. Beispielsweise kann die KPI-Evaluierungskomponente 802 so komplex sein wie die Durchführung von Analysen auf den beiden unterschiedlichen CAN-Streams, um Abweichungen zu finden. Die KPI-Evaluierungskomponente 802 kann die neuen CAN-Daten mit den ursprünglichen CAN-Daten vergleichen, und kann beide Trajektorien evaluieren, um zu bestimmen, welche Trajektorie die Sicherheitsziele des Systems am besten erfüllen würde. In einigen Beispielen kann die KPI-Evaluierungskomponente 802 eine oder mehrere Verfahren verwenden, die in der provisorischen US-Patentanmeldung Nr. 62/625,351 oder der nicht-provisorischen US-Patentanmeldung Nr. 16/256,780 beschrieben sind, die hiermit jeweils durch Bezugnahme in ihrer Gesamtheit einbezogen werden. In anderen Beispielen kann die KPI-Evaluierungskomponente 802 eines oder mehrere der Verfahren verwenden, die in der provisorischen US-Patentanmeldung Nr. 62/628,831 oder der nicht-provisorischen US-Patentanmeldung Nr. 16/269,921 beschrieben sind, die hiermit jeweils durch Bezugnahme in ihrer Gesamtheit einbezogen werden. Beispielsweise können Sicherheitsprozeduren auf der Grundlage von Berechnungen einer sicheren Ankunftszeit bestimmt werden.
  • In einigen Beispielen kann die KPI-Evaluierungskomponente 802 auch das Verfahren verwenden, das in der provisorischen US-Anmeldung Nr. 62/622,538 oder der nicht provisorischen US-Patentanmeldung Nr. 16/258,272 beschrieben ist, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen werden, und welches verwendet werden kann, um gefährliches Fahren unter Verwendung maschinellen Lernens zu erfassen. Beispielsweise können maschinelles Lernen und tiefe neuronale Netze (DNNs) für Redundanz und zur Pfadprüfung, verwendet werden, beispielsweise für einen Rationalitätsprüfer als Teil funktioneller Sicherheit für autonomes Fahren. Diese Techniken können zur Verwendung mit der KPI-Evaluierungskomponente 802 erweitert werden, um die Leistung des Systems zu bewerten.
  • Die KPI-Evaluierungskomponente kann auch zusätzliche Ansätze zur Bewertung der Leistung des Systems verwenden. Zum Beispiel kann die KPI-Evaluierungskomponente 802 berücksichtigen, ob die Zeit bis zur Ankunft (time to arrival; TTA) in dem Pfad des Querverkehrs kleiner ist als eine Schwellenwertzeit - z.B. zwei Sekunden. Der Schwellenwert kann in Abhängigkeit von der Geschwindigkeit des Fahrzeugs, den Straßenbedingungen, dem Wetter, dem Verkehr und/oder anderen Variablen variieren. Zum Beispiel kann die Schwellendauer zwei Sekunden für Geschwindigkeiten bis zu zwanzig Mph und eine Sekunde für jede höhere Geschwindigkeit betragen. Alternativ kann die Schwellendauer reduziert oder begrenzt werden, wann immer das System gefährliche Straßenbedingungen wie beispielsweise nasse Straßen, Eis oder Schnee erkennt. In einigen Beispielen können gefährliche Straßenzustände durch ein DNN erfasst werden, das darauf trainiert ist, solche Zustände bzw. Bedingungen zu erkennen.
  • In Bezug auf die Simulation kann die KPI-Evaluierungskomponente eine API beinhalten, wie hierin beschrieben. Die KPI-Evaluierungskomponente 802 kann zusätzliche Eingaben beinhalten und/oder mehr Funktionalität bereitstellen. Beispielsweise kann der Simulator in der Lage sein, die „Ground Truth“ für die Szene zu teilen, und kann in der Lage sein, die Fähigkeit des virtuellen Objekts hinsichtlich der Vermeidung von Kollisionen, des In-der-Spur-Bleibens und/oder anderer Verhaltensweisen bestimmen. Zum Beispiel kann die KPI-Evaluierungskomponente 802 mehr als nur ein passiver Zeuge des Experiments sein und kann eine API beinhalten, um den Zustand jeder laufenden Simulation zu speichern, den Zustand zu ändern oder Verhaltensweisen auszulösen und mit diesen Änderungen fortzufahren. Dadurch kann die KPI-Evaluierungskomponente nicht nur die Fahrzeugleistung bewerten, sondern auch versuchen, den Raum potenziell gefährlicher Szenarien zu erkunden.
  • Nun auf 9 und 10 Bezug nehmend, umfasst jeder Block von hierin beschriebenen Verfahren 900 und 1000 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Anweisungen ausführt. Die Verfahren können auch als computerverwendbare, auf einem Computer-Speichermedium gespeicherte Befehle ausgebildet sein. Die Verfahren können auch durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst), oder durch ein Plug-in für ein anderes Produkt bereitgestellt sein, um nur einige zu nennen. Darüber hinaus werden die Verfahren 900 und 1000 beispielhaft im Hinblick auf das Re-Simulationssystem 100 von 1, das Simulationssystem 400 von 4A-4C und das Simulationssystem 600 von 6A-6B beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich der, aber nicht beschränkt auf die hierin beschriebenen.
  • 9 ist ein Ablaufdiagramm, das ein Verfahren 900 zum Steuern eines virtuellen Objekts in einer simulierten Umgebung zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 900 beinhaltet in einem Block B902 ein Empfangen von Simulationsdaten, die repräsentativ für eine simulierte Umgebung sind, von einer Simulations-Hostvorrichtung. Beispielsweise können die Fahrzeugsimulatorkomponente(n) 406, 420 und/oder 422 von der/den Simulatorkomponente(n) 402 Simulationsdaten empfangen, die repräsentativ für die simulierte Umgebung 410 sind. In einigen Beispielen können die empfangenen Simulationsdaten die Simulationsdaten sein, die den Sensoren des virtuellen Objekts entsprechen, das von der (den) Fahrzeugsimulatorkomponente(n) gehostet wird.
  • Das Verfahren 900 beinhaltet in einem Block B904 ein Erzeugen von virtuellen Sensordaten für jeden einer dynamisch konfigurierbaren Anzahl von virtuellen Sensoren. Zum Beispiel kann (können) die Fahrzeugsimulatorkomponente(n) 406, 420 und/oder 422 virtuelle Sensordaten unter Verwendung der Simulationsdaten für jeden der virtuellen Sensoren des Fahrzeugs erzeugen. Die virtuellen Sensordaten können repräsentativ für die simulierte Umgebung 410 sein, wie sie von zumindest einem virtuellen Sensor einer dynamisch konfigurierbaren Anzahl von virtuellen Sensoren eines virtuellen Objekts innerhalb der simulierten Umgebung 410 wahrgenommen wird (z.B. Sensordaten eines Sichtfelds einer oder mehrerer virtuellen Kamera(s), Sensordaten einer Orientierung des virtuellen Fahrzeugs unter Verwendung virtueller IMU-Sensoren usw.). Die Anzahl der verwendeten virtuellen Sensoren kann derart dynamisch konfigurierbar sein, dass ein Sensor in einer ersten Simulation, fünf in einer anderen, zehn in einer anderen usw. verwendet werden kann/können. In einigen Beispielen kann die dynamische Konfiguration auf der Grundlage von Fahrzeugtypen bestimmt werden (z.B. kann ein erstes Fahrzeug des Jahres X, der Marke Y, des Modells Z 20 Sensoren beinhalten, während ein zweites Fahrzeug des Jahres A, der Marke B, des Modells C 30 Sensoren beinhalten kann). In solchen Beispielen kann das Simulationssystem 400, 600 dynamisch konfigurierbar sein, um virtuelle Sensordaten für jeden der virtuellen Sensoren jedes oder eines beliebigen Fahrzeugs in der simulierten Umgebung zu erzeugen. Darüber hinaus kann eine beliebige Anzahl verschiedener virtueller Objekte innerhalb der simulierten Umgebung zu einem beliebigen Zeitpunkt simuliert werden. So können für jedes eines ersten virtuellen Objekts (z.B. ausführend auf einem ersten Satz von Fahrzeugsimulatorkomponente(n) 406), eines zweiten virtuellen Objekts (z.B. ausführend auf einem zweiten Satz von Fahrzeugsimulatorkomponente(n) 420) und/oder beliebiger anderer virtueller Objekte eine gleiche oder eine unterschiedliche Anzahl von virtuellen Sensoren und/oder Typen virtueller Sensoren virtuelle Sensordaten erzeugen. Die virtuellen Sensordaten für jeden virtuellen Sensor können repräsentativ für beliebige andere virtuelle Objekte sein, wie sie von dem jeweiligen virtuellen Sensor wahrgenommen werden. So kann das Simulationssystem 400, 600 (z.B. unter Verwendung des DSM 424) für jeden der virtuellen Sensoren virtuelle Sensordaten erzeugen, die den Simulationszustand der simulierten Umgebung in Bezug auf jedes andere virtuelle Objekt widerspiegeln. Auf diese Weise ist das Simulationssystem auf eine beliebige Anzahl von virtuellen Objekten skalierbar und konfigurierbar, die jeweils über eine beliebige Anzahl von virtuellen Sensoren verfügen, die jeweils in Echtzeit verarbeitet werden können.
  • Das Verfahren 900 beinhaltet in einem Block B906 ein Codieren der virtuellen Sensordaten. Beispielsweise können die virtuellen Sensordaten unter Verwendung eines oder mehrerer Codecs (z.B. Codec(s) 614) codiert werden, um codierte Sensordaten zu erzeugen. In einigen Beispielen können die virtuellen Sensordaten in ein Format codiert werden, das dem/den Softwarestack(s) 116 des virtuellen Objekts vertraut ist.
  • Das Verfahren 900 beinhaltet in einem Block B908 ein Berechnen von zumindest einer Ausgabe durch ein oder mehrere Modelle maschinellen Lernens. Beispielsweise können eine oder mehrere DNNs des/der Software-Stack(s) 116 die codierten Sensordaten dazu verwenden, einen oder mehrere Ausgaben (z.B. Objekterfassungen, Steuerungen, Betätigungen, Pfadpläne, Führung usw.) zu erzeugen. In einigen Beispielen, wie hierin beschrieben, kann/können der/die Softwarestack(s) 116 auf der Fahrzeug-Hardware 104 ausgeführt werden (z.B. für HIL-Objekte), so dass die in dem physischen Fahrzeug (z.B. physischen Fahrzeug) verwendete Software und Hardware in dem Simulationssystem 400 und 600 verwendet werden kann, um genauere Ergebnisse zu erzielen, die mit dem Einsatz in der realen Welt übereinstimmen.
  • Das Verfahren 900 in einem Block B910 ein Übertragen eines Signals an die Simulations-Hostvorrichtung. Beispielsweise kann die Ausgabe (oder dafür repräsentative Daten) in einem Signal an die Simulationskomponente(n) 402 übertragen werden, um die globale Simulation und damit die Simulationsumgebung zu aktualisieren.
  • 10 ist ein Ablaufdiagramm, das ein Verfahren 1000 zum Steuern eines virtuellen Objekts in einer simulierten Umgebung unter Verwendung von Modellen maschinellen Lernens, die an physischen Sensordaten trainiert wurden, zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 1000 beinhaltet in einem Block B1002 ein Empfangen von Daten physischer Sensoren, die von einem physischen Sensor erzeugt wurden. Zum Beispiel kann/können das/die Fahrzeug(e) 102 (z.B. ein oder mehrere physische oder physische Fahrzeug(e)) physische Sensordaten bzw. Daten physischer Sensoren erzeugen, und kann das Re-Simulations- und/oder Simulationssystem die physischen Sensordaten empfangen.
  • Das Verfahren 1000 beinhaltet in einem Block B1004 ein Trainieren eines Modells maschinellen Lernens unter Verwendung der Daten physischer Sensoren. Beispielsweise können ein oder mehrere DNNs, die in dem/den Software-Stack(s) 116 verwendet werden können, anhand der physischen Sensordaten trainiert werden. Einmal trainiert, können die DNNs als trainierte DNNs betrachtet werden.
  • Das Verfahren 1000 beinhaltet in einem Block B1006 ein Empfangen von virtuellen Sensordaten, die von einem virtuellen Sensor erzeugt wurden. Zum Beispiel kann (können) die Fahrzeugsimulatorkomponente(n) 406, 420 und/oder 422 virtuelle Sensordaten unter Verwendung eines oder mehrerer virtueller Sensoren und/oder eines oder mehrerer Codecs erzeugen.
  • Das Verfahren 1000 beinhaltet in einem Block B1008 ein Anwenden der virtuellen Sensordaten auf ein trainiertes Modell maschinellen Lernens. Beispielsweise können die virtuellen Sensordaten - welche in demselben Format wie die physischen Sensordaten vorliegen können, die zum Trainieren des Modells maschinellen Lernens verwendet wurden - auf das trainierte Modell maschinellen Lernens angewendet werden.
  • Das Verfahren 1000 beinhaltet in einem Block B1010 ein Berechnen einer Ausgabe durch das trainierte Modell maschinellen Lernens. Beispielsweise kann das trainierte DNN eine oder mehrere Ausgaben unter Verwendung der virtuellen Sensordaten berechnen. Wie hier beschrieben wurde, können die virtuellen Sensordaten vor der Verwendung durch das trainierte DNN codiert werden.
  • Das Verfahren 1000 beinhaltet in einem Block B1020 ein Steuern eines virtuellen Objekts innerhalb einer simulierten Umgebung, basierend zumindest teilweise auf der Ausgabe. Zum Beispiel kann das virtuelle Objekt (z.B. ein virtuelles Fahrzeug) innerhalb der simulierten Umgebung zumindest teilweise auf der Grundlage der Ausgabe gesteuert werden. In anderen Beispielen können die Ausgaben zur Steuerung verwendet werden. Die Ausgaben können z.B. eine Objekterfassung, eine Fahrspurerfassung, eine Erfassung frei befahrbaren Raums, eine Bestimmung des Sicherheitsverfahrens usw. sein. In jedem beliebigen Beispiel können die Ergebnisse unter Verwendung einer oder mehrerer KPIs getestet werden, um die Genauigkeit und Wirksamkeit der trainierten DNNs in einer Reihe von Szenarien und Umgebungen zu bestimmen. Wenn die trainierten DNNs darunter leiden, kann eine Feinabstimmung durchgeführt werden, um die DNNs vor dem Einsatz der DNNs in realen, physischen Fahrzeugen (z.B. dem Fahrzeug 102) zu verbessern, zu validieren und zu verifizieren.
  • Beispielhaftes autonomes Fahrzeug
  • 11A ist eine Darstellung eines beispielhaften autonomen Fahrzeugs 102, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das autonome Fahrzeug 102 (hierin alternativ als das „Fahrzeug 102“ bezeichnet) kann ein Personenfahrzeug, wie z.B. ein Auto, ein Lastkraftwagen, ein Bus und/oder eine andere Art von Fahrzeug, das einen oder mehrere Passagiere aufnimmt, beinhalten. Autonome Fahrzeuge werden allgemein im Hinblick auf Automatisierungsgrade beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Norm Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Norm Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieser Norm) definiert werden. Das Fahrzeug 102 kann zu Funktionalität in Übereinstimmung mit einem oder mehreren der Level 3 - Level 5 der autonomen Fahrstufen in der Lage sein. Beispielsweise kann das Fahrzeug 102 je nach Ausführungsform zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.
  • Das Fahrzeug 102 kann Komponenten wie ein Fahrgestell, einen Fahrzeugaufbau, Räder (z.B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs beinhalten. Das Fahrzeug 102 kann ein Antriebssystem 1150 beinhalten, wie z.B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftwerk, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 1150 kann mit einem Antriebsstrang des Fahrzeugs 102 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 102 zu ermöglichen. Das Antriebssystem 1150 kann im Ansprechen auf einen Empfang von Signalen von der Drosselklappe/dem Beschleuniger 1152 gesteuert werden.
  • Ein Lenksystem 1154, das ein Lenkrad beinhalten kann, kann dazu verwendet werden, das Fahrzeug 102 zu lenken (z.B. entlang eines gewünschten Weges oder einer gewünschten Route), wenn das Antriebssystem 1150 in Betrieb ist (z.B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1154 kann Signale von einem Lenkaktuator bzw. -stellglied 1156 empfangen. Das Lenkrad kann für vollständige Automatisierung (Level 5) optional sein.
  • Das Bremssensorsystem 1146 kann dazu verwendet werden, die Fahrzeugbremsen im Ansprechen auf einen Empfang von Signalen von den Bremsaktuatoren bzw. -stellgliedern 1148 und/oder Bremssensoren zu betätigen.
  • Eine oder mehrere Steuereinrichtung(en) 1136, die ein oder mehrere System(e) auf Chips (SoCs) 1104 (11C) und/oder GPU(s) beinhalten kann/können, kann/können Signale (z.B. repräsentativ für Befehle) an ein(e) oder mehrere Komponenten und/oder Systeme des Fahrzeugs 102 liefern. Zum Beispiel kann/können die Steuereinrichtung(en) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 1148, zur Betätigung des Lenksystems 1154 über einen oder mehrere Lenkaktuatoren 1156, zur Betätigung des Antriebssystems 1150 über einen oder mehrere Drosselklappen/Beschleuniger 1152 senden. Die Steuereinrichtung(en) 1136 kann/können ein oder mehrere bordeigene (z.B. integrierte) Rechenvorrichtungen (z.B. Supercomputer) beinhalten, die Sensorsignale verarbeiten und Betriebsbefehle (z.B. Signale, die Anweisungen repräsentieren) ausgeben, um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen des Fahrzeugs 102 zu unterstützen. Die Steuereinrichtung(en) 1136 kann/können eine erste Steuereinrichtung 1136 für autonome Fahrfunktionen, eine zweite Steuereinrichtung 1136 für funktionale Sicherheitsfunktionen, eine dritte Steuereinrichtung 1136 für Funktionen der künstlichen Intelligenz (z.B. Computer Vision), eine vierte Steuereinrichtung 1136 für Infotainmentfunktionen, eine fünfte Steuereinrichtung 1136 für Redundanz in Notfällen und/oder andere Steuereinrichtungen umfassen. In einigen Beispielen kann eine einzelne Steuereinrichtung 1136 zwei oder mehr der vorstehend genannten Funktionalitäten handhaben, können zwei oder mehr Steuereinrichtungen 1136 eine einzelne Funktionalität handhaben, und/oder eine beliebige Kombination davon.
  • Die Steuereinrichtung(en) 1136 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 102 im Ansprechen auf von einem oder mehreren Sensoren empfangene Sensordaten (z.B. Sensor-Inputs) bereitstellen. Die Sensordaten können z.B. und ohne Beschränkung darauf von einem oder mehreren Sensoren für globale Satellitennavigationssysteme 1158 (z.B. von einem oder mehreren Global Positioning System-Sensor(en), RADAR-Sensor(en) 1160, Ultraschall-Sensor(en) 1162, LIDAR-Sensor(en) 1164, Trägheitsmesseinheits- bzw. Inertial Measurement Unit (IMU)-Sensor(en) 1166 (z.B. Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 1196, Stereokamera(s) 1168, Weitwinkelkamera(s) 1170 (z.B. Fisheye-Kameras), Infrarotkamera(s) 1172, Surround-Kamera(s) 1174 (z.B. 360-Grad-Kameras), Fern-und/oder Mittelbereichskamera(s) 1198, Geschwindigkeitssensor(en) 1144 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 102), Vibrationssensor(en) 1142, Lenksensor(en) 1140, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1146) und/oder anderen Sensortypen empfangen werden.
  • Ein oder mehrere der Steuereinrichtung(en) 1136 kann/können Eingaben (z.B. dargestellt durch Eingangsdaten) von einem Kombiinstrument 1132 des Fahrzeugs 102 empfangen und Ausgaben (z.B. dargestellt durch Ausgangsdaten, Anzeigedaten usw.) über eine Anzeige 1134 einer Mensch-Maschine-Schnittstelle (HMI), einen akustischen Signalgeber, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 102 bereitstellen. Die Ausgaben können Informationen wie beispielsweise Fahrzeuggeschwindigkeit, Geschwindigkeit, Zeit, Kartendaten (z.B. die HD-Karte 1122 von 11C), Standortdaten (z.B. die Position des Fahrzeugs 102, wie beispielsweise auf einer Karte), Richtung, Position anderer Fahrzeuge (z.B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von der/den Steuereinrichtung(en) 1136 wahrgenommen, usw. beinhalten. Beispielsweise kann die HMI-Anzeige 1134 Informationen über das Vorhandensein eines oder mehrerer Objekte (z.B. ein Straßenschild, ein Warnschild, einen Ampelwechsel usw.) und/oder Informationen über Fahrmanöver, die das Fahrzeug durchgeführt hat, durchführt oder durchführen wird (z.B. Spurwechsel jetzt, Ausfahrt 34B in zwei Meilen, usw.) anzeigen.
  • Das Fahrzeug 102 beinhaltet ferner eine Netzwerkschnittstelle 1124, welche eine oder mehrere drahtlose Antenne(n) 1126 und/oder ein oder mehrere Modem(s) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 1124 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 1126 kann/können unter Verwendung von lokalen Netzwerken, wie beispielsweise Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw., und/oder Breitbandnetzwerken mit geringer Leistung (LPWANs), wie beispielsweise LoRaWAN, SigFox usw., auch die Kommunikation zwischen Objekten in der Umgebung (z.B. Fahrzeugen, mobilen Geräten usw.) ermöglichen.
  • 11B ist ein Beispiel für Kamerastandorte und Sichtfelder für das beispielhafte autonome Fahrzeug 102 von 11A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Die Kameras und die entsprechenden Sichtfelder sind eine beispielhafte Ausführungsform und sollen nicht beschränkend sein. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder können sich die Kameras an verschiedenen Orten auf dem Fahrzeug 102 befinden.
  • Die Kameratypen für die Kameras können, ohne darauf beschränkt zu sein, Digitalkameras beinhalten, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 102 angepasst sein können. Die Kamera(s) können auf einer Fahrzeugsicherheitsintegritätsstufe (Automotive Safety Integrity Level, ASIL) B und/oder einer anderen ASIL-Stufe betrieben werden. Die Kameratypen können je nach Ausführungsform zu jeder beliebigen Bildaufnahmerate in der Lage sein, z.B. zu 60 Bildern pro Sekunde (frames per second, fps), 1120 fps, 240 fps usw. Die Kameras können zur Verwendung von Rolling Shutters, Global Shutters, eines anderen Typs von Verschluss oder eine Kombination derselben in der Lage sein. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar (RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau (RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar (RBGC)-Farbfilteranordnung, eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensoren (RGGB)-Farbfilteranordnung, eine Monochrom-Sensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können Kameras mit klaren Pixeln, wie z.B. Kameras mit einer RCCC-, einer RCCB-und/oder einer RBGC-Farbfilteranordnung, dazu verwendet werden, die Lichtempfindlichkeit zu erhöhen.
  • In einigen Beispielen können eine oder mehrere der Kamera(s) dazu verwendet werden, fortgeschrittene Fahrerassistenzsystem (Advanced Driver Assistance Functions, ADAS)-Funktionen durchzuführen (z.B. als Teil eines redundanten oder ausfallsicheren Designs). Beispielsweise kann eine Multifunktions-Monokamera installiert sein, um Funktionen einschließlich Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kamera(s) (z.B. alle Kameras) können gleichzeitig Bilddaten (z.B. Video) aufzeichnen und bereitstellen.
  • Eine oder mehrere der Kameras können in einer Montagebaugruppe, wie beispielsweise einer kundenspezifisch gestalteten (3-D-gedruckten) Baugruppe, montiert sein, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z.B. Reflexionen von dem Armaturenbrett, die in den Windschutzscheibenspiegeln reflektiert werden), die die Bilddatenerfassungsfähigkeiten der Kamera stören könnten, auszuschließen. In Bezug auf Klappspiegelbefestigungsbaugruppen können die Klappspiegelbaugruppen kundenspezifisch 3-D-gedruckt sein, so dass die Kameramontageplatte mit der Form des Klappspiegels übereinstimmt. In einigen Beispielen kann/können die Kamera(s) in den Klappspiegel integriert sein. Bei Seitensichtkameras können die Kamera(s) auch in die vier Säulen an jeder Ecke der Kabine integriert sein.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 102 einschließt (z.B. nach vorne gerichtete Kameras), können für Surround- bzw. Rundumsicht verwendet werden, um nach vorne gerichtete Wege und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Steuergeräte 1136 und/oder Steuerungs-SoCs bei der Bereitstellung von Informationen, die für die Erzeugung eines Belegungsrasters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind, unterstützen. Nach vorne gerichtete Kameras können dazu verwendet werden, viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnsysteme (Lane Departure Warning, „LDW“), Autonome Geschwindigkeitsregelung (Autonomous Cruise Control, „ACC“) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
  • Eine Vielzahl von Kameras kann in einer nach vorne Konfiguration verwendet werden, einschließlich z.B. einer monokularen Kameraplattform, die einen CMOS (komplementärer Metalloxid-Halbleiter)-Farbbildsensor enthält. Ein weiteres Beispiel kann eine oder mehrere Weitwinkelkamera(s) 1170 sein, die zur Wahrnehmung von Objekten verwendet werden kann/können, die von der Peripherie aus in Sicht kommen (z.B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl nur eine Weitwinkelkamera in 11B dargestellt ist, können beliebig viele Weitwinkelkameras 1170 an dem Fahrzeug 102 vorhanden sein. Darüber hinaus kann/können eine oder mehrere Fernbereichkamera(s) 1198 (z.B. ein Fernbereich-Stereokamerapaar) zur tiefenbasierten Objekterfassung verwendet werden, insbesondere für Objekte, für die ein neuronales Netzwerk noch nicht trainiert worden ist. Die Fernbereichkamera(s) 1198 kann/können auch zur Objekterfassung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
  • Auch eine oder mehrere Stereokameras 1168 können in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 1168 kann/können eine integrierte Steuereinheit mit einer skalierbaren Verarbeitungseinheit beinhalten, die eine programmierbare Logik (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzelnen Chip bereitstellen kann. Eine solche Einheit kann dazu verwendet werden, eine 3D-Karte der Fahrzeugumgebung zu erzeugen, einschließlich einer Entfernungsschätzung für alle Punkte im Bild. Eine oder mehrere alternative Stereokamera(s) 1168 kann/können einen oder mehrere kompakte(n) Stereovision-Sensor(en) beinhalten, der/die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfassen kann/können, der die Entfernung von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z.B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurverlassenswarnfunktionen verwenden kann. Andere Arten von Stereokamera(s) 1168 können zusätzlich zu oder alternativ zu den hierin beschriebenen verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 102 einschließt (z.B. Seitensichtkameras), können zur Rundumsicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Warnungen vor Seitenaufprall-Kollisionen verwendet werden. Zum Beispiel kann/können eine oder mehrere Surround-Kamera(s) 1174 (z.B. vier Surround-Kameras 1174 wie in 11B dargestellt) auf dem Fahrzeug 102 positioniert sein. Die Surround-Kamera(s) 1174 kann/können Weitwinkelkamera(s) 1170, Fischaugen-Kamera(s), 360-Grad-Kamera(s) und/oder dergleichen beinhalten. Zum Beispiel können vier Fischaugen-Kameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs positioniert sein. In einer alternativen Anordnung kann das Fahrzeug drei Surround-Kamera(s) 1174 (z.B. links, rechts und hinten) verwenden, und kann eine oder mehrere andere Kamera(s) (z.B. eine nach vorn gerichtete Kamera) als eine vierte Rundumsicht-Kamera einsetzen.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 102 einschließt (z.B. Rückfahrkameras), können zur Einparkhilfe, Rundumsicht, Warnungen vor Heckaufprall und Erstellung und Aktualisierung des Belegungsrasters verwendet werden. Es kann eine breite Vielfalt von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorn gerichtete Kamera(s) (z.B. die Fern- und/oder Mittelbereichskamera(s) 1198, die Stereokamera(s) 1168, die Infrarotkamera(s) 1172 usw.) geeignet sind, wie hierin beschrieben.
  • 11C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 102 von 11A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele dargestellt sind. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anweisungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Entitäten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Lage implementiert werden können. Verschiedene hierin beschriebene Funktionen, die von Entitäten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Anweisungen ausführt.
  • Jede(s) der Komponenten, Merkmale und Systeme des Fahrzeugs 102 in 11C sind als über einen Bus 1102 verbunden dargestellt. Der Bus 1102 kann eine Datenschnittstelle für ein Controller Area Network (CAN) (hierin alternativ als „CAN-Bus“ bezeichnet) beinhalten. Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 102 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 102, wie z.B. Bremsbetätigung, Beschleunigung, Bremsen, Lenkung, Scheibenwischer usw., verwendet wird Ein CAN-Bus kann dazu konfiguriert sein, Dutzende oder sogar Hunderte von Knoten zu haben, von denen jeder seinen eigenen eindeutigen Identifikator (z.B. eine CAN-ID) hat. Der CAN-Bus kann ausgelesen werden, um einen Lenkradwinkel, eine Fahrgeschwindigkeit, eine Motordrehzahl (RPMs bzw. 1/min), Schalterstellungen und/oder andere Fahrzeugstatusanzeigen festzustellen. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 1102 hierin als ein CAN-Bus beschrieben wird, soll dies nicht beschränkend sein. Zum Beispiel können zusätzlich zu dem oder alternativ zu dem CAN-Bus FlexRay und/oder Ethernet verwendet werden. Auch wenn eine einzelne Leitung zur Darstellung des Busses 1102 verwendet wird, soll dies nicht beschränkend sein. Beispielsweise kann eine beliebige Anzahl von Bussen 1102 vorhanden sein, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen, die ein anderes Protokoll verwenden, beinhalten können. In einigen Beispielen können zwei oder mehr Busse 1102 zur Ausführung verschiedener Funktionen und/oder zur Redundanz verwendet werden. Beispielsweise kann ein erster Bus 1102 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 1102 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1102 mit jeder der Komponenten des Fahrzeugs 102 kommunizieren, und können zwei oder mehr Busse 1102 mit den gleichen Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 1104, jede Steuereinrichtung 1136 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf die gleichen Eingangsdaten (z.B. Inputs von Sensoren des Fahrzeugs 102) haben und mit einem gemeinsamen Bus, z.B. dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 102 kann ein oder mehrere Steuereinrichtung(en) 1136 beinhalten, wie die hier in Bezug auf 11A beschriebenen. Die Steuereinrichtung(en) 1136 kann/können für eine Vielzahl von Funktionen verwendet werden. Die Steuereinrichtung(en) 1136 kann/können mit den verschiedenen anderen Komponenten und Systemen des Fahrzeugs 102 gekoppelt sein und kann/können zur Steuerung des Fahrzeugs 102, der künstlichen Intelligenz des Fahrzeugs 102, des Infotainments für das Fahrzeug 102 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 102 kann ein oder mehrere System(e) auf einem Chip (SoC) 1104 beinhalten. Das SoC 1104 kann CPU(s) 1106, GPU(s) 1108, Prozessor(en) 1110, Cache(s) 1112, Beschleuniger 1114, Datenspeicher 1116 und/oder andere nicht dargestellte Komponenten und Merkmale beinhalten. Das/die SoC(s) 1104 kann/können zur Steuerung des Fahrzeugs 102 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise können das/die SoC(s) 1104 in einem System (z.B. dem System des Fahrzeugs 102) mit einer HD-Karte 1122 kombiniert werden, die über eine Netzwerkschnittstelle 1124 von einem oder mehreren Servern (z.B. dem/den Server(n) 1178 von 11 D) Kartenauffrischungen und/oder Aktualisierungen erhalten kann.
  • Die CPU(s) 1106 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 1106 kann/können mehrere Kerne und/oder L2-Caches beinhalten. Beispielsweise kann/können die CPU(s) 1106 in einigen Ausführungsformen acht Kerne in einer kohärenten Multiprozessor-Konfiguration beinhalten. In einigen Ausführungsformen kann/können die CPU(s) 1106 vier Dual-Core-Cluster beinhalten, wobei jeder Cluster über einen eigenen L2-Cache verfügt (z.B. einen 2 MB großen L2-Cache). Die CPU(s) 1106 (z.B. CCPLEX) kann/können dazu konfiguriert sein, gleichzeitigen Clusterbetrieb zu unterstützen, so dass jede beliebige Kombination der Cluster der CPU(s) 1106 zu jedem beliebigen Zeitpunkt aktiv sein kann.
  • Die CPU(s) 1106 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardware-Blöcke können im Leerlauf automatisch taktgesteuert werden, um dynamische Energie zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund einer Ausführung von WFI/WFE-Anweisungen Anweisungen nicht aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert werden; jeder Kerncluster kann unabhängig taktgesteuert werden, wenn alle Kerne taktgesteuert oder leistungsgesteuert werden; und/oder jeder Kerncluster kann unabhängig leistungsgesteuert werden, wenn alle Kerne leistungsgesteuert werden. Die CPU(s) 1106 kann/können darüber hinaus einen erweiterten Algorithmus für die Verwaltung von Leistungszuständen implementieren, wobei zulässige Leistungszustände und erwartete Aufwachzeiten spezifiziert sind und die Hardware/der Mikrocode den besten Leistungszustand ermittelt, in den der Kern, der Cluster und der CCPLEX eintreten soll. Die Verarbeitungskerne können vereinfachte Leistungszustand-Eintrittssequenzen in Software unterstützen, wobei die Arbeit auf Mikrocode verlagert wird.
  • Die GPU(s) 1108 kann/können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 1108 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 1108 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 1108 kann/können einen oder mehrere Streaming-Mikroprozessoren beinhalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z.B. einen L1-Cache mit zumindest 96 KB Speicherkapazität) beinhalten kann und zwei oder mehr der Streaming-Mikroprozessoren sich einen L2-Cache (z.B. einen L2-Cache mit 512 KB Speicherkapazität) teilen können. In einigen Ausführungsformen können die GPU(s) 1108 zumindest acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 1108 kann/können Compute Application Programming Interface(s) (API(s)) verwenden. Darüber hinaus kann/können die GPU(s) 1108 eine oder mehrere parallele Rechnerplattformen und/oder Programmiermodelle (z.B. CUDA von NVIDIA) verwenden.
  • Die GPU(s) 1108 kann/können für beste Leistung in Automobil- und Embedded-Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1108 kann/können beispielsweise auf einem Fin-Feldeffekttransistor (FinFET) hergestellt sein. Dies soll jedoch nicht beschränkend sein, so dass die GPU(s) 1108 unter Verwendung anderer Halbleiterherstellungsverfahren hergestellt sein kann/können. Jeder Streaming-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit beinhalten, die in mehrere Blöcke unterteilt sind. Zum Beispiel und ohne Beschränkung darauf können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei gemischtgenaue NVIDIA TENSOR-COREs für Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler, eine Sendeeinheit und/oder eine 64 KB-Registerdatei zugewiesen sein. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Fließkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Rechen- und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können unabhängige Thread-Scheduling-Fähigkeiten beinhalten, um eine feinkörnigere Synchronisierung und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Daten-Cache und eine gemeinsame Speichereinheit beinhalten, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • Die GPU(s) 1108 kann/können einen Speicher mit hoher Bandbreite (High Bandwith Memory, HBM) und/oder ein 16 GB HBM2-Speichersubsystem beinhalten, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich zu dem oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, wie z.B. ein synchroner Grafik-Direktzugriffsspeicher mit doppelter Datenrate vom Typ fünf (GDDR5).
  • Die GPU(s) 1108 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern beinhalten, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz für Speicherbereiche, die zwischen Prozessoren gemeinsam genutzt werden, verbessert wird. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) genutzt werden, um der/den GPU(s) 1108 den direkten Zugriff auf die Seitentabellen der CPU(s) 1106 zu ermöglichen. In solchen Beispielen kann dann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 1108 einen Fehler aufweist, eine Adressübersetzungsanforderung an die CPU(s) 1106 übertragen werden. Als Antwort darauf kann/können die CPU(s) 1106 in ihren Seitentabellen nach der virtuellen-zu-physischen Abbildung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1108 übertragen. Somit kann die einheitliche bzw. Unified Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für Speicher sowohl der CPU(s) 1106 als auch des/der GPU(s) 1108 ermöglichen, wodurch die Programmierung der GPU(s) 1108 und die Portierung von Anwendungen auf die GPU(s) 1108 vereinfacht wird.
  • Darüber hinaus kann/können die GPU(s) 1108 einen Zugriffszähler beinhalten, der die Häufigkeit des Zugriffs der GPU(s) 1108 auf den Speicher anderer Prozessoren nachverfolgen kann. Der Zugriffszähler kann dazu beitragen, sicherzustellen, dass Speicherseiten in den physischen Speicher des Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
  • Das/die SoC(s) 1104 kann/können eine beliebige Anzahl von Cache(s) 1112, einschließlich der hierin beschriebenen, beinhalten. Der/die Cache(s) 1112 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 1106 als auch der/den GPU(s) 1108 zur Verfügung steht (d.h. der sowohl mit der/den CPU(s) 1106 als auch der/den GPU(s) 1108 verbunden ist). Der/die Cache(s) 1112 kann/können einen Write-Back-Cache beinhalten, der den Zustand von Leitungen nachverfolgen kann, z.B. unter Verwendung eines Cache-Kohärenzprotokolls (z.B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr umfassen, wobei auch kleinere Cache-Größen verwendet werden können.
  • Das/die SoC(s) 1104 kann/können einen oder mehrere Beschleuniger 1114 (z.B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon) beinhalten. Das/die SoC(s) 1104 kann/können z.B. einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder großen On-Chip-Speicher beinhalten kann. Der große On-Chip-Speicher (z.B. 4 MB SRAM) kann es dem Hardware-Beschleunigungscluster ermöglichen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 1108 und zur Auslagerung einiger der Aufgaben der GPU(s) 1108 verwendet werden (z.B. um mehr Zyklen der GPU(s) 1108 für die Ausführung anderer Aufgaben freizugeben). Der/die Beschleuniger 1114 kann/können z.B. für gezielte Arbeitslasten (z.B. Wahrnehmung, faltende neuronale Netzwerke (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“ wie hierin verwendet kann alle Arten von CNNs einschließen, einschließlich regionsbasierter oder regionaler faltender neuronaler Netzwerke (RCNNs) und schneller RCNNs (z.B. wie sie zur Objekterfassung verwendet werden).
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigungscluster) kann/können einen oder mehrere tief lernende(n) Beschleuniger (DLA) beinhalten. Der/die DLA(s) kann/können eine oder mehrere Tensorverarbeitungseinheiten (TPUs) beinhalten, die dazu konfiguriert sein können, zusätzliche zehn Trillionen Operationen pro Sekunde für Deep Learning-Anwendungen und Inferenzierung bereitzustellen. Die TPUs können Beschleuniger sein, die dazu konfiguriert und optimiert sind, Bildverarbeitungsfunktionen auszuführen (z.B. für CNNs, RCNNs usw.). Der/die DLA(s) können ferner für einen bestimmten Satz von Typen neuronaler Netzwerke und Gleitkommaoperationen sowie für die Inferenzierung optimiert sein. Die Ausgestaltung des/der DLA(s) kann mehr Leistung pro Millimeter als eine Allzweck-GPU bereitstellen und übertrifft bei weitem die Leistung einer CPU. Die TPU(s) kann/können mehrere Funktionen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z.B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch Gewichte unterstützt, als auch Nachverarbeitungsfunktionen ausführen.
  • Der/die DLA(s) können schnell und effizient neuronale Netzwerke, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, z.B. und ohne Einschränkung darauf: ein CNN zur Objektidentifizierung und -erfassung unter Verwendung von Daten von Kamerasensoren; ein CNN zur Entfernungsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN zur Notfallfahrzeugerkennung und -identifizierung und -erfassung unter Verwendung von Daten von Mikrofonen; ein CNN zur Gesichtserkennung und Fahrzeugbesitzeridentifizierung unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
  • Der/die DLA(s) kann/können jede Funktion der GPU(s) 1108 durchführen, und unter Verwendung z.B. eines Inferenzbeschleunigers kann ein Entwickler für jede Funktion entweder den/die DLA(s) oder die GPU(s) 1108 targeten. Der Entwickler kann z.B. die Verarbeitung von CNNs und Gleitkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1108 und/oder anderen Beschleuniger(n) 1114 überlassen.
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigungscluster) kann/können einen oder mehrere programmierbare Sichtbeschleuniger (Programmable Vision Accelerator(s), PVA) beinhalten, der/die hierin alternativ als Computer Vision Accelerator bezeichnet werden kann/können. Der/die PVA(s) kann/können dazu ausgelegt und konfiguriert sein, Computer Vision-Algorithmen für die fortgeschrittenen Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Anwendungen der erweiterten Realität (Augmented Reality, AR) und/oder virtuellen Realität (Virtual Reality, VR) zu beschleunigen. Der/die PVA(s) kann/können ein Gleichgewicht zwischen Leistung und Flexibilität bereitstellen. Jeder/jeder der PVA(s) kann beispielsweise und ohne Einschränkung darauf eine beliebige Anzahl von RISC (Reduced Instruction Set Computer)-Kernen bzw. Kernen für Computer mit reduziertem Befehlssatz, Direktspeicherzugriff (Direct Memory Access, DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.
  • Die RISC-Kerne können mit Bildsensoren (z.B. den Bildsensoren jeder der hierin beschriebenen Kameras), einem oder mehreren Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher beinhalten. Die RISC-Kerne können je nach Ausführungsform eines von mehreren Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (Real-Time Operating System, RTOS) ausführen. Die RISC-Kerne können unter Verwendung einer oder mehrerer integrierter Schaltkreisanordnungen, anwendungsspezifischer integrierter Schaltkreise (Application Specific Integrated Circuits, ASICs) und/oder Speichereinrichtungen implementiert sein. Beispielsweise können die RISC-Kerne einen Befehlscache und/oder ein eng gekoppeltes RAM beinhalten.
  • Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1106 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Bereitstellung einer Optimierung für den PVA verwendet werden, einschließlich, aber nicht beschränkt auf, die Unterstützung einer mehrdimensionalen Adressierung und/oder einer Ringadressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, darunter Blockbreite, Blockhöhe, Blocktiefe, horizontales Blockstepping, vertikales Blockstepping und/oder Tiefenstepping.
  • Die Vektorprozessoren können programmierbare Prozessoren sein, die dazu ausgelegt sein können, die Programmierung von Computer Vision-Algorithmen effizient und flexibel auszuführen und Signalverarbeitungsfähigkeiten bereitzustellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Subsystem-Partitionen für die Vektorverarbeitung beinhalten. Der PVA-Kern kann ein Prozessor-Subsystem, eine oder mehrere DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripherievorrichtungen beinhalten. Das Vektorverarbeitungs-Subsystem kann als die primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungseinheit (Vector Processing Unit, VPU), einen Befehlscache und/oder einen Vektorspeicher (z.B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor beinhalten, wie z.B. einen digitalen Signalprozessor für eine einzelne Anweisung und mehrere Daten (Single Instruction, Multiple Data, SIMD) oder einen digitalen Signalprozessor für ein sehr langes Anweisungswort (Very Long Instruction Word, VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Befehlscache beinhalten und kann mit dediziertem Speicher gekoppelt sein. Infolgedessen kann in einigen Beispielen jeder der Vektorprozessoren dazu konfiguriert sein, unabhängig von den anderen Vektorprozessoren auszuführen. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, dazu konfiguriert sein, Datenparallelität zu verwenden. In einigen Ausführungsformen kann z.B. die Mehrzahl der Vektorprozessoren, die in einem einzigen PVA enthalten sind, denselben Computer Vision-Algorithmus ausführen, jedoch in verschiedenen Regionen eines Bilds. In anderen Beispielen können die in einem bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Computer Vision-Algorithmen auf demselben Bild ausführen, oder sogar verschiedene Computer Vision-Algorithmen für aufeinanderfolgende Bilder oder Teile eines Bilds ausführen. Unter anderem kann eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungscluster und eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Darüber hinaus können der/die PVA(s) zusätzlichen Fehlerkorrekturcode-Speicher bzw. ECC (Error Correction Code)-Speicher beinhalten, um die Gesamtsystemsicherheit zu erhöhen.
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigungscluster) kann ein Computer Vision-Netzwerk auf dem Chip und SRAM beinhalten, um SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1114 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher zumindest 4 MB SRAM umfassen, das z.B. und ohne Beschränkung darauf aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine Advanced Peripheral Bus (APB)-Schnittstelle, Konfigurationsschaltkreise, eine Steuereinrichtung und einen Multiplexer beinhalten. Jede Art von Speicher kann verwendet werden. Der PVA und der DLA können über einen Backbone, der dem PVA und dem DLA Hochgeschwindigkeitszugriff auf den Speicher ermöglicht, auf den Speicher zugreifen. Der Backbone kann ein Computer Vision-Netzwerk auf dem Chip umfassen, das den PVA und den DLA mit dem Speicher verbindet (z.B. unter Verwendung des APB).
  • Das On-Chip-Computer Vision-Netzwerk kann eine Schnittstelle beinhalten, die vor der Übertragung irgendwelcher Steuersignale/Adressen/Daten bestimmt, dass sowohl der PVA als auch der DLA fertige und gültige Signale liefern. Eine solche Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie Burst-Kommunikationen für kontinuierliche Datenübertragung bereitstellen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, es können jedoch auch andere Normen und Protokolle verwendet werden.
  • In einigen Beispielen kann/können das/die SoC(s) 1104 einen Hardware-Beschleuniger für Echtzeit-Strahlenverfolgung bzw. Echtzeit-Raytracing-Hardwarebeschleuniger beinhalten, wie in der am 10. August 2018 eingereichten U.S. Patentanmeldung Nr. 16/101,232 beschrieben. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann zur schnellen und effizienten Bestimmung der Orte und Ausdehnungen von Objekten (z.B. innerhalb eines Weltmodells), zur Erzeugung von Echtzeit-Visualisierungssimulationen, zur RADAR-Signalinterpretation, zur Schallausbreitungssynthese und/oder -analyse, zur Simulation von SONAR-Systemen, zur allgemeinen Wellenausbreitungssimulation, zum Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder anderer Funktionen und/oder für andere Zwecke verwendet werden.
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigercluster) haben ein breites Anwendungsspektrum für autonomes Fahren. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungsstufen in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA eignen sich gut für algorithmische Domänen, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz erfordern. Mit anderen Worten arbeitet der PVA gut bei semi-dichten oder dichten regelmäßigen Berechnungen, selbst bei kleinen Datensätzen, die vorhersagbare Laufzeiten mit geringer Latenz und niedriger Leistung benötigen. Folglich sind im Kontext von Plattformen für autonome Fahrzeuge die PVAs dazu ausgelegt, klassische Computer-Vision-Algorithmen auszuführen können, da sie bei Objekterfassung effizient sind und mit Ganzzahlenmathematik arbeiten.
  • Zum Beispiel wird in Übereinstimmung mit einer Ausführungsform der Technologie der PVA zur Durchführung von Computer-Stereosehen verwendet. In einigen Beispielen kann ein Algorithmus auf der Grundlage eines semi-globalen Abgleichs verwendet werden, obwohl dies nicht beschränkend sein soll. Viele Anwendungen für autonomes Fahren der Level 3-5 erfordern eine Bewegungsschätzung/einen Stereoabgleich im Vorübergehen bzw. on-the-fly (z.B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerfassung usw.). Der PVA kann eine Computer-Stereosehfunktion auf Inputs von zwei monokularen Kameras durchführen.
  • In einigen Beispielen kann der PVA dazu verwendet werden, einen dichten optischen Fluss durchzuführen. Entsprechend der Verarbeitung von RADAR-Rohdaten (z.B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitetes RADAR bereitzustellen. In anderen Beispielen wird der PVA für die Tiefenverarbeitung zur Laufzeit verwendet, indem z.B. Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten bereitzustellen.
  • Der DLA kann für den Betrieb jeder beliebigen Art von Netzwerk verwendet werden, um die Kontrolle und die Fahrsicherheit zu verbessern, einschließlich beispielsweise eines neuronalen Netzwerks, das für jede Objekterfassung ein Vertrauensmaß ausgibt. Ein solcher Vertrauenswert kann als eine Wahrscheinlichkeit interpretiert werden oder als Bereitstellung einer relativen „Gewichtung“ jeder Erfassung im Vergleich zu anderen Erfassungen. Dieser Vertrauenswert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erfassungen als echte positive Erfassungen und nicht als falsch positive Erfassungen anzusehen sind. Beispielsweise kann das System einen Schwellenwert für das Vertrauen festlegen und nur diejenigen Erfassungen, die den Schwellenwert überschreiten, als echte positive Erfassungen betrachten. In einem automatischen Notbrems- bzw. Automatic Emergency Braking (AEB)-System würden falsch-positive Erkennungen das Fahrzeug dazu veranlassen, automatisch eine Notbremsung durchzuführen, welches offensichtlich unerwünscht ist. Daher sollten nur die zuverlässigsten Erfassungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Vertrauenswerts betreiben. Das neuronale Netzwerk kann als seinen Input zumindest eine Teilmenge von Parametern verwenden, wie z.B. die Begrenzungskastenmaße, die (z.B. von einem anderen Teilsystem) erhaltene Grundebenenschätzung, die Ausgabe des Sensors 1166 der Trägheitsmesseinheit (IMU), die mit der Orientierung des Fahrzeugs 102 korreliert, die Entfernung, die 3D-Positionsschätzungen des Objekts, die aus dem neuronalen Netzwerk und/oder anderen Sensoren (z.B. LIDAR-Sensor(en) 1164 oder RADAR-Sensor(en) 1160) erhalten wurden, und andere.
  • Das/die SoC(s) 1104 kann/können einen oder mehrere Datenspeicher 1116 (z.B. Speicher) beinhalten. Der/die Datenspeicher 1116 können On-Chip-Speicher des/der SoC(s) 1104 sein, der neuronale Netze speichern kann, die auf der GPU und/oder dem DLA auszuführen sind. In einigen Beispielen kann/können der/die Datenspeicher 1116 groß genug sein, um mehrere Instanzen von neuronalen Netzwerken für Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1112 kann/können L2- oder L3-Cache(s) 1112 umfassen. Eine Bezugnahme auf den/die Datenspeicher 1116 kann eine Bezugnahme auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 1114, wie hierin beschrieben, zugeordnet ist.
  • Das/die SoC(s) 1104 können einen oder mehrere Prozessor(en) 1110 (z.B. eingebettete Prozessoren) beinhalten. Der/die Prozessor(en) 1110 kann/können einen Boot- und Leistungsverwaltungs-Prozessor, der ein dedizierter Prozessor sein kann, und ein Subsystem zur Handhabung von Boot-Leistung und Verwaltungsfunktionen sowie damit verwandter Sicherheitsdurchsetzung beinhalten. Der Boot- und Leistungsmanagement-Prozessor kann ein Teil der Boot-Sequenz des/der SoC(s) 1104 sein und zur Laufzeit Leistungsverwaltungsdienste bereitstellen. Der Boot- und Leistungsverwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen des Systems zu Energiesparzuständen, eine Verwaltung der Thermik und der Temperatursensoren des/der SoC(s) 1104 und/oder eine Verwaltung der Leistungszustände des/der SoC(s) 1104 bereitstellen. Jeder Temperatursensor kann als ein Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und das/die SoC(s) 1104 kann/können die Ringoszillatoren dazu verwenden, Temperaturen der CPU(s) 1106, der GPU(s) 1108 und/oder des/der Beschleuniger(s) 1114 zu erfassen. Falls festgestellt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Leistungsverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und das/die SoC(s) 1104 in einen Niedrigleistungszustand versetzen und/oder das Fahrzeug 102 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z.B. das Fahrzeug 102 zu einem sicheren Halt bringen).
  • Der/die Prozessor(en) 1110 kann/können ferner eine Reihe von eingebetteten Prozessoren beinhalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audio-Subsystem sein, das volle Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und eine breite und flexible Palette von Audio-E/A-Schnittstellen bereitstellt. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der/die Prozessor(en) 1110 kann/können ferner eine ständig eingeschaltete Prozessor-Engine beinhalten, die notwendige Hardwaremerkmale zur Unterstützung von der Verwaltung von Sensoren mit niedrigem Stromverbrauch und Aufwachfällen bereitstellen kann. Die ständig eingeschaltete bzw. Always-on-Prozessor-Engine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripherievorrichtungen (z.B. Zeitgeber und eine oder mehrere Unterbrechungssteuereinrichtung(en)), verschiedene E/A-Steuereinrichtungs-Peripherievorrichtungen und Routing-Logik beinhalten.
  • Der/die Prozessor(en) 1110 kann/können ferner eine Sicherheitscluster-Engine beinhalten, die ein dediziertes Prozessor-Subsystem zur Handhabung des Sicherheitsmanagements für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripherievorrichtungen (z.B. Zeitgeber, eine oder mehrere Unterbrechungssteuer-einrichtung(en) usw.) und/oder Routing-Logik beinhalten. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Schrittverriegelungs- bzw. Lockstep-Modus arbeiten und als ein einziger Kern mit Vergleichslogik zur Erfassung von Unterschieden zwischen ihren Operationen funktionieren.
  • Der/die Prozessor(en) 1110 kann/können ferner hinaus eine Echtzeit-Kamera-Engine beinhalten, die ein dediziertes Prozessor-Subsystem zur Handhabung der Echtzeit-Kameraverwaltung umfassen kann.
  • Der/die Prozessor(en) 1110 kann/können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, welcher eine Hardware-Engine ist, die Teil der Kamera-Verarbeitungspipeline ist.
  • Der/die Prozessor(en) 1110 kann/können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock (z.B. auf einem Mikroprozessor implementiert) sein kann, der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Wiedergabefenster zu produzieren. Der Videobildkompositor kann eine Objektivverzerrungskorrektur bei der/den Weitwinkelkamera(s) 1170, der/den Rundumsicht-Kamera(s) 1174 und/oder bei Sensoren von Überwachungskameras in der Kabine durchführen. Der Sensor der Überwachungskamera in der Kabine wird vorzugsweise durch ein neuronales Netzwerk überwacht, das auf einer anderen Instanz des erweiterten SoC läuft und dazu konfiguriert ist, Ereignisse in der Kabine zu identifizieren und entsprechend zu reagieren. Ein kabineninternes System kann ein Lippenlesen durchführen, um einen Mobilfunkdienst zu aktivieren und einen Telefonanruf zu tätigen, E-Mails zu diktieren, den Zielort des Fahrzeugs zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachaktiviertes Websurfen zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind andernfalls deaktiviert.
  • Der Videobildkompositor kann eine verbesserte zeitliche Rauschreduzierung sowohl für die räumliche als auch für die zeitliche Rauschreduzierung beinhalten. Wenn beispielsweise Bewegung in einem Video auftritt, gewichtet die Rauschreduzierung räumliche Informationen in geeigneter Weise und verringert dadurch das Gewicht von von benachbarten Frames bereitgestellten Informationen. Wenn ein Bild oder Teil eines Bilds keine Bewegung enthält, kann die von dem Videobildkompositor durchgeführte zeitliche Rauschreduzierung Informationen aus dem vorherigen Bild dazu verwenden, das Rauschen in dem aktuellen Bild zu reduzieren.
  • Der Videobildkompositor kann auch dazu konfiguriert sein, eine Stereogleichrichtung auf den Eingangs-Stereolinsen-Frames durchzuführen. Der Videobildkompositor kann ferner für eine Benutzeroberflächenkomposition verwendet werden, wenn der Betriebssystem-Desktop in Verwendung ist und die GPU(s) 1108 nicht erforderlich ist/sind, um kontinuierlich neue Oberflächen zu rendern. Selbst wenn die GPU(s) 1108 eingeschaltet ist/sind und aktiv ein 3D-Rendering durchführt/durchführen, kann der Videobildkompositor zur Entlastung der GPU(s) 1108 verwendet werden, um die Leistung und das Ansprechvermögen zu verbessern.
  • Das/die SoC(s) 1104 kann/können ferner eine serielle MIPI (Mobile Industry Processor Interface)-Schnittstellen-Kameraschnittstelle zum Empfang von Video und Input von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingangsblock beinhalten, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 1104 kann/können ferner einen oder mehrere Ein-/Ausgabe-Steuereinrichtung(en) beinhalten, die durch Software gesteuert werden kann/können und zum Empfang von E/A-Signalen, die nicht für eine bestimmte Rolle vorgesehen sind, verwendet werden kann/können.
  • Das/die SoC(s) 1104 können ferner hinaus eine breite Palette von Peripherieschnittstellen beinhalten, um die Kommunikation mit Peripherievorrichtungen, Audio-Codecs, der Energieverwaltung und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 1104 kann/können zur Verarbeitung von Daten von Kameras (z.B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z.B. LIDAR-Sensor(en) 1164, RADAR-Sensor(en) 1160, usw.), die über Ethernet verbunden sein können, Daten von dem Bus 1102 (z.B. Fahrzeuggeschwindigkeit 102, Lenkradposition, usw.), Daten von einem oder mehreren GNSS-Sensor(en) 1158 (z.B. verbunden über Ethernet oder CAN-Bus) verwendet werden. Das/die SoC(s) 1104 kann/können ferner eine oder mehrere dedizierte Hochleistungs-Massenspeicher-Steuereinrichtung(en) beinhalten, die ihre eigenen DMA-Engines beinhalten können und die dazu verwendet werden können, die CPU(s) 1106 von Routineaufgaben der Datenverwaltung zu befreien.
  • Das/die SoC(s) 1104 kann/können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, die die Automatisierungslevel 3-5 überspannt und damit eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die Computer Vision und ADAS-Techniken für Diversität und Redundanz nutzt und effizient einsetzt, und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep Learning-Werkzeugen bereitstellt. Das/die SoC(s) 1104 können schneller, zuverlässiger und sogar energie- und raumsparender sein als konventionelle Systeme. Beispielsweise kann der/die Beschleuniger 1114 in Kombination mit der/den CPU(s) 1106, der/den GPU(s) 1108 und dem/den Datenspeicher(n) 1116 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Level 3-5 bereitstellen.
  • Die Technologie stellt somit Fähigkeiten und Funktionen bereit, die von konventionellen Systemen nicht erreicht werden können. Beispielsweise können Computer Vision-Algorithmen auf CPUs ausgeführt werden, welche unter Verwendung einer höheren Programmiersprache wie beispielsweise der Programmiersprache C dazu konfiguriert sein können, eine Vielzahl von Verarbeitungsalgorithmen für eine breite Vielzahl von Bilddaten auszuführen. CPUs sind jedoch häufig nicht in der Lage, die Leistungsanforderungen vieler Computer-Vision-Anwendungen zu erfüllen, wie beispielsweise diejenigen mit Bezug zu Ausführungszeit und Stromverbrauch.
  • Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterfassungsalgorithmen in Echtzeit auszuführen, welches eine Anforderung von fahrzeuginternen ADAS-Anwendungen und eine Anforderung für praktische autonome Fahrzeuge der Level 3-5 ist.
  • Im Gegensatz zu konventionellen Systemen erlaubt die hierin beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungsclusters, mehrere neuronale Netze gleichzeitig und/oder sequenziell auszuführen, sowie die Kombination der Ergebnisse, um eine autonome Fahrfunktionalität der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder der dGPU (z.B. den GPU(s) 1120) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer erlaubt, Verkehrszeichen zu lesen und zu verstehen, einschließlich der Zeichen, für welche das neuronale Netzwerk nicht speziell trainiert worden ist. Der DLA kann ferner ein neuronales Netzwerk beinhalten, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis des Zeichens zu liefern und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
  • Als weiteres Beispiel können mehrere neuronale Netze gleichzeitig betrieben werden, wie es für das Fahren auf Level 3, 4 oder 5 erforderlich ist. Beispielsweise kann ein Warnschild mit der Aufschrift „Vorsicht: Blinklichter zeigen eisige Bedingungen an“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netzwerk (z.B. einem trainierten neuronalen Netzwerk) als ein Verkehrszeichen identifiziert werden, der Text „Blinklichter zeigen eisige Bedingungen an“ kann von einem zweiten eingesetzten neuronalen Netzwerk interpretiert werden, welches die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass dann, wenn blinkende Lichter erfasst werden, eisige Bedingungen vorliegen. Das blinkende Licht kann durch Betreiben eines dritten eingesetzten neuronalen Netzwerks über mehrere Frames hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von blinkenden Lichtern informiert. Alle drei neuronalen Netzwerke können gleichzeitig laufen, z.B. innerhalb des DLA und/oder auf der/den GPU(s) 1108.
  • In einigen Beispielen kann ein CNN zur Gesichtserkennung und Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren nutzen, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 102 zu identifizieren. Die immer aktive Sensorverarbeitungs-Engine kann dazu verwendet werden, das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert, und die Beleuchtung einzuschalten, und um, im Sicherheitsmodus, das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen das/die SoC(s) 1104 für Sicherheit gegen Diebstahl und/oder Autodiebstahl.
  • In einem anderen Beispiel kann ein CNN für die Erkennung und Identifizierung von Notfallfahrzeugen die Daten von Mikrofonen 1196 zur Erkennung und Identifizierung von Sirenen von Notfallfahrzeugen verwenden. Im Gegensatz zu konventionellen Systemen, die allgemeine Klassifikatoren zur Erfassung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, verwendet/verwenden das/die SoC(s) 1104 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. In einer bevorzugten Ausführungsform ist das CNN, das auf dem DLA läuft, darauf trainiert, die relative Schließgeschwindigkeit des Einsatzfahrzeugs (z.B. durch Nutzung des Doppler-Effekts) zu identifizieren. Das CNN kann darüber hinaus darauf trainiert sein, Notfallfahrzeuge zu identifizieren, die spezifisch für den lokalen Bereich sind, in welchem das Fahrzeug operiert, wie durch einen oder mehrere GNSS-Sensor(en) 1158 identifiziert. Folglich wird zum Beispiel dann, wenn es in Europa arbeitet, das CNN versuchen, europäische Sirenen zu erkennen, und wenn es sich in den Vereinigten Staaten befindet, versuchen, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Notfallfahrzeug erfasst ist, kann ein Steuerprogramm dazu verwendet werden, mit Unterstützung der Ultraschallsensoren 1162 eine Notfallfahrzeug-Sicherheitsroutine auszuführen, das Fahrzeug abzubremsen, zum Straßenrand hin zu lenken, das Fahrzeug zu parken und/oder in den Leerlauf zu versetzen, bis das/die Notfallfahrzeug(e) vorbeifahren.
  • Das Fahrzeug kann eine oder mehrere CPU(s) 1118 (z.B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitsverbindung (z.B. PCIe) mit dem/den SoC(s) 1104 gekoppelt sein können. Die CPU(s) 1118 kann/können z.B. einen X86-Prozessor beinhalten. Die CPU(s) 1118 kann/können zur Durchführung einer Vielzahl von Funktionen verwendet werden, einschließlich einer Arbitrierung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 1104 und/oder einer Überwachung des Status und des Zustands beispielsweise des/der Steuereinrichtung(en) 1136 und/oder des Infotainment-SoC 1130.
  • Das Fahrzeug 102 kann eine oder mehrere GPU(s) 1120 beinhalten (z.B. diskrete GPU(s) oder dGPU(s)), die über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) mit dem/den SoC(s) 1104 gekoppelt sein kann/können. Die GPU(s) 1120 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z.B. durch Ausführung redundanter und/oder unterschiedlicher neuronaler Netzwerke, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netzwerke auf der Grundlage eines Input (z.B. Sensordaten) von Sensoren des Fahrzeugs 102 verwendet werden.
  • Das Fahrzeug 102 kann ferner die Netzwerkschnittstelle 1124 beinhalten, welche eine oder mehrere drahtlose Antennen 1126 (z.B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie z.B. eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) beinhalten kann. Die Netzwerkschnittstelle 1124 kann dazu verwendet werden, eine drahtlose Konnektivität über das Internet mit der Cloud (z.B. mit dem/den Server(n) 1178 und/oder anderen Netzwerkvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z.B. Client-Vorrichtungen von Passagieren) zu ermöglichen. Um mit anderen Fahrzeugen zu kommunizieren, kann eine direkte Verbindung zwischen den beiden Fahrzeugen hergestellt werden, und/oder kann eine indirekte Verbindung (z.B. über Netzwerke hinweg und über das Internet) hergestellt werden. Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 102 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 102 liefern (z.B. Fahrzeuge vor, seitlich und/oder hinter dem Fahrzeug 102). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 102 sein.
  • Die Netzwerkschnittstelle 1124 kann ein SoC beinhalten, das Modulations- und Demodulationsfunktionalität bereitstellt und es dem/den Steuereinrichtung(en) 1136 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzschnittstelle 1124 kann ein Funkfrequenz-Front-End zur Aufwärtskonvertierung von Basisband zu Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz zu Basisband beinhalten. Die Frequenzkonvertierungen können durch gut bekannte Verfahren durchgeführt werden, und/oder können unter Verwendung von Super-Heterodyne-Prozessen durchgeführt werden. In einigen Beispielen kann die Funkfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt sein. Die Netzwerkschnittstelle kann drahtlose Funktionalität für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
    Das Fahrzeug 102 kann darüber hinaus Datenspeicher 1128 beinhalten, die auch Off-Chip-Speicher (z.B. außerhalb der SoC(s) 1104) beinhalten können. Der (die) Datenspeicher 1128 kann (können) ein oder mehrere Speicherelemente einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte beinhalten, die zumindest ein Datenbit speichern können.
  • Das Fahrzeug 102 kann ferner Datenspeicher 1128 beinhalten, welche Off-Chip-Speicher (z.B. außerhalb des/der SoC(s) 1104) beinhalten können. Der/die Datenspeicher 1128 kann/können ein oder mehrere Speicherelemente einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Vorrichtungen beinhalten, die zumindest ein Datenbit speichern können.
  • Das Fahrzeug 102 kann ferner einen oder mehrere GNSS-Sensor(en) 1158 beinhalten. Der/die GNSS-Sensor(en) 1158 (z.B. GPS und/oder assistierte GPS-Sensoren), zur Unterstützung von Kartierungs-, Wahrnehmungs-, Belegungsrastererzeugungs- und/oder Wegplanungsfunktionen. Es kann eine beliebige Anzahl von GNSS-Sensor(en) 1158 verwendet werden, einschließlich, zum Beispiel und ohne Beschränkung, eines GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
  • Das Fahrzeug 102 kann ferner einen oder mehrere RADAR-Sensor(en) 1160 beinhalten. Der/die RADAR-Sensor(en) 1160 kann/können von dem Fahrzeug 102 zur Fernbereich-Fahrzeugerfassung, selbst bei Dunkelheit und/oder schlechten Wetterbedingungen, verwendet werden. Die funktionalen Sicherheitsstufen von RADAR können ASIL B sein. Der/die RADAR-Sensor(en) 1160 kann/können das CAN und/oder den Bus 1102 (z.B. zur Übertragung von Daten, die von dem/von den RADAR-Sensor(en) 1160 erzeugt wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, in einigen Beispielen mit Zugriff auf Ethernet, um auf Rohdaten zuzugreifen. Es kann eine breite Vielzahl von RADAR-Sensortypen verwendet werden. Der/die RADAR-Sensor(en) 1160 kann/können z.B. und ohne Beschränkung für die frontseitige, die heckseitige und die seitliche RADAR-Nutzung geeignet sein. In einigen Beispielen werden ein oder mehrere Puls-Doppler-RADAR-Sensor(en) verwendet.
  • Der/die RADAR-Sensor(en) 1160 kann/können verschiedene Konfigurationen beinhalten, wie z.B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, kurze Reichweite mit seitlicher Abdeckung usw. In einigen Beispielen kann das Fernbereich-RADAR bzw. Radar mit großer Reichweite für Funktionalität der adaptiven Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Abtastungen, wie beispielsweise innerhalb einer Reichweite von 250 m, realisiert wird. Der/die RADAR-Sensor(en) 1160 kann/können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und kann/können von ADAS-Systemen für Notbremsunterstützung und Vorauskollisionswarnung verwendet werden. Fernbereich-RADAR-Sensoren können monostatisches multimodales RADAR mit mehreren (z.B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die zentralen vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu ausgelegt ist, die Umgebung des Fahrzeugs 102 bei höheren Geschwindigkeiten mit minimaler Interferenz durch Verkehr auf benachbarten Fahrspuren aufzuzeichnen. Die anderen beiden Antennen können das Sichtfeld erweitern und es so möglich machen, Fahrzeuge, die in die Fahrspur des Fahrzeugs 102 einfahren oder diese verlassen, schnell erfasst werden können.
  • Mittelbereich-RADAR-Systeme können beispielsweise eine Reichweite von bis zu 1160m (Front) oder 80m (Heck) und ein Sichtfeld von bis zu 42 Grad (Front) oder 1150 Grad (Heck) beinhalten. Kurzbereich-RADAR-Systeme können ohne Beschränkung darauf RADAR-Sensoren beinhalten, welche an beiden Enden des hinteren Stoßfängers installiert sind. Wenn es an beiden Enden des hinteren Stoßfängers installiert ist, kann ein solches RADAR-Sensorsystem zwei Strahlen erzeugen, die ständig den toten Winkel im hinteren Bereich und neben dem Fahrzeug überwachen.
  • Kurzbereich-RADAR-Systeme können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Unterstützung des Spurwechsels verwendet werden.
  • Das Fahrzeug 102 kann ferner Ultraschallsensor(en) 1162 beinhalten. Der/die Ultraschallsensor(en) 1162, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 102 positioniert sein kann/können, kann/können zur Einparkunterstützung und/oder zur Erzeugung und Aktualisierung eines Belegungsrasters verwendet werden. Eine breite Vielzahl von Ultraschallsensor(en) 1162 kann verwendet werden, und verschiedene Ultraschallsensor(en) 1162 können für unterschiedliche Erfassungsbereiche (z.B. 2,5m, 4m) verwendet werden. Der/die Ultraschallsensor(en) 1162 kann/können auf einem funktionalen Sicherheitslevel von ASIL B arbeiten.
  • Das Fahrzeug 102 kann einen oder mehrere LIDAR-Sensor(en) 1164 beinhalten. Der/die LIDAR-Sensor(en) 1164 kann/können für die Objekt- und Fußgängererfassung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1164 kann/können dem funktionalen Sicherheitslevel ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 102 mehrere LIDAR-Sensoren 1164 (z.B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (z.B. zur Bereitstellung von Daten für einen Gigabit-Ethernet-Switch).
  • In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 1164 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld bereitzustellen. (Ein) kommerziell erhältliche(r) LIDAR-Sensor(en) 1164 kann/können eine versprochene Reichweite von näherungsweise 102m mit einer Genauigkeit von 2cm-3cm haben und unterstützt/unterstützen z.B. eine 102 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht hervorstehende LIDAR-Sensoren 1164 verwendet werden. In solchen Beispielen kann/können der/die LIDAR-Sensor(en) 1164 als eine kleine Vorrichtung implementiert sein, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 102 eingebettet sein kann. Der/die LIDAR-Sensor(en) 1164 kann/können in solchen Beispielen ein Sichtfeld von bis zu 1120 Grad horizontal und von bis zu 35 Grad vertikal bereitstellen, mit einer Reichweite von 200m selbst für schwach reflektierende Objekte. (Ein) frontmontierte(r) LIDAR-Sensor(en) 1164 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
  • In einigen Beispielen können auch LIDAR-Technologien, wie z.B. 3D-Flash-LIDAR, eingesetzt werden. 3D-Flash-LIDAR verwendet einen Laserblitz als eine Übertragungsquelle, um die Fahrzeugumgebung bis zu einer Entfernung von näherungsweise 200 m auszuleuchten. Eine Flash-LIDAR-Einheit beinhaltet einen Rezeptor, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, welches wiederum der Reichweite von dem Fahrzeug zu den Objekten entspricht. Flash-LIDAR kann es erlauben, mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung zu erzeugen. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 102. Verfügbare 3D-Flash-LIDAR-Systeme beinhalten eine Festkörper-3D-LIDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z.B. eine nicht abtastende LIDAR-Vorrichtung). Das Flash-LIDAR-Gerät kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Frame verwenden und kann das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und ko-registrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR, und weil Flash-LIDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, kann/können der/die LIDAR-Sensor(en) 1164 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
  • Das Fahrzeug kann ferner einen oder mehrere IMU-Sensor(en) 1166 beinhalten. Der/die IMU-Sensor(en) 1166 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 102 befinden. Der/die IMU-Sensor(en) 1166 kann/können zum Beispiel und ohne Beschränkung darauf einen oder mehrere Beschleunigungsmesser, einen oder mehrere Magnetometer, ein oder mehrere Gyroskop(e), einen oder mehrere Magnetkompass(e) und/oder andere Sensortypen beinhalten. In einigen Beispielen, wie z.B. bei Sechsachsen-Anwendungen, kann/können der/die IMU-Sensor(en) 1166 Beschleunigungsmesser und Gyroskope beinhalten, während bei Neunachsen-Anwendungen der/die IMU-Sensor(en) 1166 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen kann/können.
  • In einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 1166 als ein miniaturisiertes GPS/INS (GPS/INS = GPS-Aided Inertial Navigation System) implementiert sein, das Trägheitssensoren von mikro-elektromechanischen Systemen (MEMS), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen zur Schätzung von Position, Geschwindigkeit und Lage kombiniert. Insoweit kann/können in einigen Beispielen der/die IMU-Sensor(en) 1166 das Fahrzeug 102 in die Lage versetzen, einen Kurs abzuschätzen, ohne einen Input von einem magnetischen Sensor zu erfordern, indem die Geschwindigkeitsänderungen vom GPS zu dem/den IMU-Sensor(en) 1166 direkt beobachtet und korreliert werden. In einigen Beispielen kann/können der/die IMU-Sensor(en) 1166 und der/die GNSS-Sensor(en) 1158 in einer einzelnen integrierten Einheit kombiniert sein.
  • Das Fahrzeug kann Mikrofon(e) 1196 beinhalten, die in und/oder um das Fahrzeug 102 herum platziert sind. Das/die Mikrofon(e) 1196 kann/können unter anderem zur Erkennung und Identifizierung von Notfallfahrzeugen verwendet werden.
  • Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, einschließlich Stereokamera(s) 1168, Weitwinkelkamera(s) 1170, Infrarotkamera(s) 1172, Rundumsicht-Kamera(s) 1174, Fern- und/oder Mittelbereichkamera(s) 1198 und/oder andere Kameratypen. Die Kameras können zur Erfassung von Bilddaten um eine gesamte Peripherie des Fahrzeugs 102 herum verwendet werden. Welche Arten von Kameras verwendet werden, hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 102 ab, und jede beliebige Kombination von Kameratypen kann verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 102 herum bereitzustellen. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. Beispielsweise kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras beinhalten. Die Kameras können zum Beispiel und ohne Beschränkung darauf Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kamera(s) ist hierin mit Bezug zu 11A und 11 B ausführlicher beschrieben.
  • Das Fahrzeug 102 kann ferner einen oder mehrere Schwingungssensor(en) 1142 beinhalten. Der/die Schwingungssensor(en) 1142 kann/können Schwingungen von Komponenten des Fahrzeugs, wie z.B. der Achse(n), messen. Änderungen der Vibrationen können zum Beispiel auf eine Veränderung der Straßenoberfläche hinweisen. In einem anderen Beispiel, wenn zwei oder mehr Schwingungssensoren 1142 verwendet werden, können die Unterschiede zwischen den Schwingungen zur Bestimmung der Reibung oder des Schlupfes der Fahrbahnoberfläche verwendet werden (z.B. wenn der Schwingungsunterschied zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
  • Das Fahrzeug 102 kann ein ADAS-System 1138 beinhalten. Das ADAS-System 1138 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 1138 kann eine autonome/adaptive/automatische Geschwindigkeitsregelung (Autonomous/ Adaptive/Automatic Cruise Control, ACC), eine kooperative adaptive Geschwindigkeitsregelung (Cooperative Adaptive Cruise Control, CACC), eine Vorausaufprallwarnung (Forward Crash Warning, FCW), eine automatische Notbremsung (Automatic Emergency Braking, AEB), Spurverlassenswarnungen (Lane Departure Warnings, LDW), Fahrspurhalteunterstützung (Lane Keep Assist, LKA), Totwinkelwarnung (Blind Spot Warning, BSW), Warnung vor rückwärtigem Querverkehr (Rear Cross-Traffic Warning, RCTW), Kollisionswarnsysteme (collision Warning Systems, CWS), Fahrspurzentrierung (Lane Centering, LC) und/oder andere Merkmale und Funktionalität beinhalten.
  • Die ACC-Systeme können einen oder mehrere RADAR-Sensor(en) 1160, einen oder mehrere LIDAR-Sensor(en) 1164 und/oder eine oder mehrere Kamera(s) verwenden. Die ACC-Systeme können eine Längs-ACC und/oder eine Quer-ACC beinhalten. Die Längs-ACC überwacht und steuert den Abstand zu dem Fahrzeug unmittelbar vor dem Fahrzeug 102 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC sorgt für die Einhaltung des Abstands und weist das Fahrzeug 102 an, bei Bedarf die Spur zu wechseln. Die Quer-ACC steht im Zusammenhang mit anderen ADAS-Anwendungen wie beispielsweise LCA und CWS.
  • CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1124 und/oder die drahtlose(n) Antenne(n) 1126 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z.B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-zu-Fahrzeug (V2V)-Kommunikationsverbindung bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug (12V)-Kommunikationsverbindung sein können. Allgemein stellt das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z.B. Fahrzeuge unmittelbar vor dem und auf derselben Fahrspur wie das Fahrzeug 102) bereit, während das 12V-Kommunikationskonzept Informationen über den Verkehr weiter voraus liefert. CACC-Systeme können eine oder beide der 12V- und V2V-Informationsquellen beinhalten. Angesichts der Informationen der Fahrzeuge vor dem Fahrzeug 102 kann CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu verringern.
  • FCW-Systeme sind dazu konzipiert, den Fahrer auf eine Gefahr aufmerksam machen, so dass der Fahrer korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder einen oder mehrere RADAR-Sensor(en) 1160, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer, wie z.B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente, gekoppelt ist. FCW-Systeme können eine Warnung bereitstellen, wie beispielsweise in der Form eines Tons, einer visuellen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-Systeme erfassen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können eine oder mehrere nach vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1160 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erfasst, warnt es in der Regel zuerst den Fahrer, korrigierende Maßnahmen zur Vermeidung des Zusammenstoßes zu ergreifen, und wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen des vorausgesagten Zusammenstoßes zu verhindern oder zumindest abzuschwächen. AEB-Systeme können Techniken wie beispielsweise dynamische Bremsunterstützung und/oder Abbremsen bei drohendem Zusammenstoß beinhalten.
  • LDW-Systeme stellen sichtbare, hörbare und/oder taktile Warnungen, wie z.B. Lenkrad- oder Sitzvibrationen, bereit, um den Fahrer zu warnen, wenn das Fahrzeug 102 Fahrbahnmarkierungen überfährt. Ein LDW-System aktiviert sich nicht, wenn der Fahrer durch Aktivierung eines Abbiegesignals ein beabsichtigtes Verlassen einer Fahrspur anzeigt. LDW-Systeme können nach vorn gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer, wie z.B. einer Anzeige, einem Lautsprecher und/oder einer Vibrationskomponente, gekoppelt ist.
  • LKA-Systeme sind eine Variation von LDW-Systemen. LKA-Systeme stellen einen Lenkinput oder ein Bremsen bereit, um das Fahrzeug 102 zu korrigieren, falls das Fahrzeug 102 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme erfassen und warnen den Fahrer vor Fahrzeugen, die sich im toten Winkel eines Automobils befinden. BSW-Systeme können einen sichtbaren, hörbaren und/oder taktilen Alarm ausgeben, um anzuzeigen, dass ein Einscheren oder ein Spurwechsel unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer ein Abbiegesignal benutzt. BSW-Systeme können eine oder mehrere nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1160 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer, wie z.B. einer Anzeige, einem Lautsprecher und/oder einer Vibrationskomponente, gekoppelt ist.
  • RCTW-Systeme können eine sichtbare, hörbare und/oder taktile Benachrichtigung bereitstellen, wenn beim Rückwärtsfahren des Fahrzeugs 102 ein Objekt außerhalb des Rückfahrkamerabereichs erfasst wird. Einige RCTW-Systeme beinhalten eine AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Aufprall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 1160 verwenden, der/die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt ist/sind, der/die elektrisch mit einer Rückmeldung an den Fahrer, wie z.B. einer Anzeige, einem Lautsprecher und/oder einer Vibrationskomponente, gekoppelt ist/sind.
  • Konventionelle ADAS-Systeme können anfällig für falsch-positive Ergebnisse sein, die für einen Fahrer ärgerlich und ablenkend sein können, in der Regel aber nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 102 muss jedoch das Fahrzeug 102 im Fall widersprüchlicher Ergebnisse selbst entscheiden, ob das Ergebnis von einem Primärcomputer oder einem Sekundärcomputer (z.B. einer ersten Steuereinrichtung 1136 oder einer zweiten Steuereinrichtung 1136) zu berücksichtigen ist. Zum Beispiel kann in einigen Ausführungsformen das ADAS-System 1138 ein Backup- und/oder ein Sekundärcomputer zum Bereitstellen von Wahrnehmungsinformationen an ein Backup-Computer-Rationalitätsmodul sein. Das Backup-Computer-Rationalitätsmodul kann eine redundante diverse Software auf Hardware-Komponenten ausführen, um Fehler in Wahrnehmungen und dynamischen Fahraufgaben zu erkennen. Ausgaben des ADAS-Systems 1138 können einer übergeordneten MCU zur Verfügung gestellt werden. Falls Ausgaben des Primärcomputers und des Sekundärcomputers im Widerspruch stehen, muss die übergeordnete MCU bestimmen, wie der Widerspruch beseitigt werden kann, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der Primärcomputer dazu konfiguriert sein, der übergeordneten MCU einen Vertrauenswert bereitzustellen, der das Vertrauen des Primärcomputers in das gewählte Ergebnis anzeigt. Falls der Vertrauenswert einen Schwellenwert überschreitet, kann die übergeordnete MCU der Anweisung des Primärcomputers folgen, unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Wenn der Vertrauenswert den Schwellenwert nicht erreicht und wenn der Primär- und der Sekundärcomputer unterschiedliche Ergebnisse anzeigen (z.B. den Widerspruch), kann die übergeordnete MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
  • Die übergeordnete MCU kann dazu konfiguriert sein, ein oder mehrere neuronale(s) Netzwerk(e) bzw. neuronale Netzwerke zu betreiben, das/die so trainiert und konfiguriert ist/sind, dass es/sie auf der Grundlage von Ausgaben des Primärcomputers und des Sekundärcomputers die Bedingungen bestimmt/bestimmen, unter welchen der Sekundärcomputer Fehlalarme bereitstellt. Folglich kann/können das/die neuronale(n) Netzwerk(e) in der übergeordneten MCU erfahren, wann der Ausgabe des Sekundärcomputers vertraut werden kann und wann nicht. Wenn der Sekundärcomputer beispielsweise ein RADAR-basiertes FCW-System ist, kann/können (ein) neuronale(s) Netzwerk(e) in der übergeordneten MCU erfahren, wenn das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahren darstellen, wie z.B. ein Entwässerungsgitter oder eine Schachtabdeckung, die einen Alarm auslösen. In ähnlicher Weise kann dann, wenn der Sekundärcomputer ein kamerabasiertes LDW-System ist, ein neuronales Netzwerk in der übergeordneten MCU lernen, die LDW zu übersteuern, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die ein oder mehrere neuronale(s) Netzwerk(e) beinhalten, die auf der übergeordneten MCU laufen, kann die übergeordnete MCU zumindest einen DLA oder eine GPU beinhalten, der/die für den Betrieb des/der neuronalen Netzwerk(s/e) mit zugehörigem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die übergeordnete MCU eine Komponente des/der SoC(s) 1104 umfassen und/oder als eine solche in diesen enthalten sein.
  • In anderen Beispielen kann das ADAS-System 1138 einen Sekundärcomputer beinhalten, der ADAS-Funktionalität unter Verwendung traditioneller Regeln der Computer Vision ausführt. Als solcher kann der Sekundärcomputer die klassischen Regeln der Computer Vision (if-then) verwenden, und kann das Vorhandensein eines oder mehrerer neuronaler Netzwerke in der übergeordneten MCU die Zuverlässigkeit, Sicherheit und Leistung verbessern. Zum Beispiel machen die diverse Implementierung und die absichtliche Nicht-Identität das Gesamtsystem fehlertoleranter, speziell gegenüber Fehlern, die durch Funktionalität der Software (oder der Software-Hardware-Schnittstelle) verursacht sind. Falls beispielsweise ein Softwarefehler oder ein Fehler in der auf dem Primärcomputer laufenden Software vorliegt und der nicht identische Softwarecode, der auf dem Sekundärcomputer läuft, dasselbe Gesamtergebnis liefert, kann die übergeordnete MCU größeres Vertrauen haben, dass das Gesamtergebnis korrekt ist, und verursacht der Fehler in der Software oder Hardware auf dem Primärcomputer keinen wesentlichen Fehler.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 1138 in den Wahrnehmungsblock des Primärcomputers und/oder in den Block dynamischer Fahraufgaben des Primärcomputers eingespeist werden. Falls das ADAS-System 1138 beispielsweise eine Vorausunfallwarnung aufgrund eines sich unmittelbar voraus befindenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information verwenden, wenn Objekte identifiziert werden. In anderen Beispielen kann der Sekundärcomputer sein ein eigenes neuronales Netzwerk haben, das trainiert ist und folglich das Risiko von Falsch-Positiven reduziert, wie hierin beschrieben wurde.
  • Das Fahrzeug 102 kann darüber hinaus das Infotainment SoC 1130 (z.B. ein fahrzeuginternes Infotainmentsystem (In-Vehicle Infotainment, IVI)) beinhalten. Obwohl das Infotainmentsystem als ein SoC dargestellt und beschrieben wird, braucht das Infotainmentsystem kein SoC zu sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 1130 kann eine Kombination aus Hard- und Software beinhalten, die für die Bereitstellung von Audio (z.B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z.B. Fernsehen, Filme, Streaming usw.), Telefon (z.B. Freisprecheinrichtung), Netzwerkverbindungen (z.B., LTE, Wi-Fi usw.) und/oder Informationsdiensten (z.B. Navigationssysteme, Rückwärtseinparkunterstützung, ein Radiodatensystem, fahrzeugbezogene Informationen wie beispielsweise Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremsflüssigkeitsstand, Ölstand, Tür offen/geschlossen, Luftfilterinformationen usw.) für das Fahrzeug 102 verwendet werden können. Das Infotainment-SoC 1130 kann z.B. Radios, Plattenspieler, Navigationssysteme, Videoabspieler, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Lenkrad-Audiobedienelemente, eine Freisprech-Sprachsteuerung, eine Head-up-Anzeige (HUD), eine HMI-Anzeige 1134, eine Telematikvorrichtung, ein Bedienfeld (z.B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten beinhalten. Das Infotainment-SoC 1130 kann darüber hinaus dazu verwendet werden, Informationen (z.B. sichtbar und/oder hörbar) für einen oder mehrere Benutzer des Fahrzeugs bereitzustellen, wie beispielsweise Informationen von dem ADAS-System 1138, Informationen zum autonomen Fahren, wie beispielsweise geplante Fahrzeugmanöver, Bewegungsbahnen, Informationen zur Umgebung (z.B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Das Infotainment-SoC 1130 kann GPU-Funktionalität beinhalten. Das Infotainment-SoC 1130 kann über den Bus 1102 (z.B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 102 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 1130 mit einer übergeordneten MCU gekoppelt sein, so dass die GPU des Infotainmentsystems einige Selbstfahrfunktionen ausführen kann, falls der/die primäre(n) Steuereinrichtung(en) 1136 (z.B. die Primär- und/oder Backup-Computer des Fahrzeugs 102) ausfallen. In einem solchen Beispiel kann das Infotainment-SoC 1130 das Fahrzeug 102 in einen Chauffeur-zu-sicherem-Stopp-Modus versetzen, wie hierin beschrieben wurde.
  • Das Fahrzeug 102 kann ferner ein Kombiinstrument 1132 beinhalten (z.B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.). Das Kombiinstrument 1132 kann eine Steuereinrichtung und/oder einen Supercomputer (z.B. eine diskrete Steuereinrichtung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 1132 kann eine Reihe von Instrumenten wie beispielsweise einen Tachometer, eine Tankanzeige, eine Öldruckanzeige, einen Drehzahlmesser, einen Kilometerzähler, Blinker, eine Schaltpositionsanzeige, eine oder mehrere Gurtwarnleuchte(n), eine oder mehrere Feststellbremswarnleuchte(n), eine oder mehrere Motorstörungsleuchte(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Sicherheitssystemkontrollen, Navigationsinformationen usw. beinhalten. In einigen Beispielen können Informationen angezeigt und/oder zwischen dem Infotainment-SoC 1130 und dem Kombiinstrument 1132 gemeinsam genutzt werden. Mit anderen Worten kann das Kombiinstrument 1132 als Teil des Infotainment-SoC 1130 enthalten sein, oder umgekehrt.
  • 11 D ist ein Systemdiagramm für die Kommunikation zwischen einem oder mehreren cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 102 von 11A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das System 1176 kann einen oder mehrere Server 1178, ein oder mehrere Netzwerk(e) 1190 und Fahrzeuge, einschließlich des Fahrzeugs 102, beinhalten. Der/die Server 1178 kann/können eine Vielzahl von GPUs 1184(A)-1184(H) (hierin kollektiv als GPUs 1184 bezeichnet), PCIe-Switches 1182(A)-1182(H) (hierin kollektiv als PCIe-Switches 1182 bezeichnet) und/oder CPUs 1180(A)-1180(B) (hierin kollektiv als CPUs 1180 bezeichnet) umfassen. Die GPUs 1184, die CPUs 1180 und die PCIe-Switches können mit Hochgeschwindigkeitsverbindungen verbunden sein, wie z.B., und ohne Beschränkung darauf, die von NVIDIA entwickelten NVLink-Schnittstellen 1188 und/oder PCIe-Verbindungen 1186. In einigen Beispielen sind die GPUs 1184 über NVLink und/oder NVSwitch-SoC verbunden, und sind die GPUs 1184 und die PCIe-Switches 1182 über PCIe-Verbindungen miteinander verbunden. Obwohl acht GPUs 1184, zwei CPUs 1180 und zwei PCIe-Switches dargestellt sind, soll dies nicht beschränkend sein. Je nach Ausführungsform kann jeder der Server 1178 eine beliebige Anzahl von GPUs 1184, CPUs 1180 und/oder PCIe-Switches beinhalten. Der/die Server 1178 können beispielsweise jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1184 beinhalten.
  • Der/die Server 1178 kann/können über das/die Netzwerk(e) 1190 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder geänderte Straßenbedingungen zeigen, wie z.B. kürzlich begonnene Straßenarbeiten. Der/die Server 1178 kann/können über das/die Netzwerk(e) 1190 und an die Fahrzeuge neuronale Netzwerke 1192, aktualisierte neuronale Netzwerke 1192 und/oder Karteninformationen 1194, einschließlich Informationen über Verkehrs- und Straßenzustände, übertragen. Die Aktualisierungen der Karteninformationen 1194 können Aktualisierungen für die HD-Karte 1122 beinhalten, wie beispielsweise Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netzwerke 1192, die aktualisierten neuronalen Netzwerke 1192 und/oder die Karteninformationen 1194 aus neuem Training und/oder Erfahrungen hervorgegangen sein, die in Daten repräsentiert sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf Training basieren, die in einem Datenzentrum (z.B. unter Verwendung des/der Server(s) 1178 und/oder anderer Server) durchgeführt wurden.
  • Der/die Server 1178 kann/können dazu verwendet werden, Modelle maschinellen Lernens (z.B. neuronale Netzwerke) auf der Grundlage von Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden, und/oder können in einer Simulation (z.B. unter Verwendung einer Spiel-Engine) generiert werden. In einigen Beispielen werden die Trainingsdaten gekennzeichnet (z.B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht gekennzeichnet und/oder vorverarbeitet werden (z.B. wenn das neuronale Netzwerk kein überwachtes Lernen erfordert). Sobald die Modelle maschinellen Lernens trainiert sind, können die Modelle maschinellen Lernens von den Fahrzeugen verwendet werden (z.B. über die Netzwerk(e) 1190 an die Fahrzeuge übertragen werden, und/oder die Modelle maschinellen Lernens können von dem/den Server(n) 1178 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen können der/die Server 1178 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netzwerke zur intelligenten Echtzeit-Inferenzierung anwenden. Der/die Server 1178 können Deep Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die mit der/den GPU(s) 1184 betrieben werden, wie z.B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen kann/können der/die Server 1178 jedoch auch eine Deep Learning-Infrastruktur umfassen, die nur CPU-gestützte Datenzentren verwendet.
  • Die Deep Learning-Infrastruktur des/der Server(s) 1178 kann in der Lage sein, schnelle Echtzeit-Inferenzierung durchzuführen, und kann diese Fähigkeit dazu nutzen, den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware in dem Fahrzeug 102 zu bewerten und zu überprüfen. Zum Beispiel kann die Deep Learning-Infrastruktur periodische Aktualisierungen von dem Fahrzeug 102 empfangen, wie beispielsweise eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 102 in dieser Sequenz von Bildern lokalisiert hat (z.B. über Computer Vision und/oder andere Objektklassifizierungstechniken für maschinelles Lernen). Die Deep Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk betreiben, um die Objekte zu identifizieren und sie mit den von dem Fahrzeug 102 identifizierten Objekten zu vergleichen, und, falls die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI in dem Fahrzeug 102 fehlfunktioniert, können der/die Server 1178 ein Signal an das Fahrzeug 102 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 102 dazu anweist, die Kontrolle zu übernehmen, die Passagiere zu benachrichtigen und ein sicheres Einparkmanöver durchzuführen.
  • Zur Inferenzierung können der/die Server 1178 die GPU(s) 1184 und einen oder mehrere programmierbare Inferenzbeschleuniger (z.B. TensorRT von NVIDIA) beinhalten. Die Kombination aus GPU-betriebenen Servern und
    Inferenzbeschleunigung kann eine Echtzeit-Ansprechvermögen ermöglichen. In anderen Beispielen, in welchen beispielsweise die Leistung weniger kritisch ist, können Server, die von CPUs, FPGAs und anderen Prozessoren mit Energie versorgt werden, für Inferenzzwecke eingesetzt werden.
  • Beispielhafte Rechenvorrichtung
  • 12 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung 1200, die zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist. Die Rechenvorrichtung 1200 kann einen Bus 1202 beinhalten, der direkt oder indirekt die folgenden Einrichtungen koppelt: Speicher 1204, eine oder mehrere Zentralverarbeitungseinheiten (CPUs) 1206, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1208, eine Kommunikationsschnittstelle 1210, Eingabe-/Ausgabe (E/A)-Ports 1212, Ein-/Ausgabe-Komponenten 1214, eine Stromversorgung 1216 und eine oder mehrere Darstellungskomponenten 1218 (z.B. Anzeige(n)).
  • Obwohl die verschiedenen Blöcke von 12 als über den Bus 1202 mit Leitungen verbunden dargestellt sind, soll dies nicht beschränkend sein und dient nur der Klarheit. Beispielsweise kann in einigen Ausführungsformen eine Darstellungskomponente 1218, wie z.B. eine Anzeigevorrichtung, als eine E/A-Komponente 1214 betrachtet werden (z.B. wenn die Anzeige ein Touchscreen ist). Als ein weiteres Beispiel können die CPUs 1206 und/oder die GPUs 1208 Speicher beinhalten (z.B. kann der Speicher 1204 für eine Speichervorrichtung zusätzlich zu dem Speicher der GPUs 1208, der CPUs 1206 und/oder anderer Komponenten repräsentativ sein). Mit anderen Worten ist die Rechenvorrichtung von 12 lediglich veranschaulichend. Es wird nicht zwischen solchen Kategorien wie „Arbeitsstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung‟, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Vorrichtungs- oder Systemtypen unterschieden, da alle als im Rahmen des Rechenvorrichtung von 12 liegend betrachtet werden.
  • Der Bus 1202 kann einen oder mehrere Busse repräsentieren, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination derselben. Der Bus 1202 kann einen oder mehrere Bustypen beinhalten, wie beispielsweise einen Industry Standard Architecture (ISA)-Bus, einen Extended Industry Standard Architecture (EISA)-Bus, einen Video Electronics Standards Association (VESA-Bus), einen Peripheral Component Interconnect (PCI)-Bus, einen Peripheral Component Interconnect Express (PCIe)-Bus und/oder einen anderen Bustyp.
  • Der Speicher 1204 kann ein beliebiges einer Vielzahl von computerlesbaren Medien beinhalten. Das computerlesbare Medium kann ein beliebiges verfügbares Medium sein, auf das von der Rechenvorrichtung 1200 zugegriffen werden kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entnehmbare und nicht entnehmbare Medien beinhalten. Beispielhaft und nicht beschränkend können die computerlesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
  • Die Computer-Speichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entnehmbare und nicht entnehmbare Medien beinhalten, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Zum Beispiel kann der Speicher 1204 computerlesbare Anweisungen speichern (die z.B. ein oder mehrere Programm(e) und/oder ein oder mehrere Programmelement(e), wie beispielsweise ein Betriebssystem, repräsentieren). Computer-Speichermedien können, ohne darauf beschränkt zu sein, RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetband, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes beliebige andere Medium beinhalten, welches dazu verwendet werden kann, die gewünschten Informationen zu speichern und auf welche von der Rechenvorrichtung 1200 zugegriffen werden kann. Wie hierin verwendet, umfassen Computerspeichermedien keine Signale per se.
  • Die Kommunikationsmedien können computerlesbare Anweisungen, Datenstrukturen, Programmodule und/oder andere Datentypen in einem modulierten Datensignal wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und umfassen beliebige Informationslieferungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so festgelegt oder geändert wurden, dass Informationen in dem Signal codiert werden. Beispielhaft und nicht beschränkend können die Kommunikationsmedien drahtgebundene Medien wie beispielsweise ein drahtgebundenes Netzwerk oder eine direkt verdrahtete Verbindung sowie drahtlose Medien wie beispielsweise akustische, HF-, Infrarot- und andere drahtlose Medien beinhalten. Kombinationen von Beliebigem des Vorstehenden sollten ebenfalls in den Rahmen computerlesbarer Medien einbezogen werden.
  • Die CPU(s) 1206 kann/können dazu konfiguriert sein, die computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten der Rechenvorrichtung 1200 auszuführen, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse auszuführen. Die CPU(s) 1206 kann/können jeweils einen oder mehrere Kerne (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) beinhalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 1206 kann/können eine beliebige Art von Prozessor beinhalten, und kann/können je nach Art der implementierten Rechenvorrichtung 1200 verschiedene Typen von Prozessoren beinhalten (z.B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Je nach Typ der Rechenvorrichtung 1200 kann der Prozessor z.B. ein ARM-Prozessor sein, der unter Verwendung von Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der unter Verwendung von Complex Instruction Set Computing (CISC) implementiert ist. Die Rechenvorrichtung 1200 kann eine oder mehrere CPUs 1206 zusätzlich zu einem oder mehreren Mikroprozessoren oder ergänzenden Koprozessoren, wie z.B. mathematischen Koprozessoren, beinhalten.
  • Die GPU(s) 1208 kann/können von der Rechenvorrichtung 1200 zum Rendern von Grafiken (z.B. 3D-Grafiken) verwendet werden. Die GPU(s) 1208 kann/können Hunderte oder Tausende von Kernen beinhalten, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 1208 kann/können Pixeldaten für Ausgabebilder im Ansprechen auf Rendering-Anweisungen (z.B. Rendering-Anweisungen von der/den CPU(s) 1206, die über eine Host-Schnittstelle empfangen werden) erzeugen. Die GPU(s) 1208 kann/können Grafikspeicher, wie z.B. Anzeigespeicher, zur Speicherung von Pixeldaten beinhalten. Der Anzeigespeicher kann als Teil des Speichers 1204 enthalten sein. Die GPU(s) 708 kann/können zwei oder mehr parallel (z.B. über eine Verbindung) arbeitende GPUs beinhalten. Wenn sie miteinander kombiniert sind, kann jede GPU 1208 Pixeldaten für verschiedene Teile eines Ausgabebilds oder für verschiedene Ausgabebilder erzeugen (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher beinhalten, oder kann Speicher mit anderen GPUs gemeinsam nutzen.
  • In Beispielen, in denen die Rechenvorrichtung 1200 die GPU(s) 1208 nicht enthält, kann/können die CPU(s) 1206 zum Rendern von Grafiken verwendet werden.
  • Die Kommunikationsschnittstelle 1210 kann einen oder mehrere Empfänger, Sender und/oder Sender-Empfänger beinhalten, die es der Rechenvorrichtung 700 ermöglichen, mit anderen Computergeräten über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1210 kann Komponenten und Funktionalität beinhalten, die eine Kommunikation über ein beliebiges einer Anzahl verschiedener Netzwerke, wie beispielsweise drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z.B. Kommunikation über Ethernet), Weitverkehrsnetzwerke mit geringem Stromverbrauch (z.B. LoRaWAN, SigFox usw.) und/oder das Internet ermöglichen.
  • Die E/A-Ports 1212 können es der Rechenvorrichtung 1200 ermöglichen, logisch mit anderen Vorrichtungen einschließlich der E/A-Komponenten 1214, der Präsentationskomponente(n) 1218 und/oder anderer Komponenten, von welchen einige in die Rechenvorrichtung 1200 eingebaut (z.B. integriert) sein können, gekoppelt zu sein. Illustrative E/A-Komponenten 1214 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, eine Spielsteuereinrichtung, eine Satellitenantenne, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die E/A-Komponenten 1214 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Stimme oder andere physiologische Inputs, die von einem Benutzer erzeugt werden, verarbeitet. In einigen Fällen können Inputs zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination von Spracherkennung, Taststifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf einem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie nachstehend näher beschrieben) in Verbindung mit einer Anzeige der Rechenvorrichtung 1200 implementieren. Die Rechenvorrichtung 1200 kann Tiefenkameras, wie beispielsweise stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen derselben, zur Gestenerfassung und Gestenerkennung beinhalten. Darüber hinaus kann die Rechenvorrichtung 1200 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) beinhalten, die die Erfassung von Bewegung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Rechenvorrichtung 1200 dazu verwendet werden, immersive erweiterte Realität oder virtuelle Realität zu rendern.
  • Die Stromversorgung 1216 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination derselben beinhalten. Die Stromversorgung 1216 kann die Rechenvorrichtung 1200 mit Energie versorgen, um den Betrieb der Komponenten der Rechenvorrichtung 1200 zu ermöglichen.
  • Die eine oder mehreren Präsentationskomponente(n) 1218 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, eine Headup-Anzeige (HUD), andere Anzeigetypen oder eine Kombination derselben), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponente(n) 1218 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 1208, der/den CPU(s) 1206 usw.) empfangen und die Daten (z.B. als ein Bild, Video, Ton usw.) ausgeben.
  • Die Erfindung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen, wie z.B. Programmmodulen, beschrieben werden, die von einem Computer oder einer anderen Maschine, wie z.B. einem Assistenten für persönliche Daten oder einer anderen in der Hand zu haltenden Vorrichtung, ausgeführt werden. Allgemein beziehen sich Programmmodule, einschließlich von Routinen, Programmen, Objekten, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Erfindung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich von in der Hand zu haltenden Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Rechenvorrichtungen usw. Die Erfindung kann darüber hinaus in verteilten Computerumgebungen praktiziert werden, in denen Aufgaben durch Fernverarbeitungsvorrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk miteinander verbunden sind.
  • Wie hierin verwendet, sollte eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C beinhalten. Darüber hinaus kann „zumindest eines des Elements A oder des Elements B“ zumindest eines des Elements A, zumindest eines von Element B oder zumindest eines von Element A und zumindest eines von Element B beinhalten. Ferner kann „zumindest eines von Element A und Element B“ zumindest eines von Element A, zumindest eines von Element B oder zumindest eines von Element A und zumindest eines von Element B beinhalten.
  • Der Gegenstand der Erfindung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Erfindung nicht beschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert sein könnte, um verschiedene Schritte oder Kombinationen von Schritten, die zu den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzubeziehen. Darüber hinaus versteht sich, obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente von angewandten Verfahren zu bezeichnen, dass die Begriffe nicht so auszulegen sind, dass sie eine bestimmte Reihenfolge unter oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird explizit beschrieben.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62630445 [0021]
    • US 16246414 [0021]
    • US 16/186473 [0035]
    • US 16366506 [0037]
    • US 62644385 [0040]
    • US 62644386 [0040]
    • US 62644601 [0040]
    • US 62644806 [0040]
    • US 16354983 [0040]
    • US 16355214 [0040]
    • US 62625351 [0088]
    • US 16256780 [0088]
    • US 62628831 [0088]
    • US 16269921 [0088]
    • US 62622538 [0089]
    • US 16258272 [0089]
    • US 16/101232 [0145]

Claims (20)

  1. Verfahren, umfassend: Empfangen von Simulationsdaten, die für eine simulierte Umgebung einer Simulations-Host-Vorrichtung repräsentativ sind; zumindest teilweise basierend auf den Simulationsdaten, Erzeugen von virtuellen Sensordaten, die für die simulierte Umgebung, wie sie von zumindest einem virtuellen Sensor einer dynamisch konfigurierbaren Anzahl virtueller Sensoren wahrgenommen wird, repräsentativ sind, eines virtuellen Objekts innerhalb der simulierten Umgebung; Codieren der virtuellen Sensordaten unter Verwendung eines oder mehrerer Codecs, um codierte Sensordaten zu erzeugen; Berechnen zumindest einer Ausgabe entsprechend zumindest einer Operation des virtuellen Objekts durch ein oder mehrere Modelle maschinellen Lernens und basierend zumindest teilweise auf den codierten Sensordaten; und Übertragen von operativen Daten an die Simulations-Host-Vorrichtung, die für die zumindest eine Ausgabe an die Simulations-Host-Vorrichtung repräsentativ sind, um die Simulations-Host-Vorrichtung zu veranlassen, basierend zumindest teilweise auf der zumindest einen Aufgabe die simulierte Umgebung zu aktualisieren.
  2. Verfahren nach Anspruch 1, wobei die Simulations-Host-Vorrichtung eine von einer Vielzahl von Simulations-Host-Vorrichtungen ist, die sich ein verteiltes gemeinsam genutztes Speichersystem teilen.
  3. Verfahren nach Anspruch 2, wobei sich die Simulations-Host-Vorrichtung ferner zumindest einige Teile der simulierten Umgebung mit zumindest einer anderen Simulations-Host-Vorrichtung der Vielzahl von Simulations-Host-Vorrichtungen über das verteilte gemeinsam genutzte Speichersystem teilt.
  4. Verfahren nach Anspruch 1, wobei das virtuelle Objekt zumindest einen Roboter oder ein Fahrzeug beinhaltet.
  5. Verfahren nach Anspruch 1, wobei die Simulationsdaten virtuelle Daten und Daten der realen Welt beinhalten und die simulierte Umgebung koexistent Repräsentationen der virtuellen Daten und Repräsentationen der Daten der realen Welt beinhaltet.
  6. Verfahren nach Anspruch 1, wobei der virtuelle Sensor zumindest eines beinhaltet von: einer Kamera, einem LIDAR-Sensor, einem RADAR-Sensor, einem GNSS-Sensor, einem Geschwindigkeitssensor, einem IMU-Sensor, einem Vibrationssensor, einem Ultraschallsensor, einem Lenksensor oder einem Bremssensor.
  7. Verfahren nach Anspruch 1, wobei eine erste Instanz einer Simulations-Engine, die von der Simulations-Host-Vorrichtung ausgeführt wird, die Simulationsdaten erzeugt und eine zweite Instanz der Simulations-Engine, die von der Simulations-Host-Vorrichtung ausgeführt wird, die virtuellen Sensordaten für jeden des einen oder der mehreren virtuellen Sensoren erzeugt.
  8. Verfahren nach Anspruch 1, wobei jeder virtuelle Sensor des zumindest einen virtuellen Sensors die virtuellen Sensordaten in einer separaten Instanz einer Simulations-Engine erzeugt, die von der Simulations-Host-Vorrichtung ausgeführt wird.
  9. Verfahren nach Anspruch 1, wobei ein entsprechender Codec verwendet wird, um die virtuellen Sensordaten für jeden virtuellen Sensor zu codieren.
  10. Verfahren nach Anspruch 1, wobei jeder virtuelle Sensor einer entsprechenden Grafikverarbeitungseinheit (GPU) zugeordnet ist, die in der Simulations-Host-Vorrichtung beinhaltet ist, und jede entsprechende GPU die virtuellen Sensordaten für einen entsprechenden virtuellen Sensor erzeugt.
  11. Verfahren, umfassend: Übertragen, von einer ersten Hardware-Komponente eines Simulationssystems zu einer zweiten Hardware-Komponente des Simulationssystems, von Simulationsdaten, die für einen Teil einer simulierten Umgebung repräsentativ sind, die von der ersten Hardware-Komponente gehostet wird, wobei die Simulationsdaten zumindest einem Sichtfeld eines Sensors eines virtuellen Objekts entsprechen, das von der zweiten Hardware-Komponente gehostet wird; Empfangen, durch die erste Hardware-Komponente und von der zweiten Hardware-Komponente, von operativen Daten, die für eine dem virtuellen Objekt entsprechende Operation repräsentativ sind, wobei die operativen Daten durch die zweite Hardware-Komponente basierend zumindest teilweise auf den Simulationsdaten erzeugt werden; und Aktualisieren, durch die erste Hardware-Komponente, eines oder mehrerer Attribute des virtuellen Objekts innerhalb der simulierten Umgebung zumindest teilweise basierend auf den operativen Daten.
  12. Verfahren nach Anspruch 11, wobei zumindest eine Unterkomponente der zweiten Hardware-Komponente für den Einbau in ein autonomes Fahrzeug konfiguriert ist, das einen Software-Stack für autonomes Fahren zumindest zum Steuern des autonomen Fahrzeugs in einer realen Umgebung ausführt.
  13. Verfahren nach Anspruch 11, wobei die zweite Hardware-Komponente eine Hardware-Komponente emuliert, die für den Einbau in ein autonomes Fahrzeug konfiguriert ist, das einen Fahrsoftware-Stack für autonomes Fahren zumindest zum Steuern des autonomen Fahrzeugs in einer realen Umgebung ausführt.
  14. Verfahren nach Anspruch 11, wobei die zweite Hardware-Komponente ein Fernsteuerungssystem zur Verwendung durch einen entfernten Bediener zum Steuern des virtuellen Objekts innerhalb der simulierten Umgebung beinhaltet.
  15. Verfahren nach Anspruch 11, wobei die zweite Hardware-Komponente eine Instanz einer Simulations-Engine für jeden virtuellen Sensor des virtuellen Objekts hostet und die Simulationsdaten von der zweiten Hardware-Komponente für die Instanz der Simulations-Engine für jeden der virtuellen Sensoren verwendet werden.
  16. Verfahren nach Anspruch 11, wobei die Simulationsdaten virtuelle Daten und Daten der realen Welt beinhalten und die simulierte Umgebung koexistent Repräsentationen der virtuellen Daten und Repräsentationen der Daten der realen Welt beinhaltet.
  17. Verfahren, umfassend: Empfangen von physischen Sensordaten, die von einem physischen Sensor eines physischen Objekts erzeugt werden, wobei die physischen Sensordaten für eine physische Umgebung repräsentativ sind, wie sie von dem physischen Sensor wahrgenommen wird; Trainieren eines Modells maschinellen Lernens (MLM) unter Verwendung zumindest der physischen Sensordaten, um ein trainiertes MLM zu erzeugen; Empfangen virtueller Sensordaten, die von einem virtuellen Sensor eines virtuellen Objekts erzeugt werden, wobei die virtuellen Sensordaten für eine simulierte Umgebung repräsentativ sind, wie sie von dem virtuellen Sensor wahrgenommen wird; Anwenden der virtuellen Sensordaten auf das trainierte MLM; Berechnen einer Ausgabe durch das trainierte MLM und zumindest teilweise basierend auf den virtuellen Sensordaten; und Steuern des virtuellen Objekts innerhalb der simulierten Umgebung basierend zumindest teilweise auf der Ausgabe.
  18. Verfahren nach Anspruch 17, wobei die virtuellen Sensordaten und die physischen Sensordaten ein gleiches Format haben.
  19. Verfahren nach Anspruch 17, wobei die simulierte Umgebung unter Verwendung von Simulationsdaten erzeugt wird, die Daten der realen Welt und virtuelle Daten beinhalten, und die simulierte Umgebung koexistent Repräsentationen der virtuellen Daten und Repräsentationen der Daten der realen Welt beinhaltet.
  20. Verfahren nach Anspruch 17, wobei der physische Sensor zumindest eines einer Kamera, eines LIDAR-Sensors, eines RADAR-Sensors, eines GNSS-Sensors, eines Geschwindigkeitssensors, eines IMU-Sensors, eines Vibrationssensors, eines Ultraschallsensors, eines Lenksensors oder eines Bremssensors beinhaltet und der virtuelle Sensor eine virtuelle Repräsentation des physischen Sensors beinhaltet.
DE112019001605.9T 2018-03-27 2019-03-27 Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen Pending DE112019001605T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862648399P 2018-03-27 2018-03-27
US62/648,399 2018-03-27
US16/366,875 2019-03-27
US16/366,875 US11436484B2 (en) 2018-03-27 2019-03-27 Training, testing, and verifying autonomous machines using simulated environments
PCT/US2019/024400 WO2019191306A1 (en) 2018-03-27 2019-03-27 Training, testing, and verifying autonomous machines using simulated environments

Publications (1)

Publication Number Publication Date
DE112019001605T5 true DE112019001605T5 (de) 2020-12-17

Family

ID=68054483

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019001605.9T Pending DE112019001605T5 (de) 2018-03-27 2019-03-27 Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen

Country Status (4)

Country Link
US (2) US11436484B2 (de)
CN (1) CN111919225B (de)
DE (1) DE112019001605T5 (de)
WO (1) WO2019191306A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020119908A1 (de) 2020-07-28 2022-02-03 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Labeln von Sensordaten zur Verwendung beim Machine Learning
DE102021103367A1 (de) 2021-02-12 2022-08-18 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Erzeugung realistischer bildbasierter Daten zum Entwickeln und Testen von Fahrerassistenzsystemen
DE102022119711A1 (de) 2022-08-05 2024-02-08 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren, System und Computerprogrammprodukt zur Überprüfung von Datensätzen für das Testen und Trainieren eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)

Families Citing this family (130)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9836895B1 (en) 2015-06-19 2017-12-05 Waymo Llc Simulating virtual objects
CN111247565B (zh) * 2017-09-06 2022-06-03 瑞士再保险有限公司 用于移动远程信息处理装置的电子日志记录和跟踪检测系统及其对应方法
US10678241B2 (en) * 2017-09-06 2020-06-09 GM Global Technology Operations LLC Unsupervised learning agents for autonomous driving applications
CN108508761A (zh) * 2018-03-28 2018-09-07 惠州市德赛西威汽车电子股份有限公司 一种基于CarMaker仿真环境的AEB算法功能验证方法
US11206375B2 (en) 2018-03-28 2021-12-21 Gal Zuckerman Analyzing past events by utilizing imagery data captured by a plurality of on-road vehicles
US10671077B2 (en) * 2018-04-17 2020-06-02 Toyota Research Institute, Inc. System and method for full-stack verification of autonomous agents
US20190340317A1 (en) * 2018-05-07 2019-11-07 Microsoft Technology Licensing, Llc Computer vision through simulated hardware optimization
US20190346841A1 (en) * 2018-05-09 2019-11-14 GM Global Technology Operations LLC Method and system for remotely guiding an autonomous vehicle
US11354406B2 (en) * 2018-06-28 2022-06-07 Intel Corporation Physics-based approach for attack detection and localization in closed-loop controls for autonomous vehicles
US10901416B2 (en) * 2018-07-19 2021-01-26 Honda Motor Co., Ltd. Scene creation system for autonomous vehicles and methods thereof
US10768629B2 (en) 2018-07-24 2020-09-08 Pony Ai Inc. Generative adversarial network enriched driving simulation
JP7459794B2 (ja) * 2018-08-03 2024-04-02 日本電気株式会社 情報処理装置、情報処理方法および情報処理プログラム
US11138418B2 (en) * 2018-08-06 2021-10-05 Gal Zuckerman Systems and methods for tracking persons by utilizing imagery data captured by on-road vehicles
US10816979B2 (en) * 2018-08-24 2020-10-27 Baidu Usa Llc Image data acquisition logic of an autonomous driving vehicle for capturing image data using cameras
US11521009B2 (en) * 2018-09-04 2022-12-06 Luminar, Llc Automatically generating training data for a lidar using simulated vehicles in virtual space
US11514293B2 (en) 2018-09-11 2022-11-29 Nvidia Corporation Future object trajectory predictions for autonomous machine applications
US11341295B2 (en) * 2018-09-27 2022-05-24 Intel Corporation Methods, systems, and devices for efficient computation of simulation runs
US11040714B2 (en) * 2018-09-28 2021-06-22 Intel Corporation Vehicle controller and method for controlling a vehicle
US11762451B2 (en) * 2018-09-29 2023-09-19 Intel Corporation Methods and apparatus to add common sense reasoning to artificial intelligence in the context of human machine interfaces
US10891951B2 (en) * 2018-10-17 2021-01-12 Ford Global Technologies, Llc Vehicle language processing
US10896116B1 (en) 2018-10-19 2021-01-19 Waymo Llc Detecting performance regressions in software for controlling autonomous vehicles
US10754030B2 (en) * 2018-10-23 2020-08-25 Baidu Usa Llc Methods and systems for radar simulation and object classification
US11461963B2 (en) * 2018-11-16 2022-10-04 Uatc, Llc Systems and methods for generating synthetic light detection and ranging data via machine learning
US10824913B1 (en) * 2018-11-21 2020-11-03 Amazon Technologies, LLC Training machine learning models for physical agents and robotic controls with simulations
US10678740B1 (en) * 2018-11-21 2020-06-09 Zoox, Inc. Coordinated component interface control framework
US11087049B2 (en) * 2018-11-27 2021-08-10 Hitachi, Ltd. Online self-driving car virtual test and development system
US10922840B2 (en) * 2018-12-20 2021-02-16 Here Global B.V. Method and apparatus for localization of position data
US11214268B2 (en) * 2018-12-28 2022-01-04 Intel Corporation Methods and apparatus for unsupervised multimodal anomaly detection for autonomous vehicles
US11076022B2 (en) * 2018-12-31 2021-07-27 Lyft, Inc. Systems and methods for implementing robotics frameworks
US11656620B2 (en) * 2018-12-31 2023-05-23 Luminar, Llc Generating environmental parameters based on sensor data using machine learning
US10776542B2 (en) * 2019-01-30 2020-09-15 StradVision, Inc. Method and device for calibrating physics engine of virtual world simulator to be used for learning of deep learning-based device, and a learning method and learning device for real state network used therefor
US11548494B2 (en) * 2019-02-11 2023-01-10 Ford Global Technologies, Llc Lap learning for vehicle energy management optimization
US10860878B2 (en) * 2019-02-16 2020-12-08 Wipro Limited Method and system for synthesizing three-dimensional data
US11693417B2 (en) * 2019-03-15 2023-07-04 Volkswagen Aktiengesellschaft Generating training data using simulated environments and training machine learning models for vehicle guidance
US11153193B2 (en) * 2019-03-18 2021-10-19 Senai Networks Ltd Method of and system for testing a computer network
US11544167B2 (en) 2019-03-23 2023-01-03 Uatc, Llc Systems and methods for generating synthetic sensor data via machine learning
US11169532B2 (en) * 2019-03-26 2021-11-09 Intel Corporation Computer-assisted (CA)/autonomous driving (AD) vehicle inference model creation
US11105642B2 (en) * 2019-04-17 2021-08-31 Waymo Llc Stranding and scoping analysis for autonomous vehicle services
DE102019206212A1 (de) * 2019-04-30 2020-11-05 Ford Global Technologies, Llc Verfahren zum Durchführen von computerunterstützten Simulationen
US11280905B2 (en) * 2019-05-03 2022-03-22 Seagate Technology Llc Underwater imaging system with multiple connected autonomous underwater vehicles
EP3739361A1 (de) * 2019-05-13 2020-11-18 Aptiv Technologies Limited Verfahren und system zum fusionieren von belegungskarten
US10755691B1 (en) * 2019-05-21 2020-08-25 Ford Global Technologies, Llc Systems and methods for acoustic control of a vehicle's interior
GB201907342D0 (en) * 2019-05-24 2019-07-10 Tomtom Global Content Bv Supplementing electronic map data from user behaviour
US11391649B2 (en) * 2019-05-29 2022-07-19 Pony Ai Inc. Driving emulation system for an autonomous vehicle
US11995895B2 (en) 2019-06-03 2024-05-28 Nvidia Corporation Multi-object tracking using correlation filters in video analytics applications
US11254312B2 (en) * 2019-06-07 2022-02-22 Tusimple, Inc. Autonomous vehicle simulation system
US11138433B2 (en) * 2019-06-07 2021-10-05 The Boeing Company Cabin experience network with a sensor processing unit
US11298017B2 (en) * 2019-06-27 2022-04-12 Bao Tran Medical analysis system
US11422553B2 (en) * 2019-06-28 2022-08-23 Intel Corporation Methods and apparatus to adjust autonomous vehicle driving software using machine programming
US11069420B2 (en) * 2019-07-25 2021-07-20 Micron Technology, Inc. In-system test of a memory device
US11385610B2 (en) * 2019-08-16 2022-07-12 Exato IP LLC Stage automation system
US11829871B2 (en) * 2019-08-20 2023-11-28 Lg Electronics Inc. Validating performance of a neural network trained using labeled training data
US11340622B2 (en) * 2019-08-30 2022-05-24 Waymo Llc Determining respective impacts of agents
US11126891B2 (en) * 2019-09-11 2021-09-21 Toyota Research Institute, Inc. Systems and methods for simulating sensor data using a generative model
US11907815B1 (en) * 2019-09-26 2024-02-20 Hrl Laboratories, Llc System and method for improved generalization from concept constrained dreams
US11662985B2 (en) * 2019-10-21 2023-05-30 Woven Alpha, Inc. Vehicle developer systems, methods and devices
KR20210047477A (ko) * 2019-10-22 2021-04-30 현대자동차주식회사 오류 모니터링을 이용한 운전자 숙련용 주행 모델 생성 장치 및 방법
DE102019216836A1 (de) * 2019-10-31 2021-05-06 Psa Automobiles Sa Verfahren zum Trainieren wenigstens eines Algorithmus für ein Steuergerät eines Kraftfahrzeugs, Computerprogrammprodukt sowie Kraftfahrzeug
EP3816741B1 (de) * 2019-10-31 2023-11-29 TTTech Auto AG Sicherheitsmonitor für erweiterte fahrerassistenzsysteme
US20210133502A1 (en) * 2019-11-01 2021-05-06 The Boeing Company Computing device, method and computer program product for generating training data for a machine learning system
CN112937564B (zh) * 2019-11-27 2022-09-02 魔门塔(苏州)科技有限公司 换道决策模型生成方法和无人车换道决策方法及装置
US20210192394A1 (en) * 2019-12-19 2021-06-24 Alegion, Inc. Self-optimizing labeling platform
US20210191424A1 (en) * 2019-12-23 2021-06-24 Lyft, Inc Camera-sensor fusion module for surface detection and fleet vehicle control systems and methods
US11765067B1 (en) * 2019-12-28 2023-09-19 Waymo Llc Methods and apparatus for monitoring a sensor validator
US11687778B2 (en) 2020-01-06 2023-06-27 The Research Foundation For The State University Of New York Fakecatcher: detection of synthetic portrait videos using biological signals
US11922292B2 (en) 2020-01-27 2024-03-05 Google Llc Shared scratchpad memory with parallel load-store
KR20210106807A (ko) * 2020-02-21 2021-08-31 현대자동차주식회사 노면 분류 장치 및 이를 이용한 차량의 터레인 모드 제어 시스템
US20230084761A1 (en) * 2020-02-21 2023-03-16 Edge Case Research, Inc. Automated identification of training data candidates for perception systems
US20210266368A1 (en) * 2020-02-25 2021-08-26 Level 3 Communications, Llc Disaggregated & Distributed Composable Infrastructure
US20210286924A1 (en) 2020-03-11 2021-09-16 Aurora Innovation, Inc. Generating autonomous vehicle simulation data from logged data
US11493625B2 (en) * 2020-03-16 2022-11-08 Nio Technology (Anhui) Co., Ltd. Simulated LiDAR devices and systems
DE102020107776A1 (de) 2020-03-20 2021-09-23 Bayerische Motoren Werke Aktiengesellschaft Trainieren eines automatischen Erkennungssystems
US11403437B2 (en) 2020-03-25 2022-08-02 Ford Global Technologies, Llc Method and system for determining sensor placement for a workspace
US11364883B2 (en) * 2020-03-27 2022-06-21 Nvidia Corporation Leveraging rear-view sensors for automatic emergency braking in autonomous machine applications
US11676291B1 (en) 2020-04-20 2023-06-13 Everguard, Inc. Adaptive multimodal safety systems and methods
US11675878B1 (en) 2020-04-30 2023-06-13 Everguard, Inc. Auto-labeling method for multimodal safety systems
US11803955B1 (en) 2020-04-30 2023-10-31 Everguard, Inc. Multimodal safety systems and methods
WO2021231229A1 (en) * 2020-05-13 2021-11-18 National Instruments Corporation System for emulating an environment for testing a frequency modulated continuous wave (fmcw) light detection and ranging (l1dar) system
CN113687316A (zh) 2020-05-17 2021-11-23 是德科技股份有限公司 用于仿真测试系统的时间同步和等待时间补偿
CN111723907B (zh) * 2020-06-11 2023-02-24 浪潮电子信息产业股份有限公司 一种模型训练设备、方法、系统及计算机可读存储介质
JP2023529679A (ja) * 2020-06-12 2023-07-11 ユニバーシティ オブ ワシントン 接眼ディスプレイ内での眼追跡
KR20210155179A (ko) * 2020-06-15 2021-12-22 삼성전자주식회사 전자 장치 및 그 제어 방법
US20210406562A1 (en) * 2020-06-24 2021-12-30 Keysight Technologies, Inc. Autonomous drive emulation methods and devices
US11989020B1 (en) * 2020-07-14 2024-05-21 Aurora Operations, Inc. Training machine learning model(s), in simulation, for use in controlling autonomous vehicle(s)
JP7408815B2 (ja) 2020-07-30 2024-01-05 株式会社安川電機 機械学習データ生成装置、機械学習装置、機械学習モデルの生成方法及びプログラム
EP3951673A1 (de) * 2020-08-04 2022-02-09 Aptiv Technologies Limited Verfahren und system zum sammeln von trainingsdaten, die zum trainieren eines systems zum autonomen fahren eines fahrzeugs geeignet sind
US11420647B2 (en) 2020-08-13 2022-08-23 Argo AI, LLC Enhanced static object classification using lidar
EP3958129A1 (de) * 2020-08-17 2022-02-23 Volvo Car Corporation Verfahren und system zur validierung einer software für die autonome steuerung für ein selbstfahrendes fahrzeug
US11809790B2 (en) * 2020-09-22 2023-11-07 Beijing Voyager Technology Co., Ltd. Architecture for distributed system simulation timing alignment
US11755469B2 (en) 2020-09-24 2023-09-12 Argo AI, LLC System for executing structured tests across a fleet of autonomous vehicles
CN112052183B (zh) * 2020-09-28 2023-07-07 英博超算(南京)科技有限公司 一种基于虚拟车辆平台的中间件调试方法
DE102020212505A1 (de) 2020-10-02 2022-04-07 Ford Global Technologies, Llc Erzeugen eines vereinfachten Modells für XiL-Systeme
US20220126445A1 (en) * 2020-10-28 2022-04-28 Nvidia Corporation Machine learning model for task and motion planning
CN112286206B (zh) * 2020-11-17 2024-01-23 苏州智加科技有限公司 自动驾驶的模拟方法、系统、设备、可读存储介质及平台
DE102020215017A1 (de) * 2020-11-30 2022-06-02 Siemens Mobility GmbH Verfahren zum Testen eines Objekterkennungssystems
CN112445728B (zh) * 2020-11-30 2023-07-21 中科院软件研究所南京软件技术研究院 一种支持多种硬件接口的机器人开发板ros通讯系统
DE102020215657A1 (de) * 2020-12-10 2022-06-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und System zum Testen eines Steuergeräts eines Fahrzeugs
US11807233B1 (en) * 2020-12-23 2023-11-07 Zoox, Inc. Procedurally generated safety system determination
US20220204009A1 (en) * 2020-12-29 2022-06-30 Waymo Llc Simulations of sensor behavior in an autonomous vehicle
WO2022146742A1 (en) * 2020-12-30 2022-07-07 Robocars Inc. Systems and methods for testing, training and instructing autonomous vehicles
CN112925223B (zh) * 2021-02-03 2022-03-15 北京航空航天大学 基于视觉传感网络的无人机三维跟踪虚拟测试仿真系统
US20220264255A1 (en) * 2021-02-15 2022-08-18 Craig Walden Grass Network unilateral communication location electronic underpinning system
KR20220117625A (ko) * 2021-02-17 2022-08-24 한국기술교육대학교 산학협력단 자율형 cps의 성능 자가진화를 위한 연합 강화학습 기반의 자율형 cps 자가진화 프레임워크 및 이를 이용한 자율형 cps의 성능 자가진화 방법
GB2604100A (en) * 2021-02-17 2022-08-31 Continental Automotive Gmbh System and method for training neural network for geographical information
EP4047483A1 (de) * 2021-02-23 2022-08-24 Aptiv Technologies Limited Computerkarte zur prüfung von fahrzeuginterner software
CN113066112B (zh) * 2021-03-25 2021-10-22 泰瑞数创科技(北京)有限公司 一种基于三维模型数据的室内外融合方法及装置
US11858514B2 (en) 2021-03-30 2024-01-02 Zoox, Inc. Top-down scene discrimination
US11810225B2 (en) * 2021-03-30 2023-11-07 Zoox, Inc. Top-down scene generation
US11775909B2 (en) * 2021-03-31 2023-10-03 Caterpillar Inc. Monitoring operator condition using sensor data
WO2022221268A1 (en) * 2021-04-12 2022-10-20 Visualaim Llc Techniques for automated component classification
WO2022226238A1 (en) * 2021-04-21 2022-10-27 Nvidia Corporation End-to-end evaluation of perception systems for autonomous systems and applications
US20220340153A1 (en) * 2021-04-22 2022-10-27 Gm Cruise Holdings Llc Simulated test creation
US11714190B1 (en) 2021-05-11 2023-08-01 Waymo Llc Methods and systems for radar testing and development using hardware-in-the-loop with continuous integration
AU2022286690A1 (en) * 2021-06-02 2023-12-07 Bae Systems Plc Method and apparatus for control
EP4098547A1 (de) * 2021-06-02 2022-12-07 BAE SYSTEMS plc Verfahren und vorrichtung zur steuerung
US20220402520A1 (en) * 2021-06-16 2022-12-22 Waymo Llc Implementing synthetic scenes for autonomous vehicles
TWI821998B (zh) * 2021-07-09 2023-11-11 台達電子工業股份有限公司 離線式軟體在環模擬的開發系統及離線式軟體在環模擬方法
US11947886B2 (en) 2021-07-09 2024-04-02 Delta Electronics, Inc. Development system and method of offline software-in-the-loop simulation
CN113676368B (zh) * 2021-07-12 2022-07-19 交控科技股份有限公司 一种运用于ats网络性能测试的方法及装置
DE102021208472B3 (de) * 2021-08-04 2022-12-01 Continental Autonomous Mobility Germany GmbH Computerimplementiertes Verfahren zum Trainieren eines Machine-Learning-Modells für ein Fahrzeug oder einen Roboter
EP4141679A1 (de) * 2021-08-26 2023-03-01 Siemens Aktiengesellschaft Verwalten einer app, insbesondere testen der einsatzfähigkeit einer app mit einer trainierten funktion unter verwendung einer virtuellen testumgebung, verfahren und system
CN113705102B (zh) * 2021-08-31 2024-05-10 湖南苍树航天科技有限公司 海空集群对抗的推演仿真系统及方法、设备、存储介质
CN113484851B (zh) * 2021-09-08 2021-11-16 北京理工大学深圳汽车研究院(电动车辆国家工程实验室深圳研究院) 车载激光雷达的仿真测试系统、方法和整车在环测试系统
CN114061941B (zh) * 2021-10-18 2023-12-19 吉林大学 一种新能源车辆变速箱的实验环境调节试验方法、系统以及试验箱
WO2023092579A1 (en) * 2021-11-29 2023-06-01 Siemens Aktiengesellschaft Method and apparatus for simulating deployment for ai model, storage medium, and electronic device
US20230297096A1 (en) * 2022-03-18 2023-09-21 Microsoft Technology Licensing, Llc Machine learning design for long-term reliability and stress testing
US11704698B1 (en) 2022-03-29 2023-07-18 Woven By Toyota, Inc. Vehicle advertising system and method of using
DE102022111744A1 (de) 2022-05-11 2023-11-16 Bayerische Motoren Werke Aktiengesellschaft Computerimplementiertes Verfahren zum Erstellen einer Route für eine Kampagne zum Sammeln von Daten, Datenverarbeitungsvorrichtung, Server und Kraftfahrzeug
DE102022204862A1 (de) * 2022-05-17 2023-11-23 Robert Bosch Gesellschaft mit beschränkter Haftung Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten
US11810574B1 (en) * 2022-11-15 2023-11-07 Leslie Helpert Voice-driven internal physiological imaging

Family Cites Families (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001051970A (ja) * 1999-08-04 2001-02-23 Yamaha Motor Co Ltd ユーザ認識度成長システム
US7852462B2 (en) 2000-05-08 2010-12-14 Automotive Technologies International, Inc. Vehicular component control methods based on blind spot monitoring
US7068815B2 (en) 2003-06-13 2006-06-27 Sarnoff Corporation Method and apparatus for ground detection and removal in vision systems
US7409295B2 (en) 2004-08-09 2008-08-05 M/A-Com, Inc. Imminent-collision detection system and process
US8164628B2 (en) 2006-01-04 2012-04-24 Mobileye Technologies Ltd. Estimating distance to an object using a sequence of images recorded by a monocular camera
EP2383679A1 (de) 2006-12-06 2011-11-02 Mobileye Technologies Limited Detektion und Erkennung von Verkehrszeichen
US7787969B2 (en) * 2007-06-15 2010-08-31 Caterpillar Inc Virtual sensor system and method
JP4462333B2 (ja) 2007-11-13 2010-05-12 株式会社デンソー 走行支援装置
CA2721375C (en) 2008-04-14 2016-11-29 Google Inc. Panning using virtual surfaces
KR101717787B1 (ko) 2010-04-29 2017-03-17 엘지전자 주식회사 디스플레이장치 및 그의 음성신호 출력 방법
KR101225626B1 (ko) 2010-07-19 2013-01-24 포항공과대학교 산학협력단 차선 인식 시스템 및 방법
US9547509B2 (en) * 2012-02-23 2017-01-17 Samsung Electronics Co., Ltd. System and method for information acquisition of wireless sensor network data as cloud based service
US9256222B2 (en) * 2012-07-18 2016-02-09 International Business Machines Corporation Sensor virtualization through cloud storage and retrieval mechanisms
US9489635B1 (en) * 2012-11-01 2016-11-08 Google Inc. Methods and systems for vehicle perception feedback to classify data representative of types of objects and to request feedback regarding such classifications
CN104424466B (zh) 2013-08-21 2018-05-15 佳能株式会社 对象检测方法、对象检测设备及图像拾取设备
US9373057B1 (en) 2013-11-01 2016-06-21 Google Inc. Training a neural network to detect objects in images
CN103677838A (zh) * 2013-12-17 2014-03-26 北京奥特美克科技股份有限公司 基于虚拟传感器的rtu传感器适配层及其设计方法
EP2950175B1 (de) * 2014-05-27 2021-03-31 dSPACE digital signal processing and control engineering GmbH Verfahren und Vorrichtung zum Testen eines Steuergerätes
US20160210775A1 (en) * 2015-01-21 2016-07-21 Ford Global Technologies, Llc Virtual sensor testbed
US20160210382A1 (en) * 2015-01-21 2016-07-21 Ford Global Technologies, Llc Autonomous driving refined in virtual environments
EP3885217A1 (de) 2015-02-10 2021-09-29 Mobileye Vision Technologies Ltd. Spärliche karte für autonome fahrzeugnavigation
US9811756B2 (en) 2015-02-23 2017-11-07 Mitsubishi Electric Research Laboratories, Inc. Method for labeling images of street scenes
US11630800B2 (en) 2015-05-01 2023-04-18 Nvidia Corporation Programmable vision accelerator
WO2016183074A1 (en) 2015-05-10 2016-11-17 Mobileye Vision Technologies Ltd. Road profile along a predicted path
US10002471B2 (en) 2015-09-30 2018-06-19 Ants Technology (Hk) Limited Systems and methods for autonomous vehicle navigation
US10176634B2 (en) * 2015-10-16 2019-01-08 Ford Global Technologies, Llc Lane boundary detection data generation in virtual environment
DE102015221920A1 (de) 2015-11-09 2017-05-11 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Computerprogrammprodukt, Vorrichtung, und Fahrzeug umfassend die Vorrichtung zum Steuern einer Trajektorienplanung eines Egofahrzeugs
US9740944B2 (en) * 2015-12-18 2017-08-22 Ford Global Technologies, Llc Virtual sensor data generation for wheel stop detection
DE102015226762B4 (de) 2015-12-28 2024-04-25 Robert Bosch Gmbh Verfahren zur Korrektur mindestens eines Kollisionsparameters und korrespondierendes integriertes Sicherheitssystem für ein Fahrzeug
US10134278B1 (en) 2016-01-22 2018-11-20 State Farm Mutual Automobile Insurance Company Autonomous vehicle application
US9996771B2 (en) 2016-02-15 2018-06-12 Nvidia Corporation System and method for procedurally synthesizing datasets of objects of interest for training machine-learning models
US9802599B2 (en) 2016-03-08 2017-10-31 Ford Global Technologies, Llc Vehicle lane placement
JP6575818B2 (ja) 2016-03-25 2019-09-18 パナソニックＩｐマネジメント株式会社 運転支援方法およびそれを利用した運転支援装置、自動運転制御装置、車両、運転支援システム、プログラム
US9896096B2 (en) 2016-04-11 2018-02-20 David E. Newman Systems and methods for hazard mitigation
US10032067B2 (en) 2016-05-28 2018-07-24 Samsung Electronics Co., Ltd. System and method for a unified architecture multi-task deep learning machine for object recognition
CN106114507B (zh) 2016-06-21 2018-04-03 百度在线网络技术（北京）有限公司 用于智能车辆的局部轨迹规划方法和装置
US10354157B2 (en) 2016-06-27 2019-07-16 Mobileye Vision Technologies Ltd. Controlling host vehicle based on detection of a one-way road
WO2018002910A1 (en) 2016-06-28 2018-01-04 Cognata Ltd. Realistic 3d virtual world creation and simulation for training automated driving systems
GB2553782B (en) 2016-09-12 2021-10-20 Niantic Inc Predicting depth from image data using a statistical model
US10127670B2 (en) 2016-09-27 2018-11-13 Xactware Solutions, Inc. Computer vision systems and methods for detecting and modeling features of structures in images
US10289469B2 (en) 2016-10-28 2019-05-14 Nvidia Corporation Reliability enhancement utilizing speculative execution systems and methods
US20180136332A1 (en) 2016-11-15 2018-05-17 Wheego Electric Cars, Inc. Method and system to annotate objects and determine distances to objects in an image
WO2018102717A1 (en) 2016-12-02 2018-06-07 Google Llc Determining structure and motion in images using neural networks
US20180158244A1 (en) * 2016-12-02 2018-06-07 Ayotle Virtual sensor configuration
WO2018126228A1 (en) 2016-12-30 2018-07-05 DeepMap Inc. Sign and lane creation for high definition maps used for autonomous vehicles
US10691847B2 (en) * 2017-01-13 2020-06-23 Sap Se Real-time damage determination of an asset
US11288595B2 (en) 2017-02-14 2022-03-29 Groq, Inc. Minimizing memory and processor consumption in creating machine learning models
US10146225B2 (en) * 2017-03-02 2018-12-04 GM Global Technology Operations LLC Systems and methods for vehicle dimension prediction
US10209718B2 (en) 2017-03-14 2019-02-19 Starsky Robotics, Inc. Vehicle sensor system and method of use
US11899669B2 (en) 2017-03-20 2024-02-13 Carnegie Mellon University Searching of data structures in pre-processing data for a machine learning classifier
US10460180B2 (en) 2017-04-20 2019-10-29 GM Global Technology Operations LLC Systems and methods for visual classification with region proposals
US10108867B1 (en) 2017-04-25 2018-10-23 Uber Technologies, Inc. Image-based pedestrian detection
US10310087B2 (en) 2017-05-31 2019-06-04 Uber Technologies, Inc. Range-view LIDAR-based object detection
US20180349746A1 (en) 2017-05-31 2018-12-06 Uber Technologies, Inc. Top-View Lidar-Based Object Detection
CN107506830A (zh) * 2017-06-20 2017-12-22 同济大学 面向智能汽车规划决策模块的人工智能训练平台
US10007269B1 (en) 2017-06-23 2018-06-26 Uber Technologies, Inc. Collision-avoidance system for autonomous-capable vehicle
US11214273B2 (en) 2017-06-23 2022-01-04 Nvidia Corporation Method of using a single controller (ECU) for a fault-tolerant/fail-operational self-driving system
US20180373980A1 (en) 2017-06-27 2018-12-27 drive.ai Inc. Method for training and refining an artificial intelligence
US11188794B2 (en) 2017-08-10 2021-11-30 Intel Corporation Convolutional neural network framework using reverse connections and objectness priors for object detection
US10339669B2 (en) 2017-08-22 2019-07-02 Here Global B.V. Method, apparatus, and system for a vertex-based evaluation of polygon similarity
US11487988B2 (en) * 2017-08-31 2022-11-01 Ford Global Technologies, Llc Augmenting real sensor recordings with simulated sensor data
US10901423B2 (en) * 2017-09-01 2021-01-26 International Business Machines Corporation Generating driving behavior models
KR102026697B1 (ko) 2017-09-21 2019-09-30 엘지전자 주식회사 주행 시스템 및 차량
US10579897B2 (en) 2017-10-02 2020-03-03 Xnor.ai Inc. Image based object detection
US10997491B2 (en) * 2017-10-04 2021-05-04 Huawei Technologies Co., Ltd. Method of prediction of a state of an object in the environment using an action model of a neural network
US10599546B1 (en) * 2017-10-25 2020-03-24 Uatc, Llc Autonomous vehicle testing systems and methods
US20190129831A1 (en) * 2017-10-27 2019-05-02 Uber Technologies, Inc. Autonomous Vehicle Simulation Testing Systems and Methods
US10580158B1 (en) 2017-11-03 2020-03-03 Zoox, Inc. Dense depth estimation of image data
JP7346401B2 (ja) 2017-11-10 2023-09-19 エヌビディア コーポレーション 安全で信頼できる自動運転車両のためのシステム及び方法
US11017550B2 (en) 2017-11-15 2021-05-25 Uatc, Llc End-to-end tracking of objects
US11062461B2 (en) 2017-11-16 2021-07-13 Zoox, Inc. Pose determination from contact points
US10762396B2 (en) 2017-12-05 2020-09-01 Utac, Llc Multiple stage image based object detection and recognition
CN110574371B (zh) 2017-12-08 2021-12-21 百度时代网络技术（北京）有限公司 使用硬件加速器的立体摄像机深度确定
US20190179979A1 (en) * 2017-12-13 2019-06-13 Uber Technologies, Inc. Simulated Sensor Testing
WO2019136375A1 (en) 2018-01-07 2019-07-11 Nvidia Corporation Guiding vehicles through vehicle maneuvers using machine learning models
US11789449B2 (en) 2018-02-09 2023-10-17 Nvidia Corporation Controlling autonomous vehicles using safe arrival times
US10816978B1 (en) * 2018-02-22 2020-10-27 Msc.Software Corporation Automated vehicle artificial intelligence training based on simulations
US10157331B1 (en) 2018-03-08 2018-12-18 Capital One Services, Llc Systems and methods for image preprocessing to improve accuracy of object recognition
US10942030B2 (en) 2018-08-17 2021-03-09 Lyft, Inc. Road segment similarity determination
US10625748B1 (en) 2019-06-28 2020-04-21 Lyft, Inc. Approaches for encoding environmental information

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020119908A1 (de) 2020-07-28 2022-02-03 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Labeln von Sensordaten zur Verwendung beim Machine Learning
DE102021103367A1 (de) 2021-02-12 2022-08-18 Iav Gmbh Ingenieurgesellschaft Auto Und Verkehr Erzeugung realistischer bildbasierter Daten zum Entwickeln und Testen von Fahrerassistenzsystemen
DE102022119711A1 (de) 2022-08-05 2024-02-08 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren, System und Computerprogrammprodukt zur Überprüfung von Datensätzen für das Testen und Trainieren eines Fahrerassistenzsystems (ADAS) und/oder eines automatisierten Fahrsystems (ADS)

Also Published As

Publication number Publication date
CN111919225A (zh) 2020-11-10
US20190303759A1 (en) 2019-10-03
WO2019191306A1 (en) 2019-10-03
US20230004801A1 (en) 2023-01-05
US11436484B2 (en) 2022-09-06
CN111919225B (zh) 2024-03-26

Similar Documents

Publication Publication Date Title
DE112019001605T5 (de) Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen
DE112021000213T5 (de) Szenarien für virtuelle Umgebungen und Beobachter für Anwendungen autonomer Maschinen
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE112020004139T5 (de) Erstellung von karten und lokalisierung für anwendungen im bereich des autonomen fahrens
DE112020000369T5 (de) Objekterfassung unter verwendung von verzerrten polygonen, die zur parkplatzerfassung geeignet ist
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE112019000279T5 (de) Steuern autonomer fahrzeuge anhand sicherer ankunftszeiten
DE112019006468T5 (de) Erkennung des abstands zu hindernissen bei anwendungen mit autonomen maschinen
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
DE102021126254A1 (de) Überwachen der Aufmerksamkeit und der kognitiven Belastung der Insassen für autonome und halbautonome Fahranwendungen
DE102020117792A1 (de) Wirksames einsetzen von hindernis- und spurerkennungen, um spurzuweisungen für objekte in einer umgebung zu bestimmen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE112020001897T5 (de) Trainieren neuronaler Netze unter Verwendung von Grundwahrheitsdaten, die mit Karteninformationen ergänzt wurden, für autonome Maschinenanwendungen
DE102021100065A1 (de) Verwendung neuronaler netze zur fehlererkennung bei anwendungen für autonomes fahren
DE102021117456A1 (de) Systeme und verfahren zur risikobewertung und gerichteten warnung bei fussgängerüberwegen
DE112020000413T5 (de) Detektion von orientierungspunkten unter verwendung von kurvenanpassung für anwendungen für autonomes fahren
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE112020001400T5 (de) Iterative erzeugung räumlicher graphen
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE102020100685A1 (de) Vorhersage zeitlicher informationen in autonomenmaschinenanwendungen
DE112020006181T5 (de) Blickbestimmung mit blendung als eingabe
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed