Firmware upgrading method of parallel system and parallel system

Abstract

The invention relates to a firmware upgrading method of a parallel system and the parallel system. The method comprises the following steps: reading a firmware version number of each device connected with a first device bus; determining device roles of the first device and each device based on the firmware version number of the first device, the firmware version number of each device and the bus communication addresses of all devices; wherein the device roles comprise an upgrade initiator, an upgrade receiver and a silence party; the firmware upgrading action corresponding to the device role of each device is executed, and the firmware information of the device corresponding to the upgrading initiator is used for upgrading the device corresponding to the upgrading receiver. By adopting the method, the upgrading failure risk caused by network instability can be avoided.

Description

Technical Field

[0001] This application relates to the technical field of firmware upgrade, and particularly to a firmware upgrade method and a parallel system for a parallel system. Background Art

[0002] In a parallel system, if the firmware versions of different devices are inconsistent, a series of problems will occur. Because different firmware versions have differences in function implementation methods, parameter settings, etc., the data processing capabilities and speeds of the corresponding devices are also different, and it is very easy to have a situation where the data processing speeds do not match. Moreover, once the system fails, due to the inconsistent software versions, the troubleshooting work will become extremely difficult.

[0003] In the traditional parallel system firmware upgrade method, taking device 1 and device 2 as examples, their firmware upgrade is completed through a local network connection. The specific process includes: first downloading the latest firmware from the server to the Internet of Things (IOT) module, and then the IOT module uses the serial port or Controller Area Network (CAN) communication method to send and transmit the firmware to device 1 and device 2, so as to achieve firmware upgrade. However, this parallel system firmware upgrade method has a very high dependence on the network. If there are problems such as poor network signal, instability or interruption in the environment where the system is located, it is very likely to cause the upgrade to fail, resulting in incomplete or incorrect data transmission, and then making the device fall into an unstable state or even unable to work properly. Summary of the Invention

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

[0005] In a first aspect, this application provides a firmware upgrade method for a parallel system, including:

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

[0007] 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, determining the device roles of the first device and each device; wherein, the device roles include an upgrade initiator, an upgrade receiver, and a silent party;

[0008] Performing a 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.

[0009] Second aspect, the present application further provides a parallel system, the parallel system includes at least two devices communicating through a bus, and each device includes:

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

[0011] A device role determination module, configured to determine the device role of the device based on all the firmware version numbers and the bus communication addresses of all devices, wherein the device role includes an upgrade initiator, an upgrade receiver, and a silent party;

[0012] An upgrade action execution module, configured to perform firmware upgrade work corresponding to the device role, and the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver.

[0013] The above firmware upgrade method and parallel system of the parallel system, the method includes: reading the firmware version numbers of each device connected to the bus of the first device; 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 role includes an upgrade initiator, an upgrade receiver, and a silent party; performing the firmware upgrade actions corresponding to the device roles 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 the devices autonomously identifying the firmware version and dynamically allocating upgrade roles, the system can use high-version devices as upgrade sources without relying on an external network, avoiding the risk of upgrade failure caused by unstable network. 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 will briefly introduce the drawings required to be used in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

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

[0016] Figure 2 It is a schematic diagram of the chip flash memory division of each device in a parallel system in an embodiment;

[0017] Figure 3 It is a schematic diagram of the firmware upgrade method flow of a parallel system in an embodiment;

[0018] Figure 4 It is a schematic diagram of the method flow for determining the device roles of the first device and each device in an embodiment;

[0019] Figure 5 Schematic diagram of the firmware upgrade method for another parallel system in an embodiment;

[0020] Figure 6 Schematic diagram of the process of performing the firmware upgrade actions corresponding to the device roles of each device in an embodiment;

[0021] Figure 7 Block diagram of each device in a parallel system in an embodiment. Detailed implementation manners

[0022] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application.

[0023] The firmware upgrade method for the parallel system provided by the embodiment of the present application can be applied to the schematic diagram of the parallel system as shown in Figure 1 In the parallel system, there may be multiple parallel devices. These devices may be of the same type, but the firmware version numbers of these devices may be inconsistent. As shown in Figure 1 In the figure, 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 Schematic diagram of the division of the chip flash (Flash) of each device in a parallel system. As shown in Figure 2 In the figure, the division of the chip Flash of each device includes:

[0025] Bootloader (BOOT) area: The area for storing the bootloader cannot be erased;

[0026] Upgrade flag area: The firmware size of the Application (APP) running area, the firmware version number of the APP running area, the 32-bit Cyclic Redundancy Check (crc32) of the firmware in the APP running area, the firmware size of the APP backup area, the firmware version number of the APP backup area, the crc32 of the firmware in the APP backup area;

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

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

[0029] In the embodiments of the present application, a device with a higher firmware version number can be used to upgrade a device with a lower firmware version number to implement the upgrade process. For example, Figure 1 in it, firmware information is sent from Device 3 to Device 1 for the upgrade process.

[0030] In an exemplary embodiment, as Figure 3 shown, a schematic diagram of a firmware upgrade method for a parallel system is provided. Taking this method applied to Figure 1 any device in the parallel system as an example, the following steps 301 to 303 are included:

[0031] 301. Read the firmware version numbers of the devices connected to the first device bus.

[0032] Among them, the above-mentioned first device can be any device in the parallel system.

[0033] In the embodiments of the present application, the devices in the parallel system are connected through a bus. Among them, the first device can read the firmware version numbers of the devices connected to the first device bus.

[0034] The above-mentioned bus can refer to a CAN bus.

[0035] Exemplarily, the first device can send a version query request to all connected devices through the CAN bus (for example, broadcast a CAN message in a specific format). After other devices receive the request, they return their own firmware version numbers through the CAN bus (for example, reply with a CAN message containing the version number). Among them, the CAN bus can support multi-device communication, and different device messages are distinguished by the CAN identifier (ID).

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

[0037] Among them, the device roles include an upgrade initiator, an upgrade receiver, and a silent party.

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

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

[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 duration, and then compare the read firmware version numbers of each device with its own firmware version number. Among them, 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 roles of the first device and each device.

[0041] Among them, the above-mentioned first preset duration can be a time window set by the system (such as 10 seconds), within which it is necessary to complete reading the firmware version numbers of all devices on the CAN bus.

[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 is found that there is a device with a higher firmware version number, it can be determined that itself becomes the upgrade recipient; if it is found that its own firmware version number is the highest, it can be determined that itself is the upgrade initiator.

[0043] Exemplarily, it is assumed 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 recipients.

[0044] 303. Execute the firmware upgrade actions corresponding to the device roles of each device.

[0045] Among them, the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade recipient.

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

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

[0048] Exemplarily, the above-mentioned firmware information may include, but is not limited to: firmware binary files, version numbers, check codes (such as CRC or hash values), and other metadata.

[0049] The above firmware upgrade method for the parallel system, through autonomous identification of firmware versions between devices and dynamic allocation of upgrade roles, the upgrade process completely relies on bus communication between devices, without the need to connect to an external server or cloud, and can use high-version devices as the upgrade source without relying on an external network, avoiding the risk of upgrade failure caused by unstable network and the risk of network latency or interruption.

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

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

[0052] In the embodiments 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 bus of the first device, the sizes of these firmware version numbers can be determined, and the corresponding device roles of each device can be determined based on the size judgment result.

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

[0054] In the embodiments of the present application, during the upgrade process, there is one and only one upgrade initiator, and the upgrade receivers may include one or more.

[0055] 402. Determine that the device role of the first device is the upgrade initiator and determine that each device is the 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 each other device is the upgrade receiver.

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

[0058] 403. Determine that there is a second device in each device whose firmware version number is equal to the firmware version number of the first device.

[0059] Exemplarily, assume that the parallel system includes device A, device B, and device C. Among them, the firmware version number of device A is 1.0, and the firmware version numbers of device B and device C are both 2.0. Then it can be seen that the firmware version numbers of device B and device C are equal. At this time, it is impossible to directly determine which of device B and device C is the upgrade initiator. It is necessary to further determine according to the priority of the bus communication addresses of device B and device C.

[0060] 404. Determine the upgrade initiator, upgrade receiver, and 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 all devices except 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, the second device is the upgrade initiator, the first device is the silent party, and all devices except the second device are upgrade receivers.

[0062] Among them, the above bus communication address can refer to the unique identifier of the device on the bus. For example, the node ID in the CAN bus can be called the CAN ID.

[0063] Exemplarily, the smaller the CAN ID value, the higher its priority. For example, if the CAN ID is 0x100, its priority is higher than that of the case where the CAN ID is 0x200. The priority of the bus communication address is used to arbitrate conflicts when determining the upgrade initiator when the firmware version numbers of multiple devices are equal.

[0064] Exemplarily, assume that the parallel system includes device A, device B, and device C. Among them, the firmware version number of device A is 1.0, and the firmware version numbers of device B and device C are both 2.0. Then it can be seen that the firmware version numbers of device B and device C are equal. At this time, it is impossible to directly determine which of device B and device C is the upgrade initiator. Among them, assume that the CAN ID of device B is 0x100 and the CAN ID of device C is 0x200. Then it can be determined that device B is the upgrade initiator, device A is the upgrade receiver, and device C is the silent party. Among them, the silent party is the device that does not send information through the bus and listens to the information sent on the bus.

[0065] In the above embodiment, when there are multiple devices in the system, first determine whether the first device is the highest version device based on the comparison of the firmware version numbers. If the version numbers of all devices are lower than that of the first device, directly specify the first device as the upgrade initiator and the remaining devices as the upgrade receivers; if there are devices with equal version numbers (such as the second device), then further arbitrate according to the priority of the bus communication addresses of the devices (for example, the smaller CAN ID value in the CAN bus has a higher priority) to ensure the determination of a unique upgrade initiator. This method realizes decentralized role allocation through local bus communication, which not only avoids the risk of upgrade interruption caused by network dependence, but also effectively reduces the bus load through the priority rule and the silent mechanism, ensuring the efficiency and reliability of the upgrade process, and is especially suitable for scenarios with strict requirements for real-time performance and stability such as industrial control.

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

[0067] 501. Read the firmware version numbers of all devices connected to the first device bus.

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

[0069] For the above steps 501 and 502, reference can be made to the descriptions of the above steps 301 and 302, which will not be elaborated here.

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

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

[0072] Among them, the array set S of all devices in the upgrade can be obtained based on the priority of the bus communication addresses of the upgrade recipients. The array set S of the above devices may include:

[0073] (1) The first array.

[0074] Among them, the first array in the array set S can be formed by the upgrade initiator. The first group stores the number 1, the firmware version number of the upgrade initiator, and the bus communication address of the upgrade initiator.

[0075] (2) The second array.

[0076] The second array in the array set S is formed by the upgrade recipient. The priorities of the bus communication addresses of the devices corresponding to the upgrade recipient are sorted from largest to smallest to obtain multiple arrays starting from the number 2; among them, the second array stores the number 2, the firmware version number of the device numbered 2 in the upgrade recipient, and the bus communication address of the device numbered 2 in the upgrade recipient,..., and the Nth array stores the number N, the firmware version number of the device numbered N in the upgrade recipient, and the bus communication address of the device numbered N in the upgrade recipient.

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

[0078] Table 1

[0079]

[0080] It should be noted that in Table 1 above, the row corresponding to No. 1 is the first array, and the information therein is that of the upgrade initiator. The information in other rows is the second array, and the information therein is that of the upgrade recipient. Each row is the information of one upgrade recipient.

[0081] In some embodiments, there is also a silent party. After determining the device roles of the first device and each device, the firmware upgrade method of the above parallel system may further include: obtaining an array set A. The array set A is formed by the silent party. Among them, the priorities of the bus communication addresses of the devices corresponding to the silent party are sorted from largest to smallest to obtain the array set A; the firmware version numbers and bus communication addresses of each silent party are stored in the array set A. The silent party may include one or more.

[0082] Exemplarily, the data in the above array set A may include the content shown in Table 2 below:

[0083] Table 2

[0084]

[0085] It should be noted that in Table 2 above, the firmware version numbers of each silent party device are the same as those of the upgrade initiator in Table 1, but the bus communication addresses are different. The priorities of the bus communication addresses in Table 2 are sorted from largest to smallest, and the row with the highest priority has the highest priority of the bus communication address among the silent parties.

[0086] 504. Reconfirm the role of the upgrade initiator in the array set S.

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

[0088] (1) The first confirmation step: Confirm the firmware version number of the upgrade initiator based on the data in the Flash in the device of the upgrade initiator.

[0089] Among them, confirming the firmware version number of the upgrade initiator based on the data in the Flash in the device of the upgrade initiator may include: comparing the firmware version number of the upgrade initiator with the firmware version number of each upgrade recipient; if there is an upgrade recipient whose firmware version number is greater than that of the upgrade initiator, the upgrade recipient is deleted from 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 successfully confirmed.

[0090] Among them, 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 numbers of each upgrade recipient respectively.

[0091] The above first confirmation step is to verify the legality of the firmware version number. Among them, during the verification process of the upgrade initiator, the upgrade initiator reads the firmware version number in its own Flash and compares it with the version numbers of all upgrade recipients. If it is found through comparison that the version of a certain upgrade recipient is higher, it means that the role of this upgrade recipient is determined incorrectly. At this time, the information of this upgrade recipient can be deleted from the array set S, and the array set S (update sequence number) can be updated again. If the number of remaining devices indicated in the new array set S > 1, then the following second confirmation step can be continued.

[0092] Exemplarily, assume that the initial information in the array set S is as shown in Table 3 below:

[0093] Table 3

[0094]

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

[0096] Table 4

[0097]

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

[0099] (2) When the first confirmation step is confirmed successfully, the second confirmation step is carried out: According to the data in the Flash in the device of the upgrade initiator, the integrity of the firmware information for upgrade is confirmed.

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

[0101] The above second confirmation step is for the verification of firmware integrity. Among them, the above preset check code can be CRC32. When the above preset check code matches the first check code, it can be determined that the firmware information is complete and the confirmation is successful. If they do not match, it means that the firmware is damaged or tampered with and the confirmation fails.

[0102] The above second confirmation process can prevent upgrade failure or system crash caused by firmware damage.

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

[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 the array set A, the role of the upgrade initiator is ceded to the silent party.

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

[0107] In some embodiments, when one of the first confirmation step or the second confirmation step fails, a new upgrade initiator is determined from the devices with the same firmware version number as the current upgrade initiator, and the role of the upgrade initiator is ceded.

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

[0109] Exemplarily, the current upgrade initiator may send a concession upgrade party identity message. After that, if the confirmation upgrade party identity message sent by the target device is received within the second preset time period, it is confirmed that the target device is the new upgrade initiator and the concession process is completed. If the confirmation upgrade party identity message sent by the target device is not received within the second preset time period, then it is necessary to further preferentially 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 concession process is completed.

[0110] Among them, the current upgrade initiator may carry the CAN ID of the target device in the confirmation upgrade party identity message. When the target device finds that the CAN ID carried in the message is the same as its own CAN ID after receiving the confirmation upgrade party identity message, it may reply to the current upgrade initiator with the confirmation upgrade party identity message.

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

[0112] Among them, the upgrade initiator may block-pack the firmware information and send it to the upgrade receiver through the bus. Correspondingly, the upgrade receiver may receive the data packet, verify the integrity of the data packet, write it into the Flash storage area, and upgrade its own firmware based on the firmware information after receiving the complete firmware information.

[0113] The above embodiments significantly improve the reliability of firmware upgrade through the structured array set management and the double confirmation mechanism. The device role can be determined depending on the hardware priority such as the CAN ID, and the verification of the firmware version number and the integrity check of the firmware information are performed through the software logic to ensure the credibility of the data, and finally a decentralized and highly robust firmware upgrade process is realized.

[0114] In an exemplary embodiment, as Figure 6 shown, a flowchart of executing the firmware upgrade action corresponding to the device role of each device is provided. As Figure 6 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, the handshake upgrade operation for the upgrade initiator and each upgrade recipient may include, but is not limited to: the upgrade initiator sending handshake packet information to the upgrade recipient, where the handshake packet information includes the firmware version number and firmware size of the upgrade initiator. After the upgrade recipient receives the sent handshake packet information, it can parse the handshake packet information to obtain the firmware version number and firmware size of the upgrade initiator. Then, compare the firmware version number of the upgrade initiator's device with the firmware version number of the upgrade recipient's device, and the firmware size of the upgrade initiator with the firmware size allowed by the upgrade recipient's device. 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 firmware size of the upgrade initiator is less than or equal to the firmware size allowed by the upgrade recipient's device, then 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 recipient's device, and the firmware size of the upgrade initiator is less than or equal to the firmware size allowed by the upgrade recipient's device, then at this time the upgrade recipient 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 recipient's device, or the firmware size of the upgrade initiator is greater than the firmware size allowed by the upgrade recipient's device, then at this time the upgrade recipient can send a reject upgrade message to the upgrade initiator.

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

[0119] Verifying whether the firmware version number of the upgrade initiator's device is greater than the firmware version number of the upgrade recipient's device as described above can ensure the effectiveness of the upgrade. Verifying whether the firmware size of the upgrade initiator is greater than the firmware size allowed by the upgrade recipient's device can avoid the situation of write overflow.

[0120] Exemplarily, assume 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, then the handshake is successful.

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

[0122] Among them, the firmware data in the APP backup area in the Flash of the upgrade initiator is unpacked sequentially to obtain multiple sub-packet data with sequential numbers; the first sub-packet data is sent to the communication bus.

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

[0124] In the embodiments of the present application, a sub - packet transmission mechanism is adopted to split the firmware into multiple data packets, reducing the amount of data transmitted at one time and adapting to the bus bandwidth limitation.

[0125] 603. The operation of the upgrade receiver for acknowledging the received packet and responding.

[0126] Among them, obtain the current sub - packet data on the communication bus; verify the current sub - packet data, store the current sub - packet data with successful verification into the APP backup area of the Flash, and respond with a verification - passed message to the upgrade initiator; when the verification of the current sub - packet data fails, request to re - send the current sub - packet data.

[0127] In some embodiments, the upgrade receiver calculates a checksum for the sub - packet data, such as CRC32, and compares the calculated checksum with the checksum carried in the packet for verification. When the two checksums are the same, it is determined that the verification is successful; when the two checksums are different, it is determined that the verification fails.

[0128] In some embodiments, during the operation of the upgrade receiver for acknowledging the received packet and responding, if a device of an upgrade receiver does not respond with a verification - passed message to the upgrade initiator within a second preset interval time, then the upgrade receiver is set as a silent party, where a silent party is a device that does not send information through the bus and listens to the information sent on the bus. In some embodiments, the device that does not respond with a verification - passed message to the upgrade initiator is removed from the array set S, the sequence numbers of the devices in the array set S are 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 transmission of subsequent sub - packets continues; otherwise, the upgrade operation exits; where, if there are 4 device information in the current array set S, assuming that the device with sequence number 2 is the device that does not respond with a verification - passed message to the upgrade initiator, then 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 sequence number 2, and the device originally with sequence number 4 is updated to sequence number 3; the number of devices in the updated array set S is 3, then the transmission of the next subsequent sub - packet continues; where the second preset interval time is greater than the first preset interval time.

[0129] Exemplarily, the upgrade initiator sends packet 1 to the communication bus for the first time. After the upgrade receiver receives packet 1 sent by the upgrade initiator, if the verification fails, it can send a re - transmission request; if it does not respond within the timeout period, it can be set as a silent party.

[0130] 604. The operation of the upgrade initiator for re - splitting and transmitting.

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

[0132] Exemplarily, after the upgrade receiver receives Packet 1 sent by the upgrade initiator and receives the verification passed information of all upgrade receivers within the first preset interval time, then Packet 2 can be sent to the communication bus at this time.

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

[0134] Device 1, with a CAN ID of 0x1111 and a firmware version number of 50;

[0135] Device 2, with a CAN ID of 0x2222 and a firmware version number of 50;

[0136] Device 3, with a CAN ID of 0x3333 and a firmware version number of 60;

[0137] Device 4, with a CAN ID of 0x4444 and a firmware version number of 60;

[0138] Device 5, with a CAN ID of 0x5555 and a firmware version number of 60;

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

[0140] 1. Device 1 and Device 2 are used as upgrade receivers, Device 3 and Device 4 are used as silent parties, and Device 5 is used as an upgrade initiator. Among them, the CAN ID of Device 5 is the largest among Device 3, Device 4, and Device 5, so it is used 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 cedes the identity of the upgrade initiator to Device 4; if Device 4 fails to verify the firmware in the APP backup area of the Flash, it cedes the identity of the upgrade initiator 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 ended.

[0142] 3. Device 5 sends a handshake upgrade instruction to Device 1 and Device 2, and Device 1 and Device 2 compare the handshake information with their own definitions to confirm whether the upgrade is satisfied.

[0143] Specifically, when determining whether the upgrade conditions are met, it can be based on the above firmware size and firmware version number, which will not be elaborated here.

[0144] Assume that both Device 1 and Device 2 meet the upgrade requirements, and both respond with messages allowing the upgrade. After receiving the responses from the upgrade recipients, Device 5 counts the number of responses and determines whether the number of responses is greater than 0. If it is greater than 0, Device 5 initiates a transmission start message and jumps to the BOOT area of the Flash. After receiving the transmission start message, Device 1 and Device 2 also jump to the BOOT area of the Flash to receive the firmware.

[0145] 4. Device 5 splits the firmware into N small packets for sub-packet transmission. After each packet of data is transmitted, it waits for Device 1 and Device 2 to respond that the verification is passed before sending the next packet until the firmware transmission is complete. If a device requests a retransmission during the transmission, the packet will be retransmitted; if it is determined that a device responds to exit the upgrade, or does not respond after multiple retransmissions, or still requests repetition after multiple retransmissions, the device will be removed from the record list, and the device does not need to be concerned about during the subsequent firmware transmission process. Here, assume that when transmitting the 5th packet of data in the firmware information, Device 2 responds to exit the upgrade and becomes a silent party. Then, starting from the 6th packet, Device 5 only cares about the response of Device 1 and no longer cares about Device 2.

[0146] 5. After the firmware is transmitted, Device 5 can send an end upgrade message. If Device 1 responds that it has received it, Device 5 jumps to the APP running area of the Flash, and the upgrade process ends. After receiving the end upgrade message, Device 2, Device 3, and Device 4 exit the silent state and no longer act as silent parties but communicate normally. If in the next upgrade process, a device with a higher firmware version number detects that the firmware version number of Device 2 is low, it will initiate a new round of upgrade for Device 2 again.

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

[0148] It should be understood that although the steps in the flowcharts involved in the above embodiments are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless specifically stated herein, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turns with at least a part of other steps or steps or stages in other steps.

[0149] The embodiment of the present application also provides a parallel system, which includes at least two devices communicating through a bus.

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

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

[0152] A device role determination module 702, configured to determine the device role of the device based on all the firmware version numbers and the bus communication addresses of all devices, where the device role includes an upgrade initiator, an upgrade receiver, and a silent party;

[0153] An upgrade action execution module 703, configured to perform firmware upgrade work corresponding to the device role, and the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver.

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

[0155] If the firmware version number of any device among all devices is less than that of the first device, determine the device role of the first device as the upgrade initiator and determine all the devices as upgrade receivers;

[0156] If the firmware version number of each device among the various devices is less than or equal to the firmware version number of the first device, and there exists a second device among the various devices whose firmware version number is equal to the firmware version number of the first device, then determine the upgrade initiator, upgrade receiver, and silent party 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 various 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, then the second device is the upgrade initiator, the first device is the silent party, and the devices among the various devices other than the second device are the upgrade receivers.

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

[0158] Form the first array in the array set S with the upgrade initiator, where the first array stores the number 1, the firmware version number of the upgrade initiator, and the bus communication address of the upgrade initiator;

[0159] Form the second array in the array set S with the upgrade receivers, sort the priorities of the bus communication addresses of the devices corresponding to the upgrade receivers in descending order to obtain multiple arrays starting from the number 2; where the second array stores the number 2, the firmware version number of the device with the number 2 among the upgrade receivers, and the bus communication address of the device with the number 2 among the upgrade receivers,..., the Nth array stores the number N, the firmware version number of the device with the number N among the upgrade receivers, and the bus communication address of the device with the number N among the upgrade receivers;

[0160] Form the array set A with the silent parties, where the priorities of the bus communication addresses of the devices corresponding to the silent parties are sorted in descending order to obtain the array set A; the array set A stores the firmware version numbers and bus communication addresses of each silent party.

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

[0162] The first confirmation step: Confirm the firmware version number of the upgrade initiator based on the data in the Flash of the upgrade initiator's device;

[0163] When the first confirmation step is successfully confirmed, perform the second confirmation step: Confirm the integrity of the firmware information for the upgrade based on the data in the Flash of the upgrade initiator's device;

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

[0165] Among them, the confirmation of the firmware version number of the upgrade initiator based on the data in the Flash of the upgrade initiator's device includes:

[0166] Compare the firmware version number of the upgrade initiator with the firmware version number of each upgrade recipient;

[0167] If there is a firmware version number of an upgrade recipient that is greater than the firmware version number of the upgrade initiator, delete the upgrade recipient from the array set S, sequentially update the sequence numbers of all arrays in the array set S, and form a new array set S. If the number of remaining devices indicated in the new array set S is greater than 1, the first confirmation step is successfully confirmed;

[0168] Among them, the confirmation of the integrity of the firmware information for the upgrade based on the data in the Flash of the upgrade initiator's device includes:

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

[0170] Calculate the first check code corresponding to the firmware in the APP backup area 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 integrity confirmation fails.

[0172] In some embodiments, the upgrade action execution module 703 is used for:

[0173] Complete the handshake upgrade operation between the upgrade initiator and each upgrade recipient;

[0174] The initial sub-packet transmission operation of the upgrade initiator: Sequentially unpack the firmware data in the APP backup area in the Flash of the upgrade initiator to obtain a plurality of sub-packet data with sequential numbers; Send the first sub-packet data to the communication bus;

[0175] Upgrade the packet reception confirmation response operation of the receiver: 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 passed message to the upgrade initiator; when the verification of the current sub-packet data fails, request the retransmission of the current sub-packet data.

[0176] Upgrade initiator's re-subpacket transmission operation: Within the first preset interval time, after receiving the verification passed messages from all upgrade receivers during the previous sub-packet transmission according to the numbers, send the next sub-packet data to the communication bus; then perform the packet reception 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 configured to:

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

[0179] Remove the device that does not respond with a verification passed message to the upgrade initiator from the array set S;

[0180] Update the sequence numbers of the devices 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 with the transmission of the next sub-packet, otherwise exit the upgrade operation;

[0181] Wherein, the said silent party is a device that does not send information through the bus and listens to the information sent on the bus.

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

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

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

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

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

[0187] In an exemplary embodiment, a computer device is provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, it implements each method step involved in the above method embodiment.

[0188] In an embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements each method step involved in the above method embodiment.

[0189] In an embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, it implements each method step involved in the above method embodiment.

[0190] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.

[0191] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0192] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to 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 includes: Reading the firmware version numbers of each device connected to the first device bus; 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, determining the device roles of the first device and each device; wherein, the device roles include an upgrade initiator, an upgrade receiver, and a silent party; Performing a 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.

2. The method according to claim 1, wherein The 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 includes: If the firmware version number of any device among each device is less 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 receiver; If the firmware version number of each device among each device is less than or equal to the firmware version number of the first device, and there is a second device among each device whose firmware version number is equal to the firmware version number of the first device, determining the upgrade initiator, the upgrade receiver, and the silent party 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, the first device is the upgrade initiator, the second device is the silent party, and the devices among each device 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 among each device other than the second device are the upgrade receivers.

3. The method according to claim 2, wherein After determining the device roles of the first device and each device, the firmware upgrade method of the parallel system further includes: determining an array set S and an array set A: Forming a first array in the array set S with the upgrade initiator, where the first array stores a number with the serial number 1, the firmware version number of the upgrade initiator, and the bus communication address of the upgrade initiator; Forming a second array in the array set S with the upgrade receivers, sorting the priorities of the bus communication addresses of the devices corresponding to the upgrade receivers in a descending order to obtain multiple arrays starting from the serial number 2; wherein, the second array stores a number with the serial number 2, the firmware version number of the device with the serial number 2 among the upgrade receivers, the bus communication address of the device with the serial number 2 among the upgrade receivers,..., the Nth array stores a number with the serial number N, the firmware version number of the device with the serial number N among the upgrade receivers, the bus communication address of the device with the serial number N among the upgrade receivers; Form the array set A in a silent manner, where the priorities of the bus communication addresses of the devices corresponding to the silent parties are sorted from largest to smallest to obtain the array set A; the firmware version numbers and bus communication addresses of each silent party are stored in the array set A.

4. The method according to claim 3, wherein The method further includes reconfirming the role of the upgrade initiator in the array set S: The first confirmation step: Confirm the firmware version number of the upgrade initiator based on the data in the Flash in the upgrade initiator's device. When the first confirmation step is successfully confirmed, perform the second confirmation step: Confirm the integrity of the firmware information for upgrade based on the data in the Flash in the upgrade initiator's device. When either the first confirmation step or the second confirmation step fails, based on the search of the array set A, the role of the upgrade initiator is ceded to the silent party.

5. The method according to claim 4, It is characterized in that wherein The confirmation of the firmware version number of the upgrade initiator based on the data in the Flash in the upgrade initiator's device includes: Compare the firmware version number of the upgrade initiator with the firmware version number of each upgrade recipient. If there is an upgrade recipient whose firmware version number is greater than that of the upgrade initiator, the upgrade recipient is deleted from the array set S, the sequence numbers of all arrays in the array set S are updated in sequence, and a new array set S is formed. If the number of remaining devices indicated in the new array set S is greater than 1, the first confirmation step is successfully confirmed. Among them, the confirmation of the integrity of the firmware information for upgrade based on the data in the Flash in the upgrade initiator's device includes: Read the content of the upgrade flag area in the Flash of the upgrade initiator to obtain the preset check code of the firmware in the APP backup area. Calculate the first check code corresponding to the firmware in the APP backup area in the Flash of the upgrade initiator. If the preset check code matches the first check code, the confirmation of the integrity of the firmware information for upgrade is successful; otherwise, the confirmation of integrity fails.

6. The method according to claim 5, wherein When the confirmation fails, based on the search of the array set A, ceding the role of the upgrade initiator to the silent party includes: In the array set A, search for the silent party with the highest ranking, and use the silent party with the highest ranking as the updated upgrade initiator.

7. The method according to any one of claims 3 to 6, characterized in that, Execute the firmware upgrade actions corresponding to the device roles of each device, including: Complete the handshake upgrade operation between the upgrade initiator and each upgrade recipient. The initial sub-packet transmission operation of the upgrade initiator: Sequentially unpack the firmware data in the APP backup area in the Flash of the upgrade initiator to obtain multiple sub-packet data with sequential numbers; send the first sub-packet data to the communication bus. The packet reception confirmation response operation of the upgrade recipient: Obtain the current sub-packet data on the communication bus; check the current sub-packet data, store the current sub-packet data with successful verification in the APP backup area of the Flash, and respond with a verification passed message to the upgrade initiator; when 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 passed 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 packet reception confirmation response operation of the upgrade receiver until the last sub-packet data is sent.

8. The method according to claim 7, wherein During the packet reception confirmation response operation of the upgrade receiver, if the device of an upgrade receiver does not respond with the verification passed information to the upgrade initiator within the second preset interval, then the upgrade receiver is set as a silent party; The device that does not respond with the verification passed information to the upgrade initiator is removed from the array set S; Update the serial numbers of the devices 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 the transmission of the subsequent next sub-packet, otherwise exit the upgrade operation; Wherein, the silent party is a device that does not send information through the bus and listens to the 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 the handshake packet information sent by the upgrade initiator, and the handshake packet information includes the firmware version number and firmware size of the upgrade initiator; If the firmware version number of the device of the upgrade initiator is greater than the firmware version number of the device of the upgrade receiver, and the firmware size of the upgrade initiator is less than or equal to the firmware size allowed by the device of the upgrade receiver, then 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 through a bus, and each device includes: A reading module for reading the firmware version numbers of other devices connected to the communication bus; A device role determination module for determining the device role of the device based on all the firmware version numbers and the bus communication addresses of all devices, wherein the device role includes an upgrade initiator, an upgrade receiver, and a silent party; An upgrade action execution module for performing the firmware upgrade work corresponding to the device role, and the firmware information of the device corresponding to the upgrade initiator is used to upgrade the device corresponding to the upgrade receiver.

Images