WO2020257981A1 - Process for software and function update of hierarchic vehicle systems - Google Patents
Process for software and function update of hierarchic vehicle systems Download PDFInfo
- Publication number
- WO2020257981A1 WO2020257981A1 PCT/CN2019/092566 CN2019092566W WO2020257981A1 WO 2020257981 A1 WO2020257981 A1 WO 2020257981A1 CN 2019092566 W CN2019092566 W CN 2019092566W WO 2020257981 A1 WO2020257981 A1 WO 2020257981A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- update
- systems
- master
- software
- packages
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/185—Hierarchical storage management [HSM] systems, e.g. file migration or policies thereof
Definitions
- This invention relates to a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master, an electronic unit performing such an update process and a vehicle with such an electronic unit.
- the electronic systems have a hierarchical design with a top level, a lowest level and different middle levels.
- the lowest levels is typically comprised of sensors, actuators and other low level electronic units.
- the middle levels are typically comprised of electronic control units (ECUs) and the top level of servers.
- ECUs electronice control units
- Vehicle components are typically connected via a bus system. In vehicle construction and design, efficiency and economy play a major role. Therefore, each system is designed accordingly to these terms. Whereas the top levels are connected via a high bandwidth bus, the lowest levels are connected via a low performance bus.
- OTA over-the-air
- the middle level units act as a bridge to facilitate a form of direct connection between the OTA master and the lowest level unit.
- the time which is required for this update is limited by the smallest bandwidth of the system, which is typically the bandwidth of the lowest levels.
- the updates can therefore take a very long time, up to several hours, in which the vehicle cannot be used.
- the update processes of vehicle systems have therefore several disadvantages. Due to limited flash speed and limited bandwidth, long update times are required, during which the vehicle cannot be used. Furthermore, full network bandwidth is required during the update process and the update process cannot be interrupted. Additionally, only limited functions can be updated, such as navigation data or a human machine interface (HMI) . Likewise the units in chain between the update master and the updated unit must be simultaneously involved in the update process.
- HMI human machine interface
- This invention relates to a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master.
- the electronic unit has an hierarchic system design with at least a top and a bottom layer and the update master belongs to or is coequal with the top layer of the hierarchic system design.
- the layers have systems with software which can be updated. The process is performed using the steps of
- the update master can limit the amount of data needed to transfer to the different systems of the top layer. In this way only the needed data is provided and no unnecessary surplus of data need to be stored and analyzed by the systems of the top layer.
- the advantages of this step also prevail when performed by a system of another layer, especially a sub-master of another layer. Executing the updates hierarchically beginning at the bottom makes the update process more stable and safer. By working from the bottom to the top, the integrity and uniformity of the system is ensured.
- an update feedback is provided to the next higher level or to the update master after executing the update-package of a system. This ensures that the system is ready to work after the updating process because either the update was successful or a roll-back could be performed.
- the electronic unit furthermore has at least one middle layer having systems which can be updated.
- the update master decides if a roll-back is necessary or not.
- a roll-back can be necessary when in at least some of the updated systems, the update was not successful or completed in order to ensure that the electronic unit can work properly. Having a centralized instance to decide about this mitigates risks of a collapsing uniformity.
- an electronic unit of a vehicle for performing the process of the previous embodiments has a hierarchic system design with at least a top and a bottom layer.
- the layers have systems with software which can be updated and at least some of the systems have enough memory to support the storage of at least two version of the software. They can be designed such that they are able to switch between an activation of one of the at least two versions of the software. This ensures that the previously active software is still stored in the system when an update been performed. In case of an update failure or problems with the new software, the system can switch back to the previously working software. If a roll-back is initiated, for example due to a failed update, no new data has to be supplied.
- Vehicle with an electronic unit according to claim 5 adapted to perform the process of claims 1 to 4.
- the update master can be a central server outside of the vehicle or a central ECU connected to highest level in the hierarchic architecture of the vehicle.
- the update master has connectivity and storage capabilities at the same ECU.
- the update master is the central control instance for the update procedure. He is able to distribute update packages, control the process and decide about roll-back if needed.
- a sub-master can be any generic system element if a subsystem in that hierarchy level is existing.
- the sub-master is the master for the next lower hierarchy level. He is able to control the next lower level systems.
- the sub-master should have enough performance and storage and enough bandwidth to the upper level systems.
- the sub-master should be able to perform all relevant operations for update package analysis and transition.
- the timing of an update of vehicle software is often critical. During the update process, using the vehicle is not possible due to the systems being occupied with the update. Therefore an OTA update has to be timed correctly.
- different support systems might be used. For example the user of the vehicle might be questioned via a human machine interface (HMI) if or when the update can be performed.
- HMI human machine interface
- a navigation or data analyzation support system might be able to determine from historical usage data, that the user will typically not use the vehicle for a certain period of time such that the update might be executed.
- the OTA update can be downloaded from a server during driving.
- the analyzation and division of the update packages can also be performed while driving. If bandwidth and storage capabilities allow, a roll-out to lower levels can also be performed. However, the roll-out during the usage of the vehicle bears the risk, that bandwidth, storage or computational resources might not be present during use.
- Fig. 1 Shows a flowchart of a process according to a first embodiment of the invention
- Fig. 2 Shows a hierarchic system architecture of an electronic unit according to the invention
- Fig. 1 a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master according to an embodiment of the invention is shown.
- the electronic unit having an hierarchic system design with at least a top and a bottom layer, wherein the update master belongs to or is coequal with the top layer and wherein the layers having systems which can be updated; the process having the steps:
- a first step S1 the update package is supplied to the update master.
- the update master analyzes the update package, especially with respect to the receiver of the update. If the update master determines that the update package comprises update packages for more than one layer and/or for more than one system, he can divide the update package in several update packages such that the systems of the next layers receive only update packages relevant for themselves or for any of the following systems in the subsequent layers.
- the update packages are rolled-out to the next layer, here the top layer.
- the systems of the top layer receive the update packages and act themselves now as a kind of update sub-master in the next step S4. They also analyze the received update package, especially with respect to the receiver of the update.
- the update sub-master determines that the update package comprises update packages for more than one layer and/or for more than one system, he can divide the update package in several update packages such that the systems of the next layers receive only update packages relevant for themselves or for any of the following systems in the subsequent layers.
- the sub-master can control the systems of the lower levels connected to him. relevant for themselves or for any of the following systems in the subsequent layers.
- the update packages are rolled-out to the next layer, The steps of analyzing, dividing and roll-out to the next lower level can then be repeated until the update packages are rolled-out to the bottom or the last relevant layer.
- the update packages are executed to update hierarchically all of the systems of the layers which should be updated, beginning at the bottom layer.
- the updated systems can give an update feedback to the next higher layer. In this way, the failure or success of an update can be communicated along the different layers up to the update master. If the update has failed, once or several times, a roll-back can be initiated. If the systems are designed such that they can store only one version of the software to be updated, a previous version of the software can be provided by the update master. This can either be provided by a new data distribution from the update master or the data can be already part of the update packages, when the next higher layer systems have the ability to store this amount of data. If the systems are designed such that they can store more than one version of the software to be updated, both versions can be stored in parallel. When the update has failed, the system can directly use the previous version of the software without the need to receive a previous version of the software. The decision, if a roll-back is necessary, can be executed by the update master or a sub-master within the update chain.
- Fig. 2 shows exemplarily a hierarchical system architecture.
- the update master 1 and the systems 2 form the top level connected via a bus system. Connected to them via a bus system are the systems 3 of the next lower level. Connected to them via a bus system are the systems 4 of the bottom level. The capabilities of the bus system and the systems will typically decrease for lower levels.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Process for software and function update of hierarchic vehicle systems This invention relates to a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master, the electronic unit having an hierarchic system design with at least a top and a bottom layer, wherein the update master belongs to or is coequal with the top layer and wherein the layers having systems with software which can be updated, the process having the steps: -Supply the update package to the update master; -Analyze and divide the update package; -Roll-out the update-packages to the top layer; -Analyze and divide the update packages; -Roll-out the update-packages to the next lower-ranking layer; -Execute the update-packages to update hierarchically at least parts of the systems of the layers, beginning at the bottom layer.
Description
This invention relates to a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master, an electronic unit performing such an update process and a vehicle with such an electronic unit.
In state of the art vehicles the electronic systems have a hierarchical design with a top level, a lowest level and different middle levels. The lowest levels is typically comprised of sensors, actuators and other low level electronic units. The middle levels are typically comprised of electronic control units (ECUs) and the top level of servers. Vehicle components are typically connected via a bus system. In vehicle construction and design, efficiency and economy play a major role. Therefore, each system is designed accordingly to these terms. Whereas the top levels are connected via a high bandwidth bus, the lowest levels are connected via a low performance bus.
For vehicles the update of software and functions is designed to take place in a professional workshop where the vehicle is not in use. The update process is further designed to update application software only, in order to keep the firmware of the devices intact and mitigate security risks. These updates are initiated by a master, for example in form of an over-the-air (OTA) update, which passes through the different units in hierarchic order to update the lowest level unit. The middle level units act as a bridge to facilitate a form of direct connection between the OTA master and the lowest level unit. The time which is required for this update is limited by the smallest bandwidth of the system, which is typically the bandwidth of the lowest levels. The updates can therefore take a very long time, up to several hours, in which the vehicle cannot be used.
Due to the economic design and the specifications of the vehicle systems, especially the AUTOSAR specifications, the software of the units cannot be read out. Therefore, when an update is applied to the units, the current software cannot be saved. In case the update fails, a roll-back has to be initiated, in which a previous software version has to be supplied. As long as the update or roll-back procedure did not succeed, the vehicle cannot be used.
The update processes of vehicle systems have therefore several disadvantages. Due to limited flash speed and limited bandwidth, long update times are required, during which the vehicle cannot be used. Furthermore, full network bandwidth is required during the update process and the update process cannot be interrupted. Additionally, only limited functions can be updated, such as navigation data or a human machine interface (HMI) . Likewise the units in chain between the update master and the updated unit must be simultaneously involved in the update process.
Therefore it would be advantageous to provide a stable and robust procedure to update vehicle functions over the air, to have a fast update execution based on ECU computing capability, to have an update preparation process that can be proceeded during driving with dedicated bandwidth. Furthermore, it would be desirable if the update preparation process can be stopped and then continued seamlessly if updates are available also for ECU firmware and not only application software, and if the involvement of in-vehicle devices during update execution can be limited locally.
SUMMARY OF THE INVENTION
This invention relates to a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master. The electronic unit has an hierarchic system design with at least a top and a bottom layer and the update master belongs to or is coequal with the top layer of the hierarchic system design. The layers have systems with software which can be updated. The process is performed using the steps of
- Supplying the update package to the update master;
- Analyzing and dividing the update package;
- Rolling-out the update-packages to the top layer;
- Analyzing and dividing the update packages;
- Rolling-out the update-packages to the next lower-ranking layer;
- Executing the update-packages to update hierarchically at least parts of the systems of the layers, beginning at the bottom layer.
By having a central instance steering the update process, the uniformity and the integrity of the update process can be ensured. By analyzing and dividing the update package into several update packages before rolling-out, the update master can limit the amount of data needed to transfer to the different systems of the top layer. In this way only the needed data is provided and no unnecessary surplus of data need to be stored and analyzed by the systems of the top layer. The advantages of this step also prevail when performed by a system of another layer, especially a sub-master of another layer. Executing the updates hierarchically beginning at the bottom makes the update process more stable and safer. By working from the bottom to the top, the integrity and uniformity of the system is ensured.
According to one embodiment of the process, an update feedback is provided to the next higher level or to the update master after executing the update-package of a system. This ensures that the system is ready to work after the updating process because either the update was successful or a roll-back could be performed.
According to another embodiment of the process the electronic unit furthermore has at least one middle layer having systems which can be updated. The more layers the electronic unit has, the more efficient is the update process according to the invention.
In a further embodiment of the process the update master decides if a roll-back is necessary or not. A roll-back can be necessary when in at least some of the updated systems, the update was not successful or completed in order to ensure that the electronic unit can work properly. Having a centralized instance to decide about this mitigates risks of a collapsing uniformity.
According to another aspect of the invention, an electronic unit of a vehicle for performing the process of the previous embodiments has a hierarchic system design with at least a top and a bottom layer. The layers have systems with software which can be updated and at least some of the systems have enough memory to support the storage of at least two version of the software. They can be designed such that they are able to switch between an activation of one of the at least two versions of the software. This ensures that the previously active software is still stored in the system when an update been performed. In case of an update failure or problems with the new software, the system can switch back to the previously working software. If a roll-back is initiated, for example due to a failed update, no new data has to be supplied.
According to another aspect of the invention. Vehicle with an electronic unit according to claim 5 adapted to perform the process of claims 1 to 4.
The update master can be a central server outside of the vehicle or a central ECU connected to highest level in the hierarchic architecture of the vehicle. The update master has connectivity and storage capabilities at the same ECU. The update master is the central control instance for the update procedure. He is able to distribute update packages, control the process and decide about roll-back if needed.
A sub-master can be any generic system element if a subsystem in that hierarchy level is existing. The sub-master is the master for the next lower hierarchy level. He is able to control the next lower level systems. The sub-master should have enough performance and storage and enough bandwidth to the upper level systems. The sub-master should be able to perform all relevant operations for update package analysis and transition.
The timing of an update of vehicle software is often critical. During the update process, using the vehicle is not possible due to the systems being occupied with the update. Therefore an OTA update has to be timed correctly. In order to determine a possible time window during which the vehicle might execute the update, different support systems might be used. For example the user of the vehicle might be questioned via a human machine interface (HMI) if or when the update can be performed. A navigation or data analyzation support system might be able to determine from historical usage data, that the user will typically not use the vehicle for a certain period of time such that the update might be executed.
The OTA update can be downloaded from a server during driving. The analyzation and division of the update packages can also be performed while driving. If bandwidth and storage capabilities allow, a roll-out to lower levels can also be performed. However, the roll-out during the usage of the vehicle bears the risk, that bandwidth, storage or computational resources might not be present during use.
Various aspects of this invention will become apparent to those skilled in the art from the following detailed description of the preferred embodiments, when read in light of the accompanying drawings.
Fig. 1 Shows a flowchart of a process according to a first embodiment of the invention;
Fig. 2 Shows a hierarchic system architecture of an electronic unit according to the invention
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
In Fig. 1 a process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master according to an embodiment of the invention is shown. the electronic unit having an hierarchic system design with at least a top and a bottom layer, wherein the update master belongs to or is coequal with the top layer and wherein the layers having systems which can be updated; the process having the steps:
In a first step S1 the update package is supplied to the update master. In a second step S2, the update master analyzes the update package, especially with respect to the receiver of the update. If the update master determines that the update package comprises update packages for more than one layer and/or for more than one system, he can divide the update package in several update packages such that the systems of the next layers receive only update packages relevant for themselves or for any of the following systems in the subsequent layers. Then in the next step S3 the update packages are rolled-out to the next layer, here the top layer. The systems of the top layer receive the update packages and act themselves now as a kind of update sub-master in the next step S4. They also analyze the received update package, especially with respect to the receiver of the update. If the update sub-master determines that the update package comprises update packages for more than one layer and/or for more than one system, he can divide the update package in several update packages such that the systems of the next layers receive only update packages relevant for themselves or for any of the following systems in the subsequent layers. Preferably the sub-master can control the systems of the lower levels connected to him. relevant for themselves or for any of the following systems in the subsequent layers. Then in the next step S5 the update packages are rolled-out to the next layer, The steps of analyzing, dividing and roll-out to the next lower level can then be repeated until the update packages are rolled-out to the bottom or the last relevant layer. When the update packages have been received by the systems of these layers, in the next step S6 the update packages are executed to update hierarchically all of the systems of the layers which should be updated, beginning at the bottom layer.
Additionally, the updated systems can give an update feedback to the next higher layer. In this way, the failure or success of an update can be communicated along the different layers up to the update master. If the update has failed, once or several times, a roll-back can be initiated. If the systems are designed such that they can store only one version of the software to be updated, a previous version of the software can be provided by the update master. This can either be provided by a new data distribution from the update master or the data can be already part of the update packages, when the next higher layer systems have the ability to store this amount of data. If the systems are designed such that they can store more than one version of the software to be updated, both versions can be stored in parallel. When the update has failed, the system can directly use the previous version of the software without the need to receive a previous version of the software. The decision, if a roll-back is necessary, can be executed by the update master or a sub-master within the update chain.
Fig. 2 shows exemplarily a hierarchical system architecture. The update master 1 and the systems 2 form the top level connected via a bus system. Connected to them via a bus system are the systems 3 of the next lower level. Connected to them via a bus system are the systems 4 of the bottom level. The capabilities of the bus system and the systems will typically decrease for lower levels.
In accordance with the provisions of the patent statutes, the principle and mode of operation of this invention have been described and illustrated in its preferred embodiments. However, it must be understood that this invention may be practiced otherwise than as specifically explained and illustrated without departing from its spirit or scope.
Claims (6)
- Process for updating an electronic unit of a vehicle with an update package over an over-the-air update by an update master,the electronic unit having an hierarchic system design with at least a top and a bottom layer, wherein the update master belongs to or is coequal with the top layer and wherein the layers having systems with software which can be updated;the process having the steps:- Supply the update package to the update master (S1) ;- Analyze and divide the update package (S2) ;- Roll-out the update-packages to the top layer (S3) ;- Analyze and divide the update packages (S4) ;- Roll-out the update-packages to the next lower-ranking layer (S5) ;- Execute the update-packages to update hierarchically at least parts of the systems of the layers, beginning at the bottom layer (S6) .
- Process according to claim 1, wherein after executing the update-package of a system, an update feedback is provided to the next higher level or to the update master.
- Process according to claim 1 or 2, wherein the electronic unit furthermore has at least one middle layer having systems which can be updated.
- Process according to any of the preceding claims, wherein the update master decides if a roll-back is necessary.
- Electronic unit of a vehicle for performing the process of claims 1 to 4, the electronic unit having a hierarchic system design with at least a top and a bottom layer, wherein the layers having systems with software which can be updated; and wherein the systems have enough memory to support the storage of at least two version of the software and are designed to be able to switch between an activation of one of the at least two versions of the software.
- Vehicle with an electronic unit according to claim 5 adapted to perform the process of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2019/092566 WO2020257981A1 (en) | 2019-06-24 | 2019-06-24 | Process for software and function update of hierarchic vehicle systems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2019/092566 WO2020257981A1 (en) | 2019-06-24 | 2019-06-24 | Process for software and function update of hierarchic vehicle systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2020257981A1 true WO2020257981A1 (en) | 2020-12-30 |
Family
ID=74059577
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2019/092566 Ceased WO2020257981A1 (en) | 2019-06-24 | 2019-06-24 | Process for software and function update of hierarchic vehicle systems |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2020257981A1 (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5721914A (en) * | 1995-09-14 | 1998-02-24 | Mci Corporation | System and method for hierarchical data distribution |
| CN104142896A (en) * | 2013-05-10 | 2014-11-12 | 阿里巴巴集团控股有限公司 | Cache control method and system |
| CN106571967A (en) * | 2016-11-09 | 2017-04-19 | 上海斐讯数据通信技术有限公司 | Multi-level network topology management method and device |
-
2019
- 2019-06-24 WO PCT/CN2019/092566 patent/WO2020257981A1/en not_active Ceased
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5721914A (en) * | 1995-09-14 | 1998-02-24 | Mci Corporation | System and method for hierarchical data distribution |
| CN104142896A (en) * | 2013-05-10 | 2014-11-12 | 阿里巴巴集团控股有限公司 | Cache control method and system |
| CN106571967A (en) * | 2016-11-09 | 2017-04-19 | 上海斐讯数据通信技术有限公司 | Multi-level network topology management method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20190324858A1 (en) | Rollback recovery from partial failure in multiple electronic control unit over-the-air updates | |
| US6779176B1 (en) | Methods and apparatus for updating electronic system programs and program blocks during substantially continued system execution | |
| US11099830B2 (en) | Software updating apparatus, vehicle, and software updating method | |
| CN107844343B (en) | Upgrading system and method for complex server application system | |
| CN114895947A (en) | Software upgrading method, device, equipment and storage medium of vehicle-mounted controller | |
| KR102639949B1 (en) | Method and subsystem for installing a software update in a vehicle | |
| CN112434008A (en) | Distributed database upgrading method, device and medium | |
| US8701079B2 (en) | Procedure and development environment for generation of an executable overall control program | |
| US20190171433A1 (en) | Methods for enabling a computer to migrate microservices and to perform microservice templating | |
| US11947824B2 (en) | Electronic control unit, method, and program | |
| WO2018127394A1 (en) | Scalable control system for a motor vehicle | |
| JP2024169663A (en) | Center, update management method, and update management program | |
| WO2019123747A1 (en) | Electronic control device for automobile and control method thereof | |
| US12572349B2 (en) | Computer-implemented method and device for the automated update of a communication unit of a control unit of a vehicle | |
| CN116016172B (en) | Method and device for Pod longitudinal expansion of kubernetes clusters | |
| JP2025168511A (en) | Update Management System | |
| CN112579121B (en) | Data processing method and device | |
| CN109116818B (en) | Real-time data dump method and device during SCADA system upgrade | |
| CN109144486B (en) | Stateless workflow implementation method | |
| CN117785253A (en) | An OTA upgrade method, code image loading processing method, system and vehicle | |
| CN106095454A (en) | The Oftware updating method of a kind of coprocessor, system and primary processor | |
| CN117785045A (en) | Controller ASW data storage method and device based on autosar | |
| CN116594806B (en) | OTA backup methods, backup devices, computer-readable storage media, and vehicles | |
| CN109976792B (en) | Mirror image delay updating method | |
| CN118963790A (en) | Remote upgrade method and device for vehicle controller |
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: 19934764 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 19934764 Country of ref document: EP Kind code of ref document: A1 |