DE102021125749A1

DE102021125749A1 - Vorrichtung, Verfahren und Computerprogramm für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug

Info

Publication number: DE102021125749A1
Application number: DE102021125749.2A
Authority: DE
Inventors: Stephan Max; Timo Lange; Pernes Panta; Wolfgang Theimer
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2021-10-05
Filing date: 2021-10-05
Publication date: 2023-04-06

Abstract

Die vorliegende Erfindung bezieht sich auf eine Vorrichtung, ein Verfahren und ein Computerprogramm für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug, sowie auf ein entsprechendes Fahrzeug. Die Vorrichtung umfasst ein oder mehrere Schnittstellen zur Kommunikation mit ein oder mehreren Rechenressourcen des Fahrzeugs. Die Vorrichtung umfasst ein oder mehrere Prozessoren, ausgebildet zum Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs. Die ein oder mehreren Prozessoren sind ausgebildet zum Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt. Die ein oder mehreren Prozessoren sind ausgebildet zum Anpassen des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.

Description

Die vorliegende Erfindung bezieht sich auf eine Vorrichtung, ein Verfahren und ein Computerprogramm für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug, sowie auf ein entsprechendes Fahrzeug.
In modernen Fahrzeugen wird eine immer größer werdende Anzahl von Funktionen durch Software bereitgestellt. Diese Funktionen werden meist durch Dienste implementiert (engl. „Services“), die auf Recheneinheiten des Fahrzeugs ausgeführt werden. Diese Funktionen können beispielsweise als Rechen-Funktionsblöcke implementiert werden, die in Laufzeitumgebungen des Fahrzeugs ausgeführt werden.
Fahrzeuge haben in der Regel eine lange Lebensdauer, in der die verwendete Hardware unverändert bleibt. Ein Auto, das im Jahr 2020 entwickelt wird, könnte beispielsweise bis 2030 verkauft und 15 Jahre lang betrieben werden. In diesem Zusammenhang ist es eine Herausforderung, die Software der Rechen-Funktionsblöcke einsatzfähig und attraktiv zu halten. Diese Herausforderung wird mit der Einführung von Vorgaben zur Software-Betriebssicherheit von Fahrzeugen, etwa nach UNECE (United Nations Economic Councel for Europe, Wirtschaftskommission für Europa der Vereinten Nationen) WP.29 und der ISO/SAE (International Standardization Organization/Society of Automotive Engineers, Internationale Standardisierungs-Organisations/Gesellschaft der Fahrzeug-Ingenieure) 21434, steigen.
Die Fahrzeugsoftware kann im Autohaus, in einer Werkstatt oder über die Luft aktualisiert werden (OTA, „Over-the-Air“). Es gibt jedoch keine standardisierte Methode für Hardware-Ersetzungen. Auch Software-Aktualisierungen sind nur in Grenzen möglich, abhängig von der Rechenkapazität des Fahrzeugs und abhängig davon, ob die verwendeten Schnittstellen modernen Anforderungen genügen.
In vielen Fällen fügen Käufer eines Fahrzeugs im Nachhinein dadurch Funktionen dazu, dass sie zusätzliche Zubehörgeräte im Fahrzeug installieren, wie etwa Navigationsgeräte, Smartphones mit Navigationssoftware und Musik-Streaming oder sogenannte Dashcams. Solches Zubehör kann unabhängig vom Fahrzeug installiert werden und Funktionen unabhängig vom Fahrzeug bereitstellen.
Jedoch bietet Zubehör in der Regel nur eine minimale Integration mit dem Fahrzeug (z. B. über ein Audio-Kabel oder Bluetooth), ohne Zugriff auf Fahrzeugdaten.
Aus US 2013/0031604 A1 ist ein Verfahren für eine entfernte Authentifizierung bekannt. Hierbei wird die Aktualisierung von Anwendungen behandelt, die auf einem Mobilgerät des Fahrers ausgeführt werden und eine Kommunikation mit dem Fahrzeug voraussetzen.
Es besteht der Bedarf, ein verbessertes Konzept zum sicheren Betrieb von Software-Komponenten von Fahrzeugen bereitzustellen.
Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche entsprochen.
Die vorliegende Erfindung basiert auf der Erkenntnis, dass eine Grundlage für einen sicheren Langzeitbetrieb von softwarebasierter Fahrzeugfunktionalität ist, festzustellen, welche Funktionalität im aktuellen Zustand sicher betrieben werden kann, und welche Fahrzeugfunktionalität nicht sicher betrieben werden kann. Wird letzteres festgestellt, werden Maßnahmen getroffen, um den Betrieb der Fahrzeugfunktionalität sicher zu gestalten. Dabei sind verschiedene Maßnahmen denkbar, von einer Aktualisierung des Rechen-Funktionsblocks, der die Fahrzeugfunktionalität bereitstellt, über Maßnahmen zur Einschränkung der Funktionalität des Rechen-Funktionsblocks (etwa durch Beschränken der Kommunikationsfähigkeiten), bis zu einem Austausch der Hardware und Betrieb der vorhandenen Rechen-Funktionsblöcke in einer virtuellen Umgebung. Hierdurch kann ein sicherer Langzeitbetrieb der Fahrzeugfunktionalität ermöglicht werden.
Manche Aspekte der vorliegenden Offenbarung beziehen sich auf eine Vorrichtung für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug. Die Vorrichtung umfasst ein oder mehrere Schnittstellen zur Kommunikation mit ein oder mehreren Rechenressourcen des Fahrzeugs. Die Vorrichtung umfasst ein oder mehrere Prozessoren, ausgebildet zum Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs. Die ein oder mehreren Prozessoren sind ausgebildet zum Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt. Die ein oder mehreren Prozessoren sind ausgebildet zum Anpassen des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt. Durch das Prüfen, ob der Betrieb der Rechen-Funktionsblöcke der Sicherheitsvorgabe entspricht, kann ein Handlungsbedarf festgestellt werden. Durch Anpassen des Betriebs des Rechen-Funktionsblocks kann wiederum sichergestellt werden, dass alle Rechen-Funktionsblöcke entsprechend der Sicherheitsvorgabe betrieben werden.
Beispielsweise kann die Prüfung negativ ausfallen, falls der Betrieb des Rechenfunktionsblocks der Sicherheitsvorgabe nicht genügt und eine Aktualisierung, zumindest unter Nutzung der vorhandenen Rechenressourcen, ausgeschlossen ist. Ist eine Aktualisierung notwendig, aber nicht möglich, so kann ein ausreichend sicherer Betrieb des Rechen-Funktionsblocks möglicherweise nicht sichergestellt werden.
Nun gibt es mehrere Möglichkeiten, die Betriebssicherheit des Fahrzeugs sicherzustellen.
Beispielsweise kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren des Rechen-Funktionsblocks umfassen. Hierdurch kann verhindert werden, dass Rechen-Funktionsblöcke betrieben werden, die nicht der Sicherheitsvorgabe entsprechen.
Alternativ kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks umfassen. Dadurch wird der Rechen-Funktionsblock von den anderen Fahrzeugkomponenten isoliert, wodurch sich in vielen Fällen ein sicherer Betrieb des Rechen-Funktionsblocks ermöglichen lässt, jedoch teilweise mit Funktionseinschränkungen.
Beispielsweise kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks mit ein oder mehreren anderen Rechen-Funktionsblöcken des Fahrzeugs umfassen. Hierdurch kann eine schadhafte Beeinflussung der ein oder mehreren anderen Funktionsblöcke durch den Rechen-Funktionsblock verhindert werden. Zusätzlich oder alternativ kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks mit einer entfernten Gegenstelle umfassen. Hierdurch kann verhindert werden, dass entfernte Aktoren Zugriff auf das Fahrzeug erlangen.
In manchen Beispielen umfasst das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen einer Kopplung des Rechen-Funktionsblocks mit einer entfernten Gegenstelle. Hierdurch können der Rechen-Funktionsblock und die entfernte Gegenstelle die Möglichkeit auf gegenseitige Kommunikation und Beeinflussung verlieren. Beispielsweise kann die Kopplung durch ein Entfernen ein oder mehrerer kryptografischer Zertifikate entfernt werden. Sind diese Zertifikate nicht mehr vorhanden, können sich der Rechen-Funktionsblock und die entfernte Gegenstelle weigern, mit der jeweiligen Gegenstelle zu kommunizieren.
Im Allgemeinen weisen Fahrzeuge lediglich eine begrenzte Menge an Rechenressourcen auf. Der Bedarf an Rechenressourcen der einzelnen Rechen-Funktionsblöcke kann jedoch über die Zeit steigen. Daher kann nun eine Entscheidung getroffen werden, welche Rechen-Funktionsblöcke weiterbetrieben werden, und welche deaktiviert werden können. Folglich kann das Anpassen des Betriebs des Rechen-Funktionsblocks abhängig davon sein, ob ein Betrieb des Rechen-Funktionsblocks notwendig oder optional ist. Dies kann als Kriterium dafür genutzt werden, welcher Rechen-Funktionsblock zu deaktivieren ist, und welcher, nach Aktualisierung weiterbetrieben werden kann.
Beispielsweises kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren eines anderen Rechen-Funktionsblocks umfassen, um zusätzliche Rechenressourcen für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben. Das Anpassen des Betriebs des Rechen-Funktionsblocks kann ferner ein Aktualisieren des Rechen-Funktionsblocks unter Nutzung der zusätzlichen Rechenressourcen umfassen. Somit können durch Deaktivieren eines optionalen Rechen-Funktionsblocks zusätzliche Rechenressourcen für den Betrieb des notwendigen Rechen-Funktionsblocks geschaffen werden.
Dies ist insbesondere auch dann relevant, wenn die Rechen-Funktionsblöcke zumindest teilweise mittels rekonfigurierbarer Hardware, wie etwa sogenannten Field-Programmable Gate Arrays (Feld-Programmierbare Rechengatter-Anordnung, FPGA), implementiert werden. Beispielsweise können die ein oder mehreren Rechenressourcen des Fahrzeugs zumindest eine rekonfigurierbare Hardware-Komponente umfassen. Das Anpassen des Betriebs des Rechen-Funktionsblocks kann ein Entfernen oder permanentes Deaktivieren des anderen Rechen-Funktionsblocks umfasst, um Rechengatter der rekonfigurierbaren Hardware-Komponente für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben.
Es gibt verschiedene Kriterien und Implementierungen für den Test darauf, ob ein Rechen-Funktionsblock den Sicherheitsvorgaben genügt. Beispielsweise kann das Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, auf zumindest einem von einer Zeitdauer seit einer letzten Aktualisierung der jeweiligen Rechen-Funktionsblöcke, einer Gültigkeit eines kryptographischen Zertifikats der jeweiligen Rechen-Funktionsblöcke, und einem Regelwerk einer entfernten Gegenstelle basieren. Die ersten beiden Möglichkeiten ermöglichen eine zeitbasierte, automatische Feststellung, dass der jeweilige Rechen-Funktionsblock nicht mehr sicher betrieben werden kann (wobei das kryptographische Zertifikat erneuert werden kann, um den weiteren Betrieb des Rechen-Funktionsblocks zu gewährleisten, falls dies vertretbar scheint). Das Regelwerk der entfernten Gegenstelle kann genutzt werden, da in der entfernten Gegenstelle gesammelt für eine Fahrzeugflotte Informationen darüber vorliegen können, welche Rechen-Funktionsblöcke, mit welchem Aktualisierungsstand, sicher betrieben werden können.
Manche Aspekte der vorliegenden Offenbarung beziehen sich auf ein Fahrzeug mit einer Vorrichtung, wie sie zuvor vorgestellt wurde, sowie den ein oder mehreren Rechenressourcen.
Manche Aspekte der vorliegenden Offenbarung beziehen sich auf ein Verfahren für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug. Das Verfahren umfasst ein Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs. Das Verfahren umfasst ferner ein Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt. Das Verfahren umfasst ferner ein Anpassen des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.
Dieses Verfahren kann beispielsweise als Computerprogramm implementiert werden. Daher beziehen sich manche Aspekte der vorliegenden Offenbarung auf ein Programm mit einem Programmcode zum Durchführen des Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
In manchen Fällen kann das Verfahren jedoch auch über ein Computerprogramm herausgehen. Dies kann der Fall sein, wenn die genutzten Rechenressourcen im Rahmen des Fahrzeugs ausgetauscht werden. So kann das Anpassen des Betriebs ein Übertragen der Rechen-Funktionsblöcke in eine virtuelle Ausführungsumgebung, Austauschen zumindest einer Rechenressource des Fahrzeugs durch eine neue Rechenressource, und Ausführen der virtuellen Ausführungsumgebung mit den Rechen-Funktionsblöcken auf der neuen Rechenressource umfassen. Durch Austausch der Rechenressource eine Rechenressource mit einer erhöhten Rechenkapazität oder Speicherkapazität in das Fahrzeug übernommen werden, wodurch eine Aktualisierung der Rechen-Funktionsblöcke für eine längere Zeit ermöglicht werden kann.
Einige Beispiele von Vorrichtungen und/oder Verfahren werden nachfolgend bezugnehmend auf die beiliegenden Figuren lediglich beispielhaft näher erläutert. Es zeigen:

1a zeigt ein schematisches Diagramm eines Beispiels einer Vorrichtung für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug;
1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit einer Vorrichtung für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug; und
2a und 2b zeigen Flussdiagramme von Beispielen eines Verfahrens für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug.

Einige Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Figuren beschrieben. Weitere mögliche Beispiele sind jedoch nicht auf die Merkmale dieser detailliert beschriebenen Ausführungsformen beschränkt. Diese können Modifikationen der Merkmale sowie Entsprechungen und Alternativen zu den Merkmalen aufweisen. Ferner soll die Terminologie, die hierin zum Beschreiben bestimmter Beispiele verwendet wird, nicht einschränkend für weitere mögliche Beispiele sein.
Gleiche oder ähnliche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente beziehungsweise Merkmale, die jeweils identisch oder auch in abgewandelter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktion bereitstellen. In den Figuren können ferner die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein.
Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B, sofern nicht im Einzelfall ausdrücklich anders definiert. Als alternative Formulierung für die gleichen Kombinationen kann „zumindest eines von A und B“ oder „A und/oder B“ verwendet werden. Das gilt Äquivalent für Kombinationen von mehr als zwei Elementen.
Wenn eine Singularform, z. B. „ein, eine“ und „der, die, das“ verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als verpflichtend definiert ist, können weitere Beispiele auch mehrere Elemente verwenden, um die gleiche Funktion zu implementieren. Wenn eine Funktion im Folgenden als unter Verwendung mehrerer Elemente implementiert beschrieben ist, können weitere Beispiele die gleiche Funktion unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungsentität implementieren. Es versteht sich weiterhin, dass die Begriffe „umfasst“, „umfassend“, „aufweist“ und/oder „aufweisend“ bei deren Gebrauch das Vorhandensein der angegebenen Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/oder einer Gruppe derselben beschreiben, dabei aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Elemente, Komponenten und/einer Gruppe derselben ausschließen.
Wie bereits zuvor angesprochen führen die Entwicklungszyklen und die Betriebsdauer von Fahrzeugen zu Herausforderungen in Bezug auf die Instandhaltung von Fahrzeug-Software. So kann Software, die 2020 entwickelt werden, in Fahrzeugen stecken, die 10 Jahre später noch verkauft wird. Diese Fahrzeuge können wiederum 15 Jahre (oder länger) betrieben werden, so dass die Software theoretisch von 2020 bis 2045 gepflegt werden muss. Die Herausforderungen werden in Oldtimern nur größer, denn hier können ggf. neue Risiken aufkommen, die zur Entwicklungszeit der Oldtimer noch nicht aktuell waren, aber etwa in den folgenden 30 Jahren auftreten. Grundsätzlich ist es dabei möglich, das Fahrzeug möglichst aktuell zu halten, oder aber die Funktionalität im Rahmen der Wartung zu entfernen.
Eine Kompatibilität und Aktualisierung der Software auch noch 30 Jahren stellt eine Herausforderung dar. Um diese Herausforderung anzugehen, kann eine der folgenden Strategien angewendet werden.
Einerseits kann die Software über einen sehr langen Zeitraum aktualisiert werden. Auch 30 Jahre alte Hardware kann dabei ständig aktualisiert werden. Dies ist zwar theoretisch möglich, führt aber zu sehr hohen Kosten und ist auch in der Industrie sehr unüblich.
Andererseits kann. wenn die Software veraltet ist - und somit die Hardware im Fahrzeug nicht mehr unterstützt werden kann, die Hardware durch eine moderne Hardware mit aktueller Software ersetzt werden, um das Fahrzeug „frisch“ zu halten. Daher kann der Kunde oder der Hersteller die Hardware ersetzen und sich um die Kosten kümmern. Grundsätzlich können dabei zwei Gruppen von Kunden unterschieden werden - Kunden, die bestehende Fahrzeuge aktualisieren wollen (etwa gegen Bezahlung) und Kunden, die nicht daran interessiert sind. In letzterem Fall sollte die Sicherheit trotzdem gewährleistet sein. Hier kann nun zwischen sicherheitsrelevanten Schnittstellen unterschieden werden, deren Status eingefroren werden kann, oder deren Funktionalität abgetrennt oder abgeschaltet werden kann, und benutzerrelevante Schnittstellen, bei denen unterschiedliche Ansätze gewählt werden können.
Als Alternative kann neue Hardware hinzugefügt werden, die in der Lage ist, die in den 30 Jahren fortentwickelte, neue Software auszuführen. Jedoch ist es hier eine Herausforderung, die Nutzer für die neue Hardware zu begeistern.
In manchen Fällen kann zudem rekonfigurierbare Hardware zur Unterstützung neuer Software-Funktionen eingesetzt werden. Damit können spezialisierte Funktionen implementiert werden, die neue Software-Anwendungen ermöglichen können.
Der Nachteil dieses Ansatzes sind die Entwicklungskosten für eine sehr begrenzte Anzahl von Kunden. Da nicht viele Autobesitzer 15 Jahre alte Autos besitzen und bereit sind, für die Aktualisierung zu zahlen, führen die niedrigen Musterraten zu teuren Ersatzkosten und reduzieren die Anzahl der kaufenden Kunden noch mehr.
Als dritte, und möglicherweise bevorzugte, Möglichkeit bleibt die Aufteilung der Software in gesetzlich vorgeschriebene und nicht gesetzlich vorgeschriebene Software. Manche Funktionalitäten des Fahrzeugs sind gesetzlich vorgeschrieben (wie etwa eCall oder Berichte für Behörden). Diese Software muss über den gesamten Lebenszyklus des Fahrzeugs gewartet werden. Andere Funktionalität kann ggf. eingeschränkt werden, etwa abgeschaltet werden.
Die nachfolgend eingeführte Vorrichtung, das nachfolgend eingeführte Verfahren und das entsprechende Computerprogramm können nun genutzt werden, um die zuvor genannten Möglichkeiten zum sicheren Betrieb der Software-Funktionen des Fahrzeugs zu unterstützen oder bereitzustellen.
1a zeigt ein schematisches Diagramm eines Beispiels einer Vorrichtung 10 für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken 20 in einem Fahrzeug 100. Die Vorrichtung 10 umfasst ein oder mehrere Schnittstellen 12 zur Kommunikation mit ein oder mehreren Rechenressourcen 30 des Fahrzeugs. Die Vorrichtung 10 umfasst ferner ein oder mehrere Prozessoren 14. Optional umfasst die Vorrichtung 10 ferner ein oder mehrere Speichergeräte 16. Grundsätzlich kann die Funktionalität der Vorrichtung 10 durch die ein oder mehreren Prozessoren 14 bereitgestellt werden, mit Hilfe der ein oder mehreren Schnittstellen 12 (zum Austausch von Informationen, etwa zur Kommunikation mit den ein oder mehreren Rechenressourcen oder zur Kommunikation mit einer entfernten Gegenstelle) und/oder mit Hilfe der ein oder mehreren Speichergeräte 16 (zum Speichern und Abrufen von Informationen). Die ein oder mehreren Prozessoren 14 sind ausgebildet zum Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs. Die ein oder mehreren Prozessoren 14 sind ausgebildet zum Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt. Die ein oder mehreren Prozessoren 14 sind ausgebildet zum Anpassen des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.
Die Vorrichtung 10 und die ein oder mehreren Rechenressourcen 30 sind Teil eines Fahrzeugs 100, das in 1b gezeigt ist. 1b zeigt ein schematisches Diagramm eines Beispiels des Fahrzeugs 100 mit der Vorrichtung 10 für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug. Das Fahrzeug 100 umfasst ferner die ein oder mehreren Rechenressourcen 30. Die ein oder mehreren Rechenressourcen sind wiederum ausgebildet, um die Rechen-Funktionsblöcke auszuführen. Innerhalb des Fahrzeugs können die Rechenressourcen 30 dazu ausgebildet, mit anderen Komponenten des Fahrzeugs, wie etwa der Vorrichtung 10, über ein fahrzeuginternes Netzwerk zu kommunizieren.
Die Rechen-Funktionsblöcke sind logische Einheiten, die software-basierte Fahrzeugfunktionalitäten bereitstellen. Dabei kann eine Technik genutzt werden, in der Dienste, die Software-Funktionalitäten des Fahrzeugs bereitstellen, in die Rechen-Funktionsblöcke verpackt werden. Diese Rechen-Funktionsblöcke können wiederum durch sogenannte Software-Container implementiert werden oder diesen entsprechen. Ein oder mehrere Dienste können mit all ihren Abhängigkeiten in einem Software-Container gekapselt werden. Diese Container sind insbesondere zur Nutzung auf Servern und Entwicklergeräten bekannt. Beispielsweise können solche Container von verschiedenen Container-Engines (Docker, Podman, Crio, ...) bereitgestellt werden. Die vorliegende Offenbarung stellt eine Nutzung solcher Container in einem Fahrzeug bereit. Dabei können die Rechenressourcen, die etwa Recheneinheiten/Steuereinheiten des Fahrzeugs entsprechen können, ausgebildet sein, um eine Laufzeitumgebung für die Rechen-Funktionsblöcke/Container bereitzustellen.
Grundlage der Sicherheitsüberprüfung ist die Ermittlung der Rechen-Funktionsblöcke des Fahrzeugs. Dabei können unterschiedliche Fahrzeuge des gleichen Typs beispielsweise unterschiedliche Rechen-Funktionsblöcke aufweisen, etwa aufgrund unterschiedlicher Hardware-Komponenten (verfügt das Fahrzeug über eine Rückfahrkamera, über Ultraschallsensoren, über Radar/Lidar, über ein Navigationsgerät etc.), aufgrund unterschiedlicher Aktualisierungsstände, oder aufgrund dessen, dass ein Nutzer des Fahrzeugs eine Fahrzeugfunktion, und daher auch einen entsprechenden Rechen-Funktionsblock, über ein Fahrzeug-Anwendungsportal installiert hat. Daher wird in einem ersten Schritt eine Inventur über die Rechen-Funktionsblöcke des Fahrzeugs gemacht. Das Ergebnis der Ermittlung der Rechen-Funktionsblöcke des Fahrzeugs kann eine Liste oder Datenstruktur von derzeit betriebenen Rechen-Funktionsblöcken sein. Inaktive Rechen-Funktionsblöcke können dabei, in manchen Beispielen, außer Acht gelassen werden.
Das vorgeschlagene Konzept verwendet einen Erkennungsmechanismus, um zu prüfen, ob die Funktionen noch sicher betrieben werden können. Daher erfolgt eine Prüfung, ob der Betrieb der Rechen-Funktionsblöcke der Sicherheitsvorgabe genügt. Die Prüfung, ob der Betrieb der Rechen-Funktionsblöcke der Sicherheitsvorgabe genügt, kann dabei eine Erkennung von veralteter oder sicherheitsgefährdender Funktionalität umfassen. Dies kann mittels unterschiedlicher Mechanismen erfolgen. Beispielsweise kann das Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, auf einer Zeitdauer seit einer letzten Aktualisierung der jeweiligen Rechen-Funktionsblöcke basieren. Überschreitet die Zeitdauer seit der letzten Aktualisierung einen Schwellenwert, so kann angenommen werden, dass der (uneingeschränkte) Betrieb des jeweiligen Rechen-Funktionsblocks nicht mehr der Sicherheitsvorgabe entspricht.
Diese Zeitdauer kann auch auf kryptographischen Zertifikaten basieren. Beispielsweise kann das Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, auf einer Gültigkeit eines kryptographischen Zertifikats der jeweiligen Rechen-Funktionsblöcke basieren. In diesem Fall wird die Zeitdauer durch das kryptographische Zertifikat gesteuert, welches wiederum durch den Aussteller des Zertifikats festgelegt werden kann. Dabei kann, über die Gültigkeitsdauer des Zertifikats eine Voraussage getroffen werden, wie lange der Hersteller oder der Ersteller des Zertifikats den sicheren Betrieb des jeweiligen Rechen-Funktionsblocks für möglich erachtet. Die Zertifikate können verwendet werden, um das Aktualisierungsverhalten zu verfolgen. Wenn innerhalb eines bestimmten Zeitrahmens keine Aktualisierungen vorhanden sind, kann die Software vom Backend oder von der Vorrichtung deaktiviert werden, um den Rest des Fahrzeugs zu sichern.
Als dritte Möglichkeit kann ein Regelwerk verwendet werden, das von einer entfernten Gegenstelle (etwa des Fahrzeugherstellers) stammt / abgerufen wird. Das Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, kann somit auf dem Regelwerk der entfernten Gegenstelle basieren. Das Regelwerk kann beispielsweise vorgeben, ob der Betrieb eines Rechen-Funktionsblock mit einem gegebenen Aktualisierungsstand der Sicherheitsvorgabe entspricht. Auch kann das Regelwerk vorgeben, welche Maßnahmen ergriffen werden können, um den sicheren Betrieb des Rechen-Funktionsblocks zu gewährleisten, oder ob eine Abschaltung des jeweiligen Rechen-Funktionsblocks notwendig ist.
Nun wird der Betrieb derjenigen Rechen-Funktionsblöcke, deren Betrieb im aktuellen Zustand nicht den Sicherheitsvorgaben entspricht, angepasst.
Hierbei sind, wie bereits ausgeführt, verschiedene Maßnahmen möglich, nämlich die Deaktivierung veralteter Funktionalität, die Kapselung unsicherer Software, die Aufrüstung der Hardware über rekonfigurierbare Hardwaregeräte oder die Aufrüstung der Hardware durch neue Hardware und Virtualisierung der alten Plattform. Letztere Möglichkeit wird im Zusammenhang mit 2b eingeführt.
Grundsätzlich kann die erste, und einfachste Möglichkeit sein, den Rechen-Funktionsblock zu aktualisieren. In den vorliegenden Beispielen wird davon ausgegangen, dass ein solcher Vorgang, zumindest im einfachsten Fall, nicht zu einer Anpassung des Betriebs des Rechen-Funktionsblocks führt. Auch kann in diesem Fall die Prüfung positiv ausfallen, da ein möglicher Verstoß gegen die Sicherheitsvorgabe mit einfachen Mitteln behebbar ist. So kann beispielsweise die Prüfung negativ ausfallen, falls der Betrieb des Rechenfunktionsblocks der Sicherheitsvorgabe nicht genügt und eine Aktualisierung, zumindest unter Nutzung der vorhandenen Rechenressourcen, ausgeschlossen ist. Falls der Betrieb des Rechenfunktionsblocks der Sicherheitsvorgabe nicht genügt, aber eine Aktualisierung möglich ist, so kann die Prüfung positiv ausfallen und die Aktualisierung ohne Anpassung des Betriebs des Rechen-Funktionsblocks durchgeführt werden.
Ist dies jedoch nicht ohne weiteres möglich, so kann eine der folgenden Maßnahmen ergriffen werden.
Veraltete Funktionalitäten können deaktiviert werden (z.B. Zugang zu einem Rechen-Funktionsblock einer Firma, die in Konkurs gegangen ist). In anderen Worten kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren des Rechen-Funktionsblocks umfassen.
Andere „alte“ Funktionalitäten können gekapselt werden, um den Schaden zu begrenzen, den sie anrichten können (z.B. indem ihnen keine Netzwerkverbindung mehr angeboten wird).
Beispielsweise kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks umfassen. Dabei kann zwischen der Kommunikation im Fahrzeug und der Kommunikation mit externen Gegenstellen unterschieden werden. Beispielsweise kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren der Kommunikation des Rechen-Funktionsblocks mit ein oder mehreren anderen Rechen-Funktionsblöcken des Fahrzeugs umfassen. Alternativ oder zusätzlich kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks mit einer entfernten Gegenstelle umfassen. Dies kann beispielsweise darüber geschehen, dass ein Übergabepunkt (engl. Gateway) zwischen den Rechen-Funktionsblöcken und anderen Rechen-Funktionseinheiten instruiert wird, die Kommunikation des Rechen-Funktionsblocks zu blockieren. Alternativ oder zusätzlich kann eine softwarebasiertes Netzwerk so angepasst werden, dass die Kommunikation des Rechen-Funktionsblocks blockiert wird.
Viele Rechen-Funktionsblöcke basieren in Teilen auf einem Konzept, das „Automotive Edge“ genannt wird. Dabei werden die Rechen-Funktionsblöcke, etwa als Container, auf den Rechenressourcen des Fahrzeugs ausgeführt, sind jedoch stark an einen Backend-Server gekoppelt, der den Lebenszyklus der Rechen-Funktionsblöcke verwaltet und einen Zugang zum Netzwerk des Herstellers des Fahrzeugs gewährt. Um nun einen Rechen-Funktionsblock zu deaktivieren, können die Rechen-Funktionsblöcke (auch „Endpunkte“ genannt), die im Fahrzeug ausgeführt werden, gelöscht werden oder die komplette „Automotive Edge“ abgemeldet werden. Um nur die Kommunikation zu blockieren, können die Informationskanäle von der Automotive Edge zum Backend gekappt werden. Folglich kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen einer Kopplung des Rechen-Funktionsblocks mit einer entfernten Gegenstelle (d.h. dem Backend-Server) umfassen. Auch kann ein Löschen von Sicherheitsverbindungen zu Schlüsseln oder wenn möglich der Schlüssel selbst durchgeführt werden. Beispielweise kann die Kopplung durch ein Entfernen ein oder mehrerer kryptografischer Zertifikate entfernt werden. Als Folge können mögliche Verbindungen zu sicheren Partnern nicht hergestellt werden
Darüber hinaus kann das Automotive Edge so gestaltet werden, dass nur das Automotive Edge die Konversation mit dem Backend starten kann. Wenn also das Automotive Edge deaktiviert ist (und möglicherweise anfällig für Angriffe von außerhalb des Fahrzeugs), ist es nicht möglich, das Edge von außen zu erreichen.
Diese Maßnahmen können zusätzlich zum Entfernen oder permanenten Deaktivieren des Rechen-Funktionsblocks ausgeführt werden. Zudem können Warnungen ausgegeben werden, wenn der Benutzer eine neue Software installieren möchte (die vom System nicht mehr unterstützt wird), oder die Installation kann unmöglich gemacht werden.
Wie bereits zuvor ausgeführt kann bei der Anpassung des Betriebs von Rechen-Funktionsblöcken unterschieden werden, ob der Betrieb eines Rechen-Funktionsblocks notwendig ist (etwa rechtlich vorgeschrieben oder zum Betrieb des Fahrzeugs unbedingt nötig), oder ob der Betrieb des Rechen-Funktionsblocks optional ist, etwa weil sich der Rechen-Funktionsblock auf Funktionalität bezieht, die Komfortfunktionen für den Benutzer des Fahrzeugs bereitstellen. Folglich kann das Anpassen des Betriebs des Rechen-Funktionsblocks abhängig davon sein, oder davon abhängig gemacht werden, ob ein Betrieb des Rechen-Funktionsblocks notwendig oder optional ist.
Dabei kann basierend darauf, ob ein Betrieb des Rechen-Funktionsblocks notwendig oder optional ist, die Kommunikation des Rechen-Funktionsblocks blockiert werden, falls der Betrieb des Rechen-Funktionsblocks notwendig ist, und der Rechen-Funktionsblock entfernt oder deaktiviert werden, falls der Betrieb des Rechen-Funktionsblocks nicht notwendig, sondern optional ist.
Beispielsweise können optionale Rechen-Funktionsblöcke (etwa optionale Rechen-Funktionsblöcke, die nie oder nur selten von dem Benutzer des Fahrzeugs genutzt wurden) entfernt oder deaktiviert werden, um Rechenkapazität (oder Speicherkapazität) für einen Rechen-Funktionsblock freizugeben, dessen Betrieb notwendig ist. Daher kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren eines anderen Rechen-Funktionsblocks umfassen, um zusätzliche Rechenressourcen (d.h. zusätzliche Rechenkapazität oder Speicherkapazität) für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben. Das Anpassen des Betriebs des Rechen-Funktionsblocks kann ferner ein Aktualisieren des Rechen-Funktionsblocks unter Nutzung der zusätzlichen Rechenressourcen umfasst. Dabei kann der andere Rechen-Funktionsblock ein Rechen-Funktionsblock sein, dessen Betrieb optional ist. Auch kann für die Aktualisierung des Rechen-Funktionsblocks, sofern der andere Rechen-Funktionsblock nicht entfernt oder deaktiviert wird, zu wenige Rechenressourcen/Kapazität bereitstehen.
In einem Aspekt können die ein oder mehreren Rechenressourcen auch eine rekonfigurierbare Hardware-Komponente (z. B. einen FPGA) umfassen, die umprogrammiert werden kann, um neue Software-Funktionen zu unterstützen, die einen begrenzten Satz spezialisierter Funktionen bereitstellen können, die neue Software-Anwendungen ermöglichen. In anderen Worten können die ein oder mehreren Rechenressourcen des Fahrzeugs zumindest eine rekonfigurierbare Hardware-Komponente umfassen. Je komplexer die Funktionalität wird, desto mehr Gatter des rekonfigurierbaren Hardware-Bausteins werden in der Regel benötigt. Daher kann mit der Zeit eine geringere Anzahl von (komplexeren) Funktionen unterstützt werden. So kann das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren des anderen Rechen-Funktionsblocks umfassen, um Rechengatter der rekonfigurierbaren Hardware-Komponente für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben.
Die zumindest eine Schnittstelle 12 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Beispielen können die ein oder mehreren Prozessoren 14 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Funktionalität der ein oder mehreren Prozessoren 14 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 14 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar.
Die ein oder mehreren Speichergeräte 16 können beispielsweise zumindest ein Element der Gruppe von computerlesbares Speichermedium, magnetisches Speichermedium, optisches Speichermedium, Festplatte, Flash-Speicher, Diskette, Zufallszugriffsspeicher (auch engl. Random Access Memory), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), und Netzwerkspeicher umfassen.
Das Fahrzeug 100 kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
Mehr Details und Aspekte der Vorrichtung und des Fahrzeugs werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher (z.B. 2a bis 2b) beschrieben werden. Die Vorrichtung und das Fahrzeug kann/können ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden.
Im Folgenden wird ein entsprechendes Verfahren Verfahrens für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug vorgestellt, dem die Funktionalität der Vorrichtung 10 der 1a und 1b zugrunde liegt. Merkmale der Vorrichtung, und insbesondere der ein oder mehreren Prozessoren der Vorrichtung, können daher auch in das entsprechende Verfahren der 2a und 2b übernommen werden.
2a und 2b zeigen Flussdiagramme von Beispielen eines Verfahrens für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug. Das Verfahren umfasst ein Ermitteln 210 der Rechen-Funktionsblöcke des Fahrzeugs. Das Verfahren umfasst ferner ein Prüfen 220, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt. Das Verfahren umfasst ferner ein Anpassen 230 des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.
Ein zuvor genannten Verfahrensschritte wurden bereits im Rahmen der entsprechenden Vorrichtung der 1a und 1b vorgestellt. Auch kann diese Verfahren als Computerprogramm implementiert werden.
In manchen Fällen kann das Verfahren jedoch zumindest einen Verfahrensschritt umfassen, der nicht von einem Computerprogramm oder der Vorrichtung der 1a und 1b ausgeführt werden kann. Beispielsweise kann die gesamte Hardware oder eine Haupteinheit der Hardware (d.h. eine oder mehrere Rechenressourcen) aufgerüstet werden. Die alte Fahrzeug-Software-Umgebung kann in Virtualisierung auf der neuen Hardware ausgeführt werden. Somit kann das Anpassen des Betriebs ein Übertragen 232 der Rechen-Funktionsblöcke in eine virtuelle Ausführungsumgebung, Austauschen 234 zumindest einer Rechenressource des Fahrzeugs durch eine neue Rechenressource, und Ausführen 236 der virtuellen Ausführungsumgebung mit den Rechen-Funktionsblöcken auf der neuen Rechenressource umfasst. Von diesen Schritten können die Schritte 232 und 236 durch die Vorrichtung der 1a und/oder 1b sowie das Computerprogramm ausgeführt werden. Die neue Rechenressource kann dabei eine höhere Rechenkapazität und/oder Speicherkapazität aufweisen als die Rechenressource, die ausgetauscht wurde.
Mehr Details und Aspekte des Verfahrens werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher (z.B. 1a bis 1b) beschrieben werden. Das Verfahren kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden.
Die Aspekte und Merkmale, die im Zusammenhang mit einem bestimmten der vorherigen Beispiele beschrieben sind, können auch mit einem oder mehreren der weiteren Beispiele kombiniert werden, um ein identisches oder ähnliches Merkmal dieses weiteren Beispiels zu ersetzen oder um das Merkmal in das weitere Beispiel zusätzlich einzuführen.
Beispiele können weiterhin ein (Computer-)Programm mit einem Programmcode zum Ausführen eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Programm auf einem Computer, einem Prozessor oder einer sonstigen programmierbaren Hardwarekomponente ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen der oben beschriebenen Verfahren können also auch durch programmierte Computer, Prozessoren oder sonstige programmierbare Hardwarekomponenten ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, z. B. Digitaldatenspeichermedien, abdecken, die maschinen-, prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme und Anweisungen codieren beziehungsweise enthalten. Die Programmspeichervorrichtungen können z. B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren, Steuereinheiten, (feld-programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays),(feld)programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), Grafikprozessoren (GPU = Graphics Processor Unit), anwendungsspezifische integrierte Schaltungen (ASIC = application-specific integrated circuit), integrierte Schaltungen (IC= Integrated Circuit) oder Ein-Chip-Systeme (SoC = System-on-a-Chip) abdecken, die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind.
Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, Prozesse, Operationen oder Funktionen nicht als zwingend in der beschriebenen Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht im Einzelfall explizit angegeben oder aus technischen Gründen zwingend erforderlich ist. Daher wird durch die vorhergehende Beschreibung die Durchführung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schritt, eine einzelne Funktion, ein einzelner Prozess oder eine einzelne Operation mehrere Teilschritte, -funktionen, -prozesse oder -operationen einschließen und/oder in dieselben aufgebrochen werden.
Wenn einige Aspekte in den vorhergehenden Abschnitten im Zusammenhang mit einer Vorrichtung oder einem System beschrieben wurden, sind diese Aspekte auch als eine Beschreibung des entsprechenden Verfahrens zu verstehen. Dabei kann beispielsweise ein Block, eine Vorrichtung oder ein funktionaler Aspekt der Vorrichtung oder des Systems einem Merkmal, etwa einem Verfahrensschritt, des entsprechenden Verfahrens entsprechen. Entsprechend dazu sind Aspekte, die im Zusammenhang mit einem Verfahren beschrieben werden, auch als eine Beschreibung eines entsprechenden Blocks, eines entsprechenden Elements, einer Eigenschaft oder eines funktionalen Merkmals einer entsprechenden Vorrichtung oder eines entsprechenden Systems zu verstehen.
Die folgenden Ansprüche werden hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als getrenntes Beispiel für sich stehen kann. Ferner ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen bezieht - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hiermit explizit vorgeschlagen, sofern nicht im Einzelfall angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.
Bezugszeichenliste

10: Steuervorrichtung
12: Schnittstelle
14: Prozessor
16: Speichergerät
20: Rechen-Funktionsblock
30: Recheneinheit
100: Fahrzeug
210: Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs
220: Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt
230: Anpassen des Betriebs eines Rechen-Funktionsblocks
232: Übertragen der Rechen-Funktionsblöcke in eine virtuelle Ausführungsumgebung
234: Austauschen zumindest einer Rechenressource
236: Ausführen der virtuellen Ausführungsumgebung

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 20130031604 A1 [0007]

Claims

Vorrichtung (10) für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken (20) in einem Fahrzeug (100), die Vorrichtung umfassend: Ein oder mehrere Schnittstellen (12) zur Kommunikation mit ein oder mehreren Rechenressourcen (30) des Fahrzeugs; Ein oder mehrere Prozessoren (14), ausgebildet zum: Ermitteln der Rechen-Funktionsblöcke des Fahrzeugs, Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, und Anpassen des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.
Die Vorrichtung gemäß Anspruch 1, wobei die Prüfung negativ ausfällt, falls der Betrieb des Rechenfunktionsblocks der Sicherheitsvorgabe nicht genügt und eine Aktualisierung, zumindest unter Nutzung der vorhandenen Rechenressourcen, ausgeschlossen ist.
Die Vorrichtung gemäß einem der Ansprüche 1 oder 2, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren des Rechen-Funktionsblocks umfasst.
Die Vorrichtung gemäß einem der Ansprüche 1 oder 2, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks umfasst.
Die Vorrichtung gemäß Anspruch 4, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks mit ein oder mehreren anderen Rechen-Funktionsblöcken des Fahrzeugs umfasst, und/oder wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Blockieren einer Kommunikation des Rechen-Funktionsblocks mit einer entfernten Gegenstelle umfasst.
Die Vorrichtung gemäß einem der Ansprüche 1 oder 2, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen einer Kopplung des Rechen-Funktionsblocks mit einer entfernten Gegenstelle umfasst.
Die Vorrichtung gemäß Anspruch 6, wobei die Kopplung durch ein Entfernen ein oder mehrerer kryptografischer Zertifikate entfernt wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 7, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks abhängig davon ist, ob ein Betrieb des Rechen-Funktionsblocks notwendig oder optional ist.
Die Vorrichtung gemäß Anspruch 8, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren eines anderen Rechen-Funktionsblocks umfasst, um zusätzliche Rechenressourcen für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben, und ein Aktualisieren des Rechen-Funktionsblocks unter Nutzung der zusätzlichen Rechenressourcen umfasst.
Die Vorrichtung gemäß Anspruch 9, wobei die ein oder mehreren Rechenressourcen des Fahrzeugs zumindest eine rekonfigurierbare Hardware-Komponente umfassen, wobei das Anpassen des Betriebs des Rechen-Funktionsblocks ein Entfernen oder permanentes Deaktivieren des anderen Rechen-Funktionsblocks umfasst, um Rechengatter der rekonfigurierbaren Hardware-Komponente für den weiteren Betrieb des Rechen-Funktionsblocks freizugeben.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 10, wobei das Prüfen, ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt, auf zumindest einem von einer Zeitdauer seit einer letzten Aktualisierung der jeweiligen Rechen-Funktionsblöcke, einer Gültigkeit eines kryptographischen Zertifikats der jeweiligen Rechen-Funktionsblöcke, und einem Regelwerk einer entfernten Gegenstelle basiert.
Ein Fahrzeug (100) mit einer Vorrichtung gemäß einem der Ansprüche 1 bis 11 und den ein oder mehreren Rechenressourcen (30).
Ein Verfahren für eine Überwachung einer Sicherheit von Rechen-Funktionsblöcken in einem Fahrzeug, das Verfahren umfassend: Ermitteln (210) der Rechen-Funktionsblöcke des Fahrzeugs; Prüfen (220), ob ein Betrieb der Rechen-Funktionsblöcke einer Sicherheitsvorgabe genügt; Anpassen (230) des Betriebs eines Rechen-Funktionsblocks, falls die Prüfung des Betriebs des Rechen-Funktionsblocks negativ ausfällt.
Das Verfahren gemäß Anspruch 13, wobei das Anpassen des Betriebs ein Übertragen (232) der Rechen-Funktionsblöcke in eine virtuelle Ausführungsumgebung, Austauschen (234) zumindest einer Rechenressource des Fahrzeugs durch eine neue Rechenressource, und Ausführen (236) der virtuellen Ausführungsumgebung mit den Rechen-Funktionsblöcken auf der neuen Rechenressource umfasst.
Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß Anspruch 13, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.