-
Die vorliegende Erfindung betrifft ein Verfahren, ein Fortbewegungsmittel sowie einen Server zur Absicherung eines Softwareupdates eines Steuergerätes eines Fortbewegungsmittels. Insbesondere betrifft die vorliegende Erfindung eine in Anbetracht einer Hardwarekonfiguration größtmögliche Sicherheit beim Aktualisieren von Softwarebestandteilen von Steuergeräten.
-
Moderne Fortbewegungsmittel weisen erhebliche Datenmengen auf, welche mitunter zu verändern bzw. zu ergänzen sind, wenn Komponenten zu Sicherheitszwecken oder funktionalen Ergänzungen sowie für Bugfixes zu aktualisieren sind. Heutzutage ist es nur möglich/erlaubt, in kontrollierten Umgebungen (z.B. autorisierte Fachwerkstatt) eine Fahrzeugprogrammierung von sicherheitsrelevanten (ASIL-relevanten) Umfängen durchzuführen. Nur nichtsicherheitskritische Umfänge können derzeit über ein entsprechendes Back-End in einem auf der Straße befindlichen Fahrzeug programmiert/geupdatet werden. Ein Nachteil des oben genannten Standes der Technik besteht darin, dass Updates der Software bei sicherheitsrelevanten-ASIL-relevanten Umfängen nur unter kontrollierten Bedingungen durchgeführt werden dürfen. Insbesondere sind hierzu dezidierte Rechenmaschinen/Laptops zu verwenden und eine Kabelverbindung (z.B. über eine OBD-Buchse) muss zur Datenübertragung hergestellt werden. Somit sind keine Funktionsverbesserungen von ASIL-relevanten Funktionen über ein zur Verfügung stehendes Back-End möglich. Sind Sicherheitslücken in bestehenden Fahrzeugen bekannt geworden, müssen Rückrufe organisiert werden, was aufwendig und teuer ist. Außerdem ist es nicht möglich, neue Funktionalitäten, welche ASIL-relevant sind, in ein Fahrzeug zu laden, welches sich auf der Straße/„im Feld“ befindet. Somit ist es auch nicht möglich, dass der Kunde im Nachgang den Sonderausstattungsumfang bei sicherheitsrelevanten/ASIL-relevanten Funktionen (z.B. Fahrerassistenzsysteme) erhöht. Sofern sicherheitsrelevante Umfänge in auf der Straße befindliche Fahrzeuge über ein Back-End geladen werden sollen, müsste die E/E-Infrastruktur des gesamten Fahrzeugs ASIL-befähigt sein, was sehr aufwendig und teuer ist. Dies ist insbesondere der Tatsache geschuldet, dass zur Absicherung der Softwarestände auf verschiedenen Steuergeräten eine komplette Überprüfung der tatsächlich installierten Daten erforderlich ist. Zudem ist für ASIL-relevante Hardware eine abgesicherte Kommunikation und zur redundanten Sicherung von Daten die doppelte Speicherkapazität erforderlich. Insbesondere für komplexe Head Unit-Steuergeräte ist eine derartige Architektur derzeit nicht wirtschaftlich. Es ist eine Aufgabe der vorliegenden Erfindung, den vorstehend genannten Bedarf zu stillen.
-
Die vorstehend genannte Aufgabe wird erfindungsgemäß durch ein Verfahren zur Absicherung eines Softwareupdates eines Steuergerätes eines Fortbewegungsmittels gelöst. Das Softwareupdate kann als Aktualisierung eines Betriebssystems des Steuergerätes erfolgen. Alternativ oder zusätzlich können einzelne Funktionen oder eine Funktionsvielzahl durch das Softwareupdate geändert/aktualisiert werden. Das Steuergerät befindet sich während der Aktualisierung seiner Software in das Bordnetz des Fortbewegungsmittels eingebunden. Zur Absicherung des Softwareupdates wird in einem ersten Schritt ein einen aktuellen Softwarestand des Steuergerätes repräsentierender erster Datensatz durch das Fortbewegungsmittel an einen Server (auch „Back-End“) gesendet. Das Senden kann drahtgebunden und/oder drahtlos erfolgen. Der erste Datensatz kann beispielsweise eine Steuergeräte-Verbau-Tabelle (SVT) umfassen, welche die Softwarestände mehrerer Steuergeräte des Fahrzeugbordnetzes zumindest jedoch des oben genannten Steuergerätes kennzeichnet. Der Server kann insbesondere ein stationärer Server sein, welcher durch einen Hersteller des Fortbewegungsmittels und/oder durch ihn beauftragte Servicegesellschaften betrieben wird. Insbesondere kann eine Autorisierung des Fortbewegungsmittels zur Kommunikation mit dem Server im Fortbewegungsmittel vordefiniert sein. Mit anderen Worten kann eine Kennung des Fortbewegungsmittels durch den Server automatisch abgefragt werden, bevor der Server in einem nächsten Schritt den ersten Datensatz empfängt und speichert. Hierdurch wird dem Server mitgeteilt, welche Daten im Bordnetz des Fortbewegungsmittels vorliegen. Insbesondere wird dem Server mitgeteilt, welche Stände die Datenpakete des Bordnetzes des Fortbewegungsmittels aufweisen. Zumindest jedoch erhält der Server Informationen, welche ihn in die Lage versetzen, zu erkennen, ob eine Aktualisierung zumindest eines Steuergerätes des Bordnetzes des Fortbewegungsmittels möglich und/oder sinnvoll erscheint. Dies kann der Server anhand des ersten Datensatzes ermitteln, in welchen beispielsweise die oben genannte SVT repräsentiert, insbesondere enthalten, ist. In Abhängigkeit des ersten Datensatzes kann der Server nun einen zweiten Datensatz erstellen, welcher einen Soll-Software-Stand des Steuergerätes repräsentiert. Insbesondere kann die Software im zweiten Datensatz enthalten sein. Alternativ oder zusätzlich kann die Art und Weise, in welcher ein Softwaredatensatz durch das Steuergerät oder durch die Steuergeräte zur Aktualisierung zu verwenden ist, durch den zweiten Datensatz gekennzeichnet werden. Der zweite Datensatz kann daher eine Soll-SVT umfassen, zumindest jedoch einen Hash-Wert für die aktualisierte SVT umfassen. Anschließend wird der zweite Datensatz an das Fortbewegungsmittel gesendet, um die Aktualisierung des Steuergerätes entsprechend dem zweiten Datensatz vorzunehmen. Der zweite Datensatz kann durch den Server an das Fortbewegungsmittel gesendet werden. Insbesondere können auch der erste Datensatz und/oder ein Softwarepaket zur Aktualisierung des Steuergerätes an das Fortbewegungsmittel gesendet werden. Mittels des ersten Datensatzes kann das Fortbewegungsmittel überprüfen, ob der zunächst an den Server gesandte erste Datensatz mit dem empfangenen ersten Datensatz übereinstimmt. Auf diese Weise kann die Kommunikation zwischen dem Fortbewegungsmittel und dem Server auf eine einfache Art und Weise überprüft werden. Wird beim Abgleich des gesendeten ersten Datensatzes mit dem empfangenen Datensatz im Steuergerät festgestellt, dass keine Unterschiede bestehen, kann von einer hinreichend sicheren Übertragung auch des zweiten Datensatzes und/oder des Softwarepaketes ausgegangen werden. Ergeben sich Unterschiede zwischen dem vom Steuergerät gesendeten ersten Datensatz und dem vom Steuergerät empfangenen ersten Datensatz, kann das oben genannte Verfahren wiederholt werden, um sicherzugehen, dass der vom Server empfangene erste Datensatz keine Übertragungsfehler aufweist und auch der vom Steuergerät empfangene erste Datensatz keinen Übertragungsfehler aufweist.
-
Anders ausgedrückt besteht ein Kerngedanke der vorliegenden Erfindung darin, dass zunächst aus den einzelnen Steuergeräte-Verbau-Kennungen (SVK) durch das erste Steuergerät (z.B. die Media Graphic Unit, MGU) eine tatsächliche SVT (SVT_Ist) gebildet wird, die an das Back-End/den Server gesendet wird. Das Back-End überprüft nun, ob für die bestehende Hardware-Konfiguration ein Softwareupdate vorhanden ist. Der aktualisierte Softwarestand wird als SVT Soll zurück an das Steuergerät gesendet. Zusätzlich können die Soll- und Ist-Datensätze/Hash-Werte mit jeweils eindeutigen Kennzeichnungen versehen und an das Steuergerät geschickt werden. Hierbei können zyklische Redundanzprüfungen (CRC) über die Datensätze gebildet werden. Die Kennzeichnungen und die CRCs dienen dazu, das Zwischenspeichern der sicherheitsrelevanten Daten auf einem Steuergerät zu ermöglichen, welches nicht ASIL-konform ist. Derartige Steuergeräte werden auch als QM (Qualitätsmanagement)- abgesicherte Steuergeräte bezeichnet. Dadurch können durch ein Steuergerät, welches beispielsweise als Body Domain Controller ausgestaltet ist, alle sicherheitsrelevanten Fehler des nicht-ASIL-konformen Steuergerätes erkannt werden. Letzteres kann beispielsweise Hashwerte als Ist- und Soll-Datensätze speichern, die Steuergeräte des Fahrzeuginformationsbordnetzes flashen und optional anschließend die Soll-SVT löschen. Anschließend wird eine aktuelle SVT (SVT nach RSU) erstellt und auch ihr Hash-Wert gebildet. Dies erfolgt beispielsweise ohne Kennzeichnung der nach dem Remote Software Update erstellten SVT. Jedoch kann hierbei erneut ein CRC erstellt werden, um auch die Übertragung vom ersten Steuergerät (ASIL-non-konform) zum dritten Steuergerät (ASIL-konform) abzusichern. Die ermittelten Hash-Werte können nun vom ersten Steuergerät (z.B. MGU) an das dritte Steuergerät (z. B. BDC) geschickt werden und das BDC kann einen Vergleich der Hash-Werte durchführen und überprüfen, ob die Kennzeichnungen und CRCs in Ordnung sind. Auf diese Weise kann sichergestellt werden, dass alle Steuergeräte des Fahrzeugbordnetzes auf dem richtigen Stand sind, ohne dass die geflashten Daten selbst überprüft werden müssen. Da im Stand der Technik stets eine kabelgebundene Überprüfung der geflashten Daten selbst erforderlich war, konnte eine Aktualisierung der ASIL-relevanten Hardware nicht als Remote Software Update (RSU) erfolgen. Auf diese Weise trägt die vorliegende Erfindung zur Flexibilität einer Funktionsmehrung und/oder Softwareaktualisierung der Hardware eines Steuergerätebordnetzes bei. Daher wird eine Absicherung der Datenversion ohne konkrete Überprüfung der geflashten Daten ermöglicht. Zusätzlich wird ein nicht-ASIL-konformes Steuergerät in einer sicherheitsrelevanten Übertragungskette benutzt und dennoch können alle sicherheitsrelevanten Fehler im dritten Steuergerät erkannt werden.
-
Die im Back-End-Server erstellten Datenpakete können in einem gemeinsamen Datenpaket zusammengefasst werden, über welches eine gemeinsame Checksumme gebildet und diese an das Fortbewegungsmittel gesendet wird. Auf diese Weise können sowohl die vom ersten Steuergerät gesendeten und empfangenen ersten Datensätze als auch der korrekte Empfang des zweiten Datensatzes vom Steuergerät verifiziert werden.
-
Um den Aufwand für die Datenkommunikation/den Datenverkehr möglichst gering zu halten, kann der erste Datensatz einen Hash-Wert für eine Steuergeräte-Verbau-Tabelle darstellen. Die Übertragung eines Hash-Wertes ist mit einem geringeren zu transferierenden Datenvolumen verbunden und kann daher den erfindungsgemäßen Prozess beschleunigen.
-
Der vom Server an das Fortbewegungsmittel gesandte erste Datensatz sowie der zweite Datensatz und insbesondere auch das Softwarepaket können in vordefinierter Weise gekennzeichnet werden, um dem Fortbewegungsmittel ihre jeweilige Identifikation zu ermöglichen. Mit anderen Worten werden der erste Datensatz, der zweite Datensatz und das Softwarepaket vom Server in einer Art und Weise gekennzeichnet, welche dem Bordnetz des Fortbewegungsmittels, insbesondere dem Steuergerät bekannt ist.
-
Sämtliche zwischen dem Steuergerät und dem Server bzw. zwischen dem Server und dem Steuergerät auszutauschende Datensätze können einer zyklischen Redundanzprüfung (CRC) unterzogen werden, um auf diese Weise eine bestmögliche Erkennung von Übertragungsfehlern sicherzustellen.
-
Um eine weitreichende Aktualisierung der Software innerhalb des Fahrzeugbordnetzes mittels des ersten Steuergerätes vornehmen zu können, kann der erste Datensatz neben dem zweiten Datensatz durch das Steuergerät gespeichert werden. Anschließend können einzelne (insbesondere sämtliche) Steuergeräte des Fortbewegungsmittels durch das erste Steuergerät geflasht werden. Auf diese Weise kann die hohe Rechenleistung des ersten Steuergerätes verwendet werden, während im Stand der Technik stets ein externes Datenverarbeitungsgerät zum Flashen der Steuergeräte des Fortbewegungsmittels erforderlich war. Erfindungsgemäß kann dieser Prozess sogar von einem nicht-ASIL-konformen ersten Steuergerät durchgeführt werden, wodurch eine vereinfachte Hardwarearchitektur und eine kostengünstigere Hardware verwendet werden können.
-
Anschließend kann durch das Steuergerät die Software der geflashten weiteren Steuergeräte abgefragt werden. Mit anderen Worten kann eine Kennung der aktualisierten Softwarestände der geflashten weiteren Steuergeräte abgefragt und in Abhängigkeit von Antworten der weiteren Steuergeräte ein dritter Datensatz erstellt werden. Der dritte Datensatz repräsentiert einen tatsächlichen (neuen) Software-Stand des Steuergerätes. Dieser kann beispielsweise mit dem zweiten Datensatz verglichen werden, welcher den Soll-Software-Stand des Steuergerätes repräsentiert. Ergibt der Abgleich des zweiten Datensatzes mit dem dritten Datensatz einen Unterschied, ist ein ordnungsgemäßer Aktualisierungsvorgang der Software des Steuergerätes fehlgeschlagen. Ergibt der Abgleich eine Übereinstimmung des zweiten Datensatzes mit dem dritten Datensatz, ist die Software erfolgreich aktualisiert worden.
-
Weiter bevorzugt kann ein Hashwert für den dritten Datensatz erstellt werden. Anschließend kann ein jeweiliger Hashwert für den ersten Datensatz, den zweiten Datensatz und den dritten Datensatz an ein zweites Steuergerät (z.B. Body Domain Controller, BDC) des Fortbewegungsmittels gesendet werden. Die Hashwerte repräsentieren einen Prüfwert, mittels dessen die Datensätze miteinander verglichen und auf Integrität geprüft werden können. Insbesondere kann in einem ersten Schritt geprüft werden, ob der erste Datensatz als „bisheriger Datensatz“ und/oder der zweite Datensatz als „Soll-Datensatz“ und/oder der dritte Datensatz als „unbestimmt“ klassifiziert/benannt ist. Der dritte Datensatz kann insbesondere deshalb als „unbestimmt“ verstanden werden, da er vom nicht-ASIL-konformen ersten Steuergerät kein entsprechender Hash-Wert zugeordnet werden kann. Sofern die obige Klassifizierung des ersten, des zweiten und des dritten Datensatzes erfolgreich ist, kann in einem nächsten Schritt festgestellt werden, dass das Softwarepaket erfolgreich empfangen und/oder installiert wurde. Ist dies hingegen nicht der Fall, kann in einem weiteren Schritt verhindert werden, dass das Fortbewegungsmittel in Betrieb genommen bzw. für eine Weiterfahrt verwendet werden kann.
-
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Fortbewegungsmittel vorgeschlagen, welches gemäß dem oben genannten Verfahren hinsichtlich einer Softwareaktualisierung abgesichert werden kann. Das Fortbewegungsmittel umfasst ein Steuergerät und eine Sendeempfangseinrichtung. Das Steuergerät kann das zu aktualisierende Steuergerät sein. Die Sendeempfangseinrichtung kann für die Kommunikation mit dem Server verwendet werden. Sie ist eingerichtet, einen ersten Datensatz an einen Server zu senden, welcher einen aktuellen Software-Stand des Steuergerätes des Fortbewegungsmittels repräsentiert. Nachdem der Server entsprechend dem oben genannten Verfahren den ersten Datensatz empfangen hat, kann er den ersten Datensatz speichern, die Notwendigkeit eines Softwareupdates des Steuergerätes des Fortbewegungsmittels ermitteln und einen zweiten Datensatz erstellen, welcher einen Soll-Softwarestand des Steuergerätes repräsentiert. Dies erfolgt in Abhängigkeit des ersten Datensatzes. Insbesondere kann der Server einen Hash-Wert für die durch den ersten Datensatz repräsentierte aktualisierte SVT erstellen. Anschließend sendet der Server einen zweiten Datensatz und ein Softwarepaket zur Aktualisierung des Steuergerätes entsprechend dem zweiten Datensatz an das Fortbewegungsmittel. Die Sendeempfangseinheit empfängt den zweiten Datensatz, das Softwarepaket und insbesondere auch den ersten Datensatz, wodurch das Fortbewegungsmittel in die Lage versetzt wird, die Merkmale, Merkmalskombinationen und Vorteile des oben genannten Verfahrens (anteilig) zu verwirklichen. Mit anderen Worten ist das Fortbewegungsmittel eingerichtet, als Fortbewegungsmittel in einem erfindungsgemäßen Verfahren verwendet zu werden.
-
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Server zur Absicherung eines Softwareupdates eines Steuergerätes eines Fortbewegungsmittels vorgeschlagen. Der Server umfasst eine Auswerteeinheit, ein Speichermittel und eine Sendeempfangseinrichtung. Die Auswerteeinheit kann als programmierbarer Prozessor, als Mikrocontroller o.ä. ausgestaltet sein. Die Sendeempfangseinrichtung kann eine drahtlos und/oder drahtgebunden operierende Kommunikationseinrichtung umfassen. Sie ist eingerichtet, einen ersten Datensatz vom Fortbewegungsmittel zu empfangen, welcher einen aktuellen Softwarestand des Steuergerätes bzw. des Bordnetzes des Fortbewegungsmittels repräsentiert. Die Auswerteeinheit des Servers ist eingerichtet, den ersten Datensatz im Speichermittel zu speichern, zu ermitteln, dass ein Softwareupdate des Steuergerätes des Fortbewegungsmittels zu erfolgen hat und einen zweiten Datensatz in Abhängigkeit des ersten Datensatzes zu erstellen, welcher einen Soll-Software-Stand des Steuergerätes des Fortbewegungsmittels repräsentiert. Der zweite Datensatz kann auch als Soll-SVT bzw. als deren Hash-Wert verstanden werden. Die Sendempfangseinrichtung ist weiter eingerichtet, den zweiten Datensatz und ein Softwarepaket zur Aktualisierung des Steuergerätes entsprechend dem zweiten Datensatz an das Fortbewegungsmittel zu senden. Hierbei kann auch der erste Datensatz bzw. eine Kopie desselben an das Fortbewegungsmittel gesendet werden, damit die ordnungsgemäße Kommunikation durch einen Vergleich des gesendeten ersten Datensatzes und des empfangenen ersten Datensatzes durch das Fortbewegungsmittel geprüft werden kann.
-
Weitere Einzelheiten, Merkmale und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung und den Figuren. Es zeigen:
- 1 eine schematische Darstellung eines Ausführungsbeispiels eines erfindungsgemäßen Fortbewegungsmittels in der Kommunikation mit einem Ausführungsbeispiel eines erfindungsgemäßen Servers bei der Ausführung eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens zur Absicherung eines Softwareupdates und
- 2 ein Flussdiagramm veranschaulichend Schritte eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens zur Absicherung eines Softwareupdates.
-
1 zeigt einen PKW 10 als Ausführungsbeispiel eines erfindungsgemäßen Fortbewegungsmittels, welcher über eine mit einer Antenne 6 verbundene Sendeempfangseinrichtung 4 mit einem Funkturm 7 zu kommunizieren im Stande ist. Die Sendeempfangseinrichtung 4 ist mit einem ersten Steuergerät in Form einer Media-Graphic-Unit (MGU) 1 informationstechnisch verbunden, welche ihrerseits mit einem Datenspeicher 5 verbunden ist. Zusätzlich verfügt die MGU 1 über leitungsgebundene Informationskanäle zu ASIL-konformen zweiten Steuergeräten in Form eines Body Domain Controllers 2 bzw. eines weiteren Steuergerätes 3. Die nicht ASIL-konforme MGU 1 kann zur Aktualisierung der Steuergeräte 2, 3 entsprechend dem erfindungsgemäßen Verfahren eine aktuelle SVT mit Hilfe der Steuergeräte 2, 3 erstellen und als ersten Datensatz an den Server 20 senden. Der erste Datensatz kann alternativ oder zusätzlich auch als Hash-Wert der aktuellen SVT ausgestaltet sein. Anhand des mittels des Funkturms 7 und der Sendeempfangseinrichtung 8 empfangenen ersten Datensatzes kann die Auswerteeinheit 9 des Servers 20 ermitteln, ob im Speichermittel 11 ein aktuellerer Softwarestand für den PKW 10 verfügbar ist. Sofern dies der Fall ist, ist die Auswerteeinheit 9 des Servers 20 eingerichtet, die oben bereits beschriebenen Schritte auszuführen, auf welche in Verbindung mit 2 genauer eingegangen wird.
-
2 zeigt Schritte eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens zur Absicherung einer Softwareaktualisierung eines Steuergerätes eines Fortbewegungsmittels. In Schritt 100 wird ein erster Datensatz durch ein Fortbewegungsmittel an einen Server gesandt, welcher einen aktuellen Software-Stand des Steuergerätes bzw. sämtlicher Steuergeräte des Fortbewegungsmittels repräsentiert. Mit anderen Worten kann der erste Datensatz als Steuergeräte-Verbau-Tabelle der erfindungsgemäß potenziell zu aktualisierenden Steuergeräte des Informationsbordnetzes des Fortbewegungsmittels verstanden werden. Anschließend wird in Schritt 200 der erste Datensatz vom Server empfangen und in einem Speichermittel desselben gespeichert. In Schritt 300 ermittelt der Server anhand des ersten Datensatzes, dass ein Softwareupdate des Steuergerätes des Fortbewegungsmittels zu erfolgen hat. Anschließend wird in Schritt 400 ein zweiter Datensatz erstellt, welcher in Abhängigkeit des ersten Datensatzes einen Soll-Software-Stand des Steuergerätes repräsentiert. Der zweite Datensatz kann auch als Soll-SVT bzw. als deren Hash-Wert verstanden werden. In Schritt 500 wird anschließend eine zyklische Redundanzprüfung bezüglich des ersten und des zweiten Datensatzes ausgeführt. In Schritt 600 werden der erste Datensatz, der zweite Datensatz und ein Softwarepaket zur Aktualisierung des Steuergerätes, bezüglich dessen ebenfalls eine CRC ausgeführt worden sein kann, von dem Server an das Fortbewegungsmittel gesendet. In Schritt 700 werden der erste Datensatz und der zweite Datensatz durch das Steuergerät des Fortbewegungsmittels gespeichert. In Schritt 800 werden die durch den zweiten Datensatz adressierten Steuergeräte des Fortbewegungsmittels durch das Steuergerät geflasht. Zur Überprüfung, ob die Aktualisierung erfolgreich war, wird anschließend in Schritt 900 von den geflashten weiteren Steuergeräten abgefragt, welche Softwarestände diese nun aufweisen. In Abhängigkeit der Antworten der weiteren Steuergeräte wird in Schritt 1000 ein dritter Datensatz erstellt, welcher einen tatsächlichen Software-Stand des Steuergerätes und der sämtlichen Steuergeräte repräsentiert. Mit anderen Worten wird ein Datensatz erstellt, welcher im Falle eines erfolgreichen Softwareupdates identisch dem zweiten Datensatz ist. Durch einen einfachen Vergleich des dritten Datensatzes mit dem zweiten Datensatz kann auf diese Weise ermittelt werden, ob der Soll-Software-Stand des Fortbewegungsmittels erfolgreich hergestellt wurde. In Schritt 1100 wird ein Hash-Wert für den dritten Datensatz ermittelt und in Schritt 1200 jeweilige Hash-Werte für den ersten, den zweiten und den dritten Datensatz an ein zweites Steuergerät des Fortbewegungsmittels gesendet. Das zweite Steuergerät kann insbesondere ein ASIL-konformes Steuergerät (z.B. ein Body Domain Controller, BDC) sein. In Schritt 1300 wird durch das ASIL-konforme zweite Steuergerät jeder empfangene Datensatz daraufhin geprüft, ob zumindest einer als „alt“ und/oder einer als „soll“ und/oder einer als „unbestimmt“ klassifiziert ist. Wie oben beschrieben kann die vorgenannte Klassifikation für jeweilige Hash-Werte oder jeweilige SVTs entsprechend gelten und in diesem Schritt überprüft werden. Sofern die Prüfung der Datensätze bzw. die Klassifikation der Datensätze erfolgreich vorgenommen wurde, wird in Schritt 1400 festgestellt, dass das Softwarepaket erfolgreich empfangen und installiert wurde. Andernfalls wird in Schritt 1500 das Gegenteil festgestellt und eine Weiterfahrt des Fortbewegungsmittels unterbunden. Zumindest kann ein Funktionsumfang des Fortbewegungsmittels, welcher aufgrund der fehlerhaften Softwareaktualisierung nachteilige Auswirkungen haben könnte, eingeschränkt oder deaktiviert.
-
Auf diese Weise kann trotz der Tatsache, dass an der Aktualisierung eines ASIL-konformen Steuergerätes ein ASIL-non-konformes Steuergerät beteiligt war, eine den Sicherheitserfordernissen ASIL-konformer Steuergeräte gerecht werdendes Absichern von Softwareaktualisierungen vorgenommen werden.
-
Bezugszeichenliste
-
- 1
- (QM- bzw.- ASIL-non-konformes) Steuergerät
- 2
- zweites Steuergerät/BDC
- 3
- weiteres Steuergerät
- 4
- Sendeempfangseinrichtung
- 5
- Datenspeicher
- 6
- Antenne
- 7
- Funkturm
- 8
- Sendeempfangseinrichtung
- 9
- Auswerteeinheit
- 10
- PKW
- 11
- Datenspeicher
- 20
- Server
- 100-1500
- Verfahrensschritte
