DE102023132823A1 - Erkennen von hardwarefehlern in datenverarbeitungspipelines - Google Patents

Erkennen von hardwarefehlern in datenverarbeitungspipelines Download PDF

Info

Publication number
DE102023132823A1
DE102023132823A1 DE102023132823.9A DE102023132823A DE102023132823A1 DE 102023132823 A1 DE102023132823 A1 DE 102023132823A1 DE 102023132823 A DE102023132823 A DE 102023132823A DE 102023132823 A1 DE102023132823 A1 DE 102023132823A1
Authority
DE
Germany
Prior art keywords
error detection
blocks
data
block
circuit
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
DE102023132823.9A
Other languages
English (en)
Inventor
Rongzhe Zhu
Shangang Zhang
Nagaraju Balasubramanya
Jinyue Lu
Tinghai Miao
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 DE102023132823A1 publication Critical patent/DE102023132823A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Hardware Redundancy (AREA)

Abstract

In verschiedenen Beispielen umfasst ein System mindestens eine Schaltung, um zu erkennen, ob ein Fehler während der Durchführung einer Operation durch die mindestens eine Schaltung aufgetreten ist. In mindestens einer Ausführungsform erzeugt die mindestens eine Schaltung Fehlererkennungswerte und bestimmt, dass ein Fehler aufgetreten ist, wenn die Fehlererkennungswerte nicht mit vorherbestimmten Fehlererkennungsdaten übereinstimmen.

Description

  • GEBIET DER TECHNIK
  • Mindestens eine Ausführungsform betrifft eine Hardware-Diagnoseschaltung, die zum Erkennen von Hardwarefehlern in einem Zielsystem verwendet werden kann. Zum Beispiel beinhaltet mindestens eine Ausführungsform eine Hardware zur Erkennung von Fehlern in einer Datenverarbeitungseinheit eines System on a Chip, die verschiedene hierin beschriebene neue Techniken implementiert. Als weiteres Beispiel betrifft mindestens eine Ausführungsform ein autonomes Fahrzeug, das ein derartiges System auf einem Chip beinhaltet.
  • ALLGEMEINER STAND DER TECHNIK
  • Hardwarefehler können als vorübergehend oder permanent eingestuft werden. Vorübergehende Hardwarefehler beinhalten, dass ein oder mehrere Datenbits verfälscht (z. B. umgedreht) werden und können durch elektromagnetische Störungen veranlasst werden. Die Ursache von vorübergehenden Hardwarefehlern kann also temporär sein. Permanente Hardwarefehler hingegen können durch Hardwareprobleme veranlasst werden, die länger andauern oder sogar auf unbestimmte Zeit bestehen bleiben (z. B. bis zur Reparatur). Ein Beispiel für einen permanenten Hardwarefehler kann eine Kurzschluss oder eine offene Schaltung beinhalten, die einen Leiter (z. B. eine Leiterbahn, einen Draht, eine Übertragungsleitung und dergleichen) veranlasst, immer einen bestimmten logischen Signalwert (z. B. Eins oder Null) zu tragen. Hardwarefehler können sich in unerwünschten Resultaten äußern. Zum Beispiel kann ein Bit, das bei einem bestimmten Wert (z. B. Eins oder Null) hängen bleibt, durch einen permanenten Hardwarefehler veranlasst werden.
  • Funktionale Sicherheit ist ein Konzept, dessen Ziel es ist, ein unangemessenes Risiko aufgrund von Fehlern, die durch eine oder mehrere Fehlfunktionen eines Systems zur Laufzeit veranlasst werden, auszuschließen. Mit Operationen der funktionalen Sicherheit wird versucht, das Risiko von Schäden, die durch Fehler veranlasst werden können, auf ein tolerierbares oder akzeptables Level zu verringern. Zum Beispiel wurde die Fehlerkorrekturcodierung („ECC“) verwendet, um vorübergehende Fehler in der Datenspeicherung (z. B. im Speicher) zu erkennen, ist aber möglicherweise kein wirksames Verfahren zur Erkennung von Fehlern in der Verarbeitungslogik. Software-Diagnoseverfahren, die ein Zielsystem veranlassen, diagnostische Operationen durchzuführen, können dazu verwendet werden, einige, aber nicht alle vorübergehenden und permanenten Fehler in der Verarbeitungslogik zu erkennen. Das Durchführen solcher diagnostischen Operationen kann sich auch negativ auf die Leistung des Systems auswirken, da die Rechenressourcen für das Durchführen von diagnostische Operationen gebunden werden, anstatt funktionale Operationen durchzuführen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegenden Systeme und Verfahren zum ERKENNEN VON HARDWAREFEHLERN IN DATENVERARBEITUNGSPIPELINES werden nachstehend unter Bezugnahme auf die im Anhang befindlichen Figuren detailliert beschrieben, wobei Folgendes gilt:
    • 1 ist eine Veranschaulichung eines Blockdiagramms eines beispielhaften Systems, das Hardwarefehler innerhalb eines Verarbeitungssystems erkennt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 2 ist eine Veranschaulichung eines Blockdiagramms einer beispielhaften Verarbeitungspipeline, die durch einen oder mehrere Verarbeitungsblöcke des Verarbeitungssystems implementiert wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 3 ist eine Veranschaulichung eines Blockdiagramms von beispielhaften Komponenten, die in jedem der Verarbeitungsblöcke beinhaltet sein können, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 4 ist eine Illustration eines Schaltplans einer beispielhaften Schaltung, die verwendet wird, um zu veranschaulichen, wann ein Fehler strukturell und/oder arbeitslastbezogen beobachtbar ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 5 ist eine Veranschaulichung eines Schaltplans einer beispielhaften Schaltung, die zur Implementierung von Fehlererkennungsblöcken verwendet werden kann, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 6 ist eine Veranschaulichung eines Blockdiagramms von beispielhaften Anweisungen, die zur Implementierung von diagnostischen und funktionalen Aufgaben oder Operationen im Verarbeitungssystem verwendet werden können, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7 ist eine Veranschaulichung eines Ablaufdiagramms, das ein Verfahren zum Erkennen von Fehlern im Verarbeitungssystem zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8 ist eine Veranschaulichung eines Ablaufdiagramms zur Aufgabenkoordination, das einen der Verarbeitungsblöcke darstellt, der eine funktionale Operation durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 9 ist eine Veranschaulichung eines Ablaufdiagramms zur Aufgabenkoordination, das einen der Verarbeitungsblöcke darstellt, der eine diagnostische Operation durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 10A ist eine Veranschaulichung eines beispielhaften autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 10B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug aus 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 10C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug aus 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 10D ist ein Systemdiagramm für die Kommunikation zwischen (einem) Cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug aus 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung; und
    • 11 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.
  • DETAILLIERTE BESCHREIBUNG
  • 1 ist eine Veranschaulichung eines Blockdiagramms eines beispielhaften Systems 100, das Hardwarefehler innerhalb eines Verarbeitungssystems 102 erkennt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • In der in 1 veranschaulichten Ausführungsform beinhaltet das System 100 eine Systemsteuerung 104, die sowohl eine Sicherheitsüberwachung 106 als auch eine Anwendung 108 implementiert. Die Systemsteuerung 104 sendet eine oder mehrere Anweisungen 110, die von der Sicherheitsüberwachung 106 und/oder der Anwendung 108 erzeugt wurden, an das Verarbeitungssystem 102. Zum Beispiel kann/können die Anweisung(en) 110 eine von der Sicherheitsüberwachung 106 erzeugte Anweisung 110A beinhalten, die das Verarbeitungssystem 102 anweist, eine oder mehrere diagnostische Operationen durchzuführen. Die Anweisung 110A kann eine vorherbestimmte Eingabe 112 (z. B. Test- oder Diagnosedaten) oder Verweise auf einen oder mehrere Speicherstandorte beinhalten, von denen die vorherbestimmte Eingabe 112 erhalten werden kann. Das Verarbeitungssystem 102 verarbeitet die vorherbestimmte Eingabe 112 gemäß der/den in der Anweisung 110A identifizierten diagnostischen Operation(en). Als weiteres nicht einschränkendes Beispiel kann/können die Anweisung(en) 110 eine von der Anwendung 108 erzeugte Anweisung 110B beinhalten, die das Verarbeitungssystem 102 anweist, eine funktionale Operation (z. B. Analyse von Bilddaten) durchzuführen.
  • Die Systemsteuerung 104, die mindestens teilweise durch eine Schaltung implementiert sein kann, die eine oder mehrere Verbindungen zum Verarbeitungssystem 102, mindestens einen Prozessor und einen Speicher (z. B. ein nichttransitorisches, prozessorlesbares Medium) beinhaltet, der prozessorausführbare Anweisungen speichert, die von dem/den Prozessor(en) auszuführen sind. Die Sicherheitsüberwachung 106 und/oder die Anwendung 108 können durch prozessorausführbare Anweisungen (z. B. im Speicher der Systemsteuerung 104 gespeichert) implementiert werden, die von dem/den Prozessor(en) der Systemsteuerung 104 oder mindestens einem mit der Systemsteuerung 104 verbundenen Prozessor ausgeführt werden. Die Sicherheitsüberwachung 106 kann als Permanent Fault Software Diagnostic („PFSD“)-Softwareanwendung implementiert werden. So kann/können die diagnostische(n) Operation(en) eine oder mehrere PFSD-Aufgaben beinhalten und die vorherbestimmte Eingabe 112 kann aus PFSD-Daten bestehen. Die Anwendung 108 kann als eine oder mehrere Anwendungen implementiert werden, die mindestens ein fortgeschrittenes Fahrerassistenzsystem (Advanced Driver Assistance Systems - „ADAS“) in einem autonomen Fahrzeug mindestens teilweise implementiert. Zum Beispiel kann die funktionale Operation mindestens teilweise eine Pipeline für maschinelles Sehen implementieren und/oder betreiben, die Bilddaten verarbeitet, wie beispielsweise Bilddaten, die von einem Frontkamerasystem eines autonomen Fahrzeugs erfasst werden.
  • In der in 1 veranschaulichten Ausführungsform beinhaltet das System 100 ein Simulationssystem 114, das angewiesen werden kann, die Durchführung derselben in der Anweisung 110A identifizierten diagnostischen Operation(en) durch das Verarbeitungssystem 102 zu simulieren. Das Simulationssystem 114 simuliert die Durchführung der diagnostischen Operation(en), um erwartete oder vorherbestimmte Fehlererkennungswerte (als „goldene Referenzen“ 116 bezeichnet) zu erzeugen. Das Verarbeitungssystem 102 und das Simulationssystem 114 können getrennt und/oder zu unterschiedlichen Zeiten angewiesen werden, die diagnostische(n) Operation(en) durchzuführen. In mindestens einer Ausführungsform führt das Simulationssystem 114 die diagnostische(n) Operation(en) durch, bevor die diagnostische(n) Operation(en) von dem Verarbeitungssystem 102 durchgeführt wird/werden. Somit können die goldenen Referenzen dadurch gekennzeichnet sein, dass sie in Bezug auf die Durchführung der diagnostischen Operation(en) durch das Verarbeitungssystem 102 vorherbestimmt werden.
  • Das Simulationssystem 114 kann einen simulierten Prozess 122 implementieren, der das Verarbeitungssystem 102 und einen Fehlererkennungsprozess 120 simuliert. Der simulierte Prozess 122 kann eine Simulationsausgabe 118 erzeugen und der Fehlererkennungsprozess 120 kann die goldenen Referenzen 116 mindestens teilweise basierend auf der Simulationsausgabe 118 bestimmen. Der simulierte Prozess 122 kann bezogen auf das Verarbeitungssystem 102 offline ausgeführt werden. So kann der simulierte Prozess 122 die Durchführung der diagnostischen Operation(en) simulieren, die Simulationsausgabe 118 erzeugen (z. B. mindestens teilweise basierend auf der vorherbestimmten Eingabe 112) und die goldenen Referenzen 116 (z. B. unter Verwendung des Fehlererkennungsprozesses 120) mindestens teilweise basierend auf der Simulationsausgabe 118 bestimmen. Das Simulationssystem 114 kann durch prozessorausführbare Anweisungen implementiert werden, die auf einem nichttransitorischen computerlesbaren Medium gespeichert sind und von mindestens einem Prozessor eines Rechensystems ausgeführt werden.
  • Wie oben erwähnt, kann das Verarbeitungssystem 102 eine oder mehrere diagnostische Operationen gemäß der Anweisung 110A und/oder eine oder mehrere funktionale Operationen gemäß der Anweisung 110B durchführen. Das Verarbeitungssystem 102 beinhaltet einen oder mehrere Verarbeitungsblöcke 124, die jeweils einen oder mehrere Prozesse 126 implementieren, die jeweils eine Ausgabe erzeugen, indem sie mindestens einen Abschnitt der diagnostischen Operation(en) und/oder mindestens einen Abschnitt der funktionalen Operation(en) durchführen. Zum Beispiel können der/die Prozess(e) 126 des Verarbeitungsblocks/der Verarbeitungsblöcke 124 jeweils eine tatsächliche Ausgabe 128 erzeugen, indem sie mindestens einen Abschnitt einer oder mehrerer der in der Anweisung 110A identifizierten diagnostischen Operation(en) durchführen. Der/die Prozess(e) 126 stellt/stellen jeweils seine/ihre tatsächliche Ausgabe 128 einem Fehlererkennungsprozess 130 bereit, der einen oder mehrere tatsächliche Fehlererkennungswerte 132 mindestens teilweise basierend auf der tatsächlichen Ausgabe 128 bestimmt. Der Fehlererkennungsprozess 130 stellt den/die Fehlererkennungswert(e) 132 einem Vergleichsprozess 134 bereit, der ein Vergleichsergebnis 136 erhält, indem er eine der goldenen Referenzen 116 mit jedem der Fehlererkennungswert(e) 132 vergleicht. Das Verarbeitungssystem 102 bewertet das Vergleichsergebnis 136 und bestimmt, ob irgendwelche Fehler aufgetreten sind. Wenn das Verarbeitungssystem 102 bestimmt, dass ein Fehler aufgetreten ist, kann das Verarbeitungssystem 102 eine Fehlermeldung 138 erzeugen und die Fehlermeldung 138 an die Sicherheitsüberwachung 106 senden. Die Sicherheitsüberwachung 106 und/oder die Systemsteuerung 104 können nach dem Empfangen der Fehlermeldung 138 eine oder mehrere korrigierende Maßnahmen ergreifen.
  • Als weiteres Beispiel können der/die Prozess(e) 126 des Verarbeitungsblocks/der Verarbeitungsblöcke 124 jeweils eine funktionale Ausgabe (nicht gezeigt) erzeugen, indem sie mindestens einen Abschnitt einer oder mehrerer der in der Anweisung 110B identifizierten funktionalen Operation(en) durchführen. Das Verarbeitungssystem 102 kann möglicherweise jedoch nicht bestimmen, ob irgendwelche Fehler aufgetreten sind, wenn das Verarbeitungssystem 102 die funktionale(n) Operation(en) gemäß der Anweisung 110B durchführt. Daher kann das Verarbeitungssystem 102 den Fehlererkennungsprozess 130 deaktivieren, wenn das Verarbeitungssystem 102 die funktionale(n) Operation(en) durchführt. In solchen Ausführungsformen kann der Fehlererkennungsprozess 130 möglicherweise keine Fehlererkennungswerte für die funktionale Ausgabe bestimmen und der Vergleichsprozess 134 wird nicht verwendet, um ein Vergleichsergebnis zu erhalten. Somit kann das Verarbeitungssystem 102 möglicherweise nicht bestimmen, ob irgendwelche Fehler aufgetreten sind.
  • Die vorherbestimmte Eingabe 112, die dem Verarbeitungssystem 102 optional zusammen mit der Anweisung 110A zum Durchführen der diagnostischen Operation(en) zugeführt wird, kann in einem Speicher-Teilsystem 140 gespeichert werden. Das Speicher-Teilsystem 140 kann einen flüchtigen Speicher (z. B. einen dynamischen Direktzugriffsspeicher („DRAM“)) und/oder einen nichtflüchtigen Speicher beinhalten. Als nicht einschränkendes Beispiel kann das Verarbeitungssystem 102 als integrierte Schaltung implementiert sein, die optional die Systemsteuerung 104 und das Speicher-Teilsystem 140 beinhaltet. Die integrierte Schaltung kann auf einem oder mehreren Silicium-Substraten (z. B. Silicium-Chips) implementiert sein. Zum Beispiel können das Verarbeitungssystem 102, die Systemsteuerung 104 und das Speicher-Teilsystem 140 Komponenten eines System on a Chip („SoC“) 150 sein. Das SoC 150 kann in einer Zielvorrichtung oder einem Zielsystem installiert werden, wie beispielsweise einem autonomen Fahrzeug, einer elektrischen Vorrichtung (z. B. einem Laptop, einem Tablet, einem Mobiltelefon, einem Smartphone usw.), einer Robotervorrichtung und dergleichen.
  • Einer oder mehrere der Verarbeitungsblöcke 124 können verschiedene Arten von Operationen durchführen und/oder unterschiedliche Prozesse implementieren als mindestens ein anderer der Verarbeitungsblöcke 124. Der Verarbeitungsblock/die Verarbeitungsblöcke 124 kann/können homogen oder heterogen sein. In der veranschaulichten Ausführungsform ist/sind der Verarbeitungsblock/die Verarbeitungsblöcke 124 in verschiedenen Hardwareregionen des SoC 150 implementiert. In mindestens einer Ausführungsform können jedoch einer oder mehrere der Verarbeitungsblöcke 124 Hardwarekomponenten gemeinsam nutzen. Zum Beispiel können ein oder mehrere der Verarbeitungsblöcke 124 als Abschnitt eines getrennten SoCs implementiert werden.
  • 2 ist eine Veranschaulichung eines Blockdiagramms einer beispielhaften Verarbeitungspipeline 200, die durch einen oder mehrere Verarbeitungsblöcke 124 des Verarbeitungssystems 102 (siehe 1) implementiert wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. In der in 2 veranschaulichten Ausführungsform kann/können der Verarbeitungsblock/die Verarbeitungsblöcke 124 Verarbeitungsblöcke 202A-202F beinhalten, die als Implementierung einer Pipeline für maschinelles Sehen (z. B. für ein autonomes Fahrzeug) veranschaulicht wurden. In solchen Implementierungen können die Verarbeitungsblöcke 202A-202F einen Videoeingabe(Video Input - „VI“)-Block, einen Bildsensor-Prozessor(Image Sensor Processor - „ISP“)-Block, einen Videobildkompositor(Video Image Compositor - „VIC“)-Block, einen optischen Flussbeschleuniger(Optical Flow Accelerator - „OFA“)-Block, einen programmierbaren Sichtbeschleuniger(Programmable Vision Accelerator - „PVA“)-Block bzw. einen Deep-Learning-Beschleuniger(Deep Learning Accelerator - „DLA“)-Block implementieren. In alternativen Ausführungsformen kann/können der Verarbeitungsblock/die Verarbeitungsblöcke 124 andere Arten von Verarbeitungspipelines implementieren, die von autonomen Fahrzeugen und/oder anderen Arten von Vorrichtungen verwendet oder in diese integriert werden. Als nicht einschränkendes Beispiel kann einer oder mehrere der Verarbeitungsblöcke 124 als Hardware-Beschleuniger implementiert sein.
  • Die Anweisung(en) 110 (siehe 1) ist/sind in 2 als die Befehle 210-220 beinhaltend veranschaulicht worden. Wie in 2 gezeigt, kann eine Ausgabe von einem der Verarbeitungsblöcke 124 in einen anderen des Verarbeitungsblocks/der Verarbeitungsblöcke 124 eingegeben werden. In 2 sendet die Systemsteuerung 104 beispielsweise den Befehl 210 an den Verarbeitungsblock 202A, um die im Speicher-Teilsystem 140 gespeicherten Eingabedaten (z. B. die in 1 veranschaulichte vorherbestimmte Eingabe 112) zu verarbeiten. Der Verarbeitungsblock 202A erhält die Eingabedaten, verarbeitet sie und speichert Ausgabedaten (z. B. die in 1 veranschaulichte tatsächliche Ausgabe 128) im Speicher-Teilsystem 140. Der Verarbeitungsblock 202A kann auch der Systemsteuerung 104 mitteilen, dass der Verarbeitungsblock 202A die Verarbeitung der Eingabedaten abgeschlossen und die Ausgabedaten im Speicher-Teilsystem 140 gespeichert hat. Dann sendet die Systemsteuerung 104 den Befehl 212 an den Verarbeitungsblock 202B, um die vom Verarbeitungsblock 202A gespeicherten Ausgabedaten als Eingabedaten zu verarbeiten. Der Verarbeitungsblock 202B erhält die Eingabedaten, verarbeitet sie und speichert neue Ausgabedaten im Speicher-Teilsystem 140. Der Verarbeitungsblock 202B kann auch der Systemsteuerung 104 mitteilen, dass der Verarbeitungsblock 202B die Verarbeitung der Eingabedaten abgeschlossen und die neuen Ausgabedaten im Speicher-Teilsystem 140 gespeichert hat. Dieser Prozess wiederholt sich, indem die Systemsteuerung 104 die Befehle 214-220 an die Verarbeitungsblöcke 202C-202F sendet, die jeweils ihre jeweiligen Eingabedaten erhalten, diese verarbeiten, neue Ausgabedaten im Speicher-Teilsystem 140 speichern und optional der Systemsteuerung 104 mitteilen, dass die neuen Ausgabedaten im Speicher-Teilsystem 140 gespeichert wurden.
  • Jeder der Verarbeitungsblöcke 124 beinhaltet einen lokalen Prozessorblock 230, eine Datenverarbeitungseinheit (data processing unit - „DPU“) 232, einen lokalen Speicher 234 und einen Direktspeicherzugriffs(direct memory access - „DMA“)-Block 236. Der lokale Prozessorblock 230 interpretiert die von der Systemsteuerung 104 empfangenen Befehle (siehe 1-3, 5, 8 und 9) und steuert andere Blöcke (z. B. die DPU 232, den DMA-Block 236, den lokalen Speicher 234 und ähnliches) innerhalb seines Verarbeitungsblocks, um die durch diese Befehle festgelegten Operationen durchzuführen. Der lokale Prozessorblock 230 kann als eine Haupt-Zentralverarbeitungseinheit (central processing unit - „CPU“), einer oder mehrere Mikroprozessoren, eine oder mehrere Mikrosteuerungen, eine oder mehrere Grafikverarbeitungseinheiten (graphics processing units - „GPUs“), eine oder mehrere Datenverarbeitungseinheiten (data processing units - „DPUs“) und/oder dergleichen implementiert sein. Der lokale Speicher 234 kann flüchtigen Speicher (z. B. DRAM, statischer Direktzugriffsspeicher („SRAM“) und dergleichen) und/oder nichtflüchtigen Speicher beinhalten. Die DPU 232 und/oder der DMA-Block 236 können als eine oder mehrere Schaltungen implementiert sein.
  • Die Verarbeitungsblöcke 202A-202F verarbeiten jeweils eine oder mehrere Teiloperationen, wenn das Verarbeitungssystem 102 die diagnostische(n) Operation(en) und/oder die funktionale(n) Operation(en) durchführt, die in der/den Anweisung(en) 110 identifiziert wurde(n) (siehe 1). Zum Beispiel kann die DPU 232 jedes der Verarbeitungsblöcke 202A-202F (siehe 2) einen Prozess (z. B. mindestens einen Abschnitt einer funktionalen Operation) durchführen, der spezifisch für die Anwendung 108 ist (siehe 1, 8 und 9), wenn die Anweisung(en) 110 die Anweisung 110B beinhalten (siehe 1). Die DPU 232 jedes der Verarbeitungsblöcke 202A-202F (siehe 2) kann denselben Prozess durchführen (z. B. bezogen auf die in 1 veranschaulichte vorherbestimmte Eingabe 112), wenn die Anweisung(en) 110 die Anweisung 110A beinhalten (siehe 1).
  • 3 ist eine Veranschaulichung eines Blockdiagramms von beispielhaften Komponenten, die in jedem der Verarbeitungsblöcke 202A-202F (siehe 2) enthalten sein können, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Zur einfacheren Veranschaulichung wird 3 als die Komponenten des Verarbeitungsblocks 202A veranschaulichend beschrieben. Jeder der Verarbeitungsblöcke 124 kann jedoch im Wesentlichen identische Komponenten beinhalten wie die in 3 veranschaulichten.
  • Unter Bezugnahme auf 3 kann der lokale Prozessorblock 230 den Befehl 210 von der Systemsteuerung 104 empfangen. In diesem Beispiel leitet der Befehl 210 den Verarbeitungsblock 202A an, mindestens einen Abschnitt einer diagnostischen Operation durchzuführen, die erfordert, dass der Verarbeitungsblock 202A die im Speicher-Teilsystem 140 gespeicherten DPU-Eingabedaten 302 (z. B. die in 1 veranschaulichte vorherbestimmte Eingabe 112) verarbeitet. Als Reaktion auf den Befehl 210 kann der lokale Prozessorblock 230 den DMA-Block 236 anweisen, die DPU-Eingabedaten 302 aus dem Speicher-Teilsystem 140 abzurufen und die DPU-Eingabedaten 302 in einem Cache 304 im lokalen Speicher 234 zu speichern. Die DPU 232 verarbeitet die DPU-Eingabedaten 302 und produziert DPU-Ausgabedaten 306, die die DPU 232 in einem Puffer 308 im lokalen Speicher 234 speichert. Der lokale Prozessorblock 230 kann den DMA-Block 236 anweisen, die DPU-Ausgabedaten 306 aus dem Puffer 308 zu erhalten und die DPU-Ausgabedaten 306 im Speicher-Teilsystem 140 zu speichern. Optional kann der lokale Prozessorblock 230 die Systemsteuerung 104 informieren, dass der Verarbeitungsblock 202A die Verarbeitung der DPU-Eingabedaten 302 abgeschlossen und die DPU-Ausgabedaten 306 im Speicher-Teilsystem 140 gespeichert hat. Der Cache 304 und/oder der Puffer 308 können dazu beitragen, die mit dem Zugriff auf das Speicher-Teilsystem 140 verbundene Latenzzeit zu verringern.
  • Nun kann die Systemsteuerung 104 den Befehl 212 (siehe 2) an den Verarbeitungsblock 202B senden (siehe 2), der den lokalen Prozessorblock 230 des Verarbeitungsblocks 202B veranlassen kann, den DMA-Block 236 des Verarbeitungsblocks 202B anzuweisen, die DPU-Ausgabedaten 306 aus dem Speicher-Teilsystem 140 abzurufen und die DPU-Ausgabedaten 306 im Cache 304 im lokalen Speicher 234 des Verarbeitungsblocks 202B als die DPU-Eingabedaten 302 für den Verarbeitungsblock 202B zu speichern. Die DPU 232 des Verarbeitungsblocks 202B verarbeitet die DPU-Eingabedaten 302 und produziert neue DPU-Ausgabedaten 306, die die DPU 232 des Verarbeitungsblocks 202B im Puffer 308 im lokalen Speicher 234 des Verarbeitungsblocks 202B speichert. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202B kann den DMA-Block 236 des Verarbeitungsblocks 202B anweisen, die DPU-Ausgabedaten 306 aus dem Puffer 308 des Verarbeitungsblocks 202B zu erhalten und die DPU-Ausgabedaten 306 in dem Speicher-Teilsystem 140 zu speichern. Optional kann der lokale Prozessorblock 230 des Verarbeitungsblocks 202B die Systemsteuerung 104 informieren, dass der Verarbeitungsblock 202B die Verarbeitung seiner DPU-Eingabedaten 302 abgeschlossen und die neuen DPU-Ausgabedaten 306 im Speicher-Teilsystem 140 gespeichert hat. Nun kann die Systemsteuerung 104 den Befehl 214 (siehe 2) an den Verarbeitungsblock 202C (siehe 2) senden und so weiter, bis der Verarbeitungsblock 202F (siehe 2) die Verarbeitung seiner DPU-Eingabedaten 302 abgeschlossen und seine DPU-Ausgabedaten 306 im Speicher-Teilsystem 140 gespeichert hat. Mit anderen Worten wird dieser Prozess fortgesetzt, bis alle Verarbeitungsblöcke 202A-202F ihre jeweiligen DPU-Eingabedaten 302 verarbeitet haben.
  • Während der Verarbeitung ihrer jeweiligen DPU-Eingabedaten kann die Hardware der DPU 232 eines oder mehrerer der Verarbeitungsblöcke 202A-202F und/oder der mit der/den DPU(s) verbundenen Hardware potenziell einen oder mehrere Hardwarefehler erleiden. Funktionale Sicherheitsoperationen können verwendet werden, um das Risiko von Schäden, die durch solche Fehler potenziell veranlasst werden können, auf ein tolerierbares oder akzeptables Level zu verringern.
  • Solche funktionalen Sicherheitsoperationen können Operationen zum Erkennen von vorübergehenden Hardwarefehlern und/oder permanenten Hardwarefehlern beinhalten. Zum Beispiel können vorübergehende Hardwarefehler erkannt werden, indem ein Fehlererkennungscode(error detection code - „EDC“)-Schaltkreis verwendet wird, um EDCs zu erzeugen (z. B. Prüfbits, Fehlerkorrekturcodes (error correction codes - „ECC“) und dergleichen). Wenn es sich als nicht einschränkendes Beispiel bei einer durchgeführten Operation um eine Schreibanforderung zum Speichern von Daten im SRAM handelt, erzeugt ein Generatorblock innerhalb des EDC-Schaltkreises, der dazu positioniert ist, die Schreibanforderung zu empfangen, ein oder mehrere Prüfbits mindestens teilweise auf den Daten basierend. Der EDC-Schaltkreis kann das/die Prüfbit(s) und die Schreibanforderung an den SRAM weiterleiten, der das/die Prüfbit(s) zusammen mit den Daten speichert. Wenn der SRAM eine Leseanforderung für die Daten empfängt, ruft der SRAM das/die Prüfbit(s) und die Daten ab und sendet beide an einen Terminatorblock innerhalb des EDC-Schaltkreises. Der Terminatorblock verwendet das/die Prüfbit(s), um zu bestimmen, ob irgendwelche Bits der Daten verfälscht wurden. Optional kann der Terminatorblock das/die beschädigte(n) Bit(s) korrigieren, falls irgendwelche in den Daten vorliegen. Zum Beispiel kann der EDC-Schaltkreis Speicherparität, Speicherfehlerkorrekturcodes („ECC“) (auch als ECC-Speicher bezeichnet) und ähnliches implementieren.
  • Permanente Hardwarefehler können unter Verwendung von Software-Diagnoseverfahren erkannt werden, wie beispielsweise einem In-System Test („IST“)- und/oder einem Permanent Fault Software Diagnostic („PFSD“)-Verfahren. Im Gegensatz zu den EDC-Schaltkreisen, die vorübergehende Hardwarefehler durch die Verarbeitung von Funktionsdaten, die durch ein Zielsystem fließen, erkennen, veranlassen die Software-Diagnoseverfahren das Zielsystem, diagnostische Operationen durchzuführen (z. B. einen Verarbeitungstest, die Verarbeitung von Diagnosedaten und ähnliches). Somit können die Software-Diagnoseverfahren dadurch gekennzeichnet sein, dass sie im Zielsystem vorhandene Hardware in Anspruch nehmen.
  • Das PFSD-Verfahren gibt PFSD-Aufgaben aus, die mit funktionalen Operationen (z. B. aus der Anwendung 108 stammend) durchsetzt sein können. Zum Beispiel können die PFSD-Aufgaben so geplant werden, dass sie gelegentlich (z. B. periodisch) innerhalb eines fehlertoleranten Zeitintervalls (Fault Tolerant Time Interval - „FTTI“) durchgeführt werden. Das FTTI ist eine Zeitspanne, in der ein Fehler im Zielsystem vorliegen kann, bevor ein unerwünschtes Ereignis (z. B. eine Gefahr) eintritt. Eine PFSD-Aufgabe kann die Hardware des Zielsystems trainieren, indem sie die Hardware auf die gleiche Weise verwendet, wie eine funktionale Operation die Hardware verwendet. Zum Beispiel kann dieselbe Hardwareschnittstelle sowohl von der PFSD-Aufgabe als auch von den funktionalen Operationen für den Konfigurationszugriff und/oder Datenzugriff verwendet werden. Ebenso kann die Software, die auf dem Zielsystem ausgeführt wird, beim Durchführen sowohl von PFSD-Aufgaben als auch von funktionalen Operationen dieselbe Programmiersequenz befolgen. Mit anderen Worten verwendet das PFSD-Verfahren vorhandene Hardware- und Softwarekomponenten des Zielsystems, wodurch das PFSD-Verfahren einfach eingesetzt werden kann. Ferner erfordert das PFSD-Verfahren keine zusätzliche Kontextumschaltung, da die Hardware eine PFSD-Aufgabe auf die gleiche Weise verarbeitet wie eine funktionale Operation.
  • Der Prozentsatz der Hardware, die mit einem diagnostischen Verfahren getestet werden kann, wird als diagnostische Abdeckung bezeichnet. Die durch das PFSD-Verfahren erreichbare diagnostische Abdeckung kann mindestens teilweise durch eine vorherbestimmte Anzahl verfügbarer PFSD-Aufgaben (implementiert als Software-Diagnoseaufgaben) bestimmt werden. Ein Hardware-Verarbeitungsblock (z. B. einer der Verarbeitungsblöcke 124) kann dadurch gekennzeichnet sein, dass er einen Steuerungs- und Konfigurationsblock, einen Kommunikationsblock und Datenverarbeitungsblöcke beinhaltet. Der Steuerungs- und Konfigurationsblock kann einen Prozessor beinhalten (z. B. den lokalen Prozessorblock 230), der zu vielseitig ist, um von der vorherbestimmten Anzahl von PFSD-Aufgaben umfassend in Anspruch genommen zu werden. Daher kann die Effektivität des PFSD-Verfahrens in Bezug auf den Steuerungs- und Konfigurationsblock relativ gering sein. Zum Beispiel hat das Einbringen von simulierten permanenten Hardwarefehlern in den Steuerungs- und Konfigurationsblock eines Zielsystems gezeigt, dass das PFSD-Verfahren eine diagnostische Abdeckung von etwa 10 % bis etwa 20 % des Steuerungs- und Konfigurationsblocks im Zielsystem bereitstellen kann. Leider kann die Erhöhung der Anzahl vorherbestimmter Software-Diagnoseaufgaben, um die diagnostische Abdeckung zu erhöhen, die Laufzeit erhöhen und die Hardware überfordern.
  • Der Kommunikationsblock kann eine Logik für den Umgang mit speziellen Bedingungen beinhalten, die mit PFSD-Aufgaben nur schwer oder gar nicht zu testen sind, da eine große Anzahl von PFSD-Aufgaben erforderlich wäre, um eine große Anzahl von logischen Kombinationen zu testen, von denen einige möglicherweise nicht einmal durchführbar sind und daher nicht getestet werden müssen. Das Einbringen von simulierten permanenten Hardwarefehlern in den Kommunikationsblock eines Zielsystems hat gezeigt, dass das PFSD-Verfahren eine diagnostische Abdeckung von etwa 40 % bis etwa 50 % des Kommunikationsblocks im Zielsystem bereitstellen kann. Während es möglich sein kann, ein einigermaßen akzeptables Level der diagnostischen Abdeckung des Kommunikationsblocks zu erreichen, kann es schwierig sein, diese diagnostische Abdeckung zu erhöhen.
  • Die Datenverarbeitungsblöcke können feste Funktionen gemäß einem von einer konkreten Anwendung (z. B. der Anwendung 108) bestimmten Arbeitsmodus durchführen. Außerdem können die von den Datenverarbeitungsblöcken unterstützten Arbeitsmodi begrenzt sein, und möglicherweise kann nur eine Teilmenge der verfügbaren Arbeitsmodi (z. B. von der Anwendung 108 verwendet) für das PFSD-Verfahren von Interesse sein. Daher kann eine angemessene Anzahl von PFSD-Aufgaben, die die Hardware des Zielsystems nicht überfordern, ausreichen, um die Datenverarbeitungsblöcke angemessen in Anspruch zu nehmen. So kann die Effektivität des PFSD-Verfahrens in Bezug auf die Datenverarbeitungsblöcke relativ hoch sein. Zum Beispiel hat das Einbringen von simulierten permanenten Hardwarefehlern in die Datenverarbeitungsblöcke eines Zielsystems gezeigt, dass das PFSD-Verfahren eine diagnostische Abdeckung von etwa 60 % bis etwa 80 % der Datenverarbeitungsblöcke im Zielsystem bereitstellen kann.
  • Unter Bezugnahme auf 2, kann die vorherbestimmte Anzahl von PFSD-Aufgaben wie vorstehend erwähnt so ausgewählt werden, dass die Datenverarbeitungsblöcke angemessen in Anspruch genommen werden, ohne dass eine unerwünschte Menge an Verarbeitungsressourcen verbraucht wird (z. B. durch Erhöhung der Laufzeit und/oder Überforderung der Hardware). Die Datenverarbeitungsblöcke können die DPU 232 jedes der Verarbeitungsblöcke 124 beinhalten, die einen oder mehrere funktionale Prozesse durchführen können, die für die Anwendung 108 spezifisch sind (siehe 1, 8 und 9). Mit anderen Worten können die Datenverarbeitungsblöcke des Verarbeitungsblocks/der Verarbeitungsblöcke 124 feste Funktionen gemäß einem von der Anwendung 108 bestimmten Arbeitsmodus durchführen. Zum Beispiel kann eine DLA-Engine (z. B. implementiert durch die DPU 232 des Verarbeitungsblocks 202F) Operationen eines neuronalen Faltungsnetzes (convolutional neural network - „CNN“) durchführen. Als weiteres nicht einschränkendes Beispiel kann eine VIC-Engine (z. B. implementiert durch die DPU 232 des Verarbeitungsblocks 202C) eine Pixelinterpolation oder -extrapolation durchführen, nachdem Skalierungsfaktoren festgelegt wurden.
  • Leider ist es möglich, dass einige Hardwarefehler auftreten, die von PFSD-Aufgaben unerkannt bleiben. Ob ein Fehler erkennbar ist, wird als Beobachtbarkeit von Fehlereffekten bezeichnet. PFSD-Aufgaben sind darauf ausgelegt, tatsächliche Ergebnisse zu erzeugen, die mit vorherbestimmten Ergebnissen verglichen werden. Nur diejenigen Fehler, die eine Abweichung zwischen den tatsächlichen Ergebnissen und den vorherbestimmten Ergebnissen veranlassen, werden vom PFSD-Verfahren erkannt. Mit anderen Worten können Fehler, die keine Abweichung veranlassen, unerkannt oder latent bleiben.
  • Ein Standort, an dem ein Fehler auftritt, kann als Fehlerpunkt bezeichnet werden, und eine Position, an der ein tatsächliches Ergebnis erfasst wird, um es mit einem vorherbestimmten Ergebnis zu vergleichen, wird als Diagnosepunkt bezeichnet. Die Beobachtbarkeit eines Fehlers hängt von der Platzierung der Diagnosepunkte im Zielsystem ab. Typische Diagnosepunkte beinhalten eine primäre Ausgabe einer Hardware-Engine (z. B. einen der Verarbeitungsblöcke 124) und können ein oder mehrere Registerbits beinhalten, die nur den groben Gesundheitszustand der Hardware-Engine angeben. Die Erhöhung der Anzahl der Diagnosepunkte kann zwar die diagnostische Abdeckung erhöhen, doch kann dies auch die Laufzeit erhöhen und die Hardware überfordern. Hinzu kommt, dass herkömmliche Implementierungen des PFSD-Verfahrens von Software durchgeführt werden, was Prozessorzeit erfordert. Zum Beispiel wird Software verwendet, um einen oder mehrere Werte durch Verarbeitung der tatsächlichen Ergebnisse zu erhalten (z. B. Berechnung einer oder mehrerer Prüfsummen basierend auf den tatsächlichen Ergebnissen) und/oder den/die Wert(e) mit den vorherbestimmten Ergebnissen zu vergleichen. Daher sind die zeitlichen und räumlichen Kosten solcher Software-Implementierungen des PFSD-Verfahrens möglicherweise nicht zu vernachlässigen. Dies kann insbesondere dann der Fall sein, wenn das Zielsystem aufgrund der Menge an Pixeldaten in Videoframes, die von den Hardware-Engines (z. B. Verarbeitungsblöcken wie den Verarbeitungsblöcken 202A-202F) verarbeitet werden, eine CV-Pipeline implementiert, selbst wenn ein Prüfsummenalgorithmus wie zyklische Redundanzprüfung (Cyclic Redundancy Check - „CRC“) verwendet wird.
  • Der Fehlerpunkt kann mit anderer Hardware verbunden sein. So kann sich der Effekt eines Fehlers durch verbundene Hardware (auch als zwischengeschaltete Systemlogik bezeichnet) vom Fehlerpunkt bis zu einem Diagnosepunkt ausbreiten, sodass der Fehler dann durch das PFSD-Verfahren beobachtbar sein kann. Die Komplexität der Hardwareausgestaltung macht die Fehlerausbreitung durch verbundene Hardware zu einem schwierigen Problem, das unter Verwendung von zwei konzeptionellen Metriken untersucht werden kann: strukturelle Beobachtbarkeit und arbeitslastbezogene Beobachtbarkeit.
  • Die strukturelle Beobachtbarkeit bestimmt, ob im Zielsystem ein Pfad vom Fehlerpunkt zu einem Diagnosepunkt existiert und berücksichtigt nicht den logischen Zustand. Zum Beispiel gilt ein hängengebliebener Fehler als strukturell beobachtbar, wenn die Auswirkung des hängengebliebenen Fehlers mindestens einen Diagnosepunkt erreicht oder in einem Einzugskegel eines der Diagnosepunkte enthalten ist. 4 ist eine Veranschaulichung eines Schaltplans einer beispielhaften Schaltung 400, die verwendet wird, um zu veranschaulichen, wann ein Fehler strukturell und/oder arbeitslastbezogen beobachtbar ist, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Unter Bezugnahme auf 4 beinhaltet die Schaltung 400 ein UND-Logikgatter G1, ein ODER-Logikgatter G2 und ein XOR-Logikgatter G3 sowie zwei Flipflops FF1 und FF2. Das UND-Logikgatter G1 weist zwei Eingabeports 402 und 404 auf und das ODER-Logikgatter G2 weist einen Eingabeport 406 auf. Ein Fehler kann an einem oder mehreren der Eingabeports 402-406 auftreten. Das Flipflop FF2 weist einen Ausgabeport 408 auf, der ein Diagnosepunkt ist. Fehler, die an den Eingabeports 402-406 auftreten, sind alle strukturell beobachtbar, da sich die Zustände der Eingabeports 402-406 durch die Schaltung 400 bis zum Ausgabeport 408 ausbreiten können. PFSD-Aufgaben sind jedoch nicht in der Lage, alle strukturell beobachtbaren Fehler zu erkennen, da der Effekt einiger Fehler durch statische Werte, die von einer PFSD-Aufgabe gesetzt werden (z. B. als logische Klammern fungierend), wettgemacht werden können. Zum Beispiel, wenn die PFSD-Aufgabe den Eingabeport 404 auf Null setzt, wird das UND-Logikgatter G1 Null ausgeben und die am Eingabeport 402 empfangene Eingabe wird die Ausgabe des UND-Logikgatters G1 nicht verändern. Jegliche Fehler, die am Eingabeport 402 auftreten, werden also nicht am Ausgabeport 408 erkennbar sein. Ein weiteres Beispiel: Wenn die PFSD-Aufgabe den Eingabeport 406 auf Eins setzt, wird das ODER-Logikgatter G2 Eins ausgeben und die vom UND-Logikgatter G1 empfangene Eingabe wird die Ausgabe des ODER-Logikgatters G2 nicht verändern. Jegliche Fehler, die am Eingabeport 402 und oder am Eingabeport 404 auftreten, werden also nicht am Ausgabeport 408 erkennbar sein.
  • Wie das vorherige Beispiel veranschaulicht, kann die Erkennbarkeit eines strukturell beobachtbaren Fehlers von der Arbeitslast abhängen, die durch die PFSD-Aufgaben bestimmt wird. Ein Fehler, der sich unter einer spezifischen Arbeitslast durch einen Diagnosepunkt ausbreiten kann, wird als arbeitslastbezogen beobachtbar bezeichnet. Ob ein arbeitslastbezogen beobachtbarer Fehler tatsächlich von den PFSD-Aufgaben erkannt wird, hängt von der Ausgestaltung der PFSD-Aufgaben ab. Somit kann die Beobachtbarkeit von Fehlereffekten auf zwei Arten verbessert werden. Erstens können zusätzliche Diagnosepunkte zum Zielsystem hinzugefügt werden. Zum Beispiel können solche zusätzlichen Diagnosepunkte alle Werte beinhalten, die von einer Sicherheitsanwendung verwendet werden, um zu verhindern, dass ein Fehler die Funktion der Sicherheitsanwendung beeinträchtigt. Zweitens können die PFSD-Aufgaben so angepasst werden, dass sie eine Arbeitslast erzeugen, die sicherstellt, dass strukturelle beobachtbare Fehler arbeitslastbezogen beobachtbar sind und von einem Prüfmechanismus erkannt werden können. Eine solche Anpassung wird als Ausarbeitungsprozess bezeichnet. Um die diagnostische Abdeckung zu erhöhen, kann die Software, die das PFSD-Verfahren implementiert, die von den PFSD-Aufgaben erzeugte Arbeitslast ausarbeiten oder verbessern, um die Beobachtbarkeit von Fehlereffekten zu erhöhen. Allerdings kann die ausgearbeitete Arbeitslast auf einige Engpässe stoßen und eine erhöhte Laufzeit aufweisen.
  • Unter Bezugnahme auf 3 kann die DPU 232 solche Engpässe und/oder erhöhte Laufzeiten vermeiden, indem sie Hardware verwendet, um die Anzahl der Diagnosepunkte zu erhöhen, Fehlererkennungswerte zu bestimmen (z. B. durch Durchführen einer Prüfsummenberechnung) und die Fehlererkennungswerte mit goldenen Referenzen zu vergleichen. Zum Beispiel beinhaltet die DPU 232 in der in 3 veranschaulichten Ausführungsform die Kanäle C1-CM, Teilblöcke 310 und Fehlererkennungsblöcke 312. Die Teilblöcke 310 empfangen und/oder senden Informationen (z. B. als Datenpakete) über die Kanäle C1-C(M-1). In der veranschaulichten Ausführungsform beinhalten die Teilblöcke 310 die Teilblöcke 310-1 bis 310-N, die über die Kanäle C2-C(M-2) in Reihe geschaltet sind. Es können jedoch auch andere Anordnungen, wie beispielsweise parallele und kombinierte parallele und serielle Anordnungen, verwendet werden. In der veranschaulichten Ausführungsform beinhalten die Fehlererkennungsblöcke 312 die Fehlererkennungsblöcke 312-1 bis 312-M, die jeweils mit den Kanälen C1-CM verbunden sind. Die Fehlererkennungsblöcke 312 können dadurch gekennzeichnet sein, dass sie die von den Teilblöcken 310-1 bis 310-N ausgegebenen und in den Kanälen C2-C(M-1) übertragenen Daten passiv überwachen.
  • In der veranschaulichten Ausführungsform stellen die Kanäle C1-C(M-2) jeweils Teilblock-Eingabedaten für die Teilblöcke 310-1 bis 310-N bereit, und die Kanäle C2-C(M-1) erhalten jeweils Teilblock-Ausgabedaten von den Teilblöcken 310-1 bis 310-N. Der Kanal C1 verbindet den Cache 304 mit dem Teilblock 310-1 und der Kanal CM verbindet den Puffer 308 mit dem DMA-Block 236. In dem veranschaulichten Beispiel kann eine Anzahl M der Kanäle C1-CM um zwei größer sein als eine Anzahl N der Teilblöcke 310-1 bis 310-N. Jeder der Teilblöcke 310-1 bis 310-N führt eine oder mehrere Teiloperationen an den Teilblock-Eingabedaten durch, die durch einen der Kanäle C1-C(M-2) zum Teilblock hingeleitet werden, und produziert die Teilblock-Ausgabedaten, die durch einen der Kanäle C2-C(M-1) vom Teilblock weggeleitet werden. In dem veranschaulichten Beispiel sind also die Teilblock-Ausgabedaten eines der Teilblöcke 310-1 bis 310-N die Teilblock-Eingabedaten eines anderen der Teilblöcke 310-1 bis 310-N.
  • In dem veranschaulichten Beispiel gibt der Kanal C1 die DPU-Eingabedaten 302 in den Teilblock 310-1 und den Fehlererkennungsblock 312-1 ein. Die Teilblöcke 310-1 bis 310-N sind in Reihe geschaltet, wobei der Teilblock 310-1 die DPU-Eingabedaten 302 (als seine Teilblock-Eingabedaten) empfängt, seine Teilblock-Eingabedaten verarbeitet und seine Teilblock-Ausgabedaten über den Kanal C2 sowohl an den Teilblock 310-2 als auch an den Fehlererkennungsblock 312-2 liefert. Wie oben erwähnt, empfängt jeder der Teilblöcke 310-2 bis 310-(N-1) die Teilblock-Ausgabedaten von einem vorangegangenen einen der Teilblöcke 310-1 bis 310-(N-2) als seine Teilblock-Eingabedaten, verarbeitet seine Teilblock-Eingabedaten und liefert seine Teilblock-Ausgabedaten an einen nachfolgenden einen der Teilblöcke 310-3 bis 310-N und einen der Fehlererkennungsblöcke 312-3 bis 312-(M-2). Der Teilblock 310-N empfängt (als seine Teilblock-Eingabedaten) die Teilblock-Ausgabedaten vom Teilblock 310-(N-1), verarbeitet seine Teilblock-Eingabedaten und liefert seine Teilblock-Ausgabedaten über den Kanal C(M-1) sowohl an den Puffer 308 als auch an den Fehlererkennungsblock 312-(M-1). Der Kanal CM liefert die Ausgabe des Puffers 308 an den DMA-Block 236 und den Fehlererkennungsblock 312-M.
  • Jeder der Fehlererkennungsblöcke 312-1 bis 312-M erzeugt einen Fehlererkennungswert (z. B. eine Prüfsumme) mindestens teilweise basierend auf seiner Eingabe und bestimmt, ob dieser Fehlererkennungswert mit einer goldenen Referenz übereinstimmt. In dem veranschaulichten Beispiel erzeugen die Fehlererkennungsblöcke 312-1 bis 312-M jeweils Vergleichsergebnisse R1-RM und speichern die Vergleichsergebnisse R1-RM in einem Statusregister 320 (z. B. einem rollierenden Register). Der lokale Prozessorblock 230 ist mit dem Statusregister 320 verbunden und erhält daraus die Vergleichsergebnisse R1-RM. Der lokale Prozessorblock 230 kann eines oder mehrere der Vergleichsergebnisse R1-RM als die Fehlermeldung 138 an die Systemsteuerung 104 weiterleiten. Zum Beispiel, wenn eines der Vergleichsergebnisse R1-RM einen Fehler angibt, kann der lokale Prozessorblock 230 die Fehlermeldung 138 an die Systemsteuerung 104 weiterleiten.
  • In der veranschaulichten Ausführungsform funktionieren die Kanäle C1-CM jeweils als Diagnosepunkt und die Einbeziehung der Fehlererkennungsblöcke 312-1 bis 312-M erhöht die Anzahl der Diagnosepunkte in der DPU 232 (z. B. um mindestens die Zahl N). Zusätzlich zur Erhöhung der Anzahl der Diagnosepunkte innerhalb der DPU 232 beinhalten die Fehlererkennungsblöcke 312-2 bis 312-(M-1) Hardware, die die Fehlererkennungswerte bestimmt (z. B. durch Durchführen einer Prüfsummenberechnung), und Hardware, die die Fehlererkennungswerte mit goldenen Referenzen vergleicht. Somit überfordert die Bestimmung der Fehlererkennungswerte und ihr Vergleich mit den goldenen Referenzen nicht den lokalen Prozessorblock 230.
  • 5 ist eine Veranschaulichung eines Schaltplans einer beispielhaften Schaltung 500, die zur Implementierung eines oder mehrerer der Fehlererkennungsblöcke 312 (siehe 3) verwendet werden kann, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Unter Bezugnahme auf 5 kann eine Schaltung 500 eine Fehlererkennungsschaltung 502 (z. B. eine EDC-Schaltung), drei Register 504-508 und eine Vergleichsschaltung 510 beinhalten. Eines oder mehrere der Register 504-508 können als softwareprogrammierbare Register implementiert sein.
  • Die Fehlererkennungsschaltung 502 kann Eingaben 520 aus dem Cache 304, dem Puffer 308 oder einem der Teilblöcke 310-3 bis 310-(N) empfangen (siehe 3). Unter Bezugnahme auf 5 bestimmt die Fehlererkennungsschaltung 502 einen Fehlererkennungswert 522 mindestens teilweise basierend auf der Eingabe 520 und überträgt den Fehlererkennungswert 522 an das erste Register 504, das den Fehlererkennungswert 522 speichert. Als nicht einschränkendes Beispiel kann der Fehlererkennungswert 522 ein CRC-Code sein, der von der Fehlererkennungsschaltung 502 bestimmt wird. In mindestens einer Ausführungsform kann der Fehlererkennungswert 522 basierend auf der Eingabe 520 und einem vorhergehenden Fehlererkennungswert 524 bestimmt werden, der vom ersten Register 504 empfangen wurde. Einige Verfahren zur Fehlererkennung können zusätzliche Werte beinhalten, wie beispielsweise ein vorherbestimmtes Polynom. Wenn die Eingabe 520 beispielsweise als eine Reihe von Datenpaketen empfangen wird, kann die Fehlererkennungsschaltung 502 einen ersten CRC-Code für das erste Datenpaket in der Reihe, ein vorherbestimmtes Polynom und einen im ersten Register 504 gespeicherten Wert, der ein initialisierter Wert (z. B. Null) sein kann, bestimmen. Die Fehlererkennungsschaltung 502 kann den ersten CRC-Code in dem ersten Register 504 speichern. Dann kann die Fehlererkennungsschaltung 502 einen zweiten CRC-Code für das zweite Datenpaket in der Reihe, das vorherbestimmte Polynom und den im ersten Register 504 gespeicherten Wert, der für das erste Paket bestimmt wurde, bestimmen. Dieser Prozess wird für jedes Datenpaket in der Reihe fortgesetzt, bis alle von der Fehlererkennungsschaltung 502 verarbeitet worden sind, wobei dann das erste Register 504 einen endgültigen Fehlererkennungswert 526 speichert.
  • Das zweite Register 506 empfängt und speichert eine goldene Referenz 528 (z. B. eine der in 1 veranschaulichten goldenen Referenzen 116). In der veranschaulichten Ausführungsform kann das zweite Register 506 die goldene Referenz 528 vom lokalen Prozessorblock 230 empfangen. Der lokale Prozessorblock 230 kann die goldene Referenz 528 von der Systemsteuerung 104 empfangen haben (z. B. in der in 1 veranschaulichten Anweisung 110A).
  • Das dritte (Steuer-)Register 508 kann zum Management der Schaltung 500 beitragen, was Initialisieren des ersten Registers 504, Aktivieren der Berechnung des endgültigen Fehlererkennungswerts 526, Deaktivieren der Berechnung des endgültigen Fehlererkennungswerts 526 und/oder Auslösen der Vergleichsschaltung 510 zum Vergleichen der vom ersten und zweiten Register 504 und 506 gespeicherten Werte beinhalten kann. Zum Beispiel kann das dritte (Steuer-)Register 508 einen oder mehrere Befehle 530 von dem lokalen Prozessorblock 230 empfangen. Der/die Befehl(e) 530 kann/können das dritte (Steuer)Register 508 veranlassen, einen Wert 532 zu speichern, der das erste Register 504 dazu veranlasst, sich zu initialisieren (z. B. seinen Wert gleich Null zu setzen).
  • Der/die Befehl(e) 530 kann/können das dritte (Steuer-)Register 508 veranlassen, einen Wert 534 zu speichern, der es der Fehlererkennungsschaltung 502 ermöglicht, den endgültigen Fehlererkennungswert 526 zu bestimmen. In dem in 5 veranschaulichten Beispiel kann die Schaltung 500 ein UND-Logikgatter 536 beinhalten, das den Wert 534 und einen Wert 538 empfängt und einen vorherbestimmten hohen Wert (z. B. Eins) ausgibt, wenn keiner der Werte 534 und 538 ein niedriger Wert (z. B. Null) ist. Der Wert 538 weist einen vorherbestimmten hohen Wert auf (z. B. Eins), wenn die Eingabe 520 (z. B. ein neues Datenpaket) bereit ist, verarbeitet zu werden. Mit anderen Worten, der Wert 538 weist den vorherbestimmten hohen Wert auf, wenn die Eingabe 520 gültig ist. Das UND-Logikgatter 536 kann den Wert 538 von einer beliebigen Struktur empfangen, die Daten für einen konkreten einen der Fehlererkennungsblöcke 312 bereitstellt, der das UND-Logikgatter 536 beinhaltet, wie beispielsweise den Cache 304 (siehe 3), den Puffer 308 (siehe 3) oder einen beliebigen der Teilblöcke 310 (siehe 3, 8 und 9). Mit anderen Worten kann der Wert 538 von einem beliebigen der Kanäle C1 bis CM (siehe 3) empfangen werden. Wenn das UND-Logikgatter 536 den vorherbestimmten hohen Wert (z. B. Eins) ausgibt, stellt das erste Register 504 den vorherbestimmten hohen Wert für die Fehlererkennungsschaltung 502 bereit (z. B. zusammen mit dem vorherigen Fehlererkennungswert 524), wodurch die Fehlererkennungsschaltung 502 aktiviert wird. Das UND-Logikgatter 536 gibt einen vorherbestimmten niedrigen Wert (z. B. Null) aus, wenn mindestens einer der Werte 534 und 538 der niedrige Wert (z. B. Null) ist. Als nicht einschränkendes Beispiel kann die Fehlererkennungsschaltung 502 den von dem UND-Logikgatter 536 ausgegebenen Wert erhalten, indem sie das erste Register 504 nach dem Wert abfragt.
  • Der/die Befehl(e) 530 kann/können das dritte (Steuer-)Register 508 veranlassen, einen Wert (nicht gezeigt) zu speichern, der die Fehlererkennungsschaltung 502 deaktiviert, sodass die Fehlererkennungsschaltung 502 den endgültigen Fehlererkennungswert 526 nicht bestimmt. In dem in 5 veranschaulichten Beispiel kann der Wert (nicht gezeigt) niedrig sein (z. B. Null), sodass das UND-Logikgatter 536 einen vorherbestimmten niedrigen Wert (z. B. Null) ausgibt, den die Fehlererkennungsschaltung 502 empfängt (z. B. zusammen mit dem vorherigen Fehlererkennungswert 524) und der die Fehlererkennungsschaltung 502 deaktiviert.
  • Der/die Befehl(e) 530 kann/können das dritte (Steuer-)Register 508 veranlassen, einen Wert 540 zu speichern, der die Vergleichsschaltung 510 veranlasst, den endgültigen Fehlererkennungswert 526 und die vom ersten und zweiten Register 504 bzw. 506 gespeicherte goldene Referenz 528 zu vergleichen und ein Ergebnis 542 dieses Vergleichs (z. B. eines der in 3 veranschaulichten Vergleichsergebnisse R1-RM) an das Statusregister 320 auszugeben. Als nicht einschränkendes Beispiel kann die Vergleichsschaltung 510 das dritte (Steuer-)Register 508 nach dem Wert 540 abfragen. In der veranschaulichten Ausführungsform kann der lokale Prozessorblock 230 das Ergebnis 542 aus dem Statusregister 320 erhalten, das als dedizierter Port funktionieren kann. So kann das dritte (Steuer-)Register 508 die Schaltung 500 verwalten, indem es das erste Register 504 initialisiert, das Berechnen des Fehlererkennungswerts 522 aktiviert, das Berechnen des Fehlererkennungswerts 522 deaktiviert und den Vergleich durch die Vergleichsschaltung 510 auslöst.
  • Unter Bezugnahme auf 3 stellen die Fehlererkennungsblöcke 312-1 bis 312-M dem lokalen Prozessorblock 230 (z. B. über das Statusregister 320) die jeweiligen Vergleichsergebnisse R1-RM bereit. Wenn eines oder mehrere der Vergleichsergebnisse R1-RM angibt, dass ein Fehler aufgetreten ist, kann der lokale Prozessorblock 230 die Systemsteuerung 104 informieren, sodass korrigierende Maßnahmen ergriffen werden können. Zum Beispiel, unter Bezugnahme auf 5, kann der lokale Prozessorblock 230 die Systemsteuerung 104 informieren, indem er eine Fehlermeldung 544 (z. B. in der in 1 und 3 veranschaulichten Fehlermeldung 138) an die Systemsteuerung 104 sendet.
  • Wie vorstehend erwähnt, können die Fehlererkennungsblöcke 312 als CRC-Blöcke implementiert werden und können die Fehlererkennungswerte als CRC-Codes implementiert werden. In solchen Ausführungsformen können die Fehlererkennungsblöcke 312 dadurch gekennzeichnet sein, dass sie Hardware-CRC-gestützte Software-Diagnose implementieren, die permanente und/oder vorübergehende Fehler in einem Zielsystem, wie beispielsweise einer Verarbeitungspipeline, erkennt.
  • 6 ist eine Veranschaulichung eines Blockdiagramms von beispielhaften Anweisungen 600, die zur Implementierung von diagnostischen und funktionalen Aufgaben oder Operationen im Verarbeitungssystem 102 (siehe 1) verwendet werden können, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Zum Beispiel können die Anweisungen 600 auf dem SoC 150 gespeichert sein. Die Anweisungen 600 implementieren die Vorrichtungsfunktionalität 602 und ein Betriebssystem 604. In Ausführungsformen, in denen das Verarbeitungssystem 102 eine Komponente eines autonomen Fahrzeugs ist, kann die Vorrichtungsfunktionalität 602 das Fahren implementieren. Die Vorrichtungsfunktionalität 602 beinhaltet die Sicherheitsüberwachung 106, die Anwendung 108, eine diagnostische Anwendungsprogrammierschnittstelle (application programing interface - „API“) 606, eine Anwendungs-API 608 und einen Systemaufgabenmanager (system task manager - „STM“) 610. Das Betriebssystem 604 kann eine oder mehrere Bibliotheken 614 und einen oder mehrere Treiber 616 beinhalten, die mit Hardware-Engines 620 kommunizieren.
  • Die Anwendung 108 verwendet die Anwendungs-API 608, um eine funktionale Anforderung (z. B. einen ersten, in 8 veranschaulichten Befehl 810) in eine oder mehrere funktionale Aufgaben oder Operationen (z. B. einen zweiten, in 8 veranschaulichten Befehl 812) zu übersetzen. Die Sicherheitsüberwachung 106 verwendet die diagnostische API 606, um eine Sicherheitsanforderung (z. B. einen ersten, in 9 veranschaulichten Befehl 902) in eine oder mehrere diagnostische Aufgaben oder Operationen (z. B. einen zweiten, in 9 veranschaulichten Befehl 904) zu übersetzen.
  • Der STM 610 verschachtelt diagnostische Operationen (die von der Sicherheitsüberwachung 106 stammen) mit den Aufgaben der funktionalen Operationen (die von der Anwendung 108 stammen) und macht die diagnostischen Operationen für nachgelagerte Software-Schichten (z. B. die Bibliothek(en) 614 und den/die Treiber 616) sowie für die Hardware-Engines 620 ununterscheidbar von den funktionalen Operationen. Der STM verwaltet auch die Arbitrierung von Aufgaben, sodass sowohl ein Latenzziel für die diagnostischen Operationen (z. B. PFSD-Aufgaben) als auch ein Leistungsziel für funktionale Operationen (z. B. ADAS-Funktionen) berücksichtigt werden können. Die übrigen Komponenten im Architekturdiagramm sind unabhängig von einem Initiator der Aufgabe (z. B. der Sicherheitsüberwachung 106 oder der Anwendung 108).
  • Die Bibliothek(en) 614 kann/können als Benutzerbibliothek(en) implementiert werden und die Kommunikation zwischen dem STM 610 und dem/den Treiber(n) 616 bereitstellen. Der/die Treiber 616 kann/können die Hardware-Engines 620 anweisen, spezifische diagnostische und/oder funktionale Operationen durchzuführen. Die Hardware-Engines 620 können als der Verarbeitungsblock/die Verarbeitungsblöcke 124 implementiert werden (siehe 1 und 2).
  • 7 ist eine Veranschaulichung eines Ablaufdiagramms, das ein Verfahren 700 zum Erkennen von Fehlern im Verarbeitungssystem 102 zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Nun Bezug nehmend auf 7 umfasst j eder hier beschriebene Block des Verfahrens 700 einen Rechenprozess, der mit einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren können auch als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Die Verfahren können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (alleinstehend oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-In für ein anderes Produkt bereitgestellt sein, um nur einige zu nennen. Darüber hinaus wird das Verfahren 700 beispielhaft mit Bezug auf das System 100 aus 1 beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hierin beschriebenen.
  • Mindestens Abschnitte des Verfahrens 700 können von einem der Verarbeitungsblöcke 202A-202F durchgeführt werden (siehe 2). Zur besseren Veranschaulichung wird ein Abschnitt des Verfahrens 700 als vom Verarbeitungsblock 202A durchgeführt beschrieben, dieser Abschnitt kann jedoch alternativ oder zusätzlich von einem beliebigen der Verarbeitungsblöcke 202A-202F durchgeführt werden.
  • Unter Bezugnahme auf 7 empfängt der lokale Prozessorblock 230 (siehe 2, 3, 5, 8 und 9) im ersten Block 702 mindestens eine der Anweisung(en) 110 (siehe 1). Im Entscheidungsblock 704 bestimmt der lokale Prozessorblock 230, ob die Anweisung(en) die DPU 232 (siehe 2, 3, 8 und 9) anweist/anweisen, mindestens eine diagnostische Operation oder mindestens eine funktionale Operation durchzuführen. Wenn die Anweisung(en) die DPU 232 anweist/anweisen, die funktionale(n) Operation(en) durchzuführen, geht der lokale Prozessorblock 230 zum optionalen Block 706 über, falls dieser vorliegt, oder zum Block 710, wenn der optionale Block 706 ausgelassen wurde. Andererseits, wenn die Anweisung(en) die DPU 232 anweist/anweisen, die diagnostische(n) Operation(en) durchzuführen, geht der lokale Prozessorblock 230 zu Block 712 über.
  • Im optionalen Block 706 deaktiviert der lokale Prozessorblock 230 die Fehlererkennungsblöcke 312, wenn die Fehlererkennungsblöcke 312 (siehe 3) aktiviert sind. Wenn die DPU 232 also funktionale Operationen (oder Missionsaufgaben) durchführt, sind die Fehlererkennungsblöcke 312 deaktiviert. Im optionalen Block 706 kann der lokale Prozessorblock 230 die dritten (Steuer-)Register (z. B. das in 5 veranschaulichte dritte Register 508) programmieren, um Werte zu speichern, die Fehlererkennungsschaltungen (z. B. die in 5 veranschaulichte Fehlererkennungsschaltung 502) deaktivieren. Im nächsten Block 710 führt die DPU 232 die funktionale(n) Operation(en) durch. Dann kehrt der lokale Prozessorblock 230 zum Block 702 zurück, um mindestens eine neue der Anweisung(en) 110 zu empfangen (siehe 1).
  • In Block 712 speichert der lokale Prozessorblock 230 goldene Referenzen in den zweiten Registern (z. B. dem zweiten Register 506) der Fehlererkennungsblöcke 312 (siehe 3).
  • Dann, in Block 714, initialisiert der lokale Prozessorblock 230 die ersten Register (z. B. das erste Register 504) der Fehlererkennungsblöcke 312 (siehe 3). In Block 714 kann der lokale Prozessorblock 230 die dritten (Steuer-)Register (z. B. das dritte Register 508) so programmieren, dass sie Werte (z. B. den Wert 532) speichern, die die Initialisierung der ersten Register veranlassen (z. B. einen Wert von Null speichern).
  • Als Nächstes, wenn die Fehlererkennungsblöcke 312 (siehe 3) deaktiviert sind, aktiviert der lokale Prozessorblock 230 im optionalen Block 716 die Fehlererkennungsblöcke 312. Im optionalen Block 716 kann der lokale Prozessorblock 230 die dritten (Steuer-)Register (z. B. das in 5 veranschaulichte dritte Register 508) programmieren, um Werte (z. B. den Wert 534) zu speichern, die Fehlererkennungsschaltungen (z. B. die in 5 veranschaulichte Fehlererkennungsschaltung 502) aktivieren, um endgültige Fehlererkennungswerte zu bestimmen (z. B. den endgültigen Fehlererkennungswert 526).
  • In Block 718 führt die DPU 232 die diagnostische(n) Operation(en) durch und die Fehlererkennungsblöcke 312 (siehe 3) bestimmen endgültige Fehlererkennungswerte (z. B. den endgültigen Fehlererkennungswert 526). In Block 718 nehmen die Fehlererkennungsblöcke 312-1 bis 312-M (siehe 3) fortlaufend Abtastungen von Informationen (z. B. Datenpakete) vor, die jeweils über die Kanäle C1-CM übertragen werden, während die diagnostische(n) Operation(en) durchgeführt wird/werden, bestimmen Fehlererkennungswerte für die übertragenen Informationen (z. B. für jedes übertragene Datenpaket) und aktualisieren die Werte der ersten Register, nachdem jeder Fehlererkennungswert bestimmt wurde. Die Werte der ersten Register können sich mit jedem Datenpaket, das über die Kanäle C1-CM übertragen wird, verändern. Nach Abschluss der diagnostischen Operation(en) speichert jedes der ersten Register die endgültigen Fehlererkennungswerte für Informationen (z. B. für alle Datenpakete), die während der Durchführung der diagnostischen Operation(en) über einen jeweiligen der Kanäle C1-CM geleitet wurden.
  • Im optionalen Block 720 kann der lokale Prozessorblock 230 die Fehlererkennungsblöcke 312 deaktivieren (siehe 3). Im optionalen Block 720 kann der lokale Prozessorblock 230 das/die gleiche(n) Verfahren durchführen, das/die im optionalen Block 706 verwendet wurde(n), um die Fehlererkennungsblöcke 312 zu deaktivieren. In Ausführungsformen, die den optionalen Block 720 weglassen, kann der lokale Prozessorblock 230 den Block 722 durchführen, nachdem der Block 718 abgeschlossen wurde.
  • In Block 722 erzeugt der lokale Prozessorblock 230 Vergleichsergebnisse (z. B. die Vergleichsergebnisse R1-RM), indem er die Vergleichsschaltung (z. B. die in 5 veranschaulichte Vergleichsschaltung 510) in den Fehlererkennungsblöcken 312 (siehe 3) veranlasst, die goldenen Referenzen (z. B. gespeichert in dem in 5 veranschaulichten zweiten Register 506) mit den endgültigen Fehlererkennungswerten (z. B. gespeichert in dem in 5 veranschaulichten ersten Register 504) zu vergleichen. In Block 722 kann der lokale Prozessorblock 230 die dritten (Steuer-)Register so programmieren, dass sie Werte speichern (z. B. den in 5 veranschaulichten Wert 540), die die Vergleichsschaltung (z. B. die Vergleichsschaltung 510) veranlassen, die von den ersten Registern gespeicherten endgültigen Fehlererkennungswerte (z. B. den endgültigen Fehlererkennungswert 526) mit den von den zweiten Registern gespeicherten goldenen Referenzen (z. B. der goldenen Referenz 528) zu vergleichen und die Vergleichsergebnisse (z. B. die Vergleichsergebnisse R1-RM) auszugeben.
  • In Block 724 speichern die Fehlererkennungsblöcke 312 (siehe 3) die Vergleichsergebnisse (z. B. die in 3 veranschaulichten Vergleichsergebnisse R1-RM) in einem Statusregister (z. B. das in 3 veranschaulichte Statusregister 320). Die Vergleichsergebnisse können (z. B. über eine spezielle Leitung) an das Statusregister übertragen werden.
  • Als nächstes prüft der lokale Prozessorblock 230 im Entscheidungsblock 726 das Statusregister (z. B. das Statusregister 320) und bestimmt, ob ein beliebiges der im Statusregister gespeicherten Vergleichsergebnisse angibt, dass ein Fehler aufgetreten ist. Im Entscheidungsblock 726 bestimmt der lokale Prozessorblock 230 also, ob der Inhalt des Statusregisters angibt, dass ein Fehler aufgetreten ist. Die Entscheidung im Entscheidungsblock 726 lautet „JA“, wenn der lokale Prozessorblock 230 bestimmt, dass mindestens eines der Vergleichsergebnisse angibt, dass ein Fehler aufgetreten ist. Andernfalls lautet die Entscheidung im Entscheidungsblock 726 „NEIN“ und der lokale Prozessorblock 230 kehrt zum Block 702 zurück, um mindestens eine neue der Anweisung(en) 110 (siehe 1) zu empfangen.
  • Wenn die Entscheidung im Entscheidungsblock 726 „JA“ lautet, versucht der lokale Prozessorblock 230 in Block 728, eine Ursache des Fehlers zu bestimmen. Zum Beispiel kann der lokale Prozessorblock 230 einen ersten der Fehlererkennungsblöcke 312 in der Pipeline identifizieren, der den Fehler erkannt hat.
  • Dann, im Entscheidungsblock 730, entscheidet der lokale Prozessorblock 230, ob er eine Fehlermeldung (z. B. die in 5 veranschaulichte Fehlermeldung 544) an externe Verarbeitungseinrichtungen (z. B. die Systemsteuerung 104) im Prozessorblock (z. B. den Verarbeitungsblock 202A) eskaliert. Die Entscheidung im Entscheidungsblock 730 lautet „JA“, wenn der lokale Prozessorblock 230 beschließt, die Fehlermeldung zu eskalieren. Andernfalls lautet die Entscheidung im Entscheidungsblock 730 „NEIN“ und der lokale Prozessorblock 230 kehrt zum Block 702 zurück, um mindestens eine neue der Anweisung(en) 110 (siehe 1) zu empfangen.
  • Wenn die Entscheidung im Entscheidungsblock 730 „JA“ lautet, überträgt der lokale Prozessorblock 230 in Block 732 eine Fehlermeldung (z. B. die in 5 veranschaulichte Fehlermeldung 544) an die Systemsteuerung 104 (siehe 1-3, 5, 8 und 9). Dann kehrt der lokale Prozessorblock 230 zum Block 702 zurück, um mindestens eine neue der Anweisung(en) 110 zu empfangen (siehe 1). Unter Bezugnahme auf 1 kann die Systemsteuerung 104, nachdem die Systemsteuerung 104 die Fehlermeldung (z. B. in der Fehlermeldung 138) empfangen hat, eine oder mehrere korrigierende Maßnahmen ergreifen. Zum Beispiel kann die Systemsteuerung 104 den Verarbeitungsblock/die Verarbeitungsblöcke 124 abschalten und/oder zurücksetzen. In Ausführungsformen, bei denen das Verarbeitungssystem 102 in einem autonomen Fahrzeug installiert ist, kann die Systemsteuerung 104 die Steuerung des autonomen Fahrzeugs an einen menschlichen Fahrer zurückgeben.
  • 8 ist eine Veranschaulichung eines Ablaufdiagramms 800 zur Aufgabenkoordination, das einen der Verarbeitungsblöcke 124 (siehe 1 und 2) darstellt, der eine funktionale Operation durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Zur besseren Veranschaulichung wird der Verarbeitungsblock 202A (siehe 2) als die funktionale Operation durchführend beschrieben. Allerdings kann ein beliebiger der Verarbeitungsblöcke 202A-202F (siehe 2) die in 8 veranschaulichte funktionale Operation durchführen.
  • Unter Bezugnahme auf 8 sendet die Anwendung 108 den ersten Befehl 810 an die Anwendungs-API 608. Zum Beispiel kann der erste Befehl 810 in der Anweisung 110B (siehe 1) enthalten sein. Die Anwendungs-API 608 kann den ersten Befehl 810 in Befehle zerlegen, dass die Verarbeitungsblöcke 202A-202F eine oder mehrere funktionale Operationen durchführen. Zur besseren Veranschaulichung ist in 8 nur der zweite Befehl 812 dargestellt, der an den Verarbeitungsblock 202A weitergeleitet wird. Die Anwendungs-API 608 kann jedoch den ersten Befehl 810 in Befehle für einen oder mehrere der Verarbeitungsblöcke 202A-202F zerlegen.
  • Nachdem der lokale Prozessorblock 230 des Verarbeitungsblocks 202A den zweiten Befehl 812 (z. B. einschließlich der Anweisung 110B) empfangen hat, sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Mitteilung 814 an die Fehlererkennungsblöcke 312 des Verarbeitungsblocks 202A, die diese deaktiviert. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die im optionalen Block 706 (siehe 7) verwendet wurde(n), um die Fehlererkennungsblöcke 312 des Verarbeitungsblocks 202A zu deaktivieren.
  • Dann führen die Teilblöcke 310 des Verarbeitungsblocks 202A jeweils mindestens eine funktionale Operation 816 durch, die durch den zweiten Befehl 812 festgelegt wurde. Wenn jeder der Teilblöcke 310 das Durchführen der funktionale(n) Operation(en) 816 abgeschlossen hat, sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Bestätigungsnachricht 818 an die Anwendungs-API 608. Nachdem die Anwendungs-API 608 die Bestätigungsnachricht 818 empfangen hat, sendet die Anwendungs-API 608 eine Bestätigungsnachricht 820 an die Anwendung 108. Nun kann der lokale Prozessorblock 230 des Verarbeitungsblocks 202A einen weiteren Befehl (wie den zweiten Befehl 812) empfangen, dass die Teilblöcke 310 eine oder mehrere funktionale Operationen durchführen und/oder einen Befehl, dass die Teilblöcke 310 eine oder mehrere diagnostische Operationen durchführen.
  • 9 ist eine Veranschaulichung eines Ablaufdiagramms 900 zur Aufgabenkoordination, das einen der Verarbeitungsblöcke 124 (siehe 1 und 2) darstellt, der eine diagnostische Operation durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Zur besseren Veranschaulichung wird der Verarbeitungsblock 202A (siehe 2) als die diagnostische Operation durchführend beschrieben. Allerdings kann ein beliebiger der Verarbeitungsblöcke 202A-202F (siehe 2) die in 9 veranschaulichte diagnostische Operation durchführen.
  • Unter Bezugnahme auf 9 sendet die Sicherheitsüberwachung 106 den ersten Befehl 902 an die diagnostische API 606. Zum Beispiel kann der erste Befehl 902 in der Anweisung 110A (siehe 1) enthalten sein. Die diagnostische API 606 kann den ersten Befehl 902 in Befehle zerlegen, dass die Verarbeitungsblöcke 202A-202F eine oder mehrere diagnostische Operationen durchführen. Zur besseren Veranschaulichung ist in 9 nur der zweite Befehl 904 dargestellt, der an den Verarbeitungsblock 202A weitergeleitet wird. Die diagnostische API 606 kann jedoch den ersten Befehl 902 in Befehle für einen oder mehrere der Verarbeitungsblöcke 202A-202F zerlegen. In diesem Beispiel beinhaltet der zweite Befehl 904 eine oder mehrere goldene Referenzen 906.
  • Nachdem der lokale Prozessorblock 230 des Verarbeitungsblocks 202A den zweiten Befehl 904 (z. B. einschließlich der Anweisung 110A) empfangen hat, speichert der lokale Prozessorblock 230 des Verarbeitungsblocks 202A die goldene(n) Referenz(en) 906 im zweiten Register 506 (siehe 5) von mindestens einem der Fehlererkennungsblöcke 312. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die in Block 712 (siehe 7) verwendet wurde(n), um die goldene(n) Referenz(en) 906 in dem zweiten Register 506 (siehe 5) von mindestens einem der Fehlererkennungsblöcke 312 zu speichern.
  • Dann sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Mitteilung 908 an mindestens einen der Fehlererkennungsblöcke 312, der das erste Register 504 (siehe 5) des/der Fehlererkennungsblöcke initialisiert. Zum Beispiel kann die Mitteilung 908 das dritte (Steuer-)Register 508 (siehe 5) veranlassen, den Wert 532 (siehe 5) zu speichern, der das erste Register 504 des Fehlererkennungsblocks/der Fehlererkennungsblöcke initialisiert. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die in Block 714 (siehe 7) verwendet wurde(n), um das erste Register 504 des Fehlererkennungsblocks/der Fehlererkennungsblöcke zu initialisieren.
  • Dann sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Mitteilung 910, die diejenigen der Fehlererkennungsblöcke 312 aktiviert, die durch die Mitteilung 908 initialisiert wurden. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die im optionalen Block 716 (siehe 7) verwendet wurde(n), um den/die initialisierten Fehlererkennungsblock/Fehlererkennungsblöcke zu aktivieren.
  • Als Nächstes führen die Teilblöcke 310 des Verarbeitungsblocks 202A mindestens eine durch den zweiten Befehl 904 spezifizierte diagnostische Operation 912 durch und die Fehlererkennungsblöcke 312 bestimmen endgültige Fehlererkennungswerte 914 (wie der in 5 veranschaulichte endgültige Fehlererkennungswert 526). Der Verarbeitungsblock 202A kann das/die gleiche(n) Verfahren durchführen, das/die in Block 718 (siehe 7) verwendet wurde(n), um die diagnostische Operation(en) 912 durchzuführen und die endgültigen Fehlererkennungswerte 914 zu erhalten.
  • Nachdem der endgültige Fehlererkennungswert 526 bestimmt wurde, sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Mitteilung 916, die die Fehlererkennungsblöcke 312 des Verarbeitungsblocks 202A deaktiviert. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die im optionalen Block 706 (siehe 7) verwendet wurde(n), um die Fehlererkennungsblöcke 312 des Verarbeitungsblöcke 202A zu deaktivieren.
  • Dann sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Mitteilung 918, die einen Vergleich des endgültigen Fehlererkennungswerts 526 mit einer der goldenen Referenz(en) 906 auslöst. Der lokale Prozessorblock 230 des Verarbeitungsblocks 202A kann das/die gleiche(n) Verfahren durchführen, das/die in Block 722 (siehe 7) verwendet wurde(n), um den Vergleich auszulösen. Nach dem Vergleich führt der lokale Prozessorblock 230 des Verarbeitungsblocks 202A das/die gleiche(n) Verfahren durch, das/die in den Blöcken 724-732 (siehe 7) verwendet wurde(n), und sendet gegebenenfalls eine Fehlermeldung 920 (z. B. die in 5 veranschaulichte Fehlermeldung 544) an die diagnostische API 606. Die diagnostische API 606 kann die Fehlermeldung an die Sicherheitsüberwachung 106 weiterleiten. Die diagnostische API 606 und/oder die Sicherheitsüberwachung 106 können die Systemsteuerung 104 (siehe 1-3, 5, 8 und 9) veranlassen, eine oder mehrere korrigierende Maßnahmen in Bezug auf den Fehler zu ergreifen.
  • Nachdem die Teilblöcke 310 die Durchführung der diagnostischen Operation(en) 912 abgeschlossen haben, sendet der lokale Prozessorblock 230 des Verarbeitungsblocks 202A eine Bestätigungsnachricht 922 an die diagnostische API 606. Nachdem die diagnostische API 606 die Bestätigungsnachricht 922 empfangen hat, sendet die diagnostische API 606 eine Bestätigungsnachricht 924 an die Sicherheitsüberwachung 106. Nun kann der lokale Prozessorblock 230 des Verarbeitungsblocks 202A einen weiteren Befehl (wie den zweiten Befehl 904) empfangen, dass die Teilblöcke 310 eine oder mehrere funktionale Operationen durchführen und/oder einen Befehl, dass die Teilblöcke 310 eine oder mehrere diagnostische Operationen durchführen.
  • 10A-10D veranschaulichen ein Beispiel für ein autonomes Fahrzeug 1000, das einen oder mehrere Sensoren (z. B. eine oder mehrere Kameras) beinhaltet. Das Fahrzeug 1000 verarbeitet eine große Menge an Sensordaten, um seine Umgebung in Echtzeit wahrzunehmen und autonome Fahrfunktionen (z. B. ADAS-Funktionen) zu ermöglichen. Zum Beispiel können die Sensoren vom Fahrzeug 1000 verwendet werden, um ADAS-Funktionen wie etwa eine autonome Notbremsung (Autonomous Emergency Braking - „AEB“), einen Spurhalteassistenten (Lane Keeping Assistance - „LKA“), einen Stauassistenten (Traffic Jam Assistance - „TJA“) und dergleichen durchzuführen. Der/die Sensor(en) kann/können Komponenten eines Frontkamerasystems des Fahrzeugs 1000 sein, das weiter unten näher beschrieben wird. Alternativ und/oder zusätzlich kann/können der/die Sensor(en) Komponenten anderer Systeme sein, einschließlich anderer Kamerasysteme wie beispielsweise eines Rückfahrkamerasystems, eines Seitenkamerasystems und dergleichen.
  • Der/die Sensor(en) des Fahrzeugs 1000 kann/können Daten erfassen (z. B. Bilddaten, Videos und dergleichen) und diese Daten dem Verarbeitungssystem 102 (siehe 1) zur Verarbeitung bereitstellen. Zum Beispiel kann das Verarbeitungssystem 102 eine Pipeline für maschinelles Sehen implementieren, die Echtzeit-Videodaten verarbeitet, die von dem Frontkamerasystem des Fahrzeugs 1000 erfasst wurden. In solchen Ausführungsformen, unter Bezugnahme auf 1, kann der SoC 150 als SoC 1004 (10C) implementiert sein. Unter Bezugnahme auf 3 können die Teilblöcke 310 jeweils Verfahren durchführen, die spezifisch für die Verarbeitung von Bilddaten sind, die durch die Kanäle C1-C(M-2) fließen, und Operationen (z. B. für eine ADAS-Funktion) in einer Pipeline ausführen. Einer oder mehrere der Verarbeitungsblöcke 124 können als Hardware-Beschleunigungsblöcke implementiert sein, die beim Durchführen von Operationen an dem Video in Echtzeit helfen. Beispiele für solche Operationen beinhalten Erhalten eines optischen Flusses, Rauschunterdrückung, Bildskalierung, Durchführen einer oder mehrerer Bildtransformationen usw.
  • Das Verarbeitungssystem 102 kann ein oder mehrere Objekte von Interesse (z. B. Fußgänger, Radfahrer, Motorräder usw.) innerhalb einer begrenzten Zeitspanne (z. B. zur Vermeidung einer Kollision) erkennen, indem es funktionale Operationen an Daten (z. B. hochauflösende Bilder) durchführt, die von dem/den Sensor(en) (z. B. einer oder mehreren Kameras) des Fahrzeugs 1000 erfasst wurden. Das Verarbeitungssystem 102 kann Verfahren des maschinellen Sehens und/oder des maschinellen Lernens („ML“) durchführen, um das/die Objekt(e) von Interesse wahrzunehmen. Die Ausgabe der vom Verarbeitungssystem 102 durchgeführten funktionalen Operationen kann einem ADAS-System bereitgestellt werden, das eine oder mehrere geeignete Maßnahmen mindestens teilweise basierend auf der Ausgabe des Verarbeitungssystems 102 durchführen kann.
  • Unter Bezugnahme auf 2 können die Verarbeitungsblöcke 202A-202F den VI-Block, den ISP-Block, den VIC-Block, den OFA-Block, den PVA-Block bzw. den DLA-Block einer Pipeline für maschinelles Sehen (z. B. im Fahrzeug 1000 installiert) implementieren. In solchen Ausführungsformen kann der VI-Block (z. B. der Verarbeitungsblock 202A) einen oder mehrere Kameraströme mit Bilddaten erfassen und die Bilddaten in dem Speicher-Teilsystem 140 speichern. In diesem Beispiel können die Bilddaten Frames beinhalten, die mit einer Weitwinkellinse aufgenommen wurden.
  • Der ISP-Block (z. B. der Verarbeitungsblock 202B) kann die Bilddaten aus dem Speicher-Teilsystem 140 erhalten, die Bilddaten verarbeiten und die ISP-verarbeiteten Bilddaten im Speicher-Teilsystem 140 speichern. Zum Beispiel kann der ISP-Block einen Prozess zur Verarbeitung der Bilddaten im hochdynamischen Bereich (High Dynamic Range - „HDR“) durchführen, wie beispielsweise eine lokale Tonwertabbildung. Die ISP-verarbeiteten Bilddaten können Frames mit 16-Bit-Farbe und einem YUV420-Format beinhalten.
  • Der VIC-Block (z. B. der Verarbeitungsblock 202C) kann die ISP-verarbeiteten Bilddaten aus dem Speicher-Teilsystem 140 erhalten, die ISP-verarbeiteten Bilddaten verarbeiten und die VIC-verarbeiteten Bilddaten im Speicher-Teilsystem 140 speichern. Zum Beispiel kann der VIC-Block eine Linsenverzerrungskorrektur an Frames der ISP-verarbeiteten Bilddaten durchführen, die mit einer Weitwinkellinse aufgenommen wurden.
  • Der OFA-Block (z. B. der Verarbeitungsblock 202D) kann die VIC-verarbeiteten Bilddaten aus dem Speicher-Teilsystem 140 erhalten, die VIC-verarbeiteten Bilddaten verarbeiten und die OFA-verarbeiteten Bilddaten im Speicher-Teilsystem 140 speichern. Der OFA-Block kann eine Stereorektifizierung an den VIC-verarbeiteten Bilddaten (z. B. an Frames, die mit einem oder mehreren Stereoobjektiven aufgenommen wurden) durchführen und den optischen Fluss (z. B. für beide resultierenden Frames) bestimmen, um die Bewegung in der Szene zu bestimmen. Der VIC-Block kann auch eine Stereorektifizierungsoperation durchführen.
  • Der PVA-Block (z. B. der Verarbeitungsblock 202E) erhält die OFA-verarbeiteten Bilddaten aus dem Speicher-Teilsystem 140, verarbeitet die OFA-verarbeiteten Bilddaten und speichert die PVA-verarbeiteten Bilddaten im Speicher-Teilsystem 140. Der PVA-Block kann Berechnungen durchführen, die darauf abzielen, basierend auf der Anwendung verschiedene Arten von Objekten zu erkennen (z. B. unter Verwendung klassischer Algorithmen für maschinelles Sehen).
  • Der DLA-Block (z. B. der Verarbeitungsblock 202F) erhält die PVA-verarbeiteten Bilddaten aus dem Speicher-Teilsystem 140, verarbeitet die PVA-verarbeiteten Bilddaten und speichert die DLA-verarbeiteten Bilddaten im Speicher-Teilsystem 140. Der DLA-Block kann hochparallele mathematische Matrixoperationen durchführen, die die Hochgeschwindigkeitsverarbeitung von neuronalen Deep Learning-Netzen unterstützen.
  • Wenn sie für sicherheitskritische Funktionen wie beispielsweise eine oder mehrere der ADAS-Funktionen verwendet werden, müssen die Verarbeitungsblöcke 202A-202F möglicherweise die Anforderungen einer oder mehrerer Sicherheitsnormen für Kraftfahrzeuge (z. B. International Organization for Standardization („ISO“) 26262 Functional Safety Standard) erfüllen. Solche Sicherheitsnorm(en) für Kraftfahrzeuge können dazu beitragen, dass jegliches potenzielle Risiko (z. B. das die ADAS-Leistung beeinträchtigt) vernünftigerweise akzeptabel ist, zum Beispiel gemäß einem durch die automobilen Sicherheitsnorm(en) definierten Risikoklassifizierungslevel. Potenzielle Risiken können einen oder mehrere Hardwarefehler beinhalten. Die Sicherheitsüberwachung 106 kann die diagnostischen Operationen gemäß jeglichen anwendbaren Sicherheitsnormen für Kraftfahrzeuge einplanen. Zum Beispiel können die diagnostischen Operationen mit den funktionalen Operationen während eines gesamten Fahrzyklus verschachtelt werden, der beginnt, wenn das Fahrzeug 1000 startet (z. B. nachdem ein Key-On-Test bestimmt, dass das Fahrzeug 1000 eingeschaltet ist) und endet, wenn das Fahrzeug 1000 anhält (z. B. bevor ein Key-Off-Test bestimmt, dass das Fahrzeug 1000 ausgeschaltet ist). So kann das Verarbeitungssystem 102 während des gesamten Fahrzyklus abwechselnd funktionale Operationen und diagnostische Operationen durchführen.
  • Die ISO 26262 definiert vier Risikoklassifizierungslevel (auch als Automotive Safety Integrity Levels bezeichnet) ASIL-A, ASIL-B, ASIL-C und ASIL-D, wobei ASIL-D das höchste Risikoklassifizierungslevel ist und das höchste Sicherheitslevel angibt. Die Fehlererkennungsblöcke 312 vereinigt mit dem Einplanen von diagnostischen Operationen innerhalb des FTTI können dazu beitragen, das Risikoklassifizierungslevel des Verarbeitungssystems 102 zu erhöhen (z. B. von ASIL-B auf ASIL-C).
  • Die Sicherheitsnorm(en) für Kraftfahrzeuge kann/können verlangen, dass die Sicherheitsüberwachung 106 eine oder mehrere quantitative Messungen in Bezug auf jegliches Auftreten von Fehlern erfasst, wie beispielsweise eine Einpunkt-Fehlermetrik (single point fault metric - „SPFM“), eine latente Fehlermetrik („LFM“) und dergleichen. Die Sicherheitsnorm(en) für Kraftfahrzeuge kann/können verlangen, dass die Sicherheitsüberwachung 106 einen Hardwarefehler erkennt, den Hardwarefehler berichtet und innerhalb einer von dem FTTI vorgegebenen Zeitspanne auf den Hardwarefehler reagiert.
  • Unter erneuter Bezugnahme auf 3 kann durch das Einbeziehen der Fehlererkennungsblöcke 312 in die DPU 232 jeder der Verarbeitungsblöcke 202A-202F die Beobachtbarkeit von Fehlereffekten verbessern, die Erkennung von Fehlern mit größerer Granularität ermöglichen und den lokalen Prozessorblock 230 für andere Aufgaben entlasten. Wenn das Verarbeitungssystem 102 eine Komponente (z. B. eine Pipeline für maschinelles Sehen) eines autonomen Fahrzeugs ist (z. B. das in 10A-10D veranschaulichte Fahrzeug 1000), können diese Verbesserungen dazu beitragen, die Fahrzeugsicherheit zu erhöhen.
  • Die hierin beschriebenen Systeme und Verfahren können ohne Einschränkung durch nicht autonome Fahrzeuge, teilautonome Fahrzeuge (z. B. in einem oder mehreren adaptiven Fahrerassistenzsystemen („ADAS“)), gelotste und nicht gelotste Roboter oder Rotoberplattformen, Lagerhausfahrzeuge, Offroad-Fahrzeuge, an einen oder mehrere Anhänger gekoppelte Fahrzeuge, Flugschiffe, Boote, Shuttles, Rettungsfahrzeuge, Motorräder, elektrische oder motorisierte Fahrräder, Luftfahrzeuge, Baufahrzeuge, Unterwasserfahrzeuge, Drohnen und/oder andere Fahrzeugtypen verwendet werden. Die hierin beschriebenen Systeme und Verfahren können für eine Vielfalt von Zwecken verwendet werden, beispielsweise und ohne Einschränkung für Maschinensteuerung, Maschinenbewegung, Maschinenfahren, Erzeugung synthetischer Daten, Digital Twinning, Modelltraining, Wahrnehmung, erweiterte Realität, virtuelle Realität, gemischte Realität, Robotik, Sicherheit und Überwachung, autonome oder teilautonome Maschinenanwendungen, Deep Learning, Umgebungssimulation, Rechenzentrumsverarbeitung, Konversations-KI, Lichttransportsimulation (z. B. Raytracing, Pathtracing usw.), kollaborative Inhaltserstellung für 3D-Assets, Cloud-Computing und/oder beliebige andere geeignete Anwendungen.
  • Offenbarte Ausführungsformen können in einer Vielfalt unterschiedlicher Systeme umfasst sein, wie etwa Automobilsystemen (z. B. einem Steuersystem für eine autonome oder teilautonome Maschine, einem Wahrnehmungssystem für eine autonome oder teilautonome Maschine), Systemen, die unter Verwendung eines Roboters implementiert sind, Antennensystemen, medialen Systemen, Bootssystemen, intelligenten Bereichsüberwachungssystemen, Systemen zur Durchführung von Deep-Learning-Operationen, Systemen zur Durchführung von Simulations- und digitale Zwillingsoperationen, die unter Verwendung einer Edge-Vorrichtung implementiert sind, Systemen, die eine oder mehrere virtuelle Maschinen (VMs) enthalten, Systemen zum Durchführen von Operationen zur Erzeugung synthetischer Daten, Systemen, die mindestens teilweise in einem Rechenzentrum implementiert sind, Systemen zur Durchführung von Konversations-KI-Operationen, Systemen zur Durchführung von Lichttransportsimulation, Systemen zur Durchführung von kollaborativer Inhaltserstellung für 3D-Assets, Systemen, die mindestens teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert sind, und/oder anderen Arten von Systemen.
  • BEISPIEL FÜR EIN AUTONOMES FAHRZEUG
  • 10A ist eine Veranschaulichung des beispielhaften autonomen Fahrzeugs 1000 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 1000 (hierin alternativ als „Fahrzeug 1000“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug beinhalten, wie etwa ein Auto, einen Lastwagen, einen Bus, ein Rettungsfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, einen Feuerwehrwagen, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B., das unbemannt ist und/oder einen oder mehrere Passagiere beherbergt). Autonome Fahrzeuge werden im Allgemeinen im Hinblick auf Automatisierungslevels beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (z. B. Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert sind. Das Fahrzeug 1000 kann zu einer Funktionalität gemäß einem oder mehreren von Level 3 - Level 5 der Levels für autonomes Fahren in der Lage sein. Zum Beispiel kann das Fahrzeug 1000 in Abhängigkeit von der Ausführungsform zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.
  • Das Fahrzeug 1000 kann Komponenten wie etwa Chassis, Karosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs beinhalten. Das Fahrzeug 1000 kann ein Antriebssystem 1050 beinhalten, wie etwa eine Brennkraftmaschine, ein Hybridelektrotriebwerk, einen vollelektrischen Motor und/oder einen anderen Typ von Antriebssystem. Das Antriebssystem 1050 kann mit einem Antriebsstrang des Fahrzeugs 1000 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 1000 zu ermöglichen. Das Antriebssystem 1050 kann als Reaktion auf das Empfangen von Signalen von der Drossel/dem Fahrpedal 1052 gesteuert werden.
  • Ein Lenksystem 1054, das ein Lenkrad beinhalten kann, kann verwendet werden, um das Fahrzeug 1000 zu lenken (z. B. entlang eines gewünschten Pfads oder einer gewünschten Route), wenn das Antriebssystem 1050 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1054 kann Signale von einem Lenkaktor 1056 empfangen. Für die vollständige Automatisierungsfunktionalität (Level 5) kann das Lenkrad optional sein.
  • Das Bremssensorsystem 1046 kann zur Betätigung der Fahrzeugbremsen verwendet werden, wenn Signale von den Bremsaktoren 1048 und/oder Bremssensoren empfangen werden.
  • Die Steuerung(en) 1036, der/die eine oder mehrere CPU(s), System on Chips (SoCs) 1004 (10C) und/oder GPU(s) beinhalten kann/können, kann/können Signale (z. B. stellvertretend für Befehle) für eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1000 bereitstellen. Die Steuerung(en) kann/können z. B. Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktoren 1048, zur Betätigung des Lenksystems 1054 über einen oder mehrere Lenkaktoren 1056, und/oder zur Betätigung des Antriebssystems 1050 über ein oder mehrere Drossel-/Fahrpedale 1052 senden. Die Steuerung(en) 1036 kann/können eine oder mehrere bordeigene (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) beinhalten, 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 1000 zu unterstützen. Die Steuerung(en) 1036 kann/können eine ersten Steuerung 1036 für Funktionen des autonomen Fahrens, eine zweiten Steuerung 1036 für funktionelle Sicherheitsfunktionen, eine dritte Steuerung 1036 für eine Funktionalität der künstlichen Intelligenz (z. B. maschinelles Sehen), eine vierte Steuerung 1036 für eine Infotainment-Funktionalität, eine fünfte Steuerung 1036 für Redundanz in Notfällen und/oder andere Steuerungen beinhalten. In einigen Beispielen kann eine einzelne Steuerung 1036 zwei oder mehrere der vorstehenden Funktionalitäten handhaben, können zwei oder mehr Steuerungen 1036 eine einzelne Funktionalität handhaben und/oder eine beliebige Kombination davon.
  • Die Steuerung(en) 1036 stellt/stellen Signale zum Steuern einer/eines oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1000 als Reaktion auf Sensordaten bereit, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten können zum Beispiel und ohne Einschränkung empfangen werden von Sensor(en) 1058 von globalen Navigationssatellitensystemen (z. B. Sensor(en) des globalen Positionsbestimmungssystems), RADAR-Sensor(en) 1060, Vibrationssensor(en) 1062, LIDAR-Sensor(en) 1064, Sensor(en) 1066 einer Trägheitsmesseinheit (inertial measurement unit - IMU) (z. B. Beschleunigungsmesser(n), Gyroskop(en), Magnetkompass(en), Magnetometer(n) usw.), Mikrofon(en) 1096, Stereokamera(s) 1068, Weitwinkelkamera(s) 1070 (z. B. Fischaugenkameras), Infrarotkamera(s) 1072, Rundumkamera(s) 1074 (z. B. 360-Grad-Kameras), Langstrecken- und/oder Mittelstreckenkamera(s) 1098, Geschwindigkeitssensor(en) 1044 (z. B. zum Messen der Geschwindigkeit des Fahrzeugs 1000), Vibrationssensor(en) 1042, Lenksensor(en) 1040, Bremssensor(en) 1046 (z. B. als Teil des Bremssensorsystems 1046) und/oder anderen Sensortypen.
  • Eine oder mehrere der Steuerung(en) 1036 kann/können Eingaben (z. B. durch Eingabedaten dargestellt) von einem Kombiinstrument 1032 des Fahrzeugs 1000 empfangen und Ausgaben (z. B. durch Ausgabedaten, Anzeigedaten usw. dargestellt) über eine Anzeige 1034 einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1000 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Geschwindigkeit, Zeit, Kartendaten (z. B. die HD-Karte 1022 aus 10C), Positionsdaten (z. B. die Position des Fahrzeugs 1000, wie etwa auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie sie von den Controllern 1036 wahrgenommen werden usw. beinhalten. Auf der HMI-Anzeige 1034 können beispielsweise Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. Straßenschild, Warnschild, Ampelschaltungen usw.) und/oder Informationen über Fahrmanöver angezeigt werden, die das Fahrzeug unternommen hat, gerade macht oder durchführen wird (z. B. jetzt Spurwechsel, Ausfahrt 34B in zwei Meilen nehmen usw.).
  • Das Fahrzeug 1000 kann ferner eine Netzschnittstelle 1024, die drahtlose Antenne(n) 1026 und/oder Modem(s) zum Kommunizieren über ein oder mehrere Netze verwenden. Zum Beispiel kann die Netzschnittstelle 1024 zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. fähig sein. Die drahtlose(n) Antenne(n) 1026 kann bzw. können zudem die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeugen, mobilen Vorrichtungen usw.) unter Verwendung von (einem) lokalen Netz(en) wie etwa Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Weitverkehrsnetz(en) mit geringem Stromverbrauch (low power wide-area networks - LPWANs) wie etwa LoRaWAN, SigFox usw. ermöglichen.
  • 10B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug 1000 aus 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die entsprechenden Sichtfelder stellen eine beispielhafte Ausführungsform dar und sind nicht als einschränkend aufzufassen. Zum Beispiel können zusätzliche und/oder alternative Kameras enthalten sein und/oder können sich die Kameras an unterschiedlichen Positionen am Fahrzeug 1000 befinden.
  • Die Kameratypen für Kameras können Digitalkameras beinhalten, ohne darauf beschränkt zu sein, die zur Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 1000 ausgelegt sind. Die Kamera(s) kann/können mit dem Automobilsicherheitsintegritätslevel (automotive safety integrity level - ASIL) B und/oder mit einem anderen ASIL betrieben werden. Die Kameraarten können in Abhängigkeit von der Ausführungsform zu einer beliebigen Bildaufnahmerate in der Lage sein, wie etwa 60 Bilder pro Sekunde (frames per second - fps), 120 fps, 240 fps usw. Die Kameras können dazu in der Lage sein, Rollblendenverschlüsse, globale Blendenverschlüsse, einen anderen Typ von Blendenverschluss oder eine Kombination davon zu verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar (red clear clear clear - RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau (red clear clear blue - RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar (red blue green clear - RBGC)-Farbfilteranordnung, eine Foveon-X3-Farbfilteranordnung, eine Bayer-Sensoren (RGGB)-Farbfilteranordnung, eine Monochrom-Sensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können Klarpixelkameras, wie zum Beispiel Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, in einem Bestreben zur Erhöhung der Lichtempfindlichkeit verwendet werden.
  • In einigen Beispielen können eine oder mehrere der Kamera(s) verwendet werden, um Funktionen der weiterentwickelten Fahrerassistenzsysteme (advanced driver assistance systems - ADAS) durchzuführen (z. B. als Teil einer redundanten oder ausfallsicheren Ausgestaltung). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, die Funktionen wie Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitstellt. Eine oder mehrere der Kamera(s) (z. B. alle Kameras) können simultan Bilddaten (z. B. ein Video) aufnehmen und bereitstellen.
  • Eine oder mehrere der Kameras können in einer Montagebaugruppe, z. B. einer kundenspezifisch entworfenen (3D-gedruckten) Baugruppe, montiert sein, um Streulicht und Reflexionen aus dem Inneren des Autos (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschließen, welche die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. Unter Bezugnahme auf Außenspiegel-Montagebaugruppen können die Außenspiegelbaugruppen kundenspezifisch in 3D gedruckt werden, sodass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen kann/können die Kamera(s) in den Außenspiegel integriert sein. Bei Seitensichtkameras kann/können die Kamera(s) auch in den vier Säulen an jeder Ecke des Fahrerhauses integriert sein.
  • Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 1000 beinhaltet (z. B. nach vom gerichtete Kameras), können für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorn gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe einer oder mehrerer Steuerungen 1036 und/oder Steuer-SoCs beim Bereitstellen von Informationen zu helfen, die für die Erzeugung eines Belegungsrasters und/oder die Bestimmung bevorzugter Fahrzeugpfade entscheidend sind. Nach vom gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich Spurverlassenswarnungen (Lane Departure Warning - LDW), autonome Geschwindigkeitssteuerung (Autonomous Cruise Control - ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung.
  • Vielfältige Kameras können in einer nach vorne gerichteten Konfiguration verwendet werden, einschließlich zum Beispiel einer monokularen Kameraplattform, die einen Farbbildsensor mit CMOS (complementary metal oxide semiconductor - komplementärer Metalloxid-Halbleiter) beinhaltet. Ein weiteres Beispiel ist/sind (eine) Weitwinkelkamera(s) 1070, die verwendet werden kann/können, um Objekte wahrzunehmen, die aus der Peripherie in den Blick kommen (z. B. Fußgänger, Kreuzungsverkehr oder Fahrräder). Obwohl in 10B nur eine Weitwinkelkamera veranschaulicht ist, kann eine beliebige Anzahl von Weitwinkelkameras 1070 an dem Fahrzeug 1000 vorhanden sein. Zusätzlich kann eine Langstreckenkamera(s) 1098 (z. B. ein Weitsichtstereokamerapaar) zur tiefenbasierten Objektdetektion verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert worden ist. Die Langstreckenkamera(s) 1098 kann/können auch zur Objekterkennung und -klassifizierung sowie zur einfachen Objektverfolgung verwendet werden.
  • Eine oder mehrere Stereokameras 1068 können auch in einer nach vorne gerichteten Konfiguration beinhaltet sein. Die Stereokamera(s) 1068 können eine integrierte Steuereinheit beinhalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (z. B. FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten Schnittstelle für ein CAN oder Ethernet auf einem einzelnen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3D-Karte der Umgebung des Fahrzeugs zu erzeugen, die eine Abstandsschätzung für alle Punkte im Bild beinhaltet. Eine oder mehrere alternative Stereokamera(s) 1068 können (einen) kompakte(n) Stereosichtsensor(en) beinhalten, die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip beinhalten können, die den Abstand von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) verwenden können, um autonome Notbrems- und Spurverlassenswarnfunktionen zu aktivieren. Andere Typen von Stereokamera(s) 1068 können zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.
  • Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 1000 beinhaltet (z. B. Seitensichtkameras), können für die Rundumsicht verwendet werden, wodurch Informationen bereitgestellt werden, die zum Erstellen und Aktualisieren eines Belegungsrasters sowie zum Erzeugen von Seitenaufprallkollisionswarnungen verwendet werden. Zum Beispiel könnten die Umgebungskamera(s) 1074 (z. B. vier Umgebungskameras 1074, wie in 10B veranschaulicht) an dem Fahrzeug 1000 positioniert sein. Die Umgebungskamera(s) 1074 kann/können Weitwinkelkameras 1070, Fischaugenkameras, 360-Grad-Kameras und/oder dergleichen beinhalten. Zum Beispiel können vier Fischaugenkameras an der Front, am Heck und an den Seiten des Fahrzeugs positioniert sein. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskameras 1074 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kameras (z. B. eine nach vorne gerichtete Kamera) als vierte Umgebungssichtkamera nutzen.
  • Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 1000 beinhaltet (z. B. Rückfahrkameras), können als Einparkhilfe, für die Rundumsicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Es kann eine große Vielfalt an Kameras verwendet werden, einschließlich unter anderem Kameras, die auch als nach vorne gerichtete Kamera(s) (z. B. Langstreckenkameras und/oder Mittelstreckenkamera(s) 1098, Stereokamera(s) 1068, Infrarotkamera(s) 1072 usw.) geeignet sind, wie hierin beschrieben.
  • 10C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 1000 von 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Jede(s) der Komponenten, Merkmale und Systeme des Fahrzeugs 1000 in 10C sind als über den Bus 1002 verbunden veranschaulicht. Der Bus 1002 kann eine Controller Area Network (CAN)-Datenschnittstelle beinhalten (alternativ hierin auch als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netz innerhalb des Fahrzeugs 1000 sein, das verwendet wird, um die Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1000 zu unterstützen, wie etwa Betätigung von Bremsen, Beschleunigung, Bremsung, Lenkung, Windschutzscheibenwischer usw. Ein CAN-Bus kann so konfiguriert sein, dass er dutzende oder sogar hunderte von Knoten aufweist, von denen jeder eine eigene eindeutige Kennung (z. B. eine CAN-ID) aufweist. Der CAN-Bus kann ausgelesen werden, um Lenkradwinkel, Geschwindigkeit über Grund, Motorumdrehungen pro Minute (U/min), Tastenpositionen und/oder andere Fahrzeugstatusindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 1002 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Auch dies soll, obwohl eine einzelne Leitung verwendet wird, um den Bus 1002 darzustellen, nicht einschränkend sein. Zum Beispiel kann eine beliebige Anzahl von Bussen 1002 vorhanden sein, die einen oder mehr CAN-Busse, einen oder mehr FlexRay-Busse, einen oder mehr Ethernet-Busse und/oder einen oder mehr andere Arten von Bussen mit einem anderen Protokoll beinhalten können. In einigen Beispiel können zwei oder mehr Busse 1002 verwendet werden, um unterschiedliche Funktionen durchzuführen, und/oder können sie zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 1002 für die Funktionalität der Kollisionsvermeidung verwendet werden und ein zweiter Bus 1002 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1002 mit beliebigen Komponenten des Fahrzeugs 1000 kommunizieren und können zwei oder mehr Busse 1002 mit denselben Komponenten kommunizieren. In einigen Beispielen können jedes SoC 1004, jede Steuerung 1036 und/oder jeder Computer im Fahrzeug Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 1000) haben und mit einem gemeinsamen Bus, wie etwa dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 1000 kann eine oder mehrere Steuerung(en) 1036 beinhalten, wie etwa diejenigen, die hierin in Bezug auf 10A beschrieben sind. Die Steuerung(en) 1036 können für eine Vielfalt von Funktionen verwendet werden. Die Steuerung(en) 1036 können mit beliebigen der verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1000 gekoppelt sein und können zur Steuerung des Fahrzeugs 1000, der künstlichen Intelligenz des Fahrzeugs 1000, des Infotainment für das Fahrzeug 1000 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 1000 kann ein System (oder mehrere Systeme) auf einem Chip (SoC) 1004 beinhalten. Das SoC 1004 kann CPU(s) 1006, GPU(s) 1008, Prozessor(en) 1010, Cache(s) 1012, Beschleuniger 1014, Datenspeicher 1016 und/oder andere nicht abgebildete Komponenten und Funktionen beinhalten. Die SoC(s) 1004 können zum Steuern des Fahrzeugs 1000 in einer Vielfalt an Plattformen und Systemen verwendet werden. Die SoC(s) 1004 können beispielsweise in einem System (z. B. dem System des Fahrzeugs 1000) mit einer HD-Karte 1022 kombiniert werden, die über eine Netzschnittstelle 1024 Aktualisierungen der Karte und/oder Updates von einem oder mehreren Servern (z. B. Server 1078 der 10D) erhalten kann.
  • Die CPU(s) 1006 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 1006 können mehrere Kerne und/oder L2-Caches beinhalten. Zum Beispiel können in einigen Ausführungsformen die CPU(s) 1006 acht Kerne in einer kohärenten Mehrprozessorkonfiguration beinhalten. In einigen Ausführungsformen kann/können die CPU(s) 1006 vier Dual-Core-Cluster beinhalten, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen 2 MB-L2-Cache). Die CPU(s) 1006 (z. B. CCPLEX) können so konfiguriert sein, dass sie simultane Clusteroperationen unterstützen, sodass eine beliebige Kombination von Clustern der CPU(s) 1006 zu einem beliebigen gegebenen Zeitpunkt aktiv sein kann.
  • Die CPU(s) 1006 können Leistungsverwaltungsfähigkeiten implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardwareblöcke können automatisch taktgesteuert werden, wenn sie inaktiv sind, um dynamische Leistung zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Anweisungen keine Anweisungen aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder leistungsgesteuert sind; und/oder jeder Kerncluster kann unabhängig leistungsgesteuert sein, wenn alle Kerne leistungsgesteuert sind. Die CPU(s) 1006 können ferner einen erweiterten Algorithmus zur Verwaltung von Leistungsstatus implementieren, bei dem zulässige Leistungsstatus und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode den besten Leistungsstatus bestimmt, in den für den Kern, Cluster und CCPLEX einzutreten ist. Die Verarbeitungskerne können vereinfachte Leistungsstatus-Eintragssequenzen in der Software unterstützen, wobei die Arbeit in den Mikrocode ausgelagert wird.
  • Die GPU(s) 1008 können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 1008 können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 1008 können in einigen Beispielen einen erweiterten Tensor-Anweisungssatz verwenden. Die GPU(s) 1008 können einen oder mehrere Streaming-Mikroprozessoren beinhalten, wobei jeder Streaming-Mikroprozessor einen Level-Eins-(„L1“)Cache beinhalten kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr Streaming-Mikroprozessoren können einen L2-Cache gemeinsam nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 512 KB). In einigen Ausführungsformen können die GPU(s) 1008 mindestens acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 1008 können computerbasierte Anwendungsprogrammierschnittstelle(n) (API(s)) verwenden. Zusätzlich können die GPU(s) 1008 eine oder mehrere Parallelrechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
  • Die GPU(s) 1008 können für die beste Rechenleistung in Automobil- und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1008 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies soll jedoch nicht einschränkend sein und die GPU(s) 1008 kann/können mithilfe anderer Halbleiterfertigungsprozesse hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit beinhalten, die in mehrere Blöcke partitioniert sind. Zum Beispiel, und ohne Einschränkung, könnten 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. In solch einem Beispiel könnten jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0- Anweisungs-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine Registerdatei mit 64 KB zugewiesen sein. Zusätzlich können Streaming-Mikroprozessoren unabhängige parallele Integer- und Fließkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnung und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion beinhalten, um eine feinkörnigere Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können eine Einheit aus kombiniertem L1-Daten-Cache und gemeinsam genutztem Speicher beinhalten, um die Performance zu verbessern, während die Programmierung vereinfacht wird.
  • Die GPU(s) 1008 können einen Speicher mit hoher Bandbreite (high bandwidth memory - HBM) und/oder ein 16-GB-HBM2-Speicherteilsystem beinhalten, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (synchronous graphics random-access memory - SGRAM) verwendet werden, wie etwa ein synchroner Direktzugriffsspeicher vom Graphics-Double-Data-Rate-Typ fünf (graphics double data rate type five - GDDR5).
  • Die GPU(s) 1008 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern beinhalten, die eine genauere Zuweisung von Speicherseiten an den Prozessor ermöglicht, der am häufigsten darauf zugreift, und so die Effizienz von Speicherbereichen verbessert, die von mehreren Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 1008 direkt auf die Seitentabellen der CPU(s) 1006 zugreifen können. In solchen Beispielen kann, wenn die GPU(s) 1008 Speicherverwaltungseinheit (memory management unit - MMU) einen Fehlschlag erleidet, eine Adressübersetzungsanforderung an die CPU(s) 1006 gesendet werden. Als Reaktion darauf können die CPU(s) 1006 in ihren Seitentabellen nach einer Virtuell-zu-Physisch-Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1008 übertragen. Daher kann die einheitliche Speichertechnologie einen einzelnen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1006 als auch der GPU(s) 1008 ermöglichen, wodurch die Programmierung der GPU(s) 1008 und die Portierung von Anwendungen auf die GPU(s) 1008 vereinfacht werden.
  • Darüber hinaus kann die GPU(s) 1008 einen Zugriffszähler beinhalten, der die Häufigkeit des Zugriffs der GPU(s) 1008 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.
  • Die SoC(s) 1004 können eine beliebige Anzahl von Cache(s) 1012 beinhalten, einschließlich der hierin beschriebenen. Der/die Cache(s) 1012 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 1006 als auch der/den GPU(s) 1008 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 1006 als auch mit der/den GPU(s) 1008 verbunden ist). Der/die Cache(s) 1012 können einen Rückschreib-Cache beinhalten, der die Status von Zeilen verfolgen kann, wie z. B. durch die Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann in Abhängigkeit von der Ausführungsform 4 MB oder mehr beinhalten, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Der/die SoC(s) 1004 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) beinhalten, die beim Durchführen von Verfahren in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 1000, wie etwa der Verarbeitung von DNNs, genutzt werden kann. Darüber hinaus können die SoC(s) 1004 eine oder mehrere Gleitkommaeinheiten (floating point units - FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessoren - zur Durchführung mathematischer Operationen innerhalb des Systems beinhalten. Zum Beispiel kann der SoC(s) 104 eine oder mehrere FPUs beinhalten, die als Ausführungseinheiten in einer CPU(s) 1006 und/oder GPU(s) 1008 integriert sind.
  • Das/die SoC(s) 1004 können einen oder mehrere Beschleuniger 1014 beinhalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel können das/die SoC(s) 1004 einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder einen großen chipinternen Speicher beinhalten kann. Der große chipinterne Speicher (z. B. 4 MB SRAM) kann einen Hardware-Beschleunigungscluster zur Beschleunigung neuronaler Netze und anderer Berechnungen ermöglichen. Der Hardware-Beschleunigungscluster kann verwendet werden, um die GPU(s) 1008 zu ergänzen und einige Aufgaben der GPU(s) 1008 auszulagern (z. B. mehr Zyklen der GPU(s) 1008 zum Durchführen anderer Aufgaben freizumachen). Als Beispiel können der/die Beschleuniger 1014 für zielgerichtete Arbeitslasten (z. B. Wahrnehmung, neuronale Faltungsnetze (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hierin verwendet wird, kann alle Typen von CNNs beinhalten, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetze (RCNNs) und Fast RCNNs (z. B. für die Objekterkennung).
  • Der/die Beschleuniger 1014 (z. B. Hardware-Beschleunigungscluster) können (einen) Deep-Learning-Beschleuniger (deep learning accelerator(s) - DLA(s)) beinhalten. Der/die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPUs) beinhalten, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Vorgänge pro Sekunde für Deep-Learning-Anwendungen und -Inferenzierung bereitstellen. Die TPUs können Beschleuniger sein, die zum Durchführen von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) können ferner für einen spezifischen Satz von Arten von neuronalen Netzen und Gleitkommaoperationen sowie zum Inferenzieren optimiert sein. Die Ausgestaltung der DLA(s) kann mehr Performance pro Millimeter bereitstellen als eine typische Universal-GPU und übertrifft die Performance einer CPU bei weitem. Die TPU(s) können mehrere Funktionen durchführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datenarten sowohl für Merkmale als auch für Gewichtungen unterstützt, sowie Postprozessorfunktionen.
  • Die DLA(s) können neuronale Netze, insbesondere CNNs, an verarbeiteten oder unverarbeiteten Daten für beliebige einer Vielfalt von Funktionen schnell und effizient ausführen, darunter zum Beispiel und ohne Einschränkung: ein CNN für die Identifizierung und Erkennung von Obj ekten 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 und Erkennung von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheits- und/oder sicherungsbezogene Ereignisse.
  • Die DLA(s) können eine beliebige Funktion der GPU(s) 1008 durchführen und durch Verwenden eines Inferenzbeschleunigers kann ein Konstrukteur zum Beispiel entweder DLA(s) oder GPU(s) 1008 für eine beliebige Funktion anvisieren. So kann der Konstrukteur beispielsweise die Verarbeitung von CNNs und Gleitkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1008 und/oder anderen Beschleunigern 1014 überlassen.
  • Der/die Beschleuniger 1014 (z. B. der Hardware-Beschleunigungscluster) können (einen) programmierbare(n) Sichtbeschleuniger (programmable vision accelerator - „PVA“) beinhalten, der hierin alternativ als ein Beschleuniger für maschinelles Sehen bezeichnet werden kann. Die PVA(s) können zur Beschleunigung von Algorithmen des maschinellen Sehens für weiterentwickelte Fahrerassistenzsysteme (ADAS), autonomes Fahren, Augmented-Reality(AR)- und/oder Virtual-Reality(VR)-Anwendungen ausgestaltet und konfiguriert sein. Die PVA(s) können ein Gleichgewicht zwischen Performance und Flexibilität bereitstellen. Beispielsweise und ohne Einschränkung können alle PVA(s) eine beliebige Anzahl von Reduced-Instruction-Set-Computer (RISC)-Kernen, direkten Speicherzugriff (direct memory access - DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.
  • RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer beliebigen der hierin beschriebenen Kameras), (einem) Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher beinhalten. Die RISC-Kerne können in Abhängigkeit von der Ausführungsform ein beliebiges von einer Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (real-time operating system - RTOS) ausführen. Die RISC-Kerne können unter Verwendung einer oder mehrerer Vorrichtungen für integrierte Schaltungen, anwendungsspezifischer integrierter Schaltungen (ASICs) und/oder Speichervorrichtungen implementiert sein. Die RISC-Kerne können beispielsweise einen Anweisungs-Cache und/oder einen eng gekoppelten RAM beinhalten.
  • Der DMA kann es den Komponenten des/der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1006 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die verwendet werden, um dem PVA Optimierung bereitzustellen, einschließlich unter anderem Unterstützung von mehrdimensionaler Adressierung und/oder kreisförmiger 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 beinhalten können.
  • Die Vektorprozessoren können programmierbare Prozessoren sein, die so ausgestaltet sein können, dass sie die Programmierung für Algorithmen des maschinellen Sehens effizient und flexibel ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungsteilsystempartitionen beinhalten. Der PVA-Kern kann ein Prozessorteilsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte beinhalten. Das Vektorverarbeitungsteilsystem kann als primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungseinheit (vector processing unit - VPU), einen Anweisungs-Cache und/oder einen Vektorspeicher (z. B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor beinhalten, wie zum Beispiel einen digitalen Single-Instruction-Multiple-Data-(SIMD-)Very-Long-Instruction-Word-(VLIW-)Signalprozessor. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Anweisungs-Cache beinhalten und an dedizierten Speicher gekoppelt sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren ausgeführt wird. In anderen Beispielen können Vektorprozessoren, die in einem konkreten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität einsetzen. Zum Beispiel kann in einigen Ausführungsformen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten ist, denselben Algorithmus des maschinellen Sehens ausführen, jedoch an unterschiedlichen Regionen eines Bildes. In anderen Beispielen können die in einem konkreten PVA enthaltenen Vektorprozessoren simultan unterschiedliche Algorithmen des maschinellen Sehens an demselben Bild ausführen oder sogar unterschiedliche Algorithmen an sequentiellen Bildern oder Abschnitten eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungscluster enthalten sein und kann eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Zusätzlich können der/die PVA(s) einen zusätzlichen Fehlerkorrekturcode (ECC)-Speicher beinhalten, um die Gesamtsystemsicherheit zu erhöhen.
  • Der/die Beschleuniger 1014 (z. B. ein Hardware-Beschleunigungscluster) können ein Netz auf dem Chip für maschinelles Sehen und SRAM beinhalten, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1014 bereitzustellen. In einigen Beispielen kann der chipinterne Speicher mindestens 4 MB SRAM beinhalten, der z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine weiterentwickelte Peripheriebus (advanced peripheral bus - APB)-Schnittstelle, eine Konfigurationsschaltung, einen Controller und einen Multiplexer beinhalten. Es kann jede Art von Speicher verwendet werden. Der PVA und DLA können auf den Speicher über einen Backbone zugreifen, der dem PVA und DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. Der Backbone kann ein chipinternes Netz für maschinelles Sehen beinhalten, das den PVA und DLA mit dem Speicher verbindet (z. B. unter Verwendung vdes APB).
  • Das chipinterne Netz für maschinelles Sehen kann eine Schnittstelle beinhalten, die vor der Übertragung eines beliebigen Steuersignals/einer beliebigen Adresse/beliebiger Daten bestimmt, dass sowohl ein PVA als auch ein DLA einsatzbereite und gültige Signale bereitstellen. Eine derartige Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-artige Kommunikation für eine kontinuierliche Datenübertragung bereitstellen. 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) 1004 einen Echtzeitstrahlverfolgungs-Hardware-Beschleuniger beinhalten, wie er in der US-Patentanmeldung Nr. 16/101,232 , eingereicht am 10. August 2018, beschrieben ist. Der Echtzeit-Raytracing-Hardware-Beschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeitvisualisierungssimulationen 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 Zwecke der Lokalisierung und/oder für andere Funktionen und/oder für andere Anwendungen. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) verwendet werden, um eine oder mehrere Raytracing-bezogene Operationen auszuführen.
  • Der/die Beschleuniger 1014 (z. B. der Hardware-Beschleunigercluster) haben ein breites Spektrum von Einsatzmöglichkeiten für autonomes Fahren. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA sind eine gute Ergänzung für algorithmische Domänen, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz benötigen. Anders ausgedrückt zeigt der PVA eine gute Performance für halbdichte oder dichte reguläre Berechnungen, auch an kleinen Datensätzen, die vorhersagbare Laufzeiten mit niedriger Latenz und niedriger Leistung benötigen. Folglich sind die PVAs im Zusammenhang mit Plattformen für autonome Fahrzeuge für die Ausführung klassischer Algorithmen für maschinelles Sehen konstruiert, da diese effizient bei der Objekterkennung sind und mit Integer-Mathematik arbeiten.
  • Zum Beispiel wird gemäß einer Ausführungsform der Technologie der PVA verwendet, um maschinelles Stereo-Sehen durchzuführen. Ein auf semiglobalem Abgleich basierender Algorithmus kann verwendet werden, obwohl dies nicht als Einschränkung auszulegen ist. Viele Anwendungen für das autonome Fahren auf Level 3-5 erfordern Bewegungsschätzung/Stereo-Abgleich spontan (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Funktion des maschinellen Stereo-Sehens an Eingaben von zwei monokularen Kameras durchführen.
  • In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Der PVA kann zum Beispiel verwendet werden, um RADAR-Rohdaten zu verarbeiten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um ein verarbeitetes RADAR-Signal bereitzustellen, bevor der nächste RADAR-Impuls gesendet wird. In anderen Beispielen wird der PVA für die Laufzeit-Tiefenverarbeitung verwendet, indem z. B. Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten bereitzustellen.
  • Der DLA kann verwendet werden, um eine beliebige Art von Netz auszuführen, um die Steuerung und Fahrsicherheit zu verbessern, einschließlich zum Beispiel ein neuronales Netz, das ein Maß an Konfidenz für jede Objekterkennung ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit interpretiert werden oder als Bereitstellen einer relativen „Gewichtung“ der einzelnen Erkennungen im Vergleich zu anderen Erkennungen. Der Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als richtig positive Erkennungen und nicht als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellenwert für die Konfidenz festlegen und nur Erkennungen, die den Schwellenwert überschreiten, als richtig positive Erkennungen betrachten. In einem automatischen Notbrems (automatic emergency braking - AEB)-System 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. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwerts ausführen. Das neuronale Netz kann als seine Eingabe mindestens eine Teilmenge von Parametern verwenden, wie etwa die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Bodenebenenschätzung, die Ausgabe von Inertial Measurement Unit (IMU)-Sensor 1066, die mit der Ausrichtung des Fahrzeugs 1000 korreliert, den Abstand, die 3D-Positionsschätzungen des Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 1064 oder RADAR-Sensor(en) 1060) erhalten werden, usw.
  • Das/die SoC(s) 1004 können Datenspeicher 1016 (z. B. Speicher) beinhalten. Der bzw. die Datenspeicher 1016 kann bzw. können On-Chip-Speicher des bzw. der SoC(s) 1004 sein, der neuronale Netze speichern kann, die auf der GPU und/oder dem DLA ausgeführt werden sollen. In einigen Beispiel kann die Kapazität des/der Datenspeicher(s) 1016 groß genug sein, um mehrere Instanzen von neuronalen Netzen zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1016 können L2 oder L3 Cache(s) 1012 umfassen. Der Verweis auf den/die Datenspeicher 1016 kann einen Verweis auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 1014 zugeordnet ist, wie hier beschrieben.
  • Das/die SoC(s) 1004 kann/können einen oder mehrere Prozessor(en) 1010 (z. B. eingebettete Prozessoren) beinhalten. Der/die Prozessor(en) 1010 können einen Booting- und Leistungsverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Teilsystem sein kann, um die Booting-Leistungs- und -verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Booting- und Leistungsverwaltungsprozessor kann ein Teil der Booting-Sequenz des/der SoC(s) 1004 sein und Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Boot- und Energieverwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen des Systems in einen Zustand mit niedriger Leistung, Verwaltung von Thermo- und Temperatursensoren der SoC(s) 1004 und/oder Verwaltung von Leistungszuständen der SoC(s) 1004 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und die SoC(s) 1004 können Ringoszillatoren verwenden, um Temperaturen von CPU(s) 1006, GPU(s) 1008 und/oder Beschleuniger(n) 1014 zu detektieren. Falls bestimmt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Booting- und Leistungsverwaltungsprozessor dann in eine Temperaturfehlerroutine eintreten und die SoC(s) 1004 in einen Zustand mit niedrigerer Leistung versetzen und/oder das Fahrzeug 1000 in einen Modus des Fahrens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 1000 zu einem sicheren Halt bringen).
  • Der/die Prozessor(en) 1010 können ferner einen Satz von eingebetteten Prozessoren beinhalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audioteilsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der/die Prozessor(en) 1010 können ferner eine stets eingeschaltete Prozessor-Engine beinhalten, die notwendige Hardware-Merkmale zum Unterstützen der Sensorverwaltung bei niedriger Leistung und der Aufweck-Anwendungsfälle bereitstellen kann. Die stets eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Zeitgeber und Unterbrechungssteuerungen), verschiedene E/A-Steuerungsperipheriegeräte und Routing-Logik beinhalten.
  • Der/die Prozessor(en) 1010 kann/können außerdem eine Sicherheits-Cluster-Engine beinhalten, die ein dediziertes Prozessor-Subsystem für das Sicherheitsmanagement für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Zeitgeber, eine Unterbrechungssteuerung usw.) und/oder Routing-Logik beinhalten. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einzelner Kern mit einer Vergleichslogik funktionieren, um beliebige Unterschiede zwischen ihren Vorgängen zu erkennen.
  • Der/die Prozessor(en) 1010 können ferner eine Echtzeitkamera-Engine beinhalten, die ein dediziertes Prozessorteilsystem zur Handhabung der Echtzeitkameraverwaltung beinhalten kann.
  • Der/die Prozessor(en) 1010 können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
  • Der/die Prozessor(en) 1010 können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Fenster des Wiedergabeprogramms zu produzieren. Der Videobildkompositor kann eine Objektivverzeichnungskorrektur an den Weitsichtkamera(s) 1070, Rundumkamera(s) 1074 und/oder kabineninternen Überwachungskamerasensoren durchführen. Ein kabineninterner Überwachungskamerasensor wird vorzugsweise durch ein neuronales Netz überwacht, das auf einer anderen Instanz des fortgeschrittenen SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Ziel des Fahrzeugs zu ändern, das Infotainmentsystem des Fahrzeugs und dessen Einstellungen zu aktivieren oder zu ändern oder sprachaktiviertes Surfen im Internet bereitzustellen. Dem Fahrer stehen bestimmte Funktionen nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
  • Der Videobildkompositor kann eine erweiterte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung beinhalten. Wenn, zum Beispiel Bewegung in einem Video vorkommt, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend, indem sie die Gewichtung der Informationen, die von benachbarten Frames bereitgestellt werden, verringert. Wenn ein Bild oder ein Abschnitt eines Bildes keine Bewegung beinhaltet, kann die durch den Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen in einem derzeitigen Bild zu unterdrücken.
  • Der Videobildkompositor kann auch so konfiguriert werden, dass Stereo-Rektifikation auf Stereoeingangs-Linsenframes durchgeführt wird. Der Videobildkompositor kann ferner für die Benutzerschnittstellenzusammensetzung verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1008 nicht zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Auch wenn die GPU(s) 1008 eingeschaltet ist/sind und aktiv 3D-Rendering durchführt/durchführen, kann der Videobildkompositor verwendet werden, um die GPU(s) 1008 zu entlasten und so die Leistung und Reaktionsfähigkeit zu verbessern.
  • Das/die SoC(s) 1004 können ferner eine serielle Mobile-Industry-Processor-Interface (MIPI)-Kameraschnittstelle zum Empfangen von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock beinhalten, der für Kamera- und zugehörige Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 1004 können ferner (eine) Eingabe/Ausgabe-Steuerung(en) beinhalten, die durch Software gesteuert werden können und für den Empfang von E/A-Signalen verwendet werden können, die keiner bestimmten Rolle zugewiesen sind.
  • Das SoC 1004 kann darüber hinaus eine breite Palette von Peripherieschnittstellen enthalten, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, Energieverwaltung und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 1004 kann/können verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 1064, RADAR-Sensor(en) 1060 usw., die über Ethernet verbunden sein können), Daten vom Bus 1002 (z. B. Geschwindigkeit des Fahrzeugs 1000, Lenkradposition usw.), Daten von GNSS-Sensor(en) 1058 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das/die SoC(s) 1004 kann/können ferner dedizierte Hochleistungssteuerungen für die Massenspeicherung beinhalten, die ihre eigenen DMA-Engines enthalten können und die verwendet werden können, um die CPU(s) 1006 von Routineaufgaben der Datenverwaltung zu befreien.
  • Die SoC(s) 1004 können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, die die Automatisierungslevels 3-5 überspannt und dadurch eine umfassende funktionelle Sicherheitsarchitektur bereitstellt, die Techniken des maschinellen Sehens und des ADAS für Diversität und Redundanz ausnutzt und effizient einsetzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftwarestapel zusammen mit Deep-Learning-Werkzeugen bereitstellt. Das/die SoC(s) 1004 können schneller, zuverlässiger und sogar energieeffizienter und raumeffizienter sein als herkömmliche Systeme. Zum Beispiel können der/die Beschleuniger 1014, wenn sie mit den CPU(s) 1006, GPU(s) 1008 und Datenspeicher(n) 1016 kombiniert sind, eine schnelle, effiziente Plattform für autonome Fahrzeuge der Levels 3-5 bereitstellen.
  • Die Technologie stellt somit Möglichkeiten und Funktionen bereit, die mit herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Algorithmen des maschinellen Sehens auf CPUs ausgeführt werden, die unter Verwendung einer Programmiersprache auf hohem Level, wie z. B. der Programmiersprache C, konfiguriert werden können, um eine große Vielfalt von Verarbeitungsalgorithmen über eine große Vielfalt von visuellen Daten auszuführen. Die CPUs sind j edoch oft nicht in der Lage, die Performance-Anforderungen vieler Anwendungen des maschinellen Sehens zu erfüllen, wie z. B. in Bezug auf die Ausführungszeit und den Leistungsverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, die in fahrzeuginternen ADAS-Anwendungen und in praktischen autonomen Fahrzeugen der Levels 3-5 erforderlich sind.
  • Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungsclusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Stufen 3-5 zu ermöglichen. Ein CNN beispielsweise, das auf der DLA oder dGPU ausgeführt wird (z. B. die GPU 1020), kann 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. Der DLA kann ferner ein neuronales Netz enthalten, das in der Lage ist, Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis davon bereitzustellen und dieses semantische Verständnis an Pfadplanungsmodule weiterzugeben, die auf CPU-Komplex laufen.
  • Als weiteres Beispiel können mehrere neuronale Netze simultan ausgeführt werden, wie für das Fahren bei Level 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Vereisung hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Warnschild selbst kann durch ein erstes eingesetztes neuronales Netz (z. B. ein neuronales Netz, das trainiert wurde) als Verkehrsschild identifiziert werden und ein Text „Blinkende Lichter weisen auf Vereisung hin“ kann durch ein zweites eingesetztes neuronales Netz interpretiert werden, das eine Pfadplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass, wenn blinkende Lichter detektiert werden, Vereisung vorliegt. Das blinkende Licht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz über mehrere Frames hinweg betrieben wird und die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Nichtvorhandensein) von blinkenden Lichtern informiert. Alle drei neuronalen Netze können simultan laufen, wie etwa innerhalb des DLA und/oder auf den GPU(s) 1008.
  • In einigen Beispielen kann ein CNN zur Gesichtserkennung und Fahrzeugbesitzeridentifizierung Daten von Kamerasensoren verwenden, um das Vorhandensein eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 1000 zu identifizieren. Die stets eingeschaltete Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer 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 stellen das/die SoC(s) 1004 Sicherheit gegen Diebstahl und/oder Carjacking bereit.
  • In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Rettungsfahrzeugen Daten von Mikrofonen 1096 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) 1004 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. In einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, dafür trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu identifizieren (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch dazu trainiert werden, Rettungsfahrzeuge zu identifizieren, die für den lokalen Bereich, in dem das Fahrzeug betrieben wird, spezifisch sind, wie durch GNSS-Sensor(en) 1058 identifiziert. So wird das CNN beispielsweise beim Betrieb in Europa versuchen, europäische Sirenen zu erkennen, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, zur Seite der Straße zu fahren, das Fahrzeug abzustellen und/oder das Fahrzeug mit Hilfe der Ultraschallsensoren 1062 im Leerlauf laufen zu lassen, bis das Einsatzfahrzeug(e) vorbeifährt.
  • Das Fahrzeug kann CPU(s) 1018 (z. B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. PCIe) an die SoC(s) 1004 gekoppelt sein können. Die CPU(s) 1018 können zum Beispiel einen X86-Prozessor beinhalten. Die CPU(s) 1018 können dazu verwendet werden, eine beliebige einer Vielfalt von Funktionen durchzuführen, z. B. die Vermittlung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und SoC(s) 1004 und/oder die Überwachung des Status und Zustands der Steuerung(en) 1036 und/oder Infotainment-SoC 1030.
  • Das Fahrzeug 1000 kann GPU(s) 1020 (z. B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. NVLINK von NVIDIA) an die SoC(s) 1004 gekoppelt sein können. Die GPU(s) 1020 können eine zusätzliche Funktionalität für künstliche Intelligenz bereitstellen, wie etwa durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netze, und sie können zum Trainieren und/oder Aktualisieren neuronaler Netze auf Grundlage von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 1000 verwendet werden.
  • Das Fahrzeug 1000 kann ferner die Netzschnittstelle 1024 beinhalten, die drahtlose Antenne(n) 1026 beinhalten kann (z. B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie etwa eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzschnittstelle 1024 kann verwendet werden, um drahtlose Verbindungen über das Internet mit der Cloud (z. B. mit dem Server 1078 und/oder anderen Netzvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z. B. Client-Vorrichtungen von Passagieren) zu ermöglichen. Zum Kommunizieren mit anderen Fahrzeugen kann eine direkte Verknüpfung zwischen den zwei Fahrzeugen hergestellt werden und/oder eine indirekte Verknüpfung (z. B. über Netze und über das Internet) hergestellt werden. Direkte Verknüpfungen können unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung hergestellt werden. Eine Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung kann dem Fahrzeug 1000 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1000 bereitstellen (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 1000). Diese Funktionalität kann Teil einer kooperativen Funktionalität zur adaptiven Geschwindigkeitsregelung des Fahrzeugs 1000 sein.
  • Die Netzschnittstelle 1024 kann ein SoC beinhalten, das eine Modulations- und Demodulationsfunktionalität bereitstellt und es den Steuerungen 1036 ermöglicht, über drahtlose Netze zu kommunizieren. Die Netzschnittstelle 1024 kann ein Hochfrequenz-Frontend für die Aufwärtskonvertierung vom Basisband auf die Hochfrequenz und die Abwärtskonvertierung von der Hochfrequenz auf das Basisband beinhalten. Die Frequenzkonvertierungen können durch hinreichend bekannte Prozesse und/oder unter Verwendung von Überlagerungsverfahren durchgeführt werden. In einigen Beispielen kann die Hochfrequenz-Frontend-Funktionalität durch einen separaten Chip bereitgestellt sein. Die Netzschnittstelle kann drahtlose Funktionalität zum Kommunizieren über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
  • Das Fahrzeug 1000 kann ferner einen oder mehrere Datenspeicher 1028 beinhalten, die eine Speicherung außerhalb des Chips (z. B. außerhalb der SoC(s) 1004) beinhalten können. Der/die Datenspeicher 1028 können ein oder mehrere Speicherelemente beinhalten, darunter RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Vorrichtungen, die mindestens ein Datenbit speichern können.
  • Das Fahrzeug 1000 kann ferner GNSS-Sensor(en) 1058 (z. B. GPS- und/oder unterstützte GPS-Sensoren) beinhalten, um bei Funktionen zur Kartierung, Wahrnehmung, Erzeugung des Belegungsrasters und/oder Pfadplanung zu helfen. Es kann eine beliebige Anzahl von GNSS-Sensoren 1058 verwendet werden, einschließlich z. B. eines GPS-Geräts, das einen USB-Anschluss mit einer Ethernet-zu-Seriell-Brücke (RS-232) verwendet.
  • Das Fahrzeug 1000 kann ferner (einen) RADAR-Sensor(en) 1060 beinhalten. Der/die RADAR-Sensor(en) 1060 können vom Fahrzeug 1000 zur Fernerkennung von Fahrzeugen verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die RADAR-Funktionssicherheitslevel können ASIL B sein. Der/die RADAR-Sensor(en) 1060 können das CAN und/oder den Bus 1002 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 1060 erzeugten Daten) zur Steuerung von und zum Zugriff auf Obj ektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Eine große Vielfalt von RADAR-Sensortypen kann verwendet werden. Beispielsweise kann/können der/die RADAR-Sensor(en) 1060 uneingeschränkt als Front-, Heck- und Seiten-RADAR verwendet werden. In einigen Beispielen wird ein bzw. werden Impuls-Doppler-RADAR-Sensor(en) verwendet.
  • Der/die RADAR-Sensor(en) 1060 können unterschiedliche Konfigurationen beinhalten, z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, kurze Seitenabdeckung usw. In einigen Beispielen kann ein Langstrecken-RADAR für die adaptive Geschwindigkeitsregelung verwendet werden. Die Langstrecken-RADAR-Systeme können ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 1060 kann/können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und von ADAS-Systemen zur Notbremsunterstützung und Kollisionswarnung verwendet werden. Langstrecken-RADAR-Sensoren können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Balkenmuster erzeugen, das darauf ausgelegt ist, die Umgebung des Fahrzeugs 1000 bei höheren Geschwindigkeiten mit minimaler Störung durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. Die beiden anderen Antennen können das Sichtfeld erweitern, wodurch es möglich ist, Fahrzeuge, die in die Fahrspur des Fahrzeugs 1000 einfahren oder diese verlassen, schnell zu erkennen.
  • RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 1060 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1050 Grad (hinten) beinhalten. Kurzstrecken-RADAR-Systeme können ohne Einschränkung RADAR-Sensoren beinhalten, die für die Installation an beiden Enden des hinteren Stoßfängers ausgelegt sind. Wenn das RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug konstant überwachen.
  • Kurzstrecken-RADAR-Systeme können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Spurwechselassistenz verwendet werden.
  • Das Fahrzeug 1000 kann ferner Ultraschallsensor(en) 1062 beinhalten. Der/die Ultraschallsensor(en) 1062, die vorne, hinten und/oder an den Seiten des Fahrzeugs 1000 positioniert sein können, können als Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Eine große Vielfalt von Ultraschallsensor(en) 1062 kann verwendet werden und können unterschiedliche Ultraschallsensor(en) 1062 können für unterschiedliche Erkennungsreichweiten (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 1062 können bei funktionellen Sicherheitslevels von ASII, B arbeiten.
  • Das Fahrzeug 1000 kann einen oder mehrere LIDAR-Sensoren 1064 beinhalten. Der/die LIDAR-Sensor(en) 1064 können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1064 können dem funktionellen Sicherheitslevel ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 1000 mehrere LIDAR-Sensoren 1064 (z. B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (um z. B. Daten für einen Gigabit-Ethernet-Switch bereitzustellen).
  • In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 1064 eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld bereitstellen. Handelsübliche LIDAR-Sensor(en) 1064 können zum Beispiel eine beworbene Reichweite von ungefähr 100 m aufweisen, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 100 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 1064 verwendet werden. In solchen Beispielen können der/die LIDAR-Sensor(en) 1064 als eine kleine Vorrichtung implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1000 eingebettet werden kann. Der/die LIDAR-Sensor(en) 1064 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 niedrigem Reflexionsvermögen bereitstellen. An der Front montierte LIDAR-Sensor(en) 1064 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
  • In einigen Beispielen können auch LIDAR-Technologien, wie etwa 3D-Flash-LIDAR, verwendet werden. 3D-Flash-LIDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von ca. 200 m auszuleuchten. Eine Flash-LIDAR-Einheit beinhaltet einen Rezeptor, der die Laserpuls-Laufzeit und das reflektierte Licht an jedem Pixel aufzeichnet, was wiederum der Reichweite vom Fahrzeug zu den Objekten entspricht. Flash-LIDAR kann ermöglichen, dass mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1000. Verfügbare 3D-Flash-LIDAR-Systeme beinhalten eine Festkörper-3D-Staring-Array-LIDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z. B. eine nicht scannende LIDAR-Vorrichtung). Die Flash-LIDAR-Vorrichtung kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und kann das reflektierte Laserlicht in Form von den 3D-Reichweitenpunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, ist der/die LIDAR-Sensor(en) 1064 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.
  • Das Fahrzeug kann ferner IMU-Sensor(en) 1066 beinhalten. Der/die IMU-Sensor(en) 1066 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1000 befinden. Der/die IMU-Sensor(en) 1066 können zum Beispiel und ohne Einschränkung (einen) Beschleunigungsmesser, (ein) Magnetometer, (ein) Gyroskop(e), (einen) Magnetkompass(e) und/oder andere Sensorarten beinhalten. In einigen Beispielen, wie etwa in sechsachsigen Anwendungen, kann der/die IMU-Sensor(en) 1066 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 1066 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten können.
  • In einigen Ausführungsformen können die IMU-Sensor(en) 1066 als miniaturisiertes GPS-gestütztes Trägheitsnavigationssystem (GPS-Aided Inertial Navigation System - GPS/INS) mit hoher Rechenleistung implementiert sein, das Trägheitssensoren von mikroelektromechanischen Systemen (micro-electro-mechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und weiterentwickelte Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. Wie in solchen Beispielen können der/die IMU-Sensor(en) 1066 es dem Fahrzeug 1000 ermöglichen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem vom GPS an den/die IMU-Sensor(en) 1066 Änderungen der Geschwindigkeit direkt beobachtet und korreliert werden. In einigen Beispielen können die IMU-Sensor(en) 1066 und GNSS-Sensor(en) 1058 in einer einzelnen integrierten Einheit kombiniert sein.
  • Das Fahrzeug kann ein oder mehrere Mikrofon(e) 1096 beinhalten, die in und/oder am Fahrzeug 1000 angebracht sind. Das/die Mikrofon(e) 1096 können unter anderem zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, darunter Stereokamera(s) 1068, Weitsichtkamera(s) 1070, Infrarotkamera(s) 1072, Rundumkamera(s) 1074, Langstrecken- und/oder Mittelstreckenkamera(s) 1098 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten um die gesamte Peripherie des Fahrzeugs 1000 herum zu erfassen. Die Art der verwendeten Kameras hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 1000 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung rund um das Fahrzeug 1000 bereitzustellen. Zusätzlich kann die Anzahl der Kameras in Abhängigkeit von der Ausführungsform unterschiedlich sein. Zum Beispiel kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras beinhalten. Die Kameras können als ein Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kamera(s) wird hier mit Bezug auf 10A und 10B näher beschrieben.
  • Das Fahrzeug 1000 kann ferner (einen) Schwingungssensor(en) 1042 beinhalten. Der/die Vibrationssensor(en) 1042 können Vibrationen von Komponenten des Fahrzeugs, wie etwa der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung des Straßenbelags angeben. In einem weiteren Beispiel, wenn zwei oder mehr Vibrationssensoren 1042 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf des Straßenbelags zu bestimmen (z. B., wenn der Unterschied der Vibration zwischen einer leistungsbetriebenen Achse und einer sich frei drehenden Achse besteht).
  • Das Fahrzeug 1000 kann ein ADAS-System 1038 beinhalten. Das ADAS-System 1038 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 1038 kann autonome/adaptive/automatische Geschwindigkeitssteuerung (autonomous/adaptive/automatic cruise control - ACC), kooperative adaptive Geschwindigkeitssteuerung (cooperative adaptive cruise control - CACC), Vorwärtszusammenstoßwarnungen (forward crash warning - FCW), automatisches Notbremsen (AEB), Spurverlassenswarnungen (lane departure warning - LDW), Spurhalteassistenz (lane keep assist - LKA), Totwinkelwarnung (blind spot warning - BSW), Querverkehrswarnung (rear cross-traffic warning - RCTW), Kollisionswarn (collision warning - CWS)-Systeme, Spurzentrierung (lane centering - LC) und/oder andere Systeme, Merkmale und/oder Funktionen beinhalten.
  • Die ACC-Systeme können RADAR-Sensor(en) 1060, LIDAR-Sensor(en) 1064 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können eine ACC in Längsrichtung und/oder eine ACC in Querrichtung beinhalten. Die ACC in Längsrichtung überwacht und steuert den Abstand zum Fahrzeug unmittelbar vor dem Fahrzeug 1000 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu den vorausfahrenden Fahrzeugen einzuhalten. Die ACC in Querrichtung führt eine Abstandshaltung durch und rät dem Fahrzeug 1000, die Fahrspuren zu wechseln, wenn dies erforderlich ist. Das ACC in Querrichtung ist mit anderen ADAS-Anwendungen, wie etwa LC und CWS, verbunden.
  • Die CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzschnittstelle 1024 und/oder die drahtlose(n) Antenne(n) 1026 von anderen Fahrzeugen über eine drahtlose Verknüpfung oder indirekt über eine Netzverbindung (z. B. über das Internet) empfangen werden können. Direkte Verknüpfungen können durch eine Fahrzeug-zu-Fahrzeug(V2V)-Kommunikationsverknüpfung bereitgestellt werden, während indirekte Verknüpfungen Infrastruktur-zu-Fahrzeug(I2V)-Kommunikationsverknüpfungen sein können. Das Kommunikationskonzept V2V informiert in der Regel über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge unmittelbar vor und auf derselben Fahrbahn wie das Fahrzeug 1000), während das Kommunikationskonzept I2V Informationen über den weiteren vorausfahrenden Verkehr liefert. CACC-Systeme können entweder eines oder beides von I2V- und V2V-Informationsquellen beinhalten. Angesichts der Informationen über die Fahrzeuge vor dem Fahrzeug 1000 kann CACC zuverlässiger sein und es hat das Potenzial, die Gleichmäßigkeit des Verkehrsflusses zu verbessern und Staus auf der Straße zu reduzieren.
  • FCW-Systeme sind so ausgestaltet, dass sie den Fahrer vor einer Gefahr warnen, sodass der Fahrer Korrekturmaßnahmen ergreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 1060 gekoppelt an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-System erkennen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters eine korrigierende Handlung durchführt. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1060 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkannt, warnt es typischerweise zuerst den Fahrer, um eine korrigierende Handlung durchzuführen, um eine Kollision zu vermeiden, und, wenn der Fahrer keine korrigierende Handlung durchführt, kann das AEB-System automatisch die Bremsen in dem Bestreben betätigen, die Auswirkungen der vorhergesagten Kollision zu verhindern oder mindestens abzuschwächen. AEB-Systeme können Techniken, wie zum Beispiel dynamische Bremsunterstützung und/oder Bremsung aufgrund eines bevorstehenden Zusammenstoßes, beinhalten.
  • LDW-Systeme bieten optische, akustische und/oder taktile Warnungen, wie etwa Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 1000 Fahrspurmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er den Blinker betätigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme stellen eine Lenkeingabe oder eine Bremsung bereit, um das Fahrzeug 1000 zu korrigieren, wenn das Fahrzeug 1000 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme detektieren und warnen einen Fahrer vor Fahrzeugen in einem toten Winkel eines Automobils. BSW-Systeme können einen optischen, akustischen und/oder taktilen Alarm bereitstellen, um anzugeben, dass Einfädeln in oder Wechseln der Fahrspuren unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker verwendet. BSW-Systeme können rückseitig ausgerichtete Kameras und/oder RADAR-Sensoren 1060 verwenden, gekoppelt mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können visuelle, akustische und/oder taktile Benachrichtigungen liefern, wenn ein Objekt außerhalb des Bereichs der Rückfahrkamera erkannt wird, wenn das Fahrzeug 1000 rückwärtsfährt. Einige RCTW-Systeme beinhalten das AEB-System, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Zusammenstoß zu vermeiden. RCTW-Systeme können eine oder mehrere nach hinten gerichtete RADAR-Sensoren 1060 verwenden, gekoppelt mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • Herkömmliche ADAS-Systeme können anfällig für falsch positive Ergebnisse sein, die für den Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, da die ADAS-Systeme einen Fahrer warnen und es diesem Fahrer ermöglichen, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 1000 muss das Fahrzeug 1000 jedoch bei widersprüchlichen Ergebnissen selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 1036 oder einer zweiten Steuerung 1036) beachtet. In einigen Ausführungsformen kann das ADAS-System 1038 beispielsweise ein Backup- und/oder sekundärer Computer sein, der Wahrnehmungsinformationen für ein Rationalitätsmodul eines Backup-Computers bereitstellt. Die Rationalitätsüberwachung des Backup-Computers kann eine redundante, diverse Software auf Hardware-Komponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Ausgaben vom ADAS-System 1038 können einer Überwachungs-MCU bereitgestellt werden. Wenn die Ausgaben des primären und des sekundären Computers miteinander in Konflikt geraten, muss die Überwachungs-MCU bestimmen, wie der Konflikt beigelegt werden kann, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der primäre Computer so konfiguriert sein, dass er der Überwachungs-MCU eine Konfidenzbewertung bereitstellt, die eine Konfidenz des primären Computers für das gewählte Ergebnis angibt. Falls die Konfidenzbewertung einen Schwellenwert überschreitet, kann diese Überwachungs-MCU der Führung des primären Computers folgen, unabhängig davon, ob dieser sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. Wenn die Konfidenzbewertung den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse angeben (z. B. den Konflikt), kann die Überwachungs-MCU zwischen den Computern vermitteln, um das zweckmäßige Resultat zu bestimmen.
  • Die Überwachungs-MCU kann so konfiguriert sein, dass sie ein neuronales Netz/neuronale Netze ausführt, das/die so trainiert und konfiguriert ist/sind, dass es/sie basierend auf den Ausgaben des primären Computers und des sekundären Computers die Bedingungen bestimmt/bestimmen, unter denen der sekundäre Computer Fehlalarme bereitstellt. Folglich kann/können das neuronale Netz/die neuronalen Netze in der Überwachungs-MCU lernen, wann der Ausgabe des sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel können, wenn der sekundäre Computer ein RADARbasiertes FCW-System ist, neuronale Netz(e) in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie etwa ein Abflussgitter oder ein Gullydeckel, das/der einen Alarm auslöst. Wenn der sekundäre Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Überwachungs-MCU ähnlich lernen, die LDW zu überschreiben, wenn Fahrradfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die ein oder mehrere neuronale Netze beinhalten, die auf der Überwachungs-MCU laufen, kann die Überwachungs-MCU mindestens eine DLA oder GPU beinhalten, die für die Ausführung des oder der neuronalen Netze mit zugeordnetem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente des/der SoC(s) 1004 umfassen und/oder als solche beinhaltet sein.
  • In anderen Beispielen kann das ADAS-System 1038 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung der herkömmlichen Regeln des maschinellen Sehens durchführt. Somit kann der sekundäre Computer klassische Regeln des maschinellen Sehens (wenn-dann) verwenden und kann das Vorhandensein eines neuronalen Netzs/von neuronalen Netzen in der Überwachungs-MCU die Zuverlässigkeit, Sicherheit und Leistung verbessern. Zum Beispiel machen die diverse Implementation und absichtliche Nicht-Identität ein Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch die Funktionalität von Software (oder Software-Hardware-Schnittstellen) verursacht werden. Wenn zum Beispiel ein Software-Bug oder -Fehler in der auf dem primären Computer laufenden Software vorliegt und ein nicht identischer Software-Code, der auf dem sekundären Computer läuft, dasselbe Gesamtergebnis bereitstellt, dann kann die Kontroll-MCU eine größere Konfidenz darin haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware auf dem primären Computer keinen wesentlichen Fehler verursacht.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 1038 in einen Wahrnehmungsblock des primären Computers und/oder in einen Block für dynamische Fahraufgaben des primären Computers eingespeist werden. Wenn das ADAS-System 1038 z. B. eine Vorwärtszusammenstoßwarnung aufgrund eines unmittelbar vorausliegenden Objekts angibt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer ein eigenes neuronales Netz aufweisen, das trainiert wird und somit das Risiko von falsch positiven Ergebnissen reduziert, wie hierin beschrieben.
  • Das Fahrzeug 1000 kann ferner das Infotainment-SoC 1030 (z. B. ein fahrzeuginternes Infotainment-System (in-vehicle infotainment system - IVI-System)) beinhalten. Obwohl als ein SoC veranschaulicht und beschrieben, kann das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 1030 kann eine Kombination aus Hardware und Software beinhalten, die verwendet werden kann, um dem Fahrzeug 1000 Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzverbindungsfähigkeit (z. B. LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärtseinparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie etwa Kraftstofffüllstand, insgesamt zurückgelegte Strecke, Bremskraftstofffüllstand, Ölfüllstand, Tür öffnen/schließen, Luftfilterinformationen usw.) bereitzustellen. Das Infotainment-SoC 1030 kann zum Beispiel Radios, Plattenspieler, Navigationssysteme, Videowiedergabevorrichtungen, USB- und Bluetooth-Verbindungsfähigkeit, Carputer, In-Car-Entertainment, Wi-Fi, Audiosteuerelemente am Lenkrad, ein Freisprech-Sprachsteuerelement, eine Heads-up-Anzeige (heads-up display - HUD), eine HMI-Anzeige 1034, eine Telematikvorrichtung, ein Steuerfeld (z. B. zum Steuern von und/oder Interagieren mit verschiedenen Komponenten, Merkmalen und/oder Systemen) und/oder andere Komponenten beinhalten. Das Infotainment-SoC 1030 kann ferner dazu verwendet werden, um einem Benutzer(n) des Fahrzeugs Informationen (z. B. optisch und/oder akustisch) bereitzustellen, wie z. B. Informationen vom ADAS-System 1038, Informationen zum autonomen Fahren, wie z. B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Das Infotainment-SoC 1030 kann GPU-Funktionalität beinhalten. Der Infotainment-SoC 1030 kann über den Bus 1002 (z. B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 1000 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 1030 mit einer übergeordneten MCU gekoppelt werden, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre Steuerung 1036 (z. B. der primäre und/oder Backup-Computer des Fahrzeugs 1000) ausfällt. In einem solchen Beispiel kann der Infotainment-SoC 1030 das Fahrzeug 1000 in einen Chauffeur-zu-Safe-Stop-Modus versetzen, wie hier beschrieben.
  • Das Fahrzeug 1000 kann ferner ein Kombiinstrument 1032 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) beinhalten. Das Kombiinstrument 1032 kann eine Steuerung und/oder einen Supercomputer (z. B. eine diskreten Steuerung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 1032 kann einen Satz von Instrumenten wie etwa einen Geschwindigkeitsmesser, Kraftstofffüllstand, Öldruck, Tachometer, Wegstreckenzähler, Blinker, Schaltpositionsanzeige, Sicherheitsgurtwarnleuchte(n), Parkbremswarnleuchte(n), Motorfehlfunktionsleuchte(n), Airbag- (SRS-) Systeminformationen, Beleuchtungssteuerelemente, Sicherheitssystemsteuerelemente, Navigationsinformationen usw. beinhalten. In einigen Beispielen können Informationen angezeigt und/oder zwischen dem Infotainment-SoC 1030 und dem Kombiinstrument 1032 geteilt werden. Mit anderen Worten kann das Kombiinstrument 1032 als Teil des Infotainment-SoC 1030 beinhaltet sein oder umgekehrt.
  • 10D ist ein Systemdiagramm für die Kommunikation zwischen (einem) Cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 1000 aus 10A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 1076 kann den/die Server 1078, die Netz(e) 1090 und Fahrzeuge, einschließlich des Fahrzeugs 1000 beinhalten. Der/die Server 1078 kann/können eine Vielzahl von GPUs 1084(A)-1084(H) (hierin zusammenfassend als GPUs 1084 bezeichnet), PCIe-Switches 1082(A)-1082(H) (hierin zusammenfassend als PCIe-Switches 1082 bezeichnet) und/oder CPUs 1080(A)-1080(B) (hierin zusammenfassend als CPUs 1080 bezeichnet) beinhalten. Die GPUs 1084, CPUs 1080 und PCIe-Switches können mit Hochgeschwindigkeitszusammenschaltungen miteinander verbunden sein, wie etwa und ohne Einschränkung den von NVIDIA entwickelten NVLink-Schnittstellen 1088 und/oder PCIe-Verbindungen 1086. In einigen Beispielen sind die GPUs 1084 über ein NVLink- und/oder NVSwitch-SoC verbunden und die GPUs 1084 und die PCIe-Switches 1082 über PCIe-Zusammenschaltungen verbunden. Obwohl acht GPUs 1084, zwei CPUs 1080 und zwei PCIe-Switches veranschaulicht sind, soll dies nicht einschränkend sein. Je nach Ausführungsform kann jeder der Server 1078 eine beliebige Anzahl von GPUs 1084, CPUs 1080 und/oder PCIe-Switches beinhalten. Zum Beispiel können der/die Server 1078 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1084 beinhalten.
  • Der/die Server 1078 können über die Netz(e) 1090 und von Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenbedingungen zeigen, wie etwa kürzlich begonnene Straßenarbeiten. Der/die Server 1078 können über die Netz(e) 1090 und an die Fahrzeuge neuronale Netze 1092, aktualisierte neuronale Netze 1092 und/oder Karteninformationen 1094 übertragen, einschließlich Informationen über Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 1094 können Aktualisierungen für die HD-Karte 1022 beinhalten, wie etwa Informationen bezüglich Baustellen, Schlaglöchern, Umleitungen, Überschwemmungen und/oder anderer Hindernisse. In einigen Beispielen können die neuronalen Netze 1092, aktualisierten neuronalen Netze 1092 und/oder Karteninformationen 1094 aus einem neuen Training und/oder Erfahrungen resultieren, das/die in Daten dargestellt wird/werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das in einem Rechenzentrum (z. B. unter Verwendung von dem/den Server(n) 1078 und/oder anderen Servern) durchgeführt wurde.
  • Die Server 1078 können verwendet werden, um Maschinenlernmodelle (z. B. neuronale Netze) basierend auf Ausbildungsdaten auszubilden. Die Trainingsdaten können von Fahrzeugen erzeugt werden und/oder können in einer Simulation (z. B. unter Verwendung einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netz kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken erfolgen, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, teilüberwachtes Training, unüberwachtes Training, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Nach dem Trainieren der Maschinenlernmodelle können die Maschinenlernmodelle von den Fahrzeugen verwendet werden (z. B. über das Netz 1090 an die Fahrzeuge übertragen) und/oder können die Maschinenlernmodelle von den Servern 1078 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen kann der/können die Server 1078 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netze zum intelligenten Echtzeit-Inferenzieren anwenden. Der/die Server 1078 können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer beinhalten, die durch die GPU(s) 1084 angetrieben werden, wie etwa die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können der/die Server 1078 jedoch eine Deep-Learning-Infrastruktur beinhalten, die nur CPUangetriebene Rechenzentren verwendet.
  • Die Deep-Learning-Infrastruktur des/der Server(s) 1078 kann zum schnellen Echtzeit-Inferenzieren in der Lage sein und diese Fähigkeit verwenden, um den Zustand von Prozessoren, Software und/oder assoziierter Hardware in dem Fahrzeug 1000 zu bewerten und zu verifizieren. Zum Beispiel kann die Deep-Learning-Infrastruktur periodische Aktualisierungen von dem Fahrzeug 1000 empfangen, wie etwa eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1000 in dieser Sequenz von Bildern lokalisiert hat (z. B. über maschinelles Sehen und/oder andere Techniken des maschinellen Lernens zur Objektklassifizierung). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz ausführen, um Objekte zu identifizieren und sie mit Objekten zu vergleichen, die durch das Fahrzeug 1000 identifiziert wurden, und falls die Ergebnisse nicht übereinstimmen und die Deep-Learning-Infrastruktur zu dem Schluss kommt, dass die KI in dem Fahrzeug 1000 eine Fehlfunktion aufweist, dann kann der/können die Server 1078 ein Signal an das Fahrzeug 1000 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 1000 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Der/die Server 1078 können die GPU(s) 1084 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) beinhalten. Die Kombination von GPUangetriebenen Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, etwa wenn die Performance weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren angetriebene Server zum Inferenzieren verwendet werden.
  • Wie oben erwähnt, kann in mindestens einer Ausführungsform das SoC 150 (siehe 1 und 2) eine Komponente des Fahrzeugs 1000 sein. Zum Beispiel kann das SoC 150 eine Pipeline für maschinelles Sehen des Frontkamerasystems des Fahrzeugs 1000 implementieren. In solchen Ausführungsformen kann das SoC 150 als eines der SoCs 1004 (siehe 10C) implementiert sein. Unter Bezugnahme auf 10C kann die Systemsteuerung 104 durch die CPU(s) 1006, die GPU(s) 1008 und/oder den/die Prozessor(en) 1010 implementiert sein. Das Speicher-Teilsystem 140 kann durch den/die Cache(s) 1012 und/oder den/die Datenspeicher 1016 implementiert sein. Der Verarbeitungsblock/die Verarbeitungsblöcke 124 kann/können als Beschleuniger 1014 implementiert sein.
  • BEISPIELHAFTE RECHENVORRICHTUNG
  • 11 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 1100, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 1100 kann ein Verschaltungssystem 1102 beinhalten, das die folgenden Vorrichtungen direkt oder indirekt koppelt: Speicher 1104, eine oder mehrere Zentraleinheiten (CPUs) 1106, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1108, eine Kommunikationsschnittstelle 1110, E/A-Ports 1112, Eingabe-/Ausgabekomponenten 1114, eine Stromversorgung 1116, eine oder mehrere Präsentationskomponenten 1118 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 1120.
  • Obwohl die verschiedenen Blöcke aus 11 als über das Zusammenschaltungssystem 1102 mit Leitungen verbunden gezeigt werden, soll dies nicht als einschränkend gedacht sein und dient nur der Übersichtlichkeit. Zum Beispiel kann in einigen Ausführungsformen eine Präsentationskomponente 1118, wie etwa eine Anzeigevorrichtung, als E/A-Komponente 1114 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 1106 und/oder GPUs 1108 Speicher beinhalten (z. B. kann der Speicher 1104 neben dem Speicher der GPUs 1108, der CPUs 1106 und/oder anderer Komponenten repräsentativ für eine Speichervorrichtung sein). Mit anderen Worten ist die Rechenvorrichtung aus 11 lediglich veranschaulichend. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung“, „Spielekonsole“, „elektronische Steuereinheit (electronic control unit - ECU)“, „Virtual-Reality-System“, „Augmented-Reality-System“ und/oder anderen Vorrichtungs- oder Systemtypen unterschieden, da alle im Umfang der Rechenvorrichtung der 11 betrachtet werden.
  • Das Zusammenschaltungssystem 1102 kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Zusammenschaltungssystem 1102 kann einen oder mehrere Bus- oder Verbindungstypen beinhalten, wie etwa einen Bus mit Industriestandardarchitektur (ISA), einen Bus mit erweiterter Industriestandardarchitektur (EISA), einen Bus der Video Electronic Standards Association (VESA), einen Bus für Zusammenschaltung einer Periphärkomponente (PCI), ein Bus für Expressverschaltung einer Periphärkomponente (PCIe) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als ein Beispiel kann die CPU 1106 direkt mit dem Speicher 1104 verbunden sein. Ferner kann die CPU 1106 direkt mit der GPU 1108 verbunden sein. Bei direkter oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann das Zusammenschaltungssystem 1102 eine PCIe-Verbindung zur Durchführung der Verbindung beinhalten. In diesen Beispielen muss kein PCI-Bus in der Rechenvorrichtung 1100 beinhaltet sein.
  • Der Speicher 1104 kann eine Vielfalt von computerlesbaren Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf die die Rechenvorrichtung 1100 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie wechselbare und nicht wechselbare Medien beinhalten. Beispielhaft und nicht einschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Das Computerspeichermedium kann sowohl flüchtige als auch nichtflüchtige Medien und/oder wechselbare und nicht wechselbare Medien beinhalten, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder andere Datentypen implementiert sind. Zum Beispiel kann der Speicher 1104 computerlesbare Anweisungen speichern (die z. B. ein Programm oder Programme und/oder ein oder mehrere Programmelemente darstellen, wie etwa ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes beliebige andere Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das die Rechenvorrichtung 1100 zugreifen kann, sind aber nicht darauf beschränkt. Im hierin verwendeten Sinne umfassen Computerspeichermedien keine Signale an sich.
  • Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie etwa einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und beinhalten beliebige Informationsliefermedien. Der Begriff „moduliertes Datensignal“ kann ein Signal betreffen, das eine oder mehrere seiner Eigenschaften auf solch eine Weise verändert aufweist, dass Informationen in dem Signal kodiert werden. Zum Beispiel, und nicht als Einschränkung, können Computerspeichermedien verkabelte Medien beinhalten, wie beispielsweise ein verkabeltes Netz oder eine drahtgebundene Verbindung, und drahtlose Medien, wie beispielsweise akustische, RF, infrarote und andere drahtlose Medien. Kombinationen aller Vorstehenden sollen ebenfalls im Umfang computerlesbarer Medien eingeschlossen sein.
  • Die CPU(s) 1106 können konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1100 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Die CPU(s) 1106 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) 1106 können eine beliebige Art von Prozessor beinhalten und können unterschiedliche Arten von Prozessoren beinhalten, abhängig von der Art der Rechenvorrichtung 1100 (z. B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Je nach Rechenvorrichtung 1100 kann es sich beispielsweise um einen Advanced RISC Machine (ARM)-Prozessor mit reduziertem Instruction Set Computing (RISC) oder einen x86-Prozessor mit komplexem Instruction Set Computing (CISC) handeln. Die Rechenvorrichtung 1100 kann zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie z. B. mathematischen Coprozessoren, eine oder mehrere CPUs 1106 beinhalten.
  • Die GPUs 1108 können darüber hinaus oder alternativ von den CPUs 1106 so konfiguriert werden, dass sie mindestens einige computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechners 1100 ausführen, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 1108 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 1106) und/oder eine oder mehrere der GPU(s) 1108 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 1108 ein Coprozessor einer oder mehrerer der CPU(s) 1106 sein. Die GPUs 1108 können von der Rechenvorrichtung 1100 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder Durchführen allgemeiner Berechnungen verwendet werden. Zum Beispiel können die GPU(s) 1108 für Universalberechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 1108 können Hunderte oder Tausende von Kernen beinhalten, die Hunderte oder Tausende von Software-Threads gleichzeitig verarbeiten können. Die GPU(s) 1108 können Pixeldaten für Ausgabebilder als Reaktion auf das Rendern von Befehlen erzeugen (z. B. Rendern von Befehlen aus der/den CPU(s) 1106, die über eine Hostschnittstelle empfangen werden). Die GPU(s) 1108 können Grafikspeicher beinhalten, wie etwa Anzeigespeicher, um Pixeldaten oder andere geeignete Daten zu speichern, wie etwa GPGPU-Daten. Der Anzeigespeicher kann als Teil des Speichers 1104 beinhaltet sein. Die GPU(s) 1108 können zwei oder mehr GPUs beinhalten, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. unter Verwendung von NVLINK) oder kann die GPUs über ein Switch verbinden (z. B. unter Verwendung von NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 1108 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild) erzeugen. Jede GPU kann ihren eigenen Speicher beinhalten oder kann Speicher mit anderen GPUs gemeinsam nutzen.
  • Zusätzlich oder alternativ zu den CPU(s) 1106 und/oder den GPU(s) 1108 kann/können die Logikeinheit(en) 1120 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1100 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. In Ausführungsformen können die CPU(s) 1106, die GPU(s) 1108 und/oder die Logikeinheit(en) 1120 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 1120 kann/können Teil von und/oder integriert in eine oder mehrere der CPU(s) 1106 und/oder der GPU(s) 1108 sein und/oder eine oder mehrere der Logikeinheiten 1120 kann/können diskrete Komponenten oder anderweitig extern zu der/den CPU(s) 1106 und/oder der/den GPU(s) 1108 sein. In Ausführungsformen können eine oder mehrere der logischen Einheiten 1120 ein Coprozessor einer oder mehrerer der CPU(s) 1106 und/oder einer oder mehrerer der GPU(s) 1108 sein.
  • Beispiele der Logikeinheit(en) 1120 beinhalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie etwa Tensorkerne (Tensor Cores - TC), Tensor-Verarbeitungseinheiten (Tensor Processing Unit - TPU), visuelle Pixelkerne (Pixel Visual Cores - PVC), Bildverarbeitungseinheiten (Vision Processing Unit - VPU), Grafikverarbeitungscluster (Graphics Processing Cluster - GPC), Texturverarbeitungscluster (Texture Processing Cluster - TPC), Streaming-Multiprozessoren (SM), Baumdurchquerungseinheiten (Tree Traversal Unit - TTU), Beschleuniger für künstliche Intelligenz (Artificial Intelligence Accelerator - AIA), Deep-Learning-Beschleuniger (Deep Learning Accelerator - DLA), arithmetische Logikeinheiten (ALU), anwendungsspezifische integrierte Schaltungen (ASIC), Gleitkommaeinheiten (Floating Point Unit - FPU), Eingabe/Ausgabe(E/A)-Elemente, Elemente für Verschaltung von Periphärkomponenten (PCI) oder Expressverschaltung von Periphärkomponenten (peripheral component interconnect express - PCIe) und/oder dergleichen.
  • Die Kommunikationsschnittstelle 1110 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 1100 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1110 kann Komponenten und Funktionen beinhalten, die die Kommunikation über eine Reihe verschiedener Netze ermöglichen, z. B. drahtlose Netze (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), kabelgebundene Netze (z. B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Wide-Area-Netze (z. B. LoRaWAN, Sigfox usw.) und/oder das Internet.
  • Die E/A-Ports 1112 können die Rechenvorrichtung 1100 dazu befähigen, logisch an andere Vorrichtungen gekoppelt zu werden, einschließlich der E/A-Komponenten 1114, der Präsentationskomponente(n) 1118 und/oder anderer Komponenten, von denen einige in die Rechenvorrichtung 1100 eingebaut (z. B. darin integriert) sein können. Veranschaulichende E/A-Komponenten 1114 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die E/A-Komponenten 1114 können eine natürliche Benutzerschnittstelle (natural user interface - NUI) bereitstellen, die Luftgesten, Spracheingabe oder andere durch einen Benutzer erzeugte physiologische Eingaben verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Tasterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch in der Nähe des Bildschirms, Luftgesten, Kopf- und Augenverfolgung und Touch-Erkennung (wie unten näher beschrieben) implementieren, die mit einem Display der Rechenvorrichtung 1100 verbunden ist. Die Rechenvorrichtung 1100 kann Tiefenkameras beinhalten, wie stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung. Darüber hinaus kann die Rechenvorrichtung 1100 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) beinhalten, die eine Bewegungserkennung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Rechenvorrichtung 1100 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
  • Das Netzteil 1116 kann ein fest verdrahtetes Netzteil, ein Batterienetzteil oder eine Kombination davon beinhalten. Das Netzteil 1116 kann die Rechenvorrichtung 1100 mit Strom versorgen, damit die Komponenten der Rechenvorrichtung 1100 funktionieren können.
  • Die Darstellungskomponenten 1118 können ein Display (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-Up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Darstellungskomponenten beinhalten. Die Darstellungskomponente(n) 1118 kann bzw. können Daten von anderen Komponenten (z. B. der bzw. den GPU(s) 1108, der bzw. den CPU(s) 1106 usw.) empfangen und die Daten (z. B. als Bild, Video, Ton usw.) ausgeben.
  • In mindestens einer Ausführungsform kann das Simulationssystem 114 (siehe 1) auf einer der Rechenvorrichtung(en) 1100 implementiert sein. Wie bereits erwähnt, kann das Simulationssystem 114 durch prozessorausführbare Anweisungen implementiert sein. In solchen Ausführungsformen können die Anweisungen im Speicher 1104 gespeichert und von den CPUs 1106, den GPUs 1108 und/oder der/den Logikeinheit(en) 1120 ausgeführt werden.
  • Mindestens eine Ausführungsform der Offenbarung kann im Hinblick auf die folgenden Klauseln beschrieben werden:
    • 1. System umfassend: eine erste Schaltung, die eine Vielzahl von Teilblöcken umfasst, um Ausgabedaten zu erzeugen, wenn die Vielzahl von Teilblöcken eine diagnostische Operation durchführt, die vorherbestimmten Fehlererkennungsdaten zugeordnet ist; und eine zweite Schaltung, die eine Vielzahl von Fehlererkennungsblöcken umfasst, um einen oder mehrere Fehlererkennungswerte für die Ausgabedaten zu erzeugen und den einen oder die mehreren Fehlererkennungswerte mit den vorherbestimmten Fehlererkennungsdaten zu vergleichen.
    • 2. System nach Klausel 1, wobei zwei oder mehr Teilblöcke der Vielzahl von Teilblöcken in einer Reihe angeordnet sind, um gemeinsam eine funktionale Operation durchzuführen, wobei jeder der zwei oder mehr Teilblöcke mindestens einen Abschnitt der funktionalen Operation durchführt, und wobei die zwei oder mehr Teilblöcke die diagnostische Operation und die funktionale Operation zu unterschiedlichen Zeiten durchführen.
    • 3. System nach Klausel 2, wobei die vorherbestimmten Fehlererkennungsdaten eine Vielzahl von Werten umfassen, die Ausgabedaten eine Vielzahl von Abschnitten umfassen, wobei mindestens zwei Abschnitte der Ausgabedaten von verschiedenen Teilblöcken der Vielzahl von Teilblöcken ausgegeben werden, und die Vielzahl von Fehlererkennungsblöcken mindestens einen Fehlererkennungswert des einen oder der mehreren Fehlererkennungswerte für mindestens einen Abschnitt der Vielzahl von Abschnitten erzeugt und den mindestens einen der Fehlererkennungswerte mit einem anderen der Vielzahl von Werten vergleicht.
    • 4. System nach einer der Klauseln 1-3 zur Verwendung mit einer Systemsteuerung, wobei das System ferner Folgendes umfasst: mindestens einen Prozessor, um mindestens einen Fehlererkennungswert mit den vorherbestimmten Fehlererkennungsdaten zu vergleichen, um mindestens ein Vergleichsergebnis zu produzieren, wobei der mindestens eine Prozessor bestimmt, ob das mindestens eine Vergleichsergebnis anzeigt, dass ein Fehler aufgetreten ist, und die Systemsteuerung informiert, wenn der mindestens eine Prozessor bestimmt, dass ein Fehler aufgetreten ist.
    • 5. System nach Klausel 4 zur Verwendung mit einem externen Speichersystem, das vorherbestimmte Eingabedaten speichert, wobei das System ferner Folgendes umfasst: einen lokalen Speicher; und eine dritte Schaltung, die einen Speicherzugriffsblock umfasst, wobei der mindestens eine Prozessor den Speicherzugriffsblock anweist, die vorherbestimmten Eingabedaten von dem externen Speichersystem zu erhalten und die vorherbestimmten Eingabedaten in dem lokalen Speicher zu speichern, wobei mindestens einer der Vielzahl von Teilblöcken die vorherbestimmten Eingabedaten von dem lokalen Speicher erhält, wobei die Vielzahl von Teilblöcken die Ausgabedaten durch Verarbeiten der vorherbestimmten Eingabedaten erzeugt und der Speicherzugriffsblock die Ausgabedaten in dem externen Speichersystem speichert.
    • 6. System nach Klausel 5, ferner umfassend: eine vierte Schaltung, umfassend mindestens einen ersten Fehlererkennungsblock zum Erzeugen mindestens eines ersten Fehlererkennungswertes für die vorherbestimmten Eingabedaten, die von dem externen Speichersystem erhalten wurden, und zum Vergleichen des mindestens einen ersten Fehlererkennungswertes mit einem ersten Abschnitt der vorherbestimmten Fehlererkennungsdaten; und eine fünfte Schaltung, umfassend mindestens einen zweiten Fehlererkennungsblock zum Erzeugen mindestens eines zweiten Fehlererkennungswertes für die Ausgabedaten, bevor die Ausgabedaten in dem externen Speichersystem gespeichert werden, und zum Vergleichen des mindestens einen zweiten Fehlererkennungswertes mit einem zweiten Abschnitt der vorherbestimmten Fehlererkennungsdaten.
    • 7. System nach einer der Klauseln 1-6, wobei mindestens einer der Vielzahl von Fehlererkennungsblöcken mindestens einen des einen oder der mehreren Fehlererkennungswerte erzeugt, indem er eine zyklische Redundanzprüfung an der Ausgabe durchführt, die von einem anderen der Vielzahl von Teilblöcken erzeugt wird.
    • 8. System nach einer der Klauseln 1-7, wobei die vorherbestimmten Fehlererkennungsdaten durch eine Offline-Simulation erzeugt werden und mindestens einer der Vielzahl von Fehlererkennungsblöcken Folgendes umfasst: einen ersten Speicherstandort, um mindestens einen Abschnitt der vorherbestimmten Fehlererkennungsdaten zu speichern; einen zweiten Speicherstandort, um einen konkreten des einen oder der mehreren Fehlererkennungswerte zu speichern, die von dem Fehlererkennungsblock erzeugt werden; und eine Vergleichsschaltung, um die Werte zu vergleichen, die von dem ersten und zweiten Speicherstandort gespeichert wurden, um dadurch den konkreten Fehlererkennungswert mit dem Abschnitt der vorherbestimmten Fehlererkennungsdaten zu vergleichen.
    • 9. System nach Klausel 8, wobei jeder der Vielzahl von Fehlererkennungsblöcken Folgendes umfasst: einen dritten Speicherstandort, um eine Anweisung zu speichern, wobei die Anweisung die Vergleichsschaltung des Fehlererkennungsblocks anweist, die von dem ersten und zweiten Speicherstandort des Fehlererkennungsblocks gespeicherten Werte zu vergleichen.
    • 10. System nach einer der Klauseln 1-9, wobei die diagnostische Operation eine Permanent Fault Software Diagnostic („PFSD“)-Aufgabe umfasst.
    • 11. System nach einer der Klauseln 1-10, ferner umfassend: ein autonomes Fahrzeug, das die erste und zweite Schaltung umfasst.
    • 12. System nach Klausel 11, wobei das autonome Fahrzeug eine Pipeline für maschinelles Sehen umfasst, die die erste und zweite Schaltung umfasst.
    • 13. Verfahren, umfassend: Durchführen einer diagnostischen Operation mit einem ersten Abschnitt einer Schaltung, um eine diagnostische Ausgabe zu produzieren, wobei der erste Abschnitt einen oder mehrere erste Zwischenwerte erzeugt, bevor die diagnostische Ausgabe produziert wird; Erzeugen eines oder mehrerer erster Fehlererkennungswerte für den einen oder die mehreren ersten Zwischenwerte mit dem ersten Abschnitt; und Bestimmen, unter Verwendung des ersten Abschnitts, dass ein Fehler aufgetreten ist, wenn der eine oder die mehreren ersten Fehlererkennungswerte nicht mit vorherbestimmten Fehlererkennungsdaten übereinstimmen.
    • 14. Verfahren nach Klausel 13, ferner umfassend: Senden, mit dem ersten Abschnitt, einer Benachrichtigung an einen zweiten Abschnitt der Schaltung, wenn bestimmt wird, dass ein Fehler aufgetreten ist.
    • 15. Verfahren nach Klausel 13 oder 14, wobei der erste Abschnitt einen oder mehrere Fehlererkennungsblöcke umfasst, um den einen oder die mehreren ersten Fehlererkennungswerte zu erzeugen, und das Verfahren ferner Folgendes umfasst: Deaktivieren des einen oder der mehreren Fehlererkennungsblöcke, nachdem der eine oder die mehreren Fehlererkennungsblöcke den einen oder die mehreren ersten Fehlererkennungswerte erzeugt haben.
    • 16. Verfahren nach einer der Klauseln 13-15, ferner umfassend: Durchführen einer funktionalen Operation mit dem ersten Abschnitt der Schaltung, um eine funktionale Ausgabe zu produzieren, wobei der erste Abschnitt einen oder mehrere zweite Zwischenwerte erzeugt, wobei der erste Abschnitt einen oder mehrere Fehlererkennungsblöcke umfasst, um den einen oder die mehreren ersten Fehlererkennungswerte zu erzeugen; und Deaktivieren des einen oder der mehreren Fehlererkennungsblöcke, sodass ein oder mehrere zweite Fehlererkennungswerte nicht für den einen oder die mehreren zweiten Zwischenwerte erzeugt werden.
    • 17. Verfahren nach Klausel 16, ferner umfassend: Aktivieren des einen oder der mehreren Fehlererkennungsblöcke, bevor der eine oder die mehreren Fehlererkennungsblöcke den einen oder die mehreren ersten Fehlererkennungswerte erzeugen.
    • 18. Verfahren nach einer der Klauseln 13-17, das ferner Folgendes für mindestens einen des einen oder der mehreren ersten Zwischenwerte umfasst: Erzeugen eines Fehlererkennungscodes als einen des einen oder der mehreren ersten Fehlererkennungswerte und Speichern des Fehlererkennungscodes in einem ersten Speicherstandort als einen ersten Wert; Speichern eines Abschnitts der vorherbestimmten Fehlererkennungsdaten in einem zweiten Speicherstandort als einen zweiten Wert; Erhalten eines Vergleichsergebnisses durch Vergleichen des ersten Wertes mit dem zweiten Wert; und Speichern des Vergleichsergebnisses in einem dritten Speicherstandort, auf den von mindestens einem Prozessor des ersten Abschnitts der Schaltung zugegriffen werden kann, wobei der mindestens eine Prozessor mindestens teilweise basierend auf dem Vergleichsergebnis bestimmt, ob ein Fehler aufgetreten ist.
    • 19. Verfahren nach einer der Klauseln 13-18, ferner umfassend: Erzeugen der vorherbestimmten Fehlererkennungsdaten durch Simulieren der Durchführung der diagnostischen Operation durch den ersten Abschnitt.
    • 20. System, umfassend: eine Vielzahl von Schaltungen zum Durchführen einer Operation, wobei eine oder mehrere der Vielzahl von Schaltungen eine Vielzahl von Teilschaltungen umfassen, um eine Ausgabe zu erzeugen und zu erkennen, ob während der Durchführung der Operation ein Fehler aufgetreten ist, indem ein Fehlererkennungswert für die Ausgabe erzeugt wird und bestimmt wird, ob der Fehlererkennungswert mit einem vorherbestimmten Fehlererkennungswert übereinstimmt.
    • 21. System nach Klausel 20, ferner umfassend eine Systemsteuerung, wobei mindestens eine der einen oder mehreren Schaltungen mindestens einen Prozessor umfasst, um eine Anweisung von der Systemsteuerung zu empfangen, um einen Abschnitt der Operation durchzuführen, wobei der mindestens eine Prozessor der mindestens einen Schaltung mindestens eine der Vielzahl von Teilschaltungen der mindestens einen Schaltung anweist, mindestens eine Teiloperation durchzuführen, nachdem der mindestens eine Prozessor die Anweisung empfängt, die Ausgabe der Teilschaltung zu erzeugen, der mindestens eine Prozessor der mindestens einen Schaltung eine Fehlerquelle einer der Vielzahl von Teilschaltungen der mindestens einen Schaltung als Quelle eines Fehlers identifiziert, wenn der mindestens eine Prozessor Informationen erhält, die anzeigen, dass der Fehler aufgetreten ist, und der mindestens eine Prozessor der mindestens einen Schaltung die Fehlerquelle der Systemsteuerung mitteilt.
    • 22. System nach Klausel 20 oder 21, ferner umfassend: eine Systemsteuerung, um die Vielzahl von Schaltungen anzuweisen, als Operation eine diagnostische Operation oder eine funktionale Operation durchzuführen, wobei mindestens eine der einen oder mehreren Schaltungen eine Fehlermeldung an die Systemsteuerung sendet, wenn mindestens eine der Vielzahl von Teilschaltungen der mindestens einen Schaltung einen Fehler erkennt.
    • 23. System nach einer der Klauseln 20-22, ferner umfassend: eine Vielzahl von Hardware-Beschleunigern, die die Vielzahl von Schaltungen umfassen.
    • 24. System nach einer der Klauseln 20-23, wobei die Vielzahl von Schaltungen eine Verarbeitungspipeline implementieren.
    • 25. System nach Klausel 24, wobei die Verarbeitungspipeline eine Pipeline für maschinelles Sehen ist.
    • 26. System nach einer der Klauseln 20-25, ferner umfassend: ein autonomes Fahrzeug, das die Vielzahl von Schaltungen umfasst.
    • 27. System nach Klausel 26, wobei die Vielzahl von Schaltungen mindestens eine der Folgenden umfasst: eine Videoeingabe („VI“)-Schaltung, eine Bildsensor-Prozessor („ISP“)-Schaltung, eine Videobildkompositor („VIC“)-Schaltung, eine optische Flussbeschleuniger („OFA“)-Schaltung, eine programmierbare Sichtbeschleuniger („PVA“)-Schaltung oder eine Deep-Learning-Beschleuniger („DLA“)-Schaltung.
    • 28. System nach einer der Klauseln 20-27, ferner umfassend: eine elektrische Vorrichtung, die die Vielzahl von Schaltungen umfasst.
    • 29. System nach einer der Klauseln 20-28, wobei die Operation eine diagnostische Operation ist und die Vielzahl von Schaltungen eine funktionale Operation durchführt, ohne dass die Vielzahl von Teilschaltungen von mindestens einer der einen oder mehreren Schaltungen erkennt, ob ein Fehler während der Durchführung der funktionalen Operation aufgetreten ist.
    • 30. System nach Klausel 29, ferner umfassend: ein autonomes Fahrzeug, das die Vielzahl von Schaltungen umfasst; und eine Systemsteuerung, die die Vielzahl von Schaltungen abwechselnd anweist, eine neue diagnostische Operation und eine neue funktionale Operation durchzuführen.
    • 31. System nach Klausel 29 oder 30, wobei die funktionale Operation eine Operation des fortgeschrittenen Fahrerassistenzsystems („ADAS“) ist.
    • 32. System nach einer der Klauseln 20-31, das ein System auf einem Chip ist, das auf einem einzelnen Silicium-Substrat implementiert ist.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode- oder maschinenverwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie Programmmodulen, die von einem Computer oder einem anderen Computer, wie einem Personal Data Assistent oder einer anderen Handheld-Vorrichtung, ausgeführt werden, beschrieben werden. Im Allgemeinen beziehen sich Programmmodule einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. auf Codes, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Offenbarung kann in einer Vielfalt von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Universal computern, spezielleren Rechenvorrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetz verbunden sind, durchgeführt werden.
  • Im hier verwendeten Sinne ist der Gebrach von „und/oder“ in Bezug auf zwei oder mehr Elemente als nur ein Element oder eine Kombination von Elementen auszulegen. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder Elemente A, B und C enthalten. Außerdem kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B umfassen. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B beinhalten.
  • Der Gegenstand der vorliegenden Offenbarung wird hierin genau beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Schutzumfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um andere Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzuschließen. Auch wenn die Begriffe „Schritt“ und/oder „Block“ in diesem Dokument verwendet werden können, um verschiedene Elemente der verwendeten Methoden zu bezeichnen, sollten die Begriffe nicht als eine bestimmte Reihenfolge unter den oder zwischen den verschiedenen hierin genannten Schritten voraussetzend interpretiert werden, 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 [0137]

Claims (32)

  1. System, umfassend: eine erste Schaltung, die eine Vielzahl von Teilblöcken umfasst, um Ausgabedaten zu erzeugen, wenn die Vielzahl von Teilblöcken eine diagnostische Operation durchführt, die vorherbestimmten Fehlererkennungsdaten zugeordnet ist; und eine zweite Schaltung, die eine Vielzahl von Fehlererkennungsblöcken umfasst, um einen oder mehrere Fehlererkennungswerte für die Ausgabedaten zu erzeugen und den einen oder die mehreren Fehlererkennungswerte mit den vorherbestimmten Fehlererkennungsdaten zu vergleichen.
  2. System nach Anspruch 1, wobei zwei oder mehr Teilblöcke der Vielzahl von Teilblöcken in einer Reihe angeordnet sind, um gemeinsam eine funktionale Operation durchzuführen, wobei jeder der zwei oder mehr Teilblöcke mindestens einen Abschnitt der funktionalen Operation durchführt, und wobei die zwei oder mehr Teilblöcke die diagnostische Operation und die funktionale Operation zu unterschiedlichen Zeiten durchführen.
  3. System nach Anspruch 2, wobei die vorherbestimmten Fehlererkennungsdaten eine Vielzahl von Werten umfassen, die Ausgabedaten eine Vielzahl von Abschnitten umfassen, wobei mindestens zwei Abschnitte der Ausgabedaten von verschiedenen Teilblöcken der Vielzahl von Teilblöcken ausgegeben werden, und die Vielzahl von Fehlererkennungsblöcken mindestens einen Fehlererkennungswert des einen oder der mehreren Fehlererkennungswerte für mindestens einen Abschnitt der Vielzahl von Abschnitten erzeugt und den mindestens einen der Fehlererkennungswerte mit einem anderen der Vielzahl von Werten vergleicht.
  4. System nach einem der vorhergehenden Ansprüche zur Verwendung mit einer Systemsteuerung, wobei das System ferner Folgendes umfasst: mindestens einen Prozessor, um mindestens einen Fehlererkennungswert mit den vorherbestimmten Fehlererkennungsdaten zu vergleichen, um mindestens ein Vergleichsergebnis zu produzieren, wobei der mindestens eine Prozessor bestimmt, ob das mindestens eine Vergleichsergebnis anzeigt, dass ein Fehler aufgetreten ist, und die Systemsteuerung informiert, wenn der mindestens eine Prozessor bestimmt, dass ein Fehler aufgetreten ist.
  5. System nach Anspruch 4 zur Verwendung mit einem externen Speichersystem, das vorherbestimmte Eingabedaten speichert, wobei das System ferner Folgendes umfasst: einen lokalen Speicher; und eine dritte Schaltung, die einen Speicherzugriffsblock umfasst, wobei der mindestens eine Prozessor den Speicherzugriffsblock anweist, die vorherbestimmten Eingabedaten von dem externen Speichersystem zu erhalten und die vorherbestimmten Eingabedaten in dem lokalen Speicher zu speichern, wobei mindestens einer der Vielzahl von Teilblöcken die vorherbestimmten Eingabedaten von dem lokalen Speicher erhält, wobei die Vielzahl von Teilblöcken die Ausgabedaten durch Verarbeiten der vorherbestimmten Eingabedaten erzeugt und der Speicherzugriffsblock die Ausgabedaten in dem externen Speichersystem speichert.
  6. System nach Anspruch 5, ferner umfassend: eine vierte Schaltung, die mindestens einen ersten Fehlererkennungsblock umfasst, um mindestens einen ersten Fehlererkennungswert für die vorherbestimmten Eingabedaten zu erzeugen, die von dem externen Speichersystem erhalten wurden, und um den mindestens einen ersten Fehlererkennungswert mit einem ersten Abschnitt der vorherbestimmten Fehlererkennungsdaten zu vergleichen; und eine fünfte Schaltung, die mindestens einen zweiten Fehlererkennungsblock umfasst, um mindestens einen zweiten Fehlererkennungswert für die Ausgabedaten zu erzeugen, bevor die Ausgabedaten in dem externen Speichersystem gespeichert werden, und um den mindestens einen zweiten Fehlererkennungswert mit einem zweiten Abschnitt der vorherbestimmten Fehlererkennungsdaten zu vergleichen.
  7. System nach einem der vorhergehenden Ansprüche, wobei mindestens einer der Vielzahl von Fehlererkennungsblöcken mindestens einen des einen oder der mehreren Fehlererkennungswerte erzeugt, indem er eine zyklische Redundanzprüfung an der Ausgabe durchführt, die von einem anderen der Vielzahl von Teilblöcken erzeugt wird.
  8. System nach einem der vorhergehenden Ansprüche, wobei die vorherbestimmten Fehlererkennungsdaten durch Offline-Simulation erzeugt werden und mindestens einer der Vielzahl von Fehlererkennungsblöcken Folgendes umfasst: einen ersten Speicherstandort, um mindestens einen Abschnitt der vorherbestimmten Fehlererkennungsdaten zu speichern; einen zweiten Speicherstandort, um einen konkreten des einen oder der mehreren Fehlererkennungswerte zu speichern, die von dem Fehlererkennungsblock erzeugt werden; und eine Vergleichsschaltung, um die Werte zu vergleichen, die von dem ersten und zweiten Speicherstandort gespeichert wurden, um dadurch den konkreten Fehlererkennungswert mit dem Abschnitt der vorherbestimmten Fehlererkennungsdaten zu vergleichen.
  9. System nach Anspruch 8, wobei jeder der Vielzahl von Fehlererkennungsblöcken Folgendes umfasst: einen dritten Speicherstandort, um eine Anweisung zu speichern, wobei die Anweisung die Vergleichsschaltung des Fehlererkennungsblocks anweist, die von dem ersten und zweiten Speicherstandort des Fehlererkennungsblocks gespeicherten Werte zu vergleichen.
  10. System nach einem der vorhergehenden Ansprüche, wobei die diagnostische Operation eine Permanent Fault Software Diagnostic („PFSD“) Aufgabe umfasst.
  11. System nach einem der vorhergehenden Ansprüche, ferner umfassend: ein autonomes Fahrzeug, das die erste und zweite Schaltung umfasst.
  12. System nach Anspruch 11, wobei das autonome Fahrzeug eine Pipeline für maschinelles Sehen umfasst, die die erste und zweite Schaltung umfasst.
  13. Verfahren, umfassend: Durchführen einer diagnostischen Operation mit einem ersten Abschnitt einer Schaltung, um eine diagnostische Ausgabe zu produzieren, wobei der erste Abschnitt einen oder mehrere erste Zwischenwerte erzeugt, bevor die diagnostische Ausgabe produziert wird; Erzeugen eines oder mehrerer erster Fehlererkennungswerte für den einen oder die mehreren ersten Zwischenwerte mit dem ersten Abschnitt; und Bestimmen, unter Verwendung des ersten Abschnitts, dass ein Fehler aufgetreten ist, wenn der eine oder die mehreren ersten Fehlererkennungswerte nicht mit vorherbestimmten Fehlererkennungsdaten übereinstimmen.
  14. Verfahren nach Anspruch 13, ferner umfassend: Senden, mit dem ersten Abschnitt, einer Benachrichtigung an einen zweiten Abschnitt der Schaltung, wenn bestimmt wird, dass ein Fehler aufgetreten ist.
  15. Verfahren nach Anspruch 13 oder 14, wobei der erste Abschnitt einen oder mehrere Fehlererkennungsblöcke umfasst, um den einen oder die mehreren ersten Fehlererkennungswerte zu erzeugen, und das Verfahren ferner Folgendes umfasst: Deaktivieren des einen oder der mehreren Fehlererkennungsblöcke, nachdem der eine oder die mehreren Fehlererkennungsblöcke den einen oder die mehreren ersten Fehlererkennungswerte erzeugt haben.
  16. Verfahren nach einem der Ansprüche 13 bis 15, ferner umfassend: Durchführen einer funktionalen Operation mit dem ersten Abschnitt der Schaltung, um eine funktionale Ausgabe zu produzieren, wobei der erste Abschnitt einen oder mehrere zweite Zwischenwerte erzeugt, wobei der erste Abschnitt einen oder mehrere Fehlererkennungsblöcke umfasst, um den einen oder die mehreren ersten Fehlererkennungswerte zu erzeugen; und Deaktivieren des einen oder der mehreren Fehlererkennungsblöcke, sodass ein oder mehrere zweite Fehlererkennungswerte nicht für den einen oder die mehreren zweiten Zwischenwerte erzeugt werden.
  17. Verfahren nach Anspruch 16, ferner umfassend: Aktivierung des einen oder der mehreren Fehlererkennungsblöcke, bevor der eine oder die mehreren Fehlererkennungsblöcke den einen oder die mehreren ersten Fehlererkennungswerte erzeugen.
  18. Verfahren nach einem der Ansprüche 13 bis 17, das ferner Folgendes für mindestens einen des einen oder der mehreren ersten Zwischenwerte umfasst: Erzeugen eines Fehlererkennungscodes als einen des einen oder der mehreren ersten Fehlererkennungswerte und Speichern des Fehlererkennungscodes in einem ersten Speicherstandort als einen ersten Wert; Speichern eines Abschnitts der vorherbestimmten Fehlererkennungsdaten in einem zweiten Speicherstandort als einen zweiten Wert; Erhalten eines Vergleichsergebnisses durch Vergleichen des ersten Wertes mit dem zweiten Wert; und Speichern des Vergleichsergebnisses in einem dritten Speicherstandort, auf den von mindestens einem Prozessor des ersten Abschnitts der Schaltung zugegriffen werden kann, wobei der mindestens eine Prozessor mindestens teilweise basierend auf dem Vergleichsergebnis bestimmt, ob ein Fehler aufgetreten ist.
  19. Verfahren nach einem der Ansprüche 13 bis 18, ferner umfassend: Erzeugen der vorherbestimmten Fehlererkennungsdaten durch Simulieren der Durchführung der diagnostischen Operation durch den ersten Abschnitt.
  20. System, umfassend: eine Vielzahl von Schaltungen zum Durchführen einer Operation, wobei eine oder mehrere der Vielzahl von Schaltungen eine Vielzahl von Teilschaltungen umfassen, um eine Ausgabe zu erzeugen und zu erkennen, ob während der Durchführung der Operation ein Fehler aufgetreten ist, indem ein Fehlererkennungswert für die Ausgabe erzeugt wird und bestimmt wird, ob der Fehlererkennungswert mit einem vorherbestimmten Fehlererkennungswert übereinstimmt.
  21. System nach Anspruch 20, ferner umfassend eine Systemsteuerung, wobei mindestens eine der einen oder mehreren Schaltungen mindestens einen Prozessor umfasst, um eine Anweisung von der Systemsteuerung zu empfangen, um einen Abschnitt der Operation durchzuführen, wobei der mindestens eine Prozessor der mindestens einen Schaltung mindestens eine der Vielzahl von Teilschaltungen der mindestens einen Schaltung anweist, mindestens eine Teiloperation durchzuführen, nachdem der mindestens eine Prozessor die Anweisung empfängt, die Ausgabe der Teilschaltung zu erzeugen, der mindestens eine Prozessor der mindestens einen Schaltung eine Fehlerquelle einer der Vielzahl von Teilschaltungen der mindestens einen Schaltung als Quelle eines Fehlers identifiziert, wenn der mindestens eine Prozessor Informationen erhält, die anzeigen, dass der Fehler aufgetreten ist, und der mindestens eine Prozessor der mindestens einen Schaltung die Fehlerquelle der Systemsteuerung mitteilt.
  22. System nach Anspruch 20 oder 21, ferner umfassend: eine Systemsteuerung, um die Vielzahl von Schaltungen anzuweisen, als Operation eine diagnostische Operation oder eine funktionale Operation durchzuführen, wobei mindestens eine der einen oder mehreren Schaltungen eine Fehlermeldung an die Systemsteuerung sendet, wenn mindestens eine der Vielzahl von Teilschaltungen der mindestens einen Schaltung einen Fehler erkennt.
  23. System nach einem der Ansprüche 20 bis 22, ferner umfassend: eine Vielzahl von Hardware-Beschleunigern, die die Vielzahl von Schaltungen umfassen.
  24. System nach einem der Ansprüche 20 bis 23, wobei die Vielzahl von Schaltungen eine Verarbeitungspipeline implementieren.
  25. System nach Anspruch 24, wobei die Verarbeitungspipeline eine Pipeline für maschinelles Sehen ist.
  26. System nach einem der Ansprüche 20 bis 25, ferner umfassend: ein autonomes Fahrzeug, das die Vielzahl der Schaltungen umfasst.
  27. System nach Anspruch 26, wobei die Vielzahl von Schaltungen mindestens eine der Folgenden umfasst: eine Videoeingabe („VI“)-Schaltung, eine Bildsensor-Prozessor („ISP“)-Schaltung, eine Videobildkompositor („VIC“)-Schaltung, eine optische Flussbeschleuniger („OFA“)-Schaltung, eine programmierbare Sichtbeschleuniger („PVA“)-Schaltung oder eine Deep-Learning-Beschleuniger („DLA“)-Schaltung.
  28. System nach einem der Ansprüche 20 bis 27, ferner umfassend: eine elektrische Vorrichtung, die die Vielzahl von Schaltungen umfasst.
  29. System nach einem der Ansprüche 20 bis 28, wobei die Operation eine diagnostische Operation ist, und die Vielzahl von Schaltungen eine funktionale Operation durchführt, ohne dass die Vielzahl von Teilschaltungen von mindestens einer der einen oder mehreren Schaltungen erkennt, ob ein Fehler während der Durchführung der funktionalen Operation aufgetreten ist.
  30. Systems nach Anspruch 29, ferner umfassend: ein autonomes Fahrzeug, das die Vielzahl der Schaltungen umfasst; und eine Systemsteuerung, die die Vielzahl von Schaltungen abwechselnd anweist, eine neue diagnostische Operation und eine neue funktionale Operation durchzuführen.
  31. System nach Anspruch 29 oder 30, wobei die funktionale Operation eine Operation des fortgeschrittenen Fahrerassistenzsystems („ADAS“) ist.
  32. System nach einem der Ansprüche 20 bis 31, das ein System auf einem Chip ist, das auf einem einzelnen Silicium-Substrat implementiert ist.
DE102023132823.9A 2022-04-29 2023-11-24 Erkennen von hardwarefehlern in datenverarbeitungspipelines Pending DE102023132823A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/CN2022/090219 WO2023206346A1 (en) 2022-04-29 2022-04-29 Detecting hardware faults in data processing pipelines
US18/073,060 2022-12-01
US18/073,060 US20230350744A1 (en) 2022-04-29 2022-12-01 Detecting hardware faults in data processing pipelines

Publications (1)

Publication Number Publication Date
DE102023132823A1 true DE102023132823A1 (de) 2024-06-06

Family

ID=88512102

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102023132823.9A Pending DE102023132823A1 (de) 2022-04-29 2023-11-24 Erkennen von hardwarefehlern in datenverarbeitungspipelines

Country Status (3)

Country Link
US (1) US20230350744A1 (de)
DE (1) DE102023132823A1 (de)
WO (1) WO2023206346A1 (de)

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58105500A (ja) * 1981-11-23 1983-06-23 スペリ・コ−ポレ−シヨン メモリ駆動回路故障検出システム及び方法
US5168499A (en) * 1990-05-02 1992-12-01 California Institute Of Technology Fault detection and bypass in a sequence information signal processor
US6732300B1 (en) * 2000-02-18 2004-05-04 Lev Freydel Hybrid triple redundant computer system
US20030051186A1 (en) * 2001-09-11 2003-03-13 Sun Microsystems, Inc. Methods to restore tests execution after unexpected crashes for use in a distributed test framework
DE10302456A1 (de) * 2003-01-23 2004-07-29 Robert Bosch Gmbh Vorrichtung für sicherheitskritische Anwendungen und sichere Elektronik-Architektur
US7409594B2 (en) * 2004-07-06 2008-08-05 Intel Corporation System and method to detect errors and predict potential failures
US7320114B1 (en) * 2005-02-02 2008-01-15 Sun Microsystems, Inc. Method and system for verification of soft error handling with application to CMT processors
JP5179726B2 (ja) * 2006-06-27 2013-04-10 マーベル ワールド トレード リミテッド 半導体デバイス
JP2009223506A (ja) * 2008-03-14 2009-10-01 Fujitsu Ltd データ処理システム
US8499193B2 (en) * 2010-07-30 2013-07-30 Honeywell International Inc. Integrated dissimilar high integrity processing
US9047184B2 (en) * 2012-07-13 2015-06-02 Arm Limited Processing error detection within pipeline circuitry
JP6217086B2 (ja) * 2013-01-28 2017-10-25 日本電気株式会社 情報処理装置、エラー検出機能診断方法およびコンピュータプログラム
EP2759939B1 (de) * 2013-01-29 2016-06-08 dSPACE digital signal processing and control engineering GmbH Verfahren zum Manipulieren einer Speicheroperation eines Steuergeräteprogramms auf einen virtuellen oder realen Speicher
KR20140134376A (ko) * 2013-05-14 2014-11-24 한국전자통신연구원 오류감지가 가능한 프로세서 및 이를 이용한 프로세서 코어 오류 감지 방법
JP6496562B2 (ja) * 2014-04-11 2019-04-03 ルネサスエレクトロニクス株式会社 半導体装置、診断テスト方法及び診断テスト回路
US10656992B2 (en) * 2014-10-22 2020-05-19 Cavium International Apparatus and a method of detecting errors on registers
CN105843699B (zh) * 2015-02-02 2019-06-04 国际商业机器公司 用于错误监视与校正的动态随机存取存储器设备与方法
US11644834B2 (en) * 2017-11-10 2023-05-09 Nvidia Corporation Systems and methods for safe and reliable autonomous vehicles
US10606678B2 (en) * 2017-11-17 2020-03-31 Tesla, Inc. System and method for handling errors in a vehicle neural network processor
US11335428B2 (en) * 2018-10-09 2022-05-17 Intel Corporation Methods, systems and apparatus for in-field testing for generic diagnostic components
US10911181B2 (en) * 2019-04-02 2021-02-02 Hangzhou Fabu Technology Co., Ltd. Method for checking address and control signal integrity in functional safety applications, related products
GB2583509B (en) * 2019-05-01 2023-02-22 Advanced Risc Mach Ltd System and method for fault detection and correction
EP4096978A4 (de) * 2020-02-21 2024-03-06 Bluespace AI, Inc. Verfahren zur objektvermeidung während der autonomen navigation

Also Published As

Publication number Publication date
US20230350744A1 (en) 2023-11-02
WO2023206346A1 (en) 2023-11-02

Similar Documents

Publication Publication Date Title
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE112021000213T5 (de) Szenarien für virtuelle Umgebungen und Beobachter für Anwendungen autonomer Maschinen
DE112020003043T5 (de) Erkennung und klassifizierung von kreuzungsregionen für autonome maschinenanwendungen
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE112019001605T5 (de) Trainieren, testen und verifizieren von autonomen maschinen unter verwendung simulierter umgebungen
DE102021121558A1 (de) Auf neuronalen netzen basierende bestimmung der blickrichtung unter verwendung räumlicher modelle
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE102021100065A1 (de) Verwendung neuronaler netze zur fehlererkennung bei anwendungen für autonomes fahren
DE112020001396T5 (de) Formfusion zur bildanalyse
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE112020006181T5 (de) Blickbestimmung mit blendung als eingabe
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE102022104026A1 (de) Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren
DE102020130749A1 (de) System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben
DE102022118649A1 (de) Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen
DE102022107848A1 (de) System und verfahren zur aktualisierung von karten mit hoher auflösung
DE102022117475A1 (de) Übermitteln von fehlern an einen isolierten sicherheitsbereich eines systems auf einem chip
DE102022129438A1 (de) Partikelbasierte Gefahrenerfassung für autonome Maschinenanwendungen
DE102022114516A1 (de) Spannungsüberwachung über mehrere-frequenzbereiche für autonome-maschine anwendungen
DE112022002829T5 (de) Wahrnehmungsbasierte schilderfassung und -interpretation für autonome maschinensysteme und -anwendungen
DE102022114521A1 (de) Parallelverarbeitung einer zum einparken geeigneten fahrzeug-wegplanung
DE102022101775A1 (de) Patching eingesetzt in tiefen neuronalen netzwerken für autonome maschinenanwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed