DE102022204862A1

DE102022204862A1 - Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten

Info

Publication number: DE102022204862A1
Application number: DE102022204862.8A
Authority: DE
Inventors: Dirk Bangel; Indrasen Raghupatruni; Peter Busch; Antonia Reiter
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-05-17
Filing date: 2022-05-17
Publication date: 2023-11-23
Also published as: WO2023222794A1

Abstract

Ein Aspekt der vorliegenden Offenbarung betrifft ein Computer-implementiertes Verfahren für ein vertrauenswürdiges Update einer Steuersoftware eines Fahrzeugs auf Basis von Fahrzeugfelddaten. Das Verfahren umfasst Empfangen von Fahrzeugfelddaten, die im Betrieb mindestens eines Fahrzeugs gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs und/oder eines Nutzers des Fahrzeugs versehen sind in einem zentralen System. Das Verfahren umfasst weiter Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, wenn das Fahrzeug und/oder des Nutzes mittels der digitalen Signatur als valider Sender von Fahrzeugfelddaten erkannt wurde und Verarbeiten des Datenkorpus des zentralen Systems, um Trainingsdaten für ein Maschinenlern-Modells zu erzeugen, Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung und Signieren des trainierten Maschinenlern-Modells mit einer digitalen Signatur der Trainingsumgebung. Das Verfahren umfasst weiterhin Bereitstellen des trainierten Maschinenlern-Modells mit der Signatur der Trainingsumgebung für ein Software-Update an ein weiteres Fahrzeug.

Description

Stand der Technik
Die Software (insbesondere Steuersoftware) für Fahrzeuge wird nicht zuletzt durch die fortschreitende Automatisierung der Fahrzeuge immer komplexer. Zudem nehmen Maschinen-Lernsysteme eine immer wichtigere Stellung in der Software für Fahrzeuge ein. An dieser Stelle ist es wünschenswert oder sogar notwendig, die Software der Fahrzeuge im Feld (d.h. im Betrieb) zu aktualisieren. Auf der anderen Seite benötigen die Maschinen-Lernsysteme Trainingsdaten aus dem Feld, um ihre Funktionsfähigkeit zu gewährleisten oder zu verbessern. Wenn die Qualität der Felddaten, die Aufbereitung der Felddaten und/oder des Trainings der Maschinen-Lernsysteme zu wünschen übriglässt, kann das erhebliche Konsequenzen für die Funktionalität der Software (und damit der Fahrzeuge) nach sich ziehen. Daher kann es geboten sein, bezüglich möglicher Datenquellen des Software-Entwicklungszyklus sehr restriktiv vorzugehen. Auf der anderen Seite ist es wünschenswert, möglichst viele Akteure in den Prozess des Sammelns und Aufbereitens der Felddaten zu integrieren, da eine größere Datenmenge und Daten-Diversität häufig zu einem besseren Training der Maschinen-Lernsysteme führt. Diese Anforderungen stellen einen gewissen Widerspruch dar.
Es ist es wünschenswert, Techniken bereitzustellen, die ein sicheres und leistungsfähiges Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten ermöglichen.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-implementiertes Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs auf Basis von Fahrzeugfelddaten. Das Verfahren umfasst Empfangen von Fahrzeugfelddaten, die im Betrieb mindestens eines Fahrzeugs gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs und/oder eines Nutzers des Fahrzeugs versehen sind in einem zentralen System. Das Verfahren umfasst weiter Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, wenn das Fahrzeug und/oder des Nutzes mittels der jeweiligen digitalen Signatur als valider Sender von Fahrzeugfelddaten erkannt wurde und Verarbeiten des Datenkorpus des zentralen Systems, um Trainingsdaten für ein Maschinenlern-Modell zu erzeugen, Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung und Signieren des trainierten Maschinenlern-Modells mit einer digitalen Signatur der Trainingsumgebung. Das Verfahren umfasst weiterhin Bereitstellen des trainierten Maschinenlern-Modells mit der digitalen Signatur der Trainingsumgebung für ein Software-Update an ein weiteres Fahrzeug.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-System, das dazu ausgelegt ist, die Verfahren gemäß dem ersten allgemeinen Aspekt auszuführen.
Die Techniken der ersten und zweiten allgemeinen Aspekte können einen oder mehrere der folgenden Vorteile haben.
Erstens können mittels des Versehens von Daten an verschiedenen Stellen eines Software-Entwicklungszyklus mit digitalen Signaturen die Herkunft der jeweiligen Daten überprüft werden. Insbesondere kann das automatisiert passieren. Damit kann in manchen Fällen sichergestellt werden, dass Fahrzeugfelddaten, trainierte Maschinenlern-Modelle oder Software-Updates für Fahrzeuge aus vertrauenswürdigen Quellen stammen. Das kann letztlich die Leistungsfähigkeit von mit Software-Updates versorgten Fahrzeugen (insbesondere von zumindest teilweise autonomen Fahrzeugen) sicherstellen und/oder verbessern.
Zweitens können durch digitale Signaturen (die in manchen Beispielen mit einem dezentral erzeugten Schlüssel generiert werden) eine Skalierbarkeit und Erweiterbarkeit auf verschiedene Quellen von Daten (z.B. Fahrer oder Organisationen) erreicht werden.
Einige Begriffe werden in der vorliegenden Offenbarung in folgender Weise verwendet: Der Begriff „Fahrzeug“ umfasst jegliche Vorrichtungen, die in Passagiere und/oder Fracht transportieren. Ein Fahrzeug kann ein Kraftfahrzeug (zum Beispiel ein PKW oder ein LKW) sein, aber auch ein Schienenfahrzeug. Allerdings können auch schwimmende und fliegende Vorrichtungen Fahrzeuge sein.
Der Begriff „Nutzer“ umfasst jegliche Person, die mit dem Fahrzeug fährt, von diesem transportiert wird oder seinen Betrieb überwacht. Ein Nutzer kann ein Passagier eines Fahrzeugs (insbesondere ein Fahrer) sein. Ein Nutzer kann sich aber auch außerhalb des Fahrzeugs befinden und dieses beispielsweise Steuern und/oder Überwachen (z.B. während eines Einparkvorgangs oder von einer entfernten Zentrale).
Eine „digitale Signatur“ in der vorliegenden Offenbarung ist Teil eines asymmetrisches Verschlüsselungssystems, bei dem ein Sender mit Hilfe einer geheimen Information (z.B. eines geheimen Signaturschlüssels, auch als geheimer Schlüssel oder Englisch „Private Key“ bezeichnet) zu beliebigen Daten (in der vorliegenden Offenbarung z.B. Fahrzeugfelddaten, Maschinenlern-Modelle oder Software-Updates) ein Datum berechnet, das Signatur genannt wird. Dieses Datum ermöglicht es Dritten, mit Hilfe von öffentlicher Information (z.B. einem Verifikationsschlüssel, auch als „öffentlicher Schlüssel“ oder Englisch „Public Key“ bezeichnet) eine Urheberschaft und/oder Integrität der beliebigen Daten zu prüfen. Um eine mit einem Signaturschlüssel erstellte Signatur einem Urheber zuordnen zu können, muss der zugehörige Verifikationsschlüssel dieser Person zweifelsfrei zugeordnet sein. Eine digitale Signatur kann somit einen Urheber der Daten überprüfbar identifizieren.
„Fahrzeugfelddaten“ (oder auch einfach „Felddaten“) umfassen alle Daten, die im Zusammenhang mit dem Betrieb eines (oder einer Vielzahl) von Fahrzeugen anfallen und die insbesondere zum Auslegen (z.B. Training) von Fahrzeugen oder deren Systemen verwendet werden. Beispielsweise können Fahrzeugfelddaten dazu verwendet werden, entsprechende Betriebsszenarien in einer Simulationsumgebung zum Trainieren von Fahrzeugen (bzw. der darin enthaltenen Systeme) zu erzeugen. „Fahrzeugfelddaten“ sind ein Korpus von Felddaten. In manchen Fällen können die Fahrzeugfelddaten die Felddaten in einer gemäß einem einzigen vorgegebenen Schema strukturierten Form enthalten. Der Korpus von Fahrzeugfelddaten kann jedoch aus verschiedenen Teildatensätzen bestehen, die jeweils unterschiedlich strukturiert sind.
Ein „Cloud-Computing-System“ (deutsch Rechnerwolken-System oder Datenwolken-System) ist eine Infrastruktur, die über ein Netzwerk, beispielsweise über das Internet, verfügbar gemacht wird. Ein „Cloud-Computing-System“ beinhaltet in der Regel Speicherplatz, Rechenleistung und/oder Anwendungssoftware als Dienst (d.h. ein Nutzer kann über das Netzwerk diese Ressourcen nutzen). In anderen Worten ist ein Cloud-Computing-System eine Infrastruktur, die über ein Netzwerk zur Verfügung gestellt werden, ohne dass diese auf dem lokalen System vorhanden / installiert sein müssen. „Cloud-Computing-Systeme“ können verteilte Ressourcen enthalten (z.B. mehrerer Rechnersysteme an verschiedenen Orten. Das Angebot und die Nutzung der Ressourcen des „Cloud-Computing-System“ erfolgt dabei durch technische Schnittstellen und Protokolle, etwa mittels eines Webbrowsers.
Kurzbeschreibung der Figuren

1 zeigt ein beispielhaftes System gemäß der vorliegenden Offenbarung.
2 ist ein Flussdiagramm der Schritte der Techniken der vorliegenden Offenbarung.
3 illustriert das Ausstellen und Überprüfen von digitalen Signaturen der vorliegenden Offenbarung.

Beschreibung
Zunächst werden die Techniken der vorliegenden Offenbarung anhand der 1 und 2 erläutert. Weitere Aspekte der (z.B. mittels dezentral erzeugten Schlüsseln generierten) digitalen Signaturen der vorliegenden Offenbarung werden in der Folge anhand der 3 diskutiert.
1 zeigt ein beispielhaftes System gemäß der vorliegenden Offenbarung. 2 ist ein Flussdiagramm der Schritte der Techniken der vorliegenden Offenbarung.
Das Verfahren umfasst Empfangen 210 von Fahrzeugfelddaten 105, die im Betrieb mindestens eines Fahrzeugs 101 gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 (z.B. eines Fahrers 107 des Fahrzeugs 101) versehen sind in einem zentralen System 104.
In manchen Beispielen kann das Empfangen von Fahrzeugfelddaten 105 über eine Luftschnittstelle (z.B. über einen Mobilfunkkanal) von statten gehen.
Fahrzeugfelddaten 105 können Sensordaten umfassen, die während des Betriebs des Fahrzeugs 101 aufgenommen werden. Die Fahrzeugfelddaten 105 können zum Beispiel als Zeitseriendaten vorliegen. Die Fahrzeugfelddaten 105 können Bilddaten umfassen (z.B. Einzelbild- oder Videobilddaten).
Die Sensordaten können zum Beispiel Kameradaten (z.B. im sichtbaren oder infraroten Spektralbereich), Lidar-Sensordaten, Radar-Sensordaten, Temperatursensor-Daten und/oder Ultraschall-Sensordaten umfassen. Alternativ oder zusätzlich können die Sensordaten Positionsdaten (z.B. GPS-Daten) oder Fahrzeugfelddaten, die einen Betriebszustand des Fahrzeugs beschreiben (z.B. Lenkwinkel, Drehzahl, Betriebsmodus, Beladung etc.), sein. Die Sensordaten können das Umfeld des Fahrzeugs, seinen Innenraum und/oder seinen Betriebszustand charakterisieren. Es ist möglich, dass sich die entsprechenden Sensoren, die die Sensordaten erzeugen, innerhalb des Fahrzeugs befinden (d.h. sich mit diesem und durch dieses bewegen). In anderen Beispielen können die Sensoren sich aber auch außerhalb des Fahrzeugs befinden (z.B. in Infrastrukturkomponenten oder in anderen Fahrzeugen oder Verkehrsteilnehmern). In einem illustrativen Beispiel können die Sensordaten Kameradaten einer Kamera eines autonomen Fahrzeugs sein (z.B. einer in Fahrrichtung gerichteten Kamera). Diese Kameradaten werden fortlaufend verarbeitet (zum Beispiel für das Erstellen eines Umfeldmodells des autonomen Fahrzeugs).
Das Verfahren umfasst weiter Aufnahme 220 der empfangenen Fahrzeugfelddaten 105 in einen Datenkorpus, wenn das Fahrzeug 101 und/oder der Nutzer 107 des Fahrzeugs mittels der jeweiligen digitalen Signatur 102, 103 als valider Sender von Fahrzeugfelddaten 105 erkannt wurde. Auf der anderen Seite können die empfangenen Fahrzeugfelddaten 105 nicht in den Datenkorpus aufgenommen werden, wenn das Fahrzeug 101 und/oder der Nutzer 107 mittels der digitalen Signatur 102, 103 nicht als valider Sender von Fahrzeugfelddaten 105 erkannt wurde. In anderen Beispielen kann das zentrale System 104 in diesem Fall weitere Informationen bei dem Sender der Fahrzeugfelddaten 105 anfragen.
Öffentliche Schlüssel zu den digitalen Signaturen des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 (z.B. eines Fahrers des Fahrzeugs 101) können in einem gemeinsamen Register 108 gespeichert sein.
Prüfen der digitalen Signaturen des Fahrzeugs 102 und/oder eines Nutzers des Fahrzeugs 103 kann das Abfragen eines öffentlichen Schlüssels der jeweiligen Signatur 102, 103 in dem gemeinsamen Register 108 umfassen. In manchen Beispielen kann ein Sender der Fahrzeugfelddaten 105 als valider Sender erachtet werden, wenn die digitale Signatur 102, 103 anhand des jeweiligen öffentlichen Schlüssels aus dem gemeinsamen Register 108 verifiziert werden kann. Ist zu einer digitalen Signatur 102, 103 kein öffentlicher Schlüssel in dem gemeinsamen Register 108 hinterlegt und/oder kann eine digitale Signatur des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 nicht mit dem jeweiligen öffentlichen Schlüssel verifiziert werden, kann ein Sender der Fahrzeugfelddaten 105 nicht als valider Sender erachtet werden.
Die digitalen Signaturen des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 (und auch die weiteren digitalen Signaturen der vorliegenden Offenbarung) können digitale Signaturen sein, die mit einem dezentral erzeugten Schlüssel generiert werden. Zusätzliche Aspekte der dezentral erzeugten Schlüssel und der damit generierten digitalen Signaturen werden weiter unten im Zusammenhang mit 3 diskutiert.
In manchen Beispielen kann das zentrale System 104 ein erstes Cloud-Computing-System sein. In manchen Beispielen kann das erste Cloud-Computing-System einen Cloud-Speicher umfassen, um die Fahrzeugfelddaten 105 zu empfangen und den Datenkorpus zu speichern.
Der Fahrzeugfelddaten 105 können gefiltert und/oder vorverarbeitet werden.
Das Verfahren umfasst weiterhin Verarbeiten 230 des Datenkorpus des zentralen Systems 104, um Trainingsdaten für ein Maschinenlern-Modell zu erzeugen.
Die Schritte des Erzeugens von Trainingsdaten können in manchen Beispielen einen oder mehrere der folgenden Schritte umfassen.
Die Fahrzeugfelddaten 105 können in ein maschinen-lesbares Format gebracht werden (z.B. in ein Eingabeformat für eine Trainingsumgebung für ein Maschinenlern-Modell). Alternativ oder zusätzlich können aus den Fahrzeugfelddaten 105 bestimmte Informationen extrahiert werden (z.B. Stand-Bilddaten oder Sequenzen von Bilddaten und/oder Positionsdaten), die dann weiterverarbeitet werden. Weiter alternativ oder zusätzlich können die Fahrzeugfelddaten 105 (oder daraus extrahierte Informationen) mit Labels 111 versehen werden (z.B. um das Trainieren eines Maschinenlern-Modells, bspw. eines Klassifikators, zu ermöglichen).
Die Techniken der vorliegenden Offenbarung umfassen weiterhin Trainieren 240 eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung. Im Beispiel von 1 ist die Trainingsumgebung Teil des zentralen Systems 104. In anderen Beispielen kann die Trainingsumgebung in einem weiteren System angeordnet sein (z.B. eines weiteren Cloud-Computing-Systems oder eines anderen mit den anderen Systemen der vorliegenden Offenbarung vernetzten System).
Das Maschinenlern-Modell kann ein Klassifikator sein. In manchen Beispielen kann der Klassifikator ein Bildklassifikator sein (z.B. zum Erkennen von Objekten im Umfeld oder innerhalb des Fahrzeugs und/oder zum Klassifizieren von Betriebszuständen des Fahrzeugs und/oder seiner Umwelt). Ein Bildklassifikator kann basierend auf Merkmalen von Bilddaten (z.B. Pixelwerten, Position von Kanten usw.) Bilder oder darin enthaltene Objekte klassifizieren (z.B. zur Erkennung bestimmter Objekte in einem Umfeld des Fahrzeugs). In anderen Beispielen kann der Klassifikator andere Datentypen verarbeiten und/oder andere Klassifikationsergebnisse liefern (z.B. bezüglich eines Betriebszustands des Fahrzeugs und/oder einem Zustand des Umfelds des Fahrzeuges). In wieder anderen Beispielen kann das Maschinenlern-Modell ein Regressor oder ein anderer Typ von Modell sein.
Das Maschinenlern-Modell kann ein oder mehrere neuronale Netzwerke umfassen. Das Verfahren umfasst weiterhin das Signieren 250 des trainierten Maschinenlern-Modells 110 mit einer digitalen Signatur der Trainingsumgebung 109. Wenn die Trainingsumgebung Teil des zentralen Systems 104 ist (z.B. Teil eines ersten Cloud-Computing-Systems), kann die digitale Signatur der Trainingsumgebung 109 eine digitale Signatur des zentralen Systems 104 sein.
Die Verfahren gemäß der vorliegenden Offenbarung umfassen weiterhin Bereitstellen 260 des trainierten Maschinenlern-Modells 110 mit der Signatur der Trainingsumgebung 109 für ein Software-Update an ein weiteres Fahrzeug 120. In manchen Beispielen können zudem Labels 111 der zum Training des Maschinenlern-Modells verwendeten Trainingsdaten bereitgestellt werden.
Die Verfahren der vorliegenden Offenbarung können weitere Schritte umfassen.
In manchen Beispielen umfasst Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs das Empfangen des trainierten Maschinenlern-Modells 110 mit der Signatur der Trainingsumgebung 109 in einer Softwaretestumgebung 112. In der Softwaretestumgebung 112 kann die digitale Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) geprüft werden. In einem weiteren Schritt kann das trainierte Maschinenlern-Modells in der Softwaretestumgebung 112 getestet werden, wenn die Trainingsumgebung 104 anhand der digitalen Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) als valider Sender eines trainierten Maschinenlern-Modells erkannt wurde.
In einigen Beispielen befindet sich die Softwaretestumgebung auf einem zweiten Cloud-Computing-System. Das zweite Cloud-Computing -System kann von dem ersten Cloud-Computing-System (auf dem sich das zentrale System und/oder die Trainingsumgebung befinden) unterscheiden (z.B. können das erste Cloud-Computing-System und das zweite Cloud-Computing-System durch unterschiedliche Entitäten verwaltet werden).
Das Prüfen der digitalen Signatur der Trainingsumgebung 109 (z.B. des zentralen Systems) kann das Abfragen eines öffentlichen Schlüssels der digitalen Signatur der Trainingsumgebung 109 in dem gemeinsamen Register 108 umfassen. In manchen Beispielen kann eine Trainingsumgebung 104 als valider Sender erachtet werden, wenn die digitale Signatur der Trainingsumgebung 109 mit einem in dem gemeinsamen Register 108 hinterlegten Schlüssel verifiziert werden kann. Ist in dem gemeinsamen Register 108 kein entsprechender Schlüssel hinterlegt oder kann die digitale Signatur der Trainingsumgebung 109 nicht mit dem hinterlegten öffentlichen Schlüssel verifiziert werden, so kann eine Trainingsumgebung 104 nicht als valider Sender erachtet wird.
In manchen Beispielen kann das trainierte Maschinenlern-Modell 110 in der Softwaretestumgebung 112 in eine Simulationsumgebung integriert werden.
In der Simulationsumgebung oder einer anderen Testumgebung der Softwaretestumgebung 112 kann das trainierten Maschinenlern-Modell 110 getestet werden (z.B. auf eine spezifizierte Funktionalität hin getestet werden).
In manchen Beispielen kann das trainierte Maschinenlern-Modell 110 zusammen mit einer zugehörigen Software-Komponente eines Fahrzeugs in der Softwaretestumgebung 112 getestet werden.
Das Verfahren kann zudem das Signieren des getesteten Maschinenlern-Modells 117 mit einer digitalen Signatur der Softwaretestumgebung 113 umfassen (z.B., wenn in der Softwaretestumgebung 112 eine spezifizierte Funktionalität erkannt wurde). Das Verfahren kann zudem Bereitstellen des getesteten Maschinenlern-Modells 117 mit der digitalen Signatur der Softwaretestumgebung 113 in einem Software-Update an eine Steuereinheit (nicht in 1 gezeigt) des weiteren Fahrzeugs 120 umfassen. In manchen Beispielen kann neben dem getesteten Maschinenlern-Modell 117 (oder alternativ) eine Software-Komponente 116 eines Fahrzeugs als Teil des Software-Updates bereitgestellt werden. Zusätzlich oder alternativ können die Labels 111 als Teil des Software-Updates bereitgestellt werden. Die zusätzlichen (oder alternativen) Daten können ebenfalls mit der digitalen Signatur der Softwaretestumgebung 113 versehen sein.
In manchen Beispielen kann das Verfahren Empfangen des Software-Updates mit einer digitalen Signatur der Softwaretestumgebung 112 und/oder der digitalen Signatur der Trainingsumgebung 109 in einem Fahrzeug 101, 120 (z.B. dem weiteren Fahrzeug 120) umfassen. In dem jeweiligen Fahrzeug 101, 120 kann anhand der digitalen Signatur der Softwaretestumgebung 112 und/oder der digitalen Signatur der Trainingsumgebung 109 geprüft werden, ob die Softwaretestumgebung 112 und/oder die Trainingsumgebung 109 valide Sender von Software-Updates sind.
Das Prüfen digitalen Signatur der Softwaretestumgebung und/oder der digitalen Signatur der Trainingsumgebung 109 kann das Abfragen eines öffentlichen Schlüssels der jeweiligen digitalen Signatur in dem gemeinsamen Register 108 umfassen.
In manchen Beispielen kann eine Trainingsumgebung 104 als valider Sender erachtet werden, wenn mit einem öffentlichen Schlüssel aus dem gemeinsamen Register 108 die Signatur verifiziert werden kann. Ist dagegen in dem gemeinsamen Register 108 kein öffentlicher Schlüssel zu einer Trainingsumgebung hinterlegt und/oder kann die digitale Signatur der Trainingsumgebung 109 nicht mittels eines hinterlegten öffentlichen Schlüssels verifiziert werden, so kann eine Trainingsumgebung 104 nicht als valider Sender erachtet werden.
In gleicher Weise kann eine Softwaretestumgebung 112 als valider Sender erachtet werden, wenn mit einem öffentlichen Schlüssel aus dem gemeinsamen Register 108 die Signatur verifiziert werden kann. Ist dagegen in dem gemeinsamen Register 108 kein öffentlicher Schlüssel zu einer Softwaretestumgebung hinterlegt und/oder kann die digitalen Signatur der Softwaretestumgebung nicht mittels eines hinterlegten öffentlichen Schlüssels verifiziert werden, so kann eine Softwaretestumgebung nicht als valider Sender erachtet werden.
In manchen Beispielen kann das Empfangen des Software-Updates und/oder das Prüfen der digitalen Signatur der Softwaretestumgebung 112 und/oder einer digitalen Signatur der Trainingsumgebung 109 von einem Konnektivitäts-Modul 116 des Fahrzeugs 101, 120 durchgeführt werden.
Wenn Softwaretestumgebung 112 und/oder die Trainingsumgebung 104 als valider Sender von Software-Updates erkannt werden, kann im Fahrzeug 101, 120 ein Aktualisieren einer Software-Komponente des Fahrzeugs anhand des Software-Updates stattfinden. Wenn die Softwaretestumgebung 112 und/oder die Trainingsumgebung 104 nicht als valider Sender von Software-Updates erkannt werden, kann das Fahrzeug 101, 120 ein Aktualisieren einer Software-Komponente des Fahrzeugs anhand des Software-Updates unterbinden.
Das Software-Update kann über eine Luftschnittstelle an das Fahrzeug 101, 120 bereitgestellt werden.
In oben beschriebenen Verfahren kann das Versehen verschiedener Daten mit jeweiligen digitalen Signaturen den verschiedenen beteiligten Systemen ermöglichen, den jeweiligen Sender als valide Datenquelle zu prüfen. Die Prüfungsschritte können dabei automatisiert erfolgen (d.h. ohne Einwirken eines Nutzers). Das kann in manchen Fällen sowohl die Sicherheit als auch die Effizienz des Entwicklungsprozesses von Software-Komponenten für Fahrzeuge (insbesondere für zumindest teilweise autonome Fahrzeuge) verbessern. Zudem (und als Konsequenz) können die Verfahren der vorliegenden Offenbarung leichter skalierbar sein, da durch die Validierbarkeit der Datenquellen auch andere Datenquellen als in Verfahren des Stands der Technik in den Entwicklungsprozess der Software-Komponenten eingebunden werden kann. Das kann wiederum dazu führen, dass eine breitere Datenbasis für die Entwicklung von Software-Komponenten zur Verfügung gestellt wird, was die Qualität von auf maschinellem Lernen beruhenden Software-Komponenten erhöhen kann.
In 1 ist eine einzige Trainingsumgebung und eine einzige Softwaretest-Umgebung 112 gezeigt. In anderen Beispielen kann das System der vorliegenden Offenbarung mehrere Trainingsumgebungen und mehrere Softwaretest-Umgebungen umfassen, die unter Verwendung von jeweiligen digitalen Signaturen Daten austauschen.
In manchen Beispielen kann der Datenkorpus des zentralen Systems 104 verarbeitet werden, um zweite Trainingsdaten für ein zweites Maschinenlern-Modell zu erzeugen. Ein zweites Maschinenlern-Modell kann unter Benutzung der zweiten Trainingsdaten in einer zweiten Trainingsumgebung trainiert werden und das trainierte zweite Maschinenlern-Modell kann mit einer digitalen Signatur der zweiten Trainingsumgebung versehen werden.
Die in Bezug auf die Erzeugung von Trainingsdaten und dem Training des Maschinenlern-Modells weiter oben beschriebenen Schritte können gleichermaßen bei der Erzeugung der zweiten Trainingsdaten und des zweiten Maschinenlern-Modells angewendet werden.
Die erste Trainingsumgebung und die zweite Trainingsumgebung können sich auf verschiedenen Cloud-Computing-Systemen befinden.
Die erste Trainingsumgebung und die zweite Trainingsumgebung können Maschinenlern-Modelle für verschiedene Einsatzzwecke trainieren. Die verschiedenen Einsatzzwecke können eines oder mehrere sein von verschiedenen Fahrzeugtypen und/oder verschiedenen Steuergerättypen und/oder verschiedener Steuersoftware. Das in der zweiten Trainingsumgebung trainierte zweite Maschinenlern-Modell kann wir oben beschreiben an die Softwaretestumgebung 112 und/oder ein Fahrzeug 101, 120 gesendet werden und dort weiterverarbeitet werden.
In manchen Beispielen kann das System ein oder mehrere weitere Trainingsumgebungen umfassen, die wie die erste/zweite Trainingsumgebung Maschinenlern-Modelle trainieren können.
In manchen Beispielen umfasst das System eine zweite Softwaretestumgebung.
Die zweite Softwaretestumgebung kann das trainierte Maschinenlern-Modell 110 (und ggf. Label 111) mit der digitalen Signatur der Trainingsumgebung 109 empfangen. In der zweiten Softwaretestumgebung kann das trainierte Maschinenlern-Modell 110 getestet werden, wenn die Trainingsumgebung anhand der digitalen Signatur der Trainingsumgebung 109 als valider Sender eines trainierten Maschinenlern-Modellen erkannt wird. Zudem kann in der zweiten Softwaretestumgebung das getestete Maschinenlern-Modell mit einer digitalen Signatur der zweiten Softwaretestumgebung signiert werden. Das getestete zweite Maschinenlern-Modells kann mit der digitalen Signatur der zweiten Softwaretestumgebung als Teil eines Software-Updates an eine Steuereinheit eines weiteren Fahrzeugs 120 bereitgestellt werden.
In manchen Beispielen kann neben dem zweiten getesteten Maschinenlern-Modell eine Software-Komponente eines Fahrzeugs als Teil des Software-Updates bereitgestellt werden. Zusätzlich oder alternativ können die Labels als Teil des Software-Updates bereitgestellt werden. Die zusätzlichen Daten können ebenfalls mit der digitalen Signatur der zweiten Softwaretestumgebung versehen sein.
Die erste und zweite Softwaretestumgebungen können Software-Komponenten für verschiedene Einsatzzwecke trainieren. Die verschiedenen Einsatzzwecke können eines oder mehrere sein von verschiedenen Fahrzeugtypen und/oder verschiedenen Steuergerättypen und/oder verschiedener Steuersoftware.
Die erste Softwaretestumgebung 112 und die zweite Softwaretestumgebung können sich auf verschiedenen Cloud-Computing-Systemen befinden.
In manchen Beispielen kann das System ein oder mehrere weitere Softwaretestumgebungen umfassen, die wie die erste/zweite Softwaretestumgebung Maschinenlern-Modelle und Software-Komponente eines Fahrzeugs testen können.
In manchen Beispielen könne die Fahrzeugfelddaten 105 von einem Fahrzeug 101 gesendet werden. Dazu können die Fahrzeugfelddaten 105 mit der mindestens einer digitalen Signatur des Fahrzeugs 102 und/oder des Nutzers des Fahrzeugs 103 signiert werden und die signierten Fahrzeugfelddaten an das zentrale System 104 gesendet werden. Die digitale Signatur des Fahrzeugs 101 kann durch das Fahrzeug 101 selbst oder durch den Nutzer 107 angebracht werden. In manchen Beispielen kann ein Mobilgerät 106 (z.B. ein Smartphone) des Nutzers 107 zum Signieren der Fahrzeugfelddaten 105 verwendet werden. In anderen Beispielen kann eine Komponente des Fahrzeugs (nicht in 1 gezeigt) das Signieren mit der digitalen Signatur des Fahrzeugs 102 durchführen.
In manchen Beispielen kann das Senden der signierten Fahrzeugfelddaten 105 über das Mobilgerät 106 ausgelöst werden. In anderen Beispielen kann das Senden der signierten Fahrzeugfelddaten 105 über eine Benutzerschnittstelle des Fahrzeugs 101, 120 ausgelöst werden.
In den vorangehenden Beispielen wurden die Techniken der vorliegenden Offenbarung anhand von zwei Fahrzeugen erläutert. In manchen Beispielen können Fahrzeugfelddaten von einer Flotte von Fahrzeugen (z.B. mehr als 100 Fahrzeuge oder mehr als 10.000 Fahrzeuge) mit den Techniken der vorliegenden Offenbarung gesammelt werden und/oder Software-Komponenten einer Flotte von Fahrzeugen (z.B. mehr als 100 Fahrzeuge oder mehr als 10.000 Fahrzeuge) mit den Techniken der vorliegenden Offenbarung aktualisiert werden.
In den vorherigen Beispielen wurden digitale Signaturen eines Fahrzeugs, Nutzers des Fahrzeugs, einer Trainingsumgebung und/oder einer Softwaretestumgebung an verschiedenen Stellen eines Software-Entwicklungszyklus angebracht und überprüft. In anderen Beispielen kann diese Abfolge auch variiert werden. So können die digitalen Signaturen von Fahrzeugfelddaten (z.B. von Fahrzeugen und/oder Nutzern) auch an anderen Stellen geprüft werden (z.B. in einer Softwaretestumgebung oder in einem Fahrzeug). In anderen Beispielen können zusätzliche digitale Signaturen zu den oben besprochenen digitalen Signaturen verwendet werden.
3 illustriert das Ausstellen und Nutzen von digitalen Signaturen der vorliegenden Offenbarung.
Wie oben bereits erwähnt, können die digitalen Signaturen der vorliegenden Offenbarung dezentral erzeugte digitale Signaturen sein. Jedes beteiligte System (oder zumindest mehrere der beteiligten Systeme) kann in diesem Fall selbständig Informationen zum Erzeugen von digitalen Signaturen ausstellen (d.h., es gibt keine zentrale Autorität, die Informationen zum Erzeugen aller in der vorliegenden Offenbarung verwendeten digitalen Signaturen ausstellt). Zum Beispiel können Signaturschlüssel der digitalen Signatur des Fahrzeugs und/oder des Nutzers und/oder der digitalen Signatur(en) der Trainingsumgebung(en) und/oder der digitalen Signatur(en) der Softwaretestumgebung(en) (oder andere Informationen zum Erzeugen von digitalen Signaturen) von mindestens zwei unterschiedlichen Stellen erzeugt werden. Insbesondere können Signaturschlüssel (oder andere Informationen zum Erzeugen von digitalen Signaturen) der digitalen Signaturen verschiedener Trainingsumgebungen von verschiedenen Stellen erzeugt werden. Zusätzlich oder alternativ können Signaturschlüssel (oder andere Informationen zum Erzeugen von digitalen Signaturen) der digitalen Signaturen verschiedener Softwaretestumgebungen von verschiedenen Stellen erzeugt werden. In wieder anderen Beispielen können Signaturschlüssel der Signaturen verschiedener Fahrzeuge von verschiedenen Stellen erzeugt werden (z.B. von verschiedenen Organisationen, die die jeweiligen Fahrzeuge betreiben und/oder herstellen).
In 3 sind auf der linken Seite Stellen 301 gezeigt, die Signaturschlüssel für die digitalen Signaturen der vorliegenden Offenbarung ausstellen. Das kann die Erzeugung eines Schlüsselpaars, das einen privaten Schlüssel und einen jeweiligen öffentlichen Schlüssel enthält, umfassen. Der öffentliche Schlüssel kann in dem gemeinsamen Register 108 hinterlegt werden. Der private Schlüssel wird dem jeweiligen Nutzer 302 der Schlüssel bereitgestellt. In 3 ist beispielhaft ein Nutzer eines Fahrzeugs gezeigt, der von einer ersten Stelle einen privaten Schlüssel 303 für die Signatur des Fahrzeugs und von einer zweiten Stelle den privaten Schlüssel 304 für die Signatur des Nutzers erhält. Der Nutzer kann die privaten Schlüssel in einer geeigneten Vorrichtung abspeichern (z.B. einem Mobilgerät).
Schlüssel zu den anderen digitalen Signaturen der vorliegenden Offenbarung (insbesondere der Trainingsumgebung(en) und der Softwaretestumgebung(en)) können in gleicher Weise erzeugt werden.
Das Signieren von Daten mittels der Signatur kann eine Verwendung des jeweiligen privaten Schlüssels 303, 304 geschehen. Zum Beispiel kann der Nutzer 302 eine digitale Signatur des Nutzers anbringen unter Verwendung des privaten Schlüssel 304 für die Signatur des Nutzers (und in gleicher Weise die anderen Systeme der vorliegenden Offenbarung, die digitale Signaturen anbringen).
Die in dieser Weise signierten Daten können durch ein Prüfstelle 305 (z.B. das zentrale Netzwerk, die Softwaretestumgebung und/oder ein Fahrzeug) validiert werden. Dazu kann ein öffentlicher Schlüssel des jeweiligen Signierers in dem gemeinsamen Register 108 abgefragt werden. Falls die digitale Signatur mit dem öffentlichen Schlüssel verifiziert werden kann, kann sie und mithin die signierten Daten als valide eingeschätzt werden.
Die vorliegende Offenbarung betrifft auch ein Computer-System, das dazu ausgelegt ist, die Verfahren gemäß der vorliegenden Offenbarung auszuführen. Wie bereits beschrieben, kann das Computer-System eine große Anzahl von verteilten Knoten umfassen, die mit einem oder mehreren Netzwerken (z.B. dem Internet) verbunden sind. Die einzelnen Knoten können wiederum Cloud-Computing-Systeme enthalten.
In einem Beispiel umfasst das Computer-System ein erstes Cloud-Computing-System, das dazu ausgelegt ist, die Schritte des Empfangens von Fahrzeugfelddaten, der Aufnahme der empfangenen Fahrzeugfelddaten in einen Datenkorpus, des Verarbeitens des Datenkorpus, Trainieren eines Maschinenlern-Modells und des Signierens des trainierten Maschinenlern-Modells auszuführen.
Zusätzlich oder alternativ umfasst das Computer-System ein zweites Cloud-Computing-System, das dazu ausgelegt ist, die Schritte des Prüfens der digitalen Signatur der Trainingsumgebung, des Testen des trainierten Maschinenlern-Modells und das Signieren des validierten Maschinenlern-Modells und/oder einer zugehörigen Software-Komponente und das Bereitstellen des getesteten Maschinenlern-Modells und/oder einer zugehörigen Software-Komponente an eine Steuereinheit eines weiteren Fahrzeugs auszuführen.
Wie bereits besprochen kann das Computer-System weiter ein gemeinsames Register, in dem die öffentlichen Schlüssel zu den digitalen Signaturen gemäß der vorliegenden Offenbarung abgelegt sind. In manchen Beispielen kann das gemeinsame Register 108 ein Block-Chain-Verfahren nutzen, um die öffentlichen Schlüssel der vorliegenden Offenbarung zu speichern. In diesem Fall können mehrere Versionen des gemeinsamen Registers existieren. Zum Beispiel kann das gemeinsame Register 108 ein mehrfach repliziertes und an verschiedenen Orten gespeichertes Register sein, wobei die verschiedenen Replika des Registers 108 synchronisiert sind (d.h. in Form eines „disitributed ledger“). Die verschiedenen Replika des gemeinsamen Registers (108) können zum Beispiel in zumindest manchen der hierin beschriebenen Systeme gespeichert und/oder von diesen verwaltet werden (also nicht von einer einzigen zentralen Stelle).
In manchen Beispielen enthält das Computer-System weiter ein Bordsystem mindesten eines Fahrzeugs (oder Bordsysteme einer Flotte von Fahrzeugen), das (die) dazu ausgelegt ist (sind), die Schritte des Empfangens des Software-Updates, Prüfens, ob die Softwaretestumgebung und/oder die Trainingsumgebung valide Quellen von Software-Updates sind und Aktualisieren einer Software-Komponente des Fahrzeugs anhand des Software-Updates auszuführen.
In manchen Beispielen umfasst das Computer-System weiter ein Mobilgerät, das dazu ausgelegt ist, die Fahrzeugfelddaten, mit der mindestens einen digitalen Signatur eines Fahrzeugs und/oder Nutzers des Fahrzeugs zu versehen. Das Mobilgerät kann weiter dazu ausgelegt sein, die Fahrzeugfelddaten an das zentrale System zu versenden. Die vorliegende Offenbarung betrifft auch ein Computerprogramm, das die Schritte eines der Verfahren der vorliegenden Offenbarung ausführt.
Die vorliegende Offenbarung betrifft auch ein Computer-lesbares Medium oder Signal, das ein Computerprogramm der vorliegenden Offenbarung speichert oder enthält.

Claims

Computer-implementiertes Verfahren für ein vertrauenswürdiges Update einer Software eines Fahrzeugs (101; 120) auf Basis von Fahrzeugfelddaten, umfassend: Empfangen von Fahrzeugfelddaten (105), die im Betrieb mindestens eines Fahrzeugs (101) gesammelt wurden und die mit mindestens einer digitalen Signatur des Fahrzeugs (102) und/oder eines Nutzers des Fahrzeugs (103) versehen sind in einem zentralen System (104); Aufnahme der empfangenen Fahrzeugfelddaten (105) in einen Datenkorpus, wenn das Fahrzeug (101) und/oder der Nutzer (107) mittels der jeweiligen digitalen Signatur (102; 103) als valider Sender von Fahrzeugfelddaten erkannt wurde; Verarbeiten des Datenkorpus des zentralen Systems (104), um Trainingsdaten für ein Maschinenlern-Modells zu erzeugen; Trainieren eines Maschinenlern-Modells unter Benutzung der Trainingsdaten in einer Trainingsumgebung; Signieren des trainierten Maschinenlern-Modells (110) mit einer digitalen Signatur der Trainingsumgebung (109); und Bereitstellen des trainierten Maschinenlern-Modells (110) mit der Signatur der Trainingsumgebung (109) für ein Software-Update an ein weiteres Fahrzeug (120).
Verfahren gemäß Anspruch 1, wobei Bereitstellen des trainierten Maschinen-Lernsystems (110) umfasst: Prüfen der digitalen Signatur des zentralen Systems (109) in einer Softwaretestumgebung (112); Testen des trainierten Maschinenlern-Modells (110) und/oder einer Software-Komponente in der Softwaretestumgebung (112), wenn die Trainingsumgebung anhand der digitalen Signatur des zentralen Systems (109) als valider Sender eines trainierten Maschinenlern-Modells (110) erkannt wurde; Signieren des getesteten Maschinenlern-Modells (117) und/oder der Software-Komponente (115) mit einer digitalen Signatur der Softwaretestumgebung (113); Bereitstellen des getesteten Maschinenlern-Modells (117) und/oder der getesteten Software-Komponente (115) mit der digitalen Signatur der Softwaretestumgebung (113) in dem Software-Update an eine Steuereinheit des weiteren Fahrzeugs (120).
Verfahren gemäß einer der Ansprüche 1 und 2, wobei die digitalen Signaturen (102; 103; 109; 113) mittels dezentral erzeugter Schlüssel generiert sind.
Verfahren gemäß Anspruch 3, wobei Schlüssel der digitalen Signatur des Fahrzeugs (102) und/oder des Nutzers (103) und/oder der digitalen Signatur der Trainingsumgebung (109) und/oder der digitalen Signatur der Softwaretestumgebung (112) von mindestens zwei unterschiedlichen Stellen erzeugt werden, optional wobei die Schlüssel von dem jeweiligen System selbst erzeugt wurden.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei öffentliche Schlüssel zu den digitalen Signaturen in einem gemeinsamen Register (108) gespeichert sind, optional wobei das gemeinsame Register (108) ein mehrfach replizierter und an verschiedenen Orten gespeichertes Register ist, wobei die verschiedenen Replika des Registers (108) synchronisiert sind.
Verfahren gemäß einem der Ansprüche 1 bis 5, wobei das Prüfen der digitalen Signaturen (102; 103; 109; 113) das Abfragen eines öffentlichen Schlüssels der jeweiligen Signatur (102; 103; 109; 113) in einem gemeinsamen Register (108) umfasst, optional wobei ein Sender der jeweiligen Daten als valider Sender erachtet wird, wenn mit dem jeweiligen öffentlichen Schlüssel die digitale Signatur verifiziert werden kann.
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei umfassend das zentrale System (104) ein erstes Cloud-Computing-System ist.
Verfahren gemäß einem der Ansprüche 2 bis 7, weiter umfassend Prüfen der digitalen Signatur des zentralen Systems (109) in einer zweiten Softwaretestumgebung; Testen des trainierten Maschinenlern-Modells (110) und/oder einer zweiten Software-Komponente in einer zweiten Softwaretestumgebung, wenn das zentrale Systems anhand der digitalen Signatur des zentralen Systems (109) als valider Sender eines trainierten Maschinenlern-Modells erkannt wurde; Signieren des getesteten zweiten Maschinenlern-Modells und/oder der Software-Komponente mit einer digitalen Signatur der zweiten Softwaretestumgebung; Bereitstellen des getesteten zweiten trainierten Maschinenlern-Modells und/oder der Software-Komponente mit der digitalen Signatur der zweiten Softwaretestumgebung an eine Steuereinheit eines weiteren Fahrzeugs (120).
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei umfassend das Software-Update über eine Luftschnittstelle an das Fahrzeug (120) bereitgestellt wird.
Verfahren gemäß einem der vorangegangenen Ansprüche, weiter umfassend: Empfangen des Software-Updates mit einer digitalen Signatur der Softwaretestumgebung (113) und/oder einer digitalen Signatur der Trainingsumgebung (109); Prüfen, ob die Softwaretestumgebung (112) und/oder die Trainingsumgebung valide Sender von Software-Updates sind; und Aktualisieren einer Software-Komponente des weiteren Fahrzeugs (120) anhand des Software-Updates.
Verfahren gemäß einem der vorangegangenen Ansprüche, weiter umfassend: Signieren der Fahrzeugfelddaten (105) durch den Nutzer (107) des Fahrzeugs (101) mit der mindestens einen digitalen Signatur des Fahrzeugs (102) und/oder des Nutzers (103); und Senden der signierten Fahrzeugfelddaten (105) an das zentrale System (104).
Computer-System, das dazu ausgelegt ist, die Verfahren gemäß einem der vorangegangenen Ansprüche auszuführen