Power plant index system construction method and device

Abstract

The invention provides a power plant index system construction method and device. The method comprises the following steps: acquiring a business report template of a predefined power plant; wherein the business report template comprises a time domain attribute and a table structure; according to the time domain attributes and the table structure, generating periodic business reports, and recording index reference relationships among the business reports to obtain an index reference relationship library; based on the index reference relationship in the index reference relationship library, establishing an index reuse relationship of a cross-time-domain period; identifying repeated indexes with the same data source and computational logic in the index reference relationship library, combining the repeated indexes, establishing a unified index system model, and replacing the related index reference in each business report with the reference of the index in the unified index system model; a data service interface is provided based on a business report and a unified index system model, construction of a power plant index system is completed, maintenance time is shortened, dependence on a professional team is reduced, and report configuration efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of power production information management, and in particular to a power plant index system construction method and device. BACKGROUND

[0002] The construction of a power plant index system is an important means to improve operational efficiency, ensure safety, and achieve sustainable development. Traditional power plants have multiple sources and types of indexes, and require professional knowledge for index management and application.

[0003] However, traditional index system construction has many problems. On the one hand, the construction period is long and the workload is large, usually led by the information department, requiring a large amount of manpower for continuous maintenance to ensure the order and usability of the index system. On the other hand, the existing index definition methodology (such as KPI, OKR, and balanced scorecard) and tool chain (such as data warehouse, ETL / ELT tool, BI visualization tool, and OLAP engine) have many limitations in practical application. For example, the data extraction and conversion technology based on ETL requires operators to have high computer and database technology, and the index calculation logic is deeply bound to business needs. When business needs change, the entire ETL link needs to be restructured, resulting in low construction efficiency and difficulty in meeting the business needs of real-time production indexes in power plants, increasing the operational burden of enterprises. SUMMARY

[0004] The present application provides a power plant index system construction method and device to solve the technical problem of low efficiency of index system construction in the prior art.

[0005] In one aspect, the present application provides a power plant index system construction method, comprising:

[0006] obtaining a pre-defined business report template for a power plant; wherein the business report template includes time domain attributes and table structure;

[0007] generating periodic business reports according to the time domain attributes and the table structure, and recording the index reference relationship between each business report to obtain an index reference relationship library;

[0008] establishing an index reuse relationship across time domain periods based on the index reference relationship in the index reference relationship library;

[0009] identifying duplicate indexes with the same data source and calculation logic in the index reference relationship library, merging duplicate indexes and establishing a unified index system model, and replacing related index references in each business report with references to indexes in the unified index system model;

[0010] Based on the aforementioned business reports and unified indicator system model, a data service interface is provided to complete the construction of the power plant indicator system.

[0011] On the other hand, the present invention also provides a device for constructing a power plant indicator system, comprising:

[0012] The report acquisition module is used to acquire a predefined business report template for a power plant; wherein, the business report template includes time domain attributes and table structure;

[0013] The report generation module is used to generate periodic business reports based on the time domain attributes and the table structure, and record the indicator reference relationships between the business reports to obtain an indicator reference relationship library.

[0014] The indicator reuse module is used to establish cross-time-domain periodic indicator reuse relationships based on the indicator reference relationships in the indicator reference relationship library;

[0015] The indicator merging module is used to identify duplicate indicators with the same data source and calculation logic in the indicator reference relationship library, merge duplicate indicators and establish a unified indicator system model, and replace the relevant indicator references in each business report with references to indicators in the unified indicator system model.

[0016] The interface establishment module is used to provide data service interfaces based on the business reports and unified indicator system model, and to complete the construction of the power plant indicator system.

[0017] The method and apparatus for constructing a power plant indicator system provided by this invention can quickly locate affected indicators by automatically building a reference relationship library. For example, after a power plant's fuel calorific value data source is updated, the relevant reports are automatically identified and the calculation logic is updated synchronously, shortening maintenance time. It also enables visual tracking of indicator relationships, eliminating indicator calculation deviations caused by data source changes. The unified model reduces the number of duplicate indicators, minimizing storage redundancy while improving data consistency. Standardized interfaces allow business personnel to independently call indicator data, reducing reliance on specialized technical teams and improving report configuration efficiency. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the method for constructing a power plant indicator system provided in an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the structure of the power plant indicator system construction device provided in this embodiment of the invention;

[0021] Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] Figure 1 This is a flowchart illustrating the method for constructing a power plant indicator system provided in this embodiment of the invention.

[0024] See Figure 1 The construction method of the power plant indicator system includes the following steps 101 to 105.

[0025] Step 101: Obtain a predefined business report template for a power plant; the business report template includes time domain attributes and table structure.

[0026] In this step, the business report template includes time-domain attributes and table structure. Time-domain attributes are used to determine the report generation frequency, such as periodic features like daily, weekly, and monthly. The table structure defines the data source connection method and indicator calculation rules.

[0027] Step 102: Generate periodic business reports based on time domain attributes and table structure, and record the indicator reference relationships between each business report to obtain an indicator reference relationship library.

[0028] In this step, the indicator reference relationship library can form a complete indicator lineage map by recording the data source and calculation path of each indicator.

[0029] Step 103: Based on the indicator reference relationships in the indicator reference relationship library, establish indicator reuse relationships across time domain periods.

[0030] In this step, cross-time-domain periodic reuse relationships are established by analyzing the referencing patterns between reports of different periods, thereby creating a traceability mechanism for long-period reports to short-period data.

[0031] Step 104: Identify duplicate indicators in the indicator reference relationship library that have the same data source and calculation logic, merge duplicate indicators and establish a unified indicator system model, and replace the relevant indicator references in each business report with references to indicators in the unified indicator system model.

[0032] In this step, the unified indicator system model merges indicators with the same semantics but scattered definitions, such as unifying unit power generation efficiency and unit output ratio into standardized indicators.

[0033] Step 105: Provide data service interfaces based on business reports and a unified indicator system model to complete the construction of the power plant indicator system.

[0034] In this step, the data service interface encapsulates the underlying data access logic, supporting on-demand access to indicator data in the unified model.

[0035] Specifically, for example, the process begins by retrieving a predefined business report template, which specifies the report generation cycle and data structure. Daily and weekly reports are automatically generated based on time-domain attributes, while simultaneously recording the reference paths between indicators in each report. When a weekly report is found to reference data from multiple (e.g., three) daily reports for its power generation coal consumption indicator, a cross-cycle traceability relationship is automatically established. Semantic analysis identifies that the calculation logic for net power generation and effective unit output is completely consistent across different reports, merging them into a unified indicator. Finally, indicator data is provided externally through a standardized interface, allowing business personnel to directly access indicators from the unified model without needing to repeatedly configure calculation rules.

[0036] In this embodiment, by automatically building a reference relationship library, affected indicators can be quickly located. For example, after a power plant's fuel calorific value data source is updated, the relevant reports are automatically identified and the calculation logic is updated synchronously, shortening maintenance time. It also enables visual tracking of indicator relationships, eliminating calculation deviations caused by data source changes. The unified model reduces the number of duplicate indicators, minimizing storage redundancy while improving data consistency. Standardized interfaces allow business personnel to independently access indicator data, reducing reliance on specialized technical teams and improving report configuration efficiency.

[0037] In one embodiment of this specification, periodic business reports are generated based on time-domain attributes and table structure, and the indicator reference relationships between each business report are recorded to obtain an indicator reference relationship library, including:

[0038] Step 1: Determine the report generation cycle based on the time domain attribute, and generate the corresponding business reports according to the generation cycle;

[0039] Specifically, time-domain attributes refer to time-related business report attributes, such as periodic dimensions like daily, weekly, monthly, quarterly, or yearly. These can be achieved by parsing the time field or configuration parameters in the template, and are used to determine the generation frequency and coverage of business reports.

[0040] Step 2: Based on the pre-configured data source connection and indicator calculation rules in the table structure, obtain indicator data from external databases or other business reports and perform calculations;

[0041] Specifically, table structure refers to the data organization format defined in business reports. This can be implemented by configuring column names, row identifiers, data source mapping relationships, and calculation rules, and is used to standardize the storage and calculation logic of indicator data. Data source connection refers to the data access link between external databases or business reports. This can be implemented by configuring database addresses, authentication information, query statements, or cross-report reference paths, and is used to automatically obtain raw data or intermediate calculation results. Indicator calculation rules refer to the logical expressions that process the raw data, such as addition, subtraction, multiplication, division operations, aggregate functions, or conditional judgments. This can be implemented through predefined formula templates or dynamic script configuration, and is used to generate indicator values ​​that meet business requirements.

[0042] Step 3: When generating business reports, record the data source, calculation logic, and cross-report reference relationships of the indicators to form an indicator reference relationship library.

[0043] In this embodiment, specifically, when generating periodic business reports, the report generation process is first triggered based on the time period parameters defined in the time domain attributes, such as monthly or quarterly. Then, by parsing the data source connection information configured in the table structure, such as database table names or cross-report reference identifiers, raw data is automatically extracted from the specified location. For indicators requiring calculation, calculations are performed according to preset formulas or scripts, such as adding the power generation of multiple units to obtain the total power generation. During the report generation process, the data source path, calculation steps, and relationships referenced by other reports for each indicator are recorded synchronously, ultimately forming an indicator reference relationship library containing complete metadata.

[0044] This embodiment, through predefined templates and automated processes, can automatically generate reports based on time-domain attributes and table structures, and dynamically record the reference relationships between indicators. This avoids the workload of manually maintaining data links and improves the accuracy and consistency of indicator calculations. This embodiment realizes the automated generation of business reports and the systematic management of indicator relationships, reducing configuration errors caused by manual intervention. At the same time, by recording complete indicator reference relationships, it provides a reliable data foundation for subsequent cross-period indicator reuse and unified model construction.

[0045] In one embodiment of this specification, an indicator reuse relationship across time-domain periods is established based on the indicator reference relationship in the indicator reference relationship library, including:

[0046] Step 1: Identify the indicator reference patterns between business reports of different time periods based on the cross-report reference relationships recorded in the indicator reference relationship database;

[0047] Specifically, the indicator referencing pattern refers to the calling pattern of indicator data between reports of different time spans. This can be achieved by identifying the dependency paths between reports using data lineage analysis tools, which is used to reveal the data flow characteristics of cross-period indicators.

[0048] Step 2: Based on the indicator referencing pattern, establish the indicator tracing relationship from long-cycle reports to short-cycle reports, and the indicator aggregation relationship from short-cycle reports to long-cycle reports; where long-cycle reports are business reports with a time domain period greater than the preset duration, and short-cycle reports are business reports with a time domain period less than the preset duration.

[0049] Specifically, indicator traceability relationships refer to the links established by tracing the source of indicator data in reverse, such as using metadata management tools to record the indicator generation path, which is used to verify the original basis of indicator values ​​in long-term reports. Indicator aggregation relationships refer to the statistical associations formed by forward aggregation of short-term data, such as using the downsampling function of a time series database to achieve data accumulation calculation, which is used to support the generation of indicators in long-term reports.

[0050] Step 3: Based on the indicator traceability relationship and indicator aggregation relationship, obtain the indicator reuse relationship.

[0051] In this embodiment, specifically in the thermal power plant business scenario, monthly reports need to reference unit operating efficiency indicators from weekly reports for trend analysis, while annual reports need to integrate energy consumption data from various monthly reports. By parsing cross-report reference records in the indicator reference relationship database, the hierarchical reference characteristics between weekly, monthly, and annual reports can be discovered. Based on this characteristic, an indicator traceability relationship is established between weekly and monthly reports, allowing efficiency indicators in monthly reports to be traced back to the original data of specific weeks; an indicator aggregation relationship is established between monthly and annual reports, enabling the total energy consumption value in the annual report to automatically aggregate data from each month. This forms a cross-cycle indicator reuse network. For example, when data in a weekly report is corrected, the system can automatically trigger updates to the associated indicators in the monthly and annual reports.

[0052] This embodiment establishes a two-way data association mechanism by automatically identifying referencing patterns between reports. For example, it uses a graph database to store the indicator referencing topology, enabling real-time tracking of the impact range of cross-period data and effectively solving the pain point of manually adjusting multi-level reports when traditional ETL links change. This embodiment achieves automatic association and reuse of cross-period indicator data. For example, when a quarterly report needs to reference daily data, the system automatically matches preset aggregation rules to generate target indicators, avoiding manual repetitive configuration of calculation logic. It also supports two-way data verification; for example, the power generation indicator in the annual report can be traced back to the data details of each month, ensuring the credibility of data traceability. This mechanism significantly reduces the complexity of data maintenance between multi-period reports and improves the overall consistency of the indicator system.

[0053] In one embodiment of this specification, after summarizing the indicators from short-period reports to long-period reports, the method further includes:

[0054] Step 1: For any indicator in a long-term report, trace back to all its source short-term reports and record the original value of the indicator in each short-term report.

[0055] Specifically, the original value refers to the initial indicator value in the short-term report that has not been summarized. It can be obtained by querying the historical report database or the real-time data interface and is used to verify the accuracy of the long-term indicator calculation process.

[0056] Step 2: Recalculate these original values ​​according to the preset aggregation rules to obtain the theoretical aggregate value;

[0057] Specifically, the theoretical summary value refers to the result of recalculating the original value according to the preset summary rules. It can be achieved by weighted average, cumulative summation or extreme value statistics methods, and serves as a reference benchmark for data consistency.

[0058] Step 3: Compare the theoretical summary value with the actual value of the indicator used in the long-term report to obtain the difference between the two;

[0059] Step 4: If the difference between the two exceeds the set threshold, mark it as an anomaly in the reference path and record the anomaly type; the anomaly types include, but are not limited to: inconsistent calculation logic, unsynchronized data source changes, and incorrect unit conversion.

[0060] Specifically, setting a threshold refers to the maximum allowable deviation range between the theoretical and actual values. This can be set as an absolute value or a percentage threshold depending on the business scenario, and is used to trigger the anomaly detection mechanism. Anomaly type refers to the specific classification of the causes leading to the data deviation. This can be identified through a predefined error code table or a natural language processing model, and is used to guide subsequent remedial operations.

[0061] In this embodiment, specifically, after a long-term report is generated, each of its constituent indicators is automatically parsed, and the generation of all short-term reports upon which that indicator depends is traced back. For example, an annual power generation indicator may be formed by accumulating power generation data from 12 monthly reports. The original power generation values ​​corresponding to each monthly report are extracted from the repository, the annual total is recalculated according to the accumulation rules, and compared with the actual annual power generation displayed in the report. If the difference exceeds a preset 5% threshold, an anomaly report is generated, indicating possible calculation logic errors or data source version inconsistencies. The anomaly detection process is executed periodically by an automated script, and the detection results are stored in the audit log for technical personnel to analyze and process.

[0062] This embodiment establishes an automated traceability and comparison mechanism to achieve continuous monitoring of all indicators. It can promptly detect hidden data anomalies caused by outdated calculation rules, delayed data source updates, or unit conversion errors, effectively preventing the spread of erroneous indicators within the decision-making system. Through this technical solution, data inconsistencies during cross-period indicator referencing can be automatically identified, significantly reducing manual verification workload and improving the overall reliability of the indicator system. Precise classification of anomaly types provides technical personnel with clear troubleshooting directions, shortens fault location time, and ensures the long-term stability and accuracy of the indicator system.

[0063] In one embodiment of this specification, identifying duplicate indicators with the same data source and calculation logic in the indicator reference relationship database, merging duplicate indicators, and establishing a unified indicator system model includes:

[0064] Step 1: Traverse the indicator reference relationship database to extract the data source and calculation logic of each indicator;

[0065] Specifically, data source refers to the path or system interface through which indicator data is acquired. This can be achieved through database connection configuration or API call logs, addressing redundancy issues caused by inconsistent indicator sources across different reports. Calculation logic refers to the computational rules applied during indicator generation, which can be implemented using a formula parser or script engine, eliminating wasted computational resources caused by the repeated definition of identical business rules.

[0066] Step 2: Perform cluster analysis on indicators with the same data source and calculation logic to obtain duplicate indicators;

[0067] Specifically, cluster analysis refers to the automatic identification of indicators with the same attributes and logic through algorithms. This can be achieved by hash value comparison or similarity matrix calculation, and is used to quickly locate duplicate indicators scattered in different reports.

[0068] Step 3: Merge duplicate indicators into unified indicators and define their unique identifier in the unified indicator system model;

[0069] Specifically, a unique identifier refers to the standardized coding of a unified indicator in the model. This can be achieved using a globally unique string or a sequence of numbers, and is used to establish a cross-report indicator reference mapping relationship.

[0070] Step 4: Point duplicate references of indicators in the indicator reference relation library to a unified indicator.

[0071] In this embodiment, specifically, the indicator reference relationship database stores the indicator sources and calculation rules for each business report. By traversing this database, the core attributes of all indicators can be extracted. When multiple indicators are found to have completely identical data acquisition paths and the same calculation formula, the system automatically classifies them as duplicate indicators. For example, if two reports define the unit's average daily power generation indicator, and both read raw data from the same database table and use the same daily average algorithm, they are determined to be duplicates. These duplicate indicators are merged into a unified indicator, assigned a new global code, and stored in a unified model. The reference paths to the old indicators in the original reports are batch-replaced to point to the new code, thereby eliminating redundant storage and calculation.

[0072] This embodiment utilizes automated clustering algorithms and structured attribute extraction to quickly identify duplicate indicators scattered across different periodic reports, and achieves centralized management through a unified model. The maintenance difficulties caused by the dispersed definitions of indicators in existing technologies are effectively resolved in this solution through automatic redirection of reference paths. This technical solution standardizes indicator definitions across business reports, reduces resource waste caused by redundant calculations, and lowers the risk of data conflicts due to inconsistent indicator versions. Business personnel can directly call standard indicators from the unified model when creating new reports, avoiding the workload of redundant definitions and logical verification, and significantly improving the efficiency of indicator system maintenance.

[0073] In one embodiment of this specification, the relevant indicator references in each business report are replaced with references to indicators in the model, including:

[0074] Step 1: Based on the unique identifier in the unified indicator system model, locate the duplicate indicators referenced in each business report;

[0075] Specifically, the unique identifier in the unified indicator system model refers to assigning a globally unique code or string to each merged unified indicator. This can be achieved by using a hash algorithm to generate feature values ​​for the indicator's data source and calculation logic, ensuring that references to the same indicator in different business systems point to the same entity. Locating duplicate indicators referenced in various business reports involves parsing the metadata structure of the business reports to identify all code snippets or data fields referencing duplicate indicators. This can be achieved by using a syntax parser to traverse the indicator reference paths in the report template, and then matching and verifying this with the unique identifier from the unified indicator system model.

[0076] Step 2: Change the references to duplicate indicators in the business reports to references to the unified indicators in the model.

[0077] In this embodiment, specifically after merging duplicate metrics and establishing a unified metric system model, the metadata structure of the business report is parsed, and the attribute information of all metric referencing nodes is traversed. Based on the standard unique identifier defined in the unified metric system model, the metric names, data source addresses, and calculation logic referenced in the business report are matched and compared. When multiple referencing nodes are detected pointing to merged duplicate metrics, the reference path is automatically redirected to the unique identifier of the unified metric, and the metadata record of the business report is updated simultaneously. During this process, the syntax parser extracts the metric call statements in the report template, identifies the code blocks containing duplicate metric references, and completes the replacement operation through a mapping table.

[0078] This embodiment, through the combination of unique identifiers and automated parsing technology, can accurately identify duplicate reference nodes and complete batch replacements, significantly reducing the need for manual intervention. This technical solution solves the data redundancy and logical confusion caused by duplicate indicator references in traditional indicator systems, achieving unified management of indicator references across business reports. The automated replacement mechanism avoids errors that may be introduced by manual modifications, ensuring that the calculation logic and data source references for the same indicator are completely consistent across all reports, thereby improving the overall reliability and maintenance efficiency of the indicator system.

[0079] In one embodiment of this specification, before identifying duplicate indicators with the same data source and calculation logic in the indicator reference relation library, the method further includes:

[0080] Step 1: Standardize the indicator names, units, and description text used in each business report, removing redundant characters and format differences;

[0081] Specifically, standardization refers to uniformly replacing or deleting special symbols, spaces, and capitalization in indicator names, such as converting "unit efficiency (%)" to "unit efficiency percentage"; uniformly converting units, such as unifying "kW·h" and "kilowatt-hour" to the same expression; and replacing synonyms in descriptive text, such as unifying "coal consumption" and "coal fuel consumption" to the same terminology. This process can eliminate inconsistencies in indicator descriptions caused by differences in human input habits.

[0082] Step 2: Establish an indicator semantic tag library, where each tag represents a general semantic meaning (such as "unit efficiency", "coal consumption rate", "load rate");

[0083] Specifically, a semantic tag library refers to a pre-established collection of concepts common to the business domain. For example, "unit efficiency" can be defined as a tag that includes the calculation relationship between "power generation" and "fuel consumption". Each tag is generated by extracting high-frequency keywords from business documents using natural language processing technology, such as extracting "coal consumption rate" as an independent tag from operating procedures. Tag matching enables semantic alignment of indicators across business modules.

[0084] Step 3: Match the standardized indicator names and descriptions with the semantic tag library item by item, and assign one or more semantic tags to each indicator;

[0085] Step 4: If two indicators have different names but the same semantic label combination and consistent calculation logic, they are identified as potential duplicate indicators.

[0086] In this embodiment, specifically after generating the business report, all indicators within the report are first cleaned and their formats converted, such as removing underscores and parentheses and converting units to international standard symbols. Then, the standardized indicator description text is compared with a semantic tag library for similarity calculation, for example, using a cosine similarity algorithm to match text vectors, assigning each indicator the three most relevant tags. When two indicators are assigned the exact same tag combination, the system automatically compares their data source fields and calculation logic expressions. If they are completely identical, a duplicate indicator merging process is triggered. For example, if "coal consumption for power supply" and "standard coal consumption for power generation" are both classified as "coal consumption rate" after tag matching, and both are calculated as "total coal consumption / power generation," then they are determined to be duplicate indicators.

[0087] This embodiment utilizes automated text processing and semantic tag mapping to identify metrics with different names but identical underlying functions during the metric definition phase. For example, it automatically associates "equipment availability" and "unit availability" scattered across maintenance and operation reports, avoiding resource waste caused by naming differences. This technical solution effectively addresses the problem of redundant construction caused by non-standard metric naming. For instance, it reduces over twenty different expressions of the same coal consumption metric in different reports to a unified name, reducing metric storage space usage. Semantic tag matching identifies hidden duplicates across business lines; for example, it identifies that "unplanned outages" in production reports and "unexpected outages" in safety reports essentially point to the same data source, thereby merging four hundred previously scattered metrics into three hundred core metrics, reducing system maintenance complexity.

[0088] In one embodiment of this specification, after establishing cross-time-domain periodic index reuse relationships based on index reference relationships in the index reference relationship library, the method further includes:

[0089] Step 1: Analyze the intermediate reference links between any two long-term reports to obtain the intermediate reference nodes;

[0090] Specifically, an intermediate reference chain refers to an indicator reference path formed between two long-term reports through one or more short-term reports as intermediate nodes. This can be achieved by traversing the cross-report reference records in the indicator reference relationship database and extracting the node sequence in the chain. A transit reference node refers to a short-term report that acts as an intermediate link in the chain; key nodes can be identified using path analysis methods in graph theory.

[0091] Step 2: If multiple short-period reports serve as intermediate reference nodes and ultimately point to the same original indicator, replace all indirect references with direct references to that original indicator and update the reference records in the indicator reference relationship database.

[0092] Specifically, the original metric refers to the underlying metric that initially generated the data, and its unique source can be determined by tracing back to the end node of the reference chain. Direct reference means skipping intermediate steps and obtaining data directly from the original metric, which can be achieved by modifying the pointer relationship of the reference path and updating the records in the metric reference relationship database.

[0093] In this embodiment, specifically, after establishing cross-time-domain periodic indicator reuse relationships, the system automatically traverses all reference links between long-period reports to identify scenarios where multiple short-period reports act as intermediary nodes and ultimately point to the same original indicator. For example, when two annual reports indirectly reference the coal consumption rate indicator in the same monthly report through multiple quarterly reports, the system replaces the intermediary references in the quarterly reports with references directly pointing to the coal consumption rate indicator in the monthly report. During this process, redundant levels of reference paths are eliminated, and the records in the indicator reference relationship database are synchronously updated to new direct reference relationships, ensuring the accuracy and efficiency of subsequent data retrieval.

[0094] This embodiment automatically optimizes the reference chain, reducing the dependency levels of intermediate nodes, making the data retrieval path simpler and reducing maintenance complexity. Through the above technical solution, redundant intermediate links in cross-period indicator references can be effectively eliminated, improving data retrieval efficiency, avoiding cascading errors caused by changes in intermediate node data, and simplifying the structure of the indicator reference relationship database, thus enhancing the system's adaptability to complex reference scenarios.

[0095] In one embodiment of this specification, after providing a data service interface based on business reports and a unified indicator system model to complete the construction of the power plant indicator system, the method further includes:

[0096] Step 1: When a user creates a new business report or edits an existing report, automatically analyze the current report's theme, business module, and usage scenario;

[0097] Specifically, automatically analyzing the theme of the current report refers to parsing keywords in the report name and description text using natural language processing technology. This can be achieved using text classification models or rule-based matching algorithms to identify the core analytical objectives of the report. The business module refers to matching based on a predefined business classification system (e.g., production operation module, equipment management module), which can be achieved through metadata tag mapping to determine the scope of indicator selection. The usage scenario refers to identifying the application purpose of the report (e.g., daily monitoring, monthly analysis), which can be achieved through scenario classification models or user input selection to adjust the granularity of recommended indicators.

[0098] Step 2: Combining the existing indicators and their reference relationships in the unified indicator system model, select the set of indicators relevant to the current report;

[0099] Step 3: Based on the other metrics already configured in the current report, eliminate conflicting or redundant recommended items and provide the user with a list of recommended metrics.

[0100] In this embodiment, specifically, when a user creates or modifies a report, the system parses the report's metadata to obtain its business attributes. Combining this with the indicator relationships stored in the unified indicator system model, the system filters out a set of candidate indicators that match the current business module and scenario. For example, for a daily report scenario in the equipment management module, the system prioritizes recommending real-time indicators such as equipment failure rate and maintenance cycle. Simultaneously, by comparing the data sources and calculation logic of the selected indicators, the system automatically excludes indicators with logical conflicts (such as coal consumption rate indicators with inconsistent units), ultimately generating a filtered recommendation list.

[0101] This embodiment achieves accurate automated recommendations by analyzing report attributes in a structured manner and combining them with a pre-built indicator relationship network. This technical solution lowers the professional barrier for users when building business reports and avoids logical errors caused by inappropriate indicator selection. By dynamically eliminating conflicting items, it reduces the time spent on repeated debugging during report configuration and improves the application efficiency of the indicator system.

[0102] The invention will be explained and illustrated below through some specific examples.

[0103] In one embodiment, automating the business report creation process is a key step. Specifically, business personnel collect the indicators they need to use and manage by defining a specific time-domain (periodic) and tabular business report. After the defined business report is delivered to the scheduling module, the program automatically schedules and obtains the business report results for the specified time domain according to the defined time-domain periodic report template. For example, for shift supervisors in the production and operation department of a power generation company, their daily work requires regularly reading and summarizing meters on-site and recording the data in a commonly used Excel file. Through this invention, shift supervisors can convert existing report templates into automatic reports, defining the indicators to be automatically acquired, the indicators to be manually entered daily, and the calculation logic within the table. At the shift change each day, the shift supervisor only needs to open the pre-designed report, enter the data into the designated cells, and save it to complete the work, greatly reducing the required time.

[0104] Based on the same general inventive concept, this invention also protects a device for constructing a power plant indicator system, such as... Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of the power plant indicator system construction device provided in an embodiment of the present invention. The power plant indicator system construction device provided by the present invention is described below, and the power plant indicator system construction device described below can be referred to in correspondence with the power plant indicator system construction method described above.

[0105] The power plant indicator system construction device includes a report acquisition module 201, a report generation module 202, an indicator reuse module 203, an indicator merging module 204, and an interface establishment module 205.

[0106] The report acquisition module 201 is used to acquire a predefined business report template for a power plant; the business report template includes time domain attributes and table structure.

[0107] The report generation module 202 is used to generate periodic business reports based on time domain attributes and table structure, and record the indicator reference relationships between each business report to obtain an indicator reference relationship library.

[0108] The indicator reuse module 203 is used to establish cross-time-domain periodic indicator reuse relationships based on the indicator reference relationships in the indicator reference relationship library;

[0109] The indicator merging module 204 is used to identify duplicate indicators in the indicator reference relationship library that have the same data source and calculation logic, merge duplicate indicators and establish a unified indicator system model, and replace the relevant indicator references in various business reports with references to indicators in the unified indicator system model.

[0110] The interface establishment module 205 is used to provide data service interfaces based on business reports and a unified indicator system model, and to complete the construction of the power plant indicator system.

[0111] Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention.

[0112] like Figure 3 As shown, the electronic device may include a processor 310, a communication interface 320, a memory 330, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions from the memory 330 to execute the power plant indicator system construction method.

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

[0114] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the power plant indicator system construction method provided by the above methods.

[0115] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the power plant indicator system construction method provided by the above methods.

[0116] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0117] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for constructing a power plant indicator system, characterized in that, include: Obtain a predefined business report template for a power plant; wherein the business report template includes time-domain attributes and table structure; Based on the time domain attributes and the table structure, periodic business reports are generated, and the indicator reference relationships between each business report are recorded to obtain an indicator reference relationship library. Based on the indicator reference relationships in the indicator reference relationship database, establish indicator reuse relationships across time domain periods; Identify duplicate indicators with the same data source and calculation logic in the indicator reference relationship library, merge duplicate indicators and establish a unified indicator system model, and replace the relevant indicator references in each business report with references to the indicators in the unified indicator system model; Based on the aforementioned business reports and unified indicator system model, a data service interface is provided to complete the construction of the power plant indicator system.

2. The method for constructing a power plant indicator system according to claim 1, characterized in that, Based on the time-domain attributes and the table structure, periodic business reports are generated, and the indicator reference relationships between each business report are recorded to obtain an indicator reference relationship library, including: Based on the time domain attribute, the report generation cycle is determined, and the corresponding business report is generated according to the generation cycle. Based on the pre-configured data source connection and indicator calculation rules in the table structure, indicator data is obtained from external databases or other business reports and calculations are performed. When generating business reports, the data source, calculation logic, and cross-report reference relationships of the indicators are recorded to form an indicator reference relationship library.

3. The method for constructing a power plant indicator system according to claim 2, characterized in that, Based on the indicator reference relationships in the aforementioned indicator reference relationship library, establish cross-time-domain period indicator reuse relationships, including: Based on the cross-report reference relationships recorded in the indicator reference relationship database, identify the indicator reference patterns between business reports of different time periods; Based on the aforementioned indicator referencing pattern, establish an indicator tracing relationship from long-cycle reports to short-cycle reports, as well as an indicator aggregation relationship from short-cycle reports to long-cycle reports. Based on the indicator tracing relationship and the indicator aggregation relationship, the indicator reuse relationship is obtained; The long-cycle report is a business report with a time domain period greater than the preset duration, and the short-cycle report is a business report with a time domain period less than the preset duration.

4. The method for constructing a power plant indicator system according to claim 3, characterized in that, Following the summary relationship of indicators from short-term reports to long-term reports, it also includes: For any indicator in a long-term report, trace back to all its source short-term reports and record the original value of the indicator in each short-term report. These original values ​​are recalculated according to the preset aggregation rules to obtain the theoretical aggregation value; The theoretical summary value is compared with the actual value of the indicator used in the long-term report to obtain the difference between the two. If the difference between the two exceeds the set threshold, it is marked as an abnormal point in the reference path, and the abnormality type is recorded.

5. The method for constructing a power plant indicator system according to claim 1, characterized in that, Identify duplicate indicators in the indicator reference relationship library that have the same data source and calculation logic, merge duplicate indicators, and establish a unified indicator system model, including: Traverse the index reference relationship database to extract the data source and calculation logic of each index; Cluster analysis is performed on indicators with the same data source and calculation logic to obtain duplicate indicators; Duplicate indicators are merged into unified indicators, and their unique identifiers are defined in the unified indicator system model. The references of duplicate indicators in the indicator reference relation library are directed to the unified indicator.

6. The method for constructing a power plant indicator system according to claim 1, characterized in that, Replace the relevant indicator references in each business report with references to the indicators in the model, including: Based on the unique identifier in the unified indicator system model, locate the duplicate indicators referenced in each business report; Modify the references to duplicate indicators in the business reports to references to the unified indicators in the model.

7. The method for constructing a power plant indicator system according to claim 1, characterized in that, Before identifying duplicate indicators with the same data source and calculation logic in the indicator reference relationship library, the process also includes: Standardize the indicator names, units, and description text used in various business reports, removing redundant characters and format differences; Establish an indicator semantic tag library, where each tag represents a general semantic meaning; The standardized indicator names and descriptions are matched item by item with the semantic tag library, and one or more semantic tags are assigned to each indicator. If two metrics have different names but the same semantic label combination and consistent calculation logic, they are identified as potential duplicate metrics.

8. The method for constructing a power plant indicator system according to claim 1, characterized in that, After establishing cross-time-domain periodic indicator reuse relationships based on the indicator reference relationships in the aforementioned indicator reference relationship library, the following is also included: Analyze the intermediate reference links between any two long-term reports to identify the intermediate reference nodes; If multiple short-period reports serve as intermediate reference nodes and ultimately point to the same original indicator, then all indirect references are replaced with direct references to that original indicator, and the reference records in the indicator reference relationship database are updated.

9. The method for constructing a power plant indicator system according to claim 1, characterized in that, After completing the construction of the power plant indicator system, the system provides a data service interface based on the aforementioned business reports and unified indicator system model, and includes: When a user is detected to be creating a new business report or editing an existing report, the system automatically analyzes the current report's theme, business module, and usage scenario. By combining the existing indicators and their reference relationships in the unified indicator system model, a set of indicators relevant to the current report is selected; Based on other metrics already configured in the current report, exclude conflicting or redundant recommendations and provide the user with a list of recommended metrics.

10. A device for constructing a power plant indicator system, characterized in that, include: The report acquisition module is used to acquire a predefined business report template for a power plant; wherein, the business report template includes time domain attributes and table structure; The report generation module is used to generate periodic business reports based on the time domain attributes and the table structure, and record the indicator reference relationships between the business reports to obtain an indicator reference relationship library. The indicator reuse module is used to establish cross-time-domain periodic indicator reuse relationships based on the indicator reference relationships in the indicator reference relationship library; The indicator merging module is used to identify duplicate indicators with the same data source and calculation logic in the indicator reference relationship library, merge duplicate indicators and establish a unified indicator system model, and replace the relevant indicator references in each business report with references to indicators in the unified indicator system model. The interface establishment module is used to provide data service interfaces based on the business reports and unified indicator system model, and to complete the construction of the power plant indicator system.

Images