Smart home equipment cluster firmware updating method and device and electronic equipment
By employing a multi-stage, incremental pilot strategy and a health assessment model, the robustness and reliability issues in the firmware update process for smart home device clusters were resolved, enabling efficient and secure firmware updates and ensuring the stability and security of the device clusters.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-15
- Publication Date
- 2026-03-20
AI Technical Summary
During firmware updates for smart home device clusters, there is a risk of reduced device robustness and reliability, especially given the large number of devices and the high risk of updates.
A multi-stage, incremental pilot strategy is adopted to update the firmware of smart home devices in stages, and a health assessment is carried out at each stage. The risk type is identified through a multi-dimensional health assessment model and the corresponding rollback strategy is triggered. Finally, reliable firmware versions are recorded to the whitelist.
By conducting phased testing and risk assessment, critical defects can be detected early, avoiding risks to the cluster, improving the robustness and reliability of the device cluster, and ensuring system stability and security.
Smart Images
Figure CN121704869A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of smart home, specifically relating to a method, device, and electronic device for firmware update of a smart home device cluster. Background Technology
[0002] In practice, firmware update refers to the process of upgrading or repairing the basic software (i.e., firmware) embedded in a device by flashing new program code. The purpose is to fix known vulnerabilities, improve device performance, add new functions, or improve system compatibility, etc.
[0003] In IoT applications, firmware updates for smart home device clusters are a core component for maintaining system security and functionality. However, due to the large number of smart home devices in a cluster, there are risks involved in the firmware update process, reducing the robustness and reliability of the smart home device cluster. Summary of the Invention
[0004] The purpose of this application is to provide a method, apparatus, and electronic device for updating firmware of a smart home device cluster, so as to overcome or at least partially solve the above-mentioned problems.
[0005] To solve the above-mentioned technical problems, this application is implemented as follows: A firmware update method for a smart home device cluster, the smart home device cluster comprising multiple smart home devices, the method comprising: According to the preset multi-stage gradual pilot strategy, the firmware of the smart home devices is updated sequentially in each stage; wherein, in each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so as to continue to the next stage after the health assessment is passed; the number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. When the firmware of the smart home devices is updated and the health assessment is passed in all stages of the multi-stage progressive pilot strategy, the firmware of the smart home devices in the smart home device cluster that have not been updated is updated.
[0006] In one embodiment of this application, the multi-stage progressive pilot strategy includes at least a first stage, a second stage, and a third stage in sequence; the step of sequentially updating the firmware of the smart home device at each stage according to the preset multi-stage progressive pilot strategy includes: A first set of smart home devices is selected from the smart home devices according to the first device selection criteria corresponding to the first stage. The firmware of the first set of smart home devices is updated, and the first set of smart home devices with updated firmware is subjected to a health assessment according to the first health assessment strategy corresponding to the first stage. After the first stage health assessment is passed, a second set of smart home devices is selected from the smart home devices according to the second device screening criteria corresponding to the second stage. The firmware of the second set of smart home devices is updated, and the second set of smart home devices with updated firmware is subjected to a health assessment according to the second health assessment strategy corresponding to the second stage. After the second-stage health assessment is passed, a third set of smart home devices is selected from the smart home devices according to the third device screening criteria corresponding to the third stage. The firmware of the third set of smart home devices is updated, and the third set of smart home devices with updated firmware is subjected to a health assessment according to the third health assessment strategy corresponding to the third stage.
[0007] In one embodiment of this application, the first smart home device set, the second smart home device set, and the third smart home device set are different smart home devices.
[0008] In one embodiment of this application, the first device screening criterion is based on reliability and business criticality; the second device screening criterion is based on diversity screening; and the third device screening criterion is based on a preset device ratio.
[0009] In one embodiment of this application, the first health assessment strategy is used to monitor and assess whether a specified fatal anomaly occurs in the first smart home device set during a first monitoring period; the second health assessment strategy is used to monitor and assess the performance indicators, business function anomalies, and compatibility of the second smart home device set during a second monitoring period; and the third health assessment strategy is used to monitor and assess whether there are latent defects in the third smart home device set during a third monitoring period; wherein the second monitoring period is longer than the first monitoring period, and the third monitoring period is longer than the second monitoring period.
[0010] In one embodiment of this application, the method further includes: Acquire the health data stream of the smart home devices that are undergoing firmware updates at each stage; The health data stream is input into a preset multidimensional health assessment model to obtain the risk type corresponding to the smart home device output by the multidimensional health assessment model. For the smart home device of the aforementioned risk type, a rollback strategy corresponding to that risk type is triggered to restore the version of the smart home device to the version before the firmware update.
[0011] In one embodiment of this application, triggering a rollback strategy corresponding to the risk type for the smart home device of the risk type includes: For smart home devices with a risk type classified as catastrophic, a rollback operation will be performed within a preset time range. For smart home devices with a risk type of "severe risk", a rollback operation is performed when the device is idle. For smart home devices with a risk type of minor risk, a regression operation is performed at a preset maintenance cycle.
[0012] In one embodiment of this application, after the smart home devices have undergone firmware updates and passed health assessments at all stages of the multi-stage progressive pilot strategy, and after updating the firmware of the smart home devices in the smart home device cluster that have not yet undergone firmware updates, the method further includes: Record the firmware version for firmware updates in the whitelist.
[0013] In one embodiment of this application, after recording the firmware version of the firmware update in the whitelist, the method further includes: When the smart home device triggers verification, it verifies whether the firmware version of the smart home device is in the whitelist; If the firmware version of the smart home device is not in the whitelist, then the firmware of the smart home device will be updated according to the firmware version in the whitelist.
[0014] A firmware update device for a smart home device cluster, the smart home device cluster including multiple smart home devices, the device comprising: The multi-stage progressive pilot module is used to update the firmware of the smart home devices sequentially in each stage according to a preset multi-stage progressive pilot strategy. In each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so that they can continue to the next stage after passing the health assessment. The number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. The device firmware update module is used to update the firmware of smart home devices in the smart home device cluster that have not been updated when the smart home devices have been updated in all stages of the multi-stage progressive pilot strategy and the health assessment has passed.
[0015] In one embodiment of this application, the multi-stage progressive pilot strategy includes at least a first stage, a second stage, and a third stage in sequence; the multi-stage progressive pilot module is used for: A first set of smart home devices is selected from the smart home devices according to the first device selection criteria corresponding to the first stage. The firmware of the first set of smart home devices is updated, and the first set of smart home devices with updated firmware is subjected to a health assessment according to the first health assessment strategy corresponding to the first stage. After the first stage health assessment is passed, a second set of smart home devices is selected from the smart home devices according to the second device screening criteria corresponding to the second stage. The firmware of the second set of smart home devices is updated, and the second set of smart home devices with updated firmware is subjected to a health assessment according to the second health assessment strategy corresponding to the second stage. After the second-stage health assessment is passed, a third set of smart home devices is selected from the smart home devices according to the third device screening criteria corresponding to the third stage. The firmware of the third set of smart home devices is updated, and the third set of smart home devices with updated firmware is subjected to a health assessment according to the third health assessment strategy corresponding to the third stage.
[0016] In one embodiment of this application, the first smart home device set, the second smart home device set, and the third smart home device set are different smart home devices.
[0017] In one embodiment of this application, the first device screening criterion is based on reliability and business criticality; the second device screening criterion is based on diversity screening; and the third device screening criterion is based on a preset device ratio.
[0018] In one embodiment of this application, the first health assessment strategy is used to monitor and assess whether a specified fatal anomaly occurs in the first smart home device set during a first monitoring period; the second health assessment strategy is used to monitor and assess the performance indicators, business function anomalies, and compatibility of the second smart home device set during a second monitoring period; and the third health assessment strategy is used to monitor and assess whether there are latent defects in the third smart home device set during a third monitoring period; wherein the second monitoring period is longer than the first monitoring period, and the third monitoring period is longer than the second monitoring period.
[0019] In one embodiment of this application, the apparatus further includes: a risk processing module, used for: Acquire the health data stream of the smart home devices that are undergoing firmware updates at each stage; The health data stream is input into a preset multidimensional health assessment model to obtain the risk type corresponding to the smart home device output by the multidimensional health assessment model. For the smart home device of the aforementioned risk type, a rollback strategy corresponding to that risk type is triggered to restore the version of the smart home device to the version before the firmware update.
[0020] In one embodiment of this application, the risk processing module is used for: For smart home devices with a risk type classified as catastrophic, a rollback operation will be performed within a preset time range. For smart home devices with a risk type of "severe risk", a rollback operation is performed when the device is idle. For smart home devices with a risk type of minor risk, a regression operation is performed at a preset maintenance cycle.
[0021] In one embodiment of this application, the device further includes: a whitelist module, used for: Record the firmware version for firmware updates in the whitelist.
[0022] In one embodiment of this application, the device further includes a whitelist verification module, used for: When the smart home device triggers verification, it verifies whether the firmware version of the smart home device is in the whitelist; If the firmware version of the smart home device is not in the whitelist, then the firmware of the smart home device will be updated according to the firmware version in the whitelist.
[0023] An electronic device includes: a processor; and a memory for storing processor-executable instructions. The processor is configured to execute the instructions to implement the aforementioned smart home device cluster firmware update method.
[0024] A computer-readable storage medium, when the instructions in the storage medium are executed by the processor of a mobile terminal, enables the mobile terminal to perform the aforementioned smart home device cluster firmware update method.
[0025] The embodiments of this application have at least the following beneficial effects: In this embodiment, the smart home device cluster includes multiple smart home devices. When a firmware update is required for the entire smart home device cluster, the firmware is updated sequentially at each stage according to a preset multi-stage progressive pilot strategy. In each stage, the smart home devices that have already had their firmware updated undergo a health assessment according to the corresponding health assessment strategy. If the health assessment is passed, the device can proceed to the next stage. The number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. Subsequently, when the smart home devices have undergone firmware updates and passed the health assessments in all stages of the multi-stage progressive pilot strategy, the smart home devices in the smart home device cluster that have not yet undergone firmware updates undergo firmware updates. In this embodiment, the firmware of smart home devices is updated sequentially in multiple stages according to a preset multi-stage progressive pilot strategy. Only after the health assessment of the previous stage is passed can the next stage be continued. Furthermore, the number of smart home devices undergoing firmware updates is gradually increased in stages, thereby effectively controlling the scope of risks in the firmware update process of the smart home device cluster. This allows for the early detection of fatal defects at the lowest cost, avoiding risks to the entire smart home device cluster and improving the robustness and reliability of the smart home device cluster. Attached Figure Description
[0026] Figure 1 This is a flowchart illustrating the steps of a firmware update method for a smart home device cluster provided in this application embodiment; Figure 2 This is a flowchart illustrating a firmware update process for a smart home device cluster, as provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a smart home device cluster firmware update device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0027] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.
[0028] It should be noted that the embodiments of this application may involve the use of user data. In practical applications, user-specific personal data may be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country (e.g., with the user's explicit consent, with the user being properly notified, etc.).
[0029] Reference Figure 1 This document illustrates a flowchart of a firmware update method for a smart home device cluster provided in an embodiment of this application. The smart home device cluster includes multiple smart home devices, and the method specifically includes the following steps: Step 101: According to the preset multi-stage progressive pilot strategy, the firmware of the smart home devices is updated sequentially in each stage; wherein, in each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so as to continue to the next stage after the health assessment is passed; the number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage.
[0030] In practical implementation, an Internet of Things (IoT) system (hereinafter referred to as the system) may include a cloud-based central decision-making unit and a cluster of smart home devices (IoT devices). The central decision-making unit is the brain of the system, containing an update scheduler, a health analyzer, a risk assessor, and a policy engine. Each smart home device serves as the cell and end-effector of the system, with a fixed health monitoring agent, a policy execution client, and a reserved secure version storage for storing verified firmware backups. For example, smart home devices may include at least air conditioning units, smart lights, smart sockets, lighting equipment, dehumidifiers, audio equipment, sensor devices, smoke detectors, smart door locks, and security cameras.
[0031] In this embodiment, the firmware update process for smart home devices is designed as a pipeline containing multiple strictly ordered stages. Specifically, this embodiment employs a multi-stage progressive pilot strategy, which consists of multiple stages. The system updates the firmware of the smart home devices sequentially at each stage according to this strategy. After each stage's firmware update, a health assessment is performed on the updated smart home devices according to the corresponding health assessment strategy. If the health assessment passes, the device proceeds to the next stage. The health assessment determines whether the upgraded smart home device meets the preset goals of its current stage. The success of the health assessment determines whether to proceed to the next stage of firmware upgrade and health assessment. The number of smart home devices undergoing firmware updates in the next stage is greater than the number in the previous stage. In other words, the number of smart home devices undergoing firmware updates in the first stage is very small, even a very small range. This allows for the early detection of fatal defects with minimal cost through initial testing within a very small range.
[0032] In one embodiment of this application, the multi-stage progressive pilot strategy design may include, but is not limited to, an Alpha stage, a Beta stage, and a Release Candidate (RC) stage. In the Alpha stage, the new firmware (referring to the firmware used for firmware updates) is deployed to a very small, highly reliable set of smart home devices. Only after the smart home device set in the Alpha stage passes a comprehensive health assessment within a preset monitoring period does the system automatically enter the Beta stage, expanding the deployment scope of the new firmware to a more diverse set of smart home devices. This process proceeds sequentially. In the RC stage, large-scale near-real-world environment verification is conducted, expanding the deployment scope of the new firmware to a set of smart home devices with a much larger number than in the previous two stages, achieving a step-by-step verification of the new firmware's quality. By using a phased, gradually expanding testing approach, the compatibility and stability of the new firmware under different hardware configurations and load scenarios can be systematically tested.
[0033] Step 102: When the smart home devices have undergone firmware updates and passed health assessments at all stages of the multi-stage progressive pilot strategy, the smart home devices in the smart home device cluster that have not undergone firmware updates are then updated with firmware.
[0034] In this embodiment of the application, when the firmware update of the smart home devices is completed and the health assessment is passed in all stages of the multi-stage progressive pilot strategy, such as the Alpha stage, Beta stage, and RC stage, if there are still smart home devices in the smart home device cluster that have not been updated (deployed with new firmware), the firmware of the smart home devices that have not been updated can be updated according to the new firmware, thereby completing the firmware update of all smart home devices in the system.
[0035] In the above embodiments, the firmware of smart home devices is updated sequentially in multiple stages according to a preset multi-stage progressive pilot strategy. Only after the health assessment of the previous stage is passed can the next stage be continued. Furthermore, the number of smart home devices undergoing firmware updates is gradually increased in stages, thereby effectively controlling the scope of risks in the firmware update process of the smart home device cluster. This allows for the early detection of fatal defects at the lowest cost, avoiding risks to the entire smart home device cluster and improving the robustness and reliability of the smart home device cluster.
[0036] In one embodiment of this application, the multi-stage progressive pilot strategy includes at least a first stage, a second stage, and a third stage in sequence; the step of sequentially updating the firmware of the smart home device at each stage according to the preset multi-stage progressive pilot strategy may include: A first set of smart home devices is selected from the smart home devices according to the first device selection criteria corresponding to the first stage. The firmware of the first set of smart home devices is updated, and the first set of smart home devices with updated firmware is subjected to a health assessment according to the first health assessment strategy corresponding to the first stage. After the first stage health assessment is passed, a second set of smart home devices is selected from the smart home devices according to the second device screening criteria corresponding to the second stage. The firmware of the second set of smart home devices is updated, and the second set of smart home devices with updated firmware is subjected to a health assessment according to the second health assessment strategy corresponding to the second stage. After the second-stage health assessment is passed, a third set of smart home devices is selected from the smart home devices according to the third device screening criteria corresponding to the third stage. The firmware of the third set of smart home devices is updated, and the third set of smart home devices with updated firmware is subjected to a health assessment according to the third health assessment strategy corresponding to the third stage. The first set of smart home devices, the second set of smart home devices, and the third set of smart home devices are different smart home devices. The second monitoring period is longer than the first monitoring period, and the third monitoring period is longer than the second monitoring period.
[0037] The first stage can be the Alpha stage, the second stage can be the Beta stage, and the third stage can be the RC stage.
[0038] The first device selection criterion for the Alpha phase is based on reliability and business criticality. This is a very small-scale core internal test, requiring 1%-5% of smart home devices from the smart home device cluster to be selected as the first smart home devices and have their firmware updated. The second device selection criterion for the Beta phase is to conduct diversity screening, typically based on hardware model, software configuration, and physical deployment location. This requires 10%-20% of smart home devices from the smart home device cluster to be selected as the second smart home devices and have their firmware updated. The third device selection criterion for the RC phase is based on a preset device ratio, simulating a near-full operating environment. This requires 40%-50% of smart home devices from the smart home device cluster to be selected as the third smart home devices and have their firmware updated.
[0039] After the firmware update of the smart home devices is completed at each stage, a health assessment is performed on the set of smart home devices with updated firmware according to the health assessment strategy corresponding to that stage. In one embodiment of this application, the first health assessment strategy corresponding to the Alpha stage is used to monitor and assess whether the first set of smart home devices has a specified fatal anomaly within a first monitoring period (e.g., 24 hours); the second health assessment strategy corresponding to the Beta stage is used to monitor and assess the performance indicators, business function anomalies, and compatibility of the second set of smart home devices within a second monitoring period (e.g., 48 hours); and the third health assessment strategy corresponding to the RC stage is used to monitor and assess whether the third set of smart home devices has any latent defects within a third monitoring period (e.g., one week or one month).
[0040] In one example of this application, the firmware update testing process for the Alpha, Beta, and RC phases of a pre-defined multi-stage progressive pilot strategy can be as follows: Alpha Phase (Core Internal Testing): The central decision-making unit's update scheduler first selects approximately 1%-5% of the smart home device cluster as the initial pilot. Device selection criteria focus on the smart home devices' extremely high reliability, non-critical business nature (e.g., in backup or test environments), and robust diagnostic capabilities. The Alpha phase involves intensive 24-hour monitoring for health assessments. The health analyzer continuously detects severe system-level anomalies, such as startup failures, critical kernel errors, and hardware communication interruptions. The goal of the Alpha phase is to build the first line of defense, intercepting defects that could cause the smart home devices to completely fail.
[0041] Beta Phase (Diversity Testing): After successfully passing the monitoring and evaluation in the Alpha phase, the system automatically enters the Beta phase. The scheduler is updated to expand the deployment scope to 10%-20% of devices. The key to the Beta phase is selecting diverse smart home devices, covering different hardware models, software configurations, and physical deployment locations. The monitoring cycle in the Beta phase is extended to 48 hours for health assessment. The health analyzer's monitoring focus shifts to performance indicators (such as a sudden increase in average CPU / memory usage), business function anomalies (such as an increased failure rate of specific API calls), and driver compatibility issues. The goal of the Beta phase is to discover potential vulnerabilities that the firmware may expose in a wider range of environments.
[0042] RC (Responsible Controller) Phase: After passing both the Alpha and Beta phases, the system enters the RC phase, where the firmware is deployed on 40%-50% of devices to simulate a near-full-scale operating environment. The RC phase involves several days of monitoring for health assessments, focusing on identifying latent defects that only manifest under long-term operation and high concurrency pressure, such as slow memory leaks, resource contention under specific sequences, and cumulative performance degradation. The RC phase is the final quality checkpoint before the firmware is fully released.
[0043] Thus, the fact that the firmware has been updated and passed health assessments in the Alpha, Beta, and RC phases indicates that the new firmware version has successfully passed multi-level and systematic testing for fatal system anomalies, functional compatibility defects, and long-term stability risks in a complete progressive verification process from core internal testing and diverse external testing to large-scale stress testing. In other words, the new firmware is reliable and can be fully deployed to the entire smart home device cluster.
[0044] In this application embodiment, by conducting the first round of testing on a very small scale (such as 1%-5% of smart home devices in the smart home device cluster during the Alpha stage), fatal defects of the new firmware can be discovered early with minimal cost. In addition, by using a phased and gradually expanding testing approach, the compatibility and stability of the firmware under different hardware configurations and load scenarios can be systematically verified.
[0045] In one embodiment of this application, the method may further include: Acquire the health data stream of the smart home devices that are undergoing firmware updates at each stage; The health data stream is input into a preset multidimensional health assessment model to obtain the risk type corresponding to the smart home device output by the multidimensional health assessment model. For the smart home device of the aforementioned risk type, a rollback strategy corresponding to that risk type is triggered to restore the version of the smart home device to the version before the firmware update.
[0046] In this embodiment, the risk assessor of the central decision-making unit continuously receives health data streams from smart home devices at various stages, such as heart rate, CPU utilization, API call success rate, and network status. The risk assessor of the central decision-making unit runs a multi-dimensional health assessment model, which assigns dynamic weights to various indicators (such as device failure rate, performance deviation, and the range of affected device clusters) and calculates a quantified comprehensive risk score. Based on the comprehensive risk score, several risk types can be determined, including fatal risk, serious risk, and minor risk. Specifically, a fatal risk is characterized by the complete loss of smart home device services, collective failure of core functions, or the proportion of abnormal smart home devices exceeding a preset threshold (e.g., 30%). A severe risk is characterized by damage to some core functions of smart home devices, abnormal trends in system resources affecting user experience, but the main device itself can still operate. A minor risk is characterized by defects limited to non-core functions of smart home devices, warning logs that do not affect the main business, or occurrences only under edge conditions.
[0047] Once the risk type of a smart home device is determined, a corresponding rollback strategy can be executed based on the risk type to roll the smart home device back to the firmware version before the firmware update (or to other safe and reliable firmware versions), thereby ensuring the security of the smart home device.
[0048] In one embodiment of this application, triggering a rollback strategy corresponding to the risk type for the smart home device of the risk type may include: For smart home devices with a risk type classified as catastrophic, a rollback operation will be performed within a preset time range. For smart home devices with a risk type of "severe risk", a rollback operation is performed when the device is idle. For smart home devices with a risk type of minor risk, a regression operation is performed at a preset maintenance cycle.
[0049] In this embodiment, the strategy engine of the central decision-making unit automatically triggers a preset rollback strategy corresponding to the risk type output by the risk assessor. For critical risks, a global emergency rollback operation is immediately initiated. Specifically, through the highest priority communication channel, instructions are sent to all smart home devices running problematic versions, forcing them to perform a rollback operation within seconds, restarting and restoring to a known safe version. For severe risks, a local rapid rollback is initiated. Specifically, instructions are only sent to severely risky smart home devices that have already updated their firmware, requiring them to automatically perform a rollback operation within a few minutes of entering an idle state after completing their currently executing tasks, minimizing disruption to business processes. For minor risks, a silent delayed rollback is adopted. Specifically, the rollback operation is not executed immediately, but rather the rollback instruction is bound to the smart home device's preset maintenance cycle (such as the off-peak period of the following early morning), completing the firmware version switch without the user's awareness.
[0050] As can be seen, the embodiments of this application establish a rollback strategy system that precisely matches the risk type. Specifically, the system can automatically classify the identified risks into multiple risk types (also known as risk levels), such as minor risks, serious risks, and fatal risks, based on real-time monitoring of the health data stream of smart home devices. Different rollback strategies are configured for each risk type. These rollback strategies differ in terms of the urgency of the rollback, the timing of execution, and the scope of impact. For example, rollback strategies may include silent delayed rollback for minor risks, local rapid rollback for serious risks, and global emergency rollback for fatal risks, thereby realizing on-demand response to abnormal situations of smart home devices.
[0051] For example, refer to Figure 2 This is a flowchart of a firmware update process for a smart home device cluster provided in this application embodiment. The specific update process can be as follows: The central decision-making unit releases new firmware to the smart home device cluster. During the Alpha phase, firmware updates are performed on smart home devices, followed by a health assessment. If the health assessment passes in the Alpha phase, the device enters the Beta phase; otherwise, a tiered rollback mechanism is implemented. During the Beta phase, firmware updates are performed on smart home devices, followed by a health assessment. If the Beta phase health assessment passes, the device enters the RC phase; otherwise, a tiered rollback mechanism is implemented. During the RC phase, firmware updates are performed on smart home devices, followed by a health assessment. If the RC phase health assessment passes, the new firmware is fully deployed to the smart home device cluster; otherwise, a tiered rollback mechanism is implemented. In the tiered rollback mechanism, if a serious risk is identified, a partial fast rollback is initiated; if a minor risk is identified, a silent delayed rollback is adopted, thereby rolling the smart home device back to a safe and reliable firmware version, thus ensuring the security of the smart home device.
[0052] It is understood that, since the embodiments of this application can adopt the most appropriate rollback strategy for different types of risks, it can effectively avoid unnecessary interference with the core business of smart home devices and ensure the continuity of system services. In addition, the diversified rollback strategies enable the system to cope with various update anomalies more calmly and intelligently, thereby improving the overall responsiveness and stability of the system.
[0053] In one embodiment of this application, after the smart home devices have undergone firmware updates and passed health assessments at all stages of the multi-stage progressive pilot strategy, and after updating the firmware of the smart home devices in the smart home device cluster that have not yet undergone firmware updates, the method may further include: Record the firmware version for firmware updates in the whitelist; When the smart home device triggers verification, it verifies whether the firmware version of the smart home device is in the whitelist; If the firmware version of the smart home device is not in the whitelist, then the firmware of the smart home device will be updated according to the firmware version in the whitelist.
[0054] In this embodiment of the application, a distributed security version whitelist is deployed in the system to achieve immune memory. Specifically, the version identifier and cryptographic hash value of all firmware versions that have successfully passed all multi-stage tests of the phased incremental pilot strategy or have been proven to be stable and reliable through long-term operation will be permanently recorded in the whitelist.
[0055] When smart home devices trigger verification, such as during device startup, system recovery, or the connection of a new device, verification is performed. At this time, the whitelist serves as the sole authoritative source for verifying the firmware legitimacy of smart home devices, ensuring from the outset that the smart home device cluster always operates within a healthy and trustworthy software ecosystem. Specifically, the whitelist verifies whether the smart home device's firmware version is on the whitelist. If the firmware version is not on the whitelist, it indicates that the firmware version is unreliable. The whitelisted firmware version is then updated to ensure the device's security. Conversely, if the firmware version is on the whitelist, it indicates that the firmware version is reliable, and no further action is required.
[0056] As can be seen, this application embodiment constructs an automated closed-loop system integrating status monitoring, intelligent assessment, policy decision-making, and execution. It introduces a whitelist of secure versions as the system's long-term memory. Through the collaboration of the central decision-making unit and the device-side health monitoring agent, an autonomous cycle of monitoring, assessment, decision-making, and response is formed. Simultaneously, information on all verified firmware versions (such as version identifiers and cryptographic hash values) is recorded in a trusted whitelist of secure versions, serving as the sole authorization basis for triggering critical events by smart home devices, such as smart home device startup and the inclusion of new smart home devices. Thus, from problem detection (such as health assessment and risk assessment) to handling and recovery, the entire process requires no manual intervention, achieving efficient and accurate autonomous operation. The secure version whitelist mechanism ensures that the smart home cluster always operates on a known security baseline, effectively preventing the recurrence of historical security vulnerabilities and the degradation of device status.
[0057] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of this application.
[0058] Reference Figure 3 This paper illustrates a structural block diagram of a firmware update device for a smart home device cluster provided in an embodiment of this application. The smart home device cluster includes multiple smart home devices, and the device may specifically include the following modules: The multi-stage progressive pilot module 301 is used to update the firmware of the smart home devices in each stage according to a preset multi-stage progressive pilot strategy. In each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so that they can continue to the next stage after passing the health assessment. The number of smart home devices that are updated in the next stage is greater than the number of smart home devices that are updated in the previous stage. The device firmware update module 302 is used to update the firmware of smart home devices in the smart home device cluster that have not been updated when the smart home devices have been updated in all stages of the multi-stage progressive pilot strategy and the health assessment has passed.
[0059] In one embodiment of this application, the multi-stage progressive pilot strategy includes at least a first stage, a second stage, and a third stage in sequence; the multi-stage progressive pilot module 301 is used for: A first set of smart home devices is selected from the smart home devices according to the first device selection criteria corresponding to the first stage. The firmware of the first set of smart home devices is updated, and the first set of smart home devices with updated firmware is subjected to a health assessment according to the first health assessment strategy corresponding to the first stage. After the first stage health assessment is passed, a second set of smart home devices is selected from the smart home devices according to the second device screening criteria corresponding to the second stage. The firmware of the second set of smart home devices is updated, and the second set of smart home devices with updated firmware is subjected to a health assessment according to the second health assessment strategy corresponding to the second stage. After the second-stage health assessment is passed, a third set of smart home devices is selected from the smart home devices according to the third device screening criteria corresponding to the third stage. The firmware of the third set of smart home devices is updated, and the third set of smart home devices with updated firmware is subjected to a health assessment according to the third health assessment strategy corresponding to the third stage.
[0060] In one embodiment of this application, the first smart home device set, the second smart home device set, and the third smart home device set are different smart home devices.
[0061] In one embodiment of this application, the first device screening criterion is based on reliability and business criticality; the second device screening criterion is based on diversity screening; and the third device screening criterion is based on a preset device ratio.
[0062] In one embodiment of this application, the first health assessment strategy is used to monitor and assess whether a specified fatal anomaly occurs in the first smart home device set during a first monitoring period; the second health assessment strategy is used to monitor and assess the performance indicators, business function anomalies, and compatibility of the second smart home device set during a second monitoring period; and the third health assessment strategy is used to monitor and assess whether there are latent defects in the third smart home device set during a third monitoring period; wherein the second monitoring period is longer than the first monitoring period, and the third monitoring period is longer than the second monitoring period.
[0063] In one embodiment of this application, the apparatus further includes: a risk processing module, used for: Acquire the health data stream of the smart home devices that are undergoing firmware updates at each stage; The health data stream is input into a preset multidimensional health assessment model to obtain the risk type corresponding to the smart home device output by the multidimensional health assessment model. For the smart home device of the aforementioned risk type, a rollback strategy corresponding to that risk type is triggered to restore the version of the smart home device to the version before the firmware update.
[0064] In one embodiment of this application, the risk processing module is used for: For smart home devices with a risk type classified as catastrophic, a rollback operation will be performed within a preset time range. For smart home devices with a risk type of "severe risk", a rollback operation is performed when the device is idle. For smart home devices with a risk type of minor risk, a regression operation is performed at a preset maintenance cycle.
[0065] In one embodiment of this application, the device further includes: a whitelist module, used for: Record the firmware version for firmware updates in the whitelist.
[0066] In one embodiment of this application, the device further includes a whitelist verification module, used for: When the smart home device triggers verification, it verifies whether the firmware version of the smart home device is in the whitelist; If the firmware version of the smart home device is not in the whitelist, then the firmware of the smart home device will be updated according to the firmware version in the whitelist.
[0067] In this embodiment, the smart home device cluster includes multiple smart home devices. When a firmware update is required for the entire smart home device cluster, the firmware is updated sequentially at each stage according to a preset multi-stage progressive pilot strategy. In each stage, the smart home devices that have already had their firmware updated undergo a health assessment according to the corresponding health assessment strategy. If the health assessment is passed, the device can proceed to the next stage. The number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. Subsequently, when the smart home devices have undergone firmware updates and passed the health assessments in all stages of the multi-stage progressive pilot strategy, the smart home devices in the smart home device cluster that have not yet undergone firmware updates undergo firmware updates. In this embodiment, the firmware of smart home devices is updated sequentially in multiple stages according to a preset multi-stage progressive pilot strategy. Only after the health assessment of the previous stage is passed can the next stage be continued. Furthermore, the number of smart home devices undergoing firmware updates is gradually increased in stages, thereby effectively controlling the scope of risks in the firmware update process of the smart home device cluster. This allows for the early detection of fatal defects at the lowest cost, avoiding risks to the entire smart home device cluster and improving the robustness and reliability of the smart home device cluster.
[0068] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment. This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 1001, a device interface 1002, a memory 1003, and a bus 1004; Memory 1003 is used to store computer programs; The processor 1001 executes the above steps when executing the program stored in the memory 1003.
[0069] The bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.
[0070] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0071] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0072] This application also provides a storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to execute the smart home device cluster firmware update method of the foregoing embodiments.
[0073] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. The structure required to construct such a device is obvious from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages is for the purpose of disclosing the best mode of implementation of this application.
[0074] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0075] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.
[0076] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.
[0077] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sequencing device according to this application. This application can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can take the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
[0078] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.
[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0080] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.
[0081] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0082] It should be noted that the various data-related processes in the embodiments of this application are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.
Claims
1. A method for updating firmware of a smart home device cluster, characterized in that, The smart home device cluster includes multiple smart home devices, and the method includes: According to the preset multi-stage gradual pilot strategy, the firmware of the smart home devices is updated sequentially in each stage; wherein, in each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so as to continue to the next stage after the health assessment is passed; the number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. When the firmware of the smart home devices is updated and the health assessment is passed in all stages of the multi-stage progressive pilot strategy, the firmware of the smart home devices in the smart home device cluster that have not been updated is updated.
2. The method according to claim 1, characterized in that, The multi-stage incremental pilot strategy includes at least a first stage, a second stage, and a third stage in sequence; the step of updating the firmware of the smart home device sequentially in each stage according to the preset multi-stage incremental pilot strategy includes: A first set of smart home devices is selected from the smart home devices according to the first device selection criteria corresponding to the first stage. The firmware of the first set of smart home devices is updated, and the first set of smart home devices with updated firmware is subjected to a health assessment according to the first health assessment strategy corresponding to the first stage. After the first stage health assessment is passed, a second set of smart home devices is selected from the smart home devices according to the second device screening criteria corresponding to the second stage. The firmware of the second set of smart home devices is updated, and the second set of smart home devices with updated firmware is subjected to a health assessment according to the second health assessment strategy corresponding to the second stage. After the second-stage health assessment is passed, a third set of smart home devices is selected from the smart home devices according to the third device screening criteria corresponding to the third stage. The firmware of the third set of smart home devices is updated, and the third set of smart home devices with updated firmware is subjected to a health assessment according to the third health assessment strategy corresponding to the third stage.
3. The method according to claim 2, characterized in that, The first set of smart home devices, the second set of smart home devices, and the third set of smart home devices are different smart home devices.
4. The method according to claim 2, characterized in that, The first equipment screening criterion is based on reliability and business criticality; the second equipment screening criterion is based on diversity; and the third equipment screening criterion is based on a preset equipment ratio.
5. The method according to claim 2, characterized in that, The first health assessment strategy is used to monitor and assess whether a specified fatal anomaly occurs in the first smart home device set during a first monitoring period; the second health assessment strategy is used to monitor and assess the performance indicators, business function anomalies, and compatibility of the second smart home device set during a second monitoring period; the third health assessment strategy is used to monitor and assess whether there are hidden defects in the third smart home device set during a third monitoring period; wherein, the second monitoring period is longer than the first monitoring period, and the third monitoring period is longer than the second monitoring period.
6. The method according to claim 1, characterized in that, The method further includes: Acquire the health data stream of the smart home devices that are undergoing firmware updates at each stage; The health data stream is input into a preset multidimensional health assessment model to obtain the risk type corresponding to the smart home device output by the multidimensional health assessment model. For the smart home device of the aforementioned risk type, a rollback strategy corresponding to that risk type is triggered to restore the version of the smart home device to the version before the firmware update.
7. The method according to claim 6, characterized in that, The triggering of the rollback strategy corresponding to the risk type for the smart home device of the risk type includes: For smart home devices with a risk type classified as catastrophic, a rollback operation will be performed within a preset time range. For smart home devices with a risk type of "severe risk", a rollback operation is performed when the device is idle. For smart home devices with a risk type of minor risk, a regression operation is performed at a preset maintenance cycle.
8. The method according to claim 1, characterized in that, After the smart home devices have undergone firmware updates and passed health assessments at all stages of the multi-stage progressive pilot strategy, and the remaining smart home devices in the smart home device cluster that have not undergone firmware updates have undergone firmware updates, the method further includes: Record the firmware version for firmware updates in the whitelist.
9. The method according to claim 8, characterized in that, After recording the firmware version of the firmware update in the whitelist, the method further includes: When the smart home device triggers verification, it verifies whether the firmware version of the smart home device is in the whitelist; If the firmware version of the smart home device is not in the whitelist, then the firmware of the smart home device will be updated according to the firmware version in the whitelist.
10. A firmware update device for a smart home device cluster, characterized in that, The smart home device cluster includes multiple smart home devices, and the device includes: The multi-stage progressive pilot module is used to update the firmware of the smart home devices sequentially in each stage according to a preset multi-stage progressive pilot strategy. In each stage, the smart home devices with updated firmware are subjected to a health assessment according to the health assessment strategy corresponding to the stage, so that they can continue to the next stage after passing the health assessment. The number of smart home devices that undergo firmware updates in the next stage is greater than the number of smart home devices that undergo firmware updates in the previous stage. The device firmware update module is used to update the firmware of smart home devices in the smart home device cluster that have not been updated when the smart home devices have been updated in all stages of the multi-stage progressive pilot strategy and the health assessment has passed.
11. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute the instructions to implement the smart home device cluster firmware update method as described in any one of claims 1 to 9.
12. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the mobile terminal, the mobile terminal is able to perform the smart home device cluster firmware update method as described in any one of claims 1 to 9.