-
Stand der Technik
-
Moderne Fahrzeuge sehen oftmals Konzepte zum Aktualisieren von Fahrzeugsoftware ohne Werkstattbesuch vor. Oftmals werden Softwareupdates hierbei über eine Funkschnittstelle bezogen (Update over the Air - OTA). Zukünftig wird es ebenfalls möglich sein, in Form herunterladbarer Apps, zusätzliche Software bzw. Funktionalitäten auf bereits im Feld befindliche Fahrzeuge aufzuspielen.
-
Zusätzlichen setzen sich beispielsweise in der Automobilbranche Softwarekonzepte durch, bei denen Software so gestaltet ist, dass deren Ausführung nicht an zum Zeitpunkt der Softwareerstellung bereits festgelegte Hardwareeinheiten gekoppelt ist. So kann eine Software möglichst hardwareagnostisch ausgebildet sein, um von einem beliebigen geeigneten Steuergerät im Fahrzeug ausgeführt zu werden. Solche nomadischen Softwarefunktionen werden insbesondere im Zusammenhang mit E/E-Architekturen ermöglicht bzw. benötigt, die s.g. Zonensteuergeräte vorsehen.
-
Steuergeräten in technischen Systemen werden mitunter Sicherheitsklassen zugeordnet, die spezifizieren, welchen Grad an funktionaler Sicherheit ein Steuergerät gewährleisten kann. Im Falle von Kraftfahrzeugen wird hierfür die Einteilung in ASIL (Automotive Safety Integrity Level) gewählt. Aus Sicherheitsgründen ist vorgesehen, Funktionen, die per se eine gewisse Gefährdung mit sich bringen, nur auf besonders sicheren Steuergeräten (ASIL D, ASIL C) auszuführen.
-
Wird eine nomadische Software auf einem Fahrzeugsteuergerät aufgespielt, muss sichergestellt werden, dass das entsprechende Steuergerät einem ASIL-Level entspricht, das größer oder gleich dem von der Software geforderten ASIL-Level ist. Eine Software mit Anforderungen an ASIL C darf also nur auf Steuergeräten ausgeführt werden, die ASIL C oder ASIL D entsprechen. Eine Selbstauskunft des Sicherheitslevels einer Recheneinheit mit niedriger ASIL-Einstufung ist definitionsgemäß dabei nicht vollständig vertrauenswürdig. Ein Steuergerät, das lediglich eine Sicherheitseinstufung QM, also unterhalb ASIL A, aufweist, könnte sich daher im schlimmsten Fall als ASIL D ausgegeben, sodass hochkritische Software dort ausgeführt werden könnte, obwohl das Steuergerät hierfür nicht geeignet ist.
-
Offenbarung der Erfindung
-
Das erfindungsgemäße Verfahren zum Zuweisen eines einer Koordinierungseinheit zur Verfügung stehenden Software-Pakets an ein Zielsteuergerät, wobei das Zielsteuergerät ein Security-Modul umfasst, hat demgegenüber den Vorteil, dass dem Software-Paket eine Safety-Anforderung und eine Performance-Anforderung zugeordnet sind, dem Zielsteuergerät eine Safety-Möglichkeit und eine Performance-Möglichkeit zugeordnet sind, die Koordinierungseinheit die Performance-Anforderung des Software-Pakets mit der Performance-Möglichkeit des Zielsteuergeräts vergleicht und das Software-Paket dem Zielsteuergerät vorläufig zuweist, wenn die Performance-Anforderung des Software-Pakets der Performance-Möglichkeit des Zielsteuergeräts entspricht, wobei das Zielsteuergerät unter Verwendung des Security-Moduls die Safety-Anforderung des Software-Pakets mit der eigenen Safety-Möglichkeit vergleicht und das Software-Paket endgültig dem Zielsteuergerät zugewiesen wird, wenn die Safety-Möglichkeit des Zielsteuergeräts der Safety-Anforderung des Software-Pakets entspricht. Somit kann vorteilhafter Weise sichergestellt werden, dass auch in Systemen mit mehreren Steuergeräten Software-Pakete, beispielsweise nomadische Software, nur geeigneten Steuergeräten zugewiesen wird. Die Verwendung eines Security-Moduls, beispielsweise eines Hardware Security Moduls (HSM), bietet zusätzliche Sicherheit sowohl gegen fehlerhafte Zuweisungen als auch gegen absichtsvolle Zuweisungen zu ungeeigneten Steuergeräten im Zusammenhang mit Cybersecurity-Attacken.
-
Das erfindungsgemäße Verfahren hat weiterhin den Vorteil, dass eine vorläufige Zuweisung des Software-Pakets anhand eines Vergleichs der Performance-Anforderung und der Performance-Möglichkeit des Zielsteuergeräts erfolgt. Die Koordinierungseinheit muss daher nicht auf die Safety-Möglichkeit des Zielsteuergeräts zugreifen, kann anhand des Vergleichs der Performance-Anforderung mit der Performance-Möglichkeit aber eine sinnvolle und ressourcensparende vorläufige Zuweisung vornehmen.
-
Unter Safety-Möglichkeit soll insbesondere ein Gegenstück zu einer Safety-Anforderung verstanden werden. Eine Safety-Möglichkeit ist daher eine Klassifikation des Zielsteuergeräts in Bezug auf seine Eignung zum Ausführen des ebenfalls klassifizierten Software-Pakets. Vorteilhafterweise umfassen sowohl die Safety-Anforderung, als auch die Safety-Möglichkeit nicht nur Anforderungen bzw. Möglichkeiten in Bezug auf eine nackte Hardware des Zielsteuergeräts, sondern auch Anforderungen bzw. Möglichkeiten in Bezug auf die auf dem Zielsteuergerät installierte Basis-Software und Middleware.
-
Im Sinne der vorliegenden Erfindung entspricht die Safety-Möglichkeit des Zielsteuergeräts der Safety-Anforderung des Software-Pakets, wenn einzelne Aspekte der Safety-Möglichkeit den jeweils zugehörigen Aspekten der Safety-Anforderung mindestens entsprechen oder diese übertreffen. Beispielsweise eine ASIL-Kategorie der Safety-Möglichkeit entspricht also der ASIL-Kategorie der Safety-Anforderung, wenn die ASIL-Kategorie der Safety-Möglichkeit gleich oder höherwertig ist, als die ASIL-Kategorie der Safety-Anforderung.
-
Unter Performance-Möglichkeit soll insbesondere ein Gegenstück zu einer Performance-Anforderung verstanden werden. Eine Performance-Möglichkeit ist daher eine Information über eine Leistungsfähigkeit des Zielsteuergeräts in Hinblick auf die Ausführung des Software-Pakets. Im Sinne der vorliegenden Erfindung entspricht die Performance-Möglichkeit des Zielsteuergeräts der Performance-Anforderung des Software-Pakets, wenn alle einzelnen Aspekte der Performance-Möglichkeit den jeweils zugehörigen Aspekten der Performance-Anforderung mindestens entsprechen oder diese übertreffen.
-
Vorteilhafter Weise sind die Koordinierungseinheit und das Zielsteuergerät Teil einer E/E-Architektur, beispielsweise eines Kraftfahrzeugs. Bei der Koordinierungseinheit kann es sich um ein dezidiertes Steuergerät, beispielweise ein Steuergerät, das explizit für die Koordinierung und den Empfang von Softwareupdates (OTA-Master) vorgesehen ist, oder ein Softwaremodul innerhalb eines übergeordneten Steuergeräts, beispielsweise eines Fahrzeugführungsrechners (Vehicle Computer - VCU), handeln.
-
Besonders vorteilhaft ist, wenn die Safety-Anforderung Informationen zu einer benötigten ASIL-Kategorie umfasst. Die ASIL-Kategorie kann dabei die mindest ASIL-Kategorie von Steuergeräten festlegen, die zur Ausführung des Software-Pakets geeignet sind.
-
Vorteilhaft ist, wenn die Performance-Anforderung Informationen zu einem benötigten Speicherplatz und/oder einem benötigten Rechenraster umfasst. Der benötigte Speicherplatz gibt vorteilhafterweise an, wie viel Speicherplatz das Zielsteuergerät zur Ausführung des Software-Pakets zur Verfügung stellen muss. Das benötigte Rechenraster gibt vorteilhafterweise an, welches Rechenraster das Zielsteuergerät zur sicheren und zuverlässigen Ausführung des Software-Pakets bereitstellen muss. Beispielsweise sind Software-Pakete denkbar, die Berechnungen in einem 10ms- oder 20ms- oder 100ms-Raster benötigen.
-
Besonders vorteilhaft ist, wenn die Safety-Möglichkeit Informationen zu einer bereitgestellten ASIL-Kategorie, also einer ASIL-Einstufung des Zielsteuergeräts, umfasst.
-
Vorteilhaft ist, wenn die Performance-Möglichkeit Informationen zu einem verfügbaren Speicherplatz und/oder einem bereitgestellten Rechenraster umfasst. Der verfügbare Speicherplatz gibt vorteilhafterweise an, wie viel Speicherplatz das Zielsteuergerät zur Ausführung des Software-Pakets zur Verfügung stellen kann. Das bereitgestellte Rechenraster gibt vorteilhafterweise an, welches Rechenraster das Zielsteuergerät zur sicheren und zuverlässigen Ausführung des Software-Pakets bereitstellen kann. Beispielsweise sind Zielsteuergeräte denkbar, die Berechnungen in einem 10ms- oder 20ms- oder 100ms-Raster ermöglichen.
-
Vorteilhaft ist, wenn die Safety-Möglichkeit durch das Security-Modul bereitgestellt wird. Insbesondere kann die Safety-Möglichkeit in einem Speicher abgelegt sein, der dem Security-Modul, insbesondere einem Hardware Security Modul (HSM), zugewiesen ist und daher vor Manipulation geschützt ist. Eine Speicherung der Safety-Möglichkeit im Speicher des Security-Moduls ist besonders dann vorteilhaft, wenn die Safety-Möglichkeit wenige Informationen umfasst, insbesondere dann, wenn die Safety-Information nur eine ASIL-Kategorie umfasst.
-
Vorteilhaft ist, wenn die Safety-Möglichkeit durch einen Speicher des Zielsteuergeräts bereitgestellt und unter Verwendung des Security-Moduls des Zielsteuergeräts verifiziert wird. Insbesondere kann die Safety-Möglichkeit in einem nicht zusätzlich abgesicherten Speicher des Zielsteuergeräts abgelegt sein. Hierbei kann die Safety-Möglichkeit vorteilhafterweise verschlüsselt vorliegen, wobei die Entschlüsselung mit Hilfe des Security-Moduls erfolgt. Alternativ oder zusätzlich ist vorteilhaft, einen Hashwert über die Safety-Möglichkeit zu bilden und diesen Hashwert in einem Speicher des Security-Moduls abzulegen. Alternativ zur Verwendung eines Hashwertes sind andere Verfahren denkbar, die üblicherweise zur Prüfung einer Vollständigkeit und Unverändertheit von Informationen verwendet werden. Eine Bereitstellung der Safety-Möglichkeit durch einen Speicher des Zielsteuergeräts in Verbindung mit einer Verifikation durch das Security-Modul ist insbesondere dann vorteilhaft, wenn die Safety-Möglichkeit eine Vielzahl von Informationen umfasst und daher viel Speicherplatz benötigt.
-
Besonders vorteilhaft ist, wenn die Performance-Möglichkeit durch den Speicher des Zielsteuergeräts bereitgestellt wird und von dort ohne Involvierung des Security-Moduls des Zielsteuergeräts von der Koordinierungseinheit ausgelesen werden kann. Somit können Ressourcen des Security-Moduls gespart werden.
-
Besonders vorteilhaft lässt sich das erfindungsgemäße Verfahren verwenden, wenn es sich bei dem Software-Paket um eine nomadische Software handelt, also um eine Software, die prinzipiell von unterschiedlichen Steuergeräten ausgeführt werden könnte. Besonders vorteilhaft lässt sich das erfindungsgemäße Verfahren verwenden, um eine nomadische Software Steuergeräten, beispielsweise Zonensteuergeräten in einem Fahrzeug zuzuweisen.
-
Vorteilhafterweise wird das Software-Paket nach der endgültigen Zuweisung an das Zielsteuergerät übermittelt und dort installiert, sodass das Zielsteuergerät das Software-Paket oder eine unter Verwendung des Software-Pakets gebildete Software ausführen kann.
-
Vorteilhafter Weise handelt es sich bei der Koordinierungseinheit um ein Update-Steuergerät, beispielsweise einen OTA-Master oder eine Connectivity-Unit, eines Fahrzeugs.
-
Besonders vorteilhaft ist ein Verfahren zum Zuweisen eines einer Koordinierungseinheit zur Verfügung stehenden Software-Pakets an ein Zielsteuergerät aus einer Vielzahl von Zielsteuergeräten, wobei die Zielsteuergeräte jeweils ein Security-Modul umfassen, wobei dem Software-Paket eine Safety-Anforderung und eine Performance-Anforderung zugeordnet sind, jedem Zielsteuergerät eine Safety-Möglichkeit und eine Performance-Möglichkeit zugeordnet sind, die Koordinierungseinheit die Performance-Anforderung des Software-Pakets mit den Performance-Möglichkeiten der Zielsteuergeräte vergleicht und das Software-Paket einem vorgewählten Zielsteuergerät vorläufig zuweist, dessen Performance-Möglichkeit der Performance-Anforderung des Software-Pakets entspricht, wobei das vorgewählte Zielsteuergerät unter Verwendung des eigenen Security-Moduls die Safety-Anforderung des Software-Pakets mit der eigenen Safety-Möglichkeit vergleicht und das Software-Paket endgültig dem vorgewählten Zielsteuergerät zugewiesen wird, wenn die Safety-Möglichkeit des vorgewählten Zielsteuergeräts der Safety-Anforderung des Software-Pakets entspricht. Mit anderen Worten wird das Zielsteuergerät, dem das Softwarepaket vorläufig zugewiesen wird durch diese vorläufige Zuweisung zum vorgewählten Zielsteuergerät.
-
Es versteht sich von selbst, dass das vorstehend beschriebene Verfahren zum Zuweisen eines Software-Pakets an ein Zielsteuergeräte aus einer Vielzahl von Zielsteuergeräten mit allen vorteilhaften Weiterbildung des ebenfalls beschriebenen Verfahrens zum Zuweisen eines Software-Pakets an ein Zielsteuergerät kombiniert werden kann.
-
Nachfolgend werden Ausführungsbeispiele der Erfindung vorgestellt. Dabei zeigen:
-
Kurze Beschreibung der Zeichnungen
-
- 1 Eine schematische Darstellung einer Fahrzeugs;
- 2 eine schematische Darstellung eines Ablaufs eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens.
-
1 zeigt eine schematische Darstellung eines Fahrzeugs (10). Das Fahrzeug (10) umfasst eine Koordinierungseinheit (12), die eingerichtet ist, Software-Pakete z.B. von einem fahrzeugexternen Server (20) zu empfangen und Zielsteuergeräten (14, 16) zuzuordnen. Das Fahrzeug umfasst außerdem Zielsteuergeräte (14, 16), die wiederum jeweils ein Security-Modul (15, 17), insbesondere ein Hardware Security-Modul (HSM), umfassen. Die Koordinierungseinheit steht beispielsweise über ein Bussystem mit den Zielsteuergeräten (14, 16) in Kommunikationsverbindung, sodass Nachrichten zwischen der Koordinierungseinheit (12) und den Zielsteuergeräten (14, 16) ausgetauscht und Software-Pakete von der Koordinierungseinheit (12) an die Zielsteuergeräte (14, 16) übertragen werden können. Bei der Koordinierungseinheit (12) kann es sich insbesondere um einen OTA-Master, also ein Steuergerät zur Koordinierung von Software-Updates über eine Funkschnittstelle oder einen Fahrzeugführungsrechner (VCU) handeln. Bei den Zielsteuergeräten (14, 16) kann es sich beispielsweise um Zonensteuergeräte handeln.
-
Die Zielsteuergeräte (14, 16) umfassen jeweils einen nicht näher abgesicherten Speicher, und ein Security-Modul (15, 17). Die Security-Module wiederum umfassen jeweils einen abgesicherten Speicher.
-
2 zeigt eine schematische Darstellung eines Ablaufs eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens. Das Ausführungsbeispiel des erfindungsgemäßen Verfahrens startet mit Schritt 100. Anschließend wird Schritt 110 ausgeführt.
-
In Schritt 110 empfängt die Koordinierungseinheit (12) ein Software-Paket von dem fahrzeugexternen Server (20). Zusätzlich zu dem Software-Paket empfängt die Koordinierungseinheit (12) eine Safety-Anforderung für das Software-Paket, in der Information zu einer ASIL-Kategorie enthalten sind, und eine Performance-Anforderung für das Software-Paket, in der Informationen zu einem benötigten Speicherplatz und einem benötigten Rechenraster enthalten sind. Die ASIL-Kategorie des Software-Pakets entspricht dabei insbesondere der ASIL-Kategorie eines Steuergeräts, das das Software-Paket oder eine unter Verwendung des Software-Pakets gebildete Software ausführen darf. Im Anschluss an Schritt 110 folgt Schritt 120.
-
In Schritt 120 fragt die Koordinierungseinheit (12) die Performance-Möglichkeiten der Zielsteuergeräte (14, 16) ab. Bei der Performance-Möglichkeit eines Zielsteuergeräts kann es sich insbesondere um einen Datensatz handeln, der Informationen zum verfügbaren Speicherplatz und/oder zu bereitgestellten Rechenrastern des Zielsteuergeräts umfasst. Insbesondere kann hierfür eine entsprechende Information aus dem Speicher der Zielsteuergeräte (14, 16) ausgelesen werden. Im Anschluss an Schritt 120 folgt Schritt 130.
-
In Schritt 130 vergleicht die Koordinierungseinheit (12) die Performance-Anforderung des Software-Pakets mit den Performance-Möglichkeiten der Zielsteuergeräte (14, 16) und weist das Software-Paket einem Zielsteuergerät (14, 16) vorläufig zu, dessen Performance-Möglichkeit zu der Performance-Anforderung des Software-Pakets passt. Umfasst die Performance-Anforderung des Software-Pakets beispielsweise ein Rechenraster von 20ms und 500kB freien Speicher, so wird das Software-Paket nur einem solchen Zielsteuergerät (14, 16) vorläufig zugewiesen, das diese Anforderungen mindestens erfüllt. Umfasst die Performance-Möglichkeit des Zielsteuergeräts 14 beispielsweise Rechenraster von 10ms und 20ms sowie einen verfügbaren Speicherplatz von 2MB, während die Performance-Möglichkeit des Zielsteuergeräts 16 nur einen verfügbaren Speicherplatz von 200kB ausweist, so wird das Software-Paket dem Zielsteuergerät 14 vorläufig zugewiesen. Das Zielsteuergerät, dem das Software-Paket vorläufig zugewiesen wird, ist nunmehr das vorgewählte Zielsteuergerät. Im Anschluss an Schritt 130 folgt Schritt 140.
-
In Schritt 140 wird eine Safety-Anforderung des Software-Pakets mit einer Safety-Möglichkeit des vorgewählten Zielsteuergeräts unter Verwendung des Security-Moduls des vorgewählten Zielsterugeräts verglichen. Bevorzugt erfolgt dieser Vergleich durch das vorgewählte Zielsteuergerät. Die Safety-Möglichkeit des vorgewählten Zielsteuergeräts kann entweder aus dem Speicher des Security-Moduls oder aus dem Speicher des vorgewählten Zielsteuergeräts ausgelesen und unter Verwendung des Security-Moduls des vorgewählten Zielsteuergeräts verifiziert werden. Entspricht die Safety-Möglichkeit des vorgewählten Zielsteuergeräts der Safety-Anforderung des Software-Pakets, so wird das Software-Paket endgültig dem vorgewählten Zielsteuergerät zugewiesen. Die endgültige Zuweisung kann durch das vorgewählte Zielsteuergerät oder die Koordinierungseinheit (12) erfolgen. Falls der Vergleich der Safety-Möglichkeit des vorgewählten Zielsteuergeräts mit der Safety-Anforderung des Software-Pakets ergibt, dass eine endgültige Zuweisung nicht möglich ist, weil die Safety-Möglichkeit nicht der Safety-Anforderung entspricht, wird erneut Schritt 130 ausgeführt, wobei eine erneute vorläufige Zuordnung zu dem Zielsteuergerät, dessen Safety-Möglichkeit nicht der Safety-Anforderung entsprochen hat, unterdrückt und somit verhindert wird. Falls das Software-Paket dem vorgewählte Zielsteuergerät endgültig zugewiesen wird, folgt Schritt 150 im Anschluss an Schritt 140
-
In Schritt 150 wird das Software-Paket an das in Schritt 140 endgültig zugewiesene Zielsteuergerät (14, 16) übertragen, dort installiert und im Anschluss ausgeführt. Alternativ wird eine Software ausgeführt, die unter Verwendung des Software-Pakets gebildet wurde.