Parallel upgrade methods, apparatus, devices, and media with dependent nodes

Abstract

This invention provides a parallel upgrade method for nodes with dependencies. In this invention, since the dependent upgrade nodes include a first application partition and a second application partition, the first stage of the upgrade process for the dependent upgrade nodes is carried out in the second application partition, while the software in the first application partition runs normally and its functions remain normal. The upgrade process of all ordinary upgrade nodes that depend on it is not affected. After all ordinary upgrade nodes that depend on it have completed their upgrades, the second stage is executed to complete the upgrade. Since the first stage of the upgrade process for the dependent upgrade nodes in the dual application partitions occupies most of the upgrade process time, and the first stage is carried out simultaneously with the upgrade process of all ordinary upgrade nodes that depend on it, the total upgrade time is greatly reduced, thereby improving the user experience.

Description

Technical Field

[0001] This application relates to the field of software update technology, specifically to a parallel upgrade method, apparatus, device, and medium with dependent nodes. Background Technology

[0002] With the rapid development of computer and electronic technologies, electronic devices are ubiquitous in human life and production. Software, as the soul of electronic devices, plays an increasingly important role in these products. Furthermore, software is updatable throughout the product lifecycle, making software upgrades a fundamental technical capability for resolving product defects and iterating new features. Over-the-Air (OTA) technology, in particular, simplifies software updates, providing businesses and users with a faster and more convenient upgrade experience, and has been widely adopted across various industries. However, as a user-facing software upgrade technology, OTA places high demands on upgrade reliability and timeliness, especially in intelligent vehicles. With the increasing number of updatable ECUs and the growing size of software packages, excessively long upgrade times have become a pressing technical issue requiring optimization and improvement in the industry.

[0003] In intelligent vehicles, the problem of excessively long upgrade times is usually solved by management measures, such as controlling the number of ECUs upgraded at one time to reduce the upgrade time. However, this usually only meets the needs of solving individual product defects through software upgrades. If there are multiple product defects or new feature iterations involve multiple ECU upgrades, management measures cannot solve the problem. For electric vehicles, this means sacrificing the user experience and making users wait longer without using the vehicle. For gasoline vehicles, it means users have to upgrade frequently. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the present invention provides a parallel upgrade method, apparatus, device and medium with dependent nodes to solve the above technical problems.

[0005] This invention provides a parallel upgrade method with dependent nodes, applied to an upgrade server, the method comprising:

[0006] A node upgrade instruction carrying a node upgrade task is generated. The node upgrade instruction is used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a normal upgrade node. The dependency relationship means that the upgrade of the normal upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries the target dependent upgrade node and the target normal upgrade node to be upgraded.

[0007] Upon receiving a response instruction from the node to be upgraded to the node upgrade instruction, a first instruction is sent to the target ordinary upgrade node, causing the target ordinary upgrade node to execute a first software upgrade process to update and activate the software in the application partition, thereby completing the upgrade of the target ordinary upgrade node.

[0008] When sending the first instruction, a second instruction is sent to the target dependency upgrade node, causing the target dependency upgrade node to execute a second software upgrade process to update the software in the second application partition, thereby obtaining the updated software;

[0009] After the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, a third instruction is sent to the target dependent node to enable the target dependent upgrade node to execute the second software upgrade process to activate the software in the second application partition, switch the software running area from the first application partition to the second application partition and restart the system, so that the upgraded and updated software runs in the second application partition, thereby completing the upgrade of the target dependent upgrade node.

[0010] In one embodiment of the present invention, the first instruction includes a first program update instruction and a first program activation instruction, causing the target ordinary upgrade node to execute a first software upgrade process to upgrade the software running therein, including:

[0011] The upgrade server sends a first program update instruction to the target ordinary upgrade node, causing the target ordinary upgrade node to execute a first software update process based on the first program update instruction, obtain the first updated software, and verify the first updated software.

[0012] After verification, the upgrade server sends a first program activation command to the target ordinary upgrade node, causing the target ordinary upgrade node to perform a first activation and restart process on the first updated software based on the first program activation command, thereby completing the software upgrade.

[0013] In one embodiment of the present invention, the second instruction includes a second program update instruction, which causes the target dependent upgrade node to execute a second software upgrade process to update the software in the second application partition, including:

[0014] The upgrade server sends a second program update instruction to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software update process based on the second program update instruction, update the software in the second application partition, obtain the second updated software, and verify the second updated software.

[0015] In one embodiment of the present invention, the third instruction further includes a second program activation instruction, which causes the target dependent upgrade node to execute a second software upgrade process to activate the software in the second application partition, including:

[0016] The upgrade server sends a second program activation command to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software activation process based on the second program activation command. This process involves switching the software running area from the first application partition to the second application partition and restarting the system to complete the software upgrade.

[0017] In one embodiment of the present invention, generating a node upgrade instruction carrying a node upgrade task includes:

[0018] Get the local version number of the software running in the node and the corresponding latest version number of the software;

[0019] The latest version number is compared with the local version number. If the latest version number is higher than the local version number, the node is determined to be a node to be upgraded.

[0020] Node upgrade tasks are generated based on the nodes to be upgraded, and a list of node upgrade tasks is formed; wherein, each node to be upgraded corresponds to one node upgrade task;

[0021] The list of node upgrade tasks is embedded into the node upgrade command.

[0022] In one embodiment of the present invention, the step of generating a node upgrade task based on the node to be upgraded further includes:

[0023] Configure a task identifier for each node upgrade task and add the task identifier to the node upgrade task list.

[0024] In one embodiment of the present invention, the step of generating a node upgrade task based on the node to be upgraded further includes:

[0025] The nodes to be upgraded are grouped according to a pre-defined dependency list;

[0026] All ordinary upgrade nodes are assigned to the same group, and the nodes to be upgraded that have a dependency relationship with the ordinary upgrade nodes are assigned to the same group. The remaining nodes to be upgraded are divided into different groups according to their dependencies.

[0027] When upgrading nodes, all nodes in the same group are upgraded simultaneously, and the upgrades are completed sequentially according to the group order.

[0028] This invention provides a parallel upgrade method for nodes with dependency relationships, applied to nodes, the method comprising:

[0029] Receive node upgrade instructions sent by the upgrade server; the node upgrade instructions carry node upgrade instructions for the node upgrade task, the node upgrade instructions are used to instruct the node to be upgraded to perform an upgrade, the node to be upgraded includes: dependent upgrade nodes and ordinary upgrade nodes to be upgraded, the upgrade of the ordinary upgrade nodes depends on the dependent upgrade nodes; the dependent upgrade nodes include a first application partition and a second application partition with software, and the node upgrade task carries the target dependent upgrade node and the target ordinary upgrade node to be upgraded;

[0030] The system generates a return instruction in response to the node upgrade instruction and sends the return instruction to the upgrade server.

[0031] The ordinary upgrade node receives a first instruction generated by the upgrade server in response to the return instruction, and executes a first software upgrade process according to the first instruction to update and activate the software in the application partition, so as to complete the upgrade of the target ordinary upgrade node.

[0032] The target dependent node receives a second instruction generated by the response of the upgrade server to the return instruction, and executes a second software upgrade process according to the second instruction to update the software in the second application partition, thereby obtaining the updated software; wherein, the second instruction and the first instruction are received simultaneously.

[0033] The target dependent node receives a third instruction sent by the upgrade server and executes a second software upgrade process according to the third instruction to activate the software in the second application partition, switching the software running area from the first application partition to the second application partition, so that the upgraded updated software runs in the second application partition, thereby completing the upgrade of the target dependent upgrade node; wherein, the third instruction is sent after the target ordinary upgrade node completes the software upgrade and after the target dependent node completes the software update.

[0034] This invention provides a parallel upgrade device with dependent nodes, applied to an upgrade server, the device comprising:

[0035] The instruction generation module is used to generate node upgrade instructions carrying node upgrade tasks. The node upgrade instructions are used to instruct nodes to upgrade. The nodes include: dependent upgrade nodes and ordinary upgrade nodes to be upgraded. The dependency relationship means that the upgrade of the ordinary upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries the target dependent upgrade node and the target ordinary upgrade node to be upgraded.

[0036] The first sending module is used to send a first instruction to the target ordinary upgrade node when it receives a return instruction from the node to be upgraded in response to the node upgrade instruction, so that the target ordinary upgrade node executes the first software upgrade process to update and activate the software in the application partition, so as to complete the upgrade of the target ordinary upgrade node.

[0037] The second sending module is used to send a second instruction to the target dependency upgrade node when sending the first instruction, so that the target dependency upgrade node executes the second software upgrade process to update the software in the second application partition and obtain the updated software.

[0038] The third sending module is used to send a third instruction to the target dependent node after the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, so as to enable the target dependent upgrade node to execute the second software upgrade process to activate the software in the second application partition, thereby completing the upgrade of the target dependent upgrade node.

[0039] This invention provides a parallel upgrade device with dependent nodes, applied to nodes, the device comprising:

[0040] A receiving module is used to receive node upgrade instructions sent by an upgrade server. The node upgrade instructions carry node upgrade instructions for a node upgrade task. The node upgrade instructions are used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a normal upgrade node. The dependency relationship means that the upgrade of the normal upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries the target dependent upgrade node and the target normal upgrade node to be upgraded.

[0041] The fourth sending module is used to generate a return instruction in response to the node upgrade instruction and send the return instruction to the upgrade server;

[0042] The first node upgrade module is used to receive a first instruction generated by the upgrade server in response to the return instruction through a normal upgrade node, and execute a first software upgrade process according to the first instruction to update and activate the software in the application partition of the normal upgrade node, so as to complete the upgrade of the target normal upgrade node.

[0043] The second node upgrade module is used to receive a second instruction generated by the upgrade server in response to the return instruction through the target dependent node, and to execute the software upgrade process according to the second instruction to update the software in the second application partition to obtain the updated software; wherein, the second instruction and the first instruction are received simultaneously.

[0044] The third node upgrade module is used to receive a third instruction sent by the upgrade server through the target dependent node, and to execute a second software upgrade process according to the third instruction to activate the software in the second application partition. This is used to switch the software running area from the first application partition to the second application partition, so that the upgraded software runs in the second application partition, thereby completing the upgrade of the target dependent upgrade node. The third instruction is sent after the target ordinary upgrade node has completed the software upgrade process and the target dependent upgrade node has completed the software update process.

[0045] The present invention provides an electronic device comprising:

[0046] One or more processors;

[0047] A storage device for storing one or more programs that, when executed by one or more processors, enable the electronic device to perform the upgrade method described above.

[0048] The present invention provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a computer's processor, cause the computer to perform the upgrade method described above.

[0049] The present invention provides a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the upgrade method as described above.

[0050] The beneficial effects of this invention are:

[0051] This invention discloses a parallel upgrade method, apparatus, device, and medium for nodes with dependency relationships. The method includes: generating a node upgrade instruction carrying a node upgrade task, the node upgrade instruction instructing a node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a regular upgrade node, the dependency relationship indicating that the upgrade of the regular upgrade node is performed while the dependent upgrade node is functioning normally; the dependent upgrade node includes a first application partition and a second application partition with software; the node upgrade task carries a target dependent upgrade node and a target regular upgrade node to be upgraded; upon receiving a return instruction from the node to be upgraded responding to the node upgrade instruction, a first instruction is sent to the target regular upgrade node, causing the target regular upgrade node to execute a first software upgrade. The process updates and activates the software in the application partition to complete the upgrade of the target ordinary upgrade node. When sending the first instruction, a second instruction is sent to the target dependent upgrade node, causing the target dependent upgrade node to execute the second software upgrade process to update the software in the second application partition, resulting in the updated software. After the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, a third instruction is sent to the target dependent node, causing the target dependent upgrade node to execute the second software upgrade process to activate the software in the second application partition. This involves switching the software running area from the first application partition to the second application partition and restarting the system, so that the upgraded and updated software runs in the second application partition, thereby completing the upgrade of the target dependent upgrade node.

[0052] In this invention, the upgrade server sends program update instructions and activation / restart instructions to ordinary upgrade nodes to complete the software upgrade. Simultaneously, the upgrade server sends program update instructions to dependent upgrade nodes to complete the first stage of the software upgrade. Then, the upgrade server sends activation / restart instructions to dependent upgrade nodes to complete the second stage of the software upgrade, thus completing the entire upgrade. Since dependent upgrade nodes include a first application partition and a second application partition, with the software in the first application partition running and the software in the second application partition not running, the first stage of the upgrade process for dependent upgrade nodes is performed in the second application partition, while the software in the first application partition runs normally and its functionality remains normal. The upgrade process of all ordinary upgrade nodes that depend on it is unaffected. The second stage is executed only after all ordinary upgrade nodes that depend on it have completed their upgrades, completing the upgrade. Because the first stage of the upgrade process for dependent upgrade nodes in both application partitions occupies the majority of the upgrade time, and by performing the first stage simultaneously with the upgrade processes of all ordinary upgrade nodes that depend on it, the total upgrade time is greatly reduced, thereby improving the user experience.

[0053] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0055] Figure 1 The figure shows a common vehicle architecture as illustrated in an exemplary embodiment of this application;

[0056] Figure 2 This is a schematic diagram illustrating the implementation environment of a parallel upgrade method with dependent nodes, as shown in an exemplary embodiment of this application.

[0057] Figure 3 This is a flowchart illustrating a parallel upgrade method with dependent nodes, as shown in an exemplary embodiment of this application;

[0058] Figure 4 This is a flowchart of a method for generating node upgrade instructions in an exemplary embodiment of this application;

[0059] Figure 5 This is a flowchart illustrating the generation of a node upgrade task in an exemplary embodiment of this application;

[0060] Figure 6 This is a schematic block diagram illustrating the composition of a typical upgrade node in an exemplary embodiment of this application;

[0061] Figure 7 This is an upgrade flowchart of a normal upgrade node in an exemplary embodiment of this application;

[0062] Figure 8 This is a schematic block diagram illustrating the composition of the upgrade node in an exemplary embodiment of this application;

[0063] Figure 9 This is an upgrade flowchart that depends on the upgrade node in an exemplary embodiment of this application;

[0064] Figure 10 This is a schematic diagram illustrating the total upgrade time of existing parallel upgrade technologies that do not employ the present invention;

[0065] Figure 11 This is a schematic diagram illustrating the total upgrade time using the existing parallel upgrade technology of this invention, as an exemplary embodiment of this application.

[0066] Figure 12 This is a schematic diagram illustrating a parallel upgrade apparatus with dependent nodes applied to a server, as shown in an exemplary embodiment of this application.

[0067] Figure 13 This is a schematic diagram illustrating a parallel upgrade device with dependent nodes applied to a node, as shown in an exemplary embodiment of this application.

[0068] Figure 14 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0069] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0070] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0071] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0072] First, it should be clarified that software is a collection of computer data and instructions organized in a specific order. Generally speaking, software is divided into system software, application software, and middleware, which falls between the two. Software does not only include computer programs that can run on a computer (in the broad sense of a computer), but also the documentation associated with these computer programs is generally considered part of software. Simply put, software is a collection of programs and documentation.

[0073] Software upgrades refer to updating software from a lower version to a higher version. Since higher versions often fix bugs in lower versions, software upgrades generally result in better performance and optimization, leading to a better user experience.

[0074] To address the time-consuming nature of software upgrades through management methods, existing technologies utilize parallel upgrade techniques. This involves upgrading nodes in parallel, but only those nodes with no dependencies on each other. Specifically, parallel upgrades divide ECUs that can be upgraded simultaneously into one parallel node upgrade task, while those that cannot be upgraded simultaneously are moved to the next parallel node upgrade task, until all node upgrade tasks are completed. However, in intelligent vehicles, ECUs with dependencies are prevalent in the upgrade process; that is, nodes with dependencies are common, meaning that the upgrade of a later node depends on the upgrade of a previous node. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of a common vehicle architecture. Figure 1 In this context, ECU-A, ECU-B, and ECU-M are dependent upgrade nodes, while ECU-X1 and ECU-X2 are ordinary upgrade nodes. The dependencies between upgrade nodes include, but are not limited to, the following categories: (1) Power distribution dependency: ECU-B, ECU-X1, and ECU-X2 are controlled by ECU-A for power distribution. If ECU-A is upgraded in parallel with ECU-B, ECU-X1, and ECU-X2, executing the activation restart command during the upgrade process of ECU-A will cause the power distribution function to change or temporarily fail, thereby causing the upgrade of ECU-B, ECU-X1, and ECU-X2 to fail. Therefore, ECU-A is a dependent upgrade node. If the BCM has the function of controlling the power on and off of the whole vehicle, the ECUs in the power domain, chassis domain, and driving domain can usually only work when the whole vehicle is powered on. Therefore, the BCM and the ECUs in the power domain, chassis domain, and driving domain cannot be upgraded in parallel. (2) Upgrade communication channel dependency: ECU-B is an intermediate routing node for the upgrade communication channel of ECU-X1. If ECU-B and ECU-X1 are upgraded in parallel, executing an activation restart command during the upgrade process of ECU-B will cause the upgrade communication channel of ECU-X1 to be interrupted, thus causing the upgrade of ECU-X1 to fail. Therefore, ECU-B is a dependent upgrade node. (3) Upgrade server node dependency: ECU-M acts as the upgrade server, responsible for upgrading other nodes to be upgraded. If ECU-M is upgraded in parallel with ECU-A, ECU-B, ECU-X1, and ECU-X2, executing an activation restart command during the upgrade process of ECU-M will cause the upgrade server to temporarily fail, thus causing the upgrades of ECU-A, ECU-B, ECU-X1, and ECU-X2 to fail. Therefore, ECU-M is a dependent node. Figure 1If ECU-M, ECU-A, ECU-B, ECU-X1, and ECU-X2 are upgraded in parallel, it can be analyzed that ECU-M, ECU-A, and ECU-B are dependent nodes.

[0075] In order to address similar issues Figure 1 This application provides a parallel upgrade method for nodes with dependencies, based on the topology shown. In this method, the nodes to be upgraded include dependent upgrade nodes and ordinary upgrade nodes. The dependent upgrade nodes are divided into a first application partition and a second application partition. The software in the first application partition is running, while the software in the second application partition is not running. The first stage of the upgrade process for the dependent upgrade nodes is performed in the second application partition, while the software in the first application partition continues to run normally and its functionality remains intact. The upgrade process of all ordinary upgrade nodes that depend on it is unaffected. After all ordinary upgrade nodes that depend on it have completed their upgrades, the second stage is executed to complete the upgrade. Because the first stage of the upgrade process for the dependent upgrade nodes in both application partitions occupies the majority of the upgrade time, and by performing the first stage concurrently with the upgrade process of all ordinary upgrade nodes that depend on it, the total upgrade time is greatly reduced, thereby improving the user experience.

[0076] Figure 2 This is a schematic diagram illustrating an implementation environment for an exemplary parallel upgrade method with dependent nodes, as described in this application. Please refer to... Figure 1 The implementation environment includes a terminal device 201 and a server 202, which communicate with each other via a wired or wireless network.

[0077] It should be understood that Figure 2 The number of terminal devices 201 and servers 202 shown is merely illustrative. Any number of terminal devices 201 and servers 202 can be used depending on actual needs.

[0078] Among them, terminal device 201 corresponds to the client, which can be any electronic device with a user input interface, including but not limited to smartphones, tablets, laptops, computers, in-vehicle computers, etc. The user input interface includes but is not limited to touch screens, keyboards, physical buttons, audio pickup devices, etc.

[0079] Among them, server 202 corresponds to the server side, which can be a server that provides various services. It can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. This section does not impose any restrictions on this.

[0080] Terminal device 201 can communicate with server 202 via wireless networks such as 3G (third-generation mobile information technology), 4G (fourth-generation mobile information technology), and 5G (fifth-generation mobile information technology), and this is not restricted here.

[0081] Because existing technologies suffer from long software upgrade times, this application proposes a parallel upgrade method with dependent nodes, a parallel upgrade device with dependent nodes, an electronic device, a computer-readable storage medium, and a computer program product to address these issues. These embodiments will be described in detail below.

[0082] Please see Figure 3 , Figure 3 This is a flowchart illustrating a parallel upgrade method with dependent nodes, as shown in an exemplary embodiment of this application. The method can be applied to... Figure 2 The implementation environment shown is specifically executed by server 202 within that implementation environment. It should be understood that this method can also be applied to other exemplary implementation environments and specifically executed by devices in other implementation environments; this embodiment does not limit the implementation environment to which the method is applicable.

[0083] Please see Figure 3 , Figure 3 The flowchart below illustrates an exemplary parallel upgrade method with dependent nodes, applied to a server. The upgrade method includes at least steps S310 to S340, detailed below:

[0084] Step S310: Generate a node upgrade instruction carrying a node upgrade task. The node upgrade instruction is used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a normal upgrade node. The dependency relationship means that the upgrade of the normal upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries the target dependent upgrade node and the target normal upgrade node to be upgraded.

[0085] The software in the first application partition is running and can perform normal functions; while the software in the second application partition is not running.

[0086] In one exemplary embodiment, please refer to Figure 4 , Figure 4 This is a flowchart of a method for generating a node upgrade instruction in an exemplary embodiment. Specifically, generating the node upgrade instruction carrying the node upgrade task includes steps S410 to S430:

[0087] Step S410: Obtain the local version number of the software running in the node and the latest version number of the corresponding software;

[0088] Step S420: Compare the latest version number with the local version number. If the latest version number is higher than the local version number, determine that the node is a node to be upgraded.

[0089] Step S430: Generate node upgrade tasks based on the nodes to be upgraded, and form a node upgrade task list; wherein, each node to be upgraded corresponds to one node upgrade task;

[0090] Step S440: Embed the node upgrade task list into the node upgrade instruction.

[0091] It's important to note that the local version number of the software refers to the version number of the software currently running on the node, which can be read from the upgrade server. The latest version number of the software can be stored on the upgrade server. After reading the local version number, the upgrade server compares it with the corresponding latest version number of the software. If the latest version number is higher than the local version number, the node is determined to be a node to be upgraded. For example, if the local version number is XXXX.1.0 and the latest version number is XXXX.2.0, it can be determined that the latest version number is higher than the local version number, therefore, the corresponding node can be determined to be a node to be upgraded. At this point, a node upgrade task can be generated for the node to be upgraded, forming a node upgrade task list. This list is then embedded into the node upgrade command, thus carrying the corresponding node upgrade tasks within the node upgrade command. Upon receiving the corresponding node upgrade command, the node parses the command to obtain the node upgrade tasks, further determining the dependent upgrade nodes and ordinary upgrade nodes that need to be upgraded.

[0092] In one embodiment of the present invention, the step of generating a node upgrade task based on the node to be upgraded further includes:

[0093] Configure a task identifier for each node upgrade task and add the task identifier to the node upgrade task list.

[0094] In the step of generating node upgrade tasks, a task identifier is configured for each node upgrade task. This task identifier can be used to identify the corresponding node upgrade task. The task identifier can be the name of the node to be upgraded; the corresponding node to be upgraded can be found based on the node name.

[0095] In one embodiment of the present invention, please refer to Figure 5 , Figure 5 Here is a flowchart of a node upgrade task generated in an exemplary embodiment, such as Figure 5 As shown, the step of generating a node upgrade task based on the node to be upgraded further includes:

[0096] Step S510: Group the nodes to be upgraded according to the pre-set dependency list;

[0097] A pre-defined dependency list records which nodes depend on which nodes for upgrades. Nodes with dependencies are grouped into the same group, which includes dependent upgrade nodes and ordinary nodes. The upgrade of ordinary nodes depends on dependent nodes.

[0098] Step S520: All ordinary upgrade nodes are assigned to the same group, and the nodes to be upgraded that have a dependency relationship with the ordinary upgrade nodes are assigned to the same group. The remaining nodes to be upgraded are divided into different groups according to their dependency relationships.

[0099] After the upgrade server determines the nodes to be upgraded, including which nodes are dependent on the upgrade nodes and which are ordinary upgrade nodes, since the upgrade process of ordinary upgrade nodes will not affect other upgrade nodes, all ordinary upgrade nodes can be assigned to the same group. With the adoption of this invention, the nodes to be upgraded that have a dependency relationship with the ordinary upgrade nodes can be assigned to the same group, improving upgrade efficiency. The remaining nodes to be upgraded are divided into different groups according to their dependency relationships.

[0100] Step S530: Generate the upgrade order for each group according to the grouping order;

[0101] Based on the order of the groups, the group that comes first has no impact on the upgrade process of the nodes to be upgraded in the subsequent groups. Therefore, the upgrade order of each group can be generated based on the order of the groups.

[0102] Step S540: When upgrading the node to be upgraded, upgrade the nodes in different groups according to the priority.

[0103] After determining the order in which nodes in different groups should be upgraded, the nodes in different groups should be upgraded in that order.

[0104] Step S320: Upon receiving the return instruction of the node to be upgraded in response to the node upgrade instruction, a first instruction is sent to the target ordinary upgrade node to cause the target ordinary upgrade node to execute the first software upgrade process to update and activate the software in the application partition, so as to complete the upgrade of the target ordinary upgrade node.

[0105] In one embodiment of the present invention, the first instruction includes a first program update instruction and a first program activation instruction, causing the target ordinary upgrade node to execute a first software upgrade process to upgrade the software running therein, including:

[0106] The upgrade server sends a first program update instruction to the target ordinary upgrade node, causing the target ordinary upgrade node to execute a first software update process based on the first program update instruction, obtain the first updated software, and verify the first updated software.

[0107] After verification, the upgrade server sends a first program activation command to the target ordinary upgrade node, causing the target ordinary upgrade node to execute the first software activation process based on the first program activation command, and to perform an activation restart process on the first updated software, that is, to restart the system and complete the software upgrade.

[0108] It should be noted that the first program update instruction is used to instruct the software to update, and the first program activation instruction is used to instruct the updated software to activate and restart, thereby completing the software upgrade, which is the upgrade of a normal upgrade node.

[0109] Please see Figure 6 , Figure 6 This is a schematic block diagram illustrating the composition of a typical upgrade node in an exemplary embodiment, such as... Figure 6 As shown, a normal upgrade node is a single application partition upgrade node, which includes a bootloader partition and an application partition. The bootloader partition has a software upgrade module and an activation / reboot module, and has complete software upgrade functionality. The application partition only has an instruction receiving module and does not have software upgrade functionality.

[0110] Please see Figure 7 , Figure 7 Here is a flowchart of the upgrade process for a typical upgrade node in an exemplary embodiment, such as... Figure 7 As shown, the upgrade process includes:

[0111] S710: When the program runs in the application partition, after the instruction receiving module receives the first program update instruction, it sets the program update status, the node restarts and enters the boot program partition and activates the software upgrade module; if the program runs in the boot program partition, after the instruction receiving module in the software upgrade module receives the first program update instruction, it activates the software upgrade module.

[0112] In the S720, the instruction receiving module in the application partition receives the first program update instruction, erases and updates the program data in the application partition until the data of all target software is written, thus completing the software update.

[0113] The S730's activation and restart module in the bootloader partition verifies the program data in the application partition. Once the verification is successful, the application partition is activated.

[0114] The S740's activation and restart module in the bootloader partition allows the control node to restart and then run the target software (i.e., the updated software) in the application partition.

[0115] Step S330: When sending the first instruction, a second instruction is sent to the target dependency upgrade node, causing the target dependency upgrade node to execute the second software upgrade process to update the software in the second application partition, thereby obtaining the updated software.

[0116] Step S340: After the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, a third instruction is sent to the target dependent upgrade node to enable the target dependent upgrade node to execute the second software upgrade process to activate the software in the second application partition and switch the software running area from the first application partition to the second application partition, so as to complete the upgrade of the target dependent upgrade node.

[0117] In one embodiment of the present invention, the second instruction includes a second program update instruction, which causes the target dependent upgrade node to execute a second software upgrade process to update the software in the second application partition, including:

[0118] The upgrade server sends a second program update instruction to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software update process based on the second program update instruction, update the software in the second application partition, obtain the second updated software, and verify the second updated software.

[0119] It should be noted that the second program update instruction is used to instruct the program to perform an update.

[0120] In one embodiment of the present invention, the third instruction further includes a second program activation instruction, which causes the target dependent upgrade node to execute a second software upgrade process to activate the software in the second application partition, including:

[0121] The upgrade server sends a second program activation command to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software activation process based on the second program activation command. This process involves switching the software running area from the first application partition to the second application partition and restarting the system to complete the software upgrade.

[0122] It should be noted that the second program activation command is used to instruct the updated program to activate and restart, thereby completing the software upgrade, which is an upgrade that depends on the upgrade node.

[0123] Figure 8 This is a schematic block diagram illustrating the composition of a dependency upgrade node in an exemplary embodiment. The dependency upgrade node is a dual-application partition upgrade node, containing two identical application partitions. One application partition is called the current application partition, and the other is called the other application partition. The current application partition contains a software upgrade module, which includes an activation / restart submodule and an instruction receiving submodule. The software programs in the two application partitions can be the same or different software programs. If the software in the two application partitions is the same, the software program in the other application partition is upgraded during the upgrade process, so that the other application partition contains the target software (the software with the highest version number). If the two application partitions typically contain different software programs, the currently running software program in the running application partition, upon receiving the upgrade instruction, writes the software program to be upgraded (the target software) to the other application partition.

[0124] Please see Figure 9 , Figure 9 Here is a flowchart illustrating an upgrade process that depends on an upgrade node in an exemplary embodiment, such as... Figure 9 As shown, the upgrade process includes:

[0125] The S910 program runs in the current application partition. After the instruction receiving submodule in the software upgrade module receives the second program update instruction, it still runs in the current application partition.

[0126] The instruction receiving submodule in the software upgrade module running in the current application partition of the S920 receives the second program update instruction, erases and updates the program data in another application partition, until all software data is written and the software update is completed;

[0127] After completing the software update, S930 receives a second program activation command, which causes the activation and restart submodule in the software upgrade module of the current application partition to verify the program data of the other application partition. If the verification is successful, the other application partition is activated.

[0128] The activation and restart submodule in the software upgrade module of the current application partition of the S940 allows the control node to enter another application partition and run the updated software after restarting.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0130] An upgrade server can refer to a controller that stores upgrade node software packages and sends upgrade commands.

[0131] An upgrade node is a controller that receives upgrade instructions and completes program upgrades, while an upgrade server can also be an upgrade node.

[0132] The software upgrade process involves the upgrade server sending program update instructions and activation / restart instructions to the upgrade node through the upgrade node's software upgrade channel. The upgrade node then performs the upgrade based on the corresponding instructions and software packages.

[0133] In this method, the nodes to be upgraded include dependent upgrade nodes and regular upgrade nodes. Dependent upgrade nodes are divided into a first application partition and a second application partition. The software in the first application partition is running, while the software in the second application partition is not running. The first stage of the upgrade process for dependent upgrade nodes is performed in the second application partition, while the software in the first application partition continues to run normally and its functionality remains intact. The upgrade process of all dependent regular upgrade nodes is unaffected. The second stage is executed only after all dependent regular upgrade nodes have completed their upgrades, thus completing the upgrade. Because the first stage of the upgrade process for dependent upgrade nodes in both application partitions occupies the majority of the upgrade time, and this first stage is performed concurrently with the upgrade processes of all dependent regular upgrade nodes, the overall upgrade time is significantly reduced, thereby improving the user experience.

[0134] like Figure 1As shown, upgrade nodes ECU-B, ECU-X1, and ECU-X2 rely on the power distribution function of upgrade node ECU-A. Therefore, upgrade node ECU-A needs to be upgraded after upgrade nodes ECU-B, ECU-X1, and ECU-X2 are completed. Upgrade node ECU-X1 relies on the upgrade communication channel routing function of upgrade node ECU-B. Therefore, upgrade node ECU-B needs to be upgraded after ECU-X1 is completed. Upgrade nodes ECU-A, ECU-B, ECU-X1, and ECU-X2 rely on the upgrade server function of upgrade node ECU-M. Therefore, upgrade node ECU-M needs to be upgraded after upgrade nodes ECU-A, ECU-B, ECU-X1, and ECU-X2 are completed. If the node upgrade task needs to upgrade nodes ECU-A, ECU-B, ECU-M, ECU-X1, and ECU-X2, then according to the dependency relationship, the parallel node upgrade task allocation is as follows: (1) Upgrade server ECU-M sends program update instructions and activation restart instructions to upgrade node ECU-X2. At the same time, upgrade server ECU-M sends program update instructions and activation restart instructions to upgrade nodes ECU-X1 and upgrade node ECU-B. Node ECU-B needs to be executed after ECU-X1 has completed the upgrade. The time required is the larger value of T(X1)+t(X1)+T(B)+t(B) and T(X2)+t(X2); (2) Upgrade server ECU-M sends program update instructions and activation restart instructions to upgrade node ECU-A. The upgrade time required is T(A)+t(A); (3) Upgrade server ECU-M sends program update instructions and activation restart instructions to upgrade node ECU-M. The upgrade time required is T(M)+t(M).

[0135] like Figure 10 As shown, Figure 10 The total upgrade time for existing parallel upgrade technologies that do not employ this invention is the sum of the larger of T(X1)+t(X1)+T(B)+t(B) and T(X2)+t(X2) and T(A)+t(A) and T(M)+t(M).

[0136] Please see Figure 11 , Figure 11 The diagram illustrates the total upgrade time using the existing parallel upgrade technology of the present invention as an exemplary embodiment. The upgrade server ECU-M sends program update instructions and activation restart instructions to all ordinary upgrade nodes ECU-X1 and ECU-X2 to complete the software upgrade of ordinary upgrade nodes ECU-X1 and ECU-X2. The time required is the larger value between T(X1)+t(X1) and T(X2)+t(X2).

[0137] Please see Figure 11When the upgrade server ECU-M sends program update instructions and activation restart instructions to all ordinary upgrade nodes ECU-X1 and ECU-X2, it also sends program update instructions to all dependent upgrade nodes. The time required is the larger of T(M), T(A), and T(B).

[0138] In summary, in the first stage, the time required for the update is the larger of T(X1)+t(X1), T(X2)+t(X2), T(M), T(A), and T(B).

[0139] Please see Figure 11 The upgrade server ECU-M sends a unified activation and restart command to all dependent upgrade nodes ECU-A, ECU-B, and ECU-M to complete the second stage of the software upgrade for all dependent upgrade nodes ECU-A, ECU-B, and ECU-M. The time required is the larger of t(A), t(B), and t(M).

[0140] In summary, the total upgrade time required to complete the upgrade of all nodes ECU-A, ECU-B, ECU-M, ECU-X1, and ECU-X2 is the sum of the largest value among T(X1)+t(X1), T(X2)+t(X2), T(M), T(A), and T(B) and the largest value among t(A), t(B), and t(M).

[0141] based on Figure 11 It is understood that the upgrade method of this invention can significantly reduce the total upgrade time. In this invention, the execution time of the program update instruction and the execution time of the activation / restart instruction for each node to be upgraded are shown in Table 1. As shown in Table 2, the total upgrade time without using the parallel upgrade method of this invention is 31.2 minutes, the total execution time of the upgrade task for each parallel node. As shown in Table 3, the total upgrade time using the parallel upgrade method of this invention is the sum of the time for parallel upgrades of all upgrade nodes and the activation / restart time of dependent upgrade nodes, which is 11.5 minutes.

[0142] Table 1 Upgrade and restart times for each upgrade node

[0143] Upgrade Node Program update command execution time (minutes) Activation restart command execution time (minutes) ECU-A 10 0.5 ECU-B 5 0.1 ECU-M 11 0.5 ECU-X1 3 0.1 ECU-X2 3 0.1

[0144] Table 2 Total upgrade time without using the upgrade method of this invention

[0145]

[0146]

[0147] Table 3 Total upgrade time using the upgrade method of this invention

[0148]

[0149] As shown in Tables 1, 2, and 3, in this invention, the dependent upgrade nodes include a first application partition and a second application partition. The software in the first application partition is running, while the software in the second application partition is not running. The first stage of the dependent upgrade node upgrade process is performed in the second application partition, while the software in the first application partition runs normally and its functionality remains normal. The upgrade processes of all dependent ordinary upgrade nodes are unaffected. The second stage is executed after all dependent ordinary upgrade nodes have completed their upgrades, thus completing the upgrade. Because the first stage of the dual-application partition dependent upgrade node upgrade process occupies the majority of the upgrade time, and this first stage is performed concurrently with the upgrade processes of all dependent ordinary upgrade nodes, the total upgrade time is greatly reduced, thereby improving the user experience.

[0150] Please see Figure 12 , Figure 12 This is a schematic diagram of a parallel upgrade device with dependent nodes, an exemplary embodiment of this application. The upgrade device is applied to an upgrade server and includes:

[0151] The instruction generation module 1201 is used to generate a node upgrade instruction carrying a node upgrade task. The node upgrade instruction is used to instruct a node to upgrade. The node includes a dependent upgrade node and a normal upgrade node for upgrading. The upgrade of the normal upgrade node depends on the dependent upgrade node. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries a target dependent upgrade node and a target normal upgrade node to be upgraded.

[0152] The first sending module 1202 is used to send a first instruction to the target ordinary upgrade node when it receives a return instruction from the node to be upgraded in response to the node upgrade instruction, so that the target ordinary upgrade node executes a first software upgrade process to upgrade the software running therein, so as to complete the upgrade of the target ordinary upgrade node.

[0153] The second sending module 1203 is used to send a second instruction to the target dependency upgrade node when sending the first instruction, so that the target dependency upgrade node executes the software update process to update the software in the second application partition and obtain the updated software.

[0154] The third sending module 1204 is used to send a third instruction to the target dependent node after the target ordinary upgrade node has completed the software upgrade process and the target dependent upgrade node has completed the software update process, so that the target dependent upgrade node executes the second software upgrade process to upgrade the update software in the second application partition, and switches the software running area from the first application partition to the second application partition, so that the upgraded update software runs in the second application partition to complete the upgrade of the target dependent upgrade node.

[0155] It should be noted that the upgrade device and the upgrade method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the upgrade device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0156] In one embodiment, this application provides a parallel upgrade method for nodes with dependency relationships, applied to nodes, the upgrade method comprising:

[0157] Step S1301: Receive a node upgrade instruction sent by the upgrade server; the node upgrade instruction carries a node upgrade task instruction, the node upgrade instruction is used to instruct the node to be upgraded to perform an upgrade, the node to be upgraded includes: dependent upgrade nodes and ordinary upgrade nodes to be upgraded, the upgrade of the ordinary upgrade node depends on the dependent upgrade nodes; the dependent upgrade nodes include a first application partition and a second application partition with software, and the node upgrade task carries the target dependent upgrade node and the target ordinary upgrade node to be upgraded;

[0158] Step S1302: Respond to the node upgrade instruction by generating a return instruction and sending the return instruction to the upgrade server;

[0159] Step S1303: Receive the first instruction generated by the upgrade server in response to the return instruction through the ordinary upgrade node, and execute the first software upgrade process according to the first instruction to update and activate the software in the application partition of the ordinary upgrade node, so as to complete the upgrade of the target ordinary upgrade node;

[0160] Step S1304: Receive the second instruction generated by the upgrade server in response to the return instruction through the target dependent node, and update the software in the second application partition according to the second software upgrade process of the second instruction to obtain the updated software; wherein, the second instruction and the first instruction are received simultaneously.

[0161] Step S1305: The target dependent node receives a third instruction sent by the upgrade server and executes a second software upgrade process according to the third instruction to activate the software in the second application partition, switch the software running area from the first application partition to the second application partition, and restart the system to complete the upgrade of the target dependent upgrade node; wherein, the third instruction is sent after the target ordinary upgrade node completes the software upgrade and after the target dependent node completes the software update;

[0162] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0163] In one exemplary embodiment, such as Figure 13 As shown, Figure 13 A parallel upgrade apparatus with dependent nodes is provided, the upgrade apparatus being applied to nodes, comprising:

[0164] The receiving module 1310 is used to receive a node upgrade instruction sent by the upgrade server; the node upgrade instruction carries a node upgrade instruction for a node upgrade task, and the node upgrade instruction is used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a normal upgrade node to be upgraded, and the upgrade of the normal upgrade node depends on the dependent upgrade node; the dependent upgrade node includes a first application partition and a second application partition with software, and the node upgrade task carries the target dependent upgrade node and the target normal upgrade node to be upgraded;

[0165] The fourth sending module 1320 is used to generate a return instruction in response to the node upgrade instruction and send the return instruction to the upgrade server;

[0166] The first node upgrade module 1330 is used to receive a first instruction generated by the upgrade server in response to the return instruction through a normal upgrade node, and to execute a first software upgrade process according to the first instruction to update and activate the software in the application partition of the normal upgrade node, so as to complete the upgrade of the target normal upgrade node.

[0167] The second node upgrade module 1340 is used to receive a second instruction generated by the upgrade server in response to the return instruction through the target dependent node, and to execute a software upgrade process according to the second instruction to update the software in the second application partition to obtain updated software; wherein, the second instruction and the first instruction are received simultaneously.

[0168] The third node upgrade module 1350 is used to receive a third instruction sent by the upgrade server through the target dependent node, and to execute a second software upgrade process according to the third instruction to activate the software in the second application partition. This is used to switch the software running area from the first application partition to the second application partition, so that the upgraded updated software runs in the second application partition, thereby completing the upgrade of the target dependent upgrade node. The third instruction is sent after the target ordinary upgrade node has completed the software upgrade process and the target dependent upgrade node has completed the software update process.

[0169] It should be noted that the upgrade device and the upgrade method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the upgrade device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0170] Figure 14 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0171] like Figure 14 As shown, the computer system 1400 includes a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1402 or programs loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1403. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. An Input / Output (I / O) interface 1405 is also connected to bus 1404.

[0172] The following components are connected to I / O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to I / O interface 1405 as needed. Removable media 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1410 as needed so that computer programs read from them can be installed into storage section 1408 as needed.

[0173] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1409, and / or installed from removable medium 1411. When the computer program is executed by central processing unit (CPU) 1401, it performs various functions defined in the system of this application.

[0174] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0176] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0177] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the upgrade method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0178] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the upgrade methods provided in the various embodiments described above.

[0179] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method of parallel upgrade with dependency nodes, characterized by, Applied to an upgrade server, the method includes: A node upgrade instruction carrying a node upgrade task is generated. The node upgrade instruction is used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes a dependent upgrade node and a normal upgrade node. The dependency relationship means that the upgrade of the normal upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition with software. The node upgrade task carries the target dependent upgrade node and the target normal upgrade node to be upgraded. The software in the first application partition is in a running state, and the software in the second application partition is in a non-running state. Upon receiving a return instruction from the node to be upgraded in response to the node upgrade instruction, a first instruction is sent to the target ordinary upgrade node, causing the target ordinary upgrade node to execute a first software upgrade process to update and activate the software in the application partition, thereby completing the upgrade of the target ordinary upgrade node; while sending the first instruction, a second instruction is sent to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software upgrade process to update the software in the second application partition, thereby obtaining the updated software; after the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, a third instruction is sent to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software upgrade process to activate the software in the second application partition, thereby completing the upgrade of the target dependent upgrade node.

2. The parallel upgrade method with dependency nodes according to claim 1, wherein, The first instruction includes a first program update instruction and a first program activation instruction, causing the target ordinary upgrade node to execute a first software upgrade process to update and activate the software in the application partition, including: The upgrade server sends a first program update instruction to the target ordinary upgrade node, causing the target ordinary upgrade node to execute a first software update process based on the first program update instruction, obtain the first updated software, and verify the first updated software. After verification, the upgrade server sends a first program activation command to the target ordinary upgrade node, causing the target ordinary upgrade node to execute the first software activation process based on the first program activation command, and to perform an activation restart process on the first updated software, that is, to restart the system and complete the software upgrade.

3. The parallel upgrade method with dependent nodes according to claim 2, characterized in that, The second instruction includes a second program update instruction, which causes the target dependency upgrade node to execute a second software upgrade process to update the software in the second application partition, including: The upgrade server sends a second program update instruction to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software update process based on the second program update instruction, update the software in the second application partition, obtain the second updated software, and verify the second updated software.

4. The parallel upgrade method with dependent nodes according to claim 3, characterized in that, The third instruction also includes a second program activation instruction, which causes the target dependency upgrade node to execute a second software upgrade process to activate the software in the second application partition, including: The upgrade server sends a second program activation command to the target dependent upgrade node, causing the target dependent upgrade node to execute a second software activation process based on the second program activation command. This process involves switching the software running area from the first application partition to the second application partition and restarting the system to complete the software upgrade.

5. The parallel upgrade method with dependent nodes according to claim 1, characterized in that, The generation of node upgrade instructions carrying node upgrade tasks includes: Get the local version number of the software running in the node and the corresponding latest version number of the software; The latest version number is compared with the local version number. If the latest version number is higher than the local version number, the node is determined to be a node to be upgraded. Node upgrade tasks are generated based on the nodes to be upgraded, and a list of node upgrade tasks is formed; wherein, each node to be upgraded corresponds to one node upgrade task; The list of node upgrade tasks is embedded into the node upgrade command.

6. The parallel upgrade method with dependent nodes according to claim 5, characterized in that, The step of generating a node upgrade task based on the node to be upgraded further includes: Configure a task identifier for each node upgrade task and add the task identifier to the node upgrade task list.

7. The parallel upgrade method with dependent nodes according to claim 5, characterized in that, The step of generating a node upgrade task based on the node to be upgraded further includes: The nodes to be upgraded are grouped according to a pre-defined dependency list; All ordinary upgrade nodes are assigned to the same group, and the nodes to be upgraded that have a dependency relationship with the ordinary upgrade nodes are assigned to the same group. The remaining nodes to be upgraded are divided into different groups according to their dependencies. When upgrading nodes, all nodes in the same group are upgraded simultaneously, and the upgrades are completed sequentially according to the group order.

8. A parallel upgrade method with dependent nodes, characterized in that, Applied to nodes, the method includes: The system receives a node upgrade instruction sent by an upgrade server. This instruction carries a node upgrade task and is used to instruct the node to be upgraded. The node to be upgraded includes both dependent upgrade nodes and regular upgrade nodes. The dependency relationship indicates that the upgrade of the regular upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition containing software. The node upgrade task carries the target dependent upgrade node and the target regular upgrade node to be upgraded. The software in the first application partition is running, and the software in the second application partition is not running. The system generates a return instruction in response to the node upgrade instruction and sends the return instruction to the upgrade server. The ordinary upgrade node receives a first instruction generated by the response of the upgrade server to the return instruction, and executes a first software update process and a first software activation process according to the first instruction to upgrade the software running in the ordinary upgrade node, so as to complete the upgrade of the target ordinary upgrade node. The target dependent node receives a second instruction generated by the response of the upgrade server to the return instruction, and executes a second software update process according to the second instruction to update the software in the second application partition to obtain the second updated software, and verifies the second updated software; wherein, the second instruction and the first instruction are received simultaneously. The target dependent node receives a third instruction sent by the upgrade server and executes a second software activation process according to the third instruction. This process involves switching the software running area from the first application partition to the second application partition and restarting the system to complete the software upgrade of the dependent upgrade node. The third instruction is sent after the target ordinary upgrade node completes the software upgrade and after the target dependent node completes the software update.

9. A parallel upgrade device with dependent nodes, characterized in that, The device, used for upgrading servers, includes: The instruction generation module is used to generate node upgrade instructions carrying node upgrade tasks. These instructions instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes both dependent upgrade nodes and regular upgrade nodes. The dependency relationship indicates that the upgrade of the regular upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition containing software. The node upgrade task carries the target dependent upgrade node and the target regular upgrade node to be upgraded. The software in the first application partition is in a running state, while the software in the second application partition is in a non-running state. The first instruction sending module is used to send a first instruction to the target ordinary upgrade node when it receives a return instruction from the node to be upgraded in response to the node upgrade instruction, so that the target ordinary upgrade node executes the first software upgrade process to update and activate the software in the application partition, so as to complete the upgrade of the target ordinary upgrade node. The second instruction sending module is used to send a second instruction to the target dependency upgrade node when sending the first instruction, so that the target dependency upgrade node executes the second software upgrade process to update the software in the second application partition and obtain the updated software. The third instruction sending module is used to send a third instruction to the target dependent node after the target ordinary upgrade node completes the software upgrade and the target dependent node completes the software update, so as to enable the target dependent upgrade node to execute the second software upgrade process to activate the software in the second application partition, thereby completing the upgrade of the target dependent upgrade node.

10. A parallel upgrade device with dependent nodes, characterized in that, Applied to a node, the device includes: A receiving module is used to receive node upgrade instructions sent by an upgrade server. The node upgrade instructions carry node upgrade task instructions and are used to instruct the node to be upgraded to perform an upgrade. The node to be upgraded includes both dependent upgrade nodes and ordinary upgrade nodes. The dependency relationship means that the upgrade of the ordinary upgrade node is performed when the dependent upgrade node is functioning normally. The dependent upgrade node includes a first application partition and a second application partition containing software. The node upgrade task carries the target dependent upgrade node and the target ordinary upgrade node to be upgraded. The software in the first application partition is in a running state, and the software in the second application partition is in a non-running state. The fourth sending module is used to generate a return instruction in response to the node upgrade instruction and send the return instruction to the upgrade server; The first node upgrade module is used to receive a first instruction generated by the upgrade server in response to the return instruction through a normal upgrade node, and execute a first software upgrade process according to the first instruction to update and activate the software in the application partition of the normal upgrade node, so as to complete the upgrade of the target normal upgrade node. The second node upgrade module is used to receive a second instruction generated by the upgrade server in response to the return instruction through the target dependent node, and execute a second software update process according to the second instruction to update the software in the second application partition to obtain the second updated software, and verify the second updated software; wherein, the second instruction and the first instruction are received simultaneously. The third node upgrade module is used to receive a third instruction sent by the upgrade server through the target dependent node, and execute a second software activation process according to the third instruction. This process involves switching the software running area from the first application partition to the second application partition and restarting the system to complete the software upgrade of the dependent upgrade node. The third instruction is sent after the target ordinary upgrade node completes the software upgrade and after the target dependent node completes the software update.

11. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the electronic device to implement the upgrade method as described in any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the upgrade method as described in any one of claims 1 to 8.

13. A computer program product, characterized in that, It includes a computer program carried on a computer-readable medium, the computer program comprising a computer program for performing the upgrade method as described in any one of claims 1 to 8.

Images