Upgrading method, master node, slave node, storage medium and program product

Abstract

The invention discloses an upgrading method, a master node, slave nodes and a storage medium, and the method comprises the steps: obtaining an upgrading file based on an upgrading command issued by a server, and polling and sending an upgrading start command to at least one slave node; receiving a first reply message sent by at least one slave node, and determining a first sending end sliding window according to the first reply message; broadcasting a first data packet of the upgrading file to at least one slave node based on the first sending end sliding window; receiving a second reply message sent by at least one slave node, and determining a second sending end sliding window according to the second reply message; and broadcasting a second data packet of the upgrade file to at least one slave node based on the second sending end sliding window until the upgrade file is sent. Therefore, the master node not only can perform concurrent upgrading on the at least one slave node, shorten the upgrading time and improve the upgrading efficiency, but also can improve the stability and the reliability of the upgrading process by adopting a sliding window mechanism.

Description

Technical Field

[0001] This application relates to the field of power energy storage technology, and in particular to an upgrade method, a master node, a slave node, and a storage medium. Background Technology

[0002] In the field of power energy storage, systems use Controller Area Network (CAN) to connect various devices for communication, enabling data exchange and data sharing between devices.

[0003] Currently, when upgrading these devices, the program is usually upgraded one-to-one between the master node and the slave node. When there are many devices in the CAN network that need to be upgraded, the device response delay and the total upgrade time will increase significantly due to the limitation of bus bandwidth, resulting in low upgrade efficiency. Summary of the Invention

[0004] This application provides an upgrade method, a master node, a slave node, and a storage medium. The master node can not only perform concurrent upgrades on at least one slave node, shortening the upgrade time and improving the upgrade efficiency, but also improves the stability and reliability of the upgrade process by adopting a sliding window mechanism.

[0005] The technical solution of this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide an upgrade method applied to a master node, the method comprising:

[0007] Based on the upgrade command issued by the server, obtain the upgrade file and send an upgrade start command to at least one slave node in a polling manner;

[0008] Receive at least one first reply message from a slave node, and determine a first sending end sliding window based on the first reply message;

[0009] A first data packet of an upgrade file is broadcast to at least one slave node based on a first sending end sliding window; a second reply message is received from at least one slave node, and a second sending end sliding window is determined based on the second reply message;

[0010] The second data packet of the upgrade file is broadcast to at least one slave node based on the sliding window of the second sender until the upgrade file is sent.

[0011] Using the aforementioned technical means, the master node determines a first sending sliding window based on a first reply message sent by at least one slave node, and broadcasts a first data packet to at least one slave node based on the first sending sliding window. It then determines a second sending sliding window based on a second reply message, and broadcasts a second data packet to at least one slave node based on the second sending sliding window, until the upgrade file transmission is complete. In this way, the master node transmits upgrade file data packets to at least one slave node via broadcast. This concurrent upgrade method ensures that the upgrade speed is not affected by the number of slave nodes, significantly reducing data transmission time and response latency, shortening upgrade time, and improving upgrade efficiency. Furthermore, the master node can calculate the sending sliding window based on the reply messages from the slave nodes, thereby dynamically adjusting the sending sliding window to fully utilize bus bandwidth. Moreover, the sliding window mechanism also prevents upgrade data file loss or accumulation, further improving upgrade efficiency.

[0012] In some embodiments, determining a first sending end sliding window based on a first reply message includes: determining a first receiving end sliding window corresponding to each of at least one slave node based on a first reply message sent by at least one slave node, and determining sending end communication parameters; determining a minimum value of the receiving end sliding window based on the first receiving end sliding window corresponding to each of at least one slave node; and determining a first sending end sliding window based on the minimum value of the receiving end sliding window and the sending end communication parameters.

[0013] Using the aforementioned technical means, the master node can determine the first sending sliding window based on the minimum value of the receiving sliding window in the corresponding receiving sliding window of at least one slave node and the sending communication parameters. In this way, the determination of the sending sliding window not only takes into account the processing capabilities of all slave nodes but also considers the sending capabilities of the master node. This avoids data packet accumulation and loss due to insufficient processing capabilities of slave nodes, and also avoids wasting the processing capabilities of slave nodes, maximizing the utilization of bus bandwidth and improving upgrade efficiency.

[0014] In some embodiments, determining the second sending end sliding window based on the second reply message includes: determining the second receiving end sliding window corresponding to each of the at least one slave node based on the second reply message sent by the at least one slave node, and updating the sending end communication parameters; updating the minimum value of the receiving end sliding window based on the second receiving end sliding window corresponding to each of the at least one slave node; and determining the second sending end sliding window based on the updated minimum value of the receiving end sliding window and the updated sending end communication parameters.

[0015] Using the aforementioned techniques, before each data packet of the broadcast upgrade file, the master node dynamically adjusts the size of the sending end's sliding window based on the updated minimum value of the receiving end's sliding window and the updated sending end's communication parameters. This fully utilizes bus bandwidth and system resources, improving upgrade efficiency.

[0016] In some embodiments, after broadcasting the first data packet of the upgrade file to at least one slave node based on the first sending end sliding window, the method further includes: obtaining the number of sent frames of the first data packet; determining the number of received frames corresponding to each of the at least one slave node according to the second reply message; when the number of received frames corresponding to each of the at least one slave node is consistent with the number of sent frames, performing the step of determining the second sending end sliding window according to the second reply message; when no second reply message sent by the first slave node is received within a first preset time period, or when the number of received frames of the first slave node is inconsistent with the number of sent frames, determining that the upgrade has failed and saving the upgrade failure information, the upgrade failure information including the reason for failure and the node number of the first slave node; wherein, the first slave node is one of the at least one slave node.

[0017] Through the aforementioned technical means, after broadcasting the first data packet, the master node only continues to broadcast the second data packet to at least one slave node based on the second sending end sliding window, provided that the number of frames sent matches the number of frames received by each slave node. If the master node does not receive a second reply message from the first slave node within the first preset time period, or if the number of frames received by the first slave node does not match the number of frames sent, the master node determines that the upgrade has failed. In this way, the master node can promptly confirm the data reception status of each slave node during the upgrade process and stop the upgrade in a timely manner when an anomaly is detected, thereby improving the reliability of the upgrade process.

[0018] In some embodiments, after the upgrade file is sent, the method further includes: broadcasting an upgrade end command to at least one slave node; if no third reply message is received from the second slave node within a second preset time period, determining that the upgrade has failed and saving the upgrade failure information; wherein the upgrade failure information includes the reason for failure and the node number of the second slave node; wherein the second slave node is one of at least one slave node.

[0019] Using the aforementioned technical methods, after the upgrade files are sent, the master node sends an upgrade end command to at least one slave node, and determines that the upgrade has failed if it does not receive a fourth reply message from the second slave node. In this way, the master node confirms whether each slave node has successfully upgraded via the fourth reply message after the upgrade, improving the reliability of the upgrade process.

[0020] Secondly, embodiments of this application provide an upgrade method applied to a slave node, the method comprising:

[0021] Receive the upgrade start command sent by the master node;

[0022] Determine the first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node;

[0023] Receive the first data packet of the upgrade file broadcast by the master node;

[0024] Determine the second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node;

[0025] Receive the second data packet of the upgrade file broadcast by the master node until all upgrade files have been received.

[0026] Through the aforementioned technical means, when a slave node receives an upgrade start command, it determines a first receiving end sliding window based on the first receiving end communication parameters, generates a first reply message, and sends it to the master node. Upon receiving the first data packet broadcast by the master node, it determines a second receiving end sliding window based on the second communication parameters, generates a second reply message, and sends it to the master node. In this way, the slave node dynamically adjusts the receiving end sliding window, fully utilizing the bus bandwidth to receive data packets and processing them promptly, avoiding excessive data packet loss or accumulation, thereby improving upgrade efficiency.

[0027] In some embodiments, determining the first receiving end sliding window includes: after receiving an upgrade start command sent by the master node, determining the processing capability parameters of the slave node and determining the receiving end communication parameters; and determining the first receiving end sliding window based on the processing capability parameters of the slave node and the receiving end communication parameters.

[0028] Using the aforementioned technical methods, the slave node can determine the first receiving end sliding window based on its processing capability parameters and the receiving end's communication parameters. This avoids data packet accumulation and loss due to insufficient processing capability of the slave node, prevents waste of slave node processing capacity, maximizes the utilization of bus bandwidth, and improves upgrade efficiency.

[0029] In some embodiments, determining the second receiver sliding window includes: after receiving the first data packet of the upgrade file broadcast by the master node, updating the processing capability parameters of the slave node and the receiver communication parameters; and determining the second receiver sliding window based on the updated processing capability parameters of the slave node and the updated receiver communication parameters.

[0030] Using the aforementioned technical methods, the slave node determines the second receiving end sliding window based on the updated slave node processing capability parameters and the updated receiving end communication parameters. This fully utilizes the slave node's processing capabilities, maximizes data transmission volume, and improves upgrade efficiency.

[0031] In some embodiments, after receiving the first data packet of the upgrade file broadcast by the master node, the method further includes: obtaining the number of received frames of the first data packet; generating a second reply message based on the number of received frames and a second receiving end sliding window; and sending the second reply message to the master node.

[0032] Using the aforementioned technical means, after receiving the first data packet of the upgrade file, the slave node generates a second reply message based on the recorded number of received frames for the first data packet and sends the second reply message back to the master node. In this way, the slave node can promptly report the number of received frames to the master node, thereby stopping the upgrade in a timely manner if a frame count error occurs during the transmission of the upgrade file, improving the efficiency and reliability of the upgrade process.

[0033] In some embodiments, the method further includes: receiving an upgrade end command sent by the master node; wherein the upgrade end command is used to indicate that all upgrade files have been received; upgrading the slave node according to the upgrade files and determining the upgrade result; generating a third reply message according to the upgrade result and sending the third reply message to the master node.

[0034] Using the aforementioned technical methods, the master node sends an upgrade completion command to the slave nodes after the upgrade is finished. The slave nodes then send a third reply message to the master node based on the execution result of the upgrade files. This third reply message allows the slave nodes to promptly inform the master node whether the upgrade was successful, thus improving the reliability of the upgrade process.

[0035] In some embodiments, after receiving an upgrade start command sent by the master node, the method further includes: after receiving the upgrade start command sent by the master node, shutting down the second task module in the slave node and controlling the slave node's working mode to switch from task mode to upgrade mode; or, if no information is received from the master node within a third preset time period, controlling the slave node's working mode to switch from upgrade mode to task mode and starting the second task module in the slave node.

[0036] Using the aforementioned technical means, after a slave node switches to upgrade mode, the operation of the second task module is paused. If no content is received from the master node within a third preset time period, a timeout mechanism is triggered, and the node switches from upgrade mode to task mode. In this way, the slave node can focus on receiving and processing data packets, improving the stability and efficiency of the upgrade process, avoiding data transmission conflicts or resource contention, and preventing the slave node from waiting indefinitely, thus increasing the flexibility of the upgrade process.

[0037] Thirdly, embodiments of this application provide a master node, including:

[0038] The first sending unit is configured to obtain the upgrade file based on the upgrade command issued by the server, and send an upgrade start command to at least one slave node in a polling manner;

[0039] The first receiving unit is configured to receive a first reply message sent by at least one slave node, and determine a first sending end sliding window based on the first reply message;

[0040] The first sending unit is further configured to broadcast a first data packet of an upgrade file to at least one slave node based on a first sending end sliding window;

[0041] The first receiving unit is further configured to receive a second reply message sent by at least one slave node, and determine a second sending end sliding window based on the second reply message;

[0042] The first sending unit is further configured to broadcast a second data packet of the upgrade file to at least one slave node based on a sliding window of the second sending end, until the upgrade file is sent.

[0043] Fourthly, embodiments of this application provide a master node, which includes a first memory and a first processor, wherein:

[0044] A first memory for storing computer programs that can run on a first processor;

[0045] A first processor is configured to execute a computer program in a first memory to implement the steps of the upgrade method as described in any one of the first aspects.

[0046] Fifthly, embodiments of this application provide a slave node, including:

[0047] The second receiving unit is configured to receive the upgrade start command sent by the master node;

[0048] The second sending unit is configured to determine the first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node;

[0049] The second receiving unit is also configured to receive the first data packet of the upgrade file broadcast by the master node;

[0050] The second sending unit is further configured to determine the second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node;

[0051] The second receiving unit is also configured to receive the second data packet of the upgrade file broadcast by the master node until all upgrade files have been received.

[0052] Sixthly, embodiments of this application provide a slave node, wherein the master node includes a second memory and a second processor, wherein:

[0053] The second memory is used to store computer programs that can run on the second processor;

[0054] The second processor is configured to execute a computer program in the second memory to implement the steps of the upgrade method as described in any one of the second aspects.

[0055] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a first processor, implements the steps of the upgrade method as described in any one of the first aspects, or when executed by a second processor, implements the steps of the upgrade method as described in any one of the second aspects.

[0056] In a seventh aspect, embodiments of this application provide a computer program product having a computer program or instructions stored thereon, characterized in that the computer program or instructions, when executed by a first processor, implement the steps of the upgrade method as described in any one of the first aspects, or when executed by a second processor, implement the steps of the upgrade method as described in any one of the second aspects.

[0057] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0058] Figure 1 This application provides a schematic diagram of the architecture of an upgrade system.

[0059] Figure 2 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 1 ;

[0060] Figure 3 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 2 ;

[0061] Figure 4 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 3 ;

[0062] Figure 5 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 4 ;

[0063] Figure 6 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 5 ;

[0064] Figure 7 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 6 ;

[0065] Figure 8 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 7 ;

[0066] Figure 9 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 8 ;

[0067] Figure 10 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 9 ;

[0068] Figure 11 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 ;

[0069] Figure 12 A detailed flowchart illustrating an upgrade method provided in an embodiment of this application;

[0070] Figure 13 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 one;

[0071] Figure 14 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 two;

[0072] Figure 15 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 three;

[0073] Figure 16 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 Four;

[0074] Figure 17 A schematic diagram of the composition structure of a master node provided in an embodiment of this application;

[0075] Figure 18 A schematic diagram of the hardware structure of a master node provided in an embodiment of this application;

[0076] Figure 19 A schematic diagram of the composition structure of a slave node provided in an embodiment of this application;

[0077] Figure 20 This is a schematic diagram of the hardware structure of a slave node provided in an embodiment of this application. Detailed Implementation

[0078] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.

[0079] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0080] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0081] It should also be noted that the terms "first, second, and third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific order of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0082] Furthermore, the reference to "embodiment" herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0083] The following is a description of the relevant technologies used in this application.

[0084] New energy batteries are being used more and more widely in daily life and industry. For example, new energy vehicles equipped with batteries are already widely used. In addition, batteries are being used more and more in the field of energy storage.

[0085] Currently, new energy batteries are being used more and more widely in daily life and industry. They are not only used in energy storage systems for hydropower, thermal power, wind power, and solar power plants, but also extensively in electric vehicles such as electric bicycles, electric motorcycles, and electric cars, as well as in aerospace and other fields. With the continuous expansion of the application areas of power batteries, the market demand is also constantly increasing.

[0086] In this embodiment, the battery can be a single battery cell. A single battery cell refers to a basic unit capable of converting chemical energy into electrical energy, and can be used to manufacture battery modules or battery packs to supply power to electrical devices. A single battery cell can be a rechargeable battery, which is a battery cell that can be recharged after discharge to reactivate its active materials and continue to be used. A single battery cell can be a lithium-ion battery, sodium-ion battery, sodium-lithium-ion battery, lithium metal battery, sodium metal battery, lithium-sulfur battery, magnesium-ion battery, nickel-metal hydride battery, nickel-cadmium battery, lead-acid battery, etc., and this embodiment is not limited to these types.

[0087] In this embodiment, the battery may also be a single physical module comprising one or more battery cells to provide higher voltage and capacity. When there are multiple battery cells, the multiple battery cells are connected in series, parallel, or mixed via a busbar.

[0088] A bus is a common communication connection line for transmitting information between devices in a system, and it can consist of multiple signal lines. Buses can be classified according to the type of information transmitted, the transmission speed, and the direction of information transmission. Based on transmission speed, buses can be divided into low-speed buses and high-speed buses. High-speed buses and low-speed buses differ in transmission rate, application scenarios, number of devices, and anti-interference capabilities. Low-speed buses refer to buses with communication rates below 125Kbps, such as the CAN bus.

[0089] In various systems of the power energy storage field, a large number of devices are interconnected through low-speed buses. Normally, these devices are flashed with standard firmware programs in "factory mode". However, when there is an update requirement in the field later, the devices need to be upgraded offline through the low-speed bus.

[0090] In related technologies, when upgrading these devices, a polling method is typically used to upgrade each device on the low-speed bus. As the number of devices on the bus increases, the device response latency and the total upgrade time increase significantly due to bus bandwidth limitations. Furthermore, in these technologies, the upgrade file is sliced ​​and unpacked during the upgrade process and sent to the devices on the low-speed bus at fixed intervals. This method cannot dynamically adjust based on the actual communication conditions of the bus and the processing capacity of the receiver, resulting in low transmission efficiency.

[0091] Based on this, embodiments of this application provide an upgrade method, a master node, slave nodes, and a storage medium. The master node determines a first sending end sliding window based on a first reply message sent by at least one slave node, and broadcasts a first data packet to at least one slave node based on the first sending end sliding window. It then determines a second sending end sliding window based on a second reply message, and broadcasts a second data packet to at least one slave node based on the second sending end sliding window, until the upgrade file is sent completely. In this way, the master node transmits upgrade file data packets to at least one slave node via broadcast. This concurrent upgrade method ensures that the upgrade speed is not affected by the number of slave nodes, significantly reducing data transmission time and response latency, shortening the upgrade time, and improving upgrade efficiency. Moreover, due to the use of the sliding window mechanism, the master node dynamically adjusts the sending end sliding window for sending data, which can fully utilize the bus bandwidth, avoid the loss or accumulation of upgrade data files, and improve upgrade efficiency.

[0092] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0093] Figure 1 This is a schematic diagram of the architecture of an upgrade system provided in an embodiment of this application. Figure 1 As shown, the upgrade system 10 includes a server 101, a master node 102 in the following embodiments, and at least one slave node in the following embodiments. The server 101 is communicatively connected to the master node 102, and the master node 102 is communicatively connected to at least one slave node; wherein:

[0094] Server 101 is used to send upgrade commands to master node 102.

[0095] The master node 102 is used to execute the upgrade method executed by the master node in the following embodiments, broadcasting data packets in the upgrade file to at least one slave node until the upgrade file broadcast is completed.

[0096] At least one slave node is configured to execute the upgrade method performed by the slave node in the following embodiments, receive an upgrade file, and perform an upgrade based on the upgrade file.

[0097] In this embodiment of the application, the upgrade system 10 includes a server 101, a master node 102 and at least one slave node, wherein the at least one slave node includes a first slave node 1031, a second slave node 1032, a third slave node 1033, ..., an Nth slave node 1034, where N is a positive integer greater than zero.

[0098] In this embodiment, the upgrade system 10 can be installed in the energy storage valve control and protection system. The server 101 includes upgrade tools, which can be devices with processing capabilities such as cloud platforms, computer equipment, or host computer equipment. The server 101 also has an interactive interface, allowing staff to perform upgrade operations, monitor the upgrade process, and select the slave node to be upgraded from at least one slave node. The server 101 stores upgrade files for the upgrade process. When a staff member begins the upgrade operation through the interactive interface, the server 101 packages the upgrade files into an upgrade command and sends it to the communication module 1023 in the master node 102 via a connection to the communication module 1023 in the master node 102.

[0099] In this embodiment, the master node 102 and at least one slave node are different boards, and each slave node is connected to the master node 102 via a bus. Preferably, the bus can be a low-speed bus. Due to the low transmission rate of the low-speed bus, the upgrade method provided in this embodiment can significantly improve transmission efficiency compared to the polling upgrade method. In some embodiments, the bus can also be a high-speed bus, but due to the high transmission rate of the high-speed bus, the upgrade method provided in this embodiment does not offer a significant gain in upgrade efficiency compared to the polling upgrade scheme. The master node 102 stores configuration information, including the type information corresponding to each slave node and the number of slave nodes connected to the master node 102. The master node 102 can determine whether the slave nodes belong to the same type based on the slave node type information. For example, if they belong to the same interface node type, generally, when the upgrade system performs an upgrade, slave nodes of the same type are upgraded concurrently. It is understood that... Figure 1 The first slave node 1031, the second slave node 1032, the third slave node 1033, ..., the Nth slave node 1034 shown may not belong to the same type of slave node.

[0100] As mentioned above, staff can control the execution of the upgrade process through server 101. Moreover, when upgrading the same type of slave nodes, staff can also view these slave nodes of the same type to be upgraded through the interactive interface of server 101, and select some or all of them by checking boxes to execute the upgrade.

[0101] like Figure 1 As shown, the master node 102 includes multiple software modules, such as the first task module 1021, the first upgrade management module 1022, and the communication module 1023. When the communication module 1023 receives the upgrade command sent by the server 101, it wakes up the first upgrade management module 1022, which is in a dormant state, so that the first upgrade management module 1022 can perform concurrent upgrade tasks on the same type of slave nodes on the low-speed bus.

[0102] In this embodiment, each slave node is also deployed with multiple software modules, such as a second task module and a second upgrade management module. The second upgrade management module is used to interact with the first upgrade management module 1022 of the master node 102. It is woken up when it receives the upgrade start command sent by the first upgrade management module 1022 of the master node 102, and performs upgrade operations on the slave node, including sending a receiving end sliding window to the master node 102, receiving the data packet of the upgrade file broadcast by the master node 102 according to the corresponding sending end sliding window, and performing the upgrade based on the upgrade file after receiving the upgrade file.

[0103] This application provides an upgrade system in which a master node broadcasts an upgrade file to at least one slave node based on an adjusted sending sliding window. Upon receiving the upgrade file, the slave node performs the upgrade. In this way, the master node transmits the upgrade file data packet to at least one slave node via broadcast, and the upgrade speed is not affected by the number of slave nodes. This not only significantly reduces data transmission time and response latency, but also fully utilizes bus bandwidth by dynamically adjusting the sending sliding window, preventing upgrade data file loss or accumulation, thereby improving upgrade efficiency.

[0104] Figure 2 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 1 .like Figure 2 As shown, this method can be applied to the master node in the aforementioned upgrade system, and the method may include the following steps:

[0105] S201: Based on the upgrade command issued by the server, obtain the upgrade file and send an upgrade start command to at least one slave node in a polling manner.

[0106] In this embodiment, the upgrade command can be an upgrade command issued by the server to the master node in the aforementioned upgrade system. The master node can parse the upgrade command and extract and decompress it to obtain information such as the upgrade file and the node number of the slave node to be upgraded.

[0107] Furthermore, the upgrade start command can be an upgrade command issued by the master node to at least one slave node. It can be understood that information sent by the master node on the low-speed bus can be received by all slave nodes, and the slave nodes need to identify the recipient of the command based on the slave node's node number in the command. Therefore, the master node can sequentially fill the slave node's node number obtained from the upgrade command into the upgrade command for marking, obtaining the upgrade start command corresponding to each slave node that needs to be upgraded, and then sequentially send these upgrade start commands to the bus, polling and sending upgrade start commands to the slave nodes that need to be upgraded.

[0108] S202, receive a first reply message sent by at least one slave node, and determine a first sending end sliding window based on the first reply message.

[0109] In this embodiment of the application, after the master node receives the first reply message from the slave node that needs to be upgraded to the upgrade start command, it parses the first reply message to obtain the node number of the slave node and the first receiving end sliding window corresponding to the slave node.

[0110] Furthermore, the master node can comprehensively determine the first sending sliding window based on factors such as the first receiving sliding window and its own sending capacity. The first sending sliding window can refer to the upper limit of the number of bits in a data packet sent by the master node in one transmission.

[0111] S203, broadcasting the first data packet of the upgrade file to at least one slave node based on the sliding window of the first sender.

[0112] In this embodiment, after the master node determines the first sending end sliding window, it can broadcast a first data packet to at least one slave node of the same type that needs to be upgraded at a preset time interval based on the first sending end sliding window. The first data packet includes multiple consecutive frames of upgrade data messages. It can be understood that the sum of the number of bits corresponding to the multiple frames of upgrade data messages should be less than or equal to the value of the first sending end sliding window.

[0113] It should be noted that the first data packet broadcast includes the node number of the slave node that needs to be upgraded, and the consecutive upgrade data packets in the first data packet may include a start upgrade data packet and an end upgrade data packet. The frame header of the start upgrade packet may include a file transfer command issued by the master node to inform the slave node of the start of the data transmission process. The received upgrade data packet includes a stop marker for this transmission to indicate the end of this transmission process, that is, the first data packet transmission is complete.

[0114] S204, receive a second reply message sent by at least one slave node, and determine a second sending end sliding window based on the second reply message.

[0115] Furthermore, the master node parses the second reply message sent by at least one slave node to determine the second sending end sliding window corresponding to the data packet for the next upgrade file transmission.

[0116] S205, broadcast the second data packet of the upgrade file to at least one slave node based on the sliding window of the second sender until the upgrade file is sent.

[0117] In this embodiment, after determining the second sending end sliding window, the master node can broadcast a second data packet to at least one slave node of the same type that needs to be upgraded at a preset time interval based on the second sending end sliding window. The second data packet includes multiple consecutive frames of upgrade data messages. It can be understood that the sum of the number of bits corresponding to the multiple frames of upgrade data messages should be less than or equal to the value of the second sending end sliding window.

[0118] It should be noted that after each broadcast of the upgrade file data packet, the master node adjusts the previous sending sliding window and, based on the adjusted sending sliding window, rebroadcasts the upgrade file data packet to at least one slave node. This process continues until the master node has sent all the data in the upgrade file to at least one slave node via data packets.

[0119] For example, after the master node broadcasts a second data packet including a file transfer command to at least one slave node based on a second sending end sliding window, it receives a third reply message from at least one slave node regarding the file transfer command in the second data packet. The master node parses the third reply message and can re-determine the corresponding third sending end sliding window based on the third receiving end sliding window sent by at least one slave node, the current status of the master node, network congestion, etc.

[0120] Furthermore, based on the newly determined third sending sliding window, the master node sequentially packages the remaining data in the upgrade file into a third data packet and broadcasts the third data packet again to at least one slave node. The third data packet may include multiple frames of upgrade data messages, and the total number of bits in the multiple frames is less than or equal to the second sending sliding window. After each data packet of the upgrade file is broadcast to at least one slave node, the process of re-determining a new sending sliding window based on the receiving sliding window responded by at least one slave node, and then sending the data packet of the current upgrade file based on the new sending sliding window, is repeated until all data in the upgrade file has been broadcast to the slave nodes that need to be upgraded.

[0121] It should also be noted that when the master node finishes broadcasting message information to at least one child node through the sliding window of the sending end based on this round of broadcast, it starts a timer. If it does not receive reply messages from all the child nodes within a certain period of time, it can start the timeout retransmission mechanism and resend the data to that node until the number of retransmissions reaches the preset number.

[0122] This application provides an upgrade method in which a master node determines a first sending sliding window based on a first reply message sent by at least one slave node, and broadcasts a first data packet to at least one slave node based on the first sending sliding window. The master node then determines a second sending sliding window based on a second reply message, and broadcasts a second data packet to at least one slave node based on the second sending sliding window, until the upgrade file is successfully sent. In this way, the master node transmits upgrade file data packets to at least one slave node via broadcast. This concurrent upgrade method ensures that the upgrade speed is not affected by the number of slave nodes, significantly reducing data transmission time and response latency, shortening the upgrade time, and improving upgrade efficiency. Furthermore, due to the sliding window mechanism, the master node dynamically adjusts the sending sliding window for data transmission, fully utilizing bus bandwidth and avoiding upgrade data file loss or accumulation, thereby improving upgrade efficiency.

[0123] In some embodiments, Figure 3 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 2 .like Figure 3 As shown, this method can be applied to any slave node in at least one of the slave nodes in the aforementioned upgrade system, and the method may include the following steps:

[0124] S301 receives the upgrade start command sent by the master node.

[0125] As mentioned earlier, a slave node can determine whether it is the receiving node of the upgrade start command based on the slave node's node number in the upgrade start command. Therefore, after receiving the upgrade start command, the slave node can parse the upgrade start command, obtain the slave node's node number and match it with its own node number. If the match is successful, it will wake up its own second upgrade management module to execute the upgrade; if the match fails, it will not respond.

[0126] S302, determine the first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node.

[0127] In this embodiment, the slave node can also determine the first receiving end sliding window based on its own processing capabilities and add the value of the first sliding window to the corresponding field in the first reply message. The value of the first receiving end sliding window can refer to the upper limit of the number of bits corresponding to the first data packet of the upgrade file that the slave node can receive and process at one time.

[0128] It should be noted that after receiving the upgrade start command from the master node, the slave node will reply with a first reply message. If the slave node is performing some important tasks that cannot be interrupted, it will directly reply with a first reply message indicating upgrade failure; otherwise, it will reply with the first reply message of the first receiving end's sliding window.

[0129] S303 receives the first data packet of the upgrade file broadcast by the master node.

[0130] As mentioned above, the master node can determine the first sending sliding window based on the first receiving sliding window, and broadcast data to at least one slave node according to the first sending sliding window. In this embodiment, the slave node can parse the first data packet, match its own node number with the node number of the slave node in the first data packet, and if the match is successful, parse and process the first data packet sent by the master node, obtain the file transfer command in it, and extract the data part of the first data packet, that is, part of the upgrade file data, and store it in its own buffer.

[0131] S304, determine the second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node.

[0132] In this embodiment, referring to the process of determining the generation of the first receiving end sliding window, the second receiving end sliding window can be determined according to the communication parameters of the second receiving end, and the second receiving end sliding window can be filled into the corresponding field in the second reply message and sent to the master node. The value of the second receiving end sliding window can refer to the upper limit of the number of bits corresponding to the second data packet of the upgrade file that the slave node can receive and process at one time.

[0133] S305 receives the second data packet of the upgrade file broadcast by the master node until the entire upgrade file has been received.

[0134] Furthermore, the slave node receives the second data packet from the master node, which includes multiple frames of upgrade data messages. After receiving multiple consecutive frames of upgrade data messages, the slave node can parse them, determine the third receiving end sliding window, generate a third reply message to respond to the file transfer command in the second data packet, and extract and temporarily store the data in the second data packet in the cache.

[0135] Thus, in this embodiment, after each data packet received from the master node, the slave node will re-determine the next receiving sliding window and add it to the "receiving sliding window" field of the reply message, generating a corresponding reply message and sending it to the master node. This process is repeated, continuously determining the next receiving sliding window and sending a reply message to the master node, until the master node has finished sending all the upgrade file data packets. The reply message sent by the slave node is used to reply to the file transfer command previously sent by the master node.

[0136] Thus, this application provides an upgrade method. When a slave node receives an upgrade start command, it determines a first receiving end sliding window based on first receiving end communication parameters, generates a first reply message, and sends it to the master node. Upon receiving a first data packet broadcast by the master node, it determines a second receiving end sliding window based on second communication parameters, generates a second reply message, and sends it to the master node. In this way, the slave node dynamically adjusts the receiving end sliding window, fully utilizing bus bandwidth to receive data packets and processing them promptly, avoiding excessive data packet loss or accumulation, thereby improving upgrade efficiency.

[0137] In yet another embodiment of this application, Figure 4 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 3 .like Figure 4 As shown, this method can be applied to the master node in the aforementioned upgrade system. For step S202 in the aforementioned embodiment, determining the first sending end sliding window based on the first reply message may include the following steps:

[0138] S401, based on the first reply message sent by at least one slave node, determine the first receiving end sliding window corresponding to each of the at least one slave node, and determine the sending end communication parameters.

[0139] In this embodiment of the application, after the master node receives the first reply message from all the slave nodes that need to be upgraded, it extracts the "receive sliding window" field of the first reply message and determines the first receiving end sliding window corresponding to at least one slave node.

[0140] In this embodiment of the application, the communication parameters of the sending end may include factors that can affect the sending of the first data packet by the master node, such as the degree of network congestion, its own sending capacity, and the processing capacity of the slave node, such as the minimum value of the receiving end sliding window, the current size of the sending end buffer, and the round-trip delay.

[0141] S402, determine the minimum value of the receiving end sliding window based on the first receiving end sliding window corresponding to each of the at least one slave node.

[0142] Furthermore, in order to ensure that all slave nodes can process upgrade data packets in a timely manner, the master node compares the first receiving end sliding window corresponding to at least one slave node and determines the minimum value in at least one receiving end sliding window.

[0143] S403, determine the first sliding window of the transmitter based on the minimum value of the sliding window of the receiver and the communication parameters of the transmitter.

[0144] The master node can determine the first sending end sliding window based on the minimum value of the sending end communication parameters corresponding to the minimum value of the receiving end sliding window, the minimum value of the receiving end sliding window, and other information, and broadcast the first data packet to at least one slave node using the first sending end sliding window.

[0145] This application provides an upgrade method in which the master node determines a first sending end sliding window based on the minimum value of the receiving end sliding window in the corresponding receiving end sliding window of at least one slave node and the sending end communication parameters. In this way, the determination of the sent end sliding window not only takes into account the processing capabilities of all slave nodes but also considers the sending capabilities of the master node. This avoids data packet accumulation and loss due to insufficient processing capabilities of slave nodes, and also avoids wasting the processing capabilities of slave nodes, maximizing the utilization of bus bandwidth and improving upgrade efficiency.

[0146] In some embodiments, Figure 5 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 4 .like Figure 5 As shown, this method can be applied to the master node in the aforementioned upgrade system. For step S204 above, determining the second sending end sliding window based on the second reply message may include the following steps:

[0147] S501, based on the second reply message sent by at least one slave node, determine the second receiving end sliding window corresponding to each of the at least one slave node, and update the sending end communication parameters.

[0148] In this embodiment of the application, referring to the foregoing embodiment, the master node can extract the "receive sliding window" field of the second reply message and determine the second receiving end sliding window corresponding to the slave node that sent the second reply message. Therefore, by parsing and extracting all the received second reply messages, the first receiving end sliding window corresponding to at least one slave node can be determined.

[0149] It should be noted that the master node's sending communication parameters may be different at different times. Therefore, before each broadcast upgrade data message, the master node needs to re-acquire the current sending communication parameters and update them.

[0150] S502, update the minimum value of the receiving end sliding window according to the second receiving end sliding window corresponding to at least one slave node.

[0151] Furthermore, the master node sequentially compares the second receiving end sliding windows corresponding to at least one slave node in this reception, and determines the minimum value among them as the minimum value of the updated receiving end sliding window.

[0152] S503, determine the second transmitting end sliding window based on the updated minimum value of the receiving end sliding window and the updated transmitting end communication parameters.

[0153] It should be noted that the master node can refer to the aforementioned process for determining the first sending end sliding window, and further determine the second sending end sliding window based on the updated sending end communication parameters and the minimum value of the previous receiving end sliding window. It can be understood that the sending end sliding window corresponding to the next broadcast can also be determined by referring to the above steps, and broadcast to at least one slave node using the next sending end sliding window until the upgrade file is sent.

[0154] This application provides an upgrade method in which the master node dynamically adjusts the size of the sending end sliding window before each broadcast of the upgrade file data packet, based on the updated minimum value of the receiving end sliding window and the updated sending end communication parameters. This fully utilizes bus bandwidth and system resources, improving upgrade efficiency.

[0155] In some embodiments, Figure 6 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 5 .like Figure 6 As shown, this method can be applied to any slave node in the aforementioned upgrade system. For step S302 above, determining the first receiving end sliding window may include the following steps:

[0156] S601, after receiving the upgrade start command sent by the master node, determines the processing capability parameters of the slave node and the communication parameters of the receiving end.

[0157] In this embodiment of the application, the processing capability parameter of the slave node can be a factor that affects the slave node's reception capability, such as the receiving capability of the receiving end, which affects the first data packet of the upgrade file. For example, it may include the slave node's processing capability, the size of the receiving buffer, etc.

[0158] In this embodiment of the application, the receiving end communication parameters may refer to factors such as the degree of network congestion that affect the first data packet received by the node from the upgrade file, such as bus round-trip delay.

[0159] S602, determine the first receiving end sliding window based on the processing capability parameters of the slave node and the communication parameters of the receiving end.

[0160] After the slave node successfully matches and wakes up the second upgrade management module, the second upgrade management module calculates the first receiving end sliding window based on the minimum value among the slave node's processing capability parameters and the receiving end communication parameters. The value of the first receiving end sliding window is then filled into the "receiving sliding window" field in the first reply message, generating a reply message for the upgrade start command and sending it to the master node.

[0161] In some embodiments, Figure 7 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 6 .like Figure 7 As shown, this method can be applied to any slave node in the aforementioned upgrade system. For step S304 above, determining the second receiving end sliding window may include the following steps:

[0162] After receiving the first data packet of the upgrade file broadcast by the master node, S701 updates the processing capability parameters of the slave node and the communication parameters of the receiving end.

[0163] It should be noted that after the slave node receives the first data packet broadcast by the master node, the slave node's processing capability parameters and receiver communication parameters may change compared to the last time the receiver sliding window was determined. Therefore, after receiving the first data packet, the slave node re-acquires the slave node's processing capability parameters and receiver communication parameters.

[0164] S702, determine the second receiver sliding window based on the updated slave node's processing capability parameters and the updated receiver communication parameters.

[0165] Furthermore, referring to the method for determining the first receiving end sliding window in the above embodiments, the slave node can determine the second receiving end sliding window based on the minimum value between the slave node's processing capability parameters and the updated receiving end communication parameters.

[0166] Each time a slave node determines the receiving end sliding window, it will re-acquire the current processing capability parameters and receiving end communication parameters, and recalculate and determine the receiving end sliding window based on these parameters. This process of re-determining the receiving end sliding window is repeated until it is determined that the master node has completed sending the upgrade file.

[0167] This application provides an upgrade method in which the slave node determines a second receiving end sliding window based on the updated processing capability parameters of the slave node and the updated receiving end communication parameters. This fully utilizes the processing capability of the slave node, maximizes data transmission volume, and improves upgrade efficiency.

[0168] In yet another embodiment of this application, Figure 8 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 7 .like Figure 8 As shown, this method can be applied to the master node in the aforementioned upgrade system. Regarding step S203 in the aforementioned embodiment, after broadcasting the first data packet of the upgrade file to at least one slave node based on the first sending end sliding window, the method may further include the following steps:

[0169] S801, obtain the number of frames sent for the first data packet.

[0170] It should be noted that the number of frames sent can be the total number of frames sent in real time during the process of the master node broadcasting the first data packet to the slave node; that is, the number of frames in the upgrade data message contained in the first data packet. After the broadcast ends, the master node can read the number of frames sent to determine the actual number of upgrade data message frames sent. In other words, for each data packet of the upgrade file, the master node will record its corresponding number of frames sent during the transmission process.

[0171] S802, based on the second reply message, determine the number of received frames corresponding to each of at least one slave node.

[0172] In this embodiment, after receiving the first data packet broadcast by the master node, the slave node can send a second reply message to the master node based on the recorded number of received frames. Upon receiving the second reply messages from all slave nodes requiring upgrades, the master node sequentially parses at least one second reply message, extracts the corresponding fields, and obtains the various received frame counts for each slave node. The received frame count for a slave node can refer to the number of frames of the upgrade data packet actually received by the slave node.

[0173] It should also be noted that during the process of receiving each data packet subsequently sent by the master node, the slave node will record the corresponding number of received frames, write the number of received frames into a reply message, and send it to the master node.

[0174] S803, when the number of received frames for at least one slave node is consistent with the number of sent frames, the step of determining the second sending end sliding window based on the second reply message is executed.

[0175] As mentioned earlier, the master node broadcasts data packets to at least one slave node. Therefore, the number of received frames of the upgrade data message in the data packets received by each slave node should be consistent with the number of frames sent by the master node. In this embodiment, the master node can compare the number of received frames of each slave node with the number of sent frames in sequence to determine whether data loss has occurred during data reception.

[0176] When it is determined that the number of frames sent by the master node is consistent with the number of frames received by each slave node, the master node can broadcast data packets based on the next sending end sliding window until the upgrade file is sent.

[0177] Thus, this application provides an upgrade method in which, after broadcasting the first data packet, the master node only continues to broadcast the second data packet to at least one slave node based on the second sending end sliding window when the number of sent frames matches the number of received frames corresponding to each slave node. In this way, the master node can promptly confirm the data reception status of each slave node during the upgrade process, avoiding the loss of some frames in the data packet during the upgrade process, which could lead to the final upgrade failure and improve the stability of the upgrade process.

[0178] In some embodiments, the upgrade method performed by the master node may further include: when no second reply message is received from the first slave node within a first preset time period, or when the number of received frames and the number of sent frames by the first slave node are inconsistent, determining that the upgrade has failed and saving the upgrade failure information, which includes the reason for failure and the node number of the first slave node.

[0179] The first slave node is one of at least one slave node.

[0180] It should be noted that in the aforementioned embodiments, each slave node sends a reply message to the master node after each upgrade data packet broadcast by the master node is sent. If the master node does not receive a reply message from the first slave node among the slave nodes that need to be upgraded within a first preset time period after the first data packet is broadcast, or if the master node receives a reply message from the first slave node indicating that the upgrade has failed, or if the number of frames received by the first slave node is inconsistent with the number of frames sent, it indicates that a network failure occurred at the slave node or between the master node and the slave node during the upgrade process, or that the first slave node lost data during the reception of the upgrade data packet. The master node determines that the upgrade has failed and saves the upgrade failure information.

[0181] Thus, this application provides an upgrade method in which the master node determines that the upgrade has failed if it does not receive a second reply message from the first slave node within a first preset time period, or if the number of received frames and the number of sent frames by the first slave node are inconsistent. In this way, the master node can promptly detect the anomaly and stop the upgrade, thereby improving the reliability of the upgrade process.

[0182] In some embodiments, Figure 9 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 8 .like Figure 9 As shown, this method can be applied to any slave node in the foregoing embodiments. After receiving the first data packet of the upgrade file broadcast by the master node in step S303, the method may further include the following steps:

[0183] S901, obtain the number of received frames for the first data packet.

[0184] During the process of the master node broadcasting the first data packet to at least one slave node, the slave node records the actual number of frames received as the received frame count while receiving multiple upgrade data packets from the first data packet.

[0185] S902, based on the number of received frames and the sliding window of the second receiver, generates a second reply message and sends the second reply message to the master node.

[0186] In this embodiment of the application, the slave node can fill the recorded number of received frames into the "acknowledgment frame" field of the second reply message, fill the second receiving end sliding window into the "receive sliding window" field of the second reply message, generate the second reply message, and send the second reply message to the master node.

[0187] It should also be noted that after each slave node finishes receiving the data packets broadcast by the master node, it can fill in the number of frames received in the reply message and send it to the master node so that the master node can determine the data reception status of the slave node based on the number of frames received.

[0188] Thus, this application provides an upgrade method in which, after receiving the first data packet of the upgrade file, the slave node generates a second reply message based on the recorded number of received frames of the first data packet and sends the second reply message back to the master node. In this way, the slave node can promptly send the number of received frames back to the master node, thereby stopping the upgrade in a timely manner when a frame count error occurs during the transmission of the upgrade file, improving the efficiency and reliability of the upgrade process.

[0189] In yet another embodiment of this application, Figure 10 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 9 This method can be applied to the master node in the aforementioned upgrade system, such as... Figure 10 As shown, step S205 above, after the upgrade file is sent, may further include the following steps:

[0190] S1001, broadcast the upgrade end command to at least one slave node.

[0191] Based on the steps in the foregoing embodiments, the master node broadcasts the upgrade file data packets to the slave node multiple times until all the data packets in the upgrade file have been sent. Then, the master node can broadcast an upgrade end command to the bus, and the slave node executes the upgrade file to perform the upgrade, including steps such as erasing the original program, writing the upgrade file, and restarting.

[0192] The upgrade end command includes the node number of the slave node to be upgraded. After receiving the upgrade end command, the slave node connected to the bus matches its own slave node number with the slave node number in the upgrade end command. If the match is successful, it replies to the upgrade end command. The reply message can indicate whether the upgrade file was executed successfully or failed.

[0193] S1002, if no third reply message is received from the second slave node within the second preset time period, the upgrade is determined to have failed and the upgrade failure information is saved.

[0194] The upgrade failure information includes the reason for the failure and the node number of the second slave node.

[0195] The second slave node is one of at least one slave node.

[0196] In this embodiment, within a second preset time period after the master node broadcasts the upgrade end command, it parses the third reply messages received from at least one slave node to determine whether each slave node has successfully upgraded. For example, if the master node receives third reply messages from all slave nodes requiring upgrades, and the information in the third reply messages indicates successful upgrades, then the upgrade process ends successfully. If the master node receives a third reply message from a slave node indicating upgrade failure, or if the master node does not receive a third reply message from a slave node within the second preset time period after broadcasting the upgrade end command, then the master node considers the slave node's upgrade to have failed, saves the upgrade failure information, and confirms the upgrade failure.

[0197] Thus, this application provides an upgrade method in which, after the upgrade file is sent, the master node sends an upgrade end command to at least one slave node, and determines that the upgrade has failed if it does not receive a fourth reply message from a second slave node. In this way, the master node confirms whether each slave node has successfully upgraded via the fourth reply message after the upgrade, improving the reliability of the upgrade process.

[0198] In some embodiments, after the master node executes S201 and obtains the upgrade file based on the upgrade command issued by the server, it may further include: shutting down the first task module in the master node and controlling the master node's working mode to switch from task mode to upgrade mode.

[0199] It should be noted that the master node's task mode refers to a mode in which at least one first task module in the master node is running normally, and the master node schedules different first task modules to execute different tasks; the master node's upgrade mode refers to a mode in which only the first upgrade management module in the master node is running normally, while the other first task modules are suspended.

[0200] In this embodiment, when the communication module in the master node receives an upgrade command from the server and parses the command to extract the upgrade file, the first upgrade management module in the master node is awakened from its dormant state. Furthermore, the first upgrade management module in the master node suspends other first task modules, stops the execution of other services, and the master node switches from task mode to upgrade mode.

[0201] Thus, this application provides an upgrade method in which the master node suspends the operation of the first task module when it is in upgrade mode, allowing the master node to focus on sending and processing upgrade files, thereby improving the stability and efficiency of the upgrade process and avoiding data transmission conflicts or resource contention.

[0202] In some embodiments, Figure 11 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 This method can be applied to any slave node in the aforementioned upgrade system, such as... Figure 11 As shown, the methods executed from the node may also include:

[0203] S1101 receives the upgrade end command sent by the master node.

[0204] The upgrade end command indicates that all upgrade files have been received.

[0205] As mentioned above, after the master node finishes broadcasting the upgrade file via data packets, it sends an upgrade end command to at least one of the slave nodes that needs to be upgraded. After receiving the upgrade end command, the slave node parses the node number in the command and matches it with its own node number. If the match is found, the slave node responds to the upgrade end command.

[0206] S1102, upgrade the slave node according to the upgrade file and determine the upgrade result.

[0207] Furthermore, the upgrade is performed by executing the upgrade file on the node, including steps such as erasing the original program, writing the upgrade file, and restarting. If an error occurs during the upgrade process and the upgrade file cannot be executed, the upgrade is considered a failure; otherwise, the upgrade is considered successful.

[0208] S1103, generate a third reply message based on the upgrade result, and send the third reply message to the master node.

[0209] Finally, the slave node writes the upgrade result into the corresponding field of the third reply message, generates the third reply message, and sends the third reply message to the master node as a reply to the upgrade end command.

[0210] This application provides an upgrade method in which the master node sends an upgrade completion command to the slave node after the upgrade is completed, and the slave node sends a third reply message to the master node based on the execution result of the upgrade file. The slave node promptly informs the master node whether the upgrade was successful through the third reply message, thus improving the reliability of the upgrade process.

[0211] In some embodiments, the upgrade method performed by the slave node may further include: after receiving the upgrade start command sent by the master node, shutting down the second task module in the slave node, and controlling the slave node's working mode to switch from task mode to upgrade mode.

[0212] It should be noted that the task mode of a slave node can refer to a mode in which the second task module of the slave node is running normally and different second task modules are scheduled by the slave node to execute different tasks; the upgrade mode of a slave node refers to a mode in which only the second upgrade management module of the slave node is running normally, while the other second task modules are suspended.

[0213] In this embodiment of the application, after the slave node receives the upgrade start command sent by the master node in a polling manner, the second upgrade management module in the slave node is awakened from the dormant state, and the second upgrade management module suspends the operation of other second task modules in the slave node, so that the slave node switches from task mode to upgrade mode.

[0214] Furthermore, as mentioned above, after switching from node to upgrade mode, a first reply message is generated to respond to the upgrade start command, and the first reply message is sent to the master node.

[0215] Thus, this application provides an upgrade method in which the operation of the second task module is paused after the slave node switches to upgrade mode. This allows the slave node to focus on receiving and processing data packets, improving stability and efficiency during the upgrade process and avoiding data transmission conflicts or resource contention.

[0216] In some embodiments, the method executed by the slave node may further include: when no information is received from the master node within a third preset time period, controlling the slave node to switch its working mode from upgrade mode to task mode, and starting the second task module in the slave node.

[0217] In this embodiment, after each reply message is sent to the master node, the slave node can start a timer. If the slave node has not received any information from the master node when the timer reaches the third preset time period, such as data packets of upgrade files, file transfer commands, upgrade end commands, etc., the slave node triggers a timeout mechanism, deletes the data packets of upgrade files that have been received in the cache, the second upgrade management module goes into hibernation, the second task module starts, and the slave node switches from upgrade mode to task mode.

[0218] Thus, this application provides an upgrade method in which, if a slave node does not receive any content from the master node within a third preset time period, a timeout mechanism is triggered, switching it from upgrade mode to task mode. This avoids the slave node waiting indefinitely, improving the flexibility of the upgrade process.

[0219] In yet another embodiment of this application, Figure 12 This is a detailed flowchart illustrating an upgrade method provided in an embodiment of this application. Figure 12 As shown, this detailed process can be applied to the aforementioned upgrade system. The upgrade system includes two types of nodes: one master node and N slave nodes. Each master node deploys a first upgrade management module, a first task module, and a communication module, while each slave node deploys a second task module and a second upgrade management module.

[0220] The main functions of the first upgrade management module in the master node include:

[0221] (1) Concurrent broadcast mechanism: Concurrently broadcast upgrade instructions and upgrade file data to slave nodes of the same type on the bus;

[0222] (2) Sliding window mechanism: The sliding window of the sending end is dynamically calculated based on the sliding window of the receiving end fed back by the slave node, and the data transmission frequency is adjusted.

[0223] (3) Upgrade Management Mode: When upgrading, the first task module is terminated, and the focus is on sending and receiving upgrade data.

[0224] The main functions of the second upgrade management module in the node include:

[0225] (1) Sliding window mechanism: The receiving end sliding window is calculated based on its own system processing capacity, receiving buffer size, bus delay and other factors and fed back to the master node.

[0226] (2) Upgrade Management Mode: When upgrading, the second task module is terminated, and the focus is on receiving and processing upgrade data.

[0227] like Figure 12 As shown, this timing diagram may include the following process:

[0228] S1201: The server sends an upgrade command.

[0229] S1202: The master node parses the upgrade command and extracts the upgrade file.

[0230] After receiving the upgrade command from the upgrade tool on the server, the master node's communication module will perform concurrent upgrade tasks on the same type of slave nodes on the low-speed bus.

[0231] S1203: The master node has entered upgrade mode.

[0232] The master node is typically in task mode, or normal mode, executing different first-task modules according to system scheduling. Upon receiving an upgrade command from the server, it pauses other first-task modules and enters upgrade mode.

[0233] The master node extracts the node number of the low-speed bus slave node from the upgrade command, and simultaneously receives and decompresses the upgrade file archive.

[0234] S1204: Master node reply.

[0235] S1205: The master node polls and sends the upgrade start command.

[0236] S1206: The second task module is terminated from the node and the upgrade mode is entered.

[0237] Slave nodes are typically in task mode, or normal mode, executing different secondary task modules according to system scheduling. Upon receiving an upgrade command from the master node, they pause all executing secondary task modules, enter upgrade mode, and reply to the master node.

[0238] S1207: The node first calculates the sliding window size of the receiver.

[0239] S1208: Reply from node.

[0240] S1209: The master node calculates the sliding window size of the sending end for the first time.

[0241] S1210: The master node broadcasts the data packet containing the upgrade file.

[0242] S1211: Dynamically calculate the sliding window size of the receiver from the node.

[0243] S1212: Reply from node.

[0244] S1213: The master node dynamically calculates the sliding window size of the sending end.

[0245] S1214: The master node broadcasts an upgrade completion command.

[0246] S1215: Perform file erase and write operations on the slave node and restart.

[0247] Upon receiving the upgrade completion command broadcast by the master node, the slave node performs the final erase, write to flash, and restart operations, and then replies the upgrade results to the master node.

[0248] S1216: Reply from node.

[0249] In some embodiments, Figure 13 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 1. For example Figure 13 As shown, this method can be applied to the master node in an upgrade system and includes the following steps:

[0250] S1301, Begin.

[0251] S1302, receiving upgrade commands from the server?

[0252] If so, proceed to step S1303.

[0253] S1303, pause the first task module and enter upgrade mode.

[0254] S1304: Extract the low-speed bus upgrade slave node number from the upgrade command, and receive and decompress the upgrade file archive.

[0255] S1305 polls and sends upgrade start commands to slave nodes of the same type on the bus.

[0256] S1306, Receive replies from all slave nodes to the upgrade start command?

[0257] If yes, proceed to step S1307; otherwise, proceed to step S1317.

[0258] S1307, Broadcast File Transfer Command, continuously broadcasts data packets containing multiple upgrade files to slave nodes according to the size of the receiving end's sliding window.

[0259] For slave nodes of the same type that need to be upgraded on the bus, the master node first polls and sends an upgrade start command. After all slave nodes reply to the upgrade start command, the master node begins to use a concurrent broadcast mechanism to continuously broadcast multi-packet file transfer commands and upgrade file data packets to the low-speed bus, and records the total number of data frames actually sent as the transmission frame count.

[0260] S1308 records the total number of frames actually sent for the continuous broadcast file content.

[0261] S1309, Receive replies from all slave nodes for file transfer commands?

[0262] If yes, proceed to step S1310; otherwise, proceed to step S1317.

[0263] S1310, extract the "acknowledgment frame" field from the reply messages of each slave node, which indicates the sequence number of the last broadcast message it received.

[0264] After receiving replies from all slave nodes to the file transfer command, extract the "acknowledgment frame" field from the reply message, which indicates the number of data frames actually received by each slave node, i.e., the number of received frames corresponding to each slave node.

[0265] S1311, the "acknowledgment frame" of each slave node is equal to the total number of frames actually sent.

[0266] If yes, proceed to step S1312; otherwise, proceed to step S1317.

[0267] The total number of frames actually sent by the master node is compared with the "acknowledgment frame" field in the reply messages of each slave node to determine the number of frames received by each slave node. Further, the number of frames sent by the master node is compared with the number of frames received by each slave node.

[0268] S1312, Broadcast File Transfer Command, continuously broadcasts multiple data packets to the slave node according to the latest receiving end sliding window size.

[0269] After confirming that the number of frames sent and the number of frames received by each slave node are consistent, the master node continues to broadcast the remaining upgrade file data concurrently to the bus until the upgrade file content has been sent.

[0270] S1313 records the total number of frames actually sent for continuous broadcast data packets.

[0271] During each broadcast data packet process, the master node will record the total number of frames actually sent, which will be used as the frame count.

[0272] S1314, Has the upgrade file been sent successfully?

[0273] If yes, proceed to step S1315; otherwise, proceed to step S1317.

[0274] S1315, broadcast upgrade end command to slave node on bus.

[0275] S1316, Receive replies from all slave nodes to the upgrade end command?

[0276] If yes, proceed to step S1318; otherwise, proceed to step S1317.

[0277] Finally, the master node broadcasts an upgrade completion command to the bus. Once all slave nodes respond, the upgrade process is successfully completed. If any slave node fails to respond or fails to respond within the specified time, the upgrade fails, and the reason for the failure and the corresponding slave node number are recorded.

[0278] S1317, upgrade failed. Record the reason for failure and the corresponding slave node number.

[0279] S1318, End.

[0280] In some embodiments, Figure 14A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 2. For example Figure 14 As shown, this method can be applied to slave nodes in an upgrade system, and includes the following steps:

[0281] S1401, Begin.

[0282] S1402, after initialization, enters task mode and executes the second task module with different functions according to system scheduling.

[0283] S1403, receive the upgrade start command from the bus master node?

[0284] S1404, Reply to the master node's upgrade start command.

[0285] S1405, terminate the operation of the second task module in the system and enter upgrade mode.

[0286] S1406 receives file transfer commands and data packets concurrently broadcast by the bus master node.

[0287] If so, proceed to step S1407.

[0288] S1407: After receiving the data packets broadcast by the master node, calculate the sequence number of the last frame (acknowledgment frame) and reply.

[0289] The slave node waits to receive the "file transfer" command and upgrade file data broadcast by the master node. After receiving the data, it calculates the last frame (acknowledgment frame) and replies to the master node.

[0290] S1408, save the broadcast upgrade file data.

[0291] In this embodiment, upgrade file data refers to the data portion of the data packet broadcast by the master node.

[0292] S1409, receive the upgrade end command from the bus master node?

[0293] If yes, proceed to step S1410; otherwise, proceed to step S1406.

[0294] S1410 performs the final erase and write operations and restarts, restoring the master node.

[0295] S1411, End.

[0296] It should be noted that if a slave node does not receive any content from the master node within the third preset time period, a timeout mechanism is triggered, and it re-enters the task mode from the upgrade mode, which can also be called the normal mode, and resumes the operation of the second task module.

[0297] In some embodiments, Figure 15 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 Three. For example... Figure 15 As shown, this method can be applied to the master node in an upgrade system and includes the following steps:

[0298] S1501, Begin.

[0299] S1502, polls and sends upgrade start commands to slave nodes of the same type on the bus.

[0300] S1503, receive the first reply message from all slave nodes to the upgrade start command?

[0301] If yes, proceed to step S1504; otherwise, proceed to step S1515.

[0302] S1504, extract the "Receive Sliding Window" field from the first reply message of each slave node, and take the minimum value of all fields.

[0303] The master node first polls and sends the upgrade start command to the slave nodes of the same type. After all slave nodes reply to the upgrade start command, the master node extracts the "receive sliding window" field from the first reply message and takes the minimum value of all nodes.

[0304] S1505 is based on factors such as the minimum value of the sliding window at the receiving end, the size of the buffer at the sending end, and the round-trip delay.

[0305] S1506 was the first to estimate the actual sliding window size at the transmitter.

[0306] The master node calculates the actual sliding window size of the sender based on the minimum value of the receiving end sliding window, the current size of the sending end buffer, the round-trip delay, etc., and continuously broadcasts multiple packets of "file transfer" commands and file data to the slave nodes of the same type on the low-speed bus according to the initial sending end sliding window size.

[0307] S1507, Broadcast File Transfer Command, continuously broadcasts data packets containing multiple upgrade files to slave nodes according to the sliding window size of the initial sender.

[0308] S1508, receive reply messages from all slave nodes for file transfer commands?

[0309] If yes, proceed to step S1509; otherwise, proceed to step S1515.

[0310] S1509, extract the "Receive Sliding Window" field from the reply messages of each slave node, and take the minimum value of all fields.

[0311] After the master node receives the responses from all slave nodes to the file transfer command, it extracts the "receive sliding window" field from the response message and takes the minimum value of this field from all the response messages from the slave nodes.

[0312] S1510, based on factors such as the minimum value of the receiving end sliding window, the size of the transmitting end buffer, and round-trip delay.

[0313] Based on the updated minimum value of the receiver buffer and the round-trip delay, the actual size of the sender sliding window is dynamically adjusted, and multi-packet file transfer commands and data packets are continuously and concurrently broadcast to the same type of slave nodes on the low-speed bus according to the latest sender sliding window size until the upgrade file is sent.

[0314] S1511 dynamically adjusts the actual size of the sending end sliding window.

[0315] S1512 continuously broadcasts multiple data packets to the slave node according to the latest sending end sliding window size.

[0316] S1513, upgrade file sent successfully?

[0317] If yes, proceed to step S1514; otherwise, proceed to step S1507.

[0318] S1514, broadcast upgrade end command to slave node on bus.

[0319] The master node broadcasts an upgrade completion command to the bus. The upgrade process successfully concludes after all slave nodes respond uniformly. If any slave node fails to respond or fails to respond within the specified time, the upgrade fails, and the reason for the failure and the corresponding slave node number are recorded.

[0320] S1515, upgrade failed. Record the reason for the failure and the corresponding slave node number.

[0321] S1516, End.

[0322] In some embodiments, Figure 16 A flowchart illustrating an upgrade method provided in this application embodiment. Figure 10 IV. For example Figure 16 As shown, this method can be applied to slave nodes in an upgrade system, and includes the following steps:

[0323] S1601, Begin.

[0324] S1602, after initialization, enters task mode and executes the second task module with different functions according to system scheduling.

[0325] S1603, receive the upgrade start command from the bus master node?

[0326] S1604, based on factors such as system processing capacity, receive buffer size, and bus round-trip delay.

[0327] S1605, calculate the size of the sliding window at the receiving end for the first time and reply to the master node.

[0328] After receiving the upgrade command from the master node, the slave node calculates the size of the receiving sliding window for the first time based on factors such as system processing capacity, receive buffer size, and bus round-trip delay, and then replies to the master node.

[0329] S1606, receives upgrade transmission commands from the bus master node?

[0330] If yes, proceed to step S1607; otherwise, proceed to step S1611.

[0331] S1607, based on factors such as system processing capacity, receive buffer size, and bus round-trip delay.

[0332] S1608 dynamically calculates the size of the sliding window at the receiving end and replies to the master node.

[0333] The slave node waits to receive file transfer commands and upgrade file data packets broadcast by the master node, and dynamically calculates the size of the receiving sliding window based on factors such as the latest system processing capacity, receive buffer size, and bus latency, and then replies to the master node.

[0334] S1609, receive the upgrade end command from the bus master node?

[0335] If yes, proceed to step S1310; otherwise, proceed to step S1306.

[0336] S1610 performs the final erase and write operations and restarts, restoring the master node.

[0337] S1611, triggering the timeout mechanism, entering task mode.

[0338] S1612, End.

[0339] It should be noted that if a slave node does not receive any content from the master node within a specified time, a timeout mechanism is triggered, and it re-enters task mode, i.e., normal mode, to resume the operation of other task modules.

[0340] Based on the foregoing embodiments, this application provides an upgrade method that achieves the following functions:

[0341] (1) Concurrent broadcasting mechanism: The master node can concurrently broadcast upgrade instructions and upgrade data to the same type of slave nodes on the low-speed bus. As the number of slave nodes increases, the transmission time and response delay of upgrade data can be greatly reduced, and the overall upgrade efficiency can be improved.

[0342] (2) Sliding window mechanism: The master node can calculate the sending sliding window based on the receiving sliding window fed back by the bus slave node, dynamically adjust the frequency of data transmission, make full use of the bus bandwidth, and avoid excessive data packet loss or accumulation, thereby improving upgrade efficiency.

[0343] (3) Upgrade Mode Management: When the master and slave nodes on the bus are in upgrade mode, the operation of other task modules is suspended. This allows them to focus on receiving and processing upgrade data, improving stability and efficiency during the upgrade process and avoiding data transmission conflicts or resource contention.

[0344] This application provides an upgrade method that comprehensively utilizes concurrent broadcasting, sliding window mechanisms, and upgrade mode management to dynamically adjust the frequency of data transmission. This allows for concurrent upgrades of the same type of devices on a low-speed bus, making full use of bus bandwidth and system resources. This significantly shortens upgrade time and improves the efficiency and reliability of low-speed bus upgrades.

[0345] In yet another embodiment of this application, Figure 17 This is a schematic diagram of the composition structure of a master node provided in an embodiment of this application, such as... Figure 17 As shown, the master node 170 may include:

[0346] The first sending unit 1701 is configured to obtain the upgrade file based on the upgrade command issued by the server, and send an upgrade start command to at least one slave node in a polling manner.

[0347] The first receiving unit 1702 is configured to receive a first reply message sent by at least one slave node, and determine a first sending end sliding window based on the first reply message.

[0348] The first sending unit 1701 is also configured to broadcast a first data packet of an upgrade file to at least one slave node based on a first sending end sliding window.

[0349] The first receiving unit 1702 is further configured to receive a second reply message sent by at least one slave node, and determine a second sending end sliding window based on the second reply message.

[0350] The first sending unit 1701 is further configured to broadcast a second data packet of the upgrade file to at least one slave node based on a sliding window of the second sending end until the upgrade file is sent.

[0351] The first determining unit 1703 is configured to determine, based on the first reply message sent by at least one slave node, a first receiving end sliding window corresponding to each of the at least one slave node, and determine the sending end communication parameters; determine the minimum value of the receiving end sliding window based on the first receiving end sliding window corresponding to each of the at least one slave node; and determine the first sending end sliding window based on the minimum value of the receiving end sliding window and the sending end communication parameters.

[0352] The first determining unit 1703 is further configured to determine, based on the second reply message sent by at least one slave node, a second receiving end sliding window corresponding to each of the at least one slave node, and update the sending end communication parameters; update the minimum value of the receiving end sliding window based on the second receiving end sliding window corresponding to each of the at least one slave node; and determine the second sending end sliding window based on the updated minimum value of the receiving end sliding window and the updated sending end communication parameters.

[0353] The first determining unit 1703 is further configured to obtain the number of transmitted frames of the first data packet; determine the number of received frames corresponding to at least one slave node according to the second reply message; and when the number of received frames corresponding to at least one slave node is consistent with the number of transmitted frames, perform the step of determining the second sending end sliding window according to the second reply message.

[0354] The first determining unit 1703 is further configured to determine that the upgrade has failed and save the upgrade failure information when the second reply message sent by the first slave node is not received within the first preset time period, or when the number of received frames and the number of sent frames by the first slave node are inconsistent. The upgrade failure information includes the reason for failure and the node number of the first slave node; wherein the first slave node is one of at least one slave node.

[0355] The first sending unit 1701 is further configured to broadcast an upgrade end command to at least one slave node; if no third reply message is received from the second slave node within a second preset time period, the upgrade fails and the upgrade failure information is saved; wherein the upgrade failure information includes the reason for failure and the node number of the second slave node; wherein the second slave node is one of at least one slave node.

[0356] The first determining unit 1703 is also configured to shut down the first task module in the master node and control the master node's working mode to switch from task mode to upgrade mode.

[0357] Understandably, in this embodiment, a "unit" can be a portion of a circuit, a portion of a processor, a portion of a program or software, etc., and can also be a module or a non-modular component. Furthermore, the components in this embodiment can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0358] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0359] Therefore, this embodiment provides a computer-readable storage medium storing a computer program that, when executed by at least one first processor, implements the steps of the upgrade method executed by any of the master nodes in the foregoing embodiments.

[0360] This application also provides a computer program product containing instructions, including a computer program or instructions, which, when executed by a first processor, implement the steps in the upgrade method executed by the master node provided in the above method embodiments.

[0361] In some embodiments, Figure 18 This is a schematic diagram of the hardware structure of a master node provided in an embodiment of this application. Figure 18 As shown, the master node 170 may include: a first communication interface 1704, a first memory 1705, and a first processor 1706; the various components are coupled together via a first bus system 1707. It is understood that the first bus system 1707 is used to implement communication between these components. In addition to a data bus, the first bus system 1707 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 18 The lieutenant general designated all buses as the first bus system 1707. Among them:

[0362] The first communication interface 1704 is used for receiving and sending signals during the process of sending and receiving information with other slave nodes;

[0363] The first memory 1705 is used to store computer programs that can run on the first processor 1706;

[0364] The first processor, 1706, is used to execute the following when running computer programs:

[0365] Based on the upgrade command issued by the server, obtain the upgrade file and send an upgrade start command to at least one slave node in a polling manner;

[0366] Receive at least one first reply message from a slave node, and determine a first sending end sliding window based on the first reply message;

[0367] The first data packet of the upgrade file is broadcast to at least one slave node based on the sliding window of the first sender;

[0368] Receive at least one second reply message from a slave node, and determine a second sending end sliding window based on the second reply message;

[0369] The second data packet of the upgrade file is broadcast to at least one slave node based on the sliding window of the second sender until the upgrade file is sent.

[0370] It is understood that the first memory 1705 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The first memory 1705 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0371] The first processor 1706 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the first processor 1706 or by instructions in software form. The first processor 1706 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the first memory 1705. The first processor 1706 reads the information in the first memory 1705 and, in conjunction with its hardware, completes the steps of the above method.

[0372] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.

[0373] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. Memory can be implemented within the processor or externally.

[0374] Alternatively, as another embodiment, the first processor 1706 is further configured to perform the steps of any of the methods in the foregoing embodiments when running a computer program.

[0375] In yet another embodiment of this application, Figure 19 This application provides a schematic diagram of the composition structure of a slave node, as shown in the embodiment. Figure 19 As shown, node 180 may include:

[0376] The second receiving unit 1801 is configured to receive the upgrade start command sent by the master node.

[0377] The second sending unit 1802 is configured to determine the first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node.

[0378] The second receiving unit 1801 is also configured to receive the first data packet of the upgrade file broadcast by the master node.

[0379] The second sending unit 1802 is further configured to determine the second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node.

[0380] The second receiving unit 1801 is also configured to receive the second data packet of the upgrade file broadcast by the master node until the entire upgrade file has been received.

[0381] The second determining unit 1803 is configured to determine the processing capability parameters of the slave node and the receiving end communication parameters after receiving the upgrade start command sent by the master node; and to determine the first receiving end sliding window based on the processing capability parameters of the slave node and the receiving end communication parameters.

[0382] The second determining unit 1803 is further configured to, after receiving the first data packet of the upgrade file broadcast by the master node, update the processing capability parameters of the slave node and the receiving end communication parameters; and determine the second receiving end sliding window based on the updated processing capability parameters of the slave node and the updated receiving end communication parameters.

[0383] The second sending unit 1802 is further configured to obtain the number of received frames of the first data packet; generate a second reply message based on the number of received frames and the second receiving end sliding window; and send the second reply message to the master node.

[0384] The second sending unit 1802 is also configured to receive an upgrade end command sent by the master node; wherein, the upgrade end command is used to indicate that all upgrade files have been received; upgrade the slave node according to the upgrade files and determine the upgrade result; generate a third reply message according to the upgrade result and send the third reply message to the master node.

[0385] The second determining unit 1803 is further configured to, after receiving the upgrade start command sent by the master node, shut down the second task module in the slave node and control the slave node's working mode to switch from task mode to upgrade mode.

[0386] The second determining unit 1803 is further configured to control the working mode of the slave node to switch from upgrade mode to task mode and start the second task module in the slave node when no information is received from the master node within a third preset time period.

[0387] This application provides a computer-readable storage medium storing a computer program that, when executed by at least one second processor, implements the steps of any of the upgrade methods executed by a slave node in the foregoing embodiments.

[0388] This application also provides a computer program product containing instructions, including a computer program or instructions, which, when executed by a second processor, implement the steps in the upgrade method executed from a node provided in the above method embodiments.

[0389] In some embodiments, Figure 20 This is a schematic diagram of the hardware structure of a slave node provided in an embodiment of this application. Figure 20 As shown, node 180 may include: a second communication interface 1804, a second memory 1805, and a second processor 1806; the various components are coupled together via a second bus system 1807. It is understood that the second bus system 1807 is used to implement communication between these components. In addition to a data bus, the second bus system 1807 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 20 The lieutenant general labeled all buses as the Second Bus System 1807. Among them:

[0390] The second communication interface 1804 is used for receiving and sending signals during the process of sending and receiving information with other network elements;

[0391] The second memory 1805 is used to store computer programs that can run on the second processor 1806;

[0392] The second processor 1806 is used to execute the following when running computer programs:

[0393] Receive the upgrade start command sent by the master node;

[0394] Determine the first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node;

[0395] Receive the first data packet of the upgrade file broadcast by the master node;

[0396] Determine the second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node;

[0397] Receive the second data packet of the upgrade file broadcast by the master node until all upgrade files have been received.

[0398] It is understood that the second memory 1805 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The second memory 1805 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0399] The second processor 1806 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the second processor 1806 or by instructions in software form. The second processor 1806 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the second memory 1805. The second processor 1806 reads the information in the second memory 1805 and, in conjunction with its hardware, completes the steps of the above method.

[0400] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.

[0401] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. Memory can be implemented within the processor or externally.

[0402] Alternatively, as another embodiment, the second processor 1806 is also configured to perform the steps of any of the methods in the foregoing embodiments when running a computer program.

[0403] It should be understood that the descriptions of the above storage medium and device embodiments are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0404] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential 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 this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0405] It should also be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover 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 that element.

[0406] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0407] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0408] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0409] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0410] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0411] The above are merely preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An upgrade method characterized by, Applied to the master node, the method includes: Based on the upgrade command issued by the server, obtain the upgrade file and send an upgrade start command to at least one slave node in a polling manner; Receive a first reply message sent by the at least one slave node, and determine a first sending end sliding window based on the first reply message; The first data packet of the upgrade file is broadcast to the at least one slave node based on the first sending end sliding window; Receive a second reply message sent by the at least one slave node, and determine a second sending end sliding window based on the second reply message; The second data packet of the upgrade file is broadcast to the at least one slave node based on the second sending end sliding window until the upgrade file is sent.

2. The upgrade method of claim 1, wherein, Determining the first sending end sliding window based on the first reply message includes: Based on the first reply message sent by the at least one slave node, determine the first receiving end sliding window corresponding to each of the at least one slave node, and determine the sending end communication parameters; The minimum value of the receiving end sliding window is determined based on the first receiving end sliding window corresponding to each of the at least one slave node; The first sliding window of the transmitting end is determined based on the minimum value of the sliding window of the receiving end and the communication parameters of the transmitting end.

3. The upgrade method of claim 2, wherein, Determining the second sending end sliding window based on the second reply message includes: Based on the second reply message sent by the at least one slave node, determine the second receiving end sliding window corresponding to each of the at least one slave node, and update the sending end communication parameters; Update the minimum value of the receiving end sliding window according to the second receiving end sliding window corresponding to each of the at least one slave node; The second sending end sliding window is determined based on the updated minimum value of the receiving end sliding window and the updated sending end communication parameters.

4. The upgrading method according to any one of claims 1 to 3, characterized by, After broadcasting the first data packet of the upgrade file to the at least one slave node based on the first sending end sliding window, the method further includes: Obtain the number of frames sent for the first data packet; Based on the second reply message, determine the number of received frames corresponding to each of the at least one slave node; When the number of received frames corresponding to each of the at least one slave node is consistent with the number of sent frames, the step of determining the second sending end sliding window according to the second reply message is executed. If no second reply message is received from the first slave node within the first preset time period, or if the number of received frames from the first slave node is inconsistent with the number of sent frames, the upgrade is determined to have failed and the upgrade failure information is saved. The upgrade failure information includes the reason for failure and the node number of the first slave node. The first slave node is one of the at least one slave node.

5. The upgrade method according to any one of claims 1 to 3, characterized by, After the upgrade file is sent, the method further includes: Broadcast an upgrade end command to at least one slave node; If no third reply message is received from the second slave node within the second preset time period, the upgrade is determined to have failed and the upgrade failure information is saved; wherein, the upgrade failure information includes the reason for failure and the node number of the second slave node; The second slave node is one of the at least one slave node.

6. An upgrade method characterized by, Applied to slave nodes, the method includes: Receive the upgrade start command sent by the master node; A first receiving end sliding window is determined, a first reply message is generated based on the first receiving end sliding window, and the first reply message is sent to the master node; Receive the first data packet of the upgrade file broadcast by the master node; A second receiving end sliding window is determined, a second reply message is generated based on the second receiving end sliding window, and the second reply message is sent to the master node; Receive the second data packet of the upgrade file broadcast by the master node until all upgrade files have been received.

7. The upgrade method of claim 6, wherein, Determining the first receiving end sliding window includes: After receiving the upgrade start command sent by the master node, the processing capability parameters of the slave node and the communication parameters of the receiving end are determined. The first receiving end sliding window is determined based on the processing capability parameters of the slave node and the communication parameters of the receiving end.

8. The upgrade method of claim 6, wherein, Determining the second receiving end sliding window includes: After receiving the first data packet of the upgrade file broadcast by the master node, update the processing capability parameters of the slave node and the communication parameters of the receiving end; The second receiver sliding window is determined based on the updated processing capability parameters of the slave node and the updated receiver communication parameters.

9. The upgrade method of claim 6, wherein, After receiving the first data packet of the upgrade file broadcast by the master node, the method further includes: Obtain the number of received frames for the first data packet; The second reply message is generated based on the number of received frames and the second receiving end sliding window, and then sent to the master node.

10. The upgrade method according to any one of claims 6 to 9, characterized in that, The method further includes: Receive the upgrade end command sent by the master node; wherein the upgrade end command is used to indicate that all upgrade files have been received; The slave node is upgraded according to the upgrade file, and the upgrade result is determined; A third response message is generated based on the upgrade result, and the third response message is sent to the master node.

11. The upgrade method according to any one of claims 6 to 9, characterized in that, The method further includes: After receiving the upgrade start command from the master node, the second task module in the slave node is shut down, and the slave node's working mode is switched from task mode to upgrade mode; or, If no information is received from the master node within the third preset time period, the working mode of the slave node is switched from the upgrade mode to the task mode, and the second task module in the slave node is started.

12. A master node, characterized in that, include: The first sending unit is configured to obtain the upgrade file based on the upgrade command issued by the server, and send an upgrade start command to at least one slave node in a polling manner; The first receiving unit is configured to receive a first reply message sent by the at least one slave node, and determine a first sending end sliding window based on the first reply message; The first sending unit is further configured to broadcast a first data packet of the upgrade file to the at least one slave node based on the first sending end sliding window; The first receiving unit is further configured to receive a second reply message sent by the at least one slave node, and determine a second sending end sliding window based on the second reply message; The first sending unit is further configured to broadcast a second data packet of the upgrade file to the at least one slave node based on the sliding window of the second sending end, until the upgrade file is sent.

13. A master node, characterized in that, It includes a first memory and a first processor, wherein: The first memory is used to store computer programs that can run on the first processor; The first processor is configured to execute the computer program in the first memory to implement the steps of the upgrade method as described in any one of claims 1-5.

14. A slave node, characterized in that, include: The second receiving unit is configured to receive the upgrade start command sent by the master node; The second sending unit is configured to determine a first receiving end sliding window, generate a first reply message based on the first receiving end sliding window, and send the first reply message to the master node; The second receiving unit is further configured to receive the first data packet of the upgrade file broadcast by the master node; The second sending unit is further configured to determine a second receiving end sliding window, generate a second reply message based on the second receiving end sliding window, and send the second reply message to the master node; The second receiving unit is further configured to receive the second data packet of the upgrade file broadcast by the master node until all the upgrade files have been received.

15. A slave node, characterized in that, Includes a second memory and a second processor, wherein: The second memory is used to store computer programs that can run on the second processor; The second processor is configured to execute the computer program in the second memory to implement the steps of the upgrade method as described in any one of claims 6-11.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the first processor, it implements the steps of the upgrade method as described in any one of claims 1-5; or when it is executed by the second processor, it implements the steps of the upgrade method as described in any one of claims 6-11.

17. A computer program product having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a first processor, they implement the steps of the upgrade method as described in any one of claims 1-5; or when they are executed by a second processor, they implement the steps of the upgrade method as described in any one of claims 6-11.

Images