Electric energy metering box data interaction method and system based on internet of things

Abstract

The application relates to the technical field of digital information transmission of the Internet of Things, and discloses an electric energy metering box data interaction method and system based on the Internet of Things. The system comprises a metering box device, a metering box interaction terminal, an Internet of Things communication network and a master station. The terminal segments data, establishes a data interaction batch of associated data segments, a master station confirmation state, a target operation item and a receipt, and sends a terminal state descriptor; the master station compares the descriptor with a master station state, and generates a joint difference interaction instruction containing a data segment confirmation indication, a missing data segment indication and a target operation item bound to a pre-state execution state. The terminal supplements a missing data segment, checks based on a non-volatile execution record and idempotently executes a target operation item, and returns a closed-loop receipt; and the master station sends a convergence confirmation according to data and receipt states. The application can reduce unnecessary transmission in link recovery, avoid errors and repeated execution caused by state mismatch or retransmission, and supplement closed event evidence through a minimum evidence package and a missing evidence segment.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) digital information transmission technology, specifically to a data interaction method and system for electricity metering boxes based on IoT. Background Technology

[0002] Electricity metering boxes typically contain electricity meters and auxiliary equipment for collecting data on box door status, temperature, or switch status. Existing data exchange systems generally involve the metering box-side terminal collecting data from these devices via a local interface and uploading it to the main station via cellular networks, low-power wide-area networks, wired networks, or other IoT links. The main station can also send status queries, data supplementation requests, parameter configurations, or equipment control information to the metering box-side terminal.

[0003] When metering boxes are in environments with fluctuating wireless coverage, link congestion, or temporary network outages, existing systems typically implement separate buffering, retransmission, and acknowledgment for uplink data and downlink commands. Due to the lack of unified constraints between data acknowledgment status, device topology or configuration version, and command execution status, issues such as duplicate transmission of received data, inaccurate location of missing data, continued execution of historical commands after device status changes, or duplicate execution caused by lost acknowledgments can easily occur after link recovery. In scenarios involving multiple vendors, multiple protocols, dual links, or inter-box forwarding, link switching or device changes may also lead to the loss of existing acknowledgment status and trigger session reconstruction.

[0004] Furthermore, abnormal events are typically associated with data, device status, and operation records before and after their triggering. When bandwidth is limited, uploading all associated content at once will delay event arrival, while uploading only alarm information makes it difficult to guarantee the completeness of the content required for subsequent verification. Therefore, the existing data interaction method for electricity metering boxes still needs improvement in areas such as weak network recovery, consistency of uplink and downlink status, control execution security, and complete transmission of event information. Summary of the Invention

[0005] This invention aims to solve the problems of inconsistent understanding between the metering box interaction terminal and the master station regarding data generation and reception status, device status, and command execution results during intermittent connection, congestion, reconnection, or switching of IoT power metering boxes. These problems lead to repeated data transmission, incorrect execution of historical commands after changes in device status, repeated execution of target operation items, and the inability to achieve a coherent data and operation result closure. The invention provides a data interaction method and system for IoT-based power metering boxes, enabling uplink data recovery and downlink control or parameter configuration to be completed under the same communication state constraints.

[0006] To achieve the above objectives, the first aspect of the present invention provides a data interaction method for an electricity metering box based on the Internet of Things, which is executed collaboratively by the metering box interaction terminal and the master station through an Internet of Things communication network.

[0007] The metering box interaction terminal acquires data generated by the metering box device, divides the data into data segments, and establishes data interaction batches based on the metering box identifier, device status version, and acquisition window. The data interaction batch, as referred to in this document, is an interaction status unit used to collect and determine the data segments, master station confirmation status, target operation items, and their execution receipts under the device status version and acquisition window, rather than simply a communication cycle divided according to a fixed duration. The device status version includes the device topology version and the device configuration version; the batch identifier of the data interaction batch is jointly determined by the metering box identifier, device topology version, device configuration version, acquisition window, and local batch sequence number. The device topology version is updated when a device is added, deleted, replaced, or its capabilities change; the device configuration version is updated when device parameters or protocol field mappings change while the device connection relationship remains unchanged; a new data interaction batch is established when the device status version changes, and the migration relationship pointing to the new data interaction batch is recorded in the original data interaction batch.

[0008] Each data segment is associated with a device identifier, data type, acquisition time or acquisition window identifier, segment number, and integrity verification information. The metering box interaction terminal first writes the data segment and its metadata into non-volatile memory, and then includes the data segment in the range of generated data segments after completing the integrity verification. Thus, even after the terminal loses power, the communication link is interrupted, or the session is re-established, the terminal can still reconstruct the range of data segments to be interacted and their corresponding status based on the non-volatile storage content, without relying on whether a message has been sent as the basis for releasing data.

[0009] The metering box interaction terminal generates a terminal status descriptor for each data interaction batch and sends it to the master station. The terminal status descriptor represents the range of generated data segments, the master station confirmation set, and the command execution receipt status. It can also represent the device topology version, device configuration version, evidence summary of pending events, the set of command receipts to be confirmed or executed, the protocol field mapping version, and link continuity information. The master station saves its status for each metering box identifier and data interaction batch. This master station status represents the set of data segments that have been fully received, the set of confirmed command receipts, the received event evidence, and the device status version recorded by the master station.

[0010] The master station compares the terminal status descriptor with the master station status of the corresponding data exchange batch to determine the missing data segments that the terminal has generated but the master station has not yet fully received, and identifies the target operation item carrying an instruction identifier used to change the metering box's operating or configuration status. Based on this, the master station generates a joint differential interaction instruction. This joint differential interaction instruction simultaneously includes a data segment confirmation indication, a missing data segment indication, and a target operation item bound to the execution preconditions, establishing a link between the data confirmation relationship and the downlink operation relationship within the same communication instruction, rather than processing them separately through unrelated upload recovery and command replay processes.

[0011] The master station confirmation set can be represented by a segment identifier list, an interval set, a bitmap, or a digest tree. When using a digest tree, the master station requests the identifiers of the corresponding branches or data segments level by level after a digest comparison shows inconsistencies, forming a missing data segment indication that can indicate discontinuous data segments. This representation method is used to determine the difference between the data segments that the master station has completely received and the data segments that the terminal has generated, and is not limited to the specific cellular standard, message encoding format, or digest algorithm used in the IoT communication network.

[0012] The pre-execution status includes the target data interaction batch, the target device status version, and the specified data segment confirmation point. Further limitations can be made regarding the target device topology version, target device configuration version, the evidence closure status of the target event, or the completion status of the previous associated target operation. After receiving the joint differential interaction command, the metering box interaction terminal updates the locally stored master station confirmation set according to the data segment confirmation instruction and sends the corresponding data segment according to the missing data segment instruction. For the target operation, the terminal sequentially verifies the integrity and permissions of the joint differential interaction command, the correspondence between the target metering box device and the current device topology, whether the current device status version is consistent with the target device status version, whether the specified data segment has been confirmed by the master station, and whether the target event or the previous associated target operation is in an executeable state.

[0013] When the current state does not meet the prerequisites for execution, the metering box interactive terminal refuses to execute the target operation item and generates a state inconsistency receipt. The state inconsistency receipt includes an instruction identifier, an inconsistency field, the current device topology version, the current device configuration version, the current confirmation status of the specified data segment, and a summary of the current terminal status descriptor. After receiving the state inconsistency receipt, the master station marks the target operation item corresponding to the original instruction identifier as unexecutable and cancels the target operation item based on the current terminal status descriptor, or re-determines the missing data segment and the prerequisites for execution, and generates a joint differential interactive instruction with a new instruction identifier to avoid directly replaying the original target operation item when the state basis has changed.

[0014] When the current state meets the pre-execution requirements, the metering box interactive terminal queries the non-volatile execution record based on the instruction identifier of the target operation item. Before executing the target operation item, the terminal writes the instruction identifier, the pre-execution state summary, and the state to be executed into the non-volatile memory. After execution, the terminal persists the execution result, the post-execution device state version, and the data segment identifier associated with the execution result in an atomic or recoverable write order, forming a closed-loop receipt. If the terminal receives another target operation item with the same instruction identifier, it compares the pre-execution state summary of the target operation item with the non-volatile execution record. Instead of changing the metering box device's operating or configuration state again, it returns the existing closed-loop receipt or its verifiable summary. This process ensures that the target operation item remains idempotent in the event of receipt loss, duplicate instruction issuance, or link switching.

[0015] The closed-loop receipt is associated with the instruction identifier, execution result, post-execution status, and data segment identifier. The master station determines whether the data interaction batch has converged based on the data segment reception status and the closed-loop receipt reception status. When the missing data segment belonging to the data interaction batch has been received, the target operation item has been executed, or a clear non-execution result has been obtained and the corresponding receipt has been confirmed, the master station sends a convergence confirmation; the metering box interaction terminal marks the corresponding data interaction batch as closed based on the convergence confirmation and releases the corresponding data and receipt according to the storage strategy. When the device status version changes during the interaction, the old data interaction batch only continues to process the data retransmission and receipt confirmation corresponding to the original status, and does not execute new target operation items that do not match the current status.

[0016] Furthermore, for events generated by the metering box equipment, the metering box interactive terminal assigns an event identifier to the event and organizes the event header, pre-trigger data segment, trigger or post-trigger data segment, and associated device status or operation log into an event evidence segment set. The terminal status descriptor records the event identifier, evidence summary, and event closure status. When the available transmission resources of the IoT communication network are limited, the terminal first sends a minimum evidence packet. This minimum evidence packet includes an event header, an evidence summary of the event evidence segment set, an evidence segment index, and pre-determined key evidence segments, enabling the master station to identify the event and determine missing evidence segments even before receiving all event evidence segments.

[0017] The master station generates a missing evidence segment indication based on the evidence segment index and the received evidence segments. The metering box interaction terminal determines the retransmission order based on the urgency of the event, the degree of evidence missing, and the risk of cache eviction, and only retransmits the evidence segments corresponding to the missing evidence segment indication. After the master station has received all necessary evidence segments and the evidence digests are verified to be consistent, it sends an event closure confirmation; the terminal persists the event closure confirmation before releasing the corresponding event evidence segment according to the storage policy. If the link is interrupted again during the retransmission process, the terminal status descriptor continues to carry the unclosed state of the event and the digests of the sent evidence segments, enabling the master station to continue requesting the remaining evidence segments after the link is restored.

[0018] Furthermore, for metering box devices using different local communication protocols, the metering box interaction terminal stores the protocol identifier, device capability set, and protocol field mapping version for each metering box device. The target operation item uses a unified logical object identifier and carries the target protocol field mapping version. The terminal verifies whether the target metering box device supports the target operation item based on the device capability set, and converts the verified target operation item into the corresponding protocol message for that device. When the target protocol field mapping version is inconsistent with the current protocol field mapping version, the terminal returns a version inconsistency receipt; the master station can issue the changed field mapping entries while maintaining the existing master station confirmation set, the terminal updates the device configuration version, and establishes a new data interaction batch associated with the original data interaction batch.

[0019] Furthermore, when the metering box interaction terminal switches from the first uplink to the second uplink or is forwarded via another metering box, the terminal carries the batch identifier of the original data interaction batch, the most recent acknowledgment window summary of the original link, the most recent instruction receipt identifier, the new link identifier, and anti-replay information in the first session message of the new link. After the master station verifies the first session message, it binds the new link to the original data interaction batch and returns the current master station acknowledgment set; the terminal retransmits the unacknowledged data segments according to the master station acknowledgment set, and uses the original instruction identifier of the unclosed target operation item. When the link continuity verification fails, the master station requests a complete terminal state descriptor and suspends the execution of the unclosed target operation item in the original link until the state comparison is completed again. Therefore, a simple link switch or change in the forwarding path does not necessarily lead to the establishment of a new data interaction batch.

[0020] A second aspect of the present invention provides an Internet of Things (IoT)-based data interaction system for electricity metering boxes, including metering box equipment, metering box interaction terminal, IoT communication network, and master station.

[0021] The metering box interaction terminal includes a device access interface, non-volatile memory, a terminal communication interface, and a terminal processor. The device access interface obtains data from the metering box device and transmits target operation items to the metering box device to change its operating or configuration status. The non-volatile memory stores data segments, data interaction batch status, instruction identifiers, and closed-loop receipts. The terminal communication interface communicates with the master station via an IoT communication network. The terminal processor establishes associated data segments, master station confirmation status, target operation items, and execution receipts for data interaction batches; generates terminal status descriptors; updates or sends data segments based on data segment confirmation and missing data segment indications; verifies the pre-execution status of target operation items and performs idempotent execution; and generates closed-loop receipts for the device status and data segments after associated execution.

[0022] The master station includes a master station communication interface, a state repository, a differential and control processor, and a convergence processor. The state repository stores the master station status according to the metering box identifier and data exchange batch; the differential and control processor compares the terminal status descriptor with the master station status and generates a joint differential interaction instruction that simultaneously includes a data segment acknowledgment indication, a missing data segment indication, and a target operation item bound to the execution pre-state; the convergence processor determines whether the data exchange batch has converged based on the data segment reception status and the closed-loop acknowledgment status and generates a convergence confirmation.

[0023] The metering box interaction terminal may also include an event evidence management unit, a protocol adaptation unit, and a link continuity unit. The main station may also include an event evidence closure unit, a version management unit, and a link continuity verification unit. The event evidence management unit and the event evidence closure unit cooperate to form a minimum evidence packet, identify missing evidence segments, retransmit evidence segments, and close events after the evidence digest verification is consistent. The protocol adaptation unit and the version management unit cooperate to unify the conversion and mapping version updates between logical objects and different local communication protocol messages. The link continuity unit and the link continuity verification unit cooperate to maintain the continuity between the original data interaction batches, confirmation windows, and most recent instruction receipts during dual uplink switching or inter-box forwarding.

[0024] This invention groups data segments, master station confirmation status, target operation items, and their execution receipts into the same data interaction batch. It generates a joint differential interaction instruction through dual-end status comparison, ensuring that the terminal only retransmits the data segments actually missing from the master station. Simultaneously, it constrains the execution of target operation items with data confirmation points and device status versions. By combining instruction identifiers, non-volatile execution records, status inconsistency receipts, and closed-loop receipts, it avoids continuing to execute historical target operation items after device status changes, prevents the same target operation item from being repeatedly executed due to instruction retransmission, and enables the master station to jointly confirm the data reception status and operation execution results. This reduces unnecessary data transmission during link recovery and improves the consistency and traceability of data interaction status under conditions of weak networks, reconnection, or link switching.

[0025] This invention further maintains the verifiable integrity of event evidence under limited transmission resources by using minimum evidence packets, supplementary transmission of missing evidence segments, and event closure confirmation. Through unified logical objects, device capability verification, and protocol field mapping versions, it enables metering box devices from different manufacturers or with different local communication protocols to access the same data interaction process. By continuing batch identification, confirmation window, and instruction receipt relationships during dual uplink switching or inter-box forwarding, it ensures that link changes do not disrupt the existing interaction state. Therefore, without limiting specific local communication protocols, IoT communication standards, or message encoding formats, the adaptability of the electricity metering box data interaction mechanism to limited links, heterogeneous devices, and changes in communication paths can be improved. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the structure of an IoT-based data interaction system for electricity metering boxes according to the present invention.

[0027] Figure 2 This is a flowchart illustrating a data interaction method for an electricity metering box based on the Internet of Things according to the present invention.

[0028] Figure 3 This is a schematic diagram illustrating the data relationship between the terminal status descriptor and the joint differential interaction command of the present invention.

[0029] Figure 4 This is a schematic diagram illustrating the state transition for the pre-verification of the target operation item and the idempotent execution of the present invention.

[0030] Figure 5 This is a schematic diagram of the minimum evidence package for events in this invention and the process of supplementing missing evidence.

[0031] Figure 6 This is a timing diagram illustrating session continuity during the dual uplink switching or inter-box forwarding process of the present invention. Detailed Implementation

[0032] The embodiments of the present invention will be further described below with reference to the accompanying drawings. It should be noted that the following embodiments are used to illustrate the technical solutions of the present invention, and not to limit the scope of protection of the present invention. Where there is no conflict, the technical features in the following embodiments can be combined with each other. Communication interfaces, data encoding, integrity verification, and authentication methods not specifically limited can adopt corresponding existing implementations according to the deployment environment; the present invention focuses on the correlation and convergence relationship between the data status, operation status, and receipt status between the metering box interactive terminal and the main station.

[0033] In this application, the metering box device includes an electricity meter and at least one of auxiliary sensing devices and control devices related to the operation of the metering box. The metering box interaction terminal is an edge terminal that connects to the metering box device and communicates with the master station via the Internet of Things. The data interaction batch is an interactive status unit used to collect and determine the device status version and data segments under the acquisition window, the master station confirmation status, the target operation item and its execution receipt. The target operation item is an operation item carrying an instruction identifier and used to change the operating status or configuration status of the metering box device. It can correspond to parameter configuration, time synchronization, status reset, or authorized control when there is corresponding device capability and operation permission; data supplementation or device query can be used as an interactive action associated with the target operation item. The data interaction batch is not equivalent to a network connection, nor is it required to re-establish it during link switching.

[0034] Example 1

[0035] like Figure 1 As shown, the electricity metering box data interaction system of this embodiment includes a metering box device 110, a metering box interaction terminal 120, an Internet of Things communication network 130, and a master station 140. The metering box device 110 may include one or more meters, status acquisition devices, and devices capable of receiving control or configuration. The metering box device 110 and the metering box interaction terminal 120 transmit acquired data, device status, capacity information, and operation results. The metering box interaction terminal 120 transmits the local operation message corresponding to the verified target operation item to the metering box device 110.

[0036] The metering box interaction terminal 120 includes a device access interface 121, a non-volatile memory 122, a terminal communication interface 123, and a terminal processor 124. The device access interface 121 receives data generated by different metering box devices 110 and transmits local operation messages output by the terminal processor 124 to the corresponding metering box device 110. The device access interface 121 may include one interface or multiple interfaces oriented to different local communication protocols; its physical form does not constitute a limitation on this embodiment.

[0037] The non-volatile memory 122 stores at least the data segment, data interaction batch status, master station confirmation set, instruction identifier, execution pre-state summary, execution status of the target operation item, and closed-loop receipt. The non-volatile memory 122 can store these objects in a single storage area, or it can store them separately in a data segment area, a batch status area, and an execution record area. Regardless of the organization method, after the terminal is powered off or restarted, the terminal processor 124 can read the unclosed data interaction batch and corresponding execution record. The terminal communication interface 123 exchanges terminal status descriptors, data segments, joint differential interaction instructions, closed-loop receipts, and convergence confirmations with the master station communication interface 141 via the IoT communication network 130. The IoT communication network 130 can consist of a single uplink, or it can include a primary link, a backup link, or an inter-box forwarding path.

[0038] The terminal processor 124 performs batch management of data interaction, generation of terminal status descriptors, pre-execution status verification, idempotent execution of target operation items, generation of closed-loop receipts, and batch convergence processing. Figure 1 The event evidence management unit 125, protocol adaptation unit 126, and link continuity unit 127 shown can be implemented by the terminal processor 124 executing corresponding programs, or by a processing unit connected to the terminal processor 124. The event evidence management unit 125 manages the event evidence segment set and its closure state; the protocol adaptation unit 126 manages device capabilities and protocol field mapping versions; and the link continuity unit 127 manages batch and acknowledgment relationships before and after link switching. The states generated by these enhancement units can all be written to the non-volatile memory 122 and carried by the terminal state descriptor.

[0039] The master station 140 includes a master station communication interface 141, a status repository 142, a differential and control processor 143, and a convergence processor 144. The master station communication interface 141 receives status and data sent by the metering box interaction terminal 120 and sends joint differential interaction commands and various confirmations. The status repository 142 stores the set of completely received data segments, the set of confirmed command receipts, the received event evidence, and the device status version recorded by the master station, according to the metering box identifier and data interaction batch. The differential and control processor 143 reads the master station status from the status repository 142, compares the master station status with the terminal status descriptor, and organizes the data segment confirmation indication, missing data segment indication, and target operation items bound to the execution pre-state into a joint differential interaction command. The convergence processor 144 jointly checks the data segment reception status and closed-loop receipt status, and generates a convergence confirmation after the batch convergence conditions are met.

[0040] Figure 1 The event evidence closure unit 145 compares the event evidence segment index with the received evidence segment and generates an event closure confirmation; the version management unit 146 manages changes in protocol field mappings; and the link continuity verification unit 147 verifies the link continuity information carried during link switching or inter-box forwarding. The event evidence closure unit 145, version management unit 146, and link continuity verification unit 147 can be configured separately or implemented collaboratively by one or more processors in the master station 140. The above module division represents functional relationships and does not require each module to correspond to an independent physical device.

[0041] Combination Figure 2 The data interaction method of this embodiment includes steps S1 to S5.

[0042] In step S1, the metering box interactive terminal 120 obtains the periodic data, status data, or operation-related data generated by the metering box device 110 through the device access interface 121, and divides the obtained data into data segments. Each data segment is associated with at least the device identifier, data type, acquisition time or acquisition window identifier, segment number, and integrity verification information. A data segment may include multiple records from the same device within one acquisition window, or it may include multiple records grouped according to the same data type. The terminal first writes the data content and segment metadata into the non-volatile memory 122. After the read verification result shows that the writing is complete, the data segment is then included in the range of generated data segments. Thus, the range of generated data segments corresponds to data segments that can be recovered and sent after a restart, rather than simply representing data that has entered the volatile buffer or has been attempted to be sent.

[0043] Terminal processor 124 maintains the device topology version and device configuration version. The device topology version is used to characterize the access relationships and capability basis of the metering box device 110; when a metering box device is added, deleted, replaced, or its capabilities change, the terminal updates the device topology version. The device configuration version is used to characterize the parameter status and protocol field mapping status without changing the device connection relationships; when the device parameters or protocol field mappings change, the terminal updates the device configuration version. The terminal determines the batch identifier based on the metering box identifier, device topology version, device configuration version, acquisition window, and local batch number, and establishes a data interaction batch using this batch identifier. The batch identifier can be directly composed of the above fields, or it can be obtained from the above fields through deterministic mapping, as long as it can uniquely locate the corresponding device status version and acquisition window within the metering box.

[0044] After a data interaction batch is established, the terminal saves the data segments belonging to that batch, the currently saved master station confirmation set, the target operation items related to that batch, and the execution receipt. If the device status version changes, the terminal creates a new data interaction batch for the changed device status version and records the migration relationship pointing to the new data interaction batch in the original data interaction batch. The historical data segments in the original data interaction batch will not be lost due to the version change, but their target operation items still need to be judged according to the original execution prerequisite state and cannot be directly applied to the changed device due to the establishment of a new batch.

[0045] In step S2, the terminal processor 124 generates a terminal status descriptor for each data interaction batch and sends it via the terminal communication interface 123. The terminal status descriptor is at least associated with a batch identifier and represents the range of generated data segments, the currently saved master station acknowledgment set, and the instruction execution receipt status. Depending on the enabled functions, the terminal status descriptor can also represent the device topology version, device configuration version, evidence digest of pending events, the set of instruction receipts to be confirmed or executed, the protocol field mapping version, and link continuity information. For disabled functions, null values ​​or corresponding capability identifiers can be set in the status descriptor to ensure consistency in the meaning of the fields between the terminal and the master station.

[0046] The generated data segment range and master station confirmation set can be represented using a segment identifier list, interval set, bitmap, or digest tree. For example, when the data segment identifiers in a data exchange batch are consecutive and few in number, the terminal can send the start and end segment identifiers and the identifiers of the non-consecutive exception segments; when the number of data segments is large, the terminal can send hierarchical digests, and the master station will request the digest of the corresponding branch or the specific segment identifier when the digests are inconsistent. The above representations are all used to determine the segment-level reception difference, and do not equate data segments with network packets. Therefore, the same data segment can be verified for integrity by the master station after one or more packet transmissions and included in the set of data segments that have been completely received.

[0047] In step S3, after the master station communication interface 141 receives the terminal status descriptor, the differential and control processor 143 reads the corresponding master station status from the status warehouse 142 according to the metering box identifier and batch identifier. The set of fully received data segments in the master station status is included based on passing the integrity check. The master station compares the range of generated data segments of the terminal with the set of fully received data segments, and determines the data segments that the terminal has generated but the master station has not yet fully received as missing data segments; at the same time, based on the difference between the master station confirmation set saved by the terminal and the actual reception status of the master station, a data segment confirmation indication for updating the terminal-side confirmation status is determined. In the case of inconsistent digest comparison, the master station first locates the inconsistent digest branch, and then obtains the corresponding data segment identifier, thereby forming a missing data segment indication that can contain multiple discontinuous data segment identifiers.

[0048] The differential and control processor 143 also acquires the target operation item to be issued, assigns an instruction identifier to the target operation item, and binds the target operation item to the execution pre-state. The execution pre-state is associated with at least the target data interaction batch, the target device status version, and the specified data segment confirmation point; depending on the association of the target operation item, it may also include the target device topology version, the target device configuration version, the evidence closure status of the target event, or the completion status of the previous associated target operation item. Subsequently, the differential and control processor 143 combines the data segment confirmation indication, the missing data segment indication, and the target operation item into a joint differential interaction instruction. A joint differential interaction instruction may not contain a target operation item and is only used for data recovery, or it may carry one or more target operation items that do not conflict with each other; when carrying multiple target operation items, each target operation item has an instruction identifier and an execution pre-state.

[0049] like Figure 3 As shown, the data interaction batch aggregates the batch identifier, device status version, acquisition window, data segment, and interaction status into the terminal-side state boundary. The terminal-side generated data segment range, master station confirmation set, instruction execution receipt status, and optional event evidence, protocol field mapping version, and link continuity information form the terminal state descriptor. The master station-side fully received data segment set, confirmed instruction receipt set, received event evidence, and device status version form the master station state, which is stored in the state repository 142. Comparison of the two states generates confirmation difference, missing difference, and operation state constraints. The confirmation difference is used to generate a data segment confirmation indication, the missing difference is used to generate a missing data segment indication, and the operation state constraints are used to form the pre-execution state of the target operation item. These three are combined in a joint differential interaction instruction, and the corresponding data interaction batch is updated in subsequent interactions through closed-loop receipts and convergence confirmations.

[0050] Figure 3The capability and mapping version constraints shown are used to avoid directly interpreting a unified logical object as an incompatible local protocol operation. The master station can use a unified logical object identifier to describe the target operation item. The terminal determines whether the target device supports the target operation item based on its device capability set and converts it into a message of the corresponding local communication protocol according to the current protocol field mapping version. The protocol field mapping version is part of the device configuration status; when the mapping versions are inconsistent, the target operation item does not enter the execution branch, and the terminal returns a version inconsistency receipt. The specific conversion methods for different protocols will be further explained in the corresponding implementation methods.

[0051] In step S4, the metering box interaction terminal 120 parses the joint differential interaction command. For a data segment confirmation indication, after verifying that the confirmation indication corresponds to the current data interaction batch, the terminal updates the master station confirmation set in the non-volatile memory 122; for a missing data segment indication, the terminal reads the corresponding data segment from the non-volatile memory 122 and sends it. Data segments that have received complete reception confirmation from the master station will not be included in the retransmission range due to link reconnection. If a requested data segment fails local integrity verification, the terminal will not send the data segment as valid data, and can indicate the corresponding segment status in the subsequent terminal status descriptor so that the master station can re-determine the differential.

[0052] For the target operation item in the joint differential interaction command, the terminal first verifies the integrity and permissions of the command, then verifies the correspondence between the target metering box device and the current device topology, the consistency between the current device status version and the target device status version, whether the confirmation point of the specified data segment has been confirmed by the master station, and whether the target event or the previous associated target operation item is in an executeable state. When all the above items are satisfied, the terminal determines that the current state is consistent with the execution prerequisite state; if any item is not satisfied, the terminal refuses to execute the target operation item and generates a status inconsistency receipt. The status inconsistency receipt at least associates the command identifier and the inconsistency field, and carries the current device topology version, the current device configuration version, the current confirmation status of the specified data segment, and the current terminal status descriptor summary, so that the master station can distinguish the reasons such as version change, confirmation point not reached, and associated status not closed.

[0053] When the current state matches the pre-execution state, the terminal queries the non-volatile execution record based on the instruction identifier. If no corresponding execution record is found, the terminal first saves the instruction identifier, the pre-execution state summary, and the pending execution state, then transmits the operation message to the target metering box device, and persists the execution result, the post-execution device status version, and the data segment identifier associated with the execution result, thus forming a closed-loop receipt. If an execution record with the same instruction identifier and a consistent pre-execution state summary has been found, the terminal does not change the operating or configuration state of the target metering box device again, but instead returns an existing closed-loop receipt or a receipt summary that can be verified by the master station based on the execution record. Thus, instruction message retransmission and repeated execution of target operation items are handled separately.

[0054] In step S5, the terminal sends a closed-loop receipt to the master station. The closed-loop receipt includes at least an instruction identifier, execution result, post-execution status, and data segment identifier. The post-execution status may include the device status version after execution and the status related to the target operation item obtained through device status reading; the associated data segment identifier is used by the master station to determine which uplink data reflects the device status before or after the execution of the target operation item. After receiving the data segment and the closed-loop receipt, the master station updates the status repository 142. When the missing data segment of the data interaction batch has been received, and the relevant target operation item has been executed or a clear non-execution result has been obtained and the corresponding receipt has been confirmed, the convergence processor 144 determines that the data interaction batch has converged and sends a convergence confirmation. If there are still missing data segments, unconfirmed receipts, or target operation items that need to be reconstructed, no convergence confirmation is sent, and the status description and differential interaction continue.

[0055] After receiving the convergence confirmation, the terminal marks the corresponding data interaction batch as closed in the non-volatile memory 122, and then releases the corresponding data and receipt according to the storage strategy. This release can be deletion or transfer to an archive area that does not participate in subsequent differential calculations. The completion of data segment transmission, the completion of closed-loop receipt transmission, or link layer confirmation are not used as separate release criteria. If the convergence confirmation is lost during transmission, the terminal will still subsequently send the unclosed state of that batch; the master station will resend the convergence confirmation based on the convergence results stored in the state repository 142, without requiring the terminal to re-execute the target operation item.

[0056] As an implementation of a weak network recovery scenario, the terminal continues to collect data from metering box devices during IoT communication link interruptions, persisting data segments and expanding the range of generated data segments for the corresponding batch. During this period, the master station generates a target operation item of parameter configuration type and binds this operation item to the target device topology version, target device configuration version, and a specified data segment confirmation point. After the link is restored, the terminal sends a terminal status descriptor, which the master station uses to identify multiple discontinuous missing data segments. It combines the confirmation of received data segments, the request for missing data segments, and the target operation item of parameter configuration type into a single joint differential interaction instruction. The terminal first updates the confirmation set and sends the missing data segments, and then determines whether to allow the execution of parameter configuration based on the pre-execution status. In this way, the master station will not directly replay the target operation item generated before the link interruption simply because communication has been restored.

[0057] Example 2

[0058] This implementation method, based on the system of Implementation Method 1, further explains the state transition relationship between the pre-execution verification, non-volatile execution record, and closed-loop receipt of the target operation item. This relationship applies to target operation items such as parameter configuration, time synchronization, state reset, and operation status control after permission verification, and does not limit the specific local communication protocol used by the target operation item.

[0059] like Figure 4 As shown, after receiving a target operation item, the terminal first performs basic checks on message integrity, source identity, and operation permissions. If the basic checks fail, the terminal rejects the target operation item and returns a receipt indicating the check failure. If the basic checks pass, the terminal queries the non-volatile execution record using the instruction identifier. The non-volatile execution record includes at least the instruction identifier, a summary of the pre-execution state, the execution state, the execution result, the post-execution state, the associated data segment identifier, and the closed-loop receipt status. The execution state can include pending execution, executed, closed-loop receipt pending confirmation, and closed.

[0060] When a non-volatile execution record with the same instruction identifier exists, the terminal compares the received execution pre-state summary with the execution pre-state summary in the record. If they match and the record indicates that the target operation has been executed, the terminal does not transmit the same operation to the metering box device 110, but instead returns the closed-loop receipt or its verifiable summary in the record. If the record is in the closed-loop receipt pending confirmation state, the terminal retains the record and resends the closed-loop receipt according to the master station's request. If they do not match, it indicates that the same instruction identifier is associated with different state bases. The terminal treats this as an instruction identifier conflict, refuses execution, and returns inconsistent information to avoid overwriting the original execution record with the same instruction identifier.

[0061] When no non-volatile execution record with the same instruction identifier exists, the terminal reads the current data interaction batch status and the target device status, and checks whether the current status meets the execution preconditions. First, the target data interaction batch should correspond to the batch currently being processed by the terminal or a historical batch that is allowed to be processed; second, the target device should still exist in the device topology specified in the execution preconditions, and the current device topology version and device configuration version should be consistent with the target version; third, the specified data segment confirmation point should have been written into the master station confirmation set; when the target operation item is also bound to a target event or a previous associated target operation item, the corresponding event evidence should be in the specified closed state, or the previous associated target operation item should have been completed. When the target operation item also carries a specification field mapping version, the terminal simultaneously verifies the current mapping version and the target device capabilities.

[0062] If any of the above conditions are not met, the terminal will not establish a pending execution record that can enter the execution branch, nor will it send a local operation message to the metering box device 110 to change the operating status or configuration status. Instead, it will generate a status inconsistency receipt. This receipt uses an inconsistency field to indicate the mismatched items in the device topology version, device configuration version, data segment confirmation point, event closure status, previous operation status, device capability, or mapping version, and includes a summary of the current terminal status descriptor. After receiving the status inconsistency receipt, the master station marks the target operation item corresponding to the original instruction identifier as unexecutable. If the target operation item has lost its necessity for execution, the master station will cancel the target operation item; if it still needs to be executed, the master station will re-determine the missing data segment and execution prerequisite status based on the current terminal status descriptor, and generate a joint differential interaction instruction with a new instruction identifier, instead of directly replaying the mismatched original target operation item.

[0063] If the current state meets the pre-execution requirements, the terminal first writes the instruction identifier, pre-execution state summary, and pending execution state into the non-volatile memory 122. Only after the pending execution state is written does the terminal transmit the corresponding local operation message to the target metering box device 110 via the device access interface 121. After the metering box device 110 returns the operation result, the terminal can read the device status related to the operation for verification and save the execution result, the post-execution device status version, and the associated data segment identifier according to the atomic or recoverable write order. Then, the terminal updates the execution status to "executed," forming a closed-loop receipt, and sets the record to a closed-loop receipt pending confirmation state. This write order allows for differentiation between "no execution record yet formed," "ready to execute," "execution result obtained," and "receipt not yet confirmed by the master station" after a restart.

[0064] In the event of a power outage or restart during execution, the terminal, upon resuming operation, queries the non-volatile execution record instead of directly treating subsequent resent instructions from the master station as new target operation items. If the record already contains the execution result and post-execution status, the terminal restores the closed-loop receipt and resends the instruction without changing the device status again. If the record remains in the pending execution state, the terminal reads the current status of the target device and compares it with the execution prerequisite status and expected operation result in the record: if it can be confirmed that the target operation has taken effect, the terminal records the execution result and forms a closed-loop receipt; if it can be confirmed that the target operation has not yet taken effect and the current status still meets the execution prerequisite status, the terminal can continue execution; if it cannot be determined whether the target operation has taken effect, or if the current status has changed, the terminal does not automatically repeat execution, but instead forms a result pending verification or with inconsistent status and returns the current status to the master station. This avoids blindly replaying the target operation item at the time boundary where the terminal has completed the device operation but has not yet had time to persist the result.

[0065] Taking a target operation item of parameter configuration type as an example, before execution, the terminal records the target device identifier, target device status version, protocol field mapping version, specified data segment confirmation point, and a summary of the pre-configuration status of the logical object to be configured. After sending the configuration message and obtaining the device response, the terminal reads the current status of the corresponding logical object, associates the reading result with the execution result of the target operation item, and updates the device configuration version when necessary. If the closed-loop receipt is lost in the IoT communication network 130, the master station can continue to carry the original instruction identifier in subsequent joint differential interaction instructions. After the terminal finds the same instruction identifier and the same execution pre-configuration status summary, it only returns the existing closed-loop receipt and does not write the same parameters to the device again.

[0066] Taking the example of inconsistency caused by equipment replacement, when the master station generates a target operation item, the target device topology version it records corresponds to the original metering box device. However, before the target operation item arrives, the terminal has already identified the equipment replacement and established a new device topology version and a new data interaction batch. After comparison, the terminal determines that the target device topology version is inconsistent and therefore refuses to execute, carrying the current device topology version and the current terminal status descriptor summary in the status inconsistency receipt. Based on this, the master station first obtains the data status and device capabilities of the new data interaction batch, and then decides whether to generate a target operation item with a new instruction identifier for the new device. The original target operation item will not be applied to the replaced device simply because the receiving end address is still reachable.

[0067] After the master station confirms the closed-loop receipt, the terminal updates the corresponding execution record to the confirmed status. When the master station sends a convergence confirmation for a further data interaction batch, the terminal updates the execution record associated with that batch to the closed status. Records in the closed status can retain their instruction identifier and receipt summary according to a retention strategy to identify late duplicate instructions during the retention period, or they can be archived after ensuring that the same instruction identifier will not be reused again. Regardless of the retention strategy used, the same instruction identifier will not be assigned to different target operations during the retention period used for idempotency determination.

[0068] Figure 4 The three paths shown—"Returning Existing Closed-Loop Receipt," "Inconsistent Status Receipt," and "Forming Closed-Loop Receipt After Initial Execution"—all ultimately provide identifiable processing results to the master station. The master station incorporates the processing results along with the data segment reception status into the batch convergence judgment: when an existing closed-loop receipt is confirmed, the corresponding retransmission can be closed; when an inconsistent status receipt is confirmed and the original target operation item is revoked, the original target operation item can be terminated; if the target operation item needs to be reconstructed, it enters subsequent status comparisons through a new instruction identifier. Thus, data retransmission, operation execution, and anomaly rollback are all completed within the recoverable data interaction batch state.

[0069] Example 3

[0070] This implementation method, based on the aforementioned data exchange batch and two-end status comparison mechanism, segments, reports first, and manages closed-loop processes for events generated by the metering box equipment. Events can originate from metering instruments, status acquisition devices, or control devices. The specific triggering criteria for events can be determined by the corresponding devices or metering box interaction terminals according to existing acquisition configurations. This implementation method does not limit the event type, trigger threshold, or detection algorithm, but rather processes the digital information transmission status after the event is triggered.

[0071] Combination Figure 1 The event evidence management unit 125 in the metering box interactive terminal 120 is responsible for establishing an event evidence segment set, forming a minimum evidence package, saving the event closure status, and organizing supplementary transmission according to the missing evidence segment instructions. The event evidence closure unit 145 in the master station 140 is responsible for identifying events, comparing the evidence segment index with the received evidence segments, determining the missing evidence segments, and generating an event closure confirmation when the conditions are met. The event evidence management unit 125 and the event evidence closure unit 145 cooperate with the terminal processor 124, the state warehouse 142, and the differential and control processor 143, respectively, so that the event evidence status can enter the convergence judgment of the terminal status descriptor, the master station status, and the data interaction batch.

[0072] like Figure 5As shown, after an event is triggered, the event evidence management unit 125 first assigns an event identifier to the event. The event identifier can distinguish different events within the metering box and is associated with the metering box device that generated the event, the trigger time or acquisition window, and the corresponding data interaction batch. The event evidence management unit 125 forms an event header, which at least represents the event identifier, event type, source device, trigger time or trigger window, and event urgency. The event urgency is used to determine the transmission order among multiple unclosed events and does not indicate an evaluation of the event's business consequences.

[0073] The event evidence management unit 125 further organizes the event header, pre-trigger data segment, trigger-time or post-trigger data segment, and associated device status or operation log into an event evidence segment set. Each evidence segment has an evidence segment identifier, an event identifier, a segment sequence number or segment range, and integrity verification information. The pre-trigger data segment indicates the device status change before the event occurs; the trigger-time or post-trigger data segment indicates the trigger status and its subsequent status; and the associated device status or operation log indicates the device version, operating status, and operation process related to the event. Not every event needs to contain the same number of evidence segments; the types and ranges of event evidence segments can be pre-configured according to the event type, but all evidence segments listed in the evidence segment index are included in subsequent integrity checks.

[0074] For the j-th event, its set of event evidence segments can be represented as: P j = {H j B j X j , L j} Among them, P j H represents the set of event evidence segments for the j-th event; j Indicates the event header; B j Indicates the set of data segments before triggering; X j Indicates the set of data segments at or after triggering; L j This represents a set of associated device status or operation logs. This expression is used to describe the organizational relationships between evidence objects. Each object is a discrete set of identifiers, data segments, or logs, and has no physical dimensions. If a certain type of event does not have one of the data segments, the corresponding set can be marked as empty in the event header or evidence segment index without changing the identifier relationships of other evidence objects.

[0075] The event evidence segments and their indexes are first written to the non-volatile memory 122. After the writing is complete, the event is recorded as pending reporting. The event evidence management unit 125 generates an evidence digest and an evidence segment index based on the event evidence segment set. The evidence digest is used to verify whether the necessary evidence segments received by the master station correspond to the evidence set established by the terminal; the evidence segment index can at least represent the identifier of each evidence segment and its relationship in the evidence set. The evidence digest can be generated for all evidence segments, or a hierarchical digest that can locate inconsistent branches level by level can be used. This implementation does not limit the specific digest algorithm.

[0076] When the available transmission resources of the IoT communication network 130 are limited and it is not suitable to transmit all event evidence segments at once, the event evidence management unit 125 determines the pre-configured key evidence segments from the event evidence segment set and assembles the event header, evidence digest, evidence segment index, and key evidence segments into a minimum evidence packet. The key evidence segments can be determined based on the identification information required for the event type. Their function is to enable the master station to identify the event, determine the range of the evidence set, and locate the requested evidence segments even before receiving all event evidence segments, rather than replacing the complete evidence set with key evidence segments. When the available transmission resources are sufficient to transmit all event evidence, the terminal can also send more evidence segments in the first round of transmission, but the correspondence between the event identifier, evidence digest, and evidence segment index is still maintained.

[0077] The minimum evidence package for the j-th event can be represented as: M j = {H j Digest(P) j ), Index(P j ), KeySeg j} Among them, M j Represents the smallest evidence package; Digest(P) j Index(P) represents an evidence summary of the event evidence set; j ) indicates the evidence segment index; KeySeg j This indicates a pre-determined key evidence segment. The main station uses Index(P) j To determine the scope of evidence, use Digest(P) j Verify the received result using KeySeg j Obtain the prior information required to identify the event. The digest algorithm, index encoding, and number of key evidence segments can be configured according to device capabilities, but the versions and field meanings referenced in terminal generation, master station comparison, and event closure confirmation must remain consistent.

[0078] Figure 5In the process, after the metering box interactive terminal 120 sends the minimum evidence packet, the master station communication interface 141 hands it over to the event evidence closure unit 145. The event evidence closure unit 145 identifies the event based on the event header, determines the scope of evidence that the event should have based on the evidence segment index, and reads the evidence segments that have been fully received from the status repository 142. The master station compares the evidence segment index with the received evidence segments. Evidence segments that have not been received, have been received incompletely, or have failed integrity verification are all listed as missing evidence segment indicators. The missing evidence segment indicator can contain one or more discontinuous evidence segment identifiers, so the terminal does not need to retransmit all evidence sequentially from the beginning of the event evidence set.

[0079] After receiving a missing evidence segment indication, the metering box interactive terminal 120 reads the corresponding evidence segment from the non-volatile memory 122 and retransmits it. When multiple events are waiting to be retransmitted, the terminal determines the retransmission order according to the urgency of the events, the degree of evidence missing, and the risk of cache eviction. The urgency of the events can be derived from the event header; the degree of evidence missing can be represented by the proportion or range of missing evidence segments in the event evidence segment index; and the risk of cache eviction can be determined based on the local storage status and the retention status of the corresponding event evidence. These three factors work together in the retransmission queue, and events that have already received event closure confirmation will not enter this queue again.

[0080] In one alternative sorting implementation, the transmission priority of the j-th event can be expressed as: Priority j = alpha × U j + beta × M jr + gamma × L jr Among them, Priority j U is the transmission priority value for the j-th event; j M is the normalized value representing the urgency of the event. jr L is the normalized value representing the degree of evidence deficiency. jr To normalize the cache eviction risk value, all three are dimensionless state quantities, which can be uniformly normalized to 0 to 1 when using this expression; alpha, beta, and gamma are non-negative weights, and their sum is 1. The terminal adjusts the order of events to be retransmitted according to the transmission priority value, and re-determines the evidence missing degree of the corresponding event after the master station confirms the new evidence segment. This expression is only one implementation of sorting using the above three factors; the terminal can also compare the event urgency, evidence missing degree, and cache eviction risk in sequence according to the pre-configured hierarchical comparison rules. When a certain factor is not enabled, the other enabled factors or the aforementioned hierarchical comparison rules are used, and the missing state is not replaced by an unconfigured value.

[0081] After receiving the supplementary evidence segment, the master station re-compares the evidence segment index with the received evidence segments and performs integrity verification on the necessary evidence segments. If a necessary evidence segment is incomplete, the master station generates a new missing evidence segment indication, and the terminal continues to supplement the corresponding part. If the necessary evidence segment is complete but the evidence digest verification is inconsistent, the master station does not generate an event closure confirmation, but instead determines the evidence segments that need to be verified or retransmitted based on the range of digest inconsistency. Only when the necessary evidence segment is received completely and the evidence digest verification is consistent will the event evidence closure unit 145 generate an event closure confirmation.

[0082] After receiving the event closure confirmation, the terminal first verifies the event identifier and evidence digest, then persists the event closure confirmation to the non-volatile memory 122, updates the event to a closed state, and releases the corresponding event evidence segment according to the storage policy. Confirmation of ordinary data segments, completion of transmission of the minimum evidence packet, or link layer confirmation does not replace event closure confirmation. When an event evidence segment is also an ordinary data segment, it can be released after both the data segment confirmation condition and the event closure condition are met, preventing the ordinary data buffer from being cleared before the event is closed.

[0083] like Figure 5 As shown in the interruption branch, when a link interruption occurs again during evidence retransmission, the terminal maintains the event open state and saves the summary of sent evidence segments, the known master station reception status, and the remaining evidence segments. Subsequent terminal state descriptors continue to carry the event identifier, evidence summary, and open state. After the link is restored, the master station regenerates the missing evidence segment indication based on the received evidence segments in state repository 142, and the terminal continues retransmission from the evidence state before the interruption, without retransmitting evidence segments already fully received by the master station. If an event closure confirmation is lost during transmission, the master station can retransmit the confirmation based on its saved closure state, and the terminal does not re-establish the event evidence segment set.

[0084] When event evidence enhancement is enabled, events for which event closure confirmation has not yet been received are saved as pending closure states in the data exchange batch. When the master station determines batch convergence, in addition to checking missing data segments and loopback receipts, it also checks whether the event evidence requiring closure has received event closure confirmation. When the device status version changes during event retransmission, the original event evidence still belongs to the data exchange batch that triggered the event; the new data exchange batch records the migration relationship, but does not change the original event identifier and the scope of already confirmed evidence segments.

[0085] With event-enhanced evidence enabled, the convergence state of a data interaction batch can be represented as: Converged(E) = [Delta data (E) = empty] AND [Delta evt(E) = empty]AND[Delta rcpt (E) = empty] AND [Pending CMD (E) = empty] Where E represents the data exchange batch; Delta data (E) represents the set of data segments that have not yet been fully received by the master station; Delta evt (E) represents the set of event evidence that has not yet been closed; Delta rcpt (E) indicates the set of closed-loop receipts that have not yet been confirmed by the main station; Pending CMD (E) represents the set of target operation items that are still pending verification, execution, or confirmation. The main station only considers the batch converged when all of the above items are empty. When event evidence enhancement is not enabled, Delta... evt (E) Set to an empty set or do not participate in the judgment; when any set is not empty, the main station continues to generate the corresponding missing indication, receipt confirmation or target operation processing result, without releasing the batch status in advance.

[0086] Example 4

[0087] This embodiment describes how, when the metering box interaction terminal 120 connects to metering box devices 110 using different local communication protocols, it constrains data interpretation and target operation execution while maintaining a unified interaction object on the main station. Combined with... Figure 1 The protocol adaptation unit 126 is connected to the device access interface 121 and shares the device topology version, device configuration version and data interaction batch status with the terminal processor 124; the version management unit 146 in the main station 140 stores the protocol field mapping version corresponding to the metering box device and participates in the formation of the target operation item through the differential and control processor 143.

[0088] The metering box interaction terminal 120 stores a device identifier, logical address, protocol identifier, device capability set, and protocol field mapping version for each metering box device. The protocol identifier is used to select the corresponding local message parsing and generation method; the device capability set is used to represent the data objects and executable operations supported by the target device; and the protocol field mapping version is used to identify the current correspondence between the unified logical object and the local protocol fields. The protocol identifier and mapping relationship can be pre-configured, obtained based on the device capability response, or issued by the master station. This implementation does not require the terminal to automatically infer unknown protocols.

[0089] In the uplink direction, the protocol adaptation unit 126 parses the device data according to the protocol identifier of the source device, associates the device fields in the protocol with the unified logical object identifier, and retains the source device identifier, protocol field mapping version, and acquisition time or acquisition window identifier. The converted records are formed into data segments and included in the data interaction batch according to the method described in Implementation Method 1. Thus, the master station can process data from different local communication protocols according to the unified logical object, while still being able to determine the interpretation basis used for the data based on the device identifier and protocol field mapping version.

[0090] In the downlink direction, the master station describes the target operation item using a unified logical object identifier, and carries the target device identifier, operation parameters, target specification field mapping version, and execution pre-state within the target operation item. After receiving the target operation item, the terminal first locates the target metering box device according to the device topology record, and then determines whether the target device supports the unified logical object and corresponding operation based on the device capability set. If the target device does not have the corresponding capability, the terminal does not construct a local operation message, but instead returns a processing result indicating a mismatch in device capabilities, enabling the master station to cancel the target operation item or re-form the operation based on the current device capabilities.

[0091] When the target device has the corresponding capability, the protocol adaptation unit 126 compares the target protocol field mapping version carried by the target operation item with the protocol field mapping version currently stored in the terminal. If they match, the protocol adaptation unit 126 converts the unified logical object identifier and operation parameters into fields and message content of the local communication protocol used by the target device according to the corresponding mapping entries. The terminal processor 124 then verifies the target data interaction batch, device topology version, device configuration version, specified data segment confirmation point, and associated operation status according to the execution pre-state; after the verification is successful, the device access interface 121 sends a local operation message to the target device. The execution result returned by the device is then associated with the unified logical object by the protocol adaptation unit 126 and enters the closed-loop receipt.

[0092] When the target specification field mapping version is inconsistent with the current specification field mapping version, the terminal does not interpret the old version target operation item according to the current mapping relationship, nor does it overwrite the current configuration with the old mapping relationship. Instead, it generates a version inconsistency receipt. The version inconsistency receipt is associated with at least the instruction identifier, the target specification field mapping version, and the current specification field mapping version, and the current mapping version is included in the subsequent terminal status descriptor. After receiving the receipt, the master station marks the original target operation item as unexecutable, and the version management unit 146 determines whether the mapping relationship needs to be updated or the target operation item needs to be re-formed according to the current mapping version.

[0093] When a specification field mapping needs to be updated, the version management unit 146 can, while maintaining the existing master station confirmation set, only issue field mapping entries that have changed relative to the terminal's current mapping version. The mapping update message is associated with the target metering box device, the original mapping version, and the updated mapping version. After the terminal verifies that the mapping update message corresponds to the current device and the original mapping version, it writes the changed mapping entries to the non-volatile memory 122, and then updates the specification field mapping version and the device configuration version. The mapping change does not change the set of data segments that have been completely received by the master station, so the master station confirmation set is retained; the terminal establishes a new data interaction batch for the updated device configuration version and records the migration relationship in the original data interaction batch.

[0094] When a mapping update involves only a portion of unified logical objects, unchanged mapping entries can continue to be used, and existing historical data segments will still be interpreted based on the mapping version associated with their creation. Old data interaction batches can continue to complete data retransmission and receipt confirmation corresponding to the original device configuration state; however, target operation items that have not yet been executed and whose prerequisite state is bound to the original device configuration version cannot be directly migrated to the new data interaction batch. If the master station still needs to execute the corresponding operation, it should generate target operation items with new instruction identifiers based on the new mapping version and the new device configuration version.

[0095] When a metering box device is replaced by a device using a different local communication protocol, the terminal updates the device topology record, device topology version, and protocol field mapping version corresponding to the new device, and establishes a new data interaction batch. The master station confirmation status of the data segment corresponding to the old device is retained in the original data interaction batch; the original batch continues to process unconfirmed data segments and existing execution receipts. When a target operation item bound to the old device topology version arrives, the terminal determines that the device topology version is inconsistent through pre-state verification and refuses to execute it, preventing the target operation item from being applied to the replaced device due to the same logical address.

[0096] Figure 1 The protocol adaptation unit 126 and the version management unit 146 shown cooperate based on the aforementioned device records, capability verification, bidirectional field mapping and version update relationship. Figure 3 The capabilities and mapping version constraints are located between the target operation item entering the joint differential interaction instruction and the terminal execution. Protocol adaptation changes the way local messages are expressed; data interaction batches, master station confirmation sets, instruction identifiers, and closed-loop receipts still adopt the unified state relationship described in Implementation Methods 1 and 2. Therefore, changes in multi-protocol devices will not cause historical data already confirmed by the master station to be unconditionally re-uploaded, nor will it bypass the pre-execution state of the target operation item.

[0097] Example 5

[0098] This embodiment describes how the meter box interaction terminal 120 continues the original data interaction batch when switching between the first uplink and the second uplink, or when communicating with the main station 140 via another meter box with forwarding capabilities. (In conjunction with...) Figure 1 The link continuity unit 127 maintains the link identifier, the most recent acknowledgment window summary, and the most recent instruction receipt identifier; the link continuity verification unit 147 reads the original data interaction batch status in the status warehouse 142, verifies the information carried by the new link, and decides whether to bind the new link to the original data interaction batch.

[0099] like Figure 6 As shown, when the first uplink L1 is available, the metering box interaction terminal 120 sends a terminal status descriptor and data segment to the master station 140 via L1 and receives a joint differential interaction command. The terminal stores the batch identifier of the original data interaction batch, the master station confirmation set, the most recent confirmation window summary, and the most recent command receipt identifier in the non-volatile memory 122. The most recent confirmation window summary indicates the most recent confirmation status of the original link known to the terminal, and the most recent command receipt identifier indicates the most recent closed-loop receipt that was formed or sent before the link switch, thereby providing a status anchor point for the master station to locate the interaction progress before the link switch.

[0100] The link continuity unit 127 can decide to switch communication paths based on the uplink availability, data transmission failure, or session hold status. Specific link selection metrics and switching thresholds can be configured according to the deployed IoT communication network and do not constitute a necessary limitation of this implementation. When a link switch occurs, the terminal stops forming new transmission states on unavailable paths and selects the second uplink L2. In the inter-box forwarding scenario, L2 consists of the communication path from the terminal to the forwarding metering box and the uplink path from the forwarding metering box to the master station. The forwarding metering box is used to forward session messages and data segments with the original batch status, and does not thereby obtain the authority to reallocate instruction identifiers or change the master station confirmation set.

[0101] The first session message sent by the terminal via L2 carries the batch identifier of the original data exchange batch, the most recent acknowledgment window summary of L1, the most recent instruction receipt identifier, the new link identifier, and anti-replay information. The new link identifier is used to distinguish the current communication path, and the anti-replay information is generated by the current communication security mechanism and associated with the first session message. This implementation does not limit the specific algorithm used for the anti-replay information, but the terminal and the master station use the same verification rules, ensuring that the identity, integrity, and timing validity of the first session message can be verified. When sent via the forwarding metering box, the above link continuity information remains associated with the original terminal identity and the original data exchange batch.

[0102] After receiving the first session message, the link continuity verification unit 147 verifies the terminal identity and message integrity, verifies the anti-replay information, and reads the original data interaction batch from the state repository 142 according to the batch identifier. The master station further compares whether the most recent acknowledgment window summary and the most recent instruction receipt identifier correspond to the master station status of the original batch. If the verification is successful, the master station binds L2 to the original data interaction batch and returns the current master station acknowledgment set through L2. Link binding only updates the communication path relationship and does not change the device status version, data segment identifier, and instruction identifier of the original data interaction batch.

[0103] After receiving the current master station acknowledgment set, the terminal compares it with the range of generated data segments stored in non-volatile memory 122 and the local master station acknowledgment set, and corrects the range to be transmitted on the new link based on the current acknowledgment status returned by the master station. The terminal only retransmits data segments that have not yet been fully received by the master station and unacknowledged loop closure receipts; already acknowledged data segments are not re-queued due to link changes. Unclosed target operation items in the original link continue to use the original instruction identifier; if the master station retransmits the instruction identifier in L2 because it has not received a loop closure receipt, the terminal returns the existing loop closure receipt or completes the unfinished recoverable processing according to the non-volatile execution record, without using link switching as the basis for re-executing the target operation item.

[0104] In L2, the master station and terminal continue to use the terminal state descriptor to compare with the master station state, joint differential interaction commands, and convergence confirmation mechanisms. Data segments or receipts may have been sent before L1 expired but have not yet reached the master station, or they may arrive late after L2 is established. The master station updates the state repository 142 according to the batch identifier, data segment identifier, and command identifier. Data segments that have been fully received and closed-loop receipts that have been confirmed do not have their batch states changed again. Thus, changes in the transmission path are separated from the application layer interaction state.

[0105] like Figure 6 As shown in the verification failure branch, when the terminal identity, message integrity, anti-replay information, original batch identifier, most recent acknowledgment window summary, or most recent instruction receipt identifier fail the continuity verification, the master station does not directly bind L2 to the original data interaction batch, nor does it continue to execute unclosed target operation items in the original link through L2. The master station requests a complete terminal status descriptor from the terminal and sets the relevant target operation items to a paused state. After the terminal sends the complete terminal status descriptor, the master station rereads the status repository 142 and compares the generated data segment range, master station acknowledgment set, device status version, and instruction execution receipt status.

[0106] After recompiling the state comparison, the master station determines the missing data segments and target operation items that can continue to be processed based on the comparison results. If the execution prerequisite state of the original target operation item is still consistent with the current terminal state, the master station can continue to obtain its execution result using the original instruction identifier; if the device state version, specified data segment confirmation point, or associated operation state has changed, the master station cancels the original target operation item in accordance with the method described in Implementation Method 2, or reconstructs the joint differential interaction instruction with a new execution prerequisite state and a new instruction identifier. Only after a verifiable two-end state relationship is re-established can the suspended target operation interaction be resumed.

[0107] Once link continuity verification is passed and subsequent data segments and closed-loop receipts are confirmed, the master station still generates a convergence confirmation for the original data interaction batch, and the terminal closes the original batch accordingly. Simply switching from L1 to L2, returning from L2 to L1, or changing the forwarding route to another metering box does not automatically create a new data interaction batch; only when the basis for batch determination, such as the device topology version, device configuration version, or acquisition window, changes, is a new data interaction batch created in the aforementioned manner, and the migration relationship recorded. In this way, link continuity management maintains the relationship between batches, confirmation windows, and command receipts, rather than equating a single physical or logical link connection with a new data interaction process.

[0108] The above specific embodiments are used to illustrate the technical solution and implementation process of the present invention. Based on the disclosure in this specification, those skilled in the art can make corresponding adjustments to the data segment organization, status descriptor representation, differential indication form, and communication interface according to the type of metering box equipment, IoT communication network conditions, local communication protocol, and master station deployment method; any equivalent substitutions, conventional transformations, or combinations made without departing from the technical concept of the present invention are all within the scope of the technical solution of the present invention.

Claims

1. A data interaction method for an electricity metering box based on the Internet of Things, characterized in that, include: S1, the metering box interactive terminal divides the metering box equipment data into data segments, and establishes a data interaction batch based on the metering box identifier, equipment status version and acquisition window. The data interaction batch is associated with the data segment, the main station confirmation status, the target operation item and the execution receipt. S2, the metering box interactive terminal sends a terminal status descriptor to the master station. The descriptor is associated with the data interaction batch and represents the range of generated data segments, the master station confirmation set, and the instruction execution receipt status. S3, the master station compares the descriptor with the master station status of the data interaction batch, determines the missing data segment and the target operation item carrying the instruction identifier and changing the operating or configuration status of the metering box device, and generates a joint differential interaction instruction; the instruction includes a data segment confirmation indication, a missing data segment indication and a target operation item bound to the execution pre-state, the execution pre-state including the target data interaction batch, the target device status version and the specified data segment confirmation point. S4, the terminal updates the master station confirmation set and sends the missing data segment, compares the current state with the execution pre-state; if they match, it queries the non-volatile execution record corresponding to the instruction identifier, executes the unexecuted target operation item and saves the closed-loop receipt, or returns the existing closed-loop receipt; if they do not match, it refuses to execute and returns the state inconsistency receipt and the current terminal state descriptor. S5, the metering box interactive terminal sends a closed-loop receipt containing the associated instruction identifier, execution result, post-execution status, and data segment identifier; the master station determines the convergence of the data interaction batch based on the reception status of the data segment and the closed-loop receipt and sends a convergence confirmation, and the metering box interactive terminal releases the corresponding data and receipt accordingly.

2. The data interaction method for an IoT-based electricity metering box according to claim 1, characterized in that, The device status version includes a device topology version and a device configuration version. The batch identifier of the data interaction batch is jointly determined by the metering box identifier, the device topology version, the device configuration version, the acquisition window, and the local batch number. The device topology version is updated when the metering box is added, deleted, replaced, or its capabilities are changed. The device configuration version is updated when the device parameters or protocol field mappings change but the device connection relationship remains unchanged. Each data segment is associated with at least the device identifier, data type, acquisition time or acquisition window identifier, segment number, and integrity verification information. The data segment is written to non-volatile memory and completes integrity verification before being included in the range of generated data segments. When the device status version changes, a new data interaction batch is established, and the migration relationship pointing to the new data interaction batch is recorded in the original data interaction batch.

3. The data interaction method for an IoT-based electricity metering box according to claim 1, characterized in that, The terminal status descriptor also represents the device topology version, device configuration version, evidence digest of events to be closed, set of instruction receipts to be confirmed or executed, protocol field mapping version, and link continuity information. The master station status represents the set of data segments that have been fully received, the set of confirmed instruction receipts, the evidence of events received, and the device status version recorded by the master station. The master station confirmation set is represented by a segment identifier list, interval set, bitmap, or digest tree. When the digest comparison is inconsistent, the master station requests the identifier of the corresponding branch or data segment level by level to form the missing data segment indication containing the identifier of discontinuous data segments, and determines the data segments that the terminal has generated but the master station has not fully received as missing data segments.

4. The data interaction method for an IoT-based electricity metering box according to claim 1, characterized in that, The execution pre-state includes the target data interaction batch, the target device topology version, the target device configuration version, and the designated data segment confirmation point, and further includes the evidence closure status of the target event or the completion status of the previous associated target operation item; the meter box interaction terminal sequentially verifies the integrity and permissions of the joint differential interaction instruction, the correspondence between the target meter box device and the current device topology, the consistency between the current device status version and the target device status version, whether the designated data segment confirmation point has been confirmed by the master station, and the status of the target event or the previous associated target operation item, and determines that the comparison result is consistent when all the aforementioned verifications pass.

5. The data interaction method for an IoT-based electricity metering box according to claim 4, characterized in that, The status inconsistency receipt includes the instruction identifier, inconsistency field, current device topology version, current device configuration version, current confirmation status of the specified data segment, and current terminal status descriptor summary. The master station marks the target operation item corresponding to the original instruction identifier as unexecutable and cancels the target operation item according to the current terminal status descriptor, or re-determines the missing data segment and execution pre-state, and generates a joint differential interaction instruction with a new instruction identifier to avoid directly replaying the mismatched original target operation item.

6. The data interaction method for an IoT-based electricity metering box according to claim 1, characterized in that, Before executing the target operation item, the metering box interactive terminal writes the instruction identifier, execution pre-state summary and execution state into the non-volatile memory. After execution, persist the execution result, the post-execution device state version, and the data segment identifier associated with the execution result in an atomic or recoverable write order, and maintain the non-volatile execution record until the corresponding acknowledgment or convergence confirmation is received. When a target operation item with the same instruction identifier is received again, its execution pre-state summary is compared with the non-volatile execution record. The operating state or configuration state of the metering box device is not changed again, and a closed-loop receipt or its verifiable summary corresponding to the instruction identifier is returned.

7. The data interaction method for an electricity metering box based on the Internet of Things according to claim 1, characterized in that, For events generated by the metering box device, the metering box interactive terminal assigns an event identifier to the event and organizes the event header, pre-trigger data segment, trigger or post-trigger data segment, and associated device status or operation log into an event evidence segment set. The event identifier, evidence summary, and event closure status are recorded in the terminal status descriptor. When the available transmission resources of the IoT communication network are limited, a minimum evidence packet is sent first. The minimum evidence packet includes the event header, the evidence summary of the event evidence segment set, the evidence segment index, and pre-determined key evidence segments, so that the master station can identify the event and determine the missing evidence segments even if it has not received all the event evidence segments.

8. A data interaction system for an electricity metering box based on the Internet of Things, characterized in that, This includes metering box equipment, metering box interactive terminals, IoT communication networks, and a main station; The metering box interaction terminal includes a device access interface, a non-volatile memory, a terminal communication interface, and a terminal processor. The device access interface is used to obtain data from the metering box device and transmit target operation items to the metering box device to change its operating state or configuration state. The non-volatile memory is used to store data segments, data interaction batch status, instruction identifiers, and closed-loop receipts. The terminal communication interface communicates with the master station through the Internet of Things communication network. The terminal processor is used to establish data interaction batches with associated data segments, master station confirmation status, target operation items, and execution receipts; generate terminal status descriptors; update or send data segments according to data segment confirmation instructions and missing data segment instructions; verify the execution pre-execution status of the target operation item and perform idempotent execution; and generate closed-loop receipts for the device status and data segments after associated execution. The master station includes a master station communication interface, a state warehouse, a differential and control processor, and a convergence processor. The state warehouse is used to save the master station state according to the metering box identifier and data interaction batch. The differential and control processor is used to compare the terminal state descriptor with the master station state and generate a joint differential interaction instruction that simultaneously includes a data segment confirmation indication, a missing data segment indication, and a target operation item bound to the execution pre-state. The convergence processor is used to determine whether the data interaction batch has converged based on the data segment reception status and the closed-loop receipt status and generate a convergence confirmation.

9. The data interaction system for an electricity metering box based on the Internet of Things according to claim 8, characterized in that, The metering box interactive terminal also includes an event evidence management unit, used to establish an event evidence segment set consisting of an event header, a pre-trigger data segment, a trigger-time or post-trigger data segment, and associated device status or operation logs; generate a minimum evidence package containing an evidence digest and an evidence segment index; supplement evidence segments according to missing evidence segment instructions; and release event evidence segments after event closure confirmation persistence. The main station also includes an event evidence closure unit, used to compare the evidence segment index with the received evidence segments to generate the missing evidence segment instruction; and generate the event closure confirmation after the necessary evidence segments are received completely and the evidence digest is verified to be consistent.

10. The data interaction system for an electricity metering box based on the Internet of Things according to claim 9, characterized in that, The metering box interaction terminal also includes a protocol adaptation unit and a link continuity unit. The protocol adaptation unit is used to convert between messages of a unified logical object and different local communication protocols based on the protocol identifier, device capability set, and protocol field mapping version associated with the metering box device, and to generate a version inconsistency receipt when the versions are inconsistent. The link continuity unit is used to maintain the batch identifier, most recent acknowledgment window summary, most recent instruction receipt identifier, and anti-replay information of the original data interaction batch in the new link when switching between dual uplinks or inter-box forwarding. The master station also includes a version management unit and a link continuity verification unit. The version management unit is used to issue changed field mapping entries while maintaining the master station acknowledgment set. The link continuity verification unit is used to verify the link continuity information carried by the new link and bind the verified new link to the original data interaction batch or request a complete terminal status descriptor when the verification fails.

Images