An intelligent cloud perspective power station operation and maintenance method

Abstract

The application provides a kind of wisdom cloud perspective power station operation and maintenance method, belongs to wisdom power station operation and maintenance technical field, including: based on the edge computing node of power station field deployment collection multi-source data, and the data collected are preprocessed;In cloud based on MySQL Construction power station-equipment-sensor three level associated data model of preprocessed data, and in combination with layered storage strategy, the preprocessed data received in cloud is cached and stored;From cache storage, extract real-time heat map and historical curve, and render the superimposed display results to visualize on multi-screen terminal, at the same time, based on the back-end deployment Drools rule engine, combined with historical data and weather API dynamically adjust alarm threshold, and in multi-screen terminal differential display and sound effect playing;Synchronous generation work order to carry out operation and maintenance of power station site. Significantly improve the efficiency of power station operation and maintenance, reduce operation and maintenance cost, and ensure long-term stable operation of power station.

Description

Technical Field

[0001] This invention relates to the field of smart power plant operation and maintenance technology, and in particular to a smart cloud-based operation and maintenance method for power plants. Background Technology

[0002] The existing power plant operation and maintenance system's technical architecture is mainly divided into four layers: the front end uses Vue / React+WebSocket+ECharts / D3 to build a visual interface; the communication layer uses MQTT / WebSocket+protocol gateway to realize OPCUA / Modbus protocol conversion; the security layer relies on two-way SSL authentication+JWT dynamic tokens; and the device layer completes data collection through edge nodes such as EdgeXFoundry.

[0003] However, existing technologies have the following key drawbacks:

[0004] Data integration fragmentation: Remote signaling (switch status) and telemetry (power generation) data are processed in a scattered manner, lacking a unified model for power plant metadata and historical records, which requires operation and maintenance personnel to switch between multiple systems for querying, resulting in low decision-making efficiency;

[0005] The disconnect between real-time and historical analysis: The large screen only displays real-time data and cannot dynamically overlay historical curves (such as the power generation trend compared to the same period last week), making it difficult to quickly locate hidden problems such as abnormal equipment temperature that has not triggered alarms;

[0006] Interaction and performance bottlenecks: The high proportion of static charts, the lack of multi-level drill-down interaction from power plant to equipment to sensor, and the lack of optimized storage and caching strategies under massive data, resulting in a response delay of more than 3 seconds for historical queries of 100,000+ devices;

[0007] The alarm mechanism is simplistic: it relies solely on fixed thresholds to trigger alarms, without dynamically adjusting thresholds based on weather conditions or equipment aging, and lacks a linkage mechanism between alarms and work order systems (such as Jira), resulting in a long fault handling closed-loop cycle.

[0008] The aforementioned deficiencies prevent existing systems from meeting the operational and maintenance needs of power plants for efficient monitoring, accurate analysis, and rapid response. Therefore, this invention proposes an intelligent cloud-based power plant operation and maintenance method. Summary of the Invention

[0009] This invention provides a smart cloud-based operation and maintenance method for power plants to solve the aforementioned technical problems.

[0010] This invention provides a smart cloud-based power station operation and maintenance method, comprising:

[0011] Step 1: Collect multi-source data based on edge computing nodes deployed at the power plant site, and preprocess the collected data before uploading it to the cloud;

[0012] Step 2: Construct a three-level correlation data model of the preprocessed data (power station-equipment-sensor) based on MySQL in the cloud, and cache and store the preprocessed data received in the cloud in combination with a hierarchical storage strategy;

[0013] Step 3: Extract real-time heatmaps and historical curves from cache storage, and render the overlay display results for visualization on multi-screen terminals. At the same time, based on the Drools rule engine deployed on the backend, combine historical data and weather API to dynamically adjust alarm thresholds, and display and play sound effects in a differentiated manner on the multi-screen terminals.

[0014] Step 4: Based on the visualization results, differentiated display results, and playback sound effects, generate work orders simultaneously to carry out on-site operation and maintenance of the power station.

[0015] Preferably, step 1 includes:

[0016] EdgeXFoundry edge computing nodes are deployed at the power plant site, and Modbus / OPCUA / DNP3 protocols are adapted through policy mode to collect multi-source data from the power plant site.

[0017] Based on the edge computing node, the multi-source data is cleaned, compressed, and standardized in format, and device ID, timestamp, and data type tag are added.

[0018] Preprocessed data is uploaded to the cloud via the MQTT protocol, and ECDSA asymmetric encryption is used to protect the data transmission link.

[0019] Preferably, the compression processing of the multi-source data based on the edge computing node includes:

[0020] Based on the cleaning results, the original redundancy coefficient of each data in the multi-source data is determined, and the corresponding storage table is matched from the type-storage lookup table according to the data type of each data. A redundancy fitting function is established based on the historical redundancy coefficient of each stored data in the storage table.

[0021] Determine the correlation between the redundancy fitting function and the original redundancy coefficients. At the same time, establish a sequence of coefficient differences between each historical redundancy coefficient and the original redundancy coefficient, and construct a redundancy difference fitting function.

[0022] Obtain the historical storage queue of the storage unit corresponding to each stored data in the storage table, wherein the historical storage queue includes the historical remaining capacity after each historical update;

[0023] Sort the data groups after each historical update according to the historical remaining capacity;

[0024] Determine the correlation coefficient between the corresponding data in the multi-source data and the data group after each historical update, and perform a secondary sorting on the corresponding remaining historical capacity;

[0025] The remaining capacity threshold is determined based on the results of the first and second sorting processes.

[0026] Based on the maximum capacity of the data group after each historical update, and combined with the number of bytes in the header of the storage table, the theoretical capacity of the corresponding data is estimated.

[0027] Based on the correlation coefficients and the redundancy difference fitting function, and combined with the theoretical occupancy and remaining capacity threshold, the compression reference ratio of the corresponding data is obtained for compression processing.

[0028] Preferably, the three-level association data model includes: power plant metadata, equipment attributes, and sensor data collection information;

[0029] The tiered storage strategy includes:

[0030] Real-time data is stored in Redis within 5 minutes, using the device ID and the collected item as the key;

[0031] Historical data ranging from 5 minutes to 3 years is stored in InfluxDB 2.0, with dual sharding by power plant region and time and an inverted index.

[0032] Static data is stored in MySQL, and batch queries are optimized using MyBatisPlus.

[0033] Preferably, the overlay display result is rendered for visualization on multi-screen terminals, including:

[0034] The hierarchical attribute set stored in the cache is compared and analyzed with the user's demand set, and the global structure scheme is determined in combination with the screen size of the multi-screen terminal. The overlay display result is then structurally laid out.

[0035] The division stamp for the real-time heat map is determined according to the thermal range division standard, and the superimposed display result is cut according to the division stamp to obtain several cut superimposed display blocks.

[0036] Extract the display features of each cut and overlay display block. At the same time, establish a first mapping relationship between each cut and overlay display block and the cached hierarchical attribute set, as well as a second mapping relationship with the user's demand set.

[0037] Based on the first mapping relationship and the second mapping relationship, an extended cluster is determined, and the display features are rendered and derived based on the extended cluster to obtain a sub-rendering scheme. At the same time, the key indicators of each cut and overlay display block are determined, and the block priority is determined.

[0038] A four-dimensional input group vector is constructed based on the theoretical resolution, block priority, block length, and sub-layout extracted from the structural layout of each cut and overlay display block's sub-rendering scheme.

[0039] The four-dimensional input vector group is input into the vector analysis model to obtain an overall rendering scheme containing each cut and overlay display block for rendering processing, and then visualized on a multi-screen terminal. The rendering parameters of each display screen in the multi-screen terminal are controlled separately.

[0040] Preferably, dynamically adjusting the alarm threshold includes:

[0041] Three types of core data are collected based on the backend data interface, including: historical equipment operation data, real-time weather dataset, and equipment metadata.

[0042] The three types of core data are standardized and normalized, and the weights of weather impact (W1), historical faults (W2), and equipment aging (W3) are determined.

[0043] Based on the weather impact weight W1, historical fault weight W2, and equipment aging weight W3, the initial dynamic threshold Tin is dynamically adjusted. The Drools rule engine is set to update W1, W2, and W3 every 24 hours.

[0044] Preferably, the rendering of the display features is derived based on the extended cluster to obtain a sub-rendering scheme, including:

[0045] The first truth value parameter is determined based on the first mapping relationship. And determine the second truth value parameter based on the second mapping relationship. ;

[0046] Determine the virtual and real degree parameters based on the first mapping relationship. And determine the virtual / real degree parameter based on the second mapping relationship. And record the virtual and real deviation values. ;

[0047] Calculate the mapping synergy ,in, These are the weighting coefficients, and ;

[0048] when At that time, extract the core feature vector V0 and filter those that meet the requirements. And candidate features that satisfy the relaxed threshold constraint, form an extended cluster S, where, The similarity threshold; The threshold is denoted as u; u represents the candidate feature.

[0049] Determine the feature contribution bj of element fj in extended cluster S, and combine it with the cosine similarity with the core feature vector V to obtain the rendering sensitivity coefficient mj, which is used to characterize the priority weight of element fj in rendering.

[0050] Define a rendering dimension set D, which includes color depth, data sampling rate, dynamic refresh threshold, and spatial layout proportion.

[0051] For each element fj, the correlation degree Rjd with each dimension is calculated by combining the realism Tj, virtuality Xj of the mapping, and the basic weight of the rendering dimension.

[0052] Filter the dimensions whose relevance Rjd meets the threshold, and form the target rendering dimension subset Dj of element fj;

[0053] For each dimension in Dj, calculate the dynamic parameter value Pjd based on the baseline parameter, the rendering sensitivity coefficient mj, and the extended cluster synergy deviation.

[0054] By introducing hardware limits and minimum requirements for operation and maintenance scenarios for multi-screen terminals, the dynamic parameter value Pjd is pruned to output a sub-rendering scheme.

[0055] Preferably, the strategy pattern of edge computing nodes is implemented through protocol configuration files and interface adapter classes. When a new protocol is added, only the corresponding adapter class is added.

[0056] Compared with the prior art, the beneficial effects of this application are as follows:

[0057] By collecting and preprocessing data at edge nodes, constructing a three-level correlation model and hierarchical storage in the cloud, implementing multi-screen visualization rendering and dynamic alarms, and synchronizing work orders for operation and maintenance, the entire process of power plant data collection, processing, storage, display, and operation and maintenance is made intelligent. This allows operation and maintenance personnel to intuitively grasp the real-time status and historical trends of the power plant, quickly locate equipment anomalies, and reduce false alarm rates by more than 70% with dynamic alarm thresholds. Synchronized work orders shorten the fault handling cycle from 4 hours to within 1 hour, significantly improving power plant operation and maintenance efficiency, reducing operation and maintenance costs, and ensuring the long-term stable operation of the power plant.

[0058] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0059] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0060] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0061] Figure 1 This is a flowchart of an operation and maintenance method for a smart cloud-based power station according to an embodiment of the present invention. Detailed Implementation

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

[0063] This invention provides a smart cloud-based operation and maintenance method for power plants, such as... Figure 1 As shown, it includes:

[0064] Step 1: Collect multi-source data based on edge computing nodes deployed at the power plant site, and preprocess the collected data before uploading it to the cloud;

[0065] Step 2: Construct a three-level correlation data model of the preprocessed data (power station-equipment-sensor) based on MySQL in the cloud, and cache and store the preprocessed data received in the cloud in combination with a hierarchical storage strategy;

[0066] Step 3: Extract real-time heatmaps and historical curves from cache storage, and render the overlay display results for visualization on multi-screen terminals. At the same time, based on the Drools rule engine deployed on the backend, combine historical data and weather API to dynamically adjust alarm thresholds, and display and play sound effects in a differentiated manner on the multi-screen terminals.

[0067] Step 4: Based on the visualization results, differentiated display results, and playback sound effects, generate work orders simultaneously to carry out on-site operation and maintenance of the power station.

[0068] Preferably, the strategy pattern of edge computing nodes is implemented through protocol configuration files and interface adapter classes. When a new protocol is added, only the corresponding adapter class is added.

[0069] In this embodiment, the power plant site refers to the actual physical deployment site of the power plant, which is the installation and operation environment of hardware such as power generation equipment and sensors, including functional areas such as power generation area, equipment room, and monitoring area.

[0070] In this embodiment, the edge computing node is a localized computing unit deployed at the power plant site, close to the data acquisition source. It uses hardware devices that support the EdgeXFoundry architecture and installs EdgeXFoundry edge computing software. Through policy mode adaptation, it adapts to Modbus (commonly used in inverters), OPCUA (general for industrial equipment), and DNP3 (specific for power systems) protocols to ensure that it can connect to different types of power plant equipment.

[0071] In this embodiment, multi-source data refers to various types of data collected from different sources and different types of equipment in the power station, such as equipment operation data (inverter output power, DC side voltage, wind turbine power generation, nacelle temperature); environmental data (solar intensity and ambient temperature of photovoltaic power station, wind speed and wind direction of wind power station); and status data (switch on / off status, equipment fault codes, and sensor online / offline status).

[0072] In this embodiment, the cleaning process adopts The criteria include: filtering outliers and replacing them with the mean; compression processing: for example, compressing power data from 10-second intervals into a time series to retain trend characteristics and reduce data volume; standardization processing: for example, converting voltage data from different inverters to V units to avoid using different kV units; and tagging: for example, adding device ID INV-001, collection timestamp 2024-05-20 15:30:00, and data type AC power to each data entry.

[0073] In this embodiment, "cloud" refers to a remote cloud computing platform that enables centralized management, analysis, and operation and maintenance scheduling of power plant data. MySQL is an open-source relational database management system suitable for storing structured data, supporting multi-table join queries, and commonly used for storing static data, configuration data, etc.

[0074] In this embodiment, the three-level association data model of power plant-equipment-sensor is a structured model that associates data from three levels: power plant, equipment, and sensor. A unique identifier (such as an ID) is used to establish a correspondence between levels, enabling a penetrating data query from power plant to equipment to sensor. Three core tables are created in MySQL: Power Plant Table (station): fields include station_id (primary key), station_name, location, and installed_capacity (installed capacity); Equipment Table (device): fields include device_id (primary key), station_id (foreign key, related to station_id in the station table), device_model, and install_time; Sensor Table (sensor): fields include sensor_id (primary key), device_id (foreign key, related to device_id in the device table), sensor_type, measure_range, and calibration_time. The unified query of the three levels of data is achieved through the association chain of station_id→device_id→sensor_id.

[0075] In this embodiment, the hierarchical storage strategy divides data into different storage media or databases based on the timeliness, frequency of use, and storage requirements of the data, thereby optimizing the allocation of storage resources and improving data query efficiency.

[0076] In this embodiment, cache storage temporarily stores frequently accessed and real-time data in high-speed storage media (such as Redis), reducing the number of queries from slow storage (such as MySQL, InfluxDB) and improving data access speed.

[0077] In this embodiment, the real-time heatmap is a visual chart that uses color gradients to represent the real-time distribution of data. The depth / warmth of the color corresponds to the level of the data value, which can intuitively present the real-time operating status distribution of different areas and different equipment in the power plant. Real-time data of each device (such as the real-time power of each inverter) is extracted from Redis, and the geographical coordinates of the devices are obtained (queried from the device table in MySQL). Using the ECharts visualization framework, the power plant base map is loaded on the front-end page, the device coordinates are bound to the real-time power data, and color gradient rules are set (such as #FF0000 for power ≥80% of the rated value, #FFFF00 for 50%-80%, and #00FF00 for <50%). The real-time heatmap is generated and the data is refreshed every 10 seconds (synchronized with the upload frequency of the edge nodes).

[0078] In this embodiment, the historical curve is a line chart with time on the horizontal axis and data value on the vertical axis, used to display the trend of data changes over time, and can intuitively present the operating status of the device over a period of time (such as power fluctuations and temperature changes). Historical data for a specified device (e.g., DEV-001) and a specified time range (e.g., 2024-05-20 08:00 to 18:00) is queried from InfluxDB2.0. The data shards (e.g., STA-001_NORTH_202405) are located through the inverted index. The Highcharts visualization framework is used, with the horizontal axis set to time (type: datetime) and the vertical axis to power (unit: kW), to draw a line chart (lineWidth=2, data point radius=4px, color #1E90FF). Mouse hover is supported to view the specific power value at the corresponding time point (e.g., hovering over 12:00 displays time: 58kW).

[0079] In this embodiment, the overlay display result is the result of combining real-time heatmaps with various visualization charts such as historical curves in the same display interface, realizing the synchronous presentation of real-time status and historical trends, which facilitates correlation analysis by operation and maintenance personnel.

[0080] For example, the central main screen of the multi-screen terminal (1920×1080 resolution) adopts a left-right column layout: the left column (occupying 60% of the width) displays the real-time power heat map of power station A (current data at 15:30), and the right column (occupying 40% of the width) displays the historical power curve of the selected inverter 001 for the day (08:00-15:30). The two are synchronized in time dimension. When the operation and maintenance personnel view a certain red area in the heat map, they can immediately view the historical trend of the equipment in that area in the right column to determine whether the real-time high power is in line with the normal pattern.

[0081] In this embodiment, CSS3 and Canvas rendering technologies are used: Style optimization: The heatmap uses CSS's linear-gradient to achieve color gradients, and the historical curve uses Canvas's lineCap=round to set the rounded corners of the lines; Resolution adaptation: The screen resolution of multiple terminals (such as 1920×1080, 3840×2160) is obtained through JavaScript, and the chart size is automatically adjusted (e.g., when the resolution is 3840×2160, the chart width is set to 1920px to avoid stretching and distortion); Interaction optimization: A hover pop-up is added to the chart. Features such as zoom (using the mouse wheel to zoom the historical curve time range) and pan (dragging the historical curve to view different time periods) enhance the ease of operation for maintenance personnel. For example, the real-time heatmap is edge-blurred (making color transitions more natural and avoiding harsh color block boundaries); the lines of the historical curves are thickened to 2px (for easier viewing from a distance); the font of the chart title is adjusted to 16px and the font of the data labels is adjusted to 12px (to avoid the font being too small to read); when the mouse hovers over the heatmap area, a device details pop-up window appears (displaying inverter 001: power 58kW, rated power 60kW, operating time 18 months).

[0082] In this embodiment, the multi-screen terminal is a terminal system composed of multiple independent displays. Industrial-grade LCD displays are selected and connected to a cloud-based display control server via HDMI cable or network. Multi-screen control software is installed on the server, and the content bound to each screen is set (the left screen is bound to the heatmap page URL, the middle screen to the historical curve page URL, and the right screen to the alarm page URL). Remote control is supported (e.g., maintenance personnel can adjust the screen display content from their office via a client, without needing to go to the monitoring room).

[0083] In this embodiment, based on the front-end visualization framework (ECharts, Highcharts, DataV), cloud data is transformed into diverse visual elements: real-time data is displayed using heatmaps and dashboards; historical data is displayed using line charts and bar charts; statistical data is displayed using pie charts and radar charts; display modules are divided according to operation and maintenance scenarios (such as real-time monitoring, historical analysis, and alarm centers), and visual elements are categorized into corresponding modules and displayed on multi-screen terminals by module to ensure a clear and orderly interface.

[0084] In this embodiment, the backend refers to the cloud-based backend service system, which is responsible for data reception, processing, storage, and business logic operations (such as alarm threshold calculation and work order generation).

[0085] In this embodiment, the Drools rule engine integrates Drools version 7.0 into the backend alarm service, and writes rule files (such as alarm_rule.drl): defines rule inputs (real-time device data, dynamic thresholds, weather data); defines rule conditions (such as $temp>$dynamicThreshold&&$duration>=300000, i.e., the temperature exceeds the threshold and lasts for 5 minutes); defines rule actions (triggers alarms, calls the work order interface); and sets a rule update mechanism (reads the latest weight data from MySQL every 24 hours, such as W1, W2, W3, and updates the threshold calculation logic in the rules).

[0086] In this embodiment, historical data refers to power plant data stored in the historical layer for a past period of time, including equipment operation history data, fault history data, alarm history data, etc.

[0087] In this embodiment, the Weather API is an application programming interface that provides weather data, obtaining real-time weather data (temperature, wind speed, precipitation probability) and short-term forecast data for the location of the power station.

[0088] In this embodiment, the alarm threshold is dynamically adjusted based on factors such as weather, historical equipment failures, and equipment aging, adjusting the critical value of the equipment alarm in real time.

[0089] In this embodiment, differentiated display uses different display styles for different types of information to enable quick differentiation of information and help maintenance personnel prioritize important information. For example, alarm information is displayed differently according to level: emergency alarms (such as inverter temperature exceeding dynamic threshold) use a red background and 16px bold flashing font (animation flashing frequency of 1 second / time), general alarms (such as power 5% low) use a yellow background and 14px regular font, and normal data uses a green background and 12px regular font; in the right screen (alarm screen) of the multi-screen terminal, emergency alarms are listed at the top, general alarms at the bottom, and normal data is not displayed.

[0090] In this embodiment, sound effect files are stored on the control server of the multi-screen terminal; when the backend alarm service triggers an alarm, it sends an instruction of alarm type + sound effect identifier to the front end; after receiving the instruction, the front end calls the HTML5 Audio API to play the corresponding sound effect through the audio device connected to the server; the sound effect parameters are set (70% for emergency alarms and 60% for general alarms to avoid the volume being too loud or too soft), and the current sound effect is automatically stopped and a cancellation prompt sound is played after the alarm is cleared.

[0091] In this embodiment, the synchronous generation of work orders means that when a multi-screen terminal displays a differentiated alarm (such as a flashing red alarm) and plays the corresponding sound effect, the backend automatically generates a document (work order) containing the operation and maintenance task details, achieving a seamless connection between alarm triggering and work order generation, avoiding the delay of manually creating work orders. For example, if inverter 001 triggers an emergency alarm for overheating (displayed as a flashing red alarm with a rapid sound effect), the backend immediately generates a work order: Work Order Number WO20240520001, Operation and Maintenance Task: Check the overheating problem of inverter 001, Equipment Location: North Zone Array 1 of Power Station A (GPS coordinates 31.2°N, 120.6°E), Responsible Person: Engineer Li (responsible for North Zone operation and maintenance), Creation Time, Required Processing Time Limit 2 hours; The work order is simultaneously sent to Engineer Li's WeChat and SMS.

[0092] In this embodiment, on-site operation and maintenance of the power plant involves maintenance personnel going to the power plant site to inspect, repair, and debug faulty equipment based on generated work orders, resolving equipment malfunctions, and ensuring the normal operation of the power plant.

[0093] The beneficial effects of the above technical solution are as follows: by collecting and preprocessing data at edge nodes, constructing a three-level association model and hierarchical storage in the cloud, implementing multi-screen visualization rendering and dynamic alarms, and synchronizing work orders for operation and maintenance, the entire process of power plant data collection, processing, storage, display, and operation and maintenance is made intelligent. This allows operation and maintenance personnel to intuitively grasp the real-time status and historical trends of the power plant, quickly locate equipment anomalies, reduce the false alarm rate by more than 70% with dynamic alarm thresholds, and shorten the fault handling cycle from 4 hours to within 1 hour with synchronized work orders, significantly improving power plant operation and maintenance efficiency, reducing operation and maintenance costs, and ensuring the long-term stable operation of the power plant.

[0094] This invention provides a smart cloud-based operation and maintenance method for power stations, step 1 of which includes:

[0095] EdgeXFoundry edge computing nodes are deployed at the power plant site, and Modbus / OPCUA / DNP3 protocols are adapted through policy mode to collect multi-source data from the power plant site.

[0096] Based on the edge computing node, the multi-source data is cleaned, compressed, and standardized in format, and device ID, timestamp, and data type tag are added.

[0097] Preprocessed data is uploaded to the cloud via the MQTT protocol, and ECDSA asymmetric encryption is used to protect the data transmission link.

[0098] The beneficial effects of the above technical solution are: by deploying nodes and adapting protocols, it is convenient to collect multi-source data, and further by cleaning, compressing, formatting and encrypting the data, the reliability and security of data transmission can be ensured.

[0099] This invention provides a smart cloud-based operation and maintenance method for power stations, which compresses multi-source data based on the edge computing node, including:

[0100] Based on the cleaning results, the original redundancy coefficient of each data in the multi-source data is determined, and the corresponding storage table is matched from the type-storage lookup table according to the data type of each data. A redundancy fitting function is established based on the historical redundancy coefficient of each stored data in the storage table.

[0101] Determine the correlation between the redundancy fitting function and the original redundancy coefficients. At the same time, establish a sequence of coefficient differences between each historical redundancy coefficient and the original redundancy coefficient, and construct a redundancy difference fitting function.

[0102] Obtain the historical storage queue of the storage unit corresponding to each stored data in the storage table, wherein the historical storage queue includes the historical remaining capacity after each historical update;

[0103] Sort the data groups after each historical update according to the historical remaining capacity;

[0104] Determine the correlation coefficient between the corresponding data in the multi-source data and the data group after each historical update, and perform a secondary sorting on the corresponding remaining historical capacity;

[0105] The remaining capacity threshold is determined based on the results of the first and second sorting processes.

[0106] Based on the maximum capacity of the data group after each historical update, and combined with the number of bytes in the header of the storage table, the theoretical capacity of the corresponding data is estimated.

[0107] Based on the correlation coefficients and the redundancy difference fitting function, and combined with the theoretical occupancy and remaining capacity threshold, the compression reference ratio of the corresponding data is obtained for compression processing.

[0108] In this embodiment, the cleaning result refers to the effective data set after removing outliers, eliminating duplicates, and correcting format errors from multi-source data.

[0109] In this embodiment, the original redundancy coefficient is a quantitative indicator that represents the degree of redundancy of a single piece of original data before it is cleaned. It reflects the proportion of duplicate or compressible information in the data and has a value range of 0-1 (0 means no redundancy and 1 means complete redundancy).

[0110] The original redundancy coefficient = 1 - (actual information entropy of the data / maximum information entropy of the data), where information entropy is calculated using the Shannon formula, and the maximum information entropy is the information entropy when all possible values ​​of the data are uniformly distributed. This is determined by analyzing the historical value range of statistical data. For example, if the power data range is 0-60kW, and is divided into 60 intervals of 1kW, the maximum information entropy = .

[0111] In this embodiment, the multi-source data of the power station is divided into three types of data: numerical data (such as inverter power, equipment temperature, ambient light intensity); status data (such as switch open / close status 0 / 1, sensor online / offline status); and fault data (such as equipment fault codes 00-normal, 01-high temperature).

[0112] In this embodiment, the type-storage lookup table is a structured table that records the mapping relationship between data types and corresponding storage tables. It is used to quickly determine the storage location of different types of data and avoid data storage chaos. Some of the contents are shown in Table 1:

[0113] Table 1 - Partial Contents of the Storage Type Lookup Table

[0114] TYPE_NUM Numerical data power_num_store Stores numerical data such as power and temperature. TYPE_STATE State data dev_state_store Store switch and sensor status data TYPE_FAULT Fault-type data fault_code_store Storage device fault code data

[0115] In this embodiment, the storage table is a structured data table in the cloud database used to store specific types of data. It contains field definitions (such as device ID, timestamp, and data value) and serves as a carrier of historical data. For example, the power_num_store storage table corresponding to numerical data has the following fields: device_id (device ID, such as INV-001); timestamp (collection timestamp, such as 2024-05-2015:30:00); data_value (data value, such as 57.8); data_unit (data unit, such as kW); and redundancy_coeff (historical redundancy coefficient, such as 0.8).

[0116] In this embodiment, the historical redundancy coefficient is the redundancy coefficient of the data already stored in the storage table. It is a historical record of the redundancy characteristics of this type of data over a period of time, used to reflect the long-term pattern of data redundancy. For example, in the power_num_store storage table, the historical redundancy coefficient of inverter 001's power data for the past 7 days is recorded as follows: Time 1 - 0.78, Time 2 - 0.82, Time 3 - 0.79, Time 24 - 0.81, Time 5 - 0.77, Time 6 - 0.80, Time 7 - 0.79. It can be seen that the redundancy coefficient of the device's power data is stable between 0.77 and 0.82.

[0117] In this embodiment, the redundancy fitting function is a function model constructed based on the historical redundancy coefficient sequence through mathematical fitting methods. It uses the least squares method for fitting, and preferentially selects a linear function or a quadratic function: when the historical redundancy coefficient sequence fluctuates little (e.g., standard deviation < 0.02), a linear function is used for fitting; when the fluctuation is large (standard deviation ≥ 0.02), a quadratic function is used for fitting. The fitting is implemented using Python's NumPy library.

[0118] In this embodiment, the coefficient correlation is an index that characterizes the degree of linear correlation between the output value of the redundancy fitting function (fitted redundancy coefficient) and the original redundancy coefficient of the current data. It is used to determine whether the historical redundancy trend can reflect the redundancy characteristics of the current data. The Pearson correlation coefficient is commonly used to measure this. For example, the original redundancy coefficient of the current power data of inverter 001 is 0.8, and the fitting redundancy coefficient of the fitting function (y=-0.002x+0.801) constructed based on the historical redundancy coefficient at x=8 is 0.783. The Pearson correlation coefficient between the fitted redundancy coefficient of the past 7 days and the original redundancy coefficient of the current day is 0.92, indicating that the two are highly positively correlated and the historical redundancy trend can reflect the redundancy characteristics of the current data.

[0119] In this embodiment, for example, the original redundancy coefficient of the current data to be processed is 0.8, and the historical redundancy coefficients of the last 5 stored data in the storage table are 0.78, 0.82, 0.79, 0.81, and 0.77. The difference between the historical redundancy coefficient and the original redundancy coefficient of each data is calculated to form a coefficient difference sequence [-0.02, 0.02, -0.01, 0.01, -0.03].

[0120] In this embodiment, the redundancy difference fitting function is a function model constructed through mathematical fitting based on the coefficient difference sequence. Its working principle is similar to that of the redundancy fitting function, and will not be described in detail here.

[0121] In this embodiment, the storage unit is used as physical or logical storage space to store the storage table data.

[0122] In this embodiment, the historical storage queue is an ordered list that records the remaining capacity of storage units after each historical update in chronological order. It is used to reflect the changing trend of storage unit capacity with data updates and to provide historical capacity data for subsequent sorting and threshold determination. For example, the remaining capacity of storage unit 1 after the last 6 historical updates are: time 01-20GB, time 02-18GB, time 03-115GB, time 04-112GB, time 05-110GB, and time 06-108GB, which are arranged in chronological order to form a historical storage queue [(time 01, 120GB), (time 02, 118GB), (time 03, 115GB), (time 04, 112GB), (time 05, 110GB), (time 06, 108GB)].

[0123] In this embodiment, a historical update is the operation of the storage table receiving new data and writing it to the storage unit. An update is considered complete whenever an event triggers a record of the remaining historical capacity. The remaining historical capacity is the amount of available storage space remaining in the storage unit after each historical update.

[0124] In this embodiment, a data group is a batch of data (containing one or more data entries) written to the storage table each time a history is updated. It is usually divided into batches by device ID and time, and is the basic unit for sorting.

[0125] In this embodiment, the information correlation coefficient is an indicator that characterizes the degree of information similarity between the current data to be processed and the data in the historical data group, reflecting the correlation between the two in terms of data features, and is calculated using cosine similarity or Pearson correlation coefficient.

[0126] In this embodiment, the first sorting is based on the historical remaining capacity, and all historically updated data groups are arranged in order. The second sorting is based on the information correlation coefficient as the primary sorting criterion, and the historical remaining capacity after the first sorting is arranged again. For example, the historical remaining capacity and corresponding information correlation coefficient after the first sorting are: Group 1 (120GB, 0.62), Group 2 (118GB, 0.75), Group 3 (115GB, 0.98), Group 4 (112GB, 0.85), and Group 5 (110GB, 0.90). The second sorting is performed in descending order of information correlation coefficient, and the result is Group 3 (0.98, 115GB) > Group 5 (0.90, 110GB) > Group 4 (0.85, 112GB) > Group 2 (0.75, 118GB) > Group 1 (0.62, 120GB). At this time, the sorting result takes into account both correlation and capacity.

[0127] In this embodiment, the remaining capacity of the first k historical records is extracted from the first and second sorting results respectively (k defaults to 5, configurable); a capacity weight w1 (default 0.4) and a correlation weight w2 (default 0.6, w1+w2=1) are set; the mean of the capacity dimension avg1 = (sum of the capacities of the first k records in the first sort) / k and the mean of the correlation dimension avg2 = (sum of the capacities of the first k records in the second sort) / k are calculated; the remaining capacity threshold = avg1×w1+avg2×w2; if the threshold is lower than the minimum available capacity of the storage unit (e.g., 5GB), the minimum available capacity is taken as the threshold to avoid storage overflow caused by the threshold being too low.

[0128] In this embodiment, the maximum occupied capacity is the maximum storage space size of a single data group in all historically updated data groups, reflecting the upper limit of storage requirements for this type of data group.

[0129] In this embodiment, the field name definition part of the storage table in the header is used to describe the meaning of each column of data in the table. It does not contain specific data records and is a fixed part of the storage table structure. It will occupy a certain amount of storage space. For example, the total length of the 5 field names is 20 characters, and with 4 separators, the header byte size is 20×1+4×1=24 bytes.

[0130] In this embodiment, bytes are the unit of storage space occupied by the header or data record.

[0131] In this embodiment, the theoretical occupancy is the estimated storage space size that will be occupied after the current data to be processed is written to the storage unit. It takes into account the storage unit capacity threshold, the maximum storage requirement of the historical data group, and the fixed overhead of the table header. The theoretical occupancy = the average of the ratio of the maximum occupancy capacity after all updates to the average number of rows in the corresponding historical data group + (the number of bytes in the table header / the current total number of rows in the storage table).

[0132] In this embodiment, ;

[0133] Actual remaining capacity = ;

[0134] Secondary compression ratio ;

[0135] ;

[0136] The base coefficient is set to 0.5 by default to ensure a basic level of compression; the redundancy weight is set to 0.1 by default; the difference weight is set to 0.5 by default; if the calculated compression reference ratio is <0.2 (over-compression may lead to data loss), then 0.2 is used; if it is >0.8 (under-compression), then 0.8 is used to ensure that the compression ratio is within a reasonable range. The compression ratio value for setting the remaining capacity threshold is generally 0.5.

[0137] The beneficial effects of the above technical solution are: through the entire process logic of redundancy coefficient calculation, storage table matching, fitting function construction, capacity sorting, threshold determination, theoretical occupancy estimation, compression ratio calculation, and compression processing, dynamic compression based on data redundancy characteristics and storage capacity requirements is achieved, reducing the amount of data transmitted between edge nodes and the cloud, shortening the transmission time, and providing efficient data support for subsequent cloud data analysis and operation and maintenance decisions.

[0138] This invention provides a smart cloud-based operation and maintenance method for power plants, wherein the three-level associated data model includes: power plant metadata, equipment attributes, and sensor data collection information;

[0139] The tiered storage strategy includes:

[0140] Real-time data is stored in Redis within 5 minutes, using the device ID and the collected item as the key;

[0141] Historical data ranging from 5 minutes to 3 years is stored in InfluxDB 2.0, with dual sharding by power plant region and time and an inverted index.

[0142] Static data is stored in MySQL, and batch queries are optimized using MyBatisPlus.

[0143] In this embodiment, the real-time layer (data within 5 minutes): the real-time power data of inverter 001 at time A0 is stored in Redis for easy and fast querying; the historical layer (data from 5 minutes to 3 years): the power data of all inverters in power plant A from January to May 2024 is stored in InfluxDB2.0, sharded by power plant region (e.g., North / South) + time (e.g., time B0); the static layer (long-term unchanging data): the name of power plant A, equipment model, sensor calibration time, etc., are stored in MySQL.

[0144] The beneficial effects of the above technical solution are: through the specific division of the three-level relational data model and the hierarchical storage strategy, a data foundation is provided for the subsequent display of results.

[0145] This invention provides a smart cloud-based operation and maintenance method for power plants, which renders the overlay display results for visualization on multi-screen terminals, including:

[0146] The hierarchical attribute set stored in the cache is compared and analyzed with the user's demand set, and the global structure scheme is determined in combination with the screen size of the multi-screen terminal. The overlay display result is then structurally laid out.

[0147] The division stamp for the real-time heat map is determined according to the thermal range division standard, and the superimposed display result is cut according to the division stamp to obtain several cut superimposed display blocks.

[0148] Extract the display features of each cut and overlay display block. At the same time, establish a first mapping relationship between each cut and overlay display block and the cached hierarchical attribute set, as well as a second mapping relationship with the user's demand set.

[0149] Based on the first mapping relationship and the second mapping relationship, an extended cluster is determined, and the display features are rendered and derived based on the extended cluster to obtain a sub-rendering scheme. At the same time, the key indicators of each cut and overlay display block are determined, and the block priority is determined.

[0150] A four-dimensional input group vector is constructed based on the theoretical resolution, block priority, block length, and sub-layout extracted from the structural layout of each cut and overlay display block's sub-rendering scheme.

[0151] The four-dimensional input vector group is input into the vector analysis model to obtain an overall rendering scheme containing each cut and overlay display block for rendering processing, and then visualized on a multi-screen terminal. The rendering parameters of each display screen in the multi-screen terminal are controlled separately.

[0152] In this embodiment, the hierarchical attribute set of the cache storage is extracted from the cloud hierarchical storage (Redis real-time layer, InfluxDB historical layer, MySQL static layer), and includes a set of attributes such as data level, data type, update frequency, and the device / power station to which it belongs. It is the basis for the visualization display of the basic data attributes.

[0153] In this embodiment, the user's requirement set is a set of visualization requirements proposed by the operation and maintenance personnel based on the work scenario, which includes information such as the data types they are interested in, the display format, the interaction frequency, and the priority.

[0154] In this embodiment, the comparative analysis involves matching and comparing the hierarchical attribute set with the user demand set, and filtering out the data that is contained in the attribute set and required by the demand set. For example, the real-time inverter power data, historical daily power generation curve, and equipment ledger in the hierarchical attribute set are matched one by one with the real-time power monitoring, power generation curve of the past 7 days, and ledger query in the user demand set. Sensor calibration records in the attribute set that are not mentioned in the demand set are removed. Finally, the core data that needs to be displayed are the first three items.

[0155] In this embodiment, the screen size of the multi-screen terminal is the physical resolution or pixel size of each independent display screen in the multi-screen terminal, which determines the amount of visual content that a single screen can carry and is the hardware basis for the global structure design.

[0156] In this embodiment, the global structure scheme is a scheme for planning the overall display layout of multi-screen terminals based on the screen size and comparative analysis results. For example, the left screen (2K): the upper half displays the real-time heat map of the inverter in the north area of ​​power station A (core requirement, occupying 60% of the screen), and the lower half displays the real-time alarm list (medium priority, occupying 40% of the screen); the middle screen (4K): the left half displays the historical curve of the power generation of the entire station (secondary requirement, occupying 50% of the screen), and the right half displays the real-time parameter dashboard of key equipment (transformer, combiner box) (core requirement, occupying 50% of the screen); the right screen (2K): the folded display of the equipment ledger query entrance (low priority, occupying 20% ​​of the screen), and the main area displays the progress of maintenance work orders (medium priority, occupying 80% of the screen).

[0157] In this embodiment, structural layout refers to a refined layout operation that performs position calibration, size adaptation, and hierarchy adjustment on the overlay display results. For example, structural layout is performed on the overlay display results in the right half of the middle screen: Position calibration: The transformer dashboard is adjusted from map coordinates (1200, 800) to (1150, 750) to avoid obscuring the combiner box icon; Size adaptation: The width of the power line graph is adjusted from 800 pixels to 900 pixels (to match the width of the right half of the middle screen), and the height is adjusted from 300 pixels to 400 pixels; Hierarchy adjustment: The data label hierarchy is moved from the top layer to the bottom layer of the dashboard to avoid obscuring the dashboard values; The final result is an unobstructed and size-fitting layout effect.

[0158] In this embodiment, the thermal range division standard is based on the color gradient rules of the heat map set according to the data value range (such as power and temperature). Different values ​​correspond to different colors to distinguish between high and low data, which is the basis for determining the division stamp. For example, the thermal range division standard for the power of photovoltaic power plant inverters is as follows: 0-30kW (low power): green (#00FF00); 30-60kW (medium power): yellow (#FFFF00); 60-80kW (high power): orange (#FFA500); 80-100kW (full power): red (#FF0000). This standard is formulated with reference to the inverter's rated power (100kW) and historical power distribution (30-80kW for most periods).

[0159] In this embodiment, the dividing stamp is the boundary value of different numerical intervals in the thermal range division standard. It serves as the cutting line for cutting and overlaying the display results, dividing the continuous heat map into independent display blocks according to numerical intervals. For example, based on the power thermal range division standard, the dividing stamp is three numerical boundaries: 30kW, 60kW, and 80kW. Correspondingly, on the heat map, the dividing stamp is represented by green-yellow, yellow-orange, and orange-red color boundary lines, dividing the heat map into four independent regions.

[0160] In this embodiment, the display features are the visual and data features of the cut and overlaid display blocks used to distinguish them from other blocks. These features include data features (type, update frequency), visual features (color, size), and interactive features (whether click / zoom is supported). For example, the display features of cut block 3 (60-80kW orange area) are as follows: Data features: Type = real-time inverter power + historical curve, update frequency = 10 seconds / time (power) + 1 minute / time (curve); Visual features: main color = orange (#FFA500), size = 400×300 pixels, border = 1px gray; Interactive features: supports clicking to view single inverter details, supports scrolling the historical curve with the scroll wheel.

[0161] In this embodiment, the first mapping relationship is the correspondence between the cut and overlay display block and the hierarchical attribute set of cache storage. It clarifies which specific attributes in the hierarchical attribute set the data components in the block originate from, ensuring that the data source is traceable. For example, the first mapping relationship of cut block 3 is: ① INV-15 real-time power label in the block → hierarchical attribute set Redis real-time layer - device INV-15 - power attribute; ② local power curve in the block → hierarchical attribute set InfluxDB historical layer - device INV15 - 30-minute power attribute; ③ orange main color of the block → hierarchical attribute set MySQL static layer - thermal standard attribute.

[0162] In this embodiment, the second mapping relationship is the correspondence between the segmented and overlaid display blocks and the user demand set, clarifying which specific user needs the displayed content of the block meets, and ensuring that the displayed content is aligned with the user's goals. For example, the second mapping relationship for segmented block 3 is: ① Real-time power label of the block + click to view details → Core demand of user demand set - real-time monitoring of inverter power (interaction requirement: click to view single device data); ② Local power curve of the block → Secondary demand of user demand set - view power trend (display format: line graph); ③ Orange main color of the block (60-80kW) → Core demand of user demand set - identify high-power devices (demand description: quickly locate full-power / high-power inverters).

[0163] In this embodiment, the sub-rendering scheme is a dedicated rendering scheme for a single cut-and-overlay display block, which combines its own display characteristics with the rendering derivation rules of its extended cluster. It includes specific visual parameters (color, font), interaction logic (click / zoom), and update frequency.

[0164] In this embodiment, key indicators are the data metrics that best reflect the equipment's operating status and meet the user's core needs within the segmented and overlaid display blocks. These are the key contents that need to be highlighted within the blocks, determining the information value priority of the blocks. For example, key indicators for inverter power monitoring include: real-time power value, power fluctuation amplitude, and full-power operation time.

[0165] In this embodiment, the block priority is based on the importance of key indicators of the cut and overlay display blocks, the priority of user needs, and the importance of the device. The display priority of the blocks is sorted, and the blocks with higher priority will get better display positions (such as centering or larger size) or higher update frequency on multi-screen terminals. The block priority is calculated based on a weighted scoring method, which is a prior art.

[0166] In this embodiment, the theoretical resolution is the ideal display resolution (pixel width × height) set for cutting and overlaying display blocks in the sub-rendering scheme. It is the optimal resolution calculated based on the number of components within the block and the display requirements of key indicators.

[0167] The block length is the horizontal or vertical pixel length of the cut and stacked display block in a multi-screen terminal (determined by the layout direction; width for horizontal layout and height for vertical layout).

[0168] Sub-layouts are local layout parameters extracted from the global structure scheme and used to cut and overlay display blocks. They include the block's position (top-left corner coordinates), the spacing between adjacent blocks, and the scale of the grid in which it is located.

[0169] In this embodiment, the four-dimensional input group vector is a numerical vector formed by combining the parameters of four dimensions: theoretical resolution (after normalization), block priority (after quantization), block length (after normalization), and sub-layout (after quantization) of the cut and superimposed display blocks.

[0170] In this embodiment, 1000 sets of power plant multi-screen rendering samples (each set containing a four-dimensional vector + optimal rendering scheme parameters) are used as training data to train a vector analysis model for a neural network model. For example, after inputting the vector [0.156, 0.67, 0.104, 1.0] of the cutting block 3, the model outputs the overall rendering scheme parameters: scaling ratio = 0.67 (scaling the theoretical resolution of 600 pixels to 400 pixels); anti-aliasing level = medium (balancing image quality and performance); refresh rate = 8 seconds / time (adapting to the update requirements of priority 2).

[0171] In this embodiment, the overall rendering scheme is based on the sub-rendering schemes, combined with the adaptation parameters (scaling ratio, anti-aliasing level, etc.) output by the vector analysis model, forming the final rendering scheme of the segmented and overlaid display blocks. For example, the overall rendering scheme of segment 3 is as follows: Visual parameters (sub-schemes + model adaptation): main color gradient #FFA500 to #FF8C00, scaling ratio 0.67 (theoretical 600 → actual 400 pixels), in the anti-aliasing level, the data label font is Microsoft YaHei 12px bold, and the curve line width is 2px; Interaction parameters: click to view details, double-click to zoom in 2 times, scroll wheel zoom (10 minutes - 2 hours); Performance parameters: refresh rate 8 seconds / time, cache duration 5 seconds (to reduce repeated rendering); Adaptation parameters: pixel compensation (edge ​​blurring processing) under 4K resolution on medium screens. For example: rendering of block 3: component drawing: draw the power curve using ECharts (with a line width of 2px and a color of #FF4500), and draw the inverter icon (50×50 pixels with an orange border) using Canvas; color filling: fill the block background with an orange gradient (#FFA500 to #FF8C00), and fill the key indicator labels with a semi-transparent white background (#FFFFFF80); interaction binding: bind click events (triggering a details pop-up), dblclick events (triggering zoom), and wheel events (triggering curve scaling) using JavaScript; performance optimization: enable WebGL to accelerate rendering, and cache static components (such as borders) as sprite images to reduce redrawing.

[0172] In this embodiment, the rendering parameters are the specific parameters that control the rendering effect of the cut and overlay display blocks. They include visual parameters (color, font, line width), performance parameters (refresh rate, anti-aliasing level), and adaptation parameters (scaling ratio, pixel compensation), and are the core configuration of the rendering process.

[0173] In this embodiment, individual control means that the rendering parameters (brightness, contrast, refresh rate) of each display screen in the multi-screen terminal can be adjusted independently, without being affected by other screens.

[0174] The beneficial effects of the above technical solution are: dynamically allocating multi-screen resources according to user needs priority, ensuring the uniformity of rendering style for similar data through extended clusters, adapting vector analysis models to screens with different resolutions, and individually controlling rendering parameters to meet the needs of multiple scenarios; ultimately reducing the time for operation and maintenance personnel to obtain key information by more than 50%, reducing the error rate by 30%, and improving multi-screen collaboration efficiency by 40%, effectively supporting efficient monitoring and rapid operation and maintenance decision-making for power plants.

[0175] This invention provides a smart cloud-based operation and maintenance method for power plants, which dynamically adjusts alarm thresholds, including:

[0176] Three types of core data are collected based on the backend data interface, including: historical equipment operation data, real-time weather dataset, and equipment metadata.

[0177] The three types of core data are standardized and normalized, and the following weights are determined: weather impact weight W1, historical fault weight W2, and equipment aging weight W3, specifically as follows:

[0178] ,in, This is the base weight for weather conditions, with a default value of 0.3. This is the normalized value of the average ambient temperature over multiple operating cycles; This is the normalized value of the current ambient temperature; This is the normalized value of the current wind speed; This is the normalized value of the maximum wind speed in multiple operating cycles; k1 and k2 are correction coefficients, determined by the historical alarm accuracy. If the calculation result exceeds [0.2, 0.6], the nearest regional boundary value is automatically taken. For reference, weather weighting;

[0179] ,in, The maximum number of historical warnings for the same type of equipment within a certain number of cycles; This refers to the historical number of warnings for the same type of device within the current period. For reference fault weights;

[0180] , among which, when If, in years, calculated over 10 years, if Years are calculated as 1 year. For reference aging weight;

[0181] according to and Calculate the corresponding weather impact weight W1, historical fault weight W2, and equipment aging weight W3;

[0182] and .

[0183] Based on the weather impact weight W1, historical fault weight W2, and equipment aging weight W3, the initial dynamic threshold Tin is dynamically adjusted. The Drools rule engine is set to update W1, W2, and W3 every 24 hours.

[0184] The beneficial effects of the above technical solution are: by collecting three types of core data, standards, and normalization processing, the weights can be updated regularly.

[0185] This invention provides a smart cloud-based power station operation and maintenance method, which relies on the extended cluster to render and derive the display features to obtain a sub-rendering scheme, including:

[0186] The first truth value parameter is determined based on the first mapping relationship. And determine the second truth value parameter based on the second mapping relationship. ;

[0187] Determine the virtual and real degree parameters based on the first mapping relationship. And determine the virtual / real degree parameter based on the second mapping relationship. And record the virtual and real deviation values. ;

[0188] Calculate the mapping synergy ,in, These are the weighting coefficients, and ;

[0189] when At that time, extract the core feature vector V0 and filter those that meet the requirements. And candidate features that satisfy the relaxed threshold constraint, form an extended cluster S, where, The similarity threshold; The threshold is denoted as u; u represents the candidate feature.

[0190] Determine the feature contribution bj of element fj in extended cluster S, and combine it with the cosine similarity with the core feature vector V to obtain the rendering sensitivity coefficient mj, which is used to characterize the priority weight of element fj in rendering.

[0191] Define a rendering dimension set D, which includes color depth, data sampling rate, dynamic refresh threshold, and spatial layout proportion.

[0192] For each element fj, the correlation degree Rjd with each dimension is calculated by combining the realism Tj, virtuality Xj of the mapping, and the basic weight of the rendering dimension.

[0193] Filter the dimensions whose relevance Rjd meets the threshold, and form the target rendering dimension subset Dj of element fj;

[0194] For each dimension in Dj, calculate the dynamic parameter value Pjd based on the baseline parameter, the rendering sensitivity coefficient mj, and the extended cluster synergy deviation.

[0195] By introducing hardware limits and minimum requirements for operation and maintenance scenarios for multi-screen terminals, the dynamic parameter value Pjd is pruned to output a sub-rendering scheme.

[0196] In this embodiment, the first truth value parameter is determined based on the first mapping relationship. ,in, These are the weighting coefficients, and , To display the weighted cosine similarity between block features and attribute set fields; The percentage of information entropy for non-related fields in the attribute set; This represents the original number of historical mappings. This represents the highest historical number of mappings for similar display blocks in the power station. This is the normalized result of the difference between the timestamp of the attribute set data and the current time. The failure rate inversion value of the sensor for the past 30 days was collected to obtain this attribute data; This refers to the matching rate of the attribute across hierarchical related fields in the three-level related data model.

[0197] In this embodiment, cosine similarity is calculated using scikit-learn, information entropy ratio is calculated using numpy, historical mapping times are queried from the database, timestamp difference is calculated and normalized using datetime, and C1 is obtained by inversion after statistical analysis of sensor failure rate from the operation and maintenance system.

[0198] For example, regarding the real-time power thermal block of the inverter The values ​​are 0.4, 0.3, and 0.3 respectively.

[0199] Based on the second mapping relationship, determine the second truth value parameter. ,in, The weighting coefficients and , This is the ratio of the number of hit keywords to the length of the display block feature field; This represents the semantic expansion coefficient of the keyword. The information entropy normalized value for user clicks, pauses, and zoom operations on similar display blocks; Priority coefficient for the user's assigned operations and maintenance role; The difference between the user request's posting time and the current time is calculated using the hyperbolic tangent function, and ,and In seconds; Similarity of user interaction behaviors for the same need;

[0200] In this embodiment, keyword matching degree is calculated by string matching algorithm, semantic expansion coefficient is calculated by Word2Vec model, information entropy is analyzed by user behavior log, role priority is obtained from permission system, K2 is calculated by timestamp difference, and interaction similarity U2 is obtained by user behavior clustering (K-means).

[0201] For example, regarding inverter power The values ​​are 0.4, 0.3, and 0.3 respectively.

[0202] Based on the first mapping relationship, determine the virtual and real degree parameters. ,in, The percentage of fields in the attribute set that are not processed; Calculate depth for derived data; Normalized value for the number of queryable levels in the data storage path; Data encryption level; These are the weighting coefficients, and ;

[0203] In this embodiment, the proportion of unprocessed data is statistically determined by data field type markers (e.g., raw identifies raw data), the derived calculation depth is obtained from the data processing log, the storage level is calculated by dividing the file path, and the encryption level is read from the database encryption configuration and then normalized. For example, the proportion of unprocessed data in the attribute set is P1=0.6, the derived data calculation depth is Q1=2 (P1 / Q1=0.3), the normalized queryable storage path level is L01=0.8, and the data encryption level is G01=0.7 (L01 / G01≈1.0). Weights =0.5、 =0.5, so we can calculate X1 = 0.5 × 0.3 + 0.5 × 1.0 = 0.65.

[0204] Based on the second mapping relationship, determine the virtual and real degree parameters. ,in, These are the weighting coefficients, and , The percentage of directly matched items; This is the logical chain length; This refers to the timeliness coefficient of demand. User role weights;

[0205] In this embodiment, directly matched entries are statistically analyzed from the mapping logs, the logical chain length is extracted from the requirements analysis document, and a timeliness coefficient is set based on the requirement release time relative to the current time (e.g., 0.8 within one week). User role weights are obtained from the permission system. For example, if the percentage of directly matched entries is A1=0.7, the logical chain length is B1=3 (A1 / B1≈0.233), the requirement timeliness coefficient is T02=0.8, and the user role weight is Z02=0.9 (T02 / Z02≈0.889). =0.6、 =0.4, so X2 = 0.6 × 0.233 + 0.4 × 0.889 ≈ 0.496.

[0206] Record the virtual and real deviation values ;

[0207] Calculate the mapping synergy ,in, These are the weighting coefficients, and ;

[0208] In this embodiment, weight Determined through testing, for example... The values ​​are 0.6 and 0.4 respectively.

[0209] when At that time, extract the core feature vector V0 and filter those that meet the requirements. The candidate features that satisfy the relaxed threshold constraint are combined to form an extended cluster S.

[0210] In this embodiment, the core features are: inverter power, real-time data, and advanced operation and maintenance requirements, with vector V0=[0.9,0.8, 0.9] (normalized values ​​of each feature).

[0211] In this embodiment, the threshold constraint is relaxed: Among them, T10 and T20 are the basic thresholds, with values ​​ranging from 0.6 to 0.7. The threshold is the virtual-real threshold, ranging from 0.5 to 0.6. The basic threshold is determined by the minimum value of the index of historical high-quality mapping cases, and multiplied by 0.8 to obtain the relaxation threshold.

[0212] In this embodiment, the hardware upper limit refers to the maximum performance parameters of the multi-screen terminal hardware, such as the upper limit of resolution, refresh rate, and data sampling rate, which are upper limits of rendering parameters. For example, the upper limit of the display hardware is a resolution of 3840×2160, a refresh rate of 60Hz, and a data sampling rate of 100 times / second.

[0213] In this embodiment, the minimum requirements for the operation and maintenance scenario are the minimum parameters necessary for the operation and maintenance scenario, such as the lower limit of data sampling rate and refresh rate, which are the lower limit constraints of rendering parameters. For example, the fault monitoring scenario requires a data sampling rate of ≥5 times / second and a refresh rate of ≥20Hz.

[0214] In this embodiment, the dynamic parameter value Pjd is a dynamic rendering parameter calculated by combining rendering dimensions, sensitivity coefficients, etc., such as resolution, sampling rate, and refresh rate, and needs to be trimmed between the hardware upper limit and the scene's minimum requirements. For example, the calculated dynamic sampling rate Pjd = 50 times / second, and the dynamic resolution Pjd = 2560×1440.

[0215] In this embodiment, pruning involves adjusting the dynamic parameter value Pjd to a level where the hardware upper limit is greater than or equal to the minimum requirements of the scene, ensuring parameter feasibility. The sub-rendering scheme is the final rendering scheme composed of the pruned dynamic parameters, containing specific parameters for each dimension (such as resolution, sampling rate, and refresh rate). For example, a sub-rendering scheme might have a resolution of 2560×1440, a sampling rate of 30 times / second, a refresh rate of 30Hz, and a spatial layout occupancy of 0.6.

[0216] In this embodiment, the feature contribution bj is the degree of contribution of element fj in the extended cluster S to the core feature, and is an indicator of the importance of the element. As a reserved value, the contribution bj of the power curve feature of element fj to the real-time power monitoring of the core feature is 0.8.

[0217] In this embodiment, the rendering sensitivity coefficient mj is obtained by combining the feature contribution bj and the cosine similarity with the core feature vector, and is an index that characterizes the priority weight of an element in rendering.

[0218] In this embodiment, the rendering dimension set D includes a set of dimensions such as color depth, data sampling rate, dynamic refresh threshold, and spatial layout ratio, which are the core dimensions of the rendering parameters.

[0219] In this embodiment, the correlation degree Rjd is the degree of correlation between element fj and each rendering dimension, which measures the importance of the dimension to the element. It is determined through domain knowledge or data analysis (such as statistically analyzing the correlation of element display effects under different dimensions).

[0220] In this embodiment, the target rendering dimension subset Dj is a subset of dimensions whose correlation Rjd is greater than or equal to a threshold, forming the exclusive rendering dimension subset of element fj. For example, if the threshold is 0.7, element fj's Rjd satisfies the data sampling rate of 0.9 and spatial layout ratio of 0.8, but not the color depth of 0.6. Therefore, Dj = {data sampling rate, spatial layout ratio}.

[0221] In this embodiment, the baseline parameters are the default reference parameters for each rendering dimension and form the basis for dynamic parameter calculations. For example, the baseline parameter table includes: 8-bit color depth, 10 data sampling rates per second, a dynamic refresh threshold of 5 seconds, and a space layout occupancy of 0.5. These parameters are determined by designers or operational specifications and stored in a configuration file.

[0222] In this embodiment, the extended cluster synergy deviation is the deviation (such as standard deviation) of the degree of synergy among elements within the extended cluster, which affects the stability of dynamic parameter calculation.

[0223] The beneficial effects of the above technical solution are: through the collaborative mapping of authenticity and virtuality in two dimensions, intelligent trimming of rendering parameters, and priority of extended cluster sensitivity, a deep collaboration of mapping accuracy, rendering adaptability, and feature priority can be achieved in power plant operation and maintenance. It can dynamically adapt the authenticity of data and demand mapping, intelligently trim rendering parameters to match hardware and scene, and ensure the priority display of core features through extended clusters and sensitivity coefficients, making power plant operation and maintenance more intelligent and efficient.

[0224] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A smart cloud-based operation and maintenance method for power stations, characterized in that, include: Step 1: Collect multi-source data based on edge computing nodes deployed at the power plant site, and preprocess the collected data before uploading it to the cloud; Step 2: Construct a three-level correlation data model of the preprocessed data (power station-equipment-sensor) based on MySQL in the cloud, and cache and store the preprocessed data received in the cloud in combination with a hierarchical storage strategy; Step 3: Extract real-time heatmaps and historical curves from cache storage, and render the overlay display results for visualization on multi-screen terminals. At the same time, based on the Drools rule engine deployed on the backend, combine historical data and weather API to dynamically adjust alarm thresholds, and display and play sound effects in a differentiated manner on the multi-screen terminals. The rendering process of the overlay display result for visual display on multi-screen terminals includes: The hierarchical attribute set stored in the cache is compared and analyzed with the user's demand set, and the global structure scheme is determined in combination with the screen size of the multi-screen terminal. The overlay display result is then structurally laid out. The division stamp for the real-time heat map is determined according to the thermal range division standard, and the superimposed display result is cut according to the division stamp to obtain several cut superimposed display blocks. Extract the display features of each cut and overlay display block. At the same time, establish a first mapping relationship between each cut and overlay display block and the cached hierarchical attribute set, as well as a second mapping relationship with the user's demand set. Based on the first mapping relationship and the second mapping relationship, an extended cluster is determined, and the display features are rendered and derived based on the extended cluster to obtain a sub-rendering scheme. At the same time, the key indicators of each cut and overlay display block are determined, and the block priority is determined. A four-dimensional input group vector is constructed based on the theoretical resolution, block priority, block length, and sub-layout extracted from the structural layout of each cut and overlay display block's sub-rendering scheme. The four-dimensional input vector is input into the vector analysis model to obtain an overall rendering scheme containing each cut and overlay display block for rendering processing, and then visualized on a multi-screen terminal. The rendering parameters of each display screen in the multi-screen terminal are controlled independently. The vector analysis model is trained using 1000 sets of power plant multi-screen rendering samples as training data. Each set of samples contains a four-dimensional vector and the optimal rendering scheme parameters. Step 4: Based on the visualization results, differentiated display results, and playback sound effects, generate work orders simultaneously to carry out on-site operation and maintenance of the power station.

2. The operation and maintenance method for a smart cloud-based power station according to claim 1, characterized in that, Step 1 includes: EdgeXFoundry edge computing nodes are deployed at the power plant site, and Modbus / OPCUA / DNP3 protocols are adapted through policy mode to collect multi-source data from the power plant site. Based on the edge computing node, the multi-source data is cleaned, compressed, and standardized in format, and device ID, timestamp, and data type tag are added. Preprocessed data is uploaded to the cloud via the MQTT protocol, and ECDSA asymmetric encryption is used to protect the data transmission link.

3. The operation and maintenance method for a smart cloud-based power station according to claim 2, characterized in that, Compression processing of the multi-source data based on the edge computing node includes: Based on the cleaning results, the original redundancy coefficient of each data in the multi-source data is determined, wherein the original redundancy coefficient = 1 - (actual information entropy of data / maximum information entropy of data), the information entropy is calculated according to the Shannon formula, and the maximum information entropy is the information entropy when all possible values ​​of the data are evenly distributed, which is determined by the historical value range of statistical data. Based on the data type of each data entry, the corresponding storage table is matched from the type-storage lookup table, and a redundancy fitting function is established based on the historical redundancy coefficient of each stored data entry in the storage table. The redundancy fitting function is fitted using the least squares method. When the standard deviation of the historical redundancy coefficient sequence is <0.02, a linear function is used for fitting, and when the standard deviation is ≥0.02, a quadratic function is used for fitting. The correlation between the redundancy fitting function and the original redundancy coefficient is determined, wherein the correlation is measured using the Pearson correlation coefficient; simultaneously, a sequence of coefficient differences between each historical redundancy coefficient and the original redundancy coefficient is established, and a redundancy difference fitting function is constructed; wherein the redundancy difference fitting function is fitted using the least squares method. Obtain the historical storage queue of the storage unit corresponding to each stored data in the storage table, wherein the historical storage queue includes the historical remaining capacity after each historical update; Sort the data groups after each historical update according to the historical remaining capacity; Determine the information correlation coefficient between the corresponding data in the multi-source data and the data group after each historical update, wherein the information correlation coefficient is calculated using cosine similarity or Pearson correlation coefficient, and perform a secondary sorting on the corresponding historical remaining capacity; Based on the results of the first and second sorting, the remaining capacity threshold is determined as follows: Extract the first k remaining historical capacity from the first and second sorting results respectively, where k is set to 5 by default; set the capacity weight w1 and the correlation weight w2; calculate the mean of the capacity dimension avg1 = (sum of the capacities of the first k sorted records) / k, and the mean of the correlation dimension avg2 = (sum of the capacities of the first k sorted records) / k; the remaining capacity threshold = avg1 × w1 + avg2 × w2; Based on the maximum occupied capacity of the data group after each historical update, and combined with the number of bytes in the header of the storage table, the theoretical occupied capacity of the corresponding data is estimated; wherein, the theoretical occupied capacity = the average of the ratios of the maximum occupied capacity after all updates to the average number of rows in the corresponding historical data group + (header bytes / current total number of rows in the storage table). Based on the aforementioned coefficient correlation and redundancy difference fitting function, and combined with the theoretical occupancy and remaining capacity threshold, a compression reference ratio is obtained for the corresponding data for compression processing; where, theoretical occupancy = average of the ratios of the maximum occupancy after all updates to the average number of rows in the corresponding historical data group + (header bytes / current total number of rows in the storage table); compression reference ratio = Actual remaining capacity = Total capacity of corresponding storage units - Theoretical usage × Actual number of data entries - Header bytes; Secondary compression ratio = The compression ratio is calculated as follows: base coefficient × correlation coefficient × redundancy weight + |redundancy difference function value| × difference weight. If the calculated compression reference ratio is <0.2, then take 0.2; if it is >0.8, then take 0.

8.

4. The operation and maintenance method for a smart cloud-based power station according to claim 1, characterized in that, The three-level association data model includes: power plant metadata, equipment attributes, and sensor data collection items. The tiered storage strategy includes: Real-time data is stored in Redis within 5 minutes, using the device ID and the collected item as the key; Historical data ranging from 5 minutes to 3 years is stored in InfluxDB 2.0, with dual sharding by power plant region and time and an inverted index. Static data is stored in MySQL, and batch queries are optimized using MyBatisPlus.

5. The operation and maintenance method for a smart cloud-based power station according to claim 1, characterized in that, Dynamically adjusting alarm thresholds, wherein the dynamic adjustment of alarm thresholds includes: Three types of core data are collected based on the backend data interface, including: historical equipment operation data, real-time weather dataset, and equipment metadata. The three types of core data are standardized and normalized, and the following weights are determined: weather impact weight W1, historical fault weight W2, and equipment aging weight W3; specifically: ,in, This is the base weight for weather conditions, with a default value of 0.

3. This is the normalized value of the average ambient temperature over multiple operating cycles; This is the normalized value of the current ambient temperature; This is the normalized value of the current wind speed; This is the normalized value of the maximum wind speed in multiple operating cycles; k1 and k2 are correction coefficients, determined by the historical alarm accuracy. If the calculation result exceeds [0.2, 0.6], the nearest regional boundary value is automatically taken. For reference, weather weighting; ,in, The maximum number of historical warnings for the same type of equipment within a certain number of cycles; This refers to the historical number of warnings for the same type of device within the current period. For reference fault weights; , among which, when If, in years, calculated as 10 years, if Years are calculated as 1 year. For reference aging weight; according to , and Calculate the corresponding weather impact weight W1, historical fault weight W2, and equipment aging weight W3; and , , ; Based on the weather impact weight W1, historical fault weight W2, and equipment aging weight W3, the initial dynamic threshold Tin is dynamically adjusted. The Drools rule engine is set to update W1, W2, and W3 every 24 hours.

6. The operation and maintenance method for a smart cloud-based power station according to claim 1, characterized in that, The rendering of the display features is derived based on the extended cluster to obtain a sub-rendering scheme, including: The first truth value parameter is determined based on the first mapping relationship. : ,in, , , These are the weighting coefficients, and , To display the weighted cosine similarity between block features and attribute set fields; The percentage of information entropy for non-related fields in the attribute set; This represents the original number of historical mappings. This represents the highest historical number of mappings for similar display blocks in the power station. This is the normalized result of the difference between the timestamp of the attribute set data and the current time. The failure rate inversion value of the sensor for the past 30 days was collected from the attribute set data; The matching rate of attributes in the attribute set data across hierarchical association fields in the three-level association data model; The second truth value parameter is determined based on the second mapping relationship. : ,in, , , The weighting coefficients and , This is the ratio of the number of hit keywords to the length of the display block feature field; This represents the semantic expansion coefficient of the keyword. The information entropy normalized value for user clicks, pauses, and zoom operations on similar display blocks; Priority coefficient for the user's assigned operations and maintenance role; The difference between the user request's posting time and the current time is calculated using the hyperbolic tangent function, and ,and In seconds; Similarity of user interaction behaviors for the same need; Determine the virtual and real degree parameters based on the first mapping relationship. : ,in, The percentage of fields in the attribute set that are not processed; Calculate depth for derived data; Normalized value for the number of queryable levels in the data storage path; Data encryption level; , These are the weighting coefficients, and ; Determine the virtual and real degree parameters based on the second mapping relationship. : ,in, , These are the weighting coefficients, and , The percentage of directly matched items; This is the logical chain length; This refers to the timeliness coefficient of demand. User role weights; Record the virtual-to-real deviation value. ; Calculate the mapping synergy ,in, , These are the weighting coefficients, and ; when At that time, extract the core feature vector V0 and filter those that meet the requirements. And candidate features that satisfy the relaxed threshold constraint, form an extended cluster S, where, The similarity threshold; The threshold is the collaborative threshold; u is the candidate feature; the relaxed threshold constraint is... , , , Among them, T10 and T20 are the basic thresholds. The threshold is the virtual-real threshold. The basic threshold is determined by the minimum value of the index of historical high-quality mapping cases, and multiplied by 0.8 to obtain the relaxation threshold. The feature contribution value bj of element fj in extended cluster S is determined, and the rendering sensitivity coefficient mj is obtained by combining the cosine similarity with the core feature vector V. The rendering sensitivity coefficient mj is obtained by combining the feature contribution value bj and the cosine similarity with the core feature vector, and is used to characterize the priority weight of element fj in rendering. Define a rendering dimension set D, which includes color depth, data sampling rate, dynamic refresh threshold, and spatial layout proportion. For each element fj, the correlation degree Rjd with each dimension is calculated by combining the realism Tj, virtuality Xj of the mapping, and the basic weight of the rendering dimension. Filter the dimensions whose relevance Rjd meets the threshold, and form the target rendering dimension subset Dj of element fj; For each dimension in Dj, calculate the dynamic parameter value Pjd based on the baseline parameter, the rendering sensitivity coefficient mj, and the extended cluster synergy deviation; By introducing hardware limits and minimum requirements for operation and maintenance scenarios for multi-screen terminals, the dynamic parameter value Pjd is pruned to output a sub-rendering scheme.

7. The operation and maintenance method for a smart cloud-based power station according to claim 1, characterized in that, The strategy pattern of edge computing nodes is implemented through protocol configuration files and interface adapter classes. When a new protocol is added, only the corresponding adapter class is added.

Images