Out-of-band asynchronous secure configuration and state rollback method and system for heterogeneous edge nodes

Abstract

The application discloses an out-of-band asynchronous security configuration and state rollback method and system of a heterogeneous edge node, relates to the field of edge computing, and comprises the following steps: receiving an encrypted configuration package carrying difference configuration data and an update risk level through an out-of-band communication channel, and completing integrity, legality verification and decryption based on a hardware trust root; collecting real-time running indexes, combining historical health baselines to perform heterogeneous weighted normalization processing, and calculating a health score; dynamically determining an adaptive confirmation time window according to the health score and the update risk level; generating a differential snapshot before applying the difference configuration data, and performing local configuration updating without synchronization with other edge nodes; continuously monitoring the health score after updating within the confirmation time window, triggering rollback based on the differential snapshot when an exception occurs or a confirmation instruction is not received, and otherwise solidifying the update. Thus, the application realizes trusted delivery, dynamic confirmation and safe recovery of configuration updating in a restricted network environment.

Description

Technical Field

[0001] This application relates to the fields of edge computing network security and configuration control technology, and in particular to an out-of-band asynchronous security configuration and state rollback method and system for heterogeneous edge nodes. Background Technology

[0002] With the continuous development of the Internet of Things (IoT) and edge computing, computing and control capabilities are gradually shifting towards the edge, closer to the data source, forming a heterogeneous edge node system composed of various devices such as sensors, smart gateways, and microservers. These nodes are widely distributed in complex application scenarios such as industrial control, energy, and transportation, often undertaking tasks such as on-site data acquisition, local processing, and business linkage. Due to the complexity of the deployment environment and the variability of network conditions, some edge nodes operate in a state of weak network, intermittent network, or even relative isolation for extended periods, making it difficult for their configuration management and status control to fully rely on continuous and stable online connections.

[0003] Currently, configuration updates for edge nodes typically involve a central platform distributing the updates and nodes receiving and executing them online, or manual intervention for offline updates when nodes cannot maintain a continuous network connection. While these methods generally meet basic management needs, they often lack the flexible control capabilities to adapt to node operating status, resource differences, and environmental changes in constrained network environments. When configuration change processes still rely primarily on fixed procedures or static strategies, it becomes difficult to accommodate the differences in execution timing and confirmation methods among different types of nodes. Furthermore, unstable links or blocked feedback can easily lead to decreased configuration execution efficiency and inaccurate rollback decisions, thus affecting the stability and continuity of node-side configuration updates.

[0004] Furthermore, when heterogeneous edge nodes operate collaboratively in groups or clusters, configuration management not only involves the security of updates for individual nodes but also relates to the state coordination among multiple nodes and the overall business continuity. If nodes primarily rely on their local conditions to independently handle configuration recovery in abnormal situations, it is often difficult to consider the business relationships, importance, and global operational status between nodes. This can easily lead to imbalances in the processing rhythm of multiple nodes, the spread of local anomalies, or fluctuations in overall service, thereby limiting the stability and adaptability of configuration management in complex scenarios to some extent. Summary of the Invention

[0005] This application provides an out-of-band asynchronous security configuration and state rollback method, system, storage medium, computer program product, and electronic device for heterogeneous edge nodes, which at least solves the problem of lack of flexible security control in the edge node configuration update process in the prior art.

[0006] In a first aspect, embodiments of this application provide an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes, applied to a target edge node. The method includes: receiving an encrypted configuration packet through an out-of-band communication channel, the encrypted configuration packet carrying differential configuration data and an update risk level corresponding to the differential configuration data; performing integrity verification, legality verification, and decryption on the encrypted configuration packet based on a local hardware root of trust to extract the differential configuration data and the update risk level; collecting real-time operating indicators and performing heterogeneous weighted normalization processing on the real-time operating indicators in conjunction with a pre-stored historical health baseline to calculate a current health score; dynamically calculating an adaptive confirmation time window for observing the effective status of the configuration update based on the current health score and the update risk level; and applying the differential configuration... Before data is collected, a differentiated snapshot reflecting the current operating status of the target edge node is generated. Without requiring synchronization with other edge nodes, a local configuration update is performed based on the differentiated configuration data. Within the adaptive confirmation time window, real-time operating metrics after the update are continuously collected, and heterogeneous weighted normalization is performed on the updated real-time operating metrics in conjunction with the historical health baseline to update the current health score. If the updated current health score meets preset abnormal conditions, or if the adaptive confirmation time window ends without receiving a confirmation instruction from the out-of-band communication channel, a rollback to the operating status before the application of the differentiated configuration data is triggered based on the differentiated snapshot. Otherwise, the local configuration update is solidified to make the differentiated configuration data effective.

[0007] Secondly, embodiments of this application provide an out-of-band asynchronous security configuration and state rollback system for heterogeneous edge nodes, deployed on a target edge node. The system includes: an out-of-band packet receiving unit, used to receive encrypted configuration packets via an out-of-band communication channel, the encrypted configuration packets carrying differential configuration data and an update risk level corresponding to the differential configuration data; a trust verification and decryption unit, used to perform integrity verification, legality verification, and decryption of the encrypted configuration packets based on a local hardware trust root, to extract the differential configuration data and the update risk level; a health score calculation unit, used to collect real-time operating indicators and perform heterogeneous weighted normalization processing on the real-time operating indicators in conjunction with a pre-stored historical health baseline to calculate the current health score; a confirmation window generation unit, used to dynamically calculate an adaptive confirmation time window for observing the effective status of configuration updates based on the current health score and the update risk level; and a snapshot update execution unit. The system comprises: a line unit, used to generate a differentiated snapshot reflecting the current operating state of the target edge node before applying the differentiated configuration data, and to perform a local configuration update based on the differentiated configuration data without requiring synchronization with other edge nodes; an update health monitoring unit, used to continuously collect real-time operating indicators after the update within the adaptive confirmation time window, and to perform heterogeneous weighted normalization processing on the real-time operating indicators after the update in conjunction with the historical health baseline, so as to update the current health score; and a rollback and solidification control unit, used to trigger a rollback to the operating state before the application of the differentiated configuration data based on the differentiated snapshot if the updated current health score meets preset abnormal conditions, or if the adaptive confirmation time window ends and no confirmation instruction is received from the out-of-band communication channel; otherwise, to solidify the local configuration update so that the differentiated configuration data takes effect.

[0008] Thirdly, an electronic device is provided, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to any embodiment of the present application.

[0009] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to any embodiment of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to any embodiment of this application.

[0011] The out-of-band asynchronous security configuration and state rollback method and system for heterogeneous edge nodes provided in this application can achieve at least the following technical effects:

[0012] By combining out-of-band communication channels, encrypted configuration packet verification and decryption mechanisms, and differential configuration data update methods, the configuration update process achieves coordinated constraints across three levels: transmission path, data trustworthiness, and update granularity. Using out-of-band communication channels to carry out configuration distribution allows the configuration control link to remain relatively independent of regular business communication, thus maintaining good configuration reachability even in complex connectivity environments. Furthermore, combining local hardware trust roots to perform integrity verification, legality verification, and decryption of configuration packets effectively improves the trustworthiness of the configuration source and content. Simultaneously, using differential configuration data to perform local configuration updates ensures that the processing objects of the target edge nodes are strictly focused on the changed configuration items, significantly reducing the overall impact of the update on the underlying system. Therefore, configuration updates not only establish a foundation of security constraints but also maintain precise execution targeting and implementation efficiency in constrained heterogeneous edge environments.

[0013] By linking node health status assessment, update risk awareness, adaptive confirmation time window, and differentiated snapshot rollback mechanism, the effectiveness determination and anomaly recovery after configuration updates no longer rely on static, fixed timing, but can be dynamically adjusted according to the actual operational performance of the nodes. Specifically, the current health score is calculated by fusing real-time operational indicators with historical health baselines, and this health score, along with the update risk level, is used to deduce the adaptive confirmation time window. This allows update tasks of different nodes and risk levels to be matched with the observation period most suitable to their current capacity. Differentiated snapshots are generated before configuration application, providing a reliable rollback basis for subsequent targeted state recovery. After configuration update, operational indicators are continuously monitored, and rollback is triggered based on the differentiated snapshots when preset abnormal conditions are met or confirmation is blocked, forming a complete closed-loop control chain covering pre-update state retention, continuous observation during update, and dynamic determination after update. Based on the above multi-dimensional coupling design, the target edge node can independently complete local configuration iteration without requiring synchronization with other edge nodes, and can roll back to the original operating state when abnormal fluctuations occur, improving the elasticity and fault tolerance of the configuration update process and the continuity of business operations.

[0014] This technical solution constructs a closed-loop security control mechanism for the configuration update process of heterogeneous edge nodes, comprising out-of-band trusted reception, differentiated secure updates, dynamic state awareness, adaptive adjustment of the confirmation window, and precise snapshot rollback. This mechanism enables configuration updates to deeply adapt to the differences in hardware capabilities, health fluctuations, and network constraints of edge nodes in complex environments. Furthermore, it ensures that the confirmation of updated configurations and anomaly backtracking are highly targeted and reliable, thereby improving the security, adaptive coordination, and stability of configuration management under the edge computing architecture. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating an example of an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to an embodiment of this application is shown.

[0017] Figure 2 A flowchart illustrating an example of calculating the current health score of a target edge node according to an embodiment of this application is shown.

[0018] Figure 3 This document illustrates an example of generating a differential snapshot of the current running state and performing a local configuration update based on the differential configuration data in a method according to an embodiment of this application.

[0019] Figure 4 This paper illustrates a schematic diagram of the system operation mechanism of an example of an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to an embodiment of this application.

[0020] Figure 5 A schematic diagram of a comparative experiment simulation showing the convergence rate of configuration update and system availability of different methods in a constrained network environment is presented.

[0021] Figure 6 A schematic diagram of a comparative experimental simulation showing the trade-off between recovery efficiency and communication overhead of different methods in a multi-node failure scenario is presented.

[0022] Figure 7 A schematic diagram of a comparative experiment simulation showing the accuracy of different methods in system health status fault perception is shown.

[0023] Figure 8A structural block diagram of an example of an out-of-band asynchronous security configuration and state rollback system for heterogeneous edge nodes according to an embodiment of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that in edge node configuration management under restricted networks, current technologies typically follow three paths: offline secure distribution, out-of-band management, and post-commit protection. For extremely weak or offline network scenarios, some edge management solutions employ offline import methods using encrypted configuration data blocks. For example, configuration data is exported in the form of encrypted data packets (blobs), and decryption and application on the target device are accomplished using local hardware trust capabilities such as TPM (Trusted Platform Module). Other solutions utilize local synchronization mechanisms like Edge Sync to forward imported updated data within the local area network environment. While these methods improve the reliability of offline transmission, the overall process still usually relies on manual transfer or on-site import, and the feedback link after updates is weak. It is difficult to establish a flexible adjustment mechanism that integrates with the real-time status of nodes to address changes in node load, environmental fluctuations, or abnormal configuration applications.

[0026] Regarding management plane security isolation, current technologies often employ Out-of-Band (OOB) networks or independent management workstations to perform device configuration, achieving separation between the management plane and the business plane and reducing the risk of management credentials exposure. Simultaneously, at the configuration protection level, some network devices introduce commit-confirmed protection mechanisms, which retain a preset observation period after configuration takes effect. If the device does not receive confirmation within a fixed timeframe, it automatically reverts to its pre-change state. These approaches provide some support in terms of management isolation and basic fault tolerance, but the former focuses more on access path isolation, while the latter relies more on fixed observation periods. For widely distributed, heterogeneous, and discontinuous edge node systems, it remains difficult to simultaneously meet the requirements of asynchronous configuration delivery, state-aware confirmation, and differentiated rollback control.

[0027] Furthermore, in terms of configuration anomaly identification and recovery assistance, current technologies also attempt to improve configuration problem identification capabilities by utilizing state modeling, policy reasoning, and intelligent analysis. For example, some studies use HHMM (Hierarchical Hidden Markov Model) to hierarchically model the relationship between performance indicators and potential resource states, and combine it with MDP (Markov Decision Process) to select recovery actions; other studies have proposed methods such as CAIP (Context-Aware Iterative Prompting) to enhance configuration defect detection capabilities through configuration context extraction and prompt optimization. Meanwhile, at the underlying update level, A / B partitioning is also used to support atomic switching and failure rollback. These methods provide support for anomaly detection, policy reasoning, and basic rollback, respectively, but most still focus on single-point capabilities, with fewer addressing the integrated control mechanism for configuration delivery, execution confirmation, operational status evaluation, and multi-node recovery collaboration for heterogeneous edge nodes under constrained network conditions.

[0028] In summary, while current technologies have explored offline security updates, out-of-band management isolation, confirmed commit protection, anomaly detection assistance, and basic fault rollback, most of these approaches focus on specific aspects and have not yet formed a tightly integrated mechanism for configuration distribution, state awareness, confirmation control, and recovery handling of heterogeneous edge nodes in restricted networks. Especially in scenarios where multiple nodes collaboratively carry out services, there is still room for improvement in ensuring configuration security while maintaining flexibility in update execution, adaptability of the confirmation process, and stability of recovery control.

[0029] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0030] The technical solutions in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of users' personal information, comply with relevant laws and regulations and do not violate public order and good morals.

[0031] Figure 1 A flowchart illustrating an example of an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to an embodiment of this application is shown.

[0032] Regarding the execution entity of the method in the embodiments of this application, it can be any controller or processor with computing or processing capabilities, such as an edge gateway controller, which implements the method of the embodiments of this application by running programs or instructions stored in a storage medium. In some examples, it can be integrated and configured in an electronic device or terminal through software, hardware, or a combination of software and hardware, and the type of terminal or electronic device can be diverse, such as industrial field edge devices, smart gateways, edge servers, or other devices with local configuration execution and state rollback capabilities.

[0033] In addition, edge nodes can be deployed in smart grids such as station gateways, power distribution room control terminals, and distributed energy access units; they can also be deployed in industrial internet scenarios such as production line edge controllers, factory aggregation gateways, and equipment-side industrial computing boxes; or they can be deployed in scenarios such as traffic monitoring stations, utility tunnel monitoring terminals, and remote unattended sites.

[0034] like Figure 1 As shown, in step S110, an encrypted configuration packet is received through an out-of-band communication channel. The encrypted configuration packet carries differential configuration data and the update risk level corresponding to the differential configuration data.

[0035] Here, the out-of-band communication channel is a dedicated physical link or logically isolated link, independent of the main communication network that carries the regular business data flow of the edge node. Taking the smart grid scenario as an example, the main business link of the site where the edge node is located may undertake services such as telemetry, remote signaling, and protection action uploading. The network load is high and the real-time requirements are strict. In this case, a dedicated management network port, an independent management virtual LAN, a low-speed management wireless link, or other auxiliary communication paths can be used as the out-of-band communication channel. In the industrial IoT scenario, the production control network and the management configuration link can also be isolated from each other, so that configuration changes are not directly attached to the production business flow. Through this out-of-band communication channel, even if the main business link is in an unstable state due to high load, routing anomalies, on-site interference, or partial interruption, the central management side can still send configuration control data to the target edge node, thereby ensuring that the configuration processing link has relative independence.

[0036] The differential configuration data carried in the encrypted configuration package represents the configuration changes relative to the currently effective configuration of the target edge node. For example, in a power distribution automation scenario, differential configuration data might manifest as adjustments to alarm thresholds, sampling periods, or partial updates to routing and forwarding tables; in an industrial internet scenario, it might manifest as adjustments to edge acquisition rules, modifications to data upload frequencies, partial changes to access control policies, or updates to partial business service parameters. The corresponding update risk level characterizes the extent to which this configuration change may affect the node's operational status, business continuity, or security controls. For example, modifications involving only the ordinary log collection level or cache period might be assigned a lower risk level; while modifications involving communication protocol parameters, control command filtering rules, authentication policies, or core forwarding configurations might be assigned a higher risk level. By simultaneously carrying differential configuration data and update risk levels in the configuration package, the target edge node can not only know "what has been changed" during subsequent processing but also preliminarily assess "the potential impact of the change," thus providing basic input for subsequent verification, evaluation, and execution processes.

[0037] In step S120, the encrypted configuration package is verified for integrity, legitimacy, and decrypted based on the local hardware root of trust in order to extract differential configuration data and update the risk level.

[0038] Here, the local hardware root of trust can be a trusted platform module, security unit, trusted execution environment, or other security module with key protection, trusted boot, or trusted execution capabilities deployed at the edge node board level or system level. Considering that edge nodes are often deployed in relatively open or unattended environments such as substation peripheral cabinets, factory edge control cabinets, transportation route cabinets, and field site enclosures, relying solely on operating system-level verification mechanisms is insufficient to fully resist the risks of configuration forgery, firmware tampering, or illegal control injection. Therefore, this embodiment decentralizes the verification and decryption logic of the configuration package to the local hardware root of trust for execution.

[0039] Specifically, upon receiving the encrypted configuration packet, the target edge node can first import it into the protected processing area. The local hardware root of trust then checks the packet's source identifier, signature information, timing status, and packet integrity to confirm that the packet's source is trustworthy, its content has not been tampered with, and it meets the current node's processing conditions. For example, in a remote industrial site scenario, if the configuration packet is damaged during transmission or its source is not the pre-trusted central management side, further processing can be directly rejected. After verification, the local hardware root of trust then uses protected key materials to decrypt the configuration packet, recovering the plaintext-based differential configuration data and update risk level.

[0040] In some embodiments, after decryption, the edge node can further check the encapsulation format, field integrity, and compatibility with the current node's underlying environment of the differential configuration data to prevent situations where the packet structure is trustworthy but the content is unsuitable for execution by the current node. Taking wide-area distributed edge nodes as an example, different nodes may have different firmware versions, driver environments, or resource configurations. The same configuration change may not necessarily apply to all nodes. Therefore, performing environment compatibility checks on the node side helps prevent incorrect configurations from entering the execution phase. This ensures that the configuration packet undergoes hardware-level trust screening before formally entering the update process, reducing the risk of illegal, forged, or corrupted configurations being executed, thereby improving the security and reliability of the out-of-band configuration update process.

[0041] In step S130, real-time operating indicators are collected, and heterogeneous weighted normalization processing is performed on the real-time operating indicators in combination with the pre-stored historical health baseline to calculate the current health score.

[0042] Here, the target edge nodes collect multi-dimensional real-time operational metrics through local monitoring modules. These metrics can include processor load, memory usage, storage read / write latency, network link quality, task queue backlog, critical process response latency, service error rate, and other information reflecting the node's current operational status. For example, in a smart grid edge terminal, the focus can be on the stability of the sampling and uplink link, processor usage, and message latency; in an industrial control edge computing box, the focus can be on the response latency of containers or services, edge inference task usage, and buffer pressure; and in a traffic monitoring node, the focus can be on communication stability, sensor acquisition thread status, and local data buffering.

[0043] Because edge computing typically exhibits significant differences in hardware configuration, resource scale, and workload, the same absolute indicator value may have different meanings on different nodes. For example, a high-performance edge server may remain stable even with high processor utilization, while a low-power aggregation gateway may be nearing its resource limits under the same processor utilization. Therefore, this embodiment introduces a historical health baseline corresponding to the target edge node as a unique reference state formed during the node's long-term stable operation. The system compares the currently collected operational indicators across various dimensions with this historical health baseline, performs unified normalization on indicators with different dimensions, directions of change, and distribution characteristics, and weights and fuses these indicators based on the node's own resource dependencies and the degree of attention given to different indicators in the current business scenario, ultimately forming a current health score that reflects the overall robustness of the node's current operation.

[0044] In this embodiment, the system does not make a rough judgment on the node status based on a single threshold, but rather forms a comprehensive status evaluation result for a specific node and a specific scenario. Therefore, it can more realistically reflect whether a node currently has the ability to withstand configuration updates under heterogeneous hardware conditions, reducing the risk of misjudgment caused by relying solely on a single indicator or a uniform threshold.

[0045] In step S140, an adaptive confirmation time window for observing the effective status of the configuration update is dynamically calculated based on the current health score and the update risk level.

[0046] Here, the adaptive confirmation time window represents the duration for which the target edge node remains in the observation and verification state after the configuration update is completed. Unlike confirmation mechanisms with fixed waiting times, the confirmation time window in this embodiment is dynamically generated based on the node's current operational health and the risk level of the configuration change itself. In other words, the system does not uniformly allocate the same observation period for all update actions, but rather determines the observation period based on two factors: "whether the node is currently robust" and "whether this modification is sensitive."

[0047] For example, in a smart grid scenario, if the configuration update only involves adjusting the normal data collection cycle and the target edge node is currently in good health, the system can set a shorter confirmation window. However, if the update involves changes to communication forwarding paths, control rules, or security access policies, and the node is currently experiencing resource constraints or link fluctuations, the system can appropriately extend the confirmation time window to allow more time for potential anomalies to manifest and be detected. Similarly, in an industrial internet scenario, the impact of adjusting normal reported parameters and reconfiguring control policies on field operations differs; the former typically allows for a shorter observation time, while the latter is more suitable for a longer observation time. By adopting a dynamic time allocation method, the system can match the depth of update monitoring with configuration risks and node health status.

[0048] In this embodiment, on the one hand, it helps to avoid unnecessary resource consumption and process delays caused by setting excessively long observation periods for low-risk updates; on the other hand, it also helps to avoid the situation where hidden faults are incorrectly solidified before being fully exposed by setting excessively short observation periods for high-risk updates. Therefore, the confirmation mechanism changes from fixed-duration control to adaptive control oriented towards node state and change risks, making it more suitable for configuration update scenarios in complex edge environments.

[0049] In step S150, before applying the differential configuration data, a differential snapshot reflecting the current operating state of the target edge node is generated, and a local configuration update is performed based on the differential configuration data without requiring synchronization with other edge nodes to complete the update.

[0050] Here, before formally performing configuration overwrite, the target edge node first generates a differentiated snapshot around the configuration content and running objects involved in this change. This differentiated snapshot can include the original values ​​of the affected configuration items before the update, the local running state directly related to the update operation, and necessary process or service context information. Compared to performing a full mirror backup of the entire system, differentiated snapshots focus more on the local objects actually affected by the change. For example, on an industrial control edge node, only when a service routing rule, access control entry, or acquisition parameter changes, the system mainly records the configuration items and associated running state directly related to the change, without having to perform a full copy of the entire node, thereby reducing storage and processing overhead.

[0051] After generating the differentiated snapshot, the target edge node can perform configuration updates locally. The emphasis here on "not requiring synchronization with other edge nodes" is because in wide-area distributed edge scenarios, the network conditions, hardware resources, and service usage of different nodes vary significantly. Requiring all nodes to strictly synchronize updates could easily slow down the entire update task due to individual weak or busy nodes. Therefore, this embodiment allows nodes to independently perform configuration updates when their own snapshots are ready and local execution conditions are met. For example, in a distributed energy site scenario, even if a site's edge node's communication status is temporarily inconsistent with other sites, it can still independently complete configuration updates based on its own status, without waiting for all nodes in the entire area to simultaneously enter the update phase. In this way, the system, on the one hand, pre-establishes usable local recovery anchor points for subsequent recovery operations, and on the other hand, improves the individual autonomous update capabilities of distributed heterogeneous nodes in scenarios with weak networks, network outages, or inconsistent conditions, helping to reduce the global blocking risk caused by strong synchronous updates.

[0052] In step S160, within the adaptive confirmation time window, updated real-time operating indicators are continuously collected, and heterogeneous weighted normalization processing is performed on the updated real-time operating indicators in combination with historical health baselines to update the current health score.

[0053] It should be noted that the completion of configuration data writing does not mean the update process is completely and safely finished. Some configuration issues, especially those related to communication links, service coordination, memory usage, or task scheduling, often do not appear immediately after configuration overwrite, but rather gradually emerge after the actual business has been running for a period of time. Therefore, the target edge node remains in an observation and verification state within the adaptive confirmation time window, and collects real-time operational metrics after the update at a preset frequency. For example, in industrial internet scenarios, some anomalies may manifest as a gradual increase in service latency, a continuous increase in task backlog, or a gradual accumulation of error logs; in power edge gateway scenarios, they may manifest as an increased packet loss rate, data collection task timeouts, or increased fluctuations in link quality.

[0054] In some implementations, the collected updated operational metrics are normalized and heterogeneously weighted in conjunction with historical health baselines to continuously refresh the current health score. This allows the system to establish a continuous evolution trajectory of node health status over time, rather than relying solely on the instantaneous result immediately after the configuration is written. Through this continuous refresh mechanism, the system can identify slow deterioration issues, hidden performance degradation, or long-tail faults caused by the new configuration earlier, providing a more dynamic and comprehensive basis for deciding whether to retain the new configuration. This upgrades the traditional "write-and-complete" configuration update process to a closed-loop observation process of "continuous verification after write," improving the ability to identify hidden anomalies and delayed manifestation issues, thereby enhancing the reliability and robustness of the overall configuration update process.

[0055] In step S170, if the updated current health score is detected to meet the preset abnormal conditions, or if the adaptive confirmation time window ends and no confirmation instruction is received from the out-of-band communication channel, a rollback to the running state before the application of the differential configuration data is triggered based on the differential snapshot; otherwise, the local configuration update is solidified so that the differential configuration data takes effect.

[0056] Here, the system determines whether the configuration update should be rolled back based on two types of conditions. The first type of condition is triggered by an abnormal health status. That is, if the updated current health score meets the preset abnormal conditions within the confirmation time window, it indicates that the configuration change has adversely affected the steady state of node operation. In this case, the node can directly call the differential snapshot to perform the recovery operation without waiting for the window to end, returning to the operating state before the application of the differential configuration data. The second type of condition is triggered by a timeout without confirmation. That is, if the node still has not received a confirmation instruction through the out-of-band communication channel after the confirmation time window ends, the system can consider the current configuration state as unsuitable to continue, thus triggering a rollback to avoid permanently fixing the new configuration in the case of unclear status or abnormal confirmation link.

[0057] For example, in a substation edge node scenario, if a new configuration, after taking effect, causes a continuous increase in the load on the acquisition thread and pushes the current health score below the safety threshold, the system can immediately roll back. Similarly, in some remote unattended sites, even without obvious anomalies, if no confirmation from management is received by the end of the confirmation window, a rollback can be performed as a conservative measure. Correspondingly, only when the health status remains within an acceptable range throughout the entire confirmation time window and a confirmation command is received under specified conditions will the system officially solidify the current configuration update into the new effective state, and clean up or archive temporary states, differential snapshots, or related records from this update process. This forms a closed-loop control logic of "rollback upon anomaly, rollback upon timeout without confirmation, and retention upon stability and confirmation," enabling edge nodes in constrained network environments to withstand both explicit failures caused by misconfigurations and uncertain operating states caused by abnormal confirmation links, thereby improving the node's automatic recovery capability and continuous stable operation capability in complex field environments.

[0058] Regarding the implementation details of extracting differential configuration data and updating risk levels in step S120, in some examples of embodiments of this application, firstly, the header metadata of the encrypted configuration packet is parsed to extract the global digital signature issued by the central management platform. Configuration package sequence identifier and dynamic data keys encapsulated by asymmetric encryption algorithms. .

[0059] In this embodiment, the encrypted configuration packet can adopt a separate header and payload encapsulation format. The header metadata carries information related to identity recognition, timing control, and key exchange, while the payload area carries differential configuration data, updated risk levels, and related control parameters. Taking a smart grid terminal gateway, industrial field edge controller, or remote unattended monitoring node as an example, after receiving the configuration packet on the out-of-band management link, the edge node can first parse the header metadata to identify the source, timing status, and key encapsulation information of the current configuration packet, without needing to perform complete decryption of the entire payload area in the initial stage, thereby reducing the probability of invalid configuration packets entering the deep processing flow. Global digital signature. Used for signing and protecting the contents of the configuration package; configuration package sequence identifier. Dynamic data key used to identify the sequence of events in this configuration distribution task. This is used as the ciphertext form of the temporary symmetric key generated by the central management platform for this payload content.

[0060] Then, the configuration package sequence identifier. Anti-replay timing watermark maintained by the target edge node within a trusted isolated storage area Verify that the configured packet sequence identifier is correct. Below or equal to the anti-replay timing water level If the data is expired or replayed, the encrypted configuration package will be discarded.

[0061] In some edge deployment scenarios, historically valid configuration packets may be repeatedly sent to the node. If the node cannot distinguish whether the packet has been processed before, the old configuration may overwrite the new configuration. To address this, this embodiment maintains a replay prevention timing watermark within the trusted isolated storage area of ​​the target edge node. And use this as the timing determination benchmark. The system performs the following judgment: When the above relationship holds true, it means that the timing identifier corresponding to the currently received encrypted configuration packet does not exceed the latest valid timing that has been accepted and recorded by the node. The system can then determine that the configuration packet is expired or replayed data and terminate further processing of the configuration packet. This processing method can filter out obviously invalid historical configuration packets at an earlier stage, reducing the consumption of subsequent verification and decryption resources, while also reducing the risk of state rollback caused by old configurations being re-injected into the node.

[0062] Next, after the timing verification is passed, the public key of the central management platform, which is pre-installed in the target edge node, is used. Global digital signature Perform verification to complete the integrity verification.

[0063] In this embodiment, the public key of the central management platform It can be pre-stored in the secure area of ​​the target edge node. After confirming that the current configuration package has not triggered the anti-replay condition, the node calls the public key of the central management platform to verify the signature result of the relevant content of the configuration package, so as to confirm that the encrypted configuration package was indeed issued by the trusted central management side and that no content corruption or tampering occurred during out-of-band transmission. If the global digital signature verification fails, it indicates that there is an anomaly in the authenticity of the source or the consistency of the content of the configuration package. The node can directly terminate the current processing and mark the configuration package as an input object that fails the integrity verification, thereby improving the verifiability of the configuration package source and the consistency of the package content.

[0064] Furthermore, after integrity verification is successful, the physically isolated, non-clonable private key within the local hardware trust root is invoked. For dynamic data keys encapsulated by asymmetric encryption algorithms Decryption is performed to recover the plaintext dynamic data key. This completes the legality verification.

[0065] Edge nodes are typically deployed in environments such as outdoor sites, industrial field control cabinets, and monitoring boxes along production lines, where physical contact conditions are relatively complex. To reduce the risk of private key leakage, this embodiment stores the node's private key... It is stored in a physically isolated area within the local hardware root of trust, preventing it from being directly exported by upper-layer systems. This applies to dynamic data keys encapsulated using asymmetric encryption algorithms. The system calls the local hardware root of trust to perform decryption, which can be specifically represented as:

[0066] Equation (1)

[0067] in, This represents an asymmetric decryption function. Only edge nodes that match the target object of the encrypted configuration package are capable of recovering the plaintext dynamic data key. Therefore, it not only completes the transition from asymmetric key encapsulation to symmetric payload decryption, but also restricts the actual processing permissions of the configuration package to the specified target node.

[0068] Then, using the plaintext dynamic data key Within a trusted execution environment, the payload area of ​​the encrypted configuration package Perform symmetric decryption to extract the differential configuration data. Update risk level and accompanying heterogeneous operating environment compatibility constraints .

[0069] In this embodiment, the load area Symmetric encryption can be used for protection to balance transmission security and node-side decryption efficiency. This involves obtaining the plaintext dynamic data key. Then, the system performs symmetric decryption in a trusted execution environment, which can be specifically represented as follows:

[0070] Equation (2)

[0071] in, This represents the symmetric decryption function. Through this step, the target edge node obtains the core information needed to perform this configuration update, including the differential configuration data. Update risk level and compatibility constraints Among them, compatibility constraints This can be used to describe the applicability requirements of the configuration content to the underlying node environment, such as a specific firmware version range, a specific hardware capability range, or specific preconditions for operation. Restricting payload decryption operations to a trusted execution environment helps reduce the probability of plaintext configuration content being exposed in a normal operating environment.

[0072] Furthermore, the compatibility constraints of heterogeneous operating environments will be addressed. The current underlying firmware version of the target edge node and hardware computing power characteristics Perform a matching verification. If the matching verification passes, determine that the difference configuration data and update risk level have been successfully extracted and are valid on the current target edge node. At the same time, update the anti-replay timing water level to the current configuration package sequence identifier.

[0073] In this embodiment, nodes in the edge cluster may differ in firmware version, processing power, peripheral conditions, and security capabilities, etc. Therefore, not every configuration change is applicable to all edge nodes. To prevent incompatible configurations from being incorrectly applied to the current node, the system imposes compatibility constraints. The matching and comparison with the node's local environment can be specifically represented as follows:

[0074] Equation (3)

[0075] in, This represents the matching judgment function. When compatibility constraints apply... With the underlying firmware version of the node and hardware computing power characteristics Upon matching, the system determines that the decrypted differential configuration data and updated risk level are applicable to the current target edge node, and therefore considers it a valid extraction result. Based on this, the anti-replay timing watermark is then updated to the current configuration packet sequence identifier, i.e.: By adopting the above update order, the advancement of the timing water level can be based on the configuration package passing source verification, content verification, node-specific decryption, and environment adaptation judgment, thus avoiding the incorrect advancement of the timing state for incompatible or verification-failed configuration packages.

[0076] This embodiment enables target edge nodes to undergo multi-layered trust screening before configuration content enters the execution phase by parsing configuration packet header metadata, verifying anti-replay timing, signing, decrypting node-specific keys, performing payload symmetric decryption, and verifying node environment matching. This helps reduce execution risks caused by historical configuration packet replay, illegal configuration injection, content tampering, and environment incompatibility, and improves the accuracy and availability of differential configuration data and update risk levels during node-side extraction.

[0077] Figure 2 A flowchart illustrating an example of calculating the current health score of a target edge node in a method according to an embodiment of this application is shown.

[0078] like Figure 2 As shown, in step S210, the original values ​​of the operating indicators of the target edge node in multiple dimensions at the current sampling time are obtained.

[0079] It should be understood that edge nodes typically undertake multiple tasks simultaneously, including local data processing, edge control, protocol conversion, and network communication. A single-dimensional operational metric is insufficient to fully characterize the actual operational status of a node. Therefore, the target edge node at the current sampling time... Raw values ​​of multiple operational metrics are obtained through local monitoring probes, system interfaces, or kernel status acquisition modules, denoted as... ,in, It is a positive integer, and Multiple operational metrics can include hardware resource status metrics, link communication status metrics, and service process status metrics. For example, hardware resource status metrics can include processor utilization, available memory space, storage read / write latency, and device temperature; link communication status metrics can include packet loss rate, network throughput, out-of-band link latency, and communication jitter; and service process status metrics can include task queue length, service response time, thread blocking status, or abnormal log growth rate. Therefore, by extracting raw operational metrics from multiple dimensions at the current sampling moment, the system can obtain basic status data corresponding to the current operational status of the target edge node.

[0080] In step S220, based on the historical statistical characteristics of each dimension of indicators stored in the historical health baseline, corresponding normalization mapping logic is applied to the operating indicators with different characteristics to obtain normalized indicator values. Here, the normalization mapping logic includes: applying forward linear extreme value mapping to positive indicators, applying reverse linear extreme value mapping to negative indicators, and applying normal mapping based on probability density distribution to bidirectional indicators with optimal operating range.

[0081] Because operational metrics across different dimensions differ significantly in physical meaning, dimensional range, and direction of change—for example, memory capacity, packet loss rate, and service response time differ in magnitude and health implications—direct horizontal calculations are not feasible. In this embodiment, the system classifies and normalizes operational metrics with different characteristics based on historical health baselines formed during the target edge node's historical stable operation phase, obtaining corresponding normalized metric values. Historical health baselines can preserve statistical characteristics such as historical maximum values, historical minimum values, historical mean values, and historical standard deviations for various indicators.

[0082] More specifically, for the positive indicator that a larger indicator value indicates better health, a positive linear mapping is performed based on the historical maximum and minimum values ​​recorded in the historical health baseline; for the negative indicator that a smaller indicator value indicates better health, an inverse linear mapping is performed based on the historical maximum and minimum values ​​recorded in the historical health baseline.

[0083] For positive indicators where larger values ​​generally indicate better operational status, such as available memory, available bandwidth, or remaining cache capacity, this embodiment can use a positive linear mapping method for normalization, specifically expressed as follows:

[0084] Equation (4)

[0085] in, and These represent the historical maximum and minimum values ​​of this dimension indicator recorded in the historical health baseline, respectively.

[0086] For inverse indicators where larger values ​​suggest a more strained operational state, such as processor load, network latency, packet loss rate, or task backlog length, this embodiment can use a reverse linear mapping method for normalization, specifically expressed as:

[0087] Equation (5)

[0088] Through the above processing, positive and negative indicators can have a consistent health meaning after normalization, that is, the larger the normalized value, the closer the state of that dimension is to the healthy range.

[0089] Furthermore, for bidirectional indicators with optimal operating ranges, such as equipment temperature, operating voltage, or certain system state indicators that should not be too high or too low, extreme value linear mapping alone is insufficient to accurately reflect the degree of deviation from the ideal state. Therefore, this embodiment is based on the historical average recorded in the historical health baseline. Non-zero historical standard deviation The process employs a Gaussian mapping function based on the normal distribution, which can be specifically expressed as:

[0090] Equation (6)

[0091] When the current indicator value is close to the historical steady-state mean, the normalized indicator value is relatively high; when the indicator deviates from the steady-state center, the normalized indicator value gradually decreases, thus better reflecting the degree of influence of the two-way indicator on the operating status. Through the above classification mapping process, the original operating indicators with different dimensions, different health directions, and different distribution characteristics are uniformly converted into comparable normalized indicator values, enabling the multidimensional operating status of the target edge node to be expressed on a unified scale.

[0092] In step S230, the heterogeneous allocation weights corresponding to each dimension index are calculated. Here, the heterogeneous allocation weights combine the global importance characteristics of the index in the current business scenario with the specific sensitivity parameters of the target edge node for specific operating indicators due to hardware heterogeneity.

[0093] In this embodiment, after obtaining the normalized index values ​​for each dimension, the system further calculates the heterogeneous allocation weights corresponding to each dimension index to reflect the actual impact of different indexes on the current target edge node. Due to differences in hardware architecture, resource scale, and service delivery methods among edge nodes, the same index may have different levels of importance on different nodes. For example, for a high-performance edge server, a short-term increase in processor usage may not pose a significant risk; however, for a low-power gateway or resource-constrained terminal, the same level of processor usage fluctuation may already significantly affect node stability. Therefore, this embodiment considers both the importance of the index in the current business scenario and the resource dependency characteristics of the target edge node itself when calculating the weights.

[0094] Specifically, in this embodiment, the heterogeneous allocation weights corresponding to each dimension index can be calculated using the following formula. :

[0095] Equation (7)

[0096] in, Indicates the first The global importance parameter of each dimension in the current business scenario is used to represent the basic weight of the dimension's indicator in the overall business operation. This indicates that the target edge node at the current time is related to the first... Each dimension has a specific sensitivity parameter used to characterize the degree to which the node depends on the metric due to hardware heterogeneity, resource constraints, or differences in operating methods. The traversal index is used for normalized summation; and the calculated heterogeneous allocation weights satisfy the summation condition. The weights calculated in this way are not a fixed configuration uniformly applied to all nodes, but rather an allocation result that can be adjusted according to the characteristics of the nodes themselves and the needs of the scenario, so that the health assessment of different nodes is more in line with their actual operating conditions.

[0097] In step S240, a weighted summation process is performed based on the normalized index value and the corresponding heterogeneous allocation weight to obtain the current health score, which reflects the current overall operating status of the target edge node.

[0098] In this embodiment, after obtaining the normalized index value and the corresponding heterogeneous allocation weights Then, the system calculates the current health score of the target edge node at the current sampling time using the following weighted summation method. :

[0099] Equation (8)

[0100] in, This is a scalar result characterizing the current comprehensive operational status of the target edge node. By aggregating the normalized index values ​​of each dimension and their corresponding weights, the system transforms the originally scattered multi-dimensional operational status information into a unified health evaluation result. This health score reflects not only the multi-dimensional real-time operational status but also the combined influence of historical health baselines, key business scenarios, and the heterogeneous resource characteristics of the node.

[0101] By employing the above processing method, the current health score of the target edge node can maintain good interpretability and comparability across different types of edge devices. For heterogeneous nodes with significant differences in resource capabilities, this health score does not simply reflect the absolute load level, but rather the overall operating status of the node under its own historical steady-state reference and current business requirements. This helps to more accurately characterize whether the edge node is in a state suitable for implementing configuration changes.

[0102] This embodiment utilizes multi-dimensional operational indicator collection, classification and normalization mapping based on historical health baselines, heterogeneous weight allocation combining global importance and node-specific sensitivity, and weighted aggregation processing of normalized indicator values ​​to transform the complex, heterogeneous, and inconsistent operational status of target edge nodes into a unified health score result. This helps improve the objectivity and adaptability of edge node operational status evaluation and reduces potential biases that may arise from a unified threshold judgment method in heterogeneous edge scenarios.

[0103] In some examples of embodiments of this application, after the local configuration update is solidified to make the differential configuration data effective, an adaptive iterative update of a specific sensitivity parameter based on an error back feedback mechanism can also be performed.

[0104] Specifically, firstly, during the steady-state observation period after the configuration update and solidification, the current health score will be... The health deviation is compared with a preset ideal health target, and a differentiable health deviation loss model is constructed based on the deviation between the two. .

[0105] In this embodiment, after the target edge node completes its configuration update and fixation, the health assessment parameters at that moment are not fixed indefinitely. Instead, the node's performance under real business operating conditions is continuously monitored during a steady-state observation period. Because edge nodes operate in complex environments for extended periods, such as aging equipment components, changes in external temperature, load cycle fluctuations, or gradual changes in link quality, the node's sensitivity to various operating indicators may change over time. If the initially configured fixed assessment parameters are used for an extended period, some indicators that were originally within the normal fluctuation range may be excessively amplified, or some gradually important state changes may not be fully reflected.

[0106] Therefore, in this embodiment, the system will use the current health score The system compares the health level of the target edge node with a preset ideal health target. The ideal health target characterizes the expected health level of the target edge node under stable operating conditions. To enable this deviation to be utilized in subsequent iterative adjustment processes, the system constructs a corresponding differentiable health deviation loss model. As an optional implementation, the health deviation loss model can be constructed using the mean squared error form, which can be specifically expressed as:

[0107] Equation (9)

[0108] in, This represents the preset ideal health target. Through this process, the current health deviation of the target edge node is represented as a continuously differentiable quantification result, thereby enabling the deviation of the node's operating state to participate in subsequent parameter adjustment in a computable manner.

[0109] Then, extract the health deviation loss model. relative to the normalized index values ​​of each dimension The gradient of change is calculated, and feedback learning logic is used to iteratively adjust specific sensitivity parameters for each dimension.

[0110] In this embodiment, the system obtains the health deviation loss model. Then, further extraction of the loss model relative to the first... Normalized index values ​​of each dimension The partial derivative of this dimensional indicator is used to reflect the degree of impact of changes in this dimension on overall health deviation. In both physical and algorithmic terms, the gradient of this partial derivative... It is not directly used as a partial derivative of the weights, but rather as a guiding signal for "state-affected sensitivity" to characterize the current state. The fluctuations in indicators across various dimensions contribute to or disrupt the overall health deviation of the system. If the change in a certain dimension's indicator is highly correlated with the health deviation, the corresponding partial derivative feedback will reflect the strength of that dimension's role in the current assessment deviation. Conversely, if a certain dimension's indicator fluctuates but the fluctuation does not significantly change the overall operating state, its corresponding partial derivative feedback will be relatively small.

[0111] Subsequently, the system utilizes feedback learning logic, taking the obtained gradient changes as penalty or reward factors and substituting them into the back-learning formula to apply specific sensitivity parameters to each dimension. Perform iterative adjustments. Specifically, this can be represented as:

[0112] Equation (10)

[0113] In the formula, This is a specific sensitivity parameter used in the next configuration update cycle, and its value is positive. Indicates the current iteration cycle. Indicates the next iteration period. The learning rate control step size is preset. This indicates the steady-state observation time in the current period. The health deviation loss model compared to the first Feedback of partial derivatives of normalized index values ​​in each dimension.

[0114] It should be noted that, in order to ensure the effectiveness of the physical meaning of the iterative update process, the learning rate controls the step size in equation (10). It is configured to a sufficiently small minimum value during system initialization to ensure that the update multiplier for a single iteration remains constant under any extreme load fluctuations. All are strictly greater than zero, thus ensuring the specific sensitivity parameter after iteration. It is always a positive value.

[0115] Through the aforementioned cross-feedback design, the system directly utilizes the absolute magnitude of the error gradients generated by each dimension's indicators to suppress specific sensitivity parameters. If an indicator in a certain dimension experiences drastic fluctuations during the steady-state period, leading to a significant health deviation, the absolute value of its corresponding feedback gradient will increase. Due to the negative penalty mechanism in the formula, the sensitivity parameter of that dimension will automatically decrease during iteration. Ultimately, this achieves dynamic isolation and suppression of normal transient load noise in heterogeneous environments.

[0116] Furthermore, by utilizing the specific sensitivity parameters after iterative adjustment... The heterogeneous allocation weights for the next cycle are recalculated, enabling the target edge nodes to automatically adjust their sensitivity to fluctuations in various dimensional indicators based on historical operational feedback, thereby achieving dynamic suppression of normalized transient load noise in heterogeneous environments.

[0117] In some implementations, after updating the specific sensitivity parameters for each dimension, the system further utilizes the updated specific sensitivity parameters, combined with the corresponding global importance parameters for each dimension, to recalculate the heterogeneous allocation weights for the next cycle. As a preferred implementation, the updated specific sensitivity parameters can be used. Combining global importance parameters from various dimensions The heterogeneous allocation weights for the next cycle are recalculated using the following formula. :

[0118] Equation (11)

[0119] in, Indicates the first The global importance of each dimension in the current business scenario. This is a normalized summation traversal index. Through this calculation method, the operational feedback obtained by the node during the current steady-state observation period is reflected in the heterogeneous allocation weights of the next cycle. This ensures that the new weight results retain the basic importance of each dimension indicator under the business scenario, while also reflecting the actual sensitivity of the target edge node to changes in each dimension state under long-term operating conditions.

[0120] After adopting the above processing method, the health assessment parameters of the target edge node no longer remain static, but can be gradually corrected based on the actual feedback during the steady-state operation phase. This can reduce the interference of some normal transient fluctuations on the health assessment results and make the weight allocation results more in line with the current operating characteristics of the node.

[0121] This embodiment demonstrates how, by constructing a differentiable health deviation loss model during the steady-state observation period after configuration updates and fixation, extracting the gradient feedback of normalized index values ​​for each dimension on health deviation, iteratively adjusting specific sensitivity parameters, and recalculating heterogeneous allocation weights accordingly, the health assessment parameters of the target edge node can be adaptively corrected based on actual operational feedback. This helps improve the adaptability of health assessment results to changes in long-term operating conditions and reduces the impact of normalized transient load fluctuations on the assessment results.

[0122] Regarding the implementation details of dynamically calculating the adaptive confirmation time window in step S140, in some examples of the embodiments of this application, firstly, based on the preset risk-threshold association logic, the updated risk level is converted into the corresponding risk adjustment threshold.

[0123] In this embodiment, the update risk level is not merely used as an additional label in the configuration package, but is further transformed into a risk adjustment threshold for measuring whether the current state of a node is suitable for maintaining the new configuration. Specifically, the system quantifies the extracted update risk level into a numerical value. And determine the corresponding risk adjustment threshold based on the preset risk threshold correlation. The correlation can be set to output a higher threshold as the update risk level increases. Thus, when configuration updates involve communication paths, access control policies, protocol parameters, or other configuration items that significantly impact operational status, the corresponding risk adjustment threshold will increase accordingly; while when configuration updates only involve ordinary log parameters, general sampling frequencies, or local settings with a small impact, the corresponding threshold will be relatively low.

[0124] Through the above processing, the system converts the update risk level into a threshold value that can be directly compared with the node's health status, enabling different risk levels of configuration updates to have different health requirements during the confirmation and observation phase. Using this approach, high-risk configurations will correspond to stricter status judgment criteria, while low-risk configurations will be allowed to use relatively lenient judgment conditions, thus ensuring that risk differences are reflected in the calculation of confirmation time.

[0125] Then, the window duration coefficient of the current health score relative to the risk adjustment threshold is calculated using nonlinear smoothing mapping logic. The nonlinear smoothing mapping logic is configured such that: when the health score is higher than the risk requirement, a smaller window duration coefficient is output; when the health score is close to or lower than the risk requirement, a rapidly increasing window duration coefficient is output.

[0126] Specifically, in determining the risk adjustment threshold Then, the system further calculates the current health score. With risk adjustment threshold The relationship between the two factors is then input into a nonlinear smoothing mapping function to generate a window duration coefficient that characterizes the magnitude of the confirmation time adjustment. As a preferred implementation, a mapping form based on the Logistic function can be used, specifically expressed as follows:

[0127] Equation (12)

[0128] in, The curve steepness parameter is a positive number used to characterize the sensitivity of the window duration coefficient to changes in health status.

[0129] Under this mapping relationship, when the current health score is significantly higher than the risk adjustment threshold, the window duration coefficient... Take the smaller value; when the current health score is close to or below the risk adjustment threshold, the window duration coefficient is adjusted. Increase. Because the Logistic function exhibits smooth and continuous changes around the threshold, the system can avoid the abrupt changes in duration caused by using piecewise threshold judgments, and make the adjustment of the confirmation window more continuous. Through this processing, the difference between node state and update risk is transformed into a normalized adjustment amount that can be used for subsequent duration allocation.

[0130] Then, the window duration coefficient is used to scale the preset observation time interval to generate an adaptive confirmation time window.

[0131] In this embodiment, the system presets a global minimum confirmation time. Compared with the global maximum confirmation time and the aforementioned window duration coefficient Mapping to this time interval to generate the final adaptive confirmation time window. As a preferred implementation, the adaptive confirmation time window can be generated in the following manner. :

[0132] Equation (13)

[0133] in, This represents the minimum confirmation time required to ensure basic state verification and confirmation interactions. This represents the maximum allowable global confirmation time under conditions of weak network, high risk, or significant state fluctuations. Through the above mapping process, regardless of changes in the node's current health status, the final calculated confirmation time window is limited to [...]. Within the defined time range, the output results are kept within a controllable range.

[0134] By adopting the aforementioned time interval mapping method, the system no longer needs to preset a large number of discrete waiting times for different nodes or different configuration scenarios. Instead, it can automatically determine the actual observation time within a preset range based on the window duration coefficient. This establishes a stable mapping between the abstract state deviation and the actual executable physical time parameters, making it easier for target edge nodes to directly call the corresponding time parameters to execute observation control.

[0135] Furthermore, by leveraging the monotonic adjustment characteristics of the nonlinear smooth mapping logic, the system extends the observation window in sub-healthy states or high-risk update scenarios to adjust towards the global maximum confirmation time, thereby enhancing the depth of configuration security monitoring in out-of-band asynchronous communication environments.

[0136] In this embodiment, due to the curve steepness parameter Set to a positive value, window duration coefficient Based on current health score The window duration coefficient decreases as the risk level increases. Therefore, when the current health score of the target edge node is lower than the risk adjustment threshold, or when the risk adjustment threshold rises due to a higher updated risk level, the window duration coefficient output by the system increases accordingly, thereby increasing the adaptive confirmation time window. The window duration is adjusted towards the maximum global confirmation time. Conversely, when the node is in good health and the update risk is low, the window duration coefficient is relatively small, and the adaptive confirmation time window is adjusted towards a shorter duration.

[0137] Based on the above processing, the system can match the length of the confirmation time window with the current operating status of the node and the risk level of configuration updates. This approach helps avoid using excessively short observation times when the risk is high or the status is weak, and also helps avoid occupying unnecessary observation resources for a long time when the risk is low or the status is good, thereby improving the adaptability of confirmation time allocation.

[0138] This embodiment transforms the updated risk level into a risk adjustment threshold, generates a window duration coefficient using the relationship between the current health score and the risk adjustment threshold, and maps this coefficient to a preset confirmation time interval. This allows for dynamic adjustment of the confirmation time window based on the node's operating status and configured risks. Consequently, the confirmation observation process better aligns with the actual operating conditions of the target edge node and reduces the potential for insufficient adaptation in heterogeneous edge scenarios with fixed confirmation durations.

[0139] Figure 3 A flowchart illustrating an example of generating a differentiated snapshot of the current running state and performing a local configuration update based on the differentiated configuration data in a method according to an embodiment of this application is shown.

[0140] like Figure 3 As shown, in step S310, the differential configuration data is compared with the local currently running configuration file by key-value comparison to extract the set of key configuration items to be modified, and based on the preset configuration-service mapping topology, the target business process affected by the set of key configuration items and its corresponding resource dependency chain are identified.

[0141] Here, upon receiving the differential configuration data, the target edge node does not directly replace its local configuration file with a full overwrite. Instead, it first compares the differential configuration data with the currently running configuration item by item to identify the configuration items that have actually changed in this configuration update. The differential configuration data can be encapsulated in a structured configuration format. After parsing, the node compares the configuration key-value pairs with the currently effective local configuration item by item to extract the set of key configuration items that need to be modified. In this way, the system can limit the scope of this configuration change processing to the actual changed configuration content, without having to repeatedly process the unchanged configuration parts.

[0142] After identifying the set of key configuration items, the system further queries a pre-established configuration service mapping topology to determine which business processes are directly or indirectly affected by changes in these configuration items. The configuration service mapping topology records the relationships between configuration parameters and business services, sub-processes, calling components, and runtime dependencies. For example, in an industrial edge node, a change in a communication policy parameter may affect the calling relationships between the front-end acquisition service, protocol conversion service, and back-end forwarding service; similarly, in a power station gateway, a change in a forwarding table entry or access control item may affect specific message processing and uploading processes. By identifying the affected business processes and their resource dependency chains, subsequent update operations on the node side can be limited to a localized impact, thereby reducing interference with unrelated business processes.

[0143] In step S320, for the target business process, its transient running context and network socket state at the current moment are captured, and combined with the original key values ​​of the key configuration item set before the update, as well as the call relationship of each related component in the resource dependency chain, a differentiated snapshot is generated and stored in the local protected isolated storage area.

[0144] Here, before formally performing configuration overwrite, the target edge node generates a differentiated snapshot around the identified target business process and key configuration items. This differentiated snapshot can include the transient runtime context of the target business process at the current moment, the network connection status, the original key-value pairs of key configuration items before the update, and the call relationship information between related components in the resource dependency chain. The transient runtime context can include the process execution location, runtime control information, or context state related to the current task processing, while the network socket state can include necessary content to support recovery operations, such as whether the current connection is established, communication endpoint information, and connection occupancy status.

[0145] Compared to full-machine mirror backup, the differentiated snapshots used in this embodiment primarily encapsulate the local objects actually affected by the update. Therefore, their data scope is relatively concentrated, and storage overhead is more controllable. The generated differentiated snapshots can be written to a local protected isolated storage area to reduce the risk of accidental overwriting, mismodification, or abnormal loss in the normal operating space. Using this method, edge nodes can control snapshot construction costs while retaining necessary recovery data, making it more suitable for resource-constrained edge operating environments.

[0146] In step S330, the real-time resource utilization rate of the target edge node is collected, and combined with the current health score, the execution safety margin for this configuration update is calculated through a preset weighting function.

[0147] In this embodiment, configuration modifications themselves consume processor, storage, and process scheduling resources. Performing updates directly when nodes are busy may exacerbate the current load on those nodes. Therefore, the system further evaluates whether the current moment is suitable for performing the update operation before configuring the application. Specifically, the target edge node's real-time resource utilization is collected. Real-time resource utilization can include processor usage, storage read / write activity, memory pressure, or other information that reflects the current resource stress of a node, and is compared with the previously obtained current health score. In combination, the execution safety margin for this configuration update is calculated using a preset weighting function. .

[0148] As a preferred implementation method, the safety margin can be calculated in the following form:

[0149] Equation (14)

[0150] in, and The preset weighting coefficients satisfy the following conditions: , This is a load penalty factor with a value greater than zero. Through the above calculation method, when the overall health of the node is good and the current resource utilization is low, the execution safety margin is relatively high; when the node is generally healthy but the current resource utilization is significantly increased, the exponential decay term will reduce the output of the execution safety margin, thus enabling the system to make a more prudent judgment on whether "the current moment is suitable for executing the update". This approach allows the update execution conditions to simultaneously reflect the underlying steady-state state of the node and its current workload.

[0151] In step S340, if the execution safety margin is higher than the preset execution threshold, the target business process is suspended step by step according to the logical order of the resource dependency chain. The local configuration file is modified according to the differential configuration data using the atomic transaction mechanism. After the modification is completed, the target business process is restored in the reverse order of the resource dependency chain.

[0152] In this embodiment, when the system determines that the current execution safety margin is higher than a preset execution threshold, it indicates that the node currently has the resource conditions to perform configuration updates. At this time, the system suspends the target service process step by step according to the logical order of the resource dependency chain to reduce the risk of dependency interruption, data flow inconsistency, or service coordination mismatch during configuration overwrite. The suspension order can be executed from upstream to downstream according to the dependency chain relationship, while the recovery order is the reverse, so that the service topology after recovery is as consistent as possible with that before the update.

[0153] After suspending the target business process, the system uses atomic transactions to modify the local configuration file. For example, the updated configuration content can be written to a temporary area first, and then the original configuration file can be overwritten atomically after the write is confirmed. This process reduces the risk of incomplete, structurally corrupted, or partially effective configuration files due to abnormal interruptions during the configuration write process. After the configuration modification is complete, the system then resumes the target business process in reverse order of the resource dependency chain, gradually bringing the business processing back to the running state, which helps improve the consistency and recoverability of the configuration application process.

[0154] In step S350, if the execution safety margin is lower than or equal to the execution threshold, the local configuration update task is pushed into the asynchronous delay queue, and the load awareness probe is started to continuously detect the load idle window of the target edge node.

[0155] In this embodiment, when the system determines that the execution safety margin is lower than or equal to the preset execution threshold, it indicates that the current node is in a state of peak business, resource shortage, or high processing pressure. At this time, immediately executing the configuration update may further strain node resources. Therefore, the system temporarily pushes the local configuration update task into an asynchronous delay queue to postpone its execution. Simultaneously, the node side activates a load awareness probe to continuously monitor current resource utilization and changes in business load in order to find a suitable idle window for releasing the delayed task.

[0156] Specifically, load sensing probes can detect node-side load trends using periodic polling or event-triggered methods. For example, in industrial internet scenarios, peak data collection times or periods of centralized data upload can be avoided; in remote monitoring scenarios, peak data collection times, periods of alarm surges, or periods of high link occupancy can be avoided. Thus, the system can postpone configuration update operations to more suitable resource times, thereby reducing the disruption to current business operations caused by the update process.

[0157] In step S360, after the load sensing probe detects a load idle window, the real-time resource utilization rate of the target edge node is re-acquired, and the execution safety margin is recalculated in combination with the current health score.

[0158] In this embodiment, the appearance of a load idle window only indicates that the node's current resource utilization has improved compared to before, but it does not necessarily mean that the conditions for safely performing configuration updates are met. Therefore, when the load sensing probe detects that the load has entered a relatively stable or low range, the system does not immediately release the delayed update task, but instead re-executes the resource status acquisition and safety margin calculation process. Specifically, the system re-acquires the real-time resource utilization rate at the current moment. and the corresponding current health score The execution safety margin is then obtained again based on the same calculation logic as in step S330. .

[0159] Through this recalculation process, the system can determine whether to release update tasks in the asynchronous delayed queue based on the latest state, rather than relying on previously invalidated evaluation results. This helps improve the accuracy of determining when to release delayed tasks and reduces the problem of erroneous releases caused by short-term load fluctuations.

[0160] In step S370, when the recalculated execution safety margin is higher than the execution threshold, the local configuration update task is extracted from the asynchronous delay queue, and the target business process is suspended step by step according to the logical order of the resource dependency chain. The local configuration file is modified according to the differential configuration data using the atomic transaction mechanism, and the target business process is restored in reverse order of the resource dependency chain after the modification is completed.

[0161] In this embodiment, when the recalculated execution safety margin is higher than the execution threshold, the system considers that suitable execution conditions are currently available. Therefore, it retrieves the previously temporarily stored local configuration update task from the asynchronous delay queue and executes the same configuration application process as in step S340. Specifically, the system still suspends the target business process according to the logical order of the resource dependency chain, then modifies the local configuration file using atomic transactions, and restores the target business process in reverse order of the resource dependency chain after the modification is completed. By reusing the same set of execution logic, the immediate update path and the delayed update path can be kept consistent in their specific execution behaviors. After adopting the processing method of steps S350 to S370, the node side can postpone the update task when resources are currently scarce and automatically release the update operation after the resource conditions improve, without having to reacquire the configuration package or rely on additional manual intervention, which helps to improve the adaptability of the configuration update operation to the real-time business load of the edge node.

[0162] Through the embodiments of this application, by comparing the key-value pairs of the differential configuration data with the current local configuration, identifying the target business process and resource dependency chain, generating and saving differential snapshots, assessing execution safety margins, and performing update scheduling based on asynchronous delay queues and idle load windows, the target edge node can complete a relatively fine-grained, recoverable, and load-adaptive local configuration update under resource-constrained and continuous business operation conditions. This helps reduce the impact of configuration updates on the real-time services of edge nodes and improves the robustness and controllability of the configuration application process.

[0163] Regarding the implementation details of the state rollback triggered by the differentiated snapshot in step S170, in some examples of the embodiments of this application, when the target edge node is in a multi-node cluster scenario, the rollback execution order can be scheduled by a cluster collaboration method.

[0164] First, the updated current health score is detected within the adaptive confirmation time window. When preset abnormal conditions are met, the local rollback process of the target edge node is intercepted immediately, and encapsulated with business weights. Current health score Update risk level The asynchronous rollback intention information of abnormal characteristics is reported to the cluster coordinator through the out-of-band communication channel and enters the pending authorization suspension state.

[0165] In this embodiment, when the edge computing system is deployed in a multi-node cluster scenario, such as multiple collaborative edge gateways in a substation, multiple interconnected controllers in an industrial production line, or multiple regional edge nodes in a distributed site, if a configuration update has a common defect, multiple nodes may simultaneously meet abnormal conditions within a similar timeframe. If each node independently executes a snapshot rollback immediately after detecting the anomaly locally, control messages on the out-of-band management link and a large number of concurrent read / write operations on the node side may occur simultaneously, thereby increasing the probability of out-of-band channel congestion and node local resource contention. Therefore, in this embodiment, the target edge node detects the updated current health score... After the preset abnormal conditions are met, the local rollback is not executed directly. Instead, the original local immediate rollback process is intercepted and the rollback operation is transferred to the cluster collaborative scheduling process.

[0166] Subsequently, the target edge node extracts information related to this rollback determination and generates asynchronous rollback intention information, which is then reported to the cluster coordinating scheduler. This asynchronous rollback intention information may include the node's business weight within the cluster. Current health score This update updates the risk level. And anomaly characteristics used to describe anomaly types. For example, in a substation scenario, nodes undertaking core routing forwarding or critical data collection and aggregation tasks may have higher business weights, while ordinary edge data collection nodes have relatively lower business weights; anomaly characteristics may include status information such as resource exhaustion, link disconnection, service instability, and abnormal exit of critical processes. After reporting the above asynchronous rollback intention information through the out-of-band communication channel, the node itself enters a pending authorization state to wait for the scheduler to issue the rollback authorization result. With this processing method, the node rollback operation is changed from being triggered locally and independently to being executed under the constraint of cluster scheduling, which helps to reduce local conflicts caused by multiple nodes rolling back simultaneously.

[0167] Then, the cluster coordinating scheduler comprehensively evaluates the business weight, current health score, and update risk level of each reporting node, performs multi-criteria priority assessment, and combines the abnormal characteristics provided by each node to conduct concurrent rollback conflict assessment, identifying nodes with conflicts and lower priorities as delayed rollback nodes.

[0168] In this embodiment, after receiving asynchronous rollback intention information reported by multiple nodes, the cluster collaborative scheduler performs a unified priority assessment on each node. As a preferred implementation, the system can calculate the collaborative rollback priority of each intending node according to the following collaborative priority formula. :

[0169] Equation (15)

[0170] In the formula, This is a preset adjustment factor used to reflect the relative roles of business weight, the degree of health status impairment, and update risk level in priority assessment. As shown in the formula, when a node has a high business weight, a low current health score, and a high update risk level, its corresponding collaborative rollback priority is... Relatively high. With this priority assessment method, the cluster coordinating scheduler can identify the objects that should have a higher priority to enter the rollback process from among multiple nodes willing to roll back.

[0171] After completing the priority calculation, the cluster coordinating scheduler further performs concurrent rollback conflict assessment based on the anomaly characteristics reported by each edge node. Conflict assessment can be used to determine whether different nodes may contend for the same shared resources, out-of-band bandwidth, database access paths, or other restricted objects during the rollback process. When the scheduler determines that there are concurrent conflicts among multiple nodes, it can prioritize retaining the higher-priority nodes for the current batch of rollback, and determine the remaining lower-priority nodes with resource conflicts as delayed rollback nodes, thereby reducing the degree of resource contention caused when multiple nodes enter the rollback process simultaneously.

[0172] Then, it receives rollback authorization instructions issued in batches by the cluster coordinator based on priority sorting and conflict avoidance results.

[0173] Specifically, after completing priority calculation and conflict assessment, the cluster coordinating scheduler, based on the set of nodes not identified as delayed rollback nodes, determines the coordinating rollback priority. The system prioritizes nodes based on their performance and issues rollback authorization commands to the corresponding nodes in batches. By using batch authorization, the system prioritizes rollback opportunities for more critical nodes in poor condition, while controlling the number of nodes in rollback execution at the same time, keeping it within the capacity of out-of-band links and cluster resources. This step helps to make the rollback execution order more orderly in a multi-node cluster.

[0174] Furthermore, upon receiving the authorization instruction, the system utilizes an atomic transaction mechanism to load a differentiated snapshot for state recovery, restoring the target business process and configuration file to their running state before the application of the differentiated configuration data. Upon completion, the system sends a rollback completion signal to the cluster coordinator, enabling the cluster coordinator to release the current rollback concurrency quota and issue subsequent batches of authorization instructions to delayed rollback nodes. This avoids out-of-band network congestion and local storage resource contention caused by disordered rollback.

[0175] In this embodiment, when the target edge node receives the rollback authorization instruction issued by the cluster coordinator, the node exits the pending authorization state and loads a pre-saved differential snapshot using atomic transactions to restore the configuration file and related business process states. For example, the restoration process may include rewriting the original configuration values ​​before the update back to the local configuration file, restoring the runtime context of the relevant business processes, and restoring the necessary connection states, thereby returning the target edge node to its running state before applying the differential configuration data. Using atomic transactions to perform state restoration helps reduce the occurrence of partial restoration, incomplete state, or inconsistent configurations during the rollback process.

[0176] After the local rollback execution is complete, the target edge node sends a rollback completion signal to the cluster coordinator via out-of-band communication. Upon receiving this signal, the scheduler can release the rollback concurrency quota currently occupied by the node and, accordingly, issue rollback authorization instructions to nodes already identified as having delayed rollback or those in subsequent batches. Through this process, the rollback operations of different nodes can proceed sequentially based on the global scheduling results, thereby reducing the degree to which out-of-band links and local storage resources are concentratedly occupied within the same time period.

[0177] This embodiment achieves a more orderly state recovery process in multi-node cluster scenarios by intercepting local immediate rollback processes, centrally reporting asynchronous rollback intention information, prioritizing based on business weight, health status, and update risk level, conducting concurrency conflict assessments based on anomaly characteristics, and promoting subsequent rollbacks through batch authorization and completion feedback. This helps reduce out-of-band link congestion and node resource contention during simultaneous rollbacks by multiple nodes, thereby improving the stability of rollback execution in a cluster environment.

[0178] Figure 4 This diagram illustrates an example of the system operation mechanism of an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes according to an embodiment of this application.

[0179] like Figure 4As shown in the diagram, the overall operating mechanism of this system includes an input area, a core processing area, and an output area, and interacts with the central management platform and out-of-band communication channels. The input area provides the basic input content for entering the core processing area. This basic input content includes baseline configurations and indicators, encrypted configuration packages, and relevant inputs from the edge nodes. The data flow in the input area first enters the signature verification and decryption module in the core processing area to verify and parse the received encrypted configuration packages, and extract the configuration update content and update risk level.

[0180] After signature verification and decryption are completed, the relevant data enters the heterogeneous weighted health scoring module to obtain the corresponding health assessment result by combining it with the node's operational status information. The health assessment result is further input into the dynamic confirmation time calculation module and the differentiated snapshot backup module, respectively. The dynamic confirmation time calculation module generates the confirmation observation time corresponding to the current node status and update risk, while the differentiated snapshot backup module preserves the recovery basis during configuration processing. Subsequently, the results from both modules are sent to the collaborative scheduling decision module, which makes a comprehensive judgment based on the control commands provided by the out-of-band communication channel.

[0181] The output area receives the processing results from the collaborative scheduling decision module. When the collaborative scheduling decision module determines that the current configuration processing meets the effective conditions, it outputs the results to the configuration submission and effective module; when the collaborative scheduling decision module determines that the original state needs to be restored, it outputs the results to the safe state rollback module. Simultaneously, the central management platform can receive health indicator feedback from the core processing area, while the out-of-band communication channel is used to carry control commands and related status interactions, thus providing external communication support throughout the entire configuration processing process.

[0182] To verify the effectiveness and applicability boundaries of the out-of-band asynchronous security configuration and state rollback method provided in this application embodiment in complex heterogeneous environments, controlled testing was conducted based on a distributed network simulation platform. Specifically, the test experiment used the NS-3 network simulator and Docker containerization technology to construct a hybrid testbed to simulate the interaction environment between edge computing nodes and the underlying network.

[0183] In terms of network topology and condition settings, the experimental scenario simulated a multi-type heterogeneous node network including high-performance edge servers, smart gateways, and micro sensors. Meanwhile, to verify the performance of the solution under constrained network conditions, typical weak network characteristics such as intermittent disconnections, sudden high packet loss, and long latency were injected into the out-of-band communication link layer to simulate the network conditions that edge nodes might face under complex field deployment conditions.

[0184] This test primarily compares the performance differences between the traditional static confirmation rollback scheme and the out-of-band asynchronous adaptive collaborative scheme provided in this application's embodiments. The traditional static confirmation rollback scheme serves as the control group, employing a fixed ten-minute confirmation observation window and node-independent full snapshot rollback. The test evaluation dimensions include overall system availability, anomaly recovery efficiency, multi-node concurrent rollback conflict rate, and out-of-band network control overhead, to quantitatively compare the performance of the two schemes under different conditions.

[0185] Figure 5 This diagram illustrates a comparative simulation of the configuration update convergence rate and system availability of different methods in a constrained network environment. The comparative experiment aims to verify the real-world effectiveness of the proposed technical solution in complex heterogeneous node clusters with constrained network characteristics such as intermittent disconnections and sudden high packet loss. The horizontal axis represents the time evolution after configuration distribution, and the vertical axis represents the cumulative proportion of nodes that successfully applied the configuration without erroneous rollback. The dashed lines marked with squares represent traditional static update schemes using fixed confirmation time windows (e.g., 10 minutes), while the solid lines marked with circles represent the out-of-band asynchronous secure configuration and state rollback method provided in this embodiment.

[0186] like Figure 5 As shown in the curve trend, in the initial 0 to 5 minutes of the update, the cumulative success rate of nodes in the traditional scheme (i.e., static confirmation rollback) rises rapidly. However, when it reaches its fixed 10-minute confirmation threshold, due to the failure of a large number of edge nodes to send confirmation instructions back to the central platform in a timely manner in a restricted weak network environment, the traditional mechanism triggers a blind large-scale forced rollback, resulting in a precipitous drop in the success rate curve, ultimately converging to only about 45%. In contrast, the method of this application dynamically adjusts the adaptive confirmation time window by combining the current health score and the update risk level, automatically extending the observation period for nodes in good condition but encountering network fluctuations. Although the convergence speed is slightly slower in the early stage due to the execution of adaptive observation, it smoothly crosses the collapse threshold of the traditional scheme, avoiding system-level misjudgment rollback caused by simple network disconnection, and ultimately stabilizes the overall network update success rate at a high level of about 90%, which shows that the dynamic collaborative mechanism of this application has excellent fault tolerance robustness in harsh network environments.

[0187] Figure 6This diagram illustrates a comparative simulation of the recovery efficiency versus communication overhead trade-offs of different methods in a multi-node failure scenario. The experiment aims to evaluate the efficiency of different approaches in restoring core services to a safe state when a high-risk update triggers widespread service anomalies within the cluster, and to objectively quantify the additional control plane communication overhead introduced by cross-node collaboration mechanisms. In the diagram, the horizontal axis represents the number of edge nodes in the network (increasing from 50 to 250 nodes); the left vertical axis corresponds to a bar chart representing the system recovery time (i.e., the time required for a specific proportion of high-service-weight nodes to complete the rollback to a safe state, in seconds); and the right vertical axis corresponds to a line graph representing the average out-of-band communication overhead per node (in KB / s).

[0188] like Figure 6 The bar chart illustrating recovery efficiency shows that in a large-scale concurrent failure scenario with 250 nodes, traditional solutions, lacking a global coordination mechanism, suffer from severe local storage resource contention and out-of-band management link congestion due to instantaneous independent rollbacks. This causes system recovery time to deteriorate non-linearly with the number of nodes. In contrast, the method in this application, based on a collaborative priority assessment mechanism considering business weight, degree of health status impairment, and risk level, prioritizes core nodes for differentiated rollbacks. This collaborative mechanism effectively eliminates local conflicts caused by simultaneous rollbacks of multiple nodes, significantly reducing system recovery time by approximately 60% compared to traditional solutions and substantially improving disaster recovery efficiency for heterogeneous clusters.

[0189] On the other hand, the line graph representing the communication cost shows that the method in this application has an average out-of-band communication overhead per node that is about 1.5 times higher than the traditional silent independent rollback scheme. This is because during fault diagnosis and collaborative decision-making, the target edge node needs to actively report asynchronous rollback intention information and maintain state feedback. The line graph clearly and objectively reveals the inherent trade-off logic of the technical solution in this application: that is, by moderately increasing the control plane communication overhead of the out-of-band channel, high availability and state consistency of the cluster under extreme failure scenarios are achieved. In actual engineering deployments, for extremely limited narrowband scenarios, the system can further adapt to the compromise requirements of communication overhead by dynamically adjusting the broadcast frequency of health status, etc.

[0190] Figure 7This diagram illustrates a comparative simulation of the performance of different methods in terms of accuracy in detecting system health status faults. The comparative experiment verifies the ability of the heterogeneous weighted health assessment method provided in this application to distinguish between real system faults and transient fluctuations. In the experiment, abnormal states such as memory leaks or process deadlocks are used as positive samples, while normal transient high-load computing tasks are used as negative samples. The TPR (True Positive Rate) and FPR (False Positive Rate) of the method and the fixed-weight scheme in this application are statistically analyzed at different sensitivity thresholds.

[0191] like Figure 7 As shown, the ROC (Receiver Operating Characteristic) curve corresponding to the method of this embodiment is closer to the upper left region in the figure, and its area under the curve (AUC) is 0.92, while the area under the curve of the fixed weight scheme is 0.76, indicating that the method of this embodiment has a better overall distinguishing ability in fault state identification.

[0192] Furthermore, under the condition corresponding to the auxiliary line in the figure where TPR=95%, it can be seen that the FPR corresponding to the method of this application embodiment is about 8%, while the FPR corresponding to the fixed weight scheme is about 25%. This indicates that, while maintaining a high true rate, the method of this application embodiment can reduce the probability of misjudgment caused by transient fluctuations, thereby improving the stability of the health status assessment results.

[0193] Based on the simulation results above, the significant advantages and engineering trade-offs of the out-of-band asynchronous security configuration and state rollback method provided in this application embodiment in constrained heterogeneous environments are objectively and multidimensionally verified. On the one hand, the adaptive confirmation time window constructed through nonlinear smooth mapping logic effectively overcomes the vulnerability of traditional fixed timeout mechanisms in weak network conditions, avoids system-level erroneous rollbacks caused by brief network fluctuations, and significantly improves the final convergence rate and availability of configuration updates. On the other hand, based on heterogeneous weighted health scoring and its adaptive feedback update mechanism, the target edge node gains the ability to automatically filter out normal transient load noise, significantly reducing the erroneous rollback rate while ensuring an extremely high real fault interception rate. At the same time, the cluster collaborative scheduling strategy effectively eliminates disordered concurrent rollback conflicts during large-scale node failures, greatly shortening the recovery time of critical services. Although maintaining a cross-node collaborative view brings certain out-of-band communication overhead and there is a brief resource occupation during the initial adaptive learning phase, this mechanism objectively achieves an engineering trade-off between controllable bandwidth costs and high cluster availability and state consistency.

[0194] In summary, this application addresses the configuration management challenges faced by heterogeneous edge nodes in complex, constrained, or offline environments by constructing a full-link closed-loop control architecture encompassing out-of-band encrypted trusted reception, multi-dimensional dynamic health awareness, adaptive time confirmation, differentiated snapshot error prevention, and multi-node collaborative rollback scheduling. This technical solution not only ensures high security and controllability and precise local state recovery capabilities during configuration changes and rollback processes, but also fundamentally enhances the disaster recovery and fault tolerance resilience and business continuity of heterogeneous edge computing networks under harsh network conditions.

[0195] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of combined actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Secondly, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0196] Figure 8 A structural block diagram of an example of an out-of-band asynchronous security configuration and state rollback system for heterogeneous edge nodes according to an embodiment of this application is shown.

[0197] like Figure 8 As shown, the out-of-band asynchronous security configuration and state rollback system 800 for heterogeneous edge nodes includes an out-of-band packet receiving unit 810, a trust verification and decryption unit 820, a health score calculation unit 830, a confirmation window generation unit 840, a snapshot update execution unit 850, an update health monitoring unit 860, and a rollback and solidification control unit 870.

[0198] The out-of-band packet receiving unit 810 is used to receive encrypted configuration packets through an out-of-band communication channel. The encrypted configuration packets carry differential configuration data and an update risk level corresponding to the differential configuration data.

[0199] The trust verification and decryption unit 820 is used to perform integrity verification, legality verification and decryption of the encrypted configuration package based on the local hardware trust root, so as to extract the differential configuration data and the update risk level.

[0200] The health score calculation unit 830 is used to collect real-time operating indicators and perform heterogeneous weighted normalization processing on the real-time operating indicators in combination with the pre-stored historical health baseline to calculate the current health score.

[0201] The confirmation window generation unit 840 is used to dynamically calculate an adaptive confirmation time window for observing the effective status of the configuration update based on the current health score and the update risk level.

[0202] The snapshot update execution unit 850 is used to generate a differentiated snapshot reflecting the current running state of the target edge node before applying the differentiated configuration data, and to perform a local configuration update based on the differentiated configuration data without requiring synchronization with other edge nodes to complete the update.

[0203] The health monitoring unit 860 is used to continuously collect updated real-time operating indicators within the adaptive confirmation time window, and to perform heterogeneous weighted normalization processing on the updated real-time operating indicators in combination with the historical health baseline, so as to update the current health score.

[0204] The rollback and solidification control unit 870 is used to trigger a rollback to the running state before the application of the differential configuration data based on the differential snapshot if it detects that the updated current health score meets the preset abnormal conditions, or if the adaptive confirmation time window ends and no confirmation instruction is received from the out-of-band communication channel; otherwise, it solidifies the local configuration update to make the differential configuration data effective.

[0205] In some embodiments, this application provides a non-volatile computer-readable storage medium storing one or more programs including execution instructions. The execution instructions can be read and executed by an electronic device (including but not limited to a computer, server, or network device) to perform the steps of any of the above-described heterogeneous edge node out-of-band asynchronous security configuration and state rollback methods of this application.

[0206] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the steps of any of the above-described methods for out-of-band asynchronous security configuration and state rollback of heterogeneous edge nodes.

[0207] In some embodiments, this application also provides an electronic device including: at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of an out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes.

[0208] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0209] The electronic devices in this application can exist in various forms, including but not limited to: mobile communication devices, ultra-mobile personal computer devices, portable entertainment devices, or other airborne electronic devices with data interaction functions.

[0210] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0212] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An out-of-band asynchronous security configuration and state rollback method for heterogeneous edge nodes, applied to target edge nodes, characterized in that, The method includes: The encrypted configuration packet is received through an out-of-band communication channel. The encrypted configuration packet carries differential configuration data and an update risk level corresponding to the differential configuration data. The encrypted configuration package is verified for integrity, legality, and decryption based on the local hardware root of trust in order to extract the differential configuration data and the update risk level. Real-time operating indicators are collected, and heterogeneous weighted normalization is performed on the real-time operating indicators in combination with the pre-stored historical health baseline to calculate the current health score; Based on the current health score and the update risk level, an adaptive confirmation time window for observing the effective status of the configuration update is dynamically calculated. Before applying the differential configuration data, a differential snapshot reflecting the current operating status of the target edge node is generated, and a local configuration update is performed based on the differential configuration data without requiring synchronization with other edge nodes to complete the update. Within the adaptive confirmation time window, updated real-time operating indicators are continuously collected, and heterogeneous weighted normalization processing is performed on the updated real-time operating indicators in conjunction with the historical health baseline to update the current health score; If the updated current health score is detected to meet preset abnormal conditions, or if the adaptive confirmation time window ends without a confirmation instruction being received from the out-of-band communication channel, a rollback to the running state before the application of the differential configuration data is triggered based on the differential snapshot; otherwise, the local configuration update is solidified so that the differential configuration data takes effect.

2. The method according to claim 1, characterized in that, The process of performing integrity verification, legality verification, and decryption on the encrypted configuration package based on the local hardware root of trust to extract the differential configuration data and the update risk level includes: Parse the header metadata of the encrypted configuration package to extract the global digital signature issued by the central management platform, the configuration package sequence identifier, and the dynamic data key encapsulated by the asymmetric encryption algorithm; The configuration packet sequence identifier is compared with the anti-replay timing watermark maintained by the target edge node in the trusted isolation storage area. If the configuration packet sequence identifier is lower than or equal to the anti-replay timing watermark, it is determined to be expired or replay data and the encrypted configuration packet is discarded. After the timing verification is passed, the global digital signature is verified using the public key of the central management platform pre-installed in the target edge node to complete the integrity verification. After the integrity verification is passed, the physically isolated, non-clonable private key within the local hardware trust root is invoked to decrypt the dynamic data key encapsulated by the asymmetric encryption algorithm, thereby recovering the plaintext dynamic data key and completing the legitimacy verification. Using the dynamic data key of the plaintext, the payload area of ​​the encrypted configuration package is symmetrically decrypted within the trusted execution environment to extract the differential configuration data, the update risk level, and the accompanying heterogeneous operating environment compatibility constraints. The heterogeneous operating environment compatibility constraints are matched and verified with the current underlying firmware version and hardware computing power characteristics of the target edge node. After the matching and verification are passed, it is determined that the differential configuration data and the update risk level are successfully extracted and valid on the current target edge node. At the same time, the anti-replay timing water level is updated to the current configuration package sequence identifier.

3. The method according to claim 1, characterized in that, The real-time operational indicators are collected and combined with pre-stored historical health baselines to perform heterogeneous weighted normalization processing on the real-time operational indicators to calculate the current health score, including: Obtain the original values ​​of the target edge node's operational metrics across multiple dimensions at the current sampling time; Based on the historical statistical characteristics of each dimension of indicators stored in the historical health baseline, corresponding normalization mapping logic is applied to the operating indicators with different characteristics to obtain normalized indicator values. The normalization mapping logic includes: positive linear extreme value mapping for positive indicators, reverse linear extreme value mapping for negative indicators, and normal mapping based on probability density distribution for bidirectional indicators with optimal operating range. Calculate the heterogeneous allocation weights corresponding to each dimension indicator; the heterogeneous allocation weights combine the global importance characteristics of the indicator in the current business scenario, as well as the specific sensitivity parameters of the target edge node for specific operating indicators due to hardware heterogeneity. A weighted summation process is performed based on the normalized index value and the corresponding heterogeneous allocation weight to obtain the current health score, which reflects the current overall operating status of the target edge node.

4. The method according to claim 3, characterized in that, After the local configuration update is solidified to make the differential configuration data effective, the method further includes adaptive iterative updating of the specific sensitivity parameter based on an error backfeedback mechanism, specifically including: During the steady-state observation period after the configuration update is solidified, the current health score is compared with the preset ideal health target, and a differentiable health deviation loss model is constructed based on the deviation between the two. Extract the gradient of the health deviation loss model relative to the normalized index values ​​of each dimension, and use feedback learning logic to iteratively adjust the specific sensitivity parameters of each dimension. The heterogeneous allocation weight for the next cycle is recalculated using the specific sensitivity parameter after iterative adjustment, so that the target edge node can automatically correct its sensitivity to fluctuations in various dimensional indicators based on historical operation feedback, thereby achieving dynamic suppression of normal transient load noise in heterogeneous environments.

5. The method according to claim 1, characterized in that, The step of dynamically calculating an adaptive confirmation time window for observing the effective status of configuration updates based on the current health score and the update risk level includes: Based on a preset risk-threshold association logic, the updated risk level is converted into a corresponding risk adjustment threshold; The window duration coefficient of the current health score relative to the risk adjustment threshold is calculated using nonlinear smoothing mapping logic. The nonlinear smoothing mapping logic is configured to output a smaller window duration coefficient when the health score is higher than the risk requirement, and to output a rapidly increasing window duration coefficient when the health score is close to or lower than the risk requirement. The window duration coefficient is used to scale the preset observation time interval to generate the adaptive confirmation time window; By leveraging the monotonic adjustment characteristics of the nonlinear smooth mapping logic, the system extends the observation window in sub-healthy states or high-risk update scenarios to adjust towards the global maximum confirmation time, thereby enhancing the depth of configuration security monitoring in out-of-band asynchronous communication environments.

6. The method according to claim 1, characterized in that, Before applying the differential configuration data, generating a differential snapshot reflecting the current operating state of the target edge node, and performing a local configuration update based on the differential configuration data without requiring synchronization with other edge nodes, includes: The differential configuration data is compared with the key-value pair of the currently running configuration file to extract the set of key configuration items to be modified. Based on the preset configuration-service mapping topology, the target business process affected by the set of key configuration items and its corresponding resource dependency chain are identified. For the target business process, capture its transient running context and network socket state at the current moment, and combine it with the original key values ​​of the key configuration item set before the update, as well as the call relationship of each related component in the resource dependency chain, to encapsulate and generate the differentiated snapshot and store it in the local protected isolated storage area. The real-time resource utilization rate of the target edge node is collected, and combined with the current health score, the execution safety margin for this configuration update is calculated through a preset weighting function. If the execution safety margin is higher than the preset execution threshold, the target business process is suspended step by step according to the logical order of the resource dependency chain. The local configuration file is modified according to the differential configuration data using the atomic transaction mechanism. After the modification is completed, the target business process is restored according to the reverse order of the resource dependency chain. If the execution safety margin is lower than or equal to the execution threshold, the local configuration update task is pushed into the asynchronous delay queue, and the load awareness probe is started to continuously detect the load idle window of the target edge node. When the load sensing probe detects the load idle window, it re-collects the real-time resource utilization of the target edge node and recalculates the execution safety margin in conjunction with the current health score. When the recalculated execution safety margin is higher than the execution threshold, it extracts the local configuration update task from the asynchronous delay queue and suspends the target business process step by step according to the logical order of the resource dependency chain. It uses the atomic transaction mechanism to modify the local configuration file according to the differential configuration data and restores the target business process in reverse order of the resource dependency chain after the modification is completed.

7. The method according to claim 6, characterized in that, In a multi-node cluster scenario where the target edge node is located, triggering a rollback based on the differential snapshot to the running state before the application of the differential configuration data specifically includes: When the updated current health score is detected to meet the preset abnormal conditions within the adaptive confirmation time window, the local immediate rollback process of the target edge node is intercepted, and asynchronous rollback intention information containing business weight, current health score, update risk level and abnormal characteristics is encapsulated and reported to the cluster coordinator through out-of-band communication channel. The cluster collaborative scheduler performs multi-criteria priority assessment by comprehensively considering the business weight of each reporting node, the current health score, and the update risk level, and conducts concurrent rollback conflict assessment by combining the abnormal characteristics provided by each node, and determines the nodes with conflicts and lower priorities as delayed rollback nodes. Receive rollback authorization instructions issued in batches by the cluster coordinating scheduler based on priority sorting and conflict avoidance results; Upon receiving the authorization instruction, the differential snapshot is loaded using the atomic transaction mechanism to restore the state. After completion, a rollback completion signal is sent back to the cluster coordinating scheduler so that the cluster coordinating scheduler releases the current rollback concurrency quota and issues subsequent batches of authorization instructions to the delayed rollback nodes, thereby avoiding out-of-band network congestion and local storage resource contention caused by disordered rollback.

8. An out-of-band asynchronous security configuration and state rollback system for heterogeneous edge nodes, deployed on the target edge node, characterized in that, The system includes: An out-of-band packet receiving unit is used to receive encrypted configuration packets through an out-of-band communication channel. The encrypted configuration packets carry differential configuration data and an update risk level corresponding to the differential configuration data. The trust verification and decryption unit is used to perform integrity verification, legality verification and decryption of the encrypted configuration package based on the local hardware trust root, so as to extract the differential configuration data and the update risk level; The health score calculation unit is used to collect real-time operating indicators and perform heterogeneous weighted normalization processing on the real-time operating indicators in combination with the pre-stored historical health baseline to calculate the current health score. The confirmation window generation unit is used to dynamically calculate an adaptive confirmation time window for observing the effective status of the configuration update based on the current health score and the update risk level. The snapshot update execution unit is used to generate a differentiated snapshot reflecting the current running state of the target edge node before applying the differentiated configuration data, and to perform a local configuration update based on the differentiated configuration data without requiring synchronization with other edge nodes to complete the update. The health monitoring unit is updated to continuously collect updated real-time operating indicators within the adaptive confirmation time window, and to perform heterogeneous weighted normalization processing on the updated real-time operating indicators in combination with the historical health baseline in order to update the current health score. The rollback and solidification control unit is used to trigger a rollback to the running state before the application of the differential configuration data based on the differential snapshot when the updated current health score is detected to meet preset abnormal conditions, or when the adaptive confirmation time window ends and no confirmation instruction is received from the out-of-band communication channel; otherwise, the local configuration update is solidified so that the differential configuration data takes effect.

9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the method as described in any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-7.

Images