WO2024089082A2 - Verfahren zum optimierten ausrollen von softwareaktualisierungen - Google Patents

Verfahren zum optimierten ausrollen von softwareaktualisierungen Download PDF

Info

Publication number
WO2024089082A2
WO2024089082A2 PCT/EP2023/079739 EP2023079739W WO2024089082A2 WO 2024089082 A2 WO2024089082 A2 WO 2024089082A2 EP 2023079739 W EP2023079739 W EP 2023079739W WO 2024089082 A2 WO2024089082 A2 WO 2024089082A2
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
vectors
software update
software
rolled out
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2023/079739
Other languages
English (en)
French (fr)
Inventor
Stefan Studer
Joana Hois
Alexander Hanuschkin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Publication of WO2024089082A2 publication Critical patent/WO2024089082A2/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the invention relates to a method for the optimized rollout of software updates to a vehicle fleet, according to the type defined in the preamble of claim 1.
  • US 10 042 635 B2 also describes a method for rolling out a software update wirelessly.
  • OTA Over The Air
  • the software is distributed via wireless communication.
  • This document also does not distribute the software updates to be rolled out across the board to all vehicles, but checks the technical aspects of the vehicles, such as the year of manufacture, the type of manufacture, etc., in order to select the vehicles that should receive the software update.
  • the object of the present invention is to provide an improved method for rolling out software updates, which includes a highly efficient evaluation phase prior to the actual rollout of the software.
  • the software is first rolled out to a subset of the vehicle fleet, which is determined based on data collected from the vehicles in the vehicle fleet.
  • the collected data includes characteristic vehicle vectors, which are formed from data from the vehicle sensors.
  • the data also includes a characteristic user vector, which is formed from data on driving behavior, such as driving style or emotions, but also from physiological data and environmental data. These two vectors are then aggregated across some or all of the vehicles in the vehicle fleet.
  • system limits in the current state of the software are analyzed, which should be optimized through the software update.
  • system limits can be, for example, sensor limits, such as the range or resolution of a camera, but also physical limits such as the coefficient of friction in wet conditions or special circumstances such as gesture recognition when the vehicle user is wearing a winter jacket.
  • the detection of the system limit can be automated, for example, in such a way that, for example, in the case of a system limit of a lane keeping assistance system, a sufficiently strong manual intervention in the steering has been detected in the relevant situation, for example in the rain and with poorly visible, e.g. yellow, road markings in the area of a motorway construction site or the like.
  • a sufficiently strong manual intervention in the steering has been detected in the relevant situation, for example in the rain and with poorly visible, e.g. yellow, road markings in the area of a motorway construction site or the like.
  • the vehicle user it would also be conceivable for the vehicle user to provide active feedback that the relevant vehicle function has just reached one of its system limits.
  • the system boundaries are then used to determine a characteristic boundary vector that applies to these system boundaries.
  • the method according to the invention determines a distance measure between the characteristic boundary vector and the characteristic vehicle and user vectors of the vehicle fleet. From this, a first target group of vehicles with a minimum distance measure and a second target group of vehicles with a maximum distance measure can then be determined. The first target group therefore includes all those vehicles that relatively frequently encounter the corresponding system boundaries.
  • the first target group is therefore ideally suited to checking and evaluating a software update that is rolled out to it to determine whether the desired improved performance in the area of the system boundaries, in particular a shift of the system boundaries towards a larger or improved detection area or the like, works efficiently.
  • the second target group with the maximum distance measure refers to a group of vehicles within the vehicle fleet for which the corresponding system boundary is usually insignificant because these vehicles and their users virtually never reach this system boundary, so that this system boundary does not pose any adverse restriction for the corresponding users and/or vehicles.
  • Both target groups can now be used in the method according to the invention, depending on the objective, to roll out the software update first to the first and/or second target group or a subset of this first and/or second target group and to evaluate the performance of the rolled out software update. After successful evaluation, the rollout of the corresponding The software can then be rolled out to other parts of the vehicle fleet accordingly, or to an entire vehicle fleet as well, if the software is to be rolled out to that fleet.
  • the invention offers the decisive advantage that software updates can first be tested on the corresponding target groups or parts of these target groups.
  • the target groups can be selected extremely efficiently based on the recording of the characteristic vectors and the distance between the boundary vector and the user and vehicle vectors, so that it is not left to statistical chance whether the vehicles use the newly implemented functions or not.
  • the targeted selection of the target groups via the invention allows very efficient testing of the new functions of the software update in the area of the system boundaries for the first target group or, accordingly, for the alternatively or additionally selected second target group, a test to see whether the software update also operates reliably far away from the system boundaries.
  • a performance measure is determined to evaluate the rolled out software update, whereby a positive result of the evaluation is assumed and an evaluation bit is set to 1 if the performance measure exceeds a predetermined threshold value, and whereby a negative evaluation is assumed and the evaluation bit is set to 0 or left at 0 if the performance measure does not reach the threshold value.
  • the invention provides for the further rollout of the software update to only be carried out if the evaluation was positive.
  • Another alternative way to evaluate the software update may be to roll it out only to a subset of the first and/or second target group, after which the performance is compared to another subset of the first and/or second target group as a comparison group.
  • the evaluation is carried out using a given question.
  • a comparison test can be carried out by dividing the target groups into typically two comparable subsets.
  • Such a comparison test which is also referred to as an A/B test or A/B testing, typically requires a corresponding question and two comparison groups. The larger these comparison groups are, the better statistical evaluations can be carried out, as described in the article "Size matters?
  • the comparison test is now carried out between one subset with the software update and the other subset without the software update, in particular with the question of whether the subset with the software update experiences significantly better performance, for example fewer critical driving situations, fewer accidents, improved comfort for the user or the like.
  • the procedure for evaluation with two comparison groups whereby in principle more than two comparison groups, i.e. more than two subsets per target group, are of course conceivable, can also be extended to the extent that an alternative variant of the software update is rolled out to the comparison group or, in the case of more than two subsets, to one of the subsets. This would allow two subsets, i.e. two alternative solutions to address the problems at the system boundary, to be tested against each other. With three subsets, the two alternatives could also be tested accordingly in comparison to the previous software solution in order to be able to evaluate which of the software updates offers the best performance and is therefore the one that should preferably be rolled out to a larger number of vehicles.
  • the software update is first optimized and then sent to the Target groups or subsets of the target groups are rolled out in order to evaluate the optimized software update.
  • This loop can be repeated until the software update has received a positive evaluation and can therefore be rolled out to other parts of the vehicle fleet.
  • This approach can be used in particular to develop and train function approximations and machine learning methods whose system boundaries are fuzzy and therefore need to be tested. This testing can now be carried out relatively easily and efficiently within the target groups before the software update has to be rolled out to the entire vehicle fleet or large parts of the vehicle fleet.
  • the aggregation of the vehicle vectors and the user vectors should take place in a server external to the vehicle, in particular the backend server of a vehicle manufacturer.
  • the individual vectors of the vehicles are transmitted to this server accordingly in order to be able to carry out the aggregation with the comparatively large computing power available to this server.
  • the characteristic vector in the area of the system boundaries i.e. the boundary vector
  • the characteristic vector in the area of the system boundaries can be determined according to a very advantageous development of the method according to the invention by using the data from vehicle sensors such as camera, radar, lidar and ultrasound, temperature, haptic sensors or internal states of an implementation of a vehicle function at the time the system boundary of a vehicle function occurs in order to determine the boundary vector accordingly on this basis.
  • vehicle sensors such as camera, radar, lidar and ultrasound, temperature, haptic sensors or internal states of an implementation of a vehicle function at the time the system boundary of a vehicle function occurs in order to determine the boundary vector accordingly on this basis.
  • vehicle sensors such as camera, radar, lidar and ultrasound, temperature, haptic sensors or internal states of an implementation of a vehicle function at the time the system boundary of a vehicle function occurs in order to determine the boundary vector accordingly on this basis.
  • vehicle sensors such as camera, radar, lidar and ultrasound, temperature, haptic sensors or internal states of an implementation of a vehicle function at the time the
  • a preferred further development of this can provide that the boundary vector determined on the basis of the recorded and stored data is assigned to the respective system boundary, after which a simplified model is formed in order to map the assignment rule resulting from the assignment and to track potential changes.
  • the assignment therefore provides an initial prerequisite for supervised machine learning, which requires an assignment of input to output variables.
  • the simplified model can thus be formed using the recorded and stored data by mapping the assignment rule in the model in a training step. This can be done, for example, using machine learning methods.
  • the vehicle vector can be determined accordingly, for example, using approximately constant and/or time-varying data, such as load collectives or speeds.
  • the vehicle vector for the method according to the invention can be formed by recording data from the vehicle sensors, the speeds, steering angles, torques, operating modes and the states of the vehicle system, for example the drive train, a battery, etc., and using this as the basis for forming the characteristic vector.
  • the characteristic user vector can be formed from the driver's behavior, i.e. his driving style and possible emotions as well as environmental data.
  • Example variables can vary depending on the function, but can include steering speeds, accelerations and the like.
  • facial expressions such as a smile can be taken into account, as can data from fatigue monitoring, such as the blinking frequency, a possible microsleep.
  • the time of day, weather, objects in and around the vehicle and the like can be taken into account and incorporated into the user vector, which is then aggregated accordingly, preferably using the clustering methods described above, across the vehicles in the vehicle fleet, preferably on the backend server together with the other vectors.
  • the method according to the invention also makes it possible to roll out software evaluated in this way only to different parts of vehicles within the vehicle fleet, so that individual software versions within the vehicle fleet are conceivable. Furthermore, various software changes can be combined in different software versions in order to distribute modular software modules within the vehicle fleet, which can save capacity when transferring the software update if only certain modular modules need to be replaced or updated.
  • Fig. 1 is a schematic representation of the transmission of information from a vehicle in a vehicle fleet to a cloud as an external vehicle server;
  • Fig. 2 is a schematic representation of the transmission of information on system boundaries of a vehicle function of a vehicle in a vehicle fleet to the cloud;
  • Fig. 3 shows a first exemplary 2-dimensional representation to illustrate aggregated vehicle and user vectors as well as boundary vectors to form the distance measure.
  • the aim is to achieve target group-oriented and thus effective testing, verification and rollout of software updates for vehicle functions.
  • characteristics are collected from the vehicle fleet in the first step.
  • Sensor data in the vehicle are determined, combined to form characteristic vectors V and stored.
  • These vectors V can either be approximately constant over time (e.g. load collectives) or change over time (e.g. current speeds).
  • Characteristic vehicle vectors VVzg are then formed from the vectors V, which are made up of vehicle sensor values such as speeds, steering angles, torques, operating modes and states of vehicle systems, Drivetrain, batteries, etc.
  • characteristic user vectors Vilser are formed from the driver's behavior such as driving style/emotions or environmental data.
  • Example variables vary depending on the function, but can be, for example, steering speeds, acceleration, smiles, blinking frequency, pulse rate, microsleep, weather, objects in and around the vehicle, etc.
  • a vehicle 10 can be seen in which these two vectors VUser and VFzg are determined and sent via a communication unit 11 to a server external to the vehicle, e.g. a backend 12 of the OEM.
  • a server external to the vehicle e.g. a backend 12 of the OEM.
  • the vectors can be aggregated via VUser and VFzg for several vehicles 10 or also for all vehicles in a vehicle fleet to form the groups VFzgGi and VUserGi. Clustering methods are used for this purpose.
  • system limits of vehicle functions such as driver assistance systems (ADAS - Advanced Driver Assistance System), gesture recognition, fatigue detection, etc. are to be determined for a current software version SW1.
  • System limits can be of many different natures, e.g. sensor limits (e.g. range of a camera), physical limits (friction coefficient in wet conditions) or special conditions (gesture recognition with a winter jacket).
  • sensor limits e.g. range of a camera
  • physical limits e.g. range of a camera
  • special conditions gesture recognition with a winter jacket
  • the aim is to shift the system limits of SW1 during development by optimizing hardware and/or software in order to be able to offer the user better performance of the vehicle function.
  • characteristic limit vectors VGrenzJ are determined at the time the system limit of a vehicle function 13 occurs, which is indicated schematically in Figure 2. Values from vehicle sensors such as camera, radar, lidar, ultrasound, temperature, haptic sensors or internal states of an implementation of the vehicle function 13 are again used to form the vectors.
  • system boundaries can be marked (labeled) manually by the driver or passenger.
  • a camera detects the lane markings on the right and left and tries to guide the vehicle within the lanes. If, for example, the detection performance is reduced in a certain situation, e.g. when driving on the motorway and in the rain, it may be that the lane keeping does not work in the usual way.
  • a driver can recognize reduced performance as the system limit of its system, since it may have to steer itself, and triggers the labeling of this system limit, for example using an input function.
  • the system then stores a limit vector VGrenze_1, which contains predefined features, e.g.
  • the defined features must also be elements of VfzgGi or VUserGi.
  • the system limits are recognized automatically (systematically), e.g. if the driver steers sharply on the motorway in the rain with the lane keeping system 13 active [steering angle change > x degrees per second OR steering torque > y Newton meters].
  • a distance measure A is defined.
  • the distance measure A is first indexed with the number of the border and then with the number of the vehicle group.
  • A can be the Euclidean distance.
  • one or more groups of vehicles/users Gmin or Gmax can be used.
  • Gmin could describe a first target group of vehicles that often drove on motorways >100kmh when it is raining > 40%.
  • Gmax could also be a second target group that drives a lot in city traffic when it is dry, e.g. speed ⁇ 55km/h and rain ⁇ 10%.
  • the currently installed software version SW1 with the known system limits is converted into the software update SW2 through software changes or further developments, which is intended to improve precisely these known system limits.
  • this software update SW2 In order to test this software update SW2 as effectively as possible, it is rolled out and evaluated in the first target group Gmin. This can take place both during regular operation of the vehicles 10 of the first target group Gmin and in parallel with regular operation if the vehicle 10 has the technology for testing in so-called shadow mode.
  • the software update SW2 can then also run and be evaluated in parallel with the current software SW1 in the vehicle 10.
  • the first target group Gmin Due to the small distance created between the first target group Gmin and the limit vector VGrenz, it can be assumed that the first target group Gmin frequently reaches the operating state of the system limits of the currently installed software version SW1 and that the software update SW2 can thus be verified with a performance measure P using just a few vehicles 10 in a short time.
  • the software update SW2 can also be rolled out additionally or first to the second target group Gmax and the performance can be verified with a performance measure.
  • the new software update SW2 is therefore only rolled out to those vehicles 10 that operate far away from the system boundary, in order to test the reliability of the software update SW2 far away from the system boundary. If the performance measure reaches a value > threshold 1, the changes to the software update SW2 compared to the previous version of the software SW1 are adopted and the software update SW2 is rolled out to a larger part of the vehicle fleet or to the entire vehicle fleet. If the performance measure remains ⁇ threshold 1, a new development iteration is started and a new software update SW2' is created.
  • the approach can be used in particular for the development and further training of function approximations/machine learning methods whose system boundaries are fuzzy and therefore need to be tested.
  • the data from the second step could also be used to train a simplified model, often referred to as a surrogate model.
  • a first step a) a set of boundary vectors VGrenz can be collected. As already explained above, this can be done by manual or, preferably, automated labeling. This creates a data set that assigns a system boundary to one or more boundary vectors VGrenz. The assignment provides an input requirement for supervised machine learning, which requires an assignment of input to output variables.
  • the data collected in step a) can be used in a subsequent step b) to form the simplified model by mapping the assignment rule to the model in a training step.
  • this model can then be additionally integrated into a new software version SWT and rolled out as a software update SWT, e.g. as an OTA (Over the Air) update.
  • SWT e.g. as an OTA (Over the Air) update.
  • the data can also be used to retrain a vehicle function 13 that was implemented on the basis of learning methods (e.g. machine learning methods, neural networks, or similar). The retrained vehicle function 13 is then integrated into a new software update SW3. The previous steps can then be repeated to test the vehicle function 13.
  • learning methods e.g. machine learning methods, neural networks, or similar
  • step a) data is collected that, for example, shows poor recognition performance in people wearing winter jackets.
  • step b) a simplified model is trained with a neural network.
  • This simplified model can recognize winter jackets with an accuracy of e.g. 80%.
  • This surrogate model is integrated into the software version SW1 so that a new software version or update SWT is available. This is rolled out in a test group of vehicles. Whenever the simplified model recognizes a winter jacket with a probability > threshold 2, data is collected. This is assigned to the group of boundary vectors VGrenz of the system boundaries.
  • the software versions SW4j are only rolled out to certain sets of parts or subgroups of vehicles 10; VUserGi and/or VfzgGi .
  • modular software components can be distributed in the vehicle fleet in order to save capacity during transfer and software updates.
  • For each software version SW4j the steps described above are carried out and repeated if necessary. Each set of parts or subgroup thus receives a "personalized" version of the software used.
  • two different software solutions SW5a and SW5b are developed for the same problem or the same system boundary VGrenze_1.
  • the first target group Gmin with respect to VGrenze_1 is VVzgGI.
  • the two software solutions SW5a and SW5b are now distributed randomly among the vehicles, for example, so that a subset of the first target group Gmin receives one software solution and the other subset receives the other software solution.
  • a performance measure is then determined for each of the software solutions SW5a, SW5b. If, for example, the performance measure of the software solution SW5a achieves a significantly higher quality than SW5b: Quality(SW5a) > Quality(SW5b) + delta (where delta is a measure of a significant improvement), only solution SW5a will be pursued in the future. The above processes can then be carried out accordingly with SW5a.
  • the two software solutions SW5a and SW5b can also be replaced by the previous software SW1 in the first subset of the first target group Gmin and the software update SW2 in the second subset of the first target group Gmin.
  • a classic A/B test of the software update against a comparison group without the update would then be possible.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Description

Mercedes-Benz Group AG
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.

Claims

Mercedes-Benz Group AG Patentansprüche
1 . Verfahren zum optimierten Ausrollen von Softwareaktualisierungen an einer Fahrzeugflotte, wozu die Softwareaktualisierung (SW1 ‘, SW2, SW2‘, SW3, SW4, SW5a, SW5b) zuerst an eine Teilmenge der Fahrzeugflotte ausgerollt wird, wobei diese Teilmenge basierend auf gesammelten Daten der Fahrzeuge (10) der Fahrzeugflotte bestimmt wird, dadurch gekennzeichnet, dass die gesammelten Daten charakteristische Fahrzeugvektoren (VFzg) umfassen, welche aus Daten der Fahrzeugsensoren gebildet werden, sowie charakteristische Nutzervektoren (Vilser), welche aus Daten zum Fahrverhalten, aus physiologischen Daten und Umgebungsdaten gebildet werden, umfassen, wonach die Fahrzeugvektoren (VFzg) und Nutzervektoren (VUser) aller Fahrzeuge (10) der Fahrzeugflotte aggregiert werden, wobei im bisherigen Stand der Softwaresystemgrenzen analysiert und an diesen Systemgrenzen geltende charakteristische Grenzvektoren (VGrenz) ermittelt werden, wonach ein Abstandsmaß (A) zwischen den charakteristischen Grenzvektoren (VGrenz) und den charakteristischen Fahrzeugvektoren (VFzg) und Nutzervektoren (VUser) der Fahrzeugflotte ermittelt wird, woraus eine erste Zielgruppe (Gmin) von Fahrzeugen (10) mit dem minimalem Abstandsmaß (An, A22) und eine zweite Zielgruppe von Fahrzeugen (10) mit dem maximalen Abstandsmaß (A12, A21) ermittelt wird, wonach die Softwareaktualisierung (SWT, SW2, SW2‘, SW3, SW4, SW5a, SW5b) an die erste und/oder zweite Zielgruppe (Gmin, Gmax) oder jeweils eine Teilmenge der ersten und/oder zweiten Zielgruppe (Gmin, Gmax) ausgerollt und die Performance der ausgerollten Softwareaktualisierung evaluiert wird, wobei die Softwareaktualisierung (SWT, SW2, SW2‘, SW3, SW4, SW5a, SW5b) nur im Falle einer positiven Evaluation auf weitere Teile der Fahrzeugflotte ausgerollt wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass zur Evaluation der ausgerollten Softwareaktualisierung (SW1‘, SW2, SW2‘, SW3, SW4, SW5a, SW5b) ein Performancemaß (P) bestimmt wird, wobei eine positive Evaluation angenommen wird, wenn das Performancemaß (P) einen vorgegebenen Schwellenwert (Schwelle"!) übersteigt, und wobei eine negative Evaluation angenommen wird, wenn das Performancemaß dem vorgegebenen Schwellenwert (Schwelle"!) nicht erreicht. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass zur Evaluation der Softwareaktualisierung (SW1‘, SW2, SW2‘, SW3, SW4, SW5a, SW5b) diese nur an eine Teilmenge der ersten und/oder zweiten Zielgruppe (Gmin, Gmax) ausgerollt wird, wonach die Performance im Vergleich zu einer weiteren Teilmenge der jeweiligen ersten und/oder zweiten Zielgruppe (Gmin, Gmax) als Vergleichsgruppe evaluiert wird. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass auf die Vergleichsgruppe eine alternative Softwareaktualisierung (SW5a, SW5b) ausgerollt wird. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass im Falle einer negativen Evaluation die Softwareaktualisierung (SWT, SW2, SW2‘, SW3, SW4, SW5a, SW5b) zuerst optimiert und dann erneut auf die Zielgruppen (Gmin, Gmax) oder Teilmengen der Zielgruppen (Gmin, Gmax) ausgerollt wird, um die optimierte Softwareaktualisierung (SWT, SW2, SW2‘, SW3, SW4, SW5a, SW5b) zu evaluieren, bevor sie im Falle einer positiven Evaluation auf weitere Teile der Fahrzeugflotte ausgerollt wird. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Aggregation in einem fahrzeugexternen Server (12) erfolgt, an welchen die Fahrzeugvektoren (VFzg) und Nutzervektoren (Vilser) der Fahrzeuge (10) übermittelt werden. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Aggregation mittels Clustering-Verfahren erfolgt. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass der charakteristische Grenzvektor (VGrenz) bestimmt wird, in dem Daten von Fahrzeugsensoren erfasst und gespeichert werden, wenn eine Systemgrenze erkannt worden ist. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der anhand der durch die erfassten und gespeicherten Daten bestimmte charakteristische Grenzvektor (VGrenz) der jeweiligen Systemgrenze zugeordnet wird, wonach ein vereinfachtes Modell gebildet wird, um die Zuordnungsvorschrift abzubilden und potenziellen Veränderungen nachzuführen. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der charakteristische Fahrzeugvektor (VFzg) auf Fahrzeugsensorwerten basiert, welche zumindest eine der Größen Geschwindigkeit, Lenkwinkel, Drehmoment, Betriebsart und/oder einen der Zustände von Fahrzeugsystemen, Triebstrang, Batterie umfassen. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der charakteristische Nutzervektor (Vilser) auf Daten basiert, welche zumindest eine der Größen Lenkwinkel, Geschwindigkeit, Beschleunigung, Wetter, Objekte im und um das Fahrzeug, Lidschlagfrequenz, Sekundenschlaf, Gesichtsausdruck, Gesten des Fahrzeugnutzers, umfassen.
PCT/EP2023/079739 2022-10-28 2023-10-25 Verfahren zum optimierten ausrollen von softwareaktualisierungen Ceased WO2024089082A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022004038.7A DE102022004038A1 (de) 2022-10-28 2022-10-28 Verfahren zum optimierten Ausrollen von Softwareaktualisierungen
DE102022004038.7 2022-10-28

Publications (1)

Publication Number Publication Date
WO2024089082A2 true WO2024089082A2 (de) 2024-05-02

Family

ID=88598891

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/079739 Ceased WO2024089082A2 (de) 2022-10-28 2023-10-25 Verfahren zum optimierten ausrollen von softwareaktualisierungen

Country Status (2)

Country Link
DE (1) DE102022004038A1 (de)
WO (1) WO2024089082A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12693844B1 (en) * 2023-10-04 2026-07-28 Zoox, Inc. Vehicle state aware cloud resource management
DE102024004496B4 (de) 2024-05-25 2026-06-25 Mercedes-Benz Group AG Aktualisierungssystem, Verfahren zum Ausrollen von Drahtlosaktualisierungen, Computerprogrammprodukt und computerlesbares Speichermedium
DE102024001701B4 (de) * 2024-05-25 2026-06-18 Mercedes-Benz Group AG Aktualisierungssystem, Verfahren zum Ausrollen von Drahtlosaktualisierungen, Computerprogrammprodukt und computerlesbares Speichermedium
DE102024137877A1 (de) * 2024-12-16 2026-06-18 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Übermitteln einer aktuellen Softwareaktualisierung von einem fahrzeugexternen Server an ein Fahrzeug, computerlesbares Medium, System, und Fahrzeug

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10042635B2 (en) 2015-06-16 2018-08-07 Lear Corporation Method for wireless remote updating vehicle software
DE102018205615A1 (de) 2018-04-13 2019-10-17 Audi Ag Verfahren zum Aktualisieren einer Fahrzeugsoftware

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10042635B2 (en) 2015-06-16 2018-08-07 Lear Corporation Method for wireless remote updating vehicle software
DE102018205615A1 (de) 2018-04-13 2019-10-17 Audi Ag Verfahren zum Aktualisieren einer Fahrzeugsoftware

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LIU ET AL., SIZE MATTERS? OR NOT: A/B TESTING WITH LIMITED SAMPLE IN AUTOMOTIVE EMBEDDED SOFTWARE, 10 November 2021 (2021-11-10), Retrieved from the Internet <URL:https://arxiv.org/abs/2107.02461v2>

Also Published As

Publication number Publication date
DE102022004038A1 (de) 2024-05-08

Similar Documents

Publication Publication Date Title
DE102022004038A1 (de) Verfahren zum optimierten Ausrollen von Softwareaktualisierungen
DE102019213185B4 (de) Querführung eines Fahrzeugs mittels von anderen Fahrzeugen erfassten Umgebungsdaten
DE102018203583B4 (de) Verfahren, Fahrerassistenzsystem sowie Kraftfahrzeug zur Prädiktion einer Position oder einer Trajektorie mittels eines graphbasierten Umgebungsmodells
EP4193135B1 (de) Computerimplementiertes verfahren zum bereitstellen eines test-verlaufs zu testender verkehrsszenarien
EP3625785B1 (de) Verfahren zum erzeugen einer überholwahrscheinlichkeitssammlung, verfahren zum betreiben einer steuereinrichtung eines kraftfahrzeugs, überholwahrscheinlichkeitssammeleinrichtung und steuereinrichtung
DE102019104974A1 (de) Verfahren sowie System zum Bestimmen eines Fahrmanövers
DE102017212908B4 (de) Verfahren zur Verbesserung der Quer- und/oder Längsführung eines Fahrzeugs
WO2021121695A1 (de) Verfahren, vorrichtung und system zur detektion von anomalen betriebszuständen eines geräts
DE102019002790A1 (de) Verfahren zur Prädiktion einer Verkehrssituation für ein Fahrzeug
DE102021207781A1 (de) Verfahren, Steuereinrichtung und System zum Adaptieren einer assistierten oder automatisierten Fahrfunktion eines Fahrzeugs
DE102021003073B3 (de) Verfahren und Vorrichtung zur Erhöhung der Anteile des automatisierten Fahrens bei einem mindestens teilautomatisiert fahrenden Fahrzeug
DE102020127216A1 (de) Verfahren zum Ermitteln einer Trajektorie für ein Fahrzeug, Computerprogrammprodukt, Parkassistenzsystem und Fahrzeug
DE102018220941A1 (de) Auswertung von Messgrößen mit KI-Modulen unter Berücksichtigung von Messunsicherheiten
DE102021128201A1 (de) Verbesserter Fahrzeugbetrieb
DE102018206743A1 (de) Verfahren zum Betreiben eines Fahrerassistenzsystems eines Egofahrzeugs mit wenigstens einem Umfeldsensor zum Erfassen eines Umfelds des Egofahrzeugs, Computer-lesbares Medium, System, und Fahrzeug
EP3871052B1 (de) Verfahren zur kalibirierung eines technischen systems
DE102018215017A1 (de) Verfahren zur Bestimmung einer Betriebsstrategie für Fahrzeug, System, Steuereinrichtung für ein Fahrzeug und ein Fahrzeug
DE102023100099A1 (de) Verfahren und eine Steuereinheit zum Steuern eines Fahrerassistenzsystems
DE102022000849A1 (de) Verfahren zur Erzeugung einer Umgebungsrepräsentation für ein Fahrzeug
DE102023110200A1 (de) Anpassung von Fahrzeugplanungsparametern in einer verschlechterten Fahrsituation
DE112021007341T5 (de) Steuervorrichtung und Steuerverfahren
DE102023211428B4 (de) Verfahren und Vorrichtung zum Unterstützen einer Vielzahl von automatisierten Fahrsystemen
DE112022007117B4 (de) Kolonnenverwaltungsvorrichtung und kolonnenverwaltungsverfahren
DE102024204116A1 (de) Verfahren und System zum Betreiben eines Assistenzsystems in Fahrzeugen einer Fahrzeugflotte
DE102023206845A1 (de) Verfahren und Vorrichtung zur Verkehrsflusssteuerung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23798172

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23798172

Country of ref document: EP

Kind code of ref document: A2