Unified cloud upgrading method based on multi-device serial communication

Abstract

The invention belongs to the technical field of equipment upgrading, and discloses a unified cloud upgrading method based on multi-equipment serial communication. Comprising the following steps: S1, sending a broadcast silence mode instruction; s2, selecting a first device; s3, controlling the equipment to enter a firmware downloading mode; s4, downloading firmware to the equipment; s5, a restart instruction is sent to restart the device to operate the new firmware; s6, checking an upgrading result and controlling the equipment to enter a silent mode; s7, checking and switching equipment; s8, quitting the silent mode; according to the method, operation and maintenance personnel do not need to personally arrive at the place where the equipment is located for operation, batch orderly firmware upgrading can be conveniently and rapidly conducted on the equipment in a remote mode, the equipment supports running firmware version rollback, and it can be ensured that the equipment can run the last version of stable firmware once a hidden fault is triggered after new firmware runs.

Description

Technical Field

[0001] The present invention relates to the technical field of device upgrade, and more specifically, to a unified cloud upgrade method based on multi-device serial communication. Background Art

[0002] Embedded devices are increasingly used in the fields of industry, agriculture, education, national defense, scientific research, and daily life due to their small size, high reliability, powerful functions, flexibility, and convenience. With the frequent use and functional iteration of smart terminal electronic products, firmware upgrades have become particularly important; the current mainstream download solutions are: the host reserves a dedicated burning port (swd), and the firmware is downloaded to the machine with a programmer supported by the chip; the host reserves a USB interface, and the upgrade firmware can be placed in a U disk first, and then the U disk is inserted into the device to be upgraded to complete the upgrade; the host reserves a network port, and the firmware is uploaded to the host through the web page by logging into the host web background to complete the upgrade.

[0003] Existing embedded device firmware upgrade solutions often have the following defects:

[0004] Solutions with dedicated burning ports (such as SWD) and USB interfaces require devices to have specific hardware interfaces, which limits the versatility and applicability of upgrade solutions; users are required to perform physical operations, such as inserting a USB flash drive or connecting a programmer, which increases the complexity of operations; uploading firmware through the Web background may face network security threats (such as data leakage, malware attacks, etc.); in multi-device or large-scale deployment scenarios, upgrading each device one by one is inefficient, time-consuming and error-prone; and existing solutions lack effective verification of firmware integrity and source, which makes the firmware at risk of being tampered with.

[0005] In view of this, the present invention proposes a unified cloud upgrade method based on multi-device serial communication to solve the above problems. Summary of the invention

[0006] In order to overcome the above-mentioned defects of the prior art and to achieve the above-mentioned purpose, the present invention provides the following technical solution: a unified cloud upgrade method based on multi-device serial communication, comprising the following steps:

[0007] S1, send broadcast silent mode command;

[0008] S2, select the first device;

[0009] S3, control the device to enter firmware download mode;

[0010] S4. Download the firmware to the device;

[0011] S5. Send a restart command to restart the device to run the new firmware;

[0012] S6. Check the upgrade result and control the device to enter silent mode;

[0013] S7, check and switch equipment;

[0014] S8. Exit silent mode.

[0015] Furthermore, before S1, it is necessary to build an upgrade system, create a Flash partition inside the device, and perform a firmware upgrade:

[0016] The upgrade system includes a cloud server, a transfer controller, a communication bus (serial device communication bus) and a serial device;

[0017] The internal Flash partition of the device includes a bootload partition, a program storage area A, a program storage area B and an operation parameter recording area;

[0018] The firmware upgrade includes firmware uploading, firmware caching and firmware updating.

[0019] Further, the step of sending the broadcast silent mode instruction includes:

[0020] All devices are connected to the communication bus, and the communication bus is communicating normally;

[0021] Then, a silent mode command is sent to all devices on the communication bus through broadcast mode;

[0022] Send data read commands to the devices stored in the device online list one by one, and determine whether the silent mode setting is successful by whether the device replies to the read command.

[0023] Furthermore, the step of selecting the first device includes:

[0024] A random number is randomly generated by the transfer controller, and the random number is divided by the number of serial devices that have not been upgraded. The remainder is taken as the device index. If the remainder is zero, the first device is selected, and if the remainder is one, the second device is selected and the above operation is repeated until all devices have been upgraded;

[0025] Record the current program version status of the selected device, the program version status to be upgraded, and whether the upgrade is successful or not.

[0026] Furthermore, the step of controlling the device to enter a firmware download (bootload) mode comprises:

[0027] Send a command to the selected device to enter firmware download mode;

[0028] The transfer controller receives an upgrade preparation signal from a serial device with a specific address on the communication bus within a preset specified time, and then jumps to the next step of downloading the firmware.

[0029] Furthermore, the step of downloading the firmware to the device includes S100, firmware encryption preparation; S200, random transmission of the firmware; S300, integrity verification;

[0030] In S100, the transit controller divides the firmware into a number of program data segments of equal length, assigns a sequence number and a random number to each program data segment, divides the random number by four, takes the remainder as the encryption method, and uses the quotient as the encryption factor, and substitutes the encryption method and the encryption factor into the preset encryption algorithm to perform encryption operations on the divided program data segments;

[0031] In S200, check whether the transmission of all program data segments is completed, if yes, jump to S300, if not, continue to transmit;

[0032] Before sending out the encrypted firmware program data segment each time, the transfer controller randomly assigns a weight value to all unsent program data segments, selects the program data segment with the largest weight and sends the data packet first. The content of the sent data packet includes the program data segment number, the encrypted random number, the encrypted program data and the CRC check code of the first three.

[0033] After receiving the above four items, the device bootload first determines whether the data packet is correct based on the CRC check code. If it is not correct, it notifies the transfer controller to resend it. If it is correct, it first decrypts the encrypted program data according to the encryption method and encryption factor generated by the received encrypted random number, and then obtains the decrypted program data segment;

[0034] The bootloader then calculates the CRC checksum based on the decrypted program data segment and returns the CRC checksum along with the program data segment number to the relay controller;

[0035] The relay controller calculates the CRC checksum of the program data segment according to the program data segment number in the data packet returned by Bootload. If the calculated checksum is consistent with the checksum returned by Bootload, it means that the transmission and decryption of the program data segment are normal. Otherwise, it is abnormal. Then the relay controller informs Bootload that the program data segment is valid data, otherwise it is invalid data.

[0036] After receiving the valid data, the bootloader first determines the write location of the segmented decryption program according to the current program storage area mark in the running parameter record area;

[0037] Subsequently, according to the program data segment number, the decrypted program data segment is written into the address of the relative address offset of the corresponding program storage area, and then the program data segment storage flag of the corresponding program storage area of ​​the running parameter data record is set, and jump to S200;

[0038] If invalid data is received, the data packet is discarded and the receiving data continues to jump to S200;

[0039] In S300, after all segmented programs are encrypted, transmitted and decrypted, cached, the relay controller first notifies the firmware that the transmission is completed. After receiving the transmission completion signal, Bootload first checks whether there is an unstored flag in the program data segment storage flag interval. If there is an unstored flag, the unstored program segment number is sent to the relay controller, and jumps to S200 to receive the unstored program data segment.

[0040] If the Bootload checks that there is no unstored mark in the program data segment storage flag interval, it means that the program firmware receiving interval is continuous, and the length calculation, CRC check, and MD5 check can be performed on the program storage data interval, and the above calculation results are sent to the transfer controller;

[0041] After receiving the information returned by Bootload, the relay controller uses the same method to perform the same calculation on the program data segment and compares the calculation result with the information returned by Bootload. If the comparison result is consistent, it indicates that the firmware transmission is successful and jumps to S5. If the result is inconsistent, it indicates that the transmission failed, then jump to S200 to retransmit.

[0042] Furthermore, the step of restarting the device to run the new firmware and send a restart instruction includes:

[0043] The relay controller sends a restart command to the serial device. After receiving the restart command, Bootload first changes the host restart identifier in the operating parameter record area from upgrade entry restart to upgrade completion restart, and then switches the current program storage area mark in the operating parameter record area to the program storage area saved after the new program is downloaded, and then executes the software restart and monitors the device restart process;

[0044] Among them, the monitoring methods are:

[0045] Bootload reads the host restart identifier when it starts up, and detects that it is a restart after the upgrade is completed. First, based on the changed current program storage area flag, it calculates whether the file size check code and other information of the program stored in the corresponding program storage area are consistent with the relevant information recorded in the running parameter recording area. If the check results are consistent, it means that the program is complete, and the program is loaded from the corresponding program storage area to run, and jumps to S6; if the check results are inconsistent, it means that the program is incomplete, and the host restart identifier in the running parameter recording area is changed from upgrade completion restart to normal restart, and the current running storage area flag is switched back to the storage area flag corresponding to the upgrade to load the original program.

[0046] Furthermore, the step of checking the upgrade result and controlling the device to enter the silent mode includes:

[0047] The relay controller first reads the serial device firmware version number, and after successfully reading the device firmware version number, sends a silent mode command to the device alone;

[0048] After the serial device restarts, the relay controller first reads the device firmware version number. If the read device firmware version number is consistent with the version before the upgrade, it means the upgrade has failed. If the read device firmware version number is consistent with the current upgrade version, it means the upgrade has succeeded.

[0049] According to the check and upgrade result, the device upgrade status of the device in the online device list is marked as upgraded or failed;

[0050] If the program upgrade fails, query the number of repeated upgrades of the current device. If the number of repeated upgrades is less than the preset maximum number of repeated upgrades, add one to the number of repeated upgrades and jump to S3 to upgrade again. If the number of repeated upgrades is more than three times, notify the operation and maintenance personnel to handle it manually later.

[0051] If the upgrade is successful, execute S7.

[0052] Furthermore, the step of checking and switching the device includes:

[0053] Check whether there are other devices on the communication bus that need to be upgraded. If there are devices to be upgraded, randomly assign different weight values ​​to each device that has not completed the upgrade;

[0054] Select the device with the largest weight value, and repeat S3 to S6 to upgrade the firmware of the device. If there is no device that needs to be upgraded, it means that the device upgrade is completed, and then run S8.

[0055] Furthermore, the step of exiting the silent mode includes:

[0056] When all devices have been upgraded, all devices are notified to exit silent mode through broadcast commands;

[0057] Wait for all devices to return confirmation signals, mark all devices as upgraded, record the time when the upgrade is completed, and synchronize the information to the cloud server.

[0058] The technical effects and advantages of the unified cloud upgrade method based on multi-device serial communication of the present invention are as follows:

[0059] The present invention adds a device switching operation, so that when the upgraded firmware is transmitted to the target device via the communication bus, interference of other devices on the communication bus on the firmware transmission is avoided, thereby improving the success rate and stability of the firmware upgrade; and the firmware upgrade can be completed remotely without manual on-site physical operation of the equipment, making the firmware upgrade more efficient and saving labor costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 A schematic diagram of a unified cloud upgrade method based on multi-device serial communication of the present invention;

[0061] Figure 2 It is a schematic diagram of the connection between the device connection diagram of the present invention and the communication bus (communication bus);

[0062] Figure 3 It is a schematic diagram of the process of upgrading the equipment of the present invention. DETAILED DESCRIPTION

[0063] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0064] Example 1

[0065] See also Figures 1 to 3 As shown, the unified cloud upgrade method based on multi-device serial communication described in this embodiment includes the following steps:

[0066] S1, send broadcast silent mode command;

[0067] S2, select the first device;

[0068] S3, control the device to enter firmware download mode;

[0069] S4. Download the firmware to the device;

[0070] S5. Send a restart command to restart the device to run the new firmware;

[0071] S6. Check the upgrade result and control the device to enter silent mode;

[0072] S7, check and switch equipment;

[0073] S8. Exit silent mode.

[0074] Furthermore, before S1, you need to build an upgrade system, create a Flash partition inside the device, and upgrade the firmware:

[0075] The upgrade system includes a cloud server, a transfer controller (serial device transfer controller), a communication bus (serial device communication bus) and a serial device;

[0076] The internal Flash partition of the device includes the bootload partition, program storage area A, program storage area B and operation parameter recording area (among which, program storage area A and B are used as the main program storage area and the backup program storage area respectively. As the firmware upgrade progresses, their identities will change alternately; the operation parameter recording area mainly records the host restart identifier (normal restart, upgrade entry restart, upgrade completion restart, firmware abnormal restart), the current operation storage area flag (pointing to A or B), the file size of the firmware program stored in the AB storage areas respectively, the program version, CRC, MD5 algorithm checksum, program data segment storage flag and other information);

[0077] Firmware upgrade includes firmware upload, firmware cache and firmware update.

[0078] Specifically, the cloud server is usually deployed synchronously when the project is delivered. After the cloud server is deployed, the operation and maintenance personnel can enter the URL anywhere to open the cloud server, upload the firmware as needed, and batch select the serial devices mounted on the serial port of the transit controller for firmware upgrade; the transit controller includes an Ethernet port and a serial port. The Ethernet port can communicate with the cloud server deployed by the project through TCP, and the serial port connects multiple serial devices with different addresses through a serial communication bus; the serial communication bus provides a communication path for information exchange between the transit controller and the serial device. The serial device is responsible for data acquisition and signal control, and reports operating data and receives control instructions when the transit controller actively inquires; the device supports running firmware version rollback (rollback), which ensures that when the new firmware has no hidden fault action, the device can run the previous stable firmware;

[0079] Firmware uploading includes the operation and maintenance personnel entering the URL and filling in the account and password in the browser according to the pre-assigned account and password, uploading the device firmware using websocket encryption, and the operation and maintenance personnel selecting the transfer controller and clicking the upgrade button to start the upgrade process; firmware caching includes the operation and maintenance personnel clicking the upgrade button in the background of the cloud server, the transfer controller receiving the firmware upgrade signal, the transfer controller downloading the device firmware through the websocket protocol and caching it in the memory for firmware upgrade; updating firmware includes reporting the serial device status. The transfer controller actively reports the working mode (normal mode, silent mode, download mode) of the serial peripheral connected to the serial communication bus, the firmware version number, the upgrade status (to be upgraded, upgrading, upgrade completed), the device address and the device model every 1 second.

[0080] Further, the step of sending a broadcast silent mode instruction includes:

[0081] All devices are connected to the communication bus, and the communication bus is communicating normally (in the full address range, data read instructions are sent to the addresses one by one, and the existence of the device at the address is determined based on whether there is data returned. The devices on the communication bus are recorded in the online list of the management system equipment to facilitate subsequent upgrade operations; and the online device information is sent to the cloud server to facilitate the operation and maintenance personnel to intuitively display the current serial device status);

[0082] Then, a silent mode command (the silent mode command includes a clear identifier, such as "enter silent mode") is sent to all devices on the communication bus through broadcast mode (the address segment data in the control command is set to 0, indicating broadcast mode);

[0083] Send data read commands to the devices stored in the device online list one by one. Whether the silent mode setting is successful can be determined by whether the device replies to the read command. (When the device enters silent mode, it can receive control commands normally, but will not return response data packets. If the control end receives a response data packet returned by a certain device, it proves that the device has not entered silent mode as expected. You can also send a control command separately to make it enter silent mode and confirm it again. Then, it can be ensured that all devices have received the command and are ready to enter silent mode. When the devices are upgraded one by one later, the devices that are not in the upgrade state will not cause communication interference to the receiving process of the device that is executing the firmware receiving action. In addition to not responding to the control command data packet, the original software and hardware business logic of the device in silent mode works normally. It has little impact on the production environment).

[0084] Furthermore, the step of selecting the first device includes:

[0085] A random number is randomly generated by the transfer controller, and the random number is divided by the number of serial devices that have not been upgraded. The remainder is taken as the device index. If the remainder is zero, the first device is selected, and if the remainder is one, the second device is selected to perform the above operation (and so on) until all devices have been upgraded;

[0086] Record the current program version status of the selected device, the program version status to be upgraded, and the upgrade success or failure status (in order to track the device upgrade progress).

[0087] Furthermore, the step of controlling the device to enter the firmware download mode includes:

[0088] Send a command to the selected device to enter the firmware download mode (wherein, after receiving the command, the device changes the host restart identifier in the operating parameter recording area from normal restart to upgrade restart, and then executes the software restart action; Bootload reads the host restart identifier when it is turned on, detects it as upgrade restart, and then enters the upgrade download mode; after entering the download mode, Bootload outputs an upgrade preparation signal containing the device address information on the communication bus to indicate that Bootload has entered the upgrade download mode);

[0089] When the transfer controller receives an upgrade preparation signal from a serial device with a specific address on the communication bus within a preset specified time (generally set to 5 seconds) (indicating that it has successfully entered the firmware download mode), it can jump to the next step of downloading the firmware.

[0090] Furthermore, the step of downloading the firmware to the device includes:

[0091] S100, firmware encryption preparation; S200, out-of-order firmware transmission; S300, integrity verification;

[0092] In S100, the transit controller divides the firmware (firmware file) into several program data segments of equal length, and assigns a sequence number and a random number to each program data segment (wherein, it is necessary to ensure that the firmware file is the latest and compatible with the device); the transit controller divides the random number by four, takes the remainder as the encryption method, and uses the quotient as the encryption factor, and uses the encryption method and the encryption factor to substitute into the preset encryption algorithm to perform encryption operations on the split program data segments (the encryption algorithm can be AES, DES, etc., which combines the encryption factor and the encryption method to implement firmware encryption);

[0093] In S200, check whether all program data segments have been transmitted. If yes, jump to S300. If not, continue to transmit. Before sending the encrypted firmware program data segment each time, the transit controller will randomly assign a weight value to all unsent program data segments, and select the program data segment with the largest weight to send first (the content of the sent data packet includes the program data segment number, the encrypted random number, the encrypted program data, and the CRC check code of the first three. After the device bootload receives the above four items, it first determines whether the three data (program data segment number, encrypted random number, encrypted program data) are correct according to the CRC check code; if not, notify the transit controller to resend. If correct, first generate the encryption method and encryption factor in the firmware preparation work according to the received encrypted random number, and decrypt the encrypted program data according to the two to obtain the real program data segment;

[0094] The bootloader then calculates the CRC checksum based on the decrypted program data segment and returns the checksum along with the program data segment number to the relay controller;

[0095] The relay controller calculates the CRC checksum of the program data segment according to the program data segment number in the data packet returned by Bootload. If the calculated checksum is consistent with the checksum returned by Bootload, it means that the transmission and decryption of the program data segment are normal. Otherwise, it is abnormal. Then the relay controller informs Bootload that the program data segment is valid data; otherwise, it is invalid data.

[0096] After receiving the valid data, bootloader first determines the write position of the segmented decryption program according to the current program storage area mark in the running parameter record area (if the current program storage area mark is A, the segmented program is written to program storage area B; if the current program storage area mark is B, the segmented program is written to program storage area A);

[0097] Subsequently, according to the program data segment number, the decrypted program data segment is written into the address of the relative address offset of the corresponding program storage area, and then the program data segment storage flag of the corresponding program storage area is set (updated or set) to run the parameter data record, and jump to S200; if an invalid signal is received, the data packet is discarded and the data continues to be received and jump to S200;

[0098] In S300, after all segmented programs are encrypted, transmitted and decrypted, cached, the relay controller first notifies the firmware that the transmission is completed. After receiving the transmission completion signal, Bootload first checks whether there is an unstored flag in the program data segment storage flag interval. If there is an unstored flag, the unstored program segment number is sent to the relay controller, and jumps to S200 to receive the unstored program data segment.

[0099] If the Bootload checks that there is no unstored mark in the program data segment storage flag interval, it means that the program firmware receiving interval is continuous, and the length calculation, CRC check, and MD5 check can be performed on the program storage data interval, and the above calculation results are sent to the transfer controller;

[0100] After receiving the information returned by Bootload, the transit controller uses the same method to perform the same calculation on the program data segment (original program data), and compares the calculation result with the information returned by Bootload. If the comparison result is consistent, it means that the firmware transmission is successful (Bootload writes the long whisker length, program version, verification code and other information of the newly downloaded program to the data recording position of the corresponding program storage area in the running parameter recording area) and jumps to S5; if the results are inconsistent, it means that the transmission has failed, and jumps to S200 to retransmit.

[0101] Further, the step of sending a restart instruction to restart the device to run the new firmware includes:

[0102] The relay controller sends a restart command to the serial device Bootload. After receiving the restart command, Bootload first changes the host restart identifier in the operating parameter record area from upgrade entry restart to upgrade completion restart, and then switches the current program storage area flag in the operating parameter record area to the program storage area saved after the new program is downloaded (so that it can load and run the new firmware), and then executes the software restart and monitors the device restart process (to ensure that no abnormalities occur);

[0103] The monitoring method is as follows: Bootload reads the host restart identifier when starting up, and detects that it is an upgrade completion restart. First, based on the changed current program storage area flag, calculate whether the file size check code and other information of the program stored in the corresponding program storage area are consistent with the relevant information recorded in the running parameter recording area (and then judge the integrity of the program storage). If the verification results are consistent, it means that the program is complete, and the program is loaded from the corresponding program storage area to run, and jump to S6; if the verification results are inconsistent, it means that the program is incomplete, and the host restart identifier of the running parameter recording area is changed from upgrade completion restart to normal restart, and the current running storage area flag is switched back to the storage area flag corresponding to the upgrade to load the original program.

[0104] Furthermore, the steps of checking the upgrade result and controlling the device to enter the silent mode include:

[0105] The relay controller first reads the serial device firmware version number;

[0106] After successfully reading the device firmware version number, send a silent mode command to the device alone (to prevent it from interfering with the subsequent upgrade process of other devices);

[0107] After the serial device restarts, the relay controller first reads the device firmware version number. If the read device firmware version number is consistent with the version before the upgrade, it means the upgrade has failed. If the read device firmware version number is consistent with the current upgrade version, it means the upgrade has succeeded.

[0108] According to the check and upgrade result, the device upgrade status of the device in the online device list is marked as upgraded or failed;

[0109] If the program upgrade fails, query the number of repeated upgrades of the current device. If the number of repeated upgrades is less than the preset maximum number of repeated upgrades (usually three or five times), add one to the number of repeated upgrades and jump to S3 to upgrade again.

[0110] If the upgrade is repeated more than three times, the operation and maintenance personnel will be notified (through the cloud server browser interface) for subsequent manual processing (this probability is low and can be classified as exception processing);

[0111] If the upgrade is successful, execute S7.

[0112] Furthermore, the steps of checking and switching the device include:

[0113] Check whether there are other devices on the communication bus that need to be upgraded (obtain the upgrade status recorded in the online device information);

[0114] If there are devices to be upgraded, a different weight value will be randomly assigned to each device that has not completed the upgrade;

[0115] Select the device with the largest weight value, and repeat S3 to S6 to upgrade the firmware of the device. If there is no device that needs to be upgraded, it means that the device upgrade is completed, and then run S8.

[0116] Furthermore, the step of exiting the silent mode includes:

[0117] When all devices have been upgraded, notify all devices to exit silent mode through broadcast instructions (to ensure that they have exited silent mode and are ready to run business logic);

[0118] Wait for all devices to return confirmation signals, mark all devices as upgraded, record the time when the upgrade is completed, and synchronize the information to the cloud server. Then, display the upgrade results to the operation and maintenance personnel through the browser interface.

[0119] In this embodiment, by adding operations such as device switching, when upgrading the firmware, while transmitting it to the target device via the communication bus (business communication bus), interference with the firmware transmission by other devices on the communication bus is avoided, thereby improving the success rate and stability of the firmware upgrade; and the firmware upgrade can be completed remotely without the need for manual on-site physical operation of the equipment, making the firmware upgrade more efficient; at the same time, labor costs are saved, manual configuration time can be reduced, and construction costs are reduced; problems caused by address configuration errors are avoided, and the overall performance of the system is improved; even when the network topology changes, device management and maintenance can be easily performed; and a more intelligent and efficient solution can be provided for applications such as smart buildings and smart computer rooms. Furthermore, the present invention can avoid manual on-site physical repetitive operations, speed up the firmware upgrade time of a single device and the total time for batch device upgrades.

[0120] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0121] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only one, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0122] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

[0123] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A unified cloud upgrade method based on multi-device serial communication, characterized in that: The following steps are involved: S1, send broadcast silent mode command; S2, select the first device; S3, control the device to enter firmware download mode; S4. Download the firmware to the device; S5. Send a restart command to restart the device to run the new firmware; S6. Check the upgrade result and control the device to enter silent mode; S7, check and switch equipment; S8. Exit silent mode.

2. A unified cloud upgrade method based on multi-device serial communication according to claim 1, characterized in that: Before S1, you need to build an upgrade system, create a Flash partition inside the device, and upgrade the firmware: The upgrade system includes a cloud server, a transfer controller, a communication bus and a serial device; The internal Flash partition of the device includes a bootload partition, a program storage area A, a program storage area B and an operation parameter recording area; The firmware upgrade includes firmware uploading, firmware caching and firmware updating.

3. A unified cloud upgrade method based on multi-device serial communication according to claim 2, characterized in that: The step of sending a broadcast silent mode instruction comprises: All devices are connected to the communication bus, and the communication bus is normal; Then, a silent mode command is sent to all devices on the communication bus through broadcast mode; Send data read commands to the devices stored in the device online list one by one, and determine whether the silent mode setting is successful by whether the device replies to the read command.

4. A unified cloud upgrade method based on multi-device serial communication according to claim 3, characterized in that: The step of selecting the first device comprises: A random number is randomly generated by the transfer controller, and the random number is divided by the number of serial devices that have not been upgraded. The remainder is taken as the device index. If the remainder is zero, the first device is selected, and if the remainder is one, the second device is selected and the above operation is repeated until all devices have been upgraded; Record the current program version status of the selected device, the program version status to be upgraded, and whether the upgrade is successful or not.

5. A unified cloud upgrade method based on multi-device serial communication according to claim 4, characterized in that: The step of controlling the device to enter the firmware download mode comprises: Send a command to the selected device to enter the firmware download bootload mode; The transfer controller receives an upgrade preparation signal from a serial device with a specific address on the communication bus within a preset specified time, and then jumps to the next step of downloading the firmware.

6. A unified cloud upgrade method based on multi-device serial communication according to claim 5, characterized in that: The steps of downloading the firmware to the device include S100, firmware encryption preparation; S200, random transmission of the firmware; S300, integrity verification; In S100, the transit controller divides the firmware into a number of program data segments of equal length, assigns a sequence number and a random number to each program data segment, divides the random number by four, takes the remainder as the encryption method, and uses the quotient as the encryption factor, and substitutes the encryption method and the encryption factor into the preset encryption algorithm to perform encryption operations on the divided program data segments; In S200, check whether the transmission of all program data segments is completed, if yes, jump to S300, if not, continue to transmit; Before sending out the encrypted firmware program data segment each time, the transfer controller randomly assigns a weight value to all unsent program data segments, selects the program data segment with the largest weight and sends the data packet first. The content of the sent data packet includes the program data segment number, the encrypted random number, the encrypted program data and the CRC check code of the first three. After receiving the above four items, the device bootload first determines whether the data packet is correct based on the CRC check code. If it is not correct, it notifies the transfer controller to resend it. If it is correct, it first decrypts the encrypted program data according to the encryption method and encryption factor generated by the received encrypted random number, and then obtains the decrypted program data segment; The bootloader then calculates the CRC checksum based on the decrypted program data segment and returns the CRC checksum along with the program data segment number to the relay controller; The relay controller calculates the CRC checksum of the program data segment according to the program data segment number in the data packet returned by Bootload. If the calculated checksum is consistent with the checksum returned by Bootload, it means that the transmission and decryption of the program data segment are normal. Otherwise, it is abnormal. Then the relay controller informs Bootload that the program data segment is valid data, otherwise it is invalid data. After receiving the valid data, the bootloader first determines the write location of the segmented decryption program according to the current program storage area mark in the running parameter record area; Subsequently, according to the program data segment number, the decrypted program data segment is written into the address of the relative address offset of the corresponding program storage area, and then the program data segment storage flag of the corresponding program storage area of ​​the running parameter data record is set, and jump to S200; If invalid data is received, the data packet is discarded and the receiving data continues to jump to S200; In S300, after all segmented programs are encrypted, transmitted and decrypted, cached, the relay controller first notifies the firmware that the transmission is completed. After receiving the transmission completion signal, Bootload first checks whether there is an unstored flag in the program data segment storage flag interval. If there is an unstored flag, the unstored program segment number is sent to the relay controller, and jumps to S200 to receive the unstored program data segment. If the Bootload checks that there is no unstored mark in the program data segment storage flag interval, it means that the program firmware receiving interval is continuous, and the length calculation, CRC check, and MD5 check can be performed on the program storage data interval, and the above calculation results are sent to the transfer controller; After receiving the information returned by Bootload, the relay controller uses the same method to perform the same calculation on the program data segment and compares the calculation result with the information returned by Bootload. If the comparison result is consistent, it indicates that the firmware transmission is successful and jumps to S5. If the result is inconsistent, it indicates that the transmission failed, then jump to S200 to retransmit.

7. A unified cloud upgrade method based on multi-device serial communication according to claim 6, characterized in that: The step of restarting the device to run the new firmware and send a restart instruction includes: The relay controller sends a restart command to the serial device. After receiving the restart command, Bootload first changes the host restart identifier in the operating parameter record area from upgrade entry restart to upgrade completion restart, and then switches the current program storage area mark in the operating parameter record area to the program storage area saved after the new program is downloaded, and then executes the software restart and monitors the device restart process; Among them, the monitoring methods are: Bootload reads the host restart identifier when it starts up, and detects that it is a restart after the upgrade is completed. First, based on the changed current program storage area flag, it calculates whether the file size check code and other information of the program stored in the corresponding program storage area are consistent with the relevant information recorded in the running parameter recording area. If the check results are consistent, it means that the program is complete, and the program is loaded from the corresponding program storage area to run, and jumps to S6; if the check results are inconsistent, it means that the program is incomplete, and the host restart identifier in the running parameter recording area is changed from upgrade completion restart to normal restart, and the current running storage area flag is switched back to the storage area flag corresponding to the upgrade to load the original program.

8. A unified cloud upgrade method based on multi-device serial communication according to claim 7, characterized in that: The step of checking the upgrade result and controlling the device to enter the silent mode includes: The relay controller first reads the serial device firmware version number, and after successfully reading the device firmware version number, sends a silent mode command to the device alone; After the serial device restarts, the relay controller first reads the device firmware version number. If the read device firmware version number is consistent with the version before the upgrade, it means the upgrade has failed. If the read device firmware version number is consistent with the current upgrade version, it means the upgrade has succeeded. According to the check and upgrade result, the device upgrade status of the device in the online device list is marked as upgraded or failed; If the program upgrade fails, query the number of repeated upgrades of the current device. If the number of repeated upgrades is less than the preset maximum number of repeated upgrades, add one to the number of repeated upgrades and jump to S3 to upgrade again. If the number of repeated upgrades is more than three times, notify the operation and maintenance personnel to handle it manually later. If the upgrade is successful, execute S7.

9. A unified cloud upgrade method based on multi-device serial communication according to claim 8, characterized in that: The step of checking and switching the device includes: Check whether there are other devices on the communication bus that need to be upgraded. If there are devices to be upgraded, randomly assign different weight values ​​to each device that has not completed the upgrade; Select the device with the largest weight value, and repeat S3 to S6 to upgrade the firmware of the device. If there is no device that needs to be upgraded, it means that the device upgrade is completed, and then run S8.

10. A unified cloud upgrade method based on multi-device serial communication according to claim 9, characterized in that: The step of exiting the silent mode includes: When all devices have been upgraded, all devices are notified to exit silent mode through broadcast commands; Wait for all devices to return confirmation signals, mark all devices as upgraded, record the time when the upgrade is completed, and synchronize the information to the cloud server.

Images