DE102022124361A1 - Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen - Google Patents

Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen Download PDF

Info

Publication number
DE102022124361A1
DE102022124361A1 DE102022124361.3A DE102022124361A DE102022124361A1 DE 102022124361 A1 DE102022124361 A1 DE 102022124361A1 DE 102022124361 A DE102022124361 A DE 102022124361A DE 102022124361 A1 DE102022124361 A1 DE 102022124361A1
Authority
DE
Germany
Prior art keywords
data
sensor data
visibility
vehicle
instance
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
DE102022124361.3A
Other languages
English (en)
Inventor
Abhishek Bajpayee
Arjun Gupta
George Tang
Hae-Jong Seo
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 DE102022124361A1 publication Critical patent/DE102022124361A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/08Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B60W30/095Predicting travel path or likelihood of collision
    • B60W30/0956Predicting travel path or likelihood of collision the prediction being responsive to traffic or environmental parameters
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00Scenes; Scene-specific elements
    • G06V20/50Context or environment of the image
    • G06V20/56Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/08Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B60W30/09Taking automatic action to avoid collision, e.g. braking and steering
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W40/00Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models
    • B60W40/02Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models related to ambient conditions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00Pattern recognition
    • G06F18/20Analysing
    • G06F18/21Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/214Generating training patterns; Bootstrap methods, e.g. bagging or boosting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • G06N20/10Machine learning using kernel methods, e.g. support vector machines [SVM]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • G06N20/20Ensemble learning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00Computing arrangements based on biological models
    • G06N3/02Neural networks
    • G06N3/04Architecture, e.g. interconnection topology
    • G06N3/044Recurrent networks, e.g. Hopfield networks
    • G06N3/0442Recurrent networks, e.g. Hopfield networks characterised by memory or gating, e.g. long short-term memory [LSTM] or gated recurrent units [GRU]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00Computing arrangements based on biological models
    • G06N3/02Neural networks
    • G06N3/04Architecture, e.g. interconnection topology
    • G06N3/0464Convolutional networks [CNN, ConvNet]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00Computing arrangements based on biological models
    • G06N3/02Neural networks
    • G06N3/04Architecture, e.g. interconnection topology
    • G06N3/047Probabilistic or stochastic networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00Computing arrangements based on biological models
    • G06N3/02Neural networks
    • G06N3/08Learning methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00Computing arrangements based on biological models
    • G06N3/02Neural networks
    • G06N3/08Learning methods
    • G06N3/09Supervised learning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00Computing arrangements using knowledge-based models
    • G06N5/01Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00Computing arrangements based on specific mathematical models
    • G06N7/01Probabilistic graphical models, e.g. probabilistic networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00Arrangements for image or video recognition or understanding
    • G06V10/70Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/77Processing image or video features in feature spaces; using data integration or data reduction, e.g. principal component analysis [PCA] or independent component analysis [ICA] or self-organising maps [SOM]; Blind source separation
    • G06V10/774Generating sets of training patterns; Bootstrap methods, e.g. bagging or boosting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00Arrangements for image or video recognition or understanding
    • G06V10/70Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/82Arrangements for image or video recognition or understanding using pattern recognition or machine learning using neural networks
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2555/00Input parameters relating to exterior conditions, not covered by groups B60W2552/00, B60W2554/00
    • B60W2555/20Ambient conditions, e.g. wind or rain

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Software Systems (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Computational Linguistics (AREA)
  • Biomedical Technology (AREA)
  • Molecular Biology (AREA)
  • Biophysics (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Probability & Statistics with Applications (AREA)
  • Databases & Information Systems (AREA)
  • Algebra (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Image Analysis (AREA)
  • Measurement Of Optical Distance (AREA)
  • Closed-Circuit Television Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

In verschiedenen Beispielen werden Systeme und Verfahren offenbart, die ein oder mehrere Modelle für maschinelles Lernen (MLMs) - wie zum Beispiel Deep Neural Networks (DNNs) - verwenden, um Ausgaben zu berechnen, die eine geschätzte Sichtweite angeben, die Sensordaten entspricht, die mit einem oder mehreren Sensoren einer autonomen oder halbautonomen Maschine erzeugt wurden. Sobald die Sichtweite unter Verwendung des einen oder der mehreren MLMs berechnet wurde, kann die Verwendbarkeit der Sensordaten für eine oder mehrere nachgelagerte Aufgaben der Maschine bewertet werden. Wenn die geschätzte Sichtweite gering ist, können die entsprechenden Sensordaten für weniger Aufgaben verwendet werden als bei einer hohen Sichtweite.

Description

  • HINTERGRUND
  • Autonome Fahrsysteme und teilautonome Fahrsysteme (z. B. fortschrittliche Fahrerassistenzsysteme (advanced driver assistance systems, ADAS) können Sensoren (z. B. Kameras, LiDAR-Sensoren, RADAR-Sensoren usw.) einsetzen, um verschiedene Aufgaben auszuführen - z. B. ein Überwachen eines toten Winkels, ein automatisches Notbremsen, ein Halten der Fahrspur, ein Erkennen von Objekten, ein Umfahren von Hindernissen und eine Lokalisierung. Damit autonome und ADAS-Systeme unabhängig und effizient arbeiten können, kann beispielsweise ein Verständnis der Umgebung des Fahrzeugs in Echtzeit oder nahezu in Echtzeit erzeugt werden. Um die Umgebung des Fahrzeugs genau und effizient zu verstehen, müssen die Sensoren verwertbare, klare Sensordaten erzeugen (z. B. in Form von Bildern, Tiefenkarten, Punktwolken usw.). Die Fähigkeit eines Sensors, die umgebende Umwelt wahrzunehmen, kann jedoch durch eine Vielzahl von Faktoren beeinträchtigt werden, wie z. B. Wetter (z. B. Regen, Nebel, Schnee, Hagel, Rauch usw.), Verkehrsbedingungen, Blockierung eines Sensors (z. B. durch Schmutz, Feuchtigkeit usw.) oder Unschärfe. Infolgedessen können die resultierenden Sensordaten Fahrzeuge, Hindernisse und/oder andere Objekte in der Umgebung nicht klar abbilden.
  • Herkömmliche Systeme zum Umgang mit beeinträchtigten Sichtweiten haben Ansätze auf Merkmalsebene verwendet, um einzelne Teile visueller Hinweise zu erkennen, und diese Merkmale anschließend zusammengesetzt, um zu bestimmen, dass eine beeinträchtigte Sicht vorliegt. Diese konventionellen Verfahren beruhen in erster Linie auf Computer-Vision-Techniken - z. B. durch Analysieren des Fehlens von scharfen Kantenmerkmalen (z. B. scharfe Änderungen in Gradient, Farbe, Intensität) in Bereichen des Bildes, unter Verwendung einer farbbasierten Pixelanalyse oder einer anderen Low-Level-Merkmalanalyse, um potenzielle Sichtprobleme zu erkennen, und/oder einer binären Support-Vector-Machine-Klassifizierung mit einer blinden gegenüber einer nicht blinden Ausgabe. Solche merkmalsbasierten Computer-Vision-Techniken erfordern jedoch eine separate Analyse von jedem Merkmal - z. B. ob jedes Merkmal für die Sicht relevant ist oder nicht - sowie eine Analyse, wie die verschiedenen Merkmale für eine reduzierte Sichtbedingung eines bestimmten Sensor zu kombinieren sind, wodurch die Skalierbarkeit solcher Ansätze aufgrund der Komplexität eingeschränkt wird, die der großen Vielfalt und Diversität von Bedingungen und Ereignissen inhärent ist, die die Daten beeinträchtigen können, die mit Sensoren in Situationen der realen Welt beobachtet werden. Zum Beispiel sind diese herkömmlichen Ansätze aufgrund des hohen Rechenaufwands für den Einsatz in Echtzeit oder nahezu in Echtzeit ungeeignet.
  • Ferner können sich herkömmliche Systeme auf ein Klassifizieren der Ursachen für eine eingeschränkte Sensorsicht verlassen - wie Regen, Schnee, Nebel, Blendung usw. - liefern aber möglicherweise keinen genauen Hinweis auf die Verwendbarkeit der Sensordaten. Zum Beispiel kann ein Erkennen von Regen in einem Bild für das System nicht geeignet sein, um zu bestimmen, ob das entsprechende Bild - oder ein Teil davon - für verschiedene autonome oder halbautonome Aufgaben verwendbar ist. In einem solchen Beispiel, in dem Regen vorhanden ist, kann das Bild von konventionellen Systemen als unbrauchbar angesehen werden, obwohl das Bild die Umgebung in einem Umkreis von 100 Metern um das Fahrzeug klar darstellen kann. Anstatt sich auf das Bild für eine oder mehrere Aufgaben innerhalb des Sichtbereichs zu verlassen, kann das Bild fälschlicherweise verworfen werden und die eine oder mehrere Aufgaben können deaktiviert werden. Auf diese Weise kann durch die gleiche Behandlung aller Arten von beeinträchtigter Sensorsicht eine Instanz von Sensordaten als unbrauchbar eingestuft werden, selbst wenn diese Bestimmung nicht ganz korrekt ist (z. B. kann ein Bild einer Umgebung, in der leichter Nieselregen vorhanden ist, für eine oder mehrere Aufgaben verwendet werden, während ein Bild einer Umgebung mit dichtem Nebel nicht verwendet werden kann).
  • ZUSAMMENFASSUNG
  • Ausführungsformen der vorliegenden Offenbarung betreffen eine Verarbeitung mit einem Deep Neural Network für eine Schätzung einer Sichtweite - z. B. einer weitesten Entfernung von einem Sensor, in der Objekte oder Elemente erkannt werden können - in autonomen Maschinenanwendungen. Es werden Systeme und Verfahren offenbart, die ein oder mehrere Modelle des maschinellen Lernens (Machine Learning) - wie Deep Neural Networks (DNNs) - verwenden, um Ausgaben zu berechnen, die eine geschätzte Sichtweite (z. B. in Form eines berechneten Abstands oder eines Abstandsbereichs, der einen Bereich von Abständen enthält) anzeigen, die einem oder mehreren Sensoren einer autonomen oder halbautonomen Maschine entsprechen. Zum Beispiel kann durch ein Vorhersagen einer geschätzten Sichtweite das Vertrauen der Maschine auf zugehörige Sensordaten für eine oder mehrere nachgelagerte Aufgaben - wie Objekterkennung, Objektverfolgung, Hindernisumgehung, Pfadplanung, Steuerungsentscheidungen und/oder dergleichen - angepasst werden. Beispielsweise können, wenn eine geschätzten Sichtweite gering ist, - z. B. 20 Meter oder weniger - die entsprechenden Sensordaten nur für Aufgaben der Stufe 0 (keine Automatisierung) oder der Stufe 1 (Fahrerassistenz) herangezogen werden (z. B. gemäß den Automatisierungsstufen der Society of Automotive Engineers (SAE)), oder sie können nur für Vorhersagen herangezogen werden, die sich innerhalb von 20 Metern von der Maschine befinden (und Vorhersagen jenseits von 20 Metern können z. B. unberücksichtigt bleiben oder eine geringere Zuverlässigkeit aufweisen). Ähnlich kann als weiteres Beispiel, wenn eine geschätzten Sichtweite groß ist, - z. B. 1000 Meter oder mehr - auf die entsprechenden Sensordaten für die vollständige Durchführung von Aufgaben der Stufen 3 (bedingte Fahrautomatisierung) und der Stufe 4 (hohe Fahrautomatisierung) vertraut werden, oder es kann auf Vorhersagen vertraut werden, die sich auf Orte innerhalb von 1000 Metern um die Maschine beziehen.
  • Auf diese Weise und im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, können die Systeme und Verfahren der vorliegenden Offenbarung nicht nur dazu verwendet werden, eine Verwendbarkeit von Sensordaten zu bestimmen, sondern auch, um ein Niveau oder einen Grad der Verwendbarkeit der Sensordaten zu bestimmen, wie sie durch eine Sichtweite - oder einen Sichtweitenbereich mit zugehörigen Bereichen von Sichtweiten - definiert sind. Um ein Modell für maschinelles Lernen - z. B. ein DNN - zu trainieren, um genaue Ausgaben zu berechnen, die die Sichtweite darstellen, kann das DNN unter Verwendung von Daten aus der realen Welt (real-world data), erweiterten Daten aus der realen Welt (augmented real-world data) und/oder synthetischen Daten trainiert werden, die Sensordatendarstellungen (z. B. Bilder, LiDAR-Punktwolken usw.) einschließlich unterschiedlicher Wetter-, Beleuchtungs- und/oder anderer Bedingungen darstellen. Jede Sensordateninstanz kann entsprechende Grundwahrheitsdaten (Ground-Truth-Data) aufweisen, die eine Sichtweite und/oder einen Sichtweitenbereich darstellen. In einigen Ausführungsformen können die Ground-Truth-Daten automatisch unter Verwendung eines oder mehrerer trainierter Modelle erzeugt werden, so dass für bestimmte Parameter - z. B. Nebeldichte, Regennässe, Regenintensität usw. - eine bekannte oder geschätzte Sichtweite vorhanden ist. Als solches kann ein robuster Trainingssatz unter Verwendung des einen oder mehrerer Modelle erzeugt werden (z.B. können verschiedene Modelle verschiedenen Sensordatentypen entsprechen, wie z.B. realen, erweiterten und/oder synthetischen), und das Modell des maschinellen Lernens kann unter Verwendung der Kombination aus den Trainingsdaten und den zugeordneten Ground-Truth-Daten trainiert werden.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren für die Verarbeitung von Deep Neural Networks zum Schätzen von Sichtweiten in autonomen Maschinenanwendungen werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen detailliert beschrieben, wobei:
    • 1 ein Datenflussdiagramm ist, das einen Prozess zum Trainieren eines Modells für maschinelles Lernen veranschaulicht, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 2A-2C Beispielvisualisierungen von Sensordaten mit unterschiedlichen Sichtweiten sind, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 3 ein Flussdiagramm ist, das ein Verfahren zum Trainieren eines Modells für maschinelles Lernen veranschaulicht, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 4 ein Datenflussdiagramm ist, das einen Prozess für den Einsatz eines Modells für maschinelles Lernen veranschaulicht, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 5 eine Beispielvisualisierung von Sensordaten und entsprechenden Sichtweitenausgaben für verschiedene Objekte ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 6 ein Flussdiagramm ist, das ein Verfahren zum Einsetzen eines Modells für maschinelles Lernen veranschaulicht, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;^
    • 7A eine Darstellung eines Beispiels eines autonomen Fahrzeugs ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7B ein Beispiel für Kamerapositionen und Sichtfelder für das Beispiel eines autonomen Fahrzeugs aus 7A ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7C ein Blockdiagramm eines Beispiels einer Systemarchitektur für das Beispiel eines autonomen Fahrzeugs von 7A ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7D ein Systemdiagramm für eine Kommunikation zwischen einem oder mehreren Cloud-basierten Servern und dem Beispiel für ein autonomes Fahrzeug aus 7A ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8 ein Blockdiagramm eines Beispiels einer Rechenvorrichtung ist, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
    • 9 ein Blockdiagramm eines Beispiels eines Rechenzentrums ist, das für eine Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Systeme und Verfahren werden in Bezug auf eine Deep Neural Network Verarbeitung für eine Abschätzung einer Sichtweite in autonomen Maschinenanwendungen offenbart. Obwohl die vorliegende Offenbarung in Bezug auf ein Beispiel für ein autonomes Fahrzeug 700 (hier alternativ als „Fahrzeug 700“ oder „Ego-Fahrzeug 700“ bezeichnet, von dem ein Beispiel in Bezug auf die 7A-7D beschrieben ist), ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können die hier beschriebenen Systeme und Verfahren ohne Einschränkung von nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z.B. in einem oder mehreren fortschrittlichen Fahrerassistenzsystemen (ADAS)), gelenkten und ungelenkten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, Fahrzeugen, die mit einem oder mehreren Anhängern gekoppelt sind, fliegenden Fahrzeugen, Booten, Pendelfahrzeugen, Notarzteinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Außerdem, obwohl die vorliegende Offenbarung in Bezug auf eine Abschätzung der Sichtweite in autonomen oder halbautonomen Maschinenanwendungen beschrieben wird, soll dies nicht einschränkend sein, und die hier beschriebenen Systeme und Verfahren können in den Bereichen erweiterte Realität (augmented reality), virtuelle Realität, gemischte Realität, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenanwendungen und/oder in jedem anderen Technologiebereich verwendet werden, in dem der Zustand und die Verwendbarkeit von Sensordaten analysiert werden kann.
  • TRAINIEREN EINES MODELLS FÜR MASCHINELLES LERNEN, UM SICHTWEITEN ZU BERECHNEN
  • Unter Bezugnahme auf 1 ist 1 ein Datenflussdiagramm, das einem Beispielprozess 100 zum Trainieren eines Modells für maschinelles Lernen für Schätzungen von Sichtweiten entspricht, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es sollte klar sein, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargelegt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Gruppierungen von Funktionen usw.) können zusätzlich zu den oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene Funktionen, die hier als von Einheiten ausgeführt beschrieben werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in einem Speicher gespeicherte Befehle ausführt. In einigen Ausführungsformen können die hierin beschriebenen Systeme, Verfahren und Prozesse unter Verwendung ähnlicher Komponenten, Merkmale und/oder Funktionen ausgeführt werden, wie die des autonomen Beispielfahrzeugs 700 der 7A-7D, der beispielhaften Recheneinrichtung 800 von 8 und/oder des beispielhaften Rechenzentrums 900 von 9.
  • Das/die Modell(e) für maschinelles Lernen 104 kann/können unter Verwendung von Trainingsdaten 102 - wie beispielsweise Sensordaten 102A, erweiterte Daten 102B, und/oder synthetische Daten 102C - trainiert werden. Zum Beispiel können die Sensordaten 102A Sensordaten aus der realen Welt entsprechen, die mit einem oder mehreren Sensoren der Ego-Maschine 700 erzeugt wurden, wie beispielsweise Stereokameras 768, RADAR-Sensoren 760, Ultraschallsensoren 762, LiDAR-Sensoren 764, Weitwinkelkameras 770, Surround-Kameras 774, andere Sensoren der Ego-Maschine 700 und/oder andere Sensortypen. Zum Beispiel können die Sensordaten 102A mit einem oder mehreren Datenerfassungsfahrzeugen gesammelt werden, die verschiedene Arten von Sensordaten 102A unter verschiedenen Bedingungen sammeln, wie z.B. unter verschiedenen Wetter-, Beleuchtungs-, Verdeckungs- und/oder anderen Bedingungen. Da ein Erzeugen eines hinreichend vielfältigen Trainingsdatensatzes unter Verwendung von Sensordaten 102A allein unpraktisch und/oder unerschwinglich teuer sein kann, können in Ausführungsformen zusätzlich zu oder alternativ zu den Sensordaten 102A der realen Welt erweiterte Daten 102B und/oder synthetische Daten 102C erzeugt werden.
  • Die erweiterten Daten 102B können Sensordaten 102A aus der realen Welt entsprechen, die erweitert werden - z. B. um verschiedene Wetter-(Nebel, Schnee, Regen, Schneeregen usw.), Beleuchtungs- (Dunkelheit, Sonne, auf den Sensor scheinende Sonne usw.), Verdeckungs- und/oder andere Bedingungen einzubeziehen - um Sensordaten zu simulieren, die unter verschiedenen Bedingungen erfasst wurden, die von den tatsächlichen Bedingungen abweichen, unter denen die Sensordaten 102A ursprünglich erfasst wurden. Wenn beispielweise die Sensordaten 102A unter Schönwetterbedingungen erfasst wurden, können die Sensordaten 102A unter Einbeziehung von Regen, Nebel, Schnee und/oder anderen Bedingungen ergänzt werden, um die erweiterten Sensordaten 102B zu erzeugen. Als weiteres Beispiel, bei dem die Sensordaten 102A bei leichtem Regen erfasst wurden, können die Sensordaten 102A erweitert werden, um zusätzlich zu dem leichten Regen stärkeren Regen und/oder Nebel einzubeziehen. Um dies zu tun, können in Ausführungsformen verschiedene Niveaus von Regen (z. B. Nieselregen, starker Regen usw.), Nebel (z. B. dichter Nebel, leichter Nebel usw.), Schnee (z. B. starker Schnee, leichter Schnee, Schneegestöber usw.) und/oder andere Bedingungen (z. B. verschiedene Sonnenstandorte, um verschiedene Lichtbedingungen für den/die Sensor(en) zu schaffen) angewendet werden, um die erweiterten Daten 102B zu erzeugen. So können Werte, die Parametern entsprechen, die eine oder mehrere Bedingungen steuern, bestimmt werden - z.B. manuell, automatisch und/oder zufällig - um die erweiterten Daten 102B zu erzeugen. Zum Beispiel können Werte für einen Parameter der Nebeldichte, einen Parameter der Regenintensität und/oder einen anderen Parameter für eine andere Bedingung bestimmt werden, und die Sensordaten 102A können auf der Grundlage der Werte erweitert werden, um die erweiterten Daten 102B zu erzeugen.
  • Die synthetischen Daten 102C können Sensordaten entsprechen, die unter Verwendung eines oder mehrerer virtueller Sensoren (z. B. Kameras, LiDAR-Sensoren, RADAR-Sensoren usw.) einer oder mehrerer virtueller Maschinen (z. B. einer virtuellen Instanz des Fahrzeugs 700) innerhalb einer virtuellen Umgebung erzeugt wurden (z. B. einer virtuellen Kamera eines virtuellen Fahrzeugs innerhalb einer virtuellen oder simulierten Umgebung). Zum Beispiel kann eine Simulations- oder Spielmaschine verwendet werden, um simulierte Umgebungen für die virtuelle Maschine zu erzeugen, und die virtuellen Sensoren können synthetische Daten 102C aus der simulierten Umgebung zur Verwendung als Trainingsdaten 102 erzeugen. Um simulierte oder virtuelle Umgebungen zu erzeugen, die verschiedenen Bedingungen entsprechen - z. B. Wetter, Beleuchtung, Verdeckung usw. - können Werte für Parameter, die verschiedenen Bedingungen entsprechen, manuell, automatisch und/oder zufällig eingestellt werden, um eine Vielfalt von synthetischen Daten 102C zu erzeugen. Darüber hinaus können Straßenanordnungen (z. B. Anzahl der Fahrspuren, Krümmung, Höhenänderung usw.), Verkehrsbedingungen, umgebende Umweltbedingungen, Landschaften, Orte und/oder Arten von Objekten und/oder andere Faktoren in der virtuellen Umgebung ausgewählt oder zufällig gesetzt werden, um die Trainingsdaten 102 unter Verwendung der synthetischen Daten 102C weiter zu diversifizieren.
  • Um die erweiterten Daten 102B und die synthetischen Daten 102C zu kalibrieren, um Kohärenz zwischen den beiden und damit genauere Trainingsdaten 102 sicherzustellen, können die Erweiterungs- und Simulationsparameter kalibriert werden. Dies kann die Wahrscheinlichkeit erhöhen, dass Daten, die unter Verwendung von Erweiterung und Simulation mit der gleichen Sichtweitebezeichnung erzeugt wurden, visuell gleich oder ähnlich sind. Um die Kalibrierung durchzuführen, können in Ausführungsformen eine Instanz von erweiterten Daten 102B und eine Instanz von synthetischen Daten 102C sorgfältig ausgesucht werden, die ein Objekt in einem gleichen Abstand enthalten, der der Sichtweite entspricht. Für jede Instanz kann ein Paar von erweiterten Instanzen und ein Paar von synthetischen Instanzen im Abstand von (beispielsweise und ohne Einschränkung) +2 Metern und im Abstand von (beispielsweise und ohne Einschränkung) -2 Metern erzeugt werden. Ein Prüfer kann dann feststellen, ob das Zielobjekt in beiden Instanzen der erweiterten Daten 102B und beiden Instanzen der synthetischen Daten 102C sichtbar ist. Gemäß Ausführungsformen können in solchen beispielhaften Szenarien die Parameter so lange eingestellt werden, bis das Objekt im Abstand von -2 Metern sichtbar ist und im Abstand von +2 Metern nicht mehr sichtbar ist. So können für eine gleiche Sichtweite die Parameter für Regen, Schnee, Nebel usw. so eingestellt werden, dass die resultierenden Trainingsdaten für synthetische oder erweiterte Daten visuell ähnlich sind.
  • In Ausführungsformen können die Trainingsdaten 102 Originaldaten 102A, 102B und/oder 102C, abwärts abgetastete (down-sampled) Daten, aufwärts abgetastete (up-sampled) Daten, abgeschnittene (cropped) Daten oder Daten eines interessierenden Bereichs (Region of Interest, ROI), gespiegelte oder gedrehte Daten, anderweitig erweiterte Daten und/oder eine Kombination davon enthalten, um den Trainingsdatensatz weiter zu diversifizieren und die Robustheit des Trainingsdatensatzes zu erhöhen.
  • Die Trainingsdaten 102 - zusätzlich zu entsprechenden Ground-Truth-Daten, die unter Verwendung eines Ground-Truth-Generators 116 erzeugt werden - können verwendet werden, um das/die Modell(e) für maschinelles Lernen 104 zu trainieren, um Ausgaben 106 zu berechnen (z. B. Sichtweiten 108, Abstandsbereiche 110 und/oder Sichtweiten-Klassifikationen und/oder Attribute 112). Obwohl hier Beispiele in Bezug auf eine Verwendung von Deep Neural Networks (DNNs) und insbesondere von faltenden neuronalen Netzen (Convolutional Neural Networks, CNNs) als Modell(e) für maschinelles Lernen 104 beschrieben werden, ist dies nicht als Einschränkung zu verstehen. Beispielsweise und ohne Einschränkung können das/die Modell(e) für maschinelles Lernen 104 jede Art von Modell für maschinelles Lernen umfassen, wie z. B. ein Modell für maschinelles Lernen unter Verwendung von linearer Regression, logistischer Regression, Entscheidungsbäumen, Support-Vector-Maschinen (SVM), Naive Bayes, k-nächster Nachbar (k nearest neighbor, Knn), K-means-clustering, Random Forest, Dimensionalitätsreduktionsalgorithmen, Gradient-Verstärkungsalgorithmen, neuronalen Netzen (z. B, Autocodierer, faltende (convolutional), rekurrente, Perzeptronen, Lang-/Kurzzeitspeicher (long/short term memory, LSTM), Hopfield, Boltzmann, Deep Belief, deconvolutional, generative adversariale, Liquid State Machine usw.), Algorithmen für maschinelles Sehen und/oder andere Arten von Modellen für maschinelles Lernen.
  • Als ein Beispiel, z. B. wenn das/die Modell(e) für maschinelles Lernen 104 ein CNN umfasst/umfassen, kann/können das/die Modell(e) für maschinelles Lernen 104 eine beliebige Anzahl von Schichten aufweisen. Eine oder mehrere der Schichten können eine Eingabeschicht enthalten. Die Eingabeschicht kann Werte halten, die den Trainingsdaten 102 (oder Sensordaten 402, im Einsatz) zugeordnet sind (z. B. vor oder nach einer Nachbearbeitung). Wenn die Trainingsdaten beispielsweise ein Bild darstellen, kann die Eingabeschicht Werte halten, die die rohen Pixelwerte des Bildes/der Bilder als ein Volumen darstellen (z. B. eine Breite, eine Höhe und Farbkanäle (z. B. RGB), wie 32 × 32 × 3).
  • Eine oder mehrere Schichten können faltende Schichten (convolutional layers) enthalten. Die faltenden Schichten können die Ausgabe von Neuronen berechnen, die mit lokalen Bereichen in einer Eingabeschicht verbunden sind, wobei jedes Neuron ein Skalarprodukt zwischen seinen Gewichten und einem kleinen Bereich berechnet, mit dem es in dem Eingabevolumen verbunden ist. Ein Ergebnis der faltenden Schichten kann ein weiteres Volumen sein, wobei eine der Dimensionen auf der Anzahl von angewandten Filtern basiert (z. B. die Breite, die Höhe und die Anzahl von Filtern, wie z. B. 32 × 32 × 12, wenn 12 die Anzahl von Filtern wäre).
  • Eine oder mehrere Schichten können dekonvolutionale Schichten (deconvolutional layers) (oder transponierte faltende Schichten) enthalten. Ein Ergebnis der dekonvolutionalen Schichten kann z.B. ein weiteres Volumen sein, mit einer höheren Dimensionalität als die Eingangsdimensionalität von Daten, die in der dekonvolutionalen Schicht empfangen werden.
  • Eine oder mehrere der Schichten können eine Schicht mit gleichgerichteter linearer Einheit (rectified linear unit (ReLU) layer) enthalten. Die ReLU-Schicht(en) kann/können eine elementweise Aktivierungsfunktion anwenden, wie z. B. max (0, x), wobei der Schwellenwert beispielsweise bei Null liegt. Das sich ergebende Volumen einer ReLU-Schicht kann das gleiche sein wie das Volumen der Eingabe der ReLU-Schicht.
  • Eine oder mehrere der Schichten können eine Pooling-Schicht enthalten. Die Pooling-Schicht kann eine Downsampling-Operation entlang der räumlichen Dimensionen (z. B. Höhe und Breite) durchführen, was zu einem kleineren Volumen als die Eingabe der Pooling-Schicht führen kann (z. B. 16 × 16 × 12 aus dem 32 × 32 × 12-Eingabevolumen).
  • Eine oder mehrere der Schichten können eine oder mehrere vollständig verbundene Schicht(en) (fully connected layer(s)) enthalten. Jedes Neuron in der/den vollständig verbundenen Schicht(en) kann mit jedem der Neuronen in dem vorhergehenden Volumen verbunden sein. Die vollständig verbundene Schicht kann Klassenbewertungen berechnen, und das resultierende Volumen kann 1 × 1 × n sein, wobei n gleich der Anzahl der Klassen ist. In einigen Beispielen kann das CNN eine oder mehrere vollständig verbundene Schichten aufweisen, so dass die Ausgabe einer oder mehrerer Schichten des CNN als Eingabe für eine oder mehrere vollständig verbundene Schichten des CNN bereitgestellt werden kann. In einigen Beispielen können ein oder mehrere faltende Ströme (convolutional streams) mittels des/der Modells/Modelle für maschinelles Lernen 104 implementiert werden, und einige oder alle der faltenden Ströme können eine entsprechende vollständig verbundene Schicht(en) enthalten.
  • In einigen nicht-einschränkenden Ausführungsformen kann das Modell für maschinelles Lernen 104 eine Reihe von faltenden Schichten und Max-Pooling-Schichten umfassen, um eine Extraktion von Bildmerkmalen zu unterstützen, gefolgt von multiskalen erweiterten faltenden (multi-scale dilated convolutional) und Up-Sampling-Schichten, um eine Extraktion globaler Kontextmerkmale zu ermöglichen.
  • Obwohl hier Eingabeschichten, faltende Schichten, Pooling-Schichten, ReLU-Schichten und vollständig verbundene Schichten in Bezug auf das/die Modell(e) für maschinelles Lernen 104 erörtert werden, ist dies nicht als Einschränkung anzusehen. Zum Beispiel können zusätzliche oder alternative Schichten in dem/den Modell(en) für maschinelles Lernen 104 verwendet werden, wie Normalisierungsschichten, SoftMax-Schichten und/oder andere Schichttypen.
  • Zusätzlich können einige der Schichten Parameter (z.B. Gewichte und/oder Biases) enthalten, wie z.B. die faltenden Schichten und die vollständig verbundenen Schichten, während andere dies nicht tun, wie z.B. die ReLU-Schichten und Pooling-Schichten. In einigen Beispielen können die Parameter mittels des/der Modells/Modelle für maschinelles Lernen 104 während des Trainings gelernt werden. Ferner können einige der Schichten zusätzliche Hyperparameter enthalten (z. B. Lernrate, Schrittweite, Epochen usw.), wie z. B. die faltenden Schichten, die vollständig verbundenen Schichten und die Pooling-Schichten, während dies andere Schichten nicht können, wie z. B. die ReLU-Schichten. In Ausführungsformen, in denen das/die Modell(e) für maschinelles Lernen 104 auf Sichtweiten regressieren, kann die Aktivierungsfunktion einer letzten Schicht des CNN eine ReLU-Aktivierungsfunktion enthalten. In Ausführungsformen, in denen das/die Modell(e) für maschinelles Lernen 104 Instanzen von Sensordaten in einen Abstandsbereich 110 klassifiziert, kann die Aktivierungsfunktion einer letzten Schicht des CNN eine SoftMax-Aktivierungsfunktion aufweisen. Die Parameter und Hyperparameter sollen nicht eingeschränkt sein und können je nach Ausführungsform unterschiedlich sein.
  • In Ausführungsformen, in denen das/die Modell(e) für maschinelles Lernen 104 ein CNN aufweisen, können abhängig von der Ausführungsform unterschiedliche Reihenfolgen und Anzahlen der Schichten des CNN verwendet werden. Mit anderen Worten, die Reihenfolge und Anzahl von Schichten des CNN ist nicht auf eine bestimmte Architektur beschränkt.
  • Zum Beispiel kann das CNN in einer oder mehreren Ausführungsformen eine Kodierer-Dekodierer-Architektur aufweisen und/oder einen oder mehrere Ausgabeköpfe aufweisen. Zum Beispiel kann das CNN eine oder mehrere Schichten enthalten, die einem Merkmalserkennungsstamm des CNN entsprechen, und die Ausgaben des Merkmalserkennungsstammes (z. B. Merkmalskarten, sog. feature maps) können mit einem oder mehreren Ausgabeköpfen verarbeitet werden. Zum Beispiel kann ein erster Ausgabekopf (der eine oder mehrere erste Schichten enthält) verwendet werden, um die Sichtweite 108 zu berechnen, ein zweiter Ausgabekopf (der eine oder mehrere zweite Schichten enthält) kann verwendet werden, um den/die Abstandsbereich(e) 110 zu berechnen, und/oder ein dritter Ausgabekopf bzw. dritte Ausgabeköpfe (der/die eine oder mehrere dritte Schichten enthält/enthalten) kann/können verwendet werden, um die Sichtweiten-Klassifikationen/Attribute 112 zu berechnen. Wenn beispielsweise zwei oder mehr Köpfe verwendet werden, können die zwei oder mehr Köpfe die Daten des Stammes parallel verarbeiten, und jeder Kopf kann trainiert werden, um die entsprechende(n) Ausgabe(n) dieses Ausgabekopfes genau vorherzusagen. In anderen Ausführungsformen kann jedoch auch ein einziger Stamm ohne separate Köpfe verwendet werden.
  • Der Ground-Truth-Generator 116 kann verwendet werden, um Bezeichnungen oder Anmerkungen 118 der realen Welt als Ground-Truth-Daten zu erzeugen, die den Sensordaten 102A der realen Welt entsprechen. Zum Beispiel können für die Sensordaten 102A, die in einer realen Umgebung - ohne Erweiterung - erzeugt wurden, die Bezeichnungen oder Anmerkungen der realen Welt den Sichtweitebezeichnungen entsprechen, die die Sichtweite für jede Instanz der Sensordaten 102A angeben. Wenn die Bezeichnungen oder Anmerkungen 118 der realen Welt verwendet werden, um die Ground-Truth-Daten zu erzeugen, können die Anmerkungen oder Bezeichnungen in einem Zeichenprogramm (z. B. einem Anmerkungsprogramm), einem Programm für computergestütztes Design (CAD), einem Beschriftungsprogramm oder einer anderen Art von Programm erzeugt werden, das für die Erzeugung der Anmerkungen geeignet ist, und/oder sie können in einigen Beispielen von Hand gezeichnet werden. In einem Beispiel können die Ground-Truth-Daten synthetisch erzeugt werden (z. B. aus Computermodellen oder Renderings erzeugt werden), real erzeugt werden (z. B. aus realen Daten entworfen und erzeugt werden), maschinell automatisiert werden (z. B. unter Verwendung von Merkmalsanalyse und Lernen, um Merkmale aus Daten zu extrahieren und dann Bezeichnungen zu erzeugen), von Menschen angemerkt werden (z. B. legt ein Experte für Bezeichnungen oder Anmerkungen die Position der Bezeichnungen fest) und/oder eine Kombination davon sein (z. B. identifiziert ein Mensch ein Objekt, das sichtbar ist, ein Computer bestimmt eine Entfernung zum Objekt und eine entsprechende Sichtweite).
  • Die Bezeichnungen der realen Welt 118 können einer tatsächlichen Sichtweite entsprechen - z.B. in Metern, Fuß, etc. - und/oder können Abstandsbereichen entsprechen (z. B. kann jeder Abstandsbereich einen Bereich von Sichtweitenwerten aufweisen). Werden beispielsweise Abstandsbereiche verwendet, können die Abstandsbereiche ohne Einschränkung einen ersten Bereich für sehr geringe Sichtweite (z. B. <10 m), einen zweiten Bereich für geringe Sichtweite (z. B. zwischen 10 m und 100 m), einen dritten Bereich für mittlere Sichtweite (z. B. zwischen 100 m und 1000 m), einen vierten Bereich für hohe Sichtweite (z. B. zwischen 1000 m und 4000 m) und einen fünften Bereich für klare Sicht (z. B. über 4000 m) umfassen. Obwohl hier fünf Bereiche aufgelistet sind, ist dies nicht als Einschränkung zu verstehen, und es kann eine beliebige Anzahl von Abstandsbereichen mit beliebigen Wertebereichen verwendet werden, ohne den Umfang der vorliegenden Offenbarung zu verlassen. Als solches können die Sensordaten 102A für eine gegebene Instanz der Sensordaten 102A mit einem Sichtweite- und/oder einem Abstandsbereich bezeichnet werden, und diese Werte können verwendet werden, um sie - z. B. unter Verwendung von Verlustfunktion(en) 114 - mit den Ausgaben 106 des maschinellen Lernmodells bzw. der maschinellen Lernmodelle 104 während des Trainings zu vergleichen. In einigen Fällen können das/die Modell(e) des maschinellen Lernens 104 auch trainiert werden, um Sichtweiten-Klassifikationen und/oder Attribute 112 zu berechnen - z. B. entsprechend einer Ursache für die verringerte Sichtweite, sofern vorhanden. In anderen Fällen können das/die Modell(e) des maschinellen Lernens 104 zusätzlich oder alternativ zu den Sichtweiten-Klassifikationen trainiert werden, um Sensorblindheitsklassifikationen zu berechnen, die beeinträchtigten Sensordaten entsprechen (z. B. Regentropfen auf einer Kameralinse, Schnee, der den Sensor blockiert, usw.) In solchen Fällen können die Ground-Truth-Daten und -Ausgaben denen ähnlich sein, die in der U.S. Non-Provisional Application No. 16/570,187 beschrieben sind, die am 13. September 2019 eingereicht wurde und hiermit durch Bezugnahme in vollem Umfang aufgenommen wird.
  • Um die Sichtweite und/oder den Abstandsbereich für eine bestimmte Instanz der Sensordaten 102A zu bestimmen, können statische und/oder dynamische Objektpositionen verwendet werden. Zum Beispiel können in einigen Fällen ein oder mehrere Tiefen- oder Abstandswerte für Objekte in der Umgebung unter Verwendung eines oder mehrerer maschineller Lernverfahren, Computer Vision, Tiefensensoren und/oder anderer Ausgaben bestimmt werden, und diese Tiefen- oder Abstandswerte können verwendet werden, um die Sichtweiteninformationen für die Instanz der Sensordaten 102A zu bestimmen. In Bezug auf 2A, unter der Annahme, dass die Visualisierung 200A (die einen starken Regen aufweist) einer Instanz der Sensordaten 102A (z. B. einem Bild von einer Kamera eines Datenerfassungsfahrzeugs) entspricht, kann (können) ein (mehrere) Tiefenwert(e) für das Fahrzeug 202A auf der Grundlage einer Ausgabe eines Tiefensensors (z. B. LiDAR, RADAR usw.), einer Ausgabe eines maschinellen Lernmodells oder eines neuronalen Netzes, einer Ausgabe eines Computer-Vision-Algorithmus und/oder eines anderen Ausgabentyps bekannt sein. In einem solchen Beispiel kann das Datenerfassungsfahrzeug, während das Datenerfassungsfahrzeug die Instanz der Sensordaten 102A, die das Fahrzeug 202A einschließen, erzeugt, einen oder mehrere zugrunde liegende Prozesse zur Bestimmung von Tiefen- oder Abstandsinformationen zu Objekten in der Umgebung ausgeführt haben. Wenn das Fahrzeug 202A das am weitesten vom Datenerfassungsfahrzeug entfernte sichtbare Objekt war und die Tiefe zu dem Fahrzeug 202A bekannt ist, kann daher die Sichtweite für die Instanz der Sensordaten 102A der Tiefe oder der Entfernung zu dem Fahrzeug 202A entsprechen (z. B. zuzüglich einer zusätzlichen Entfernung, in der die Umgebung jenseits des Fahrzeugs 202A sichtbar ist, oder abzüglich einer Entfernung, in der das Fahrzeug 202A geringfügig sichtbar oder unscharf ist, in Ausführungsformen). In ähnlicher Weise kann bei der Visualisierung 200B (die leichten Regen aufweist) das Fahrzeug 202B sichtbar sein, und daher kann die Sichtweite und/oder der Abstandsbereich unter Verwendung von Tiefen- oder Abstandswerten bestimmt werden, die dem Fahrzeug 202B entsprechen.
  • In einigen Ausführungsformen kann zusätzlich oder alternativ zur Verwendung von Tiefenausgaben von Sensoren, Modellen für maschinelles Lernen, Computer-Vision-Algorithmen usw. eine hochauflösende (high definition, HD) Karte verwendet werden, um Abstände oder Tiefen zu statischen Objekten in einer Umgebung zu bestimmen. Wenn beispielsweise Lokalisierungstechniken verwendet werden, um das Datenerfassungsfahrzeug in Bezug auf die HD-Karte zu lokalisieren, können identifizierbare oder sichtbare Objekte in der Umgebung mit bekannten Entfernungen von einem lokalisierten Standort des Datenerfassungsfahrzeugs verwendet werden, um die Sichtweite für eine bestimmte Instanz der Sensordaten 102A zu bestimmen. Wenn beispielsweise ein Verkehrsschild, ein Baum, eine Straßenlaterne, eine Kreuzung, ein Gebäude und/oder ein statisches Merkmal in der Instanz der Sensordaten 102A sichtbar ist und der Abstand zu dem Objekt oder Merkmal nach der Lokalisierung aus der HD-Karte bekannt ist, kann so der Abstand oder die Tiefe als Sichtweite und/oder zur Bestimmung des Abstandsbereichs verwendet werden.
  • In einigen Ausführungsformen kann diese Bestimmung der Ground-Truth-Bezeichnung für die Sichtweite und/oder den Abstandsbereich manuell durchgeführt werden. Zum Beispiel kann ein menschlicher Kommentator ein am weitesten entferntes Objekt bestimmen, das in einer Instanz von Sensordaten 102A sichtbar ist, den zugehörigen Abstands- oder Tiefenwert für dieses Objekt bestimmen und die Ground-Truth entsprechend erzeugen. In anderen Ausführungsformen kann die Bestimmung der Ground-Truth-Bezeichnung für die Sichtweite und/oder den Abstandsbereich automatisch ausgeführt werden, so dass ein Tiefen- oder Abstandswert für ein Objekt, das unter Verwendung einer Tiefensensorausgabe, eines Modells für maschinelles Lernen, eines DNN, eines Computer-Vision-Algorithmus, einer HD-Karte usw. identifiziert wird, der am größten ist (z. B. der die weiteste Entfernung von dem Datenerfassungsfahrzeug aufweist), als Sichtweitenwert verwendet werden kann und/oder verwendet werden kann, um den Abstandsbereich für die Instanz der Sensordaten 102A zu bestimmen.
  • Um die Ground-Truth-Daten für die erweiterten Daten 102B zu erzeugen, kann in Ausführungsformen ein ähnlicher Prozess wie für die Sensordaten 102A verwendet werden. Zum Beispiel können bekannte Abstands- oder Tiefenwerte für die Objekte in der Umgebung verwendet werden, um die Sichtweite und/oder Abstandsbereiche zu bestimmen. Zusätzlich oder alternativ kann ein Modell trainiert werden, um eine Entsprechung oder Abbildung zwischen Werten für Parameter der Erweiterung und der Sichtweite und/oder den Abstandsbereichen zu bestimmen. Zum Beispiel können Werte für Nebelparameter (z. B. Dichte, Höhe usw.) verwendet werden, um die Sensordaten 102A zu erweitern und erweiterte Daten 102B zu erzeugen. Die Instanz der erweiterten Daten 102B kann dann analysiert werden (z. B. unter Verwendung bekannter Tiefenwerte für sichtbare Objekte nach der Erweiterung), um die Sichtweite und/oder Abstandsbereiche zu bestimmen. Dieser Prozess kann für eine beliebige Anzahl von Instanzen der erweiterten Daten 102B wiederholt werden, bis das Modell trainiert ist, um Sichtweiten und/oder Abstandsbereiche basierend auf den Werten der Parameter für die Erweiterung zu berechnen. Sobald das Modell trainiert ist, kann dieses Modell verwendet werden, um automatisch eine Ground-Truth für die automatisch generierten erweiterten Daten zu erzeugen. Zum Beispiel können die Werte für die Parameter (z. B. für Regen, Schnee, Nebel, Graupel, Beleuchtung, Verdeckung usw.) zufällig gewählt werden, um die erweiterten Daten 102B zu erzeugen, und die Werte (oder Kombinationen davon) können eine bekannte Entsprechung zu Sichtweiten und/oder Abstandsbereichen haben, und diese Sichtweiten und/oder Abstandsbereiche können als Ground-Truth für die Instanzen der erweiterten Daten 102B verwendet werden.
  • Als ein Beispiel für ein Trainieren eines Modells oder für ein Erzeugen einer Abbildung zwischen Werten von Parametern und Sichtweiten und/oder Abstandsbereichen und in Bezug auf die 2A-2C kann die Visualisierung 200A Werten für Regenparameter entsprechen, die verwendet werden, um erweiterte Daten 102B mit starken Regen zu erzeugen. Ein Kommentator oder Beschrifter kann dann einen Abstand zu dem Fahrzeug 202A bestimmen, die erweiterten Daten 102B als solche bezeichnen, und dies kann einer Abbildung zwischen den Werten eines oder mehrerer Parameter zum Erweitern der Daten und Sichtweiten und/oder Abstandsbereichen entsprechen. Dieser Prozess kann für die Visualisierung 200B unter Verwendung des Abstands zu dem Fahrzeug 202B und der Werte für die Parameter, die zu einem leichten Regen führen, und für die Visualisierung 200C unter Verwendung des Abstands zu dem Fahrzeug 202C und der Werte für die Parameter, die zu einer klaren Bedingung führen (z. B. alle Regenwerte auf 0, da es keinen Regen gibt), wiederholt werden. Obwohl Regen in Bezug auf die 2A-2C veranschaulicht und beschrieben wurde, soll dies nicht einschränkend sein, und andere Bedingungen wie Nebel, Schnee, Graupel, Hagel, Beleuchtung, Verdeckung, eine Kombination davon usw. können verwendet werden, um die erweiterten Daten 102B und somit die Abbildung zwischen den Werten der Parameter (oder Kombinationen davon) und den Sichtweiten und/oder Abstandsbereichen für die Ground-Truth zu erzeugen.
  • Um die Ground-Truth-Daten für die synthetischen Daten 102C zu erzeugen, können ähnliche Prozesse wie bei den Sensordaten 102A verwendet werden, mit der Ausnahme, dass die bekannten Tiefeninformationen von der Simulationsmaschine stammen können, da die der Simulation entsprechenden Zustandsdaten genaue Tiefen- oder Abstandsinformationen für Objekte in der Umgebung aufweisen können. Zum Beispiel kann ein menschlicher Kommentator ein am weitesten sichtbares Objekt in einer Instanz der synthetischen Daten 102C identifizieren, die gemäß variierenden Werten für Parameter in der Simulation erzeugt wurden, und eine Tiefe oder Entfernung von dem virtuellen Sensor der virtuellen Maschine zu dem am weitesten sichtbaren Objekt kann als die Sichtweite und/oder zur Bestimmung des Abstandsbereichs als Ground-Truth verwendet werden. Zusätzlich oder alternativ kann in Ausführungsformen ein Modell trainiert werden, um eine Entsprechung oder Abbildung zwischen Werten für Parameter der Simulation und der Sichtweite und/oder Abstandsbereichen zu bestimmen. Zum Beispiel können Werte für Nebelparameter (z. B. Dichte, Höhe usw.) verwendet werden, um die simulierte Umgebung der Simulation zu erzeugen, und die synthetischen Daten 102C können aus der simulierten Umgebung erfasst werden. Die Instanz der synthetischen Daten 102C kann dann analysiert werden (z. B. unter Verwendung bekannter Tiefenwerte für sichtbare Objekte in der Simulation), um die Sichtweite und/oder Abstandsbereiche zu bestimmen. Dieser Prozess kann für eine beliebige Anzahl von Instanzen der synthetischen Daten 102C wiederholt werden, bis das Modell trainiert ist, um Sichtweiten und/oder Abstandsbereiche basierend auf den Werten der Parameter für die Simulation zu berechnen. In einigen Ausführungsformen kann ein Werkzeug verwendet werden, um einem Benutzer zu ermöglichen, zu erkennen, wann ein bestimmtes Objekt für einen bestimmten Satz von Parametern sichtbar oder nicht sichtbar ist. Zum Beispiel kann ein Fahrzeug an einem ersten Ort angeordnet werden, und der Benutzer kann angeben, dass das Fahrzeug sichtbar ist. Das Fahrzeug kann dann weiter weg bewegt werden, und der Benutzer kann angeben, dass das Fahrzeug immer noch sichtbar ist. Das Fahrzeug kann dann in der simulierten Umgebung noch weiter weg bewegt werden, und der Benutzer kann angeben, dass das Fahrzeug nicht mehr sichtbar ist, und diese Entfernung des Fahrzeugs kann als die Ground-Truth-Sichtweite und/oder zur Bestimmung des Abstandsbereichs verwendet werden. Dieser Vorgang kann mit verschiedenen Parametern und für verschiedene Objekttypen wiederholt werden, bis das Modell trainiert ist. Sobald das Modell trainiert ist, kann dieses Modell verwendet werden, um automatisch eine Ground-Truth für die automatisch erzeugten synthetischen Daten zu erzeugen. Zum Beispiel können die Werte für die Parameter (z. B. für Regen, Schnee, Nebel, Graupel, Beleuchtung, Verdeckung usw.) zufällig bestimmt werden, um die Simulationen zu erzeugen, und die Werte (oder Kombinationen davon) können eine bekannte Entsprechung zu Sichtweiten und/oder Abstandsbereichen haben, und diese Sichtweiten und/oder Abstandsbereiche können als Ground-Truth für die Instanzen der synthetischen Daten 102C verwendet werden.
  • Als ein Beispiel für ein Trainieren eines Modells oder ein Erzeugen einer Abbildung zwischen Werten von Parametern und Sichtweiten und/oder Abstandsbereichen und in Bezug auf die 2A-2C kann die Visualisierung 200A Werten für Regenparameter entsprechen, die verwendet werden, um synthetische Daten 102C mit einem starken Regen zu erzeugen. Ein Kommentator oder Beschrifter kann dann eine Entfernung zu dem Fahrzeug 202A bestimmen, die synthetischen Daten 102C als solche bezeichnen, und dies kann einer Abbildung zwischen Werten von einem oder mehreren Parametern zum Erzeugen einer Simulation und Sichtweiten und/oder Abstandsbereichen entsprechen. Dieser Prozess kann für die Visualisierung 200B unter Verwendung der Entfernung zu dem Fahrzeug 202B und der Werte für die Parameter, die zu einem leichten Regen führen, und für die Visualisierung 200C unter Verwendung der Entfernung zu dem Fahrzeug 202C und der Werte für die Parameter, die zu einem klaren Zustand führen (z. B. alle Regenwerte auf 0, da es keinen Regen gibt), wiederholt werden. Obwohl Regen in den 2A-2C dargestellt und beschrieben ist, soll dies nicht einschränkend sein, und es können auch andere Bedingungen wie Nebel, Schnee, Graupel, Hagel, Beleuchtung, Verdeckung, eine Kombination davon usw. verwendet werden, um die synthetischen Daten 102C und somit die Abbildung zwischen den Werten der Parameter (oder Kombinationen davon) und den Sichtweiten und/oder Abstandsbereichen für die Ground-Truth zu erzeugen.
  • Sobald die Ground-Truth-Daten - unter Verwendung des Ground-Truth-Generators 116 - erzeugt sind, um den Ausgaben 106 des/der Modells/Modelle für maschinelles Lernen 104 zu entsprechen, wie sie unter Verwendung der Trainingsdaten 102 berechnet wurden, können eine oder mehrere Verlustfunktionen 114 verwendet werden, um eine Genauigkeit des/der Modells/Modelle für maschinelles Lernen 104 zu bestimmen und das/die Modell(e) für maschinelles Lernen bei jeder Iteration zu aktualisieren (z. B. Parameter wie Gewichte und Biases), bis ein akzeptables Genauigkeitsniveau erreicht ist. Wird das Modell für maschinelles Lernen 104 trainiert, um auf einen Wert der Sichtweite zu regressieren (d.h., eine Regression durchzuführen), kann ein Regressionsverlust als eine Verlustfunktion 114 verwendet werden. In einem solchen Beispiel kann der Regressionsverlust einen normalisierten L1-Verlust aufweisen, der einen höheren Fehler bei größeren Sichtweiten und einen geringeren Fehler bei kürzeren Sichtweiten ergibt. In einem solchen Beispiel kann der Verlust gemäß der folgenden Gleichung (1) berechnet werden: R e g r e s s i o n s v e r l u s t = d p r e d d G T d G T
    Figure DE102022124361A1_0001
    wobei dpred die vorhergesagte Sichtweite ist, die von dem/den Modell(en) für maschinelles Lernen 104 ausgegeben wird, und dGT die Ground-Truth-Sichtweite ist.
  • In anderen Beispielen kann ein normalisierter L2-Verlust oder ein gerichteter normalisierter L1-Verlust verwendet werden. Der gerichtete normalisierte L1-Verlust kann dem normalisierten L1-Verlust ähnlich sein, aber die Steigung der Verlustkurve kann auf der positiven Seite steiler sein, um einen Anreiz für Fehler auf der positiven Seite zu schaffen (z. B. um auf der Verlustebene eine Zurückrufen (recall) gegenüber Präzision zu begünstigen). Der Minimalwert für diese Verlustfunktion kann immer noch bei 0 liegen, aber Vorhersagen, die unter der Ground-Truth liegen, können stärker bestraft werden.
  • In noch weiteren Beispielen kann ein Gaußscher Abstandsverlust für einen Regressionskanal verwendet werden, um Abstände, die weiter von der Ground-Truth entfernt sind, stärker zu bestrafen, und Vorhersagen, die näher an der Ground-Truth liegen, weniger zu bestrafen (anstatt eine vollständige Genauigkeit zu fordern). In einem solchen Beispiel kann eine Überschätzung des Abstands stärker bestraft werden als eine Unterschätzung.
  • In Ausführungsformen, in denen das/die Modell(e) für maschinelles Lernen 104 die Abstandsbereiche 110 ausgibt/ausgeben (z. B. als Klassifikationsausgabe), kann ein Klassifikationsverlust verwendet werden. Um das/die Modell(e) für maschinelles Lernen 104 zu trainieren, um den Abstandsbereich 110 zu berechnen, kann z. B. eine kategorische Kreuzentropie-Verlustfunktion verwendet werden und/oder eine gerichtete kategorische Kreuzentropie-Verlustfunktion kann verwendet werden.
  • Während eines Trainierens des/der Modelle für maschinelles Lernen 104 und um ein akzeptables Genauigkeitsniveau zu bestimmen, können ein oder mehrere wichtige Leistungsindikatoren (key performance indicators, KPls) verwendet werden. Zum Beispiel kann ein KPI auf Ebene des Netzes (oder des Modells für maschinelles Lernen) und ein KPI auf Modulebene verwendet werden. Der KPI auf Ebene des Netzes kann einen relativen Vorhersagefehler der Sichtweite (relative visibility distance prediction error, RDE) für jede Instanz von Trainingsdaten 102 gemäß der folgenden Gleichung (2) abschätzen: R D E = d p r e d d G T d G T
    Figure DE102022124361A1_0002
    wobei dpred die von dem/den Modell(en) für maschinelles Lernen 104 vorhergesagte Sichtweite und dGT die Ground-Truth-Sichtweite ist. Unter Verwendung dieser Werte für jede Instanz der Trainingsdaten 102 können der Mittelwert und die Standardabweichung analysiert werden.
  • Der KPI auf Modulebene kann den Fehler bei der Klassifikation von vorhergesagten Sichtweiten in verschiedenen Bereichen abschätzen. Um den Fehler in einer Klassifikation (Δclass) zu berechnen, kann die nachstehende Gleichung (3) verwendet werden: Δ c l a s s = c p r e d c G T
    Figure DE102022124361A1_0003
    wobei c die Abstandsbereichskennung (distance bin identifier, ID) ist (z. B. 1 entspricht sehr gering, 5 entspricht klar), cpred die durch das/die Modell(e) für maschinelles Lernen vorhergesagte ID des Sichtweite-Abstandsbereichs ist und cGT die ID des Sichtweite-Abstandsbereichs der Ground-Truth ist. Als solches kann Δclass für korrekte Vorhersagen 0 sein, positiv, wenn der vorhergesagte Abstandsbereich höher als erwartet ist, und negativ, wenn der vorhergesagte Abstandsbereich niedriger als erwartet ist. Auf diese Weise kann Δclass = 0 ein richtig Positiv, Δclass > 0 ein falsch Negativ und Δclass < 0 ein falsch Positiv darstellen. Dies kann dazu beitragen, dass ein falsch positiver Wert dazu führt, dass die Ego-Maschine 700 zu konservativ ist (was für einen Insassen unangenehm sein kann) und ein falsch negativer Wert dazu führt, dass die Ego-Maschine 700 zu wenig konservativ ist (was für einen Insassen gefährlich sein kann). Unter Verwendung dieser Definitionen von richtig Positiv, falsch-Positiv und falsch-Negativ kann das Modul so eingestellt werden, dass es eine gute Präzision und Zurückrufen erreicht, kann aber bei Bedarf das Zurückrufen bevorzugen (z.B. kann es bevorzugen, zu konservativ zu sein). Darüber hinaus kann der |Δclass| als Indikator für den vorhergesagten Fehler verwendet werden, und die Verlustfunktion kann verwendet werden, um die Streuung des |Δclass| zu verringern.
  • Unter Bezugnahme auf 3 umfasst nun jeder Block des hier beschriebenen Verfahrens 300 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 im Speicher gespeicherte Befehle ausführt. Das Verfahren 300 kann auch in Form von computerverwendbaren Befehlen ausgeführt werden, die auf Computerspeichermedien gespeichert sind. Das Verfahren 300 kann als eigenständige Anwendung, als Dienst oder gehosteter Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder als Einschub für ein anderes Produkt bereitgestellt werden, um nur einige Beispiele zu nennen. Zusätzlich wird das Verfahren 300 beispielhaft in Bezug auf den Prozess 100 von 1 und die Ego-Maschine 700 von 7A-7D beschrieben. Dieses Verfahren 300 kann jedoch zusätzlich oder alternativ innerhalb eines beliebigen Prozesses und/oder durch ein beliebiges System oder eine beliebige Kombination von Prozessen und Systemen, einschließlich, aber nicht beschränkt auf die hierin beschriebenen, ausgeführt werden.
  • 3 ist ein Flussdiagramm, das ein Verfahren 300 zum Trainieren eines Modells für maschinelles Lernen darstellt, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 300 umfasst im Block B302 ein Empfangen von Werten, die einem oder mehreren Parametern zum Einstellen einer Sichtweite entsprechen, die einer Instanz von Trainingssensordaten entspricht. Zum Beispiel können Werte für einen oder mehrere Parameter (z. B. Regenintensität, Regennässe, Nebeldichte, Lichtverhältnisse usw.) empfangen werden.
  • Das Verfahren 300 weist in Block B304 ein Erzeugen der Instanz von Trainingssensordaten auf, die zumindest teilweise auf den Werten basieren. Zum Beispiel können unter Verwendung der Werte des einen oder der mehreren Parameter die Sensordaten 102A erweitert werden, um die erweiterten Daten 102B zu erzeugen, und/oder es kann eine virtuelle Simulation erzeugt werden, und die synthetischen Daten 102C können unter Verwendung eines virtuellen Sensors einer virtuellen Maschine erfasst werden.
  • Das Verfahren 300 weist in Block B306 ein Bestimmen einer Sichtweite auf, die der Instanz von Trainingssensordaten entspricht, die zumindest zum Teil auf den Werten basieren. Zum Beispiel kann unter Verwendung eines oder mehrerer trainierter Modelle eine Entsprechung zwischen dem einen oder den mehreren Werten des einen oder der mehreren Parameter und einer Sichtweite 108 und/oder einem Sichtweitenbereich 110 bestimmt werden.
  • Das Verfahren 300 weist in Block B308 ein Trainieren eines Modells für maschinelles Lernen auf, welches die Instanz von Trainingssensordaten und die Sichtweite als Ground-Truth-Daten verwendet. Zum Beispiel können das/die Modell(e) für maschinelles Lernen 104 unter Verwendung einer oder mehrerer Verlustfunktion(en) 114 trainiert werden, um die Ausgaben 106 mit den Ground-Truth-Daten zu vergleichen (z. B. entsprechend den Ground-Truth-Sichtweiten, den Ground-Truth-Abstandsbereichen und/oder den Ground-Truth-Sichtweiten-Klassifikationen/Attributen), die unter Verwendung des Ground-Truth-Generators 116 erzeugt wurden. Eine beliebige Anzahl (z. B. Tausende, Millionen usw.) von Instanzen von Trainingsdaten 102 kann verwendet werden, um das/die Modell(e) für maschinelles Lernen 104 zu trainieren, bis das/die Modell(e) für maschinelles Lernen 104 ein akzeptables Genauigkeitsniveau erreicht/erreichen (wie es unter Verwendung eines oder mehrerer KPls in Ausführungsformen bestimmt wird) und für den Einsatz validiert ist (z. B. in Prozess 400 von 4).
  • BERECHNEN VON SICHTWEITEN IM EINSATZ
  • Unter Bezugnahme auf 4 ist 4 ein Datenflussdiagramm, das einem Beispielprozess 400 für einen Einsatz eines Modells für maschinelles Lernen für Sichtweitenschätzungen gemäß einigen Ausführungsformen der vorliegenden Offenbarung entspricht. Es sollte klar sein, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, 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 hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten 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 im Speicher gespeicherte Befehle ausführt. In einigen Ausführungsformen können die hierin beschriebenen Systeme, Verfahren und Prozesse unter Verwendung ähnlicher Komponenten, Merkmale und/oder Funktionen ausgeführt werden wie die des Beispiels eines autonomen Fahrzeugs 700 der 7A-7D, dem Beispiel einer Rechenvorrichtung 800 von 8 und/oder dem Beispiel eines Rechenzentrums 900 von 9.
  • Beim Einsatz kann der Prozess 400 ein Erzeugen und/oder Empfangen von Sensordaten 402 umfassen. Die Sensordaten 402 können Sensordaten aufweisen, die unter Verwendung eines oder mehrerer Sensoren einer Ego-Maschine erzeugt wurden - wie die hierin in Bezug auf die 7A-7D beschriebene Ego-Maschine 700. Beispielsweise können die Sensordaten 402 ähnlich wie die in 1 beschriebenen Sensordaten 102A sein. Als solche können die Sensordaten 402 ein Sichtfeld und/oder ein sensorisches Feld eines oder mehrerer Sensoren der Ego-Maschine 700 darstellen - beispielsweise in Form eines Bildes, eines LiDAR-Entfernungsbildes, einer Punktwolke usw.
  • Das/die Modell(e) für maschinelles Lernen 104 kann/können die Sensordaten 402 als Eingabe empfangen und die Sensordaten 402 verarbeiten, um die Ausgabe(n) 106 zu berechnen, die die Sichtweite 108, den/die Abstandsbereich(e) 110 und/oder die Sichtweiten-Klassifikationen/Attribute 112 enthalten können. In Ausführungsformen, in denen das/die Modell(e) für maschinelles Lernen 104 die Sichtweite 108 (und nicht den/die Abstandsbereich(e) 110) berechnet, kann ein Postprozessor 404 verwendet werden, um die Sichtweite 108 in einen Abstandsbereich einzuteilen. Zum Beispiel, wenn ein Abstandsbereich zwischen 10 Metern und 100 Metern liegt und die Sichtweite 108 beträgt 78 Meter, kann der Postprozessor 404 die Instanz der Sensordaten 402 als dem Abstandsbereich zwischen 10 Metern und 100 Metern entsprechend kennzeichnen oder klassifizieren, und diese Information kann für die Verwendbarkeit 406 analysiert werden.
  • In einem beliebigen Beispiel, egal ob der/die Abstandsbereich(e) 110 direkt als eine Ausgabe 106 des/der Modells/Modelle für maschinelles Lernen 104 berechnet oder unter Verwendung des Postprozessors 404 bestimmt wird/werden, kann es eine beliebige Anzahl von Abstandsbereichen geben, und jeder Abstandsbereich kann einen beliebigen Bereich von Sichtweiten-Werten aufweisen. Zusätzlich kann jeder Bereich einer unterschiedlichen Anzahl von Operationen entsprechen, die durchgeführt werden können. Zum Beispiel, wenn die Sensordaten 402 in keiner Weise visuell beeinträchtigt sind, kann es einen Satz von Operationen geben, für die sich die Ego-Maschine 700 auf die Sensordaten 402 verlassen kann. Wenn die Sensordaten 402 jedoch in irgendeiner Weise visuell beeinträchtigt sind (z. B. ist die Sichtweite geringer als ein Maximum), können eine oder mehrere Operationen des Satzes von Operationen deaktiviert werden, oder ein Indikator kann bereitgestellt werden, der eine oder mehrere Komponenten, Merkmale und/oder Funktionalitäten, die sich auf die Sensordaten 402 stützen, veranlasst, die Instanzen der Sensordaten 402 zu ignorieren, die nicht geeignet oder verwendbar sind. Zusätzlich können in Ausführungsformen, in denen die Sichtweiten-Klassifikationen/Attribute 112 berechnet werden, diese Informationen zusätzlich als ein Faktor bei der Entscheidung über die Verwendbarkeit 406 verwendet werden, so dass bestimmte Sichtweiten-Klassifikationen in Kombination mit bestimmten Abstandsbereichen einer anderen Verwendbarkeit entsprechen können als andere Sichtweiten-Klassifikationen in Kombination mit anderen Abstandsbereichen.
  • Als nicht einschränkendes Beispiel können die Abstandsbereiche einen ersten Bereich für sehr geringe Sichtweite (z.B. <10 Meter), einen zweiten Bereich für geringe Sichtweite (z.B. zwischen 10 Metern und 100 Metern), einen dritten Bereich für mittlere Sichtweite (z.B. zwischen 100 Metern und 1000 Metern), einen vierten Bereich für hohe Sichtweite (z.B. zwischen 1000 Metern und 4000 Metern) und einen fünften Bereich für klare Sicht („clear visibility“, z.B. größer als 4000 Meter) umfassen. Der erste Bereich kann in diesem Beispiel einem Sichtbereich entsprechen, der extremem Nebeln oder Schneetreiben, starkem Niederschlag oder starkem Nieselregen entspricht. Der zweite Bereich kann einem Sichtbereich entsprechen, der dichtem Nebelwetter entspricht. Der dritte Bereich kann einem Sichtbereich entsprechen, der mäßigem Nebelwetter oder mittlerem Niederschlag oder mäßigem Nieselregen entspricht. Der vierte Bereich kann einem Sichtbereich entsprechen, der einer dunstigen Wetterbedingung oder leichtem Niederschlag oder Nieselregen entspricht. Der fünfte Bereich kann einem Sichtbereich entsprechen, der einer maximalen Sichtweite des (der) bestimmten Sensors (Sensoren) entspricht, der (die) die Sensordaten 402 erzeugt (erzeugen).
  • In Fortführung dieses nicht-einschränkenden Beispiels kann jeder Bereich der fünf Bereiche verschiedenen Aufgaben entsprechen, die von der Ego-Maschine ausgeführt werden können. Zum Beispiel kann für den ersten Bereich (z. B. sehr geringe Sichtweite) die volle Leistung von aktiven Sicherheitsfunktionen für niedrige Geschwindigkeiten der Stufe 0, Stufe 1 und Stufe 2 (z. B. Fahrspurassistent, automatischer Spurhalteassistent, automatischer Geschwindigkeitsregler, automatische Notbremsung usw.) verfügbar sein, solange die Ego-Maschine mit einer Geschwindigkeit von weniger als einem Schwellenwert (z. B. weniger als 25 Kilometer pro Stunde) unterwegs ist. Fährt das Fahrzeug jedoch mit einer über dem Grenzwert liegenden Geschwindigkeit, können diese Funktionen deaktiviert werden - zumindest in Bezug auf die Instanz(en) von Sensordaten 402 mit einer sehr geringen Sichtweite. In Bezug auf den zweiten Bereich (z. B. geringe Sichtweite) kann die volle Leistung der Parkfunktionen der Stufe 0, der Stufe 1 und der Stufe 2 (z. B. Annäherungserkennung, automatische parallele Parkausrichtung usw.) und der aktiven Sicherheitsfunktionen für niedrige Geschwindigkeiten verfügbar sein, solange die Ego-Maschine mit einer geringeren Geschwindigkeit als einem Schwellenwert unterwegs ist. In Bezug auf den dritten Bereich (z. B. mittlere Sichtweite) kann die volle Leistung der Fahrfunktionen der Stufe 0, Stufe 1, Stufe 2 und Stufe 2+ verfügbar sein. In Bezug auf den vierten Bereich (z. B. große Sichtweite) kann zusätzlich zu den Funktionen der Stufe 0, Stufe 1, Stufe 2 und Stufe 2+ des ersten, zweiten und dritten Bereichs die volle Leistung der Parkfunktionen der Stufe 3 und Stufe 4 (z. B. automatisches Parallelparken (APP), MPP, VVP) verfügbar sein. In Bezug auf den fünften Bereich (z. B. klare Sicht) kann zusätzlich zu den Funktionen des ersten, zweiten, dritten und vierten Bereichs die volle Leistung des automatisierten Fahrens auf der Autobahn der Stufe 3 verfügbar sein.
  • In einigen Ausführungsformen kann die Verwendbarkeit 406 einem Teil der Informationen aus den Sensordaten 402 entsprechen, der verwendet werden kann. Zum Beispiel, wenn der Abstandsbereich bekannt ist und der Abstandsbereich einem Bereich von 100 bis 1000 Metern entspricht, können alle Ausgaben des Systems, die den Sensordaten 402 entsprechen und die innerhalb von 1000 Metern der Ego-Maschine 700 liegen, verwendet werden, während alle Ausgaben, die einem Abstand von mehr als 1000 Metern entsprechen, ignoriert werden können. In einem solchen Beispiel, in dem ein erstes Fahrzeug in einer Entfernung von 200 Metern von der Ego-Maschine 700 unter Verwendung eines Objekterkennungsalgorithmus erkannt wird, kann sich ein nachgeschaltetes System des Fahrstapels 408 auf diese Erkennung verlassen. Wird jedoch ein zweites Fahrzeug in einer Entfernung von 1200 Metern von der Ego-Maschine 700 unter Verwendung des Objekterkennungsalgorithmus erkannt, kann auf die Erkennung nicht zurückgegriffen werden. Dieser ähnliche Prozess kann für andere Aufgaben wie Objektverfolgung, Hindernis-im-Weg-Analyse (obstacle in path analysis, OIPA), Objekt-zu-Spur-Zuordnung, Lokalisierung usw. verwendet werden.
  • In einer beliebigen Ausführungsform kann die Instanz der Sensordaten 402, sobald die Verwendbarkeit 406 bestimmt ist, versehen werden mit oder übertragen werden an einen autonomen oder halbautonomen Software-Fahrstapel („Drive Stack“) mit einem Hinweis auf die Verwendbarkeit 406, so dass eine oder mehrere Eigenschaften, Funktionalitäten und/oder Komponenten des Fahrstapels 408 entweder deaktiviert werden können, die Instanz der Sensordaten 402 ignorieren können und/oder anderweitig die Verwendbarkeit 406 nutzen können. Der Fahrstapel 408 kann eine oder mehrere Schichten aufweisen, wie z.B. eine Weltzustandsverwaltungsschicht, die den Weltzustand unter Verwendung einer oder mehrerer Karten (z. B. 3D-Karten), Lokalisierungskomponente(n), Wahrnehmungskomponente(n) und/oder dergleichen verwaltet. Zusätzlich kann der autonome Software-Fahrstapel Planungskomponenten (z. B. als Teil einer Planungsschicht), Steuerungskomponenten (z. B. als Teil einer Steuerungsschicht), Betätigungskomponenten (z. B. als Teil einer Betätigungsschicht), Hindernisausweichkomponenten (z. B. als Teil einer Hindernisausweichschicht), und/oder andere Komponenten (z. B. als Teil einer oder mehrerer zusätzlicher oder alternativer Schichten) enthalten. Als solches kann die Verwendbarkeit 406 einen Hinweis für alle nachgelagerten Aufgaben des Fahrstapels 408 bereitstellen, die auf den Sensordaten 402 beruhen, so dass eine geeignete Verwendung der Sensordaten 402 organisiert wird.
  • Als ein Beispiel und in Bezug auf die Visualisierung 500 von 5 kann eine Instanz von Sensordaten 402, die ein Bild darstellt, unter Verwendung einer Kamera der Ego-Maschine 700 erzeugt werden. Die Instanz der Sensordaten 402 kann auf das/die Modell(e) für maschinelles Lernen 104 angewendet werden, und das/die Modell(e) für maschinelles Lernen 104 kann/können eine oder mehrere der Ausgaben 106 berechnen. Wenn die Ausgabe 106 die Sichtweite 108 aufweist, kann der Postprozessor 404 die Sichtweite 108 in einen Abstandsbereich einteilen. Die Verwendbarkeit 406 kann dann auf der Grundlage des Abstandsbereichs (und/oder der Sichtweiten-Klassifikation/Attribute 112) bestimmt werden, und diese Informationen können von dem Fahrstapel 408 verwendet werden. Zum Beispiel, wenn der Abstandsbereich einer sehr geringen Sichtweite entspricht, können Sicherheitsfunktionen wie die automatische Notbremsung (AEB) verwendet werden, um die Ego-Maschine 700 beim Anhalten des Fahrzeugs 502A zu unterstützen, aber auf ein Ergebnis der Objekterkennung, das dem Fahrzeug 502B entspricht, kann aufgrund der reduzierten Verwendbarkeit 406 der Sensordaten 402, die der Visualisierung 500 entsprechen, nicht zurückgegriffen werden.
  • Unter Bezugnahme auf 6 umfasst nun jeder Block eines hier beschriebenen Verfahrens 600 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 im Speicher gespeicherte Befehle ausführt. Das Verfahren 600 kann auch in Form von computerverwendbaren Befehlen ausgeführt werden, die auf Computerspeichermedien gespeichert sind. Das Verfahren 600 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Einsteckmodul für ein anderes Produkt bereitgestellt werden, um nur Einige zu nennen. Zusätzlich wird das Verfahren 600 anhand eines Beispiels in Bezug auf den Prozess 400 von 4 und die Ego-Maschine 700 der 7A-7D beschrieben. Dieses Verfahren 600 kann jedoch zusätzlich oder alternativ innerhalb eines beliebigen Prozesses und/oder durch ein beliebiges System oder eine beliebige Kombination von Prozessen und Systemen, einschließlich, aber nicht beschränkt auf die hier beschriebenen, ausgeführt werden.
  • 6 ist ein Flussdiagramm, das ein Verfahren 600 zum Einsatz eines Modells für maschinelles Lernen darstellt, um geschätzte Sichtweiten zu berechnen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 600 weist im Block B602 ein Berechnen, unter Verwendung eines Modells für maschinelles Lernen und zumindest teilweise basierend auf Sensordaten, die unter Verwendung eines oder mehrerer Sensoren einer Ego-Maschine erzeugt werden, von Daten auf, die eine den Sensordaten entsprechende Sichtweite anzeigen. Zum Beispiel können das oder die Modelle für maschinelles Lernen 104 eine oder mehrere der Ausgaben 106 unter Verwendung der Sensordaten 402 als Eingabe berechnen.
  • Das Verfahren 600 weist in Block B604 ein Bestimmen, zumindest teilweise basierend auf der Sichtweite, einer Verwendbarkeit der Sensordaten für eine oder mehrere Operationen der Ego-Maschine auf. Zum Beispiel kann die Verwendbarkeit 406 der Sensordaten 402 auf der Grundlage der Sichtweite 108, des Abstandsbereichs 110 und/oder der Sichtweiten-Klassifikation/Attribute 112 bestimmt werden.
  • Das Verfahren 600 umfasst in Block B606 ein Durchführen mindestens einer Operation der einen oder mehreren Operationen, die zumindest teilweise auf der Verwendbarkeit der Sensordaten basieren. Zum Beispiel, wenn die Sichtweite nicht klar ist, kann eine Operatio oder können mehrere Operationen, die sonst auf den Sensordaten 402 beruhen würden, wenn die Sensordaten klar wären, deaktiviert werden und/oder es kann signalisiert werden, die bestimmte Instanz der Sensordaten 402 zu ignorieren.
  • BEISPIEL FÜR EIN AUTONOMES FAHRZEUG
  • 7A ist eine Darstellung eines Beispiels für ein autonomes Fahrzeug 700, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 700 (hierin alternativ als „Fahrzeug 700“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug, wie z. B. einen Pkw, einen Lkw, einen Bus, ein Ersthelferfahrzeug, einen Pendelbus, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (z. B., das unbemannt ist und/oder einen oder mehrere Fahrgäste aufnimmt) aufweisen. Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen 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“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 700 kann in der Lage sein, Funktionen gemäß einer oder mehrerer der Stufen 3 bis 5 der autonomen Fahrstufen auszuführen. Das Fahrzeug 700 kann über Funktionen verfügen, die einer oder mehreren der Stufen 1 bis 5 der autonomen Fahrstufen entsprechen. Zum Beispiel kann das Fahrzeug 700 je nach Ausführungsform in der Lage sein, den Fahrer zu unterstützen (Stufe 1), eine Teilautomatisierung (Stufe 2), eine bedingte Automatisierung (Stufe 3), eine hohe Automatisierung (Stufe 4) und/oder eine Vollautomatisierung (Stufe 5) durchzuführen. Der Begriff „autonom“, wie er hier verwendet wird, kann jede und/oder alle Arten von Autonomie für das Fahrzeug 700 oder eine andere Maschine umfassen, wie z. B. vollständig autonom sein, hochgradig autonom sein, bedingt autonom sein, teilautonom sein, unterstützende Autonomie bereitstellen, halbautonom sein, primär autonom sein, oder eine andere Bezeichnung.
  • Das Fahrzeug 700 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z.B. 2, 4, 6, 8, 18, etc.), Reifen, Achsen und andere Komponenten eines Fahrzeugs aufweisen. Das Fahrzeug 700 kann ein Antriebssystem 750 aufweisen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftwerk, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 750 kann mit einem Antriebsstrang des Fahrzeugs 700 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 700 zu ermöglichen. Das Antriebssystem 750 kann in Reaktion auf ein Empfangen von Signalen von der Drosselklappe/Beschleunigungsvorrichtung 752 gesteuert werden.
  • Ein Lenksystem 754, das ein Lenkrad aufweisen kann, kann verwendet werden, um das Fahrzeug 700 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 750 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 754 kann Signale von einem Lenkaktuator 756 empfangen. Das Lenkrad kann optional für die vollständige Automatisierung (Stufe 5) eingesetzt werden.
  • Das Bremssensorsystem 746 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf ein Empfangen von Signalen von den Bremsaktuatoren 748 und/oder Bremssensoren zu betätigen.
  • Eine Steuerung (Steuerungen) 736, die ein oder mehrere System-on-Chips (SoCs) 704 (7C) und/oder GPU(s) aufweisen kann (können), kann (können) Signale (z. B. die Befehle darstellen) für eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 700 bereitstellen. Zum Beispiel kann (können) die Steuerung(en) Signale senden, um die Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 748 zu betätigen, um das Lenksystem 754 über einen oder mehrere Lenkaktuatoren 756 zu betätigen, um das Antriebssystem 750 über einen oder mehrere Drossel-/Beschleunigungsaktuatoren 752 zu betreiben. Die Steuerung(en) 736 kann (können) eine oder mehrere eingebaute (z. B. integrierte) Recheneinrichtungen (z.B. Supercomputer) aufweisen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 700 zu unterstützen. Die Steuerung(en) 736 kann (können) eine erste Steuerung 736 für autonome Fahrfunktionen, eine zweite Steuerung 736 für funktionale Sicherheitsfunktionen, eine dritte Steuerung 736 für Funktionen der künstlichen Intelligenz (z. B. Computer Vision), eine vierte Steuerung 736 für Infotainment-Funktionen, eine fünfte Steuerung 736 für Redundanz unter Notfallbedingungen und/oder andere Steuerungen umfassen. In einigen Beispielen kann eine einzelne Steuerung 736 zwei oder mehr der oben genannten Funktionen übernehmen, zwei oder mehr Steuerungen 736 können eine einzelne Funktion übernehmen, und/oder eine beliebige Kombination davon.
  • Die Steuerung(en) 736 kann (können) die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 700 in Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren (z. B. Sensoreingaben) empfangen werden. Die Sensordaten können zum Beispiel und ohne Einschränkung von (einem) Sensor(en) für globale Navigationssatellitensysteme 758 (z. B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 760, Ultraschallsensor(en) 762, LIDAR-Sensor(en) 764, Trägheitssensor(en) (inertial measurement unit (IMU) sensor(s)) 766 (z. B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(en) 796, Stereokamera(s) 768, Weitwinkelkamera(s) 770 (z. B., Fischaugenkameras), Infrarotkamera(s) 772, Surround-Kamera(s) 774 (z. B. 360-Grad-Kameras), Fern- und/oder Mittelbereichskamera(s) 798, Geschwindigkeitssensor(en) 744 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 700), Vibrationssensor(en) 742, Lenksensor(en) 740, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 746) und/oder anderen Sensortypen empfangen werden.
  • Eine oder mehrere der Steuerungen 736 können Eingaben (z. B. dargestellt durch Eingabedaten) von einem Kombiinstrument 732 des Fahrzeugs 700 empfangen und Ausgaben (z. B. dargestellt durch Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 734, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 700 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 722 von 7C), Standortdaten (z. B. den Standort des Fahrzeugs 700, z. B. auf einer Karte), Richtung, den Standort anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von der/den Steuerung(en) 736 wahrgenommen, usw. aufweisen. Zum Beispiel kann die HMI-Anzeige 734 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen, usw.).
  • Das Fahrzeug 700 umfasst ferner eine Netzschnittstelle 724, die eine oder mehrere drahtlose Antenne(n) 726 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netze verwenden kann. Zum Beispiel kann die Netzschnittstelle 724 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000, etc. zu kommunizieren. Die drahtlose(n) Antenne(n) 726 kann (können) auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) ermöglichen, wobei lokale Netze wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Weitverkehrsnetze mit geringer Leistung (LPWANs) wie LoRaWAN, SigFox usw. verwendet werden.
  • 7B ist ein Beispiel für Kamerastandorte und Sichtfelder für das autonome Beispielfahrzeug 700 von 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder sind ein Beispiel für eine Ausführungsform und nicht als Einschränkung gedacht. Beispielsweise können zusätzliche und/oder alternative Kameras vorgesehen sein und/oder die Kameras können an anderen Stellen an dem Fahrzeug 700 angeordnet sein.
  • Die Kameratypen für die Kameras können, sind aber nicht darauf beschränkt, Digitalkameras umfassen, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 700 ausgelegt sein können. Die Kamera(s) kann/können gemäß ASIL (Automotive Safety Integrity Level) B und/oder einem anderen ASIL arbeiten. Die Kameratypen können in Abhängigkeit von der Ausführungsform jede beliebige Bildaufnahmerate erreichen, z. B. 60 Einzelbilder pro Sekunde („frames per second“, fps), 120 fps, 240 fps usw.. Die Kameras können Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar-Farbfilteranordnung („red clear clear clear“, RCCC), eine Rot-Klar-Klar-Blau-Farbfilteranordnung („red clear clear blue“, RCCB), eine Rot-Blau-Grün-Klar-Farbfilteranordnung („red blue green clear“ RBGC), eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensor-Farbfilteranordnung (RGGB), eine Monochromsensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung aufweisen. In einigen Ausführungsformen können zur Erhöhung der Lichtempfindlichkeit Klarpixelkameras, wie z. B. Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, verwendet werden.
  • In einigen Beispielen können eine oder mehrere der Kamera(s) verwendet werden, um fortschrittliche Fahrerassistenzsystem („advanced driver assistance systems“, ADAS)-Funktionen auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). So kann zum Beispiel eine Multifunktions-Monokamera installiert werden, die Funktionen bereitstellt, die einen Spurhalteassistenten, einen Verkehrszeichenassistenten und eine intelligente Scheinwerfersteuerung umfassen. 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 Montageanordnung, wie z. B. einer kundenspezifisch entworfenen (3-D-gedruckten) Anordnung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen von dem Armaturenbrett, die in den Windschutzscheibenspiegeln reflektiert werden) auszuschalten, die die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. Bei der Montage von Außenspiegeln können die Außenspiegel kundenspezifisch dreidimensional gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen können die Kameras in den Außenspiegel integriert werden. Bei Seitenkameras können die Kameras auch in die vier Säulen an jeder Ecke der Fahrgastzelle integriert werden.
  • Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 700 einbezieht (z. B. nach vorne gerichtete Kameras), können für die Umgebungsansicht verwendet werden, um zu helfen, nach vorne gerichtete Pfade und Hindernisse zu identifizieren, sowie dazu beizutragen, mit Hilfe von einer oder mehreren Steuerungen 736 und/oder Steuer-SoCs Informationen bereitzustellen, die für ein Erzeugen eines Belegungsgitters und/oder ein Bestimmen der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen als LIDAR auszuführen, einschließlich Notbremsung, Fußgängererfassung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie eine Warnung vor dem Verlassen der Fahrspur („Lane Departure Warnings“, LDW), eine autonome Geschwindigkeitsregelung („Autonomous Cruise Control“, ACC) und/oder andere Funktionen wie die Erkennung von Verkehrszeichen verwendet werden.
  • Eine Vielzahl von Kameras kann in einer nach vorne gerichteten Konfiguration verwendet werden, z. B. eine monokulare Kameraplattform, die einen Farbbildwandler vom Typ CMOS (Complementary Metal Oxide Semiconductor) aufweist. Ein weiteres Beispiel sind eine oder mehrere Weitwinkelkameras 770, die verwendet werden können, um Objekte zu erkennen, die von der Peripherie her in Sicht kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 7B nur eine Weitwinkelkamera dargestellt ist, kann sich eine beliebige Anzahl von Weitwinkelkameras 770 an dem Fahrzeug 700 befinden. Darüber hinaus kann (können) Fernbereichskamera(s) 798 (z. B. ein weitreichendes Stereokamerapaar) zur tiefenbasierten Objekterfassung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Fernbereichskamera(s) 798 kann (können) auch zur Objekterfassung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
  • Eine oder mehrere Stereokameras 768 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 768 kann (können) eine integrierte Steuereinheit enthalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Multicore-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3-D-Karte der Fahrzeugumgebung zu erzeugen, einschließlich einer Abstandsschätzung für alle Punkte in dem Bild. Eine alternative Stereokamera(s) 768 kann einen kompakten Stereosicht-Sensor bzw. kompakte Stereosicht-Sensoren umfassen, der bzw. die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip enthält bzw. enthalten, die die Entfernung zwischen dem Fahrzeug und dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) verwenden können, um die autonomen Notbrems- und Spurhaltewarnfunktionen zu aktivieren. Andere Arten von Stereokamera(s) 768 können zusätzlich oder alternativ zu den hier beschriebenen verwendet werden.
  • Kameras mit einem Sichtfeld, die Abschnitte der Umgebung seitlich des Fahrzeugs 700 einbeziehen (z. B. Seitenkameras), können für eine Umgebungsansicht verwendet werden, die Informationen bereitstellen, die zur Erzeugung und Aktualisierung des Belegungsgitters sowie zur Erzeugung von Seitenaufprallwarnungen verwendet werden. Zum Beispiel kann (können) die Surround-Kamera(s) 774 (z. B. vier Surround-Kameras 774, wie in 7B dargestellt) am Fahrzeug 700 positioniert werden. Die Surround-Kamera(s) 774 kann/können Weitwinkelkamera(s) 770, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Zum Beispiel können vier Fischaugenkameras an der Vorderseite, der Rückseite und den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Surround-Kameras 774 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als eine vierte Umgebungskamera nutzen.
  • Kameras mit einem Sichtfeld, die Abschnitte der Umgebung hinter dem Fahrzeug 700 einschließen (z. B. Rückfahrkameras), können für eine Einparkhilfe, eine Umgebungsansicht, Heckkollisionswarnungen und ein Erzeugen und Aktualisieren des Belegungsgitters verwendet werden. Eine große Vielfalt von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z. B. Fernbereichs- und/oder Mittelbereichskamera(s) 798, Stereokamera(s) 768, Infrarotkamera(s) 772, usw.), wie hier beschrieben.
  • 7C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 700 von 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es sollte klar sein, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargelegt sind. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten 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.
  • Alle Komponenten, Merkmale und Systeme des Fahrzeugs 700 in 7C sind als über einen Bus 702 verbunden dargestellt. Der Bus 702 kann eine Controller Area Network (CAN) Datenschnittstelle (hier alternativ als „CAN-Bus“ bezeichnet) umfassen. Ein CAN-Bus kann ein Netz innerhalb des Fahrzeugs 700 sein, das verwendet wird, um die Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 700 zu unterstützen, wie beispielsweise eine Bremsenbetätigung, Beschleunigung, Bremsen, Lenken, Scheibenwischer, usw. Ein CAN-Bus kann so ausgelegt sein, dass er Dutzende oder sogar Hunderte von Knoten hat, jeder mit seiner eigenen eindeutigen Kennung (z. B. einer CAN-ID). Der CAN-Bus kann ausgelesen werden, um einen Lenkradwinkel, eine Fahrgeschwindigkeit, eine Motordrehzahl pro Minute (RPM), Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 702 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können zusätzlich oder alternativ zu dem CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Obwohl eine einzelne Leitung verwendet wird, um den Bus 702 darzustellen, ist dies nicht als Einschränkung zu verstehen. So kann es beispielsweise eine beliebige Anzahl von Bussen 702 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Bustypen mit einem anderen Protokoll aufweisen können. In einigen Beispielen können zwei oder mehr Busse 702 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. So kann beispielsweise ein erster Bus 702 für eine Kollisionsvermeidungsfunktion verwendet werden und ein zweiter Bus 702 kann für eine Betätigungssteuerung verwendet werden. In einem beliebigen Beispiel kann jeder Bus 702 mit einer beliebigen der Komponenten des Fahrzeugs 700 kommunizieren, und zwei oder mehr Busse 702 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jedes SoC 704, jede Steuerung 736 und/oder jeder Computer innerhalb des Fahrzeugs Zugang zu denselben Eingangsdaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 700) und kann mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 700 kann eine oder mehrere Steuerungen 736 enthalten, wie sie hier in Bezug auf 7A beschrieben sind. Die Steuerung(en) 736 kann (können) für eine Vielzahl von Funktionen verwendet werden. Die Steuerung(en) 736 kann (können) mit verschiedenen anderen Komponenten und Systemen des Fahrzeugs 700 gekoppelt werden und kann (können) zur Steuerung des Fahrzeugs 700, zur künstlichen Intelligenz des Fahrzeugs 700, zum Infotainment für das Fahrzeug 700 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 700 kann ein oder mehrere System(e) auf einem Chip („System on Chip“, SoC) 704 aufweisen. Das SoC 704 kann CPU(s) 706, GPU(s) 708, Prozessor(en) 710, Cache(s) 712, Beschleuniger 714, Datenspeicher 716 und/oder andere nicht dargestellte Komponenten und Merkmale aufweisen. Das (die) SoC(s) 704 kann (können) verwendet werden, um das Fahrzeug 700 in einer Vielzahl von Plattformen und Systemen zu steuern. Zum Beispiel kann das SoC (bzw. die SoCs) 704 in einem System (z. B. dem System des Fahrzeugs 700) mit einer HD-Karte 722 kombiniert werden, die Kartenauffrischungen und/oder Kartenaktualisierungen über eine Netzschnittstelle 724 von einem oder mehreren Servern (z. B. Server(n) 778 von 7D) erhalten kann.
  • Die CPU(s) 706 kann (können) einen CPU-Cluster oder CPU-Komplex (hier alternativ als „CCPLEX“ bezeichnet) umfassen. Die CPU(s) 706 kann (können) mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsformen kann (können) die CPU(s) 706 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsformen kann (können) die CPU(s) 706 vier Dual-Core-Cluster umfassen, wobei jeder Cluster einen dedizierten L2-Cache aufweist (z. B. einen 2 MB L2-Cache). Die CPU(s) 706 (z. B. der CCPLEX) kann (können) konfiguriert werden, um den gleichzeitigen Clusterbetrieb zu unterstützen, wodurch ermöglicht wird, dass eine beliebige Kombination von Clustern der CPU(s) 706 zu einem bestimmten Zeitpunkt aktiv ist.
  • Die CPU(s) 706 kann (können) Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale aufweisen: einzelne Hardwareblöcke können automatisch taktbegrenzt werden, wenn sie sich im Leerlauf befinden, um dynamische Energie zu sparen; jeder Kerntakt kann begrenzt werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig strombegrenzt sein; jeder Kerncluster kann unabhängig taktbegrenzt sein, wenn alle Kerne taktbegrenzt oder strombegrenzt sind; und/oder jeder Kerncluster kann unabhängig strombegrenzt sein, wenn alle Kerne strombegrenzt sind. Die CPU(s) 706 kann (können) darüber hinaus einen erweiterten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten festgelegt werden und die Hardware/der Mikrocode den besten Energiezustand bestimmt, der für den Kern, den Cluster und CCPLEX einzunehmen ist. Die Prozessorkerne können vereinfachte Sequenzen für den Eintritt in den Energiezustand in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
  • Die GPU(s) 708 kann (können) eine integrierte GPU (hier alternativ als „iGPU“ bezeichnet) umfassen. Die GPU(s) 708 kann (können) programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 708 kann (können) in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 708 kann (können) einen oder mehrere Streaming-Mikroprozessoren enthalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z. B. einen L1-Cache mit mindestens 96 KB Speicherkapazität) enthalten 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 kann (können) die GPU(s) 708 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPU(s) 708 kann (können) Anwendungsprogrammierschnittstelle(n) („Application Programming Interface(s)“, API(s)) für Berechnungen verwenden. Darüber hinaus kann (können) die GPU(s) 708 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
  • Die GPU(s) 708 kann (können) für die beste Leistung in automobilen und eingebetteten Anwendungsfällen energieoptimiert sein. Beispielsweise kann (können) die GPU(s) 708 auf einem Fin-Feldeffekttransistor (FinFET) hergestellt werden. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 708 kann (können) auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von in mehrere Blöcke unterteilten gemischt-präzisen Rechenkernen enthalten. So können beispielsweise 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt werden, ohne darauf beschränkt zu sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Präzision für Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64-KB-Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkommadatenpfade enthalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen bereitzustellen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfähigkeit aufweisen, um eine feingranulare Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsam genutzte Speichereinheit enthalten, um die Leistung zu verbessern und gleichzeitig das Programmieren zu vereinfachen.
  • Die GPU(s) 708 kann (können) einen Speicher mit hoher Bandbreite („High Bandwidth Memory“, HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, z. B. ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
  • Die GPU(s) 708 kann (können) eine Unified-Memory-Technologie mit Zugriffszählern enthalten, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz von Speicherbereichen verbessert wird, die von den Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, um der/den GPU(s) 708 zu ermöglichen, direkt auf die Seitentabellen der CPU(s) 706 zuzugreifen. In solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 708 einen Fehler feststellt, eine Adressübersetzungsanforderung an die CPU(s) 706 übertragen werden. Als Reaktion darauf kann (können) die CPU(s) 706 in ihren Seitentabellen nach der virtuell-physikalischen Abbildung für die Adresse suchen und die Übersetzung an die GPU(s) 708 zurückübertragen. Als solches kann die Unified-Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 706 als auch der GPU(s) 708 ermöglichen, wodurch die Programmierung der GPU(s) 708 und die Portierung von Anwendungen auf die GPU(s) 708 vereinfacht wird.
  • Darüber hinaus kann die GPU(s) 708 einen Zugriffszähler enthalten, der die Zugriffshäufigkeit der GPU(s) 708 auf den Speicher anderer Prozessoren nachverfolgen kann. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher von dem Prozessor verschoben werden, der am häufigsten auf die Seiten zugreift.
  • Das (die) SoC(s) 704 kann (können) eine beliebige Anzahl von Cache(s) 712 enthalten, einschließlich der hier beschriebenen. Der (die) Cache(s) 712 kann (können) beispielsweise einen L3-Cache enthalten, der sowohl der (den) CPU(s) 706 als auch der (den) GPU(s) 708 zur Verfügung steht (z. B. der sowohl mit der (den) CPU(s) 706 als auch mit der (den) GPU(s) 708 verbunden ist). Der (die) Cache(s) 712 kann (können) einen Rückschreib-Cache umfassen, der die Zustände von Zeilen nachverfolgen kann, z. B. durch Verwenden eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI, usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr aufweisen, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Das (die) SoC(s) 704 kann (können) eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die beim Durchführen einer Verarbeitung in Bezug auf eine beliebige Vielfalt von Aufgaben oder Operationen des Fahrzeugs 700 - wie die Verarbeitung von DNNs - wirksam eingesetzt werden kann. Darüber hinaus kann (können) das (die) SoC(s) 704 eine Gleitkommaeinheit(en) (FPU(s)) - oder andere mathematische Koprozessoren oder numerische Koprozessortypen - zum Durchführen mathematischer Operationen innerhalb des Systems aufweisen. Zum Beispiel kann (können) das (die) SoC(s) 504 eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in eine CPU(s) 706 und/oder GPU(s) 708 integriert sind.
  • Das (die) SoC(s) 704 kann (können) einen oder mehrere Beschleuniger 714 aufweisen (z. B. Hardwarebeschleuniger, Softwarebeschleuniger oder eine Kombination davon). Beispielsweise kann (können) das (die) SoC(s) 704 einen Hardware-Beschleunigungs-Cluster aufweisen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 708 und zur Entlastung einiger Aufgaben der GPU(s) 708 verwendet werden (z. B. um mehr Zyklen der GPU(s) 708 für das Durchführen anderer Aufgaben freizugeben). Der (die) Beschleuniger 714 kann (können) beispielsweise für gezielte Arbeitslasten (z. B. Wahrnehmung, faltende neuronale Netze („Convolutional Neural Networks“, CNNs) usw.) verwendet werden, die stabil genug sind, um beschleunigt werden zu können. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs einbeziehen, einschließlich regionenbasierter oder regionaler faltender neuronaler Netze (RCNNs) und schneller RCNNs (z. B. wie sie für die Objekterfassung verwendet werden).
  • Der (die) Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann (können) einen Deep-Learning-Beschleuniger („Deep Learning Accelerator“, DLA) aufweisen. Der (die) DLA(s) kann (können) eine oder mehrere Tensor Processing Einheiten (TPUs) aufweisen, die konfiguriert sein können, um zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und Inferencing bereitzustellen. Die TPUs können Beschleuniger sein, die konfiguriert und optimiert sind, um Bildverarbeitungsfunktionen auszuführen (z. B. für CNNs, RCNNs usw.). Der (die) DLA(s) kann (können) darüber hinaus für einen bestimmten Satz von neuronalen Netztypen und Fließkommaoperationen sowie für Inferencing optimiert sein. Das Design des (der) DLA(s) kann mehr Leistung pro Millimeter bereitstellen als eine Allzweck-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann (können) mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte unterstützt, sowie Postprozessorfunktionen.
  • Der (die) DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter beispielsweise und ohne Einschränkung: ein CNN für eine Objektidentifizierung und -erfassung unter Verwendung von Daten von Kamerasensoren; ein CNN für eine Entfernungsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für eine Notfallfahrzeugerkennung und -identifizierung und -erfassung unter Verwendung von Daten von Mikrofonen; ein CNN für eine Gesichtserkennung und eine 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) 708 ausführen, und durch Verwenden eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder den (die) DLA(s) oder die GPU(s) 708 für eine beliebige Funktion einsetzen. Zum Beispiel kann der Entwickler die Verarbeitung von CNNs und Gleitkommaoperationen auf den (die) DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 708 und/oder anderen Beschleuniger(n) 714 überlassen.
  • Der (die) Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann (können) einen programmierbaren Bildverarbeitungsbeschleuniger (PVA) aufweisen, der hier alternativ auch als Computer-Vision-Beschleuniger bezeichnet werden kann. Der (die) PVA(s) kann (können) ausgelegt und konfiguriert sein, um Computer-Vision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality- (AR) und/oder Virtual-Reality- (VR) Anwendungen zu beschleunigen. Der (die) PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. Zum Beispiel kann jeder PVA zum Beispiel und ohne Einschränkung eine beliebige Anzahl von Rechenkernen mit reduziertem Befehlssatz (RISC), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren aufweisen.
  • Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher aufweisen. Die RISC-Kerne können je nach Ausführungsform eine beliebige Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisvorrichtungen, anwendungsspezifischen integrierten Schaltkreisvorrichtungen (ASICs) und/oder Speichervorrichtungen implementiert werden. Zum Beispiel können die RISC-Kerne einen Befehls-Cache und/oder einen eng gekoppelten RAM enthalten.
  • Der DMA kann es Komponenten des (der) PVA(s) ermöglichen, unabhängig von der (den) CPU(s) 706 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die verwendet werden, um den PVA zu optimieren, einschließlich, aber nicht beschränkt auf, die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontales Block-Stepping, vertikales Block-Stepping und/oder Tiefen-Stepping aufweisen können.
  • Die Vektorprozessoren können programmierbare Prozessoren sein, die ausgelegt sein können, um die Programmierung für Computer-Vision-Algorithmen effizient und flexibel auszuführen und Signalverarbeitungsmöglichkeiten bereitzustellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen aufweisen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte aufweisen. Das Vektorverarbeitungs-Teilsystem kann als die primäre Verarbeitungseinheit des PVA arbeiten und kann eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) aufweisen. Ein VPU-Kern kann einen digitalen Signalprozessor aufweisen, z. B. einen digitalen Signalprozessor mit einem einzelnen Befehl für mehrere Daten („Single Instruction, Multiple Data“, SIMD) und sehr langen Befehlsworten („Very Long Instruction Word“, VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Befehls-Cache aufweisen und mit einem dedizierten Speicher verbunden sein. Als Ergebnis kann in einigen Beispielen jeder der Vektorprozessoren konfiguriert sein, unabhängig von den anderen Vektorprozessoren zu arbeiten. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, konfiguriert sein, um Datenparallelität zu verwenden. Zum Beispiel kann in einigen Ausführungsformen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten sind, den gleichen Computer-Vision-Algorithmus ausführen, aber auf verschiedenen Regionen eines Bildes. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, gleichzeitig verschiedene Computer-Vision-Algorithmen auf demselben Bild ausführen oder sogar verschiedene Algorithmen auf aufeinanderfolgenden Bildern oder Abschnitten eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungscluster vorhanden sein und eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Zusätzlich kann (können) der (die) PVA(s) einen zusätzlichen Fehlerkorrekturcode („Error Correcting Code“, ECC) Speicher aufweisen, um die Sicherheit des Gesamtsystems zu erhöhen.
  • Der (die) Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann (können) ein Computer-Vision-Netz auf einem Chip und SRAM aufweisen, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den (die) Beschleuniger 714 bereitzustellen. In einigen Beispielen kann der Speicher auf dem Chip mindestens 4 MB SRAM aufweisen, der beispielsweise und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, die sowohl für den PVA als auch für den DLA zugreifbar sein können. Jedes Paar von Speicherblöcken kann eine erweiterte Peripheriebus-Schnittstelle („Advanced Peripheral Bus“, APB), Konfigurationsschaltungen, eine Steuerung und einen Multiplexer aufweisen. Jede Art von Speicher kann verwendet werden. Der PVA und der DLA können auf den Speicher über ein Backbone zugreifen, das dem PVA und dem DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. Der Backbone kann ein Computer-Vision-Netz auf einem Chip aufweisen, das den PVA und den DLA mit dem Speicher verbindet (z. B. unter Verwendung des APB).
  • Das Computer-Vision-Netz auf dem Chip kann eine Schnittstelle aufweisen, die vor der Übertragung von beliebigen Steuersignalen/Adressen/Daten feststellt, dass sowohl der PVA als auch der DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
  • In einigen Beispielen kann (können) das (die) SoC(s) 704 einen Echtzeit-Raytracing-Hardwarebeschleuniger aufweisen, wie er in der am 10. August 2018 eingereichten US-Patentanmeldung Nr. 16/101,232 beschrieben ist. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu erzeugen, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für einen Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder anderer Funktionen und/oder für andere Verwendungen. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) für eine Ausführung einer oder mehrerer Raytracing-bezogener Operationen verwendet werden.
  • Der (die) Beschleuniger 714 (z. B. der Hardware-Beschleuniger-Cluster) hat (haben) eine breite Palette von Anwendungen für das autonome Fahren. Der PVA kann ein programmierbarer Bildverarbeitungs-Beschleuniger 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 Bereiche, die eine vorhersehbare Verarbeitung bei geringer Leistung und geringer Latenz benötigen. Mit anderen Worten: Der PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und geringem Stromverbrauch erfordern. Somit sind die PVAs im Zusammenhang von Plattformen für autonome Fahrzeuge für die Ausführung klassischer Computer-Vision-Algorithmen ausgelegt, da sie bei einer Objekterfassung effizient sind und mit ganzzahliger Mathematik arbeiten.
  • Zum Beispiel, gemäß einer Ausführungsform der Technologie, wird der PVA verwendet, um Computer-Stereo-Vision durchzuführen. Ein semi-globaler Matching-basierter Algorithmus kann in einigen Beispielen verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. Viele Anwendungen für das autonome Fahren der Stufen 3 bis 5 erfordern eine Bewegungsabschätzung / einen Stereoabgleich während des Betriebs (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspur-Erfassung usw.). Der PVA kann eine Computer-Stereo-Vision-Funktion auf Eingaben von zwei monokularen Kameras ausführen.
  • In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Entsprechend der Verarbeitung von RADAR-Rohdaten (z.B. unter Verwendung einer schnellen 4D-FourierTransformation), um verarbeitete RADAR-Daten bereitzustellen. In anderen Beispielen wird der PVA für die Flugzeittiefenverarbeitung verwendet, indem Flugzeitrohdaten verarbeitet werden, um z. B. verarbeitete Flugzeitdaten bereitzustellen.
  • Der DLA kann verwendet werden, um jede Art von Netz zu betreiben, um die Steuerung und die Fahrsicherheit zu verbessern, einschließlich beispielsweise eines neuronalen Netzes, das für jede Objekterfassung ein Maß für das Vertrauen ausgibt. Ein solcher Vertrauenswert kann als Wahrscheinlichkeit interpretiert werden oder als relatives „Gewicht“ für jede Erfassung im Vergleich zu anderen Erfassungen. Dieser Vertrauenswert ermöglicht es dem System, weitere Entscheidungen in Bezug darauf zu treffen, welche Erfassungen als echte positive Erfassungen und welche als falsch-positive Erfassungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellenwert für das Vertrauen festlegen und nur die Erfassungen, die diesen Schwellenwert überschreiten, als wahre positive Erfassungen betrachten. In einem automatischen Notbremssystem („Automatic Emergency Braking“, AEB) würden falsch positive Erfassungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die vertrauenswürdigsten Erfassungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Vertrauenswertes einsetzen. Das neuronale Netz kann als Eingabe zumindest eine Teilmenge von Parametern verwenden, wie z. B. Abmessungen eines Begrenzungsrahmens, eine (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, eine Ausgabe eines Trägheitssensors (Inertial Measurement Unit, IMU) 766, die mit der Ausrichtung des Fahrzeugs 700 korreliert, eine Entfernung, eine Schätzung der 3D-Position des Objekts, die von dem neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 764 oder RADAR-Sensor(en) 760) erhalten wurde, und andere.
  • Das (die) SoC(s) 704 kann (können) einen oder mehrere Datenspeicher 716 (z. B. einen Speicher) aufweisen. Der (die) Datenspeicher 716 kann (können) ein On-Chip-Speicher des (der) SoC(s) 704 sein, der (die) neuronale Netze speichern kann (können), die auf der GPU und/oder dem DLA ausgeführt werden. In einigen Beispielen kann die Kapazität des (der) Datenspeicher(s) 716 groß genug sein, um mehrere Instanzen von neuronalen Netzen aus Gründen der Redundanz und Sicherheit zu speichern. Der (die) Datenspeicher 712 kann (können) L2 oder L3 Cache(s) 712 umfassen. Ein Verweis auf den (die) Datenspeicher 716 kann einen Verweis auf den Speicher aufweisen, der dem PVA, DLA und/oder anderen Beschleunigern 714 zugeordnet ist, wie hierin beschrieben.
  • Das (die) SoC(s) 704 kann (können) einen oder mehrere Prozessor(en) 710 (z.B. eingebettete Prozessoren) aufweisen. Der (die) Prozessor(en) 710 kann (können) einen Boot- und Energieverwaltungsprozessor aufweisen, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Energie- und Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energieverwaltungsprozessor kann Teil einer Bootsequenz des (der) SoC(s) 704 sein und kann Laufzeit-Energieverwaltungsdienste bereitstellen. Der Boot-Energie- und Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen in einen Zustand mit geringer Leistung, Verwaltung von Temperaturen und Temperatursensoren von SoC(s) 704 und/oder Verwaltung von Energieversorgungszuständen der SoC(s) 704 bereitstellen. Jeder Temperatursensor kann als ein Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und das (die) SoC(s) 704 kann (können) die Ringoszillatoren verwenden, um Temperaturen der CPU(s) 706, GPU(s) 708 und/oder Beschleuniger 714 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energieverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und das (die) SoC(s) 704 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 700 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 700 zu einem sicheren Halt bringen).
  • Der (die) Prozessor(en) 710 kann (können) ferner einen Satz eingebetteter Prozessoren aufweisen, die als Audioverarbeitungsmaschine dienen können. Die Audioverarbeitungsmaschine kann ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungsmaschine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der (die) Prozessor(en) 710 kann (können) außerdem eine „immer eingeschaltet“-Prozessor-Maschine aufweisen, die die notwendigen Hardware-Funktionen bereitstellt, um ein Sensormanagement mit geringem Stromverbrauch und Aufwach-Anwendungsfälle zu unterstützen. Die „immer eingeschaltet“-Prozessor-Maschine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer und Interrupt-Steuerung), verschiedene E/A-Steuerungs-Peripheriegeräte und Routing-Logik aufweisen.
  • Der (die) Prozessor(en) 710 kann (können) außerdem eine Sicherheits-Cluster-Maschine aufweisen, die ein dediziertes Prozessor-Subsystem für das Sicherheitsmanagement von Automobilanwendungen aufweist. Die Sicherheits-Cluster-Maschine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Zeitgeber, eine Interrupt-Steuerung usw.) und/oder Routing-Logik aufweisen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit einer Vergleichslogik funktionieren, um etwaige Unterschiede zwischen ihren Operationen zu erfassen.
  • Der (die) Prozessor(en) 710 kann (können) ferner eine Echtzeit-Kamera-Maschine aufweisen, die ein dediziertes Prozessor-Subsystem zur Handhabung des Echtzeit-Kameramanagements aufweisen kann.
  • Der (die) Prozessor(en) 710 kann (können) ferner einen Signalprozessor mit hohem Dynamikbereich aufweisen, der einen Bildsignalprozessor aufweisen kann, der eine Hardware-Maschine ist, die Teil der Kameraverarbeitungspipeline ist.
  • Der (die) Prozessor(en) 710 kann (können) einen Videobildkompositor aufweisen, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Abspielfenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der (den) Weitwinkelkamera(s) 770, der (den) Surround-Kamera(s) 774 und/oder an den Sensoren der Überwachungskamera in der Fahrgastzelle vornehmen. Der Überwachungskamerasensor in der Fahrgastzelle wird vorzugsweise von einem neuronalen Netz überwacht, das auf einer anderen Instanz des erweiterten SoC läuft, das ausgelegt ist, Ereignisse in der Fahrgastzelle zu erkennen und entsprechend zu reagieren. Ein System in der Fahrgastzelle kann ein Lippenlesen durchführen, um einen Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrzeugfahrtziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen sind dem Fahrer nur verfügbar, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
  • Der Videobildkompositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl für räumliche als auch für zeitliche Rauschunterdrückung aufweisen. Wenn beispielsweise Bewegungen in einem Video auftreten, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der von benachbarten Einzelbildern gelieferten Informationen. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung aufweist, kann die vom Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
  • Der Videobildkompositor kann auch konfiguriert sein, um eine Stereorektifizierung an eingegebenen Stereo-Einzelbildern durchzuführen. Der Videobildkompositor kann ferner für die Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 708 nicht benötigt werden, um ständig neue Oberflächen zu rendern. Selbst wenn der (die) Grafikprozessor(en) 708 eingeschaltet und aktiv mit dem 3D-Rendering beschäftigt ist (sind), kann der Videobildkompositor verwendet werden, um den (die) Grafikprozessor(en) 708 zu entlasten, um die Leistung und Reaktionsfähigkeit zu verbessern.
  • Das (die) SoC(s) 704 kann (können) ferner eine serielle mobile Industrieprozessorschnittstelle („Mobile Industry Processor Interface“, MIPI)-Kameraschnittstelle für den Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock aufweisen, die/der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Das (die) SoC(s) 704 kann (können) ferner eine Eingabe/Ausgabe-Steuerung(en) aufweisen, die durch Software gesteuert werden kann (können) und für den Empfang von E/A-Signalen verwendet werden kann (können), die nicht an eine bestimmte Rolle gebunden sind.
  • Das (die) SoC(s) 704 kann (können) weiterhin eine breite Palette von Peripherieschnittstellen aufweisen, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energieverwaltung und/oder anderen Geräten zu ermöglichen. Das (die) SoC(s) 704 kann (können) verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 764, RADAR-Sensor(en) 760 usw., die über Ethernet verbunden sein können), Daten vom Bus 702 (z. B. Geschwindigkeit des Fahrzeugs 700, Lenkradposition usw.), Daten von GNSS-Sensor(en) 758 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das (die) SoC(s) 704 kann (können) ferner dedizierte Hochleistungs-Massenspeichersteuerungen aufweisen, die ihre eigenen DMA-Maschinen aufweisen können und die verwendet werden können, um die CPU(s) 706 von routinemäßigen Datenverwaltungsaufgaben zu entlasten.
  • Das (die) SoC(s) 704 kann (können) eine Ende zu Ende Plattform mit einer flexiblen Architektur sein, die die Automatisierungsebenen 3-5 überspannt und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die Computer Vision und ADAS-Techniken für Diversität und Redundanz nutzt, eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Werkzeugen für Deep Learning bereitstellt und diese effizient einsetzt. Das (die) SoC(s) 704 kann (können) schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel kann (können) der (die) Beschleuniger 714, wenn er (sie) mit der (den) CPU(s) 706, der (den) GPU(s) 708 und dem (den) Datenspeicher(n) 716 kombiniert wird (werden), eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
  • Die Technologie bietet somit Möglichkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Computer-Vision-Algorithmen auf CPUs ausgeführt werden, die unter Verwendung von High-Level-Programmiersprachen, wie der Programmiersprache C, konfiguriert werden können, um eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von visuellen Daten auszuführen. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Computer-Vision-Anwendungen zu erfüllen, z. B. in Bezug auf die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterfassungsalgorithmen in Echtzeit auszuführen, was eine Voraussetzung für ADAS-Anwendungen im Fahrzeug und eine Voraussetzung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
  • Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch Bereitstellen eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters, dass mehrere neuronale Netze gleichzeitig und/oder nacheinander ausgeführt und die Ergebnisse miteinander kombiniert werden können, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder der dGPU (z. B. die GPU(s) 720) ausgeführt wird, eine Text- und Worterkennung aufweisen, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schilder, für die das neuronale Netz nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netz aufweisen, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis dafür bereitzustellen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
  • Als weiteres Beispiel können mehrere neuronale Netze gleichzeitig ausgeführt werden, wie es für das Fahren der Stufe 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Eisglätte hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem neuronalen Netz, das trainiert wurde) als ein Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Eisglätte hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das der Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) mitteilt, dass, wenn blinkende Lichter erfasst werden, Eisglätte vorliegt. Das Blinklicht kann durch Betreiben eines dritten neuronalen Netzes über mehrere Einzelbilder identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. innerhalb des DLA und/oder auf der (den) GPU(s) 708.
  • In einigen Beispielen kann ein CNN für eine Gesichtserkennung und die Identifizierung eines Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 700 zu identifizieren. Die „immer eingeschaltete" Sensorverarbeitungsmaschine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert, und die Lichter einschalten, und, im Sicherheitsmodus, um das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise stellt (stellen) das (die) SoC(s) 704 die Sicherheit gegen Diebstahl und/oder Fahrzeugentführung sicher.
  • In einem anderen Beispiel kann ein CNN zur Erfassung und Identifizierung von Notfallfahrzeugen Daten von Mikrofonen 796 verwenden, um Sirenen von Notfallfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erfassung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzt (nutzen) das (die) SoC(s) 704 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einer bevorzugten Ausführungsform wird der CNN, der auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Notfallfahrzeugs zu erkennen (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch trainiert werden, um Einsatzfahrzeuge zu identifizieren, die spezifisch für den lokalen Bereich sind, in dem das Fahrzeug betrieben wird, wie von GNSS-Sensor(en) 758 identifiziert. So wird das CNN beispielsweise versuchen, in Europa europäische Sirenen zu erfassen, während es in den Vereinigten Staaten versuchen wird, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Notfallfahrzeug erfasst wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Notfallfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, mit Hilfe von Ultraschallsensoren 762, bis das (die) Notfallfahrzeug(e) vorbeigefahren ist (sind).
  • Das Fahrzeug kann eine CPU(s) 718 (z.B. diskrete CPU(s) oder dCPU(s)) aufweisen, die über eine Hochgeschwindigkeitsverbindung (z.B. PCIe) mit dem (den) SoC(s) 704 gekoppelt sein kann. Die CPU(s) 718 kann (können) zum Beispiel einen X86-Prozessor aufweisen. Die CPU(s) 718 kann (können) verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich eines Abstimmens potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und dem (den) SoC(s) 704 und/oder eines Überwachens des Status und des Zustands der Steuerung(en) 736 und/oder des Infotainment-SoC 730, zum Beispiel.
  • Das Fahrzeug 700 kann eine GPU(s) 720 (z.B. diskrete GPU(s) oder dGPU(s)) aufweisen, die mit dem (den) SoC(s) 704 über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) gekoppelt sein kann. Der (die) GPU(s) 720 kann (können) zusätzliche künstliche Intelligenzfunktionalität bereitstellen, zum Beispiel durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netze, und kann (können) verwendet werden, um neuronale Netze auf der Grundlage einer Eingabe (z. B. Sensordaten) von Sensoren des Fahrzeugs 700 zu trainieren und/oder zu aktualisieren.
  • Das Fahrzeug 700 kann ferner die Netzschnittstelle 724 aufweisen, die eine oder mehrere drahtlose Antennen 726 aufweisen kann (z.B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie z.B. eine Mobilfunkantenne, eine Bluetooth-Antenne, usw.). Die Netzschnittstelle 724 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem (den) Server(n) 778 und/oder anderen Netzvorrichtungen), mit anderen Fahrzeugen und/oder mit Recheneinrichtungen (z. B. Client-Vorrichtungen der Fahrgäste) zu ermöglichen. Um mit anderen Fahrzeugen zu kommunizieren, kann eine direkte Verbindung zwischen den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z. B. über Netze und über das Internet). Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 700 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 700 bereitstellen (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 700). Diese Funktion kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 700 sein.
  • Die Netzschnittstelle 724 kann über ein SoC verfügen, das Modulation und Demodulation bietet und es der Steuerung 736 ermöglicht, über drahtlose Netze zu kommunizieren. Die Netzschnittstelle 724 kann ein Hochfrequenz-Front-End für die Up-Konvertierung von Basisband zu Hochfrequenz und Down-Konvertierung von Hochfrequenz zu Basisband enthalten. Die Frequenzumwandlungen können durch bekannte Prozesse und/oder durch Super-Heterodyn-Prozesse durchgeführt werden. In einigen Beispielen kann die Funkfrequenz-Frontend-Funktion durch einen separaten Chip bereitgestellt werden. Die Netzschnittstelle kann drahtlose Funktionen für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle umfassen.
  • Das Fahrzeug 700 kann außerdem Datenspeicher 728 enthalten, die auch Off-Chip-Speicher (z. B. Off-the-SoC 704) umfassen können. Die Datenspeicher 728 können ein oder mehrere Speicherelemente einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Bit von Daten speichern können, umfassen.
  • Das Fahrzeug 700 kann außerdem einen oder mehrere GNSS-Sensoren 758 enthalten. Die GNSS-Sensoren 758 (z. B. GPS, unterstützte GPS-Sensoren, differenzielle GPS-Sensoren (differential GPS - DGPS) usw.) unterstützen bei der Kartierung, Wahrnehmung, Generierung von Belegungsrastern und/oder der Wegplanung. Es kann eine beliebige Anzahl von GNSS-Sensoren 758 verwendet werden, einschließlich z. B. eines GPS-Geräts, das einen USB-Anschluss mit einer Ethernet-zu-Seriell-Brücke (RS-232) verwendet.
  • Das Fahrzeug 700 kann außerdem einen oder mehrere RADAR-Sensoren 760 enthalten. Der RADAR-Sensor 760 kann vom Fahrzeug 700 für die Fernerkennung von Fahrzeugen verwendet werden, selbst bei Dunkelheit und/oder bei Unwetter. Die funktionalen Sicherheitsstufen des RADARs können ASIL B sein. Der RADAR-Sensor 760 kann den CAN und/oder den Bus 702 (z. B. zur Übertragung der vom RADAR-Sensor 760 generierten Daten) zur Steuerung und zum Zugriff auf Daten zur Objektverfolgung verwenden, wobei in einigen Beispielen auf Ethernet zugegriffen werden kann, um auf Rohdaten zuzugreifen. Es können eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise können die RADAR-Sensoren 760 uneingeschränkt als Front-, Heck- und Seiten-RADAR verwendet werden. In einigen Beispielen werden Pulse-Doppler-RADAR-Sensoren verwendet.
  • Die RADAR-Sensoren 760 können verschiedene Konfigurationen umfassen, z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit großem Sichtfeld, kurze Seitenabdeckung usw. In einigen Beispielen kann ein Langstrecken-RADAR für die adaptive Geschwindigkeitsregelung verwendet werden. Die Langstrecken-RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld, das durch zwei oder mehr unabhängige Scans, z. B. innerhalb einer Reichweite von 250 m, realisiert wird, bieten. Die RADAR-Sensoren 760 können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und von ADAS-Systemen zur Notbremsunterstützung und Kollisionswarnung verwendet werden. Langstrecken-RADAR-Sensoren für große Reichweiten können monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die zentralen vier Antennen ein fokussiertes Strahlmuster erzeugen, das entwickelt wurde, um die Umgebung des Fahrzeugs 700 bei höheren Geschwindigkeiten mit minimaler Beeinträchtigung durch den Verkehr in benachbarten Fahrbahnen aufzuzeichnen. Die anderen beiden Antennen können das Sichtfeld erweitern, wodurch es möglich ist, schnell Fahrzeuge zu erkennen, die in die Fahrbahn des Fahrzeugs 700 fahren oder diese verlassen.
  • RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 160 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 150 Grad (hinten) umfassen. RADAR-Systeme mit kurzer Reichweite können, ohne Einschränkung, RADAR-Sensoren umfassen, die an beiden Enden des hinteren Stoßfängers installiert werden können. Bei Installation an beiden Enden des hinteren Stoßfängers können solche RADAR-Sensorsysteme zwei Strahlen erzeugen, die den toten Winkel im Heck und neben dem Fahrzeug ständig überwachen.
  • RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Fahrbahnwechselunterstützung verwendet werden.
  • Das Fahrzeug 700 kann außerdem Ultraschallsensoren 762 enthalten. Die Ultraschallsensoren 762, die sich vorne, hinten und/oder an den Seiten des Fahrzeugs 700 befinden können, können zum Einparken und/oder zum Erstellen und Aktualisieren eines Belegungsrasters verwendet werden. Es können eine Vielzahl von Ultraschallsensoren 762 und verschiedene Ultraschallsensoren 762 für verschiedene Detektionsbereiche (z. B. 2,5 m, 4 m) verwendet werden. Die Ultraschallsensoren 762 können mit der Funktionssicherheitsstufe ASIL B arbeiten.
  • Das Fahrzeug 700 kann LIDAR-Sensoren 764 enthalten. Die LIDAR Sensoren 764 können für die Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Die LIDAR-Sensoren 764 können die funktionale Sicherheitsstufe ASIL B erfüllen. In einigen Beispielen kann das Fahrzeug 700 mehrere LIDAR-Sensoren 764 (z. B. zwei, vier, sechs usw.) enthalten, die Ethernet verwenden können (z. B. zur Bereitstellung von Daten an einen Gigabit-Ethernet-Switch).
  • In einigen Beispielen können die LIDAR-Sensoren 764 eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld bereitstellen. Im Handel erhältliche LIDAR-Sensoren 764 können eine angekündigte Reichweite von etwa 700 m, eine Genauigkeit von 2 cm bis 3 cm und beispielsweise eine Unterstützung für eine 100-Mbit/s-Ethernet-Verbindung aufweisen. In einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 764 verwendet werden. In solchen Beispielen können die LIDAR-Sensoren 764 als kleines Gerät implementiert werden, das in die Front-, Heck-, Seiten- und/oder Ecken des Fahrzeugs 700 eingebettet werden kann. Die LIDAR-Sensoren 764 können in solchen Beispielen ein bis zu 120 Grad horizontales und 35 Grad vertikales Sichtfeld mit einer Reichweite von 200 m bieten, selbst bei Objekten mit geringer Reflexion. Front-montierte LIDAR-Sensoren 764 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
  • In einigen Beispielen können auch LIDAR-Technologien wie 3D-Flash-LIDAR verwendet werden. 3D-Flash-LIDAR nutzt einen Laserblitz als Übertragungsquelle, um die Fahrzeugumgebung bis zu ca. 200 m zu beleuchten. Eine LIDAR-Blitzeinheit enthält einen Rezeptor, der die Übertragungszeit des Laserpulses und das reflektierte Licht auf jedem Pixel erfasst, was wiederum dem Bereich vom Fahrzeug bis zu den Objekten entspricht. Flash LIDAR kann die Erzeugung hochgenauer und verzerrungsfreier Bilder der Umgebung mit jedem Laserblitz ermöglichen. In einigen Beispielen können vier LIDAR-Blitzsensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 700. Zu den verfügbaren 3D-Flash-LIDAR-Systemen gehört eine Solid-State-3D-Staring-Array-LIDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z. B. ein nicht-scannendes LIDAR-Gerät). Das Flash-LIDAR-Gerät kann einen Laserpuls der Klasse I (augensicher) mit 5 Nanosekunden pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Punktwolken und mitregistrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR ein Festkörpergerät ohne bewegliche Teile ist, ist der LIDAR-Sensor 764 möglicherweise weniger anfällig für Bewegungsunschärfen, Vibrationen und/oder Stöße.
  • Das Fahrzeug kann außerdem IMU-Sensoren 766 enthalten. Die IMU-Sensoren 766 können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 700 befinden. Die IMU-Sensoren 766 können z. B. einen oder mehrere Beschleunigungsmesser, Magnetometer, Gyroskope, magnetische Kompasse und/oder andere Sensortypen umfassen. In einigen Beispielen, wie z. B. in sechs-Achsen-Anwendungen, können die IMU-Sensoren 766 Beschleunigungsmesser und Gyroskope enthalten, während in neun-Achsen-Anwendungen die IMU-Sensoren 766 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
  • In einigen Ausführungsformen können die IMU-Sensoren 766 als Miniatur-GPS-Aided Inertial Navigation System (GPS/INS) implementiert werden, das Inertialsensoren mikroelektromechanischer Systeme (micro-electromechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Abschätzungen von Position, Geschwindigkeit und Neigung zu liefern. In einigen Beispielen können die IMU-Sensoren 766 es dem Fahrzeug 700 ermöglichen, den Kurs ohne Eingabe eines Magnetsensors zu schätzen, indem die Geschwindigkeitsänderungen vom GPS direkt auf den IMU-Sensoren 766 beobachtet und korreliert werden. In einigen Beispielen können IMU-Sensoren 766 und GNSS-Sensoren 758 in einer einzigen integrierten Einheit kombiniert werden.
  • Das Fahrzeug kann mit Mikrofonen 796 ausgestattet sein, die in und/oder um das Fahrzeug 700 platziert sind. Die Mikrofone 796 können unter anderem zur Erkennung und Identifizierung von Rettungsfahrzeugen verwendet werden.
  • Das Fahrzeug kann außerdem eine beliebige Anzahl von Kameratypen umfassen, einschließlich Stereokameras 768, Weitwinkelkameras 770, Infrarotkameras 772, Surround-Kameras 774, Fernbereichs- und Mittelbereichskameras 798 und/oder andere Kameratypen. Mit den Kameras können Bilddaten rund um eine gesamte Peripherie des Fahrzeugs 700 herum erfasst werden. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen für das Fahrzeug 700 ab, und jede Kombination von Kameratypen kann verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 700 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform variieren. Zum Beispiel kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras umfassen. Die Kameras können beispielsweise und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede Kamera wird in diesem Dokument in Bezug auf 7A und 7B beschrieben.
  • Das Fahrzeug 700 kann außerdem Vibrationssensoren 742 enthalten. Die Vibrationssensoren 742 können Vibrationen von Komponenten des Fahrzeugs, z.B. den Achsen, messen. Veränderungen der Vibrationen können beispielsweise auf eine Veränderung der Straßenbeläge hindeuten. In einem anderen Beispiel können bei Verwendung von zwei oder mehr Vibrationssensoren 742 die Unterschiede zwischen den Vibrationen zur Bestimmung der Reibung oder des Schlupfes der Fahrbahnoberfläche verwendet werden (z. B. wenn der Vibrationsunterschied zwischen einer elektrisch angetriebenen und einer frei drehenden Achse besteht).
  • Das Fahrzeug 700 kann ein ADAS-System 738 enthalten. Das ADAS-System 738 kann in einigen Beispielen ein SoC enthalten. Das ADAS-System 738 kann autonome/adaptive/automatische Geschwindigkeitsregelung (autonomous/adaptive/automatic cruise control - ACC), kooperative adaptive Geschwindigkeitsregelung (cooperative adaptive cruise control - CACC), Aufprallwarnung (forward crash warning - FCW), automatische Notbremsung (automatic emergency braking - AEB), Spurerkennungssystem (lane departure warning - LDW), Spurhalteassistent (lane keep assistent - LKA), Totwinkel-Warner (blind spot warning - BSW), Heckbereichswarnung (rear cross-traffic warning - RCTW), Kollisionswarnsysteme (collision warning system - CWS), Fahrbahnzentrierung (lane centering - LC) und/oder andere Merkmale und Funktionalitäten umfassen.
  • Die ACC-Systeme können RADAR-Sensoren 760, LIDAR-Sensoren 764 und/oder Kameras verwenden. Die ACC-Systeme können longitudinales ACC und/oder laterales ACC umfassen. Das ACC in Längsrichtung überwacht und steuert den Abstand zum Fahrzeug unmittelbar vor dem Fahrzeug 700 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu den vorausfahrenden Fahrzeugen einzuhalten. Das laterale ACC führt die Distanzmessung durch und rät dem Fahrzeug 700, bei Bedarf die Fahrbahn zu wechseln. Das laterale ACC steht in Zusammenhang mit anderen ADAS-Anwendungen wie LCA und CWS.
  • CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzschnittstelle 724 und/oder die drahtlosen Antenne(n) 726 von anderen Fahrzeugen über eine Wireless-Verbindung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verbindungen können über eine V2V-Kommunikationsverbindung (Vehicle-to-Vehicle) bereitgestellt werden, während indirekte Verbindungen eine I2V-Kommunikationsverbindung (Infrastructure-to-Vehicle) sein können. Das Kommunikationskonzept V2V informiert in der Regel über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge unmittelbar vor und auf derselben Fahrbahn wie das Fahrzeug 700), während das Kommunikationskonzept I2V Informationen über den weiteren vorausfahrenden Verkehr liefert. CACC-Systeme können eine oder beide 12V- und V2V-Informationsquellen enthalten. Angesichts der Informationen über die Fahrzeuge vor dem Fahrzeug 700 könnte CACC zuverlässiger sein und das Potenzial haben, die Verkehrsströme zu verbessern und Staus auf der Straße zu reduzieren.
  • FCW-Systeme wurden entwickelt, um den Fahrer auf eine Gefahr aufmerksam zu machen, damit der Fahrer Korrekturmaßnahmen ergreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensoren 760 gekoppelt an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Schalls, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-Systeme erkennen einen drohenden Aufprall mit einem anderen Fahrzeug oder einem anderen Objekt und können die Bremsen automatisch betätigen, wenn der Fahrer innerhalb eines bestimmten Zeit- oder Entfernungsparameters keine Korrekturmaßnahmen ergreift. AEB-Systeme können nach vorne gerichtete Kameras und/oder RADAR-Sensoren 760 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, warnt es den Fahrer normalerweise zuerst, Korrekturmaßnahmen zu ergreifen, um die Kollision zu vermeiden. Wenn der Fahrer keine Korrekturmaßnahmen ergreift, kann das AEB-System die Bremsen automatisch betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern, oder zumindest zu mildern. AEB-Systeme können Techniken wie dynamische Bremsunterstützung und/oder Notbremsung umfassen.
  • LDW-Systeme bieten optische, akustische und/oder taktile Warnungen, wie z. B. Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 700 die Fahrbahnmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer durch Aktivieren eines Blinksignals einen absichtlichen Fahrbahnwechsel anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, gekoppelt an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme bieten Lenkeingaben oder Bremsen, um das Fahrzeug 700 zu korrigieren, wenn das Fahrzeug 700 die Fahrbahn verlässt.
  • BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen im toten Winkel eines Automobils. BSW-Systeme können einen visuellen, akustischen und/oder taktilen Alarm ausgeben, der darauf hinweist, dass das Zusammenführen oder Wechseln von Fahrbahnen unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker verwendet. BSW-Systeme können rückseitig ausgerichtete Kameras und/oder RADAR-Sensoren 760 verwenden, gekoppelt mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können visuelle, akustische und/oder taktile Benachrichtigungen liefern, wenn ein Objekt außerhalb des Bereichs der Rückfahrkamera erkannt wird, wenn das Fahrzeug 700 rückwärtsfährt. Einige RCTW-Systeme verfügen über AEB, um sicherzustellen, dass die Bremsen des Fahrzeugs aktiviert werden, um einen Unfall zu vermeiden. RCTW-Systeme können eine oder mehrere nach hinten gerichtete RADAR-Sensoren 760 verwenden, gekoppelt mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • Herkömmliche ADAS-Systeme können zu falsch positiven Ergebnissen neigen, die für den Fahrer störend und ablenkend sein können, aber in der Regel nicht katastrophal sind, da die ADAS-Systeme den Fahrer alarmieren und es dem Fahrer ermöglichen, zu entscheiden, ob eine Sicherheitsbedingung tatsächlich vorliegt, und entsprechend zu handeln. Bei einem autonomen Fahrzeug 700 muss das Fahrzeug 700 selbst jedoch bei widersprüchlichen Ergebnissen entscheiden, ob das Ergebnis eines primären oder eines sekundären Computers (z. B. einer ersten Steuerung 736 oder einer zweiten Steuerung 736) berücksichtigt werden soll. In einigen Ausführungsformen kann das ADAS-System 738 beispielsweise ein Backup- und/oder Sekundärcomputer sein, um Wahrnehmungsinformationen für ein Rationalitätsmodul des Backup-Computers bereitzustellen. Auf dem Monitor zur Rationalität des Backup-Computers kann eine redundante, vielfältige Software auf Hardwarekomponenten ausgeführt werden, um Wahrnehmungsfehler und dynamische Fahraufgaben zu erkennen. Ausgaben von dem ADAS-System 738 können an eine übergeordnete MCU geliefert werden. Wenn Ausgaben von dem primären Computer und von dem sekundären Computer in Konflikt geraten, muss die übergeordnete MCU bestimmen, wie der Konflikt abgeglichen werden kann, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der primäre Computer konfiguriert werden, um der übergeordneten MCU einen Konfidenzwert bereitzustellen, der die Konfidenz des primären Computers in das ausgewählte Ergebnis angibt. Wenn der Konfidenzwert einen Schwellenwert überschreitet, kann die übergeordnete MCU der Richtung des primären Computers folgen, unabhängig davon, ob der sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Wenn der Konfidenzwert den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse (z. B. den Konflikt) anzeigen, kann die übergeordnete MCU zwischen den Computern entscheiden, um das geeignete Ergebnis zu ermitteln.
  • Die übergeordnete MCU kann konfiguriert sein, um ein neuronales Netz laufen zu lassen, das ausgebildet und konfiguriert ist, um basierend auf den Ausgaben des primären Computers und des sekundären Computers Bedingungen zu bestimmen, unter denen der sekundäre Computer Fehlalarme ausgibt. So können die neuronalen Netze in der übergeordneten MCU lernen, wann die Ausgabe des sekundären Computers vertrauenswürdig ist und wann nicht. Wenn es sich bei dem sekundären Computer beispielsweise um ein RADAR-basiertes FCW-System handelt, können neuronale Netze in der übergeordneten MCU erkennen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahren darstellen, wie z. B. ein Drainagerost oder eine Schachtabdeckung, die einen Alarm auslöst. Wenn es sich bei dem sekundären Computer um ein kamerabasiertes LDW-System handelt, kann ein neuronales Netz in der übergeordneten MCU lernen, das LDW zu überschreiben, wenn Radfahrer oder Fußgänger anwesend sind und ein Fahrbahnwechsel tatsächlich das sicherste Manöver ist. In Ausführungsformen, die ein neuronales Netz enthalten, das auf der übergeordneten MCU ausgeführt wird, kann die übergeordnete MCU mindestens eine DLA oder GPU enthalten, die für den Betrieb des neuronalen Netzes mit dem zugehörigen Speicher geeignet ist. In bevorzugten Ausführungsformen kann die übergeordnete MCU als Bestandteil des SoCs 704 enthalten und/oder einbezogen werden.
  • In anderen Beispielen kann das ADAS-System 738 einen sekundären Computer umfassen, der die ADAS-Funktionalität mithilfe herkömmlicher Regeln der Computervision ausführt. Daher kann der sekundäre Computer klassische Computervision-Regeln (wenn-dann) verwenden und das Vorhandensein eines neuronalen Netzes in der übergeordneten MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Die vielfältige Implementierung und die absichtliche Nichtidentität beispielsweise machen das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch die Funktionalität der Software (oder Software-Hardware-Schnittstelle) verursacht werden. Wenn beispielsweise ein Softwarefehler oder Fehler in der Software auf dem primären Computer vorliegt und der nicht identische Softwarecode auf dem sekundären Computer das gleiche Gesamtergebnis liefert, kann die übergeordnete MCU mehr Vertrauen in das Gesamtergebnis haben und der Fehler in der Software oder Hardware auf dem primären Computer verursacht keinen erheblichen Fehler.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 738 in den Wahrnehmungs-Block des primären Computers und/oder den dynamischen Fahraufgaben-Block des primären Computers eingespeist werden. Wenn das ADAS-System 738 beispielsweise eine Aufprallwarnung aufgrund eines unmittelbar vorausliegenden Objekts anzeigt, kann der Wahrnehmungs-Block diese Informationen bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer über ein eigenes ausgebildetes neuronales Netz verfügen und so das Risiko von falsch-positiven Ergebnissen reduzieren, wie hier beschrieben.
  • Das Fahrzeug 700 kann außerdem das Infotainment-SoC 730 (z. B. ein Fahrzeug-Infotainment-System (in-vehicle infotainment, IVI)) enthalten. Obwohl das Infotainment-System als SoC dargestellt und beschrieben wird, handelt es sich möglicherweise nicht um ein SoC und kann zwei oder mehr separate Komponenten enthalten. Das Infotainment-SoC 730 kann eine Kombination aus Hardware und Software umfassen, die verwendet werden kann, um dem Fahrzeug 700 Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechfunktion), Netzwerkkonnektivität (z. B. LTE, Wi-Fi, Usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Funkdatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremsflüssigkeitsstand, Ölstand, Tür auf/zu, Luftfilterinformationen usw.) bereitzustellen. Zum Beispiel kann das Infotainment-SoC 730 Radios, CD-Player, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Lenkrad-Audiosteuerungen, Freisprech-Sprachsteuerung, ein Heads-Up-Display (HUD), ein HMI-Anzeige 734, ein Telematikgerät, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder anderen Komponenten umfassen. Das Infotainment-SoC 730 kann außerdem dazu verwendet werden, Informationen (z. B. visuell und/oder hörbar) für Benutzer des Fahrzeugs bereitzustellen, z. B. Informationen aus dem ADAS-System 738, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsdaten (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Das Infotainment-SoC 730 kann GPU-Funktionalität enthalten. Das Infotainment-SoC 730 kann über den Bus 702 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 700 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 730 mit einer übergeordneten MCU gekoppelt werden, sodass die GPU des Infotainment-Systems einige Selbstfahr-Funktionen ausführen kann, falls die primäre Steuerung 736 (z. B. der primäre und/oder Backup-Computer des Fahrzeugs 700) ausfällt. In einem solchen Beispiel kann das Infotainment-SoC 730 das Fahrzeug 700 in den sicheren Stopp-Modus versetzen, wie hier beschrieben.
  • Das Fahrzeug 700 kann außerdem ein Kombiinstrument 732 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) enthalten. Das Kombiinstrument 732 kann eine Steuerung und/oder Supercomputer (z. B. eine diskrete Steuerung oder Supercomputer) enthalten. Das Kombiinstrument 732 kann eine Reihe von Instrumenten wie Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurtwarnleuchte(n), Feststellbremse-Warnleuchte(n), Motorstörungsanzeige(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Bedienelemente des Sicherheitssystems, Navigationsinformationen usw. umfassen. In einigen Beispielen können Informationen angezeigt und/oder zwischen dem Infotainment-SoC 730 und dem Kombiinstrument 732 geteilt werden. Mit anderen Worten kann das Kombiinstrument 732 als Teil des Infotainment-SoC 730 oder umgekehrt aufgenommen werden.
  • 7D ist ein Systemdiagramm für die Kommunikation zwischen Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug 700 aus 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 776 kann Server 778, Netze 790 und Fahrzeuge einschließlich Fahrzeug 700 umfassen. Die Server 778 können eine Vielzahl von GPUs 784(A)-784(H) (zusammenfassend als GPUs 784 bezeichnet), PCle-Switches 782(A)-782(H) (gemeinsam als PCIe-Switches 782 bezeichnet) und/oder CPUs 780(A)-780(B) (gemeinsam als CPUs 780 bezeichnet) enthalten. Die GPUs 784, die CPUs 780 und die PCle-Switches können mit Hochgeschwindigkeitsverbindungen wie beispielsweise den von NVIDIA entwickelten NVLink-Schnittstellen 788 und/oder PCIe Connections 786 verbunden werden. In einigen Beispielen werden die GPUs 784 über NVLink und/oder NVSwitch SoC angeschlossen und die GPUs 784 und die PCle-Switches 782 über PCle-Verbindungen. Obwohl acht GPUs 784, zwei CPUs 780 und zwei PCIe-Switches abgebildet sind, soll dies nicht als einschränkend verstanden werden. Je nach Ausführungsform kann jeder Server 778 eine beliebige Anzahl von GPUs 784, CPUs 780 und/oder PCIe-Switches enthalten. Zum Beispiel können die Server 778 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 784 enthalten.
  • Die Server 778 können über die Netze 790 und von den Fahrzeugen Bilddaten empfangen, die für Bilder stehen, die unerwartete oder veränderte Straßenbedingungen zeigen, wie z. B. kürzlich begonnene Straßenarbeiten. Die Server 778 können, über die Netze 790 und an die Fahrzeuge, neuronale Netze 792, aktualisierte neuronale Netze 792 und/oder Karteninformationen 794 übertragen, einschließlich Informationen über den Verkehr und die Straßenbedingungen. Die Aktualisierungen der Karteninformationen 794 können Aktualisierungen für die HD-Karte 722 enthalten, wie z. B. Informationen zu Baustellen, Schlaglöchern, Umwegen, Überschwemmungen und/oder anderen Hindernissen. In einigen Beispielen können die neuronalen Netze 792, die aktualisierten neuronalen Netze 792 und/oder die Karteninformationen 794 aus neuen Trainings und/oder Erfahrungen resultieren, dargestellt in Daten aus einer beliebigen Anzahl von Fahrzeugen in der Umgebung, und/oder basierend auf Trainings, die in einem Rechenzentrum durchgeführt werden (z.B. unter Verwendung der Server 778 und/oder anderer Server).
  • Die Server 778 können verwendet werden, um Machine-Learning-Modelle (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen generiert und/oder in einer Simulation (z. B. mit einem Game Engine) generiert werden. In einigen Beispielen werden die Trainingsdaten markiert (z. B. wenn das neuronale Netz vom überwachten Lernen profitiert) und/oder unterliegen einer anderen Vorverarbeitung, während in anderen Beispielen die Trainingsdaten nicht markiert und/oder vorverarbeitet werden (z. B. wenn das neuronale Netz kein überwachtes Lernen erfordert). Trainings können nach einer oder mehreren Klassen von Machine-Learning-Techniken durchgeführt werden, einschließlich, aber nicht beschränkt auf Kurse wie: beaufsichtigtes Training, halb beaufsichtigtes Training, unbeaufsichtigtes Training, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Feature-Lernen (einschließlich Hauptkomponenten- und Cluster-Analysen), multilineares Subraumlernen, vielfältiges Lernen, Repräsentation-Lernen (einschließlich des Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Nach dem Training der Machine-Learning-Modelle können die Machine-Learning-Modelle von den Fahrzeugen verwendet werden (z. B. über das Netz 790 an die Fahrzeuge übertragen) und/oder die Machine-Learning-Modelle können von den Servern 778 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen kann der Server 778 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netze anwenden, um intelligente Echtzeit-Inferenzen zu ermöglichen. Die Server 778 können Deep-Learning-Supercomputer und/oder dedizierte Kl-Computer mit GPUs 784 umfassen, wie z. B. DGX- und DGX-Stationsmaschinen, die von NVIDIA entwickelt wurden. In einigen Beispielen können die Server 778 jedoch eine Deep-Learning-Infrastruktur enthalten, die nur CPU-betriebene Rechenzentren verwendet.
  • Die Deep-Learning-Infrastruktur der Server 778 kann eine schnelle Echtzeit-Inferenz ermöglichen und diese Funktion nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 700 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen vom Fahrzeug 700 erhalten, wie z. B. eine Abfolge von Bildern und/oder Objekten, die das Fahrzeug 700 in dieser Abfolge von Bildern lokalisiert hat (z. B. durch Computervision und/oder andere Techniken zur Klassifizierung von Machine-Learning-Objekten). Die Deep-Learning-Infrastruktur kann ein eigenes neuronales Netz betreiben, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 700 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die Kl im Fahrzeug 700 defekt ist, kann der Server 778 ein Signal an das Fahrzeug 700 senden, das einen ausfallsicheren Computer des Fahrzeugs 700 anweist, die Kontrolle zu übernehmen, die Passagiere zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Für Inferencing können die Server 778 die GPUs 784 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. NVIDIA TensorRT) enthalten. Die Kombination aus GPU-basierten Servern und der Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, z. B. bei weniger kritischer Performance, können Server mit CPUs, FPGAs und anderen Prozessoren für die Inferenz verwendet werden.
  • BEISPIELHAFTE RECHENEINRICHTUNG
  • 8 ist ein Blockdiagramm einer beispielhaften Recheneinrichtung 800, die zur Verwendung bei der Umsetzung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Recheneinrichtung 800 kann ein Verbindungssystem 802 enthalten, das die folgenden Einrichtungen direkt oder indirekt koppelt: Speicher 804, einen oder mehrere Zentralprozessoren (CPUs) 806, einen oder mehrere Grafikprozessoren (GPUs) 808, eine Kommunikationsschnittstelle 810, Eingangs-/Ausgangs (I/O)-Ports 812, Eingabe-/Ausgabekomponenten 814, ein Stromversorgung 816 und eine oder mehrere Darstellungskomponenten 818 (z. B. Displays) und eine oder mehrere Logikeinheiten 820. Bei mindestens einer Ausführungsform kann (können) die Recheneinrichtung(en) 800 eine oder mehrere virtuelle Maschinen (VMs) umfassen und/oder jede ihrer Komponenten kann virtuelle Komponenten umfassen (z.B. virtuelle Hardwarekomponenten). Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 808 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 806 können eine oder mehrere vCPUs umfassen und/oder eine oder mehrere der Logikeinheiten 820 können eine oder mehrere virtuelle Logikeinheiten umfassen. Die Recheneinrichtung(en) 800 kann (können) diskrete Komponenten (z.B. eine vollständige GPU für die Recheneinrichtung 800), virtuelle Komponenten (z.B. einen Abschnitt einer GPU für die Recheneinrichtung 800) oder eine Kombination davon aufweisen.
  • Obwohl die verschiedenen Blöcke der 8 als über das Verbindungssystem 802 mit Leitungen verbunden angezeigt werden, soll dies nicht als einschränkend gedacht sein und dient nur der Übersichtlichkeit. In einigen Ausführungsformen kann beispielsweise eine Darstellungskomponente 818, wie z. B. ein Anzeigegerät, als I/O-Komponente 814 betrachtet werden (z. B. wenn es sich bei dem Display um einen Touchscreen handelt). Als weiteres Beispiel können die CPUs 806 und/oder GPUs 808 Speicher enthalten (z. B. kann der Speicher 804 neben dem Speicher der GPUs 808, der CPUs 806 und/oder anderer Komponenten repräsentativ für ein Speichergerät sein). Mit anderen Worten ist die Recheneinrichtung aus 8 lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „Mobilgerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronisches Steuergerät (electronic control unit - ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle im Umfang der Recheneinrichtung aus 8 gesehen werden.
  • Das Verbindungssystem 802 kann einen oder mehrere Verbindungen oder Busse darstellen, z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 802 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCle-Bus (Peripheral Component Interconnect Express) und/oder einen anderen Bus- oder Verbindungstyp. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als Beispiel kann die CPU 806 direkt an den Speicher 804 angeschlossen werden. Außerdem kann die CPU 806 direkt an die GPU 808 angeschlossen werden. Bei direkter oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann das Verbindungssystem 802 eine PCIe-Verbindung zur Durchführung der Verbindung enthalten. In diesen Beispielen muss kein PCI-Bus in die Recheneinrichtung 800 aufgenommen werden.
  • Der Speicher 804 kann über eine Vielzahl von computer-lesbaren Medien verfügen. Die computer-lesbaren Medien können alle verfügbaren Medien sein, auf die die Recheneinrichtung 800 zugreifen kann. Die computer-lesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie wechselbare und nicht wechselbare Medien enthalten. Als Beispiel und nicht als Einschränkung können die computer-lesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
  • Das Computerspeichermedium kann sowohl flüchtige als auch nichtflüchtige Medien und/oder wechselbare und nicht wechselbare Medien enthalten, die in jedem Verfahren oder Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder andere Datentypen implementiert sind. Im Speicher 804 können beispielsweise computer-lesbare Anweisungen gespeichert werden (z. B., die ein oder mehrere Programme und/oder Programmelemente darstellen, z. B. ein Betriebssystem. Zu den Speichermedien für Computer gehören unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Datenträger, Magnetkassetten, Magnetband, Magnetplattenspeicher oder andere magnetische Speichergeräte, oder jedes andere Medium, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das die Recheneinrichtung 800 zugreifen kann. Wie hier verwendet, umfassen die Speichermedien für Computer nicht per se Signale.
  • Die Speichermedien des Computers können computer-lesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal enthalten, wie z. B. eine Trägerwelle oder einen anderen Transportmechanismus, und umfassen alle Informationsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, das eine oder mehrere seiner Eigenschaften so eingestellt oder geändert hat, dass Informationen im Signal kodiert werden. Als Beispiel und nicht als Einschränkung können die Speichermedien des Computers drahtgebundene Medien wie ein kabelgebundenes Netz oder eine direkte kabelgebundene Verbindung sowie drahtlose Medien wie akustische, HF-, Infrarot- und andere drahtlose Medien umfassen. Kombinationen der oben genannten Punkte sollten ebenfalls in den Umfang von computerlesbaren Medien aufgenommen werden.
  • Die CPUs 806 können so konfiguriert werden, dass sie mindestens einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechners 800 ausführen, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse auszuführen. Die CPUs 806 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPUs 806 können jede Art von Prozessor enthalten und je nach Art der implementierten Recheneinrichtung 800 verschiedene Typen von Prozessoren enthalten (z. B. Prozessoren mit weniger Kernen für Mobilgeräte und Prozessoren mit mehr Kernen für Server). Je nach Recheneinrichtung 800 kann es sich beispielsweise um einen Advanced RISC Machine (ARM)-Prozessor mit reduziertem Instruction Set Computing (RISC) oder einen x86-Prozessor mit komplexem Instruction Set Computing (CISC) handeln. Die Recheneinrichtung 800 kann zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie z. B. mathematischen Coprozessoren, eine oder mehrere CPUs 806 enthalten.
  • Die GPUs 808 können darüber hinaus oder alternativ von den CPUs 806 so konfiguriert werden, dass sie mindestens einige computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechners 800 ausführen, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse auszuführen. Eine oder mehrere GPUs 808 können eine integrierte GPU (z. B. mit einer oder mehreren CPUs 806) sein und/oder eine oder mehrere GPUs 808 können eine separate GPU sein. In Ausführungsformen können eine oder mehrere GPUs 808 ein Coprozessor einer oder mehrerer CPUs 806 sein. Die GPUs 808 können von der Recheneinrichtung 800 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder Durchführen allgemeiner Berechnungen verwendet werden. Beispielsweise können die GPUs 808 zum General-Purpose Computing auf GPUs (GPGPU) verwendet werden. Die GPUs 808 können Hunderte oder Tausende von Kernen umfassen, die Hunderte oder Tausende von Software-Threads gleichzeitig verarbeiten können. Die GPUs 808 können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von den CPUs 806, die über eine Host-Schnittstelle empfangen wurde) Pixeldaten für Ausgabebilder generieren. Die GPUs 808 können Grafikspeicher, wie z. B. Displayspeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie GPGPU-Daten, enthalten. Der Displayspeicher kann als Teil des Speichers 804 enthalten sein. Die GPUs 808 können zwei oder mehr GPUs enthalten, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. über NVLINK) oder die GPUs über einen Switch verbinden (z. B. über NVSwitch). Wenn sie zusammen kombiniert werden, kann jede GPU 808 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für unterschiedliche Ausgaben generieren (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 enthalten oder den Speicher mit anderen GPUs teilen.
  • Die Logikeinheiten 820 können darüber hinaus oder alternativ von den CPUs 806 und/oder den GPUs 808 so konfiguriert werden, dass sie mindestens einige computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechners 800 ausführen, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse auszuführen. In Ausführungsformen können die CPUs 806, die GPUs 808 und/oder die Logikeinheiten 820 diskret oder gemeinsam jede beliebige Kombination der Verfahren, Prozesse und/oder Teile davon durchführen. Eine oder mehrere der Logikeinheiten 820 können Teil einer oder mehrerer CPUs 806 und/oder GPUs 808 sein und/oder eine oder mehrere der Logikeinheiten 820 können diskrete Komponenten oder auf andere Weise außerhalb der CPUs 806 und/oder der GPUs 808 sein. In Ausführungsformen können eine oder mehrere Logikeinheiten 820 ein Coprozessor einer oder mehrerer CPUs 806 und/oder einer oder mehrerer GPUs 808 sein.
  • Beispiele für die Logikeinheiten 820 enthalten einen oder mehrere Prozessorkerne und/oder Komponenten davon, wie Datenverarbeitungseinheiten (DPUs), Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprozessoren (Streaming Multiprocessors - SMs), Tree Traversal Units (TTUs), Artificial Intelligence (AIAS), Accelerators (AIAS) Deep Learning Accelerators (DLAs), Arithmetic-Logic Units (ALUs), Application-Specific Integrated Circuits (ASICs), Floating Point Units (FPUs), Eingangs-/Ausgangs (I/O)-Elemente (input/output - I/O), Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder ähnliches.
  • Die Kommunikationsschnittstelle 810 kann einen oder mehrere Empfänger, Sender und/oder Transceiver umfassen, die es der Recheneinrichtung 800 ermöglichen, über ein elektronisches Kommunikationsnetzwerk, einschließlich drahtgebundener und/oder drahtloser Kommunikation, mit anderen Recheneinrichtungen zu kommunizieren. Die Kommunikationsschnittstelle 810 kann Komponenten und Funktionen enthalten, die die Kommunikation über eine Reihe verschiedener Netzwerke ermöglichen, z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), kabelgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Wide-Area-Netzwerke (z. B. LoRaWAN, Sigfox usw.) und/oder das Internet. In einer oder mehreren Ausführungsformen kann (können) die Logikeinheit(en) 820 und/oder die Kommunikationsschnittstelle 810 eine oder mehrere Datenverarbeitungseinheiten (DPUs) aufweisen, um über ein Netz und/oder über das Verbindungssystem 802 empfangene Daten direkt an eine oder mehrere GPU(s) 808 (z. B. an einen Speicher davon) zu übertragen.
  • Die I/O-Ports 812 können ermöglichen, dass die Recheneinrichtung 800 logisch mit anderen Einrichtungen gekoppelt wird, einschließlich der I/O-Komponenten 814, der Darstellungskomponente(n) 818 und/oder anderen Komponenten, von denen einige in die Recheneinrichtung 800 eingebaut (z. B. integriert) sein können. Die I/O-Komponenten 814 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, Gamecontroller, Satellitenschüssel, Scanner, Drucker, drahtloses Gerät, usw. Die I/O-Komponenten 814 können eine natürliche Benutzeroberfläche (natural user interface, NUI) bereitstellen, die Luftgesten, Stimme oder andere physiologische Eingaben verarbeitet, die von einem Benutzer generiert werden. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Tasterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch in der Nähe des Bildschirms, Luftgesten, Kopf- und Augenverfolgung und Touch-Erkennung (wie unten näher beschrieben) implementieren, die mit einem Display der Recheneinrichtung 800 verbunden ist. Die Recheneinrichtung 800 kann Tiefenkameras umfassen, wie stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung. Darüber hinaus kann die Recheneinrichtung 800 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die eine Bewegungserkennung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Recheneinrichtung 800 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
  • Die Stromversorgung 816 kann eine fest verdrahtete Stromversorgung, eine Batterie-Stromversorgung oder eine Kombination davon umfassen. Die Stromversorgung 816 kann die Recheneinrichtung 800 mit Strom versorgen, damit die Komponenten der Recheneinrichtung 800 arbeiten können.
  • Die Darstellungskomponenten 818 können ein Display (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-Up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Darstellungskomponenten umfassen. Die Darstellungskomponenten 818 können Daten von anderen Komponenten (z. B. GPUs 808, CPUs 806, GPUs usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
  • BEISPIELHAFTES RECHENZENTRUM
  • 9 zeigt ein Beispiel für ein Rechenzentrum 900, das in mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Rechenzentrum 900 kann eine Rechenzentrumsinfrastrukturschicht 910, eine Framework-Schicht 920, eine Softwareschicht 930 und/oder eine Anwendungsschicht 940 beinhalten.
  • Wie in 9 gezeigt, kann die Rechenzentrumsinfrastrukturschicht 910 einen Ressourcen-Orchestrator 912, gruppierte Rechenressourcen 914 und Knotenberechnungsressourcen („Knoten-CRs“) 916(1)-916(N) beinhalten, wobei „N“ eine beliebige ganze positive Zahl darstellt. In mindestens einer Ausführungsform können die Knoten-C.R.s 916(1)-916(N) eine beliebige Anzahl von zentralen Verarbeitungseinheiten (CPUs) oder anderen Prozessoren (einschließlich DPUs, Beschleunigern, feldprogrammierbaren Gate-Anordnungen (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Arbeitsspeichervorrichtungen (z. B. dynamischer Festwertspeicher), Datenspeichervorrichtungen (z. B. Solid-State- oder Festplattenlaufwerke), Netz-Eingabe-/Ausgabe(NW-E/A)-Vorrichtungen, Netz-Switches, virtuellen Maschinen (VMs), Leistungsmodulen und Kühlmodulen usw. beinhalten, sind aber nicht darauf beschränkt. In einigen Ausführungsformen kann einer oder können mehrere Knoten-C.R.s unter den Knoten-C.R.s 916(1)-916(N) einem Server entsprechen, der eine oder mehrere der vorstehend erwähnten Rechenressourcen aufweist. Darüber hinaus können die Knoten C.R.s 916(1)-961(N) in einigen Ausführungsformen eine oder mehrere virtuelle Komponenten beinhalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 916(1)-916(N) können einer virtuellen Maschine (VM) entsprechen.
  • In mindestens einer Ausführungsform können die gruppierten Rechenressourcen 914 getrennte Gruppierungen von Knoten-CR 916 beinhalten, die in einem oder mehreren Gestellen (nicht gezeigt) untergebracht sind, oder in vielen Gestellen, die in Rechenzentren an verschiedenen geografischen Standorten (ebenfalls nicht gezeigt) untergebracht sind. Getrennte Gruppierungen von Knoten-CR 916 innerhalb der gruppierten Rechenressourcen 914 können gruppierte Rechen-, Netzwerk-, Arbeitsspeicher- oder Datenspeicherressourcen beinhalten, die konfiguriert oder zugewiesen sein können, um eine oder mehrere Rechenlasten zu unterstützen. In mindestens einer Ausführungsform können mehrere Knoten-CR 916, die CPUs, GPUs, DPUs und/oder Prozessoren beinhalten, in einem oder mehreren Gestellen gruppiert sein, um Rechenressourcen bereitzustellen, um eine oder mehrere Rechenlasten zu unterstützen. Das eine oder mehreren Gestelle können auch eine beliebige Anzahl von Leistungsmodulen, Kühlmodulen und Netz-Switches in beliebiger Kombination beinhalten.
  • Der Ressourcen-Orchestrator 912 kann einen oder mehrere Knoten-CR 916(1)-916(N) und/oder gruppierte Rechenressourcen 914 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 912 eine Verwaltungseinheit für Software-Design-Infrastruktur (SDI) für das Rechenzentrum 900 beinhalten. Der Ressourcen-Orchestrator 912 kann Hardware, Software oder eine Kombination davon aufweisen.
  • In mindestens einer Ausführungsform, wie in 9 gezeigt, kann die Framework-Schicht 920 einen Aufgabenplaner 932, einen Konfigurationsverwalter 934, einen Ressourcenverwalter 936 und ein verteiltes Dateisystem 938 beinhalten. Die Framework-Schicht 920 kann ein Framework zur Unterstützung von Software 932 der Software-Schicht 930 und/oder einer oder mehrerer Anwendung(en) 942 der Anwendungsschicht 940 beinhalten. Die Software 932 bzw. die Anwendung(en) 942 können webbasierte Dienst-Software oder - Anwendungen beinhalten, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Die Framework-Schicht 920 kann eine Art freies und quelloffenes Software-Webanwendungs-Framework wie Apache SparkTM (im nachfolgend „Spark“) sein, der ein verteiltes Dateisystem 938 für die Verarbeitung großer Datenmengen (z. B. Big Data) verwenden kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Aufgabenplaner 932 einen Spark-Treiber beinhalten, um die Planung von Arbeitslasten zu erleichtern, die durch verschiedene Schichten des Rechenzentrums 900 unterstützt werden. Der Konfigurationsverwalter 934 kann in der Lage sein, unterschiedliche Schichten zu konfigurieren, z. B. die Software-Schicht 930 und die Framework-Schicht 920, einschließlich Spark und des verteilten Dateisystems 938 zur Unterstützung der Verarbeitung großer Datenmengen. Der Ressourcenverwalter 936 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 938 und des Aufgabenplaners 932 zugeordnet oder zugewiesen sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen die gruppierte Rechenressource 914 auf der Rechenzentrumsinfrastrukturschicht 910 beinhalten. Der Ressourcenverwalter 936 und der Ressourcen-Orchestrator 912 können sich aufeinander abstimmen, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.
  • In mindestens einer Ausführungsform kann die in der Softwareschicht 930 beinhaltete Software 932 Software beinhalten, die von mindestens Teilen der Knoten-CR 916(1)-916(N), den gruppierten Rechenressourcen 914 und/oder dem verteilten Dateisystem 938 der Framework-Schicht 920 verwendet werden. Eine oder mehrere Arten von Software können Internet-Webseiten-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Streaming-Videoinhalt-Software beinhalten, ohne darauf beschränkt zu sein.
  • In mindestens einer Ausführungsform kann/können die Anwendung(en) 942, die in der Anwendungsschicht 940 beinhaltet ist (sind), eine oder mehrere Arten von Anwendungen beinhalten, die von mindestens Teilen der Knoten-CR 916(1)-916(N), den gruppierten Rechenressourcen 914 und/oder dem verteilten Dateisystem 938 der Framework-Schicht 920 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl einer Genomikanwendung, einer kognitiven Rechenanwendung und einer maschinellen Lernanwendung, einschließlich Trainings- oder Ableitungssoftware, Framework-Software des maschinellen Lernens (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere maschinelle Lernanwendungen aufweisen, ohne darauf beschränkt zu sein, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden.
  • In mindestens einer Ausführungsform können beliebige von dem Konfigurationsverwalter 934, Ressourcenverwalter 936 und Ressourcen-Orchestrator 912 eine beliebige Anzahl und Art von selbstmodifizierenden Handlungen auf Grundlage einer beliebigen Menge und Art von Daten implementieren, die auf jede technisch machbare Weise erfasst werden. Selbstmodifizierende Handlungen können einen Rechenzentrumsbetreiber des Rechenzentrums 900 dahingehend entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Abschnitte eines Rechenzentrums zu vermeiden.
  • Das Rechenzentrum 900 kann Werkzeuge, Dienste, Software oder andere Ressourcen beinhalten, um ein oder mehrere Modelle des maschinellen Lernens zu trainieren oder Informationen unter Verwendung eines oder mehrerer Modelle des maschinellen Lernens gemäß einer oder mehreren in dieser Schrift beschriebenen Ausführungsformen vorherzusagen oder abzuleiten. Zum Beispiel kann ein (können) Modell(e) für maschinelles Lernen trainiert werden, indem Gewichtungsparameter gemäß einer Architektur eines neuronalen Netzes unter Verwendung von Software und/oder Rechenressourcen berechnet werden, die vorstehend in Bezug auf das Rechenzentrum 900 beschrieben sind. In mindestens einer Ausführungsform können trainierte oder eingesetzte Modelle für maschinelles Lernen, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen unter Verwendung der vorstehend in Bezug auf das Rechenzentrum 900 beschriebenen Ressourcen zu inferenzieren oder vorherzusagen, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere hierin beschriebene Trainingstechniken berechnet werden, sind aber nicht darauf beschränkt.
  • In mindestens einer Ausführungsform kann das Rechenzentrum 900 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenzierung mit den oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, der es dem Benutzer ermöglicht, Informationen zu trainieren oder zu inferieren, wie z.B. Bilderkennung, Spracherkennung oder andere Dienste künstlicher Intelligenz.
  • BEISPIELHAFTE NETZUMGEBUNGEN
  • Netzumgebungen, die für die Verwendung beim Implementieren von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, netzverbundene Speicher (network attached storage - NAS), andere Backend-Vorrichtungen und/oder andere Vorrichtungstypen beinhalten. Die Client-Vorrichtungen, -Server und/oder andere Vorrichtungsarten (z. B. jede Vorrichtung) können auf einer oder mehreren Instanzen der Recheneinrichtung(en) 800 von 8 implementiert werden - z. B. kann jede Vorrichtung ähnliche Komponenten, Merkmale und/oder Funktionen der Recheneinrichtung(en) 800 beinhalten. Wenn Backend-Vorrichtungen (z. B. Server, NAS usw.) implementiert werden, können die Backend-Vorrichtungen auch Teil eines Rechenzentrums 900 sein, dessen Beispiel in 9 hierin näher beschrieben wird.
  • Komponenten einer Netzumgebung können miteinander über ein oder mehrere Netze kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netz kann mehrere Netze oder ein Netz von Netzen beinhalten. Beispielsweise kann das Netz ein oder mehrere Weitverkehrsnetze (WAN), ein oder mehrere lokale Netze (LANs), ein oder mehrere öffentliche Netze wie das Internet und/oder ein öffentliches Telefonvermittlungsnetz (publich switched telephone network - PSTN) und/oder ein oder mehrere private Netze beinhalten. Wenn das Netz ein drahtloses Telekommunikationsnetz beinhaltet, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bereitstellen.
  • Kompatible Netzumgebungen können eine oder mehrere Peer-to-Peer-Netzumgebungen beinhalten - in diesem Fall kann ein Server nicht in einer Netzumgebung beinhaltet sein - und eine oder mehrere Client-Server-Netzumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzumgebung beinhaltet sein. In Peer-to-Peer-Netzumgebungen kann die hierin in Bezug auf einen oder mehrere Server beschriebene Funktionalität auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert sein.
  • In mindestens einer Ausführungsform kann eine Netzumgebung eine oder mehrere Cloud-basierte Netzumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. beinhalten. Eine Cloud-basierte Netzumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem beinhalten, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzserver und/oder Edge-Server beinhalten können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht beinhalten. Die Software oder Anwendung(en) können jeweils Web-basierte Dienstsoftware oder Anwendungen beinhalten. In Ausführungsformen können eine oder mehrere der Client-Vorrichtungen die Web-basierte Dienstsoftware oder Anwendungen verwenden (z. B. durch Zugreifen auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (API)). Bei der Framework-Schicht kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework handeln, das etwa ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. Big Data) verwenden kann, ist aber nicht darauf beschränkt.
  • Eine Cloud-basierte Netzumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination von hierin beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kernservern (z. B. von einem oder mehreren Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Wenn eine Verbindung zu einem Benutzer (z. B. einer Client-Vorrichtung) relativ nahe bei einem oder mehreren Edge-Servern ist, können ein oder mehrere Core-Server dem oder den Edge-Servern mindestens einen Teil der Funktionalität zuweisen. Eine Cloud-basierte Netzumgebung kann privat sein (z. B. auf eine einzelne Organisation beschränkt), kann öffentlich sein (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon sein (z. B. eine Hybrid-Cloud-Umgebung).
  • Die Client-Vorrichtung(en) kann (können) mindestens eine der Komponenten, Merkmale und Funktionalität der hierin in Bezug auf 8 beschrieben Recheneinrichtung(en) 800 beinhalten. Als Beispiel und nicht einschränkend kann eine Client-Vorrichtung als Personal Computer (PC), Laptop-Computer, mobile Vorrichtung, Smartphone, Tablet-Computer, Smartwatch, tragbarer Computer, Personal Digital Assistant (PDA), MP3-Player, Virtual-Reality-Headset, System oder Vorrichtung zur globalen Positionsbestimmung (GPS), Videoplayer, Videokamera, Überwachungsvorrichtung oder -system, Fahrzeug, Boot, Flugschiff, virtuelle Maschine, Drohne, Roboter, tragbare Kommunikationsvorrichtung, Vorrichtung in einem Krankenhaus, Spielgerät oder - system, Unterhaltungssystem, Fahrzeugcomputersystem, eingebetteter Systemcontroller, Fernbedienung, Haushaltsgerät, Unterhaltungselektronikgerät, Workstation, Edge-Vorrichtung, eine beliebige Kombination dieser skizzierten Vorrichtungen oder jede andere geeignete Vorrichtung ausgeführt sein.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen wie etwa Programmmodulen, die von einem Computer oder einer anderen Maschine wie etwa einem Personal Data Assistant oder einem anderen Handgerät ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen ausgeführt werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Recheneinrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen ausgeführt werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetz verbunden sind, durchgeführt werden.
  • Wie hierin verwendet, sollte eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente so ausgelegt werden, dass sie nur ein Element oder eine Kombination von Elementen bedeutet. 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 Elemente A, B und C enthalten. Außerdem kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element umfassen B. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B beinhalten.
  • Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise ausgeführt werden könnte, um andere Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzuschließen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe darüber hinaus nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge ist der einzelnen Schritte ist explizit beschrieben.

Claims (20)

  1. Prozessor umfassend: eine oder mehrere Schaltungen, um: unter Verwendung eines Modells für maschinelles Lernen und basierend zumindest teilweise auf Sensordaten, die unter Verwendung eines oder mehrerer Sensoren einer Ego-Maschine erzeugt wurden, Daten zu berechnen, die eine Sichtweite anzeigen, die den Sensordaten entspricht; eine Verwendbarkeit der Sensordaten für eine oder mehrere Operationen der Ego-Maschine zumindest teilweise auf der Grundlage der Sichtweite zu bestimmen; und mindestens eine Operation der einen oder mehreren Operationen mindestens teilweise auf der Grundlage der Verwendbarkeit der Sensordaten auszuführen.
  2. Prozessor nach Anspruch 1, ferner umfassend ein Bestimmen, mindestens eine autonome oder halbautonome Operation der einen oder mehreren Operationen zumindest teilweise auf der Grundlage der Verwendbarkeit der Sensordaten nicht auszuführen.
  3. Prozessor nach Anspruch 1 oder 2, wobei die Berechnung der Daten eine Regression auf einen Wert der Sichtweite umfasst.
  4. Prozessor nach Anspruch 3, ferner umfassend: Bestimmen, zumindest teilweise basierend auf dem Wert der Sichtweite, eines Sichtweitenbereichs aus mehreren Sichtweitenbereichen, der den Sensordaten entspricht, wobei der Sichtweitenbereich die Verwendbarkeit der Sensordaten für die eine oder mehrere Operationen der Ego-Maschine anzeigt.
  5. Prozessor nach einem der vorhergehenden Ansprüche, wobei die Daten einen Sichtweitenbereich aus mehreren Sichtweitenbereichen anzeigen, und wobei ferner der Sichtweitenbereich die Verwendbarkeit der Sensordaten für die eine oder die mehreren Operationen der Ego-Maschine anzeigt.
  6. Prozessor nach einem der vorhergehenden Ansprüche, wobei die eine oder die mehreren Operationen mindestens eine von einer Objektverfolgung, Objekterkennung, Pfadplanung, Hindernisvermeidung oder eine Operation eines erweiterten Fahrerassistenzsystems (ADAS) umfassen.
  7. Prozessor nach einem der vorhergehenden Ansprüche, wobei das Modell für maschinelles Lernen ein Deep Neural Network (DNN) umfasst, wobei das DNN unter Verwendung einer Kombination von Daten der realen Welt, erweiterten Daten der realen Welt und synthetischen Daten trainiert wird.
  8. Prozessor nach einem der vorhergehenden Ansprüche, wobei der Prozessor in mindestens einem der folgenden enthalten ist: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System, das unter Verwendung einer Edge-Vorrichtung implementiert ist; einem System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das zumindest teilweise in einem Rechenzentrum implementiert ist; oder einem System, das zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
  9. System, umfassend: einen oder mehrere Sensoren; und eine oder mehrere Verarbeitungseinheiten, um eine Verwendbarkeit von Instanzen von Sensordaten zu bestimmen, die unter Verwendung des einen oder der mehreren Sensoren erzeugt werden, zumindest teilweise basierend auf zugeordneten Sichtweiten, die unter Verwendung eines Modells für maschinelles Lernen berechnet werden, wobei das Modell für maschinelles Lernen zumindest teilweise trainiert wird durch: Empfangen von Werten, die einem oder mehreren Parametern zum Einstellen einer Sicht entsprechen, die einer Instanz von Trainingssensordaten entspricht; Erzeugen der Instanz von Trainingssensordaten zumindest teilweise auf der Grundlage der Werte; Bestimmen einer Sichtweite, die der Instanz von Trainingssensordaten entspricht, zumindest teilweise auf der Grundlage der Werte; und Trainieren eines Modells für maschinelles Lernen unter Verwendung der Instanz von Trainingssensordaten und der Sichtweite als Ground-Truth-Daten.
  10. System nach Anspruch 9, wobei die Parameter einer Wetterbedingung, einer Beleuchtungsbedingung oder einer Verdeckungsbedingung entsprechen.
  11. System nach Anspruch 9 oder 10, wobei das Bestimmen der Sichtweite ein Verwenden der Werte aufweist, um die Sichtweite zu berechnen.
  12. System nach einem der Ansprüche 9 bis 11, wobei die Werte auf ein trainiertes Modell angewendet werden, das eine Entsprechung zwischen den jeweiligen Werten des einen oder der mehreren Parameter und den Sichtweiten bestimmt.
  13. System nach Anspruch 12, wobei das trainierte Modell unter Verwendung von Anmerkungen oder Bezeichnungen trainiert wird, die Sichtweiten angeben, die Instanzen von Trainingssensordaten entsprechen, die unter Verwendung zugeordneter Werte des einen oder der mehreren Parameter erzeugt wurden.
  14. System nach einem der Ansprüche 9 bis 13, wobei die Instanz von Trainingssensordaten einer Instanz von Sensordaten aus der realen Welt entspricht und das Erzeugen der Instanz von Trainingssensordaten ein Erweitern der Instanz von Sensordaten aus der realen Welt unter Verwendung der dem einen oder den mehreren Parametern entsprechenden Werte umfasst, um die Instanz von Trainingssensordaten zu erzeugen.
  15. System nach einem der Ansprüche 9 bis 14, wobei die Instanz von Trainingssensordaten einer synthetischen Instanz von Sensordaten entspricht, und das Erzeugen der synthetischen Instanz von Sensordaten umfasst: Anwenden der dem einen oder den mehreren Parametern entsprechenden Werte auf eine Simulationsmaschine, um eine Simulation zu erzeugen; und Erfassen der synthetischen Instanz von Sensordaten unter Verwendung eines oder mehrerer virtueller Sensoren innerhalb der Simulation.
  16. System nach einem der Ansprüche 9 bis 15, wobei das Modell für maschinelles Lernen trainiert wird, um Daten zu berechnen, die Sichtweiten anzeigen, und das Training ein Verwenden einer Verlustfunktion umfasst, die eine Überschätzung der Sichtweiten stärker bestraft als eine Unterschätzung der Sichtweiten.
  17. System nach einem der Ansprüche 9 bis 16, wobei das System mindestens eines der folgenden umfasst: ein Steuerungssystem für eine autonome oder teilautonome Maschine; ein Wahrnehmungssystem für eine autonome oder halbautonome Maschine; ein System zum Durchführen von Simulationsoperationen; ein System zum Durchführen von Deep-Learning-Operationen; ein System, das unter Verwendung einer Edge-Vorrichtung implementiert ist; ein System, das unter Verwendung eines Roboters implementiert ist; ein System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; ein System, das zumindest teilweise in einem Rechenzentrum implementiert ist; oder ein System, das zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
  18. Prozessor, umfassend: einen Verarbeitungsschaltkreis, um einen Satz geeigneter Operationen einer Maschine zu bestimmen, der einer Instanz von Sensordaten entspricht, zumindest teilweise basierend auf einer Sichtweite, die der Instanz von Sensordaten zugeordnet ist, wie sie unter Verwendung eines Maschinenlernmodells berechnet wird.
  19. Prozessor nach Anspruch 18, wobei mindestens eine Operation nicht in den Satz geeigneter Operationen aufgenommen wird, zumindest teilweise basierend darauf, dass die Sichtweite unter einem Sichtweitenschwellenwert liegt.
  20. Prozessor nach Anspruch 18 oder 19, wobei der Satz geeigneter Operationen zumindest teilweise auf der Grundlage bestimmt wird, dass die Sichtweite in einen Sichtweitenbereich fällt, der dem Satz geeigneter Operationen entspricht.
DE102022124361.3A 2021-09-29 2022-09-22 Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen Pending DE102022124361A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/449,306 US20230110027A1 (en) 2021-09-29 2021-09-29 Visibility distance estimation using deep learning in autonomous machine applications
US17/449,306 2021-09-29

Publications (1)

Publication Number Publication Date
DE102022124361A1 true DE102022124361A1 (de) 2023-03-30

Family

ID=85477104

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022124361.3A Pending DE102022124361A1 (de) 2021-09-29 2022-09-22 Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen

Country Status (4)

Country Link
US (1) US20230110027A1 (de)
JP (1) JP2023051713A (de)
CN (1) CN115909237A (de)
DE (1) DE102022124361A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117766014A (zh) * 2024-02-21 2024-03-26 北京怀美科技有限公司 辐照检测存储器芯片的测试方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230127418A (ko) * 2022-02-24 2023-09-01 삼성디스플레이 주식회사 타일형 표시 장치
US20230419680A1 (en) * 2022-06-27 2023-12-28 Ford Global Technologies, Llc Automatically generating machine-learning training data
CN117953445B (zh) * 2024-03-26 2024-05-28 南京大学 基于交通监控相机雨天道路能见度测定方法、系统及介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9952058B2 (en) * 2016-08-29 2018-04-24 Denso International America, Inc. Driver visibility detection system and method for detecting driver visibility
US11508049B2 (en) * 2018-09-13 2022-11-22 Nvidia Corporation Deep neural network processing for sensor blindness detection in autonomous machine applications
US11170299B2 (en) * 2018-12-28 2021-11-09 Nvidia Corporation Distance estimation to objects and free-space boundaries in autonomous machine applications

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117766014A (zh) * 2024-02-21 2024-03-26 北京怀美科技有限公司 辐照检测存储器芯片的测试方法
CN117766014B (zh) * 2024-02-21 2024-04-19 北京怀美科技有限公司 辐照检测存储器芯片的测试方法

Also Published As

Publication number Publication date
CN115909237A (zh) 2023-04-04
JP2023051713A (ja) 2023-04-11
US20230110027A1 (en) 2023-04-13

Similar Documents

Publication Publication Date Title
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112020003043T5 (de) Erkennung und klassifizierung von kreuzungsregionen für autonome maschinenanwendungen
DE102021126254A1 (de) Überwachen der Aufmerksamkeit und der kognitiven Belastung der Insassen für autonome und halbautonome Fahranwendungen
DE112020000413T5 (de) Detektion von orientierungspunkten unter verwendung von kurvenanpassung für anwendungen für autonomes fahren
DE112019006484T5 (de) Detektion von abständen zu hindernissen in autonomen maschinenanwendungen
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE102021121558A1 (de) Auf neuronalen netzen basierende bestimmung der blickrichtung unter verwendung räumlicher modelle
DE112020001897T5 (de) Trainieren neuronaler Netze unter Verwendung von Grundwahrheitsdaten, die mit Karteninformationen ergänzt wurden, für autonome Maschinenanwendungen
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE102021117456A1 (de) Systeme und verfahren zur risikobewertung und gerichteten warnung bei fussgängerüberwegen
DE102021126648A1 (de) Imitationstraining mittels synthetischen daten
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE102019113114A1 (de) Verhaltensgesteuerte wegplanung in autonomen maschinenanwendungen
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE112020006181T5 (de) Blickbestimmung mit blendung als eingabe
DE102022124361A1 (de) Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen
DE102020130749A1 (de) System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben
DE102022111322A1 (de) Engine für adaptive maschinelle lernmodelle zur augenverfolgung
DE102023120759A1 (de) Adaptive cruise control using future trajectory prediction for autonomous systems and applications
DE102021105245A1 (de) Verwenden von bildaugmentation mit simulierten objekten zum trainieren von maschinenlernmodellen in autonomen fahranwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed