A heterogeneous energy edge off-line synchronous self-healing method, system, device and storage medium

Abstract

The application discloses a kind of heterogeneous energy edge offline synchronous self-healing method, system, equipment and storage medium, it is related to energy internet of things and edge computing technology field, including obtaining the cloud side cooperation state information in heterogeneous energy internet of things network, the state synchronization benchmark of edge node is formed;When the state synchronization benchmark meets offline takeover condition, the offline takeover state of edge node is generated;The offline takeover state is used to represent the temporary takeover relationship of local service during edge node is unreachable in cloud;Based on the offline takeover state, the state change and service execution result of heterogeneous energy equipment are cached and accepted, and offline autonomous acceptance record is generated in combination with the local autonomy rule of edge node;The method of the application improves network interruption takeover accuracy, offline service continuity and consistency after cloud side state.

Description

Technical Field

[0001] This invention relates to the field of energy Internet of Things and edge computing technology, specifically to a heterogeneous energy edge offline synchronous self-healing method, system, device and storage medium. Background Technology

[0002] The energy Internet of Things (IoT) is gradually evolving from a centralized monitoring architecture to a cloud-edge collaborative architecture. In scenarios such as electricity, gas, heating, energy storage, charging and swapping, and integrated energy stations, numerous heterogeneous energy devices are connected to a unified platform through sensors, control terminals, edge gateways, and industrial communication protocols. This forms an IoT network covering device sensing, status acquisition, command issuance, operation monitoring, and business linkage. Different energy devices differ in communication protocols, data formats, acquisition frequencies, control logic, and security constraints. Simply relying on centralized cloud processing is insufficient to meet the real-time and continuous requirements of on-site operations. Edge computing has therefore been introduced into energy IoT systems. Edge nodes undertake functions such as protocol adaptation, data preprocessing, status caching, rule execution, and on-site control, while maintaining heartbeat confirmation, status synchronization, application deployment, and configuration distribution relationships with the cloud platform. Existing cloud-edge collaborative platforms typically incorporate mechanisms such as node management, application hosting, fault detection, primary / backup switching, data verification, redundant storage, and backup recovery to maintain collaborative operation between the edge and the cloud platform.

[0003] Existing cloud-edge collaborative systems primarily rely on alarms, reconnection, or simple caching in communication interruption scenarios, offering insufficient support for continuous local business operation during periods of cloud unavailability. Edge nodes often lack a clear takeover starting point during network outages, and device states, business execution results, and local time sequences generated during offline periods are easily scattered, making it difficult to reconstruct the state source and execution order after recovery. While some systems possess local rule execution capabilities, the lack of a stable correlation between the autonomous execution scope of the edge side, device security boundaries, and offline business permissions can lead to unclear correspondences between offline execution results and subsequent state calibration. After network recovery, historical data is often processed using full retransmission, time-period playback, or simple deduplication. When there are many edge nodes, frequent device state changes, or long offline periods, issues such as large amounts of compensation data, duplicate writes, state version conflicts, and repeated business triggering can easily arise. While digest verification can be used for data integrity verification, in cloud-edge offline recovery scenarios, if the digest identifier does not establish a stable correspondence with the edge node, state version, local incremental time sequence, and business execution results, it remains difficult to support rapid comparison, compensation location, and consistency restoration of massive offline records. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is that existing energy Internet of Things cloud-edge collaboration methods have problems such as: edge nodes lacking clear takeover basis when the cloud is unreachable; low continuity of business status during offline periods; and easy duplication or version conflict in historical data compensation after recovery. The invention also addresses the problem of how to maintain temporary local business takeover during network outages and achieve idempotent synchronization of cloud-edge status after network recovery.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a heterogeneous energy edge offline synchronization self-healing method, comprising: acquiring cloud-edge collaborative state information in a heterogeneous energy Internet of Things network to form a state synchronization benchmark for edge nodes; generating an offline takeover state for the edge nodes when the state synchronization benchmark meets the offline takeover conditions; the offline takeover state characterizing the temporary takeover relationship of the edge nodes on local services during periods when the cloud is unreachable; caching and accepting state changes and service execution results of heterogeneous energy devices based on the offline takeover state, and generating an offline autonomous acceptance record in conjunction with the local autonomous rules of the edge nodes; generating a state summary compensation relationship based on the state summary compensation relationship when the state synchronization benchmark characterizes cloud-edge collaborative recovery; and performing idempotent compensation synchronization on the cloud state and edge node state based on the state summary compensation relationship to generate a cloud-edge offline self-healing consistent state.

[0007] As a preferred embodiment of the heterogeneous energy edge offline synchronization self-healing method described in this invention, the state synchronization benchmark includes: establishing node grouping relationships for edge nodes after they are incorporated into the management system according to their respective business domains, and binding the online confirmation result, application carrying result, and most recent cloud state confirmation result of the same edge node in the node grouping relationship as synchronization anchor points to form a synchronization benchmark record that can be used to determine whether the cloud edge state is continuous.

[0008] As a preferred embodiment of the heterogeneous energy edge offline synchronization self-healing method described in this invention, the following steps are taken: when determining the offline takeover conditions, the most recent cloud status confirmation result among the synchronization anchor points is used as the takeover starting point. When the edge node does not obtain cloud status confirmation within a preset detection period and the local device collection result remains valid, the corresponding edge node is determined as a candidate takeover node. Offline license verification and device security boundary verification are performed on the services carried by the candidate takeover nodes, and the candidate takeover nodes that pass both the offline license verification and device security boundary verification are determined as the target takeover node.

[0009] As a preferred embodiment of the heterogeneous energy edge offline synchronization self-healing method described in this invention, when the target takeover node enters the offline takeover state, a local cache segment is established with the takeover starting point as the first state node, and the device status data, service execution results, and local incremental timing generated during the disconnection period are written into the local cache segment; the local cache segment maintains version association with the synchronization anchor point during the writing process, so that the local service status formed from the moment of network disconnection to before cloud edge recovery can be continuously traced according to the status source and execution timing.

[0010] As a preferred embodiment of the heterogeneous energy edge offline synchronous self-healing method described in this invention, in which: when generating the offline autonomous takeover record, the target takeover node matches the current device state in the local cache segment with the preset autonomous boundary, and determines the autonomous execution strategy of the local service based on the matching result; when the current device state meets the preset autonomous boundary, the execution result corresponding to the autonomous execution strategy is bound to the corresponding state node in the local cache segment to form an offline autonomous takeover record that simultaneously records the cache state and the autonomous execution result.

[0011] As a preferred embodiment of the heterogeneous energy edge offline synchronous self-healing method described in this invention, wherein: when generating the state summary compensation relationship, the offline autonomous undertaking record is divided into compensation segments according to the synchronization anchor point and the local incremental time sequence, and a summary identifier is generated for each compensation segment; the summary identifier is generated based at least on the edge node identifier, state version, local incremental time sequence and business execution result in the compensation segment, and the summary identifier is used to perform a hit comparison with the confirmed summary result in the cloud to determine the offline autonomous undertaking record that needs to be compensated.

[0012] As a preferred embodiment of the heterogeneous energy edge offline synchronization self-healing method described in this invention, wherein: during the idempotent compensation synchronization, compensation writing is performed on compensation segments for which the digest identifier does not match the cloud-confirmed digest result, and duplicate writing is suppressed on compensation segments for which the digest identifier matches the cloud-confirmed digest result; when the cloud state version after compensation writing and the local state version of the target takeover node form a continuous relationship based on the same synchronization anchor point, the cloud state and the target takeover node state are determined to be a consistent cloud-edge offline self-healing state.

[0013] Another objective of this invention is to provide a heterogeneous energy edge offline synchronization self-healing system. This system can form an integrated processing solution for edge node offline takeover, offline autonomous acceptance, and idempotent compensation synchronization after recovery through the coordinated operation of the synchronization takeover module, autonomous acceptance module, and summary self-healing module. This solves the problems of unclear local business takeover basis, low continuity of offline state acceptance, and easy duplication or version conflict of historical data after recovery in the current energy Internet of Things cloud-edge collaborative system when the cloud is unreachable.

[0014] As a preferred embodiment of the heterogeneous energy edge offline synchronization self-healing system described in this invention, it includes: a synchronization takeover module, an autonomous acceptance module, and a summary self-healing module; the synchronization takeover module is used to form a state synchronization benchmark for edge nodes based on cloud-edge collaborative state information, and generate an offline takeover state for edge nodes when the state synchronization benchmark meets the offline takeover conditions; the autonomous acceptance module is used to establish a local cache segment based on the offline takeover state, cache and accept the state changes and business execution results of heterogeneous energy devices, and generate an offline autonomous acceptance record in combination with local autonomous rules; the summary self-healing module is used to generate a state summary compensation relationship based on the offline autonomous acceptance record, and perform idempotent compensation synchronization according to the state summary compensation relationship to generate a cloud-edge offline self-healing consistent state.

[0015] Another object of the present invention is to provide a heterogeneous energy edge offline synchronous self-healing device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the heterogeneous energy edge offline synchronous self-healing method.

[0016] Another object of the present invention is to provide a heterogeneous energy edge offline synchronous self-healing storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the heterogeneous energy edge offline synchronous self-healing method.

[0017] The beneficial effects of this invention are as follows: The heterogeneous energy edge offline synchronization self-healing method provided by this invention, through the generation of state synchronization benchmarks and offline takeover states, ensures that edge nodes have a clear takeover starting point and basis when they are unreachable from the cloud, reducing the risk of uncontrolled service states and unclear takeover boundaries during network outages. Through the formation of local cache segments and offline autonomous takeover records, the device states, service execution results, and autonomous execution results generated during the disconnection period are kept continuously correlated, improving the integrity and traceability of local service takeover during offline periods. Through state summary compensation relationships and idempotent compensation synchronization, offline records after network recovery can be compensated and located according to the summary hit results, and duplicate writes are suppressed, reducing data redundancy, state conflicts, and duplicate triggering problems caused by full playback. Therefore, this invention achieves better results in terms of cloud-edge disconnection and reconnection management accuracy, edge offline service continuity, and state consistency after network recovery. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 The overall flowchart of a heterogeneous energy edge offline synchronous self-healing method provided by the present invention.

[0020] Figure 2 This is a schematic diagram of an offline synchronous self-healing system for heterogeneous energy edges provided by the present invention. Detailed Implementation

[0021] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0022] In this invention, "heterogeneous energy Internet of Things network" specifically refers to a cloud-edge collaborative network that connects to on-site equipment of power plants, energy storage stations, heating stations, charging and swapping stations, or integrated energy stations in the embodiments.

[0023] "Edge node" specifically refers to a computing node deployed on the site side of a plant that carries out data acquisition, edge gateway, local inference, or data services.

[0024] "Cloud-Edge Collaboration Status Information 100" specifically refers to the information formed by the online confirmation results of edge nodes, the status of plant nodes, the deployment status of edge applications, the effective status of protocol configuration, the collection results of local devices, and the status confirmation results of the cloud.

[0025] "State Synchronization Baseline 200" specifically refers to the baseline record used to determine whether the cloud state and the edge node state are continuous.

[0026] "Synchronization Anchor 201" specifically refers to the binding record between the node grouping relationship, online confirmation result, application carrying result, and the most recent cloud status confirmation result of the same edge node.

[0027] "Takeover starting point" specifically refers to the most recent cloud status confirmation result in synchronization anchor point 201.

[0028] "Offline takeover status 300" specifically refers to the status where the edge node continues to take over local business operations from the takeover starting point while the edge node is unreachable from the cloud.

[0029] "Local cache segment 301" specifically refers to a data segment that takes the takeover start point as the first status node and continuously writes device status data, business execution results, and local incrementing time sequence during the disconnection period.

[0030] "Offline Autonomous Acceptance Record 302" specifically refers to the record formed after binding the status node in the local cache segment 301 with the autonomous execution strategy and the autonomous execution result.

[0031] "Status summary compensation relationship 400" specifically refers to the relationship of determining the compensation object based on the hit relationship between the summary identifier and the confirmed summary result in the cloud after the cloud-edge collaborative recovery.

[0032] The "idempotent compensation synchronization 500" specifically refers to the synchronization process of performing compensation writing on unconfirmed compensation segments and suppressing duplicate writing on confirmed compensation segments.

[0033] Example 1, referring to Figure 1 This invention provides a method for offline synchronization and self-healing of heterogeneous energy edge nodes, illustrating the overall operation process before cloud-edge collaboration is interrupted, during disconnection, and after cloud-edge recovery. This embodiment addresses the problems of edge nodes lacking clear takeover criteria when the cloud is unreachable, difficulty in continuously inheriting offline business status, and difficulty in maintaining consistent cloud-edge status after recovery.

[0034] On the edge node overview interface 10 of the cloud platform, the platform displays operational information such as the total number of edge nodes, online nodes, offline nodes, alarm nodes, connected devices, and edge applications; the interface also displays the online trend of edge nodes in the past fourteen days, the distribution of device access protocols, and the status of nodes in each plant.

[0035] Online trends reflect changes in cloud-edge connectivity over time; device access protocol distribution reflects the access status of field devices to the platform via different industrial protocols; and the status of each plant node reflects whether different plant edge nodes are in a fully online, partially offline, alarmed, or fully offline state. Therefore, the cloud-edge collaborative status information 100 is not a single network connectivity result, but rather a combination of node online status, plant node status, edge application operation status, protocol access status, and cloud status confirmation.

[0036] In this embodiment, the state synchronization benchmark 200 is used to determine whether the edge node and the cloud still maintain state continuity. During the normal operation of the edge node, the cloud platform receives online confirmation, application operation confirmation, configuration effectiveness confirmation and device collection confirmation from the edge node, and associates and saves the above confirmation results with the most recent cloud state confirmation result.

[0037] The status synchronization baseline 200 can be stored in the cloud node management table or synchronously stored in the local status table of the edge node. Taking the edge node of the plant as an example, when a certain plant node changes from online to alarm or offline, the platform will not directly determine the business interruption based solely on the offline identifier. Instead, it will further read the latest cloud confirmation result of the edge node, the current application carrying status, and whether the local device data collection is still valid, and form the status synchronization baseline 200 accordingly.

[0038] Furthermore, when the state synchronization baseline 200 indicates that the cloud is temporarily unreachable, but the edge node still has the conditions to take over local services, the platform generates an offline takeover state 300 for the edge node. This offline takeover state 300 is not a synonym for "network disconnection," but rather indicates that the edge node continues to take over local services according to the takeover starting point.

[0039] Specifically, if an edge node does not receive new cloud status confirmation within a preset detection period, but can still obtain local device collection results with device source, collection time, and parsing results from the effective protocol configuration, the edge node enters offline takeover state 300.

[0040] Alternatively, the offline takeover status 300 can be represented by the edge node local running flag, the edge application takeover identifier, or the local status version record.

[0041] Furthermore, in offline takeover state 300, the edge node caches and receives the status changes and business execution results of heterogeneous energy devices, and generates an offline autonomous acceptance record 302 in combination with local autonomous rules. The edge node writes the device status, edge application execution results, local incremental time sequence, and autonomous execution results generated during the disconnection period into the local record, so that the device status and business execution results do not exist in the form of scattered logs. The local autonomous rules can come from edge application configuration, protocol configuration, device protection parameters, or business licensing policies. Taking the industrial data acquisition service, edge gateway service, and local artificial intelligence inference service in the edge application interface as examples, if the cloud is unreachable but the local acquisition link is still effective, the edge node continues to collect field device data and writes the acquisition results, gateway forwarding results, or local inference results into the offline autonomous acceptance record 302.

[0042] It should be noted that when the state synchronization benchmark 200 represents the cloud-edge collaborative recovery, the platform generates a state summary compensation relationship 400 based on the offline autonomous takeover record 302. The edge node divides the records formed during the offline period into comparable compensation objects and generates a summary identifier. The cloud compares the summary identifier with the cloud-confirmed summary results. Compensation objects that do not match are written for compensation, while compensation objects that match are prevented from being written repeatedly. After the compensation is written, the cloud state version and the edge node local state version form a continuous relationship based on the same takeover starting point. The platform determines the cloud state and the edge node state as a consistent cloud-edge offline self-healing state 600.

[0043] Example 2, based on Example 1, further defines the state synchronization benchmark 200 and the offline takeover conditions, solving the problems of inconsistent synchronization references, unclear takeover starting points, and difficulty in accurately determining the takeover object in multi-plant and multi-node group management scenarios. It achieves the technical effect of offline takeover judgment having node affiliation, application support, and cloud confirmation basis.

[0044] In the edge node group interface 20, the platform displays the node group status according to the plant or business domain. The interface can display the total number of edge node groups, all online groups, some offline groups, all offline groups, and the total number of edge nodes. The node group list includes multiple plant node groups, each with its own project, node status, running applications, tags, and status. Node groups can be displayed as all online, some offline, or all offline; the number of running applications indicates the number of edge applications carried within the node group; tags are used to identify the project affiliation, production type, or business type.

[0045] In this embodiment, the node grouping relationship is used to uniformly manage the edge nodes after they are included in the management system according to their respective business domains or plant areas. After the cloud platform manages the nodes, it binds the edge nodes to the corresponding projects, plants, or business domains and forms node group records in the node group interface. The node grouping relationship can be established according to the plant, or according to the energy business type, project space, or application deployment scope. Taking the whole plant node group as an example, the platform can include multiple power plant edge nodes in the same node group and uniformly display the node name, organization location, network address, and cloud-edge connection status through the node group details interface.

[0046] Furthermore, the synchronization anchor point 201 is used to fix the node grouping relationship, online confirmation result, application carrying result and the most recent cloud status confirmation result of the same edge node to the same status reference point.

[0047] Specifically, the node group details interface displays the node group identifier, display name, affiliated project, project space, number of nodes, number of online nodes, running application, node group tag, and a list of nodes within the group. Based on this information, the platform reads the online confirmation result and application carrying result of each edge node and binds the most recent cloud status confirmation result to the same edge node. Optionally, synchronization anchor 201 can be written to the cloud node management table or the edge node's local status table. Taking a plant edge node in an alarm state as an example, the platform still retains the node group to which the edge node belongs, the running application, the most recent cloud confirmation time, and the most recent cloud confirmation status version, using this as the starting point for subsequent takeover.

[0048] Furthermore, the fact that the local device acquisition results remain valid means that the edge node can still receive device data from the already effective protocol configuration within the preset detection period, and the received data has the device source, acquisition time, protocol parsing results, and continuous acquisition relationship.

[0049] If the edge node can read the status of the field device through the message queue telemetry transmission protocol, industrial bus protocol or unified architecture industrial communication protocol, and there are no parsing failures, time breaks or missing device sources in the collected data, the platform determines that the local device collection results are still valid. The validity judgment can be determined by the collection service heartbeat, protocol connection status, data parsing status or collection time continuity.

[0050] It should be noted that the offline takeover conditions are jointly defined by offline license verification 202 and device security boundary verification 203. Offline license verification 202 is used to determine whether the services carried by the candidate takeover node are allowed to continue operating during periods when the cloud is unreachable. The platform can determine whether a service is allowed to execute offline based on the application category, running status, deployment node range, application tag, and configuration source in the edge application interface. For example, industrial data acquisition services, edge gateway services, or local inference services can be configured to allow offline takeover, while services involving high-risk remote control can be configured to await cloud confirmation. Device security boundary verification 203 is used to determine whether the current status of the field equipment is within the range that allows autonomous takeover. The platform can determine the device security boundary based on the device alarm status, protection status, protocol connection status, data collection range, and edge configuration validity. The platform only determines the candidate takeover node as the target takeover node when the candidate takeover node passes both offline license verification 202 and device security boundary verification 203.

[0051] Example 3, based on Example 2, further defines the local cache segment 301 to solve the problem of scattered records of device status, business execution results and local time sequence from the moment of network outage to the time of cloud edge recovery, achieving the technical effect of continuous tracing of local business status along the takeover starting point during offline period.

[0052] In the edge application interface 30, the platform displays the total number of applications, the number of edge applications, the number of gateway services, and the number of data services, and lists applications such as industrial data acquisition services, edge gateway services, and local artificial intelligence inference services. The application list displays the application name, project to which it belongs, application category, image version, deployment progress, status, and operation entry point. The application details interface further displays the application name, project to which it belongs, application node, image, access protocol, target node, and running nodes. Through the above interfaces, the platform can determine which applications a given edge node actually supports before offline takeover, and which applications are already running.

[0053] In this embodiment, the local cache segment 301 is used to inherit the local business state formed by the target takeover node during the offline takeover. Specifically, after the target takeover node enters the offline takeover state 300, the local cache segment 301 is established with the takeover start point as the first state node. The takeover start point is derived from the most recent cloud state confirmation result in the synchronization anchor point 201, so the local cache segment 301 is continuously appended starting from the state already confirmed in the cloud. Optionally, the local cache segment 301 can be located in the edge node's local database, edge application cache directory, lightweight message queue, or log-type storage file. Taking the industrial data acquisition service as an example, if the service has been deployed on the target takeover node and is running, the acquisition service continues to receive field equipment data and write it to the local cache segment 301 after the cloud becomes unreachable.

[0054] Furthermore, the local incrementing sequence is used to represent the order of each state node during the disconnection period. Each time the target takeover node receives device status data or forms a service execution result, it assigns a local incrementing sequence to the corresponding state node, so that the state nodes in the local cache segment 301 can be arranged according to the local execution order. The local incrementing sequence can be an incrementing sequence number, a monotonic timestamp, a local logical clock, or a cache offset position. Taking the edge gateway service as an example, when the edge node completes multiple protocol conversions and local forwardings in sequence during the offline period, each forwarding result is written to the local cache segment 301 according to the local incrementing sequence, instead of overwriting the previous state.

[0055] Version association is used to ensure a traceable relationship between the local cache segment 301 and the cloud-confirmed status. Specifically, the local cache segment 301 always retains the cloud-confirmed status corresponding to the takeover starting point during the writing process, so that the cloud can identify which offline takeover process the local cache segment 301 belongs to after the network is restored. Version association can be saved through cache segment header fields, status node version fields, application running records, or summary input fields. Taking an edge node in an alarm state in the node group details interface as an example, if the edge node enters offline takeover from the most recent cloud confirmation result, the subsequent device status data and business execution results in the local cache segment 301 will be associated with the takeover starting point.

[0056] It should be noted that the local cache segment 301 also determines the write scope based on the deployment status of the edge applications. For data acquisition services and edge gateway services that are in a partially deployed state, the target takeover node only records the data and execution results generated by applications that are already running locally. For fully running local inference services, the target takeover node records the inference input status, inference output results, and the corresponding local incrementing time sequence. Thus, the local cache segment 301 can reflect the actual operation process of different edge applications during offline periods.

[0057] Example 4, based on Example 3, further limits the offline autonomous undertaking record 302, and solves the problems that the local cache state and autonomous execution result cannot be bound during offline and the autonomous execution scope of edge nodes is unclear, so as to achieve the technical effect that offline autonomous behavior can be saved according to the preset autonomous boundary constraints and corresponding to the cache state.

[0058] The edge configuration interface displays configuration types such as gateway configuration, protocol configuration, application configuration, and certificate configuration. The configuration list also includes data acquisition message queue configuration, industrial unified architecture protocol acquisition configuration, industrial bus example configuration, and message relay configuration. Each configuration item has a configuration name, type, belonging project, data file, referenced application, update time, and operation entry point. The platform manages the required configuration files on the edge side through the edge configuration interface, and these configuration files are referenced by data services, gateway services, or edge applications.

[0059] In this embodiment, a pre-defined autonomous boundary is used to limit whether the target takeover node is allowed to continue executing local services when it is unreachable from the cloud. The pre-defined autonomous boundary can be formed by the protocol connection status, configuration effectiveness status, device collection range, device alarm status, protection status, and service licensing policy. Optionally, the pre-defined autonomous boundary can be derived from protocol configuration, gateway configuration, edge application configuration, or device protection parameters. Taking the data collection message queue configuration as an example, the configuration details interface can display the server address, port, client identifier, authentication information, topic, keep-alive time, and reconnection interval. If the edge node can still maintain the local collection link according to this configuration during offline periods, and the collected data does not trigger device alarms, the target takeover node can determine that the current device status meets the pre-defined autonomous boundary.

[0060] Furthermore, the autonomous execution strategy is used to determine the execution method adopted by the target takeover node for local services when the preset autonomous boundaries are met. Specifically, when the current device state meets the preset autonomous boundaries, the target takeover node continues to execute the corresponding edge application or gateway service; when the current device state does not meet the preset autonomous boundaries, the target takeover node can suspend high-risk control, retain only the cache, or mark the corresponding state node as pending cloud confirmation. Optionally, the autonomous execution strategy may include continuing data collection, continuing protocol conversion, continuing local inference, suspending control actions, caching only without execution, or pending cloud confirmation. Taking local AI inference service as an example, if the inference input data is continuous and the device state does not exceed the security boundary, the edge node continues to output the local inference result; if the device state enters the alarm range, the edge node marks the corresponding inference result as pending confirmation.

[0061] Furthermore, the offline autonomous takeover record 302 is used to simultaneously store the cached state and the autonomous execution result. Specifically, the target takeover node binds the execution result corresponding to the autonomous execution strategy to the corresponding state node in the local cache segment 301, so that the same record can reflect the takeover start point, local incrementing time sequence, current device state, autonomous execution strategy, and execution result. Optionally, the binding method can use the state node identifier, cache segment offset position, local incrementing time sequence, or summary pre-field. Taking industrial data acquisition service as an example, if the device state corresponding to a certain state node meets the preset autonomous boundary, the edge node continues to collect data and form a collection result, which is bound to the corresponding state node; if the device state corresponding to another state node does not meet the preset autonomous boundary, the edge node generates a confirmation flag and binds it to the corresponding state node.

[0062] The offline autonomous takeover record 302 can also store edge configuration references. Specifically, the target takeover node can record the data acquisition configuration, gateway configuration, or protocol configuration referenced for a certain autonomous execution result, enabling the cloud to confirm whether the autonomous execution during the offline period was based on the effective configuration after the network is restored. Thus, the offline autonomous takeover record 302 not only represents the execution result, but also the configuration source and state source of the execution result.

[0063] Example 5, based on Example 4, further defines the state summary compensation relationship 400 and the idempotent compensation synchronization 500, which solves the problems of difficult compensation positioning, repeated writing and state version conflict when there are many offline records after network recovery. It achieves the technical effect of continuous calibration of cloud state and edge node state based on the same synchronization anchor point 201 after recovery.

[0064] In the configuration details interface, the platform can display the configuration name, type, project to which it belongs, project space, creation time, update time, referenced application, description, tags, and configuration data of the data collection configuration. The configuration data may include server address, port, client identifier, authentication information, topic, keep-alive time, reconnection interval, etc. The above configuration indicates that edge nodes may continue to generate a large amount of device status data and business execution results during offline periods. Therefore, after cloud-edge recovery, it is necessary to locate the offline records that need to be compensated through a summary method.

[0065] In this embodiment, compensation segments are used to divide the offline autonomous takeover record 302 into compensation objects that can be confirmed segment by segment in the cloud. Specifically, when the state synchronization benchmark 200 represents the cloud-edge collaborative recovery, the platform divides the offline autonomous takeover record 302 according to the synchronization anchor point 201 and the local incremental time sequence. Each compensation segment corresponds to a continuous offline record under the same takeover starting point. Optionally, compensation segments can be divided according to a fixed number of records, a fixed time window, application execution boundaries, or cache file size. Taking industrial data acquisition services as an example, if edge nodes continuously generate acquisition results during offline periods, the platform can form compensation segments according to the acquisition time window; taking edge gateway services as an example, the platform can form compensation segments according to forwarding batches.

[0066] Furthermore, the digest identifier is used to represent the content characteristics of the compensation fragment. Specifically, the digest identifier is generated based at least on the edge node identifier, status version, local incrementing time sequence, and service execution result. The edge node identifier is used to determine the source of the compensation fragment, the status version is used to determine the takeover process to which the compensation fragment belongs, the local incrementing time sequence is used to determine the location of the compensation fragment during offline periods, and the service execution result is used to reflect the service content of the compensation fragment. Optionally, the digest identifier can be generated using a message digest algorithm, hash algorithm, or verification algorithm, such as MD5, SHA, CRC, or other digest algorithms. The algorithm type of the digest identifier is not limited, as long as it can generate a digest result for comparison.

[0067] Furthermore, the cloud-confirmed summary results are used to maintain the summary identifiers that have been successfully received and confirmed by the cloud. Specifically, after each compensation fragment is successfully written, the cloud writes the corresponding summary identifier into the cloud-confirmed summary results; when the edge node reports the same summary identifier again, the cloud can recognize that the compensation fragment has been confirmed. Optionally, the cloud-confirmed summary results can be stored in the cloud status confirmation table, summary index table, or compensation task table. Through this maintenance process, the summary hit comparison forms a closed loop, which can not only determine whether the current compensation object needs to be written, but also provide a basis for subsequent duplicate reporting suppression.

[0068] It should be noted that the idempotent compensation synchronization 500 is used to ensure that when the same compensation segment is reported multiple times, only one valid write is formed in the cloud. The cloud performs compensation write for compensation segments whose digest identifier does not match the cloud-confirmed digest result, and forms a cloud-confirmed status after successful write. The cloud suppresses duplicate writes for compensation segments whose digest identifier has already matched, and does not trigger status entry or business execution again. After the compensation write is completed, the cloud performs continuity calibration on the cloud status version and the local status version of the target takeover node based on the same synchronization anchor 201. If the cloud status version has covered the local incremental timing that needs to be compensated during offline, and forms a continuous relationship with the local status version of the target takeover node based on the same synchronization anchor 201, then the platform determines the cloud status and the target takeover node status as a cloud-edge offline self-healing consistent state 600.

[0069] Example 6, refer to Figure 2 As an embodiment of the present invention, a heterogeneous energy edge offline synchronous self-healing system is provided, including a synchronous takeover module 01, an autonomous undertaking module 02, and a summary self-healing module 03.

[0070] The synchronization takeover module is used to form a state synchronization benchmark 200 for edge nodes based on cloud-edge collaborative state information 100, and to generate an offline takeover state 300 for edge nodes when the state synchronization benchmark 200 meets the offline takeover conditions.

[0071] The autonomous takeover module is used to establish a local cache segment 301 based on the offline takeover status 300, cache and take over the status changes of heterogeneous energy devices and business execution results, and generate an offline autonomous takeover record 302 in combination with local autonomous rules.

[0072] The summary self-healing module is used to generate a state summary compensation relationship 400 based on the offline autonomous acceptance record 302, and to perform idempotent compensation synchronization 500 according to the state summary compensation relationship 400 to generate a cloud-edge offline self-healing consistent state 600.

[0073] This embodiment also provides a computer device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements a heterogeneous energy edge offline synchronous self-healing method as proposed in the above embodiment.

[0074] This embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a heterogeneous energy edge offline synchronous self-healing method as proposed in the above embodiment.

[0075] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0076] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0077] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0078] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0079] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A heterogeneous energy edge offline synchronous self-healing method, characterized in that, include: Obtain cloud-edge collaborative status information in heterogeneous energy IoT network (100) and form a status synchronization benchmark for edge nodes (200). When the state synchronization benchmark (200) meets the offline takeover conditions, the state changes and business execution results of heterogeneous energy devices are cached and taken over, and an offline autonomous takeover record (302) is generated in combination with the local autonomous rules of the edge node. When the state synchronization benchmark (200) characterizes cloud-edge collaborative recovery, a state summary compensation relationship (400) is generated based on the offline autonomous acceptance record (302). Based on the state summary compensation relationship (400), idempotent compensation synchronization (500) is performed on the cloud state and edge node state to generate a cloud-edge offline self-healing consistent state (600).

2. The heterogeneous energy edge offline synchronous self-healing method as described in claim 1, characterized in that: The state synchronization reference (200) includes, After being managed, the edge nodes are grouped according to their respective business domains, and the online confirmation result, application bearing result and the most recent cloud status confirmation result of the same edge node in the node grouping relationship are bound as synchronization anchors (201) to form a synchronization benchmark record that can be used to determine whether the cloud edge status is continuous. The synchronization anchor (201) represents at least the most recent cloud-based status confirmation result in the status synchronization benchmark (200).

3. The heterogeneous energy edge offline synchronous self-healing method as described in claim 1 or 2, characterized in that: When determining the offline takeover conditions, the most recent cloud status confirmation result in the synchronization anchor point (201) is used as the takeover starting point. When the edge node does not obtain cloud status confirmation within the preset detection period and the local device collection result remains valid, the corresponding edge node is determined as a candidate takeover node. Offline license verification (202) and device security boundary verification (203) are performed on the services carried by the candidate takeover node. The candidate takeover node that passes both the offline license verification (202) and device security boundary verification (203) is determined as the target takeover node.

4. The heterogeneous energy edge offline synchronous self-healing method as described in claim 3, characterized in that: When the target takeover node enters the offline takeover state (300), a local cache segment (301) is established with the takeover start point as the first state node, and the device status data, service execution results and local increment timing generated during the disconnection period are written into the local cache segment (301). The local cache segment (301) maintains version association with the synchronization anchor point (201) during the writing process, so that the local business state formed from the moment of network outage to the time before cloud edge recovery can be continuously traced according to the state source and execution sequence.

5. The heterogeneous energy edge offline synchronous self-healing method as described in claim 4, characterized in that: When generating the offline autonomous takeover record (302), the target takeover node matches the current device status in the local cache segment (301) with the preset autonomous boundary, and determines the autonomous execution strategy of the local service based on the matching result; When the current device state meets the preset autonomous boundary, the execution result corresponding to the autonomous execution strategy is bound to the corresponding state node in the local cache segment (301) to form an offline autonomous acceptance record (302) that simultaneously records the cache state and the autonomous execution result.

6. The heterogeneous energy edge offline synchronous self-healing method as described in claim 5, characterized in that: When generating the state summary compensation relationship (400), the offline autonomous acceptance record (302) is divided into compensation segments according to the synchronization anchor point (201) and the local incremental time sequence, and a summary identifier is generated for each compensation segment; The summary identifier is generated based at least on the edge node identifier, status version, local incremental timing and business execution result in the compensation segment, and the summary identifier is used to compare with the confirmed summary result in the cloud to determine the offline autonomous undertaking record (302) that needs to be compensated.

7. The heterogeneous energy edge offline synchronous self-healing method as described in claim 6, characterized in that: When performing the idempotent compensation synchronization (500), compensation write is performed on the compensation fragments for which the summary identifier does not hit the cloud-confirmed summary result, and duplicate write is suppressed on the compensation fragments for which the summary identifier has hit the cloud-confirmed summary result; When the cloud state version after compensation is written and the local state version of the target takeover node form a continuous relationship based on the same synchronization anchor point (201), the cloud state and the target takeover node state are determined to be a consistent cloud-edge offline self-healing state (600).

8. A heterogeneous energy edge offline synchronous self-healing system, employing the heterogeneous energy edge offline synchronous self-healing method as described in any one of claims 1 to 7, characterized in that: Includes a synchronous takeover module (01), an autonomous takeover module (02), and a summary self-healing module (03). The synchronization takeover module is used to form a state synchronization benchmark (200) for edge nodes based on cloud-edge collaborative state information (100), and to generate an offline takeover state (300) for edge nodes when the state synchronization benchmark (200) meets the offline takeover conditions. The autonomous takeover module is used to establish a local cache segment (301) based on the offline takeover status (300), cache and take over the status changes of heterogeneous energy devices and business execution results, and generate offline autonomous takeover records (302) in combination with local autonomous rules. The summary self-healing module is used to generate a state summary compensation relationship (400) based on the offline autonomous acceptance record (302), and perform idempotent compensation synchronization (500) according to the state summary compensation relationship (400) to generate a cloud-edge offline self-healing consistent state (600).

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the heterogeneous energy edge offline synchronous self-healing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the heterogeneous energy edge offline synchronous self-healing method according to any one of claims 1 to 7.

Images