Verfahren zum optimierten Ausrollen von Softwareaktualisierungen

Die Erfindung betrifft ein Verfahren zum optimierten Ausrollen von Softwareaktualisierungen an eine Fahrzeugflotte, nach der im Oberbegriff von Anspruch 1 näher definierten Art.

Das Ausrollen von Softwareaktualisierungen an Fahrzeugen kann technisch eine große Herausforderung darstellen, da häufig eine sehr große Anzahl von Fahrzeugen mit der entsprechenden Softwareaktualisierung versorgt werden muss. Um dies zu erleichtern, schlägt beispielsweise die DE 10 2018 205615 A1 vor, die Softwareaktualisierung nur an bestimmten nach technischen Voraussetzungen bezüglich der Kommunikationsverbindung ausgewählte Fahrzeuge zu übertragen, welche dann als Replikatoren dienen, um die Softwareaktualisierung an andere Fahrzeuge der Fahrzeugflotte weiterzugeben.

Die US 10 042 635 B2 beschreibt ebenfalls eine Methode, um drahtlos eine Softwareaktualisierung auszurollen. Bei dieser Art Verteilung von Softwareaktualisierungen, welche auch mit dem Begriff Over The Air (OTA) bezeichnet wird, wird für die Software über drahtlose Kommunikation verteilt. Auch diese Schrift verteilt die auszurollende Softwareaktualisierungen nicht pauschal an alle Fahrzeuge, sondern prüft die technischen Aspekte der Fahrzeuge, beispielsweise das Baujahr, den Bautyp usw. ab, um eine Auswahl derjenigen Fahrzeuge zu treffen, welche die Softwareaktualisierung erhalten sollen.

Neben der reinen Verteilung der Softwareaktualisierung spielt in der Praxis auch die Qualität der verteilten Softwareaktualisierung eine entscheidende Rolle. Sinnvoll wäre es diese vorab ausführlich zu testen, bevor sie an die gesamte Fahrzeugflotte oder zumindest einen größeren Teil einer Fahrzeugflotte ausgerollt werden. Die Problematik bei derartigen Testungen im Fahrzeugbereich liegt dabei in der typischerweise eher kleinen Anzahl von verfügbaren Fahrzeugen für die Testung. In einer willkürlich ausgewählten Gruppe sind dann sehr wenige Fahrzeuge bei denen Testung brauchbare reproduzierbare Ergebnisse innerhalb einer geeigneten Zeitspanne liefert. Diese Problematik wird in dem Artikel „Size matters? Or not: A/B testing with limited sample in automotive embedded software“ von Liu et al https://arxiv.org/abs/2107.02461v2, 10 Nov. 2021 thematisiert.

Die Aufgabe der hier vorliegenden Erfindung besteht nun darin, ein verbessertes Verfahren zum Ausrollen von Softwareaktualisierungen anzugeben, welches eine der eigentlichen Ausrollung der Software vorgeschaltete Evaluationsphase mit Hocheffizienz beinhaltet.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Unteransprüchen.

Bei dem erfindungsgemäßen Verfahren zum Ausrollen von Softwareaktualisierungen an eine Fahrzeugflotte ist es so, dass ähnlich wie im eingangs genannten Stand der Technik zuerst an eine Teilmenge der Fahrzeugflotte ausgerollt wird, welche anhand von gesammelten Daten der Fahrzeuge der Fahrzeugflotte bestimmt wird. Erfindungsgemäß umfassen die gesammelten Daten charakteristische Fahrzeugvektoren, welche aus Daten der Fahrzeugsensoren gebildet werden. Ferner umfassen die Daten einen charakteristischen Nutzervektor, welcher aus Daten zum Fahrverhalten wie beispielsweise den Fahrstil oder Emotionen, aber auch aus physiologischen Daten und Umgebungsdaten gebildet werden. Diese beiden Vektoren werden dann über einige oder alle Fahrzeuge der Fahrzeugflotte hinweg aggregiert.

Im nächsten Schritt werden Systemgrenzen im bisherigen Stand der Software analysiert, an welchen durch die Softwareaktualisierung eine Optimierung erfolgen soll. Derartige Systemgrenzen können beispielweise Grenzen der Sensoren, wie beispielweise die Reichweite oder Auflösung einer Kamera, aber auch physikalische Grenzen wie beispielweise der Reibwert bei Nässe oder besonders Gegebenheiten sein wie beispielsweise eine Gestenerkennung, wenn der Fahrzeugnutzer eine Winterjacke trägt.

Das Erkennen der Systemgrenze kann dabei beispielweise automatisiert in der Art erfolgen, dass beispielsweise bei einer Systemgrenze einer Spurhalteassistenz ein entsprechend starkes manuelles Eingreifen in die Lenkung in der entsprechenden Situation erkannt worden ist, beispielsweise bei Regen und schlecht erkennbaren, z.B. gelben, Fahrbahnmarkierungen im Bereich einer Autobahnbaustelle oder dergleichen. Alternativ dazu wäre es auch denkbar, dass der Nutzer des Fahrzeugs eine aktive Rückmeldung gibt, dass die entsprechende Fahrzeugfunktion gerade an einer ihrer Systemgrenzen gestoßen ist.

Diese so erkannten Systemgrenzen dienen dann dazu einen an diesen Systemgrenzen geltenden charakteristischen Grenzvektor zu ermitteln. Damit liegen nun also mit dem Fahrzeugvektor, dem Nutzervektor und dem Grenzvektor verschiedene Vektoren vor, welche jeweils mehrere Datensätze umfassen. Um nun eine für das begrenzte Ausrollen der Softwareaktualisierung geeignete Zielgruppe zu ermitteln, wird bei dem erfindungsgemäßen Verfahren ein Abstandsmaß zwischen dem charakteristischen Grenzvektor und dem charakteristischen Fahrzeug- und Nutzervektoren der Fahrzeugflotte ermittelt. Hieraus lässt sich dann eine erste Zielgruppe von Fahrzeugen mit minimalem Abstandsmaß und eine zweite Zielgruppe von Fahrzeugen mit maximalem Abstandsmaß ermittelt. In der ersten Zielgruppe befinden sich also all jene Fahrzeuge, welche relativ häufig an die entsprechenden Systemgrenzen stoßen. Diese erste Zielgruppe eignet sich also nun ideal um eine Softwareaktualisierung, welche an sie ausgerollt wird, dahingehend zu überprüfen und zu evaluieren, ob die gewollte verbesserte Performance im Bereich der Systemgrenzen, insbesondere ein Verschieben der Systemgrenzen hin zu einem größeren beziehungsweise verbesserten Erfassungsbereich oder dergleichen effizient funktioniert. Die zweite Zielgruppe mit maximalem Abstandsmaß bezeichnet dahingegen eine Gruppe von Fahrzeugen innerhalb der Fahrzeugflotte, für welche die entsprechende Systemgrenze meist unbedeutend ist, weil von diesen Fahrzeugen und ihren Nutzern eben diese Systemgrenze quasi nie erreicht wird, sodass von dieser Systemgrenze für die entsprechenden Nutzer und/oder Fahrzeuge keine nachteilige Einschränkung ausgeht.

Beide Zielgruppen lassen sich nun bei dem erfindungsgemäßen Verfahren je nach Zielsetzung entsprechend nutzen, um die Softwareaktualisierung zuerst an die erste und/oder zweite Zielgruppe oder jeweils eine Teilmenge dieser ersten und/oder zweiten Zielgruppe auszurollen und die Performance der ausgerollten Softwareaktualisierung zu evaluieren. Nach erfolgreicher Evaluation kann die Ausrollung der entsprechenden Software dann an weitere Teile der Fahrzeugflotte entsprechend erfolgen, oder falls die Software auf eine gesamte Fahrzeugflotte ausgerollt werden soll auch an diese.

Die Erfindung bietet dabei den entscheidenden Vorteil, dass Softwareaktualisierungen zuerst an den entsprechenden Zielgruppen oder Teilen dieser Zielgruppen getestet werden können. Die Zielgruppen lassen sich aufgrund der Erfassung der charakteristischen Vektoren und des Abstandsmaß zwischen dem Grenzvektor und den Nutzer- und Fahrzeugvektoren dementsprechend außerordentlich effizient auswählen, sodass es nicht im statistischen Zufall überlassen bleibt, ob die Fahrzeuge die neu implementierten Funktionen nutzen oder eben nicht. Vielmehr erlaubt die gezielte Auswahl der Zielgruppen über die Erfindung ein sehr effizientes Testen der neuen Funktionen der Softwareaktualisierung im Bereich der Systemgrenzen bei der ersten Zielgruppe oder dementsprechend bei der alternativ oder ergänzend gewählten zweiten Zielgruppe ein Test, ob die Softwareaktualisierung auch fernab der Systemgrenzen zuverlässig operiert.

Erst im Anschluss, also im Falle einer positiven Evaluation der Überwachung der einen und/oder der anderen Zielgruppe kann dann entschieden werden, ob die Software auf die geplanten Teile der Fahrzeugflotte ausgerollt wird, oder ob eine weitere Entwicklungsstufe durchlaufen werden muss, um die Software noch weiter zu optimieren.

Dementsprechend kann es gemäß einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens vorgesehen sein, dass zur Evaluation der ausgerollten Softwareaktualisierung ein Performancemaß bestimmt wird, wobei ein positives Ergebnis der Evaluation angenommen und eine Evaluationsbit auf 1 gesetzt wird, wenn das Performancemaß einen vorgegebenen Schwellenwert übersteigt, und wobei eine negative Evaluation angenommen und das Evaluationsbit auf 0 gesetzt oder bei 0 belassen wird, wenn das Performancemaß den Schwellenwert eben nicht erreicht. Wie bereits angekündigt ist es erfindungsgemäß vorgesehen, die weitere Ausrollung der Softwareaktualisierung nur für den Fall vorzunehmen, dass die Evaluation positiv war.

Eine weitere Alternative Möglichkeit zur Evaluation der Softwareaktualisierung kann es dabei vorsehen, dass diese nur an eine Teilmenge der ersten und/oder zweiten Zielgruppe ausgerollt wird, wonach die Performance im Vergleich zu einer weiteren Teilmenge der jeweils ersten und/oder zweiten Zielgruppe als Vergleichsgruppe erfolgt, wobei die Evaluation in diesem Fall unter einer vorgegebenen Fragestellung erfolgt. Anstelle des Einsatzes eines Performancemaßes, welche die Funktion im Wesentlichen gegenüber theoretischen Vorgaben ermittelt, kann hier also durch das Aufteilen der Zielgruppen in typischerweise zwei vergleichbare Teilmengen ein Vergleichsversuch vorgenommen werden. Ein solcher Vergleichsversuch, welcher auch als A/B-Versuch beziehungsweise A/B-Testing bezeichnet wird, benötigt typischerweise eine entsprechende Fragestellung und zwei Vergleichsgruppen. Je größer diese Vergleichsgruppen sind, desto besser lassen sich statistische Auswertungen vornehmen, wie es in dem eingangs zitierten Artikel „Size matters? Or not: A/B testing with limited sample in automotive embedded software“ beschrieben ist. Bei dem Verfahren gemäß der Erfindung erfolgt nun jedoch die Auswahl der Zielgruppen bereits sehr zielgerichtet auf die gewünschte Optimierung im Hinblick auf analysierte Systemgrenzen hin. Dadurch sind für das erfindungsgemäße Verfahren auch relativ kleine Teilmengen für eine zuverlässige Evaluation anhand eines solchen Vergleichstests bereits ausreichend.

Typischerweise wird der Vergleichstest nun zwischen der einen Teilmenge mit der Softwareaktualisierung und der anderen Teilmenge ohne die Softwareaktualisierung durchgeführt, insbesondere unter der Fragestellung, ob die Teilmenge mit der Softwareaktualisierung eine signifikant bessere Performance erfährt, beispielsweise weniger kritische Fahrsituationen, weniger Unfälle, einen verbesserten Komfort für den Nutzer oder dergleichen. Das Verfahren zur Evaluation mit zwei Vergleichsgruppen, wobei prinzipiell natürlich auch mehr als zwei Vergleichsgruppen, also mehr als zwei Teilmengen je Zielgruppe, denkbar sind, kann auch dahingehend erweitert werden, dass auf die Vergleichsgruppe oder bei mehr als zwei Teilmengen auf eine der Teilmenge eine Alternative Variante der Softwareaktualisierung ausgerollt wird. Hierdurch ließen sich bei zwei Teilmengen, also zwei alternative Lösungen, um den Problemen an der Systemgrenze zu begegnen, gegeneinander testen. Bei drei Teilmengen ließen sich die beiden Alternativen auch im Vergleich zur bisherigen Softwarelösung entsprechend testen, um so evaluieren zu können, welche der Softwareaktualisierungen die beste Performance bietet und damit diejenige ist, die bevorzugt auf eine größere Anzahl von Fahrzeugen ausgerollt werden soll.

Für alle Varianten ist es dabei so, und so ist es gemäß einer sehr vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens vorgesehen, dass im Falle einer negativen Evaluation die Softwareaktualisierung zuerst optimiert und dann erneut an die Zielgruppen oder Teilmengen der Zielgruppen ausgerollt wird, um die optimierte Softwareaktualisierung wiederrum zu evaluieren. Diese Schleife lässt sich so lange wiederholen, bis die Softwareaktualisierung eine positive Evaluation erhalten hat und dementsprechend auf weitere Teile der Fahrzeugflotte ausgerollt werden kann. Dieser Ansatz kann dabei insbesondere zur Entwicklung und zum Trainieren von Funktionsapproximationen und Methoden des maschinellen Lernens genutzt werden, deren Systemgrenzen unscharf sind und daher erprobt werden müssen. Diese Erprobung kann nun innerhalb der Zielgruppen vergleichsweise einfach und effizient erfolgen, bevor die Softwareaktualisierung auf die ganze Fahrzeugflotte oder große Teile der Fahrzeugflotte ausgerollt werden muss. Insbesondere stellt dies im Falle einer negativen Evaluation einen besonderen Vorteil dar, da so verhindert werden kann, dass potentielle Softwarefehler oder Probleme in der Softwareaktualisierung sich auf eine große Zahl von Fahrzeugen verbreiten und nur mit großer Mühe wieder rückgängig gemacht werden können.

Gemäß einer weiteren sehr vorteilhaften Ausgestaltung des Verfahrens gemäß der Erfindung soll die Aggregation der Fahrzeugvektoren und der Nutzervektoren dabei in einem fahrzeugexternen Server, insbesondere dem Backend-Server eines Fahrzeugherstellers, erfolgen. An diesen werden die einzelnen Vektoren der Fahrzeuge entsprechend übermittelt, um so mit der vergleichsweise großen zur Verfügung stehenden Rechenleistung dieses Servers die Aggregation vornehmen zu können.

Eine besonders günstige Weiterbildung sieht es dabei vor, dass diese Aggregation mittels Clustering-Verfahren erfolgt.

Der charakteristische Vektor im Bereich der Systemgrenzen, also der Grenzvektor, kann dabei gemäß einer sehr vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens dadurch ermittelt werden, dass zum Zeitpunkt des Auftretens der Systemgrenze einer Fahrzeugfunktion die Daten von Fahrzeugsensoren wie beispielsweise Kamera, Radar, Lidar und Ultraschall, Temperatur, haptische Sensoren oder interne Zustände einer Implementierung eine Fahrzeugfunktion herangezogen werden, um auf dieser Basis den Grenzvektor entsprechend zu ermitteln. Damit kann also eine Menge an Datenpunkten für die Grenzvektoren gesammelt werden. Ein Datenpunkt kann dabei bereits einen Grenzvektor beschreiben, es ist aber auch möglich, z.Bsp. eine Vielzahl von Datenpunkten durch ein Verfahren, z.Bsp. Mittelwertbildung, Medianbildung, zu einem Grenzvektor zusammenzuführen. Es entsteht ein Datensatz, welcher jedem Grenzvektor eine Systemgrenze zuordnet.

Ein bevorzugte Weiterbildung hiervon kann es vorsehen, dass der anhand der durch die erfassten und gespeicherten Daten bestimmte Grenzvektor der jeweiligen Systemgrenze zugeordnet wird, wonach eine vereinfachtes Modell gebildet wird, um die sich bei der Zuordnung ergebende Zuordnungsvorschrift abzubilden und potenziellen Veränderungen nachzuführen. Die Zuordnung ergibt also eine Eingangsvoraussetzung für ein überwachtes maschinelles Lernen, welches eine Zuordnung von Eingangs- zu Ausgabegrößen benötigt. Mit den erfassten und gespeicherten Daten lässt sich so das vereinfachte Modell bilden, indem die Zuordnungsvorschrift in einem Trainingsschritt in dem Modell abgebildet wird. Dies kann z.B. über Methoden des maschinellen Lernens erfolgen.

Der Fahrzeugvektor lässt sich gemäß einer sehr vorteilhaften Weiterbildung beispielsweise anhand annähernd konstanter und/oder zeitlich veränderlicher Daten entsprechend ermitteln, wie beispielsweise Lastkollektive oder Geschwindigkeiten. Der Fahrzeugvektor für das erfindungsgemäße Verfahren kann gemäß einer sehr vorteilhaften Weiterbildung eben dieses Verfahrens dadurch gebildet werden, dass Daten der Fahrzeugsensoren die Geschwindigkeiten, Lenkwinkel, Drehmomente, Betriebsarten sowie die Zustände von Fahrzeugsystem, beispielsweise des Triebstrangs, einer Batterie usw. erfasst und der Bildung des charakteristischen Vektors zugrunde gelegt werden.

Der charakteristische Nutzervektor lässt sich gemäß einer sehr vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens aus dem Verhalten des Fahrers, also seinem Fahrstil und eventuellen Emotionen sowie Umgebungsdaten bilden. Beispielhafte Größen können dabei je nach Funktion variieren, können aber beispielsweise Lenkgeschwindigkeiten, Beschleunigungen und ähnliches umfassen. Daneben können Gesichtsausdrücke wie beispielsweise ein Lächeln ebenso berücksichtigt werden wie Daten einer Müdigkeitsüberwachung, beispielsweise die Lidschlagfrequenz, ein eventuell aufgetretener Sekundenschlaf. Darüber hinaus können Tageszeit, Wetter, Objekte in und um das Fahrzeug und ähnliches Berücksichtigung finden und in den Nutzervektor einfließen, welcher dann, bevorzugt über die oben beschriebenen Clustering-Verfahren, über die Fahrzeuge der Fahrzeugflotte, vorzugsweise auf dem Backend-Server zusammen mit den anderen Vektoren entsprechend aggregiert wird. Das erfindungsgemäße Verfahren ermöglicht es dabei auch eine so evaluierte Software nur auf verschiedene Teile von Fahrzeugen innerhalb der Fahrzeugflotte auszurollen, sodass individuelle Softwarestände innerhalb der Fahrzeugflotte denkbar sind. Ferner können verschiedene Softwareänderungen in unterschiedlichen Softwareständen zusammengefasst werden, um so modulare Softwarebausteine innerhalb der Fahrzeugflotte zu verteilen, was Kapazitäten bei der Übertragung der Softwareaktualisierung einsparen kann, wenn immer nur bestimmte modulare Bausteine ausgetauscht beziehungsweise aktualisiert werden müssen.

Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens und seiner Anwendung ergeben sich auch aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die Figuren näher dargestellt ist.

Dabei zeigen:

Fig. 1 eine schematische Darstellung der Übermittlung von Informationen eines Fahrzeugs einer Fahrzeugflotte in eine Cloud als fahrzeugexternen Server;

Fig. 2 eine schematische Darstellung der Übermittlung von Informationen zu Systemgrenzen einer Fahrzeugfunktion eines Fahrzeugs einer Fahrzeugflotte in die Cloud;

Fig. 3 eine erste beispielhafte 2-dimensionale Repräsentation zu Illustration von aggregierten Fahrzeug- und Nutzervektoren sowie Grenzvektoren zur Bildung des Abstandsmaßes.

Ziel ist es, ein zielgruppenorientiertes und somit effektives Testen, Verifizieren und Ausrollen von Softwareaktualisierungen, sog. Software-Updates, für Fahrzeugfunktionen zu erzielen.

Dazu werden im ersten Schritt Charakteristika aus der Fahrzeugflotte gesammelt. Sensordaten im Fahrzeug werden ermittelt, zu charakteristischen Vektoren V zusammengefügt und gespeichert. Diese Vektoren V können entweder zeitlich annährend konstant (z.B. Lastkollektive) oder zeitlich veränderlich (z.B. gegenwärtige Geschwindigkeiten) sein. Aus den Vektoren V werden nun charakteristische Fahrzeugvektoren VFzg gebildet, die aus Fahrzeugsensorwerten wie Geschwindigkeiten, Lenkwinkeln, Drehmomenten, Betriebsarten und Zuständen von Fahrzeugsystemen, Triebstrang, Batterien usw. aufgebaut sind. Daneben werden charakteristische Nutzervektoren Vilser aus dem Verhalten des Fahrers wie Fahrstil/Emotionen bzw. Umgebungsdaten gebildet. Beispielhafte Größen variieren je nach Funktionen, können aber z.B. Lenkgeschwindigkeiten, Beschleunigungen, Lächeln, Lidschlagfrequenz, Pulsfrequenz, Sekundenschlaf, Wetter, Objekte im und um das Fahrzeug usw. sein.

In der Darstellung der Figur 1 ist eine Fahrzeug 10 zu erkennen, in welchen diese beiden Vektoren VUser und VFzg ermittelt und über eine Kommunikationseinheit 11 an einen fahrzeugexternen Server, z.B. ein Backend 12 des OEM geschickt werden. Dieser ist hier als Cloud angedeutet. Dort können die Vektoren über VUser und VFzg mehrere Fahrzeuge 10 oder auch über alle Fahrzeuge einer Fahrzeugflotte zu den Gruppen VFzgGi und VUserGi aggregiert werden. Dazu kommen Clustering-Verfahren zum Einsatz.

Im zweiten Schritt sollen Systemgrenzen von Fahrzeugfunktionen wie Fahrerassistenzsysteme (ADAS-Advanced Driver Assistance System), Gestenerkennung, Müdigkeitserkennung usw. bei einem aktuellen Softwarestand SW1 ermittelt werden. Systemgrenzen, können vielerlei Natur sein, z.B. Sensorgrenzen (z.B. Reichweite einer Kamera), physikalischen Grenzen (Reibwert bei Nässe) oder besonderen Gegebenheiten (Gestenerkennung mit Winterjacke). Ziel ist es, im Rahmen der Entwicklung die Systemgrenzen von SW1 durch Optimierung von Hardware und/oder Software zu verschieben, um dem Nutzer eine bessere Performance der Fahrzeugfunktion anbieten zu können. Dazu werden charakteristische Grenzvektoren VGrenzeJ zum Zeitpunkt des Auftretens der Systemgrenze einer Fahrzeugfunktion 13 ermittelt, welche in Figur 2 schematisch angedeutet ist. Für die Bildung der Vektoren werden wieder Werte von Fahrzeugsensoren wie Kamera, Radar, Lidar, Ultraschall, Temperatur, haptische Sensoren oder interne Zustände einer Implementierung der Fahrzeugfunktion 13 herangezogen.

Im einfachsten Fall können Systemgrenzen manuell durch den Fahrer oder Mitfahrer markiert (gelabelt) werden. Bei einem Spurhaltesystem als Fahrzeugfunktion 13 erkennt eine Kamera die Fahrbahnmarkierungen rechts und links und versucht das Fahrzeug innerhalb der Spuren zu führen. Ist nun z.B. in einer gewissen Situation die Erkennungsleistung reduziert, z.B. bei Autobahnfahrt und Regen, so kann es sein, dass die Spurhaltung nicht in der gewohnten Art und Weise funktioniert. Ein Fahrer kann die reduzierte Performance als Systemgrenze seines Systems erkennen, da er ggfs. selbst mitlenken muss, und löst z.B. durch eine Eingabefunktion das Labeln dieser Systemgrenze aus. Das System legt dann einen Grenzvektor VGrenze_1 ab, dieser enthält vorab definierte Features, z.B. [Geschwindigkeit = 120km/h, Straßentyp = Autobahn, Regen 50%, Spurhaltesystem = Aktiv usw.]. Die definierten Features müssen dabei auch Element von VfzgGi oder VUserGi sein. Vorteilhafterweise werden die Systemgrenzen aber automatisch (systematisch) erkannt, z.B. wenn der Fahrer auf der Autobahn bei Regen bei aktivem Spurhaltesystem 13 stark lenkt [Lenkwinkeländerung > x Grad pro Sekunde ODER Lenkmoment > y Newtonmeter], In diesem Fall wird der Vektor VGrenze_2 automatisch abgelegt, z.B. [Geschwindigkeit = 120km/h, Straßentyp = Autobahn, Regen 50%, Spurhaltesystem = Aktiv, ..].

Ein weiteres Beispiel für die systematische Erkennung von Systemgrenzen kann bei einer Reichweitenprognose als Fahrzeugfunktion 13 aufgezeigt werden, die die Restreichweite bzw. Batterieladung am Zielort prädiziert. Weicht die prädizierte Reichweite bzw. Batterieladung am Zielort um mindestens z% von der prädizierten Reichweite bzw. Batterieladung ab, so wird ein Vektor VGrenze_3 automatisch abgelegt: [Abweichung z = 5%, Länge der Strecke = 120km, Verteilung der Straßentypen = [50%, 20%, 30%]x[Autobahn, Landstraße, Stadt], Höhenmeter aufwärts/abwärts = [300m, 100m], Temperatur = -10 Grad usw.].

Auch kann es sein, dass Sensoren systematisch physikalische Grenzen aufweisen. Z.B. erfahren die Radarwellen eines Radarsensors bei starker Nässe eine hohe Dämpfung, so dass er nur reduziert Radarreflektionen empfangen kann. Hat ein Radarsensor ein integriertes Verfahren, dass die Dämpfung messen kann, so kann z.B. bei einer Reduktion von der Radarreflektionen um >50% ein Vektor VGrenze_4 abgelegt werden: [Radarreflektion < 50%, Scheibenwischer >=Stufe 2, Temperatur = 15 Grad, radarbasiertes ADAS System = Aktiv usw.]

Um nun die charakteristischen Vektoren VGrenze den Gruppen VfzgGi bzw. VUserGi zuzuordnen, wird ein Abstandsmaß A definiert. In Figur 3 ist das Abstandsmaß A dabei zuerst mit der Nummer der Grenze und anschließend der Nummer der Fahrzeuggruppe indiziert. A kann im einfachsten Fall der euklidische Abstand sein. Daneben sind aber auch beliebig komplexe Ähnlichkeitsmaße möglich, welche z.B. als Metriken aus Clustering-Verfahren und Korrelationsverfahren bekannt sind. Dadurch kann jedem VGrenze eine erste Zielgruppe Gmin mit minimalem Abstandsmaß (Gmin= min(A(VGrenze, VFzgGi oder VUserGi) für alle i), hier An und A22, zugeordnet werden. Genauso kann jedem VGrenze eine zweite Zielgruppe Gmax mit maximalem Abstandsmaß (Gmax= max(A(VGrenze, VFzgGi oder VUserGi) für alle i) ), hier A12 und A21, zugeordnet werden. Somit wird gewährleistet, dass Systemgrenzen in der ersten Zielgruppe Gmin mit niedrigem Abstandsmaß An und A22 statistisch häufig auftreten und in der zweiten Zielgruppe Gmax statistisch selten sind. Je nach Test-Ziel kann somit eine oder mehrere Gruppen von Fahrzeugen/Usern Gmin oder Gmax herangezogen werden.

Bezüglich des abgelegten Vektors VGrenze_2, der eine Systemgrenze des Spurhaltesystems 13 bei Regen auf Autobahnen aufzeigt, könnte somit Gmin eine erste Zielgruppe von Fahrzeugen beschreiben, die häufig auf Autobahnen >100kmh bei Regen > 40% gefahren ist. Gmax dagegen könnte auch eine zweite Zielgruppe sein, die viel Stadtverkehr bei Trockenheit fährt, z.B. Geschwindigkeit < 55km/h und Regen < 10%.

Dies lässt sich für das effiziente Testen und Verifizieren von Softwareaktualisierungen nutzen. Aus der aktuell installierten Softwareversion SW1 mit den bekannten Systemgrenzen wird durch Softwareänderungen- bzw. -Weiterentwicklungen die Softwareaktualisierung SW2, die genau diese bekannten Systemgrenzen verbessern soll. Um nun möglichst effektiv diese Softwareaktualisierung SW2 zu testen, wird sie in der ersten Zielgruppe Gmin ausgerollt und evaluiert. Dies kann sowohl im regulären Betrieb der Fahrzeuge 10 der ersten Zielgruppe Gmin erfolgen als auch parallel zum regulären Betrieb, wenn das Fahrzeug 10 über die Technik für ein Testen im sogenannten Shadowmode verfügt. Dann kann die Softwareaktualisierung SW2 nämlich auch parallel zu aktuellen Software SW1 im Fahrzeug 10 mitlaufen und evaluiert werden.

Durch den hergestellten geringen Abstand der ersten Zielgruppe Gmin zum Grenzvektor VGrenze ist davon auszugehen, dass die erste Zielgruppe Gmin häufig in den Betriebszustand der Systemgrenzen der aktuell installierten Softwareversion SW1 kommt und man so mit wenigen Fahrzeugen 10 in kurzer Zeit mit einem Performance Maß P die Softwareaktualisierung SW2 verifizieren kann.

In einer vorteilhaften ergänzenden oder auch alternativen Ausführung kann die Softwareaktualisierung SW2 auch ergänzend oder zuerst auf die zweite Zielgruppe Gmax ausgerollt werden und die Performance mit einem Performance-Maß verifiziert werden. Somit wird die neue Softwareaktualisierung SW2, erst in solche Fahrzeuge 10 ausgerollt, welche weit entfernt von der Systemgrenze operieren, um somit die Zuverlässigkeit der Softwareaktualisierung SW2 fernab der Systemgrenze zu testen. Erreicht das Performance-Maß einen Wert > Schwelle 1, so werden die Änderungen der Softwareaktualisierung SW2 gegenüber dem bisherigen Stand der Software SW1 übernommen und Softwareaktualisierung SW2 wird auf die einen größeren Teil der oder die ganze Fahrzeugflotte ausgerollt. Bleibt das Performance-Maß < Schwelle 1 , so wird eine erneute Entwicklungsiteration gestartet und eine neue Softwareaktualisierung SW2’ erstellt.

Der Ansatz kann insbesondere zur Entwicklung und zum weiterem Trainieren von Funktionsapproximationen/Methoden des maschinellen Lernens genutzt werden, deren Systemgrenzen unscharf ist und daher erprobt werden müssen.

Alternativ dazu könnte mit den Daten des zweiten Schritts, welche jeweils einem oder mehreren Grenzvektoren eine Systemgrenze zuordnet auch ein vereinfachtes Modell, welches oftmals als Surrogate Model bezeichnet wird, trainiert werden. Dazu kann in einem ersten Schritt a) eine Menge an Grenzvektoren VGrenz gesammelt werden. Wie oben bereits dargelegt kann dies durch ein manuelles oder vorzugsweise automatisiertes Labeln erfolgen. Damit entsteht eine Datensatz, welcher jeweils einem oder mehreren Grenzvektoren VGrenz eine Systemgrenze zuordnet. Die Zuordnung ergibt dabei eine Eingangsvoraussetzung für ein überwachtes maschinelles Lernen, welches eine Zuordnung von Eingangs- zu Ausgabegrößen benötigt. Mit den so im Schritt a) gesammelten Daten lässt sich in einem nachfolgenden Schritt b) das vereinfachte Modell bilden, indem die Zuordnungsvorschrift in einem Trainingsschritt in dem Modell abgebildet wird.

In einem dritten optionalen Schritt c) kann diese Modell dann zusätzlich in einen neuen Softwarestand SWT integriert und als Softwareaktualisierung SWT ausgerollt werden, z.B. als OTA (Over the Air) Update.

Immer wenn das Modell eine Genauigkeit > Schwelle 2 erreicht, werden Daten gesammelt. Die Daten können dann einerseits dazu verwendet werden, diese den Grenzvektoren VGrenz zuzuordnen, um die Datenbasis zu vergrößern. Dies stellt eine Erleichterung bzw. Vereinfachung von Schritt 2 dar, da die Erfassung der von Grenzvektoren VGrenz somit weiter automatisiert und der manuelle Aufwand reduziert werden kann. Die Daten können andererseits aber auch dazu verwendet werden, eine Fahrzeugfunktion 13 nachzutrainieren, die auf Basis von lernenden Verfahren (z.B. maschinelle Lernverfahren, Neuronale Netze, o.ä.) implementiert wurde. Die nachtrainierte Fahrzeugfunktion 13 wird dann in eine neue Softwareaktualisierung SW3 integriert. Zum Testen der Fahrzeugfunktion 13 können dann die vorherigen Schritte wiederholt werden.

Ein Beispiel für eine solche Vorgehensweise bei einer mögliche Systemgrenze sind Personen mit Winterjacke für die Gestenerkennung. Dafür werden im Schritt a) Daten gesammelt, die z.B. eine mangelhafte Erkennungsleistung bei Personen mit Winterjacken abbilden. Diese Systemgrenzen werden einer Menge von Grenzvektoren VGrenz zugeordnet. Nun wird im Schritt b) ein vereinfachtes Modell mit einem neuronalen Netz trainiert. Dieses vereinfachte Model kann Winterjacken mit einer Genauigkeit von z.B. 80% erkennen. Dieses Surrogate Model wird in den Softwarestand SW1 integriert, so dass eine neuer Softwarestand bzw. eine -aktualisierung SWT vorliegt. Diese wird in einer Testgruppe an Fahrzeugen ausgerollt. Immer wenn das vereinfachte Model eine Winterjacke mit einer Wahrscheinlichkeit > Schwelle 2 erkennt, werden Daten gesammelt. Diese werden der Gruppe an Grenzvektoren VGrenz der Systemgrenzen zugeordnet.

Ferner kann es vorgesehen werden mit diesen Daten ein maschinelles Lernverfahren nachzutrainieren, um die Gestenerkennung bei Personen mit Winterjacke zu erhöhen und in einen Softwarestand SW3 integriert werden. Dieser wird dann als Softwareaktualisierung SW3 in der ersten Zielgruppe Gmin ausgerollt und die oben beschriebenen Schritte werden zu testen und verifizieren befolgt.

In einer zusätzlichen Ausführung können n Software-Änderungen in n Softwarestände SW4j (j = 1..n) integriert werden. Die Software Stände SW4j werden ausschließlich auf bestimmte Teilemengen bzw. Untergruppen von Fahrzeugen 10 ausgerollt; VUserGi und/oder VfzgGi . So können modulare Softwarebausteine in der Fahrzeugflotte verteilt werden, um Kapazitäten bei der Übertragung und Softwareaktualisierung zu sparen. Für jeden Softwarestand SW4j werden die oben beschriebenen Schritte durchlaufen und ggf. wiederholt. Jede Teilmenge bzw. Untergruppe bekommt somit einen „personalisierten“ Stand der genutzten Software. In einer zusätzlichen in Figur 4 dargestellten Ausführung werden zwei unterschiedliche Softwarelösungen SW5a und SW5b für dasselbe Problem bzw. dieselbe Systemgrenze VGrenze_1 entwickelt. Die erste Zielgruppe Gmin bezüglich VGrenze_1 ist VFzgGI. Nun werden die zwei Softwarelösungen SW5a und SW5b z.B. randomisiert auf die Fahrzeuge verteilt, so dass jeweils eine Teilmenge der ersten Zielgruppe Gmin die eine und die andere Teilmenge die andere Softwarelösung erhält. Dann wird ein Performance-Maß für jede der Softwarelösungen SW5a, SW5b ermittelt. Erreicht z.B. das Performance Maß der Softwarelösung SW5a eine signifikant höherer Güte als SW5b: Güte(SW5a) > Güte(SW5b) + delta (wobei delta ein Maß für eine signifikante Verbesserung ist), wird zukünftig nur noch Lösung SW5a verfolgt. Die oben genannten Abläufe können dann mit SW5a entsprechend ausgeführt werden.

An die Stelle der beiden Softwarelösungen SW5a, SW5b können auch die bisherige Software SW1 in der ersten Teilmenge der ersten Zielgruppe Gmin und die Softwareaktualisierung SW2 in der zweiten Teilmenge der ersten Zielgruppe Gmin treten. Dann wäre eine klassische A/B- Testung der Softwareaktualisierung gegenüber einer Vergleichsgruppe ohne die Aktualisierung möglich.