Parallel system and firmware upgrade method of parallel system

Abstract

The application relates to a firmware upgrading method of a parallel system and the parallel system. The method comprises the following steps: reading firmware version numbers of devices connected with a first device bus; determining device roles of the first device and the devices based on the firmware version number of the first device, the firmware version numbers of the devices and bus communication addresses of all the devices; wherein the device roles comprise an upgrading initiator, an upgrading receiver and a silent party; and performing a firmware upgrading action corresponding to the device role of each device, wherein firmware information of the device corresponding to the upgrading initiator is used for upgrading the devices corresponding to the upgrading receiver. The method can avoid the risk of upgrading failure caused by unstable network.

Description

Technical Field

[0001] The present application relates to the technical field of firmware upgrade, and in particular to a firmware upgrade method for a parallel system and a parallel system. Background Art

[0002] In a parallel system, inconsistent firmware versions across different devices can lead to a host of issues. Because different firmware versions vary in functional implementation and parameter settings, the corresponding devices' data processing capabilities and speeds also vary, making data processing speed mismatches highly likely. Furthermore, if a system failure occurs, troubleshooting becomes extremely difficult due to inconsistent software versions.

[0003] In traditional parallel system firmware upgrades, for example, for Device 1 and Device 2, the firmware upgrade is completed via a local network connection. The specific process involves first downloading the latest firmware from a server to the Internet of Things (IoT) module. The IoT module then transmits the firmware to Device 1 and Device 2 via a serial port or Controller Area Network (CAN) communication method, completing the firmware upgrade. However, this parallel system firmware upgrade method is highly dependent on the network. If the system environment experiences poor, unstable, or interrupted network signals, the upgrade is likely to fail, resulting in incomplete or erroneous data transmission, causing the device to become unstable or even malfunction. Summary of the Invention

[0004] Based on this, it is necessary to provide a firmware upgrade method and a parallel system for the above technical problems.

[0005] In a first aspect, the present application provides a firmware upgrade method for a parallel system, comprising:

[0006] Reading the firmware version number of each device connected to the first device bus;

[0007] Determine the device roles of the first device and each of the devices based on the firmware version number of the first device, the firmware version numbers of the respective devices, and the bus communication addresses of all devices; wherein the device roles include upgrade initiator, upgrade receiver, and silent party;

[0008] A firmware upgrade action corresponding to the device role of each device is executed, wherein the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade recipient.

[0009] In a second aspect, the present application further provides a parallel system, the parallel system comprising at least two devices communicating via a bus, each device comprising:

[0010] A reading module is used to read the firmware version numbers of other devices connected to the communication bus;

[0011] A device role determination module, which determines the device role of a device based on all firmware version numbers and bus communication addresses of all devices, wherein the device roles include upgrade initiator, upgrade receiver, and silent party;

[0012] The upgrade action execution module is used for the firmware upgrade work corresponding to the device role. The firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver.

[0013] The firmware upgrade method and parallel system described above include: reading the firmware version number of each device connected to the first device bus; determining the device roles of the first device and each device based on the firmware version number of the first device, the firmware version numbers of each device, and the bus communication addresses of all devices; wherein the device roles include an upgrade initiator, an upgrade receiver, and a silent party; and executing the firmware upgrade action corresponding to the device role of each device, wherein the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver. Through this solution, by autonomously identifying firmware versions between devices and dynamically assigning upgrade roles, the system can use higher-version devices as upgrade sources without relying on an external network, avoiding the risk of upgrade failure due to network instability. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0015] Figure 1 is a schematic diagram of a parallel system in one embodiment;

[0016] Figure 2 A schematic diagram of chip flash memory partitioning of each device in a parallel system according to one embodiment;

[0017] Figure 3 A schematic flow chart of a firmware upgrade method for a parallel system according to an embodiment;

[0018] Figure 4 1 is a flow chart of a method for determining device roles of a first device and each device in one embodiment;

[0019] Figure 5 A flowchart of another method for upgrading firmware of a parallel system according to an embodiment is shown;

[0020] Figure 6 A schematic diagram of a flow chart of executing a firmware upgrade action corresponding to a device role of each device in one embodiment;

[0021] Figure 7 FIG. 4 is a structural block diagram of each device in a parallel system in one embodiment. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0023] The firmware upgrade method of the parallel system provided in the embodiment of the present application can be applied to Figure 1 In the schematic diagram of the parallel system shown in FIG. A parallel system may include multiple parallel devices, which may be of the same type, but the firmware versions of these devices may be inconsistent. Figure 1 As shown in FIG, the firmware version number of device 1 is 01, the firmware version number of device 2 is 02, and the firmware version number of device 3 is 03. These devices are connected through a parallel system controller area network (CAN) bus.

[0024] Figure 2 The following is a schematic diagram of the chip flash memory (Flash) division of each device in a parallel system. Figure 2 As shown in the figure, the chip Flash of each device is divided into:

[0025] Boot program (BOOT) area: The area used to store the boot program cannot be erased;

[0026] Upgrade flag area: Application (APP) running area firmware size, APP running area firmware version number, 32-bit cyclic redundancy check code (Cyclic Redundancy Check 32, CRC32) of APP running area firmware, APP backup area firmware size, APP backup area firmware version number, APP backup area firmware CRC32;

[0027] APP running area: used to store business logic code. This area is the core running area for executing business logic;

[0028] APP backup area: used to temporarily store the firmware received during software upgrade.

[0029] In the embodiment of the present application, the upgrade process can be implemented by upgrading the device with a lower firmware version number through the device with a higher firmware version number. For example, Figure 1 In the process, the firmware information is sent to the device 1 through the device 3 for the upgrade process.

[0030] In an exemplary embodiment, Figure 3 As shown, a flow chart of a firmware upgrade method for a parallel system is provided, in which the method is applied to Figure 1 Taking any device in the parallel system as an example, the method includes the following steps 301 to 303:

[0031] 301. Read the firmware version number of each device connected to the first device bus.

[0032] The first device mentioned above may be any device in the parallel system.

[0033] In an embodiment of the present application, the devices in the parallel system are connected via a bus, wherein the first device can read the firmware version number of each device connected to the first device bus.

[0034] The aforementioned bus may refer to a CAN bus.

[0035] For example, the first device can send a version query request to all connected devices via the CAN bus (for example, broadcasting a CAN message in a specific format). After receiving the request, other devices return their own firmware version numbers via the CAN bus (for example, replying with a CAN message containing the version number). The CAN bus can support multi-device communication and distinguish messages from different devices through CAN identifiers (IDs).

[0036] 302. Determine device roles of the first device and each device based on the firmware version number of the first device, the firmware version numbers of each device, and bus communication addresses of all devices.

[0037] Device roles include upgrade initiator, upgrade receiver, and silent device.

[0038] The upgrade initiator is the device with the highest firmware version number and is responsible for providing firmware data to devices with lower versions.

[0039] The upgrade receiver is a device with a lower firmware version number (for example, the firmware version number is not the highest, or the firmware version number is the lowest). It needs to receive firmware information from the upgrade initiator and update it.

[0040] In some embodiments, each device in the parallel system can read the firmware version numbers of all devices on the CAN bus within a first preset time period, and then compare the read firmware version numbers of each device with its own firmware version number. Specifically, for the first device, the first device can compare its own firmware version number with the firmware version numbers of each device to determine the device role of the first device and each device.

[0041] The first preset time duration may be a time window set by the system (eg, 10 seconds), within which the firmware version numbers of all devices on the CAN bus must be read.

[0042] In some embodiments, the first device can compare its own firmware version number with the version numbers of other devices one by one. If it finds a device with a higher firmware version number, it can determine that it is the upgrade recipient; if it finds that its own firmware version number is the highest, it can determine that it is the upgrade initiator.

[0043] For example, assuming that the parallel system includes device A, device B and device C, and the firmware version number of device A is 1.0, the firmware version number of device B is 1.2, and the firmware version number of device C is 1.1, then it can be determined that device B is the upgrade initiator, and device A and device C are the upgrade receivers.

[0044] 303. Execute a firmware upgrade action corresponding to the device role of each device.

[0045] The firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver.

[0046] In some embodiments, for the upgrade initiator, the firmware upgrade action performed by it may include: sending its own firmware information to the upgrade recipient.

[0047] In some embodiments, for the upgrade recipient, the firmware upgrade action performed by it may include: receiving firmware information sent by the upgrade initiator, and upgrading its own firmware based on the firmware information.

[0048] Exemplarily, the above firmware information may include but is not limited to: firmware binary file, version number, check code (such as CRC or hash value) and other metadata.

[0049] The firmware upgrade method for the parallel system mentioned above autonomously identifies firmware versions between devices and dynamically allocates upgrade roles. The upgrade process relies entirely on bus communication between devices. There is no need to connect to an external server or cloud, and no need to rely on an external network to use high-version devices as the upgrade source. This avoids the risk of upgrade failure due to network instability and avoids the risk of network delays or interruptions.

[0050] In an exemplary embodiment, Figure 4 As shown, a flowchart of a method for determining the device roles of a first device and each device is provided, which may include the following steps 401 to 404:

[0051] 401. Determine whether the firmware version number of any device among the devices is smaller than the firmware version number of the first device.

[0052] In an embodiment of the present application, after obtaining the firmware version number of the first device in the parallel system and the firmware version numbers of each device connected to the first device bus, the size of these firmware version numbers can be determined, and the device role corresponding to each device can be determined based on the size judgment result.

[0053] If the firmware version number of any device among the devices is smaller than the firmware version number of the first device, then it means that the first device is the only device with the largest firmware version number, and the following step 402 is executed; if the firmware version number of any device among the devices is greater than or equal to the firmware version number of the first device, then it means that the first device is not the only device with the largest firmware version number, and the following steps 403 and 404 are executed.

[0054] In the embodiment of the present application, during the upgrade process, there is one and only one upgrade initiator, and there may be one or more upgrade recipients.

[0055] 402. Determine the device role of the first device as an upgrade initiator and determine each device as an upgrade receiver.

[0056] At this time, the first device is the device with the highest version in the system. At this time, the first device naturally becomes the upgrade initiator, and the other devices are upgrade receivers.

[0057] In some embodiments, the first device can broadcast a role assignment notification to the bus. For example, the first device can declare itself as the upgrade initiator via a CAN message. After receiving the notification, other devices enter receiver mode and prepare to receive firmware data.

[0058] 403. Determine whether the firmware version number of the second device is equal to the firmware version number of the first device among the devices.

[0059] For example, assume a parallel system includes devices A, B, and C. Device A's firmware version is 1.0, while both devices B and C have version 2.0. Therefore, the firmware versions of devices B and C are equal. In this case, it's impossible to directly determine which of devices B and C is the upgrade initiator. This requires further determination based on the bus communication address priorities of devices B and C.

[0060] 404. Determine an upgrade initiator, an upgrade receiver, and a silent party based on the priorities of the bus communication addresses of the first device and the second device.

[0061] Among them, if the priority of the bus communication address of the first device is greater than the priority of the bus communication address of the second device, the first device is the upgrade initiator, the second device is the silent party, and the devices other than the second device are the upgrade receivers; if the priority of the bus communication address of the second device is greater than the priority of the bus communication address of the first device, the second device is the upgrade initiator, the first device is the silent party, and the devices other than the second device are the upgrade receivers.

[0062] The bus communication address may refer to a unique identifier of a device on the bus, such as a node ID in a CAN bus, which may be referred to as a CAN ID.

[0063] For example, the smaller the CAN ID value, the higher the priority. For example, a CAN ID of 0x100 has a higher priority than a CAN ID of 0x200. The priority of the bus communication address is used to arbitrate conflicts when multiple devices have the same firmware version number and are identified as the upgrade initiator.

[0064] For example, assume a parallel system includes devices A, B, and C. Device A's firmware version is 1.0, while both devices B and C have version 2.0. Therefore, the firmware versions of devices B and C are equal. In this case, it's impossible to directly determine which of devices B and C is the upgrade initiator. Assuming that device B's CAN ID is 0x100 and device C's CAN ID is 0x200, we can determine that device B is the upgrade initiator, device A is the upgrade receiver, and device C is the silent device. A silent device is a device that does not send information over the bus but instead listens to information sent on the bus.

[0065] In the above embodiment, when there are multiple devices in the system, the system first determines whether the first device has the highest version based on a firmware version comparison. If all devices have a lower version number than the first device, the first device is directly designated as the upgrade initiator, and the remaining devices are designated as upgrade recipients. If there are devices with the same version number (such as the second device), arbitration is further performed based on the device's bus communication address priority (for example, a CAN ID with a smaller value in the CAN bus has a higher priority) to ensure the identification of a unique upgrade initiator. This method achieves decentralized role allocation through local bus communication, avoiding the risk of upgrade interruption caused by network dependence, while effectively reducing bus load through priority rules and silent mechanisms, ensuring the efficiency and reliability of the upgrade process. It is particularly suitable for scenarios such as industrial control that have strict real-time and stability requirements.

[0066] In an exemplary embodiment, Figure 5 As shown, a flow chart of a firmware upgrade method for a parallel system is provided, in which the method is applied to Figure 1 Taking any device in the parallel system as an example, the method includes the following steps 501 to 506:

[0067] 501. Read the firmware version number of each device connected to the first device bus.

[0068] 502. Determine device roles of the first device and each device based on the firmware version number of the first device, the firmware version numbers of each device, and bus communication addresses of all devices.

[0069] For the above steps 501 and 502, reference may be made to the description of the above steps 301 and 302, which will not be repeated here.

[0070] 503. Obtain array set S and array set A.

[0071] In some embodiments, after determining the device roles of the first device and each device, the firmware upgrade method for the parallel system may further include: obtaining an array set S.

[0072] The array set S of all devices being upgraded can be obtained based on the priority of the bus communication address of the upgrade recipient. The array set S of the above devices may include:

[0073] (1) The first array.

[0074] The first array in the array set S may be formed with the upgrade initiator, and the first group stores a serial number 1, a firmware version number of the upgrade initiator, and a bus communication address of the upgrade initiator.

[0075] (2) The second array.

[0076] The second array in the array set S is formed with the upgrade receiver, and the priorities of the bus communication addresses of the devices corresponding to the upgrade receiver are sorted from large to small to obtain multiple arrays starting with sequence number 2; wherein the second array stores the number with sequence number 2, the firmware version number of the device with sequence number 2 in the upgrade receiver, the bus communication address of the device with sequence number 2 in the upgrade receiver, ..., and the Nth array stores the number with sequence number N, the firmware version number of the device with sequence number N in the upgrade receiver, and the bus communication address of the device with sequence number N in the upgrade receiver.

[0077] In some cases, there is no silent party. Exemplarily, the data in the above array set S may include the content shown in the following Table 1:

[0078] Table 1

[0079]

[0080] It should be noted that in the above table 1, the first row corresponding to the serial number 1 is the first array, the information therein is the information of the upgrade initiator, and the information of the other rows is the information of the second array, which is the information of the upgrade receiver. Each row is the information of an upgrade receiver.

[0081] In some embodiments, there are also silent parties. After determining the device roles of the first device and each device, the above-mentioned firmware upgrade method of the combined system can further include: obtaining an array set A. The array set A is formed by the silent parties, wherein the priority of the bus communication address of the device corresponding to the silent party is sorted in descending order to obtain the array set A; and the array set A stores the firmware version number and the bus communication address of each silent party. The silent party can include one or more.

[0082] For example, the data in the above-mentioned array set A can include the contents shown in Table 2 as follows:

[0083] Table 2

[0084]

[0085] It should be noted that in the above table 2, the firmware version number of each silent party device is the same as that of the upgrade initiator in table 1, and the bus communication address is different. The priority of the bus communication address in table 2 is sorted in descending order, and the first row in the sorting has the highest priority of the bus communication address among the silent parties.

[0086] 504, the role of the upgrade initiator in the array set S is confirmed again.

[0087] In some embodiments, the role of the upgrade initiator in the array set S can also be confirmed again. The reconfirmation process can include but is not limited to:

[0088] (1) First confirmation step: according to the data in the Flash in the device of the upgrade initiator, the firmware version number of the upgrade initiator is confirmed.

[0089] Among them, according to the data in the Flash in the device of the upgrade initiator, the firmware version number of the upgrade initiator is confirmed, which can include: comparing the firmware version number of the upgrade initiator with the firmware version number of each upgrade receiver; if there is an upgrade receiver whose firmware version number is greater than that of the upgrade initiator, the upgrade receiver is deleted in the array set S, the serial numbers of all arrays in the array set S are updated in sequence, and a new array set S is obtained. If the number of arrays in the new array set S is greater than 1, the first confirmation step is successful.

[0090] The upgrade initiator can read the content of the upgrade flag area of ​​the Flash to obtain the firmware version number of the APP backup area of ​​the Flash, and then compare it with the firmware version number of each upgrade recipient.

[0091] The first confirmation step above verifies the legitimacy of the firmware version number. During the upgrade initiator's verification process, the upgrade initiator reads the firmware version number from its own Flash memory and compares it with the version numbers of all upgrade recipients. If the comparison reveals that a particular upgrade recipient has a higher version, this indicates that the upgrade recipient's role was incorrectly determined. In this case, the upgrade recipient's information can be deleted from array set S, and array set S can be updated (with an updated sequence number). If the number of remaining devices indicated in the new array set S is greater than 1, then the second confirmation step, described below, can be continued.

[0092] For example, it is assumed that the initial information in the array set S is as shown in Table 3 below:

[0093] Table 3

[0094]

[0095] Among them, sequence number 1 in Table 3 represents the upgrade initiator, and sequence numbers 2, 3, and 4 all represent upgrade receivers. The upgrade initiator can check the firmware version numbers of all upgrade receivers. In the array set S shown in Table 3 above, it can be found that the firmware version number of the upgrade initiator with sequence number 2 is higher than that of the upgrade initiator. At this time, the information of the upgrade initiator with sequence number 2 can be directly deleted from Table 3, and the array set S can be updated again. The updated array set S can obtain the content shown in Table 4.

[0096] Table 4

[0097]

[0098] In the above Table 4, the remaining devices in the second array also include devices with serial numbers 2 and 3, and their number is greater than 1. Therefore, it can be considered that the first confirmation step is successful at this time, and the second confirmation step can be continued.

[0099] (2) When the first confirmation step is successful, the second confirmation step is performed: based on the data in the Flash memory of the device of the upgrade initiator, the integrity of the firmware information used for the upgrade is confirmed.

[0100] Among them, based on the data in the Flash in the device of the upgrade initiator, the integrity of the firmware information used for the upgrade is confirmed, including: reading the content of the upgrade flag area in the Flash of the upgrade initiator to obtain the preset verification code of the APP backup area firmware therefrom; calculating the first verification code corresponding to the APP backup area firmware in the Flash of the upgrade initiator; if the preset verification code matches the first verification code, the integrity of the firmware information used for the upgrade is confirmed successfully, otherwise the integrity confirmation fails.

[0101] The second confirmation step is to verify the integrity of the firmware. The preset checksum may be CRC32. If the preset checksum matches the first checksum, the firmware information is confirmed to be complete and the confirmation is successful. If they do not match, the firmware is damaged or tampered with, and the confirmation fails.

[0102] The second confirmation process described above can prevent upgrade failure or system crash due to firmware damage.

[0103] (3) When either the first confirmation step or the second confirmation step fails, the role of the upgrade initiator is relinquished to the silent party based on the search of the array set A.

[0104] When the confirmation is successful, directly execute the following step 506; when the confirmation fails, first execute the following step 505 and then execute the following step 506.

[0105] 505. Based on the search of array set A, the role of the upgrade initiator is relinquished to the silent party.

[0106] In some embodiments, when the confirmation fails, the silent party with the highest ranking is searched for in the array set A, and the silent party with the highest ranking is used as the updated upgrade initiator.

[0107] In some embodiments, when either the first confirmation step or the second confirmation step fails, a new upgrade initiator is determined from devices with the same firmware version number as the current upgrade initiator, so that the upgrade initiator's role is relinquished.

[0108] Among them, the target device with the highest priority of the corresponding bus communication address can be preferentially selected as the new upgrade initiator from the devices with the same firmware version number as the current upgrade initiator, and the upgrade initiator role can be relinquished to the target device.

[0109] For example, the current upgrade initiator can send a message to yield the upgrade party identity. If the target device receives a message to confirm the upgrade party identity within the second preset time period, the target device is confirmed to be the new upgrade initiator, and the yield process is completed. If the target device does not receive a message to confirm the upgrade party identity within the second preset time period, it is necessary to further select the device with the highest priority of the next bus communication address among the devices with the same firmware version number as the new upgrade initiator, and so on until the yield process is completed.

[0110] Among them, the above-mentioned current upgrade initiator can carry the CANID of the target device in the upgrade party identity confirmation message. After the target device receives the upgrade party identity confirmation message and finds that the CAN ID carried in the message is consistent with its own CAN ID, it can reply to the current upgrade initiator with the upgrade party identity confirmation message.

[0111] 506. Execute a firmware upgrade action corresponding to the device role of each device.

[0112] The upgrade initiator can package the firmware information into blocks and send it to the upgrade receiver via the bus. In return, the upgrade receiver can receive the data packets, verify the integrity of the data packets, write them into the Flash storage area, and after receiving the complete firmware information, upgrade its own firmware based on the firmware information.

[0113] The above embodiment significantly improves the reliability of firmware upgrades through structured array set management and a dual confirmation mechanism. Hardware priorities, such as CAN IDs, can be used to determine device roles. Software logic can also be used to verify firmware version numbers and check firmware information integrity to ensure data reliability. This ultimately achieves a decentralized, highly robust firmware upgrade process.

[0114] In an exemplary embodiment, Figure 6 As shown, a flowchart of executing the firmware upgrade action corresponding to the device role of each device is provided, such as Figure 6 As shown, the process may include the following steps 601 to 604:

[0115] 601. Complete the handshake upgrade operation between the upgrade initiator and each upgrade receiver.

[0116] In some embodiments, completing the handshake upgrade operation between the upgrade initiator and each upgrade receiver may include but is not limited to: the upgrade initiator sends a handshake packet message to the upgrade receiver, the handshake packet message includes the firmware version number and firmware size of the upgrade initiator, and after the upgrade receiver receives the sent handshake packet message, it can parse the handshake packet message to obtain the firmware version number and firmware size of the upgrade initiator, and then compare the firmware version number of the upgrade initiator's device with the firmware version number of the upgrade receiver's device, as well as the firmware size of the upgrade initiator with the firmware size allowed by the upgrade receiver's device; if the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade receiver's device, and the firmware size of the upgrade initiator is less than or equal to the firmware size allowed by the upgrade receiver's device, the upgrade initiator sends an upgrade permission message to the communication bus.

[0117] Among them, if the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade receiver's device, and the upgrade initiator's firmware size is less than or equal to the firmware size allowed by the upgrade receiver's device, then the upgrade receiver can send an upgrade permission message to the upgrade initiator. If the firmware version number of the upgrade initiator's device is less than or equal to the firmware version number of the upgrade receiver's device, or the upgrade initiator's firmware size is greater than the firmware size allowed by the upgrade receiver's device, then the upgrade receiver can send an upgrade rejection message to the upgrade initiator.

[0118] For the upgrade initiator, if it receives an upgrade permission message from a certain device, it can send a transmission start message within the preset time. After the preset time ends, both the upgrade initiator and the upgrade receiver jump to the BOOT area of ​​the Flash and enter the firmware information transmission stage.

[0119] The above verification of whether the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade recipient's device can ensure the validity of the upgrade, and verifying whether the firmware size of the upgrade initiator is greater than the firmware size allowed by the upgrade recipient's device can avoid write overflow.

[0120] For example, assuming that the firmware version number of the upgrade initiator is 3.0, the firmware version number of the upgrade recipient is 2.0, and the firmware size does not exceed the firmware size allowed by the upgrade recipient, the handshake is successful.

[0121] 602. Initial sub-packet transmission operation of the upgrade initiator.

[0122] The firmware data in the APP backup area of ​​the Flash memory of the upgrade initiator is sequentially unpacked to obtain a plurality of sequentially numbered sub-packet data; and the first sub-packet data is sent to the communication bus.

[0123] Exemplarily, the upgrade initiator splits the APP backup area firmware in the Flash into multiple sub-packets according to a preset package size, and numbers them in sequence, such as package 1, package 2, ..., package N, and sends package 1 to the communication bus for the first time.

[0124] In the embodiment of the present application, a packet transmission mechanism is adopted to split the firmware into multiple data packets, reduce the amount of data transmitted in a single time, and adapt to the bus bandwidth limitation.

[0125] 603. Upgrade the receiving party's packet confirmation response operation.

[0126] Among them, the current sub-package data on the communication bus is obtained; the current sub-package data is verified, the current sub-package data that has successfully been verified is stored in the APP backup area of ​​the Flash, and the verification pass information is responded to the upgrade initiator; when the verification of the current sub-package data fails, the current sub-package data is requested to be resent.

[0127] In some embodiments, the upgrade recipient calculates a checksum, such as CRC32, on the subpacketized data and compares the calculated checksum with the checksum carried in the packet for verification. If the two checksums match, the verification is determined to be successful; if the two checksums do not match, the verification is determined to have failed.

[0128] In some embodiments, during the packet receiving confirmation response operation of the upgrade receiver, if a device of the upgrade receiver does not respond to the verification pass information to the upgrade initiator within a second preset interval, the upgrade receiver is set to a silent party, wherein a silent party is a device that does not send information via the bus and listens to information sent on the bus. In some embodiments, the device that did not respond to the verification pass information to the upgrade initiator is removed from the array set S, the sequence number of the device in the array set S is updated, and it is determined whether the number of devices in the updated array set S is greater than 1. If it is greater than 1, the subsequent sub-packet transmission continues; otherwise, the upgrade operation is exited. In some embodiments, if there are 4 device information in the current array set S, if the device with sequence number 2 is the device that did not respond to the verification pass information to the upgrade initiator, the device with sequence number 2 is removed from the current array set, and the current array set S is updated: the device originally with sequence number 3 is updated to the device with sequence number 2, and the device originally with sequence number 4 is updated to the device with sequence number 3; the number of devices in the updated array set S is 3, and the transmission of the next subsequent sub-packet continues; wherein the second preset interval is greater than the first preset interval.

[0129] For example, the upgrade initiator sends packet 1 to the communication bus for the first time. After receiving packet 1 sent by the upgrade initiator, the upgrade receiver can send a retransmission request if the verification fails; if there is no response within the timeout, it can be set as a silent party.

[0130] 604. The upgrade initiator subcontracts the transmission operation again.

[0131] Among them, within the first preset interval, after receiving the verification pass information of all upgraded receivers during the previous sub-packet transmission, the next sub-packet data is sent to the communication bus according to the number; then the upgraded receiver performs the package confirmation response operation until the last sub-packet data is sent.

[0132] For example, after receiving the package 1 sent by the upgrade initiator, the upgrade receiver receives verification pass information from all upgrade receivers within a first preset interval, and then can continue to send the package 2 to the communication bus.

[0133] For example, it can be defined that there are 5 devices in the parallel system, including:

[0134] Device 1, CAN ID is 0x1111, firmware version number is 50;

[0135] Device 2, CAN ID is 0x2222, firmware version number is 50;

[0136] Device 3, CAN ID is 0x3333, firmware version number is 60;

[0137] Device 4, CAN ID is 0x4444, firmware version number is 60;

[0138] Device 5, CAN ID is 0x5555, firmware version number is 60;

[0139] In the embodiment of the present application, in an offline state, the firmware version numbers of device 1 and device 2 can be upgraded to 60 to make them consistent with the version numbers of other devices. The implementation process may include but is not limited to the following process:

[0140] 1. Devices 1 and 2 act as upgrade receivers, devices 3 and 4 act as silent devices, and device 5 acts as the upgrade initiator. Device 5 has the largest CAN ID among devices 3, 4, and 5, so it acts as the upgrade initiator.

[0141] 2. If device 5 successfully verifies the firmware in the APP backup area of ​​the Flash, it is finally confirmed as the upgrade initiator. If the verification fails, it will give up the upgrade initiator identity to device 4. If device 4 fails to verify the firmware in the APP backup area of ​​the Flash, it will give up the upgrade initiator identity to device 3. If device 3 still fails to verify the firmware in the APP backup area of ​​the Flash, the upgrade is not satisfied and the entire upgrade process can be terminated.

[0142] 3. Device 5 sends a handshake upgrade command to Device 1 and Device 2. Device 1 and Device 2 compare the handshake information with their own definitions to confirm whether they meet the upgrade requirements.

[0143] The specific determination of whether the upgrade is satisfied may be based on the above-mentioned firmware size and firmware version number, which will not be described in detail here.

[0144] Assume that both Device 1 and Device 2 meet the upgrade requirements and both respond with an upgrade permission message. After Device 5 receives the upgrade recipient's response, it counts the responses and determines whether the number is greater than 0. If so, it initiates a transfer start message and jumps to the Flash's BOOT area. After Device 1 and Device 2 receive the transfer start message, they also jump to the Flash's BOOT area to receive the firmware.

[0145] 4. Device 5 splits the firmware into N small packets and transmits them separately. After each packet is transmitted, it waits for Device 1 and Device 2 to verify that they have passed before sending the next packet. This continues until the firmware is completely transmitted. If a device requests a retransmission during the transmission process, the packet is retransmitted. If a device responds to the request to exit the upgrade, does not respond after multiple retransmissions, or continues to request a repeat after multiple retransmissions, the device is removed from the record list and will not be considered for subsequent firmware transmissions. This assumes that during the fifth packet of firmware information, Device 2 responds to exit the upgrade, becoming the silent party. From the sixth packet onward, Device 5 only cares about Device 1's response and no longer cares about Device 2.

[0146] 5. After the firmware is transferred, device 5 can send an upgrade completion message. If device 1 responds that device 5 has received the message, device 5 will jump to the app runtime area in the Flash memory, and the upgrade process is complete. After receiving the upgrade completion message, devices 2, 3, and 4 exit the silent state and no longer act as silent parties, but instead communicate normally. If, during the next upgrade process, the device with the higher firmware version detects that device 2 has a lower firmware version, it will initiate a new upgrade for device 2.

[0147] Among them, device 1 verifies the entire firmware received. If the calculated verification code is consistent with the verification code of the entire firmware received, it indicates that the firmware is received completely, and the firmware in the APP backup area of ​​Flash is copied to the APP running area of ​​Flash. After the copy is completed, the content of the upgrade flag area of ​​Flash is updated, and then jumps to the APP running area of ​​Flash to run the latest software.

[0148] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0149] An embodiment of the present application further provides a parallel system, which includes at least two devices communicating via a bus.

[0150] For example, Figure 7 As shown, a structural block diagram of each device in a parallel system is provided, including:

[0151] A reading module 701 is used to read the firmware version numbers of other devices connected to the communication bus;

[0152] The device role determination module 702 determines the device role of the device based on all firmware version numbers and bus communication addresses of all devices, wherein the device roles include upgrade initiator, upgrade receiver and silent party;

[0153] The upgrade action execution module 703 is used for the firmware upgrade work corresponding to the device role. The firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade recipient.

[0154] In some embodiments, the device role determination module 702 is configured to:

[0155] If the firmware version number of any device in each device is smaller than that of the first device, determining the device role of the first device as the upgrade initiator and determining each device as the upgrade recipient;

[0156] If the firmware version number of each of the devices is less than or equal to the firmware version number of the first device, and there is a second device among the devices with a firmware version number equal to the firmware version number of the first device, then the upgrade initiator, upgrade receiver and silent party are determined based on the priority of the bus communication addresses of the first device and the second device: if the priority of the bus communication address of the first device is greater than the priority of the bus communication address of the second device, then the first device is the upgrade initiator, the second device is the silent party, and the devices among the devices other than the second device are upgrade receivers; if the priority of the bus communication address of the second device is greater than the priority of the bus communication address of the first device, then the second device is the upgrade initiator, the first device is the silent party, and the devices among the devices other than the second device are upgrade receivers.

[0157] In some embodiments, each device in the parallel system may further include an array set acquisition module. After the device role determination module 702 determines the device roles of the first device and each of the devices, the array set acquisition module may further determine an array set S and an array set A:

[0158] The upgrade initiator forms a first array in the array set S, wherein the first array stores a serial number 1, a firmware version number of the upgrade initiator, and a bus communication address of the upgrade initiator;

[0159] The second array in the array set S is formed using the upgrade recipients, and the bus communication addresses of the devices corresponding to the upgrade recipients are sorted in descending order of priority to obtain multiple arrays starting with sequence number 2; wherein the second array stores a number with sequence number 2, a firmware version number of the device with sequence number 2 in the upgrade recipient, and a bus communication address of the device with sequence number 2 in the upgrade recipient, ..., and the Nth array stores a number with sequence number N, a firmware version number of the device with sequence number N in the upgrade recipient, and a bus communication address of the device with sequence number N in the upgrade recipient;

[0160] The array set A is formed with silent parties, wherein the priorities of the bus communication addresses of the devices corresponding to the silent parties are sorted from large to small to obtain the array set A; the array set A stores the firmware version number and bus communication address of each silent party.

[0161] In some embodiments, each device in the parallel system may further include an upgrade initiator role reconfirmation module, which may reconfirm the role of the upgrade initiator in the array set S:

[0162] The first confirmation step is to confirm the firmware version number of the upgrade initiator according to the data in the Flash in the device of the upgrade initiator.

[0163] When the first confirmation step is successful, the second confirmation step is to confirm the integrity of the firmware information for the upgrade according to the data in the Flash in the device of the upgrade initiator.

[0164] When one of the first confirmation step or the second confirmation step fails, the role of the upgrade initiator is given up to the silent party based on the search of the array set A.

[0165] The confirmation of the firmware version number of the upgrade initiator according to the data in the Flash in the device of the upgrade initiator includes:

[0166] Comparing the firmware version number of the upgrade initiator with the firmware version number of each upgrade receiver;

[0167] If the firmware version number of one upgrade receiver is greater than the firmware version number of the upgrade initiator, the upgrade receiver is deleted in the array set S, the serial numbers of all arrays in the array set S are updated in sequence, a new array set S is formed, and if the number of remaining devices indicated in the new array set S is greater than 1, the first confirmation step is successful.

[0168] The confirmation of the integrity of the firmware information for the upgrade according to the data in the Flash in the device of the upgrade initiator includes:

[0169] Reading the content of the upgrade flag area in the Flash of the upgrade initiator to obtain a preset check code of the APP backup area firmware therefrom;

[0170] Calculating a first check code corresponding to the APP backup area firmware in the Flash of the upgrade initiator;

[0171] If the preset check code matches the first check code, the confirmation of the integrity of the firmware information for the upgrade is successful, otherwise the confirmation of the integrity fails.

[0172] In some embodiments, the upgrade action execution module 703 is configured to:

[0173] Complete the handshake upgrade operation of the upgrade initiator and each upgrade receiver;

[0174] The initial packet transmission operation of the upgrade initiator is to sequentially unpack the APP backup area firmware data in the Flash of the upgrade initiator to obtain a plurality of sequentially numbered packet data, and send the first packet data to the communication bus.

[0175] The upgrade receiver's packet confirmation response operation: obtain the current sub-packet data on the communication bus; verify the current sub-packet data, store the successfully verified current sub-packet data in the APP backup area of ​​the Flash, and respond with a verification pass message to the upgrade initiator; if the verification of the current sub-packet data fails, request to resend the current sub-packet data.

[0176] The upgrade initiator performs another sub-packet transmission operation: within the first preset interval, after receiving the verification pass information of all upgrade receivers during the previous sub-packet transmission, it sends the next sub-packet data to the communication bus according to the number; then performs the package confirmation response operation of the upgrade receiver until the last sub-packet data is sent.

[0177] In some embodiments, the upgrade action execution module 703 is used to:

[0178] During the packet receiving confirmation response operation of the upgrade receiver, if a device of the upgrade receiver does not respond with a verification pass message to the upgrade initiator within the second preset interval, the upgrade receiver is set as a silent party;

[0179] Remove the devices that have not responded to the verification pass message to the upgrade initiator from the array set S;

[0180] Update the serial number of the device in the array set S and determine whether the number of devices in the updated array set S is greater than 1. If it is greater than 1, continue to transmit the next sub-packet; otherwise, exit the upgrade operation;

[0181] The silent party is a device that does not send information through the bus and monitors information sent on the bus.

[0182] In some embodiments, the upgrade action execution module 703 is used to:

[0183] Complete the handshake upgrade operation between the upgrade initiator and each upgrade receiver, including:

[0184] Receive handshake packet information sent by the upgrade initiator, wherein the handshake packet information includes the firmware version number and firmware size of the upgrade initiator;

[0185] If the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade recipient's device, and the size of the upgrade initiator's firmware is less than or equal to the firmware size allowed by the upgrade recipient's device, the upgrade initiator sends an upgrade permission message to the communication bus.

[0186] Each module in the above-mentioned device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0187] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the various method steps involved in the above method embodiment when executing the computer program.

[0188] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the various method steps involved in the above method embodiment are implemented.

[0189] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the computer program implements the various method steps involved in the above method embodiment.

[0190] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0191] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0192] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent of the present application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A firmware upgrade method for a parallel system, characterized in that: The method comprises: Reading a firmware version number of each device connected to a first device bus, where the first device is any device in the parallel system; Determine the device roles of the first device and the respective devices based on the firmware version number of the first device, the firmware version numbers of the respective devices, and the bus communication addresses of all devices; wherein the device roles include an upgrade initiator, an upgrade receiver, and a silent party, the upgrade initiator and the silent party correspond to the devices with the highest firmware version numbers among the devices connected to the bus, the priority of the bus communication address of the upgrade initiator is greater than the priority of the bus communication address of the silent party, the firmware version number of the upgrade receiver is less than the firmware version number of the upgrade initiator and the firmware version number of the silent party, the array set S is determined by the devices corresponding to the upgrade initiator and the upgrade receiver, and the array set A is determined by the device corresponding to the silent party; Using the firmware information of the device corresponding to the upgrade initiator, the device corresponding to the upgrade receiver is upgraded. During the upgrade process, the silent party does not send information through the bus and monitors the information sent on the bus; Wherein, when the upgrade recipient is upgraded by using the upgrade initiator to send firmware information, a confirmation step is performed on the role of the upgrade initiator in the array set S and the integrity of the firmware information used for upgrading. When the confirmation of the role information of the upgrade initiator in the confirmation step fails, the role of the upgrade initiator is yielded to one of the silent parties based on the search of the array set A. In the yielding process, the target device with the highest priority of the bus communication address is first selected from the array set A and a yielding upgrade party identity message is sent to the target device. If the confirmation upgrade party identity message sent by the target device is received within a second preset time length, the target device is confirmed as the new upgrade initiator and the yielding process is completed. If the confirmation upgrade party identity message sent by the target device is not received within the second preset time length, the device with the highest priority of the next bus communication address is selected in the array set A as the new upgrade initiator, and so on until the yielding process is completed.

2. The method according to claim 1, characterized in that The determining the device roles of the first device and each of the devices based on the firmware version number of the first device, the firmware version numbers of the each of the devices, and the bus communication addresses of all the devices includes: If the firmware version number of any device in each device is smaller than that of the first device, determining the device role of the first device as the upgrade initiator and determining each device as the upgrade recipient; If the firmware version number of each of the devices is less than or equal to the firmware version number of the first device, and there is a second device among the devices with a firmware version number equal to the firmware version number of the first device, then the upgrade initiator, upgrade receiver and silent party are determined based on the priority of the bus communication addresses of the first device and the second device: if the priority of the bus communication address of the first device is greater than the priority of the bus communication address of the second device, then the first device is the upgrade initiator, the second device is the silent party, and the devices among the devices other than the second device are upgrade receivers; if the priority of the bus communication address of the second device is greater than the priority of the bus communication address of the first device, then the second device is the upgrade initiator, the first device is the silent party, and the devices among the devices other than the second device are upgrade receivers.

3. The method according to claim 2, characterized in that The determining array set S comprises: The upgrade initiator forms a first array in the array set S, wherein the first array stores a serial number 1, a firmware version number of the upgrade initiator, and a bus communication address of the upgrade initiator; The second array in the array set S is formed using the upgrade recipients, and the bus communication addresses of the devices corresponding to the upgrade recipients are sorted in descending order of priority to obtain multiple arrays starting with sequence number 2; wherein the second array stores a number with sequence number 2, a firmware version number of the device with sequence number 2 in the upgrade recipient, and a bus communication address of the device with sequence number 2 in the upgrade recipient, ..., and the Nth array stores a number with sequence number N, a firmware version number of the device with sequence number N in the upgrade recipient, and a bus communication address of the device with sequence number N in the upgrade recipient; The step of determining the array set A includes: The priorities of the bus communication addresses of the devices corresponding to the silent parties are sorted from large to small to obtain the array set A; the array set A stores the firmware version number and bus communication address of each silent party.

4. The method according to claim 3, characterized in that The step of confirming the role of the upgrade initiator and the integrity of the firmware information used for upgrading in the array set S includes: Compare the firmware version number of the upgrade initiator with the firmware version number of each upgrade recipient; If there is an upgrade receiver whose firmware version number is greater than that of the upgrade initiator, the upgrade receiver is deleted from the array set S, and the sequence numbers of all arrays in the array set S are updated in sequence to form a new array set S. If the number of remaining devices indicated in the new array set S is greater than 1, the confirmation is successful; The integrity of the firmware information used for the upgrade is confirmed based on the data in the Flash memory of the device of the upgrade initiator.

5. The method according to claim 4, characterized in that The confirmation of the integrity of the firmware information used for the upgrade based on the data in the Flash memory of the device of the upgrade initiator includes: Read the upgrade flag area content in the Flash of the upgrade initiator to obtain the preset verification code of the APP backup area firmware; Calculate the first verification code corresponding to the APP backup area firmware in the Flash of the upgrade initiator; If the preset verification code matches the first verification code, the integrity confirmation of the firmware information for upgrading is successful; otherwise, the integrity confirmation fails.

6. The method according to claim 5, characterized in that The step of yielding the role of the upgrade initiator to the silent party includes: In the array set A, the silent party with the highest ranking is searched out, and the silent party with the highest ranking is used as the updated upgrade initiator.

7. The method according to any one of claims 3 to 6, characterized in that Perform the firmware upgrade actions corresponding to the device role of each device, including: Complete the handshake upgrade operation between the upgrade initiator and each upgrade receiver; Initial sub-packet transmission operation of the upgrade initiator: sequentially unpack the firmware data in the APP backup area of ​​the upgrade initiator's Flash to obtain multiple sub-packet data with sequential numbers; send the first sub-packet data to the communication bus; The upgrade receiver's packet confirmation response operation: obtain the current sub-packet data on the communication bus; verify the current sub-packet data, store the successfully verified current sub-packet data in the APP backup area of ​​the Flash, and respond with a verification pass message to the upgrade initiator; if the verification of the current sub-packet data fails, request the retransmission of the current sub-packet data; The upgrade initiator performs another sub-packet transmission operation: within the first preset interval, after receiving the verification pass information of all upgrade receivers during the previous sub-packet transmission, it sends the next sub-packet data to the communication bus according to the number; then performs the package confirmation response operation of the upgrade receiver until the last sub-packet data is sent.

8. The method according to claim 7, characterized in that During the packet receiving confirmation response operation of the upgrade receiver, if a device of the upgrade receiver does not respond with a verification pass message to the upgrade initiator within the second preset interval, the upgrade receiver is set as a silent party; Remove the devices that have not responded to the verification pass message to the upgrade initiator from the array set S; Update the serial number of the device in the array set S and determine whether the number of devices in the updated array set S is greater than 1. If it is greater than 1, continue to transmit the next sub-packet; otherwise, exit the upgrade operation; The silent party is a device that does not send information through the bus and monitors information sent on the bus.

9. The method according to claim 7, characterized in that Complete the handshake upgrade operation between the upgrade initiator and each upgrade receiver, including: Receive handshake packet information sent by the upgrade initiator, wherein the handshake packet information includes the firmware version number and firmware size of the upgrade initiator; If the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade recipient's device, and the size of the upgrade initiator's firmware is less than or equal to the firmware size allowed by the upgrade recipient's device, the upgrade initiator sends an upgrade permission message to the communication bus.

10. A parallel system, characterized in that: The parallel system includes at least two devices communicating via a bus, each device including: A reading module is used to read the firmware version numbers of other devices connected to the communication bus; a device role determination module, which determines the device role of a device based on all firmware version numbers and bus communication addresses of all devices, wherein the device roles include an upgrade initiator, an upgrade receiver, and a silent party, the upgrade initiator and the silent party corresponding to the device with the highest firmware version number among the devices connected to the bus, the priority of the bus communication address of the upgrade initiator being greater than the priority of the bus communication address of the silent party, the firmware version number of the upgrade receiver being less than the firmware version number of the upgrade initiator and the firmware version number of the silent party, the array set S being determined by the devices corresponding to the upgrade initiator and the upgrade receiver, and the array set A being determined by the device corresponding to the silent party; An upgrade action execution module, configured to upgrade the device corresponding to the upgrade recipient using the firmware information of the device corresponding to the upgrade initiator. During the upgrade process, the silent party does not send information via the bus and monitors information sent on the bus. Wherein, when the upgrade recipient is upgraded by using the upgrade initiator to send firmware information, a confirmation step is performed on the role of the upgrade initiator in the array set S and the integrity of the firmware information used for upgrading. When the confirmation of the role information of the upgrade initiator in the confirmation step fails, the role of the upgrade initiator is yielded to one of the silent parties based on the search of the array set A. In the yielding process, the target device with the highest priority of the bus communication address is first selected from the array set A and a yielding upgrade party identity message is sent to the target device. If the confirmation upgrade party identity message sent by the target device is received within a second preset time length, the target device is confirmed as the new upgrade initiator and the yielding process is completed. If the confirmation upgrade party identity message sent by the target device is not received within the second preset time length, the device with the highest priority of the next bus communication address is selected in the array set A as the new upgrade initiator, and so on until the yielding process is completed.

Images