WO2024022732A1 - Verfahren zum bereitstellen eines updates für ein kraftfahrzeug - Google Patents

Verfahren zum bereitstellen eines updates für ein kraftfahrzeug Download PDF

Info

Publication number
WO2024022732A1
WO2024022732A1 PCT/EP2023/068011 EP2023068011W WO2024022732A1 WO 2024022732 A1 WO2024022732 A1 WO 2024022732A1 EP 2023068011 W EP2023068011 W EP 2023068011W WO 2024022732 A1 WO2024022732 A1 WO 2024022732A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
motor vehicle
data
installation
units
Prior art date
Application number
PCT/EP2023/068011
Other languages
English (en)
French (fr)
Inventor
Stefan Frank
Stefan HAGG
André Oliver KLEINERT
Original Assignee
Audi Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Audi Ag filed Critical Audi Ag
Publication of WO2024022732A1 publication Critical patent/WO2024022732A1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Definitions

  • the invention relates to a method for providing an update for a motor vehicle and a system for carrying out such a method.
  • a motor vehicle can have several control devices, each of which is operated with software. There may be several software versions for each software.
  • the respective control device of the motor vehicle is operated with exactly one of the software versions, which can be referred to as the respective current software version of the control device. It may now be the case that there is a new software version for at least one of the control devices that differs from the current software version of the control device, so that an update of the software of the control device makes sense.
  • the update is typically provided to the motor vehicle by an external computing device by being transmitted to the motor vehicle.
  • the update can have several update units, each of which includes update software for one of the control devices of the motor vehicle, so that the software of several control devices can be changed with a single update.
  • the DE 10 2019 212 664 A1 shows a device for providing an update for a vehicle with a plurality of controls.
  • a control circuit of the vehicle is configured to set an order of updating the controls based on a preset priority and a size of update data.
  • DE 11 2017 006 978 T5 shows a control device designed to control updating a control program of an on-board vehicle control device.
  • a control unit of the control device may execute a determination process to determine whether or not to execute an update of the plurality of control programs according to update orders.
  • WO 2019/021064 A1 shows generating a software delta file for a vehicle control device. Attributes of a software update are compared with attributes of current software stored in the vehicle control device and, depending on differences between these attributes, a software delta file is generated.
  • a first aspect of the invention relates to a method for providing an update for a motor vehicle.
  • the method is based at least partially on the knowledge that in a motor vehicle there is often an air conditioning system for each individual control device, that is, for example, for a control device for a braking system, a control device for a lighting device and/or a control device for a comfort function, such as a seat heater and/or a multimedia device, individual control devices are provided.
  • Common interfaces can be provided for several of the control devices, via which a connection to a central communication interface of the motor vehicle can be possible.
  • the central communication interface can be used, for example, to provide Internet access for the motor vehicle.
  • an obligation to provide evidence for software that is newly intended for the motor vehicle can be specified, for example in order to be able to detect manipulation of the software at an early stage.
  • a complete software list is provided in which a currently intended software version is entered for each control device potentially included in the motor vehicle.
  • the complete software list can be provided by a vehicle manufacturer. In the list, different versions of the control device itself can be distinguished, which differ in terms of hardware.
  • a motor vehicle does not necessarily have all of the control devices in the overall list, but rather, for example, depending on the equipment of the motor vehicle, a selection of the control devices in the overall software list.
  • the overall software list can be referred to as the baseline. The overall software list therefore describes a full package of possible control devices for a motor vehicle.
  • a motor vehicle typically only has a selection of control devices, when providing an update, corresponding update units should not be transmitted for all control devices in the overall software list, but only the update units relevant to the motor vehicle that affect the software of the control devices actually arranged in the motor vehicle.
  • Such an approach is particularly resource- and time-saving because the update that is provided to the motor vehicle is tailored to the motor vehicle.
  • the method according to the invention includes providing equipment data from the motor vehicle to an external computing device.
  • the equipment data describes which control devices the motor vehicle is equipped with and which software version the respective control device is currently operated with.
  • the software version therefore refers to software that is stored in the control device and with which the control device is currently operated.
  • the software version is a version of the software installed in the control device.
  • the equipment data can be summarized as a list, which lists all control devices of the motor vehicle with their current software version. The equipment data therefore describes the installation status of the motor vehicle in terms of hardware and software.
  • a central control device can be provided in the motor vehicle itself, which compiles the equipment data and transmits it, for example, to a communication interface of the motor vehicle, which then transmits the equipment data to the external computing device via a communication connection and thus makes it available to it.
  • the communication connection is preferably designed to be wireless, in particular wireless.
  • the communication connection can be, for example, via a wireless local area network (WLAN for Wireless Local Area Network), a Bluetooth connection and/or a mobile data network, for example based on the Long Term Evolution (LTE) mobile communications standard, Long Term Evolution Advanced (LTE-A). , Fifth Generation (5G) or Sixth Generation (6G).
  • the communication connection can be at least partially wired, in particular wired.
  • the communication connection of this type can take place via a vehicle diagnostic system interface of the motor vehicle.
  • An additional external computing device can be provided, which is at least wired coupled to the vehicle diagnostic system interface and which is designed to establish or maintain a communication connection to the external computing device.
  • the external computing device is, for example, a server, a cloud server or a backend.
  • the external computing device is used to select all update units relevant to the motor vehicle from the overall software list.
  • a currently planned software version is entered in the overall software list for each control device potentially included in the motor vehicle.
  • the overall software list preferably has exactly one software version per control device.
  • the relevant software units are selected taking into account the equipment data provided. In other words, everyone can Individual control device of the motor vehicle must be checked to see whether a different software version is provided for it according to the overall software list than the software version that can be found in the equipment list for this control device.
  • the update unit For each control device of the motor vehicle for which the software versions of the equipment data and the overall software list do not match, the update unit is selected, that is, the software of the corresponding new software version is selected.
  • the update unit is a component of an overall update and can alternatively be referred to as an individual update for one of the control devices of the motor vehicle.
  • the external computing device is now used to determine update sequence data by applying a sequence determination criterion to the selected update units.
  • the update order data describes an order of installing the selected update units in the motor vehicle.
  • the sequence determination criterion is an algorithm and/or a rule, based on which the external computing device determines which of the selected update units should be installed in the motor vehicle and when compared to the other update units.
  • each update unit is assigned a position number, for example, so that, for example, the individual update units are installed one after the other, i.e. serially, following ascending position numbers when they are installed in the motor vehicle according to the update sequence data.
  • the sequence determination criterion is carried out by the external computing device, with the update sequence data being available as a result of the implementation. In other words, the update sequence is determined by determining a chronological sequence of the individual update units.
  • the method also includes providing the selected update units and the determined update sequence data for the motor vehicle.
  • the selected update units and the determined update sequence data are transmitted via the communication connection transmitted to the motor vehicle by the external computing device.
  • the selected update units and the determined update sequence data can be transmitted, for example, as an update package or as an update folder.
  • the update units are to be understood in such a way that they have the corresponding software for the corresponding update of the respective control device.
  • the update units each include software code for the respective control device for which a new software version is intended.
  • the method according to the invention ensures that a reliable update is provided for the motor vehicle, which only includes the update units that should actually be installed in the motor vehicle and which also specifies how particularly sensible and reliable the order of installing the update units should be.
  • a dependency of the installation of an update unit on the installation of another update unit can be taken into account if such information is taken into account by the sequence determination criterion.
  • a large number of possible requirements for the update sequence can be taken into account by designing the sequence determination criterion accordingly.
  • the invention includes embodiments that result in additional advantages.
  • the provided update units are installed in the motor vehicle in the order according to the provided update sequence data.
  • the individual update units in the motor vehicle itself can be assigned to their respective control devices are assigned, so that, for example, initiated by the central control device or carried out by the respective individual control devices themselves, the respective update units are installed according to the update sequence data.
  • the control devices can be flashed or updated according to the order based on the update units provided.
  • a further exemplary embodiment provides that the update sequence data specifies whether several of the update units provided and, if so, which of the update units are installed in parallel. It is therefore not necessarily necessary for the individual update units to be installed serially, but rather the sequence determination criterion can be used to determine which of the update units can be installed in the motor vehicle at the same time, for example since the corresponding control devices do not provide processes and/or services that depend on one another. This allows the installation time for installing the update units to be reduced since, if possible, several update units are always installed at the same time in accordance with the update sequence data. This leads to a particularly time-saving update of the control devices.
  • an exemplary embodiment provides that the sequence determination criterion is based on a mathematical model.
  • the mathematical model takes into account at least one of the following information for each of the selected update units: a dependency on an installation of at least one other update unit; an installation period; an installation energy consumption; a general security requirement; a functional safety requirement; and/or a legal security requirement.
  • the sequence determination criterion therefore contains, for example, information about the installation of the individual update units themselves, that is to say their dependence on each other, time required and/or energy required.
  • the installation time period can alternatively be referred to as the update time.
  • the installation energy consumption can be understood as the amount of energy required to install the respective update unit.
  • a maximum current load in a motor vehicle can be measured and the installation energy consumption can be calculated from this.
  • the installation time can also be determined during the test installation.
  • the installation time and the installation energy consumption are performance indicators for the installation of the respective update unit.
  • the dependency of the individual control devices on one another is preferably a functional dependency, so that this includes, for example, whether individual control devices are in a data exchange. It can then be provided that, for example, the update unit is not installed in one control device while another control device continuously expects data from the control device. In this situation, the control device waiting for the data can malfunction. In such a case, it therefore makes sense to update the interconnected control devices synchronously, that is, in parallel. Alternatively or in addition to this, precautions can be taken so that, for example, no malfunction is triggered in the control device awaiting the data.
  • the general security requirement can, for example, have requirements and thus specifications for the communication interface itself and its possible update.
  • the safety requirement can alternatively be referred to as a safety and security-relevant requirement.
  • the software update is an update for an interface that may receive and/or process data from the external computing device and/or another external data source, there may be special requirements for carrying out the corresponding update unit, since the security of the entire system of Motor vehicle can be affected. Such security requests can therefore be taken into account using the general security requirements.
  • the functional safety requirement concerns, for example, control devices that are designed to be redundant and which, for example, should not be affected by the update at the same time.
  • the functional safety requirement can, for example, specify that in the case of updates for control devices for door locking of the doors of the motor vehicle, it is not possible for the control device to be installed on all, for example, four doors of the motor vehicle at the same time.
  • at least one control device for one of the doors of the motor vehicle must always be unaffected by the installation of the update unit, so that, for example, the four control devices of the four vehicle doors can only be affected by the update one after the other, that is to say serially, and not at the same time.
  • the legal requirement concerns, for example, legally specified prohibitions and/or specifications for update processes, so that, for example, stamps and/or signatures must be specified and maintained.
  • Such a legal security requirement may, for example, have been determined by an international or national institution, such as the Automotive Cybersecurity Regulations of the United Nations Economic Commission for Europe (UNECE, for United Nations Economic Commission for Europe).
  • sequence determination criterion bundles a lot of information that can be used to determine the update sequence data.
  • the sequence determination criterion is therefore present as a mathematical model that is based on at least one and preferably on several of the mentioned pieces of information. This allows a particularly sensible update sequence to be determined.
  • an exemplary embodiment provides that
  • Sequence determination criterion empirical data is taken into account.
  • the Experience data describes at least one experience that was determined during a protection of the respective control device of the motor vehicle and/or a network protection of the control device. Alternatively or in addition, the experience was provided as feedback to past updates. In other words, past experience can be used to optimize and adapt the mathematical model of the sequence determination criterion.
  • the protection of the respective control device is determined, for example, as part of a cyclic test that is required to release the control device for installation in a motor vehicle.
  • requirements for updates can be checked, such as determining the installation time and the installation energy consumption.
  • Such safeguards can also be determined for an entire network, that is, for example, for all control devices mentioned in the overall software list. This is then the network protection.
  • maximum values for the installation time and/or the installation energy consumption for the update units for all control devices in the overall software list can be determined from the network protection.
  • information from development at the vehicle manufacturer which is generated as part of cyclical tests in the development and/or production of control devices, can be made available to the sequence determination criterion, which can then take this into account.
  • the test installation mentioned above can be carried out as an example.
  • Feedback from previous or previous updates can be provided, for example, by workshops and/or other test installations.
  • the feedback is, for example, empirical values from previous update campaigns.
  • Feedback is preferably provided by individual motor vehicles for example, be transmitted from the respective motor vehicle to the external computing device. In this way, for example, information can be obtained about which dependencies between the individual control devices must be taken into account and/or the installation time duration and/or installation energy consumption determined for the respective protection can be checked, in particular confirmed. This allows the sequence determination criterion to be further specified.
  • the experience data is provided cyclically. For example, fixed time intervals can be provided at which the empirical data is provided. This ensures that the information provided in the form of experience data is always up to date.
  • the update sequence data has total installation duration information that describes an expected total duration of an installation of the selected update units.
  • the total installation time information can be described using total time data included in the update order data. It is now checked whether the total installation duration information, i.e. the expected total duration of the installation of the update, is less than a predetermined duration limit. If this is the case, in particular only if this is the case, the selected update units and the determined update sequence data are provided and/or their installation is permitted. The checking takes place in particular before providing the selected update units and the determined update sequence data. Ultimately, it can be provided that the update is only provided or its installation is made possible if the total time required for installing the update units of the update does not exceed the predetermined time limit.
  • the update units are to be installed while waiting in front of a traffic light device and thus while the motor vehicle is in motion. Since such a waiting period is typically only a few seconds or minutes long, a correspondingly short time limit can be specified. This prevents the update from preventing the motor vehicle from being roadworthy for a longer period of time than desired. If the total installation duration information is greater than or equal to the specified duration limit, it may be possible that the determined update sequence data and the selected update units are still provided, but a message is issued in the motor vehicle, which informs about the expected exceedance of the duration limit when installing the update. The user can then, for example, still allow the update to be installed at any time, even though the time limit has been exceeded. This ultimately provides a particularly user-friendly update for the motor vehicle.
  • a further exemplary embodiment can provide that the update sequence data has total energy consumption information that describes an expected total installation energy consumption of an installation of the selected update units.
  • the total energy consumption information may be in the form of total energy consumption data, which may be included in the update order data. It is then checked whether the expected total installation energy consumption according to the total energy consumption information is less than a predetermined energy consumption limit. If this is the case, in particular only if this is the case, the selected update units and the determined update sequence data are provided and/or their installation is permitted. In particular, the checking takes place before the selected update units and the determined update sequence data are provided for the motor vehicle. This can be done if the check is not successful, i.e.
  • the Total energy consumption information is greater than or equal to the energy consumption limit, an indication of the expected exceeding of the energy consumption limit in the motor vehicle is issued.
  • This can ensure that, for example, the update does not require more energy than is intended for this purpose and, for example, that a 12-volt battery of the motor vehicle, which, for example, provides energy for installing the update, is not drained while the update is being installed.
  • This ensures by means of an additional check that the determined update sequence makes sense for the selected update units, since it provides the update for the motor vehicle in such a way that the installation energy consumption for the entire update does not exceed the specified limit value.
  • charge state data is determined.
  • the state of charge data describes a state of charge of a battery of the motor vehicle.
  • the battery of the motor vehicle is typically the 12-volt battery of the motor vehicle.
  • the battery is therefore, for example, not a high-voltage battery that is designed to supply energy to an electric motor and thus an electric drive of the motor vehicle.
  • the energy consumption limit is set depending on the determined state of charge data. If, for example, it is determined that the battery of the motor vehicle is already almost empty, this can have an impact on the provision of the selected update units and the determined update sequence data for the motor vehicle and / or their installation, so that only if the battery of the motor vehicle supports the installation of the update actually allows this to be provided and/or installed at all, for example.
  • the state of charge data is determined in the motor vehicle and transmitted, for example, to the external computing device via the communication connection.
  • the transmission to the external computing device can take place automatically, that is, for example, continuously, and/or in response to a request from the external computing device. This allows a reliable Protection must be provided to prevent the update from negatively affecting the energy supply of the motor vehicle.
  • the system includes a motor vehicle and an external computing device.
  • the system is designed to carry out the method described above.
  • the system can alternatively be referred to as an arrangement comprising a motor vehicle and an external computing device. In this case, the arrangement is designed to carry out the method described above.
  • the invention also includes further developments of the system according to the invention, which have features as have already been described in connection with the further developments of the method according to the invention. For this reason, the corresponding further training courses are not described again here.
  • the motor vehicle is preferably designed as a motor vehicle, in particular as a passenger car or truck, or as a passenger bus or motorcycle.
  • the invention also includes the control devices for the motor vehicle and the external computing device.
  • the respective control device can have a data processing device or a processor device that is set up to carry out an embodiment of the method according to the invention.
  • the processor device can have at least one microprocessor and/or at least one microcontroller and/or at least one FPGA (Field Programmable Gate Array) and/or at least one DSP (Digital Signal Processor).
  • the processor device can have program code that is designed to carry out the embodiment of the method according to the invention when executed by the processor device.
  • the program code can be stored in a data memory of the processor device.
  • the invention also includes a computer-readable storage medium comprising instructions which, when executed by a computer or a computer network, cause it to carry out an embodiment of the method according to the invention.
  • the storage medium can, for example, be designed at least partially as a non-volatile data storage (e.g. as a flash memory and/or as an SSD - solid state drive) and/or at least partially as a volatile data storage (e.g. as a RAM - random access memory).
  • the computer or computer network can provide a processor circuit with at least one microprocessor.
  • the instructions may be provided as binary code or assembler and/or as source code of a programming language (e.g. C).
  • the invention also includes the combinations of the features of the described embodiments.
  • the invention therefore also includes implementations that each have a combination of the features of several of the described embodiments, provided that the embodiments have not been described as mutually exclusive.
  • 1 shows a schematic representation of a system comprising a motor vehicle and an external computing device; and 2 shows a schematic representation of a signal flow graph for a method for providing an update for a motor vehicle.
  • a motor vehicle 1 is sketched in FIG.
  • An external computing device 2 is also sketched, which is designed, for example, as a server or backend.
  • the motor vehicle 1 and the computing device 2 are included in a system 3.
  • System 3 can alternatively be referred to as an arrangement.
  • the motor vehicle 1 has several control devices 4.
  • the individual control devices 4 can be designed to control a drive device of the motor vehicle 1, that is, for example, an engine of the motor vehicle 1, to provide a comfort function, such as control of an air conditioning system and/or a multimedia device, and/or another function or one to provide other services for the motor vehicle 1, such as the control of a lighting device, a remote control for a door locking device and/or an automatic window opening device.
  • the motor vehicle includes 1 individual control devices 4 for different functions and/or services.
  • the respective control device 4 can be a computing device, which, however, unlike the external computing device 2, is an internal device of the motor vehicle 1.
  • a central control device 5 for the motor vehicle 1 is also sketched, which can, for example, receive and collect information from the individual control devices 4. For example, data exchange with the external computing device 2 can be controlled via the control device 5.
  • the motor vehicle 1 has a communication interface 6.
  • the external computing device 2 has a communication interface 6.
  • a wireless, in particular wireless, communication connection 7 can be established and/or maintained between the two communication interfaces 6.
  • the communication connection can be at least partially wired, in particular wired.
  • data can be transmitted, in particular exchanged, between the motor vehicle 1 and the external computing device 2 via the communication connection 7.
  • the motor vehicle 1 also has a battery 8 for which charge status data 9 is available.
  • the state of charge data 9 describes a state of charge of the battery 8 of the motor vehicle 1.
  • the state of charge data 9 refers, for example, to a 12-volt battery as battery 8 and not, for example, to a high-voltage battery, as would be required to operate an electric motor as a drive device of the motor vehicle 1.
  • step S1 equipment data 10 is provided from the motor vehicle 1 to the external computing device
  • the equipment data 10 describes which control devices 4 are used in the motor vehicle 1 is equipped and with which software version the respective control device 4 is currently operated.
  • the equipment data 10 contains information about current hardware and software of the motor vehicle
  • step S2 the external computing device is used
  • 11 shows a list of all the software potentially installed in the motor vehicle 1, which includes the current software described for each possible hardware using the corresponding software version.
  • the motor vehicle 1 does not necessarily include all control devices 4 that are listed in the overall software list 11, but rather, for example, only a selection of them.
  • the overall software list 11 can list 80 control devices 4, with the motor vehicle 1 actually comprising, for example, only five or any other number between 1 and 80 of these control devices 4.
  • an update unit 12 is only relevant if this control device 4 is operated according to the equipment data 10 with a different software version than the overall software list 11 provides for it.
  • two update units 12 are therefore selected, since, for example, three of the five exemplary control devices 4 are at a software level, that is to say have a software version as provided for in the overall software list 11 and therefore respective update units 12 are only available for two of the control devices 4 .
  • the Update units 12 include the software code required for updating the corresponding control device 4.
  • a sequence determination criterion 13 is applied to the selected update units 12 using the external computing device 2.
  • update sequence data 14 is determined, which describes an order of installing the selected update units 12 in the motor vehicle 1.
  • it is determined which of the two update units 12 should be installed first in the motor vehicle 1 and/or whether both could be installed in parallel and therefore at the same time, for example.
  • a detailed order can be determined.
  • the sequence determination criterion 13 is based on a mathematical model.
  • the mathematical model takes into account at least one of the following pieces of information 15 for each of the selected update units 12: a dependency on an installation of at least one other update unit 12, an installation time period, an installation energy consumption, a general security requirement, a functional security requirement and/or a legal security requirement.
  • the sequence determination criterion 13 can alternatively or additionally take into account experience data 16, which describe at least one experience that occurs when the respective control device 4 of the motor vehicle 1 is secured and/or a network is secured for the control devices 4, that is, for example, of all control devices 4 that are in the overall software list 11 listed, identified and/or provided as feedback to past updates.
  • the experience data 16 can, for example, be provided cyclically, so that the sequence determination criterion 13 can be revised cyclically based on the experience data 16.
  • the experience data 16 can at least partially concern the aforementioned information 15, that is, they can, for example, concern an installation period for an update unit 12.
  • the selected update units 12 and the determined update sequence data 14 are made available for the motor vehicle 1.
  • the selected update units 12 together with the determined update sequence data 14 can be referred to as an update package 17 or an update.
  • the motor vehicle 1 is thus provided with an update package 17, in which the software updates required for the individual control devices 4 (update units 12) as well as information on the order of installation of the individual software updates (update sequence data 14) can be found.
  • step S5 it is provided that the provided update units 12 are installed in the motor vehicle 1 in the order according to the provided update sequence data 14. This can be done, for example, by appropriately controlling the individual control devices 4 using the central control device 5.
  • the individual update units 12 are installed in parallel, if this is possible and sensible, and otherwise in series.
  • a method step S6 it can be checked whether an expected total time duration according to total installation time duration information 18 is smaller than a predetermined time duration limit value 19.
  • the update sequence data 14 here has the total installation duration information 18, which describes an expected total duration of an installation of the selected update units 12. Only if this is the case or always if this is the case can method step S4 and/or method step S5 take place. If method step S5 takes place after successful checking, method step S4 is also carried out before method step S6 is carried out. Alternatively or additionally, in a method step S7 it can be checked whether an expected total installation energy consumption according to total energy consumption information 20 is smaller than a predetermined energy consumption limit value 21.
  • the update sequence data 14 has the total energy consumption information 20, which describes an expected total installation consumption of an installation of the selected update units 12. If the checking is successful, method step S4 and/or method step S5 can take place. If method steps S7 and/or S6 are not successful, method step S2 can be carried out again, for example, that is, for example, fewer update units 12 can be selected and/or a different update sequence and thus different update sequence data 14 can be determined by carrying out method step S3 again .
  • the state of charge data 9 can be taken into account, so that, for example, the energy consumption limit 21 can be dependent on the current state of charge according to the state of charge data 9.
  • the method steps S6 and S7 can be carried out using the external computing device 2 and/or using the control device 5.
  • the examples show a model-based calculation of update orders (flash order) for the composite update of motor vehicle 1.
  • the update order i.e. the update sequence data 14 is created using a model-based approach. All flash-relevant, functional dependencies between control devices 4, safety and security-relevant requirements, performance indicators such as update time, maximum current load and amount of energy during the update as well as legal requirements are described in a mathematical model that is used for an automated calculation of the update order .
  • This mathematical model is available here in the form of sequence determination criterion 13.
  • the experience data 16 is therefore taken into account by the sequence determination criterion 13.
  • a database is used as input for the data model, in which the recording of the relevant artifacts (individual control device updates, current values, energy quantities) from the upstream measurement and validation processes on individual control devices or composite tests is mapped, i.e. the information 15 is used for the sequence determination criterion 13 taken into account.
  • the technical implementation is based on a group database that is filled with empirical values such as individual control device flash times, individual control device energy quantities, current measurements and so on, both from measurements at a test station and from real update processes from customers (experience data 16) in order to serve the mathematical data model.
  • the data model uses mathematical and logical relationships to map the requirement, dependency and/or relevant legal requirements when calculating a flash sequence for a network update, that is, the update sequence data 14 can be determined using the sequence determination criterion 13.
  • the data calculation is initiated via a server (external computing device 2) when a new baseline is created, i.e. a new overall software list 11, and the results of the calculation are retrieved using the data model.
  • these implemented and paralyzed update processes can be displayed in an easily readable manner for the operator.
  • Critical paths, expected total update times and expected amounts of energy required can also be calculated. Based on these values, a statement can be made regarding compliance with the statutory performance indicators before the release of a complete software list 11. This is at least partially achieved, for example, by checking steps S6 and S7.

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug (1) sowie ein System (3) zum Durchführen des Verfahrens. Das Verfahren umfasst: Bereitstellen (S1) von Ausstattungsdaten (10), die beschreiben, mit welchen Steuereinrichtungen (4) das Kraftfahrzeug (1) ausgestattet ist und mit welcher Softwareversion die jeweilige Steuereinrichtung (4) aktuell betrieben wird, für eine externe Recheneinrichtung (2); mittels der externen Recheneinrichtung (2), Auswählen (S2) von allen für das Kraftfahrzeug (1) relevanten Updateeinheiten (12) aus einer Softwaregesamtliste (11), in die für jede potentiell vom Kraftfahrzeug (1) umfasste Steuereinrichtung (4) eine aktuell vorgesehene Softwareversion eingetragen ist, unter Berücksichtigung der bereitgestellten Ausstattungsdaten (10); mittels der externen Recheneinrichtung (2), Ermitteln (S3) von Updatereihenfolgedaten (14), die eine Reihenfolge eines Installierens der ausgewählten Updateeinheiten (12) im Kraftfahrzeug (1) beschreiben, durch Anwenden eines Reihenfolgeermittlungskriteriums (13) auf die ausgewählten Updateeinheiten (12); und Bereitstellen (S4) der ausgewählten Updateeinheiten (12) und der ermittelten Updatereihenfolgedaten (14) für das Kraftfahrzeug (1).

Description

Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug
BESCHREIBUNG:
Die Erfindung betrifft ein Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug sowie ein System zum Durchführen eines derartigen Verfahrens.
Ein Kraftfahrzeug kann mehrere Steuereinrichtungen aufweisen, die jeweils mit einer Software betrieben werden. Für die jeweilige Software kann es mehreren Softwareversionen geben. Die jeweilige Steuereinrichtung des Kraftfahrzeugs wird mit genau einer der Softwareversionen betrieben, die als jeweilige aktuelle Softwareversion der Steuereinrichtung bezeichnet werden kann. Es kann nun der Fall sein, dass für zumindest eine der Steuereinrichtungen eine neue Softwareversion vorliegt, die von der aktuellen Softwareversion der Steuereinrichtung abweicht, sodass ein Update der Software der Steuereinrichtung sinnvoll ist. Das Update wird dem Kraftfahrzeug typischerweise von einer externen Recheneinrichtung bereitgestellt, indem es an das Kraftfahrzeug übermittelt wird. Das Update kann mehrere Updateeinheiten aufweisen, die jeweils Updatesoftware für eine der Steuereinrichtungen des Kraftfahrzeugs umfassen, sodass mit einem einzelnen Update die Software mehrerer Steuereinrichtungen geändert werden kann.
Die DE 10 2019 212 664 A1 zeigt eine Vorrichtung zum Bereitstellen einer Aktualisierung für ein Fahrzeug mit einer Vielzahl von Steuerungen. Eine Steuerschaltung des Fahrzeugs ist dazu eingerichtet, eine Reihenfolge der Aktualisierung der Steuerungen auf der Grundlage einer voreingestellten Priorität und einer Größe von Aktualisierungsdaten einzustellen. Die DE 11 2017 006 978 T5 zeigt eine Steuereinrichtung, ausgebildet zum Steuern eines Aktualisierens eines Steuerprogramms einer Bordfahrzeugsteuervorrichtung. Eine Steuereinheit der Steuereinrichtung kann einen Bestimmungsprozess ausführen, um zu bestimmen, ob eine Aktualisierung der Vielzahl von Steuerprogrammen entsprechend von Aktualisierungsreihenfolgen auszuführen ist oder nicht.
Die WO 2019/021064 A1 zeigt ein Erzeugen einer Software-Deltadatei für eine Fahrzeugsteuereinrichtung. Attribute eines Softwareupdates werden mit Attributen einer aktuellen Software, die in der Fahrzeugsteuereinrichtung gespeichert ist, verglichen und abhängig von Unterschieden zwischen diesen Attributen wird eine Software-Deltadatei erzeugt.
Es ist die Aufgabe der Erfindung, eine Lösung bereitzustellen, mittels derer zuverlässig ein Update für ein Kraftfahrzeug bereitgestellt werden kann.
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst.
Ein erster Aspekt der Erfindung betrifft ein Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug. Das Verfahren beruht zumindest teilweise auf der Erkenntnis, dass in einem Kraftfahrzeug oftmals für jede einzelne Steuereinrichtung, das heißt beispielsweise für eine Steuereinrichtung für ein Bremssystem, eine Steuereinrichtung für eine Leuchteinrichtung und/oder eine Steuereinrichtung für eine Komfortfunktion, wie beispielsweise eine Sitzheizung, eine Klimaanlage und/oder eine Multimediaeinrichtung, jeweils einzelne Steuereinrichtungen vorgesehen sind. Für mehrere der Steuereinrichtungen können gemeinsame Schnittstellen vorgesehen sein, über die eine Verbindung zu einer zentralen Kommunikationsschnittstelle des Kraftfahrzeugs möglich sein kann. Mittels der zentralen Kommunikationsschnittstelle kann beispielsweise ein Internetzugang für das Kraftfahrzeug bereitgestellt werden. Ferner kann eine Nachweispflicht für Software, die neu für das Kraftfahrzeug vorgesehen ist, vorgegeben sein, um beispielsweise Manipulationen an der Software frühzeitig feststellen zu können. Aus diesem Grund wird beispielsweise eine Softwaregesamtliste bereitgestellt, in der für jede potentiell vom Kraftfahrzeug umfasste Steuereinrichtung eine aktuell vorgesehene Softwareversion eingetragen ist. Die Softwaregesamtliste kann von einem Fahrzeughersteller bereitgestellt sein. In der Liste können verschiedene Versionen der Steuereinrichtung selbst unterschieden werden, die sich hardwaretechnisch unterscheiden. Ein Kraftfahrzeug weist nicht zwangsläufig alle Steuereinrichtungen der Gesamtliste auf, sondern, zum Beispiel je nach Ausstattung des Kraftfahrzeugs, eine Auswahl der Steuereinrichtungen der Softwaregesamtliste. Die Softwaregesamtliste kann als Baseline bezeichnet werden. Die Softwaregesamtliste beschreibt also ein Vollpaket an möglichen Steuereinrichtungen für ein Kraftfahrzeug.
Da ein Kraftfahrzeug typischerweise nur die Auswahl an Steuereinrichtungen aufweist, sollten im Rahmen des Bereitstellens eines Updates nicht für alle Steuereinrichtungen der Softwaregesamtliste entsprechende Updateeinheiten übermittelt werden, sondern nur die für das Kraftfahrzeug relevanten Updateeinheiten, die die Software der tatsächlich im Kraftfahrzeug angeordneten Steuereinrichtungen betreffen. Ein derartiges Vorgehen ist besonders ressourcen- und zeitsparsam, da das Update, das dem Kraftfahrzeug bereitgestellt wird, auf das Kraftfahrzeug zugeschnitten ist.
Das erfindungsgemäße Verfahren umfasst ein Bereitstellen von Ausstattungsdaten vom Kraftfahrzeug für eine externe Recheneinrichtung. Die Ausstattungsdaten beschreiben, mit welchen Steuereinrichtungen das Kraftfahrzeug ausgestattet ist und mit welcher Softwareversion die jeweilige Steuereinrichtung aktuell betrieben wird. Die Softwareversion bezieht sich also auf eine Software, die in der Steuereinrichtung gespeichert ist und mit der die Steuereinrichtung aktuell betrieben wird. Die Softwareversion ist mit anderen Worten eine Version der Software, die in der Steuereinrichtung installiert ist. Die Ausstattungsdaten können als Liste zusammengefasst sein, die alle Steuereinrichtungen des Kraftfahrzeugs mit ihrer jeweiligen aktuellen Softwareversion auflistet. Die Ausstattungsdaten beschreiben somit einen Verbauzustand des Kraftfahrzeugs hinsichtlich Hardware und Software. Im Kraftfahrzeug selbst kann beispielsweise eine zentrale Steuervorrichtung vorgesehen sein, die die Ausstattungsdaten zusammenstellt und diese beispielsweise einer Kommunikationsschnittstelle des Kraftfahrzeugs übermittelt, die daraufhin über eine Kommunikationsverbindung die Ausstattungsdaten an die externe Recheneinrichtung übermittelt und sie somit dieser bereitstellt. Die Kommunikationsverbindung ist bevorzugt kabellos, insbesondere drahtlos, ausgebildet. Die Kommunikationsverbindung kann beispielsweise über ein drahtloses lokales Netzwerk (WLAN für Wireless Local Area Network), eine Bluetooth- Verbindung und/oder ein mobiles Datennetzwerk, beispielsweise basierend auf dem Mobilfunkstandard Long Term Evolution (LTE), Long Term Evolution Advanced (LTE-A), Fifth Generation (5G) oder Sixth Generation (6G), ausgebildet sein. Alternativ oder zusätzlich dazu kann die Kommunikationsverbindung zumindest teilweise kabelgebunden, insbesondere drahtgebunden, ausgebildet sein. Die derartige Kommunikationsverbindung kann über eine Fahrzeugdiagnosesystemschnittstelle des Kraftfahrzeugs erfolgen. Es kann eine zusätzliche externe Recheneinrichtung vorgesehen sein, die zumindest mit der Fahrzeugdiagnosesystemschnittstelle kabelgebunden gekoppelt ist und die dazu ausgebildet ist, eine Kommunikationsverbindung zur externen Recheneinrichtung aufzubauen beziehungsweise zu unterhalten.
Die externe Recheneinrichtung ist beispielsweise ein Server, ein Cloud- Server oder ein Backend. Mittels der externen Recheneinrichtung erfolgt ein Auswählen von allen für das Kraftfahrzeug relevanten Updateeinheiten aus der Softwaregesamtliste. In die Softwaregesamtliste ist für jede potentiell vom Kraftfahrzeug umfasste Steuereinrichtung eine aktuell vorgesehene Softwareversion eingetragen. Bevorzugt weist die Softwaregesamtliste genau eine Softwareversion pro Steuereinrichtung auf. Das Auswählen der relevanten Softwareeinheiten erfolgt unter Berücksichtigung der bereitgestellten Ausstattungsdaten. Mit anderen Worten kann für jede einzelne Steuereinrichtung des Kraftfahrzeugs überprüft werden, ob für diese gemäß der Softwaregesamtliste eine andere Softwareversion vorgesehen ist, als die Softwareversion, die der Ausstattungsliste für diese Steuereinrichtung zu entnehmen ist. Für jede Steuereinrichtung des Kraftfahrzeugs, für die die Softwareversionen der Ausstattungsdaten und der Softwaregesamtliste nicht übereinstimmen, wird die Updateeinheit ausgewählt, das heißt es wird die Software der entsprechenden neuen Softwareversion ausgewählt. Die Updateeinheit ist hierbei eine Komponente eines Gesamtupdates und kann alternativ als Einzelupdate für eine der Steuereinrichtungen des Kraftfahrzeugs bezeichnet werden.
Mittels der externen Recheneinrichtung erfolgt nun ein Ermitteln von Updatereihenfolgedaten durch Anwenden eines Reihenfolgeermittlungskriteriums auf die ausgewählten Updateeinheiten. Die Updatereihenfolgedaten beschreiben eine Reihenfolge eines Installierens der ausgewählten Updateeinheiten im Kraftfahrzeug. Das Reihenfolgeermittlungskriterium ist ein Algorithmus und/oder eine Vorschrift, anhand dessen beziehungsweise deren die externe Recheneinrichtung bestimmt, welche der ausgewählten Updateeinheiten wann im Vergleich zu den anderen Updateeinheiten im Kraftfahrzeug installiert werden soll. In einem einfachen Beispiel wird jeder Updateeinheit beispielsweise eine Positionszahl zuordnen, sodass beispielsweise aufsteigenden Positionszahlen folgend die einzelnen Updateeinheiten nacheinander, das heißt seriell, installiert werden, wenn sie gemäß der Updatereihenfolgedaten im Kraftfahrzeug installiert werden. Das Reihenfolgeermittlungskriterium wird von der externen Recheneinrichtung durchgeführt, wobei als Ergebnis des Durchführens die Updatereihenfolgedaten vorliegen. Mit anderen Worten wird die Updatereihenfolge festgelegt, indem eine zeitliche Abfolge der einzelnen Updateeinheiten ermittelt wird.
Das Verfahren umfasst zudem ein Bereitstellen der ausgewählten Updateeinheiten und der ermittelten Updatereihenfolgedaten für das Kraftfahrzeug. Hierfür werden die ausgewählten Updateeinheiten und die ermittelten Updatereihenfolgedaten über die Kommunikationsverbindung von der externen Recheneinrichtung an das Kraftfahrzeug übermittelt. Die ausgewählten Updateeinheiten und die ermittelten Updatereihenfolgedaten können beispielsweise als Updatepaket oder als Updateordner zusammengefasst übermittelt werden. Die Updateeinheiten sind hierbei derart zu verstehen, dass sie die entsprechende Software für das entsprechende Update der jeweiligen Steuereinrichtung aufweisen. Mit anderen Worten umfassen die Updateeinheiten jeweils Softwarecode für die jeweilige Steuereinrichtung, für die eine neue Softwareversion vorgesehen ist.
Mittels des erfindungsgemäßen Verfahrens wird erreicht, dass ein zuverlässiges Update für das Kraftfahrzeug bereitgestellt wird, das nur die Updateeinheiten umfasst, die tatsächlich im Kraftfahrzeug installiert werden sollten und das zudem vorgibt, wie besonders sinnvoll und zuverlässig die Reihenfolge des Installierens der Updateeinheiten erfolgen sollte. Hierdurch kann beispielsweise eine Abhängigkeit der Installation einer Updateeinheit von der Installation einer anderen Updateeinheit berücksichtigt werden, falls eine derartige Information vom Reihenfolgeermittlungskriterium berücksichtigt wird. Insgesamt kann eine Vielzahl von möglichen Voraussetzungen an die Updatereihenfolge berücksichtigt werden, indem das Reihenfolgeermittlungskriterium entsprechend ausgestaltet wird.
Zu der Erfindung gehören Ausführungsformen, durch die sich zusätzliche Vorteile ergeben.
Ein Ausführungsbeispiel sieht vor, dass die bereitgestellten Updateeinheiten in der Reihenfolge gemäß den bereitgestellten Updatereihenfolgedaten im Kraftfahrzeug installiert werden. Bevorzugt werden also nicht nur die Informationen, die benötigt werden, um das Update prinzipiell im Kraftfahrzeug durchführen zu können, bereitgestellt, das heißt die ausgewählten Updatedaten und die ermittelten Updatereihenfolgedaten, sondern es wird zudem tatsächlich das vorgesehene Update im Kraftfahrzeug installiert. Hierfür können beispielsweise im Kraftfahrzeug selbst die einzelnen Updateeinheiten ihren jeweiligen Steuereinrichtungen zugeordnet werden, sodass, beispielsweise von der zentralen Steuereinrichtung initiiert oder von den jeweiligen einzelnen Steuereinrichtungen selbst durchgeführt, die jeweiligen Updateeinheiten gemäß den Updatereihenfolgedaten installiert werden. Alternativ ausgedrückt können die Steuereinrichtungen auf Basis der bereitgestellten Updateeinheiten gemäß der Reihenfolge geflasht oder geupdated werden. Letztendlich kann als Ergebnis des Verfahrens erreicht sein, dass die Steuereinrichtungen des Kraftfahrzeugs alle auf einen Softwarestand gemäß der Softwaregesamtliste gebracht wurden.
Ein weiteres Ausführungsbeispiel sieht vor, dass die Updatereihenfolgedaten vorgeben, ob mehrere der bereitgestellten Updateeinheiten und wenn ja, welche der Updateeinheiten parallel installiert werden. Es ist also nicht zwangsläufig nötig, dass die einzelnen Updateeinheiten seriell installiert werden, sondern mittels des Reihenfolgeermittlungskriteriums kann festgestellt werden, welche der Updateeinheiten zeitgleich im Kraftfahrzeug installiert werden können, beispielsweise da die entsprechenden Steuereinrichtungen nicht voneinander abhängende Prozesse und/oder Services bereitstellen. Hierdurch kann eine Installationszeitdauer für das Installieren der Updateeinheiten reduziert werden, da immer, falls möglich, zeitgleich mehrere Updateeinheiten gemäß der Updatereihenfolgedaten installiert werden. Dies führt zu einem besonders zeitsparsamen Updaten der Steuereinrichtungen.
Ferner sieht es ein Ausführungsbeispiel vor, dass das Reihenfolgeermittlungskriterium auf einem mathematischen Modell basiert. Das mathematische Modell berücksichtigt für jede der ausgewählten Updateeinheiten zumindest eine von folgenden Informationen: Eine Abhängigkeit von einer Installation zumindest einer anderen Updateeinheit; eine Installationszeitdauer; einen Installationsenergieverbrauch; eine allgemeine Sicherheitsanforderung; eine funktionelle Sicherheitsanforderung; und/oder eine gesetzliche Sicherheitsanforderung. Dem Reihenfolgeermittlungskriterium liegen somit zum Beispiel Informationen über das Installieren der einzelnen Updateeinheiten selbst vor, das heißt deren Abhängigkeit voneinander, benötigte Zeit und/oder benötigte Energie. Die Installationszeitdauer kann alternativ als Updatezeit bezeichnet werden. Der Installationsenergieverbrauch kann als Energiemenge für die Installation der jeweiligen Updateeinheit verstanden werden. Zur Ermittlung des Installationsenergieverbrauchs kann beispielsweise bei einer Testinstallation der Updateeinheit eine maximale Strombelastung in einem Kraftfahrzeug gemessen und daraus der Installationsenergieverbrauch berechnet werden. Die Installationszeitdauer kann ebenfalls bei der Testinstallation bestimmt werden. Letztendlich sind die Installationszeitdauer und der Installationsenergieverbrauch Leistungskennzahlen für die Installation der jeweiligen Updateeinheit.
Die Abhängigkeit der einzelnen Steuereinrichtungen untereinander ist bevorzugt eine funktionale Abhängigkeit, sodass hiervon beispielsweise umfasst wird, ob einzelne Steuereinrichtungen in einem Datenaustausch stehen. Es kann dann vorgesehen sein, dass beispielsweise nicht in einer Steuereinrichtung die Updateeinheit installiert wird, während eine andere Steuereinrichtung kontinuierlich Daten von der Steuereinrichtung erwartet. Denn in dieser Situation kann eine Fehlfunktion der auf die Daten wartenden Steuereinrichtung ausgelöst werden. In einem solchen Fall ist es daher sinnvoll, die miteinander im Zusammenhang stehenden Steuereinrichtungen synchron, das heißt parallel, zu updaten. Alternativ oder zusätzlich dazu können Vorkehrungen getroffen werden, damit zum Beispiel in der die Daten erwartenden Steuereinrichtung keine Fehlfunktion ausgelöst wird.
Die allgemeine Sicherheitsanforderung kann beispielsweise Anforderungen und somit Vorgaben an die Kommunikationsschnittstelle selbst und deren mögliches Update aufweisen. Die Sicherheitsanforderung kann alternativ als Safety-und-Security-relevante Anforderung bezeichnet werden. Handelt es sich beispielsweise bei dem Softwareupdate um ein Update für eine Schnittstelle, die gegebenenfalls Daten von der externen Recheneinrichtung und/oder einer anderen externen Datenquelle empfängt und/oder verarbeitet, können besondere Anforderungen an das Durchführen der entsprechenden Updateeinheit vorliegen, da die Sicherheit des Gesamtsystems des Kraftfahrzeugs betroffen sein kann. Derartige Security-Requests können also mittels der allgemeinen Sicherheitsanforderungen berücksichtigt werden.
Die funktionale Sicherheitsanforderung betrifft beispielsweise Steuereinrichtungen, die redundant ausgebildet sind und die beispielsweise nicht zeitgleich von dem Update betroffen sein sollten. Die funktionelle Sicherheitsanforderung kann beispielsweise vorgeben, dass im Falle von Updates für Steuereinrichtungen für eine Türverriegelung von Türen des Kraftfahrzeugs es nicht möglich ist, dass das Steuergerät von allen beispielsweise vier Türen des Kraftfahrzeugs gleichzeitig installiert wird. Es muss beispielsweise immer zumindest eine Steuereinrichtung für eine der Türen des Kraftfahrzeugs von der Installation der Updateeinheit nicht betroffen sein, sodass beispielsweise die vier Steuereinrichtungen der vier Fahrzeugtüren nur nacheinander, das heißt seriell, vom Update betroffen sein können und nicht gleichzeitig.
Die gesetzliche Anforderung betrifft beispielsweise gesetzlich vorgegebene Verbote und/oder Vorgaben an Updatevorgänge, sodass beispielsweise Stempel und/oder Signaturen vorgegeben und beibehalten werden müssen. Eine derartige gesetzliche Sicherheitsanforderung kann beispielsweise von einer internationalen oder nationalen Institution bestimmt worden sein, wie zum Beispiel das Regularium für automotive Cybersecurity der Wirtschaftskommission für Europa der Vereinten Nationen (UNECE, für United Nations Economic Commission for Europe).
Letztendlich sind im Reihenfolgeermittlungskriterium zahlreiche Informationen gebündelt, anhand derer die Updatereihenfolgedaten ermittelt werden können. Das Reihenfolgeermittlungskriterium liegt somit als mathematisches Modell vor, das auf zumindest einer und bevorzugt auf mehreren der genannten Informationen basiert. Hierdurch kann eine besonders sinnvolle Updatereihenfolge ermittelt werden.
Außerdem sieht es ein Ausführungsbeispiel vor, dass das
Reihenfolgeermittlungskriterium Erfahrungsdaten berücksichtigt. Die Erfahrungsdaten beschreiben zumindest eine Erfahrung, die bei einer Absicherung der jeweiligen Steuereinrichtung des Kraftfahrzeugs und/oder einer Verbundabsicherung der Steuereinrichtung ermittelt wurde. Alternativ oder zusätzlich dazu wurde die Erfahrung als eine Rückmeldung auf vergangene Updates bereitgestellt. Mit anderen Worten kann auf Erfahrungswerte aus der Vergangenheit zurückgegriffen werden und anhand derer das mathematische Modell des Reihenfolgeermittlungskriteriums optimiert und angepasst werden.
Die Absicherung der jeweiligen Steuereinrichtung wird beispielsweise im Rahmen eines zyklischen Tests ermittelt, der für die Freigabe der Steuereinrichtung für den Einbau in einem Kraftfahrzeug benötigt wird. In diesem Rahmen können Anforderungen an Updates geprüft werden, wie beispielsweise ein Bestimmen der Installationszeitdauer und des Installationsenergieverbrauchs. Derartige Absicherungen können auch für einen ganzen Verbund, das heißt beispielsweise für alle in der Softwaregesamtliste genannten Steuereinrichtungen, bestimmt werden. Dies ist dann die Verbundabsicherung. Es können beispielsweise aus der Verbundabsicherung Maximalwerte für die Installationszeitdauer und/oder den Installationsenergieverbrauch für die Updateeinheiten für alle Steuereinrichtungen der Softwaregesamtliste bestimmt werden. Letztendlich können hierdurch Informationen aus der Entwicklung beim Fahrzeughersteller, die im Rahmen von zyklischen Tests bei der Entwicklung und/oder Produktion von Steuereinrichtungen erzeugt werden, dem Reihenfolgeermittlungskriterium bereitgestellt werden, das diese dann berücksichtigen kann. Im Rahmen der Absicherung beziehungsweise Verbundabsicherung kann die oben exemplarisch genannte Testinstallation erfolgen.
Rückmeldungen von bisherigen oder vergangenen Updates können beispielsweise von Werkstätten und/oder sonstigen Testinstallationen bereitgestellt werden. Die Rückmeldungen sind somit zum Beispiel Erfahrungswerte aus vorhergehenden Updatekampagnen. Hierbei werden bevorzugt von einzelnen Kraftfahrzeugen Rückmeldungen gegeben, die beispielsweise vom jeweiligen Kraftfahrzeug an die externe Recheneinrichtung übermittelt werden. Hierdurch lassen sich beispielsweise Informationen dazu entnehmen, welche Abhängigkeiten zwischen den einzelnen Steuereinrichtungen zu berücksichtigen sind und/oder es lässt sich die bei der jeweiligen Absicherung festgestellte Installationszeitdauer und/oder Installationsenergieverbrauch überprüfen, insbesondere bestätigen. Hierdurch kann das Reihenfolgeermittlungskriterium weiter präzisiert werden.
Im Zusammenhang mit den Erfahrungsdaten kann es in einem Ausführungsbeispiel vorgesehen sein, dass die Erfahrungsdaten zyklisch bereitgestellt werden. Es können beispielsweise fest vorgeschriebene Zeitabstände vorgesehen sein, in denen die Erfahrungsdaten bereitgestellt werden. Hierdurch wird sichergestellt, dass die Informationen, die in Form der Erfahrungsdaten bereitgestellt werden, stets aktuell sind.
Gemäß einem weiteren Ausführungsbeispiel ist es vorgesehen, dass die Updatereihenfolgedaten eine Gesamtinstallationszeitdauerinformation aufweisen, die eine voraussichtliche Gesamtzeitdauer einer Installation der ausgewählten Updateeinheiten beschreibt. Die Gesamtinstallationszeitdauerinformation kann mittels Gesamtzeitdauerdaten beschrieben werden, die von den Updatereihenfolgedaten umfasst werden. Es wird nun überprüft, ob die Gesamtinstallationszeitdauerinformation, das heißt die voraussichtliche Gesamtzeitdauer der Installation des Updates, kleiner als ein vorgegebener Zeitdauergrenzwert ist. Falls dies der Fall ist, insbesondere nur falls dies der Fall ist, werden die ausgewählten Updateeinheiten und die ermittelten Updatereihenfolgedaten bereitgestellt und/oder deren Installation wird zugelassen. Das Überprüfen erfolgt insbesondere vor dem Bereitstellen der ausgewählten Updateeinheiten und der ermittelten Updatereihenfolgedaten. Letztendlich kann es vorgesehen sein, dass das Update nur dann bereitgestellt beziehungsweise dessen Installation ermöglicht wird, wenn die Gesamtzeitdauer des Installierens der Updateeinheiten des Updates nicht den vorgegebenen Zeitdauergrenzwert überschreitet. Hierdurch wird sichergestellt, dass das Update nicht mehr Zeit benötigt, als beispielsweise aufgrund eines gleichzeitigen Betriebs des Kraftfahrzeugs vorgegeben ist. Es kann beispielsweise der Fall sein, dass das Installieren der Updateeinheiten während einer Wartepause vor einer Ampeleinrichtung und somit während einer Fahrt des Kraftfahrzeugs erfolgen soll. Da eine derartige Wartedauer typischerweise nur wenige Sekunden oder Minuten lang ist, kann ein entsprechend kurzer Zeitdauergrenzwert vorgegeben sein. Hierdurch wird verhindert, dass durch das Update das Kraftfahrzeug über eine längere Zeit beispielsweise nicht fahrtüchtig ist, als es gewünscht ist. Falls die Gesamtinstallationszeitdauerinformation größer als oder gleich des vorgegebenen Zeitdauergrenzwerts ist, kann es möglich sein, dass die ermittelten Updatereihenfolgedaten sowie die ausgewählten Updateeinheiten dennoch bereitgestellt werden, jedoch ein Hinweis im Kraftfahrzeug ausgegeben wird, der über die voraussichtliche Überschreitung des Zeitdauergrenzwerts beim Installieren des Updates informiert. Der Nutzer kann daraufhin beispielsweise zu einem beliebigen Zeitpunkt dennoch die Installation des Updates erlauben, obwohl der Zeitdauergrenzwert überschritten ist. Hierdurch wird letztendlich ein besonders benutzerfreundliches Update für das Kraftfahrzeug bereitgestellt.
Außerdem kann es ein weiteres Ausführungsbeispiel vorsehen, dass die Updatereihenfolgedaten eine Gesamtenergieverbrauchsinformation aufweisen, die einen voraussichtlichen gesamten Installationsenergieverbrauch einer Installation der ausgewählten Updateeinheiten beschreibt. Die Gesamtenergieverbrauchsinformation kann in Form von Gesamtenergieverbrauchsdaten vorliegen, die von den Updatereihenfolgedaten umfasst sein können. Es wird daraufhin überprüft, ob der voraussichtliche gesamte Installationsenergieverbrauch gemäß der Gesamtenergieverbrauchsinformation kleiner als ein vorgegebener Energieverbrauchsgrenzwert ist. Falls dies der Fall ist, insbesondere nur falls dies der Fall ist, werden die ausgewählten Updateeinheiten und die ermittelten Updatereihenfolgedaten bereitgestellt und/oder deren Installation wird zugelassen. Insbesondere erfolgt das Überprüfen vor dem Bereitstellen der ausgewählten Updateeinheiten und der ermittelten Updatereihenfolgedaten für das Kraftfahrzeug. Hierbei kann, falls das Überprüfen nicht erfolgreich ist, also falls die Gesamtenergieverbrauchsinformation größer als oder gleich dem Energieverbrauchsgrenzwert ist, ein Hinweis über das voraussichtliche Überschreiten des Energieverbrauchsgrenzwerts im Kraftfahrzeug ausgegeben werden. Hierdurch kann sichergestellt werden, dass beispielsweise das Update nicht mehr Energie benötigt, als hierfür vorgesehen ist und beispielsweise nicht eine 12-Volt-Batterie des Kraftfahrzeugs, die beispielsweise Energie für die Installation des Updates bereitstellt, entleert wird, während das Update installiert wird. Hierdurch wird mittels einer zusätzlichen Überprüfung gewährleistet, dass die ermittelte Updatereihenfolge für die ausgewählten Updateeinheiten sinnvoll ist, da diese das Update für das Kraftfahrzeug derart bereitstellt, dass der Installationsenergieverbrauch für das gesamte Update betrachtet nicht den vorgegebenen Grenzwert überschreitet.
Ferner kann es gemäß einem Ausführungsbeispiel vorgesehen sein, dass Ladezustandsdaten ermittelt werden. Die Ladezustandsdaten beschreiben einen Ladezustand einer Batterie des Kraftfahrzeugs. Die Batterie des Kraftfahrzeugs ist hierbei typischerweise die 12-Volt-Batterie des Kraftfahrzeugs. Die Batterie ist somit beispielsweise keine Hochvolt-Batterie, die zur Energieversorgung eines Elektromotors und somit eines elektrischen Antriebs des Kraftfahrzeugs ausgebildet ist. Der Energieverbrauchsgrenzwert wird abhängig von den ermittelten Ladezustandsdaten festgelegt. Wird beispielsweise festgestellt, dass die Batterie des Kraftfahrzeugs schon annähernd entleert ist, kann dies Auswirkungen auf das Bereitstellen der ausgewählten Updateeinheiten und der ermittelten Updatereihenfolgedaten für das Kraftfahrzeug und/oder deren Installation haben, sodass nur dann, wenn die Batterie des Kraftfahrzeugs die Installation des Updates tatsächlich zulässt, dieses beispielsweise überhaupt bereitgestellt und/oder installiert wird. Die Ladezustandsdaten werden hierfür im Kraftfahrzeug ermittelt und beispielsweise über die Kommunikationsverbindung an die externe Recheneinrichtung übermittelt. Das Übermitteln an die externe Recheneinrichtung kann automatisch, das heißt beispielsweise kontinuierlich, und/oder auf eine Anfrage der externen Recheneinrichtung hin erfolgen. Hierdurch kann eine zuverlässige Absicherung bereitgestellt sein, um zu verhindern, dass das Update die Energieversorgung des Kraftfahrzeugs negativ beeinträchtigt.
Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
Ein weiterer Aspekt der Erfindung betrifft ein System. Das System umfasst ein Kraftfahrzeug und eine externe Recheneinrichtung. Das System ist dazu ausgebildet, das oben beschriebene Verfahren durchzuführen. Das System kann alternativ als Anordnung umfassend ein Kraftfahrzeug und eine externe Recheneinrichtung bezeichnet werden. In diesem Fall ist die Anordnung dazu ausgebildet, das oben beschriebene Verfahren durchzuführen.
Zu der Erfindung gehören auch Weiterbildungen des erfindungsgemäßen Systems, die Merkmale aufweisen, wie sie bereits im Zusammenhang mit den Weiterbildungen des erfindungsgemäßen Verfahrens beschrieben worden sind. Aus diesem Grund sind die entsprechenden Weiterbildungen hier nicht noch einmal beschrieben.
Das Kraftfahrzeug ist bevorzugt als Kraftwagen, insbesondere als Personenkraftwagen oder Lastkraftwagen, oder als Personenbus oder Motorrad ausgestaltet.
Zu der Erfindung gehören auch die Steuereinrichtungen für das Kraftfahrzeug und die externe Recheneinrichtung. Die jeweilige Steuereinrichtung kann eine Datenverarbeitungsvorrichtung oder eine Prozessoreinrichtung aufweisen, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Die Prozessoreinrichtung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Prozessoreinrichtung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessoreinrichtung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessoreinrichtung gespeichert sein.
Als eine weitere Lösung umfasst die Erfindung auch ein computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch einen Computer oder einen Computerverbund diesen veranlassen, eine Ausführungsform des erfindungsgemäßen Verfahrens auszuführen. Das Speichermedium kann z.B. zumindest teilweise als ein nicht-flüchtiger Datenspeicher (z.B. als eine Flash-Speicher und/oder als SSD - solid state drive) und/oder zumindest teilweise als ein flüchtiger Datenspeicher (z.B. als ein RAM - random access memory) ausgestaltet sein. Durch den Computer oder Computerverbund kann eine Prozessorschaltung mit zumindest einem Mikroprozessor bereitgestellt sein. Die Befehle können als Binärcode oder Assembler und/oder als Quellcode einer Programmiersprache (z.B. C) bereitgestellt sein.
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen. Die Erfindung umfasst also auch Realisierungen, die jeweils eine Kombination der Merkmale mehrerer der beschriebenen Ausführungsformen aufweisen, sofern die Ausführungsformen nicht als sich gegenseitig ausschließend beschrieben wurden.
Im Folgenden sind Ausführungsbeispiele der Erfindung beschrieben. Hierzu zeigt:
Fig. 1 eine schematische Darstellung eines Systems umfassend ein Kraftfahrzeug und eine externe Recheneinrichtung; und Fig. 2 in schematischer Darstellung einen Signalflussgraphen für ein Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug.
Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden. Daher soll die Offenbarung auch andere als die dargestellten Kombinationen der Merkmale der Ausführungsformen umfassen. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
In den Figuren bezeichnen gleiche Bezugszeichen jeweils funktionsgleiche Elemente.
In Fig. 1 ist ein Kraftfahrzeug 1 skizziert. Es ist ferner eine externe Recheneinrichtung 2 skizziert, die beispielsweise als Server oder Backend ausgebildet ist. Das Kraftfahrzeug 1 und die Recheneinrichtung 2 werden von einem System 3 umfasst. Das System 3 kann alternativ als Anordnung bezeichnet werden.
Das Kraftfahrzeug 1 weist mehrere Steuereinrichtungen 4 auf. Die einzelnen Steuereinrichtungen 4 können dazu ausgebildet sein, eine Antriebseinrichtung des Kraftfahrzeugs 1 , das heißt beispielsweise einen Motor des Kraftfahrzeugs 1 , anzusteuern, eine Komfortfunktion bereitzustellen, wie beispielsweise eine Steuerung einer Klimaanlage und/oder einer Multimediaeinrichtung, und/oder eine andere Funktion oder einen anderen Service des Kraftfahrzeugs 1 bereitzustellen, wie beispielsweise die Steuerung einer Lichteinrichtung, eine Fernsteuerung für eine Türschließeinrichtung und/oder eine automatische Fensteröffnungseinrichtung. Mit anderen Worten umfasst das Kraftfahrzeug 1 für verschiedene Funktionen und/oder Services einzelne Steuereinrichtungen 4. Die jeweilige Steuereinrichtung 4 kann eine Recheneinrichtung sein, die jedoch anders als die externe Recheneinrichtung 2 eine interne Einrichtung des Kraftfahrzeugs 1 ist. Es ist ferner eine zentrale Steuervorrichtung 5 für das Kraftfahrzeug 1 skizziert, die beispielsweise Informationen von den einzelnen Steuereinrichtungen 4 empfangen und sammeln kann. Über die Steuervorrichtung 5 kann zum Beispiel ein Datenaustausch mit der externen Recheneinrichtung 2 gesteuert werden.
Das Kraftfahrzeug 1 weist eine Kommunikationsschnittstelle 6 auf. Ferner weist die externe Recheneinrichtung 2 eine Kommunikationsschnittstelle 6 auf. Zwischen den beiden Kommunikationsschnittstellen 6 kann eine kabellose, insbesondere drahtlose Kommunikationsverbindung 7 aufgebaut und beziehungsweise aufrecht erhalten werden. Alternativ oder zusätzlich dazu kann die Kommunikationsverbindung zumindest teilweise kabelgebunden, insbesondere drahtgebunden, ausgebildet sein. Über die Kommunikationsverbindung 7 können beispielsweise Daten zwischen dem Kraftfahrzeug 1 und der externen Recheneinrichtung 2 übermittelt, insbesondere ausgetauscht werden.
Das Kraftfahrzeug 1 weist zudem eine Batterie 8 auf, zu der Ladezustandsdaten 9 vorliegen. Die Ladezustandsdaten 9 beschreiben einen Ladezustand der Batterie 8 des Kraftfahrzeugs 1 . Die Ladezustandsdaten 9 beziehen sich hierbei beispielsweise auf eine 12-Volt- Batterie als Batterie 8 und nicht beispielsweise auf eine Hochvolt-Batterie, wie sie zum Betreiben eines Elektromotors als Antriebseinrichtung des Kraftfahrzeugs 1 benötigt werden würde.
Fig. 2 zeigt ein Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug 1. In einem Verfahrensschritt S1 erfolgt ein Bereitstellen von Ausstattungsdaten 10 vom Kraftfahrzeug 1 an die externe Recheneinrichtung
2 über die Kommunikationsverbindung 7. Die Ausstattungsdaten 10 beschreiben, mit welchen Steuereinrichtungen 4 das Kraftfahrzeugs 1 ausgestattet ist und mit welcher Softwareversion die jeweilige Steuereinrichtung 4 aktuell betrieben wird. Hier sind exemplarisch fünf Steuereinrichtungen 4 in Fig. 1 skizziert, sodass beispielsweise das Kraftfahrzeug 1 im Rahmen der Ausstattungsdaten 10 die Bezeichnungen dieser fünf Steuereinrichtungen 4 sowie deren aktuelle Softwareversion bereitstellen würde. Mit anderen Worten weisen die Ausstattungsdaten 10 Informationen über eine aktuelle Hardware und Software des Kraftfahrzeugs
1 auf.
In einem Verfahrensschritt S2 erfolgt mittels der externen Recheneinrichtung
2 ein Auswahlen von allen für das Kraftfahrzeug 1 relevanten Updateeinheiten 12 aus einer Softwaregesamtliste 11 unter Berücksichtigung der bereitgestellten Ausstattungsdaten 10. In die Softwaregesamtliste 11 ist für jede potentiell vom Kraftfahrzeug 1 umfasste Steuereinrichtung 4 eine aktuell vorgesehene Softwareversion eingetragen. Der Softwaregesamtliste
11 ist somit eine Liste der gesamten im Kraftfahrzeug 1 potentiell installierten Software zu entnehmen, die für jede mögliche Hardware die aktuelle Software beschrieben mittels der entsprechenden Softwareversion umfasst.
Das Kraftfahrzeug 1 umfasst nicht zwangsläufig alle Steuereinrichtungen 4, die in der Softwaregesamtliste 11 gelistet sind, sondern beispielsweise nur eine Auswahl von diesen. Beispielsweise kann die Softwaregesamtliste 11 80 Steuereinrichtungen 4 listen, wobei das Kraftfahrzeug 1 beispielsweise nur fünf oder eine beliebige andere Anzahl zwischen 1 und 80 dieser Steuereinrichtungen 4 tatsächlich umfasst.
Für die jeweilige Steuereinrichtung 4 des Kraftfahrzeugs 1 ist nur dann eine Updateeinheit 12 relevant, wenn diese Steuereinrichtung 4 gemäß den Ausstattungsdaten 10 mit einer anderen Softwareversion betrieben wird, als es die Softwaregesamtliste 11 für diese vorsieht. Im hier skizzierten Beispiel werden daher zwei Updateeinheiten 12 ausgewählt, da beispielsweise drei der fünf exemplarischen Steuereinrichtungen 4 auf einem Softwarestand sind, das heißt eine Softwareversion aufweisen, wie sie gemäß der Softwaregesamtliste 11 vorgesehen ist und somit nur für zwei der Steuereinrichtungen 4 jeweilige Updateeinheiten 12 vorliegen. Die Updateeinheiten 12 umfassen den für das Updaten der entsprechenden Steuereinrichtung 4 benötigten Softwarecode.
In einem Verfahrensschritt S3 wird mittels der externen Recheneinrichtung 2 ein Reihenfolgeermittlungskriterium 13 auf die ausgewählten Updateeinheiten 12 angewendet. Hierbei werden Updatereihenfolgedaten 14 ermittelt, die eine Reihenfolge eines Installierens der ausgewählten Updateeinheiten 12 im Kraftfahrzeug 1 beschreiben. In diesem Beispiel wird also festgestellt, welche der beiden Updateeinheiten 12 zuerst im Kraftfahrzeug 1 installiert werden sollte und/oder ob beide beispielsweise parallel und somit zeitgleich installiert werden könnten. Im Falle von mehreren Updateeinheiten 12 kann hierbei eine detaillierte Reihenfolge bestimmt werden. Das Reihenfolgeermittlungskriterium 13 basiert auf einem mathematischen Modell. Das mathematische Modell berücksichtigt für jede der ausgewählten Updateeinheiten 12 zumindest eine von folgenden Informationen 15: Eine Abhängigkeit von einer Installation zumindest einer anderen Updateeinheit 12, eine Installationszeitdauer, einen Installationsenergieverbrauch, eine allgemeine Sicherheitsanforderung, eine funktionelle Sicherheitsanforderung und/oder eine gesetzliche Sicherheitsanforderung.
Das Reihenfolgeermittlungskriterium 13 kann alternativ oder zusätzlich dazu Erfahrungsdaten 16 berücksichtigen, die zumindest eine Erfahrung beschreiben, die bei einer Absicherung der jeweiligen Steuereinrichtung 4 des Kraftfahrzeugs 1 und/oder einer Verbundabsicherung der Steuereinrichtungen 4, das heißt beispielsweise aller Steuereinrichtungen 4, die in der Softwaregesamtliste 11 gelistet werden, ermittelt wurden und/oder als eine Rückmeldung auf vergangene Updates bereitgestellt wurden. Die Erfahrungsdaten 16 können beispielsweise zyklisch bereitgestellt werden, sodass das Reihenfolgeermittlungskriterium 13 zyklisch auf Basis der Erfahrungsdaten 16 überarbeitet werden kann. Die Erfahrungsdaten 16 können die zuvor genannten Informationen 15 zumindest teilweise betreffen, das heißt, sie können beispielsweise eine Installationszeitdauer für eine Updateeinheit 12 betreffen. In einem Verfahrensschritt S4 erfolgt ein Bereitstellen der ausgewählten Updateeinheiten 12 und der ermittelten Updatereihenfolgedaten 14 für das Kraftfahrzeug 1. Hierfür können diese über die Kommunikationsverbindung 7 von der externen Recheneinrichtung 2 an das Kraftfahrzeug 1 übermittelt werden. Die ausgewählten Updateeinheiten 12 zusammen mit den ermittelten Updatereihenfolgedaten 14 können als Updatepaket 17 oder als Update bezeichnet werden. Dem Kraftfahrzeug 1 wird somit ein Updatepaket 17 bereitgestellt, in dem die für die einzelnen Steuereinrichtungen 4 benötigten Softwareupdates (Updateeinheiten 12) sowie Informationen zur Reihenfolge der Installation der einzelnen Softwareupdates (Updatereihenfolgedaten 14) zu entnehmen sind.
In einem Verfahrensschritt S5 ist es vorgesehen, dass die bereitgestellten Updateeinheiten 12 in der Reihenfolge gemäß der bereitgestellten Updatereihenfolgedaten 14 im Kraftfahrzeug 1 installiert werden. Dies kann beispielsweise durch entsprechende Ansteuerung der einzelnen Steuereinrichtungen 4 mittels der zentralen Steuervorrichtung 5 erfolgen. Die einzelnen Updateeinheiten 12 werden, sofern dies möglich und sinnvoll ist, parallel installiert und ansonsten seriell.
In einem Verfahrensschritt S6 kann überprüft werden, ob eine voraussichtliche Gesamtzeitdauer gemäß einer Gesamtinstallationszeitdauerinformation 18 kleiner als ein vorgegebener Zeitdauergrenzwert 19 ist. Die Updatereihenfolgedaten 14 weisen hierbei die Gesamtinstallationszeitdauerinformation 18 auf, die eine voraussichtliche Gesamtzeitdauer einer Installation der ausgewählten Updateeinheiten 12 beschreibt. Nur falls dies der Fall ist beziehungsweise immer dann, falls dies der Fall ist, können der Verfahrensschritt S4 und/oder der Verfahrensschritt S5 erfolgen. Falls nach dem erfolgreichen Überprüfen der Verfahrensschritt S5 erfolgt, wird vor dem Durchführen des Verfahrensschritts S6 auch der Verfahrensschritt S4 durchgeführt. Alternativ oder zusätzlich dazu kann in einem Verfahrensschritt S7 überprüft werden, ob ein voraussichtlicher gesamter Installationsenergieverbrauch gemäß einer Gesamtenergieverbrauchsinformation 20 kleiner ist als ein vorgegebener Energieverbrauchsgrenzwert 21 . Hierbei weisen die Updatereihenfolgedaten 14 die Gesamtenergieverbrauchsinformation 20 auf, die einen voraussichtlichen Gesamtinstallationsverbrauch einer Installation der ausgewählten Updateeinheiten 12 beschreibt. Falls das Überprüfen erfolgreich ist, können der Verfahrensschritt S4 und/oder der Verfahrensschritt S5 erfolgen. Falls die Verfahrensschritte S7 und/oder S6 nicht erfolgreich sind, kann beispielsweise der Verfahrensschritt S2 erneut erfolgen, das heißt es können beispielsweise weniger Updateeinheiten 12 ausgewählt werden und/oder in einem erneuten Durchführen des Verfahrensschritts S3 eine andere Updatereihenfolge und somit andere Updatereihenfolgedaten 14 ermittelt werden. Beim Vorgeben des Energieverbrauchsgrenzwerts 21 können die Ladezustandsdaten 9 berücksichtigt werden, sodass beispielsweise der Energieverbrauchsgrenzwert 21 abhängig vom aktuellen Ladezustand gemäß den Ladezustandsdaten 9 sein kann. Die Verfahrensschritte S6 und S7 können mittels der externen Recheneinrichtung 2 und/oder mittels der Steuervorrichtung 5 durchgeführt werden.
Insgesamt zeigen die Beispiele eine modellbasierte Berechnung von Updateordern (Flashreihenfolge) beim Verbundupdate vom Kraftfahrzeug 1 . Die Erstellung der Updateorder, das heißt der Updatereihenfolgedaten 14, erfolgt über einen modellbasierten Lösungsansatz. Dabei sind alle flashrelevanten, funktionalen Abhängigkeiten von Steuereinrichtungen 4 untereinander, Safefy-and-Security-relevante Anforderungen, Leistungskennzahlen wie Updatezeit, maximale Strombelastung und Energiemenge während des Updates sowie gesetzliche Anforderungen in einem mathematischen Modell beschrieben, das für eine automatisierte Berechnung der Updateorder genutzt wird. Dieses mathematische Modell liegt hier in Form des Reihenfolgeermittlungskriteriums 13 vor. Erfahrungswerte aus der Absicherung von Einzelsteuergeräten, aus der Verbundabsicherung und/oder aus Rückmeldungen von Updatekampagnen aus dem Feld fließen zur Pflege beziehungsweise Aktualisierung zyklisch in das Datenmodell, das heißt in das mathematische Modell, ein. Es werden also die Erfahrungsdaten 16 vom Reihenfolgeermittlungskriterium 13 berücksichtigt. Als Input für das Datenmodell kommt eine Datenbank zur Anwendung, in der die Erfassung der relevanten Artefakte (Einzelsteuergerätupdates, Stromwerte, Energiemengen) aus den vorgelagerten Mess- und Absicherungsvorgängen an Einzelsteuergeräten beziehungsweise Verbundprüfungen abgebildet ist, das heißt es werden die Informationen 15 für das Reihenfolgeermittlungskriterium 13 berücksichtigt.
Die technische Umsetzung basiert auf einer Konzerndatenbank, die mit empirischen Werten wie Einzelsteuergeräteflashzeiten, Einzelsteuergeräteenergiemengen, Strommessungen und so weiter sowohl aus Messungen an einem Prüfplatz als auch aus realen Updatevorgängen von Kunden (Erfahrungsdaten 16) befüllt wird, um das mathematische Datenmodell zu bedienen. Das Datenmodell bildet anhand mathematischer und logischer Zusammenhänge die Anforderung, Abhängigkeit und/oder relevanten Gesetzesvorgaben bei der Berechnung einer Flashreihenfolge beim Verbundupdate ab, das heißt es können die Updatereihenfolgedaten 14 mittels des Reihenfolgeermittlungskriteriums 13 ermittelt werden. Über einen Server (externe Recheneinrichtung 2) wird die Datenberechnung bei Erstellung einer neuen Baseline, das heißt einer neuen Softwaregesamtliste 11 , angestoßen und die Ergebnisse aus der Berechnung anhand des Datenmodells abgerufen. Über eine geeignete Visualisierung können diese realisierten und paralysierten Updatevorgänge für den Bediener leicht lesbar dargestellt werden. Ebenso können kritische Pfade, erwartete Gesamtupdatezeiten sowie voraussichtlich benötigte Energiemengen berechnet werden. Basierend auf diesen Werten können im Vorfeld der Freigabe einer Softwaregesamtliste 11 eine Aussage bezüglich Einhaltung der gesetzlichen Leistungskennzahlen getroffen werden. Dies wird beispielsweise durch die Überprüfungsschritte S6 und S7 zumindest teilweise realisiert.

Claims

PATENTANSPRÜCHE:
1 . Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug (1 ), umfassend:
- Bereitstellen (S1 ) von Ausstattungsdaten (10), die beschreiben, mit welchen Steuereinrichtungen (4) das Kraftfahrzeug (1 ) ausgestattet ist und mit welcher Softwareversion die jeweilige Steuereinrichtung (4) aktuell betrieben wird, für eine externe Recheneinrichtung (2);
- mittels der externen Recheneinrichtung (2), Auswahlen (S2) von allen für das Kraftfahrzeug (1 ) relevanten Updateeinheiten (12) aus einer Softwaregesamtliste (11 ), in die für jede potentiell vom Kraftfahrzeug (1 ) umfasste Steuereinrichtung (4) eine aktuell vorgesehene Softwareversion eingetragen ist, unter Berücksichtigung der bereitgestellten Ausstattungsdaten (10);
- mittels der externen Recheneinrichtung (2), Ermitteln (S3) von Updatereihenfolgedaten (14), die eine Reihenfolge eines Installierens der ausgewählten Updateeinheiten (12) im Kraftfahrzeug (1 ) beschreiben, durch Anwenden eines Reihenfolgeermittlungskriteriums (13) auf die ausgewählten Updateeinheiten (12); und
- Bereitstellen (S4) der ausgewählten Updateeinheiten (12) und der ermittelten Updatereihenfolgedaten (14) für das Kraftfahrzeug (1 ).
2. Verfahren nach Anspruch 1 , wobei die bereitgestellten Updateeinheiten
(12) in der Reihenfolge gemäß der bereitgestellten Updatereihenfolgedaten (14) im Kraftfahrzeug (1 ) installiert werden (S5).
3. Verfahren nach Anspruch 2, wobei die Updatereihenfolgedaten (14) vorgeben, ob mehrere der bereitgestellten Updateeinheiten (12) und wenn ja welche der Updateeinheiten (12) parallel installiert werden. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Reihenfolgeermittlungskriterium (13) auf einem mathematischen Modell basiert, das für jede der ausgewählten Updateeinheiten (12) zumindest eine von folgenden Informationen (15) berücksichtigt:
- eine Abhängigkeit von einer Installation zumindest einer anderen Updateeinheit (12);
- eine Installationszeitdauer;
- einen Installationsenergieverbrauch;
- eine allgemeine Sicherheitsanforderung;
- eine funktionelle Sicherheitsanforderung; und/oder
- eine gesetzliche Sicherheitsanforderung. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Reihenfolgeermittlungskriterium (13) Erfahrungsdaten (16) berücksichtigt, die zumindest eine Erfahrung beschreiben, die bei einer Absicherung der jeweiligen Steuereinrichtung (4) des Kraftfahrzeugs (1 ) und/oder einer Verbundabsicherung der Steuereinrichtungen (4) ermittelt und/oder als eine Rückmeldung auf vergangene Updates bereitgestellt wurde. Verfahren nach Anspruch 5, wobei die Erfahrungsdaten (16) zyklisch bereitgestellt werden. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Updatereihenfolgedaten (14) eine Gesamtinstallationszeitdauerinformation (18) aufweisen, die eine voraussichtliche Gesamtzeitdauer einer Installation der ausgewählten Updateeinheiten (12) beschreibt, und überprüft wird (S6), ob die Gesamtinstallationszeitdauerinformation (18) kleiner als ein vorgegebener Zeitdauergrenzwert (19) ist, wobei falls dies der Fall ist, die ausgewählten Updateeinheiten (12) und die ermittelten Updatereihenfolgedaten (14) bereitgestellt werden und/oder deren Installation zugelassen wird. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Updatereihenfolgedaten (14) eine Gesamtenergieverbrauchsinformation (20) aufweisen, die einen voraussichtlichen gesamten Installationsenergieverbrauch einer Installation der ausgewählten Updateeinheiten (12) beschreibt, und überprüft wird (S7), ob die Gesamtenergieverbrauchsinformation (20) kleiner als ein vorgegebener Energieverbrauchsgrenzwert (21 ) ist, wobei falls dies der Fall ist, die ausgewählten Updateeinheiten (12) und die ermittelten Updatereihenfolgedaten (14) bereitgestellt werden und/oder deren Installation zugelassen wird. Verfahren nach Anspruch 8, wobei Ladezustandsdaten (9), die einen Ladezustand einer Batterie (8) des Kraftfahrzeugs (1 ) beschreiben, ermittelt werden und der Energieverbrauchsgrenzwert (21 ) abhängig von den ermittelten Ladezustandsdaten (9) festgelegt wird. System (3) umfassend ein Kraftfahrzeug (1 ) und eine externe Recheneinrichtung (2), wobei das System (3) dazu ausgebildet ist, ein Verfahren nach einem der vorhergehenden Ansprüche durchzuführen.
PCT/EP2023/068011 2022-07-27 2023-06-30 Verfahren zum bereitstellen eines updates für ein kraftfahrzeug WO2024022732A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022118843.4 2022-07-27
DE102022118843.4A DE102022118843A1 (de) 2022-07-27 2022-07-27 Verfahren zum Bereitstellen eines Updates für ein Kraftfahrzeug

Publications (1)

Publication Number Publication Date
WO2024022732A1 true WO2024022732A1 (de) 2024-02-01

Family

ID=87312159

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/068011 WO2024022732A1 (de) 2022-07-27 2023-06-30 Verfahren zum bereitstellen eines updates für ein kraftfahrzeug

Country Status (2)

Country Link
DE (1) DE102022118843A1 (de)
WO (1) WO2024022732A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019021064A1 (en) 2017-07-25 2019-01-31 Aurora Labs Ltd CONSTRUCTION OF SOFTWARE DELTA UPDATES FOR VEHICLE ECU SOFTWARE AND TOOL-BASED ANOMALY DETECTION
WO2019182509A1 (en) * 2018-03-19 2019-09-26 Huawei International Pte. Ltd. Method and apparatus for updating devices in a remote network
DE112017006978T5 (de) 2017-02-01 2019-10-10 Sumitomo Electric Industries, Ltd. Steuervorrichtungen, Programmaktualisierungsverfahren und Computerprogramm
DE102019212664A1 (de) 2018-11-16 2020-05-20 Hyundai Motor Company Vorrichtung zum Bereitstellen einer Aktualisierung und Computerlesbares Speichermedium

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009018761A1 (de) 2009-04-27 2010-10-28 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Aktualisierung von Softwarekomponenten
US9229704B2 (en) 2014-04-01 2016-01-05 Ford Global Technologies, Llc Smart vehicle reflash with battery state of charge (SOC) estimator
DE112017006980T5 (de) 2017-02-01 2019-10-17 Sumitomo Electric Industries, Ltd. Steuereinrichtung, Programmaktualisierungsverfahren und Computerprogramm

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112017006978T5 (de) 2017-02-01 2019-10-10 Sumitomo Electric Industries, Ltd. Steuervorrichtungen, Programmaktualisierungsverfahren und Computerprogramm
WO2019021064A1 (en) 2017-07-25 2019-01-31 Aurora Labs Ltd CONSTRUCTION OF SOFTWARE DELTA UPDATES FOR VEHICLE ECU SOFTWARE AND TOOL-BASED ANOMALY DETECTION
WO2019182509A1 (en) * 2018-03-19 2019-09-26 Huawei International Pte. Ltd. Method and apparatus for updating devices in a remote network
DE102019212664A1 (de) 2018-11-16 2020-05-20 Hyundai Motor Company Vorrichtung zum Bereitstellen einer Aktualisierung und Computerlesbares Speichermedium

Also Published As

Publication number Publication date
DE102022118843A1 (de) 2024-02-01

Similar Documents

Publication Publication Date Title
EP3368379B1 (de) Steuergeräte-update im kraftfahrzeug
DE102011100106A1 (de) System zur Diagnose einer Komponente in einem Fahrzeug
EP3704573B1 (de) Verfahren zum durchführen eines softwareupdates in einem steuergerät eines kraftfahrzeugs sowie entsprechend eingerichtetes kraftfahrzeug
EP3709166B1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
DE102017217668A1 (de) Verfahren und zentrale Datenverarbeitungsvorrichtung zum Aktualisieren von Software in einer Vielzahl von Fahrzeugen
EP3353650B1 (de) System und verfahren zur verteilung und/oder aktualisierung von software in vernetzten steuereinrichtungen eines fahrzeugs
DE10140519A1 (de) Kommunikationsverfahren und Kommunikationsmodul
EP1804144A1 (de) Überprüfung des Steuerprogramms eines Steuergerätes für eine Maschine
DE102008040796A1 (de) Verfahren zur Ermittlung eines Fehlers in einer Baugruppe
WO2024022732A1 (de) Verfahren zum bereitstellen eines updates für ein kraftfahrzeug
EP3732608B1 (de) Verfahren zur rechnergestützten parametrierung eines technischen systems
DE102018212214A1 (de) Verfahren zum Durchführen eines Fernupdates von Steuergeräten in einem Kraftfahrzeug
DE102018217728B4 (de) Verfahren und Vorrichtung zum Schätzen von mindestens einer Leistungskennzahl eines Systems
WO2015158594A1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
DE102017216797B4 (de) Verfahren zum Durchführen einer Eigendiagnose eines Steuergeräts sowie Steuergerät und Kraftfahrzeug
WO2021018452A1 (de) Verfahren zum prüfen einer zulässigen verwendung eines rolling chassis
DE102021120221A1 (de) Verfahren zum Bereitstellen eines Gamification-Moduls an einen Nutzer eines Fahrzeugs, computerlesbares Medium, System, und Fahrzeug
WO2023057126A1 (de) Prozessorsystem für ein fahrzeug und verfahren zum überwachen eines prozesszustands nach einem remote-software-update
DE102012222908A1 (de) Verfahren und Vorrichtung zur Steuerung von Anwendungsfunktionen in einem Steuergerät insbesondere einer Brennkraftmaschine eines Kraftfahrzeuges
DE102019133331A1 (de) System und Verfahren zur optimierten Erhöhung der Sicherheit in einem E/E-System
DE102022109637A1 (de) Verfahren zum Betreiben einer Steuervorrichtung für ein Kraftfahrzeug
WO2023156060A1 (de) Verfahren zur automatisierten verifizierung von anforderungsspezifikationen eines technischen prozesses
WO2022179928A1 (de) Verfahren zur konfiguration einer steuerungssoftware bei einem schienenfahrzeug
DE102018126334A1 (de) Verfahren, Fahrzeug und System zur Implementierung der End-of-Life-Phase des Produktlebenszyklus einer Fahrzeugkomponente
DE102021208681A1 (de) Steuergerät für ein Kraftfahrzeug und Verfahren zum Aktualisieren eines Steuergeräts

Legal Events

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

Ref document number: 23741597

Country of ref document: EP

Kind code of ref document: A1