An Automatic Identification and Verification Method for Anomalies in Electricity Meter Reading Data

Abstract

This invention discloses an automatic identification and verification method for abnormal data in electricity meter reading, belonging to the field of power data quality governance technology. It marks abnormalities at the protocol layer by comparing protocol layer features, and extracts daily frozen energy readings, tariff values, remaining balances, number of electricity purchases, and power outage / once events from normal protocol layer data. This data is then used to determine a set of abnormalities at the business layer through business logic. A fault factor algorithm composed of singular value decomposition and linear regression is then used to cluster these abnormalities, grouping high-risk subsets. Next, equipment attributes are extracted, and similar records are retrieved from a fault case database. Self-inspection reports are obtained through meter reading commands to determine the fault type. Finally, an automated repair protocol is executed, and the repaired data is verified in real-time using a streaming computing framework. A genetic algorithm is used to optimize the verification rule coefficients. This invention achieves a shift from passive data quality governance to proactive closed-loop management, significantly improving the accuracy of abnormality identification and the efficiency of operation and maintenance response.

Description

Technical Field

[0001] This invention relates to the field of power data quality management technology, specifically a method for automatic identification and verification of anomalies in power meter reading data. Background Technology

[0002] With the rapid development of smart grids, electricity information collection systems have become a crucial cornerstone for ensuring the quality of electricity services and user experience. Their core function is to ensure the stability and accuracy of data collection, directly impacting electricity billing, user services, and grid operation decisions. However, facing an increasingly complex grid environment and a rapidly growing scale of collection equipment, traditional equipment maintenance models relying on periodic on-site inspections and manual intervention suffer from high resource consumption and slow response times. They struggle to adapt to dynamic changes and sudden anomalies in equipment operation, leading to delayed problem detection and affecting the continuity of data collection and the timeliness of business processing.

[0003] The core problems facing current technology are: on the one hand, the collected data is susceptible to communication interference or equipment failure during transmission, resulting in incomplete or incorrect data content. Existing systems lack an immediate verification mechanism for data quality, and abnormal data is often only discovered after business applications, leading to consequences such as billing errors. On the other hand, even if abnormal data is discovered, there is a lack of real-time analysis and feedback mechanisms, making it impossible to quickly locate the root cause of the fault and take targeted remedial measures, leaving data quality governance in a passive state for a long time. Summary of the Invention

[0004] The purpose of this invention is to provide an automatic identification and verification method for abnormal electricity meter reading data, which realizes intelligent governance of the entire chain of electricity meter reading data from abnormal identification and fault location to automatic repair and rule adaptation, and solves the problems of delayed abnormal detection, low efficiency of fault investigation, and passive and rigid data quality governance.

[0005] The objective of this invention can be achieved through the following technical solutions: This application provides a method for automatic identification and verification of abnormal electricity meter reading data, including the following steps: S1. Receive raw data frames sent by the acquisition terminal or electricity meter in real time, extract the frame start and end characters, frame length, frame checksum, sequence number, transmission direction bit and terminal address, determine whether the extracted features are consistent with the protocol requirements, and mark inconsistent data as protocol layer anomalies. S2. Extract daily frozen energy readings, tariff values, remaining amount, number of electricity purchases, and power outage / once events from the normal data at the protocol layer. Perform tariff missing item judgment, reading imbalance judgment, meter stop judgment, meter fly-away judgment, meter reverse judgment, remaining amount sudden change judgment, and timeliness and validity judgment of power outage / once events to obtain the abnormal data set at the business layer. S3. The fault factor algorithm composed of singular value decomposition and linear regression is used to perform cluster analysis on the abnormal data of the business layer, calculate the deviation between the cluster center of each type of anomaly and the historical fault mode threshold, and classify the data with deviation exceeding the specified range into a high-risk abnormal data subset. S4. Extract the equipment manufacturers, models, software and hardware versions and terminal addresses from the high-risk abnormal data subset, search for similar historical fault records in the fault case database, calculate the matching degree, and obtain the equipment self-inspection report by issuing a penetration meter reading command through the electricity information collection system. S5. Parse the terminal address, clock information, event counter and communication status word in the device self-test report, determine the specific fault type according to the protocol layer verification rules, and retrieve the corresponding repair protocol from the fault handling database; S6. Execute automated scripts through remote communication networks to send repair protocols to data acquisition terminals or electricity meters, including remote time synchronization, parameter correction, terminal restart, or event buffer clearing, and record the updated device status after repair.

[0006] S7. Use a streaming computing framework to perform real-time verification of the data re-collected by the repaired acquisition terminal or electricity meter. After confirming that the data quality has returned to normal, integrate the quality indicators into the power grid operation decision module, and use a genetic algorithm to perform regression verification and optimization of the verification rule coefficients.

[0007] The beneficial effects of this invention are as follows: By establishing a dual real-time verification mechanism that combines the specification layer and the business layer, the specification characteristics of the original data frame are compared in real time before the data is entered into the database. At the same time, multi-dimensional logical judgments are made on key business data such as daily frozen electricity values, rates, and remaining amounts. This fundamentally solves the problem of the lag in the discovery of abnormal data only after business application, realizes the quality control of the source of collected data, ensures that core businesses such as billing and settlement are no longer contaminated by erroneous data, and significantly improves the accuracy of data collection and the reliability of business systems. By integrating fault factor clustering analysis with fault case library retrieval and equipment self-inspection report parsing, this method first uses singular value decomposition and linear regression to automatically extract high-risk equipment groups from massive abnormal data, then matches historical fault cases using cosine similarity, and finally remotely obtains equipment self-inspection information to accurately locate the fault type. This approach breaks through the limitations of fault root cause location relying on manual experience and being inefficient, and realizes the automated jump from abnormal alarm to fault cause determination, greatly shortening the fault diagnosis time and enabling maintenance personnel to directly obtain a clear fault type and handling direction. By constructing a closed-loop governance process that includes automated repair, streaming real-time verification, and genetic algorithm self-optimization, the repair effect is immediately verified by streaming computing after the repair protocols such as time synchronization and parameter correction are remotely issued. The quality indicators are then fed back to the decision-making module. At the same time, the verification rule coefficients are dynamically optimized using a genetic algorithm. This solves the problem of data quality governance being passive and rigid in its response for a long time, forming a virtuous cycle of proactive repair, real-time verification, and adaptive optimization. This continuously improves the accuracy of anomaly identification and provides stable and reliable data support for the power grid operation decision-making module. Attached Figure Description

[0008] To better understand and implement this application, the technical solution is described in detail below with reference to the accompanying drawings.

[0009] Figure 1 This is a flowchart illustrating an automatic identification and verification method for abnormal electricity meter reading data provided in Embodiment 1 of this application. Detailed Implementation

[0010] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, exemplary embodiments will be described in detail below, examples of which are illustrated in the accompanying drawings. In the following description, when referring to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0011] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0012] The following detailed description of the specific implementation methods, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided in detail.

[0013] Example 1, please refer to Figure 1 This embodiment provides a method for automatic identification and verification of abnormal electricity meter reading data, including the following steps: S1. Receive raw data frames sent by the acquisition terminal or electricity meter in real time, extract the frame start and end symbols, frame length, frame checksum, sequence number, transmission direction bit and terminal address, determine whether the features are consistent with the protocol requirements, and mark inconsistent data as protocol layer anomalies. Further, step S1 specifically includes: S11. The raw data frames are continuously acquired through the interface of the acquisition terminal and the electricity meter and stored in the buffer. The frame start symbol and frame end symbol are extracted frame by frame to determine the boundary range of each frame, and the data frame segmentation is completed to obtain independent single frame data units. The step-by-step extraction of the frame start and end symbols includes: sequentially reading the byte stream from the buffer; setting the start symbol's identifier value to a fixed byte, such as hexadecimal 0x68 (commonly found in DL / T645, 1376.1, and other protocols); employing a state machine scanning mechanism to match the start symbol byte by byte: when a start symbol byte is read consecutively and the preceding byte is a frame interval or start position, the current byte is determined to be a valid frame start position. To prevent mismatches, the start symbol can be set to appear twice consecutively (e.g., 0x680x68) as a frame header identifier, according to the specific protocol definition; after determining the start symbol, reading the frame length field (usually 1 or 2 bytes, including checksum and user data length) from a fixed offset position after the start symbol; calculating the theoretical number of bytes in the entire frame based on the frame length field; and then scanning backwards from the start symbol position according to the theoretical length to find the frame end symbol. The end-of-frame marker is usually a fixed byte, such as hexadecimal 0x16. If the end-of-frame marker is found at the expected position, the frame boundary is confirmed to be complete. If the end-of-frame marker is not found, the search continues until an end-of-frame marker is encountered or the maximum frame length threshold (such as 1024 bytes) is exceeded, at which point the frame boundary is considered abnormal. For protocols with escaping handling (such as 698.45 which may escape specific bytes within the frame), escaping must be restored during the extraction process: when an escape flag byte (such as 0x1B) is scanned, the bytes following it are restored to their original data according to the escaping rules, and then it is determined whether it is an end-of-frame marker. Based on the positions of the start and end markers, a complete single-frame data unit is extracted from the buffer for subsequent parsing of fields such as frame length and checksum.

[0014] S12. Parse the frame length, frame checksum, sequence number, transmission direction bit and terminal address from a single frame data unit. If the frame length does not match the actual parsed length, mark it as a structural anomaly. If the frame checksum verification fails, mark it as an integrity anomaly. Obtain the preliminary anomaly judgment result. After acquiring an independent single-frame data unit, the frame length field is read according to the fixed offset position specified in the protocol. For example, in the 1376.1 protocol, the first byte after the start-of-frame symbol is the length L1, and the second byte is the length L2. These two bytes should be equal to the length of the user data area plus 8. The correctness of the frame structure is confirmed by comparing L1 and L2 and verifying whether the actual frame length matches. Subsequently, the frame checksum (CS) is extracted from the frame, usually located one byte before the end-of-frame symbol. The arithmetic sum of all bytes in the user data area (ignoring carry) is calculated and compared with CS. The S-value is compared to determine the integrity of the frame transmission. Next, the sequence number PSEQ is parsed. This field, typically located in the control field, identifies the correspondence between uplink and downlink messages and needs to be compared with the sequence number of the message sent by the master station. The transmission direction bit DIR is usually associated with a bit in the control field, with a value of 0 indicating a downlink message and 1 indicating an uplink message. The transmission direction is determined based on the DIR value. The terminal address is parsed from the address field. In the 1376.1 protocol, the terminal address is usually a 5-byte BCD code or hexadecimal number, which needs to be extracted and converted to a logical address. For the 698.45 protocol, the parsing positions of the header checksum (HCS) and frame checksum (FCS) are slightly different, but the parsing process is similar: first, the frame length L is read; then, the frame header is checked using the HCS; finally, the entire frame data is checked using the FCS. Simultaneously, fields such as service type and terminal logical address are parsed from the application layer protocol data unit. If any parsed field does not conform to the protocol standard (e.g., frame length mismatch, checksum error, inconsistent sequence number, invalid address, etc.), it is marked as a protocol layer anomaly.

[0015] Among them, CS is the frame checksum, located one byte before the end-of-frame marker, used to verify the integrity of frame transmission; DIR (Direction) is used to identify the transmission direction of the message; PSEQ (Packet Sequence) is used to identify the correspondence between uplink and downlink messages to prevent message loss or duplication. When the master station sends a message, it carries a sequence number, and the terminal sends back the same sequence number in the response message, thereby achieving matching of request and response; HCS (Header Check Sequence) is used to verify the integrity of the frame header; and FCS (Frame Check Sequence) is used to verify the integrity of the entire data frame.

[0016] When calculating the frame checksum (CS), the range of the user data area is determined according to the protocol definition: In the 1376.1 protocol, the user data area begins after the control field (including sequence number, transmission direction bits, etc.) and ends before the CS byte, excluding the CS itself. Then, each byte in the user data area is read sequentially, treated as an 8-bit unsigned integer, and an accumulation operation is performed. No carry is processed during accumulation; that is, only the lower 8 bits of the result are retained after each addition, equivalent to taking the modulo 256. For example, if the current accumulated sum is 0xFE, adding another byte 0x05 results in 0xFE + 0x05 = 0x103, and only the lower 8 bits of 0x03 are retained as the new accumulated value. After traversing all user data area bytes, the final 8-bit value is the calculated checksum. Finally, this calculated value is compared bit by bit with the CS byte stored at a fixed position in the frame: if the two are completely equal, the frame checksum is determined to be correct and the data integrity is passed; if they are not equal, it is marked as a frame checksum error and classified as a protocol layer anomaly. For the 698.45 protocol, the frame check CS uses the CRC-16 algorithm, which requires the generator polynomial to be used to calculate the entire frame data (except for the start character, end character and FCS itself), and the result is compared with the FCS field in the frame. The process is similar but the algorithm is different.

[0017] S13. Check whether the transmission direction bit and terminal address conform to the preset protocol standard. If they do not conform, mark them as compliance anomalies. Integrate all anomaly markers to generate anomaly data records and store them in the anomaly log library. Use support vector machine to perform pattern analysis on the anomaly data archive, extract the regular characteristics of anomaly occurrence, and determine the potential association patterns of anomaly data frames.

[0018] The transmission direction bit DIR of the preset protocol standard must be 0 or 1, where 0 represents a downlink message sent by the master station and 1 represents an uplink message sent by the terminal. If the DIR bit has other values, it is judged as a compliance abnormality. The terminal address must conform to the address format and range defined in the protocol. For example, in the 1376.1 protocol, the terminal address is a 5-byte BCD code. The address value cannot be all 0 or all F, and it must be registered in the system file. If the address is invalid or does not match the file, it is judged as a compliance abnormality. The method employs Support Vector Machines (SVM) to perform pattern analysis on archived anomaly data, extracting regular features of anomaly occurrences. This includes: extracting records marked as reduction layer anomalies from the anomaly log database; converting each record into a feature vector; and including discrete features (such as anomaly type encoding: frame length error 1, checksum error 2, sequence number mismatch 3, illegal transmission direction bit 4, invalid terminal address 5) and continuous features (such as converting the anomaly occurrence timestamp into periodic time features, terminal manufacturer encoding, reduction version number, hardware / software version number, cumulative device runtime, historical anomaly frequency, etc.). Numerical features are then normalized. The feature vector set is divided into training and testing sets. A SVM classification model is constructed using radial basis function (RBF) or linear kernel function. The optimal penalty and kernel parameters are found using a grid search method to maximize the model's classification accuracy on the testing set. After training, the distribution patterns of different anomaly categories in the high-dimensional feature space are analyzed using the support vectors and decision boundaries obtained from the SVM. For example, by observing the sample points corresponding to the support vectors, it was found that certain anomalies (such as checksum errors) exhibit a strong correlation with the feature dimensions of specific terminal manufacturers and protocol versions in the feature space. Further, feature weight ranking or recursive feature elimination methods were used to identify the feature dimensions that contribute most to the classification, such as time interval features or device batch features. Finally, based on the classification results and feature importance ranking output by the support vector machine, regular features of anomaly occurrences were extracted: for example, a certain type of terminal experiences concentrated transmission direction bit errors between 0:00 and 2:00 AM daily, or a batch of electricity meters shows a significantly increased probability of serial number mismatch after firmware version upgrades. These regular features can be used to predict future trends of similar anomalies and provide data support for equipment operation and maintenance strategies.

[0019] Specifically, by using real-time verification at the reduction layer and support vector machine pattern analysis, the problem of difficulty in quickly identifying reduction anomalies and mining patterns in the original data frames is solved, and the instant marking of frame structure, integrity and compliance anomalies and automatic extraction of potential association patterns are realized.

[0020] S2. Extract daily frozen energy readings, tariff values, remaining amount, number of electricity purchases, and power outage / once events from the normal data at the protocol layer. Perform tariff missing item judgment, reading imbalance judgment, meter stop judgment, meter fly-away judgment, meter reverse judgment, remaining amount sudden change judgment, and timeliness and validity judgment of power outage / once events to obtain the abnormal data set at the business layer. Furthermore, step S2 specifically includes: S21. Obtain daily frozen energy readings, tariff values, remaining amount, number of electricity purchases, and power outage / once events through the protocol layer interface, construct an initial dataset, and perform data integrity and format consistency cleaning to obtain a preliminarily cleaned dataset. The daily frozen energy consumption records include metering point identifier, freeze time, total positive active power reading, peak tariff rate reading, off-peak tariff rate reading, and valley tariff rate reading; the tariff value records include tariff number and corresponding time period; the remaining amount records include meter number, remaining amount value, and amount update time; the electricity purchase frequency records include meter number, purchase time, number of times before purchase, and number of times after purchase; the power outage / restoration event records include device address, power outage time, power restoration time, and reporting time. These records are then linked by device identifier and timestamp to form an initial dataset.

[0021] Perform integrity checks: For daily frozen electricity consumption records, check if the total value is not empty and not negative, and check if at least one of the four rate values ​​(peak, off-peak, and valley) is not empty. If the total value is empty or negative, or if all rate values ​​are empty, the record is considered incomplete and moved to the incomplete data log. For remaining amount records, check if the amount is not empty and is greater than or equal to zero, and check if the update time is not empty; otherwise, the record is considered incomplete. For electricity purchase count records, check if both the number of purchases before and after the purchase are not empty, and if the number of purchases after the purchase is not less than the number of purchases before the purchase; otherwise, the record is considered incomplete. For power outage / update event records, check if the device address is not empty, and check if the power outage time and power-on time are not both empty; otherwise, the record is considered incomplete. All incomplete records are not proceeded to subsequent steps.

[0022] For records that pass the integrity check, perform a format consistency check: The daily frozen energy reading field must be a numeric type with no more than 2 decimal places; the freeze time must be a 14-digit pure numeric string and conform to the year-month-day-hour-minute-second order; the remaining amount field must be a numeric type with a maximum of two decimal places, and the update time format must be the same as the freeze time; the number of electricity purchases must be an integer greater than or equal to 0, and the electricity purchase time format must be correct; for power outage and power-on events, if the outage and power-on times are not empty, they must be 14-digit numbers, and the outage time must not be later than the power-on time, and the reporting time must not be earlier than the outage time. If any field does not meet the above format requirements, it will be marked as a format abnormal record and moved to the format abnormal log.

[0023] Then, using the combination of the three fields of device identifier, data timestamp, and data type as a unique key, the remaining data is deduplicated. If there are multiple completely duplicate records, only the one with the earliest timestamp is retained. If there are records with different values ​​under the same unique key, the frequency of each value is counted, and the highest frequency value is taken. If the frequencies are the same, the group of records is marked as conflict records and stored separately in the conflict pending resolution table.

[0024] S22. Perform rate missing item detection on the cleaned data set, mark the data with missing or incomplete rate values ​​as a rate abnormal subset, and then analyze the reading imbalance problem in combination with the daily frozen energy reading. If the correspondence between the daily frozen energy reading and the rate value deviates from the preset threshold, it is determined to be an reading imbalance abnormality, and the reading abnormal subset is obtained. The process involves reading daily frozen energy consumption records one by one from the cleaned dataset, extracting five key fields: total daily frozen energy consumption, peak rate, off-peak rate, and valley rate. Then, based on the metering point identifier, the configured rate type for the user or meter is retrieved from the database. For example, residential users typically use three rates (peak, off-peak, and valley), while industrial and commercial users may use four rates (peak, off-peak, and valley). Each rate is then compared: for rates marked "enabled" in the database, the corresponding value field is checked for non-empty, valid values, and values ​​not less than zero. If a field is empty, has a negative value, or contains non-numeric characters, it is considered a missing rate. Rates not enabled in the database are not checked.

[0025] S23. Use the abnormal subset of readings and historical data of daily frozen energy readings to detect the problem of meter stopping and running away. Mark the data where the daily frozen energy reading does not change or changes beyond the preset range within a continuous time period as an abnormal stop or run, and generate a subset of meter operation abnormalities. Then, use the subset of meter operation abnormalities to determine the problem of meter running backwards. Mark the data where the daily frozen energy reading decreases and there is no reasonable electricity purchase record associated with it as a reverse running abnormality, and obtain the subset of reverse running abnormalities. S24. To address the issue of sudden changes in the amount of the reverse flow abnormal subset and the remaining amount data analysis, data with short-term large fluctuations in the remaining amount and no corresponding records of electricity purchases are identified as abnormal amount changes, generating an abnormal amount subset. Then, based on the abnormal amount subset and the power outage / once event data, the timeliness of the events is detected. Data with a time difference between the recorded time of the power outage / once event and the actual abnormal time of the electricity meter operation exceeding a preset threshold are marked as timeliness anomalies, resulting in the final set of abnormal data at the business layer.

[0026] Specifically, by performing integrity and format cleaning and multi-dimensional business logic verification on normal data at the specification layer, the problem of difficulty in automatically identifying anomalies at the business semantic level of collected data is solved. This enables comprehensive identification and classification aggregation of anomalies such as missing rate items, uneven readings, meter stoppages, running away, reversal, sudden changes in remaining amount, and power outage events.

[0027] S3. The fault factor algorithm composed of singular value decomposition and linear regression is used to perform cluster analysis on the abnormal data of the business layer, calculate the deviation between the cluster center of each type of anomaly and the historical fault mode threshold, and classify the data with deviation exceeding the specified range into a high-risk abnormal data subset. Furthermore, step S3 specifically includes: S31. Obtain time-series abnormal data from the abnormal data set of the business layer, use the singular value decomposition algorithm to decompose the time-series abnormal data to obtain the decomposition quantity, and perform cluster analysis based on the decomposition quantity to determine the cluster center of each type of abnormality. The business layer abnormal data set includes all business layer abnormal records identified in step S2. Each record is associated with a device identifier, anomaly type (such as missing rate, uneven readings, meter stoppage, meter flying away, meter running backwards, sudden change in remaining amount, power outage / restoration anomalies, etc.), and the timestamp of the anomaly occurrence. By filtering out records where the anomaly type is strongly correlated with the time series, such as uneven readings over multiple consecutive collection periods, daily sudden change sequences of remaining amount, and continuous time period records of meter stoppage, these records are grouped by device identifier, and each group is arranged in ascending order of time. Abnormal feature values ​​(such as reading deviation, change in remaining amount, duration of stoppage, etc.) are extracted at each time point to form a time-series abnormal data vector for each device. The time-series anomaly vectors of all devices are concatenated to form an original data matrix A of N rows and M columns, where N is the total number of anomaly time points and M is the feature dimension extracted for each time point. Features may include anomaly type code, anomaly magnitude, time interval from the previous anomaly, and auxiliary features such as daily temperature or load. Next, this matrix is ​​centered by calculating the mean of each column and subtracting the mean of its column from each element to obtain the centered matrix. Then on Perform singular value decomposition, the decomposition form is: ,in It is an N×N left singular matrix. Let M be an N×M singular value diagonal matrix, whose diagonal elements These are the singular values ​​obtained from the decomposition, arranged in descending order. The transpose of an M×M right singular matrix; these singular values This represents the required decomposition, where each singular value reflects the energy proportion of the corresponding latent pattern component in the original data. By retaining the top r largest singular values ​​and their corresponding singular vectors, dimensionality reduction and feature extraction of time-series anomalous data can be achieved, yielding the main anomalous pattern decomposition quantities for subsequent cluster analysis.

[0028] The specific process of performing cluster analysis based on the decomposition and determining the cluster centers of various anomalies is as follows: Extract the dimensionality-reduced feature matrix from the results obtained from singular value decomposition. Assuming that the first r largest singular values ​​are retained, the first r columns of the corresponding left singular matrix U constitute the matrix. Its dimension is N×r. (The rest of the text appears to be incomplete and requires further context.) Each row is considered as the coordinates of a sample point in an r-dimensional space, and each sample point corresponds to a time-series anomaly data record. Then, the K-means clustering algorithm is used to cluster these sample points: K cluster centers are randomly initialized, the Euclidean distance from each sample point to each cluster center is calculated, and the sample point is assigned to the cluster to which the nearest cluster center belongs; the mean of all sample points within each cluster is recalculated as the new cluster center; this process is repeated iteratively until the cluster centers no longer change or the maximum number of iterations is reached. The value of K is determined by the silhouette coefficient or the elbow rule. The resulting K cluster centers represent the central positions of each anomaly in the reduced-dimensional feature space, with each cluster center corresponding to an anomaly pattern. Simultaneously, projecting the cluster centers back into the original feature space yields typical feature vectors for each anomaly category, which are used for subsequent deviation calculations compared to historical fault mode thresholds.

[0029] S32. Obtain the historical threshold corresponding to the historical fault mode, and use the linear regression algorithm to calculate the deviation between the cluster center of each type of anomaly and the historical threshold to obtain the deviation calculation result. The calculation of the deviation between the cluster centers of various anomalies and historical thresholds using a linear regression algorithm includes: using the cluster centers of various anomalies obtained in step S31 as independent variables, and denoting the cluster center vector of the i-th anomaly as... ;in is the feature dimension. Simultaneously, historical thresholds corresponding to various anomalies are obtained from the historical fault mode library, denoted as the historical threshold for the i-th type of anomaly. This threshold is usually a scalar value, representing the critical characteristic value at which this type of anomaly is judged as high-risk in historical data (e.g., the deviation threshold of 0.03 for uneven readings, the threshold of 1000 yuan for sudden changes in remaining amount, etc.).

[0030] Then, for all K types of anomalies, a linear regression model is constructed, with the dependent variable Y being a vector of historical thresholds. Each row of the independent variable matrix X is the cluster center vector of the corresponding category. And add an intercept term, i.e., X=[ The regression coefficients were solved using the least squares method. To minimize the sum of squared residuals: After obtaining the regression model, for the i-th type of anomaly, calculate the regression prediction value corresponding to its cluster center. Next, calculate the deviation between the predicted value and the actual historical threshold: ; This deviation value This is the calculated deviation between the cluster centers of the i-th type of anomaly and the historical threshold. If... If the data exceeds a preset specified range, it is determined that the anomaly is a high-risk anomalous data subset. By using a linear regression algorithm, the influence of different feature dimensions can be eliminated, and the deviation of the cluster center from the historical threshold can be reflected more objectively.

[0031] S33. Compare the deviation calculation result with the specified range. If the deviation value exceeds the specified range, the abnormal data corresponding to the cluster center is classified as a high-risk abnormal data subset.

[0032] Specifically, the fault factor algorithm, composed of singular value decomposition and linear regression, is used to perform cluster analysis and historical threshold deviation calculation on abnormal data in the business layer. This solves the problem of automatically quantifying and classifying high-risk equipment in massive abnormal data, and realizes the scientific classification of abnormal risk levels and the accurate collection of high-risk abnormal data subsets.

[0033] S4. Extract the equipment manufacturers, models, software and hardware versions and terminal addresses from the high-risk abnormal data subset, search for similar historical fault records in the fault case database, calculate the matching degree, and obtain the equipment self-inspection report by issuing a penetration meter reading command through the electricity information collection system. Furthermore, step S4 specifically includes: S41. Extract equipment manufacturers, equipment models, software versions, hardware versions and terminal addresses from the high-risk abnormal data subset and perform structured processing. Based on this information, perform multi-dimensional comparisons in a pre-established fault case database, use the cosine similarity algorithm to calculate the degree of matching with historical cases, and determine the set of similar fault records. The process involves reading each abnormal record from a high-risk anomaly data subset, extracting the strings for equipment manufacturer name, equipment model, software version number, hardware version number, and terminal address. Non-standard characters (such as spaces, newlines, tabs, and special symbols) in each field are filtered and formatted uniformly. For example, equipment manufacturers are converted to uppercase pinyin or standardized encoding; model numbers are stripped of leading and trailing spaces and converted to lowercase; software and hardware versions are standardized according to the format "major version number.minor version number.revision number"; and terminal addresses are standardized to a fixed length using BCD code or hexadecimal strings with leading zeros. The processed fields are then concatenated or combined into key-value pairs to form a structured feature vector or JSON object. Each record corresponds to a unique structured entry for subsequent multi-dimensional comparison with the fault case database.

[0034] The specific process of calculating the matching degree with historical cases using the cosine similarity algorithm is as follows: First, fields such as equipment manufacturer, equipment model, software version, hardware version, and terminal address, extracted and structured from the high-risk abnormal data subset, are converted into feature vectors. Specifically, the value of each field is mapped to a unified feature space. For example, a full device attribute dictionary is established, and each attribute value is one-hot encoded or word frequency encoded, converting each abnormal record into a sparse vector C of length equal to the total number of features, where each dimension represents the existence or specific value of a certain attribute. Similarly, each historical fault record in the fault case database is pre-converted into a corresponding feature vector B according to the same encoding rules. Then, the cosine similarity between the two vectors is calculated using the formula: Where similarity represents cosine similarity, θ represents the angle between feature vectors C and B, and g is the total dimension of the feature vectors. and The values ​​for the current anomaly record and historical cases on dimension i are respectively. The calculated result ranges from [0,1]. The closer the value is to 1, the more consistent the directions of the two vectors are, meaning the higher the degree of matching between the current anomaly and the historical case in terms of device attributes. Finally, a matching threshold is set (e.g., 0.85), and all historical cases with a cosine similarity greater than or equal to this threshold are output as a set of similar fault records for subsequent fault mode judgment and command issuance.

[0035] S42. Extract fault modes and terminal address information from the set of similar fault records. Determine the potential fault type by comparing the common features of the current abnormal data with the historical fault records. If the potential fault type is highly correlated with historical cases, send a penetrating meter reading command to the corresponding terminal address through the electricity information collection system to obtain the real-time self-test report data of the equipment. The specific process of extracting fault modes and terminal address information from the set of similar fault records is as follows: traverse each historical case in the set of similar fault records, read the pre-stored fault mode fields in the case, such as standardized fault type codes like "clock out of tolerance", "485 meter reading failure", and "terminal power failure false alarm", as well as the corresponding terminal address or electricity meter address, statistically sort the extracted fault modes according to their frequency of occurrence, select the fault mode with the highest frequency as the most likely fault type to match the current abnormal data, and at the same time collect all associated terminal address information, deduplicate it to form a target device address list for subsequent penetration meter reading command issuance.

[0036] S43. Based on the acquired equipment self-inspection report data, perform automated comparison and analysis with the solution information in the historical fault records to determine whether the current equipment status conforms to the known fault mode, and generate fault troubleshooting guidance based on the equipment status analysis results, and store the guidance information in association with the self-inspection report data.

[0037] Specifically, by extracting device attributes from high-risk anomaly subsets, combining the cosine similarity algorithm to search and match historical fault records in the fault case database, and issuing a penetrating meter reading command to obtain self-inspection reports, the problem of difficulty in quickly locating high-risk device fault types is solved, and the automatic matching of fault modes based on historical experience and the efficient acquisition of remote self-inspection data of equipment are realized.

[0038] S5. Parse the terminal address, clock information, event counter and communication status word in the device self-test report, determine the specific fault type according to the protocol layer verification rules, and retrieve the corresponding repair protocol from the fault handling database; Furthermore, step S5 specifically includes: S51. Extract the terminal address, clock information, event counter and communication status word from the device self-test report. Use the preset protocol verification rules to check the legality of the terminal address and communication status word. If the field value exceeds the preset range, it is judged as an abnormal communication state and an abnormality mark is output. The specific process for extracting the terminal address, clock information, event counter, and communication status word is as follows: The raw data of the device self-test report obtained through the meter reading instruction is received. This report typically follows the DL / T1376.1 or DL / T698.45 protocol format, and is parsed field by field according to the offset positions defined in the protocol. The terminal address is located in the address field and is extracted and converted into a logical address format. The clock information is read from the time field, including year, month, day, hour, minute, and second, and merged into a complete timestamp. The event counter is located in the event record area, and key count values ​​such as power outage event count and power-on event count are extracted. The communication status word is parsed from the status word field, with each bit representing a different communication status, such as bit 0 indicating whether 485 communication is normal, bit 1 indicating whether carrier communication is normal, etc. All extracted fields are stored in key-value pairs for subsequent legality checks.

[0039] The preset protocol verification rules refer to a set of legality judgment standards for electricity information collection protocols such as DL / T1376.1 and DL / T698.45 that are predefined and stored.

[0040] The terminal address and communication status word are validated using preset protocol verification rules, including: Terminal address validation: The first step is to read the terminal address field from the device self-test report. In the DL / T1376.1 protocol, the terminal address occupies 5 bytes and is usually stored in BCD code format. Convert this 5-byte data into a string or integer value. The second step involves performing the following three checks one by one: Null or all-zero detection: If all 5 bytes are 0x00, it is determined that the address is null or abnormal; All F check: If all 5 bytes are 0xFF, it is determined to be an address broadcast anomaly (broadcast addresses are usually not allowed to be used as unique device identifiers); File matching detection: The parsed terminal address is compared with the list of registered terminal addresses in the electricity information collection system's archive. If the address does not exist in the archive, it is determined to be an address that is not registered. If any of the above checks fails, an illegal terminal address error flag will be output, and the specific reason will be recorded.

[0041] Communication status word validity check: The first step is to read the communication status word from the device self-test report. The communication status word usually occupies 2 bytes (16 bits), and each bit represents a communication status or fault flag.

[0042] The second step is to check whether the value of each bit is within the range allowed by the specification. Taking the 1376.1 specification as an example, a typical definition is as follows: Bit 0 (least significant bit): 485 communication status, 0 indicates normal, 1 indicates abnormal. If this bit has a value that is neither 0 nor 1 (in reality, since a bit can only be 0 or 1, this step can be skipped, but it is necessary to confirm that the byte value has no illegal bit combinations), it is necessary to check whether it contradicts the known communication facts: if the current communication is normal and this bit is 1, then it is determined that the status is inconsistent; 1st position: Carrier communication status, also 0 normal and 1 abnormal; Second position: Ethernet communication status; Positions 3 through 7: Reserved, must be 0; Positions 8 through 15: Other states defined by the manufacturer or by the specification. The value range needs to be checked one by one according to the specific specification standard.

[0043] During the detection, the system checks each bit one by one: for reserved bits that are explicitly prohibited from being 1 in the protocol, if they are 1, the status word is determined to be illegal; for function bits, if the value exceeds {0,1} (which will not actually happen, but range verification can be performed), or if the value contradicts the communication status actually perceived by the system (e.g., the device is detected to be online through heartbeat but all communication status bits in the status word are set to 1), the communication status word is determined to be abnormal. The third step is a comprehensive judgment: if either the terminal address detection or the communication status word detection fails, a communication abnormality status indicator is output, along with abnormal details (e.g., the terminal address is not registered or the reserved bits of the communication status word are non-zero). If both fail, a normal communication status indicator is output, and subsequent steps are continued.

[0044] S52. Based on the anomaly identifier, combined with the clock information and the recorded value of the event counter, compare the timestamp and event frequency of the historical data to determine the timing deviation or counting anomaly. Match the corresponding fault type code according to the fault type classification table to generate the fault classification result. Among them, clock information: the current internal clock time of the device extracted from the device self-test report, usually including year, month, day, hour, minute and second, used to compare with the system master station time or historical timestamp; Event counters: The cumulative number of various events recorded internally by the device, such as power outage event counters, power-on event counters, and overvoltage event counters. The counter automatically increments by 1 each time a corresponding event occurs. Recorded values: refer to the specific numerical values ​​of the clock information and the current count value of the event counter; Timestamps of historical data: These are the timestamps of historical records stored in the database of the electricity information collection system, such as the time of the last reported power outage event or the time of the last data freeze. Event frequency: The number of times a certain type of event occurs per unit of time, such as the number of power outages in the past 24 hours. It is obtained by calculating the difference between the current event counter and the historical counter, divided by the time interval. Timing deviation: refers to the difference between the device clock and the system standard time, or the difference between the time the device reports an event and the actual time it occurs. For example, the device clock is 5 minutes ahead of the standard time, or the power outage event is reported 10 minutes later than the actual power outage time; Counting anomalies: This refers to changes in the event counter that do not conform to expected logic. For example, the power outage counter increases for no reason during a period when no power outages have occurred, or the increment of the counter between two adjacent reports does not match the number of reported events. Fault Type Classification Table: A pre-established mapping table that maps different combinations of anomaly identifiers, timing deviation ranges, and count anomaly types to standardized fault type codes. For example, the table defines: if the anomaly identifier is "communication status normal" and the timing deviation exceeds 5 minutes, the fault type code is "T001 - clock error"; if the count anomaly manifests as an unexpected increase in the power outage counter, the fault type code is "E002 - false power outage alarm". Fault type code: A unique code that identifies a specific fault and is used to retrieve the corresponding repair protocol from the fault handling database.

[0045] S53. Based on the fault classification results, retrieve the corresponding repair protocol and repair instruction set from the fault handling database, generate equipment adjustment parameters and send them to the target terminal address, record the sending log, and if the execution feedback does not match the expectations, mark it as an execution exception and output an exception report.

[0046] The specific process of retrieving the corresponding repair protocol and repair instruction set from the fault handling database is as follows: Using the fault type code generated in step S52 as the primary key, a precise matching query is performed in the pre-built fault handling database. This database uses the fault type code as an index, and each record contains the corresponding repair protocol identifier, repair instruction set sequence, required parameter list, and expected execution result template. After a successful match, the operation step sequence in the repair protocol is extracted. For example, the time synchronization protocol needs to include the standard time source address and write command; the parameter correction protocol needs to include the parameter number to be modified and the target value; the terminal restart protocol needs to include the restart command code and waiting time; and the event buffer clearing protocol needs to include the clearing command and confirmation code. Simultaneously, the required device adjustment parameters are parsed from the protocol, such as the time synchronization parameter being taken from the home station system time, and the correction parameter being taken from the standard configuration value in the archive. The repair instruction set and specific parameter values ​​are assembled into a complete downlink message format for subsequent distribution. If no repair protocol with the corresponding fault type code exists in the database, an empty result is returned, and a manual processing alarm is triggered.

[0047] Specifically, by parsing the terminal address, clock information, event counter, and communication status word in the device self-test report, and combining the protocol verification rules and fault type classification table, the fault type is accurately determined and the corresponding repair protocol is retrieved. This solves the problems of difficult automated parsing of device self-test data and low efficiency in fault type matching, and realizes rapid identification of fault types and instant acquisition of repair protocols.

[0048] S6. Execute automated scripts through remote communication networks to send repair protocols to data acquisition terminals or electricity meters, including remote time synchronization, parameter correction, terminal restart or event buffer clearing, and record the device status update after repair. Furthermore, step S6 specifically includes: S61. Obtain the set of terminal addresses to be repaired and the corresponding repair instruction type, match the repair instruction type from the instruction set, and generate a complete instruction sequence containing specific parameters from the preset instruction template library according to the instruction type. If the instruction is a time synchronization instruction or a parameter correction instruction, obtain the standard time source or standard parameter value from the system and embed it into the instruction sequence. The specific process of obtaining the set of terminal addresses to be repaired and the corresponding repair instruction types is as follows: All terminal addresses requiring repair are extracted from the fault classification results. Each terminal address is associated with a determined repair instruction type, which includes remote time synchronization, parameter correction, terminal restart, or event buffer clearing. Based on the repair instruction type, a corresponding instruction template is matched from a preset instruction template library. The remote time synchronization template includes a time setting command code, time byte length, and time data placeholders; the parameter correction template includes a parameter identifier, parameter length, and parameter value placeholders; the terminal restart template includes a restart command code and a delay wait placeholder; and the event buffer clearing template includes a clear command code and a confirmation code placeholder. If the instruction type is remote time synchronization, the system obtains the current precise time from a standard time source server, converts it to a time format conforming to the specification requirements, embeds the time data placeholders in the instruction template, and generates a complete time synchronization instruction sequence. If the instruction type is parameter correction, the system reads the standard parameter configuration values ​​of the terminal from the archive, such as terminal address, communication rate, CT ratio, PT ratio, etc., encodes the standard parameter values ​​according to the protocol format, and embeds them into the parameter value placeholders in the instruction template to generate a complete parameter correction instruction sequence. If the instruction type is terminal restart or event buffer clearing, the instruction template does not need to embed external parameters and directly generates a standard instruction sequence. All generated complete instruction sequences contain a start-of-frame character, control field, address field, data field, frame checksum, and end-of-frame character, forming a message format that can be sent.

[0049] Where CT stands for Current Transformer Ratio and PT stands for Voltage Transformer Ratio.

[0050] The specific process of matching repair instruction types from the instruction set is as follows: Based on the fault type code in the fault classification results, the corresponding repair instruction type (such as remote time synchronization, parameter correction, terminal restart, or event buffer clearing) is determined through a predefined mapping table. Then, the instruction type is used as the key to perform a precise search in the preset instruction set. The instruction set stores the command code, parameter format, and expected response template of each instruction using the instruction type as the index. If a match is successful, the corresponding instruction template is returned for subsequent use in generating a complete instruction sequence. If a match fails, the task is marked as an unknown instruction type and transferred to the manual processing queue.

[0051] S62. The complete instruction sequence is sent to the target terminal address through a polling mechanism via a remote communication network. A listening process is started to obtain the feedback value returned by the target terminal from the communication network. The instruction execution status is determined by comparing the feedback value with the expected result of the instruction. The specific process of sending the complete instruction sequence to the target terminal address via a polling mechanism through a remote communication network is as follows: A list of terminal addresses to be repaired is obtained, and each address is processed sequentially. For the current terminal, the generated complete instruction sequence is sent to the designated terminal address in message form through the front-end communication module of the remote communication network. Immediately after sending, a listening process is started, with a timeout set (e.g., 30 seconds), waiting for an acknowledgment frame or response data frame from the target terminal. The listening process captures the returned messages from the communication network, parses the frame structure, and extracts feedback status fields. For example, for time synchronization instructions, the terminal returns a confirmation code indicating success or failure; for parameter correction instructions, the terminal returns a flag indicating successful or failed parameter writing; for restart instructions, the terminal returns an acknowledgment of readiness to restart; and for clearing instructions, the terminal returns a clearing completion flag. The feedback value is compared with the expected result of the instruction. The expected result is predefined in the instruction template library. For example, the time synchronization instruction expects to receive a successful confirmation frame without an error code, and the parameter correction instruction expects to receive a successful write response. If the feedback value is consistent with the expected result, the instruction is judged to have been executed successfully. If the feedback value is an error code or no feedback is received after a timeout, the instruction is judged to have failed, and the reason for the failure is recorded, such as communication timeout, verification error, instruction not supported, etc.

[0052] S63. Update the device status record according to the instruction execution status. If the status record shows that the execution failed, trigger the preset backup instruction sequence or mark it as manual processing according to the failure type, and record the device status update after repair.

[0053] If the repair result does not meet expectations, return to step S5, re-parse the device self-test report and retrieve the repair protocol.

[0054] The specific process of updating the device status record based on the instruction execution status is as follows: The successful or failed execution status determined in step S62 is written into the device status record table, which includes fields such as terminal address, repair instruction type, execution time, execution result, and failure reason. If the status record shows successful execution, the last repair time and current status of the device are updated to normal. If the status record shows failed execution, a preset backup instruction sequence is triggered according to the failure type. For example, if communication timeout fails, it will automatically retry once; if the terminal returns a verification error, it will re-verify and resend the instruction; if the instruction is not supported, it will switch to a simplified instruction sequence. If the backup instruction sequence still fails after execution, the terminal is marked as manually processed, and a pending work order is generated, including the terminal address, original fault type, failure reason, and attempted repair instructions, which is then pushed to the maintenance personnel's workbench. Regardless of whether the execution is successful or failed, the system records the device status update after repair, including the current operating status of the device, the latest self-test report time, and repair operation logs, for subsequent data quality verification and status assessment.

[0055] The preset instruction template library refers to a collection of instruction templates pre-built and stored in the system. Each template corresponds to a repair instruction type, including remote time synchronization, parameter correction, terminal restart, and event buffer clearing. Each template defines the instruction's command code, parameter placeholders, parameter length, expected response structure, and timeout period in a fixed format, but does not contain specific parameter values. During repair, the corresponding template is called based on the matched instruction type, and the actual parameter values ​​obtained from the standard time source or archive are filled into the placeholders, thereby generating a complete, deployable instruction sequence.

[0056] Polling mechanism: This refers to sending instructions to each terminal in the terminal address list in a preset order, that is, sending instructions to only one terminal at a time, and processing the next terminal only after the instruction is completed (receiving feedback or timeout), rather than sending instructions to multiple terminals at the same time, in order to avoid communication conflicts and resource contention. Listening process: refers to an independent program or thread that starts after an instruction is issued. It is specifically responsible for receiving the response message returned by the target terminal from the communication network within a specified timeout period, and performing preliminary parsing and status capture on the message to determine whether the instruction has been successfully executed. Expected Result: Refers to the standard response content predefined in the instruction template library for each type of repair instruction. For example, the expected result of the time synchronization instruction is that the terminal returns a success confirmation frame without error code, and the expected result of the parameter correction instruction is that the terminal returns a write success flag; Backup instruction sequence: refers to the set of alternative repair instructions that are automatically triggered when the main repair instruction fails. The backup instruction sequence is preset according to the failure type. For example, if the communication timeout fails, it will automatically retry once; if the terminal returns a verification error, it will re-verify and resend the instruction; if the instruction is not supported, it will switch to a simplified instruction sequence, etc. Manual intervention status: When all automatic repair methods (including main command and backup command sequence) fail, the system marks the terminal as requiring manual intervention by operation and maintenance personnel, generates a work order containing information such as terminal address, original fault type, and failure reason, and pushes it to the operation and maintenance personnel's workbench.

[0057] Specifically, by generating and issuing repair instruction sequences through automated scripts, combined with polling issuance, listening feedback, and backup instruction mechanisms, the problem of fault repair relying on manual operation and having a low success rate is solved, and a closed-loop recording of remote automatic repair and execution status of the acquisition terminal is realized.

[0058] S7. Use a streaming computing framework to perform real-time verification of the data re-collected by the repaired acquisition terminal or electricity meter. After confirming that the data quality has returned to normal, integrate the quality indicators into the power grid operation decision module, and use a genetic algorithm to perform regression verification and optimization of the verification rule coefficients.

[0059] Furthermore, step S7 specifically includes: S71. A streaming computing framework is used to process and preliminarily screen the data re-collected by the repaired acquisition terminal or electricity meter in real time. A real-time verification mechanism is used to perform deep detection on the data stream. If missing or abnormal values ​​are detected, the automatic completion logic is triggered to obtain a completed data stream that meets the preset standards. In this process, a data source connector is configured in a streaming computing platform (such as Apache Flink or Spark Streaming) to subscribe in real-time to the raw data stream sent by the repaired device from a Kafka message queue topic. The Kafka topic is partitioned according to device type and data category to ensure high-throughput parallel consumption. The streaming computing task divides the data stream into fixed time windows (e.g., a micro-batch window every 5 seconds or event-time processing), and the data within each window is processed independently. Upon entering a window, a data integrity check is first performed: the frame start character, frame length, and frame checksum of each data frame are read, and invalid data frames that do not match the actual number of bytes or whose checksum verification fails are discarded and output to the exception log channel. Then, the data that passed the integrity check is validated for non-empty fields. Key fields such as daily frozen energy readings, voltage values, current values, timestamps, and device addresses are checked one by one to see if they are null or empty strings. If a missing field is found, automatic completion logic is triggered based on the field type: for continuous numerical fields (such as daily frozen energy readings), linear interpolation is used to fill the data based on the values ​​at two valid time points before and after; for discrete fields (such as rate codes), the mode of historical data for the same period is used; for missing timestamps, the Kafka message's received timestamp is used as an approximation. Next, the completed data undergoes a reasonableness threshold screening: based on preset physical threshold ranges (such as voltage 0~1.2 times rated voltage, current not exceeding 1.5 times rated current, power factor -1~1), if a field value exceeds the threshold, it is marked as a suspected anomaly but not deleted; instead, it is separately diverted to a deep detection queue. After initial screening, the data stream is divided into two paths: one is the normal data stream that meets the basic integrity and rationality requirements, which directly enters the quality indicator calculation in step S72; the other is the data stream that needs to be deeply detected and contains missing completion records or suspected outliers, which is sent to the real-time verification mechanism for further business logic verification (such as uneven readings, stoppages, fly-aways, etc.). The entire process saves intermediate completion model parameters and window statistics through the state backend of the streaming computing framework (such as RocksDB) to ensure that the processing state can be accurately restored during fault recovery, achieving real-time processing with millisecond-level latency.

[0060] In step S71, the specific process of performing deep detection on the data stream through the real-time verification mechanism is as follows: For the data stream to be deep detected after preliminary screening, the following business logic verifications are executed sequentially: The first step is to detect missing rates: extract the daily frozen energy readings from the data stream, query the user profile to obtain the list of rates that the user should use (such as peak, flat, and valley rates), check whether the corresponding rate readings exist in the records and are non-negative, and mark it as a missing rate if the required rate is missing. The second step is to detect discrepancies in readings: calculate the absolute difference between the total daily frozen energy reading and the sum of the readings for each rate. If the difference is greater than a preset threshold (e.g., 0.03 kWh), it is marked as an abnormality in readings. The third step is to detect when the meter stops running: If the daily frozen energy readings for two consecutive data collection cycles do not change and the current current is greater than 0.1 amperes (for non-residential users) or the remaining amount decreases (for residential users), then it is marked as an abnormal stop running. The fourth step is to detect if the meter is running away: Calculate the daily electricity consumption. If it exceeds the theoretical maximum electricity consumption (rated voltage × rated current × 24 hours × 1.2), it is marked as running away abnormally. Step 5, Meter Reverse Running Detection: If the current daily frozen energy reading is less than the reading of the previous collection cycle, and there is no meter replacement record for the day, it is marked as reverse running abnormal; Step 6, Detection of Abnormal Changes in Remaining Amount: If the decrease in remaining amount exceeds the theoretical maximum electricity cost (electricity consumption × maximum electricity price) and there is no corresponding electricity purchase record, it is marked as an abnormal change in amount; Step 7, Power Outage / Power On Event Validity Detection: For power outage / power on events, check whether the difference between the power outage time and the power on time is less than 10 minutes or greater than 3 days. At the same time, test the equipment voltage for verification. If the conditions are not met, mark the event as invalid.

[0061] All depth detection steps are calculated using the state cache (such as the previous cycle reading, current value, etc.) within the streaming computation window. The detection results are output to the anomaly marker field in real time, and the data stream after depth detection is merged with the normal data stream for subsequent quality indicator calculations.

[0062] S72. Calculate various data quality indicators and evaluate stability based on the completed data stream. Integrate the quality indicators into the power grid operation decision module for classified storage and decision-making needs judgment, and record the fluctuation of the indicators. The specific process for calculating various data quality indicators and evaluating stability of the completed data stream is as follows: First, quality-related fields are extracted from the completed data stream according to device and time dimensions, including daily frozen energy reading completeness rate, rate missing rate, reading discrepancy rate, meter stoppage rate, meter runaway rate, meter reverse rate, remaining balance mutation rate, and power outage / restoration event effectiveness rate. For each indicator, the current value is calculated using a rolling time window (e.g., the past 24 hours or the past 7 days): the completeness rate equals the number of valid records actually collected divided by the number of records that should be collected; each anomaly rate equals the number of corresponding abnormal records divided by the total number of records. Then, the stability of each indicator is calculated using the standard deviation formula: For the same indicator value over multiple consecutive days (e.g., 5 consecutive days), a dispersion analysis is performed. The smaller the standard deviation, the more stable the indicator is, and vice versa. Here, S is the standard deviation, and n is the number of consecutive days (e.g., n=5). Let i be the index value for day i. The arithmetic mean of the n-day index values ​​is used. Meanwhile, the changes in the indexes of the same equipment before and after the repair are compared. If the abnormality rate decreases significantly after the repair and the standard deviation converges to below the preset threshold, the data quality is determined to have been restored to stability. The calculated quality indicators (including current value, historical mean, standard deviation, and changes before and after the repair) are integrated into structured data and transmitted to the power grid operation decision module for persistent storage.

[0063] The power grid operation decision module refers to the functional unit in the power grid dispatching or marketing system responsible for making decisions such as operation control, electricity price calculation, load forecasting, and fault handling based on collected data. This module typically includes components such as an electricity price calculation engine, a load control strategy library, an equipment condition assessment subsystem, and a user service interface. The accuracy of its input data directly determines the reliability of the decision output.

[0064] The specific process of integrating quality indicators into the power grid operation decision module for classification, storage, and decision-making needs assessment is as follows: The various quality indicators calculated in step S72 (such as completeness rate, anomaly rate, and stability standard deviation) are classified according to equipment type, time granularity, and geographical region, and stored in the quality metadata database of the decision module, with added repair identifiers and timestamps. Each time the decision module performs electricity bill calculation, load forecasting, or equipment status assessment, it first queries the corresponding equipment's quality indicators. If the completeness rate is below 95% or the anomaly rate is above a preset threshold, the decision module automatically marks the equipment's data as "pending verification," prioritizing the use of completed data or historical data from the same period, and indicating data quality risks in the decision report. If the quality indicators return to normal and remain stable for three consecutive cycles, the decision module resumes using real-time data and lowers the verification priority. Simultaneously, the decision module performs correlation analysis between the quality indicators and business decision results (such as electricity bill deviations and load forecasting errors). When a strong correlation is found between quality indicator fluctuations and decision deviations, a verification rule coefficient optimization request is triggered.

[0065] S73. Use a genetic algorithm to perform regression analysis on the coefficients of the verification rules to obtain an optimized set of coefficients, update the verification rules and verify the subsequent data stream, adjust the input parameters of the power grid operation decision module based on the more accurate quality assessment results, and confirm that the data quality has returned to normal.

[0066] The specific process of using a genetic algorithm to perform regression analysis on the coefficients of the verification rules to obtain the optimized coefficient set is as follows: The set of verification rule coefficients to be optimized is determined. These coefficients include various thresholds used in steps S71 and S72, such as the threshold for judging uneven readings (currently 0.03 kWh), the current threshold for meter stoppage (currently 0.1 A), the theoretical maximum electricity consumption multiple for meter overrun (currently 1.2), the electricity bill multiple for sudden changes in remaining balance (currently 1.0), and the time window for judging the timeliness of power outage events (currently 5 minutes). All coefficients to be optimized are encoded into a chromosome using real-number encoding, with each coefficient corresponding to a gene position, forming a vector. , where m is the total number of coefficients; Secondly, a fitness function is constructed. The fitness function evaluates the performance of a set of coefficients in the validation rules. A batch of sample data with known labels (normal or abnormal) is selected from historical data. The samples are validated using the current set of coefficients, and the precision, recall, and false positive rate of the validation results are calculated. The fitness function is defined as a comprehensive score, for example, F = α·precision + δ·recall - γ·false positive rate, where F is the fitness value, used to evaluate the performance of a set of validation rule coefficients; α, δ, and γ are weighting coefficients; a higher fitness value indicates a better set of coefficients.

[0067] Then, the iterative optimization process of the genetic algorithm is executed: Initialize the population: randomly generate V chromosomes (e.g., V=100), and the gene value of each chromosome is randomly selected within a preset range, for example, the reading imbalance threshold is between 0.01 and 0.10, and the current threshold is between 0.05 and 0.50 amperes; Fitness assessment: For each chromosome in the population, it is decoded into a specific verification rule coefficient, verified against historical sample data, and the fitness value of each chromosome is calculated; Selection operation: The roulette wheel selection method is used to select parent chromosomes according to the ratio of fitness values. The chromosome with higher fitness has a greater probability of being selected. Crossover operation: Perform single-point or multi-point crossover on the selected parent chromosomes with a preset crossover probability (e.g., 0.8) to exchange some gene loci and generate offspring chromosomes; Mutation operation: Randomly perturb some gene loci on the offspring chromosome with a preset mutation probability (e.g., 0.05), increasing or decreasing a small amount within the allowable range of coefficients to maintain population diversity; Generate a new generation of population: Replace the individuals with the lowest fitness in the original population with offspring chromosomes, while maintaining the same population size.

[0068] Repeat this process until the preset number of generations (e.g., 200 generations) is reached or the fitness value converges (the change is less than the threshold for multiple consecutive generations). Finally, the chromosome with the highest fitness is selected from the population, and the optimized set of coefficients is obtained by decoding.

[0069] Finally, the optimized coefficient set is updated in the verification rule base, replacing the original fixed threshold. When performing deep detection on subsequent data streams, the new coefficients are used to determine anomalies such as uneven readings, stopping, flying away, and sudden changes in amount. At the same time, a genetic algorithm regression analysis is automatically triggered every cycle (e.g., monthly) to re-optimize the coefficients using newly added normal and abnormal sample data, so that the verification rules can adapt to changes in data distribution and continuously improve the verification accuracy. The optimized coefficient set is also recorded in the rule version management table for easy backtracking and comparison.

[0070] Specifically, the repaired data is verified and its quality is assessed in real time through a streaming computing framework, and the quality indicators are integrated into the power grid operation decision module. At the same time, the verification rule coefficients are dynamically optimized using a genetic algorithm, which solves the problems of difficulty in verifying the repair effect in real time and the inability of the verification rules to be adaptively optimized, and realizes real-time confirmation of data quality recovery and continuous iterative improvement of verification rules.

[0071] Example 2 provides an automatic identification and verification method for abnormal electricity meter reading data, applicable to the automatic quality verification of daily frozen electricity reading data for residential and non-residential users in an electricity information collection system. The method includes the following: Step 1: Data Acquisition and Preprocessing. Every day at midnight, the system automatically acquires the previous day's frozen energy consumption data from the electricity information collection system, including: user identification, collection time, total daily frozen energy consumption of positive active power, daily frozen energy consumption for each tariff rate (peak, flat, and valley), current, voltage, remaining balance, meter replacement records, etc.

[0072] The acquired data is formatted and standardized, including: unifying the time format to YYYY-MM-DDHH:MM:SS, marking missing values, and converting data types.

[0073] Step 2: Verify discrepancies between time stamp and meter reading time For time stamp anomaly detection, compare the collection date issued by the main station with the time stamp of the data returned by the terminal. If the two are inconsistent (for example, the main station issues data for the 20th, but the terminal returns data for the 19th), it is determined to be "time stamp anomaly", and the data is stored to the 20th. The system detects anomalies in terminal meter reading time by checking if the terminal meter reading time matches the daily frozen data timescale (allowing for a 1-hour error). If the meter reading time is earlier than the frozen timescale, it is determined as "terminal meter reading time is ahead of schedule"; if it is later, it is determined as "terminal meter reading time is behind schedule".

[0074] Step 3: Rate and Indication Integrity Verification To determine if rate data is abnormal, according to the specific data collection standards for a particular region, normal rate data should include four rates (peak, peak, flat, and valley), with the first rate (peak) being either empty or 0. If the collected peak rate is neither 0 nor empty, it is considered "abnormal rate data". To determine if a rate is missing, check if the total daily frozen energy readings and the daily frozen energy readings for each rate are complete. If the total reading is missing or any rate reading is missing, it is determined as a "rate missing item". To determine if the readings are unbalanced, calculate the difference between the total daily frozen energy reading and the sum of the daily frozen energy readings for each tariff rate. If the absolute value is ≥0.03, it is determined to be "unbalanced readings". For residential users, only the total positive active power reading is checked; for non-residential users, positive active power, negative active power, positive reactive power, and negative reactive power must be checked separately, and only when all of them are not equal is it considered abnormal.

[0075] Step 4: Verify abnormal operation status of the electricity meter For non-residential users (excluding distributed generation and low-voltage single-phase): if the daily frozen energy reading of the positive active power is equal to the previous day's reading, and the current current is >0.1A, then the meter is determined to be "out of service". Residential users: If the daily frozen energy reading is equal to the previous day's reading, and the remaining amount for the same period decreases, it is determined that the meter has stopped running. For non-residential users, the determination of "meter flying away" is as follows: if the operating capacity is >10 and the total positive active power ÷ (24 × operating capacity) >1.2, then the meter is determined to have "meter flying away". Residential users: If the positive active power is greater than the rated voltage × rated current × 24h × 1.2, it is determined as "meter flying away"; To determine if an electricity meter is running backwards, if the daily frozen energy reading minus the previous day's reading is less than 0, and there is no record of meter replacement on that day, then the meter is considered to be running backwards.

[0076] Step 5: Verification of abrupt changes in indicated values ​​and the accuracy of the rate readings The indicator abrupt change judgment is made by calculating the actual daily electricity consumption and the theoretical maximum daily electricity consumption. If the actual electricity consumption is greater than the theoretical maximum electricity consumption, it is judged as an "indicator abrupt change".

[0077] Theoretical maximum power calculation formula: Three-phase three-wire: × Line voltage × Maximum phase current × CT × PT × 0.95; Three-phase four-wire: 3 × phase voltage × maximum phase current × CT × PT × 0.95; The "peak rate fluctuation" detection method determines whether a rate has malfunctioned. If the peak rate data is not 0, and the peak rate value for the current day is greater than the peak rate value for the previous day, then it is considered a "peak rate fluctuation". Step 6: Abnormal Data Aggregation and Push All the above verification results are summarized by user, time, and anomaly type to generate an anomaly data list; data that passes verification is automatically pushed to the marketing business system. For data that fails verification, the system does not automatically push notifications but generates a detailed list for business personnel to manually verify. Business personnel can decide whether to push the results or take further action based on the diagnostic results and correlation analysis (such as manufacturer, batch, and replacement records).

[0078] Step 7: Statistical Analysis of Abnormal Data The system automatically counts the number and percentage of various anomalies daily, and performs distribution analysis by power supply unit, meter manufacturer, and protocol version, etc. By calculating the standard deviation of abnormal data over several consecutive days, it can be determined whether the abnormalities have been handled in a timely manner. If the number of a certain type of abnormality remains stable (small standard deviation) over several consecutive days, it will prompt the operations and maintenance personnel to pay close attention.

[0079] Example 3 This embodiment provides an automatic identification and verification method for abnormal electricity meter reading data. It is a real-time data quality verification method based on a three-layer model and fault factors, applicable to real-time quality verification of operating data from data acquisition devices (including dedicated transformer terminals, concentrators, and smart meters) in electricity information acquisition systems. This method integrates source code layer specification verification, business layer logic verification, and dynamic evaluation of fault factors, and achieves real-time verification based on stream computing, while also possessing model autoregressive optimization capabilities.

[0080] Building a three-layer validation rule base For the 1376.1 and 698.45 protocols widely used in electricity information collection systems, a source code layer protocol rule base is established, pre-setting frame start character (0x68) and end character (0x16) verification, protocol version verification (distinguishing between 2005, 2009, and 2013 versions based on D0 and D1 bits), frame length verification (consistency between L and user data length L1+8), frame check and CS check (arithmetic sum of eight bits in the user data area, with no carry), transmission direction identifier DIR verification, and frame sequence number PSE. The system performs the following checks: Q consistency verification, terminal address A2 verification (should be 0000H), MSA response consistency verification, time stamp TpV identifier verification, AFN data frame response consistency verification, table address consistency verification, and BCD code and date format validity verification. For the 698.45 protocol, additional checks are added: frame header verification (HCS), frame verification (FCS), application layer service matching verification (GET / SET / ACTION / PROXY correspondence), and transmission timing and timeliness verification. Furthermore, based on the power grid company and provincial... The company has established an online metering monitoring anomaly rule library, creating a business-level logic rule library. This library covers meter reading rules (missing rates, uneven readings, meter stopping, running away, running backwards, sudden changes in readings, abnormal rate readings, abnormal time stamps, and abnormal terminal meter reading times), fee control rules (remaining amount stopping, abnormal increase / decrease, discrepancy between remaining amount and overdraft amount, sudden changes in remaining amount, unreasonable electricity price, mismatch between remaining amount and accumulated amount, and mismatch between number of electricity purchases and amount), and event rules (timeliness requirement for terminal power outage / power-on events: the difference between the main station's reception time and the event occurrence time must be ≤30 minutes; power outage effectiveness requirement: the voltage of phase A of the test meter must be ≤50V; power-on effectiveness requirement: consistency with the power outage / power-on time of the connected meters must be ≤5 minutes). Finally, fault factors are extracted from historical fault reports. Each factor includes attributes such as equipment manufacturer, software and hardware version, protocol type, clock deviation, historical anomaly event type, years of operation, ambient temperature, power supply unit, and batch number. An initial weight is assigned to each factor using the analytic hierarchy process or entropy weight method, and these factors are stored in a fault case library. Real-time verification process based on stream computing The data validation process is moved to the front-end data collection service, and streaming computation is implemented using Kafka message queues and Spark Streaming, including: Source code layer specification verification: After receiving the raw data frame from the terminal, the front-end service immediately calls the source code layer specification verification module. If the verification fails (such as frame header error, checksum error, AFN mismatch, etc.), the abnormal frame and the reason for failure are written to the "Abnormal Source Code" topic in Kafka, and the device ID, timestamp, and failure type are marked. If the verification passes, proceed to the next step. Data parsing and basic filtering: The task service consumes validated data frames from Kafka, parses them into structured business data, including daily frozen energy readings, remaining balance, number of electricity purchases, event records, etc., and writes them to the "Raw Data" topic in Kafka. The basic validation service consumes the "Raw Data" topic and performs null, range, and basic mutation filtering. For example, if the daily frozen energy reading is negative or exceeds twice the theoretical maximum value (theoretical maximum capacity is calculated as rated voltage × rated current × 24 hours), it is directly judged as a suspected anomaly and written to the "Abnormal Data" topic; otherwise, it is written to the "Validation Data" topic. Business layer logic verification: Verify and analyze the "abnormal data" theme in service consumption, and sequentially execute the judgments in the business layer logic rule base; for example, for daily frozen electricity readings, if the current total positive active power reading is less than the previous day's reading and there is no meter replacement record for the day, it is determined as "meter running backwards"; if the non-residential user's operating capacity (unit: kVA, referring to the transformer's rated capacity) > 10 and the total positive active power (kWh) ÷ (24 hours × operating capacity) > 1.2, it is determined as "meter running away"; if the residential user's positive active power... If the electricity consumption (kWh) > rated voltage (V) × rated current (A) × 24h × 1.2, it is judged as "meter running away"; if |total reading - (peak + flat + valley) reading| ≥ 0.03, it is judged as "uneven reading"; for prepaid data, if the daily frozen remaining amount equals the previous day's remaining amount and the electricity consumption > 0 and there is no remote recharge record, it is judged as "stopped running"; if the previous day's remaining amount - the current day's remaining amount > 1000 (residential) or > 10000 (non-residential), it is judged as "abnormal decrease". For clearly identified anomalies, they are directly written into the "verification result" topic and marked with the anomaly type; for boundary data judged as "pending confirmation", they enter the fault factor in-depth analysis. In-depth analysis of fault factors: The system reads the device's profile information, historical anomaly records, and similar device fault modes from a distributed in-memory database (such as Redis or GemFire). It calculates the fault factor matching score T = Σ(w_i × m_i), where w_i is the weight of the i-th factor, and m_i is the similarity between the current device and the i-th factor in the fault case library (value range 0~1, 1 for a perfect match, 0 for a non-match, and partial matches are calculated proportionally). If T exceeds the threshold (initially set to 0.7), it is judged as a "fault-related anomaly" and recommended handling suggestions are output (such as suggesting device replacement, re-sampling data, or checking the clock). If T is less than or equal to the threshold, it is judged as a suspected anomaly pending manual confirmation. All in-depth analysis results (including factor scores and matched fault case IDs) are written to the "Verification Results" topic.

[0081] Categorized storage and closed-loop processing of abnormal data A hybrid storage architecture is adopted to classify and store the verification results: normal verification data is written to the Oracle business analysis database for marketing system settlement, abnormal data and fault factor scores are written to HBase (retained for 1-2 years) and ElasticSearch (for fast retrieval), and the original source code frame is written to HDFS (retained for 6 months). The system automatically generates an abnormal data list and pushes it to the operation and maintenance work order system through the interface to generate pending tasks. Business personnel can view the abnormal details, fault factor scores, and historical information of similar devices in the visual interface, and choose one of the following operations according to the actual situation: push to the marketing system (data is deemed usable after manual verification), add to the whitelist (no more repeated alarms for known intermittent abnormalities), initiate an approval process (requires on-site review or device replacement), or ignore directly (confirmed as a false alarm), thereby realizing full-process management from abnormal identification to processing.

[0082] Model Autoregressive Optimization Weekly, confirmed anomaly and false alarm data are regularly extracted from the database to perform model optimization: First, a genetic algorithm is used to search and optimize key thresholds in the business layer rules (including the reading imbalance threshold of 0.03, the stop current threshold of 0.1A, the flyaway coefficient of 1.2, the anomaly reduction amount threshold of 1000 yuan for residents and 10000 yuan for non-residents, the timeliness threshold of power outage events of 30 minutes, etc.). The fitness function is defined as F = precision + recall - 0.5 × false alarm rate. After 100 generations of iteration through selection, crossover, and mutation operations, the optimal threshold combination is output and the rule base is updated; then, the historical... Whether a device is confirmed as faulty is labeled (1 for fault, 0 for non-fault). Each fault factor is used as a feature, and the importance of the features is calculated using the random forest algorithm. The feature importance is normalized and used as the new weight w_i. Factors with importance below 0.01 are removed. At the same time, the information of newly confirmed faulty devices (including factor vectors) is added to the fault case library to achieve incremental updates of the knowledge base. Finally, a model evaluation report is generated weekly, including verification accuracy, recall, false positive rate, fault factor hit rate, and anomaly closure rate. If the accuracy drops by more than 2% for two consecutive weeks, retraining is automatically triggered.

[0083] Visualization and monitoring Develop a data quality monitoring dashboard that displays in real time the current data acquisition channel's pass rate, anomaly rate, and number of fault factor triggers. It also provides rankings and trend charts by manufacturer, protocol version, power supply unit, and anomaly type, as well as accuracy comparison curves before and after model optimization (weekly / monthly), anomaly data closed-loop processing rate (processed / total), and a histogram of fault factor matching degree distribution. The dashboard supports drill-down query functionality; users can click on any anomaly type to view detailed data, and click on detailed data to view the corresponding meter's file information, historical anomaly records, original messages, and fault factor score details, providing maintenance personnel with an intuitive and traceable data quality analysis tool.

[0084] This embodiment employs a three-layer joint verification system—source code layer, business layer, and fault factor layer—to not only verify the compliance of the specification format but also integrate power business logic and historical fault patterns, significantly reducing false alarms and missed alarms. Pre-verification based on stream computing enables quality assessment to be completed immediately upon data acquisition, with a verification latency of less than one minute. By dynamically adjusting rule thresholds and fault factor weights through genetic algorithms and random forests, the model possesses self-learning and self-optimization capabilities, adapting to equipment updates and business changes, avoiding the lag of manual rule base maintenance. Fault factor scores can intuitively display the causes of anomalies (e.g., "Clock deviation factor matching degree 0.8, clock check recommended"), assisting maintenance personnel in quickly locating problems. This achieves a shift from "arbitrary replacement" to "on-demand replacement," reducing daily on-site troubleshooting workload and saving significant manpower and material costs annually. The abnormal data list is automatically pushed to the work order system, allowing business personnel to complete the entire process of identification, approval, and processing, effectively improving the efficiency of data quality governance.

[0085] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any brief modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for automatic identification and verification of abnormal data in electricity meter reading, characterized in that: Includes the following steps: S1. Receive raw data frames sent by the acquisition terminal or electricity meter in real time, extract the frame start and end characters, frame length, frame checksum, sequence number, transmission direction bit and terminal address, determine whether the extracted features are consistent with the protocol requirements, and mark inconsistent data as protocol layer anomalies. S2. Extract daily frozen energy readings, tariff values, remaining amount, number of electricity purchases, and power outage / once events from the normal data at the protocol layer. Perform tariff missing item judgment, reading imbalance judgment, meter stop judgment, meter fly-away judgment, meter reverse judgment, remaining amount sudden change judgment, and timeliness and validity judgment of power outage / once events to obtain the abnormal data set at the business layer. S3. The fault factor algorithm composed of singular value decomposition and linear regression is used to perform cluster analysis on the abnormal data of the business layer, calculate the deviation between the cluster center of each type of anomaly and the historical fault mode threshold, and classify the data with deviation exceeding the specified range into a high-risk abnormal data subset. S4. Extract the equipment manufacturers, models, software and hardware versions and terminal addresses from the high-risk abnormal data subset, search for similar historical fault records in the fault case database, calculate the matching degree, and obtain the equipment self-inspection report by issuing a penetration meter reading command through the electricity information collection system. S5. Parse the terminal address, clock information, event counter and communication status word in the device self-test report, determine the specific fault type according to the protocol layer verification rules, and retrieve the corresponding repair protocol from the fault handling database; S6. Execute automated scripts through remote communication networks to send repair protocols to data acquisition terminals or electricity meters, including remote time synchronization, parameter correction, terminal restart, or event buffer clearing, and record the updated device status after repair.

2. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S1 specifically includes: S11. The raw data frames are continuously acquired and stored in the buffer through the interface of the acquisition terminal and the energy meter. The frame start symbol and end symbol are extracted frame by frame using the state machine scanning mechanism. The theoretical number of bytes is calculated according to the frame length field, and a complete single frame data unit is extracted. S12. Parse the frame length, frame checksum, sequence number, transmission direction bit and terminal address from a single frame data unit. If the frame length does not match, mark it as a structural anomaly. If the frame checksum verification fails, mark it as an integrity anomaly. Obtain the preliminary anomaly judgment result. S13. Check whether the transmission direction bit and terminal address conform to the preset protocol standard. If they do not conform, mark them as compliance anomalies. Integrate all anomaly markers to generate anomaly data records and store them in the anomaly log library. Use support vector machine to perform pattern analysis on the anomaly data archive, extract the regular characteristics of anomaly occurrence, and determine the potential association patterns of anomaly data frames.

3. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S2 specifically includes: S21. Obtain daily frozen energy readings, tariff values, remaining amount, number of electricity purchases, and power outage / once events through the protocol layer interface, construct an initial dataset, and perform data integrity and format consistency cleaning to obtain a preliminarily cleaned dataset. S22. Perform rate missing item detection on the cleaned data set, mark the data with missing or incomplete rate values ​​as a rate abnormal subset, and then analyze the reading imbalance problem in combination with the daily frozen energy reading. If the correspondence between the daily frozen energy reading and the rate value deviates from the preset threshold, it is determined to be an reading imbalance abnormality, and the reading abnormal subset is obtained. S23. Use the abnormal subset of readings and historical data of daily frozen energy readings to detect the problem of meter stopping and running away. Mark the data where the daily frozen energy reading does not change or changes beyond the preset range within a continuous time period as an abnormal stop or run, and generate a subset of meter operation abnormalities. Then, use the subset of meter operation abnormalities to determine the problem of meter running backwards. Mark the data where the daily frozen energy reading decreases and there is no reasonable electricity purchase record associated with it as a reverse running abnormality, and obtain the subset of reverse running abnormalities. S24. To address the issue of sudden changes in the amount of the reverse flow abnormal subset and the remaining amount data analysis, data with short-term large fluctuations in the remaining amount and no corresponding records of electricity purchases are identified as abnormal amount changes, generating an abnormal amount subset. Then, based on the abnormal amount subset and the power outage / once event data, the timeliness of the events is detected. Data with a time difference between the recorded time of the power outage / once event and the actual abnormal time of the electricity meter operation exceeding a preset threshold are marked as timeliness anomalies, resulting in the final set of abnormal data at the business layer.

4. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S3 specifically includes: S31. Obtain time-series abnormal data from the abnormal data set of the business layer, use the singular value decomposition algorithm to decompose the time-series abnormal data to obtain the decomposition quantity, and perform cluster analysis based on the decomposition quantity to determine the cluster center of each type of abnormality. S32. Obtain the historical threshold corresponding to the historical fault mode, and use the linear regression algorithm to calculate the deviation between the cluster center of each type of anomaly and the historical threshold to obtain the deviation calculation result. S33. Compare the deviation calculation result with the specified range. If the deviation value exceeds the specified range, the abnormal data corresponding to the cluster center is classified as a high-risk abnormal data subset.

5. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 4, characterized in that: The singular value decomposition algorithm is used to decompose the time-series anomaly data, including: concatenating the time-series anomaly vectors of all devices into the original data matrix and centering it, then performing singular value decomposition to obtain singular values ​​as decomposition quantities, retaining the left singular vectors corresponding to the first r largest singular values, using each row as the coordinates of the sample points after dimensionality reduction, and finally obtaining the cluster centers of various anomalies through K-means clustering.

6. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S4 specifically includes: S41. Extract equipment manufacturers, equipment models, software versions, hardware versions and terminal addresses from the high-risk abnormal data subset and perform structured processing. Then, compare them with the pre-established fault case library in multiple dimensions, use the cosine similarity algorithm to calculate the degree of matching with historical cases, and determine the set of similar fault records. S42. Extract fault modes and terminal address information from the set of similar fault records. Determine the potential fault type by comparing the common features of the current abnormal data with the historical fault records. If the potential fault type is highly correlated with historical cases, send a penetrating meter reading command to the corresponding terminal address through the electricity information collection system to obtain the real-time self-test report data of the equipment. S43. Based on the acquired equipment self-inspection report data, perform automated comparison and analysis with the solution information in the historical fault records to determine whether the current equipment status conforms to the known fault mode, and generate fault troubleshooting guidance based on the equipment status analysis results, and store the guidance information in association with the self-inspection report data.

7. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S5 specifically includes: S51. Extract the terminal address, clock information, event counter and communication status word from the device self-test report. Use the preset protocol verification rules to check the legality of the terminal address and communication status word. If the field value exceeds the preset range, it is judged as an abnormal communication state and an abnormality mark is output. S52. Based on the anomaly identifier, combined with the clock information and the recorded value of the event counter, compare the timestamp and event frequency of the historical data to determine the timing deviation or counting anomaly. Match the corresponding fault type code according to the fault type classification table to generate the fault classification result. S53. Based on the fault classification results, retrieve the corresponding repair protocol and repair instruction set from the fault handling database, generate equipment adjustment parameters and send them to the target terminal address, record the sending log, and if the execution feedback does not match the expectations, mark it as an execution exception and output an exception report.

8. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Step S6 specifically includes: S61. Obtain the set of terminal addresses to be repaired and the corresponding repair instruction type, match the repair instruction type from the instruction set, and generate a complete instruction sequence containing specific parameters from the preset instruction template library according to the instruction type. If the instruction is a time synchronization instruction or a parameter correction instruction, obtain the standard time source or standard parameter value from the system and embed it into the instruction sequence. S62. The complete instruction sequence is sent to the target terminal address through a polling mechanism via a remote communication network. A listening process is started to obtain the feedback value returned by the target terminal from the communication network. The instruction execution status is determined by comparing the feedback value with the expected result of the instruction. S63. Update the device status record according to the instruction execution status. If the status record shows that the execution failed, trigger the preset backup instruction sequence or mark it as manual processing according to the failure type, and record the device status update after repair.

9. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 1, characterized in that: Also includes: S7. Use a streaming computing framework to perform real-time verification of the data re-collected by the repaired acquisition terminal or electricity meter. After confirming that the data quality has returned to normal, integrate the quality indicators into the power grid operation decision module, and use a genetic algorithm to perform regression verification and optimization of the verification rule coefficients.

10. The method for automatic identification and verification of abnormal electricity meter reading data according to claim 9, characterized in that: Step S7 specifically includes: S71. A streaming computing framework is used to process and preliminarily screen the data re-collected by the repaired acquisition terminal or electricity meter in real time. A real-time verification mechanism is used to perform deep detection on the data stream. If missing or abnormal values ​​are detected, the automatic completion logic is triggered to obtain a completed data stream that meets the preset standards. S72. Calculate various data quality indicators and evaluate stability based on the completed data stream. Integrate the quality indicators into the power grid operation decision module for classified storage and decision-making needs judgment, and record the fluctuation of the indicators. S73. Use a genetic algorithm to perform regression analysis on the coefficients of the verification rules to obtain an optimized set of coefficients, update the verification rules and perform verification, adjust the input parameters of the power grid operation decision module based on more accurate quality assessment results, and confirm that the data quality has returned to normal.

Images