Digital farm wisdom management system

Abstract

The application discloses a digital farm intelligent management system and relates to the technical field of intelligent management, and solves the problem that unattended field edge equipment cannot keep stable operation and safely complete remote upgrading in all seasons. For a large number of solar-powered edge sensing devices deployed in a digital farm, an artificial intelligence algorithm is used to predict the environmental energy supply and dynamically adjust the device task mode, and a self-health monitoring and progressive firmware upgrading mechanism is used to ensure that the devices can continuously and reliably operate under various weather conditions throughout the year and safely complete remote updating of firmware without interrupting business.

Description

Technical Field

[0001] This invention relates to the field of intelligent management technology, and more specifically, to an intelligent management system for digital farms. Background Technology

[0002] Digital farms typically deploy numerous sensors and control devices across vast fields for environmental data collection, crop monitoring, and irrigation control. These devices are often unattended and powered by solar cells, resulting in significant energy limitations depending on the season and weather. They can easily cease operation due to power depletion or extreme conditions. Furthermore, with the development of agricultural IoT technology, remote over-the-air (OTA) firmware updates have become essential for maintaining device functionality and security. Power outages or other malfunctions during upgrades can corrupt firmware, rendering the equipment inoperable. Therefore, ensuring stable year-round operation of field equipment under energy-constrained conditions, while also safely performing remote firmware upgrades, is a pressing issue that needs to be addressed.

[0003] To address the above problems, this invention proposes a solution. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a digital farm intelligent management system to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A smart management system for digital farms includes: an evaluation and mode selection module, a mode upgrade and downgrade module, a gray-scale batch determination module, and a verification and rollback module, with signal connections between the modules;

[0007] The evaluation and mode selection module obtains the available light energy prediction value and the current remaining battery power for the dual firmware partitions respectively. After deducting the minimum energy consumption required for the device to maintain a specified cycle, a safety margin is obtained. The module then selects between low-frequency task mode and high-frequency or low-frequency task mode based on the current task completion rate.

[0008] The mode upgrade / downgrade module uses a health probe to monitor the CPU usage and recent reset count in real time, and calculates the running health score to determine the boot partition and backup partition in the dual firmware partition;

[0009] The gray-scale batch determination module sets an upper limit on the number of devices with tolerable functional failures in a single batch, assigns an average business criticality to gray-scale devices, obtains a risk budget, and calculates the number of gray-scale devices in the first batch by combining the historical over-the-air download failure rate, while ensuring that at least one device of each hardware model is sampled.

[0010] The verification and rollback module writes the candidate firmware image to the backup partition and restarts. The flags of the boot partition and backup partition are swapped. The grayscale observation window is entered to continuously monitor the number of abnormal operation health scores, the number of automatic resets, and the critical task false alarm rate. If the grayscale is determined to have failed, it switches back to the old boot partition. If no abnormality is found in the grayscale observation window, it is considered to have passed. The grayscale range is then expanded by a fixed factor, and the process is repeated until all devices are updated.

[0011] In a preferred embodiment, the evaluation and mode selection module includes the following steps:

[0012] The device is divided into firmware partition A and firmware partition B. The available light energy prediction value and the current remaining battery power are obtained for each firmware partition. After deducting the minimum energy consumption required for the device to maintain a specified period, the safety margin of each firmware partition is obtained.

[0013] When the firmware partition security margin is negative, switch to low-frequency task mode;

[0014] When the security margin of the firmware partition is zero or positive, if the task completion rate is lower than the preset threshold, it will enter the high-frequency task mode; if the task completion rate reaches the preset threshold, it will maintain or switch to the low-frequency task mode.

[0015] In a preferred embodiment, the mode upgrade / downgrade module includes the following steps:

[0016] The CPU utilization rate and the number of resets in the previous specified period are collected in real time by a health probe. The number of resets in the previous specified period is normalized and weighted with the CPU utilization rate to calculate the running health score.

[0017] When the health score falls below the preset low threshold, local self-repair is triggered and a forced switch to low-frequency task mode is initiated.

[0018] When the score exceeds the preset high score threshold, it will be automatically downgraded to low-frequency task mode.

[0019] When the score stabilizes between the preset low score threshold and the preset high score threshold, maintain or gradually restore the high-frequency task mode.

[0020] The firmware partition with the higher health score is marked as the boot partition, and the other firmware partition is marked as the spare partition.

[0021] In a preferred embodiment, the grayscale batch determination module includes the following steps:

[0022] Set an upper limit on the number of device function failures that can be tolerated in a single batch of upgrades, and assign an average business criticality;

[0023] The risk budget for this phased rollout is obtained by multiplying the maximum number of tolerable device malfunctions by the average business criticality.

[0024] By combining the historical failure rate of OTA upgrades in the past, the product of the number of devices in the first phase of gray-scale upgrades and the historical failure rate shall not exceed the risk budget.

[0025] Based on the calculated number of devices for the first phase of gray-scale upgrades, one device for each model is randomly selected. From the remaining candidate devices, devices with higher safety margins and lower business criticality are selected to be added to the first phase of gray-scale upgrades until the number of devices for the first phase of gray-scale upgrades is met. The set of devices for the first phase of gray-scale upgrades is then output.

[0026] In a preferred embodiment, the verification and rollback module includes the following steps:

[0027] Write the candidate firmware image to the spare partition and reboot the device, then swap the boot partition and spare partition flags; monitor the number of abnormal health scores, the number of automatic resets, and the critical task miss rate within the grayscale observation window;

[0028] If any monitoring metric exceeds the threshold, the grayscale test is deemed a failure and the system is rolled back to the old boot partition.

[0029] If all indicators are normal, the number of devices to be upgraded in the next batch will be increased by a fixed ratio, and this process will be repeated until all devices to be upgraded have been upgraded.

[0030] The technical effects and advantages of the digital farm intelligent management system of the present invention are as follows:

[0031] By using AI models to predict environmental energy such as solar radiation, the system adjusts the task execution frequency of equipment in advance to adapt to the energy supply in the coming days, thus ensuring continuous operation. Each device employs a dual-boot partition architecture to store firmware versions. Once a new firmware is released, it can be written to the backup partition and tested. After ensuring stability, it is then switched to the primary partition, thus avoiding the risk of the device failing to boot in the event of an upgrade failure. A health probe is embedded to monitor operating indicators such as CPU load and reset count in real time, calculating an operational health score to assess the device's status. When an anomaly is detected, the device can trigger local self-repair and reduce the frequency of its operating mode to prevent the fault from escalating; conversely, it maintains high-performance operation. During large-scale OTA upgrades, the system adopts a gradual gray-scale release strategy, upgrading a small batch of devices first, and then gradually expanding the scope after verification. These modules work together to build an intelligent management system that can autonomously adapt to changes in environmental energy, self-diagnose and repair, and safely and efficiently perform remote upgrades. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the structure of a digital farm intelligent management system according to the present invention;

[0033] Figure 2 This is a schematic diagram of the process of a digital farm intelligent management system according to the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] Example: Please refer to Figures 1-2 As shown, the present invention discloses a smart management system for digital farms, including: an evaluation and mode selection module, a mode upgrade and downgrade module, a gray-scale batch determination module, and a verification and rollback module, with signal connections between the modules;

[0036] The evaluation and mode selection module obtains the available light energy prediction value and the current remaining battery power for the dual firmware partitions respectively. After deducting the minimum energy consumption required for the device to maintain a specified cycle, a safety margin is obtained. The module then selects between low-frequency task mode and high-frequency or low-frequency task mode based on the current task completion rate.

[0037] The mode upgrade / downgrade module uses a health probe to monitor the CPU usage and recent reset count in real time, and calculates the running health score to determine the boot partition and backup partition in the dual firmware partition;

[0038] The gray-scale batch determination module sets an upper limit on the number of devices with tolerable functional failures in a single batch, assigns an average business criticality to gray-scale devices, obtains a risk budget, and estimates the number of gray-scale devices in the first batch by combining the historical over-the-air download failure rate, while ensuring that at least one device of each hardware model is sampled.

[0039] The verification and rollback module writes the candidate firmware image to the backup partition and restarts. The flags of the boot partition and backup partition are swapped. The grayscale observation window is entered to continuously monitor the number of abnormal operation health scores, the number of automatic resets, and the critical task false alarm rate. If the grayscale is determined to have failed, it switches back to the old boot partition. If no abnormality is found in the grayscale observation window, it is considered to have passed. The grayscale range is then expanded by a fixed factor, and the process is repeated until all devices are updated.

[0040] In the evaluation and mode selection module, the available light energy prediction value and the current remaining battery power are obtained for the dual firmware partitions. After deducting the minimum energy consumption required for the device to maintain a specified cycle, a safety margin is obtained. The module then selects between a low-frequency task mode and a high-frequency or low-frequency task mode based on the current task completion rate. Specific details include:

[0041] The device in this embodiment uses dual firmware partitions. Its storage space is divided into firmware partition A and firmware partition B, which respectively store two sets of bootable system firmware images. One set is used as the boot partition and the other set is used as a backup partition for firmware upgrades and rollbacks.

[0042] The information to be obtained from firmware partition A and firmware partition B includes: solar power supply and current remaining battery power.

[0043] Solar energy supply is predicted by AI models based on weather forecasts and historical data to determine the available solar energy supply within a specified period.

[0044] The current remaining battery power is obtained through the battery fuel gauge.

[0045] The safety margins for firmware partitions A and B are calculated based on the solar power supply and the remaining battery power, respectively. This means the energy surplus available for task execution within a specified period for the corresponding firmware partition. The difference between the solar power supply and the remaining battery power is the safety margin.

[0046] The minimum energy consumption required for the device to maintain basic operation for a specified period is the energy required to maintain communication heartbeat, clock and key sensor operation when the device is not performing high-load tasks during the specified period. This can be measured by historical operating data or experiments. For example, it requires 0.2Wh per day to maintain basic communication and core sensing.

[0047] If the safety margin of the firmware partition is zero or positive, it means that the energy is expected to be sufficient to support the normal operation of the device for the specified period without reducing the current task frequency; if the safety margin is negative, it means that the firmware partition may run out of energy in the next specified period if it operates in the current mode.

[0048] When the firmware partition safety margin is negative, it switches to low-frequency task mode. In low-frequency task mode, only the minimum critical sensing tasks are performed to minimize the frequency of sensor acquisition and data transmission in order to save energy consumption.

[0049] For example, a sensor that originally collected environmental data every 10 minutes may be changed to collect data once per hour in low-frequency task mode. However, critical sensors such as security monitoring will still maintain necessary operation. This frequency reduction operation can significantly reduce energy consumption and ensure that the equipment can still survive in the event of energy shortage, so as not to shut down due to power depletion.

[0050] If the safety margin is zero or positive, it indicates that the energy supply is relatively sufficient. However, in order to avoid wasting energy unnecessarily, the current task completion rate is added to determine whether to use the high-frequency task mode or the low-frequency task mode.

[0051] For example, if there are still important data acquisition tasks that have not been completed or have accumulated delays, and the task completion rate is low, then select to enter the high-frequency task mode to complete the task with a higher acquisition frequency and processing speed before the power is sufficient.

[0052] Conversely, if all tasks have been completed as planned and the task completion rate is high, even if there is a surplus of energy, the low-frequency task mode should be temporarily maintained or switched to optimize energy utilization efficiency.

[0053] In the mode upgrade / downgrade module, the CPU utilization and recent reset count are monitored in real time using health probes. A health score is calculated to determine the boot partition and backup partition in the dual firmware partitioning. Specific details include:

[0054] High-load tasks may cause equipment to overheat, exhaust resources, or even crash, while long-term low-load operation may waste the potential of the equipment. Therefore, it is necessary to dynamically adjust the task mode according to the health status of the equipment and obtain key operating indicators continuously collected by the health probe, including: CPU utilization and the number of resets in the previous specified period.

[0055] The current operating health score is calculated by weighting the CPU utilization rate and the number of resets in the previous specified period, which is used to quantify the quality of the device's operating status.

[0056] The normalized sum of the CPU utilization rate and the number of resets in the previous specified period is equal to one. Considering that a high CPU load has a greater impact on stability, the CPU utilization rate can be given a larger weight, for example, 70%.

[0057] When the health score is lower than the preset low threshold, such as below 60 points, it indicates that the device may be in an abnormal or sub-healthy state. In this case, a local self-repair process is triggered, and the device is forced to be downgraded to a low-frequency task mode.

[0058] The local self-healing process may include: terminating non-critical processes that consume too many resources, clearing the cache, reinitializing the sensor driver, or even performing a safe reboot to clear potential fault states. After the local self-healing is completed, the device switches to a low-frequency task mode to maintain only the operation of critical functions, thereby significantly reducing system load and power consumption, preventing the fault from deteriorating further, and ensuring that even if the device encounters software anomalies or resource bottlenecks, it can maintain operation at the lowest functional level and wait for maintenance, rather than completely failing.

[0059] When the health score is above the threshold and the device is running stably, the module maintains the existing task mode and allows the device to gradually return to a high-frequency task mode as needed.

[0060] The partition with the higher current health score is marked as the boot partition, while the other free partition is automatically marked as the standby partition. At this time, the firmware version of the boot partition that the device is running is recognized as a reliable version and recorded as the preferred version for the next boot.

[0061] When the operating health score is higher than the preset high threshold, the device is actively switched to a low-frequency task mode to temporarily reduce the frequency of image acquisition and analysis in order to avoid system crashes caused by overheating or insufficient memory. For example, if the CPU utilization rate is kept above 90% for a long time due to continuous processing of high-definition images, the health probe will detect this state and cause the operating health score to gradually decrease. After the analysis task is completed or the device load returns to normal, the module will allow the device to return to the high-frequency mode to continue working.

[0062] It should be noted that, to ensure timely degradation of the equipment in the event of an anomaly, the preset low threshold for the score can be set to 0.6. That is, when the operating health score is below 0.6, self-repair should be performed and the device should be forced into a low-frequency task mode. To prevent possible overload in advance, the preset high threshold for the score can be set to 0.9. This is used to determine overheating or prolonged high load. When the high threshold is exceeded, the sampling frequency should be actively reduced. The initial setting of the threshold should be combined with a large amount of historical data from the equipment and optimized through simulation or small-scale trial operation. It should be set by technical personnel according to the actual situation.

[0063] In the mode upgrade / downgrade module, the CPU utilization and recent reset count are monitored in real time using health probes. A health score is calculated to determine the boot partition and backup partition in the dual firmware partitioning. Specific details include:

[0064] When performing firmware upgrades, a decision is made on how to gradually push the update to the device group in batches to keep the risks within a manageable range. Considering that upgrading all devices at once may cause widespread failures, a risk-driven incremental release strategy is adopted, and the specific steps are as follows:

[0065] Set an upper limit on the number of device malfunctions that can be tolerated in a single batch of upgrades. This can be based on operational experience and business requirements. For example, it can be stipulated that no more than 2 devices in each batch are allowed to malfunction due to upgrade failures and thus be unable to work properly.

[0066] Assign an average business criticality to the equipment to be upgraded, based on its importance in farm operations, reflecting the importance of the equipment in the production process. For example, setting an irrigation control node may be more critical than a regular environmental sensor. The irrigation control node can be rated 1.0, while a regular temperature sensor can be rated 0.3. The score can be taken by the operation and maintenance team based on business experience, taking the average of these devices as the average business criticality to measure the impact of a single device failure on the business.

[0067] Multiply the maximum number of tolerable device failures by the average business criticality to obtain the risk budget for this gray-scale upgrade. This represents the total business impact that a single batch of upgrades can bear. For example, if a single batch tolerates the failure of 2 devices and the average criticality of each device is 0.5, then the risk budget is equivalent to the impact of the failure of 1 highly critical device.

[0068] Based on the historical failure rate of OTA upgrades, such as an average of 5% failure rate in past upgrades, determine the number of devices to be upgraded in the first phase of gray-scale upgrades, ensuring that the product of the number of devices to be upgraded in the first phase and the historical failure rate does not exceed the risk budget.

[0069] For example, if the risk budget allows for the failure of one critical device and the historical failure rate is 5%, then the number of devices to be upgraded in the first phase of gray-scale upgrades is 20.

[0070] Based on the calculation of the number of devices to be upgraded in the first phase, ensure that at least one device of each hardware model is selected to be added to the first upgrade list. Since different hardware versions may have different compatibility with the new firmware, this step can identify potential problems of specific device models in advance. If some device models are not included, at least one of each model should be added. This adjustment may slightly increase the total number of devices in the first phase.

[0071] It should be noted that the initial equipment selection method is as follows: according to the instruction manual, at least one of each hardware model should be selected. If the number of models exceeds the initial limit, one of each model can be randomly selected first. After the model coverage is met, equipment with higher safety margin and lower business criticality will be selected from the remaining candidate equipment to be added to the first batch to reduce risk. To avoid concentration in a certain region or a certain production link, random sampling or stratified sampling strategies can be adopted to ensure that different regions and different production links are representative.

[0072] A safe initial set of devices for gray-scale upgrades has been output. If this batch performs well, it will lay the foundation for gradually expanding the upgrade scope; otherwise, the impact can be limited to this batch to prevent it from affecting the entire system. In addition, for a small number of devices that are extremely critical to the business, they can be scheduled for upgrade in the last batch to ensure that the new firmware has been fully verified and stabilized in the previous gray-scale batches before these critical devices receive the upgrade.

[0073] In the verification and rollback module, the candidate firmware image is written to the backup partition and the system restarts. The flags of the boot partition and backup partition are swapped. The system then enters a grayscale observation window, continuously monitoring the number of abnormal health scores, the number of automatic resets, and the critical task false alarm rate. If the grayscale update fails, it switches back to the old boot partition. If no abnormalities are found in the grayscale observation window, it is considered successful, and the grayscale range is expanded at a fixed rate. This process is repeated until all devices are updated. Specific details include:

[0074] Once the device obtains the first batch of devices for gray-scale upgrade, it first writes the candidate firmware image to the backup partition, then reboots the device and runs the backup partition.

[0075] For example, if the device's current boot partition is firmware partition A, then the candidate firmware image will be written to firmware partition B, and vice versa. During this process, the firmware in the boot partition remains unchanged, and the normal operation of the device is unaffected.

[0076] The device is rebooted and a new firmware version of the candidate firmware image is loaded from the spare partition. The spare partition is marked as the boot partition, and the boot partition is changed to the spare partition, i.e. the boot partition and spare partition flags are swapped.

[0077] After the partition flag switch is completed, the new version of the boot partition starts running. Set a grayscale observation window, such as 24 hours, and focus on monitoring key indicators including: the number of abnormal operation health scores, the number of automatic resets, and the missed detection rate of critical tasks.

[0078] Number of abnormal operation health scores: This refers to the number of times the operation health score is lower than the preset low score threshold. If the new firmware has performance issues, the operation health score may frequently fall below the preset low score threshold, indicating that abnormal conditions occur too frequently.

[0079] Automatic reset count: Monitors whether the device experienced any abnormal restarts during the observation period. If the device keeps restarting after running new firmware, it indicates that the new firmware may contain serious errors;

[0080] Critical task underreporting rate: This is the percentage of critical tasks that are underreported or not completed on time. If this results in certain critical functions not being executed as expected, the underreporting rate will increase.

[0081] It should be noted that during the gray-scale observation window, services such as irrigation control command issuance, emergency alarms for temperature and humidity / soil moisture, and video monitoring alarms can be set as key tasks. The expected number of executions and the actual number of successful executions on time can be continuously recorded, and the missed report rate can be calculated as one minus the ratio of the number of successful executions on time to the number of expected executions.

[0082] Thresholds are set for the number of abnormal health scores, the number of automatic resets, and the false alarm rate of critical tasks, respectively, and are denoted as the abnormal number threshold, the reset number threshold, and the false alarm rate threshold. Once any of the above monitoring indicators exceeds the corresponding threshold, the first batch of gray-scale upgrades is determined to fail. When the device is restarted for the next time, the device will be automatically switched back to the old boot partition through the Bootloader. With the help of this rollback mechanism of the dual partition architecture, even if the upgraded device fails, it can automatically restore to the normal state before the upgrade and will not be offline for a long time.

[0083] It should be noted that the threshold for the number of anomalies can be set to 5, and the threshold for the number of resets can be set to 2. If the baseline is extremely low, at least 2 fault tolerances should be reserved in engineering to avoid rollback due to occasional jitter. The threshold for the false negative rate can be set to 2%. Based on the maximum business loss that production can tolerate, it may affect irrigation or alarms and directly trigger rollback. The specific settings should be made by technical personnel in the field according to the actual situation.

[0084] If no abnormalities occur during the grayscale observation window, meaning all indicators are within the normal range, the new firmware is considered to have passed the first batch of grayscale upgrades, and the grayscale range will be expanded according to the predetermined fixed ratio.

[0085] For example, the number of devices to be upgraded will be doubled in each round. After the first batch of pilot upgrades is successful, the second batch will push the number of devices to be upgraded to twice the number of devices in the first batch of gray-scale upgrades, and enter a new round of observation. If it is still stable, it will be expanded to the third batch of devices with about four times the number of devices in the first batch of gray-scale upgrades, and so on. Through exponential multiplication, after several rounds of iteration, all devices can be covered and the upgrade can be completed.

[0086] For example, if the first batch of devices to be upgraded in the gray-scale phase consists of 20 devices, the upgrade of thousands of devices can be completed in about four to five rounds using the doubling strategy. During the process, if any batch has an anomaly, the rollback mechanism will be triggered to stop the upgrade; otherwise, the upgrade will proceed as planned until the entire network is updated.

[0087] This step-by-step verification and rollback strategy ensures the security and reliability of OTA upgrades: problems can be detected on a small scale and losses can be stopped in time to prevent the fault from spreading rapidly to the entire device network. That is, small-scale pilot testing, real-time monitoring of the effect and the ability to roll back at any time are implemented. This realizes an automated phased upgrade and fault rollback mechanism, ensuring that unattended devices can complete remote firmware upgrades smoothly without human intervention and without affecting production.

[0088] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0089] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0090] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0092] 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 scope of the technology 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.

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

Claims

1. A smart management system for digital farms, characterized in that, Signal connections between modules; The evaluation and mode selection module obtains the available light energy prediction value and the current remaining battery power for the dual firmware partitions respectively. After deducting the minimum energy consumption required for the device to maintain a specified cycle, a safety margin is obtained. The module then selects between low-frequency task mode and high-frequency or low-frequency task mode based on the current task completion rate. The mode upgrade / downgrade module uses a health probe to monitor the CPU usage and recent reset count in real time, and calculates the running health score to determine the boot partition and backup partition in the dual firmware partition; The gray-scale batch determination module sets an upper limit on the number of devices with tolerable functional failures in a single batch, assigns an average business criticality to gray-scale devices, obtains a risk budget, and calculates the number of gray-scale devices in the first batch by combining the historical over-the-air download failure rate, while ensuring that at least one device of each hardware model is sampled. The verification and rollback module writes the candidate firmware image to the backup partition and restarts. The flags of the boot partition and backup partition are swapped. The grayscale observation window is entered to continuously monitor the number of abnormal operation health scores, the number of automatic resets, and the critical task false alarm rate. If the grayscale is determined to have failed, it switches back to the old boot partition. If no abnormality is found in the grayscale observation window, it is considered to have passed. The grayscale range is then expanded by a fixed factor, and the process is repeated until all devices are updated.

2. The intelligent management system for digital farms according to claim 1, characterized in that: The dual firmware partitions include firmware partition A and firmware partition B. The available light energy prediction value and the current remaining battery power are obtained for each dual firmware partition. After deducting the minimum energy consumption required for the device to maintain a specified period, the safety margin of each firmware partition is obtained.

3. The intelligent management system for digital farms according to claim 2, characterized in that: When the firmware partition security margin is negative, switch to low-frequency task mode; When the security margin of the firmware partition is zero or positive, if the task completion rate is lower than the preset threshold, it will enter the high-frequency task mode. If the task completion rate reaches the preset threshold, the task will be maintained or switched to a low-frequency task mode.

4. The intelligent management system for digital farms according to claim 1, characterized in that: The CPU utilization rate and the number of resets in the previous specified period are collected in real time by a health probe. The number of resets in the previous specified period is normalized and weighted with the CPU utilization rate to calculate the running health score. When the health score falls below the preset low threshold, local self-repair is triggered and a forced switch to low-frequency task mode is initiated. When the score exceeds the preset high score threshold, it will be automatically downgraded to low-frequency task mode. When the score stabilizes between the preset low score threshold and the preset high score threshold, maintain or gradually restore the high-frequency task mode.

5. The intelligent management system for digital farms according to claim 4, characterized in that: The firmware partition with the higher health score is marked as the boot partition, and the other firmware partition is marked as the spare partition.

6. The intelligent management system for digital farms according to claim 1, characterized in that: Set an upper limit on the number of device function failures that can be tolerated in a single batch of upgrades, and assign an average business criticality; The risk budget for this phased rollout is obtained by multiplying the maximum number of tolerable device malfunctions by the average business criticality. Based on the historical failure rate of OTA upgrades, the product of the number of devices to be upgraded in the first phase and the historical failure rate is kept within the risk budget. The number of devices to be upgraded in the first phase is then calculated.

7. A digital farm intelligent management system according to claim 6, characterized in that: Based on the calculated number of devices for the first phase of gray-scale upgrades, one device for each model is randomly selected. From the remaining devices to be upgraded, devices with higher safety margins and lower business criticality are selected to be added to the first phase of gray-scale upgrades until the number of devices for the first phase of gray-scale upgrades is met. The set of devices for the first phase of gray-scale upgrades is then output.

8. The intelligent management system for digital farms according to claim 1, characterized in that: Write the candidate firmware image to the spare partition and reboot the device, then swap the boot partition and spare partition flags; monitor the number of abnormal health scores, the number of automatic resets, and the critical task miss rate within the grayscale observation window; If any monitoring metric exceeds the threshold, the grayscale test is deemed a failure and the system is rolled back to the old boot partition. If all indicators are normal, the number of devices to be upgraded in the next batch will be increased by a fixed ratio, and this process will be repeated until all devices to be upgraded have been upgraded.

Images