-
Die vorliegende Erfindung betrifft ein System und ein Verfahren, welches die Gewährleistung der Sicherheit in einem E/E-System im Fahrzeug optimiert.
-
Das E/E-System (elektrisch-elektronisches System) im Fahrzeug umfasst insbesondere Steuerungs-, Regelungs-, Überwachungs- und Diagnosefunktionen im Fahrzeug. Es umfasst die Kraftfahrzeugelektrik und -elektronik, die Vernetzung, die Schnittstellen und die optimale Strom-, Signal- und Datenverteilung zwischen der Vielzahl an E/E-Komponenten (z.B. Steuergeräte, Sensoren, Netzwerk, Diagnosesystem, Infotainmentsystem) sowie zu externen Komponenten (Integration mobiler Endgeräte, Car-to-Car-Kommunikation, Car-to-Infrastruktur-Kommunikation. Durch die Komplexität, die sich durch der Vielzahl an Komponenten des E/E-Systems mit Bezug auf die Datenerfassung, -speicherung und - verarbeitung und den Datenfluss zwischen den Komponenten ergibt, kommt es zunehmend zu Dateninkonsistenzen führt. Durch die Schnittstellen zu externen Komponenten besteht die Gefahr von Angriffen bzw. Attacken von außen auf das E/E-System. Dadurch kann die Datensicherheit in E/E-Systemen beeinträchtigt werden. Gleichzeitig ist es im E/E-System im Fahrzeug unabdingbar, Lösungen zur Gewährleistung der Datensicherheit ressourcenoptimal bereitzustellen.
-
Die Aufgabe der Erfindung besteht darin, eine Lösung bereitzustellen, die die Gewährleistung der Sicherheit im E/E-System im Fahrzeug optimiert.
-
Diese Aufgabe wird erfindungsgemäß durch die Merkmale der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
-
Die vorstehend genannte Aufgabe wird durch ein System zur Optimierung der Gewährleistung der Sicherheit in einem E/E, elektrisch-elektronischem, System im Fahrzeug gelöst, umfassend:
- eine Recheneinheit, die eingerichtet ist:
- - zumindest eine Sicherheitsrichtlinie mit Bezug auf den Datenaustausch zwischen einer Mehrzahl an E/E-Komponenten umzusetzen, wobei jede E/E-Komponente Datenquelle und/oder Datensenke sein kann;
- - aus einer Vielzahl an möglichen Datenflüssen zwischen zumindest zwei E/E-Komponenten einen Datenfluss zu identifizieren, die die Sicherheitsrichtlinie verletzt; und
- - für den identifizierten Datenfluss der die Sicherheitsrichtlinie verletzt eine ressourcenoptimierte Lösung bereitzustellen.
-
Der Begriff Fahrzeug umfasst im Rahmen des Dokuments mobile Verkehrsmittel, die dem Transport von Personen (Personenverkehr), Gütern (Güterverkehr) oder Werkzeugen (Maschinen oder Hilfsmittel) dienen. Insbesondere umfasst der Begriff Fahrzeug Kraftfahrzeuge sowie Kraftfahrzeuge, die zumindest teilweise elektrisch angetrieben sein können (Elektroauto, Hybridfahrzeuge).
-
Das Fahrzeug kann von einem Fahrzeugführer gesteuert werden. Darüber hinaus oder alternativ dazu kann das Fahrzeug ein zumindest teilweise automatisiert fahrendes Fahrzeug sein. Unter dem Begriff „automatisiertes fahrendes Fahrzeug“ bzw. „automatisiertes Fahren“ kann im Rahmen des Dokuments ein Fahren mit automatisierter Längs- oder Querführung oder ein autonomes Fahren mit automatisierter Längs- und Querführung verstanden werden. Bei dem automatisierten Fahren kann es sich beispielsweise um ein zeitlich längeres Fahren auf der Autobahn oder um ein zeitlich begrenztes Fahren im Rahmen des Einparkens oder Rangierens handeln. Der Begriff „automatisiertes Fahren“ umfasst ein automatisiertes Fahren mit einem beliebigen Automatisierungsgrad. Beispielhafte Automatisierungsgrade sind ein assistiertes, teilautomatisiertes, hochautomatisiertes oder vollautomatisiertes Fahren. Diese Automatisierungsgrade wurden von der Bundesanstalt für Straßenwesen (BASt) definiert (siehe BASt-Publikation „Forschung kompakt“, Ausgabe 11/2012). Beim assistierten Fahren führt der Fahrer dauerhaft die Längs- oder Querführung aus, während das System die jeweils andere Funktion in gewissen Grenzen übernimmt. Beim teilautomatisierten Fahren übernimmt das System die Längs- und Querführung für einen gewissen Zeitraum und/oder in spezifischen Situationen, wobei der Fahrer das System wie beim assistierten Fahren dauerhaft überwachen muss. Beim hochautomatisierten Fahren übernimmt das System die Längs- und Querführung für einen gewissen Zeitraum, ohne dass der Fahrer das System dauerhaft überwachen muss; der Fahrer muss aber in einer gewissen Zeit in der Lage sein, die Fahrzeugführung zu übernehmen. Beim vollautomatisierten Fahren kann das System für einen spezifischen Anwendungsfall das Fahren in allen Situationen automatisch bewältigen; für diesen Anwendungsfall ist kein Fahrer mehr erforderlich. Die vorstehend genannten vier Automatisierungsgrade entsprechen den SAE-Level 1 bis 4 der Norm SAE J3016 (SAE - Society of Automotive Engineering). Ferner ist in der SAE J3016 noch der SAE-Level 5 als höchster Automatisierungsgrad vorgesehen, der in der Definition der BASt nicht enthalten ist. Der SAE-Level 5 entspricht einem fahrerlosen Fahren, bei dem das System während der ganzen Fahrt alle Situationen wie ein menschlicher Fahrer automatisch bewältigen kann.
-
Der Begriff Datensicherheit umfasst im Rahmen dieses Dokuments technische Maßnahmen und Aspekte, die dem Schutz von Daten mit Bezug auf die Vertraulichkeit der Daten, der Datenintegrität, und der Verfügbarkeit und Authentizität der Daten.
-
Der Begriff E/E (elektrisch-elektronisches) System umfasst im Rahmen dieses Dokuments die Fahrzeugelektrik, die Fahrzeugelektronik, die Vernetzung des Fahrzeugs, die Schnittstellen zum bzw. vom Fahrzeug, sowie deren Strom-, Signal- und Datenübertragung bzw. -verarbeitung über typische Kommunikationsverbindungen wie z.B. Ethernet, CAN, FR (FlexRay), etc. Somit umfasst der Begriff E/E-Komponente im Rahmen dieses Dokuments sämtliche Komponenten des E/E-Systems wie z.B. Sensoren, Aktoren, Steuergeräte, Gateways, Schnittstellen wie z.B. USB (Universal Serial Bus) - Schnittstellen, OBD (On-Board-Diagnose)-Schnittstellen, TCU (Telematics Control Unit bzw. Telematiksteuergerät), Head-Unit, BLE (Bluetooth Low Energy), etc.
-
Eine Sicherheitsrichtlinie bzw. Security Policy umfasst im Rahmen dieses Dokuments eine Sicherheitsrichtlinie mit Bezug auf die Vertraulichkeit und/oder Integrität und/oder Verfügbarkeit und/oder Authentizität von Daten, die mit Bezug auf das E/E-System zwischen zwei oder mehreren E/E-Komponenten bzw. über zumindest eine E/E-Komponente ausgetauscht werden.
-
Der Begriff Datenfluss umfasst im Rahmen dieses Dokuments die Übertragung von Daten von einer E/E-Komponente an eine andere E/E-Komponente. Der Datenfluss kann eine Übertragung über eine E/E-Komponente umfassen (z.B. Datenübertragung zwischen Luftschnittstelle bzw. weitere typische Kommunikationsverbindungen wie Ethernet, CAN, FR, etc.) umfassen.
-
Das System umfasst eine Recheneinheit, die eingerichtet ist, zumindest eine Sicherheitsrichtlinie mit Bezug auf den Datenaustausch zwischen einer Mehrzahl an E/E-Komponenten zu empfangen. Jede E/E-Komponente kann eine Datenquelle und/oder eine Datensenke und/oder eine Kommunikationsverbindung zwischen einer Datenquelle und/oder einer Datensenke sein.
-
Die Recheneinheit ist insbesondere eingerichtet, aus einer Vielzahl an möglichen Datenflüssen, die zwischen der Vielzahl an E/E-Komponenten stattfinden können, einen Datenfluss zu identifizieren, die eine bzw. die zumindest eine Sicherheitsrichtlinie verletzt. Dies kann beispielsweise zur Laufzeit erfolgen, indem Verletzungen von Sicherheitsrichtlinien in den entsprechenden E/E-Komponenten identifiziert wird. Beispielsweise kann eine Datensenke (z.B. Steuergerät) Daten während der Laufzeit zumindest eine Sicherheitsrichtlinie, die an den von einer Datenquelle empfangenen Daten hängen bzw. mit den von einer Datenquelle empfangenen Daten übermittelt wurden, prüfen, und mit potentiellen Sicherheitsrichtlinien, die für die jeweilige Datensenke gelten, vergleichen.
-
Die Recheneinheit ist zudem eingerichtet, für den identifizierten Datenfluss, der die Sicherheitsrichtlinie verletzt, eine ressourcenoptimierte Lösung bereitzustellen.
-
Beispielsweise kann ein CSP (Constraint-Satisfaction-Problem bzw. Bedingungserfüllungsproblem) definiert werden, der die Erfüllung der Sicherheitsrichtlinie bei gleichzeitiger Ressourcenoptimierung für den identifizierten Datenfluss fordert. Ein CSP besteht aus einer Menge von Variablen, den Wertebereichen der Variablen und den Bedingungen, die Verknüpfungen zwischen den Variablen herstellen und dadurch feststellen, welche Kombinationen von Werten der Variablen zulässig sind. Sie ermöglichen es somit, Probleme bzw. Aufgabenstellungen aus der Künstlichen Intelligenz bzw. aus dem Operations Research zu formulieren. Durch die Verwendung von CSP ist es möglich, eine Belegung von Variablen zu identifizieren, der alle aufgestellten Bedingungen bzw. Constraints erfüllt. Gerade im E/E-System ist es mit Bezug auf die Minimierung der Datenlast auf den Kommunikationsverbindungen (Ethernet, Controller Area Network (CAN), FlexRay (FR), etc.) wesentlich, den richtigen Ort für die Bereitstellung der Lösung zur Gewährleistung der Einhaltung der Sicherheitsrichtlinie mit Bezug auf den identifizierten Datenfluss zu definieren. Auch die Energieoptimierung im E/E-System im Fahrzeug kann im CSP formuliert werden.
-
Vorteilhafterweise kann somit für sämtliche Datenflüsse, die im E/E-System stattfinden können, eine optimierte Lösung zur Sicherstellung der Sicherheitsrichtlinie, die für den Datenaustausch im E/E-System definiert wurde, bereitzustellen.
-
Vorzugsweise umfasst die zumindest eine Sicherheitsrichtlinie
- - eine Sicherheitsanforderung zwischen einer Datenquelle und einer Datensenke; und/oder
- - eine Restriktion zwischen einer Datenquelle und einer Datensenke.
-
Die zumindest eine Sicherheitsrichtlinie kann zumindest eine Sicherheitsanforderungen zwischen einer Datenquelle und einer Datensenke umfassen. Darüber hinaus oder alternativ dazu kann die Sicherheitsrichtlinien zumindest eine Restriktion zwischen einer Datenquelle und einer Datensenke im E/E-System umfassen. Im Steuergerät eines Fahrzeuges können die Datenquellen Mechanismen umfassen, die an die von der jeweiligen Datenquelle übertragenen Daten eine Sicherheitsrichtlinie anhängen können, die dann in den entsprechenden Datensenken (z.B. Steuergeräten) verarbeitet werden können.
-
Vorteilhafter Weise kann somit festgestellt werden, ob die Sicherheitsanforderungen und/oder die Restriktionen, die für den Datenfluss zwischen einer Datenquelle und einer Datensenke definiert sind, eingehalten werden.
-
Vorzugsweise umfasst das Identifizieren des Datenflusses, der die Sicherheitsrichtlinie verletzt, das Generieren eines Konflikts.
-
Der Begriff Konflikt umfasst im Rahmen dieses Dokuments die Erkennung einer Verletzung zumindest einer Sicherheitsrichtlinie. Der Konflikt kann Informationen darüber umfassen, auf welchem Pfad die Verletzung stattgefunden hat und welche Bedingung bzw. Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurden. Der Konflikt kann beispielsweise zur Laufzeit in den E/E-Komponenten identifiziert werden. Dies kann erfolgen, indem in den entsprechenden E/E-Komponenten, beispielsweise in einer Datensenke (z.B. Steuergerät), während der Laufzeit zumindest eine Sicherheitsrichtlinie, die an den von einer Datenquelle empfangenen Daten hängen bzw. mit den von einer Datenquelle empfangenen Daten übermittelt wurden, prüfen und mit potentiellen Sicherheitsrichtlinien, die für die jeweilige Datensenke gelten, vergleicht). Darüber hinaus oder alternativ dazu kann der Konflikt beispielsweise zur Designzeit durch den Einsatz von Model Checking identifiziert werden. Model Checking ist ein Verfahren zur vollautomatischen Verifikation einer Systembeschreibung gegen eine Spezifikation. Die Systembeschreibung kann das E/E-System umfassen. Die Spezifikation kann die zumindest eine Sicherheitsrichtlinie umfassen. Der Konflikt kann Informationen darüber umfassen, auf welchem Pfad die Verletzung stattgefunden hat und welche Bedingung bzw. Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurden.
-
Vorzugsweise beschreibt jeder Konflikt eine konkrete Verletzung der zumindest einen Sicherheitsrichtlinie.
-
Jeder Konflikt, der durch die Recheneinheit generiert wurde, kann eine konkrete Verletzung der zumindest einen Sicherheitsrichtlinien beschreiben. Die Beschreibung der konkreten Verletzung der zumindest einen Sicherheitsrichtlinien kann Informationen darüber umfassen, welche Sicherheitsrichtlinie (n) auf welchem Pfad die Verletzung stattgefunden hat und welche Bedingung bzw. Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurden.
-
Vorteilhafterweise kann somit exakt festgestellt werden, auf welchem Pfad im E/E-System die Verletzung der zumindest einen Sicherheitsrichtlinie stattgefunden hat und welche Bedingung bzw. welche Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurde(n), was zur Identifikation des Ortes der ressourcenoptimierten Bereitstellung der Lösung beiträgt.
-
Gemäß einem zweiten Aspekt wird die zugrundeliegende Aufgabe durch ein Verfahren zur Optimierung der Gewährleistung der Sicherheit in einem E/E, elektrisch-elektronischem, System im Fahrzeug gelöst, umfassend:
- Umsetzen, durch eine Recheneinheit, zumindest einer Sicherheitsrichtlinie mit Bezug auf den Datenaustausch zwischen einer Mehrzahl an E/E-Komponenten, wobei jede E/E-Komponente Datenquelle und/oder Datensenke sein kann;
- Identifizieren, durch die Recheneinheit, eines Datenflusses aus einer Vielzahl an möglichen Datenflüssen zwischen zumindest zwei E/E-Komponenten, der die zumindest eine Sicherheitsrichtlinie verletzt; und
- Bereitstellen, durch die Recheneinheit, einer ressourcenoptimierten Lösung für den identifizierten Datenfluss, der die Sicherheitsrichtlinie verletzt.
-
Vorzugsweise umfasst die zumindest eine Sicherheitsrichtlinie:
- - eine Sicherheitsanforderung zwischen einer Datenquelle und einer Datensenke; und/oder
- - eine Restriktion zwischen einer Datenquelle und einer Datensenke.
-
Vorzugsweise umfasst das Identifizieren des Datenflusses, der die Sicherheitsrichtlinie verletzt, das Generieren eines Konflikts.
-
Vorzugsweise beschreibt jeder Konflikt eine konkrete Verletzung einer Sicherheitsrichtlinie.
-
Diese und andere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden aus dem Studium der folgenden detaillierten Beschreibung bevorzugter Ausführungsformen und der beiliegenden Figuren verdeutlicht. Es ist ersichtlich, dass - obwohl Ausführungsformen separat beschrieben werden - einzelne Merkmale daraus zu zusätzlichen Ausführungsformen kombiniert werden können.
- 1 zeigt schematisch ein E/E, elektrisch-elektronisches, System im Fahrzeug;
- 2 zeigt ein beispielhaftes Verfahren Optimierung der Gewährleistung der Sicherheit im Fahrzeug;
- 3 zeigt eine beispielhafte Darstellung eines Steuergeräts bzw. einer ECU eines E/E-Systems;
- 4A zeigt eine beispielhafte Darstellung einer Datenquelle bzw. eines Sensors eines E/E-Systems;
- 4B zeigt eine beispielhafte Darstellung einer Datensenke bzw. eines Aktors eines E/E-Systems;
-
1 zeigt schematisch ein beispielhaftes E/E, elektrisch-elektronischem, System im Fahrzeug.
-
Das beispielhafte E/E-System kann eine Vielzahl an E/E-Komponenten umfassen, die Datenquellen sind. Das beispielhafte E/E-System umfasst als Datenquelle einen Sensor 122, einen OBD (On-Board-Diagnose)-Anschluss 124, einen USB-Anschluss 126, sowie einen Angreifer 128, der über die Kommunikationsverbindung des OBD-Anschlusses 124 und des USB-Anschlusses 126 einen Angriff auf das E/E-System durchführen kann. In diesem Fall können Daten durch die Datenquellen als Datenfluss über eine Kommunikationsverbindung 112 zu einem Steuergerät bzw. einer ECU fließen und dort in einer Speichereinheit 111 hinterlegt werden. Das Infotainmentsystem 140 kann sowohl eine Datenquelle als auch eine Datensenke sein, d.h. es kann ein Datenfluss vom Infotainmentsystem 140 zum Steuergerät 110 führen (und beispielsweise auch in der Speichereinheit 111) hinterlegt werden. Es kann aber auch ein Datenfluss vom Steuergerät 110 zum Infotainmentsystem 140 stattfinden. Die Aktoren 132, 134 und 136 sind Datensenken. Es kann ein Datenfluss zwischen dem Steuergerät 110 und dem jeweiligen Aktor 132, 134 bzw. 136 stattfinden. Bei dem Datenfluss können Daten, die von Datenquellen stammen, direkt fließen bzw. übermittelt werden oder vorher durch das Steuergerät verarbeitet werden. Somit ist das Steuergerät 110 auch sowohl Datenquelle (für den Datenfluss an die Aktoren 132, 134 und 136) als auch Datensenke (für den Datenfluss der Datenquellen 122, 124, 126, 128 und 140).
-
Ein System zur Optimierung der Gewährleistung der Sicherheit in einem E/E-System in dieses beispielhafte E/E-System integriert werden.
-
Das System zur Optimierung der Gewährleistung der Sicherheit im E/E-System umfasst eine Recheneinheit, die eingerichtet ist, zumindest eine Sicherheitsrichtlinie mit Bezug auf den Datenaustausch zwischen einer Mehrzahl an E/E-Komponenten umzusetzen. Wie bereits ausgeführt, kann jede E/E-Komponente eine Datenquelle und/oder eine Datensenke und/oder eine Kommunikationsverbindung zwischen einer Datenquelle und/oder einer Datensenke sein. Die Recheneinheit ist eingerichtet, aus einer Vielzahl an möglichen Datenflüssen, die zwischen der Vielzahl an E/E-Komponenten stattfinden können, einen Datenfluss zu identifizieren, die die bzw. die zumindest eine Sicherheitsrichtlinie verletzt. Die Implementierung von Sicherheitsrichtlinien wird weiter unten mit Bezug auf 3, 4A und 4B beschrieben.
-
Die zumindest eine Sicherheitsrichtlinie kann zumindest eine Sicherheitsanforderungen zwischen einer Datenquelle und einer Datensenke umfassen. Darüber hinaus oder alternativ dazu kann die Sicherheitsrichtlinien zumindest eine Restriktion zwischen einer Datenquelle und einer Datensenke im E/E-System umfassen. Im Steuergerät eines Fahrzeuges umfassen die Datenquellen beispielsweise Mechanismen, die an die von der jeweiligen Datenquelle übertragenen Daten eine Sicherheitsrichtlinie anhängen können, die dann in den entsprechenden Datensenken (z.B. Steuergeräten) verarbeitet werden können.
-
Die Recheneinheit kann eingerichtet sein, für den identifizierten Datenfluss, der die zumindest eine Sicherheitsrichtlinie verletzt, einen Konflikt zu generieren. Der Konflikt kann beispielsweise zur Laufzeit in den E/E-Komponenten identifiziert werden. Dies kann erfolgen, indem in den entsprechenden E/E-Komponenten, beispielsweise in einer Datensenke (z.B. Steuergerät), während der Laufzeit zumindest eine Sicherheitsrichtlinie, die an den von einer Datenquelle empfangenen Daten hängen bzw. mit den von einer Datenquelle empfangenen Daten übermittelt wurden, prüfen und mit potentiellen Sicherheitsrichtlinien, die für die jeweilige Datensenke gelten, vergleicht) Darüber hinaus oder alternativ dazu kann der Konflikt durch den Einsatz von Model Checking identifiziert werden. Model Checking ist ein Verfahren zur vollautomatischen Verifikation einer Systembeschreibung gegen eine Spezifikation. Die Systembeschreibung kann das E/E- System umfassen. Die Spezifikation kann die zumindest eine Sicherheitsrichtlinie umfassen. Der Konflikt kann Informationen darüber umfassen, auf welchem Pfad die Verletzung stattgefunden hat und welche Bedingung bzw. Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurden.
-
Jeder Konflikt, der durch die Recheneinheit generiert wird, kann eine konkrete Verletzung der zumindest einen Sicherheitsrichtlinien beschreiben. Die Beschreibung der konkreten Verletzung der zumindest einen Sicherheitsrichtlinien kann Informationen darüber umfassen, welche Sicherheitsrichtlinie (n) auf welchem Pfad die Verletzung stattgefunden hat und welche Bedingung bzw. Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurden.
-
Die Recheneinheit ist zudem eingerichtet, für den identifizierten Datenfluss, der die Sicherheitsrichtlinie verletzt, eine ressourcenoptimierte Lösung bereitzustellen.
-
Beispielsweise kann ein CSP (Constraint-Satisfaction-Problem bzw. Bedingungserfüllungsproblem) definiert werden, der die Erfüllung der Sicherheitsrichtlinie bei gleichzeitiger Ressourcenoptimierung für den identifizierten Datenfluss fordert. Durch die Verwendung von CSP ist es möglich, eine Belegung von Variablen zu identifizieren, der alle aufgestellten Bedingungen bzw. Constraints erfüllt. Gerade im E/E-System ist es mit Bezug auf die Minimierung der Datenlast auf den Kommunikationsverbindungen (Ethernet, Controller Area Network (CAN), FlexRay (FR), etc.) wesentlich, den richtigen Ort für die Bereitstellung der Lösung zur Gewährleistung der Einhaltung der Sicherheitsrichtlinie mit Bezug auf den identifizierten Datenfluss zu definieren. Auch die Energieoptimierung im E/E-System im Fahrzeug kann im CSP formuliert werden.
-
Vorteilhafterweise kann somit für sämtliche Datenflüsse, die im E/E-System stattfinden können, festgestellt werden, ob die zumindest eine Sicherheitsrichtlinie, die für den Datenaustausch im E/E-System definiert wurde, eingehalten wird. Insbesondere kann exakt festgestellt werden, auf welchem Pfad im E/E-System die Verletzung der zumindest einen Sicherheitsrichtlinie stattgefunden hat und welche Bedingung bzw. welche Bedingungen der zumindest einen Sicherheitsrichtlinie verletzt wurde(n), was insbesondere zur Identifikation des Ortes der ressourcenoptimierten Bereitstellung der Lösung beiträgt.
-
2 zeigt ein Verfahren 200 zur Optimierung der Gewährleistung der Sicherheit in einem E/E, elektrisch-elektronischem, System im Fahrzeug, das von einem System 100 wie mit Bezug auf 1 beschrieben ausgeführt werden kann.
-
Das Verfahren 200 umfasst:
- Umsetzen 210, durch eine Recheneinheit, zumindest einer Sicherheitsrichtlinie mit Bezug auf den Datenaustausch zwischen einer Mehrzahl an E/E-Komponenten, wobei jede E/E-Komponente Datenquelle und/oder Datensenke sein kann;
- Identifizieren 220, durch die Recheneinheit, eines Datenflusses aus einer Vielzahl an möglichen Datenflüssen zwischen zumindest zwei E/E-Komponenten, der die zumindest eine Sicherheitsrichtlinie verletzt; und
- Bereitstellen 230, durch die Recheneinheit, einer ressourcenoptimierten Lösung für den identifizierten Datenfluss, der die Sicherheitsrichtlinie verletzt.
-
Die zumindest eine Sicherheitsrichtlinie kann umfassen:
- - eine Sicherheitsanforderung zwischen einer Datenquelle und einer Datensenke; und/oder
- - eine Restriktion zwischen einer Datenquelle und einer Datensenke.
-
Das Identifizieren des Datenflusses, der die Sicherheitsrichtlinie verletzt, kann das Generieren eines Konflikts umfassen.
-
Jeder Konflikt kann eine konkrete Verletzung der zumindest einen Sicherheitsrichtlinie beschreiben.
-
3 zeigt eine beispielhafte Darstellung eines Steuergeräts bzw. einer ECU 300 eines E/E-Systems, wie mit Bezug auf 1 beschrieben. Das Steuergerät 300 kann auf die Kommmunikationskanäle CAN1 301, 302, CAN 2 303, Ethernet Eth 1 302 und Ethernet Eth 2 zugreifen. Zudem gibt es eine USB-Schnittstelle 305. 4A zeigt eine beispielhafte Darstellung einer Datenquelle bzw. eines Sensors 400 eines E/E-Systems, wie mit Bezug auf 1 beschrieben. Die Datenquelle 400 hat Zugriff auf Kommunikationskanäle CAN 1 401 und Eth 2 302. Zudem Umfasst sie einen OBD-Anschluss 412 und einen Sensor 410. 4B zeigt eine beispielhafte Darstellung einer Datensenke bzw. eines Aktors 450 eines E/E-Systems, wie mit Bezug auf 1 beschrieben. Der Aktor 450 hat Zugriff auf Kommunikationskanäle CAN 1 451 und Ethernet Eth 1 452. Zudem kann der Aktor Steuernd bzw. Regelnd auf eine LED (Light Emitting Diode) 466 zugreifen.
-
Für das System bzw. Verfahren zur optimierten Gewährleistung der Sicherheit in einem E/E, elektrisch-elektronischem, System im Fahrzeug wie mit Bezug auf 1 und zwei beschrieben kann ein entsprechendes Modell wie in 3, 4A und 4B beispielhaft dargestellt, generiert werden.
-
In dem Modell des E/E-Systems trägt jede Nachricht, die über einen Datenfluss zwischen E/E-Komponenten des Systems ausgetauscht wird, eine Sicherheitsrichtline (nicht gezeigt). Die Sicherheitsrichtlinie beschreibt eine Menge an Bedingungen, die erfüllt werden müssen, wenn auf die Daten der Nachricht lesend oder schreibend durch eine Datensenke zugegriffen wird. Diese Bedingungen können beispielsweise durch eine einfache, parameterisierte Boolesche Struktur - beispielsweise Paralocks wie durch David Sands definiert - definiert werden und beschreiben, wann, wie und was von einer E/E-Komponente zu einer anderen E/E-Komponente fließen darf (im Sinne von Datenfluss). Die E/E-Komponenten können als Knoten 301, 302, 303, 304, 305, 306, 340, 350, 360, 401, 402, 410, 412, 424, 426, 428, 451, 452, 461, 462, 463, 465, 466 modelliert werden und tragen Sicherheitsrichtlinien an Start- und/oder Endpunkten der Pfeile (nicht gezeigt). An den Endpunkten der Pfeile können Eingangsrichtlinien zum nächsten Knoten definiert sein, an den Startpunkten können Ausgangsrichtlinien definiert sein. Eingangsrichtlinien beschreiben die Bedingungen, die erfüllt sein müssen, damit die Nachricht bzw. das Datenpaket in den Knoten fließen darf. Ausgangsrichtlinien beschreiben die Bedingungen, die Nachrichten bzw. Datenpakete erben, wenn sie einen Knoten verlassen. Interne Funktionalität eines Knotens, der nicht durch dasselbe Modell beschrieben ist, ist durch ein Flussmodell (Flow Model) 312, 322, 432, 442, 472, 482 beschrieben. Ein Flussmodell beschreibt auf abstrakte Art und Weise, unter welchen Bedingungen die Information wohin fließt, also beispielsweise in eine Variable (Var 1, Var 2) 314, 316, 324, 434, 436, 444, 476, 477, 484, einen Speicherbereich (Vol Mem Region) 360, 426, 461 eine Datenbank (DB) 350, 424, 462, etc. Es existiert auch externer Daten- bzw. Nachrichten- bzw. Informationsfluss in das Modell, welches dazu dienen kann, einen Systemstatus (System State) 330, 464 zu definieren. Ein Systemstatus 330, 464 kann beispielsweise einen Zeitstempel bzw. eine Zeit, eine Geschwindigkeit des Fahrzeugs sowie weitere externe Bedingungen umfassen. Die Informationen über den Systemstatus 330, 464 kann in Bedingungen verwendet werden, um Sicherheitsrichtlinien zu definieren. Beispiel einer Bedingung für die Definition einer Sicherheitsrichtlinie kann die Überprüfung eines Zertifikats durch das Steuergerät umfassen, nachdem die Gültigkeit des Zertifikats abgelaufen ist. Auch ein Status des Steuergeräts (ECU State) 340, 428, 463 fließt in das Modell mit ein. Das Flussmodel definiert die Effekte, die während der Ausführung der Software auf der E/E-Komponente (z.B. auf einem Steuergerät) stattfinden werden. So kann vor der Ausführung geprüft werden, ob aufgrund der Ausführung der Steuergerätesoftware ein Konflikt erzeugt wird und welche Sicherheitseigenschaften die einzelnen Daten in den Datensenken auf der ECU nach der Ausführung, haben werden. Das Flussmodel kann somit zur Laufzeit vor der Ausführung der Software ausgeführt werden. Das kann - wie weiter oben ausgeführt - im E/E-System während der Laufzeit erfolgen.
-
3, 4A und 4B zeigen ein Modell von drei typischen E/E-Komponenten bzw. Knoten. Nachrichten bzw. Datenpakete können in einem Dienst kombiniert werden, der im Fahrzeug läuft. Beispiele für einen solchen Dienst sind das Speichern eines Strings der VIN (Vehicle Identification Number bzw. Fahrzeugidentifikationsnummer) und dessen aktuelle GNSS (Global Navigation Satellite System bzw. globales Navigationssatellitensystem) - Position kann in einer Speichereinheit 350, 360, 424, 426, 461, 462 hinterlegt werden und dann an einen externen Dienstleister bzw. an ein System eines externen Dienstleisters übermittelt werden. Wie weiter oben ausgeführt, können alle ausgetauschten Daten mit entsprechenden Sicherheitsrichtlinien ausgestattet sein, die zur Laufzeit überprüfe werden können. Vorteilhafterweise können die im Rahmen dieses Dokuments beschriebenen Anwendungen und Ausführungen im Fahrzeug während des Fahrzeugbetriebs durchgeführt werden.
-
Darüber hinaus können im Vorfeld Anwendungen bei der Architekturspezifikation während der Design-Zeit realisiert werden. In diesem Fall können die Daten selbst können als Dummy-Daten betrachtet werden. Daher werden die Sicherheitsrichtlinien über ein Gitter mit Definitionen einer kleinsten Obergrenze und größten Untergrenze definiert werden, um die Sicherheitsrichtlinien vergleichbar zu machen. Während des Checkens bzw. Prüfens werden alle Pfade simuliert und es werden Kombinationen von Sicherheitsrichtlinien generiert. Beim Propagieren werden die Bedingungen der Sicherheitsrichtlinien gegen die Eingangsrichtlinien überprüft und/oder durch die Ausgangsrichtlinien ersetzt. Die Konflikte, die durch den Model-Checker entdeckt werden, beschreiben Mengen von Bedingungen, die nicht erfüllt werden. Daher definiert jeder Konflikt klar, welche Bedingungen erfüllt sein müssen und auf welchem Pfad im E/E-Systemmodell der Konflikt aufgetreten ist. Das vorstehend beschriebene Modell kann auch ohne klassische Model Checker überprüft werden. Allerdings hat sich herausgestellt, dass ein Problem der Zustandsexplosion im E/E-Systemmodell besteht. Daher ist effizientes Checken mittels Bounded Model Checking oder Symbolic Model Checking erforderlich.
-
Aus den durch das Model Checking identifizierten, konkreten Konflikten kann jeweils ein CSP (Constraint-Satisfaction-Problem bzw. Bedingungserfüllungsproblem) definiert werden, der die Erfüllung der Sicherheitsrichtlinie bzw. die Lösung des Konflikts bei gleichzeitiger Ressourcenoptimierung für den identifizierten Datenfluss fordert. Die Verwendung von CSP ermöglicht es, eine Belegung von Variablen zu identifizieren, die alle aufgestellten Bedingungen bzw. Constraints erfüllt. Gerade im E/E-System ist es mit Bezug auf die Minimierung der Datenlast auf den Kommunikationsverbindungen (Ethernet, Controller Area Network (CAN), FlexRay (FR), etc.) wesentlich, den richtigen Ort für die Bereitstellung der Lösung zur Gewährleistung der Einhaltung der Sicherheitsrichtlinie mit Bezug auf den identifizierten Datenfluss zu definieren. Auch die Energieoptimierung im E/E-System im Fahrzeug kann im CSP formuliert werden.
