DE102020118412A9

DE102020118412A9 - Unabhängige sicherheitsüberwachung eines automatisierten fahrsystems

Info

Publication number: DE102020118412A9
Application number: DE102020118412.3A
Authority: DE
Inventors: Umberto Santoni; Riccardo Mariani; John Weast
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-09-23
Filing date: 2020-07-13
Publication date: 2021-06-24
Also published as: DE102020118412A1; US20200017114A1

Abstract

Ein automatisiertes Fahrsystem (210) weist ein Sicherheitsbegleitteilsystem (710) auf, um auf Daten zuzugreifen, die in einem Rechenteilsystem (705) des automatisierten Fahrsystems (210) erzeugt werden, die eine Bestimmung durch das Rechenteilsystem (705) im Zusammenhang mit einer automatisierten Fahraufgabe anzeigen. Das Sicherheitsbegleitteilsystem bestimmt basierend auf den Daten, ob die Bestimmung sicher ist. Das Sicherheitsbegleitteilsystem ist dazu ausgelegt, eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem (705) zu realisieren.

Description

Diese Offenbarung bezieht sich allgemein auf den Bereich von Rechensystemen und insbesondere auf Rechensysteme zur Ermöglichung autonomer Fahrzeuge.
Einige Fahrzeuge sind zum Betrieb in einem autonomen Modus ausgelegt, in dem das Fahrzeug durch eine Umgebung mit wenig oder ohne Zutun eines Fahrers navigiert. Ein solches Fahrzeug weist typischerweise einen oder mehrere Sensoren auf, die zur Erfassung von Informationen über die Umgebung ausgelegt sind. Das Fahrzeug kann die erfassten Informationen zum Navigieren durch die Umgebung nutzen. Wenn die Sensoren beispielsweise erkennen, dass sich das Fahrzeug einem Hindernis nähert, kann das Fahrzeug um das Hindernis herum navigieren.

1 ist ein vereinfachtes Blockdiagramm einer beispielhaften Fahrumgebung.
2 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein automatisiertes Fahrsystem in einem Fahrzeug.
3 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung automatisierter Fahrstufen.
4 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung des Betriebs eines automatisierten Fahrsystems.
5 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung der Grundfunktionen von automatisierten Fahrsystemen.
6 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung der Komponenten eines beispielhaften automatisierten Fahrsystems.
7 ist ein vereinfachtes Blockdiagramm eines beispielhaften automatisierten Fahrsystems mit einem Sicherheitsbegleitteilsystem.
8 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung eines beispielhaften Sicherheitsbegleitteilsystems, das mit einem Rechenteilsystem eines automatisierten Fahrsystems zusammenarbeitet.
9 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung von Beispielschnittstellen eines automatisierten Fahrsystems.
10 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung der Hardware eines beispielhaften automatisierten Fahrsystems.
11 ist ein Flussdiagramm zur Veranschaulichung einer Beispieltechnik zur Gewährleistung der Sicherheit im Zusammenhang mit dem autonomen Betrieb einer Maschine.
12 ist ein Blockdiagramm eines beispielhaften Prozessors gemäß einer Ausführungsform.
13 ist ein Blockdiagramm eines beispielhaften Rechensystems gemäß einer Ausführungsform.

Ähnliche Referenznummern und Bezeichnungen in den verschiedenen Zeichnungen weisen auf ähnliche Elemente hin.
1 ist eine vereinfachte Darstellung 100, die ein Beispiel für eine autonome Fahrumgebung zeigt. Fahrzeuge (z. B. 105, 110, 115 usw.) können mit einem unterschiedlichen Grad autonomer Fahrfähigkeiten ausgestattet sein, die durch bordeigene Rechensysteme mit in Hardware, Firmware und/oder Software implementierter Logik ermöglicht werden, um entsprechende autonome Fahrstacks zu erzielen. Derartige autonome Fahrstacks können es den Fahrzeugen ermöglichen, sich selbst zu steuern oder den Fahrer dabei zu unterstützen, Straßen zu erkennen, von einem Punkt zum anderen zu navigieren, andere Fahrzeuge und Straßenakteure (z. B. Fußgänger (z. B. 135), Radfahrer usw.) zu erkennen, Hindernisse und Gefahren (z. B. 120) sowie den Straßenzustand (z. B. Verkehr, Straßenzustand, Wetterbedingungen usw.) zu erkennen und die Steuerung und Führung des Fahrzeugs entsprechend anzupassen.
In einigen Implementierungen können Fahrzeuge (z. B. 105, 110, 115) innerhalb der Umgebung insofern „verbunden“ sein, als die bordeigenen Rechensysteme Kommunikationsmodule zur Unterstützung drahtloser Kommunikation aufweisen, die eine oder mehrere Technologien (z. B. IEEE 802.11-Kommunikation (z. B. WLAN), zellulare Datennetze (z. B., „3rd Generation Partnership Project‟ (3GPP)-Netzwerke, Globales System für Mobilkommunikation (GSM), allgemeiner Paketfunkdienst, Code Division Multiple Access (CDMA) usw.), Bluetooth™, Millimeterwellen (mmWave), ZigBee™, Z-Wave™ usw.) verwenden, die es den bordeigenen Rechensystemen ermöglichen, sich mit anderen Rechensystemen zu verbinden und mit diesen zu kommunizieren, wie z. B. mit den bordeigenen Rechensystemen anderer Fahrzeuge, straßenseitigen Anlagen, Cloud-basierten Rechensystemen oder anderen unterstützenden Infrastrukturen. Beispielsweise können in einigen Implementierungen Fahrzeuge (z. B. 105, 110, 115) mit Rechensystemen kommunizieren, die Sensoren, Daten und Dienste zur Unterstützung der fahrzeugeigenen autonomen Fahrfähigkeiten übermitteln. Wie im illustrativen Beispiel von 1 gezeigt, können beispielsweise Unterstützungsdrohnen 180 (z. B. boden- und/oder luftgestützt), straßenseitige Rechenvorrichtungen (z. B. 140), verschiedene externe (zum Fahrzeug gehörende oder fremde) Sensorvorrichtungen (z. B., 160, 165, 170, 175 usw.) und andere Vorrichtungen als autonome Fahrinfrastruktur getrennt von den in den Fahrzeugen implementierten Rechensystemen, Sensoren und Logiken (z. B. 105, 110, 115) bereitgestellt werden, um die durch die Fahrzeuge bereitgestellten autonomen Fahrergebnisse zu unterstützen und zu verbessern, neben anderen Beispielen. Fahrzeuge können auch mit anderen verbundenen Fahrzeugen über drahtlose Kommunikationskanäle kommunizieren, um Daten auszutauschen und Bewegungen innerhalb einer autonomen Fahrumgebung zu koordinieren, neben anderen beispielhaften Kommunikationsmöglichkeiten.
Wie im Beispiel von 1 dargestellt, kann eine autonome Fahrinfrastruktur eine Vielzahl verschiedener Systeme umfassen. Solche Systeme können je nach Standort variieren, wobei stärker ausgebaute Straßen (z. B. Straßen, die von bestimmten Gemeinden oder Mautbehörden kontrolliert werden, Straßen in städtischen Gebieten, Straßenabschnitte, die bekanntermaßen für autonome Fahrzeuge problematisch sind, usw.) eine größere Anzahl oder fortschrittlichere Unterstützungsvorrichtungen für die Infrastruktur aufweisen als andere Straßenabschnitte usw. So können z. B. zusätzliche Sensorvorrichtungen (z. B. 160, 165, 170, 175) vorgesehen sein, die Sensoren zur Beobachtung von Teilen von Straßen und sich in der Umgebung bewegenden Fahrzeugen aufweisen und entsprechende Daten erzeugen, die die Beobachtungen der Sensoren beschreiben oder verkörpern. Sensorvorrichtungen können z. B. in die Fahrbahn selbst (z. B. Sensor 160), in straßenseitige oder überirdische Beschilderung (z. B. Sensor 165 auf Schild 125), in Sensoren (z. B. 170, 175), die an elektronischen straßenseitigen Anlagen oder Einrichtungen (z. B. Ampeln (z. B. 130), elektronischen Straßenschildern, elektronischen Reklametafeln usw.) angebracht sind, sowie in spezielle straßenseitige Anlagen (z. B. 140) eingebettet sein. Sensorvorrichtungen können auch Kommunikationsvorrichtungen aufweisen, um ihre gesammelten Sensordaten direkt an angeschlossene Fahrzeuge in der Nähe oder an Fog- oder Cloud-basierte Rechensysteme (z. B. 140, 150) zu übermitteln. Fahrzeuge können Sensordaten, die durch externe Sensorvorrichtungen (z. B. 160, 165, 170, 175, 180) erhoben wurden, oder Daten erhalten, die Beobachtungen oder Empfehlungen enthalten, die durch andere Systeme (z. B. 140, 150) basierend auf Sensordaten dieser Sensorvorrichtungen (z. B. 160, 165, 170, 175, 180) erzeugt wurden, und diese Daten bei der Sensorfusion, Inferenz, Wegplanung und anderen Aufgaben verwenden, die durch das bordeigene autonome Fahrsystem durchgeführt werden. In einigen Fällen können sich derartige Fremdsensoren und Sensordaten tatsächlich innerhalb des Fahrzeugs befinden, z. B. in Form eines am Fahrzeug angebrachten Nachrüstsensors, einer persönlichen Vorrichtung (z. B. Smartphone, am Körper tragbare Geräte usw.), die durch Insassen des Fahrzeugs mitgeführt oder getragen werden, usw. Andere Akteure im Straßenverkehr, einschließlich Fußgänger, Fahrräder, Drohnen, Elektroroller usw. können ebenfalls mit Sensoren ausgestattet sein oder Sensoren tragen, um Sensordaten zu erzeugen, die eine autonome Fahrumgebung beschreiben, die durch autonome Fahrzeuge, Cloud- oder Fogbasierte Unterstützungssysteme (z. B. 140, 150) und andere Sensorvorrichtungen (z. B. 160, 165, 170, 175, 180) genutzt und verbraucht werden können.
Da autonome Fahrzeugsysteme einen unterschiedlichen Grad an Funktionalität und Ausgereiftheit aufweisen können, kann eine unterstützende Infrastruktur erforderlich sein, um nicht nur die Erfassungsfähigkeiten einiger Fahrzeuge, sondern auch die Computer- und Maschinenlernfunktionen zu ergänzen, die die autonome Fahrfunktionalität einiger Fahrzeuge ermöglichen. Beispielsweise können die Rechenressourcen und die autonome Fahrlogik, die zum Trainieren von Maschinenlernmodellen und zur Nutzung solcher Maschinenlernmodelle verwendet werden, ganz oder teilweise auf den bordeigenen Rechensystemen und einigen externen Systemen (z. B. 140, 150) bereitgestellt werden. Beispielsweise kann ein angeschlossenes Fahrzeug mit straßenseitigen Anlagen, Edge-Systemen oder Cloud-basierten Vorrichtungen (z. B. 140) kommunizieren, die sich lokal auf einem bestimmten Straßenabschnitt befinden, wobei solche Vorrichtungen (z. B. 140) Daten (z. B. aus lokalen Sensoren (z. B. 160, 165, 170, 175, 180) oder aus Sensoren anderer Fahrzeuge gemeldete Daten), die Berechnungen (als Dienst) über durch ein Fahrzeug gelieferte Daten durchführen, um die fahrzeugeigenen Fähigkeiten zu ergänzen und/oder Informationen an vorbeifahrende oder sich nähernde Fahrzeuge weiterzuleiten (z. B. basierend auf an der Vorrichtung 140 oder aus nahegelegenen Sensorvorrichtungen gesammelten Sensordaten usw.). Ein verbundenes Fahrzeug (z. B. 105, 110, 115) kann auch oder stattdessen mit Cloud-basierten Rechensystemen (z. B. 150) kommunizieren, wobei ähnliche Speicher-, Erfassungs- und Rechenressourcen zur Verfügung stehen können, um die im Fahrzeug verfügbaren Ressourcen zu erweitern. Beispielsweise kann ein Cloud-basiertes System (z. B. 150) Sensordaten aus einer Vielzahl von Vorrichtungen an einem oder mehreren Standorten sammeln und diese Daten nutzen, um Maschinenlernmodelle zu erstellen und/oder zu trainieren, die im Cloud-basierten System verwendet werden können, um die Ergebnisse an verschiedene Fahrzeuge (z. B. 105, 110, 115) in Kommunikation mit dem Cloud-basierten System 150 zu übermitteln oder an Fahrzeuge zur Verwendung durch deren bordeigene Systeme zu „pushen“, neben anderen Beispielimplementierungen. Zugangspunkte (z. B. 145), wie z. B. Mobilfunkmasten, straßenseitige Anlagen, Netzzugangspunkte, die an verschiedenen Straßeninfrastrukturen angebracht sind, Zugangspunkte, die durch benachbarte Fahrzeuge oder Gebäude bereitgestellt werden, und andere Zugangspunkte können innerhalb einer Umgebung bereitgestellt und verwendet werden, um die Kommunikation über ein oder mehrere lokale oder Weitverkehrsnetze (z. B. 155) zwischen Cloud-basierten Systemen (z. B. 150) und verschiedenen Fahrzeugen (z. B. 105, 110, 115) zu übermitteln. Es versteht sich, dass die hier erörterten Beispiele, Merkmale und Lösungen durch derartige Infrastruktur- und Rechnersysteme vollständig durch eines oder mehrere solcher fahrzeuginternen Rechnersysteme, durch Fog- oder Edge-basierte Vorrichtungen oder durch Cloud-basierte Rechensysteme oder durch Kombinationen der Vorgenannten mittels Kommunikation und Kooperation zwischen den Systemen durchgeführt werden können.
Allgemein können „Server“, „Clients“, „Rechenvorrichtungen“, „Netzwerkelemente“, „Hosts“, „Plattformen“, „Sensorvorrichtungen“, „Edge-Vorrichtung“, „autonome Fahrsysteme“, „autonome Fahrzeuge“, „Fog-basiertes System“, „Cloud-basiertes System“ und generell „Systeme“ usw., die hier erörtert werden, elektronische Rechenvorrichtungen umfassen, die zum Empfangen, Senden/Übertragen, Verarbeiten, Speichern oder Verwalten von Daten und Informationen im Zusammenhang mit einer autonomen Fahrumgebung betrieben werden können. Wie in diesem Dokument verwendet, soll der Begriff „Computer“, „Prozessor“, „Prozessorvorrichtung“ oder „Verarbeitungsvorrichtung“ jede geeignete Vorrichtung zur Verarbeitung umfassen, einschließlich Zentraleinheiten (CPUs), grafische Verarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), digitale Signalprozessoren (DSPs), Tensorprozessoren und andere MatrixArithmetikprozessoren, neben anderen Beispielen. Zum Beispiel können Elemente, die als einzelne Vorrichtungen innerhalb der Umgebung dargestellt werden, unter Verwendung einer Vielzahl von Rechenvorrichtungen und Prozessoren implementiert werden, wie zum Beispiel Serverpools, die mehrere Servercomputer umfassen. Ferner können beliebige, alle oder einige der Vorrichtungen zur Ausführung eines beliebigen Betriebssystems angepasst sein, einschließlich Linux™, UNIX™, Microsoft™ Windows™, Apple™ macOS™, Apple™ iOS™, Google™ Android™, Windows Server™ usw., sowie virtuelle Maschinen, die zur Virtualisierung der Ausführung eines bestimmten Betriebssystems angepasst sind, einschließlich individuell angepasster und proprietärer Betriebssysteme.
Jeder der Abläufe, Verfahren, Prozesse (oder Teile davon) oder die Funktionen der verschiedenen unten beschriebenen oder in den Figuren dargestellten Komponenten können durch jede geeignete Rechenlogik, wie z. B. ein oder mehrere Module, Engines, Blöcke, Einheiten, Modelle, Systeme oder andere geeignete Rechenlogiken, durchgeführt werden. Der hierin enthaltene Verweis auf ein „Modul“, eine „Engine“, einen „Block“, eine „Einheit“, ein „Modell“, ein „System“ oder eine „Logik“ kann sich auf Hardware, Firmware, Software und/oder Kombinationen davon zur Durchführung einer oder mehrerer Funktionen beziehen. Als Beispiel kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik eine oder mehrere Hardwarekomponenten aufweisen, wie z. B. eine Steuervorrichtung oder einen Prozessor, die mit einem nichtflüchtigen Medium zum Speichern von Code verbunden sind, der dazu ausgelegt ist, durch die Steuervorrichtung oder den Prozessor ausgeführt zu werden. Daher kann sich der Verweis auf ein Modul, eine Engine, einen Block, eine Einheit, ein Modell, ein System oder eine Logik in einer Ausführungsform auf Hardware beziehen, die speziell dafür ausgelegt ist, den auf einem nichtflüchtigen Medium zu speichernden Code zu erkennen und/oder auszuführen. Ferner bezieht sich in einer anderen Ausführungsform die Verwendung eines Moduls, einer Engine, eines Blocks, einer Einheit, eines Modells, eines Systems oder einer Logik auf das nichtflüchtige Medium, das den Code aufweist, der speziell dazu angepasst ist, durch den Mikrocontroller oder Prozessor ausgeführt zu werden, um vorbestimmte Betriebsvorgänge durchzuführen. Und wie sich daraus schließen lässt, kann sich in einer weiteren Ausführungsform ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik auf die Kombination der Hardware und des nichtflüchtigen Mediums beziehen. In verschiedenen Ausführungsformen kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik einen Mikroprozessor oder ein anderes Verarbeitungselement aufweisen, das zur Ausführung von Softwareanweisungen, diskreter Logik, wie z. B. eine anwendungsspezifische integrierte Schaltung (ASIC), einer programmierten logischen Vorrichtung, wie z. B. ein Field Programmable Gate Array (FPGA), einer Speichervorrichtung mit Anweisungen, Kombinationen von logischen Vorrichtungen (z. B. wie sie auf einer gedruckten Leiterplatte zu finden wären) oder anderer geeigneter Hardware und/oder Software betrieben werden kann. Ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik kann ein oder mehrere Gatter oder andere Schaltungskomponenten aufweisen, die beispielsweise durch Transistoren implementiert sein können. In einigen Ausführungsformen kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik vollständig als Software verkörpert sein. Software kann als Softwarepaket, Code, Anweisungen, Befehlssätze und/oder Daten, die auf einem nichtflüchtigen computerlesbaren Speichermedium abgelegt sind, verkörpert sein. Firmware kann als Code, Anweisungen oder Befehlssätze und/oder Daten, die in Speichervorrichtungen hartcodiert (z. B. nichtflüchtig) sind, verkörpert sein. Ferner variieren als getrennt dargestellte logische Grenzen häufig und können sich potenziell überlappen. Beispielsweise können ein erstes und ein zweites Modul (oder mehrere Engines, Blöcke, Einheiten, Modelle, Systeme oder Logiken) Hardware, Software, Firmware oder eine Kombination davon gemeinsam nutzen, wobei möglicherweise eine unabhängige Hardware, Software oder Firmware beibehalten wird.
Die nachfolgend und in den begleitenden Figuren beschriebenen Abläufe, Verfahren und Vorgänge sind lediglich repräsentativ für Funktionen, die in bestimmten Ausführungsformen durchgeführt werden können. In anderen Ausführungsformen können zusätzliche Funktionen in den Abläufen, Verfahren und Vorgängen durchgeführt werden. In verschiedenen Ausführungsformen der vorliegenden Offenbarung werden beliebige geeignete Signalmechanismen zur Erreichung der hier beschriebenen Funktionen in Betracht gezogen. Einige der hier dargestellten Funktionen können innerhalb der Abläufe, Verfahren und Vorgänge gegebenenfalls wiederholt, kombiniert, verändert oder gelöscht werden. Darüber hinaus können die Funktionen in jeder geeigneten Reihenfolge innerhalb der Abläufe, Verfahren und Vorgänge durchgeführt werden, ohne dass vom Geltungsbereich bestimmter Ausführungsformen abgewichen wird.
Unter Bezugnahme nun auf 2 wird ein vereinfachtes Blockdiagramm 200 gezeigt, das eine Beispielimplementierung eines Fahrzeugs (und eines entsprechenden fahrzeuginternen Rechensystems) 105 mit autonomer Fahrfunktionalität veranschaulicht. In einem Beispiel kann ein Fahrzeug 105 mit einem oder mehreren Prozessoren 202 ausgestattet sein, wie z. B. Zentraleinheiten (CPUs), grafische Verarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), digitale Signalprozessoren (DSPs), Tensorprozessoren und andere Matrixarithmetikprozessoren, neben anderen Beispielen. Derartige Prozessoren 202 können mit Hardwarebeschleunigungsvorrichtungen gekoppelt sein oder integrierte Hardwarebeschleunigungsvorrichtungen (z. B. 204) aufweisen, die mit Hardware zur Beschleunigung bestimmter Verarbeitungs- und Speicherzugriffsfunktionen ausgestattet sein können, wie z. B. Funktionen im Zusammenhang mit Maschinenlerninferenz oder -training (einschließlich der unten beschriebenen Maschinenlerninferenz oder -trainingsfunktionen), Verarbeitung bestimmter Sensordaten (z. B. Kamerabilddaten, Light Detection and Ranging(LIDAR)-Sensorpunktwolken usw.), Durchführen bestimmter arithmetischer Funktionen, die sich auf das autonome Fahren beziehen (z. B. Matrixarithmetik, Faltungsarithmetik usw.), neben anderen Beispielen. Es können ein oder mehrere Speicherelemente (z. B. 206) vorgesehen sein, um maschinenausführbare Anweisungen zu speichern, die alle oder einen Teil eines der Module oder Untermodule eines auf dem Fahrzeug implementierten autonomen Fahrstacks implementieren, sowie um Maschinenlernmodelle (z. B. 256), Sensordaten (z. B. 258) und andere Daten zu speichern, die in Verbindung mit der durch das Fahrzeug auszuführenden Funktionalität des autonomen Fahrens empfangen, erzeugt oder verwendet werden (oder in Verbindung mit den hier behandelten Beispielen und Lösungen verwendet werden). Es können auch verschiedene Kommunikationsmodule (z. B. 212) bereitgestellt werden, die in Hardwareschaltungstechnik und/oder Software implementiert sind, um Kommunikationsfähigkeiten zu implementieren, die durch das Fahrzeugsystem verwendet werden, um mit anderen fremden Rechensystemen über einen oder mehrere Netzwerkkanäle, die eine oder mehrere Netzwerkkommunikationstechnologien verwenden, zu kommunizieren. Diese verschiedenen Prozessoren 202, Beschleuniger 204, Speichervorrichtungen 206 und Netzwerkkommunikationsmodule 212 können im Fahrzeugsystem über eine Vielzahl von Schnittstellen (z. B. 208) miteinander verbunden sein, die z. B. über eine oder mehrere Verbundstrukturen oder Verknüpfungen (z. B. 208) implementiert sind, wie z. B. Strukturen, die Technologien wie z. B. einen Peripheral Component Interconnect Express(PCIe)-, Ethernet-, Universal Serial Bus(USB)-, Ultra Path Interconnect(UPI)-, Controller Area Network(CAN)-Bus u. a. verwenden.
Weiter im Beispiel von 2 kann ein Beispielfahrzeug (und ein entsprechendes fahrzeuginternes Rechensystem) 105 ein automatisiertes Fahrsystem 210, Fahrsteuerungssysteme (z. B. 220), Sensoren (z. B. 225) und Benutzer-/Insassenoberfläche(n) (z. B. 230) aufweisen, neben anderen Beispielmodulen, die die Funktionalität des autonomen Fahrzeugs in Hardware und/oder Software implementieren. So kann z. B. ein automatisiertes Fahrsystem 210 in einigen Implementierungen den gesamten oder einen Teil eines autonomen Fahrstacks und Prozessablaufs implementieren (z. B. wie im Beispiel von 5 dargestellt und erörtert). Eine Maschinenlernengine 232 kann vorgesehen sein, um verschiedene im Fahrzeug 105 bereitgestellte Maschinenlernmodelle (z. B. 256) in Verbindung mit einer oder mehreren autonomen Funktionen und Merkmalen zu nutzen, die im oder für das Fahrzeug bereitgestellt und implementiert sind, wie in den Beispielen hier erörtert. Solche Maschinenlernmodelle 256 können Modelle für künstliche neuronale Netze, „Convolutional Neural Networks“, Entscheidungsbaum-basierte Modelle, Support-Vector-Machines (SVMs), Bayessche Modelle, Deep-Learning-Modelle und andere Beispielmodelle aufweisen. In einigen Implementierungen kann eine beispielhafte Maschinenlernengine 232 eine oder mehrere Modelltrainierengines 252 aufweisen, die am Training (z. B. Anfangstraining, Fortsetzungstraining usw.) eines oder mehrerer der Maschinenlernmodelle 256 beteiligt sind. Es können auch eine oder mehrere Inferenzengines 254 vorgesehen sein, um die trainierten Maschinenlernmodelle 256 zur Ableitung verschiedener Inferenzen, Vorhersagen, Klassifikationen und anderer Ergebnisse zu nutzen. In einigen Ausführungsformen kann das hier beschriebene Training des Maschinenlernmodells oder die hier beschriebene Inferenz außerhalb des Fahrzeugs durchgeführt werden, z. B. durch das Rechensystem 140 oder 150.
Die im Fahrzeug vorgesehene(n) Maschinenlernengine(s) 232 kann/können zur Unterstützung und Bereitstellung von Ergebnissen zur Verwendung durch andere logische Komponenten und Module des automatisierten Fahrsystems 210 verwendet werden, die einen autonomen Fahrstack und andere mit dem autonomen Fahren zusammenhängende Funktionen implementieren. So kann z. B. ein Datenerfassungsmodul 234 mit einer Logik versehen sein, um die Quellen zu bestimmen, aus denen Daten gesammelt werden sollen (z. B. für Eingaben zum Training oder zur Verwendung verschiedener Maschinenlernmodelle 256, die durch das Fahrzeug verwendet werden). Beispielsweise kann/können die jeweilige Quelle (z. B. interne Sensoren (z. B. 225) oder Fremdquellen (z. B. 115, 140, 150, 180, 215 usw.)) ausgewählt werden, wobei auch die Häufigkeit und Genauigkeit, mit der die Daten erfasst werden können, ausgewählt wird. In einigen Fällen können solche Auswahlen und Konfigurationen mindestens teilweise autonom durch das Datenerfassungsmodul 234 unter Verwendung eines oder mehrerer entsprechender Maschinenlernmodelle (z. B. zur Erfassung von Daten, die für ein bestimmtes erkanntes Szenario geeignet sind) ausgelegt sein.
Ebenfalls kann ein Sensorfusionsmodul 236 verwendet werden, um die Verwendung und Verarbeitung der verschiedenen Sensoreingaben zu steuern, die durch die Maschinenlernengine 232 und andere Module (z. B. 238, 240, 242, 244, 246 usw.) des fahrzeuginternen Verarbeitungssystems verwendet werden. Es können ein oder mehrere Sensorfusionsmodule (z. B. 236) vorgesehen sein, die eine Ausgabe aus mehreren Sensordatenquellen (z. B. am Fahrzeug oder fahrzeugextern) beziehen können. Die Quellen können homogene oder heterogene Arten von Quellen sein (z. B. mehrere Eingaben aus mehreren Instanzen eines gemeinsamen Sensortyps oder aus Instanzen mehrerer verschiedener Sensorarten). Ein Beispiel für das Sensorfusionsmodul 236 kann direkte Fusion, indirekte Fusion und andere Sensorfusionstechniken anwenden. Das Ergebnis der Sensorfusion kann in einigen Fällen durch Einspeisen als Eingabe (zusammen mit potentiell zusätzlichen Eingaben) in ein anderes Modul des fahrzeuginternen Verarbeitungssystems und/oder in ein oder mehrere Maschinenlernmodelle in Verbindung mit der Bereitstellung autonomer Fahrfunktionen oder anderer Funktionen, wie beispielsweise in den hier erörterten Beispiellösungen beschrieben, erfolgen.
In einigen Beispielen kann eine Wahrnehmungsengine 238 vorgesehen sein, die als Eingabe verschiedene Sensordaten (z. B. 258) hernehmen kann, in einigen Fällen einschließlich Daten aus Fremdquellen und/oder dem Sensorfusionsmodul 236, um Objekterkennung und/oder Verfolgung erkannter Objekte durchzuführen, neben anderen Beispielfunktionen entsprechend der autonomen Wahrnehmung der durch das Fahrzeug angetroffenen (oder anzutreffenden) Umgebung 105. Die Wahrnehmungsengine 238 kann die Objekterkennung aus Sensordateneingaben durch tiefes Lernen durchführen, z. B. durch ein oder mehrere „Convolutional Neural Networks“ und andere Maschinenlernmodelle 256. Die Objektverfolgung kann auch dazu durchgeführt werden, anhand von Sensordateneingaben autonom zu schätzen, ob sich ein Objekt bewegt und, falls ja, entlang welcher Bewegungsbahn. Zum Beispiel kann eine Wahrnehmungsengine 238 nach dem Erkennen eines gegebenen Objekts erkennen, wie sich das gegebene Objekt im Verhältnis zum Fahrzeug bewegt. Diese Funktionalität kann z. B. dazu verwendet werden, um Objekte wie andere Fahrzeuge, Fußgänger, Wildtiere, Radfahrer usw. zu erkennen, die sich in einer Umgebung bewegen, wodurch neben anderen Beispielanwendungen der Weg des Fahrzeugs auf einer Straße beeinflusst werden kann.
Eine Lokalisierungsengine 240 kann in einigen Implementierungen ebenfalls in einem automatisierten Fahrsystem 210 enthalten sein. In einigen Fällen kann die Lokalisierungsengine 240 als Unterkomponente einer Wahrnehmungsengine 238 implementiert sein. Die Lokalisierungsengine 240 kann auch ein oder mehrere Maschinenlernmodelle 256 und die Sensorfusion (z. B. von LIDAR- und GPS-Daten usw.) nutzen, um mit hoher Zuverlässigkeit den Standort des Fahrzeugs und den Raum, den es in einem bestimmten physischen Raum (oder einer „Umgebung“) einnimmt, zu bestimmen.
Ein Fahrzeug 105 kann ferner einen Wegplaner 242 aufweisen, der die Ergebnisse verschiedener anderer Module, wie z. B. Datenerfassung 234, Sensorfusion 236, Wahrnehmungsengine 238 und Lokalisierungsengine (z. B. 240) u. a. (z. B. Empfehlungsengine 244) nutzen kann, um einen Wegplan und/oder Maßnahmenplan für das Fahrzeug zu bestimmen, der durch eine Steuervorrichtung (z. B. 220) zur Steuerung des Fahrens des Fahrzeugs 105 innerhalb einer Umgebung verwendet werden kann. Zum Beispiel kann ein Wegplaner 242 diese Eingaben und ein oder mehrere Maschinenlernmodelle nutzen, um die Wahrscheinlichkeiten verschiedener Ereignisse innerhalb einer Fahrumgebung zu bestimmen, um effektive Echtzeitpläne zum Handeln innerhalb der Umgebung zu bestimmen.
In einigen Implementierungen kann das Fahrzeug 105 eine oder mehrere Empfehlungsengines 244 aufweisen, um verschiedene Empfehlungen aus Sensordaten zu erzeugen, die durch die eigenen Sensoren (z. B. 225) des Fahrzeugs 105 sowie Sensordaten aus Fremdsensoren (z. B. auf den Sensorvorrichtungen 115, 180, 215 usw.) erzeugt werden. Einige Empfehlungen können durch die Empfehlungsengine 244 bestimmt werden, wobei diese als Eingaben für andere Komponenten des autonomen Fahrstacks des Fahrzeugs bereitgestellt werden können, um Bestimmungen zu beeinflussen, die durch diese Komponenten vorgenommen werden. Zum Beispiel kann eine Empfehlung bestimmt werden, die, wenn sie durch einen Wegplaner 242 berücksichtigt wird, den Wegplaner 242 dazu veranlasst, von Entscheidungen oder Plänen abzuweichen, die er normalerweise ohne die Empfehlung bestimmen würde. Empfehlungen können auch durch Empfehlungsengines (z. B. 244) basierend auf Berücksichtigung des Insassenkomforts und Insassenerlebnisses erstellt werden. In einigen Fällen können die Innenausstattungen im Fahrzeug prädiktiv und autonom basierend auf diesen Empfehlungen (die basierend auf durch die Fahrzeugsensoren und/oder Fremdsensoren usw. erfassten Sensordaten (z. B. 258) bestimmt werden) verändert werden.
Wie oben vorgestellt, können einige Fahrzeugimplementierungen Benutzer-/Insassenerlebnisengines (z. B. 246) aufweisen, die Sensordaten und Ausgaben anderer Module innerhalb des Fahrstacks des autonomen Fahrzeugs nutzen können, um Fahrmanöver und Änderungen der Fahrgastraumumgebung des Fahrzeugs zu bewirken, um das Fahrerlebnis der Insassen im Fahrzeug basierend auf den aus den Sensordaten (z. B. 258) erfassten Beobachtungen zu verbessern. In einigen Fällen können Aspekte der Benutzeroberflächen (z. B. 230), die im Fahrzeug vorgesehen sind, um den Benutzern die Interaktion mit dem Fahrzeug und seinem autonomen Fahrsystem zu ermöglichen, verbessert sein. In einigen Fällen können informative Darstellungen erzeugt und über Benutzeranzeigen (z. B. Audio-, visuelle und/oder taktile Darstellungen) bereitgestellt werden, um das Fahrerlebnis der Insassen in einem Fahrzeug (z. B. 105) neben anderen Anwendungsbeispielen zu beeinflussen und zu verbessern.
In einigen Fällen kann auch ein Systemmanager 250 vorgesehen sein, der die durch verschiedene Sensoren am Fahrzeug gesammelten Informationen überwacht, um Probleme im Zusammenhang mit der Leistung des autonomen Fahrsystems eines Fahrzeugs zu erkennen. So können z. B. Rechenfehler, Sensorausfälle und - probleme, Verfügbarkeit und Qualität der Kommunikationskanäle (z. B. übermittelt durch Kommunikationsmodule 212), Prüfungen des Fahrzeugsystems (z. B. Probleme bezüglich Motor, Getriebe, Batterie, Kühlsystem, Bordnetz, Reifen usw.) oder andere Betriebsereignisse durch den Systemmanager 250 erkannt werden. Derartige Probleme können in den durch den Systemmanager 250 erzeugten Systemberichtsdaten identifiziert werden, die in einigen Fällen als Eingaben für Maschinenlernmodelle 256 und zugehörige autonome Fahrmodule (z. B. 232, 234, 236, 238, 240, 242, 244, 246 usw.) verwendet werden können, um den Zustand und Probleme des Fahrzeugsystems zusammen mit anderen Informationen, die in den Sensordaten 258 in der autonomen Fahrfunktion des Fahrzeugs 105 gesammelt werden, ebenfalls zu berücksichtigen. In einigen Implementierungen kann der Sicherheitsmanager 250 neben anderen Beispielelementen ein beispielhaftes Sicherheitsbegleitteilsystem implementieren oder verkörpern.
In einigen Implementierungen kann ein autonomer Fahrstack eines Fahrzeugs 105 mit Antriebssteuerungen 220 gekoppelt sein, um zu beeinflussen, wie das Fahrzeug gefahren wird, einschließlich Lenkungssteuerungen (z. B. 260), Gaspedal-/Drosselklappensteuerungen (z. B. 262), Bremssteuerungen (z. B. 264), Blinkersteuerungen (z. B. 266) und andere Beispiele. In einigen Fällen kann ein Fahrzeug auch ganz oder teilweise basierend auf Benutzereingaben gesteuert werden. Benutzeroberflächen (z. B. 230) können beispielsweise Bedienelemente für das Führen des Fahrzeugs aufweisen (z. B. physisches oder virtuelles Lenkrad, Gaspedal, Bremsen, Kupplung usw.), die es einem menschlichen Fahrer ermöglichen, die Kontrolle über das autonome Fahrsystem zu übernehmen (z. B. bei einer Übergabe oder nach einer Fahrerassistenzaktion). Andere Sensoren können verwendet werden, um Eingaben von Benutzern/Insassen aufzunehmen, wie z. B. Spracherkennung 292, Gestenerkennungskameras 294 und andere Beispiele. Benutzeroberflächen (z. B. 230) können die Wünsche und Absichten der Insassen/Benutzer erfassen, und der autonome Fahrstack des Fahrzeugs 105 kann diese als zusätzliche Eingaben bei der Steuerung des Fahrens des Fahrzeugs berücksichtigen (z. B. Fahrsteuerungen 220). In einigen Implementierungen können die Fahrsteuerungen durch externe Rechensysteme übernommen werden, wie z. B. in Fällen, in denen ein Insasse eine externe Vorrichtung (z. B. ein Smartphone oder Tablet) verwendet, um die Fahrtrichtung oder die Steuerung vorzugeben, oder in Fällen eines entfernten Dienstanbieters, in denen ein externer Fahrer oder ein externes System die Steuerung des Fahrzeugs übernimmt (z. B. aufgrund eines Notfallereignisses), neben anderen Beispielimplementierungen.
Wie oben erörtert, kann der autonome Fahrstack eines Fahrzeugs eine Vielzahl von Sensordaten (z. B. 258) nutzen, die durch verschiedene Sensoren am und außerhalb des Fahrzeugs erzeugt werden. Beispielsweise kann ein Fahrzeug 105 über eine Reihe von Sensoren 225 verfügen, um verschiedene Informationen über die Außenseite des Fahrzeugs und die Umgebung, den Zustand des Fahrzeugsystems, die Bedingungen im Fahrzeug und andere Informationen zu sammeln, die durch die Module des automatisierten Fahrsystems 210 des Fahrzeugs genutzt werden können. Diese Sensoren 225 können z. B. Global Positioning(GPS)-Sensoren 268, Light Detection and Ranging(LIDAR)-Sensoren 270, zweidimensionale(2D)-Kameras 272, dreidimensionale(3D)- oder Stereokameras 274, akustische Sensoren 276, Inertial Measurement Unit(IMU)-Sensoren 278, Wärmesensoren 280, Ultraschallsensoren 282, Biosensoren 284 (z. B. Gesichtserkennung, Spracherkennung, Herzfrequenzsensoren, Körpertemperatursensoren, Emotionserkennungssensoren usw.), Radarsensoren 286, Wettersensoren (nicht abgebildet) neben anderen Beispielsensoren umfassen. Sensordaten 258 können auch (oder stattdessen) durch Sensoren erzeugt werden, die nicht fest mit dem Fahrzeug gekoppelt sind, einschließlich Sensoren an anderen Fahrzeugen (z. B. 115) (die über Fahrzeug-zu-Fahrzeug-Kommunikation oder andere Techniken an das Fahrzeug übermittelt werden können 105), Sensoren an bodengebundenen oder fliegenden Drohnen 180, Sensoren von Benutzervorrichtungen 215 (z. B. ein Smartphone oder eine am Körper tragbare Vorrichtung), die durch menschliche Benutzer innerhalb oder außerhalb des Fahrzeugs getragen werden 105, und Sensoren, die an anderen straßenseitigen Elementen angebracht oder mit diesen versehen sind, wie z. B. einer straßenseitigen Anlage (z. B. 140), einem Straßenschild, einer Ampel, einer Straßenbeleuchtung usw. Sensordaten aus solchen fremden Sensorvorrichtungen können direkt aus den Sensorvorrichtungen an das Fahrzeug geliefert werden, oder sie können durch Datenaggregationsvorrichtungen oder als Ergebnisse, die anhand dieser Sensoren durch andere Rechensysteme (z. B. 140, 150) erzeugt werden, neben anderem Beispielimplementierungen, bereitgestellt werden.
In einigen Implementierungen kann ein autonomes Fahrzeugsystem 105 mit Informationen und Diensten, die durch andere Rechensysteme bereitgestellt werden, zusammenarbeiten und diese nutzen, um die autonome Fahrfunktionalität der Vorrichtung 105 zu verbessern, zu ermöglichen oder anderweitig zu unterstützen. In einigen Fällen können einige autonome Fahrfunktionen (einschließlich einiger der hier besprochenen Beispiellösungen) durch Dienste, Rechenlogik, Maschinenlernmodelle, Daten oder andere Ressourcen von Rechensystemen außerhalb eines Fahrzeugs ermöglicht werden. Wenn solche externen Systeme für ein Fahrzeug nicht verfügbar sind, kann es sein, dass diese Funktionen zumindest vorübergehend deaktiviert sind. Beispielsweise können externe Rechensysteme bereitgestellt und genutzt werden, die in straßenseitigen Anlagen oder Fog-basierten Edge-Vorrichtungen (z. B. 140), anderen (z. B. übergeordneten) Fahrzeugen (z. B. 115) und Cloud-basierten Systemen 150 (z. B. über verschiedene Netzwerkzugangspunkte zugänglich (z. B. 145)) untergebracht sind. Eine straßenseitige Anlage 140 oder ein Cloud-basiertes System 150 (oder ein anderes kooperierendes System, mit dem ein Fahrzeug (z. B. 105) interagiert, kann die gesamte oder einen Teil der Logik aufweisen, die als zu einem fahrzeuginternen automatisierten Fahrsystem (z. B. 210) gehörend dargestellt ist, zusammen mit möglicherweise zusätzlichen Funktionen und Logiken. Zum Beispiel kann ein Cloud-basiertes Rechensystem, eine straßenseitige Anlage 140 oder ein anderes Rechensystem eine Maschinenlernengine aufweisen, die entweder Modelltrainingslogik oder Inferenzenginelogik oder beides unterstützen kann. Solche externen Systeme können beispielsweise über höherwertige Rechenressourcen und weiterentwickelte oder aktuelle Maschinenlernmodelle verfügen, sodass diese Dienste bessere Ergebnisse liefern können als das, was nativ auf einem automatisierten Fahrsystem 210 eines Fahrzeugs erzeugt würde. Beispielsweise kann ein automatisiertes Fahrsystem 210 für bestimmte Aufgaben und die Bearbeitung bestimmter Szenarien auf Maschinenlerntraining, Maschinenlerninferenz und/oder Maschinenlernmodellen beruhen, die über einen Cloud-basierten Dienst bereitgestellt werden.
Es versteht sich, dass ein oder mehrere der erörterten und als zum Fahrzeug 105 gehörend dargestellten Module in einigen Implementierungen alternativ oder redundant innerhalb eines Cloud-basierten, Fog-basierten oder anderen Rechensystems, das eine autonome Fahrumgebung unterstützt, bereitgestellt werden können.
In 3 ist ein vereinfachtes Blockdiagramm 300 dargestellt, das beispielhafte Stufen des autonomen Fahrens zeigt, die in verschiedenen Fahrzeugen (z. B. durch entsprechende bordeigene Rechensysteme) unterstützt werden können. Beispielsweise kann eine Reihe von Stufen definiert werden (z. B. L0-L5 (405-435)), wobei Stufe 5 (L5) den Fahrzeugen mit der höchsten Stufe autonomer Fahrfunktionalität (z. B. Vollautomatisierung) und Stufe 0 (L0) der niedrigsten Stufe autonomer Fahrfunktionalität (z. B. keine Automatisierung) entspricht. Beispielsweise kann ein L5-Fahrzeug (z. B. 335) über ein vollständig autonomes Rechensystem verfügen, das in der Lage ist, in jedem Fahrszenario eine autonome Fahrleistung zu erbringen, die selbst bei extremen Straßen- und Witterungsbedingungen gleich oder besser als die eines menschlichen Fahrers ist. Ein L4-Fahrzeug (z. B. 330) kann auch als vollständig autonom betrachtet werden und in der Lage sein, sicherheitskritische Fahrfunktionen autonom durchzuführen und den Straßenzustand während der gesamten Fahrt von einem Startort zu einem Zielort wirksam zu überwachen. L4-Fahrzeuge können sich von L5-Fahrzeugen dadurch unterscheiden, dass die autonomen Fähigkeiten eines L4-Fahrzeugs innerhalb der Grenzen der „betrieblichen Konstruktionsdomäne“ des Fahrzeugs definiert sind, die möglicherweise nicht alle Fahrszenarien aufweisen. L3-Fahrzeuge (z. B. 320) bieten eine autonome Fahrfunktionalität, um sicherheitskritische Funktionen unter bestimmten Verkehrs- und Umgebungsbedingungen vollständig auf das Fahrzeug zu verlagern, wobei jedoch in allen anderen Szenarien der Einsatz und die Verfügbarkeit von menschlichen Fahrern zur Durchführung des Fahrens erwartet wird. Dementsprechend können L3-Fahrzeuge Übergabeprotokolle bereitstellen, um die Übergabe der Steuerung von einem menschlichen Fahrer an den autonomen Fahrstack und zurück zu regeln. L2-Fahrzeuge (z. B. 315) bieten Fahrerassistenzfunktionen, die es dem Fahrer ermöglichen, sich gelegentlich vom physischen Betrieb des Fahrzeugs zu lösen, wobei sowohl die Hände als auch die Füße des Fahrers periodisch von den physischen Steuervorgängen des Fahrzeugs abgekoppelt sein können. L1-Fahrzeuge (z. B. 310) unterstützen den Fahrer bei einer oder mehreren spezifischen Funktionen (z. B. Lenken, Bremsen usw.), erfordern aber dennoch eine ständige Kontrolle des Fahrers über die meisten Funktionen des Fahrzeugs. L0-Fahrzeuge können als nicht autonom angesehen werden. Der menschliche Fahrer steuert die gesamte Fahrfunktionalität des Fahrzeugs (obwohl solche Fahrzeuge dennoch passiv an autonomen Fahrumgebungen teilnehmen können, z. B. durch Bereitstellen von Sensordaten für Fahrzeuge auf höheren Stufen, durch Nutzen von Sensordaten zur Verbesserung von GPS- und Infotainment-Diensten im Fahrzeug usw.). In einigen Implementierungen kann ein einzelnes Fahrzeug den Betrieb auf mehreren autonomen Fahrstufen unterstützen. Beispielsweise kann ein Fahrer steuern und auswählen, welche unterstützte Autonomiestufe während einer bestimmten Fahrt verwendet wird (z. B. L4 oder eine niedrigere Stufe). In anderen Fällen kann ein Fahrzeug autonom zwischen den Stufen umschalten, z. B. basierend auf Bedingungen, die die Fahrbahn oder das autonome Fahrsystem des Fahrzeugs betreffen. Beispielsweise kann ein Fahrzeug der Stufe L5 oder L4 als Reaktion auf das Erkennen einer Beeinträchtigung eines oder mehrerer Sensoren in einen niedrigeren Modus (z. B. L2 oder niedriger) wechseln, um aufgrund der Sensorproblematik einen menschlichen Insassen einzubeziehen, neben anderen Beispielen.
4 ist ein vereinfachtes Blockdiagramm 400, das einen beispielhaften autonomen Fahrablauf zeigt, der in einigen autonomen Fahrsystemen implementiert sein kann. Beispielsweise kann ein autonomer Fahrablauf, der in einem autonomen (oder halbautonomen) Fahrzeug implementiert ist, eine Erfassungs- und Wahrnehmungsstufe 405, eine Planungs- und Entscheidungsstufe 410 und eine Steuerungs- und Aktionsphase 415 aufweisen. Während einer Erfassungs- und Wahrnehmungsstufe werden 405 Daten durch verschiedene Sensoren erzeugt und zur Verwendung durch das autonome Fahrsystem gesammelt. Die Datensammlung kann in einigen Fällen eine Datenfilterung und den Empfang von Sensoren aus externen Quellen aufweisen. Diese Stufe kann auch Sensorfusionsvorgänge und Objekterkennung und andere Wahrnehmungsaufgaben, wie z. B. Lokalisierung, aufweisen, die mittels eines oder mehrerer Maschinenlernmodelle durchgeführt werden. Eine Planungs- und Entscheidungsstufe 410 kann die Sensordaten und die Ergebnisse verschiedener Wahrnehmungsvorgänge nutzen, um probabilistische Vorhersagen über die vorausliegende(n) Straße(n) zu treffen und einen Echtzeitwegplan basierend auf diesen Vorhersagen zu bestimmen. Eine Planungs- und Entscheidungsstufe 410 kann zusätzlich das Treffen von Entscheidungen in Bezug auf den Wegplan als Reaktion auf das Erkennen von Hindernissen und anderen Ereignissen aufweisen, um zu entscheiden, ob und welche Maßnahmen zu ergreifen sind, um den bestimmten Weg angesichts dieser Ereignisse sicher zu befahren. Basierend auf dem Wegplan und den Entscheidungen der Planungs- und Entscheidungsstufe 410 kann eine Steuerungs- und Aktionsstufe 415 diese Bestimmungen in Aktionen umsetzen durch Aktoren zur Betätigung der Fahrsteuerungselemente einschließlich Lenken, Beschleunigen und Bremsen sowie sekundäre Steuerelemente wie Blinker, Sensorreiniger, Scheibenwischer, Scheinwerfer usw. Dementsprechend kann gemäß 5 die allgemeine Funktion eines automatisierten Fahrsystems 210 die Eingaben einer oder mehrerer Sensorvorrichtungen 225 (z. B. mehrere Sensoren verschiedener Arten) nutzen und diese Vorgänge verarbeiten, um eine Bestimmung für das automatisierte Fahren eines Fahrzeugs vorzunehmen. Um die Durchführung des automatisierten Fahrens (z. B. Beschleunigen, Lenken, Bremsen, Blinkerbetätigen usw.) zu realisieren, kann das automatisierte Fahrsystem 210 ein oder mehrere Ausgabesignale erzeugen, um die bestimmenden automatisierten Fahrvorgänge zu implementieren, und diese Signale an eine oder mehrere Steuervorrichtungen, oder allgemeiner „Aktoren“ 220, senden, die dazu verwendet werden, das entsprechende Fahrzeug zum Durchführen dieser Fahrvorgänge zu veranlassen.
6 ist ein vereinfachtes Blockdiagramm, das das beispielhafte Zusammenspiel von Komponenten und Logik zur Implementierung eines automatisierten Fahrsystems im Fahrzeug gemäß einer Beispielimplementierung veranschaulicht. Beispielsweise kann eine Vielzahl von Sensoren und Logiken bereitgestellt werden, die Daten erzeugen, die durch das automatisierte Fahrsystem verwendet werden können, wie z. B. Trägheitsmesseinheiten (IMUs) 605, Odometrielogik 610, Bordsensoren 615, GPS-Sensoren 268, Kartendaten 620, Wegpunktdaten und Logik (z. B. 625), Kameras (z. B. 272), LIDAR-Sensoren 270, Kurzstreckenradarsensoren 286a, Langstreckenradarsensoren 286b, vorausschauender Infrarotsensor (FLIR) 630, neben anderen Beispielsensoren. Zusätzliche Informationen können aus fahrzeugexternen Quellen (z. B. über ein Netzwerk, das die Kommunikation zwischen Fahrzeug und allem (V2X) ermöglicht (z. B. 635)) oder vom Fahrzeugbenutzer (z. B. Fahrtziele (z. B. 640) oder andere Eingaben der Insassen im Fahrzeug (z. B. durch Mensch-Maschine-Schnittstellen (z. B. 230)) übermittelt werden. Einige dieser Eingaben können einer Wahrnehmungsengine 238 zur Verfügung gestellt werden, die die in den Sensordaten enthaltenen Informationen, die durch einen oder eine Kombination der Fahrzeugsensoren (oder sogar durch externe (z. B. straßenseitige) Sensoren) erzeugt werden, auswerten und eine Objekterkennung (z. B. zur Identifizierung potenzieller Gefahren und Straßeneigenschaften) durchführen, die Objekte klassifizieren (z. B. zur Bestimmung, ob es sich um Gefahren handelt oder nicht) und Objekte verfolgen (z. B. zur Bestimmung und Vorhersage der Bewegung der Objekte und zur Feststellung, ob oder wann die Objekte das Fahren des Fahrzeugs beeinträchtigen könnten).
Andere Sensoren und Logiken (z. B. 268, 620, 625 usw.) können der Lokalisierungs- und Positionierungslogik (z. B. 240) des automatisierten Fahrsystems zugeführt werden, um eine genaue und präzise Lokalisierung des Fahrzeugs durch das automatisierte Fahrsystem zu ermöglichen (z. B. um die Geolokalisierung des Fahrzeugs sowie seine Position im Verhältnis zu bestimmten tatsächlichen oder erwarteten Gefahren usw. zu verstehen). Die Ergebnisse der Wahrnehmungsengine 230 und der Lokalisierungsengine 240 können gemeinsam durch die Wegplanungslogik 242 des automatisierten Fahrsystems genutzt werden, sodass das Fahrzeug selbsttätig direkter und sicher auf ein gewünschtes Ergebnis zusteuert. Eine Planungslogik für das Fahrverhalten (z. B. 650) kann in einigen Implementierungen ebenfalls vorgesehen sein, um Fahrziele (z. B. Ziele auf Systemebene oder benutzerdefinierte Ziele) zu berücksichtigen, um bestimmte Erwartungen an das Fahrverhalten oder den Benutzerkomfort zu erfüllen (z. B. Geschwindigkeit, Komfort, Verkehrsvermeidung, Vermeidung von Mautstraßen, Priorisierung landschaftlich reizvoller Strecken oder Strecken, die das Fahrzeug in der Nähe bestimmter Sehenswürdigkeiten oder Annehmlichkeiten halten, usw.). Die Ausgabe des Fahrverhaltensplanungsmoduls 650 kann auch in eine Wegplanungsengine 242 eingespeist und durch diese bei der Bestimmung des günstigsten Weges für das Fahrzeug berücksichtigt werden.
Eine Wegplanungsengine 242 kann über den durch ein Fahrzeug zu nehmenden Weg entscheiden, wobei eine Bewegungsplanungsengine 655 die Aufgabe hat, zu bestimmen, „wie“ dieser Weg zu realisieren ist (z. B. durch die Fahrsteuerungslogik (z. B. 220) des Fahrzeugs). Die Fahrsteuerungslogik 220 kann auch den gegenwärtigen Zustand des Fahrzeugs berücksichtigen, der mittels einer Fahrzeugzustandsschätzengine 660 bestimmt wird. Die Fahrzeugzustandsschätzengine 660 kann den gegenwärtigen Zustand des Fahrzeugs bestimmen (z. B. in welche(n) Richtung(en) es sich gerade bewegt, welche Geschwindigkeit es fährt, ob es beschleunigt oder verzögert (z. B. bremst) usw.), was bei der Bestimmung berücksichtigt werden kann, welche Fahrfunktionen des Fahrzeugs wie zu betätigen sind (z. B. unter Verwendung einer Fahrsteuerungslogik 220). Beispielsweise können einige der Sensoren (z. B. 605, 610, 615 usw.) als Eingaben für die Fahrzeugzustandsschätzengine 660 bereitgestellt werden, und es können Steuerzustandsinformationen erzeugt und der Fahrsteuerungslogik 220 zur Verfügung gestellt werden, die zusammen mit Bewegungsplanungsdaten berücksichtigt werden können (z. B. von der Bewegungsplanungsengine 655), um die verschiedenen Aktoren des Fahrzeugs so zu steuern, dass sie den gewünschten Weg genau, sicher und komfortabel umsetzen (z. B. durch Betätigen von Lenkungssteuerungen (z. B. 260), Drosselklappe (z. B. 262), Bremse (z. B. 264), Karosseriesteuerungen (z. B. 665) usw.), neben anderen Beispielen.
Zur Beurteilung der Leistung des automatisierten Fahrsystems und seiner kollektiven Komponenten können in einigen Implementierungen auch ein oder mehrere Systemverwaltungswerkzeuge (z. B. 670) bereitgestellt werden. Beispielsweise können die Systemverwaltungswerkzeuge 670 unter anderem eine Logik zur Erkennung und Protokollierung von Ereignissen und verschiedenen Daten aufweisen, die durch das automatisierte Fahrsystem gesammelt und/oder erzeugt werden, um beispielsweise Trends zu erkennen, die durch das automatisierte Fahrsystem verwendeten Maschinenlernmodelle zu verbessern oder zu trainieren und potenzielle Sicherheitsprobleme oder -fehler zu identifizieren und zu beheben. In der Tat kann das Systemmanagementwerkzeug 670 in einigen Implementierungen Sicherheitsteilsysteme oder Begleitwerkzeuge aufweisen (z. B., wie hier ausführlicher behandelt) und ferner Werkzeuge zur Fehlererkennung und - behebung enthalten, neben anderen Beispielwerkzeugen und verwandten Funktionen.
Es versteht sich, dass die Automatisierung von Fahrzeugen bei falscher oder unzureichender Umsetzung die Gefahr katastrophaler Verletzungen und Schäden nicht nur für die Insassen des automatisierten Fahrzeugs, sondern auch für die Insassen anderer Fahrzeuge, die die Straße mitbenutzen, Fußgänger und Radfahrer, Gebäude, öffentliche Infrastruktur usw. aufweisen kann. Dementsprechend können Sicherheitsmechanismen und Teilsysteme innerhalb eines Fahrzeugs eingesetzt werden, um den ordnungsgemäßen Betrieb des Fahrzeugs zu unterstützen. In der Tat können Mindestsicherheitsstandards für bestimmte Elemente des automatisierten Fahrsystems 210 eines Fahrzeugs und der zugehörigen Sensoren, Aktoren und Teilsysteme sowohl einzeln als auch gemeinsam definiert werden (z. B. eine aggregierte Sicherheitsbewertung für die Kombination von Elementen, die die automatisierte Fahrfunktionalität des Fahrzeugs implementieren). Zum Beispiel hat die Internationale Organisation für Normung (ISO) die ISO 26262 mit dem Titel „Straßenfahrzeuge - Funktionale Sicherheit“ definiert, die Mindeststandards sowie ein Risikoklassifizierungsschema für die Fahrzeugsicherheit, wie z. B. den Automotive Safety Integrity Level (ASIL), aufweist. Damit ein automatisiertes Fahrsystem und ein autonomes Fahrzeug als ausreichend sicher angesehen werden können, um auf Straßen zugelassen zu werden, oder damit Komponenten oder Teilsysteme des Fahrzeugs als sicher genug angesehen werden, um in solchen Fahrzeugen eingesetzt werden zu können, müssen die Systeme und Komponenten in einigen Fällen bestimmte Sicherheitsstandards und Vorschriften erfüllen (z. B. gemäß ASIL-Normen), neben anderen Beispielen.
Um ein autonomes Fahrzeug mit Systemen zu implementieren, die ASIL oder andere Sicherheitsanforderungen erfüllen, können einige Implementierungen Fähigkeiten zur Laufzeit-Fehlermilderung aufweisen, die für das automatisierte Fahrsystem in jeder im Fahrzeug verwendeten Hardwarekomponente erforderlich sind. Dies kann das Hinzufügen der während des Systembetriebs erforderlichen Einrichtungen zum Erkennen, Steuern, Melden und möglicherweise Wiederherstellen nach Ausfällen zu jeder Hardwarekomponente in einem automatisierten Fahrsystem erfordern. In anderen Implementierungen können die Hardware und die zugehörige Software, die zur Durchführung der Fahrzeugautomatisierung verwendet werden, bewusst in mehrere Module repliziert werden, wodurch Sicherheit durch Redundanz (z. B. Doppel-, Dreifach- oder N-modulare Redundanz) erreicht wird. Darüber hinaus können solche Komponenten zwar redundant, aber dennoch unter Verwendung verschiedener Architekturen implementiert werden (z. B. mehrere Komponenten derselben Art, aber mit unterschiedlichen Architekturen oder Implementierungen), um eine gewisse Diversität bei der Implementierung zu realisieren und systematische Hardwarefehler (z. B. Siliziumfehler) zu erkennen. In solchen Fällen können Fehler erkannt, kontrolliert und durch den Vergleich von Zwischen- und Endergebnissen zwischen den N Modulen, unter anderem durch Beispielimplementierungen, gemeldet werden.
Wie oben veranschaulicht, sind automatisierte Fahrsysteme jedoch komplexer Natur und weisen viele Hardwarekomponenten auf (z. B. CPU, Arbeitsspeicher, Massenspeicher, Beschleuniger, Netzwerkkomponenten usw.). Das Einbringen aller Funktionen zur Laufzeit-Fehlermilderung in jede einzelne Hardwarekomponente kann sowohl im Hinblick auf Forschung und Entwicklung (F&E) als auch auf die Produktkosten untragbar sein. Darüber hinaus stehen die Fähigkeiten zur Fehlermilderung möglicherweise in direktem Wettbewerb mit den für andere Funktionen und Leistungen erforderlichen Ressourcen (F&E, Werkzeugbereich usw.) und können dazu führen, dass Hardwarekomponenten basierend auf den spezifischen Anforderungen nur eines der Märkte, in denen die Hardwarekomponente eingesetzt wird, belastet werden. Darüber hinaus können Implementierungen, die auf modularer Redundanz beruhen, für ein System übermäßig teuer und komplex sein. Wenn beispielsweise die Replikation kompletter Hard- und Software erforderlich ist, führt dies zu einer entsprechenden Vervielfachung der zusätzlichen Kosten, des Stromverbrauchs und des Platzbedarfs, was solche Systeme potenziell unerschwinglich und kommerziell unpraktikabel macht.
In einigen Implementierungen kann eine verbesserte Sicherheitsplattform in Verbindung mit einem automatisierten Fahrsystem eines autonomen Fahrzeugs implementiert sein, die zumindest einige der oben genannten Beispielprobleme behebt. Beispielsweise wird ein System bereitgestellt, das eine kostengünstige, modulare, unabhängige Sicherheitsüberwachung von Laufzeitfehlern in einem automatisierten Fahrrechensystem implementiert, das sicherheitskritische automatisierte Fahraufgaben durchführt. Eine verbesserte Implementierung eines Sicherheitssystems kann eine Architektur und kooperative Struktur über zwei diskrete, verteilte Systeme hinweg für eine unabhängige softwarebasierte Sicherheitsüberwachung von autonomen Fahranwendungen bieten. Die Softwarekomponente zur Sicherheitsüberwachung der Architektur kann unabhängig die an dem automatisierten Fahrsystem beteiligte Rechenhardware (z. B. die zur Ausführung der Logik des automatisierten Fahrsystems verwendete Rechenhardware sowie die zur Ausführung des Sicherheitsmanagements oder der Begleitlogik verwendete Rechenhardware) und die Anwendung(en) des automatisierten Fahrsystems (z. B. Software, Firmware usw.) überwachen. Ferner kann die Softwarekomponente zur Sicherheitsüberwachung sicherheitsrelevante Vorgänge erfassen und verarbeiten und gewährleistet die Unabhängigkeit zwischen den beiden Teilsystemen.
Eine solche Architektur kann eine Zerlegung der auf den beiden Teilsystemen implementierten Sicherheitsstandards und -merkmale ermöglichen (z. B. wenn die Teilsysteme unterschiedliche ASIL-Einstufungen aufweisen).
Beispielsweise kann eine niedrigere ASIL-Zuordnung auf dem komplexeren automatisierten Fahrrechenteilsystem implementiert werden, während eine vergleichsweise höhere (z. B. die höchste) ASIL-Zuordnung auf dem relativ einfacheren (aus logischer und rechnerischer Sicht betrachteten) Sicherheitsbegleitteilsystem implementiert wird. Eine solche Architektur kann es Kunden zusätzlich ermöglichen, den Entwicklungszeitplan ihrer automatisierten Fahrsysteme und Anwendungen von der Entwicklung von Hard- und Software für die Sicherheitsüberwachung zu entkoppeln. Ersteres kann basierend auf den zu unterstützenden anwendungs- oder fahrzeugspezifischen Einsatzfällen optimiert werden, während Letzteres basierend auf der erforderlichen Fehlerüberwachung und dem Melden von Fehlern optimiert werden kann, wobei gleichzeitig ein System ermöglicht wird, das in der Summe die Schwellenwerte der Mindestsicherheitsstandards einhält (z. B. aggregierte ASIL-Bewertung). Eine solche Architektur kann u. a. eine schnellere Entwicklung automatisierter Fahrsysteme und eine kosteneffektivere F&E für Systemhardware und -software ermöglichen.
7 ist ein vereinfachtes Blockdiagramm 700, das eine beispielhafte Architektur eines automatisierten Fahrsystems 210 zeigt, das ein zweigeteiltes automatisiertes Fahrrechenteilsystem 705 und ein unabhängiges Sicherheitsbegleitteilsystem 710 aufweist. Sowohl das Rechenteilsystem 705 als auch das Sicherheitsbegleitteilsystem 710 weisen jeweils eine separate Mikrocontrollereinheit (MCU) (z. B. 715, 720) und computerimplementierte Logik (z. B. 725, 730) auf, die dazu ausgelegt sind, durch die jeweilige MCU des Teilsystems (z. B. 715, 720) effizient ausgeführt zu werden. Als kombiniertes System 210 führt das automatisierte Fahrsystem 710 Fahraufgaben durch, die sonst durch einen menschlichen Fahrer durchgeführt würden. Das automatisierte Fahrsystem kann beispielsweise Funktionen zur Überwachung der Fahrumgebung (z. B. Erfassen, Klassifizieren und Erkennen statischer und dynamischer Objekte auf der Fahrbahn), zur Entscheidung über die Reaktion des Fahrzeugs, zur Planung der Fahrzeugbewegung in Quer- (Lenkung) und Längsrichtung (Beschleunigung und Verlangsamung) und zur Steuerung der Fahrzeugbewegung neben anderen möglichen Funktionen aufweisen. Generell besteht die Umsetzung der dynamischen Fahraufgaben durch das automatisierte Fahrsystem aus dem Empfangen von Sensoreingaben, dem Berechnen eines sicheren Fahrverhaltens des Fahrzeugs basierend auf den Sensoreingaben und dem Übertragen der bestimmten Fahrbefehle an die Aktoren (siehe auch 5). Wie oben erörtert, kann von dem Gesamtsystem (z. B. 210), das für die Durchführung der Berechnung des Fahrverhaltens verantwortlich ist, verlangt werden, dass es dies auf funktional sichere Weise durchführt und strenge standardisierte Anforderungen (z. B. ASIL-Normen) erfüllt.
Jedoch können die durch das System 210 vorgenommenen Berechnungen durch zufällige Hardwarefehler (z. B. weiche und harte Fehlfunktionen in der Hardware) und systematische Ausfälle (z. B. Hardware- und Softwarefehler/-fehlfunktionen) beeinträchtigt werden. Beide Arten von Fehlfunktionen können zu gefährlichen Ereignissen führen, bei denen Menschen zu Schaden kommen können, wie z. B. seitliche, frontale oder rückwärtige Kollisionen mit anderen Fahrzeugen, Fußgänger- und Radfahrerunfälle, Zusammenstöße mit statischen Objekten am Straßenrand (z. B. Leitplanken, Bordsteine, Zäune, Leitungsmasten, Vegetation), neben anderen möglichen Gefahren.
In einer Beispielimplementierung kann das Rechenteilsystem 705 dazu ausgelegt sein, automatisierte Fahraufgaben durchzuführen, während das Sicherheitsbegleitteilsystem 710 die Aufgabe hat, durch das Sicherheitsbegleitteilsystem 710 erkannte Fehlfunktionen des Rechenteilsystems 705 zu überwachen und möglicherweise zu korrigieren oder zumindest abzuschwächen. Durch Bereitstellen einer Architektur und einer kooperativen Struktur über zwei verteilte Systeme zur unabhängigen softwarebasierten Sicherheitsüberwachung der automatisierten Fahrsysteme können automatisierte Fahrfunktion, Redundanz und Systemvielfalt zur Realisierung der erforderlichen Sicherheitsstandards genutzt werden, wobei gleichzeitig ein modularisierter Ansatz zur Verfügung steht, der eine höhere Lastenminderung in der Forschung und Entwicklung sowie eine aufgeteilte Entwicklung und Verbesserungen der Teilsysteme ermöglichen kann. Beispielsweise kann eine aggregierte Sicherheitsstandardmetrik, die für die Implementierung des gesamten automatisierten Fahrsystems 210 erforderlich ist, wie z. B. ein Schwellenwert für den ASIL-Wert, über das Rechenteilsystem 705 und das Sicherheitsbegleitteilsystem 710 aufgeteilt werden. Dementsprechend können Funktionalität und Merkmale des Sicherheitsbegleitteilsystems 710 im Vergleich zu denen des Rechenteilsystems 710 verbessert werden. Beispielsweise kann das Sicherheitsbegleitteilsystem 710 mit erweiterten Sicherheitsgewährleistungsfähigkeiten ausgestattet sein, wie z. B. periodische Selbsttests der Kerne, On-Chip-Speicher (Cache- und Registerdateien, die sowohl Arrays als auch Logik aufweisen), On-Chip-Speicher-Controllerlogik, On-Chip-PCIe-Controllerlogik, On-Chip-Speicherkohärenzlogik usw. Als zusätzliches Beispiel kann das Sicherheitsbegleitteilsystem 710 dazu ausgelegt sein, die Laufzeitüberwachung von integrierten On-Chip-Spannungsreglern und On-Chip-Taktgebern und Phase-Locked-Loop(PPL)-Schaltkreisen sowie andere Selbstüberwachungsfunktionen, neben anderen Beispielfunktionen, durchzuführen. Dementsprechend kann durch die relativ verbesserten Eigenschaften des Sicherheitsbegleitteilsystems 710 (gegenüber dem Rechenteilsystem 705) eine ASIL-Zerlegung erreicht werden, die die Zuordnung verschiedener ASIL-Einstufungen für die Sicherheitsanforderungen ermöglicht, die jeweils dem Rechenteilsystem 705 und dem Sicherheitsbegleitteilsystem 710 zugeordnet sind. Insbesondere erlaubt die ASIL-Zerlegung, dass die durch das Rechenteilsystem 705 erfüllten Sicherheitsanforderungen (die beabsichtigte Funktionalität des automatisierten Fahrens) einen niedrigeren ASIL als die Sicherheitsanforderungen aufweisen, die durch das Sicherheitsbegleitteilsystem 710 (das die Sicherheitsmechanismen für das automatisierte Fahren bereitstellt) erfüllt werden. Beispielsweise kann das Rechenteilsystem 705 ASIL-QM-Fähigkeiten bieten, während das Sicherheitsbegleitteilsystem 710 neben anderen Implementierungen und spezifischen ASIL-Kombinationen/-Beiträgen auch ASIL-D-Fähigkeiten bietet.
Durch eine solche unausgewogene ASIL-Zerlegung zwischen dem Rechenteilsystem 705 und dem Sicherheitsbegleitteilsystem 710 können die ASIL-Gesamtanforderungen dennoch erfüllt werden, wobei die Investitionen in die Sicherheitstechnik auf das Sicherheitsbegleitteilsystem 710 konzentriert werden können, was angesichts der komplexeren Funktionalität und Logik des Rechenteilsystems 705 (im Vergleich zum Sicherheitsbegleitteilsystem 710) von Vorteil sein kann. In der Tat kann der gesamte Forschungs- und Entwicklungsaufwand für die Implementierung einer solchen Architektur geringer sein, als wenn das Rechenteilsystem 705 allein alle Sicherheitsfunktionen implementieren würde, neben anderen Beispielvorteilen.
Um mit dem Beispiel von 7 fortzufahren, kann ein beispielhaftes Sicherheitsbegleitteilsystem 710 über eine Überwachungsschnittstelle 740 auf Daten zugreifen, die im Rechenteilsystem 705 erzeugt werden, um zu bestimmen, ob das Rechenteilsystem 705 korrekt arbeitet, um eine sichere automatisierte Fahrfunktionalität zu implementieren. Das Sicherheitsbegleitteilsystem 710 kann sowohl die softwareimplementierten Anwendungen (z. B. im Verarbeitungskomplex 725 des Rechenteilsystems 705 implementiert) überwachen, wie z. B. Software zur Implementierung von Objekterkennung, Objektverfolgung, Wegplanung, Lokalisierung und Positionierung, Schätzung des Fahrzeugzustands und Signalisierung an eine Steuervorrichtung, neben anderen Merkmalen und Funktionen. Das Sicherheitsbegleitteilsystem 710 kann auch den Betrieb der Hardware des Rechenteilsystems überwachen, einschließlich des/der Mikrocontroller (z. B. 715) der Systemhardware, der Hardwarebeschleuniger und anderer in Hardware implementierter Logik und Prozessoren, die zur Ausführung der Software des Rechenteilsystem-Verarbeitungskomplexes 725 verwendet werden. Ferner kann das Sicherheitsbegleitteilsystem 710 in einigen Implementierungen eine Logik aufweisen, die die korrekte Funktion der eigenen Hardware (z. B. das Sicherheitsbegleitteilsystem MCU 720) überwacht, um zu bestimmen, ob die durch das Sicherheitsbegleitteilsystem 710 bereitgestellte Sicherheitsfunktionalität korrekt arbeitet und zur Gewährleistung der Sicherheit des automatisierten Fahrsystems vertrauenswürdig ist.
Zum Beispiel können, wie in 7 dargestellt, durch das Sicherheitsbegleitteilsystem 710 Daten aus dem Rechenteilsystem 705 gesammelt werden, die den Betrieb sowohl der Software (z. B. 725) als auch der Hardware (z. B. 715) des Rechenteilsystems identifizieren. Beispielsweise können Entscheidungen und Bestimmungen, die durch die Anwendungen des Rechenteilsystem-Verabeitungskomplexes 725 getroffen werden, wie Objektbestimmungen, Objektklassifizierungen, Wegpläne, bestimmte Befehle, die an die Fahrzeugaktoren (z. B. 220) zu senden sind, und andere Informationen in den Daten enthalten sein, die bei der Überwachung des Rechenteilsystem-Verabeitungskomplexes 725 gesammelt werden. Diese Informationen können mithilfe der Anwendung des Sicherheitsbegleitteilsystems (z. B. bei 730) verarbeitet werden, um aus den aus Verarbeitungskomplex 725 des Rechenteilsystems gesammelten Informationen zu bestimmen, welche Bestimmungen durch das Rechenteilsystem 705 vorgenommen wurden, und basierend auf diesen Bestimmungen, welche Maßnahmen durch das Rechenteilsystem 705 zur Durchführung sicherer und angemessener Fahrmaßnahmen ausgelöst werden sollten. Das Sicherheitsbegleitteilsystem 710 kann die korrekte Reaktion des Rechenteilsystems 705 bestimmen und das Rechenteilsystem 705 überwachen, um sicherzustellen, dass diese korrekte Reaktion erfolgt (z. B. bremsen oder von einem gefährlichen Objekt weglenken, das durch die Sensoren 225 des Systems erkannt wurde). Wenn das Rechenteilsystem 705 nicht in der vorhergesagten sicheren Weise arbeitet, kann das Sicherheitsbegleitteilsystem 710 nötigenfalls die durch das Rechenteilsystem angewiesenen Maßnahmen außer Kraft setzen (z. B. Bremsaktoren anweisen zu bremsen und ein Signal an einen Drosselklappensteller aus dem Rechenteilsystem abschalten, um stattdessen basierend auf der Erkennung einer Gefahr zu beschleunigen) und den erkannten Fehler des Rechenteilsystems protokollieren. In einigen Fällen kann das Sicherheitsbegleitteilsystem 710 (z. B. als Reaktion auf die Erkennung eines fatalen Fehlers oder mehrerer oder wiederholter Fehler durch den Verarbeitungskomplex des Rechenteilsystems über eine Zeitspanne hinweg) ein automatisiertes Ausfallsicherungsfahrsystem (z. B. 750) aktivieren und/oder den Insassen des Fahrzeugs Informationen über eine bordeigene Benutzeroberfläche (z. B. 230) zur Verfügung stellen, z. B. um einen menschlichen Fahrer wieder in die Lage zu versetzen, die manuelle Steuerung des Fahrzeugs zu übernehmen (z. B., als Reaktion darauf, dass die Funktionalität des automatisierten Fahrsystems durch den Sicherheitsbegleiter basierend auf fehlerhaften Maßnahmen des Rechenteilsystems 705, die durch den Sicherheitsbegleiter 710 erkannt wurden, zumindest vorübergehend deaktiviert wird (z. B. um die Automatisierungsstufe des automatisierten Fahrsystems des Fahrzeugs (z. B. von L4 auf L2 oder L1) zu reduzieren, neben anderen Beispielen.
Zusätzlich zur Überwachung der durch die Software (bei 725) des Rechenteilsystems erzeugten Daten und Signale kann die Überwachungsschnittstelle 740 es dem Sicherheitsbegleiter ermöglichen, Signale abzufangen, die innerhalb der Hardware 715 des Rechenteilsystems 705 erzeugt werden, damit der Sicherheitsbegleiter 710 (z. B. durch ein entsprechendes Modul oder eine entsprechende Anwendung innerhalb des Sicherheitsbegleiter-Verarbeitungskomplexes 730) Fehler und Störungen auf der Hardwareebene erkennen und bestimmen kann, ob die Hardware (z. B. 715) des Rechenteilsystems zuverlässig arbeitet, sodass man sich darauf verlassen kann, dass sie genaue und sichere Ergebnisse liefert (z. B. bei der Ausführung von automatisierten Fahranwendungen, die in der Software 725 des Verarbeitungskomplexes des Rechenteilsystems bereitgestellt werden). Beispielsweise können Signale, die am Rechenteilsystem-MCU 715 erzeugt werden, abgefangen und an den Sicherheitsbegleitteil-Verarbeitungskomplex 730 gesendet werden, um das Auftreten von Softfehlern oder anderen Fehlern zu erkennen, die den korrekten Betrieb des Rechenteilsystems 705 kritisch beeinflussen können.
Das Bestimmen derartiger Probleme kann auch dazu führen, dass das Sicherheitsbegleitteilsystem 710 den normalen Betrieb des oben beschriebenen automatisierten Fahrsystems 210 unterbricht, indem es (z. B. unter Verwendung seiner grundlegenderen automatisierten Fahrlogik) die Steuerung der Richtung der Fahrzeugaktoren 220 übernimmt, die Ausfallsicherung der Fahrsystemfunktionalität (z. B. bei 750) aktiviert, Warnungen, Alarme oder andere Meldungen über bordeigene Benutzeroberflächen (z. B. 230) ausgibt, neben anderen Beispielen. In ähnlicher Weise können Fehler, die durch den Sicherheitsbegleiter in seiner eigenen Hardware (z. B. 730) erkannt werden, das Sicherheitsbegleitteilsystem 710 veranlassen, alternative Funktionen des Fahrzeugs zu steuern (z. B. das Fahrzeug wieder in die manuelle Fahrersteuerung zu versetzen, Ausfallsicherungsfahrsysteme aufzurufen, Fernunterstützung/-steuerung für den Fahrer aufzurufen, neben anderen Maßnahmen), um die Sicherheit des Fahrzeugs und seiner Insassen zu gewährleisten.
In 8 wird ein vereinfachtes Blockdiagramm 800 gezeigt, das beispielhafte Stack-Implementierungen eines Rechenteilsystems 705 und eines Sicherheitsbegleitteilsystems 710 zeigt.
Wie oben vorgestellt, kann das Rechenteilsystem 705 automatisierte Fahranwendung(en) 805 aufweisen, um die Verarbeitung von Sensordaten zur Bestimmung automatisierter Fahrvorgänge für ein Fahrzeug zu implementieren. Zusätzlich kann eine Sicherheitsüberwachungsanwendung 810 auf dem Sicherheitsbegleitteilsystem 710 bereitgestellt werden, um eine Logik (z. B. ausführbar durch die Verarbeitungshardware des Sicherheitsbegleitteilsystems (z. B. 720a, 720b)) zu implementieren, um den ordnungsgemäßen Betrieb des Rechenteilsystems, seiner Soft- und Hardware zu überwachen, die Leistung der Hardware des Sicherheitsbegleitteilsystems zu überwachen und in einigen Implementierungen sogar vereinfachte automatisierte Fahrvorgänge durchzuführen (und/oder eine interne Ausfallsicherungssteuerlogik aufzurufen (z. B. 750) oder ein robusteres automatisiertes Ausfallsicherungsfahrsystem, das auf dem Fahrzeug vorhanden ist), um zu versuchen, die Auswirkungen von Fehlern oder anderen Problemen zu beheben oder zu mindern, von denen bestimmt wird, dass sie Sicherheit der durch das Rechenteilsystem 705 getroffenen automatisierten Fahrentscheidungen beeinträchtigen.
In einigen Implementierungen können zur Unterstützung der Überwachung des Rechenteilsystems 705 Agenten (z. B. 815, 820) bereitgestellt werden (z. B. als separate Komponente installiert und/oder alternativ in die entsprechenden Komponenten des Rechenteilsystems integriert), um Daten abzufangen, die Informationen enthalten, die für das Sicherheitsbegleitteilsystem 705 von Interesse sind, und diese Informationen (z. B. in annähernd Echtzeit bei ihrer Erzeugung im Rechenteilsystem) an das Sicherheitsbegleitteilsystem 710 weiterzuleiten. Im konkreten Beispiel von 8 kann das Rechenteilsystem 705 einen Mikrocontroller(MCU)-Agenten 815 aufweisen (neben potentiell anderen Hardwareagenten für andere Hardware (z. B. Beschleuniger), die durch das Rechenteilsystem 705 zur Ausführung automatisierter Fahrlogik verwendet werden), um die Datenerfassung auf Hardwareebene zu ermöglichen, um die Erfassung von Daten auf Hardwareebene zu ermöglichen (z. B. Beschreibung der lokalen Signalisierung innerhalb der Hardware, Fernmeldung mit Beschreibung der Ein- und Ausgaben der Hardware usw.), die das Sicherheitsbegleitteilsystem 710 verwenden kann, um Fehler, Programmfehler und andere Probleme zu erkennen, die die Hardware des Rechenteilsystems betreffen (z. B. 715a, 715b). Der Hardwareagent (z. B. 815) kann Intelligenz aufweisen, um diejenigen Signale zu identifizieren, die möglicherweise die Sicherheit der Plattform beeinträchtigen können, und kann andere Signale von geringerer Relevanz aus der Meldung an den Sicherheitsbegleiter herausfiltern.
Im Beispiel von 8 kann die Software des Rechenteilsystems 705 auch mit einem Agenten (z. B. Host-Agent 820) ausgestattet sein, um in ähnlicher Weise die verschiedenen Softwarekomponenten und Transaktionen des Rechenteilsystems 705 zu überwachen. So können z. B. in das Rechenteilsystem eingegebene Sensordaten, Bestimmungen durch die verschiedenen Komponenten des Rechenteilsystems, die Entscheidungen und Bestimmungen des Rechenteilsystems identifizieren (z. B. Objekterkennungsergebnisse, Ergebnisse der Wegplanung, Lokalisierungsergebnisse, Fahrzeugzustandsergebnisse), und andere Daten durch den/die Host-Agenten 820 erfasst und mit dem Sicherheitsbegleitteilsystem 710 gemeinsam genutzt werden. Diese Informationen können es dem Sicherheitsbegleiter nicht nur ermöglichen, die Ausgaben des Rechenteilsystems 705 an verschiedene Fahrzeugaktoren zu identifizieren (z. B. zum Steuern bestimmter automatisierter Fahrvorgänge), sondern auch die Zwischenbestimmungen zu erkennen, die die automatisierte(n) Fahranwendung(en) 805 zur Bestimmung dieser Vorgänge verwenden kann (können), um Fehler zu erkennen und zu protokollieren (und möglicherweise darauf zu reagieren), und zwar in einigen Fällen, bevor entsprechende fehlerhafte und möglicherweise unsichere Maßnahmen durch das Rechenteilsystem 705 ergriffen werden. Eine Anwendungsprogrammierschnittstellen(API)-Schicht (z. B. implementiert durch die APIs 840, 842) kann vorgesehen sein, um die Interaktion zwischen den Agenten (z. B. 815, 820) und den überwachten Komponenten (z. B. Hardware 715a,b und Software (z. B. 805)) des Rechenteilsystems 705, neben anderen Beispielimplementierungen, zu ermöglichen.
Weiter mit dem Beispiel von 8 kann der Sicherheitsbegleiter 710 in einigen Implementierungen einen Sicherheitsproxy 825 aufweisen, der als Eingangsfach, Aufnahme oder Clearingstelle für Daten dient, die durch andere Überwachungskomponenten (z. B. durch Rechenteilsysteme (z. B. 815, 820), Hardwarewächter des Sicherheitsbegleiters (z. B. 835) usw.) gesammelt oder erzeugt werden. Der Sicherheitsproxy 825 kann eine Logik aufweisen, um Nachrichten von diesen Komponenten zu vermitteln, die empfangenen Daten zu sammeln und möglicherweise zu filtern und den Zugriff auf die Daten zu kontrollieren (z. B. durch das Anwendungsüberwachungsrahmenwerk, den Hardwarewächter 835, die Sicherheitsüberwachungsanwendung 810 usw.). Beispielsweise kann der Sicherheitsproxy 825 als Nachrichtenvermittler zwischen der Sicherheitsüberwachungsanwendung 810 und den Agenten (z. B. 815, 820) auf dem Rechenteilsystem (z. B. 705) dienen. Zusätzlich kann ein Sicherheitsproxy 825 gemeldete sicherheitsrelevante Ereignisse und Zustände verfolgen oder in eine Warteschlange stellen, bis sie durch die Sicherheitsüberwachungsanwendung 810 konsumiert werden. Die Sicherheitsüberwachungsanwendung 810 konsumiert die Ereignisse und den Zustand, die durch den Sicherheitsproxy 825 bereitgestellt werden (z. B. mithilfe des Anwendungsüberwachungsrahmenwerks 830 und/oder zugehöriger APIs (z. B. 846), um die unabhängige Überwachung der automatisierten Fahranwendung 805 durchzuführen. Zusätzlich kann ein Sicherheitsproxy 825 eine sichere Kommunikation zwischen dem Sicherheitsbegleitteilsystem 810 und dem Rechenteilsystem 805 erzwingen. Tatsächlich kann der Sicherheitsproxy 825 die empfangenen Daten analysieren, um verschiedene Richtlinien durchzusetzen, wie z. B. Richtlinien zur Isolierung „schlechter“ Daten, die durch das Rechenteilsystem empfangen wurden, um sicherzustellen, dass sich das Sicherheitsbegleitteilsystem 710 nicht auf diese Daten verlässt oder diese anwendet, Richtlinien zur Priorisierung von Daten, die sicherheitsrelevante Ereignisse basierend auf der Kritikalität oder zeitlichen Beschränkungen, basierend auf der Quelle der Daten (z. B. mit Datenerstellerrollen, die einigen Überwachungskomponenten (z. B. 815, 820, 935, etc.) zugewiesen werden, beschreiben, neben anderen Beispielen.
Der Verarbeitungskomplex eines Rechenteilsystems 705 kann beispielsweise die automatisierten Fahranwendungen (z. B. 805) enthalten, die zur Verarbeitung von Sensorinformationen und zur Erzeugung von Fahrbefehlen verwendet werden. Die automatisierte(n) Fahranwendung(en) 805 auf dem Rechenteilsystem 705 kann/können eine entsprechende API (z. B. 842) verwenden, um dem auf dem Verarbeitungskomplex des Rechenteilsystems ausgeführten Host-Agenten 820 sicherheitsrelevante Zustände und Ereignisse zur Verfügung zu stellen. Der Zustand und die Ereignisse können sicherheitsrelevante Informationen aufweisen, wie z. B. erkannte statische und dynamische Straßenobjekte, Entscheidungen zur Wegplanung und Fahrbefehle. Der Host-Agent 820 kann seine Informationen an den Sicherheitsproxy 825 melden, der auf dem Sicherheitsbegleitteilsystem 710 ausgeführt wird.
In einigen Implementierungen kann ein Anwendungsüberwachungsrahmenwerk 830 bereitgestellt werden, um die im Sicherheitsproxy gesammelten benötigten Daten schnell an die Sicherheitsüberwachungsanwendung 810 (und in Fällen, in denen die Ausfallsicherung des Sicherheitsbegleitteilsystems (z. B. 750) aufgerufen wird, an die Ausfallsicherungssteuerung) zu liefern oder weiterzuleiten. Beispielsweise kann das Anwendungsüberwachungsrahmenwerk 830 mit einem Satz wiederverwendbarer Überwachungsgrundelemente implementiert werden, die für die Hardware des Sicherheitsbegleitteilsystems (z. B. 720a, 720b) optimiert sind. Diese Grundelemente können unter anderem Funktionen zur Verfolgung des sicherheitsbezogenen Anwendungszustands, des Konfigurationszustands, der Verarbeitung sicherheitsbezogener Vorgänge, der Protokollierung und des Meldens aufweisen. Da der Sicherheitsbegleithardwarewächter 835 auf dem Sicherheitsbegleitteilsystem 710 vorhanden ist, kann er in einigen Fällen eine direkte Schnittstelle mit der Sicherheitsüberwachungsanwendung 810 bilden und Daten direkt an die Sicherheitsüberwachungsanwendung 810 liefern, anstatt den Sicherheitsproxy 825 zu liefern, der mit anderen Informationen (einschließlich Informationen, die außerhalb des Sicherheitsbegleitteilsystems 710 erzeugt werden) aggregiert wird, die durch das Anwendungsüberwachungsrahmenwerk 830 weitergeleitet werden sollen, neben anderen Beispielen für Alternativen und Implementierungen. Der Hardwarewächter 835 des Sicherheitsbegleiters kann den Betrieb des Sicherheitsbegleithardwarewächters 835 (z. B. 720a,b) überwachen, um das korrekte Arbeiten der Hardware sicherzustellen und zuverlässige Ergebnisse durch die Sicherheitsüberwachungsanwendung 810 zu erzielen. In einigen Implementierungen kann der Sicherheitsbegleithardwarewächter 835 auch zur Verarbeitung von Vorgängen, die im Rechenteilsystem erzeugt werden und die die Hardware des Rechenteilsystems beschreiben, sowie zur Erkennung von Fehlern und Ereignissen anhand dieser Daten verwendet werden. In anderen Implementierungen können Ereignisse und Fehler zusätzlich oder alternativ durch Hardwareüberwachungswerkzeuge auf dem Rechenteilsystem 705 (z. B. durch Hardwareagenten (z. B. MCU-Agent 815) oder andere Werkzeuge auf dem Rechenteilsystem 705) erkannt werden, und diese Ergebnisse können in Daten gemeldet werden, die der Sicherheitsüberwachungsanwendung 810 (z. B. durch Sicherheitsproxy 825 und Anwendungsüberwachungsrahmenwerk 830) durch das Rechenteilsystem 705 zur Verarbeitung zur Verfügung gestellt werden.
Generell können Hardwarewächter, die auf dem Sicherheitsbegleitteilsystem 710 oder dem Rechenteilsystem 705 bereitgestellt werden, die Hardwarekomponenten im entsprechenden Rechenteilsystem auf Hardwarefehlfunktionen testen und überwachen. Zum Beispiel kann ein Hardwarewächter (z. B. 835) über eine oder mehrere Hardwareüberwachungsschnittstellen einen periodischen und Laufzeittest der rechenintensiven Hardware durchführen. Der Hardwarewächter (z. B. 835) meldet Fehlfunktionen an das Sicherheitsbegleitteilsystem (z. B. über einen Sicherheitsproxy 825) zur Analyse und Berücksichtigung durch die Sicherheitsüberwachungsanwendung (z. B. 810) sowie in einigen Fällen direkt an fahrzeuginterne Benutzeroberflächen oder sogar an eine Ausfallsicherungssteuerlogik (z. B. 750).
Wie beim Rechenteilsystem 705 kann eine API-Schicht (z. B. durch APIs für den Sicherheitsproxy (z. B. API 844), ein Anwendungsüberwachungsrahmenwerk (z. B. API 846), einen Sicherheitsbegleithardwarewächter 835 (z. B. API 848) usw. verkörpert) bereitgestellt werden, um die Kommunikation mit der Sicherheitsüberwachungsanwendung 810 zu ermöglichen. Die Sicherheitsüberwachungsanwendung 810 kann die durch das Rechenteilsystem 705 gesammelten Daten verwenden, um Fälle zu erkennen, in denen das Rechenteilsystem eine anomale oder anderweitig unerwartete Entscheidung, eine möglicherweise unsichere Entscheidung oder eine andere Entscheidung trifft, die möglicherweise eine unmittelbare oder spätere Auswirkung auf die Sicherheit eines Fahrzeugbetriebs aufweist. Abhängig von der Art und Häufigkeit des Fehlers (der Fehler), der (die) durch die Sicherheitsüberwachungsanwendung 810 aus den Daten bestimmt wurde(n), kann die Sicherheitsüberwachungsanwendung 810 als Reaktion auf den Versuch, die negativen Auswirkungen des Fehlers (der Fehler) zu mildern, eine Vielzahl von Aufgaben durchführen. Beispielsweise können einige schwerwiegende Fehler dazu führen, dass die Sicherheitsüberwachungsanwendung 810 Maßnahmen als Reaktion auf einen einzelnen erkannten Fehlerfall ergreift oder dass andere weniger schwerwiegende oder weniger unmittelbare Fehler dazu führen, dass die Sicherheitsüberwachungsanwendung 810 Maßnahmen ergreift, nachdem eine Reihe ähnlicher Fehler erkannt und über eine Zeitspanne protokolliert wurden, neben anderen Beispielen. Beispielsweise kann die Sicherheitsüberwachungsanwendung 810 Warnungen erzeugen (z. B. zur Anzeige für einen Insassen oder als Meldung an ein externes Sicherheits- oder Qualitätskontrollsystem), eine durch die automatisierte Fahranwendung 805 getroffene Bestimmung oder gesendetes Signal, das gemäß dem Sicherheitsbegleiter 710 zu einer unsicheren Maßnahme führen würde, negieren oder außer Kraft setzen oder eine lokale Ausfallsicherungssteuerlogik (z. B. 750) oder externe automatisierte Ausfallsicherungsfahrsysteme aufrufen, neben anderen Beispielaktionen. In einigen Fällen kann die Sicherheitsüberwachungsanwendung 810 derartige Maßnahmen ferner basierend auf Fehlern einleiten, die in der Hardware (z. B. 720a,b) des Sicherheitsbegleitteilsystems 710 erkannt wurden, selbst wenn am Rechenteilsystem 705 keine Fehler erkannt wurden (z. B. da die Nichterkennung von Fehlern tatsächlich auf einem fehlerhaften Betrieb des Sicherheitsbegleitteilsystems 710 selbst beruhen kann), neben anderen Beispielen.
In einigen Implementierungen kann ein beispielhaftes Ausfallsicherungssteuersystem (z. B. 750) am Sicherheitsbegleitsystem 710 vorgesehen sein, die eine durch Hardware des Sicherheitsbegleitteilsystems 710 ausgeführte Logik implementiert, um zuverlässig Ausfallsicherungsvorgänge wie z. B. Einleiten eines automatischen Anhaltens, automatisches Bremsen, Übergabe an einen menschlichen Benutzer (z. B. innerhalb des Fahrzeugs oder in einem entfernten Fahrzeugsteuerungsdienstzentrum) zu implementieren, neben anderen Beispielfunktionen. In einigen Implementierungen (z. B., wie in 8 dargestellt) kann das Sicherheitsbegleitteilsystem 710 eine Ausfallsicherungssteuerung implementieren, um eine niedrigere Fahrautomatisierungsstufe durchzuführen. In anderen Fällen kann die Ausfallsicherungsfahrlogik zusätzlich oder alternativ durch ein vom Sicherheitsbegleitteilsystem 710 getrenntes Teilsystem bereitgestellt werden. Wenn die Sicherheitsüberwachungsanwendung 810 bestimmte kritische oder wiederholte Fehler erkennt, kann die Sicherheitsüberwachungsanwendung 810 generell die Fahrsteuerungsfunktionalität der Ausfallsicherung aufrufen, um vorübergehend unangemessene Risiken zu vermeiden, bis ein separates, funktionsreicheres Ausfallsicherungssystem aktiviert wird. In der Tat kann die Sicherheitsüberwachungsanwendung 810 in einigen Implementierungen bestimmen, ob ein robustes automatisiertes Ausfallsicherungsfahrsystem im Fahrzeug vorhanden ist, und ein solches System als primären Ausfallsicherungsmechanismus nutzen. In Fällen, in denen kein solches Ausfallsicherungssystem vorhanden ist oder wenn bestimmt wird, dass das Ausfallsicherungssystem nicht verfügbar ist, kann stattdessen die Ausfallsicherungssteuerung 750 des Sicherheitsbegleitsystems 710 verwendet werden, um das Fahrzeug in einen sicheren Zustand zu bringen (z. B. in der Fahrspur angehalten oder am Straßenrand geparkt).
Ein Beispiel des Sicherheitsbegleitteilsystems 710 kann zusätzliche Komponenten und Elemente aufweisen, die den Betrieb des Systems und die Ausführung von Sicherheitsüberwachungsanwendungen (z. B. 810) und -funktionen ermöglichen. Zum Beispiel kann, wie im Beispiel von 8 gezeigt, ein Sicherheitsbegleitteilsystem 710 eine oder mehrere Hardwarekomponenten (z. B. 720a,b) und unterstützenden Hypervisor, Betriebssystem, Treiber usw. (z. B. 860) aufweisen. Ebenso können softwareimplementierte Komponenten des Sicherheitsbegleitteilsystems 710 durch die Abstraktionslogik des Betriebssystems (z. B. 854), die Abstraktionslogik der Hardware (z. B. 856) und andere Komponenten unterstützt werden. Ebenso können Implementierungen eines Beispielrechenteilsystems (z. B. 705) entsprechende Hardwareabstraktionen (z. B. 850) und Betriebssystemabstraktionen (z. B. 852) sowie entsprechende Betriebssysteme, Hypervisor, Treiber usw. (z. B. 858) zur Verwendung mit der Hardware (z. B. 715b) des Rechenteilsystems 705 aufweisen, neben anderen geeigneten Implementierungen.
Angesichts der Unabhängigkeit und Modularität des Sicherheitsbegleitteilsystems 710 und des Rechenteilsystems 705 werden die Systeme eventuell nicht monolithisch, sondern separat entwickelt und aktualisiert. Wenn zum Beispiel Verbesserungen der Funktionalität der Sicherheitserkennung erkannt werden, kann die Sicherheitsüberwachungsanwendung des Sicherheitsbegleiters aktualisiert werden (ohne die Konfiguration des Rechensystems 705 zu stören), um derartige Funktionen einzubinden. In ähnlicher Weise können Aktualisierungen der automatisierten Fahranwendung(en) des Rechenteilsystems 705 unabhängig vom Sicherheitsbegleitteilsystem 710 vorgenommen werden (obwohl einige Aktualisierungen möglicherweise Aktualisierungen beider Teilsysteme umfassen). Zusätzlich kann das Sicherheitsbegleitteilsystem 710 mit einer anderen Architektur als das Rechenteilsystem implementiert werden. So können z. B. Hardware, Betriebssysteme, Kernel, Treiber usw. (z. B. 860), die im Sicherheitsbegleitteilsystem 710 verwendet werden, mit Merkmalen und Funktionen ausgestattet werden, die es dem Sicherheitsbegleitteilsystem 710 ermöglichen, höhere Sicherheitsstufen zu erzielen und zu implementieren (z. B. durch Einhaltung von Anforderungen, die durch ein Industriegremium oder eine andere Normungsorganisation, der das automatisierte Fahrsystem unterstellt sein kann, festgelegt werden), wobei ähnliche Merkmale bei analogen Elementen des Rechenteilsystems 705 entfallen können. In einem Beispiel kann ein virtueller Maschinenwächter zum Verwalten der Koexistenz von sicherheitsbezogenen und nicht sicherheitsbezogenen Anwendungen verwendet werden. Als weiteres Beispiel kann ein durch das Sicherheitsbegleitsystem genutztes Betriebssystem eine geeignete ASIL-Fähigkeit aufweisen, die gegebenenfalls im Rechenteilsystem genutzt werden kann, neben anderen Beispielen. Die architektonische Vielfalt kann in der Tat Redundanz und Notfallunterstützung bieten und gleichzeitig das automatisierte Fahrsystem gegen einen Fehler in der Architektur eines Teilsystems mit Auswirkungen auf das gesamte System absichern, neben anderen Beispielvorteilen.
Gemäß einigen Normen kann davon ausgegangen werden, dass das automatisierte Fahrsystem die gesamte oder einen Teil der dynamischen Fahraufgabe dauerhaft ausführt, um die Fahrautomatisierungsstufen L3, L4 und L5 zu erfüllen. Zu den dynamischen Fahraufgaben des automatisierten Fahrsystems können betriebliche und taktische Funktionen gehören, die für den Betrieb eines Fahrzeugs im Straßenverkehr erforderlich sind, einschließlich, aber nicht beschränkt auf die Steuerung der seitlichen Fahrzeugbewegung über die Lenkung (betrieblich); die Steuerung der Fahrzeugbewegung in Längsrichtung über Beschleunigung und Verlangsamung (betrieblich); Überwachung der Fahrumgebung durch Objekt- und Ereigniserfassung, -erkennung, -klassifizierung und Reaktionsvorbereitung (betrieblich und taktisch); Überwachung des Fahrzeugstatus (Sensorstatus, Quer- und Längsstatus); Objekt- und Ereignisreaktionsausführung (betrieblich und taktisch); Manöverplanung (taktisch); und Verbesserung der Auffälligkeit durch Beleuchtung, Signalgebung und Gestik usw. (taktisch). In einigen Implementierungen können alle Elemente des Systems korrekt eingeleitet werden, sobald das automatisierte Fahrsystem aktiviert ist. Es kann davon ausgegangen werden, dass keine Betätigungsbefehle vom automatisierten Fahrsystem ausgehen sollten, bis das automatisierte Fahrsystem durch den (lokalen oder entfernten) Fahrer aufgefordert wird, dynamische Fahraufgaben durchzuführen. Nach Abschluss der Initialisierung werden Sensoren verwendet, um Informationen aus der Umgebung des Fahrzeugs und dem Fahrzeug selbst zu erhalten, um die Daten für die implementierten Fahrzeugfunktionen des automatisierten Fahrsystems bereitzustellen. Sensordaten werden empfangen und durch das automatisierte Fahrsystem verarbeitet, um Befehle für die Aktoren zu erzeugen.
Wie oben erwähnt, kann in einigen Implementierungen das Sicherheitsbegleitteilsystem mit einem höheren ASIL als das Rechenteilsystem ausgelegt sein. In einer Implementierung kann ein automatisiertes Fahrsystem der SAE-Stufe L3, L4 oder L5 die Aufgabe haben, alle oder einen Teil der dynamischen Fahraufgaben über einen betrieblichen Entwurfsbereich dauerhaft durchzuführen. Die gefährlichen Ereignisse, denen das automatisierte Fahrsystem begegnen und die von ihm klassifiziert werden können, können eine Exposition, Kontrollierbarkeit und Schwere aufweisen, die wie folgt anzunehmen sind: - Exposition: Hohe Wahrscheinlichkeit - Kontrollierbarkeit: Schwierig zu kontrollieren oder unkontrollierbar - Schwere: Lebensbedrohliche Verletzungen (Überleben ungewiss), tödliche Verletzungen Bei einer solchen Implementierung kann das automatisierte Fahrsystem gezielt eingesetzt werden, um gefährliche Ereignisse zu beherrschen und Sicherheitsziele bis zu ASIL D zu realisieren. Aus diesen Beispielgefahren kann eine Reihe von angenommenen, für das Verarbeitungselement geeigneten Sicherheitszielen abgeleitet werden. Zum Beispiel: das automatisierte Fahrsystem muss Fehlermodi vermeiden, erkennen oder kontrollieren, die zur Verwendung fehlerhafter Daten aus dem/den Sensorelement(en) führen; das automatisierte Fahrsystem muss Fehlermodi vermeiden, erkennen oder kontrollieren, die zu einer fehlerhaften Datenverarbeitung führen; und das automatisierte Fahrsystem muss Fehlermodi vermeiden, erkennen oder kontrollieren, die zur Übertragung von unbeabsichtigten Befehlen an das/die Aktorelement(e) führen, neben anderen Beispielen.
Wie hier dargelegt, kann ein automatisiertes Fahrsystem ein Rechenteilsystem und ein Sicherheitsbegleitteilsystem aufweisen, die jeweils über verschiedene Schnittstellen miteinander sowie mit anderen Komponenten des Systems verbunden sein können, einschließlich verschiedener Sensoren und Aktoren des Systems, sowie automatisierte Fahrteilsysteme zur Ausfallsicherung. Allgemein verarbeitet das Rechenteilsystem Sensorinformationen und erzeugt Betätigungsbefehle. Das Sicherheitsbegleitteilsystem erkennt und meldet Fehler im Rechenteilsystem. In 9 wird eine Beispielimplementierung eines automatisierten Fahrsystems 210 gezeigt, das die Schnittstellen (z. B. 912, 914, 916, 918, 920, 922, 924, 926 usw.) aufweist, über die Hardwareelemente des Rechenteilsystems 705 und des Sicherheitsbegleitteilsystems 710 miteinander verbunden sein können (sowie Unterkomponenten, wie z. B. Hardwarewächter (z. B. MCU-Agent 815, Sicherheitsbegleiter-Hardwarewächter 835 usw.), Stromversorgungswächter für das Teilsystem (z. B. Rechenteilsystem-Stromversorgungswächter 905, Sicherheitsbegleitteilsystem-Stromversorgungswächter 910)) und andere Komponenten des automatisierten Fahrsystems 210, wie Stromversorgungssysteme, Sensoren, Aktoren usw. Als Beispiel kann das Sicherheitsbegleitelement 710 Signale erzeugen, um den Status des Rechenteilsystems und des automatisierten Fahrsystems 210 allgemein sowie den Status eines Ausfallsicherungsfahrsystems des Systems zu identifizieren, z. B. unter Verwendung des Status des automatisierten Fahrsystems und des Ausfallsicherungsfahrteilsystems mittels einer Schnittstelle, einschließlich des Meldens von Ausfallzuständen. Eine Steuerschnittstelle kann vorgesehen sein und zur Steuerung des Betriebszustands des automatisierten Fahrsystems 210 und/oder des Ausfallsicherungsfahrsystems verwendet werden, einschließlich Aktivierung oder Deaktivierung des automatisierten Fahrsystems 210 und Umschaltung auf das Ausfallsicherungsfahrsystem im Bedarfsfall.
Das Sicherheitsbegleitteilsystem 710 kann möglicherweise Statusinformationen aus dem automatisierten Fahrsystem 210 und dem Umschalten auf das Ausfallsicherungsfahrsystem empfangen und den Betrieb des Rechenteilsystems und des Ausfallsicherungsfahrsystems wirksam steuern. Das Rechenteilsystem stellt über eine oder mehrere der Schnittstellen Informationen über den Status des automatisierten Fahrsystems zur Verfügung, wobei die Informationen auch Fehler umfassen, die innerhalb des automatisierten Fahrsystems, seiner Elemente und Schnittstellen gemeldet werden. Das Rechenteilsystem empfängt zudem Informationen zur Steuerung des automatisierten Fahrsystems über eine oder mehrere der Schnittstellen, wobei diese Informationen Befehle wie das Aktivieren, Deaktivieren und Testen des automatisierten Fahrsystems aufweisen. Das Sicherheitsbegleitteilsystem ist dafür verantwortlich, das Rechenteilsystem und das automatisierte Ausfallsicherungsfahrteilsystem basierend auf den durch diese beiden Elemente gemeldeten Ausfallbedingungen zu aktivieren. Das Sicherheitsbegleitteilsystem deaktiviert das automatisierte Fahrsystem, wenn durch das Rechenteilsystem ein Fehler gemeldet wird, und führt die dynamische Rückfallfunktion der Fahraufgabe unter Verwendung des Rückfallelements des automatisierten Ausfallsicherungsfahrteilsystems durch. Zusätzlich sollte das Sicherheitsbegleitteilsystem Befehlsschnittstellen des Rechenteilsystems steuern, um solche Schnittstellen potenziell zu deaktivieren, um zu verhindern, dass das automatisierte Fahrsystem weiterhin Befehle an die Aktoren ausgibt, wenn ein Fehler im Rechenteilsystem erkannt wurde.
In Fällen, in denen das Sicherheitsbegleitteilsystem 710 dem automatisierten Ausfallsicherungsfahrteilsystem befohlen hat, eine dynamische Rückfallfunktion der Fahraufgabe durchzuführen, kann das Sicherheitsbegleitteilsystem 710 dem Rechenteilsystem 705 befehlen, Offline-Tests durchzuführen. Wenn das Rechenteilsystem die Offline-Tests besteht, kann das Sicherheitsbegleitteilsystem das Rechenteilsystem wieder in Betrieb nehmen (z. B. und das Ausfallsicherungsteilsystem deaktivieren). Wenn das Rechenteilsystem 705 ausfällt oder die Offline-Tests nicht vollständig durchläuft, steht dem automatisierten Fahrsystem möglicherweise keine weitere Fehlertoleranz zur Verfügung, es sei denn, es sind weitere Rückfallelemente verfügbar. Wenn keine weitere Fehlertoleranz zur Verfügung steht, befiehlt das Sicherheitsbegleitteilsystem 710 in einigen Implementierungen dem Rückfallelement des automatisierten Ausfallsicherungsfahrteilsystems, das Fahrzeug in einen sicheren Zustand zu bringen. Die Leistungsfähigkeit des automatisierten Fahrsystems zur Durchführung der dynamischen Fahraufgabe kann in einigen Implementierungen durch Hinzufügen zusätzlicher Rechenteilsysteme skaliert werden. Jedes der mehreren Rechenteilsysteme kann in einigen Implementierungen an dasselbe Sicherheitsbegleitteilsystem (z. B. 710) angebunden sein.
In einigen Implementierungen kann ein automatisiertes Ausfallsicherungsfahrteilsystem getrennt vom Rechenteilsystem 705 implementiert sein und eine dynamische Rückfallfunktion der Fahraufgabe für das automatisierte Fahrsystem bereitstellen, falls das automatisierte Fahrsystem 210 einen Fehler aufweist und ein betriebsfähiges System erforderlich ist (z. B. für ein automatisiertes Fahrsystem der Stufe L4 oder L5). Das Rückfallelement des automatisierten Ausfallsicherungsfahrteilsystems kann als Bereitschaftselement implementiert sein. Angesichts der Bewertungen des akzeptablen Fehlertoleranzzeitintervalls (FTTI), die für automatisierte Fahrsysteme eingehalten werden, und der beträchtlichen Menge an Zuständen und Vorgeschichten, die wahrscheinlich durch das Rückfallelement zur Durchführung der dynamischen Fahraufgabe verwendet werden, kann das automatisierte Ausfallsicherungsfahrteilsystem in einigen Implementierungen als Hot-Standby implementiert werden. Auf diese Weise laufen das automatisierte Fahrsystem und das automatisierte Ausfallsicherungsfahrteilsystem gleichzeitig und verarbeiten die gleichen Informationen. Das Rückfallelement kann die gleiche beabsichtigte Funktionalität wie das automatisierte Fahrsystem oder eine reduzierte Form der beabsichtigten Funktionalität bieten, je nach der erforderlichen Reduzierfähigkeit des automatisierten Fahrsystems. Zusätzlich können ein oder mehrere solcher Rückfallelemente/-teilsysteme basierend auf der Implementierung vorhanden sein. Das Rückfallelement des automatisierten Ausfallsicherungsfahrteilsystems verarbeitet Sensorinformationen aus den Sensorschnittstellen des Systems und liefert Betätigungsbefehle über Aktorschnittstellen. Diese Tätigkeit kann gleichzeitig mit dem Betrieb des automatisierten Fahrsystems durchgeführt werden, um einen Hot-Standby-Betrieb zu gewährleisten. Das Sicherheitsbegleitteilsystem 710 kann eine oder mehrere Steuerschnittstellen verwenden, um den Zustand des Ausfallteilsystems zu steuern, einschließlich der Aktivierung oder Deaktivierung des Ausfallteilsystems. Das automatisierte Ausfallsicherungsfahrteilsystem kann über eine dedizierte Schnittstelle Statusinformationen an das Sicherheitsbegleitteilsystem liefern. Das Sicherheitsbegleitteilsystem führt die Diagnose des automatisierten Ausfallsicherungsfahrteilsystems ebenfalls über eine entsprechende Schnittstelle durch. In einigen Implementierungen kann die Funktionalität des Sicherheitsbegleitteilsystems mindestens teilweise mit der des automatisierten Ausfallsicherungsfahrteilsystems zusammengelegt oder kombiniert werden, sodass eine ausreichende Unabhängigkeit von Ausfällen des Rechenteilsystems gewährleistet ist. Diese Kombination kann in einigen Fällen vorteilhaft sein, um Verzögerungen zwischen dem Erkennen einer Störung im Rechenteilsystem und dem Aktivieren der dynamischen Rückfallfunktion der Fahraufgabe zu verringern, neben anderen Beispielalternativen und -vorteilen.
In einer Beispielimplementierung kann das automatisierte Fahrsystem 210 zur Unterstützung der Sicherheitsziele des automatisierten Fahrsystems bis zu ASIL D implementiert sein. Wie hier erörtert, kann in einigen Implementierungen das Rechenteilsystem selbst dazu ausgelegt sein, unterhalb dieser Zielsetzung liegende Sicherheitsziele zu erreichen, wobei es sich auf die verbesserten Sicherheitsmerkmale des kooperierenden Sicherheitsbegleitteilsystems stützt, um die für das System festgelegten erforderlichen Sicherheitsziele zu erreichen. Wie oben angemerkt, können entsprechende Hardwarewächter vorgesehen sein, um die Hardware sowohl des Rechenteilsystems als auch des Sicherheitsbegleitteilsystems zu überwachen und Daten, die die Bedingungen in der Hardware beschreiben, an die Software des Sicherheitsbegleitteilsystems zur Verarbeitung und zu möglichen Abhilfemaßnahmen zu liefern. Die Hardwarewächter können beispielsweise dazu ausgelegt sein, eine diagnostische Erfassung in Bezug auf Restfehler von 0,99 % und eine diagnostische Erfassung in Bezug auf latente Fehler von 0,90 % bereitzustellen (z. B. bei jeder Hardware des Sicherheitsbegleitteilsystems und der Hardware des Rechenteilsystems). In einem Beispiel kann der Zielwert für Verletzungen des Sicherheitsziels durch zufällige Hardwareausfälle (z. B. in der gesamten Hardware des automatisierten Fahrsystems) ein angestrebter maximaler Beitrag von 10-9 pro Stunde (10 Ausfälle in der Zeit (FIT)) zur Wahrscheinlichkeit der Verletzung eines Sicherheitsziels durch zufällige Hardwareausfälle sein (z. B. einschließlich sicherer Fehler und Restfehler, die mittels Hardwarewächtern des Systems erkannt werden).
Zusätzliche Sicherheitsmaßnahmen können unter Verwendung eines Sicherheitsbegleitteilsystems implementiert werden, um das gewünschte ASIL oder ein anderes Ziel zu erreichen, wobei die Sicherheitsfähigkeit (z. B. ASIL) des Sicherheitsbegleitteilsystems (und des Rechenteilsystems) genutzt wird. Beispielsweise kann das Sicherheitsbegleitteilsystem dazu verwendet werden, das Durchführen oder Unterstützen des Durchführens (durch das Rechenteilsystem oder andere Komponenten des automatisierten Fahrsystems) verschiedener technischer Sicherheitsanforderungen (TSRs) (z. B. TSRs, die in ISO 26262-4, Straßenfahrzeuge - funktionale Sicherheit, definiert sind) zu unterstützen. Beispielsweise kann das Sicherheitsbegleitteilsystem Fehler im Zusammenhang mit der Kalibrierung des Rechenteilsystems (z. B. einschließlich der Pflege entsprechender Kalibrierungsdaten), Fehler im Zusammenhang mit unbeabsichtigten oder falschen Übergängen zwischen den Betriebsarten des automatisierten Fahrsystems erkennen und steuern (z. B. Übergänge zwischen den Betriebsarten des Rechenteilsystems oder den Ausfallteilsystemen), Fehler in Bezug auf die für das Rechenteilsystem definierten sicheren Zustände, Fehler in Bezug auf die durch das Rechenteilsystem oder das Sicherheitsbegleitteilsystem verwendeten Schnittstellen, Stromausfälle (z. B. durch Stromüberwachungsgeräte des Rechenteilsystems oder des Sicherheitsbegleitteilsystems erkannt) und Spannungsausfälle (z. B. Über- oder Unterspannungsbedingungen). Weitere TSRs, die mit dem Sicherheitsbegleitteilsystem zufriedenstellend erfüllt werden, können die Erkennung und Kontrolle von Störungen im Zusammenhang mit der fehlerhaften Fehlersuche durch das Rechenteilsystem, Fehler bei der Einhaltung der Schwellenwerte für die Erkennungs- und Reaktionszeit, Fehler im Zusammenhang mit Benutzerwarnungen (z. B. über bordeigene Benutzeroberflächen), Fehler im Zusammenhang mit der manuellen (lokalen oder entfernten) Übergabe durch das automatisierte Fahrsystem, Speicherfehler (z. B. verfälschende Fehlerdaten, die durch Hardwarewächter erkannt werden, Konfigurationsdaten usw.), Hardwarefehler (z. B. Fehler beim direkten Speicherzugriff (DMA), Schnittstellen-Bitfehler, Speicherverwaltung, Interrupt-Behandlung usw.) sowie Fehler im Zusammenhang mit falschen Fahrentscheidungen oder -betätigungen, die durch das Rechenteilsystem bestimmt wurden (z. B. wie oben dargelegt), neben anderen Beispielen. Fehler können durch den Austausch sicherheitsrelevanter Informationen über eine oder mehrere Schnittstellen der Schnittstelle des automatisierten Fahrsystems identifiziert und kontrolliert werden, die dazu ausgelegt sind, u. a. gegen Kommunikationsverlust, Nachrichtenverfälschung, inakzeptable Nachrichtenverzögerung, Nachrichtenverlust, unbeabsichtigte Nachrichtenwiederholung, falsche Nachrichtenreihenfolge, Nachrichteneinfügung, Nachrichtenmaskierung und falsche Nachrichtenadressierung zu schützen, neben anderen erweiterten Funktionen zum Schutz der Integrität dieser Schnittstellen und der durch sie übertragenen Signale.
In 10 ist ein vereinfachtes Blockdiagramm dargestellt, das eine Beispielimplementierung der Hardware eines automatisierten Fahrsystems in einem System mit einem Rechenteilsystem 705 in Verbindung mit einem Sicherheitsbegleitteilsystem 710 zeigt. In diesem Beispiel kann das Rechenteilsystem 705 ein Paar miteinander verbundener Zentraleinheiten (CPUs) 715b,c zur Implementierung einer zentralen Verarbeitungsfunktion sowie eine Fahrzeug-MCU 715a zum Durchführen automatisierter Fahrsystemaufgaben aufweisen. Jede der CPUs 715b,c kann Speicherelemente mit doppelter Datenrate (DDR) und Halbleiterlaufwerk(SSD)-Speicherelemente (z. B. 1004, 1006), eine oder mehrere kooperierende Beschleunigungsvorrichtungen (z. B. 1008) und möglicherweise weitere unterstützende Verarbeitungselemente (z. B. feldprogrammierbares Gate-Array (FPGA) 1002) aufweisen. Ein Baseboard Management Controller (BMC) 1018 kann mit der MCU 715a gekoppelt sein (ebenso kann eine BMC-Steuervorrichtung 1020 mit der MCU 720b des Sicherheitsbegleitsystems gekoppelt sein. Zur Kommunikation zwischen Elementen des Rechenteilsystems 705, des Sicherheitsbegleitteilsystems 710 und anderen Komponenten (z. B. Aktoren, Sensoren und Teilsystemen) des Fahrzeugs (z. B. unter Verwendung der Schnittstellen 1056, 1058, 1060, 1062, 1064, 1066, 1068 gemäß einer oder mehrerer Kommunikationstechnologien (z. B. Ethernet, MIPI, CAN, FlexRay usw.) können Schaltvorrichtungen (z. B. 1050, 1055) bereitgestellt werden. In einigen Implementierungen können Prozessoren (z. B. 715b,c) durch einen Plattformsteuerknoten (PCH) (z. B. 1016) mit Schaltstrukturen gekoppelt werden, neben anderen Beispielimplementierungen.
Das Sicherheitsbegleitteilsystem kann unter Verwendung einer anderen Architektur implementiert werden (und kann sogar von einem separaten Anbieter oder Lieferanten bereitgestellt werden), wodurch eine architektonische Vielfalt gewährleistet wird und Fehler oder Defekte in einem Teilsystem 705, 710, die das gesamte automatisierte Fahrsystem betreffen, vermieden werden. In einem Beispiel kann das Sicherheitsbegleitteilsystem 710 einen CPU-Prozessor 720 verwenden, der mit einem oder mehreren Speicherelementen (z. B. 1010, 1012) und einer oder mehreren Hardwarebeschleunigungsvorrichtungen (z. B. 1014, die von den im Rechenteilsystem 705 verwendeten Beschleunigern verschieden sein können) gekoppelt ist. Das Sicherheitsbegleitteilsystem 710 kann auch eine Fahrzeug-MCU 720b aufweisen (z. B. die gleiche oder eine andere als die MCU 715a des Rechenteilsystems 705), die zusammen mit CPU 720a mit BMC 1020 gekoppelt sein kann, neben anderen Beispielkomponenten.
Wie im Beispiel von 10 gezeigt, können in einigen Implementierungen das Rechenteilsystem 705 und das Sicherheitsbegleitteilsystem 710 aus einer gemeinsamen Stromquelle versorgt werden (z. B. durch die Stromversorgung 1025 des Motorsteuergeräts (ECU)). In einigen Fällen können sowohl das Rechenteilsystem 705 als auch das Sicherheitsbegleitteilsystem 710 jeweils mit einem Stromwächter (z. B. 905, 910) ausgestattet sein, um zu erkennen, ob das Teilsystem ausreichend mit Strom versorgt wird. Stromversorgungsstatus und - ereignisse können durch die Stromwächterschaltung (z. B. 905, 910) gemeldet und durch das Sicherheitsbegleitteilsystem als zusätzliche Eingaben zur Bestimmung des korrekten Betriebs des Rechenteilsystems und/oder als Eingabe für Ausfallsicherungssysteme (z. B. wenn das Sicherheitsbegleitteilsystem die Stromversorgung verliert) verwendet werden. In ähnlicher Weise können separate Spannungswächterschaltungen (z. B. 1040, 1045) die Spannungsbedingungen an jedem der entsprechenden Rechenteilsysteme 705 oder Sicherheitsbegleitteilsysteme 710 überwachen und das erkannte Auftreten von Unter- oder Überspannungsereignissen innerhalb der Teilsysteme (z. B. durch die Software oder Ausfallsicherungssysteme des Sicherheitsbegleitteilsystems, je nach Fall) neben anderen Beispielmerkmalen und -komponenten signalisieren.
Obwohl sich viele der obigen Beispiele auf Implementierungen eines Sicherheitsbegleitteilsystems innerhalb eines automatisierten Fahrsystems konzentrieren, versteht sich, dass ähnliche Architekturen (mit einem Rechenteilsystem und einem unabhängigen Sicherheitsbegleitteilsystem höherer Sicherheitsstufe) auch in anderen maschinellen Automatisierungssystemen wie z. B. industriellen oder persönlichen Robotern, Drohnen und anderen autonomen (oder halbautonomen) Maschinen verwendet werden können, um den sicheren Betrieb der Maschine zu ermöglichen. Zum Beispiel zeigt 11 ein Flussdiagramm 1100, das eine Beispieltechnik zur Gewährleistung der Sicherheit in Verbindung mit dem autonomen Betrieb einer Maschine illustriert. Beispielsweise können Ereignisdaten in Verbindung mit Entscheidungen erzeugt werden, die durch das Rechenteilsystem im Laufe des Betriebs getroffen werden und dynamische automatisierte Aufgaben bestimmen, die durch die Maschine physisch implementiert werden sollen. Auf die Ereignisdaten kann durch das Sicherheitsbegleitteilsystem zugegriffen 1105 (z. B. durch einen Agenten auf dem Rechenteilsystem gesammelt und über eine Schnittstelle oder Vermittlungskomponente (z. B. Sicherheitsproxy) an die Sicherheitskomponente weitergeleitet) und analysiert werden, um zu bestimmen (z. B. 1120), ob die Entscheidung korrekt und sicher ist oder durch die Softwarelogik des Rechenteilsystems, die zur Entscheidungsfindung verwendet wird, eine Fehlfunktion darstellt. Zusätzlich (oder alternativ) können Hardwarezustandsdaten (z. B. durch einen Hardwarewächter auf dem Rechenteilsystem) erzeugt werden, um Attribute der Hardware des Rechenteilsystems zu identifizieren. Auf diese Daten kann auch durch die Logik des Sicherheitsbegleitteilsystems zugegriffen 1110 werden, um Fehlfunktionen (in der Hardware des Rechenteilsystems) zu erkennen (z. B. 1120), die die Sicherheit der durch das Rechenteilsystem bestimmten Maschinenautomatisierungsaufgaben (z. B. unter Verwendung der fehlerhaften Hardware) beeinträchtigen. Ferner kann in einigen Implementierungen ein Hardwarewächter zur Überwachung der eigenen Hardware des Sicherheitsbegleitteilsystems (die sich von der Hardware des Rechenteilsystems unterscheidet) vorgesehen sein, um Fehlfunktionen zu erkennen, die die Sicherheitsfunktionalität untergraben, die durch das Sicherheitsbegleitteilsystem der höheren Sicherheitsstufe (z. B. höheres ASIL) (unter Verwendung seiner Hardware) bereitgestellt werden soll. Entsprechend kann ein Sicherheitsbegleitteilsystem ebenfalls auf diese Hardwarezustandsdaten (bei 1115) zugreifen und (bei 1120) Fehlfunktionen bestimmen, die vom Sicherheitsbegleitteilsystem ausgehen und den sicheren Betrieb des Systems gefährden können. Basierend auf derartigen Fehlfunktionen kann das Sicherheitsbegleitteilsystem eine oder mehrere Maßnahmen auslösen 1125, um die bestimmte(n) Fehlfunktion(en) zu kontrollieren. Die Maßnahmen können auf der Schwere und/oder Häufigkeit der Fehlfunktion sowie auf der Quelle der Fehlfunktion basieren. In einigen Fällen kann die Fehlfunktion beispielsweise dazu führen, dass ein Alarm vorliegt, Fehler protokolliert oder Selbsttests durchgeführt werden (z. B. zur Überprüfung und/oder Selbstkorrektur des festgestellten Fehlers). In anderen Fällen kann die Fehlfunktion dazu führen, dass eine alternative Automatisierungslogik aufgerufen wird, um (z. B. vorübergehend) die Steuerung der Maschinenautomatisierung zu übernehmen. In Fällen, in denen eine kritische Fehlfunktion im Sicherheitsbegleitteilsystem selbst erkannt wird, können Ausfallsicherungssysteme eingesetzt werden (z. B. basierend auf der Annahme, dass der sichere Betrieb der Maschine nicht mehr gewährleistet werden kann, da die Integrität des Sicherheitsbegleitteilsystems gefährdet ist), neben anderen Beispielmerkmalen und -implementierungen.
12-13 sind Blockdiagramme von beispielhaften Computerarchitekturen, die gemäß den hier offenbarten Ausführungsformen verwendet werden können. Es können auch andere in der Fachwelt bekannte Computerarchitekturen für Prozessoren und Rechensysteme zum Einsatz kommen. Generell können geeignete Computerarchitekturen für die hier offenbarten Ausführungsformen unter anderem die in 12-13 dargestellten Konfigurationen aufweisen, sind aber nicht darauf beschränkt.
12 ist ein Beispiel für einen Prozessor gemäß einer Ausführungsform. Prozessor 1200 ist ein Beispiel für eine Art von Hardwarevorrichtung, die in Verbindung mit den obigen Implementierungen verwendet werden kann. Bei Prozessor 1200 kann es sich um jede Art von Prozessor handeln, z. B. einen Mikroprozessor, einen eingebetteten Prozessor, einen digitalen Signalprozessor (DSP), einen Netzwerkprozessor, einen Mehrkernprozessor, einen Einkernprozessor oder eine andere Vorrichtung zur Ausführung von Code. Obwohl nur ein Prozessor 1200 in 12 dargestellt ist, kann ein Verarbeitungselement alternativ auch mehr als einen der in 12 dargestellten Prozessoren 1200 aufweisen. Der Prozessor 1200 kann ein Single-Thread-Kern sein oder für mindestens eine Ausführungsform kann der Prozessor 1200 ein Multi-Thread-Kern sein, indem er mehr als einen Hardware-Thread-Kontext (oder logischen Prozessor) pro Kern aufweisen kann.
12 zeigt auch einen Speicher 1202, der gemäß einer Ausführungsform mit dem Prozessor 1200 gekoppelt ist. Der Speicher 1202 kann eine Vielzahl von Speichern (einschließlich verschiedener Schichten der Speicherhierarchie) aufweisen, die in der Fachwelt bekannt sind oder Fachleuten anderweitig zur Verfügung stehen. Solche Speicherelemente können unter anderem Direktzugriffsspeicher (RAM), Festwertspeicher (ROM), Logikblöcke eines feldprogrammierbaren Gate-Arrays (FPGA), löschbare programmierbare Festwertspeicher (EPROM) und elektrisch löschbare programmierbare ROMs (EEPROM) aufweisen.
Der Prozessor 1200 kann jede Art von Anweisungen ausführen, die mit den hier beschriebenen Algorithmen, Prozessen oder Vorgängen verbunden sind. Generell kann der Prozessor 1200 ein Element oder einen Artikel (z. B. Daten) von einem Zustand oder Ding in einen anderen Zustand oder Ding transformieren.
Der Code 1204, bei dem es sich um eine oder mehrere Anweisungen handeln kann, die durch den Prozessor 1200 ausgeführt werden sollen, kann im Speicher 1202 gespeichert sein oder in Software, Hardware, Firmware oder einer geeigneten Kombination davon oder in einer anderen internen oder externen Komponente, Vorrichtung, einem Element oder Objekt gespeichert sein, wo dies angemessen ist und auf besonderen Bedürfnissen basiert. In einem Beispiel kann der Prozessor 1200 einer Programmsequenz von Anweisungen folgen, die durch den Code 1204 angezeigt wird. Jede Anweisung geht in eine Frontendlogik 1206 ein und wird durch einen oder mehrere Decoder 1208 verarbeitet. Der Decoder kann als Ausgabe eine Mikrooperation wie z. B. eine Mikrooperation mit fester Breite in einem vordefinierten Format erzeugen oder andere Anweisungen, Mikroanweisungen oder Steuersignale erzeugen, die die ursprüngliche Codeanweisung widerspiegeln. Die Frontendlogik 1206 weist auch eine Registerumbenennungslogik 1210 und eine Planungslogik 1212 auf, wobei allgemein Ressourcen zugewiesen werden und der Betrieb entsprechend der Anweisung zur Ausführung in eine Warteschlange gestellt wird.
Der Prozessor 1200 kann auch Ausführungslogik 1214 mit einem Satz von Ausführungseinheiten 1216a, 1216b, 1216n usw. aufweisen. Einige Ausführungsformen können eine Anzahl von Ausführungseinheiten aufweisen, die für bestimmte Funktionen oder Funktionsgruppen bestimmt sind. Andere Ausführungsformen enthalten eventuell nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion durchführen kann. Die Ausführungslogik 1214 führt die durch Codeanweisungen spezifizierten Operationen durch.
Nach Abschluss der Ausführung der durch die Codeanweisungen spezifizierten Operationen kann die Backendlogik 1218 die Anweisungen von Code 1204 zurückziehen. In einer Ausführungsform ermöglicht der Prozessor 1200 die Ausführung außerhalb der Reihenfolge, verlangt aber in der entsprechenden Reihenfolge die Rücknahme von Anweisungen. Die Rücknahmelogik 1220 kann verschiedene bekannte Formen annehmen (z. B. Neuordnungspuffer o. ä.). Auf diese Weise wird der Prozessor 1200 während der Ausführung von Code 1204 transformiert, zumindest hinsichtlich der durch den Decoder erzeugten Ausgabe, der Hardwareregister und Tabellen, die durch die Registerumbenennungslogik 1210 verwendet werden, und aller Register (nicht dargestellt), die durch die Ausführungslogik 1214 geändert werden.
Obwohl nicht in 12 gezeigt, kann ein Verarbeitungselement weitere Elemente auf einem Chip mit Prozessor 1200 aufweisen. Ein Verarbeitungselement kann zum Beispiel zusammen mit dem Prozessor 1200 eine Speichersteuerlogik aufweisen.
Das Verarbeitungselement kann eine E/A-Steuerlogik aufweisen und/oder eine mit der Speichersteuerlogik integrierte E/A-Steuerungslogik aufweisen. Das Verarbeitungselement kann auch einen oder mehrere Zwischenspeicher aufweisen. In einigen Ausführungsformen kann auch ein nichtflüchtiger Speicher (wie z. B. Flashspeicher oder Sicherungen) auf dem Chip mit Prozessor 1200 vorhanden sein.
13 veranschaulicht ein Rechensystem 1300, das gemäß einer Ausführungsform in einer Punkt-zu-Punkt(PtP)-Konfiguration ausgelegt ist. Insbesondere zeigt 13 ein System, bei dem Prozessoren, Speichereingabe und Ein-/Ausgabevorrichtungen durch eine Reihe von Punkt-zu-Punkt-Schnittstellen miteinander verbunden sind. Allgemein können eines oder mehrere der hier beschriebenen Rechensysteme auf die gleiche oder ähnliche Weise wie das Rechensystem 1200 ausgelegt sein.
Die Prozessoren 1370 und 1380 können auch jeweils eine Steuervorrichtung mit integrierter Speicherlogik (MC) 1372 und 1382 aufweisen, um mit den Speicherelementen 1332 und 1334 zu kommunizieren. In alternativen Ausführungsformen kann die Speichersteuerungslogik 1372 und 1382 eine von den Prozessoren 1370 und 1380 getrennte diskrete Logik sein. Die Speicherelemente 1332 und/oder 1334 können verschiedene Daten speichern, die durch die Prozessoren 1370 und 1380 verwendet werden, um die hier beschriebenen Operationen und Funktionen zu erreichen.
Bei den Prozessoren 1370 und 1380 kann es sich um jede Art von Prozessor handeln, wie sie im Zusammenhang mit anderen Figuren hier erörtert werden. Die Prozessoren 1370 und 1380 können Daten über eine Punkt-zu-Punkt(PtP)-Schnittstelle 1350 unter Verwendung der Punkt-zu-Punkt-Schnittstellenschaltungen 1378 bzw. 1388 austauschen.
Die Prozessoren 1370 und 1380 können jeweils Daten mit einem Chipsatz 1390 über individuelle Punkt-zu-Punkt-Schnittstellen 1352 und 1354 unter Verwendung der Punkt-zu-Punkt-Schnittstellenschaltungen 1376, 1386, 1394 und 1398 austauschen. Der Chipsatz 1390 kann auch über eine Schnittstelle 1339, wie beispielsweise eine PtP-Schnittstellenschaltung, Daten mit einem Coprozessor 1338, wie beispielsweise einer Hochleistungsgrafikschaltung, einem Maschinenlernbeschleuniger oder einem anderen Coprozessor 1338, austauschen. In alternativen Ausführungsformen könnten einige oder alle der in 13 dargestellten PtP-Verbindungen als Multidrop-Bus statt als PtP-Verbindung implementiert werden.
Der Chipsatz 1390 kann über eine Schnittstellenschaltung 1396 mit einem Bus 1320 in Kommunikation stehen. Der Bus 1320 kann eine oder mehrere Vorrichtungen aufweisen, die über ihn kommunizieren, wie z. B. eine Busbrücke 1318 und E/A-Vorrichtungen 1316. Über einen Bus 1310 kann die Busbrücke 1318 mit anderen Vorrichtungen wie einer Benutzeroberfläche 1312 (z. B. Tastatur, Maus, Touchscreen oder andere Eingabegeräte), Kommunikationsvorrichtungen 1326 (z. B. Modems, Netzwerkschnittstellenvorrichtungen oder andere Arten von Kommunikationsvorrichtungen, die über ein Computernetzwerk 1360 kommunizieren können), Audio-E/A-Vorrichtungen 1314 und/oder einer Datenspeichervorrichtung 1328 kommuniziert werden. Die Datenspeichervorrichtung 1328 kann den Code 1330 speichern, der durch die Prozessoren 1370 und/oder 1380 ausgeführt werden kann. In alternativen Ausführungsformen könnten beliebige Teile der Busarchitekturen mit einem oder mehreren PtP-Verbindungen implementiert sein.
Das in 13 dargestellte Rechensystem ist eine schematische Darstellung einer Ausführungsform eines Rechensystems, das zur Implementierung verschiedener hier behandelter Ausführungsformen verwendet werden kann. Es versteht sich, dass verschiedene Komponenten des in 13 dargestellten Systems in einer System-on-a-Chip(SoC)-Architektur oder in jeder anderen geeigneten Konfiguration kombiniert werden können, die in der Lage ist, die Funktionalität und die Eigenschaften der hier aufgeführten Beispiele und Implementierungen zu erreichen.
Während einige der hier beschriebenen und dargestellten Systeme und Lösungen eine Vielzahl von Elementen aufweisen oder mit einer Vielzahl von Elementen verknüpft sind, können möglicherweise nicht alle explizit dargestellten oder beschriebenen Elemente in jeder alternativen Implementierung der vorliegenden Offenbarung verwendet sein. Darüber hinaus können sich eines oder mehrere der hier beschriebenen Elemente außerhalb eines Systems befinden, während in anderen Fällen bestimmte Elemente innerhalb oder als Teil eines oder mehrerer der anderen beschriebenen Elemente sowie andere Elemente, die in der dargestellten Implementierung nicht beschrieben sind, vorhanden sein. Ferner können bestimmte Elemente mit anderen Komponenten kombiniert sowie für alternative oder zusätzliche Zwecke zusätzlich zu den hier beschriebenen Zwecken verwendet werden.
Ferner versteht sich, dass es sich bei den oben aufgeführten Beispielen um nicht einschränkende Beispiele handelt, die lediglich dazu dienen, bestimmte Prinzipien und Merkmale zu veranschaulichen, und die die möglichen Ausführungsformen der hier beschriebenen Konzepte nicht notwendigerweise begrenzen oder einschränken. Beispielsweise kann eine Vielzahl verschiedener Ausführungsformen unter Verwendung verschiedener Kombinationen der hier beschriebenen Merkmale und Komponenten realisiert werden, einschließlich Kombinationen, die durch die verschiedenen Implementierungen der hier beschriebenen Komponenten realisiert werden. Andere Implementierungen, Merkmale und Details sollten aus dem Inhalt dieser Spezifikation hervorgehen.
Auch wenn diese Offenbarung in Bezug auf bestimmte Implementierungen und generell damit verknüpfte Verfahren beschrieben ist, werden Änderungen und Permutationen dieser Implementierungen und Verfahren für Fachleute offensichtlich sein. Beispielsweise können die hier beschriebenen Maßnahmen in einer anderen Reihenfolge als beschrieben durchgeführt werden und dennoch die gewünschten Ergebnisse erzielen. Beispielsweise erfordern die in den begleitenden Figuren dargestellten Vorgänge nicht notwendigerweise die dargestellte bestimmte Reihenfolge oder sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. In bestimmten Implementierungen können Multitasking und parallele Vorgänge vorteilhaft sein. Zusätzlich können auch andere Layouts und Funktionen der Benutzeroberfläche unterstützt werden. Andere Abweichungen liegen im Rahmen der folgenden Ansprüche.
Obwohl diese Spezifikation viele spezifische Implementierungsdetails enthält, sollten diese nicht als Begrenzungen des Umfangs von Erfindungen oder dessen, was beansprucht werden kann, ausgelegt werden, sondern vielmehr als Beschreibungen von Merkmalen, die für bestimmte Ausführungsformen bestimmter Erfindungen spezifisch sind. Bestimmte Merkmale, die in dieser Spezifikation im Zusammenhang mit separaten Ausführungsformen beschrieben werden, können auch in Kombination in einer einzelnen Ausführungsform implementiert werden. Umgekehrt können verschiedene Merkmale, die im Zusammenhang mit einer einzelnen Ausführungsform beschrieben werden, auch in mehreren Ausführungsformen getrennt oder in jeder geeigneten Unterkombination implementiert werden. Darüber hinaus, obwohl Merkmale oben als in bestimmten Kombinationen wirkend beschrieben und sogar zunächst als solche beansprucht sein können, können ein oder mehrere Merkmale aus einer beanspruchten Kombination in einigen Fällen aus der Kombination herausgenommen werden, und die beanspruchte Kombination kann auf eine Unterkombination oder Variation einer Unterkombination geleitet werden.
In ähnlicher Weise sollte, auch wenn die Operationen in den Zeichnungen in einer bestimmten Reihenfolge dargestellt sind, dies nicht so verstanden werden, dass diese Operationen in der gezeigten Reihenfolge oder in sequentieller Reihenfolge durchgeführt werden müssen oder dass alle dargestellten Operationen durchgeführt werden müssen, um die gewünschten Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und parallele Vorgänge vorteilhaft sein. Darüber hinaus sollte die Trennung der verschiedenen Systemkomponenten in den oben beschriebenen Ausführungsformen nicht so verstanden werden, dass eine solche Trennung in allen Ausführungsformen erforderlich ist, und es sollte verstanden werden, dass die beschriebenen Programmkomponenten und Systeme generell zusammen in ein einzelnes Softwareprodukt integriert oder in mehrere Softwareprodukte gepackt werden können.
Die folgenden Beispiele beziehen sich auf Ausführungsformen gemäß dieser Spezifikation. Beispiel 1 ist eine Vorrichtung, die Folgendes aufweist: ein Sicherheitsbegleitteilsystem eines automatisierten Fahrsystems eines Fahrzeugs, wobei das Sicherheitsbegleitteilsystem aufweist: einen ersten Prozessor; einen ersten Speicher; eine oder mehrere Schnittstellen zur Kopplung des Sicherheitsbegleitteilsystems mit einem Rechenteilsystem des automatisierten Fahrsystems; einen Sicherheitswächter, der durch den ersten Prozessor ausgeführt wird, um: auf Daten zuzugreifen, die im Rechenteilsystem erzeugt werden, wobei die Daten eine Bestimmung durch das Rechenteilsystem anzeigen, die mit einer automatisierten Fahraufgabe verbunden ist, die durch das automatisierte Fahrsystem durchzuführen ist, wobei die Bestimmung durch eine automatisierte Fahranwendung vorgenommen wird, die durch eine andere, zweite Vorrichtung auf dem Rechenteilsystem ausgeführt wird; und zu bestimmen, ob die Bestimmung basierend auf den Daten sicher ist, wobei das Sicherheitsbegleitteilsystem dazu ausgelegt ist, eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem zu realisieren.
Beispiel 2 umfasst den Gegenstand von Beispiel 1, wobei der Sicherheitswächter ferner dazu dient, eine Maßnahme zur Steuerung der automatisierten Fahraufgabe basierend auf einer Sicherheitsbestimmung, dass die Bestimmung unsicher ist, a uszu lösen.
Beispiel 3 umfasst den Gegenstand von Beispiel 2, wobei die Maßnahme die automatisierte Fahraufgabe durch eine andere automatisierte Fahraufgabe ersetzt und das Sicherheitsbegleitteilsystem ein Signal an einen oder mehrere Aktoren des Fahrzeugs sendet, um zu bewirken, dass die andere automatisierte Fahraufgabe basierend auf der Sicherheitsbestimmung durchgeführt wird.
Beispiel 4 umfasst den Gegenstand von Beispiel 2, wobei die Maßnahme die Übergabe der Steuerung der automatisierten Fahraufgaben vom Rechenteilsystem an eine andere automatisierte Fahrfunktion auf dem automatisierten Fahrsystem beinhaltet, wobei die andere automatisierte Fahrfunktion auszuführen ist, um das Fahrzeug in einen sicheren physischen Zustand zu bringen.
Beispiel 5 umfasst den Gegenstand von Beispiel 4, wobei das Sicherheitsbegleitteilsystem die verschiedenen automatischen Fahrfunktionen aufweist und die verschiedenen automatischen Fahrfunktionen durch die erste Prozessorvorrichtung ausgeführt werden.
Beispiel 6 umfasst den Gegenstand von Beispiel 4, wobei die verschiedenen Funktionen des automatisierten Fahrens auf einem automatisierten Ausfallsicherungsfahrteilsystem getrennt vom Sicherheitsbegleitteilsystem und Rechenteilsystem des automatisierten Fahrsystems vorgesehen sind.
Beispiel 7 umfasst den Gegenstand eines der Beispiele 1-6, wobei die Bestimmung mindestens eine Bestimmung der Objekterkennung, eine Bestimmung der Objektklassifizierung, eine Bestimmung der Wegplanung, eine Bestimmung des Fahrzeugzustands, eine Bestimmung der Lokalisierung oder eine Bestimmung der Bewegungsplanung durch die automatisierte Fahranwendung aufweist, wobei die automatisierte Fahraufgabe auf der Bestimmung basiert.
Beispiel 8 umfasst den Gegenstand eines der Beispiele 1-7, wobei der Sicherheitswächter ferner dazu dient: Hardwareüberwachungsdaten zu empfangen, wobei die Hardwareüberwachungsdaten Ereignisse identifizieren, die auf der Hardware des Rechenteilsystems im Zusammenhang mit automatisierten Fahraufgaben, die durch das Rechenteilsystem zu bestimmen sind, erkannt werden; einen Fehler in der Hardware des Rechenteilsystems basierend auf den Hardwareüberwachungsdaten zu erkennen; und eine Maßnahme zur Kontrolle der mit dem Fehler verbundenen Auswirkungen durchzuführen.
Beispiel 9 umfasst den Gegenstand von Beispiel 8, wobei das Sicherheitsbegleitteilsystem ferner einen Hardwarewächter zur Überwachung des Betriebs der Hardware des Sicherheitsbegleitteilsystems einschließlich der ersten Vorrichtung aufweist, wobei der Sicherheitsbegleithardwarewächter zweite Hardwareüberwachungsdaten zum Beschreiben von Attributen der Hardware des Sicherheitsbegleitteilsystems erzeugt, und der Sicherheitswächter ferner folgende Aufgaben hat: Erkennen von Fehlern der Hardware des Sicherheitsbegleitteilsystems basierend auf den zweiten Hardwareüberwachungsdaten; und Deaktivieren mindestens eines Teils des automatisierten Fahrsystems basierend auf einem erkannten Fehler der Hardware des Sicherheitsbegleitteilsystems.
Beispiel 10 umfasst den Gegenstand eines der Beispiele 1-9, wobei der Sicherheitswächter ferner dazu dient, Fehler im Zusammenhang mit Schnittstellen zu erkennen, die zur Übermittlung von Signalen im Zusammenhang mit automatisierten Fahraufgaben verwendet werden, die durch das Rechenteilsystem bestimmt werden.
Beispiel 11 umfasst den Gegenstand eines der Beispiele 1-10, wobei das Rechenteilsystem dafür zuständig ist, Sensordaten aus dem Fahrzeug aufzunehmen, um automatisierte Fahraufgaben für das Fahrzeug zu bestimmen, und das Sicherheitsbegleitteilsystem dafür zuständig ist, die Sicherheit des automatisierten Fahrsystems durch Erkennen von Fehlfunktionen des Rechenteilsystems aufrechtzuerhalten.
Beispiel 12 umfasst den Gegenstand eines der Beispiele 1-11, wobei die höhere Sicherheitsintegritätsstufe eine Sicherheitsintegritätsstufe für Kraftfahrzeuge (ASIL) aufweist.
Beispiel 13 umfasst den Gegenstand eines der Beispiele 1-12, wobei das Sicherheitsbegleitteilsystem ferner einen Sicherheitsproxy aufweist zum: Empfangen von Daten über Sicherheitsereignisse aus dem Rechenteilsystem, wobei die Daten Daten über Sicherheitsereignisse enthalten; Bestimmen der Integrität der Daten über Sicherheitsereignisse; und Liefern einer Teilmenge der Daten über Sicherheitsereignisse auf Anforderung an den Sicherheitswächter im Zusammenhang mit der Aufnahme der Teilmenge der Daten über Sicherheitsereignisse durch den Sicherheitswächter, um Fehlfunktionen des Rechenteilsystems zu bestimmen.
Beispiel 14 umfasst den Gegenstand eines der Beispiele 1-13, wobei die erste Prozessorvorrichtung einen ersten Kfz-Mikrocontroller und die zweite Prozessorvorrichtung einen separaten, zweiten Kfz-Mikrocontroller aufweist.
Beispiel 15 ist mindestens ein nichtflüchtiges, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch eine Maschine ausführbar sind, um die Maschine dazu zu veranlassen: auf Ereignisdaten in einem Sicherheitsbegleitteilsystem eines automatisierten Fahrsystems zuzugreifen, wobei die Ereignisdaten in einem Rechenteilsystem des automatisierten Fahrsystems erzeugt werden und die Ereignisdaten eine Bestimmung durch das Rechenteilsystem angeben, die mit einer automatisierten Fahraufgabe verknüpft ist; im Sicherheitsbegleitteilsystem auf erste Hardwareüberwachungsdaten zuzugreifen, die im Rechenteilsystem erfasst werden, um Attribute der Hardware des Rechenteilsystems anzugeben; auf zweite Hardwareüberwachungsdaten zuzugreifen, die im Sicherheitsbegleitteilsystem erfasst werden, um Attribute der Hardware des Sicherheitsbegleitteilsystems anzugeben, wobei die Hardware des Sicherheitsbegleitteilsystems von der Hardware des Rechenteilsystems verschieden ist; im Sicherheitsbegleitteilsystem Fehlfunktionen zu bestimmen, die die Sicherheit automatisierter Fahraufgaben des automatisierten Fahrsystems basierend auf einem oder mehreren der Ereignisdaten, ersten Hardwareüberwachungsdaten oder zweiten Hardwareüberwachungsdaten beeinträchtigen können; und eine Maßnahme zur Steuerung einer durch das Sicherheitsbegleitteilsystem bestimmten Fehlfunktion a uszu lösen.
Beispiel 16 umfasst den Gegenstand von Beispiel 15, wobei die Maßnahme die automatisierte Fahraufgabe durch eine andere automatisierte Fahraufgabe ersetzt und das Sicherheitsbegleitteilsystem ein Signal an einen oder mehrere Aktoren eines Fahrzeugs sendet, um zu bewirken, dass die andere automatisierte Fahraufgabe basierend auf der Fehlfunktion durchgeführt wird.
Beispiel 17 umfasst den Gegenstand von Beispiel 15, wobei die Maßnahme die Übergabe der Steuerung der automatisierten Fahraufgaben vom Rechenteilsystem an eine andere automatisierte Fahrfunktion auf dem automatisierten Fahrsystem beinhaltet, wobei die andere automatisierte Fahrfunktion auszuführen ist, um das Fahrzeug in einen sicheren physischen Zustand zu bringen.
Beispiel 18 umfasst den Gegenstand von Beispiel 17, wobei das Sicherheitsbegleitteilsystem die verschiedenen automatischen Fahrfunktionen aufweist und die verschiedenen automatischen Fahrfunktionen durch die erste Prozessorvorrichtung ausgeführt werden.
Beispiel 19 umfasst den Gegenstand von Beispiel 17, wobei die verschiedenen Funktionen des automatisierten Fahrens auf einem automatisierten Ausfallsicherungsfahrteilsystem getrennt vom Sicherheitsbegleitteilsystem und Rechenteilsystem des automatisierten Fahrsystems vorgesehen sind.
Beispiel 20 umfasst den Gegenstand eines der Beispiele 15-19, wobei die Bestimmung mindestens eine Bestimmung der Objekterkennung, eine Bestimmung der Objektklassifizierung, eine Bestimmung der Wegplanung, eine Bestimmung des Fahrzeugzustands, eine Bestimmung der Lokalisierung oder eine Bestimmung der Bewegungsplanung durch die automatisierte Fahranwendung aufweist, wobei die automatisierte Fahraufgabe auf der Bestimmung basiert.
Beispiel 21 umfasst den Gegenstand eines der Beispiele 15-20, wobei die Anweisungen ferner dazu ausführbar sind, die Maschine zu veranlassen, im Sicherheitsbegleitteilsystem Fehler bezüglich Schnittstellen zu erkennen, die zur Übermittlung von Signalen im Zusammenhang mit automatisierten Fahraufgaben verwendet werden, die durch das Rechenteilsystem bestimmt werden.
Beispiel 22 umfasst den Gegenstand eines der Beispiele 15-21, wobei das Rechenteilsystem dafür zuständig ist, Sensordaten aus einem Fahrzeug aufzunehmen, um automatisierte Fahraufgaben für das Fahrzeug zu bestimmen, und das Sicherheitsbegleitteilsystem dafür zuständig ist, die Sicherheit des automatisierten Fahrsystems durch Erkennen von Fehlfunktionen des Rechenteilsystems aufrechtzuerhalten.
Beispiel 23 umfasst den Gegenstand eines der Beispiele 15-22, wobei das Sicherheitsbegleitteilsystem eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem aufweist.
Beispiel 24 umfasst den Gegenstand des Beispiels 23, wobei die höhere Sicherheitsintegritätsstufe eine Sicherheitsintegritätsstufe für Kraftfahrzeuge (ASIL) aufweist.
Beispiel 25 umfasst den Gegenstand eines der Beispiele 15-24, wobei die Anweisungen ferner dazu ausführbar sind, die Maschine zu veranlassen: bestimmte Daten an einem Sicherheitsproxyelement des Sicherheitsbegleitteilsystems zu empfangen, wobei die bestimmten Daten ein oder mehrere Ereignisdaten, erste Hardwareüberwachungsdaten und zweite Hardwareüberwachungsdaten umfassen; die Integrität der bestimmten Daten zu bestimmen; und eine Teilmenge der bestimmten Daten auf Anforderung an die Logik des Sicherheitsbegleitteilsystems im Zusammenhang mit dem Gebrauch der Teilmenge der Sicherheitsereignisdaten durch die Logik des Sicherheitsbegleitteilsystems zu liefern, um Fehlfunktionen des Rechenteilsystems zu bestimmen.
Beispiel 26 umfasst den Gegenstand eines der Beispiele 15-25, wobei das Sicherheitsbegleitteilsystem eine erste Prozessorvorrichtung und das Rechenteilsystem eine separate, zweite Prozessorvorrichtung aufweist.
Beispiel 27 umfasst den Gegenstand des Beispiels 26, wobei die erste Prozessorvorrichtung einen ersten Kfz-Mikrocontroller und die zweite Prozessorvorrichtung einen separaten, zweiten Kfz-Mikrocontroller aufweist.
Beispiel 28 ist ein Verfahren, das Folgendes aufweist: Zugreifen auf Ereignisdaten in einem Sicherheitsbegleitteilsystem eines automatisierten Fahrsystems, wobei die Ereignisdaten in einem Rechenteilsystem des automatisierten Fahrsystems erzeugt werden und die Ereignisdaten eine Bestimmung durch das Rechenteilsystem im Zusammenhang mit einer automatisierten Fahraufgabe bestimmen; Zugreifen auf erste, im Rechenteilsystem erfasste Hardwareüberwachungsdaten im Sicherheitsbegleitteilsystem, um Attribute der Hardware des Rechenteilsystems anzugeben; Zugreifen auf zweite, im Sicherheitsbegleitteilsystem erfasste Hardwareüberwachungsdaten, um Attribute der Hardware des Sicherheitsbegleitteilsystems anzugeben, wobei die Hardware des Sicherheitsbegleitteilsystems von der Hardware des Rechenteilsystems verschieden ist; Bestimmen von Fehlfunktionen im Sicherheitsbegleitteilsystem, die die Sicherheit automatisierter Fahraufgaben des automatisierten Fahrsystems beeinträchtigen können, basierend auf einem oder mehreren der Ereignisdaten, ersten Hardwareüberwachungsdaten oder zweiten Hardwareüberwachungsdaten; und Auslösen einer Maßnahme zur Kontrolle einer durch das Sicherheitsbegleitteilsystem bestimmten Fehlfunktion.
Beispiel 29 umfasst den Gegenstand von Beispiel 28, wobei die Maßnahme die automatisierte Fahraufgabe durch eine andere automatisierte Fahraufgabe ersetzt und das Sicherheitsbegleitteilsystem ein Signal an einen oder mehrere Aktoren eines Fahrzeugs sendet, um zu bewirken, dass die andere automatisierte Fahraufgabe basierend auf der Fehlfunktion durchgeführt wird.
Beispiel 30 umfasst den Gegenstand von Beispiel 28, wobei die Maßnahme die Übergabe der Steuerung der automatisierten Fahraufgaben vom Rechenteilsystem an eine andere automatisierte Fahrfunktion auf dem automatisierten Fahrsystem beinhaltet, wobei die andere automatisierte Fahrfunktion auszuführen ist, um das Fahrzeug in einen sicheren physischen Zustand zu bringen.
Beispiel 31 umfasst den Gegenstand von Beispiel 30, wobei das Sicherheitsbegleitteilsystem die verschiedenen automatischen Fahrfunktionen aufweist und die verschiedenen automatischen Fahrfunktionen durch die erste Prozessorvorrichtung ausgeführt werden.
Beispiel 32 umfasst den Gegenstand von Beispiel 30, wobei die verschiedenen Funktionen des automatisierten Fahrens auf einem automatisierten Ausfallsicherungsfahrteilsystem getrennt vom Sicherheitsbegleitteilsystem und Rechenteilsystem des automatisierten Fahrsystems vorgesehen sind.
Beispiel 33 umfasst den Gegenstand eines der Beispiele 28-32, wobei die Bestimmung mindestens eine Bestimmung der Objekterkennung, eine Bestimmung der Objektklassifizierung, eine Bestimmung der Wegplanung, eine Bestimmung des Fahrzeugzustands, eine Bestimmung der Lokalisierung oder eine Bestimmung der Bewegungsplanung durch die automatisierte Fahranwendung aufweist, wobei die automatisierte Fahraufgabe auf der Bestimmung basiert.
Beispiel 34 umfasst den Gegenstand eines der Beispiele 28-33, ferner umfassend das Erkennen von Fehlern am Sicherheitsbegleitteilsystem im Zusammenhang mit Schnittstellen, die zur Kommunikation von Signalen im Zusammenhang mit automatischen Fahraufgaben verwendet werden, die durch das Rechenteilsystem bestimmt werden.
Beispiel 35 umfasst den Gegenstand eines der Beispiele 28-34, wobei das Rechenteilsystem dafür zuständig ist, Sensordaten aus einem Fahrzeug aufzunehmen, um automatisierte Fahraufgaben für das Fahrzeug zu bestimmen, und das Sicherheitsbegleitteilsystem dafür zuständig ist, die Sicherheit des automatisierten Fahrsystems durch Erkennen von Fehlfunktionen des Rechenteilsystems aufrechtzuerhalten.
Beispiel 36 umfasst den Gegenstand eines der Beispiele 28-35, wobei das Sicherheitsbegleitteilsystem eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem aufweist.
Beispiel 37 umfasst den Gegenstand des Beispiels 36, wobei die höhere Sicherheitsintegritätsstufe eine Sicherheitsintegritätsstufe für Kraftfahrzeuge (ASIL) aufweist.
Beispiel 38 umfasst den Gegenstand eines der Beispiele 28-37 und umfasst ferner: Empfangen bestimmter Daten an einem Sicherheitsproxyelement des Sicherheitsbegleitteilsystems, wobei die bestimmten Daten ein oder mehrere Ereignisdaten, erste Hardwareüberwachungsdaten und zweite Hardwareüberwachungsdaten umfassen; Bestimmen der Integrität der bestimmten Daten; und bei Bedarf Bereitstellen einer Teilmenge der bestimmten Daten an die Logik des Sicherheitsbegleitteilsystems in Verbindung mit dem Aufnehmen der Teilmenge der Sicherheitsereignisdaten durch die Logik des Sicherheitsbegleitteilsystems, um Fehlfunktionen des Rechenteilsystems zu bestimmen.
Beispiel 39 umfasst den Gegenstand eines der Beispiele 28-38, wobei das Sicherheitsbegleitteilsystem eine erste Prozessorvorrichtung und das Rechenteilsystem eine separate, zweite Prozessorvorrichtung aufweist.
Beispiel 40 umfasst den Gegenstand des Beispiels 39, wobei die erste Prozessorvorrichtung einen ersten Kfz-Mikrocontroller und die zweite Prozessorvorrichtung einen separaten, zweiten Kfz-Mikrocontroller aufweist.
Beispiel 41 ist ein System, das eine Einrichtung zum Durchführen des Verfahrens eines der Beispiele 28-40 aufweist.
Beispiel 42 ist ein System, das Folgendes aufweist: ein Rechenteilsystem, das Folgendes aufweist: einen ersten Mikrocontroller; einen ersten Speicher; eine Automatisierungsengine, die durch den ersten Mikrocontroller ausführbar ist, um: Sensordaten zu empfangen; und eine automatisierte Aufgabe zu bestimmen, die durch eine Maschine basierend auf den Sensordaten durchzuführen ist; ein Sicherheitsbegleitteilsystem, das Folgendes aufweist: einen zweiten Mikrocontroller; einen zweiten Speicher; einen Sicherheitswächter, der durch den zweiten Mikrocontroller ausführbar ist, um: auf Ereignisdaten zur Identifizierung von Attributen des Rechenteilsystems zuzugreifen, die mit der Bestimmung der automatisierten Aufgabe verknüpft sind; eine Fehlfunktion des Rechenteilsystems basierend auf den Ereignisdaten zu bestimmen; und zu bewirken, dass eine Maßnahme zur Steuerung der Sicherheit der Maschine basierend auf der bestimmten Fehlfunktion durchgeführt wird, wobei das Sicherheitsbegleitteilsystem eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem implementiert.
Beispiel 43 umfasst den Gegenstand von Beispiel 42, wobei das Rechenteilsystem ferner einen ersten Hardwarewächter aufweist, um die Hardware des Rechenteilsystems zu überwachen, um Fehlfunktionen der Hardware des Rechenteilsystems zu erkennen und erste Zustandsdaten basierend auf der Überwachung der Hardware des Rechenteilsystems zu erzeugen, wobei der Sicherheitswächter ferner dazu dient: auf die ersten Zustandsdaten zuzugreifen; und basierend auf den ersten Zustandsdaten zu bestimmen, dass eine Hardwarefehlfunktion der Hardware des Rechenteilsystems die Sicherheit der Maschine beeinträchtigt.
Beispiel 44 umfasst den Gegenstand von Beispiel 43, wobei das Sicherheitsbegleitteilsystem ferner einen zweiten Hardwarewächter zur Überwachung der Hardware des Sicherheitsbegleitteilsystems aufweist, um Fehlfunktionen der Hardware des Sicherheitsbegleitteilsystems zu erkennen und basierend auf der Überwachung der Hardware des Sicherheitsbegleitteilsystems zweite Zustandsdaten zu erzeugen, wobei der Sicherheitswächter ferner dazu dient: auf die zweiten Zustandsdaten zuzugreifen; und basierend auf den zweiten Zustandsdaten zu bestimmen, dass eine Hardwarefehlfunktion der Hardware des Sicherheitsbegleitteilsystems die Sicherheit der Maschine beeinträchtigt.
Beispiel 45 umfasst den Gegenstand eines der Beispiele 42-44, wobei die Maßnahme die automatisierte Aufgabe durch eine andere automatisierte Aufgabe ersetzt und das Sicherheitsbegleitteilsystem ein Signal an einen oder mehrere Aktoren der Maschine sendet, um zu bewirken, dass die andere automatisierte Aufgabe basierend auf der Sicherheitsbestimmung durchgeführt wird.
Beispiel 46 umfasst den Gegenstand eines der Beispiele 42-44, wobei die Maßnahme die Übergabe der Steuerung automatisierter Aufgaben vom Rechenteilsystem an eine andere Automatisierungsfunktionalität auf dem automatisierten System umfasst, wobei die andere Automatisierungsfunktionalität auszuführen ist, um die Maschine in einen sicheren physischen Zustand zu bringen.
Beispiel 47 umfasst den Gegenstand von Beispiel 46, wobei das Sicherheitsbegleitteilsystem die verschiedenen Automatisierungsfunktionen aufweist und die verschiedenen Automatisierungsfunktionen durch die erste Prozessorvorrichtung ausgeführt werden.
Beispiel 48 umfasst den Gegenstand von Beispiel 46, wobei die verschiedenen Automatisierungsfunktionen auf einem von dem Sicherheitsbegleitteilsystem und dem Rechenteilsystem des Automatisierungssystems getrennten Ausfallteilautomatisierungssystem bereitgestellt werden.
Beispiel 49 umfasst den Gegenstand eines der Beispiele 42-48, wobei die Bestimmung der automatisierten Aufgabe mindestens eines von einer Bestimmung der Objekterkennung, einer Bestimmung der Objektklassifizierung, einer Bestimmung der Wegplanung, einer Bestimmung des Maschinenzustands, einer Bestimmung der Lokalisierung oder einer Bestimmung der Bewegungsplanung durch das Rechenteilsystem aufweist, wobei die automatisierte Aufgabe auf der Bestimmung der automatisierten Aufgabe basiert.
Beispiel 50 umfasst den Gegenstand eines der Beispiele 42-49, wobei der Sicherheitswächter ferner dazu dient: Hardwareüberwachungsdaten zu empfangen, wobei die Hardwareüberwachungsdaten Ereignisse identifizieren, die auf der Hardware des Rechenteilsystems im Zusammenhang mit Automatisierungsaufgaben, die durch das Rechenteilsystem zu bestimmen sind, erkannt werden; einen Fehler in der Hardware des Rechenteilsystems basierend auf den Hardwareüberwachungsdaten zu erkennen; und eine Maßnahme zur Kontrolle der mit dem Fehler verbundenen Auswirkungen durchzuführen.
Beispiel 51 umfasst den Gegenstand von Beispiel 50, wobei das Sicherheitsbegleitteilsystem ferner einen Hardwarewächter zur Überwachung des Betriebs der Hardware des Sicherheitsbegleitteilsystems einschließlich der ersten Vorrichtung aufweist, wobei der Sicherheitsbegleithardwarewächter zweite Hardwareüberwachungsdaten zum Beschreiben von Attributen der Hardware des Sicherheitsbegleitteilsystems erzeugt, und der Sicherheitswächter ferner folgende Aufgaben hat: Erkennen von Fehlern der Hardware des Sicherheitsbegleitteilsystems basierend auf den zweiten Hardwareüberwachungsdaten; und Deaktivieren mindestens eines Teils des automatisierten Fahrsystems basierend auf einem erkannten Fehler der Hardware des Sicherheitsbegleitteilsystems.
Beispiel 52 umfasst den Gegenstand eines der Beispiele 42-51, wobei der Sicherheitswächter ferner dazu dient, Fehler im Zusammenhang mit Schnittstellen zu erkennen, die zur Übermittlung von Signalen im Zusammenhang mit Automatisierungsaufgaben verwendet werden, die durch das Rechenteilsystem bestimmt werden.
Beispiel 53 umfasst den Gegenstand eines der Beispiele 42-52, wobei das Rechenteilsystem dafür zuständig ist, Sensordaten aus der Maschine aufzunehmen, um Automatisierungsaufgaben für die Maschine zu bestimmen, und das Sicherheitsbegleitteilsystem dafür zuständig ist, die Sicherheit des automatisierten Systems durch Erkennen von Fehlfunktionen des Rechenteilsystems aufrechtzuerhalten.
Beispiel 54 umfasst den Gegenstand eines der Beispiele 42-53, wobei das Sicherheitsbegleitteilsystem ferner einen Sicherheitsproxy aufweist zum: Empfangen von Daten über Sicherheitsereignisse aus dem Rechenteilsystem, wobei die Daten Daten über Sicherheitsereignisse enthalten; Bestimmen der Integrität der Daten über Sicherheitsereignisse; und Liefern einer Teilmenge der Daten über Sicherheitsereignisse auf Anforderung an den Sicherheitswächter im Zusammenhang mit der Aufnahme der Teilmenge der Daten über Sicherheitsereignisse durch den Sicherheitswächter, um Fehlfunktionen des Rechenteilsystems zu bestimmen.
Beispiel 55 umfasst den Gegenstand eines der Beispiele 42-54 und umfasst ferner die Maschine, wobei die Maschine ein Personenfahrzeug umfasst.
Beispiel 56 umfasst den Gegenstand des Beispiels 55, wobei die höhere Sicherheitsintegritätsstufe eine Sicherheitsintegritätsstufe für Kraftfahrzeuge (ASIL) aufweist.
Beispiel 57 umfasst den Gegenstand eines der Beispiele 55-56, wobei die erste Prozessorvorrichtung einen ersten Kfz-Mikrocontroller und die zweite Prozessorvorrichtung einen separaten, zweiten Kfz-Mikrocontroller aufweist.
Beispiel 58 umfasst den Gegenstand eines der Beispiele 42-54 und umfasst ferner die Maschine, wobei die Maschine einen Roboter umfasst.
Somit wurden bestimmte Ausführungsformen des behandelten Themas beschrieben. Andere Ausführungsformen liegen im Rahmen der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen genannten Maßnahmen in einer anderen Reihenfolge durchgeführt werden und dennoch die gewünschten Ergebnisse erzielen. Darüber hinaus benötigen die in den begleitenden Figuren dargestellten Vorgänge nicht notwendigerweise die dargestellte bestimmte Reihenfolge oder sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

ISO 26262 [0031]
ISO 26262-4 [0064]

Claims

Vorrichtung, umfassend: ein Sicherheitsbegleitteilsystem (710) eines automatisierten Fahrsystems (210) eines Fahrzeugs, wobei das Sicherheitsbegleitteilsystem (710) umfasst: eine erste Prozessorvorrichtung; einen ersten Speicher; eine oder mehrere Schnittstellen, um das Sicherheitsbegleitteilsystem (710) mit einem Rechenteilsystem des automatisierten Fahrsystems (210) zu koppeln; einen Sicherheitswächter (810), der durch die erste Prozessorvorrichtung ausgeführt wird, um: auf Daten zuzugreifen, die im Rechenteilsystem (705) erzeugt werden, wobei die Daten eine Bestimmung durch das Rechenteilsystem (705) angeben, die mit einer automatisierten Fahraufgabe verbunden ist, die durch das automatisierte Fahrsystem (210) durchzuführen ist, wobei die Bestimmung durch eine automatisierte Fahranwendung (805) erfolgt, die durch eine andere, zweite Prozessorvorrichtung auf dem Rechenteilsystem (705) ausgeführt wird; und zu bestimmen, ob die Bestimmung basierend auf den Daten sicher ist, wobei das Sicherheitsbegleitteilsystem (710) dazu ausgelegt ist, eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem (705) zu realisieren.
Vorrichtung gemäß Anspruch 1, wobei der Sicherheitswächter (810) ferner dazu dient, eine Maßnahme zum Steuern der automatisierten Fahraufgabe basierend auf einer Sicherheitsbestimmung, dass die Bestimmung unsicher ist, auszulösen; wobei gegebenenfalls die Maßnahme die automatisierte Fahraufgabe durch eine andere automatisierte Fahraufgabe ersetzt und das Sicherheitsbegleitteilsystem (710) ein Signal an einen oder mehrere Aktoren des Fahrzeugs zu senden hat, um zu bewirken, dass die andere automatisierte Fahraufgabe basierend auf der Sicherheitsbestimmung durchgeführt wird.
Vorrichtung gemäß Anspruch 2, wobei die Maßnahme das Übergeben der Steuerung von automatisierten Fahraufgaben vom Rechenteilsystem (705) an eine andere automatisierte Fahrfunktionalität auf dem automatisierten Fahrsystem (210) umfasst, wobei die andere automatisierte Fahrfunktionalität dazu auszuführen ist, das Fahrzeug in einen sicheren physischen Zustand zu bringen; wobei gegebenenfalls das Sicherheitsbegleitteilsystem (710) die andere automatisierte Antriebsfunktionalität umfasst und die andere automatisierte Antriebsfunktionalität durch die erste Prozessorvorrichtung ausgeführt wird; und/oder wobei gegebenenfalls die andere automatisierte Fahrfunktionalität auf einem automatisierten Ausfallsicherungsfahrteilsystem getrennt vom Sicherheitsbegleitteilsystem (710) und Rechenteilsystem (705) des automatisierten Fahrsystems (210) vorgesehen ist.
Vorrichtung gemäß einem der Ansprüche 1 bis 3, wobei die Bestimmung mindestens eines von einer Bestimmung der Objekterkennung, einer Bestimmung der Objektklassifizierung, einer Bestimmung der Wegplanung, einer Bestimmung des Fahrzeugzustands, einer Bestimmung der Lokalisierung oder einer Bestimmung der Bewegungsplanung durch die automatisierte Fahranwendung (805) umfasst, wobei die automatisierte Fahraufgabe auf der Bestimmung basiert.
Vorrichtung gemäß einem der Ansprüche 1 bis 4, wobei der Sicherheitswächter (810) ferner dazu dient: Hardwareüberwachungsdaten zu empfangen, wobei die Hardwareüberwachungsdaten auf der Hardware des Rechenteilsystems (705) erkannte Ereignisse im Zusammenhang mit durch das Rechenteilsystem (705) zu bestimmenden automatisierten Fahraufgaben identifizieren; einen Fehler in der Hardware des Rechenteilsystems (705) basierend auf den Hardwareüberwachungsdaten zu erkennen; und eine Maßnahme durchzuführen, um die mit dem Fehler zusammenhängenden Auswirkungen zu kontrollieren; wobei gegebenenfalls das Sicherheitsbegleitteilsystem (710) ferner einen Sicherheitsbegleithardwarewächter umfasst, um den Betrieb der Hardware des Sicherheitsbegleitteilsystems (710) zu überwachen, das die erste Prozessorvorrichtung umfasst, wobei der Sicherheitsbegleithardwarewächter zweite Hardwareüberwachungsdaten zu erzeugen hat, um Attribute der Hardware des Sicherheitsbegleitteilsystems (710) zu beschreiben, und der Sicherheitswächter (810) ferner dazu dient: Fehler der Hardware des Sicherheitsbegleitteilsystems (710) basierend auf den zweiten Hardwareüberwachungsdaten zu erkennen; und mindestens einen Abschnitt des automatisierten Fahrsystems (210) basierend auf einem erkannten Fehler der Hardware des Sicherheitsbegleitteilsystems (710) zu deaktivieren.
Vorrichtung gemäß einem der Ansprüche 1 bis 5, wobei der Sicherheitswächter (810) ferner dazu dient, Fehler im Zusammenhang mit Schnittstellen zu erkennen, die dazu verwendet werden, Signale im Zusammenhang mit durch das Rechenteilsystem (705) bestimmten automatisierten Fahraufgaben zu übermitteln; und/oder wobei das Rechenteilsystem (705) dafür zuständig ist, Sensordaten aus dem Fahrzeug aufzunehmen, um automatisierte Fahraufgaben für das Fahrzeug zu bestimmen, und das Sicherheitsbegleitteilsystem (710) dafür zuständig ist, die Sicherheit des automatisierten Fahrsystems (210) durch Erkennen von Fehlfunktionen des Rechenteilsystems (705) aufrechtzuerhalten; und/oder wobei die höhere Sicherheitsintegritätsstufe eine Kraftfahrzeug-Sicherheitsintegritätsstufe (ASIL) umfasst.
Vorrichtung gemäß einem der Ansprüche 1 bis 6, wobei das Sicherheitsbegleitteilsystem (710) ferner ein Sicherheitsproxy umfasst, um: Sicherheitsereignisdaten aus dem Rechenteilsystem (705) zu empfangen, wobei die Daten Sicherheitsereignisdaten umfassen; die Integrität der Sicherheitsereignisdaten zu bestimmen; und dem Sicherheitswächter (810) auf Anforderung eine Teilmenge der Sicherheitsereignisdaten im Zusammenhang mit dem Aufnehmen der Teilmenge der Sicherheitsereignisdaten durch den Sicherheitswächter (810) bereitzustellen, um Fehlfunktionen des Rechenteilsystems (705) zu bestimmen; und/oder wobei die erste Prozessorvorrichtung einen ersten Kfz-Mikrocontroller und die zweite Prozessorvorrichtung einen separaten, zweiten Kfz-Mikrocontroller umfasst.
Mindestens ein nichtflüchtiges, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch eine Maschine ausführbar sind, um die Maschine dazu zu veranlassen: auf Ereignisdaten in einem Sicherheitsbegleitteilsystem (710) eines automatisierten Fahrsystems (210) zuzugreifen, wobei die Ereignisdaten in einem Rechenteilsystem (705) des automatisierten Fahrsystems (210) erzeugt werden und die Ereignisdaten eine Bestimmung durch das Rechenteilsystem (705) im Zusammenhang mit einer automatisierten Fahraufgabe angeben; im Sicherheitsbegleitteilsystem (710) auf erste Hardwareüberwachungsdaten zuzugreifen, die im Rechenteilsystem (705) erfasst werden, um Attribute der Hardware des Rechenteilsystems (705) anzuzeigen; auf zweite Hardwareüberwachungsdaten zuzugreifen, die im Sicherheitsbegleitteilsystem (710) erfasst werden, um Attribute der Hardware des Sicherheitsbegleitteilsystems (710) anzugeben, wobei die Hardware des Sicherheitsbegleitteilsystems (710) von der Hardware des Rechenteilsystems (705) verschieden ist; im Sicherheitsbegleitteilsystem (710) Fehlfunktionen zu bestimmen, die die Sicherheit von automatisierten Fahraufgaben des automatisierten Fahrsystems (210) basierend auf einem oder mehreren der Ereignisdaten, ersten Hardwareüberwachungsdaten oder zweiten Hardwareüberwachungsdaten beeinträchtigen können; und eine Maßnahme zur Kontrolle einer durch das Sicherheitsbegleitteilsystem (710) bestimmten Fehlfunktion auszulösen; wobei gegebenenfalls das Rechenteilsystem (705) die automatisierten Fahraufgaben bestimmt und die Maßnahme zur Kontrolle der Fehlfunktion die Übergabe der Steuerung der automatisierten Fahraufgaben an ein anderes Rechensystem des automatisierten Fahrsystems (210) umfasst.
System, umfassend: ein Rechenteilsystem (705), umfassend: einen ersten Mikrocontroller; einen ersten Speicher; eine Automatisierungsengine, die durch den ersten Mikrocontroller ausführbar ist, um: Sensordaten zu empfangen; und eine durch eine Maschine durchzuführende automatisierte Aufgabe basierend auf den Sensordaten zu bestimmen; und ein Sicherheitsbegleitteilsystem (710), umfassend: einen zweiten Mikrocontroller; einen zweiten Speicher; einen Sicherheitswächter (810), der durch den zweiten Mikrocontroller ausführbar ist, um: auf Ereignisdaten zuzugreifen, um Attribute des Rechenteilsystems (705) im Zusammenhang mit der Bestimmung der automatisierten Aufgabe zu identifizieren; eine Fehlfunktion des Rechenteilsystems (705) basierend auf den Ereignisdaten zu bestimmen; und eine Maßnahme zur Steuerung der Sicherheit der Maschine basierend auf der bestimmten Fehlfunktion durchführen zu lassen, wobei das Sicherheitsbegleitteilsystem (710) eine höhere Sicherheitsintegritätsstufe als das Rechenteilsystem (705) implementiert; wobei gegebenenfalls das Rechenteilsystem (705) ferner einen ersten Hardwarewächter zum Überwachen der Hardware des Rechenteilsystems (705) umfasst, um Fehlfunktionen der Hardware des Rechenteilsystems (705) zu erkennen und basierend auf der Überwachung der Hardware des Rechenteilsystems (705) erste Zustandsdaten zu erzeugen, wobei gegebenenfalls der Sicherheitswächter (810) ferner dazu dient: auf die ersten Zustandsdaten zuzugreifen; und basierend auf den ersten Zustandsdaten zu bestimmen, dass eine Hardwarefehlfunktion der Hardware des Rechenteilsystems (705) die Sicherheit der Maschine beeinträchtigt; wobei ferner gegebenenfalls das Sicherheitsbegleitteilsystem (710) ferner einen zweiten Hardwarewächter zum Überwachen der Hardware des Sicherheitsbegleitteilsystems (710) umfasst, um Fehlfunktionen der Hardware des Sicherheitsbegleitteilsystems (710) zu erkennen und basierend auf der Überwachung der Hardware des Sicherheitsbegleitteilsystems (710) zweite Zustandsdaten zu erzeugen, wobei ferner gegebenenfalls der Sicherheitswächter (810) ferner dazu dient: auf die zweiten Zustandsdaten zuzugreifen; und basierend auf den zweiten Zustandsdaten zu bestimmen, dass eine Hardwarefehlfunktion der Hardware des Sicherheitsbegleitteilsystems (710) die Sicherheit der Maschine beeinträchtigt.
System gemäß Anspruch 9, ferner umfassend die Maschine, wobei die Maschine eines von einem Fahrzeug oder einem Roboter umfasst.