-
Die Erfindung betrifft ein System für ein Fahrzeug, das es ermöglicht, SW-Programme, insbesondere SW-Programme von Drittanbietern, in sicherer Weise in einem Fahrzeug auszuführen. Des Weiteren betrifft die Erfindung ein Verfahren zur Ausführung von SW-Programmen in einem Fahrzeug.
-
Mit zunehmender Digitalisierung, mit steigender Vernetzung von Fahrzeugen und mit steigender Einbindung von Fahrzeugen in vernetzte Systeme, steigt der Bedarf daran, in flexibler Weise Software (SW) von Drittanbietern zur Bereitstellung von Anwendungen auf eine HW-Plattform eines Fahrzeugs aufspielen zu können. Beispielsweise kann eine in ein Fahrzeug integrierte Parkhaus-, Maut- und/oder Tank-SW eine automatische Einfahrt und Ausfahrt des Fahrzeugs sowie eine automatische Abrechnung von Park-, Maut- oder Tankgebühren ermöglichen. Weitere Beispiele für Anwendungen sind: Automatische Zugangskontrollen (z.B. für Garagensysteme); Anbindung an Home-Automation Dienste; Fahrtenbuch-Systeme; Flottenmanagement-Systeme; Car-Sharing-Systeme; automatische Abrechnung von Fahrdiensten (wie z.B. Taxi- oder Mitfahr-Diensten); etc.
-
Bei der Integration eines SW-Programms (insbesondere bei der Integration einer sogenannten App) auf einer HW-Plattform eines Fahrzeugs muss sichergestellt werden, dass durch das SW-Programm die Sicherheit des Fahrzeugs nicht beeinträchtigt wird. Andererseits kann es erforderlich sein, zumindest Teile des SW-Programms (z.B. Teile mit vertraulichen Informationen, wie z.B. Abrechnungsdaten) vor unzulässigen Zugriffen zu schützen. Diese Anforderungen können zu einem relativ hohen Integrationsaufwand führen.
-
Das vorliegende Dokument befasst sich mit der technischen Aufgabe, ein System und ein Verfahren bereitzustellen, die eine flexible und sichere Integration von SW-Programmen in einem Fahrzeug ermöglichen.
-
Die Aufgabe wird durch die unabhängigen Ansprüche gelöst. Vorteilhafte Ausführungsformen werden u.a. in den abhängigen Ansprüchen beschrieben.
-
Gemäß einem Aspekt wird ein System zur Bereitstellung einer Anwendung mittels eines SW (Software)-Programms in einem Fahrzeug beschrieben. Die Anwendung kann z.B. darauf ausgelegt sein, das Fahrzeug mit einem Server und/oder mit einem elektronischen Gerät (z.B. einem Smartphone) außerhalb des Fahrzeugs zu vernetzten. Des Weiteren kann die Anwendung darauf ausgelegt sein, das Fahrzeug automatisch in eine Dienstleistung einzubinden (z.B. eine Parkdienstleistung, eine Straßennutzungsdienstleistung, eine Car-Sharing-Dienstleistung, etc.). Das SW-Programm kann dabei durch einen Dienstleister für die jeweilige Dienstleistung bereitgestellt werden.
-
Das System umfasst eine erste HW (Hardware)-Plattform und eine zweite HW-Plattform. Dabei können die erste HW-Plattform und die zweite HW-Plattform zur Bereitstellung einer besonders zuverlässigen Isolation zwischen den beiden HW-Plattformen separate Prozessoren umfassen. Beispielsweise kann die erste HW-Plattform Teil eines Steuergeräts, insbesondere einer Head Unit, des Fahrzeugs sein. Andererseits kann die zweite HW-Plattform von dem Steuergerät, insbesondere der Head Unit, des Fahrzeugs, insbesondere von einem Betriebssystem des Steuergeräts des Fahrzeugs, getrennt sein.
-
Alternativ oder ergänzend kann die zweite HW-Plattform einen nicht-flüchtigen Speicher (z.B. zur Speicherung von Daten) und/oder einen flüchtigen Speicher (z.B. für den Betrieb eines SW-Moduls) umfassen, der von der ersten HW-Plattform getrennt ist. Des Weiteren kann der Speicher der zweiten HW-Plattform mittels ein oder mehrerer Sicherheitsmaßnahmen geschützt sein. Dabei kann der Speicher der zweiten HW-Plattform mit ein oder mehreren Sicherheitsmaßnahmen geschützt sein, die nicht zum Schutz der ersten HW-Plattform verwendet werden. Der Speicher (sowohl der „runtime“ Speicher als auch der „storage“ Speicher) der zweiten HW-Plattform können derart durch ein oder mehrere Sicherheitsmaßnahmen geschützt sein, dass der Speicher nicht von außen (bzw. von einer unsicheren Applikation) manipulierbar ist.
-
Die zweite HW-Plattform unterliegt ein oder mehreren Sicherheitsmaßnahmen, denen die erste HW-Plattform nicht unterliegt. Die ein oder mehreren Sicherheitsmaßnahmen können z.B. eine Überprüfung von SW-Code eines SW-Moduls umfassen, das auf der zweiten HW-Plattform ausgeführt wird. Insbesondere kann der SW-Code von einem Hersteller des Fahrzeugs und/oder durch eine von dem Bereitsteller des SW-Programms separate Einheit überprüft werden. So kann gewährleistet werden, dass durch ein SW-Modul auf der zweiten HW-Plattform keine sicherheitsrelevanten Daten freigegeben werden und/oder keine sicherheitsrelevante Funktion (des Fahrzeugs) beeinträchtigt wird. Alternativ oder ergänzend können die ein oder mehreren Sicherheitsmaßnahmen eine Beschränkung von Daten umfassen, die an ein SW-Modul oder von einem SW-Modul übergeben werden können, das auf der zweiten HW-Plattform ausgeführt wird. Es können somit der Fluss von Daten zu der zweiten HW-Plattform hin und/oder von der zweiten HW-Plattform weg beschränkt werden.
-
Das SW-Programm umfasst zumindest ein Basis-Modul und zumindest ein sicherheitsrelevantes Modul. Dabei greift das sicherheitsrelevante Modul auf sicherheitsrelevante Daten und/oder auf eine sicherheitsrelevante Funktion zu. Andererseits greift das Basis-Modul typischerweise nicht oder nur über definierte Schnittstellen auf sicherheitsrelevante Daten und/oder auf eine sicherheitsrelevante Funktion zu. Das SW-Programm kann somit in ein oder mehrere sicherheits-kritische Teile und in ein oder mehrere sicherheits-unkritische Teile ausgeteilt werden.
-
Das Basis-Modul (d.h. die ein oder mehreren sicherheits-unkritischen Teile) kann dann auf der ersten HW-Plattform ausgeführt werden, und das sicherheitsrelevante Modul (d.h. die ein oder mehreren sicherheits-kritischen Teile) kann auf der zweiten HW-Plattform ausgeführt werden.
-
Das System ermöglicht es somit, in zuverlässiger, sicherer und effizienter Weise SW-Programme für Anwendungen in einem Fahrzeug bereitzustellen.
-
Das zumindest eine sicherheitsrelevante Modul (d.h. die ein oder mehreren sicherheits-kritischen Teile) umfasst bevorzugt 20%, 10% oder weniger des SW-Codes des SW-Programms und das zumindest eine Basis-Modul (d.h. die ein oder mehreren sicherheits-unkritischen Teile) umfasst bevorzugt 80%, 90% oder mehr des SW-Codes des SW-Programms. So können die ein oder mehreren Sicherheitsmaßnahmen bezüglich des zweiten HW-Moduls in effizienter Weise umgesetzt werden.
-
Die erste HW-Plattform ist bevorzugt derart ausgelegt, dass ein auf der ersten HW-Plattform ausgeführtes SW-Modul (d.h. ein Basis-Modul) keinen Zugriff oder nur Zugriff über eine definierte Schnittstelle auf eine sicherheitsrelevante Funktion des Fahrzeugs hat. Andererseits ist die zweite HW-Plattform bevorzugt derart ausgelegt, dass ein auf der zweiten HW-Plattform ausgeführtes SW-Modul einen Zugriff auf eine sicherheitsrelevante Funktion des Fahrzeugs hat. So kann in zuverlässiger Weise eine sichere Ausführung von SW-Programmen in einem Fahrzeug ermöglicht werden.
-
Das Basis-Modul kann eingerichtet sein, bei der Ausführung des SW-Programms das sicherheitsrelevante Modul aufzurufen und eine Ausführung des sicherheitsrelevanten Moduls auf der zweiten HW-Plattform zu veranlassen. Dabei können bei der Ausführung des SW-Programms Daten von dem Basis-Modul an das sicherheitsrelevante Modul übergeben werden. Des Weiteren können Daten von dem sicherheitsrelevanten Modul an das Basis-Modul übergeben werden. Dabei kann das sicherheitsrelevante Modul eine standardisierte Schnittstelle aufweisen, über die die Daten an das sicherheitsrelevante Modul oder von dem sicherheitsrelevanten Modul übergeben werden können. So kann eine sichere Ausführung von SW-Programmen von externen SW Anbietern in einem Fahrzeug ermöglicht werden.
-
Gemäß einem weiteren Aspekt wird ein Verfahren zur Ausführung eines SW-Programms in einem Fahrzeug beschrieben. Das Verfahren umfasst das Ausführen eines Basis-Moduls des SW-Programms auf einer ersten HW-Plattform (z.B. auf der Head Unit) des Fahrzeugs. Außerdem umfasst das Verfahren das Aufrufen, aus dem Basis-Modul heraus, eines sicherheitsrelevanten Moduls des SW-Programms, wobei das sicherheitsrelevante Modul auf sicherheitsrelevante Daten und/oder auf eine sicherheitsrelevante Funktion zugreift. Das Verfahren umfasst weiter das Ausführen des sicherheitsrelevanten Moduls auf einer zweiten HW-Plattform des Fahrzeugs, wobei die zweite HW-Plattform ein oder mehreren Sicherheitsmaßnahmen unterliegt, denen die erste HW-Plattform nicht unterliegt.
-
Gemäß einem weiteren Aspekt wird ein Fahrzeug (insbesondere ein Straßenkraftfahrzeug z.B. ein Personenkraftwagen, ein Lastkraftwagen oder ein Motorrad) beschrieben, das das in diesem Dokument beschriebene System umfasst.
-
Es ist zu beachten, dass die in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systeme sowohl alleine, als auch in Kombination mit anderen in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systemen verwendet werden können. Des Weiteren können jegliche Aspekte der in diesem Dokument beschriebenen Verfahren, Vorrichtungen und Systemen in vielfältiger Weise miteinander kombiniert werden. Insbesondere können die Merkmale der Ansprüche in vielfältiger Weise miteinander kombiniert werden.
-
Im Weiteren wird die Erfindung anhand von Ausführungsbeispielen näher beschrieben. Dabei zeigen
- 1 ein beispielhaftes System zur Integration von SW-Programmen;
- 2 einen beispielhaften Aufbau eines SW-Programms; und
- 3 ein Ablaufdiagramm eines beispielhaften Verfahrens zur Ausführung eines SW-Programms in einem Fahrzeug.
-
Wie eingangs dargelegt, befasst sich das vorliegende Dokument mit der flexiblen und sicheren Integration von SW-Programmen für unterschiedliche Anwendungen auf einer HW-Plattform eines Fahrzeugs.
-
Ein SW-Programm für eine Anwendung kann z.B. auf einem Smartphone eines Nutzers installiert werden, und das Smartphone kann mit dem Fahrzeug über eine Datenverbindung verbunden werden. Andererseits kann ein SW-Programm direkt auf einem Steuergerät (z.B. der Head Unit) eines Fahrzeugs installiert und ausgeführt werden. Diese beiden Möglichkeiten sind mit Nachteilen verbunden. Beispielsweise kann es für einen Nutzer unerwünscht sein, Software von ggf. unbekannten Anbietern auf einem persönlichen Smartphone zu installieren. Andererseits erfordert die direkt Integration von SW-Programmen auf der Head Unit eines Fahrzeugs typischerweise hohe Integrationsaufwendungen. Dabei ist eine vollständige Kontrolle und/oder Überprüfung der aufgespielten SW aufgrund der hohen Komplexität ggf. nicht möglich. Des Weiteren kann die Sicherheit von Daten aus einem SW Programm innerhalb einer Head Unit ggf. nicht ausreichend gewährleistet werden.
-
Es wird daher vorgeschlagen, in einem Fahrzeug eine vertrauenswürdige Umgebung (d.h. ein sicheres Ökosystem) für Software von Drittanbietern bereitzustellen. Durch die Bereitstellung einer derartigen vertrauenswürdigen Umgebung kann einem externen Anbieter eines SW-Programms gewährleistet werden, dass sicherheitsrelevante Teile des SW-Programms (z.B. kryptographische Schlüssel) vor Zugriff geschützt sind. Des Weiteren kann in effizienter Weise sichergestellt werden, dass ein SW-Programm eines externen Anbieters nicht die Sicherheit des Fahrzeugs beeinträchtigt.
-
1 zeigt ein Blockdiagramm eines Systems 100 zur Bereitstellung von SW-Programmen in einem Fahrzeug. Das System 100 umfasst eine erste HW-Plattform 110 (z.B. einen ersten Prozessor) auf dem unterschiedliche SW-Programme 111, 112, 113, insbesondere ein SW-Programm 113 eines externen Anbieters, ausgeführt werden können. Die SW-Programme 111, 112, 113 können unter Verwendung eines Betriebssystems 130 ausgeführt werden. Des Weiteren können die SW-Programme 111, 112, 113 auf ein oder mehrere HW-Treiber 131 zugreifen, z.B. um eine Datenkommunikation über eine Kommunikationseinheit 141, 142, 143 zu ermöglichen (z.B. über eine Kommunikationseinheit 141 für ein zellulares Netz (GSM, UMTS, LTE), über eine Kommunikationseinheit 142 für WLAN und/oder über eine Kommunikationseinheit 143 für Bluetooth).
-
Das System 100 umfasst weiter eine zweite HW-Plattform 120 (z.B. einen zweiten Prozessor) zur Ausführung von ein oder mehreren sicherheitsrelevanten SW-Modulen 121, 122 der auf der ersten HW-Plattform 110 implementierten SW-Programme 111, 112, 113. Ein sicherheitsrelevantes SW-Modul 121, 122 kann z.B. sicherheitsrelevante Daten umfassen. Alternativ oder ergänzend kann ein sicherheitsrelevantes SW-Modul 121, 122 einen Zugriff auf eine sicherheitsrelevante Fahrzeug-interne oder Fahrzeug-externe Funktion ermöglichen.
-
Die zweite HW-Plattform 120 kann besonderen ein oder mehreren Sicherheitsmaßnahmen unterliegen. Insbesondere kann durch den Hersteller eines Fahrzeugs eine detaillierte Analyse und Überprüfung der ein oder mehrere SW-Module 121, 122 vorgenommen werden, die auf der zweiten HW-Plattform 120 installiert werden. Des Weiteren können Maßnahmen vorgesehen sein, die einen unbefugten Zugriff auf SW-Module 121, 122 und/oder Daten auf der zweiten HW-Plattform 120 verhindern. Die zweite HW-Plattform 120 kann eine Sicherheitsmaßnahme aufweisen, die der zweiten HW-Plattform 120 einen besonderen Schutz vor Seitenkanalangriffen liefert. Des Weiteren kann durch eine Sicherheitsmaßnahme ein physisches Auslesen eines Speichers der zweiten HW-Plattform 120 unterbunden werden. Mit anderen Worten, die zweite HW-Plattform 120 kann derart durch ein oder mehrere Sicherheitsmaßnahmen geschützt sein, dass die ein oder mehreren Speicher der zweiten HW-Plattform 120 nicht (von außen) ausgelesen werden können. Die zweite HW-Plattform 120 kann insbesondere „tamper-resistant“ bzw. manipulationssicher ausgebildet sein.
-
Es wird somit eine vertrauenswürdige Anwendungsumgebung 120 für einen Automobilhersteller und einen Anbieter von Drittsoftware bereitgestellt. Die Sicherheits-Hardware-Plattform 120 stellt eine Abstraktionsschicht zwischen dem Steuergerät Betriebssystem 130, ein oder mehreren Hoch-Sicherheits-Modulen 121, 122 und allen anderen SW-Programmen 111, 112, 113 dar. Ein Hoch-Sicherheits-Modul 121, 122 ist dabei typischerweise sehr klein, so dass der Programm-Quell-Code eines solchen Moduls 121, 122 geprüft werden kann. Darüber hinaus stellt die Sicherheits-Hardware-Plattform 120 eine starke Isolation für ein Hoch-Sicherheits-Modul 121, 122 bereit. Hierdurch wird ein Zugriff auf Rechenoperationen und/oder Daten eines Hoch-Sicherheits-Moduls 121, 122 durch ein anderes Hoch-Sicherheits-Modul 121, 122 oder durch ein sonstiges SW-Programm 111, 112, 113 verhindert. Die ein oder mehreren Schnittstellen für Hoch-Sicherheits-Module 121, 122 können einheitlich und/oder standardisiert sein.
-
1 zeigt weiter ein Kommunikationsnetz 150 (z.B. das Internet) mit dem direkt (z.B. über eine Kommunikationseinheit 141 für ein zellulares Netz) oder indirekt über ein Smartphone 160 mit ein oder mehreren SW-Applikationen 161 kommuniziert werden kann.
-
2 veranschaulicht einen beispielhaften Ablauf 200 eines SW-Programmes 111, 112, 113. Ein SW-Programm 111, 112, 113 kann ein oder mehrere Basis-Module 210 umfassen, die auf der ersten HW-Plattform 110 installiert sein können. Des Weiteren kann ein SW-Programm 111, 112, 113 ein oder mehrere sicherheitsrelevante Module 121, 122 umfassen, die auf der zweiten HW-Plattform 120 installiert sind. Bei der Ausführung eines SW-Programms 111, 112 113 kann zunächst ein Basis-Modul 210 ausgeführt werden, das bei Bedarf ein sicherheitsrelevantes Modul 121, 122 aufruft. Bei dem Aufruf können Eingangsdaten 211 an ein sicherheitsrelevantes Modul 121, 122 übergeben werden. Des Weiteren können nach oder während der Ausführung der sicherheitsrelevanten Moduls 121, 122 Ausgangsdaten 221 zurück an ein Basis-Modul 210 übergeben werden. Durch die Aufteilung eines SW-Programms 111, 112, 113 in ein oder mehrere Basis-Module 210 und ein oder mehrere sicherheitsrelevante Module 121, 122 können komplexe Anwendungen bereitgestellt werden, die jedoch nur relativ kleine sicherheitsrelevante Module 121, 122 umfassen, die in effizienter und zuverlässiger Weise überprüft werden können.
-
Der Zugriff auf eine sicherheitsrelevante Fahrzeug-interne Funktion 201 und/oder auf eine sicherheitsrelevante Fahrzeug-externe Funktion 202 kann bevorzugt ausschließlich durch ein sicherheitsrelevantes Modul 121, 122 ermöglicht werden. So kann in effizienter Weise die Sicherheit von Fahrzeugfunktionen 201 und/oder Fahrzeug-externen Funktionen 202 sichergestellt werden.
-
In einem Beispiel für eine automatische Parkhausabrechnung stellt ein externer Anbieter eine Bezahl-Applikation 113 bereit. Diese Applikation 113 teilt sich in zwei Teile 121, 210, einen sicherheits-kritischen Teil 121 und einen sicherheits-unkritischen Teil 210. Der sicherheits-kritische Teil 121 wird auf der Sicherheits-Hardware-Plattform 120 ausgeführt und der sicherheits-unkritischen Teil 210 wird innerhalb des üblichen Steuergerät (z.B. Head Unit) Betriebssystems 130 bzw. auf der ersten HW-Plattform 110 ausgeführt. Als sicherheits-kritischer Teil 121 können z.B. die für den Bezahlvorgang erforderlichen kryptografischen Operationen angesehen werden. Als sicherheits-unkritischer Teil 210 können die Nutzerschnittstelle und die Kommunikation z.B. mit dem Internet 150 angesehen werden. Alle kritischen Operationen (insbesondere eine Verschlüsselung) können auf der Sicherheits-Hardware-Plattform 120 ausgeführt werden, so dass z.B. alle Daten von und zum Internet 150, die z.B. auf der ersten HW-Plattform 110 bearbeitet werden, verschlüsselt und integritätsgeschützt sind.
-
Ein Nutzer fährt mit seinem Fahrzeug zum Parkhauseingang und das Parkhaus nimmt z.B. über WLAN, Bluetooth oder Internet, Kontakt mit dem Fahrzeug auf. Unter Verwendung eines sicherheits-kritischen Teils 121 der Bezahl-Applikation 113 wird der Nutzer bzw. das Fahrzeug als „im Parkhaus“ registriert und es kann (mittels eines sicherheits-unkritischen Teils 210) eine Bestätigung über die Nutzerschnittstelle ausgegeben werden. Bei der Ausfahrt übernimmt wiederum ein sicherheits-kritischer Teil 121 der Bezahl-Applikation 113 die Berechnung der Kosten und identifiziert dabei das Fahrzeug eindeutig mittels kryptografischer Operationen.
-
In einem weiteren Beispiel wird ein sicheres Car-Sharing (ohne Zusatz-/Fremd-Hardware) beschrieben. Dabei möchte ein Drittanbieter ein Fahrzeug für Car-Sharing zur Verfügung stellen. Dazu könnte eine Car-Sharing Software direkt in einem Steuergerät des Fahrzeugs ausgeführt werden, was ggf. zu SicherheitsRisiken führen könnte und/oder was einen relativ hohen Integrationsaufwand erfordert. Alternativ könnte eine Zusatzhardware (z.B. ein weiteres Steuergerät) in ein Fahrzeug verbaut werden, was ebenfalls zu relativ hohen Integrationsaufwänden führen würde.
-
Unter Verwendung des in diesem Dokument beschriebenen Systems 100 kann eine Car-Sharing Anwendung 113 in zwei Teile 210, 121 aufgeteilt werden, einen sicherheits-kritischen Teil 121 und einen sicherheits-unkritischen Teil 210. Der sicherheits-kritische Teil 121 wird auf der Sicherheits-HW-Plattform 120 ausgeführt und der sicherheits-unkritische Teil 210 kann innerhalb des üblichen Head Unit Betriebssystems 130 und/oder zusammen mit einer unkritischen Benutzer-Applikation auf z.B. einem Smartphone 160 ausgeführt werden.
-
Als sicherheits-kritischer Teil 121 können z.B. die für den Fahrzeug-Zugang, Fahrzeug-Start und den Abrechnungs-Vorgang erforderlichen kryptografischen Operationen angesehen werden. Als sicherheits-unkritischer Teil 210 können die Nutzerschnittstelle und die Kommunikation z.B. mit dem Internet angesehen werden. Da alle kritischen Operationen bereits auf der Sicherheits-HW-Plattform 120 ausgeführt werden, sind z.B. alle Daten von und zum Internet bereits verschlüsselt und integritätsgeschützt.
-
Ein Nutzer installiert sich eine Car-Sharing Applikation (die Fahrzeug-spezifische Schnittstellen unterstützt) auf einem Smartphone 160. Der Nutzer registriert sich bei einem Car-Sharing Anbieter, der wiederum eine Registrierung des Nutzers in einem Backend vornimmt. Der Nutzer bucht über die Car-Sharing Applikation ein verfügbares Fahrzeug und erhält auf seinem Smartphone 160 ein „Token“ mit dem er ein bestimmtes Fahrzeug z.B. in einem bestimmten Zeitraum nutzen kann. Der Nutzer geht mit seinem Smartphone 160 zu dem bestimmten Fahrzeug und kann mit dem Smartphone 160 u.A. das Fahrzeug öffnen.
-
Der sicherheits-kritische Teil 121 der Car-Sharing Anwendung 113 verifiziert das „Token“, und es wird bei Bestätigung des „Token“ die Fahrzeugnutzung gewährt. Dabei ist es für einen Nutzer unmöglich ein Token selbst zu erzeugen oder ein altes Token erneut einzuspielen. Des Weiteren ist es aufgrund der in diesem Dokument beschriebenen Struktur irrelevant, ob das Smartphone 160 oder die Car-Sharing Applikation unsicher sind, da nur der sicherheits-kritische Teil 121 der Car-Sharing Anwendung 113 kritische Komponenten 201 des Fahrzeugs und/oder kritische Fahrzeug-externe Komponenten 202 beeinflusst (z.B. Zugang, Fahrzeugstart, Buchungen).
-
Durch eine weitere Anpassung der zugrundeliegenden Hardware (insbesondere der Prozessorumgebung von z.B. der Head Unit) kann eine weitergehende Isolation von SW Programmen 113 eines externen Anbieters ermöglicht werden. Dabei können Applikationen vollständig von der übrigen Softwareumgebung der Head Unit isoliert werden. So kann die Sicherheit weiter erhöht werden.
-
3 zeigt ein Ablaufdiagramm eines beispielhaften Verfahrens 300 zur Ausführung eines SW-Programms 113 in einem Fahrzeug. Das SW-Programm 113 kann durch einen externen Anbieter für eine Anwendung bereitgestellt werden. Der externe Anbieter kann dabei weder der Hersteller des Fahrzeugs noch ein Zulieferer für eine Komponente des Fahrzeugs sein. Der externe Anbieter kann z.B. ein Dienstleister sein, der mittels des SW-Programms 113 eine Dienstleistung, wie z.B. eine Abrechnungs-Dienstleistung, eine Car-Sharing Dienstleistung, etc., in Zusammenhang mit dem Fahrzeug bereitstellen möchte.
-
Das Verfahren 300 umfasst das Ausführen 301 eines Basis-Moduls 210 des SW-Programms 113 auf einer ersten HW-Plattform 110 des Fahrzeugs (z.B. auf der Head Unit des Fahrzeugs). Das Basis-Modul 210 kann z.B. relativ unkritische Funktionen, wie z.B. eine Nutzerschnittstelle und/oder eine Kommunikation mit einem Netzwerk 150 und/oder mit einem Fahrzeug-externen Gerät 160 (z.B. einem Smartphone) ermöglichen.
-
Es kann dann aus dem Basis-Modul 210 heraus bei Ausführung des SW-Programms 113 ein sicherheitsrelevantes Modul (121) des SW-Programms (113) aufgerufen werden (Schritt 302). Dabei greift das sicherheitsrelevante Modul 121 auf sicherheitsrelevante Daten (z.B. auf kryptographische Schlüssel und/oder auf Abrechnungsdaten) und/oder auf eine sicherheitsrelevante Funktion (z.B. auf eine Schließanlage des Fahrzeugs und/oder auf eine Motorstartfunktion des Fahrzeugs) zu.
-
Außerdem umfasst das Verfahren 300 das Ausführen 303 des sicherheitsrelevanten Moduls 121 auf einer zweiten HW-Plattform 120 des Fahrzeugs. Dabei unterliegt die zweite HW-Plattform 120 ein oder mehreren Sicherheitsmaßnahmen, denen die erste HW-Plattform 110 nicht unterliegt. Beispielsweise erfolgt für SW-Module 121, die auf der zweiten HW-Plattform 120 ausgeführt werden sollen, eine Überprüfung des SW-Codes durch den Hersteller des Fahrzeugs, um ungewünschte Auswirkungen auf eine Fahrzeug-Funktion 201 zu unterbinden. Alternativ oder ergänzend kann eine Beschränkung von Daten 201, 202 erfolgen, die an ein SW-Module 121 oder von einem SW-Module 121 übergeben werden können, das auf der zweiten HW-Plattform 120 ausgeführt wird.
-
In diesem Dokument wird somit eine standardisierte Software- und Hardwareumgebung für SW Programme 113 von externen Anbietern beschrieben. Dabei ist das beschriebene System 100 bevorzugt derart ausgelegt, dass keine Spezialkenntnisse bezüglich Embedded-Hardware/-Software benötigt werden und dass alle Softwareschnittstellen eindeutig definiert sind. Durch eine Abstraktion der Hardware muss sich ein externer Anbieter von SW-Programmen 113 nicht um Hardwareschnittstellen kümmern. Des Weiteren muss ein Fahrzeughersteller für die Anbindung eines neuen SW-Programms 113 keine Software- bzw. Hardware-Änderungen vornehmen.
-
Es wird somit eine sichere und verlässliche Ausführungsumgebung für SW-Programme 113 von externen Anbietern innerhalb eines Fahrzeugs bereitgestellt. Dabei können SW-Programme 113 während der Betriebszeit eines Fahrzeugs nachgeliefert werden (nach Prüfung und Signatur durch den Automobilhersteller), so dass Funktionserweiterung des Fahrzeugs ermöglicht werden. Außerdem kann ein Automobilhersteller sicherheits-kritische Teile 121 eines SW-Programms 111 auf die Sicherheits-HW-Plattform 120 auslagern, um das Sicherheitsniveau einess Steuergerätes (z.B. einer Head Unit) eines Fahrzeugs zu erhöhen.
-
Die vorliegende Erfindung ist nicht auf die gezeigten Ausführungsbeispiele beschränkt. Insbesondere ist zu beachten, dass die Beschreibung und die Figuren nur das Prinzip der vorgeschlagenen Verfahren, Vorrichtungen und Systeme veranschaulichen sollen.
