Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren einer Soft- ware in Fahrzeugen einer Fahrzeugflotte, ein Aktualisierungssystem, welches eine solche Aktualisierung an Fahrzeugen der Flotte vornimmt, ein derartiges Fahrzeug sowie eine Hmtergrundeinrichtung und eine Aktuahsierungseinrich- tung des Aktualisierungssystems.

Moderne Fahrzeuge sind mit einer Vielzahl von elektronischen, Software-ge- steuerten Komponenten ausgestattet, welche Funktionen des Fahrzeugs steuern und implementieren. Solche Fahrzeuge umfassen beispielsweise ehre Vielzahl von elektronischen Steuergeräten (ECU = Electronic Control Unit) in unter- schiedlichen Ausprägungen, die mit Mikroprozessoren und geeigneten Spei- chereinrichtungen ausgestattet sind und Funktionen des Fahrzeugs überneh- men, die beispielsweise die Motor- und Antriebssteuerung, Diagnose- und Si- cherheitssysteme, Navigations-, Assistenz- und Kommunikationssysteme und dergleichen mehr betreffen.

Die in solchen Steuersystemen installierte Software ist in der Regel eine Be- triebssoftware oder Firmware, die das Verhalten der betreffenden Komponen- ten bzw. ECUs vorgibt und insbesondere aus Sicherheitsgründen regelmäßig aktualisiert werden muss, zum Beispiel indem Updates und/ oder Patches ein- gespielt werden, die Teile der Software oder die Software als Ganzes ersetzen. Inzwischen ist man dazu übergegangen, die Softwareaktualisierung bei Fahr- zeugen während der Fahrt mittels der mobilen Datenkommunikation durchzu- führen, beispielsweise über eine herkömmlichen Mobilfunkverbindung eines Mobilfunknetzes in das sich das betreffende Fahrzeug als Teilnehmer einwählt, beispielsweise über eine SIM- oder eSIM-Mobilfunkkarte. In diesem Zusammenhang ist unter Aktualisierung oder Softwareaktualisie- rung ein Prozess zu verstehen, mit dem eine auf einem Server bereitliegende aktuelle Software zunächst auf das Fahrzeug heruntergeladen, in einem geeig- neten Speicher abgelegt und anschließend in den richtigen Steuereinheiten und -komponenten installiert wird. Beim anschließenden Installieren wird die bishe- rige Software durch die heruntergeladene, aktuelle Software ersetzt und gege- benenfalls so konfiguriert, dass sie bei Ausführung durch einen Mikroprozessor die Aufgaben der bisherigen Software übernimmt. Während eine geeignete Funkverbindung hauptsächlich zum Herunterladen der Software auf das Fahr- zeug benötigt wird, kann auch das Installieren bzw. Konfigurieren der aktuel- len Software in dem Fahrzeug eine Funkverbindung erfordern, zum Beispiel um von dem Server Konfigurationsdaten herunterzuladen oder spezifische Da- ten, wie zum Beispiel Schlüssel, Prüfsummen, Kennungen, Referenzen oder dergleichen auf den Server hochzuladen. Mit dem Begriff „Aktualisierung" o- der „Softwareaktualisierung" ist im Folgenden also insbesondere derjenige An- teil dieses Prozesses gemeint, für den eine stabile Funkverbindung benötigt wird.

Hierbei ergibt sich das Problem, dass das Herunterladen einer aktuellen Soft- wareversion über eine Funkverbindung aufgrund von deren Größe häufig län- ger dauert und damit die Gefahr steigt, dass die Funkverbindung während des Herunterladens fahrtbedingt abbricht. Nach dem Abbruch oder einer Störung einer Funkverbindung kann das Herunterladen einer Software aber nicht naht- los fortgesetzt werden, sobald wieder eine Funkverbindung besteht, so dass der der Prozess des Herunterladens unter Umständen mehrfach wiederholt werden muss, bevor die Software vollständig auf dem Fahrzeug vorliegt.

Daraus ergeben sich viele technische Nachteile, insbesondere erhöhter Batterie- verbrauch im Fahrzeug und Energieverbrauch insgesamt, unnötige Belastung des betreffenden Funknetzwerks und der Server, von denen die Software her- untergeladen wird, oder dergleichen. Es ist insofern die Aufgabe der vorliegenden Erfindung, eine Lösung vorzu- schlagen, die die oben genannten und weitere Nachteile des Standes der Tech- nik vermeidet.

Gelöst wird diese Aufgabe durch ein Verfahren, ein Aktualisierungssystem, eine Hintergrundeinrichtung und eine Aktualisierungseinrichtung des Hinter- grundsystems sowie ein Fahrzeug gemäß den unabhängigen Ansprüchen. In den abhängigen Ansprüchen werden weitere Ausgestaltungen bevorzugter Ausführungsformen der Erfindung angegeben.

Gemäß eines Hauptaspekts der Erfindung werden zum Aktualisieren einer Software in Fahrzeugen einer Fahrzeugflotte zunächst diejenigen Fahrzeuge der Flotte identifiziert, deren Software zu aktualisieren ist. Bei diesem Schritt wird zumindest eines der Fahrzeuge der Fahrzeugflotte ausgewählt, dessen Software über eine bestehende Funkverbindung gemäß vorgegebenen Aktualisierungs- bedingungen anschließend aktualisiert wird.

Die Aktualisierungsbedingungen werden erfindungsgemäß mittels eines Ma- schinenlern-Modells bzw. „Machine Learning Model" bestimmt, im Folgenden auch als ML-Modell bezeichnet, welches Übertragungsqualitäten von möglichst vielen verschiedenen Funkverbindungen über ein Funknetzwerk modelliert, also von Funkverbindungen zu verschiedenen Zeiten und an verschiedenen Or- ten des Funknetzwerks. Das ML-Modell ist also vergleichbar mit einer zeitlich variablen, veränderlichen Karte, die mit einer bestimmten Ortsauflösung, bei- spielsweise entsprechend den Funkzellen eines Mobilfunknetzwerks, Übertra- gungsqualitäten von Funkverbindungen kartiert und zwar zeitabhängig mit ei- ner bestimmten Zeitauflösung über einen sinnvollen Zeitraum hinweg, bei- spielsweise einen Tag eine Woche, oder einen Monat. Dieses ML-Modell ist das Ergebnis eines fortgesetzten Trainingsprozesses, der nachfolgend beschrieben werden wird. Das trainierte ML-Modell wird einge- setzt, tun Vorhersagen hinsichtlich der Übertragungsqualitäten von Funkver- bindungen abzuleiten, über die zukünftig die Software des zumindest einen identifizierten Fahrzeugs aktualisiert werden kann. Die Aktualisierungsbedin- gungen werden dann so bestimmt, dass sie eine oder mehrere zukünftig mögli- che Funkverbindungen hinreichend genau spezifizieren, deren vorausgesagte Übertragungsqualitäten ausreichen, um die Software des Fahrzeugs zu aktuali- sieren.

Unter einer „zukünftigen Funkverbindung" ist in diesem Zusammenhang eine solche Funkverbindung zu verstehen, die das Fahrzeug in der Zukunft potenti- ell aufbauen und unterhalten kann, um die Software über diese Funkverbin- dung zu aktualisieren, sobald sie besteht. Das ML-Modell sagt also voraus, un- ter welchen Aktualisierungsbedingungen die Software des Fahrzeugs mit hin- reichend hoher Wahrscheinlichkeit so aktualisiert werden kann, dass die ein- gangs geschilderten Nachteile des Standes der Technik vermieden werden.

Für eine Funkverbindung wird von dem ML-Modell eine im Sinne der Erfin- dung ausreichende Übertragungsqualität vorausgesagt, wenn sie voraussicht- lich geeignet ist, den Vorgang des Aktualisierens der Software erfolgreich abzu- schließen sobald er begonnen wird. Hierbei liegt es in der Natur von Voraussa- gen durch ein Maschinenlern-Modell, dass diese nicht zutreffen müssen, son- dern nur wahrscheinlich zutreffen. So kann ein unerwartet hohes Verkehrsauf- kommen in bestimmten Funkzellen, zum Beispiel aufgrund einer Baustelle in anderen Funkzellen, die tatsächliche Übertragungsqualität einer Funkverbin- dung entgegen der Voraussage verschlechtern.

Erfindungsgemäß ist das durch Training erzeugte ML-Modell, welches Übertra- gungsqualitäten von potentiellen Funkverbindungen modelliert, die Grundlage einer Voraussage, unter welchen Umständen die Software des betreffenden Fahrzeugs voraussichtlich unterbrechungsfrei aktualisiert werden kann. Diese Umstände der unterbrechungsfreien Aktualisierung werden durch Aktualisie- rungsbedingungen beschrieben. Wenn die Software also gemäß den Aktualisie- rungsbedingungen aktualisiert wird, können die eingangs geschilderten Nach- teile des Standes der Technik voraussichtlich vermieden werden.

Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird das erfin- dungsgemäße Aktualisierungsverfahren von einem Aktualisierungssystem aus- geführt, welches eine Hintergrundeinrichtung umfasst sowie zumindest eine mit der Hintergrundeinrichtung über eine Datenkommunikationsverbindung in Kontakt stehende Aktualisierungseinrichtung. Die Aktuahsierungseinrich- tung identifiziert die Fahrzeuge, deren Software zu aktualisieren ist, baut die hierzu benötigten Funkverbindungen zu den Fahrzeugen auf und aktualisiert schließlich die Software der identifizierten Fahrzeuge gemäß den vorgegebenen Aktualisierungsbedingungen. Auf der Hintergrundeinrichtung ist das ML- Modell eingerichtet, welches Übertragungsqualitäten von potentiellen Funkver- bindungen modelliert.

Während als Datenkommunikationsverbindungen zwischen der Hintergrund- einrichtung und der einen oder den mehreren Aktualisierungseinrichtimgen herkömmliche kabelgebundene Verbindungen genutzt werden, zum Beispiel übliche Intemet/DSL-Verbindungen, besteht zwischen der zumindest einen Aktualisierungseinrichtung und den betreffenden Fahrzeugen jeweils lediglich eine drahtlose Funkverbindung, zum Beispiel über ein herkömmliches Mobil- funknetzwerk.

Gemäß eines weiteren Aspekts der Erfindung bestimmt das auf einer erfin- dungsgemäßen Hintergrundeinrichtung eingerichtete Maschinenlern-Modell erfindungsgemäß die individuellen Aktualisierungsbedingungen zum Aktuali- sieren der Software eines jeden identifizierten Fahrzeugs derart, dass die Aktu- alisierungsbedingungen jeweils Funkverbindungen beschreiben, für die gemäß Voraussage jeweils ausreichende Übertragungsqualitäten zu erwarten sind. Dadurch kann die Software der betreffenden Fahrzeuge erfindungsgemäß aktu- alisiert werden, vorzugsweise unterbrechungsfrei und/oder innerhalb eines vorgegebenen Zeitfensters, innerhalb dessen die Softwareaktualisierung begon- nen und vollständig beendet wird.

Gemäß eines weiteren Aspekts der vorliegenden Erfindung ist ein Fahrzeug derart eingerichtet, dass seine Software durch ein erfindungsgemäßes Aktuali- sierungssystem in erfindungsgemäßer Art und Weise aktualisiert werden kann. Entsprechend umfasst ein erfindungsgemäßes Fahrzeug Mittel zum Aufbau ei- ner Funkverbindung nach Vorgabe der AJktualisierungsbedingungen und zum Herunterladen und Installieren einer aktuellen Software in den betreffenden Steuergeräten und ECU-Komponenten.

Die Übertragungsqualität, die von dem Maschinenlern-Modell der Bestimmung von Aktualisierungsbedingungen zugrunde gelegt wird, ist vorzugsweise eine Datenübertragungsrate bzw. Datenrate, also ein Maß dafür, welches digitale Datenvolumen innerhalb einer bestimmten Zeitspanne und an einem bestimm- ten Standort, zum Beispiel innerhalb einer Funkzelle, über die betreffende Funkverbindung übertragen werden kann. Je größer die Datenrate ist und je länger die Datenrate aufrechterhalten werden kann, desto größer ist die Über- tragungsqualität der betreffenden Funkverbindung, denn desto schneller und zuverlässiger kann eine Softwareaktualisierung über diese Funkverbindung er- folgen. Je mehr Teilnehmer sich jedoch zum gleichen Zeitpunkt bzw. innerhalb der gleichen Zeitspanne in einer Funkzelle (voraussichtlich) anmelden, je mehr parallele Funkverbindungen also (voraussichtlich) bestehen, desto geringer ist die (voraussichtliche) Datenrate jeder einzelnen dieser Funkverbindungen.

Eine ausreichende Übertragungsqualität im Sinne der Erfindung wird also von dem ML-Modell insbesondere dann vorausgesagt, wenn für eine Funkverbin- düng eine Datenrate erwartet wird, die für eine bestimmte Dauer eine vorgege- bene minimale Datenrate überschreitet, so dass die Software innerhalb dieser Dauer aktualisiert werden kann. Für Funkverbindungen, für die das ML- Modell eine Datenrate vorhersagt, die die minimale Datenrate innerhalb der vorgegebenen Zeitdauer überschreitet, werden Aktualisierungsbedingungen ermittelt, gemäß denen das Fahrzeug die Softwareaktualisierung voraussicht- lich unterbrechungsfrei durchführen kann, sobald diese zutreffen.

Vorzugsweise wird dabei auch die digitale Größe bzw. das Datenvolumen der über die Funkverbindung herunterzuladenden aktuellen Software berücksich- tigt und die Aktualisierungsbedingungen werden entsprechend derart festge- legt, dass die die minimale Datenrate ausreichend lange überschritten wird, um die Software vollständig aktualisieren zu können. Mit anderen Worten, die Ak- tualisierungsbedingungen werden insbesondere so bestimmt, dass die Funkver- bindung zeitlich ausreichend stabil ist, sie also lange genug unterbrechungsfrei zur Verfügung steht, um die Software zu aktualisieren.

Da es sich dabei aber um eine Voraussage handelt, kann nicht angenommen werden, dass die vorausgesagte Übertragungsqualität sicher vorliegen wird, so- bald die Aktualisierungsbedingungen erfüllt sind. Stattdessen ist nur mit einer hinreichend hohen Wahrscheinlichkeit damit zu rechnen, dass die Voraussage eintrifft und die Software ohne Unterbrechungen der Funkverbindung aktuali- siert werden kann. Eine solche vorgegebene Wahrscheinlichkeit ist beispiels- weise größer 0,8 (> 80%), größer 0,9 (> 90%) oder größer 0,95 (> 95%) oder grö- ßer als 0,98 (> 98%).

Die Aktualisierungsbedingungen umfassen vorzugsweise zumindest eine Zeit- bedingung und zumindest eine Ortsbedingung. Bevorzugt wird zumindest ein Bedingungspaar ermittelt, bestehend aus einer Zeitbedingung und einer Orts- bedingung, Die Software wird dann automatisch aktualisiert, sobald eines der Bedingungspaare zutrifft, die das ML-Modell für das betreffende Fahrzeug be- stimmt hat; wenn das Fahrzeug also sowohl die Orts- als auch die Zeitbedin- gung erfüllt.

Als Ortsbedingung wird beispielsweise eine Funkzelle oder ein bestimmter Standort, ein Straßenabschnitt oder ein Flächenareal bestimmt, in der oder dem die Aktualisierung der Software des betreffenden Fahrzeuges stattfinden muss. Die Zeitbedingung gibt vorzugsweise ein Zeitintervall an, innerhalb dessen die Software zu aktualisieren ist, während das Fahrzeug gleichzeitig die Ortsbedin- gung erfüllt. Das Zeitintervall ist dabei so bemessen, dass die Software bei der zugehörigen vorausgesagten Übertragungsqualität vollständig aktualisiert wer- den kann.

Neben dem Bestimmen der AktuaHsierungsbedingungen mittels Vorhersage von Übertragungsqualitäten für Funkverbindungen wird auch das Trainieren des ML-Modells von der zentralen Hintergrundeinrichtung durchgeführt. Kon- kret werden alle Vorgänge und Operationen von der Hintergrundeinrichtung durchgeführt, die mit dem Erzeugen, Trainieren und Nutzen des ML-Modells Zusammenhängen. Dabei wird das ML-Modell zunächst mit Trainingsdaten trainiert, um dann, in einem anschließenden Schritt, mit dem ML-Modell Vo- raussagen betreffend die Übertragungsqualitäten von Funkverbindungen zu treffen bzw. aus dem trainierten ML-Modell abzuleiten und geeignete Aktuali- sierungsbedingungen zu ermitteln.

Als Trainingsdaten werden deshalb von den Fahrzeugen der Fahrzeugflotte eine Vielzahl von Sensordaten erhoben, die über eine Aktualisierungseinrich- tung an die Hintergrundeinrichtung weitergeleitet werden und dort als Trai- ningsdaten für das ML-Modell dienen. Zu diesen Sensordaten zählen insbeson- dere Messwerte der konkreten Übertragungsqualitäten bzw. Datenraten von Funkverbindungen inklusive zugehöriger Orts- und Zeitdaten, die von den Fahrzeugen während ihres regulären Fährbetriebs erhoben werden. Wenn ein Fahrzeug eine Funkzelle durchfährt, misst es die Übertragungsqualität einer ak- tuellen Funkverbindung, zum Beispiel in Form der aktuellen Datenübertra- gungsrate, und liefert diese zusammen mit Angaben zu der betreffenden Funk- zelle und dem Zeitpunkt als Sensordaten an die Aktualisierungseinrichtung.

Weitere Sensordaten, die vorzugsweise auch zum Training des ML-Modells eingesetzt werden, betreffen Angaben zur Anzahl aktiver Funkverbindungen innerhalb von Funkzellen zu bestimmten Zeitpunkten oder innerhalb bestimm- ter Zeitintervalle, ebenso wie Angaben zu den konkreten Fahrtwegen der Fahr- zeuge, also zu den Bewegungsmustern der Fahrzeuge durch das Funknetzwerk und den besuchten Funkzellen inklusive der entsprechenden Zeitangaben.

Die Aktualisierungseinrichtung leitet diese Sensordaten nicht einfach an die Hmtergrundeinrichtung weiter, sondern bereitet sie nötigenfalls auf. So kann ein einzelnes Fahrzeug möglicherweis keine Messungen zu der Anzahl der zu einem Zeitpunkt aktiven Funkverbindungen vornehmen, so dass die Aktuali- sierungseinrichtung vorzugsweise die Sensordaten von vielen Fahrzeugen aus- wertet, tun daraus solche Angaben abzuleiten. Selbiges gilt für die Bewegungs- daten der einzelnen Fahrzeuge, die auch erst von der Aktualisierimgseinrich- tung aus den Sensordaten der Fahrzeuge betreffend bestimmte Funkzellen ge- neriert werden.

Während diese Sensordaten und Bewegungsdaten lediglich Momentaufnah- men zu den Übertragungsqualitäten verschiedener Funkverbindungen inner- halb des Funknetzes betreffen, wird beim Trainieren des ML-Modells basierend auf den Sensor- und Bewegungsdaten ein möglichst umfassendes Modell mit Mitteln des Maschinenlernens erzeugt, das es erlaubt, Vorhersagen zu den Übertragungsqualitäten möglichst vieler örtlich/ zeitlich verschiedener zukünf- tiger Funkverbindungen zu treffen. Durch das Trainieren des ML-Modells wird also die oben angesprochene zeitlich variable Karte des Mobilfunknetzes er- zeugt, die mit bestimmter Orts- und Zeitauflösung Voraussagen zu Übertra- gungsqualitäten von zukünftigen Funkverbindungen kartiert.

Basierend auf den von den Fahrzeugen konkret gemessenen Übertragungsqua- litäten in bestimmten Funkzellen zu bestimmten Zeiten werden beim Trainieren des ML-Modells mögliche Übertragungsqualitäten von Funkverbindungen ab- geleitet, zu denen keine Sensordaten vorliegen. Die Übertragungsqualitäten sol- cher Funkverbindungen werden beim Trainieren also geschätzt bzw. aus den vorhandenen Sensordaten extrapoliert, beispielsweise anhand von Sensordaten aus Funkzellen oder für Zeitintervalle mit ähnlicher Charakteristik. So kann beispielsweise die örtliche Nähe einer Funkzelle, zu der keine oder nicht genü- gend Sensordaten vorliegen, zu anderen Funkzellen, für die ausreichende Sens- ordaten erhoben wurden, eine ähnliche Charakteristik sein, oder vergleichbare Verkehrsaufkommen in zwei Fuhkzellen, ähnliche Bevölkerungsdichten oder dergleichen. Vorzugsweise werden Funkzellen anhand solcher und anderer Charakteristika zu Clustern gruppiert und Sensordaten für eine oder wenige Fuhkzellen eines Clusters für alle weiteren Funkzellen des Clusters verwendet.

Mit dem derart trainierten ML-Modell werden dann für ein Fahrzeug, dessen Software aktualisiert werden soll, Vorhersagen zu den Übertragungsqualitäten von F unk Verbindungen getroffen, die dieses Fahrzeug in der Zukunft potentiell nutzen könnte, um dessen Software zu aktualisieren. Hierbei werden vorzugs- weise die Bewegungsdaten des Fahrzeugs zugrunde gelegt, damit nur Funkver- bindungen in Betracht gezogen werden, die das Fahrzeug während seines übli- chen Betriebs, zum Beispiel auf sich regelmäßig wiederholenden Fahrten, auch realistisch aufbauen kann. Das ML-Modell wählt dann eine oder mehrere dieser Funkverbindungen aus, für die ausreichend stabile Übertragungsqualitäten vo- rausgesagt werden, und die vorzugsweise auf die Bewegungsdaten des Fahr- zeugs abgestimmt sind. Die Aktualisierungsbedingungen, gemäß denen die Software des betreffenden Fahrzeugs aktualisiert wird, beschreiben dann die ausgewählten Funkverbin- dungen mit potentiell ausreichenden Übertragungsqualitäten. Wenn das ML- Modell zum Beispiel an einem bestimmten Wochentag auf dem morgendlichen Arbeitsweg und an einem anderen Arbeitstag auf dem abendlichen Weg nach

Hause in bestimmten, von dem Fahrzeug besuchten Funkzellen ausreichende Übertragungsqualitäten voraussagt, beschreiben die Aktualisierungsbedingun- gen Standorte bzw. Funkzellen und Zeitpunkte bzw. Zeitintervalle dieser bei- den Situationen, so dass zwei unterschiedliche Möglichkeiten angeboten wer- den, die Software zu aktualisieren.

Gemäß einer besonderen Ausgestaltung der Erfindung werden für alle identifi- zierten Fahrzeuge Aktualisierungsbedingungen bestimmt und zu einem Aktua- lisierungsplan zusammengefasst, der Grundlage einer Aktualisierungskam- pagne ist, die innerhalb eines vorgegebenen Zeitrahmes die Software aller iden- tifizierten Fahrzeuge aktualisiert. Dem ML-Modell werden zur Erzeugung eines optimalen Aktualisierungsplans deshalb die Liste aller identifizierten Fahr- zeuge, deren Software zu aktualisieren ist, die entsprechenden Zeitvorgaben hinsichtlich des gewünschten Zeithorizonts der AktuaÜsierungskampagne so- wie die Bewegungsdaten der betreffenden Fahrzeuge bereitgestellt.

Dies erfordert, dass die Aktuaüsierungsbedingungen nicht für jedes einzelne Fahrzeug unabhängig von denen anderer Fahrzeuge bestimmt werden, sondern dass vielmehr ein optimaler Aktualisierungsplan gefunden wird, der eine über- geordnete Kostenfunktion minimiert oder eine übergeordnete Nutzenfunktion maximiert. Eine solche Funktion wird dann optimal, wenn für möglichst viele Fahrzeuge auf deren Bewegungsdaten abgestimmte Übertragungsqualitäten vorhergesagt werden und Aktualisierungsbedingungen gefunden werden, die nicht miteinander kollidieren. Sobald die Aktualisierungsbedingungen für ein Fahrzeug zutreffen, wird des- sen Software aktualisiert. Die Aktualisierungsbedingungen können entweder von der Aktualisierungseinrichtung überwacht und umgesetzt werden oder au- tonom von jedem Fahrzeug selbst.

Bei einer besonders vorteilhaften Ausgestaltung der Erfindung wird vermie- den, dass sensible personenbezogene Daten, wie etwa die als Trainingsdaten für das ML-Modell verwendeten Sensor- und/ oder Bewegungsdaten, die über Aufenthaltsorte und -Zeiten von Personen Auskunft geben und insofern gelten- den Datenschutzbestimmungen unterliegen können, das jeweilige Fahrzeug verlassen und dadurch potentiell Unbefugten zugänglich werden können.

Um dies zu erreichen, kann die oben beschriebene Erfindung auch als „federa- ted learning"-V ariante realisiert werden. Beim „federated leaming" handelt es sich um einen verteilten bzw. dezentralen Ansatz des Maschinenlernens, bei dem lokale Instanzen eines ML-Modells dezentral basierend auf jeweils indivi- duellen, lokalen Trainingsdaten trainiert werden.

Deshalb ist gemäß dieser Ausgestaltung der Erfindung auf mehreren Fahrzeu- gen, vorzugsweise auf allen Fahrzeugen der Fahrzeugflotte, ein lokales, fahr- zeugindividuelles ML-Modell installiert, welches basierend lediglich auf den Sensor- und/ oder Bewegungsdaten des betreffenden, individuellen Fahrzeuges trainiert wird. Die Fahrzeuge bzw. deren fahrzeugindividuellen ML-Modelle tauschen dabei keine personenbezogenen (Trainings-) Daten untereinander o- der mit der Hintergrund- oder Aktualisierungseinrichtung aus.

Auf der Hintergrundeinrichtung wird ein korrespondierendes, übergeordnetes und flottenübergreifendes ML-Modell betrieben, welches einerseits die lokalen Trainingsergebnisse der einzelnen fahrzeugindividuellen ML-Modelle flotten- übergreifend integriert und welches andererseits genutzt wird, um die einzel- nen fahrzeugindividuellen ML-Modelle zu aktualisieren und zu synchronisie- ren. Während die fahrzeugindividuellen ML-Modelle also jeweils basierend auf fahrzeugindividuellen Sensor- und Bewegungsdaten trainiert werden, wird das flottenübergreifende ML-Model nicht trainiert, sondern synthetisiert. Durch die Synthese wird der Trainingszustand des das flottenübergreifende ML-Model al- lerdings in ähnlicher Weise verbessert, wie bei einem herkömmlichen Training des flottenübergreifende ML-Models.

In regelmäßigen Zeitabständen oder nach Bedarf werden die lokalen, fahrzeug- individuellen ML-Modelle zu einem aktualisierten, flottenübergreifenden ML- Modell auf der Hintergrundeinrichtung zusammengeführt bzw. synthetisiert. Das derart gebildete flottenübergreifende ML-Modell repräsentiert dann eine Synthese der Trainingsergebnisse aller fahrzeugindividuellen ML-Modelle zu einem bestimmten Zeitpunkt und mit ihm werden die fahrzeugindividuellen ML-Modelle vorzugsweise immittelbar nach der Synthese wieder aktualisiert bzw. synchronisiert. Dazu wird das synthetisierte, flottenübergreifende ML- Modell von der Hintergrundeinrichtung über die Aktualisierungseinrichtung an die Fahrzeuge der Fahrzeugflotte weitergegeben, so dass aufgrund der Syn- chronisation jedes fahrzeugindividuelle ML-Modelle auch von den Trainingser- gebnissen aller anderen fahrzeugindividuellen ML-Modelle profitiert.

Das Zusammenführen (Synthetisieren) des flottenübergreifenden ML-Modells und das anschließende Aktualisieren (Synchronisieren) der fahrzeugindividuel- len ML-Modelle wird mit geeigneten Datenstrukturen derart durchgeführt, dass keine personenbezogenen Sensor- und/ oder Bewegungsdaten zwischen den Fahrzeugen und dem Hintergrundsystem ausgetauscht werden. Vielmehr werden lediglich fahrzeugindividuelle bzw. flottenübergreifende, repräsenta- tive Modelldaten übertragen, die aus den fahrzeugindividuellen bzw. flotten- übergreifenden ML-Modellen jeweils basierend auf deren jeweiligem Trainings- zustand abgeleitet werden. Aus diesen repräsentativen Modelldaten sind die zugrundeliegenden, perso- nenbezogenen Trainingsdaten nicht mehr zu extrahieren, denn die Modelldaten betreffen Schätzungen von Übertragungsqualitäten von potentiellen Funkver- bindungen, die aus den Sensordaten extrapoliert wurden und diese dadurch derart verfremden, dass sie für Unbefugte keinen Wert mehr haben können.

Vorzugsweise repräsentieren die fahrzeugindividuellen Modelldaten, die je- weils aus den betreffenden fahrzeugindividuellen ML-Modellen abgeleitet wer- den, eine Differenz bzw. einen Unterschied zwischen dem aktuellen Zustand des betreffenden fahrzeugindividuellen ML-Modells und dem Zustand dieses ML-Modells nach dessen letzter Aktualisierung. Die fahrzeugindividuellen Mo- delldaten, die schließlich zu dem flottenübergreifenden ML-Modell zusammen- geführt werden, betreffen also vorzugsweise Inkremente der Trainingszustände bzw. inkrementeile Trainingsfortschritte des jeweiligen fahrzeugindividuellen ML-Modells zwischen zwei Trainingsphasen oder zwei Zeitpunkten innerhalb einer Trainingsphase.

Entsprechend repräsentieren auch die flottenübergreifenden Modelldaten, die zur Synchronisation der fahrzeugindividuellen ML-Modelle aus dem flotten- übergreifenden ML-Modell abgeleitet werden, eine Differenz bzw. einen Unter- schied zwischen dem aktuellen Zustand des flottenübergreifenden ML-Modells und dem Zustand dieses ML-Modells nach dessen letzter Synthese aus den fahrzeugindividuellen ML-Modellen. Die flottenübergreifenden Modelldaten, mit denen die fahrzeugindividuellen ML-Modelle aktualisiert werden, betreffen also Inkremente der Trainingszustände bzw. inkrementeile Trainingsfort- schritte des flottenübergreifenden ML-Modells zwischen zwei Trainingsphasen oder zwei Zeitpunkten innerhalb einer Trainingsphase.

Die derart aktualisierten fahrzeugindividuellen ML-Modelle werden dann an- hand der von diesem Fahrzeug im weiteren Verlauf individuell erhobenen Sen- sor- und Bewegungsdaten weiter trainiert, sodass die verschiedenen fahrzeug- individuellen ML-Modelle nach deren Synchronisation wieder divergieren. Die dadurch entstehenden Unterschiede werden zu einem geeigneten Zeitpunkt wieder in Form von fahrzeugindividuellen Modelldaten aus den jeweiligen fahrzeugindividuellen ML-Modellen extrahiert und erneut zum flottenübergrei- fenden ML-Modell zusammengeführt. Aus dem derart synthetisierten flotten- übergreifenden ML-Model können dann Vorhersagen zu den Übertragungs- qualitäten von Funkverbindungen basierend auf den Sensordaten aller Fahr- zeuge der Fahrzeugflotte getroffen werden.

Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung erfindungsgemäßer Ausführungsbeispiele sowie weiterer Aus- führungsalternativen im Zusammenhang mit den Zeichnungen, die zeigen:

Fig. 1 ein Schema eines erfindungsgemäßen Aktualisierungssystems;

Fig. 2a eine erste bevorzugte Ausführungsform des erfindungsgemäßen Ak- tualisierungsverfahrens;

Fig. 2b eine zweite bevorzugte Ausführungsform des erfindungsgemäßen Aktualisierungsverfahrens;

Fig. 3 ein Schema der Maschinenlem-Einheit eines erfindungsgemäßen

Hintergrundsystems;

Fig.4 ein Schema der Aktualisierung der Software eines Fahrzeugs; und

Fig. 5 eine dritte bevorzugte Ausführungsform des erfindungsgemäßen Aktualisierungsverfahrens. Fig. 1 zeigt exemplarisch ein erfindungsgemäßes Aktualisierungssystem umfas- send eine zentrale Hintergrundeinrichtung 10 (HGE) sowie mehrere mit dieser über geeignete, üblicherweise kabelgebundene Datenkommunikationsverbin- dungen 20 in Datenkommunikation stehende AktuaHsierungseinrichtungen 30 (SAE). Die Aktualisierungseinrichtungen 30 wiederum unterhalten individuelle Funkverbindungen 40 zu einer Vielzahl von Fahrzeugen 50 einer Fahrzeug- flotte, über die die Aktualisierungseinrichtungen 30 zu verschiedenen Zwecken mit den Fahrzeugen 50 Datenkommunikation betreiben können, zum Beispiel zu Zwecken der Fernwartung, Messwerterhebung, Sensoransteuerung oder dergleichen. Über die Funkverbindungen 40 wird darüber hinaus auch die Ak- tualisierung von Software, die auf den Fahrzeugen 50 installiert ist, nach Vorga- ben der Hintergrundeinrichtung 10 veranlasst.

Die Fahrzeuge 50 sind mit komplexen elektronischen Steuer- und Regelsyste- men ausgestattet, die in der Regel als eingebettete Module („embedded Sys- tems") realisiert sind und vielfältige Aufgaben innerhalb eines Fahrzeugs 50 wahrnehmen, wie zum Beispiel die Motor- und Bremssteuerung, die Steuerung von Assistenz-, Sicherheits- und Kommunikationssystemen und dergleichen mehr. Diese elektronischen Steuergeräte, üblicherweise ECU bzw. „Electronic Control Units" genannt, sind mit Mikroprozessoren, flüchtigen und nicht-flüch- tigen Speichern, Peripherie- und Bussystemen ausgestattet und werden von ei- ner Betriebssoftware oder Firmware betrieben, beispielsweise gemäß einer vor- gegebenen Softwarearchitektur, wie zum Beispiel dem AUTOSAR-Standard (Automotive Open System Architecture).

Wie jede Software müssen auch die Softwarekomponenten der Betriebssoftware einer Fahrzeugsteuerung aus Sicherheits- und Performancegründen regelmäßig aktualisiert werden. Die Funktionsweise und das Zusammenwirken der Hinter- grundeinrichtung 10 mit den Aktualisierungseinrichtungen 30 stellt sicher, dass die Aktualisierung der Software jedes einzelnen Fahrzeugs 50 nach individuell festgelegten Bedingungen durchgeführt wird, welche stabile Mobilfunkverbin- dungen 40 mit ausreichenden Übertragungsqualitäten bzw. ausreichenden Da- tenübertragungsraten zu den Fahrzeugen 50 sicherstellen, um die Software je- weils unterbrechungsfrei zu aktualisieren.

Das Zusammenwirken und die Datenkommunikation zwischen der Hinter- grundeinrichtung 10, einer Aktualisierxmgseinrichtung 30 sowie den verschie- denen Fahrzeugen 50 einer Fahrzeugflotte, deren Software zu aktualisieren ist, wird am Beispiel der Figuren 2a und 2b dargestellt, die jeweils bevorzugte Aus- führungsformen des erfindungsgemäßen Aktualisierungsverfahrens illustrie- ren.

Die Hintergrundeinrichtung 10 der Fig. 2a umfasst eine Steuereinheit 11, die die Hintergrundeinrichtung 10 steuert und insbesondere die Maschinenlern-Einheit 12 (ML-Einheit) ansteuert. Die ML-Einheit 12 ist realisiert als ein auf einem Pro- zessor (nicht dargestellt) der Hintergrundeinrichtung 10 ausführbares Software- programm und erzeugt, bearbeitet, verwaltet und benutzt zwei ausgewählte Datenstrukturen, nämlich einerseits das Maschinenlem-Modell 13 (ML-Modell) und andererseits den Aktualisierungsplan 14. Diese und andere Daten- und Kontrollstrukturen sind in einem geeigneten Speicher (nicht dargestellt) der Hintergrundeinrichtung 10 abgelegt, auf die die ML-Einheit 12 Zugriff hat.

Sobald eine neue, aktuelle Software vorliegt, die auf einigen oder allen Fahrzeu- gen 50 einer Fahrzeugflotte installiert werden soll, weist die Hintergrundein- richtung 10 die AktuaHsierungseinrichtung 30 in einem Schritt S1 an, alle Fahr- zeuge 50 zu identifizieren, deren derzeitige Software durch die aktuelle Soft- ware zu ersetzen ist. Dazu wird der Aktualisienmgseinrichtung 30 insbeson- dere die Versionsnummer(n) der zu aktualisierenden Software übergeben, ebenso wie weitere Identifikationskriterien, die die Identifikation aller betroffe- nen Fahrzeuge 50 erlauben, wie zum Beispiel Modellangaben und Modellnum- mern betreffend die elektronischen Steuereinheiten, Fahrzeugtypen, Zulas- sungsdaten oder dergleichen.

Eine Identifikationseinheit 31 der AktuaHsierungseinrichtung 30 stellt darauf- hin in einem Schritt S2 eine Liste L aller Fahrzeuge 50 zusammen, die den von der Hintergrundeinrichtung 10 übergebenen Identifikationskriterien entspre- chen. Dazu werden in einem Schritt S3 Informationen von den Fahrzeugen 50 über die Funkverbindungen 40 eingeholt, die zur Identifikation der betroffenen Fahrzeuge 50 gegebenenfalls benötigt werden, beispielsweise Betriebszustände, Fehlercodes oder dergleichen. In eine Schritt S4 wird die Liste L der identifizier- ten Fahrzeuge 50 an die Hintergrundeinrichtung 10 und dort an die ML-Einheit 12 übergeben.

Zusammen mit der Liste L übermittelt die Identifikationseinheit 31 auch Zeit- vorgaben Z an die Hintergrundeinrichtung 10, die ebenfalls auf den in Schritt S3 von den Fahrzeugen 50 empfangenen Informationen basieren können. Diese betreffen insbesondere Angaben hinsichtlich der Dauer einer betreffenden Ak- tualisierungskampagne bzw. des „Rollout" in Tagen oder Wochen, also das Zeitfenster in dem die Softwareaktualisierung aller identifizierten Fahrzeuge 50 abgeschlossen sein soll, und gegebenenfalls Angaben zur Dauer einer individu- ellen Aktualisierung auf einem konkreten Fahrzeug, die in der Regel abhängig ist von der konkreten technischen Infrastruktur des betreffenden Fahrzeugs 50.

Die Liste L mit den identifizierten Fahrzeugen 50 und die Zeitvorgaben Z, wer- den in Schritt S4 an die Maschinenlern-Einheit 12 übergeben und dort als Ein- gabewerte für eine Voraussage geeigneter Aktualisierungsbedingungen B für die identifizierten Fahrzeuge 50 basierend auf dem ML-Modell 13 verwendet, die schließlich zusammengefasst zu einem Aktualisierungsplan 14 die vollstän- dige Aktualisierungskampagne definieren, also die zeitliche/ örtliche Abfolge der Softwareaktualisierung aller in der Liste L genannten Fahrzeuge 50 inner- halb der Zeitvorgabe Z bezüglich der Dauer der Kampagne.

Der Schritt S8 gemäß Fig. 2a fasst die beiden Betriebsphasen der ML-Einheit 12 zusammen, nämHch erstens das Trainieren des ML-Modells 13 basierend unter anderem auf Sensordaten D, die die ML-Einheit 12 in Schritt S7 erhält, und zweitens die Vorhersage von Aktualisierungsbedingungen B und eines Aktuali- sierungsplans 14 basierend auf der Liste L und den Zeitvorgaben Z, die die ML- Einheit 12 in Schritt S4 erhält. Fig. 3 zeigt die beiden entsprechenden Module der ML-Einheit, nämlich das Trainingsmodul 12a, welches in Schritt S8a das ML-Modell 13 trainiert, und das Vorhersagemodul 12b, welches daraus in Schritt S8b Aktualisierungsbedingungen B ableitet.

Beim Trainieren wird das ML-Modell 13 auf die Vorhersage von Aktualisie- rungsbedingungen B vorbereitet, indem aus problemspezifischen, exemplari- schen Trainingsdaten gewissermaßen eine mehrdimensionale Karte des Mobil- funknetzes erzeugt wird, die mit bestimmten Orts- und Zeitauflösungen Vo- raussagen zu Übertragungsqualitäten Q von zukünftigen Funkverbindungen 40 kartiert bzw. modelliert. Als problemspezifische Trainingsdaten werden dazu in den Schritten S5 bis S 7 insbesondere solche Sensordaten D von den Fahrzeu- gen 50 erhoben und der ML-Einheit 12 zur Verfügung gestellt, die konkret ge- messene Übertragungsqualitäten Q in möglichst vielen Funkzellen des Mobil- funknetzes und zu möglichst vielen Zeitpunkten abgestuft betreffen.

Zu diesem Zweck sind die Fahrzeuge 50 mit geeigneten Sensoren und Messein- richtungen ausgestattet, so dass sie im Schritt S5 Messungen hinsichtlich der Übertragungsqualitäten Q innerhalb der von den Fahrzeugen 50 besuchten Funkzellen vornehmen und als Sensordaten D an ein Sensordatenmodul 32 der Aktualisierungseinrichtung 30 übermitteln. Dazu werden die Sensoren geeignet aktiviert und deaktiviert, um zuverlässig die gewünschten Sensordaten D zu er- mittein, auf deren Basis das ML-Modell 13 trainiert wird. Die Sensordaten be- treffen neben der jeweils aktuellen Übertragungsqualität Q, beispielsweise in Form einer gemessenen Datenübertragungsrate, auch Zeit-/ Datums- und Orts- daten, letztere zum Beispiel in Form der Fuhkzellen-IDs des vermessenen Funk- netzes. Ferner werden auch Bewegungsprofile der Fahrzeuge 50 protokolliert, zum Beispiel in Form von GPS-Daten, und dem Sensordatenmodul 32 bereitge- stellt.

Das Sensordatenmodul 32 bereitet die Sensordaten D der Fahrzeuge 50 geeignet auf und stellt sie schließlich in Schritt S7 der ML-Einheit 12 als Trainingsdaten für das ML-Modell 13 zur Verfügung. In dem Schritt S6 bereitet das Sensorda- tenmodul 32 insbesondere die Bewegungsprofile der Fahrzeuge 50 so auf, dass für jedes Fahrzeug 50 zeitlich und örtlich möglichst gut aufgelöste Bewegungs- daten T an die ML-Einheit übergeben werden, die insbesondere Zeiten und Wege regelmäßiger Fahrten mit dem betreffenden Fahrzeug 50 ausweisen, zum Beispiel regelmäßige Fahrten zu und von einer Arbeitsstätte. Die individuellen Bewegungsdaten T bilden auch das unterschiedliche Fahrverhalten an den ein- zelnen Wochentagen ab, zum Beispiel aufgrund von Teilzeitarbeit, Home- Office-Tagen und sonstigen wöchentlich wiederkehrenden Fahrten.

Gemäß Fig. 2a finden sowohl Training als auch Vorhersage im Rahmen des Schrittes S8 statt, eine zeitliche Reihenfolge oder Abhängigkeit zwischen Trai- ning und Vorhersage, und damit der Schritte S1 bis S4 einerseits und der Schritte S5 bis S7 andererseits, erfordert die Ausführungsform gemäß Fig. 2a nicht. Vielmehr können diese beiden Gruppen von Schritten nahezu beliebig verzahnt sein, zum Beispiel derart, dass Schritt S1 zwischen den Schritten S5 und S6 einsetzt oder dass Schritt S4 zeitgleich mit Schritt S7 stattfindet.

Dies bedeutet konzeptionell, dass das ML-Modell 13 gemäß der Ausführungs- form nach Fig. 2a kontinuierlich trainiert wird basierend auf immer neuen, ak- tuellen Sensordaten D, die im Rahmen des Schrittes S7 fortwährend eingeliefert werden. Das ML-ModeU 13 ist dadurch lernend ausgestaltet, denn es passt sich immer wieder aktuellen Veränderungen der Verbindungsqualitäten Q und/o- der Bewegungsdaten T der Fahrzeuge 50 an. Eine Vorhersage zur Bestimmung von Aktualisierungsbedingungen B kann gemäß Fig. 2a also jederzeit durchge- führt werden und findet immer basierend auf dem zum betreffenden Zeitpunkt aktuellen ML-Modell 13 statt. Die gleiche Vorhersageanfrage kann also zu ei- nem späteren Zeitpunkt aufgrund eines aktuelleren ML-Modells 13 andere Ak- tualisierungsbedingungen B ergeben. Gemäß Fig. 2b ist die ML-Einheit 12 wie in Fig. 3 gezeigt unterteilt in ein Trai- ningsmodul 12a und ein Vorhersagemodul 12b. Diese Ausführungsform geht davon aus, dass die Trainingsphase des ML-Modells 13 gemäß Schritt S8a zu- erst vollständig abgeschlossen wird, bevor die Vorhersagephase gemäß Schritt S8b einsetzt. Insofern werden bei der Ausführungsform gemäß Fig. 2b zunächst die Schritte S5 bis S8a ausgeführt und erst danach, wenn ein stabiles, trainiertes

ML-Modell 13 vorliegt, werden die AktuaHsierungsbedingungen B mit den Schritten S1 bis S4 und S8b bestimmt. Die Schritte S1 bis S4, S5 bis S7, S9 und S10 sind in Fig. 2a und Fig. 2b technisch identisch, lediglich die Reihenfolge der Ausführung unterscheidet sich in den beiden Ausführungsformen, ebenso wie die Differenzierung des Schritts S8 gemäß Fig. 2a in zwei separate Teilschritte

S8a und S8b gemäß Fig. 2b. Die Nummerierung der Schritte gibt also keine zwingend einzuhaltende Ausführungsreihenfolge vor. Die Reihenfolge der Ausführung der Schritte gemäß den Figuren 2a und 2b wird vielmehr lediglich bestimmt durch (daten-)technische Abhängigkeiten und den Zweck des erfin- dungsgemäßen Verfahrens.

Beim Training des ML-Modell 13 werden die von den Fahrzeugen 50 ermittel- ten und von dem Sensordatenmodul 32 aufbereiteten Sensordaten D und Bewe- gungsdaten T verwendet, tun den Funkzellen zu den betreffenden Zeiten Über- tragungsqualitäten Q zuzuordnen. Denjenigen Funkzellen bzw. denjenigen Zeitpunkten oder Zeitintervallen, für die keine Sensordaten D erhoben wurden, werden beim Training des ML-Modells 13 aus den vorhandenen Sensordaten D abgeleitete Übertragungsqualitäten Q zugeordnet, um auf diese Weise die Karte auch hinsichtlich solcher Funkzellen und Zeitintervalle zu vervollständigen, für die keine originären Sensordaten D vorliegen. Dies kann zum Beispiel auch dann Vorkommen, wenn für eine Funkzelle lediglich widersprüchliche Sensor- daten D vorliegen oder nicht genügend oder ausreichend zuverlässige Sensor- daten D erhoben werden konnten.

Die Ableitung von Übertragungsqualitäten Q im Rahmen des Trainings wird basierend auf Ähnlichkeitskriterien zwischen Netzwerkzellen und/ oder be- stimmten Charakteristika von Funkverbindungen durchgeführt. Die örtliche Nähe einer Funkzelle ohne brauchbare Sensordaten D zu einer Funkzelle mit brauchbaren Sensordaten D ist beispielsweise ein einfaches Ähnlichkeitskrite- rium. Weitere sinnvolle Ähnlichkeitskriterien können die zeitabhängige Ver- kehrsdichte oder die Anzahl von Netzteilnehmem sein, beides ableitbar aus den Bewegungsdaten T, oder auch die Bebauung und prinzipiell jedes geeig- nete Kriterium, das Einfluss auf die Datenrate einer Funkverbindung hat. Diese Ähnhchkeitskriterien erlauben es, ähnliche Funkzellen zu Clustern zu gruppie- ren, die beim Training Sensordaten D und Übertragungsqualitäten Q miteinan- der teilen.

Mit dem trainierten ML-Modell 13 werden dann geeignete Aktualisierungsbe- dingungen B für die identifizierten Fahrzeuge 50 vorher gesagt und zu einem Aktualisierungsplan 14 zusammengefasst, der es erlaubt, die Software mög- lichst vieler Fahrzeuge 50 unterbrechungsfrei und innerhalb der vorgegebenen Zeitdauer einer Aktualisierungskampagne zu installieren.

Die Aktualisierungsbedingungen B werden basierend auf den Bewegungsdaten T der betroffenen Fahrzeuge ermittelt. Sie definieren entlang der protokollierten Fahrtwege der Fahrzeuge 50 eine oder mehrere mögliche Funkverbindungen 40, über die die Software aktualisiert werden kann. Die Aktualisierungsbedin- gungen B geben bestimmte Standorte, zum Beispiel in Form von regelmäßig von dem betreffenden Fahrzeug 50 besuchten Funkzellen, und entsprechende Zeiten vor, zu denen das ML-Modell 13 eine Funkverbindung 40 mit einer aus- reichenden Übertragungsqualität voraussagt, um die Software dieses Fahrzeugs 50 unterbrechungsfrei zu aktualisieren. Diese Voraussage trifft das ML-Modell 13 letztlich basierend auf den Sensordaten D und den daraus im Rahmen des Trainings abgeleiteten Übertragungsqualitäten Q.

Die Bewegungsdaten T bilden bei der Vorhersage von geeigneten Aktualisie- rungsbedingungen B wichtige Nebenbedingungen, denn sie schränken die po- tentiell zur Softwareaktualisierung einsetzbaren Funkverbindungen 40 ein auf die sinnvollen Funkverbindungen 40, die ein Fahrzeug 50 im Rahmen seiner Nutzung überhaupt aufbauen kann. Unter diesen sinnvollen Funkverbindun- gen 40, die das Fahrzeug 50 auf seinen regelmäßigen Fahrten aufbauen kann, ermittelt das ML-Modell 13 diejenigen, die voraussichtlich ausreichende Über- tragungsqualitäten Q bieten, um die unterbrechungsfreie Aktualisierung der Software zu gewährleisten.

Das ML-Modell 13 sagt für alle Fahrzeuge 50, die in der Liste L verzeichnet sind, Aktualisierungsbedingungen B voraus, die voraussichtlich eine unterbre- chungsfr eie Softwareaktualisierung erlauben. Dabei werden einerseits Konflikte zwischen den Aktualisierungsbedingungen B verschiedener Fahrzeuge 50 ver- mieden und andererseits eine globale Kosten- oder Verlustfunktion („loss func- tion") optimiert bzw. minimiert, die genau dann optimal/minimal wird, wenn für alle in der Liste L verzeichneten Fahrzeuge 50 Aktualisierungsbedingungen B gefunden werden können, die mit hoher Wahrscheinlichkeit eine unterbre- chungsfreie Softwareaktualisierung gewährleisten. Insgesamt minimiert der Aktualisierungsplan 14 die Gesamtzeit der Softwareaktualisierung aller Fahr- zeuge 50, da das ML-Modell 13 Aktualisierungsbedingungen B vorgibt, die nicht nur für einzelne Fahrzeuge 50 optimal sind, sondern für die Aktualisie- rungskampagne insgesamt.

In Schritt S9 wird der Aktualisierungsplan 14 schließlich an die Aktualisie- rungseinrichtung 30 bzw. deren Aktualisierungsmodul 33 übergeben, so dass in Schritt S10 die Aktualisierungskampagne vorbereitet wird und in Schritt Sil Anweisungen über die Funkverbindungen 40 an die betreffenden Fahrzeuge 50 zum Aktualisieren von deren Software ergehen.

Die Fig. 3 illustriert die ML-Einheit 12 unterteilt in deren beide bereits ange- sprochenen Module, nämlich das Trainingsmodul 12a und das Vorhersagemo- dul 12b. Entsprechend den bisherigen Erläuterungen ist der Trainingsschritt S8a, durchgeführt durch das Trainingsmodul 12a, prinzipiell unabhängig von dem Vorhersageschritt S8b, durchgeführt von dem Modul 12b. Entsprechend sieht die Ausführungsform, gemäß Fig. 2a vor, dass beide Module in dem Sinne parallel genutzt werden, dass jederzeit eine Vorhersage (Schritt S8b) basierend auf dem aktuellen Zustand des ML-Modells 13 durchgeführt wird, während das „lernende" ML-Modell 13 kontinuierlich mit immer neuen Sensordaten D trainiert wird (Schritt S8a). Die Ausführungsform gemäß Fig. 2b sieht demge- genüber kein in diesem Sinne „lernendes" ML-Modell 13 vor, denn das ML- Modell 13 wird dort im Hinblick auf eine erforderliche Aktualisierungskam- pagne eine bestimmten Zeit lang trainiert und wird dann, austrainiert, für die Bestimmung des Aktualisierungsplans 14 verwendet, ohne dass es Trends und Veränderungen lernend berücksichtigen würde.

Gemäß Fig. 3 erhält das Trainingsmodul 12a im Schritt S7 Sensordaten D sowie Bewegungsdaten T, aus denen Übertragungsqualitäten Q mit möglichst hoher zeitlicher und örtlicher Auflösung abgeleitet werden. Das ML-Modell 13 model- liert also in dem Trainingsschritt S8a die oben angesprochene Karte der Über- tragungsqualitäten Q. Der Vorhersageschritt S8b wird dann durchgeführt mit dem hinreichend trainierten ML-Modell 13, den von dem Trainingsmodul 12a an das Vorhersagemodul 12b übergebenen Bewegungsdaten T und der in Schritt S4 bereitgestellten Liste L der identifizierten Fahrzeuge 50 sowie den Zeitvorgaben Z. Durch den Schritt S8b werden schließlich aufgrund von Vo- raussagen hinsichtlich der Übertragungsqualitäten Q Aktualisierungsbedingun- gen B für alle Fahrzeuge 50 der Liste L bestimmt und daraus ein Aktualisie- rungsplan 14 gebildet, der festlegt, wann und auf welcher konkreten Fahrt die Software eines jeden Fahrzeugs 50 zu aktualisieren ist.

Fig. 4 illustriert schließlich die Umsetzung des Aktualisierungsplans 14 und der zugehörigen Aktualisierungsbedingungen B. In Schritt S9 wird der Aktualisie- rungsplan 14 an ein Aktualisierungsmodul 33 der Aktualisierungseinheit 30 übergeben, die dann die Aktualisierungskampagne startet und überwacht.

Dazu werden den identifizierten Fahrzeugen 50, bzw. den entsprechenden Steuereinrichtungen CNTL dieser Fahrzeuge 50, in Schritt Sil die diese Fahr- zeuge 50 betreffenden Aktualisierungsbedingungen B übergeben. Die Steuer- einrichtungen CNTL der Fahrzeuge 50 überwachen also selbständig das Vorlie- gen der jeweiligen Aktualisierungsbedingungen B. Das Aktualisieren der Soft- ware SW wird von der Steuereinrichtung CNTL dann in Schritt S12 durchge- führt, wenn die Aktualisierungsbedingungen B zutreffen, wenn sich das Fahr- zeug 50 also innerhalb des vorbestimmten Zeitintervalls in der/ den vorbe- stimmten Funkzelle/ n befindet bzw. sie durchfährt. Dazu wird in Schritt S13 die aktuelle Software SW* über die Funkverbindung 40 heruntergeladen, in dem Speicher 51 abgelegt und installiert.

Die aktuelle Software SW* liegt hierbei auf einem oder mehreren geeigneten Download-Servem zum Herunterladen durch die Fahrzeuge 50 bereit. Der Download-Server kann als Bestandteil der Aktualisienmgseinrichtung 30 oder als separate technische Entität ausgestaltet sein. Die Fig. 5 zeigt eine dritte bevorzugte Ausführungsform des erfindungsgemä- ßen Aktualisierungsverfahrens, welche auf der zweiten bevorzugten Ausfüh- rungsform gemäß Fig. 2b basiert. Die Fig. 5 unterscheidet sich von der Fig. 2b lediglich betreffend die Schritte S5 bis S8a der Fig. 2b, die in Fig. 5 durch die Schritte S5, S6 sowie S7a bis S7d ersetzt werden. Die Schritte S5, S6 sowie S7a bis S7d gemäß Fig. 5 können ebenso gut auch in der Ausführungsform gemäß Fig. 2a ergänzt werden.

Gemäß Fig. 5 umfasst die Hintergrundeinrichtung 10 statt dem Trainingsmodul 12a gemäß Fig. 2b ein Synthesemodul 12c, welches ein flottenübergreifendes ML-Modell 13a in der nachfolgend beschriebenen Weise synthetisiert. Die Ak- tuahsierungseinrichtung 30 umfasst statt dem Sensordatenmodul 32 gemäß Fig. 2b ein Weiterleitungsmodul 34, das die Datenkommunikation zwischen der Hintergrundeinrichtung 10 und den Fahrzeugen 50 bidirektional sicherstellt. Die Fahrzeuge 50 umfassen jeweils neben einem fahrzeugindividuellen ML- Modell 13b ein eigenes Sensordatenmodul 53, welches dem betreffenden Fahr- zeug 50 die Funktionalität des Sensordatenmoduls 32 der Fig. 2a bereitstellt, so- wie ein Trainings- und Synchronisationsmodul 52, welches einerseits die Funk- tion des Trainingsmoduls 12a gemäß Fig. 2b bereitstellt und andererseits das betreffende fahrzeugindividuelle ML-Modell 13b aktualisiert bzw. mit dem flot- tenübergreifenden ML-Modell 13a synchronisiert. Konzeptionell werden bei dieser Ausführungsform also die zentralen Funktionen des Trainingsmoduls 12a und des Sensordatenmoduls 32 gemäß Fig. 2b dezentralisiert und in jedes Fahrzeug 50 der Fahrzeugflotte integriert.

Dadurch wird sichergestellt, dass schützenswerte, personenbezogene Trai- ningsdaten, wie zum Beispiel die Sensordaten D und/ oder die Bewegungsda- ten T in den jeweiligen Fahrzeugen 50 verbleiben und insofern datenschutzkon- form vor Ausspähen und Missbrauch geschützt sind. Die Schritte S1 bis S4 und S9 bis Sil gemäß Fig. 5 sind identisch mit den ent- sprechend bezifferten Schritten der Figuren 2a und 2b. Ebenso sind ist der Schritt S8b in den Ausführungsformen gemäß den Figuren 2b und 5 identisch. Im Schritt S5 gemäß Fig. 5 werden in einem Fahrzeug 50 fahrzeugindividuelle

Messungen hinsichtlich der Übertragungsqualitäten Q innerhalb der von den betreffenden Fahrzeugen 50 besuchten Funkzellen vorgenommen und dem Sensordatenmodul 53 als Sensordaten D des betreffenden Fahrzeugs 50 bereit- gestellt. Das Sensordatenmodul 53 bereitet analog zur Funktion des Sensorda- tenmoduls 32 gemäß Fig. 2a und 2b die Sensordaten D und die individuellen

Bewegungsprofile des Fahrzeugs 50 geeignet zu möglichst gut aufgelösten Be- wegungsdaten T auf und stellt in Schritt S6 diese gemeinsam mit den Sensorda- ten D dem Trainings- und Synchronisationsmodul 52 des Fahrzeugs 50 zur Ver- fügung. In Schritt S7a trainiert das Trainings- und Synchronisationsmodul 52 das fahrzeugindividuelle ML-Modell 13b des Fahrzeugs 50 mit den fahrzeugin- dividuellen Sensor- und Bewegungsdaten D, T analog zur Funktion des Trai- ningsmoduls 12c gemäß Fig. 2b.

Die Schritte S7b bis S7e betreffen den Prozess des Synthetisierens (S7b, S7c) des flottenübergreifenden ML-Modells 13a, also dessen Zusammenführen aus den fahrzeugindividuellen ML-Modellen 13b, und des Synchronisierens (S7d, S7e) der jeweiligen fahrzeugindividuellen ML-Modelle 13b, also deren Aktualisie- rung basierend auf dem synthetisierten flottenübergreifenden ML-Modell 13a. Konzeptionell werden mittels der Schritte S7b bis S7e jedem einzelnen fahr- zeugindividuellen ML-Modellen 13b die individuellen Trainingsfortschritte al- ler fahrzeugindividuellen ML-Modellen 13b gebündelt zur Verfügung gestellt, um dadurch die Trainingsqualität insgesamt zu verbessern. Zu Beginn des Schrittes S7b liegt auf einem Fahrzeug 50 ein stabiles, trainiertes, fahrzeugindividuelles ML-Modell 13b vor, das Vorhersagen hinsichtlich der Übertragungsqualitäten Qb von Funkverbindungen basierend auf den Sensor- daten D des jeweiligen Fahrzeugs erlaubt. Initial können die so beurteilten Funkverbindungen natürlich nur aus Funkzellen stammen, die das betreffende Fahrzeug 50 tatsächlich besucht hat, für die das Fahrzeug also Sensordaten D bzw. Bewegungsdaten T ermittelt hat. Durch die regelmäßige Wiederholung von Synthese (Schritte S7b, S7c) und Synchronisation (Schritte S7d, S7e) werden jedem fahrzeugindividuellen ML-Modell 13b schrittweise immer mehr Informa- tionen zu Funkverbindungen in Funkzellen bereitgestellt, die andere Fahrzeuge 50 der Fahrzeugflotte besucht haben, so dass das betreffenden fahrzeugindivi- duelle ML-Modell 13b iterativ eine immer bessere Grundlage für die Vorher- sage der Übertragungsqualitäten Qb von Funkverbindungen in den besuchten Funkzellen bildet, da das betreffenden fahrzeugindividuelle ML-Modell 13b immer mehr Kontextwissen über andere Bereiche des Funknetzwerks erwirbt. Gemäß dem Schritt S7b schicken alle Fahrzeuge 50 der Fahrzeugflotte fahrzeug- individuelle Modelldaten Mb an das Weiterleitungsmodul 34 der Aktualisie- rungseinrichtung 30, die die Vielzahl von Modelldaten Mb fahrzeugweise oder bereits gebündelt an das Synthesemodul 12c der Hintergnmdeinrichtung 10 weiterleitet.

Als fahrzeugindividuelle Modelldaten Mb eines jeden fahrzeugindividuellen ML-Modells 13b erzeugt das jeweilige Trainings- und Synchronisationsmodul 52 inkrementelle Modelldaten Mb, die die Differenz zwischen dem Trainings- zustand des betreffenden fahrzeugindividuellen ML-Modells 13b zum aktuel- len Zeitpunkt (also zum Zeitpunkt des Ausführend des Schrittes S7b) und dem

Trainingszustand des fahrzeugindividuellen ML-Modells 13b zum Zeitpunkt nach dessen letzter Aktualisierung (also zum Zeitpunkt nach dem letztmaligen Ausführen des Schrittes S7e und vor dem letztmaligen Training in Schritt S7a) repräsentieren. Dieser fahrzeugindividuelle Trainingsfortschritt innerhalb des Zeitraums zwischen den beiden benannten Zeitpunkten wird mit den nachfol- genden Schritten S7c bis S7e an die fahrzeugindividuellen ML-Modelle 13b aller anderen Fahrzeuge 50 der Fahrzeugflotte weitergeben.

Die inkrementellen fahrzeugindividuellen Modelldaten Mb einzelner oder aller Fahrzeuge 50 werden im Schritt S7c von dem Synthesemodul 12c zusammenge- führt und zu einem aktuellen flottenübergreifendes ML-Modell 13a syntheti- siert, welches dann die aktuellen Trainingsergebnisse sämtlicher fahrzeugindi- viduellen ML-Modelle 13b in sich trägt. Nach dem Schritt S7c repräsentiert das flottenübergreifende ML-Modell 13a, ebenso wie die ML-Modelle 13 gemäß den Ausführungsformen nach Fig. 2a und 2b, ein stabiles, trainiertes, flottenüber- greifendes ML-Modell, welches Grundlage für die anschließende Vorhersage- phase gemäß dem Schritt S8b und die Ableitung von Aktualisierungsbedingun- gen B ist.

Der Unterschied zwischen der Ausführungsform gemäß Fig. 5 und den Aus- führungsformen gemäß den Figuren 2a und 2b liegt also unter anderem darin, dass das flottenübergreifende ML-Modell 13a und die Übertragungsqualitäten Qa zwar dieselbe Trainingsqualität und ein vergleichbares Vorhersagepotential besitzen wie das ML-Modell 13 gemäß den Figuren 2a und 2b, dass das flotten- übergreifende ML-Modell 13a jedoch nicht durch eine eigene Trainingsphase zustande kommt, welcher notwendig die sensiblen, personenbezogenen Sensor- daten D und Bewegungsdaten T zugrunde Hegen müssten, sondern durch den Syntheseschritt S7c, in dem ledighch hinsichtlich etwaiger Datenschutzbestim- mungen unproblematische, inkrementeile Modelldaten Mb zusammengeführt werden. Das Training findet bei der Ausführungsform gemäß Fig. 5 in den lo- kalen Schritten S7a auf den einzelnen Fahrzeugen 50 statt, so dass die jeweih- gen Sensordaten diese Fahrzeuge 50 nicht verlassen.

Die anschHeßenden Schritte S7d und S7e betreffen sie Synchronisation bzw. Ak- tuaHsierung der einzelnen fahrzeugindividuellen ML-Modelle 13b basierend auf flottenübergreifenden, inkrementellen Modelldaten Ma, welche im Schrit S7d aus dem flotenübergreifenden ML-Modell 13a extrahiert werden.

Die inkrementellen Modelldaten Ma repräsentieren die Differenz zwischen dem Trainingszustand des flotenübergreifenden ML-Modells 13a zum aktuellen

Zeitpunkt (also zum Zeitpunkt des Ausführend des Schrites S7d) und dem Trainingszustand des flotenübergreifenden ML-Modells 13a zum Zeitpunkt nach dessen vorletzter Synthese (also zum Zeitpunkt nach dem vorletztmaligen Ausführen des Schrites S7c).

Nachdem die flotenübergreifenden Modelldaten Ma im Schrit S7d von dem Synthesemodul 12c über das Weiterleitungsmodul 34 der Aktualisierungsein- richtung 30 an die jeweiligen Trainings- und Synchronisationsmodule 52 der einzelnen Fahrzeuge 50 geschickt wurden, wird auf all diesen Fahrzeugen 50 je- weils in einem Schrit S7e das betreffende fahrzeugindividuelle ML-Modell 13b mit den flottenübergreifenden Modelldaten Ma aktualisiert. Danach sind sämt- liche fahrzeugindividuellen ML-Modelle 13b synchronisiert und repräsentieren zu diesem Zeitpunkt den Trainingszustand des flotenübergreifenden ML- Modells 13a, bevor die einzelnen fahrzeugindividuellen ML-Modelle 13b im Rahmen des jeweiligen fahrzeugindividuellen Trainings wieder divergieren, in- dem sie basierend auf den weiterhin fahrzeugindividuell erhobenen Sensorda- ten D in einem erneuten Schrit S7a weitertrainiert werden.

Dieser Prozess bestehend aus der Synthese des flotenübergreifenden ML- Modells 13a durch die Schrite S7b und S7c und der Synchronisation der fahr- zeugindividuellen ML-Modelle 13b durch die Schritte S7d und S7e kann regel- mäßig wiederholt werden, beispielsweise nachdem vorgegebene Zeitintervalle verstrichen sind. Ebenso kann der Prozess der Schritte S7a bis S7e auch durch bestimmte Ereignisse veranlasste werden, beispielsweise wenn ein ausreichen- der Trainingsfortschrit bei einzelnen, einer bestimmten Anzahl oder allen fahr- zeugindividuellen ML-Modellen 13b erzielt wurde oder wenn ausreichende neue Sensordaten D erhoben wurden, die eine erneute Synthese/ Synchronisa- tion nötig werden lassen.

Ferner können die fahrzeugindividuellen Modelldaten Mb aus den einzelnen fahrzeugindividuellen ML-Modellen 13b synchron erzeugt und nahezu zeit- gleich dem Weiterleitungsmodul 34 bereitgestellt werden. Bereits das Weiterlei- tungsmodul 34 kann die fahrzeugindividuellen Modelldaten Mb der Fahrzeuge 50 bündeln und an das Synthesemodul 12c als ein Datensatz weiterleiten. Die- sen Datensatz würde dann das Synthesemodul 12c mit den flottenübergreifen- den ML-Modell 13a kombinieren und dadurch ein neues flottenübergreifenden ML-Modell 13a bilden, dass die Trainingsfortschritte aller fahrzeugindividuel- len ML-Modelle in sich vereint.

Alternativ können die Fahrzeuge 50 jeweils ihre fahrzeugindividuellen Modell- daten Mb imabhängig voneinander an das Weiterleitungsmodul 34 schicken und von diesem zwischengespeichert und erst dann gebündelt an das Synthese- modul 12c weitergeleitet werden, wenn ein ausreichend großer Datensatz aus fahrzeugindividuellen Modelldaten Mb verschiedener Fahrzeuge 50 vorliegt.

Ein praktisches und nicht beschränkendes Beispiel eines ML-Modells 13, so wie es im Zusammenhang mit den Figuren 2 bis 5 beschrieben ist, besitzt Ausgangs- bzw. Ergebnisklassen (Output) für unterbrechungsfreie Mobilfunkverbindung verschiedener Dauer:

- Verbindungen, die 0 bis 5 Minuten unterbrechungsfrei waren;

- Verbindungen, die 5 bis 10 Minuten unterbrechungsfrei waren;

- Verbindungen, die 10 bis 20 Minuten unterbrechungsfrei waren;

- Verbindungen, die 20 bis 30 Minuten unterbrechungsfrei waren;

- Verbindungen, die 30 bis 45 Minuten unterbrechungsfrei waren;

- Verbindungen, die 45 bis 60 Minuten unterbrechungsfrei waren; und

- Verbindungen, mehr als 60 Minuten unterbrechungsfrei waren. Als Eingangskategorien (Input) des ML-Modells 13 werden relevante Zeitanga- ben verwendet, wie etwa

- Kategorie „Tageszeit" mit sechs Merkmalen, nämlich „früh morgens", „morgendlicher Berufsverkehr", „mittags", „abendlicher Berufsverkehr", „abends", „nachts";

- Kategorie „Wochentag" mit sieben Merkmalen entsprechend den einzel- nen Wochentagen;

- Kategorie „Feiertag" als ein binäres Merkmal mit den Merkmalswerten „ja" und „nein";

- Kategorie „Urlaubszeit" als ein binäres Merkmal mit den Merkmalswer- ten „ja" und „nein"; sowie Eingangskategorien mit kontinuierlichen, numerischen Werten:

- Kategorie "Signalstärke" mit der mittleren Signalstärke der vergangenen 5 Minuten minus einem Offset-Wert dividiert durch die Standardabwei- chung;

- Kategorie „Fahrtzeit" mit einer numerischen Angabe der verstrichenen Zeit seit dem Beginn der Fahrt in Stunden; oder topologische Angaben:

- Kategorie „Standort" mit einer Identifikation der Mobilfunkzelle, in der sich das Fahrzeug 50 aktuell oder zu Beginn der Fahrt befindet;

- Kategorie „Fahrtrichtung" mit der Angabe einer Folge von zwei benach- barten Mobilfunkzellen, die die aktuelle Fahrtrichtung charakterisieren. Das ML-Modell 13 umfasst einen Klassifikator, der auf Entscheidungsbäumen basiert, wie etwa einen Random-Forest-Klassifikator oder einen Extreme-Gra- dient-Boosting-Klassifikator. Derartige Klassifikatoren können selbst mit den beschränkten Ressourcen in einem Fahrzeug 50 und bei kleinen Trainingsda- tensätzen effizient mit der Hardware eines Fahrzeugs 50 betrieben werden, denn sie können schnell trainiert werden und sind leicht parallelisierbar.

Die konkrete Definition der Ausgangsklassen und der spezifischen Merkmale wird in Abhängigkeit von bestimmten Vorbedingungen ausgewählt bzw. kon- figuriert, zum Beispiel abhängig von der Region, in der sich die betreffenden Fahrzeuge 50 bewegen, oder von saisonalen oder kulturellen Umständen oder dergleichen. Abhängig von solchen Vorbedingungen werden die Fahrzeuge 50 mit vortrainierten, ML-Modellen 13 (oder flottenübergreifenden ML-Modellen 13a) ausgestattet, die dann in den betreffenden Fahrzeugen 50 individuell wei- ter trainiert werden und dann fahrzeugindividuelle ML-Modelle 13b bilden.

Verdeutlicht anhand der beiden Kategorien „Standort" und „Fahrtrichtung" umfasst das vortrainierte ML-Modell 13 (oder 13a) Zuordnungen der Auftritts- wahrscheinlichkeiten der Ausgangsklassen zu den verschiedenen Standorten und Fahrtrichtungen. Einer konkreten Kombination aus Standort und Fahrt- richtung ist etwa der Vektor (0,06; 0,13; 0,18; 0,22; 0,26; 0,12; 0,03) zugewiesen, was bedeutet, dass in der betreffenden Situation statistisch 6% aller Mobil- funkverbindungen zwischen 0 und 5 Minuten stabil bzw. unterbrechungsfrei waren, 13% aller Mobilfunkverbindungen zwischen 5 und 10 Minuten stabil bzw. unterbrechungsfrei waren, etc.

Diese statistischen Werte, die in das vortrainierte ML-Modell 13 (oder 13a) ein- gehen und dessen Trainingsdaten repräsentieren, werden einer Karte entnom- men, die historische Werte umfasst, welche in der Vergangenheit von Fahrzeu- gen 50 gesammelt wurde und welche kontinuierlich von den aktuell beteiligten Fahrzeugen 50 aktualisiert werden. Sind für einzelne Situationen bzw. Karten- elemente keine zuverlässigen historischen Werte verfügbar, werden fahrzeug- spezifische Standardwerte eingesetzt, zum Beispiel in Form des Vektors (0,1; 0,1; 0,2; 0,2; 0,25; 0,1; 0,05).