Cloud edge collaboration-based electric energy meter intelligent management method and system and medium

Abstract

The application provides a cloud edge cooperation-based intelligent management method and system for electric energy meters and a medium, relates to the technical field of electric energy meter management, and comprises the following steps: sending version state information to the cloud through an edge node; constructing a version heterogeneous graph and calculating a version heterogeneity index; acquiring heterogeneous analysis processing capability information corresponding to a concurrent analysis task script based on the cloud, and acquiring a version heterogeneity threshold; judging whether a version convergence mechanism is triggered through comparison, and if the version convergence mechanism is triggered, performing iterative search according to a search algorithm to determine a set of edge nodes to be upgraded; and the cloud performs upgrade management by issuing a version convergence instruction to the set of edge nodes to be upgraded. The application solves the technical problems that the prior art usually adopts a fixed-period whole-network unified upgrade strategy, a large number of normally operating nodes are forced to participate in version switching, network communication load is further increased, the risk of edge service interruption is increased, and upgrade resources are wasted.

Description

Technical Field

[0001] This invention relates to the field of electricity meter management technology, specifically to a cloud-edge collaborative intelligent management method, system, and medium for electricity meters. Background Technology

[0002] With the development of the power Internet of Things and smart grids, large-scale electricity meter terminals are gradually adopting a cloud-edge collaborative approach for centralized management. The cloud is responsible for data parsing, task scheduling, strategy analysis, and model collaborative computation, while edge nodes are responsible for data acquisition, protocol conversion, local caching, and control execution of electricity meter terminals within their respective regions. Due to the large number of electricity meter terminals and their dispersed deployment areas, there are significant differences in network conditions, hardware resources, and business requirements in different regions. Therefore, it is difficult to maintain complete consistency in the software version of edge nodes over a long period of time.

[0003] Existing technologies typically employ a unified version mandatory upgrade or static compatibility management approach to control the version of edge nodes. However, this approach has significant shortcomings in scenarios with a large number of electricity meter terminals. Specifically, existing technologies often adopt a fixed-cycle unified upgrade strategy across the entire network, which leads to the cloud performing synchronous upgrades on all edge nodes without assessing the actual heterogeneous processing pressure. This results in a large number of normally operating nodes being forced to participate in version switching, further increasing network communication load, raising the risk of edge service interruption, and wasting upgrade resources. Summary of the Invention

[0004] This application provides a cloud-edge collaborative intelligent management method, system, and medium for electricity meters, aiming to solve the technical problems of existing technologies that typically adopt a fixed-cycle, unified upgrade strategy for the entire network, which forces a large number of normally operating nodes to participate in version switching, further leading to increased network communication load, increased risk of edge service interruption, and waste of upgrade resources.

[0005] The first aspect disclosed in this application provides a smart management method for electricity meters based on cloud-edge collaboration. The method includes: sending version status information to the cloud via an edge node, wherein the edge node is used to manage electricity meter terminals; constructing a version heterogeneity graph based on the version status information and calculating a version heterogeneity index of the version heterogeneity graph; obtaining heterogeneous parsing processing capability information of the cloud based on concurrent parsing task scripts, and obtaining a version heterogeneity threshold based on the heterogeneous parsing processing capability information; determining whether a version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index; if the version convergence mechanism is triggered, iteratively searching the version heterogeneity graph according to a search algorithm to determine a set of edge nodes to be upgraded that meet the version heterogeneity threshold; and the cloud performing upgrade management by issuing a version convergence command to the set of edge nodes to be upgraded.

[0006] The second aspect of this application discloses a cloud-edge collaborative smart management system for electricity meters. The system is used in the aforementioned cloud-edge collaborative smart management method for electricity meters. The system includes: a status information sending module for sending version status information to the cloud via edge nodes, wherein the edge nodes are used to manage electricity meter terminals; a heterogeneity index calculation module for constructing a version heterogeneity graph based on the version status information and calculating the version heterogeneity index of the version heterogeneity graph; a heterogeneity threshold acquisition module for acquiring heterogeneous parsing processing capability information of the cloud based on concurrent parsing task scripts, and acquiring a version heterogeneity threshold based on the heterogeneous parsing processing capability information; an iterative search module for determining whether a version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index; if the version convergence mechanism is triggered, iteratively searching the version heterogeneity graph according to a search algorithm to determine a set of edge nodes to be upgraded that meet the version heterogeneity threshold; and an upgrade management module for the cloud to perform upgrade management by issuing version convergence instructions to the set of edge nodes to be upgraded.

[0007] The third aspect disclosed in this application provides a storage medium on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the steps of the cloud-edge collaborative smart energy meter management method in the first aspect.

[0008] One or more technical solutions provided in this application have at least the following beneficial effects:

[0009] By sending version status information from edge nodes to the cloud, the cloud can monitor the version distribution of each edge node and electricity meter terminal in real time, providing basic data support for subsequent version heterogeneity analysis and unified management. By constructing a version heterogeneity map and calculating a version heterogeneity index, the degree of version heterogeneity in the current network can be quantified, enabling the cloud to accurately identify the heterogeneous relationships and complexity caused by multiple versions coexisting, thus improving version management capabilities for large-scale electricity meter networks. By acquiring information on the cloud's heterogeneity resolution and processing capabilities and dynamically generating version heterogeneity thresholds, the system can adaptively adjust the tolerable degree of version heterogeneity based on the cloud's current resolution capabilities, avoiding... This approach avoids resource waste or heterogeneous control issues caused by fixed thresholds. By comparing version heterogeneity thresholds with version heterogeneity indices, it dynamically determines whether to trigger the version convergence mechanism and determines the set of edge nodes to be upgraded through iterative search. This reduces the heterogeneous resolution pressure on the cloud, minimizes unnecessary network-wide upgrade operations, and improves version convergence efficiency and system stability. By issuing version convergence commands from the cloud to the edge nodes to be upgraded, it achieves unified upgrade management of edge nodes. Combined with differential upgrade and verification mechanisms, it reduces upgrade communication overhead, ensures the security and consistency of the upgrade process, and thus improves the overall operating efficiency of the cloud-edge collaborative smart energy meter management system.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the cloud-edge collaborative smart management method for electricity meters provided in the embodiments of this application.

[0012] Figure 2 This is a schematic diagram of the structure of a cloud-edge collaborative smart management system for electricity meters provided in an embodiment of this application.

[0013] Figure labeling: Status information sending module 10, heterogeneity index calculation module 20, heterogeneity threshold acquisition module 30, iterative search module 40, upgrade management module 50. Detailed Implementation

[0014] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0015] Example 1, as Figure 1 As shown in the embodiment of this application, a smart management method for electricity meters based on cloud-edge collaboration is provided, the method comprising: Version status information is sent to the cloud via edge nodes, whereby the edge nodes are used to manage electricity meter terminals.

[0016] Edge nodes are responsible for managing the electricity meter terminals under their jurisdiction and periodically or based on triggered events, sending their own version status information to the cloud. Version status information includes, but is not limited to, protocol version, data structure version, management model version, interpreter chain version, and semantic mapping rule version. After uniformly encoding this information, the edge nodes upload it to the cloud through a secure communication channel, achieving version information synchronization between the edge nodes and the cloud. This process ensures that the cloud can understand the version distribution of each edge node in the network in real time, providing an accurate data foundation for subsequent heterogeneous analysis.

[0017] Based on the version status information, a version heterogeneity graph is constructed, and the version heterogeneity index of the version heterogeneity graph is calculated.

[0018] After receiving version status information from edge nodes, the cloud extracts and vectorizes the heterogeneous features of each edge node to generate a node version feature vector. By calculating the difference between the feature vectors of any two edge nodes, the difference is used as an edge to connect the nodes, thus constructing a complete version heterogeneity graph. In this graph, each node represents an edge node, and each edge represents the degree of version heterogeneity between two nodes. By calculating the heterogeneity contribution of each node and weighting the contribution (the weights are configured according to the number of electricity meters managed by the node), a version heterogeneity index for the entire graph is obtained, thereby quantifying the overall version heterogeneity of the network.

[0019] Obtain heterogeneous parsing processing capability information corresponding to concurrent parsing task scripts in the cloud, and obtain the version heterogeneity threshold based on the heterogeneous parsing processing capability information.

[0020] Based on the execution status of the current concurrent parsing task scripts, the cloud obtains information about its own heterogeneous parsing processing capabilities, including interpreter call frequency, interpreter switching frequency, semantic conversion time, processor usage, model output latency, and data structure conversion failure rate. These load assessment metrics are input into a preset negative correlation mapping function, and a version heterogeneity threshold is calculated through exponential decay or other mathematical mapping methods. This threshold reflects the upper limit of network version heterogeneity that the cloud can withstand under the current load, providing a reference for triggering version convergence.

[0021] The version heterogeneity threshold and the version heterogeneity index are compared to determine whether the version convergence mechanism is triggered. If the version convergence mechanism is triggered, the version heterogeneity graph is iteratively searched according to the search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold.

[0022] The obtained version heterogeneity index is compared with the version heterogeneity threshold to calculate the heterogeneity deviation. When the heterogeneity deviation exceeds the safety threshold, a version convergence mechanism is triggered. The convergence mechanism iteratively searches the version heterogeneity graph using a search algorithm to determine the set of edge nodes that need to be upgraded. During the search, nodes with high marginal contribution can be prioritized, as upgrading these nodes can significantly reduce the version heterogeneity index. The search range is adjusted according to local or global strategies until the version heterogeneity index drops to within the threshold's allowable range, ultimately forming a set of edge nodes to be upgraded, providing a list for actual version upgrades.

[0023] The cloud platform manages upgrades by issuing version convergence commands to the set of edge nodes to be upgraded.

[0024] The cloud generates version convergence instructions for the set of edge nodes to be upgraded. Each instruction includes the target version number, the download path of the differential upgrade package, and the algorithm verification certificate. After receiving the instruction, the edge nodes first verify the integrity and correctness of the upgrade package using the algorithm verification certificate. Then, they read the differential upgrade package based on the download path and execute the version update operation, thus completing the version convergence for the managed electricity meter terminals.

[0025] Furthermore, the method for constructing a version heterogeneous graph based on the version status information also includes: The version status information includes protocol version information, data structure version information, model version information, interpreter chain version information, and semantic mapping rule version information. The cloud performs heterogeneous feature extraction on the version status information of each edge node to obtain a node heterogeneous feature set. After vectorizing and encoding the node heterogeneous feature set, the cloud outputs a node version feature vector. The cloud calculates the difference between the node version feature vectors of any two edge nodes to obtain the node heterogeneous difference. The edge nodes are connected by edges using the node heterogeneous difference as heterogeneous association edges to generate a version heterogeneous graph.

[0026] Protocol version information characterizes the type and version of the data communication protocol between edge nodes and electricity meter terminals; data structure version information describes the data field structure used by edge nodes when collecting, encapsulating, and uploading electricity meter data; model version information indicates the version of the data analysis model, anomaly identification model, or state prediction model currently running on the edge node; interpreter chain version information indicates the edge node's support for different scripts, rule engines, or parsing programs; and semantic mapping rule version information indicates the version of the mapping rules between different protocol fields and unified business semantics. The edge nodes encapsulate the above version status information and send it to the cloud, enabling the cloud to obtain the multi-dimensional heterogeneous version distribution across the entire electricity meter management network, providing a data foundation for subsequent version heterogeneity analysis and convergence control.

[0027] The cloud platform identifies protocol version differences, data structure differences, model compatibility, interpreter call compatibility, and semantic rule mapping features, and normalizes these different types of features. The acquired heterogeneous node feature set is then vectorized, mapping version features of different dimensions to a unified feature space to generate corresponding node version feature vectors. Each edge node i's version feature vector consists of 5 feature values, denoted as V. i =[v i,1 v i,2 v i,3 v i,4 v i,5 The definitions and quantification methods for each dimension are as follows: vi,1 For protocol version dimensions, the major version number is used as a scalar (e.g., v1.0 is denoted as 1.0, v2.3 as 2.3); v i,2 For data structure dimensions, structural complexity is indicated by symbols; for example, compact binary is 1, XML is 2, JSON is 3, and Protobuf is 4. i,3 For model versions, this corresponds to the version evolution code of the core smart energy meter algorithm (e.g., 1, 2, 3...); v i,4 For interpreter chain version dimensions, the cloud resolves the required dynamic link library / script chain index number (e.g., 101, 102...) for this node; v i,5 For the semantic mapping rule dimension, the hash / category code (e.g., 10, 20, 30...) of the semantic alignment dictionary is used. The node version feature vector is used to uniformly represent the current overall version state of the edge node, thereby enabling standardized heterogeneous difference analysis between different edge nodes. In this way, the originally discretized and multi-type version state information is transformed into a computable and comparable unified vector data structure, providing a foundation for subsequent graph construction.

[0028] The overall heterogeneity between two edge nodes is calculated by comparing their version feature vectors across dimensions such as protocol version, data structure, model version, interpreter chain, and semantic mapping rules. Specifically, version features of the two edge nodes are extracted across these dimensions, and the differences in each dimension are normalized and then weighted and summed. Since the parsing pressure on the cloud processor varies depending on the dimensions (for example, the conversion overhead of changing the data structure from binary to JSON is much greater than the overhead of fine-tuning the model version), a weight vector is introduced: W = [w1, w2, w3, w4, w5], satisfying... In this example, based on industry experience, the weights are set as: W=[0.25, 0.30, 0.10, 0.20, 0.15], where data structure w2=0.30 and protocol version w1=0.25 account for the majority, as they directly determine the computation cycle of cloud-based hard parsing. The overall heterogeneity difference D between the two edge nodes i and j is also significant. ij The weighted mixed distance formula is used for calculation. For continuous dimensions (such as version number), Euclidean distance difference is used, and for discrete / nominal dimensions (such as data structure type, solver chain index), dissimilarity indicator function is used.

[0029] Node heterogeneity dissimilarity reflects the version compatibility distance between two edge nodes. A higher value indicates a more significant version difference between the two edge nodes, resulting in higher heterogeneity adaptation costs for unified cloud resolution. Conversely, a lower value indicates higher version compatibility. By calculating the node heterogeneity dissimilarity between any two edge nodes in the network, a complete heterogeneous relationship between nodes is formed, providing a basis for subsequent construction of the version heterogeneous graph.

[0030] Each edge node serves as a graph node in the graph, and the heterogeneity difference between nodes is used as the weight of the corresponding heterogeneous association edge. When there is a version difference between two edge nodes, the cloud establishes a heterogeneous association edge between the corresponding nodes and uses the node heterogeneity difference as the edge weight parameter to represent the strength of the heterogeneous association between the two nodes. By connecting the edge nodes in the entire network, a version heterogeneous graph describing the heterogeneous relationship of the entire network is formed. In this version heterogeneous graph, the version clustering relationships formed in different regions, different business scenarios, or different operating environments can be intuitively represented, enabling the cloud to identify heterogeneous concentrated areas, highly heterogeneous nodes, and heterogeneous propagation paths. The version heterogeneous graph is not only used to reflect the current version distribution status in the network, but also for subsequent version heterogeneity index calculation, version convergence trigger judgment, and edge node search to be upgraded.

[0031] Furthermore, the method for calculating the version heterogeneity index of the version heterogeneity map includes: Obtain the number of electricity meter terminals connected to each edge node in the version heterogeneous graph, and configure the node heterogeneity contribution influence weight according to the number of electricity meter terminals; extract at least one heterogeneous association edge connected to each edge node in the version heterogeneous graph, and calculate the node heterogeneity contribution of each edge node according to the at least one heterogeneous association edge; obtain the version heterogeneity index according to the node heterogeneity contribution influence weight and the node heterogeneity contribution.

[0032] Because different edge nodes manage different scales of electricity meter terminals, even if two edge nodes have the same version heterogeneity, the heterogeneous resolution pressure they exert on the entire cloud-edge collaborative network will differ. Edge nodes managing a larger number of terminals will generate higher data interaction frequencies and heterogeneous processing requirements during protocol parsing, semantic mapping, interpreter calls, and model collaboration, thus causing a greater heterogeneous load impact on the cloud. Therefore, the cloud configures a node heterogeneity contribution weight for each edge node based on the number of electricity meter terminals connected to it, allowing the business scale factor of the edge node to participate in subsequent version heterogeneity calculations. This node heterogeneity contribution weight is positively correlated with the number of electricity meter terminals managed by the edge node, increasing the influence of high-load edge nodes in the overall heterogeneity assessment, thereby more accurately reflecting the heterogeneous load status in actual network operation. Specifically, let N be the number of electricity meter terminals managed by edge node i. i The total number of electricity meter terminals managed by all edge nodes in the heterogeneous graph is: Then the weight of the heterogeneous contribution of edge node i is: σ i =N i / N sum , where m is the total number of edge nodes in the version heterogeneous graph.

[0033] In a version heterogeneous graph, each edge node is connected to others via heterogeneous edges. The weight of each edge represents the degree of heterogeneity between two edge nodes. The cloud-based system obtains the version heterogeneity of a given edge node relative to the entire network by statistically analyzing all heterogeneous edges connected to it and their corresponding weights. Since an edge node may be associated with multiple edge nodes of different versions simultaneously, the more heterogeneous edges an edge node connects to and the larger their weights, the more types of data parsing, interpreter switching, and semantic mapping processes the edge node needs to participate in, and the more significant the load it places on the cloud-based heterogeneous parsing system. Specifically, the weights of all heterogeneous edges connected to the target edge node are weighted and aggregated to obtain the node heterogeneity contribution C of the corresponding edge node. i : , where k i D is the number of heterogeneous associated edges connected to edge node i. ij Let C be the node heterogeneity difference between edge node i and edge node j, and C be the node heterogeneity contribution. iThis represents the heterogeneous load contribution level of edge node i relative to the entire network. A higher heterogeneous contribution indicates more highly disparate version associations between the edge node and other edge nodes in the network, requiring it to participate in more types of data structure transformations, interpreter switching, and semantic mapping processes, thus causing a higher load impact on the cloud-based heterogeneous parsing system. Based on this, the cloud performs aggregate calculations on the overall heterogeneous impact of edge nodes according to at least one heterogeneous association edge connected to the edge node, obtaining the corresponding node heterogeneous contribution level. This node heterogeneous contribution level is used to characterize the heterogeneous load contribution level of a single edge node in the current cloud-edge collaborative network.

[0034] Global statistics are performed on each edge node in the version heterogeneity graph. The heterogeneity contribution of each edge node and its influence weight are fused and calculated to form the overall heterogeneous load aggregation result. Specifically, the heterogeneity contribution of each edge node and its influence weight are multiplied, and then globally accumulated or normalized to obtain the version heterogeneity index. The formula is as follows: Where H is the version heterogeneity index, σ i The weight of the contribution of heterogeneous nodes is C. i The version heterogeneity index represents the contribution of node heterogeneity. It characterizes the overall heterogeneous load caused by the coexistence of multiple versions in the current cloud-edge collaborative network, affecting cloud-based heterogeneous parsing, dynamic interpreter chain switching, semantic mapping, and AI model collaboration. A higher version heterogeneity index indicates that the cloud needs to simultaneously accommodate and process more heterogeneous versions, resulting in higher interpreter switching frequency, greater data structure conversion complexity, and greater semantic mapping pressure, thus increasing the resource consumption for heterogeneous parsing in the cloud.

[0035] Furthermore, the method for obtaining the version heterogeneity threshold based on the heterogeneous parsing processing capability information includes: The heterogeneous parsing processing capability information is subjected to load assessment to obtain cloud load assessment indicators. The heterogeneous parsing processing capability information includes interpreter call frequency, interpreter switching frequency, semantic conversion time, processor usage indicators, model output latency, and data structure conversion failure rate. The cloud load assessment indicators are input into a preset negative correlation mapping function to obtain the version heterogeneity threshold.

[0036] Interpreter call frequency and switching frequency reflect the cloud's pressure to switch between different versions of scripts or rules; semantic conversion time represents the time cost required to complete unified semantic mapping after data is uploaded from the edge node to the cloud; processor usage and model output latency reflect the cloud's resource consumption when executing the analysis model; and data structure conversion failure rate reflects the potential exception handling overhead caused by heterogeneous version compatibility. By weighting, normalizing, or aggregating these indicators, a comprehensive cloud load assessment indicator is obtained to reflect the heterogeneous processing pressure in the cloud under the current network.

[0037] The cloud load assessment metric is input into a pre-defined negative correlation mapping function. This function employs exponential decay or other negative correlation modeling methods. The input variable is the real-time cloud load assessment metric, and the output variable is the tolerable upper limit of version heterogeneity. The mapping function is designed to control this by setting a heterogeneity tolerance boundary and a sensitivity adjustment coefficient. When the cloud load increases, the threshold automatically decreases, thereby limiting the allowed version heterogeneity in the network; conversely, when the load is low, the threshold can be increased to allow more version heterogeneity. The final version heterogeneity threshold provides a quantitative reference for triggering subsequent version convergence mechanisms, enabling the cloud to dynamically adjust the version heterogeneity in the network while ensuring resolution performance.

[0038] Furthermore, the cloud load assessment metric is input into a preset negative correlation mapping function to obtain a version heterogeneity threshold. The method for obtaining the preset negative correlation mapping function includes: Define the heterogeneity tolerance boundary and sensitivity adjustment coefficient as control parameters of the exponential decay mapping function; let the input variable of the preset negative correlation mapping function be the cloud load evaluation index obtained in real time, and the output variable be the version heterogeneity threshold. Fit the exponential decay mapping function to obtain the preset negative correlation mapping function.

[0039] The heterogeneity tolerance boundary consists of two parts: the maximum heterogeneity tolerance boundary and the minimum heterogeneity tolerance boundary. The maximum heterogeneity tolerance boundary is a system constant, set based on historical experience or the maximum number of interpreter handles that can be supported in the cloud, and is used to represent the highest degree of version heterogeneity that the system can tolerate; the minimum heterogeneity tolerance boundary is also a system constant, close to 0, and is used to preserve the ability to coexist with a very small number of core custom versions.

[0040] The sensitivity adjustment coefficient is used to control the steepness of the exponential decay function, by setting a threshold value when the load reaches its maximum (e.g., x). load When =1), the threshold must be reduced to near the minimum, such as occupying 5% of the available range, to deduce the parameters of the exponential decay function. , approximately equal to 3. This parameter This determines the rate of load change and threshold decrease, ensuring that the system has strict restrictions on heterogeneous versions under high load conditions, while allowing moderate heterogeneity under low load conditions.

[0041] An exponential decay mapping function is fitted, where the input variable is the cloud load assessment metric X obtained from real-time evaluation. load Normalized to the [0,1] interval, this reflects the current utilization rate of heterogeneous resolution capabilities in the cloud; the output variable is the version heterogeneity threshold. This represents the maximum version heterogeneity that the cloud can tolerate under the current load. The mapping function is constructed using the negative exponential property of the natural constant e, forming a negative correlation: as the cloud load increases, the version heterogeneity threshold gradually decreases, thus achieving the function of dynamically adjusting the degree of version heterogeneity in the network.

[0042] Preferably, the exponential decay mapping function is expressed as: , This indicates the current cloud-tolerant threshold for version heterogeneity, which is dynamically adjusted according to load changes; This represents the minimum value of the version heterogeneity threshold, ensuring that a very small number of critical versions can coexist even under extremely high load. X represents the maximum value of the version heterogeneity threshold, indicating the maximum degree of version heterogeneity that the cloud can tolerate when idle or under low load; load This represents cloud load assessment metrics. This represents the sensitivity adjustment coefficient, which controls the rate at which the threshold decreases as the load increases. The larger the value, the faster the threshold decreases.

[0043] The working mechanism of this preset negative correlation mapping function is as follows: when X load Close to 0 (low load), exponential term ≈1, threshold ≈ Allows for heterogeneous higher versions to exist; when X load As the load increases, the exponential term decreases, and the threshold... Approaching It automatically tightens tolerable heterogeneity, avoiding excessive cloud load. This exponential decay characteristic ensures that the threshold changes smoothly and continuously with the load, avoiding large-scale version convergence operations caused by sudden threshold drops, thus making the convergence process smooth and stable.

[0044] Furthermore, the method for determining whether a version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index includes: Calculate the heterogeneity deviation of the version heterogeneity threshold and the version heterogeneity index; when the heterogeneity deviation is less than a preset safety threshold, the version convergence mechanism is not triggered; when the heterogeneity deviation is greater than or equal to the preset safety threshold and less than or equal to a preset convergence trigger threshold, a local version convergence mechanism is triggered, which is used to perform a local iterative search on the version heterogeneous subgraph in the version heterogeneity graph, wherein the version heterogeneous subgraph is composed of edge nodes whose node heterogeneity difference is greater than the mean node heterogeneity difference; when the heterogeneity deviation is greater than the preset convergence trigger threshold, a global version convergence mechanism is triggered, which is used to perform a global iterative search on the version heterogeneous subgraph in the version heterogeneity graph.

[0045] The version heterogeneity index is compared and analyzed with the version heterogeneity threshold. By calculating the difference, ratio, or normalized deviation between the two, the heterogeneity deviation degree is obtained. This degree reflects the extent to which the current network version heterogeneity deviates from the cloud's tolerable range. A larger heterogeneity deviation degree indicates that the degree of version heterogeneity in the current network is closer to or exceeds the cloud's heterogeneous resolution capacity limit, which may lead to an increase in interpreter switching frequency, increased semantic mapping time, and abnormal growth in resolution resource consumption.

[0046] When the heterogeneity deviation is less than a preset safety threshold, it is determined that the version heterogeneity in the current network is still within a stable range that the cloud can handle, and therefore the version convergence mechanism is not triggered. In this state, although there are multiple different versions in the network, since the current heterogeneous load has not yet put significant pressure on the cloud, different edge nodes are allowed to continue operating in their current version states. By setting a safety threshold, frequent version upgrades can be avoided under slight heterogeneous fluctuations, thereby reducing invalid upgrade operations, reducing the communication load on edge nodes, and preserving a certain degree of regional customized version coexistence capability, improving the overall operational flexibility of the system.

[0047] When the heterogeneity deviation is greater than or equal to a preset safety threshold and less than or equal to a preset convergence trigger threshold, the cloud triggers a local version convergence mechanism. In this state, it indicates that the current network heterogeneity has begun to affect the cloud's heterogeneous resolution capabilities, but has not yet reached the point where a unified convergence across the entire network is required. Therefore, version convergence is only performed on locally high heterogeneous regions. Specifically, firstly, edge nodes with a heterogeneity difference greater than the average heterogeneity difference in the version heterogeneity graph are identified, and a version heterogeneous subgraph is constructed based on these edge nodes. This subgraph represents local regions with a high degree of heterogeneity aggregation in the current network. A local iterative search is performed within this subgraph. By analyzing the heterogeneous association edges, edge weight changes, and node heterogeneity contribution between local nodes, edge nodes that can significantly reduce local heterogeneity load are prioritized as nodes to be upgraded. Through the local version convergence mechanism, targeted governance of locally high heterogeneous regions can be carried out without affecting the overall network version structure, thereby reducing the cloud's heterogeneous resolution pressure and reducing resource consumption caused by a full network upgrade.

[0048] When the heterogeneity deviation exceeds the preset convergence trigger threshold, it indicates that the version heterogeneity in the current network has exceeded the stable processing capacity of the cloud, triggering a global version convergence mechanism. In this state, the coexistence of multiple versions has led to frequent interpreter chain switching, a significant increase in semantic mapping complexity, and a decrease in model collaboration efficiency. Therefore, overall convergence control of the entire network's version structure is required. A global iterative search is performed based on the entire version heterogeneity graph to uniformly analyze the heterogeneous relationships between edge nodes across the entire network. Factors such as node heterogeneity contribution, node influence weight, and upgrade benefits are comprehensively considered to determine the set of edge nodes requiring version upgrades. During the global version convergence process, not only are locally highly heterogeneous areas processed, but also large-scale heterogeneous relationships formed across regions, protocols, and models are uniformly optimized to reduce the overall network heterogeneity load level, gradually lowering the version heterogeneity index to within the allowable range of the version heterogeneity threshold. Through the global version convergence mechanism, the stable parsing capability of the cloud-edge collaborative network can be quickly restored under high-load scenarios, avoiding parsing failures, model anomalies, or cloud resource congestion caused by uncontrolled heterogeneity.

[0049] Furthermore, the method involves iteratively searching the heterogeneous graph of the version using a search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold. Traverse the candidate edge nodes that are not the latest version in the version heterogeneity graph; calculate the marginal contribution of each candidate edge node, where the marginal contribution is the decrease in the version heterogeneity index after the node upgrade; after the first candidate edge node sorted according to the marginal contribution is placed into the set of edge nodes to be upgraded, recalculate the version heterogeneity index for the next iteration round; until the heterogeneity deviation from the version heterogeneity threshold is less than the preset safety threshold, determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold.

[0050] Identify edge nodes in the version heterogeneity graph that are not currently running the latest version, and designate them as candidate edge nodes. Since the latest version nodes usually already meet the current unified version strategy, they do not need to participate in subsequent convergence optimization, while the non-latest version nodes may become the main source of increased version heterogeneity load.

[0051] The network state changes of a candidate edge node after upgrading to the target version are simulated, and the heterogeneous graph, heterogeneous node association edges, and version heterogeneity index are recalculated after the upgrade. The version heterogeneity index before and after the upgrade is compared to obtain the reduction in heterogeneous load brought about by the node upgrade, and the reduction is defined as the marginal contribution of the candidate edge node. The larger the marginal contribution, the more significantly the edge node can reduce the number of interpreter chain switches, reduce semantic mapping complexity, and alleviate the heterogeneous parsing load in the cloud after the upgrade, and therefore the higher its version convergence benefit.

[0052] By calculating the marginal contribution of all candidate edge nodes, a version convergence priority ranking based on upgrade benefits is formed, thereby avoiding resource waste caused by indiscriminate full upgrades.

[0053] Candidate edge nodes are ranked based on their marginal contribution, and the first candidate edge node with the highest marginal contribution is selected to be added to the set of edge nodes to be upgraded. Once the first candidate edge node is determined, the network state after the node completes the version upgrade is simulated, and the corresponding version heterogeneity graph is reconstructed. The version heterogeneity index for the next iteration is then recalculated. Since the heterogeneous associations between a node and other edge nodes change after the upgrade, the original node heterogeneous contribution, heterogeneous association edge weights, and overall version heterogeneity index are all dynamically adjusted.

[0054] The marginal contribution of the remaining candidate edge nodes is recalculated based on the updated heterogeneous graph, and the next round of iterative search continues. In this way, the impact of each upgrade on the overall heterogeneous load can be dynamically evaluated, ensuring that the version convergence process always remains in the current optimal benefit state, thereby achieving incremental heterogeneous governance.

[0055] The iterative search and version heterogeneity index update process continues until the heterogeneity deviation between the current version heterogeneity index and the version heterogeneity threshold is less than a preset safety threshold. When the heterogeneity deviation drops to a safe range, it indicates that the current multi-version coexistence state in the network is within a heterogeneous load range that can be stably handled in the cloud, and therefore the current version convergence search process is terminated. At this point, all edge nodes added during the iteration process are identified as the set of edge nodes to be upgraded that meet the version heterogeneity threshold. This set of edge nodes to be upgraded not only effectively reduces the heterogeneous resolution load in the cloud, but also minimizes the number of upgrade nodes while ensuring system stability, thereby reducing the overall network upgrade cost, reducing communication resource consumption, and avoiding the impact of large-scale version switching on edge services.

[0056] Furthermore, the cloud performs upgrade management by issuing version convergence instructions to the set of edge nodes to be upgraded. The version convergence instruction corresponding to each edge node to be upgraded includes a target version number, a differential upgrade package download path, and an algorithm verification certificate. After passing the algorithm verification certificate, each edge node to be upgraded reads the target version number based on the differential upgrade package download path and performs a version update on the managed electricity meter terminal.

[0057] The cloud identifies a set of edge nodes to be upgraded and sends version convergence commands to these nodes via the network. Each edge node receives a version convergence command containing three key pieces of information: a target version number, specifying the standard version the edge node needs to upgrade to, ensuring version consistency across nodes in the cloud-edge collaborative network and reducing heterogeneous load; a differential upgrade package download path, providing the network path for edge nodes to access upgrade resources, allowing them to download incremental upgrade packages instead of full upgrade packages, thus saving bandwidth and storage resources; and an algorithm verification credential, used to verify the integrity and correctness of the downloaded upgrade package, ensuring that cloud-edge collaboration will not fail due to data corruption or version incompatibility during the upgrade process. By uniformly issuing version convergence commands with verification mechanisms, the cloud can centrally manage the edge node upgrade process, ensuring secure and efficient upgrade operations, and precisely controlling the version iteration order and strategy.

[0058] Upon receiving the version convergence command, each edge node to be upgraded first uses an algorithm to verify the integrity and correctness of the downloaded differential upgrade package. After successful verification, the edge node reads the upgrade package content through the provided download path and performs version updates on the managed electricity meter terminals according to the target version number in the command. During the version update, the edge node ensures that the upgrade operation is completed synchronously with the electricity meter terminals it manages, maintaining consistency in terminal data acquisition, control logic, and communication protocols. Through differential upgrades and algorithm verification, the upgrade process ensures version uniformity while minimizing the impact on network bandwidth and terminal operation, thereby achieving efficient and controllable edge node version convergence management.

[0059] Example 2 is based on the same inventive concept as the cloud-edge collaborative smart energy meter management method in the previous examples, such as... Figure 2 As shown in the figure, this application provides a cloud-edge collaborative smart management system for electricity meters, the system comprising: The status information sending module 10 is used to send version status information to the cloud through edge nodes, wherein the edge nodes are used to manage electricity meter terminals; the heterogeneity index calculation module 20 is used to construct a version heterogeneity graph based on the version status information and calculate the version heterogeneity index of the version heterogeneity graph; the heterogeneity threshold acquisition module 30 is used to acquire heterogeneous parsing processing capability information corresponding to the concurrent parsing task script in the cloud, and acquire the version heterogeneity threshold according to the heterogeneous parsing processing capability information; the iterative search module 40 is used to determine whether the version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index. If the version convergence mechanism is triggered, the version heterogeneity graph is iteratively searched according to the search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold; the upgrade management module 50 is used by the cloud to perform upgrade management by issuing version convergence instructions to the set of edge nodes to be upgraded.

[0060] Furthermore, the heterogeneity index calculation module 20 is used to perform the following operation steps: The version status information includes protocol version information, data structure version information, model version information, interpreter chain version information, and semantic mapping rule version information. The cloud performs heterogeneous feature extraction on the version status information of each edge node to obtain a node heterogeneous feature set. After vectorizing and encoding the node heterogeneous feature set, the cloud outputs a node version feature vector. The cloud calculates the difference between the node version feature vectors of any two edge nodes to obtain the node heterogeneous difference. The edge nodes are connected by edges using the node heterogeneous difference as heterogeneous association edges to generate a version heterogeneous graph.

[0061] Furthermore, the heterogeneity index calculation module 20 is used to perform the following operation steps: Obtain the number of electricity meter terminals connected to each edge node in the version heterogeneous graph, and configure the node heterogeneity contribution influence weight according to the number of electricity meter terminals; extract at least one heterogeneous association edge connected to each edge node in the version heterogeneous graph, and calculate the node heterogeneity contribution of each edge node according to the at least one heterogeneous association edge; obtain the version heterogeneity index according to the node heterogeneity contribution influence weight and the node heterogeneity contribution.

[0062] Furthermore, the heterogeneous threshold acquisition module 30 is used to perform the following operation steps: The heterogeneous parsing processing capability information is subjected to load assessment to obtain cloud load assessment indicators. The heterogeneous parsing processing capability information includes interpreter call frequency, interpreter switching frequency, semantic conversion time, processor usage indicators, model output latency, and data structure conversion failure rate. The cloud load assessment indicators are input into a preset negative correlation mapping function to obtain the version heterogeneity threshold.

[0063] Furthermore, the heterogeneous threshold acquisition module 30 is used to perform the following operation steps: Define the heterogeneity tolerance boundary and sensitivity adjustment coefficient as control parameters of the exponential decay mapping function; let the input variable of the preset negative correlation mapping function be the cloud load evaluation index obtained in real time, and the output variable be the version heterogeneity threshold. Fit the exponential decay mapping function to obtain the preset negative correlation mapping function.

[0064] Furthermore, the iterative search module 40 is used to perform the following operation steps: Calculate the heterogeneity deviation of the version heterogeneity threshold and the version heterogeneity index; when the heterogeneity deviation is less than a preset safety threshold, the version convergence mechanism is not triggered; when the heterogeneity deviation is greater than or equal to the preset safety threshold and less than or equal to a preset convergence trigger threshold, a local version convergence mechanism is triggered, which is used to perform a local iterative search on the version heterogeneous subgraph in the version heterogeneity graph, wherein the version heterogeneous subgraph is composed of edge nodes whose node heterogeneity difference is greater than the mean node heterogeneity difference; when the heterogeneity deviation is greater than the preset convergence trigger threshold, a global version convergence mechanism is triggered, which is used to perform a global iterative search on the version heterogeneous subgraph in the version heterogeneity graph.

[0065] Furthermore, the iterative search module 40 is used to perform the following operation steps: Traverse the candidate edge nodes that are not the latest version in the version heterogeneity graph; calculate the marginal contribution of each candidate edge node, where the marginal contribution is the decrease in the version heterogeneity index after the node upgrade; after the first candidate edge node sorted according to the marginal contribution is placed into the set of edge nodes to be upgraded, recalculate the version heterogeneity index for the next iteration round; until the heterogeneity deviation from the version heterogeneity threshold is less than the preset safety threshold, determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold.

[0066] Furthermore, the cloud performs upgrade management by issuing version convergence instructions to the set of edge nodes to be upgraded. The version convergence instruction corresponding to each edge node to be upgraded includes a target version number, a differential upgrade package download path, and an algorithm verification certificate. After passing the algorithm verification certificate, each edge node to be upgraded reads the target version number based on the differential upgrade package download path and performs a version update on the managed electricity meter terminal.

[0067] Through the foregoing detailed description of the cloud-edge collaborative smart meter management method, those skilled in the art can clearly understand the cloud-edge collaborative smart meter management system in this embodiment. Since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and relevant parts can be referred to the method section.

[0068] Example 3 provides a storage medium on which a computer program is stored, which, when executed by a processor, implements any step of Example 1.

[0069] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A smart management method for electricity meters based on cloud-edge collaboration, characterized in that, The method includes: Version status information is sent to the cloud via edge nodes, wherein the edge nodes are used to manage electricity meter terminals; Based on the version status information, a version heterogeneity graph is constructed, and the version heterogeneity index of the version heterogeneity graph is calculated. Obtain heterogeneous parsing processing capability information corresponding to concurrent parsing task scripts in the cloud, and obtain the version heterogeneity threshold based on the heterogeneous parsing processing capability information; Whether the version convergence mechanism is triggered is determined by comparing the version heterogeneity threshold and the version heterogeneity index. If the version convergence mechanism is triggered, the version heterogeneity graph is iteratively searched according to the search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold. The cloud platform manages upgrades by issuing version convergence commands to the set of edge nodes to be upgraded. The method for constructing a version heterogeneous graph based on the version status information further includes: The version status information includes protocol version information, data structure version information, model version information, interpreter chain version information, and semantic mapping rule version information; The cloud performs heterogeneous feature extraction on the version status information of each edge node to obtain a node heterogeneous feature set, and outputs the node version feature vector after vectorizing the node heterogeneous feature set. The cloud platform obtains the heterogeneity degree of nodes by calculating the difference between the node version feature vectors of any two edge nodes. The edge nodes are connected by using the node heterogeneity difference degree as the heterogeneous association edge to generate a version heterogeneous graph. The method for calculating the version heterogeneity index of the version heterogeneity map includes: Obtain the number of electricity meter terminals connected to each edge node in the heterogeneous graph, and configure the node heterogeneous contribution influence weight according to the number of electricity meter terminals; Extract at least one heterogeneous association edge connecting each edge node in the heterogeneous graph of the version, and calculate the node heterogeneous contribution of each edge node based on the at least one heterogeneous association edge; Based on the influence weight of node heterogeneity contribution and node heterogeneity contribution, obtain the version heterogeneity index; The method for determining whether a version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index includes: Calculate the heterogeneity deviation of the version heterogeneity threshold and the version heterogeneity index; When the heterogeneity deviation is less than a preset safety threshold, the version convergence mechanism is not triggered; When the heterogeneity deviation is greater than or equal to the preset safety threshold and less than or equal to the preset convergence trigger threshold, a local version convergence mechanism is triggered. The local version convergence mechanism is used to perform local iterative search on the version heterogeneous subgraph in the version heterogeneous graph. The version heterogeneous subgraph is composed of edge nodes whose node heterogeneity difference is greater than the average node heterogeneity difference. When the heterogeneity deviation is greater than the preset convergence trigger threshold, a global version convergence mechanism is triggered. The global version convergence mechanism is used to perform a global iterative search on the version heterogeneous subgraphs in the version heterogeneous graph.

2. The intelligent management method for electricity meters based on cloud-edge collaboration as described in claim 1, characterized in that, The method for obtaining the version heterogeneity threshold based on the heterogeneous parsing processing capability information includes: The heterogeneous parsing processing capability information is subjected to load assessment to obtain cloud load assessment indicators. The heterogeneous parsing processing capability information includes interpreter call frequency, interpreter switching frequency, semantic conversion time, processor usage indicators, model output latency, and data structure conversion failure rate. The cloud load assessment metric is input into a preset negative correlation mapping function to obtain the version heterogeneity threshold.

3. The intelligent management method for electricity meters based on cloud-edge collaboration as described in claim 2, characterized in that, The cloud load assessment metric is input into a preset negative correlation mapping function to obtain the version heterogeneity threshold. The method for obtaining the preset negative correlation mapping function includes: The heterogeneity tolerance boundary and sensitivity adjustment coefficient are defined as control parameters of the exponential decay mapping function; Let the input variable of the preset negative correlation mapping function be the cloud load assessment index obtained in real time, and the output variable be the version heterogeneity threshold. Then, the preset negative correlation mapping function is obtained by fitting the exponential decay mapping function.

4. The intelligent management method for electricity meters based on cloud-edge collaboration as described in claim 1, characterized in that, The method involves iteratively searching the heterogeneous graph of the version using a search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold. Traverse the candidate edge nodes of the non-latest version in the heterogeneous graph of the stated version; For each of the candidate edge nodes, calculate the marginal contribution, which is the decrease in the heterogeneity index of the node after the upgrade. After the first candidate edge node, sorted according to the marginal contribution, is placed into the set of edge nodes to be upgraded, the version heterogeneity index for the next iteration round is recalculated. Until the heterogeneity deviation from the version heterogeneity threshold is less than a preset safety threshold, a set of edge nodes to be upgraded that meet the version heterogeneity threshold is determined.

5. The intelligent management method for electricity meters based on cloud-edge collaboration as described in claim 1, characterized in that, The cloud performs upgrade management by issuing version convergence instructions to the set of edge nodes to be upgraded. The version convergence instruction corresponding to each edge node to be upgraded includes the target version number, the differential upgrade package download path and the algorithm verification certificate. After verifying the credentials through the algorithm, each edge node to be upgraded reads the target version number based on the differential upgrade package download path and performs a version update on the managed electricity meter terminals.

6. A smart management system for electricity meters based on cloud-edge collaboration, characterized in that: The system is used to implement the cloud-edge collaborative smart energy meter management method according to any one of claims 1-5, the system comprising: The status information sending module is used to send version status information to the cloud through the edge node, wherein the edge node is used to manage the electricity meter terminal; The heterogeneity index calculation module is used to construct a version heterogeneity map based on the version status information and calculate the version heterogeneity index of the version heterogeneity map. The heterogeneity threshold acquisition module is used to acquire heterogeneous parsing processing capability information based on concurrent parsing task scripts in the cloud, and to acquire the version heterogeneity threshold based on the heterogeneous parsing processing capability information. The iterative search module is used to determine whether the version convergence mechanism is triggered by comparing the version heterogeneity threshold and the version heterogeneity index. If the version convergence mechanism is triggered, the version heterogeneity graph is iteratively searched according to the search algorithm to determine the set of edge nodes to be upgraded that meet the version heterogeneity threshold. The upgrade management module is used by the cloud to manage upgrades by issuing version convergence instructions to the set of edge nodes to be upgraded.

7. A 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 smart energy meter management method based on cloud-edge collaboration as described in any one of claims 1 to 5.

Images