A method and system for automatic construction and analysis of a blood graph of multi-source monitoring data of a hydropower project

Abstract

The application provides a kind of water and electricity engineering multi-source monitoring data's blood graph automatic construction and analysis method and system, applied to water and electricity engineering processing technical field.Access water and electricity engineering total monitoring, operation and maintenance data, build standardization log and script analysis system, build blood graph mode covering all business objects, define node and association relationship completely, extract multi-dimensional node features as model input.Through log slot extraction, AST script analysis generates five-tuple blood record, same source evidence aggregation improves confidence, low confidence relationship is sent to artificial review.Triple is stored and multi-dimensional is de-duplicated, and a complete set of traceability materials is bound, and the data is checked as network training material.Relation graph convolution network is used to learn node representation iteratively, implicit blood is identified through scoring mechanism, and finally relying on the completed graph realizes upstream and downstream link tracing and quantitative path evaluation, and outputs complete and interpretable analysis conclusion.

Description

Technical Field

[0001] This invention relates to the field of hydropower engineering processing technology, and in particular to a method and system for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower engineering. Background Technology

[0002] Existing methods for managing monitoring data in hydropower projects mainly fall into three categories: First, data acquisition and storage methods based on industrial control computers and databases, primarily involving sensor polling, serial communication, message parsing, data writing, and server reporting; second, data cleaning and statistical methods based on ETL scripts and business rules, utilizing Python scripts, SQL scripts, or scheduled tasks to perform anomaly identification, missing data filling, mean calculation, indicator updating, and report generation on raw data; and third, data querying and visualization methods based on monitoring platforms, displaying monitoring data and analysis results through curves, tables, and alarm information. While these methods can meet general data acquisition, storage, and display needs, their focus is primarily on the data results themselves, lacking a unified approach to expressing data sources, transmission links, processing procedures, field dependencies, indicator generation paths, and the scope of anomaly propagation.

[0003] Data lineage technology records the dependencies of data throughout its entire lifecycle, from generation and transmission to processing and application. Traditional data lineage methods are primarily geared towards data warehouse scenarios in industries such as finance, telecommunications, and the internet. They typically use database tables, fields, SQL scripts, and scheduling tasks as objects, generating table-level and field-level lineage relationships through SQL parsing, metadata collection, or manual configuration. However, hydropower engineering monitoring data is characterized by complex engineering objects, long data acquisition chains, numerous industrial control logs, a large amount of time-series data, processing rules with engineering implications, and significant differences in data formats between different processes. Directly applying traditional data warehouse lineage methods is insufficient to express the acquisition, parsing, reporting, cleaning, filling, statistics, indicator updates, and engineering object relationships of hydropower engineering monitoring data.

[0004] Meanwhile, existing lineage maps typically rely on manual annotation or rule extraction, making it difficult to uncover potential lineage relationships not explicitly recorded in logs and scripts. For example, a server log might record "calculated the average value, which is 26.3℃," but without clearly specifying the input fields and corresponding original measurement points; a log might record "updated cooling rate successfully," but without fully recording the dependencies between the cooling rate and the average temperature, the overnight temperature, and the continuous time series. Therefore, initial lineage maps formed solely through rule extraction often suffer from missing edges, weakly correlated edges, and difficulties in identifying implicit influence relationships.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0007] According to one aspect of this application, a method for automatically constructing and analyzing lineage graphs of multi-source monitoring data in hydropower projects is provided, comprising: acquiring various monitoring data during construction and operation periods; synchronously collecting industrial control computer logs, server logs, Python and SQL scripts, monitoring point ledgers, acquisition module configurations, monitoring point equipment lists, anomaly record tables, statistical indicators, database tables and field metadata; dividing standardized log templates and script parsing objects; defining a lineage graph pattern for hydropower project monitoring data; setting up a set of nodes and relationships for monitoring equipment, raw data, monitoring indicators, project objects, acquisition ports, raw messages, processing rules, and report status; extracting three types of features—node text semantics, node type, and project attributes—as node inputs; extracting template slots from the logs; parsing ETL scripts using abstract syntax trees; and generating a formula containing predicates, subjects, objects, and confidence levels based on triplet extraction formulas. The process involves: recording the lineage of evidence texts, merging source evidence to increase confidence, and sending low-confidence candidate edges to a manual verification queue; writing candidate triples into a graph database to construct an initial lineage graph, aligning and deduplicating based on measurement point number, device number, module number, port number, field name, task name, and timestamp, and binding each lineage edge to source evidence from the original log text and script location; using the manual verification results as positive samples for the graph neural network; iteratively calculating based on a relational graph convolutional network according to the multi-layer node representation update formula, constructing a training sample set using type-constrained negative sampling, calculating the probability of lineage existence between nodes using a bilinear scoring matrix, completing training with binary cross-entropy loss, and predicting unexplained indicator derivation and cross-variable implicit lineage edges; tracing back the upstream original collection link based on the complete graph and inferring the downstream impact of anomalies, scoring based on confidence, path length, and evidence completeness, and outputting interpretable lineage analysis results.

[0008] Another aspect of this application is an automatic construction and analysis system for lineage maps of multi-source monitoring data in hydropower projects, which executes executable instructions to perform the above-described method for automatic construction and analysis of lineage maps of multi-source monitoring data in hydropower projects.

[0009] According to another aspect of this application, an electronic device includes: a first processor; and a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute the above-described method for automatically constructing and analyzing lineage maps of multi-source monitoring data for hydropower projects by executing the executable instructions.

[0010] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a second processor, implements the above-described method for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects.

[0011] The beneficial technical effects of this application are as follows: It integrates full monitoring data during construction and operation, industrial control and server logs, ETL scripts, measurement point ledgers, and metadata; defines a unique lineage graph pattern for hydropower projects containing 11 types of nodes and 14 types of relationships; extracts three types of node features; generates five-tuple lineage records through log template slot extraction and abstract syntax tree script parsing; enhances confidence through homologous evidence aggregation; and transfers low-confidence relationships to manual review; after candidate triples are entered into the database, aligned, deduplicated, and bound to traceability evidence, implicit lineage edges are completed using a relationship graph convolutional network; and finally, it achieves bidirectional link tracing and quantitative evaluation based on the complete graph, outputting interpretable analytical conclusions.

[0012] This application aims to construct a lineage graph system adapted to hydropower engineering scenarios, fully covering the entire data acquisition and application chain. It overcomes the limitations of traditional data lineage methods, which are ill-suited to complex engineering objects and long acquisition chains. Furthermore, by integrating rule extraction and graph neural network completion, it effectively identifies indicator derivation and implicit cross-variable dependencies not explicitly recorded in logs and scripts, compensating for the edge-missing problem in pure rule-based graph construction. Through end-to-end binding of source evidence and a corresponding quantitative scoring mechanism, the analysis results are highly interpretable, supporting data quality auditing and anomaly impact assessment, thereby improving the transparency and credibility of monitoring data management.

[0013] It should be understood that the above general description and the following detailed description are merely examples, explanatory and not intended to limit this disclosure. Attached Figure Description

[0014] Figure 1 This invention provides a flowchart illustrating an automatic method for constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects, according to an embodiment of this application. Figure 2 This is a schematic diagram of a system for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects, provided as an embodiment of the present invention. Detailed Implementation

[0015] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0016] In one implementation, Figure 1 The diagram illustrates a flowchart of an automatic construction and analysis method for lineage maps of multi-source monitoring data in hydropower projects, according to an embodiment of this application.

[0017] S101 acquires various monitoring data during construction and operation, and synchronously collects industrial control computer logs, server logs, Python and SQL scripts, measurement point ledgers, acquisition module configurations, measurement point equipment lists, anomaly record tables, statistical indicators, database tables and field metadata, and divides them into standardized log templates and script parsing objects.

[0018] In one implementation, the system uniformly accesses full-volume operational monitoring data from both the construction and operation phases of hydropower projects. This data serves as the upstream source data in the lineage chain, corresponding to the original data nodes in the lineage graph. Construction phase data originates from various sensors deployed at the dam construction site, specifically covering monitoring items such as dam concrete pouring temperature, internal concrete temperature, cooling water flow rate, inlet and outlet water temperatures, ambient temperature, humidity, and wind speed in the construction area. Operation phase data originates from the routine monitoring facilities of already operational hydropower projects, specifically covering monitoring items such as dam displacement, deformation, water level, seepage pressure, uplift pressure, and stress-strain. In a typical application scenario of water flow temperature control monitoring, the system can access internal temperature measurement data from each pouring layer of a dam section, cooling water flow rate and inlet / outlet water temperature data, as well as real-time temperature, humidity, and wind speed data from the construction area, serving as the upstream data carrier for subsequent lineage tracing.

[0019] The system synchronously collects data from the entire operational process supporting the monitoring data flow, covering industrial control computer logs, server logs, Python and SQL scripts, acquisition module configurations, measurement point equipment lists, measurement point ledgers, anomaly record tables, statistical indicator tables, database tables, and field metadata. Among them, the measurement point ledger and measurement point equipment lists together constitute the basic attribute data of measurement points and equipment, fully covering core information such as the number, parameters, and deployment location of monitoring points and acquisition equipment.

[0020] Industrial control computer logs are used to record the entire process of device operation and data transmission at the field acquisition end, including event types such as module polling, serial port transmission, return message, successful parsing, data writing, and reporting to the server. In real-world scenarios, industrial control computer logs can completely record the entire execution chain: polling a specified numbered acquisition module, sending acquisition commands through a specified serial port, receiving the raw messages returned by the device, writing the parsed messages to local storage, and periodically reporting the acquisition results to a remote server.

[0021] Server logs record the entire process of data processing and metric calculation on the server side, including event types such as querying data reported by the industrial control computer, writing to the server, identifying abnormal data, filling missing values, calculating average values, updating the highest temperature, updating the lowest temperature, and updating the cooling rate. In real-world scenarios, server logs can completely record the entire process of querying temperature data reported by the industrial control computer for a specific time period, performing outlier identification and removal, filling missing data for the specified period, calculating the average temperature within the period, synchronously updating the highest and lowest temperatures of the day at that measurement point, and recalculating the cooling rate for the day.

[0022] Python and SQL scripts handle the execution logic for data cleaning, statistical calculations, and indicator updates. This includes functions for outlier removal, missing value imputation, moving averages, statistical calculations, and indicator update statements. In practical scenarios, the scripts might include logic for handling outlier thresholds in temperature data, linear imputation for discontinuous measurement points, moving average calculations for hourly data, and data manipulation logic for updating statistical indicator tables.

[0023] The data acquisition module configuration records the operating parameter settings of the field data acquisition unit; the measurement point equipment list records the model and deployment information of all sensing and data acquisition devices; the anomaly record table stores all identified abnormal data events and their corresponding processing results; the statistical index table stores the monitoring index results calculated for each time period; and the database table and field metadata record the structural information of the monitoring data storage, including the data table name, field definition, data type, primary key association, and index settings.

[0024] After completing full data collection, the system standardizes and categorizes logs and scripts, defining corresponding log template categories and script parsing objects to provide a unified classification basis for subsequent automatic lineage labeling. Log templates are categorized according to the device and business process to which the logs belong. For industrial control computer logs, template categories include module polling, serial port sending, return messages, parsing and writing, and data reporting. For server logs, template categories include server ingestion, anomaly identification, missing data filling, statistical calculation, and indicator updates. Script parsing objects are categorized according to scripting language and processing function. For Python scripts, parsing objects are categorized into data cleaning and statistical calculation parsing objects. For SQL scripts, parsing objects are categorized into data query and indicator update parsing objects.

[0025] S102 defines the lineage graph pattern of hydropower project monitoring data, sets up the nodes and relationship sets of monitoring equipment, raw data, monitoring indicators, project objects, acquisition ports, raw messages, processing rules, and report status, and extracts three types of features—node text semantics, node type, and project attributes—as node inputs.

[0026] In one implementation, a design for a general scenario of monitoring data in hydropower projects is provided, not limited to a single monitoring process. The design concept abstracts various monitored physical quantities such as temperature, flow rate, humidity, wind speed, displacement, deformation, water level, and seepage pressure into monitoring variables, and abstracts various data processing actions such as anomaly identification, missing data filling, moving average, mean calculation, and rate of change calculation into processing tasks. Water flow temperature control is only a typical example of this model; the model can be directly extended to various hydropower project monitoring scenarios such as deformation monitoring, water level monitoring, seepage monitoring, and stress-strain monitoring.

[0027] The lineage graph of monitoring data at any given time consists of four parts: a set of nodes, a set of directed edges, a set of node and edge attributes, and a set of lineage relationship types. It is dynamically updated during data acquisition and processing. Nodes are the basic building blocks of the lineage graph, covering all entities involved in the entire monitoring data chain from generation to application, and include eleven types of nodes. Engineering object nodes correspond to specific engineering entities in hydropower projects and are the physical carriers of the monitoring data. For example, a water flow temperature control monitoring unit in a section of a dam, or a deformation monitoring section of the dam. Monitoring equipment nodes correspond to various sensing devices deployed on-site and are the source of monitoring data generation. For example, temperature sensors embedded in concrete or displacement monitoring sensors installed on the dam crest.

[0028] The data acquisition module node corresponds to the data acquisition unit on-site responsible for aggregating multiple sensor signals, undertaking data acquisition and initial forwarding functions. For example, the multi-channel temperature acquisition module numbered 50 can simultaneously connect to multiple temperature measurement points. The communication port node corresponds to the data transmission interface between the industrial control computer and the acquisition module, serving as the transmission channel node in the data link. For example, the fifth serial port on the industrial control computer used to connect to the acquisition module. The raw message node corresponds to the unparsed raw communication data returned by the acquisition module, representing the original form of data transmission. For example, the hexadecimal communication message returned by the acquisition module through the serial port carries the raw values ​​collected by the sensors.

[0029] The raw data node corresponds to the structured time-series data obtained after parsing the original message, representing the most upstream valid monitoring data in the lineage chain. For example, the concrete temperature value obtained every ten minutes after message parsing is bound to a unique measuring point number. The processing task node corresponds to the specific execution stage in the data processing flow, serving as the execution unit for data transformation and calculation. Examples include tasks such as anomaly identification, missing value imputation, hourly average temperature calculation, and cooling rate calculation. The processing rule node corresponds to the judgment and calculation rules followed by the processing tasks, providing the logical basis for task execution. Examples include the three-standard-deviation threshold rule used for anomaly detection, the linear interpolation rule used for missing value imputation, and the one-hour sliding window rule used for moving averages.

[0030] The processed data node corresponds to the intermediate data obtained after processing tasks, representing a transitional form between raw data and monitoring indicators. For example, temperature time-series data after anomaly removal and missing data imputation. The monitoring indicator node corresponds to the business monitoring indicators obtained after statistical calculations, representing the core data objects of concern for engineering operations and maintenance. Examples include daily maximum temperature, daily minimum temperature, daily average temperature, and daily cooling rate. The report status node corresponds to the final output monitoring report and its data status, serving as the downstream application outlet for the monitoring data. For example, the data entries in the daily water supply temperature control report and the update status of the report for that day.

[0031] The relationship types are defined as follows: a relationship is a directed edge in the graph, reflecting the dependencies, flow, and logical connections between nodes, fully covering the connection logic of the entire data acquisition, transmission, processing, and application process, and including a total of fourteen types of relationships. The relationships connect monitoring equipment nodes and engineering object nodes, reflecting the deployment affiliation of the equipment. For example, a temperature sensor is deployed inside the concrete of a certain section of a dam.

[0032] The data acquisition mechanism connects the raw data nodes and monitoring device nodes, indicating the source device of the data. For example, raw temperature data is acquired from a temperature sensor with a corresponding number. The port transmission mechanism connects the raw message nodes and communication port nodes, indicating the message transmission channel. For example, the raw message returned by the acquisition module is transmitted through serial port number 5. The parsing mechanism connects the raw data nodes and raw message nodes, indicating the logic of converting messages into structured data. For example, the hexadecimal raw message is converted into structured raw monitoring data after parsing.

[0033] The write operation connects the raw data node to the industrial control computer's local storage node, demonstrating the local data storage process. For example, parsed raw data is written to the industrial control computer's local database. The report operation connects the industrial control computer's data node to the server's data node, demonstrating the data upload and transfer process. For example, raw data from the industrial control computer is periodically reported to the central server. The input operation connects the data node to the processing task node, demonstrating the source of the task's input. For example, raw temperature data is input to the anomaly detection and processing task.

[0034] The data nodes and processing task nodes are connected by task processing relationships, reflecting the main body of data processing. For example, temperature time series data is calculated and processed by a moving average task. Processing task nodes and processing rule nodes are connected by rule relationships, reflecting the logical basis for task execution. For example, an anomaly detection task uses a three-standard-deviation threshold judgment rule. Output relationships connect processing task nodes and processed data nodes, reflecting the task's output results. For example, an anomaly detection task outputs temperature data after removing outliers. Derivation relationships connect processed data nodes and monitoring indicator nodes, reflecting the source of indicator derivation. For example, daily temperature time series data is derived into the daily average temperature indicator.

[0035] The update relationship connects monitoring indicator nodes and report status nodes, reflecting the update actions of report data. For example, the cooling rate indicator calculated for the day updates the corresponding field in the daily water flow temperature control report. The entry into the report relationship connects monitoring indicator nodes and report status nodes, reflecting the final output of the indicator. For example, the daily maximum temperature indicator enters the water flow temperature control statistical report. The impact relationship connects upstream nodes and all affected downstream nodes, reflecting the propagation path of anomalies or changes. For example, a failure in the data acquisition module will affect all derived temperature indicator data downstream.

[0036] Both nodes and edges have unique attributes used to carry business information and traceability evidence. Node attributes include number, name, type, unit, associated project object, measurement point number, timestamp, data table, field name, processing parameters, and evidence source. For example, the attributes of a raw data node may include measurement point number, temperature unit, associated dam section, collection timestamp, corresponding data table and field name, and data source log number. Edge attributes include relation type, confidence level, evidence text, log time, script location, and extraction method. For example, the attributes of an input edge may include relation type name, confidence level value, corresponding log fragment, log generation time, and template number used for extraction.

[0037] The core function of node input feature construction is to provide standardized input for subsequent lineage completion based on graph neural networks. The features of each node are composed of three parts: textual semantic features, node type features, and engineering attribute features, which fully cover the semantic connotation, graph role, and engineering domain attributes of the node, ensuring the accuracy and engineering rationality of the completion results.

[0038] Node text semantic feature extraction extracts features from node names, Chinese field names, variable descriptions, task descriptions, and processing rule descriptions. Through text embedding, natural language descriptions are converted into dense vectors of fixed dimensions, capturing the deep semantic meaning of nodes. For example, the text description of a raw data node might be the original collected value of a temperature measuring point inside a section of a dam. After text embedding, a corresponding semantic vector is generated, reflecting the monitoring category and physical meaning of the node. Similarly, the text description of a processing task node might be an hourly moving average calculation task; the embedded vector reflects the processing type and time granularity of the task. Finally, the text description of a processing rule node might be a three-times standard deviation constant judgment rule; the embedded vector reflects the rule's function and judgment logic.

[0039] Node type feature extraction is generated using one-hot encoding. Different types of nodes are assigned unique encoding vectors to distinguish their roles within the graph, enabling the model to quickly identify functional differences between nodes. For example, monitoring equipment nodes correspond to one type of one-hot encoding, raw data nodes to another, and processing task nodes to a specific type of encoding. The model can use this feature to quickly distinguish the category attributes of data nodes, task nodes, and equipment nodes, adapting the interaction logic of different node types during graph structure learning.

[0040] Node engineering attribute feature extraction is used to extract the engineering domain attributes of nodes, including information such as monitoring variable type, unit, data frequency, engineering stage, measuring point location, and data status. These attributes are quantified or encoded to form attribute vectors, injecting hydropower engineering domain knowledge into the model and improving the engineering rationality of the completed results. For example, the engineering attributes of a temperature measuring point include variable type "temperature," unit "degrees Celsius," data frequency "every ten minutes," engineering stage "construction period," measuring point location "at a specified elevation on a section of the dam," and data status "valid raw data." These attributes, after encoding, constitute the engineering attribute vector of this node. Similarly, the engineering attributes of a processing task include processing variable type "temperature," processing granularity "hourly," process "water flow temperature control," and processing type "statistical calculation." These attributes, after encoding, constitute the engineering attribute vector of the task node.

[0041] After extracting the three types of features, the text semantic embedding vector, node type one-hot encoding vector, and engineering attribute vector are concatenated in a fixed order to form the final node input feature vector. Each node corresponds to a unique feature vector, which can be directly input into the subsequent graph neural network model for node representation learning and missing lineage edge prediction.

[0042] S103 performs template slot extraction on the logs, uses abstract syntax tree to parse ETL scripts, and generates lineage records containing predicate, subject, object, confidence level, and evidence text based on triple extraction formula. Same-source evidence is merged to increase confidence level, and low-confidence candidate edges are sent to the manual verification queue.

[0043] In one implementation, template recognition and slot extraction are performed on various logs from industrial control computers and servers. An abstract syntax tree is used to parse both Python and SQL ETL scripts. A complete lineage record containing subject, predicate, object, confidence level, and evidence text is generated based on a triplet extraction formula. The triplet extraction formula is as follows: In the formula, Indicates from the first Candidate lineage records extracted from log entries or script snippets. , , They represent the subject, predicate, and object, respectively. Indicates the confidence level. Representing the evidence text, This represents the extraction function, which consists of template rules, a script parser, and a necessary semantic extraction model. The system pre-establishes a log template library covering the entire monitoring chain of hydropower projects. Template categories include polling module templates, serial port sending templates, return message templates, parsing and writing templates, data reporting templates, server database entry templates, anomaly identification templates, missing data filling templates, statistical calculation templates, and indicator update templates. When processing a single log entry, the system first matches the log content with the template library to determine the corresponding log template type, and then extracts the specific values ​​corresponding to the dynamic slots in the template, completing the conversion from unstructured logs to structured slot information.

[0044] The system log template library covers 10 standardized template categories. Each template category includes four parts: a fixed prefix, dynamic slots, matching rules, and initial confidence. The specific definitions are as follows: The industrial control computer side includes 5 types of templates, as follows: Module polling template: The fixed prefix is ​​"polling module", the dynamic slot contains the module number, the matching method is exact string matching, and the initial confidence score is 0.96 when the match is successful; Serial port transmission template: The fixed prefix is ​​"port transmission command", the dynamic slot contains the port number and command content, the matching method is prefix + regular expression matching, and the initial confidence score is 0.92 when the match is successful; Return message template: The fixed prefix is ​​"receive module return message", the dynamic slots include the module number and message length, the matching method is prefix + regular expression matching, and the initial confidence score is set to 0.89 when the match is successful; Parsing and writing template: The fixed prefix is ​​"Message parsing successfully written", the dynamic slot contains the measurement point number, data value, and timestamp, the matching method is exact match, and the initial confidence level is set to 0.95 when the match is successful; Data reporting template: The fixed prefix is ​​"Report data to server", the dynamic slots include the number of data entries and the reporting time, the matching method is prefix matching, and the initial confidence score is set to 0.93 when the match is successful.

[0045] The server side includes 5 types of templates, as follows: Server database template: The fixed prefix is ​​"Receive data reported by industrial control computer", and the dynamic slots include the data source and the number of data entries. The initial confidence level for a successful match is 0.94. Anomaly identification template: The fixed prefix is ​​"Execution Anomaly Data Identification". The dynamic slots include the measurement point number, the anomaly value, and the processing action. The initial confidence level for a successful match is 0.95. Missing value imputation template: The fixed prefix is ​​"Perform missing value imputation", and the dynamic slots include the measurement point number, imputation time period, and imputation method. The initial confidence level for a successful match is 0.94. Statistical calculation template: The fixed prefix is ​​"Execute statistical calculation", and the dynamic slots include the calculation type, statistical period, and calculation result. The initial confidence level for a successful match is 0.90. Metric update template: The fixed prefix is ​​"Update monitoring metric", and the dynamic slots contain the metric name and the updated value. The initial confidence level for a successful match is 0.91.

[0046] Log and template matching is determined by edit distance. When the edit distance is ≤3, the match is considered successful; when the edit distance is >3 and ≤5, it is considered a fuzzy match, and the initial confidence level is lowered by 0.2 accordingly; when the edit distance is >5, the match is considered unsuccessful, and the semantic extraction model is used to assist in recognition.

[0047] For the industrial control computer's module polling logs, the original log content is "Polling one module: 50". After the system matches the polling module template, the value of the module number slot is extracted as 50. For the serial port transmission logs, the original log content is "Sending a hexadecimal command string from COM5 port". After the system matches the serial port transmission template, the value of the communication port slot is extracted as COM5, and the value of the command content slot is the corresponding hexadecimal command sequence. For the server-side anomaly identification logs, the original log content is "Executing anomaly data identification; threshold judgment: if data of 60 is collected at a certain moment, it is identified as anomaly data and the data is removed". After the system matches the anomaly identification template, the value of the processing task slot is extracted as "anomaly data identification", the judgment rule slot is extracted as "threshold judgment", the anomaly value slot is extracted as "60", and the processing action slot is extracted as "data removal".

[0048] For both Python and SQL ETL scripts, the system employs abstract syntax tree parsing, regular expression matching, SQL parser parsing, variable dependency analysis, and a small amount of semantic model assistance to identify input tables, output tables, input fields, output fields, processing functions, and processing parameters in the scripts, and to clarify the data flow and dependencies at the field level.

[0049] For Python scripts, the abstract syntax tree (AST) parses and traverses the following core nodes to extract field dependencies: traversing the Import node to identify dependent libraries; traversing the FunctionDef node to locate data processing functions; traversing the Assign node to identify variable assignment relationships, extracting the output variables on the left and the input variables on the right to establish variable-level dependencies; traversing the Call node to identify function calls, extracting the input fields corresponding to the function parameters and the output fields corresponding to the return values; and combining the mapping relationship between variables and database table fields to convert variable-level dependencies into table field-level lineage relationships.

[0050] For SQL scripts, the parsing rules are as follows: Parse SELECT clauses to extract output fields; parse FROM and JOIN clauses to extract input table and related fields; parse WHERE, GROUP BY, and aggregate functions to extract calculation logic and filtering conditions, and identify derivative dependencies between fields; parse INSERT and UPDATE clauses to locate the target table and target fields, establishing a complete lineage from input fields to processing logic to output fields. The initial confidence level of the script parsing results is uniformly assigned to 0.97. If unidentified user-defined functions are found during parsing, the corresponding confidence level is lowered by 0.15 and the parsing is marked as incomplete.

[0051] For the outlier removal script, the system parses and identifies the input field as the original monitoring data field, the processing function as the outlier removal function, the processing parameter as a threshold of three standard deviations, and the output field as the processed data field. For the moving average script, the system parses and identifies the input field as the minute-level original data field, the processing function as the moving average function, the processing parameter as a one-hour sliding window, and the output field as the hourly average data field. For the indicator update SQL script, the system parses and identifies the input field as the hourly statistical data field, the processing logic as maximum value statistics, and the output field as the daily maximum temperature indicator field.

[0052] The system inputs the log slot extraction results and script parsing results into the extraction function to generate standardized candidate lineage records. The extraction process of candidate lineage triples follows a unified calculation formula, the complete form of which is as follows: In the formula, Indicates from the first Candidate lineage records extracted from log entries or script snippets. , , They represent the subject, predicate, and object, respectively. Indicates the confidence level. Representing the evidence text, This represents an extraction function consisting of template rules, a script parser, and a necessary semantic extraction model.

[0053] The extraction function calls the corresponding processing logic based on the different input sources, mapping the structured slots or script parsing results to kinship triples. The subject and object correspond to node entities in the kinship graph, the predicate corresponds to the kinship relationship type between nodes, the confidence score is used to characterize the credibility of the kinship relationship, and the evidence text retains the original data fragments as the basis for tracing the source.

[0054] Corresponding to the aforementioned industrial control computer return message log, a single log segment serves as input. Match the returned message template as Candidate lineage records generated after extraction function operation. In the middle, the subject For the data acquisition module numbered fifty, the predicate... For return, object For the original message, confidence level The value is 0.89, and the evidence text is as follows. This is the complete content of the industrial control computer log. Corresponding to the aforementioned server anomaly identification log, a single log fragment is used as input. Matching anomaly identification templates as Candidate lineage records generated after extraction function operation. In the middle, the subject For the original temperature data, the predicate For input to, object For anomaly detection and processing tasks, confidence level The value is 0.95, and the evidence text is as follows. This is the complete content of the server log entry. The single-segment script logic is used as input to the aforementioned outlier removal script. Matching script parsing rules as Candidate lineage records generated after extraction function operation. In the middle, the subject For the original temperature field, the predicate For input to, object For outlier removal tasks, confidence level The value is 0.97, evidence text. This is a text description of the corresponding processing logic in the script.

[0055] The confidence level of multi-source evidence was calculated using a weighted evidence fusion formula. Basic weights were assigned to the three evidence sources: industrial control computer logs, server logs, and ETL scripts: industrial control computer logs 0.25, server logs 0.35, and ETL scripts 0.40. The final confidence level calculation formula is as follows: In the formula, The final confidence level after fusion is given, where n is the number of evidence sources. The basic weights for the i-th type of evidence source, This represents the single-source confidence score extracted from the i-th evidence source. When there are two or more independent evidence sources for the same blood relationship, the above fusion calculation is performed. If the blood relationship directions derived from different evidence sources conflict, the result with the higher confidence score is retained, while the final confidence score is lowered by 0.3 and marked as an ambiguous relationship, and transferred to the manual verification queue.

[0056] When multiple sources of evidence exist for the same bloodline, the evidence is merged and the confidence level is increased. Low-confidence candidate edges are sent to a manual verification queue, and the results of the manual verification are used as positive samples for training the graph neural network. For the same bloodline relationship, if multiple different sources of evidence exist simultaneously, such as industrial control computer logs, server logs, and ETL scripts, the system will merge all the evidence texts corresponding to that relationship. Simultaneously, based on the number of evidence sources and the credibility of each source, the confidence level of the bloodline relationship is comprehensively increased. Taking the bloodline relationship of inputting raw temperature data into an anomaly identification task as an example, this relationship can be extracted from server anomaly identification logs or parsed from anomaly removal scripts. After the system identifies two extraction results pointing to the same bloodline relationship, it includes both the original log text and the script fragment into the evidence set for that relationship, and simultaneously increases the confidence level of the relationship from 0.95 for a single evidence source to 0.99. Bloodline relationships with multi-source cross-validation have higher credibility.

[0057] The system pre-sets a confidence threshold. Candidate lineage edges with confidence levels below the threshold or those with semantic ambiguity are not directly added to the initial lineage graph. Instead, they are transferred to a manual verification queue, where engineers verify the correctness of the lineage relationships based on the measurement point log and business processing rules. Lineage relationships confirmed correctly by manual verification are added to the initial lineage graph and stored as high-quality positive samples in the sample library for subsequent training of graph neural network models.

[0058] A candidate kinship edge for a cross-variable influence relationship, generated with the assistance of a semantic extraction model, has a confidence score of 0.6, lower than the preset threshold of 0.8, and the corresponding field name is ambiguous. The system sends this candidate edge to a manual verification queue. Engineers, after verifying it against the measurement point deployment log and data processing logic, confirm the kinship relationship is valid. This manually confirmed kinship relationship will be added to the initial kinship graph and also marked as a positive sample, stored in the training sample library of the graph neural network for subsequent model training and optimization.

[0059] S104. The candidate triples are written into the graph database to construct the initial lineage graph. The duplicates are aligned and removed based on the measurement point number, device number, module number, port number, field name, task name, and timestamp. Each lineage edge is bound to the original log text and script location as source evidence. The results of manual verification are used as positive samples for the graph neural network.

[0060] In one implementation, all candidate lineage triples obtained from log templates and ETL script parsing are written into a graph database to build an initial monitoring data lineage graph. The system uses an attribute graph model to store the lineage graph, adapting to mainstream graph databases (such as Neo4j and NebulaGraph). The storage structure is defined as follows: Specifically, for node storage, each type of node corresponds to a label. Node attributes include eight core fields: unique ID, node name, node type, business number (measurement point / equipment / module number), project attribute set, timestamp, data table to which it belongs, and corresponding field name. Unique indexes are established for measurement point numbers and equipment numbers, and label indexes are established for node types.

[0061] Edge storage: Each directed edge contains seven core fields: start point ID, end point ID, relationship type, confidence level, evidence ID set, extraction method, and creation time. An index is created for the relationship type, and a range index is created for the confidence level. Source tracing evidence is stored separately in an evidence table. Each piece of evidence contains six fields: evidence ID, evidence type (log / script / ledger), original content, log time / script line number, source file path, and extraction rule number. Lineage edges are associated with corresponding evidence through evidence ID sets, avoiding redundancy in graph edge attributes. When the text length of a single piece of evidence exceeds 500 characters, it is stored in fragments, with the first paragraph retaining a core summary, and the complete content stored as an attachment.

[0062] All candidate lineage triples are written into the graph database to construct an initial lineage graph of the monitoring data. The system imports all candidate lineage records generated during the automatic annotation phase into the graph database, mapping the subject and object in the triples to node entities in the graph, and the predicate in the triples to directed edges between nodes. Confidence level, evidence text, and other information are stored in the attribute fields of the corresponding edges. The lineage relationships of all stages—collection, transmission, parsing, storage, cleaning, statistics, and indicator updates—are initially stored in the database, forming an initial graph skeleton covering the entire processing chain of hydropower engineering monitoring data.

[0063] For example, the lineage records generated by the industrial control computer log extraction, such as the polling of module 50 by the acquisition task, the return of the original message by module 50, the parsing of the original message into the original monitoring data, and the writing of the original monitoring data into the local database of the industrial control computer; the lineage records of the original temperature data generated by the server log extraction, such as the input of the anomaly identification task and the triggering of the removal process by the anomaly identification task; and the lineage records of the original temperature field generated by the anomaly removal script, such as the input of the processed temperature field into the anomaly removal task and the output of the processed temperature field by the anomaly removal task, will be synchronously written into the graph database, with each node and directed edge mapped one by one, initially connecting the complete lineage link from field acquisition to server-side cleaning.

[0064] Nodes are merged and aligned based on multiple dimensions, including measurement point number, device number, module number, port number, field name, task name, and timestamp, with duplicate nodes removed. Node alignment and deduplication are performed by matching identifiers in descending order of priority, as follows: globally unique primary keys: measurement point number, device number, module number, port number; business identifiers: field name, task name, rule name; time-based identifiers: data timestamp, task execution time; semantic auxiliary identifiers: node name text similarity. High-priority identifiers are used first during matching; if all high-priority identifiers are identical, the nodes are considered the same. If a high-priority identifier is missing, lower-priority identifier combinations are used sequentially for matching; if the combination match rate is ≥90%, the nodes are considered the same.

[0065] When node attributes from different sources conflict, the attribute values ​​are prioritized according to the order of "measurement point ledger > data acquisition module configuration > database metadata > log extraction > script extraction," and conflicting items retain all source information and are marked. Node merging and alignment are performed according to multi-dimensional rules, and duplicate nodes are removed. Node alignment is based on seven categories of information: measurement point number, device number, module number, port number, field name, task name, and timestamp. Since candidate triples come from multiple different channels such as industrial control computer logs, server logs, and ETL scripts, different sources may generate duplicate nodes pointing to the same entity. The system sets node matching rules according to the above business dimensions, integrates the attributes of nodes that identify the same entity, and retains only unique node entities to avoid redundant nodes in the graph that could lead to structural chaos and relationship mismatches.

[0066] For example, the raw temperature data node generated by the industrial control computer log has a measurement point number and a timestamp attribute. The raw temperature data node generated by the server log has the same measurement point number and timestamp attribute. The raw temperature field node obtained by the ETL script corresponds to the raw temperature field of the same measurement point in the database. The system performs matching and verification according to three dimensions: measurement point number, timestamp, and field name. It determines that the three nodes point to the same raw temperature monitoring data, integrates the attribute information of the three, and merges them into a single raw data node, removing the other two duplicate node entries. As another example, the fifth serial port node appearing in the industrial control computer log matches the corresponding communication port node in the acquisition module configuration file. The system matches them according to the port number dimension and confirms that they are the same communication port entity, completing the node merging and attribute completion.

[0067] If the same lineage relationship is generated from multiple evidence sources, all evidence sets are merged and the corresponding confidence level is increased. The system performs relationship consistency checks on all candidate lineage edges. When the subject, predicate, and object of two edges match completely, they are determined to point to the same lineage relationship. If the same lineage relationship comes from multiple evidence sources such as ETL scripts, industrial control computer logs, and server logs, the system integrates the evidence texts from multiple sources into the evidence set of the same edge. At the same time, it combines the inherent credibility and the amount of evidence from different sources to comprehensively calculate and update the confidence level of the lineage edge. Relationships with independent cross-validation from multiple sources correspond to a higher level of credibility.

[0068] For example, the lineage relationship of inputting raw temperature data into the anomaly identification task can be obtained either from the server anomaly identification log (with a confidence level of 0.95 for evidence from a single server log) or from parsing the outlier removal Python script (with a confidence level of 0.97 for evidence from a single script). After the system identifies two candidate edges whose entities and relationships completely match, it includes both the original server log text and the script processing logic fragment into the evidence set for this relationship. By combining the credibility of the two independent evidence sources, the confidence level of this lineage relationship is increased to 0.99, significantly higher than the confidence level of a single evidence source.

[0069] Each bloodline edge is bound to a complete set of traceability materials, including the original log text, log time, script file name, script line number, and extraction rule number. These traceability materials cover seven categories of information: the original log text, log time, script file name, script line number, database table name, field name, and extraction rule number. The system configures a complete set of traceability information for each bloodline edge that ultimately ends up in the database, ensuring that each bloodline relationship has a clear basis for its generation. Engineers can retrieve the original materials at any time to verify the correctness of the bloodline relationship, avoiding unreliable results caused by black-box extraction. For example, if the original message is parsed as original monitoring data, this bloodline edge originates from the template matching result of the industrial control computer's returned message log. The traceability materials bound to it by the system include the complete original text of the corresponding industrial control computer log, the specific timestamp of the log's generation, the database table name and corresponding field names to which the original data belongs, and the rule number corresponding to the returned message template used for matching.

[0070] For example, the lineage edge from which the processed temperature field derives to the daily average temperature index originates from the parsing result of the SQL index update script. The traceability materials bound to it by the system include the file name of the corresponding script, the specific line number where the update statement is located, the database table name and corresponding field name to which the index belongs, and the rule number corresponding to the SQL index update parsing. At the same time, the text content of the corresponding statement in the script is retained as evidence text. All traceability materials are stored together with the lineage edge, and the complete generation basis can be viewed by retrieving any lineage relationship.

[0071] High-confidence matching results are directly stored in the database, while low-confidence or ambiguous candidate lineage edges are transferred to a manual verification queue. Records verified manually are retained as high-quality positive samples for training the graph convolutional network. The system pre-sets a confidence threshold to categorize candidate lineage edges. Lineage edges with a confidence level above the threshold and no semantic ambiguity are directly written into the initial lineage graph, while candidate edges with a confidence level below the threshold or ambiguous entity mappings are entered into the manual verification queue. The results of manual verification serve as high-quality positive samples for subsequent graph neural network training.

[0072] For example, the system presets a confidence threshold of 0.8. Industrial control computer data acquisition link lineage relationships generated through precise matching using standard log templates generally have a confidence level above 0.95, exceeding the preset threshold and lacking ambiguity. The system directly adds these lineage edges to the initial lineage graph. Candidate edges for cross-variable influence relationships generated with the assistance of a semantic extraction model have a confidence level of 0.6, below the preset threshold, and their corresponding field names have multiple possible mapping directions, indicating strong semantic ambiguity. The system transfers these candidate edges to a manual verification queue, where engineers verify them based on the measurement point deployment log and on-site data processing logic. Once the engineers confirm the validity of the lineage relationship, it is both added to the initial lineage graph and marked as a high-quality positive sample, stored in the training sample library of the graph neural network for subsequent model parameter learning and performance optimization.

[0073] S105, based on a relational graph convolutional network, iteratively calculates according to the multi-layer node representation update formula, constructs a training sample set using type-constrained negative sampling, calculates the probability of kinship between nodes using a bilinear scoring matrix, completes training with binary cross-entropy loss, and predicts un-explicitly recorded index derivation and cross-variable implicit kinship edges.

[0074] In one implementation, node feature vectors generated from an initial kinship graph through text embedding, type one-hot encoding, and engineering attribute concatenation are used as node inputs. A relational graph convolutional network is then employed for graph processing. This converts heterogeneous nodes in the graph into standardized vector inputs that can be processed by the graph neural network, providing a foundation for subsequent representation learning. The node input features are composed of three types of features: textual semantic features, node type features, and engineering attribute features.

[0075] Textual semantic features are derived from node names, Chinese field names, variable descriptions, task descriptions, and processing rule descriptions. Natural language descriptions are converted into fixed-dimensional dense vectors through text embedding to capture the semantic connotations of nodes. Node type features are generated using one-hot encoding, assigning unique encoding vectors to different types of nodes to distinguish their roles within the graph. Engineering attribute features extract engineering domain attributes from nodes, including monitoring variable types, units, data frequency, project stage, measurement point location, and data status. These attributes are quantified or encoded to form attribute vectors, injecting hydropower engineering domain knowledge into the model.

[0076] Taking the raw temperature data node as an example, its text description is the original collected value of a temperature measuring point inside a certain section of the dam. After text embedding, a corresponding semantic vector is generated, reflecting the monitoring category and physical meaning of the node. The node type corresponds to the raw data category, generating a unique thermal encoding vector. Engineering attributes include variable type as temperature, unit as degrees Celsius, data frequency as once every ten minutes, engineering stage as construction period, measuring point location as a specified elevation of the dam section, and data status as valid raw data. These attributes, after encoding, constitute the engineering attribute vector. The input features of node v can be represented as: In the formula, This represents the input features of node v. This represents the node's text description. Represents a text embedding vector. Indicates the node type. Indicates node type encoding, This represents the engineering attribute vector. The three types of features are concatenated sequentially to form the initial input feature vector for each node, which serves as the input layer data for the graph convolutional network.

[0077] Taking the raw temperature data node as an example, its text description is the original collected value of a temperature measuring point inside a certain section of the dam. After text embedding, a corresponding semantic vector is generated, reflecting the monitoring category and physical meaning of the node. The node type corresponds to the raw data category, generating a unique thermal encoding vector. Engineering attributes include variable type as temperature, unit as degrees Celsius, data frequency as once every ten minutes, engineering stage as construction period, measuring point location as an elevation of a designated section of the dam, and data status as valid raw data. These attributes are encoded to form an engineering attribute vector. The three types of vectors are concatenated to form the complete input features of the node, simultaneously covering semantic information, graph role, and engineering domain constraints.

[0078] The core hyperparameter settings for the relational graph convolutional network are as follows: It employs two graph convolutional layers, with an input layer dimension of 171 (128-dimensional text semantic vector + 11-dimensional node type one-hot vector + 32-dimensional engineering attribute vector), a first hidden layer dimension of 64, and a second output layer dimension of 32. The optimizer used is the Adam optimizer, with an initial learning rate of 0.001, a weight decay coefficient of 1e-5, a batch size of 32, a maximum training epoch of 200 epochs, and an early stopping patience value of 20 epochs (training terminates if the validation set loss does not decrease for 20 consecutive epochs).

[0079] The sample parameters are as follows: the ratio of positive to negative samples is 1:5, and training batches are constructed using in-batch negative sampling. The decision thresholds are as follows: the implicit kinship determination threshold is 0.7, and a predicted probability ≥ 0.7 is considered to indicate the existence of a kinship relationship. The activation function is the ReLU function, and the output layer score is calculated and then mapped to the 0-1 interval using the Sigmoid function.

[0080] This approach relies on a multi-layered node representation update formula to traverse the entire set of kinship relationships layer by layer. After weighted normalization of the features of neighboring nodes under each relationship, a non-linear activation function is superimposed to iteratively update the latent representations of each node. A relationship-aware graph neural network is employed to learn node representations, with a relation graph convolutional network being the preferred implementation method. It is also compatible with various heterogeneous graph neural network models such as R-GCN, GraphSAGE, and HGT. The core feature of this type of model is its ability to distinguish between different types of kinship relationships, setting independent learnable weight matrices for each relationship, adhering to relationship boundaries during information aggregation, and adapting to the heterogeneous characteristics of multiple relationship types in hydropower engineering monitoring kinship maps.

[0081] Based on a multi-layer node representation update formula, the entire set of kinship relationships is traversed layer by layer. The features of neighboring nodes under each relationship are weighted and normalized, then superimposed with a non-linear activation function to iteratively update the hidden representation of each node. A relationship-aware graph neural network is used to learn node representations, with a relation graph convolutional network preferred as the basic implementation method. It is also adaptable to various heterogeneous graph neural network models such as R-GCN, GraphSAGE, and HGT. The core feature of this type of model is that it distinguishes different types of kinship relationships, sets an independent learnable weight matrix for each relationship, follows the relationship boundaries during information aggregation, and adapts to the heterogeneous characteristics of multiple relationship types in the kinship map of hydropower engineering monitoring. In the k-th layer graph neural network, the representation of node v is updated as follows: In the formula, This represents the representation of node v at the k-th layer. Represents a set of relation types. Indicates the relationship With nodes The set of connected neighbor nodes, Representing relations The corresponding learnable weight matrix, Represents the normalization coefficient. Represents a non-linear activation function. This represents the weight matrix used to process information about node v itself. This represents the feature vector of node v in the k-th layer of the neural network. This represents the feature vector of a neighbor node u connected to node v through relation r in the k-th layer of the neural network.

[0082] The update logic for each layer of graph convolution is as follows: For each target node, first traverse all lineage relationship types to find all neighboring nodes connected to the target node under that relationship. Multiply the previous layer representation of each neighboring node by the weight matrix of the corresponding relationship, and then perform weighted processing according to the normalization coefficient. Add the aggregation results of all relationship types, and then superimpose the product of the previous layer representation of the target node and the self-connection weight matrix. Finally, perform a non-linear activation function operation to obtain the latent representation of the target node in the current layer. After multiple layers of graph convolution iteration, the representation of each node will gradually integrate neighbor information and graph structure information within a multi-hop range, more accurately depicting the node's location in the entire lineage link.

[0083] Taking the anomaly detection task node as an example, during the first-layer graph convolution update, the node aggregates neighbor information from three types of relationships. The first type consists of neighbor nodes representing the original temperature data under the input relationship, whose representation contribution is calculated using a weight matrix specific to the input relationship. The second type consists of neighbor nodes representing the threshold judgment rules under the rule relationship, whose contribution is calculated using a weight matrix specific to the rule relationship. The third type consists of neighbor nodes representing the processed temperature data under the output relationship, whose contribution is calculated using a weight matrix specific to the output relationship. The aggregation results of the three types of relationships are normalized and then added together. This sum is then superimposed with the product of the node's initial representation and the self-connection weights, and after passing through an activation function, the first-layer hidden representation is obtained. After multi-layer graph convolution updates, the node can further aggregate information from upstream original message nodes and downstream average temperature index nodes. At this point, the node representation has incorporated a wider range of structural information and domain attributes.

[0084] A balanced training sample set is constructed using a negative sampling method constrained by engineering rules, with manually verified kinship edges serving as positive samples. For any node pairing and correspondence type, a kinship existence prediction score is output through relation-specific bilinear scoring matrix operations. Model training requires constructing a balanced training set containing both positive and negative samples to support loss function calculation and parameter iteration. Positive samples are manually verified kinship edges; these samples have the highest annotation quality and serve as positive examples for training.

[0085] Negative sampling supports multiple implementation methods, including random negative sampling, type-constrained negative sampling, and engineering rule-constrained negative sampling. Among them, engineering rule-constrained negative sampling can avoid generating invalid negative samples that obviously do not conform to engineering logic, thus improving training efficiency and the reasonableness of results. Engineering rule constraints contain two layers of logic. The first layer is node type constraints, which pre-excludes node type combinations that cannot possibly be related. For example, an engineering object node cannot be directly derived into a monitoring indicator node, and a raw message node cannot be directly associated with a report status node. Such combinations are not included in the scope of negative samples. The second layer is engineering logic constraints, which follow the basic logic of data flow from upstream to downstream. Downstream data nodes cannot be used as inputs to upstream data nodes, and later indicator nodes cannot be the source of earlier raw data. Such reverse combinations are also not included in the scope of negative samples. Negative sampling constrained by engineering rules is filtered through a dual approach of node type compatibility matrix and flow direction constraints. The specific rules are as follows: node type combinations are prohibited (completely excluded from negative samples): there is no direct association between engineering object nodes and original messages, processed data, monitoring indicators, and report status nodes; there is no direct association between original message nodes and processing tasks, monitoring indicators, and report status nodes; there is no direct association between report status nodes and monitoring equipment, acquisition modules, and original data nodes; and there is no direct association between processing rule nodes and engineering object, monitoring equipment, and original message nodes.

[0086] The data flow constraints are as follows: all relationships follow a unidirectional "upstream-downstream" flow, and the timestamp of the downstream node must be later than that of the upstream node; generating negative samples with reverse relationships is prohibited. Between nodes of different monitoring processes (such as temperature monitoring and seepage monitoring), only influence relationships are allowed; direct data dependencies such as input-to or derivation are not permitted. After filtering according to the above rules, negative samples are randomly selected from the remaining node pairs to ensure that all negative samples are valid samples that are "logically possible but not actually present." The final generated negative samples are node pairs that are logically possible but not present in the actual engineering scenario, ensuring the validity of the negative samples.

[0087] Taking the sample construction of a water temperature control scenario as an example, positive samples are selected by inputting manually verified raw temperature data into the anomaly identification task, deriving the daily average temperature index from the processed temperature data, and using sliding window rules for the moving average task—all true lineage edges—to ensure the authenticity and representativeness of the positive samples. When negative sampling adopts engineering rule constraints, combinations of direct connections between engineering object nodes and report status nodes, as well as combinations of direct connections between raw message nodes and monitoring indicator nodes, are first excluded, because there must be multiple processing steps between them, making direct association impossible. Secondly, combinations of reverse relationships from monitoring indicator nodes to raw data nodes are excluded, as they do not conform to the data flow direction. The final generated negative samples, such as combinations of raw humidity data nodes and temperature anomaly identification task nodes, conform to the data node input to task node pattern in terms of type and are logically correct in direction. However, in actual engineering, humidity data is not input into the temperature anomaly identification task; therefore, these are used as valid negative samples for training.

[0088] After completing node representation learning, for any candidate node pair and a specified lineage relationship type, the model calculates the predicted probability of their existence using a relationship-specific bilinear scoring mechanism. For a candidate node pair (u,v) and relationship type r, the system calculates the probability of the existence of a lineage edge: In the formula, Represents a node With nodes There is a relationship The predicted probability, Representing relation type The bilinear rating matrix Indicates the bias term. , These represent the graph neural network embedding vectors of nodes u and v, respectively.

[0089] Each relation type is configured with an independent bilinear scoring matrix and bias term to adapt to the semantic differences and structural patterns of different relations. The specific calculation process is as follows: the final latent representations of the two nodes after the last layer of graph convolution are extracted, substituted into the corresponding relation's bilinear scoring matrix for bilinear operation, the result is added to the relation's bias term, and then the Sigmoid activation function is used to map the value to the interval between 0 and 1. The final output value is the predicted probability that a specified kinship relationship exists between the node pair. The closer the value is to 1, the higher the model's confidence in the existence of this kinship relationship; the closer the value is to 0, the lower the probability of this relationship.

[0090] Taking the determination of whether there is a derived relationship between the processed temperature data node and the cooling rate index node as an example, we first extract the final latent representations of the two nodes, substitute them into the bilinear scoring matrix corresponding to the derived relationship, add the bias term of the derived relationship, and then calculate the predicted probability using the Sigmoid function. If the calculated probability is 0.92, it indicates that the model, considering the surrounding statistical calculation task structure and the engineering properties of the temperature variable, is highly confident that there is a derived relationship between the two. If the calculated probability of a derived relationship between a certain original flow rate data node and the highest temperature index node is 0.11, it indicates that the model believes that there is almost no such relationship between the two.

[0091] The network is trained by backpropagating all learnable weight matrices using binary cross-entropy as the global loss function. After training, the network is used to predict latent kinship dependencies in logs and scripts within the kinship graph, outputting missing candidate kinship edges to complete the initial monitoring data kinship graph. The model training uses binary cross-entropy as the global loss function and employs a backpropagation mechanism to iteratively update all learnable parameters. The training process is as follows: First, the weight matrices, self-connection weight matrices, bilinear scoring matrices, and bias terms for all relationships are initialized. Training samples are input into the model in batches for forward computation to obtain the predicted probability of each sample. The binary cross-entropy loss value is calculated based on the predicted probability and the sample's true label. The loss is then backpropagated layer by layer using the backpropagation algorithm to update all learnable parameters. This process is repeated multiple times until the loss value stabilizes, at which point the model is trained and has the ability to predict implicit kinship relationships.

[0092] After training, the system iterates through candidate node pairs in the initial lineage graph that meet the constraints but are not explicitly recorded in the logs and scripts. Each pair is input into the trained model, and the predicted probability of the corresponding relationship is calculated. A pre-set judgment threshold is used; candidate node pairs with predicted probabilities higher than the threshold are considered to have implicit lineage relationships and are added to the monitoring data lineage graph as missing edges to complete the data. The training dataset is constructed according to the following rules: all positive samples are from lineage edges that have been manually verified. The selection criteria are: confirmed correct by engineers, confidence level ≥ 0.9, and bound to at least one type of complete traceability evidence; the dataset is randomly divided into training, validation, and test sets in a 7:2:1 ratio, ensuring a uniform distribution of nodes within the same process scenario to avoid distribution shift; before training, samples are deduplicated, and only one sample is retained for the same node pair and the same relationship.

[0093] Implicit kinship completion edges employ a three-tiered triage mechanism: high-confidence edges with a prediction confidence of ≥0.9 are automatically added to the database and marked as "Model Completion - High Confidence"; medium-confidence edges with a prediction confidence of 0.7~0.9 are transferred to a manual verification queue and added to the database after manual confirmation; low-confidence edges with a prediction confidence of <0.7 are discarded and not included in the graph. All model-completed edges are individually tagged with their source and stored separately from rule-extracted edges. All completed edges are labeled with their prediction confidence, completion source, and corresponding relationship type to maintain traceability. They can also be sent to a manual verification queue for further verification as needed.

[0094] The model completes the genealogy relationships covering three scenarios. The first is where the logs don't explicitly record the derivation relationships of input fields; for example, the logs might only record the calculated average value without specifying the corresponding original measurement point. The model can complete the association between fields and indicators based on structure and attributes. The second is implicit dependencies in multi-variable calculations; for example, the cooling rate depends on the average temperature, the overnight temperature, and a continuous time series. The logs might only record successful updates to the cooling rate; the model can complete the association of all dependent fields. The third is potential impact relationships; for example, changes in related variables indirectly affect the calculation results of downstream indicators. These impacts are not explicitly recorded in scripts and logs; the model can identify such impact edges by combining engineering attributes and topology.

[0095] Taking the completion of the cooling rate index as an example, the initial graph only recorded the cooling rate output by the statistical calculation task, but did not fully associate the early morning temperature data node with the time series processing rule node. The model, combining the engineering properties of the temperature variable, the topological structure of the surrounding statistical tasks, and the dependency patterns of similar indicators, predicted a probability of a derivation relationship between the early morning temperature data node and the cooling rate index node of 0.88, exceeding the set threshold. The system added this derivation relationship as a completion edge to the graph, while also labeling the prediction confidence and the source markers of the graph neural network completion, thus completing the entire generation chain of the cooling rate index.

[0096] S106, relying on the complete map, traces back the original upstream collection link and forward extrapolates the downstream impact of anomalies. It scores based on confidence level, path length, and evidence completeness to output interpretable kinship analysis results.

[0097] In one implementation, based on the complete monitoring data lineage map with missing edge prediction and completion, the system divides the analysis execution logic into three categories: upstream tracing, downstream impact, and intelligent interpretation. The applicable boundaries of these three core analysis functions are clearly defined, establishing a relational foundation to support end-to-end retrieval. The system pre-divides the three analysis execution logics—upstream tracing, downstream impact analysis, and intelligent interpretation—corresponding to three core business scenarios: data source tracing, anomaly impact range determination, and analysis conclusion readability.

[0098] The bidirectional retrieval path is established based on all the kinship relationships defined in the graph. Upstream tracing extends backward along relationships such as input to, output to, derivation to, writing, and reporting, while downstream impact analysis extends forward along the corresponding kinship relationship. This ensures that the retrieval path can fully cover the entire flow of data from on-site collection to terminal application without any link interruption.

[0099] Taking water flow temperature control as an example, the system pre-matches three types of analytical business application scenarios. Upstream tracing is suitable for investigating the complete data source and processing chain of monitoring indicators; downstream impact analysis is suitable for determining the downstream propagation range of equipment failures or data anomalies; and intelligent interpretation is suitable for generating readable analytical conclusions for engineering and maintenance personnel. The bidirectional retrieval path is pre-associated with all lineage relationship types under the water flow temperature control scenario, ensuring that starting from any node in the graph, a full-link retrieval can be completed along the correct relationship direction.

[0100] A bidirectional retrieval path is established based on the entire lineage from input to derivation, writing, and reporting of the data map. It traces upstream from monitoring indicators and anomaly records back to the sensor, acquisition module, and original message nodes, while forward traversing all affected processed data and monitoring indicators from equipment failures and missing data records. During upstream tracing, the system starts from a specified monitoring indicator, report field, or anomaly record and searches backward layer by layer along the lineage, sequentially locating the corresponding processing task, processed data, raw data, original message, communication port, acquisition module, and monitoring device node. This completely reconstructs the entire upstream link of the data object from sensor acquisition to indicator generation, leaving no breakpoints.

[0101] When performing downstream impact analysis, the system starts from the specified abnormal data, missing value imputation records, data acquisition module failures, or ETL script modification nodes, and traverses forward layer by layer along the lineage relationship. It sequentially locates all affected processed data, statistical indicators, report status, and engineering analysis result nodes, fully covering all downstream nodes that may be affected by the anomaly or change, avoiding omissions of potential impact objects. The downstream anomaly impact deduction is set with four termination conditions. Meeting any one of these conditions stops the forward traversal of that branch: Node type termination: When traversing to a report status node, the branch terminates, corresponding to the downstream application exit point of the data; Path length termination: When the length of a single propagation path exceeds 8 hops, the branch terminates to prevent unlimited propagation; Confidence termination: When the cumulative confidence product of the path is less than 0.3, the branch terminates, excluding weakly correlated impact links; Process boundary termination: When propagating across monitoring processes, if there is no direct data dependency, the branch terminates, retaining only the direct impact within the same process.

[0102] Taking the upstream tracing scenario as an example, for the daily cooling rate index node in the water temperature control scenario, the system reverses along the derivation relation to find the corresponding statistical calculation task node, then reverses along the input to find the processed temperature data node, continues along the write and report relation to find the original temperature data node on the industrial control computer side, then reverses along the parsing relation to find the original message node, and finally traces along the port transmission and acquisition relation to the corresponding acquisition module and temperature sensor node, forming a complete upstream tracing path.

[0103] Taking the downstream impact analysis scenario as an example, for the fault node of the acquisition module numbered fifty in the water temperature control scenario, the system finds the corresponding original message node by following the forward direction of the returned message relationship, and then finds the original temperature data node by following the forward direction of the parsed relationship. It continues to traverse all the anomaly identification task, missing information filling task and statistical calculation task nodes that depend on the data of this module by following the forward direction of the input to the relationship. Finally, it locates all the affected processed data, daily average temperature index, daily maximum temperature index and cooling rate index nodes, and completely sorts out the downstream impact range of the acquisition module failure.

[0104] Based on the kinship path scoring formula, a comprehensive weighted calculation is performed, integrating single-edge confidence, path length penalty coefficient, and evidence completeness coefficient, and the retrieved paths are ranked according to their scores. Multiple candidate kinship paths are quantitatively scored, ranked according to their scores, and the path with the highest credibility and most complete evidence is returned first to support rapid verification by engineers. The path score comprehensively considers three core elements, and the final score is obtained by multiplying these three elements together. The core parameters and calculation rules in the path scoring formula are as follows: the path length penalty coefficient λ is 0.1, meaning that for each additional hop in the path, the path score decreases exponentially by about 10%, prioritizing the return of the shortest core path; the evidence completeness coefficient η ranges from 0.2 to 1.0, and the calculation rules are as follows: when each edge on the path is bound to at least one type of valid evidence, the base coefficient is 0.2; for each additional type of evidence source (log / script / ledger), the coefficient increases by 0.2; when all edges on the path are bound to both log and script evidence, the coefficient takes the maximum value of 1.0; when there is a model completion edge in the path, the confidence of the corresponding edge is calculated based on the predicted value, and the evidence completeness coefficient is reduced by 0.1 overall.

[0105] Path retrieval returns a maximum of 5 candidate paths, sorted from highest to lowest overall score. Paths with a score below 0.3 are filtered out. The kinship path score is calculated based on edge confidence, path length, and evidence completeness. In the formula, This indicates a candidate lineage path. Representing an edge Confidence level, Indicates path length. This represents the path length penalty coefficient. This represents the coefficient of evidence completeness.

[0106] The first term is the product of the confidence scores of all edges within the path. The higher the confidence score of a single edge, the stronger the credibility of the entire path. The second term is the path length penalty, implemented through an exponential penalty function. The more edges a path contains, the stronger the penalty. Shorter, direct paths are prioritized, and the penalty strength is controlled by the path length penalty coefficient. The third term is the evidence completeness coefficient. The more complete the evidence attached to the path, such as the original log text and script location, the higher the evidence completeness coefficient. The system sorts all candidate paths from highest to lowest score, prioritizing the return of higher-scoring lineage paths.

[0107] Taking upstream tracing in a water flow temperature control scenario as an example, there are two candidate tracing paths for the daily average temperature indicator. The first path traces directly from the indicator node to the processed data node, the original data node, and the corresponding sensor node. This path contains four edges, all of which are supported by both log and script evidence. The average edge confidence is high, the evidence completeness coefficient is high, and the final overall score is high. The second path requires passing through an intermediate temporary cache data node. This path contains six edges, some of which only have single log evidence. The average edge confidence is low, the evidence completeness coefficient is low, and the final overall score is lower than the first path. After sorting, the system prioritizes the first path as the preferred result, allowing engineers to quickly complete the core link verification.

[0108] The system integrates kinship retrieval subgraphs, processing rules, and node engineering attributes to generate structured text, outputting complete and interpretable kinship analysis results. The interpretable kinship analysis results use a standardized structured output, consistently containing five parts: Basic information: including the name of the analyzed object, analysis type (upstream tracing / downstream impact), analysis time range, and triggering reason. Core kinship link: listing all nodes and relationship types along the path in flow order, annotating the confidence level and evidence type of each relationship. Key rule explanation: extracting the core processing rules involved in the path, explaining the specific logic and parameters of data transformation. Source tracing evidence list: listing all source tracing evidence associated with the path, including evidence type, original text summary, and source location. Comprehensive evaluation conclusion: providing a comprehensive path score, link reliability assessment, and engineering application suggestions.

[0109] The output format supports both structured JSON and natural language text, adapting to both system calls and human reading scenarios. It integrates the retrieved kinship subgraphs, path evidence, processing rules, and key node attributes into structured natural language text, outputting complete and interpretable kinship analysis conclusions. Engineers can obtain all core information simply by viewing the graph structure.

[0110] The system extracts all node and edge information from the top-ranked lineage paths, identifies the entity names and core engineering attributes corresponding to the nodes, and organizes the relational meanings and supporting evidence for the edges. It also extracts the specific rule content of the processing rule nodes along the path, organizing it into a coherent text description according to the logical sequence of data flow. The generated analysis results include a complete lineage traceability analysis as well as rule descriptions and supporting evidence for key processing steps, which can be directly used for data quality auditing and interpretation of monitoring results.

[0111] Taking the interpretation of the indicator generation path in a water flow temperature control scenario as an example, for the daily cooling rate indicator, the interpretable results generated by the system will fully explain that the indicator originates from a statistical calculation task. The calculation process uses cooling rate calculation rules, and the input data includes processed hourly temperature data, early morning temperature data, and continuous time series data. The processed data comes from the anomaly identification and missing data filling task, while the raw data comes from the temperature sensor of the designated dam section, collected by the acquisition module numbered fifty, and reported through the corresponding serial port. The results also mark the log evidence and script evidence corresponding to each link, clarifying the confidence level of each lineage. Engineers can directly verify and audit the indicator generation path based on these results.

[0112] Using the water flow temperature control monitoring data of three consecutive dam sections of a large hydropower station as the verification scenario, the test data scale is as follows: 128 temperature measuring points were deployed, 24 acquisition modules were set up, 32 communication ports were set up, 28 supporting Python cleaning scripts and 18 SQL statistical scripts were used, and a total of 126,000 industrial control computer logs and 83,000 server logs were collected.

[0113] This method was used to construct a lineage graph and its effectiveness was verified. The results are as follows: the initial rule extraction yielded 2136 nodes and 3752 lineage edges; after completion using a relational graph convolutional network, 428 new implicit lineage edges were added, with a manually verified accuracy of 92.3%, effectively supplementing multivariate dependencies not recorded in the logs. The average time for upstream tracing of a single node across the entire link was 118ms, and the average time for downstream impact inference was 142ms, meeting the real-time query requirements of the project. Compared with the traditional metadata configuration lineage method, this method improves the lineage link completeness by 27.4%, reduces the field-level dependency miss rate by 24.1%, and improves the source tracing efficiency of data quality auditing by 62%.

[0114] In one implementation, such as Figure 2 As shown, this application also provides an automatic system for constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects, including: The multi-source monitoring data access module 201 is used to collect monitoring data during construction and operation, and synchronously collect industrial control computer logs, server logs, Python and SQL scripts, measurement point ledgers, acquisition module configurations, measurement point equipment lists, anomaly record tables, statistical indicators, database field metadata, and divide standardized logs and script parsing objects to adapt to various running files; The lineage graph pattern definition module 202 is used to build a lineage graph architecture specific to hydropower projects. It configures monitoring equipment, raw data, monitoring indicators, engineering objects, acquisition ports, raw messages, processing rules, report status nodes and corresponding relationship sets, extracts three types of features: node text semantics, node type, and engineering attributes, and concatenates them to generate node input vectors. The bloodline triple automatic generation module 203 is used to extract template slots from logs. It parses Python and SQL ETL scripts through an abstract syntax tree and uses triple extraction formulas to generate bloodline records containing subject, predicate, object, confidence level, and evidence text. Homologous evidence aggregation increases confidence level, and low-confidence and ambiguous bloodline candidate edges are transferred to the manual verification queue. The initial graph construction and evidence binding module 204 is used to write all candidate triples into the graph database, complete node alignment and deduplication according to the measurement point number, device number, module number, port number, field name, task name, and timestamp, bind complete traceability materials for each bloodline edge, and manually verify the data and retain it as high-quality positive samples for network training. The implicit kinship prediction module 205 is used to adopt a relation graph convolutional network, iteratively update the hidden features of nodes based on the multi-layer node representation update formula, construct a training set through type-constrained negative sampling, calculate the probability of kinship existence using a bilinear scoring matrix, complete model training with binary cross-entropy loss, and mine unrecorded indicator derivation and cross-variable implicit kinship relationships. The bloodline tracing intelligent analysis module 206 is used to trace the upstream collection link in reverse based on the completed map and to infer the downstream impact range of abnormal data in forward. It combines path confidence, path length, and evidence completeness to calculate the path score and output interpretable bloodline analysis conclusions with complete evidence.

[0115] The computer-readable storage medium provided in the above embodiments of this application and the automatic construction and analysis method of lineage maps of multi-source monitoring data of hydropower projects provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application programs stored therein.

[0116] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of the method, system, electronic device, and readable storage medium for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects are basically similar to the embodiments of the method for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects described above, and are therefore described relatively simply. Relevant parts can be referred to in the descriptions of the embodiments of the method for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects described above.

Claims

1. A method for automatically constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects, characterized in that, include: Acquire various monitoring data during construction and operation, and synchronously collect industrial control computer logs, server logs, Python and SQL scripts, measurement point ledgers, acquisition module configurations, measurement point equipment lists, anomaly record tables, statistical indicators, database tables and field metadata, and divide them into standardized log templates and script parsing objects; Define a lineage graph pattern for hydropower project monitoring data, and set up a set of nodes and relationships for monitoring equipment, raw data, monitoring indicators, project objects, acquisition ports, raw messages, processing rules, and report status. Extract three types of features from the nodes: textual semantics, node type, and project attributes, and combine them as node inputs. Template slot extraction is performed on the logs, and the ETL script is parsed using an abstract syntax tree. Based on the triple extraction formula, a lineage record containing predicate, subject, object, confidence level, and evidence text is generated. Homologous evidence is merged to increase confidence level, and low-confidence candidate edges are sent to the manual verification queue. Candidate triples are written into a graph database to construct an initial lineage graph. The graph is then aligned and deduplicated based on the measurement point number, device number, module number, port number, field name, task name, and timestamp. Each lineage edge is bound to the original log text and script location as source evidence. The results of manual verification are used as positive samples for the graph neural network. Based on the relational graph convolutional network, iterative calculation is performed according to the multi-layer node representation update formula. Type-constrained negative sampling is used to construct the training sample set. The probability of kinship between nodes is calculated with the help of the bilinear scoring matrix. Training is completed with binary cross-entropy loss to predict un-recorded index derivation and cross-variable implicit kinship edges. By tracing the upstream original collection link back to the complete map and extrapolating the downstream impact of anomalies, the results of interpretable kinship analysis are output by comprehensively scoring confidence level, path length, and evidence completeness.

2. The method as described in claim 1, characterized in that, Template slot extraction is performed on the logs. An abstract syntax tree is used to parse the ETL script. Based on the triple extraction formula, a lineage record containing predicate, subject, object, confidence level, and evidence text is generated. Homologous evidence is merged to increase confidence. Low-confidence candidate edges are sent to a manual verification queue, including: Template recognition and slot extraction are performed on various logs from industrial control computers and servers. Abstract syntax trees are used to parse both Python and SQL ETL scripts. A complete lineage record containing subject, predicate, object, confidence level, and evidence text is generated based on a triplet extraction formula. The triplet extraction formula is as follows: In the formula, Indicates from the first Candidate lineage records extracted from log entries or script snippets. , , They represent the subject, predicate, and object, respectively. Indicates the confidence level. Representing the evidence text, This represents an extraction function consisting of template rules, a script parser, and a necessary semantic extraction model. Indicates the first A log entry or script snippet, This indicates the corresponding log template or script parsing rule; When multiple sources of evidence exist for the same bloodline, the evidence is merged and the confidence level is increased. Low-confidence bloodline candidate edges are sent to the manual verification queue, and the results of the manual verification are used as positive samples for training the graph neural network.

3. The method as described in claim 1, characterized in that, Candidate triples are written into a graph database to construct an initial lineage graph. Deduplication is performed based on the measurement point number, device number, module number, port number, field name, task name, and timestamp. Each lineage edge is bound to source evidence from the original log text and script location. The results of manual verification are used as positive samples for the graph neural network, including: Write all candidate pedigree triples obtained from the log template and ETL script parsing into a graph database to build an initial monitoring data pedigree graph. For nodes, the system performs merging and alignment and removes duplicate nodes by considering multiple dimensions such as measurement point number, device number, module number, port number, field name, task name, and timestamp. If the same blood relationship is generated by multiple sources of evidence, then all evidence sets should be merged and the corresponding confidence level increased; For each bloodline edge, bind the original log text, log time, script file name, script line number, and extraction rule number to a complete set of traceability materials; High-confidence matching results are directly stored in the database, while low-confidence or ambiguous candidate bloodline edges are transferred to the manual verification queue. Records that have been manually verified are retained as high-quality positive samples for training relational graph convolutional networks.

4. The method as described in claim 1, characterized in that, Based on a relational graph convolutional network, iterative calculations are performed according to the multi-layer node representation update formula. A type-constrained negative sampling is used to construct the training sample set. The probability of kinship between nodes is calculated using a bilinear scoring matrix. Training is completed with binary cross-entropy loss. This predicts unexplained index derivation and cross-variable implicit kinship edges, including: The node feature vectors generated by text embedding, type one-hot encoding, and engineering attribute concatenation from the initial kinship map are used as node inputs, and a relational graph convolutional network is used to perform graph processing. Based on the multi-layer node representation update formula, the entire set of blood relations is traversed layer by layer. After weighted normalization of the features of neighboring nodes under each relationship, a non-linear activation function is superimposed to iterate and update the hidden representation of each node. A balanced training sample set is constructed by using engineering rule-constrained negative sampling, with the real bloodline obtained by manual verification as the positive sample; for any node pairing and corresponding relationship type, the bloodline existence prediction score is output by operating the relationship-specific bilinear scoring matrix. The network training is completed by back-updating all learnable weight matrices of the network using binary cross-entropy as the global loss function. After training, the network is used to predict the derivation of indicators not explicitly recorded in the logs and scripts within the graph, as well as potential cross-variable lineage dependencies, and output missing candidate lineage edges to improve the initial monitoring data lineage graph.

5. The method as described in claim 4, characterized in that, Based on the complete phylogenetic map, the upstream original data collection link is traced backward, and the downstream impact of anomalies is deduced forward. A comprehensive score is applied based on confidence level, path length, and evidence completeness to output interpretable phylogenetic analysis results, including: Based on the complete monitoring data lineage map that completes the prediction and completion of missing edges, the analysis execution logic is divided into three categories: upstream tracing, downstream impact, and intelligent interpretation. A bidirectional retrieval path is established based on the entire lineage relationship from input to derivation, writing, and reporting of the map. The upstream acquisition nodes of the entire link, from monitoring indicators and abnormal records, are retrieved in reverse from sensors, acquisition modules, and original messages. All affected processing data and monitoring indicators are traversed in the forward direction from equipment failure and data missing records. Based on the bloodline path scoring formula, a comprehensive weighted calculation is performed by integrating the confidence of a single edge, the path length penalty coefficient, and the evidence completeness coefficient, and the search paths are sorted according to the score. Integrate the kinship retrieval subgraph, processing rules, and node engineering attributes to generate structured text and output complete and interpretable kinship analysis results.

6. An automatic system for constructing and analyzing lineage maps of multi-source monitoring data in hydropower projects, characterized in that, The system is used to execute executable instructions to perform the automatic construction and analysis method of lineage maps of multi-source monitoring data of hydropower projects as described in any one of claims 1 to 5.

7. An electronic device, characterized in that, include: First processor; The processor includes a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute the automatic construction and analysis method for lineage mapping of multi-source monitoring data of hydropower projects according to any one of claims 1 to 5 by executing the executable instructions.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the second processor, it implements the method for automatic construction and analysis of lineage maps of multi-source monitoring data of hydropower projects as described in any one of claims 1 to 5.

Images