Method and system for verifying reliability of remote acquisition data of electric meter box

Abstract

The invention discloses a method and a system for verifying the reliability of remotely acquired data of an electric meter box, particularly relates to the technical field of communication and data transmission, and aims to solve the problem that the reliability of the remotely acquired data of the electric meter box is verified without changing an existing netmeter and a communication protocol. The invention aims to solve the problem of how to execute cross-layer reviewable reliability verification and quantitative credibility evaluation on a single reading result remotely acquired by an electric meter box so as to identify and eliminate the abnormity that communication is successful but data is not credible in real time, and support source end positioning. By introducing fusion of a cross-layer evidence set and an active detection mechanism, the credibility of each copying and reading result can be comprehensively evaluated. Multi-level data of a physical layer, a link layer, an application layer and the like are verified, and data exception is identified through active detection. Through the mechanisms, the method can effectively eliminate reading results which succeed in communication but have errors in actual data, thereby ensuring that the collected data are more reliable and accurately reflect the actual state of the electric meter.

Description

Technical Field

[0001] This invention relates to the field of communication and data transmission technology, specifically to a method and system for verifying the reliability of remote data acquisition from an electricity meter box. Background Technology

[0002] Existing remote data acquisition systems for electricity meters typically rely on physical layer (e.g., signal strength, noise ratio) and data link layer (e.g., data packet success rate) checks to determine successful data transmission. However, while this method ensures smooth data packet transmission, it doesn't consider the reliability of the data itself. Even with successful communication, factors such as meter hardware failure, software issues, or inconsistent data field formats can still lead to inaccurate data. For example, meter data may be corrupted during communication, but these problems may not be detected by conventional data link layer checks (e.g., CRC). Traditional systems cannot effectively identify situations where "communication is successful but the data content is unreliable," resulting in incorrect billing or statistical errors and increasing the complexity of system maintenance and troubleshooting.

[0003] Existing technologies typically only perform simple verification at the physical and data link layers, lacking in-depth verification of application layer data. For example, voltage and current data from an electricity meter should follow certain physical relationships; abnormal values ​​in certain fields may indicate data problems. However, traditional systems can usually only perform simple data integrity checks and cannot effectively identify these anomalies. Existing methods rely on a single data source (such as packet integrity verification) and cannot comprehensively judge multiple possible anomalies. Even with good signal quality, the data itself may be erroneous due to equipment failure, timing issues, or other external factors. Therefore, the verification capabilities of existing systems are quite limited and cannot provide reliable data quality assurance.

[0004] This limitation leads to unreliability issues during data acquisition. Traditional methods cannot detect and eliminate situations where "communication is successful but the data is unreliable" in real time, and when data anomalies occur, the system cannot accurately pinpoint the root cause (whether it's a communication link problem, equipment hardware failure, or data acquisition software malfunction). Therefore, data quality assurance relies on simple error detection mechanisms, and there is no effective way to diagnose and repair potential problems. Current systems lack cross-layer verification and multi-evidence support, resulting in low efficiency in data anomaly detection and troubleshooting. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a method and system for verifying the reliability of remote data acquisition from electricity meter boxes. By collecting and integrating cross-layer evidence from the physical, link, and application layers, it identifies and eliminates anomalies where communication is successful but the data is unreliable in real time. Through multi-layer verification of signal quality, field integrity, and business logic consistency, it ensures that each data reading result is both successfully transmitted and highly reliable, thereby solving the problems mentioned in the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for verifying the reliability of remote data acquisition from an electricity meter box, comprising: S1. Synchronize the time base and register a single copying task, and collect a cross-layer evidence set, which includes channel quality parameters, protocol fingerprint, payload field and device event flag; S2. Perform monotonicity and constraint checks on the specification fingerprint and load fields to generate suspicious flags; S3. When a suspicious marker is present, trigger active detection to obtain the difference vector associated with this copying. The active detection includes at least one of repeated read consistency, field order perturbation, light load handshake and loopback delay measurement. S4. Based on the cross-layer evidence set and difference vector, perform fusion evaluation, output numerical credibility and complete the classification; S5. Based on the hierarchical execution of supplementary data collection and communication mode switching, determine the final data value of this data reading; S6. Generate an evidence package containing evidence summary, probe logs, and credibility, protect its integrity, and upload it. At the same time, locate and handle the source based on the evidence.

[0007] In a preferred embodiment, S1 includes: Before starting the data collection, perform time base synchronization, register the single-transfer task identifier, and start the current data collection session; Read the channel quality parameters sequentially, including signal-to-noise ratio, received signal strength indication, hybrid automatic repeat count, round-trip time delay, and cyclic redundancy check results; Parse the protocol fingerprint, which includes frame sequence number, timestamp, random number or handshake factor and synchronization identifier; Parse the load fields, including cumulative energy consumption, phase voltage, phase current, power factor, and demand; Read device event flags, including those for opening the cover, power failure, exceeding temperature limits, and port reset. Write the above items into the evidence set according to the task identifier and unified time benchmark, and then end this step.

[0008] In a preferred embodiment, S2 includes: Monotonicity and constraint checks are performed on the specification fingerprint and payload fields, including: first parsing the specification fingerprint, and then establishing a check queue based on frame number, timestamp, random factor and handshake identifier; Then, the frame sequence number increment verification, timestamp order verification, random factor freshness verification, and handshake identifier consistency verification are completed in sequence. Then, perform field integrity checks, type and encoding format verification, unit identifier consistency verification, cross-field constraint comparison, and cross-period monotonicity comparison on the load field in sequence. Finally, if any verification fails to meet the preset rules, a suspicious flag is generated and archived in this copying record.

[0009] In a preferred embodiment, S3 includes: When a suspicious marker is found, the detection and control unit is set to execute the probe sequence in sequence: repeat read consistency probe, issue the same read command twice, record the two return frames, and the comparison unit compares them item by item according to the field index; The field order perturbation probe adjusts the field reading order for the same read command, sends and records the return frame, and compares the re-imaged field position with the baseline frame. Lightweight handshake probes only initiate the handshake process and record handshake elements and sequence numbers. The loopback delay measurement probe sends a loopback request, records the transmit and receive times, and calculates the round-trip difference. The result recording unit encodes the comparison results of each probe and summarizes them into a difference vector associated with the copying.

[0010] In a preferred embodiment, S4 includes: The cross-layer evidence set and the difference vector are input into the feature standardization unit to generate a unified feature vector; The feature vector is sent to the rule verification unit to perform consistency determination of sequence number, time base and field constraints and output the tag vector; When the verification is passed or a non-fatal marker exists, the unified feature vector and the marker vector are concatenated and sent to the fusion calculation unit to calculate the numerical credibility according to the preset weights and the combined model. The credibility input is compared with the threshold set to generate a level identifier; The results output unit outputs a rating record containing credibility and level identifiers.

[0011] In a preferred embodiment, S5 includes: Based on the classification results, confirmation is performed for Class A, and supplementary sampling is performed for Class B according to the retry parameters. If it fails, the steady-state parameter set is loaded and supplementary sampling is performed again. If it still fails, supplementary sampling is performed according to the system switching sequence. For Level C, supplementary sampling is performed directly into the standard switching sequence, and the candidate selection is based on a preset sorting and priority. When multiple candidates are obtained for the same communication standard, one is selected according to a preset sorting table; After outputting the final result, select multiple communication standards and choose the return value.

[0012] In a preferred embodiment, S6 includes: After the classification is completed, the evidence packaging process is initiated: cross-layer evidence summaries, key message indexes, probe logs, credibility and task identifiers are collected and the evidence objects are constructed in a fixed field order; Calculate the hash of the evidence object and attach a digital signature to generate a signed evidence package; The evidence packet is encapsulated into an application layer message and sent to the main station. After receiving it, the main station verifies and validates the signature, registers the time base and index and archives it. After archiving, it calls the source end positioning rule set, compares the link characteristics, protocol fingerprint and detection results according to the preset decision order, and generates a positioning conclusion. Based on the location conclusion, a set of disposal instructions is generated and a backtracking identifier is recorded. The disposal instructions are then sent to the data collection side and the execution status is written back.

[0013] In a preferred embodiment, the communication standard switching is performed according to a preset priority order, which is power line carrier supplementary sampling, serial bus relay supplementary sampling, and cellular standard supplementary sampling in sequence. Each system completes one supplementary sampling and result registration before moving on to the next system.

[0014] In a preferred embodiment, the evidence package adopts a partitioned frame structure and is generated in a fixed order, namely: evidence header field area, evidence digest area, probe log area, scoring record area, and signature area. Calculate the hash of all fields except the signature area and write them into the signature area. Then encapsulate them into an application layer message and send it up in the order described.

[0015] On the other hand, the present invention provides a reliability verification system for remote data acquisition from an electricity meter box, comprising: The time base synchronization and task registration module synchronizes the time base and registers a single copying task, collects cross-layer evidence sets, including channel quality parameters, protocol fingerprints, payload fields and device event flags, ensures task identification and time synchronization, and starts data acquisition; The data verification and tag generation module performs monotonicity and constraint verification on the specification fingerprint and payload fields, generates suspicious tags, and is responsible for checking the consistency of frame sequence number, timestamp, random factor, etc., and marking it as suspicious when an anomaly is found; The active detection and difference vector generation module triggers active detection when a suspicious marker is found, obtains the difference vector associated with this copying, performs different types of detection, and generates difference vectors to help further confirm the credibility of the data; The credibility assessment and grading module performs a fusion assessment based on cross-layer evidence sets and difference vectors, outputs numerical credibility and completes the grading, and generates credibility scores by combining feature standardization and rule verification and grading according to set thresholds. The supplementary data acquisition and standard switching module performs supplementary data acquisition and communication standard switching based on the classification results, determines the final data value, and executes the corresponding supplementary data acquisition or switching strategy according to the reliability classification to ensure the accuracy of the final result. The evidence package generation and source location module generates an evidence package containing evidence summary, probe logs, and credibility, protects its integrity, and uploads it. At the same time, it performs source location and processing based on the evidence to ensure data integrity and improve data reliability through source location and processing decisions.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. By introducing cross-layer evidence set fusion and active detection mechanisms, the reliability of each data reading from the meter box can be verified in real time and comprehensively. Through active detection mechanisms, such as repeatability checks, field order perturbation, and latency measurement, not only is data transmission integrity ensured, but potential anomalies in the meter data are also detected through dynamic verification, ensuring the accuracy and reliability of the final collected data. This effectively solves the problem of traditional methods relying on single-link layer verification and neglecting application layer data consistency and logical verification, thereby greatly improving the reliability and accuracy of meter data collection.

[0017] 2. By generating detailed evidence packages and protecting their integrity, and by locating the source of the anomaly based on the evidence, the system can quickly identify the source of the anomaly. Whether it's a communication link problem, a meter hardware failure, or a software problem during data acquisition, the detailed records and source location functions provided by the evidence package can accurately trace the issue, significantly improving the efficiency of troubleshooting. This effectively solves the problem of not being able to accurately locate the source of the fault when data anomalies occur, avoiding the troubleshooting delays caused by the lack of source location in traditional methods. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the reliability verification method for remote data acquisition from an electricity meter box according to the present invention. Figure 2 This is a schematic diagram of the structure of a remote data acquisition reliability verification system for an electric meter box according to the present invention. Detailed Implementation

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

[0020] Example 1: Figure 1 This invention provides a method for verifying the reliability of remotely acquired data from an electricity meter box. The method is characterized by comprising: S1. Synchronize the time base and register a single copying task, and collect a cross-layer evidence set, which includes channel quality parameters, protocol fingerprint, payload field and device event flag; S2. Perform monotonicity and constraint checks on the specification fingerprint and load fields to generate suspicious flags; S3. When a suspicious marker is present, trigger active detection to obtain the difference vector associated with this copying. The active detection includes at least one of repeated read consistency, field order perturbation, light load handshake and loopback delay measurement. S4. Based on the cross-layer evidence set and difference vector, perform fusion evaluation, output numerical credibility and complete the classification; S5. Based on the hierarchical execution of supplementary data collection and communication mode switching, determine the final data value of this data reading; S6. Generate an evidence package containing evidence summary, probe logs, and credibility, protect its integrity, and upload it. At the same time, locate and handle the source based on the evidence.

[0021] The technical connections and implementation logic of the six steps are as follows: First, in step S1, the system synchronizes the time base and registers the single copying task, while simultaneously collecting a cross-layer evidence set, including channel quality parameters, protocol fingerprints, payload fields, and device event flags. Next, step S2 performs monotonicity and constraint checks on the collected protocol fingerprints and payload fields. If the checks fail, a suspicious flag is generated, indicating potential data anomalies. In step S3, when a suspicious flag exists, an active probing process is triggered. Active probing uses any one of the following methods—repeated read consistency, field order perturbation, light-load handshake, or loopback delay measurement—to obtain the difference vector associated with the current copying task. Step 4 involves fusion evaluation based on the collected cross-layer evidence set and difference vectors, generating numerical credibility and completing the classification, and outputting the results to subsequent steps for further processing. In step S5, based on the classification of the evaluation results, the system performs supplementary data collection or switches the communication mode to finally determine the final data value of this reading, ensuring the accuracy and reliability of the data. Finally, in step S6, the system generates an evidence package containing evidence summary, probe log, and credibility, and sends it to the main station after protecting its integrity. At the same time, source location and processing are performed based on the evidence to ensure data traceability and processing accuracy.

[0022] S1. Synchronize the time base and register a single copying task, and collect a cross-layer evidence set. The evidence set includes channel quality parameters, protocol fingerprint, payload field, and device event flags. Specifically, the implementation is as follows: Before initiating data acquisition, time base synchronization is performed to register the single-transfer task identifier and start the current acquisition session. Before starting acquisition, the time base synchronization process is executed first. Input data includes the system's local clock and external synchronization signals (such as NTP, GPS signals, etc.). The system adjusts its local clock using a standard time base synchronization algorithm (such as IEEE1588 or PTP) to ensure that the system time is aligned with the external time base. The time base synchronization process includes: receiving the external time signal, calculating the time difference, and adjusting the local clock to ensure that the time error does not exceed 1 millisecond. The output is the synchronized local clock time, ensuring that the timestamps of all acquired data are consistent. If synchronization fails, the system will use a retry mechanism or switch to a backup synchronization signal source (such as GPS signal) until time base synchronization is successful. In terms of performance requirements, the time base synchronization completion time should be less than 100 milliseconds to ensure real-time performance. Verification includes multiple tests to ensure the accuracy and stability of synchronization, verifying that the time base synchronization error is controlled within the allowable range.

[0023] Next, the task identification registration and data collection session begins. Input data includes task type, device identifier, start and end times of data collection, etc. The system generates a unique task ID and registers this information in the database or log. The task identifier is associated with the synchronized timestamp to ensure the uniqueness and traceability of the data collection task. The output is the successfully registered task identifier, which is associated with subsequent data collection processes. If task registration fails, the system will ensure accurate registration of task information through a retry mechanism or a backup identifier generation method.

[0024] The system sequentially reads channel quality parameters, including signal-to-noise ratio (SNR), received signal strength indication (RSRP), hybrid automatic repeat count (HARQ), round-trip time (RTT), and cyclic redundancy check (CRC) results. After completing time base synchronization and task registration, the system sequentially reads channel quality parameters, including SNR, Received Signal Strength Indicator (RSRP), Hybrid Automatic Repeat Count (HARQ), Round-Trip Time (RTT), and Cyclic Redundancy Check (CRC) results. The reading process acquires data through the communication interface between the data collector and the meter (such as PLC, NB-IoT, or RS5 communication). The algorithms used include standard channel quality assessment algorithms; for example, the SNR calculation formula is:

[0025] Each channel quality parameter is read sequentially and stored in memory or a database. If any channel quality parameter read fails, the system will recover by rereading or using an alternative communication path to ensure data integrity and accuracy. Performance requirements include: the response time for each read process should be less than 50 milliseconds to ensure real-time performance and efficiency. The system should also have fault tolerance for low signal quality or communication interruptions, such as restoring the connection by automatically switching communication paths or adjusting parameters.

[0026] The protocol fingerprint is parsed, including the frame sequence number, timestamp, random number or handshake factor, and synchronization identifier. The system then parses the protocol fingerprint, including the frame sequence number, timestamp, random number or handshake factor, and synchronization identifier. The parsing process parses the data frame header information according to the protocol (such as DL / T645 or MODBUS), verifying the incrementing frame sequence number, timestamp consistency, uniqueness of the random factor, and the synchronization identifier of the handshake factor. Relevant formulas include: If timestamp increment verification fails, the data is marked as suspicious. The output is the successfully parsed protocol fingerprint, stored in the evidence set corresponding to the task identifier. If protocol fingerprint parsing fails, the system records the error information and triggers re-parsing or parsing of a backup protocol to ensure data transmission integrity. The parsing process should be completed within 100 milliseconds to ensure data processing efficiency.

[0027] The system parses load fields, including cumulative energy consumption, phase voltage, phase current, power factor, and demand. Next, the system parses load fields, including cumulative energy consumption, phase voltage, phase current, power factor, and demand. Load field parsing is performed by a parser that analyzes the data content according to the protocol format, verifying the validity and consistency of each field. For example, the formula for calculating the power factor is: The system reads and verifies the correctness of these data fields. If the verification passes, the parsing result is stored in the evidence set. Anomaly handling includes: if a field is parsed incorrectly or the format is mismatched, the system automatically marks the field as invalid and performs error correction, such as re-collecting data or supplementing it with default values. The output is the parsed payload field data, recorded in the task evidence set. The performance requirement is that the parsing and verification of payload fields should be completed within 200 milliseconds to ensure real-time feedback.

[0028] Read device event flags, including those for lid opening, power failure, temperature exceeding limits, and port reset. During the read process, the system acquires and parses device status information such as lid opening, power failure, temperature exceeding limits, and port reset. These flags are obtained through device sensors or status interfaces and stored in the task data. If a device event read fails, the system checks the device status interface or sensors using a verification mechanism and recovers through a retry mechanism or backup status signal. The output is the real-time status of each device event flag, ensuring the integrity of the task evidence. The read process should be completed within 100 milliseconds to ensure no impact on system real-time performance.

[0029] Write all the above items into the evidence set according to the task identifier and unified time reference, and then end this step. Finally, after all information collection is completed, the system writes all data into the evidence set and stores it according to the task identifier and unified time reference. All data items (channel quality parameters, protocol fingerprints, payload fields, device event flags) are saved in a fixed format (such as JSON, XML, etc.) to ensure that the data structure is clear and easy to query and process later. The data structure includes task ID, timestamp, parameter values, and status flags. The output is a complete evidence set containing all collected data, written to the database or storage system, and the execution of this step ends. If data storage fails, the system will automatically trigger error log recording and re-storage. Performance requirements include that the processing time of each task should be less than 200 milliseconds to ensure that the data collection process is efficient and real-time. The storage system should support parallel data processing, support at least 1000 tasks per second, and ensure the integrity and consistency of data storage.

[0030] S2. Perform monotonicity and constraint checks on the specification fingerprint and load fields to generate suspicious flags. The specific implementation is as follows: Monotonicity and constraint checks are performed on the protocol fingerprint and payload fields, including: first, parsing the protocol fingerprint and establishing a check queue based on frame number, timestamp, random factor, and handshake identifier. When performing monotonicity and constraint checks on the protocol fingerprint and payload fields, the system first needs to parse the protocol fingerprint, including fields such as frame number, timestamp, random factor, and handshake identifier. Input data comes from communication protocol data packets from the meter device or data collector, typically transmitted in binary or JSON format, containing this key information. The parsing process receives data through a communication interface (such as PLC, NB-IoT, RS-485), uses a protocol parser to parse the data frame header, and extracts the frame number, timestamp, random factor, and handshake identifier into a check queue. The algorithm used in this process includes frame number increment check, with the formula: The formula for verifying the order of timestamps is: The formula for random factor verification is: The handshake identifier consistency check is as follows: If any field fails to meet these rules, the system immediately generates a suspicious flag. The output is the parsed protocol fingerprint data, which is recorded in the database for subsequent verification.

[0031] Subsequently, the system sequentially performs frame sequence number increment verification, timestamp order verification, random factor freshness verification, and handshake identifier consistency verification. Next, the system performs item-by-item verification on the parsed protocol fingerprint. First, it performs frame sequence number increment verification to ensure that the sequence number of each frame strictly increments. If reverse order or frame loss is found, the system marks it as suspicious and records the abnormal data for subsequent processing. Then, the system performs timestamp order verification to ensure that the timestamp of each data packet increments, avoiding clock backtracking. If the timestamp backtracks, a suspicious flag is immediately generated, indicating a time synchronization problem. Next, it performs random factor freshness verification to ensure that the random factor of each data packet is unique and conforms to protocol requirements; if it is duplicated or incorrect, a suspicious flag is generated. The handshake identifier consistency verification ensures that the identifier during the handshake process is unique within the communication cycle; if the identifier is abnormal, a suspicious flag is also generated. All these verifications are performed through logical condition judgment and according to preset rules to validate each field. If any verification fails, a suspicious flag is generated, indicating a data problem. The results of each verification are stored in logs or a database for subsequent auditing and data analysis.

[0032] Next, the load fields undergo sequential checks: field integrity, type and encoding format verification, unit identifier consistency verification, cross-field constraint comparison, and cross-cycle monotonicity comparison. After completing the protocol fingerprint verification, the system further verifies the load fields. Load fields include cumulative energy consumption, phase voltage, phase current, power factor, and demand, with input data being real-time data collected by the meter equipment. First, the system performs a field integrity check to ensure that each field exists and conforms to the protocol format. If a field is missing or its format is incorrect, the system marks it as invalid and triggers a re-acquisition command. Next, type and encoding format verification is performed to verify whether the data type (e.g., floating decimal, integer) and encoding format (e.g., BCD, hexadecimal) of each field conform to the preset standards. If the field data type or encoding format does not match, a suspicious flag is generated. Unit identifier consistency verification follows immediately to ensure that the units of voltage and current are consistent (e.g., volts, amperes). If the units do not match, the system marks it as abnormal and generates a warning. Next, cross-field constraint comparisons are performed. For example, the product of current and voltage should conform to the physical constraints of the power factor. If this relationship does not hold, the data is marked as abnormal, indicating a possible acquisition error. Finally, cross-period monotonicity comparisons check the changing trends of fields such as cumulative energy and power factor to ensure that the data increases monotonically or conforms to physical logic across multiple acquisition periods. If the data shows negative changes or violates physical rules, a suspicious flag is also generated.

[0033] Finally, if any verification fails to meet the preset rules, a suspicious flag is generated and archived in the current data collection record. After all these verifications are completed, the system will return the final result. If all verification items pass, the data will continue to the credibility assessment and repair phase. If any verification fails, the system will immediately generate a suspicious flag and archive the data in the current data collection record for subsequent analysis and repair. Abnormal data will be marked as "pending review" and an alert will be sent to the operations and maintenance personnel, requiring manual review. To ensure the timeliness of data processing, each data verification and processing by the system should be completed within 200 milliseconds and be able to maintain stable operation under high load. Data storage uses a relational database, and all data (including verification results, flags, timestamps, etc.) is indexed by task ID and timestamp for easy subsequent querying and analysis. The system also has a fault tolerance mechanism; for example, if a verification item fails multiple times consecutively, the system will automatically switch to a backup data source for supplementary collection to ensure that the collection task is not hindered.

[0034] S3. When a suspicious marker is present, trigger active detection to obtain the difference vector associated with the current copying. The active detection includes at least one of repeated read consistency, field order perturbation, light-load handshake, and loopback delay measurement. Specifically, the implementation is as follows: When suspicious markers are present, the detection control unit executes a probe sequence sequentially: a repeated read consistency probe, which sends the same read command twice, recording two return frames. The comparison unit then compares the results item by item according to the field index. When suspicious markers are present, the system verifies data reliability by executing the probe sequence sequentially through the detection control unit. Input data includes previously generated suspicious markers, task identifiers, channel quality parameters, device status, and other relevant information that may affect data accuracy. The system first executes the repeated read consistency probe by sending the same read command twice to the device, recording two return frames. Each return frame contains field index information, and the system compares the field values ​​in these frames item by item through the comparison unit. If the field values ​​match, the verification passes; if any discrepancies exist, a difference vector is generated and the frame is marked as suspicious. The processing uses standard comparison algorithms, such as comparing the size and type of field values ​​item by item, and performs consistency verification using the following formula: If the verification fails, the system will trigger a retry mechanism, attempting a maximum of 3 times. The processing time for repeated read probes should not exceed 100 milliseconds to ensure the system's real-time performance. When the comparison fails, the read operation is re-executed, recovering via a backup communication path, with a maximum of 3 retries.

[0035] The field order perturbation probe adjusts the reading order of fields within the same read command, issues and records the returned frame, and compares the re-imaged field positions with the baseline frame. Next, the field order perturbation probe is executed. The system adjusts the reading order of fields within the same read command, reissues the command, and records the returned frame. During processing, the system re-images the field positions through the comparison unit and compares them with the baseline frame. If the field order is normal and the returned frame matches the baseline frame, the verification passes; if there are any inconsistencies, a difference vector is generated and marked as suspicious. The comparison algorithm is based on the field position index to ensure that each field is verified in the expected position. The execution time of the field order perturbation probe should be controlled within 150 milliseconds to ensure data real-time performance. If the comparison fails, the system will automatically attempt to reread and use a backup path for fault tolerance.

[0036] The lightweight handshake probe only initiates the handshake process and records handshake elements and sequence numbers. It does not read actual data, but records handshake elements and sequence numbers during the process. Input data includes handshake commands and handshake parameters from the protocol. The probe initiates a handshake request through the control unit and records the involved handshake identifiers, sequence numbers, and other information. Output is the sequence number of a successfully executed handshake. If inconsistencies in identifiers or sequence numbers are found during the handshake process, a difference vector is generated and the system is marked as suspicious. If the handshake fails or the identifier is incorrect, the system will retry and check if the communication protocol is normal. If it still fails, it is marked as a communication anomaly and a fault is reported.

[0037] The loopback delay measurement probe sends a loopback request, records the transmit and receive times, and calculates the round-trip time difference. Subsequently, the system executes the loopback delay measurement probe, sending a loopback request to the device. The input data includes the transmission timestamp and the loopback request. The system records the device's return time and calculates the round-trip time delay. The calculation uses the following formula to determine the difference between the transmission and reception times: If the latency exceeds a preset threshold (e.g., 100 milliseconds), a difference vector is generated and the data is marked as suspicious. When latency exceeds the limit, the system will attempt to reduce latency by resending the request or switching to an alternative path. The response time for latency measurement should be controlled within 80 milliseconds to ensure the system's sensitivity to network fluctuations.

[0038] The result recording unit encodes the comparison results of each probe and summarizes them into a difference vector associated with the current copying task. Finally, all detection results are encoded by the result recording unit and summarized into a difference vector associated with the current copying task. Input data includes the execution results and comparison data of all probes. The verification result of each probe is converted into a standard format (such as JSON or XML), and the difference vector is stored along with the task ID. The output is the generated difference vector, which will be archived in the current copying task record as a basis for subsequent decision-making and evaluation. Data storage includes fields such as difference vector, timestamp, task identifier, and probe type, and is stored in a standardized format (such as JSON) for easy subsequent querying and analysis. If difference vector generation fails, the system will log the failure and trigger a fault handling process to ensure data integrity. The record generation process is ensured to be no more than 200 milliseconds to guarantee real-time performance.

[0039] S4. Based on the cross-layer evidence set and difference vector, perform a fusion evaluation, output numerical confidence level and complete the classification. The specific implementation is as follows: The cross-layer evidence set and difference vectors are input into the feature standardization unit to generate a unified feature vector. First, the cross-layer evidence set and difference vectors are input into the feature standardization unit. Input data includes channel quality parameters, protocol fingerprints, payload fields, and device event flags collected from different layers (physical layer, link layer, and application layer), as well as difference vectors generated through probing. The task of the feature standardization unit is to transform this data into a unified standard format. The input data is first processed by its respective standardization algorithm to ensure that data from different sources remain consistent in numerical range, units, and precision; for example, all values ​​are normalized to between 0 and 1. This processing ensures that all data in the feature vector are on the same scale, facilitating subsequent combination calculations. The output is a unified standardized feature vector, which is convenient for subsequent fusion calculations and evaluations. If the format of the input data does not meet the preset requirements, the system will automatically trigger a data re-acquisition or correction step to ensure that all input data conforms to the expected format. The entire feature standardization process should be completed within 50 milliseconds to ensure the system's real-time response capability.

[0040] The feature vector is fed into the rule verification unit to perform consistency checks on the sequence number, time base, and field constraints, and outputs a marker vector. Next, the standardized feature vector is fed into the rule verification unit. The input data is the standardized feature vector, and the rule verification unit performs a series of consistency checks on the data, including sequence number verification, time base consistency verification, and field constraint verification. Sequence number verification ensures that the frame sequence number of the data increases sequentially; time base consistency verification ensures that the timestamp increases according to a predetermined rule; and field constraint verification ensures that the field data conforms to a preset type and range. Each verification has a clear rule and formula, such as: the frame sequence number verification formula is "frame sequence number n > frame sequence number n-1", and the timestamp verification formula is "timestamp n > timestamp n-1". If all verifications pass, a marker vector is output, indicating that the data conforms to the rules. If inconsistencies are found during the verification process, the generated marker vector indicates which fields need further analysis or repair. If the verification fails, the system records the error and triggers a retry operation. If the verification still fails, the system marks the data as unusable and re-collects it. The verification process should be completed within 100 milliseconds to ensure real-time processing.

[0041] If the verification passes or a non-fatal marker exists, the unified feature vector and the marker vector are concatenated and sent to the fusion computing unit to calculate a numerical confidence score according to preset weights and a combined model. If the verification passes or a non-fatal marker exists, the standardized feature vector and the marker vector are concatenated and sent to the fusion computing unit. The fusion computing unit will calculate a numerical confidence score based on preset weights and a combined model. The preset combined model may be a weighted average, a support vector machine (SVM), or a decision tree model, depending on the weights of each feature. The formula for the weighted average is: in, It is the weight of the i-th feature. This is the standardized value of the i-th feature. The output is a confidence score, indicating the reliability of the data. If the input feature data is abnormal (e.g., the label vector is empty or the feature values ​​do not meet expectations), the system will automatically adjust the calculation model or use the default model to remedy the situation. For performance verification, the fusion computing unit should complete the calculation within 150 milliseconds to ensure stability under high concurrency.

[0042] The credibility score is input into the grading unit and compared with a threshold set to generate a grade identifier. Next, the credibility score is input into the grading unit for grade classification. The grading unit generates a grade identifier by comparing the credibility score with a preset threshold set. The specific grading formula is as follows: in, and This is a preset threshold. The system generates a level identifier based on the credibility score, indicating the reliability level of the data. The output is a level identifier indicating whether the data is credible. If the data is level B or C, the system will trigger supplementary sampling or repair operations. If the credibility value cannot be calculated or the grading fails, the system will use a backup algorithm or perform data repair according to a preset strategy. The performance requirement for grading determination is to complete within 200 milliseconds to ensure efficient real-time decision-making. The grading threshold set {T1, T2} is calibrated by ROC / Youden using labeled samples, initially set to T1=0.85 and T2=0.60; sites are recalibrated weekly (nearly 100,000 samples), and the default threshold for the entire network is used when the sample size is insufficient; the grading rules are A: Cred ≥ T1, B: T2 ≤ Cred <T1,C:Cred<T2。

[0043] The results output unit outputs scoring records containing credibility and level identifiers. Finally, the results output unit outputs the generated credibility score and level identifier and stores them as scoring records. These records include fields such as task ID, timestamp, credibility score, and level identifier, stored in JSON format to ensure data queryability and operability. The data structure includes: task ID, data source identifier, channel quality parameters, verification result, credibility score, and level identifier. All scoring records are stored in the database for easy subsequent querying and data analysis. If an anomaly occurs during storage, the system will automatically log and trigger a re-storage operation to ensure data integrity and consistency. The data storage structure uses a relational database, and important fields are indexed and optimized to support fast retrieval and querying.

[0044] S5. Based on the hierarchical execution of supplementary data collection and communication mode switching, determine the final data value for this data reading. The specific implementation is as follows: Based on the classification results, confirmation is performed for Level A data, and supplementary data acquisition is performed for Level B data according to the retry parameters. If the retry fails, the steady-state parameter set is loaded and supplementary data acquisition is performed again. If the retry still fails, supplementary data acquisition is performed according to the system switching sequence. First, the data is processed based on the classification results. When data is determined to be Level A, the system directly performs a confirmation operation. In this process, the input data includes the results from the reliability assessment and classification determination modules, specifically Level A identification data. The processing involves final verification of the data to ensure that all previous verifications and assessments have passed. The output result is data confirmation and storage in the final storage location, marked as reliable data. During the operation, if the data is Level A, the system will directly output the final result to ensure timely processing of high-reliability data. If an anomaly is found during verification, the system will mark the data as invalid and trigger a re-acquisition operation. This process should be completed within 50 milliseconds to ensure real-time performance.

[0045] For Class B data, the system will perform supplementary acquisition based on preset retry parameters. Input data includes Class B identifier data and retry parameters (such as maximum number of retries, retry interval, etc.). The processing involves performing a supplementary acquisition operation on the Class B data. If the supplementary acquisition succeeds, valid data is output; if it fails, a preset steady-state parameter set is loaded for another supplementary acquisition. The steady-state parameter set includes a fixed acquisition frequency, data verification rules, etc., helping the system to stably acquire data even under less than ideal communication conditions. If the supplementary acquisition still fails, the system will perform supplementary acquisition according to a preset standard switching sequence, trying different communication standards in turn. The output result is the data result after supplementary acquisition, or a failure flag based on the supplementary acquisition status. The operation process involves calling different communication standards (such as power line carrier, serial bus relay, cellular standards, etc.) for supplementary acquisition. If an anomaly occurs during the supplementary acquisition process, the system will automatically switch to a backup standard and retry. If the number of failed supplementary acquisitions exceeds a preset value, the system will automatically mark the data as unrecoverable and trigger an early warning. Each supplementary acquisition should be completed within 200 milliseconds to ensure timely data acquisition.

[0046] For Class C data, the system directly enters the standard switching sequence for supplementary data acquisition, selecting candidates according to a preset sorting and priority. Input data includes Class C identifier data. The processing involves supplementary acquisition according to a preset standard switching priority order, with the system sequentially attempting power line carrier, serial bus relay, and cellular standard supplementary acquisition. After each supplementary acquisition operation, the system records the result and selects the best candidate result according to a preset sorting table. The output result is the selected candidate result, which is stored as the final data. The operation process ensures that each communication standard completes one supplementary acquisition and records the result before proceeding to the next standard's supplementary acquisition.

[0047] When multiple candidates are obtained under the same communication standard, one is selected according to a preset sorting table. If the system obtains multiple candidate data under the same communication standard, it will select the optimal result according to the preset sorting table and priority, and output the final data. If supplementary acquisition for a certain standard fails, the system will try the next standard and mark it when the final supplementary acquisition fails. The standard switching process should not exceed 300 milliseconds after each supplementary acquisition operation to ensure the real-time performance and stability of data acquisition.

[0048] After outputting the final result, the system performs multi-communication standard selection and return value selection. During this process, the system needs to determine the final data output based on the previously selected communication standard and the supplementary data acquisition results. Input data includes the supplementary data acquisition results for each communication standard and their priority. The processing involves evaluating the supplementary data acquisition results for each standard and selecting the best data according to a preset sorting table and priority. For example, if the supplementary data acquisition result for the power line carrier standard is level C, the system will prioritize selecting the supplementary data acquisition result for the cellular standard. The output result is the finally selected supplementary data acquisition result, which is stored as the final data. The operation process involves comparing with historical data and network conditions to select the standard suitable for the current environment for supplementary data acquisition. If multiple standard supplementary data acquisitions fail, the system will enter fault recovery mode, recovering through backup standards or retry mechanisms. Standard selection and data return should be completed within 100 milliseconds to ensure rapid response.

[0049] S6. Generate an evidence package containing an evidence summary, probe logs, and credibility information; perform integrity protection and upload the package; simultaneously, locate and process the source based on the evidence. The specific implementation is as follows: After data grading is completed, the evidence packaging process is initiated: cross-layer evidence summaries, key message indexes, probe logs, credibility, and task identifiers are aggregated and arranged in a fixed field order to form an evidence object. First, after data grading is completed, the system initiates the evidence packaging process. Input data includes cross-layer evidence summaries, key message indexes, probe logs, credibility, and task identifiers. The cross-layer evidence summary contains signal quality data collected at each layer, device event flags, and probe results. The key message index marks important information during data collection and probe processes, and the probe log records various probe operations and their results. The task identifier includes the task ID, timestamp, and device information. This input data will be arranged in a fixed field order to form an evidence object. The structure of the evidence object can adopt a standard data format (such as JSON or XML), containing multiple areas such as an evidence header, evidence summary, probe log, scoring record, and signature area.

[0050] The process involves hashing the evidence objects and attaching a digital signature to generate a signed evidence package. This includes organizing the input data into evidence objects of a prescribed format and storing them according to a fixed field order. The process first involves gathering all evidence data and serializing it according to its content, ensuring that each field is arranged in order (e.g., evidence header field, evidence summary field, probe log field, scoring record field, signature field). Then, the hash calculation unit calculates the hash value for all fields except the signature field, ensuring data integrity and consistency. A common hash algorithm (such as SHA-256) is used to calculate the hash value of the data, as shown in the following formula: The hash value will be used in the subsequent signing and verification process. The generated hash value will be written into the signature area to ensure that the evidence data is not tampered with during transmission. Next, the digital signature unit digitally signs the evidence object based on the generated hash value and the private key, generating a signed evidence package. The digital signature uses a standard public-key encryption algorithm (such as RSA or ECC) to generate signature data by signing the hash value with the private key.

[0051] The output is a digitally signed evidence packet, which will be encapsulated into an application-layer message and sent via a communication protocol (such as TCP / IP, MQTT, or other transport protocols). The application-layer message includes the complete evidence packet and transport protocol header information to ensure correct data reception and parsing. The performance requirement for this process is that the evidence packet generation and signing process should be completed within 200 milliseconds to ensure real-time performance and efficiency.

[0052] The evidence packet is encapsulated into an application-layer message and sent to the master station. Upon receiving the message, the master station verifies the signature, registers the time reference and index, and archives it. After archiving, it calls the source-end positioning rule set and compares the link characteristics, protocol fingerprints, and detection results according to a preset decision order to generate a positioning conclusion. After the evidence packet is sent to the master station, the master station first verifies the signature. Input data includes the sent evidence packet, the master station's public key, and hash algorithms. The master station verifies the digital signature of the evidence packet using the public key to ensure data integrity and authenticity. If verification passes, the master station registers the time reference and evidence packet index and archives the data to ensure all evidence has complete records and traceability. If signature verification fails, the system triggers an error alarm and requests a resend of the evidence packet.

[0053] The archived evidence is transmitted to the source-end location rule set. Here, the system compares link features, protocol fingerprints, and detection results sequentially according to a preset decision order. The comparison process uses algorithms to determine if there are any anomalies in the data collection. Link features include signal quality and transmission rate, protocol fingerprints include the consistency of protocol fields, and detection results include previous active detection data. Through comparison, the system generates a location conclusion, such as whether it is a communication link problem, equipment failure, or other anomaly. The generated location conclusion will serve as the basis for subsequent processing.

[0054] Based on the location findings, a set of handling instructions is generated and a backtracking identifier is recorded. The handling instructions are then sent to the data acquisition side, and the execution status is written back. According to the location findings, the handling instruction set will generate and record a backtracking identifier, ensuring the system can trace back to every step of the anomaly handling process. The handling instruction set includes specific operational steps, such as requiring the device to reinitialize, re-acquire data, or switch communication paths. The generated instruction set is sent to the data acquisition side via the communication interface, and the execution status is recorded to ensure that each instruction is executed accurately. The status is written back to the system for subsequent tracking and monitoring. If the handling instruction fails to be sent, the system will retry or use an alternative instruction path to ensure the problem is resolved.

[0055] Example 2: Figure 2 This invention provides a reliability verification system for remote data acquisition from an electricity meter box, comprising: The time base synchronization and task registration module synchronizes the time base and registers a single copying task, collects cross-layer evidence sets, including channel quality parameters, protocol fingerprints, payload fields and device event flags, ensures task identification and time synchronization, and starts data acquisition; The data verification and tag generation module performs monotonicity and constraint verification on the specification fingerprint and payload fields, generates suspicious tags, and is responsible for checking the consistency of frame sequence number, timestamp, random factor, etc., and marking it as suspicious when an anomaly is found; The active detection and difference vector generation module triggers active detection when a suspicious marker is found, obtains the difference vector associated with this copying, performs different types of detection, and generates difference vectors to help further confirm the credibility of the data; The credibility assessment and grading module performs a fusion assessment based on cross-layer evidence sets and difference vectors, outputs numerical credibility and completes the grading, and generates credibility scores by combining feature standardization and rule verification and grading according to set thresholds. The supplementary data acquisition and standard switching module performs supplementary data acquisition and communication standard switching based on the classification results, determines the final data value, and executes the corresponding supplementary data acquisition or switching strategy according to the reliability classification to ensure the accuracy of the final result. The evidence package generation and source location module generates an evidence package containing evidence summary, probe logs, and credibility, protects its integrity, and uploads it. At the same time, it performs source location and processing based on the evidence to ensure data integrity and improve data reliability through source location and processing decisions.

[0056] The technical connections and implementation logic of the six modules are as follows: First, before initiating data acquisition, the time base synchronization and task registration module synchronizes the time base and registers a single copying task. Simultaneously, it collects cross-layer evidence sets, including channel quality parameters, protocol fingerprints, payload fields, and device event flags, ensuring task identification and time synchronization to provide accurate time references and identifiers for subsequent data acquisition. Next, the data verification and tag generation module performs monotonicity and constraint checks on the collected protocol fingerprints and payload fields, checking the consistency of frame sequence numbers, timestamps, and random factors. If an anomaly is found, a suspicious tag is generated, marking the data as suspicious and passing it to the next stage. In the active detection and difference vector generation module, when a suspicious tag exists, the system triggers an active detection process. Through detection methods such as repeated read consistency, field order perturbation, light-load handshake, or loopback delay measurement, a difference vector associated with the current copying task is generated. This provides data support for subsequent credibility assessment. Subsequently, the credibility assessment and grading module performs a fusion assessment based on cross-layer evidence sets and difference vectors, outputting a numerical credibility score. It then generates a credibility score based on feature standardization and rule verification, grading it according to a set threshold to determine the data's credibility level. Based on the grading results, the supplementary data collection and communication mode switching module performs corresponding supplementary data collection or communication mode switching operations to ensure the accuracy of the final data value. It also determines whether to adopt a supplementary data collection strategy or switch to a backup communication mode based on the credibility grading. Finally, the evidence package generation and source location module generates an evidence package containing evidence summaries, probe logs, and credibility scores. This package is protected for integrity and uploaded to the main station. Simultaneously, it performs source location and processing based on the evidence to ensure data integrity and improve data reliability and accuracy for subsequent use through source location and processing decisions.

[0057] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0058] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0059] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0060] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0061] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0062] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0066] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for verifying the reliability of remote data acquisition from an electricity meter box, characterized in that, include: S1. Synchronize the time base and register a single copying task, and collect a cross-layer evidence set, which includes channel quality parameters, protocol fingerprint, payload field and device event flag; S2. Perform monotonicity and constraint checks on the specification fingerprint and load fields to generate suspicious flags; S3. When a suspicious marker is present, trigger active detection to obtain the difference vector associated with this copying. The active detection includes at least one of repeated read consistency, field order perturbation, light load handshake and loopback delay measurement. S4. Based on the cross-layer evidence set and difference vector, perform fusion evaluation, output numerical credibility and complete the classification; S5. Based on the hierarchical execution of supplementary data collection and communication mode switching, determine the final data value of this data reading; S6. Generate an evidence package containing evidence summary, probe logs, and credibility, protect its integrity, and upload it. At the same time, locate and handle the source based on the evidence.

2. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S1 includes: Before starting the data collection, perform time base synchronization, register the single-transfer task identifier, and start the current data collection session; Read the channel quality parameters sequentially, including signal-to-noise ratio, received signal strength indication, hybrid automatic repeat count, round-trip time delay, and cyclic redundancy check results; Parse the protocol fingerprint, which includes frame sequence number, timestamp, random number or handshake factor and synchronization identifier; Parse the load fields, including cumulative energy consumption, phase voltage, phase current, power factor, and demand; Read device event flags, including those for opening the cover, power failure, exceeding temperature limits, and port reset. Write the above items into the evidence set according to the task identifier and unified time benchmark, and then end this step.

3. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S2 include: Monotonicity and constraint checks are performed on the specification fingerprint and payload fields, including: first parsing the specification fingerprint, and then establishing a check queue based on frame number, timestamp, random factor and handshake identifier; Then, the frame sequence number increment verification, timestamp order verification, random factor freshness verification, and handshake identifier consistency verification are completed in sequence. Then, perform field integrity checks, type and encoding format verification, unit identifier consistency verification, cross-field constraint comparison, and cross-period monotonicity comparison on the load field in sequence. Finally, if any verification fails to meet the preset rules, a suspicious flag is generated and archived in this copying record.

4. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S3 includes: When a suspicious marker is found, the detection and control unit is set to execute the probe sequence in sequence: repeat read consistency probe, issue the same read command twice, record the two return frames, and the comparison unit compares them item by item according to the field index; The field order perturbation probe adjusts the field reading order for the same read command, sends and records the return frame, and compares the re-imaged field position with the baseline frame. Lightweight handshake probes only initiate the handshake process and record handshake elements and sequence numbers. The loopback delay measurement probe sends a loopback request, records the transmit and receive times, and calculates the round-trip difference. The result recording unit encodes the comparison results of each probe and summarizes them into a difference vector associated with the copying.

5. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S4 include: The cross-layer evidence set and the difference vector are input into the feature standardization unit to generate a unified feature vector; The feature vector is sent to the rule verification unit to perform consistency determination of sequence number, time base and field constraints and output the tag vector; When the verification is passed or a non-fatal marker exists, the unified feature vector and the marker vector are concatenated and sent to the fusion computing unit to calculate the numerical credibility according to the preset weights and the combined model. The credibility input is compared with the threshold set to generate a level identifier; The results output unit outputs a rating record containing credibility and level identifiers.

6. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S5 includes: Based on the classification results, confirmation is performed for Class A, and supplementary sampling is performed for Class B according to the retry parameters. If it fails, the steady-state parameter set is loaded and supplementary sampling is performed again. If it still fails, supplementary sampling is performed according to the system switching sequence. For Level C, supplementary sampling is performed directly into the standard switching sequence, and the candidate selection is based on a preset sorting and priority. When multiple candidates are obtained for the same communication standard, one is selected according to a preset sorting table; After outputting the final result, select multiple communication standards and choose the return value.

7. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 1, characterized in that, S6 include: After the classification is completed, the evidence packaging process is initiated: cross-layer evidence summaries, key message indexes, probe logs, credibility and task identifiers are collected and the evidence objects are constructed in a fixed field order; Calculate the hash of the evidence object and attach a digital signature to generate a signed evidence package; The evidence packet is encapsulated into an application layer message and sent to the main station. After receiving it, the main station verifies and validates the signature, registers the time base and index and archives it. After archiving, it calls the source end positioning rule set, compares the link characteristics, protocol fingerprint and detection results according to the preset decision order, and generates a positioning conclusion. Based on the location conclusion, a set of disposal instructions is generated and a backtracking identifier is recorded. The disposal instructions are then sent to the data collection side and the execution status is written back.

8. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 6, characterized in that: Communication mode switching is performed according to a preset priority order, which is power line carrier supplementary sampling, serial bus relay supplementary sampling, and cellular mode supplementary sampling in that order. Each system completes one supplementary sampling and result registration before moving on to the next system.

9. The method for verifying the reliability of remote data acquisition from an electricity meter box according to claim 7, characterized in that: The evidence package adopts a partitioned frame structure and is generated in a fixed order, namely: evidence header field area, evidence digest area, probe log area, scoring record area, and signature area; Calculate the hash of all fields except the signature area and write them into the signature area. Then encapsulate them into an application layer message and send it up in the order described.

10. A system for verifying the reliability of remote data acquisition from an electricity meter box, used to implement the method for verifying the reliability of remote data acquisition from an electricity meter box as described in any one of claims 1-9, characterized in that, include: The time base synchronization and task registration module synchronizes the time base and registers a single copying task, collects cross-layer evidence sets, including channel quality parameters, protocol fingerprints, payload fields and device event flags, ensures task identification and time synchronization, and starts data acquisition; The data verification and tag generation module performs monotonicity and constraint verification on the specification fingerprint and payload fields, generates suspicious tags, and is responsible for checking the consistency of frame sequence number, timestamp, random factor, etc., and marking it as suspicious when an anomaly is found; The active detection and difference vector generation module triggers active detection when a suspicious marker is found, obtains the difference vector associated with this copying, performs different types of detection, and generates difference vectors to help further confirm the credibility of the data; The credibility assessment and grading module performs a fusion assessment based on cross-layer evidence sets and difference vectors, outputs numerical credibility and completes the grading, and generates credibility scores by combining feature standardization and rule verification and grading according to set thresholds. The supplementary data acquisition and standard switching module performs supplementary data acquisition and communication standard switching based on the classification results, determines the final data value, and executes the corresponding supplementary data acquisition or switching strategy according to the reliability classification to ensure the accuracy of the final result. The evidence package generation and source location module generates an evidence package containing evidence summary, probe logs, and credibility, protects its integrity, and uploads it. At the same time, it performs source location and processing based on the evidence to ensure data integrity and improve data reliability through source location and processing decisions.

Images