Vehicle-mounted software upgrading method and system and vehicle

Abstract

The invention discloses a vehicle-mounted software upgrading method and system and a vehicle, and belongs to the technical field of vehicle-mounted software, and the vehicle-mounted software upgrading method comprises the steps that a software package is analyzed to determine ECU slave modules needing to be upgraded so as to accurately screen out modules actually needing to update software; each ECU slave module needing to be upgraded is upgraded, the upgrading state of each ECU slave module is marked in the corresponding state memory, and according to statistical analysis of the upgrading states of a large number of vehicles, modules or links prone to having upgrading problems are found out, so that the upgrading process and the software quality can be optimized in a targeted mode; by considering the dependency relationship, the collaboration and stability of the whole vehicle electronic system can be guaranteed, the situation that all modules are forced to stop running or roll back to the old version due to failure of part of modules is avoided, and it is guaranteed that the system can be in smooth transition in the upgrading process and continuously and stably exert functions.

Description

Technical Field

[0001] The present invention relates to the field of vehicle-mounted software technology, and more specifically, to a vehicle-mounted software upgrading method, system and vehicle. Background Art

[0002] At present, cars are generally equipped with OTA (Over-The-Air, air download technology) upgrade function system, so that cars can still perform software function iteration after delivery to users, so that vehicles are often used and always new, which continuously brings value to users and enhances user experience. As the level of automobile intelligence becomes higher and higher, the use of various types of on-board controllers ECU (electronic control unit) is increasing, and the network communication architecture of cars is becoming more and more complex. In order to have the ability to iterate software functions, these ECUs usually need to support OTA upgrades. This brings great challenges to the OTA system itself. For example, the upgrade of domain control, the upgrade of ordinary CAN controller, the upgrade of slave module, etc., all require OTA system alignment for upgrade operations. Any type of ECU is equally important to the OTA upgrade system.

[0003] The current OTA system of smart new energy passenger cars can usually upgrade various controller ECUs of the entire vehicle. From the perspective of network communication topology, some of these ECUs are master modules and some are slave modules. From the perspective of the main business process of OTA upgrade, generally only the upgrade results fed back by the master module are considered, and whether the slave module upgrade is successful is determined by the master module. Under the increasingly complex network topology architecture, this approach is more conducive to the rationalization of the overall OTA process, and at the same time, each master module does not need to develop a communication routing gateway function specifically for the upgrade needs.

[0004] However, the existing software upgrade model also has the following defects: in the OTA main process, whether the upgrade of the slave module is successful is not visible to the OTA-Master. The OTA-Master does not know the actual upgrade status and specific process status of the slave module, and is unable to make more accurate decisions. If there are multiple slave modules under the main module, when a slave module fails, the main module will feedback the failure to the OTA-Master, resulting in the failure of the current vehicle upgrade task, and even the need for version rollback, causing more risks. Summary of the invention

[0005] An object of the present invention is to provide a vehicle-mounted software upgrade method, system and vehicle to solve the problems that whether the upgrade of the aforementioned ECU slave module is successful is not visible to the OTA management master node, and a more accurate decision cannot be made, and when a slave module fails, the current vehicle upgrade task fails.

[0006] According to a first aspect of the present invention, there is provided a method for upgrading vehicle software, comprising the following steps:

[0007] Step 1: Obtain the software package delivered by the upstream, which contains update content for multiple ECU slave modules;

[0008] Step 2: Parse the software package to determine the ECU slave module that needs to be upgraded;

[0009] Step 3: Check the current software version of each ECU slave module that needs to be upgraded and compare it with the version in the software package;

[0010] Step 4: Determine whether an upgrade is needed based on the comparison results;

[0011] Step 5: Each ECU slave module that needs to be upgraded is upgraded respectively, and the upgrade status of each ECU slave module is marked in the corresponding status memory, and the upgrade status includes upgrade success or upgrade failure;

[0012] Step 6: Check whether there is a dependency between the software upgrades of the ECU slave modules. If there is no dependency between the ECU slave modules, the ECU slave modules that failed to be upgraded among the ECU slave modules will retry the upgrade, while the ECU slave modules that successfully upgraded will continue to operate normally.

[0013] Optionally, based on the information marked in the state memory, the ECU slave module that failed to upgrade is retried to upgrade, and the result of the retried upgrade is fed back to the OTA management master node.

[0014] Optionally, the OTA management master node evaluates whether the upgrade task of the entire vehicle is successful based on the received status information, and reports the evaluation result to the OTA cloud for subsequent operations.

[0015] Optionally, subsequent operations include, but are not limited to, one or more of retrying the upgrade, recording an upgrade log, and notifying a user.

[0016] Optionally, in step 4, if the current version number of the ECU slave module is lower than the new version number provided in the software package, the ECU slave module is marked as requiring an upgrade.

[0017] According to a second aspect of the present invention, a vehicle software upgrade system is provided, which is applied to an ECU unit, wherein the ECU unit includes an ECU master module and a plurality of ECU slave modules, wherein the ECU master module includes a main control unit (MCU) and a flash writer which are independently arranged, wherein:

[0018] A main control unit, used for obtaining a software package transmitted from an upstream, wherein the software package includes update contents for multiple ECU slave modules;

[0019] The flash writer unit is used to parse the software package, determine the ECU slave modules that need to be upgraded, check the current software version of each ECU slave module that needs to be upgraded, and compare it with the version in the software package, and determine whether an upgrade is required based on the comparison result; and upgrade each ECU slave module that needs to be upgraded, and mark the upgrade status of each ECU slave module in the corresponding status memory, where the upgrade status includes upgrade success or upgrade failure.

[0020] Optionally, the flash writer unit includes:

[0021] A communication interface, through which the flash writer unit communicates with the main control unit to receive new software package information; the communication interface adopts serial communication, parallel communication or network communication;

[0022] Multiple status memories, used to record the upgrade status of each ECU slave module;

[0023] A refresh controller is used to coordinate data transmission between a communication interface and a plurality of state memories, and to execute various control logics in a refresh process. The refresh controller is configured as any one of a microcontroller, an FPGA (field programmable gate array), and an ASIC (application-specific integrated circuit).

[0024] Optionally, the flash writer unit further includes a security control component, which includes an encryption algorithm processor and a digital signature verifier for encrypting, decrypting and verifying the signature of the software package information.

[0025] According to a third aspect of the present invention, there is provided a vehicle, the vehicle comprising:

[0026] one or more processors;

[0027] A memory for storing one or more programs;

[0028] When the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle software upgrade method described in the first aspect of the present invention.

[0029] The vehicle software upgrade method, system and vehicle disclosed in the present invention have the following technical effects:

[0030] The refresh function of the ECU main module is separated from the MCU to form a main control unit and a flash writer that are independently set up. The ECU main module can record the upgrade result information of each ECU slave module in detail and report it to the OTA cloud, instead of the previous feedback of overall failure as long as one ECU slave module fails, so that the entire software upgrade task will not be judged as a failure due to the failure of one ECU slave module;

[0031] The ECU master module can report the upgrade results of each ECU slave module in the domain in detail, so that the OTA management master node can compare the task logic obtained from the OTA cloud and provide a decision basis for the next operation, rather than directly determining failure.

[0032] Further features and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the present invention with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

[0034] Figure 1 A schematic diagram of a process flow of a vehicle software upgrade method provided by an embodiment of the present invention;

[0035] Figure 2 A schematic diagram of the structure of a vehicle software upgrade system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0036] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that the relative arrangement of components and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present invention unless otherwise specifically stated.

[0037] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.

[0038] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.

[0039] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values.

[0040] The present invention proposes an embodiment of a vehicle software upgrade method. Specifically, Figure 1 As shown, the following steps are included:

[0041] Step 1: Obtain a software package delivered by an upstream source, which contains update content for multiple ECU slave modules; the upstream source is, for example, a car manufacturer's server, and the update content includes information for fixing vulnerabilities, adding new features, or optimizing performance for multiple ECU units installed on the vehicle.

[0042] Step 2: Parse the software package to determine the ECU slave module that needs to be upgraded;

[0043] Step 3: Check the current software version of each ECU slave module that needs to be upgraded and compare it with the version in the software package; for example, compare the model, serial number, hardware version and other information of the version.

[0044] Step 4: Determine whether an upgrade is required based on the comparison results; based on the version comparison results, the system decides whether the ECU slave module needs to be upgraded. If the current version is lower than the version in the software package, an upgrade is required; if the current version is already the latest, skip the upgrade of the ECU slave module.

[0045] Step 5: Each ECU slave module that needs to be upgraded is upgraded separately, and the upgrade status of each ECU slave module is marked in the corresponding state memory, and the upgrade status includes upgrade success or upgrade failure; establish communication with each ECU slave module that needs to be upgraded through the vehicle's communication network (such as CAN bus, FlexRay, Ethernet, etc.). After the communication is established, a security check is performed, such as verifying the identity of the ECU slave module, etc., and the upgraded file is transferred to the target ECU slave module. During the transmission process, a check code or hash value is used to verify the integrity of each data packet. The state memory is, for example, a non-volatile memory inside the ECU (such as EEPROM, Flash memory), and the upgrade status includes "upgrade success", "upgrade failure", "upgrading", etc. By recording the upgrade status of each ECU slave module, a detailed upgrade report and fault information can be provided to the owner or maintenance personnel.

[0046] Step 6: Check whether there is a dependency between the software upgrades of the ECU slave modules. If there is no dependency between the ECU slave modules, the ECU slave modules that failed to be upgraded among the ECU slave modules will retry the upgrade, while the ECU slave modules that successfully upgraded will continue to operate normally.

[0047] It should be noted that different ECU slave modules undertake different functions such as controlling engine operation, managing the in-vehicle entertainment system, and monitoring the vehicle safety status. The software upgrades between these ECU slave modules may be interdependent. For example, the software upgrade of an ECU slave module responsible for vehicle power transmission control depends on the upgrade of another ECU slave module responsible for sensor data acquisition and preprocessing. This is because the new power control software needs to use the more accurate and more format-matched data from the upgraded sensor module to run normally. Therefore, it is necessary to check and confirm whether there is such a sequential constraint and interdependence between these ECU slave modules.

[0048] The failure of upgrading the ECU slave module may be caused by incomplete download of the software package due to network transmission interruption, errors when writing the new software code to the storage unit, or temporary hardware failure. Retrying the upgrade includes re-downloading the software package, re-checking the written data, and other operations. For the ECU slave module that has successfully completed the software upgrade, it can normally participate in the operation of the entire vehicle system according to the functional logic set by the new software version. If there is a dependency relationship between the ECU slave modules, the upgrade failure of one of the ECU slave modules will be the failure of the upgrade report of the overall ECU main module. The method of classifying and processing according to the dependency relationship in the embodiment of the present invention helps to clearly locate which ECU slave modules are prone to problems during the upgrade process, which is convenient for technicians to analyze in a targeted manner whether the upgrade failure is caused by compatibility issues of the software itself or hidden faults at the hardware level, and provides strong data support and management convenience for optimizing subsequent upgrade processes, improving software version quality, and doing hardware maintenance in advance.

[0049] In an embodiment of the present invention, according to the information marked in the state memory, the ECU slave module that failed to upgrade is retried to upgrade, and the result of the retried upgrade is fed back to the OTA management master node. Specifically, the retried upgrade will take some additional measures based on the previously marked failure reasons. For example, if the marking information shows that the failure is caused by a network connection problem, the network channel will be switched or the stability check of the network connection will be increased when the upgrade is retried; if it is a checksum mismatch problem, the data verification link will be strengthened after the software package is re-downloaded. The feedback result information includes whether the upgrade is successful, the new reason code if it fails again, the time taken to upgrade, etc. Based on this feedback information, the OTA management master node further decides whether it needs to retry again, whether it needs to adjust the entire upgrade strategy, or report the upgrade status to the user or administrator.

[0050] In an embodiment of the present invention, the OTA management master node evaluates whether the upgrade task of the entire vehicle is successful based on the received status information, and reports the evaluation result to the OTA cloud for subsequent operations, which include but are not limited to one or more of retrying the upgrade, recording the upgrade log, and notifying the user.

[0051] Specifically, when the vehicle receives the upgrade command from the OTA cloud, the OTA management master node begins to coordinate the upgrade of each module. During the entire upgrade process, it continuously collects status information from all aspects. For example, the radar sensor module in the automatic driving assistance system reported that the upgrade process went smoothly and the new software version was successfully installed; however, the in-vehicle entertainment system module reported that when downloading the upgrade package, the network signal weakened due to the vehicle entering the underground parking lot, resulting in partial data loss and the upgrade failure. In the subsequent retry process, the power management strategy was adjusted after the vehicle was started, temporarily interrupting the upgrade process, and the upgrade was still not successful.

[0052] After the OTA management master node summarizes this information, it determines that the vehicle upgrade task has partially failed according to the established evaluation rules. Then, the evaluation results are sent to the OTA cloud. After receiving it, the OTA cloud analyzes that the failure is mainly affected by the network conditions. Therefore, when the vehicle is parked and the network signal is good, the upgrade command is pushed to the vehicle again, and the download method of the upgrade package is appropriately adjusted. The method of segmented download and real-time verification is adopted to improve the success rate of the next upgrade and ensure that all modules of the vehicle can be successfully upgraded in the end.

[0053] In the embodiment of the present invention, in step 4, if the current version number of the ECU slave module is lower than the new version number provided in the software package, the ECU slave module is marked as requiring an upgrade.

[0054] The present invention also provides an embodiment of a vehicle software upgrade system, specifically as follows Figure 2 As shown, the vehicle software upgrade system is applied to an ECU unit, the ECU unit includes an ECU master module and multiple ECU slave modules, the ECU master module includes a main control unit and a flash writer that are independently set, wherein:

[0055] A main control unit, used for obtaining a software package transmitted from an upstream, wherein the software package includes update contents for multiple ECU slave modules;

[0056] The flash writer unit is used to parse the software package, determine the ECU slave modules that need to be upgraded, check the current software version of each ECU slave module that needs to be upgraded, and compare it with the version in the software package, and determine whether an upgrade is required based on the comparison result; and upgrade each ECU slave module that needs to be upgraded, and mark the upgrade status of each ECU slave module in the corresponding status memory, where the upgrade status includes upgrade success or upgrade failure.

[0057] It should be noted that the flash writer unit determines which ECU slave modules need to be upgraded based on the parsed software package content and the actual software status of each ECU slave module. For example, the software package contains updates for the ECU slave modules related to the vehicle entertainment system and the braking system, but after inspection, it is found that the current software version of a certain ECU slave module of the vehicle entertainment system is consistent with that in the software package, so it does not need to be upgraded, while the software version of the relevant ECU slave module of the braking system is lower, so it is determined to be the object that needs to be upgraded. Through the analysis of the software package by the flash writer unit and the detailed comparison with the current software version of each ECU slave module, it is possible to accurately determine which slave modules really need to be upgraded, avoiding unnecessary upgrade operations. Through the marking of the status memory, users can intuitively understand the progress of the vehicle software upgrade. When maintenance personnel encounter problems related to vehicle software, they can quickly check the upgrade status to determine whether the fault may be caused by an upgrade failure.

[0058] In an embodiment of the present invention, the flash writer unit includes:

[0059] A communication interface, through which the flash writer unit communicates with the main control unit to receive new software package information; the communication interface adopts serial communication, parallel communication or network communication; specifically, the flash writer unit receives the software package forwarded by the main control unit from the remote server through the in-vehicle network (such as CAN bus, etc.) or the wireless communication network (such as 4G, 5G, etc.);

[0060] Multiple state memories are used to record the upgrade status of each ECU slave module. Each state memory can accurately track the upgrade trajectory of each ECU slave module, providing detailed data support for subsequent query, analysis and further processing of upgrade-related issues.

[0061] The refresh controller is used to coordinate the data transmission between the communication interface and multiple state memories, and to execute various control logics in the refresh process. The refresh controller is configured as any one of a microcontroller, an FPGA (field programmable gate array), and an ASIC (application-specific integrated circuit). Specifically, when the communication interface receives the software package information from the main control unit, the refresh controller will direct the data to flow to the corresponding location accurately in the appropriate order and at the appropriate time, such as storing the relevant information of the ECU slave module currently being upgraded in the corresponding state memory, or reading the upgrade status of a previous module from the state memory to determine the next operation, etc. When a data verification error is detected in a certain ECU slave module during the flashing process, the refresh controller will suspend the flashing according to the set logic, record the error information to the corresponding state memory, and then try to flash again or take other remedial measures.

[0062] Specifically, the refresh controller instructs the communication interface to perform preliminary analysis and classification of the received software package data. For example, it extracts the update data related to the engine control module, and then interacts with the corresponding state memory to query the previous upgrade history of the engine control module and determine whether the upgrade conditions are met (such as whether the current version is lower than the target version in the software package, etc.). After determining that the upgrade is possible, the refresh controller will gradually and orderly write the update data to the engine control module according to the set control logic. During this process, the data transmission status and the module feedback information are monitored in real time. If everything goes well and the engine control module completes the upgrade, the refresh controller will record the status information of "upgrade successful" in the corresponding state memory; if there is an unexpected situation such as data loss caused by network signal interruption, the refresh controller will suspend the flashing operation, record the error information, and try to re-initiate the flashing, and mark "upgrade failed" in the state memory and record the specific error details to facilitate subsequent maintenance personnel to view and handle.

[0063] In an embodiment of the present invention, the flash writer unit also includes a security control component, which includes an encryption algorithm processor and a digital signature verifier, which is used to encrypt, decrypt and verify the software package information. For example, when a software package containing the optimization of the vehicle's automatic driving function is pushed via OTA, the encryption algorithm processor will use a predetermined encryption algorithm and key on the server side to encrypt the entire content of the software package, and then send the ciphertext out. After the flash writer unit receives the software package in ciphertext form, it also uses the corresponding decryption key to perform a decryption operation through the encryption algorithm processor to restore the original software package content, thereby ensuring the confidentiality of the software package during transmission. After receiving the software package, the digital signature verifier will first obtain the digital signature attached to the software package, and then use the corresponding public key of the sender to verify the validity of the signature. When the flash writer unit of the vehicle receives the ciphertext software package with a digital signature through the communication interface, the encryption algorithm processor of the security control component uses the decryption key pre-stored on the vehicle side and matching the server side to decrypt the ciphertext software package and try to restore the original software package content. Next, the digital signature verifier obtains the digital signature attached to the software package and uses the public key disclosed by the car manufacturer to verify the authenticity and validity of the signature.

[0064] The present invention also provides an embodiment of a vehicle, the vehicle comprising:

[0065] one or more processors;

[0066] A memory for storing one or more programs;

[0067] When the one or more programs are executed by the one or more processors, the one or more processors implement the above-mentioned vehicle software upgrade method.

[0068] The vehicle software upgrade solution of the present invention upgrades each ECU slave module that needs to be upgraded separately, and marks the upgrade status of each ECU slave module in the corresponding state memory. It can find out the modules or links that are prone to upgrade problems based on the statistical analysis of the upgrade status of a large number of vehicles, so as to optimize the upgrade process and software quality in a targeted manner; considering the dependency relationship can ensure the coordination and stability of the entire vehicle electronic system, avoid forcing all modules to stop running or roll back to the old version due to the failure of some modules, and ensure that the system can smoothly transition during the upgrade process and continue to function stably. The present invention makes efforts in many aspects, such as reasonably screening upgrade objects, accurately confirming upgrade requirements, effectively executing upgrade operations, and properly handling subsequent upgrade situations, to ensure the efficiency, accuracy, stability and safety of the vehicle software upgrade process, improve the overall performance and function of the vehicle electronic system, and also facilitate relevant personnel to manage, monitor and troubleshoot the upgrade process.

[0069] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings, but the above is only a preferred embodiment of the present invention. It should be noted that the technical features involved in the above embodiments and their preferred methods can be reasonably combined and matched into a variety of equivalent schemes by those skilled in the art without departing from or changing the design ideas and technical effects of the present invention; therefore, the present invention is not limited to the scope of implementation shown in the drawings, and all changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which still do not exceed the spirit covered by the specification and drawings, should be within the protection scope of the present invention.

Claims

1. A vehicle software upgrade method, characterized in that: The following steps are involved: Step 1: Obtain the software package delivered by the upstream, which contains update content for multiple ECU slave modules; Step 2: Parse the software package to determine the ECU slave module that needs to be upgraded; Step 3: Check the current software version of each ECU slave module that needs to be upgraded and compare it with the version in the software package; Step 4: Determine whether an upgrade is needed based on the comparison results; Step 5: Each ECU slave module that needs to be upgraded is upgraded respectively, and the upgrade status of each ECU slave module is marked in the corresponding status memory, and the upgrade status includes upgrade success or upgrade failure; Step 6: Check whether there is a dependency between the software upgrades of the ECU slave modules. If there is no dependency between the ECU slave modules, the ECU slave modules that failed to be upgraded among the ECU slave modules will retry the upgrade, while the ECU slave modules that successfully upgraded will continue to operate normally.

2. The vehicle software upgrade method according to claim 1, characterized in that: According to the information marked in the status memory, the ECU slave module that failed to upgrade is retried and the result of the retry upgrade is fed back to the OTA management master node.

3. The vehicle software upgrade method according to claim 2, characterized in that: The OTA management master node evaluates whether the upgrade task of the entire vehicle is successful based on the received status information, and reports the evaluation results to the OTA cloud for subsequent operations.

4. The vehicle software upgrade method according to claim 3, characterized in that: Subsequent operations include, but are not limited to, one or more of retrying the upgrade, recording an upgrade log, and notifying the user.

5. The vehicle software upgrade method according to claim 1, characterized in that: In step 4, if the current version number of the ECU slave module is lower than the new version number provided in the software package, the ECU slave module is marked as requiring an upgrade.

6. A vehicle software upgrade system, characterized in that: Applied to an ECU unit, the ECU unit includes an ECU master module and multiple ECU slave modules, the ECU master module includes a main control unit (MCU) and a flash writer that are independently set, wherein: A main control unit, used for obtaining a software package transmitted from an upstream, wherein the software package includes update contents for multiple ECU slave modules; The flash writer unit is used to parse the software package, determine the ECU slave modules that need to be upgraded, check the current software version of each ECU slave module that needs to be upgraded, and compare it with the version in the software package, and determine whether an upgrade is required based on the comparison result; and upgrade each ECU slave module that needs to be upgraded, and mark the upgrade status of each ECU slave module in the corresponding status memory, where the upgrade status includes upgrade success or upgrade failure.

7. The vehicle software upgrade system according to claim 6, characterized in that: The flash writer unit comprises: A communication interface, through which the flash writer unit communicates with the main control unit to receive new software package information; the communication interface adopts serial communication, parallel communication or network communication; Multiple status memories, used to record the upgrade status of each ECU slave module; A refresh controller is used to coordinate data transmission between a communication interface and a plurality of state memories, and to execute various control logics in a refresh process. The refresh controller is configured as any one of a microcontroller, an FPGA (field programmable gate array), and an ASIC (application-specific integrated circuit).

8. The vehicle software upgrade system according to claim 7, characterized in that: The flash writer unit further includes a security control component, which includes an encryption algorithm processor and a digital signature verifier for encrypting, decrypting and verifying the signature of the software package information.

9. A vehicle, characterized in that: The vehicle comprises: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle software upgrade method as described in any one of claims 1 to 5.

Images