DE102022117475A1

DE102022117475A1 - Übermitteln von fehlern an einen isolierten sicherheitsbereich eines systems auf einem chip

Info

Publication number: DE102022117475A1
Application number: DE102022117475.1A
Authority: DE
Inventors: Padam Patt Krishnani; Avinash J V; Shraddha Manohar Gondkar; Sowmya Satya Venkata Naga Siva Sai Bindu Mandapati
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-07-30
Filing date: 2022-07-13
Publication date: 2023-02-02
Also published as: CN115688093A; US20240300537A1

Abstract

In verschiedenen Beispielen umfasst eine integrierte Schaltung einen ersten und einen zweiten Abschnitt. Der erste Abschnitt beinhaltet einen Timer, der startet, wenn der erste Abschnitt mindestens ein Fehlersignal an den zweiten Abschnitt überträgt. Der Timer kann zurückgesetzt werden, wenn Daten, die mindestens einem Fehler entsprechen, aus dem ersten Abschnitt gelöscht wurden. Der erste Abschnitt überträgt ein Timeout-Fehlersignal, wenn der Timer anzeigt, dass mindestens eine vorbestimmte Zeitdauer verstrichen ist. Der zweite Abschnitt empfängt das mindestens eine Fehlersignal und das Timeout-Fehlersignal, wenn das Timeout-Fehlersignal gesendet wurde. Der zweite Abschnitt kann ein externes System benachrichtigen, nachdem das Timeout-Fehlersignal empfangen wurde.

Description

TECHNISCHES GEBIET
Mindestens eine Ausführungsform betrifft das Kommunizieren von Fehlern, die in einem Bereich einer Schaltung erzeugt werden, an einen anderen Bereich der Schaltung. Zum Beispiel betrifft mindestens eine Ausführungsform ein System auf einem Chip, das verschiedene hierin beschriebene neue Techniken implementiert. Als weiteres Beispiel betrifft mindestens eine Ausführungsform ein autonomes Fahrzeug, das ein solches System auf einem Chip beinhaltet.
ALLGEMEINER STAND DER TECHNIK
Automotive Safety Integrity Level („ASIL“) ist ein Risikoklassifizierungssystem für die funktionale Sicherheit von Straßenfahrzeugen, das von der International Organization for Standardization („ISO“) 26262 Functional Safety Standard definiert wurde. In diesem Risikoklassifizierungssystem gibt es vier Risikoklassifizierungs-Level, die als ASIL-A, ASIL-B, ASIL-C und ASIL-D bezeichnet werden, wobei ASIL-D das höchste Risikoklassifizierungs-Level ist. Daher haben als ASIL-D spezifizierte Komponenten höhere Sicherheitsanforderungen als Komponenten, die mit einem niedrigeren Risikoklassifizierungs-Level (z. B. ASIL-B) spezifiziert sind, und können teurer sein. Bei vielen Automobil-Plattformen werden zumindest einige Sicherheitsdienste von einer externen Steuereinheit ausgeführt, wenn bestimmte Fehler in einem Automobil-System auf einem Chip („SoC“) erkannt werden, das verschiedene Fahrfunktionen eines autonomen oder halbautonomen Fahrzeugs steuert. Im Allgemeinen kann die externe Steuerungseinheit auf einem höheren Risiko-Level (z. B. ASIL-D) arbeiten als das automobile SoC (z. B. ASIL-B). Leider führen solche externen Steuerungseinheiten zu Latenzzeiten und können teuer sein, weil sie getrennte Komponenten benötigen, die auch im automobilen SoC vorhanden sind, wie z. B. DRAM, nichtflüchtiger Speicher usw., und die jeweils Platz innerhalb der Automobil-Plattform (z. B. auf einer Leiterplatte) einnehmen.
AA
Figurenliste
Die vorliegenden Systeme und Verfahren zur Isolierung eines Bereichs eines Systems auf einem Chip werden im Folgenden unter Bezugnahme auf die beigefügten Figuren detailliert beschrieben, wobei:

1 eine Veranschaulichung einer beispielhaften Automobil-Plattform gemäß einiger Ausführungsformen der vorliegenden Offenbarung ist;
2 eine Veranschaulichung einer Beispielschnittstelle(n) ist, die eine in ein automobiles SoC integrierte Sicherheitsinsel mit anderen Komponenten des automobilen SoC gemäß einigen Ausführungsformen der vorliegenden Offenbarung verbindet;
3 ein Ablaufdiagramm ist, das ein Verfahren zum Übergang der Sicherheitsinsel zwischen dem Cocoon- und dem Nicht-Isolations-Modus gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
4 eine Veranschaulichung von beispielhaften Fehlerschnittstellen ist, die gemäß einigen Ausführungsformen der vorliegenden Offenbarung Fehler von den anderen Komponenten des automobilen SoC an die Sicherheitsinsel übermitteln;
5A ist ein Flussdiagramm, das ein Verfahren zur Übermittlung von Fehlern an die Sicherheitsinsel gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
5B ein Ablaufdiagramm ist, das ein Verfahren zeigt, mit dem ein Prozessor gemäß einigen Ausführungsformen der vorliegenden Offenbarung von einem SoC-Fehleraggregator empfangene Unterbrechungen verarbeiten kann;
5C ein Ablaufdiagramm ist, das ein Verfahren zeigt, mit dem die SI 110 gemäß einiger Ausführungsformen der vorliegenden Offenbarung korrigierte und unkorrigierte Fehlersignale verarbeiten kann;
5D ein Ablaufdiagramm ist, das ein Verfahren zeigt, mit dem die SI 110 ein SoC-Fehleraggregatorsignal gemäß einigen Ausführungsformen der vorliegenden Offenbarung verarbeiten kann;
6A veranschaulicht ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit niedrigem Schweregrad (z. B. der Minimalwert) geltend gemacht wurde, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6B veranschaulicht ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit hohem Schweregrad (z. B. der Maximalwert) gemäß einigen vorliegenden Offenbarungen festgestellt wurde;
6C gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein beispielhaftes Signalzeitdiagramm für Signale veranschaulicht, die vom Prozessor der Sicherheitsinsel empfangen und gesendet werden, nachdem ein unkorrigierter Fehler (z. B. der Maximalwert) geltend gemacht wurde, die Sicherheitsinsel jedoch die Mailboxunterbrechung nicht empfängt;
7 ist ein Flussdiagramm, das ein Verfahren zum Schreiben von Daten in einen Ausschnitt zeigt, die in einem flüchtigen Speicher definiert ist, der von der Sicherheitsinsel und den anderen Komponenten des automobilen SoC gemeinsam genutzt wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8 ein Beispiel für einen Block zur Erkennung von Fehlern in der Sicherheitsinsel veranschaulicht, der das Verfahren von 7, gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchführt;
9 ist ein Flussdiagramm, das ein Verfahren zum Lesen von Daten aus dem Ausschnitt gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
10 ein Beispiel für einen Block zur Erkennung von Fehlern in der Sicherheitsinsel veranschaulicht, der das Verfahren von 9, gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchführt;
11 ein Blockdiagramm veranschaulicht, das Fehlermeldungen zeigt, die vom Block für die Erkennung von Fehlern erzeugt werden, wenn der Block für die Erkennung von Fehlern gemäß einiger Ausführungsformen Timer für den Ausgang und den Eintritt einschließt oder mit diesen verbunden ist;
12 ist eine Illustration eines Beispiels für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
13 ist ein Beispiel für die Positionen und Sichtfelder der Kameras für das autonome Fahrzeug von 12 gemäß einiger Ausführungsformen der vorliegenden Offenbarung;
14 ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
15 ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug von 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung; und
16 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung beim Umsetzen einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

DETAILLIERTE BESCHREIBUNG
Es werden Systeme und Verfahren offenbart, die sich auf die Isolierung eines Bereichs einer Schaltung beziehen, der auf einem höheren Risiko-Level (z. B. ASIL-D) arbeitet, von anderen Bereichen der Schaltung, die auf einem niedrigeren Risiko-Level (z. B. ASIL-B) arbeiten. Beispielsweise kann eine Region oder „Insel“, die der funktionalen Sicherheit gewidmet ist, (z. B. kommunikativ) von anderen Komponenten auf einem System auf einem Chip („SoC“), wie z. B. einem automobilen SoC, isoliert sein. 1 ist eine Veranschaulichung einer Automobil-Plattform 100 gemäß mindestens einer Ausführungsform. Die Automobil-Plattform 100 kann ein autonomes oder teilautonomes Fahrzeug implementieren, wie beispielsweise ein autonomes Fahrzeug 1200 (siehe 12). Die Automobil-Plattform 100 beinhaltet ein automobiles Verarbeitungssystem 102, das einen Grad an Fahrautonomie implementieren kann, der größer als Grad 0 (keine Fahrautomatisierung) ist, wie von der Society of Automotive Engineers („SAE“) definiert. Zum Beispiel kann das automobile Verarbeitungssystem 102 Level 2 (teilweise Fahrautomatisierung) bis Level 5 (vollständige Fahrautomatisierung) implementieren, wie durch SAE definiert. Ein Level-2-System kann als fortschrittliches Fahrerassistenzsystem („ADAS“) bezeichnet werden.
Das automobile Verarbeitungssystem 102 beinhaltet mindestens ein automobiles SoC 104. Das automobile SoC 104 führt zumindest einige Funktionen aus, kann aber eine oder mehrere Sicherheitsfunktionen an eine optionale externe Steuereinheit 106 (z. B. einschließlich einer externen ASIL-D-Mikrocontrollereinheit) auslagern. Die optionale externe Steuereinheit 106 kann unter einem höheren Risikoklassifizierungs-Level (z. B. ASIL-D) als das automobile SoC 104 betrieben werden und damit konform sein. In Ausführungsformen, die die optionale externe Steuerungseinheit 106 einschließen, wird bei Auftreten eines Fehlers in der automobilen SoC 104 dieser Fehler an die optionale externe Steuerungseinheit 106 übermittelt, die eine oder mehrere Maßnahmen ergreifen kann, um die Automobil-Plattform 100 in einen sicheren Zustand zu versetzen. Somit kann zumindest ein Abschnitt der Sicherheitsfunktionen durch die optionale externe Steuereinheit 106 durchgeführt werden. Die optionale externe Steuerungseinheit 106 kann jedoch eine Latenzzeit verursachen und teuer sein, weil sie getrennte Komponenten wie DRAM, nichtflüchtigen Speicher usw. benötigt, die jeweils Platz in der Automobil-Plattform 100 (z. B. auf einer Leiterplatte) beanspruchen.
Um zumindest einen Teil der Latenzzeit und des Aufwands zu vermeiden, die durch die optionale externe Steuereinheit 106 entstehen, beinhaltet die Automobil-Plattform 100 von 1 eine funktionale Sicherheitsinsel oder Sicherheitsinsel („SI“) 110, die in den automobilen SoC 104 integriert ist. Die SI 110 kann als Rechen-Cluster implementiert werden, der unter einem höheren Risikoklassifizierungs-Level (z. B. ASIL-D) im Vergleich zum Rest des automobilen SoC 104 betriebsfähig und konform ist. Die SI 110 kann zumindest einen Abschnitt der Funktionen ausführen, die typischerweise von der optionalen externen Steuereinheit 106 durchgeführt werden. Das Vorhandensein der SI 110 ermöglicht es, dass die optionale externe Steuereinheit 106 vollständig weggelassen oder unter Verwendung einer weniger ausgeklügelten implementiert werden kann und/oder kostengünstigere externe Steuereinheit. Wenn zum Beispiel die optionale externe Steuereinheit 106 vorhanden ist, kann sie eine oder mehrere Legacy-Funktionen ausführen, wie z. B. Bereitstellen von Kommunikation auf einem Bus eines Controller-Area-Network („CAN“-Bus), Bereitstellen einer Rücksetzsteuerung für das SoC 104 des Fahrzeugs, und/oder Durchführen einer Bordspannungsüberwachung.
Zusätzlich zu dem automobilen SoC 104 und der optionalen externen Steuerungseinheit 106 (falls vorhanden) kann das automobile Verarbeitungssystem 102 ein erster (SoC-)Taktgeber 112 für den automobilen SoC 104, einen zweite (SI-)Taktgeber 114 für die SI 110 und eine integrierte Schaltung („IC“) zur Energieverwaltung 116 einschließen. Jede der Komponenten des automobilen Verarbeitungssystems 102 ist zumindest teilweise in Hardware implementiert. Die logischen Komponenten des automobilen Verarbeitungssystems 102 (z. B. der automobile SoC 104 und die optionale externe Steuerungseinheit 106) sind in der Regel in Hardware-Logikschaltungen in einem oder mehreren integrierten Schaltkreisen implementiert. Die Logik kann festverdrahtet oder programmierbar oder eine Kombination aus festverdrahteten und programmierbaren Elementen sein. Zusätzlich oder alternativ können bestimmte Funktionen des automobilen Verarbeitungssystems 102 in Software oder Firmware implementiert sein, die von einem eingebetteten Mikroprozessor oder Mikrocontroller ausgeführt werden.
Die ersten und zweiten Taktgeber 112 und 114 stellen zwei getrennte Taktsignale für das automobile SoC 104 bereit. Insbesondere wird ein erstes Taktsignal, das von der ersten (SoC) Uhr 112 erzeugt wird, den Komponenten 160 des automobilen SoC 104 mit Ausnahme der SI 110 bereitgestellt, und ein zweites Taktsignal, das von dem zweiten (SI-)Taktgeber 114 erzeugt wird, wird der SI 110 bereitgestellt. Somit können die SI 110 und die anderen Komponenten 160 als in getrennten Taktdomänen arbeitend bezeichnet werden. Die Taktdomäne der SI 110 wird als eine SI-Taktdomäne bezeichnet und die Taktdomäne der anderen Komponenten 160 wird als eine SoC-Taktdomäne bezeichnet. Der erste und der zweite Taktgeber 112 und 114 können jeweils zumindest teilweise als Quarzoszillatoren implementiert sein. Der erste (SoC-)Taktgeber 112 kann mit jeder der anderen Komponenten 160 des automobilen SoC 104 über eine erste Taktverbindung (nicht gezeigt) verbunden sein, wie beispielsweise eine Leitung, eine Signalspur und dergleichen. So kann der erste (SoC-)-Taktgeber 112 den anderen Komponenten 160 des automobilen SoC 104 über die erste Taktverbindung (nicht gezeigt) das erste Taktsignal bereitstellen. Der zweite (SI-)Taktgeber 114 kann mit jeder von zumindest einigen der Komponenten der SI 110 über eine (nicht gezeigte) zweite Taktverbindung verbunden sein, wie z. B. einen Draht, eine Signalbahn und dergleichen. So kann der zweite (SI-)Taktgeber 114 das zweite Taktsignal für die SI 110 über die zweite Taktverbindung (nicht gezeigt) bereitstellen.
Der Energieverwaltungs-IC 116 liefert Leistung an andere Komponenten des automobilen Verarbeitungssystems 102. Zum Beispiel verbinden Stromschienen oder Verbindungen 118A-118C den Energieverwaltungs-IC 116 mit den anderen Komponenten 160 des automobilen SoC 104, der SI 110/der optionalen externen Steuerungseinheit 106. Die Stromanschlüsse 118A- 118C helfen dabei, die anderen Komponenten 160 des automobilen SoC 104, der Sl 110 und der optionalen externen Steuereinheit 106 (falls vorhanden) elektrisch voneinander zu isolieren. Somit kann die SI 110 in einer von den anderen Komponenten 160 und der optionalen externen Steuerungseinheit 106 (sofern vorhanden) getrennten Domäne arbeiten. Die Spannungsdomäne der SI 110 wird als eine SI-Spannungsdomäne bezeichnet und die Spannungsdomäne der anderen Komponenten 160 wird als eine SoC-Spannungsdomäne bezeichnet. Der Energieverwaltungs-IC 116 kann als eine oder mehrere integrierte Schaltungen implementiert sein, die Komponenten des automobilen Verarbeitungssystems 102 mit angemessener Leistung versorgen. Die Stromanschlüsse 118A - 118C können jeweils als leitfähiges Element implementiert sein, wie beispielsweise eine elektrische Übertragungsleitung, ein Draht, eine Strombahn und dergleichen.
Wie bereits erwähnt, ist die Sl 110 in der SI-Taktdomäne und der SI-Spannungsdomäne betriebsfähig. Zusammen werden die SI-Taktdomäne und die SI-Spannungsdomäne als SI-Domäne bezeichnet. In ähnlicher Weise arbeiten auch die anderen Komponenten 160 in der SoC-Taktdomäne und der SoC-Spannungsdomäne. Zusammen werden die SoC-Taktdomäne und die SoC-Spannungsdomäne als SoC-Domäne bezeichnet.
Die anderen Komponenten 160 des automobilen SoC 104 können einen Komplex 120 einer zentralen Hauptverarbeitungseinheit („CPU“), eine Hilfssicherheitseinheit 122, eine Schaltung 124 zum Durchführen von automobilen SoC-Funktionen, einen flüchtigen Datenspeicher oder Speicher 126 (z. Zugangsspeicher („DRAM“)) und nichtflüchtiger Datenspeicher oder Speicher 128. Der Haupt-CPU-Komplex 120 kann als ein oder mehrere Prozessoren implementiert werden, die bei ASIL-B arbeiten. In solchen Ausführungsformen kann das automobile SoC 104 mit mehreren oder gemischten ASILs arbeiten, weil die SI 110 mit einem höheren ASIL-Level (z. B. ASIL-D) arbeiten kann. Als nicht einschränkende Beispiele kann die Schaltung 124 Hardware beinhalten, die ein oder mehrere Displays implementiert, ein oder mehrere Automobil-Eingabe/Ausgabe(„E/A“)-Steuerung, ein oder mehrere Speichersteuerungen, eine oder mehrere Verbindungen usw. In der dargestellten Ausführungsform ist die Schaltung 124 so dargestellt, dass er eine Vielzahl von Logikblöcken LB(1) - LB(N) beinhaltet oder implementiert, die oft jeder als geistiges Eigentum „IP“ bezeichnet sind. Die Logikblöcke LB(1) - LB(N) können verschiedene Funktionen innerhalb des autonomen Fahrzeugs implementieren (z. B. das autonome Fahrzeug 1200, veranschaulicht in 12).
Die optionale externe Steuereinheit 106 kann eine Steuerung 130, einen Fehleraggregator 132, einen flüchtigen Datenspeicher oder Speicher 136 (z. B. DRAM) und einen nichtflüchtigen Datenspeicher oder Speicher 138 beinhalten. Die optionale externe Steuereinheit 106 kann auch einen oder mehrere Logikblöcke (nicht gezeigt) beinhalten, die diese Sicherheitsfunktionen implementieren, die von der optionalen externen Steuereinheit 106 durchgeführt werden. Die Steuerung 130 kann als ein oder mehrere Prozessoren (z. B. Mikrocontroller) implementiert sein, die bei ASIL-D arbeiten. Die Steuerung 130 führt Anweisungen aus, wie etwa Anweisungen, die mit einem oder mehreren Automotive-Open-System-Architecture („AUTOSAR“)-Softwarestandards konform sind, die in dem nichtflüchtigen Speicher 138 gespeichert sind. Die Anweisungen können die Steuerung 130 anweisen, geeignete Maßnahmen zu ergreifen, wenn der Fehleraggregator 132 einen Fehler von dem Automobil-SoC 104 empfängt.
In einer oder mehreren Ausführungsformen umfasst die SI 110 einen Prozessor 140, einen Unterbrechungscontroller 141, einen SI-Fehleraggregator 142, einen flüchtigen Datenspeicher oder Speicher 146 (z. B. einen statischen direkten Speicherzugriff („SRAM“)) und einen oder mehrere Logikblöcke 148. Der Prozessor 140 kann als ein Cluster von Prozessoren implementiert sein, wie z. B. hochbewertete ASIL-D-Sicherheitsprozessoren. Der Prozessor 140 führt Anweisungen 149 aus, z. B. Anweisungen, die mit dem/den AUTOSAR-Software-Standard(s) konform sind, die beim Hochfahren aus dem nichtflüchtigen Speicher 128 abgerufen und im flüchtigen Speicher 146 gespeichert werden. Die Anweisungen 149 können den Prozessor 140 anweisen, geeignete Maßnahmen zu ergreifen, wenn der SI-Fehleraggregator 142 einen Fehler von den anderen Komponenten 160 des automobilen SoC 104 empfängt. Der/die Logikblock(s) 148 kann/können dabei helfen, diese Sicherheitsfunktionen zu implementieren, die von der SI 110 durchgeführt werden.
Die Hilfssicherheitseinheit 122 kann als Echtzeit-Sicherheitshilfsverarbeitungseinheit implementiert sein und/oder kann als ASIL-B oder höher eingestuft werden. Mit anderen Worten, die Hilfssicherheitseinheit 122 kann auf demselben Risikoklassifizierungs-Level wie oder auf einem höheren Risikoklassifizierungs-Level als andere Komponenten innerhalb der SoC-Domäne arbeiten. Die Hilfssicherheitseinheit 122 beinhaltet einen Prozessor 150, einen oder mehrere SoC-Fehleraggregatoren 152, einen Unterbrechungscontroller 154 und einen oder mehrere Logikblöcke, die als Mailbox(en) 156 bezeichnet werden. Der SI-Fehleraggregator 142 und der Fehleraggregator 132 (sofern vorhanden) können jeweils Fehler von dem/den SoC-Fehleraggregator(en) 152 empfangen. Somit können der/die SoC-Fehleraggregator(en) 152 über eine oder mehrere Fehlerschnittstellen 170 mit dem Fehleraggregator 132 verbunden sein und sind über eine oder mehrere Fehlerschnittstellen 172 mit dem SI-Fehleraggregator 142 verbunden. Jede der Fehlerschnittstellen 170 und 172 schließt eine Verbindung ein, wie beispielsweise einen Draht, eine Signalspur oder ähnliches, die jeden der SoC-Fehleraggregatoren 152 physisch mit einem der Fehleraggregatoren 132 oder dem SI-Fehleraggregator 142 verbindet.
Die Mailbox(en) 156 kann eine erste Mailbox einschließen, in die der Prozessor 150 schreibt und aus der der Prozessor 140 liest, und eine zweite Mailbox, in die der Prozessor 140 schreibt und aus der der Prozessor 150 liest. Die Mailbox(en) 156 kann/können von dem Prozessor 150 (z. B. einer zentralen Verarbeitungseinheit („CPU“) mit ASIL-B oder höher) verwendet werden, um Mailbox-Unterbrechungen an den Unterbrechungscontroller 141 zu melden und Unterbrechungen von dem Unterbrechungscontroller 141 zu empfangen. Somit beinhalten die Fehlerschnittstelle(n) 172 mindestens einen Signalleiter, der die Mailbox(en) 156 mit dem Unterbrechungscontroller 141 verbindet. Jeder Mailboxunterbrechung beinhaltet einen Schweregrad-Bezeichner, der einen Schweregrad des Fehlers anzeigt. Als nicht einschränkendes Beispiel kann der Schweregrad-Bezeichner ein numerischer Wert sein, der von einem Minimalwert (z. B. null) bis zu einem Maximalwert (z. B. sieben) reicht. Als weiteres nicht einschränkendes Beispiel kann die Unterbrechung eine Unterbrechungs-Nummer haben, die a priori codiert ist, um den Schweregrad anzuzeigen. Der Prozessor 140 und/oder der Prozessor 150 kann Fehlerinformationen in die Mailbox(en) 156 schreiben. Die Fehlerinformationen beinhalten Informationen über den/die Fehler, der/die den Fehler erzeugt hat/haben, wie beispielsweise Logikblockname(n), wo der/die Fehler aufgetreten sind, Logikblock-Diagnosebezeichner, Art des Fehlers, Schweregrad-Bezeichner und dergleichen.
Das Integrieren der SI 110 in das automobile SoC 104 kann ermöglichen, dass eine Anzahl separater Komponenten (z. B. der flüchtige Speicher 136 und der nichtflüchtige Speicher 138) aus dem automobilen Verarbeitungssystem 102 weggelassen werden, wenn die optionale externe Steuereinheit 106 ebenfalls weggelassen wird. Dennoch ist es notwendig, die SI 110 von den anderen Komponenten 160 (z. B. dem Haupt-CPU-Komplex 120, der Hilfssicherheitseinheit 122, der Schaltung 124, dem flüchtigen Speicher 126 und dem nichtflüchtigen Speicher 128) des automobilen SoC zu isolieren 104, sodass potenzielle Probleme, die in einer oder mehreren der anderen Komponenten 160 auftreten, die SI 110 nicht negativ beeinflussen. Eine solche Isolierung kann zum Beispiel verhindern, dass die SI 110 durch einen Ausfall in einer oder mehreren der anderen Komponenten 160 des automobilen SoC 104 beeinträchtigt wird. Nicht einschränkende Beispiele für Ausfälle, die in einer oder mehreren der anderen Komponenten 160 auftreten können, schließen zufällige Fehler, Taktprobleme, Stromversorgungsprobleme und/oder Spannungsprobleme ein. Aufgrund der räumlichen Nähe und einer oder mehrerer Schnittstellen 200 (siehe 2), die die SI 110 mit den anderen Komponenten 160 des automobilen SoC 104 teilt, können solche Ausfälle auf die SI 110 übergreifen und die SI 110 daran hindern, die Fallback- und/oder Failsafe-Funktionalität auszuführen, für die die SI 110 in das automobile SoC 104 integriert wurde. Somit isoliert das automobile Verarbeitungssystem 102 die SI 110 von den anderen Komponenten 160 des automobilen SoC 104, um eine Isolierung zu erreichen, die mit der zwischen dem automobilen SoC 104 und der optionalen externen Steuerungseinheit 106 vergleichbar ist. Eine solche Isolierung kann durch den ersten und den zweiten Taktgeber 112 und 114, den ersten und den zweiten Stromanschluss 118A und 118B und die Schnittstelle(n) 200 erreicht werden.
Der erste (SoC-)Taktgeber 112 ist von dem zweiten (SI-)Taktgeber 114 getrennt (z. B. schließt er einen separaten Referenzkristall ein), was dazu beiträgt, die Sl 110 von den anderen Komponenten 160 des automobilen SoC 104 zu isolieren. Ebenso ist der erste Stromanschluss 118A vom zweiten Stromanschluss 118B getrennt, was dazu beiträgt, die SI 110 von den anderen Komponenten 160 des automobilen SoC 104 zu isolieren. Wie bereits erwähnt, kann die SI 110 in der von den anderen Komponenten 160 des automobilen SoC 104 getrennten SI-Spannungsdomäne betrieben werden. Aber auch mit dem getrennten zweiten (SI-)Taktgeber 114 und dem getrennten zweiten Stromanschluss 118B kommuniziert die SI 110 mit den anderen Komponenten 160 des autobmobilen SoC 104 über die Schnittstelle(n) 200 (siehe 2).
Der (die) Logikblock(e) 148 beinhaltet (beinhalten) eine Takt- und Rücksetzschaltung 230 (siehe 2), die mit dem dedizierten zweiten (SI-)Taktgeber 114 verbunden ist. Der dedizierte zweite (SI-)-Taktgeber 114 kann als ein Referenz-Taktgeber für die Takt- und Rücksetzschaltung 230 verwendet werden. Beispielsweise kann die Takt- und Rücksetzschaltung 230 einen internen dedizierten Phasenregelkreis („PLL“) beinhalten, der verwendet wird, um andere Funktions- und Debug-Takte der SI 110 abzuleiten. Als nicht einschränkende Beispiele kann die Takt- und Rücksetzschaltung 230 ein Debug-Taktsignal und ein Test-Taktsignal bereitstellen, die von der PLL abgeleitet werden können. Die Takt- und Rücksetzschaltung 230 kann alle Takt- und Rücksetzsignale erzeugen, die innerhalb der SI 110 verwendet werden. Mit anderen Worten, die Takt- und Rücksetzschaltung 230 kann das (die) Taktsignal(e) und Rücksetz(e) erzeugen, die innerhalb der SI-Domäne verwendet werden. Zusätzlich oder alternativ kann der zweite (SI-)Taktgeber 114 direkt als funktionaler Taktgeber für einen oder mehrere der Logikblöcke 148 verwendet werden. Auf diese Weise verwendet die SI 110 das/die lokal erzeugte(n) Taktsignal(e) und Rücksetzung(en) und/oder das vom zweiten (SI-)Taktgeber 114 bereitgestellte Taktsignal. In der SI 110 werden keine Taktsignale oder Rücksetzungen von den anderen Komponenten 160 verwendet. Die Takt- und Rücksetzschaltung 230 trägt dazu bei sicherzustellen, dass keine Störung von der Logik, die Rücksetzungen (z. B. Rücksetzblöcke) innerhalb der anderen Komponenten 160 erzeugt, die Komponenten der SI 110 erreicht.
2 ist eine Veranschaulichung der Schnittstelle(n) 200, die die SI 110 gemäß mindestens einer Ausführungsform mit den anderen Komponenten 160 des automobilen SoC 104 verbindet. Unter Bezugnahme auf 2 stellen die Schnittstelle(n) 200 eine logische Isolierung für die Schaltung und Logik der SI 110 in dem automobilen SoC 104 bereit. In der dargestellten Ausführungsform umfassen die Schnittstelle(n) 200 die Fehlerschnittstelle(n) 172, eine flüchtige Speicherschnittstelle 200A, eine erste Steuer-Backbone-Schnittstelle 200B, eine zweite Steuer-Backbone-Schnittstelle 200C, eine sichere Inhaltsschnittstelle 200D, eine Debug-Schnittstelle 200E und eine Testschnittstelle 200F. Die Fehlerschnittstelle(n) 172 ist (sind) möglicherweise nicht logisch von dem (den) SoC-Fehleraggregator(en) 152 isoliert, sondern durchläuft (durchlaufen) oder schließt (schließen) jeweils einen oder mehrere Spannungspegelwandler 240 ein, die jeweils eine elektrische Isolierung zwischen der Sl- und der SoC-Spannungsdomäne bereitstellen. Während der (die) Spannungspegelwandler 240 jeweils eine elektrische Isolierung bereitstellen, kann/können der/die Spannungspegelwandler 240 keine angemessene Isolierung für einige Arten von Fehlern bereitstellen, wie z. B. Unterbrechungsstürme, Fehlerstürme, und/oder kontinuierliche Behauptungen. Der SI-Fehleraggregator 142 kann ein oder mehrere Statusbits 242 einschließen, die Fehlerinformationen über die Fehlerschnittstelle(n) 172 empfangen und den vom Prozessor 140 ausgeführten Anweisungen 149 eine Benachrichtigung über solche Ausfälle bereitstellen. In der dargestellten Ausführungsform umfassen die Statusbits 242 die Statusbits „BT1“, „BT2“ und „BT3“ (siehe 4). Die Anweisungen 149 weisen den Prozessor 140 an, diese Benachrichtigung zu verwenden, um Ausfälle abzumildern, die an der/den Fehlerschnittstelle(n) 172 auftreten.
Die flüchtige Speicherschnittstelle 200A ist eine Schnittstelle zwischen dem Prozessor 140 und dem flüchtigen Speicher 126 des automobilen SoC 104. Die flüchtige Speicherschnittstelle 200A ermöglicht dem Prozessor 140, Informationen in den flüchtigen Speicher 126 zu schreiben und Informationen aus dem flüchtigen Speicher 126 zu lesen. Die flüchtige Speicherschnittstelle 200A umfasst eine oder mehrere Verbindungen mit dem flüchtigen Speicher 126, wie z. B. einen Draht, eine Signalspur und dergleichen. Die flüchtige Speicherschnittstelle 200A kann die logische Isolationssteuerung 220, einen Zugangs-Timer 222 und eine Domänensynchronisierungsschaltung 224 beinhalten. Die logische Isolationssteuerung 220 beinhaltet einen Tor- oder Verriegelungsmechanismus, der durch den Prozessor 140 selektiv gesperrt und entsperrt werden kann. Der Zugangs-Timer 222 lässt zu, dass ein Zugangsversuch, der durch den Prozessor 140 initiiert wird, zeitlich abläuft.
Die Domänensynchronisationsschaltung 224 umfasst eine Phasensynchronisationsschaltung und einen oder mehrere Spannungspegelwandler. Die Phasensynchronisationsschaltung hilft dabei, die Phasen von Signalen zu synchronisieren, die über die SI- und SoC-Domänen kommuniziert werden, die unter Verwendung der separaten ersten und zweiten Takte 112 und 114 (siehe 1) erzeugt wurden. Von der Takt- und Rücksetzschaltung 230 erzeugte Rücksetzungen können von beliebigen Elementen verwendet werden, die die SI- und SoC-Spannungs- und -Taktdomänen kreuzen, wie beispielsweise die Phasensynchronisationsschaltung. Die Phasensynchronisationsschaltung weist einen SoC-Abschnitt und einen SI-Abschnitt auf, die jeweils als separate Synthesespitzen fungieren können. Der SoC-Abschnitt befindet sich physikalisch in der SoC-Domäne und der SI-Abschnitt befindet sich physikalisch in der SI-Domäne. Die Logik sowohl der SI- als auch des SoC-Abschnitts verwendet Rücksetzungen, die von der Takt- und Rücksetzschaltung 230 erzeugt werden. So können die vom SI 110 erzeugten Rücksetzungen von der Logik des automobilen SoC 104 verwendet werden, das mit einem niedrigeren ASIL als die SI 110 arbeiten kann, aber die vom automobilen SoC 104 erzeugten Rücksetzungen werden der SI 110 nicht mitgeteilt und können von diesem nicht verwendet werden. Als nicht einschränkendes Beispiel kann die Phasensynchronisationsschaltung als geteiltes First-In-First-Out („Fifo“) und dergleichen implementiert werden. Der/die Spannungspegelwandler der Bereichssynchronisationsschaltung 224 kann/können im Wesentlichen identisch mit dem/den Spannungspegelwandler(n) 240 sein und die Spannung der Signale einstellen, die über die SI- und SoC-Spannungsdomänen übertragen werden, um eine sichere Übertragung der Signale zu ermöglichen über die SI- und SoC-Domänen hinweg. Wenn der Zugangs-Timer 222 anzeigt, dass ein Zugang durch den Prozessor 140 abgelaufen ist, kann die Anforderung von der Domänensynchronisationsschaltung 224 entfernt werden (z. B. aus dem geteilten FIFO entnommen werden).
Wenn die flüchtige Speicherschnittstelle 200A entsperrt ist, kann der Prozessor 140 auf den flüchtigen Speicher 126 zugreifen, was den Zugangs-Timer 222 startet. Wenn der Zugangs-Timer 222 anzeigt, dass mehr als eine erste vorbestimmte Zeitdauer verstrichen ist und eine Antwort von dem flüchtigen Speicher 126 nicht empfangen wurde, zeigt der Prozessor 140 einen Sicherheitsfehler an und verwendet die logische Isolationssteuerung 220, um die flüchtige Speicherschnittstelle 200A zu sperren, sperrt optional eine oder mehrere der Schnittstellen 200, die entsperrt sind, und führt optional eine oder mehrere Maßnahmen durch, die konfiguriert sind, um die Fahrzeugplattform 100 (siehe 1) in einen sicheren Zustand zurückzubringen. Wenn andererseits die Antwort empfangen wird, bevor der Zugangs-Timer 222 anzeigt, dass die erste vorbestimmte Zeitdauer verstrichen ist, setzt sich der Zugangs-Timer 222 selbst zurück, der Prozessor 140 schließt den Zugang ab und der Prozessor 140 sperrt die flüchtige Speicherschnittstelle 200A nachdem der Zugang abgeschlossen ist. Somit bleibt/bleiben die flüchtige Speicherschnittstelle(n) 200A gesperrt, wann immer der Prozessor 140 nicht auf den flüchtigen Speicher 126 zugreift, was dazu beiträgt, die SI 110 vor Fehlern zu schützen und/oder Ausfälle, die vom flüchtigen Speicher 126 zum SI 110 wandern.
Die erste und zweite Steuer-Backbone-Schnittstelle 200B und 200C sind Schnittstellen zwischen dem Prozessor 140 und einem Steuer-Backbone 210. Das Steuer-Backbone 210 kann als Bus und dergleichen implementiert sein. Die erste Steuer-Backbone-Schnittstelle 200B dient der Kommunikation zwischen dem Prozessor 140 und dem Steuer-Backbone 210, und die zweite Steuer-Backbone-Schnittstelle 200C dient der Kommunikation zwischen dem Steuer-Backbone 210 und dem Prozessor 140. Als nicht einschränkendes Beispiel kann der Prozessor 140 auf zumindest einige der anderen Komponenten 160 (z. B. die Schaltung 124, die Mailbox(en) 156 und den nichtflüchtigen Speicher 128) des automobilen SoC 104 zugreifen das Steuer-Backbone 210.
Die erste Steuer-Backbone-Schnittstelle 200B ermöglicht es dem Prozessor 140, Anweisungen und/oder Informationen an das Steuer-Backbone 210 zu senden. Die erste Steuer-Backbone-Schnittstelle 200B kann die logische Isolationssteuerung 220, den Zugangs-Timer 222, die Domänensynchronisierungsschaltung 224 und eine Firewall 226 beinhalten. Die logische Isolationssteuerung 220 der ersten Steuer-Backbone-Schnittstelle 200B ist im Wesentlichen identisch mit und funktioniert im Wesentlichen identisch mit der logischen Isolationssteuerung 220 der flüchtigen Speicherschnittstelle 200A. So erlaubt die logische Isolationssteuerung 220 der ersten Steuer-Backbone-Schnittstelle 200B dem Prozessor 140, die erste Steuer-Backbone-Schnittstelle 200B zu sperren und zu entsperren. Der Zugangs-Timer 222 der ersten Steuer-Backbone-Schnittstelle 200B erlaubt es, einen durch den Prozessor 140 eingeleiteten Zugangsversuch zu unterbrechen. Die Domänensynchronisationsschaltung 224 der ersten Steuer-Backbone-Schnittstelle 200B ist im Wesentlichen identisch mit und funktioniert im Wesentlichen identisch mit der Domänensynchronisationsschaltung 224 der flüchtigen Speicherschnittstelle 200A. Die Firewall 226 der ersten Steuer-Backbone-Schnittstelle 200B implementiert eine oder mehrere Sicherheitsregeln und erlaubt oder blockiert basierend auf der/den Sicherheitsregel(n) jede Kommunikation.
Über die zweite Steuer-Backbone-Schnittstelle 200C kann der Prozessor 140 Anweisungen und/oder Informationen von der Steuer-Backbone-Schnittstelle 210 empfangen. Die zweite Steuer-Backbone-Schnittstelle 200C kann die logische Isolationssteuerung 220, die Domänensynchronisationsschaltung 224 und die Firewall 226 beinhalten. Die logische Isolationssteuerung 220 der zweiten Steuer-Backbone-Schnittstelle 200C ist im Wesentlichen identisch mit der logischen Isolationssteuerung 220 der flüchtigen Speicherschnittstelle 200A und funktioniert im Wesentlichen genauso. So ermöglicht die logische Isolationssteuerung 220 der zweiten Steuer-Backbone-Schnittstelle 200C dem Prozessor 140, die zweite Steuer-Backbone-Schnittstelle 200C zu sperren und zu entsperren. Die Domänensynchronisationsschaltung 224 der zweiten Steuer-Backbone-Schnittstelle 200C ist im Wesentlichen identisch mit der Domänensynchronisationsschaltung 224 der flüchtigen Speicherschnittstelle 200A und funktioniert im Wesentlichen genauso wie diese. Die Firewall 226 der zweiten Steuer-Backbone-Schnittstelle 200C implementiert eine oder mehrere Sicherheitsregeln und erlaubt oder blockiert basierend auf der/den Sicherheitsregel(n) jede Kommunikation.
Die Schnittstelle 200D für sicheren Inhalt ist eine Schnittstelle zwischen dem Prozessor 140 und der Schaltung 212 für sicheren Inhalt. Die sichere Inhaltsschnittstelle 200D ermöglicht es dem Prozessor 140, Anweisungen zu empfangen und/oder Informationen (z. B. sichere und/oder vertraulicher Inhalt) von der sicheren Inhaltsschaltung 212. Die sichere Inhaltsschnittstelle 200D kann die logische Isolationssteuerung 220 und die Domänensynchronisierungsschaltung 224 beinhalten. Die logische Isolationssteuerung 220 der sicheren Inhaltsschnittstelle 200D ist im Wesentlichen identisch mit der logischen Isolationssteuerung 220 der flüchtigen Speicherschnittstelle 200A und funktioniert im Wesentlichen genauso wie diese. Somit ermöglicht die logische Isolationssteuerung 220 der sicheren Inhaltsschnittstelle 200D dem Prozessor 140, die sichere Inhaltsschnittstelle 200D zu sperren und zu entsperren. Die Domänensynchronisationsschaltung 224 der sicheren Inhaltsschnittstelle 200D ist im Wesentlichen identisch mit der Domänensynchronisationsschaltung 224 der Schnittstelle für flüchtigen Speicher 200A und funktioniert im Wesentlichen genauso wie diese.
Die Debug-Schnittstelle 200E ist eine Schnittstelle zwischen dem Prozessor 140 und der Debug-Schaltung 214. Die Debug-Schnittstelle 200E erlaubt dem Prozessor 140 Anweisungen zu empfangen und/oder Informationen von der Debug-Schaltung 214. Die Debug-Schnittstelle 200E kann die logische Isolationssteuerung 220 und die Domänensynchronisationsschaltung 224 beinhalten. Die logische Isolationssteuerung 220 der Debug-Schnittstelle 200E ist im Wesentlichen identisch mit der logischen Isolationssteuerung 220 der flüchtigen Speicherschnittstelle 200A und funktioniert im Wesentlichen genauso. Somit ermöglicht die logische Isolationssteuerung 220 der Debug-Schnittstelle 200E dem Prozessor 140, die Debug-Schnittstelle 200E zu sperren und zu entsperren. Die Domänensynchronisationsschaltung 224 der Debug-Schnittstelle 200E ist im Wesentlichen identisch mit der Domänensynchronisationsschaltung 224 der Schnittstelle für den flüchtigen Speicher 200A und funktioniert im Wesentlichen genauso wie diese. Wie bereits erwähnt, arbeiten die SI 110 und die anderen Komponenten 160 in getrennten Domänen. In einer oder mehreren Ausführungsformen speisen keine Signale von einem externen Taktgeber einer oder mehrerer der anderen Komponenten 160 des automobilen SoC 104, wie etwa der Debug-Schaltung 214, in die Sl 110 ein. Von dem Automobil-SoC 104 durchgeführte Debug-Funktionen empfangen das Debug-Taktsignal über die Domänensynchronisierungsschaltung 224 der Debug-Schnittstelle 200E, die die von dem Automotive-SoC 104 durchgeführten Debug-Funktionen umschaltet oder umwandelt, um das von der SI 110 erzeugte Debug-Taktsignal zu verwenden und/oder den zweiten (SI-)Taktgeber 114. Da die Debug-Logik nicht verwendet wird, während sich die SI 110 im Missionsmodus befindet (z. B. wenn das Fahrzeug fährt), beinhaltet die Sl 110 ein erstes Taktgatter auf dem Debug-Takt, um jegliche Interferenz zu verhindern, die möglicherweise dadurch verursacht werden könnte das Debug-Taktsignal. Als nicht einschränkendes Beispiel kann das erste Taktgatter eine Komponente die Takt- und Rücksetzschaltung 230 sein. Das erste Taktgatter kann durch die Steuerung eines ersten Konfigurationsbits, das vom Prozessor 140 gesetzt wird, gesteuert werden (z. B. selektiv ein- und ausgeschaltet werden).
Die Testschnittstelle 200F ist eine Schnittstelle zwischen dem Prozessor 140 und der Testschaltung 216. Die Testschnittstelle 200F ermöglicht es dem Prozessor 140, Anweisungen zu empfangen und/oder Informationen von der Testschaltung 216. Die Testschnittstelle 200F kann die logische Isolationssteuerung 220 und die Domänensynchronisationsschaltung 224 beinhalten. Die logische Isolationssteuerung 220 der Testschnittstelle 200F ist im Wesentlichen identisch mit der logischen Isolationssteuerung 220 der flüchtigen Speicherschnittstelle 200A und funktioniert im Wesentlichen genauso wie diese. So ermöglicht die logische Isolationssteuerung 220 der Testschnittstelle 200F dem Prozessor 140, die Testschnittstelle 200F zu sperren und zu entsperren. Die Domänensynchronisationsschaltung 224 der Testschnittstelle 200F ist im Wesentlichen identisch mit der Domänensynchronisationsschaltung 224 der Schnittstelle für den flüchtigen Speicher 200A und funktioniert im Wesentlichen genauso wie diese. Wie oben erwähnt, wird durch diese Konfiguration verhindert, dass externe Signale von einer oder mehreren der anderen Komponenten 160 des automobile SoC 104, wie etwa der Testschaltung 216, in die SI 110 eingespeist werden. Die vom automobilen SoC 104 durchgeführten Testfunktionen empfangen das Testtaktsignal über die Domänensynchronisationsschaltung 224 der Debug-Schnittstelle 200E, die die vom automobilen SoC 104 durchgeführten Testfunktionen auf die Verwendung des vom SI 110 und/oder dem zweiten (SI-)Taktgeber 114 erzeugten Testtaktsignals umschaltet oder umwandelt. Da die Testlogik nicht verwendet wird, während sich die SI 110 im Missionsmodus befindet (z. B. wenn das Fahrzeug fährt), schließt der SI 110 ein zweites Taktgatter in den Test-Taktgeber ein, um jegliche Störungen zu unterbinden, die möglicherweise durch das Testtaktsignal verursacht werden könnten. Als nicht einschränkendes Beispiel kann das zweite Taktgatter eine Komponente der Takt- und Rücksetzschaltung 230 sein. Das zweite Taktgatter kann durch die Steuerung eines zweiten Konfigurationsbits, das vom Prozessor 140 gesetzt wird, gesteuert werden (z. B. selektiv ein- und ausgeschaltet werden).
Die SI 110 kann mindestens zwei Betriebsmodi haben, einen isolierten oder Cocoon-Modus und einen nicht-isolierten Modus. Wenn die SI 110 im Cocoon-Modus arbeitet, sind die einzigen Informationen, die vom automobilen SoC 104 in die SI 110 eindringen dürfen, Fehlerinformationen, die über die Fehlerschnittstelle(n) 172 in die SI 110 eindringen. Auf diese Weise behält die SI-Fehleraggregator 142 einen kumulativen Funktionszustand des automobilen SoC 104 und der SI 110 bei. Wenn andererseits die SI 110 im nicht isolierten Modus arbeitet, können Informationen über eine oder mehrere der Schnittstelle(n) 200 in die SI 110 gelangen. Ob die SI 110 im Cocoon-Modus oder im nicht-isolierten Modus arbeitet, wird zumindest teilweise durch die vom Prozessor 140 ausgeführten Anweisungen 149 und zumindest teilweise durch die Schnittstelle(n) 200 bestimmt.
Um zu verhindern, dass ein potenzielles sicherheitskritisches Problem, das von den anderen Komponenten 160 des automobilen SoC 104 ausgeht, über eine oder mehrere der Schnittstelle(n) 200 zur SI 110 gelangt, beinhaltet jede der Schnittstelle(n) 200 die getrennte logische Isolationssteuerung 220, die durch den Prozessor 140 selektiv gesperrt und entsperrt wird. Wenn der Verriegelungsmechanismus der logischen Isolationssteuerung 220 durch den Prozessor 140 gesperrt ist, verhindert der Verriegelungsmechanismus jegliche Kommunikation zwischen dem automobilen SoC 104 und der SI 110 über die gesperrte Schnittstelle. Andererseits kann die Schnittstelle durch den Prozessor 140 entsperrt werden, um eine solche Kommunikation über die entsperrte Schnittstelle zu ermöglichen. Auf diese Weise kann der Prozessor 140 die Sl 110 selektiv in den Cocoon-Modus oder den nicht-isolierten Modus aufsetzen. Immer wenn alle Schnittstelle(n) 200 gesperrt ist, kann der Prozessor 140 weder auf den flüchtigen Speicher 126 noch auf den nichtflüchtigen Speicher 128 zugreifen und führt die Anweisungen 149 aus, die in dem flüchtigen Speicher 146 (z. B. SRAM), der sich innerhalb der SI 110 befindet, gespeichert sind.
Unter nunmehriger Bezugnahme auf 3 umfasst jeder Block des hier beschriebenen Verfahrens 300 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen von einem Prozessor (z. B. dem in 1, 2 und 4 veranschaulichten Prozessor 140) ausgeführt werden, der darin gespeicherte Anweisungen (z. B. die in 1, 2 und 4 veranschaulichten Anweisungen 149) ausführt Speicher (z. B. der in den 1, 2 und 4 dargestellte flüchtige Speicher 146). Das Verfahren 300 kann auch als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 300 kann 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 300 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 300 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
3 ist ein Ablaufdiagramm, das das Verfahren 300 für den Übergang der SI 110 zwischen den Cocoon und Nicht-Isolations-Modi gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Zur Vereinfachung der Darstellung wird das Verfahren 300 so beschrieben, dass es von dem Prozessor 140 durchgeführt wird (siehe 1, 2 und 4). Unter Bezugnahme auf 3 stellt der Prozessor 140 im ersten Block 302 fest, dass er mit einer der anderen Komponenten 160 (siehe 1 und 2) des automobilen SoC 104 kommunizieren muss. Beispielsweise kann diese Kommunikation über die flüchtige Speicherschnittstelle 200A oder die erste Steuer-Backbone-Schnittstelle 200B erfolgen, die es der SI 110 jeweils ermöglichen, Kommunikationen mit den anderen Komponenten 160 des automobilen SoC 104 zu initiieren. Alternativ kann diese Kommunikation auch über die zweite Steuer-Backbone-Schnittstelle 200C, die sichere Inhaltsschnittstelle 200D, die Debug-Schnittstelle 200E oder die Testschnittstelle 200F erfolgen, die es der SI 110 jeweils ermöglichen, von den anderen Komponenten 160 des automobilen SoC 104 eingeleitete Kommunikationen zu empfangen. Wie bereits erwähnt, erfolgt die Kommunikation über die Fehlerschnittstelle(n) 172 (siehe 2) unabhängig davon, ob sich die SI 110 im Cocoon-Modus oder im Nicht-Isolations-Modus befindet.
Wann immer der Prozessor 140 das Bedürfnis hat, mit einer bestimmten der anderen Komponenten 160 des automobilen SoC 104 zu kommunizieren, bestimmt der Prozessor 140, dass die Kommunikation mit der betreffenden Komponente sicher ist, bevor er dies versucht. Um diese Feststellung zu treffen, kann der Prozessor 140 in Block 304 den Inhalt des SI-Fehleraggregators 142 überprüfen, der über die Fehlerschnittstelle(n) 172 (siehe 2) Fehlerinformationen von dem/den SoC-Fehleraggregator(en) 152 empfängt, der/die extern zur SI 110 ist/sind. Wie oben erwähnt, die Fehlerschnittstelle(n) 172 nicht logisch von dem/den SoC-Fehleraggregator(en) 152 isoliert, sondern jeweils durch den/die Spannungspegelwandler 240, der/die eine elektrische Isolierung zwischen den SI- und SoC-Spannungsdomänen bereitstellt/bereitstellen, durchgehen oder beinhalten.
Im Entscheidungsblock 306 bestimmt der Prozessor 140, ob im SI-Fehleraggregator 142 irgendwelche Fehler erkannt wurden. Die Entscheidung in Entscheidungsblock 306 lautet „JA“, wenn mindestens ein Fehler erkannt wurde, was durchschnittlich aufweist, dass ein Fehler, die für eine oder mehrere der anderen Komponenten 160 identifiziert wurde, dem SI-Fehleraggregator 142 von dem/den SoC-Fehleraggregator(en) 152 berichtet wurde. Der Prozessor 140 kann den Fehler unter Verwendung der Statusbits 242 innerhalb der SI-Fehleraggregators 142 erkennen. Die Statusbits 242 können als Indikator für den Zustand des automobilen SoC 104 dienen. Alternativ kann der SI-Fehleraggregator 142 den Prozessor 140 über den Fehler informieren, indem er eine Unterbrechung an den Prozessor 140 sendet. Andernfalls lautet die Entscheidung im Entscheidungsblock 306 „NEIN“, wenn keine Fehler erkannt werden.
Wenn die Entscheidung im Entscheidungsblock 306 im Block 308 „JA“ lautet, kann der Prozessor 140 eine oder mehrere Korrekturmaßnahmen ergreifen. Die Korrekturmaßnahme(n) kann/können dabei helfen, das Fahrzeug in einen sicheren Zustand zu bringen. Als nicht einschränkende Beispiele können solche Korrekturmaßnahmen das Anwenden der Bremsen des Fahrzeugs, das Reduzieren der Fahrzeuggeschwindigkeit, das Führen des Fahrzeugs zum Seitenstreifen der Straße und dergleichen beinhalten. Dann kann der Prozessor 140 zu Block 304 zurückkehren.
Wenn die Entscheidung im Entscheidungsblock 306 „NEIN“ lautet, entsperrt der Prozessor 140 in Block 310 den Verriegelungsmechanismus der logischen Isolationssteuerung 220 einer bestimmten der mit der bestimmten Komponente verbundenen Schnittstelle(n) 200, wenn der Verriegelungsmechanismus der bestimmten Schnittstelle gesperrt war. Mit anderen Worten, der Prozessor 140 kann bestimmen, dass der Zugang auf die bestimmte Komponente des automobilen SoC 104 über die bestimmte Schnittstelle sicher ist, wenn der SI-Fehleraggregator 142 keine Fehler speichert. Somit entsperrt der Prozessor 140 die bestimmte Schnittstelle in Block 310.
In Block 312 kann der Prozessor 140 dann über die entsperrte Schnittstelle Nachrichten an die bestimmte Komponente senden oder von ihr empfangen, wodurch automatisch der Zugangs-Timer 222 der bestimmten Schnittstelle gestartet wird. Wenn die bestimmte Schnittstelle entsperrt ist, kann der Prozessor 140 einen oder mehrere stark geordnete Zugänge (einen nach dem anderen) auf den automobilen SoC 104 einleiten. Der Zugangs-Timer 222 startet automatisch für jeden Zugang. So kann der Zugangs-Timer 222 mit dem Rückwärtszählen beginnen, sobald ein bestimmter Zugang durch den Prozessor 140 eingeleitet wird.
Im Entscheidungsblock 314 bestimmt der Prozessor 140, ob ein Timeout aufgetreten ist. Die Entscheidung in Entscheidungsblock 314 lautet „JA“, wenn der Zugangs-Timer 222 anzeigt, dass mehr als die erste vorherbestimmte Zeitdauer verstrichen ist und keine Antwort von der betreffenden Komponente empfangen wurde. Andernfalls lautet die Entscheidung im Entscheidungsblock 314 „NEIN“, wenn eine Antwort von der bestimmten Komponente empfangen wird, bevor der Zugangs-Timer 222 anzeigt, dass mehr als die erste vorbestimmte Zeitdauer verstrichen ist.
Wenn die Entscheidung im Entscheidungsblock 314 „JA“ ist, zeigt der Prozessor 140 im Block 316 an, dass ein Sicherheitsfehler aufgetreten ist. Dann sperrt der Prozessor 140 n Block 318 den Verriegelungsmechanismus der logischen Isolationssteuerung 220 der bestimmten Schnittstelle, sperrt gegebenenfalls den Verriegelungsmechanismus der logischen Isolationssteuerung 220 irgendeiner der anderen Schnittstelle(n), die entsperrt ist/sind, und ergreift gegebenenfalls eine oder mehrere Maßnahmen, die so konfiguriert sind, dass die Automobil-Plattform 100 wieder in einen sicheren Zustand versetzt wird.
Wenn andererseits die Entscheidung im Entscheidungsblock 314 im Block 320 „NEIN“ ist, schließt der Prozessor 140 die Kommunikation ab. Der Zugangs-Timer 222 wird automatisch zurückgesetzt. Dann sperrt der Prozessor 140 in Block 318 den Verriegelungsmechanismus der bestimmten Schnittstelle. So stellt das Verfahren 300 sicher, dass die Schnittstelle(n) 200 immer dann gesperrt bleibt (bleiben), wenn der Prozessor 140 nicht auf eine der anderen Komponenten 160 des automobilen SoC 104 zugreift. Das Verfahren 300 endet dann.
Die SI 110 kann den Zugang auf den gemeinsam genutzten nichtflüchtigen Speicher 128 vermeiden, indem er die Anweisungen 149 (z. B. kritische Anweisungen, die das System in einen sicheren Zustand bringen) aus dem gemeinsam genutzten nichtflüchtigen Speicher 128 in seinen internen flüchtigen Speicher 146 kopiert, wenn der automobile SoC 104 hochgefahren wird. Der Prozessor 140 kann die Anweisungen 149 authentifizieren und validieren, bevor die SI 110 in einen Missionsmodus eintritt, der den Fahrzeugfahrzyklus ermöglicht. Die SI 110 kann gleichzeitig im Missionsmodus und entweder im Cocoon-Modus oder im nicht-isolierten Modus betrieben werden. Die Anweisungen 149 verbleiben im flüchtigen Speicher 146, wodurch der Prozessor 140 den Zugang auf den gemeinsamen nichtflüchtigen Speicher 128 vermeiden kann. Nicht kritische Daten, z. B. Anwendungscode, Fusionsdaten usw., können aus dem gemeinsam genutzten flüchtigen Speicher 126 mit Hilfe einer internen direkten Speicherzugriffs („DMA“)-Engine 402 (siehe 4), die im SI 110 beinhaltet ist, bezogen werden. Die DMA-Engine 402 kann optional eine Komponente des Prozessors 140 sein. Ein Ausfall der DMA-Engine 402 wirkt sich nicht negativ auf den Prozessor 140 aus, da der Prozessor 140 selbst dann, wenn die DMA-Engine 402 ausfällt, während Daten aus dem gemeinsam genutzten flüchtigen Speicher 126 erhalten werden, mit der Ausführung der im flüchtigen Speicher 146 gespeicherten Anweisungen 149 fortfahren wird.
4 ist eine Veranschaulichung der Fehlerschnittstelle(n) 172, gemäß einiger Ausführungsformen der vorliegenden Offenbarung. Unter Bezugnahme auf 4 können den Logikblöcken LB(1) - LB(N) des automobilen SoC 104 jeweils erste Fehleraggregatoren 260-1 bis 260-N zugeordnet sein. Die ersten Fehleraggregatoren 260-1 bis 260-N aggregieren Fehler, die jeweils von den Logikblöcken LB(1) bis LB(N) erzeugt werden, und übertragen erste aggregierte Fehlersignale an die Hilfssicherheitseinheit 122 des automobilen SoC 104. Die Hilfssicherheitseinheit 122 implementiert den/die zweite(n) SoC-Fehleraggregator(en) 152, der/die das/die erste(n) aggregierte(n) Fehlersignal(e), das/die von den ersten Fehleraggregatoren 260-1 bis 260-N empfangen wurde(n), aggregiert(aggregiert) und eines oder mehrere zweite aggregierte Fehlersignale an die optionale externe Steuereinheit 106 (siehe 1), falls vorhanden, überträgt(sendet). Wenn die optionale externe Steuerungseinheit 106 durch das (die) zweite(n) aggregierte(n) Fehlersignal(e) über einen Fehler benachrichtigt wird, kann die optionale externe Steuerungseinheit 106 eine oder mehrere Maßnahmen aus einer Reihe von möglichen Maßnahmen ergreifen. Zuerst kann die optionale externe Steuereinheit 106 den Fehler löschen. Zweitens kann die optionale externe Steuereinheit 106 eine Korrekturmaßnahme ergreifen. Drittens kann die optionale externe Steuereinheit 106 ein externes System (z. B. einen oder mehrere externe Mikrocontroller, einen oder mehrere externe Agenten und dergleichen) benachrichtigen. Aber wie oben erwähnt, kann in einigen Ausführungsformen die optionale externe Steuereinheit 106 weggelassen werden.
1, obwohl die SI 110, wie oben beschrieben, von den anderen Komponenten 160 des automobilen SoC 104 isoliert ist, muss zumindest eine gewisse Kommunikation zwischen der SI 110 und den anderen Komponenten 160 des automobilen SoC 104 ermöglicht werden. Insbesondere müssen Fehler, die in den Logikblöcken LB(1) bis LB(N) des automobilen SoC 104 auftreten, der SI 110 über die Fehlerschnittstelle(n) 172 mitgeteilt werden. Eine Methode zur Bereitstellung einer solchen Kommunikation bestünde darin, dass die ersten Fehleraggregatoren 260-1 bis 260-N (siehe 4) die ersten aggregierten Fehlersignale direkt an die SI 110 senden. Dies erfordert, dass die Fehlerschnittstelle(n) 172 eine separate Übertragungsleitung oder einen Signalleiter zwischen der SI 110 und jedem der ersten Fehleraggregatoren 260-1 bis 260-N beinhalten, was durch die Isolierung der SI 110 von den anderen Komponenten 160 des automobilen SoC 104 verkompliziert wird. Unter Bezugnahme auf FIG. Wie in 2 gezeigt, müssten der (die) Spannungspegelwandler 240 einen separaten Spannungspegelumsetzer für jeden Signalleiter beinhalten. Ferner gilt: Je größer die Anzahl der Signalleiter zwischen der SI 110 und den anderen Komponenten 160 des automobilen SoC 104 ist, desto anfälliger ist die SI 110 für Störungen, die vom automobilen SoC 104 ausgehen.
Stattdessen kann jeder der SoC-Fehleraggregatoren 152 über drei Signalleiter mit der SI 110 verbunden sein (siehe 4): (1) einen korrigierten Fehlersignalleiter 410; (2) einen unkorrigierten Fehlersignalleiter 412; und (3) einen SoC-Fehleraggregator-Signalleiter 414. Diese Anordnung kann es der (den) Fehlerschnittstelle(n) 172 ermöglichen, Fehler von den Logikblöcken LB(1) bis LB(N) an die SI 110 zu berichten, ohne dass die Fehlerschnittstelle(n) 172 so viele Leiter einschließt (einschließen), dass die Leiter elektrische Interferenzen verursachen, und ohne dass die Fehlerschnittstelle(n) 172 so groß wird (werden), dass sie eine Überlastung des automobilen SoC 104 und/oder der SI 110 verursachen. Die Signalleiter 410, 412 und 414 können die Statusbits „BT1“, „BT2“ und „BT3“ setzen, von denen jedes, nachdem es gesetzt wurde, anschließend vom Prozessor 140 wieder gelöscht werden kann.
Die Mailbox(en) 156 kann/können mit dem Unterbrechungscontroller 141 der SI 110 durch einen Mailbox-Unterbrechungssignalleiter416 verbunden sein. Die Signalleiter 410-416 können jeweils als Draht, Signalleitung oder ähnliches ausgeführt sein.
5A ist ein Flussdiagramm, das das Verfahren 500 zum Schreiben von Daten in die SI 110 (siehe 1, 2, 4, 8 und 10) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Unter nunmehriger Bezugnahme auf 5A umfasst jeder Block des hier beschriebenen Verfahrens 500 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. So können beispielsweise verschiedene Funktionen von einem Prozessor (z. B. dem in 1 und 4 dargestellten Prozessor 150) ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Zumindest Abschnitte des Verfahrens 500 können zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 500 kann 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 500 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 500 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
Zur besseren Veranschaulichung wird das Verfahren 500 so beschrieben, dass es von einem bestimmten SoC-Fehleraggregator 152 durchgeführt wird (siehe 1, 2 und 4). Mit anderen Worten, das Verfahren 500 kann durch Hardware durchgeführt werden. Unter Bezugnahme auf 5A empfängt der bestimmte SoC-Fehleraggregator im ersten Block 502 erste aggregierte Fehlersignale von mindestens einem Abschnitt der ersten Fehleraggregatoren 260-1 bis 260-N (siehe 2 und 4).
In Block 506 aggregiert der jeweilige SoC-Fehleraggregator diejenigen der ersten aggregierten Fehlersignale, die einen Fehler identifizieren, der durch einen korrigierten Fehler verursacht wurde, zu einem korrigierten Fehlersignal. Dann, in Block 508, überträgt der jeweilige SoC-Fehleraggregator das korrigierte Fehlersignal über den korrigierten Fehlersignalleiter410 (siehe 4) an die SI 110 (siehe 1, 2, 4, 8 und 10). In Block 510 sendet der bestimmte SoC-Fehleraggregator für jeden korrigierten Fehler eine Unterbrechung an den Unterbrechungscontroller 154 (siehe 1 und 4), die die Unterbrechung(en) an den Prozessor 150 (siehe 1 und 4) der Hilfssicherheitseinheit 122 (siehe 1 und 4) weiterleitet. Jede Unterbrechung benachrichtigt den Prozessor 150 über den korrigierten Fehler, der der Unterbrechung zugeordnet ist.
In Block 512 startet der bestimmte SoC-Fehleraggregator einen Timer 420C für korrigierte Fehler (siehe 4) für einen ersten korrigierten Fehler, der in dem korrigierten Fehlersignal identifiziert wird.
Im Entscheidungsblock 514 bestimmt der jeweilige SoC-Fehleraggregator, ob der erste korrigierte Fehler aus dem jeweiligen SoC-Fehleraggregator gelöscht worden ist. Die Entscheidung in Entscheidungsblock 514 lautet „JA“, wenn der erste korrigierte Fehler gelöscht wurde, bevor der Timer 420C für korrigierte Fehler (siehe 4) anzeigte, dass mehr als eine zweite vorbestimmte Zeitdauer verstrichen ist. Andernfalls lautet die Entscheidung im Entscheidungsblock 514 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 514 „JA“ lautet, ergreift der bestimmte SoC-Fehleraggregator in Block 515 keine Maßnahme. Wenn die Entscheidung im Entscheidungsblock 514 hingegen „NEIN“ lautet, schreitet der bestimmte SoC-Fehleraggregator zum Entscheidungsblock 516 fort.
Im Entscheidungsblock 516 stellt der Prozessor 150 fest, ob der Timer für korrigierte Fehler 420C (siehe 4) anzeigt, dass mehr als die zweite vorbestimmte Zeitdauer verstrichen ist, was bedeutet, dass der Timer für korrigierte Fehler 420C abgelaufen oder abgelaufen ist. Die Entscheidung im Entscheidungsblock 516 ist „JA“, wenn die zweite vorbestimmte Zeitdauer verstrichen ist. Andernfalls lautet die Entscheidung im Entscheidungsblock 516 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 516 „JA“ lautet, schreitet der SoC-Fehleraggregator zu Block 518 fort. Andernfalls, wenn die Entscheidung im Entscheidungsblock 516 „NEIN“ lautet, kehrt der bestimmte SoC-Fehleraggregator zum Entscheidungsblock 514 zurück, um darauf zu warten, dass der erste korrigierte Fehler vom Prozessor 150 gelöscht wird. Der jeweilige SoC-Fehleraggregator überwacht also weiterhin, ob der erste korrigierte Fehler gelöscht wurde und ob der Timer 420C für korrigierte Fehler abgelaufen ist. Wenn der erste korrigierte Fehler gelöscht wird, bevor der Timer 420C für korrigierte Fehler abläuft, ergreift der jeweilige SoC-Fehleraggregator in Block 515 keine Maßnahme. Läuft hingegen der Timer 420C für korrigierte Fehler ab, bevor der erste korrigierte Fehler gelöscht wurde, geht der SoC-Fehleraggregator zum Block 518 fort. In Block 518 überträgt der jeweilige SoC-Fehleraggregator das SoC-Fehleraggregatorsignal über den SoC-Fehleraggregator-Signalleiter 414 (siehe 4) an die SI 110 (siehe 1, 2, 4, 8 und 10).
In Block 520 aggregiert der spezielle SoC-Fehleraggregator diejenigen der in Block 502 empfangenen ersten aggregierten Fehlersignale, die einen Fehler identifizieren, der durch einen nicht korrigierbaren Fehler verursacht wurde, zu einem unkorrigierten Fehlersignal. Dann, in Block 522, überträgt der jeweilige SoC-Fehleraggregator das unkorrigierte Fehlersignal an die SI 110 (siehe 1, 2, 4, 8 und 10) über den Leiter des nicht korrigierten Fehlersignals 412 (siehe 4). In Block 524 sendet der bestimmte SoC-Fehleraggregator eine Unterbrechung an den Unterbrechungscontroller 154 (siehe 1 und 4) für jeden nicht-korrigierten Fehler, der die Unterbrechung(en) an den Prozessor 150 (siehe 1 und 4) der Hilfssicherheitseinheit 122 weiterleitet (siehe 1 und 4). Jede Unterbrechung benachrichtigt den Prozessor 150 über den nicht-korrigierten Fehler, der der Unterbrechung zugeordnet ist.
In Block 526 startet der jeweilige SoC-Fehleraggregator einen unkorrigierten Fehler-Timer 420U (siehe 4) für einen ersten unkorrigierten Fehler, der in dem unkorrigierten Fehlersignal identifiziert wurde.
Im Entscheidungsblock 528 bestimmt der jeweilige SoC-Fehleraggregator, ob der erste unkorrigierte Fehler aus dem jeweiligen SoC-Fehleraggregator gelöscht worden ist. Die Entscheidung in Entscheidungsblock 528 lautet „JA“, wenn der erste unkorrigierte Fehler gelöscht wurde, bevor der Timer für unkorrigierte Fehler 420U (siehe 4) anzeigte, dass mehr als eine dritte vorherbestimmte Zeitdauer verstrichen ist. Andernfalls lautet die Entscheidung im Entscheidungsblock 528 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 528 „JA“ lautet, ergreift der bestimmte SoC-Fehleraggregator in Block 529 keine Maßnahme. Wenn die Entscheidung im Entscheidungsblock 528 „NEIN“ lautet, schreitet der SoC-Fehleraggregator zu Entscheidungsblock 530 fort.
Im Entscheidungsblock 530 bestimmt der Prozessor 150, ob der unkorrigierte Fehler-Timer 420U anzeigt, dass mehr als die dritte vorherbestimmte Zeitdauer verstrichen ist, was bedeutet, dass der unkorrigierte Fehler-Timer 420U (siehe 4) eine Zeitüberschreitung aufweist oder abgelaufen ist. Die Entscheidung im Entscheidungsblock 530 lautet „JA“, wenn die dritte vorherbestimmte Zeitdauer abgelaufen ist. Andernfalls lautet die Entscheidung im Entscheidungsblock 530 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 530 „JA“ lautet, schreitet der SoC-Fehleraggregator zu Block 532 fort. Andernfalls, wenn die Entscheidung im Entscheidungsblock 530 „NEIN“ lautet, kehrt der bestimmte SoC-Fehleraggregator zum Entscheidungsblock 528 zurück, um darauf zu warten, dass der erste unkorrigierte Fehler vom Prozessor 150 gelöscht wird. Der jeweilige SoC-Fehleraggregator überwacht also weiterhin, ob der erste unkorrigierte Fehler gelöscht wurde und ob der Timer 420U unkorrigierte Fehler abgelaufen ist. Wenn der erste unkorrigierte Fehler gelöscht wird, bevor der Timer 420U für unkorrigierte Fehler abläuft, ergreift der jeweilige SoC-Fehleraggregator in Block 529 keine Maßnahme. Läuft hingegen der Timer 420U für unkorrigierte Fehler ab, bevor der erste unkorrigierte Fehler gelöscht wurde, geht der SoC-Fehleraggregator zum Block 532 fort. In Block 532 überträgt der jeweilige SoC-Fehleraggregator das SoC-Fehleraggregator-Signal an die SI 110 (siehe 1, 2, 4, 8 und 10) über den SoC-Fehleraggregator-Signalleiter 414 (siehe 4). An diesem Punkt endet das Verfahren 500.
5B ist ein Flussdiagramm, das ein Verfahren 540 zeigt, das der Prozessor 150 (siehe 1 und 4) verwenden kann, um Unterbrechungen zu verarbeiten, die von dem/den SoC-Fehleraggregator(en) 152 (siehe 1, 2 und 4) empfangen werden, in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung. Unter nunmehriger Bezugnahme auf 5B beinhaltet jeder Block des hier beschriebenen Verfahrens 540 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. So können beispielsweise verschiedene Funktionen von einem Prozessor (z. B. dem Prozessor 150) ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Zumindest Abschnitte des Verfahrens 540 können zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 540 kann 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 540 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 540 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
Zur einfacheren Veranschaulichung wird das Verfahren 540 so beschrieben, wie es vom Prozessor 150 durchgeführt wird (siehe 1 und 4). Unter Bezugnahme auf 5B empfängt der Prozessor 150 im ersten Block 541 eine bestimmte Unterbrechung von einem bestimmten der SoC-Fehleraggregatoren 152. Dann, in Block 542, triagiert der Prozessor 150 einen oder mehrere Fehler, die in der bestimmten Unterbrechung identifiziert wurden, und kann eine oder mehrere korrigierende Maßnahmen ergreifen, um den/die Fehler zu beheben.
Wenn ein Problem auftritt, während der Prozessor 150 die Fehlerbehandlung durchführt und/oder die korrigierenden Maßnahmen ergreift, kann der Prozessor 150 möglicherweise nicht in der Lage sein, die Verarbeitung der jeweiligen Unterbrechung fortzusetzen. Wenn dies auftritt, ist die Entscheidung bei Entscheidungsblock 543 „JA“, und bei Block 544 ergreift der Prozessor 150 keine weitere Maßnahme in Bezug auf die bestimmte Unterbrechung. Wenn der Prozessor 150 hingegen in der Lage ist, die bestimmte Unterbrechung zu klassifizieren und gegebenenfalls die korrigierende(n) Maßnahme(n) zu ergreifen, lautet die Entscheidung im Entscheidungsblock 543 „NEIN“. Wenn die Entscheidung in Entscheidungsblock 543 „NEIN“ lautet, schreibt der Prozessor 150 in Block 545 Informationen in Relation zu der jeweiligen Unterbrechung in die Mailbox(en) 156, die von dem Prozessor 140 gelesen werden können. Als nächstes sendet der Prozessor 150 in Block 546 eine Mailbox-Unterbrechung an den Unterbrechungscontroller 141 über den Mailbox-Unterbrechungssignalleiter 416. Die Mailbox-Unterbrechung gibt einen Schweregrad des Fehlers an, der in der in Block 541 empfangenen Unterbrechung identifiziert wurde.
Im Entscheidungsblock 547 bestimmt der Prozessor 150 dann, ob der Prozessor 150 den Fehler, für den die bestimmte Unterbrechung erzeugt wurde, aus dem bestimmten SoC-Fehleraggregator löschen soll. Die Entscheidung im Entscheidungsblock 547 ist „JA“, wenn der Prozessor 150 entscheidet, den Fehler zu löschen. Andernfalls lautet die Entscheidung im Entscheidungsblock 547 „NEIN“. Die Entscheidung im Entscheidungsblock 547 kann „JA“ lauten, wenn die Korrekturmaßnahme(n) vom Prozessor 150 ergriffen wurden, den Fehler adressieren können oder der Fehler wurde durch einen korrigierten Fehler erzeugt (z. B. ein Fehler, der durch einen der Logikblöcke LB(1) - LB(N) korrigiert wurde). Als weiteres nicht einschränkendes Beispiel kann die Entscheidung im Entscheidungsblock 547 „JA“ lauten, wenn der Prozessor 150 eine Mailboxunterbrechung vom Prozessor 140 empfängt, die anzeigt, dass der Prozessor 140 den Fehler gelöscht hat. Wenn die Entscheidung im Entscheidungsblock 547 „NEIN“ lautet, ergreift der Prozessor 150 im Block 548 keine weiteren Maßnahmen in Bezug auf die bestimmte Unterbrechung. Wenn die Entscheidung im Entscheidungsblock 547 hingegen „JA“ lautet, löscht der Prozessor 150 in Block 549 den Fehler aus dem jeweiligen SoC-Fehleraggregator. Der Prozessor 150 kann den Prozessor 140 benachrichtigen, dass der Fehler aus dem jeweiligen SoC-Fehleraggregator gelöscht wurde. Das Verfahren 540 endet dann.
5C ist ein Ablaufdiagramm, das ein Verfahren 550 zeigt, das die SI 110 (siehe 1, 2, 4, 8 und 10) gemäß einigen Ausführungsformen der vorliegenden Offenbarung die korrigierten und unkorrigierten Fehlersignale verarbeiten kann. Unter nunmehriger Bezugnahme auf 5C beinhaltet jeder Block des hier beschriebenen Verfahrens 550 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen von einem Prozessor (z. B. dem in 1, 2 und 4 veranschaulichten Prozessor 140) ausgeführt werden, der darin gespeicherte Anweisungen (z. B. die in 1, 2 und 4 veranschaulichten Anweisungen 149) ausführt Speicher (z. B. der in den 1, 2 und 4 dargestellte flüchtige Speicher 146). Zumindest Abschnitte des Verfahrens 550 können zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 550 kann 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 550 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 550 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
Der Einfachheit halber wird das Verfahren 550 so beschrieben, dass es vom SI-Fehleraggregator 142 (siehe 1, 2 und 4) und dem Prozessor 140 (siehe 1, 2 und 4) durchgeführt wird. Unter Bezugnahme auf 5C empfängt der SI-Fehleraggregator 142 der SI 110 (siehe 1, 2, 4, 8 und 10) im ersten Block 552 das korrigierte Fehlersignal, das das Statusbit „BT1“ setzt und/oder das unkorrigierte Fehlersignal, das das Statusbit „BT2“ setzt. Wenn der SI-Fehleraggregator 142 das korrigierte Fehlersignal auf dem Leiter 410 für das korrigierte Fehlersignal empfängt, sendet der SI-Fehleraggregator 142 in Block 554 eine Unterbrechung an den Unterbrechungscontroller 141 (siehe 1, 2 und 4) des Prozessors 140. Diese Unterbrechung informiert den Prozessor 140 über den/die korrigierten Fehler.
Im Entscheidungsblock 556 bestimmt der Prozessor 140 (siehe 1, 2 und 4), ob eine Mailboxunterbrechung vom Prozessor 150 (siehe 1 und 4) über den Mailboxunterbrechungssignalleiter 416 empfangen worden ist. Wenn die Mailbox-Unterbrechung empfangen wird, zeigt die Mailbox-Unterbrechung den Schweregrad des korrigierten Fehlers an. Die Entscheidung im Entscheidungsblock 556 ist „JA“, wenn der Prozessor 140 die Mailboxunterbrechung empfangen hat. Andernfalls lautet die Entscheidung im Entscheidungsblock 556 „NEIN“. Wenn die Entscheidung in Entscheidungsblock 556 „NEIN“ lautet, wartet der Prozessor 140 in Block 558 darauf, entweder die Mailboxunterbrechung oder das SoC-Fehleraggregatorsignal zu empfangen. Wenn die Entscheidung im Entscheidungsblock 556 „JA“ lautet, geht der Prozessor 140 zum Entscheidungsblock 560 über.
Im Entscheidungsblock 560 entscheidet der Prozessor 140 (siehe 1, 2 und 4), ob die Mailbox(en) 156 gelesen werden sollen. Diese Entscheidung kann zumindest teilweise auf dem Schweregrad des korrigierten Fehlers basieren, der dem Prozessor 140 durch die Mailbox-Unterbrechung mitgeteilt wird. Beispielsweise kann der Prozessor 140 entscheiden, die Mailbox(en) 156 nicht zu lesen, wenn der Schweregrad des korrigierten Fehlers bei oder über einem Schwellenwert (z. B. 7) liegt, und kann entscheiden, die Mailbox(en) 156 zu lesen, wenn der Schweregrad des korrigierten Fehlers unter dem Schwellenwert liegt. Wenn die Entscheidung im Entscheidungsblock 560 „JA“ lautet, liest der Prozessor 140 im Block 562 die Mailbox(en) 156. Dann rückt der Prozessor 140 zu Block 564 vor, wo der Prozessor 140 den korrigierten Fehler löscht, beispielsweise durch Zurücksetzen des Statusbits „BT1“. Wenn die Entscheidung im Entscheidungsblock 560 „NEIN“ ist, rückt der Prozessor 140 zu Block 564 vor und löscht den korrigierten Fehler, indem er zum Beispiel das Statusbit „BT1“ zurücksetzt. Der Prozessor 140 kann auf die Benachrichtigung des Prozessors 150 warten, dass der Fehler, der dem korrigierten Fehler entspricht, aus dem jeweiligen SoC-Fehleraggregator gelöscht wurde, bevor der Prozessor 140 den korrigierten Fehler aus dem SI-Fehleraggregator 142 löscht. Da der Fehler jedoch korrigiert wurde, kann der Prozessor 140 in einigen Ausführungsformen den korrigierten Fehler einfach löschen, ohne zuerst eine solche Benachrichtigung zu erhalten.
Wenn der SI-Fehleraggregator 142 das unkorrigierte Fehlersignal auf dem Leiter 412 für das unkorrigierte Fehlersignal empfängt, sendet der SI-Fehleraggregator 142 in Block 566 eine Unterbrechung an den Unterbrechungscontroller 141 (siehe 1, 2, und 4) des Prozessors 140. Diese Unterbrechung informiert den Prozessor 140 über den/die unkorrigierten Fehler.
Im Entscheidungsblock 568 entscheidet der Prozessor 140 (siehe 1, 2 und 4), ob eine Mailboxunterbrechung vom Prozessor 150 (siehe 1 und 4) über den Mailboxunterbrechungssignalleiter 416 empfangen wurde. Wenn die Mailbox-Unterbrechung empfangen wird, zeigt die Mailbox-Unterbrechung den Schweregrad des unkorrigierten Fehlers an. Die Entscheidung im Entscheidungsblock 568 lautet „JA“, wenn der Prozessor 140 die Mailboxunterbrechung empfangen hat. Andernfalls lautet die Entscheidung im Entscheidungsblock 568 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 568 „NEIN“ lautet, wartet der Prozessor 140 in Block 558 darauf, entweder die Mailboxunterbrechung oder das SoC-Fehleraggregatorsignal zu empfangen. Wenn die Entscheidung im Entscheidungsblock 568 „JA“ lautet, schreitet der Prozessor 140 zum Entscheidungsblock 570 fort.
Im Entscheidungsblock 570 entscheidet der Prozessor 140 (siehe 1, 2 und 4), ob die Mailbox(en) 156 gelesen werden sollen. Diese Entscheidung kann zumindest teilweise auf dem Schweregrad des nicht korrigierten Fehlers basieren. Zum Beispiel kann der Prozessor 140 entscheiden, die Mailbox(en) 156 nicht zu lesen, wenn der Schweregrad des/der unkorrigierten Fehlers bei oder über dem Schwellenwert (z. B. 7) liegt, und kann entscheiden, die Mailbox(en) 156 zu lesen, wenn der Schweregrad des korrigierten Fehlers unterhalb des Schwellenwerts liegt. Wenn die Entscheidung im Entscheidungsblock 570 „JA“ lautet, liest der Prozessor 140 im Block 572 die Mailbox(en) 156. Dann rückt der Prozessor 140 zu Entscheidungsblock 573 vor. Wenn die Entscheidung im Entscheidungsblock 570 „NEIN“ lautet, rückt der Prozessor 140 zu Block 573 vor.
Im Entscheidungsblock 573 entscheidet der Prozessor 140, ob er eine oder mehrere Korrekturmaßnahmen ergreifen soll. Wenn die Entscheidung im Entscheidungsblock 573 „JA“ ist, ergreift der Prozessor 140 im Block 574 die Korrekturmaßnahme(n), wie beispielsweise das Anwenden der Bremsen des Fahrzeugs. Dann schreitet der Prozessor 140 zum Entscheidungsblock 575 fort.
Wenn die Entscheidung im Entscheidungsblock 573 „NEIN“ lautet, schreitet der Prozessor 140 zum Entscheidungsblock 575 fort. Im Entscheidungsblock 575 entscheidet der Prozessor 140, ob das externe System 404 zu benachrichtigen ist. Wenn die Entscheidung im Entscheidungsblock 575 in Block 576 „JA“ lautet, benachrichtigt der Prozessor 140 das externe System 404 und rückt zu Block 578 vor. Wenn die Entscheidung im Entscheidungsblock 575 „NEIN“ lautet, schreitet der Prozessor 140 zum Block 578 fort.
In Block 578 sendet der Prozessor 140 eine Mailboxunterbrechung an die Mailbox(en) 156 und/oder löscht den unkorrigierten Fehler, zum Beispiel durch Rücksetzen des Statusbits „BT2“. Optional kann der Prozessor 140 Fehlerinformationen in die Mailbox(en) 156 schreiben. Der Prozessor 140 kann auf die Benachrichtigung des Prozessors 150 warten, dass der Fehler, der dem nicht korrigierten Fehler entspricht, aus dem jeweiligen SoC-Fehleraggregator gelöscht wurde, bevor der Prozessor 140 den nicht korrigierten Fehler aus dem SI-Fehleraggregator 142 löscht. Das Verfahren 550 endet dann. Die Mailboxunterbrechung wird vom Prozessor 150 empfangen und kann im Entscheidungsblock 547 (siehe 5B) verwendet werden, wenn entschieden wird, ob der Prozessor 150 den dem unkorrigierten Fehler entsprechenden Fehler löschen soll. Der Prozessor 150 kann optional die durch den Prozessor 140 in die Mailbox(en) 156 geschriebenen Fehlerinformationen lesen, bevor er diese Entscheidung trifft.
5D ist ein Ablaufdiagramm, das ein Verfahren 580 zeigt, das die SI 110 (siehe 1, 2, 4, 8 und 10) gemäß einigen Ausführungsformen der vorliegenden Offenbarung zur Verarbeitung des SoC-Fehleraggregatorsignals verwenden kann. Unter nunmehriger Bezugnahme auf 5D beinhaltet jeder Block des hier beschriebenen Verfahrens 580 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen von einem Prozessor (z. B. dem in 1, 2 und 4 veranschaulichten Prozessor 140) ausgeführt werden, der darin gespeicherte Anweisungen (z. B. die in 1, 2 und 4 veranschaulichten Anweisungen 149) ausführt Speicher (z. B. der in den 1, 2 und 4 dargestellte flüchtige Speicher 146). Zumindest Abschnitte des Verfahrens 580 können zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 580 kann 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 580 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 580 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
Zur besseren Veranschaulichung wird das Verfahren 580 so beschrieben, dass es vom SI-Fehleraggregator 142 (siehe 1, 2 und 4), dem Prozessor 140 (siehe 1, 2 und 4), und der SoC-Fehlerbehandlungsschaltung 422 durchgeführt wird (siehe 4). Die SoC-Fehlerbehandlungsschaltung 422 kann als eine Komponente der SI-Fehleraggregators 142 implementiert sein. Wie in 5D dargestellt, empfängt der SI-Fehleraggregator 142 (siehe 1, 2 und 4) im ersten Block 582 das SoC-Fehleraggregatorsignal, das das Statusbit „BT3“ setzt.
Wie durch einen Pfeil mit einer gestrichelten Linie in 5D kann, wenn der SI-Fehleraggregator 142 (siehe 1, 2 und 4) das SoC-Fehleraggregatorsignal empfängt, der SoC-Fehlerbehandlungsschaltkreis 422 (siehe 4) der SI 110 automatisch und automatisch zu Block 584 vorrücken und automatisch ein SoC-Fehlersignals einschließlich eines SoC-Fehlers an das externe System 404 (siehe 4) über die Verbindung 406 (siehe 4) senden. Alternativ dazu kann die SoC-Fehlerbehandlungsschaltung 422 zum Block 586 fortgeschritten sein und einen SoC-Fehler-Timer 424 starten (siehe 4). Der SoC-Fehler-Timer 424 kann eine Verzögerung zwischen dem Zeitpunkt, an dem das SoC-Fehleraggregatorsignal empfangen wurde, und der Benachrichtigung des externen Systems 404 einführen. Während der SoC-Fehler-Timer 424 läuft, kann der Prozessor 140 eine oder mehrere korrigierende Maßnahmen ergreifen. Wenn die korrigierende(n) Maßnahme(n) erfolgreich ist/sind, kann der Prozessor 140 den/die unkorrigierten Fehler löschen, indem er das Statusbit „BT2“ zurücksetzt, und den SoC-Fehleraggregatorfehler, indem er das Statusbit „BT3“ zurücksetzt. Das Löschen des SoC-Fehleraggregatorfehlers stoppt den SoC-Fehler-Timer 424. Der Prozessor 140 kann auf die Benachrichtigung des Prozessors 150 warten, dass der Fehler, der dem/n unkorrigierten Fehler(en) entspricht, aus dem jeweiligen SoC-Fehleraggregator gelöscht wurde/n, bevor der Prozessor 140 den/die unkorrigierten Fehler aus dem SI-Fehleraggregator 142 löscht.
Nachdem der SoC-Fehler-Timer 424 gestartet wurde, bestimmt die SoC-Fehlerbehandlungsschaltung 422 im Entscheidungsblock 588, ob der SoC-Fehler-Timer 424 anzeigt, dass mehr als eine vierte vorherbestimmte Zeitdauer verstrichen ist. Die Entscheidung im Entscheidungsblock 588 lautet „JA“, wenn der SoC-Fehler-Timer 424 anzeigt, dass mehr als die vierte vorherbestimmte Zeitdauer verstrichen ist und der SoC-Fehleraggregatorfehler nicht gelöscht wurde. Andererseits lautet die Entscheidung im Entscheidungsblock 588 „NEIN“, wenn der SoC-Fehleraggregatorfehler gelöscht wurde, bevor der SoC-Fehler-Timer 424 anzeigt, dass mehr als die vierte vorherbestimmte Zeitdauer verstrichen ist.
Wenn die Entscheidung im Entscheidungsblock 588 „NEIN“ lautet, wartet die SoC-Fehlerbehandlungsschaltung 422 im Block 590 darauf, dass der SoC-Fehler-Timer 424 anzeigt, dass mehr als die vierte vorherbestimmte Zeitdauer verstrichen ist. Andererseits, wenn die Entscheidung im Entscheidungsblock 588 „JA“ ist, überträgt die SoC-Fehlerbehandlungsschaltung 422 im Block 584 das SoC-Fehlersignal einschließlich des SoC-Fehlers über die Verbindung 406 (siehe 4) an das externe System 404 (siehe 4), was anzeigt, dass der erste unkorrigierte Fehler nicht gelöscht wurde und der SoC-Fehleraggregatorfehler geltend gemacht wurde. Der SoC-Fehler-Timer 424 wird automatisch angehalten und/oder zurückgesetzt, wenn der SoC-Fehler gesendet wird. Alternativ dazu kann die SoC-Fehlerbehandlungsschaltung 422 den SoC-Fehler-Timer 424 zurücksetzen oder der SoC-Fehler-Timer 424 kann einfach ablaufen, ohne dass die SoC-Fehlerbehandlungsschaltung 422 irgendeine Maßnahme ergreift.
Nachdem der SI-Fehleraggregator 142 (siehe 1, 2 und 4) das SoC-Fehleraggregatorsignal empfangen hat, kann der SI-Fehleraggregator 142 in Block 592 eine Unterbrechung an den Prozessor 140 senden. In Block 594 sortiert der Prozessor 140 den ersten unkorrigierten Fehler. Im Entscheidungsblock 595 entscheidet der Prozessor 140, ob er eine oder mehrere Korrekturmaßnahmen ergreifen soll. Die Entscheidung im Entscheidungsblock 595 ist „JA“, wenn der Prozessor 140 entscheidet, eine oder mehrere Korrekturmaßnahmen zu ergreifen. Andernfalls lautet die Entscheidung im Entscheidungsblock 595 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 595 „NEIN“ ist, rückt der Prozessor 140 zu Block 596 vor und ergreift keine Maßnahmen. Wenn andererseits die Entscheidung im Entscheidungsblock 595 im Block 597 „JA“ ist, ergreift der Prozessor 140 die Korrekturmaßnahme(n).
Dann, in Block 598, sendet der Prozessor 140 eine Mailboxunterbrechung an die Mailbox(en) 156 und/oder löscht den SoC-Fehleraggregatorfehler, zum Beispiel durch Zurücksetzen des Statusbits „BT3“, und den/die unkorrigierten Fehler durch Zurücksetzen des Statusbits „BT2“. Das Löschen des SoC-Fehleraggregatorfehlers stoppt den SoC-Fehler-Timer 424. Die Mailboxunterbrechung, die an die Mailbox(en) 156 gesendet wird, kann anzeigen, dass der unkorrigierte Fehler gelöscht wurde und/oder dass der Prozessor 140 die korrigierende(n) Maßnahme(n) in Block 597 durchgeführt hat. Optional kann der Prozessor 140 Fehlerinformationen in die Mailbox(en) 156 schreiben. Der Prozessor 140 kann auf die Benachrichtigung des Prozessors 150 warten, dass der/die dem/den unkorrigierten Fehler(n) entsprechende(n) Fehler aus dem jeweiligen SoC-Fehleraggregator gelöscht wurde(n), bevor der Prozessor 140 den SoC-Fehleraggregatorfehler und den/die unkorrigierten Fehler aus dem SI-Fehleraggregator 142 löscht. Das Verfahren 580 endet dann. Die Mailboxunterbrechung wird vom Prozessor 150 empfangen, der den Fehler, der dem unkorrigierten Fehler entspricht, löschen kann. Der Prozessor 150 kann gegebenenfalls die Fehlerinformationen lesen, die der Prozessor 140 in die Mailbox(en) 156 geschrieben hat, bevor er den Fehler löscht.
5A-5D, beinhaltet das automobile SoC 104 den Prozessor 150. In zumindest einigen Ausführungsformen kann der Prozessor 150 weggelassen werden. In solchen Ausführungsformen wird das Verfahren 540 nicht durchgeführt. Bei jedem Fehler erzeugt der jeweilige SoC-Fehleraggregator den SoC-Fehleraggregatorfehler (Blöcke 518 und 532) und sendet ihn an den SI-Fehleraggregator 142. Da der Prozessor 150 nicht vorhanden ist, werden die Mailbox-Unterbrechungen nicht an den Unterbrechungscontroller 141 übertragen, sodass der Prozessor 140 auf das SoC-Fehleraggregatorsignal wartet (Block 558 von 5C), bevor der Prozessor 140 handelt. Wenn dann der Fehler des SoC-Fehleraggregators empfangen wird (Block 582 von 5D), geht die Sl 110 zu den anderen Komponenten 160, um eine Triage (Block 594 von 5D) für jeden korrigierten und unkorrigierten Fehler durchzuführen, der in der Methode 550 empfangen wurde (siehe 5C). Wenn die Sichtung erfolgreich ist, ergreift der Prozessor 140 die Korrekturmaßnahme(n) (Block 597 von 5D). Wenn die Sichtung andererseits nicht erfolgreich ist, ergreift der Prozessor 140 keine Maßnahme (Block 596 von 5D), was bewirkt, dass die SoC-Fehlerbehandlungsschaltung 422 den SoC-Fehler (ohne Softwareeingriff), nachdem der SoC-Fehler-Timer 424 abläuft, sendet (Block 584 von 5D). Der SoC-Fehler benachrichtigt das externe System 404 (z. B. die optionale externe Steuereinheit 106, einen oder mehrere externe Mikrocontroller, einen oder mehrere externe Agenten und dergleichen), was es dem externen System 404 ermöglicht, die Automobil-Plattform 100 (siehe 1) zurückzugeben) in einen sicheren Zustand.
6A - 6C veranschaulichen beispielhafte Maßnahmen, die von der SI 110 ergriffen werden können, wenn die SI 110 über einen bestimmten Fehler durch mindestens eines von dem korrigierten Fehlersignal, dem unkorrigierten Fehlersignal oder dem SoC-Fehleraggregatorsignal benachrichtigt wird. 6A veranschaulicht ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor 140 empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit niedrigem Schweregrad (z. B. der Minimalwert) geltend gemacht wurde, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Zeilen 612A-618A in 6A stellen das unkorrigierte Fehlersignal, ein Mailboxunterbrechungssignal, das SoC-Fehleraggregationssignal und das SoC-Fehlersignal dar. Das unkorrigierte Fehlersignal, das Mailbox-Unterbrechungssignal, das SoC-Fehleraggregationssignal und das SoC-Fehlersignal werden mit einem durch eine Linie 610A dargestellten Taktsignal synchronisiert. Das durch die Linie 610A dargestellte Taktsignal wurde basierend auf dem zweiten (SI-)Taktgeber 114 (siehe FIG: 1) in der SI-Domäne erzeugt.
Die Linie 612A stellt das unkorrigierte Fehlersignal dar, das durch den unkorrigierten Fehlersignalleiter 412 (siehe 4) an den SI-Fehleraggregator 142 geleitet wird. Ein Abschnitt 622A der Linie 612A repräsentiert die Geltendmachung des unkorrigierten Fehlers. Nach Empfang des unkorrigierten Fehlersignals (z. B. Block 552 von 5C) sendet der SI-Fehleraggregator 142 eine Unterbrechung an den Prozessor 140 (z. B. Block 566 von 5C).
Dann, in 6A empfängt der Unterbrechungscontroller 141 eine Mailbox-Unterbrechung (Entscheidung im Entscheidungsblock 568 von 5C ist „JA“). Ein Abschnitt 626A der Linie 614A stellt die (vom Prozessor 150 gesendete) Mailboxunterbrechung dar, die den Schweregrad des unkorrigierten Fehlers anzeigt. Da die Mailboxunterbrechung anzeigt, dass der bestimmte Fehler einen niedrigen Schweregrad hat, entscheidet der Prozessor 140, auf die Mailbox(en) 156 zuzugreifen (z. B. Entscheidung im Entscheidungsblock 570 von 5C ist „JA“) und den Inhalt der Mailbox(en) 156 (z. B. Block 572 von 5C) zu lesen. Wenn die Mailbox(en) 156 Fehlerinformationen (die vom Prozessor 150 erstellt wurden) einschließen, die anzeigen, dass der bestimmte Fehler gelöscht wurde, löscht der Prozessor 140 den bestimmten Fehler im SI-Fehleraggregator 142 (z. B. Block 578 von 5C). Wenn dies geschieht, bevor der Timer 420U für korrigierte Fehler abläuft, melden der/die SoC-Fehleraggregator(en) 152 den SoC-Fehleraggregatorfehler nicht (z. B. Block 529 von 5A).
Wenn andererseits der Inhalt der Mailbox(en) 156 nicht anzeigt, dass der Prozessor 150 den bestimmten Fehler behoben hat, kann der Prozessor 140 entscheiden, eine oder mehrere Korrekturmaßnahmen zu ergreifen (z. B. Entscheidung in Entscheidungsblock 573 von 5C ist „JA“). Wenn die Korrekturmaßnahme(n) (z. B. in Block 574 von 5C durchgeführt) erfolgreich sind, kann der Prozessor 140 den Prozessor 150 benachrichtigen, den Fehler zu deaktivieren (oder den Fehler zu löschen). Zum Beispiel kann der Prozessor 140 eine Mailboxunterbrechung an den Prozessor 150 senden und/oder Fehlerinformationen in die Mailbox(en) 156 schreiben. Nachdem der Prozessor 150 diese Benachrichtigung empfangen und den Fehler zurückgenommen hat, teilt der Prozessor 150 dem Prozessor 140 mit, dass der Fehler zurückgenommen wurde (z. B. über das unkorrigierte Fehlersignal, eine Mailboxunterbrechung und/oder die in der/den Mailbox(en) 156 gespeicherten Fehlerinformationen). Nach Erhalt dieser Benachrichtigung kann der Prozessor 140 den Fehler löschen, z. B. durch Zurücksetzen des Statusbits „BT2“ (z. B. Block 578 von 5C). Ein Abschnitt 624A der Linie 612A stellt eine Deaktivierung des unkorrigierten Fehlers dar, nachdem der Prozessor 140 die Mailbox(en) 156 liest und eine oder mehrere Korrekturmaßnahmen durchführt. Der gekrümmte Pfeil 628A steht für eine Verzögerung zwischen dem Zeitpunkt, an dem der Prozessor 140 die Mailboxunterbrechung empfängt, und dem Zeitpunkt, an dem der Prozessor 140 den Fehler deaktiviert (oder den Fehler löscht).
Wenn die korrigierende(n) Maßnahme(n) erfolgreich war(en), kann der Prozessor 140 eine Mailboxunterbrechung an die Mailbox(en) 156 senden, die anzeigt, dass der Prozessor 140 den bestimmten Fehler gelöscht hat (z. B. Block 578 von 5C). Optional kann der Prozessor 140 Fehlerinformationen in die Mailbox(en) 156 schreiben. Der Prozessor 150 empfängt die Mailboxunterbrechung, bestimmt, dass der bestimmte Fehler vom Prozessor 140 korrigiert wurde (z. B. lautet die Entscheidung im Entscheidungsblock 547 „JA“), und löscht den bestimmten Fehler aus dem/den SoC-Fehleraggregator(en) 152 (z. B. Block 549 von 5B). Wenn dies geschieht, bevor der Timer 420U für unkorrigierte Fehler abläuft, melden der/die SoC-Fehleraggregator(en) 152 den SoC-Fehleraggregatorfehler nicht (z. B. Block 529 von 5A). Der/die SoC-Fehleraggregator(en) 152 überwacht/überwachen also den jeweiligen Fehler, um sicherzustellen, dass er von einem der Prozessoren 140 und 150 behandelt wurde, und wenn der jeweilige Fehler nicht gelöscht wurde, bevor der Timer für unkorrigierte Fehler 420U abgelaufen ist, benachrichtigt/benachrichtigen der/die SoC-Fehleraggregator(en) 152 die SoC-Fehlerbehandlungsschaltung 422. Wie bereits erwähnt, teilt der Prozessor 150, nachdem der Prozessor 150 den Fehler geltend gemacht hat, dem Prozessor 140 mit, dass der Fehler gelöscht wurde (z. B. über das unkorrigierte Fehlersignal, eine Mailboxunterbrechung und/oder in der/den Mailbox(en) 156 gespeicherte Fehlerinformationen), und der Prozessor 140 kann den Fehler im SI-Fehleraggregator 142 löschen.
Die Linie 616A stellt das SoC-Fehleraggregationssignal dar und veranschaulicht, dass der SoC-Fehleraggregationsfehler nicht geltend gemacht wurde. Der oder die unkorrigierte Fehler wurden somit gelöscht, bevor der Timer 420U für unkorrigierte Fehler abgelaufen ist.
Die Linie 618A stellt ein SoC-Fehlersignal dar, das über die Verbindung 406 an das externe System 404 (z. B. die optionale externe Steuereinheit 106, einen oder mehrere externe Mikrocontroller, einen oder mehrere externe Agenten und dergleichen) gesendet werden kann. Da der/die nicht korrigierte(n) Fehler gehandhabt wurde/n und der SoC-Fehleraggregationsfehler nicht geltend gemacht wurde, gibt die Linie 618A an, dass die SI 110 das externe System 404 nicht über den/die unkorrigierten Fehler benachrichtigt (z. B. ist die Entscheidung in Entscheidungsblock 575 „NEIN“).
6B veranschaulicht gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein beispielhaftes Signalzeitdiagramm für Signale, die von dem Prozessor 140 empfangen und gesendet werden, nachdem ein unkorrigierter Fehler mit hohem Schweregrad (z. B. der Maximalwert) festgestellt wurde. Die Linien 612B-618B von 6B stellen das unkorrigierte Fehlersignal, ein Mailboxunterbrechungssignal, das SoC-Fehleraggregations-Signal und das SoC-Fehlersignal dar. Das unkorrigierte Fehlersignal, das Mailbox-Unterbrechungssignal, das SoC-Fehleraggregationssignal und das SoC-Fehlersignal werden mit einem Taktsignal synchronisiert, das durch eine Linie 610B dargestellt wird. Das durch die Linie 610B dargestellte Taktsignal wurde basierend auf dem zweiten (SI-)Taktgeber 114 (siehe 1) in der SI-Domäne erzeugt.
Die Linie 612B repräsentiert das unkorrigierte Fehlersignal, das von dem unkorrigierten Fehlersignalleiter 412 (siehe 4) an die SI-Fehleraggregator 142 geleitet wird. Ein Abschnitt 622B der Linie 612B repräsentiert eine Behauptung eines unkorrigierten Fehlers. Nach Empfang des unkorrigierten Fehlersignals (z. B. Block 552 von 5C) sendet der SI-Fehleraggregator 142 eine Unterbrechung an den Prozessor 140 (z. B. Block 566 von 5C).
Dann, in 6B empfängt der Unterbrechungscontroller 141 die Mailbox-Unterbrechung (z. B. Entscheidung im Entscheidungsblock 568 von 5C ist „JA“). Ein Abschnitt 624B der Linie 614B stellt die Mailbox-Unterbrechung dar, die anzeigt, dass der erste unkorrigierte Fehler einen hohen Schweregrad (z. B. sieben) aufweist. Da die Mailbox-Unterbrechung anzeigt, dass der bestimmte Fehler einen hohen Schweregrad aufweist, entscheidet der Prozessor 140, nicht auf die Mailbox(en) 156 zuzugreifen (z. B. ist die Entscheidung im Entscheidungsblock 570 von 5C „NEIN“). Zum Beispiel kann der Prozessor 140 bestimmen, dass es zu riskant ist, auf die anderen Komponenten 160 des automobilen SoC 104 zuzugreifen und dass dies der SI 110 schaden könnte. 6B, entscheidet der Prozessor 140 auch, eine oder mehrere korrigierende Maßnahmen nicht zu ergreifen (z. B. Entscheidung im Entscheidungsblock 573 von 5C ist „NEIN“). 6B wird der unkorrigierte Fehler nicht deaktiviert, weil die SI 110 nicht in der Lage ist, eine oder mehrere korrigierende Maßnahmen durchzuführen.
Der Prozessor 140 entscheidet jedoch, das externe System 404 (siehe 4) durch Senden des SoC-Fehlers im SoC-Fehlersignal zu benachrichtigen (z. B. ist die Entscheidung im Entscheidungsblock 575 von 5C „JA“). Dann sendet der Prozessor 140 das SoC-Fehlersignal (z. B. Block 576 von 5C). Somit, in 6B, wenn der Schweregrad des Fehlers hoch ist (z. B. der Maximalwert), kann die SI 110 entscheiden, nicht auf das Automobil-SoC 104 zuzugreifen, keine Korrekturmaßnahmen zu ergreifen und stattdessen das externe System 404 zu benachrichtigen. Die Linie 618B stellt das SoC-Fehlersignal dar, das von der SI 110 an das externe System 404 gesendet wird, und ein Abschnitt 626B der Linie 618B stellt die Geltendmachung des SoC-Fehlers dar. Die Linie 616B stellt das SoC-Fehleraggregationssignal dar und gibt nicht an, dass ein SoC-Fehleraggregationsfehler noch geltend gemacht wurde. Daher hat die SI 110 erkannt, dass der unkorrigierte Fehler noch nicht behandelt wurde und beschlossen, das externe System 404 zu benachrichtigen, bevor der SoC-Fehleraggregationsfehler festgestellt wurde.
6C veranschaulicht gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel-Signalzeitdiagramm für Signale, die vom Prozessor 140 empfangen und gesendet werden, nachdem ein unkorrigierter Fehler (z. B. der Maximalwert) geltend gemacht wurde, der SI 110 jedoch die Mailboxunterbrechung nicht empfängt. Die Linien 612C-618C von 6C stellen das unkorrigierte Fehlersignal, das Mailboxunterbrechungssignal, das SoC-Fehleraggregationssignal und das SoC-Fehlersignal dar. Das unkorrigierte Fehlersignal, das Mailbox-Unterbrechungssignal, das SoC-Fehleraggregationssignal und das SoC-Fehlersignal werden mit einem Taktsignal synchronisiert, das durch eine Linie 610C dargestellt wird. Das durch die Linie 610C dargestellte Taktsignal wurde basierend auf dem zweiten (SI-)Taktgeber 114 (siehe 1) in der SI-Domäne erzeugt.
Die Linie 612C repräsentiert das unkorrigierte Fehlersignal, das von dem unkorrigierten Fehlersignalleiter 412 (siehe 4) an die SI-Fehleraggregator 142 geleitet wird. Ein Abschnitt 622C der Linie 612C steht für eine Geltendmachung eines unkorrigierten Fehlers. Nach Empfang des unkorrigierten Fehlersignals (z. B. Block 552 von 5C) sendet der SI-Fehleraggregator 142 eine Unterbrechung an den Prozessor 140 (z. B. Block 566 von 5C).
In 6C zeigt die Linie 614C nicht an, dass die Mailbox-Unterbrechung empfangen wurde. Somit empfängt der Unterbrechungscontroller 141 in diesem Beispiel die Mailbox-Unterbrechung nicht (z. B. ist die Entscheidung im Entscheidungsblock 568 von 5C „NEIN“). Dies kann z. B. der Fall sein, wenn der Prozessor 150 die Fehlerkorrektur nicht abgeschlossen hat (z. B. Block 542 von 5B), was dazu führt, dass der Prozessor 150 die Mailboxunterbrechung nicht sendet (z. B. Block 544 von 5B) (Entscheidung in Entscheidungsblock 543 von 5C ist „JA“). Daher wartet der Prozessor 140 darauf, entweder die Mailboxunterbrechung oder den SoC-Fehleraggregatorfehler zu empfangen, je nachdem, was zuerst eintritt (z. B. Block 558 von 5C).
Eine Linie 628C stellt die dritte vorbestimmte Zeitdauer dar und zeigt, dass der Timer 420U für unkorrigierte Fehler abgelaufen ist. Da weder der Prozessor 140 noch der Prozessor 150 in der Lage waren, den ersten unkorrigierten Fehler zu löschen, darf der Timer 420U für unkorrigierte Fehler ablaufen (z. B. ist die Entscheidung im Entscheidungsblock 530 von 5A „JA“), was einen bestimmten von den/die SoC-Fehleraggregator(en) 152 verursacht hat, die das unkorrigierte Fehlersignal an die SI 110 und die Unterbrechung an den Prozessor 150 gesendet haben, um das SoC-Fehleraggregatorsignal über den SoC-Fehleraggregator-Signalleiter 414 an den SI-Fehleraggregator 142 zu übertragen (z. B. in Block 532 von 5A). Der SI-Fehleraggregator 142 empfängt das SoC-Fehleraggregatorsignal (z. B. in Block 582 von 5D). Ein Abschnitt 624C der Linie 616C stellt den SI-Fehleraggregatorfehler dar, der von dem bestimmten SoC-Fehleraggregator an die SI 110 gesendet wird. Ein gekrümmter Pfeil 630C repräsentiert eine Verzögerung zwischen dem Empfang des unkorrigierten Fehlers durch die SI 110 und dem Empfang der SI-Fehleraggregatorfehlers durch die SI 110.
Nach Empfang der SI-Fehleraggregatorsignals (z. B. Block 582 von 5D) sendet der SI-Fehleraggregator 142 eine Unterbrechung an den Prozessor 140 (z. B. Block 592 von 5D). Dann kann der Prozessor 140 den ersten unkorrigierten Fehler selektieren (z. B. Block 594 von 5D) und entscheiden, ob Korrekturmaßnahmen ergriffen werden sollen. Wenn der Prozessor 140 nicht in der Lage ist, irgendwelche Korrekturmaßnahmen zu ergreifen (z. B. die Entscheidung in Entscheidungsblock 595 von 5D ist „NEIN“), sendet die SoC-Fehlerbehandlungsschaltung 422 das SoC-Fehlersignal an das externe System 404 (z. B. Block 584 von 5C). Ein Abschnitt 626C der Linie 612C stellt den SoC-Fehler dar, der an das externe System 404 gesendet wird. In Ausführungsformen, die den SoC-Fehler-Timer 424 verwenden, wird der SoC-Fehler gesendet, wenn der SoC-Fehler-Timer 424 abläuft. In 6C gibt eine Linie 632C an, dass mehr als die vierte vorbestimmte Zeitdauer verstrichen ist, was bedeutet, dass der SoC-Fehler-Timer 424 abgelaufen ist. Ein gekrümmter Pfeil 634C steht für eine Verzögerung zwischen dem Zeitpunkt, zu dem der SI-Fehleraggregatorfehler von der SI 110 empfangen wurde und dem Zeitpunkt, zu dem der SoC-Fehler von der SI 110 bestätigt wurde. Auf diese Weise benachrichtigt die Hardware in der SI 110 das externe System 404, wobei dieses versuchen wird, die Automobil-Plattform 100 in einen sicheren Zustand zu versetzen.
Unter Bezugnahme auf 2 teilen sich die SI 110 und die anderen Komponenten 160 des automobilen SoC 104 den flüchtigen Speicher 126. Jedoch arbeitet die SI 110 innerhalb eines ersten Levels der Risikoklassifizierung und die anderen Komponenten 160 des automobilen SoC 104 können innerhalb eines niedrigeren zweiten Levels der Risikoklassifizierung arbeiten. Beispielsweise kann die SI 110 bei ASIL-D arbeiten, aber die anderen Komponenten des automobilen SoC, einschließlich des flüchtigen Speichers 126 und eines Kommunikationspfads (z. B. Verbindung, Speichersteuerung und dergleichen) zwischen der SI 110 und dem flüchtigen Speicher 126, kann bei ASIL-B arbeiten.
Um es der SI 110 zu ermöglichen, den flüchtigen Speicher 126 mit den anderen Komponenten 160 des automobilen SoC 104 gemeinsam zu nutzen, wird eine separate dedizierte Speicherregion (als „Ausschnitt“ 250 bezeichnet) in dem flüchtigen Speicher 126 zur ausschließlichen Verwendung durch die SI 110 erstellt. Der Ausschnitt 250 ist möglicherweise für Speicherverwaltungssoftware (z. B. Rich-OS-Speicherverwaltungs-Rich-OS-Speicherverwaltungssoftware), die von dem Haupt-CPU-Komplex 120 (siehe 1) ausgeführt wird, nicht sichtbar. Der Ausschnitt 250 kann zur Zeit des Hochfahrens erstellt und konfiguriert werden und kann für einen gegebenen Zyklus des Hochfahrens der SI 110 zugeordnet bleiben. Beispielsweise kann die Größe des Ausschnitts 250 durch einen vom Benutzer bearbeitbaren Softwareparameter bestimmt werden, der von Software verwendet wird (z. B. durch den Haupt-CPU-Komplex 120 ausgeführt wird), um der Ausschnitt 250 zu konfigurieren. Der Ausschnitt 250 kann in einen ersten Unterabschnitt 252 (siehe 8) und einen zweiten Unterabschnitt 254 (siehe 8) unterteilt werden. Die SI 110 kann über einen Kommunikationspfad auf den Ausschnitt 250 zugreifen, der auf dem ersten Risikoklassifizierungs-Level arbeitet, und jeder Zugang auf den Ausschnitt 250 durch die SI 110 über den Kommunikationspfad kann Sicherheitserlaubnisprüfungen wie diesen unterzogen werden nachstehend beschrieben.
Die SI 110 beinhaltet einen Fehlererkennungsblock 272, der Hardware beinhaltet, die zwischen anderen Komponenten der SI 110 und des Ausschnitts 250 positioniert ist. Somit kann der Fehlererkennungsblock 272 als eine Komponente der flüchtigen Speicherschnittstelle 200A implementiert werden. Alternativ kann der Fehlererkennungsblock 272 zwischen dem Prozessor 140 und der flüchtigen Speicherschnittstelle 200A positioniert sein. In solchen Ausführungsformen können ein oder mehrere Signalleiter (z. B. ein Draht, eine Signalspur und dergleichen) den Fehlererkennungsblock 272 sowohl mit dem Prozessor 140 als auch mit der flüchtigen Speicherschnittstelle 200A verbinden.
Die Hardware des Fehlererkennungsblocks 272 kann einen Codeerzeugungs-Unterblock 273 (siehe 8) beinhalten. Der Codeerzeugungsunterblock 273 kann unter Verwendung einer Codeerzeugungsschaltung für eine zyklische Redundanzprüfung („CRC“) implementiert werden, der einen CRC-Code erzeugt. Alternativ kann der Fehlererkennungsblock 272 andere Typen von Codeerzeugungsschaltungen beinhalten, die unterschiedliche Typen von Fehlererkennungscodes erzeugen, wie z. B. einen Fehlerkorrekturcode („ECC“). Die Hardware des Fehlererkennungsblocks 272 bestimmt einen oder mehrere Fehlererkennungscodes (z. B. CRC-Codes) für Daten, die den Fehlererkennungsblock 272 durchlaufen. Beispielsweise kann der Fehlererkennungsblock 272 einen separaten Fehlererkennungscode für jedes Datenbyte bestimmen, das den Fehlererkennungsblock 272 durchläuft. Der Fehlererkennungscode kann basierend auf dem Byte und einer Datenadresse in dem Ausschnitt 250 berechnet werden, wo das Byte gespeichert werden soll. Zum Beispiel kann Gleichung 1 unten verwendet werden, um den Fehlererkennungscode für ein bestimmtes Datenbyte zu bestimmen, das in den Ausschnitt 250 geschrieben werden soll: ${crc_out}_{Byte x} = CRC (Byte - Andresse,Byte - Daten)$
In der obigen Gleichung 1 stellt die Variable „crc_out_{Byte x}“ den Fehlererkennungscode dar, der basierend auf dem Byte, dargestellt durch die Variable „Bytedaten“, und der Datenadresse, dargestellt durch die Variable „Byteadresse“, berechnet wird. In Gleichung 1 verwendet eine Funktion „CRC“ die Werte der Variablen „Bytedaten“ und „Byteadresse“ als Eingaben und gibt den Wert der Variablen „crc_out_{Byte x}“ aus. Die Ausgabe der Funktion „CRC“ kann zumindest teilweise durch den Codeerzeugungsunterblock 273 (siehe 8) berechnet werden, falls vorhanden.
Nachdem der Fehlererkennungscode erkannt wurde, bestimmt der Fehlererkennungsblock 272 (z. B. unter Verwendung eines Versatzes) eine Codeadresse für den Fehlererkennungscode. Zum Beispiel kann die nachstehende Gleichung 2 verwendet werden, um den Fehlererkennungscode für ein bestimmtes Byte der Daten zu bestimmen, die in dem Ausschnitt 250 geschrieben werden sollen. $crc_out_address = write_andress + fixed_offset$
In der obigen Gleichung 2 stellt die Variable „crc_out_address“ die Codeadresse dar, die basierend auf der Datenadresse des Bytes, die durch die Variable „write_address“ dargestellt wird, und einem Versatz, der durch die Variable „fixed_offset“ dargestellt wird, berechnet wird. Wie oben erwähnt, kann der Ausschnitt 250 in Unterabschnitte unterteilt werden, wobei der erste Unterabschnitt 252 (siehe 8) die Daten speichert und der zweite Unterabschnitt 254 (siehe 8) die Fehlererkennungscodes speichert. So kann sich die Datenadresse, dargestellt durch die Variable „Byte-Adresse“ in Gleichung 1 oben, im ersten Unterabschnitt 252 befinden und die Codeadresse, dargestellt durch die Variable „write_address“ in Gleichung 2 oben, im zweiten Unterabschnitt 254. In solchen Ausführungsformen der Wert der Variablen „fixed_offset“ kann gleich der Größe des ersten Unterabschnitts 252 des Ausschnitts 250 sein, um sicherzustellen, dass die Fehlererkennungscodes im zweiten Unterabschnitt 254 gespeichert werden. Auf diese Weise werden die Daten von den Codes für die Erkennung von Fehlern durch adressbasiertes Abtrennen getrennt, so dass sich ein Fehler, der in einem der beiden Unterabschnitte 252 und 254 auftritt, nicht auf den anderen auswirken kann.
Der Fehlererkennungsblock 272 führt eine Verzögerung (z. B. einige Taktzyklen) zwischen der Speicherung der Daten in der/den Datenadresse(n) und der Speicherung des Fehlererkennungscodes in der/den Codeadresse(n) ein. Diese Verzögerung verringert die Wahrscheinlichkeit, dass ein Ereignis (z. B. ein vorübergehendes Ereignis), das sich negativ auf die Daten auswirkt, auch den Fehlererkennungscode negativ beeinflusst. Mit anderen Worten: Die Verzögerung trägt dazu bei, Immunität gegen Fehler gemeinsamer Ursache und vorübergehende Fehler bereitzustellen, was zum Schutz vor Problemen wie Taktstörungen beiträgt. Der Fehlererkennungsblock 272 kann zwei oder mehr Datenbytes und ihre entsprechenden Fehlererkennungscodes puffern, bevor sie in dem Ausschnitt 250 gespeichert werden. Dann kann der Fehlererkennungsblock 272 die Datenbytes (z. B. 16 Bytes) im ersten Unterabschnitt 252 speichern, gefolgt von der Verzögerung. Als nächstes kann der Fehlererkennungsblock 272 die entsprechenden Codes für die Erkennung von Fehlern (z. B. 16 Bytes) in der zweiten Unterabschnitt 254 speichern.
Unter nunmehriger Bezugnahme auf 7 beinhaltet jeder Block des hier beschriebenen Verfahrens 700 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise kann das Verfahren 700 durch die Hardware des Fehlererkennungsblocks 272 durchgeführt werden (siehe 2, 8 und 10). Als weiteres, nicht einschränkendes Beispiel können eine oder mehrere Funktionen von einem Prozessor ausgeführt werden (z. B. der in 1, 2 und 4 veranschaulichte Prozessor 140), der Anweisungen (z. B. die in 1, 2 und 4 veranschaulichten Anweisungen 149) ausführt, die in einem Speicher (z. B. der flüchtige Speicher 146 in 1, 2 und 4 veranschaulicht) gespeichert sind. In solchen Ausführungsformen können zumindest Abschnitte des Verfahrens 700 auch als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 700 kann 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 für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 700 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
7 ist ein Flussdiagramm, das das Verfahren 700 zum Schreiben von Daten in den Ausschnitt 250 (siehe 2, 8 und 10) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Zur Vereinfachung der Darstellung wird das Verfahren 700 so beschrieben, dass es von dem Fehlererkennungsblock 272 durchgeführt wird (siehe 2, 8 und 10). Bevor das Verfahren 700 beginnt, leitet ein Initiator (z. B. der Prozessor 140, die DMA-Engine 402 oder dergleichen), der in der SI-Domäne arbeitet, eine erste Schreibanweisung einschließlich Daten und Datenadresse(n) an den Fehlererkennungsblock 272 weiter. Der Initiator kann Daten mit einer vorbestimmten Größe (z. B. 16 Byte) in den Ausschnitt 250 schreiben.
Unter Bezugnahme auf 7 empfängt der Fehlererkennungsblock 272 (siehe 2, 8 und 10) im ersten Block 702 die erste Schreibanweisung einschließlich der Daten und Datenadresse(n) von dem Initiator. In Block 704 wählt der Fehlererkennungsblock 272 einen Abschnitt der Daten und eine der diesem Abschnitt entsprechenden Datenadresse(n) aus. Als nicht einschränkendes Beispiel kann der Fehlererkennungsblock 272 ein Byte der Daten in Block 704 und die dem ausgewählten Byte entsprechende Datenadresse auswählen. In einigen Ausführungsformen kann die erste Schreibanweisung nur eine einzige Datenadresse (z. B. eine erste Adresse) beinhalten. Nachfolgende Datenadressen können basierend auf dieser einzelnen Adresse bestimmt werden (z. B. durch Addieren einer vorbestimmten Datengröße zu der einzelnen Datenadresse). Daher kann in einigen Ausführungsformen die Datenadresse in Block 704 für zumindest einige der Daten berechnet werden.
Dann bestimmt der Fehlererkennungsblock 272 in Block 706 einen Fehlererkennungscode für den Abschnitt der in Block 704 ausgewählten Daten (z. B. unter Verwendung der obigen Gleichung 1). Als Nächstes leitet der Fehlererkennungsblock 272 in Block 708 die erste Schreibanweisung einschließlich des Abschnitts der in Block 704 ausgewählten Daten und der entsprechenden Datenadresse an den ersten Unterabschnitt 252 (siehe 8 und 10) des Ausschnitts 250 weiter (siehe 2, 8 und 10). Gemäß der ersten Schreibanweisung speichert der Ausschnitt 250 den Abschnitt in der entsprechenden Datenadresse im ersten Unterabschnitt 252.
Im nächsten Block 710 bestimmt der Fehlererkennungsblock 272 (siehe 2, 8 und 10) eine Codeadresse für den im Block 706 bestimmten Fehlererkennungscode (z. B. unter Verwendung der obigen Gleichung 2). In Block 712 wartet der Fehlererkennungsblock 272 (z. B. einige Taktzyklen), um den Fehlererkennungscode an den ersten Unterabschnitt 252 (siehe 8 und 10) des Ausschnitts 250 (siehe 2, 8 und 10) zur Speicherung dabei in der Codeadresse zu senden. In Block 712 führt der Block 272 zur Fehlererkennung also eine Verzögerung zwischen der Speicherung der Daten in der Datenadresse und der Speicherung des Fehlererkennungscodes in der Codeadresse ein. Der Fehlererkennungsblock 272 kann einen Schreibverzögerungs-Timer (nicht gezeigt) einschließen, der bestimmt, wie lange der Fehlererkennungsblock 272 in Block 712 wartet. Somit kann der Fehlererkennungsblock 272 eine fünfte vorbestimmte Zeitdauer warten, bevor er den Fehlererkennungscode an den Ausschnitt 250 zur Speicherung in der Codeadresse sendet. Als nächstes leitet der Fehlererkennungsblock 272 in Block 714 eine zweite Schreibanweisung, die den in Block 706 bestimmten Fehlererkennungscode und die in Block 710 bestimmte Codeadresse beinhaltet, an den zweiten Unterabschnitt 254 (siehe 8 und 10) des Ausschnitts 250 (siehe 2, 8 und 10) weiter aus. Somit greift der Fehlererkennungsblock 272 zum Speichern der Daten zweimal auf den Ausschnitt 250 zu, jeweils einmal in den Blöcken 708 und 714. Gemäß der zweiten Schreibanweisung speichert der Ausschnitt 250 den Fehlererkennungscode in der Codeadresse im zweiten Unterabschnitt 254.
Dann bestimmt im Entscheidungsblock 716 der Fehlererkennungsblock 272 (siehe 2, 8 und 10), ob irgendwelche der Daten nicht gespeichert worden sind. Die Entscheidung im Entscheidungsblock 716 ist „JA“, wenn der Fehlererkennungsblock 272 feststellt, dass zumindest einige der Daten nicht gespeichert wurden. Andernfalls lautet die Entscheidung im Entscheidungsblock 516 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 716 „JA“ ist, kehrt der Fehlererkennungsblock 272 zu Block 704 zurück, um einen neuen Abschnitt der Daten auszuwählen. Wenn andererseits die Entscheidung im Entscheidungsblock 716 „NEIN“ ist, kehrt der Fehlererkennungsblock 272 zum Block 702 zurück, um neue Daten und neue Datenadresse(n) zu empfangen.
Wie bereits erwähnt, kann der Fehlererkennungsblock 272 zwei oder mehr Datenbytes und die entsprechenden Codes für die Fehlererkennung zwischenspeichern, bevor er sie in dem Ausschnitt 250 speichert. Beispielsweise können die Blöcke 706 - 714 jeweils für mehrere Datenblöcke (z. B. in Block 704 ausgewählt) durchgeführt werden. Als nicht einschränkendes Beispiel kann der Fehlererkennungsblock 272 Block 706 für zwei oder mehr Datenbytes ausführen, bevor er die erste Schreibanweisung an den Ausschnitt 250 in Block 708 zusammen mit den Datenbytes und ihren entsprechenden Datenadresse(n) sendet. Zum Beispiel kann der Block 272 zur Fehlererkennung die Datenbytes zusammen mit einer ersten Datenadresse an den ersten Unterabschnitt 252 senden. Der erste Unterabschnitt 252 kann die Datenbytes in aufeinanderfolgende Speicheradressen schreiben, beginnend mit der ersten Datenadresse. Dann kann der Fehlererkennungsblock 272 in Block 710 Codeadressen für die zwei oder mehr Fehlererkennungscodes bestimmen, die in Block 706 bestimmt wurden. In Block 712 führt der Fehlererkennungsblock 272 eine Verzögerung zwischen dem Schreiben der Datenbytes und dem Schreiben der Fehlererkennungscodes in den Ausschnitt 250 ein. Anschließend leitet der Fehlererkennungsblock 272 in Block 714 die zweiten Schreibanweisung, der die Fehlererkennungscodes und die Codeadressen einschließt, an den zweiten Unterabschnitt 254 weiter. Der zweite Unterabschnitt 254 schreibt die Codes zur Fehlererkennung in die Codeadressen. Je nach Implementierungsdetails kann die zweite Schreibanweisung nur eine erste Codeadresse einschließen und der zweite Unterabschnitt 254 kann die Codes zur Fehlererkennung in aufeinanderfolgende Speicheradressen schreiben, beginnend mit der ersten Codeadresse.
8 veranschaulicht ein Beispiel für den Fehlererkennungsblock 272, der das Verfahren 700 durchführt (siehe 7). Die SI 110 kann einen oder mehrere Initiatoren 800 einschließen, wie beispielsweise den Prozessor 140, die DMA-Engine 402 und dergleichen, die jeweils innerhalb der SI-Domäne einleiten. 8, schließt der/die Initiator(en) 800 einen Initiator 802 (z. B. den Prozessor 140) ein. Der Initiator 802 (z. B. der Prozessor 140) kann Daten mit einer vorherbestimmten Größe (z. B. 16 Byte) in dem Ausschnitt 250 einleiten. In dem in 8 sendet der Initiator 802 16 Datenbytes und eine erste Datenadresse an den Fehlererkennungsblock 272. Die Daten werden in 8 durch ein Array von 128 Bits mit der Bezeichnung „wdata_in[127:0]“ gespeichert oder dargestellt und die erste Datenadresse wird in 8 durch ein Array von 40 Bits mit der Bezeichnung „Address_0[39:0]“ gespeichert oder dargestellt. Abhängig von den Implementierungsdetails können die Daten jedoch andere Größen haben und 128 Bit werden als nicht einschränkendes Beispiel bereitgestellt. In ähnlicher Weise kann die erste Datenadresse andere Größen haben und 40 Bits werden als nicht einschränkendes Beispiel bereitgestellt. Das erste Byte der Daten kann in der ersten Datenadresse gespeichert werden, dann kann eine nächste Datenadresse für ein zweites Byte der Daten identifiziert werden, indem ein Byte zur ersten Datenadresse hinzugefügt wird, und so weiter. 8 zeigt, wie der Initiator 802 eine erste Schreibanweisung 804 in einem Signal 806 über eine Sicherheitsinselverbindung 808 an den Block zur Fehlererkennung 272 sendet. Wie oben erwähnt, beinhaltet die erste Schreibanweisung 804 die Daten und die erste Datenadresse. Die Sicherheitsinselverbindung 808 kann als Bus und dergleichen implementiert sein.
Die Sicherheitsinselverbindung 808 liefert die erste Schreibanweisung 804 an den Fehlererkennungsblock 272 (z. B. Block 702 von 7). In der dargestellten Ausführungsform liefert die Sicherheitsinselverbindung 808 die erste Schreibanweisung 804 in Signalen 810-0 bis 810-15, die jeweils eines der Bytes der Daten und die erste Datenadresse beinhalten. In dieser Ausführungsform erzeugt der Fehlererkennungsblock 272 einen Fehlererkennungscode für jedes Byte der Daten, und der erzeugte Fehlererkennungscode ist ein CRC-Code. Der Fehlererkennungsblock 272 kann mit der Verarbeitung der Bytes beginnen, wenn sie in den Signalen 810-0 bis 810-15 empfangen werden (z. B. Block 704 von 7).
Als nächstes bestimmt der Codeerzeugungs-Unterblock 273 einen Fehlererkennungscode für jedes Byte der Daten (z. B. Block 706 von 7). In 8 sind Signale, die die Fehlererkennungscodes tragen, und ein Signal 838, das Antworten von dem Ausschnitt 250 trägt, die sich auf die Fehlererkennungscodes beziehen, durch Pfeile mit gestrichelten Linien dargestellt. So empfängt der Codeerzeugungs-Unterblock 273 als Eingaben die Datenbytes in den Signalen 812-0 bis 812-15 und die entsprechenden Fehlererkennungscodes in den Signalen 814-0 bis 814-15. Die (Daten-)Signale 812-0 bis 812-15 werden zur Speicherung an den ersten Unterabschnitt 252 und die (Code-)Signale 814-0 bis 814-15 zur Speicherung an den zweiten Unterabschnitt 254 weitergeleitet.
Der Fehlererkennungsblock 272 sendet die Daten und die erste Datenadresse (z. B. in den Signalen 812-0 bis 812-15) an den ersten Unterabschnitt 252 des Ausschnitts 250 über die flüchtige Speicherschnittstelle 200A (siehe 2) zu einem ersten Zeitpunkt (z. B. in 8 identifiziert als „Time=T0“). Mit anderen Worten, der Fehlererkennungsblock 272 sendet die erste Schreibanweisung an den ersten Unterabschnitt 252 des Ausschnitts 250 (z. B. Block 708 von 7). Die flüchtige Speicherschnittstelle 200A übermittelt die erste Schreibanweisung an den Ausschnitt 250 über ein Daten-Backbone- und Speichersubsystem 826 des automobilen SoC 104 (siehe 1, 2 und 4). 8 wird die erste Schreibanweisung vom Block zur Fehlererkennung 272 in einem Signal 824 an den ersten Unterabschnitt 252 gesendet.
Der erste Unterabschnitt 252 schreibt die Daten in den Speicher, indem er das erste Byte (in 8 als „Data0“ dargestellt) an der ersten Datenadresse (in 8 als „Address_0“ dargestellt) speichert und die nachfolgenden Bytes an nachfolgende Datenadressen nach der ersten Datenadresse schreibt. Dieses Schreiben tritt zum ersten Mal auf, was in 8 als „Time=T0“ dargestellt ist. Dann sendet der erste Unterabschnitt 252 ein Antwortsignal 828 an den Initiator 802, das bestätigt, dass die Daten gespeichert worden sind. Das Antwortsignal 828 wird vom ersten Unterabschnitt 252 an das Daten-Backbone- und Speichersubsystem 826 gesendet, das das Antwortsignal 828 an die flüchtige Speicherschnittstelle 200A (siehe 2) weiterleitet. Wenn die flüchtige Speicherschnittstelle 200A entsperrt ist, leitet die flüchtige Speicherschnittstelle 200A das Antwortsignal 828 an einen ersten (Daten-)Puffer 820 weiter.
Der erste (Daten-)Puffer 820 ordnet „Datenschreibabschlussantworten“ neu, die in dem Antwortsignal 828 von dem Ausschnitt 250 empfangen werden. Beispielsweise kann der Fehlererkennungsblock 272 ein Paar von Schreibanweisungen A und B (z. B. in der ersten Schreibanweisung, der in Block 708 von 7 gesendet wird) an den Ausschnitt 250 senden, wobei die Schreibanweisung B durch den Fehlererkennungsblock 272 nach der Schreibanweisung A gesendet wird. Nachdem der Ausschnitt 250 die in den Schreibanweisungen A und B enthaltenen Daten geschrieben hat, sendet der Ausschnitt 250 erste und zweite Datenschreibabschlussantworten an den Fehlererkennungsblock 272. Aber die für die Schreibanweisung B empfangene zweite Datenschreibabschlussantwort kann am Fehlererkennungsblock 272 vor der ersten Datenschreibabschlussantwort für die Schreibanweisung A ankommen. Wenn dies auftritt, wird der erste (Daten-)Puffer 820 die zweite Datenschreibabschlussantwort speichern, auf die erste Datenschreibabschlussantwort warten, die erste Datenschreibabschlussantwort senden, sobald sie ankommt, und die zweite Datenschreibabschlussantwort nach der ersten Datenschreibabschlussantwort senden. Somit ordnet der erste (Daten-)Puffer 820 die Antworten zum Abschluss des Datenschreibens in einer erwarteten Reihenfolge im Antwortsignal 828 an.
Der erste (Daten-)Puffer 820 leitet das Antwortsignal 828 an die Sicherheitsinselverbindung 808 weiter, die das Antwortsignal 828 an den Initiator 802 weiterleitet. Zu diesem Zeitpunkt wurden in diesem Beispiel die Daten (z. B. 16 Bytes) in einem ersten einzelnen Schreibvorgang in den ersten Unterabschnitt 252 geschrieben.
Der Fehlererkennungsblock 272 bestimmt auch eine erste Codeadresse basierend auf der ersten Datenadresse (z. B. Block 710 von 7). In 8 wird die erste Codeadresse berechnet, indem 16 Megabyte („MB“) zur ersten Datenadresse addiert werden. Abhängig von den Implementierungsdetails kann der Offset jedoch andere Größen haben und 16 MB sind beispielhaft angegeben. Ferner kann die Position der ersten Codeadresse unter Verwendung anderer Verfahren und/oder Berechnungen bestimmt werden.
Der Fehlererkennungsblock 272 wartet (z. B. Block 712 von 7), bis zum zweiten Mal (z. B. in 8 als identifiziert) „Time=T1“). Das erste und das zweite Mal sind unterschiedlich. Zum zweiten Mal sendet der Fehlererkennungsblock 272 die Fehlererkennungscodes und die erste Codeadresse über die flüchtige Speicherschnittstelle 200A (siehe 2) an den zweiten Unterabschnitt 254 des Ausschnitts 250. Mit anderen Worten: Der Block 272 zur Fehlererkennung sendet die zweite Schreibanweisung an den zweiten Unterabschnitt 254 des Ausschnitts 250 (z. B. Block 714 in 7). Die flüchtige Speicherschnittstelle 200A übermittelt die zweite Schreibanweisung über das Daten-Backbone- und Speicher-Subsystem 826 des automobilen SoC 104 an den Ausschnitt 250 (siehe 1, 2 und 4 veranschaulicht) gespeichert sind. 8 wird die zweite Schreibanweisung vom Block zur Fehlererkennung 272 in einem Signal 834 an den zweiten Unterabschnitt 254 gesendet.
Der zweite Unterabschnitt 254 schreibt die Fehlererkennungscodes in den Speicher, indem er den ersten Fehlererkennungscode (in 8 als „CRC0“ dargestellt) an der ersten Codeadresse (in 8 als „Adresse_1“ dargestellt) speichert und die nachfolgenden Fehlererkennungscodes an nachfolgende Codeadressen nach der ersten Codeadresse schreibt. Dann sendet die zweite Unterabschnitt 254 ein Antwortsignal 838 an den Initiator 802, das bestätigt, dass die Codes zur Fehlererkennung gespeichert wurden. Bei der in 8 gezeigten Ausführungsform, wird das Antwortsignal 838 durch den zweiten Unterabschnitt 254 an das Daten-Backbone- und Speichersubsystem 826 gesendet, das das Antwortsignal 838 an die flüchtige Speicherschnittstelle 200A (siehe 2) weiterleitet. Wenn die flüchtige Speicherschnittstelle 200A entsperrt ist, leitet die flüchtige Speicherschnittstelle 200A das Antwortsignal 838 an einen zweiten (Code-)Puffer 822 weiter. Der zweite (Code-)Puffer 822 ordnet „Code-Schreibabschluss-Antworten“ neu, die in dem Antwortsignal 838 von dem Ausschnitt 250 empfangen werden. Beispielsweise bestimmt der Fehlererkennungsblock 272 erste und zweite Fehlererkennungscodes für die Daten, die in den Schreibanweisungen A und B beinhaltet sind, und sendet die ersten und zweiten Fehlererkennungscodes an den Ausschnitt 250 (z. B. in die zweite Schreibanweisung). Nachdem der Ausschnitt 250 den ersten und den zweiten Fehlererkennungscode in den Speicher geschrieben hat, sendet der Ausschnitt 250 erste und zweite Code-Schreibabschluss-Antworten an den zweiten (Code-)Puffer 822. Es kann jedoch sein, dass die für den zweiten Fehlererkennungscode empfangene zweite Code-Schreibabschlussantwort vor der ersten Code-Schreibabschlussantwort für den ersten Fehlererkennungscode im Fehlererkennungsblock 272 ankommt. In diesem Fall speichert der zweite (Code-)Puffer 822 die zweite Code-Schreibabschluss-Antwort, wartet auf die erste Code-Schreibabschluss-Antwort, sendet die erste Code-Schreibabschluss-Antwort, sobald sie eintrifft, und sendet die zweite Code-Schreibabschluss-Antwort nach der ersten Code-Schreibabschluss-Antwort.
Der zweite (Code-)Puffer 822 kann das Antwortsignal 838 verwerfen. Alternativ kann der zweite (Code-)Puffer 822 das Antwortsignal 838 an die Sicherheitsinselverbindung 808 weiterleiten, die das Antwortsignal 838 an den Initiator 802 weiterleiten kann. Zu diesem Zeitpunkt wurden in diesem Beispiel die Codes zur Fehlererkennung (z. B. 16 Bytes) in einem zweiten einzelnen Schreibvorgang in den zweiten Unterabschnitt 254 geschrieben.
Die flüchtige Speicherschnittstelle 200A kann zwei parallele und optional dedizierte Schnittstellen beinhalten, die den Fehlererkennungsblock 272 mit dem flüchtigen Speicher 126 verbinden. Die Daten können über die erste Schnittstelle an die erste Datenadresse gesendet werden, und der/die Fehlererkennungscode(s) kann/können über die zweite Schnittstelle an die erste Codeadresse gesendet werden. In solchen Ausführungsformen kann der Fehlererkennungsblock 272 die erste Schreibanweisung, der die Daten und die erste Datenadresse (z. B. im Signal 824) einschließt, über die erste Schnittstelle an den ersten Unterabschnitt 252 senden, während der Fehlererkennungsblock 272 die zweite Schreibanweisung, der den/die Fehlererkennungscode(s) und die erste Codeadresse (z. B. im Signal 834) einschließt, über die zweite Schnittstelle an die zweite Unterabteilung 254 sendet. Ferner können das (Daten-)Antwortsignal 828 und das (Code-)Antwortsignal 838 gleichzeitig über die erste und zweite Schnittstelle an den ersten und zweiten Puffer 820 und 822 übertragen werden.
Wenn der Initiator 802 (z. B. der Prozessor 140) der Sl 110 die Daten von dem Ausschnitt 250 lesen möchte, empfängt die SI 110 sowohl die Daten als auch den/die Fehlererkennungscode(s) von dem Ausschnitt 250. Die Sl 110 führt eine Verzögerung zwischen dem Lesen der Daten von der/den Datenadresse(n) und dem Lesen des/der Codes zur Fehlererkennung von der/den Codeadresse(n) ein. Diese Verzögerung verringert die Wahrscheinlichkeit, dass ein Ereignis, das sich negativ auf die Daten auswirkt, sich auch negativ auf den Code für die Erkennung von Fehlern auswirkt. Die SI 110 leitet die gelesenen Daten durch den Fehlererkennungsblock 272, der einen Prüfcode für die gelesenen Daten bestimmt und den Fehlererkennungscode mit dem Prüfcode vergleicht. Dieser Vergleich kann durch eine Gleichung 3 unten dargestellt werden: $CRC_gen (Requested Adresse,abgerufene Daten) = = {crc_in}_{Byte x} (CRC_address)$
In Gleichung 3 ein Operator „==“ gibt an, ob ein Ausdruck links vom Operator steht „==“ ist gleich einem Ausdruck rechts vom Operator „==.“ Eine Variable „abgeholte Daten“ stellt mindestens einen Abschnitt (z. B. Byte x) der in Block 906 erhaltenen Daten dar, eine Variable „angeforderte Adresse“ stellt die Datenadresse dieses Abschnitts der Daten dar, und eine Variable „CRC_address“ stellt die Codeadresse dar, die basierend auf der Datenadresse des Abschnitts (z. B. Byte x) der Daten bestimmt wird. Eine Funktion „CRC_gen“ verwendet die Werte der Variablen „Fetched Data“ und „Requested address“ als Eingänge und die Funktion „CRC_gen“ gibt den Prüfcode für den Abschnitt (z. B. Byte x) aus. Die Funktion „CRC_gen“ kann mit der Funktion „CRC“ der obigen Gleichung 1 identisch sein. Die Ausgabe der Funktion „CRC_gen“ kann zumindest teilweise durch den Unterblock 273 zur Codeerzeugung berechnet werden (siehe 8), sofern vorhanden. Ein Ausdruck „crc_in_{Byte x}(CRC_address)„ stellt den Fehlererkennungscode dar, der aus der Codeadresse erhalten wird, die für den Abschnitt (z. B. Byte x) unter Verwendung seiner Datenadresse bestimmt wurde. Somit bestimmt die Gleichung 3, ob der Prüfcode gleich dem Fehlererkennungscode ist oder mit ihm übereinstimmt. Der Fehlererkennungsblock 272 kann einen Nichtübereinstimmungsfehler erzeugen, wenn der Prüfcode nicht mit dem Fehlererkennungscode übereinstimmt. Der Block 272 zur Fehlererkennung kann den Nichtübereinstimmungsfehler an den Initiator 802 und den SI-Fehleraggregator 142 senden, so dass der Fehler durch die Sicherheitssoftware, die durch die Anweisungen 149 implementiert und durch den Prozessor 140 ausgeführt wird, gelöscht werden kann.
Unter nunmehriger Bezugnahme auf 9 beinhaltet jeder Block des hier beschriebenen Verfahrens 900 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Das Verfahren 900 kann zum Beispiel von der Hardware des Blocks 272 für die Fehlererkennung durchgeführt werden (siehe 2, 8 und 10 veranschaulicht) gespeichert sind. Als weiteres, nicht einschränkendes Beispiel können eine oder mehrere Funktionen von einem Prozessor ausgeführt werden (z. B. der in 1, 2 und 4 veranschaulichte Prozessor 140), der Anweisungen (z. B. die in 1, 2 und 4 veranschaulichten Anweisungen 149) ausführt, die in einem Speicher (z. B. der flüchtige Speicher 146 in 1, 2 und 4 veranschaulicht) gespeichert sind. Zumindest Abschnitte des Verfahrens 900 können zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 900 kann 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 900 beispielhaft für die Automobil-Plattform 100 von 1 beschrieben. Das Verfahren 900 kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
9 ist ein Flussdiagramm, das das Verfahren 900 zum Lesen von Daten aus dem Ausschnitt 250 (siehe 2, 8 und 10) in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Zur besseren Veranschaulichung wird das Verfahren 900 so beschrieben, dass es vom Fehlererkennungsblock 272 durchgeführt wird (siehe 2, 8 und 10 veranschaulicht) gespeichert sind. Bevor das Verfahren 900 beginnt, leitet der Initiator 802 (siehe 8) eine erste Leseanweisung, die eine oder mehrere Datenadressen beinhaltet, an den Fehlererkennungsblock 272 weiter. Als nicht einschränkendes Beispiel kann die erste Leseanweisung nur eine erste Datenadresse beinhalten. Unter Bezugnahme auf 9 empfängt der Fehlererkennungsblock 272 im ersten Block 902 die erste Leseanweisung einschließlich der Datenadresse(n) von dem Initiator 802. In Block 904 leitet der Fehlererkennungsblock 272 die erste Leseanweisung an den ersten Unterabschnitt 252 weiter, der die an der/den Datenadresse(n) gespeicherten Daten anfordert. Wenn die erste Leseanweisung nur die erste Datenadresse enthielt, kann der erste Unterabschnitt 252 eine vorbestimmte Datenmenge (z. B. 16 Bytes) von aufeinanderfolgenden Speicheradressen beginnend bei der ersten Datenadresse lesen. In Block 906 empfängt der Fehlererkennungsblock 272 die Daten, die an der/den Datenadresse(n) von dem ersten Unterabschnitt 252 gespeichert sind.
In Block 908 bestimmt der Fehlererkennungsblock 272 dann die Codeadresse(n) für den/die Fehlererkennungscode(s), die den Daten entsprechen (z. B. unter Verwendung der obigen Gleichung 2). Als nicht einschränkendes Beispiel können die Codeadresse(n) zumindest teilweise basierend auf der (den) Datenadresse(n) bestimmt werden. Zum Beispiel kann gemäß der obigen Gleichung 2 jede der Codeadresse(n) berechnet werden, indem der Versatz (der Wert der Variablen „fixed_offset“) zu einer entsprechenden der Datenadresse(n) (dem Wert der Variablen „write_address“) addiert wird. Abhängig von den Implementierungsdetails kann der Fehlererkennungsblock 272 nur eine erste Codeadresse basierend auf der ersten Datenadresse identifizieren. Dann wartet in Block 910 der Fehlererkennungsblock 272 (z. B. einige Taktzyklen), um den/die Fehlererkennungscode(s) anzufordern, der/die an der/den in Block 908 bestimmten Codeadresse(n) gespeichert ist/sind. In Block 910 führt der Fehlererkennungsblock 272 demnach eine Verzögerung zwischen dem Lesen der Daten und dem Lesen des/der Fehlererkennungscodes von der/den Codeadresse(n) ein. Der Fehlererkennungsblock 272 kann einen Leseverzögerungs-Timer (nicht gezeigt) einschließen, der bestimmt, wie lange der Fehlererkennungsblock 272 in Block 910 wartet. Somit kann der Fehlererkennungsblock 272 eine sechste vorbestimmte Zeitdauer warten, bevor er den/die Fehlererkennungscode(s) von dem zweiten Unterabschnitt 254 anfordert.
Nach der Wartezeit sendet der Fehlererkennungsblock 272 im nächsten Block 912 eine zweite Leseanweisung an den zweiten Unterabschnitt 254, der die in Block 908 bestimmte(n) Codeadresse(n) einschließt und den/die an diesen Codeadresse(n) gespeicherten Fehlererkennungscode(s) anfordert. Um die Daten zu lesen, greift der Fehlererkennungsblock 272 also zweimal auf den Ausschnitt 250 zu, jeweils einmal in den Blöcken 904 und 912. Wenn die zweite Leseanweisung nur die erste Codeadresse einschließt, kann der zweite Unterabschnitt 254 eine vorherbestimmte Anzahl von Codes zur Fehlererkennung (z. B. 16 Bytes) aus aufeinanderfolgenden Speicheradressen, beginnend mit der ersten Codeadresse, lesen. In Block 914 empfängt der Fehlererkennungsblock 272 den/die an der/den Codeadresse(n) gespeicherten Fehlererkennungscode(s) von dem zweiten Unterabschnitt 254. In Block 916 bestimmt der Fehlererkennungsblock 272 einen Prüfcode für jeden der in Block 914 erhaltenen Fehlererkennungscodes (z. B. unter Verwendung der obigen Gleichung 1).
Im Entscheidungsblock 918 bestimmt der Fehlererkennungsblock 272 für jeden der Fehlererkennungscodes, ob der Fehlererkennungscode mit dem Prüfcode übereinstimmt, der dem Fehlererkennungscode entspricht (z. B. unter Verwendung der obigen Gleichung 3). Die Entscheidung im Entscheidungsblock 918 ist „JA“, wenn der Fehlererkennungscode mit seinem entsprechenden Prüfcode übereinstimmt. Andernfalls lautet die Entscheidung im Entscheidungsblock 918 „NEIN“. Wenn die Entscheidung im Entscheidungsblock 918 „JA“ ist, leitet der Fehlererkennungsblock 272 im Block 920 die dem Fehlererkennungscode entsprechenden Daten an den Initiator 802 weiter (siehe 8). Wenn die Entscheidung im Entscheidungsblock 918 „NEIN“ lautet, erzeugt der Fehlererkennungsblock 272 im Block 922 einen Nichtübereinstimmungsfehler und sendet ihn an den Initiator 802 und den SI-Fehleraggregator 142 (siehe 1, 2 und 4), so dass der Nichtübereinstimmungsfehler durch die Sicherheitssoftware gelöscht werden kann, die durch die Anweisungen 149 implementiert und vom Prozessor 140 ausgeführt wird. Optional kann der Fehlererkennungsblock 272 in Block 922 versuchen, die Nichtübereinstimmung zu korrigieren, wenn der Fehlererkennungscode (z. B. als ECC implementiert) Informationen (z. B. Bits) beinhaltet, die verwendet werden können, um die Daten wiederherzustellen. Wenn der Fehlererkennungsblock 272 in der Lage ist, den Fehler zu korrigieren, kann der Fehlererkennungsblock 272 das Erzeugen des Nichtübereinstimmungsfehlers in Block 922 weglassen. Nach Block 920 rückt der Fehlererkennungsblock 272 zu Block 920 vor und leitet die Daten an den Initiator 802 weiter. Das Verfahren 900 endet dann.
Der Fehlererkennungsblock 272 kann gleichzeitig zwei oder mehr Datenbytes und ihre entsprechenden Fehlererkennungscodes aus dem Ausschnitt 250 lesen. Beispielsweise können die Blöcke 904 - 914 jeweils für mehrere Datenblöcke durchgeführt werden. Als nicht einschränkendes Beispiel kann der Fehlererkennungsblock 272 in Block 904 die erste Leseanweisung an den ersten Unterabschnitt 252 senden, der zwei oder mehr Datenbytes von einer ersten Datenadresse anfordert. Der erste Unterabschnitt 252 kann die Datenbytes von aufeinanderfolgenden Speicheradressen beginnend mit der ersten Datenadresse lesen und die Datenbytes an den Fehlererkennungsblock 272 senden, den der Fehlererkennungsblock 272 in Block 906 empfängt. Dann kann der Fehlererkennungsblock 272 in Block 908 Codeadresse(n) auf der Grundlage der Datenadresse(n) bestimmen. Abhängig von den Implementierungsdetails kann der Fehlererkennungsblock 272 nur eine erste Codeadresse basierend auf der ersten Datenadresse identifizieren. Dann führt der Fehlererkennungsblock 272 in Block 910 eine Verzögerung zwischen dem Lesen der Datenbytes und dem Lesen der Fehlererkennungscodes aus dem Ausschnitt 250 ein. Als Nächstes kann der Fehlererkennungsblock 272 die Fehlererkennungscodes anfordern, die in dem Ausschnitt 250 für die in Block 906 erhaltenen Datenbytes gespeichert sind. Beispielsweise kann der Fehlererkennungsblock 272 die erste Codeadresse an den zweiten Unterabschnitt 254 senden. Der zweite Unterabschnitt 254 kann die Fehlererkennungscodes von aufeinanderfolgenden Speicheradressen, beginnend mit der ersten Codeadresse, lesen und die Fehlererkennungscodes an den Fehlererkennungsblock 272 senden, die der Fehlererkennungsblock 272 in Block 914 empfängt. Dann fährt das Verfahren 900 mit Block 916 fort.
10 veranschaulicht ein Beispiel für den Fehlererkennungsblock 272, der das Verfahren 900 durchführt. In diesem Beispiel liest der Prozessor 140 16 Datenbytes aus dem Ausschnitt 250, der in dem in 8 dargestellten Beispiel gespeichert ist. In 10 werden die gelesenen Daten in einem Array von 128 Bits mit der Bezeichnung „rdata_in[127:0]“ gespeichert oder durch dieses dargestellt, und die Daten werden ab der ersten Datenadresse gespeichert, die in einem Array von 40 Bits mit der Bezeichnung „Address_0[39:0]“ gespeichert oder durch dieses dargestellt wird. 10 zeigt, wie der Initiator 802 (z. B. der Prozessor 140) eine erste Leseanweisung 1004 über die Sicherheitsinselverbindung 808 an den Block zur Fehlererkennung 272 sendet. Die Sicherheitsinselverbindung 808 gibt die erste Leseanweisung 1004 an den Block zur Fehlererkennung 272 ab (z. B. Block 902 in 9).
Der Block 272 für die Fehlererkennung sendet die erste Datenadresse an den ersten Unterabschnitt 252 des Ausschnitts 250 über die flüchtige Speicherschnittstelle 200A (siehe 2) zu einem dritten Zeitpunkt (z. B. identifiziert in 8 als „Zeit=T3“). Mit anderen Worten, der Block 272 zur Fehlererkennung leitet die erste Leseanweisung an den ersten Unterabschnitt 252 des Ausschnitts 250 weiter (z. B. Block 904 von 9). Die flüchtige Speicherschnittstelle 200A übermittelt die erste Leseanweisung über das Daten-Backbone und das Speicher-Subsystem 826 des automobilen SoC 104 an den Ausschnitt 250. In 10 wird die erste Leseanweisung vom Block zur Fehlererkennung 272 in einem Signal 1010 an den ersten Unterabschnitt 252 gesendet.
Der erste Unterabschnitt 252 liest die Daten aus dem Speicher, beginnend mit dem ersten Byte („Byte 0“) an der ersten Datenadresse und dem Lesen der nachfolgenden Bytes von den nachfolgenden Datenadressen nach der ersten Datenadresse. Die SI 110 kann Daten mit einer vorbestimmten Größe (z. B. 16 Byte) aus dem Ausschnitt 250 lesen. Anschließend sendet der erste Unterabschnitt 252 ein Antwortsignal 1012 an den Initiator 802, das die gelesenen Daten schließt. Das Antwortsignal 1012 wird von der ersten Unterabteilung 252 an das Daten-Backbone- und Speicher-Subsystem 826 gesendet, das das Antwortsignal 1012 an die flüchtige Speicherschnittstelle 200A weiterleitet (siehe 2). Wenn die flüchtige Speicherschnittstelle 200A entsperrt ist, leitet die flüchtige Speicherschnittstelle 200A das Antwortsignal 1012 an den ersten (Daten-)Puffer 820 weiter (z. B. Block 906 von 9). Die Daten, die gelesen und in das Antwortsignal 1012 eingeschlossen wurden, zeigen automatisch den Abschluss des Datenlesens an und können daher als Antworten auf den Abschluss des Datenlesens charakterisiert werden. Wie der erste (Daten-)Puffer 820 bei den Antworten zum Abschluss des Datenschreibens vorgeht, kann der erste (Daten-)Puffer 820 die Antworten zum Abschluss des Datenlesens in einer erwarteten Reihenfolge im Antwortsignal 1012 aufsetzen. Zu diesem Zeitpunkt wurden in diesem Beispiel die Daten (z. B. 16 Bytes) in einem ersten einzelnen Lesevorgang aus dem ersten Unterabschnitt 252 gelesen und vom ersten (Daten-)Puffer 820 in der erwarteten Reihenfolge aufgesetzt.
Dann bestimmt der Fehlererkennungsblock 272 eine erste Codeadresse („Address_1“) basierend auf der ersten Datenadresse (z. B. Block 908 von 9). In 10 wird die erste Codeadresse berechnet, indem (zum Beispiel) 16 Megabytes („MB“) zu der ersten Datenadresse („Address_0“) addiert werden.
Als Nächstes wartet der Fehlererkennungsblock 272 (z. B. Block 910 von 9 bis zu einem vierten Mal (z. B. in 10 als „Time=T4“ identifiziert). Zum vierten Mal fordert der Fehlererkennungsblock 272 über die flüchtige Speicherschnittstelle 200A (siehe 2) den/die an der/den ersten Codeadresse(n) im zweiten Unterabschnitt 254 gespeicherten Fehlererkennungscode(s) an. Mit anderen Worten: Der Block 272 zur Fehlererkennung sendet die zweite Leseanweisung an den zweiten Unterabschnitt 254 des Ausschnitts 250 (z. B. Block 912 in 9). Die flüchtige Speicherschnittstelle 200A übermittelt die zweite Schreibanweisung über das Daten-Backbone- und Speicher-Subsystem 826 des automobilen SoC 104 an den Carve-out 250 (siehe FIG. In 10 wird die zweite Leseanweisung vom Block zur Fehlererkennung 272 in einem Signal 1014 an Unterabschnitt 254 gesendet.
Der zweite Unterabschnitt 254 liest die Fehlererkennungscodes aus dem Speicher, indem er den ersten Fehlererkennungscode (für „Byte 0“) an der ersten Codeadresse liest und die nachfolgenden Fehlererkennungscodes von nachfolgenden Codeadressen nach der ersten Codeadresse liest. Im Beispiel von 8 und 10 haben der/die Fehlererkennungscode(s) jeweils eine Größe von einem Byte. Anschließend sendet der zweite Unterabschnitt 254 ein Antwortsignal 1016 an den Initiator 802, das den/die aus dem Speicher gelesenen Fehlererkennungscode(s) beinhaltet. 10 werden die Signale, die die Codes für die Fehlererkennung tragen, und das Signal 1014 durch Pfeile mit gestrichelten Linien veranschaulicht. In der Ausführungsform, wie in 10 veranschaulicht, wird das Antwortsignal 1016 von der ersten Unterabschnitt 254 an das Daten-Backbone- und Speicher-Subsystem 826 gesendet, das das Antwortsignal 1016 an die flüchtige Speicherschnittstelle 200A weiterleitet (siehe 2). Wenn die flüchtige Speicherschnittstelle 200A entsperrt ist, leitet die flüchtige Speicherschnittstelle 200A das Antwortsignal 1016 an den zweiten (Code-)Puffer 822 weiter (z. B. Block 914 von 9). Die Codes zur Fehlererkennung, die gelesen und in das Antwortsignal 1016 eingeschlossen wurden, zeigen automatisch die Beendigung des Codelesens an und können daher als Antworten auf die Beendigung des Codelesens charakterisiert werden. Wie der erste (Daten-)Puffer 822 bei den Antworten zum Abschluss des Datenschreibens vorgeht, kann der erste (Daten-)Puffer 822 die Antworten zum Abschluss des Datenlesens in einer erwarteten Reihenfolge im Antwortsignal 1016 aufsetzen. An diesem Punkt wurden in diesem Beispiel die Fehlererkennungscodes (z. B. 16 Bytes) aus dem zweiten Unterabschnitt 254 in einem zweiten einzelnen Lesevorgang gelesen und durch den zweiten (Code-)Puffer 822 in der erwarteten Reihenfolge platziert.
Wenn der Fehlererkennungsblock 272 (z. B. Block 910 von 9) bis zum vierten Mal (z. B. in 10 als gekennzeichnet) wartet „Time=T4“), der Fehlererkennungsblock 272 beabstandet lediglich die ersten und zweiten Leseanweisungen zeitlich. Der Fehlererkennungsblock 272 kann den/die Fehlererkennungscode(s) von dem zweiten Unterabschnitt 254 anfordern, nachdem der Fehlererkennungsblock 272 die Daten in dem Antwortsignal 1012 empfängt. Alternativ kann der Fehlererkennungsblock 272 nicht warten, bis er die Daten in dem Antwortsignal 1012 empfängt, bevor er den/die Fehlererkennungscode(s) von dem zweiten Unterabschnitt 254 anfordert. Mit anderen Worten, der vierte Zeitpunkt kann basierend darauf bestimmt werden, wann die erste Leseanweisung gesendet wird, und nicht darauf, wann das Antwortsignal 1012 empfangen wird.
Wie oben erwähnt, kann der erste (Daten-)Puffer 820 die Bytes neu ordnen, da die Bytes in dem Antwortsignal 1012 möglicherweise nicht in der richtigen Reihenfolge sind. In ähnlicher Weise kann der zweite (Code-)Puffer 822 die Fehlererkennungscodes neu ordnen, wenn die Fehlererkennungscodes in dem Antwortsignal 1016 in der falschen Reihenfolge sind. Der erste (Daten-)Puffer 820 gibt Signale 1022-0 bis 1022-15 aus, die jeweils eines der Datenbytes tragen, und der zweite (Code-)Puffer 822 gibt Signale 1024-0 bis 1024-15 aus, die jeweils einen der Fehlererkennungscodes tragen. Die Signale 1022-0 bis 1022-15 entsprechen jeweils den Signalen 1024-0 bis 1024-15. Der erste und der zweite Puffer 820 und 822 können die Signale 1022-0 bis 1022-15 und 1024-0 bis 1024-15 umleiten oder neu anordnen, um jedes Datenbyte an einer bekannten Position zu lokalisieren, bezogen auf den für das Byte erstellten Fehlererkennungscode. In der Ausführungsform, wie in 10, werden die von den Signalen 1022-0 bis 1022-15 übertragenen Bytes mit den von den Signalen 1024-0 bis 1024-15 übertragenen Fehlererkennungscodes verschachtelt. Somit, wie in 10, werden die Datenbytes an Stellen platziert, die durch die schattierten Blöcke b0-b15 dargestellt werden, und der/die Fehlererkennungscode(s) wird/werden an Stellen platziert, die durch die Blöcke c0-c15 dargestellt werden.
Dann bestimmt der Codeerzeugungsunterblock 273 (z. B. unter Verwendung der obigen Gleichung 1) einen Prüfcode für jedes der Bytes der Daten (z. B. Block 916 von 9). Somit empfängt der Codeerzeugungsunterblock 273 als Eingaben die Datenbytes in den Signalen 1022-0 bis 1022-15 und die entsprechenden Fehlererkennungscodes in den Signalen 1024-0 bis 1024-15.
Für jeden der Fehlererkennungscodes bestimmt der Fehlererkennungsblock 272, ob der Fehlererkennungscode mit dem Prüfcode abgleicht, der dem Fehlererkennungscode entspricht (z. B. Entscheidungsblock 918 von 9). Der Fehlererkennungsblock 272 zeigt an, ob sie in einem Durchgangssignal 1030 übereinstimmen, das zusammen mit einem Datensignal 1032, das das Datenbyte beinhaltet, an eine logische Komponente 1034 weitergeleitet wird, die in 10 als UND-Gatter implementiert ist. Wenn das Durchgangssignal 1030 anzeigt, dass der für das Byte gespeicherte Fehlererkennungscode mit dem für das Byte erstellten Prüfcode übereinstimmt, gibt die Logikkomponente 1034 das Byte in einem geprüften Datensignal 1036 aus (das nur Datenbytes einschließt) und leitet das geprüfte Datensignal 1036 an den Initiator 802 weiter. Wenn andererseits das Durchgangssignal 1030 eine Nichtübereinstimmung anzeigt, leitet die Logikkomponente 1034 das Byte in dem geprüften Datensignal 1036 nicht an den Initiator 802 weiter. Stattdessen kann der Fehlererkennungsblock 272 das Byte verwerfen und/oder durch Informationen (z. B. Nullen) ersetzen, die anzeigen, dass eine Nichtübereinstimmung aufgetreten ist. Als nicht einschränkendes Beispiel können die Bits des Bytes, das die Nichtübereinstimmung erzeugt hat, auf null gesetzt werden. Das geprüfte Datensignal 1036 wird an den Initiator 802 weitergeleitet (z. B. Block 920 von 9). Der Fehlererkennungsblock 272 kann einen Nichtübereinstimmungsfehler erzeugen und ihn an den Initiator 802 senden, wenn der Fehlererkennungscode nicht mit dem Prüfcode übereinstimmt, der dem Fehlererkennungscode entspricht (z. B. Block 922 von 9). Mit anderen Worten, wenn das Durchgangssignal 1030 eine oder mehrere Nichtübereinstimmungen anzeigt, kann der Fehlererkennungsblock 272 einen Nichtübereinstimmungsfehler erzeugen und ihn an den Initiator 802 senden. Alternativ oder zusätzlich kann der Fehlererkennungsblock 272 den Fehlanpassungsfehler als unkorrigierten Fehler an den SI-Fehleraggregator 142 senden. Somit jeder Fehler, der in den Daten oder dem/den Fehlererkennungscode(s) während der Speicherung in dem Ausschnitt 250 auftritt und/oder ein Abruf aus dem Carve-out 250 kann erkannt und gemeldet werden (z. B. als ein unkorrigierter Fehler).
Wie bereits erwähnt, kann die flüchtige Speicherschnittstelle 200A die beiden parallelen und gegebenenfalls dedizierten Schnittstellen einschließen, die den Block für die Fehlererkennung 272 mit dem flüchtigen Speicher 126 verbinden. In solchen Ausführungsformen kann der Fehlererkennungsblock 272 die erste Leseanweisung einschließlich der ersten Datenadresse (z. B. im Signal 1010) über die erste Schnittstelle an den ersten Unterabschnitt 252 senden, während der Fehlererkennungsblock 272 die zweite Leseanweisung einschließlich der ersten Codeadresse (z. B. im Signal 1014) über die zweite Schnittstelle an den zweiten Unterabschnitt 254 sendet. Ferner können die aus der ersten Untersektion 252 gelesenen Daten (z. B. und übertragen im Antwortsignal 1012) und die aus dem zweiten Unterabschnitt 254 gelesenen Fehlererkennungscodes (z. B. und übertragen im Antwortsignal 1016) gleichzeitig über die erste/zweite Schnittstelle an den ersten und zweiten Puffer 820 und 822 übertragen werden.
Unter Bezugnahme auf FIG., wie in 2 gezeigt, kann der Fehlererkennungsblock 272 mindestens einen Transaktions-Timer beinhalten oder mit diesem verbunden sein, wie z. B. Austritts- und Eintritts-Timer 274 und 276, der eine Zeitdauer begrenzt, aus der der Fehlererkennungsblock 272 Daten lesen muss und/oder Daten in den Ausschnitt 250 schreiben. Der Ausgangs-Timer 274 und/oder der Eintritts-Timer 276 werden automatisch gestartet, wenn ein Zugang den Block für die Fehlererkennung 272 durchläuft. Beispielsweise kann der Eintritts-Timer 276 immer dann starten, wenn Daten zwischen dem Fehlererkennungsblock 272 und dem Initiator 802 (z. B. dem Prozessor 140) übertragen werden, und der Ausgangs-Timer 274 kann immer dann starten, wenn Daten zwischen dem Fehlererkennungsblock 272 und der SoC-Domäne (z.B. der Ausschnitt 250) durchlaufen. Der Eintritts-Timer 276 kann dabei helfen, das Funktionieren des Fehlererkennungsblocks 272 zu überwachen und/oder kann dabei helfen, Backup-Funktionalität für den Ausgangs-Timer 274 bereitzustellen (z. B. wenn der Ausgangs-Timer 274 nicht richtig funktioniert).
Während einer Schreiboperation kann der Eintritts-Timer 276 starten, wenn der Initiator 802 Daten an den Fehlererkennungsblock 272 weiterleitet, um in den Ausschnitt 250 zu schreiben (z. B. bei Block 702 von 7). Dann kann der Ausgangs-Timer 274 starten, wenn diese Daten den Block 272 für die Fehlererkennung und/oder die SI-Domäne verlassen (z. B. in Block 708 von 7). Der Ausgangs-Timer 274 kann anhalten oder zurückgesetzt werden, wenn die Antwort (z. B. das in 8 veranschaulichte Antwortsignal 828) von dem Ausschnitt 250 durch den Fehlererkennungsblock 272 empfangen wird. Dann kann der Eintritts-Timer 276 anhalten oder zurückgesetzt werden, wenn die Antwort (z. B. das in 8 veranschaulichte Antwortsignal 828) durch den Fehlererkennungsblock 272 an den Initiator 802 (siehe 8) übertragen wird. Wenn der Ausgangs-Timer 274 angibt, dass mehr als eine erste Schwellenzeitdauer verstrichen ist und der Fehlererkennungsblock 272 die Antwort nicht empfangen hat, bedeutet dies, dass der Initiator 802 keine Antwort von dem Ausschnitt 250 (z. B. das Antwortsignal 828 dargestellt in 8) empfangen hat, wobei der Initiator 802 (z. B. der Prozessor 140) einen Ausgangs-Timeout-Fehler erzeugt. Wenn der Eintritts-Timer 276 angibt, dass mehr als eine zweite Schwellenzeitdauerdauer verstrichen ist und der Fehlererkennungsblock 272 die Antwort nicht an den Initiator 802 gesendet hat, bedeutet dies, dass der Initiator 802 die Antwort von dem Ausschnitt 250 nicht empfangen hat, wobei der Initiator 802 einen Eintritts-Timeout-Fehler erzeugt.
Während einer Leseoperation kann der Eintritts-Timer 276 starten, wenn der Fehlererkennungsblock 272 die Leseanforderung von dem Initiator 802 empfängt (z. B. bei Block 902 von 9). Dann kann der Ausgangs-Timer 274 starten, wenn der Fehlererkennungsblock 272 die an der ersten Datenadresse gespeicherten Daten von dem Ausschnitt 250 anfordert (z. B. bei Block 904 von 9). Der Ausgangs-Timer 274 kann anhalten oder zurückgesetzt werden, wenn die Daten von dem Ausschnitt 250 durch den Fehlererkennungsblock 272 empfangen werden (z. B. bei Block 906 von 9). Dann kann der Eintritts-Timer 276 angehalten oder zurückgesetzt werden, wenn die Daten durch den Block 272 zur Fehlererkennung an den Initiator 802 übertragen werden (z. B. in Block 920 von 9). Wenn der Ausgangs-Timer 274 angibt, dass die erste Schwellenzeitdauerdauer verstrichen ist und der Fehlererkennungsblock 272 die Daten nicht von dem Ausschnitt 250 empfangen hat, bedeutet dies, dass der Initiator 802 die Daten nicht von dem Fehlererkennungsblock 272 empfangen hat (z.B. in dem geprüften Datensignal 1036, das in 10 dargestellt ist), wobei der Initiator 802 den Ausgangs-Timeout-Fehler erzeugt. Wenn der Eintritts-Timer 276 anzeigt, dass mehr als der zweite Schwellenwert an Zeit verstrichen ist und der Block zur Fehlererkennung 272 die Daten nicht an den Initiator 802 gesendet hat, bedeutet dies, dass der Initiator 802 die Daten nicht vom Ausschnitt 250 empfangen hat, wobei der Initiator 802 den Eintritts-Timeout-Fehler erzeugt.
11 veranschaulicht ein Blockdiagramm mit Fehlermeldungen, die vom Block zur Fehlererkennung 272 erzeugt werden (siehe 2, 8 und 10), wenn der Block zur Fehlererkennung 272 die Ausgangs- und Eintritts-Timer 274 und 276 einschließt oder mit ihnen verbunden ist (siehe 2), gemäß einigen Ausführungsformen. In 11 sendet der Initiator 802 (siehe 8 und 10) ein Signal 1102, das entweder die erste Schreibanweisung 804 (siehe 8) oder die erste Leseanweisung 1004 (siehe 10) beinhaltet, an den Fehlererkennungsblock 272. Wie oben erwähnt, kann der Ausgangs-Timer 274 starten, wenn die Daten den Fehlererkennungsblock 272 verlassen und/oder die SI-Domäne während einer Schreiboperation, und der Ausgangs-Timer 274 kann starten, wenn der Fehlererkennungsblock 272 die an der ersten Datenadresse gespeicherten Daten von dem Ausschnitt 250 während einer Leseoperation anfordert. Block 1104 zeigt an, dass der Ausgangs-Timer 274 eine Zeitüberschreitung aufweist. Der Eintritts-Timer 274 kann z. B. ablaufen, wenn der Fehlererkennungsblock 272 während eines Schreibvorgangs keine Antwort vom Ausschnitt 250 (z. B. das in 8 dargestellte Antwortsignal 828) erhalten hat und mehr als die erste Schwellenzeitdauer verstrichen ist. Als weiteres, nicht einschränkendes Beispiel kann der Ausgangs-Timer 274 ablaufen, wenn der Fehlererkennungsblock 272 die Daten vom Fehlererkennungsblock 272 (z. B. im Antwortsignal 1012, das in 10 dargestellt ist) während eines Lesevorgangs nicht empfangen hat und mehr als die erste Schwellenzeitdauerdauer verstrichen ist. Wenn der Ausgangs-Timer 274 abgelaufen ist, erzeugt der Initiator 802 (z. B. der Prozessor 140) einen Ausgangs-Timeout-Fehler 1106 und leitet den Ausgangs-Timeout-Fehler 1106 an einen Fehler-Logger 1108 weiter. Wenn der Ausgangs-Timer 274 hingegen keine Zeitüberschreitung aufweist, kann der Ausgangs-Timer 274 angehalten oder zurückgesetzt werden. Dies kann auftreten, wenn der Fehlererkennungsblock 272 entweder die Antwort (z. B. das Antwortsignal 828) von dem Ausschnitt 250 während einer Schreiboperation oder die Daten (z. B. in dem Antwortsignal 1012) von dem Ausschnitt 250 empfängt während einer Leseoperation, bevor die erste Schwellenzeitdauer verstrichen ist.
Wie oben erwähnt, kann der Eintritts-Timer 276 beginnen, wenn der Initiator 802 während eines Schreibvorgangs Daten an den Fehlererkennungsblock 272 weitergibt, um in den Ausschnitt 250 zu schreiben (z. B. in Block 702 von 7), oder der Eintritts-Timer 276 kann beginnen, wenn der Fehlererkennungsblock 272 während eines Lesevorgangs die Leseanforderung vom Initiator 802 empfängt (z. B. in Block 902 von 9). Somit kann der Eintritts-Timer 276 (siehe 2) starten, wenn das Signal 1102 die erste Leseanweisung 804 (siehe 8) oder die erste Leseanweisung 1004 (siehe 10) beinhaltet und diese Anweisung durch den Fehler empfangen wird Erkennungsblock 272 (siehe 2, 8 und 10). Block 1114 zeigt an, dass der Eintritts-Timer 276 eine Zeitüberschreitung aufweist. Der Eintritts-Timer 276 kann zum Beispiel ablaufen, wenn mehr als die zweite Schwellenzeitdauerdauer verstrichen ist und der Initiator 802 (siehe 8) keine Antwort von dem Ausschnitt 250 (z. B. das Antwortsignal 828 dargestellt in 8) während einer Schreiboperation empfangen hat. Als ein weiteres nicht einschränkendes Beispiel kann der Eintritts-Timer 276 ablaufen, wenn mehr als die zweite Schwellenzeitdauerdauer verstrichen ist und der Initiator 802 die Daten (z. B. das in 10 dargestellte Signal 1036 für geprüfte Daten) aus dem Ausschnitt 250 während einer Leseoperation nicht empfangen hat. Wenn der Eintritts-Timer 276 abgelaufen ist, erzeugt der Initiator 802 einen Eintritts-Timeout-Fehler 1116 und leitet den Eintritts-Timeout-Fehler 1116 an den Fehler-Logger 1108 weiter. Wenn der Eintritts-Timer 276 hingegen keine Zeitüberschreitung aufweist, kann der Eintritts-Timer 276 angehalten oder zurückgesetzt werden. Dies kann geschehen, wenn der Block 272 zur Fehlererkennung während eines Schreibvorgangs die Antwort (z. B. das Antwortsignal 828) an den Initiator 802 überträgt oder wenn der Block 272 zur Fehlererkennung während eines Lesevorgangs die Daten (z. B. das Signal 1036 für geprüfte Daten) an den Initiator 802 überträgt.
Block 1124 zeigt an, dass der Codeerzeugungs-Unterblock 273 (siehe 2, 8 und 10) des Fehlererkennungsblocks 272 (siehe 2, 8 und 10) einen Codeerzeugungs-/Prüfungsfehler 1126 erzeugen kann, der anzeigt, dass während der Erzeugung eines Fehlererkennungscodes oder eines Prüfcodes ein Fehler aufgetreten ist. In einigen Ausführungsformen kann der Codegenerations-/Prüffehler 1126 anzeigen, dass eine Nichtübereinstimmung aufgetreten ist. Zum Beispiel kann, wenn das Signal 1102 die erste Schreibanweisung 804 beinhaltet, der Codeerzeugungs-Unterblock 273 einen Codeerzeugungsfehler erzeugen, während er den/die Fehlererkennungscode(s) schließt. Als weitere, nicht einschränkende Beispiele kann der Fehlererkennungsblock 272, wenn das Signal 1102 die erste Leseanweisung 1004 beinhaltet, einen Nichtübereinstimmungsfehler und/oder einen Codeerzeugungsfehler erzeugen, während er den/die Prüfcode(s) erzeugt, die als Codeerzeugungs-/Prüffehler 1126 an den Fehler-Logger 1108 weitergeleitet wird/werden.
Der Fehler-Logger 1108 kann als Fehleraggregator funktionieren, der die Fehler 1106, 1116 und 1126 zu einer Fehlermeldung 1130 aggregiert, die der Fehlerlogger 1108 an den SI-Fehleraggregator 142 sendet.
Wenn das automobile SoC 104 zum ersten Mal hochfährt, kann der Prozessor 140 der SI 110 versuchen, Daten von dem Ausschnitt 250 vorab abzurufen. Ein Vorabruf kann als eine Art nicht absichtliches Lesen von Daten aus dem Ausschnitt 250 charakterisiert werden. Da der gemeinsam genutzte flüchtige Speicher 126 flüchtig ist, kann der Ausschnitt 250 an diesem Punkt nicht initialisierte Daten speichern, denen ein oder mehrere Fehlererkennungscodes fehlen oder denen ein oder mehrere nicht übereinstimmende Fehlererkennungscodes zugeordnet sind. Um zu verhindern, dass der Fehlererkennungsblock 272 Fehlanpassungsfehler erzeugt, kann die SI 110 (z. B. der Prozessor 140, die DMA-Maschine 402, und/oder dergleichen) kann einen oder mehrere Fehlererkennungscodes in den Ausschnitt 250 für die Daten schreiben, die der Prozessor 140 vorab abrufen wird oder könnte. Als nicht einschränkendes Beispiel kann die Sl 110 Anfangsdaten in den Ausschnitt 250 schreiben, was bewirkt, dass die Hardware des Fehlererkennungsblocks 272 einen oder mehrere Fehlererkennungscodes für die Anfangsdaten bestimmt, die jeweils einer Codeadresse zugeordnet sind. Dann kann die SI 110 der Ausschnitt 250 veranlassen, jeden Fehlererkennungscode in seiner zugeordneten Codeadresse zu speichern. Somit entsprechen während eines Vorabrufsvorgang die vom zweiten Unterabschnitt 254 gespeicherten Fehlererkennungscodes den im ersten Unterabschnitt 252 gespeicherten Daten, und der Fehlererkennungsblock 272 erzeugt keine Fehlanpassungsfehler.
Unter Bezugnahme auf 2 kann die SI 110 den Codeerzeugungsunterblock 273 ausschalten (siehe 2, 8 und 10) und/oder den Fehlererkennungsblock 272 (z. B. unter Verwendung eines Softwareregisterschreibens), wenn die Automobil-Plattform 100 (siehe 1) den Ausschnitt 250 nicht erfordert. Zum Beispiel kann die SI 110 den Unterblock 273 zur Codeerzeugung und/oder den Block 272 zur Fehlererkennung abschalten, wenn der flüchtige Speicher 126 auf einem für die Automobil-Plattform 100 ausreichenden Risiko-Level arbeitet.
Es versteht sich, dass diese und andere hierin beschrieben 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.
BEISPIELHAFTES AUTONOMES FAHRZEUG
12 ist eine Veranschaulichung des Beispiels eines autonomen Fahrzeugs 1200 gemäß einiger Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 1200 (hier alternativ als das „Fahrzeug 1200“ bezeichnet) kann ohne Einschränkung einen Personenkraftwagen wie etwa ein Auto, einen Lastkraftwagen, einen Bus, ein Ersthelferfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder einen anderen Fahrzeugtyp beinhalten (der z. B. unbemannt ist und/oder einen oder mehrere Fahrgäste unterbringt). Autonome Fahrzeuge werden im Allgemeinen in Bezug auf das Automatisierungs-Level beschrieben, die durch die National Highway Traffic Safety Administration (NHTSA), eine Abteilung des US-Verkehrsministeriums, und die „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ der Society of Automotive Engineers (SAE) (Norm Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Norm Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieser Norm) definiert sind. Das Fahrzeug 1200 kann zu einer Funktionalität gemäß einem oder mehreren von Level 2 - Level 5 der Levels für autonomes Fahren, wie durch SAE definiert, in der Lage sein. Zum Beispiel kann das Fahrzeug 1200 in Abhängigkeit von der Ausführungsform zu einer teilweisen Automatisierung des Fahrens (Level 2), bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.
Das Fahrzeug 1200 kann Komponenten wie Chassis, Karosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 1200 kann ein Antriebssystem 1250 beinhalten, wie etwa eine Brennkraftmaschine, ein Hybridelektrotriebwerk, einen vollelektrischen Motor und/oder einen anderen Typ von Antriebssystem. Das Antriebssystem 1250 kann mit einem Antriebsstrang des Fahrzeugs 1200 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 1200 zu ermöglichen. Das Antriebssystem 1250 kann als Reaktion auf den Empfang von Signalen des Gaspedals/Gashebel 1252 gesteuert werden.
Ein Lenksystem 1254, das möglicherweise ein Lenkrad beinhaltet, kann verwendet werden, um das Fahrzeug 1200 zu lenken (z. B. entlang eines gewünschten Wegs oder Route), wenn das Antriebssystem 1250 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1254 kann Signale von einem Lenkaktor 1256 empfangen. Für die vollständige Automatisierungsfunktionalität (Level 5) kann das Lenkrad optional sein.
Das Bremssensorsystem 1246 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf das Empfangen von Signalen von den Bremsaktoren 1248 und/oder Bremssensoren zu betreiben.
Die Steuerung(en) 1236, der/die eine oder mehrere CPU(s), System on Chips (SoCs) 1204 (14) 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 1200 bereitstellen. Die Steuerung(en) kann/können z. B. Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktoren 1248, zur Betätigung des Lenksystems 1254 über einen oder mehrere Lenkaktoren 1256, und/oder zur Betätigung des Antriebssystems 1250 über einen oder mehrere Drossel-/Beschleunigungsaktoren 1252 senden. Die Steuerung(en) 1236 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 1200 zu unterstützen. Die Steuerung(en) 1236 kann/können eine ersten Steuerung 1236 für Funktionen des autonomen Fahrens, eine zweiten Steuerung 1236 für funktionelle Sicherheitsfunktionen, eine dritte Steuerung 1236 für eine Funktionalität der künstlichen Intelligenz (z. B. maschinelles Sehen), eine vierte Steuerung 1236 für eine Infotainment-Funktionalität, eine fünfte Steuerung 1236 für Redundanz in Notfällen und/oder andere Steuerungen beinhalten. In einigen Beispielen kann ein einzelner Steuerungen 1236 zwei oder mehr der vorstehenden Funktionalitäten handhaben, können zwei oder mehr Steuerungen 1236 eine einzelne Funktionalität handhaben und/oder eine beliebige Kombination davon.
Die Steuerung(en) 1236 stellt/stellen Signale zum Steuern einer/eines oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1200 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) 1258 von globalen Navigationssatellitensystemen (z. B. Sensor(en) des globalen Positionsbestimmungssystems), RADAR-Sensor(en) 1260, Schwingungssensor(en) 1262, LIDAR-Sensor(en) 1264, Sensor(en) 1266 einer Trägheitsmesseinheit (inertial measurement unit - IMU) (z. B. Beschleunigungsmesser(n), Gyroskop(en), Magnetkompass(en), Magnetometer(n) usw.), Mikrofon(en) 1296, Stereokamera(s) 1268, Weitsichtkamera(s) 1270 (z. B. Fischaugenkameras), Infrarotkamera(s) 1272, Rundumkamera(s) 1274 (z. B. 360-Grad-Kameras), Langstrecken- und/oder Mittelstreckenkamera(s) 1298, Geschwindigkeitssensor(en) 1244 (z. B. zum Messen der Geschwindigkeit des Fahrzeugs 1200), Schwingungssensor(en) 1242, Lenksensor(en) 1240, Bremssensor(en) 1246 (z. B. als Teil des Bremssensorsystems 1246) und/oder anderen Sensortypen.
Eine oder mehrere der Steuerung(en) 1236 kann/können Eingaben (z. B. durch Eingabedaten dargestellt) von einem Kombiinstrument 1232 des Fahrzeugs 1200 empfangen und Ausgaben (z. B. durch Ausgabedaten, Anzeigedaten usw. dargestellt) über eine Anzeige 1234 einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1200 bereitstellen. Die Ausgaben können Informationen wie etwa Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Abbildungsdaten (z. B. die HD-Abbildung 1222 aus 14), Standortdaten (z. B. den Standort des Fahrzeugs 1200, wie etwa auf einer Karte), Richtung, Standort von anderen Fahrzeugen (z. B. ein Belegungsraster), Informationen über Objekte und Status von Objekten, wie sie durch die Steuerung(en) 1236 wahrgenommen werden, usw. beinhalten. Zum Beispiel kann die HMI-Anzeige 1234 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. eines Straßenschilds, eines Warnschilds, einer umschaltenden Ampel usw.) und/oder Informationen über Fahrmanöver, die das Fahrzeug vorgenommen hat, vornimmt oder vornehmen wird (z. B. dass es jetzt die Spur wechselt, in zwei Meilen Ausfahrt 34B nimmt usw.), anzeigen.
Das Fahrzeug 1200 kann ferner eine Netzwerkschnittstelle 1224, die drahtlose Antenne(n) 1226 und/oder Modem(s) zum Kommunizieren über ein oder mehrere Netzwerke verwenden. Zum Beispiel kann die Netzwerkschnittstelle 1224 zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. fähig sein. Die drahtlose(n) Antenne(n) 1226 kann/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 Weitverkehrsnetzwerk(en) mit niedriger Leistung (low power wide-area networks - LPWANs) wie etwa LoRaWAN, SigFox usw. ermöglichen.
Wie oben erwähnt, kann die Automobil-Plattform 100 (siehe 1) in zumindest einigen Ausführungsformen eine Komponente des autonomen Fahrzeugs 1200 sein. In solchen Ausführungsformen beinhalten die Steuerung(en) 1236 das Automobil-SoC 104.
13 ist ein Beispiel für die Positionen und Sichtfelder der Kameras für das autonome Fahrzeug 1200 von 12 gemäß einiger 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 beinhaltet sein und/oder die Kameras können sich an unterschiedlichen Stellen an dem Fahrzeug 1200 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 1200 ausgelegt sind. Die Kamera(s) können mit dem automobilen Sicherheitsintegritä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 z. B. 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 eine 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, ein 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) 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 die Kamera(s) in den Außenspiegel integriert sein. Bei Seitensichtkameras können die Kamera(s) auch in vier Säulen an jeder Ecke des Fahrerhauses integriert sein.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 1200 beinhaltet (z. B. nach vorn 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 1236 und/oder Steuer-SoCs beim Bereitstellen von Informationen zu helfen, die für die Erzeugung eines Belegungsgitters und/oder die Bestimmung bevorzugter Fahrzeugpfade entscheidend sind. Nach vorn 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.
Eine Vielfalt an Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, einschließlich zum Beispiel einer monokularen Kameraplattform, die einen Farbbildsensor mit CMOS (complementary metal oxide semiconductorkomplementärer Metalloxid-Halbleiter) beinhaltet. Ein weiteres Beispiel kann eine Weitsichtkamera 1270 sein, die verwendet werden kann, um Objekte wahrzunehmen, die aus einer Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 13 nur eine Weitwinkelkamera veranschaulicht ist, kann eine beliebige Anzahl von Weitwinkelkameras 1270 an dem Fahrzeug 1200 vorhanden sein. Zusätzlich kann eine Langstreckenkamera(s) 1298 (z. B. ein Weitsichtstereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netzwerk noch nicht trainiert worden ist. Die Langstreckenkamera(s) 1298 können auch zur Objekterkennung und - klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 1268 können auch in einer nach vorne gerichteten Konfiguration beinhalten. Die Stereokamera(s) 1268 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 alternative Stereokamera(s) 1268 können (einen) kompakte(n) Stereosichtsensor(en) beinhalten, die zwei Kameraobjektive (je eines 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 die autonome Notbrems- und Spurverlassenswarnfunktionen zu aktivieren. Andere Typen von Stereokamera(s) 1268 können zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 1200 beinhaltet (z. B. Seitensichtkameras), können für die Rundumsicht verwendet werden, wodurch Informationen bereitgestellt werden, die zum Erstellen und Aktualisieren eines Belegungsgitters sowie zum Erzeugen von Seitenaufprallkollisionswarnungen verwendet werden. Zum Beispiel könnten die Rundumkamera(s) 1274 (z. B. vier Rundumkameras 1274, wie in 13 veranschaulicht) an dem Fahrzeug 1200 positioniert sein. Die Rundumkamera(s) 1274 können Weitwinkelkamera(s) 1270, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder ähnliches beinhalten. Zum Beispiel können vier Fischaugenkameras an der Front, am Heck und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Rundumkamera(s) 1274 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorn gerichtete Kamera) als vierte Rundumsichtkamera ausnutzen.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 1200 einschließt (z. B. Rückfahrkameras), können als Einparkhilfe, für die Rundumsicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsgitters 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. Kamera(s) 1298 mit langer oder mittlerer Reichweite, Stereokamera(s) 1268, Infrarotkamera(s) 1272 usw.) geeignet sind, wie hier beschrieben.
14 ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 1200 aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben 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 1200 in 14 als über den Bus 1202 verbunden veranschaulicht. Der Bus 1202 kann eine Controller-Area-Network (CAN)-Datenschnittstelle beinhalten (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 1200 sein, das verwendet wird, um die Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1200 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 einen eigenen eindeutigen Bezeichner (z. B. eine CAN-ID) aufweist. Der CAN-Bus kann ausgelesen werden, um Lenkradwinkel, Geschwindigkeit über Grund, Motorumdrehungen pro Minute (revolutions per minute - RPMs), Tastenpositionen und/oder andere Fahrzeugstatusindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 1202 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich zu oder alternativ zu dem CAN- Bus auch FlexRay und/oder Ethernet verwendet werden. Obwohl der Bus 1202 mit einer einzigen Linie dargestellt wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel kann eine beliebige Anzahl von Bussen 1202 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 1202 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder können zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 1202 für die Funktionalität der Kollisionsvermeidung verwendet werden und ein zweiter Bus 1202 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1202 mit beliebigen der Komponenten des Fahrzeugs 1200 kommunizieren, und zwei oder mehr Busse 1202 können mit den gleichen Komponenten kommunizieren. In einigen Beispielen können jedes SOC(s) 1204, jede Steuerung 1236 und/oder jeder Computer im Fahrzeug Zugang auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 1200) haben und mit einem gemeinsamen Bus, wie etwa dem CAN-Bus, verbunden sein.
In mindestens einer Ausführungsform kann das Fahrzeug 1200 eine oder mehrere Steuerung(en) 1236 beinhalten, wie etwa diejenigen, die hierin in Bezug auf 12 beschrieben sind. Die Steuerung(en) 1236 kann/können für eine Vielfalt von Funktionen verwendet werden. In mindestens einer Ausführungsform kann/können die Steuerung(en) 1236 an beliebige von verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1200 gekoppelt sein und zur Steuerung des Fahrzeugs 1200, der künstlichen Intelligenz des Fahrzeugs 1200, des Infotainments für das Fahrzeug 1200 und/oder anderer Funktionen verwendet werden.
Das Fahrzeug 1200 kann ein Ein-Chip-System (system on a chip - SoC) 1204 umfassen. Das SoC 1204 kann CPU(s) 1206, GPU(s) 1208, Prozessor(en) 1210, Cache(s) 1212, einen oder mehrere Beschleuniger 1214, einen oder mehrere Datenspeicher 1216 und/oder andere nicht veranschaulichte Komponenten und Merkmale beinhalten. Die SoC(s) 1204 können zum Steuern des Fahrzeugs 1200 in einer Vielfalt an Plattformen und Systemen verwendet werden. Die SoC(s) 1204 können beispielsweise in einem System (z. B. dem System des Fahrzeugs 1200) mit einer HD-Karte 1222 kombiniert werden, die über eine Netzwerkschnittstelle 1224 Aktualisierungen der Karte und/oder Updates von einem oder mehreren Servern (z. B. Server 1278 der 15) erhalten kann.
Die CPU(s) 1206 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 1206 können mehrere Kerne und/oder L2-Caches beinhalten. Zum Beispiel können in einigen Ausführungsformen die CPU(s) 1206 acht Kerne in einer kohärenten Mehrprozessorkonfiguration beinhalten. In einigen Ausführungsformen kann/können die CPU(s) 1206 vier Dualkern-Cluster beinhalten, wobei jedes Cluster einen dedizierten L2-Cache (z. B. einen 2 MB großen L2-Cache) aufweist. Die CPU(s) 1206 (z. B. der CCPLEX) kann/können so konfiguriert sein, dass sie einen gleichzeitigen Clusterbetrieb unterstützt/unterstützen, der ermöglicht, dass eine beliebige Kombination der Cluster der CPU(s) 1206 zu einem gegebenen Zeitpunkt aktiv ist.
Die CPU(s) 1206 können Energieverwaltungsfä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 Kern-Taktgeber 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) 1206 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) 1208 können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 1208 können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 1208 können in einigen Beispielen einen erweiterten Tensor-Anweisungssatz verwenden. Die GPU(s) 1208 kann 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) 1208 mindestens acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 1208 können computerbasierte Anwendungsprogrammierschnittstelle(n) (application programming interface(s) - API(s)) verwenden. Zusätzlich können die GPU(s) 1208 eine oder mehrere Parallelrechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 1208 können für die beste Rechenleistung in automobilen und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1208 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung gedacht, und die GPU(s) 1208 können auch mit anderen Verfahren zur Halbleiterherstellung 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 die 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) 1208 kann/können einen Speicher mit hoher Bandbreite (high bandwidth memory - HBM) und/oder ein 16 GB großes 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 direkter Grafik-Speicherzugriff (synchronous graphics random-access memory - SGRAM) verwendet werden, wie etwa ein synchroner direkter Speicherzugriff vom Graphics-Double-Data-Rate-Typ fünf (graphics double data rate type five - GDDR5).
Die GPU(s) 1208 kann/können eine einheitliche Speichertechnologie mit Zugangszä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 (address translation services - ATS) verwendet werden, um es der/den GPU(s) 1208 zu ermöglichen, direkt auf die Seitentabellen der CPU(s) 1206 zuzugreifen. In derartigen Beispielen kann, wenn die Speicherverwaltungseinheit (memory management unit - MMU) der GPU(s) 1208 einen Fehler aufweist, eine Adressübersetzungsanforderung an die CPU(s) 1206 übertragen werden. Als Reaktion darauf können die CPU(s) 1206 in ihren Seitentabellen nach einer Virtuell-zu-Physisch-Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1208 übertragen. Demnach kann die vereinheitlichte Speichertechnologie einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher sowohl der CPU(s) 1206 als auch der GPU(s) 1208 ermöglichen, wodurch die Programmierung der GPU(s) 1208 und Portierung von Anwendungen auf die GPU(s) 1208 vereinfacht werden.
Zusätzlich kann/können die GPU(s) 1208 einen Zugangszähler beinhalten, der die Häufigkeit des Zugangs der GPU(s) 1208 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugangszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Das/die SoC(s) 1204 kann/können eine beliebige Anzahl von Cache(s) 1212 beinhalten, einschließlich der hier beschriebenen. Der/die Cache(s) 1212 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 1206 als auch der/den GPU(s) 1208 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 1206 als auch der/den GPU(s) 1208 verbunden ist). Der/die Cache(s) 1212 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) 1204 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) beinhalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 1200 - wie z. B. der Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus können die SoC(s) 1204 eine oder mehrere Fließkommaeinheiten (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) 1206 und/oder GPU(s) 1208 integriert sind.
Das SoC 1204 kann einen oder mehrere Beschleuniger 1214 beinhalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel können das/die SoC(s) 1204 einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher beinhalten kann. Der großer On-Chip-Speicher (z. B. 4 MB SRAM) kann einen Hardware-Beschleunigungscluster zur Beschleunigung neuronaler Netzwerke und anderer Berechnungen ermöglichen. Der Hardwarebeschleunigungscluster kann verwendet werden, um die GPU(s) 1208 zu ergänzen und einige der Aufgaben der GPU(s) 1208 auszulagern (um z. B. mehr Zyklen der GPU(s) 1208 zum Durchführen anderer Aufgaben freizumachen). Als Beispiel können der/die Beschleuniger 1214 für zielgerichtete Arbeitslasten (z. B. Wahrnehmung, neuronale Faltungsnetzwerke (CNNs usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs beinhalten, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetzwerke (RCNNs) und Fast-RCNNs (z. B. für die Objekterkennung).
Der/die Beschleuniger 1214 können (z. B. Hardware-Beschleunigungscluster) (einen) Deep-Learning-Beschleuniger (deep learning accelerator(s) - DLA(s)) beinhalten. Die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPU(s)) beinhalten, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Vorgänge pro Sekunde für Deep-Learning-Anwendungen und -Ableitung 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 Netzwerken und Fließkommavorgängen sowie für die Ableitung optimiert sein. Das Design der DLA(s) kann mehr Performance pro Millimeter bereitstellen als eine Allgemeinzweck-GPU und übertrifft typischerweise 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 Netzwerke, 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 Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung 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.
Der/die DLA(s) kann/können jede beliebige Funktion der GPU(s) 1208 durchführen und durch Verwenden eines Inferenzbeschleunigers kann ein Gestalter zum Beispiel entweder den/die DLA(s) oder die GPU(s) 1208 für jede beliebige Funktion anzielen. Zum Beispiel kann der Designer die Verarbeitung von CNNs und Fließkommavorgängen auf DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1208 und/oder anderen Beschleuniger(n) 1214 überlassen.
Der/die Beschleuniger 1214 (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 konstruiert und konfiguriert sein. Die PVA(s) können ein Gleichgewicht zwischen Performance und Flexibilität bereitstellen. Zum Beispiel können alle PVA(s) ohne Einschränkung eine beliebige Anzahl von Reduced-Instruction-Set-Computer(RISC)-Kerne, direkten Speicherzugriff (direct memory access - DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.
Die RISC-Kerne können mit Bildsensoren (z. B. Bildsensoren einer beliebigen der hierin beschriebenen Kameras), 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 Beispieln 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) 1206 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die zum Bereitstellen der Optimierung des PVA verwendet werden, einschließlich der Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung, ohne darauf beschränkt zu sein. 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 aus 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 anderen Vektorprozessoren ausgeführt wird. In anderen Beispielen können die Vektorprozessoren, die in einem konkreten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität einsetzen. Zum Beispiel kann in einigen Ausführungsformen eine 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 einem 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 1214 (z. B. ein Hardware-Beschleunigungscluster) können ein Netzwerk auf dem Chip für maschinelles Sehen und SRAM beinhalten, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1214 bereitzustellen. In einigen Beispielen kann der On-Chip-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, eine Steuerung und einen Multiplexer beinhalten. Jede Art von Speicher kann 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 Netzwerk auf dem Chip für maschinelles Sehen beinhalten, das den PVA und DLA mit dem Speicher verbindet (z. B. unter Verwendung von APB).
Das Netzwerk auf dem Chip für maschinelles Sehen kann eine Schnittstelle beinhalten, die vor der Übertragung eines beliebigen Steuersignals/einer beliebigen Adresse/ beliebiger Daten bestimmt, dass sowohl der PVA als auch der 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 kann das SoC 1204 einen Echtzeit-Hardware-Beschleuniger für die Raytracing-Überwachung beinhalten, wie in der am 10. August 2018 eingereichten US-Patentanmeldung Nr. 16/101,232 beschrieben. Der Echtzeitstrahlverfolgungs-Hardware-Beschleuniger kann verwendet werden, um schnell und effizient 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 1214 (z. B. der Hardware-Beschleunigercluster) weisen ein breites Spektrum von Verwendungen für das autonome Fahren auf. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungs-Level im ADAS und in autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten eines PVA passen gut zu algorithmischen 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. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs also dafür ausgelegt, klassische Computer-Vision-Algorithmen auszuführen, da sie effizient bei der Objekterkennung sind und mit ganzzahligen mathematischen Verfahren arbeiten.
Zum Beispiel, gemäß einer Ausführungsform der Technologie, wird 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. mit 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 Netzwerk auszuführen, um die Steuerung und Fahrsicherheit zu verbessern, einschließlich zum Beispiel ein neuronales Netzwerk, 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. Anhand dieses Konfidenzwerts kann das System ferner entscheiden, welche Erkennungen als echte positive Erkennungen und welche als falsch positive Erkennungen betrachtet werden sollten. Das System kann zum Beispiel einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die den Schwellenwert überschreiten, als echte 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 Entdeckungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Konfidenzwerts ausführen. Das neuronale Netzwerk kann als Eingabe zumindest eine Teilmenge von Parametern verwenden, wie etwa die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 1266, die mit der Ausrichtung des Fahrzeugs 1200 korreliert, die Entfernung, die Schätzung der 3D-Position der Aufgabe, die vom neuronalen Netzwerk und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 1264 oder RADAR-Sensor(en) 1260) erhalten wird, und andere.
Das/die SoC(s) 1204 kann/können einen oder mehrere Datenspeicher 1216 (z. B. Speicher) beinhalten. Der/die Datenspeicher 1216 kann/können On-Chip-Speicher des/der SoC(s) 1204 sein, der neuronale Netzwerke 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) 1216 groß genug sein, um mehrere Instanzen von neuronalen Netzwerken zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1216 können L2 oder L3 Cache(s) 1212 beinhalten. Der Verweis auf den/die Datenspeicher 1216 kann einen Verweis auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 1214 zugeordnet ist, wie hier beschrieben.
Das/die SoC(s) 1204 kann/können einen oder mehrere Prozessor(en) 1210 beinhalten (z. B. eingebettete Prozessoren). Der/die Prozessor(en) 1210 können einen Booting- und Energieverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Teilsystem sein kann, um die Hochfahr-Leistungs- und - verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Booting- und Leistungsverwaltungsprozessor kann ein Teil der Hochfahr-Sequenz des/der SoC(s) 1204 sein und Laufzeit-Energieverwaltungsdienste bereitstellen. Der Hochfahr- und Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen mit niedriger Leistung, Verwaltung der Thermik und Temperatursensoren des/der SoC(s) 1204 und/oder Verwaltung der Stromzustände des/der SoC(s) 1204 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und die SoC(s) 1204 können Ringoszillatoren verwenden, um Temperaturen von CPU(s) 1206, GPU(s) 1208 und/oder Beschleuniger(n) 1214 zu erkennen. Falls bestimmt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Hochfahr- und Energieverwaltungsprozessor dann in eine Temperaturfehlerroutine eintreten und die SoC(s) 1204 in einen Zustand mit niedrigerer Leistung versetzen und/oder das Fahrzeug 1200 in einen Modus des Fahrens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 1200 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 1210 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.
Die Prozessor(en) 1210 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. Timer und Unterbrechungscontroller), verschiedene E/A-Steuerungsperipheriegeräte und Routing-Logik beinhalten.
Die Prozessor(en) 1210 können ferner eine Sicherheitscluster-Engine beinhalten, die ein dediziertes Prozessorteilsystem zum Handhaben der Sicherheitsverwaltung für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer, einen Unterbrechungscontroller 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) 1210 können ferner eine Echtzeitkamera-Engine beinhalten, die ein dediziertes Prozessorteilsystem zur Handhabung der Echtzeitkameraverwaltung beinhalten kann.
Die Prozessor(en) 1210 können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
Die Prozessor(en) 1210 können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die durch eine Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Fenster des Wiedergabeprogramms zu erzeugen. Der Videobildkompositor kann eine Objektivverzeichnungskorrektur an den Weitsichtkamera(s) 1270, Rundumkamera(s) 1274 und/oder kabineninternen Überwachungskamerasensoren durchführen. Ein kabineninterner Überwachungskamerasensor wird vorzugsweise durch ein neuronales Netzwerk ü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, EMails 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 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. Zum Beispiel wo 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. Wo ein Bild oder ein Abschnitt eines Bildes keine Bewegung enthält, kann die vom Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu unterdrücken.
Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereoentzerrung an den eingegebenen Stereolinsen-Frames durchführt. Der Videobildkompositor kann ferner für die Benutzerschnittstellenzusammensetzung verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1208 nicht zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Auch wenn die GPU(s) 1208 eingeschaltet ist/sind und aktiv 3D-Rendering durchführt/durchführen, kann der Videobildkompositor verwendet werden, um die GPU(s) 1208 zu entlasten und so die Leistung und Reaktionsfähigkeit zu verbessern.
Das/die SoC(s) 1204 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) 1204 kann/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/die SoC(s) 1204 können ferner eine breite Palette von Peripherieschnittstellen beinhalten, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, Energieverwaltungs- und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 1204 kann/können verwendet werden, um Daten von Kameras (z. B. über Gigabit Multimedia Serial Link und Ethernet verbunden), Sensoren (z. B. LIDAR-Sensor(en) 1264, RADAR-Sensor(en) 1260 usw., die über Ethernet verbunden sein können), Daten von dem Bus 1202 (z. B. Geschwindigkeit des Fahrzeugs 1200, Lenkradposition usw.), Daten von dem/den GNSS-Sensor(en) 1258 (z. B. über Ethernet oder CAN-Bus verbunden) zu verarbeiten. Das/die SoC(s) 1204 kann/können ferner dedizierte Hochleistungssteuerungen für die Massenspeicherung beinhalten, die ihre eigenen DMA-Engines beinhalten können und die verwendet werden können, um die CPU(s) 1206 von Routineaufgaben der Datenverwaltung zu befreien.
Das/die SoC(s) 1204 kann/können eine End-to-End-Plattform mit einer flexiblen Architektur sein, das Automatisierungs-Level 3-5 überspannt, wodurch eine umfassende funktionale Sicherheitsarchitektur bereitgestellt wird, die Computer-Vision- und ADAS-Techniken für Diversität und Redundanz nutzt und effizient verwendet und eine Plattform für einen flexiblen, zuverlässigen Fahr-Software-Stack sowie Deep-Learning-Tools bereitstellt. Das/die SoC(s) 1204 können schneller, zuverlässiger und sogar energieeffizienter und raumeffizienter sein als herkömmliche Systeme. Zum Beispiel kann der/können die Beschleuniger 1214 in Kombination mit der/den CPU(s) 1206, der/den GPU(s) 1208 und dem/den Datenspeicher(n) 1216 eine schnelle, effiziente Plattform für autonome Fahrzeuge des Levels 3-5 bereitstellen.
Die Technologie stellt somit Fähigkeiten 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 etwa 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 jedoch 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-Beschleunigungclusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netzwerke und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. GPU(s) 1220) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netzwerk nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk beinhalten, 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 Netzwerke 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 Netzwerken 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 Netzwerk über mehrere Frames hinweg betrieben wird und die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Nichtvorhandensein) von blinkenden Lichtern informiert. Alle drei neuronalen Netzwerke können simultan laufen, wie etwa innerhalb des DLA und/oder auf den GPU(s) 1208.
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 1200 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) 1204 Sicherheit gegen Diebstahl und/oder Carjacking bereit.
In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Rettungsfahrzeugen Daten von Mikrofonen 1296 verwenden, um Sirenen von Notfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren verwenden, um Sirenen zu erkennen und manuell Merkmale zu extrahieren, verwenden die SoC(s) 1204 das CNN für die Klassifizierung von Umwelt- und Stadtgeräuschen sowie für die Klassifizierung visueller 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 geschult werden, um Einsatzfahrzeuge zu identifizieren, die für den lokalen Einsatzbereich des Fahrzeugs spezifisch sind, wie durch GNSS-Sensor(en) 1258 identifiziert. Folglich versucht das CNN zum Beispiel, wenn es in Europa betrieben wird, europäische Sirenen zu erkennen, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Rettungsfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Rettungsfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, zur Seite der Straße zu fahren, das Fahrzeug abzustellen und/oder das Fahrzeug mit Hilfe der Ultraschallsensoren 1262 im Leerlauf laufen zu lassen, bis das Rettungsfahrzeug vorbeifährt.
Das Fahrzeug kann eine CPU(s) 1218 (z. B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) an das/die SoC(s) 1204 gekoppelt sein kann/können. Die CPU(s) 1218 kann/können zum Beispiel einen X86-Prozessor beinhalten. Die CPU(s) 1218 kann/können dazu verwendet werden, eine beliebige einer Vielfalt von Funktionen durchzuführen, einschließlich zum Beispiel des Vermittelns potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und den SoC(s) 1204 und/oder des Überwachens des Status und Zustands der Steuerung(en) 1236 und/oder eines Infotainment-SoC 1230.
Das Fahrzeug 1200 kann eine GPU(s) 1220 (z. B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitsverbindung (z. B. NVLINK von NVIDIA) an das/die SoC(s) 1204 gekoppelt sein kann/können. Die GPU(s) 1220 können eine zusätzliche Funktionalität für künstliche Intelligenz bereitstellen, wie etwa durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netzwerke, und sie können zum Trainieren und/oder Aktualisieren neuronaler Netze auf Grundlage von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 1200 verwendet werden.
Das Fahrzeug 1200 kann ferner die Netzwerkschnittstelle 1224 beinhalten, die drahtlose Antenne(n) 1226 beinhalten kann (z. B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie etwa eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 1224 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit (einem) Server(n) 1278 und/oder anderen Netzwerkvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z. B. Client-Vorrichtungen von Fahrgästen) 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 Netzwerke und über das Internet) hergestellt werden. Direkte Verbindungen können unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung bereitgestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 1200 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1200 (z. B. Fahrzeuge vor, seitlich von und/oder hinter dem Fahrzeug 1200) bereitstellen. Die vorgenannte Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitssteuerungsfunktionalität des Fahrzeugs 1200 sein.
Die Netzwerkschnittstelle 1224 kann ein SoC beinhalten, das eine Modulations- und Demodulationsfunktionalität bereitstellt und es den Steuerungen 1236 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 1224 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 Radiofrequenz-Front-End-Funktionalität von einem separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
Das Fahrzeug 1200 kann ferner einen oder mehrere Datenspeicher 1228 beinhalten, die eine Speicherung außerhalb des Chips (z. B. außerhalb der SoC(s) 1204) beinhalten können. Der/die Datenspeicher 1228 können ein oder mehrere Speicherelemente beinhalten, darunter RAM, SRAM, DRAM, VRAM, Blitz, Festplatten und/oder andere Komponenten und/oder Vorrichtungen, die mindestens ein Datenbit speichern können.
Das Fahrzeug 1200 kann ferner GNSS-Sensor(en) 1258 (z. B. GPS- und/oder unterstützte GPS-Sensoren) beinhalten, um bei Funktionen zur Kartierung, Wahrnehmung, Erzeugung des Belegungsgitters und/oder Pfadplanung zu helfen. Es kann eine beliebige Anzahl von GNSS-Sensor(en) 1258 verwendet werden, einschließlich zum Beispiel und ohne Einschränkung eines GPS unter Verwendung eines USB-Anschlusses mit einer Ethernet-zu-Seriell-Brücke (RS-232).
In mindestens einer Ausführungsform kann das Fahrzeug 1200 ferner RADAR-Sensor(en) 1260 beinhalten. Der/die RADAR-Sensor(en) 1260 kann/können vom Fahrzeug 1200 zur Fahrzeugerkennung mit großer Reichweite verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die RADAR-Funktionssicherheitslevel können ASIL B sein. Der/die RADAR-Sensor(en) 1260 kann/können den CAN-Bus und/oder den Bus 1202 (z. B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 1260 erzeugt wurden) zur Steuerung und zum Zugang auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugang auf Rohdaten über Ethernet erfolgt. Eine große Vielfalt von RADAR-Sensortypen kann verwendet werden. Zum Beispiel und ohne Einschränkung können die RADAR-Sensor(en) 1260 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
Der/die RADAR-Sensor(en) 1260 kann/können unterschiedliche Konfigurationen beinhalten, wie etwa lange Reichweite mit schmalem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, Seitenabdeckung mit kurzer Reichweite usw. In einigen Beispielen kann RADAR mit langer Reichweite zur Funktionalität der adaptiven Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Die RADAR-Sensoren 1260 können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und von ADAS-Systemen zur Notbremsunterstützung und Kollisionswarnung verwendet werden. RADAR-Systeme mit großer Reichweite 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 1200 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 1200 einfahren oder diese verlassen, schnell zu erkennen.
RADAR-Systeme mit mittlerer Reichweite können als ein Beispiel eine Reichweite von bis zu 1260 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1250 Grad (hinten) beinhalten. RADAR-Systeme mit kurzer Reichweite können ohne Einschränkung RADAR-Sensoren beinhalten, die für die Installation an beiden Enden des hinteren Stoßfängers konstruiert 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.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Spurwechselassistenz verwendet werden.
Das Fahrzeug 1200 kann ferner (einen) Ultraschallsensor(en) 1262 beinhalten. Der/die Ultraschallsensor(en) 1262, die vorne, hinten und/oder an den Seiten des Fahrzeugs 1200 positioniert sein können, können als Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsgitters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 1262 verwendet werden, und verschiedene Ultraschallsensoren 1262 können für unterschiedliche Erkennungsbereiche (z. B. 2,5 m, 4 m) eingesetzt werden. Der/die Ultraschallsensor(en) 1262 können bei funktionellen Sicherheitslevels von ASIL B arbeiten.
In mindestens einer Ausführungsform kann das Fahrzeug 1200 LIDAR-Sensor(en) 1264 beinhalten. Der/die LIDAR-Sensor(en) 1264 können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1264 kann/können dem funktionalen Sicherheits-Level ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 1200 mehrere LIDAR-Sensoren 1264 (z. B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (z. B. um Daten an einen Gigabit-Ethernet-Switch zu liefern).
In einigen Beispielen können die LIDAR-Sensor(en) 1264 dazu in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld bereitzustellen. Handelsübliche LIDAR-Sensor(en) 1264 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 1264 verwendet werden. In solchen Beispielen können der/die LIDAR-Sensor(en) 1264 als eine kleine Vorrichtung implementiert werden, die in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1200 eingebettet werden kann. Der/die LIDAR-Sensor(en) 1264 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. Die an der Front montierte(n) LIDAR-Sensor(en) 1264 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-Blitz-LIDAR, verwendet werden. 3D-Blitz-LIDAR verwendet einen Blitz eines Lasers als eine Übertragungsquelle, um die Umgebung des Fahrzeugs bis zu ungefähr 200 m zu erleuchten. Eine Blitz-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. Blitz-LIDAR kann ermöglichen, dass mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. In einigen Beispielen können vier Blitz-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1200. Verfügbare 3D-Blitz-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 Blitz-LIDAR-Vorrichtung(en) können einen fünf-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und können das reflektierte Laserlicht in Form von 3D-Reichweitenpunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Blitz-LIDAR und weil Blitz-LIDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, ist/sind der/die LIDAR-Sensor(en) 1264 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.
Das Fahrzeug kann ferner IMU-Sensor(en) 1266 beinhalten. Der/die IMU-Sensor(en) 1266 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1200 befinden. Der/die IMU-Sensor(en) 1266 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) 1266 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 1266 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten können.
In einigen Ausführungsformen können die IMU-Sensor(en) 1266 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-electromechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und weiterentwickelte Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. Demnach kann der/können die IMU-Sensor(en) 1266 es dem Fahrzeug 1200 in einigen Beispielen ermöglichen, den Kurs zu schätzen, ohne dass eine Eingabe von einem Magnetsensor erforderlich ist, indem die Geschwindigkeitsänderungen von GPS zu dem/den IMU-Sensor(en) 1266 direkt beobachtet und korreliert werden. In einigen Beispielen können die IMU-Sensor(en) 1266 und GNSS-Sensor(en) 1258 in einer einzelnen integrierten Einheit kombiniert sein.
Das Fahrzeug kann ein oder mehrere Mikrofon(e) 1296 in dem und/oder um das Fahrzeug 1200 platziert beinhalten. Die Mikrofone 1296 können unter anderem zur Erkennung und Identifizierung von Rettungsfahrzeugen verwendet werden.
Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, zu denen Stereokamera(s) 1268, Weitwinkelkamera(s) 1270, Infrarotkamera(s) 1272, Rundumkamera(s) 1274, Kamera(s) 1298 mit langer und/oder mittlerer Reichweite und/oder andere Kameratypen gehören. Die Kameras können verwendet werden, um Bilddaten um die gesamte Peripherie des Fahrzeugs 1200 herum zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen für das Fahrzeug 1200 ab, und jede beliebige Kombination von Kameratypen kann verwendet werden, um die notwendige Abdeckung um das Fahrzeug 1200 herum 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 zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier mit Bezug auf 12 und 13 näher beschrieben.
Das Fahrzeug 1200 kann ferner (einen) Schwingungssensor(en) 1242 beinhalten. Der/die Vibrationssensor(en) 1242 können Vibrationen von Komponenten des Fahrzeugs, wie z. B. der 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 1242 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 1200 kann ein ADAS-System 1238 beinhalten. Das ADAS-System 1238 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 1238 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) 1260, LIDAR-Sensor(en) 1264 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können eine ACC in Längsrichtung und/oder eine ACC in Querrichtung beinhalten. Das Längs-ACC-System steuert und überwacht den Abstand zu einem anderen Fahrzeug, das sich unmittelbar vor dem Fahrzeug 1200 befindet, und stellt die Geschwindigkeit des Fahrzeugs automatisch ein, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC führt eine Abstandshaltung durch und rät dem Fahrzeug 1200, die Fahrspuren zu wechseln, wenn dies erforderlich ist. Das Quer-ACC-System ist mit anderen ADAS-Anwendungen, wie etwa LC und CWS, verbunden.
Die CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1224 und/oder die drahtlose(n) Antenne(n) 1226 von anderen Fahrzeugen über eine drahtlose Verknüpfung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verknüpfungen können durch eine Fahrzeug-zu-Fahrzeug(V2V)-Kommunikationsverbindung, während indirekte Verknüpfungen durch eine Infrastruktur-zu-Fahrzeug(I2V)-Kommunikationsverbindungen bereitgestellt werden 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 1200), während das Kommunikationskonzept 12V Informationen über den weiteren vorausfahrenden Verkehr liefert. CACC-Systeme können entweder eines oder beides von 12V- und V2V-Informationsquellen beinhalten. Angesichts der Informationen über Fahrzeuge vor dem Fahrzeug 1200 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 ausgelegt, dass sie den Fahrer vor einer Gefahr warnen, so dass er entsprechende Maßnahmen ergreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder RADAR-Sensor(en) 1260, 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. FCW-Systeme können eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-Systeme erkennen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und kann 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 vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1260 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, 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 stellen optische, akustische und/oder taktile Warnungen bereit, wie z. B. Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 1200 die Fahrspurmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein beabsichtigtes Verlassen der Fahrspur durch Betätigen des Blinkers anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC verbunden sind, der elektrisch mit dem Fahrer-Feedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme stellen eine Lenkeingabe oder Bremsung bereit, um das Fahrzeug 1200 zu korrigieren, falls das Fahrzeug 1200 beginnt, die Spur zu verlassen.
BSW-Systeme erkennen 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 bereitstellen, wenn der Fahrer einen Blinker setzt. BSW-Systeme können (eine) nach hinten und zur Seite gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1260 verwenden, die an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, das heißt elektrisch an eine Rückführung des Fahrers gekoppelt, wie etwa eine Anzeige, einen Lautsprecher und/oder eine schwingende Komponente.
RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb der Reichweite der Heckkamera erkannt wird, wenn das Fahrzeug 1200 rückwärts fährt. Einige RCTW-Systeme beinhalten das AEB-System, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Zusammenstoß zu vermeiden. Die RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 1260 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.
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 1200 muss das Fahrzeug 1200 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 1236 oder einer zweiten Steuerung 1236) beachtet. In einigen Ausführungsformen kann das ADAS-System 1238 beispielsweise ein Backup- und/oder sekundärer Computer sein, der Wahrnehmungsinformationen für ein Rationalitätsmodul eines Backup-Computers bereitstellt. Der Rationalitätsmonitor des Backup-Computers kann eine redundante, diverse Software auf Hardware-Komponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 1238 können für eine Überwachungs-MCU bereitgestellt werden. Wenn die Ausgaben des primären und des sekundären Computers miteinander in Konflikt geraten, muss die Kontroll-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 Kontroll-MCU eine Konfidenzbewertung bereitstellt, welche die Konfidenz des primären Computers in das gewählte Ergebnis angibt. Wenn die Konfidenzbewertung einen Schwellenwert überschreitet, kann die Kontroll-MCU der Führung des primären Computers folgen, unabhängig davon, ob der sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. Wo die Konfidenzbewertung den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse angeben (z. B. einen Widerspruch), kann die Kontroll-MCU zwischen den Computern vermitteln, um ein geeignetes Resultat zu bestimmen.
Die Kontroll-MCU kann so konfiguriert sein, dass sie ein neuronales Netzwerk/neuronale Netzwerke 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 Netzwerk/die neuronalen Netzwerke in der Kotroll-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 RADAR-basiertes FCW-System ist, neuronale Netz(e) in der Kontroll-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. Ähnlich, wenn der sekundäre Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netzwerk in der Kontroll-MCU 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 Netzwerke beinhalten, die auf der Kontroll-MCU laufen, kann die Kontroll-MCU mindestens eine DLA oder GPU beinhalten, die für die Ausführung des oder der neuronalen Netzwerke mit zugewiesenem Speicher geeignet ist. In bevorzugten Ausführungsformen kann eine Kontroll-MCU eine Komponente eines oder mehrerer SoC(s) 1204 beinhalten und/oder als solche beinhaltet sein.
In anderen Beispielen kann das ADAS-System 1238 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung der traditionellen Regeln des maschinellen Sehens durchführt. Als solcher kann der sekundäre Computer klassische Regeln des maschinellen Sehens (wenn-dann) verwenden und kann das Vorhandensein eines neuronalen Netzwerks/von neuronalen Netzwerken in der Kontroll-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 1238 in einen Wahrnehmungsblock des primären Computers und/oder in einen Block für dynamische Fahr-Tasks des primären Computers eingespeist werden. Wenn das ADAS-System 1238 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 Netzwerk aufweisen, das trainiert wird und somit das Risiko von falsch positiven Ergebnissen reduziert, wie hierin beschrieben.
Das Fahrzeug 1200 kann außerdem das Infotainment-SoC 1230 (z. B. ein Fahrzeug-Infotainment-System (in-vehicle infotainment - lVI)) 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 1230 kann eine Kombination aus Hardware und Software beinhalten, die verwendet werden kann, um dem Fahrzeug 1200 Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkverbindungsfähigkeit (z. B. LTE, WiFi 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 1230 kann zum Beispiel Radios, Plattenspieler, Navigationssysteme, Videowiedergabevorrichtungen, USB- und Bluetooth-Verbindungsfähigkeit, Carputer, In-Car-Entertainment, WiFi, Audiosteuerelemente am Lenkrad, ein Freisprech-Sprachsteuerelement, eine Heads-up-Anzeige (heads-up display - HUD), eine HMI-Anzeige 1234, 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 1230 kann außerdem dazu verwendet werden, Informationen (z. B. visuell und/oder hörbar) für Benutzer des Fahrzeugs bereitzustellen, z. B. Informationen aus dem ADAS-System 1238, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsdaten (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
Das Infotainment-SoC 1230 kann GPU-Funktionen beinhalten. Der Infotainment-SoC 1230 kann über den Bus 1202 (z. B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 1200 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 1230 an eine Überwachungs-MCU gekoppelt sein, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuerung(en) 1236 (z. B. primäre und/oder Reserve-Computer des Fahrzeugs 1200) ausfallen. In einem solchen Beispiel kann der Infotainment-SoC 1230 das Fahrzeug 1200 in einen Chauffeur-zu-Safe-Stop-Modus versetzen, wie hier beschrieben.
Das Fahrzeug 1200 kann ferner ein Kombiinstrument 1232 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) beinhalten. Das Kombiinstrument 1232 kann eine Steuerung und/oder einen Supercomputer (z. B. eine diskrete Steuerung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 1232 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 1230 und dem Kombiinstrument 1232 geteilt werden. Mit anderen Worten kann das Kombiinstrument 1232 als Teil des Infotainment-SoC 1230 eingeschlossen sein oder umgekehrt.
Wie oben erwähnt, kann die Automobil-Plattform 100 (siehe 1) in zumindest einigen Ausführungsformen eine Komponente des autonomen Fahrzeugs 1200 sein. In solchen Ausführungsformen beinhalten die Steuerung(en) 1236 das Automobil-SoC 104. Zum Beispiel kann der automobile SoC 104 als einer der SoC 1204 implementiert werden.
15 ist ein Systemdiagramm für die Kommunikation zwischen (einem) Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 1200 aus 12 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 1276 kann Server 1278, Netzwerk(e) 1290 und Fahrzeuge, einschließlich des Fahrzeugs 1200, beinhalten. Der/die Server 1278 kann/können eine Vielzahl von GPUs 1284(A)-1284(H) (hier gemeinsam als GPUs 1284 bezeichnet), PCle-Switches 1282(A)-1282(H) (hier gemeinsam als PCle-Switches 1282 bezeichnet) und/oder CPUs 1280(A)-1280(B) (hier gemeinsam als CPUs 1280 bezeichnet) beinhalten. Die GPUs 1284, die CPUs 1280 und die PCle-Switches können mit Hochgeschwindigkeitsverbindungen miteinander verbunden sein, wie zum Beispiel und ohne Einschränkung von NVIDIA entwickelten NVLink-Schnittstellen 1288 und/oder PCle-Verbindungen 1286. In einigen Beispielen sind die GPUs 1284 über NVLink und/oder NVSwitch als SoC verbunden und die GPUs 1284 und die PCIe-Switches 1282 sind über PCle-Verbindungen verbunden. Obwohl acht GPUs 1284, zwei CPUs 1280 und zwei PCIe-Switches veranschaulicht sind, soll dies keine Einschränkung darstellen. In Abhängigkeit von der Ausführungsform kann jeder des/der Server(s) 1278 eine beliebige Anzahl von GPUs 1284, CPUs 1280 und/oder PCIe-Switches beinhalten. Zum Beispiel können der/die Server 1278 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1284 beinhalten.
Der/die Server 1278 können über die Netzwerk(e) 1290 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 1278 können über die Netzwerk(e) 1290 und an die Fahrzeuge neuronale Netzwerke 1292, aktualisierte neuronale Netzwerke 1292 und/oder Karteninformationen 1294 übertragen, einschließlich Informationen über Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 1294 können Aktualisierungen für die HD-Karte 1222 beinhalten, wie z. B. Informationen zu Baustellen, Schlaglöchern, Umwegen, Überschwemmungen und/oder anderen Hindernissen. In einigen Beispielen können die neuronalen Netzwerke 1292, aktualisierten neuronalen Netzwerke 1292 und/oder Karteninformationen 1294 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) 1278 und/oder anderen Servern) durchgeführt wurde.
Der/die Server 1278 können verwendet werden, um Modelle des maschinellen Lernens (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. 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 Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken durchgeführt werden, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, 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. Sobald die Modelle des maschinellen Lernens trainiert sind, können die Modelle des maschinellen Lernens durch Fahrzeuge verwendet werden (z. B. über die Netzwerk(e) 1290 an Fahrzeuge übertragen werden) und/oder die Modelle des maschinellen Lernens können durch den/die Server 1278 verwendet werden, um Fahrzeuge aus der Ferne zu überwachen.
In einigen Beispielen kann der/können die Server 1278 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netzwerke zum intelligenten Echtzeit-Inferenzieren anwenden. Der/die Server 1278 können Deep-Learning-Supercomputer und/oder dedizierte Kl-Computer beinhalten, die von GPU(s) 1284 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen kann/können der/die Server 1278 jedoch eine Deep-Learning-Infrastruktur beinhalten, die nur CPU-angetriebene Rechenzentren verwendet.
Die Deep-Learning-Infrastruktur der Server 1278 kann eine schnelle Echtzeit-Inferenz ermöglichen und diese Funktion nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 1200 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen vom Fahrzeug 1200 erhalten, wie z. B. eine Abfolge von Bildern und/oder Objekten, die das Fahrzeug 1200 in dieser Abfolge von Bildern lokalisiert hat (z. B. durch Computervision und/oder andere Techniken zur Klassifizierung von Machine-Learning-Objekten). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk ausführen, um Objekte zu identifizieren und sie mit Objekten zu vergleichen, die durch das Fahrzeug 1200 identifiziert wurden, und falls die Ergebnisse nicht übereinstimmen und die Deep-Learning-Infrastruktur zu dem Schluss kommt, dass die Kl in dem Fahrzeug 1200 eine Fehlfunktion aufweist, dann kann der/können die Server 1278 ein Signal an das Fahrzeug 1200 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 1200 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Zum Inferenzieren kann der/können die Server 1278 die GPU(s) 1284 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) beinhalten. Die Kombination von GPU-angetriebenen Servern und Ableitungsbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, wenn z. B. die Performance weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren angetriebene Server für die Ableitung verwendet werden.
BEISPIELHAFTE RECHENVORRICHTUNG
16 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 1600, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist/sind. Die Rechenvorrichtung 1600 kann ein Verbindungssystem 1602 beinhalten, das die folgenden Vorrichtungen direkt oder indirekt koppelt: Speicher 1604, eine oder mehrere Zentralverarbeitungseinheiten (CPUs) 1606, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1608, eine Kommunikationsschnittstelle 1610, E/A-Ports 1612, Eingabe-/Ausgabekomponenten 1614, eine Stromversorgung 1616, eine oder mehrere Präsentationskomponenten 1618 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 1620.
Auch wenn die verschiedenen Blöcke von 16 als über das Verbindungssystem 1602 mit Leitungen verbunden gezeigt sind, soll dies nicht einschränkend sein und dient nur der Klarheit. Zum Beispiel kann in einigen Ausführungsformen eine Präsentationskomponente 1618, wie etwa eine Anzeigevorrichtung, als E/A-Komponente 1614 angesehen werden (falls die Anzeige z. B. ein Touchscreen ist). Als ein anderes Beispiel können die CPUs 1606 und/oder die GPUs 1608 Speicher beinhalten (z. B. kann der Speicher 1604 für eine Speichervorrichtung zusätzlich zu dem Speicher der GPUs 1608, der CPUs 1606 und/oder anderer Komponenten repräsentativ sein). Mit anderen Worten ist die Rechenvorrichtung aus 16 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 andere Vorrichtungs- oder Systemtypen unterschieden, da alle im Umfang der Rechenvorrichtung der 16 betrachtet werden.
Das Verbindungssystem 1602 kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 1602 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCle-Bus (Peripheral Component Interconnect Express) und/oder einen anderen Bus- oder Verbindungstyp. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als ein Beispiel kann die CPU 1606 direkt mit dem Speicher 1604 verbunden sein. Ferner kann die CPU 1606 direkt mit der GPU 1608 verbunden sein. Wo eine direkte oder Punkt-zu-Punkt-Verbindung zwischen Komponenten besteht, kann das Verbindungssystem 1602 eine PCIe-Verbindung beinhalten, um die Verbindung auszuführen. In diesen Beispielen muss kein PCI-Bus in der Rechenvorrichtung 1600 beinhaltet sein.
Der Speicher 1604 kann eine beliebige Vielfalt computerlesbarer Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf welche die Rechenvorrichtung 1600 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien beinhalten. Beispielhaft und nicht einschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien einschließen.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige und/oder entfernbare und nicht entfernbare Medien beinhalten, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zum Speichern von Informationen wie etwa computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder anderen Daten implementiert werden. Zum Beispiel kann der Speicher 1604 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, Blitz-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das die Rechenvorrichtung 1600 zugreifen kann, sind aber nicht darauf beschränkt. Wie hier verwendet, schließen die Speichermedien für Computer nicht per se Signale ein.
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 sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder geändert wurden, dass Informationen in dem Signal codiert sind. Als Beispiel und nicht einschränkend können die Computerspeichermedien drahtgebundene Medien beinhalten, wie etwa ein drahtgebundenes Netzwerk oder eine direkte drahtgebundene Verbindung, und drahtlose Medien, wie beispielsweise akustische, Funk-, Infrarot- und andere drahtlose Medien. Kombinationen aller Vorstehenden sollen ebenfalls im Umfang computerlesbarer Medien eingeschlossen sein.
Die CPU(s) 1606 kann/können konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1600 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Die CPU(s) 1606 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) beinhalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu handhaben. Die CPU(s) 1606 kann/können einen beliebigen Prozessortyp beinhalten und in Abhängigkeit vom Typ der umgesetzten Rechenvorrichtung 1600 unterschiedliche Prozessortypen beinhalten (z. B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann der Prozessor in Abhängigkeit vom Typ der Rechenvorrichtung 1600 ein Advanced-RISC-Machines(ARM)-Prozessor sein, der unter Verwendung von Reduced-Instruction-Set-Computing (RISC) implementiert ist, oder ein x86-Prozessor, der unter Verwendung von Complex-Instruction-Set-Computing (CISC) implementiert ist. Die Rechenvorrichtung 1600 kann zusätzlich zu einem oder mehreren Mikroprozessoren oder ergänzenden Koprozessoren, wie etwa mathematischen Koprozessoren, eine oder mehrere CPUs 1606 beinhalten.
Zusätzlich oder alternativ zu den CPU(s) 1606 können die GPU(s) 1608 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1600 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Eine oder mehrere der GPU(s) 1608 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 1606) und/oder eine oder mehrere der GPU(s) 1608 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 1608 ein Coprozessor einer oder mehrerer der CPU(s) 1606 sein. Die GPU(s) 1608 können durch die Rechenvorrichtung 1600 verwendet werden, um Grafiken (z. B. 3D-Grafiken) zu rendern oder Universalberechnungen durchzuführen. Zum Beispiel können die GPU(s) 1608 für Universalberechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 1608 können Hunderte oder Tausende von Kernen beinhalten, die in der Lage sind, Hunderte oder Tausende von Softwarethreads gleichzeitig zu handhaben. Die GPU(s) 1608 können Pixeldaten für Ausgabebilder als Reaktion auf das Rendern von Befehlen erzeugen (z. B. Rendern von Befehlen aus der/den CPU(s) 1606, die über eine Host-Schnittstelle empfangen werden). Die GPU(s) 1608 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 1604 beinhaltet sein. Die GPU(s) 1608 können zwei oder mehrere GPUs beinhalten, die parallel arbeiten (z. B. über eine Verbindung). Der Link 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 1608 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) generieren. Jede GPU kann ihren eigenen Speicher beinhalten oder kann Speicher mit anderen GPUs teilen.
Zusätzlich oder alternativ zu den CPU(s) 1606 und/oder den GPU(s) 1608 kann/können die Logikeinheit(en) 1620 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1600 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) 1606, die GPU(s) 1608 und/oder die Logikeinheit(en) 1620 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Abschnitte davon ausführen. Eine oder mehrere der Logikeinheiten 1620 kann/können Teil von und/oder integriert in eine oder mehrere der CPU(s) 1606 und/oder der GPU(s) 1608 sein und/oder eine oder mehrere der Logikeinheiten 1620 kann/können diskrete Komponenten oder anderweitig extern zu der/den CPU(s) 1606 und/oder der/den GPU(s) 1608 sein. In Ausführungsformen können eine oder mehrere der logischen Einheiten 1620 ein Coprozessor einer oder mehrerer der CPU(s) 1606 und/oder einer oder mehrerer der GPU(s) 1608 sein.
Beispiele der Logikeinheit(en) 1620 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 1610 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 1600 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetzwerk, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1610 kann Komponenten und Funktionalität beinhalten, um eine Kommunikation über eine Anzahl unterschiedlicher Netzwerke zu ermöglichen, wie etwa drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weiterverkehrsnetzwerke mit geringem Energieverbrauch (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die E/A-Ports 1612 können es der Rechenvorrichtung 1600 ermöglichen, logisch an andere Vorrichtungen einschließlich der E/A-Komponenten 1614, der Präsentationskomponente(n) 1618 und/oder anderer Komponenten gekoppelt zu sein, von denen einige in die Rechenvorrichtung 1600 eingebaut (z. B. in diese integriert) sein können. Veranschaulichende E/A-Komponenten 1614 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 1614 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 Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie nachstehend genauer beschrieben) implementieren, die einer Anzeige der Rechenvorrichtung 1600 zugeordnet sind. Die Rechenvorrichtung 1600 kann Tiefenkameras, wie etwa stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erkennung beinhalten. Zusätzlich kann die Rechenvorrichtung 1600 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 durch die Rechenvorrichtung 1600 verwendet werden, um immersive augmentierte Realität oder virtuelle Realität zu rendern.
Die Stromversorgung 1616 kann auch eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon beinhalten. Die Stromversorgung 1616 kann der Rechenvorrichtung 1600 Strom bereitstellen, um es den Komponenten der Rechenvorrichtung 1600 zu ermöglichen, zu arbeiten.
Die Präsentationskomponent(en) 1618 können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigearten oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponente(n) 1618 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 1608, der/den CPU(s) 1606 usw.) empfangen und die Daten (z. B. als Bild, Video, Ton usw.) ausgeben.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen wie etwa Programmmodulen, die von einem Computer oder einer anderen Maschine wie etwa einem Personal Data Assistant oder einer anderen Handheld-Vorrichtung ausgeführt 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 Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Rechenvorrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetzwerk verbunden sind, durchgeführt werden.
Mindestens eine Ausführungsform der Offenbarung kann im Hinblick auf die folgenden Klauseln beschrieben werden:

1. Integrierte Schaltung mit ersten und zweiten Abschnitten, wobei der erste Abschnitt einen ersten Timer umfasst, wobei der erste Abschnitt Daten, die mindestens einem Fehler entsprechen, der von einer Vielzahl von Logikblöcken stammt, zu mindestens einem Fehlersignal aggregiert und das mindestens eine Fehlersignal überträgt, wobei der erste Timer startet, wenn das mindestens eine Fehlersignal übertragen und zurückgesetzt wird, wenn die dem mindestens einen Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, wobei der erste Abschnitt ein Timeout-Fehlersignal überträgt, wenn der erste Timer mindestens eine erste vorbestimmte Zeitdauer, die verstrichen ist, anzeigt und die dem mindestens einen Fehler entsprechenden Daten nicht aus dem ersten Abschnitt gelöscht wurden, wobei der zweite Abschnitt zum Empfangen des mindestens einen Fehlersignals und des Timeout-Fehlersignals, wenn das Timeout-Fehlersignal gesendet wurde, wobei der zweite Abschnitt ein externes System benachrichtigt, nachdem das Timeout-Fehlersignal empfangen wurde.
2. Integrierte Schaltung nach Klausel 1, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt löscht, wenn der erste Abschnitt bestimmt, dass mindestens einer der Vielzahl von Logikblöcken den Fehler korrigiert hat, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
3. Integrierte Schaltung nach Klausel 1 oder 2, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt eine oder mehrere Maßnahmen durchführt, die den Fehler korrigieren und die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt löscht, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
4. Integrierte Schaltung nach einer der Klauseln 1-3, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt Fehlerinformationen an einen Speicherort schreibt und den zweiten Abschnitt über einen Schweregrad des Fehlers benachrichtigt, der zweite Abschnitt entscheidet, ob die Fehlerinformationen gelesen werden sollen, basierend zumindest teilweise auf dem Schweregrad des Fehlers, der zweite Abschnitt eine oder mehrere Maßnahmen ausführt, die den Fehler korrigieren, und den ersten Abschnitt benachrichtigt, die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt zu löschen, der erste Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt löscht, nachdem der erste Abschnitt die Benachrichtigung empfangen hat, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht worden sind, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
5. Integrierte Schaltung nach einer der Klauseln 1-4, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt den zweiten Abschnitt über einen Schweregrad des Fehlers benachrichtigt und der zweite Abschnitt das externe System über den Fehler basierend auf dem Schweregrad des Fehlers benachrichtigt.
6. Integrierte Schaltung nach einer der Klauseln 1-5, wobei der zweite Abschnitt einen zweiten Timer umfasst, der startet, wenn der zweite Abschnitt das Timeout-Fehlersignal empfängt, wobei der zweite Timer zurückgesetzt wird, nachdem die dem mindestens einen Fehler entsprechenden Daten von dem zweiten Abschnitt gelöscht wurden, und der zweite Abschnitt wartet, bis der zweite Timer anzeigt, dass mindestens eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor er das externe System benachrichtigt.
7. Integrierte Schaltung nach Klausel 6, wobei der zweite Abschnitt eine oder mehrere Korrekturmaßnahmen durchführt, nachdem er das Timeout-Fehlersignal empfangen hat, und den ersten Abschnitt benachrichtigt, die Daten zu löschen, die dem mindestens einen Fehler entsprechen, wobei der zweite Abschnitt das externe System nicht benachrichtigt, wenn die der zweite Abschnitt den ersten Abschnitt benachrichtigt hat, die Daten zu löschen, die dem mindestens einen Fehler entsprechen, bevor der zweite Timer anzeigt, dass mindestens die zweite vorbestimmte Zeitdauer verstrichen ist.
8. Integrierte Schaltung nach Klausel 7, wobei der erste Abschnitt die Daten, die dem mindestens einen Fehler entsprechen, aus dem ersten Abschnitt löscht, nachdem er die Benachrichtigung erhalten hat, die Daten, die dem mindestens einen Fehler entsprechen, aus dem zweiten Abschnitt zu löschen, der erste Abschnitt dem zweiten Abschnitt mitteilt, dass die Daten, die dem mindestens einen Fehler entsprechen, aus dem ersten Abschnitt gelöscht worden sind, und der zweite Abschnitt die Daten, die dem mindestens einen Fehler entsprechen, aus dem zweiten Abschnitt löscht.
9. Integrierte Schaltung nach einer der Klauseln 1-8, die sich auf einem einzigen Stück Halbleitermaterial befindet.
10. Integrierte Schaltung nach einer der Klauseln 1-9, die einen Abschnitt eines Systems auf einem Chip („SoC“) eines Automobil-Systems implementiert.
11. Integrierte Schaltung nach einer der Klauseln 1-10, wobei der zweite Abschnitt unter einem höheren Risikoklassifizierungs-Level arbeitet als der erste Abschnitt.
12. Integrierte Schaltung nach einer der Klauseln 1-11, wobei das mindestens eine Fehlersignal ein unkorrigiertes Fehlersignal umfasst, die Daten, die dem mindestens einen Fehler entsprechen, Daten umfassen, die einem unkorrigierten Fehler entsprechen, der durch den ersten Abschnitt in das unkorrigierte Fehlersignal aggregiert wird, und die integrierte Schaltung ferner umfasst: einen ersten Signalleiter, um das Timeout-Fehlersignal von dem ersten Abschnitt zu dem zweiten Abschnitt zu leiten; und einen zweiten Signalleiter, um das unkorrigierte Fehlersignal von dem ersten Abschnitt zu dem zweiten Abschnitt zu leiten.
13. Integrierte Schaltung nach Klausel 11, wobei das mindestens eine Fehlersignal ein korrigiertes Fehlersignal umfasst, die Daten, die dem mindestens einen Fehler entsprechen, Daten umfassen, die einem korrigierten Fehler entsprechen, der durch den ersten Abschnitt in das korrigierte Fehlersignal aggregiert wird, und die integrierte Schaltung ferner umfasst: einen dritten Signalleiter zum Leiten des korrigierten Fehlersignals von dem ersten Abschnitt zu dem zweiten Abschnitt.
14. Integrierte Schaltung nach einer der Klauseln 1-13, ferner umfassend: eine Verbindung zwischen dem ersten und dem zweiten Abschnitt zum Übertragen eines Schweregradsignals von dem ersten Abschnitt an den zweiten Abschnitt, wobei das Schweregradsignal einen Schweregrad für jeden der mindestens einen Fehler angibt.
15. Integrierte Schaltung nach einer der Klauseln 1-14, ferner umfassend: eine Vielzahl von Fehleraggregatoren, die jeweils Daten empfangen, die einem oder mehreren Fehlern von mindestens einem der Vielzahl von Logikblöcken entsprechen, die Daten, die dem einen oder den mehreren Fehlern entsprechen, zu einem oder mehreren Fehlersignalen aggregieren und das eine oder die mehreren Fehlersignale an den ersten Abschnitt übertragen, der das eine oder die mehreren Fehlersignale zu dem mindestens einen Fehlersignal aggregiert.
16. Verfahren, umfassend: Empfangen von Daten, die mindestens einem Fehler entsprechen, der jeweils durch mindestens einen Fehler erzeugt wird, der in einem Logikblock der integrierten Schaltung aufgetreten ist, durch die erste Schaltung einer integrierten Schaltung; Zusammenfassen der dem mindestens einen Fehler entsprechenden Daten durch eine erste Schaltung zu mindestens einem Fehlersignal; Übertragen des mindestens einen Fehlersignals durch eine erste Schaltung an eine zweite Schaltung der integrierten Schaltung, wobei die Übertragung einen ersten Timer startet; Bestimmen, durch eine erste Schaltung, dass ein oder mehrere Fehler, die einen bestimmten von mindestens einem Fehler erzeugt haben, korrigiert worden sind; Löschen der Daten, die dem bestimmten Fehler entsprechen, durch eine erste Schaltung, nachdem die erste Schaltung bestimmt, dass der eine oder die mehreren Fehler korrigiert wurden, wobei der erste Timer zurückgesetzt wird, wenn die Daten, die dem mindestens einen Fehler entsprechen, gelöscht wurden; Übertragen eines Timeout-Fehlersignals durch eine erste Schaltung an die zweite Schaltung, wenn der erste Timer anzeigt, dass mindestens eine erste vorbestimmte Zeitdauer verstrichen ist; und Benachrichtigen eines externen Systems durch die zweite Schaltung, nachdem die zweite Schaltung das Timeout-Fehlersignal empfangen hat.
17. Verfahren nach Klausel 16, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch eine erste Schaltung; Bestimmen durch eine erste Schaltung, dass der eine oder die mehreren Fehler durch mindestens einen Logikblock der integrierten Schaltung korrigiert wurden; Informieren der zweiten Schaltung durch eine erste Schaltung, dass die Daten, die dem bestimmten Fehler entsprechen, von der ersten Schaltung gelöscht wurden; und Löschen der dem bestimmten Fehler entsprechenden Daten aus der zweiten Schaltung durch die zweite Schaltung.
18. Verfahren nach den Absätzen 16 oder 17, das ferner umfasst: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch den ersten Absatz; Durchführen einer oder mehrerer Maßnahmen zur Korrektur des einen oder der mehreren Fehler durch den ersten Absatz; Informieren des zweiten Absatzes durch den ersten Absatz, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Absatz gelöscht wurden; und Löschen der dem bestimmten Fehler entsprechenden Daten aus dem zweiten Absatz durch den zweiten Absatz.
19. Verfahren nach einer der Klauseln 16-18, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch die erste Schaltung; Schreiben von Fehlerinformationen an einen Speicherort durch die erste Schaltung; Informieren der zweiten Schaltung durch die erste Schaltung über einen Schweregrad des einen oder der mehreren Fehler; Entscheiden, durch die zweite Schaltung, ob die Fehlerinformationen zumindest teilweise basierend auf dem Schweregrad des einen oder der mehreren Fehler gelesen werden sollen; Durchführen einer oder mehrerer Maßnahmen, die den einen oder die mehreren Fehler korrigieren, durch die zweite Schaltung; Informieren der ersten Schaltung durch die zweite Schaltung, dass der eine oder die mehreren Fehler, die den bestimmten Fehler erzeugt haben, korrigiert worden sind; und Löschen der dem bestimmten Fehler entsprechenden Daten aus der ersten und zweiten Schaltung.
20. Verfahren nach einer der Klauseln 16-19, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch die erste Schaltung; Informieren der zweiten Schaltung durch die erste Schaltung über einen Schweregrad des einen oder der mehreren Fehler; und Benachrichtigen des externen Systems über den Fehler durch die zweite Schaltung basierend auf dem Schweregrad des Fehlers.
21. Verfahren nach einem der Teile 16-20, ferner umfassend: Warten durch die zweite Schaltung, bis ein zweiter Timer anzeigt, dass mindestens eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor das externe System benachrichtigt wird, wobei der zweite Timer startet, wenn die zweite Schaltung das Timeout-Fehlersignal empfängt und zurückgesetzt wird, nachdem die Daten, die dem mindestens einen Fehler entsprechen, von der zweiten Schaltung gelöscht wurden.
22. Verfahren nach Klausel 21, ferner umfassend: Durchführen einer oder mehrerer Korrekturmaßnahmen durch die zweite Schaltung nach dem Empfangen des Timeout-Fehlersignals, wobei die eine oder mehreren Korrekturmaßnahmen den mindestens einen Fehler korrigieren, der jeden der mindestens einen Fehler erzeugt hat; und Löschen der dem mindestens einen Fehler entsprechenden Daten von der ersten und zweiten Schaltung, wobei die zweite Schaltung das externe System nicht benachrichtigt, wenn die dem mindestens einen Fehler entsprechenden Daten von der zweiten Schaltung gelöscht wurden, bevor der zweite Timer dies zumindest anzeigt die zweite vorbestimmte Zeitdauer verstrichen ist.
23. Verfahren nach Klausel 22, wobei das Löschen der Daten, die dem mindestens einen Fehler entsprechen, von der ersten und zweiten Schaltung umfasst: Informieren der ersten Schaltung durch die zweite Schaltung, dass der mindestens eine Fehler jeden der mindestens einen Fehler erzeugt hat wurde korrigiert; Löschen der Daten, die jedem Fehler des mindestens einen Fehlers von der ersten Schaltung entsprechen, durch eine erste Schaltung; Informieren der zweiten Schaltung durch eine erste Schaltung, dass die Daten, die jedem Fehler des mindestens einen Fehlers entsprechen, von der ersten Schaltung gelöscht wurden; und Löschen der Daten, die jedem Fehler des mindestens einen Fehlers entsprechen, durch die zweite Schaltung von der zweiten Schaltung.
24. Das Verfahren nach einer der Klauseln 16-23, wobei sich die integrierte Schaltung auf einem zusammenhängenden Stück Halbleitermaterial befindet.
25. Das Verfahren nach einer der Klauseln 16-24, wobei Integrierte Schaltung einen Abschnitt eines Systems auf einem Chip („SoC“) in einem Automobil-System implementiert.
26. Das Verfahren nach einer der Klauseln 16-25, wobei die erste Schaltung innerhalb einer ersten Spannungsdomäne und einer ersten Taktdomäne arbeitet und die zweite Schaltung innerhalb einer zweiten Spannungsdomäne und einer zweiten Taktdomäne arbeitet, wobei die zweite Spannungsdomäne unterschiedlich ist von der ersten Spannungsdomäne unterscheidet sich die zweite Taktdomäne von der ersten Taktdomäne, und die zweite Schaltung arbeitet auf einem höheren Risikoklassifizierungsniveau als die erste Schaltung.
27. Verfahren nach einem der Teile 16-26, ferner umfassend: Empfangen eines oder mehrerer Fehler von mindestens einem von mehreren Logikblöcken durch jeden einer Vielzahl von Fehleraggregatoren; Erzeugen eines Fehlersignals durch jeden der Vielzahl von Fehleraggregatoren basierend auf dem einen oder den mehreren Fehlern, die von dem Fehleraggregator empfangen wurden; und Übertragen des von dem Fehleraggregator erzeugten Fehlersignals durch jeden der Mehrzahl von Fehleraggregatoren an die erste Schaltung, um dadurch eine Mehrzahl von Fehlersignalen zu übertragen, die den mindestens einen Fehler umfassen, wobei die erste Schaltung die Daten aggregiert, die dem mindestens entsprechen einen Fehler in das mindestens eine Fehlersignal.
28. Eine integrierte Schaltung eines autonomen Fahrzeugs, wobei integrierte Schaltung umfasst: einen Sicherheitsabschnitt, einen Treiberabschnitt, einen ersten Signalleiter und einen Timeout-Signalleiter, wobei der Sicherheitsabschnitt eine Vielzahl von Korrekturmaßnahmen durchführt, um das autonome Fahrzeug in einen sicheren Zustand zu bringen, wobei die Vielzahl von Korrekturmaßnahmen das Übertragen eines ausgehenden Fehlersignals an ein externes System umfasst, wenn der Sicherheitsabschnitt erkennt, dass ein Timeout-Fehler geltend gemacht wurde, der Treiberabschnitt zum Steuern mindestens einer Funktion des autonomen Fahrzeugs, der Treiberabschnitt umfassend einen ersten Timer, der startet, wenn der Treiberabschnitt einen ersten geltend gemachten Fehler in einem Fehlersignal an den Sicherheitsabschnitt überträgt, wobei der erste Timer zurückgesetzt wird, wenn ein zuletzt geltend gemachter Fehler im Treiberabschnitt aufgehoben wird, wobei der Treiberabschnitt den Timeout-Fehler in einem Timeout-Fehlersignal geltend macht, wenn der erste Timer anzeigt, dass mindestens eine erste vorbestimmte Zeitdauer verstrichen ist, der erste Signalleiter, um das Fehlersignal von dem Treiberabschnitt zu dem Sicherheitsabschnitt zu leiten, wobei der Sicherheitsabschnitt einen behaupteten Fehler für jeden behaupteten Fehler in dem Fehlersignal umfasst, und der Timeout-Signalleiter, um das Timeout-Fehlersignal von dem Treiberabschnitt zu dem Sicherheitsabschnitt zu leiten.
29. Integrierte Schaltung nach Klausel 28, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Treiberabschnitt einen Grund für die Behauptung des Fehlers identifiziert, der Treiberabschnitt den Fehler innerhalb des Treiberabschnitts deaktiviert, wenn der Treiberabschnitt einen Logikblock von dem Treiberabschnitt bestimmt, der den Grund für die Behauptung des Fehlers angemessen adressiert hat, der Treiberabschnitt den Sicherheitsabschnitt benachrichtigt, dass der Fehler innerhalb des Treiberabschnitts aufgehoben wurde, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung erhalten hat, dass der Fehler innerhalb des Treiberabschnitts aufgehoben wurde.
30. Integrierte Schaltung nach Klausel 28 oder 29, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Treiberabschnitt einen Grund identifiziert, aus dem der Fehler geltend gemacht wurde, der Treiberabschnitt eine oder mehrere Maßnahmen durchführt, um dadurch den Grund, aus dem der Fehler geltend gemacht wurde, zu adressieren, der Treiberabschnitt den Fehler innerhalb des Treiberabschnitts deaktiviert, der Treiberabschnitt den Sicherheitsabschnitt benachrichtigt, dass der Fehler innerhalb des Treiberabschnitts deaktiviert wurde, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung empfangen hat, dass der Fehler innerhalb des Treiberabschnitts deaktiviert wurde.
31. Integrierte Schaltung nach einer der Klauseln 28-30, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Treiberabschnitt einen Grund für den geltend gemachten Fehlers identifiziert, der Treiberabschnitt Informationen an einen Speicherort schreibt und der Sicherheitsabschnitt über einen Schweregrad des Fehlers benachrichtigt, der Sicherheitsabschnitt entscheidet, ob die Informationen gelesen werden sollen, basierend zumindest teilweise auf dem Schweregrad des Fehlers, der Sicherheitsabschnitt zumindest eine der Vielzahl von Korrekturmaßnahmen durchführt, um dadurch den Grund anzugehen, warum der Fehler geltend gemacht wurde, der Sicherheitsabschnitt dem Treiberabschnitt mitteilt, den Fehler zu deaktivieren, der Treiberabschnitt den Fehler innerhalb des Treiberabschnitts deaktiviert, nachdem der Treiberabschnitt die Benachrichtigung zum Deaktivieren des Fehlers empfangen hat, der Treiberabschnitt dem Sicherheitsabschnitt mitteilt, dass der Fehler innerhalb des Treiberabschnitts deaktiviert ist, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung empfangen hat, dass der Fehler im Trieberteil deaktiviert wurde.
32. Integrierte Schaltung nach einer der Klauseln 28-31, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Treiberabschnitt einen Grund identifiziert, warum der Fehler geltend gemacht wurde, der Treiberabschnitt der Sicherheitsabschnitt über einen Schweregrad des Fehlers benachrichtigt und der Sicherheitsabschnitt das externe System über den Fehler basierend auf dem Schweregrad des Fehlers benachrichtigt.
33. Integrierte Schaltung nach einer der Klauseln 28-32, wobei der Sicherheitsabschnitt einen zweiten Timer umfasst, der startet, wenn der Sicherheitsabschnitt den Timeout-Fehler in dem Timeout-Fehlersignal empfängt, wobei der zweite Timer zurückgesetzt wird, wenn der Sicherheitsabschnitt keine geltend gemachten Fehler mehr umfasst, und der Sicherheitsabschnitt wartet, bis der zweite Timer anzeigt, dass mindestens eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor er das ausgehende Fehlersignal an das externe System überträgt.
34. Integrierte Schaltung nach Klausel 33, wobei der Sicherheitsabschnitt mindestens eine der Vielzahl von Korrekturmaßnahmen durchführt, nachdem er den Timeout-Fehler in dem Timeout-Fehlersignal empfangen hat, und den Treiberabschnitt benachrichtigt, jeden Fehler, der in dem Fehlersignal behauptet wurde, zu deaktivieren, wobei der Sicherheitsabschnitt das ausgehende Fehlersignal nicht überträgt, wenn der Sicherheitsabschnitt den Treiberabschnitt benachrichtigt hat, jeden Fehler, der in dem Fehlersignal behauptet wurde, zu deaktivieren, bevor der zweite Timer anzeigt, dass zumindest die zweite vorbestimmte Zeitdauer verstrichen ist.
35. Integrierte Schaltung nach einer der Klauseln 28-34, die sich auf einem einzigen Stück Halbleitermaterial befindet.
36. Integrierte Schaltung nach einer der Klauseln 28-35, wobei der Sicherheitsabschnitt auf einem höheren Risiko-Level arbeitet als der Treiberabschnitt.
37. Integrierte Schaltung nach einer der Klauseln 28-36, wobei jeder geltend gemachte Fehler im Fehlersignal ein unkorrigierter Fehler ist, das Fehlersignal ein unkorrigiertes Fehlersignal ist, der erste Signalleiter ein unkorrigierter Fehlersignalleiter ist, der Treiberabschnitt geltend gemachte korrigierte Fehler in einem korrigierten Fehlersignal an den Sicherheitsabschnitt überträgt, und die integrierte Schaltung ferner umfasst: einen korrigierten Signalleiter, um das korrigierte Fehlersignal von dem Treiberabschnitt an den Sicherheitsabschnitt zu leiten, wobei der Sicherheitsabschnitt einen geltend gemachten korrigierten Fehler für jeden geltend gemachten korrigierten Fehler in dem korrigierten Fehlersignal umfasst.
38. Integrierte Schaltung nach einer der Klauseln 28-37, ferner umfassend: eine Verbindung zwischen dem Treiber- und Sicherheitsabschnitt zum Übertragen eines Schweregradsignals von dem Trieberteil an den Sicherheitsabschnitt, wobei das Schweregradsignal einen Schweregrad für einen geltend gemachten Fehler in dem Fehlersignal angibt.
39. Integrierte Schaltung nach einer der Klauseln 28-38, ferner umfassend: eine Vielzahl von Fehleraggregatoren, die jeweils einen oder mehrere Fehler von mindestens einem einer Vielzahl von Logikblöcken empfangen, den einen oder die mehreren Fehler zu einem oder mehreren Fehlersignalen zusammenfassen und das eine oder die mehreren Fehlersignale an den Treiberabschnitt übertragen, der das eine oder die mehreren Fehlersignale zu einem Fehlersignal zusammenfasst.

Die Verwendung der Begriffe „ein“ und „eine“ und „der/die/das“ und ähnlicher Bezeichnungen im Zusammenhang mit der Beschreibung offengelegter Ausführungsformen (insbesondere im Zusammenhang mit den folgenden Ansprüchen) ist so auszulegen, dass sie sowohl die Einzahl als auch die Mehrzahl abdeckt, sofern hier nicht anders angegeben oder durch den Kontext eindeutig widerlegt, und nicht als Definition eines Begriffs. Die Begriffe „umfassen“, „aufweisen“, „beinhaltend“ und „enthaltend“ sind, sofern nicht anders angegeben, als offene Begriffe zu verstehen (d. h. „beinhaltend, aber nicht beschränkt auf“). Der Begriff „verbunden“ ist, wenn er unverändert bleibt und sich auf physikalische Verbindungen bezieht, als teilweise oder vollständig in einem Bauteil beinhalten, an ihm befestigt oder mit ihm verbunden zu verstehen, auch wenn etwas dazwischen liegt. Die Nennung von Wertebereichen hierin soll lediglich als ein schnelles Verfahren des einzelnen Bezugnehmens auf jeden getrennten Wert dienen, der in den Bereich fällt, es sei denn, hierin ist etwas anderes angegeben, und jeder getrennte Wert ist in die Beschreibung integriert, als ob er einzeln hierin wiedergegeben wäre. In mindestens einer Ausführungsform ist die Verwendung des Begriffs „Satz“ (z. B. „ein Satz von Objekten“) oder „Teilsatz“ als eine nichtleere Zusammenstellung auszulegen, die ein oder mehrere Elemente umfasst, es sei denn, es ist etwas anderes angemerkt oder dies widerspricht dem Kontext. Sofern nicht anders vermerkt oder durch den Kontext widerlegt, bezeichnet der Begriff „Teilmenge“ einer entsprechenden Menge nicht notwendigerweise eine echte Teilmenge der entsprechenden Menge, sondern Teilmenge und entsprechende Menge können gleich sein.
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. Beispiel: „Element A, Element B, und/oder Element C“ kann 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 beinhalten.
Sofern nicht spezifisch etwas anderes genannt ist oder der Kontext dem eindeutig widerspricht, ist verbindende Sprache, wie etwa Formulierungen der Form „wenigstens eines von A, B und C“ oder „mindestens eines von A, B und C“, andernfalls in dem Kontext zu verstehen, in dem sie allgemein verwendet werden, um darzustellen, dass ein Gegenstand, ein Ausdruck usw. entweder A oder B oder C oder eine beliebige nicht leere Teilmenge des Satzes aus A und B und C sein kann. Zum Beispiel beziehen sich in dem veranschaulichenden Beispiel für einen Satz, der drei Elemente aufweist, die verbindenden Formulierungen „wenigstens eines von A, B und C“ und „mindestens eines von A, B und C“ auf einen beliebigen der folgenden Sätze: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Somit soll derartige verbindende Sprache im Allgemeinen nicht implizieren, dass bestimmte Ausführungen es erforderlich machen, dass mindestens eines von A, mindestens eines von B und mindestens eines von C vorhanden ist. Sofern nichts anderes angemerkt ist oder der Kontext dem widerspricht, gibt der Ausdruck „Vielzahl“ einen Zustand der Pluralität an (z. B. gibt „eine Vielzahl von Gegenständen“ mehrere Gegenstände an). In mindestens einer Ausführungsform beträgt die Anzahl der Objekte in einer Vielzahl mindestens zwei, es können aber auch mehr sein, wenn dies entweder explizit oder durch den Kontext angegeben ist. Sofern nichts anderes genannt ist oder es anderweitig aus dem Kontext ersichtlich ist, bedeutet die Formulierung „auf Grundlage von“ „mindestens zum Teil auf Grundlage von“ und nicht „ausschließlich auf Grundlage von“.
Die Operationen der hier beschriebenen Prozesse können in jeder geeigneten Reihenfolge durchgeführt werden, sofern hier nichts anderes angegeben ist oder der Kontext nicht eindeutig dagegen spricht. In mindestens einer Ausführungsform wird ein Prozess, wie zum Beispiel die hierin beschriebenen Prozesse (oder Variationen und/oder Kombinationen davon), unter der Kontrolle von einem oder mehreren Computersystemen ausgeführt, die mit ausführbaren Anweisungen konfiguriert sind, und ist als Code (z. B. ausführbare Anweisungen, ein oder mehrere Computerprogramme oder eine oder mehrere Anwendungen), die kollektiv auf einem oder mehreren Prozessoren ausgeführt werden, durch Hardware oder Kombinationen davon implementiert. In mindestens einer Ausführungsform wird Code auf einem computerlesbaren Speichermedium gespeichert. In einer Ausführungsform in der Form eines Computerprogramms, das eine Vielzahl von Anweisungen umfasst, die durch einen oder mehrere Prozessoren ausgeführt werden können. In mindestens einer Ausführungsform ist ein computerlesbares Speichermedium ein nichttransitorisches computerlesbares Speichermedium, das transitorische Signale (z. B. eine sich ausbreitende transiente elektrische oder elektromagnetische Übertragung) ausschließt, aber nichttransitorische Datenspeicherschaltungen (z. B. Puffer, Cache und Warteschlangen) innerhalb der Transceiver von transitorischen Signalen einschließt. In einigen Ausführungsformen ist der Code (z. B. ausführbarer Code oder Quellcode) auf einem Satz von einem oder mehreren nichtflüchtigen computerlesbaren Speichermedien gespeichert, die darauf gespeicherte ausführbare Anweisungen (oder anderen Speicher, um ausführbare Anweisungen zu speichern) aufweisen, die bei Ausführung (d. h. als Folge der Ausführung) durch einen oder mehrere Prozessoren eines Computersystems das Computersystem veranlassen, hierin beschriebene Operationen auszuführen. Ein Satz von nichttransitorischen computerlesbaren Speichermedien kann in mindestens einer Ausführungsform mehrere nichttransitorische computerlesbare Speichermedien umfassen und eines oder mehrere von einzelnen nicht transitorischen Speichermedien der mehreren nichttransitorischen computerlesbaren Speichermedien verfügen möglicherweise nicht über den gesamten Code, während mehrere nichttransitorische computerlesbares Speichermedien gemeinschaftlich den gesamten Code speichern. In mindestens einer Ausführungsform werden die ausführbaren Anweisungen so ausgeführt, dass unterschiedliche Anweisungen durch unterschiedliche Prozessoren ausgeführt werden - in mindestens einer Ausführungsform speichert ein nichttransitorisches computerlesbares Speichermedium Anweisungen und führt eine hauptsächliche Zentraleinheit („CPU“) einige der Anweisungen aus, während eine Grafikverarbeitungseinheit („GPU“) andere Anweisungen ausführt. Im Allgemeinen können unterschiedliche Komponenten eines Computersystems getrennte Prozessoren aufweisen und können unterschiedliche Prozessoren unterschiedliche Teilsätze der Anweisungen ausführen.
Dementsprechend sind in mindestens einer Ausführungsform Computersysteme so konfiguriert, dass sie einen oder mehrere Dienste implementieren, die einzeln oder gemeinsam Operationen der hierin beschriebenen Prozesse durchführen, und solche Computersysteme sind mit geeigneter Hardware und/oder Software konfiguriert, die die Durchführung der Operationen ermöglichen. Ferner ist ein Computersystem, das mindestens eine Ausführungsform der vorliegenden Offenbarung implementiert, eine einzelne Vorrichtung und in einer anderen Ausführungsform ein verteiltes Computersystem, das mehrere Vorrichtungen beinhaltet, die unterschiedlich arbeiten, sodass das verteilte Computersystem die hierin beschriebenen Operationen durchführt und eine einzelne Vorrichtung nicht alle Operationen durchführt.
Die Verwendung von Beispielen oder beispielhaften Ausdrücken (z. B. „wie“) dient lediglich der besseren Veranschaulichung von Ausführungsformen der Offenbarung und stellt keine Einschränkung des Umfangs der Offenbarung dar, sofern nicht anders angegeben. Keinerlei Wortwahl in der Beschreibung sollte so ausgelegt werden, dass sie ein beliebiges nicht beanspruchtes Element als für die Umsetzung der Offenbarung wesentlich angibt.
Alle hierin zitierten Referenzen, beinhaltend Veröffentlichungen, Patentanmeldungen und Patente, werden hiermit durch Verweis in demselben Umfang einbezogen, als ob jede Referenz einzeln und ausdrücklich als durch Verweis einbezogen angegeben wäre und hier in ihrer Gesamtheit wiedergegeben würde.
In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie ihre Ableitungen verwendet werden. Es versteht sich, dass diese Ausdrücke nicht als Synonyme füreinander beabsichtigt sein können. Vielmehr kann in konkreten Beispielen „verbunden“ oder „gekoppelt“ verwendet werden, um anzugeben, dass zwei oder mehr Elemente in direktem oder indirektem physischem oder elektrischem Kontakt miteinander stehen. Mit „gekoppelt“ kann auch gemeint sein, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, jedoch trotzdem miteinander zusammenwirken oder interagieren.
Sofern nicht ausdrücklich anders angegeben, beziehen sich Begriffe wie „Verarbeitung“, „Berechnung“, „Berechnen“, „Bestimmen“ o. ä. in der gesamten Spezifikation auf Aktionen und/oder Prozesse eines Computers oder eines Computersystems oder eines ähnlichen elektronischen Rechengeräts, die Daten, die als physikalische, z. B. elektronische, Größen in den Registern und/oder Speichern des Computersystems dargestellt werden, manipulieren und/oder in andere Daten konvertieren, die in ähnlicher Weise als physikalische Größen in den Speichern, Registern oder anderen Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen des Computersystems dargestellt werden.
In ähnlicher Weise kann sich der Begriff „Prozessor“ auf eine Vorrichtung oder einen Teil einer Vorrichtung beziehen, das elektronische Daten aus Registern und/oder einem Speicher verarbeitet und diese elektronischen Daten in andere elektronische Daten umwandelt, die in Registern und/oder einem Speicher gespeichert werden können. Als nicht einschränkende Beispiele kann der „Prozessor“ eine CPU oder eine GPU sein. Eine „Rechenplattform“ kann einen oder mehrere Prozessoren umfassen. Im hierin verwendeten Sinne können „Software“-Prozesse zum Beispiel Software- und/oder Hardware-Entitäten beinhalten, die im Verlauf der Zeit Arbeit Durchführen, wie etwa Tasks, Threads und intelligente Agenten. Außerdem kann sich jeder Prozess auf mehrere Prozesse beziehen, um Anweisungen nacheinander oder parallel, kontinuierlich oder intermittierend auszuführen. Die Begriffe „System“ und „Verfahren“ werden hier insofern synonym verwendet, als ein System eine oder mehrere Verfahren umfassen kann und Verfahren als System betrachtet werden können.
Bei mindestens einer Ausführungsform ist eine arithmetische Logikeinheit eine kombinatorische Logikschaltungsanordnung, die eine oder mehrere Eingaben verarbeitet, um ein Ergebnis zu erzeugen. Bei mindestens einer Ausführungsform wird eine arithmetische Logikeinheit von einem Prozessor verwendet, um mathematische Operationen wie Addition, Subtraktion oder Multiplikation auszuführen. Bei mindestens einer Ausführungsform wird eine arithmetische Logikeinheit verwendet, um logische Operationen wie logisches AND/OR oder XOR umzusetzen. Bei mindestens einer Ausführungsform ist eine arithmetische Logikeinheit zustandslos und besteht aus physikalischen Schaltkomponenten wie Halbleitertransistoren, die so angeordnet sind, dass sie logische Gatter bilden. Bei mindestens einer Ausführungsform kann eine arithmetische Logikeinheit intern als zustandsabhängige Logikschaltung mit einem assoziierten Taktgeber arbeiten. Bei mindestens einer Ausführungsform kann eine arithmetische Logikeinheit als asynchrone Logikschaltung aufgebaut sein, deren interner Zustand nicht in einem assoziierten Registersatz gehalten wird. Bei mindestens einer Ausführungsform wird eine arithmetische Logikeinheit von einem Prozessor verwendet, um in einem oder mehreren Registern des Prozessors gespeicherte Operanden zu kombinieren und eine Ausgabe zu erzeugen, die vom Prozessor in einem anderen Register oder einem Speicherplatz gespeichert werden kann.
Bei mindestens einer Ausführungsform übergibt der Prozessor als Ergebnis der Verarbeitung eines vom Prozessor abgerufenen Anweisungen einen oder mehrere Eingaben oder Operanden an eine arithmetische Logikeinheit, wodurch die arithmetische Logikeinheit veranlasst wird, ein Ergebnis zu erzeugen, das mindestens zum Teil auf einem Anweisungscode basiert, der den Eingängen der arithmetischen Logikeinheit bereitgestellt wird. Bei mindestens einer Ausführungsform basieren die vom Prozessor an die ALU bereitgestellten Anweisungscodes mindestens zum Teil auf der von dem Prozessor ausgeführten Anweisung. Bei mindestens einer Ausführungsform verarbeitet die kombinatorische Logik in der ALU die Eingaben und erzeugt eine Ausgabe, die auf einen Bus innerhalb des Prozessors gelegt wird. Bei mindestens einer Ausführungsform wählt der Prozessor ein Zielregister, einen Speicherort, eine Ausgabevorrichtung oder einen Ausgabespeicherort auf dem Ausgangsbus aus, so dass ein Taktgeber des Prozessors bewirkt, dass die von der ALU erzeugten Ergebnisse an den gewünschten Ort gesendet werden.
Im vorliegenden Dokument kann auf das Beschaffen, Erfassen, Empfangen oder Eingeben von analogen oder digitalen Daten in ein Teilsystem, ein Computersystem oder eine computerimplementierte Maschine Bezug genommen werden. In mindestens einer Ausführungsform kann der Prozess des Erlangens, Erfassens, Empfangens oder Eingebens von analogen und digitalen Daten auf eine Vielfalt von Weisen erzielt werden, wie etwa durch das Empfangen von Daten als Parameter eines Funktionsaufrufs oder eines Aufrufs einer Anwendungsprogrammierschnittstelle. In einigen Umsetzungen kann der Prozess des Erhaltens, Übernehmens, Empfangens oder Eingebens von analogen oder digitalen Daten durch das Übertragen von Daten über eine serielle oder parallele Schnittstelle erreicht werden. In einer anderen Implementierung kann der Prozess des Erhaltens, Erfassens, Empfangens oder Eingebens analoger oder digitaler Daten durch die Übertragung von Daten über ein Computernetzwerk von der bereitstellenden Einheit zur erfassenden Einheit durchgeführt werden. Es kann auch auf das Bereitstellen, Ausgeben, Übertragen, Senden oder Darstellen von analogen oder digitalen Daten Bezug genommen werden. In verschiedenen Beispielen kann der Prozess des Bereitstellens, Ausgebens, Übertragens, Sendens oder Darstellens von analogen oder digitalen Daten durch das Übermitteln von Daten als Eingabe- oder Ausgabeparameter eines Funktionsaufrufs, eines Parameters einer Anwendungsprogrammierschnittstelle oder eines Interprozesskommunikationsmechanismus erfolgen.
Obwohl die vorstehende Diskussion Beispielimplementierungen der beschriebenen Techniken darlegt, können auch andere Architekturen verwendet werden, um die beschriebene Funktionellität zu implementieren, und sie sollen in den Anwendungsbereich dieser Offenlegung fallen. Darüber hinaus könnten, obwohl spezifische Verteilungen von Zuständigkeiten vorstehend zum Zwecke der Erörterung definiert sind, verschiedene Funktionen und Zuständigkeiten in Abhängigkeit von den Umständen anders verteilt und aufgeteilt werden.
Auch wenn der Gegenstand in einer Sprache beschrieben wurde, die sich auf strukturelle Merkmale und/oder methodische Handlungen bezieht, ist zu verstehen, dass der in den beigefügten Ansprüchen beanspruchte Gegenstand nicht notwendigerweise auf die beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Vielmehr werden spezifische Merkmale und Handlungen als beispielhafte Formen zum Implementieren der Ansprüche offenbart.
Der Gegenstand der vorliegenden Offenbarung wird hier genau beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise 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. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe darüber hinaus nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge zwischen oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge ist der einzelnen Schritte ist explizit beschrieben.
Andere Variationen sind im Sinne der vorliegenden Offenbarung. Während die offenbarten Techniken für verschiedene Modifikationen und alternative Konstruktionen anfällig sind, sind bestimmte illustrierte Ausführungsformen davon in den Zeichnungen dargestellt und wurden vorstehend im Detail beschrieben. Allerdings versteht es sich, dass nicht die Absicht verfolgt wird, die Offenbarung auf die spezifische(n) offenbarte(n) Form oder Formen einzuschränken, sondern die Absicht ganz im Gegenteil darin besteht, sämtliche Modifikationen, alternativen Konstruktionen und Äquivalente abzudecken, die in den Geist und Umfang der wie in den beigefügten Ansprüchen definierten Offenbarung fallen.

Claims

Integrierte Schaltung, umfassend: einen ersten Abschnitt, der einen ersten Timer umfasst, wobei der erste Abschnitt Daten, die mindestens einem Fehler entsprechen, der von einer Vielzahl von Logikblöcken stammt, in mindestens ein Fehlersignal aggregiert, und das mindestens eine Fehlersignal überträgt, wobei der erste Timer startet, wenn das mindestens eine Fehlersignal übertragen und zurückgesetzt wird, wenn die dem mindestens einen Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, wobei der erste Abschnitt ein Timeout-Fehlersignal überträgt, wenn der erste Timer anzeigt, dass mindestens eine erste vorbestimmte Zeitdauer verstrichen ist, und die Daten, die dem mindestens einen Fehler entsprechen, nicht aus dem ersten Abschnitt gelöscht wurden; und einen zweiten Abschnitt zum Empfangen des mindestens einen Fehlersignals und des Timeout-Fehlersignals, wenn das Timeout-Fehlersignal gesendet wurde, wobei der zweite Abschnitt ein externes System benachrichtigt, nachdem das Timeout-Fehlersignal empfangen wurde.
Integrierte Schaltung nach Anspruch 1, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt löscht, wenn der erste Abschnitt bestimmt, dass mindestens einer der Vielzahl von Logikblöcken den Fehler korrigiert hat, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
Integrierte Schaltung nach Anspruch 1 oder 2, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt eine oder mehrere Maßnahmen ausführt, die den Fehler korrigieren, und die Daten, die dem bestimmten Fehler entsprechen, aus dem ersten Abschnitt löscht, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt Fehlerinformationen an einen Speicherort schreibt und den zweiten Abschnitt über die Schwere des Fehlers benachrichtigt, der zweite Abschnitt entscheidet, ob die Fehlerinformationen zumindest teilweise basierend auf dem Schweregrad des Fehlers gelesen werden sollen, der zweite Abschnitt eine oder mehrere Maßnahmen durchführt, die den Fehler beheben, und den ersten Abschnitt benachrichtigt, die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt zu löschen, der erste Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt löscht, nachdem der erste Abschnitt die Benachrichtigung empfangen hat, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem bestimmten Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem bestimmten Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, wobei für einen bestimmten Fehler des mindestens einen Fehlers: der erste Abschnitt einen Fehler identifiziert, der den bestimmten Fehler erzeugt hat, der erste Abschnitt den zweiten Abschnitt über einen Schweregrad des Fehlers benachrichtigt, und der zweite Abschnitt das externe System über den Fehler basierend auf dem Schweregrad des Fehlers benachrichtigt.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, wobei der zweite Abschnitt einen zweiten Timer umfasst, der startet, wenn der zweite Abschnitt das Timeout-Fehlersignal empfängt, der zweite Timer zurückgesetzt wird, nachdem die dem mindestens einen Fehler entsprechenden Daten aus dem zweiten Abschnitt gelöscht wurden, und der zweite Abschnitt wartet, bis der zweite Timer anzeigt, dass mindestens eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor er das externe System benachrichtigt.
Integrierte Schaltung nach Anspruch 6, wobei der zweite Abschnitt eine oder mehrere korrigierende Maßnahmen durchführt, nachdem er das Timeout-Fehler empfangen hat, und den ersten Abschnitt benachrichtigt, die dem mindestens einen Fehler entsprechenden Daten zu löschen, wobei der zweite Abschnitt das externe System nicht benachrichtigt, wenn der zweite Abschnitt den ersten Abschnitt benachrichtigt hat, die dem mindestens einen Fehler entsprechenden Daten zu löschen, bevor der zweite Timer anzeigt, dass mindestens die zweite vorherbestimmte Zeitdauer verstrichen ist.
Integrierte Schaltung nach Anspruch 7, wobei der erste Abschnitt die Daten, die dem mindestens einen Fehler entsprechen, aus dem ersten Abschnitt löscht, nachdem er die Benachrichtigung zum Löschen der Daten, die dem mindestens einen Fehler entsprechen, aus dem zweiten Abschnitt empfangen hat, der erste Abschnitt den zweiten Abschnitt benachrichtigt, dass die dem mindestens einen Fehler entsprechenden Daten aus dem ersten Abschnitt gelöscht wurden, und der zweite Abschnitt die dem mindestens einen Fehler entsprechenden Daten aus dem zweiten Abschnitt löscht.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, die sich auf einem einzigen Stück Halbleitermaterial befindet.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, die einen Abschnitt eines Systems auf einem Chip („SoC“) eines Automobil-Systems implementiert.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, wobei der zweite Abschnitt unter einem höheren Risikoklassifizierungs-Level arbeitet als der erste Abschnitt.
Integrierte Schaltung nach einem der vorhergehenden Ansprüche, wobei das mindestens eine Fehlersignal ein unkorrigiertes Fehlersignal umfasst, die Daten, die dem mindestens einen Fehler entsprechen, Daten umfassen, die einem unkorrigierten Fehler entsprechen, der durch den ersten Abschnitt in das unkorrigierte Fehlersignal aggregiert wird, und die integrierte Schaltung ferner umfasst: einen ersten Signalleiter zum Leiten des Timeout-Fehlersignals von dem ersten Abschnitt zu dem zweiten Abschnitt; und einen zweiten Signalleiter, um das unkorrigierte Fehlersignal von dem ersten Abschnitt zu dem zweiten Abschnitt zu leiten.
Integrierte Schaltung nach Anspruch 11, wobei das mindestens eine Fehlersignal ein korrigiertes Fehlersignal umfasst, die Daten, die dem mindestens einen Fehler entsprechen, Daten umfassen, die einem korrigierten Fehler entsprechen, der von dem ersten Abschnitt in das korrigierte Fehlersignal aggregiert wird, und die integrierte Schaltung ferner umfasst: einen dritten Signalleiter, um das korrigierte Fehlersignal von dem ersten Abschnitt zu dem zweiten Abschnitt zu leiten.
Verfahren nach einem der vorstehenden Ansprüche, ferner umfassend: eine Verbindung zwischen dem ersten und dem zweiten Abschnitt zum Übertragen eines Schweregradsignals vom ersten Abschnitt zum zweiten Abschnitt, wobei das Schweregradsignal einen Schweregrad für jeden der mindestens einen Fehler angibt.
Verfahren nach einem der vorstehenden Ansprüche, ferner umfassend: eine Vielzahl von Fehleraggregatoren, die jeweils Daten empfangen, die einem oder mehreren Fehlern von mindestens einem der Vielzahl von Logikblöcken entsprechen, die Daten, die dem einen oder den mehreren Fehlern entsprechen, zu einem oder mehreren Fehlersignalen aggregieren und das eine oder die mehreren Fehlersignale an den ersten Abschnitt übertragen, der das eine oder die mehreren Fehlersignale zu dem mindestens einen Fehlersignal aggregiert.
Verfahren, umfassend: Empfangen von Daten durch eine erste Schaltung einer integrierten Schaltung, die mindestens einem Fehler entsprechen, der jeweils durch mindestens einen Fehler erzeugt wird, der in einem Logikblock der integrierten Schaltung aufgetreten ist; Zusammenfassen der dem mindestens einen Fehler entsprechenden Daten durch eine erste Schaltung zu mindestens einem Fehlersignal; Übertragen des mindestens einen Fehlersignals durch eine erste Schaltung an eine zweite Schaltung der integrierten Schaltung, wobei die Übertragung einen ersten Timer startet; Bestimmen, durch eine erste Schaltung, dass ein oder mehrere Fehler, die einen bestimmten von mindestens einem Fehler erzeugt haben, korrigiert worden sind; Löschen der Daten, die dem bestimmten Fehler entsprechen, durch eine erste Schaltung, nachdem die erste Schaltung bestimmt, dass der eine oder die mehreren Fehler korrigiert wurden, wobei der erste Timer zurückgesetzt wird, wenn die Daten, die dem mindestens einen Fehler entsprechen, gelöscht wurden; Übertragen eines Timeout-Fehlersignals durch eine erste Schaltung an die zweite Schaltung, wenn der erste Timer anzeigt, dass mindestens eine erste vorbestimmte Zeitdauer verstrichen ist; und Benachrichtigen eines externen Systems durch die zweite Schaltung, nachdem die zweite Schaltung das Timeout-Fehlersignal empfangen hat.
Verfahren nach Anspruch 16, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch eine erste Schaltung; Bestimmen durch eine erste Schaltung, dass der eine oder die mehreren Fehler durch mindestens einen Logikblock der integrierten Schaltung korrigiert wurden; Informieren der zweiten Schaltung durch eine erste Schaltung, dass die Daten, die dem bestimmten Fehler entsprechen, von der ersten Schaltung gelöscht wurden; und Löschen der dem bestimmten Fehler entsprechenden Daten aus der zweiten Schaltung durch die zweite Schaltung.
Verfahren nach Anspruch 16 oder 17, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch eine erste Schaltung; Durchführen einer oder mehrerer Maßnahmen, die den einen oder die mehreren Fehler korrigieren, durch eine erste Schaltung; Informieren der zweiten Schaltung durch eine erste Schaltung, dass die Daten, die dem bestimmten Fehler entsprechen, von der ersten Schaltung gelöscht wurden; und Löschen der dem bestimmten Fehler entsprechenden Daten aus der zweiten Schaltung durch die zweite Schaltung.
Verfahren nach einem der Ansprüche 16 bis 18, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch eine erste Schaltung; Schreiben von Fehlerinformationen an einen Speicherort durch eine erste Schaltung; Informieren der zweiten Schaltung durch die erste Schaltung über einen Schweregrad des einen oder der mehreren Fehler; Entscheiden ob die Fehlerinformationen zumindest teilweise basierend auf dem Schwereg des einen oder der mehreren Fehler durch die zweite Schaltung gelesen werden sollen; Durchführen einer oder mehrerer Maßnahmen, die den einen oder die mehreren Fehler korrigieren, durch die zweite Schaltung; Informieren der ersten Schaltung durch die zweite Schaltung, dass der eine oder die mehreren Fehler, die den bestimmten Fehler erzeugt haben, korrigiert worden sind; und Löschen der dem bestimmten Fehler entsprechenden Daten aus der ersten und zweiten Schaltung.
Verfahren nach einem der Ansprüche 16 bis 19, ferner umfassend: Identifizieren des einen oder der mehreren Fehler, die den bestimmten Fehler erzeugt haben, durch eine erste Schaltung; Informieren der zweiten Schaltung durch die erste Schaltung über den Schweregrad des einen oder der mehreren Fehler; und Benachrichtigen des externen Systems über den Fehler basierend auf dem Schweregrad des Fehlers durch die zweite Schaltung.
Verfahren nach einem der Ansprüche 16 bis 20, ferner umfassend: Warten durch die zweite Schaltung, bis ein zweiter Timer anzeigt, dass mindestens eine zweite vorherbestimmte Zeitdauer verstrichen ist, bevor das externe System benachrichtigt wird, wobei der zweite Timer beginnt, wenn die zweite Schaltung das Timeout-Fehlersignal empfängt und zurückgesetzt wird, nachdem die dem mindestens einen Fehler entsprechenden Daten aus der zweiten Schaltung gelöscht wurden.
Verfahren nach Anspruch 21, ferner umfassend: Durchführen einer oder mehrerer Korrekturmaßnahmen durch die zweite Schaltung nach dem Empfangen des Timeout-Fehlersignals, wobei die eine oder mehreren Korrekturmaßnahmen den mindestens einen Fehler korrigieren, der jeden der mindestens einen Fehler erzeugt hat; und Löschen der Daten, die dem mindestens einen Fehler entsprechen, von der ersten und zweiten Schaltung, wobei die zweite Schaltung das externe System nicht benachrichtigt, wenn die Daten, die dem mindestens einen Fehler entsprechen, von der zweiten Schaltung gelöscht wurden, bevor der zweite Timer mindestens das anzeigt zweite vorbestimmte Zeitdauer verstrichen ist.
Verfahren nach Anspruch 22, wobei das Löschen der Daten, die dem mindestens einen Fehler entsprechen, von der ersten und zweiten Schaltung umfasst: Informieren der ersten Schaltung durch die zweite Schaltung, dass der mindestens eine Fehler, der jeden der mindestens einen Fehler erzeugt hat, korrigiert worden ist; Löschen der Daten, die jedem Fehler des mindestens einen Fehlers von der ersten Schaltung entsprechen, durch eine erste Schaltung; Informieren der zweiten Schaltung durch eine erste Schaltung, dass die Daten, die jedem Fehler des mindestens einen Fehlers entsprechen, aus der ersten Schaltung gelöscht wurden; und Löschen der Daten, die jedem Fehler des mindestens einen Fehlers entsprechen, durch die zweite Schaltung.
Verfahren nach einem der Ansprüche 16 bis 23, wobei sich die integrierte Schaltung auf einem zusammenhängenden Stück Halbleitermaterial befindet.
Verfahren nach einem der Ansprüche 16-24, wobei die integrierte Schaltung einen Abschnitt eines Systems auf einem Chip („SoC“) in einem Automobil-System implementiert.
Verfahren nach einem der Ansprüche 16 bis 25, wobei die erste Schaltung innerhalb einer ersten Spannungsdomäne und einer ersten Taktdomäne arbeitet, und die zweite Schaltung innerhalb einer zweiten Spannungsdomäne und einer zweiten Taktdomäne arbeitet, die zweite Spannungsdomäne unterscheidet sich von der ersten Spannungsdomäne, die zweite Taktdomäne unterscheidet sich von der ersten Taktdomäne, und die zweite Schaltung arbeitet auf einem höheren Risikoklassifizierungs-Level als die erste Schaltung.
Verfahren nach einem der Ansprüche 16 bis 26, ferner umfassend: Empfangen von einem oder mehreren Fehlern von mindestens einem aus einer Vielzahl von Logikblöcken durch jeden aus einer Vielzahl von Fehleraggregatoren; Erzeugen, durch jeden der Vielzahl von Fehleraggregatoren, eines Fehlersignals basierend auf dem einen oder den mehreren von dem Fehleraggregator empfangenen Fehlern; und Übertragen des von dem Fehleraggregator erzeugten Fehlersignals durch jeden der Mehrzahl von Fehleraggregatoren an die erste Schaltung, um dadurch eine Mehrzahl von Fehlersignalen zu übertragen, die den mindestens einen Fehler umfassen, wobei die erste Schaltung die Daten aggregiert, die dem mindestens einen entsprechen Fehler in das mindestens eine Fehlersignal.
Integrierte Schaltung eines autonomen Fahrzeugs, wobei integrierte Schaltung Folgendes umfasst: einen Sicherheitsabschnitt zum Durchführen mehrerer Korrekturmaßnahmen, um das autonome Fahrzeug in einen sicheren Zustand zu bringen, wobei die mehreren Korrekturmaßnahmen das Übertragen eines ausgehenden Fehlersignals an ein externes System umfassen, wenn der Sicherheitsabschnitt erkennt, dass ein Timeout-Fehler geltend gemacht wurde; einen Treiberabschnitt zum Steuern mindestens einer Funktion des autonomen Fahrzeugs, wobei der Treiberabschnitt einen ersten Timer umfasst, der startet, wenn der Treiberabschnitt einen ersten geltend gemachten Fehler in einem Fehlersignal an den Sicherheitsabschnitt überträgt, wobei der erste Timer zurückgesetzt wird, wenn ein letzter geltend gemachter Fehler im Treiberabschnitt deaktiviert wird, wobei der Treiberabschnitt den Timeout-Fehler in einem Timeout-Fehlersignal geltend macht, wenn der erste Timer angibt, dass zumindest eine erste vorbestimmte Zeitdauer verstrichen ist; einen ersten Signalleiter, um das Fehlersignal von dem Treiberabschnitt zu dem Sicherheitsabschnitt zu leiten, wobei der Sicherheitsabschnitt einen geltend gemachten Fehler für jeden geltend gemachten Fehler in dem Fehlersignal umfasst; und einen Timeout-Signalleiter, um das Timeout-Fehlersignal von dem Treiberabschnitt zu dem Sicherheitsabschnitt zu leiten.
Integrierte Schaltung nach Anspruch 28, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Antriebsabschnitt einen Grund identifiziert, warum der Fehler geltend gemacht wurde, der Treiberabschnitt den Fehler innerhalb des Treiberabschnitts deaktiviert, wenn der Treiberabschnitt bestimmt, dass ein Logikblock des Treiberabschnitts den Grund für die Behauptung des Fehlers angemessen adressiert, der Treiberabschnitt den Sicherheitsabschnitt benachrichtigt, dass der Fehler innerhalb des Treiberabschnitts aufgehoben wurde, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung empfangen hat, dass der Fehler innerhalb des Treiberabschnitts deaktiviert wurde.
Integrierte Schaltung nach Anspruch 28 oder 29, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Antriebsabschnitt einen Grund identifiziert, warum der Fehler geltend gemacht wurde, der Treiberabschnitt eine oder mehrere Maßnahmen ausführt, um dadurch den Grund für die Behauptung des Fehlers anzugehen, der Antriebsabschnitt den Fehler innerhalb des Antriebsabschnitts deaktiviert, der Treiberabschnitt den Sicherheitsabschnitt benachrichtigt, dass der Fehler innerhalb des Treiberabschnitts aufgehoben wurde, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung empfangen hat, dass der Fehler innerhalb des Treiberabschnitts deaktiviert wurde.
Integrierte Schaltung nach einem der Ansprüche 28 bis 30, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Antriebsabschnitt einen Grund identifiziert, warum der Fehler geltend gemacht wurde, der Trieberteil Informationen an einen Speicherort schreibt und den Sicherheitsabschnitt über den Schweregrad des Fehlers benachrichtigt, der Sicherheitsabschnitt basierend auf dem Schweregrad des Fehlers entscheidet, ob die Information gelesen werden soll oder nicht, der Sicherheitsabschnitt mindestens eine der Vielzahl von Korrekturmaßnahmen durchführt, um dadurch den Grund für die Behauptung des Fehlers anzugehen, der Sicherheitsabschnitt den Antrieb benachrichtigt, den Fehler zu deaktivieren, der Laufwerksabschnitt den Fehler innerhalb des Laufwerksabschnitts deaktiviert, nachdem der Laufwerksabschnitt die Benachrichtigung zum Deaktivieren des Fehlers empfangen hat, der Treiberabschnitt den Sicherheitsabschnitt benachrichtigt, dass der Fehler innerhalb des Treiberabschnitts aufgehoben wurde, und der Sicherheitsabschnitt den Fehler innerhalb des Sicherheitsabschnitts deaktiviert, nachdem der Sicherheitsabschnitt die Benachrichtigung empfangen hat, dass der Fehler innerhalb des Treiberabschnitts deaktiviert wurde.
Integrierte Schaltung nach einem der Ansprüche 28 bis 30, wobei für jeden im Fehlersignal geltend gemachten Fehler: der Antriebsabschnitt einen Grund identifiziert, warum der Fehler geltend gemacht wurde, der Trieberteil den Sicherheitsabschnitt über einen Schweregrad des Fehlers benachrichtigt, und der Sicherheitsabschnitt das externe System über einen Fehler basierend auf dem Schweregrad des Fehlers benachrichtigt.
Integrierte Schaltung nach einem der Ansprüche 28 bis 32, wobei der Sicherheitsabschnitt einen zweiten Timer umfasst, der startet, wenn der Sicherheitsabschnitt den Timeout-Fehler in dem Timeout-Fehlersignal empfängt, der zweite Timer wird zurückgesetzt, wenn der Sicherheitsabschnitt keine geltend gemachten Fehler mehr umfasst, und der Sicherheitsabschnitt wartet, bis der zweite Timer anzeigt, dass mindestens eine zweite vorbestimmte Zeitdauer verstrichen ist, bevor er das ausgehende Fehlersignal an das externe System überträgt.
Integrierte Schaltung nach einem der Ansprüche 28 bis 33, wobei der Sicherheitsabschnitt mindestens eine der Vielzahl von Korrekturmaßnahmen durchführt, nachdem er den Timeout-Fehler im Timeout-Fehlersignal empfangen hat, und den Treiberabschnitt benachrichtigt, jeden Fehler, der im Fehlersignal geltend gemacht wurde, zu deassertieren, wobei der Sicherheitsabschnitt das ausgehende Fehlersignal nicht überträgt, wenn der Sicherheitsabschnitt den Treiberabschnitt benachrichtigt hat, jeden Fehler, der im Fehlersignal geltend gemacht wurde, zu deaktivieren, bevor der zweite Timer anzeigt, dass mindestens die zweite vorherbestimmte Zeitdauer verstrichen ist.
Integrierte Schaltung nach einem der Ansprüche 28 bis 34 auf einem einzelnen Stück Halbleitermaterial.
Integrierte Schaltung nach einem der Ansprüche 28 bis 35, wobei der Sicherheitsabschnitt auf einem höheren Risiko-Level arbeitet als der Treiberabschnitt.
Integrierte Schaltung nach einem der Ansprüche 28 bis 36, wobei jeder geltend gemachte Fehler im Fehlersignal ein unkorrigierter Fehler ist, das Fehlersignal ein unkorrigiertes Fehlersignal ist, der erste Signalleiter ein unkorrigierter Fehlersignalleiter ist, der Treiberabschnitt geltend gemachtes korrigiert überträgt Fehler in einem korrigierten Fehlersignal an den Sicherheitsabschnitt, und die integrierte Schaltung ferner umfasst: einen Leiter für korrigierte Signale, um das korrigierte Fehlersignal von dem Treiberabschnitt zu dem Sicherheitsabschnitt zu leiten, wobei der Sicherheitsabschnitt einen behaupteten korrigierten Fehler für jeden behaupteten korrigierten Fehler in dem korrigierten Fehlersignal umfasst.
Integrierte Schaltung nach einem der Ansprüche 28 bis 37, ferner umfassend: eine Verbindung zwischen den Treiber- und Sicherheitsabschnitten, um ein Schweregradsignal von dem Trieberteil zu dem Sicherheitsabschnitt zu übertragen, wobei das Schweregradsignal einen Schweregrad für einen geltend gemachten Fehler in dem Fehlersignal angibt.
Integrierte Schaltung nach einem der Ansprüche 28 bis 38, ferner umfassend: eine Vielzahl von Fehleraggregatoren, die jeweils einen oder mehrere Fehler von mindestens einem einer Vielzahl von Logikblöcken empfangen, den einen oder die mehreren Fehler zu einem oder mehreren Fehlersignalen zusammenfassen und das eine oder die mehreren Fehlersignale an den Treiberabschnitt übertragen, der das eine oder die mehreren Fehlersignale zu einem Fehlersignal zusammenfasst.