A power meter trip event compliance verification method and system

Abstract

The present application relates to the technical field of power information collection and fee control business event verification for smart grid, and particularly relates to a power meter trip event compliance verification method and system. The method comprises: receiving a main station trip instruction issuing log, a power meter file and a fee control business rule, generating a trip event instance and a stage state record; matching a DL / T645 protocol frame template based on the meter model and the protocol version, associating the meter end response frame and performing target response code field verification; determining a load verification window according to the trip time, generating a load cut-off verification record based on the load curve; associating the arrears settlement state, the power restoration application work order, the power restoration instruction record and the power restoration response frame, generating a power restoration closed-loop verification record; updating the stage state record and writing the evidence index into the compliance verification record. The present application forms a continuous corresponding relationship among the trip instruction, the meter end response, the load cut-off and the power restoration record, effectively improving the correspondence between the trip event abnormal type and the original evidence.

Description

Technical Field

[0001] This invention relates to the field of smart grid electricity consumption information collection and fee control business event verification technology, and in particular to a compliance verification method and system for electricity meter tripping events. Background Technology

[0002] In the field of smart grid electricity consumption information collection and fee control business event verification technology, existing solutions for electricity meter tripping events typically involve the master station issuing a tripping command, the collection terminal or meter returning a response frame, and the master station recording the command status, return status, tripping event record information, or closing event record information. While this approach can complete remote tripping, payment-based closing, and event recording in typical scenarios, it is prone to limitations in scenarios involving intertwined tripping due to overdue payments, fee control tripping, load management tripping, and power restoration processing. These limitations include discontinuous connection between the master station log and the meter's response frame, lack of verification of the load status after tripping, and difficulty in correlating power restoration records with preceding tripping events.

[0003] Existing solutions often rely on meter status words, relay command status, relay actual status, confirmation response frames, or trip and reconnection data for processing. When the same account number has trip commands, meter responses, load curve changes, and power restoration requests within adjacent time periods, there is a lack of stable connection between the command issuance stage and the meter response, load disconnection verification, and power restoration processing stages. This can easily lead to incomplete stage status records and difficulty in matching anomaly types with original evidence.

[0004] Regarding the joint processing of master station trip command issuance logs, meter response frames, load curves, and power restoration records, existing technologies still have common shortcomings in event log analysis, response frame parsing, load status determination, and power restoration record correlation. Therefore, it is necessary to address the issue of generating compliance verification records based on master station trip command issuance logs, meter response frames, load curves, and power restoration records, focusing on electricity meter trip events. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a compliance verification method for electricity meter tripping events, comprising:

[0006] S100: Receive the master station tripping instruction log, electricity meter file and fee control business rules, perform event record analysis by account number, meter address, task serial number and tripping time, and generate tripping event instances and stage status records. The stage status records include instruction issuance stage, meter response stage, load disconnection verification stage and power restoration closed loop stage.

[0007] S200. Based on the tripping event instance, read the meter manufacturer model and protocol version in the electricity meter file, match the DL / T645 protocol frame template, associate the meter response frame within the preset response time window, and perform response frame parsing and target return code field verification on the meter response frame to generate a meter response verification record.

[0008] S300. Based on the tripping event instance and the meter response verification record, determine the load verification window according to the tripping time, read the load curve in the load verification window, and compare the load value after tripping with the preset disconnection threshold to generate a load disconnection verification record.

[0009] S400: Based on the tripping event instance, the meter response verification record and the load disconnection verification record, associate the overdue payment status, power restoration application work order, power restoration instruction record and power restoration response frame, perform information verification on the completeness and time sequence of power restoration elements, and generate a power restoration closed-loop verification record.

[0010] S500. Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, update the stage status record and write the evidence index into the compliance verification record.

[0011] Furthermore, in S100, the generation of the trip event instance includes:

[0012] Read the account number, table address, task serial number, trip time, trip type, instruction status, channel identifier, and rule version from the main station trip instruction issuance log;

[0013] The account number, the table address, the task serial number, and the trip time are combined into an event identifier, and the trip type, the instruction status, the channel identifier, and the rule version are written into the instruction issuance stage.

[0014] Furthermore, in S100, the stage status record includes a pending verification status, a passed status, an abnormal status, and an undeterminable status; each stage status is bound to a data source, a timestamp, and an evidence index.

[0015] Further, in S200, the DL / T645 protocol frame template includes the DL / T645-1997 template and the DL / T645-2007 template; the matching of the DL / T645 protocol frame template includes: reading the meter manufacturer model, protocol version, meter address, control code and data identifier from the electricity meter file, and generating a protocol frame template matching result based on the meter manufacturer model, the protocol version, the meter address, the control code and the data identifier.

[0016] Further, in S200, the step of associating the response frame within the preset response time window includes:

[0017] The master station trip command issuance log and the table terminal response frame are timestamped according to the account number, the table address, the task serial number, the trip time, and the response reception time.

[0018] If no response frame is associated with the table terminal within the preset response time window, the table terminal response stage is marked as a response timeout and an exception type is written.

[0019] Furthermore, in S300, determining the load verification window based on the tripping time includes:

[0020] Starting from the tripping time, read the load curve within a preset time range after the tripping.

[0021] Read the load value of the target sampling point after the trip from the load curve, and use the load value of the target sampling point after the trip as the load value after the trip.

[0022] Furthermore, in S300, the generation of the load cut-off verification record includes:

[0023] When the load curve is missing, the freeze is delayed, or the quality identification is abnormal, the load cut-off verification stage will be marked as an undeterminable state.

[0024] When the load value after the trip is not lower than the preset disconnection threshold, the load disconnection verification stage is marked as an abnormal state and the abnormal type of load not disconnected is written.

[0025] Furthermore, in S400, the information verification of the completeness and time sequence of the power restoration elements includes:

[0026] Read the overdue payment status, the power restoration application work order status, the power restoration instruction record, and the power restoration response frame;

[0027] When the overdue payment settlement status is valid, the work order status is valid, the power restoration instruction record exists, and the power restoration response frame is associated with the preset response time window, the order of overdue payment settlement time, power restoration application time, and power restoration instruction time are checked for their sequential relationship.

[0028] Furthermore, in S500, the generation of the compliance verification record includes:

[0029] Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, the anomaly type is determined;

[0030] The compliance score is calculated based on the preset weights for the meter response stage, the load disconnection verification stage, and the power restoration closed-loop stage.

[0031] The stage status, the anomaly type, the evidence index, and the compliance score are written into the compliance verification record.

[0032] Furthermore, a compliance verification system for electricity meter tripping events includes: an event instance generation module, a meter response verification module, a load disconnection verification module, a power restoration closed-loop verification module, and a compliance result output module; the system is used to implement the method described in any of the above embodiments.

[0033] The key innovations of this invention include:

[0034] (1) Taking the main station trip command issuance log as the event starting point, and combining the electricity meter file and fee control business rules, the event record analysis is performed according to the account number, meter address, task serial number and trip time to generate trip event instances and stage status records including the command issuance stage, meter response stage, load disconnection verification stage and power restoration closed loop stage.

[0035] (2) Based on the tripping event instance, read the meter manufacturer model and protocol version in the energy meter file, match the DL / T645 protocol frame template, associate the meter response frame within the preset response time window, and perform response frame parsing and target return code field verification on the meter response frame to generate the meter response verification record.

[0036] (3) Using the tripping event instance as the associated object, the meter response verification record, load disconnection verification record, overdue payment status, power restoration application work order, power restoration instruction record and power restoration response frame are continuously associated. The information verification of load disconnection status, power restoration element completeness and time sequence is performed, and the evidence index is written into the compliance verification record.

[0037] The following are its main beneficial effects:

[0038] (1) To address the issue of discontinuous connection between the main station log, meter response and power restoration record, the command issuance, meter response, load disconnection verification and power restoration closed loop are incorporated into the same event record through trip event instances and stage status records, so that the status of each stage and the corresponding data source form a continuous correspondence.

[0039] (2) To address the problem that existing solutions rely on confirmation response frames or return status and have difficulty distinguishing between the protocol version and the meaning of the table response code, the response frame of the table response frame is parsed and the target response code field is verified by using the table manufacturer model, protocol version and DL / T645 protocol frame template, so that the table response verification record can reflect the response status at the protocol field level.

[0040] (3) To address the issues of lack of verification of load status after tripping and difficulty in matching power restoration records with previous tripping events, load disconnection verification records, power restoration closed-loop verification records, and evidence indexes are written into compliance verification records through load verification window, preset disconnection threshold, completeness of power restoration elements, and time sequence information verification. Attached Figure Description

[0041] Figure 1 A flowchart illustrating a compliance verification method for a power meter tripping event provided in this application embodiment;

[0042] Figure 2 This is a structural block diagram of a compliance verification system for electricity meter tripping events provided in an embodiment of this application. Detailed Implementation

[0043] Example 1: Refer to Figure 1 This is a flowchart illustrating a compliance verification method for electricity meter tripping events provided in an embodiment of the present invention. The process may include at least steps S100-S500:

[0044] S100: Receive the master station tripping instruction log, electricity meter file and fee control business rules, perform event record analysis by account number, meter address, task serial number and tripping time, and generate tripping event instances and stage status records. The stage status records include instruction issuance stage, meter response stage, load disconnection verification stage and power restoration closed loop stage.

[0045] S200. Based on the tripping event instance, read the meter manufacturer model and protocol version in the electricity meter file, match the DL / T645 protocol frame template, associate the meter response frame within the preset response time window, and perform response frame parsing and target return code field verification on the meter response frame to generate a meter response verification record.

[0046] S300. Based on the tripping event instance and the meter response verification record, determine the load verification window according to the tripping time, read the load curve in the load verification window, and compare the load value after tripping with the preset disconnection threshold to generate a load disconnection verification record.

[0047] S400: Based on the tripping event instance, the meter response verification record and the load disconnection verification record, associate the overdue payment status, power restoration application work order, power restoration instruction record and power restoration response frame, perform information verification on the completeness and time sequence of power restoration elements, and generate a power restoration closed-loop verification record.

[0048] S500. Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, update the stage status record and write the evidence index into the compliance verification record.

[0049] S100 receives the master station trip command distribution log, electricity meter files and fee control business rules, performs event recording analysis by account number, meter address, task serial number and trip time, and generates trip event instances and stage status records.

[0050] In this embodiment, S100 is executed by the event instance generation module, which is deployed in the electricity information acquisition master station, the fee control business audit server, or a data processing device connected to the master station. The event instance generation module receives the master station trip instruction issuance log, electricity meter files, and fee control business rules. The master station trip instruction issuance log comes from the master station control log library and includes the user number, meter address, task serial number, trip time, trip type, instruction status, channel identifier, and rule version. The electricity meter files come from the metering archive library and include the user number, meter address, meter manufacturer model, protocol version, rated load, acquisition channel, and communication parameters. The fee control business rules come from the rule configuration table and include trip type, power restoration preconditions, response time window configuration, and stage status writing rules.

[0051] The tripping event instance is a structured event record formed starting from a single tripping command issuance record from the main station. Specifically, the event instance generation module reads the user number, table address, task serial number, and tripping time from the main station tripping command issuance log, and combines the user number, table address, task serial number, and tripping time into an event identifier. When multiple tripping command issuance logs exist for the same user number within adjacent time periods, the event instance generation module prioritizes matching based on the task serial number. If the task serial number is missing, multiple event identifiers are created according to the chronological order of the tripping time, and each event identifier is written into the corresponding tripping event instance.

[0052] The stage status record is used to record the status changes of the tripping event instance during the instruction issuance stage, meter response stage, load disconnection verification stage, and power restoration closed-loop stage. Specifically, after generating the tripping event instance, the event instance generation module writes an initial state for the instruction issuance stage; writes a pending verification state for the meter response stage, the load disconnection verification stage, and the power restoration closed-loop stage; and binds the data source, timestamp, and evidence index to each stage status. The evidence index is used to point to the storage location of the original log, meter response frame, load curve segment, power restoration application work order, or power restoration instruction record in the corresponding database.

[0053] In one implementation, the event record analysis includes log field integrity verification, event identifier generation, and stage status writing. Log field integrity verification uses the user number, table address, task serial number, and trip time as verification objects. When the user number or table address is missing, the event instance generation module writes the main station trip instruction issuance log to the exception cache and marks the instruction issuance stage as an exception state. When the task serial number is missing but the user number, table address, and trip time are complete, the event instance generation module generates a temporary event identifier based on the user number, table address, and trip time, and writes the exception type of missing task serial number into the stage status record.

[0054] In another implementation, the tripping types include overdue payment tripping, fee control tripping, and load management tripping. The event instance generation module reads the corresponding fee control business rule according to the tripping type and writes the rule version into the instruction issuance stage. The rule version corresponds to the rule calls in subsequent meter response verification, load disconnection verification, and power restoration closed-loop verification; when the rule version does not match the tripping time, the event instance generation module retains the original rule version field and writes the rule version inconsistency into the stage status record.

[0055] This step can be triggered by the logging of a new master station tripping command or by a scheduled audit task. When triggered by the logging of a new master station tripping command, the event instance generation module reads the logs in the order they were logged. When triggered by a scheduled audit task, the event instance generation module reads the master station tripping command logs that have not generated tripping event instances within a specified time range, and generates corresponding tripping event instances by user number and table address. For master station tripping command logs that have already generated event identifiers, the event instance generation module reads the existing tripping event instances and updates the stage status record, without generating event identifiers again.

[0056] In a specific implementation scenario, at 10:00:00 on July 1, 2026, the master station issues an overdue payment trip command to account number U001 and meter address M001. The task serial number is T202607010001, the command status is "issued," the channel identifier is C01, and the rule version is R2026-01. After reading the above fields, the event instance generation module combines U001, M001, T202607010001, and 10:00:00 on July 1, 2026 into an event identifier. It writes the trip type, command status, channel identifier, and rule version into the command issuance stage, and writes the meter response stage, load disconnection verification stage, and power restoration closed-loop stage into the pending verification status.

[0057] S100 ultimately generates a tripping event instance and a stage status record. The tripping event instance includes an event identifier, account number, meter address, task serial number, tripping time, tripping type, instruction status, channel identifier, and rule version. The stage status record includes status fields, timestamps, data sources, and evidence indexes for the instruction issuance stage, meter response stage, load disconnection verification stage, and power restoration closed-loop stage. S200 retrieves the account number, meter address, task serial number, tripping time, and energy meter file index from the tripping event instance to perform DL / T645 protocol frame template matching and meter response frame association.

[0058] S200: Based on the tripping event instance, read the meter manufacturer model and protocol version from the electricity meter file, match the DL / T645 protocol frame template, associate the meter response frame within the preset response time window, and perform response frame parsing and target return code field verification on the meter response frame to generate a meter response verification record.

[0059] In this embodiment, S200 is executed by the protocol template matching module and the meter response verification module. The protocol template matching module receives the trip event instance generated in S100 and reads the electricity meter file based on the account number and meter address in the trip event instance; the meter response verification module receives the trip event instance, the protocol frame template matching result, and the meter response frame in the master station communication message library, and performs association and response frame parsing within a preset response time window. The meter response frame is a communication message returned by the meter after responding to the master station trip command, and includes the meter address, control code, data identifier, data field, verification field, response reception time, and channel identifier.

[0060] The DL / T645 protocol frame templates include the DL / T645-1997 template and the DL / T645-2007 template. The protocol template matching module reads the meter manufacturer model, protocol version, meter address, control code, and data identifier from the electricity meter file, and generates a protocol frame template matching result based on these information. The protocol frame template matching result includes the template version, frame start field position, address field position, control code position, data identifier position, target response code field position, and check field position. The target response code field is a data identifier field or manufacturer extended field in the meter's response frame used to indicate the reception, parsing, or execution status of a trip command.

[0061] When performing the association, the meter response verification module reads the account number, table address, task serial number, and trip time from the trip event instance, and reads the meter response frames in the master station communication message library whose response reception time falls within a preset response time window. The preset response time window is given by the fee control service rules, starting from the trip time; in one implementation, the preset response time window is 3 seconds; in another implementation, the preset response time window is configured by both the trip type and the communication channel. The meter response verification module timestamps the master station trip command issuance log and the meter response frames according to the account number, table address, task serial number, trip time, and response reception time; when the task serial number is not written into the meter response frame, auxiliary matching is performed according to the table address, channel identifier, and response reception time, and the missing task serial number is written into the meter response verification record.

[0062] The response frame parsing is performed according to the protocol frame template matching result. Specifically, the table-side response verification module reads the address field of the table-side response frame according to the template version and compares the address field with the table address in the trip event instance; if the address fields match, it continues to read the control code and data identifier; if the control code and data identifier match the protocol frame template matching result, it reads the target return code field; the field value of the target return code field is compared with the return code rule corresponding to the trip type in the fee control business rules to generate the target return code field parsing result. The target return code field parsing result includes the field position, field value, return code meaning, parsing time, and template version.

[0063] When no table response frame is associated within the preset response time window, the table response verification module marks the table response stage as a response timeout and writes it into the exception type. When a table response frame is associated but the address field is inconsistent with the table address, the table response stage is marked as an exception state and the address field inconsistency is recorded. When the control code or data identifier is inconsistent with the matching result of the protocol frame template, the target return code field mismatch is written into the exception type. When the table response frame has a verification field error, the original message index of the table response frame is retained, and the verification field error is written into the evidence index.

[0064] In one implementation, the protocol template matching module maintains multiple DL / T645 protocol frame templates corresponding to different meter manufacturers and models. When the protocol version in the meter file is empty, the module first reads the default template by meter manufacturer and address, and writes the missing protocol version into the protocol frame template matching result. When the control code and data identifier of a subsequent meter response frame are inconsistent with the default template, the module reads another template from the same meter manufacturer and model for matching, and writes a template switching record into the meter response verification record. Understandably, the template switching record is only used as a record field for this meter response verification and does not change the original meter file.

[0065] In a specific implementation scenario, the trip event instance generated by S100 corresponds to table address M001, the meter manufacturer model in the electricity meter file is F01, and the protocol version is DL / T645-2007. The protocol template matching module reads the protocol frame templates corresponding to F01 and DL / T645-2007, and generates a protocol frame template matching result containing the control code position, data identifier position, and target response code field position. Within 3 seconds after the trip time, the meter response verification module reads the meter response frame for table address M001 from the master station communication message library, and performs response frame parsing on the meter response frame; when the target response code field matches the trip execution response code in the fee control business rule, the meter response stage is written to the pass status, and a meter response verification record is generated.

[0066] The meter response verification record output by S200 includes event identifier, protocol frame template matching result, meter response frame index, response reception time, target return code field parsing result, meter response stage status, and exception type. S300 reads the event identifier, trip time, and meter response stage status from the meter response verification record and uses this record as preliminary evidence for load cut-off verification. When the meter response stage is a response timeout or the target return code field does not match, S300 can still read the load curve to form a load cut-off verification record and retain the exception type of the meter response stage in the load cut-off verification record.

[0067] In one specific embodiment, S200 is executed by a protocol template matching module and a meter response verification module. The protocol template matching module receives the trip event instance generated in S100 and reads the electricity meter file based on the account number and meter address in the trip event instance. The meter response verification module receives the trip event instance, the protocol frame template matching result, and the meter response frame in the master station communication message library, and performs correlation and response frame parsing within a preset response time window. The protocol template matching module first extracts the meter manufacturer model field, protocol version field, meter address field, control code field, and data identifier field from the electricity meter file, and generates a protocol frame template matching result based on the above fields. The matching result includes the template version, frame start field position, address field position, control code position, data identifier position, target return code field position, and verification field position. The target return code field is a data identifier field or manufacturer extended field in the meter response frame used to indicate the status of receiving, parsing, or executing the trip command.

[0068] The protocol template matching module maintains DL / T645 protocol frame templates corresponding to multiple meter manufacturers and models, including DL / T645-1997 and DL / T645-2007 templates, as well as proprietary extended templates for each meter manufacturer and model based on the aforementioned standard protocol. To map discrete fields in the electricity meter file to executable location parsing instructions, the protocol template matching module queries the template library using a double-key index composed of the meter manufacturer model and protocol version, outputting an ordered set of template version identifiers and offsets for each field. When performing the association, the meter response verification module reads the account number, meter address, task serial number, and trip time from the trip event instance, and simultaneously filters the set of meter response frames whose response reception time falls within a preset response time window from the master station communication message library.

[0069] The preset response time window is given by the fee control service rules, and its starting point is the tripping time. In one implementation, the preset response time window is 3 seconds, and in another implementation, the preset response time window is configured by both the tripping type and the communication channel.

[0070] For meter response frames that fall within the time window, the meter response verification module timestamps the user number, meter address, task serial number, trip time, and response reception time. When the task serial number is not written into the meter response frame, auxiliary matching is performed based on the meter address, channel identifier, and response reception time, and the missing task serial number is written into the meter response verification record.

[0071] During the timestamp alignment process, since the timestamp of the master station trip command issuance log and the response reception time of the table terminal response frame come from different clock sources and acquisition links, there is a system-level clock deviation and communication link transmission delay between the two. Directly associating them according to absolute time will lead to a decrease in matching accuracy.

[0072] To address this, the meter response verification module introduces a time window cross-correlation metric within a preset response time window. It performs sliding matching between the tripping time in the tripping event instance and the response reception time sequence in the meter response frame set, using the response frame corresponding to the peak value of the time window cross-correlation as the optimal correlation result.

[0073] Formula ① constructs a reference time series centered on the tripping time, uses the response and reception time series as the sliding sequence, calculates the cross-correlation energy value within the preset response time window, and selects the sequence alignment position with the largest energy value that exceeds the preset threshold as the timestamp alignment result.

[0074] Formula①

[0075]

[0076] in: The time delay is Time window cross-correlation energy value;

[0077] Discrete Delay Index;

[0078] : Summation operator;

[0079] Index of discrete sampling points in a time series;

[0080] : The length of the time series involved in the cross-correlation calculation;

[0081] : The first tripping event example The timestamp sequence value of each trip time discretized according to the sampling interval;

[0082] The response reception time series of the table-end response frames in the master station communication message library is indexed. The value at;

[0083] : The duration of the preset response time window;

[0084] : Symbols for the set of integers;

[0085] : to make the cross-correlation energy value Maximize the optimal latency index;

[0086] : The operator that takes the maximum value of the independent variable;

[0087] : Symbol for closed interval; represents The lower bound of the value is the negative preset response time window duration, and the upper bound is the positive preset response time window duration;

[0088] Take Maximize latency index As a timestamp alignment offset .

[0089] when When the threshold is lower than the preset cross-correlation threshold, the table response verification module determines that there is no reliably correlated table response frame within the current time window. At this time, the table response stage is directly marked as response timeout and written into the exception type, and subsequent response frame parsing is no longer executed.

[0090] when When the preset cross-correlation threshold is reached or exceeded, The aligned response frame is used as the association result and enters the response frame parsing process.

[0091] Formula ① addresses the practical problem that there is an unknown and non-fixed clock deviation and communication delay between the trip time in the master station control log library and the response reception time in the master station communication message library. The optimal alignment position is found through time window cross-correlation sliding matching, and the trip event instance and the table response frame are precisely bound in the time dimension.

[0092] After completing timestamp alignment, the table response verification module performs response frame parsing according to the protocol frame template matching result. The protocol frame template matching result contains the position of the target return code field, but this position is a relative offset. The length of each field in the actual table response frame structure varies depending on the manufacturer's extension and protocol version. Directly using a fixed offset to read will result in field misalignment.

[0093] The table response verification module reads the address field of the table response frame according to the template version and compares the address field with the table address in the trip event instance byte by byte. If the address field matches, it continues to read the control code and data identifier. If the control code and data identifier match the protocol frame template matching result, under the frame structure definition corresponding to the template version, it accumulates the offset step by step according to the frame start field position, address field length, control code length and data identifier length to finally locate the start byte and length of the target return code field.

[0094] There are multiple verification branches during the response frame parsing process: when the table response frame is associated but the address field is inconsistent with the table address, the table response stage is marked as an abnormal state and the address field inconsistency is recorded; when the control code or data identifier is inconsistent with the protocol frame template matching result, the target return code field mismatch is written into the abnormal type; when the table response frame has a verification field error, the original message index of the table response frame is retained and the verification field error is written into the evidence index.

[0095] Since the protocol template matching result comes from the meter manufacturer model and protocol version in the electricity meter file, while the control code and data identifier in the actual meter response frame are filled in by the meter device during operation, there may be discrepancies between the two due to file configuration errors or meter device firmware upgrades.

[0096] To quantify this deviation and assist in anomaly attribution, the table response verification module introduces a state space metric in the control code and data identifier comparison process. It maps the control code position, data identifier position, and target return code field position in the specification template matching result into a three-dimensional weighted ideal state vector, maps the parsed values ​​of the corresponding fields in the actual table response frame into the measured state vector, and calculates the weighted Euclidean distance between the two as the frame structure consistency score.

[0097] Formula ② constructs a normalized consistency score based on the distance between the ideal state vector and the measured state vector. This score is used for the joint verification of the positions of the control code, data identifier, and target return code fields.

[0098] Formula②

[0099]

[0100] in: Frame structure consistency score;

[0101] : Natural exponential function;

[0102] The power term of an exponential function;

[0103] :vector and The square of the Euclidean distance between them;

[0104] : L2 norm square operator; indicates that the L2 norm (Euclidean norm) of the vector is calculated first, and then the result is squared;

[0105] Ideal state vector;

[0106] : Measured state vector;

[0107] : Preset scale parameters (Gaussian kernel width parameters);

[0108] Ideal state vector The first component;

[0109] Ideal state vector The second component;

[0110] Ideal state vector The third component;

[0111] : Measured state vector The first component;

[0112] : Measured state vector The second component;

[0113] : Measured state vector The third component;

[0114] : Column vector construction symbol; indicates that the three components within the brackets are arranged vertically to form a three-dimensional column vector.

[0115] Extracted from the template matching results of the standard frame , , And construct Extracted from the actual parsing results of the response frame at the table end. , , And construct Together, they form the two state vectors in formula ②.

[0116] In Formula ② and The formula obtained from formula ① was used. The aligned response frame position index, i.e., the cross-correlation alignment result of Formula ①, provides Formula ② with the specific location of the response frame in the message library after confirmation within the time window, enabling Formula ② to read the measured state vector based on this location. When If the value exceeds a preset consistency threshold (e.g., 0.85), the frame structure is determined to be consistent, and semantic verification of the target return code field continues; when... If the frame structure is not greater than the preset consistency threshold, the frame structure is determined to be inconsistent. The mismatch between the control code or data identifier is written into the exception type, and the table response stage is marked as an exception state.

[0117] Formula ② addresses the practical problem that when there is a coupling relationship between the control code, data identifier, and target return code field positions, comparing any one field alone may lead to misjudgment. By constructing a three-dimensional state space and calculating the weighted distance, the three are jointly verified into a consistency score, which improves the robustness of frame structure verification.

[0118] After the frame structure consistency determination is passed, the table-side response verification module performs semantic parsing on the target return code field. The field value of the target return code field is compared with the return code rule for the corresponding tripping type in the fee control business rules to generate the target return code field parsing result.

[0119] Since different meter manufacturers may assign different return code values ​​to the same trip execution status, for example, meter manufacturer F01 uses 0x90 to indicate successful trip execution while meter manufacturer F02 uses 0x11 to indicate successful trip execution, the parsing of the target return code field cannot rely solely on a single mapping table. It is necessary to dynamically select the return code rule in combination with the meter manufacturer model associated with the current trip event instance.

[0120] The meter response verification module reads the trip type from the trip event instance and the meter manufacturer model from the electricity meter file. It then queries the return code rule configuration table in the fee control business rules using the combination key of the trip type and the meter manufacturer model to obtain the mapping dictionary from the return code encoding to the return code meaning in the current scenario.

[0121] Before querying the mapping dictionary, the table-side response verification module also performs verification field error detection: it reads the verification field value of the table-side response frame according to the verification field position in the protocol frame template matching result, recalculates the frame content other than the verification field according to the verification algorithm specified in the DL / T645 protocol (usually checksum or CRC check), and compares the recalculated verification value with the read verification field value.

[0122] When a validation field error occurs, the table-side response validation module retains the original message index of the table-side response frame, writes the validation field error into the evidence index, and marks the table-side response stage as an abnormal state. However, it still attempts to parse the target return code field and marks the validation field error in the parsing result in order to retain as much on-site information as possible for subsequent auditing.

[0123] When performing semantic mapping on the target return code field, the table-side response verification module reads the field value of the target return code field (usually a single-byte or double-byte hexadecimal encoding). This encoded value is used as a key to retrieve the value from the return code rule mapping dictionary. The retrieval results include the return code meaning (e.g., "trip command received and executed," "trip command received but execution failed," "trip command not recognized," etc.), the parsing timestamp, and the template version number. To quantify the reliability of the target return code field parsing results, the table-side response verification module introduces a confidence score based on rule matching degree. This score considers both the matching certainty in the return code rule mapping dictionary and the historical frequency of the return code value in the current scenario.

[0124] Formula ③ constructs a confidence score in the form of log-likelihood based on the matching status of the target return code field value in the return code rule mapping dictionary and the prior probability of the return code value under the table model. This score is used to represent the credibility of the current target return code field parsing result.

[0125] Formula③

[0126]

[0127] in: : Confidence score for parsing the target return code field;

[0128] Natural logarithm function (in Euler's number) (logarithmic function with base 0)

[0129] Fraction (ratio) operator;

[0130] : The value of the conditional probability function;

[0131] Conditional probability operator (vertical line) (Indicates "under the condition of")

[0132] : Target return code field value;

[0133] Watch manufacturer and model number;

[0134] Trip type;

[0135] : Global prior probability;

[0136] : Preset to a very small positive number.

[0137] Extracted from the return code rule configuration table in the expense control business rules Extracted from the statistical results of historical response frames in the master station's communication message database. Together, they form the probability input in formula ③.

[0138] Formula ③ In , and After the frame structure consistency check is passed, it is used for location and extraction. That is, formula ③ directly uses the frame field positioning information provided by the measured state vector in formula ②.

[0139] when A value greater than the preset confidence upper bound (e.g., 1.0) indicates that the return code value has a significantly higher matching degree under the current conditions than the global prior, and is judged as a high-confidence parsing; when When the value is below the preset confidence lower bound (e.g., -1.0), it means that the matching degree of the return code value under the current conditions is lower than the global prior, and it is judged as a low confidence parsing and the low confidence state is written into the exception type.

[0140] Formula ③ addresses the practical problem that the same return code value may have different semantics under different combinations of meter manufacturer models and tripping types. Furthermore, some rare return code values ​​may have extremely low probability in global statistics but may be correct in specific scenarios. By comparing the conditional probability with the log-likelihood of the global prior, the semantic mapping process is quantified into a threshold-decision confidence score, avoiding the deficiency of the simple lookup table method in not being able to provide a confidence indication when encountering undefined return code values.

[0141] After completing the parsing of the target response code field, the table response verification module generates a table response verification record. This record includes the event identifier, protocol frame template matching result, table response frame index, response reception time, target response code field parsing result, table response stage status, and exception type.

[0142] When the protocol version in the electricity meter file is empty, the protocol template matching module first reads the default template according to the meter manufacturer model and meter address, and writes the missing protocol version into the protocol frame template matching result; when the control code and data identifier of the subsequent meter response frame are inconsistent with the default template, the protocol template matching module reads another template under the same meter manufacturer model for matching, and writes the template switching record into the meter response verification record.

[0143] The template switching record is only used as a record field for this meter response verification and does not change the original energy meter file. During the template switching process, the meter response verification module needs to determine whether the switched template produces a better matching effect, for which a template matching gain metric is introduced.

[0144] Formula ④ uses the frame structure consistency score calculated separately for the two templates before and after the handover. and Based on this, the gain value is defined as the normalized result of the difference between two scores. When the gain exceeds the preset switching threshold, the template switching is confirmed to be effective and the template version after switching is recorded.

[0145] Formula④

[0146]

[0147] in: Template switching gain value;

[0148] The frame structure consistency score calculated by formula ② when the default template is used before template switching;

[0149] The frame structure consistency score is recalculated using formula ② when another template from the same manufacturer and model is used after template switching.

[0150] : Preset to a very small positive number.

[0151] The specification template matching module executes formula ② according to the default template before switching to obtain the result. After switching, re-execute formula ② using the new template to obtain the result. Together, these two factors form the input score in formula ④.

[0152] Formula ④ directly uses the formula obtained from formula ② The value, namely the frame structure consistency score in Formula ②, serves as the basis for gain calculation in Formula ④.

[0153] when If the value exceeds the preset switching threshold (e.g., 0.15), the template switching is confirmed to be valid, the new template version is written into the table's response verification record, and the new version is used. The corresponding frame structure parsing result is used as the final parsing basis; when If the value is not greater than the preset switching threshold, the switching is deemed invalid, the parsing result of the default template is retained, and the invalid switching is marked in the template switching record.

[0154] Formula ④ addresses the practical problem that when the protocol version in the electricity meter file is empty, the default template may not be able to correctly parse the meter response frame. However, other templates under the same meter manufacturer and model may have a better matching effect. By calculating the gain value before and after the switch, we can quantitatively judge whether the switch has brought about a substantial improvement in parsing and avoid introducing new parsing errors due to blindly switching templates.

[0155] The S200 output table response verification record includes event identifier, protocol frame template matching result, table response frame index, response reception time, target return code field parsing result, table response stage status, and exception type.

[0156] The status of the table response phase is determined based on the results of the above verification link: when no table response frame is associated within the preset response time window, the status is response timeout; when a table response frame is associated but the address field is inconsistent or the verification field is incorrect, the status is abnormal; when the frame structure consistency score is... When the confidence score of the target return code field parsing is not greater than the preset consistency threshold, the status is abnormal; When the value falls below the preset confidence lower bound, the status is an abnormal state, and the target return code field mismatch is written into the exception type; when Greater than the preset consistency threshold and If the target response code field is greater than the preset upper bound and its semantic meaning is that the tripping instruction has been successfully received and executed, the status is "passed". In other cases, the response code is written to the corresponding stage status according to the response code rules in the fee control business rules.

[0157] In the target return code field parsing result, in addition to the field position, field value, return code meaning, parsing time, and template version, it also includes the confidence score calculated by formula ③. As an auxiliary quality indicator of the parsing result, the meter response verification record is read by S300. S300 calls the event identifier, trip time, and meter response stage status in the record and uses the record as preliminary evidence for load cut-off verification. When the meter response stage is a response timeout or the target return code field does not match, S300 can still read the load curve to form a load cut-off verification record and retain the anomaly type of the meter response stage in the load cut-off verification record.

[0158] The S200's protocol template matching module and table response verification module form a complete mapping from the original message to semantic parsing in the entire processing link. Formula ① completes the time window cross-correlation timestamp alignment, Formula ② completes the multi-dimensional joint verification of frame structure consistency, Formula ③ completes the semantic confidence quantification of the target return code field, and Formula ④ completes the template switching gain determination. Together, these four constitute the complete technical link of the protocol layer response verification.

[0159] Technical effects of this section: This section refines the verification of table-end response frames from simple frame reception confirmation to field-level semantic parsing and credibility measurement through four progressive indicators: time window cross-correlation alignment, state space consistency scoring, conditional log-likelihood ratio confidence determination, and template switching gain quantification. This allows five anomaly types—response timeout, address inconsistency, frame structure abnormality, return code semantic mismatch, and template configuration error—to be independently distinguished and associated with their corresponding evidence indexes, providing a verifiable specification-level evidence chain for subsequent load cut-off verification and compliance verification records.

[0160] S300. Based on the tripping event instance and the meter response verification record, determine the load verification window according to the tripping time, read the load curve in the load verification window, and compare the load value after tripping with the preset disconnection threshold to generate a load disconnection verification record.

[0161] In this embodiment, S300 is executed by the load disconnection verification module. The load disconnection verification module receives the tripping event instance generated in S100 and the meter response verification record generated in S200, and reads the load curve from the load curve database of the electricity consumption information acquisition system based on the account number, meter address, and tripping time in the tripping event instance. The load curve includes sampling time, load value, acquisition channel, data quality identifier, and freeze time; the load verification window is a time range configured with the tripping time as the starting point, used to extract a segment of the load curve after the trip.

[0162] The load disconnection verification module determines the load verification window based on the tripping time. Specifically, the load disconnection verification module reads the preset time range corresponding to the tripping type in the fee control business rules, and generates a window start time and a window end time starting from the tripping time. In one embodiment, the preset time range is 5 minutes to 15 minutes after the tripping; in another embodiment, the preset time range is configured according to the load curve acquisition cycle. After the load verification window is generated, the load disconnection verification module reads the load curve according to the user number, table address, window start time, and window end time, and binds the read load curve segment with the event identifier of the tripping event instance.

[0163] The load value after tripping is read from the load curve within the load verification window. Specifically, the load disconnection verification module first reads the sampling points in the load curve whose sampling time falls within the load verification window; when there are multiple sampling points, it reads the load value of the target sampling point after tripping according to the fee control business rules, and uses the load value of the target sampling point after tripping as the load value after tripping; in one embodiment, the target sampling point after tripping is the first hourly sampling point after tripping; in another embodiment, the target sampling point after tripping is the sampling point within the load verification window that is closest to the window termination time.

[0164] The preset disconnection threshold is generated jointly by the rated load in the electricity meter file and the prepaid service rules. Specifically, the load disconnection verification module reads the rated load in the electricity meter file and the threshold ratio of the corresponding tripping type in the prepaid service rules. The rated load is multiplied by the threshold ratio to obtain the preset disconnection threshold; in one embodiment, the threshold ratio is 5%. The load disconnection verification module compares the load value after tripping with the preset disconnection threshold; when the load value after tripping is lower than the preset disconnection threshold, the load disconnection verification stage is written to the pass status; when the load value after tripping is not lower than the preset disconnection threshold, the load disconnection verification stage is marked as an abnormal state and the abnormal type of load not disconnected is written.

[0165] In one implementation, the load disconnection verification module also reads the pre-trip load curve. The pre-trip load curve records the load status before the trip command is issued, including multiple sampling points within a preset time range before tripping. The load disconnection verification module writes the sampling time, load value, and data quality identifier of the pre-trip load curve into the load disconnection verification record; when the pre-trip load curve shows that the pre-trip load value is already lower than the preset disconnection threshold, the load disconnection verification module writes the pre-trip low load status into the evidence index and maintains the load disconnection verification stage as an undeterminable state or writes it as a passed state according to the fee control business rules.

[0166] When the load curve is missing, the freeze is delayed, or the quality indicator is abnormal, the load cut-off verification module marks the load cut-off verification stage as undeterminable. Specifically, when there are no sampling points in the load curve database that fall within the load verification window, "load curve missing" is written; when sampling points exist but the freeze time is later than the preset entry time, "freeze delay" is written; when the data quality indicator indicates collection failure, estimated value, or manual entry, "quality indicator abnormal" is written. For undeterminable states, the load cut-off verification module retains the load verification window, query conditions, and original query result index, and writes the undeterminable state into the stage status record.

[0167] In a specific implementation scenario, the tripping event instance occurs at 10:00:00 on July 1, 2026. The load disconnection verification module generates a load verification window from 10:05:00 to 10:15:00 according to the prepaid service rules, and reads the load curve for customer number U001 and meter address M001 within this time range from the load curve database. The rated load in the electricity meter file is 6kW, the threshold ratio in the prepaid service rules is 5%, and the preset disconnection threshold is 0.3kW. The load disconnection verification module reads the load value at 10:15:00 as 0.12kW, compares this load value with 0.3kW, writes the load disconnection verification stage as passed, and writes the load curve segment index into the evidence index.

[0168] The load disconnection verification record output by S300 includes an event identifier, a load verification window, a load curve segment index, a load value after tripping, a preset disconnection threshold, a load disconnection verification stage status, anomaly type, and a data quality identifier. S400 retrieves the event identifier, load disconnection verification stage status, and anomaly type from the load disconnection verification record and associates them with the power restoration service record. When the load disconnection verification stage is in an abnormal or undeterminable state, S400 still performs power restoration closed-loop verification and writes the load disconnection verification stage status into the preceding stage field of the power restoration closed-loop verification record.

[0169] S400: Based on the tripping event instance, the meter response verification record, and the load disconnection verification record, associate the overdue payment status, power restoration application work order, power restoration instruction record, and power restoration response frame, perform information verification on the completeness and time sequence of power restoration elements, and generate a power restoration closed-loop verification record.

[0170] In this embodiment, S400 is executed by the power restoration closed-loop verification module. The power restoration closed-loop verification module receives the trip event instance generated in S100, the meter response verification record generated in S200, and the load disconnection verification record generated in S300. Based on the account number, meter address, task serial number, and trip time in the trip event instance, it reads the overdue payment status, power restoration application work order, power restoration instruction record, and power restoration response frame from the marketing payment system, work order system, master station control log database, and master station communication message database, respectively. The power restoration closed-loop verification record is used to record the completeness of power restoration elements, the order of power restoration time, and the power restoration response status.

[0171] The outstanding payment status is obtained from the marketing payment system and includes the account number, outstanding amount status, outstanding payment time, and status update time. The power restoration application work order is obtained from the work order system and includes the account number, work order number, work order status, power restoration application time, and approval time. The power restoration instruction record is obtained from the main station control log database and includes the table address, power restoration instruction time, task serial number, channel identifier, and instruction status. The power restoration response frame is obtained from the main station communication message database and includes the table address, response reception time, control code, data identifier, target response code field, and original message index.

[0172] The power restoration closed-loop verification module first associates the overdue payment status and power restoration application work order by account number, and then associates the power restoration instruction record and power restoration response frame by table address and task serial number. For the correspondence between power restoration instruction records and tripping event instances, the module uses the same account number, the same table address, and the power restoration instruction time after the tripping time as matching conditions. When multiple power restoration instruction records exist, it reads the first power restoration instruction record after the power restoration application time and writes the unused power restoration instruction record into the evidence index. For the power restoration response frame, the module timestamps the table address, task serial number, power restoration instruction time, and response reception time. When a power restoration response frame is associated within a preset response time window, the module reads the target response code field of the power restoration response frame and writes it into the power restoration closed-loop verification record.

[0173] The information verification for the completeness of power restoration elements includes reading the overdue payment status, the work order status of the power restoration application, the power restoration instruction record, and the power restoration response frame. Specifically, when the overdue payment status is valid, the work order status is valid, a power restoration instruction record exists, and a power restoration response frame is associated with it within a preset response time window, the power restoration closed-loop verification module writes the completeness of power restoration elements into the pass status; when the overdue payment status is missing or invalid, it writes the exception type of missing power restoration elements; when the power restoration application work order is missing or the work order status is invalid, it writes the power restoration application missing or work order status abnormality; when the power restoration instruction record is missing, it writes the power restoration instruction missing; when the power restoration response frame is not associated with it within the preset response time window, it writes the power restoration response timeout.

[0174] The time sequence verification includes checking the chronological relationship between the overdue payment settlement time, the power restoration application time, and the power restoration command time. Specifically, the power restoration closed-loop verification module compares the overdue payment settlement time with the power restoration application time, and also compares the power restoration application time with the power restoration command time. If the overdue payment settlement time is later than the power restoration command time, an overdue payment settlement time anomaly is recorded; if the power restoration application time is later than the power restoration command time, a power restoration application time anomaly is recorded; if the power restoration command time is earlier than the tripping time, a power restoration command time anomaly is recorded. All of the above anomaly types are recorded in the power restoration closed-loop stage and bound to the evidence index of the corresponding overdue payment settlement status, power restoration application work order, power restoration command record, and power restoration response frame.

[0175] In one implementation, the power restoration closed-loop verification module also reads the stage status of the meter response verification record and the load disconnection verification record. When the preceding meter response stage is in an abnormal state, an abnormal meter response preceding field is written into the power restoration closed-loop verification record; when the preceding load disconnection verification stage is in a load not disconnected or undeterminable state, a load verification preceding field is written into the power restoration closed-loop verification record. The preceding field does not change the input object of the power restoration element completeness verification, but serves as the source of the stage status when S500 generates the compliance verification record.

[0176] In a specific implementation scenario, account number U001 reached a cleared overdue payment status at 10:30:00 on July 1, 2026. The work order system generated a power restoration application work order at 10:31:00, with the work order status being valid. The master station issued a power restoration command at 10:33:00, and the master station communication message database recorded a power restoration response frame at 10:33:02. After reading the above records, the power restoration closed-loop verification module completed the association based on account number U001 and table address M001. Since the overdue payment clearing time was earlier than the power restoration application time, the power restoration application time was earlier than the power restoration command time, and the power restoration response frame fell within the preset response time window, the power restoration closed-loop verification module wrote the power restoration closed-loop stage into the pass status and wrote the work order number, power restoration command record index, and power restoration response frame index into the evidence index.

[0177] The power restoration closed-loop verification record output by S400 includes event identifiers, overdue payment status, power restoration application work order index, power restoration instruction record index, power restoration response frame index, power restoration element completeness verification result, time sequence verification result, power restoration closed-loop stage status, and anomaly type. S500 reads the power restoration closed-loop verification record and updates the stage status record together with the meter response verification record and load disconnection verification record; the evidence index in the power restoration closed-loop verification record is written as part of the compliance verification record.

[0178] S500. Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, update the stage status record and write the evidence index into the compliance verification record.

[0179] In this embodiment, S500 is executed by the compliance result output module. The compliance result output module receives the meter response verification record generated in S200, the load disconnection verification record generated in S300, and the power restoration closed-loop verification record generated in S400, and reads the stage status record generated in S100. The compliance result output module associates the above records according to the event identifier and writes the status fields of the meter response stage, load disconnection verification stage, and power restoration closed-loop stage into the same compliance verification record. The compliance verification record is used to store the stage status, anomaly type, evidence index, and compliance score of a single trip event instance.

[0180] The compliance result output module first reads the stage status record according to the event identifier, then reads the table response stage status, target return code field parsing result, and exception type from the table response verification record; it reads the load disconnection verification stage status, tripped load value, preset disconnection threshold, and exception type from the load disconnection verification record; and it reads the power restoration closed-loop verification stage status, power restoration element completeness verification result, time sequence verification result, and exception type from the power restoration closed-loop verification record. The compliance result output module writes the above stage status into the stage status record and updates the original pending verification status of each stage to a pass status, an abnormal status, or an undeterminable status.

[0181] In one implementation, the anomaly type is directly written into the verification records of each stage. Specifically, when the table response verification record contains a response timeout, target return code field mismatch, or verification field error, the compliance result output module writes the corresponding anomaly type into the compliance verification record; when the load disconnection verification record contains load not disconnected, load curve missing, freeze delay, or quality identifier anomaly, the compliance result output module writes the corresponding anomaly type into the compliance verification record; when the power restoration closed-loop verification record contains missing power restoration elements, missing power restoration application, missing power restoration instruction, power restoration response timeout, or time sequence anomaly, the compliance result output module writes the corresponding anomaly type into the compliance verification record. When multiple stages contain anomaly types, the compliance result output module writes the anomaly type sequence in stage order and retains the evidence index corresponding to each anomaly type.

[0182] In another implementation, the compliance result output module calculates compliance scores for the meter response stage, load disconnection verification stage, and power restoration closed-loop stage according to preset weights. Specifically, the compliance result output module records a pass status as a pass score, an abnormal status as an abnormal score, and an undeterminable status as an undeterminable score; then, it reads the stage weights configured in the expense control business rules and performs a weighted calculation on the meter response stage, the load disconnection verification stage, and the power restoration closed-loop stage to generate a compliance score. In one implementation, the weight of the meter response stage is 0.3, the weight of the load disconnection verification stage is 0.4, and the weight of the power restoration closed-loop stage is 0.3. The compliance score and stage status are written together into the compliance verification record.

[0183] The evidence index is formed by merging records from each stage. The compliance result output module reads the table response frame index and the protocol frame template matching result index from the table response verification record; it reads the load curve segment index from the load cut-off verification record; and it reads the overdue payment settlement status index, power restoration application work order index, power restoration instruction record index, and power restoration response frame index from the power restoration closed-loop verification record. The compliance result output module writes the above indexes into the compliance verification record in the order of the stage status records. For stages with undeterminable states, the compliance result output module writes the query conditions, query time, and query return status as components of the evidence index for that stage.

[0184] When updating stage status records, the compliance result output module handles status conflicts. When multiple status sources exist for the same stage, the stage record is read based on the same event identifier, stage name, and latest timestamp. When multiple status sources point to different states, abnormal states are retained first, followed by undetermined states, and then the passed state is written. Simultaneously, the record indexes of each status source are written to the evidence index. This process does not delete the original stage records; the original records are retained in the corresponding table response verification records, load cut-off verification records, and power restoration closed-loop verification records.

[0185] The compliance verification record generated by S500 includes an event identifier, account number, table address, task serial number, trip time, stage status, anomaly type, evidence index, and compliance score. This compliance verification record is written to the compliance verification record database and maintains consistency with the event identifier of the trip event instance. When subsequent review task records call upon this compliance verification record, the stage status and evidence index are read according to the event identifier. When a delayed meter response frame, load curve, or power restoration response frame is subsequently added, the compliance result output module rereads the corresponding stage record according to the event identifier, updates the stage status record, and generates a new version of the compliance verification record.

[0186] Example 2: Figure 2A structural block diagram of a compliance verification system for electricity meter tripping events according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0187] The event instance generation module 01 is used to receive the master station tripping instruction issuance log, electricity meter files, and fee control business rules, and analyze event records according to the account number, meter address, task serial number, and tripping time to generate tripping event instances and stage status records. Specifically, the event instance generation module receives the master station tripping instruction issuance log from the master station, receives electricity meter files from the electricity meter file library, and receives fee control business rules. The master station tripping instruction issuance log includes the account number, meter address, task serial number, tripping time, tripping type, instruction status, channel identifier, and rule version. The event instance generation module reads fields and analyzes event records according to the account number, meter address, task serial number, and tripping time, and generates tripping event instances and stage status records according to the account number, meter address, task serial number, and tripping time. The water number and the trip time are combined to form an event identifier, which is then written into the trip event instance. The stage status record includes the instruction issuance stage, the meter response stage, the load disconnection verification stage, and the power restoration closed-loop stage. Each stage records the status field, timestamp, data source, and evidence index. When the account number, meter address, or trip time is missing, the event instance generation module marks the instruction issuance stage as an abnormal state and retains the original record index of the master station trip instruction issuance log. The event instance generation module provides the trip event instance and the stage status record to the meter response verification module, which then uses the account number, meter address, task flow number, and trip time from the trip event instance for subsequent association.

[0188] Meter response verification module 02, connected to the event instance generation module, is used to read the meter manufacturer model and protocol version from the electricity meter file based on the trip event instance, match the DL / T645 protocol frame template, associate the meter response frame within a preset response time window, and perform response frame parsing and target response code field verification on the meter response frame to generate a meter response verification record. Specifically, the meter response verification module receives the trip event instance from the event instance generation module and reads the meter manufacturer model, protocol version, meter address, control code, and data identifier from the electricity meter file based on the user number and meter address in the trip event instance; the meter response verification module matches the DL / T645 protocol frame template according to the meter manufacturer model and protocol version, and generates a preset response time window based on the trip time; the meter response verification module reads the meter response frame from the master station communication message, and performs response frame parsing and target response code field verification on the user number, meter address, and target response code field verification to generate a meter response verification record. The service serial number, trip time, and response reception time are timestamped and aligned. When a meter-end response frame is associated within the preset response time window, the meter-end response verification module reads the control code, data identifier, and target return code field according to the DL / T645 protocol frame template, and verifies the target return code field with the return code field in the fee control service rules. When no meter-end response frame is associated within the preset response time window, the meter-end response verification module marks the meter-end response stage as a response timeout and writes an exception type. The meter-end response verification record includes an event identifier, protocol frame template matching result, meter-end response frame index, response reception time, target return code field parsing result, meter-end response stage status, and exception type. The meter-end response verification module provides the trip event instance and the meter-end response verification record to the load cut-off verification module, and the load cut-off verification module calls the trip time and the meter-end response stage status.

[0189] The load cut-off verification module 03, connected to the meter response verification module, is used to determine the load verification window based on the tripping event instance and the meter response verification record, according to the tripping time. It reads the load curve within the load verification window and compares the post-tripping load value with a preset cut-off threshold to generate a load cut-off verification record. Specifically, the load cut-off verification module receives the tripping event instance and the meter response verification record from the meter response verification module and reads the account number, meter address, and tripping time from the tripping event instance. The load cut-off verification module determines the load verification window according to the time range corresponding to the tripping type in the fee control business rules and reads the load curve within the load verification window from the load curve record. The load curve includes sampling time, load value, acquisition channel, data quality identifier, and freeze time. The load cut-off verification module reads the target sampling point load value after tripping from the load curve and compares the target sampling point load value after tripping with the meter response verification record. The load value after tripping is used as the load value; the preset disconnection threshold is generated based on the rated load in the electricity meter file and the threshold configuration in the prepaid business rules; the load disconnection verification module compares the load value after tripping with the preset disconnection threshold and writes the comparison result into the load disconnection verification stage; when the load curve is missing, there is a freeze delay, or the quality identifier is abnormal, the load disconnection verification module marks the load disconnection verification stage as an undeterminable state; when the load value after tripping is not lower than the preset disconnection threshold, the load disconnection verification module marks the load disconnection verification stage as an abnormal state and writes the abnormal type of load not disconnected; the load disconnection verification record includes an event identifier, a load verification window, a load curve index, a load value after tripping, a preset disconnection threshold, a load disconnection verification stage status, and an abnormal type; the load disconnection verification module provides the tripping event instance, the meter response verification record, and the load disconnection verification record to the power restoration closed-loop verification module.

[0190] The power restoration closed-loop verification module 04, connected to the load disconnection verification module, is used to verify the completeness and time sequence of power restoration elements based on the tripping event instance, the meter response verification record, and the load disconnection verification record, as well as the overdue payment status, power restoration application work order, power restoration instruction record, and power restoration response frame, and generate a power restoration closed-loop verification record. Specifically, the power restoration closed-loop verification module receives the tripping event instance, meter response verification record, and load disconnection verification record from the load disconnection verification module, and based on the... In a tripping event instance, the system retrieves the account number, table address, task serial number, and tripping time, along with the overdue payment status, power restoration application work order, power restoration instruction record, and power restoration response frame. The overdue payment status includes the account number, overdue amount status, overdue payment time, and status update time. The power restoration application work order includes the account number, work order number, work order status, power restoration application time, and approval time. The power restoration instruction record includes the table address, power restoration instruction time, task serial number, channel identifier, and instruction status. The power restoration response frame includes the table address and response reception time. The system includes control codes, data identifiers, target response code fields, and original message indexes. The power restoration closed-loop verification module associates the outstanding payment status and power restoration application work order with the account number, and associates the power restoration instruction record and power restoration response frame with the table address, task serial number, and power restoration instruction time. When the outstanding payment status is valid, the work order status is valid, a power restoration instruction record exists, and a power restoration response frame is associated within a preset response time window, the power restoration closed-loop verification module verifies the chronological relationship between the outstanding payment time, the power restoration application time, and the power restoration instruction time. If the outstanding payment status is missing... When a power restoration application work order is missing, a power restoration instruction record is missing, or a power restoration response frame is not associated, the power restoration closed-loop verification module writes the corresponding exception type. The power restoration closed-loop verification record includes an event identifier, an overdue payment status index, a power restoration application work order index, a power restoration instruction record index, a power restoration response frame index, a power restoration closed-loop stage status, and an exception type. The power restoration closed-loop verification module provides the power restoration closed-loop verification record to the compliance result output module, and simultaneously provides the stage status of the meter response verification record and the load disconnection verification record.

[0191] The compliance result output module 05, connected to the power restoration closed-loop verification module, is used to update the stage status record based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, and write the evidence index into the compliance verification record. Specifically, the compliance result output module receives the power restoration closed-loop verification record from the power restoration closed-loop verification module and reads the meter response verification record and the load disconnection verification record; the compliance result output module associates the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record according to the event identifier, and reads the meter response stage status, the load disconnection verification stage status, and the power restoration closed-loop stage status; the compliance result output module writes the status of each stage into the stage status record, and adds the meter response frame index, the protocol frame template matching result index, the load curve index, the overdue payment settlement status index, the power restoration application work order index, and the power restoration instruction record. The index and power restoration response frame index are written into the evidence index; when multiple stages have anomaly types, the compliance result output module writes the anomaly types in the order of meter response stage, load disconnection verification stage, and power restoration closed-loop stage; when multiple status sources exist in the same stage, the compliance result output module reads the status source by timestamp and retains the evidence index corresponding to each status source; the compliance verification record includes event identifier, account number, table address, task serial number, trip time, stage status, anomaly type, and evidence index; the compliance result output module keeps the compliance verification record and the trip event instance under the same event identifier and writes the compliance verification record into the record database.

Claims

1. A compliance verification method for electricity meter tripping events, characterized in that, include: S100: Receive the master station tripping instruction log, electricity meter file and fee control business rules, perform event record analysis by account number, meter address, task serial number and tripping time, and generate tripping event instances and stage status records. The stage status records include instruction issuance stage, meter response stage, load disconnection verification stage and power restoration closed loop stage. S200. Based on the tripping event instance, read the meter manufacturer model and protocol version in the electricity meter file, match the DL / T645 protocol frame template, associate the meter response frame within the preset response time window, and perform response frame parsing and target return code field verification on the meter response frame to generate a meter response verification record. S300. Based on the tripping event instance and the meter response verification record, determine the load verification window according to the tripping time, read the load curve in the load verification window, and compare the load value after tripping with the preset disconnection threshold to generate a load disconnection verification record. S400: Based on the tripping event instance, the meter response verification record and the load disconnection verification record, associate the overdue payment status, power restoration application work order, power restoration instruction record and power restoration response frame, perform information verification on the completeness and time sequence of power restoration elements, and generate a power restoration closed-loop verification record. S500. Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, update the stage status record and write the evidence index into the compliance verification record.

2. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S100, the generated trip event instances include: Read the account number, table address, task serial number, trip time, trip type, instruction status, channel identifier, and rule version from the main station trip instruction issuance log; The account number, the table address, the task serial number, and the trip time are combined into an event identifier, and the trip type, the instruction status, the channel identifier, and the rule version are written into the instruction issuance stage.

3. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S100, the stage status record includes a pending verification status, a passed status, an abnormal status, and an undeterminable status; each stage status is bound to a data source, a timestamp, and an evidence index.

4. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S200, the DL / T645 protocol frame template includes the DL / T645-1997 template and the DL / T645-2007 template; the matching of the DL / T645 protocol frame template includes: reading the meter manufacturer model, protocol version, meter address, control code and data identifier from the electricity meter file, and generating a protocol frame template matching result based on the meter manufacturer model, the protocol version, the meter address, the control code and the data identifier.

5. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S200, the associated response frames within the preset response time window include: The master station trip command issuance log and the table terminal response frame are timestamped according to the account number, the table address, the task serial number, the trip time, and the response reception time. If no response frame is associated with the table terminal within the preset response time window, the table terminal response stage is marked as a response timeout and an exception type is written.

6. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S300, determining the load verification window based on the tripping time includes: Starting from the tripping time, read the load curve within a preset time range after the tripping. Read the load value of the target sampling point after the trip from the load curve, and use the load value of the target sampling point after the trip as the load value after the trip.

7. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S300, the generation of load disconnection verification records includes: When the load curve is missing, the freeze is delayed, or the quality identification is abnormal, the load cut-off verification stage will be marked as an undeterminable state. When the load value after the trip is not lower than the preset disconnection threshold, the load disconnection verification stage is marked as an abnormal state and the abnormal type of load not disconnected is written.

8. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S400, the information verification for the completeness and time sequence of power restoration elements includes: Read the overdue payment status, the power restoration application work order status, the power restoration instruction record, and the power restoration response frame; When the overdue payment settlement status is valid, the work order status is valid, the power restoration instruction record exists, and the power restoration response frame is associated with the preset response time window, the order of overdue payment settlement time, power restoration application time, and power restoration instruction time are checked for their sequential relationship.

9. The compliance verification method for electricity meter tripping events according to claim 1, characterized in that, In S500, the generation of compliance verification records includes: Based on the meter response verification record, the load disconnection verification record, and the power restoration closed-loop verification record, the anomaly type is determined; The compliance score is calculated based on the preset weights for the meter response stage, the load disconnection verification stage, and the power restoration closed-loop stage. The stage status, the anomaly type, the evidence index, and the compliance score are written into the compliance verification record.

10. A compliance verification system for electricity meter tripping events, characterized in that, include: Event instance generation module, meter response verification module, load disconnection verification module, power restoration closed-loop verification module, compliance result output module; The system is used to implement the method described in any one of claims 1-9.

Images