A multi-role-oriented hydroelectric power operation management and control cockpit construction method and system

Abstract

The application provides a multi-role-oriented hydropower operation management and control cockpit construction method and system, relates to the cockpit intelligent construction technical field, and comprises the following steps: constructing and configuring software and hardware resources of a unified data base, configuring an extension interface for unified access of multi-source heterogeneous data; collecting production data of a hydropower control center and each hydropower station to form a multi-source database; obtaining cockpit demand text; calculating demand correlation to realize function module configuration of each cockpit and construction of a drilling analysis link; using a visual chart tool to respectively build front-end display interfaces of a group-side cockpit, a regional-side cockpit and a station cockpit, and combining the multi-source database and the extension interface for unified access to construct the hydropower operation management and control cockpit. The application effectively improves the intelligent level and construction efficiency of hydropower production operation management and control.

Description

Technical Field

[0001] This invention relates to the field of intelligent cockpit construction technology, and more specifically, to a method and system for constructing a multi-role hydropower operation and management cockpit. Background Technology

[0002] Hydropower operation and management involves multiple management levels, including the group, regional control centers, and power plants, as well as various professional roles such as operation, dispatch, dam management, and technical supervision. Currently, hydropower companies have generally built various production monitoring systems, such as SCADA, hydrological monitoring, dam monitoring, and equipment status monitoring, accumulating massive amounts of multi-source heterogeneous data.

[0003] However, most operational control dashboards for different roles adopt the traditional model of manually sorting out requirements, custom development, and deployment one by one, which has the following technical problems: (1) Existing methods require business personnel to sort out the management requirements of each level of the group, region, and plant, and then the developers manually configure indicators, design charts, and write drill-down logic. The whole process is long and repetitive, making it difficult to respond quickly to business changes. (2) The core indicators, data granularity, and permission scope of users at different levels and in different positions are significantly different. Traditional dashboards are usually designed separately for a certain type of role and lack a unified modeling method from requirement text to multi-role view, resulting in weak cross-level data association and discontinuous drill-down paths, making it difficult to achieve vertical penetration analysis of the group, region, and plant. (3) Although hydropower companies have built a unified data platform, there is a lack of explicit knowledge association between the data indicators and business dimensions of each business system, resulting in weak linkage ability of the dashboard when performing cross-topic analysis.

[0004] There are currently no effective solutions to the problems in the relevant technologies. Summary of the Invention

[0005] In view of this, the present invention provides a method and system for constructing a multi-role hydropower operation and management cockpit to solve the aforementioned problems.

[0006] To solve the above problems, the specific technical solution adopted by the present invention is as follows:

[0007] According to a first aspect of the present invention, a method for constructing a multi-role hydropower operation and control cockpit is provided, comprising the following steps:

[0008] S1. Based on pre-built hardware and software resources, configure an extended interface for unified access to multi-source heterogeneous data;

[0009] S2. Collect production data from the hydropower control center and various hydropower plants, and perform data quality verification and data classification and integration processing on the production data to form a multi-source database;

[0010] S3. Obtain the dashboard requirements texts for the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level.

[0011] S4. Based on the topic decoupling method of the demand topology graph, the topic decoupling of the cockpit demand text of the organizational level is performed to generate topic demand subgraphs. Combined with knowledge graph technology and tag coupling strength analysis, the demand correlation degree is calculated to realize the construction of functional module configuration and drill-down analysis link of each cockpit.

[0012] S5. Based on the functional module configuration and drill-down analysis link of each cockpit, use visualization chart tools to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively, and combine multi-source databases and unified access extension interface to build hydropower operation and management cockpit.

[0013] According to a second aspect of the present invention, a multi-role hydropower operation and control cockpit construction system is provided, the system comprising:

[0014] The data configuration module is used to build and configure the hardware and software resources of a unified data base according to the data volume, real-time requirements and communication protocol types of the hydropower control center and each hydropower plant. Based on the hardware and software resources, it configures a unified access extension interface for multi-source heterogeneous data.

[0015] The data acquisition module is used to collect production data from the hydropower control center and various hydropower plants, and to perform data quality verification and data classification and integration processing on the production data to form a multi-source database.

[0016] The requirement elicitation module is used to obtain the dashboard requirement texts from the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level.

[0017] The association analysis module is used to perform topic decoupling on the cockpit requirement text of the organization level based on the topic decoupling method of the requirement topology graph, generate topic requirement subgraphs, and calculate the requirement association degree by combining knowledge graph technology and tag coupling strength analysis, so as to realize the construction of functional module configuration and drill-down analysis link of each cockpit;

[0018] The cockpit building module is used to configure and analyze the functional modules of each cockpit, and to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively using visualization chart tools. Combined with multi-source databases and unified access extension interfaces, it constructs a hydropower operation and management cockpit.

[0019] The beneficial effects of this invention are as follows:

[0020] 1. This invention achieves standardized access and governance of multi-source heterogeneous data by constructing a unified data foundation. It adopts demand topology graph topic decoupling and knowledge graph technology to automatically transform the natural language requirements of the group, region and plant into the configuration of cockpit functional modules and drill-down analysis links, thereby quickly building a visual cockpit for multiple roles. It has the advantages of high automation, accurate role adaptation, strong cross-level collaboration capability and good scalability, effectively improving the intelligent level and construction efficiency of hydropower production operation and management.

[0021] 2. This invention uses demand topology graph topic decoupling and knowledge graph technology to automatically transform scattered textual demands into structured hierarchical topic subgraphs, cross-level association matrices, and indicator-dimension-permission triples, thereby realizing the intelligent generation of cockpit functional modules and drill-down links. This significantly reduces the cost of manual analysis and configuration, while also having good scalability and reusability, and can effectively support the intensive management and intelligent decision-making of hydropower production and operation. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of a method according to an embodiment of the present invention;

[0024] Figure 2 This is a technical architecture diagram of a real-time data acquisition program according to an embodiment of the present invention;

[0025] Figure 3 This is a diagram of the overall data governance architecture according to an embodiment of the present invention;

[0026] Figure 4 This is a hardware structure block diagram of the host device according to an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0028] The methods and embodiments provided in this application can be executed on a host device or a similar computing device. Taking running on a host device as an example, such as... Figure 4 As shown, the host device may include one or more ( Figure 4 Only one is shown in the diagram. The processor (which may include, but is not limited to, a microprocessor (MCU) or programmable logic device (FPGA), etc.) and storage for storing data are also shown. The host device may further include transmission devices for communication functions and input / output devices. Those skilled in the art will understand that... Figure 4 The structure shown is for illustrative purposes only and does not limit the structure of the host device described above. For example, the host device may also include components that are larger than... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown.

[0029] According to an embodiment of the present invention, a method and system for constructing a multi-role hydropower operation and management cockpit are provided.

[0030] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments, such as... Figure 1 As shown, according to a first embodiment of the present invention, a method for constructing a multi-role hydropower operation and management dashboard is provided, comprising the following steps:

[0031] S1. Based on pre-built hardware and software resources, configure an extended interface for unified access to multi-source heterogeneous data;

[0032] Specifically, based on the data volume, real-time requirements, and communication protocol types of the hydropower control center and various hydropower plants, a unified data foundation of hardware and software resources is constructed and configured. Based on the hardware and software resources, a unified access extension interface is configured for multi-source heterogeneous data.

[0033] It should be noted that the hardware and software resources for building and configuring a unified data infrastructure include hardware resources, software resources, etc. Hardware resources include computing resources, storage resources, network resources, etc.

[0034] Computing resources are allocated based on the scale of production data access, data acquisition frequency, and real-time computing requirements of each hydropower plant and control center. Several high-performance servers are configured as computing nodes for the data infrastructure. For example, for scenarios with over 500,000 access points and a data acquisition frequency of ≤1 second / time, at least five x86 architecture servers can be configured, each with at least 32 CPU cores and 128GB of memory, using a cluster deployment approach and a load balancer to distribute data processing tasks. Storage resources are configured based on the historical data retention period (typically 3-5 years) and real-time data caching requirements, using a hybrid storage architecture. Network resources are configured based on the communication bandwidth and real-time requirements between the control center and each plant, with a backbone network bandwidth of at least 1000Mbps. A dedicated data acquisition gateway is deployed on the control side to support breakpoint resumption and traffic shaping, ensuring no data loss during network fluctuations.

[0035] The software resources include the operating system and basic environment, data access components, data processing and storage components, etc. The operating system and basic environment consist of a 64-bit Linux operating system installed on each server node, configured with a Docker containerized runtime environment for flexible deployment of subsequent components. The data access component is an IoT data acquisition platform supporting multiple industrial protocols, used to connect to SCADA systems, automatic hydrological monitoring systems, dam safety monitoring systems, etc., from different vendors at the hydropower plant. The data processing and storage components are used to store real-time production data, with a data retention policy of retaining raw data for one year and aggregated data for five years.

[0036] In addition, the extended interface for unified access to multi-source heterogeneous data includes: (1) providing a pluggable protocol conversion module. When a new communication protocol needs to be accessed, only the corresponding protocol parsing plugin needs to be developed and registered to the adaptation layer, without modifying the core data processing logic. (2) defining a unified data access specification, requiring all access data to be reported in the format of a four-tuple of "measurement point code, timestamp, value, quality stamp", and supporting multiple serialization methods such as JSON, Protobuf, and binary. (3) providing a Web management interface, supporting dynamic addition / deletion of data sources, modification of acquisition frequency, configuration of data filtering rules, etc. during runtime, avoiding downtime for adjustments due to changes in requirements.

[0037] S2. Collect production data from the hydropower control center and various hydropower plants, and perform data quality verification and data classification and integration processing on the production data to form a multi-source database;

[0038] It should be noted that establishing a multi-source database is crucial for data access to the cockpit. This data access aims to support the comprehensive cockpit's panoramic display and intelligent business application analysis. The main data sources are the regional control center, production management systems at various plants and stations, and various monitoring and surveillance systems. The accessed data primarily consists of real-time / near-real-time sensing data from measurement points, while also considering key business data and model data. Major business systems include computer monitoring systems, electrical energy monitoring, equipment status monitoring, water conditions monitoring, dam monitoring, and video security systems. The key access systems include real-time data, some historical data, model calculation results, alarm data, and other production-related data.

[0039] Data access follows the principles of prioritizing the source and prioritizing centralized control:

[0040] (1) Source Priority: Prioritize direct data collection from the source system to ensure the timeliness and accuracy of the data. If source collection is difficult, data can also be obtained from mature business systems that have been tested and proven over a long period of time and have reliable data quality.

[0041] (2) Centralized control priority: When the same data exists in both the plant and the regional centralized control center, it should be collected from the regional centralized control center in principle.

[0042] During data acquisition, the process is executed through a data acquisition interface program. This program, applied to both the plant and regional sides, primarily comprises a protocol parsing module and a data transfer module. At the plant level, the protocol parsing module is deployed in the edge integrated machine of the security zone, and the data transfer module is also deployed in the edge integrated machine. After data aggregation, it is uniformly uploaded to the hydropower smart platform via the program's transfer capability. There, it interfaces with the data transfer module already deployed on the base, and after parsing and processing, the data is stored in the data warehouse. At the regional side, the protocol parsing module of the data acquisition program is deployed in the hydropower smart platform's data forwarding virtual machine. This module parses data from the hydropower centralized control platform and various systems on the regional side. After aggregation, it is uniformly uploaded to the hydropower smart platform via the program's transfer capability, and after parsing and processing, the data is stored in the data warehouse.

[0043] The data acquisition program adopts a cross-machine design pattern, comprising a protocol parsing (Input, hereinafter referred to as I) module, a data dumping (Output, hereinafter referred to as O) module, a configuration management module, and a logging module. The I and O modules are used for data parsing and data dumping functions. Each I module contains a protocol or standard, and each O module contains a dumping protocol, standard, or API. The module architecture design of the data acquisition program is as follows: Figure 2As shown: The data acquisition program adopts a star topology. Module I, the protocol parsing module, is deployed in a distributed manner according to the resource availability of the acquisition node servers. It primarily connects to data sources, parsing source data through embedded industrial control protocols such as Modbus and OPCUA, and power protocols such as IEC102 / 104 and IEC60870. Module O, the protocol transfer module, supports distributed deployment according to the resource availability of forwarding servers and edge gateways, and has a built-in API for transferring data to the data platform's time-series library. Redis, as a message middleware and data caching medium, is centrally deployed, serving as a bridge between the acquisition and transmission modules. Module O obtains real-time change data from module I by subscribing to Redis channels. To ensure data continuity, the program provides data caching and breakpoint resume functionality. The central node periodically collects real-time message data from Redis. When the output of module O is interrupted, its internal logic records the interruption time and stores the collected data in a file format. Once the network is restored, O reads the cached file data and resumes transmission.

[0044] In the data acquisition phase, differentiated acquisition strategies should be adopted based on the characteristics of different types of data to achieve efficient and reliable data integration.

[0045] Time-series data acquisition: The time-series data acquisition program adopts a star topology. Module I, serving as the protocol parsing module, is deployed in a distributed manner according to the resource availability of the acquisition node servers. It primarily connects to data sources, parsing source data through embedded industrial control protocols such as Modbus and OPCUA, and power protocols such as IEC102 / 104 and IEC60870. Module O, serving as the protocol transfer module, supports distributed deployment according to the resource availability of forwarding servers and edge gateways. It has a built-in API for transferring data to the time-series database of the intelligent data platform. Redis, as the message middleware and data caching medium, is centrally deployed, acting as a bridge between the acquisition and transmission modules. The O module obtains real-time change data from I by subscribing to Redis channels. To ensure data continuity, the program provides data caching and breakpoint resume functionality. The central node periodically collects real-time message data from Redis. When the O module's output is interrupted, its internal logic records the interruption time and stores the collected data in a file format. Once the network is restored, O reads the cached file data and resumes transmission.

[0046] Structured Data Acquisition: For structured data in relational databases such as those on plant and regional control platforms, a dual-mode collaborative mechanism of scheduled incremental data retrieval and CDC change capture is adopted. Databases are scanned periodically via standard JDBC / ODBC interfaces, accurately capturing incremental changes based on data update timestamps or archived database logs, avoiding network bandwidth waste caused by full data collection. Collected data is efficiently integrated with the data warehouse through the JDBC interface built into the O module, supporting custom field mapping rules such as automatic data type conversion and intelligent field name matching, ensuring compatibility between source and target table structures. To ensure data reliability, data is automatically retried upon push failure. An alarm is triggered when the cumulative retries exceed a threshold, and error details are written to the system log for maintenance and repair, forming a complete closed loop of acquisition, transmission, and fault tolerance.

[0047] Unstructured Data Acquisition: For unstructured data such as log files and video streams, an acquisition architecture of "protocol adaptation + storage decoupling" is constructed. File-level transfer on traditional devices is achieved through integration of FTP / SFTP protocols, while seamless integration with modern object storage, such as the MinIO S3 compatible interface, is supported via HTTP / HTTPS RESTful APIs. The acquisition module automatically identifies file types and applies differentiated processing strategies: small files (<100MB) are directly transmitted using memory buffering, while large files (≥100MB) are uploaded in chunks concurrently. MD5 checksums are supported during transmission to ensure data integrity. After data is successfully written to MinIO, the metadata database is automatically updated to record key information such as the file storage path, providing a foundation for subsequent data governance.

[0048] Furthermore, data quality verification and data classification and integration processing are performed on production data, which constitutes data governance. Data governance covers all types of data resources, including not only structured production operation and management data from time-series and relational databases, but also semi-structured data such as logs and reports, as well as unstructured data such as technical documents, specifications, drawings, and images, ensuring that the governance system covers all data assets of the hydropower smart platform. The overall data governance solution architecture diagram is shown below. Figure 3 As shown. Data quality verification includes integrity verification, validity verification, etc. Data classification can be based on business themes to categorize data that has passed quality verification.

[0049] S3. Obtain the dashboard requirements texts for the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level.

[0050] It should be noted that the control cockpits for the three organizational levels—group management, regional control, and plant / station execution—are respectively: the group-side control cockpit, the regional-side control cockpit, and the plant / station-side control cockpit. Specific control requirements are as follows:

[0051] The group-level cockpit is designed for group headquarters leaders and production management departments. It serves to provide a comprehensive overview of the group's production operations, assess regional differences, identify systemic issues, and support resource coordination and strategic decision-making. The group cockpit is divided into two types, A and B. Group A cockpit is for external display, while Group B cockpit is used by production management departments and the Electric Power Research Institute for daily monitoring. The content displayed in Group B cockpit is shown in Table 1.

[0052] Table 1. Content and Display Method of the Group Side Cockpit

[0053]

[0054] The regional control center and specialized management departments utilize multi-dimensional data fusion and intuitive graphical presentation to showcase key indicators, risk warnings, task execution, and management loops. This supports operational status identification, work coordination, and rapid response to emergencies, enabling the monitoring of operational status across multiple plants within the region, collaborative scheduling analysis, key risk supervision, and specialized task coordination. Simultaneously, it connects to the group-side control center, providing drilling-down functionality to facilitate supervision, management, and business guidance for regions and plants. The content and presentation methods of the operational control center are shown in Table 2.

[0055] Table 2. Content and Display Method of the Operational Cockpit

[0056] The plant-side control room is primarily designed for plant production management, operation, and maintenance personnel. It focuses on the real-time display and comprehensive analysis of the plant's operational status, task execution, safety risks, and equipment status. It aims to aggregate data and information from various functional control rooms, providing a comprehensive view of key indicators such as the overall plant's operational status, equipment health, operational safety, and dispatch execution. Content includes basic asset information, real-time unit operation and performance, benchmarking indicators, key hydrological information, equipment health assessment, technical supervision, and maintenance and improvement progress. This helps plant managers clearly understand the overall production, equipment, and safety situation of their unit and receive significant risk information through the early warning notification bar. Compared to the regional control room, it places greater emphasis on detailed operational data for the plant and the tracking of all potential hazards / defects.

[0057] S4. Based on the topic decoupling method of the demand topology graph, the topic decoupling of the cockpit demand text of the organizational level is performed to generate topic demand subgraphs. Combined with knowledge graph technology and tag coupling strength analysis, the demand correlation degree is calculated to realize the construction of functional module configuration and drill-down analysis link of each cockpit.

[0058] As a preferred implementation, the topic decoupling method based on the demand topology graph decouples the cockpit demand text at the organizational level to generate topic demand subgraphs. It then combines knowledge graph technology and tag coupling strength analysis to calculate the demand correlation degree, thereby realizing the construction of functional module configuration and drill-down analysis links for each cockpit. This includes the following steps:

[0059] S41. Preprocess the cockpit requirement texts of each organizational level, extract all business tags from the preprocessed requirement texts, and obtain the standardized feature vectors of each cockpit requirement by numerically encoding the all business tags.

[0060] In a preferred embodiment, the preprocessing of cockpit requirement texts at each organizational level, the extraction of full business tags from the preprocessed requirement texts, and the obtaining of standardized feature vectors for each cockpit requirement through numerical encoding of the full business tags include the following steps:

[0061] S411. Perform preprocessing on the cockpit requirement texts of each organizational level, including Chinese word segmentation, stop word removal, punctuation filtering, semantic normalization of hydropower industry terms, and synonym merging.

[0062] It should be noted that the purpose of the standardized preprocessing of the requirement text is to address issues such as colloquial expressions, synonymous but different names for industry terms, and noise interference from information without business meaning in the requirement texts of the three-level dashboards of the group management, regional control layer, and plant execution layer. This avoids deviations in subsequent tag extraction and distortion of semantic analysis due to differences in text expression. In the specific implementation process, a word segmentation tool adapted to the hydropower industry corpus is used to complete Chinese word segmentation, filtering out stop words and punctuation marks without business meaning, such as modal particles and connecting words. At the same time, according to the "Specification of Hydropower Operation and Management Terminology in the Power Industry", the semantics of industry terms are normalized, unifying the synonymous and heterogeneous expressions such as hydropower unit, generator unit, unit, control center, dispatch center, and regional dispatch into industry standard terms, and merging synonyms with completely consistent business meanings. Finally, a standardized requirement text corpus with no noise, unified expression, and standardized semantics is output.

[0063] S412. Extract all business tags for hydropower operation and management from the preprocessed cockpit requirement text, and numerically encode all business tags to construct a binary association matrix of requirement items and business tags.

[0064] It should be noted that the full-volume business tag extraction and binary association matrix construction specifically includes: using a pre-set hydropower operation core business indicator thesaurus containing indicator terms such as power generation, water consumption rate, head, gate opening, unit efficiency, vibration value, leakage, equipment health, two-ticket qualification rate, hidden danger elimination rate, and technical supervision indicators, matching the preprocessed requirement text, and supplementing it with part-of-speech filtering and business expert-assisted annotation to form a full-volume business tag set T, where the total number of tags is m; in addition, for n requirement items, requirement item d is defined. i With business tag t j Indicator variable r between ij If requirement item d i Includes the tag t j If the value is 1, it is 0 otherwise. This constructs an n×m dimensional binary association matrix of demand item-business label; the matrix is ​​stored in sparse triplet form.

[0065] S413. Based on the binary association matrix of requirement items and business tags, the term frequency-inverse document frequency method is used to calculate the weight of each full business tag, so as to obtain the weighted distribution of each requirement item on different full business tags, and the weight distribution is normalized.

[0066] It should be noted that, based on the binary association matrix of requirement items and business tags, the term frequency-inverse document frequency method is used for weight calculation. First, the term frequency (TF) is calculated, which is the ratio of the frequency of a single business tag in the corresponding requirement item to the total number of tags in that requirement item. Then, the inverse document frequency (IDF) is calculated, which is the logarithm of the ratio of the total number of all requirement items to the number of requirement items containing that tag. Multiplying the TF value and the IDF value yields the weight value of each business tag in the corresponding requirement item, resulting in the weighted distribution of each requirement item across all business tags. For the weighted distribution, the min-max normalization method is used to map all weight values ​​to the 0-1 interval to eliminate the dimensional influence caused by the difference in the number of tags of different requirement items.

[0067] S414. The normalized weight distribution is used as the standardized feature vector for each cockpit requirement.

[0068] S42. Based on the standardized feature vectors of each cockpit requirement, construct the requirement topology diagram of the hydropower operation and control cockpit, and decouple the requirement topology diagram by theme to obtain three hierarchical theme requirement sub-diagrams, including the group strategic supervision theme sub-diagram, the regional collaborative scheduling theme sub-diagram, and the plant execution monitoring theme sub-diagram.

[0069] As a preferred implementation, the process of constructing a demand topology diagram for hydropower operation and management based on standardized feature vectors of each cockpit requirement, and then decoupling the demand topology diagram by theme to obtain three hierarchical thematic demand sub-graphs including a group strategic supervision theme sub-graph, a regional collaborative scheduling theme sub-graph, and a plant execution monitoring theme sub-graph, includes the following steps:

[0070] S421. Using standardized feature vectors as demand nodes, and calculating the semantic association strength between different demand nodes based on cosine similarity, the semantic association strength is used as the association edge between demand nodes to construct the demand topology graph of the hydropower operation and management cockpit.

[0071] Specifically, each standardized feature vector is treated as an independent demand node, and the node attributes fully retain the business semantics, label weights and hierarchical information of the corresponding demand. By calculating the cosine similarity between the feature vectors of any two demand nodes, the semantic association strength between the nodes is obtained, and this strength value is used as the weight of the association edge between the nodes. In this way, a demand topology map of the hydropower operation and management cockpit that can comprehensively reflect the semantic similarity relationship between all demands is constructed.

[0072] S422. Based on the organizational hierarchy affiliation identifiers pre-bound to each demand node, the nodes of the demand topology graph are divided into three-level hierarchical boundaries: group, region, and plant. The edges of the demand topology graph are weighted and corrected by calculating the subject core degree of each demand node within its respective level and combining the label coupling frequency between demand nodes, resulting in a hierarchical weighted directed demand topology graph.

[0073] It should be noted that the organizational hierarchy identifiers pre-bound to each demand node include: a group-level identifier, corresponding to the group management's dashboard requirements; a regional-level identifier, corresponding to the regional centralized control layer's dashboard requirements; and a plant / station-level identifier, corresponding to the plant / station's execution layer's dashboard requirements. These identifiers are bound during the demand collection phase based on the role of the demand text's source or by annotations from business experts. For example, dashboard demand text originating from the group headquarters' production management department is automatically bound to the group identifier, demand text originating from the regional centralized control center is bound to the regional identifier, and demand text originating from a single hydropower plant / station is bound to the plant / station identifier.

[0074] Based on this identifier, nodes in the demand topology graph are assigned to corresponding hierarchical sets. Cross-level edges are temporarily retained but will be re-evaluated later based on hierarchical boundaries. For nodes within each level, the topic core degree of each node within its level is calculated. The topic core degree is defined as the average edge weight between the node and all other nodes in the same level, to measure the representativeness of the node in its level. Simultaneously, the frequency of common business tags between any two demand nodes, i.e., tag coupling frequency, is used to weight the original cosine similarity edge. A weighted adjustment is performed, and the adjustment formula is as follows: ,in, This represents the normalized tag coupling frequency. The adjustment coefficient (range 0-1) is used to assign the corrected edge weights to each edge, and the direction of the graph is determined to be from high-level nodes to low-level nodes, i.e., group → region → plant, forming a hierarchical weighted directed demand topology graph.

[0075] S423. Based on the three-level hierarchical boundaries of the group, region and plant, the hierarchical weighted directed demand topology graph is divided into three initial subgraphs, and each initial subgraph is subjected to internal clustering to obtain the optimized initial subgraph.

[0076] As a preferred embodiment, the hierarchical weighted directed demand topology graph is divided into three initial subgraphs based on the three-level hierarchical boundaries of the group, region, and plant, and each initial subgraph is subjected to internal clustering to obtain the optimized initial subgraph, including the following steps:

[0077] S4231. Using the three-level hierarchical boundaries of group, region, and plant as hard constraints, and combining the organizational hierarchical affiliation identifiers pre-bound to each demand node, extract the demand nodes belonging to the corresponding level and the weighted association edges between demand nodes from the hierarchical weighted directed demand topology graph, remove invalid association edges across levels, and generate three initial subgraphs containing the initial subgraphs of the group level, the region level, and the plant level.

[0078] It should be noted that using the three-tiered hierarchical boundaries of group, region, and plant as hard constraints means that: each demand node has obtained a unique organizational hierarchy identifier based on its source role or expert annotation; for the determined hierarchy identifiers, three empty subgraphs are created for group, region, and plant respectively; for each demand node in the hierarchical weighted directed demand topology graph, it is added to the corresponding subgraph according to its hierarchy identifier; for each directed edge, if the two nodes connected by the directed edge have the same hierarchy identifier, i.e., both belong to the group, both belong to the region, or both belong to the plant, then the edge and its modified weight are retained and added to the corresponding subgraph; if the two nodes... If an edge belongs to a different level, such as a group node pointing to a regional node, it is determined to be a cross-level edge. However, it is not completely eliminated. Only those cross-level edges with a weight lower than a preset threshold (e.g., 0.1) or without clear business transmission meaning are eliminated. For cross-level edges with higher weights that reflect actual business drill-down requirements, they are recorded as mapping relationships between subgraphs for use in subsequent steps and are not included in the internal edge set of any initial subgraph. Finally, three initial subgraphs without cross-level edges are obtained: the group-level initial subgraph, the regional-level initial subgraph, and the plant-level initial subgraph. Each subgraph is a directed weighted graph with demand nodes as vertices and weighted directed edges within the level as edges.

[0079] S4232. Based on the standardized feature vectors of the demand nodes in the initial subgraph, and combined with the weights of the weighted association edges between the demand nodes, construct a comprehensive similarity matrix of the demand nodes in the initial subgraph.

[0080] It should be noted that for each initial subgraph, such as the initial subgraph at the group level, let it contain... Each demand node; utilizing the standardized feature vectors of each node that have been calculated. Calculate the cosine similarity between nodes. Then use the corrected edge weights If a directed edge exists between two nodes in the hierarchical weighted directed topology graph, then the weight of that edge is taken; otherwise, it is 0. Construct an adjacency weight matrix. Then, a comprehensive similarity matrix is ​​constructed using a weighted fusion method. The fusion formula is: , This is a balancing coefficient, typically ranging from 0.5 to 0.7, which can be adjusted based on actual results. This matrix reflects both the semantic similarity between nodes based on natural language and the structural association strength expressed by edge weights in the demand topology graph; for An edge that does not exist in the original graph, i.e., there is no direct connection in the original graph, let At this point, the overall similarity is contributed only by the cosine similarity; a single output is given for each initial subgraph. The comprehensive similarity matrix is ​​used as the input for subsequent clustering processing.

[0081] S4233. Based on the comprehensive similarity matrix, clustering is performed on the demand nodes in each initial subgraph, and the demand nodes in the initial subgraph are simplified and optimized according to the clustering results to obtain the optimized initial subgraph.

[0082] Specifically, using the comprehensive similarity matrix As a distance metric between nodes, the demand nodes within each initial subgraph are clustered unsupervised using a spectral clustering algorithm. The number of clusters is automatically determined by the modularity or silhouette coefficient and does not need to be preset. After clustering, the demand nodes within the same subgraph are divided into several clusters, each cluster representing a refined business sub-topic within that level.

[0083] The simplification and optimization process for each cluster includes: calculating the degree centrality of each node within the cluster, which is the sum of its comprehensive similarity with other nodes in the cluster, and selecting the nodes with the highest total comprehensive similarity. Each node serves as a core node, typically Core nodes and their edges are retained, such as edges with a comprehensive similarity greater than a preset threshold of 0.3. Non-core nodes are deleted if their average comprehensive similarity with core nodes is less than 0.2; otherwise, their attributes are merged into the most similar core node. Isolated edges generated after deleting nodes are cleaned up, while a small number of high-weight connections between clusters are retained to maintain the overall connectivity of the subgraph. After the above simplification and optimization, each initial subgraph yields an optimized initial subgraph with a significantly reduced number of nodes, but still able to represent the semantic structure of the original requirements.

[0084] S424. Based on the preset business rule base for hydropower operation and management, extract the theme features of each optimized initial subgraph.

[0085] It should be noted that the pre-built business rule base for hydropower operation and management is a structured knowledge base used to guide the identification and extraction of business-meaningful thematic features from the optimized subgraph. This rule base is built upon hydropower industry standards and specifications, as well as expert experience, and includes the following core components:

[0086] (1) The attribution relationships between various core indicators and typical business themes in hydropower operation are defined. For example, indicators such as power generation, water consumption rate, head, and unit efficiency are mapped to the operational efficiency theme; indicators such as upstream water level, inflow, gate opening, and outflow are mapped to the water situation dispatch theme.

[0087] (2) It specifies the typical relationship patterns between different organizational levels (group, region, plant) and business themes. For example, the group level focuses on strategic themes such as asset overview, operating performance, and macro-safety situation; the region level focuses on collaborative themes such as basin scheduling coordination, cross-plant benchmarking, and risk warning; and the plant level focuses on execution themes such as real-time monitoring of units, equipment maintenance management, and hidden danger investigation and tracking.

[0088] (3) Identify the topic category corresponding to the set of business tags contained in the nodes in the subgraph by combining regular expressions and keywords. For example, the pattern "water level, flow rate, rainfall" matches the water situation topic; the pattern "vibration, temperature, oil level" matches the equipment monitoring topic.

[0089] (4) For subgraphs that involve multiple business areas, their primary and secondary themes are determined based on the label weight distribution and business rules. For example, if the total weight of operational indicators such as power generation and water consumption rate in a subgraph is significantly higher than that of other indicators, it is determined to be an operational efficiency-dominated subgraph; if safety indicators such as hidden dangers and defects and the execution of two tickets have prominent weights, it is determined to be a safety production-dominated subgraph.

[0090] Based on the above rule base, for each optimized initial subgraph, the non-zero dimensions of the business labels and standardized feature vectors of all requirement nodes in the subgraph are traversed. The matching index-topic mapping rules and feature word pattern library are matched, and the matching frequency and weight score of each topic are counted. The weighting is combined with the hierarchical-topic association rules, and finally the main topic and several auxiliary topics of the subgraph are extracted to form the topic feature vector of the subgraph.

[0091] S425. Perform a matching degree verification between the subgraph theme features and the three preset levels of group strategic supervision, regional collaborative scheduling, and plant execution monitoring. After the verification is passed, the initial subgraph is labeled with the theme to obtain three hierarchical theme requirement subgraphs containing the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph.

[0092] As a preferred implementation, the process of verifying the matching degree between the subgraph theme features and the preset three-level themes of group strategic supervision, regional collaborative scheduling, and plant execution monitoring, and then labeling the initial subgraph with themes after the verification is passed, to obtain three hierarchical theme requirement subgraphs including group strategic supervision theme subgraphs, regional collaborative scheduling theme subgraphs, and plant execution monitoring theme subgraphs, includes the following steps:

[0093] S4251. The subgraph theme features extracted from each optimized initial subgraph are compared with the preset group strategic supervision theme feature template, regional collaborative scheduling theme feature template, and plant execution monitoring theme feature template to calculate the similarity between each initial subgraph and the corresponding level theme.

[0094] It should be noted that the three preset thematic feature templates are standardized vector templates pre-constructed after statistical analysis of typical cockpit requirement samples: the vector dimension of the group strategic supervision thematic feature template is consistent with the full business tag space, and it has high weight in strategic indicators such as asset overview, operating performance, macro safety situation, and benchmarking analysis; the regional collaborative scheduling thematic feature template has high weight in collaborative indicators such as basin scheduling collaboration, cross-plant benchmarking, risk warning, and scheduling execution; and the plant execution monitoring thematic feature template has high weight in execution indicators such as unit real-time operation, equipment health, hidden danger and defect tracking, and technical supervision.

[0095] For each optimized initial subgraph, the extracted subgraph topic feature vector is compared with the three templates above using cosine similarity calculation to obtain three matching degree values. The maximum value is taken as the comprehensive matching degree value of the subgraph, and the matching template type is recorded.

[0096] S4252. Based on the preset matching degree verification threshold, the comprehensive matching degree value of each initial subgraph and the corresponding level topic is verified for compliance. If the comprehensive matching degree value is greater than or equal to the preset verification threshold, the verification is deemed to have passed; otherwise, the subgraph topic feature extraction and clustering optimization operations are iteratively executed until the verification is passed or the maximum number of optimization iterations is reached.

[0097] It should be noted that the preset matching degree verification threshold The value range is 0.5-0.7, with 0.6 being preferred. For each optimized initial subgraph, if its comprehensive matching degree value... If the check passes, the subgraph initially corresponds to the template level theme with the highest matching degree. If the match fails, the verification is deemed unsuccessful. At this point, an iterative optimization mechanism is initiated. Specifically, the overall similarity fusion coefficient and the resolution parameters of the clustering algorithm are adjusted. Clustering simplification in S4233 and topic feature extraction in S424 are re-executed, and the matching degree verification is performed again. The current optimal overall matching degree value is recorded in each iteration. To avoid infinite loops, the maximum number of optimization iterations is set to 3. If the threshold is not reached after 3 iterations, the result with the highest overall matching degree is taken, and this subgraph is marked as a low-confidence match. Simultaneously, the template level corresponding to the highest matching degree is output as the default label.

[0098] S4253. For each initial subgraph that passes the verification, bind the corresponding hierarchical theme and label the theme. Also, supplement the hierarchical subordinate mapping relationship between the initial subgraphs to complete the construction of the hierarchical relationship between the initial subgraphs and obtain the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph.

[0099] It should be noted that for each validated initial subgraph, a corresponding topic name label is bound to it according to the matching template level. For example, the subgraph matching the group template is labeled "Group Strategic Supervision Topic Subgraph", the one matching the regional template is labeled "Regional Collaborative Scheduling Topic Subgraph", and the one matching the plant template is labeled "Plant Execution Monitoring Topic Subgraph". Simultaneously, based on the cross-level high-weight edges retained in step S4231, hierarchical subordinate mapping association edges are added between the current three initial subgraphs. Specifically, if there is an original cross-level edge weight greater than or equal to 0.2 between a demand node in the group subgraph and a demand node in the regional subgraph, a mapping association edge from the group subgraph node to the regional subgraph node is established between the two initial subgraphs, and the weight of this edge is recorded; similarly, a mapping association edge from the regional subgraph to the plant subgraph is established. These association edges are stored in dashed line form and are not considered internal edges of the subgraph, but are used for subsequent generation of cross-level drill-down analysis links. Finally, the three sub-graphs with completed topic labeling and hierarchical mapping will be output as the group strategic supervision topic sub-graph, the regional collaborative scheduling topic sub-graph, and the plant execution monitoring topic sub-graph, respectively.

[0100] S43. Based on knowledge graph technology, semantic association modeling is performed on the hierarchical topic requirement subgraph, and cross-level requirement association degree is calculated through tag coupling strength analysis. Based on the cross-level requirement association degree, a requirement knowledge graph containing indicator entities, business dimensions, and data permission triples is constructed. Based on the requirement knowledge graph, a set of permission binding relationships between indicator entities, business dimensions, and data permission entities is further generated, and a set of permission propagation paths and an executable permission verification chain are constructed through permission propagation analysis.

[0101] As a preferred implementation, the step of semantic association modeling of the hierarchical topic requirement subgraph based on knowledge graph technology, calculating the cross-level requirement association degree through tag coupling strength analysis, constructing a requirement knowledge graph containing triples of indicator entities, business dimensions, and data permissions based on the cross-level requirement association degree, and further generating a set of permission binding relationships between indicator entities, business dimensions, and data permission entities based on the requirement knowledge graph, and constructing a set of permission propagation paths and an executable permission verification chain through permission propagation analysis includes the following steps:

[0102] S431. Extract entity sets from the group strategic supervision theme sub-graph, the regional collaborative scheduling theme sub-graph, and the plant execution monitoring theme sub-graph, respectively;

[0103] It should be noted that, after traversing all demand nodes in each subgraph, three types of entities are extracted from the non-zero business labels corresponding to the standardized feature vector of each demand node: indicator entities, i.e., quantifiable production and operation indicators, such as power generation, water consumption rate, unit vibration amplitude, upstream water level, deformation, etc.; business dimension entities, i.e., the business domain or analysis perspective to which the indicator belongs, such as operation, scheduling, dam safety, equipment health, technical supervision, safe production, etc.; and data permission entities, i.e., data access control labels corresponding to the indicator or business dimension, such as group level, regional level, plant level, job level, etc. During extraction, type discrimination needs to be performed in conjunction with the feature word pattern library of the business rule base. When the same keyword may belong to multiple types simultaneously, multiple labels are applied according to the context and the preset entity type priority. Finally, the entity sets of each of the three subgraphs are obtained.

[0104] In addition, explicit permission scope entities, permission object entities, and operation type entities are extracted from the role permission description text using rule-based regular expression matching and keyword extraction. If no explicit permission entity is extracted for a certain level, the corresponding default permission entity in the level-position permission mapping template is bound to ensure that each organizational level has an initial permission entity as the starting point for subsequent permission propagation.

[0105] S432. Based on the extracted entity set, calculate the label coupling strength between cross-level entities, and combine the topic core degree and hierarchical association weight of the entity in its respective topic subgraph to perform weighted correction on the label coupling strength to obtain the cross-level demand association matrix.

[0106] As a preferred embodiment, the step of calculating the tag coupling strength between cross-level entities based on the extracted entity set, and then weighting and correcting the tag coupling strength by combining the topic core degree and hierarchical association weight of the entities in their respective topic subgraphs to obtain the cross-level demand association matrix includes the following steps:

[0107] S4321. Extract business tag sets from each entity set, and for entity pairs in different level topic subgraphs, calculate the ratio of the intersection size to the union size of their business tag sets to obtain the tag coupling strength.

[0108] Specifically, the list of original business tags associated with each entity is extracted as those tags that triggered the extraction in the requirement text for that entity, denoted as follows: and The tag coupling strength was calculated using the Jaccard coefficient.

[0109] ;

[0110] In the formula, This indicates the tag coupling strength, with a value between 0 and 1. It represents the degree of overlap between two entities in terms of business semantics. The larger the value, the more similar the business connotations of the two entities are, and the more likely there is a vertical association across levels.

[0111] S4322. Based on the topological characteristics of each thematic subgraph, calculate the thematic core degree of each entity in its respective thematic subgraph, and determine the hierarchical association weight by combining the hierarchical architecture relationship of group-region-plant.

[0112] It should be noted that for each entity In its subgraph, determine the set of demand nodes corresponding to it, and an entity may correspond to multiple demand nodes. Define the subject core degree of the entity. for:

[0113] ;

[0114] In the formula, It is a set containing all the demand nodes of this entity. For nodes The degree of a node in its subgraph, specifically the weighted degree of the connecting edges, reflects the importance of the node in the graph. For this entity in node The normalized TF-IDF weights in the model.

[0115] The hierarchical association weights are preset based on the hierarchical combination to which the entity belongs. Specifically, the weight between a group and a region is set to 0.8, and the weight between a region and a plant is set to 0.9, indicating that the former will have some information attenuation in business transmission, while the latter is more direct. Additionally, if two entities already have a cross-hierarchical mapping relationship in the subgraph, their weight value is multiplied by 0.5 as an additional increment to strengthen existing clearly related entity pairs.

[0116] S4323. Perform a Hadamard product operation on the cross-level demand correlation matrix and the theme core degree vector. Then, perform a weighted fusion operation on the result and the hierarchical correlation weight matrix to obtain the corrected cross-level correlation strength value. Normalize the corrected cross-level correlation strength value to generate a cross-level demand correlation matrix that includes the entity correlation strength between the three levels of group, region, and plant.

[0117] It should be noted that the Hadamard product operation refers to the element-wise multiplication of two matrices of the same type. Performing the Hadamard product operation on the temporary matrix and the topic coreity matrix yields a new matrix, thus achieving a weighted correction of the topic coreity of the original coupling strength. This corrected result is then weighted and fused with the hierarchical association weight matrix, and a fusion coefficient α (ranging from 0 to 1) is used to balance the contributions of both, resulting in a corrected cross-level association strength matrix. This matrix is ​​then row-normalized to generate a cross-level demand association strength matrix containing the entity association strengths at the group, region, and plant / station levels. The row indices of this matrix represent higher-level entities, the column indices represent lower-level entities, and the matrix values ​​represent the vertical coupling strength from higher-level entities to lower-level entities.

[0118] S433. Based on the cross-level requirement correlation matrix, construct a requirement knowledge graph containing triples of indicator entities, business dimensions, and data permissions.

[0119] It should be noted that the construction of the demand knowledge graph specifically includes: using all extracted indicator entities, business dimension entities, and data permission entities as nodes in the graph, with each node recording its source subgraph (group, region, or plant) as an attribute. Based on the cross-level demand correlation matrix, for each non-zero pair of cross-level entities in the matrix, a directed edge is established from the higher-level entity to the lower-level entity, and different semantic labels are assigned to the edge according to the entity type combination: if the source entity is an indicator entity and the target entity is a business dimension entity, the edge is marked as "belonging"; if the source entity is an indicator entity and the target entity is also an indicator entity, the edge is marked as "vertical coupling"; if the source entity is a business dimension entity and the target entity is a data permission entity, the edge is marked as "authorized". In addition, for each demand node in the hierarchical topic demand subgraph, the co-occurring indicator entities and business dimension entities are counted. If the co-occurrence frequency of the two exceeds a preset threshold, an undirected association edge is established between them, and the weight of the edge is determined by the normalized co-occurrence frequency. After defining the nodes and edges, all nodes and directed edges are stored in the graph database, thus forming a requirement knowledge graph containing multiple relationship triples such as indicator-belonging-dimension, indicator-vertical coupling-indicator, dimension-authorization-permission, and indicator-association-dimension.

[0120] S434. Based on the aforementioned requirement knowledge graph, generate a set of permission binding relationships between indicator entities, business dimensions, and data permission entities, and construct a set of permission propagation paths and an executable permission verification chain through permission propagation analysis.

[0121] It should be noted that, based on step S433, a requirement knowledge graph was constructed. On this basis, a set of permission binding relationships, a set of permission propagation paths, and an executable permission verification chain were generated. This allows for the further execution of the following steps, specifically including:

[0122] Step A1: Based on the indicator entities, business dimension entities, data permission entities, and cross-level directed edges in the requirement knowledge graph, parse the permission level, permission scope, and permission object of each data permission entity. Search backward along the authorization edge from the business dimension entity to the data permission entity to find the indicator entity that has a membership relationship with the business dimension entity. Then, bind the data permission entity to the corresponding indicator entity synchronously to form a set of permission binding relationships between indicator entity, business dimension entity, and data permission entity.

[0123] Furthermore, step A1 includes:

[0124] Step A1.1: Traverse each data permission entity in the requirement knowledge graph, parse its attributes to obtain the permission level, permission scope, and permission object; at the same time, extract the authorization edges from all business dimension entities in the graph to the data permission entities.

[0125] The permission levels include: group level, regional level, factory / station level, or job level;

[0126] The scope of permissions includes: viewing, drilling down, exporting, or alarm confirmation.

[0127] The permission objects include: indicator entities, business dimension entities, or vertical coupling edges formed by connecting indicator entities;

[0128] Step A1.2: For each authorization edge, obtain its source business dimension entity, and search in the knowledge graph for all indicator entities that have a membership relationship with the business dimension entity (i.e., the indicator entity points to the business dimension entity through the membership edge). Then bind the data permission entity corresponding to the current authorization edge to each found indicator entity, thereby forming a triplet binding record of indicator entity-business dimension entity-data permission entity.

[0129] Step A1.3: If a certain metric entity belongs to multiple different business dimensions, then multiple permission entity records are maintained for that metric entity. The permission intersection relationships between these permission entities are also recorded to prevent the permission definition of a single business dimension from overriding the permission restrictions of other dimensions. Finally, a set of permission binding relationships consisting of all binding records is output.

[0130] It should be noted that the permission intersection relationship between the permission entities, in this embodiment, includes, but is not limited to: viewable intersection is viewable, and drill-down intersection is only valid when all permission entities allow drill-down;

[0131] Step A2: Based on the set of permission binding relationships, expand step by step along the vertical coupling edges between the group, region, and plant indicator entities, pass the permission entities on the high-level indicator entities to the associated low-level indicator entities according to the hierarchical inheritance constraints, and calculate the permission propagation strength of each drill-down link to generate a set of permission propagation paths with propagation strength.

[0132] Furthermore, step A2 also includes:

[0133] Step A2.1: Based on the permission binding relationship set, extract the vertical coupling edges between group indicator entities, regional indicator entities, and plant / station indicator entities, specifically:

[0134] Starting from the group-level indicator entity, propagate downwards along the vertical coupling edge: if a certain permission entity is already bound to the group-level indicator entity, then find the regional indicator entity that has a vertical coupling edge with it, and pass the permission entity to the regional indicator entity; if the target level lacks a corresponding permission entity, then stop the propagation of this branch.

[0135] It should be noted that the transfer follows hierarchical inheritance constraints. Specifically, group-level permissions are only allowed to enter regional indicators when the corresponding region has the same or more granular permission entity. The transfer from region to plant is also based on the same logic: a region is only allowed to enter plant indicators when the corresponding plant has the same or more granular permission entity.

[0136] Step A2.2: For each established propagation path (e.g., group indicators - regional indicators - plant / station indicators), calculate its permission propagation strength. : ;in: The cross-level demand correlation degree, with a value ranging from 0 to 1, is obtained from the original cross-level demand correlation degree matrix and represents the strength of the business correlation between two level indicators. This is the hierarchical allowance coefficient, which can be either 0 or 1. It should be noted that if the permission scope of a higher-level permission allows access to a lower level (for example, the "drill down" permission of the group allows drilling down to the region), then the hierarchical allowance coefficient is 1; otherwise, it is 0. This is the role matching coefficient, which can range from 0, 0.5, or 1. It should be noted that the coefficient is determined by the degree of matching between the current user role and the data permission entity: when there is a complete match, the role matching coefficient is 1; when there is a partial match, the role matching coefficient is 0.5; and when there is no match, the role matching coefficient is 0.

[0137] Step A2.3: Assign each drill-down link and its corresponding permission propagation strength. Record these paths to create a set of permission propagation paths.

[0138] Each drilling link includes: the starting indicator entity, intermediate indicator entities at each level, the target indicator entity, and the permission entities along the way;

[0139] Step A3: Based on the set of permission propagation paths, identify conflicts for each propagation path and determine whether there are multiple permission entities with inconsistent permission scopes on the same indicator entity; if conflicts exist, shrink the scope according to the principle of least privilege.

[0140] Simultaneously, the effective permission value of each drill-down path is calculated and compared with the preset effective permission threshold. For drill-down paths with effective permission values ​​lower than the preset threshold, the path is shrunk to only display summary data and is not allowed to continue drilling down. Finally, the set of permission-constrained drill-down paths is output.

[0141] Furthermore, step A3 also includes:

[0142] Step A3.1: Traverse the set of permission propagation paths. For each indicator entity in each path, check whether it is bound to multiple permission entities at the same time. If multiple permission entities exist, further compare their permission ranges. If the permission ranges are inconsistent, it is determined that there is a permission conflict in the path. If the permission ranges are consistent, it is determined that there is no permission conflict in the path.

[0143] The scope of permissions includes: viewing, drilling down, exporting, and alarm confirmation;

[0144] Step A3.2: For paths with conflicting permissions, shrink them according to the principle of least privilege;

[0145] The shrinkage process specifically involves: viewing permissions do not automatically grant drill-down permissions, drill-down permissions do not automatically grant export permissions, and regional permissions do not automatically grant plant / station level detailed permissions. If both viewing and drill-down permissions exist on a certain indicator entity, only the propagation capability of viewing on that path is retained to suppress further propagation of drill-down permissions.

[0146] Step A3.3: For each drill-down path consisting of multiple entities, such as group indicators - regional indicators - plant indicators, calculate its effective authority value. : ;in: For the strength of permission propagation; This is the drilling depth coefficient; The intersection coefficient of permissions;

[0147] It should be noted that when the path is from the group to the region, the drilling depth coefficient is 0.8; when the path is from the region to the plant, the drilling depth coefficient is 0.9; and when the path is directly from the group to the plant, the drilling depth coefficient is 0.6.

[0148] It should also be noted that if all entities in the path have the same permission range, the permission intersection coefficient is 1; if they are only partially consistent, the permission intersection coefficient is 0.5; if there are mutually exclusive permissions, such as requiring both exportable and non-exportable permissions, the permission intersection coefficient is 0.

[0149] Step A3.4: Enter the valid permission value Compared with the preset permission threshold, specifically:

[0150] When a certain path If the path is below this threshold, it will be marked as a shrinking path, meaning that only the summary data of the starting entity of the path will be displayed and no actual drill-down operation will be allowed.

[0151] When a certain path If the value is greater than or equal to the threshold, the path is retained as an executable drill-down path; then all retained paths are aggregated to form a set of permission-constrained drill-down paths.

[0152] It should be noted that the threshold value for the permission value is 0.5.

[0153] Step A4: Based on the set of drill-down paths constrained by permissions, each path is converted into a permission verification chain that can be called by the front-end dashboard; when the user clicks on the indicator block in the dashboard to trigger drill-down, the system reads the corresponding permission verification chain and performs verification according to the user role, current level, target level and operation type. Drill-down is only allowed if the valid permission value is not lower than the preset threshold and the operation type is within the allowed range; otherwise, the summary display result of the current level is returned.

[0154] The verification chain includes: starting indicator entity, target indicator entity, business dimension entity, data permission entity, valid permission value, and allowed operation type;

[0155] Furthermore, step A4 also includes:

[0156] Step A4.1: Traverse each path in the permission constraint drill-down path set and convert it into a standardized permission verification chain structure. The specific conversion is as follows: Use the starting indicator entity of the path as the starting indicator entity of the verification chain; use the target indicator entity of the path (i.e., the indicator reached by drill-down) as the target indicator entity; extract the business dimension entities involved in the path (i.e., the business domain to which the indicator belongs) as the business dimension identifier of the verification chain; extract the data permission entities and their permission scope transmitted in the path as the data permission entities and allowed operation types (viewable, drill-downable, exportable, alarm confirmationable) of the verification chain; and set the valid permission values... This serves as the valid permission value for the verification chain; each path generates an independent permission verification chain record.

[0157] Step A4.2: Store the generated permission verification chain in a cache area that the system can quickly access (such as Redis), and bind it to the indicator blocks of the front-end cockpit. After binding, the system preloads all verification chains when the cockpit is initialized to avoid repeated path parsing at runtime.

[0158] Each indicator block can be associated with one or more verification chains, each corresponding to a different drill-down target. For example, group indicators can be drilled down to regional indicators or plant indicators.

[0159] Step A4.3: Define the execution logic for drill-down verification to form an executable permission verification chain;

[0160] The execution logic is as follows: When a user clicks on an indicator block in the cockpit and selects the drill-down operation, the front-end calls the back-end verification interface, passing in the current user role, current level (group / region / plant), target level, and operation type (e.g., view details or continue drilling); the back-end searches for the corresponding permission verification chain based on the current indicator entity and target level, and retrieves the valid permission value. and the set of allowed operation types;

[0161] like If the requested operation type is greater than or equal to the preset permission threshold and belongs to the set of allowed operation types, the verification passes and drill-down is allowed; otherwise, the verification fails, the system only returns the summary display results of the current level and gives a prompt that permissions are insufficient.

[0162] It should be noted that the verification results are returned to the front end in real time, allowing the front end to decide whether to redirect or display detailed data;

[0163] Step A5: Based on the executable permission verification chain, during the drilling process in the cockpit, the permission verification chain is used as a pre-constraint for each indicator jump, page switch, and data query. The verification chain is called level by level for judgment. If the verification passes, the indicator details, dimensional analysis results, and allowed data range of the target level are output. If the verification fails, the drilling path is blocked and the summary results of the previous level are returned. This allows the data permission entity to continuously propagate along the cross-level indicator link, shrink level by level, and participate in the drilling verification, thus solving the problem of permission constraint failure.

[0164] Furthermore, step A5 also includes:

[0165] Step A5.1: Establish a drill-down access control interceptor between the front and back ends of the cockpit; when a user drills down from the group-side cockpit to the regional side, from the regional side to the plant side, or from the plant side to the equipment measurement point / work order record, the interceptor first captures the request and extracts the current user role, current indicator entity, target level, and operation type; the operation type is: view details, continue drilling, or export data;

[0166] Step A5.2: Based on the current metric entity and target level, search for a matching verification chain in the executable permission verification chain cache; if multiple chains are found, for example, if the same metric can drill down to multiple different targets, select the most suitable one based on user role, operation type, and business context, and retrieve its valid permission value. and the set of allowed operation types;

[0167] Step A5.3: When the verification passes, the backend queries the target level's indicator details, dimensional analysis results, and data range from the multi-source database, encapsulates them, and returns them to the frontend for display;

[0168] When the verification fails, the backend blocks the drill-down path, returns the summary results of the previous level that the current user can access, and includes a permission insufficient message.

[0169] The data range specifically refers to: data filtered by row-level / column-level permissions recorded in the data permission entity;

[0170] It should be noted that the front end decides whether to redirect the interface or only display a prompt message based on the result; through this mechanism, the effect of permission propagation and constraint is achieved along the chain of group-region-plant-test point / work order, and finally the output of the cockpit drilling result constrained by the permission entity propagation path is achieved.

[0171] Through the above steps, the data permission entity is no longer confined to a static authorization relationship from a single business dimension to permissions, but instead continues to propagate along the cross-level indicator link, shrinks level by level, and participates in drill-down verification, ultimately solving the problem of permission constraints failing due to the lack of permission entity propagation path.

[0172] S44. Based on the requirement knowledge graph and hierarchical topic requirement subgraph, and combined with the permission binding relationship set, permission propagation path set and executable permission verification chain, generate the functional module configuration and hierarchical drill-down analysis link of each level of the cockpit.

[0173] As a preferred implementation, the step of generating the functional module configuration and hierarchical drill-down analysis link of each level of the cockpit based on the demand knowledge graph and hierarchical topic demand subgraph, combined with the permission binding relationship set, permission propagation path set and executable permission verification chain, includes the following steps:

[0174] S441. Based on the entity triples in the demand knowledge graph, and combined with the theme features of the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph, extract the core indicator set and core business dimension set of each organizational level cockpit respectively.

[0175] It should be noted that for the three organizational levels of group, region, and plant, all requirement nodes are traversed from the corresponding thematic subgraphs. Utilizing the triple relationships already constructed in the requirement knowledge graph, indicator entities strongly correlated with the theme characteristics of that level are extracted as the core indicator set. For example, the group level extracts macro-level indicators such as total installed capacity, total regional power generation, and safe days; the plant level extracts micro-level indicators such as real-time unit power, vibration swing, and upstream water level. Simultaneously, based on the "indicator-belongs-dimension" edges in the knowledge graph, the business dimension entities associated with each indicator are extracted, forming a core business dimension set, such as operation dimension, scheduling dimension, dam safety dimension, equipment health dimension, and technical supervision dimension. Furthermore, data permission entities connected to business dimension entities can be retrieved from the knowledge graph to form the data permission control rule set for that level's dashboard. For example, the group level can access all regional and plant data, the region level can only access data within its own region, and the plant level can only access data within its own station. After extraction, the core indicator set and core business dimension set are sorted by business importance: the sorting criteria include the number of edges connected to the indicator in the demand knowledge graph, the frequency of co-occurrence in the corresponding topic subgraph, and the weight coefficients preset in the business rule base. The business importance score of each indicator is calculated and sorted in descending order of score.

[0176] S442. Based on the core indicator set and core business dimension set of each organizational level, combined with the business rule library of hydropower operation and management, the functional modules of the requirement nodes of each level of the cockpit are divided, the indicator display component type, dimension analysis component type, early warning threshold configuration and user interaction operation method of each functional module are determined, and the corresponding data permission entity is associated with each functional module according to the permission binding relationship set, so as to generate the functional module configuration of each level of the cockpit.

[0177] It should be noted that for each organizational level, based on its core indicator set and core business dimension set, combined with the business rule base for hydropower operation and management, the rule base predefines the mapping relationship between indicators and recommended display components. For example, power generation is suitable for display using dashboards or line charts, water level is suitable for displaying using water level process curves or digital instruments, equipment health is suitable for displaying using radar charts or health scoring cards, and hidden dangers and defects are suitable for displaying using lists or heat maps. Indicators under similar business dimensions are aggregated into the same functional module. Specifically, for each functional module, the most suitable display component type for the main indicators within the module is matched from the rule base, including line charts, bar charts, dashboards, tables, geographic maps, radar charts, heat maps, etc.; the dimensional analysis component type is determined, such as time range selectors, plant filters, equipment type switches, etc.; based on the preset thresholds in the business rule base, such as warnings when the water level exceeds the flood limit level and alarms when the vibration swing exceeds the set value, warning thresholds and alarm levels are configured; and user interaction operation methods are defined, such as drill-down, filtering, refreshing, exporting, etc.

[0178] For example, on the group side, modules such as asset overview, operational performance, and safety supervision can be divided; on the regional side, modules such as watershed scheduling, cross-plant benchmarking, and risk warning can be divided; and on the plant side, modules such as real-time unit monitoring, equipment health, hidden danger and defect tracking, and technical supervision can be divided.

[0179] S443. Based on the entity association strength between the three levels of group, region and plant in the cross-level demand association matrix, and combined with the cross-level triplet relationship in the demand knowledge graph, as well as the permission propagation path set and the executable permission verification chain, construct a hierarchical drill-down analysis link with permission verification nodes.

[0180] It should be noted that non-zero association strength terms between group-level indicator entities and regional-level indicator entities, as well as non-zero association strength terms between regional-level indicator entities and plant / station-level indicator entities, are extracted from the cross-level demand correlation matrix. Simultaneously, vertical coupling edges and belonging edges in the demand knowledge graph are used to assist in determining drill-down paths. Specifically, the drill-down path is constructed as follows: For each core indicator entity in the group dashboard, such as total regional power generation, one or more regional-level indicator entities with the highest association strength are found from the cross-level demand correlation matrix. Then, for each regional-level indicator entity, the plant / station-level indicator entity with the highest association strength is found, sequentially connecting them to form a primary drill-down path of "group indicator, regional indicator, plant / station indicator". Within the plant / station dashboard, the association edges and belonging edges within the plant / station subgraph in the knowledge graph are further utilized to drill down from the plant / station indicator entity to specific equipment measurement points or work order records. Finally, the drilling analysis link is associated and bound with the functional module configuration. For each functional module that supports drilling, a corresponding drilling target level and target indicator entity are specified to form an executable hierarchical drilling analysis link description file, which is loaded by the front-end cockpit system to realize interactive drilling analysis.

[0181] Furthermore, when constructing the drill-down analysis path, a business rationality verification sub-step is added: extract the core topic tags of the current node and calculate the matching degree with the core topic tags of the target node. The drill-down path is only retained if the topic tags of the target node and the topic tags of the current node belong to the same business domain, i.e., the preset business domain synonym chain, such as the operating domain containing {power generation, load, water consumption}, or if the target node is a direct vertically coupled child node of the current node in the knowledge graph; otherwise, even if the association strength value is high, the path is automatically blocked, and a log reminder of unreasonable cross-business domain drill-down is output to the system to avoid logical errors such as drilling down to water level data based on the number of safe days.

[0182] In addition, after generating the functional module configuration and drill-down analysis links, a consistency coordination check is performed. The specific check logic is as follows: traverse each drill-down analysis link, check whether the functional module to which the starting indicator entity belongs is the same as or belongs to the functional module to which the ending indicator entity belongs, or whether they belong to the same business domain. This is determined by a preset cross-module collaboration whitelist. For example, the running module is allowed to drill down to the scheduling module, but not to the security module.

[0183] For inconsistent links discovered during verification, the following coordination strategies are implemented: (1) Prioritize adjusting the drill-down link and try to find the second most relevant metric in the same module as the alternative endpoint within the target module; (2) If no alternative metric can be found, the operation type of the drill-down path is downgraded from automatic drill-down to query-based drill-down, and cross-module drill-down is only performed after the user manually confirms; (3) Solidify the above adjustment results into the drill-down link description file to ensure that the automatically generated functional module layout and drill-down interaction logic are coordinated and consistent at the business level, and avoid confusion in user interaction.

[0184] S5. Based on the functional module configuration and drill-down analysis link of each cockpit, use visualization chart tools to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively, and combine multi-source databases and unified access extension interface to build hydropower operation and management cockpit.

[0185] It should be noted that for the three levels—group-side, regional-side, and plant-side—mature visualization charting tools are selected for front-end interface development based on the functional module configuration list and the hierarchical drill-down analysis link description file. Examples include ECharts, AntV, Highcharts, or commercial BI tools such as FineBI and Tableau. For each functional module, corresponding chart components are instantiated according to the component types in the configuration list, and corresponding data query interfaces are bound. Multi-dimensional data slicing is supported through dimensional analysis components, such as time filters, plant-side trees, and equipment selectors. Simultaneously, interactive events are configured according to the drill-down analysis link: when a user clicks on a certain indicator block in the group-side dashboard, the system automatically performs a drill-down operation to the corresponding indicator details in the regional-side dashboard or pops up a details window, passing the filtering conditions.

[0186] All chart components obtain data by calling a unified data service interface from multiple databases and update in real time according to a preset refresh frequency. Warning threshold configuration is achieved through front-end conditional coloring or pop-up alarms; when real-time data exceeds the threshold, the chart automatically turns red or an alarm message pops up. The three-tiered front-end interface is integrated into the hydropower operation and management dashboard platform via single sign-on and a unified navigation menu. Based on the extracted data permission control rule set, corresponding dashboard access permissions and drill-down ranges are assigned to users with different roles, such as group leaders, regional dispatchers, and plant operators. This ensures that users can only see the content of their authorized dashboard level and the allowed drill-down paths after logging in, thus achieving a safe, efficient, and multi-role-adaptive hydropower operation and management dashboard.

[0187] According to a second embodiment of the present invention, a multi-role hydropower operation and management cockpit construction system is provided, the system comprising:

[0188] The data configuration module is used to build and configure the hardware and software resources of a unified data base according to the data volume, real-time requirements and communication protocol types of the hydropower control center and each hydropower plant. Based on the hardware and software resources, it configures a unified access extension interface for multi-source heterogeneous data.

[0189] The data acquisition module is used to collect production data from the hydropower control center and various hydropower plants, and to perform data quality verification and data classification and integration processing on the production data to form a multi-source database.

[0190] The requirement elicitation module is used to obtain the dashboard requirement texts from the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level.

[0191] The association analysis module is used to perform topic decoupling on the cockpit requirement text of the organization level based on the topic decoupling method of the requirement topology graph, generate topic requirement subgraphs, and calculate the requirement association degree by combining knowledge graph technology and tag coupling strength analysis, so as to realize the construction of functional module configuration and drill-down analysis link of each cockpit;

[0192] The cockpit building module is used to configure and analyze the functional modules of each cockpit, and to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively using visualization chart tools. Combined with multi-source databases and unified access extension interfaces, it constructs a hydropower operation and management cockpit.

[0193] According to a third embodiment of the present invention, an electronic device is provided, the electronic device comprising: one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the steps in any of the above method embodiments.

[0194] According to a fourth embodiment of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to perform the steps in any of the above method embodiments.

[0195] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for constructing a multi-role hydropower operation and management dashboard, characterized in that, Includes the following steps: S1. Based on pre-built hardware and software resources, configure an extended interface for unified access to multi-source heterogeneous data; S2. Collect production data from the hydropower control center and various hydropower plants, and perform data quality verification and data classification and integration processing on the production data to form a multi-source database; S3. Obtain the dashboard requirements texts for the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level. S4. Based on the topic decoupling method of the demand topology graph, the topic decoupling of the cockpit demand text of the organizational level is performed to generate topic demand subgraphs. Combined with knowledge graph technology and tag coupling strength analysis, the demand correlation degree is calculated to realize the construction of functional module configuration and drill-down analysis link of each cockpit. S5. Based on the functional module configuration and drill-down analysis link of each cockpit, use visualization chart tools to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively, and combine multi-source databases and unified access extension interface to build hydropower operation and management cockpit.

2. The method for constructing a multi-role hydropower operation and control cockpit according to claim 1, characterized in that, The topic decoupling method based on the demand topology graph decouples the cockpit demand text at the organizational level, generates topic demand subgraphs, and calculates the demand correlation degree by combining knowledge graph technology and tag coupling strength analysis to realize the construction of functional module configuration and drill-down analysis links for each cockpit. The method includes the following steps: S41. Preprocess the cockpit requirement texts of each organizational level, extract all business tags from the preprocessed requirement texts, and obtain the standardized feature vectors of each cockpit requirement by numerically encoding the all business tags. S42. Based on the standardized feature vectors of each cockpit requirement, construct the requirement topology diagram of the hydropower operation and control cockpit, and decouple the requirement topology diagram by theme to obtain three hierarchical theme requirement sub-diagrams, including the group strategic supervision theme sub-diagram, the regional collaborative scheduling theme sub-diagram, and the plant execution monitoring theme sub-diagram. S43. Based on knowledge graph technology, semantic association modeling is performed on the hierarchical topic requirement subgraph, and cross-level requirement association degree is calculated through tag coupling strength analysis. Based on the cross-level requirement association degree, a requirement knowledge graph containing indicator entities, business dimensions, and data permission triples is constructed. Based on the requirement knowledge graph, a set of permission binding relationships between indicator entities, business dimensions, and data permission entities is generated, and a set of permission propagation paths and an executable permission verification chain are constructed through permission propagation analysis. S44. Based on the requirement knowledge graph and hierarchical topic requirement subgraph, and combined with the permission binding relationship set, permission propagation path set and executable permission verification chain, generate the functional module configuration and hierarchical drill-down analysis link of each level of the cockpit.

3. The method for constructing a multi-role hydropower operation and control cockpit according to claim 2, characterized in that, The process of preprocessing the cockpit requirement texts at each organizational level, extracting all business tags from the preprocessed requirement texts, and obtaining standardized feature vectors for each cockpit requirement by numerically encoding the all business tags includes the following steps: S411. Perform preprocessing on the cockpit requirement texts of each organizational level, including Chinese word segmentation, stop word removal, punctuation filtering, semantic normalization of hydropower industry terms, and synonym merging. S412. Extract all business tags for hydropower operation and management from the preprocessed cockpit requirement text, and numerically encode all business tags to construct a binary association matrix of requirement items and business tags. S413. Based on the binary association matrix of requirement items and business tags, the term frequency-inverse document frequency method is used to calculate the weight of each full business tag, so as to obtain the weighted distribution of each requirement item on different full business tags, and the weight distribution is normalized. S414. The normalized weight distribution is used as the standardized feature vector for each cockpit requirement.

4. The method for constructing a multi-role hydropower operation and control cockpit according to claim 2, characterized in that, The process of constructing a demand topology diagram for hydropower operation and management based on standardized feature vectors of each cockpit requirement, and then decoupling the demand topology diagram by theme to obtain three hierarchical thematic demand sub-graphs including a group strategic supervision theme sub-graph, a regional collaborative scheduling theme sub-graph, and a plant execution monitoring theme sub-graph, includes the following steps: S421. Using standardized feature vectors as demand nodes, and calculating the semantic association strength between different demand nodes based on cosine similarity, the semantic association strength is used as the association edge between demand nodes to construct the demand topology graph of the hydropower operation and management cockpit. S422. Based on the organizational hierarchy affiliation identifiers pre-bound to each demand node, the nodes of the demand topology graph are divided into three-level hierarchical boundaries: group, region, and plant. The edges of the demand topology graph are weighted and corrected by calculating the subject core degree of each demand node within its respective level and combining the label coupling frequency between demand nodes, resulting in a hierarchical weighted directed demand topology graph. S423. Based on the three-level hierarchical boundaries of the group, region and plant, the hierarchical weighted directed demand topology graph is divided into three initial subgraphs, and each initial subgraph is subjected to internal clustering to obtain the optimized initial subgraph. S424. Based on the preset business rule base for hydropower operation and management, extract the theme features of each optimized initial subgraph. S425. Perform a matching degree verification between the subgraph theme features and the three preset levels of group strategic supervision, regional collaborative scheduling, and plant execution monitoring. After the verification is passed, the initial subgraph is labeled with the theme to obtain three hierarchical theme requirement subgraphs containing the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph.

5. A method for constructing a multi-role hydropower operation and control cockpit according to claim 4, characterized in that, The hierarchical weighted directed demand topology graph, based on the three-level boundaries of group, region, and plant, is divided into three initial subgraphs. Each initial subgraph undergoes internal clustering to obtain the optimized initial subgraph, comprising the following steps: S4231. Using the three-level hierarchical boundaries of group, region, and plant as hard constraints, and combining the organizational hierarchical affiliation identifiers pre-bound to each demand node, extract the demand nodes belonging to the corresponding level and the weighted association edges between demand nodes from the hierarchical weighted directed demand topology graph, remove invalid association edges across levels, and generate three initial subgraphs containing the initial subgraphs of the group level, the region level, and the plant level. S4232. Based on the standardized feature vectors of the demand nodes in the initial subgraph, and combined with the weights of the weighted association edges between the demand nodes, construct a comprehensive similarity matrix of the demand nodes in the initial subgraph. S4233. Based on the comprehensive similarity matrix, clustering is performed on the demand nodes in each initial subgraph, and the demand nodes in the initial subgraph are simplified and optimized according to the clustering results to obtain the optimized initial subgraph.

6. A method for constructing a multi-role hydropower operation and control cockpit according to claim 4, characterized in that, The process of verifying the matching degree between the subgraph theme features and the preset three-level themes of group strategic supervision, regional collaborative scheduling, and plant execution monitoring, and then labeling the initial subgraph with themes after the verification is passed, to obtain three hierarchical theme requirement subgraphs including group strategic supervision theme subgraphs, regional collaborative scheduling theme subgraphs, and plant execution monitoring theme subgraphs, includes the following steps: S4251. The subgraph theme features extracted from each optimized initial subgraph are compared with the preset group strategic supervision theme feature template, regional collaborative scheduling theme feature template, and plant execution monitoring theme feature template to calculate the similarity between each initial subgraph and the corresponding level theme. S4252. Based on the preset matching degree verification threshold, the comprehensive matching degree value of each initial subgraph and the corresponding level topic is verified for compliance. If the comprehensive matching degree value is greater than or equal to the preset verification threshold, the verification is deemed to have passed; otherwise, the subgraph topic feature extraction and clustering optimization operations are iteratively executed until the verification is passed or the maximum number of optimization iterations is reached. S4253. For each initial subgraph that passes the verification, bind the corresponding hierarchical theme and label the theme. Also, supplement the hierarchical subordinate mapping relationship between the initial subgraphs to complete the construction of the hierarchical relationship between the initial subgraphs and obtain the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph.

7. A method for constructing a multi-role hydropower operation and control cockpit according to claim 2, characterized in that, The process, based on knowledge graph technology, involves semantic association modeling of the hierarchical topic requirement subgraph, calculating cross-level requirement association degree through tag coupling strength analysis, constructing a requirement knowledge graph containing triples of indicator entities, business dimensions, and data permissions based on the cross-level requirement association degree, generating a set of permission binding relationships between indicator entities, business dimensions, and data permission entities based on the requirement knowledge graph, and constructing a set of permission propagation paths and an executable permission verification chain through permission propagation analysis. This includes the following steps: S431. Extract entity sets from the group strategic supervision theme sub-graph, the regional collaborative scheduling theme sub-graph, and the plant execution monitoring theme sub-graph, respectively; S432. Based on the extracted entity set, calculate the label coupling strength between cross-level entities, and combine the topic core degree and hierarchical association weight of the entity in its respective topic subgraph to perform weighted correction on the label coupling strength to obtain the cross-level demand association matrix. S433. Based on the cross-level requirement correlation matrix, construct a requirement knowledge graph containing triples of indicator entities, business dimensions, and data permissions. S434. Based on the aforementioned requirement knowledge graph, generate a set of permission binding relationships between indicator entities, business dimensions, and data permission entities, and construct a set of permission propagation paths and an executable permission verification chain through permission propagation analysis.

8. A method for constructing a multi-role hydropower operation and control cockpit according to claim 7, characterized in that, The process of calculating the label coupling strength between cross-level entities based on the extracted entity set, and then weighting and correcting the label coupling strength by combining the topic core degree and hierarchical association weight of the entities in their respective topic subgraphs to obtain the cross-level demand association matrix includes the following steps: S4321. Extract business tag sets from each entity set, and for entity pairs in different level topic subgraphs, calculate the ratio of the intersection size to the union size of their business tag sets to obtain the tag coupling strength. S4322. Based on the topological characteristics of each thematic subgraph, calculate the thematic core degree of each entity in its respective thematic subgraph, and determine the hierarchical association weight by combining the hierarchical architecture relationship of group-region-plant. S4323. Perform a Hadamard product operation on the cross-level demand correlation matrix and the theme core degree vector. Then, perform a weighted fusion operation on the result and the hierarchical correlation weight matrix to obtain the corrected cross-level correlation strength value. Normalize the corrected cross-level correlation strength value to generate a cross-level demand correlation matrix that includes the entity correlation strength between the three levels of group, region, and plant.

9. A method for constructing a multi-role hydropower operation and control cockpit according to claim 2, characterized in that, The process of generating functional module configurations and hierarchical drill-down analysis links for each level of the dashboard, based on a demand knowledge graph and hierarchical topic demand subgraphs, and combined with a set of permission binding relationships, a set of permission propagation paths, and an executable permission verification chain, includes the following steps: S441. Based on the entity triples in the demand knowledge graph, and combined with the theme features of the group strategic supervision theme subgraph, the regional collaborative scheduling theme subgraph, and the plant execution monitoring theme subgraph, extract the core indicator set and core business dimension set of each organizational level cockpit respectively. S442. Based on the core indicator set and core business dimension set of each organizational level, combined with the business rule library of hydropower operation and management, the functional modules of the requirement nodes of each level of the cockpit are divided, the indicator display component type, dimension analysis component type, early warning threshold configuration and user interaction operation method of each functional module are determined, and the corresponding data permission entity is associated with each functional module according to the permission binding relationship set, so as to generate the functional module configuration of each level of the cockpit. S443. Based on the entity association strength between the three levels of group, region and plant in the cross-level demand association matrix, and combined with the cross-level triplet relationship in the demand knowledge graph, as well as the permission propagation path set and the executable permission verification chain, construct a hierarchical drill-down analysis link with permission verification nodes.

10. A multi-role hydropower operation and control cockpit construction system, used to implement the multi-role hydropower operation and control cockpit construction method according to any one of claims 1-9, characterized in that, The system includes: The data configuration module is used to build and configure the hardware and software resources of a unified data base according to the data volume, real-time requirements and communication protocol types of the hydropower control center and each hydropower plant. Based on the hardware and software resources, it configures a unified access extension interface for multi-source heterogeneous data. The data acquisition module is used to collect production data from the hydropower control center and various hydropower plants, and to perform data quality verification and data classification and integration processing on the production data to form a multi-source database. The requirement elicitation module is used to obtain the dashboard requirement texts from the three organizational levels of the hydropower centralized control center: the group management level, the regional centralized control level, and the plant execution level. The association analysis module is used to perform topic decoupling on the cockpit requirement text of the organization level based on the topic decoupling method of the requirement topology graph, generate topic requirement subgraphs, and calculate the requirement association degree by combining knowledge graph technology and tag coupling strength analysis, so as to realize the construction of functional module configuration and drill-down analysis link of each cockpit; The cockpit building module is used to configure and analyze the functional modules of each cockpit, and to build the front-end display interface of the group-side cockpit, regional-side cockpit and plant cockpit respectively using visualization chart tools. Combined with multi-source databases and unified access extension interfaces, it constructs a hydropower operation and management cockpit.

Images