DE112020002166T5 - Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen - Google Patents

Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen Download PDF

Info

Publication number
DE112020002166T5
DE112020002166T5 DE112020002166.1T DE112020002166T DE112020002166T5 DE 112020002166 T5 DE112020002166 T5 DE 112020002166T5 DE 112020002166 T DE112020002166 T DE 112020002166T DE 112020002166 T5 DE112020002166 T5 DE 112020002166T5
Authority
DE
Germany
Prior art keywords
vehicle
instances
sensor data
state information
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
DE112020002166.1T
Other languages
English (en)
Inventor
Jesse Hong
Urs Muller
Bernhard Firner
Zongyi Yang
Joyjit Daw
David Nister
Roberto Giuseppe Luca Valenti
Rotem Aviv
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 DE112020002166T5 publication Critical patent/DE112020002166T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Purposes 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, or advanced driver assistance systems for ensuring comfort, stability and safety or drive control systems for propelling or retarding the vehicle
    • B60W30/08—Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Purposes 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, or advanced driver assistance systems for ensuring comfort, stability and safety or drive control systems for propelling or retarding the vehicle
    • B60W30/10—Path keeping
    • B60W30/12—Lane keeping
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Purposes 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, or advanced driver assistance systems for ensuring comfort, stability and safety or drive control systems for propelling or retarding the vehicle
    • B60W30/14—Adaptive cruise control
    • B60W30/143—Speed control
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B60W50/045—Monitoring control system parameters
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • B60W60/0011—Planning or execution of driving tasks involving control alternatives for a single driving scenario, e.g. planning several paths to avoid obstacles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G01M17/06—Steering behaviour; Rolling behaviour
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/86—Combinations of radar systems with non-radar systems, e.g. sonar, direction finder
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/88—Radar or analogous systems specially adapted for specific applications
    • G01S13/93—Radar or analogous systems specially adapted for specific applications for anti-collision purposes
    • G01S13/931—Radar or analogous systems specially adapted for specific applications for anti-collision purposes of land vehicles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S7/00—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00
    • G01S7/02—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00 of systems according to group G01S13/00
    • G01S7/41—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00 of systems according to group G01S13/00 using analysis of echo signal for target characterisation; Target signature; Target cross-section
    • G01S7/417—Details of systems according to groups G01S13/00, G01S15/00, G01S17/00 of systems according to group G01S13/00 using analysis of echo signal for target characterisation; Target signature; Target cross-section involving the use of neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/23—Clustering techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G06F30/27—Design optimisation, verification or simulation using machine learning, e.g. artificial intelligence, neural networks, support vector machines [SVM] or training a model
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/77—Processing 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/774—Generating sets of training patterns; Bootstrap methods, e.g. bagging or boosting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0019—Control system elements or transfer functions
    • B60W2050/0028—Mathematical models, e.g. for simulation
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S15/00—Systems using the reflection or reradiation of acoustic waves, e.g. sonar systems
    • G01S15/88—Sonar systems specially adapted for specific applications
    • G01S15/93—Sonar systems specially adapted for specific applications for anti-collision purposes
    • G01S15/931—Sonar systems specially adapted for specific applications for anti-collision purposes of land vehicles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S17/00—Systems using the reflection or reradiation of electromagnetic waves other than radio waves, e.g. lidar systems
    • G01S17/88—Lidar systems specially adapted for specific applications
    • G01S17/89—Lidar systems specially adapted for specific applications for mapping or imaging
    • G01S17/894—3D imaging with simultaneous measurement of time-of-flight at a 2D array of receiver pixels, e.g. time-of-flight cameras or flash lidar
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S17/00—Systems using the reflection or reradiation of electromagnetic waves other than radio waves, e.g. lidar systems
    • G01S17/88—Lidar systems specially adapted for specific applications
    • G01S17/93—Lidar systems specially adapted for specific applications for anti-collision purposes
    • G01S17/931—Lidar systems specially adapted for specific applications for anti-collision purposes of land vehicles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold

Abstract

In verschiedenen Beispielen können Sensordaten, die in der realen Welt aufgezeichnet wurden, genutzt werden, um transformierte Sensordaten zu erzeugen, um eine oder mehrere Funktionen eines Fahrzeugs zu testen - beispielsweise eine Funktion eines AEB-, CMW-, LDW-, ALC- oder ACC-Systems. Die von den Sensoren aufgezeichneten Sensordaten können ergänzt, transformiert oder anderweitig aktualisiert werden, um Sensordaten darzustellen, die den durch ein Simulationstestprofil definierten Zustandsinformationen zum Testen der Fahrzeugfunktion(en) entsprechen. Nach der Erzeugung von Testdaten können diese von einem System des Fahrzeugs verarbeitet werden, um die Wirksamkeit des Systems in Bezug auf eine beliebige Anzahl von Testkriterien zu bestimmen. Folglich kann ein Testsatz, der zusätzliche oder alternative Instanzen von Sensordaten enthält, aus den unter realen Bedingungen aufgezeichneten Sensordaten erzeugt werden, um ein Fahrzeug in einer Vielzahl von Testszenarien zu prüfen - einschließlich solcher, deren Prüfung unter realen Bedingungen gefährlich sein kann.

Description

  • HINTERGRUND DER ERFINDUNG
  • Autonome Fahrsysteme und fortschrittliche Fahrerassistenzsysteme (ADAS; advanced driver assistance systems) können verschiedene Sensoren nutzen, um verschiedene Aufgaben zu erfüllen, wie z.B. Spurhaltung, Spurwechsel, Spurzuweisung, Kamerakalibrierung, Abbiegen, Anhalten, Wegplanung und Lokalisierung. Damit autonome Systeme und ADAS-Systeme unabhängig und effizient arbeiten können, kann beispielsweise ein Verständnis der umgebenden Umgebung des Fahrzeugs in Echtzeit oder nahezu in Echtzeit erzeugt werden. Dieses Verständnis kann Informationen über die Lage von Objekten, Hindernissen, Fahrspuren und/oder Kreuzungen in der Umgebung in Bezug auf verschiedene Abgrenzungen wie beispielsweise Fahrspuren, Straßenbegrenzungen, Kreuzungen und/oder dergleichen beinhalten. Die Informationen über die umgebende Umgebung können von einem Fahrzeug verwendet werden, um Entscheidungen zu treffen, wie z.B. wann und/oder wo zu bremsen ist, wo und wie lange anzuhalten ist, wann und ob die Spur zu wechseln ist soll, wie schnell zu fahren ist usw.
  • Als ein Beispiel können ADAS-Systeme automatische Notbremssysteme (AEB; automatic emergency braking) (und/oder Kollisionsminderungswarnungs (CMW; collision mitigation warning)-Systeme) einsetzen, um ein Fahrzeug bei der sicheren Navigation in einer Umgebung zu unterstützen, indem in verschiedenen Situationen automatisch die Bremsen aktiviert werden - und/oder eine Anzeige bereitgestellt wird, dass die Bremsen aktiviert werden sollten -, um potenzielle Kollisionen zu vermeiden. Beispielsweise kann ein AEB-System - wenn es ausgelöst wird - dazu konfiguriert sein, Aufgaben wie beispielsweise ein Vorladen der Bremsen, ein Verlangsamen und/oder ein Bringen des Fahrzeugs zu einem Halt zu übernehmen. Informationen über Standorte und Eigenschaften von Objekten und/oder Fahrspuren in einer Umgebung eines autonomen oder teilautonomen Fahrzeugs können sich für das AEB-System als wertvoll erweisen, wenn Entscheidungen zur Hindernisvermeidung und/oder zur Steuerung mit Bezug dazu getroffen werden, z.B. wie beispielsweise wo anzuhalten ist, wann zu bremsen ist, wo mit dem Bremsen zu beginnen ist und/oder dergleichen. Aufgrund des sicherheitskritischen Charakters von AEB-Systemen müssen diese Systeme rigoros getestet werden, um sicheren Betrieb im Einsatz zu gewährleisten. Beispielsweise kann eine Prüfung durchgeführt werden, um zu bestimmen, ob das AEB-System die Bremsen zum richtigen Zeitpunkt oder an der richtigen Stelle akkurat auslöst, wenn sich das Fahrzeug mit einer einer Vielzahl von Geschwindigkeiten auf ein Objekt zubewegt. Die Prüfung des AEB-Systems eines Fahrzeugs in einer realen Umgebung kann sich jedoch als gefährlich erweisen, und ein Simulieren einer realen Umgebung für die Prüfung kann zeitaufwändig und teuer sein und dennoch keine genauen und zuverlässigen Ergebnisse liefern.
  • Beispielsweise können einige herkömmliche AEB- und/oder CMW-Systeme unter Verwendung von Wiederholungen von Sensordaten getestet bzw. geprüft werden, die während der Fahrt eines Fahrzeugs auf einer Teststrecke aufgezeichnet wurden. Die Teststrecke kann Ziele wie beispielsweise Luftballons, Schaumstoff und/oder Pappfiguren beinhalten, um Objekte wie beispielsweise Fahrzeuge, Fußgänger, Straßenschilder usw. zu repräsentieren. Sensordaten können aufgezeichnet werden, während das Fahrzeug auf die Ziele zufährt, und diese Sensordaten können verwendet werden, um das AEB-System auf Genauigkeit, Zuverlässigkeit und Sicherheit zu testen. Um jedoch die Funktionsfähigkeit eines AEB-Systems genau und ausreichend zu testen, muss eine große Menge an Sensordaten unter verschiedenen Betriebsbedingungen erfasst werden. Das Sammeln einer solch großen und vielfältigen Menge an Sensordaten mittels Feldversuchen kann extrem zeitaufwändig und teuer sein und spiegelt letztlich möglicherweise nicht genau die Leistungsfähigkeit des AEB-Systems in der realen Welt wider - z.B. weil die Testobjekte anders und von den Sensoren anders registriert werden können als tatsächliche Objekte (z.B. bieten Schaumstoff, Pappe oder Objektausschnitte möglicherweise nicht die gleichen Reflexions- und/oder Erscheinungsmerkmale für Bilddaten, LIDAR-Daten und/oder SONAR-Daten wie ein entsprechendes reales Objekt).
  • In einigen anderen konventionellen AEB- und/oder CMW-Systemen können Tests mit Hilfe von Simulationen durchgeführt werden, die mit vollständig synthetisch erzeugten Sensordaten in einer virtuellen Umgebung erstellt werden. Solche konventionellen Systeme ermöglichen es, eine große Menge an Sensordaten synthetisch zu erzeugen; synthetisch erzeugte Sensordaten sind jedoch naturgemäß nicht so zuverlässig wie Sensordaten, die in realen Umgebungen gesammelt werden. Daher kann es sein, dass die Leistung eines AEB-Systems in der realen Welt nicht genau in den Tests wiedergegeben wird, die mit synthetisch erzeugten Sensordaten durchgeführt werden. Infolgedessen sind diese herkömmlichen Systeme nicht in der Lage, eine genaue Bewertung der Leistung eines AEB- und/oder CMW-Systems zu liefern, und/oder sie können sich auf der Grundlage synthetischer Testdaten als fälschlich zuverlässig erweisen, aber bei Einsatz oder Test in realen Umgebungen ein unsicheres Verhalten zeigen.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Ausführungsformen der Erfindung beziehen sich auf die Simulation realistischer Testdaten aus transformierten Sensordaten der realen Welt für Anwendungen autonomer Maschinen. Es werden Systeme und Verfahren offenbart, die reale Sensordaten, die von Sensoren an einem Fahrzeug erfasst wurden, nutzen, um transformierte oder aktualisierte Testdaten zu erzeugen, die gewünschten Fahrzeugzuständen bzw. Sollfahrzeugzuständen entsprechen, um eine Funktion des Fahrzeugs zu testen - beispielsweise eine Funktion eines automatischen Notbremsungs (AEB)-Systems, eines Kollisionsminderungswarnungs (CMW)-Systems, eines automatischen Spurhaltewarn (ALDW oder LDW; automatic lane departure warning)-Systems, eines automatischen Spurwechsel (ALC; automatic lane change)-Systems und/oder eines adaptiven Geschwindigkeitsregel (ACC; adaptive cruise control)-Systems.
  • Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, können die erfindungsgemäßen Systeme und Verfahren aufgezeichnete Sensordaten von einem Fahrzeug, das in der realen Welt auf reale Objekte operiert, nutzen, um Testdaten zur Verwendung beim Testen verschiedener Funktionen einer autonomen Maschine - wie einem autonomen oder teilautonomen Fahrzeug - zu erzeugen. Beispielsweise können Testdaten erzeugt werden, indem Instanzen von aufgezeichneten Sensordaten, die tatsächlichen Zustandsinformationen entsprechen, die den gewünschten Zustandsinformationen bzw. Sollzustandsinformationen des Fahrzeugs an bestimmten Simulationspunkten sehr ähnlich sind, ergänzt, umgewandelt und/oder aktualisiert werden. Die Simulationspunkte und die entsprechenden Sollzustandsinformationen können mit einem Simulationsprofil verknüpft sein, das auf der Grundlage eines physikalischen Modells des Fahrzeugs, einer gewünschten Anfangsgeschwindigkeit bzw. Sollanfangsgeschwindigkeit zum Testen der Funktion(en) des autonomen Fahrzeugs und/oder anderen Kriterien erstellt oder bestimmt wurde. In einigen Beispielen können die Instanzen der aufgezeichneten Sensordaten, die ausgewählt wurden, um einem Simulationspunkt des Profils zu entsprechen, unter Verwendung einer oder mehrerer Transformationen - z.B. einer Viewport-Transformation - transformiert werden, um die entsprechenden aktualisierten Instanzen zu erzeugen. In Ausführungsformen, z.B. wenn eine Instanz der aufgezeichneten Sensordaten tatsächliche Zustandsinformationen innerhalb eines Schwellenwerts für Ähnlichkeit mit den Sollzustandsinformationen des Simulationspunkts aufweist, kann die aufgezeichnete Instanz ohne Transformation, Erweiterung oder dergleichen verwendet werden. Sobald ein Testdatensatz aus den aufgezeichneten Sensordaten erzeugt wurde, kann der Testdatensatz verwendet werden, um eine oder mehrere Funktionen des Fahrzeugs zu testen, und können die Testergebnisse direkt oder indirekt (z.B. über eine Decodierung) verwendet werden, um die Genauigkeit der Anwendung für autonome Maschinen zu bestimmen.
  • Durch die Umwandlung von Sensordaten aus der realen Welt zur Erzeugung von Testdaten für die Prüfung der Funktionalität eines Fahrzeugs können wertvolle Zeit und Rechenressourcen eingespart werden, die sonst - in herkömmlichen Systemen - für die Erfassung und Verarbeitung zusätzlicher Daten aus der realen Welt verwendet würden. Der Prozess der Umwandlung von Sensordaten aus der realen Welt auf der Grundlage eines Simulationsprofils zur Erzeugung von Testdaten kann vergleichsweise kostengünstiger, weniger rechenintensiv und besser skalierbar sein als herkömmliche Systeme, da das System die Menge der Testdaten erhöhen kann, die genauer und zuverlässiger sind und den Sensordaten aus der realen Welt ähnlicher sind - ohne dass die Verwendung simulierter oder virtueller Daten oder die Aufzeichnung einer großen Menge von Sensordaten in realen, gestaffelten Testsituationen erforderlich ist. Darüber hinaus können die Testdaten erfasst werden, während ein Fahrzeug von einer Stelle in der Nähe eines Objekts rückwärtsfährt, wodurch die Testdaten zur Simulation von Nahbegegnungen mit Objekten verwendet werden können, während die Sicherheit der Datenerfassung maximiert wird (z.B. wenn herkömmliche Systeme auf das Objekt zufahren und versuchen müssten, vor dem Objekt anzuhalten, was gefährlich sein könnte).
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zur Umwandlung von Sensordaten aus der realen Welt auf der Grundlage eines simulierten Profils, um Testdaten für autonome Maschinenanwendungen zu erzeugen, werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungen näher beschrieben, wobei:
    • 1 ein beispielhaftes Datenflussdiagramm ist, das einen beispielhaften Prozess zum Erzeugen von Testdaten zum Testen einer oder mehrerer Funktionen einer autonomen Maschine veranschaulicht, gemäß einigen Ausführungsformen der Erfindung;
    • 2 eine beispielhafte Darstellung der Bestimmung nächstgelegener Instanzen von Sensordaten auf der Grundlage eines Vergleichs von Ist- und Soll-Zustandsinformationen eines Fahrzeugs zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 3A eine beispielhafte Darstellung eines aufgezeichneten Bilds zeigt, das von einem Sensor eines Fahrzeugs erzeugt wurde, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 3B eine beispielhafte Darstellung eines aktualisierten Bilds zeigt, das durch Umwandlung des aufgezeichneten Bilds von 3A erzeugt wurde, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 4-5 Flussdiagramme enthalten, die Beispielprozesse zum Testen von Funktionen eines Fahrzeugs veranschaulichen, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6A eine Darstellung eines Beispiels für ein autonomes Fahrzeug ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6B ein Beispiel für Kameraorte und Sichtfelder für das beispielhafte autonome Fahrzeug von 6A ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6C ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 6A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung;
    • 6D ein Systemdiagramm für eine Kommunikation zwischen einem oder mehreren Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug von 6A ist, in Übereinstimmung mit einigen Ausführungsformen der Erfindung; und
    • 7 ein Blockdiagramm einer beispielhaften Computervorrichtung ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • Es werden Systeme und Verfahren offenbart, die sich auf die Transformation bzw. Umwandlung von Sensordaten aus der realen Welt auf der Grundlage eines simulierten Profils beziehen, um Testdaten für autonome Maschinenanwendungen zu erzeugen. Obwohl die Erfindung in Bezug auf ein beispielhaftes autonomes Fahrzeug 600 (hierin alternativ als „Fahrzeug 600“ oder „Eigen-Fahrzeug 600“ bezeichnet, von dem ein Beispiel in Bezug auf 6A-6D beschrieben ist), ist dies nicht als Beschränkung zu verstehen. Beispielsweise können die hierin beschriebenen Systeme und Verfahren ohne Beschränkung von nicht autonomen Fahrzeugen, halbautonomen Fahrzeugen (z.B. in einem oder mehreren adaptiven Fahrerassistenzsystemen (ADAS)), Robotern, Lagerfahrzeugen, Geländewagen, Luftfahrzeugen, Booten, Shuttles, Rettungseinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Auch wenn hierin in erster Linie die Prüfung von AEB-Systemen beschrieben wird, ist dies nicht als Beschränkung zu verstehen, und können alle Systeme eines Fahrzeugs geprüft werden, wie z.B., ohne darauf beschränkt zu sein, die automatische Notbremsung (AEB), die Kollisionsminderungswarnung (CMW), die adaptive Geschwindigkeitsregelung (ACC), die Überwachung des toten Winkels (BSM; blind spot monitoring), die Querverkehrswarnung (CTW; cross traffic warning), usw. Darüber hinaus soll die Beschreibung der Erfindung in Verbindung mit einem Testen oder Prüfen für Fahrzeuganwendungen nicht beschränkend sein, und können die hierin beschriebenen Systeme und Verfahren in den Bereichen der Augmented Reality, der Virtual Reality, der Robotik, der Sicherheit und Überwachung, der autonomen oder halbautonomen Maschinen und/oder in jedem anderen Technologiebereich eingesetzt werden, in dem die Erzeugung zusätzlicher Sensordaten aus aufgezeichneten Sensordaten für die Prüfung verschiedener Funktionen und/oder Prozesse des jeweiligen Fahrzeugs oder Akteurtyps nützlich sein kann.
  • Die aktuellen Systeme und Verfahren stellen Techniken bereit zur Transformation, Ergänzung oder anderweitigen Aktualisierung aufgezeichneter Sensordaten, um verschiedene Situationen zu simulieren - wie beispielsweise unterschiedliche Fahrzeuggeschwindigkeiten, unterschiedliche Fahrzeugausrichtungen, unterschiedliche Geschwindigkeiten umgebender Akteure usw. Darüber hinaus können, weil die Sensordaten aktualisiert werden können, die ursprünglichen Sensordaten in einer realen Umgebung und/oder auf einer Teststrecke mit realen Objekten erzeugt werden. Beispielsweise kann das Fahrzeug mit einer langsamen und sicheren Geschwindigkeit auf ein reales Objekt zufahren und/oder sich von diesem entfernen, und können die erzeugten Sensordaten ergänzt oder umgewandelt werden, um ein weniger sicheres Fahrszenario zu simulieren - z.B. wenn das Fahrzeug mit hoher Geschwindigkeit auf ein Objekt zufährt. Die Leistungsfähigkeit eines AEB-, CMW-, ACC- und/oder eines anderen mit dem Fahrzeug verbundenen Systems kann dann unter Verwendung der transformierten oder aktualisierten Sensordaten getestet werden.
  • Um die transformierten Sensordaten zu generieren, können während der Datenerfassung erzeugte Sensordaten mit zugehörigen Zustandsinformationen versehen bzw. getaggt werden, wie z.B. mit Standort, Geschwindigkeit und/oder Lage- oder Orientierungsinformationen (hierin zusammenfassend als „Zustandsinformationen“ bezeichnet). Während der Prüfung können Simulationsprofile oder Trajektorien generiert werden, um Bedingungen für die Prüfung eines Systems - oder einer Funktion desselben - eines Fahrzeugs zu bestimmen. Die Simulationsprofile können eine beliebige Anzahl von Punkten enthalten, und jedem Punkt kann eine Sollzustandsinformation zugeordnet sein. In einigen Beispielen kann das Simulationsprofil auf der Grundlage einer gewünschten Geschwindigkeit bzw. Sollgeschwindigkeit und eines gewünschten Abstands bzw. Sollabstands - z.B. der Startgeschwindigkeit des Eigen-Fahrzeugs und des Abstands zu einem vorausfahrenden Objekt oder Fahrzeug - zum Testen eines AEB-Systems des Fahrzeugs erstellt werden. Es kann ein Vergleich zwischen den tatsächlichen Zustandsinformationen für einen bestimmten Punkt und den Zustandsinformationen aus den Sensordaten durchgeführt werden, und es können Instanzen der Sensordaten mit zugehörigen Zustandsinformationen, die den Sollzustandsinformationen am ähnlichsten sind - und die in Ausführungsformen einem früheren Ort im Raum entsprechen - für den Punkt ausgewählt werden. Die jedem Punkt des Simulationsprofils am nächsten liegenden (früheren) Instanzen der aufgezeichneten Sensordaten können dann zur Erzeugung der transformierten Sensordaten verwendet werden, um die Leistungsfähigkeit des AEB-Systems zu testen. In einigen Ausführungsformen kann zur Erzeugung der transformierten Sensordaten aus den aufgezeichneten Sensordaten eine Viewport-Transformation für jedes Pixel auf der Grundlage intrinsischer und/oder extrinsischer Parameter des Sensors, der die Sensordaten erfasst hat, durchgeführt werden. In einigen Ausführungsformen kann zusätzlich oder alternativ zur Aktualisierung der Sensordaten eine Instanz der aufgezeichneten Sensordaten, die mit Zustandsinformationen verknüpft ist, die den Sollzustandsinformationen für einen bestimmten Punkt auf dem Simulationsprofil am ähnlichsten sind, als die Sensordateninstanz für diesen Punkt verwendet werden.
  • Insoweit kann eine Live-Wahrnehmung von Sensordaten, die in einer realen Umgebung aufgezeichnet wurden, genutzt werden, um transformierte Sensordaten für die Prüfung des Fahrzeugs unter verschiedenen Zustandsbedingungen zu erzeugen. Auf diese Weise kann die Menge der Testdaten für die Systeme des Fahrzeugs erhöht werden, während gleichzeitig Testdaten erzeugt werden, die genauer und zuverlässiger sind und näher an den Sensordaten der realen Welt liegen als bei herkömmlichen Ansätzen - bei denen z.B. die Testdaten mit imitierten Objekten oder mit synthetischen Daten aus einer simulierten Testumgebung erzeugt werden. Dadurch werden der Zeitaufwand für die Erzeugung von Testdaten oder die Durchführung von Tests sowie die Kosten für die Erzeugung und die Simulation von virtuellen Testumgebungen und/oder realen Testumgebungen reduziert.
  • SYSTEM ZUR ERZEUGUNG TRANSFORMIERTER TESTDATEN
  • Aufgezeichnete Sensordaten (z.B. Bilddaten, LIDAR-Daten, RADAR-Daten usw.) können mit Hilfe von Sensoren (z.B. Kameras, RADAR-Sensoren, LIDAR-Sensoren usw.), die sich an einem autonomen oder halbautonomen Fahrzeug befinden oder anderweitig daran angeordnet sind, empfangen und/oder erzeugt werden. Die aufgezeichneten Sensordaten können Sensordaten enthalten, die zu verschiedenen Zeitpunkten aufgezeichnet wurden, während sich das Fahrzeug auf ein oder mehrere Objekte zubewegt, sich von ihnen entfernt, neben ihnen her fährt oder sich auf andere Weise in Bezug auf sie bewegt. Andere Sensoren (z.B. GNSS, eine Trägheitsmesseinheit (IMU; inertial measurement unit), Geschwindigkeitssensoren, Lenksensoren usw.) können verwendet werden, um Zustandsinformationen für das Fahrzeug bei jeder der verschiedenen Instanzen der Sensordaten zu empfangen und/oder zu erzeugen. Jede Instanz der Sensordaten kann somit das Sensorfeld des Sensors und die zugehörigen Zustandsinformationen für das Fahrzeug und/oder das/die Objekt(e) repräsentieren. In einigen Beispielen können die Zustandsinformationen tatsächliche Zustandsinformationen des Fahrzeugs sein, wie z.B. Standort, Geschwindigkeit, Beschleunigung, Ausrichtung, Lage bzw. Pose usw.
  • Um das AEB-System zu testen, können verschiedene Testbedingungen verwendet werden, um zu bestimmen, was das AEB-System leistet. Diese verschiedenen Testbedingungen können durch Simulationsprofile oder Trajektorien bzw. Bewegungsbahnen repräsentiert werden, die zum Testen der AEB-Systeme erstellt werden. In einigen Ausführungsformen können die Simulationsprofile eine beliebige Anzahl von Punkten enthalten, und kann jeder Punkt zugehörige (oder Soll-) Zustandsinformationen enthalten. Die Sollzustandsinformationen können eine gewünschte oder erwartete Geschwindigkeit, eine Position, eine Beschleunigung, eine Ausrichtung und/oder Lage bzw. Pose des Fahrzeugs für das jeweilige Testfallszenario beinhalten. In einigen Beispielen kann die Sollzustandsinformation auf der Grundlage einer gewünschten Anfangsgeschwindigkeit des Fahrzeugs und/oder eines gewünschten Abstands zu einem anderen Objekt in der Umgebung bestimmt werden.
  • In einigen Ausführungsformen kann das Simulationsprofil so erstellt werden, dass es einer bestimmten Frequenz des Sensors entspricht, da verschiedene Sensoren unterschiedliche Frequenzen haben können (z.B. kann eine Kamera eine Frequenz von 30 Hz haben, kann ein IMU-Sensor eine Frequenz von 100 bis 200 Hz haben, kann ein RADAR-Sensor eine Frequenz von 15 bis 30 Hz haben, usw.). Folglich kann jeder Punkt entlang des Profils einem bestimmten Sensor zugeordnet werden (z.B. Kamera, dann RADAR, dann IMU, dann IMU, dann IMU, dann Kamera, dann RADAR, dann IMU und so weiter). Wenn also die aufgezeichneten Sensordaten tatsächliche Zustandsinformationen repräsentieren, die von einer beliebigen Anzahl verschiedener Sensortypen mit unterschiedlichen Frequenzen erzeugt wurden, kann das Simulationsprofil einem oder mehreren der Sensoren mit einer gewissen Abtastfrequenz an jedem Punkt entsprechen. Darüber hinaus können in einigen Ausführungsformen die simulierten Profile mit mehr oder weniger Punkten erstellt werden, um die Auswirkungen niedrigerer oder höherer Abtastfrequenzen bestimmter Sensoren zu simulieren und/oder um das Ausfallen von Sensoren zu simulieren (z.B. weniger Punkte über einen Teil des simulierten Profils, um eine Fehlfunktion eines oder mehrerer Sensoren zu simulieren). Insoweit kann das Simulationsprofil einen Ausfall von Sensoren, Rauschen in den Sensordaten, eine zeitliche Abweichung bzw. Jitter bei der Erzeugung der Sensordaten und/oder andere Aspekte erfassen, die eine weitere Diversifizierung der Testszenarien ermöglichen.
  • Sobald das Profil erstellt ist und die Sollzustandsinformationen dem System bekannt sind, kann die Instanz der Sensordaten mit den tatsächlichen Zustandsinformationen, die denen der Sollzustandsinformationen an jedem Punkt am ähnlichsten sind, für die Zuordnung zu dem jeweiligen Punkt ausgewählt werden. Diese Instanz der Sensordaten kann als die am nächsten liegende Instanz der Sensordaten bezeichnet werden und kann - mit oder ohne Aktualisierung - als die Sensordaten für den Punkt verwendet werden. Wenn die Sensordaten zu transformieren oder zu erweitern sind, kann die nächstgelegene Instanz für jeden Punkt transformiert werden, um sie mit den Sollzustandsinformationen auszurichten. In einigen Ausführungsformen kann ein Zoomvorgang verwendet werden, um die nächstgelegene Instanz zu transformieren werden. In anderen Beispielen kann eine Viewport-Transformation auf jedes Pixel der nächstgelegenen Instanz angewendet werden, um die Sensordaten so zu aktualisieren, dass die Sensordaten - nun als transformierte oder aktualisierte Sensordaten bezeichnet - besser mit den Sollzustandsinformationen übereinstimmen. In Ausführungsformen, in denen eine Viewport-Transformation durchgeführt wird, kann eine flache Oberfläche angenommen werden.
  • Auf diese Weise können auf effiziente und genaue Weise automatisch Testdaten erzeugt werden, die realen Daten ähnlicher sind, um die Funktion(en) des Fahrzeugs in einer Vielzahl von Szenarien zu testen. Insoweit kann durch Nutzen und Modifizieren einer begrenzten Menge aufgezeichneter Sensordaten ein größerer Bestand an genauen und zuverlässigen bzw. belastbaren Testdaten erzeugt werden, während gleichzeitig die Kosten und die Zeit für die Erzeugung von Testdaten auf imitierten oder simulierten Objekten und/oder innerhalb virtueller Umgebungen eingespart werden.
  • Mit Bezug auf 1 ist 1 ein beispielhaftes Datenflussdiagramm, das einen beispielhaften Prozess 100 zur Erzeugung von Testdaten zum Testen verschiedener Funktionen einer autonomen Maschine veranschaulicht, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele dargestellt sind und dass die Reihenfolge der Komponenten und/oder Prozesse angepasst werden kann, ohne den Rahmen der Erfindung zu verlassen. Darüber hinaus können zusätzliche oder alternative Komponenten und/oder Prozesse, die von den hierin beschriebenen abweichen, implementiert werden. In einigen Ausführungsformen können die Merkmale, die Funktionalität und/oder die Komponenten, die innerhalb des Prozesses 100 verwendet werden, denen des autonomen Fahrzeugs 600 (6A-6D) und/oder der beispielhaften Computervorrichtung 700 (7) ähnlich sein. Darüber hinaus können in einigen Ausführungsformen zusätzliche und/oder alternative Merkmale, Funktionen und/oder Komponenten, die sich von den hierin beschriebenen unterscheiden, innerhalb des Prozesses 100 verwendet werden, ohne den Rahmen der Erfindung zu verlassen.
  • Der Prozess 100 kann ein Erzeugen und/oder Empfangen von aufgezeichneten Daten 102 von einem oder mehreren Sensoren beinhalten. Die aufgezeichneten Sensordaten 102 können, als ein nicht beschränkendes Beispiel, von einem oder mehreren Sensoren eines Fahrzeugs (z.B. des Fahrzeugs 600 der 6A-6C und hierin beschrieben) empfangen werden. Die aufgezeichneten Sensordaten 102 können von dem Fahrzeug und innerhalb des Prozesses 100 verwendet werden, um Funktionen eines oder mehrerer Systeme des Fahrzeugs zu testen, wobei Testdaten verwendet werden, die durch Umwandlung, Ergänzung oder anderweitige Aktualisierung von realen Sensordaten auf der Grundlage eines Simulationsprofils erzeugt wurden. Beispielsweise können die aufgezeichneten Sensordaten 102, ohne Beschränkung darauf, Sensordaten beinhalten, die zu verschiedenen Zeitpunkten aufgezeichnet wurden, während sich das Fahrzeug auf ein oder mehrere Objekte zu bewegt hat, von ihnen weg bewegt hat, neben ihnen her gefahren ist oder sich in anderer Weise in Bezug dazu bewegt hat. Als ein weiteres Beispiel können die aufgezeichneten Sensordaten 102 virtuelle Sensordaten enthalten, die von einer beliebigen Anzahl von Sensoren eines virtuellen Fahrzeugs oder eines anderen virtuellen Objekts erzeugt wurden. In einem solchen Beispiel können die virtuellen Sensoren einem virtuellen Fahrzeug oder einem anderen virtuellen Objekt in einer simulierten Umgebung entsprechen (z.B. verwendet zum Testen, Trainieren und/oder Validieren der Leistung eines neuronalen Netzwerks), und können die virtuellen Sensordaten Sensordaten repräsentieren, die von den virtuellen Sensoren innerhalb der simulierten oder virtuellen Umgebung erfasst wurden.
  • Die aufgezeichneten Sensordaten 102 können aufgezeichnete Instanz(en) 102A (z.B. aufgezeichnete Instanzen der Sensordaten, wie beispielsweise ein Bild, eine Tiefenkarte, eine Punktwolke usw.) und entsprechende aufgezeichnete Zustandsinformationen 102B enthalten, die von dem einen oder den mehreren Sensoren des in der realen Welt navigierenden Fahrzeugs aufgezeichnet wurden. Die aufgezeichnete(n) Instanz(en) 102A kann/können, ohne Beschränkung darauf, Bilddaten von jedem beliebigen der Sensoren des Fahrzeugs 600 beinhalten, einschließlich, zum Beispiel und unter Bezugnahme auf 6A-6C, Stereokamera(s) 668, Weitwinkelkamera(s) 670 (z.B. Fischaugenkameras), Infrarotkamera(s) 672, Umgebungskamera(s) 674 (z.B. 360-Grad-Kameras) und/oder Langstrecken- und/oder Mittelstreckenkamera(s) 678. In einigen Ausführungsformen können die aufgezeichnete(n) Instanz(en) 102A von anderen Sensortypen erzeugt werden, wie z.B., ohne Beschränkung darauf, RADAR-Sensor(en) 660, Ultraschallsensor(en) 662, LIDAR-Sensor(en) 664, usw.
  • In einigen Ausführungsformen können die aufgezeichnete(n) Instanz(en) 102A Bilddaten, die ein Bild bzw. Bilder repräsentieren, Bilddaten, die ein Video repräsentieren (z.B. Schnappschüsse von Videos), und/oder Sensordaten, die Darstellungen von Sensorfeldern von Sensoren repräsentieren (z.B. Tiefenkarten oder Punktwolken für LIDAR-Sensoren, ein Wertediagramm für Ultraschallsensoren usw.), entsprechen. In Bezug auf die aufgezeichnete(n) Instanz(en) 102A, die Bilddaten entsprechen, kann jede beliebige Art von Bilddatenformat verwendet werden, wie z.B., und ohne Beschränkung darauf, komprimierte Bilder wie in den Formaten Joint Photographic Experts Group (JPEG) oder Luminanz/Chrominanz (YUV), komprimierte Bilder als Frames, die aus einem komprimierten Videoformat wie beispielsweise H.264/Advanced Video Coding (AVC) oder H.265/High Efficiency Video Coding (HEVC) stammen, Rohbilder, die beispielsweise von einem Red Clear Blue (RCCB), Red Clear (RCCC) oder einer anderen Art von Bildsensor stammen, und/oder andere Formate. Darüber hinaus kann in einigen Beispielen die aufgezeichnete(n) Instanz(en) 102A innerhalb des Prozesses 100 ohne jegliche Vorverarbeitung verwendet werden (z.B. in einem rohen oder erfassten Format), während in anderen Beispielen die aufgezeichnete(n) Instanz(en) 102A einer Vorverarbeitung (z.B. Rauschausgleich, Entmosaikisierung, Skalierung, Beschneidung, Vergrößerung, Weißabgleich, Tonkurvenanpassung usw., wie z.B. unter Verwendung eines Sensordaten-Vorprozessors (nicht gezeigt)) unterzogen werden können. Wie hierin verwendet, kann/können sich die aufgezeichnete(n) Instanz(en) 102A auf unverarbeitete Bilddaten, vorverarbeitete Bilddaten oder eine Kombination davon beziehen. Die aufgezeichnete(n) Instanz(en) 102A kann/können Originalbilder (z.B. wie von einem oder mehreren Bildsensoren erfasst), heruntergerechnete bzw. down-gesampelte Bilder, hochgerechnete bzw. up-gesampelte Bilder, beschnittene Bilder oder ROI (Region of Interest)-Bilder, anderweitig vergrößerte Bilder und/oder eine Kombination davon beinhalten.
  • Die aufgezeichnete Zustandsinformationen 102B können, ohne Beschränkung darauf, Zustandsinformationsdaten von jedem der Sensoren des Fahrzeugs 600 beinhalten, einschließlich, zum Beispiel und unter Bezugnahme auf 6A-6C, eines oder mehrerer Lenksensoren 640, eines oder mehrerer Geschwindigkeitssensoren 644, eines Bremssensorsystem 646, eines Drosselklappen-/Beschleunigungssensors 652, eines oder mehrerer GNSS-Sensoren 658, eines oder mehrerer IMU-Sensoren 666 und/oder anderer Sensortypen, die in der Lage sind, Zustandsinformationen des Fahrzeugs zu verschiedenen Zeitpunkten zu erzeugen, zu erhalten und/oder aufzuzeichnen. Beispielsweise können die aufgezeichneten Zustandsinformationen 102B, ohne Beschränkung darauf, Daten enthalten, die für einen Fahrzeugzustand zu Zeitpunkten repräsentativ sind, die dem Erfassen der aufgezeichneten Instanz(en) 102A der aufgezeichneten Sensordaten 102 entsprechen. Insoweit können, während sich das Fahrzeug 600 auf das/die Objekt(e) zubewegt, davon wegbewegt, nebenher fährt oder sich in anderer auf in Bezug auf das/die Objekte Weise bewegt, Zustandsinformationen mit verschiedenen Sensoren aufgezeichnet werden, und können die Zustandsinformationen den entsprechenden aufgezeichneten Instanzen zugeordnet werden (z.B. können die aufgezeichneten Instanzen 102A mit Tags versehen werden - z.B. als Metadaten). In einigen Beispielen können die aufgezeichneten Zustandsinformationen 102B tatsächliche Zustandsinformationen des Fahrzeugs 600 (und/oder anderer erfasster Objekte in der Umgebung) beinhalten, wie z.B. Ort, Geschwindigkeit, Beschleunigung, Lage (z.B. Orientierung) und/oder andere Zustandsinformationen. Auf diese Weise kann jede der aufgezeichneten Instanzen 102A der aufgezeichneten Sensordaten 102 ein sensorisches Feld des Sensors repräsentieren und kann zugehörige aufgezeichnete Zustandsinformationen 102B haben, die innerhalb des Prozesses 100 verwendet werden können, um transformierte oder aktualisierte Instanzen 110 der aufgezeichneten Sensordaten 102 zu erzeugen.
  • Der Prozess 100 kann einen Simulationsprofilgenerator 104 beinhalten, der eine oder mehrere Eingaben empfängt -wie beispielsweise ein Fahrzeugphysikmodell 116, eine Sollgeschwindigkeit 118, einen Abstand zu einem oder mehreren Objekten, eine zu testende Funktion, ein zu prüfendes System und/oder andere Eingaben - und eine oder mehrere Ausgaben erzeugt. Beispielsweise kann der Simulationsprofilgenerator 104 unter Verwendung der einen oder mehreren Eingaben ein Simulationsprofil erzeugen, das Simulationspunkte 104A und dazugehörige Informationen über einen gewünschten Zustand bzw. Sollzustandsinformationen 104B enthält. Die Sollzustandsinformationen 104B an jedem Simulationspunkt 104A können eine oder mehrere gewünschte Geschwindigkeits-, Orts-, Beschleunigungs- (z.B. Winkel-, Skalar- usw.), Orientierungs-, Lage- und/oder andere Zustandsinformationen (z.B. wie unter Verwendung des Fahrzeugphysikmodells 116 bestimmt) des Fahrzeugs 600 für die zugrundeliegende(n) Testbedingung(en) oder das/die Szenarien des Simulationsprofils beinhalten.
  • Das Simulationsprofil kann verwendet werden, um eine Fahrzeugfunktion (oder ein System) 112 in Bezug auf einige im Simulationsprofil simulierte Testbedingungen und in Bezug auf die aufgezeichneten Instanzen 102A und/oder die aktualisierten Instanzen 110 zu testen. Um beispielsweise zu ermitteln, wie die Fahrzeugfunktion 112 performt, können verschiedene Testbedingungen verwendet werden. Ein Simulationsprofil (z.B. eine Trajektorie für das Fahrzeug 600) kann für jede Testbedingung zum Testen der Fahrzeugfunktion (oder des Systems) 112 (z.B. eine Funktion eines AEB-, ACC- oder CMW-Systems) erstellt werden. Der/die Simulationspunkt(e) 104A kann/können, wenn er/sie verbunden ist/sind, eine gewünschte Trajektorie bzw. Solltrajektorie des Fahrzeugs 600 durch eine Umgebung darstellen (z.B. eine Umgebung, die in der/den aufgezeichneten Instanz(en) 102A repräsentiert ist). Die aufgezeichnete(n) Instanz(en) 102A entspricht/entsprechen jedoch möglicherweise nicht direkt der Sollzustandsinformation 104B jedes Simulationspunkts 104A, so dass ein Transformator 108 genutzt werden kann, um (eine) naheliegende(n) Instanz(en) 106 - z.B. (eine) aufgezeichnete(n) Instanz(en) 102A mit zugehörigen aufgezeichneten Zustandsinformationen 102B, die den Sollzustandsinformationen 104B am ähnlichsten sind - in (eine) aktualisierte Instanz(en) 110 zu transformieren oder anderweitig zu aktualisieren, die einem sensorischen Feld (z.B. einem Sichtfeld) des Sensors am ähnlichsten ist, der die nächstgelegene(n) Instanz(en) 106 erfasst hat, in der der Sensor eine Instanz der aufgezeichneten Sensordaten 102 erfasst hat, während ein Zustand des Fahrzeugs 600 den Sollzustandsinformationen 104B entsprach.
  • Wie hierin beschrieben, können in einigen Beispielen die Sollzustandsinformationen 104B und/oder der/die Simulationspunkt(e) 104A auf der Grundlage eines Fahrzeugphysikmodells 116 (z.B. von einem Fahrzeughersteller erhalten), einer Sollgeschwindigkeit 118 des Fahrzeugs 600, einer Entfernung zu einem oder mehreren Objekten in der Umgebung, der Straßenform oder anderen Straßeninformationen (z.B. Oberflächenmaterial oder Reibungskoeffizient, Steigung, Krümmung usw.), Wetterinformationen usw. bestimmt werden. Das Fahrzeugphysikmodell 116 kann Informationen über einen oder mehrere Sensoren des Fahrzeugs enthalten, z.B. Standort, Ausrichtung, Funktion, technische Spezifikationen usw. der Sensoren. Das Fahrzeugphysikmodell 116 kann auch Informationen über eine oder mehrere Fahrzeugfunktionen enthalten, wie z.B. die maximale Beschleunigung oder Verzögerung des Fahrzeugs, die Auslösefunktion des AEB-Systems, die Warnauslöser des CMW-Systems, die Auswirkungen der Umweltbedingungen auf die verschiedenen Funktionen des Fahrzeugs, Reifengrößen, Reifenverschleiß (z.B. Reibungskoeffizienten) usw. In einigen Beispielen kann das Fahrzeugphysikmodell 116 auch Informationen über das Fahrzeug enthalten, wie z.B. die Masse, die Trägheit, die Anzahl der Fahrgäste, das erforderliche Gesamtgewicht usw. Das Fahrzeugphysikmodell 116 kann verwendet werden, um das Simulationsprofil für eine Testbedingung zu erstellen, z.B. um einen Punkt im Simulationsprofil zu bestimmen (z.B. wenn sich das Fahrzeug 600 in einem bestimmten Abstand von einem oder mehreren Objekten befindet), an dem das Fahrzeug das AEB-System auslösen muss, um rechtzeitig zu einem vollständigen Halt zu kommen. Würden in einem solchen Beispiel die aufgezeichneten Instanzen 102A nicht die Sollzustandsinformationen 104B widerspiegeln, wenn das Fahrzeug 600 bestimmen sollte, AEB zu aktivieren, wäre(n) die aufgezeichnete(n) Instanz(en) 102A möglicherweise nicht so nützlich für die Prüfung der Genauigkeit des AEB-Systems. Infolgedessen kann eine aufgezeichnete Instanz bzw. können aufgezeichnete Instanzen 102A - wie die nächstgelegene(n) Instanz(en) 106 - ausgewählt und umgewandelt werden, um die aktualisierte(n) Instanz(en) 110 zu erzeugen, die dem gewünschten räumlichen oder zeitlichen Punkt entspricht bzw. entsprechen, an dem das Fahrzeug 600 das AEB-System aktivieren sollte. Wenn das Fahrzeug 600 bei der Durchführung des Tests AEB nicht zum richtigen Zeitpunkt aktiviert, kann ein Problem diagnostiziert und behoben werden. Der/die Simulationspunkt(e) 104A und die entsprechenden Sollzustandsinformationen 104B können aus dem Fahrzeugphysikmodell 116 abgeleitet werden.
  • In anderen Beispielen kann die Sollgeschwindigkeit 118 verwendet werden, um das Simulationsprofil für eine Testbedingung zu erstellen. Die Sollgeschwindigkeit 118 kann eine Sollanfangsgeschwindigkeit des Fahrzeugs sein und kann zur Bestimmung der Simulationspunkte 104A verwendet werden, an denen Simulationsinstanzen oder -daten benötigt werden, um die Fahrzeugfunktion 112 zu testen. Die Simulationspunkte 104A können simulierte Fahrzeugpositionen sein, für welche (eine) aktualisierte Instanz(en) 110 zum Testen zu erzeugen sind. Die Sollanfangsgeschwindigkeit des Fahrzeugs kann verwendet werden, um die Sollzustandsinformationen 104B (z.B. gewünschte Position, Orientierung, Geschwindigkeit, Beschleunigung) des Fahrzeugs an jedem Punkt des/der Simulationspunkt(s) 104A zu bestimmen, die die Trajektorie des Fahrzeugs für die Testbedingung (z.B. die gewünschte Anfangsgeschwindigkeit des Fahrzeugs) definieren.
  • Das Simulationsprofil - z.B. die ihm entsprechenden Sollzustandsinformationen 104B - kann genutzt werden, um die aufgezeichneten Instanzen 102A zu bestimmen, die für die Transformation für jeden der Simulationspunkte 104A auszuwählen sind. In einigen Beispielen kann/können die nächstgelegene(n) Instanz(en) 106 auf der Grundlage eines Vergleichs zwischen den aufgezeichneten Zustandsinformationen 102B und den Sollzustandsinformationen 104B bestimmt werden. Die nächstgelegene(n) Instanz(en) 106 kann/können die aufgezeichnete(n) Instanz(en) 102A darstellen, die die geringste Abweichung von den Sollzustandsinformationen 104B aufweist (aufweisen). Diese Berechnung kann eine Berechnung von Unterschieden zwischen verschiedenen Zustandskriterien beinhalten - z.B. ein Unterschied in den Geschwindigkeiten, ein Unterschied in den Orientierungen oder Lagen, ein Unterschied in der Position, ein Unterschied in der Beschleunigung, usw. - die durch die aufgezeichneten Zustandsinformationen 102B und die Sollzustandsinformationen 104B repräsentiert werden.
  • Beispielsweise kann ein prozentualer Unterschied für jedes Zustandskriterium berechnet werden, und kann der aufgezeichnete Fall 102A mit dem kleinsten kombinierten prozentualen Unterschied als der nächstliegende Fall 106 ausgewählt werden. In einigen Beispielen können die verschiedenen Zustandskriterien gewichtet werden, so dass ein kleinerer Unterschied in der Position wichtiger sein kann als ein Unterschied in der Geschwindigkeit, oder ein kleinerer Unterschied in der Orientierung wichtiger sein kann als ein kleinerer Unterschied in der Position usw. In solchen Beispielen können die Differenzen für verschiedene Zustandskriterien unterschiedlich gewichtet werden, und kann eine berechnete Differenz zwischen den aufgezeichneten Zustandsinformationen 102B und den Sollzustandsinformationen 104B die Gewichtungen berücksichtigen. In einem weiteren Beispiel können die verschiedenen Zustandskriterien, die die größte Transformation der aufgezeichneten Sensordaten 102 erfordern, als wichtiger gewichtet werden als Zustandskriterien, die weniger Transformation erfordern. In einem solchen Beispiel kann es schwieriger sein, die aktualisierte(n) Instanz(en) 110 für Änderungen der Pose zu berechnen als für Änderungen der Geschwindigkeit oder des Standorts, so dass die nächstgelegene(n) Instanz(en) 106 durch stärkere Gewichtung des Unterschieds in der Pose bestimmt werden können. In einigen Beispielen kann die Gewichtung für verschiedene Sensoren, die die aufgezeichneten Sensordaten erzeugt haben, unterschiedlich sein.
  • In einigen Beispielen kann/können die nächstgelegene(n) Instanz(en) 106 einem Ort entsprechen, der vor dem Ort aus den Sollzustandsinformationen 104B liegt, so dass genügend Sensordaten - z.B. Sensordaten, die für einen ausreichenden Teil des sensorischen Felds repräsentativ sind - verfügbar sind, um die Transformation akkurat durchzuführen. In anderen Beispielen kann/können die nächstgelegene(n) Instanz(en) 106 jedoch an Orten vor oder nach den Orten für die Sollzustandsinformationen 104B ausgewählt werden. In jedem Beispiel kann/können die nächstgelegene(n) Instanz(en) 106 auf der Grundlage einiger Kriterien ausgewählt und zur Erzeugung einer oder mehrerer aktualisierter Instanzen 110 verwendet werden, die dem/den Simulationspunkt(en) 104A entsprechend den Sollzustandsinformationen 104B zugeordnet wird/werden. Nach der Bestimmung kann/können die nächstgelegene(n) Instanz(en) 106 dem/den jeweiligen Simulationspunkt(en) 104A zugeordnet werden und kann/können - mit oder ohne Erweiterung, Umwandlung usw. - als Test- oder aktualisierte Instanz der Sensordaten für diesen Simulationspunkt verwendet werden.
  • Als ein Beispiel für die Bestimmung der nächstgelegenen Instanz(en) 106 und unter Bezugnahme auf eine Visualisierung 200 von 2 können aufgezeichnete Sensordaten 210 eine aufgezeichnete Trajektorie oder ein tatsächliches Profil eines Fahrzeugs darstellen, während es sich von einem Ist-Zustand 212A zu einem Ist-Zustand 212D mit dazwischenliegenden Ist-Zuständen 212B-212C bewegt. Sollsensordaten 220 können eine Solltrajektorie oder ein Simulationsprofil des Fahrzeugs repräsentieren, während es sich von einem Sollzustand 220A zu einem Sollzustand 222E mit Sollzwischenzuständen 222B-222D an Simulationspunkten bewegt, die den Sollzuständen 222A-222E entsprechen. Die Informationen über den Ist- und den Soll-Zustand können Fahrzeugpositionen, Ausrichtungen, Geschwindigkeiten, Beschleunigungen, Posen usw. zu jedem aufgezeichneten bzw. gewünschten Zeitpunkt beinhalten. Als ein nicht beschränkendes Beispiel können die aufgezeichneten Sensordaten 210 einem Sensor des Fahrzeugs entsprechen, der Sensordaten mit einer Bildrate des Sensors erfasst, während sich das Fahrzeug mit einer Geschwindigkeit auf ein Objekt zubewegt, die höher ist als eine Sollsimulationsgeschwindigkeit, die den Sollsensordaten 220 entspricht. In solchen Beispielen können die aufgezeichneten Sensordaten 210 weniger aufgezeichnete Instanzen oder Bilder enthalten als die Sollsensordaten, die für die Simulation einer niedrigeren Geschwindigkeit erforderlich sind.
  • Für jeden Sollzustand 222A-222E kann ein nächstgelegenes (ähnlichstes) Beispiel aus den aufgezeichneten Beispielen auf der Grundlage der tatsächlichen Zustände 212A-212D bestimmt oder ausgewählt werden. Beispielsweise kann als nächstgelegene Instanz für den Sollzustand 222A die aufgezeichnete Instanz im Ist-Zustand 212A auf der Grundlage der aufgezeichneten Zustandsinformationen des Ist-Zustands 212A bestimmt werden, die den Sollzustandsinformationen an einem Simulationspunkt, der dem Zustand 222A entspricht, am ähnlichsten ist. Der Ist-Zustand 212A kann dem Soll-Zustand 222A in Bezug auf Abstand, Ausrichtung, Geschwindigkeit und/oder einer Kombination daraus am nächsten liegen - und der Soll-Zustand 222A kann vor dem Ist-Zustand 212A liegen. In ähnlicher Weise können die nächstgelegenen Instanzen für die Sollzustände 222B, 222C, 222D und 222E als tatsächliche Zustände 212A, 212B, 212C bzw. 212C bestimmt werden, basierend auf dem Vergleich der Sollzustandsinformationen für jeden Sollzustand mit den tatsächlichen aufgezeichneten Zustandsinformationen für jeden aufgezeichneten Zustand. In einigen Beispielen können die Sollzustandsinformationen genau den tatsächlichen Zustandsinformationen entsprechen oder innerhalb eines vordefinierten Ähnlichkeitsschwellenwerts liegen, so dass eine Transformation nicht erforderlich ist - z.B. kann die nächstgelegene Instanz als die aktualisierte Instanz verwendet werden, ohne dass sie transformiert, erweitert oder anderweitig aktualisiert wird. Beispielsweise kann eine nächstgelegene Instanz mit dem entsprechenden aufgezeichneten Standort innerhalb einer Schwellenentfernung vom gewünschten Standort als eine aktualisierte Instanz verwendet werden, die auf die Fahrzeugfunktion 112 anzuwenden ist. In einigen Ausführungsformen können eine oder mehrere aufgezeichnete Instanzen nicht als nächstgelegene Instanz für einen gewünschten Punkt verwendet werden, z.B. wenn die aufgezeichneten Instanzen mehr Instanzen enthalten als für das simulierte Profil erforderlich.
  • In anderen Beispielen, obwohl nicht dargestellt, können die aufgezeichneten Sensordaten 210 bei einer langsameren Fahrzeuggeschwindigkeit aufgezeichnet werden, so dass es mehr aufgezeichnete Instanzen oder Bilder gibt, die von den Fahrzeugsensoren aufgezeichnet wurden. Um mehr aufgezeichnete Sensordaten zur Verfügung zu haben, kann das Fahrzeug in einigen Ausführungsformen während der Sensordatenerfassung sehr langsam fahren, um einen robusteren Satz aufgezeichneter Sensordaten zu erhalten, aus denen die nächstgelegenen Instanzen ausgewählt werden können.
  • Wenn (eine) nächstgelegene(n) Instanz(en) 106 ausgewählt oder bestimmt wurde(n), kann der Prozess 100 das Transformieren der nächstgelegenen Instanz(en) 106 unter Verwendung eines Transformators 108 beinhalten, um die aktualisierte(n) Instanz(en) 110 zu erzeugen, die mit den Sollzustandsinformationen 104B an jedem (den) Simulationspunkt(en) 104A besser übereinstimmen. Der Transformator 108 kann so konfiguriert sein, dass er die nächstgelegene Instanz 106 für jeden Simulationspunkt(e) 104A auf der Grundlage einer Differenz zwischen den Sollzustandsinformationen 104B und den aufgezeichneten Zustandsinformationen 102B erweitert oder transformiert - z.B. um Sensordaten (z.B. aktualisierte Instanz(en) 110) zu simulieren, die Sensordaten ähneln, als ob sie vom Sollzustand des Fahrzeugs erfasst worden wären.
  • In einigen Ausführungsformen kann der Transformator 108 eine Transformationsfunktion auf die nächstliegende(n) Instanz(en) 106 anwenden, die auf intrinsischen und/oder extrinsischen Parametern des Sensors basiert, der die nächstliegende(n) Instanz(en) 106 erfasst hat. In nicht beschränkenden Beispielen kann die Transformationsfunktion eine Viewport-Transformation beinhalten, die einige oder alle Pixel der nächstgelegenen Instanz(en) 106 transformieren kann, um die Sollzustandsinformationen 104B genauer wiederzugeben. In solchen Beispielen, z.B. bei Verwendung eines Bildsensors, kann die Annahme einer flachen Oberfläche verwendet werden, um einen Abstand eines Pixels von dem Aufnahmesensor zu schätzen. In anderen Beispielen, z.B. wenn LIDAR-Sensoren, RADAR-Sensoren und/oder andere Sensortypen verwendet werden, braucht die Annahme einer flachen Oberfläche nicht verwendet zu werden.
  • In einigen Ausführungsformen kann der Transformator 108 anstelle der Anwendung einer Transformationsfunktion eine Vergrößerungsoperation (z.B. Vergrößern, Verkleinern) verwenden, um die nächstgelegene(n) Instanz(en) 106, eine Beschneidungsoperation, eine Rotationsoperation und/oder eine andere Operation zu transformieren. Beispielsweise kann der Transformator 108 die nächstgelegene(n) Instanz(en) 106 leicht heranzoomen, um die Vorwärtsbewegung des aufgezeichneten Fahrzeugs zu kompensieren, wenn sich die nächstgelegene(n) Instanz(en) 106 an einer Stelle hinter der gewünschten Stelle befindet. In ähnlicher Weise kann der Transformator 108 die nächstgelegene(n) Instanz(en) 106 leicht herauszoomen, um die Rückwärtsbewegung des aufgezeichneten Fahrzeugs zu kompensieren, wenn sich die nächstgelegene(n) Instanz(en) 106 an einem Ort vor dem gewünschten Ort befindet. In anderen Beispielen kann der Transformator 108 die Wiedergabegeschwindigkeit der aufgezeichneten Sensordaten 102 verlangsamen oder beschleunigen, um die aktualisierte(n) Instanz(en) 110 ohne Transformation, Zoom, Zuschnitt, Drehung oder anderweitig zu bestimmen.
  • Als ein anschauliches Beispiel und in Bezug auf 3A und 3B kann ein aufgezeichnetes Bild 300 unter Verwendung des Transformators 108 transformiert werden, um ein aktualisiertes Bild 320 zu erzeugen. Das aufgezeichnete Bild 300 kann beispielsweise von einem Fahrzeugsensor aufgezeichnet werden, während sich das Fahrzeug 302 auf einen Versorgungsmast 304 und einen Lieferwagen 306 zubewegt (z.B. bei einer Panne auf der Fahrbahn, wodurch ein AEB-System aktiviert werden muss, während sich das Fahrzeug 302 nähert, falls der Fahrer die Bremsen nicht betätigt, oder in einer autonomen Anwendung, in der das System noch nicht mit der Verlangsamung begonnen hat und die Hindernisvermeidungsfunktionalität einsetzt). Der Aufnahmesensor kann eine nach vorne gerichtete Kamera sein, die sich am Fahrzeug 302 befindet. Auf das aufgezeichnete Bild 300 kann eine Viewport-Transformation angewendet werden, indem eine Transformation auf einige oder alle Pixel des aufgezeichneten Bilds300 angewendet wird. Wie zu sehen ist, zeigt das aktualisierte Bild 320, dass das Fahrzeug näher am Lieferwagen 306 und am Versorgungsmast 304 steht als im aufgenommenen Bild 300. Anstelle eines einfachen Zoomvorgangs wurde jedoch eine Ansichtstransformation durchgeführt, so dass sich die Perspektive des Lieferwagens 306 und des Versorgungsmasts 304 geändert hat, um das Wahrnehmungsfeld des Sensors im Sollzustand genauer wiederzugeben. In einigen Fällen kann die Ansichtsfenster- bzw. Viewport-Transformation oder eine andere Transformationsart das Erscheinungsbild von Objekten anpassen, aber da der Großteil der Instanz der Sensordaten das Sensorfeld im Sollzustand genauer wiedergibt, liefert die resultierende aktualisierte Instanz 110 immer noch genauere Testdaten.
  • Erneut auf 1 Bezug nehmend, kann/können die aktualisierte(n) Instanz(en) 110 gemäß dem Simulationsprofil auf die Fahrzeugfunktion 112 angewendet werden, um Testergebnisse 114 zu erzeugen, die die Leistungsfähigkeit der Fahrzeugfunktion 112 für das gewünschte Testszenario angeben. Die Fahrzeugfunktion 112 kann eine beliebige Funktion und/oder ein beliebiges System des zu prüfenden Fahrzeugs beinhalten, wie z.B., aber nicht beschränkt auf, AEB-Systeme, CMW-Systeme, ACC-Systeme und/oder dergleichen. Die aktualisierte(n) Instanz(en) 110 kann/können auf die Fahrzeugfunktion 112 angewendet werden, um zu bestimmen, ob die Fahrzeugfunktion 112 in einer erwarteten, akzeptablen und/oder sicheren Weise funktioniert. In einigen Beispielen können nach dem Testen der Fahrzeugfunktion 112 Testergebnisse 114 erzeugt werden, die die Leistungsfähigkeit der Fahrzeugfunktion (oder des Systems) 112 auf dem Testsatz, der die aktualisierte(n) Instanz(en) 110 beinhaltet, anzeigen. Beispielsweise kann/können das/die Testergebnis(se) 114 für die Fahrzeugfunktion 112, bei der es sich um ein AEB-System handelt, eine Angabe darüber beinhalten, ob das AEB-System korrekt ausgelöst wurde, wann das AEB-System ausgelöst wurde, ob das AEB-System zum richtigen Zeitpunkt und/oder im richtigen Abstand zu einem Objekt (zu Objekten) ausgelöst wurde, wann/wo/ob die Bremsen vorgespannt wurden, wann das Fahrzeug anfing, langsamer zu werden oder anzuhalten, und/oder dergleichen. In einigen Beispielen kann/können das/die Testergebnisse 114 anzeigen, ob die Fahrzeugfunktion 112 korrekt ausgelöst oder aktiviert wurde. In einigen anderen Beispielen kann/können das/die Testergebnis(se) 114 weiter die Auswirkungen der Fahrzeugfunktion 112, die die Navigation des Fahrzeugs steuert, simulieren. In solchen Beispielen kann das Fahrzeugphysikmodell 116 verwendet werden, um das Simulationsprofil für das Prüfszenario zu definieren und das/die Prüfergebnis(se) 114 akkurat zu generieren (z. B. wenn ein physikalisches Modell 116 eine Anhalteleistung des Fahrzeugs angibt, kann diese Information genutzt werden, um zu bestimmen, ob das Fahrzeug ausgehend von dem Punkt, an dem die Fahrzeugfunktion 112 aktiviert wurde, auf der Grundlage der Verarbeitung der aktualisierten Instanz(en) 110 rechtzeitig anhalten würde). Darüber hinaus können auch andere Kriterien verwendet werden, wie z.B. die hierin beschriebenen Kriterien, einschließlich Straßenbedingungen, Fahrzeugbedingungen, Wetter usw.
  • Nunmehr auf 4 und 5 Bezug nehmend, umfasst jeder Block von hierin beschriebenen Verfahren 400 und 500 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in Speicher gespeicherte Anweisungen ausführt. Die Verfahren 400 und 500 können auch als computerverwendbare Anweisungen auf Computerspeichermedien gespeichert sein. Die Verfahren können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt sein, um nur einige zu nennen. Darüber hinaus werden die Verfahren 400 und 500 beispielhaft in Bezug auf den Prozess von 1 und das Fahrzeug 600 beschrieben. Diese Verfahren 400 und 500 können jedoch zusätzlich oder alternativ von einem beliebigen System oder innerhalb eines beliebigen Prozesses oder einer beliebigen Kombination von Systemen und Prozessen, einschließlich, aber nicht beschränkt auf die hierin beschriebenen, ausgeführt werden.
  • 4 ist ein Flussdiagramm, das ein Verfahren 400 zum Testen einer Funktion eines Fahrzeugs zeigt, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das Verfahren 400 beinhaltet in einem Block B402 den Empfang erster Sensordaten, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs repräsentativ sind, und zweiter Sensordaten, die für Zustandsinformationen repräsentativ sind, die dem Fahrzeug bei jeder Instanz der Instanzen des sensorischen Felds entsprechen. Zum Beispiel können aufgezeichnete Instanz(en) 102 A, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs 600 repräsentativ sind, und aufgezeichnete Zustandsinformationen 102B, die für Zustandsinformationen repräsentativ sind, die dem Fahrzeug 600 bei jeder Instanz der aufgezeichneten Instanz(en) 102 A entsprechen, empfangen, abgerufen und/oder erzeugt werden.
  • Das Verfahren 400 beinhaltet in einem Block B404 das Erzeugen eines simulierten Profils zum Testen einer Funktion des Fahrzeugs, wobei das simulierte Profil Sollzustandsinformationen für das Fahrzeug an einer Vielzahl von Punkten entlang des simulierten Profils enthält. Zum Beispiel kann das Simulationsprofil zum Testen der Fahrzeugfunktion 112 des Fahrzeugs 600 erzeugt werden. Das Simulationsprofil kann die Sollzustandsinformationen 104B für das Fahrzeug an den Simulationspunkt(en) 104A entlang des Simulationsprofils enthalten.
  • Das Verfahren 400 beinhaltet in einem Block B406 das Bestimmen einer nächstgelegenen Instanz aus der Vielzahl der Instanzen für einen Punkt aus der Vielzahl der Punkte, zumindest teilweise basierend auf einem Vergleich der Zustandsinformationen und der jeweiligen Sollzustandsinformationen für den Punkt. Zum Beispiel kann/können für jeden Punkt der Simulationspunkte 104A die nächstgelegene(n) Instanz(en) 106 der aufgezeichneten Instanz(en) 102A zumindest teilweise auf der Grundlage eines Vergleichs der aufgezeichneten Zustandsinformationen 102A und der jeweiligen Sollzustandsinformationen 104B für den/die Simulationspunkt(e) 104A bestimmt werden.
  • Das Verfahren 400 beinhaltet in einem Block B408 die Berechnung einer Transformation für die nächstgelegene Instanz, um eine aktualisierte Instanz zu erzeugen, die den jeweiligen Sollzustandsinformationen entspricht. Beispielsweise kann der Transformator 108 eine Transformation für die nächstgelegene(n) Instanz(en) 106 berechnen, um aktualisierte Instanz(en) 110 zu erzeugen, die den jeweiligen Sollzustandsinformationen 104B entsprechen.
  • Das Verfahren 400 beinhaltet in einem Block B410 die Durchführung der Prüfung der Funktion zumindest teilweise auf der Grundlage der aktualisierten Instanz. Beispielsweise kann das Testen der Fahrzeugfunktion 112 zumindest teilweise auf der Grundlage der aktualisierten Instanz(en) 110 ausgeführt werden, um ein oder mehrere Testergebnisse 114 zu erzeugen. Das Testen der Fahrzeugfunktion 112 kann das Laden und/oder Ausführen einer oder aller aktualisierten Instanz(en) 110, Sensordaten, aufgezeichneten Instanz(en) 102A und Zustandsinformationen 102B, Simulationsprofil, Simulationspunkt(e) 104A und Sollzustandsinformationen 104B in ein/einem Simulationssystem zum Ausführen von Tests der Funktion in einer simulierten Umgebung beinhalten.
  • Nunmehr auf 5 Bezug nehmend, ist 5 ein Flussdiagramm, das ein Verfahren 500 zum Testen einer Funktion eines Fahrzeugs in Übereinstimmung mit einigen Ausführungsformen der Erfindung zeigt. Das Verfahren 500 beinhaltet in einem Block B502 den Empfang erster Sensordaten, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs repräsentativ sind, und zweiter Sensordaten, die für Zustandsinformationen repräsentativ sind, die dem Fahrzeug bei jeder Instanz der Instanzen des sensorischen Felds entsprechen. Beispielsweise können die aufgezeichnete(n) Instanz(en) 102A, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs 600 repräsentativ sind, und aufgezeichnete Zustandsinformationen 102B, die für Zustandsinformationen repräsentativ sind, die dem Fahrzeug 600 bei jeder Instanz der aufgezeichneten Instanz(en) 102A entsprechen, empfangen, abgerufen und/oder erzeugt werden.
  • Das Verfahren 500 beinhaltet in einem Block B504 das Erzeugen eines simulierten Profils zum Testen einer Funktion des Fahrzeugs, wobei das simulierte Profil Sollzustandsinformationen für das Fahrzeug an einer Vielzahl von Punkten entlang des simulierten Profils enthält. Zum Beispiel kann das Simulationsprofil zum Testen der Fahrzeugfunktion 112 des Fahrzeugs 600 erzeugt werden. Das Simulationsprofil kann die Sollzustandsinformationen 104B für das Fahrzeug an dem/den Simulationspunkt(en) 104A entlang des Simulationsprofils enthalten.
  • Das Verfahren 500 beinhaltet in einem Block B506 für jeden Punkt der Punkte die Bestimmung einer Instanz aus der Vielzahl der Instanzen, die die jeweiligen Zustandsinformationen aufweisen, die den jeweiligen Sollzustandsinformationen für den Punkt am ähnlichsten sind. Beispielsweise kann/können für jeden Punkt des (der) Simulationspunkte 104A die nächstgelegene(n) Instanz(en) 106 der aufgezeichneten Instanz(en) 102A mit den jeweiligen aufgezeichneten Zustandsinformationen 102B, die den jeweiligen Sollzustandsinformationen 104B für diesen Punkt am ähnlichsten sind, bestimmt werden.
  • Das Verfahren 500 beinhaltet in einem Block B508 das Erzeugen eines Satzes von Instanzen aus der Vielzahl von Instanzen zumindest teilweise auf der Grundlage der Bestimmung. Beispielsweise können ein oder mehrere aktualisierte Instanz(en) 110 - z.B. ohne Transformation oder andere Operationen - aus der/den nächstgelegenen Instanz(en) 106 und/oder der/den von dem Transformator 108 erzeugten Instanz(en) zumindest teilweise auf der Grundlage der nächstgelegenen Instanz(en) 106 ausgewählt werden.
  • Das Verfahren 500 beinhaltet in einem Block B510 die Ausführung des Testens der Funktion zumindest teilweise basierend auf dem Satz von Instanzen. Beispielsweise kann das Testen der Fahrzeugfunktion 112 zumindest teilweise auf der Grundlage der aktualisierten Instanz(en) 110 ausgeführt werden, um ein Testergebnis bzw. Testergebnisse 114 zu erzeugen.
  • BEISPIELHAFTES AUTONOMES FAHRZEUG
  • 6A ist eine Darstellung eines beispielhaften autonomen Fahrzeugs 600, gemäß einigen Ausführungsformen der Erfindung. Das autonome Fahrzeug 600 (hierin alternativ als das „Fahrzeug 600“ bezeichnet) kann, ohne Beschränkung darauf, ein Personenfahrzeug beinhalten, wie z.B. einen Pkw, einen Lkw, einen Bus, ein Notfalleinsatzfahrzeug, ein Pendelfahrzeug bzw. Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z.B., das unbemannt ist und/oder einen oder mehrere Passagiere beherbergt). Autonome Fahrzeuge werden allgemein 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“ (z.B. 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. In einer oder mehreren Ausführungsformen kann das Fahrzeug 600 in der Lage sein, eine Funktionalität gemäß einer oder mehrerer der Stufen 3 bis 5 der Stufen des autonomen Fahrens zu erfüllen. Zum Beispiel kann das Fahrzeug 600 in mindestens einer Ausführungsform in der Lage sein, bedingt automatisiert (Stufe 3), hochautomatisiert (Stufe 4) und/oder voll automatisiert (Stufe 5) zu fahren, je nach der Ausführungsform.
  • Das Fahrzeug 600 kann, ohne darauf beschränkt zu sein, Komponenten wie beispielsweise ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z.B. 2, 4, 6, 8, 18, usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 600 kann ein Antriebssystem 650 umfassen, wie z.B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftwerk, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 650 kann mit einem Antriebsstrang des Fahrzeugs 600 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 600 zu ermöglichen. Das Antriebssystem 650 kann im Ansprechen auf den Empfang von Signalen von der Drosselklappe/dem Gaspedal 652 gesteuert werden.
  • Ein Lenksystem 654, das ein Lenkrad umfassen kann, kann verwendet werden, um das Fahrzeug 600 (z.B. entlang eines gewünschten Weges oder einer Route) zu lenken, wenn das Antriebssystem 650 in Betrieb ist (z.B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 654 kann Signale von einem Lenkaktuator 656 empfangen. Das Lenkrad für volle Automatisierungsfunktionalität (Stufe 5) optional sein.
  • Das Bremssensorsystem 646 kann verwendet werden, um die Fahrzeugbremsen im Ansprechen auf den Empfang von Signalen von den Bremsaktuatoren 648 und/oder Bremssensoren zu betätigen.
  • Eine oder mehrere Steuereinheit(en) 636, die ein oder mehrere System-on-Chips („SoCs“) (6C) und/oder GPUs beinhalten können, können Signale (z.B. repräsentativ für Befehle) für eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 600 bereitstellen. Beispielsweise kann/können die Steuereinheit(en) 636 Signale senden, um die Fahrzeugbremsen über ein oder mehrere Bremsaktuatoren 648 zu betätigen, um das Lenksystem 654 über den (die) Lenkaktuator(en) 656 zu betätigen, um das Antriebssystem 650 über den (die) Drosselklappe/den bzw. die Beschleuniger 652 zu betätigen. Die Steuereinheit(en) 636 kann/können eine oder mehrere eingebaute (z.B. integrierte) Rechenvorrichtungen (z.B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle (z.B. Signale, die Befehle repräsentieren) ausgeben, um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 600 zu unterstützen. Die Steuereinheit(en) 636 kann/können eine erste Steuereinheit 636 für autonome Fahrfunktionen, eine zweite Steuereinheit 636 für funktionale Sicherheitsfunktionen, eine dritte Steuereinheit 636 für Funktionen der künstlichen Intelligenz (z.B. Computer Vision), eine vierte Steuereinheit 636 für Infotainment-Funktionen, eine fünfte Steuereinheit 636 für Redundanz in Notfällen und/oder andere Steuereinheiten beinhalten. In einigen Beispielen kann ein einzelnes Steuergerät 636 zwei oder mehr der oben genannten Funktionen übernehmen, können zwei oder mehr Steuergeräte 636 eine einzige Funktion übernehmen, und/oder eine beliebige Kombination davon.
  • Das/die Steuereinheit(en) 636 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 600 im Ansprechen auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren (z.B. Sensoreingaben) empfangen werden. Die Sensordaten können beispielsweise und ohne Beschränkung darauf von (einem) Sensor(en) eines globalen Navigationssatellitensystems 658 (z.B. Global Positioning System-Sensor(en)), von einem oder mehreren RADAR-Sensor(en) 660, von einem oder mehreren Ultraschallsensor(en) 662, von einem oder mehreren LIDAR-Sensor(en) 664, von einem oder mehreren Trägheitsmesseinheit (IMU)-Sensor(en) 666 (z.B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), von einem oder mehreren Mikrofon(en) 696, von einer oder mehreren Stereokamera(s) 668, von einer oder mehreren Weitwinkelkamera(s) 670 (z.B., Fischaugenkameras), von einer oder mehreren Infrarotkamera(s) 672, von einer oder mehreren Umgebungskamera(s) 674 (z.B. 360-Grad-Kameras), von einer oder mehreren Fern- und/oder Mittelstreckenkamera(s) 698, von einem oder mehreren Geschwindigkeitssensor(en) 644 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 600), von einem oder mehreren Vibrationssensor(en) 642, von einem oder mehreren Lenksensor(en) 640, von einem oder mehreren Bremssensor(en) (z.B. als Teil des Bremssensorsystems 646) und/oder andere Sensortypen empfangen werden.
  • Ein oder mehrere Steuereinheit(en) 636 können Eingaben (z.B. in Form von Eingabedaten) von einem Kombiinstrument 632 des Fahrzeugs 600 empfangen und Ausgaben (z.B. in Form von Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 634, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 600 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z.B. die HD-Karte 622 von 6C), Standortdaten (z.B. der Standort des Fahrzeugs 600, z.B. auf einer Karte), Richtung, Standort anderer Fahrzeuge (z.B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von der/den Steuereinheit(en) 636 wahrgenommen, usw. enthalten. Beispielsweise kann die HMI-Anzeige 634 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. Spurwechsel jetzt, Ausfahrt 34B in zwei Meilen usw.).
  • Das Fahrzeug 600 beinhaltet ferner eine Netzwerkschnittstelle 624, die eine oder mehrere drahtlose Antenne(n) 626 und/oder Modem(e) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 624 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 626 kann/können auch Kommunikation zwischen Objekten in der Umgebung (z.B. Fahrzeuge, mobile Geräte usw.) ermöglichen, indem lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Weitverkehrsnetze mit geringer Leistung (LPWANs), wie beispielsweise LoRaWAN, Sig-Fox usw., verwendet werden.
  • 6B ist ein Beispiel für Kamerastandorte und Sichtfelder für das beispielhafte autonome Fahrzeug 600 von 6A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Die Kameras und jeweilige Sichtfelder stellen eine beispielhafte Ausführungsform dar und sollen beschränkend sein. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder können sich die Kameras an verschiedenen Stellen des Fahrzeugs 600 befinden.
  • Die Kameratypen für die Kameras können Digitalkameras beinhalten, sind aber nicht auf diese beschränkt, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 600 angepasst sein können. Die Kamera(s) kann/können auf der Sicherheitsstufe B (ASIL; automotive safety integrity level) und/oder einer anderen ASIL betrieben werden. Die Kameratypen können je nach Ausführungsform zu einer beliebigen Bildaufnahmerate, z.B. 60 Bilder pro Sekunde (fps), 620 fps, 240 fps usw., in der Lage sein. 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 (RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau (RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar (RBGC)-Farbfilteranordnung, eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensor(RGGB)-Farbfilteranordnung, eine Monochromsensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können zur Erhöhung der Lichtempfindlichkeit Clear-Pixel-Kameras, 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 Kameras verwendet werden, um fortschrittliche Fahrerassistenzsystem (ADAS)-Funktionen auszuführen (z.B. als Teil eines redundanten oder ausfallsicheren Designs). Beispielsweise kann eine Multifunktions-Monokamera installiert sein, um Funktionen einschließlich Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z.B. alle der Kameras) können gleichzeitig Bilddaten (z.B. Video) aufzeichnen und bereitstellen.
  • Eine oder mehrere der Kameras können in einer Montagebaugruppe montiert sein, z.B. in einer kundenspezifisch gestalteten (3D-gedruckten) Baugruppe, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z.B. Reflexionen vom Armaturenbrett, die sich in den Außenspiegeln der Windschutzscheibe spiegeln) auszuschalten, die die Fähigkeit der Kamera zur Bilddatenerfassung beeinträchtigen können. In Bezug auf Flügelspiegelanordnungen können die Außenspiegel-Baugruppen kundenspezifisch in 3D gedruckt sein, so dass die Kameramontageplatte der Form des Flügelspiegels entspricht. In einigen Beispielen können Kamera(s) in den Flügelspiegel integriert sein. Bei Seitenkameras können die eine oder mehreren Kamera(s) auch in die vier Säulen an jeder Ecke des Fahrzeugs integriert sein.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 600 einschließt (z.B. nach vorne gerichtete Kameras), für eine Umgebungsansicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe von einer oder mehreren Steuereinheiten 636 und/oder einem oder mehreren Steuer-SoCs bei der Bereitstellung von Informationen zu helfen, die für die Erstellung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie beispielsweise LIDAR auszuführen, einschließlich Notbremsung, Fußgängererfassung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich Spurverlassenswarnungen („LDW“, Lane Departure Warnings), autonome Geschwindigkeitsregelung („ACC“, Autonomous Cruise Control) und/oder andere Funktionen wie Verkehrszeichenerfassung.
  • Eine Vielzahl von Kameras kann in einer nach vorne gerichteten Konfiguration verwendet werden, die z.B. eine monokulare Kameraplattform umfasst, die einen CMOS (Complementary Metal Oxide Semiconductor)-Farbbildgeber enthält. Ein anderes Beispiel kann eine Weitwinkelkamera 670 sein, die verwendet werden kann, um Objekte wahrzunehmen, die von der Peripherie ins Blickfeld kommen (z.B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 6B nur eine Weitwinkelkamera dargestellt ist, kann es in anderen Ausführungsformen eine beliebige Anzahl von Weitwinkelkamera(s) 670 an dem Fahrzeug 600 geben. Darüber hinaus können eine oder mehrere Mittelstrecken- bzw. Weitwinkelkamera(s) 698 (z.B. ein Weitwinkel-Stereokamerapaar) zur tiefenbasierten Objekterfassung verwendet werden, insbesondere für Objekte, für die ein neuronales Netzwerk noch nicht trainiert wurde. Die Mittelstrecken- bzw. Weitbereichskamera(s) 698 können auch zur Objekterfassung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
  • Eine oder mehrere Stereokameras 668 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 668 kann/können eine integrierte Steuereinheit beinhalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann dazu verwendet werden, eine 3D-Karte der Fahrzeugumgebung zu erstellen, die eine Entfernungsschätzung für alle Punkte im Bild beinhaltet. Eine alternative Stereokamera(s) 668 kann einen kompakten Stereobildsensor enthalten, der zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfasst, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt messen und die erzeugten Informationen (z.B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwenden kann. Zusätzlich oder alternativ zu den hierin beschriebenen Stereokameras können auch andere Typen von Stereokameras 668 verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 600 beinhaltet (z.B. Seitenkameras), können für die Umgebungsansicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsgitters sowie zur Erzeugung von Seitenaufprallwarnungen verwendet werden. Beispielsweise können Umgebungskamera(s) 674 (z.B. vier Umgebungskameras 674 wie in 6B dargestellt) an dem Fahrzeug 600 positioniert sein. Die Umgebungskamera(s) 674 kann/können Weitwinkelkamera(s) 670, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder dergleichen beinhalten. Beispielsweise können vier Fischaugenkameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht sein. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskameras 674 (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, das Teile der Umgebung hinter dem Fahrzeug 600 beinhaltet (z.B. Rückfahrkameras), können zur Einparkhilfe, für die Umgebungsansicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Es kann eine Vielzahl von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z.B. Fern- und/oder Mittelstreckenkamera(s) 698, Stereokamera(s) 668, Infrarotkamera(s) 672 usw.), wie hierin beschrieben.
  • 6C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 600 von 6A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele dargestellt sind. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Entitäten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert sein können. Verschiedene hierin beschriebene Funktionen, die von Entitäten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der in Speicher gespeicherte Anweisungen ausführt.
  • Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 600 in 6C sind als über den Bus 602 verbunden dargestellt. Der Bus 602 kann eine Controller Area Network (CAN)-Datenschnittstelle beinhalten (hierin alternativ als „CAN-Bus“ bezeichnet). Ein CAN-Bus kann ein Netzwerk innerhalb des Fahrzeugs 600 sein, das verwendet wird, um bei der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 600, z.B. zur Betätigung von Bremsen, Beschleunigen, Bremsen, Lenken, Betätigung von Scheibenwischern usw. zu helfen. Ein CAN-Bus kann dazu konfiguriert sein, Dutzende oder sogar Hunderte von Knoten aufzuweisen, jeder mit seiner eigenen eindeutige Fassung (z.B. eine CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Motordrehzahl (RPM bzw. 1/min), Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 602 hierin als ein CAN-Bus beschrieben wird, ist dies nicht als Beschränkung zu verstehen. Beispielsweise können zusätzlich oder alternativ zu dem CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Darüber hinaus ist, obwohl eine einzelne Leitung zur Darstellung des Busses 602 verwendet wird, dies nicht als Beschränkung zu verstehen. Beispielsweise kann es eine beliebige Anzahl von Bussen 602 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 beinhalten können. In einigen Beispielen können zwei oder mehr Busse 602 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder können zur Redundanz verwendet werden. Beispielsweise kann ein erster Bus 602 für die Kollisionsvermeidungsfunktionalität verwendet werden, und kann ein zweiter Bus 602 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 602 mit einer beliebigen Komponente des Fahrzeugs 600 kommunizieren, und können zwei oder mehr Busse 602 mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 604, jede Steuereinheit 636 und/oder jeder Computer bzw. Rechner innerhalb des Fahrzeugs Zugriff auf dieselben Eingangsdaten (z.B. Eingaben von Sensoren des Fahrzeugs 600) haben, und kann mit einem gemeinsamen Bus, wie beispielsweise dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 600 kann ein oder mehrere Steuereinheit(en) 636 beinhalten, wie sie hierin in Bezug auf 6A beschrieben sind. Die Steuereinheit(en) 636 kann/können für eine Vielzahl von Funktionen verwendet werden. Die Steuereinheit(en) 636 kann/können mit den verschiedenen anderen Komponenten und Systemen des Fahrzeugs 600 gekoppelt sein und kann/können zur Steuerung des Fahrzeugs 600, zur künstlichen Intelligenz des Fahrzeugs 600, zum Infotainment für das Fahrzeug 600 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 600 kann ein oder mehrere System(e) auf einem Chip (SoC) 604 beinhalten. Der SoC 604 kann eine oder mehrere CPU(s) 606, GPU(s) 608, Prozessor(en) 610, Cache(s) 612, Beschleuniger 614, Datenspeicher 616 und/oder andere nicht dargestellte Komponenten und Merkmale enthalten. Die SoC(s) 604 können zur Steuerung des Fahrzeugs 600 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise kann/können der/die SoC(s) 604 in einem System (z.B. dem System des Fahrzeugs 600) mit einer HD-Karte 622 kombiniert sein, die Kartenauffrischungen und/oder -aktualisierungen über eine Netzwerkschnittstelle 624 von einem oder mehreren Servern (z.B. dem/den Server(n) 678 von 6D) erhalten kann.
  • Die CPU(s) 606 kann/können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 606 kann/können mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsformen kann/können die CPU(s) 606 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration enthalten. In einigen Ausführungsformen kann/können die CPU(s) 606 vier Zweikern- bzw. Dual-Core-Cluster enthalten, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z.B. einen 2 MB L2-Cache). Die CPU(s) 606 (z.B. der CCPLEX) kann/können dazu konfiguriert sein, den gleichzeitigen Betrieb von Clustern zu unterstützen, so dass eine beliebige Kombination von Clustern der CPU(s) 606 zu einem bestimmten Zeitpunkt aktiv sein kann.
  • Die CPU(s) 606 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardwareblöcke können im Leerlauf automatisch getaktet werden, um dynamisch Energie zu sparen; jeder Kerntakt kann taktgesteuert werden, wenn der Kern aufgrund der Ausführung von WFIIWFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kerncluster kann unabhängig stromgesteuert sein, wenn alle Kerne stromgesteuert sind. Die CPU(s) 606 kann/können darüber hinaus einen erweiterten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten spezifiziert sind und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Verarbeitungskerne können vereinfachte Sequenzen für die Eingabe des Energiezustands in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
  • Die GPU(s) 608 kann/können eine integrierte GPU (hierin alternativ als eine „iGPU“ bezeichnet) beinhalten. Die GPU(s) 608 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 608 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 608 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 einen L2-Cache (z.B. einen L2-Cache mit 512 KB Speicherkapazität) gemeinsam nutzen können. In einigen Ausführungsformen kann/können die GPU(s) 608 mindestens acht Streaming-Mikroprozessoren enthalten. Die GPU(S) 608 kann/können Anwendungsprogrammierschnittstelle(n) (API(s)) für Berechnungen verwenden. Darüber hinaus kann/können die GPU(s) 608 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z.B. CUDA von NVIDIA) verwenden.
  • Die GPU(s) 608 kann/können für die beste Leistung in automobilen und eingebetteten Anwendungsfällen energieoptimiert sein. Beispielsweise können die GPU(s) 608 auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Beschränkung zu verstehen, und die GPU(s) 608 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Reihe von gemischtgenauen Rechenkernen integrieren, die in mehrere Blöcke unterteilt sind. Beispielsweise können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt sein, ohne darauf beschränkt zu sein. In einem solchen Beispiel können jedem Verarbeitungsblock 6 FP32-Kerne, 8 FP64-Kerne, 6 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler bzw. -Planer, eine Dispatch- bzw. Versende-Einheit und/oder eine 64-KB-Registerdatei allokiert sein. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfähigkeit beinhalten, um eine feinkörnigere 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 Leistungsfähigkeit zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • Die GPU(s) 608 kann/können einen HBM (High Bandwidth Memory)-Speicher und/oder ein 16 GB HBM2-Speicher-Subsystem enthalten, um in einigen Beispielen eine Spitzen-Speicherbandbreite 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, beispielsweise ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
  • Die GPU(S) 608 kann/können eine Technologie vereinheitlichten Speichers bzw. eine Unified-Memory-Technologie beinhalten, die Zugriffszähler beinhaltet, 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 mehreren Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 608 direkt auf die Seitentabellen der CPU(s) 606 zugreifen kann/können. In solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 608 einen Fehler feststellt, eine Adressübersetzungsanforderung an die CPU(s) 606 übermittelt werden. Als Reaktion darauf kann/können die CPU(s) 606 in ihren Seitentabellen nach der virtuell-physikalischen Zuordnung für die Adresse suchen und die Übersetzung an die GPU(s) 608 zurückübertragen. So kann die Unified-Memory-Technologie einen einzigen, einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 606 als auch der GPU(s) 608 ermöglichen, wodurch die Programmierung der GPU(s) 608 und die Portierung von Anwendungen auf die GPU(s) 608 vereinfacht wird.
  • Darüber hinaus kann/können die GPU(s) 608 einen Zugriffszähler enthalten, der die Häufigkeit des Zugriffs der GPU(s) 608 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
  • Der/die SoC(s) 604 kann/können eine beliebige Anzahl von Cache(s) 612 enthalten, einschließlich der hierin beschriebenen. Der/die Cache(s) 612 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 606 als auch der/den GPU(s) 608 zur Verfügung steht (z.B. der sowohl mit der/den CPU(s) 606 als auch mit der/den GPU(s) 608 verbunden ist). Der/die Cache(s) 612 kann/können einen Write-Back-Cache enthalten, der die Zustände von Zeilen verfolgen kann, z.B. durch Verwendung eines Cache-Kohärenzprotokolls (z.B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr enthalten, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Der/die SoC(s) 604 kann/können eine oder mehrere Arithmetik-Logik-Einheit(en) (ALU(s)) beinhalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 600 - wie z.B. die Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus kann/können der/die SoC(s) 604 eine oder mehrere Gleitkommaeinheit(en) (FPU(s)) - oder andere mathematische Co-Prozessoren oder numerische Co-Prozessortypen - zur Durchführung mathematischer Operationen innerhalb des Systems enthalten. Der/die SoC(s) 104 kann/können beispielsweise eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in eine oder mehrere CPU(s) 606 und/oder GPU(s) 608 integriert sind.
  • Der/die SoC(s) 604 kann/können einen oder mehrere Beschleuniger 614 enthalten (z.B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Der/die SoC(s) 604 kann/können beispielsweise einen Hardware-Beschleunigungscluster beinhalten, 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) 608 und zur Entlastung einiger Aufgaben der GPU(s) 608 verwendet werden (z.B. um mehr Zyklen der GPU(s) 608 für die Durchführung anderer Aufgaben freizugeben). Der/die Beschleuniger 614 kann/können beispielsweise für gezielte Arbeitslasten (z.B. Wahrnehmung, faltende neuronale Netzwerke (CNNs; convolutional neural networks) usw.) verwendet werden, die stabil genug sind, um beschleunigt werden zu können. Der Begriff „CNN“ wie hierin verwendet kann alle Arten von CNNs beinhalten, einschließlich regionenbasierter oder regionaler faltender neuronaler Netzwerke (RCNNs; regional convolutional neural networks) und schneller RCNNs (wie z.B. für die Objekterfassung verwendet).
  • Der/die Beschleuniger 614 (z.B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA; deep learning accelerator) beinhalten. Der/die DLA(s) kann/können eine oder mehrere Tensorverarbeitungseinheiten (TPUs; bzw. tensor processing units) beinhalten, die dazu konfiguriert sein können, zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und Inferenzierung bereitstellen. Die TPUs können Beschleuniger sein, die für die Ausführung von Bildverarbeitungsfunktionen (z.B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Der/die DLA(s) kann/können darüber hinaus für einen bestimmten Satz neuronaler Netzwerktypen und Gleitkommaoperationen sowie für die Inferenzierung optimiert sein. Das Design des/der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Universal-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 sowie Postprozessorfunktionen unterstützt.
  • Der/die DLA(s) kann/können schnell und effizient neuronale Netzwerke, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, einschließlich, zum Beispiel und ohne darauf beschränkt zu sein: ein CNN für die Identifizierung und Erfassung von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erfassung und Identifizierung von Einsatzfahrzeugen und die Erfassung unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserfassung und die Identifizierung des Fahrzeugbesitzers unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante und/oder sicherheitsbezogene Ereignisse.
  • Die DLA(s) können jede beliebige Funktion der GPU(s) 608 ausführen, und durch die Verwendung eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder die DLA(s) oder die GPU(s) 608 für eine beliebige Funktion einsetzen. Zum Beispiel kann der Entwickler die Verarbeitung von CNNs und Gleitkommaoperationen auf die DLA(s) konzentrieren und andere Funktionen der GPU(s) 608 und/oder anderen Beschleunigern 614 überlassen.
  • Der/die Beschleuniger 614 (z.B. Hardware-Beschleunigungscluster) kann/können einen programmierbaren Bildverarbeitungsbeschleuniger („PVA“, Programmable Vision Accelerator) enthalten, der hierin alternativ als Computer-Vision-Beschleuniger bezeichnet werden kann. Der/die PVA(s) kann/können so ausgelegt und konfiguriert sein, dass er (sie) Computer-Vision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS) 638, autonomes Fahren und/oder Augmented-Reality (AR) und/oder Virtual-Reality (VR) beschleunigt. Der/die PVA(s) kann/können ein Gleichgewicht zwischen Leistung und Flexibilität bereitstellen. Beispielsweise kann jeder/können PVA(s) beispielsweise, und ohne darauf beschränkt zu sein, eine beliebige Anzahl von Computer-Kernen mit reduziertem Befehlssatz (RISC-Kerne, Reduced Instruction Set Computer-Kerne), direkten Speicherzugriff (DMA, Direct Memory Access) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
  • Die RISC-Kerne können mit Bildsensoren (z.B. den Bildsensoren einer der hierin beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher enthalten. Die RISC-Kerne können je nach Ausführungsform eine Reihe 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 Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speicherbausteinen implementiert werden. Die RISC-Kerne können beispielsweise einen Befehls-Cache und/oder ein eng gekoppeltes RAM enthalten.
  • Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 606 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung des PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung 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 Blockstepping, vertikales Blockstepping und/oder Tiefenstepping beinhalten können.
  • Die Vektorprozessoren können programmierbare Prozessoren sein, die dazu konzipiert sein können, die Programmierung von Computer-Vision-Algorithmen effizient und flexibel auszuführen und Signalverarbeitungsfunktionen bereitzustellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen beinhalten. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte beinhalten. Das Vektorverarbeitungs-Subsystem kann als primäre Verarbeitungseinheit des PVA fungieren und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z.B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor enthalten, wie z.B. einen SIMD-Digitalprozessor (Single Instruction, Multiple Data) mit sehr langen Befehlsworten (VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Befehls-Cache enthalten und mit einem dedizierten Speicher verbunden sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität verwenden. In einigen Ausführungsformen kann die Vielzahl der in einer einzigen PVA enthaltenen Vektorprozessoren beispielsweise denselben Computer-Vision-Algorithmus ausführen, jedoch für unterschiedliche Bildbereiche. In anderen Beispielen können die in einem bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Computer-Vision-Algorithmen für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinander folgende Bilder oder Teile eines Bilds ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs. Darüber hinaus kann/können der/die PVA(s) einen zusätzlichen ECC (Error Correcting Code)-Speicher enthalten, um die Sicherheit des Gesamtsystems zu erhöhen.
  • Der/die Beschleuniger 614 (z.B. der Hardware-Beschleunigungscluster) kann ein Computer-Vision-Netzwerk auf dem Chip und SRAM enthalten, um einen SRAM mit hoher Bandbreite und geringer Latenz für den/die Beschleuniger 614 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM enthalten, der beispielsweise und ohne Beschränkung darauf aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine APB (Advanced Peripheral Bus)-Schnittstelle, Konfigurationsschaltungen, eine Steuereinrichtung bzw. einen Controller und einen Multiplexer enthalten. Es kann jeder beliebige Speichertyp 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 ermöglicht. Das Backbone kann ein Computer-Vision-Netzwerk auf dem Chip beinhalten, das den PVA und den DLA mit dem Speicher verbindet (z.B. unter Verwendung des APB).
  • Das Computer-Vision-Netzwerk auf dem Chip kann eine Schnittstelle beinhalten, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl der PVA als auch der DLA bereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie Burst-Kommunikationen für 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 können der/die SoC(s) 604 einen Echtzeit-Raytracing-Hardware-beschleuniger beinhalten, 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 den Vergleich mit LIDAR-Daten zum Zweck der Lokalisierung und/oder für andere Funktionen und/oder für andere Zwecke. In einigen Ausführungsformen können eine oder mehrere Baumtraversierungseinheiten (TTUs; Tree Traversal Units) für die Ausführung einer oder mehrerer Operationen im Zusammenhang mit Raytracing verwendet werden.
  • Der/die Beschleuniger 614 (z.B. der Hardware-Beschleuniger-Cluster) kann/können in vielfältiger Weise für das autonome Fahren eingesetzt werden. Der PVA kann ein programmierbarer Bildverarbeitungsbeschleuniger sein, der für wichtige Verarbeitungsschritte 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 geringem Stromverbrauch und geringer Latenzzeit erfordern. 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. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs daher so konzipiert, dass sie klassische Computer-Vision-Algorithmen ausführen, da sie bei der Objekterfassung effizient sind und mit ganzzahligen mathematischen Verfahren arbeiten.
  • Gemäß einer Ausführungsform der Technologie wird der PVA beispielsweise zur Durchführung von Computer-Stereo-Vision verwendet. In einigen Beispielen kann ein auf semiglobaler Übereinstimmung basierender Algorithmus verwendet werden, obwohl dies nicht beschränkend sein soll. Viele Anwendungen für das autonome Fahren der Stufen 3 bis 5 erfordern eine(n) fliegende(n) Bewegungsabschätzung/Stereoabgleich (z.B. Struktur aus Bewegung, Fußgängererfassung, Fahrspurerfassung usw.). Der PVA kann eine Computer-Stereo-Vision-Funktion auf Eingaben zweier monokularer Kameras durchführen.
  • In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. In Übereinstimmung mit der Verarbeitung von RADAR-Rohdaten (z.B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitetes RADAR zu erhalten. In anderen Beispielen wird der PVA für die Flugzeit-Tiefenverarbeitung verwendet, z.B. durch Verarbeitung von Flugzeit-Rohdaten, um verarbeitete Flugzeitdaten zu erhalten.
  • Der DLA kann für jede Art von Netzwerk verwendet werden, um Kontrolle und Fahrsicherheit zu verbessern, einschließlich eines neuronalen Netzwerks, das für jede Objekterfassung ein Maß für Konfidenz bzw. Vertrauen ausgibt. Ein solcher Vertrauens- bzw. Konfidenzwert kann als eine Wahrscheinlichkeit oder als Bereitstellung eines relativen „Gewichts“ jeder Erfassung im Vergleich zu anderen Erfassungen interpretiert werden. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erfassungen als echte positive Erfassungen und welche als falsch-positive Erfassungen zu betrachten sind. Beispielsweise kann das System einen Schwellenwert für die Konfidenz festlegen und nur die Erfassungen, die diesen Schwellenwert überschreiten, als echte positive Erfassungen betrachten. In einem automatischen Notbremsungs (AEB)-System 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 sichersten Erfassungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Vertrauenswerts einsetzen. Das neuronale Netzwerk kann als seinen Input zumindest eine Teilmenge von Parametern verwenden, wie z.B. die Abmessungen eines Begrenzungsrahmens, die (z.B. von einem anderen Subsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des Trägheitsmesseinheits (IMU)-Sensors 666, die mit der Ausrichtung des Fahrzeugs 600 korreliert, die Entfernung, die von dem neuronalen Netzwerk und/oder anderen Sensoren (z.B. den LIDAR-Sensor(en) 664 oder den RADAR-Sensor(en) 660) erhaltene Schätzung der 3D-Position des Objekts und andere.
  • Der/die SoC(s) 604 kann/können einen oder mehrere Datenspeicher 616 (z.B. einen Speicher) enthalten. Der/die Datenspeicher 616 kann/können ein On-Chip-Speicher des/der SoC(s) 604 sein, der neuronale Netzwerke speichern kann, die auf der GPU und/oder dem DLA auszuführen sind. In einigen Beispielen kann/können der/die Datenspeicher 616 groß genug sein, um mehrere Instanzen neuronaler Netzwerke für Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 612 kann/können L2 oder L3 Cache(s) 612 umfassen. Eine Referenz auf den/die Datenspeicher 616 kann eine Referenz auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 614 zugeordnet ist, wie hierin beschrieben.
  • Der/die SoC(s) 604 kann/können einen oder mehrere Prozessor(en) 610 (z.B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 610 kann/können einen Boot- und Energieverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Subsystem sein kann, um Boot-Energie- und Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energieverwaltungsprozessor kann Teil der Bootsequenz des/der SoC(s) 604 sein und kann Laufzeit-Energieverwaltungsdienste bereitstellen. Der Boot-Energieversorgungs- und -Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen in einen Zustand mit geringem Energieverbrauch, Verwaltung von SoC(s) 604-Temperaturen und Temperatursensoren und/oder Verwaltung der SoC(s) 604-Energieversorgungszustände bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und der/die SoC(s) 604 kann/können die Ringoszillatoren verwenden, um Temperaturen der CPU(s) 606, der GPU(s) 608 und/oder des/der Beschleuniger(s) 614 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energieverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und die SoC(s) 604 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 600 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z.B. das Fahrzeug 600 zu einem sicheren Halt bringen).
  • Der/die Prozessor(en) 610 kann/können ferner einen Satz eingebetteter Prozessoren enthalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der/die Prozessor(en) 610 kann/können außerdem eine „always on“ bzw. ständig eingeschaltete Prozessor-Engine beinhalten, die die notwendigen Hardware-Funktionen zur Unterstützung der Sensorverwaltung mit geringem Stromverbrauch und des Aufwachens von Anwendungsfällen bereitstellt. Die „always on“-Prozessor-Engine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z.B. Zeitgeber und Interrupt-Controller), verschiedene E/A-Controller-Peripheriegeräte und Routing-Logik beinhalten.
  • Der/die Prozessor(en) 610 kann/können außerdem eine Sicherheits-Cluster-Engine enthalten, die ein spezielles Prozessor-Subsystem zur Handhabung des Sicherheitsmanagements für Automobilanwendungen beinhaltet. Die Sicherheits-Cluster-Engine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z.B. Zeitgeber, einen Interrupt-Controller usw.) und/oder Routing-Logik beinhalten. 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 Unterschiede zwischen ihren Operationen zu erfassen.
  • Der/die Prozessor(en) 610 kann/können ferner eine Echtzeit-Kamera-Engine beinhalten, die ein dediziertes Prozessor-Subsystem zur Handhabung eines Echtzeit-Kamera-Managements umfassen kann.
  • Der/die Prozessor(en) 610 kann/können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor enthalten kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
  • Der/die Prozessor(en) 610 kann/können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z.B. auf einem Mikroprozessor implementiert), der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Abspieler- bzw. Player-Fenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitwinkelkamera(s) 670, an der/den Surround-Kamera(s) 674 und/oder an den Sensoren der Überwachungskamera in der Kabine vornehmen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erfasst und entsprechend reagiert. Ein System in der Kabine kann Lippenlesen durchführen, um einen Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, den Zielort des Fahrzeugs zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, 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 beinhalten. Wenn beispielsweise Bewegungen in einem Video auftreten, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Frames geliefert werden. Wenn ein Bild oder ein Teil eines Bilds keine Bewegung beinhaltet, kann die von dem Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um Rauschen in dem aktuellen Bild zu reduzieren.
  • Der Videobildkompositor bzw. Videobildzusammensetzer kann auch dazu konfiguriert sein, eine Stereorektifizierung bzw. Stereoentzerrung auf zugeführten Stereolinsen-Frames durchzuführen. Der Videobildkompositor kann ferner für die Komposition der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 608 nicht ständig neue Oberflächen rendern muss/müssen. Selbst wenn die GPU(S) 608 eingeschaltet ist/sind und aktiv 3D-Rendering betreibt/betreiben, kann der Videobildkompositor verwendet werden, um den/die GPU(s) 608 zu entlasten und so die Leistung und die Reaktionsfähigkeit zu verbessern.
  • Der/die SoC(s) 604 kann ferner eine serielle Mobilindustrieprozessorschnittstellen (MIPI; mobile industry processor interface)-Kameraschnittstelle zum Empfangen von Video und Input von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann, beinhalten. Der/die SoC(s) 604 kann/können ferner einen oder mehrere Eingangs-/Ausgangs-Controller enthalten, der/die durch Software gesteuert werden kann/können und für den Empfang von E/A-Signalen verwendet werden kann/können, die keiner bestimmten Rolle zugeordnet sind.
  • Der/die SoC(s) 604 kann/können ferner eine breite Palette von Peripherieschnittstellen beinhalten, um Kommunikation mit Peripheriegeräten, Audiocodecs, Energieverwaltung und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 604 kann/können zur Verarbeitung von Daten von Kameras (z.B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z.B. LIDAR-Sensor(en) 664, RADAR-Sensor(en) 660 usw., die über Ethernet verbunden sein können), Daten vom Bus 602 (z.B. Geschwindigkeit des Fahrzeugs 600, Lenkradposition usw.), Daten von GNSS-Sensor(en) 658 (z.B. verbunden über Ethernet oder CAN-Bus) verwendet werden. Der/die SoC(s) 604 kann/können ferner dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und dazu verwendet werden können, die CPU(s) 606 von Routineaufgaben der Datenverwaltung zu entlasten.
  • Der/die SoC(s) 604 kann/können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsebenen 3 bis 5 umfasst und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die effizient Computer-Vision- und ADAS-Techniken für Diversität und Redundanz nutzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bereitstellt. Der/die SoC(s) 604 kann/können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel kann der/die Beschleuniger 614 in Kombination mit der/den CPU(s) 606, der/den GPU(s) 608 und dem/den Datenspeicher(n) 616 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
  • Die Technologie bietet somit Fähigkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreicht werden können. Beispielsweise können Computer-Vision-Algorithmen auf CPUs ausgeführt werden, die mit Hilfe 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. Jedoch sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Computer-Vision-Anwendungen zu erfüllen, wie beispielsweise solchen, die sich auf Ausführungszeit und Stromverbrauch beziehen. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterfassungsalgorithmen in Echtzeit auszuführen, welches eine Voraussetzung für fahrzeuginterne ADAS-Anwendungen und eine Voraussetzung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
  • Im Gegensatz zu herkömmlichen Systemen ermöglicht die hierin beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters die gleichzeitige und/oder sequenzielle Ausführung mehrerer neuronaler Netzwerke und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Beispielsweise kann ein CNN, das auf dem DLA oder der dGPU (z.B. der/den GPU(s) 620) ausgeführt wird, eine Text- und Worterfassung beinhalten, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netzwerk nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk enthalten, das in der Lage ist, das Verkehrszeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
  • Als ein weiteres Beispiel können mehrere neuronale Netzwerke gleichzeitig betrieben werden, wie es für das Fahren in den Stufen 3, 4 oder 5 erforderlich ist. Beispielsweise kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Eisglätte hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netzwerk (z.B. einem trainierten neuronalen Netzwerk) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter weisen auf Eisglätte hin“ kann von einem zweiten eingesetzten neuronalen Netzwerk interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass, wenn blinkende Lichter erfasst werden, Glatteis vorliegt. Das Blinklicht kann durch den Betrieb eines dritten neuronalen Netzwerks über mehrere Frames hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netzwerke können gleichzeitig laufen, wie beispielsweise innerhalb des DLA und/oder auf der/den GPU(s) 608.
  • In einigen Beispielen kann ein CNN zur Gesichtserkennung und Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 600 zu identifizieren. Die „always on“-Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert, und die Lichter einzuschalten, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen die SoC(s) 604 für Sicherheit gegen Diebstahl und/oder Carjacking.
  • In einem anderen Beispiel kann ein CNN zur Erfassung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 696 verwenden, um Sirenen von Einsatzfahrzeugen zu erfassen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erfassung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzen die SoC(s) 604 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einer bevorzugten Ausführungsform ist das CNN, das auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erfassen (z.B. durch Verwendung des Dopplereffekts). Das CNN kann auch dazu trainiert sein, Einsatzfahrzeuge zu identifizieren, die spezifisch für das lokale Gebiet sind, in dem das Fahrzeug operiert, wie es durch die GNSS-Sensor(en) 658 identifiziert wird. So wird das CNN z.B. bei einem Einsatz in Europa versuchen, europäische Sirenen zu erfassen, und bei einem Einsatz in den Vereinigten Staaten wird das CNN versuchen, nur nordamerikanische Sirenen zu erfassen. Sobald ein Einsatzfahrzeug erfasst wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge 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, und zwar mit Hilfe der Ultraschallsensoren 662, bis das/die Einsatzfahrzeug(e) vorbeigefahren sind.
  • Das Fahrzeug kann eine oder mehrere CPU(s) 618 (z.B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitsverbindung (z.B. PCle) mit dem/den SoC(s) 604 gekoppelt sein kann/können. Die CPU(s) 618 kann/können z.B. einen X86-Prozessor beinhalten. Die CPU(s) 618 kann/können verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich der Schlichtung potenziell widersprüchlicher Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 604 und/oder der Überwachung des Status und des Zustands des/der Steuereinheit(en) bzw. Controller(s) 636 und/oder des Infotainment-SoC 630, zum Beispiel.
  • Das Fahrzeug 600 kann eine oder mehrere GPU(s) 620 (z.B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) mit dem/den SoC(s) 604 gekoppelt sein können. Die GPU(s) 620 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z.B. durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netzwerke, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netzwerke auf der Grundlage von Eingaben (z.B. Sensordaten) von Sensoren des Fahrzeugs 600 verwendet werden.
  • Das Fahrzeug 600 kann ferner die Netzwerkschnittstelle 624 beinhalten, die eine oder mehrere Drahtlos-Antennen 626 (z.B. eine oder mehrere Drahtlos-Antennen für verschiedene Kommunikationsprotokolle, wie beispielsweise eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) beinhalten kann. Die Netzwerkschnittstelle 624 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z.B. mit dem/den Server(n) 678 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Computergeräten (z.B. Client-Geräten von Fahrgästen) zu ermöglichen. Zur Kommunikation mit anderen Fahrzeugen kann eine direkte Verbindung zwischen den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z.B. über Netzwerke und das Internet). Direkte Verbindungen können über eine Fahrzeugzu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 600 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 600 liefern (z.B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 600). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 600 sein.
  • Die Netzwerkschnittstelle 624 kann ein SoC beinhalten, das Modulations- und Demodulations-Funktionen bereitstellt und die Steuereinheit(en) 636 in die Lage versetzt, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 624 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband beinhalten. Die Frequenzumwandlungen können mit bekannten Verfahren und/oder mit Super-Heterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Funkfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
  • Das Fahrzeug 600 kann ferner einen oder mehrere Datenspeicher 628 beinhalten, welches eine Speicherung außerhalb des Chips (z.B. außerhalb des/der SoC(s) 604) beinhalten kann. Der/die Datenspeicher 628 kann/können ein oder mehrere Speicherelemente beinhalten, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Datenbit speichern können.
  • Das Fahrzeug 600 kann ferner einen oder mehrere GNSS-Sensoren 658 beinhalten. Der/die GNSS-Sensor(en) 658 (z.B. GPS, unterstützte GPS-Sensoren, Differential-GPS-Sensoren (DGPS) usw.) unterstützen bei der Kartierung, Wahrnehmung, Erzeugung von Belegungsrastern und/oder Pfadplanungsfunktionen. Es kann eine beliebige Anzahl von GNSS-Sensoren 658 verwendet werden, einschließlich, zum Beispiel und ohne Beschränkung darauf, eines GPS, das einen USB-Anschluss mit einer Ethernetzu-Seriell (RS-232)-Brücke verwendet.
  • Das Fahrzeug 600 kann ferner RADAR-Sensor(en) 660 beinhalten. Der/die RADAR-Sensor(en) 660 kann/können von dem Fahrzeug 600 zur Fahrzeugerfassung über große Entfernungen, auch bei Dunkelheit und/oder schlechten Wetterbedingungen, verwendet werden. Der/die RADAR-Sensor(en) 660 kann/können den CAN-Bus und/oder den Bus 602 (z.B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 660 erzeugt wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise und ohne Beschränkung darauf können der/die RADAR-Sensor(en) 660 für Front-, Heck- und Seiten-RADAR-Einsatz geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
  • Der/die RADAR-Sensor(en) 660 kann/können verschiedene Konfigurationen beinhalten, wie z.B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, seitliche Abdeckung kurzer Reichweite usw. In einigen Beispielen kann RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bieten, das durch zwei oder mehr unabhängige Abtastungen realisiert wird, wie z.B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 660 kann/können helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. RADAR-Langstreckensensoren können ein monostatisches multimodales RADAR mit mehreren (z.B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu dient, die Umgebung des Fahrzeugs bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Fahrspur des Fahrzeugs 600 einfahren oder sie verlassen, schnell erfasst werden können.
  • RADAR-Systeme mit mittlerer Reichweite können z.B. eine Reichweite von bis zu 660 m (vorne) bzw. 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) bzw. 650 Grad (hinten) beinhalten. Kurzstrecken-RADAR-Systeme können unter anderem RADAR-Sensoren enthalten, die für den Einbau an beiden Enden des hinteren Stoßfängers ausgelegt sind. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinten und neben dem Fahrzeug ständig überwachen.
  • RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erfassung des toten Winkels und/oder als Spurwechselassistent eingesetzt werden.
  • Das Fahrzeug 600 kann ferner einen oder mehrere Ultraschallsensoren 662 enthalten. Der/die Ultraschallsensor(en) 662, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 600 angebracht sein kann/können, kann/können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 662 verwendet werden, und unterschiedliche Ultraschallsensoren 662 können für unterschiedliche Erfassungsbereiche (z.B. 2,5 m, 4 m) eingesetzt werden. Der/die Ultraschallsensor(en) 662 kann/können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
  • Das Fahrzeug 600 kann LIDAR-Sensor(en) 664 beinhalten. Der/die LIDAR-Sensor(en) 664 kann/können zur Objekt- und Fußgängererfassung, Notbremsung, Kollisionsvermeidung und/oder anderen Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 664 kann/können der funktionalen Sicherheitsstufe ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 600 mehrere LIDAR-Sensoren 664 (z.B. zwei, vier, sechs usw.) enthalten, die Ethernet verwenden können (z.B. um Daten an einen Gigabit-Ethernet-Switch zu liefern).
  • In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 664 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Kommerziell erhältliche LIDAR-Sensoren 664 können eine Reichweite von ca. 600 m haben, mit einer Genauigkeit von 2 cm bis 3 cm und mit Unterstützung für eine 600 Mbps-Ethernet-Verbindung, zum Beispiel. In einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 664 verwendet werden. In solchen Beispielen kann/können der/die LIDAR-Sensor(en) 664 als eine kleine Vorrichtung implementiert sein, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 600 eingebettet sein kann. Der/die LIDAR-Sensor(en) 664 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 620 Grad und ein vertikales Sichtfeld von 35 Grad mit einer Reichweite von 200 m selbst für Objekte mit geringer Reflektivität bieten. Ein oder mehrere an der Vorderseite montierte LIDAR-Sensor(en) 664 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
  • In einigen Beispielen können auch LIDAR-Technologien wie 3D-Blitz-LIDAR verwendet werden. 3D-Blitz-LIDAR verwendet einen Laserblitz als eine Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von etwa 200 m zu beleuchten. Eine Flash-LIDAR-Einheit beinhaltet einen Rezeptor, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung zwischen dem Fahrzeug und den Objekten entspricht. Mit Flash-LIDAR lassen sich mit jedem Laserblitz hochpräzise und verzerrungsfreie Bilder der Umgebung erzeugen. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt sein, einer an jeder Seite des Fahrzeugs 600. Verfügbare 3D-Blitz-LIDAR-Systeme beinhalten eine Festkörper-3D-Staring-Array-LIDAR-Kamera, die außer einem Lüfter keine beweglichen Teile aufweist (z.B. eine nicht-abtastende LIDAR-Vorrichtung). Die Flash-LIDAR-Vorrichtung kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Frame verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und koregistrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR, und weil Flash-LIDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, kann/können der/die LIDAR-Sensor(en) 664 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
  • Das Fahrzeug kann ferner den/die IMU-Sensor(en) 666 enthalten. Der/die IMU-Sensor(en) 666 kann/können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 600 angeordnet sein. Der/die IMU-Sensor(en) 666 kann/können beispielsweise, und ohne Beschränkung darauf, einen oder mehrere Beschleunigungsmesser, einen oder mehrere Magnetometer, ein oder mehrere Gyroskope, einen oder mehrere Magnetkompasse und/oder andere Sensortypen beinhalten. In einigen Beispielen, wie z.B. in sechsachsigen Anwendungen, kann/können der/die IMU-Sensor(en) 666 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 666 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten kann/können.
  • In einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 666 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert sein, das MEMS-Trägheitssensoren, einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. In einigen Beispielen kann/können der/die IMU-Sensoren 666 das Fahrzeug 600 in die Lage versetzen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem die Geschwindigkeitsänderungen von dem GPS direkt beobachtet und mit dem/den IMU-Sensoren 666 korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 666 und der/die GNSS-Sensor(en) 658 in einer einzigen integrierten Einheit kombiniert sein.
  • Das Fahrzeug kann ein oder mehrere Mikrofone 696 enthalten, das/die in und/oder um das Fahrzeug 600 platziert sind. Das/die Mikrofon(e) 696 kann/können unter anderem zur Erfassung und Identifizierung von Einsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, einschließlich Stereokamera(s) 668, Weitwinkelkamera(s) 670, Infrarotkamera(s) 672, Umgebungskamera(s) 674, Lang- und/oder Mittelstreckenkamera(s) 698 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 600 zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen für das Fahrzeug 600 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 600 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. Beispielsweise kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras enthalten. Die Kameras können zum Beispiel, und ohne Beschränkung darauf, Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras ist hierin mit Bezug auf 6A und 6B ausführlicher beschrieben.
  • Das Fahrzeug 600 kann ferner einen oder mehrere Schwingungs- bzw. Vibrationssensoren 642 beinhalten. Der/die Vibrationssensor(en) 642 kann/können Schwingungen bzw. Vibrationen von Komponenten des Fahrzeugs, wie z.B. der Achse(n), messen. Beispielsweise können Änderungen der Vibrationen auf eine Änderung der Straßenoberfläche hinweisen. In einem anderen Beispiel können bei Verwendung von zwei oder mehr Vibrationssensoren 642 die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z.B. wenn der Unterschied in der Vibration zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
  • Das Fahrzeug 600 kann ein ADAS-System 638 beinhalten. Das ADAS-System 638 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 638 kann eine autonome/adaptive/automatische Geschwindigkeitsregelung (ACC), eine kooperative adaptive Geschwindigkeitsregelung (CACC), eine Auffahrwarnung (FCW; forward crash warning), eine automatische Notbremsung (AEB), eine Spurverlassenswarnung (LDW), einen Spurhalteassistenten (LKA), einen Totwinkelwarner (BSW), einen Querverkehrswarner (RCTW), Kollisionswarnsystems (CWS), eine Spurenzentrierung (LC; lane centering) und/oder andere Merkmale und Funktionen beinhalten.
  • Die ACC-Systeme können RADAR-Sensor(en) 660, LIDAR-Sensor(en) 664 und/oder eine oder mehrere Kamera(s) verwenden. Die ACC-Systeme können eine ACC in Längsrichtung und/oder eine ACC in Querrichtung beinhalten. Die ACC in Längsrichtung überwacht und steuert den Abstand zu dem unmittelbar vor dem Fahrzeug 600 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die ACC in Querrichtung sorgt für die Einhaltung des Abstands und rät dem Fahrzeug 600, bei Bedarf die Spur zu wechseln. Die ACC in Querrichtung ist mit anderen ADAS-Anwendungen wie LCA und CWS verwandt.
  • CACC nutzt Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 624 und/oder die Funkantenne(n) 626 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z.B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-zu-Fahrzeug (V2V)-Kommunikationsverbindung bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug (12V)-Kommunikationsverbindung sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z.B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 600 und auf derselben Fahrspur wie dieses befinden), während das 12V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können eine oder beide 12V- und V2V-Informationsquellen beinhalten. Angesichts der Informationen über die vor dem Fahrzeug 600 fahrenden Fahrzeuge kann CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu verringern.
  • FCW-Systeme sind so konzipiert, dass sie den Fahrer vor einer Gefahr warnen, so dass der Fahrer korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder einen oder mehrere RADAR-Sensor(en) 660, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit der Rückmeldung an den Fahrer verbunden ist, z.B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z.B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-Systeme erfassen einen drohenden Zusammenstoß mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, falls der Fahrer nicht innerhalb eines bestimmten Zeit- oder Entfernungsparameters korrigierend eingreift. AEB-Systeme können eine oder mehrere nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 660 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC verbunden sind. Wenn das AEB-System eine Gefahr erfasst, warnt es in der Regel zunächst den Fahrer, damit dieser korrigierend eingreift, um die Kollision zu vermeiden, und falls der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzumildern. AEB-Systeme können Techniken wie dynamische Bremsunterstützung und/oder die Crash-Imminent Braking beinhalten.
  • LDW-Systeme stellen visuelle, hörbare und/oder taktile Warnungen, wie beispielsweise Lenkrad- oder Sitz-Vibrationen, bereit, um den Fahrer zu warnen, wenn das Fahrzeug 600 Fahrbahnmarkierungen quert. Ein LDW-System aktiviert sich nicht, wenn der Fahrer durch Betätigen eines Richtungsanzeigesignals ein absichtliches Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC verbunden sind, der elektrisch mit einer Rückmeldung an den Fahrer gekoppelt ist, z.B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme stellen Lenkeingaben oder Bremsen bereit, um das Fahrzeug 600 zu korrigieren, falls das Fahrzeug 600 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme erfassen und warnen den Fahrer vor Fahrzeugen, die sich in einem toten Winkel des Fahrzeugs befinden. BSW-Systeme können ein optisches, akustisches und/oder taktiles Warnsignal bereitstellen, um darauf hinzuweisen, dass ein Einscheren oder Wechseln der Fahrspur unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Richtungsanzeiger betätigt. BSW-Systeme können eine oder mehrere nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 660 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer gekoppelt ist, z.B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können eine visuelle, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb des Bereichs der Rückfahrkamera erfasst wird, wenn das Fahrzeug 600 rückwärtsfährt. Einige RCTW-Systeme beinhalten AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensoren 660 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer gekoppelt ist, z.B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • Konventionelle ADAS-Systeme können für falsch positive Ergebnisse anfällig sein, welche für den Fahrer ärgerlich und ablenkend sein können, aber in der Regel nicht katastrophal sind, weil die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob eine Sicherheitsbedingung wirklich vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 600 muss das Fahrzeug 600 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z.B. einer ersten Steuereinheit 636 oder einer zweiten Steuereinheit 636) beachtet. In einigen Ausführungsformen kann das ADAS-System 638 beispielsweise ein Backup- und/oder Sekundärcomputer sein, der Wahrnehmungsinformationen an ein Rationalitätsmodul des Backup-Computers liefert. Der Rationalitätsmonitor des Backup-Computers kann eine redundante Software auf Hardwarekomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erfassen. Ausgaben des ADAS-Systems 638 können an eine übergeordnete bzw. überwachende MCU weitergeleitet werden. Falls Ausgaben des Primärrechners und des Sekundärrechners in Konflikt geraten, muss die überwachende MCU bestimmen, wie der Konflikt zu lösen ist, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der Primärcomputer dazu konfiguriert sein, der überwachenden MCU einen Konfidenzwert zu liefern, der das Vertrauen des Primärcomputers in das gewählte Ergebnis angibt. Übersteigt der Konfidenzwert einen Schwellenwert, kann die überwachende MCU der Anweisung des Primärcomputers folgen, unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Erreicht der Konfidenzwert den Schwellenwert nicht und zeigen der primäre und der sekundäre Computer unterschiedliche Ergebnisse an (z.B. den Konflikt), kann die überwachende MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
  • Die überwachende MCU kann dazu konfiguriert sein, ein neuronales Netzwerk bzw. neuronale Netzwerke zu betreiben, das bzw. die so trainiert und konfiguriert ist bzw. sind, dass es bzw. sie auf der Grundlage der Ausgaben des Primärcomputers und des Sekundärcomputers die Bedingungen bestimmt bzw. bestimmen, unter denen der Sekundärcomputer Fehlalarme liefert. So kann das neuronale Netzwerk bzw. können die neuronalen Netzwerke in der überwachenden MCU erfassen, wann den Ausgaben des Sekundärcomputers vertraut werden kann und wann nicht. Handelt es sich bei dem sekundären Computer beispielsweise um ein RADAR-basiertes FCW-System, kann ein neuronales Netzwerk in der überwachenden MCU lernen, wann das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahr darstellen, wie etwa ein Abflussgitter oder ein Schachtdeckel, der einen Alarm auslöst. In ähnlicher Weise kann dann, wenn der Sekundärcomputer ein kamerabasiertes Spurhaltewarnsystem ist, ein neuronales Netzwerk in der überwachenden MCU lernen, das Spurhaltewarnsystem zu übersteuern, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die (ein) neuronale(s) Netzwerk(e) enthalten, das/die auf der überwachenden MCU laufen, kann die überwachende MCU mindestens einen DLA oder eine GPU enthalten, der/die für den Betrieb des/der neuronalen Netzwerks/Netzwerke mit zugehörigem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die überwachende MCU eine Komponente des/der SoC(s) 604 umfassen und/oder als eine solche enthalten sein.
  • In anderen Beispielen kann das ADAS-System 638 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung herkömmlicher Regeln der Computer Vision ausführt. So kann der sekundäre Computer klassische Computer-Vision-Regeln (wenn-dann) verwenden, und kann das Vorhandensein eines neuronalen Netzwerkes (von neuronalen Netzwerken) in der überwachenden MCU die Zuverlässigkeit, Sicherheit und Leistung verbessern. Beispielsweise wird das Gesamtsystem durch die unterschiedliche Implementierung und die absichtliche Nichtidentität fehlertoleranter, insbesondere gegenüber Fehlern, die durch Softwarefunktionen (oder Software-Hardware-Schnittstellen) verursacht werden. Wenn beispielsweise ein Softwarefehler in der auf dem Primärcomputer laufenden Software auftritt und der nicht identische Softwarecode auf dem Sekundärcomputer das gleiche Gesamtergebnis liefert, kann die überwachende MCU mit größerer Sicherheit davon ausgehen, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder der Hardware des Primärcomputers keinen wesentlichen Fehler verursacht.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 638 in den Wahrnehmungsblock des Primärrechners und/oder den Block für dynamische Fahraufgaben des Primärrechners eingespeist werden. Wenn das ADAS-System 638 beispielsweise eine Warnung vor einem Aufprall aufgrund eines unmittelbar vorausliegenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer über ein eigenes neuronales Netzwerk verfügen, das trainiert ist und somit das Risiko von Fehlalarmen bzw. Falsch-Positiven reduziert, wie hierin beschrieben.
  • Das Fahrzeug 600 kann ferner das Infotainment-SoC 630 (z.B. ein fahrzeuginternes Infotainment-System (IVI)) enthalten. Obwohl als SoC dargestellt und beschrieben, braucht das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 630 kann eine Kombination aus Hardware und Software beinhalten, die verwendet werden kann, um Audio (z.B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z.B. TV, Filme, Streaming usw.), Telefon (z.B. Freisprechen), Netzwerkkonnektivität (z.B., LTE, Wi-Fi usw.) und/oder Informationsdienste (z.B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) für das Fahrzeug 600 bereitzustellen. Das Infotainment-SoC 630 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, eine Heads-up-Anzeige (HUD), eine HMI-Anzeige 634, ein Telematikgerät, ein Bedienfeld (z.B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten enthalten. Das Infotainment-SoC 630 kann ferner dazu verwendet werden, einem oder mehreren Nutzern des Fahrzeugs Informationen (z.B. visuell und/oder akustisch) zur Verfügung zu stellen, wie z.B. Informationen vom ADAS-System 638, autonome Fahrinformationen wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z.B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Das Infotainment-SoC 630 kann GPU-Funktionalität beinhalten. Das Infotainment-SoC 630 kann über den Bus 602 (z.B. CAN-Bus, Ethernet, usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 600 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 630 mit einer überwachenden MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuereinheit(en) 636 (z.B. die primären und/oder Backup-Computer des Fahrzeugs 600) ausfallen. In einem solchen Beispiel kann das Infotainment-SoC 630 das Fahrzeug 600 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen, wie hierin beschrieben.
  • Das Fahrzeug 600 kann ferner ein Kombiinstrument 632 (z.B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) enthalten. Das Kombiinstrument 632 kann eine Steuereinheit und/oder einen Supercomputer (z.B. eine diskrete Steuereinrichtung bzw. Controller oder einen Supercomputer) enthalten. Das Kombiinstrument 632 kann eine Reihe von Instrumenten beinhalten, wie z.B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über das Airbag-System (SRS), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können Informationen von dem Infotainment SoC 630 und dem Kombiinstrument 632 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 632 kann als Teil des Infotainment-SoC 630 enthalten sein, oder umgekehrt.
  • 6D ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 600 von 6A, in Übereinstimmung mit einigen Ausführungsformen der Erfindung. Das System 676 kann den/die Server 678, das/die Netzwerk(e) 690 und Fahrzeuge, einschließlich des Fahrzeugs 600, beinhalten. Der/die Server 678 kann/können eine Vielzahl von GPUs 684(A)-684(H) (hierin kollektiv als GPUs 684 bezeichnet), PCIe-Switches 682(A)-682(H) (hierin kollektiv als PCIe-Switches 682 bezeichnet) und/oder CPUs 680(A)-680(B) (hierin kollektiv als CPUs 680 bezeichnet) beinhalten. Die GPUs 684, die CPUs 680 und die PCIe-Switches können mit Hochgeschwindigkeitsverbindungen wie z.B. den von NVIDIA entwickelten NVLink-Schnittstellen 688 und/oder PCIe-Verbindungen 686 miteinander verbunden sein. In einigen Beispielen sind die GPUs 684 über NVLink und/oder NVSwitch SoC verbunden, und sind die GPUs 684 und die PCIe-Switches 682 über PCIe-Verbindungen verbunden. Obwohl acht GPUs 684, zwei CPUs 680 und zwei PCIe-Switches dargestellt sind, ist dies nicht als Beschränkung zu verstehen. Je nach Ausführungsform kann der/jeder der Server 678 eine beliebige Anzahl von GPUs 684, CPUs 680 und/oder PCIe-Switches enthalten. Beispielsweise können der/die Server 678 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 684 enthalten.
  • Der/die Server 678 kann/können über das/die Netzwerk(e) 690 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, wie z.B. kürzlich begonnene Straßenbauarbeiten. Der/die Server 678 kann/können über das/die Netzwerk(e) 690 und an die Fahrzeuge neuronale Netzwerke 692, aktualisierte neuronale Netzwerke 692 und/oder Karteninformationen 694 übertragen, die Informationen über den Verkehr und die Straßenbedingungen beinhalten. Die Aktualisierungen der Karteninformationen 694 können Aktualisierungen für die HD-Karte 622 beinhalten, wie beispielsweise Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netzwerke 692, die aktualisierten neuronalen Netzwerke 692 und/oder die Karteninformationen 694 aus neuem Training und/oder Erfahrungen resultieren, die in Daten repräsentiert sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf Training basieren, das in einem Datenzentrum durchgeführt wurde (z.B. unter Verwendung des/der Server(s) 678 und/oder anderer Server).
  • Der/die Server 678 kann/können zum Trainieren von Modellen maschinellen Lernens (z.B. neuronalen Netzwerken) auf der Grundlage von Trainingsdaten verwendet werden. Die Trainingsdaten können von den Fahrzeugen und/oder in einer Simulation (z.B. unter Verwendung einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen bzw. getaggt (z.B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z.B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Das Training kann in Übereinstimmung mit einer oder mehreren Klassen von maschinellen Lerntechniken durchgeführt werden, einschließlich, aber nicht beschränkt auf, Klassen wie beispielsweise: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Subraumlernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerfassung und alle Varianten oder Kombinationen davon. Sobald die Modelle maschinellen Lernens trainiert sind, können die Modelle maschinellen Lernens von den Fahrzeugen verwendet werden (z.B. an die Fahrzeuge über das/die Netzwerk(e) 690 übertragen werden) und/oder können die Modelle maschinellen Lernens von dem/den Server(n) 678 verwendet werden, um die Fahrzeuge aus der Ferne zu überwachen.
  • In einigen Beispielen kann/können der/die Server 678 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netzwerke für intelligente Echtzeit-Inferenzierung anwenden. Der/die Server 678 kann/können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer enthalten, die von einer oder mehreren GPU(s) 684 angetrieben werden, wie z.B. die von NVIDIA entwickelten DGX- und DGX Station-Maschinen. In einigen Beispielen kann/können der/die Server 678 jedoch auch eine Deep-Learning-Infrastruktur beinhalten, die nur CPU-betriebene Rechenzentren verwendet.
  • Die Deep-Learning-Infrastruktur des/der Server(s) 678 kann in der Lage sein, schnelle Echtzeit-Inferenzierung durchzuführen und diese Fähigkeit zu nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware in dem Fahrzeug 600 zu evaluieren und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen von dem Fahrzeug 600 erhalten, wie z.B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 600 in dieser Bildsequenz (z.B. über Computer Vision und/oder andere maschinelle Objektklassifizierungstechniken) lokalisiert hat. Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk laufen lassen, um die Objekte zu identifizieren und sie mit den von dem Fahrzeug 600 identifizierten Objekten zu vergleichen. Falls die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI in dem Fahrzeug 600 eine Fehlfunktion aufweist, kann/können der/die Server 678 ein Signal an das Fahrzeug 600 senden, das einen ausfallsicheren Computer des Fahrzeugs 600 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Zur Inferenzierung kann/können der/die Server 678 die GPU(s) 684 und einen oder mehrere programmierbare Inferenzbeschleuniger (z.B. TensorRT von NVIDIA) enthalten. Die Kombination aus GPU-getriebenen Servern und Inferenzbeschleunigung kann eine Echtzeit-Reaktionsfähigkeit ermöglichen. In anderen Beispielen, in denen Leistungsfähigkeit weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren getriebene Server zur Inferenzierung verwendet werden.
  • BEISPIELHAFTE RECHENVORRICHTUNG
  • 7 ist ein Blockdiagramm einer oder mehrerer beispielhafter Computer- bzw. Rechenvorrichtung(en) 700, die zur Verwendung bei der Implementierung einiger Ausführungsformen der Erfindung geeignet ist/sind. Die Rechenvorrichtung 700 kann ein Verbindungssystem 702 enthalten, das direkt oder indirekt die folgenden Vorrichtungen koppelt: Speicher 704, eine oder mehrere Zentralverarbeitungseinheiten (CPUs) 706, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 708, eine Kommunikationsschnittstelle 710, Eingabe-/Ausgabe (E/A)-Ports 712, Eingabe-/Ausgabe-Komponenten 714, eine Stromversorgung 716, eine oder mehrere Darstellungs- bzw. Präsentationskomponenten 718 (z.B. eine oder mehrere Anzeige(n)) und eine oder mehrere Logikeinheiten 720.
  • Obwohl die verschiedenen Blöcke in 7 als über das Interconnect- bzw. Verbindungssystem 702 mit Leitungen verbunden dargestellt sind, ist dies nicht als Beschränkung zu verstehen und dient nur der Klarheit. In einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente 718, wie beispielsweise eine Anzeigevorrichtung, als eine E/A-Komponente 714 betrachtet werden (z.B. falls die Anzeige ein Touchscreen ist). Als ein weiteres Beispiel können die CPUs 706 und/oder die GPUs 708 Speicher enthalten (z.B. kann der Speicher 704 repräsentativ sein für eine Speichervorrichtung zusätzlich zu dem Speicher der GPUs 708, der CPUs 706 und/oder anderer Komponenten). Mit anderen Worten ist die Rechenvorrichtung von 7 lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da sie alle in den Anwendungsbereich der Rechenvorrichtung von 7 fallen.
  • Das Verbindungssystem 702 kann eine oder mehrere Verbindungen oder Busse repräsentieren, wie z.B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 702 kann einen oder mehrere Bus- oder Verbindungstypen beinhalten, wie z.B. einen ISA (Industry Standard Architecture)-Bus, einen EISA (Extended Industry Standard Architecture)-Bus, einen VESA (Video Electronics Standards Association)-Bus, einen PCI (Peripheral Component Interconnect)-Bus, einen PCle (Peripheral Component Interconnect Express)-Bus und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Beispielsweise kann die CPU 706 direkt mit dem Speicher 704 verbunden sein. Ferner kann die CPU 706 direkt mit der GPU 708 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 702 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen braucht ein PCI-Bus nicht in der Rechenvorrichtung 700 enthalten zu sein.
  • Der Speicher 704 kann eine Vielzahl von computerlesbaren Medien beinhalten. Die computerlesbaren Medien können jedes verfügbare Medium sein, auf das die Rechenvorrichtung 700 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entnehmbare und nicht-entnehmbare Medien beinhalten. Als Beispiel und ohne Beschränkung darauf können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entnehmbare und nichtentfernbare Medien beinhalten, die in einem beliebigen Verfahren oder in einer beliebigen Technologie zur Speicherung von Informationen wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 704 computerlesbare Anweisungen speichern (z.B. solche, die ein Programm bzw. Programme und/oder ein Programmelement bzw. Programmelemente repräsentieren, wie z.B. ein Betriebssystem. Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das die Rechenvorrichtung 700 zugreifen kann, ist aber nicht darauf beschränkt. Der hierin verwendete Begriff „Computerspeichermedium“ umfasst nicht per se Signale.
  • Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und beinhalten beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so festgelegt oder verändert sind, dass Informationen in dem Signal kodiert werden. Beispielhaft und ohne Beschränkung darauf können die Computerspeichermedien verdrahtete Medien, wie beispielsweise ein verdrahtetes Netzwerk oder eine Direktverbindung, und drahtlose Medien, wie beispielsweise akustische, RF-, Infrarot- und andere drahtlose Medien, beinhalten. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der computerlesbaren Medien einbezogen werden.
  • Die CPU(s) 706 kann/können dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 700 zu steuern, um eine oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 706 kann/können jeweils einen oder mehrere Kerne (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) enthalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 706 kann/können jede Art von Prozessor beinhalten und je nach Art der implementierten Rechenvorrichtung 700 verschiedene Arten von Prozessoren umfassen (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art der Rechenvorrichtung 700 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) arbeitet, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) arbeitet. Die Rechenvorrichtung 700 kann eine oder mehrere CPUs 706 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z.B. mathematischen Co-Prozessoren, enthalten.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 706 kann/können die GPU(s) 708 dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 700 zu steuern, um einen/eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 708 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 706), und/oder eine oder mehrere der GPU(s) 708 können eine diskrete GPU sein. In Ausführungsformen kann/können eine oder mehrere der GPU(s) 708 ein Co-Prozessor einer oder mehrerer der CPU(s) 706 sein. Die GPU(S) 708 kann/können von der Computervorrichtung 700 verwendet werden, um Grafiken (z.B. 3D-Grafiken) zu rendern oder allgemeine Berechnungen durchzuführen. Die GPU(s) 708 kann/können zum Beispiel für General-Purpose Computing on GPUs (GPGPU) verwendet werden. Die GPU(S) 708 kann/können Hunderte oder Tausende von Kernen enthalten, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 708 kann/können im Ansprechen auf Rendering-Befehle (z.B. Rendering-Befehle von der/den CPU(s) 706, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 708 kann/können einen Grafikspeicher, wie beispielsweise einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, z.B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 704 enthalten sein. Die GPU(s) 708 kann/können zwei oder mehr GPUs beinhalten, die parallel arbeiten (z.B. über eine Verbindung). Die Verbindung kann die GPUs direkt (z.B. mit NVLINK) oder über einen Switch (z.B. mit NVSwitch) verbinden. Wenn sie miteinander kombiniert sind, kann jede GPU 708 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher beinhalten oder sich den Speicher mit anderen GPUs teilen.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 706 und/oder der/den GPU(s) 708 kann/können die Logikeinheit(en) 720 dazu konfiguriert sein, zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 700 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 706, die GPU(s) 708 und/oder die Logikeinheit(en) 720 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 720 können Teil einer oder mehrerer der CPU(s) 706 und/oder der GPU(s) 708 sein und/oder eine oder mehrere der Logikeinheiten 720 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 706 und/oder der GPU(s) 708 liegen. In Ausführungsformen kann eine oder mehrere der Logikeinheiten 720 ein Co-Prozessor einer oder mehrerer der CPU(s) 706 und/oder einer oder mehrerer der GPU(S) 708 sein.
  • Beispiele der Logikeinheit(en) 720 beinhalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie beispielsweise Tensorkerne (TCs; Tensor Cores), Tensorverarbeitungseinheiten (TPUs; Tensor Processing Units), Pixel-visuelle Kerne (PVCs; Pixel Visual Cores), Vision-Verarbeitungseinheiten (VPUs; Vision Processing Units), Graphikverarbeitungscluster (GPCs; Graphics Processing Clusters), Texturverarbeitungscluster (TPCs; Texture Processing Clusters), Streaming-Multiprozessoren (SMs; Streaming Multiprocessors), Baumtraversierungseinheiten (TTUs; Tree Traversal Units), Beschleuniger für künstliche Intelligenz (AlAs; Artificial Intelligence Accelerators), Beschleuniger für Deep Learning Accelerators (DLAs; Deep Learning Accelerators), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkommaeinheiten (FPUs), Eingabe-/Ausgabeelemente (E/A), Peripheral Component Interconnect (PCI) oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 710 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 700 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 710 kann Komponenten und Funktionen enthalten, die die Kommunikation über eine Reihe verschiedener Netzwerke ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z.B. LoRaWAN, SigFox usw.) und/oder das Internet.
  • Die E/A-Anschlüsse 712 können es der Rechenvorrichtung 700 ermöglichen, logisch mit anderen Geräten, einschließlich der E/A-Komponenten 714, der Präsentationskomponente(n) 718 und/oder anderer Komponenten, von welchen einige in die Rechenvorrichtung 700 eingebaut (z.B. integriert) sein können, gekoppelt zu sein. Illustrative E/A-Komponenten 714 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 714 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherfassung, Stifterfassung, Gesichtserfassung, biometrischer Erfassung, Gestenerfassung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserfassung (wie unten ausführlicher beschrieben) in Verbindung mit einer Anzeige der Rechenvorrichtung 700 implementieren. Die Rechenvorrichtung 700 kann Tiefenkameras, wie z.B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon zur Gestenerfassung und -erfassung beinhalten. Darüber hinaus kann die Rechenvorrichtung 700 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die eine Bewegungserfassung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Rechenvorrichtung 700 verwendet werden, um immersive erweiterte Realität oder virtuelle Realität darzustellen.
  • Die Stromversorgung 716 kann eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon beinhalten. Die Stromversorgung 716 kann das Computergerät 700 mit Strom versorgen, um den Betrieb der Komponenten des Computergeräts 700 zu ermöglichen.
  • Die Präsentationskomponente(n) 718 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, eine Heads-up-Anzeige (HUD), andere Anzeigearten oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponente(n) 718 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 708, der/den CPU(s) 706 usw.) empfangen und die Daten (z.B. als Bild, Video, Ton usw.) ausgeben.
  • Die Erfindung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen beschrieben werden, einschließlich von computerausführbaren Anweisungen wie beispielsweise Programmmodulen, die von einem Computer oder einer anderen Maschine, wie beispielsweise einem persönlichen Datenassistenten oder einem anderen Handheld-Gerät, ausgeführt werden. Allgemein beziehen sich Programmmodule, die Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. enthalten, auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Erfindung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Universal-Computern, spezielleren Computergeräten usw. Die Erfindung kann auch in verteilten Computerumgebungen praktiziert werden, in denen Aufgaben von entfernt verarbeitenden Geräten ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
  • Wie hierin verwendet, ist eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente als nur ein Element oder eine Kombination von Elementen bedeutend zu interpretieren. Beispielsweise kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C beinhalten. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines des Elements A, mindestens eines des Elements B oder mindestens eines des Elements A und mindestens eines des Elements B beinhalten. Ferner kann „mindestens eines der Elemente A und B“ mindestens eines des Elements A, mindestens eines des Elements B oder mindestens eines des Elements A und mindestens eines des Elements B beinhalten.
  • Der Gegenstand der Erfindung wird hierin mit einer gewissen Genauigkeit beschrieben, um gesetzlichen Anforderungen zu genügen. Die Beschreibung selbst soll jedoch nicht den Umfang dieser Erfindung beschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu beinhalten. Außerdem sollten, obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, die Begriffe nicht so ausgelegt werden, dass sie irgendeine bestimmte Reihenfolge unter oder zwischen den verschiedenen hierin offenbarten Schritten implizieren, es sei denn und außer die Reihenfolge der einzelnen Schritte wird explizit beschrieben.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 16/101232 [0091]

Claims (20)

  1. Verfahren, umfassend: Empfangen von ersten Sensordaten, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs repräsentativ sind, und von zweiten Sensordaten, die für Zustandsinformationen entsprechend dem Fahrzeug bei jeder Instanz der Instanzen des sensorischen Felds repräsentativ sind; Erzeugen eines simulierten Profils zum Prüfen einer Funktion des Fahrzeugs, wobei das simulierte Profil Sollzustandsinformationen für das Fahrzeug an einer Vielzahl von Punkten entlang des simulierten Profils beinhaltet; Bestimmen einer nächstgelegenen Instanz der Vielzahl von Instanzen der ersten Sensordaten für einen Punkt der Vielzahl von Punkten zumindest teilweise auf der Grundlage eines Vergleichs der Zustandsinformationen und jeweiliger Sollzustandsinformationen für den Punkt; Berechnen einer Transformation für die nächstgelegene Instanz, um eine aktualisierte Instanz zu erzeugen, die den jeweiligen Sollzustandsinformationen entspricht; und Ausführen der Prüfung der Funktion zumindest teilweise auf der Grundlage der aktualisierten Instanz.
  2. Verfahren nach Anspruch 1, wobei die Zustandsinformationen und die Sollzustandsinformationen mindestens eines einer Geschwindigkeit, eines Orts oder einer Lage des Fahrzeugs repräsentieren.
  3. Verfahren nach Anspruch 1, wobei die ersten Sensordaten erfasst werden, während sich das Fahrzeug mit einer im Wesentlichen konstanten Geschwindigkeit einem Objekt nähert oder sich von diesem entfernt.
  4. Verfahren nach Anspruch 1, wobei die Funktion mindestens einem automatischen Notbrems (AEB)-System, einem Kollisionswarn (CMW)-System, einem automatischen Spurverlassenswarnsystem, einem automatischen Spurwechselsystem oder einem adaptiven Geschwindigkeitsregel (ACC)-System entspricht.
  5. Verfahren nach Anspruch 1, wobei die Transformation eine Viewport-Transformation für jedes Pixel entsprechend der nächstgelegenen Instanz des sensorischen Felds beinhaltet.
  6. Verfahren nach Anspruch 1, wobei die Transformation eine Vergrößerungsoperation beinhaltet.
  7. Verfahren nach Anspruch 1, wobei für jeden Punkt der Punkte eine jeweilige nächstgelegene Instanz aus der Vielzahl von Instanzen der ersten Sensordaten bestimmt wird und die Transformation für die jeweilige nächstgelegene Instanz berechnet wird, um einen Satz von aktualisierten Instanzen zu erzeugen, wobei ferner der Satz von aktualisierten Instanzen für die Ausführung der Prüfung der Funktion verwendet wird.
  8. Verfahren nach Anspruch 1, wobei dann, wenn die Sollzustandsinformationen innerhalb einer Schwellenähnlichkeit zu den Zustandsinformationen liegt, die nächstgelegene Instanz für die Ausführung der Prüfung der Funktion verwendet wird, ohne die Transformation zu berechnen.
  9. Verfahren nach Anspruch 1, wobei das Ausführen der Prüfung der Funktion ferner zumindest teilweise auf einem physikalischen Modell basiert, das dem Fahrzeug entspricht.
  10. Verfahren nach Anspruch 1, wobei die Sollzustandsinformationen zumindest teilweise auf der Grundlage einer Sollanfangsgeschwindigkeit des Fahrzeugs für die Ausführung der Prüfung bestimmt wird.
  11. System, umfassend: einen ersten Sensor zum Erzeugen von Instanzen erster Sensordaten entlang einer realen Trajektorie eines Fahrzeugs; einen oder mehrere zweite Sensoren zum Erzeugen entsprechender Instanzen zweiter Sensordaten, die für Zustandsinformationen des Fahrzeugs entlang der realen Trajektorie repräsentativ sind; einen oder mehrere Prozessoren; eine oder mehrere Speichervorrichtungen, auf denen programmierbare Befehle gespeichert sind, die dann, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, Vorgänge auszuführen, die umfassen: Erzeugen einer simulierten Trajektorie zum Prüfen einer Funktion des Fahrzeugs, wobei die simulierte Trajektorie Sollzustandsinformationen für das Fahrzeug an einer Vielzahl von Punkten entlang der simulierten Trajektorie beinhaltet; Erzeugen, zumindest teilweise basierend auf den Instanzen der ersten Sensordaten und Unterschieden zwischen den Zustandsinformationen und den Sollzustandsinformationen, von aktualisierten Instanzen der ersten Sensordaten entsprechend jedem Punkt der Vielzahl von Punkten; und Ausführen der Prüfung der Funktion zumindest teilweise auf der Grundlage der aktualisierten Instanzen.
  12. System nach Anspruch 11, wobei das Erzeugen der aktualisierten Instanzen der ersten Sensordaten umfasst: Bestimmen, für jeden Punkt der Vielzahl von Punkten, einer entsprechenden nächstgelegenen Instanz der Instanzen zumindest teilweise auf der Grundlage eines Vergleichs der Zustandsinformationen und jeweiliger Sollzustandsinformationen für die Punkte; und Erzeugen der aktualisierten Instanzen zumindest teilweise auf der Grundlage der nächstgelegenen Instanzen.
  13. System nach Anspruch 11, wobei die Zustandsinformationen und die Sollzustandsinformationen mindestens eines einer Geschwindigkeit, eines Orts oder einer Ausrichtung des Fahrzeugs repräsentieren.
  14. System nach Anspruch 11, wobei das Erzeugen der aktualisierten Instanzen der ersten Sensordaten ein Berechnen einer Transformation für jede einer Vielzahl von nächstgelegenen Instanzen aus den ersten Sensordaten entsprechend den jeweiligen Sollzustandsinformationen an einer entsprechenden Vielzahl von Punkten umfasst, wobei die Vielzahl von nächstgelegenen Instanzen eine Teilmenge der Instanzen ist, die auf der Grundlage eines Vergleichs der Zustandsinformationen und der jeweiligen Sollzustandsinformationen für jeden der Punkte ausgewählt sind.
  15. System nach Anspruch 12, wobei die Transformation für jeden Punkt eine Vierport-Transformation für jedes Pixel entsprechend der nächstgelegenen Instanz des sensorischen Felds zumindest teilweise auf der Grundlage der Unterschiede zwischen den Zustandsinformationen und den Sollzustandsinformationen beinhaltet.
  16. System nach Anspruch 11, wobei dann, wenn die Sollzustandsinformationen innerhalb einer Schwellenähnlichkeit zu den Zustandsinformationen einer nächstgelegenen Instanz der Instanzen liegt, die nächstgelegene Instanz als die entsprechende aktualisierte Instanz für den jeweiligen Punkt für die Ausführung der Prüfung der Funktion verwendet wird.
  17. System nach Anspruch 11, wobei die Funktion mindestens einem automatischen Notbrems (AEB)-System, einem Kollisionswarn (CMW)-System, einem automatischen Spurverlassenswarnsystem, einem automatischen Spurwechselsystem oder einem adaptiven Geschwindigkeitsregel (ACC)-System entspricht.
  18. Verfahren, umfassend: Empfangen von ersten Sensordaten, die für eine Vielzahl von Instanzen eines sensorischen Felds eines Sensors eines Fahrzeugs repräsentativ sind, und von zweiten Sensordaten, die für Zustandsinformationen entsprechend dem Fahrzeug bei jeder Instanz der Instanzen des sensorischen Felds repräsentativ sind; Erzeugen eines simulierten Profils zum Testen einer Funktion des Fahrzeugs, wobei das simulierte Profil Sollzustandsinformationen für das Fahrzeug an einer Vielzahl von Punkten entlang des simulierten Profils beinhaltet; Bestimmen, für jeden Punkt der Punkte, einer Instanz der Vielzahl von Instanzen der ersten Sensordaten mit jeweiligen Zustandsinformationen, die jeweiligen Sollzustandsinformationen für den Punkt am ähnlichsten sind; Erzeugen eines Satzes von Instanzen aus der Vielzahl von Instanzen der ersten Sensordaten zumindest teilweise auf der Grundlage der Bestimmung; und Ausführen der Prüfung der Funktion zumindest teilweise auf der Grundlage des Satzes von Instanzen.
  19. Verfahren nach Anspruch 18, wobei das Erzeugen des Satzes von Instanzen aus der Vielzahl von Instanzen der ersten Sensordaten ferner ein Transformieren der bestimmten ähnlichsten Instanzen entsprechend den jeweiligen Sollzustandsinformationen der entsprechenden Vielzahl von Punkten umfasst.
  20. Verfahren nach Anspruch 18, wobei die Sollzustandsinformationen für das Fahrzeug zumindest teilweise auf der Grundlage einer Sollanfangsgeschwindigkeit des Fahrzeugs für die Ausführung der Prüfung bestimmt wird.
DE112020002166.1T 2019-04-29 2020-04-28 Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen Pending DE112020002166T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962840048P 2019-04-29 2019-04-29
US62/840,048 2019-04-29
US16/860,824 US11927502B2 (en) 2019-04-29 2020-04-28 Simulating realistic test data from transformed real-world sensor data for autonomous machine applications
PCT/US2020/030296 WO2020223248A1 (en) 2019-04-29 2020-04-28 Simulating realistic test data from transformed real-world sensor data for autonomous machine applications
US16/860,824 2020-04-28

Publications (1)

Publication Number Publication Date
DE112020002166T5 true DE112020002166T5 (de) 2022-01-20

Family

ID=72916915

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020002166.1T Pending DE112020002166T5 (de) 2019-04-29 2020-04-28 Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen

Country Status (5)

Country Link
US (1) US11927502B2 (de)
JP (1) JP2022531092A (de)
CN (1) CN113767389A (de)
DE (1) DE112020002166T5 (de)
WO (1) WO2020223248A1 (de)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3803828B1 (de) * 2018-05-31 2022-03-30 Nissan North America, Inc. Probabilistisches objektverfolgungs- und prädiktionsframework
US11966838B2 (en) 2018-06-19 2024-04-23 Nvidia Corporation Behavior-guided path planning in autonomous machine applications
WO2020013525A1 (en) * 2018-07-11 2020-01-16 Samsung Electronics Co., Ltd. In-vehicle infotainment system communicating with unmanned aerial vehicle and method of operating the same
WO2020163390A1 (en) 2019-02-05 2020-08-13 Nvidia Corporation Driving lane perception diversity and redundancy in autonomous driving applications
US11548494B2 (en) * 2019-02-11 2023-01-10 Ford Global Technologies, Llc Lap learning for vehicle energy management optimization
US11587448B2 (en) * 2019-07-26 2023-02-21 General Electric Company Systems and methods for manifolds learning of airline network data
US11551414B2 (en) * 2019-12-02 2023-01-10 Woven Planet North America, Inc. Simulation architecture for on-vehicle testing and validation
WO2021124110A1 (en) * 2019-12-17 2021-06-24 Foretellix Ltd. System and methods thereof for monitoring proper behavior of an autonomous vehicle
US11782823B2 (en) * 2020-07-27 2023-10-10 International Business Machines Corporation Automatically capturing weather data during engineering tests
US20220135030A1 (en) * 2020-10-29 2022-05-05 Magna Electronics Inc. Simulator for evaluating vehicular lane centering system
WO2022106896A1 (en) * 2020-11-19 2022-05-27 Mobileye Vision Technologies Ltd. Vehicle operation safety model compliance measurement
US11904892B2 (en) 2021-03-31 2024-02-20 Gm Cruise Holdings Llc Machine learning algorithm predicton of movements of simulated objects by using a velocity grid created in a simulation
US11897502B2 (en) * 2021-03-31 2024-02-13 Gm Cruise Holdings Llc Object tracking by generating velocity grids
US20220340153A1 (en) * 2021-04-22 2022-10-27 Gm Cruise Holdings Llc Simulated test creation
US11208206B1 (en) * 2021-05-17 2021-12-28 Beta Air, Llc Aircraft for fixed pitch lift
CN113609016B (zh) * 2021-08-05 2024-03-15 北京赛目科技股份有限公司 车辆自动驾驶测试场景的构建方法、装置、设备及介质
DE102021208988A1 (de) 2021-08-17 2023-02-23 Zf Friedrichshafen Ag Trainingsverfahren zum Trainieren eines künstlichen maschinellen Lernsystems zur Erkennung von Fehlfunktionen und Fahrzeugvorrichtung
EP4198482A1 (de) * 2021-12-17 2023-06-21 dSPACE GmbH Erstellen von testdaten mit konsistenten anfangsbedingungen zum stimulieren eines zu testenden steuergeräts
US20230271607A1 (en) * 2022-02-28 2023-08-31 Nissan North America, Inc. Vehicle lane marking detection system
EP4261733A1 (de) * 2022-04-12 2023-10-18 Beijing Tusen Zhitu Technology Co., Ltd. Simulationsverfahren, rechnervorrichtung und speichermedium
US20230350778A1 (en) * 2022-04-29 2023-11-02 Embark Trucks, Inc. Simulation evaluation pipeline
CN114721359B (zh) * 2022-05-23 2022-08-30 交通运输部公路科学研究所 一种预见性巡航控制系统测试平台及测试方法
CN114978361B (zh) * 2022-06-08 2024-01-30 深圳市钛和巴伦技术股份有限公司 一种基于5g的汽车行驶环境模拟系统以及模拟方法
CN115292822B (zh) * 2022-10-08 2023-02-07 江铃汽车股份有限公司 一种防止头部碰撞汽车内部凸出物的测试方法及系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0723039D0 (en) * 2007-11-23 2008-01-02 Itw Ltd System,controller and method for synchronized capture and synchronized playback of data
US11256931B2 (en) * 2010-04-19 2022-02-22 SMR Patent S.à.r.l Rearview device simulation
US20160210775A1 (en) * 2015-01-21 2016-07-21 Ford Global Technologies, Llc Virtual sensor testbed
US9798941B2 (en) * 2015-03-18 2017-10-24 Ford Global Technologies, Llc Driver visual sensor behavior study device
US9494439B1 (en) * 2015-05-13 2016-11-15 Uber Technologies, Inc. Autonomous vehicle operated with guide assistance of human driven vehicles
US10176634B2 (en) * 2015-10-16 2019-01-08 Ford Global Technologies, Llc Lane boundary detection data generation in virtual environment
US20170109458A1 (en) * 2015-10-16 2017-04-20 Ford Global Technologies, Llc Testbed for lane boundary detection in virtual driving environment
US20180300620A1 (en) * 2017-04-12 2018-10-18 Ford Global Technologies, Llc Foliage Detection Training Systems And Methods
US11487988B2 (en) * 2017-08-31 2022-11-01 Ford Global Technologies, Llc Augmenting real sensor recordings with simulated sensor data
US11966838B2 (en) * 2018-06-19 2024-04-23 Nvidia Corporation Behavior-guided path planning in autonomous machine applications
US10885698B2 (en) 2018-08-10 2021-01-05 Nvidia Corporation Method for programmable timeouts of tree traversal mechanisms in hardware
US20200209874A1 (en) * 2018-12-31 2020-07-02 Chongqing Jinkang New Energy Vehicle, Ltd. Combined virtual and real environment for autonomous vehicle planning and control testing
US11150660B1 (en) * 2019-04-23 2021-10-19 Zoox, Inc. Scenario editor and simulator

Also Published As

Publication number Publication date
WO2020223248A1 (en) 2020-11-05
JP2022531092A (ja) 2022-07-06
US20200339109A1 (en) 2020-10-29
US11927502B2 (en) 2024-03-12
CN113767389A (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE112020003043T5 (de) Erkennung und klassifizierung von kreuzungsregionen für autonome maschinenanwendungen
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112019006484T5 (de) Detektion von abständen zu hindernissen in autonomen maschinenanwendungen
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
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
DE112021000422T5 (de) Vorhersage künftiger Trajektorien in Umgebungen mit mehreren Aktoren für autonome Maschinenanwendungen
DE102021126254A1 (de) Überwachen der Aufmerksamkeit und der kognitiven Belastung der Insassen für autonome und halbautonome Fahranwendungen
DE102020117792A1 (de) Wirksames einsetzen von hindernis- und spurerkennungen, um spurzuweisungen für objekte in einer umgebung zu bestimmen
DE112019000279T5 (de) Steuern autonomer fahrzeuge anhand sicherer ankunftszeiten
DE102021100065A1 (de) Verwendung neuronaler netze zur fehlererkennung bei anwendungen für autonomes fahren
DE102021117456A1 (de) Systeme und verfahren zur risikobewertung und gerichteten warnung bei fussgängerüberwegen
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE112020006181T5 (de) Blickbestimmung mit blendung als eingabe
DE102021125234A1 (de) Datenerweiterung einschliesslich hintergrundmodifikation für robuste vorhersage mit neuronalen netzwerken
DE102020100685A1 (de) Vorhersage zeitlicher informationen in autonomenmaschinenanwendungen
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE102022104026A1 (de) Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren

Legal Events

Date Code Title Description
R012 Request for examination validly filed