Software upgrade method, system and terminal device

Abstract

This application relates to the field of vehicle-to-everything (V2X) communication technology, and discloses a software upgrade method, system, and terminal device. The software upgrade method of this application includes: a third upgrade management module detecting first upgrade data corresponding to a first upgrade management module, and sending the first upgrade data to the first upgrade management module based on a first communication protocol; the first upgrade management module converting the first upgrade data in a first format into second upgrade data in a second format; the third upgrade management module detecting third upgrade data corresponding to a second upgrade management module, and sending the third upgrade data to the second upgrade management module based on the first communication protocol; and the second upgrade management module converting the third upgrade data in the first format into fourth upgrade data in a third format. This application can achieve unified scheduling and efficient management of the software program upgrade process by having the third upgrade management module adopt the same upgrade strategy formulation method for both the first and second upgrade management modules.

Description

Technical Field

[0001] This application relates to the field of vehicle-to-everything (V2X) communication technology, and in particular to a software upgrade method, system, and terminal device. Background Technology

[0002] In order to respond to changes in market demands in the automotive industry, such as rapid defect repair and timely deployment of new features, onboard controllers, such as the bootloader in a microprocessor unit (MPU), can obtain the latest version upgrade package of the software to be upgraded when a new software upgrade request is detected, thereby upgrading the software to the latest version.

[0003] Currently, to meet diverse functional requirements, vehicle MPUs generally adopt a multi-core heterogeneous design. While this design enhances MPU performance, it also makes the software architecture increasingly complex. Furthermore, due to the different functional roles of MPUs in different functional domains, the underlying operating system kernels of the MPUs also exhibit diverse characteristics. This internal and cross-MPU software architecture difference and complexity means that the upgrade package for each MPU needs to be customized for each MPU's characteristics. That is, each MPU's bootloader maintains a connection with each upgrade management module in the corresponding server, and each MPU's upgrade package requires the corresponding upgrade management module to formulate an upgrade strategy. This makes the formulation of upgrade strategies extremely difficult, hindering unified standardization and making centralized and efficient management of software versions and upgrade tasks impossible. Summary of the Invention

[0004] To address the problem of the inability to centrally and efficiently manage software versions and upgrade tasks, embodiments of this application provide a software upgrade method, system, and terminal device.

[0005] In a first aspect, embodiments of this application provide a software upgrade method. The software upgrade method is applied to a software upgrade system, which includes a terminal device and a server. The terminal device includes a first upgrade management module and a second upgrade management module, and the server includes a third upgrade management module. The method includes: the third upgrade management module detecting first upgrade data corresponding to the first upgrade management module, and sending the first upgrade data to the first upgrade management module based on a first communication protocol, wherein the first upgrade data is in a first format; the first upgrade management module converting the first upgrade data into second upgrade data, wherein the second upgrade data is in a second format; and the first upgrade management module upgrading the software program corresponding to the second upgrade data based on the second upgrade data; the third upgrade module detecting third upgrade data corresponding to the second upgrade module, and sending the third upgrade data to the second upgrade module based on the first communication protocol, wherein the third upgrade data is in a first format; and the second upgrade module converting the third upgrade data into fourth upgrade data, wherein the fourth upgrade data is in a third format; and the second upgrade module upgrading the software program corresponding to the fourth upgrade data based on the fourth upgrade data.

[0006] In this way, the server's third upgrade management module can adopt the same upgrade strategy for each software program on the terminal device. Furthermore, the server's third upgrade management module can indirectly schedule and manage the upgrade process of each software program on the terminal device in a unified and efficient manner by controlling the upgrade management module of the terminal device, thus ensuring the coordination and efficient execution of the upgrade process.

[0007] In one possible implementation, the terminal device includes a first MPU node and a second MPU node. The first upgrade management module is used to upgrade the software program corresponding to the first MPU node, and the second upgrade management module is used to upgrade the software program corresponding to the second MPU node.

[0008] In one possible implementation, the first communication protocol is a high-speed, high-bandwidth transmission protocol, which includes any one of the following: Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), File Transfer Protocol (FTP), Diagnostics over IP (DOIP), and full-duplex communication protocol (WebSocket).

[0009] In one possible implementation, the third upgrade management module detects the first upgrade data corresponding to the first upgrade management module and sends the first upgrade data to the first upgrade management module based on the first communication protocol. This includes: the third upgrade management module detects the first upgrade data corresponding to the first upgrade management module and sends a first task establishment request to the first upgrade management module based on the first communication protocol; the first upgrade management module receives the first task establishment request and sends a first task feedback request to the third upgrade management module based on the first communication protocol; corresponding to the first task feedback request indicating that the terminal device has not installed the first upgrade data, the third upgrade management module sends the first upgrade data to the first upgrade management module based on the first communication protocol.

[0010] In one possible implementation, the first upgrade data and the third upgrade data include upgrade data, message type, MPU node identifier, upgrade task name, and upgrade data volume.

[0011] In one possible implementation, corresponding to the third upgrade management module determining that the upgrade of the software program corresponding to the first upgrade data has failed, the third upgrade management module sends a rollback request to the first upgrade management module. The rollback request is used to change the version of the software program corresponding to the first upgrade data from the version corresponding to the first upgrade data to the version before the upgrade.

[0012] In one possible implementation, corresponding to the third upgrade management module determining that the software program corresponding to the first upgrade data has failed to upgrade, the software program corresponding to the third upgrade data has successfully upgraded, and the correlation between the first MPU corresponding to the first upgrade management module and the second MPU corresponding to the second upgrade management module is greater than the correlation threshold, the third upgrade management module sends a rollback request to both the first upgrade management module and the second upgrade management module.

[0013] In one possible implementation, the terminal device is an in-vehicle device.

[0014] Secondly, embodiments of this application also provide a software upgrade method, which is applied to a terminal device. The terminal device includes a first upgrade management module and a second upgrade management module. The method includes: the first upgrade management module receiving first upgrade data from a third upgrade management module based on a first communication protocol, converting the first upgrade data into second upgrade data, and upgrading the software program corresponding to the second upgrade data based on the second upgrade data. The first upgrade data is in a first format, and the second upgrade data is in a second format. The second upgrade management module receiving third upgrade data from the third upgrade module based on the first communication protocol, converting the third upgrade data into fourth upgrade data, and upgrading the software program corresponding to the fourth upgrade data based on the fourth upgrade data. The third upgrade data is in a first format, and the fourth upgrade data is in a third format.

[0015] Thirdly, embodiments of this application provide a software upgrade system, which includes a terminal device and a server. The terminal device includes a first upgrade management module and a second upgrade management module, and the server includes a third upgrade management module. The system includes: the third upgrade management module detecting first upgrade data corresponding to the first upgrade management module, and sending the first upgrade data to the first upgrade management module based on a first communication protocol, wherein the format of the first upgrade data is a first format; the first upgrade management module converting the first upgrade data into second upgrade data, wherein the second upgrade data is in a second format, and the first upgrade management module upgrading the software program corresponding to the second upgrade data based on the second upgrade data; the third upgrade module detecting third upgrade data corresponding to the second upgrade module, and sending the third upgrade data to the second upgrade module based on the first communication protocol, wherein the format of the third upgrade data is a first format; the second upgrade module converting the third upgrade data into fourth upgrade data, wherein the fourth upgrade data is in a third format, and the second upgrade module upgrading the software program corresponding to the fourth upgrade data based on the fourth upgrade data.

[0016] Fourthly, embodiments of this application provide a terminal device, including a memory for storing instructions executed by one or more processors of an electronic device; and a processor, one of the processors of the electronic device, for executing the instructions stored in the memory to implement any of the software upgrade methods provided by the second aspect and various possible implementations of the second aspect. Attached Figure Description

[0017] Figure 1 A schematic diagram of the architecture of a software upgrade system is shown.

[0018] Figure 2 According to an embodiment of this application, a schematic diagram of the architecture of a software upgrade system is shown;

[0019] Figure 3 According to an embodiment of this application, an interactive schematic diagram of a software upgrade method is shown;

[0020] Figure 4 According to an embodiment of this application, an interactive schematic diagram of an upgrade task creation method is shown;

[0021] Figure 5 According to an embodiment of this application, an interactive schematic diagram of an upgrade packet transmission method is shown;

[0022] Figure 6 According to an embodiment of this application, an interactive schematic diagram of an upgrade package installation method is shown;

[0023] Figure 7 According to an embodiment of this application, an interactive schematic diagram of a software program activation method corresponding to an upgrade package is shown;

[0024] Figure 8 According to an embodiment of this application, an interactive schematic diagram of a software rollback method is shown;

[0025] Figure 9 According to an embodiment of this application, a schematic diagram of the state changes of the upgrade state machine corresponding to the in-vehicle upgrade management module is shown when each MPU node in the vehicle-mounted device 100 is upgraded.

[0026] Figure 10 According to an embodiment of this application, a structural schematic diagram of an in-vehicle device 100 is shown. Detailed Implementation

[0027] The illustrative embodiments of this application include, but are not limited to, a software upgrade method, system, and terminal device.

[0028] Against the backdrop of rapid development in automotive electronic and electrical architecture, on-board controllers are undergoing a transformation from single-function microcontroller units (MCUs) to high-performance, cross-domain integrated MPUs. This transformation places higher demands on software architecture design, emphasizing a balance between complexity and flexibility. In this context, the functional scope of MPUs continues to expand, and the software architecture is becoming increasingly large and complex.

[0029] Currently, MPUs commonly employ multi-core heterogeneous designs to meet diverse functional requirements. While this design enhances MPU performance, it also leads to increasingly complex software architectures. Furthermore, due to the different functional roles of each MPU domain, their underlying operating system kernels also exhibit diverse characteristics. This internal and cross-MPU software architectural variation and complexity necessitates that each MPU's upgrade package be customized to the specific characteristics of each MPU.

[0030] Figure 1 This diagram illustrates the architecture of a software upgrade system. Figure 1 As shown, the vehicle-mounted equipment 100 includes a first MPU, a second MPU, and a third MPU, and the first MPU, second MPU, and third MPU adopt different software architectures, such as... Figure 1As shown, the bootloader of the first MPU can obtain and parse the upgrade package sent by the upgrade management module 1 that meets the characteristics of the first MPU from the server 200; the bootloader of the second MPU can obtain and parse the upgrade package sent by the upgrade management module 2 that meets the characteristics of the second MPU from the server 200; and the bootloader of the third MPU can obtain and parse the upgrade package sent by the upgrade management module 3 that meets the characteristics of the third MPU from the server 200. That is, each MPU's bootloader in the vehicle-mounted device maintains a connection with each upgrade management module in the corresponding server. This means that each MPU in the vehicle-mounted device 100 requires a corresponding upgrade management module to formulate an upgrade strategy. This not only leads to lengthy and diverse upgrade paths but also makes formulating upgrade strategies extremely difficult, hindering unified standardization and making centralized and efficient management of software versions and upgrade tasks impossible.

[0031] It is understandable that Server 200 can be deployed in Over-The-Air (OTA) cloud environments, IoT platforms, file servers, etc.

[0032] To address the problem of centralized and efficient management of software versions and upgrade tasks, this application provides a software upgrade method applied to a software upgrade system. The software upgrade system includes a terminal device (e.g., an in-vehicle device) and a server. The terminal device includes a first upgrade management module and a second upgrade management module, and the server includes a third upgrade management module. The method includes: the third upgrade management module detecting first upgrade data corresponding to the first upgrade management module and sending the first upgrade data to the first upgrade management module based on a first communication protocol, wherein the first upgrade data is in a first format; the first upgrade management module converting the first upgrade data into second upgrade data, wherein the second upgrade data is in a second format; the third upgrade module detecting third upgrade data corresponding to the second upgrade module and sending the third upgrade data to the second upgrade module based on the first communication protocol, wherein the third upgrade data is in the first format; and the second upgrade module converting the third upgrade data into fourth upgrade data, wherein the fourth upgrade data is in a third format.

[0033] In this embodiment, an upgrade management module can be pre-configured in each MPU of the terminal device. When the server's upgrade management module detects upgrade data, it sends the upgrade data to the upgrade management module of the corresponding MPU of the terminal device based on the first communication protocol. The upgrade management module of the corresponding MPU converts the upgrade data into the message format of the MPU corresponding to the upgrade data, so that the software program of the MPU corresponding to the upgrade data can be upgraded based on the converted upgrade data.

[0034] For example, the server's third upgrade management module detects the first upgrade data of the software program of the first MPU of the terminal device, and sends the first upgrade data in a first format to the first upgrade management module based on the first communication protocol; the first upgrade management module converts the first upgrade data into second upgrade data in a second format, wherein the second format is the message format of the first MPU.

[0035] In this way, the server's third upgrade management module can adopt the same upgrade strategy formulation method for each MPU of the terminal device. Furthermore, the server's third upgrade management module can indirectly schedule and manage the software program upgrade process of each MPU of the terminal device in a unified and efficient manner by controlling the upgrade management module of each MPU of the terminal device, thus ensuring the coordination and efficient execution of the upgrade process.

[0036] It is understandable that the traditional MCU upgrade method based on unified diagnostic services (UDS) typically has a transmission speed of 1MB / min, while the MPU upgrade package has a large data volume. The large upgrade package not only reduces the upgrade efficiency, but also seriously affects the stability and success rate of the upgrade process, hinders the effective implementation of efficient production and operation and maintenance strategies, and limits the further optimization of user experience.

[0037] In this embodiment, the server's third upgrade management module can send upgrade data to the upgrade management modules of each MPU in the terminal device via a first communication protocol, namely a high-speed, high-bandwidth transmission protocol. The high-speed, high-bandwidth transmission protocol includes any one of HTTP, HTTPS, FTP, DOIP, WebSocket, etc.

[0038] It is understandable that the transmission speed of the high-speed, high-bandwidth transmission protocol can reach 200MB / min. The transmission speed of the high-speed, high-bandwidth transmission protocol is significantly improved compared to the transmission speed of UDS. It can realize the rapid and accurate issuance of control commands and the high-speed and complete transmission of upgrade data, which significantly improves the efficiency of the upgrade process.

[0039] This application embodiment also provides a software upgrade system, which includes a terminal device and a server. The terminal device can be any of the following: in-vehicle equipment, mobile phone, smart TV, wearable device, tablet computer, desktop computer, laptop computer, virtual reality (VR) device, augmented reality (AR) device, terminal in industrial control, terminal in self-driving, terminal in remote medical surgery, terminal in smart grid, terminal in transportation safety, terminal in smart city, terminal in smart home, etc. The following example uses terminal device 100 and server 200 as a case study. Figure 2 The software upgrade system provided in the embodiments of this application will be described.

[0040] like Figure 2 As shown, the software upgrade system includes a terminal device 100 and a server 200. The terminal device 100 includes a first MPU, a second MPU, a third MPU, and a fourth MPU. The first MPU includes a first upgrade management module, the second MPU includes a second upgrade management module, the third MPU includes a fourth upgrade management module, and the fourth MPU includes a fifth upgrade management module. The server 200 includes a third upgrade management module.

[0041] Understandable. Figure 2 The software system architecture shown is an example. In some embodiments, the terminal device 100 may include more or fewer MPUs, each MPU may have a corresponding upgrade management module, and the server 200 may include more upgrade management modules.

[0042] The third upgrade management module is used to detect the upgrade data of the software program of each MPU in the terminal device 100. When upgrade data is detected, the upgrade data is sent to the upgrade management module of the corresponding MPU node according to the name of the MPU node included in the upgrade data.

[0043] The first upgrade management module, the second upgrade management module, the fourth upgrade management module, and the fifth upgrade management module are used to convert upgrade data into the message format of the corresponding MPU in order to upgrade the software program of the corresponding MPU.

[0044] For example, the third upgrade management module of server 200 detects the first upgrade data of the software program of the first MPU of terminal device 100, and sends the first upgrade data in a first format to the first upgrade management module based on the first communication protocol; the first upgrade management module converts the first upgrade data into second upgrade data in a second format of the first MPU, so that the software program of the first MPU can be upgraded based on the converted upgrade data.

[0045] In this embodiment, the third upgrade management module can send upgrade data to the upgrade management modules of each MPU within the terminal device 100 via any of high-speed, high-bandwidth transmission protocols such as HTTP, HTTPS, FTP, DOIP, and WebSocket. This not only simplifies the upgrade path but also enables parallel upgrades and centralized management of all MPUs, enhancing the controllability and operational efficiency of the software upgrade system. Furthermore, because high-speed, high-bandwidth transmission protocols offer faster transmission speeds, they can increase the transmission speed of upgrade data, significantly improving upgrade efficiency and shortening upgrade time.

[0046] The following example demonstrates how the third upgrade management module of server 200 upgrades the software program of the first MPU of terminal device 100. Figure 3 This application describes a software upgrade method according to embodiments of the present application. It is understood that... Figure 3 The diagram shown can be applied to Figure 2 The software upgrade system shown is described below. For simplicity, further details are provided in the description. Figure 3 The execution entity for each step will not be described again in the schematic diagram shown. For example... Figure 3 As shown, the software upgrade methods include:

[0047] 101: The third upgrade management module detected the first upgrade data corresponding to the first upgrade management module.

[0048] In this embodiment, the third upgrade management module can be an external upgrade management module. The third upgrade management module can detect the upgrade data of each software program in the terminal device 100. In other embodiments, the third upgrade management module can obtain the software version of each software program in the terminal device 100 and determine the upgrade data to be sent to the terminal device 100 based on the software version of each software program. The software program can be an application program, and the software version of the software program includes one or more of the following: software version information, calibration data version information, component identifier (ID), component version number, etc. For example, the program version number of the camera program of the terminal device 100 is "v12.5.8", where "v12.5.8" is the software version of the camera program.

[0049] 102: The third upgrade management module sends the first task establishment request to the first upgrade management module based on the first communication protocol.

[0050] In this embodiment, when the third upgrade management module detects the first upgrade data of the first application of the first MPU in the terminal device 100, it can send a first task establishment request in a first format to the first upgrade management module based on the first communication protocol. The first format is the format of the first communication protocol, the first upgrade data is the upgrade data of the latest version of the first application, and the first task establishment request is used to establish a communication connection between the third upgrade management module and the first upgrade management module to ensure that the third upgrade management module and the first upgrade management module can exchange data.

[0051] In this embodiment, the first upgrade management module can be the first upgrade management module corresponding to the first MPU of the terminal device 100. The first communication protocol can be a high-speed, high-bandwidth transmission protocol, including any one of HTTP, HTTPS, FTP, DOIP, WebSocket, etc.

[0052] It is understandable that the transmission speed of the high-speed, high-bandwidth transmission protocol can reach 200MB / min. The transmission speed of the high-speed, high-bandwidth transmission protocol is significantly improved compared to the transmission speed of UDS, which enables accurate and timely delivery of upgrade packages and high-speed complete transmission of upgrade packages, thus significantly improving the efficiency and reliability of the upgrade process.

[0053] 103: The first upgrade management module sends the first task feedback request to the third upgrade management module based on the first communication protocol.

[0054] In this embodiment, the first upgrade management module obtains a first task creation request in a first format, converts it into a second task creation request in a second format, so that the first MPU corresponding to the first task creation request creates a task based on the second task creation request and generates a second task feedback request in a second format. The first upgrade management module obtains the second task feedback request in the second format, converts it back into a first task feedback request in the first format, and sends the first task feedback request to the third upgrade management module based on a first communication protocol. The first task feedback request includes a task creation result and a first upgrade data installation result; the task creation result includes whether the task creation was successful or failed.

[0055] 104: The third upgrade management module determines that the terminal device has not installed the first upgrade data based on the feedback request of the first task.

[0056] In this embodiment, the third upgrade management module can determine whether the terminal device has installed the first upgrade data based on the first upgrade data installation result in the "first task feedback request". When the first task feedback request indicates that the terminal device 100 has not installed the first upgrade data, proceed to step 105: the third upgrade management module sends the first upgrade data to the first upgrade management module based on the first communication protocol; when the first task feedback request indicates that the terminal device 100 has installed the first upgrade data, the third upgrade management module sends a request to pause the establishment of the upgrade task to the first upgrade management module based on the first communication protocol.

[0057] 105: The third upgrade management module sends the first upgrade data to the first upgrade management module based on the first communication protocol.

[0058] In this embodiment, when the first task feedback request indicates successful task establishment, the third upgrade management module can determine whether to send the first upgrade data to the first upgrade management module based on whether the first upgrade data is installed. For example, if the first task feedback request indicates that the terminal device 100 has not installed the first upgrade data, the third upgrade management module sends the first upgrade data to the first upgrade management module based on the first communication protocol. If the first task feedback request indicates that the terminal device 100 has installed the first upgrade data, the third upgrade management module sends a request to suspend task establishment to the first upgrade management module based on the first communication protocol. When the first task feedback request indicates that task establishment has failed, the third upgrade management module can send the first task establishment request to the first upgrade management module again based on the first communication protocol. If the first task feedback request still indicates that task establishment has failed, the third upgrade management module stops sending the first task establishment request to the first upgrade management module.

[0059] In some embodiments, during the process of transmitting first upgrade data to the first upgrade management module, the third upgrade management module may send a transmission progress acquisition request to the first upgrade management module at any time or periodically based on the first communication protocol. Upon receiving the transmission progress acquisition request, the first upgrade management module sends the upgrade data transmission progress to the third upgrade management module based on the first communication protocol. In other embodiments, during the process of the first upgrade management module acquiring the first upgrade data, the first upgrade management module may send the upgrade data transmission progress to the third upgrade management module at any time or periodically based on the first communication protocol.

[0060] The upgrade data transmission progress can be any real number between 0 and 1. When the upgrade data transmission progress is 1, the first upgrade data transmission is determined to be completed. When the upgrade data transmission progress is less than 1 and the transmission progress is paused, the first upgrade data transmission is determined to be paused.

[0061] In this embodiment, corresponding to the upgrade data transmission progress indicating that the first upgrade data transmission is paused, the third upgrade management module stops sending the first upgrade data to the first upgrade management module to stop the upgrade process; corresponding to the upgrade data transmission progress indicating that the first upgrade data transmission is completed, the third upgrade management module can send a first installation request to the first upgrade management module based on the first communication protocol.

[0062] 106: The first upgrade management module converts the first upgrade data into second upgrade data in a second format, and upgrades the software program corresponding to the second upgrade data based on the second upgrade data.

[0063] In this embodiment of the application, the second format is the communication protocol format of the first MPU corresponding to the first upgrade data.

[0064] It is understood that the first upgrade management module can also install the first upgrade data upon receiving a first installation request from the third upgrade management module based on the first communication protocol, and can activate the software program corresponding to the first upgrade data upon receiving a first activation request from the third upgrade management module based on the first communication protocol. The method for installing the first upgrade data is as follows: Figure 6 The method for activating the software program corresponding to the first upgrade data is described in the illustrated embodiment. Figure 7 The embodiments shown will be described in detail here, and will not be repeated.

[0065] It is understandable that the third upgrade management module of server 200 can refer to the same method for upgrading the software programs of other MPUs on terminal device 100. Figure 3 The method is illustrated below. For example, the method by which the third upgrade management module detects the third upgrade data corresponding to the second upgrade management module and sends the third upgrade packet to the second upgrade management module based on the first communication protocol is the same as the method by which the third upgrade management module detects the first upgrade data corresponding to the first upgrade module and sends the first upgrade data to the first upgrade management module based on the first communication protocol, and will not be described again here.

[0066] Based on the above scheme, the third upgrade management module of server 200 can adopt the same upgrade strategy formulation method for each MPU of terminal device 100. Furthermore, the third upgrade management module of the server can indirectly schedule and manage the software program upgrade process of each MPU of terminal device in a unified manner by controlling the upgrade management module of each MPU of terminal device, thus ensuring the coordination and efficient execution of the upgrade process.

[0067] In this embodiment, the third upgrade management module can send upgrade data to the upgrade management modules of each MPU within the terminal device 100 via any of high-speed, high-bandwidth transmission protocols such as HTTP, HTTPS, FTP, DOIP, and WebSocket. This not only simplifies the upgrade path but also enables parallel upgrades and centralized management of all MPUs, enhancing the controllability and operational efficiency of the software upgrade system. Furthermore, because high-speed, high-bandwidth transmission protocols offer faster transmission speeds, they can increase the transmission speed of upgrade data, significantly improving upgrade efficiency and shortening upgrade time.

[0068] It is understandable that there may be strong dependencies between the software versions of MPUs in different functional domains. For example, if the upgrade of any MPU node on the same chain fails, it may trigger a chain reaction. For instance, if the software version of an MPU node that fails to upgrade is incompatible with the software versions of other MPU nodes, it may cause some functions of other MPU nodes to fail, which may pose a serious threat to user experience and even vehicle safety, with far-reaching consequences.

[0069] To prevent the failure of a software version upgrade on one MPU node from causing partial functional failures on other MPU nodes, in this embodiment, if the software program corresponding to the first upgrade data fails to upgrade, the software program corresponding to the third upgrade data succeeds to upgrade, and the correlation between the first MPU corresponding to the first upgrade management module and the second MPU corresponding to the second upgrade management module is greater than a correlation threshold, the third upgrade management module sends a rollback request to the second upgrade management module. The failure of the software program upgrade corresponding to the first upgrade data includes any one of the following: a first task feedback request indicating task creation failure, an upgrade data transmission progress indicating paused first upgrade data transmission, a first installation progress indicating paused first upgrade data installation progress, or a first activation progress indicating paused activation progress of the software program corresponding to the first upgrade data.

[0070] Correlation refers to the interrelationships or dependencies among MPUs in terms of task execution, resource sharing, and data communication. In some embodiments, correlation can be determined based on task dependencies. In other embodiments, correlation can be determined based on thread synchronization. Correlation thresholds can be determined based on empirical values.

[0071] For example, if the installation of the first upgrade data fails but the software program corresponding to the third upgrade data is successfully activated, the third upgrade management module can determine the correlation between the first MPU corresponding to the first upgrade data and the second MPU corresponding to the third upgrade data. If the third upgrade management module determines that the correlation between the first MPU and the second MPU corresponding to the first upgrade data is greater than the correlation threshold, the third upgrade management module sends a pause installation request to the first upgrade management module and a rollback request to the second upgrade management module to suspend the installation of the first upgrade data and change the software program corresponding to the third upgrade data from the version corresponding to the third upgrade data to the version before the upgrade. If the third upgrade management module determines that the correlation between the first MPU and the second MPU corresponding to the first upgrade data is less than or equal to the correlation threshold, the third upgrade management module sends a pause installation request to the first upgrade management module to suspend the installation of the first upgrade data.

[0072] In this embodiment, during the software activation phase, if the software corresponding to the first upgrade data fails to activate and the software corresponding to the third upgrade data activates successfully, the third upgrade management module can determine the correlation between the first MPU and the second MPU corresponding to the first upgrade data. If the third upgrade management module determines that the correlation between the first MPU and the second MPU is greater than a correlation threshold, the third upgrade management module sends a rollback request to both the first and second upgrade management modules to change the software program corresponding to the first upgrade data from the version corresponding to the first upgrade data to the version before the upgrade, and the software program corresponding to the third upgrade data from the version corresponding to the third upgrade data to the version before the upgrade. If the third upgrade management module determines that the correlation between the first MPU and the second MPU corresponding to the first upgrade data is less than or equal to a correlation threshold, the third upgrade management module sends a rollback request to the first upgrade module to change the software program corresponding to the first upgrade data from the version corresponding to the first upgrade data to the version before the upgrade.

[0073] It is understandable that if the correlation between the first MPU corresponding to the first upgrade data and the second MPU corresponding to the third upgrade data is greater than the correlation threshold, then the first MPU corresponding to the first upgrade data may depend on the second MPU corresponding to the third upgrade data, or the second MPU corresponding to the third upgrade data may depend on the first MPU corresponding to the first upgrade data. If the software program corresponding to the first upgrade data and the software program corresponding to the third upgrade data are different versions, it may cause the software program corresponding to the first upgrade data or the software program corresponding to the third upgrade data to fail to run, which may lead to security risks in the system of terminal device 100.

[0074] In this embodiment of the application, if a software version incompatibility problem is encountered during the software program upgrade process, the original version of each MPU node can be quickly restored as needed. For example, if it is determined that the software program corresponding to the first upgrade data fails to upgrade and the software program corresponding to the third upgrade data succeeds to upgrade, it can be determined whether to suspend the establishment of the upgrade task, or suspend the transmission of upgrade data, or suspend the installation of upgrade data, or suspend the activation of the software program corresponding to the upgrade data based on the correlation between the first MPU corresponding to the first upgrade data and the second MPU corresponding to the third upgrade data. This ensures the consistency and compatibility of the vehicle system version during the upgrade process of the terminal device 100, providing users with a more secure, convenient, and reliable upgrade experience.

[0075] In this embodiment, an in-vehicle upgrade management module is embedded in each MPU of the terminal device 100. The third upgrade management module can use a high-speed, high-bandwidth transmission protocol to interact with the in-vehicle upgrade management module, simplifying the cumbersome process of upgrading all MPUs in the vehicle. Furthermore, by optimizing the upgrade link, direct and efficient control of the in-vehicle upgrade management module of each MPU in the vehicle is achieved, ensuring the rapid and accurate transmission of the upgrade package. This allows the upgrade command to accurately trigger the state transition of the in-vehicle upgrade management module, thereby efficiently coordinating the entire upgrade process. From the initialization task setting to the instant transmission and seamless installation of the upgrade package, and then to successful activation and software rollback in abnormal situations, the controllability and stability of the upgrade process are guaranteed throughout.

[0076] It is understandable that the software upgrade method includes creating an upgrade task, transmitting the upgrade package (transmitting upgrade data), installing the upgrade package (installing upgrade data), activating the software, and rolling back the software. The following example uses the third upgrade management module as the external upgrade management module, the first upgrade management module as the in-vehicle upgrade management module, the first upgrade data as the software package, and the first communication protocol as the HTTP protocol. Figures 4 to 8 The software upgrade method is introduced; it can be understood that the in-vehicle upgrade management module can also be any one of the second, fourth, or fifth upgrade management modules within the terminal device 100.

[0077] Figure 4 This diagram illustrates the interaction between the external upgrade management module and the internal upgrade management module in establishing an upgrade task. Figure 4 As shown, it includes:

[0078] 201: The external upgrade management module sends a request to the internal upgrade management module to establish an upgrade task.

[0079] In this embodiment, the external upgrade management module detects the upgrade package of the MPU software program in the terminal device 100 and can send a "request to establish an upgrade task" Hypertext Transfer Protocol (HTTP) message to the in-vehicle upgrade management module of the target MPU node corresponding to the upgrade package in the terminal device 100 based on the HTTP protocol. In other embodiments, the external upgrade management module can send an "request to establish an upgrade task" HTTPS message to the in-vehicle upgrade management module of the target MPU node corresponding to the upgrade package in the terminal device 100 based on the HTTPS protocol.

[0080] The "Request to Establish Upgrade Task" message includes the target message type, the name of the MPU node, the identifier (ID) of this upgrade task, the total number of software packages, the total size of the software packages, the source media access control (MAC) address, the source internet protocol (IP) address, the HTTP port number, the log level, and extended parameters. The target message type refers to the message type of the target MPU node corresponding to the upgrade task. The in-vehicle upgrade management module can convert the format of the acquired message to the target message type based on this information.

[0081] For example, if the external upgrade management module detects an upgrade package for the software program of the MPU in the terminal device 100, it can send an HTTP message "Request to establish upgrade task" to the in-vehicle upgrade management module of the MPU node corresponding to the upgrade package.

[0082] As can be understood, an MPU node refers to a memory region or partition within an MPU, used to implement memory isolation and protection for the operating system. Each MPU node can be configured with different access permissions to protect memory from unauthorized access.

[0083] 202: The in-vehicle upgrade management module responds to the external upgrade management module with the result of the task creation.

[0084] In this embodiment, after the in-vehicle upgrade management module of the target MPU node corresponding to the upgrade package successfully receives, parses, and executes the "Establish Upgrade Task", it can send an HTTP-formatted "Task Establishment Result" message to the external upgrade management module based on the HTTP protocol. In other embodiments, after the in-vehicle upgrade management module successfully receives, parses, and executes the "Establish Upgrade Task", it can send an HTTPS-formatted "Task Establishment Result" message to the external upgrade management module based on the HTTPS protocol. The "Task Establishment Result" message includes the message type, the name of the MPU node, the ID of this upgrade task, the task establishment result, and whether the upgrade package is installed. The task establishment result includes whether the task establishment was successful or failed.

[0085] It is understandable that the "Task Creation Result" message indicates that the task was successfully created, and the external upgrade management module can transmit the upgrade package to the internal upgrade management module; the "Task Creation Result" message indicates that the task creation failed, and the process ends.

[0086] Figure 5 This diagram illustrates the interaction between the external upgrade management module and the internal upgrade management module when transmitting upgrade packages. Figure 5 As shown, it includes:

[0087] 301: The in-vehicle upgrade management module sends the URL address of the upgrade package request to the external upgrade management module.

[0088] In this embodiment, the "task establishment result" message indicates that the task has been successfully established. The in-vehicle upgrade management module of the target MPU node can send a "request for upgrade package URL address" message to the external upgrade management module based on the HTTP protocol. In other embodiments, the "task establishment result" message indicates that the task has been successfully established. The in-vehicle upgrade management module can send an HTTPS message "request for upgrade package URL address" to the external upgrade management module based on the HTTPS protocol.

[0089] The "Request Upgrade Package URL Address" message includes the message type, the name of the target MPU node, the ID of this upgrade task, the total number of upgrade packages, and the size of the upgrade package. The URL is used to identify and locate the resource.

[0090] It is understandable that the same software program corresponds to different URLs in different application scenarios. By obtaining the URL address of the upgrade package, the upgrade package required to upgrade the software program can be accurately found and accessed.

[0091] 302: The external upgrade management module responds to the internal upgrade management module with the URL address of the upgrade package.

[0092] In this embodiment, after the external upgrade management module successfully receives and parses the HTTP message "request for upgrade package URL address" sent by the in-vehicle upgrade management module of the target MPU node, it can send an HTTP format "upgrade package URL address" message to the in-vehicle upgrade management module of the target MPU node based on the HTTP protocol. In other embodiments, after the external upgrade management module successfully receives and parses the HTTPS message "request for upgrade package URL address" sent by the in-vehicle upgrade management module, it can send an HTTPS message "upgrade package URL address" to the in-vehicle upgrade management module of the target MPU node based on the HTTPS protocol.

[0093] The "URL address of the upgrade package" message includes the message type, the name of the MPU node, the ID of this upgrade task, and the URL address where the upgrade package for this task is stored.

[0094] 303: The size of the upgrade package requested by the in-vehicle upgrade management module to the external upgrade management module.

[0095] In this embodiment, if the in-vehicle upgrade management module of the target MPU node determines that the total number of upgrade packages is one based on the URL address of the upgrade package, then the in-vehicle upgrade management module of the target MPU node can send an HTTP message "request upgrade package" to the external upgrade management module based on the HTTP protocol (i.e., execute step 305). If the in-vehicle upgrade management module of the target MPU node determines that the total number of upgrade packages is greater than or equal to two based on the URL address of the upgrade package, then the in-vehicle upgrade management module of the target MPU node can send an HTTP message "request upgrade package size" to the external upgrade management module based on the HTTP protocol. In other embodiments, if the in-vehicle upgrade management module of the target MPU node determines that the total number of upgrade packages is one based on the URL address of the upgrade package, then the in-vehicle upgrade management module of the target MPU node can send an HTTPS message "request upgrade package" to the external upgrade management module based on the HTTPS protocol (i.e., execute step 305). If the in-vehicle upgrade management module of the target MPU node determines that the total number of upgrade packages is greater than or equal to two based on the URL address of the upgrade package, the in-vehicle upgrade management module of the target MPU node can send an HTTPS message "requesting the size of the upgrade package" to the external upgrade management module based on the HTTPS protocol.

[0096] The "Request Upgrade Package Size" message includes the message type, the name of the target MPU node, the ID of this upgrade task, the total number of packages, and the total size of the packages.

[0097] In this embodiment, when the total number of upgrade packages is greater than or equal to 2, the in-vehicle upgrade management module of the target MPU node can convert the upgrade package into a message format corresponding to the target MPU node based on the size of the upgrade package after obtaining it. In other embodiments, when the total number of upgrade packages is greater than or equal to 2, the in-vehicle upgrade management module of the target MPU node can convert the upgrade package into a message format corresponding to the target MPU node based on at least one of the following: patch level, compatibility, user rating, number of downloads, and installation success rate.

[0098] 304: The external upgrade management module responds to the internal upgrade management module with the size of the upgrade package.

[0099] In this embodiment, after the external upgrade management module successfully receives and parses the "request for upgrade package size" HTTP message sent by the in-vehicle upgrade management module of the target MPU node, it can send an HTTP message of "upgrade package size" based on the HTTP protocol. In other embodiments, after the external upgrade management module successfully receives and parses the "request for upgrade package size" HTTPS message sent by the in-vehicle upgrade management module, it can send an HTTPS message of "upgrade package size".

[0100] The "Upgrade Package Size" message includes the message type, the name of the MPU node, the ID of this upgrade task, the total number of packages, the total size of the packages, the name of each module, and the size of each package.

[0101] As you can understand, the upgrade packages are all compressed in zip format, with the suffix indicating the corresponding module. The module name indicates the installation order of the upgrade packages. For example, the first package is module 10, the second package is module 11, and so on.

[0102] 305: The in-vehicle upgrade management module sends an upgrade request package to the external upgrade management module.

[0103] In this embodiment, when the total number of upgrade packages is equal to 1, the in-vehicle upgrade management module of the target MPU node can send an HTTP message "request upgrade package" to the external upgrade management module; when the total number of upgrade packages is greater than or equal to 2, the in-vehicle upgrade management module of the target MPU node can sort each upgrade package into modules according to the module name in the HTTP message "upgrade package size", and then send HTTP messages "request upgrade package" to the external upgrade management module in sequence based on the module order to request the upgrade package of each module in sequence.

[0104] In other embodiments, when the total number of upgrade packages is equal to 1, the in-vehicle upgrade management module of the target MPU node can send an HTTPS message requesting an upgrade package to the external upgrade management module; when the total number of upgrade packages is greater than or equal to 2, the in-vehicle upgrade management module of the target MPU node can sort the upgrade packages into modules according to the module name in the HTTPS message of "upgrade package size", and then send HTTPS messages requesting upgrade packages to the external upgrade management module in sequence based on the module order to request the upgrade packages of each module in sequence.

[0105] The "Request Upgrade Packet" message includes the message type, the name of the target MPU node, the ID of this upgrade task, the name of the requested module, and the size of the requested module package.

[0106] 306: The external upgrade management module responds to the internal upgrade management module with an upgrade package.

[0107] In this embodiment, after the external upgrade management module successfully receives and parses the HTTP message of the "request upgrade packet" sent by the in-vehicle upgrade management module of the target MPU node, it can use the HTTP message to send an "upgrade packet" to the in-vehicle upgrade management module of the target MPU node.

[0108] In other embodiments, after the external upgrade management module successfully receives and parses the HTTPS message of the "request upgrade packet" sent by the in-vehicle upgrade management module of the target MPU node, it can use the HTTPS message to send an "upgrade packet" to the in-vehicle upgrade management module of the target MPU node.

[0109] 307: The external upgrade management module sends a request to the internal upgrade management module to transmit the status and progress of the upgrade package.

[0110] In this embodiment, during the process of the external upgrade management module transmitting the upgrade package to the in-vehicle upgrade management module of the target MPU node, corresponding to the external upgrade management module sending the "upgrade package" to the in-vehicle upgrade management module of the target MPU node based on the HTTP protocol, the external upgrade management module can send a "request for upgrade package transmission status and progress" message to the in-vehicle upgrade management module based on the HTTP protocol at any time or periodically; corresponding to the external upgrade management module sending the "upgrade package" to the in-vehicle upgrade management module of the target MPU node based on the HTTPS message, the external upgrade management module can send a "request for upgrade package transmission status and progress" message to the in-vehicle upgrade management module of the target MPU node based on the HTTPS message at any time or periodically; wherein the "request for upgrade package transmission status and progress" message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0111] 308: The in-vehicle upgrade management module responds to the external upgrade management module by transmitting the status and progress of the upgrade package.

[0112] In this embodiment, after the in-vehicle upgrade management module corresponding to the target MPU node successfully receives and parses the HTTP message "Request Upgrade Package Transmission Status and Progress" from the external upgrade management module, it can convert the HTTP message into the target message type corresponding to "Request Upgrade Package Transmission Status and Progress". The target message type refers to the message format of the target MPU node in the "Request Upgrade Package Transmission Status and Progress" message, and the target MPU refers to the MPU corresponding to the "Request Upgrade Package Transmission Status and Progress". The target MPU in the "Request Upgrade Package Transmission Status and Progress" message can generate a "Transmission Upgrade Package Status and Progress" message of the target message type based on the obtained upgrade package. The in-vehicle upgrade management module can obtain the "Transmission Upgrade Package Status and Progress" message of the target message type, convert it into an HTTP format "Transmission Upgrade Package Status and Progress" message, and send it to the external upgrade management module.

[0113] The "Transmission Upgrade Package Status and Progress" message includes the message type, MPU node name, ID of this upgrade task, transmission module name, transmission status, and transmission progress. The transmission status includes "Transmission in progress," "Transmission completed," and "Transmission failed," while the transmission progress can be any real number between 0 and 1.

[0114] In this embodiment, the target MPU can also determine whether the upgrade package is complete. If it is determined that the upgrade package is incomplete, a first acquisition request of the target message type can be generated. The in-vehicle upgrade management module acquires the first acquisition request of the target message type, converts the first acquisition request of the target message type into a second acquisition request in HTTP format, and sends the second acquisition request to the external upgrade management module to download the upgrade package again.

[0115] It is understandable that the transmission progress can be any real number between 0 and 1. A message corresponding to "Transmission status and progress of upgrade package" indicates that the transmission progress is 1, confirming that the upgrade package transmission is complete; a message corresponding to "Transmission status and progress of upgrade package" indicates that the transmission progress is less than 1, the transmission progress is paused, and a "Pause transmission of upgrade package" message is received, confirming that the upgrade package transmission is paused; a message corresponding to "Transmission status and progress of upgrade package" indicates that the transmission progress is less than 1, the transmission progress is paused, and a "Pause transmission of upgrade package" message is not received, confirming that the upgrade package transmission has failed.

[0116] In some embodiments, during the process of the target MPU node's in-vehicle upgrade management module acquiring the "upgrade package," it can send "upgrade package transmission status and progress" HTTP messages to the external upgrade management module at any time or periodically. In other embodiments, during the process of the target MPU node's in-vehicle upgrade management module acquiring the "upgrade package," it can send "upgrade package transmission status and progress" HTTPS messages to the external upgrade management module at any time or periodically.

[0117] 309: The external upgrade management module sends a pause upgrade transmission package to the internal upgrade management module.

[0118] In this embodiment of the application, during the transmission of the upgrade package, the external upgrade management module can send an HTTP or HTTPS message to the in-vehicle upgrade management module of the target MPU node at any time to "pause transmission of upgrade package". The message to "pause transmission of upgrade package" includes message type, name of MPU node, ID of this upgrade task, and pause type (pause, stop, continue).

[0119] For example, if the external upgrade management module determines that the upgrade package transmission has failed based on the transmission status, it can send a pause upgrade package transmission message to the in-vehicle upgrade management module of the target MPU node, which includes stopping the transmission of the upgrade package.

[0120] 310: The in-vehicle upgrade management module responds to the external upgrade management module to suspend the transmission of upgrade packages.

[0121] In this embodiment, after successfully receiving, parsing, and executing the HTTP message "Pause Upgrade Package Transmission" sent by the external upgrade management module, the in-vehicle upgrade management module of the target MPU node can send an HTTP-formatted "Pause Upgrade Package Transmission Result" message to the external upgrade management module. In other embodiments, after successfully receiving, parsing, and executing the HTTPS message "Pause Upgrade Package Transmission" sent by the external upgrade management module, the in-vehicle upgrade management module of the target MPU node can use an HTTPS message to send a "Pause Upgrade Package Transmission Result" message to the external upgrade management module.

[0122] The "Pause Transmission of Upgrade Package Result" message includes message type, MPU node name, ID of this upgrade task, transmission progress, pause type, and pause result.

[0123] Figure 6 The diagram illustrates the interaction between the external upgrade management module and the internal upgrade management module during the installation of the upgrade package. Figure 6 As shown, it includes:

[0124] 401: The external upgrade management module sends a request to the internal upgrade management module to install the upgrade package.

[0125] In this embodiment, after the upgrade packages of all modules of the target MPU node are successfully transmitted, the external upgrade management module can send an HTTP message "request to install upgrade package" to the in-vehicle upgrade management module of the target MPU node. In other embodiments, after the upgrade packages of all modules of the target MPU node are successfully transmitted, the external upgrade management module can send an HTTPS message "request to install upgrade package" to the in-vehicle upgrade management module.

[0126] The "Request to install upgrade package" message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0127] 402: The in-vehicle upgrade management module responds to the external upgrade management module with the status of the upgrade package installation.

[0128] In this embodiment, after successfully receiving, parsing, and executing the HTTP message "Request to Install Upgrade Package" sent by the external upgrade management module, the in-vehicle upgrade management module of the target MPU node can convert the HTTP message into a target message type corresponding to the "Request to Install Upgrade Package". Here, the target message type refers to the message format of the target MPU node in the "Request to Install Upgrade Package" message, and the target MPU refers to the MPU corresponding to the "Request to Install Upgrade Package". The target MPU of the "Request to Install Upgrade Package" message can install the obtained upgrade package based on the "Request to Install Upgrade Package" message, generating a "Upgrade Package Installation Execution Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Upgrade Package Installation Execution Status" message of the target message type, convert it into an HTTP-formatted "Upgrade Package Installation Execution Status" message, and send the HTTP-formatted "Upgrade Package Installation Execution Status" message to the external upgrade management module.

[0129] In other embodiments, the in-vehicle upgrade management module corresponding to the target MPU node successfully receives, parses, and executes the HTTPS message "Request to Install Upgrade Package" sent from the external upgrade management module. It can convert the HTTPS message into the target message type corresponding to the "Request to Install Upgrade Package," where the target message type refers to the message format of the target MPU node, and the target MPU refers to the MPU corresponding to the "Request to Install Upgrade Package." The target MPU of the "Request to Install Upgrade Package" message can install the obtained upgrade package based on the message, generating a "Upgrade Package Installation Execution Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Upgrade Package Installation Execution Status" message of the target message type, convert it into an HTTPS format "Upgrade Package Installation Execution Status" message, and send the HTTPS format "Upgrade Package Installation Execution Status" message to the external upgrade management module.

[0130] The "Installation Upgrade Package Execution Status" message includes message type, MPU node name, ID of this upgrade task, and installation upgrade package execution status; the installation upgrade package execution status includes successful installation, installation in progress, installation paused, and installation failed.

[0131] 403: The external upgrade management module sends a request to the internal upgrade management module for installation status and progress.

[0132] In this embodiment of the application, during the installation of the upgrade package, the external upgrade management module can send a "request for upgrade package installation status and progress" message to the in-vehicle upgrade management module at any time or periodically via HTTP message. The "request for upgrade package installation status and progress" message includes message type, MPU node name, and ID of this upgrade task.

[0133] In some implementations, during the installation of the upgrade package, the external upgrade management module can send a "request for upgrade package installation status and progress" message to the in-vehicle upgrade management module via HTTPS messages at any time or periodically.

[0134] In some embodiments, during the process of the in-vehicle upgrade management module of the target MPU obtaining the "request to install upgrade package" message, the in-vehicle upgrade management module can send the "upgrade package installation status and progress" message to the external upgrade management module at any time or periodically.

[0135] 404: The in-vehicle upgrade management module responds to the external upgrade management module with the upgrade package installation status and progress.

[0136] In this embodiment, after successfully receiving and parsing the HTTP message "Request for Upgrade Package Installation Status and Progress" from the external upgrade management module, the in-vehicle upgrade management module can convert the HTTP message into a target message type corresponding to the "Request for Upgrade Package Installation Status and Progress". The target message type refers to the message format of the target MPU node in the "Request for Upgrade Package Installation Status and Progress", and the target MPU refers to the MPU corresponding to the "Request for Upgrade Package Installation Status and Progress". The target MPU can generate an "Upgrade Package Installation Status and Progress" message of the target message type based on the obtained upgrade package. The in-vehicle upgrade management module can obtain the "Upgrade Package Installation Status and Progress" message of the target message type, convert it into an HTTP format "Upgrade Package Installation Status and Progress" message, and send the HTTP format "Upgrade Package Installation Status and Progress" message to the external upgrade management module.

[0137] In other embodiments, after successfully receiving and parsing the HTTPS message "Request for Upgrade Package Installation Status and Progress" from the external upgrade management module, the in-vehicle upgrade management module can convert the HTTPS message into a target message type corresponding to the "Request for Upgrade Package Installation Status and Progress". The target message type refers to the message format of the target MPU node in the "Request for Upgrade Package Installation Status and Progress", and the target MPU refers to the MPU corresponding to the "Request for Upgrade Package Installation Status and Progress". The target MPU can generate an "Upgrade Package Installation Status and Progress" message of the target message type based on the obtained upgrade package. The in-vehicle upgrade management module can obtain the "Upgrade Package Installation Status and Progress" message of the target message type, convert it into an HTTPS format "Upgrade Package Installation Status and Progress" message, and send the HTTPS format "Upgrade Package Installation Status and Progress" message to the external upgrade management module.

[0138] The "Upgrade Package Installation Status and Progress" message includes the message type, MPU node name, ID of this upgrade task, upgrade package installation execution status, and installation progress. The upgrade package installation execution status includes successful installation, in progress, paused installation, and failed installation. The installation progress can be any real number between 0 and 1. If the installation progress is less than 1 and continues to increase, the upgrade package is considered to be installing. If the installation progress is 1, the upgrade package is considered to be installed. If the installation progress is less than 1, the installation is paused, and a "Pause Upgrade Package Installation" message is received, the upgrade package installation is considered paused. If the installation progress is less than 1, the installation is paused, and no "Pause Upgrade Package Installation" message is received, the upgrade package installation is considered to have failed.

[0139] It is understandable that if the "upgrade package installation status and progress" indicates that the installation has failed, the external upgrade management module will send a "pause installation of upgrade package" message to the internal upgrade management module to stop the installation process.

[0140] 405: The external upgrade management module sends a message to the internal upgrade management module to suspend the installation of the upgrade package.

[0141] In the embodiments of this application, during the installation of the upgrade package, the external upgrade management module can send an HTTP message of "pause installation of upgrade package" to the in-vehicle upgrade management module of the target MPU at any time; in other embodiments, during the installation of the upgrade package, the external upgrade management module can send an HTTPS message of "pause installation of upgrade package" to the in-vehicle upgrade management module of the target MPU at any time.

[0142] The "Pause Installation of Upgrade Package" message includes the message type, the name of the MPU node, the ID of this upgrade task, and the pause type (which can be paused, stopped, or continued).

[0143] For example, if the external upgrade management module determines that the upgrade package installation has failed based on the "upgrade package installation status and progress", it can send a "pause upgrade package installation" message to the in-vehicle upgrade management module of the target MPU, which includes stopping the installation of the upgrade package.

[0144] 406: The in-vehicle upgrade management module responds to the external upgrade management module with the result of pausing the installation of the upgrade package.

[0145] In this embodiment of the application, after successfully receiving, parsing, and executing the HTTP message "Pause Installation of Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module of the target MPU should send the "Pause Installation of Upgrade Package Result" to the external upgrade management module using the HTTP message; after successfully receiving, parsing, and executing the HTTPS message "Pause Installation of Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module of the target MPU should send the "Pause Installation of Upgrade Package Result" to the external upgrade management module using the HTTPS message.

[0146] The "Pause Installation of Upgrade Package Result" message includes message type, MPU node name, ID of this upgrade task, installation progress, pause type, and pause result; the pause type includes active pause and passive pause, and the pause result includes pause success and pause failure.

[0147] Figure 7 The diagram illustrates the interaction between the external upgrade management module and the internal upgrade management module during the activation of the software corresponding to the upgrade package. Figure 7 As shown, it includes:

[0148] 501: The external upgrade management module sends a request to the internal upgrade management module to activate the software.

[0149] In this embodiment, after the upgrade packages for all modules of the target MPU node are successfully installed, the external upgrade management module can send an HTTP message requesting software activation to the in-vehicle upgrade management module based on the HTTP protocol. In other embodiments, after the upgrade packages for all modules of the target MPU node are successfully installed, the external upgrade management module can send an HTTPS message requesting software activation to the in-vehicle upgrade management module.

[0150] The "Request to Activate Software" message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0151] 502: The in-vehicle upgrade management module responds to the external upgrade management module to activate the software execution status.

[0152] In this embodiment, after successfully receiving, parsing, and executing the "Request to Activate Software" HTTP message from the external upgrade management module, the in-vehicle upgrade management module can convert the "Request to Activate Software" HTTP message into a target message type corresponding to the "Request to Activate Software". The target message type refers to the message format of the target MPU node of the "Request to Activate Software", and the target MPU refers to the MPU corresponding to the "Request to Activate Software". The target MPU of the "Request to Activate Software" message can activate the software corresponding to the obtained upgrade package based on the "Request to Activate Software" message and generate an "Activated Software Execution Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Activated Software Execution Status" message of the target message type, convert it into an HTTP-formatted "Activated Software Execution Status" message, and send the HTTP-formatted "Activated Software Execution Status" message to the external upgrade management module.

[0153] In other embodiments, the in-vehicle upgrade management module corresponding to the target MPU node successfully receives, parses, and executes the HTTPS message "Request to Activate Software" sent from the external upgrade management module. It can convert the HTTPS message into a target message type corresponding to the "Request to Activate Software" message. Here, the target message type refers to the message format of the target MPU node of the "Request to Activate Software" message, and the target MPU refers to the MPU corresponding to the "Request to Activate Software". The target MPU of the "Request to Activate Software" message can activate the software program corresponding to the obtained upgrade package based on the "Request to Activate Software" message, generating a "Software Activation Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Software Activation Status" message of the target message type, convert it into an HTTPS format "Software Activation Status" message, and send the HTTPS format "Software Activation Status" message to the external upgrade management module.

[0154] The "Activate Software Execution Status" message includes message type, MPU node name, ID of this upgrade task, and activation software execution status; activation software execution status includes activation successful, activation in progress, activation paused, and activation failed.

[0155] 503: The external upgrade management module sends a request to the internal upgrade management module for software activation status and progress.

[0156] In the embodiments of this application, during the activation of the upgrade package, the external upgrade management module can send an HTTP-formatted "request for software activation status and progress" message to the in-vehicle upgrade management module of the target MPU at any time or periodically via the HTTP protocol; in other embodiments, during the activation of the upgrade package, the external upgrade management module can send an HTTPS-formatted "request for software activation status and progress" message to the in-vehicle upgrade management module of the target MPU at any time or periodically via the HTTPS protocol.

[0157] The "Request Software Activation Status and Progress" message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0158] In some embodiments, during the process of the in-vehicle upgrade management module of the target MPU obtaining the "request to activate software" message, the in-vehicle upgrade management module of the target MPU can send the "software activation status and progress" message to the external upgrade management module at any time or periodically.

[0159] 504: The in-vehicle upgrade management module is responding to the external upgrade management module with the software activation status and progress.

[0160] In this embodiment, after successfully receiving and parsing the "Request for Software Activation Status and Progress" HTTP message from the external upgrade management module, the in-vehicle upgrade management module of the target MPU can convert the "Request for Software Activation Status and Progress" HTTP message into the target message type corresponding to the "Request for Software Activation Status and Progress". Here, the target message type refers to the message format of the target MPU node in the "Request for Software Activation Status and Progress", and the target MPU refers to the MPU corresponding to the "Request for Software Activation Status and Progress". The target MPU in the "Request for Software Activation Status and Progress" can generate a "Software Activation Status and Progress" message of the target message type based on the obtained upgrade package. The in-vehicle upgrade management module can obtain the "Software Activation Status and Progress" message of the target message type, convert it into an HTTP format "Software Activation Status and Progress" message, and send the HTTP format "Software Activation Status and Progress" message to the external upgrade management module.

[0161] In other embodiments, after successfully receiving and parsing the HTTPS message "Request Software Activation Status and Progress" from the external upgrade management module, the in-vehicle upgrade management module can convert the HTTPS message into a target message type corresponding to the "Request Software Activation Status and Progress". The target message type refers to the message format of the target MPU node in the "Request Software Activation Status and Progress", and the target MPU refers to the MPU corresponding to the "Request Software Activation Status and Progress". The target MPU in the "Request Software Activation Status and Progress" can generate a "Software Activation Status and Progress" message of the target message type based on the obtained upgrade package. The in-vehicle upgrade management module can obtain the "Software Activation Status and Progress" message of the target message type, convert it into an HTTPS format "Software Activation Status and Progress" message, and send the HTTPS format "Software Activation Status and Progress" message to the external upgrade management module.

[0162] The "Software Activation Status and Progress" message includes the message type, MPU node name, ID of this upgrade task, activation software execution status, and activation progress. The activation software execution status includes activating, activation paused, activation completed, and activation failed. The activation progress can be any real number between 0 and 1. If the activation progress is less than 1 and continuously increasing, the software program corresponding to the upgrade package is considered to be activating. If the activation progress is 1, the software program corresponding to the upgrade package is considered to be activated. If the activation progress is less than 1, the activation is paused, and a "Pause Activation Software" message is received, the software program corresponding to the upgrade package is considered to be activating. If the activation progress is less than 1, the activation is paused, and a "Pause Activation Software" message is not received, the software program corresponding to the upgrade package is considered to have failed to activate.

[0163] It is understandable that if the "upgrade package activation status and progress" indicates that the software program corresponding to the upgrade package has failed to activate, the external upgrade management module will send "pause activation software" to the in-vehicle upgrade management module of the target MPU to stop activating the software program corresponding to the upgrade package.

[0164] 505: The external upgrade management module sends a message to the internal upgrade management module to suspend the activation software.

[0165] In the embodiments of this application, during the activation of the upgrade package, the external upgrade management module can send an HTTP message of "pause software activation" to the in-vehicle upgrade management module of the target MPU node at any time based on the HTTP protocol. In other embodiments, during the activation of the upgrade package, the external upgrade management module can send an HTTPS message of "pause software activation" to the in-vehicle upgrade management module of the target MPU node at any time.

[0166] The "Pause Activation Software" message includes the message type, the name of the MPU node, the ID of this upgrade task, and the pause type (which can be paused, stopped, or continued).

[0167] 506: The in-vehicle upgrade management module responded to the external upgrade management module with the result of pausing software activation.

[0168] In this embodiment, after successfully receiving, parsing, and executing the HTTP message of the "Pause Activation Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module of the target MPU node should send an HTTP-formatted "Pause Activation Software Result" to the external upgrade management module. In other embodiments, after successfully receiving, parsing, and executing the HTTPS message of the "Pause Activation Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module of the target MPU node should send an HTTPS-formatted "Pause Activation Software Result" to the external upgrade management module.

[0169] The "Suspension Activation Software Result" message includes message type, MPU node name, ID of this upgrade task, activation progress, suspension type, and suspension result; the suspension type includes active suspension and passive suspension, and the suspension result includes suspension success and suspension failure.

[0170] Figure 8 The diagram illustrates the interaction between the external upgrade management module and the internal upgrade management module during the rollback process. For example... Figure 8 As shown, it includes:

[0171] 601: The external upgrade management module sends a request to the internal upgrade management module to roll back the software.

[0172] In this embodiment, when an MPU node fails to upgrade under abnormal circumstances, or when there is a need to roll back the MPU node version to ensure consistency of software program versions across all MPU nodes, a software rollback can be performed on the MPU node. For example, the external upgrade management module can send an HTTP message requesting software rollback to the in-vehicle upgrade management module. The requesting software rollback message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0173] In other embodiments, the external upgrade management module can send an HTTPS message requesting software rollback to the in-vehicle upgrade management module.

[0174] 602: The in-vehicle upgrade management module responds to the external upgrade management module with the rollback software execution status.

[0175] In this embodiment, after successfully receiving, parsing, and executing the "Request to Roll Back Software" HTTP message from the external upgrade management module, the in-vehicle upgrade management module can convert the "Request to Roll Back Software" HTTP message into a target message type corresponding to the "Request to Roll Back Software". The target message type refers to the message format of the target MPU node in the "Request to Roll Back Software", and the target MPU refers to the MPU corresponding to the "Request to Roll Back Software". The target MPU of the "Request to Roll Back Software" message can roll back the software based on the "Request to Roll Back Software" message, generating a "Rollback Software Execution Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Rollback Software Execution Status" message of the target message type, convert it into an HTTP-formatted "Rollback Software Execution Status" message, and send the "Rollback Software Execution Status" message to the external upgrade management module.

[0176] In other embodiments, after the in-vehicle upgrade management module corresponding to the target MPU node successfully receives, parses, and executes the HTTPS message "Request to Roll Back Software" sent by the external upgrade management module, it can convert the HTTPS message into the target message type corresponding to the "Request to Roll Back Software". Here, the target message type refers to the message format of the target MPU node of the "Request to Roll Back Software", and the target MPU refers to the MPU corresponding to the "Request to Roll Back Software". The target MPU of the "Request to Roll Back Software" message can roll back the software based on the "Request to Roll Back Software" message, generating a "Rollback Software Execution Status" message of the target message type. The in-vehicle upgrade management module can obtain the "Rollback Software Execution Status" message of the target message type, convert it into an HTTPS format "Rollback Software Execution Status" message, and send the "Rollback Software Execution Status" message to the external upgrade management module.

[0177] The "Rollback Software Execution Status" message includes the message type, the name of the MPU node, the ID of this upgrade task, and the rollback software execution status; the rollback software execution status includes rollback successful, rollback in progress, rollback paused, and rollback failed.

[0178] 603: The external upgrade management module sends a request to the internal upgrade management module for software rollback status and progress.

[0179] In this embodiment, during the rollback of the upgrade package, the external upgrade management module can send a "request for software rollback status and progress" to the in-vehicle upgrade management module of the target MPU node via HTTP messages at any time or periodically. In other embodiments, during the rollback of the upgrade package, the external upgrade management module can send a "request for software rollback status and progress" to the in-vehicle upgrade management module of the target MPU node via HTTPS messages at any time or periodically.

[0180] The "Request Software Rollback Status and Progress" message includes the message type, the name of the MPU node, and the ID of this upgrade task.

[0181] In some embodiments, during the process of the in-vehicle upgrade management module of the target MPU obtaining the "request to roll back software" message, the in-vehicle upgrade management module can send the "software rollback status and progress" message to the external upgrade management module at any time or periodically.

[0182] 604: The in-vehicle upgrade management module responds to the external upgrade management module with the software rollback status and progress.

[0183] In this embodiment, after successfully receiving and parsing the HTTP message "Request software rollback status and progress" from the external upgrade management module, the in-vehicle upgrade management module can convert the HTTP message into a target message type corresponding to the "Request software rollback status and progress". The target message type refers to the message format of the target MPU node in the "Request software rollback status and progress", and the target MPU refers to the MPU corresponding to the "Request software rollback status and progress". The target MPU in the "Request software rollback status and progress" can roll back the software, generating a "Software rollback status and progress" message of the target message type. The in-vehicle upgrade management module can obtain the "Software rollback status and progress" message of the target message type, convert it into an HTTP format "Software rollback status and progress" message, and send the HTTP format "Software rollback status and progress" message to the external upgrade management module.

[0184] In other embodiments, after successfully receiving and parsing the HTTPS message "Request software rollback status and progress" from the external upgrade management module, the in-vehicle upgrade management module can convert the HTTPS message into a target message type corresponding to the "Request software rollback status and progress". The target message type refers to the message format of the target MPU node in the "Request software rollback status and progress", and the target MPU refers to the MPU corresponding to the "Request software rollback status and progress". The target MPU in the "Request software rollback status and progress" can roll back the software, generating a "Software rollback status and progress" message of the target message type. The in-vehicle upgrade management module can obtain the "Software rollback status and progress" message of the target message type, convert it into an HTTPS format "Software rollback status and progress" message, and send the HTTPS format "Software rollback status and progress" message to the external upgrade management module.

[0185] The "Software Rollback Status and Progress" message includes the message type, the name of the MPU node, the ID of this upgrade task, the software rollback execution status, and the rollback progress. The software rollback execution status includes rolling, rollback paused, rollback completed, and rollback failed. The rollback progress can be any real number between 0 and 1.

[0186] If the rollback progress is less than 1 and continues to increase, the software is confirmed to be rolling back; if the rollback progress is 1, the software rollback is confirmed to be complete; if the rollback progress is less than 1, the rollback progress is paused and a "pause rollback software" message is received, the software rollback is confirmed to be paused; if the rollback progress is less than 1, the rollback progress is paused and a "pause rollback software" message is not received, the software rollback is confirmed to have failed.

[0187] It is understandable that if the "software rollback status and progress" indicates that the installation has failed, the external upgrade management module will retransmit the upgrade package to the internal upgrade management module.

[0188] 605: The external upgrade management module sends a pause rollback software to the internal upgrade management module.

[0189] In the embodiments of this application, during the rollback of the upgrade package, the external upgrade management module can send an HTTP message of "pause software rollback" to the in-vehicle upgrade management module of the target MPU node at any time. In other embodiments, during the rollback of the upgrade package, the external upgrade management module can send an HTTPS message of "pause software rollback" to the in-vehicle upgrade management module of the target MPU node at any time.

[0190] The "Pause and Rollback Software" message includes the message type, the name of the MPU node, the ID of this upgrade task, and the pause type (which can be paused, stopped, or continued).

[0191] 606: The in-vehicle upgrade management module responds to the external upgrade management module with a pause on the software rollback result.

[0192] In this embodiment, after successfully receiving, parsing, and executing the HTTP message "Pause Rollback Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module should send an HTTP-formatted "Pause Rollback Software Result" to the external upgrade management module. In other embodiments, after successfully receiving, parsing, and executing the HTTPS message "Pause Rollback Upgrade Package" from the external upgrade management module, the in-vehicle upgrade management module should send an HTTPS-formatted "Pause Rollback Software Result" to the external upgrade management module.

[0193] The "Pause and Rollback Software Result" message includes message type, MPU node name, ID of this upgrade task, rollback progress, pause type, and pause result; the pause type includes active pause and passive pause, and the pause result includes pause success and pause failure.

[0194] This application embodiment supports software rollback functionality, meaning that if software version incompatibility issues are encountered during the upgrade process, the original version of each MPU node can be quickly restored as needed, effectively ensuring the consistency and compatibility of the terminal device system version and providing users with a more secure, convenient, and reliable upgrade experience.

[0195] The following example uses a vehicle-mounted device 100 as the terminal device, combined with... Figure 9 This paper describes the state change process of the upgrade state machine corresponding to the in-vehicle upgrade management module when each MPU node within the vehicle-mounted equipment 100 is upgraded. The state of the upgrade state machine represents the state of the in-vehicle upgrade management module.

[0196] The states of the upgrade state machine are described below, as shown in Table 1. The upgrade state machine includes the initial state, the idle state, the transmitting state, the transmitting state, the installing state, the installing state, the activating state, the activated state, the rolling back state, and the rolled back state.

[0197] Table 1

[0198]

[0199]

[0200] The following is combined Figure 9 Tables 1 and 2 introduce the actions in the upgrade status diagram and their corresponding triggering conditions.

[0201] Table 2

[0202]

[0203]

[0204]

[0205] The initial state of operation 13, or the final state of operation 12, is called the temporary state.

[0206] In this embodiment, each MPU node within the vehicle-mounted device 100 uses a standardized upgrade state machine for state maintenance. The external upgrade management module (or the third upgrade management module) can uniformly schedule and switch the upgrade state machines of each MPU node, thereby achieving seamless monitoring and unified management of the upgrade process of all MPU nodes, enhancing the controllability and operational efficiency of the software upgrade system.

[0207] This application also provides a software upgrade method, which is applied to a terminal device. The terminal device includes a first upgrade management module and a second upgrade management module. The method includes: the first upgrade management module receiving first upgrade data from a third upgrade management module based on a first communication protocol, converting the first upgrade data into second upgrade data, and upgrading the software program corresponding to the second upgrade data based on the second upgrade data. The first upgrade data is in a first format, and the second upgrade data is in a second format. The second upgrade management module receiving third upgrade data from the third upgrade module based on the first communication protocol, converting the third upgrade data into fourth upgrade data, and upgrading the software program corresponding to the fourth upgrade data based on the fourth upgrade data. The third upgrade data is in a first format, and the fourth upgrade data is in a third format.

[0208] This application embodiment also provides a software upgrade system, characterized in that the software upgrade system includes a terminal device and a server. The terminal device includes a first upgrade management module and a second upgrade management module, and the server includes a third upgrade management module. The system includes: the third upgrade management module detecting first upgrade data corresponding to the first upgrade management module, and sending the first upgrade data to the first upgrade management module based on a first communication protocol, wherein the format of the first upgrade data is a first format; the first upgrade management module converting the first upgrade data into second upgrade data, wherein the second upgrade data is in a second format, and the first upgrade management module upgrading the software program corresponding to the second upgrade data based on the second upgrade data; the third upgrade module detecting third upgrade data corresponding to the second upgrade module, and sending the third upgrade data to the second upgrade module based on the first communication protocol, wherein the format of the third upgrade data is a first format; the second upgrade module converting the third upgrade data into fourth upgrade data, wherein the format of the fourth upgrade data is a third format, and the second upgrade module upgrading the software program corresponding to the fourth upgrade data based on the fourth upgrade data.

[0209] This application also provides a terminal device, including a memory for storing instructions executed by one or more processors of an electronic device; and a processor, one of the processors of the electronic device, for executing the instructions stored in the memory to implement the software upgrade method on the terminal device side described above. In some embodiments, the terminal device may be an in-vehicle device.

[0210] This application also provides a server for performing a server-side software upgrade method.

[0211] This application also provides a vehicle, including an on-board device.

[0212] According to the embodiments of this application, Figure 10A block diagram of an in-vehicle device 100 is shown. The in-vehicle device 100 may include a driving system 202, a sensor system 204, a control system 206, one or more peripheral devices 208, a power supply 210, a computer system 212, and a user interface 216. Optionally, the in-vehicle device 100 may include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of the in-vehicle device 100 may be interconnected via wired or wireless means.

[0213] The mobility system 202 may include components that provide powered motion to the vehicle-mounted device 100. The sensor system 204 may include several sensors that sense information about the environment surrounding the vehicle-mounted device 100. The control system 206 controls the operation of the vehicle-mounted device 100 and its components.

[0214] The vehicle-mounted device 100 interacts with external sensors, other vehicles, other computer systems, or users via peripheral devices 208. In some embodiments, peripheral devices 208 provide a means for users of the vehicle-mounted device 100 to interact with a user interface 216. A power source 210 can provide power to various components of the vehicle-mounted device 100. In one embodiment, the power source 210 can be a rechargeable lithium-ion or lead-acid battery. One or more battery packs of such batteries can be configured to provide power to various components of the vehicle-mounted device 100. Some or all of the functions of the vehicle-mounted device 100 are controlled by a computer system 212. The computer system 212 may include at least one processor 213 that executes instructions 215 stored in a non-transitory computer-readable medium such as a data storage device 214. The computer system 212 may also be multiple computing devices that control individual components or subsystems of the vehicle-mounted device 100 in a distributed manner.

[0215] Processor 213 can be any conventional processor, such as an MPU or a commercially available central processing unit (CPU). Processor 213 includes a first upgrade management module 2131 for acquiring and parsing upgrade packages. In some embodiments, data storage device 214 may contain instructions 215 (e.g., program logic) that can be executed by processor 213 to perform various functions of the vehicle-mounted device 100. In addition to instructions 215, data storage device 214, acting as a memory, may also store data such as road maps, route information, vehicle position, direction, speed, and other such vehicle data, as well as other information. This information can be used by the vehicle-mounted device 100 and computer system 212 during operation of the vehicle-mounted device 100 in autonomous, semi-autonomous, and / or manual modes. Examples include, for instance, the location information of the target vehicle, the current attitude of the target vehicle, the location information of the target parking space, and the location information of obstacles.

[0216] User interface 216 is used to provide information to or receive information from a user of the vehicle-mounted device 100. Optionally, user interface 216 may include one or more input / output devices within a set of peripheral devices 208. Computer system 212 may control the functions of the vehicle-mounted device 100 based on input received from various subsystems (e.g., mobility system 202, sensor system 204, and control system 206) and from user interface 216.

[0217] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, compact disc-read-only memory (CD-ROMs), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0218] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0219] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0220] It should be noted that, in the examples and description of this patent, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0221] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

Claims

1. A software upgrade method, characterized in that, The method is applied to a software upgrade system, which includes a terminal device and a server. The terminal device includes a first upgrade management module and a second upgrade management module, and the server includes a third upgrade management module. The method includes: The third upgrade management module detects the first upgrade data corresponding to the first upgrade management module, and sends the first upgrade data to the first upgrade module based on the first communication protocol. The format of the first upgrade data is the first format. The first upgrade management module converts the first upgrade data into second upgrade data, the second upgrade data being in a second format, and the first upgrade management module upgrades the software program corresponding to the second upgrade data based on the second upgrade data; The third upgrade management module detects the third upgrade data corresponding to the second upgrade management module, and sends the third upgrade data to the second upgrade module based on the first communication protocol. The format of the third upgrade data is the first format. The second upgrade management module converts the third upgrade data into fourth upgrade data, the fourth upgrade data being in the third format, and the second upgrade management module upgrades the software program corresponding to the fourth upgrade data based on the fourth upgrade data.

2. The software upgrade method according to claim 1, characterized in that, The terminal device includes a first MPU node and a second MPU node. The first upgrade management module is used to upgrade the software program corresponding to the first MPU node, and the second upgrade management module is used to upgrade the software program corresponding to the second MPU node.

3. The software upgrade method according to claim 1, characterized in that, The first communication protocol is a high-speed, high-bandwidth transmission protocol, which includes any one of the following: Hypertext Transfer Protocol, Hypertext Transfer Secure Protocol, File Transfer Protocol, IP-based diagnostic protocol, and full-duplex communication protocol.

4. The software upgrade method according to claim 1, characterized in that, The third upgrade management module detects the first upgrade data corresponding to the first upgrade management module, and sends the first upgrade data to the first upgrade management module based on the first communication protocol, including: The third upgrade management module detects the first upgrade data corresponding to the first upgrade management module and sends a first task establishment request to the first upgrade management module based on the first communication protocol; Upon receiving the first task creation request, the first upgrade management module sends a first task feedback request to the third upgrade management module based on the first communication protocol. Corresponding to the first task feedback request indicating that the terminal device has not installed the first upgrade data, the third upgrade management module sends the first upgrade data to the first upgrade management module based on the first communication protocol.

5. The software upgrade method according to claim 1, characterized in that, The first upgrade data and the third upgrade data include upgrade data, message type, MPU node identifier, upgrade task name, and upgrade data volume.

6. The software upgrade method according to claim 1, characterized in that, Also includes: When the third upgrade management module determines that the upgrade of the software program corresponding to the first upgrade data has failed, the third upgrade management module sends a rollback request to the first upgrade management module. The rollback request is used to change the version of the software program corresponding to the first upgrade data from the version corresponding to the first upgrade data to the version before the upgrade.

7. The software upgrade method according to claim 6, characterized in that, Also includes: If the third upgrade management module determines that the software program corresponding to the first upgrade data has failed to upgrade, the software program corresponding to the third upgrade data has successfully upgraded, and the correlation between the first MPU corresponding to the first upgrade management module and the second MPU corresponding to the second upgrade management module is greater than the correlation threshold, the third upgrade management module sends a rollback request to both the first upgrade management module and the second upgrade management module.

8. The software upgrade method according to any one of claims 1 to 7, characterized in that, The terminal device is a vehicle-mounted device.

9. A software upgrade method, characterized in that, The software upgrade method is applied to a terminal device, the terminal device including a first upgrade management module and a second upgrade management module, the method including: The first upgrade management module receives first upgrade data from the third upgrade management module based on the first communication protocol, converts the first upgrade data into second upgrade data, and upgrades the software program corresponding to the second upgrade data based on the second upgrade data. The format of the first upgrade data is the first format, and the format of the second upgrade data is the second format. The second upgrade management module receives third upgrade data from the third upgrade management module based on the first communication protocol, converts the third upgrade data into fourth upgrade data, and upgrades the software program corresponding to the fourth upgrade data based on the fourth upgrade data. The format of the third upgrade data is the first format, and the format of the fourth upgrade data is the third format.

10. A software upgrade system, characterized in that, The software upgrade system includes terminal devices and a server. The terminal devices include a first upgrade management module and a second upgrade management module. The server includes a third upgrade management module. The system includes: The third upgrade management module detects the first upgrade data corresponding to the first upgrade management module, and sends the first upgrade data to the first upgrade module based on the first communication protocol. The format of the first upgrade data is the first format. The first upgrade management module converts the first upgrade data into second upgrade data, the second upgrade data being in a second format, and the first upgrade management module upgrades the software program corresponding to the second upgrade data based on the second upgrade data; The third upgrade management module detects the third upgrade data corresponding to the second upgrade management module, and sends the third upgrade data to the second upgrade module based on the first communication protocol. The format of the third upgrade data is the first format. The second upgrade management module converts the third upgrade data into fourth upgrade data, the fourth upgrade data being in the third format, and the second upgrade management module upgrades the software program corresponding to the fourth upgrade data based on the fourth upgrade data.

11. A terminal device, characterized in that, It includes a memory for storing instructions executable by one or more processors of an electronic device; and a processor, one of the processors of the electronic device, for executing the instructions stored in the memory to implement the software upgrade method of claim 9.

Images