Energy self-control platform multi-source data fusion and collaborative control method and system

Abstract

The present application belongs to the technical field of multi-source data fusion and collaborative control method, in particular to a multi-source data fusion and collaborative control method and system for an energy self-control platform, a dynamic semantic self-alignment engine is constructed, physical quantity unit conversion, definition normalization and automatic point mapping are realized through NLP and deep learning, user-defined rule completion and deviation correction are supported; a topological automatic identification algorithm is developed, a physical correlation graph is constructed based on edge side multi-dimensional information and GNN, automatic binding of measuring points-topological nodes and CAD drawing import initialization are realized; a three-layer ontology modeling framework is built, through modular protocol adaptation, semantic normalization and topological correlation, device constraints and characteristics are embedded, and an energy ontology model with topological attribution and physical properties is constructed.

Description

Technical Field

[0001] This invention belongs to the technical field of multi-source data fusion and collaborative control methods, and particularly relates to a multi-source data fusion and collaborative control method and system for energy self-control platforms. Background Technology

[0002] Current energy automation systems encompass devices across multiple scenarios, including power distribution, power consumption, and energy storage / photovoltaics. They involve various heterogeneous communication protocols such as Modbus, OPCUA, and BACnet. Significant differences exist in the names, units, and definitions of physical quantities across different manufacturers' devices, leading to chaotic multi-source data formats and semantic heterogeneity, making standardized integration difficult. Traditional data processing methods rely on manual configuration of mapping rules, which is not only inefficient but also prone to human error. Furthermore, the conversion of physical quantity units and the normalization of definitions lack automated mechanisms, and the association and binding of measurement points and topology nodes must be done manually. This fails to adapt to the dynamic changes in system equipment additions and removals, and topology modifications, severely restricting the timeliness and accuracy of data fusion.

[0003] Existing energy ontology models primarily focus on physical attribute descriptions, lacking deep embedding of topological attribution information, equipment physical constraints, and operational characteristics. Furthermore, they fail to effectively integrate multimodal data such as operation and maintenance logs and fault codes, resulting in insufficient model practicality. Simultaneously, the edge-cloud collaboration mechanism is imperfect, with coarse-grained data synchronization and high latency. The lack of unified standards for version management of semantic rules and algorithm models leads to conflicts, and edge-side model deployment faces issues such as large size and resource-intensive inference, making it difficult to meet the requirements of low latency and low power consumption. In addition, the traceability of data flow throughout the entire process is poor, resulting in low efficiency in fault location and problem investigation during operation and maintenance, failing to provide reliable data support for system collaborative control. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for multi-source data fusion and collaborative control of an energy self-control platform, the method comprising: A dynamic semantic self-alignment engine is built, which uses NLP and deep learning to realize physical quantity unit conversion, definition normalization and automatic point mapping, and supports user-defined rule completion and deviation correction. Develop an automatic topology recognition algorithm, construct a physical association map based on multi-dimensional information from the edge side and GNN, and realize automatic binding of measurement points and topology nodes and initialization of CAD drawings; A three-layer ontology modeling framework is built, and through modular protocol adaptation, semantic normalization and topological association, device constraints and characteristics are embedded to construct an energy ontology model with topological affiliation and physical attributes. Deploy a semantic verification and topology update mechanism for edge-cloud collaboration to achieve real-time data correction, algorithm parameter optimization, and dynamic reconstruction of the ontology model after device / topology changes; By introducing cross-protocol data middleware, defining a unified data interaction standard, shielding the differences in underlying protocols, and achieving high-precision synchronization of edge-cloud clocks through the PTP protocol; The ontology model is enhanced by integrating multimodal information, enabling the binding of data such as operation and maintenance logs and fault codes with topology nodes, and supporting model visualization and data traceability.

[0005] Furthermore, embodiments of the present invention also provide a multi-source data fusion and collaborative control system for an energy self-control platform, characterized in that it includes: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described energy self-control platform multi-source data fusion and collaborative control method by executing the machine-executable instructions.

[0006] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, the processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-mentioned energy self-control platform multi-source data fusion and collaborative control method.

[0007] Based on the above, the synergistic effect of the dynamic semantic self-alignment engine and the automatic topology recognition algorithm enables automated and standardized processing of multi-source heterogeneous data and intelligent binding of measurement points to topology nodes, completely eliminating the reliance on manual configuration. Automated execution of physical quantity unit conversion and definition normalization, along with the shielding of underlying protocol differences by cross-protocol data middleware, significantly reduces the manual cost and error rate of data integration. The accuracy of standardized data and the efficiency of point mapping are significantly improved. The GNN-driven physical correlation map can accurately capture the physical relationships between devices. Combined with the CAD drawing import initialization and dynamic update mechanism, it ensures the real-time consistency between topology information and the actual system, laying a solid foundation for data fusion.

[0008] The three-layer ontology modeling framework and multimodal information fusion technology endow the ontology model with rich topological affiliation, physical constraints, and operational characteristics, significantly improving the model's practicality and expressive power. The binding of operation and maintenance logs, fault codes, and topology nodes gives the data complete physical meaning and traceability. The edge-cloud collaboration mechanism, through the efficient combination of incremental synchronization and global optimization, reduces communication bandwidth consumption while achieving dynamic iterative optimization of semantic rules, algorithm models, and ontology models. Lightweight model processing and edge-side deployment adaptation meet the requirements of low latency and low power consumption. The end-to-end data traceability and visualization functions greatly improve the efficiency of fault location and problem investigation during operation and maintenance, providing reliable data support and technical assurance for the collaborative control and intelligent decision-making of energy automation systems. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the execution flow of the multi-source data fusion and collaborative control method for the energy self-control platform provided in this embodiment of the invention.

[0010] Figure 2 This is a schematic diagram of exemplary hardware and software components of the multi-source data fusion and collaborative control system of the energy self-control platform provided in the embodiments of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0012] Step S110: Construct a dynamic semantic self-alignment engine, which uses NLP and deep learning to realize physical quantity unit conversion, definition normalization and automatic point mapping, and supports user-defined rule completion and deviation correction. The constructed dynamic semantic self-alignment engine integrates NLP technology and deep learning models to automate the entire physical quantity processing process. Specifically, the unit conversion function uses a built-in industry-standard conversion table (covering all categories of physical quantities such as power, temperature, and flow rate) combined with the semantic recognition capabilities of deep learning models for unit expressions, supporting automatic mapping and conversion of non-standardized units (such as "degree" and "kilowatt-hour"). The definition normalization module, based on energy field standards (GB / T 2900.50), unifies heterogeneous expressions such as "total load" and "total power consumption" into standard definition labels through semantic similarity calculations. The automatic point mapping module achieves accurate association between original and standard points through matching similarity output from a dual-tower model. Simultaneously, the engine provides a visual custom rule configuration interface, allowing users to add custom rules in the format of "original expression - standard mapping - effective scope," which the system automatically incorporates into the rule base for calculation. For mapping deviations, the engine statistically analyzes deviation data in real time (such as semantic matching error rate and conversion error), fine-tunes model weights through incremental learning algorithms, and updates the rule base and model parameters periodically to ensure continuous deviation correction and improve engine adaptability.

[0013] Step S111: Build a basic resource layer, construct a structured semantic dictionary library containing physical quantity standard information for all types of energy self-control protocols, and formulate nameplate OCR recognition rules and field extraction templates according to equipment categories to build a nameplate parsing template library; The basic resource layer comprises two core components: a structured semantic dictionary and a device nameplate parsing template library. The semantic dictionary, designed for all types of energy control protocols including Modbus, OPC UA, and BACnet, is structured and stored using fields such as "physical quantity name - standard unit - definition dimension - equipment type - protocol compatibility range." It covers over a thousand core physical quantities, including active power, voltage, and temperature, and supports rapid retrieval by protocol type and equipment category. The device nameplate parsing template library is categorized by equipment type (meters, transformers, frequency converters, etc.), with each category corresponding to specific OCR recognition rules and field extraction templates. The OCR recognition rules optimize the image preprocessing workflow (denoising, correction, enhancement) to improve the accuracy of nameplate character recognition. The field extraction templates, addressing layout differences in nameplates from different manufacturers, pre-set extraction logic for key fields such as rated power, voltage level, and model number. It supports both fixed-position extraction and semantic matching extraction modes to ensure the completeness and accuracy of field extraction. The template library also allows users to add custom templates to adapt to nameplates from less common manufacturers.

[0014] Step S112: Collect unstructured data from equipment manuals, protocol documents, and nameplate images; preprocess the text and nameplate data separately; and standardize all data into JSON format with source annotations. The data collection scope covers three types of unstructured data: device manuals (PDF / Word format), protocol documents (register mapping tables, message format descriptions), and nameplate images (JPG / PNG format). The preprocessing process for text data includes: deduplication (removing duplicate content based on text hash values), format standardization (uniformly converting to plain text), word segmentation and stop word removal (using jieba for word segmentation and filtering meaningless words such as "de", "ji", etc.); the preprocessing of nameplate images includes: grayscale conversion, noise removal (Gaussian filtering), skew correction (Hough transform), and character region segmentation. All preprocessed data is encapsulated in a unified JSON format, with fields including "data type (text / image) - source identifier (device model - document name) - original content - preprocessed content - collection timestamp". For image data, a text result field after OCR recognition needs to be appended to ensure that the source of each data can be traced and the format can be parsed, laying a foundation for subsequent semantic entity extraction.

[0015] Step S113: Based on the fine-tuned BERT model, construct NER and RE models, extract and associate semantic entities related to physical quantities, and combine manual assisted annotation to construct a sufficient amount of labeled data set, and divide it into training / validation / test sets according to the ratio of 8:1:1; Based on the fine-tuned BERT model in the energy field, construct a named entity recognition (NER) model and a relation extraction (RE) model respectively. After being fine-tuned by the energy field corpus (device manuals, protocol documents), the NER model is specialized in extracting semantic entities such as physical quantity names, units, definition dimensions, device types, etc., and outputs entity type and location information; the RE model targets three core relationships of "physical quantity - unit", "physical quantity - definition dimension", and "physical quantity - device type", and realizes entity association relationship recognition through the training of labeled entity pairs. Manual assisted annotation uses professional annotation tools, and annotators annotate the preprocessed data according to preset specifications (entity type definition, relationship type definition) to construct a sufficient amount of labeled data set (with a scale of not less than 100,000), and randomly divide it into training set, validation set, and test set according to the ratio of 8:1:1. The training set is used for model parameter training, the validation set is used to adjust hyperparameters (such as learning rate, batch size), and the test set is used to evaluate model performance. It is required that the entity recognition accuracy of the NER model is ≥96%, and the relation extraction accuracy of the RE model is ≥94%.

[0016] Step S114: Extract multi-dimensional features of physical quantities, build a two-tower deep learning model and embed unit conversion and definition normalization rules, complete model training optimization and lightweight processing, and adapt to the requirements of edge-side deployment; First, multi-dimensional feature extraction of physical quantities is performed, followed by the construction of a dual-tower deep learning model and optimization of the entire process. During feature extraction, semantic, rule-based, and statistical features are integrated and weighted into a high-dimensional feature vector through an attention mechanism. The dual-tower model processes the original physical quantity and standard physical quantity features separately, embedding a unit conversion submodule and a normalization definition submodule to achieve matching degree calculation and standardized output. During model training, data augmentation techniques are used to expand training data, a joint loss function is designed to optimize model performance, and the optimal hyperparameter combination is determined through grid search. Lightweight processing employs a three-level "pruning-quantization-compression" scheme: structured and unstructured pruning are combined to remove redundant parameters, differential precision quantization balances performance and resource consumption, and the LZMA algorithm compresses the model size. For edge deployment adaptation, the model is converted to ONNX format, and then adapted to inference engines such as TensorRT and OpenVINO for ARM / x86 architecture edge controllers, ensuring inference latency ≤100ms and memory usage ≤200MB, meeting the requirements of low-resource environments on the edge.

[0017] Step S1141: Extract semantic features of physical quantities based on a pre-trained language model adapted to the energy field, introduce dynamic context encoding to compensate for scene adaptation defects, and process cross-language physical quantity names to ensure feature consistency. Construct an encoding dictionary and rule system to extract and normalize unit, definition dimension, and related information rules features. Statistically analyze the frequency of physical quantity occurrence, matching success rate, and unit and equipment type matching degree and standardize them. After concatenating the semantic, rule, and statistical features, focus the features through an attention mechanism and output a fused feature vector. Semantic feature extraction employs a fine-tuned BERT model adapted for the energy domain. The original names and definitions of physical quantities are input into the model to obtain 768-dimensional static word vectors. Dynamic context encoding is introduced, concatenating protocol type and device type as contextual features to the word vectors, which are then mapped to dynamic semantic features via a fully connected layer, compensating for the limitations of static vectors in adapting to different scenarios. For English physical quantity names (e.g., "P_active"), stemming is performed using Porter Stemmer and then mapped to Chinese semantic vectors, ensuring cross-language consistency. Rule-based feature extraction constructs a unit encoding dictionary, converting units into one-hot encodings and concatenating them with numerical features. Definition dimensions such as "instantaneous / cumulative" and protocol / device types are individually encoded using one-hot encoding. All rule features are normalized by a BatchNorm layer. Statistical features are extracted based on the frequency of physical quantity occurrence and matching success rate. The matching degree between units and device types is calculated and normalized to the [0,1] interval using Min-Max. Finally, the three types of features are concatenated into an 811-dimensional fusion feature vector, weighted by a Self-Attention layer to focus on key features such as name semantics and unit type, suppressing redundant information.

[0018] Step S1142: Construct the original physical quantity tower and the standard physical quantity tower, use the same network structure to process the corresponding fused features and output feature vectors respectively, obtain the matching degree between the two through the similarity calculation layer, embed a unit conversion submodule in the model, build industry standard conversion rules, identify unit types and calculate conversion coefficients, mark abnormal unit matching cases and bind similarity trigger conditions, add a definition dimension normalization submodule, realize the mapping of the original definition dimension to the standard label through rule matching and semantic similarity verification, design the output layer to integrate matching similarity, conversion coefficient, and standard definition dimension label, and build a logic verification and matching standard judgment mechanism. In the dual-tower model, Tower 1 (the original physical quantity tower) and Tower 2 (the standard physical quantity tower) use the same network structure: after inputting 811-dimensional weighted fusion features, they pass sequentially through fully connected layers (ReLU activation) with 512 and 256 neurons, and a Dropout layer with dropout_rate=0.2, outputting a 256-dimensional feature vector. The similarity calculation layer uses the cosine similarity formula to calculate the matching degree of the output vectors of the two towers, outputting a value in the range of 0-1. The unit conversion submodule has a built-in industry standard conversion table. It first identifies the unit types of the original and standard physical quantities, calls the corresponding formula to calculate the conversion coefficient, and if the unit types do not match, it marks an anomaly and outputs a coefficient of 0. This coefficient is bound to the similarity, and the application is automatically triggered when the similarity is ≥0.85. The dimension normalization submodule has a built-in mapping rule library. Through rule matching and semantic similarity dual verification, it maps the original defined dimensions to standard labels (such as "total power consumption" and "total active power (cumulative value)"). The output layer integrates matching similarity, conversion factor, and standard label, with built-in validation logic: if the similarity is <0.85, only the similarity is output and marked "match not met"; if it is ≥0.85, the complete three elements are output, and the logic consistency between the conversion factor and the defined dimension is verified.

[0019] Step S1143: Augment the training data and organize it into a specified format, divide it into training set, validation set and test set, design a joint loss function including main loss and auxiliary loss, use an optimizer combined with learning rate decay strategy and early stopping strategy to train the model, optimize network structure parameters and training parameters through grid search, and verify the model performance based on the test set. Training data augmentation employs two methods: first, randomly replacing synonyms of physical quantities (e.g., replacing "active power" with "effective power"), and second, adjusting unit expressions (e.g., replacing "kW" with "kilowatt") to ensure data diversity. Data is formatted as "original feature-standard feature-label," with labels including similarity (1 / 0), standard conversion coefficient values, and standard labels for defined dimensions. The loss function uses a joint loss mechanism: the main loss is cross-entropy loss (weight 0.6), for similarity matching tasks; the auxiliary loss is L1 loss (weight 0.2), for conversion coefficient errors; and the classification cross-entropy loss (weight 0.2), for defined dimension mapping tasks. Model training uses the Adam optimizer with an initial learning rate of 1e-4, cosine annealing decay (T_max=100, eta_min=1e-6), batch_size=64, epoch=100, and an early stopping strategy (patience=10). The number of neurons in the fully connected layer (256 / 512 / 1024), Dropout rate (0.1 / 0.2 / 0.3), and learning rate (1e-4 / 5e-4 / 1e-3) were optimized using a grid search, and the parameter combination that achieved the highest accuracy on the validation set was selected. After training, the overall accuracy on the test set was required to be ≥95%, and the mean absolute error of the conversion coefficients was ≤0.01.

[0020] Step S1144: Use structured pruning and unstructured pruning to remove redundant parameters of the model. After pruning, fine-tune to recover the accuracy loss. Perform differentiated accuracy quantification on different levels of the model. Optimize the computation graph after calibration. Compress the model and convert it into a general format to adapt to different edge hardware architectures. Structured pruning removes neurons with an absolute weight percentage < 1e-4 and prioritizes handling redundant parameters in fully connected layers. Unstructured pruning sets parameters with weights < 1e-5 to 0, controlling sparsity between 30% and 50%. After pruning, fine-tuning is performed using 10% of the original training set to recover accuracy loss. Model quantization employs a differentiated accuracy strategy: non-critical layers (such as the input layer and intermediate fully connected layers) are converted from FP32 to INT8, critical layers (attention layers and similarity calculation layers) retain FP32, and some computationally intensive layers are converted to FP16. KL divergence calibration is used to calibrate the quantized model, ensuring an accuracy decrease of ≤2%, while removing redundant operations generated by quantization and optimizing the computation graph. Model compression uses the LZMA algorithm to compress the model size to within 500MB. Format conversion first converts PyTorch / TensorFlow models to the ONNX universal format, then adapts them according to edge hardware architecture: NVIDIA edge cards are converted to TensorRT format, Intel devices to OpenVINO format, and embedded devices to TFLite format, ensuring efficient model operation on different edge hardware.

[0021] Step S1145: Compile corresponding inference engines for edge controllers with different architectures, adopt multi-threaded inference and adapt to low-power mode, input physical quantity data and abnormal data under various protocols, verify model functions and performance, reserve incremental update interfaces on the edge side, upload inference logs regularly, and optimize the model iteratively based on logs in the cloud to achieve edge-cloud collaborative closed-loop update.

[0022] The TensorRT inference engine is deployed on NVIDIA edge cards, OpenVINORuntime on Intel devices, and the TFLite engine on embedded devices. A multi-threaded inference mechanism is employed, with the number of threads set to match the number of CPU cores. Memory management is optimized to control memory usage, ensuring inference latency ≤100ms. A low-power mode is implemented; when there are no inference tasks, the model enters a sleep state, with only the monitoring module running, reducing energy consumption. During functional verification, raw physical quantity data (e.g., "total load, W, instantaneous value") from different protocols such as Modbus and OPCUA are input to verify the similarity, conversion coefficients, and accuracy of standard labels in the model output. Abnormal data (e.g., "temperature, kW") is input to verify the anomaly labeling function. Performance verification involves continuously inputting 1000 data points, testing single-data-point inference latency ≤100ms, CPU usage ≤50%, and memory usage ≤200MB. An incremental update interface is reserved on the edge side, and inference logs (including matching results, anomaly information, and deviation data) are uploaded regularly (daily). The cloud iterates and optimizes model parameters and rule base based on the logs, and distributes them to the edge side through incremental update packages to achieve closed-loop update between edge and cloud.

[0023] Step S115: Obtain raw location data from the interface protocol access layer, complete semantic matching through a deep learning model, automatically perform unit conversion and definition normalization on the qualified data, and generate a standardized location mapping table; The system obtains raw location data through a standardized interface access layer. The data format includes "Location ID - Physical Quantity Name - Unit - Definition Description - Protocol - Device ID". This raw location data is then input into a trained dynamic semantic self-alignment engine. The engine uses a dual-tower model for semantic matching, calculating the similarity between the raw physical quantities and standard physical quantities in the semantic dictionary. When the similarity is ≥0.85 (the threshold), unit conversion (based on the conversion coefficient output by the model) and definition normalization (based on standard definition dimension labels) are automatically triggered, completing the standardization of the raw data. When the similarity is <0.85, the data is marked as "Pending Manual Review" and pushed to the operations and maintenance end. The resulting standardized location mapping table is stored in a structured format, with fields including "Raw Location ID - Standard Physical Quantity Name - Standard Unit - Conversion Coefficient - Definition Dimension Label - Matching Similarity - Data Status (Valid / Pending Review)". This mapping table supports batch export and real-time querying, providing standardized data support for subsequent ontology modeling and topology association.

[0024] Step S116: Develop a visual custom rule configuration interface, detect mapping deviations in real time, correct model weights through incremental learning, set rule priorities, and incorporate high-frequency custom rules into the semantic dictionary library for iteration; The visual custom rule configuration interface includes three main functional modules: rule editing, priority setting, and scope limitation. Users can enter "original physical quantity description - standard mapping result" through the text input box, select the scope of application (entire system / specific protocol / specific device type), and set the rule priority (level 1-5, level 5 being the highest). Rules take effect immediately upon submission and are stored in the rule library. Mapping deviation detection compares the standardized results with user feedback data in real time, statistically analyzing the deviation type (e.g., unit conversion errors, definition mapping deviation) and frequency, automatically marking deviation data as incremental training data. During incremental learning, the underlying model parameters are frozen, with only the weights of the top fully connected layer and attention layer fine-tuned. The model is updated using deviation data to improve adaptability to specific scenarios. For high-frequency custom rules (usage frequency ≥ 100 times and no conflicts), the system automatically initiates a review process. After approval, the rules are standardized into dictionary entries and incorporated into the semantic dictionary for iterative updates, continuously optimizing the engine's mapping accuracy.

[0025] Step S117: Perform multi-dimensional real-time semantic verification on normalized data, issue graded alarms for anomalies, record and analyze full-process logs, and iteratively update the semantic dictionary and deep learning model on a periodic basis to achieve closed-loop optimization.

[0026] The system performs the following checks: 1) Verification of physical quantity and unit compatibility (e.g., temperature quantities must not correspond to units such as kW or A); 2) Verification of definitional dimension consistency (power measurement points on the same device must not be simultaneously labeled "instantaneous" and "cumulative"); 3) Verification of numerical reasonableness (based on the device's rated parameters, determine whether the physical quantity values ​​are within a reasonable range (e.g., rated voltage ±20%)); 4) Verification of topology logic (under the same topology node, the sum of branch physical quantities must not exceed the total physical quantity value). Anomalies are categorized by severity into minor (e.g., incorrect unit representation but correct conversion), moderate (e.g., values ​​exceeding a reasonable range but not exceeding safety thresholds), and severe (e.g., physical quantity-unit mismatch, values ​​exceeding protection thresholds), corresponding to log alerts, email alarms, and SMS + APP push alarms, respectively. The entire process log records verification results, anomaly information, handling methods, operators, etc., and is summarized and analyzed daily. The semantic dictionary and deep learning model are iterated weekly: dictionary entries are optimized based on log analysis results, and high-frequency heterogeneous expressions are added; the model is fine-tuned using newly added abnormal data and user feedback data, forming a closed-loop optimization mechanism of "verification-analysis-update-validation" to continuously improve the quality of data standardization.

[0027] Step S120: Develop an automatic topology recognition algorithm, construct a physical association map based on multi-dimensional information from the edge side and GNN, and realize automatic binding of measurement points and topology nodes and initialization of CAD drawings; The core of the automatic topology identification algorithm is based on multi-dimensional information from the edge side and a Graph Attention Network (GAT) to construct a physical association map, simultaneously achieving automatic binding of measurement points to topology nodes and initialization of CAD drawings. The algorithm first integrates edge-side electrical operating characteristics, communication link information, equipment location attributes, and measurement point configuration data to form multi-source input. It then uses the GAT model to mine potential physical associations between devices, outputting node association confidence scores and topology hierarchy labels (bus / main circuit / branch circuit). When importing CAD drawings, the algorithm connects to the drawing parsing module to obtain the initial topology skeleton, using it as the basis for map initialization, and integrates real-time edge-side data to correct drawing deviations (such as topology differences caused by actual equipment additions or subtractions). Automatic binding of measurement points to topology nodes is achieved through a dual mechanism of semantic matching and electrical logic reasoning. The binding result includes a confidence score; a score ≥0.9 is directly effective, while scores below the threshold are pushed for manual review. The algorithm supports incremental updates; when equipment, links, or measurement points change, only the changed parts are re-reasoned, ensuring map real-time performance and efficient resource utilization. The algorithm requires a topology identification accuracy of ≥98% and a measurement point binding accuracy of ≥97%.

[0028] Step S121: Collect electrical operation characteristics of the power distribution side, power consumption side, and energy storage / photovoltaic side according to the equipment type, and simultaneously collect communication link topology information between equipment, equipment installation location and basic attribute information, original configuration of measurement points and historical correlation records. The collected data is stamped with high precision and stored in a structured format. Multi-dimensional topology association information is collected based on equipment type differences to ensure data comprehensiveness and relevance. For distribution-side equipment, electrical characteristics such as impedance, voltage phase difference, current amplitude / phase, and power flow direction are collected; for consumption-side equipment, voltage level, rated power, and consumption phase are collected; for energy storage / PV-side equipment, voltage fluctuations and power interaction characteristics at the grid connection point are collected. The collection frequency is set according to the equipment response speed (high-frequency collection is used for millisecond-level equipment such as PLCs / RTUs, and conventional collection is used for second-level equipment such as smart meters). Communication link information between devices is collected synchronously. IP / MAC mapping, protocol type, and data interaction frequency are obtained through ARP / ICMP scanning to generate communication topology relationships. Equipment installation location (field entry / BeiDou positioning) and basic attributes (model, manufacturer, equipment type, circuit to which it belongs) are collected to form structured data of "equipment ID-attribute-location". Original configuration of measurement points (measurement point ID, equipment ID, collection protocol, physical quantity type) and historical association records and topology error logs are collected. All collected data is appended with a high-precision timestamp synchronized by PTP and stored in the edge database in a structured format of "data type-device ID-collection time-feature value" to support data traceability and subsequent preprocessing.

[0029] Step S122: Perform format conversion, redundant element removal and layer layering on the received electrical drawings, identify electrical components in the drawings and encode and assign topology node IDs, extract the connection relationships between components to generate an initial topology skeleton diagram, and standardize it into a graph data structure that can be interfacing with edge side data to form an initial topology map. For DWG / DXF format electrical drawings, parsing and topology initialization are performed to ensure standardized drawing data adaptation to edge-side systems. First, the drawings are converted to SVG vector format using the CAD SDK, preserving layer hierarchy information. Redundant elements such as annotation text, legends, and borders are removed using OpenCV algorithms, and Hough transform is used to correct drawing skew distortion. Layers are extracted according to "primary circuit / secondary circuit / communication circuit," and layers of core electrical components such as busbars, circuit breakers, transformers, meters, and sensors are selected and retained. Components are identified based on a finely tuned YOLOv8 model, outputting component location coordinates and type labels. A unique topology node ID is assigned to each component, establishing a mapping table of "drawing component - node ID - component type." Connection lines between components are extracted using a straight-line detection algorithm, identifying the node IDs corresponding to the start / end points of the connection lines. The connection type is determined by combining electrical drawing standards (thick solid lines for electrical connections, thin solid lines for communication connections), generating an initial topology skeleton diagram. The skeleton diagram is standardized into a graph data structure (adjacency matrix + node feature matrix). The node features include component type, drawing location, and line number. The node naming is unified according to the GB / T14549-2010 standard to form an initial topology map that can be connected with edge side data.

[0030] Step S123: Perform outlier removal, missing value completion and standardization on the multi-type data collected from the edge side, extract the topological features related to electrical, communication, equipment attributes and spatial location, and fuse the equipment features from the edge side with the topological node features from CAD analysis to form a total feature vector of topological nodes; Preprocessing and feature engineering were performed on various types of data collected from the edge side to provide high-quality input for the GNN model. During data preprocessing, the 3σ criterion was used to remove outliers in electrical features, and missing values ​​were filled in by interpolation using data from similar devices at the same time. Electrical features such as voltage, current, and impedance, as well as communication link weights, were normalized to the [0,1] interval, and spatial location information was converted into relative coordinate features with the distribution room as the origin. Topology feature extraction was categorized by dimension: electrical features extracted included 10 dimensions such as voltage phase difference, power flow direction, and impedance matching; communication topology features extracted included 8 dimensions such as link weight, protocol type, and interaction delay; equipment attribute features extracted included 6 dimensions such as equipment type, voltage level, and rated power; and spatial location features extracted included 4 dimensions such as region level and relative coordinates. During feature fusion, the 28-dimensional feature vectors of the edge-side devices were concatenated with the 12-dimensional topology node feature vectors from CAD analysis. After standardization using the BatchNorm layer, a 38-dimensional total topology node feature vector was formed, ensuring consistent feature dimensions and no information redundancy, laying the foundation for subsequent graph dataset construction.

[0031] Step S124: Construct a graph dataset containing nodes, edges, and association labels; design a GNN model architecture and input the adjacency matrix and node feature matrix of the graph data; complete model training by setting the loss function, optimizer, and training strategy; the model outputs the confidence of association between nodes and topological level labels. A graph dataset was constructed and a GNN model was trained, with the core implementation focusing on identifying device topology relationships and hierarchical structures. The graph dataset was constructed using edge devices and CAD-analyzed topological elements as nodes, with each node featuring a 38-dimensional total feature vector. Edges were initialized based on communication links and drawing connections, with weights set to initial association confidence. Labels were derived from manually confirmed topological relationships and equipment ledgers, indicating whether physical associations existed between nodes (1 = present, 0 = non-existent). The GNN model adopted a hybrid architecture of "GAT+GCN": the input layer received the adjacency matrix and node feature matrix, extracted local association features through two GAT layers (128 attention heads per layer), and output a 128-dimensional node embedding vector; subsequently, a single GCN layer fused global topological information, and the feature representation was optimized through fully connected layers (ReLU activation) with 128, 64, and 32 neurons; the output layer output the association confidence between nodes and the topological hierarchy labels. The loss function uses binary cross-entropy loss (70% weight) + cross-entropy loss (30% weight). The optimizer is AdamW with an initial learning rate of 5e-4, which decays by 10% every 20 epochs. The training set / validation set / test set is divided in a 7:1:2 ratio. An early stopping strategy is introduced (if the validation set loss does not decrease after 10 epochs, the training is stopped). After training, the topological association recognition accuracy is required to be ≥98%, and the hierarchical classification accuracy is required to be ≥95%.

[0032] Step S125: Input the edge-side fused features into the trained GNN model to infer the device association relationship, fuse the initial CAD topology skeleton to generate the initial physical association map, detect and mark topology conflict items for manual correction, monitor system changes in real time and trigger incremental model inference to realize dynamic updating of the topology map; A physical relationship map is generated based on the trained GNN model and dynamically updated. First, the 38-dimensional fused features from the edge side are input into the model, and the inference output shows the confidence level of relationships between devices. A threshold of ≥0.9 is set to filter valid relationships. The CAD initialization topology skeleton is then fused, and the model's inference results are compared with the topology relationships on the drawings. High-confidence relationships are retained, while low-confidence conflict items (such as device A being marked as connected to bus 1 on the drawing, but the model infers it to be connected to bus 2) and electrical logic conflict items (such as the sum of branch power exceeding the total power) are marked and pushed to the engineer for manual correction. The dynamic update mechanism is triggered in real time by monitoring device additions / removals, communication link changes, and abrupt changes in electrical characteristics (such as power flow reversal lasting more than 5 seconds). After triggering, a lightweight GNN model is invoked to perform incremental inference, updating only the relationships and node attributes of the changed devices, avoiding the resource consumption of full inference. The updated topology map is synchronized to edge-side storage, and a log of "change type - involved nodes - old relationship - new relationship - update time" is generated to ensure map traceability and update latency is controlled within 5 seconds.

[0033] Step S126: Extract the measurement point features and topology node features for semantic and electrical feature matching, perform batch binding operations according to the set priority binding rules, automatically verify the binding results, and mark those that fail the verification as pending manual review. The system achieves automatic binding of measurement points to topology nodes, employing a core workflow of "feature matching - priority binding - automatic verification." Measurement point feature extraction includes measurement point ID, type of physical quantity acquired, associated protocol, associated device ID, and acquired value characteristics. Topology node features include device type, physical quantity acquisition capability, protocol type, and topology level. The matching phase utilizes a dynamic semantic self-alignment engine to achieve semantic matching (physical quantity name similarity), combined with electrical feature matching (e.g., voltage measurement points only match bus / transformer nodes), generating a binding confidence score. Binding priority rules are set as follows: ① direct device ID matching (measurement point label device ID matches topology node ID), ② semantic + electrical feature matching (confidence score ≥ 0.9), ③ historical binding record matching. Binding is performed in batches according to priority, generating a "measurement point ID - topology node ID - binding type - confidence score" relationship table. The automatic verification logic includes: whether the device to which the measurement point belongs is under the jurisdiction of the topology node, whether the physical quantity type matches the node's acquisition capability, and whether the sum of the power of the branch measurement points is less than or equal to the total node power. If the verification fails, it is marked as "awaiting manual review" and pushed to the visual interface for operation and maintenance personnel to handle. The overall accuracy requirement is ≥97%.

[0034] Step S127: Lightweight the GNN model to adapt it for edge deployment, integrate various functional modules and link them with relevant levels of the energy control platform, carry out functional verification and performance and abnormal scenario verification of topology initialization, association graph generation and measurement point binding, and continuously iterate and optimize the model and binding rules based on error logs during use.

[0035] The deployment, system integration, and iterative optimization of the GNN model at the edge were completed. The model lightweighting adopted a "pruning + quantization" scheme: a combination of structured and unstructured pruning to remove redundant parameters, and INT8 quantization to compress the model size, ensuring inference latency ≤50ms and memory usage ≤200MB. For ARM / x86 architecture edge controllers, TensorRT and OpenVINO inference engines were adapted respectively, employing multi-threaded inference and adapting to low-power mode. During system integration, topology recognition, drawing parsing, and measurement point binding modules were integrated into the edge-side topology recognition engine, linking with the energy self-control platform protocol access layer and semantic aggregation layer to achieve seamless data flow. The verification phase included functional verification (importing CAD drawings from different manufacturers, simulating device addition / deletion / communication interruption), performance verification (generating a map of 1000+ devices in ≤5 minutes), and abnormal scenario verification (generating a map based on edge data when drawings are missing, with an accuracy ≥90%). Iterative optimization is based on error logs during use. The hyperparameters of the GNN model, topology association rules, and measurement point binding priorities are adjusted regularly, and the model training data is updated monthly to continuously improve the accuracy of topology recognition and binding.

[0036] Step S130: Build a three-layer ontology modeling framework, embed device constraints and characteristics through modular protocol adaptation, semantic normalization and topological association, and construct an energy ontology model with topological affiliation and physical attributes; A three-layer ontology modeling framework of "protocol adaptation, semantic normalization, and topology association" is constructed, with core embedded equipment constraints and characteristics to build an energy ontology model with topological affiliation and physical attributes. The bottom layer, protocol adaptation, shields heterogeneous protocol differences and outputs standardized raw data; the middle layer, semantic normalization, normalizes the names, units, and definition dimensions of physical quantities, outputting data with physical attributes; the top layer, topology association, assigns topological affiliation attributes to the data, outputting ontological data. Equipment constraints (rated voltage / current, protection threshold) and operating characteristics (efficiency curves, SOC curves) are collected from equipment ledgers, nameplates, and manufacturer manuals, and a structured library is built. This library is embedded into the ontology model by adding "equipment constraint classes," "operating characteristic classes," and relationships (equipment-containment-constraint / characteristic). The framework adopts a modular design, with decoupling between layers and data traceability. The ontology model supports unified querying of physical attributes (such as power and voltage), topological attributes (such as node and level), and constraint characteristics (such as rated power), providing ontological data support for subsequent energy consumption statistics and collaborative control.

[0037] Step S131: Define the overall architecture and interaction logic of the three-layer ontology modeling framework, clarify the functional boundaries of the bottom protocol adaptation layer, the middle semantic unification layer, and the top top topology association layer, design the unified interaction interface and data flow triggering rules between layers, clarify the modules and outputs of each layer, and realize the decoupling between layers and data traceability. The architecture and interaction logic of the three-layer ontology modeling framework are clearly defined to ensure efficient inter-layer collaboration. The bottom layer, the protocol adaptation layer, is defined as the "heterogeneous data access layer," with core modules including pluggable protocol adapters and data preprocessing units, outputting standardized raw data. The middle layer, the semantic normalization layer, is defined as the "data standardization layer," with core modules including a semantic normalization engine and a consistency verification unit, outputting normalized data with physical attributes. The top layer, the top-level topology association layer, is defined as the "physical association layer," with core modules including a topology association rule engine and an ontology modeling unit, outputting ontology-specific data with topology attribution. Inter-layer interaction interfaces use JSON-LD format to adapt to ontology modeling specifications, and the communication protocol uses gRPC to ensure low latency. Data flow triggering rules are set as follows: data is automatically pushed to the middle layer after bottom-layer data collection; topology association is triggered after semantic normalization; and the updated topology map is synchronized to the top-level ontology model. The output formats and data traceability identifiers for each layer are clearly defined (e.g., each layer's data is appended with a unique ID and source marker), achieving decoupling between layers and ensuring full traceability of data from access to ontology, with interface compatibility supporting subsequent module expansion.

[0038] Step S132: Develop pluggable protocol adaptation modules according to protocol type, adopt a pluggable framework to support hot-plugging, define a unified input and output interface, adapt the acquisition strategy for different protocol characteristics, perform integrity verification and invalid data filtering on the acquired data, output structured raw data, and reserve custom protocol adaptation interfaces to expand compatibility. A modular protocol adaptation layer is implemented at the bottom layer, with core support for heterogeneous protocol access and expansion. Independent pluggable adaptation modules are developed based on the OSGi pluggable framework for protocol types such as Modbus-RTU / TCP, OPCDA / UA, and BACnet. Each module includes sub-modules for protocol parsing, data acquisition, and message verification, supporting hot-swapping. When adding a new protocol, only the corresponding plug-in needs to be developed, without modifying the core code. A unified input / output interface is defined: inputs are acquisition commands and device communication parameters, and outputs are structured data in the format of "Device ID-Measurement Point ID-Raw Value-Acquisition Timestamp-Protocol Type." The interface uses the gRPC protocol for communication. Acquisition strategies are adapted according to protocol characteristics: Modbus uses polling acquisition, and OPCDA uses subscription acquisition. After acquisition, CRC / MD5 message verification, null / garbled character filtering are performed, and communication timeouts, message errors, and other anomalies are recorded and retries are triggered. The framework provides a custom protocol adaptation interface, allowing users to upload register mapping tables and message format rules for their private protocols. The framework automatically generates lightweight parsing logic to adapt to non-standard protocols from niche vendors, reducing adaptation costs and ensuring protocol coverage of ≥99%.

[0039] Step S133: Deploy a lightweight instance of the dynamic semantic self-alignment engine, complete the normalization of physical quantity names, units, and definition dimensions based on the semantic dictionary, encapsulate the normalized data into structured data units and supplement relevant tags, build in semantic consistency verification logic, and establish an edge-cloud semantic rule synchronization mechanism. The middle layer achieves semantic normalization, with the core function of data standardization and consistency verification. A lightweight instance of the dynamic semantic self-alignment engine (≤200MB in size, inference latency ≤50ms) is deployed. After receiving the raw data from the underlying layer, it matches the semantic dictionary (based on GB / T2900.50 standard) to normalize physical quantity names (e.g., "total load," "total active power"), convert units (e.g., W, kW, ℃, K), and normalize defined dimensions (e.g., "instantaneous," "cumulative," standard labels). Normalized data is encapsulated in RDF triple format (subject: measurement point ID, predicate: physical attribute, object: value / standard unit), supplemented with data quality labels (valid / abnormal / complete) and data source (protocol type, adapter ID), forming the basic data unit for semantic normalization. Built-in semantic consistency verification logic verifies the matching of physical quantities and units (e.g., temperature ≠ kW), the consistency of defined dimensions for physical quantities on the same device, and the reasonableness of numerical ranges (e.g., voltage exceeding rated value ±20% is marked as abnormal). Abnormal data is pushed to the engineer's end and triggers engine deviation correction. The edge-cloud semantic rule synchronization mechanism is set as follows: the edge side synchronizes semantic rules and exception logs to the cloud every hour. After optimizing the rules based on global data, the cloud sends out incremental update packages to ensure the consistency of edge-cloud rules.

[0040] Step S134: Define topological association rules based on the physical association graph, bind semantically normalized data units to topological nodes to embed topological attribution information, construct the topological layer ontology structure using ontology description language and instantiate data units, and listen for topological graph update events to realize dynamic updates of topological attributes and relationships in the ontology model. The top-level topology association layer is implemented by fusing semantically normalized data with topology associations to construct an ontology model. Based on the physical association graph generated by GNN, rules for binding measurement points to topology nodes, topology level aggregation rules (branch loops, main loops, buses), and physical quantity topology attribution rules are defined. These rules are stored in a configurable format and support visual modification. Topology attribution information is embedded by binding semantically normalized data units with topology node IDs, adding attributes such as "belonging topology node ID, topology level, loop number, and parent topology node ID," giving the data a three-dimensional attribute of "physical location - topology level - equipment attribution." The topology layer ontology structure is constructed using the OWL 2 DL ontology description language, defining core ontology classes (buses, main loops, branch loops, electrical equipment), ontology attributes (including measurement points, parent topology nodes, and physical quantity types), and ontology relationships (belonging to, aggregation of, and power supply). Data units bound to topology attribution are instantiated into the corresponding ontology classes. Listen for topology map update events (device addition / removal, topology relationship changes), automatically update the topology attributes and relationships in the ontology model, and instantiate the corresponding ontology class and bind the attributes when a new device is added, without manual intervention.

[0041] Step S135: Collect equipment physical constraints and operating characteristics data from multiple sources and build a structured library. Add corresponding ontology classes and attributes to the ontology model. Instantiate the constraint and characteristic data to the corresponding equipment ontology instance and establish the association relationship. Built-in constraint verification logic and characteristic adaptation algorithm support dynamic updates of constraint and characteristic data. The system extracts rated voltage / current and start / stop intervals from equipment ledgers, rated power and protection thresholds from nameplate analysis, and efficiency curves, response delays, and SOC curves from manufacturer manuals. These are categorized and stored as a structured constraint / characteristic library by equipment ID, supporting both manual addition and automatic updates. The ontology model is expanded to include "Equipment Constraint Class" and "Operating Characteristic Class," defining attributes such as rated power, start / stop intervals, efficiency curve parameters, and SOC thresholds. Constraint / characteristic library data is instantiated into corresponding equipment ontology instances, establishing relationships such as "Equipment ontology - Contains - Constraint Instance" and "Equipment ontology - Associates - Characteristic Instance." Built-in constraint verification logic verifies in real-time whether measurement point data conforms to constraints (e.g., triggering alarms when current exceeds rated values). Embedded characteristic adaptation algorithms adjust power data parsing rules based on the energy storage SOC curve to ensure data aligns with actual equipment operating characteristics. A dynamic update mechanism supports: periodic correction of characteristic parameters based on historical equipment operating data (e.g., adjusting efficiency curves due to equipment aging); manual updates of constraint parameters after equipment maintenance / replacement; and automatic synchronization of the framework to the ontology model.

[0042] Step S136: Instantiate the instance data of each layer according to the ontology specification and assign a unique identifier to build a complete energy ontology instance library. Adopt an edge-cloud collaborative storage and retrieval scheme, develop a visualization module to display ontology classes, relationships and instance data, and support querying, modification and data topology attribution tracing. The energy ontology model is instantiated and stored, supporting visualization, interaction, and traceability. Instantiation is performed according to the OWL 2 DL specification, assigning unique URIs to protocol adaptation layer device instances, semantic layer physical quantity instances, topology association layer topology node instances, and constraint / characteristic instances to ensure global uniqueness and form a complete energy ontology instance library. Storage adopts an edge-cloud collaborative solution: the Stardog ontology database is deployed in the cloud to store the full ontology data and support complex SPARQL queries (such as "query the total active power of all branch circuits under bus 1"); a lightweight RDF4J database is deployed at the edge to store ontology data within its local jurisdiction, meeting low-latency query requirements, with edge-cloud data synchronized on a minute-by-minute basis. Unstructured data (such as complete equipment manuals and characteristic curve charts) is stored in object storage services, with associations established through instance IDs. The visualization module is developed based on D3.js, displaying ontology classes, relationships, and instance data in the form of a topology diagram and attribute panel, supporting engineers to visualize and query, modify ontology attributes (such as adjusting constraint thresholds), and trace data topology ownership, solving the black-box problem of the ontology model, with query response latency ≤1s.

[0043] Step S137: Verify the integrity, consistency and usability of the ontology model. Based on the verification results and field usage logs, regularly optimize the protocol adaptation module, semantic normalization rules and topology association rules, update the ontology class and attribute definitions, and adapt to the dynamic changes of the energy system.

[0044] Integrity verification checks that the coverage rate of equipment / measuring points / topology nodes is ≥99% and the embedding rate of constraints / features is ≥98%. Uncovered items are marked and supplementary data collection is triggered. Consistency verification uses the Pellet ontology inference engine to detect logical conflicts (such as binding multiple topology nodes to the same measuring point or contradictory constraint parameters), outputting conflict reports and locating the root cause. Usability verification is based on business scenarios such as energy consumption statistics and collaborative control, verifying model query efficiency (complex queries ≤1s) and data support accuracy ≥98%. Iterative optimization is based on verification results and field usage logs, regularly optimizing protocol adaptation modules (e.g., adding non-standard protocol plugins), semantic normalization rules (supplementing high-frequency heterogeneous representation mappings), and topology association rules (adjusting binding priorities). Ontology classes and attribute definitions are updated quarterly (e.g., adding a "photovoltaic-storage collaborative equipment class"). A closed loop of "verification-analysis-optimization-verification" is established to adapt to dynamic changes in energy system equipment, topology, and operating status, continuously improving the integrity, consistency, and usability of the ontology model.

[0045] Step S140: Deploy the semantic verification and topology update mechanism for edge-cloud collaboration to achieve real-time data correction, algorithm parameter optimization, and dynamic reconstruction of the ontology model after device / topology changes; The deployed edge-cloud collaborative semantic verification and topology update mechanism achieves a three-in-one collaborative approach: real-time data correction, algorithm parameter optimization, and dynamic ontology model reconstruction. At the edge, focusing on low-latency scenarios, a lightweight engine performs local data semantic verification and anomaly correction, monitors topology changes in real time, and executes incremental updates. The cloud assumes global optimization responsibilities, aggregating incremental data from the edge to iterate rules and models, and executing global ontology model reconstruction when trigger conditions are met. The mechanism reduces communication bandwidth consumption through incremental synchronization strategies, establishing a closed-loop process of "real-time edge processing - global cloud optimization - edge feedback execution": data correction is achieved in real-time based on an anomaly classification mechanism; algorithm parameter optimization continuously improves accuracy through incremental training; and ontology reconstruction adapts to dynamic changes in devices / topology, ensuring consistency and timeliness throughout the system from the data layer to the model layer. Technical personnel can flexibly adapt to different energy automation scenarios by configuring synchronization rules, reconstruction trigger thresholds, and other parameters.

[0046] Step S141: Define the responsibilities of the edge-cloud collaborative architecture. The edge focuses on real-time scenarios, performing local real-time semantic verification of data, topology change monitoring, abnormal data correction, lightweight algorithm inference, and local incremental updates of the ontology model. It only synchronizes incremental data to the cloud. The cloud focuses on global optimization scenarios, responsible for global semantic rule management, algorithm model training iteration, global reconstruction verification of the ontology model, and cross-edge node topology data fusion, and sends incremental update packages to the edge. The edge-cloud collaborative architecture clearly defines the responsibilities of the edge and cloud sides, ensuring efficient collaboration and clear division of labor. The edge side, deployed on edge controllers / gateways, focuses on real-time core tasks: performing millisecond-level verification of local data through a lightweight semantic verification engine, capturing topology changes in seconds through multi-dimensional monitoring modules, correcting local data according to anomaly classification rules, and implementing low-latency inference by calling lightweight algorithm models, performing only local incremental updates to the ontology model (such as topology attribute modifications and new instance bindings). The edge side only synchronizes incremental data (anomaly logs, topology change events, and inference bias data) to the cloud, avoiding full data transmission. The cloud side, deployed on a central server, focuses on global optimization: establishing a unified global semantic rule library for management, performing full training or incremental iteration on algorithm models, integrating cross-edge node data to complete global reconstruction and consistency verification of the ontology model, and encapsulating optimized rules, model parameters, and ontology changes into incremental update packages and distributing them to the edge side, ensuring the consistency between edge-cloud data and models.

[0047] Step S142: Design an edge-cloud collaborative communication mechanism, adopt a lightweight low-latency communication protocol combined with a high-reliability protocol to achieve bidirectional communication, encrypt data transmission, clarify the data synchronization granularity, synchronize incremental data only from the edge to the cloud, and send incremental update packets only from the cloud to the edge, set data synchronization trigger rules, including real-time push, event-triggered push and batch push, and configure a breakpoint resume mechanism to ensure data synchronization reliability. The edge-cloud collaborative communication mechanism adopts a combination of "lightweight protocols as the primary means and highly reliable protocols as a supplement" to ensure low latency and high reliability. The core communication protocol is MQTT 5.0, adapted to the lightweight deployment requirements of the edge side, supporting QoS 1 / 2 level message delivery to meet the transmission needs of incremental data and ordinary commands. Key commands (rule issuance, topology reconstruction commands) are overlaid with the HTTP / 2 protocol, improving transmission reliability through connection reuse and flow control mechanisms. Data transmission uses TLS 1.3 encryption to prevent data leakage and tampering. Data synchronization granularity is strictly limited to incremental: the edge side only synchronizes incremental data such as abnormal logs and topology change events, with each data entry controlled within 1KB; the cloud only issues incremental update packages such as rule patches and parameter fine-tuning values. Synchronization trigger rules are set according to scenarios: real-time push of abnormal data from the edge side (≤1s), immediate push of topology change events, and batch push of regular logs; hourly batch distribution of cloud optimization results and on-demand incremental distribution after ontology reconstruction. Resumable transmission uses Redis persistent caching of data to be synchronized on the edge side, and records the received data identifier in the cloud. Once the network is restored, transmission will automatically resume, avoiding duplicate synchronization and data loss.

[0048] Step S143: Deploy a lightweight semantic verification engine on the edge side, connect to multi-level data and set the dimensions and rules for basic verification, logical verification and time-series verification, process abnormal data according to minor, moderate and severe levels and correct them in real time, record correction logs in a structured manner and only synchronize abnormal logs to the cloud. The lightweight semantic verification engine deployed at the edge is tailored from a dynamic semantic self-alignment engine, with a size ≤200MB and inference latency ≤50ms, seamlessly integrated into the edge controller. The engine interfaces with the protocol adaptation layer for raw data and the semantic normalization layer for normalized data, setting three layers of verification rules: basic verification verifies the matching of physical quantities and units, and the consistency of defined dimensions; logical verification ensures that the sum of branch power under the same topology node is ≤ total power, and voltage values ​​are within a reasonable range of device ratings; time-series verification ensures that cumulative physical quantities monotonically increase and that abrupt changes are compliant. Abnormal data is handled according to severity: minor anomalies (non-standard units) are automatically converted and corrected using the semantic dictionary; moderate anomalies (values ​​slightly out of range) temporarily store the original data, correct it to the average value of similar devices during the same period, and report it to the cloud; severe anomalies (physical quantity-unit mismatch, value exceeding protection threshold) suspend data output, mark the anomaly type, push for manual confirmation, and trigger device communication retry. Correction logs are recorded in a structured manner according to "data ID-verification dimension-anomaly type-correction method-time," with only anomaly logs synchronized to the cloud, and valid data retained locally.

[0049] Step S144: Construct a multi-dimensional monitoring module for edge-side topology changes, collect trigger signals from the device layer, link layer, and electrical layer, set monitoring thresholds and generate topology change events, call the lightweight model to perform incremental inference to update the local topology map, synchronously update relevant attributes of the local ontology model, and synchronize topology change-related data to the cloud after completion. The constructed edge-side topology change multi-dimensional monitoring module achieves dynamic topology monitoring through a complete process involving signal acquisition at the device, link, and electrical layers, threshold comparison, incremental inference, local updates, and edge-cloud synchronization. The module adopts a modular design, with each sub-module performing its specific function: the multi-dimensional monitoring sub-module acquires three types of trigger signals according to a strategy; the threshold configuration unit sets dynamic thresholds; the event generation unit generates deduplicated topology change events; the incremental inference unit calls a lightweight GNN model to output correlation results; the model update unit synchronously updates the topology map and ontology model; and the data synchronization unit completes incremental transmission between the edge and cloud. The module incorporates built-in operation monitoring and anomaly handling logic, monitoring the operational status of each stage in real time, triggering retry mechanisms for anomalies such as acquisition failures and inference timeouts, and periodically verifying the consistency between the topology map and ontology model. The entire module achieves closed-loop processing from signal acquisition to model update, with a topology change event synchronization latency of ≤5s, meeting the real-time requirements of the edge side and adapting to dynamic changes in energy system equipment and topology.

[0050] Step S1441: A modular design is adopted to construct a multi-dimensional monitoring module for topology changes, which includes a multi-dimensional monitoring sub-module, a threshold configuration unit, an event generation unit, an incremental inference unit, a model update unit, and a data synchronization unit. A standardized interface between the module and the existing system on the edge side is defined, and a low-latency communication protocol is used to realize the interaction between the module and each system. The multi-dimensional topology change monitoring module adopts a modular design, comprising seven core components: device layer / link layer / electrical layer monitoring sub-modules, threshold configuration unit, event generation unit, incremental inference unit, model update unit, and data synchronization unit. The module defines standardized interfaces for interfacing with existing edge systems: it obtains device communication data and electrical quantity acquisition data through gRPC protocol and protocol adaptation layer; it interacts with the edge-side ontology database to obtain device / measuring point topology attributes; and it interfaces with a lightweight GNN model to provide inference input and receive output results. The interface supports low-latency interaction (latency ≤10ms). Modules communicate with each other through internal message queues, supporting independent component upgrades and replacements, and possessing good scalability. The standardized interfaces and modular design ensure that the module can adapt to edge controllers and gateways of different brands and architectures, and technical personnel can quickly complete integration and deployment through the interface documentation.

[0051] Step S1442: Collect multiple types of trigger signals from the device layer, link layer, and electrical layer respectively, obtain relevant status, parameter, and feature data according to the corresponding acquisition strategy, and generate structured acquisition data; Multi-dimensional signal acquisition is categorized into device, link, and electrical layers to ensure comprehensive signal coverage across topology change scenarios. At the device layer, the edge gateway's device management interface collects device communication status, ID addition / deletion flags, and nameplate parameter changes every second. The device ledger synchronization interface collects batch data on device type and rated parameter updates every 5 minutes, generating structured data in the format of "Device ID - Signal Type - Acquired Value - Time". At the link layer, the network scanning module collects IP / MAC mapping relationships every 30 seconds, synchronously parsing communication protocol headers to extract protocol type, interaction frequency, and port status. Link latency and packet loss rate are calculated every minute, forming data in the format of "Link Identifier - Signal Type - Feature Value - Time". At the electrical layer, the edge controller's electrical quantity acquisition interface collects power flow direction, voltage phase difference, branch and total power data differentiated by device type, synchronously calculating power balance deviations and generating data in the format of "Topology Node ID - Electrical Parameter - Value - Timestamp", ensuring real-time capture of electrical characteristic signals.

[0052] Step S1443: Establish a multi-dimensional threshold configuration library, set the initial threshold for each signal type, support user-defined thresholds, and automatically optimize the thresholds based on historical data to form a dynamic threshold update table; A multi-dimensional threshold configuration library is established, with initial thresholds set according to signal type: For the device layer, communication interruption exceeding a set time is considered offline, and ID addition / deletion triggers the process directly; for the link layer, IP / MAC mapping changes ≥1, interaction frequency mutations exceeding a set proportion, and latency exceeding a threshold trigger the process; for the electrical layer, power flow reversal lasting longer than a set time, voltage phase difference mutations exceeding a set angle, and power deviation exceeding a set proportion trigger the process. Threshold configuration allows users to customize the effective range and values ​​through a visual interface to meet individual needs. Simultaneously, the module automatically optimizes thresholds monthly based on historical topology change data and abnormal event logs: adjusting the offline judgment time by statistically analyzing device communication stability, correcting the interaction frequency mutation threshold based on link fluctuations, and optimizing the power deviation threshold by combining electrical parameter fluctuation patterns, forming a dynamic threshold update table that automatically takes effect, improving threshold adaptability and trigger accuracy, and reducing false triggers and missed triggers.

[0053] Step S1444: Compare the collected multi-dimensional signals with the corresponding thresholds. When the triggering conditions are met, integrate the relevant information to generate a topology change event. Avoid duplicate processing by using built-in deduplication logic. The threshold configuration unit compares the collected multi-dimensional signals with the corresponding thresholds in real time, and pushes a signal to the event generation unit when the triggering conditions are met. The event generation unit integrates device association information and signal feature data, and generates a topology change event in the format of "Event ID-Event Type (Device Addition / Deletion / Link Change / Electrical Topology Change)-List of Affected Device IDs-Change Characteristics-Trigger Time-Threshold Type". Built-in event deduplication logic is used, setting a 30-second time window to merge events of the same type triggered by the same device within the window, retaining the first trigger time and complete feature data to avoid redundant processing and consuming edge-side resources. After event generation, it is immediately pushed to the incremental inference unit, while simultaneously caching event data locally to ensure subsequent traceability and synchronization needs. The event format is standardized to adapt to the edge-cloud collaborative communication mechanism.

[0054] Step S1445: After receiving the topology change event, filter the multi-dimensional feature data of the devices involved to form an incremental inference dataset, call the edge-side lightweight GNN model to perform incremental inference, and output the topology association confidence and hierarchical adjustment suggestions. After receiving a topology change event, the incremental inference unit filters multi-dimensional feature data (electrical features, link features, and device attribute features) involving the devices. It extracts only the feature vectors of the changed devices and directly related nodes in the historical topology map to construct an incremental inference dataset, avoiding the resource consumption of full-data inference. A lightweight GNN model is invoked on the edge side, inputting the adjacency matrix fragments of the incremental inference dataset and the current local topology map. The model focuses on inferring the topological relationships of the changed devices, avoiding redundant calculations of unchanged nodes. The model outputs updated inter-node association confidence and topology node hierarchy adjustment suggestions. The inference process is strictly controlled within 50ms to ensure low-latency processing on the edge side, meeting the real-time response requirements for topology changes. Technicians can optimize the balance between latency and accuracy by adjusting the model's inference parameters.

[0055] Step S1446: Based on the model inference results, filter valid associations according to confidence level, process newly added, deleted and topologically changed devices respectively, and update the node, edge information and correlation matrix of the local topology graph; The model update unit receives the inference results from the lightweight GNN model and filters valid associations based on "association confidence ≥ 0.9". For newly added devices, corresponding nodes are added to the local topology graph, and device feature data and associations are entered; for deleted devices, nodes are marked as "invalid" while retaining historical association records; for devices with changed topology relationships, the edge attributes between nodes (association confidence, connection type) are updated. The adjacency matrix and node feature matrix of the topology graph are updated synchronously to ensure consistency between matrix data and node / edge information, guaranteeing the accuracy of subsequent inference and queries. The entire update process optimizes computational logic, avoids redundant operations, and strictly controls update time to within 1 second, ensuring that the topology graph can quickly reflect the actual changes in devices and links, laying the foundation for ontology model updates and data synchronization.

[0056] Step S1447: Based on the updated local topology map, extract the topology ownership change information, update the topology attributes of the corresponding ontology instance, instantiate ontology classes for newly added devices and bind relevant attributes, mark the ontology instance status for deleted devices, and generate change logs. Based on the updated local topology map, the model update unit automatically extracts the topology affiliation change information for devices / measurement points. For devices / measurement points with changed topology relationships, the attributes of the corresponding ontology instance, such as "belonging topology node ID," "topology level," "parent topology node ID," and "loop number," are modified. For newly added devices, the corresponding ontology class (such as electrical equipment class or energy storage equipment class) is instantiated according to the device type, topology attributes and physical attributes are bound, and the data is entered into the edge-side ontology database. For deleted devices, the ontology instance status is marked as "invalid," and the attribute data is retained for traceability. After the update is completed, a change log is generated in the format of "ontology instance ID - changed attribute - old value - new value - update time." The log is stored locally in a structured manner, which supports subsequent traceability and provides a complete change record for edge-cloud synchronization, ensuring the real-time consistency between the ontology model and the topology map.

[0057] Step S1448: According to the edge-cloud collaborative communication strategy, encapsulate the topology change events, incremental topology map data and ontology model change logs into standardized data, push them to the cloud using the specified communication protocol, and configure synchronization trigger rules, local caching and breakpoint resume mechanism. The data synchronization unit, following an edge-cloud collaborative communication strategy, encapsulates topology change events, incremental topology graph data (containing only changed node / edge information), and ontology model change logs into standardized JSON format data, strictly controlling the size of a single data entry to within 1KB to reduce communication bandwidth consumption. It uses the MQTT 5.0 protocol to push data to the cloud, with synchronization trigger rules set according to the scenario: topology change events are pushed immediately after generation, with a latency of ≤5s; batch change data is pushed out every 5 minutes, balancing real-time performance and communication efficiency. On the edge side, data to be synchronized is persistently cached using Redis, recording the data synchronization status (pending push / pushed / confirmed). Unsynchronized data is automatically cached during network interruptions, and resumed transmission based on the cached status after network recovery. Synchronized data carries the edge node ID, data type identifier, and timestamp, facilitating cloud-based differentiation of data sources and types for accurate integration.

[0058] Step S1449: The built-in module runs the monitoring logic, monitors the running status of each sub-module in real time, records the running log, marks various abnormal situations and pushes alarms, triggers the retry mechanism, and periodically verifies the consistency between the local topology map and the ontology model and triggers incremental updates.

[0059] The system records the signal acquisition success rate of the acquisition submodule, the threshold comparison accuracy of the threshold configuration unit, the model inference latency of the incremental inference unit, and the success rate of map and ontology updates of the model update unit in the format of "time-submodule-metric value-status". When anomalies such as acquisition failure (no signal acquisition for 3 consecutive times), inference timeout (more than 50ms), or update failure occur, the system automatically marks the anomaly type (acquisition anomaly / inference anomaly / update anomaly), pushes it to the edge-side operation and maintenance panel, and triggers the retry mechanism: 3 retries for acquisition failure, re-calling the model for inference timeout, and rollback to the pre-update state for update failure. The system periodically (daily) verifies the consistency between the local topology map and the ontology model by comparing node IDs, topology attributes, and relationships. Inconsistencies are automatically triggered to ensure stable module operation and data accuracy.

[0060] Step S145: Build a global data lake in the cloud, aggregate multiple types of data from the edge side and classify and store them to form a global optimized dataset. Analyze the dataset regularly to locate high-frequency error types. Optimize semantic rules based on the analysis results, incrementally train semantic association models and topology recognition models, and encapsulate the optimized rules and parameters into incremental update packages and distribute them to the edge side in a differentiated manner. A unified data lake is built in the cloud, employing a distributed storage architecture. It aggregates semantic verification anomaly logs, topology change data, and algorithm inference deviation data uploaded from all edge nodes, storing them categorized by "time-edge node-anomaly type" to form a globally optimized dataset. The cloud analyzes this dataset daily: calculating semantic matching error rates and topology recognition deviation rates; analyzing the distribution characteristics of anomaly data (e.g., incorrect mapping of non-standard physical quantity names from a manufacturer, low accuracy in topology association recognition for a certain type of equipment); and identifying high-frequency error types and their root causes. Based on the analysis results, semantic rules are optimized: adding or updating semantic dictionary entries, adjusting semantic matching thresholds; performing incremental training on the semantic association model and GNN topology recognition model, freezing bottom-level parameters and fine-tuning only top-level parameters, incorporating edge-side deviation data into the training set, and optimizing model weights and loss function coefficients. The optimized rules and parameters are packaged into incremental update packages and distributed differentiatedly according to edge node type (e.g., only pushed to high-frequency error nodes) to improve the targeting of optimization.

[0061] Step S146: The cloud integrates all edge node topology change events to construct a global physical association graph and performs consistency verification. When the preset triggering conditions are met, the global reconstruction of the ontology model is initiated, including updating the ontology structure, instance data and model verification. The reconstructed ontology model is split into incremental packages according to the jurisdiction of the edge nodes and distributed to the corresponding edge side. The cloud integrates all topology change events reported by edge nodes to construct a global physical relational graph. Through cross-edge node data fusion, it verifies the consistency of cross-regional topology relations (such as cross-regional bus power supply relationships), resolving topology fragmentation issues caused by local perspectives on the edge side. Consistency checks are performed on the global graph, verifying logic such as the sum of branch power ≤ total power and no closed loops in device topology levels. Conflict items are marked and pushed to the global operations and maintenance end for manual confirmation. The trigger conditions for global ontology model reconstruction are set as follows: a single batch of topology change events covering ≥10% of devices, a major monthly semantic rule update, and the addition of new device categories / topology types. The reconstruction process includes: updating the ontology structure (adding / deleting classes, extending attributes, adjusting relationships), updating instance data (mapping the global graph and optimizing rules), and model verification (inference engine detection of conflicts, verification of coverage and query efficiency). After reconstruction, incremental packages are split according to the jurisdiction of edge nodes, and only ontology change items for the corresponding nodes are issued. The edge side receives these and overwrites the corresponding local entries.

[0062] Step S147: Establish a closed-loop and consistency guarantee mechanism for edge-cloud collaboration, assign unique version numbers to semantic rules, algorithm models, and ontology models and maintain a version library, set conflict resolution rules, deploy a monitoring panel in the cloud to monitor the edge-cloud collaboration operation status in real time, set alarm rules and trigger corresponding alarms. The edge-cloud collaboration closed-loop and consistency guarantee mechanism covers five core aspects: version management, conflict resolution, operation monitoring, alarm handling, and continuous iteration. The mechanism assigns unique version numbers to semantic rules, algorithm models, and ontology models, constructs a global version repository in the cloud and a lightweight local version repository on the edge, and ensures version baseline consistency through scheduled synchronization; it sets three-layer conflict resolution priorities and formulates processing logic for different scenarios to ensure reasonable conflict resolution; it deploys a multi-dimensional monitoring panel in the cloud to monitor edge-cloud data synchronization, model / rule consistency, edge-side operation status, and resource consumption in real time; it classifies alarm levels according to severity and configures multiple types of trigger conditions and response mechanisms; and it conducts comprehensive analysis based on monitoring data and logs monthly to optimize version rules, conflict priorities, monitoring indicators, and alarm conditions, forming a closed-loop iterative process of "monitoring-analysis-optimization-verification" to continuously improve the consistency and stability of edge-cloud collaboration.

[0063] Step S1471: Establish a unified version number naming convention, assign globally unique version numbers to semantic rules, algorithm models, and ontology models, and record version update-related metadata; A unified version number naming convention is established to assign globally unique version numbers to semantic rules, algorithm models, and ontology models. The format includes "Edge Node ID - Object Type Identifier - Date - Iteration Sequence Number," where the object type identifier is Semantic Rule = SR, Algorithm Model = AM, and Ontology Model = OM, respectively. The version number not only distinguishes different versions but also links to complete version metadata, recording the reason for the version update (e.g., rule optimization, model iteration, new feature addition), update scope (e.g., system-wide / specific device type / specific protocol), operator information, and update timestamp, forming a version management archive. Metadata is stored in association with version files, supporting quick lookup of the corresponding update background and scope by version number. This provides a basis for version backtracking, conflict resolution, and iterative optimization, ensuring that every version update is traceable and auditable.

[0064] Step S1472: Build a cloud-based global version repository and an edge-side local lightweight version repository. Store corresponding version data according to object type and support version backtracking and difference comparison functions. Synchronize version metadata periodically through the edge-cloud collaborative communication protocol to verify and ensure the baseline consistency of the edge-cloud version repository. A hierarchical storage architecture is formed by constructing a global version control repository in the cloud and a lightweight local version control repository on the edge. The global version control repository in the cloud adopts distributed storage and stores data according to object type (semantic rules, algorithm models, ontology models): semantic rules store rule entries, matching thresholds, etc.; algorithm models store weight files, hyperparameter configurations, and inference logic; and ontology models store ontology structure and instance data changes. The global version control repository supports version rollback (restoring to any historical version) and difference comparison (comparing core changes between different versions). The lightweight local version control repository on the edge only stores the currently effective version and the three most recent historical versions, reducing the storage pressure on the edge. Through the edge-cloud collaborative communication protocol, the edge synchronizes local version metadata to the cloud every hour. The cloud verifies the consistency between the metadata and the global version control repository, returns version difference information, and the edge downloads incremental update packages as needed, ensuring the baseline consistency between the edge and cloud version control repositories.

[0065] Step S1473: Define the version lifecycle status. The global version lifecycle is managed uniformly by the cloud, and the local version status on the edge side is updated synchronously with the cloud. It supports the temporary effect of local modified versions in emergency scenarios and the initiation of review requests to the cloud. The version lifecycle is defined into four states: Draft (not yet effective, in the editing stage), Effective (currently in use), Obsolete (replaced by a new version and no longer used), and Archived (historical version, retained for traceability). The cloud centrally manages the global version lifecycle. Changes to version status are made through the version management platform, and the local version status on the edge is automatically synchronized to the cloud and cannot be modified without authorization. Only in emergency scenarios (such as emergency adjustments for device failures or temporary changes to security thresholds) is the edge side allowed to mark the local modified version as "temporarily effective" and automatically initiate a version review request to the cloud, uploading materials such as the reason for the correction, the scope of impact, and test data. If the cloud review is approved, the version is added to the global version repository and updated to the "effective" status; if the review fails, it is rejected, and the edge side automatically rolls back to the previous effective version.

[0066] Step S1474: Set the three-layer conflict resolution priority, formulate conflict handling logic for semantic rules, algorithm model, and ontology model scenarios, retain the corresponding version according to priority and record conflict differences or mark local extended attributes; The first layer is the local emergency correction version on the edge side, with the highest priority. It is suitable for scenarios such as emergency adjustments for device failures and temporary changes to security thresholds. After taking effect, it is synchronized to the cloud for filing and subsequently incorporated into global rule optimization. The second layer is the cloud-based globally optimized version, verified by multiple edge nodes, with the next highest priority. It is used to cover non-emergency correction versions on the edge side. The third layer is the system default version, with the lowest priority, and is only enabled when no effective version is available. Processing logic is defined for different scenarios: for semantic rule conflicts, core content is compared, and rules with higher priority are retained while recording differences; for algorithm model conflicts, inference accuracy and bias rate are used as the basis, prioritizing the version with better performance; for ontology model conflicts, the cloud version is used by default, and custom attributes on the edge side are marked "local extension" and retained to avoid attribute loss, ensuring that conflict resolution guarantees consistency without omitting key data.

[0067] Step S1475: Construct a multi-dimensional monitoring indicator system covering data synchronization status, model / rule consistency, edge-side operation status, and resource usage. Develop a cloud-based monitoring panel using a microservice architecture, supporting real-time data refresh, multi-dimensional filtering, visualization, and custom monitoring view functions. Data synchronization status (synchronization success rate, latency, amount of unsynchronized data, number of breakpoint resume attempts), model / rule consistency (version consistency compliance rate, number and type of conflict events), edge-side operational status (semantic verification accuracy, topology update latency, inference time, correction success rate), and resource usage (edge-side CPU / memory usage, model inference resource consumption, and communication bandwidth usage). A cloud-based monitoring panel is developed using a microservice architecture, with each monitoring dimension corresponding to an independent microservice, supporting horizontal scaling. Panel features include: real-time data refresh (refresh frequency ≤ 5 seconds), multi-dimensional filtering (by edge node, time range, object type), data visualization (line charts, pie charts, lists), and customizable monitoring views (users can combine metrics as needed). It adapts to different operational scenarios such as global maintenance, edge node management, and fault diagnosis, allowing operations personnel to intuitively grasp the edge-cloud collaborative operational status.

[0068] Step S1476: Deploy a monitoring data collection agent on the edge side to collect and encapsulate local operating indicator data and push it to the cloud in batches; deploy a data aggregation service on the cloud to clean and standardize the received monitoring data before storing it, supporting fast query and statistical analysis; A lightweight monitoring data acquisition agent is deployed at the edge, with a size ≤50MB, minimizing edge resource consumption. The acquisition agent collects local operational metrics in real time, including semantic verification logs, topology update logs, model inference performance data, and resource usage statistics. Data is packaged in the format of "metric type-value-collection time-edge node ID" and pushed to the cloud in batches every 30 seconds, balancing real-time performance with communication overhead. A data aggregation service is deployed in the cloud to receive monitoring data from all edge nodes and perform preprocessing: deduplication (removing duplicate data based on data identifiers), outlier removal (removing obviously abnormal metric values ​​using the 3σ criterion), and standardization (unifying metric units and formats). The processed monitoring data is stored in a time-series database, supporting quick querying and statistical analysis by metric type, time range, and edge node ID, providing data support for monitoring dashboard display, alarm triggering, and iterative optimization.

[0069] Step S1477: Classify alarm levels according to severity and configure corresponding response mechanisms. Set trigger conditions for multiple types of alarms, including threshold triggering, trend triggering, and event triggering. Support visual configuration and modification of alarm rules. Emergency alarms (synchronization success rate <99%, ontology model conflicts >3, resource utilization exceeding 90%) are pushed in real-time to the operations and maintenance personnel's mobile app and via SMS, triggering voice alerts, requiring a response within 15 minutes. Important alarms (semantic validation error rate >5%, topology update latency exceeding 5 seconds, version consistency compliance rate <95%) are pushed to the platform alarm center and via email, requiring a response within 1 hour. General alarms (single synchronization failure, minor resource fluctuations) are only marked on the monitoring panel, with daily summary logs pushed. Alarm triggering conditions support three types: threshold triggering (e.g., synchronization latency exceeding 10 seconds), trend triggering (e.g., error rate increasing continuously for 30 minutes), and event triggering (e.g., conflict events occurring). Alarm rules can be visually configured and modified through the monitoring panel. Users can customize alarm thresholds, triggering conditions, and notification methods to adapt to different operations and maintenance management needs.

[0070] Step S1478: Establish an alarm handling process, with maintenance personnel marking the handling status and entering the solution. The system automatically associates relevant data to assist in locating the root cause of the problem, regularly analyzes alarm logs, and optimizes alarm rules, conflict resolution logic, and edge-cloud synchronization strategies. After receiving an alarm, operations and maintenance personnel mark its processing status (unprocessed / processing / resolved) on the monitoring panel and enter the processing plan and results. The system automatically associates the alarm with the corresponding operation logs, version information, and data synchronization records to help operations and maintenance personnel locate the root cause of the problem (such as synchronization failure due to version conflicts, or false alarms due to unreasonable thresholds). Alarm logs are analyzed regularly (weekly): high-frequency alarm types, number of repeated alarms, and alarm processing time are statistically analyzed to identify invalid alarms (such as frequent alarms caused by overly strict thresholds) and potential risks (such as a continuous increase in a certain type of conflict event). Based on the analysis results, alarm rules are optimized (thresholds are adjusted, repeated alarms are merged), conflict resolution logic is improved (targeted processing rules are added), and edge-cloud synchronization strategies are optimized (synchronization cycles are adjusted) to reduce the invalid alarm rate and improve problem response and resolution efficiency.

[0071] Step S1479: Conduct comprehensive analysis monthly based on monitoring data, alarm logs, and version update records to optimize version number rules, conflict priorities, monitoring indicator systems, and alarm triggering conditions, forming a closed-loop iterative process of monitoring, analysis, optimization, and verification to continuously improve edge-cloud collaboration consistency and stability.

[0072] Analyze the effectiveness of version management strategies (e.g., whether version update frequency is reasonable and conflict occurrence rate is controllable), the rationality of conflict resolution rules (e.g., whether priority settings are suitable for actual scenarios and whether conflict handling omissions data), the comprehensiveness of monitoring metrics (e.g., whether they cover key operational processes), and the suitability of alarm triggering conditions (e.g., whether thresholds are reasonable and alarm level classifications are accurate). For identified issues (e.g., frequent occurrence of certain types of conflicts, alarm thresholds leading to missed alarms), develop optimization plans: adjust version number rules, optimize conflict priorities, supplement monitoring metrics, and correct alarm triggering conditions. After implementing the optimization plans, verify the effects through subsequent operational data, forming a closed-loop iterative process of "monitoring-analysis-optimization-verification" to continuously improve the consistency, stability, and operational efficiency of edge-cloud collaboration.

[0073] Step S148: Conduct functional verification and performance verification, simulate various scenarios to verify the real-time performance of semantic verification, the timeliness of topology updates, the accuracy of ontology model data query, and the collaborative operation efficiency in large-scale scenarios. Based on the operation logs, continuously iterate and optimize the communication synchronization strategy, algorithm training frequency, and ontology reconstruction trigger threshold.

[0074] The system verifies the real-time performance of semantic verification (≤100ms), the timeliness of topology updates (≤5s), the accuracy of ontology model data query (≥98%), and the success rate of abnormal data correction by adding or deleting edge devices, handling communication interruptions and recovery, integrating non-standard protocols, and mitigating topology changes. Performance verification simulates a large-scale application scenario with 100+ edge nodes and 10,000+ devices, verifying cloud data aggregation efficiency (≤10 minutes), algorithm model incremental training time (≤1 hour), ontology model reconstruction time (≤30 minutes), and edge-cloud data synchronization success rate (≥99.9%). Based on the verification results and runtime logs, continuous iterative optimization is performed: adjusting communication synchronization strategies (e.g., batch push cycle), optimizing algorithm incremental training frequency (e.g., from daily to every two days), and correcting ontology reconstruction trigger thresholds (e.g., adjusting device coverage ratio thresholds). This aims to reduce resource consumption and improve collaborative operation efficiency in large-scale scenarios while ensuring functional effectiveness.

[0075] Step S150: Introduce cross-protocol data middleware, define a unified data interaction standard, shield the differences in underlying protocols, and achieve high-precision synchronization of edge-cloud clocks through the PTP protocol; A cross-protocol data middleware is introduced to achieve the core functionality of masking underlying protocol differences and ensuring high-precision synchronization of edge and cloud clocks. The middleware adopts a pluggable architecture, with built-in adapters for energy self-control protocols such as Modbus, OPCUA, and BACnet, supporting hot-swappable expansion. Through a unified data interaction standard (defining core fields such as "protocol identifier-device ID-physical quantity type-value-timestamp"), it converts heterogeneous protocol data into a standardized structure, masking differences in protocol message formats and register address mappings. Clock synchronization is based on the PTPv2 (IEEE1588-2008) protocol. A PTP slave clock module is deployed at the edge, periodically (every 10ms) exchanging time synchronization messages with the cloud PTP master clock. Through delay measurement and timestamp calibration algorithms, the edge-cloud clock deviation is controlled within ±1μs. The middleware has built-in clock synchronization verification logic to monitor synchronization deviation in real time. When the deviation exceeds a threshold (>5μs), resynchronization is triggered. It also supports the NTP protocol as a backup synchronization scheme to ensure clock consistency in extreme network environments, providing a foundation for edge-cloud data timing alignment and accurate correlation of topology change events.

[0076] Step S160: Integrate multimodal information to enhance the ontology model, realize the binding of data such as operation and maintenance logs and fault codes with topology nodes, and support model visualization and data traceability.

[0077] Step S161: Identify the sources of multimodal data, develop standardized acquisition protocols, and perform structured encapsulation and preprocessing on the acquired multimodal data to ensure that the data format is uniform and parseable; We systematically analyzed and standardized the sources of multimodal data to ensure a unified and parsable data format. Data sources included maintenance logs (edge-side maintenance interfaces, work order management systems), fault codes (equipment alarm system APIs, IEC61850 standard encoding mapping), equipment manuals (PDF / Word format), and nameplate images (JPG / PNG format). A standardized data collection protocol was established, encapsulating data according to the fields "Data Type - Associated Equipment ID - Generation Time - Core Content - Data Format - Source Identifier." Maintenance logs extracted key fields such as fault descriptions and handling measures; fault codes were mapped to industry-standard encodings; and unstructured data (such as log details and nameplate images) underwent preprocessing: text data was converted to structured text through jieba segmentation and stop word removal; and images were extracted using OCR recognition (using a finely tuned YOLOv8+CRNN model). All data was ultimately standardized into a JSON format with source annotations, and stored only after passing field integrity checks to ensure data compatibility in subsequent binding and modeling stages.

[0078] Step S162: Expand the structure based on the existing ontology model, add new ontology classes, attributes and ontology relations related to multimodal information, clarify the domain and value range of the relations, and use a specified ontology description language to extend them, ensuring compatibility with the original model attributes; The structure is expanded based on the existing ontology model, adding new ontology classes and relationships related to multimodal information while ensuring compatibility with existing attributes. The new ontology classes include "Operation Log Class," "Fault Code Class," and "Multimodal Data Association Class": the "Operation Log Class" contains attributes such as log ID, fault description, and handling plan; the "Fault Code Class" contains attributes such as fault code ID, standard code, and fault level. Both classes define data type constraints (e.g., string, integer) and cardinality restrictions (e.g., unique log ID). New ontology relationships are added: "Topology Node - Contains - Operation Log," "Topology Node - Association - Fault Code," and "Fault Code - Corresponds to - Operation Log." The domain of these relationships is explicitly defined as the "Topology Node Class," and the value domain is the corresponding multimodal information class. The ontology extension files are written using the OWL2DL language, and the logical consistency between the extended structure and the original topology attributes and physical constraint attributes is verified using a Pellet inference engine. After ensuring no conflicts, the extended structure is integrated into the existing ontology model without affecting the querying and use of historical data.

[0079] Step S163: Construct a dual-mode intelligent binding engine that combines automatic binding and manual binding. It realizes the association between multimodal data and topology nodes through semantic matching and logical reasoning. It has built-in binding verification logic, marks data that fails the verification and pushes it for review. A dual-mode intelligent binding engine combining automatic and manual methods is constructed to achieve accurate association between multimodal data and topology nodes. Automatic binding is achieved through a dual mechanism: extracting device IDs and topology node identifiers (loop number, device name) from multimodal data, calculating semantic matching similarity using a dynamic semantic self-alignment engine, and generating binding confidence based on electrical logic reasoning (e.g., associating branch loop fault codes with corresponding branch nodes). Association is automatically established when the confidence level is ≥0.9. For data without explicit identifiers, binding is based on generation time, fault impact range, and topology connection relationships. Manual binding provides a visual interface, allowing maintenance personnel to select topology nodes and upload associated data. Batch import of the "Topology Node ID - Multimodal Data ID - Binding Type" relationship table is supported, and the system records the operator and binding time. Built-in binding verification logic verifies whether the associated device belongs to the topology node's jurisdiction and whether the fault impact range matches the topology level. If the verification fails, it is marked "Pending Review" and pushed to the maintenance end to ensure binding accuracy.

[0080] Step S164: Design a hybrid storage architecture to store structured and unstructured multimodal data separately, build a joint index for cross-storage retrieval, and support reverse data queries based on topology nodes; A hybrid storage architecture is designed to balance the efficiency of multimodal data storage and the flexibility of querying. Structured data (fault code attributes, key fields in operation and maintenance logs, and binding relationships) is stored in an RDF4J ontology database on the edge and a Stardog database in the cloud, with SPARQL statements used to optimize the efficiency of join queries. Unstructured data (complete operation and maintenance logs, nameplate images, and video frames) is stored in MinIO on the edge and an object storage service in the cloud, with a unique association established between the "multimodal data ID" and the ontology instance. A cross-storage composite index is built, integrating topology node IDs, multimodal data IDs, and key attributes (fault level, log time), supporting reverse queries of related multimodal data by topology node. During the query process, the index quickly locates structured data and then retrieves unstructured data, with a response time controlled within 1 second. Data within the local jurisdiction is stored on the edge, and full backups are stored in the cloud. New data is added to the edge and cloud on an hourly basis, ensuring data security and accessibility.

[0081] Step S165: Develop a layered visualization display system that provides visualization and interactive functions for the topology map layer, multimodal data layer, and relationship layer, adapts to multi-terminal display, and supports offline caching; Develop a hierarchical visualization system to enable intuitive interaction between topology and multimodal data. The system consists of three interfaces: the topology map layer uses D3.js to draw a hierarchical topology map, with node colors mapping to fault levels (red = high risk, yellow = moderate, green = normal). Hovering the mouse displays the three most recent maintenance logs and the number of currently active fault codes. The multimodal data layer expands the side panel by clicking on a node, displaying data categorized as "Maintenance Logs," "Fault Codes," and "Extended Data." It supports filtering by time range and data type, and fault codes can be linked to corresponding solutions. Maintenance logs provide a complete processing flow. The relationship layer uses ECharts to draw a "Topology Node - Fault Code - Maintenance Log" relationship graph, supporting drag-and-drop zooming and node highlighting to intuitively present the data traceability chain. The system is compatible with both web and mobile devices, employing a responsive design to automatically adjust the interface layout. It supports offline caching of visualized data (stored via IndexedDB), allowing local viewing when there is no network at the edge, and automatic synchronization and updates after network recovery.

[0082] Step S166: Construct a full-link data traceability mechanism, establish a traceability metadata system, develop a multi-dimensional traceability query engine, and display the traceability results in a visual form to ensure that the entire data flow is traceable; A full-link data traceability mechanism is constructed to ensure the traceability of multimodal data flow throughout the entire process. A traceability metadata system is established to record the binding method (automatic / manual), binding time, operator, data source channel, and version number for each binding relationship. Multimodal data itself carries generated link logs (collection time, transmission nodes, preprocessing steps). A multi-dimensional traceability query engine is developed, based on Elasticsearch for fast retrieval, supporting three query dimensions: querying historical associated fault codes and maintenance records by topology node, querying involved topology nodes and processing trajectories by fault code, and reversing the fault evolution process of associated topology nodes by maintenance logs. Traceability results are displayed in a "timeline + association graph" format, marking key nodes such as fault occurrence, processing completion, and topology changes, and supporting the viewing of raw data and processing logs for each stage. The system is configured with traceability integrity verification, requiring historical data coverage ≥99% to ensure auditability throughout the data lifecycle.

[0083] Step S167: Establish a binding rule optimization library, optimize binding rules based on feedback, support multimodal data type expansion, and regularly update relevant mapping libraries and keyword dictionaries to improve automatic binding adaptability; Establish a binding rule optimization library to continuously improve the adaptability and accuracy of automatic binding. The optimization library integrates binding logs (automatic binding accuracy, misbinding scenarios) and operation and maintenance feedback data. For high-frequency misbinding scenarios (such as cross-node device ID confusion, non-standard fault code mapping deviation), it adjusts semantic matching weights (such as increasing topology-level matching weights) and supplements exclusive binding rules (such as associating certain types of device fault codes only with specific topology nodes). It supports multimodal data type expansion, reserving adaptation interfaces for data such as device infrared thermal imaging images and voice alarm records. When adding new data types, only the corresponding ontology class attributes and binding verification rules need to be expanded; no modification to the core architecture is required. The fault code standard mapping library and operation and maintenance log keyword dictionary are updated regularly (monthly), incorporating new heterogeneous expressions (such as vendor-defined fault descriptions) into the semantic dictionary. The semantic matching model is optimized through incremental training to ensure that the automatic binding accuracy improves by ≥5% monthly.

[0084] Step S168: Integrate the multimodal enhanced ontology model with the edge-cloud collaborative architecture, synchronize relevant metadata to the cloud, conduct functional verification, and optimize the binding engine and visualization interaction logic based on the verification results.

[0085] The multimodal enhanced ontology model is integrated with an edge-cloud collaborative architecture to achieve data synchronization and continuous optimization. During integration, the edge-cloud communication module is connected via the gRPC protocol. The edge side pushes binding relationships, traceability metadata, and binding logs to the cloud according to an incremental synchronization strategy. The cloud integrates multimodal data across edge nodes and updates the global ontology model. Functional verification covers three scenarios: automatic binding accuracy testing (target ≥95%), traceability query completeness testing (target ≥99%), and visual interaction response speed testing (node ​​click loading ≤1s). These tests simulate real-world scenarios such as fault code triggering, maintenance log association, and topology node changes to verify model stability. Based on the verification results and user feedback, the semantic matching algorithm of the binding engine is optimized (e.g., adjusting the confidence threshold) and the interaction logic of the visual interface is improved (e.g., adding batch binding functionality), establishing a closed loop of "verification-analysis-optimization-verification" to adapt to the expansion of multimodal data types in the energy system and changes in business requirements.

[0086] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of the structure of an energy self-control platform multi-source data fusion and collaborative control system 100 for executing the above-described energy self-control platform multi-source data fusion and collaborative control method, provided in an embodiment of this application. The energy self-control platform multi-source data fusion and collaborative control system 100 may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0087] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located within the multi-source data fusion and collaborative control system 100 of the energy self-control platform and are separately configured. However, it should be understood that the machine-readable storage medium 120 may also be independent of the multi-source data fusion and collaborative control system 100 of the energy self-control platform and may be accessed by the processor 130 via a bus interface. Alternatively, the machine-readable storage medium 120 may also be integrated into the processor 130 and may communicate and interact with external systems through the communication unit 110.

[0088] The processor 130 is the control center of the multi-source data fusion and collaborative control system 100 of the energy self-control platform. It connects various parts of the entire multi-source data fusion and collaborative control system 100 via various interfaces and lines. By running or executing software programs and / or modules stored in the machine-readable storage medium 120, and by calling data stored in the machine-readable storage medium 120, it performs various functions and processes data of the multi-source data fusion and collaborative control system 100, thereby providing overall monitoring of the energy self-control platform multi-source data fusion and collaborative control system 100. Optionally, the processor 130 may include one or more processing cores; for example, the processor 130 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the aforementioned modem processor may also not be integrated into the processor. The machine-readable storage medium 120 is used to store machine-executable instructions for executing the scheme of this application, and the processor 130 is used to execute the machine-executable instructions stored in the machine-readable storage medium 120 to realize the multi-source data fusion and collaborative control method of the energy self-control platform provided in the aforementioned method embodiment.

[0089] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

[0090] The embodiments of this application have been described above with reference to the accompanying drawings. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. This application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for multi-source data fusion and collaborative control of an energy self-control platform, characterized by: Includes the following steps: A dynamic semantic self-alignment engine is built, which uses NLP and deep learning to realize physical quantity unit conversion, definition normalization and automatic point mapping, and supports user-defined rule completion and deviation correction. Develop an automatic topology recognition algorithm, construct a physical association map based on multi-dimensional information from the edge side and GNN, and realize automatic binding of measurement points and topology nodes and initialization of CAD drawings; A three-layer ontology modeling framework is built, and through modular protocol adaptation, semantic normalization and topological association, device constraints and characteristics are embedded to construct an energy ontology model with topological affiliation and physical attributes. Deploy a semantic verification and topology update mechanism for edge-cloud collaboration to achieve real-time data correction, algorithm parameter optimization, and dynamic reconstruction of the ontology model after device / topology changes; By introducing cross-protocol data middleware, defining a unified data interaction standard, shielding the differences in underlying protocols, and achieving high-precision synchronization of edge-cloud clocks through the PTP protocol; The ontology model is enhanced by integrating multimodal information, enabling the binding of data such as operation and maintenance logs and fault codes with topology nodes, and supporting model visualization and data traceability.

2. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 1, characterized in that: The aforementioned construction of a dynamic semantic self-alignment engine utilizes NLP and deep learning to achieve physical quantity unit conversion, definition normalization, and automatic point mapping. It supports user-defined rule completion and deviation correction, including: A basic resource layer is built, and a structured semantic dictionary containing standard information on physical quantities is constructed for all types of energy self-control protocols. At the same time, nameplate OCR recognition rules and field extraction templates are formulated according to equipment categories, and a nameplate parsing template library is constructed. Collect unstructured data from equipment manuals, protocol documents, and nameplate images; preprocess the text and nameplate data separately; and standardize all data into JSON format with source annotations. Based on the fine-tuned BERT model, NER and RE models were constructed, and semantic entities related to physical quantities were extracted and associated. A sufficient labeled dataset was constructed by combining manual annotation, and the training / validation / test sets were divided in an 8:1:1 ratio. Extract multi-dimensional features of physical quantities, build a dual-tower deep learning model and embed unit conversion and define normalization rules to complete model training optimization and lightweight processing, and adapt to edge deployment requirements. The interface protocol access layer obtains raw location data, completes semantic matching through a deep learning model, automatically performs unit conversion and definition normalization on the qualified data, and generates a standardized location mapping table. Develop a visual custom rule configuration interface, detect mapping deviations in real time, correct model weights through incremental learning, set rule priorities, and incorporate high-frequency custom rules into the semantic dictionary library for iteration; Perform multi-dimensional real-time semantic verification on normalized data, issue graded alarms for anomalies, record and analyze full-process logs, and iteratively update the semantic dictionary and deep learning model on a periodic basis to achieve closed-loop optimization.

3. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 2, characterized in that: The process of extracting multi-dimensional features of physical quantities, building a dual-tower deep learning model and embedding unit conversion and defining normalization rules, completing model training optimization and lightweight processing, and adapting to edge deployment requirements includes: Based on a pre-trained language model adapted to the energy field, semantic features of physical quantities are extracted. Dynamic context encoding is introduced to compensate for the defects in scene adaptation. At the same time, cross-language physical quantity names are processed to ensure feature consistency. An encoding dictionary and rule system are constructed to extract and normalize the relevant rule features of units, definition dimensions, and associated information. The frequency of occurrence of physical quantities, matching success rate, and matching degree between units and equipment types are statistically analyzed and standardized. After concatenating the three types of features (semantic, rule, and statistical), the features are weighted and focused through an attention mechanism to output a fused feature vector. The original physical quantity tower and the standard physical quantity tower are built. The corresponding fused features are processed and the feature vectors are output using the same network structure. The matching degree between the two is obtained through a similarity calculation layer. A unit conversion submodule is embedded in the model, with built-in industry standard conversion rules, which identify the unit type and calculate the conversion coefficient. Abnormal unit matching cases are marked and similarity trigger conditions are bound. A new definition dimension normalization submodule is added. The original definition dimension is mapped to the standard label through rule matching and semantic similarity verification. The output layer is designed to integrate matching similarity, conversion coefficient, and standard definition dimension label. A built-in logic verification and matching compliance judgment mechanism is included. The training data is augmented and organized into a specified format. The training set, validation set, and test set are divided. A joint loss function including main loss and auxiliary loss is designed. An optimizer is used in combination with learning rate decay strategy and early stopping strategy to train the model. The network structure parameters and training parameters are optimized by grid search. The model performance is verified based on the test set. Structured and unstructured pruning are used to remove redundant parameters from the model. After pruning, the accuracy loss is recovered by fine-tuning. Differential accuracy quantification is performed on different levels of the model. The computation graph is optimized after calibration. The model is compressed and converted into a general format to adapt to different edge hardware architectures. For edge controllers with different architectures, corresponding inference engines are compiled. Multi-threaded inference is adopted and adapted to low-power mode. Physical quantity data and abnormal data under various protocols are input to verify the model's function and performance. Incremental update interfaces are reserved on the edge side, and inference logs are uploaded regularly. The cloud iterates and optimizes the model based on the logs to achieve closed-loop update of edge-cloud collaboration.

4. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 1, characterized in that: The aforementioned automatic topology recognition algorithm, based on multi-dimensional information from the edge side and a GNN to construct a physical association map, enables automatic binding of measurement points to topology nodes and initialization of CAD drawings, including: Based on the differences in equipment type, the electrical operation characteristics of the power distribution side, power consumption side, and energy storage / photovoltaic side are collected. The communication link topology information between equipment, equipment installation location and basic attribute information, original configuration of measurement points and historical correlation records are collected simultaneously. The collected data is stamped with high precision and stored in a structured format. The received electrical drawings are format converted, redundant elements are removed and layers are processed. Electrical components in the drawings are identified and topology node IDs are assigned. The connection relationships between components are extracted to generate an initial topology skeleton diagram. This is then standardized into a graph data structure that can interface with edge data to form an initial topology map. Outlier removal, missing value completion, and standardization are performed on various types of data collected from the edge side. Topological features related to electrical, communication, equipment attributes, and spatial location are extracted. The edge side equipment features are fused with the topological node features analyzed by CAD to form a total feature vector of topological nodes. Construct a graph dataset containing nodes, edges, and association labels. Design a GNN model architecture and input the adjacency matrix and node feature matrix of the graph data. Complete the model training by setting the loss function, optimizer, and training strategy. The model outputs the association confidence between nodes and the topological level label. The edge-side fused features are input into the trained GNN model to infer the device association relationship. The initial physical association map is generated by fusing the initial CAD topology skeleton. Topology conflict items are detected and marked for manual correction. System changes are monitored in real time and incremental model inference is triggered to achieve dynamic updating of the topology map. Extract measurement point features and topology node features for semantic and electrical feature matching, perform batch binding operations according to the set priority binding rules, automatically verify the binding results, and mark those that fail the verification as pending manual review; The GNN model is lightweighted to adapt for edge deployment, and various functional modules are integrated and linked with relevant levels of the energy control platform. Functional verification, performance verification, and abnormal scenario verification are carried out for topology initialization, association graph generation, and measurement point binding. The model and binding rules are continuously iterated and optimized based on error logs during use.

5. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 1, characterized in that: The aforementioned three-layer ontology modeling framework, through modular protocol adaptation, semantic normalization, and topological association, embeds device constraints and characteristics to construct an energy ontology model with topological affiliation and physical attributes, including: Define the overall architecture and interaction logic of the three-layer ontology modeling framework, clarify the functional boundaries of the bottom protocol adaptation layer, the middle semantic unification layer, and the top top topology association layer, design a unified interaction interface and data flow triggering rules between layers, clarify the modules and outputs of each layer, and achieve decoupling between layers and data traceability. Develop pluggable protocol adaptation modules according to protocol type, adopt a plug-in framework to support hot-swapping, define unified input and output interfaces, adapt acquisition strategies for different protocol characteristics, perform integrity verification and invalid data filtering on the acquired data, output structured raw data, and reserve custom protocol adaptation interfaces to expand compatibility. Deploy a lightweight instance of the dynamic semantic self-alignment engine, complete the normalization of physical quantity names, units, and definition dimensions based on the semantic dictionary, encapsulate the normalized data into structured data units and supplement relevant tags, build in semantic consistency verification logic, and establish an edge-cloud semantic rule synchronization mechanism. Based on the physical association graph, topological association rules are defined, semantically normalized data units are bound to topological nodes to embed topological attribution information, an ontology description language is used to construct the topological layer ontology structure and instantiate data units, and topological graph update events are listened to to realize the dynamic update of topological attributes and relationships in the ontology model. The system collects physical constraints and operating characteristics data of equipment from multiple sources and builds a structured library. It adds corresponding ontology classes and attributes to the ontology model, instantiates the constraint and characteristic data to the corresponding equipment ontology instance and establishes the association relationship. It has built-in constraint verification logic and characteristic adaptation algorithm and supports dynamic updates of constraint and characteristic data. According to the ontology specification, instance data at each layer is instantiated and assigned a unique identifier to build a complete energy ontology instance library. An edge-cloud collaborative storage and retrieval solution is adopted, and a visualization module is developed to display ontology classes, relationships, and instance data, supporting querying, modification, and data topology attribution tracing. The ontology model is verified for completeness, consistency, and usability. Based on the verification results and field usage logs, the protocol adaptation module, semantic normalization rules, and topology association rules are regularly optimized, and the ontology class and attribute definitions are updated to adapt to the dynamic changes of the energy system.

6. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 1, characterized in that: The aforementioned semantic verification and topology update mechanism for edge-cloud collaboration enables real-time data correction, algorithm parameter optimization, and dynamic reconstruction of the ontology model after device / topology changes, including: Define the responsibilities of the edge-cloud collaborative architecture. The edge focuses on real-time scenarios, performing local data real-time semantic verification, topology change monitoring, abnormal data correction, lightweight algorithm inference, and local incremental updates of the ontology model, and only synchronizing incremental data to the cloud. The cloud focuses on global optimization scenarios, and is responsible for global semantic rule management, algorithm model training iteration, global reconstruction verification of the ontology model, and cross-edge node topology data fusion, and sends incremental update packages to the edge. The edge-cloud collaborative communication mechanism is designed, which adopts a lightweight low-latency communication protocol combined with a high-reliability protocol to achieve bidirectional communication. Data transmission is encrypted, the data synchronization granularity is clearly defined, the edge side only synchronizes incremental data to the cloud, and the cloud only sends incremental update packets to the edge side. Data synchronization triggering rules are set, including real-time push, event-triggered push and batch push, and a breakpoint resume mechanism is configured to ensure the reliability of data synchronization. Deploy a lightweight semantic verification engine on the edge side, connect to multi-level data and set basic verification, logical verification, and time-series verification dimensions and rules, classify abnormal data into minor, moderate and severe levels and correct them in real time, record correction logs in a structured manner and only synchronize abnormal logs to the cloud. A multi-dimensional monitoring module for edge-side topology changes is constructed. It collects trigger signals from the device layer, link layer, and electrical layer, sets monitoring thresholds and generates topology change events, calls a lightweight model to perform incremental inference to update the local topology map, synchronously updates relevant attributes of the local ontology model, and then synchronizes topology change-related data to the cloud. A global data lake is built in the cloud to aggregate and classify various types of data from the edge to form a global optimized dataset. The dataset is analyzed regularly to identify high-frequency error types. Based on the analysis results, semantic rules are optimized, semantic association models and topology recognition models are incrementally trained, and the optimized rules and parameters are packaged into incremental update packages and distributed to the edge in a differentiated manner. The cloud integrates all edge node topology change events to construct a global physical association graph and performs consistency verification. When the preset trigger conditions are met, the global reconstruction of the ontology model is initiated, including updating the ontology structure, instance data and model verification. The reconstructed ontology model is split into incremental packages according to the jurisdiction of the edge nodes and distributed to the corresponding edge side. Establish a closed-loop and consistency guarantee mechanism for edge-cloud collaboration, assign unique version numbers to semantic rules, algorithm models, and ontology models and maintain a version library, set conflict resolution rules, deploy a monitoring panel in the cloud to monitor the edge-cloud collaboration operation status in real time, set alarm rules and trigger corresponding alarms. We conducted functional and performance verifications, simulated various scenarios to verify the real-time performance of semantic verification, the timeliness of topology updates, the accuracy of ontology model data queries, and the collaborative operation efficiency in large-scale scenarios. Based on the operation logs, we continuously iterated and optimized the communication synchronization strategy, algorithm training frequency, and ontology reconstruction trigger threshold.

7. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 6, characterized in that: The aforementioned multi-dimensional monitoring module for edge-side topology changes collects trigger signals from the device layer, link layer, and electrical layer, sets monitoring thresholds and generates topology change events, calls a lightweight model to perform incremental inference to update the local topology map, synchronously updates relevant attributes of the local ontology model, and then synchronizes topology change-related data to the cloud, including: A modular design is adopted to construct a multi-dimensional monitoring module for topology changes, which includes a multi-dimensional monitoring sub-module, a threshold configuration unit, an event generation unit, an incremental inference unit, a model update unit, and a data synchronization unit. A standardized interface is defined between the module and the existing system on the edge side, and a low-latency communication protocol is used to realize the interaction between the module and various systems. Multiple types of trigger signals are collected from the device layer, link layer, and electrical layer respectively. Relevant status, parameter, and feature data are obtained according to the corresponding collection strategy to generate structured collection data. Establish a multi-dimensional threshold configuration library, set initial thresholds for each signal type, support user-defined thresholds, and automatically optimize thresholds based on historical data to form a dynamic threshold update table. The collected multi-dimensional signals are compared with the corresponding thresholds. When the triggering conditions are met, relevant information is integrated to generate a topology change event. The built-in deduplication logic avoids duplicate processing. After receiving a topology change event, the multi-dimensional feature data of the devices involved are filtered to form an incremental inference dataset. The lightweight GNN model on the edge side is called to perform incremental inference and output the topology association confidence and hierarchical adjustment suggestions. Based on the model inference results, valid associations are filtered according to confidence level. New, deleted, and topologically altered devices are processed separately, and the node, edge information, and correlation matrix of the local topological graph are updated. Based on the updated local topology map, extract the topology ownership change information, update the topology attributes of the corresponding ontology instance, instantiate ontology classes for newly added devices and bind relevant attributes, mark the ontology instance status for deleted devices, and generate change logs. According to the edge-cloud collaborative communication strategy, topology change events, incremental topology map data and ontology model change logs are encapsulated into standardized data, pushed to the cloud using a specified communication protocol, and configured with synchronization triggering rules, local caching and breakpoint resume mechanism. The built-in module runs monitoring logic, monitors the running status of each sub-module in real time, records running logs, marks various abnormal situations and pushes alarms, triggers retry mechanism, and periodically verifies the consistency between the local topology map and the ontology model and triggers incremental updates.

8. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 6, characterized in that: The establishment of an edge-cloud collaborative closed-loop and consistency guarantee mechanism involves assigning unique version numbers to semantic rules, algorithm models, and ontology models and maintaining a version repository; setting conflict resolution rules; deploying a monitoring panel in the cloud to monitor the edge-cloud collaborative operation status in real time; and setting alarm rules and triggering corresponding alarms, including: Establish a unified version number naming convention, assign globally unique version numbers to semantic rules, algorithm models, and ontology models, and record version update-related metadata; Build a global version control repository in the cloud and a lightweight local version control repository on the edge. Store corresponding version data according to object type and support version backtracking and difference comparison functions. Synchronize version metadata on a regular basis through the edge-cloud collaborative communication protocol to verify and ensure the baseline consistency of the edge-cloud version control repository. Define the version lifecycle status, with the global version lifecycle managed uniformly by the cloud, and the local version status on the edge side updated synchronously with the cloud. It supports the temporary effect of local modified versions in emergency scenarios and the initiation of review requests to the cloud. Set a three-tiered conflict resolution priority, define conflict handling logic for semantic rules, algorithm models, and ontology model scenarios, retain the corresponding versions according to priority and record conflict differences or mark local extended attributes; Construct a multi-dimensional monitoring indicator system covering data synchronization status, model / rule consistency, edge-side operation status, and resource consumption. Develop a cloud-based monitoring panel using a microservice architecture, supporting real-time data refresh, multi-dimensional filtering, visualization, and custom monitoring view functions. Deploy a monitoring data collection agent at the edge to collect and encapsulate local operating metric data and then push it to the cloud in batches; deploy a data aggregation service in the cloud to clean and standardize the received monitoring data before storing it, supporting fast querying and statistical analysis; Alarms are classified into severity levels and corresponding response mechanisms are configured. Multiple types of alarm triggering conditions are set, including threshold triggering, trend triggering, and event triggering. Visual configuration and modification of alarm rules are supported. Establish an alarm handling process, where operations and maintenance personnel mark the handling status and enter the solution. The system automatically associates relevant data to assist in locating the root cause of the problem. Regularly analyze alarm logs and optimize alarm rules, conflict resolution logic, and edge-cloud synchronization strategies. Monthly comprehensive analysis is conducted based on monitoring data, alarm logs, and version update records to optimize version number rules, conflict priorities, monitoring indicator systems, and alarm triggering conditions, forming a closed-loop iterative process of monitoring, analysis, optimization, and verification to continuously improve the consistency and stability of edge-cloud collaboration.

9. The multi-source data fusion and collaborative control method for the energy self-control platform according to claim 1, characterized in that: The enhanced ontology model, which integrates multimodal information, binds data such as operation and maintenance logs and fault codes to topology nodes, supporting model visualization and data traceability, including: We identified the sources of multimodal data, developed standardized acquisition protocols, and performed structured encapsulation and preprocessing on the acquired multimodal data to ensure that the data format was uniform and parseable. The structure is extended based on the existing ontology model, adding new ontology classes, attributes and ontology relations related to multimodal information, clarifying the domain and value range of relations, and using a specified ontology description language to extend it, ensuring compatibility with the original model attributes; A dual-mode intelligent binding engine combining automatic and manual binding is constructed. It realizes the association between multimodal data and topology nodes through semantic matching and logical reasoning. It has built-in binding verification logic, which marks data that fails the verification and pushes it for review. Design a hybrid storage architecture to store structured and unstructured multimodal data separately, build a joint index for cross-storage retrieval, and support reverse data queries based on topology nodes; Develop a layered visualization display system that provides visualization and interactive functions for the topology map layer, multimodal data layer, and relationship layer, adapts to multi-terminal display, and supports offline caching; Construct a full-link data traceability mechanism, establish a traceability metadata system, develop a multi-dimensional traceability query engine, and display traceability results in a visual form to ensure that the entire data flow is traceable. Establish a binding rule optimization library, optimize binding rules based on feedback, support multimodal data type expansion, and regularly update relevant mapping libraries and keyword dictionaries to improve the adaptability of automatic binding; Integrate the multimodal enhanced ontology model with the edge-cloud collaborative architecture, synchronize relevant metadata to the cloud, conduct functional verification, and optimize the binding engine and visualization interaction logic based on the verification results.

10. A multi-source data fusion and collaborative control system for an energy self-control platform, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the multi-source data fusion and collaborative control method of the energy self-control platform according to any one of claims 1 to 9 by executing the machine-executable instructions.

Images