EP4185951A1 - Software-aktualisierung über eine funkverbindung - Google Patents

Software-aktualisierung über eine funkverbindung

Info

Publication number
EP4185951A1
EP4185951A1 EP21749092.9A EP21749092A EP4185951A1 EP 4185951 A1 EP4185951 A1 EP 4185951A1 EP 21749092 A EP21749092 A EP 21749092A EP 4185951 A1 EP4185951 A1 EP 4185951A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
software
update
machine learning
fleet
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.)
Pending
Application number
EP21749092.9A
Other languages
English (en)
French (fr)
Inventor
Dirk Wacker
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.)
Giesecke+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany GmbH
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 Giesecke+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP4185951A1 publication Critical patent/EP4185951A1/de
Pending 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present invention relates to a method for updating software in vehicles in a vehicle fleet, an updating system which carries out such an update on vehicles in the fleet, such a vehicle and a background device and an updating device of the updating system.
  • Modern vehicles are equipped with a large number of electronic, software-controlled components that control and implement vehicle functions.
  • ECU Electronic Control Unit
  • the software installed in such control systems is usually operating software or firmware that specifies the behavior of the relevant components or ECUs and must be updated regularly, for example by installing updates and/or patches, particularly for security reasons that replace parts of the Software or the Software as a whole.
  • updating or software updating means a process with which up-to-date software available on a server is first downloaded to the vehicle, stored in a suitable memory and then installed in the correct control units and components.
  • the previous software is replaced by the downloaded, current software and, if necessary, configured in such a way that it takes over the tasks of the previous software when executed by a microprocessor.
  • a suitable radio link is mainly required for downloading the software to the vehicle
  • installing or configuring the current software in the vehicle may also require a radio link, for example to download configuration data from the server or specific data such as keys, checksums, identifiers, references or the like to the server.
  • the term "update” or "software update” means in particular that part of this process for which a stable radio connection is required.
  • a main aspect of the invention in order to update software in vehicles in a vehicle fleet, those vehicles in the fleet whose software is to be updated are first identified. In this step, at least one of the vehicles in the vehicle fleet is selected, the software of which is then updated via an existing radio link according to predetermined update conditions.
  • the update conditions are determined according to the invention by means of a machine learning model or "machine learning model”, also referred to below as an ML model, which models transmission qualities of as many different radio links as possible via a radio network, i.e. of radio links at different times and at different times Locating the radio network
  • the ML model can therefore be compared to a time-variable, changeable map that maps the transmission qualities of radio connections with a specific spatial resolution, for example corresponding to the radio cells of a mobile radio network, and does so with a specific time-dependent Time resolution over a reasonable period of time, for example a day, a week, or a month.
  • This ML model is the result of an ongoing training process that will be described below.
  • the trained ML model is used to derive predictions regarding the transmission quality of radio connections, via which the software of the at least one identified vehicle can be updated in the future.
  • the update conditions are then determined in such a way that they specify one or more possible future radio links with sufficient accuracy, the predicted transmission qualities of which are sufficient to update the vehicle's software.
  • a “future radio connection” in this context means such a radio connection that the vehicle can potentially establish and maintain in the future in order to update the software via this radio connection as soon as it is established.
  • the ML model says in other words, the update conditions under which the vehicle's software can be updated with a sufficiently high probability in such a way that the disadvantages of the prior art described at the outset are avoided.
  • the ML model predicts a transmission quality that is sufficient within the meaning of the invention for a radio connection if it is likely to be suitable for successfully completing the process of updating the software as soon as it is started. It is in the nature of predictions made by a machine learning model that they do not have to apply, but only probably apply. An unexpectedly high volume of traffic in certain radio cells, for example due to a construction site in other radio cells, can worsen the actual transmission quality of a radio connection contrary to the forecast.
  • the ML model generated by training which models transmission qualities of potential radio links, is the basis for a prediction of the circumstances under which the software of the relevant Vehicle can be expected to be updated without interruption. These circumstances of the non-disruptive update are described by update conditions. If the software is updated in accordance with the update conditions, the disadvantages of the prior art described above can probably be avoided.
  • the updating method according to the invention is carried out by an updating system which comprises a background device and at least one updating device which is in contact with the background device via a data communication connection.
  • the updating device identifies the vehicles whose software is to be updated, establishes the radio connections required for this to the vehicles and finally updates the software of the identified vehicles in accordance with the specified update conditions.
  • the ML model which models transmission qualities of potential radio connections, is set up on the background device.
  • the machine learning model set up on a background device determines the individual update conditions for updating the software of each identified vehicle in such a way that the update conditions each describe radio connections for which according to Prediction sufficient transmission qualities are to be expected.
  • the software of the vehicles in question can be updated according to the invention, preferably without interruption and/or within a predetermined time window, within which the software update is started and completely ended.
  • a vehicle is set up in such a way that its software can be updated by an update system according to the invention in the manner according to the invention.
  • a vehicle according to the invention includes means for setting up a radio link according to the specification of the update conditions and for downloading and installing up-to-date software in the relevant control units and ECU components.
  • the transmission quality which the machine learning model uses as a basis for determining update conditions, is preferably a data transmission rate or data rate, i.e. a measure of the digital data volume within a specific period of time and at a specific location, for example within a radio cell , can be transmitted via the relevant radio link.
  • a data transmission rate or data rate i.e. a measure of the digital data volume within a specific period of time and at a specific location, for example within a radio cell .
  • the more participants (probably) register in a radio cell at the same time or within the same period of time, i.e. the more parallel radio connections (probably) exist, the lower the (probable) data rate of each of these radio connections.
  • Adequate transmission quality within the meaning of the invention is thus predicted by the ML model in particular when a radio connection PHg a data rate is expected that exceeds a specified minimum data rate for a specific period, so that the software can be updated within this period.
  • update conditions are determined according to which the vehicle can probably carry out the software update without interruption as soon as these apply.
  • the digital size or the data volume of the current software to be downloaded via the radio link is also taken into account and the update conditions are defined accordingly such that the minimum data rate is exceeded long enough to be able to completely update the software.
  • the update conditions are determined in particular in such a way that the radio connection is sufficiently stable over time, ie it is available long enough without interruption to update the software.
  • Such a specified probability is, for example, greater than 0.8 (> 80%), greater than 0.9 (> 90%) or greater than 0.95 (> 95%) or greater than 0.98 (> 98%) .
  • the update conditions preferably include at least one time condition and at least one location condition. At least one pair of conditions is preferably determined, consisting of a time condition and a location condition.
  • the software is then automatically updated as soon as one of the pairs of conditions that the ML model has determined for the vehicle in question are met; if the vehicle satisfies both the location and the time condition.
  • a radio cell or a specific location, a section of road or an area in which the software of the relevant vehicle must be updated is determined as a location condition, for example.
  • the time condition preferably specifies a time interval within which the software is to be updated while the vehicle simultaneously meets the location condition.
  • the time interval is dimensioned in such a way that the software can be completely updated with the associated predicted transmission quality.
  • the ML model is also trained by the central background facility. Specifically, all processes and operations related to the creation, training, and use of the ML model are performed by the backend facility. The ML model is first trained with training data in order then, in a subsequent step, to use the ML model to make predictions regarding the transmission qualities of radio links or to derive them from the trained ML model and to determine suitable update conditions .
  • a large number of sensor data are therefore collected from the vehicles in the vehicle fleet as training data, which are forwarded to the background device via an updating device and are used there as training data for the ML model.
  • This sensor data includes, in particular, measured values of the specific transmission qualities or data rates of radio connections, including the associated location and time data, which are collected from the vehicles during their regular ferry operations.
  • Other sensor data which is preferably also used to train the ML model, relates to information on the number of active radio connections within radio cells at specific times or within specific time intervals, as well as information on the specific routes of the vehicles, i.e. on the movement patterns of the vehicles through the radio network and the radio cells visited, including the corresponding time information.
  • the update device does not simply forward this sensor data to the background device, but rather processes it if necessary.
  • a single vehicle may not be able to take measurements of the number of wireless connections active at a point in time, so that the updating device preferably evaluates the sensor data from many vehicles in order to derive such information from them.
  • radio connections Based on the transmission qualities measured by the vehicles in certain radio cells at certain times, possible transmission qualities of radio connections for which no sensor data are available are derived when training the ML model.
  • the transmission qualities of such radio connections are therefore estimated during training or extrapolated from the available sensor data, for example using sensor data from radio cells or for time intervals with similar characteristics.
  • the proximity of a radio cell for which there is no or insufficient sensor data to other radio cells for which sufficient sensor data has been collected can have a similar characteristic, or comparable traffic volumes in two radio cells, similar population densities, or the like.
  • Radio cells are preferably grouped into clusters on the basis of such and other characteristics, and sensor data for one or a few radio cells in a cluster are used for all other radio cells in the cluster.
  • the ML model trained in this way is then used to make predictions about the transmission qualities of radio connections for a vehicle whose software is to be updated, which this vehicle could potentially use in the future to update its software. This is preferably based on the movement data of the vehicle so that only radio connections are taken into account that the vehicle can also realistically set up during its normal operation, for example on regularly repeated journeys.
  • the ML model selects one or more of these radio links for which sufficiently stable transmission qualities are predicted and which are preferably matched to the movement data of the vehicle.
  • the update conditions according to which the software of the relevant vehicle is updated then describe the selected radio links with potentially adequate transmission qualities. For example, if the ML model is on the morning commute on a certain day of the week and on the evening commute on another working day
  • the update conditions describe locations or radio cells and points in time or time intervals of these two situations, so that two different options are offered for updating the software.
  • update conditions are determined for all identified vehicles and combined into an update plan that forms the basis of an update campaign that updates the software of all identified vehicles within a specified time frame.
  • the ML model is therefore provided with the list of all identified vehicles whose software is to be updated, the corresponding time specifications with regard to the desired time horizon of the update campaign, and the movement data of the vehicles in question.
  • update conditions are not determined for each individual vehicle independently of those of other vehicles, but rather that an optimal update plan is found that minimizes a higher-level cost function or maximizes a higher-level utility function.
  • Such a function is optimal when transmission qualities matched to their movement data are predicted for as many vehicles as possible and update conditions are found that do not collide with one another.
  • the update conditions can either be monitored and implemented by the update device or autonomously by each vehicle itself.
  • sensitive personal data such as the sensor and/or movement data used as training data for the ML model
  • provide information about whereabouts and times of people and are therefore valid may be subject to data protection regulations, leave the respective vehicle and thereby potentially become accessible to unauthorized persons.
  • the invention described above can also be implemented as a “federated learning” variant.
  • “Federated leaming” is a distributed or decentralized approach to machine learning in which local instances of an ML model be trained decentrally based on individual, local training data.
  • a local, vehicle-specific ML model is installed on several vehicles, preferably on all vehicles in the vehicle fleet, which is trained based solely on the sensor and/or movement data of the relevant individual vehicle.
  • the vehicles or their vehicle-specific ML models do not exchange any personal (training) data with one another or with the background or update device.
  • a corresponding, higher-level and fleet-wide ML model is operated on the background device, which on the one hand integrates the local training results of the individual vehicle-specific ML models across the fleet and which on the other hand is used to to update and synchronize vehicle-specific ML models. While the vehicle-specific ML models are each trained based on vehicle-specific sensor and movement data, the fleet-wide ML model is not trained but synthesized. However, the synthesis improves the training status of the fleet-wide ML model in a similar way to conventional training of the fleet-wide ML model.
  • the local, vehicle-specific ML models are merged or synthesized into an updated, fleet-wide ML model on the background device.
  • the fleet-wide ML model formed in this way then represents a synthesis of the training results of all vehicle-specific ML models at a specific point in time, and the vehicle-specific ML models are preferably updated or synchronized with it again immediately after the synthesis.
  • the synthesized, fleet-wide ML model is passed on from the background device via the update device to the vehicles in the vehicle fleet, so that due to the synchronization, each vehicle-specific ML model also benefits from the training results of all other vehicle-specific ML models.
  • the merging (synthesizing) of the fleet-wide ML model and the subsequent updating (synchronization) of the vehicle-specific ML models is carried out with suitable data structures in such a way that no personal sensor and/or movement data is exchanged between the vehicles and the background system. Rather, only vehicle-specific or cross-fleet, representative model data is transmitted, which is derived from the vehicle-specific or cross-fleet ML models based on their respective training status.
  • the underlying, person-related training data can no longer be extracted from this representative model data, because the model data relate to estimates of transmission qualities of potential radio connections, which were extrapolated from the sensor data and thus alienate them in such a way that they are no longer of any value to unauthorized persons be able.
  • the vehicle-specific model data which are derived from the relevant vehicle-specific ML models, preferably represent a difference or a difference between the current state of the relevant vehicle-specific ML model and the state of this ML model after its last update.
  • the vehicle-specific model data which is finally merged into the fleet-wide ML model, therefore preferably relates to increments of the training states or incremental training progress of the respective vehicle-specific ML model between two training phases or two points in time within a training phase.
  • the fleet-wide model data which are derived from the fleet-wide ML model for synchronizing the vehicle-specific ML models, also represent a difference or a difference between the current state of the fleet-wide ML model and the state of this ML model after its last synthesis from the vehicle-specific ML models.
  • the vehicle-specific ML models updated in this way are then based on the sensors collected individually from this vehicle in the further course. sensor and movement data is further trained so that the various vehicle-specific ML models diverge again after they have been synchronized. The resulting differences are extracted again at a suitable point in time in the form of vehicle-specific model data from the respective vehicle-specific ML models and recombined to form the fleet-wide ML model. From the fleet-wide ML model synthesized in this way, predictions can then be made about the transmission quality of wireless connections based on the sensor data of all vehicles in the vehicle fleet.
  • FIG. 1 shows a schematic of an update system according to the invention
  • Fig. 3 is a schematic of the machine learning unit of one according to the invention
  • FIG. 5 shows a third preferred embodiment of the updating method according to the invention.
  • 1 shows an example of an update system according to the invention comprising a central background device 10 (HGE) and a number of update devices 30 (SAE) in data communication with it via suitable, usually wired data communication connections 20 .
  • the updating devices 30 in turn maintain individual radio links 40 to a large number of vehicles 50 in a vehicle fleet, via which the updating devices 30 can operate data communication with the vehicles 50 for various purposes, for example for the purposes of remote maintenance, measuring values, sensor control or the like.
  • the updating of software that is installed on the vehicles 50 is initiated via the radio links 40 according to specifications of the background device 10 .
  • the vehicles 50 are equipped with complex electronic control and regulation systems, which are generally implemented as embedded modules (“embedded systems”) and perform a variety of tasks within a vehicle 50, such as engine and brake control, the control of assistance, safety and communication systems and the like more.
  • These electronic control units usually called ECU or "Electronic Control Units”
  • ECU Electronic Control Units
  • microprocessors volatile and non-volatile memories
  • peripheral and bus systems are equipped with microprocessors, volatile and non-volatile memories, peripheral and bus systems and are an operating software or firmware, for example according to a predetermined software architecture, such as the AUTOSAR standard (Automotive Open System Architecture).
  • the software components of the operating software of a vehicle control must be updated regularly for security and performance reasons.
  • the mode of operation and the interaction of the background device 10 with the updating devices 30 ensures that the software of each individual vehicle 50 is updated individually specified conditions are carried out, which ensure stable mobile radio connections 40 with sufficient transmission qualities or sufficient data transmission rates to the vehicles 50 in order to update the software in each case without interruption.
  • FIGS. 2a and 2b The interaction and the data communication between the background device 10, an updating device 30 and the various vehicles 50 in a vehicle fleet whose software is to be updated is illustrated using the example of FIGS. 2a and 2b, the respective preferred embodiments of the updating method according to the invention illustrate.
  • the background device 10 of FIG. 2a comprises a control unit 11 which controls the background device 10 and in particular the machine learning unit 12 (ML unit).
  • the ML unit 12 is implemented as a software program that can be executed on a processor (not shown) of the background device 10 and generates, processes, manages and uses two selected data structures, namely on the one hand the machine learning model 13 (ML model) and on the other hand, the update plan 14.
  • ML model machine learning model 13
  • the update plan 14 are stored in a suitable memory (not shown) of the backend facility 10 to which the ML unit 12 has access.
  • the background device 10 instructs the updating device 30 in a step S1 to identify all vehicles 50 whose current software is running the current software is to be replaced.
  • the updating device 30 is transferred in particular the version number(s) of the software to be updated, as well as other identification criteria that enable the identification of all affected n vehicles 50, such as model information and model numbers relating to the electronic control units, vehicle types, registration dates or the like.
  • an identification unit 31 of the updating device 30 then compiles a list L of all vehicles 50 that correspond to the identification criteria transmitted by the background device 10 .
  • information is obtained from the vehicles 50 via the radio links 40, which information may be required to identify the affected vehicles 50, for example operating states, error codes or the like.
  • the list L of the identified vehicles 50 is transferred to the background device 10 and there to the ML unit 12.
  • the identification unit 31 also transmits time specifications Z to the background device 10, which can also be based on the information received from the vehicles 50 in step S3.
  • time specifications Z relate in particular to information about the duration of an update campaign in question or the "rollout" in days or weeks, i.e. the time window in which the software update of all identified vehicles 50 should be completed, and possibly information about the duration of an individual update on one specific vehicle, which is generally dependent on the specific technical infrastructure of the vehicle in question 50.
  • the list L with the identified vehicles 50 and the time specifications Z are transferred to the machine learning unit 12 in step S4 and there as input values for a prediction of suitable update conditions B for the identified vehicles 50 based on the ML model 13 used, which finally combined to form an update plan 14 define the complete update campaign, ie the chronological/spatial sequence the software update of all vehicles 50 specified in list L within the time specification Z with regard to the duration of the campaign.
  • Step S8 combines the two operating phases of the ML unit 12, namely firstly the training of the ML model 13 based, among other things, on sensor data D that the ML unit 12 receives in step S7, and secondly the prediction of Update conditions B and an update plan 14 based on the list L and the timing Z, which the ML unit 12 receives in step S4.
  • 3 shows the two corresponding modules of the ML unit, namely the training module 12a, which trains the ML model 13 in step S8a, and the prediction module 12b, which derives update conditions B therefrom in step S8b.
  • the ML model 13 is prepared for the prediction of update conditions B by generating a multidimensional map of the mobile radio network from problem-specific, exemplary training data, which, with specific spatial and time resolutions, can be used to make predictions about the transmission qualities Q of future radio links 40 mapped or modeled.
  • problem-specific training data sensor data D from the vehicles 50 in particular are collected in steps S5 to S7 and made available to the ML unit 12, the specifically measured transmission qualities Q in as many radio cells of the mobile network and relate to as many points in time as possible.
  • the vehicles 50 are equipped with suitable sensors and measuring devices, so that in step S5 they take measurements with regard to the transmission qualities Q within the radio cells visited by the vehicles 50 and transmit them as sensor data D to a sensor data module 32 of the updating device 30 .
  • the sensors are suitably activated and deactivated in order to reliably obtain the desired sensor data D. mean, on the basis of which the ML model 13 is trained.
  • the sensor data also relate to time, date and location data, the latter for example in the form of the radio cell IDs of the measured radio network.
  • movement profiles of the vehicles 50 are also logged, for example in the form of GPS data, and made available to the sensor data module 32 .
  • the sensor data module 32 prepares the sensor data D of the vehicles 50 in a suitable manner and finally makes them available to the ML unit 12 as training data for the ML model 13 in step S7.
  • the sensor data module 32 prepares the movement profiles of the vehicles 50 in particular in such a way that movement data T with the best possible temporal and spatial resolution for each vehicle 50 is transferred to the ML unit, which particularly includes the times and routes of regular journeys identify the vehicle 50 in question, for example, regular trips to and from a place of work.
  • the individual movement data T also show the different driving behavior on the individual days of the week, for example due to part-time work, home office days and other weekly trips.
  • both training and prediction take place within the framework of step S8, a chronological sequence or dependency between training and prediction, and thus of steps S1 to S4 on the one hand and steps S5 to S7 on the other hand, requires the embodiment according to FIG .2a not. Rather, these two groups of steps can be interlinked in almost any way, for example in such a way that step S1 begins between steps S5 and S6 or that step S4 takes place at the same time as step S7.
  • this means that the ML model 13 according to the embodiment according to FIG. 2a is continuously trained based on ever new, current sensor data D, which are continuously supplied as part of step S7 will.
  • the ML-ModeU 13 is designed to be learning because it constantly adapts to current changes in the connection qualities Q and/or the movement data T of the vehicles 50 .
  • a prediction for determining update conditions B can therefore be carried out at any time and is always based on the ML model 13 that is current at the relevant point in time. The same prediction request can therefore result in different update conditions B at a later point in time due to a more up-to-date ML model 13 .
  • FIG. 1 the ML model 13 according to the embodiment according to FIG. 2a is continuously trained based on ever new, current sensor data D, which are continuously supplied as part of step S7 will.
  • the ML-ModeU 13 is designed to be learning because it constantly adapts to current changes in the connection qualities Q and/or the movement data T of the vehicles 50 .
  • the ML unit 12 is divided into a training module 12a and a prediction module 12b, as shown in FIG.
  • This specific embodiment assumes that the training phase of the ML model 13 according to step S8a is first fully completed before the prediction phase according to step S8b begins.
  • steps S5 to S8a are first carried out and only then when a stable, trained
  • Steps S1 to S4, S5 to S7, S9 and S10 are technically identical in FIGS. 2a and 2b, only the order of execution differs in the two embodiments, as does the differentiation of step S8 according to FIG. 2a into two separate substeps
  • the sensor data D and movement data T determined by the vehicles 50 and processed by the sensor data module 32 are used to assign transmission qualities Q to the radio cells at the relevant times. Those radio cells or those points in time or time intervals for which no sensor data D were collected, When training the ML model 13, transmission qualities Q derived from the existing sensor data D are assigned in order in this way to also complete the map with regard to those radio cells and time intervals for which no original sensor data D are available. This can also occur, for example, if only contradictory sensor data D is available for a radio cell or if insufficient or sufficiently reliable sensor data D could be collected.
  • Transmission qualities Q are derived as part of the training based on similarity criteria between network cells and/or specific characteristics of radio links.
  • the physical proximity of a radio cell without usable sensor data D to a radio cell with usable sensor data D is, for example, a simple similarity criterion.
  • Other meaningful similarity criteria can be the time-dependent traffic density or the number of network participants, both of which can be derived from the movement data T, or also the buildings and, in principle, any suitable criterion that influences the data rate of a radio link.
  • Suitable update conditions B for the identified vehicles 50 are then predicted with the trained ML model 13 and combined into an update plan 14 that allows the software to be installed on as many vehicles 50 as possible without interruption and within the specified time period of an update campaign .
  • the update conditions B are determined based on the movement data T of the affected vehicles. They define one or more possible radio connections along the logged routes of the vehicles 50 40, through which the software can be updated.
  • the update conditions B specify specific locations, for example in the form of radio cells regularly visited by the vehicle 50 in question, and corresponding times, at which the ML model 13 predicts a radio connection 40 with a sufficient transmission quality to the software of this Update vehicle 50 without disruption.
  • the ML model 13 ultimately makes this prediction based on the sensor data D and the transmission qualities Q derived from it during the training.
  • the movement data T form important secondary conditions in the prediction of suitable update conditions B because they limit the radio connections 40 that can potentially be used for software updating to the sensible radio connections 40 that a vehicle 50 can set up at all within the scope of its use. From these useful radio links 40 that the vehicle 50 can set up on its regular journeys, the ML model 13 determines those that probably offer sufficient transmission qualities Q to ensure the uninterrupted updating of the software.
  • the ML model 13 predicts update conditions B for all vehicles 50 that are listed in the list L, which presumably allow an uninterrupted e software update.
  • conflicts between the update conditions B of different vehicles 50 are avoided and, on the other hand, a global cost or loss function (“loss function”) is optimized or minimized, which becomes optimal/minimal precisely when for all in the list L listed vehicles 50 update conditions B can be found, which guarantee an uninterrupted software update with a high degree of probability are not only optimal for individual vehicles 50, but for the update campaign as a whole.
  • step S9 the update plan 14 is finally transferred to the update device 30 or its update module 33, so that in step S10 the update campaign is prepared and in step S11 instructions are given via the radio links 40 to the vehicles 50 in question to update their software .
  • FIG. 3 illustrates the ML unit 12 divided into its two already mentioned modules, namely the training module 12a and the prediction module 12b.
  • the training step S8a carried out by the training module 12a
  • the prediction step S8b carried out by the module 12b.
  • the embodiment according to FIG. 2a provides that both modules are used in parallel in the sense that a prediction (step S8b) is carried out at any time based on the current state of the ML model 13, while the "learning" ML model 13 is continuously trained with ever new sensor data D (step S8a).
  • the update campaign is trained for a certain period of time and is then, trained out, used to determine the update plan 14 without taking trends and changes into account while learning.
  • step S7 the training module 12a receives sensor data D and movement data T, from which transmission qualities Q with the highest possible temporal and spatial resolution are derived.
  • the ML model 13 thus models the above-mentioned map of the transmission qualities Q in the training step S8a.
  • the prediction step S8b is then carried out with the sufficiently trained ML model 13, the training module 12a movement data T transferred to the prediction module 12b and the list L of the identified vehicles 50 provided in step S4 as well as the time specifications Z.
  • update conditions B for all vehicles 50 of the list L are finally based on predictions with regard to the transmission qualities Q is determined and from this an update plan 14 is formed, which defines when and on which specific trip the software of each vehicle 50 is to be updated.
  • FIG. 4 illustrates the implementation of the update plan 14 and the associated update conditions B.
  • the update plan 14 is transferred to an update module 33 of the update unit 30, which then starts and monitors the update campaign.
  • the update conditions B relating to these vehicles 50 are transferred to the identified vehicles 50 or to the corresponding control devices CNTL of these vehicles 50 in step S11.
  • the control devices CNTL of the vehicles 50 thus independently monitor the presence of the respective update conditions B.
  • the software SW is then updated by the control device CNTL in step S12 if the update conditions B apply, if the driving - zeug 50 is within the predetermined time interval in the / the predetermined radio cell / n or drives through it.
  • the current software SW* is downloaded via the radio link 40, stored in the memory 51 and installed.
  • FIG. 5 shows a third preferred embodiment of the updating method according to the invention, which is based on the second preferred embodiment according to FIG. 2b.
  • FIG. 5 differs from FIG. 2b only with regard to steps S5 to S8a of FIG. 2b, which are replaced in FIG. 5 by steps S5, S6 and S7a to S7d. Steps S5, S6 and S7a to S7d according to FIG. 5 can just as well be supplemented in the embodiment according to FIG. 2a.
  • the background device 10 comprises a synthesis module 12c, which synthesizes a fleet-wide ML model 13a in the manner described below.
  • the updating device 30 comprises a forwarding module 34 which ensures bidirectional data communication between the background device 10 and the vehicles 50 .
  • the vehicles 50 each have their own sensor data module 53, which provides the relevant vehicle 50 with the functionality of the sensor data module 32 in FIG. 2a, as well as a training and synchronization module 52, which on the one hand tion of the training module 12a according to FIG.
  • the central functions of the training module 12a and the sensor data module 32 according to FIG. 2b are conceptually decentralized and integrated into each vehicle 50 of the vehicle fleet.
  • Steps S1 through S4 and S9 through S11 according to FIG. 5 are identical to the correspondingly numbered steps in FIGS. 2a and 2b.
  • Step S8b is also identical in the embodiments according to FIGS. 2b and 5.
  • step S5 according to FIG. 5 in a vehicle 50 vehicle-specific
  • Measurements regarding the transmission qualities Q are made within the radio cells visited by the vehicles 50 in question and are made available to the sensor data module 53 as sensor data D of the vehicle 50 in question.
  • the sensor data module 53 prepares the sensor data D and the individual data analogously to the function of the sensor data module 32 according to FIGS
  • the training and synchronization module 52 trains the vehicle-specific ML model 13b of the vehicle 50 with the vehicle-specific sensor and movement data D, T analogously to the function of the training module 12c according to FIG. 2b.
  • Steps S7b to S7e relate to the process of synthesizing (S7b, S7c) the fleet-wide ML model 13a, i.e. merging it from the vehicle-specific ML models 13b, and synchronizing (S7d, S7e) the respective vehicle-specific ML models 13b, i.e their update based on the synthesized fleet-wide ML model 13a.
  • the individual training progress of all vehicle-specific ML models 13b is bundled and made available to each individual vehicle-specific ML model 13b by means of steps S7b to S7e, in order thereby to improve the overall training quality.
  • step S7b there is a stable, trained, vehicle-specific ML model 13b on a vehicle 50, the predictions regarding the Transmission qualities Qb of radio connections based on the sensor data D of the respective vehicle allowed.
  • the radio links evaluated in this way can only come from radio cells that the relevant vehicle 50 has actually visited, for which the vehicle has therefore determined sensor data D or movement data T.
  • each vehicle-specific ML model 13b is gradually provided with more and more information about radio connections in radio cells that other vehicles 50 of the vehicle fleet have visited, so that the relevant vehicle-specific ML model 13b iteratively forms an ever better basis for predicting the transmission qualities Qb of radio links in the radio cells visited, since the relevant vehicle-specific ML model 13b acquires more and more contextual knowledge about other areas of the radio network.
  • all vehicles 50 in the vehicle fleet send vehicle-specific model data Mb to the forwarding module 34 of the updating device 30, which forwards the multitude of model data Mb to the synthesis module 12c of the background device 10 by vehicle or already bundled.
  • the respective training and synchronization module 52 generates incremental model data Mb as the vehicle-specific model data Mb of each vehicle-specific ML model 13b, which represents the difference between the training state of the relevant vehicle-specific ML model 13b at the current time (i.e. at the time of executing the Step S7b) and the
  • the incremental vehicle-specific model data Mb of individual or all vehicles 50 are combined in step S7c by the synthesis module 12c and synthesized to form a current fleet-wide ML model 13a, which then contains the current training results of all vehicle-specific ML models 13b .
  • the fleet-wide ML model 13a like the ML models 13 according to the embodiments according to FIGS. 2a and 2b, represents a stable, trained, fleet-wide ML model, which forms the basis for the subsequent prediction phase the step S8b and the derivation of update conditions B is.
  • the difference between the embodiment according to FIG. 5 and the embodiments according to FIGS. 2a and 2b is, among other things, that the fleet-wide ML model 13a and the transmission qualities Qa have the same training quality and a comparable prediction potential as the ML model 13 according to Figures 2a and 2b, that the fleet-wide ML model 13a does not come about through its own training phase, which would necessarily have to be based on the sensitive, personal sensor data D and movement data T, but through the synthesis step S7c, in in which only incremental model data Mb that are unproblematic with regard to any data protection provisions are combined.
  • the training takes place in the local steps S7a on the individual vehicles 50, so that the respective sensor data do not leave these vehicles 50.
  • the subsequent steps S7d and S7e relate to synchronization or updating of the individual vehicle-specific ML models 13b on fleet-wide, incremental model data Ma, which are extracted from the fleet-wide ML model 13a in step S7d.
  • the incremental model data Ma represent the difference between the training status of the fleet-wide ML model 13a and the current one
  • step S7d After the fleet-wide model data Ma have been sent from the synthesis module 12c via the forwarding module 34 of the updating device 30 to the respective training and synchronization modules 52 of the individual vehicles 50 in step S7d, on all of these vehicles 50 the relevant vehicle-specific ML model 13b updated with the fleet-wide model data Ma. After that, all vehicle-specific ML models 13b are synchronized and at this point represent the training status of the fleet-wide ML model 13a before the individual vehicle-specific ML models 13b diverge again as part of the respective vehicle-specific training by continuing to do so based on the vehicle-specifically collected sensor data D are further trained in a renewed step S7a.
  • This process consisting of the synthesis of the overall fleet ML model 13a through steps S7b and S7c and the synchronization of the vehicle-specific ML models 13b through steps S7d and S7e can be repeated regularly, for example after specified time intervals have elapsed.
  • the process of steps S7a to S7e can also be initiated by specific events, for example if sufficient training progress has been made with individual, a specific number or all vehicle-specific ML models 13b, or if sufficient new sensor data D were collected, which make a renewed synthesis/synchronization necessary.
  • the vehicle-specific model data Mb can be generated synchronously from the individual vehicle-specific ML models 13b and made available to the forwarding module 34 almost at the same time.
  • the forwarding module 34 can already bundle the vehicle-specific model data Mb of the vehicles 50 and forward them to the synthesis module 12c as a data set.
  • the synthesis module 12c would then combine this data set with the fleet-wide ML model 13a and thus form a new fleet-wide ML model 13a that combines the training progress of all vehicle-specific ML models.
  • the vehicles 50 can each send their vehicle-specific model data Mb independently of one another to the forwarding module 34 and temporarily stored by the latter and only forwarded in bundles to the synthesis module 12c when a sufficiently large data set of vehicle-specific model data Mb from different vehicles 50 is available.
  • a practical and non-limiting example of an ML model 13, as described in connection with Figures 2 to 5, has output or result classes (output) for uninterrupted mobile radio connections of different durations:
  • the ML model 13 includes a classifier based on decision trees, such as a random forest classifier or an extreme gradient boosting classifier.
  • classifiers can be operated efficiently with the hardware of a vehicle 50 even with the limited resources in a vehicle 50 and with small training data sets, because they can be trained quickly and can be easily parallelized.
  • the specific definition of the output classes and the specific features is selected or configured depending on certain preconditions, for example depending on the region in which the relevant vehicles 50 are moving, or on seasonal or cultural circumstances or the like.
  • the vehicles 50 are equipped with pre-trained ML models 13 (or fleet-wide ML models 13a), which are then further trained individually in the relevant vehicles 50 and then form vehicle-specific ML models 13b.
  • the pre-trained ML model 13 includes assignments of the probabilities of occurrence of the output classes to the various locations and directions of travel, illustrated using the two categories “location” and “direction of travel”.
  • a specific combination of location and driving direction is assigned the vector (0.06; 0.13; 0.18; 0.22; 0.26; 0.12; 0.03), which means that in the In the relevant situation, statistically 6% of all mobile phone connections were stable or uninterrupted between 0 and 5 minutes, 13% of all mobile phone connections were stable or uninterrupted between 5 and 10 minutes, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Gemäß einem Verfahren zum Aktualisieren einer Software in Fahrzeugen (50) einer Fahrzeugflotte wird zumindest ein Fahrzeug (50) der Fahrzeugflotte identifiziert (S2), dessen Software (SW) zu aktualisieren ist, und die Software (SW) des identifizierten Fahrzeugs (50) wird dann über eine Funkverbindung (40) gemäß vorgegebenen Aktualisierungsbedingungen (B) aktualisiert (S12, S13). Erfindungsgemäß werden die Aktualisierungsbedingungen (B) derart bestimmt (S8; S8b), dass ein Maschinenlern-Modell (13; 13a, 13b), welches Übertragungsqualitäten (Q) von Funkverbindungen (40) modelliert, für die Funkverbindung (40) eine ausreichende Übertragungsqualität (Q) voraussagt, um die Software (SW) des zumindest einen Fahrzeugs (50) zu aktualisieren (S12, S13).

Description

S of tw ar e - Ak tu alis i e r un g üb er e ine Funkv e rb indun g
Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren einer Soft- ware in Fahrzeugen einer Fahrzeugflotte, ein Aktualisierungssystem, welches eine solche Aktualisierung an Fahrzeugen der Flotte vornimmt, ein derartiges Fahrzeug sowie eine Hmtergrundeinrichtung und eine Aktuahsierungseinrich- tung des Aktualisierungssystems.
Moderne Fahrzeuge sind mit einer Vielzahl von elektronischen, Software-ge- steuerten Komponenten ausgestattet, welche Funktionen des Fahrzeugs steuern und implementieren. Solche Fahrzeuge umfassen beispielsweise ehre Vielzahl von elektronischen Steuergeräten (ECU = Electronic Control Unit) in unter- schiedlichen Ausprägungen, die mit Mikroprozessoren und geeigneten Spei- chereinrichtungen ausgestattet sind und Funktionen des Fahrzeugs überneh- men, die beispielsweise die Motor- und Antriebssteuerung, Diagnose- und Si- cherheitssysteme, Navigations-, Assistenz- und Kommunikationssysteme und dergleichen mehr betreffen.
Die in solchen Steuersystemen installierte Software ist in der Regel eine Be- triebssoftware oder Firmware, die das Verhalten der betreffenden Komponen- ten bzw. ECUs vorgibt und insbesondere aus Sicherheitsgründen regelmäßig aktualisiert werden muss, zum Beispiel indem Updates und/ oder Patches ein- gespielt werden, die Teile der Software oder die Software als Ganzes ersetzen. Inzwischen ist man dazu übergegangen, die Softwareaktualisierung bei Fahr- zeugen während der Fahrt mittels der mobilen Datenkommunikation durchzu- führen, beispielsweise über eine herkömmlichen Mobilfunkverbindung eines Mobilfunknetzes in das sich das betreffende Fahrzeug als Teilnehmer einwählt, beispielsweise über eine SIM- oder eSIM-Mobilfunkkarte. In diesem Zusammenhang ist unter Aktualisierung oder Softwareaktualisie- rung ein Prozess zu verstehen, mit dem eine auf einem Server bereitliegende aktuelle Software zunächst auf das Fahrzeug heruntergeladen, in einem geeig- neten Speicher abgelegt und anschließend in den richtigen Steuereinheiten und -komponenten installiert wird. Beim anschließenden Installieren wird die bishe- rige Software durch die heruntergeladene, aktuelle Software ersetzt und gege- benenfalls so konfiguriert, dass sie bei Ausführung durch einen Mikroprozessor die Aufgaben der bisherigen Software übernimmt. Während eine geeignete Funkverbindung hauptsächlich zum Herunterladen der Software auf das Fahr- zeug benötigt wird, kann auch das Installieren bzw. Konfigurieren der aktuel- len Software in dem Fahrzeug eine Funkverbindung erfordern, zum Beispiel um von dem Server Konfigurationsdaten herunterzuladen oder spezifische Da- ten, wie zum Beispiel Schlüssel, Prüfsummen, Kennungen, Referenzen oder dergleichen auf den Server hochzuladen. Mit dem Begriff „Aktualisierung" o- der „Softwareaktualisierung" ist im Folgenden also insbesondere derjenige An- teil dieses Prozesses gemeint, für den eine stabile Funkverbindung benötigt wird.
Hierbei ergibt sich das Problem, dass das Herunterladen einer aktuellen Soft- wareversion über eine Funkverbindung aufgrund von deren Größe häufig län- ger dauert und damit die Gefahr steigt, dass die Funkverbindung während des Herunterladens fahrtbedingt abbricht. Nach dem Abbruch oder einer Störung einer Funkverbindung kann das Herunterladen einer Software aber nicht naht- los fortgesetzt werden, sobald wieder eine Funkverbindung besteht, so dass der der Prozess des Herunterladens unter Umständen mehrfach wiederholt werden muss, bevor die Software vollständig auf dem Fahrzeug vorliegt.
Daraus ergeben sich viele technische Nachteile, insbesondere erhöhter Batterie- verbrauch im Fahrzeug und Energieverbrauch insgesamt, unnötige Belastung des betreffenden Funknetzwerks und der Server, von denen die Software her- untergeladen wird, oder dergleichen. Es ist insofern die Aufgabe der vorliegenden Erfindung, eine Lösung vorzu- schlagen, die die oben genannten und weitere Nachteile des Standes der Tech- nik vermeidet.
Gelöst wird diese Aufgabe durch ein Verfahren, ein Aktualisierungssystem, eine Hintergrundeinrichtung und eine Aktualisierungseinrichtung des Hinter- grundsystems sowie ein Fahrzeug gemäß den unabhängigen Ansprüchen. In den abhängigen Ansprüchen werden weitere Ausgestaltungen bevorzugter Ausführungsformen der Erfindung angegeben.
Gemäß eines Hauptaspekts der Erfindung werden zum Aktualisieren einer Software in Fahrzeugen einer Fahrzeugflotte zunächst diejenigen Fahrzeuge der Flotte identifiziert, deren Software zu aktualisieren ist. Bei diesem Schritt wird zumindest eines der Fahrzeuge der Fahrzeugflotte ausgewählt, dessen Software über eine bestehende Funkverbindung gemäß vorgegebenen Aktualisierungs- bedingungen anschließend aktualisiert wird.
Die Aktualisierungsbedingungen werden erfindungsgemäß mittels eines Ma- schinenlern-Modells bzw. „Machine Learning Model" bestimmt, im Folgenden auch als ML-Modell bezeichnet, welches Übertragungsqualitäten von möglichst vielen verschiedenen Funkverbindungen über ein Funknetzwerk modelliert, also von Funkverbindungen zu verschiedenen Zeiten und an verschiedenen Or- ten des Funknetzwerks. Das ML-Modell ist also vergleichbar mit einer zeitlich variablen, veränderlichen Karte, die mit einer bestimmten Ortsauflösung, bei- spielsweise entsprechend den Funkzellen eines Mobilfunknetzwerks, Übertra- gungsqualitäten von Funkverbindungen kartiert und zwar zeitabhängig mit ei- ner bestimmten Zeitauflösung über einen sinnvollen Zeitraum hinweg, bei- spielsweise einen Tag eine Woche, oder einen Monat. Dieses ML-Modell ist das Ergebnis eines fortgesetzten Trainingsprozesses, der nachfolgend beschrieben werden wird. Das trainierte ML-Modell wird einge- setzt, tun Vorhersagen hinsichtlich der Übertragungsqualitäten von Funkver- bindungen abzuleiten, über die zukünftig die Software des zumindest einen identifizierten Fahrzeugs aktualisiert werden kann. Die Aktualisierungsbedin- gungen werden dann so bestimmt, dass sie eine oder mehrere zukünftig mögli- che Funkverbindungen hinreichend genau spezifizieren, deren vorausgesagte Übertragungsqualitäten ausreichen, um die Software des Fahrzeugs zu aktuali- sieren.
Unter einer „zukünftigen Funkverbindung" ist in diesem Zusammenhang eine solche Funkverbindung zu verstehen, die das Fahrzeug in der Zukunft potenti- ell aufbauen und unterhalten kann, um die Software über diese Funkverbin- dung zu aktualisieren, sobald sie besteht. Das ML-Modell sagt also voraus, un- ter welchen Aktualisierungsbedingungen die Software des Fahrzeugs mit hin- reichend hoher Wahrscheinlichkeit so aktualisiert werden kann, dass die ein- gangs geschilderten Nachteile des Standes der Technik vermieden werden.
Für eine Funkverbindung wird von dem ML-Modell eine im Sinne der Erfin- dung ausreichende Übertragungsqualität vorausgesagt, wenn sie voraussicht- lich geeignet ist, den Vorgang des Aktualisierens der Software erfolgreich abzu- schließen sobald er begonnen wird. Hierbei liegt es in der Natur von Voraussa- gen durch ein Maschinenlern-Modell, dass diese nicht zutreffen müssen, son- dern nur wahrscheinlich zutreffen. So kann ein unerwartet hohes Verkehrsauf- kommen in bestimmten Funkzellen, zum Beispiel aufgrund einer Baustelle in anderen Funkzellen, die tatsächliche Übertragungsqualität einer Funkverbin- dung entgegen der Voraussage verschlechtern.
Erfindungsgemäß ist das durch Training erzeugte ML-Modell, welches Übertra- gungsqualitäten von potentiellen Funkverbindungen modelliert, die Grundlage einer Voraussage, unter welchen Umständen die Software des betreffenden Fahrzeugs voraussichtlich unterbrechungsfrei aktualisiert werden kann. Diese Umstände der unterbrechungsfreien Aktualisierung werden durch Aktualisie- rungsbedingungen beschrieben. Wenn die Software also gemäß den Aktualisie- rungsbedingungen aktualisiert wird, können die eingangs geschilderten Nach- teile des Standes der Technik voraussichtlich vermieden werden.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird das erfin- dungsgemäße Aktualisierungsverfahren von einem Aktualisierungssystem aus- geführt, welches eine Hintergrundeinrichtung umfasst sowie zumindest eine mit der Hintergrundeinrichtung über eine Datenkommunikationsverbindung in Kontakt stehende Aktualisierungseinrichtung. Die Aktuahsierungseinrich- tung identifiziert die Fahrzeuge, deren Software zu aktualisieren ist, baut die hierzu benötigten Funkverbindungen zu den Fahrzeugen auf und aktualisiert schließlich die Software der identifizierten Fahrzeuge gemäß den vorgegebenen Aktualisierungsbedingungen. Auf der Hintergrundeinrichtung ist das ML- Modell eingerichtet, welches Übertragungsqualitäten von potentiellen Funkver- bindungen modelliert.
Während als Datenkommunikationsverbindungen zwischen der Hintergrund- einrichtung und der einen oder den mehreren Aktualisierungseinrichtimgen herkömmliche kabelgebundene Verbindungen genutzt werden, zum Beispiel übliche Intemet/DSL-Verbindungen, besteht zwischen der zumindest einen Aktualisierungseinrichtung und den betreffenden Fahrzeugen jeweils lediglich eine drahtlose Funkverbindung, zum Beispiel über ein herkömmliches Mobil- funknetzwerk.
Gemäß eines weiteren Aspekts der Erfindung bestimmt das auf einer erfin- dungsgemäßen Hintergrundeinrichtung eingerichtete Maschinenlern-Modell erfindungsgemäß die individuellen Aktualisierungsbedingungen zum Aktuali- sieren der Software eines jeden identifizierten Fahrzeugs derart, dass die Aktu- alisierungsbedingungen jeweils Funkverbindungen beschreiben, für die gemäß Voraussage jeweils ausreichende Übertragungsqualitäten zu erwarten sind. Dadurch kann die Software der betreffenden Fahrzeuge erfindungsgemäß aktu- alisiert werden, vorzugsweise unterbrechungsfrei und/oder innerhalb eines vorgegebenen Zeitfensters, innerhalb dessen die Softwareaktualisierung begon- nen und vollständig beendet wird.
Gemäß eines weiteren Aspekts der vorliegenden Erfindung ist ein Fahrzeug derart eingerichtet, dass seine Software durch ein erfindungsgemäßes Aktuali- sierungssystem in erfindungsgemäßer Art und Weise aktualisiert werden kann. Entsprechend umfasst ein erfindungsgemäßes Fahrzeug Mittel zum Aufbau ei- ner Funkverbindung nach Vorgabe der AJktualisierungsbedingungen und zum Herunterladen und Installieren einer aktuellen Software in den betreffenden Steuergeräten und ECU-Komponenten.
Die Übertragungsqualität, die von dem Maschinenlern-Modell der Bestimmung von Aktualisierungsbedingungen zugrunde gelegt wird, ist vorzugsweise eine Datenübertragungsrate bzw. Datenrate, also ein Maß dafür, welches digitale Datenvolumen innerhalb einer bestimmten Zeitspanne und an einem bestimm- ten Standort, zum Beispiel innerhalb einer Funkzelle, über die betreffende Funkverbindung übertragen werden kann. Je größer die Datenrate ist und je länger die Datenrate aufrechterhalten werden kann, desto größer ist die Über- tragungsqualität der betreffenden Funkverbindung, denn desto schneller und zuverlässiger kann eine Softwareaktualisierung über diese Funkverbindung er- folgen. Je mehr Teilnehmer sich jedoch zum gleichen Zeitpunkt bzw. innerhalb der gleichen Zeitspanne in einer Funkzelle (voraussichtlich) anmelden, je mehr parallele Funkverbindungen also (voraussichtlich) bestehen, desto geringer ist die (voraussichtliche) Datenrate jeder einzelnen dieser Funkverbindungen.
Eine ausreichende Übertragungsqualität im Sinne der Erfindung wird also von dem ML-Modell insbesondere dann vorausgesagt, wenn für eine Funkverbin- düng eine Datenrate erwartet wird, die für eine bestimmte Dauer eine vorgege- bene minimale Datenrate überschreitet, so dass die Software innerhalb dieser Dauer aktualisiert werden kann. Für Funkverbindungen, für die das ML- Modell eine Datenrate vorhersagt, die die minimale Datenrate innerhalb der vorgegebenen Zeitdauer überschreitet, werden Aktualisierungsbedingungen ermittelt, gemäß denen das Fahrzeug die Softwareaktualisierung voraussicht- lich unterbrechungsfrei durchführen kann, sobald diese zutreffen.
Vorzugsweise wird dabei auch die digitale Größe bzw. das Datenvolumen der über die Funkverbindung herunterzuladenden aktuellen Software berücksich- tigt und die Aktualisierungsbedingungen werden entsprechend derart festge- legt, dass die die minimale Datenrate ausreichend lange überschritten wird, um die Software vollständig aktualisieren zu können. Mit anderen Worten, die Ak- tualisierungsbedingungen werden insbesondere so bestimmt, dass die Funkver- bindung zeitlich ausreichend stabil ist, sie also lange genug unterbrechungsfrei zur Verfügung steht, um die Software zu aktualisieren.
Da es sich dabei aber um eine Voraussage handelt, kann nicht angenommen werden, dass die vorausgesagte Übertragungsqualität sicher vorliegen wird, so- bald die Aktualisierungsbedingungen erfüllt sind. Stattdessen ist nur mit einer hinreichend hohen Wahrscheinlichkeit damit zu rechnen, dass die Voraussage eintrifft und die Software ohne Unterbrechungen der Funkverbindung aktuali- siert werden kann. Eine solche vorgegebene Wahrscheinlichkeit ist beispiels- weise größer 0,8 (> 80%), größer 0,9 (> 90%) oder größer 0,95 (> 95%) oder grö- ßer als 0,98 (> 98%).
Die Aktualisierungsbedingungen umfassen vorzugsweise zumindest eine Zeit- bedingung und zumindest eine Ortsbedingung. Bevorzugt wird zumindest ein Bedingungspaar ermittelt, bestehend aus einer Zeitbedingung und einer Orts- bedingung, Die Software wird dann automatisch aktualisiert, sobald eines der Bedingungspaare zutrifft, die das ML-Modell für das betreffende Fahrzeug be- stimmt hat; wenn das Fahrzeug also sowohl die Orts- als auch die Zeitbedin- gung erfüllt.
Als Ortsbedingung wird beispielsweise eine Funkzelle oder ein bestimmter Standort, ein Straßenabschnitt oder ein Flächenareal bestimmt, in der oder dem die Aktualisierung der Software des betreffenden Fahrzeuges stattfinden muss. Die Zeitbedingung gibt vorzugsweise ein Zeitintervall an, innerhalb dessen die Software zu aktualisieren ist, während das Fahrzeug gleichzeitig die Ortsbedin- gung erfüllt. Das Zeitintervall ist dabei so bemessen, dass die Software bei der zugehörigen vorausgesagten Übertragungsqualität vollständig aktualisiert wer- den kann.
Neben dem Bestimmen der AktuaHsierungsbedingungen mittels Vorhersage von Übertragungsqualitäten für Funkverbindungen wird auch das Trainieren des ML-Modells von der zentralen Hintergrundeinrichtung durchgeführt. Kon- kret werden alle Vorgänge und Operationen von der Hintergrundeinrichtung durchgeführt, die mit dem Erzeugen, Trainieren und Nutzen des ML-Modells Zusammenhängen. Dabei wird das ML-Modell zunächst mit Trainingsdaten trainiert, um dann, in einem anschließenden Schritt, mit dem ML-Modell Vo- raussagen betreffend die Übertragungsqualitäten von Funkverbindungen zu treffen bzw. aus dem trainierten ML-Modell abzuleiten und geeignete Aktuali- sierungsbedingungen zu ermitteln.
Als Trainingsdaten werden deshalb von den Fahrzeugen der Fahrzeugflotte eine Vielzahl von Sensordaten erhoben, die über eine Aktualisierungseinrich- tung an die Hintergrundeinrichtung weitergeleitet werden und dort als Trai- ningsdaten für das ML-Modell dienen. Zu diesen Sensordaten zählen insbeson- dere Messwerte der konkreten Übertragungsqualitäten bzw. Datenraten von Funkverbindungen inklusive zugehöriger Orts- und Zeitdaten, die von den Fahrzeugen während ihres regulären Fährbetriebs erhoben werden. Wenn ein Fahrzeug eine Funkzelle durchfährt, misst es die Übertragungsqualität einer ak- tuellen Funkverbindung, zum Beispiel in Form der aktuellen Datenübertra- gungsrate, und liefert diese zusammen mit Angaben zu der betreffenden Funk- zelle und dem Zeitpunkt als Sensordaten an die Aktualisierungseinrichtung.
Weitere Sensordaten, die vorzugsweise auch zum Training des ML-Modells eingesetzt werden, betreffen Angaben zur Anzahl aktiver Funkverbindungen innerhalb von Funkzellen zu bestimmten Zeitpunkten oder innerhalb bestimm- ter Zeitintervalle, ebenso wie Angaben zu den konkreten Fahrtwegen der Fahr- zeuge, also zu den Bewegungsmustern der Fahrzeuge durch das Funknetzwerk und den besuchten Funkzellen inklusive der entsprechenden Zeitangaben.
Die Aktualisierungseinrichtung leitet diese Sensordaten nicht einfach an die Hmtergrundeinrichtung weiter, sondern bereitet sie nötigenfalls auf. So kann ein einzelnes Fahrzeug möglicherweis keine Messungen zu der Anzahl der zu einem Zeitpunkt aktiven Funkverbindungen vornehmen, so dass die Aktuali- sierungseinrichtung vorzugsweise die Sensordaten von vielen Fahrzeugen aus- wertet, tun daraus solche Angaben abzuleiten. Selbiges gilt für die Bewegungs- daten der einzelnen Fahrzeuge, die auch erst von der Aktualisierimgseinrich- tung aus den Sensordaten der Fahrzeuge betreffend bestimmte Funkzellen ge- neriert werden.
Während diese Sensordaten und Bewegungsdaten lediglich Momentaufnah- men zu den Übertragungsqualitäten verschiedener Funkverbindungen inner- halb des Funknetzes betreffen, wird beim Trainieren des ML-Modells basierend auf den Sensor- und Bewegungsdaten ein möglichst umfassendes Modell mit Mitteln des Maschinenlernens erzeugt, das es erlaubt, Vorhersagen zu den Übertragungsqualitäten möglichst vieler örtlich/ zeitlich verschiedener zukünf- tiger Funkverbindungen zu treffen. Durch das Trainieren des ML-Modells wird also die oben angesprochene zeitlich variable Karte des Mobilfunknetzes er- zeugt, die mit bestimmter Orts- und Zeitauflösung Voraussagen zu Übertra- gungsqualitäten von zukünftigen Funkverbindungen kartiert.
Basierend auf den von den Fahrzeugen konkret gemessenen Übertragungsqua- litäten in bestimmten Funkzellen zu bestimmten Zeiten werden beim Trainieren des ML-Modells mögliche Übertragungsqualitäten von Funkverbindungen ab- geleitet, zu denen keine Sensordaten vorliegen. Die Übertragungsqualitäten sol- cher Funkverbindungen werden beim Trainieren also geschätzt bzw. aus den vorhandenen Sensordaten extrapoliert, beispielsweise anhand von Sensordaten aus Funkzellen oder für Zeitintervalle mit ähnlicher Charakteristik. So kann beispielsweise die örtliche Nähe einer Funkzelle, zu der keine oder nicht genü- gend Sensordaten vorliegen, zu anderen Funkzellen, für die ausreichende Sens- ordaten erhoben wurden, eine ähnliche Charakteristik sein, oder vergleichbare Verkehrsaufkommen in zwei Fuhkzellen, ähnliche Bevölkerungsdichten oder dergleichen. Vorzugsweise werden Funkzellen anhand solcher und anderer Charakteristika zu Clustern gruppiert und Sensordaten für eine oder wenige Fuhkzellen eines Clusters für alle weiteren Funkzellen des Clusters verwendet.
Mit dem derart trainierten ML-Modell werden dann für ein Fahrzeug, dessen Software aktualisiert werden soll, Vorhersagen zu den Übertragungsqualitäten von F unk Verbindungen getroffen, die dieses Fahrzeug in der Zukunft potentiell nutzen könnte, um dessen Software zu aktualisieren. Hierbei werden vorzugs- weise die Bewegungsdaten des Fahrzeugs zugrunde gelegt, damit nur Funkver- bindungen in Betracht gezogen werden, die das Fahrzeug während seines übli- chen Betriebs, zum Beispiel auf sich regelmäßig wiederholenden Fahrten, auch realistisch aufbauen kann. Das ML-Modell wählt dann eine oder mehrere dieser Funkverbindungen aus, für die ausreichend stabile Übertragungsqualitäten vo- rausgesagt werden, und die vorzugsweise auf die Bewegungsdaten des Fahr- zeugs abgestimmt sind. Die Aktualisierungsbedingungen, gemäß denen die Software des betreffenden Fahrzeugs aktualisiert wird, beschreiben dann die ausgewählten Funkverbin- dungen mit potentiell ausreichenden Übertragungsqualitäten. Wenn das ML- Modell zum Beispiel an einem bestimmten Wochentag auf dem morgendlichen Arbeitsweg und an einem anderen Arbeitstag auf dem abendlichen Weg nach
Hause in bestimmten, von dem Fahrzeug besuchten Funkzellen ausreichende Übertragungsqualitäten voraussagt, beschreiben die Aktualisierungsbedingun- gen Standorte bzw. Funkzellen und Zeitpunkte bzw. Zeitintervalle dieser bei- den Situationen, so dass zwei unterschiedliche Möglichkeiten angeboten wer- den, die Software zu aktualisieren.
Gemäß einer besonderen Ausgestaltung der Erfindung werden für alle identifi- zierten Fahrzeuge Aktualisierungsbedingungen bestimmt und zu einem Aktua- lisierungsplan zusammengefasst, der Grundlage einer Aktualisierungskam- pagne ist, die innerhalb eines vorgegebenen Zeitrahmes die Software aller iden- tifizierten Fahrzeuge aktualisiert. Dem ML-Modell werden zur Erzeugung eines optimalen Aktualisierungsplans deshalb die Liste aller identifizierten Fahr- zeuge, deren Software zu aktualisieren ist, die entsprechenden Zeitvorgaben hinsichtlich des gewünschten Zeithorizonts der AktuaÜsierungskampagne so- wie die Bewegungsdaten der betreffenden Fahrzeuge bereitgestellt.
Dies erfordert, dass die Aktuaüsierungsbedingungen nicht für jedes einzelne Fahrzeug unabhängig von denen anderer Fahrzeuge bestimmt werden, sondern dass vielmehr ein optimaler Aktualisierungsplan gefunden wird, der eine über- geordnete Kostenfunktion minimiert oder eine übergeordnete Nutzenfunktion maximiert. Eine solche Funktion wird dann optimal, wenn für möglichst viele Fahrzeuge auf deren Bewegungsdaten abgestimmte Übertragungsqualitäten vorhergesagt werden und Aktualisierungsbedingungen gefunden werden, die nicht miteinander kollidieren. Sobald die Aktualisierungsbedingungen für ein Fahrzeug zutreffen, wird des- sen Software aktualisiert. Die Aktualisierungsbedingungen können entweder von der Aktualisierungseinrichtung überwacht und umgesetzt werden oder au- tonom von jedem Fahrzeug selbst.
Bei einer besonders vorteilhaften Ausgestaltung der Erfindung wird vermie- den, dass sensible personenbezogene Daten, wie etwa die als Trainingsdaten für das ML-Modell verwendeten Sensor- und/ oder Bewegungsdaten, die über Aufenthaltsorte und -Zeiten von Personen Auskunft geben und insofern gelten- den Datenschutzbestimmungen unterliegen können, das jeweilige Fahrzeug verlassen und dadurch potentiell Unbefugten zugänglich werden können.
Um dies zu erreichen, kann die oben beschriebene Erfindung auch als „federa- ted learning"-V ariante realisiert werden. Beim „federated leaming" handelt es sich um einen verteilten bzw. dezentralen Ansatz des Maschinenlernens, bei dem lokale Instanzen eines ML-Modells dezentral basierend auf jeweils indivi- duellen, lokalen Trainingsdaten trainiert werden.
Deshalb ist gemäß dieser Ausgestaltung der Erfindung auf mehreren Fahrzeu- gen, vorzugsweise auf allen Fahrzeugen der Fahrzeugflotte, ein lokales, fahr- zeugindividuelles ML-Modell installiert, welches basierend lediglich auf den Sensor- und/ oder Bewegungsdaten des betreffenden, individuellen Fahrzeuges trainiert wird. Die Fahrzeuge bzw. deren fahrzeugindividuellen ML-Modelle tauschen dabei keine personenbezogenen (Trainings-) Daten untereinander o- der mit der Hintergrund- oder Aktualisierungseinrichtung aus.
Auf der Hintergrundeinrichtung wird ein korrespondierendes, übergeordnetes und flottenübergreifendes ML-Modell betrieben, welches einerseits die lokalen Trainingsergebnisse der einzelnen fahrzeugindividuellen ML-Modelle flotten- übergreifend integriert und welches andererseits genutzt wird, um die einzel- nen fahrzeugindividuellen ML-Modelle zu aktualisieren und zu synchronisie- ren. Während die fahrzeugindividuellen ML-Modelle also jeweils basierend auf fahrzeugindividuellen Sensor- und Bewegungsdaten trainiert werden, wird das flottenübergreifende ML-Model nicht trainiert, sondern synthetisiert. Durch die Synthese wird der Trainingszustand des das flottenübergreifende ML-Model al- lerdings in ähnlicher Weise verbessert, wie bei einem herkömmlichen Training des flottenübergreifende ML-Models.
In regelmäßigen Zeitabständen oder nach Bedarf werden die lokalen, fahrzeug- individuellen ML-Modelle zu einem aktualisierten, flottenübergreifenden ML- Modell auf der Hintergrundeinrichtung zusammengeführt bzw. synthetisiert. Das derart gebildete flottenübergreifende ML-Modell repräsentiert dann eine Synthese der Trainingsergebnisse aller fahrzeugindividuellen ML-Modelle zu einem bestimmten Zeitpunkt und mit ihm werden die fahrzeugindividuellen ML-Modelle vorzugsweise immittelbar nach der Synthese wieder aktualisiert bzw. synchronisiert. Dazu wird das synthetisierte, flottenübergreifende ML- Modell von der Hintergrundeinrichtung über die Aktualisierungseinrichtung an die Fahrzeuge der Fahrzeugflotte weitergegeben, so dass aufgrund der Syn- chronisation jedes fahrzeugindividuelle ML-Modelle auch von den Trainingser- gebnissen aller anderen fahrzeugindividuellen ML-Modelle profitiert.
Das Zusammenführen (Synthetisieren) des flottenübergreifenden ML-Modells und das anschließende Aktualisieren (Synchronisieren) der fahrzeugindividuel- len ML-Modelle wird mit geeigneten Datenstrukturen derart durchgeführt, dass keine personenbezogenen Sensor- und/ oder Bewegungsdaten zwischen den Fahrzeugen und dem Hintergrundsystem ausgetauscht werden. Vielmehr werden lediglich fahrzeugindividuelle bzw. flottenübergreifende, repräsenta- tive Modelldaten übertragen, die aus den fahrzeugindividuellen bzw. flotten- übergreifenden ML-Modellen jeweils basierend auf deren jeweiligem Trainings- zustand abgeleitet werden. Aus diesen repräsentativen Modelldaten sind die zugrundeliegenden, perso- nenbezogenen Trainingsdaten nicht mehr zu extrahieren, denn die Modelldaten betreffen Schätzungen von Übertragungsqualitäten von potentiellen Funkver- bindungen, die aus den Sensordaten extrapoliert wurden und diese dadurch derart verfremden, dass sie für Unbefugte keinen Wert mehr haben können.
Vorzugsweise repräsentieren die fahrzeugindividuellen Modelldaten, die je- weils aus den betreffenden fahrzeugindividuellen ML-Modellen abgeleitet wer- den, eine Differenz bzw. einen Unterschied zwischen dem aktuellen Zustand des betreffenden fahrzeugindividuellen ML-Modells und dem Zustand dieses ML-Modells nach dessen letzter Aktualisierung. Die fahrzeugindividuellen Mo- delldaten, die schließlich zu dem flottenübergreifenden ML-Modell zusammen- geführt werden, betreffen also vorzugsweise Inkremente der Trainingszustände bzw. inkrementeile Trainingsfortschritte des jeweiligen fahrzeugindividuellen ML-Modells zwischen zwei Trainingsphasen oder zwei Zeitpunkten innerhalb einer Trainingsphase.
Entsprechend repräsentieren auch die flottenübergreifenden Modelldaten, die zur Synchronisation der fahrzeugindividuellen ML-Modelle aus dem flotten- übergreifenden ML-Modell abgeleitet werden, eine Differenz bzw. einen Unter- schied zwischen dem aktuellen Zustand des flottenübergreifenden ML-Modells und dem Zustand dieses ML-Modells nach dessen letzter Synthese aus den fahrzeugindividuellen ML-Modellen. Die flottenübergreifenden Modelldaten, mit denen die fahrzeugindividuellen ML-Modelle aktualisiert werden, betreffen also Inkremente der Trainingszustände bzw. inkrementeile Trainingsfort- schritte des flottenübergreifenden ML-Modells zwischen zwei Trainingsphasen oder zwei Zeitpunkten innerhalb einer Trainingsphase.
Die derart aktualisierten fahrzeugindividuellen ML-Modelle werden dann an- hand der von diesem Fahrzeug im weiteren Verlauf individuell erhobenen Sen- sor- und Bewegungsdaten weiter trainiert, sodass die verschiedenen fahrzeug- individuellen ML-Modelle nach deren Synchronisation wieder divergieren. Die dadurch entstehenden Unterschiede werden zu einem geeigneten Zeitpunkt wieder in Form von fahrzeugindividuellen Modelldaten aus den jeweiligen fahrzeugindividuellen ML-Modellen extrahiert und erneut zum flottenübergrei- fenden ML-Modell zusammengeführt. Aus dem derart synthetisierten flotten- übergreifenden ML-Model können dann Vorhersagen zu den Übertragungs- qualitäten von Funkverbindungen basierend auf den Sensordaten aller Fahr- zeuge der Fahrzeugflotte getroffen werden.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung erfindungsgemäßer Ausführungsbeispiele sowie weiterer Aus- führungsalternativen im Zusammenhang mit den Zeichnungen, die zeigen:
Fig. 1 ein Schema eines erfindungsgemäßen Aktualisierungssystems;
Fig. 2a eine erste bevorzugte Ausführungsform des erfindungsgemäßen Ak- tualisierungsverfahrens;
Fig. 2b eine zweite bevorzugte Ausführungsform des erfindungsgemäßen Aktualisierungsverfahrens;
Fig. 3 ein Schema der Maschinenlem-Einheit eines erfindungsgemäßen
Hintergrundsystems;
Fig.4 ein Schema der Aktualisierung der Software eines Fahrzeugs; und
Fig. 5 eine dritte bevorzugte Ausführungsform des erfindungsgemäßen Aktualisierungsverfahrens. Fig. 1 zeigt exemplarisch ein erfindungsgemäßes Aktualisierungssystem umfas- send eine zentrale Hintergrundeinrichtung 10 (HGE) sowie mehrere mit dieser über geeignete, üblicherweise kabelgebundene Datenkommunikationsverbin- dungen 20 in Datenkommunikation stehende AktuaHsierungseinrichtungen 30 (SAE). Die Aktualisierungseinrichtungen 30 wiederum unterhalten individuelle Funkverbindungen 40 zu einer Vielzahl von Fahrzeugen 50 einer Fahrzeug- flotte, über die die Aktualisierungseinrichtungen 30 zu verschiedenen Zwecken mit den Fahrzeugen 50 Datenkommunikation betreiben können, zum Beispiel zu Zwecken der Fernwartung, Messwerterhebung, Sensoransteuerung oder dergleichen. Über die Funkverbindungen 40 wird darüber hinaus auch die Ak- tualisierung von Software, die auf den Fahrzeugen 50 installiert ist, nach Vorga- ben der Hintergrundeinrichtung 10 veranlasst.
Die Fahrzeuge 50 sind mit komplexen elektronischen Steuer- und Regelsyste- men ausgestattet, die in der Regel als eingebettete Module („embedded Sys- tems") realisiert sind und vielfältige Aufgaben innerhalb eines Fahrzeugs 50 wahrnehmen, wie zum Beispiel die Motor- und Bremssteuerung, die Steuerung von Assistenz-, Sicherheits- und Kommunikationssystemen und dergleichen mehr. Diese elektronischen Steuergeräte, üblicherweise ECU bzw. „Electronic Control Units" genannt, sind mit Mikroprozessoren, flüchtigen und nicht-flüch- tigen Speichern, Peripherie- und Bussystemen ausgestattet und werden von ei- ner Betriebssoftware oder Firmware betrieben, beispielsweise gemäß einer vor- gegebenen Softwarearchitektur, wie zum Beispiel dem AUTOSAR-Standard (Automotive Open System Architecture).
Wie jede Software müssen auch die Softwarekomponenten der Betriebssoftware einer Fahrzeugsteuerung aus Sicherheits- und Performancegründen regelmäßig aktualisiert werden. Die Funktionsweise und das Zusammenwirken der Hinter- grundeinrichtung 10 mit den Aktualisierungseinrichtungen 30 stellt sicher, dass die Aktualisierung der Software jedes einzelnen Fahrzeugs 50 nach individuell festgelegten Bedingungen durchgeführt wird, welche stabile Mobilfunkverbin- dungen 40 mit ausreichenden Übertragungsqualitäten bzw. ausreichenden Da- tenübertragungsraten zu den Fahrzeugen 50 sicherstellen, um die Software je- weils unterbrechungsfrei zu aktualisieren.
Das Zusammenwirken und die Datenkommunikation zwischen der Hinter- grundeinrichtung 10, einer Aktualisierxmgseinrichtung 30 sowie den verschie- denen Fahrzeugen 50 einer Fahrzeugflotte, deren Software zu aktualisieren ist, wird am Beispiel der Figuren 2a und 2b dargestellt, die jeweils bevorzugte Aus- führungsformen des erfindungsgemäßen Aktualisierungsverfahrens illustrie- ren.
Die Hintergrundeinrichtung 10 der Fig. 2a umfasst eine Steuereinheit 11, die die Hintergrundeinrichtung 10 steuert und insbesondere die Maschinenlern-Einheit 12 (ML-Einheit) ansteuert. Die ML-Einheit 12 ist realisiert als ein auf einem Pro- zessor (nicht dargestellt) der Hintergrundeinrichtung 10 ausführbares Software- programm und erzeugt, bearbeitet, verwaltet und benutzt zwei ausgewählte Datenstrukturen, nämlich einerseits das Maschinenlem-Modell 13 (ML-Modell) und andererseits den Aktualisierungsplan 14. Diese und andere Daten- und Kontrollstrukturen sind in einem geeigneten Speicher (nicht dargestellt) der Hintergrundeinrichtung 10 abgelegt, auf die die ML-Einheit 12 Zugriff hat.
Sobald eine neue, aktuelle Software vorliegt, die auf einigen oder allen Fahrzeu- gen 50 einer Fahrzeugflotte installiert werden soll, weist die Hintergrundein- richtung 10 die AktuaHsierungseinrichtung 30 in einem Schritt S1 an, alle Fahr- zeuge 50 zu identifizieren, deren derzeitige Software durch die aktuelle Soft- ware zu ersetzen ist. Dazu wird der Aktualisienmgseinrichtung 30 insbeson- dere die Versionsnummer(n) der zu aktualisierenden Software übergeben, ebenso wie weitere Identifikationskriterien, die die Identifikation aller betroffe- nen Fahrzeuge 50 erlauben, wie zum Beispiel Modellangaben und Modellnum- mern betreffend die elektronischen Steuereinheiten, Fahrzeugtypen, Zulas- sungsdaten oder dergleichen.
Eine Identifikationseinheit 31 der AktuaHsierungseinrichtung 30 stellt darauf- hin in einem Schritt S2 eine Liste L aller Fahrzeuge 50 zusammen, die den von der Hintergrundeinrichtung 10 übergebenen Identifikationskriterien entspre- chen. Dazu werden in einem Schritt S3 Informationen von den Fahrzeugen 50 über die Funkverbindungen 40 eingeholt, die zur Identifikation der betroffenen Fahrzeuge 50 gegebenenfalls benötigt werden, beispielsweise Betriebszustände, Fehlercodes oder dergleichen. In eine Schritt S4 wird die Liste L der identifizier- ten Fahrzeuge 50 an die Hintergrundeinrichtung 10 und dort an die ML-Einheit 12 übergeben.
Zusammen mit der Liste L übermittelt die Identifikationseinheit 31 auch Zeit- vorgaben Z an die Hintergrundeinrichtung 10, die ebenfalls auf den in Schritt S3 von den Fahrzeugen 50 empfangenen Informationen basieren können. Diese betreffen insbesondere Angaben hinsichtlich der Dauer einer betreffenden Ak- tualisierungskampagne bzw. des „Rollout" in Tagen oder Wochen, also das Zeitfenster in dem die Softwareaktualisierung aller identifizierten Fahrzeuge 50 abgeschlossen sein soll, und gegebenenfalls Angaben zur Dauer einer individu- ellen Aktualisierung auf einem konkreten Fahrzeug, die in der Regel abhängig ist von der konkreten technischen Infrastruktur des betreffenden Fahrzeugs 50.
Die Liste L mit den identifizierten Fahrzeugen 50 und die Zeitvorgaben Z, wer- den in Schritt S4 an die Maschinenlern-Einheit 12 übergeben und dort als Ein- gabewerte für eine Voraussage geeigneter Aktualisierungsbedingungen B für die identifizierten Fahrzeuge 50 basierend auf dem ML-Modell 13 verwendet, die schließlich zusammengefasst zu einem Aktualisierungsplan 14 die vollstän- dige Aktualisierungskampagne definieren, also die zeitliche/ örtliche Abfolge der Softwareaktualisierung aller in der Liste L genannten Fahrzeuge 50 inner- halb der Zeitvorgabe Z bezüglich der Dauer der Kampagne.
Der Schritt S8 gemäß Fig. 2a fasst die beiden Betriebsphasen der ML-Einheit 12 zusammen, nämHch erstens das Trainieren des ML-Modells 13 basierend unter anderem auf Sensordaten D, die die ML-Einheit 12 in Schritt S7 erhält, und zweitens die Vorhersage von Aktualisierungsbedingungen B und eines Aktuali- sierungsplans 14 basierend auf der Liste L und den Zeitvorgaben Z, die die ML- Einheit 12 in Schritt S4 erhält. Fig. 3 zeigt die beiden entsprechenden Module der ML-Einheit, nämlich das Trainingsmodul 12a, welches in Schritt S8a das ML-Modell 13 trainiert, und das Vorhersagemodul 12b, welches daraus in Schritt S8b Aktualisierungsbedingungen B ableitet.
Beim Trainieren wird das ML-Modell 13 auf die Vorhersage von Aktualisie- rungsbedingungen B vorbereitet, indem aus problemspezifischen, exemplari- schen Trainingsdaten gewissermaßen eine mehrdimensionale Karte des Mobil- funknetzes erzeugt wird, die mit bestimmten Orts- und Zeitauflösungen Vo- raussagen zu Übertragungsqualitäten Q von zukünftigen Funkverbindungen 40 kartiert bzw. modelliert. Als problemspezifische Trainingsdaten werden dazu in den Schritten S5 bis S 7 insbesondere solche Sensordaten D von den Fahrzeu- gen 50 erhoben und der ML-Einheit 12 zur Verfügung gestellt, die konkret ge- messene Übertragungsqualitäten Q in möglichst vielen Funkzellen des Mobil- funknetzes und zu möglichst vielen Zeitpunkten abgestuft betreffen.
Zu diesem Zweck sind die Fahrzeuge 50 mit geeigneten Sensoren und Messein- richtungen ausgestattet, so dass sie im Schritt S5 Messungen hinsichtlich der Übertragungsqualitäten Q innerhalb der von den Fahrzeugen 50 besuchten Funkzellen vornehmen und als Sensordaten D an ein Sensordatenmodul 32 der Aktualisierungseinrichtung 30 übermitteln. Dazu werden die Sensoren geeignet aktiviert und deaktiviert, um zuverlässig die gewünschten Sensordaten D zu er- mittein, auf deren Basis das ML-Modell 13 trainiert wird. Die Sensordaten be- treffen neben der jeweils aktuellen Übertragungsqualität Q, beispielsweise in Form einer gemessenen Datenübertragungsrate, auch Zeit-/ Datums- und Orts- daten, letztere zum Beispiel in Form der Fuhkzellen-IDs des vermessenen Funk- netzes. Ferner werden auch Bewegungsprofile der Fahrzeuge 50 protokolliert, zum Beispiel in Form von GPS-Daten, und dem Sensordatenmodul 32 bereitge- stellt.
Das Sensordatenmodul 32 bereitet die Sensordaten D der Fahrzeuge 50 geeignet auf und stellt sie schließlich in Schritt S7 der ML-Einheit 12 als Trainingsdaten für das ML-Modell 13 zur Verfügung. In dem Schritt S6 bereitet das Sensorda- tenmodul 32 insbesondere die Bewegungsprofile der Fahrzeuge 50 so auf, dass für jedes Fahrzeug 50 zeitlich und örtlich möglichst gut aufgelöste Bewegungs- daten T an die ML-Einheit übergeben werden, die insbesondere Zeiten und Wege regelmäßiger Fahrten mit dem betreffenden Fahrzeug 50 ausweisen, zum Beispiel regelmäßige Fahrten zu und von einer Arbeitsstätte. Die individuellen Bewegungsdaten T bilden auch das unterschiedliche Fahrverhalten an den ein- zelnen Wochentagen ab, zum Beispiel aufgrund von Teilzeitarbeit, Home- Office-Tagen und sonstigen wöchentlich wiederkehrenden Fahrten.
Gemäß Fig. 2a finden sowohl Training als auch Vorhersage im Rahmen des Schrittes S8 statt, eine zeitliche Reihenfolge oder Abhängigkeit zwischen Trai- ning und Vorhersage, und damit der Schritte S1 bis S4 einerseits und der Schritte S5 bis S7 andererseits, erfordert die Ausführungsform gemäß Fig. 2a nicht. Vielmehr können diese beiden Gruppen von Schritten nahezu beliebig verzahnt sein, zum Beispiel derart, dass Schritt S1 zwischen den Schritten S5 und S6 einsetzt oder dass Schritt S4 zeitgleich mit Schritt S7 stattfindet.
Dies bedeutet konzeptionell, dass das ML-Modell 13 gemäß der Ausführungs- form nach Fig. 2a kontinuierlich trainiert wird basierend auf immer neuen, ak- tuellen Sensordaten D, die im Rahmen des Schrittes S7 fortwährend eingeliefert werden. Das ML-ModeU 13 ist dadurch lernend ausgestaltet, denn es passt sich immer wieder aktuellen Veränderungen der Verbindungsqualitäten Q und/o- der Bewegungsdaten T der Fahrzeuge 50 an. Eine Vorhersage zur Bestimmung von Aktualisierungsbedingungen B kann gemäß Fig. 2a also jederzeit durchge- führt werden und findet immer basierend auf dem zum betreffenden Zeitpunkt aktuellen ML-Modell 13 statt. Die gleiche Vorhersageanfrage kann also zu ei- nem späteren Zeitpunkt aufgrund eines aktuelleren ML-Modells 13 andere Ak- tualisierungsbedingungen B ergeben. Gemäß Fig. 2b ist die ML-Einheit 12 wie in Fig. 3 gezeigt unterteilt in ein Trai- ningsmodul 12a und ein Vorhersagemodul 12b. Diese Ausführungsform geht davon aus, dass die Trainingsphase des ML-Modells 13 gemäß Schritt S8a zu- erst vollständig abgeschlossen wird, bevor die Vorhersagephase gemäß Schritt S8b einsetzt. Insofern werden bei der Ausführungsform gemäß Fig. 2b zunächst die Schritte S5 bis S8a ausgeführt und erst danach, wenn ein stabiles, trainiertes
ML-Modell 13 vorliegt, werden die AktuaHsierungsbedingungen B mit den Schritten S1 bis S4 und S8b bestimmt. Die Schritte S1 bis S4, S5 bis S7, S9 und S10 sind in Fig. 2a und Fig. 2b technisch identisch, lediglich die Reihenfolge der Ausführung unterscheidet sich in den beiden Ausführungsformen, ebenso wie die Differenzierung des Schritts S8 gemäß Fig. 2a in zwei separate Teilschritte
S8a und S8b gemäß Fig. 2b. Die Nummerierung der Schritte gibt also keine zwingend einzuhaltende Ausführungsreihenfolge vor. Die Reihenfolge der Ausführung der Schritte gemäß den Figuren 2a und 2b wird vielmehr lediglich bestimmt durch (daten-)technische Abhängigkeiten und den Zweck des erfin- dungsgemäßen Verfahrens.
Beim Training des ML-Modell 13 werden die von den Fahrzeugen 50 ermittel- ten und von dem Sensordatenmodul 32 aufbereiteten Sensordaten D und Bewe- gungsdaten T verwendet, tun den Funkzellen zu den betreffenden Zeiten Über- tragungsqualitäten Q zuzuordnen. Denjenigen Funkzellen bzw. denjenigen Zeitpunkten oder Zeitintervallen, für die keine Sensordaten D erhoben wurden, werden beim Training des ML-Modells 13 aus den vorhandenen Sensordaten D abgeleitete Übertragungsqualitäten Q zugeordnet, um auf diese Weise die Karte auch hinsichtlich solcher Funkzellen und Zeitintervalle zu vervollständigen, für die keine originären Sensordaten D vorliegen. Dies kann zum Beispiel auch dann Vorkommen, wenn für eine Funkzelle lediglich widersprüchliche Sensor- daten D vorliegen oder nicht genügend oder ausreichend zuverlässige Sensor- daten D erhoben werden konnten.
Die Ableitung von Übertragungsqualitäten Q im Rahmen des Trainings wird basierend auf Ähnlichkeitskriterien zwischen Netzwerkzellen und/ oder be- stimmten Charakteristika von Funkverbindungen durchgeführt. Die örtliche Nähe einer Funkzelle ohne brauchbare Sensordaten D zu einer Funkzelle mit brauchbaren Sensordaten D ist beispielsweise ein einfaches Ähnlichkeitskrite- rium. Weitere sinnvolle Ähnlichkeitskriterien können die zeitabhängige Ver- kehrsdichte oder die Anzahl von Netzteilnehmem sein, beides ableitbar aus den Bewegungsdaten T, oder auch die Bebauung und prinzipiell jedes geeig- nete Kriterium, das Einfluss auf die Datenrate einer Funkverbindung hat. Diese Ähnhchkeitskriterien erlauben es, ähnliche Funkzellen zu Clustern zu gruppie- ren, die beim Training Sensordaten D und Übertragungsqualitäten Q miteinan- der teilen.
Mit dem trainierten ML-Modell 13 werden dann geeignete Aktualisierungsbe- dingungen B für die identifizierten Fahrzeuge 50 vorher gesagt und zu einem Aktualisierungsplan 14 zusammengefasst, der es erlaubt, die Software mög- lichst vieler Fahrzeuge 50 unterbrechungsfrei und innerhalb der vorgegebenen Zeitdauer einer Aktualisierungskampagne zu installieren.
Die Aktualisierungsbedingungen B werden basierend auf den Bewegungsdaten T der betroffenen Fahrzeuge ermittelt. Sie definieren entlang der protokollierten Fahrtwege der Fahrzeuge 50 eine oder mehrere mögliche Funkverbindungen 40, über die die Software aktualisiert werden kann. Die Aktualisierungsbedin- gungen B geben bestimmte Standorte, zum Beispiel in Form von regelmäßig von dem betreffenden Fahrzeug 50 besuchten Funkzellen, und entsprechende Zeiten vor, zu denen das ML-Modell 13 eine Funkverbindung 40 mit einer aus- reichenden Übertragungsqualität voraussagt, um die Software dieses Fahrzeugs 50 unterbrechungsfrei zu aktualisieren. Diese Voraussage trifft das ML-Modell 13 letztlich basierend auf den Sensordaten D und den daraus im Rahmen des Trainings abgeleiteten Übertragungsqualitäten Q.
Die Bewegungsdaten T bilden bei der Vorhersage von geeigneten Aktualisie- rungsbedingungen B wichtige Nebenbedingungen, denn sie schränken die po- tentiell zur Softwareaktualisierung einsetzbaren Funkverbindungen 40 ein auf die sinnvollen Funkverbindungen 40, die ein Fahrzeug 50 im Rahmen seiner Nutzung überhaupt aufbauen kann. Unter diesen sinnvollen Funkverbindun- gen 40, die das Fahrzeug 50 auf seinen regelmäßigen Fahrten aufbauen kann, ermittelt das ML-Modell 13 diejenigen, die voraussichtlich ausreichende Über- tragungsqualitäten Q bieten, um die unterbrechungsfreie Aktualisierung der Software zu gewährleisten.
Das ML-Modell 13 sagt für alle Fahrzeuge 50, die in der Liste L verzeichnet sind, Aktualisierungsbedingungen B voraus, die voraussichtlich eine unterbre- chungsfr eie Softwareaktualisierung erlauben. Dabei werden einerseits Konflikte zwischen den Aktualisierungsbedingungen B verschiedener Fahrzeuge 50 ver- mieden und andererseits eine globale Kosten- oder Verlustfunktion („loss func- tion") optimiert bzw. minimiert, die genau dann optimal/minimal wird, wenn für alle in der Liste L verzeichneten Fahrzeuge 50 Aktualisierungsbedingungen B gefunden werden können, die mit hoher Wahrscheinlichkeit eine unterbre- chungsfreie Softwareaktualisierung gewährleisten. Insgesamt minimiert der Aktualisierungsplan 14 die Gesamtzeit der Softwareaktualisierung aller Fahr- zeuge 50, da das ML-Modell 13 Aktualisierungsbedingungen B vorgibt, die nicht nur für einzelne Fahrzeuge 50 optimal sind, sondern für die Aktualisie- rungskampagne insgesamt.
In Schritt S9 wird der Aktualisierungsplan 14 schließlich an die Aktualisie- rungseinrichtung 30 bzw. deren Aktualisierungsmodul 33 übergeben, so dass in Schritt S10 die Aktualisierungskampagne vorbereitet wird und in Schritt Sil Anweisungen über die Funkverbindungen 40 an die betreffenden Fahrzeuge 50 zum Aktualisieren von deren Software ergehen.
Die Fig. 3 illustriert die ML-Einheit 12 unterteilt in deren beide bereits ange- sprochenen Module, nämlich das Trainingsmodul 12a und das Vorhersagemo- dul 12b. Entsprechend den bisherigen Erläuterungen ist der Trainingsschritt S8a, durchgeführt durch das Trainingsmodul 12a, prinzipiell unabhängig von dem Vorhersageschritt S8b, durchgeführt von dem Modul 12b. Entsprechend sieht die Ausführungsform, gemäß Fig. 2a vor, dass beide Module in dem Sinne parallel genutzt werden, dass jederzeit eine Vorhersage (Schritt S8b) basierend auf dem aktuellen Zustand des ML-Modells 13 durchgeführt wird, während das „lernende" ML-Modell 13 kontinuierlich mit immer neuen Sensordaten D trainiert wird (Schritt S8a). Die Ausführungsform gemäß Fig. 2b sieht demge- genüber kein in diesem Sinne „lernendes" ML-Modell 13 vor, denn das ML- Modell 13 wird dort im Hinblick auf eine erforderliche Aktualisierungskam- pagne eine bestimmten Zeit lang trainiert und wird dann, austrainiert, für die Bestimmung des Aktualisierungsplans 14 verwendet, ohne dass es Trends und Veränderungen lernend berücksichtigen würde.
Gemäß Fig. 3 erhält das Trainingsmodul 12a im Schritt S7 Sensordaten D sowie Bewegungsdaten T, aus denen Übertragungsqualitäten Q mit möglichst hoher zeitlicher und örtlicher Auflösung abgeleitet werden. Das ML-Modell 13 model- liert also in dem Trainingsschritt S8a die oben angesprochene Karte der Über- tragungsqualitäten Q. Der Vorhersageschritt S8b wird dann durchgeführt mit dem hinreichend trainierten ML-Modell 13, den von dem Trainingsmodul 12a an das Vorhersagemodul 12b übergebenen Bewegungsdaten T und der in Schritt S4 bereitgestellten Liste L der identifizierten Fahrzeuge 50 sowie den Zeitvorgaben Z. Durch den Schritt S8b werden schließlich aufgrund von Vo- raussagen hinsichtlich der Übertragungsqualitäten Q Aktualisierungsbedingun- gen B für alle Fahrzeuge 50 der Liste L bestimmt und daraus ein Aktualisie- rungsplan 14 gebildet, der festlegt, wann und auf welcher konkreten Fahrt die Software eines jeden Fahrzeugs 50 zu aktualisieren ist.
Fig. 4 illustriert schließlich die Umsetzung des Aktualisierungsplans 14 und der zugehörigen Aktualisierungsbedingungen B. In Schritt S9 wird der Aktualisie- rungsplan 14 an ein Aktualisierungsmodul 33 der Aktualisierungseinheit 30 übergeben, die dann die Aktualisierungskampagne startet und überwacht.
Dazu werden den identifizierten Fahrzeugen 50, bzw. den entsprechenden Steuereinrichtungen CNTL dieser Fahrzeuge 50, in Schritt Sil die diese Fahr- zeuge 50 betreffenden Aktualisierungsbedingungen B übergeben. Die Steuer- einrichtungen CNTL der Fahrzeuge 50 überwachen also selbständig das Vorlie- gen der jeweiligen Aktualisierungsbedingungen B. Das Aktualisieren der Soft- ware SW wird von der Steuereinrichtung CNTL dann in Schritt S12 durchge- führt, wenn die Aktualisierungsbedingungen B zutreffen, wenn sich das Fahr- zeug 50 also innerhalb des vorbestimmten Zeitintervalls in der/ den vorbe- stimmten Funkzelle/ n befindet bzw. sie durchfährt. Dazu wird in Schritt S13 die aktuelle Software SW* über die Funkverbindung 40 heruntergeladen, in dem Speicher 51 abgelegt und installiert.
Die aktuelle Software SW* liegt hierbei auf einem oder mehreren geeigneten Download-Servem zum Herunterladen durch die Fahrzeuge 50 bereit. Der Download-Server kann als Bestandteil der Aktualisienmgseinrichtung 30 oder als separate technische Entität ausgestaltet sein. Die Fig. 5 zeigt eine dritte bevorzugte Ausführungsform des erfindungsgemä- ßen Aktualisierungsverfahrens, welche auf der zweiten bevorzugten Ausfüh- rungsform gemäß Fig. 2b basiert. Die Fig. 5 unterscheidet sich von der Fig. 2b lediglich betreffend die Schritte S5 bis S8a der Fig. 2b, die in Fig. 5 durch die Schritte S5, S6 sowie S7a bis S7d ersetzt werden. Die Schritte S5, S6 sowie S7a bis S7d gemäß Fig. 5 können ebenso gut auch in der Ausführungsform gemäß Fig. 2a ergänzt werden.
Gemäß Fig. 5 umfasst die Hintergrundeinrichtung 10 statt dem Trainingsmodul 12a gemäß Fig. 2b ein Synthesemodul 12c, welches ein flottenübergreifendes ML-Modell 13a in der nachfolgend beschriebenen Weise synthetisiert. Die Ak- tuahsierungseinrichtung 30 umfasst statt dem Sensordatenmodul 32 gemäß Fig. 2b ein Weiterleitungsmodul 34, das die Datenkommunikation zwischen der Hintergrundeinrichtung 10 und den Fahrzeugen 50 bidirektional sicherstellt. Die Fahrzeuge 50 umfassen jeweils neben einem fahrzeugindividuellen ML- Modell 13b ein eigenes Sensordatenmodul 53, welches dem betreffenden Fahr- zeug 50 die Funktionalität des Sensordatenmoduls 32 der Fig. 2a bereitstellt, so- wie ein Trainings- und Synchronisationsmodul 52, welches einerseits die Funk- tion des Trainingsmoduls 12a gemäß Fig. 2b bereitstellt und andererseits das betreffende fahrzeugindividuelle ML-Modell 13b aktualisiert bzw. mit dem flot- tenübergreifenden ML-Modell 13a synchronisiert. Konzeptionell werden bei dieser Ausführungsform also die zentralen Funktionen des Trainingsmoduls 12a und des Sensordatenmoduls 32 gemäß Fig. 2b dezentralisiert und in jedes Fahrzeug 50 der Fahrzeugflotte integriert.
Dadurch wird sichergestellt, dass schützenswerte, personenbezogene Trai- ningsdaten, wie zum Beispiel die Sensordaten D und/ oder die Bewegungsda- ten T in den jeweiligen Fahrzeugen 50 verbleiben und insofern datenschutzkon- form vor Ausspähen und Missbrauch geschützt sind. Die Schritte S1 bis S4 und S9 bis Sil gemäß Fig. 5 sind identisch mit den ent- sprechend bezifferten Schritten der Figuren 2a und 2b. Ebenso sind ist der Schritt S8b in den Ausführungsformen gemäß den Figuren 2b und 5 identisch. Im Schritt S5 gemäß Fig. 5 werden in einem Fahrzeug 50 fahrzeugindividuelle
Messungen hinsichtlich der Übertragungsqualitäten Q innerhalb der von den betreffenden Fahrzeugen 50 besuchten Funkzellen vorgenommen und dem Sensordatenmodul 53 als Sensordaten D des betreffenden Fahrzeugs 50 bereit- gestellt. Das Sensordatenmodul 53 bereitet analog zur Funktion des Sensorda- tenmoduls 32 gemäß Fig. 2a und 2b die Sensordaten D und die individuellen
Bewegungsprofile des Fahrzeugs 50 geeignet zu möglichst gut aufgelösten Be- wegungsdaten T auf und stellt in Schritt S6 diese gemeinsam mit den Sensorda- ten D dem Trainings- und Synchronisationsmodul 52 des Fahrzeugs 50 zur Ver- fügung. In Schritt S7a trainiert das Trainings- und Synchronisationsmodul 52 das fahrzeugindividuelle ML-Modell 13b des Fahrzeugs 50 mit den fahrzeugin- dividuellen Sensor- und Bewegungsdaten D, T analog zur Funktion des Trai- ningsmoduls 12c gemäß Fig. 2b.
Die Schritte S7b bis S7e betreffen den Prozess des Synthetisierens (S7b, S7c) des flottenübergreifenden ML-Modells 13a, also dessen Zusammenführen aus den fahrzeugindividuellen ML-Modellen 13b, und des Synchronisierens (S7d, S7e) der jeweiligen fahrzeugindividuellen ML-Modelle 13b, also deren Aktualisie- rung basierend auf dem synthetisierten flottenübergreifenden ML-Modell 13a. Konzeptionell werden mittels der Schritte S7b bis S7e jedem einzelnen fahr- zeugindividuellen ML-Modellen 13b die individuellen Trainingsfortschritte al- ler fahrzeugindividuellen ML-Modellen 13b gebündelt zur Verfügung gestellt, um dadurch die Trainingsqualität insgesamt zu verbessern. Zu Beginn des Schrittes S7b liegt auf einem Fahrzeug 50 ein stabiles, trainiertes, fahrzeugindividuelles ML-Modell 13b vor, das Vorhersagen hinsichtlich der Übertragungsqualitäten Qb von Funkverbindungen basierend auf den Sensor- daten D des jeweiligen Fahrzeugs erlaubt. Initial können die so beurteilten Funkverbindungen natürlich nur aus Funkzellen stammen, die das betreffende Fahrzeug 50 tatsächlich besucht hat, für die das Fahrzeug also Sensordaten D bzw. Bewegungsdaten T ermittelt hat. Durch die regelmäßige Wiederholung von Synthese (Schritte S7b, S7c) und Synchronisation (Schritte S7d, S7e) werden jedem fahrzeugindividuellen ML-Modell 13b schrittweise immer mehr Informa- tionen zu Funkverbindungen in Funkzellen bereitgestellt, die andere Fahrzeuge 50 der Fahrzeugflotte besucht haben, so dass das betreffenden fahrzeugindivi- duelle ML-Modell 13b iterativ eine immer bessere Grundlage für die Vorher- sage der Übertragungsqualitäten Qb von Funkverbindungen in den besuchten Funkzellen bildet, da das betreffenden fahrzeugindividuelle ML-Modell 13b immer mehr Kontextwissen über andere Bereiche des Funknetzwerks erwirbt. Gemäß dem Schritt S7b schicken alle Fahrzeuge 50 der Fahrzeugflotte fahrzeug- individuelle Modelldaten Mb an das Weiterleitungsmodul 34 der Aktualisie- rungseinrichtung 30, die die Vielzahl von Modelldaten Mb fahrzeugweise oder bereits gebündelt an das Synthesemodul 12c der Hintergnmdeinrichtung 10 weiterleitet.
Als fahrzeugindividuelle Modelldaten Mb eines jeden fahrzeugindividuellen ML-Modells 13b erzeugt das jeweilige Trainings- und Synchronisationsmodul 52 inkrementelle Modelldaten Mb, die die Differenz zwischen dem Trainings- zustand des betreffenden fahrzeugindividuellen ML-Modells 13b zum aktuel- len Zeitpunkt (also zum Zeitpunkt des Ausführend des Schrittes S7b) und dem
Trainingszustand des fahrzeugindividuellen ML-Modells 13b zum Zeitpunkt nach dessen letzter Aktualisierung (also zum Zeitpunkt nach dem letztmaligen Ausführen des Schrittes S7e und vor dem letztmaligen Training in Schritt S7a) repräsentieren. Dieser fahrzeugindividuelle Trainingsfortschritt innerhalb des Zeitraums zwischen den beiden benannten Zeitpunkten wird mit den nachfol- genden Schritten S7c bis S7e an die fahrzeugindividuellen ML-Modelle 13b aller anderen Fahrzeuge 50 der Fahrzeugflotte weitergeben.
Die inkrementellen fahrzeugindividuellen Modelldaten Mb einzelner oder aller Fahrzeuge 50 werden im Schritt S7c von dem Synthesemodul 12c zusammenge- führt und zu einem aktuellen flottenübergreifendes ML-Modell 13a syntheti- siert, welches dann die aktuellen Trainingsergebnisse sämtlicher fahrzeugindi- viduellen ML-Modelle 13b in sich trägt. Nach dem Schritt S7c repräsentiert das flottenübergreifende ML-Modell 13a, ebenso wie die ML-Modelle 13 gemäß den Ausführungsformen nach Fig. 2a und 2b, ein stabiles, trainiertes, flottenüber- greifendes ML-Modell, welches Grundlage für die anschließende Vorhersage- phase gemäß dem Schritt S8b und die Ableitung von Aktualisierungsbedingun- gen B ist.
Der Unterschied zwischen der Ausführungsform gemäß Fig. 5 und den Aus- führungsformen gemäß den Figuren 2a und 2b liegt also unter anderem darin, dass das flottenübergreifende ML-Modell 13a und die Übertragungsqualitäten Qa zwar dieselbe Trainingsqualität und ein vergleichbares Vorhersagepotential besitzen wie das ML-Modell 13 gemäß den Figuren 2a und 2b, dass das flotten- übergreifende ML-Modell 13a jedoch nicht durch eine eigene Trainingsphase zustande kommt, welcher notwendig die sensiblen, personenbezogenen Sensor- daten D und Bewegungsdaten T zugrunde Hegen müssten, sondern durch den Syntheseschritt S7c, in dem ledighch hinsichtlich etwaiger Datenschutzbestim- mungen unproblematische, inkrementeile Modelldaten Mb zusammengeführt werden. Das Training findet bei der Ausführungsform gemäß Fig. 5 in den lo- kalen Schritten S7a auf den einzelnen Fahrzeugen 50 statt, so dass die jeweih- gen Sensordaten diese Fahrzeuge 50 nicht verlassen.
Die anschHeßenden Schritte S7d und S7e betreffen sie Synchronisation bzw. Ak- tuaHsierung der einzelnen fahrzeugindividuellen ML-Modelle 13b basierend auf flottenübergreifenden, inkrementellen Modelldaten Ma, welche im Schrit S7d aus dem flotenübergreifenden ML-Modell 13a extrahiert werden.
Die inkrementellen Modelldaten Ma repräsentieren die Differenz zwischen dem Trainingszustand des flotenübergreifenden ML-Modells 13a zum aktuellen
Zeitpunkt (also zum Zeitpunkt des Ausführend des Schrites S7d) und dem Trainingszustand des flotenübergreifenden ML-Modells 13a zum Zeitpunkt nach dessen vorletzter Synthese (also zum Zeitpunkt nach dem vorletztmaligen Ausführen des Schrites S7c).
Nachdem die flotenübergreifenden Modelldaten Ma im Schrit S7d von dem Synthesemodul 12c über das Weiterleitungsmodul 34 der Aktualisierungsein- richtung 30 an die jeweiligen Trainings- und Synchronisationsmodule 52 der einzelnen Fahrzeuge 50 geschickt wurden, wird auf all diesen Fahrzeugen 50 je- weils in einem Schrit S7e das betreffende fahrzeugindividuelle ML-Modell 13b mit den flottenübergreifenden Modelldaten Ma aktualisiert. Danach sind sämt- liche fahrzeugindividuellen ML-Modelle 13b synchronisiert und repräsentieren zu diesem Zeitpunkt den Trainingszustand des flotenübergreifenden ML- Modells 13a, bevor die einzelnen fahrzeugindividuellen ML-Modelle 13b im Rahmen des jeweiligen fahrzeugindividuellen Trainings wieder divergieren, in- dem sie basierend auf den weiterhin fahrzeugindividuell erhobenen Sensorda- ten D in einem erneuten Schrit S7a weitertrainiert werden.
Dieser Prozess bestehend aus der Synthese des flotenübergreifenden ML- Modells 13a durch die Schrite S7b und S7c und der Synchronisation der fahr- zeugindividuellen ML-Modelle 13b durch die Schritte S7d und S7e kann regel- mäßig wiederholt werden, beispielsweise nachdem vorgegebene Zeitintervalle verstrichen sind. Ebenso kann der Prozess der Schritte S7a bis S7e auch durch bestimmte Ereignisse veranlasste werden, beispielsweise wenn ein ausreichen- der Trainingsfortschrit bei einzelnen, einer bestimmten Anzahl oder allen fahr- zeugindividuellen ML-Modellen 13b erzielt wurde oder wenn ausreichende neue Sensordaten D erhoben wurden, die eine erneute Synthese/ Synchronisa- tion nötig werden lassen.
Ferner können die fahrzeugindividuellen Modelldaten Mb aus den einzelnen fahrzeugindividuellen ML-Modellen 13b synchron erzeugt und nahezu zeit- gleich dem Weiterleitungsmodul 34 bereitgestellt werden. Bereits das Weiterlei- tungsmodul 34 kann die fahrzeugindividuellen Modelldaten Mb der Fahrzeuge 50 bündeln und an das Synthesemodul 12c als ein Datensatz weiterleiten. Die- sen Datensatz würde dann das Synthesemodul 12c mit den flottenübergreifen- den ML-Modell 13a kombinieren und dadurch ein neues flottenübergreifenden ML-Modell 13a bilden, dass die Trainingsfortschritte aller fahrzeugindividuel- len ML-Modelle in sich vereint.
Alternativ können die Fahrzeuge 50 jeweils ihre fahrzeugindividuellen Modell- daten Mb imabhängig voneinander an das Weiterleitungsmodul 34 schicken und von diesem zwischengespeichert und erst dann gebündelt an das Synthese- modul 12c weitergeleitet werden, wenn ein ausreichend großer Datensatz aus fahrzeugindividuellen Modelldaten Mb verschiedener Fahrzeuge 50 vorliegt.
Ein praktisches und nicht beschränkendes Beispiel eines ML-Modells 13, so wie es im Zusammenhang mit den Figuren 2 bis 5 beschrieben ist, besitzt Ausgangs- bzw. Ergebnisklassen (Output) für unterbrechungsfreie Mobilfunkverbindung verschiedener Dauer:
- Verbindungen, die 0 bis 5 Minuten unterbrechungsfrei waren;
- Verbindungen, die 5 bis 10 Minuten unterbrechungsfrei waren;
- Verbindungen, die 10 bis 20 Minuten unterbrechungsfrei waren;
- Verbindungen, die 20 bis 30 Minuten unterbrechungsfrei waren;
- Verbindungen, die 30 bis 45 Minuten unterbrechungsfrei waren;
- Verbindungen, die 45 bis 60 Minuten unterbrechungsfrei waren; und
- Verbindungen, mehr als 60 Minuten unterbrechungsfrei waren. Als Eingangskategorien (Input) des ML-Modells 13 werden relevante Zeitanga- ben verwendet, wie etwa
- Kategorie „Tageszeit" mit sechs Merkmalen, nämlich „früh morgens", „morgendlicher Berufsverkehr", „mittags", „abendlicher Berufsverkehr", „abends", „nachts";
- Kategorie „Wochentag" mit sieben Merkmalen entsprechend den einzel- nen Wochentagen;
- Kategorie „Feiertag" als ein binäres Merkmal mit den Merkmalswerten „ja" und „nein";
- Kategorie „Urlaubszeit" als ein binäres Merkmal mit den Merkmalswer- ten „ja" und „nein"; sowie Eingangskategorien mit kontinuierlichen, numerischen Werten:
- Kategorie "Signalstärke" mit der mittleren Signalstärke der vergangenen 5 Minuten minus einem Offset-Wert dividiert durch die Standardabwei- chung;
- Kategorie „Fahrtzeit" mit einer numerischen Angabe der verstrichenen Zeit seit dem Beginn der Fahrt in Stunden; oder topologische Angaben:
- Kategorie „Standort" mit einer Identifikation der Mobilfunkzelle, in der sich das Fahrzeug 50 aktuell oder zu Beginn der Fahrt befindet;
- Kategorie „Fahrtrichtung" mit der Angabe einer Folge von zwei benach- barten Mobilfunkzellen, die die aktuelle Fahrtrichtung charakterisieren. Das ML-Modell 13 umfasst einen Klassifikator, der auf Entscheidungsbäumen basiert, wie etwa einen Random-Forest-Klassifikator oder einen Extreme-Gra- dient-Boosting-Klassifikator. Derartige Klassifikatoren können selbst mit den beschränkten Ressourcen in einem Fahrzeug 50 und bei kleinen Trainingsda- tensätzen effizient mit der Hardware eines Fahrzeugs 50 betrieben werden, denn sie können schnell trainiert werden und sind leicht parallelisierbar.
Die konkrete Definition der Ausgangsklassen und der spezifischen Merkmale wird in Abhängigkeit von bestimmten Vorbedingungen ausgewählt bzw. kon- figuriert, zum Beispiel abhängig von der Region, in der sich die betreffenden Fahrzeuge 50 bewegen, oder von saisonalen oder kulturellen Umständen oder dergleichen. Abhängig von solchen Vorbedingungen werden die Fahrzeuge 50 mit vortrainierten, ML-Modellen 13 (oder flottenübergreifenden ML-Modellen 13a) ausgestattet, die dann in den betreffenden Fahrzeugen 50 individuell wei- ter trainiert werden und dann fahrzeugindividuelle ML-Modelle 13b bilden.
Verdeutlicht anhand der beiden Kategorien „Standort" und „Fahrtrichtung" umfasst das vortrainierte ML-Modell 13 (oder 13a) Zuordnungen der Auftritts- wahrscheinlichkeiten der Ausgangsklassen zu den verschiedenen Standorten und Fahrtrichtungen. Einer konkreten Kombination aus Standort und Fahrt- richtung ist etwa der Vektor (0,06; 0,13; 0,18; 0,22; 0,26; 0,12; 0,03) zugewiesen, was bedeutet, dass in der betreffenden Situation statistisch 6% aller Mobil- funkverbindungen zwischen 0 und 5 Minuten stabil bzw. unterbrechungsfrei waren, 13% aller Mobilfunkverbindungen zwischen 5 und 10 Minuten stabil bzw. unterbrechungsfrei waren, etc.
Diese statistischen Werte, die in das vortrainierte ML-Modell 13 (oder 13a) ein- gehen und dessen Trainingsdaten repräsentieren, werden einer Karte entnom- men, die historische Werte umfasst, welche in der Vergangenheit von Fahrzeu- gen 50 gesammelt wurde und welche kontinuierlich von den aktuell beteiligten Fahrzeugen 50 aktualisiert werden. Sind für einzelne Situationen bzw. Karten- elemente keine zuverlässigen historischen Werte verfügbar, werden fahrzeug- spezifische Standardwerte eingesetzt, zum Beispiel in Form des Vektors (0,1; 0,1; 0,2; 0,2; 0,25; 0,1; 0,05).

Claims

Patentansprüche
1. Verfahren zum Aktualisieren einer Software in Fahrzeugen (50) einer Fahrzeugflotte, umfassend die Schritte:
Identifizieren (S2) zumindest eines Fahrzeugs (50) der Fahrzeugflotte, dessen Software (SW) zu aktualisieren ist;
Aktualisieren (S12, S13) der Software (SW) des zumindest einen identifi- zierten Fahrzeugs (50) über eine Funkverbindung (40) gemäß vorgegebe- nen Aktualisienmgsbedingungen (B); dadurch gekennzeichnet, dass die Aktualisierungsbedingungen (B) derart be- stimmt werden (S8; S8b), dass ein Maschinenlern-Modell (13; 13a, 13b), welches Übertragungsqualitäten (Q; Qa, Qb) von Funkverbindungen (40) modelliert, für die Funkverbindung (40) eine ausreichende Übertragungsqualität (Q; Qa, Qb) voraussagt, um die Software des zumindest einen Fahrzeugs (50) zu aktualisie- ren (S12, S13).
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Maschi- nenlern-Modell (13; 13a, 13b) Datenraten von Funkverbindungen (40) innerhalb eines Funknetzwerks modelliert und für die Funkverbindung (40) als Übertra- gungsqualität (Q; Qa, Qb) eine Datenrate voraussagt, die ausreichend hoch und/ oder ausreichend stabil ist, um die Software (SW) des zumindest einen Fahrzeugs (50) zu aktualisieren (S12, S13).
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass Ma- schinenlern-Modell (13; 13a, 13b) für die Funkverbindung (40) eine Übertra- gungsqualität (Q; Qa, Qb) voraussagt, die es erlaubt, die Software (SW) des zu- mindest einen Fahrzeugs (50) unterbrechungsfrei und/oder innerhalb einer vorgegebenen Aktualisierungsdauer zu aktualisieren (S12, S13).
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass beim Bestimmen der Aktualisierungsbedingungen (B) zumindest eine Zeitbedingung und/ oder zumindest einer Ortsbedingung ermittelt werden (S8; S8b), wobei die Zeitbedingung ein Zeitintervall betrifft, innerhalb dessen die Software (SW) des zumindest einen Fahrzeugs (50) aktualisiert werden soll, und die Ortsbedingung einen Standort betrifft, an dem sich das zumindest eine Fahrzeug (50) zum Aktualisieren (S12, S13) der Software (SW) befinden muss.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Maschinenlern-Modell (13; 13a, 13b) basierend auf Sensordaten (D) trainiert wird (S8; S8a; S7a, S7c), die von dem zumindest einen Fahrzeug (50) und/ oder von weiteren Fahrzeugen (50) der Fahrzeugflotte erhoben werden (S5, S6) und Übertragungsqualitäten (Q; 13a, 13b) von Funkverbindungen (40) innerhalb von Funkzellen und/ oder Anzahlen von Funkverbindungen (40) in- nerhalb von Funkzellen und/oder Bewegungsdaten (T) entlang besuchter Funkzellen sowie zugehörige Zeitdaten betreffen.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Maschi- nenlern-Modell (13; 13a, 13b) beim Trainieren aus den erhobenen Sensordaten (D) Übertragungsqualitäten (Q; Qa, Qb) von Funkverbindungen (40) innerhalb von Funkzellen und/ oder für Zeitintervalle innerhalb von Funkzellen ableitet (S8; S8a; S7a, S7c), für welche keine geeigneten Sensordaten (D) vorliegen, vor- zugsweise basierend auf Sensordaten (D), die in Funkzellen und/ oder für Zeit- intervalle innerhalb von Funkzellen mit ähnlicher Charakteristik erhoben wur- den (S5, S6).
7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass aus den Sensordaten (D) und/oder den Bewegungsdaten (T) zukünftige Fahrtwege des zumindest einen Fahrzeugs (50) und/oder der weiteren Fahrzeuge (50) ab- geleitet werden (S6).
8. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass das Maschinenlern-Modell (13) die Aktualisierungsbedingungen (B) derart bestimmt (S8; S8b), dass sie auf die Bewegungsdaten (T) oder auf zukünftige Fahrtwege des zumindest einen Fahrzeugs (50) abgestimmt sind.
9. Verfahren nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, dass eine Vielzahl von Fahrzeugen (50) identifiziert wird (S2), deren Software jeweils zu aktualisieren ist, und ein Aktualisierungsplan (14) erstellt wird (S8; S8b), der Aktualisierungsbedingungen (B) für jedes der Vielzahl von Fahrzeu- gen (50) umfasst, wobei das Maschinenlern-Modell (13; 13a, 13b) die Aktualisie- rungsbedingungen (B) derart bestimmt (S8; S8b), dass sie für jedes der Vielzahl von Fahrzeugen (50) eine ausreichende Übertragungsqualität (Q) Voraussagen, um die Software zu aktualisieren (S12, S13).
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass auf dem zumindest einen Fahrzeug (50) und/oder auf weiteren Fahrzeu- gen (50) der Fahrzeugflotte fahrzeugindividuelle Maschinenlern-Modelle (13b) betrieben und basierend auf den Sensordaten (D) trainiert werden (S8; S8a;
S7a), wobei die fahrzeugindividuellen Maschinenlern-Modelle (13b) auf einer Hmtergrundeinrichtung (10) zu einem flottenübergreifenden Maschinenlern- Modell (13a) als dem Maschinenlern-Modell zusammengeführt werden (S7c), und die fahrzeugindividuellen Maschinenlern-Modelle (13b) basierend auf dem flottenübergreifenden Maschinenlern-Modell (13a) aktualisiert werden (S7e).
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass aus den fahrzeugindividuellen Maschinenlern-Modellen (13b) jeweils fahrzeugindividuelle Modelldaten (Mb) abgeleitet werden (S7b), die jeweils eine Differenz zwischen einem aktuellen Zustand des jeweiligen fahrzeugindi- viduellen Maschinenlern-Modelles (13b) und dem Zustand nach der letzten Ak- tualisierung dieses fahrzeugindividuellen Maschinenlem-Modelles (13b) reprä- sentieren, und dass die fahrzeugindividuellen Modelldaten (13b) zu dem flot- tenübergreifenden Maschinenlern-Modell (13a) zusammengeführt werden (S7c), und dass aus dem flottenübergreifenden Maschinenlern-Modell (13a) flottenüber- greifende Modelldaten (Ma) abgeleitet werden (S7d), die eine Differenz zwi- schen einem aktuellen Zustand des flottenübergreifenden Maschinenlem-Mo- dells (13a) und dem Zustand nach dem letzten Zusammenführen des flotten- übergreifenden Maschinenlern-Modells (13a) repräsentieren, und dass die fahr- zeugindividuellen Maschinenlern-Modelle (13a) jeweils mit den flottenüber- greifenden Modelldaten (Ma) aktualisiert werden (S7e).
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Software eines identifizierten Fahrzeugs (50) automatisch aktualisiert wird (S12, S13), sobald die für dieses Fahrzeug (50) bestimmten Aktualisie- rungsbedingungen (B) zutreffen.
13. Aktualisierungssystem zum Aktualisieren einer Software (SW) in Fahr- zeugen (50) einer Fahrzeugflotte, umfassend zumindest eine Aktualisierungs- einrichtung (30), die eingerichtet ist, zumindest ein Fahrzeug (50) der Fahrzeug- flotte zu identifizieren, dessen Software (SW) zu aktualisieren ist, und die Soft- ware (SW) des zumindest einen identifizierten Fahrzeugs (50) über eine Funk- verbindung (40) gemäß vorgegebenen Aktualisierungsbedingungen (B) zu ak- tualisieren, dadurch gekennzeichnet, dass das Aktualisierungssystem ferner eine Hintergrundeinrichtung (10) mit einem Maschinenlern-Modell (13; 13a) umfasst, welches Übertragungsqualitäten (Q) von Funkverbindungen (40) mo- delliert, wobei die Hintergrundeinrichtung (10) eingerichtet ist, die Aktualisie- rungsbedingungen (B) derart zu bestimmen, dass das Maschinenlern-Modell (13; 13a) für die Funkverbindung (40) eine ausreichende Übertragungsqualität (Q) voraussagt, tun die Software (SW) des zumindest einen Fahrzeugs (50) zu aktualisieren.
14. Aktualisierungssystem nach Anspruch 13, wobei die Hintergrundein- richtung (10) und die zumindest eine Aktualisienmgseinrichtung (30) derart eingerichtet sind, dass ein Verfahren nach einem der Ansprüche 1 bis 10 ausge- führt wird.
15. Hintergrundeinrichtung (10), eingerichtet zum Zusammenwirken mit zumindest einer Aktualisierungseinrichtung (30) in einem Aktualisierungssys- tem nach Anspruch 14 oder 15 zum Aktualisieren einer Software (SW) in Fahr- zeugen (50) einer Fahrzeugflotte, durch gekennzeichnet, dass die Hintergrund- einrichtung (10) ein Maschinenlem-Modell (13; 13a) umfasst, welches Übertra- gungsqualitäten (Q) von Funkverbindungen (40) modelliert und eingerichtet ist, Aktualisierungsbedingungen (14), gemäß denen die Software (SW) zumin- dest eines Fahrzeugs (50) der Fahrzeugflotte über eine Funkverbindung (40) zu aktualisieren ist, derart zu bestimmen, dass das Maschinenlem-Modell (13; 13a) für die Funkverbindung (40) eine ausreichende Übertragungsqualität (Q) vo- raussagt, um die Software (SW) des zumindest einen Fahrzeugs (50) zu aktuali- sieren.
16. Flintergrundeinrichtung (10) nach Anspruch 15, wobei die Hintergrund- einrichtung (10) eingerichtet ist, mit der zumindest einen Aktualisierungsein- richtung (30) derart zusammenzuwirken, dass ein Verfahren nach einem der Ansprüche 1 bis 12 ausgeführt wird.
17. AktuaÜsierungseinrichtung (30) eingerichtet zum Zusammenwirken mit einer Hintergrundeinrichtung (10) in einem Aktualisierungssystem gemäß An- spruch 14 oder 15 zum Aktualisieren einer Software (SW) in Fahrzeugen (50) ei- ner Fahrzeugflotte gemäß einem der Ansprüche 1 bis 12 und insbesondere dazu, zumindest ein Fahrzeug (50) der Fahrzeugflotte zu identifizieren, dessen Software (SW) zu aktualisieren ist, und die Software (SW) des zumindest einen identifizierten Fahrzeugs (50) über eine Funkverbindung (40) gemäß vorgege- benen Aktualisierungsbedingungen (B) zu aktualisieren, welche eine Hinter- grundeinrichtung (10) bereitstellt.
18. Fahrzeug (50) einer Fahrzeugflotte, derart eingerichtet, dass eine in dem
Fahrzeug (50) installierte Software (SW) durch ein Aktualisierungssystem nach Anspruch 13 oder 14 gemäß einem Verfahren nach einem der Ansprüche 1 bis 12 aktualisiert werden kann.
EP21749092.9A 2020-07-24 2021-07-22 Software-aktualisierung über eine funkverbindung Pending EP4185951A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020004570.7A DE102020004570A1 (de) 2020-07-24 2020-07-24 Software-Aktualisierung über eine Funkverbindung
PCT/EP2021/025273 WO2022017645A1 (de) 2020-07-24 2021-07-22 Software-aktualisierung über eine funkverbindung

Publications (1)

Publication Number Publication Date
EP4185951A1 true EP4185951A1 (de) 2023-05-31

Family

ID=77168200

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21749092.9A Pending EP4185951A1 (de) 2020-07-24 2021-07-22 Software-aktualisierung über eine funkverbindung

Country Status (3)

Country Link
EP (1) EP4185951A1 (de)
DE (1) DE102020004570A1 (de)
WO (1) WO2022017645A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12288059B2 (en) 2023-01-27 2025-04-29 Toyota Motor North America, Inc. Over the air analytics
DE102023209901A1 (de) * 2023-10-10 2025-04-10 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Durchführen eines Updates eines Steuergeräts in einem Fahrzeug

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009060358A1 (de) 2009-12-24 2011-06-30 Volkswagen AG, 38440 Kommunikationssystem für Kraftfahrzeuge
US9549291B2 (en) 2014-03-31 2017-01-17 Ford Global Technologies, Llc Crowd enhanced connectivity map for data transfer intermittency mitigation
DE102017205479B4 (de) 2017-03-31 2024-08-29 Audi Ag Verfahren zur Vorhersage einer Mobilfunksignalstärke einer Mobilfunkanbindung eines Kraftfahrzeugs und Servervorrichtung zum Ausführen des Verfahrens
US10496394B2 (en) * 2018-02-22 2019-12-03 Ford Global Technologies, Llc Cloud-based dynamic optimization of vehicle software updates
US10812624B2 (en) * 2018-09-14 2020-10-20 Cisco Technology, Inc. Firmware/software over the air (FOTA) scheduling for connected vehicles

Also Published As

Publication number Publication date
DE102020004570A1 (de) 2022-01-27
WO2022017645A1 (de) 2022-01-27

Similar Documents

Publication Publication Date Title
EP3688538B1 (de) Verfahren und system zum aktualisieren eines steuerungsmodells für eine automatische steuerung zumindest einer mobilen einheit
DE102017201789B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
EP1026649B1 (de) Verfahren und Vorrichtung zur Bereitstellung von Verkehrsinformation
EP2186077B1 (de) Verfahren und vorrichtung zur steuerung des verkehrsflusses
DE102019002790B4 (de) Verfahren zur Prädiktion einer Verkehrssituation für ein Fahrzeug
DE102017126167A1 (de) Verfahren und vorrichtung zur fahrzeugfahrunterstützung
DE102015111218A1 (de) Parkmanagement für ein Fahrzeug
DE102012201472A1 (de) Verfahren zur Bereitstellung von Parkinformationen zu freien Parkplätzen
EP3333823B1 (de) Prognose einer signalisierung einer lichtsignalanlage mittels künstlicher intelligenz
EP4185951A1 (de) Software-aktualisierung über eine funkverbindung
DE112021001592T5 (de) Fahrzeuginterne steuervorrichtung, server und verifikationssystem
DE102013000385A1 (de) Verfahren und Navigationssystem zum Ermitteln eines Fahrroutenvorschlags für eine bevorstehende Fahrt mit einem Kraftwagen
DE102014225122A1 (de) Verfahren und System zur Bereitstellung von Informationen zur Verfügbarkeit von Ladestationen
WO2023247089A1 (de) Verfahren und vorrichtung zur prädiktion der wartezeit an einer ladestation
DE102019122543A1 (de) Verkehrsminderungssystem
EP3437958A1 (de) Abschätzen einer voraussichtlichen fahrzeit eines schienenfahrzeugs
DE102014214757B4 (de) Verfahren und Vorrichtung zum Erinnern eines Nutzers an einen Termin an einem entfernten Ort
DE102020129016A1 (de) Kontextmodellierung beim lernen eines benutzerverhaltens
EP3709278B1 (de) Erheben von fahrzeugbasierten, ortsbezogenen datensätzen
EP0239827A2 (de) Verfahren zum Ansteuern eines gemeinsamen Speichers eines aus einzelnen Mikroprozessorsystemen bestehenden Mehrprozessorsystems
WO2023274585A1 (de) Verfahren zum bereitstellen eines prädizierten, aktuellen fahrziels an einen nutzer eines fahrzeugs, computerlesbares medium, system, fahrzeug, und mobiles endgerät
DE102021204191B4 (de) Vorrichtung und Verfahren zur echtzeit-basierten dynamischen Verkehrszuordnung für zumindest zwei nachfolgende Fahrbahnen
EP4700684A1 (de) Verfahren zur ermittlung der verteilung der raumaufgelösten nutzung von verkehrsmitteln einer aus einer vielzahl an individuen bestehenden personenmenge in einem ermittlungszeitraum sowie ein das verfahren ausführendes system
EP4700686A1 (de) Verfahren zur ermittlung der verteilung der raumaufgelösten nutzung von verkehrsmitteln einer aus einer vielzahl an individuen bestehenden personenmenge in einem ermittlungszeitraum sowie ein das verfahren ausführendes system
DE102009027544A1 (de) Verfahren und Vorrichtung zur Ermittlung einer Verkehrsprognose

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230224

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20260116