Vehicle electronic module updating method and vehicle electronic module

Abstract

The present application relates to a vehicle-mounted electronic module updating method, comprising the following steps: receiving an update instruction and update data; determining an update type according to the update instruction; and performing a corresponding update operation using the update data according to the update type.

Description

Technical Field

[0001] The present invention relates to the field of vehicle electronic technology, and in particular to a vehicle-mounted electronic module updating method and a vehicle-mounted electronic module. Background Art

[0002] With the development of automotive electronics technology and the electrification, networking, and intelligence of vehicles, the number of on-board electronic control units (ECUs) is increasing. Consequently, while their functionality is gradually increasing, their structures are also becoming increasingly complex. To meet the demands of on-board software for multi-process and file management systems, a growing number of non-entertainment system ECUs are now using the Linux operating system to replace real-time operating systems. Traditional real-time operating system refresh (also referred to as update in the context of this invention) technology involves sending commands via a tool, followed by the deletion and downloading of the entire application or calibration during the system boot mode phase. This offline refresh method, when updating applications, requires that the operating system and application be deleted and rewritten in their entirety, as even minor changes are bundled in the same file. This results in low update efficiency and a cumbersome update process.

[0003] While in some cases, using the Linux operating system to manage in-vehicle software resources as files allows for convenient control of certain memory areas, enabling multi-level file system flashing, U-Boot, as a conventional Linux system boot loader, cannot guarantee the authenticity and integrity of downloaded software through its update functionality, failing to meet in-vehicle network security requirements. U-Boot also lacks internal integration with end-to-end communication with the in-vehicle system, making it unsuitable for application or calibration updates within the automotive production line and aftermarket tool chain. Summary of the Invention

[0004] The present invention proposes an update mechanism for an on-vehicle ECU, so that the on-vehicle electronic module update method and the on-vehicle electronic module according to the present invention can update the ECU module efficiently and reliably. Specifically:

[0005] According to one aspect of the present invention, a method for updating an in-vehicle electronic module is provided, comprising the steps of: receiving an update instruction and update data; determining an update type according to the update instruction; and performing a corresponding update operation using the update data according to the update type.

[0006] Optionally, in some embodiments of the present invention, if the update type is determined to be an operating system update, the update operation includes the following steps: restarting the operating system and booting into the minimum system through U-Boot; and updating the operating system using the update data under the minimum system.

[0007] Optionally, in some embodiments of the present invention, the method further includes: verifying the signature of the update data under the minimum system, and updating the operating system if the verification passes.

[0008] Optionally, in some embodiments of the present invention, if the update type is an application update or a calibration update, the update operation includes the following steps: storing the update data in a designated storage area; and calling an operating system to perform data flashing according to the update data.

[0009] Optionally, in some embodiments of the present invention, the method further comprises: verifying the authenticity of the update data, and performing data flashing if the authenticity is verified.

[0010] According to another aspect of the present invention, there is provided an in-vehicle electronic module, comprising: a receiving unit configured to receive an update instruction and update data; a determining unit configured to determine an update type according to the update instruction; and an updating unit configured to perform a corresponding update operation using the update data according to the update type.

[0011] Optionally, in some embodiments of the present invention, if the judgment unit determines that the update type is an operating system update, the update operation performed by the update unit is: restarting the operating system and booting into the minimum system through U-Boot; and using the update data to update the operating system under the minimum system.

[0012] Optionally, in some embodiments of the present invention, the updating unit is further configured to: verify the signature of the update data under the minimum system, and update the operating system if the verification passes.

[0013] Optionally, in some embodiments of the present invention, if the judgment unit determines that the update type is an application update or a calibration update, the update operation performed by the update unit is: storing the update data to a designated storage area; and calling the operating system to perform data flashing based on the update data.

[0014] Optionally, in some embodiments of the present invention, the updating unit is further configured to: verify the authenticity of the updated data, and execute data flashing if the authenticity is verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other objects and advantages of the present invention will become more fully apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein the same or similar elements are denoted by the same reference numerals.

[0016] Figure 1 FIG. 1 illustrates an in-vehicle electronic module according to an embodiment of the present invention.

[0017] Figure 2 FIG. 1 illustrates an in-vehicle electronic module according to an embodiment of the present invention.

[0018] Figure 3 A method for updating an in-vehicle electronic module according to an embodiment of the present invention is illustrated.

[0019] Figure 4 FIG. 1 illustrates an in-vehicle electronic module according to an embodiment of the present invention. DETAILED DESCRIPTION

[0020] Because real-time operating systems can no longer meet the functional requirements of some ECUs, and general Linux file updates cannot be directly applied to the vehicle, this article proposes a secure update (or refresh) solution, as described in detail below. This solution uses the vehicle communication interface to securely update the Linux operating system itself or applications.

[0021] According to one aspect of the present invention, a method for updating a vehicle electronic module is provided. Figure 3 As shown, the vehicle electronic module updating method includes the following steps: receiving an update instruction and update data in step S31 (abbreviated as "receiving" in the figure); determining an update type according to the update instruction in step S32 (abbreviated as "determining" in the figure); and performing a corresponding update operation using the update data according to the update type in step S33 (abbreviated as "update" in the figure).

[0022] In step S31 of the update method of the present invention, an update instruction and update data are received. Generally speaking, the ECU, serving as the node to be updated, can receive an update instruction (or query, request) from an update tool (e.g., an automotive production line tool or after-sales tool). The ECU to be updated may or may not return corresponding data to the update tool, depending on its own circumstances. If the ECU accepts the update instruction, it can return a response to the update tool indicating its willingness to receive the update data. If the ECU does not accept the update instruction (e.g., certain communication protocol services do not meet the ECU system requirements), the ECU can send an error code and exit the ECU's update process (not entering the download process and, therefore, not receiving the update data). Alternatively, if the update tool does not receive a response from the ECU due to other reasons, the update tool may also exit the update process. After the ECU indicates acceptance of the update request, the update tool can send the update data to the ECU. Specifically, for example, the ECU can receive a download instruction from the update tool, then initiate a download operation and receive the update data.

[0023] In step S32 of the update method of the present invention, the update type is determined based on the update instruction. As described above, the update of the ECU may be at multiple levels (or called types, modes, etc.), that is, the update of the ECU needs to consider the update type. In some examples of the present invention, the update type can be determined based on certain parameters in the update instruction. For example, the update tool can use the update instruction to inform which type of update needs to be performed. In other examples of the present invention, the type of update to be performed can be determined based on the parameters in the update data. Of course, the type of update can also be determined by combining the two. For example, when the update types claimed by the two are inconsistent, the update can be exited, or the update type received next can be used as the basis. In other examples of the present invention, additional data can also be sent to indicate the type of update.

[0024] In step S33 of the update method of the present invention, the update data is used to perform the corresponding update operation based on the update type. In this step, the ECU can perform the update operation based on the update type determined above and the update data used for the update operation. It should be noted that the ECU has pre-specified update methods for different update types, and the update operation can be achieved by flashing the update data under the corresponding update method. The present invention does not limit the specific form of the update type, but common update types include system-level updates (e.g., Linux kernel updates, file system updates, etc.), application updates, and calibration updates.

[0025] In some embodiments of the present invention, if the update type is determined to be an operating system update, the update operation includes the following steps: restarting the operating system and booting into the minimum system through U-Boot; and updating the operating system using the update data in the minimum system.

[0026] Figure 1The diagram illustrates an in-vehicle electronic module according to one embodiment of the present invention. As shown, the ECU 10 includes U-Boot 101, a minimal system 102, a Linux kernel 103, a file system 104, and a data update area 105. U-Boot 101 is the first program accessed upon system startup and is used to boot the Linux minimal system 102. Other system update functions are disabled. Minimum system 102 is a separate component, integrating functions such as communication protocols, security key algorithms, and a Flash driver. Minimum system 102 primarily performs operations such as system file deletion, updating, and verification. After exiting the update process, the updated ECU node enters the Linux system. The Linux kernel 103 is the core of the Linux operating system. When the Linux kernel 103 boots, it boots the file system 104, where applications reside, and starts the corresponding application processes. Furthermore, applications for updates must be downloaded to a specific storage area, known as the data update area 105. The ECU 10 may also include a data storage area (not shown) for storing shared data required during ECU 10 startup and program execution.

[0027] Combine Figure 1 In the example shown, if the update to ECU 10 is a system-level update, the system will directly configure the startup parameters and restart. After the restart, the minimum system 102 will continue to receive information from the update tool, erase the corresponding partition area, download the file system content to the data update area 105, and then update the operating system based on the downloaded content.

[0028] In some embodiments of the present invention, the method further includes: verifying the signature of the update data in the minimum system, and updating the operating system if the verification passes. Continuing with the above example, after downloading the file system content to the designated area, the Linux minimum system will use the integrated key algorithm to verify the file signature of the downloaded file to ensure the authenticity and integrity of the downloaded file, and feed back the final result to the update tool. Figure 2 As shown, the minimum system 102 may include a digital signature unit 201, a diagnostic communication unit 202, and a file management unit 203. In some examples of the present invention, the digital signature unit 201 may verify the signature of a downloaded file using an integrated key algorithm. If the Linux system fails, the process will remain in the minimum system.

[0029] In some embodiments of the present invention, if the update type is an application update or a calibration update, the update operation includes the following steps: storing the updated data in a designated storage area; and invoking the operating system to perform a data flash based on the updated data. For application-layer software and calibration updates, a download process in the Linux file system can receive download instructions from the update tool and download the update package to the designated storage area. Specifically, for application-layer software or calibration updates, the download process in the Linux file system can receive download instructions from the update tool, download the update package to the designated storage area (e.g., data update area 105), and further invoke the Linux operating system to perform a file flash.

[0030] In some embodiments of the present invention, the method further includes verifying the authenticity of the update data and, if the verification is successful, executing the data flash. Continuing with the previous example, after the download is complete, the download process can be used to verify the authenticity of the file. Successful verification triggers the update process, which invokes a Linux system call to complete the file flash and feeds back the final result to the update tool.

[0031] According to another aspect of the present invention, a vehicle-mounted electronic module is provided. Figure 4 As shown, the vehicle-mounted electronic module 40 includes a receiving unit 401 , a judging unit 402 and an updating unit 403 , and data can be exchanged between the various units as needed.

[0032] The receiving unit 401 is configured to receive update instructions and update data. Generally speaking, the onboard electronic module 40, as the node to be updated, can receive update instructions (or inquiries or requests) from an update tool (e.g., an automotive production line tool or after-sales tool) via the receiving unit 401. The onboard electronic module 40 to be updated may or may not return data to the update tool, depending on its own circumstances. If the onboard electronic module 40 accepts the update instruction, it may return a response to the update tool indicating its willingness to receive the update data. If the onboard electronic module 40 does not accept the update instruction (e.g., if certain communication protocol services do not meet the system requirements of the onboard electronic module 40), the onboard electronic module 40 may send an error code and exit the update process (not entering the download process and, therefore, not receiving the update data). Alternatively, if the update tool does not receive a response from the onboard electronic module 40 due to other reasons, the update tool may also exit the update process. After the onboard electronic module 40 indicates acceptance of the update request, the update tool may send the update data to the onboard electronic module 40. Specifically, for example, the vehicle electronic module 40 may receive a download instruction sent by the update tool, and then the vehicle electronic module 40 may initiate a download operation and receive the update data. It should be noted that in some examples of the present invention, the receiving unit 401 may be responsible for the data transmission task of the vehicle electronic module 40.

[0033] The determination unit 402 is configured to determine the update type based on the update instruction. As described above, updates to the onboard electronic module 40 may occur at multiple levels (or types, modes, etc.). That is, the update type must be considered when updating the onboard electronic module 40. In some examples of the present invention, the determination unit 402 may determine the update type based on certain parameters in the update instruction. For example, the update tool may indicate which type of update is to be performed through the update instruction. In other examples of the present invention, the determination unit 402 may determine the update type based on parameters in the update data. Of course, the determination unit 402 may also determine the update type based on a combination of both. For example, if the update types claimed by the two sources are inconsistent, the update may be aborted, or the update type received later may be used as the basis. In other examples of the present invention, the update tool may also send additional data to indicate the update type.

[0034] The update unit 403 is configured to perform a corresponding update operation using the update data based on the update type. At this point, the update unit 403 can perform the update operation based on the update type determined above and the update data used for the update operation. It should be noted that the onboard electronic module 40 has pre-specified update methods for different update types, and the update operation can be achieved by flashing the update data under the corresponding update method. While the present invention does not limit the specific form of the update type, common update types include system-level updates (e.g., Linux kernel updates, file system updates, etc.), application updates, and calibration updates.

[0035] In some embodiments of the present invention, if the determination unit determines that the update type is an operating system update, the update unit performs the following update operations: restarting the operating system and booting into the minimum system via U-Boot; and updating the operating system using the update data within the minimum system. If the update to the vehicle electronic module 40 is a system-level update, the system will directly configure the startup parameters and restart. After the restart, the minimum system will continue to receive information from the update tool, erase the corresponding partition area, download the file system content to the data update area, and then update the operating system based on the downloaded content.

[0036] In some embodiments of the present invention, the update unit is further configured to verify the signature of the update data within the minimal system and, if verification passes, update the operating system. Continuing with the example above, after downloading the file system content to the designated area, the Linux minimal system uses an integrated key algorithm to verify the signature of the downloaded file, ensuring its authenticity and integrity, and then provides feedback to the update tool. If the Linux system fails, the process will remain in the minimal system.

[0037] In some embodiments of the present invention, if the determination unit determines that the update type is an application update or a calibration update, the update unit performs the following update operations: storing the updated data in a designated storage area; and invoking the operating system to perform a data flash based on the updated data. If the update involves application-layer software or calibration updates, a download process in the Linux file system can receive download instructions from the update tool and download the update package to the designated storage area. Specifically, if the update involves application-layer software or calibration updates, the download process in the Linux file system can receive download instructions from the update tool, download the update package to the designated storage area, and further invoke the Linux operating system to perform a file flash.

[0038] In some embodiments of the present invention, the update unit is further configured to verify the authenticity of the update data and, if verified, execute a data flash. Continuing with the previous example, after the download is complete, the download process can verify the authenticity of the file. Successful verification triggers the update process, which invokes a Linux system call to execute the file flash and feeds back the final result to the update tool.

[0039] In the secure refresh mechanism under the Linux environment of the present invention, some examples provide a variety of different update methods for the vehicle end, including full system refresh and app / CAL update, and meet the refresh requirements in different situations in a single mechanism. In addition, some examples of the present invention build a Linux minimum system to complete operations such as file verification / deletion / upgrade, improving the overall security of the system and meeting the trust chain requirements of in-vehicle network security. Finally, some examples of the present invention implement the function of updating the Linux file system from the vehicle communication interface by building a Linux minimum system, meeting the update requirements of the automotive tool chain.

[0040] The above examples primarily illustrate the vehicle electronic module update method and vehicle electronic module of the present invention. Although only some embodiments of the present invention have been described, those skilled in the art will appreciate that the present invention may be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments presented are to be considered illustrative rather than restrictive, and the present invention may encompass various modifications and substitutions without departing from the spirit and scope of the present invention as defined in the appended claims.

Claims

1. A method for updating a vehicle electronic module, characterized in that: The vehicle-mounted electronic module updating method comprises the following steps: receiving an update instruction and update data; Determining an update type according to the update instruction; and Perform corresponding update operations using the update data according to the update type, If the update type is determined to be an operating system update, the update operation includes the following steps: Restart the operating system and boot into the minimal system through U-Boot; and Using the update data to update the operating system under the minimum system, If the update type is an application update or a calibration update, the update operation includes the following steps: storing the updated data in a designated storage area; and The operating system is called to execute data flashing according to the update data.

2. The vehicle-mounted electronic module updating method according to claim 1, characterized in that: The vehicle-mounted electronic module updating method further includes: verifying the signature of the update data under the minimum system, and updating the operating system if the verification passes.

3. The vehicle-mounted electronic module updating method according to claim 1, characterized in that: The vehicle-mounted electronic module updating method further includes: verifying the authenticity of the update data, and executing data flashing if the authenticity is verified.

4. A vehicle-mounted electronic module, characterized in that: The modules include: a receiving unit configured to receive an update instruction and update data; a determination unit configured to determine an update type according to the update instruction; and an updating unit configured to perform a corresponding updating operation using the updating data according to the updating type, If the determination unit determines that the update type is an operating system update, the update unit performs the following update operations: Restart the operating system and boot into the minimal system through U-Boot; and Using the update data to update the operating system under the minimum system, If the determination unit determines that the update type is an application update or a calibration update, the update operation performed by the update unit is: storing the updated data in a designated storage area; and The operating system is called to execute data flashing according to the update data.

5. The module according to claim 4, characterized in that The updating unit is further configured to verify the signature of the update data under the minimum system, and update the operating system if the verification passes.

6. The module according to claim 4, characterized in that The updating unit is further configured to verify the authenticity of the updating data and execute data flashing if the authenticity is verified.

7. A computer program product, characterized in that The computer program product includes instructions, and when the instructions are executed by a processor, the method for updating an in-vehicle electronic module according to any one of claims 1 to 3 is implemented.

Images