CN111381844A - Method and device for updating vehicle ECU firmware - Google Patents

Abstract

The application provides a method and a device for updating vehicle ECU firmware, wherein the method comprises the following steps: the method comprises the steps of obtaining a firmware upgrading version to be updated of the vehicle ECU, simulating and upgrading the firmware of the ECU to the firmware upgrading version in a virtual machine, and updating the actual firmware of the vehicle ECU by using the firmware upgrading version if the simulation updating is successful, so that the success rate of updating the firmware of the actual ECU is greatly improved, the problem that the vehicle cannot be started due to failure of updating the firmware of the ECU is solved, and the problem that the success rate of the ECU firmware upgrading process in the related technology is low is solved.

Description

Method and device for updating vehicle ECU firmware

Technical Field

The present application relates to, but is not limited to, the field of vehicles, and more particularly, to a method and apparatus for updating vehicle ECU firmware.

Background

At present, with the rapid development of the 3G and 4G networks of the third and fourth generation mobile communication systems, more and more vehicle-mounted terminal devices integrate wireless communication modules, and such vehicle-mounted terminal products increasingly need to serve as control centers of the whole in-vehicle network. The extension of such control is also increasing, and in addition to the control of the in-vehicle devices, network channels and control hubs as in-vehicle passenger mobile terminals are also required. This makes the application range of the in-vehicle terminal wider and wider. Automobile manufacturers desire that the in-vehicle terminals provide not only basic communication functions but also functions for managing and upgrading other Electronic Control Units (ECUs) in the automobile.

Aiming at the problem of low success rate of the ECU firmware upgrading process in the related technology, no effective solution is available at present.

Disclosure of Invention

The embodiment of the application provides a method and a device for updating vehicle ECU firmware, which at least solve the problem of low success rate of ECU firmware upgrading process in the related technology.

According to an embodiment of the present application, there is provided a method of updating vehicle ECU firmware, including: acquiring a firmware upgrading version of an ECU (electronic control Unit) of a vehicle; simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version; and after the simulation updating is successful, updating the firmware of the vehicle ECU by using the firmware upgrading version.

There is also provided, in accordance with another embodiment of the present application, apparatus for updating vehicle ECU firmware, including: the acquisition module is used for acquiring a firmware upgrading version of an ECU (electronic control unit) of the vehicle; the simulation updating module is used for simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version; and the updating module is used for updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

According to another embodiment of the present application, there is also provided a vehicle-mounted terminal including: the ECU upgrading component is used for requesting a firmware upgrading version of the vehicle control unit ECU to the cloud server and downloading the firmware upgrading version of the ECU to be stored locally; and the virtual safety framework is used for simulating and updating the firmware of the vehicle ECU according to the saved firmware upgrading version, and updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

According to another embodiment of the present application, there is also provided a cloud server including: the communication module is used for receiving an ECU firmware upgrading request sent by a vehicle-mounted terminal and sending the ECU firmware upgrading version to the vehicle-mounted terminal.

According to a further embodiment of the present application, there is also provided a storage medium having a computer program stored therein, wherein the computer program is arranged to perform the steps of any of the above method embodiments when executed.

According to yet another embodiment of the present application, there is also provided an electronic device, comprising a memory in which a computer program is stored and a processor arranged to run the computer program to perform the steps of any of the above method embodiments.

According to the method and the device, the firmware upgrading version to be updated of the vehicle ECU is obtained, then the firmware of the ECU is upgraded to the firmware upgrading version in a simulation mode, if the simulation updating is successful, the firmware of the actual ECU of the vehicle is updated by the firmware upgrading version, so that the success rate of updating the firmware of the actual ECU is greatly improved, the problem that the vehicle cannot be started due to failure of updating the firmware of the ECU is solved, and the problem that the success rate of the ECU firmware upgrading process in the related technology is low is solved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a block diagram of the hardware architecture of an onboard TBOX of a method of updating the firmware of a vehicle ECU according to an embodiment of the present application;

FIG. 2 is a flow chart of a method of updating vehicle ECU firmware according to an embodiment of the present application;

FIG. 3 is a block diagram of a vehicle performing a firmware upgrade according to another embodiment of the present application;

FIG. 4 is an overview flow diagram of an offline write flash according to another embodiment of the present application;

FIG. 5 is a flow diagram of a highly secure flash upgrade based on an ECU simulation agent according to another embodiment of the present application;

FIG. 6 is a schematic diagram of an initialization portion of a behavior modeling module according to another embodiment of the present application;

FIG. 7 is a flow diagram of core steps of a behavior modeling module according to another embodiment of the present application;

FIG. 8 is a flow diagram of core steps of a behavior modeling module according to another embodiment of the present application;

FIG. 9 is a schematic structural diagram of a vehicle-mounted terminal according to another embodiment of the present application;

fig. 10 is a schematic structural diagram of a cloud server according to another embodiment of the present application.

Detailed Description

The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

The scheme described in the application can be applied to a vehicle networking scene, and particularly can be a scene that a vehicle needs to update an electronic control unit of the vehicle.

First, two types of schemes are adopted for updating the vehicle ECU in the related art:

scheme A, whole car ECU upgrading function based on local ODB equipment: the scheme is a traditional implementation mode, and requires that physical ODB equipment is adopted to connect the vehicle, and then other ECUs in the vehicle are managed and upgraded through the equipment.

Scheme B, based on the whole car ECU upgrading function that wireless refresher was accomplished in high in the clouds: according to the scheme, the wireless communication module is integrated on the traditional ECU refresher, so that the server can be connected with the ECU to be upgraded through wireless signals, and the in-vehicle ECU upgrading function based on the cloud is achieved.

The main drawback of the solution based on local ODB devices is the limited versatility of use; the overall cost is prohibitive. The scheme requires that an OBD upgrading device must be connected during upgrading, and the overall cost of the scheme is obviously increased. And the scheme requires that other ECUs can be upgraded only in a place with OBD upgrading equipment, the application range of the scheme is severely limited, and the upgrading requirements of regions and time cannot be limited at any time and any place. Meanwhile, because the diagnostic protocols of various car factories are different, the required diagnostic equipment is different, and the application range of the scheme is narrower.

The main drawback of cloud-based solutions is that they rely heavily on mobile networks, once the vehicle is in an area with poor network coverage, such as an underground garage; suburban or mountain parking lots. The wireless refresher cannot be connected with the server, so that the whole upgrading process cannot be carried out. And the wireless refresher is also a physical entity added device, which increases the overall cost of the solution. Meanwhile, other ECUs are directly written in a brush mode, no safety protection measures are arranged in the middle, once the writing is mistaken or attacked, key ECUs in the vehicle cannot work, and therefore the whole vehicle cannot be started.

Aiming at a vehicle networking product TBOX (telematics BOX), the market hopes that the product can upgrade an Electronic Control Unit (ECU) of a whole vehicle in an Over-the-Air Technology (OTA) mode, so that the requirement of a manufacturer and a 4S shop for On-Board Diagnostic (ODB) Diagnostic equipment can be reduced. The above needs require the provision of an integrated solution to manage all in-vehicle ECU software components, including firmware, applications, configuration, host maps, etc., that can be updated at any time and place, whether the vehicle is in a production line, 4S outlet, or private garage.

Example one

The method provided by the embodiment one of the application can be executed in a vehicle-mounted TBOX or other similar vehicle-mounted terminals. Taking an example of the vehicle TBOX running on the vehicle TBOX, fig. 1 is a hardware block diagram of the vehicle TBOX of the method for updating the vehicle ECU firmware according to the embodiment of the present application, and as shown in fig. 1, the vehicle TBOX may include one or more processors 102 (only one is shown in fig. 1) (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data, and optionally, the vehicle TBOX may further include a transmission device 106 for a communication function and an input/output device 108. Those skilled in the art will appreciate that the configuration shown in fig. 1 is merely illustrative and is not intended to limit the configuration of the onboard TBOX described above. For example, the onboard TBOX may also include more or fewer components than shown in FIG. 1, or have a different configuration than shown in FIG. 1.

The memory 104 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the method for updating the vehicle ECU firmware in the embodiment of the present application, and the processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, so as to implement the method described above. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory located remotely from processor 102, which may be connected to TBOX through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used for receiving or transmitting data via a network. Specific examples of such networks may include wireless networks provided by communication providers of onboard TBOXs. In one example, the transmission device 106 includes a Network adapter (NIC) that can communicate with the cloud server via a Network.

In the present embodiment, a method for updating vehicle ECU firmware that can be operated in a vehicle is provided, and fig. 2 is a flowchart of a method for updating vehicle ECU firmware according to an embodiment of the present application, as shown in fig. 2, the flowchart includes the following steps:

step S202, acquiring a firmware upgrading version of an ECU (electronic control Unit) of the vehicle;

the firmware upgrading version of the ECU can be acquired from the server in real time when the network permits, or the firmware upgrading version can be downloaded from the server and stored to the local, and the firmware upgrading version can be acquired from the local when the use is required.

Step S204, simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

the virtual machine may be built using a microkernel machine, or other virtual machine types, such as a container scheme, etc. The virtual machine may correspond to the virtual security framework described in the subsequent embodiments.

And step S206, after the simulation updating is successful, updating the firmware of the vehicle ECU by using the firmware upgrading version.

Updating the firmware of the vehicle ECU may be equivalent to flashing the firmware upgrade version to the vehicle ECU.

Through the steps, the firmware upgrading version to be updated of the vehicle ECU is obtained, then the firmware of the vehicle ECU is simulated and upgraded to the firmware upgrading version in the virtual machine, and if the simulation updating is successful, the firmware of the actual vehicle ECU is updated by the firmware upgrading version, so that the firmware updating success rate of the actual ECU is greatly improved, the problem that the vehicle cannot be started due to failure of the firmware updating of the ECU is solved, and the problem that the success rate of the ECU firmware upgrading process in the related technology is low is solved.

Alternatively, the above scheme may be run in a vehicle terminal, such as a TBOX, or other vehicle terminal mounted on the front of the vehicle.

Optionally, obtaining a firmware upgrade version of the vehicle ECU comprises: connecting to a server through an onboard telematics box TBOX of the vehicle; and downloading the firmware upgrading version corresponding to the ECU from the server. The timing of firmware update may be determined first, for example, when the vehicle is turned off, the firmware update is triggered, and TBOX is controlled to connect to the server, although the operation of connecting to the server to download the firmware upgrade version may also be performed independently. Alternatively, the TBOX connects to the server from time to detect if a firmware upgrade version exists, downloads if it does, and triggers a firmware upgrade for the ECU. The firmware upgrading version can be stored after being downloaded, and the ECU firmware can be upgraded in a subsequent scene that the vehicle TBOX does not have a network, such as a deep mountain, if the time is appropriate.

Optionally, before downloading the firmware upgrade versions corresponding to the ECUs from the server, when a plurality of ECUs exist in the vehicle, detecting that an update version of a firmware download control flow corresponding to the vehicle exists in the server, where the firmware download control flow is used to indicate a download order of the firmware upgrade versions of the ECUs; acquiring the updated version as a first firmware downloading control process; and determining the downloading sequence of the firmware upgrading versions of the plurality of ECUs according to the first firmware downloading control flow. By adopting the scheme, the downloading can be realized according to the downloading control flow most suitable for the current automobile, the method can be suitable for different automobile manufacturers to set the grades of different ECUs, and the application scenes of the scheme in the application file are greatly expanded.

Optionally, after downloading the firmware upgrade version corresponding to the ECU from the server and storing the firmware upgrade version in the vehicle-mounted terminal, when the vehicle-mounted terminal cannot be connected to the server and is in an offline state, calling the firmware upgrade version already stored in the vehicle-mounted terminal to perform simulation update. By adopting the scheme, the possibility of upgrading the ECU in an off-line manner is realized, the scene range of the ECU upgrading is greatly expanded, and the firmware upgrading can be completed in an area with poor network coverage.

Optionally, according to the firmware upgrade version, before simulating updating of firmware of the vehicle ECU in the virtual machine, the virtual machine is built through a microkernel state machine. By adopting the scheme, the actual ECU and the virtual machine can be isolated through the micro-kernel state machine.

Optionally, after the simulation update is successful, updating the firmware of the vehicle ECU using the firmware upgrade version, including: and after the simulation updating is successful, sending an instruction for indicating to start updating the firmware to the ECU through the microkernel state machine. I.e. an instruction to the actual ECU for firmware update is sent by the microkernel state machine.

Optionally, simulating, in the virtual machine, updating the firmware of the vehicle ECU according to the firmware upgrade version, including: simulating, by the virtual machine, a response instruction of the ECU during a firmware upgrade process. The virtual machine simulates the behavior of the actual ECU, including simulating the response instruction of the actual ECU in the firmware updating process, so as to judge whether the updating is successful.

Optionally, according to the firmware upgrade version, after the firmware of the vehicle ECU is updated in the virtual machine in a simulated manner, the firmware upgrade version is retrieved from the server when the update fails. By adopting the scheme, when the updating fails, the firmware upgrading version is judged to have problems, so that the firmware upgrading version is downloaded again, and the steps from the step S202 to the step S206 are repeatedly executed, so that the virtual machine is used for detecting the firmware upgrading version, the subsequent updating is stopped when the firmware upgrading version has errors, and the condition that the vehicle cannot be started due to the fact that the firmware of the vehicle ECU fails to be updated is avoided.

The following description is made in conjunction with another embodiment of the present application.

The technical problem to be solved by another embodiment of the present application is: the defect that entity hardware must be added newly and/or a wireless network must be relied on and the scheme safety is extremely low in the related technology is overcome, and a TBOX-based finished vehicle ECU upgrading solution is provided.

The scheme of another embodiment of the application has three characteristics: a pure software implementation; offline upgrade without depending on a network; a highly secure flash technique based on an ECU simulation agent.

The pure software implementation means that the implementation scheme of the application does not need to add new hardware at all, and only sets a software module on a TBOX product in the related technology, and the upgrading function of the vehicle ECU is finally realized through the cooperation of a plurality of software modules. The user does not need to add new hardware, and the cost of ownership of the whole solution is greatly reduced.

For the offline updating process, the vehicle-mounted terminal is required to be connected with the cloud server first to download the ECU firmware to be updated, and then the updating service main control module of the vehicle-mounted terminal is disconnected from the network completely to control the whole ECU firmware updating process. The ECU upgrading process does not need participation of a server side, the whole process is initiated and controlled by the vehicle-mounted terminal, and the flashing function is not affected no matter whether the vehicle-mounted terminal is networked or not. No matter the vehicle-mounted terminal is on-line or off-line, the user can write the ECU in the vehicle, and the application range of the scheme is greatly expanded.

The high-safety flash upgrading process based on the ECU simulation agent refers to any actual flash operation initiated by a flash service main control module of the vehicle-mounted terminal, only operates a virtual safety framework, and does not involve flash of actual hardware. And authenticating the flash in the virtual safety frame, simulating execution and other operations, and actually flashing the firmware to the specific ECU after the flash is correct. The high-safety flash technology based on the ECU simulation agent means that the vehicle-mounted terminal does not directly flash other ECUs in the vehicle, but indirectly flashes through an ECU agent software module arranged in the vehicle-mounted terminal. The safety level of the whole scheme is greatly enhanced through the ECU agent software module, and the worry about the death of the ECU or the attack of hackers is avoided.

The ECU agent software module mainly comprises two functions: ECU behavior simulation and flash instruction forwarding. The ECU behavior simulation refers to completely simulating command response processing of an ECU to be refreshed in a vehicle and Controller Area Network (CAN) bus network message response. When the vehicle-mounted terminal initiates a new ECU flash, the flash flow firstly reaches the ECU behavior simulation unit, and the response of the ECU to be flashed is simulated by the unit. If all the flow and instruction responses are correct, the vehicle-mounted terminal considers that the brush writing is safe brush writing and can continue to perform. The flash instruction forwarding unit is a software unit which enters a processing flow after the ECU behavior simulation unit, when the vehicle-mounted terminal passes the verification and the discrimination of the ECU behavior simulation unit, the flash instruction can be transmitted to the unit, and the unit forwards the flash instruction to actual ECU hardware.

The scheme of the application has high practical value, and the usability and stability of the product and the user experience are improved to a great extent.

Fig. 3 is a block diagram of a vehicle for performing firmware upgrade according to another embodiment of the present application, and as shown in fig. 3, the whole system is composed of three major components: an ECU upgrade component 302, a virtual security framework 304, and a cloud server 306. Where the ECU upgrade component 302 and the virtual safety framework 304 are located inside the onboard TBOX, they may be purely software components. The cloud server 306 component is located inside the cloud server 306, and is a software component newly added to the cloud server 306 in the related art. Each component is composed of a plurality of modules, and the functions of the modules specifically included in fig. 3 can be described with reference to the following embodiments. Through the modules, a solution for upgrading the ECU of the whole vehicle through TBOX can be realized based on the cooperation of the three large components.

The constitution and the module function of each component in fig. 3 are described in detail below.

ECU upgrade Assembly 302

The component is a pure software component, is positioned in a vehicle-mounted TBOX or other front-mounted vehicle-mounted terminals, and is a software component added to the hardware terminals. As shown in fig. 3, the assembly includes five service modules, which are a firmware downloading module, a flash service master control module, a vehicle configuration information updating module, a local storage module, and a unified diagnostic service UDS service module.

A firmware downloading module: the module is responsible for initiating a firmware download to update the ECU. This module is responsible for establishing a secure link with the cloud server 306, and then downloading the firmware to be updated through the secure link. The starting of the module is initiated by the flash service main control module. The module is only responsible for the air interface downloading of the firmware, once the downloading is completed, the task of the module is completed, and the network connection with the cloud server 306 can be disconnected. The module is also responsible for updating the downloading control flow, if the firmware downloading control flow between the vehicle-mounted equipment and the server is updated, the module can download the updated downloading control flow firstly and then initiate the firmware downloading for updating the ECU. This responsibility is mainly to deal with the question that the present application cannot flexibly change the download control flow.

The flash service master control module: the module is a core module in the ECU upgrade module 302, and is responsible for the control of the whole refresh upgrade process, and the module initiates scheduling to control other service modules in the module, and interacts with the virtual security framework 304 module. After the vehicle configuration information updating module informs the flash service main control module of the version information of the current ECU, the flash service main control module determines whether to initiate an updating request according to the current state of the vehicle, relevant precondition judgment and other factors, if so, the flash service module informs the firmware downloading module to establish a secure link with the server, and downloads the firmware to be updated according to the real vehicle ECU version. After the firmware downloading module finishes downloading the firmware, the flash service main control module calls the local storage module and stores the firmware to be updated to the local storage module. And then interacts with the virtual security framework 304 to perform the next related flash operation.

The vehicle configuration information updating module: this module is responsible for collecting relevant ECU configuration information for the current vehicle at regular times or when certain conditions are met, including but not limited to: a vehicle VIN code; the name of the ECU; an ECU address; ECU software and hardware version number; ECU calibration information, and the like. The module acquires the vehicle configuration information and then informs the flash service main control module, stores the vehicle configuration information to the local storage module, and then performs the next action according to the requirements of the flash service main control module.

A local storage module: this module is responsible for vehicle configuration information storage and ECU firmware storage to be updated. Respectively called by the vehicle configuration information updating module and the firmware downloading module. The module is designed mainly by considering the discretization design of business logic processing and business data storage, and is beneficial to the calling of other modules and the long-term consistent storage of data.

Unified Diagnostic Service (UDS) Service module: this module is responsible for UDS instruction processing involved in all ECU flashing functions. Including but not limited to: inquiring an ECU address; inquiring the software and hardware version of the ECU; flashing time of the current version of the ECU; ECU firmware size to be flashed, and so on. The UDS service is a service which the CAN network in the vehicle must require to support, and a user CAN apply for the relevant UDS service of a certain ECU through an external OBD interface. The module is a UDS service set which is newly added in the TBOX and aims at upgrading the ECU function of the whole vehicle.

Virtual safety framework 304(Virtual Safe infostracture)

The component is a pure software component, is positioned in a vehicle-mounted TBOX or other front-mounted vehicle-mounted terminals, and is a software component added to the hardware terminals. As shown in fig. 3, the assembly contains four business modules: a microkernel state machine module; an ECU behavior simulation module; an ECU flash execution module; and the VSI interacts the interface module externally.

This component is an important part of another embodiment of the present application. The main intention is to completely simulate the behavior characteristics of the ECU in the vehicle through a virtual safety framework 304, thereby solving the safety pain points in the ECU flashing process. The specific function is that the ECU upgrade module 302 first transmits the firmware to be upgraded to the virtual security framework 304, and performs the upgrade action in advance in the virtual security framework 304, and then performs the actual write-through action if the upgrade action is correct.

A microkernel state machine module: this module is the core module of the virtual security framework 304. The main role is to isolate the actual ECU hardware from the virtual security framework 304 by isolating the interaction between different services in the VSI through a microkernel mode state machine. That is, within the VSI, any related service modules cannot directly communicate with each other, and the modules must perform inter-process communication (ipc) to enable normal interaction. The method has the advantages that the safety level of the whole scheme is greatly improved, the behavior simulation and the behavior execution are extremely low in coupling, and the normal operation of the whole scheme cannot be influenced by the failure behavior of one module.

ECU behavior simulation module: this module is the core module of the virtual security framework 304. The module serves a pre-flush process in an ECU flush scheme, i.e., different flush flows and instruction processing of multiple ECUs inside a simulated vehicle completely inside a VSI. When the ECU upgrade module 302 transmits a firmware to be updated of a certain ECU through the VSI external interaction interface module and the microkernel state machine, the ECU behavior simulation module receives the firmware, internally executes the flash operation, provides instruction responses at different stages according to a specific ECU type, and transmits a final executed result to the ECU upgrade module 302 through the microkernel state machine and the external interaction interface module.

The micro-kernel state machine module and the ECU behavior simulation module are core modules of the VSI component, and the implementation mechanism is that the bottom layer task scheduling adopts a micro-kernel mode, and the upper layer behavior simulation module adopts software simulation behaviors. The implementation mechanism is similar to the traditional virtual machine/simulator scheme; container solution (Docker); trustzone is significantly different.

The virtual machine/simulator scheme adopts an instruction level hardware simulation platform, and simulates peripheral devices of different hardware platforms, such as a Memory Management Unit (MMU), an input/output IO, a Cache Memory, and the like. The scheme has great requirements on the computing capacity and the storage capacity of the equipment, and generally cannot be applied to the embedded type of the vehicle-mounted terminal.

The container scheme does not virtualize hardware, but merely simulates the running environment of an application. The VSI of the present application requires a behavioral logic that simulates the ECU, as opposed to a vessel solution.

Trustzone is a system virtualization scheme based on dedicated hardware, and two hardware areas are provided by processor (Advanced RISCMachines, ARM for short) cores: a normal zone and a safe zone. Software in the secure area may access memory in the normal area, otherwise not.

An ECU flashing execution module: when the ECU behavior simulation module feeds back that the pre-flashing flow of a certain ECU is normal and the response of relevant steps is correct, the microkernel state calls the ECU flashing execution module to perform actual ECU flashing operation. The module is mainly responsible for calling a VSI external interaction interface to initiate a flash instruction to a related ECU after receiving a flash task from the microkernel state machine.

The VSI external interaction interface module: the module is responsible for external interaction in the VSI, and external contacts have two types: an ECU upgrade component 302 and specific ECU hardware. The contacts in the pair are other business modules inside the VSI. The module shields the connection between the VSI and external services and hardware, the VSI internal requirement and external interaction can be carried out only through the module, and the reliability and safety of the whole system are greatly improved.

Third, cloud server 306

The cloud server 306 component of the present application is a cloud server 306 component that multiplexes TBOX. Only a part of software business modules are added in the component to support the scheme described in the application. The cloud server 306 subassembly of this application only reports the link in the result after upgrade package download and the flow of writing with a brush are accomplished and produces the effect, in case the upgrade package finishes downloading, cloud server 306 subassembly can with on-vehicle TBOX disconnection, do not influence the writing with a brush of whole car ECU.

As shown in fig. 3, the cloud server 306 includes the following modules:

a synchronization management module: the module is configured to receive vehicle configuration information sent by a vehicle configuration information update module in the ECU upgrade module 302, compare the vehicle configuration information with configuration information of the vehicle stored in the cloud server 306, and notify the ECU upgrade module 302 if there is an ECU whose version needs to be updated, and attach an ECU name and version information to be updated.

Upgrade and wrap the administrative module: this module is responsible for generating the ECU firmware combination that a certain vehicle needs to be upgraded. The module interacts with a firmware downloading module of the ECU upgrading assembly 302, the firmware downloading module uploads the information of the ECU combination and the specific version to be upgraded of the vehicle, and the upgrading package management module generates the corresponding ECU and the version to be upgraded of the vehicle according to the information reported by the vehicle and sends the ECU and the version to be upgraded of the vehicle to the vehicle-mounted TBOX through the firmware downloading module of the ECU upgrading assembly 302.

An upgrade task management module: the module is responsible for counting the execution result of the upgrade task. The result is reported by a vehicle configuration information updating module in the ECU upgrade component 302, if the upgrade task is successfully executed this time, the vehicle configuration information stored in the cloud of the vehicle is updated by the module, otherwise, the vehicle configuration information after the vehicle was successfully executed last time is retained.

In another embodiment of the present application, the offline update-over-write process means that once the firmware to be updated is downloaded, the subsequent update-over-write process does not need the participation of the cloud server 306, and the update-over-write process can be completed even in a region with a weak network signal interruption or coverage. This offline flash flow is guaranteed by the built-in ECU upgrade component 302 of TBOX, which is the flow of fig. 4.

The highly-safe flash upgrading process based on the ECU simulation agent means that the ECU cannot be directly operated in the actual flash ECU process, the ECU needs to be simulated and operated firstly through an ECU behavior simulation module in the VSI, and the ECU is forwarded to the actual ECU to be executed after the ECU is correct, namely the process described in the figure 5.

FIG. 4 is a general flow chart of an offline write-through according to another embodiment of the present application, as shown in FIG. 4, including the following steps:

step S401, the vehicle configuration information is sent to a cloud server, specifically, the vehicle configuration information updating module sends the configuration information of the vehicle to the cloud server at a relevant trigger time. Trigger opportunities here include, but are not limited to: after each vehicle ignition; more than 7 days from the last successful flash, and so on. Configuration information for a vehicle includes, but is not limited to: a Vehicle Identification Number (VIN) code of the Vehicle; ECU software and hardware version numbers in an ECU list of the vehicle; ECU update time; an ECU address; the name of the ECU; ECU manufacturers, etc.

Step S402: the cloud compares the vehicle configuration information, specifically, after receiving the vehicle configuration information sent by the TBOX, the cloud server compares the configuration information with the configuration information of the vehicle stored in the cloud, and if an ECU which needs to be updated is found, an installation report is generated. Installation reports include, but are not limited to: the name of the ECU to be upgraded; ECU software and hardware version number to be upgraded; a check code, and the like.

Step S403: the cloud sends the comparison result to the TBOX, and specifically, the cloud server sends the installation report generated in the previous step to a vehicle configuration information updating module in the TBOX.

Step S404: and informing the master control of the ECU to be updated, specifically, after the vehicle configuration information updating module receives an installation report sent by the cloud server, analyzing the installation report, and if the ECU to be updated exists, informing the flashing service master control module to master the whole flashing process.

Step S405: specifically, after receiving an ECU to be updated notification sent by the vehicle configuration information updating module, the flash service main control module judges whether the current vehicle is in a state suitable for downloading, and if so, notifies the firmware downloading module to download new firmware.

Step S406: and initiating firmware downloading, specifically, the firmware downloading module establishes a secure link with the cloud server, and initiates a firmware downloading request to the cloud server by using the name of the ECU to be upgraded in the installation report.

Step S407: and (3) downloading the firmware, specifically, after receiving a request sent by the firmware downloading module, the cloud server analyzes a specific ECU combination to be upgraded contained in the request, dynamically generates a related new firmware collection, packages all ECU firmware to be upgraded according to a VDF format, and sends the ECU firmware to the firmware downloading module through a secure link channel.

Step S408: specifically, the firmware downloading module performs security check on a received firmware packet to be upgraded and then decompresses the firmware packet, reversely separates out the ECU independent firmware to be upgraded by using a VDF format, and then stores the firmware in a TBOX internal or external storage unit through the local storage module.

At this step, all the steps needing to interact with the cloud server are completed, and the real brushing process does not involve any interaction with the server, namely the steps can be carried out off line.

Step S409: and informing the state machine to start the flash through the VSI, specifically, informing the microkernel state machine to start the flash through the VSI by the flash service main control module.

Step S410: the notification behavior module starts the flash, specifically, the microkernel state machine notifies the ECU behavior simulation module to start the simulation flash operation, and the specific steps of the process are explained in fig. two.

Step S411: and feeding back the result to the state machine, specifically, after the ECU behavior simulation module executes the ECU flash, feeding back the execution result of each ECU to the microkernel state machine.

Step S412: and informing the flash execution starting, specifically, judging which ECUs are successfully flashed and which ECUs are failed in the flash process according to the received ECU behavior simulation module execution result by the microkernel state machine. And executing subsequent steps only if all the ECUs to be upgraded are successfully written in the ECU behavior simulation module, otherwise, failing the whole process.

And when the behavior simulation of all the ECUs is in accordance with expectation, the microkernel state machine informs the ECU flash execution module to actually flash.

Step S413: and feeding back the result to the state machine, specifically, feeding back all the ECU flash results to be flashed to the microkernel state machine by the ECU flash execution module.

Step S414: and the actual flashing result informs the service main control module through the VSI, and specifically, a microkernel state machine in the VSI component informs a flashing service main control module in the ECU upgrading component of the flashing result through the VSI. The result includes which ECUs were flashed, the flash status of each ECU, and the version number of the ECU after flashing.

Step S415: and sending the updated vehicle configuration, specifically, the flashing service main control module regenerates the updated vehicle configuration information according to the received ECU flashing result of the time and sends the updated vehicle configuration information to the vehicle configuration information updating module.

Step S416: and updating the vehicle configuration information to the cloud, specifically, sending the updated vehicle configuration information to a cloud server by a vehicle configuration information updating module.

The whole offline flashing overall process is completed, in the whole process, only the firmware downloading and result reporting parts need to participate in the network, other actual flashing processes are performed offline, the flashing service main control module of the ECU upgrading assembly serves as an execution main body of the flashing process, and the participation of any cloud component is not relied.

Fig. 5 is a flow chart of highly secure flash upgrade based on ECU simulation agent according to another embodiment of the present application, as shown in fig. 5, comprising the steps of:

step S501: the vehicle enters a programming mode. Firstly, enabling relevant ECU nodes to be upgraded to enter a boot mode; and then, simulating to power on a keyless Entry and Start system (PEPS) and muting the host. Finally, the 15 nodes are enabled to enter boot mode. All the ECUs are in a simulation state and can make relevant positive and negative responses aiming at the instructions. If the execution is correct, the next step is entered. Otherwise, repeating retry through a retry mechanism, and reporting a flash failure result after the retry times are exceeded.

Fig. 6 is a schematic diagram of an initialization part of a behavior simulation module according to another embodiment of the present application, and the main purpose is to start a flash simulation session, as shown in fig. 6, a microkernel state machine sends 1407 a command, and the behavior simulation module starts ECU upgrading the entire vehicle network environment detection. The behavior simulation module needs to wake up the network, check the preconditions, send the 3E service keep diagnostic sessions, mute the multimedia interaction system MMI, command the PEPS to power up and send other diagnostic commands. The method specifically comprises the following steps:

s601, the behavior simulation module receives 1407 a command;

s602, detecting whether the protocol stack is idle, and turning to the step S603 when the protocol stack is idle, and turning to the step S6018 when the protocol stack is busy;

s603, waking up the network;

s604, detecting a precondition; the precondition may be a preset condition, such as whether the vehicle is turned off or not.

S605, maintaining the session;

s606, function addressing extension conversation;

s607, function addressing forbids DTC;

s608, the function addresses forbid communication;

s609, the function addresses 30 nodes to start BOOT;

s6010, simulating the process of entering and starting system peps messages without a key;

s6011, controlling the peps to be electrified;

s6012, keeping the MMI silent;

s6013, sending a function request 19;

the S6014, 15 node enters expansion;

s6015, 15 nodes prohibit diagnosis of fault codes (DTCs);

s6016, 15 nodes forbid communication;

s6017, 15 node programming is prohibited;

s6018, reply 1408 to the microkernel state machine.

The flow of fig. 5 further includes step S502: the pre-download mode includes three steps. Switching session nodes of a target ECU; unlocking the target ECU; and writing a flash log. If the execution is correct, the next step is entered. Otherwise, repeating retry through a retry mechanism, and reporting a flash failure result after the retry times are exceeded.

Step S503: the downloading of the SBL mode refers to the beginning of simulating the SBL part of the downloading target ECU, and the step comprises two parts: data transfer and CRC check. If both steps are performed without errors, the next step is entered. Otherwise, repeating retry through a retry mechanism, and reporting a flash failure result after the retry times are exceeded.

Step S504: the download Data file mode is a Data file portion for starting simulation of the download target ECU. This step is similar to the process of the previous step, except that the transfer data is changed from SBL to data file.

Step S503 and step S504 are core steps of the behavior simulation module, and are download simulation of the actual firmware. The main logic is as shown in fig. 7, and fig. 7 is a first flowchart of core steps of a behavior simulation module according to another embodiment of the present application, where as shown in fig. 7, a microkernel state machine sends 1503 a command to let a target ECU in the behavior simulation module enter a programming session, unlock the ECU, and write an upgrade date and a device number, and specifically includes the following steps:

s701, the behavior simulation module receives 1503 commands;

s702, detecting whether the protocol stack is idle, and turning to the step S703 when the protocol stack is idle, and turning to the step S709 when the protocol stack is busy;

s703, entering a default session by the target ECU, wherein the target ECU is the ECU to be upgraded;

s704, expanding the target ECU;

s705, the target ECU enters BOOT;

s706, enabling the target ECU to pass through 27;

s707, target ECU 2E F198;

s708, target ECU 2E F199;

s709, reply 1504 to the microkernel state machine.

Fig. 8 is a flowchart illustrating core steps of a behavior simulation module according to another embodiment of the present application, and as shown in fig. 8, the behavior simulation module sends 1511 a command to complete an actual program upgrade operation. The method specifically comprises the following steps:

s801, the behavior simulation module receives a 1511 command;

s802, detecting whether the protocol stack is busy, and when the protocol stack is busy, turning to the step S804, and when the protocol stack is idle, turning to the step S803;

s803, target ECU 34;

s804, replying to modelm 1512; when the busy protocol stack is detected in the front, the flow is ended;

s805, the target ECU36 transmits the database, and when the database transmission is completed, the process proceeds to S806, and when the database transmission is not completed, the process repeats S805;

s806, the target ECU37, and then the flow ends.

The flow of fig. 5 further includes step S505: and the post-downloading mode is mainly used for checking the integrity of the ECU after the flash is finished, and observing whether the ECU normally replies by sending a related CAN instruction. The method comprises the following specific steps: the PEPS is instructed to be powered off, and the target ECU is reset; the PEPS is instructed to be electrified, and the target ECU version number is read; the host is shut down.

Step S506: and if all the ECUs to be updated are updated, informing the vehicle CAN bus to perform reset operation.

And finishing the execution of all the processes of the high-safety flash upgrading of the ECU simulation agent.

By adopting the scheme, the following technical effects are realized: the method and the system mainly solve the problems that in the existing scheme, the safety is hard, the vehicle-mounted terminal cannot directly write the target ECU in a flash mode, and the most headache target ECU in the safety scheme fails to write in a flash mode or crashes through the virtual safety framework scheme. 2 this application needs the pain point of whole networking in the current scheme, the creative notion that has proposed ECU upgrading subassembly, will brush the write flow and all put into on-vehicle TBOX local, need not the networking and also can accomplish the work of brushing of target ECU.

The method and the device can be widely applied to the upgrading function of the vehicle-mounted terminal on the network nodes of the whole vehicle.

The scheme of another embodiment of the present application can also be completed by a plurality of ECUs in cooperation, and the firmware of all target ECUs is forwarded through the ethernet gateway. However, the biggest two drawbacks of this solution are cost and safety. The overall solution cost is dramatically increased because multiple physical ECUs are used to cooperate and must be forwarded via ethernet. In addition, there is no security simulation between the upgrading processor and the ethernet gateway and the target ECU, once the contaminated target ECU firmware is written, the firmware will be driven to the target ECU for a long time, causing damage to the ECU and further threatening the safety of the whole vehicle.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present application.

Example two

In this embodiment, an apparatus for updating the firmware of the vehicle ECU is also provided, and the apparatus is used to implement the above embodiments and preferred embodiments, which have already been described and will not be described again. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

There is also provided, in accordance with another embodiment of the present application, apparatus for updating vehicle ECU firmware, including:

the acquisition module is used for acquiring a firmware upgrading version of an ECU (electronic control unit) of the vehicle;

the simulation updating module is used for simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

and the updating module is used for updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

Through the steps, the firmware upgrading version to be updated of the vehicle ECU is obtained, then the firmware of the vehicle ECU is simulated and upgraded to the firmware upgrading version in the virtual machine, and if the simulation updating is successful, the firmware of the actual vehicle ECU is updated by the firmware upgrading version, so that the firmware updating success rate of the actual ECU is greatly improved, the problem that the vehicle cannot be started due to failure of the firmware updating of the ECU is solved, and the problem that the success rate of the ECU firmware upgrading process in the related technology is low is solved.

Optionally, the obtaining module further includes: a connection unit for connecting to a server through an in-vehicle terminal of the vehicle; and the downloading unit is used for downloading the firmware upgrading version corresponding to the ECU from the server.

Optionally, before downloading the firmware upgrade versions corresponding to the ECUs from the server, the downloading unit is further configured to detect that an update version of a firmware downloading control flow corresponding to the vehicle exists in the server when a plurality of ECUs exist in the vehicle, where the firmware downloading control flow is used to indicate a downloading order of the firmware upgrade versions of the ECUs; the firmware updating method comprises the steps of updating a firmware version of a firmware to be downloaded; and the downloading sequence of the firmware upgrading versions of the plurality of ECUs is determined according to the first firmware downloading control flow.

Optionally, after the downloading unit downloads the firmware upgrade version corresponding to the ECU from the server and stores the firmware upgrade version in the vehicle-mounted terminal, when the vehicle-mounted terminal cannot be connected to the server and is in an offline state, the simulation update module is further configured to call the firmware upgrade version already stored in the vehicle-mounted terminal to perform simulation update.

Optionally, the simulation updating module is further configured to build the virtual machine by a microkernel state machine before simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrade version.

Optionally, the simulation updating module is further configured to send, to the ECU through the microkernel state machine, an instruction for instructing to start updating the firmware after the simulation updating is successful.

Optionally, the simulation updating module is further configured to simulate, by the virtual machine, a response instruction of the ECU during firmware upgrade.

Optionally, the simulation updating module is further configured to retrieve the firmware upgrade version from the server when the updating fails.

It should be noted that, the above modules may be implemented by software or hardware, and for the latter, the following may be implemented, but not limited to: the modules are all positioned in the same processor; alternatively, the modules are respectively located in different processors in any combination.

EXAMPLE III

According to another embodiment of the present application, there is also provided a vehicle-mounted terminal, and fig. 9 is a schematic structural diagram of a vehicle-mounted terminal according to another embodiment of the present application, and as shown in fig. 9, a vehicle-mounted terminal 90 includes:

the ECU upgrading component 902 is used for requesting a firmware upgrading version of the vehicle control unit ECU from the cloud server and downloading the firmware upgrading version of the ECU to be stored locally;

and the virtual safety framework 904 is used for simulating and updating the firmware of the vehicle ECU according to the saved firmware upgrading version, and updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

By adopting the scheme, the problem that the vehicle cannot be started due to the failure of the firmware update of the ECU is avoided, and the problem that the success rate of the ECU firmware update process in the related technology is low is solved.

According to another embodiment of the present application, there is also provided a cloud server, and fig. 10 is a schematic structural diagram of a cloud server according to another embodiment of the present application, and as shown in fig. 10, a cloud server 100 includes:

the communication module 1002 is configured to receive an ECU firmware upgrade request sent by a vehicle-mounted terminal, and send an ECU firmware upgrade version to the vehicle-mounted terminal.

By adopting the scheme, the designed cloud server is fully matched with the TBOX of the vehicle to download the firmware upgrading version in an off-line manner, so that the problem that the vehicle cannot be started due to failure of firmware updating of the ECU is avoided, and the problem that the success rate of the ECU firmware upgrading process in the related technology is low is solved.

Optionally, the cloud server 100 further includes: the storage module is used for storing the firmware upgrading version of the vehicle ECU; and the synchronous management module is used for receiving the current version information of the vehicle ECU sent by the vehicle-mounted terminal and informing the vehicle-mounted terminal to update the firmware of the vehicle ECU when detecting the firmware upgrading version corresponding to the current version information.

Optionally, the cloud server 100 further includes: and the upgrade package management module is used for acquiring the firmware upgrade version of the vehicle ECU from the storage module after detecting the firmware upgrade version corresponding to the current version information, and sending the firmware upgrade version to the communication module.

Optionally, the cloud server 100 further includes: and the upgrading task management module is used for receiving indication information sent by the vehicle-mounted terminal, updating the configuration information of the vehicle ECU in the storage module after the indication information indicates that the firmware of the vehicle ECU is updated successfully, and keeping the configuration information before updating in the storage module after the indication information indicates that the firmware of the vehicle ECU is updated unsuccessfully.

The storage module, the upgrade package management module, and the upgrade task management module may be equivalent to the corresponding modules in fig. 3.

Optionally, the cloud server 100 is further provided with a storage medium for firmware version status of a plurality of ECUs of the vehicle, and version information.

Example four

Embodiments of the present application also provide a storage medium. Alternatively, in the present embodiment, the storage medium may be configured to store program codes for performing the following steps:

s1, acquiring the firmware upgrade version of the vehicle electronic control unit ECU;

s2, simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

and S3, after the simulation updating is successful, updating the firmware of the vehicle ECU by using the firmware upgrading version.

Optionally, in this embodiment, the storage medium may include, but is not limited to: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

Embodiments of the present application further provide an electronic device comprising a memory having a computer program stored therein and a processor configured to execute the computer program to perform the steps of any of the above method embodiments.

Optionally, the electronic apparatus may further include a transmission device and an input/output device, wherein the transmission device is connected to the processor, and the input/output device is connected to the processor.

Optionally, in this embodiment, the processor may be configured to execute the following steps by a computer program:

s1, acquiring the firmware upgrade version of the vehicle electronic control unit ECU;

s2, simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

and S3, after the simulation updating is successful, updating the firmware of the vehicle ECU by using the firmware upgrading version.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

It will be apparent to those skilled in the art that the modules or steps of the present application described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present application is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present application and is not intended to limit the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims (23)

1. A method of updating vehicle ECU firmware, comprising:

acquiring a firmware upgrading version of an ECU (electronic control Unit) of a vehicle;

simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

and after the simulation updating is successful, updating the firmware of the vehicle ECU by using the firmware upgrading version.

2. The method of claim 1, wherein obtaining a firmware upgrade version of a vehicle ECU comprises:

connecting to a server through a vehicle-mounted terminal of the vehicle;

and downloading the firmware upgrading version corresponding to the ECU from the server and storing the firmware upgrading version to the vehicle-mounted terminal.

3. The method of claim 2, wherein prior to downloading the firmware upgrade version corresponding to the ECU from the server, the method further comprises:

when a plurality of ECUs exist in the vehicle, detecting that an updated version of a firmware downloading control flow corresponding to the vehicle exists in the server, wherein the firmware downloading control flow is used for indicating a downloading sequence of firmware upgrading versions of the plurality of ECUs;

acquiring the updated version as a first firmware downloading control process;

and determining the downloading sequence of the firmware upgrading versions of the plurality of ECUs according to the first firmware downloading control flow.

4. The method according to claim 2, wherein after downloading the firmware upgrade version corresponding to the ECU from the server and saving the firmware upgrade version to the in-vehicle terminal, the method further comprises:

and when the vehicle-mounted terminal cannot be connected to the server and is in an off-line state, calling the firmware upgrading version stored in the vehicle-mounted terminal for simulation updating.

5. The method of claim 1, wherein prior to simulating updating firmware of a vehicle ECU in a virtual machine according to the firmware upgrade version, the method further comprises:

and constructing the virtual machine through a microkernel state machine.

6. The method of claim 5, wherein updating the firmware of the vehicle ECU using the firmware upgrade version after the simulation update is successful comprises:

and after the simulation updating is successful, sending an instruction for indicating to start updating the firmware to the ECU through the microkernel state machine.

7. The method of claim 1, wherein simulating in the virtual machine updating firmware of the vehicle ECU in accordance with the firmware upgrade version comprises:

simulating, by the virtual machine, a response instruction of the ECU during a firmware upgrade process.

8. The method according to claim 1, wherein, after simulating in the virtual machine updating of firmware of the vehicle ECU according to the firmware upgrade version, the method comprises:

and when the updating fails, the firmware upgrading version is obtained from the server again.

9. An apparatus for updating firmware of an ECU of a vehicle, comprising:

the acquisition module is used for acquiring a firmware upgrading version of an ECU (electronic control unit) of the vehicle;

the simulation updating module is used for simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version;

and the updating module is used for updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

10. The apparatus of claim 9, wherein the obtaining module further comprises:

a connection unit for connecting to a server through an in-vehicle terminal of the vehicle;

and the downloading unit is used for downloading the firmware upgrading version corresponding to the ECU from the server and storing the firmware upgrading version to the vehicle-mounted terminal.

11. The apparatus of claim 10,

before downloading the firmware upgrading versions corresponding to the ECUs from the server, the downloading unit is further configured to detect that an updated version of a firmware downloading control flow corresponding to the vehicle exists in the server when a plurality of ECUs exist in the vehicle, where the firmware downloading control flow is used to indicate a downloading order of the firmware upgrading versions of the plurality of ECUs;

the firmware updating method comprises the steps of updating a firmware version of a firmware to be downloaded;

and the downloading sequence of the firmware upgrading versions of the plurality of ECUs is determined according to the first firmware downloading control flow.

12. The apparatus according to claim 10, wherein after the downloading unit downloads the firmware upgrade version corresponding to the ECU from the server and stores the firmware upgrade version in a vehicle-mounted terminal, when the vehicle-mounted terminal cannot be connected to the server and is in an offline state, the simulation update module is further configured to invoke the firmware upgrade version already stored in the vehicle-mounted terminal to perform simulation update.

13. The apparatus of claim 9,

the simulation updating module is also used for establishing the virtual machine through a microkernel state machine before simulating and updating the firmware of the vehicle ECU in the virtual machine according to the firmware upgrading version.

14. The apparatus of claim 13,

and the simulation updating module is also used for sending an instruction for indicating to start updating the firmware to the ECU through the microkernel state machine after the simulation updating is successful.

15. The apparatus of claim 9, wherein the simulation update module is further configured to simulate, by the virtual machine, response instructions of the ECU during a firmware upgrade.

16. The apparatus of claim 9, wherein the simulation update module is further configured to retrieve the firmware upgrade version from a server if the update fails.

17. A vehicle-mounted terminal characterized by comprising:

the ECU upgrading component is used for requesting a firmware upgrading version of the vehicle control unit ECU to the cloud server and downloading the firmware upgrading version of the ECU to be stored locally;

and the virtual safety framework is used for simulating and updating the firmware of the vehicle ECU according to the saved firmware upgrading version, and updating the firmware of the vehicle ECU by using the firmware upgrading version after the simulation updating is successful.

18. A cloud server, comprising:

the communication module is used for receiving an ECU firmware upgrading request sent by a vehicle-mounted terminal and sending the ECU firmware upgrading version to the vehicle-mounted terminal.

19. The cloud server of claim 18, wherein the cloud server further comprises:

the storage module is used for storing the firmware upgrading version of the vehicle ECU;

and the synchronous management module is used for receiving the current version information of the vehicle ECU sent by the vehicle-mounted terminal and informing the vehicle-mounted terminal to update the firmware of the vehicle ECU when detecting the firmware upgrading version corresponding to the current version information.

20. The cloud server of claim 19, wherein the cloud server further comprises:

and the upgrade package management module is used for acquiring the firmware upgrade version of the vehicle ECU from the storage module after detecting the firmware upgrade version corresponding to the current version information, and sending the firmware upgrade version to the communication module.

21. The cloud server of claim 19, wherein the cloud server further comprises:

and the upgrading task management module is used for receiving indication information sent by the vehicle-mounted terminal, updating the configuration information of the vehicle ECU in the storage module after the indication information indicates that the firmware of the vehicle ECU is updated successfully, and keeping the configuration information before updating in the storage module after the indication information indicates that the firmware of the vehicle ECU is updated unsuccessfully.

22. A storage medium, in which a computer program is stored, wherein the computer program is arranged to perform the method of any of claims 1 to 8 when executed.

23. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and wherein the processor is arranged to execute the computer program to perform the method of any of claims 1 to 8.

Images