Distributed energy data monitoring and cleaning method and system based on cloud platform

Abstract

This invention relates to the field of data cleaning technology, and more particularly to a method for monitoring and cleaning distributed energy data based on a cloud platform. The method includes the following steps: periodically and synchronously monitoring and collecting the power generation, load power, and network connection status parameters of distributed energy terminals to generate equipment operating parameters; identifying data breakpoints in the equipment operating parameters; determining linear interpolation instructions based on the network communication status of the data breakpoints, and using the data interpolation instructions to filter potential abnormal datasets of the equipment operating parameters; determining anomaly identification conditions using the potential abnormal datasets; and, while continuously receiving energy data on the cloud platform, automatically invoking the linear interpolation instructions when the anomaly identification conditions are met, generating a cleaning processing log and updating the data status label. This invention achieves intelligent cleaning and correction of distributed energy operating data throughout the entire process based on data cleaning technology, thereby improving the continuity and reliability of distributed energy data.

Description

Technical Field

[0001] This invention relates to the field of data cleaning technology, and in particular to a method and system for monitoring and cleaning distributed energy data based on a cloud platform. Background Technology

[0002] Currently, distributed energy systems are playing an increasingly important role in new power systems and the energy internet. Accurate monitoring and data management of their operational status have become crucial for ensuring system stability and optimizing dispatch efficiency. However, the large number of distributed energy terminals, their wide geographical distribution, and complex communication environments lead to frequent quality issues in the collected operational data, such as delays, packet loss, breakpoints, and time-series disorders, severely impacting the accuracy of subsequent data analysis and decision support. Existing data cleaning methods largely rely on local processing or static rules, making it difficult to adapt to the dynamic and ever-changing network conditions and equipment operating characteristics in distributed energy scenarios, resulting in a lack of targeted and flexible processing strategies. Furthermore, existing technologies often employ single interpolation methods in key stages such as data breakpoint identification, channel jitter judgment, and abnormal data recovery, failing to incorporate differentiated corrections based on the data's inherent trends and communication link status. This can easily introduce systematic biases, affecting the reliability of the cleaned data. Simultaneously, existing systems generally lack log recording and status tag management for the cleaning process, hindering the tracking and further correction of residual abnormal data, thus limiting their promotion and application in large-scale distributed energy monitoring platforms. Summary of the Invention

[0003] Therefore, the present invention needs to provide a distributed energy data monitoring and cleaning method and system based on a cloud platform to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, a cloud-based distributed energy data monitoring and cleaning method includes the following steps:

[0005] Step S1: Periodically and synchronously monitor and collect the power generation, load power, and network connection status parameters of the distributed energy terminal to generate equipment operating parameters; identify data breakpoints in the equipment operating parameters;

[0006] Step S2: Determine the linear interpolation instruction based on the network communication status in the data breakpoint, and use the data interpolation instruction to filter potential abnormal datasets of equipment operating parameters;

[0007] Step S3: Determine the anomaly identification conditions using the potential anomaly dataset; while continuously receiving energy data on the cloud platform, when the anomaly identification conditions are met, automatically call the linear interpolation instruction to generate a cleaning processing log and update the data status label;

[0008] Step S4: Identify residual data using data status tags and cleaning processing logs; use the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

[0009] This specification also provides a cloud-based distributed energy data monitoring and cleaning system for performing the cloud-based distributed energy data monitoring and cleaning method described above. The cloud-based distributed energy data monitoring and cleaning system includes:

[0010] The data acquisition module is used to periodically and synchronously monitor and collect the power generation, load power, and network connection status parameters of distributed energy terminals to generate equipment operating parameters and identify data breakpoints in the equipment operating parameters.

[0011] The instruction generation module is used to determine linear interpolation instructions based on the network communication status in the data breakpoints, and to use the data interpolation instructions to filter potential abnormal datasets of device operating parameters.

[0012] The cleaning log generation module is used to determine the anomaly identification conditions using the potential anomaly dataset. When the anomaly identification conditions are met while continuously receiving energy data on the cloud platform, the linear interpolation instruction is automatically invoked to generate cleaning processing logs and update the data status labels.

[0013] The calibration data module is used to identify residual data using data status tags and cleaning processing logs; it uses the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

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

[0015] On the one hand, by periodically and synchronously monitoring and collecting the power generation, load power, and network connection status parameters of distributed energy terminals, a set of equipment operating parameters with high timeliness and completeness can be constructed in real time, effectively improving the comprehensive perception of operating status. Based on time series continuity analysis and communication parameter consistency verification, the location and type of data breakpoints can be accurately identified, overcoming the problems of insufficient sensitivity to abnormal data and lagging breakpoint identification in traditional methods, laying the foundation for the dynamic scheduling of subsequent cleaning and repair strategies.

[0016] On the other hand, by combining network communication status and link quality indicators to classify and judge data breakpoints, and generating targeted linear interpolation instructions accordingly, a data repair strategy that matches the actual link status can be implemented, avoiding the problems of slow response and high misjudgment rate of static interpolation methods to data trend changes. By jointly constructing a potential anomaly dataset using interpolation deviation and rate of change features, the system's ability to identify multi-source anomaly features is improved, providing accurate support for subsequent anomaly condition judgment and processing instruction triggering.

[0017] On the other hand, during the continuous reception of energy data on the cloud platform, a dynamic matching mechanism based on anomaly identification conditions can trigger the interpolation cleaning process in real time and generate cleaning processing logs, while simultaneously updating data status tags. This enables full-process recording and status traceability of the data cleaning process. By re-identifying and correcting residual anomalies using data status tags and cleaning logs, the reliability and completeness of equipment operating parameters can be further improved. This overcomes the shortcomings of insufficient residual data processing and lack of correction mechanisms in existing systems, significantly enhancing the overall data quality assurance capability and strengthening the system's robustness to communication fluctuations and data anomalies in distributed energy environments. Attached Figure Description

[0018] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0019] Figure 1 This is a schematic diagram of the steps of the distributed energy data monitoring and cleaning method based on a cloud platform according to the present invention.

[0020] Figure 2 This is a schematic diagram of the modules of the distributed energy data monitoring and cleaning system based on a cloud platform according to the present invention;

[0021] Figure 3 This is a schematic diagram of channel jitter in the present invention;

[0022] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] The technical method of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this invention.

[0024] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0025] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0026] To achieve the above objectives, please refer to Figures 1 to 3 This invention provides a method for monitoring and cleaning distributed energy data based on a cloud platform, the method comprising the following steps:

[0027] Step S1: Periodically and synchronously monitor and collect the power generation, load power, and network connection status parameters of the distributed energy terminal to generate equipment operating parameters; identify data breakpoints in the equipment operating parameters;

[0028] In one embodiment, a power acquisition device and a network status monitoring module deployed at a distributed energy terminal periodically acquire the three-phase voltage and current on the generator side at a frequency of 0.5Hz and calculate its instantaneous power generation. Simultaneously, voltage, current, and power factor are acquired on the load side to calculate the load power. The network status acquisition module records the average delay and packet loss rate during each transmission based on communication quality parameters returned by the access point. The system performs a timing check on the operating data within a continuous 300 seconds. If the time interval between two adjacent data records exceeds 1.5 times the sampling period (i.e., the interval is greater than 3 seconds), it is marked as a data breakpoint.

[0029] In another embodiment, assuming the sampling frequency is set to 1Hz, the system continuously collects 360 data records. Differential analysis revealed that the interval between records 58-59 is 3.2s, between records 129-130 is 3.5s, and between records 270-271 is 4.1s, all exceeding 1.5 times the sampling period (1.5s). Therefore, these three locations were identified as data breakpoints. Statistical results show that the total breakpoint rate is 0.83%, which can be processed by the subsequent interpolation and repair module.

[0030] Step S2: Determine the linear interpolation instruction based on the network communication status in the data breakpoint, and use the data interpolation instruction to filter potential abnormal datasets of equipment operating parameters;

[0031] In one embodiment, for identified data breakpoints, the system extracts the handshake failure response code and link break flag from their communication status and evaluates the frequency of link break events using a 10-second sliding window. If the number of consecutive link breaks exceeds three and the handshake failure code appears more than twice, it is determined to be a channel jitter-type data breakpoint. Subsequently, the system schedules a linear interpolation module to identify the data trend before and after the breakpoint and generate an interpolation sequence. Simultaneously, the deviation between the instantaneous rate of change and the interpolation trend is calculated. If the deviation exceeds 5%, it is marked as an interpolation deviation point; if the rate mutation exceeds 20% of the normal value, it is marked as a rate anomaly point. Both are merged into a potential anomaly dataset.

[0032] In another embodiment, assuming five data breakpoints are identified during the monitoring period, three of these breakpoints are accompanied by consecutive handshake failure response codes (6 times in total) and link break markers (4 times each) in the communication log, and are thus identified as channel jitter segments. Linear interpolation is performed within these segments, generating an average of five trend-derived values ​​per segment. Nine of these points have a deviation greater than 5%, and eleven points have rate mutation values ​​exceeding ±20%. These two types of anomalies account for 4.4% of the total sample and are included in the potential anomaly dataset for subsequent anomaly triggering strategy matching.

[0033] Step S3: Determine the anomaly identification conditions using the potential anomaly dataset; while continuously receiving energy data on the cloud platform, when the anomaly identification conditions are met, automatically call the linear interpolation instruction to generate a cleaning processing log and update the data status label;

[0034] In one embodiment, the system extracts indicators such as mean square deviation, rate change range, and interpolation residual based on the statistical characteristics of the potential anomaly dataset to construct anomaly identification conditions. When newly received energy data meets any of the condition thresholds, the cloud platform automatically invokes the interpolation cleaning module to perform linear repair in real time and records the cleaning process log. Simultaneously, the system updates the status labels of the data for the corresponding time period, such as "interpolated and repaired" or "high-risk segment," achieving transparent management of the cleaning process and traceability of anomaly data.

[0035] In another embodiment, assume the set anomaly triggering conditions include: 1) interpolation deviation > 5%; 2) rate change > ±25%; 3) residual variance > threshold σ = 0.02. During a monitoring process, if 7 new data entries simultaneously meet conditions 1 and 2, the system immediately triggers an interpolation command to fill in the missing data and generates 7 corresponding cleaning log records. The logs contain the interpolation time period, repair method, residual processing details, and repair status code. Simultaneously, the data tags for these 7 records are updated to "cleaned" for subsequent identification and analysis.

[0036] Of particular importance, step S3 includes the following steps:

[0037] Step S31: Extract the timestamps of interpolation deviation points and rate anomaly points from the potential anomaly dataset, and construct an anomaly triggering window;

[0038] In one embodiment, the system first performs interpolation residual analysis and rate fluctuation analysis on historical energy data received from the cloud. Interpolation deviations are identified by comparing the differences between observed and interpolated predicted values, while rate anomalies are determined by detecting whether the rate of change of values ​​at adjacent time points exceeds a set threshold. The system extracts the timestamps of all identified anomalies and constructs a sliding time window with a width of three times the sampling period, centered on each time point. All windows containing at least one anomaly are recorded as anomaly trigger windows for subsequent frequency determination.

[0039] In another embodiment, assuming the system collects 1440 energy data points daily, analysis reveals 160 interpolation deviations and 130 rate anomalies, resulting in a total of 280 anomalies after deduplication. Setting the sliding window width to 3 minutes and the step size to 1 minute, statistics show that 510 windows contain anomalies, forming a preliminary set of anomaly trigger windows.

[0040] Step S32: Calculate the frequency of the abnormal trigger window. If the frequency exceeds 30% of the total number of sampling periods, it is marked as a high-frequency abnormal period.

[0041] In one embodiment, the system calculates the frequency of all sliding windows. The number of abnormal trigger windows is compared to the total number of windows. If the proportion of abnormal windows exceeds 30%, the time period is marked as a "high-frequency abnormal period." This period is considered an abnormal segment with concentrated data fluctuations and requires further processing in the cleaning strategy. The system also records the start and end times of this period and the number of abnormal points.

[0042] In another embodiment, assuming a total of 1400 sliding windows and 520 abnormal trigger windows, accounting for approximately 37%, this period is marked as a high-frequency abnormal period because it exceeds the set threshold of 30%. The abnormal points are mainly concentrated between 2:00 AM and 5:00 AM on the same day, affecting a total of approximately 400 data points.

[0043] Step S33: Collect the interpolation residual amplitude during high-frequency abnormal periods as an anomaly identification condition. When the anomaly identification condition is met while continuously receiving energy data on the cloud platform, the linear interpolation instruction is automatically invoked to generate a cleaning processing log and update the data status label.

[0044] In one embodiment, for the aforementioned high-frequency abnormal period, the system collects residual data between all interpolated data and actual observed values ​​within that segment. After statistical analysis, the range of residual variation is obtained, and the system sets the characteristic range of the residual as the identification condition for real-time data cleaning. When the cloud platform receives new data, it calculates the residual between the new data and the interpolated predicted value in real time. If the residual is found to exceed the set range, a linear interpolation operation is automatically triggered for correction. Simultaneously, a cleaning processing log containing information such as time, data point number, triggering rules, and cleaning method is generated, and the data status label is updated from "raw" to "cleaned".

[0045] In another embodiment, assuming the residual values ​​obtained from sampling high-frequency anomaly segments vary between 1.0 and 5.0, the anomaly identification threshold is set to 4.0. Subsequently, when the cloud platform receives new data, if the predicted value of a certain data point is 10.5 and the actual value is 6.2, its residual is 4.3, exceeding the threshold of 4.0. Therefore, linear interpolation is automatically performed, and the cleaning time is recorded in the log as "2025-08-05 13:45:00", changing the data status from "raw" to "cleaned".

[0046] Step S4: Identify residual data using data status tags and cleaning processing logs; use the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

[0047] In one embodiment, the system locates the corresponding cache rollback area based on the "rollback" or "high-risk uncleaned" marker in the data status label and counts the number of cache rollbacks. If the number of rollbacks exceeds a set threshold (e.g., 3 times), the system extracts the interfering data frames in that area and further identifies residual data by combining them with the cleaning logs. Subsequently, the residual data is reconstructed using adjacent normal data and interpolation trends to correct the device operating parameters and improve the consistency and integrity of the overall dataset.

[0048] In another embodiment, suppose there are two cache rollback segments marked in the data status label: segments 200–210 (11 frames in total) and 430–437 (8 frames in total), where the number of cache rollbacks detected are 4 and 5 respectively, both exceeding the set rollback threshold of 3 times. The system retrieves the cleaning log and finds that segment 200–210 underwent one interpolation repair, but two abnormal residual data points remained unprocessed. Finally, the system corrected this segment again, and after correction, the mean squared error was reduced to 35% of the original value, significantly improving data availability.

[0049] Preferably, in step S1, the periodic synchronous monitoring and collection of the distributed energy terminal's power generation, load power, and network connection status parameters to generate equipment operating parameters includes:

[0050] By deploying a power measurement device on the power supply side of a distributed energy terminal, the voltage and current signals of the inverter output side are synchronously collected at a frequency of 0.5Hz-2Hz, and the power generation is calculated.

[0051] In one embodiment, the system deploys voltage and current sensors at the inverter output of the distributed energy terminal and synchronously collects real-time voltage and current data at a sampling frequency of 1Hz via an edge computing module. The measuring device has data preprocessing capabilities, enabling simple filtering of abnormal current surges during data acquisition to ensure stable and reliable calculation results. The collected data is transmitted in real time to a local data cache center for further power generation calculations and time-series analysis.

[0052] In another embodiment, the acquisition device synchronizes data at a frequency of 0.5Hz, and the three sets of continuous voltage values ​​measured are [228V, 229V, 227V], corresponding to current values ​​of [3.1A, 3.0A, 3.2A]. After simple noise reduction processing in the local computing unit, the system estimates the power generation for this cycle to be approximately 706W. This value will serve as a basic power generation performance indicator and participate in the construction of equipment operating status parameters.

[0053] By using an electrical parameter acquisition device installed at the load end, the voltage, current and power factor information of the load end are collected, and the load power is calculated.

[0054] In one embodiment, a three-phase intelligent electrical parameter acquisition device is installed on the user load side to collect the voltage, current, and power factor of each phase in real time. The device samples twice per second and uses embedded filtering logic to remove short-term noise. The acquisition device uploads the data for each cycle to the gateway node and performs local load power calculation, ensuring short response time and accurate power data, which is beneficial for real-time analysis of dynamic supply and demand balance.

[0055] In another embodiment, the sampling frequency is set to 2Hz, and the voltage [231V, 230V], current [4.6A, 4.5A], and power factor [0.94, 0.95] are obtained in one sampling period. After calculation, the system obtains a load power of approximately 980W, which is used as the load demand level for this period of time and input into the subsequent model to monitor the operating efficiency and energy rationality of the equipment.

[0056] Based on the network connection status parameters of the current wireless access point, a sliding window consistency check is performed on the network latency and packet loss rate collected periodically within 0.4s–0.6s to eliminate abnormal data caused by instantaneous fluctuations.

[0057] In one embodiment, the system continuously monitors the stability of the wireless communication network, collecting continuous network status information centered on the wireless access point, including latency and packet loss rate. A sliding window mechanism with a duration of 0.5 seconds is used to assess the consistency of network data sampled at a frequency of 5Hz. A median filtering algorithm effectively filters out extreme outliers caused by transient signal degradation, ensuring the continuity and reliability of network status assessment.

[0058] In another embodiment, network status sampling lasts for 0.6 seconds, with collected latency of [35ms, 150ms, 40ms, 36ms, 34ms] and packet loss rate of [0.1%, 5.3%, 0.1%, 0.2%, 0.1%]. After sliding window consistency verification, the second group of data is identified as abnormal and removed. The remaining data is considered as valid communication status under stable network conditions. This stable status label will directly participate in the encapsulation and cleaning strategy judgment of subsequent device operating parameters.

[0059] Power generation, load power, and network connection status parameters are aligned by timestamps and encapsulated into equipment operating parameters.

[0060] In one embodiment, the system performs unified timestamp alignment on the collected power generation, load power, and network status parameters. After each data point is corrected to a unified clock reference using a time synchronization protocol (such as NTP), alignment matching is performed according to a nearest neighbor strategy, and the data is encapsulated in a fixed-structure operating parameter vector. This operating parameter vector is sent in real-time to the cloud platform's data processing module to support equipment status assessment, trend prediction, and anomaly early warning.

[0061] In another embodiment, it is assumed that the data acquisition system obtains the following data at a certain moment: power generation of 700W, load power of 950W, network latency of 35ms, and packet loss rate of 0.1%. The system encapsulates these data into a structured operation parameter object in a standard format, along with a unified timestamp for that moment. This object is used for batch calculations and model input in the cloud, ultimately supporting the optimized execution of distributed energy operation strategies.

[0062] Preferably, the data breakpoints identified in the device operating parameters in step S1 include:

[0063] Extract the time series continuity index of power generation and load power of the equipment operating parameters within the most recent 270s-330s;

[0064] In one embodiment, the system retrieves power generation and load power data recorded in the cloud platform and sets a 300-second time window, backtracking 270 seconds from the current moment to extract sampling records for continuous time segments. The system verifies the validity of each sampling point within this time period and records the timestamp, whether it is missing, and the legality of the value range for each parameter. It then calculates continuity indicators for the time series, such as data integrity rate and average sampling interval, as a basis for subsequent judgments on data integrity and stability.

[0065] In another embodiment, assuming a sampling period of 2 seconds, ideally 30 records should be collected within a 60-second window. The system found 26 actual records in the power generation data, with 4 missing, resulting in a continuity index of 86.7%; and 28 records in the load power data, with 2 missing, resulting in a continuity index of 93.3%. This continuity index will serve as an important reference for determining whether subsequent data has gaps or abnormal interruptions.

[0066] The difference between the timestamps of two adjacent operating parameters in the time series continuity index is calculated. If there are records with a time interval greater than 1.5 times the sampling period, they are marked as data breakpoints.

[0067] In one embodiment, the system performs a timestamp-based analysis on the power generation and load power data extracted in step 1, calculating the time interval for each group of adjacent records. The system pre-sets a sampling period tolerance range, for example, 1.5 times the normal period. When the interval between two sampling points is detected to exceed this range, the current time point is marked as an anomaly and recorded as a data breakpoint. The entire process is completed locally by the edge computing node, and the anomaly log is synchronized to the cloud.

[0068] In another embodiment, assuming the system sampling period is set to 2 seconds, the maximum allowed interval is 3 seconds. After calculating the power generation sequence, it was found that the interval between records 12 and 13 was 5 seconds, and between records 22 and 23 was 4 seconds, both exceeding the set threshold. Therefore, these two positions were marked as data breakpoints by the system. No intervals exceeding the threshold were found in the load power data, indicating that the sequence continuity was normal.

[0069] Preferably, step S2 includes the following steps:

[0070] Step S21: Read the connection disconnection flag from the data breakpoint; extract the handshake failure response code of the connection disconnection flag;

[0071] In one embodiment, after detecting a data breakpoint, the system first retrieves the connection event log corresponding to that time period from the underlying communication protocol stack, including TCP connection status, handshake process records, and failure response codes. The system identifies connection disconnection flags, such as FIN, RST packets, or broken MQTT heartbeats, and further extracts handshake failure response codes, such as TLS handshake failure codes (e.g., 0x15), TCP SYN no response, and authentication failure codes (e.g., 0x84). This information is cached for subsequent determination of the breakpoint type.

[0072] In another embodiment, suppose a distributed energy device experiences three data interruptions between 8:00 and 8:05. The system reads the communication module logs and finds two TCP SYN-ACK timeouts (response code 0x01) and one TLS handshake failure (response code 0x15). Since all three instances recorded connection disconnections, they are identified as potential communication channel anomalies.

[0073] Step S22: Periodically sample the connection disconnection flag and calculate the disconnection frequency to evaluate link stability; if the link stability is lower than the stability threshold and is accompanied by multiple handshake failure response codes, it is determined to be a channel jitter data breakpoint.

[0074] In one embodiment, the system polls and samples the connection status log every 10 seconds and counts the number of connection disconnection events within a sampling period. The system presets a stability threshold (e.g., average disconnection frequency ≤ 1 time / minute). If the frequency of such events is too high within a consecutive sampling period, and the event contains at least two different types of handshake failure response codes (e.g., SYN timeout + TLS failure), the data breakpoint is further marked as a channel jitter type, and a network anomaly reporting mechanism is triggered.

[0075] In another embodiment, the sampling period was set to 10 seconds, and 30 samples were taken within a 5-minute window. The system found that connection break events were recorded in 6 of these sampling periods, with an average break frequency of 1.2 times / minute, exceeding the preset threshold. Furthermore, the handshake failure response code contained three different types (0x01, 0x15, 0x84), and the system determined that the data breakpoint was a "channel jitter data breakpoint".

[0076] Step S23: Determine the linear interpolation command based on the channel jitter data breakpoint;

[0077] In one embodiment, when a data breakpoint is determined to be channel jitter-related, the system initiates a data compensation mechanism. The interval between the breakpoint and the corresponding device operating parameters is calculated. and parameter difference And issue a linear interpolation instruction: divide the breakpoint interval into equal parts. Each segment has a complement value of [value]. This command is passed to the local compute node or the historical data repair module.

[0078] In another embodiment, a photovoltaic inverter device experiences a data breakpoint during the sampling interval from 10:00 to 10:01. The active power before and after the breakpoint is 380W and 420W, respectively, with a difference of [missing information]. Time interval The system automatically divides the interval into four equal segments (with values ​​added every 5 seconds) and generates interpolation instructions: inserting 390W, 400W, 410W, and 420W respectively to maintain trend smoothness.

[0079] Step S24: Use linear interpolation instructions to identify missing data items in the interval of interruption points of equipment operating parameters and generate trend derived values. If the trend derived value deviates from the maximum allowable residual by more than 5%, it is marked as an interpolation deviation point.

[0080] In one embodiment, the system calculates each expected value (i.e., trend-derived value) for the interval of the interruption point according to the interpolation instruction, and then compares it with the subsequent actual sampled value. If there is a deviation between the interpolated predicted value and the subsequent sampled value that exceeds the maximum allowable residual (set to 5% by the system), the interpolation point is marked as an "interpolation deviation point" and submitted to the data quality control module for processing as a potential outlier.

[0081] In another embodiment, a device inserts values ​​of [390W, 400W, 410W, 420W] into the breakpoint interval. The actual recovered sampled value is [388W, 407W, 395W, 419W]. Therefore, the deviation at point 3 is |410–395| / 410 = 3.66%, which is less than 5%. However, if a point is recorded as 385W, the deviation is 25W, with a relative error of 6.1%. This point is then marked as an interpolation deviation point.

[0082] Step S25: Calculate the instantaneous rate of change of the equipment operating parameters. If the instantaneous rate of change exceeds 20% of the preset speed average, it is marked as a rate anomaly point. Merge the rate anomaly points and interpolation deviation points to generate a potential anomaly dataset.

[0083] In one embodiment, the system calculates the rate of change of the device operating parameters within each sampling period, i.e. and the preset speed average Compare them. If If a rate anomaly is detected, it is marked as a rate anomaly. Subsequently, this type of rate anomaly is combined with the interpolation deviation point in step S24 to generate a complete "potential anomaly dataset", which is used to train the anomaly recognition model or trigger the alarm system.

[0084] In another embodiment, it is assumed that the system has a preset normal rate of change in photovoltaic power. The difference between two sampling points is 45W, with an interval of 20 seconds. The relative difference was 50%, exceeding the threshold. This point was marked as a rate anomaly. It also appeared in the interpolation deviation list and was therefore merged into the potential anomaly dataset. Ultimately, this dataset contained 5 anomaly records, which were used as input for subsequent models.

[0085] Preferably, the step S23 of determining the linear interpolation instruction based on the channel jitter data breakpoint includes:

[0086] Calculate the standard deviation of the receiving interval between adjacent data frames in the channel jitter data breakpoint. When the standard deviation of the receiving interval exceeds the jitter threshold by 20μs within 64 consecutive minimum data units, it is determined to be an abnormal channel jitter interval.

[0087] In one embodiment, the system continuously records the reception timestamp of each data frame, analyzes the 64 consecutive smallest data units within the current time window, calculates the reception time interval (in microseconds) between adjacent data frames, and then calculates the standard deviation of these time intervals. The system sets a jitter threshold of 20 μs. Exceeding this threshold, i.e. The system marks this time window as an "abnormal channel jitter interval" and triggers a subsequent data integrity check mechanism.

[0088] In another embodiment, suppose a device continuously receives 64 data frames within a certain time period. After calculating the reception interval between adjacent frames, the average interval is found to be 100 μs, with a standard deviation of 27 μs. Since this standard deviation is greater than a set threshold of 20 μs, this 64-frame interval is identified as an abnormal channel jitter interval. In contrast, the standard deviation of 64 frames within another window is only 13 μs, so no abnormality detection is triggered.

[0089] Read the buffer queue in the channel jitter abnormal interval frame by frame; calculate the buffer write rate of the buffer queue; calculate the buffer read rate of the buffer queue; if the buffer write rate is higher than the read rate and the buffer queue occupancy rate is consistently higher than 90%, it is determined to be a buffer overflow block.

[0090] In one embodiment, after identifying an abnormal channel jitter interval, the system calls the buffer information of the underlying communication module and reads the buffer status frame by frame in chronological order. During each frame recording, the system statistically analyzes the write rate (unit: frames / second) and read rate, and calculates the real-time occupancy rate of the buffer queue (currently occupied bytes ÷ total capacity). If, for multiple consecutive sampling periods, the write rate consistently exceeds the read rate, and the queue occupancy rate continuously exceeds 90%, the system classifies this segment of buffered data as a "buffer overflow block," indicating a risk of latency or blocking.

[0091] In another embodiment, assuming the maximum capacity of the cache queue is 1000KB, within a certain detection period: the cache write rate is 180 frames / second; the cache read rate is 150 frames / second; the current cache occupancy is 920KB, with an occupancy rate of 92%. If this state persists for more than 3 consecutive sampling periods (e.g., 100ms per period), the data segment is determined to be a cache overflow block. This state indicates a processing bottleneck, possibly caused by a sudden increase in upstream data or excessive downstream computational load.

[0092] Assign linear interpolation instructions to the buffer overflow block.

[0093] In one embodiment, for a data block identified as having a buffer overflow, the system initiates an interpolation compensation process. Based on the number of missing frames in the data block and the data characteristics of adjacent frames (such as timestamps, device parameter values, etc.), a linear interpolation instruction is generated. This interpolation process follows the minimum mean square error principle, distributing the missing frames at equal time intervals and filling in reasonably trending intermediate values. The interpolation instruction is then sent to the data restoration module for recovery processing and marked with an interpolation tag.

[0094] In another embodiment, a buffer overflow block is missing 4 frames of data, and the timestamps of the preceding and following boundary frames are... ms and ms, power values ​​are 320W and 400W. Based on this, the system calculates the interpolation interval per frame as follows: Interpolation increment W. The final linear interpolation instruction is generated, and the inserted frame data is: ms: 336W; ms: 352W; ms: 368W; ms: 384W; The interpolation frame will be used to maintain data smoothness and avoid amplification of downstream modeling errors due to abrupt changes.

[0095] Preferably, the data interpolation instructions for allocating cache overflow blocks include:

[0096] If a data frame with a retransmission flag exists in the cache overflow block, it is marked as a frame with missing data integrity; if a data frame with a timestamp rollback error exists in the cache overflow block, it is marked as a frame with inconsistent timing.

[0097] In one embodiment, the system performs integrity and timing analysis on each frame of data in the buffer overflow block. First, it checks for the presence of a retransmission flag field (such as an abnormal TCP sequence number or a duplicate frame flag). If this flag is found, it indicates that the frame may have undergone retransmission or packet loss retransmission, and the frame is marked as a "data integrity missing frame." Next, it parses the timestamp of each frame and constructs a timing sequence. If a frame's timestamp is found to be earlier than the previous frame, it is determined that there is a "timestamp rollback anomaly," and the frame is marked as a "timing inconsistency frame." These two flags together constitute a data quality identification mechanism, used to distinguish the source of anomalies and provide a basis for interpolation correction.

[0098] In another embodiment, suppose the buffer overflow data block contains 128 frames, of which 3 frames have sequence numbers that duplicate those of already received frames and are marked as "data integrity missing frames"; another 2 frames have timestamps of t=1020ms and t=1015ms respectively, appearing after t=1030ms, constituting a time backtracking, and are marked as "timing inconsistency frames". Therefore, this data block contains a total of 5 abnormal frames. Different interpolation strategies will be applied to these two types of abnormal frames to ensure data recovery quality.

[0099] Linear interpolation is performed on frames with missing data integrity to determine the linear index; the time axis of frames with inconsistent timing is reconstructed to determine the timing nodes; and data interpolation instructions are generated using the linear index and timing nodes.

[0100] In one embodiment, for a "frame with missing data integrity," the system selects two valid data points before and after the frame and estimates its data value using linear interpolation. For example, if the time of the preceding frame A is t1 and its value is v1, and the time of the following frame B is t2 and its value is v2, and the missing frame is at tx, then the linear index α = (tx – t1) / (t2 – t1) is calculated, and vx = v1 + α·(v2 – v1) is interpolated. For a "frame with inconsistent timing," the system reconstructs its theoretical time point based on the timeline of adjacent normal frames and corrects its timestamp accordingly, generating a time remapping node. The interpolation instruction set includes interpolation position, indexing method (linear / time correction), target field, interpolation result, etc., and finally generates complete interpolation instructions for data completion.

[0101] In another embodiment, it is assumed that in a data segment, the missing frame is located in time. ms, the preceding and following adjacent frames are: Frame A: ms, W; Frame B: ms, W; Linear Index The interpolation result is: Meanwhile, the original time of a "timing inconsistency frame" was t=2150ms, and the system detected that it should be located at... and Between these points, the theoretical timeframe is determined based on content trends. ms, update its timestamp to this value.

[0102] Preferably, linear interpolation of frames with missing data integrity includes:

[0103] If the number of missing data integrity frames is less than the preset missing threshold, record the start and end timestamps of the missing frames and calculate the linear rate of change; fill in the missing data of the missing data integrity frames one by one according to the linear rate of change to obtain linear interpolated data;

[0104] In one embodiment, when collecting operating parameters of distributed energy terminals, such as power generation, load power, and network status, the system automatically performs data integrity checks. When a missing frame is detected in a data channel, and the number of missing frames is less than a set missing frame threshold (e.g., 5 frames), the system immediately records the start and end timestamps of the missing frame segment. Subsequently, the valid values ​​at both ends of the missing segment are extracted, and the rate of change of the values ​​that should be present at each missing moment is calculated based on the trend of change between the two points. The missing frame data is then filled in accordingly, ultimately generating a continuous and smooth linear interpolated data sequence. This method is fast and suitable for repairing short-term, occasional frame loss scenarios.

[0105] In another embodiment, assuming the system collects energy data at a frequency of 10Hz, a data gap occurs between frames 320 and 324, totaling 4 frames, which is below the threshold of 5 frames. The system identifies the start time of the missing segment as 3200ms and the end time as 3250ms, with valid data values ​​of 82.5kW and 84.0kW at the two ends of the missing segment, respectively. Based on this, the system quickly fills in the missing values ​​and ultimately generates equally interpolated repair data, restoring the data sequence within that time period to a usable state.

[0106] If the number of missing data integrity frames exceeds the preset missing threshold, record the valid data points of the missing data integrity frames as spline interpolation nodes; perform cubic spline interpolation on the spline interpolation nodes to obtain spline interpolation data; fuse the linear interpolation data and the spline interpolation data to determine the linear index.

[0107] In one embodiment, when the system detects that the number of missing frames exceeds a set threshold, it determines that the data segment is not suitable for linear interpolation. The system iterates through all data records in the missing segment, extracts the remaining valid data points, including timestamps and corresponding values, and uses them as nodes for spline interpolation. Subsequently, the cubic spline interpolation module is activated, and by performing overall fitting on all nodes, the missing frame data is automatically filled in. The interpolation result has better curve continuity and smoothness, and can adapt to scenarios with large-scale or abrupt data loss.

[0108] In another embodiment, suppose that during a data synchronization, the system detects 12 missing frames between frames 700 and 720, exceeding the missing frame threshold of 5 frames. The system identifies 6 valid data points in this interval, located at frames 700, 703, 707, 711, 715, and 720. The system uses these valid points as interpolation nodes and fills in the missing frames using cubic spline fitting. After interpolation, the data sequence exhibits a natural and continuous curve change, making it particularly suitable for energy data completion tasks with slow fluctuations or periodic characteristics.

[0109] Preferably, the timeline for reconstructing time-inconsistent frames includes:

[0110] Extract the original timestamp sequence of frames with inconsistent timing;

[0111] In one embodiment, sampling frames with abnormal timestamps are extracted from a distributed energy system data stream collected from a cloud platform. First, the data stream contains sensor frames sampled at a frequency of 30Hz, each frame accompanied by a nanosecond-level timestamp. The system reads the timestamp sequence of all sampling frames within a specified time period from a database; the timestamp format is Unix timestamps (millisecond level). Then, the difference between each pair of adjacent frame timestamps is calculated, with an ideal interval of 33.33 milliseconds.

[0112] It's important to note that all timestamp differences are iterated through, with a timing consistency threshold set to ±5 milliseconds. This means that if the time difference between adjacent frames is greater than 38.33 milliseconds or less than 28.33 milliseconds, the frame is considered to have a timing inconsistency. The system marks all frames meeting this condition as "timing-inconsistent frames," extracts their original timestamps frame by frame, and forms a complete timestamp sequence containing the anomalous frames. This sequence serves as the foundational data for subsequent processing and is stored in a temporary buffer for use in the next step.

[0113] Calculate the equal-interval deviation of the original timestamp sequence;

[0114] In one embodiment, based on the extracted original timestamp sequence of time-inconsistent frames, the deviation between the actual interval and the theoretical sampling interval for each pair of consecutive timestamps is calculated. The theoretical sampling interval is calculated to be 33.33 milliseconds based on a fixed system sampling frequency of 30Hz. The difference between adjacent timestamps is calculated sequentially for the extracted timestamp sequence. And based on the theoretical interval of 33.33 milliseconds, the deviation for each interval was calculated. millisecond.

[0115] All deviations The data is stored in an array. Statistical analysis is performed on the array to calculate the mean and standard deviation of the deviation. The mean deviation represents the overall degree of deviation, while the standard deviation reflects the stability of the intervals. Extreme deviation values ​​(outliers exceeding the mean ± 3 times the standard deviation) are removed. This step ensures that the deviation data accurately reflects the patterns of inconsistencies in the time series, providing an accurate reference for timeline reconstruction.

[0116] The time axis of the time-inconsistent frames is reconstructed using equal-interval deviations to determine the timing nodes.

[0117] In one embodiment, the reconstruction method employs fixed-time interval resampling. Starting with the first timestamp in the extracted sequence, an ideal timestamp sequence is generated by incrementing at fixed 33.33 millisecond intervals. The system then maps the original sampled frames to this ideal timeline using linear interpolation.

[0118] It is important to note that during mapping, for the first... Frame, let its original timestamp be Reconstruct the timestamp as Calculate the time offset .in accordance with Adjust the timestamps of the corresponding sampled data to maintain the uniform time order and intervals of the sampled data. After reconstruction, the system verifies the continuity of the reconstructed timestamp sequence, ensuring that the time interval between all adjacent frames is 33.33 milliseconds, with an allowable error within ±0.5 milliseconds. Finally, the reconstructed timestamp sequence is written to the database or cache for subsequent use by the time-series synchronization and data fusion modules.

[0119] Preferably, step S4, which uses data status tags and cleaning processing logs to identify residual data, includes:

[0120] Read the cache rollback label in the data status label, and use the cache rollback label to locate the cache queue rollback segment; calculate the cache rollback number of the cache queue rollback segment, and if the cache rollback number is greater than the preset rollback threshold, extract the cache interference data frame;

[0121] In one embodiment, the status label of each collected data frame is read from the cloud platform database. This status label includes a "cache rollback" field. The status labels are stored in a structured format, with each label containing a timestamp, data frame identifier, and cache status. The cache rollback label field indicates whether the frame triggered a cache rollback event as a Boolean value. The system sequentially scans the status labels of all data frames within a specified time interval and marks frames with a cache rollback label value of "true".

[0122] Based on the continuous distribution of cached rollback tags, rollback segments in the cache queue are identified. A continuous set of cached rollback frames is considered a rollback segment, with its start and end frames determined by the first and last cached rollback tag frames within that segment. The specific location method involves traversing the cached rollback tag sequence, counting consecutive "true" tag frames, and identifying the breakpoints as rollback segment boundaries. This method ensures accurate capture of the complete time period of rollback events, supporting subsequent rollback count statistics and anomaly data analysis.

[0123] It is important to note that the cleaning log is indexed by timestamps and records detailed event information for all monitoring and cleaning operations. The system retrieves all log entries within the corresponding time period from the log database by caching the start and end timestamps of the interfering data frames.

[0124] The search criteria are limited to log timestamps within the time range of cached interference data frames and log categories of "data cleaning" or "anomaly handling". This process is completed through the log management module, using a time range query interface to efficiently locate log records. The location result is the cleaning processing area, covering all cleaning operation records related to cache rollback, for subsequent analysis by the residual data identification module.

[0125] Of particular importance is the use of cache rollback tags to locate cache queue rollback segments, including:

[0126] The write pointer state is read using the cache rollback tag; based on the write pointer state, the starting frame position in the cache queue is located by backtracking, and the ending frame position of the rollback repair is found by searching backward, forming a cache queue rollback segment.

[0127] In one embodiment, the write pointer status is continuously tracked on the cloud platform side to accurately analyze the cache fragments corresponding to the cache rollback tags. During implementation, firstly, based on the periodically uploaded data status tag information, the flag bit marked as "rollback status" is identified. This tag field uses a binary mask to indicate write failure or retry status; for example, a flag bit set to "0x08" represents a cache rollback event. Based on this, the cloud platform reads the write pointer status information at the corresponding time point by parsing the timestamp sequence and sequence index field corresponding to the tag. This information is the address offset in the cache queue and is recorded in the cache metadata table.

[0128] Based on the write pointer status information, it is necessary to backtrack to find the starting frame position in the buffer queue. This frame position is the first data frame affected by the rollback operation, and its identifier is determined by looking back at the address of the first normally written frame from the current write pointer value. The criteria are: the memory address corresponding to the write pointer does not contain any "retry count" flag or "rollback flag," and the data integrity check result corresponding to that address is successful (e.g., CRC check result is 1). Subsequently, the buffer queue is scanned sequentially from this starting frame to find the position of the first frame that was rewritten; this position is the end frame position of the rollback repair. This end frame typically meets two conditions: its write pointer position increases continuously, and the rollback flag in its data status label is cleared to "0." All frame addresses between the starting frame and the end frame constitute the buffer queue rollback segment.

[0129] It is important to note that an index matching algorithm and pointer range comparison mechanism are employed, combining the timestamp field (accurately recorded in seconds, standard format Unix timestamp) and frame sequence number field (continuously incrementing frame number in integer unit) of each data frame to achieve accurate segmentation and identification of cached rollback segments. All related operations are performed in the cloud database by retrieving original records and status fields using SQL statements, and are recorded in the cleaning and processing log table for subsequent steps to identify residual data. This log table will contain fields such as the start and end addresses of the rollback segment, the corresponding timestamp range, the number of affected frames, and the write pointer status change trajectory, used to assist in subsequent data cleaning and correction tasks.

[0130] The cleaning processing area of ​​the cleaning processing log is located based on the cached interference data frame; residual data is identified in the cleaning processing area.

[0131] In one embodiment, residual data entries are identified in the logs of the located cleaning processing area. Residual data is defined as collected data that was not completely removed or still contains anomaly markers during the cache rollback cleaning process. The identification step first parses each operation record in the cleaning processing log, extracting the data status fields before and after cleaning, data integrity markers, and anomaly markers.

[0132] For log records where the cleaning result status remains unchanged or where anomaly markers persist, the corresponding data frames are marked as residual data. During the identification process, a residual judgment threshold is set when the data integrity index is below 90% and the anomaly marker frequency exceeds 3 times. This threshold is based on historical data analysis and monitoring system settings. The system aggregates the timestamps and markers of all residual data frames to generate a residual data list. The list is stored in a cloud database, supporting subsequent manual intervention or automatic re-inspection operations.

[0133] This specification also provides a cloud-based distributed energy data monitoring and cleaning system for performing the cloud-based distributed energy data monitoring and cleaning method described above. The cloud-based distributed energy data monitoring and cleaning system includes:

[0134] The data acquisition module 101 is used to periodically and synchronously monitor and collect the power generation, load power and network connection status parameters of the distributed energy terminal to generate equipment operating parameters and identify data breakpoints in the equipment operating parameters.

[0135] The instruction generation module 102 is used to determine the linear interpolation instruction based on the network communication status in the data breakpoint, and to use the data interpolation instruction to filter potential abnormal datasets of device operating parameters.

[0136] The cleaning log generation module 103 is used to determine the anomaly identification conditions using the potential anomaly dataset; when the anomaly identification conditions are met while continuously receiving energy data on the cloud platform, the linear interpolation instruction is automatically invoked to generate the cleaning processing log and update the data status label.

[0137] The calibration data module 104 is used to identify residual data using data status tags and cleaning processing logs; and to use the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

[0138] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0139] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A cloud platform-based distributed energy data monitoring cleaning method, characterized in that, Includes the following steps: Step S1: Periodically and synchronously monitor and collect the power generation, load power, and network connection status parameters of the distributed energy terminal to generate equipment operating parameters; identify data breakpoints in the equipment operating parameters; Step S2: Determine the linear interpolation instruction based on the network communication status in the data breakpoint, and use the data interpolation instruction to filter potential abnormal datasets of equipment operating parameters; Step S3: Determine the anomaly identification conditions using the potential anomaly dataset; while continuously receiving energy data on the cloud platform, when the anomaly identification conditions are met, automatically call the linear interpolation instruction to generate a cleaning processing log and update the data status label; Step S4: Identify residual data using data status tags and cleaning processing logs; use the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

2. The cloud platform based distributed energy data monitoring cleaning method according to claim 1, wherein, In step S1, the periodic synchronous monitoring and collection of the distributed energy terminal's power generation, load power, and network connection status parameters to generate equipment operating parameters include: By deploying a power measurement device on the power supply side of a distributed energy terminal, the voltage and current signals of the inverter output side are synchronously collected at a frequency of 0.5Hz-2Hz, and the power generation is calculated. By using an electrical parameter acquisition device installed at the load end, the voltage, current and power factor information of the load end are collected, and the load power is calculated. Based on the network connection status parameters of the current wireless access point, a sliding window consistency check is performed on the network latency and packet loss rate collected periodically within 0.4s–0.6s to eliminate abnormal data caused by instantaneous fluctuations. Power generation, load power, and network connection status parameters are aligned by timestamps and encapsulated into equipment operating parameters.

3. The cloud platform based distributed energy data monitoring and cleaning method according to claim 1, wherein, The data breakpoints identified in the device operating parameters in step S1 include: Extract the time series continuity index of power generation and load power of the equipment operating parameters within the most recent 270s-330s; The difference between the timestamps of two adjacent operating parameters in the time series continuity index is calculated. If there are records with a time interval greater than 1.5 times the sampling period, they are marked as data breakpoints.

4. The cloud platform based distributed energy data monitoring and cleaning method according to claim 1, wherein, Step S2 includes the following steps: Step S21: Read the connection disconnection flag from the data breakpoint; extract the handshake failure response code of the connection disconnection flag; Step S22: Periodically sample the connection disconnection flag and calculate the disconnection frequency to evaluate link stability; if the link stability is lower than the stability threshold and is accompanied by multiple handshake failure response codes, it is determined to be a channel jitter data breakpoint. Step S23: Determine the linear interpolation command based on the channel jitter data breakpoint; Step S24: Use linear interpolation instructions to identify missing data items in the interval of interruption points of equipment operating parameters and generate trend derived values. If the trend derived value deviates from the maximum allowable residual by more than 5%, it is marked as an interpolation deviation point. Step S25: Calculate the instantaneous rate of change of the equipment operating parameters. If the instantaneous rate of change exceeds 20% of the preset speed average, it is marked as a rate anomaly point. Merge the rate anomaly points and interpolation deviation points to generate a potential anomaly dataset.

5. The cloud platform based distributed energy data monitoring and cleaning method according to claim 4, wherein, Step S23, which involves determining the linear interpolation instruction based on the channel jitter data breakpoint, includes: Calculate the standard deviation of the receiving interval between adjacent data frames in the channel jitter data breakpoint. When the standard deviation of the receiving interval exceeds the jitter threshold by 20μs within 64 consecutive minimum data units, it is determined to be an abnormal channel jitter interval. Read the buffer queue in the channel jitter abnormal interval frame by frame; calculate the buffer write rate of the buffer queue; calculate the buffer read rate of the buffer queue; if the buffer write rate is higher than the read rate and the buffer queue occupancy rate is consistently higher than 90%, it is determined to be a buffer overflow block. Assign linear interpolation instructions to the buffer overflow block.

6. The cloud platform based distributed energy data monitoring and cleaning method according to claim 5, wherein, The instructions for allocating data interpolation to cache overflow blocks include: If a data frame with a retransmission flag exists in the cache overflow block, it is marked as a frame with missing data integrity; if a data frame with a timestamp rollback error exists in the cache overflow block, it is marked as a frame with inconsistent timing. Linear interpolation is performed on frames with missing data integrity to determine the linear index; the time axis of frames with inconsistent timing is reconstructed to determine the timing nodes; and data interpolation instructions are generated using the linear index and timing nodes.

7. The cloud platform based distributed energy data monitoring and cleaning method according to claim 6, wherein, Linear interpolation of frames with missing data integrity includes: If the number of missing data integrity frames is less than the preset missing threshold, record the start and end timestamps of the missing frames and calculate the linear rate of change; fill in the missing data of the missing data integrity frames one by one according to the linear rate of change to obtain linear interpolated data; If the number of missing data integrity frames exceeds the preset missing threshold, record the valid data points of the missing data integrity frames as spline interpolation nodes; perform cubic spline interpolation on the spline interpolation nodes to obtain spline interpolation data; fuse the linear interpolation data and the spline interpolation data to determine the linear index.

8. The distributed energy data monitoring and cleaning method based on a cloud platform according to claim 6, characterized in that, The timeline for reconstructing the timing inconsistencies of the frames includes: Extract the original timestamp sequence of frames with inconsistent timing; Calculate the equal-interval deviation of the original timestamp sequence; The time axis of the time-inconsistent frames is reconstructed using equal-interval deviations to determine the timing nodes.

9. The distributed energy data monitoring and cleaning method based on a cloud platform according to claim 1, characterized in that, Step S4 involves identifying residual data using data status tags and cleaning logs, including: Read the cache rollback label in the data status label, and use the cache rollback label to locate the cache queue rollback segment; calculate the cache rollback number of the cache queue rollback segment, and if the cache rollback number is greater than the preset rollback threshold, extract the cache interference data frame; The cleaning processing area of ​​the cleaning processing log is located based on the cached interference data frame; residual data is identified in the cleaning processing area.

10. A distributed energy data monitoring and cleaning system based on a cloud platform, characterized in that, For executing the cloud-based distributed energy data monitoring and cleaning method as described in claim 1, the cloud-based distributed energy data monitoring and cleaning system comprises: The data acquisition module is used to periodically and synchronously monitor and collect the power generation, load power, and network connection status parameters of distributed energy terminals to generate equipment operating parameters and identify data breakpoints in the equipment operating parameters. The instruction generation module is used to determine linear interpolation instructions based on the network communication status in the data breakpoints, and to use the data interpolation instructions to filter potential abnormal datasets of device operating parameters. The cleaning log generation module is used to determine the anomaly identification conditions using the potential anomaly dataset. When the anomaly identification conditions are met while continuously receiving energy data on the cloud platform, the linear interpolation instruction is automatically invoked to generate cleaning processing logs and update the data status labels. The calibration data module is used to identify residual data using data status tags and cleaning processing logs; it uses the residual data to correct equipment operating parameters, thereby obtaining monitoring cleaning data.

Images