DE102019204452A1 - Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten - Google Patents

Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten Download PDF

Info

Publication number
DE102019204452A1
DE102019204452A1 DE102019204452.2A DE102019204452A DE102019204452A1 DE 102019204452 A1 DE102019204452 A1 DE 102019204452A1 DE 102019204452 A DE102019204452 A DE 102019204452A DE 102019204452 A1 DE102019204452 A1 DE 102019204452A1
Authority
DE
Germany
Prior art keywords
network
request
control
following features
motor vehicle
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019204452.2A
Other languages
English (en)
Inventor
Simon Greiner
Johann Kobelski
Claudia Loderhose
Franziska Wiemer
Joachim Graf
Juergen Klarmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102019204452.2A priority Critical patent/DE102019204452A1/de
Priority to US16/823,747 priority patent/US11363034B2/en
Priority to CN202010229831.1A priority patent/CN111746551A/zh
Publication of DE102019204452A1 publication Critical patent/DE102019204452A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/035—Bringing the control units into a predefined state, e.g. giving priority to particular actuators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Human Computer Interaction (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Small-Scale Networks (AREA)

Abstract

Verfahren (10) zum Betreiben eines Steuergerätes (A-G, X) in einem Verbund (11) von Steuergeräten (A-G, X), gekennzeichnet durch folgende Merkmale:- eine Aufforderung, einen Modus des Verbundes (11) zu wechseln, wird empfangen (11),- die Aufforderung wird einer Prüfung unterzogen (12), die ein Prüfungsergebnis liefert,- hinsichtlich des Prüfungsergebnisses und eines dem Steuergerät (A-G, X) bekannten Status des Verbundes (11) wird eine Meldung an die übrigen Steuergeräte (A-G, X) verbreitet und jeweils eine Rückmeldung empfangen (13) und- abhängig von den Rückmeldungen wird die Aufforderung befolgt (14) oder verworfen (15).

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium.
  • Stand der Technik
  • In der IT-Sicherheit wird jedwedes System zur Erkennung von Angriffen, die gegen ein Computersystem oder Rechnernetz gerichtet sind, als Angriffserkennungssystem (intrusion detection system, IDS) bezeichnet. Bekannt sind insbesondere Netzwerk-basierte IDS (NIDS), die alle Pakete in einem zu überwachenden Netzwerksegment aufzeichnen, analysieren und anhand bekannter Angriffsmuster verdächtige Aktivitäten melden.
  • DE102017210647A1 offenbart ein Verfahren zur Erkennung eines Angriffes auf einen Feldbus, gekennzeichnet durch folgende Merkmale: Über den Feldbus wird eine erste Nachricht empfangen; die erste Nachricht wird einer Integritätsprüfung unterzogen; schlägt die Integritätsprüfung fehl, so wird die erste Nachricht verworfen und eine zweite Nachricht erzeugt; und die zweite Nachricht wird über den Feldbus an ein Angriffserkennungssystem gesendet.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Der erfindungsgemäße Ansatz fußt auf der Erkenntnis, dass ein modernes Fahrzeug aus vielen vernetzten Komponenten besteht, welche gemeinsam unterschiedliche Fahrzeugfunktionen erfüllen. Diese Fahrzeugfunktionen können einzeln oder auch überlagernd aktiv sein. Zur Steuerung werden Fahrzeugbetriebsmodi zur Klassifizierung von Betriebszuständen des Fahrzeugs definiert, etwa der Fahrer fährt, das Fahrzeug fährt autonom oder teilautonom mit z. B. Abstandsregeltempomat (adaptive cruise control, ACC) usw. Jede funktionsnotwendige Komponente innerhalb des Netzwerks muss hierzu ebenfalls den „richtigen“ (übergeordneten) Zustand einnehmen, um die Fahrzeugfunktion wie vorgesehen zu erfüllen.
  • Das vorgeschlagene Verfahren trägt ferner dem Umstand Rechnung, dass derartige Komponentenzustände zueinander funktional und sicherheitstechnisch kompatibel sein müssen. Im Rahmen bekannter Sicherheitskonzepte werden Sicherheitsmechanismen (limiter) in für die Betriebssicherheit (safety) relevanten Komponenten (z. B. Aktuatoren) eingesetzt, welche die Wirkung einer fehlerhaften Eingangsgröße begrenzen. Um Komfortfunktionen und sicherheitsrelevante Funktion innerhalb einer Fahrzeugarchitektur einsetzen zu können, werden solcherlei skalierbare Sicherheitsmechanismen eingesetzt, welche die Wirkung funktionsspezifisch begrenzen. Hierzu werden die sicherheitsrelevanten Komponenten auf Basis ihrer Eingangsinformationen in den entsprechenden notwendigen Betriebszustand (nachfolgend: Modus) versetzt. Die Fähigkeit der Komponenten zur Modus-Änderung ermöglicht einen Angriff über einzelne durch einen Angreifer korrumpierte Komponenten durch Manipulation der Netzwerksignale. Über die Netzwerksignale werden in diesem Fall Modus-Änderungen einzelner Komponenten in der Art bewirkt, dass die verwendeten Sicherheitsmechanismen deaktiviert werden. In Betracht kommen etwas das Frei- bzw. Abschalten skalierbarer Limiter von Aktuatoren oder das Umschalten von Sensorbetriebszuständen. Des Weiteren können mehrere Komponenten in eine inkompatible Kombination von Betriebszuständen versetzt werden.
  • Ein Vorzug der erfindungsgemäßen Lösung liegt in Anbetracht dieser Bedrohung darin, dass Einzelsteuergeräte der vorgeschlagenen Art in einem Verbund ihre Konfiguration nicht wechseln können, ohne dass andere Steuergeräte des Verbundes dem angeforderten Modus-Wechsel zustimmen.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass der Verbund über einen die Steuergeräte umfassenden Feldbus eines Kraftfahrzeuges kommuniziert und die Prüfung der Aufforderung, den Modus des Verbundes zu wechseln, die durch das Kraftfahrzeug einzuhaltenden Betriebsbedingungen berücksichtigt. Auf diesem Wege wird gleichsam ein den einzelnen Steuergeräten übergeordneter Modus des Fahrzeugs geschaffen, welcher nicht durch eine einzige Komponente verändert werden kann.
  • Gemäß einem weiteren Aspekt kann vorgesehen sein, dass der Verbund definierte Modi aufweist, welche bestimmten Funktionen des Kraftfahrzeuges entsprechen, wobei die besagte Prüfung anhand zulässiger Übergänge zwischen den Modi erfolgt. Vom Verbund umfasste Steuergeräte lassen somit nur Transitionen zu kompatiblen Systemkonfigurationen zu.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
    • 2 das Blockschaltbild einer Steuerkette.
    • 3 das Zustandsübergangsdiagramm eines Sensors.
    • 4 das Zustandsübergangsdiagramm einer Steuerung.
    • 5 das Zustandsübergangsdiagramm eines Aktuators.
    • 6 das Blockdiagramm eines die Steuerkette umfassenden Bussegmentes im Modus „Fahrerinformationssystem“.
    • 7 das Verhalten bei einem zulässigen Wechsel in den Modus „Stauassistent“.
    • 8 ein potenziell gefährliches Verhalten durch Angriff über Gateway oder Systemschnittstelle.
    • 9 das Verhalten bei einem erkannten Angriff über Gateway oder Systemschnittstelle auf ein Element und entsprechender Zurückweisung des Zustandswechsels.
    • 10 das Verhalten bei Erkennung einer korrumpierten Komponente anhand eines fehlenden oder ungültigen Zustandsvektors und entsprechender Zurückweisung des Zustandswechsels.
    • 11 das Blockdiagramm eines drei oder mehr Sensoren umfassenden Systems im Modus „Fahrerinformationssystem“.
    • 12 die Anwendung des byzantinischen Fehlermodells mit Mehrheitsentscheider auf Basis verteilter Zustandsvektoren.
  • Ausführungsformen der Erfindung
  • Eine Steuereinheit, welche die Gestalt eines eigenständigen Hardwareproduktes oder eines Softwareprozesses annehmen mag, wechselt ihren Modus erfindungsgemäß nicht nur auf Basis einer ankommenden Nachricht aus dem Fahrzeugnetzwerk, sondern plausibilisiert diese vorher anhand der Statusvektoren der anderen Steuergeräte im Funktionsverbund. Die Steuereinheit wechselt ihren Modus sodann nur bei einer gültigen Funktionskonfiguration.
  • Als Voraussetzung dazu wird bei jedem Modus-Wechsel die entsprechende Statusinformation ins Fahrzeugnetzwerk verteilt und dort synchronisiert. Damit wird die Statusinformation des Fahrmodus verteilt und nicht mehr von einer einzigen Quelle im Fahrzeugnetzwerk bezogen.
  • Ein Modus-Wechsel erfolgt, wie 1 illustriert, gemäß folgendem Ablauf: Ein Steuergerät informiert einen per Funktionskonfiguration wohldefinierten Steuergeräteverbund über die Anforderung zur Modus-Änderung (Prozess 11). Jedes Steuergerät im relevanten Steuergeräteverbund prüft die Vollständigkeit der Anforderung. Jedes Steuergerät im relevanten Steuergeräteverbund prüft die angeforderte Modi-Änderung ferner auf Integrität (die in der unten stehenden Tabelle dargestellte Konfiguration und die in den 3, 4, 5 dargestellten Transitionen) und auf Randbedingungen bzgl. Verträglichkeit mit der Funktionalität, also daraufhin, ob die Fahrzeugsituation einen sicheren Wechsel in den angeforderten Modus erlaubt (Prozess 12). Die Prüfung (Prozess 12) kann auch nacheinander oder in Teilen erfolgen, um hierdurch spezifische Fehlerreaktionen zu ermöglichen. Jedes Steuergerät im relevanten Steuergeräteverbund teilt das Ergebnis dieser Prüfung und seinen Status im Zustandsvektor den anderen Steuergeräten mit und empfängt entsprechende Rückmeldungen (Prozess 13). Jedes Steuergerät schließlich führt die Modus-Änderung nur dann durch (Prozess 14), wenn alle Steuergeräte zustimmen und eine gültige Systemkonfiguration vorliegt oder wenn - gemäß einem byzantinischen Fehlermodell - eine vorgegebene Mindestzahl der Rückmeldungen positiv ausfällt und der angeforderte Modus eine eingeschränkte Funktionalität mit einer Untermenge der am Verbund beteiligten Steuergeräte erlaubt. Letzteres könnte zum Beispiel bei Vorliegen multipler redundanter Sensoren der Fall sein.
  • Für den Fall, dass nicht alle Steuergeräte im Verbund in der Lage sind, die Vollständigkeit, Integrität und Authentizität der Anforderung einer Modus-Änderung zu überprüfen, bleibt gleichwohl eine Variante der Erfindung anwendbar, solange zumindest ein Steuergerät zu dieser Prüfung in der Lage ist. In diesem Szenario nehmen lediglich die hierzu fähigen Steuergeräte die jeweilige Prüfung vor und teilen deren Ergebnis den übrigen Steuergeräten mit.
  • 2 zeigt exemplarisch einen Verbund (11) aus drei Komponenten (C, D, E) mit potenziell gefährlicher Umgebungsinteraktion. Die in 2 dargestellte Systembeschreibung wird in den folgenden Beispielen verwendet. Ein Gefahrenpotenzial geht hierbei direkt vom Aktuator (E) und indirekt von Sensor (C) und Controller (B) aus. Hierbei sei angenommen, dass der Aktuator (E) die Wirkung auf die Umgebung zustandsabhängig auf generell sichere Grenzwerte limitieren und das System die notwendigen Randbedingungen wie Geschwindigkeit, Zustand eines etwaigen Antiblockiersystems (ABS), Systemfehler und Umwelteinflüsse für einen Konfigurationswechsel in die Entscheidung einbeziehen kann.
  • Die Steuergeräte (C, D, E) mögen hierbei als endliche Automaten betrachtet werden, deren Zustände (CO-C3, DO-D3, EO-E2) und zulässige Zustandsübergänge in den 3, 4 bzw. 5 veranschaulicht sind. Die Bedeutung der aus der Kombination dieser Zustände resultierenden Modi des Verbundes (11) ist folgender Tabelle zu entnehmen:
    Zustand des Sensors Zustands des Controllers Zustand des Aktuators Bedeutung und Risikoeinstufung
    C0 D0 E0 Gültiger und sicherer Ausgangszustand
    C0 D0 E1 Gestörte Komfortfunktion
    C0 D0 E2 Sicherheitskritisch
    C0 D1 E0 Gestörte Komfortfunktion
    C0 D1 E1 Gestörte Komfortfunktion
    C0 D1 E2 Sicherheitskritisch
    C0 D2 E0 Gestörte Komfortfunktion
    C0 D2 E1 Gestörte Komfortfunktion
    C0 D2 D2 Sicherheitskritisch
    C0 D3 E0 Gestörte Komfortfunktion
    C0 D3 E1 Gestörte Komfortfunktion
    C0 D3 E2 Sicherheitskritisch
    C1 D0 E0 Gestörte Komfortfunktion
    C1 D0 E1 Gestörte Komfortfunktion
    C1 D0 E2 Sicherheitskritisch
    C1 D1 E0 Gültige Funktion 1 (Fahrerinformation), Teilkonfiguration
    C1 D1 E1 Gestörte Komfortfunktion
    C1 D1 E2 Sicherheitskritisch
    C1 D2 E0 Gestörte Komfortfunktion
    C1 D2 E1 Gestörte Komfortfunktion
    C1 D2 D2 Sicherheitskritisch
    C1 D3 E0 Gestörte Komfortfunktion
    C1 D3 E1 Gestörte Komfortfunktion
    C1 D3 E2 Sicherheitskritisch
    C2 D0 E0 Gestörte Komfortfunktion
    C2 D0 E1 Gestörte Komfortfunktion
    C2 D0 E2 Sicherheitskritisch
    C2 D1 E0 Gestörte Komfortfunktion
    C2 D1 E1 Gestörte Komfortfunktion
    C2 D1 E2 Sicherheitskritisch
    C2 D2 E0 Gestörte Komfortfunktion
    C2 D2 E1 Gültige Funktion 2 (Abstan dsregeltem pomat)
    C2 D2 D2 Sicherheitskritisch
    C2 D3 E0 Gestörte Komfortfunktion
    C2 D3 E1 Gestörte Komfortfunktion
    C2 D3 E2 Sicherheitskritisch
    C3 D0 E0 Gestörte Komfortfunktion
    C3 D0 E1 Gestörte Komfortfunktion
    C3 D0 E2 Sicherheitskritisch
    C3 D1 E0 Gestörte Komfortfunktion
    C3 D1 E1 Gestörte Komfortfunktion
    C3 D1 E2 Sicherheitskritisch
    C3 D2 E0 Gestörte Komfortfunktion
    C3 D2 E1 Gestörte Komfortfunktion
    C3 D2 D2 Sicherheitskritisch
    C3 D3 E0 Gestörte Komfortfunktion
    C3 D3 E1 Gestörte Komfortfunktion
    C3 D3 E2 Gültige Funktion 3 (Stauassistent)
  • 6 beleuchtet beispielhaft ein diesen Verbund umfassendes Bussegment, wobei sich der Verbund zunächst im Modus „Fahrerinformationssystem“ befindet. Das Verhalten des Verbundes bei Anforderung des Modus „Stauassistent“ (travel jam assistant, TJA) sei nunmehr anhand der 7 erläutert. Jedes Element (C, D, E) des Verbundes sendet in diesem Fall den angeforderten eigenen Modus und den von den übrigen Teilnehmern empfangenen Modus in Gestalt einer im Folgenden als Statusvektor bezeichneten Struktur an jeden anderen Teilnehmer. Im vorliegenden Beispiel herrscht unter den besagten Teilnehmern Einigkeit über den Statusvektor (C3, D3, E2). Eine durch jedes Element (C, D, E) vorgenommene Auswertung des Statusvektors im Rahmen einer Missbrauchsprüfung ergibt die Gültigkeit des Statusvektors sowie die Einhaltung der Randbedingungen. Jedes Element (C, D, E) erklärt den angeforderten Zustandsübergang somit für ordnungsgemäß, teilt die entsprechende Entscheidung mit den anderen Elementen und nimmt die Konfigurationsänderung vor.
  • 8 stellt diesem Verhalten ohne Angriff - wiederum ausgehend von der Ausgangskonfiguration gemäß 6 - ein potenziell gefährliches Verhalten durch einen Angriff über ein Gateway (A) oder eine Systemschnittstelle gegenüber, bei welchem der Angreifer durch Versetzen des Aktuators (E) in den Modus E2 die Stauassistent-Schnittstelle erfolgreich im ungültigen Modus C1, D1, E2 konfiguriert.
  • Ein derartiger Angriff lässt sich erfindungsgemäß abwehren, wie 9 verdeutlicht: Hier herrscht unter sämtlichen Teilnehmern Einigkeit über den Statusvektor (C1, D1, E2). Eine durch jedes Element (C, D, E) vorgenommene Auswertung des Statusvektors ergibt dessen Ungültigkeit sowie die Einhaltung der Randbedingungen. Jedes Element (C, D, E) erklärt den angeforderten Zustandsübergang somit für nicht ordnungsgemäß, teilt die entsprechende Entscheidung und den lokal bekannten Statusvektor mit den anderen Elementen und weist den angeforderten Zustandswechsel zurück. Im Falle des Aktuators (E) könnte eine derartige Prüfung des Zustandes der übrigen TJA-Komponenten beispielsweise gemäß des folgenden Pseudocodes erfolgen: If ( … AND ( C ! = ' ' C3' '  OR D ! = ' ' D3 ' ' ) )  then REJECT  ' ' E2 ' '
    Figure DE102019204452A1_0001
  • Eine Auswertung von Teilkonfigurationen ergäbe, dass (C1, D1) einer gültigen Teilkonfiguration des Fahrerinformationssystems entspräche, während die Kombinationen C1/E2 sowie D1/E2 als ungültig erkannt würden.
  • Ebenfalls anhand der 9 lässt sich das entsprechende Verhalten bei einem Angriff über Gateway (A) oder Systemschnittstelle auf eine vollständige Konfiguration erläutern, bei welchem der Angreifer versucht, den Verbund in den Modus C3, D3, E2 zu versetzen. Hier herrscht unter sämtlichen Teilnehmern Einigkeit über den Statusvektor (C3, D3, E2). Jeder der Teilnehmer C, D, E prüft die Einhaltung der Randbedingungen, die Zulässigkeit des Statusvektors (Tabelle) und die Zulässigkeit seines Transitionsziels (3, 4, 5). Die Teilnehmer sind sich einig über die Zulässigkeit des Statusvektors. Die Transitionsziele werden von den Teilnehmern C und D als unzulässig erkannt, da gemäß 3, 4 keine Übergänge von den Zuständen C1, D1 in die Zustände C2, D2 erlaubt sind. C, D informieren den Verbund über die Unzulässigkeit der geforderten Modusänderung. Die geforderte Modusänderung erfolgt daraufhin nicht und das Fahrzeug bleibt im sicheren Ausgangszustand.
  • Aufgrund der Erfindung sind nur die Angriffe erfolgreich, die darauf abzielen, den Verbund in einen Zustand zu versetzen, der sowohl zu den Randbedingungen passt als auch den Transitionsregeln der einzelnen Teilnehmern entspricht und von allen Teilnehmern als zulässig erkannt wird. Alle Angriffe dieser Art resultieren in einen sicheren Zustand und stellen daher keine Gefahr für Leib und Leben dar.
  • 10 illustriert das Verhalten des Systems in dem Fall, dass ein entsprechender Angriff vom Sensor (C) ausgeht. Dessen Statusvektor fehlt in diesem Fall oder ist falsch. Sowohl Controller (B) als auch Aktuator (E) erkennen diesen Fehlerzustand anhand der Bedingung IF ( C ! = ' ' C3' '  OR D ! = ' ' D3 ' '  OR E!= ' ' E2 ' ' )
    Figure DE102019204452A1_0002
  • Es sei bemerkt, dass auch ein geeignetes asymmetrisches Kryptosystem eingesetzt werden sollte, um den Sensor (C, F, G) anhand seines öffentlichen Schlüssels zu authentifizieren.
  • 11 zeigt das Blockdiagramm eines drei oder mehr Sensoren (C, F, G) umfassenden Systems im Modus „Fahrerinformationssystem“. Wie 12 veranschaulicht, ist angesichts der Anzahl vom Verbund umfasster Steuergeräte (A-G, X) ausgehend von dieser Konfiguration das byzantinische Fehlermodell mit Mehrheitsentscheider auf Basis des verteilten Zustandsvektors - im vorliegenden Falle (F1, G1, C3, D3, E2) - anwendbar.
  • Als zweites Ausführungsbeispiel sei nunmehr ein Staupilot (travel jam pilot, TJP) angeführt. Zur Vereinfachung sei dabei angenommen, dass das System lediglich die Modi „manuelle Steuerung“ und „automatische Steuerung“ unterstützt. Im ersteren Falle verbleibt die volle Kontrolle über das Fahrzeug beim Fahrer und entsprechende Limiter erlauben die volle Lenkfreiheit sowie die Erhöhung der Geschwindigkeit bis zur baulich bedingten Höchstgeschwindigkeit. Im letzteren Falle reduzieren die Limiter die Freiheiten auf kleinere Lenkwinkel und eine Geschwindigkeit von 65 km/h. Der Limiter ist vorzugsweise dynamisch und verändert sich je nach ASIL-Einstufung des Modus.
  • Ferner sei angenommen, dass ein Angreifer einen Unfall erzeugen möchte und ein Steuergerät, das nicht die Lenkung steuert, bereits unter seine Kontrolle gebracht hat, mit dem er valide Nachrichten an das Steuergerät der Lenkung schicken kann. Beispielsweise wolle der Angreifer den Limiter im automatischen Fahrmodus dazu veranlassen, maximale Freiheiten bei der Steuerung zu erlauben, da der üblicherweise in diesem Modul begrenzte Lenkwinkel nicht ausreichend ist. Der Angreifer könne jedoch den Limiter nur durch Signale konfigurieren und nicht etwa direkt dessen Speicher beschreiben.
  • Ausgehend von diesen Annahmen bestünde eine Angriffsmöglichkeit darin, ein Signal zum Modus-Wechsel an die Lenkung zu schicken, sodass sich der Limiter an einen vermeintlich manuellen Fahrmodus anpasst, der volle Lenkfreiheit erlaubt. Da der Modus durch die erfindungsgemäß ausgetauschten Statusvektoren jedoch allen Steuergeräten bekannt ist, kann er nicht ohne Weiteres geändert werden; vielmehr müssten mehrere Steuergeräte - basierend auf deren Sensorauswertung - einem durch den Angreifer angeforderten Modus-Wechsel gleichsam „zustimmen“. Die Aufforderung des Angreifers zum Modus-Wechsel würde daher vom erfindungsgemäßen System verworfen (Prozess 15 - 1).
  • Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem der Steuergeräte (A-G, X) implementiert sein.
  • 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
    • DE 102017210647 A1 [0003]

Claims (11)

  1. Verfahren (10) zum Betreiben eines Steuergerätes (A-G, X) in einem Verbund (11) von Steuergeräten (A-G, X), gekennzeichnet durch folgende Merkmale: - eine Aufforderung, einen Modus des Verbundes (11) zu wechseln, wird empfangen (11), - die Aufforderung wird einer Prüfung unterzogen (12), die ein Prüfungsergebnis liefert, - hinsichtlich des Prüfungsergebnisses und eines dem Steuergerät (A-G, X) bekannten Status des Verbundes (11) wird eine Meldung an die übrigen Steuergeräte (A-G, X) verbreitet und jeweils eine Rückmeldung empfangen (13) und - abhängig von den Rückmeldungen wird die Aufforderung befolgt (14) oder verworfen (15).
  2. Verfahren (10) nach Anspruch 1, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Aufforderung wird befolgt (14), wenn die Rückmeldungen sämtlich positiv ausfallen und das Steuergerät (A-G, X) den angeforderten Modus als gültig erachtet oder - die Aufforderung wird befolgt, wenn eine vorgegebene Mindestzahl der Rückmeldungen positiv ausfällt und der angeforderte Modus eine eingeschränkte Funktionalität erlaubt.
  3. Verfahren (10) nach Anspruch 1 oder 2, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Prüfung betrifft die Vollständigkeit der Aufforderung, - die Prüfung betrifft die Integrität der Aufforderung oder - die Prüfung betrifft die Authentizität der Aufforderung.
  4. Verfahren (10) nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgende Merkmale: - der Verbund (11) kommuniziert über einen die Steuergeräte (A-G, X) umfassenden Feldbus (12) eines Kraftfahrzeuges und - die Prüfung berücksichtigt durch das Kraftfahrzeug einzuhaltende Betriebsbedingungen.
  5. Verfahren (10) nach Anspruch 4, gekennzeichnet durch mindestens eines der folgenden Merkmale: - das Steuergerät (A-G, X) ist ein Gateway (A) des Feldbusses (12), - das Steuergerät (A-G, X) steuert einen Sensor (C, F, G) des Kraftfahrzeuges, - das Steuergerät (A-G, X) ist ein Controller (B, D) des Feldbusses (12) oder - das Steuergerät (A-G, X) steuert einen Aktuator (E) des Kraftfahrzeuges.
  6. Verfahren (10) nach Anspruch 4, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die logische Komponente (A-G, X) ist ein Gateway (A) des Feldbusses (12), - die logische Komponente (A-G, X) steuert einen Sensor (C, F, G) des Kraftfahrzeuges, - die logische Komponente (A-G, X) steuert eine Funktionalität über Kontroll- und Datenflüsse (B, D) oder - die logische Komponente (A-G, X) steuert einen Aktuator (E) des Kraftfahrzeuges.
  7. Verfahren (10) nach Anspruch 4 oder 5, gekennzeichnet durch folgende Merkmale: - der Verbund (11) besitzt mehrere Modi, welche den angeforderten Modus umfassen und Funktionen des Kraftfahrzeuges entsprechen, - die Prüfung erfolgt anhand vorgegebener Übergänge zwischen den Modi.
  8. Verfahren (10) nach Anspruch 7, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Funktionen umfassen einen Abstandsregeltempomat, - die Funktionen umfassen ein Fahrerinformationssystem, - die Funktionen umfassen einen Stauassistenten oder - die Funktionen umfassen einen Staupiloten.
  9. Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
  10. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 9 gespeichert ist.
  11. Vorrichtung (A, B, C, D, E, X), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 8 auszuführen.
DE102019204452.2A 2019-03-29 2019-03-29 Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten Pending DE102019204452A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102019204452.2A DE102019204452A1 (de) 2019-03-29 2019-03-29 Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten
US16/823,747 US11363034B2 (en) 2019-03-29 2020-03-19 Method and device for operating a control unit in a network of control units
CN202010229831.1A CN111746551A (zh) 2019-03-29 2020-03-27 用于运行控制器的组合体中的控制器的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019204452.2A DE102019204452A1 (de) 2019-03-29 2019-03-29 Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten

Publications (1)

Publication Number Publication Date
DE102019204452A1 true DE102019204452A1 (de) 2020-10-01

Family

ID=72605145

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019204452.2A Pending DE102019204452A1 (de) 2019-03-29 2019-03-29 Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten

Country Status (3)

Country Link
US (1) US11363034B2 (de)
CN (1) CN111746551A (de)
DE (1) DE102019204452A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022120458A1 (de) 2022-08-12 2024-02-15 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Verhindern eines Ausgebens einer Ausgabenachricht eines manipulierten Steuergeräts an einen Nutzer eines Fahrzeugs durch ein Kopfeinheit-Steuergerät des Fahrzeugs, computerlesbares Medium, System, und Fahrzeug

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9503470B2 (en) * 2002-12-24 2016-11-22 Fred Herz Patents, LLC Distributed agent based model for security monitoring and response
DE102011084633A1 (de) * 2011-10-17 2013-04-18 Robert Bosch Gmbh Vorrichtung und Verfahren zum Erkennen von Fehlern in Streckendaten
DE102011085167A1 (de) * 2011-10-25 2013-04-25 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betrieb eines Stauassistenzsystems eines Kraftfahrzeugs
US9160620B2 (en) * 2011-11-30 2015-10-13 GM Global Technology Operations LLC Integrated fault diagnosis and prognosis for in-vehicle communications
ES2805290T3 (es) * 2012-03-29 2021-02-11 Arilou Information Security Tech Ltd Dispositivo para proteger un sistema electrónico de un vehículo
EP2973123A4 (de) * 2013-03-14 2016-11-02 Autoconnect Holdings Llc Fahrzeuginternes netzwerkmodul
EP3348036B1 (de) * 2015-09-10 2022-05-11 Robert Bosch GmbH Benachrichtigung über unautorisiertes zugriffsereignis für elektronische steuerungseinheiten eines fahrzeugs
JP6696468B2 (ja) * 2016-08-30 2020-05-20 株式会社オートネットワーク技術研究所 車載更新装置及び車載更新システム
JP6539363B2 (ja) * 2017-04-07 2019-07-03 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 不正通信検知方法、不正通信検知システム及びプログラム
DE102017209556A1 (de) * 2017-06-07 2018-12-13 Robert Bosch Gmbh Verfahren zum Schutz eines Fahrzeugnetzwerks gegen manipulierte Datenübertragung
DE102017210647A1 (de) 2017-06-23 2018-12-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Erkennung eines Angriffes auf einen Feldbus
DE102017217195A1 (de) * 2017-09-27 2019-03-28 Continental Teves Ag & Co. Ohg Verfahren zum Erfassen eines Angriffs auf ein Steuergerät eines Fahrzeugs
US11163549B2 (en) * 2018-08-10 2021-11-02 Denso Corporation Vehicle information communication system

Also Published As

Publication number Publication date
US20200314114A1 (en) 2020-10-01
US11363034B2 (en) 2022-06-14
CN111746551A (zh) 2020-10-09

Similar Documents

Publication Publication Date Title
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
EP3001884B1 (de) Verfahren, vorrichtung und system zur überwachung einer sicherheits-netzübergangseinheit
EP2981926B1 (de) Datenspeichervorrichtung zum geschützten datenaustausch zwischen verschiedenen sicherheitszonen
EP3295645B1 (de) Verfahren und anordnung zur rückwirkungsfreien übertragung von daten zwischen netzwerken
DE102018209407A1 (de) Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk
DE10335904B4 (de) Verfahren und Vorrichtung zur bidirektionalen Eindraht-Datenübertragung
DE102017203898A1 (de) Gateway-Vorrichtung, Kommunikationsverfahren und Kommunikationssystem für ein Fahrzeug, insbesondere ein Schienenfahrzeug
EP2491492B1 (de) Automatisierungssystem und verfahren zum betrieb eines automatisierungssystems
EP3642717A1 (de) Vorrichtung und verfahren zum ansteuern eines fahrzeugmoduls
DE102007029116A1 (de) Verfahren zum Betreiben eines Mikrocontrollers und einer Ausführungseinheit sowie ein Mikrocontroller und eine Ausführungseinheit
DE102017220845A1 (de) Verlagerung einer Funktion oder Anwendung von einem Steuergerät
EP3028409B1 (de) Filtern eines datenpaketes durch eine netzwerkfiltereinrichtung
DE102019204452A1 (de) Verfahren und Vorrichtung zum Betreiben eines Steuergerätes in einem Verbund von Steuergeräten
EP3983897B1 (de) Verfahren zum sicherstellen und aufrechterhalten der funktion eines sicherheitskritischen gesamtsystems
DE102018221952A1 (de) Verfahren und Vorrichtung zum Betreiben eines Kommunikationsnetzwerks
EP3665603B1 (de) Verfahren und vorrichtung zum unmittelbaren und rückwirkungsfreien übertragen von log-nachrichten
DE102021208459B4 (de) Verfahren zur authentischen Datenübertragung zwischen Steuergeräten eines Fahrzeugs, Anordnung mit Steuergeräten, Computerprogramm und Fahrzeug
DE102018220324A1 (de) Verfahren zur Überwachung eines Datenübertragungssystems, Datenübertragungssystem und Kraftfahrzeug
DE102017220131A1 (de) Erkennung von Anomalien in einem Netzwerkdatenstrom
EP2449438B1 (de) Verfahren und system zur ansteuerung von mindestens einem aktuator
DE10328059A1 (de) Verfahren und Vorrichtung zur Überwachung eines verteilten Systems
EP0059789A2 (de) Einrichtung zur Funktionsprüfung eines Mehrrechnersystems
WO2021144271A1 (de) Verfahren und vorrichtung zum rekonfigurieren eines automatisiert fahrenden fahrzeugs in einem fehlerfall
DE102019209009A1 (de) Filter, Anordnung und Betriebsverfahren für eine Anordnung
DE102022202337A1 (de) Verfahren zum Einbinden eines Anwendungsprogramms