DE102022114511A1 - Ruhen des Zustands zur Optimierung von Hochfahrprozessen autonomer Fahrzeuge - Google Patents

Ruhen des Zustands zur Optimierung von Hochfahrprozessen autonomer Fahrzeuge Download PDF

Info

Publication number
DE102022114511A1
DE102022114511A1 DE102022114511.5A DE102022114511A DE102022114511A1 DE 102022114511 A1 DE102022114511 A1 DE 102022114511A1 DE 102022114511 A DE102022114511 A DE 102022114511A DE 102022114511 A1 DE102022114511 A1 DE 102022114511A1
Authority
DE
Germany
Prior art keywords
vehicle
state
computer system
power mode
low power
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
DE102022114511.5A
Other languages
English (en)
Inventor
Mitchell Darren Luban
Krishna Sitaraman
Bhavesh Parekh
Michael Truog
Hari Krishnan
Karl Friedrich Greb
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 DE102022114511A1 publication Critical patent/DE102022114511A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4418—Suspend and resume; Hibernate and awake
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0232—Circuits relating to the driving or the functioning of the vehicle for measuring vehicle parameters and indicating critical, abnormal or dangerous conditions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/24—Resetting means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3212—Monitoring battery levels, e.g. power saving mode being initiated when battery voltage goes below a certain level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3215—Monitoring of peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3228—Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3231—Monitoring the presence, absence or movement of users
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/324—Power saving characterised by the action undertaken by lowering clock frequency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3287—Power saving characterised by the action undertaken by switching off individual functional units in the computer system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3296—Power saving characterised by the action undertaken by lowering the supply or operating voltage
    • 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/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • 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/02—Registering or indicating driving, working, idle, or waiting time only

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Power Sources (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)

Abstract

Die Diagnose und das Hochfahren der AV-Hardware und Software eines Computersystems eines autonomen Fahrzeugs kann mindestens basierend auf dem Empfang einer Anzeige des Herunterfahrens oder Ausschaltens durchgeführt werden, woraufhin ein Rechenzustand des Computersystems in den Ruhezustand versetzt werden kann, wobei das Computersystem in einen Niederenergiemodus übergeht. Der in den Ruhezustand versetzte Rechenzustand kann schnell wiederhergestellt werden, ohne dass ein Reboot und eine Diagnose zum Einschalten der Zündung erforderlich sind. Um die Integrität des gespeicherten Rechenzustands zu gewährleisten, kann das Computersystem den Niederenergiemodus verlassen, die Diagnose erneut durchführen, die Programme neu laden und dann wieder in den Niederenergiemodus eintreten. Die Wiederherstellung des in den Ruhezustand versetzten Rechenzustands kann dadurch ausgelöst werden, dass ein Benutzer einen Zündschlüssel einsteckt, einen Knopf drückt, um das Fahrzeug einzuschalten, eine Fahrzeugtür öffnet, das Fahrzeug aus der Ferne entriegelt, das Fahrzeug aus der Ferne startet, usw.

Description

  • Hintergrund
  • Das Konstruieren eines Systems zum autonomen Fahren eines Fahrzeugs ohne Aufsicht auf einem für die praktische Akzeptanz erforderlichen Sicherheitsniveau ist enorm schwierig. Ein autonomes Fahrzeug (AV) sollte mindestens in der Lage sein, das funktionale Äquivalent eines aufmerksamen Fahrers zu sein, der auf ein Wahrnehmungs- und Handlungssystem zurückgreift, das über eine unglaubliche Fähigkeit verfügt, bewegliche und statische Hindernisse in einer komplexen Umgebung zu erkennen und darauf zu reagieren, um eine Kollision mit anderen Objekten oder Strukturen auf seinem Weg zu vermeiden. Um diese Standards zu erfüllen, führen autonome Fahrzeuge immer komplexere Programme aus. Mit dieser Komplexität geht eine erhöhte Boot-Zeit für autonome Fahrsysteme einher, was zum Teil auf die Zunahme der Softwaredaten zurückzuführen ist, die geladen und konfiguriert werden müssen. Gleichzeitig steigt die Anforderung, die Hochfahrzeit ab dem Einschalten der Zündung des Fahrzeugs zu verkürzen (z. B. die Zeit vom Einschalten des Fahrzeugs bis zur Fähigkeit zum sicheren Fahren).
  • Vor dem Ausführen einer Software zum autonomen Fahren kann ein System zum autonomen Fahren eine Anfangsdiagnose durchführen (z. B. Prüfung auf latente Fehler). Dies erfordert in der Regel einen Reboot des Systems, gefolgt von einer Initialisierung der AV-Hardware und AV-Software, bei der die AV-Software aus dem persistenten Speicher in den Direktzugriffsspeicher (RAM) geladen wird und die Diagnose durchgeführt wird. Üblicherweise wird dieser Prozess durch das Einschalten der Zündung des Fahrzeugs oder eine sich öffnende Tür ausgelöst. Aufgrund der Komplexität moderner AV-Systeme kann es zu lange dauern, bis dieser Prozess abgeschlossen ist (z. B. zwanzig Sekunden oder mehr). Eine Möglichkeit, die Hochfahrzeiten zu verkürzen, besteht darin, die Fahrzeugarchitektur zu fragmentieren, z. B. durch Verwendung einer eigenen elektronischen Steuereinheit (ECU) für das Kombi-Instrument (Rückfahrkamera), einer weiteren ECU für die Fahrzeugvernetzung und einer weiteren für ADAS, so dass jede dieser ECUs speziell dafür ausgelegt werden kann, die entsprechenden Funktionen schneller zu laden. Je stärker jedoch die Fahrzeugarchitektur fragmentiert ist, desto mehr Spezialhardware und -software wird benötigt, was die Systemkomplexität erhöht. Da zudem die AV-Software immer komplexer wird, reicht selbst dieser Ansatz möglicherweise nicht aus, um die Anforderungen an die Hochfahrzeit zu erfüllen.
  • Zusammenfassung
  • Ausführungsformen der vorliegenden Offenbarung beziehen sich auf Ruhezustände für den schnellen Start von autonomen Fahrzeugen. Es werden Systeme und Verfahren offengelegt, die die Hochfahrzeit verkürzen, die erforderlich ist, um ein Computersystem (und damit auch ein autonomes Fahrzeug) nach dem Einschalten der Zündung in einen voll funktionsfähigen Zustand zu versetzen.
  • Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, kann die Diagnose und das Booten der AV-Hardware und -Software eines Computersystems eines autonomen Fahrzeugs mindestens basierend auf dem Empfangen einer Anzeige zum Herunterfahren oder Ausschalten durchgeführt werden, woraufhin ein Rechenzustand des Computersystems in den Ruhezustand versetzt werden kann, wobei das Computersystem in einen Niederenergiemodus übergeht. Der ruhende Rechenzustand kann schnell wiederhergestellt werden, wenn das autonome Fahrzeug wieder eingeschaltet wird, ohne dass ein Reboot und eine Diagnose für das Einschalten der Zündung erforderlich sind.
  • Um in den Niederenergiemodus zu gelangen, kann das Computersystem verschiedene Diagnosefunktionen ausführen, Sicherheitsmechanismen ausführen und dann Programme in ein Speichermedium, wie einen Direktzugriffsspeicher (RAM) neu laden. Im Niederenergiemodus können bestimmte Komponenten des Computersystems vollständig versorgt werden, bestimmte Komponenten teilweise versorgt werden und bestimmte Komponenten ausgeschaltet sein. Um die Integrität des gespeicherten Rechenzustands zu gewährleisten, kann das Computersystem den Niederenergiemodus nach einer bestimmten Zeitspanne verlassen. Nach Ablauf des Intervalls kann das Computersystem die Diagnose erneut durchführen, die Programme erneut in den Arbeitsspeicher laden und dann wieder in den Niederenergiemodus wechseln. Wenn der Fahrer in das Fahrzeug zurückkehrt, kann das Computersystem den Niederenergiemodus verlassen (z. B. aufgrund einer Anzeige eines Einschaltereignisses der Zündung). Da die Diagnose vor dem Eintritt in den Niederenergiemodus durchgeführt wurde, ist eine weitere Diagnose möglicherweise nicht erforderlich. Da sich die Programme bereits im Arbeitsspeicher befinden, kann die Zeit bis die Programme zur Ausführung bereit sind, erheblich verkürzt werden. Somit kann das Computersystem eine schnellere Hochfahrzeit aufweisen, selbst wenn eine allgemeinere Systemarchitektur verwendet wird (z. B. eine einzelne ECU), was ein einfacheres und kostengünstigeres System ermöglicht.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren für Ruhezustände für Computersysteme in einem autonomen Fahrzeug werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungsfiguren detailliert beschrieben, wobei:
    • 1 ist ein Flussdiagramm, das ein Verfahren zum Eintritt in den Ruhezustand und zum Verlassen des Ruhezustands gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 2 ist ein Systemdiagramm, das die Komponenten eines Computersystems eines autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 3A ist ein Flussdiagramm, das die Verarbeitung einer Aufforderung zum Eintritt in einen Ruhezustand darstellt, wie sie von einem Verarbeitungssystem und einem Controller gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird;
    • 3B ist ein Flussdiagramm, das den Eintritt in den Ruhezustand darstellt, wie er vom Verarbeitungssystem und von dem Controller gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird;
    • 4A ist ein Flussdiagramm, das das Verlassen des Ruhezustands zur Wiederaufnahme der autonomen Steuerung darstellt, wie es vom Verarbeitungssystem und von dem Controller gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird;
    • 4B ist ein Flussdiagramm, das das Verlassen des Ruhezustands in einen ausgeschalteten Zustand darstellt, wie es von dem Verarbeitungssystem und von dem Controller gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird;
    • 5 ist ein Flussdiagramm, das ein Verfahren zum Eintreten in einen Niederenergiemodus und zum Verlassen eines solchen Modus darstellt, um die autonome Steuerung wieder aufzunehmen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 6 ist ein Flussdiagramm, das ein Verfahren zum Steuern eines Verarbeitungssystems, in einen Niederenergiemodus einzutreten und diesen zu verlassen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 7 ist ein Flussdiagramm, das ein Verfahren zum Anweisen des Eintretens und Verlassens eines Niederenergiemodus gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 8A ist eine Darstellung eines beispielhaften autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8D ist ein Systemdiagramm für die Kommunikation zwischen einem oder mehreren Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 9 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
    • 10 ist ein Blockdiagramm eines beispielhaften Datenzentrums, das zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.
  • Detaillierte Beschreibung
  • Es werden Systeme und Verfahren in Bezug auf Ruhezustände für das schnelle Hochfahren autonomer Fahrzeuge offengelegt. Obwohl die vorliegende Offenbarung in Bezug auf ein beispielhaftes autonomes Fahrzeug 800 (hier alternativ als „Fahrzeug 800“ oder „Ego-Fahrzeug 800“ bezeichnet, von dem ein Beispiel in Bezug auf die 8A-8D beschrieben wird), ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hier beschriebenen Systeme und Verfahren ohne Einschränkung von nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z. B. in einem oder mehreren adaptiven Fahrerassistenzsystemen (ADAS)), pilotierten und nicht pilotierten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, Fahrzeugen, die mit einem oder mehreren Anhängern gekoppelt sind, Flugschiffen, Booten, Shuttles, Notarzteinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Auch wenn die vorliegende Offenbarung in Bezug auf das Booten und Versetzen in den Ruhezustand von Computersystemen für autonome Fahrzeuge beschrieben wird, ist dies nicht als Einschränkung zu verstehen, und die hier beschriebenen Systeme und Verfahren können in erweiterter Realität, virtueller Realität, gemischter Realität, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenanwendungen und/oder in jedem anderen Technologiebereich eingesetzt werden, in dem das Booten und Versetzen in den Ruhezustand von Computern verwendet werden kann.
  • In einer oder mehreren Ausführungsformen kann ein Computersystem bei einer Anzeige (z. B. vom Fahrer und/oder der Systemkomponente) eines Ausschaltens der Zündung (z. B. einem Herunterfahren oder Ausschalten) des Fahrzeugs in einen Stromsparmodus übergehen. Beispielsweise kann der Benutzer einen Zündschlüssel abziehen, einen physischen oder virtuellen Knopf drücken, um das Fahrzeug auszuschalten, das Fahrzeug verlassen usw. In einer oder mehreren Ausführungsformen kann das Computersystem einen Fahrzyklus beenden, in dem das Fahrzeug mindestens teilweise autonom betrieben wurde. Dazu kann das Abschalten verschiedener Sensoren und Anzeigen gehören. In einer oder mehreren Ausführungsformen führt das Computersystem eine Diagnose der Hardware durch. Bei jeder mit Strom versorgten Komponente besteht die Möglichkeit, dass sich Bits vertauschen oder andere Fehler während des Betriebs ansammeln. Diese Fehler können z. B. mindestens teilweise durch Strahlung (z. B. Sonnenstrahlung, Alphateilchen usw.) verursacht werden. Bei der Diagnose kann geprüft werden, ob sich während des Betriebs der verschiedenen Komponenten Fehler ansammeln. Diese Diagnosen können Prüfungen auf latente Fehler beinhalten.
  • In einer oder mehreren Ausführungsformen wird das Computersystem mindestens teilweise vor dem Durchführen der Diagnose sich in einen Fahrzyklus neuinitialisieren oder rebooten. In einer oder mehreren Ausführungsformen wird das Computersystem nach der Diagnose und/oder dem Reboot Komponenten in den Ruhezustand versetzen und den aktuellen Zustand im RAM speichern. Prüfungen auf latente Fehler, die mindestens als Teil der Diagnose durchgeführt werden können, können den aktuellen Zustand des Prozessors zerstören, beeinträchtigen oder anderweitig beeinflussen. Die Sicherheit des Systems kann dadurch gewährleistet werden, dass nach Abschluss der Prüfungen auf latente Fehler und vor dem Versetzen in den Ruhezustand in den RAM ein vollständiger Reboot des Systems durchgeführt wird. Das Computersystem kann dann in einen Stromsparmodus übergehen. Der Stromsparmodus kann sich auf verschiedene Modi beziehen, die den Stromverbrauch des Computersystems reduzieren, wie hierin beschrieben. Andere Komponenten können deaktiviert oder in einen Standby-Zustand versetzt werden. In einer oder mehreren Ausführungsformen kann das System das Ausführen der Diagnose fortsetzen, während es den Eintritt in den Niederenergiemodus durchführt, und Sicherheitsmechanismen nur an dem Punkt deaktivieren, an dem die Logik, die den Mechanismus beherbergt, deaktiviert wird.
  • Das Computersystem kann im Niederenergiemodus verbleiben, bis es getriggert wird, den Niederenergiemodus zu verlassen. Drei Beispiele für Trigger werden kurz erläutert, um ein Beispiel zu geben und nicht einzuschränken. Erstens kann das Computersystem erkennen oder feststellen, dass der Bediener in das Fahrzeug zurückgekehrt ist, was das Computersystem veranlasst, den Niederenergiemodus zu verlassen und in den normalen Betriebsmodus zu wechseln. Der normale Betriebsmodus kann die autonome Steuerung und andere Funktionen umfassen, die bei voller Leistung ausgeführt werden. Zweitens kann eine bestimmte Zeitspanne vergehen, in der das Computersystem die Diagnose erneut durchführt, die Programme neu lädt und wieder in den Niederenergiemodus wechselt. Drittens kann das Computersystem bei einem bestimmten Schwellenwert für den Batteriestand (oder einem anderen Schwellenwert) den Niederenergiemodus verlassen und sich vollständig abschalten oder ausschalten (um eine weitere Entladung der Batterie zu verhindern). Obwohl hier eine Batterie beschrieben wird, kann die Beschreibung einer Batterie auch auf ein oder mehrere Energiespeichermedien (z. B. einen Kondensator usw.) zutreffen.
  • Im Niederenergiemodus können die stromhungrigsten Komponenten abgeschaltet werden. Beispiele für abgeschaltete Komponenten können eine Zentraleinheit (CPU) und eine Grafikverarbeitungseinheit (GPU) sein. Die CPU und/oder der Grafikprozessor können zum Teil für autonome Fahrfunktionen verwendet werden, z. B. für Computervision mit neuronalen Netzen. Im Niederenergiemodus können bestimmte Komponenten vollständig mit Strom versorgt werden (z. B. eine Fahrzeugbatterie, Stromvorregulierungsschaltungen, Stromsequenzer, Spannungsregler für ein ständig eingeschaltetes Segment des Prozessors, Spannungsregler für DRAM usw.). Die Fahrzeugbatterie kann das Computersystem über einen Schalter oder direkt über die Fahrzeugbatterie mit Strom versorgen. Im Niederenergiemodus können bestimmte Komponenten teilweise mit Strom versorgt werden (Beispiele umfassen integrierte Schaltungen zur Energiemanagement, ein immer eingeschaltetes Segment des Prozessors/der Prozessoren, Flex Rays, Ethernet usw.). Einige dieser Komponenten können direkt von der Batterie mit Strom versorgt werden und so konfiguriert sein, dass sie bei Bedarf Wecksignale an die anderen Komponenten senden, um den Niederenergiemodus zu beenden. Auch im Niederenergiemodus können bestimmte Komponenten vollständig abgeschaltet werden (z. B. Grafikverarbeitungseinheiten, Mikrocontroller-Einheiten, Fahrzeugkabelbäume, Peripheriegeräte, Sensoren und Anzeigen). Ein Mikrocontroller und/oder anderer Controller können zur Sicherheit, zur Kontrolle anderer Aspekte des Systems und zur Leistungssteuerung eingesetzt werden.
  • Wie hierin beschrieben, kann das Computersystem für eine bestimmte Zeitspanne im Niederenergiemodus bleiben. Das Zeitintervall kann beispielsweise acht Stunden oder vierundzwanzig Stunden betragen. Das Zeitintervall kann eine statische Zahl sein, eine statische Zahl, die programmierbar ist (z. B. durch den Fahrzeughersteller oder den Endkunden), oder es kann dynamisch sein. Nach Ablauf des Intervalls kann das Computersystem kurz aus dem Niederenergiemodus heraustreten, die Diagnose erneut durchführen, die Programme neu initialisieren, neu starten und erneut in den Niederenergiemodus eintreten. Dieser Zyklus kann so lange fortgesetzt werden, bis ein Beendigungsereignis festgestellt wird, wie z. B., dass eine Anzeige des Einschaltens der Zündung empfangen wird oder die Batterie unter einen bestimmten Wert fällt.
  • In einer oder mehreren Ausführungsformen kann der Eintritt in den Niederenergiemodus durch das Ausschalten der Zündung (oder eine andere Anzeige für das Ende des Fahrzyklus) erfolgen. Der Eintritt in den Niederenergiemodus kann jedoch so konfiguriert werden, dass er bei Erfüllung einer Vielzahl möglicher Kriterien oder Bedingungen erfolgt. Dem Benutzer kann auch die Möglichkeit geboten werden, vollständig abzuschalten, falls dies gewünscht wird.
  • Das Computersystem kann den Niederenergiemodus verlassen, um den normalen autonomen Fahrbetrieb zu ermöglichen. Das Verlassen des Niederenergiemodus kann durch eine Anzeige ausgelöst werden, dass die Rückkehr zum normalen Fahrbetrieb beginnt oder unmittelbar bevorsteht. Zum Beispiel kann der Benutzer einen Zündschlüssel einstecken, einen Knopf drücken, um das Fahrzeug einzuschalten, eine Fahrzeugtür zu öffnen, das Fahrzeug aus der Ferne zu entriegeln, das Fahrzeug aus der Ferne zu starten usw.
  • Um den Niederenergiemodus zu verlassen, kann ein Aufwecksignal an die Mikrocontroller-Einheit (und/oder ein anderer Controller) gesendet werden. Die Mikrocontroller-Einheit kann das Computersystem mindestens basierend auf dem Wecksignal veranlassen, den Niederenergiemodus zu verlassen. Nachdem es getriggert worden ist, kann das Computersystem den Niederenergiemodus verlassen. Das Verlassen des Niederenergiemodus kann (z. B. und ohne Einschränkung) Aufgaben oder Operationen wie das Einschalten von Uhren, Sensoren und Anzeigen umfassen. Das Verlassen des Niederenergiemodus kann auch (z. B. und ohne Einschränkung) Aufgaben oder Operationen umfassen wie: Authentifizierung, Wiederherstellung eines gesicherten Zustands und anderweitige Vorbereitung des Computersystems für den normalen Betrieb. Da der Rechenzustand im RAM (und/oder einem anderen Speichermedium) gespeichert wurde, kann das Computersystem viel schneller in den Normalbetrieb übergehen (z. B. wenn das autonome Fahrzeug für die autonome Steuerung bereit ist) als herkömmliche Verfahren und Lösungen. So können sich beispielsweise alle Anwendungszustände und Sensorzustände bereits im RAM befinden.
  • In einigen Fällen kann das Computersystem von einem Stromsparmodus in einen Ausschaltmodus oder -zustand übergehen. Das Computersystem kann in den Ausschaltmodus übergehen, wenn mindestens ein oder mehrere Kriterien erfüllt sind. Beispielsweise kann das Computersystem in den Ausschaltmodus übergehen, wenn der Batteriepegel unter einem bestimmten Schwellenwert liegt. Als weiteres Beispiel kann das Computersystem basierend auf einer Zeitüberschreitung einer Gesamtzeit im Stromsparmodus in den Ausschaltmodus übergehen. In diesen Fällen kann die Mikrocontroller-Einheit durch eine Mikrocontroller-Energiemanagementschaltung aufgeweckt werden. Der Mikrocontroller kann die Zeitüberschreitung bestätigen und dann verschiedene Komponenten im Niederenergiemodus anweisen, vollständig herunterzufahren oder sich auszuschalten. Der Mikrocontroller kann auch seine Energiemanagementschaltung in einen Standby-Modus versetzen und sich dann selbst ausschalten. Einige Komponenten, z. B. die Energiemanagementschaltung, können im Ausschaltzustand eingeschaltet bleiben, um eine Wiederbelebung zu ermöglichen. Das Computersystem kann im Ausschaltmodus verbleiben, bis ein Einschalten der Zündung oder ein anderes Signal empfangen wird (z. B. wenn die Batterie ausreichend geladen ist, das Fahrzeug an die Steckdose angeschlossen wurde usw.).
  • Unter Bezugnahme auf 1 ist 1 ein Flussdiagramm, das ein Verfahren 100 für das Eintreten in und das Verlassen von Ruhezuständen gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Jeder Block des Verfahrens 100 (und anderer hierin beschriebener Verfahren) umfasst einen Rechenprozess, der unter Verwendung einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 100 kann auch in Form von computerverwendbaren Anweisungen ausgeführt werden, die auf Computerspeichermedien gespeichert sind. Das Verfahren 100 kann als eigenständige Anwendung, als Dienst oder gehosteter Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder als Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Beispiele zu nennen. Außerdem wird das Verfahren 100 beispielhaft mit Bezug auf das Computersystem 200 der 2 beschrieben. Das Verfahren 100 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hierin beschriebenen.
  • Das Verfahren 100 kann zum Booten, Versetzen in den Ruhezustand von Zuständen und Laden von Zuständen eines Computersystems 200 (z. B. eine ECU) der 2 verwendet werden, um die autonome Steuerung eines autonomen Fahrzeugs (z. B. des Fahrzeugs 800) zu ermöglichen. Das Verfahren 100 kann jedoch auch für andere Arten von Computersystemen verwendet werden oder um andere Arten von Funktionalitäten unter Verwendung des Computersystems zu ermöglichen. In Ausführungsformen der Offenbarung kann das Verfahren 100 beim Ausschalten der Zündung des autonomen Fahrzeugs ausgeführt werden. Das Verfahren 100 kann auch konfigurierbar sein, bei bestimmten Kriterien oder Bedingungen zusätzlich zum oder anstelle des Ausschaltens der Zündung ausgeführt zu werden. Ferner kann ein Benutzer die Möglichkeit haben, das Computersystem 200 des Fahrzeugs vollständig abzuschalten, falls gewünscht, anstatt das Verfahren 100 auszuführen und das Computersystem 200 in den Niederenergiemodus zu versetzen. Wenn der Benutzer beispielsweise weiß, dass das autonome Fahrzeug für längere Zeit nicht benutzt wird, kann er das Fahrzeug vollständig abschalten, anstatt das autonome Fahrzeug in das Verfahren 100 eintreten zu lassen, das standardmäßig durchgeführt werden kann.
  • Das Verfahren 100 umfasst in Block B102 einen Empfang oder eine Erkennung einer Ausschaltanzeige. Das Computersystem kann den Eintritt in einen Niederenergiemodus basierend zumindest auf der Anzeige des Herunterfahrens oder Ausschaltens beginnen, wie etwa einer Anzeige von dem Fahrer (und/oder einer Systemkomponente), dass das Fahrzeug den Betrieb eingestellt hat oder den Betrieb einstellen soll (und /oder dass die autonome Steuerung deaktiviert werden soll). Der Benutzer kann zum Beispiel den Zündschlüssel abziehen, einen Knopf zum Ausschalten des Fahrzeugs drücken, das Fahrzeug verlassen usw. Basierend auf der Anzeige des Herunterfahrens oder Ausschaltens kann das Computersystem einen Fahrzyklus beenden, in dem das Fahrzeug autonom betrieben wurde. Dazu kann auch das Abschalten verschiedener Sensoren und Anzeigen des Fahrzeugs gehören.
  • Das Verfahren 100 umfasst in Block B104, dass Diagnosen auf dem Computersystem, wie einer ECU ausgeführt werden. Das Computersystem kann eine Vielzahl von Diagnosen an der Hardware ausführen. In einer oder mehreren Ausführungsformen kann die Diagnose mittels In-System-Testing (IST) durchgeführt werden. Während des normalen Computerbetriebs können Bits im Computersystem kippen oder andere Fehler oder Störungen auftreten. Diese Fehler und Störungen können auf Strahlung (Sonnenstrahlung, Alphateilchen usw.) oder andere externe Quellen zurückzuführen sein oder auf andere Weise während der Stromversorgung verursacht werden. Die durchgeführte Diagnose kann eine Prüfung auf latente Fehler beinhalten, um solche Fehler zu ermitteln und zu korrigieren. Obwohl in 1 nicht dargestellt, kann das Computersystem in einer oder mehreren Ausführungsformen vor der Diagnose mindestens teilweise rebooten (z. B. basierend auf der Anzeige des Herunterfahrens oder Ausschaltens im Block B102 und/oder basierend darauf, dass ein Stromsparmodus im Block B124 verlassen wird).
  • Das Verfahren 100 umfasst in Block B106 einen Reboot des Computersystems. Das Computersystem kann nach der Diagnose mindestens teilweise wieder in einen Fahrzyklus zurückfahren. Das Computersystem kann den Reboot mindestens teilweise durchführen, weil die Prüfungen auf latente Fehler einen aktuellen Zustand des Prozessors zerstört haben. Der Reboot kann einen neuen Computerzustand erzeugen, der eine aktuell geladene Instanz eines oder mehrerer Programme enthält, die für die autonome Steuerung und/oder andere Funktionen des autonomen Fahrzeugs verwendet werden.
  • Das Verfahren 100 umfasst im Block B108, dass der Rechenzustand gespeichert wird. Beispielsweise kann der Rechenzustand in einem oder mehreren Computerspeichermedien gespeichert werden, die mindestens einen flüchtigen Speicher, wie z. B. einen Direktzugriffsspeicher (RAM), enthalten können. Das Speichern des Rechenzustands vor dem Eintreten in den Niederenergiemodus kann es ermöglichen, den Rechenstatus beim Verlassen des Niederenergiemodus schnell abzurufen, ohne einen vollständigen Reboot durchführen zu müssen.
  • Das Verfahren 100 umfasst in Block B 110, dass in einen Stromsparzustand eingetreten wird. Um in den Stromsparzustand zu gelangen, kann das Computersystem eine oder mehrere hierin beschriebene Komponenten in den Ruhezustand versetzen. Andere Komponenten können deaktiviert oder in einen Standby-Zustand versetzt werden. Beispiele für solche Komponenten werden unter Bezugnahme auf 2 näher erläutert. In einigen Ausführungsformen ist der Stromsparmodus System Control 7 (SC7), wobei sich eine System Control auf einen Systemleistungszustand beziehen kann. Andere System Controls können die System Control 0 umfassen, bei der das Computersystem mit voller Leistung betrieben wird, oder die System Control 8, bei der das System vollständig ausgeschaltet ist (z. B. mit Ausnahme der Weckschaltung). Es können auch andere Stufen und Konfigurationen von Energiesparmodi verwendet werden.
  • In einer oder mehreren Ausführungsformen können nach dem Eintritt in den Niederenergiemodus im Block B110 verschiedene andere Funktionen ausgeführt werden, abhängig davon, dass verschiedene Kriterien erfüllt sind. Zum Beispiel können die Blöcke B112-B116, B118-B120, B122-B124 oder B126-128 auftreten. Was die Blöcke B112-B116 betrifft, so beinhaltet das Verfahren 100 im Block B112 eine Einschalt- oder Hochfahranzeige. Die Einschalt- oder Hochfahranzeige kann ein Verlassen des Niederenergiemodus auslösen und kann beispielhaft und ohne Einschränkung eine Anzeige umfassen, dass eine Rückkehr zum normalen Fahrbetrieb beginnt, unmittelbar bevorsteht oder anderweitig gewünscht ist. Die Einschalt- oder Hochfahranzeige kann von einer Komponente außerhalb des Computersystems (z. B. ECU) im autonomen Fahrzeug, von einem kommunikativ mit dem Computersystem gekoppelten Sensor und/oder von einem anderen elektronischen Gerät (z. B. einem Schlüsselanhänger) empfangen werden. In einer oder mehreren Ausführungsformen kann der Benutzer die Einschalt- oder Hochfahranzeige auslösen, indem er auf irgendeine Weise mit dem autonomen Fahrzeug interagiert. Zum Beispiel kann der Benutzer einen Zündschlüssel einstecken, einen Knopf drücken, um das Fahrzeug einzuschalten, eine Tür zum Fahrzeug öffnen, das Fahrzeug aus der Ferne entriegeln, das Fahrzeug aus der Ferne starten, sich dem Fahrzeug mit einem registrierten, drahtlos kommunizierenden Gerät nähern usw.
  • Das Verfahren 100 umfasst in Block B114 das Verlassen des Niederenergiemodus. Beispielsweise kann ein Controller ein Verarbeitungssystem und andere Komponenten des Computersystems triggern, den Niederenergiemodus zu verlassen. Dies kann beinhalten, dass der Controller einen Energiemanager anweist, verschiedene Komponenten mit Energie zu versorgen, wie hierin beschrieben. Der Controller und/oder das Verarbeitungssystem können auch Uhren, Sensoren und Anzeigen einschalten. Dies kann die Authentifizierung, das Booten und/oder die anderweitige Vorbereitung des Computersystems für den normalen Betrieb beinhalten. Da der vorherige Rechenzustand im Speicher gespeichert wurde (z. B. gemäß Block B108), kann das Computersystem in die Laufzeit übergehen, ohne alle AV-Software- und Hardwarekonfigurationen zu laden und zu initialisieren. So können beispielsweise alle Anwendungszustände und Sensorzustände bereits in den im Speicher abgelegten Rechenzustand geladen werden.
  • Das Verfahren 100 umfasst in Block B116 die Aktivierung der autonomen Steuerung. Beispielsweise kann das Computersystem, nachdem der Rechenzustand aus dem Speicher wiederbelebt wurde, die autonome Steuerung des Fahrzeugs übernehmen. Das Computersystem kann in der autonomen Steuerung des Fahrzeugs verbleiben, bis eine Anzeige des Herunterfahrens oder Ausschalten empfangen wird oder ein anderes Ereignis eintritt. Beispielsweise kann das Verfahren 100 in einer Schleife zum Block B102 zurückkehren und einen weiteren Zyklus fortsetzen.
  • Hinsichtlich der Blöcke B118-B120 weist das Verfahren 100 im Block B1 18 auf, dass eine Quelle mit niedriger Leistung auftritt. Ein niedriger Batteriestand kann beispielsweise durch das Computersystem, eine Komponente außerhalb des Computersystems oder durch eine andere Vorrichtung festgestellt werden. In einer oder mehreren Ausführungsformen kann die Quelle mit niedriger Leistung mindestens basierend darauf bestimmt werden, dass ein Leistungspegel unter einem Schwellenwert liegt.
  • Das Verfahren 100 umfasst im Block B120, dass das Computersystem vollständig abgeschaltet wird. Durch das vollständige Abschalten wird der Stromverbrauch der Stromquelle gestoppt oder stark reduziert.
  • Die Fortsetzung des Betriebs im Niederenergiemodus, wenn die Stromquelle unter einen bestimmten Schwellenwert fällt, kann nachteilig sein, weil die niedrige Stromquelle das autonome Fahrzeug daran hindern kann, zu starten oder über einen ausreichend langen Zeitraum zu fahren. Beispielsweise kann im Fall eines verbrennungsmotorbetriebenen Fahrzeugs eine schwache Batterie den Anlasser daran hindern, den Motor erfolgreich zu starten. Ebenso kann eine schwache Batterie bei einem elektrisch betriebenen Fahrzeug die Reichweite des Elektrofahrzeugs verringern. Die Blöcke B 122-B 124 können verwendet werden, um solche Situationen zu verbessern. In Bezug auf die Blöcke B122-B124 umfasst das Verfahren 100 bei Block B122, dass ein bestimmtes Zeitintervall vergangen ist (und/oder eine andere Bedingung erfüllt ist). Das Zeitintervall kann anzeigen, dass die Diagnose erneut durchgeführt werden sollte, um im Niederenergiemodus zu bleiben.
  • Das Computersystem kann für ein bestimmtes Zeitintervall im Stromsparzustand bleiben. Das Zeitintervall kann beispielsweise acht Stunden oder vierundzwanzig Stunden betragen. Das Zeitintervall kann eine im Voraus festgelegte Zahl sein, eine statische Zahl, die programmierbar ist (z. B. durch den Fahrzeughersteller oder den Endkunden), oder es kann dynamisch sein. Nach dem Intervall kann das Computersystem kurz aus dem Stromsparzustand herauskommen, die Diagnose erneut durchführen, die Programme neu initialisieren und wieder in den Stromsparmodus eintreten (z. B. gemäß den Blöcken B104-B110). In einer oder mehreren Ausführungsformen kann das Computersystem auch vor dem Block B104 rebooten.
  • Somit umfasst das Verfahren 100 in Block B124 das Verlassen des Niederenergiemodus, woraufhin das Verfahren 100 zu Block B104 zurückkehren kann (z. B. nach einem Reboot), so dass die Diagnose erneut durchgeführt werden kann. Das Computersystem kann dann neu starten, den Rechenzustand speichern und dann wieder in den Niederenergiemodus eintreten (z. B. in Block B 110). Das Computersystem kann diesen Zyklus beispielsweise so lange wiederholen, wie die Stromquelle (z. B. die Batterie) über ausreichend Strom verfügt und kein Einschalt- oder Startsignal empfangen wurde. Wird die Stromquelle extern aufgeladen, kann das Computersystem diesen Zyklus so lange wiederholen, bis ein Einschalt- oder Startsignal empfangen wird (z. B. wie in Block B112 beschrieben).
  • Das Verfahren 100 kann in Block B126 beinhalten, dass ein oder mehrere Fehler erkannt werden, während sich das Computersystem im Stromsparmodus befindet. Beispielsweise kann ein Controller eine Diagnose durchführen, während sich das Verarbeitungssystem und andere Komponenten des Computersystems im Niederenergiemodus befinden. Dies kann beinhalten, dass der Controller den Prozessor, den Energiemanager oder eine andere Komponente anweist, in regelmäßigen Abständen oder bei einem bestimmten Auslöser auf einen oder mehrere Fehler zu prüfen. Die Diagnose kann dieselbe sein wie die in Block B104 durchgeführte Diagnose oder sich von ihr unterscheiden.
  • Das Verfahren 100 kann in Block B128 beinhalten, dass der Fehler nach seiner Erkennung in Block B126 protokolliert wird. Die Protokollierung des Fehlers kann eine Aufzeichnung erstellen oder aktualisieren, die angibt, welche Komponente und welche Art von Fehler erkannt wurde, und kann verschiedene Sensormesswerte und ähnliches enthalten, die mit dem Fehler verbunden sind. In einigen Ausführungsformen der vorliegenden Offenbarung kann die Steuerung nach der Erkennung und/oder Protokollierung des Fehlers eine vollständige Abschaltung anordnen. Diese vollständige Abschaltung kann einen oder mehrere Schritte umfassen, die hier in Block B120 beschrieben sind. In anderen Ausführungsformen der vorliegenden Offenbarung kann das Computersystem, nachdem der Fehler erkannt und/oder protokolliert wurde, für die Dauer des Zeitintervalls, das verstreicht (wie in Block B122 beschrieben) und/oder ein Einschalt- oder Startsignal empfangen wird (wie in Block B112 beschrieben), im Niederenergiemodus bleiben. In diesen Ausführungsformen kann der protokollierte Fehler weiter ausgewertet und getestet werden, wenn das Computersystem in den Modus mit voller Leistung zurückkehrt (wie in den Blöcken B 114 und/oder B 124 beschrieben). Wenn der Fehler nach der Rückkehr in den Modus mit voller Leistung verifiziert wird, kann der Controller das Computersystem anweisen, sich vollständig abzuschalten (wie in Block B120 beschrieben).
  • Mit Bezug auf 2 ist 2 ein Beispiel für ein Computersystem 200 für das autonome Fahrzeug 800 oder eine andere Maschine. Das Computersystem 200 kann ein oder mehrere Verarbeitungssysteme 202 aufweisen. Das eine oder die mehreren Verarbeitungssysteme 202 können autonome Steuerungssoftware für ein autonomes Fahrzeug laden und ausführen und/oder andere Funktionen ausführen. Das Computersystem 200 kann auch einen oder mehrere Controller 204 aufweisen. Der/die Controller kann/können eine Mikrocontrollereinheit (MCU) oder einen anderen Controller umfassen. Der/die Controller 204 kann (können) aus Sicherheitsgründen dazu verwendet werden, die anderen Komponenten des Computersystems 200 zu kontrollieren, zu instruieren und zu überwachen. Der/die Controller 204 kann (können) auch die Stromversorgung der anderen Komponenten des Computersystems 200 steuern. Das Computersystem 200 kann auch über einen Computerspeicher 206 (z. B. einen flüchtigen Speicher) verfügen. Der Computerspeicher 206 kann ein oder mehrere Computerspeichermedien, wie RAM, umfassen und kann in einer oder mehreren Ausführungsformen einen dynamischen Direktzugriffsspeicher (DRAM) enthalten. Das Computersystem 200 kann auch über einen (nicht dargestellten) nichtflüchtigen Speicher zum Speichern der verschiedenen Programme und Konfigurationen für das Verarbeitungssystem 202 verfügen oder darauf zugreifen können. Dieser Speicher kann verwendet werden, um die Programme und Konfigurationen während des Reboots des Computersystems 200 zu laden, wie hierin beschrieben.
  • Das Computersystem 200 kann außerdem über eine Stromquelle 208 verfügen oder anderweitig mit dieser verbunden sein. Beispiele für die Stromquelle 208 sind eine Fahrzeugbatterie, wie z. B. eine Batterie, die ein elektrisch angetriebenes Fahrzeug mit Strom versorgt, eine Batterie, die ein verbrennungsgetriebenes Fahrzeug mit elektrischen Funktionen versorgt, eine spezielle Batterie für die elektronische Steuereinheit und/oder eine andere Batterie. Das Computersystem 200 kann zusätzlich über einen Schnittstellenmanager 210 verfügen. Der Schnittstellenmanager kann eine oder mehrere Kommunikationsschnittstellen verwalten, z. B. die eines Controller Area Network (CAN), eines Ethernet-Netzwerks, eines FlexRay-Netzwerks und/oder anderer Netzwerk- oder Schnittstellentypen. In einer oder mehreren Ausführungsformen kann der Schnittstellenmanager 210 einen CAN-Controller, eine physikalische Ethernet-Schicht (wie einen Chip oder Software, die Ethernet-Frames sendet und empfängt), einen FlexRay-Kommunikationsbus und/oder andere Komponenten umfassen. Das Computersystem 200 kann auch einen Energiemanager 212 aufweisen. Der Energiemanager kann beispielsweise eine integrierte Schaltung für die Energiemanagement (PMIC) umfassen. Der Energiemanager 212 kann mit einem Fahrzeugkabelbaum 214 sowie mit dem Controller 204 gekoppelt sein.
  • Das Computersystem 200 kann außerdem einen oder mehrere Vorregler 216 aufweisen. Der/die Vorregler 216 kann/können so konfiguriert sein, dass er/sie die in der Ausgangsleistung der Stromquelle 208 vorhandene Welligkeit reduziert/reduzieren. Der/die Vorregler 216 kann/können zusätzlich oder alternativ die Verlustleistung am Spannungsregler 220 reduzieren oder minimieren. Der/die Vorregler 216 kann/können mit der Peripheriestromversorgung 218 verbunden werden. Die Peripheriestromversorgung 218 kann verschiedene periphere Komponenten (z. B. die hier beschriebenen Sensoren) direkt oder indirekt mit Strom versorgen.
  • Der Spannungsregler 220 kann die verschiedenen anderen Komponenten des Computersystems 200 mit Strom versorgen, einschließlich eines Aufwachmoduls 222 auf dem Verarbeitungssystem 202. Das Aufwachmodul 222 kann ein immer eingeschaltetes Segment des Verarbeitungssystems 202 und/oder ein Segment umfassen, das eingeschaltet werden kann, während sich das Verarbeitungssystem 202 in einem Stromsparmodus befindet. Der Spannungsregler 220 kann das Aufwachmodul 222 über eine Aufwachmodul-Stromversorgung 224 mit Strom versorgen, die einen Spannungsregler für das immer eingeschaltete Segment des Verarbeitungssystems 202 umfassen kann. Der Spannungsregler 220 kann auch den Computerspeicher 206 über eine Speicherstromversorgung 226 mit Strom versorgen. Der Spannungsregler kann das Verarbeitungssystem 202 auch über eine Hauptstromversorgung 228 des Verarbeitungssystems 202 mit Strom versorgen (z. B. wenn sich das Verarbeitungssystem 202 nicht in einem Stromsparmodus und/oder im Normalbetrieb befindet).
  • Wie hierin beschrieben, können bestimmte Komponenten im Niederenergiemodus mit voller Leistung, mit teilweiser Leistung oder ohne Leistung betrieben werden. In verschiedenen Ausführungsformen können die Komponenten je nach ihrer Funktionalität und dem Bedarf während des Niederenergiemodus und beim Verlassen des Niederenergiemodus für die volle, teilweise oder gar keine Stromversorgung ausgewählt werden. Um in den Niederenergiemodus zu gelangen, können die Komponenten des Computersystems 200, die am meisten Energie verbrauchen, ausgeschaltet werden. Dazu können eine Zentraleinheit (CPU) und/oder ein Grafikprozessor (GPU) gehören, die Komponenten des Verarbeitungssystems 202 sein können oder anderweitig mit diesem verbunden sind. Zum Beispiel kann das Verarbeitungssystem 202 einer oder mehrere der SoCs 804 der 8C sein oder diese umfassen. Ferner können der oder die Prozessoren 810, die CPU(s) 806, der/die Beschleuniger 814 und/oder der/die GPU(s) 808 für den Niederenergiemodus ausgeschaltet werden. In Ausführungsformen, in denen das Verarbeitungssystem 202 die Logikeinheit(en) 920 der 9 umfasst, können diese ebenfalls für den Niederenergiemodus abgeschaltet werden.
  • Während sie sich im Niederenergiemodus oder -zustand befinden, können bestimmte Komponenten vollständig mit Strom versorgt werden (z. B. die Stromquelle 208, der Vorregler 216, das Aufwachmodul 222, die Aufwachmodul-Stromversorgung 224, die Speicherstromversorgung 226 usw.), wie in 2 dargestellt. Die Fahrzeugbatterie oder eine andere Stromquelle 208 versorgt das elektronische Steuereinheit mit Strom und kann von einem Schalter oder direkt vom Fahrzeug stammen. Im stromsparenden Zustand können bestimmte Komponenten teilweise mit Strom versorgt werden (z. B. der Energiemanager 212, der Schnittstellenmanager 210, der Computerspeicher 206, das Verarbeitungssystem 202 usw.). Einige der teilweise mit Strom versorgten Komponenten können von der Stromquelle 208 mit Strom versorgt werden und können so konfiguriert sein, dass sie Aufwecksignale an die anderen Komponenten liefern. Beispielsweise kann der Energiemanager 212 so konfiguriert sein, dass er ein oder mehrere Wecksignale an das Weckmodul 222 sendet, um das Verarbeitungssystem 202 aus dem Niederenergiemodus aufzuwecken. Im Niederenergiemodus können bestimmte Komponenten vollständig abgeschaltet werden (z. B. die hier beschriebenen stromhungrigsten Komponenten des Verarbeitungssystems 202, der/die Controller 204, der Fahrzeugkabelbaum 214 und Peripheriegeräte, Sensoren und/oder Anzeigen, die über die Peripheriestromversorgung 218 versorgt werden können). Verschiedene Sicherheitsmechanismen können während des Niederenergiemodus teilweise oder vollständig mit Strom versorgt werden. Beispiele für diese Sicherheitsmechanismen können sich auf die Überwachung und Steuerung von Strom, Uhren, Temperatur und anderen Variablen beziehen, um einen sicheren Betrieb des Computersystems 200 beim Verlassen des Niederenergiemodus zu gewährleisten, was die Hochfahrzeit weiter verbessern kann, indem der Umfang der beim Aufwachen erforderlichen Tests reduziert wird.
  • Nun auf die 3A-3B bezugnehmend, sind die allgemeinen Abläufe zwischen dem Verarbeitungssystem 202 und dem Controller 204 dargestellt. Beispielhaft können das Verarbeitungssystem 202 und der Controller 204 gemäß den allgemeinen Abläufen zusammenwirken, um mindestens einige der Blöcke B102-B110 des Verfahrens 100 zu implementieren. 3A zeigt ein beispielhaftes Flussdiagramm 300A, das den Empfang und die Verarbeitung einer Anforderung zum Herunterfahren oder Ausschalten des Computersystems 200 umfasst. 3B zeigt ein beispielhaftes Flussdiagramm 300B, das den Eintritt in einen Niederenergiemodus als Reaktion auf die im Flussdiagramm 300A empfangene und verarbeitete Anforderung zum Herunterfahren oder Ausschalten umfasst.
  • Die Funktionen, die vom Verarbeitungssystem 202 ausgeführt werden können, werden auf der linken Seite der 3A und 3B gezeigt, und Schritte, die vom Controller 204 ausgeführt werden können, werden auf der rechten Seite der 3A und 3B gezeigt. Die 3A und 3B zeigen im Allgemeinen den Zeitablauf, der sich für einen beispielhaften Prozess nach unten bewegt. Es ist zu beachten, dass die Länge der gezeigten Zeitabläufe lediglich ein Beispiel ist und dass die Zeitabläufe in oder zwischen den einzelnen Blöcken variieren können, ohne vom Schutzumfang der vorliegenden Offenbarung abzuweichen. In ähnlicher Weise können die zwischen den beiden Seiten dargestellten Pfeile eine oder mehrere Nachrichten oder Statusaktualisierungen anzeigen, die zwischen dem Verarbeitungssystem 202 und dem Controller 204 gesendet werden, oder sie können einen nächsten Schritt anzeigen, der unternommen wird, ohne dass irgendwelche Informationen oder Nachrichten zwischen dem Verarbeitungssystem 202 und dem Controller 204 gesendet werden. Insbesondere die Pfeile und die Zeitintervalle dienen lediglich dazu, dem Leser die beteiligten Konzepte zu erläutern.
  • Im Flussdiagramm 300A umfasst Block B302, dass der Controller 204 das Verarbeitungssystem 202 auffordert, herunterzufahren oder sich abzuschalten, beispielsweise als Reaktion auf eine Anzeige zum Herunterfahren oder Ausschalten von einer Fahrzeugkomponente außerhalb des Computersystems 200. Der Controller 204 kann diese Anforderung zum Herunterfahren oder Ausschalten an das Verarbeitungssystem 202 senden. Block B304 beinhaltet, dass der Controller 204 eine Abschaltsequenz des Verarbeitungssystems 202 einleitet. Block B306 beinhaltet, dass der Controller 204 einen Reboot des Verarbeitungssystems 202 auslöst. Block B308 umfasst die Vorbereitung des Verarbeitungssystems 202 auf den von der Controller 204 ausgelösten Reboot. Das Verarbeitungssystem 202 kann die Bereitschaft zum Reboot an den Controller 204 zurückmelden, oder der Controller 204 kann ein bestimmtes Zeitintervall abwarten. Block B310 beinhaltet, dass der Controller 204 den Reset des Verarbeitungssystems 202 auslöst. Der Controller 204 kann auch die vom Verarbeitungssystem 202 durchzuführende Diagnose einleiten. Block B312 umfasst den Reboot des Verarbeitungssystems 202 und die anschließende Durchführung der Diagnose, wie vom Controller 204 angewiesen. Nach Abschluss der Diagnose kann das Verarbeitungssystem 202 dem Controller 204 den Abschluss melden. Der Bericht kann die Angabe enthalten, dass keine Fehler gefunden wurden, eine Angabe zu gefundenen Fehlern oder andere Informationen. Block B314 beinhaltet, dass der Controller 204 einen Reset des Verarbeitungssystems 202 durchführt, wenn angezeigt wird, dass die Diagnose abgeschlossen ist. In Block B316 wird das Verarbeitungssystem 202 in einen funktionalen Betriebsmodus rebootet. Der funktionale Betriebsmodus kann das Laden aller oder eines Teils der Programme, Anwendungen, Funktionen und anderer Computeranweisungen umfassen, die mit der autonomen Steuerung des autonomen Fahrzeugs verbunden sind. Block B318 beinhaltet, dass der Controller 204 den Eintritt in den Funktionsmodus des Verarbeitungssystems 202 erkennt (oder auf andere Weise eine Anzeige darauf erhält).
  • Im Flussdiagramm 300B enthält der Block B350, dass das Verarbeitungssystem 202 den Eintritt in den Niederenergiemodus nach Ablauf eines bestimmten Zeitgebers anfordert. Der Zeitgeber kann eine Beendigung des Niederenergiemodus ermöglichen. Block B352 umfasst, dass der Controller 204 den Niederenergiemodus auslöst und dem Verarbeitungssystem 202 antwortet. Block B354 beinhaltet, dass das Verarbeitungssystem 202 Einheiten in den Ruhezustand versetzt und den Rechenzustand im Computerspeicher 206 speichert. Zu den in den Ruhezustand versetzten Einheiten kann jede der verschiedenen Komponenten des Computersystems 200 gehören, und sie können zusätzlich oder alternativ verschiedene andere Komponenten außerhalb des Computersystems 200 umfassen, wie z. B. Peripheriegeräte, Sensoren, Anzeigen, Eingabegeräte, Ausgabegeräte und/oder andere elektronische Geräte. Der Rechenzustand, der unter Verwendung von Block B316 des Flussdiagramms 300A erzeugt und unter Verwendung von Block B318 des Flussdiagramms 300A erfasst worden sein kann, kann in dem Computerspeicher 206 gespeichert werden. Dies kann es ermöglichen, dass der Rechenzustand beim Booten aus dem Computerspeicher 206 abgerufen werden kann. Block B356 umfasst, dass der Controller einen Status an eine oder mehrere Komponenten des autonomen Fahrzeugs meldet, die sich außerhalb des Computersystems 200 befinden. Block B356 kann vom Controller 204 ausgeführt werden, während das Verarbeitungssystem 202 Einheiten in den Ruhezustand versetzt und/oder den Rechenzustand speichert. Block B358 beinhaltet, dass das Verarbeitungssystem 202 eine Ausschaltsequenz startet. Block B360 beinhaltet, dass das Verarbeitungssystem 202 mindestens einen Teil des Computersystems 200 in den Niederenergiemodus versetzt.
  • Nun auf 4A bezugnehmend, ist 4A ein Flussdiagramm 400A, das das Verlassen des Ruhezustands zur Wiederaufnahme der autonomen Steuerung darstellt, wie es von dem Verarbeitungssystem 202 und dem Controller 204 gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird. Beispielsweise können das Verarbeitungssystem 202 und der Controller 204 gemäß dem Flussdiagramm 400A zusammenwirken, um mindestens einige der Blöcke B112-B114 des Verfahrens 100 zu implementieren.
  • Block B402 beinhaltet, dass der Controller 204 einen Trigger oder eine Anzeige für das Einschalten oder Hochfahren des Fahrzeugs empfängt. Der Trigger kann vom Fahrzeugkabelbaum 214 über den Energiemanager 212 empfangen werden. Block B404 umfasst die Bereitstellung von Energie für den Controller 204, z. B. durch den Energiemanager 212. Beispielsweise kann die Energie von der Energiequelle 208 über den Energiemanager 212 bereitgestellt werden. Block B406 umfasst das Booten des Controllers 204. Der Controller 204 kann mit verschiedenen Operationen beginnen, um den Trigger zum Einschalten oder Hochfahren zu verarbeiten und die anderen Komponenten des Computersystems 200 anzuweisen, den Stromsparmodus zu verlassen. Block B408 umfasst, dass der Controller 204 auf den Trigger zum Einschalten oder Hochfahren reagiert. Beispielsweise kann der Controller 204 eine Nachricht an eine Komponente außerhalb des Computersystems 200 senden, die anzeigt, dass der Trigger zum Einschalten oder Hochfahren empfangen wurde und verarbeitet wird.
  • In Block B410 umfasst, dass der Controller 204 das Verarbeitungssystem 202 anweist, den Niederenergiemodus zu verlassen und den normalen Betrieb wieder aufzunehmen. Der Controller 204 kann den Vorregler 216 und/oder den Spannungsregler 220 anweisen, Strom (z. B. volle Leistung) an entsprechenden Komponenten des Computersystems 200 zu liefern, wie hierin beschrieben. Außerdem können der Vorregler 216 und/oder der Spannungsregler 220 das Verarbeitungssystem 202, die Peripheriegeräte, den Computerspeicher 206 und andere Komponenten mit Strom versorgen.
  • Block B412 umfasst, dass sich das Verarbeitungssystem 202 auf das Verlassen des Niederenergiemodus vorbereitet. Dazu kann die Wiederherstellung des Rechenzustands aus dem Computerspeicher 206 gehören. Block B414 beinhaltet, dass das Verarbeitungssystem 202 dem Controller 204 anzeigt, dass das Verarbeitungssystem für die autonome Steuerung bereit ist. Block B416 beinhaltet, dass der Controller 204 eine Meldung über die Bereitschaft des Verarbeitungssystems 202 an eine Komponente außerhalb des Computersystems 200 sendet. Der Block B418 beinhaltet, dass der Controller 204 das Verarbeitungssystem 202 anweist, die autonome Steuerung des autonomen Fahrzeugs zu übernehmen. Das Verarbeitungssystem kann dann die autonome Steuerung übernehmen, bis eine nachfolgende Anzeige zum Herunterfahren oder Ausschalten empfangen wird oder ein anderes Ereignis eintritt oder erkannt wird.
  • Nun auf 4B bezugnehmend, ist 4B ein Flussdiagramm 400B, das das Verlassen des Ruhezustands zu einem ausgeschalteten Zustand darstellt, wie es vom Controller 204 gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchgeführt wird. Beispielsweise kann der Controller 204 gemäß dem Flussdiagramm 400B handeln, um mindestens einige der Blöcke B122-B124 des Verfahrens 100 zu implementieren.
  • Block B452 beinhaltet, dass der Energiemanager 212 eine Zeitüberschreitung aus dem Niederenergiemodus aufgrund einer schwachen Batterie, einer Gesamtzeit in einem Zyklus von Energiesparmodi oder eines anderen Triggers auslöst. Block B454 beinhaltet, dass der Controller 204 als Reaktion auf das Aufwachen des Energiemanagers 212 durch den Energiemanager 212 mit Strom versorgt wird. Block B456 beinhaltet, dass der Controller 204 die Zeitüberschreitung aufgrund des Auslösers bestätigt. Block B458 umfasst, dass der Controller 204 ein Abschalten anderer Komponenten im Computersystem 200 anweist (die z. B. über eine Stromsparschiene mit Strom versorgt werden). Block B460 umfass, dass der Controller 204 den Energiemanager 212 in den Standby-Modus versetzt und sich selbst ausschaltet. Während des Ausschaltzustands können alle Schienen des Computersystems 200 ausgeschaltet sein, mit Ausnahme des Energiemanagers 212, der sich im Standby- oder Schlafmodus befinden kann. Außerdem kann sich der Schnittstellenmanager 210 in einem Standby-Niederenergiemodus befinden.
  • 5 ist ein Flussdiagramm, das ein Verfahren 500 für das Eintreten in und das Verlassen eines Niederenergiemodus zur Wiederaufnahme der autonomen Steuerung gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 500 wird beispielhaft in Bezug auf das Computersystem 200 der 2 beschrieben. Das Verfahren 500 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
  • Das Verfahren 500 umfasst in Block B502 die Durchführung von Diagnosen auf einem Computersystem. Beispielsweise kann das Verarbeitungssystem 202 eine Diagnose auf dem Computersystem 200 durchführen, das für die autonome Steuerung einer Maschine (z. B. des Fahrzeugs 800) verwendet wird, basierend mindestens auf einer Anzeige für das Herunterfahren oder Ausschalten der Maschine.
  • Das Verfahren 500 umfasst in Block B504 das Rebooten des Computersystems. Beispielsweise kann das Verarbeitungssystem 202 einen oder mehrere Teile des Computersystems 200 mindestens teilweise basierend auf den Diagnosen rebooten, um das Computersystem 200 in einen Rechenzustand zu versetzen.
  • Das Verfahren 500 umfasst in Block B506 das Speichern des Rechenzustands. Beispielsweise kann das Verarbeitungssystem 202 den Rechenzustand im Computerspeicher 206 als gesicherten Zustand speichern.
  • Das Verfahren 500 umfasst in Block B508 das Eintreten in einen Stromsparmodus. Beispielsweise kann das Verarbeitungssystem 202 in einen Stromsparmodus übergehen, während der gesicherte Zustand im Computerspeicher 206 gespeichert wird.
  • Das Verfahren 500 umfasst in Block B510 das Beenden des Niederenergiemodus. Beispielsweise kann das Verarbeitungssystem 202 den Niederenergiemodus mindestens basierend auf einer Anzeige zum Einschalten oder Hochfahren der Maschine beenden.
  • Das Verfahren 500 aktiviert im Block B512 die autonome Steuerung. Zum Beispiel kann das Verarbeitungssystem die autonome Steuerung der Maschine durch das Computersystem 200 mindestens basierend auf der Wiederherstellung des gesicherten Zustands aus dem Computerspeicher 206 aktivieren.
  • Bezugnehmen auf 6, ist 6 ein Flussdiagramm, das ein Verfahren zum Steuern eines Verarbeitungssystems zum Eintritt in einen Stromsparmodus und zum Verlassen eines solchen Modus gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt. Das Verfahren 600 wird beispielhaft in Bezug auf das Computersystem 200 der 2 beschrieben. Das Verfahren 600 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
  • Das Verfahren 600 umfasst in Block B602 das Einleiten einer Abschaltsequenz. Beispielsweise kann der Controller 204 eine Abschaltsequenz als Reaktion auf die Erkennung einer Anzeige auf ein Herunterfahren oder Ausschalten eines Fahrzeugs (z. B. des Fahrzeugs 800) einleiten.
  • Das Verfahren 600 umfasst in Block B604 die Anweisung, eine Diagnose durchzuführen. Beispielsweise kann der Controller 204 das für die autonome Steuerung des Fahrzeugs verwendete Computersystem 200 anweisen, eine Diagnose durchzuführen.
  • Das Verfahren 600 umfasst in Block B606 die Anweisung, einen Reboot durchzuführen. Beispielsweise kann der Controller 204 einen oder mehrere Teile des Computersystems 200 (z. B. das Verarbeitungssystem 202) anweisen zu rebooten, um das Computersystem 200 zu einem Rechenzustand zu konfigurieren und den Rechenzustand im Computerspeicher 206 als gesicherten Zustand zu speichern.
  • Das Verfahren 600 umfasst in Block B608 das Auslösen eines Stromsparmodus. Beispielsweise kann der Controller 204 einen Stromsparmodus für eine oder mehrere Komponenten innerhalb des Computersystems 200 auslösen, während der gesicherte Zustand im Computerspeicher 206 gespeichert wird.
  • Das Verfahren 600 umfasst in Block B610 das Auslösen des Verlassens des Niederenergiemodus. Beispielsweise kann der Controller 204 ein Verlassen des Niederenergiemodus mindestens basierend auf einer Anzeige zum Einschalten oder Hochfahren des Fahrzeugs auslösen, wobei das Auslösen des Verlassens die autonome Steuerung des Fahrzeugs durch das Computersystem 200 mindestens basierend darauf ermöglicht, dass der gespeicherte Zustand aus dem Computerspeicher 206 wiederhergestellt wird.
  • Nun auf 7 bezugnehmend, ist 7 ein Flussdiagramm, das ein Verfahren 700 zum Einleiten und Verlassen eines Niederenergiemodus gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt. Das Verfahren 700 wird beispielhaft in Bezug auf das (hierin erläuterte) Computersystem 200 der 2 beschrieben. Dieses Verfahren 700 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
  • Das Verfahren 700 umfasst in Block B702 die Durchführung von systeminternen Tests. Beispielsweise kann das Verarbeitungssystem 202 einen systeminternen Test des Computersystems 200 durchführen, das für die autonome Steuerung eines Fahrzeugs verwendet wird, und basierend mindestens auf einer ersten Anzeige eines Abschaltens der Zündung des Fahrzeugs.
  • Das Verfahren 700 umfasst in Block B704 das Konfigurieren eines Rechenzustands. Beispielsweise kann das Verarbeitungssystem 202 das Computersystem 200 in einen Rechenzustand versetzen, der in der Lage ist, die autonome Steuerung mindestens basierend auf dem Abschluss der systeminternen Tests durchzuführen.
  • Das Verfahren 700 umfasst in Block B706 den Betrieb in einem Niederenergiemodus. Beispielsweise kann das Verarbeitungssystem 202 in einem Niederenergiemodus arbeiten, während der Rechenzustand im Computerspeicher 206 als gesicherter Zustand gespeichert ist.
  • Das Verfahren 700 umfasst in Block B708 das Beenden des Niederenergiemodus. Beispielsweise kann das Verarbeitungssystem 202 den Niederenergiemodus mindestens basierend auf einer zweiten Anzeige eines Einschaltens der Zündung des Fahrzeugs beenden.
  • Das Verfahren 700 umfasst in Block B710 die Aktivierung der autonomen Steuerung. Zum Beispiel kann das Verarbeitungssystem 202 die autonome Steuerung der Maschine durch das Computersystem 200 mindestens basierend auf der Wiederherstellung des gesicherten Zustands aus dem Computerspeicher 206 aktivieren.
  • Beispielhaftes autonomes Fahrzeug
  • 8A ist eine Illustration eines beispielhaften autonomen Fahrzeugs 800 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 800 (hier alternativ als „Fahrzeug 800“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug sein, wie z. B. ein Pkw, ein Lkw, ein Bus, ein Ersthelferfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, ein Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (z. B. ein unbemanntes Fahrzeug und/oder ein Fahrzeug, das einen oder mehrere Fahrgäste aufnimmt). Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 800 kann in der Lage sein, Funktionen gemäß einer oder mehrerer der Stufen 1 bis 5 der autonomen Fahrstufen zu erfüllen. Beispielsweise kann das Fahrzeug 800 je nach Ausführungsform Fahrerassistenz (Stufe 1), Teilautomatisierung (Stufe 2), bedingte Automatisierung (Stufe 3), Hochautomatisierung (Stufe 4) und/oder Vollautomatisierung (Stufe 5) bieten. Der Begriff „autonom“, wie er hier verwendet wird, kann jede und/oder alle Arten von Autonomie für das Fahrzeug 800 oder eine andere Maschine umfassen, wie z. B. vollständig autonom, hochgradig autonom, bedingt autonom, teilautonom, unterstützende Autonomie, teilautonom, primär autonom oder eine andere Bezeichnung.
  • Das Fahrzeug 800 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 800 kann ein Antriebssystem 850 umfassen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftanlage, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 850 kann mit einem Antriebsstrang des Fahrzeugs 800 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 800 zu ermöglichen. Das Antriebssystem 850 kann in Reaktion auf den Empfang von Signalen von der Drosselklappe/Beschleunigungsvorrichtung 852 gesteuert werden.
  • Ein Lenksystem 854, das ein Lenkrad umfassen kann, kann verwendet werden, um das Fahrzeug 800 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 850 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 854 kann Signale von einem Lenkaktor 856 empfangen. Das Lenkrad kann optional für die vollständige Automatisierung (Stufe 5) eingesetzt werden.
  • Das Bremssensorsystem 846 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktoren 848 und/oder Bremssensoren zu betätigen.
  • Ein oder mehrere Controller 836, die einen oder mehrere System-on-Chips (SoCs) 804 (8C) und/oder GPU(s) enthalten kann/können, kann/können Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 800 senden. Beispielsweise können der/die Controller Signale zum Betätigen der Fahrzeugbremsen über einen oder mehrere Bremsaktoren 848, zum Betätigen des Lenksystems 854 über einen oder mehrere Lenkaktoren 856 und zum Betätigen des Antriebssystems 850 über einen oder mehrere Drosselklappen/Gaspedale 852 senden. Der/die Controller 836 kann/können eine oder mehrere eingebaute (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen des Fahrzeugs 800 zu unterstützen. Der/die Controller 836 kann/können eine erste Steuerung 836 für autonome Fahrfunktionen, eine zweite Steuerung 836 für funktionale Sicherheitsfunktionen, eine dritte Steuerung 836 für Funktionen der künstlichen Intelligenz (z. B. Computervision), eine vierte Steuerung 836 für Infotainment-Funktionen, eine fünfte Steuerung 836 für Redundanz unter Notfallbedingungen und/oder andere Steuerungen umfassen. In einigen Beispielen kann eine einzige Steuerung 836 zwei oder mehr der oben genannten Funktionen übernehmen, zwei oder mehr Steuerungen 836 können eine einzige Funktion übernehmen und/oder eine beliebige Kombination davon.
  • Der/die Controller 836 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 800 als Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren (z. B. Sensoreingaben) empfangen werden. Die Sensordaten können beispielsweise und ohne Einschränkung empfangen werden von (einem) Sensor(en) des globalen Navigationssatellitensystems 858 (z. B. Global-Positioning-System-Sensor(en)), Radar-Sensor(en) 860, Ultraschallsensor(en) 862, LIDAR-Sensor(en) 864, Trägheitsmesseinheits- (IMU)-Sensor(en) 866 (z. B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 896, Stereokamera(s) 868, Weitwinkelkamera(s) 870 (z. B. Fischaugenkameras), Infrarotkamera(s) 872, Umgebungskamera(s) 874 (z. B. 360-Grad-Kameras), Fernbereichs- und/oder Mittelbereichskamera(s) 898, Geschwindigkeitssensor(en) 844 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 800), Vibrationssensor(en) 842, Lenksensor(en) 840, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 846) und/oder andere Sensortypen.
  • Eines oder mehrere der Steuerungen 836 können Eingaben (z. B. in Form von Eingabedaten) von einem Kombiinstrument 832 des Fahrzeugs 800 empfangen und Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten usw.) über eine Anzeige 834 der Mensch-Maschine-Schnittstelle (HMI), einen akustischen Signalgeber, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 800 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 822 der 8C), Standortdaten (z. B. der Standort des Fahrzeugs 800, z. B. auf einer Karte), Richtung, Standort anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von dem/den Controller 836 wahrgenommen, usw. umfassen. Beispielsweise kann die HMI-Anzeige 834 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 800 umfasst außerdem eine Netzwerkschnittstelle 824, die eine oder mehrere drahtlose Antennen 826 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 824 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 826 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) über lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low Power Wide Area Networks (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
  • 8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder stellen ein Ausführungsbeispiel dar und sind nicht als einschränkend zu betrachten. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder die Kameras können an verschiedenen Stellen des Fahrzeugs 800 angeordnet sein.
  • Die Kameratypen für die Kameras können unter anderem Digitalkameras sein, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 800 angepasst werden können. Die Kamera(s) kann/können mit der Sicherheitsstufe B (ASIL) und/oder einer anderen ASIL betrieben werden. Die Kameratypen können je nach Ausführungsform eine beliebige Bildaufnahmerate aufweisen, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw.. Die Kameras können einen Rollblendenverschluss, globalen Blendenverschluss, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar-Farbfilteranordnung (RCCC), eine Rot-Klar-Klar-Blau-Farbfilteranordnung (RCCB), eine Rot-Blau-Grün-Klar-Farbfilteranordnung (RBGC), eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensor-Farbfilteranordnung (RGGB), eine Monochromsensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung umfassen. In einigen Ausführungsformen können Kameras mit klaren Pixeln, wie z. B. Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, verwendet werden, um die Lichtempfindlichkeit zu erhöhen.
  • In einigen Beispielen können eine oder mehrere der Kameras verwendet werden, um erweiterte Fahrerassistenzsysteme (ADAS) auszuführen (z. B. als Teil einer redundanten oder ausfallsicheren Konstruktion). So kann beispielsweise eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z. B. alle Kameras) können gleichzeitig Bilddaten (z. B. Video) aufzeichnen und liefern.
  • Eine oder mehrere Kameras können in einer Montagevorrichtung, z. B. einer kundenspezifischen (3D-gedruckten) Vorrichtung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschalten, die die Bilddatenerfassung der Kamera beeinträchtigen könnten. Bei der Montage von Außenspiegeln können die Außenspiegel kundenspezifisch dreidimensional gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen können die Kameras in den Außenspiegel integriert werden. Bei Seitenkameras können die Kameras auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 800 einschließt (z. B. nach vorne gerichtete Kameras), können für die Umgebungsansicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Controller 836 und/oder Steuer-SoCs Informationen bereitzustellen, 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 LID AR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnung (LDW), autonome Geschwindigkeitsregelung (ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
  • In einer nach vorne gerichteten Konfiguration kann eine Vielzahl von Kameras verwendet werden, z. B. eine monokulare Kameraplattform, die einen CMOS-Farbbildsensor (Komplementär-Metalloxid-Halbleiter) enthält. Ein weiteres Beispiel sind eine oder mehrere Weitwinkelkameras 870, die verwendet werden können, um Objekte zu erkennen, die von der Peripherie her ins Blickfeld kommen (z. B. Fußgänger, kreuzende Fahrzeuge oder Fahrräder). Obwohl in 8B nur eine Weitwinkelkamera dargestellt ist, kann das Fahrzeug 800 mit einer beliebigen Anzahl von Weitwinkelkameras 870 ausgestattet sein. Darüber hinaus kann/können eine oder mehrere Kameras mit großer Reichweite 898 (z. B. ein Stereokamerapaar mit großer Reichweite) für die tiefenbasierte Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Weitbereichskamera(s) 898 kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung eingesetzt werden.
  • Eine oder mehrere Stereokameras 868 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 868 kann/können eine integrierte Steuereinheit enthalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Multicore-Mikroprozessor mit integrierter CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Mit einer solchen Einheit kann eine 3D-Karte der Fahrzeugumgebung erstellt werden, einschließlich einer Entfernungsschätzung für alle Punkte im Bild. Eine alternative Stereokamera(s) 868 kann einen oder mehrere kompakte Stereosicht-Sensoren mit zwei Kameraobjektiven (je eines links und rechts) und einen Bildverarbeitungschip umfassen, der die Entfernung 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 hier beschriebenen Stereokameras können auch andere Typen von Stereokameras (868) verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 800 einschließt (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Kollisionswarnungen bei Seitenaufprall verwendet werden. Beispielsweise können die Umgebungskamera(s) 874 (z. B. vier Umgebungskameras 874 wie in 8B dargestellt) am Fahrzeug 800 positioniert werden. Die Umgebungskamera(s) 874 kann/können Weitwinkelkamera(s) 870, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Vier Beispiele: Vier Fischaugenkameras können an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskameras 874 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als vierte Umgebungskamera nutzen.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 800 einschließt (z. B. Rückfahrkameras), können für die Einparkhilfe, 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) 898, Stereokamera(s) 868, Infrarotkamera(s) 872 usw.), wie hierin beschrieben.
  • 8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Alle Komponenten, Merkmale und Systeme des Fahrzeugs 800 in 8C sind als über den Bus 802 verbunden dargestellt. Der Bus 802 kann eine Controller Area Network (CAN)-Datenschnittstelle (hier alternativ als „CAN-Bus“ bezeichnet) umfassen. Ein CAN-Bus kann ein Netzwerk innerhalb des Fahrzeugs 800 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 800 verwendet wird, wie z. B. Betätigung von Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischern usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten hat, jeder mit seiner eigenen eindeutigen Kennung (z. B. einer CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Motordrehzahl (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 802 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Auch wenn der Bus 802 durch eine einzige Leitung dargestellt wird, ist dies nicht als Einschränkung zu verstehen. So kann es beispielsweise eine beliebige Anzahl von Bussen 802 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen mit einem anderen Protokoll umfassen können. In einigen Beispielen können zwei oder mehr Busse 802 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. So kann beispielsweise ein erster Bus 802 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 802 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 802 mit einer beliebigen Komponente des Fahrzeugs 800 kommunizieren, und zwei oder mehr Busse 802 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 804, jeder Controller 836 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingangsdaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 800) und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 800 kann einen oder mehrere Controller 836 enthalten, wie sie hier in Bezug auf 8A beschrieben sind. Der/die Controller 836 kann/können für eine Vielzahl von Funktionen verwendet werden. Der/die Controller 836 kann (können) mit verschiedenen anderen Komponenten und Systemen des Fahrzeugs 800 gekoppelt werden und kann (können) für die Steuerung des Fahrzeugs 800, die künstliche Intelligenz des Fahrzeugs 800, das Infotainment des Fahrzeugs 800 und/oder Ähnliches verwendet werden.
  • Das Fahrzeug 800 kann ein oder mehrere System(e) auf einem Chip (SoC) 804 enthalten. Der SoC 804 kann CPU(s) 806, GPU(s) 808, Prozessor(en) 810, Cache(s) 812, Beschleuniger 814, Datenspeicher 816 und/oder andere nicht dargestellte Komponenten und Merkmale umfassen. Der/die SoC(s) 804 kann/können zur Steuerung des Fahrzeugs 800 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise können die SoC(s) 804 in einem System (z. B. dem System des Fahrzeugs 800) mit einer HD-Karte 822 kombiniert werden, die Kartenaktualisierungen und/oder -aktualisierungen über eine Netzwerkschnittstelle 824 von einem oder mehreren Servern (z. B. dem/den Server(n) 878 der 8D) erhalten kann.
  • Die CPU(s) 806 kann/können einen CPU-Cluster oder CPU-Komplex (hier auch als „CCPLEX“ bezeichnet) umfassen. Die CPU(s) 806 kann/können mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsformen können die CPU(s) 806 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsformen kann (können) die CPU(s) 806 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache (z. B. einen 2 MB L2-Cache) verfügt. Die CPU(s) 806 (z. B. der CCPLEX) kann so konfiguriert sein, dass sie den gleichzeitigen Clusterbetrieb unterstützt, so dass jede Kombination der Cluster der CPU(s) 806 zu jedem Zeitpunkt aktiv sein kann.
  • Die CPU(s) 806 kann/können Energiemanagementfunktionen implementieren, die eines oder mehrere der folgenden Merkmale umfassen: einzelne Hardwareblöcke können im Leerlauf automatisch taktgesteuert werden, um dynamische Energie zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert werden; jeder Kerncluster kann unabhängig taktgesteuert werden, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kerncluster kann unabhängig stromgesteuert werden, wenn alle Kerne stromgesteuert sind. Die CPU(s) 806 kann/können darüber hinaus einen erweiterten Algorithmus zur Management von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten festgelegt werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Prozessorkerne können vereinfachte Sequenzen für den Eintritt in den Energiezustand in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
  • Die GPU(s) 808 kann/können eine integrierte GPU (hier auch als „iGPU“ bezeichnet) umfassen. Die GPU(s) 808 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 808 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 808 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) 808 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPU(s) 808 kann/können Anwendungsprogrammierschnittstelle(n) (API(s)) für Berechnungen verwenden. Darüber hinaus können die GPU(s) 808 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
  • Der/die Grafikprozessor(en) 808 kann/können für die beste Leistung in Automobil- und eingebetteten Anwendungsfällen optimiert werden. Die GPU(s) 808 kann/können beispielsweise auf einem Fin-Feldeffekttransistor (FinFET) hergestellt werden. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 808 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Reihe von gemischtpräzisen Rechenkernen enthalten, die in mehrere Blöcke unterteilt sind. So können beispielsweise 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt werden, ohne darauf beschränkt zu sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA-Tensor-Kerne mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64-KB-Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade enthalten, 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-Planungsfunktion enthalten, um eine feinere Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsame Speichereinheit enthalten, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • Der/die Grafikprozessor(en) 808 kann/können einen Speicher mit hoher Bandbreite (HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, beispielsweise ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
  • Die GPU(s) 808 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern enthalten, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz von Speicherbereichen verbessert wird, die von den Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 808 direkt auf die Seitentabellen der CPU(s) 806 zugreifen können. In solchen Beispielen kann, wenn die Speichermanagementeinheit (MMU) der GPU(s) 808 einen Fehler feststellt, eine Adressübersetzungsanforderung an die CPU(s) 806 übertragen werden. Als Reaktion darauf kann die CPU(s) 806 in ihren Seitentabellen nach der virtuell-physikalischen Zuordnung für die Adresse suchen und die Übersetzung an die GPU(s) 808 zurückübertragen. So kann die einheitliche Speichertechnologie einen einzigen, einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 806 als auch der GPU(s) 808 ermöglichen und dadurch die Programmierung der GPU(s) 808 und die Portierung von Anwendungen auf die GPU(s) 808 vereinfachen.
  • Darüber hinaus kann die GPU(s) 808 einen Zugriffszähler enthalten, der die Häufigkeit des Zugriffs der GPU(s) 808 auf den Speicher anderer Prozessoren verfolgt. 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) 804 kann/können eine beliebige Anzahl von Cache(s) 812 enthalten, einschließlich der hier beschriebenen. Der/die Cache(s) 812 kann/können beispielsweise einen L3-Cache umfassen, der sowohl der/den CPU(s) 806 als auch der/den GPU(s) 808 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 806 als auch mit der/den GPU(s) 808 verbunden ist). Der/die Cache(s) 812 kann/können einen Write-Back-Cache umfassen, 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 umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Der/die SoC(s) 804 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der verschiedenen Aufgaben oder Operationen des Fahrzeugs 800 - wie z. B. die Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus kann/können der/die SoC(s) 804 eine Gleitkommaeinheit(en) (FPU(s)) - oder andere mathematische Coprozessor- oder numerische Coprozessor-Typen - zur Durchführung mathematischer Operationen innerhalb des Systems enthalten. Beispielsweise können die SoC(s) 104 eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in eine CPU(s) 806 und/oder GPU(s) 808 integriert sind.
  • Der/die SoC(s) 804 kann/können einen oder mehrere Beschleuniger 814 enthalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Beispielsweise können die SoC(s) 804 einen Hardware-Beschleunigungscluster enthalten, 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) 808 und zur Entlastung einiger Aufgaben der GPU(s) 808 verwendet werden (z. B. um mehr Zyklen der GPU(s) 808 für die Durchführung anderer Aufgaben freizugeben). Der/die Beschleuniger 814 kann/können beispielsweise für gezielte Arbeitslasten verwendet werden (z. B. Wahrnehmung, Faltungsneuronale Netze (CNNs) usw.), die stabil genug sind, um beschleunigt werden zu können. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich regionsbasierter oder regionaler neuronaler Faltungsnetze (RCNNs) und schneller RCNNs (z. B. für die Objekterkennung).
  • Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) enthalten. Der/die DLA(s) kann/können eine oder mehrere Tensor-Verarbeitungseinheiten (TPUs) umfassen, die konfiguriert sein können, zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und zur Inferenz bereitzustellen. Bei den TPUs kann es sich um Beschleuniger handeln, die für die Ausführung von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) kann/können darüber hinaus für einen bestimmten Satz neuronaler Netzwerktypen und Gleitkommaoperationen sowie für die Inferenz optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann/können mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte sowie Postprozessorfunktionen unterstützt.
  • Die DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter beispielsweise und ohne Einschränkung: ein CNN für die Identifizierung und Erkennung 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 Erkennung und Identifizierung von Einsatzfahrzeugen und die Erkennung unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung des Fahrzeughalters unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsbezogene Ereignisse.
  • Die DLA(s) können jede Funktion der GPU(s) 808 ausführen, und durch die Verwendung eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder die DLA(s) oder die GPU(s) 808 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) 808 und/oder anderen Beschleunigern 814 überlassen.
  • Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) kann/können einen programmierbaren Bildverarbeitungsbeschleuniger (PVA) umfassen, der hier alternativ auch als Computervision-Beschleuniger bezeichnet werden kann. Der/die PVA(s) kann/können zur Beschleunigung von Computervision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Anwendungen für erweiterte Realität (AR) und/oder virtuelle Realität (VR) entwickelt und konfiguriert werden. Die PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. So kann jede PVA zum Beispiel und ohne Einschränkung eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
  • Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen zusammenwirken. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher enthalten. Die RISC-Kerne können je nach Ausführungsform eine beliebige Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten 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) 806 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung der PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockabstufung, vertikale Blockabstufung und/oder Tiefenabstufung umfassen können.
  • Bei den Vektorprozessoren kann es sich um programmierbare Prozessoren handeln, die so konzipiert sein können, dass sie die Programmierung von Computervision-Algorithmen effizient und flexibel ausführen und Signalverarbeitungsfunktionen bieten. In einigen Beispielen kann die PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Teilsystem kann als primäre Verarbeitungseinheit der PVA fungieren und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor enthalten, wie z. B. einen digitalen Signalprozessor mit einem einzigen Befehl und mehreren Daten (SIMD) und 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 einer bestimmten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität verwenden. So kann in einigen Ausführungsformen die Mehrzahl der in einer einzigen PVA enthaltenen Vektorprozessoren denselben Computervision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die in einer bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Computervision-Algorithmen für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinander folgende Bilder oder Teile eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren in jeder der PVAs. Darüber hinaus können die PVA(s) einen zusätzlichen Fehlerkorrekturcode (ECC) Speicher enthalten, um die Sicherheit des Systems insgesamt zu erhöhen.
  • Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) kann/können ein Computervision-Netzwerk auf dem Chip und SRAM enthalten, um ein SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 814 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der beispielsweise und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl die PVA als auch die DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine APB-Schnittstelle (Advanced Peripheral Bus), Konfigurationsschaltungen, einen Controller und einen Multiplexer umfassen. Es kann jeder beliebige Speichertyp verwendet werden. Die PVA und die DLA können auf den Speicher über ein Backbone zugreifen, das der PVA und der DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Das Backbone kann ein Computervision-Netzwerk auf dem Chip umfassen, das die PVA und die DLA mit dem Speicher verbindet (z. B. unter Verwendung des APB).
  • Das Computervision-Netz auf dem Chip kann eine Schnittstelle enthalten, die vor der Übertragung von Steuersignalen/Adressen/Daten feststellt, dass sowohl die PVA als auch die DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
  • In einigen Beispielen können die SoC(s) 804 einen Echtzeit-Raytracing-Hardwarebeschleuniger enthalten, wie er in der US-Patentanmeldung Nr. 16/101,232 beschrieben ist, die am 10. August 2018 eingereicht wurde. 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 Tree Traversal Units (TTUs) für die Ausführung einer oder mehrerer Operationen im Zusammenhang mit der Strahlenverfolgung verwendet werden.
  • Der/die Beschleuniger 814 (z. B. der Hardware-Beschleuniger-Cluster) kann/können für das autonome Fahren auf vielfältige Weise 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 der PVA eignen sich gut für algorithmische Bereiche, die eine vorhersehbare Verarbeitung bei geringem Stromverbrauch und geringer Latenzzeit erfordern. Mit anderen Worten: Die 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 für die Ausführung klassischer Computervision-Algorithmen konzipiert, da sie bei der Objekterkennung und der Verarbeitung ganzzahliger mathematischer Daten effizient sind.
  • Bei einer Ausführungsform der Technologie wird die PVA beispielsweise für die Durchführung des Computer-Stereobildes verwendet. In einigen Beispielen kann ein auf semiglobaler Anpassung basierender Algorithmus verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. Viele Anwendungen für das autonome Fahren der Stufen 3 bis 5 erfordern eine Bewegungsabschätzung/Stereoabgleich während der Fahrt (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Die PVA kann eine Computer-Stereosichtfunktion mit Eingaben von zwei monokularen Kameras durchführen.
  • In einigen Beispielen kann die PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Entsprechend der Verarbeitung von RADAR-Rohdaten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten zu erhalten. In anderen Beispielen wird die PVA für die Verarbeitung von Flugzeittiefendaten verwendet, z. B. durch Verarbeitung von Flugzeit-Rohdaten, um verarbeitete Flugzeitdaten zu erhalten.
  • Mit dem DLA kann jede Art von Netzwerk betrieben werden, um die Kontrolle und die Fahrsicherheit zu verbessern, z. B. ein neuronales Netzwerk, das für jede Objekterkennung einen Konfidenzmaß ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit oder als relative „Gewichtung“ der einzelnen Erkennungen im Vergleich zu anderen Erkennungen interpretiert werden. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und welche als falsch-positive Erkennungen betrachtet werden sollten. So kann das System beispielsweise einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die diesen Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die sichersten Erkennungen als Auslöser für AEB in Betracht gezogen werden. Die DLA kann ein neuronales Netz zur Regression des Vertrauenswertes einsetzen. Das neuronale Netz kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 866, die mit der Ausrichtung des Fahrzeugs 800 korreliert, die Entfernung, die Schätzungen der 3D-Position des Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 864 oder RADAR-Sensor(en) 860) erhalten werden, und andere.
  • Der/die SoC(s) 804 kann/können einen oder mehrere Datenspeicher 816 (z. B. einen Speicher) enthalten. Bei dem/den Datenspeicher(n) 816 kann es sich um einen On-Chip-Speicher des/der SoC(s) 804 handeln, der neuronale Netze speichern kann, die auf der GPU und/oder der DLA ausgeführt werden sollen. In einigen Beispielen kann der/die Datenspeicher 816 groß genug sein, um mehrere Instanzen neuronaler Netze zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 812 kann/können L2 oder L3 Cache(s) 812 umfassen. Der Verweis auf den/die Datenspeicher 816 kann einen Verweis auf den Speicher beinhalten, der mit der PVA, DLA und/oder anderen Beschleunigern 814 verbunden ist, wie hierin beschrieben.
  • Der/die SoC(s) 804 kann/können einen oder mehrere Prozessor(en) 810 (z. B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 810 kann/können einen Boot- und Energiemanagementprozessor enthalten, der ein dedizierter Prozessor und ein Subsystem sein kann, um Boot-Energie- und Managementfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energiemanagementprozessor kann Teil der Bootsequenz des/der SoC(s) 804 sein und kann Laufzeit-Energiemanagementdienste bereitstellen. Der Boot-Energieversorgungs- und -Managementprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen in einen Zustand mit niedriger Leistung, Management von Wärme- und Temperatursensoren des/der SoC(s) 804 und/oder Management der Energieversorgungszustände des/der SoC(s) 804 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert werden, dessen Ausgangsfrequenz proportional zur Temperatur ist, und der/die SoC(s) 804 kann/können die Ringoszillatoren verwenden, um die Temperaturen der CPU(s) 806, GPU(s) 808 und/oder des/der Beschleuniger(s) 814 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energiemanagementprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 804 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 800 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 800 zu einem sicheren Halt bringen).
  • Der (die) Prozessor(en) 810 kann (können) außerdem eine Reihe eingebetteter Prozessoren enthalten, die als Audioverarbeitungsmodul dienen können. Bei der Audioverarbeitungs-Engine kann es sich um ein Audio-Subsystem handeln, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-FO-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der (die) Prozessor(en) 810 kann (können) außerdem eine ständig eingeschaltete Prozessor-Engine enthalten, die die notwendigen Hardware-Funktionen zur Unterstützung der Sensormanagement mit geringem Stromverbrauch und des Aufwachens von Anwendungsfällen bereitstellen kann. Die ständig eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und Routing-Logik umfassen.
  • Der (die) Prozessor(en) 810 kann (können) außerdem eine Sicherheits-Cluster-Engine enthalten, die ein spezielles Prozessor-Subsystem für das Sicherheitsmanagement von Automobilanwendungen umfasst. Die Safety-Cluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber, einen Interrupt-Controller usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit einer Vergleichslogik zur Erkennung von Unterschieden zwischen ihren Operationen fungieren.
  • Der/die Prozessor(en) 810 kann/können außerdem eine Echtzeit-Kamera-Engine enthalten, die ein dediziertes Prozessor-Subsystem für das Echtzeit-Kameramanagement umfassen kann.
  • Der (die) Prozessor(en) 810 kann (können) außerdem einen Signalprozessor mit hohem Dynamikbereich enthalten, der einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
  • Der/die Prozessor(en) 810 kann/können einen Videobild-Compositor enthalten, 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 Player-Fenster zu erzeugen. Der Videobild-Compositor kann eine Linsenverzerrungskorrektur an der (den) Weitwinkelkamera(s) 870, an der (den) Surround-Kamera(s) 874 und/oder an den Sensoren der Überwachungskamera in der Kabine vornehmen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netz überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein System in der Kabine kann Lippenlesen durchführen, um den 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 Videobild-Compositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl zur räumlichen als auch zur zeitlichen Rauschunterdrückung enthalten. Tritt beispielsweise Bewegung in einem Video auf, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Bildern stammen. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung enthält, kann die vom Video-Compositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
  • Der Videobild-Compositor kann auch so konfiguriert sein, dass er eine Stereorektifizierung der eingegebenen Stereoobjektivbilder durchführt. Der Videobild-Compositor kann ferner für die Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 808 nicht ständig neue Oberflächen rendern muss. Selbst wenn der/die Grafikprozessor(en) 808 eingeschaltet und aktiv mit dem 3D-Rendering beschäftigt ist/sind, kann der Videobild-Compositor verwendet werden, um den/die Grafikprozessor(en) 808 zu entlasten und die Leistung und Reaktionsfähigkeit zu verbessern.
  • Der/die SoC(s) 804 kann/können außerdem eine serielle MIPI-Kameraschnittstelle zum Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock enthalten, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 804 kann/können außerdem einen oder mehrere Eingangs-/Ausgangs-Controller enthalten, die durch Software gesteuert werden können und für den Empfang von I/O-Signalen verwendet werden können, die keiner bestimmten Rolle zugeordnet sind.
  • Der/die SoC(s) 804 kann/können außerdem eine breite Palette von Peripherieschnittstellen enthalten, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energiemanagement und/oder anderen Geräten zu ermöglichen. die über Ethernet angeschlossen sein können), Daten vom Bus 802 (z. B. Geschwindigkeit des Fahrzeugs 800, Lenkradposition usw.), Daten von GNSS-Sensor(en) 858 (z. B. über Ethernet oder CAN-Bus angeschlossen). Der/die SoC(s) 804 kann/können darüber hinaus dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und die dazu verwendet werden können, die CPU(s) 806 von routinemäßigen Datenmanagementaufgaben zu entlasten.
  • Der/die SoC(s) 804 kann/können eine End-to-End-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsstufen 3 bis 5 abdeckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bietet, die Computervision- 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. Die SoC(s) 804 können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Beispielsweise kann der/die Beschleuniger 814 in Kombination mit der/den CPU(s) 806, der/den GPU(s) 808 und dem/den Datenspeicher(n) 816 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 Computervision-Algorithmen auf CPUs ausgeführt werden, die mit Hilfe von Hochsprachen wie der Programmiersprache C so konfiguriert werden können, dass sie eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von visuellen Daten ausführen können. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Bildverarbeitungsanwendungen zu erfüllen, z. B. in Bezug auf die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was 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 hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters, dass mehrere neuronale Netze gleichzeitig und/oder nacheinander ausgeführt und die Ergebnisse miteinander kombiniert werden können, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf der DLA oder dGPU (z. B. die GPU(s) 820) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netz nicht speziell trainiert wurde. Die DLA kann ferner ein neuronales Netz enthalten, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
  • Ein weiteres Beispiel ist, dass mehrere neuronale Netze gleichzeitig betrieben werden können, wie es für das Fahren der Stufen 3, 4 oder 5 erforderlich ist. So kann beispielsweise ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Glatteis hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Glatteis hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die (vorzugsweise auf dem CPU-Komplex ausgeführte) Software zur Wegplanung des Fahrzeugs darüber informiert, dass bei Erkennung blinkender Lichter Glatteis vorliegt. Das Blinklicht kann durch den Betrieb eines dritten neuronalen Netzes über mehrere Frames hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. innerhalb der DLA und/oder auf der/den GPU(s) 808.
  • 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 800 zu erkennen. Die „always on“-Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert und die Lichter einschaltet, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen die SoC(s) 804 für Sicherheit gegen Diebstahl und/oder Carjacking.
  • In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 896 verwenden, um Sirenen von Einsatzfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzen die SoC(s) 804 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einer bevorzugten Ausführungsform wird der CNN, der auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erkennen (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch so trainiert werden, dass es Einsatzfahrzeuge identifiziert, die für das örtliche Gebiet, in dem das Fahrzeug eingesetzt wird, spezifisch sind, wie es von dem/den GNSS-Sensor(en) 858 ermittelt wird. So wird das CNN beispielsweise versuchen, europäische Sirenen zu erkennen, wenn es in Europa eingesetzt wird, und nur nordamerikanische Sirenen, wenn es in den Vereinigten Staaten eingesetzt wird. Sobald ein Einsatzfahrzeug erkannt 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 mit Hilfe der Ultraschallsensoren 862 im Leerlauf laufen zu lassen, bis das/die Einsatzfahrzeug(e) vorbeifahren.
  • Das Fahrzeug kann eine oder mehrere CPU(s) 818 (z. B. diskrete CPU(s) oder dCPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) mit dem/den SoC(s) 804 verbunden sein können. Die CPU(s) 818 kann/können beispielsweise einen X86-Prozessor enthalten. Die CPU(s) 818 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) 804 und/oder der Überwachung des Status und des Zustands des/der Controller 836 und/oder des Infotainment-SoC 830, zum Beispiel.
  • Das Fahrzeug 800 kann eine oder mehrere GPU(s) 820 (z.B. diskrete GPU(s) oder dGPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) mit dem/den SoC(s) 804 gekoppelt sein können. Die GPU(s) 820 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z. B. durch die Ausführung redundanter und/oder unterschiedlicher neuronaler Netze, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netze basierend auf von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 800 verwendet werden.
  • Das Fahrzeug 800 kann ferner die Netzwerkschnittstelle 824 enthalten, die eine oder mehrere drahtlose Antennen 826 (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) enthalten kann. Die Netzwerkschnittstelle 824 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem/den Server(n) 878 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Datenverarbeitungsgeräten (z. B. Client-Vorrichtungen 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 Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 800 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 800 liefern (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 800). Diese Funktion kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 800 sein.
  • Die Netzwerkschnittstelle 824 kann einen SoC enthalten, der Modulations- und Demodulationsfunktionen bereitstellt und den/die Controller 836 in die Lage versetzt, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 824 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband enthalten. Die Frequenzumwandlungen können mit bekannten Verfahren und/oder mit Superheterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Funkfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionen für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle enthalten.
  • Das Fahrzeug 800 kann ferner einen oder mehrere Datenspeicher 828 umfassen, die außerhalb des Chips (z. B. außerhalb der SoC(s) 804) gespeichert werden können. Der/die Datenspeicher 828 kann/können ein oder mehrere Speicherelemente wie RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte umfassen, die mindestens ein Datenbit speichern können.
  • Das Fahrzeug 800 kann außerdem GNSS-Sensor(en) 858 enthalten. Der/die GNSS-Sensor(en) 858 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS-Sensoren (DGPS) usw.) unterstützen die Funktionen Kartierung, Wahrnehmung, Erstellung von Belegungsrastern und/oder Wegplanung. Es kann eine beliebige Anzahl von GNSS-Sensoren 858 verwendet werden, z. B. und ohne Einschränkung ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
  • Das Fahrzeug 800 kann außerdem RADAR-Sensor(en) 860 enthalten. Der/die RADAR-Sensor(en) 860 kann/können vom Fahrzeug 800 für die Fahrzeugerkennung über große Entfernungen verwendet werden, selbst bei Dunkelheit und/oder schlechten Wetterbedingungen. Der/die RADAR-Sensor(en) 860 kann/können den CAN-Bus und/oder den Bus 802 (z. B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 860 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. Zum Beispiel und ohne Einschränkung können der/die RADAR-Sensor(en) 860 für den Einsatz von Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
  • Der/die RADAR-Sensor(en) 860 kann/können verschiedene Konfigurationen umfassen, 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, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 860 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. Langstrecken-RADAR-Sensoren können monostatische multimodale RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die 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 800 Fahrspur des Fahrzeugs einfahren oder sie verlassen, schnell erfasst werden können.
  • RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 860 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 850 Grad (hinten) haben. Zu den RADAR-Systemen mit geringer Reichweite können unter anderem RADAR-Sensoren gehören, die an beiden Enden des hinteren Stoßfängers angebracht werden. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers angebracht ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug ständig überwachen.
  • RADAR-Systeme mit geringer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder als Spurwechselassistent eingesetzt werden.
  • Das Fahrzeug 800 kann außerdem einen oder mehrere Ultraschallsensoren 862 enthalten. Der/die Ultraschallsensor(en) 862, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 800 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 862 verwendet werden, und unterschiedliche Ultraschallsensoren 862 können für unterschiedliche Erfassungsbereiche (z. B. 2,5 m, 4 m) eingesetzt werden. Der/die Ultraschallsensor(en) 862 kann/können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
  • Das Fahrzeug 800 kann LIDAR-Sensor(en) 864 enthalten. Der/die LIDAR-Sensor(en) 864 kann/können für Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 864 kann/können der funktionalen Sicherheitsstufe ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 800 mehrere LIDAR-Sensoren 864 (z. B. zwei, vier, sechs usw.) enthalten, die Ethernet verwenden können (z. B. zur Bereitstellung von Daten an einen Gigabit-Ethernet-Switch).
  • In einigen Beispielen kann der/die LIDAR-Sensor(en) 864 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Im Handel erhältliche LIDAR-Sensoren 864 können eine Reichweite von etwa 800 m haben, mit einer Genauigkeit von 2 cm bis 3 cm und mit Unterstützung für eine Ethernet-Verbindung mit 800 Mbit/s, zum Beispiel. In einigen Beispielen können ein oder mehrere nicht vorspringende LIDAR-Sensoren 864 verwendet werden. In solchen Beispielen kann/können der/die LIDAR-Sensor(en) 864 als kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 800 eingebettet werden kann. Der/die LIDAR-Sensor(en) 864 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad mit einer Reichweite von 200 m selbst bei Objekten mit geringem Reflexionsvermögen bieten. Der/die frontmontierte(n) LIDAR-Sensor(en) 864 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
  • In einigen Beispielen können auch LIDAR-Technologien wie 3D-Blitz-LIDAR eingesetzt werden. 3D-Blitz-LIDAR verwendet einen Laserblitz als Übertragungsquelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von etwa 200 m zu beleuchten. Eine Flash-LIDAR-Einheit umfasst 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 werden, einer an jeder Seite des Fahrzeugs 800. Zu den verfügbaren 3D-Blitz-LIDAR-Systemen gehört eine 3D-Star-Array-LIDAR-Festkörperkamera, die außer einem Gebläse keine beweglichen Teile aufweist (z. B. ein nicht scannendes LIDAR-Gerät). Das Flash-LIDAR-Gerät kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Bild 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 ein Festkörpergerät ohne bewegliche Teile ist, kann der/die LIDAR-Sensor(en) 864 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
  • Das Fahrzeug kann außerdem einen oder mehrere IMU-Sensoren 866 enthalten. Der/die IMU-Sensor(en) 866 kann/können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 800 angeordnet sein. Der (die) IMU-Sensor(en) 866 kann (können) beispielsweise und ohne Einschränkung einen (mehrere) Beschleunigungsmesser, einen (mehrere) Magnetometer, ein (mehrere) Gyroskop(e), einen (mehrere) Magnetkompass(e) und/oder andere Sensortypen umfassen. In einigen Beispielen, wie z. B. bei sechsachsigen Anwendungen, kann/können der/die IMU-Sensor(en) 866 Beschleunigungsmesser und Gyroskope umfassen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 866 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
  • In einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 866 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert werden, das mikroelektromechanische Trägheitssensoren (MEMS), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage zu liefern. In einigen Beispielen können die IMU-Sensoren 866 das Fahrzeug 800 in die Lage versetzen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem die Geschwindigkeitsänderungen von GPS direkt beobachtet und mit den IMU-Sensoren 866 korreliert werden. In einigen Beispielen können der/die INW-Sensor(en) 866 und der/die GNSS-Sensor(en) 858 in einer einzigen integrierten Einheit kombiniert werden.
  • Das Fahrzeug kann Mikrofon(e) 896 enthalten, die im und/oder um das Fahrzeug 800 herum angebracht sind. Das/die Mikrofon(e) 896 kann/können u. a. zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen enthalten, einschließlich Stereokamera(s) 868, Weitwinkelkamera(s) 870, Infrarotkamera(s) 872, Umgebungskamera(s) 874, Fern- und/oder Mittelbereichskamera(s) 898 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 800 zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen für das Fahrzeug 800 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 800 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 umfassen. Die Kameras können zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hierin in Bezug auf 8A und 8B ausführlicher beschrieben.
  • Das Fahrzeug 800 kann außerdem einen oder mehrere Schwingungssensoren 842 enthalten. Der/die Schwingungssensor(en) 842 kann/können Schwingungen von Komponenten des Fahrzeugs, wie z. B. der Achse(n), messen. So können beispielsweise Änderungen der Vibrationen auf eine Änderung der Straßenoberfläche hinweisen. In einem anderen Beispiel können bei Verwendung von zwei oder mehr Schwingungssensoren 842 die Unterschiede zwischen den Schwingungen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z. B. wenn der Unterschied in der Schwingung zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
  • Das Fahrzeug 800 kann ein ADAS-System 838 enthalten. Das ADAS-System 838 kann in einigen Beispielen einen SoC enthalten. Das ADAS-System 838 kann einen autonomen/adaptiven/automatischen Geschwindigkeitsregler (ACC), eine kooperative adaptive Geschwindigkeitsregelung (CACC), eine Vorwärtskollisionswarnung (FCW), eine automatische Notbremsung (AEB), Spurverlassenswarnungen (LDW), einen Spurhalteassistenten (LKA), Toter-Winkel-Warner (BSW), Querverkehrswarnung hinten (RCTW), Kollisionswarnsysteme (CWS), Fahrspurzentrierung (LC) und/oder andere Merkmale und Funktionen umfassen.
  • Die ACC-Systeme können RADAR-Sensor(en) 860, LIDAR-Sensor(en) 864 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können einen ACC in Längsrichtung und/oder einen ACC in Querrichtung umfassen. Der ACC in Längsrichtung überwacht und steuert den Abstand zum unmittelbar vor dem Fahrzeug 800 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der seitliche ACC sorgt für die Einhaltung des Abstands und rät dem Fahrzeug 800, bei Bedarf die Spur zu wechseln. Lateral ACC ist mit anderen ADAS-Anwendungen wie LCA und CWS verwandt.
  • CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 824 und/oder die Funkantenne(n) 826 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-Kommunikationsverbindung (V2V) bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug-Kommunikationsverbindung (I2V) sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 800 und auf derselben Fahrspur wie dieses befinden), während das I2V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können eine oder beide I2V- und V2V-Informationsquellen enthalten. Angesichts der Informationen über die vor dem Fahrzeug 800 fahrenden Fahrzeuge kann das CACC-System 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 er korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 860, 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 einem Display, 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 erkennen einen drohenden Zusammenstoß mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Entfernungsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC verbunden sind. Wenn das AEB-System eine Gefahr erkennt, warnt es in der Regel zunächst den Fahrer, damit er korrigierend eingreift, um die Kollision zu vermeiden. Wenn 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 mindestens abzumildern. AEB-Systeme können Techniken wie die dynamische Bremsunterstützung und/oder die Crash-Imminent-Bremsung umfassen.
  • Spurhalteassistenten warnen den Fahrer durch optische, akustische und/oder taktile Signale, z. B. durch Vibrationen am Lenkrad oder am Sitz, wenn das Fahrzeug 800 die Fahrbahnmarkierungen überfährt. Ein Spurhaltewarnsystem wird nicht aktiviert, wenn der Fahrer durch Betätigen des Blinkers ein absichtliches Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC verbunden sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme sorgen für einen Lenkeingriff oder eine Bremsung, um das Fahrzeug 800 zu korrigieren, wenn das Fahrzeug 800 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen im toten Winkel des Fahrzeugs. BSW-Systeme können ein optisches, akustisches und/oder taktiles Warnsignal ausgeben, um darauf hinzuweisen, dass das Zusammenführen oder Wechseln der Fahrspur unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung ausgeben, wenn beim Rückwärtsfahren des Fahrzeugs 800 ein Objekt außerhalb des Bereichs der Heckkamera erkannt wird. Einige RCTW-Systeme umfassen 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 860 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, Lautsprecher und/oder einer vibrierenden Komponente.
  • Bei herkömmlichen ADAS-Systemen kann es zu falsch-positiven Ergebnissen kommen, die für den Fahrer ärgerlich und ablenkend sein können, aber in der Regel nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob wirklich ein Sicherheitszustand vorliegt und entsprechend zu handeln. In einem autonomen Fahrzeug 800 muss das Fahrzeug 800 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. eines ersten Controllers 836 oder eines zweiten Controllers 836) beachtet. In einigen Ausführungsformen kann das ADAS-System 838 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 erkennen. Die Ausgaben des ADAS-Systems 838 können an eine übergeordnete MCU weitergeleitet werden. Wenn die Ausgaben des Primärrechners und des Sekundärrechners kollidieren, muss die überwachende MCU bestimmen, wie der Konflikt gelöst werden kann, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der primäre Computer so konfiguriert sein, dass er der übergeordneten MCU einen Vertrauenswert liefert, der das Vertrauen des primären Computers in das gewählte Ergebnis angibt. Übersteigt der Vertrauenswert 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 geben der primäre und der sekundäre Computer unterschiedliche Ergebnisse an (z. B. den Konflikt), kann die übergeordnete MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
  • Die überwachende MCU kann so konfiguriert sein, dass sie ein neuronales Netz bzw. neuronale Netze betreibt, das bzw. die so trainiert und konfiguriert ist bzw. sind, dass es bzw. sie basierend auf den Ausgaben des primären Computers und des sekundären Computers die Bedingungen bestimmt bzw. bestimmen, unter denen der sekundäre Computer Fehlalarme auslöst. So kann das neuronale Netz bzw. können die neuronalen Netze in der Überwachungs-MCU lernen, wann der Ausgabe 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 Netz in der übergeordneten 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. Wenn der Sekundärcomputer ein kamerabasiertes Spurhaltewarnsystem ist, kann ein neuronales Netz in der Überwachungs-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, in denen ein neuronales Netz bzw. neuronale Netze auf der überwachenden MCU laufen, kann die überwachende MCU mindestens eine DLA oder eine GPU enthalten, die für den Betrieb des neuronalen Netzes bzw. der neuronalen Netze mit zugehörigem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente des/der SoC(s) 804 umfassen und/oder darin enthalten sein.
  • In anderen Beispielen kann das ADAS-System 838 einen sekundären Computer umfassen, der die ADAS-Funktionen unter Verwendung herkömmlicher Regeln der Computervision ausführt. Der sekundäre Computer kann also klassische Regeln der Computervision verwenden (wenn-dann), und das Vorhandensein eines neuronalen Netzes in der übergeordneten MCU kann 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 Hardware des Primärcomputers keinen wesentlichen Fehler verursacht.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 838 in den Wahrnehmungsblock des Primärrechners und/oder in den Block für dynamische Fahraufgaben des Primärrechners eingespeist werden. Wenn das ADAS-System 838 beispielsweise eine Warnung vor einem Aufprall aufgrund eines unmittelbar vorausfahrenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der Sekundärcomputer über ein eigenes neuronales Netz verfügen, das trainiert ist und somit das Risiko von Fehlalarmen reduziert, wie hierin beschrieben.
  • Das Fahrzeug 800 kann ferner das Infotainment-SoC 830 (z. B. ein bordeigenes Infotainment-System (IVI)) enthalten. Obwohl das Infotainment-System als SoC dargestellt und beschrieben wird, muss es nicht unbedingt ein SoC sein, sondern kann auch zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 830 kann eine Kombination aus Hardware und Software enthalten, die zur Bereitstellung von Audio (z. B. Musik, einem persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. Fernsehen, 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.) an das Fahrzeug 800. Der Infotainment-SoC 830 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, ein Heads-up-Display (HUD), ein HMI-Display 834, ein Telematikgerät, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten enthalten. Der Infotainment-SoC 830 kann ferner verwendet werden, um einem oder mehreren Nutzern des Fahrzeugs Informationen (z. B. visuell und/oder akustisch) bereitzustellen, wie etwa Informationen vom ADAS-System 838, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Der Infotainment-SoC 830 kann eine GPU-Funktionalität enthalten. Der Infotainment-SoC 830 kann über den Bus 802 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 800 kommunizieren. In einigen Beispielen kann der Infotainment-SoC 830 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls der (die) primäre(n) Controller 836 (z. B. die primären und/oder Backup-Computer des Fahrzeugs 800) ausfallen. In einem solchen Beispiel kann der Infotainment-SoC 830 das Fahrzeug 800, wie hierin beschrieben, in einen Chauffeurmodus bis zum sicheren Anhalten versetzen.
  • Das Fahrzeug 800 kann ferner ein Kombiinstrument 832 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) enthalten. Das Kombiinstrument 832 kann einen Controller und/oder einen Supercomputer (z. B. ein diskreter Controller oder einen Supercomputer) enthalten. Das Kombiinstrument 832 kann eine Reihe von Instrumenten enthalten, z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Parkbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über das Airbag-System (SRS), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können die Informationen vom Infotainment-SoC 830 und dem Kombiinstrument 832 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 832 kann Teil des Infotainment-SoC 830 sein oder umgekehrt.
  • 8D ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhafte autonome Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenlegung. Das System 876 kann den/die Server 878, das/die Netzwerk(e) 890 und die Fahrzeuge, einschließlich des Fahrzeugs 800, umfassen. Der (die) Server 878 kann (können) eine Vielzahl von GPUs 884(A)-884(H) (hier zusammenfassend als GPUs 884 bezeichnet), PCIe-Switches 882(A)-882(H) (hier zusammenfassend als PCIe-Switches 882 bezeichnet) und/oder CPUs 880(A)-880(B) (hier zusammenfassend als CPUs 880 bezeichnet) umfassen. Die GPUs 884, die CPUs 880 und die PCIe-Switches können über Hochgeschwindigkeitsverbindungen miteinander verbunden werden, wie z. B. und ohne Einschränkung über die von NVIDIA entwickelten NVLink-Schnittstellen 888 und/oder PCIe-Verbindungen 886. In einigen Beispielen sind die GPUs 884 über NVLink und/oder NVSwitch SoC und die GPUs 884 und die PCIe-Switches 882 über PCIe-Interconnects verbunden. Obwohl acht GPUs 884, zwei CPUs 880 und zwei PCIe-Switches abgebildet sind, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsform kann jeder der Server 878 eine beliebige Anzahl von GPUs 884, CPUs 880 und/oder PCIe-Switches umfassen. Beispielsweise kann jeder der Server 878 acht, sechzehn, zweiunddreißig und/oder mehr GPUs 884 enthalten.
  • Der (die) Server 878 kann (können) über das (die) Netzwerk(e) 890 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, z. B. kürzlich begonnene Straßenarbeiten. Der (die) Server 878 kann (können) über das (die) Netzwerk(e) 890 und an die Fahrzeuge neuronale Netze 892, aktualisierte neuronale Netze 892 und/oder Karteninformationen 894, einschließlich Informationen über Verkehrs- und Straßenbedingungen, übertragen. Die Aktualisierungen der Karteninformationen 894 können Aktualisierungen für die HD-Karte 822 enthalten, z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netze 892, die aktualisierten neuronalen Netze 892 und/oder die Karteninformationen 894 aus neuem Training und/oder Erfahrungen resultieren, die in Daten dargestellt sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf einem Training basieren, das in einem Datenzentrum durchgeführt wurde (z. B. unter Verwendung des/der Server(s) 878 und/oder anderer Server).
  • Der/die Server 878 kann/können verwendet werden, um Modelle für maschinelles Lernen (z. B. neuronale Netze) basierend auf von Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen und/oder in einer Simulation (z. B. mit einer Spiel-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder anderen Vorverarbeitungen unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netz kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken durchgeführt werden, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, selbstlernendes Lernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlemen, vielfältiges Lernen, Repräsentationslernen (einschließlich Lernen mit Ersatzwörterbüchern), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. durch Übertragung an die Fahrzeuge über das/die Netzwerk(e) 890 und/oder die maschinellen Lernmodelle können von dem/den Server(n) 878 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen können die Server 878 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netze in Echtzeit für intelligente Schlussfolgerungen in Echtzeit anwenden. Der/die Server 878 kann/können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPUs 884 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können die Server 878 jedoch auch Deep-Learning-Infrastrukturen enthalten, die nur CPU-betriebene Rechenzentren verwenden.
  • Die Deep-Learning-Infrastruktur des/der Server(s) 878 kann zur schnellen Inferenz in Echtzeit fähig sein und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 800 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen vom Fahrzeug 800 erhalten, wie etwa eine Bildsequenz und/oder Objekte, die das Fahrzeug 800 in dieser Bildsequenz lokalisiert hat (z. B. über Computervision und/oder andere maschinelle Objektklassifizierungstechniken). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz laufen lassen, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 800 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 800 eine Fehlfunktion aufweist, kann der/die Server 878 ein Signal an das Fahrzeug 800 senden, das einen ausfallsicheren Computer des Fahrzeugs 800 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Für die Inferenzerstellung kann der/die Server 878 die GPU(s) 884 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) enthalten. Die Kombination von GPU-gesteuerten Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, in denen die Leistung weniger kritisch ist, können Server mit CPUs, FPGAs und anderen Prozessoren für die Inferenzbildung verwendet werden.
  • Beispielhafte Rechenvorrichtung
  • 9 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung 900, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 900 kann ein Interconnect-System 902 enthalten, das direkt oder indirekt die folgenden Vorrichtungen koppelt: Speicher 904, eine oder mehrere Zentraleinheiten (CPUs) 906, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 908, eine Kommunikationsschnittstelle 910, Eingangs-/Ausgangs- (I/O) Anschlüsse 912, Eingabe-/Ausgabekomponenten 914, eine Stromversorgung 916, eine oder mehrere Präsentationskomponenten 918 (z. B. Display(s)) und eine oder mehrere Logikeinheiten 920. In mindestens einer Ausführungsform kann das (die) Computergerät(e) 900 eine oder mehrere virtuelle Maschinen (VMs) umfassen und/oder jede der Komponenten davon kann virtuelle Komponenten (z. B. virtuelle Hardwarekomponenten) umfassen. Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 908 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 906 können eine oder mehrere vCPUs umfassen, und/oder eine oder mehrere der Logikeinheiten 920 können eine oder mehrere virtuelle Logikeinheiten umfassen. So kann eine Rechenvorrichtung 900 diskrete Komponenten (z. B. eine vollständige GPU, die der Rechenvorrichtung 900 zugeordnet ist), virtuelle Komponenten (z. B. einen Teil einer GPU, die der Rechenvorrichtung 900 zugeordnet ist) oder eine Kombination davon umfassen.
  • Obwohl die verschiedenen Blöcke in 9 als über das Interconnect-System 902 mit Leitungen verbunden dargestellt sind, ist dies nicht als Einschränkung gedacht und dient nur der Klarheit. In einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente 918, wie z. B. ein Anzeigegerät, als I/O-Komponente 914 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 906 und/oder GPUs 908 Speicher enthalten (z. B. kann der Speicher 904 zusätzlich zum Speicher der GPUs 908, der CPUs 906 und/oder anderer Komponenten eine Speichereinrichtung darstellen). Mit anderen Worten, die Rechnereinrichtung der 9 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „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 der 9 fallen.
  • Das Interconnect-System 902 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Interconnect-System 902 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. Zum Beispiel kann die CPU 906 direkt mit dem Speicher 904 verbunden sein. Ferner kann die CPU 906 direkt mit der GPU 908 verbunden sein. Bei einer direkten oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann das Interconnect-System 902 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen muss ein PCI-Bus nicht in das Computergerät 900 integriert sein.
  • Der Speicher 904 kann aus einer Vielzahl von computerlesbaren Medien bestehen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Computergerät 900 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie austauschbare und nicht-entfernbare Medien umfassen. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 904 computerlesbare Anweisungen speichern (z. B. solche, die ein Programm bzw. Programme und/oder ein Programmelement bzw. Programmelemente darstellen, wie z. B. ein Betriebssystem. Zu den Computerspeichermedien können unter anderem 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 gehören, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das die Rechenvorrichtung 900 zugreifen kann. Der hier verwendete Begriff „Computerspeichermedium“ umfasst nicht per se Signale.
  • Die Computerspeichermedien können computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert sind, dass Informationen in dem Signal kodiert werden. Die Computerspeichermedien können beispielsweise verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine direkte Kabelverbindung, und drahtlose Medien, wie akustische, RF-, Infrarot- und andere drahtlose Medien, umfassen. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der computerlesbaren Medien fallen.
  • Die CPU(s) 906 kann/können so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern und eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 906 kann/können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 906 kann/können jede Art von Prozessor umfassen und je nach Art des implementierten Computergeräts 900 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 des Rechengeräts 900 kann der Prozessor zum Beispiel 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 Recheneinheit 900 kann eine oder mehrere CPUs 906 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie z. B. mathematischen Coprozessoren, enthalten.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 906 kann/können die GPU(s) 908 so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 908 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 906 und/oder eine oder mehrere der GPU(s) 908 können eine diskrete GPU sein. In Ausführungsformen kann eine oder mehrere der GPU(s) 908 ein Coprozessor einer oder mehrerer der CPU(s) 906 sein. Der/die Grafikprozessor(en) 908 kann/können von der Rechenvorrichtung 900 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder zur Durchführung von allgemeinen Berechnungen verwendet werden. Die GPU(s) 908 kann/können zum Beispiel für General-Purpose Computing on GPUs (GPGPU) verwendet werden. Die GPU(s) 908 kann/können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 908 kann/können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 906, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 908 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, z. B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 904 enthalten sein. Die GPU(s) 908 können zwei oder mehr GPUs umfassen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. mit NVLINK) oder die GPUs über einen Switch verbinden (z. B. mit NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 908 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 haben oder sich den Speicher mit anderen GPUs teilen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 906 und/oder der (den) GPU(s) 908 kann (können) die Logikeinheit(en) 920 so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 906, die GPU(s) 908 und/oder die Logikeinheit(en) 920 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 920 können Teil einer oder mehrerer der CPU(s) 906 und/oder der GPU(s) 908 sein und/oder eine oder mehrere der Logikeinheiten 920 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 906 und/oder der GPU(s) 908 liegen. In Ausführungsformen kann eine oder mehrere der Logikeinheiten 920 ein Coprozessor einer oder mehrerer der CPU(s) 906 und/oder einer oder mehrerer der GPU(s) 908 sein.
  • Beispiele für die logische(n) Einheit(en) 920 umfassen einen oder mehrere Rechenkerne und/oder Komponenten davon, wie Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Eingabe-/Ausgabe-Elemente (I/O), Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 910 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es dem Computergerät 900 ermöglichen, mit anderen Computergeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 910 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.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
  • Über die I/O-Anschlüsse 912 kann das Computergerät 900 logisch mit anderen Geräten gekoppelt werden, einschließlich der I/O-Komponenten 914, der Präsentationskomponente(n) 918 und/oder anderer Komponenten, von denen einige in das Computergerät 900 eingebaut (z. B. integriert) sein können. Illustrative I/O-Komponenten 914 umfassen 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 I/O-Komponenten 914 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten ausführlicher beschrieben) in Verbindung mit einer Anzeige des Computergeräts 900 implementieren. Das Computergerät 900 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung enthalten. Darüber hinaus kann das Computergerät 900 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die die Erkennung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Computervorrichtung 900 verwendet werden, um immersive erweiterter Realität oder Virtual Reality darzustellen.
  • Die Stromversorgung 916 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon sein. Die Stromversorgung 916 kann das Computergerät 900 mit Strom versorgen, um den Betrieb der Komponenten des Computergeräts 900 zu ermöglichen.
  • Die Präsentationskomponente(n) 918 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 918 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 908, der/den CPU(s) 906 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
  • Beispielhaftes Datenzentrum
  • 10 zeigt ein beispielhaftes Datenzentrum 1000, das in mindestens einer Ausführungsform der vorliegenden Offenlegung verwendet werden kann. Das Datenzentrum 1000 kann eine Datenzentrum-Infrastrukturschicht 1010, eine Framework-Schicht 1020, eine Softwareschicht 1030 und/oder eine Anwendungsschicht 1040 umfassen.
  • Wie in 10 dargestellt, kann die Infrastrukturschicht 1010 des Datenzentrums einen Ressourcen-Orchestrator 1012, gruppierte Rechenressourcen 1014 und Knotenrechenressourcen („Knoten-C.R.s“) 1016(1)-1016(N) umfassen, wobei „N“ eine beliebige ganze, positive Zahl darstellt. In mindestens einer Ausführungsform können die Knoten-CRs 1016(1)-1016(N) eine beliebige Anzahl von Zentraleinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichergeräten (z. B., dynamischer Festwertspeicher), Speichergeräte (z. B. Festkörper- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabegeräte („NW I/O“), Netzwerk-Switches, virtuelle Maschinen („VMs“), Stromversorgungsmodule und/oder Kühlmodule, usw. In einigen Ausführungsformen können ein oder mehrere Knoten-C.R.s unter den Knoten-CRs 1016(1)-1016(N) einem Server entsprechen, der über eine oder mehrere der oben erwähnten Rechenressourcen verfügt. Darüber hinaus können in einigen Ausführungsformen die Knoten C.R.s 1016(1)-10161(N) eine oder mehrere virtuelle Komponenten enthalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 1016(1)-1016(N) können einer virtuellen Maschine (VM) entsprechen.
  • In mindestens einer Ausführungsform können die gruppierten Rechenressourcen 1014 separate Gruppierungen von Knoten-CRs 1016 umfassen, die in einem oder mehreren Racks (nicht dargestellt) oder in vielen Racks in Datenzentren an verschiedenen geografischen Standorten (ebenfalls nicht dargestellt) untergebracht sind. Separate Gruppierungen von Knoten-CRs 1016 innerhalb der gruppierten Rechenressourcen 1014 können gruppierte Rechen-, Netzwerk-, Speicher- oder Speicherressourcen umfassen, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen werden können. In mindestens einer Ausführungsform können mehrere Knoten-CRs 1016 einschließlich CPUs, GPUs und/oder anderer Prozessoren in einem oder mehreren Racks gruppiert werden, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Das eine oder die mehreren Racks können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk-Switches in beliebiger Kombination enthalten.
  • Der Ressourcen-Orchestrator 1022 kann einen oder mehrere Knoten-CRs 1016(1)-1016(N) und/oder gruppierte Rechenressourcen 1014 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1022 eine Software-Design-Infrastruktur („SDI“)-Managementeinheit für das Datenzentrum 1000 umfassen. Der Ressourcen-Orchestrator 1022 kann Hardware, Software oder eine Kombination davon umfassen.
  • In mindestens einer Ausführungsform, wie in 10 gezeigt, kann die Framework-Schicht 1020 einen Job Scheduler 1048, einen Konfigurationsmanager 1034, einen Ressourcenmanager 1036 und/oder ein verteiltes Dateisystem 1038 enthalten. Die Framework-Schicht 1020 kann einen Rahmen zur Unterstützung der Software 1048 der Softwareschicht 1030 und/oder einer oder mehrerer Anwendungen 1042 der Anwendungsschicht 1040 enthalten. Die Software 1048 bzw. die Anwendung(en) 1042 kann/können webbasierte Dienstsoftware oder Anwendungen umfassen, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Bei der Framework-Schicht 1020 kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework wie Apache Spark™ (im Folgenden „Spark“) handeln, das ein verteiltes Dateisystem 1038 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) nutzen kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Job Scheduler 1032 einen Spark-Treiber enthalten, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Datenzentrums 1000 unterstützt werden. Der Konfigurationsmanager 1034 kann in der Lage sein, verschiedene Schichten wie die Softwareschicht 1030 und die Framework-Schicht 1020 einschließlich Spark und das verteilte Dateisystem 1038 zu konfigurieren, um die Verarbeitung großer Datenmengen zu unterstützen. Der Ressourcenmanager 1036 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1038 und des Job Schedulers 1032 zugeordnet sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen gruppierte Rechenressourcen 1014 auf der Infrastrukturschicht 1010 des Datenzentrums umfassen. Der Ressourcenmanager 1036 kann sich mit dem Ressourcen-Orchestrator 1012 abstimmen, um diese zugeordneten oder zugewiesenen Computerressourcen zu verwalten.
  • In mindestens einer Ausführungsform kann die in der Softwareschicht 1030 enthaltene Software 1032 Software enthalten, die von mindestens Teilen der Knoten C.R.s 1016(1)-1016(N), der gruppierten Rechenressourcen 1014 und/oder des verteilten Dateisystems 1038 der Framework-Schicht 1020 verwendet wird. Eine oder mehrere Arten von Software können u. a. Internet-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Software für Streaming-Videoinhalte umfassen.
  • In mindestens einer Ausführungsform kann (können) die in der Anwendungsschicht 1040 enthaltene(n) Anwendung(en) 1042 eine oder mehrere Arten von Anwendungen umfassen, die von mindestens Teilen der Knoten C.R.s 1016(1)-1016(N), gruppierten Rechenressourcen 1014 und/oder dem verteilten Dateisystem 1038 der Framework-Schicht 1020 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl von Genomanwendungen, kognitiven Berechnungen und Anwendungen für maschinelles Lernen umfassen, einschließlich Trainings- oder Inferenzsoftware, Framework-Software für maschinelles Lernen (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere Anwendungen für maschinelles Lernen, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden, sind jedoch nicht darauf beschränkt.
  • In mindestens einer Ausführungsform können der Konfigurationsmanager 1034, der Ressourcenmanager 1036 und der Ressourcen-Orchestrator 1012 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren, die auf einer beliebigen Menge und Art von Daten basieren, die auf jede technisch mögliche Weise erfasst wurden. Selbstmodifizierende Aktionen können einen Datenzentrumsbetreiber des Datenzentrums 1000 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Teile eines Datenzentrums zu vermeiden.
  • Das Datenzentrum 1000 kann Werkzeuge, Dienste, Software oder andere Ressourcen enthalten, um ein oder mehrere maschinelle Lernmodelle zu trainieren oder Informationen unter Verwendung eines oder mehrerer maschineller Lernmodelle gemäß einer oder mehrerer hierin beschriebener Ausführungsformen vorherzusagen oder abzuleiten. Beispielsweise kann ein maschinelles Lernmodell bzw. können maschinelle Lernmodelle trainiert werden, indem Gewichtsparameter gemäß einer neuronalen Netzwerkarchitektur unter Verwendung von Software und/oder Computerressourcen berechnet werden, die oben in Bezug auf das Datenzentrum 1000 beschrieben wurden. In mindestens einer Ausführungsform können trainierte oder eingesetzte maschinelle Lernmodelle, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen abzuleiten oder vorherzusagen, wobei die oben beschriebenen Ressourcen in Bezug auf das Datenzentrum 1000 verwendet werden, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere Trainingstechniken berechnet werden, wie zum Beispiel, aber nicht beschränkt auf die hierin beschriebenen.
  • In mindestens einer Ausführungsform kann das Datenzentrum 1000 CPUs, anwendungsspezifische integrierte Schaltkreise (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenz mit den oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, um Benutzern das Training oder die Inferenz von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
  • Beispielhafte Netzwerkumgebungen
  • Netzwerkumgebungen, die zur Verwendung bei der Implementierung von Ausführungsformen der Offenlegung geeignet sind, können ein oder mehrere Client-Vorrichtunge, Server, Network Attached Storage (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Die Client-Vorrichtunge, Server und/oder anderen Gerätetypen (z. B. jedes Gerät) können auf einer oder mehreren Instanzen des/der Computergeräts/e 900 der 9 implementiert werden - z. B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität des/der Computergeräts/e 900 enthalten. Wenn Backend-Geräte (z. B. Server, NAS usw.) implementiert sind, können die Backend-Geräte außerdem Teil eines Datenzentrums 1000 sein, dessen Beispiel hier in Bezug auf 10 näher beschrieben wird.
  • Die Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netz kann mehrere Netze oder ein Netz von Netzen umfassen. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netz ein drahtloses Telekommunikationsnetz umfasst, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bieten.
  • Zu den kompatiblen Netzwerkumgebungen gehören eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in eine Netzwerkumgebung eingebunden sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in eine Netzwerkumgebung eingebunden sein. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert werden.
  • In mindestens einer Ausführungsform kann eine Netzumgebung eine oder mehrere Cloud-basierte Netzumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem umfassen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann einen Rahmen zur Unterstützung von Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht umfassen. Die Software oder die Anwendung(en) können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen. In Ausführungsformen können ein oder mehrere Client-Vorrichtunge die webbasierte Dienstsoftware oder Anwendungen nutzen (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Framework-Schicht kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework handeln, das beispielsweise ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwendet, ohne darauf beschränkt zu sein.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kernservern (z. B. von einem oder mehreren Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Benutzer (z. B. einem Client-Vorrichtung) relativ nahe an einem oder mehreren Edge-Servern, kann ein Kernserver mindestens einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
  • Die Client-Vorrichtung(en) kann (können) mindestens einige der Komponenten, Merkmale und Funktionen des (der) hier in Bezug auf 9 beschriebenen beispielhaften Rechenvorrichtung (-geräte) 900 enthalten. Beispielhaft und ohne Einschränkung kann ein Client-Vorrichtung ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, ein fliegendes Schiff, eine virtuelle Maschine ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, ein eingebettetes Systemsteuergerät, eine Fernbedienung, ein Gerät, ein Unterhaltungselektronikgerät, eine Workstation, ein Randgerät, eine beliebige Kombination dieser beschriebenen Geräte oder ein anderes geeignetes Gerät.
  • Die Offenlegung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich von computerausführbaren Anweisungen wie Programmmodulen, beschrieben werden, die von einem Computer oder einer anderen Maschine, z. B. einem persönlichen Datenassistenten oder einem anderen Handheld-Gerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen angewendet werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Datenverarbeitungsgeräten usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewendet werden, in denen Aufgaben von ferngesteuerten Geräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind.
  • Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, sollte dies so verstanden werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. So kann beispielsweise „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 umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B einschließen.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer Genauigkeit beschrieben, die den gesetzlichen Anforderungen entspricht. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschrä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 umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der angewandten Methoden zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich 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 16101232 [0111]

Claims (20)

  1. Verfahren, das aufweist: Erfassen einer Abschaltanzeige, die einer Maschine entspricht; Durchführen von Diagnosen auf einem Computersystem, das verwendet wird, um eine oder mehrere autonome Steuerungsoperationen der Maschine auszuführen, mindestens basierend auf dem Erfassen einer Abschaltanzeige; Rebooten eines oder mehrerer Teile des Computersystems mindestens basierend auf dem Durchführen der Diagnose; Speichern, als gesicherten Zustand und basierend mindestens auf dem Rebooten, eines Zustands einer Rechenumgebung, die dem Computersystem entspricht, in einem Computerspeicher und; Eintreten in einen Niederenergiemodus mindestens basierend auf dem Speichern des Zustands der Rechenumgebung; Erfassen einer Einschaltanzeige, die einer Maschine entspricht; Verlassen des Niederenergiemodus mindestens basierend auf dem Erfassen der Einschaltanzeige; und Wiederherstellen des Zustands der Rechenumgebung, die dem Computersystem entspricht, auf den gesicherten Zustand aus dem Computerspeicher, der mindestens auf dem Verlassen des Niederenergiemodus basiert.
  2. Verfahren nach Anspruch 1, das ferner das Rebooten des einen oder der mehreren Teile des Computersystems vor dem Durchführen der Diagnose mindestens basierend auf dem Erfassen der Abschaltanzeige der Maschine aufweist.
  3. Verfahren nach Anspruch 1 oder 2, wobei der Zustand der Rechenumgebung ein erster Zustand ist, und das Verfahren ferner aufweist: Verlassen des Niederenergiemodus vor der Einschaltanzeige basierend auf mindestens einem oder mehreren Kriterien, die erfüllt werden; erneutes Durchführen der Diagnose auf dem Computersystem; Rebooten des Computersystems, um einen zweiten Zustand der Rechenumgebung zu erzeugen; Speichern des zweiten Zustands der Rechenumgebung im Computerspeicher als einen zweiten gesicherten Zustand; und erneutes Eintreten in den Niederenergiemodus, wobei das Wiederherstellen des Zustands der Rechenumgebung das Wiederherstellen des Zustands der Rechenumgebung, die dem Computersystem entspricht, auf den zweiten Zustand aufweist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Computerspeicher einen flüchtigen Speicher aufweist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Maschine ein Energiespeichermedium aufweist, um das Computersystem mit elektrischer Energie zu versorgen, wobei die Maschine mindestens eines ist von: einer mindestens teilweise elektrisch betriebenen Maschine; oder einer mindestens teilweise verbrennungsmotorisch betriebenen Maschine.
  6. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Maschine einen oder mehrere Sensoren aufweist, wobei der Niederenergiemodus dadurch gekennzeichnet ist, dass mindestens ein Sensor des einen oder der mehreren Sensoren keinen Strom erhält.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Maschine eine Grafikverarbeitungseinheit aufweist, die verwendet wird, um zur die autonomen Steueroperationen auszuführen, wobei der Niederenergiemodus dadurch gekennzeichnet ist, dass die Grafikverarbeitungseinheit keinen Strom erhält.
  8. Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens eines des Durchführens der Diagnose, des Rebootens, des Eintretens in den Niederenergiemodus, des Verlassens des Niederenergiemodus oder des Aktivierens der autonomen Steueroperationen mindestens teilweise von einem Controller durchgeführt wird, der Steuersignale erzeugt, die verwendet werden, um die autonomen Steueroperationen zu bewirken.
  9. Verfahren nach Anspruch 8, wobei der Controller eine Schaltung aufweist, die während des Niederenergiemodus eingeschaltet bleibt, um das System-on-Chip aus dem Niederenergiemodus aufzuwecken.
  10. Prozessor, der aufweist: einen oder mehrere Schaltkreise, um: eine Abschaltanzeige eines Fahrzeugs zu erkennen; ein Computersystem für die autonome Steuerung des Fahrzeugs anzuweisen, Diagnosen durchzuführen; das Computersystems zu triggern zu rebooten, um das Computersystem zu einem Rechenzustand zu konfigurieren und den Rechenzustand in einem Computerspeicher als gesicherten Zustand zu speichern; einen Niederenergiemodus des Computersystems zu triggern, während der gesicherte Zustand in dem Computerspeicher gespeichert ist; und ein Verlassen des Niederenergiemodus mindestens basierend auf einer Einschaltanzeige des Fahrzeugs zu triggern, wobei das Triggern des Verlassens die autonome Steuerung des Fahrzeugs durch das Computersystem mindestens basierend auf dem gesicherten Zustand ermöglicht, der aus dem Computerspeicher wiederhergestellt wird.
  11. Prozessor nach Anspruch 10, wobei der Prozessor in mindestens einem enthalten ist von: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System, das unter Verwendung einer Edge-Vorrichtung realisiert wird; einem System, das unter Verwendung eines Roboters realisiert wird; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das mindestens teilweise in einem Datenzentrum implementiert ist; oder einem System, das mindestens teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
  12. Prozessor nach Anspruch 10 oder 11, wobei der eine oder die mehreren Schaltungen zu einer Mikrocontrollereinheit des Computersystems gehören.
  13. Prozessor nach einem der Ansprüche 10 bis 12, wobei der Rechenzustand ein erster Rechenzustand ist und die eine oder mehreren Schaltungen ferner konfiguriert sind: ein Verlassen des Niederenergiemodus vor der Anzeige zum Einschalten oder Hochfahren basierend auf mindestens einem oder mehreren erfüllten Kriterien zu triggern; das Computersystem anzuweisen, die Diagnose erneut auszuführen; das Computersystem zu triggern zu rebooten, um einen zweiten Rechenzustand zu erzeugen und den zweiten Rechenzustand im Computerspeicher als den gesicherten Zustand zu speichern; und einen Wiedereintritt in den Niederenergiemodus zu triggern, wobei der gesicherte Zustand, der für die Aktivierung der autonomen Steuerung wiederhergestellt wird, der zweite Rechenzustand ist.
  14. Prozessor nach einem der Ansprüche 10 bis 13, wobei die Diagnose eine Prüfung auf latente Fehler in einer oder mehreren Komponenten des Computersystems aufweist.
  15. Prozessor nach einem der Ansprüche 10 bis 14, wobei das Fahrzeug einen oder mehrere Sensoren aufweist, wobei der Niederenergiemodus dadurch gekennzeichnet ist, dass mindestens ein Sensor des einen oder der mehreren Sensoren keinen Strom erhält.
  16. System, das aufweist: eine oder mehrere Verarbeitungseinheiten eines Fahrzeugs; und eine oder mehrere Speichereinheiten, die Befehle speichern, die, wenn sie von der einen oder den mehreren Verarbeitungseinheiten ausgeführt werden, die eine oder die mehreren Verarbeitungseinheiten veranlassen, Operationen auszuführen, die aufweisen: Ausführen von systeminternen Tests eines Computersystems, das für die autonome Steuerung des Fahrzeugs verwendet wird, mindestens basierend auf einer ersten Anzeige eines Abschaltens der Zündung des Fahrzeugs; Konfigurieren des Computersystems zu einem Rechenzustand, der in der Lage ist, die autonome Steuerung mindestens basierend auf dem Abschluss der systeminternen Tests zu bewirken; Arbeiten in einem Niederenergiemodus, während der Rechenzustand im Computerspeicher als gesicherter Zustand gespeichert ist; Verlassen des Niederenergiemodus mindestens basierend auf einer zweiten Anzeige eines Einschaltens der Zündung des Fahrzeugs; und Aktivieren der autonomen Steuerung des Fahrzeugs durch das Computersystem mindestens basierend auf der Wiederherstellung des gesicherten Zustands aus dem Computerspeicher.
  17. System nach Anspruch 16, wobei das System aus mindestens einem der folgenden Elemente besteht: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System, das unter Verwendung einer Edge-Vorrichtung realisiert wird; einem System, das unter Verwendung eines Roboters realisiert wird; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das mindestens teilweise in einem Datenzentrum implementiert ist; oder einem System, das mindestens teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
  18. System nach Anspruch 16 oder 17, wobei die Operationen ferner das Rebooten eines oder mehrerer Teile des Computersystems vor dem Ausführen des systeminternen Tests basierend auf mindestens der ersten Anzeige eines Abschaltens der Zündung des Fahrzeugs aufweisen.
  19. System nach einem der Ansprüche 16 bis 18, wobei der Rechenzustand ein erster Rechenzustand ist und die Operationen ferner aufweisen: Verlassen des Niederenergiemodus vor der ersten Anzeige mindestens basierend auf einem oder mehreren erfüllten Kriterien; erneutes Ausführen des systeminternen Tests des Computersystems; und Konfigurieren des Computersystems, einen zweiten Rechenzustand zu erzeugen, wobei der gesicherte Zustand, der aus dem Computerspeicher wiederhergestellt wird, der zweite Zustand ist.
  20. System nach einem der Ansprüche 16 bis 19, das ferner aufweist: einen oder mehrere Sensoren, wobei der Niederenergiemodus dadurch gekennzeichnet ist, dass mindestens ein Sensor des einen oder der mehreren Sensoren keinen Strom erhält.
DE102022114511.5A 2021-06-28 2022-06-09 Ruhen des Zustands zur Optimierung von Hochfahrprozessen autonomer Fahrzeuge Pending DE102022114511A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/360,044 US11513814B1 (en) 2021-06-28 2021-06-28 State suspension for optimizing start-up processes of autonomous vehicles
US17/360,044 2021-06-28

Publications (1)

Publication Number Publication Date
DE102022114511A1 true DE102022114511A1 (de) 2022-12-29

Family

ID=84230768

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022114511.5A Pending DE102022114511A1 (de) 2021-06-28 2022-06-09 Ruhen des Zustands zur Optimierung von Hochfahrprozessen autonomer Fahrzeuge

Country Status (4)

Country Link
US (2) US11513814B1 (de)
JP (1) JP2023007396A (de)
CN (1) CN115599460A (de)
DE (1) DE102022114511A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023105294A1 (de) 2023-03-03 2024-09-05 Valeo Schalter Und Sensoren Gmbh Analysieren einer Umgebung eines Kraftfahrzeugs mittels Kameramodul

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11513814B1 (en) 2021-06-28 2022-11-29 Nvidia Corporation State suspension for optimizing start-up processes of autonomous vehicles
US20230109877A1 (en) * 2021-10-07 2023-04-13 Sygnal Technologies, Inc. Fail-Safe Signal Injection
US20230267774A1 (en) * 2022-02-21 2023-08-24 Cox Communications, Inc. Systems and methods for sending vehicle information and health data over a wireless network
US20240192965A1 (en) * 2022-12-13 2024-06-13 Ati Technologies Ulc Continuity of service for virtualized device after resumption from hibernation
US20240227825A1 (en) * 2023-01-10 2024-07-11 Qualcomm Incorporated Testing mixed safety systems

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5629609A (en) * 1994-03-08 1997-05-13 Texas Instruments Incorporated Method and apparatus for improving the drop-out voltage in a low drop out voltage regulator
US5877956A (en) * 1996-12-23 1999-03-02 Micron Electronics, Inc. System for burning in and diagnostically testing a computer
US7043416B1 (en) * 2001-07-27 2006-05-09 Lsi Logic Corporation System and method for state restoration in a diagnostic module for a high-speed microprocessor
US8423961B2 (en) * 2008-06-06 2013-04-16 Microsoft Corporation Simulating operations through out-of-process execution
US8626565B2 (en) * 2008-06-30 2014-01-07 Autonomous Solutions, Inc. Vehicle dispatching method and system
US9044863B2 (en) * 2013-02-06 2015-06-02 Steelcase Inc. Polarized enhanced confidentiality in mobile camera applications
JP6363462B2 (ja) * 2014-10-03 2018-07-25 シャープ株式会社 自律走行装置
US9946601B2 (en) * 2015-05-21 2018-04-17 Red Hat, Inc. User interface state saving and restoration
US9946890B2 (en) 2016-03-18 2018-04-17 Uber Technologies, Inc. Secure start system for an autonomous vehicle
US10412094B2 (en) * 2017-05-25 2019-09-10 GM Global Technology Operations LLC Privileged, diagnostic link connector based network monitoring capabilities within a vehicle employing a gateway module used to isolate and secure vehicle networks
US11126191B2 (en) * 2017-08-07 2021-09-21 Panasonic Intellectual Property Corporation Of America Control device and control method
US10845407B2 (en) * 2018-06-25 2020-11-24 Intel Corporation Scalable infield scan coverage for multi-chip module for functional safety mission application
US10885698B2 (en) 2018-08-10 2021-01-05 Nvidia Corporation Method for programmable timeouts of tree traversal mechanisms in hardware
US10916072B2 (en) 2019-05-13 2021-02-09 Gm Cruise Holdings Llc Self-maintaining autonomous vehicle procedure
JP7358959B2 (ja) * 2019-12-13 2023-10-11 トヨタ自動車株式会社 自動駐車システム
US20210181736A1 (en) * 2019-12-16 2021-06-17 Mastercard International Incorporated On demand autonomous vehicle application and service
US11514968B2 (en) * 2020-03-26 2022-11-29 Micron Technology, Inc. Charge leakage detection for memory system reliability
US11422825B2 (en) * 2020-12-30 2022-08-23 Kioxia Corporation Determination of power-off duration of NVMe SSD
US11513814B1 (en) 2021-06-28 2022-11-29 Nvidia Corporation State suspension for optimizing start-up processes of autonomous vehicles

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023105294A1 (de) 2023-03-03 2024-09-05 Valeo Schalter Und Sensoren Gmbh Analysieren einer Umgebung eines Kraftfahrzeugs mittels Kameramodul

Also Published As

Publication number Publication date
JP2023007396A (ja) 2023-01-18
US20230014569A1 (en) 2023-01-19
CN115599460A (zh) 2023-01-13
US11513814B1 (en) 2022-11-29
US12039343B2 (en) 2024-07-16

Similar Documents

Publication Publication Date Title
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE102021126648A1 (de) Imitationstraining mittels synthetischen daten
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE102021100065A1 (de) Verwendung neuronaler netze zur fehlererkennung bei anwendungen für autonomes fahren
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE112020001400T5 (de) Iterative erzeugung räumlicher graphen
DE102022114511A1 (de) Ruhen des Zustands zur Optimierung von Hochfahrprozessen autonomer Fahrzeuge
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
DE102022123130A1 (de) Trainieren von objekterkennungsmodellen unter verwendung von transferlernen
US11693470B2 (en) Voltage monitoring over multiple frequency ranges for autonomous machine applications
DE102022118649A1 (de) Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen
DE102020130749A1 (de) System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben
DE102022124361A1 (de) Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen
DE102021128559A1 (de) Sicherheitszerlegung zur pfadbestimmung in autonomen systemen
DE102022107848A1 (de) System und verfahren zur aktualisierung von karten mit hoher auflösung
DE102022129438A1 (de) Partikelbasierte Gefahrenerfassung für autonome Maschinenanwendungen
DE102023111579A1 (de) Objektverfolgung und zeit-bis-kollision-schätzung für autonome systeme und anwendungen
DE102022121021A1 (de) Bildsignalverarbeitungs-pipeline für sensoren für den hochdynamikbereich
DE102022117298A1 (de) Zusammenfügungsqualitätsbewertung für rundumsichtsysteme
DE102022101775A1 (de) Patching eingesetzt in tiefen neuronalen netzwerken für autonome maschinenanwendungen
DE102023128544A1 (de) Asynchrone in-system-tests für autonome systeme und anwendungen
DE102023124878A1 (de) Dialogsysteme unter verwendung von wissensbasen und sprachmodellen für kraftfahrzeugsysteme und -anwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed