Remote upgrading method for preventing downtime

Abstract

The invention provides an anti-downtime remote upgrading method which comprises the following steps: step 1, a server issues an upgrading instruction and a firmware file to equipment, the equipment starts an upgrading program, original firmware is stored in an external storage area, and a system is restarted; 2, judging whether upgrading succeeds or not in boot, if upgrading fails and firmware cannot be started, reporting an error, starting to recover original firmware and recovering from an external storage area, and if upgrading succeeds, skipping to the step 3; the method for judging whether upgrading succeeds comprises the steps that after the equipment is restarted, a hardware watchdog interrupts and judges whether an upgrading flag bit is cleared or not, and if the upgrading flag bit is not cleared, upgrading fails; 3, checking whether the new-version firmware is required by the equipment or not, if not, installing the required firmware, and if yes, executing the step 1 to install the new-version firmware; the method for checking whether the new version firmware is the equipment or not comprises the step of checking whether the number of the new firmware is matched with the number of the equipment or not.

Description

Technical Field

[0001] The invention belongs to the field of remote upgrading, and in particular relates to a remote upgrading method for preventing downtime. Background Art

[0002] With the widespread application of embedded systems in various industries, the importance of ensuring their stability and continuous operation has become increasingly prominent. Embedded systems are often used in mission-critical scenarios, such as industrial control, medical equipment, and transportation. The normal operation of these systems is directly related to safety and reliability. However, with the rapid development of technology and the complexity of application scenarios, traditional embedded systems face many challenges in preventing downtime and remote upgrades.

[0003] Existing embedded systems generally have security risks during remote upgrades. Many systems still rely on traditional firmware upgrade methods, which often lack effective authentication and data encryption measures and are easily interfered with by malicious attackers. Attackers can attack embedded systems by forging upgrade packages or intercepting data during transmission, causing downtime or data leakage. This security vulnerability makes embedded systems vulnerable to cyber attacks and unable to effectively protect core functions and user data.

[0004] Current remote upgrade mechanisms often lack reliability and fault tolerance. When performing a system upgrade, if there is a network outage, power failure, or other abnormal conditions, the upgrade process may be interrupted or even put the device into an unrecoverable state. This situation is particularly dangerous in critical applications and may cause the system to completely lose functionality, resulting in economic losses and safety hazards. Therefore, existing technologies are not adaptable enough to deal with unstable environments and cannot ensure a smooth upgrade process.

[0005] Traditional embedded systems have defects in version management and rollback strategies. Many systems do not fully consider version compatibility when upgrading, resulting in the new version of the firmware being incompatible with the existing version, causing system crashes or malfunctions. In addition, the lack of an effective rollback mechanism means that once a problem occurs with the new version, it is impossible to quickly restore to the stable old version. This inflexible management method makes system maintenance more difficult and operators need to bear greater risks.

[0006] Existing remote upgrade solutions usually lack intelligent and automated support. Many systems still require manual intervention when upgrading, which not only increases labor costs but also reduces upgrade efficiency. In a rapidly evolving technology environment, the update and maintenance of embedded systems requires faster and more flexible response capabilities to adapt to changing needs. Therefore, traditional methods that rely on manual operations are particularly backward and cannot meet the needs of modern embedded applications.

[0007] There are also deficiencies in the user experience. In many cases, users cannot view the upgrade status or obtain upgrade-related information in real time, which leads to insufficient control over the system status. At the same time, the system may be unavailable for a long time during the upgrade process, affecting the user's normal experience. The lack of transparency and real-time feedback in the upgrade process has reduced users' trust in the system.

[0008] The current technical defects of embedded systems in remote upgrade and anti-downtime are mainly reflected in security, reliability, version management, intelligence and user experience. The existence of these problems not only affects the stability and security of embedded systems, but also hinders their application in a wider range of fields. Therefore, it is imperative to develop more advanced remote upgrade methods for embedded system anti-downtime to improve the overall performance of the system and user satisfaction. Summary of the invention

[0009] The present invention proposes a remote upgrade method to prevent downtime, which solves the downtime problem that may occur in the embedded system during the remote upgrade process, ensures the reliability of firmware upgrade and the stability of the system. Through the recovery mechanism, it can effectively prevent the system from being unable to start due to upgrade failure, thereby improving the availability and security of the device.

[0010] The technical solution of the present invention is implemented as follows: a remote upgrade method for preventing downtime, the method comprising the following steps:

[0011] Step 1: The server sends the upgrade command and firmware file to the device. The device starts the upgrade program, saves the original firmware to the external storage area, and restarts the system.

[0012] Step 2: Determine whether the upgrade is successful in the boot. If the upgrade fails and the firmware cannot be started, an error is reported and the original firmware is restored from the external storage area. If the upgrade is successful, jump to step 3. The method for determining whether the upgrade is successful is as follows: after the device is restarted, the hardware watchdog interrupt determines whether the upgrade flag is cleared. If it is not cleared, it indicates that the upgrade has failed.

[0013] Step 3: Check whether the new version of the firmware is required by the device. If not, install the required firmware. If yes, execute step 1 to install the new version of the firmware. The method of checking whether the new version of the firmware is required by the device is: check whether the number of the new firmware matches the number of the device.

[0014] Step 4: Check whether the firmware is installed correctly. If not, report an error and return to step 2 to restore the original firmware. If correct, execute step 5. The method for checking whether the firmware is installed correctly includes: testing all functions in the new version of the firmware, testing whether the system that needs to be maintained by the watchdog is normal and the system that needs to be restarted by the watchdog is in working state;

[0015] Step 5: Notify the remote server that the version has been successfully installed, clear the upgrade flag and watchdog flag, and wait for the remote server to indicate the next upgrade content.

[0016] Compared with the existing technology, the main difference of this method lies in its enhanced fault recovery capability and intelligent upgrade management. Traditional embedded system upgrade methods often lack an effective rollback mechanism. Once the upgrade fails, the device may be in an unbootable state, resulting in service interruption and reduced user experience. During the upgrade process, this method first backs up the original firmware to an external storage area to ensure that it can quickly recover to the previous stable state in the event of a fault. This design greatly improves the system's fault tolerance.

[0017] The existing technology is generally simple in judging whether the upgrade is successful or not, and may only rely on whether the firmware is successfully written, while ignoring the comprehensive inspection of the firmware version and function. This method introduces a hardware watchdog interrupt mechanism to monitor the status of the upgrade flag in real time, ensuring that the system will continue to perform subsequent operations only after the upgrade is successful. This multi-level verification method not only improves the security of the upgrade, but also reduces the potential risks caused by firmware incompatibility or missing functions.

[0018] In the step of checking whether the new firmware meets the device requirements, the method further ensures the compatibility of the firmware through the firmware number matching mechanism, avoiding system errors caused by version mismatch. This detailed inspection process is not common in the prior art, making the upgrade process more intelligent and precise. At the same time, the functional test after the firmware is installed also ensures the stability and reliability of the new version of the firmware in actual application, further improving the robustness of the system.

[0019] As a preferred implementation, there is a preparatory startup link before step 1, by setting a hardware watchdog and a software watchdog, and waiting for setting a watchdog flag and an upgrade flag.

[0020] As a preferred implementation, the method for setting a hardware watchdog is as follows: the interrupt frequency of the watchdog chip is set by the watchdog register. If the interrupt frequency is 0, the watchdog is started. If the interrupt frequency is 0xFFFF and the value read by the register is not 0xFFFF, the watchdog interrupt is stopped or the watchdog flag is cleared. The interrupt of the hardware watchdog module directly causes the device to restart.

[0021] As a preferred implementation method, the implementation method of the software watchdog interrupt is that the watchdog interrupt is executed for the first time after the device is restarted, and the watchdog flag is checked to see if it is 0. If it is 0, it is set to 1, and the next watchdog interrupt is executed. Otherwise, the watchdog flag is set to 0x0005 and the watchdog flag is cleared. The second watchdog interrupt directly clears the watchdog flag. If the watchdog flag is not 0, it means that the watchdog interrupt has not been executed, and an instruction to clear the watchdog flag needs to be executed.

[0022] As a preferred implementation, the method of setting the upgrade flag is: the flag of this upgrade is a global variable, and the global variable has two setting watchdog flags and upgrading flags; when the device starts to upgrade, the upgrade flag is set to 1. If the upgrade process fails after restarting, if the watchdog flag has not been cleared, the upgrade flag is set to 2. If the upgrade process does not fail, the upgrade flag is set to 0. Whether the original firmware needs to be restored after restarting, the upgrade flag is set to 3.

[0023] As a preferred implementation, the step of judging whether the upgrade is successful in boot in step 2 is: when starting the upgrade program, set the upgrade flag to 1 and the watchdog flag to 0. If the firmware installation is complete, set the upgrade flag to 0; if the upgrade fails at the end of the upgrade program, the upgrade flag will be set to 2 regardless of the type of failure; clear the upgrade flag to start the device, and after the device is started, the hardware watchdog judges the upgrade flag. If the upgrade flag is 1, the upgrade failure flag is set, and the upgrade flag is cleared from the flag. If the upgrade flag is 2, the device is restarted, the watchdog flag is cleared from the upgrade flag position, and the upgrade failure flag is not cleared. If the upgrade flag is 0, the upgrade failure flag is not set; the upgrade flag is 1, which means that the upgrade failure flag has not been set from the restart to the present. If it is 2, the flag is 2. After the device is restarted, the watchdog flag is set, and the upgrade flag is still 2, that is, the upgrade failure flag has not been set to 0.

[0024] After adopting the above technical solution, the beneficial effect of the present invention is that by establishing an effective rollback mechanism, even in the case of upgrade failure, the device can quickly return to a stable state, greatly improving the availability of the system. This design allows users to avoid the risk of downtime caused by firmware problems when the device is remotely upgraded, thereby improving the user experience.

[0025] The multiple verification mechanism in the method ensures that every firmware upgrade is strictly checked. Only after it is fully confirmed that the new firmware version is compatible with the device and functions normally, the system is allowed to switch to the new firmware. This approach effectively reduces the risk of system downtime caused by incompatible firmware and provides a guarantee for the stable operation of embedded devices.

[0026] The steps of notifying the remote server of the successful version installation ensure the information synchronization between the system and the server, which is convenient for subsequent management and maintenance. By clearing the upgrade flag and the watchdog flag, the system can be ready to meet the next upgrade request at any time, improving the management efficiency of the entire device.

[0027] This method improves the stability and security of embedded systems in various application scenarios through efficient firmware management and upgrade strategies, enabling devices to remain competitive in a rapidly evolving technology environment. This highly reliable upgrade mechanism has laid a solid foundation for widespread application in the fields of the Internet of Things and smart homes, and has important practical significance. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0029] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0030] 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.

[0031] Example:

[0032] like Figure 1 As shown, a remote upgrade method for preventing downtime includes the following steps:

[0033] Step 1: The server sends the upgrade command and firmware file to the device. The device starts the upgrade program, saves the original firmware to the external storage area, and restarts the system.

[0034] Step 2: Determine whether the upgrade is successful in the boot. If the upgrade fails and the firmware cannot be started, an error is reported and the original firmware is restored from the external storage area. If the upgrade is successful, jump to step 3. The method for determining whether the upgrade is successful is as follows: after the device is restarted, the hardware watchdog interrupt determines whether the upgrade flag is cleared. If it is not cleared, it indicates that the upgrade has failed.

[0035] Step 3: Check whether the new version of the firmware is required by the device. If not, install the required firmware. If yes, execute step 1 to install the new version of the firmware. The method of checking whether the new version of the firmware is required by the device is: check whether the number of the new firmware matches the number of the device.

[0036] Step 4: Check whether the firmware is installed correctly. If not, report an error and return to step 2 to restore the original firmware. If correct, execute step 5. The method for checking whether the firmware is installed correctly includes: testing all functions in the new version of the firmware, testing whether the system that needs to be maintained by the watchdog is normal and the system that needs to be restarted by the watchdog is in working state;

[0037] Step 5: Notify the remote server that the version has been successfully installed, clear the upgrade flag and watchdog flag, and wait for the remote server to indicate the next upgrade content.

[0038] This remote upgrade method for embedded system anti-downtime shows several significant differences and advantages compared with existing technologies. Existing remote upgrade methods usually have the problem of being unable to effectively restore the original firmware when a downtime or failure occurs during the firmware upgrade process, causing the device to fail to work properly. This method greatly improves the robustness and reliability of the system by saving the original firmware to an external storage area and monitoring it through a hardware watchdog during the upgrade process. Specifically, the first step of this method is to back up the original firmware before the upgrade, so that it can be quickly restored to a stable state in the event of an upgrade failure. This design is often lacking in traditional upgrade methods, which can easily cause the device to be unable to resume normal functions for a long time.

[0039] In the step of determining whether the upgrade is successful, the method uses a hardware watchdog interrupt to monitor the upgrade flag. This mechanism enables the system to quickly determine whether the firmware is successfully installed after restarting. If the flag is not cleared, the system will automatically handle the error and restore the original firmware. This automated judgment and recovery mechanism is not common in the prior art. Many traditional methods often rely on software-level checks and may not respond in time when the system crashes or becomes unresponsive, resulting in firmware damage or device failure.

[0040] In the step of checking whether the new version of firmware is suitable for the device, the method ensures that the installed firmware meets the device requirements by matching the firmware number. This mechanism can effectively avoid system failures caused by firmware incompatibility. In the prior art, the firmware applicability verification is often relatively simple, lacking strict checks on the firmware version and device model, which easily leads to mismatch problems.

[0041] In the step of detecting whether the firmware is installed correctly, this method not only confirms the validity of the new firmware through functional testing, but also combines watchdog monitoring to ensure that the system is tested in normal working conditions. This multiple verification mechanism increases the system's guarantee of firmware stability and ensures that the device can operate normally after the firmware upgrade. Traditional methods often rely only on a single functional test and lack a comprehensive evaluation of the overall system performance, which may fail to discover potential problems in some cases.

[0042] In the step of notifying the remote server that the version has been successfully installed, the method clears the upgrade flag and the watchdog flag to prepare for subsequent upgrades. This design ensures the system's state management, allowing the device to smoothly enter the standby state after completing an upgrade and wait for the next instruction. This state management is often overlooked in traditional upgrade solutions, which may cause the device to fail to respond correctly to subsequent operations after the upgrade.

[0043] This remote upgrade method for embedded system anti-downtime significantly improves the stability and reliability of the system by introducing a series of innovative designs such as firmware backup, hardware watchdog monitoring, firmware adaptation check, multiple verification mechanisms, and status management. It avoids the problem of device failure after firmware upgrade failure in traditional technologies, ensures that the embedded system can continue to run stably in complex and unstable environments, and meets the high requirements of modern embedded systems for remote upgrades.

[0044] There is a preparatory startup link before step 1, which sets the hardware watchdog and software watchdog while waiting for the watchdog flag and upgrade flag to be set. The preparatory startup link in this technical solution shows a significant difference compared with the prior art through the combination of hardware watchdog and software watchdog. Traditional systems often lack an effective monitoring mechanism at startup, and are prone to deadlock or non-response during the startup process. However, this solution not only provides redundant monitoring means by setting hardware and software watchdogs, but also can automatically restart when the system is abnormal, ensuring the reliability and stability of the equipment. This dual monitoring mechanism enables the device to effectively wait for the flag to be set before startup, avoiding unnecessary operations when the status is unclear, thereby improving the system startup success rate and security.

[0045] The method for setting the hardware watchdog is as follows: the interrupt frequency of the watchdog chip is set by the watchdog register. If the interrupt frequency is 0, the watchdog is started. If the interrupt frequency is 0xFFFF and the value read by the register is not 0xFFFF, the watchdog interrupt is stopped or the watchdog flag is cleared. The interrupt of the hardware watchdog module directly causes the device to restart.

[0046] In the specific implementation method of setting the hardware watchdog, the scheme controls the interrupt frequency through the watchdog register. If it is set to 0, the watchdog is started, otherwise the interrupt is stopped. Compared with the static setting or single timer method commonly used in the prior art, this mechanism has higher flexibility and real-time performance. The traditional method may cause the system to be unable to restart due to timer failure, while this scheme ensures timely response at critical moments by dynamically adjusting the interrupt frequency, thereby effectively reducing the risk of system crash.

[0047] The implementation method of the software watchdog interrupt is as follows: the watchdog interrupt is executed for the first time after the device is restarted, and the watchdog flag is checked to see if it is 0. If it is 0, it is set to 1, and the next watchdog interrupt is continued to be executed; otherwise, the watchdog flag is set to 0x0005, and the watchdog flag is cleared. The second watchdog interrupt directly clears the watchdog flag. If the watchdog flag is not 0, it means that the watchdog interrupt has not been executed, and an instruction to clear the watchdog flag needs to be executed.

[0048] Regarding the implementation of the software watchdog, the solution checks the watchdog flag bit to decide whether to continue execution during the first execution after the device is restarted. This mechanism ensures the efficient execution of the watchdog interrupt and avoids the repeated clearing of the flag bit. Compared with the simple timer reset mechanism that may exist in the prior art, this solution makes the watchdog monitoring more intelligent through the dynamic management of the flag bit, can better adapt to complex operating environments, and ensures the system's rapid response in abnormal situations.

[0049] The method for setting the upgrade flag is as follows: the flag for this upgrade is a global variable, and the global variable has two setting watchdog flags and upgrading flags; when the device starts upgrading, the upgrade flag is set to 1. If the upgrade process fails and the watchdog flag has not been cleared after restarting, the upgrade flag is set to 2. If the upgrade process does not fail, the upgrade flag is set to 0. Whether the original firmware needs to be restored after restarting, the upgrade flag is set to 3.

[0050] In setting the upgrade flag, this solution uses global variables to manage the status of the flag. This design enhances the state tracking capability during the upgrade process. Traditional technologies may only rely on local variables or simple status codes, lacking comprehensive monitoring of the upgrade process. Through clear flag management, this solution can record the status in time when the upgrade fails, ensuring that different upgrade situations can be correctly identified and handled after restart, further improving the system's fault tolerance.

[0051] In step 2, the steps for judging whether the upgrade is successful in boot are as follows: when starting the upgrade program, set the upgrade flag position to 1 and the watchdog flag position to 0. If the firmware installation is complete, set the upgrade flag position to 0; if the upgrade fails at the end of the upgrade program, set the upgrade flag position to 2 regardless of the type of failure; clear the upgrade flag position to start the device, and after the device is started, the hardware watchdog judges the upgrade flag position. If the upgrade flag position is 1, set the upgrade failure flag position, and clear the upgrade flag position from the flag position. If the upgrade flag position is 2, the device is restarted, the watchdog flag position is cleared from the upgrade flag position, and the upgrade failure flag position is not cleared. If the upgrade flag position is 0, the upgrade failure flag position is not set; if the upgrade flag position is 1, it means that the upgrade failure flag position has not been set from the restart to the present. If it is 2, the flag position is 2. After the device is restarted, the watchdog flag position is set, and the upgrade flag position is still 2, that is, the upgrade failure flag position is not set to 0.

[0052] In the step of judging whether the upgrade is successful or not, the solution specifies that the upgrade flag and watchdog flag need to be set accordingly when starting the upgrade program, and status feedback is provided based on the results of the firmware installation. This clear control process is in sharp contrast to the traditional fuzzy judgment mechanism, which often leads to uncertainty and potential failures in the upgrade process. By combining the upgrade flag with the watchdog control, this solution can effectively determine whether the original firmware needs to be restarted or restored after the device is started, greatly improving the stability and reliability of the system during the firmware upgrade process. This technical solution significantly improves the reliability and intelligence level of the system by combining hardware and software watchdogs, dynamic interrupt management, comprehensive status monitoring, and a clear upgrade control process, overcomes many deficiencies in the existing technology, and provides a strong guarantee for the safe startup and stable operation of the device.

[0053] 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 principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A remote upgrade method to prevent downtime, characterized in that: The method comprises the following steps: Step 1: The server sends the upgrade command and firmware file to the device. The device starts the upgrade program, saves the original firmware to the external storage area, and restarts the system. Step 2: Determine whether the upgrade is successful in the boot. If the upgrade fails and the firmware cannot be started, an error is reported and the original firmware is restored from the external storage area. If the upgrade is successful, jump to step 3. The method for determining whether the upgrade is successful is as follows: after the device is restarted, the hardware watchdog interrupt determines whether the upgrade flag is cleared. If it is not cleared, it indicates that the upgrade has failed. Step 3: Check whether the new version of the firmware is required by the device. If not, install the required firmware. If yes, execute step 1 to install the new version of the firmware. The method of checking whether the new version of the firmware is required by the device is: check whether the number of the new firmware matches the number of the device. Step 4: Check whether the firmware is installed correctly. If not, report an error and return to step 2 to restore the original firmware. If correct, execute step 5. The method for checking whether the firmware is installed correctly includes: testing all functions in the new version of the firmware, testing whether the system that needs to be maintained by the watchdog is normal and the system that needs to be restarted by the watchdog is in working state; Step 5: Notify the remote server that the version has been successfully installed, clear the upgrade flag and watchdog flag, and wait for the remote server to indicate the next upgrade content.

2. The method for remote upgrading to prevent downtime according to claim 1, characterized in that: There is a preparatory startup link before step 1, which sets the hardware watchdog and software watchdog, and waits for the watchdog flag and upgrade flag to be set.

3. A remote upgrade method for preventing downtime as claimed in claim 2, characterized in that: The method for setting the hardware watchdog is as follows: the interrupt frequency of the watchdog chip is set by the watchdog register. If the interrupt frequency is 0, the watchdog is started. If the interrupt frequency is 0xFFFF and the value read by the register is not 0xFFFF, the watchdog interrupt is stopped or the watchdog flag is cleared. The interrupt of the hardware watchdog module directly causes the device to restart.

4. A remote upgrade method for preventing downtime as claimed in claim 2, characterized in that: The implementation method of the software watchdog interrupt is as follows: the watchdog interrupt is executed for the first time after the device is restarted, and the watchdog flag is checked to see if it is 0. If it is 0, it is set to 1, and the next watchdog interrupt is continued to be executed; otherwise, the watchdog flag is set to 0x0005, and the watchdog flag is cleared. The second watchdog interrupt directly clears the watchdog flag. If the watchdog flag is not 0, it means that the watchdog interrupt has not been executed, and an instruction to clear the watchdog flag needs to be executed.

5. The method for remote upgrading to prevent downtime according to claim 2, characterized in that: The method for setting the upgrade flag is as follows: the flag for this upgrade is a global variable, and the global variable has two setting watchdog flags and upgrading flags; when the device starts upgrading, the upgrade flag is set to 1. If the upgrade process fails and the watchdog flag has not been cleared after restarting, the upgrade flag is set to 2. If the upgrade process does not fail, the upgrade flag is set to 0. Whether the original firmware needs to be restored after restarting, the upgrade flag is set to 3.

6. The method for remote upgrading to prevent downtime according to claim 1, characterized in that: The step of judging whether the upgrade is successful in boot in step 2 is as follows: when starting the upgrade program, set the upgrade flag to 1 and the watchdog flag to 0; if the firmware installation is completed, set the upgrade flag to 0; if the upgrade fails at the end of the upgrade program, set the upgrade flag to 2 regardless of the failure type; Clear the upgrade flag to start the device. After the device starts, the hardware watchdog determines the upgrade flag. If the upgrade flag is 1, the upgrade failure flag is set, and the upgrade flag is cleared from the flag. If the upgrade flag is 2, the device restarts, the watchdog flag is cleared from the upgrade flag position, and the upgrade failure flag is not cleared. If the upgrade flag is 0, the upgrade failure flag is not set; if the upgrade flag is 1, it means that the upgrade failure flag has not been set from the restart to the present. If it is 2, the flag is 2. After the device restarts, the watchdog flag is set, and the upgrade flag is still 2, that is, the upgrade failure flag is not set to 0.

Images