Single-phase power cost control intelligent electric energy meter and method thereof

Abstract

The application discloses a single-phase intelligent electric energy meter with a fee control function and a method thereof, and relates to the field of electric energy fee control. The complete new fee rate strategy is encapsulated into a transaction data packet for overall transmission. After receiving the transaction data packet, the electric meter side first performs presetting and integrity checking on the whole data packet, and only when it is confirmed that the data packet is correct, the electric meter enters a ready state, so that data inconsistency caused by interruption of updating is avoided. The use of the new strategy is triggered by a unified effective time stamp, so that the synchronization of activation is ensured. Finally, through an activation state proof mechanism based on a random challenge number, the master station can remotely verify that the electric meter is operated under the correct new strategy, so that the atomicity, accuracy and traceability of the whole fee control process are ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of electric energy cost control, and more particularly, to a single-phase cost control smart electric energy meter and a method thereof. BACKGROUND

[0002] With the deepening of the construction of smart grid, the power market puts forward higher requirements for the fine management of electricity price policy, and the traditional single electricity price mode is rapidly replaced by complex mixed rate strategies such as time-of-use electricity price and step electricity price. This change requires power companies to frequently, reliably and accurately update the remote rate strategy for a large number of terminal smart electric energy meters. Therefore, constructing an efficient and safe cost control scheme for single-phase cost control smart electric energy meters to ensure accurate execution of the billing strategy has become a key link to protect the stable operation of the power system and maintain the interests of both parties.

[0003] However, the existing remote cost control technology generally has the technical defect of non-atomicity when dealing with complex strategy updates. Traditional cost control schemes, such as the serial instruction mode based on the DLMS / COSEM protocol, usually split a complete new rate strategy into multiple independent parameter setting instructions and send them one by one through channels such as power line carrier (PLC) or wireless network (RF). Due to the unreliability of the communication link, data packets are easily lost or damaged due to environmental interference. This question-and-answer type of update process is extremely easy to be interrupted in the middle. Once interrupted, the electric energy meter may have only completed part of the parameter writing, resulting in the coexistence of new and old strategies in the device, forming a state of inconsistent data. In addition, as a resource-limited embedded device, the smart electric energy meter has limited processing capacity and storage space, and cannot support complex transaction processing mechanisms to ensure the atomicity of operations, i.e. all success or all failure. This inconsistent state will eventually lead to serious billing errors, causing user complaints and increasing the operation and calibration costs of power companies.

[0004] Therefore, the existing technology fails to provide an effective mechanism to ensure the integrity and consistency of the rate strategy update, a key operation, under unreliable communication conditions. How to design a lightweight transaction mechanism to realize the atomicity of rate parameter presetting, integrity verification on resource-limited electric energy meters, and accurate activation at a predetermined time, while providing a verifiable activation proof afterwards, has become a technical problem to be solved in the field. SUMMARY

[0005] To solve the problems in the prior art, according to an aspect of the present application, a method of a single-phase cost control smart electric energy meter is provided, which includes: S1: a master station side performs transaction initialization and parameter set encapsulation based on a target electric meter ID and a new rate strategy to obtain a transaction data packet.

[0006] S2: The meter side performs parameter set presetting and checking on the transaction data packet to obtain a preset state after receiving the transaction data packet.

[0007] S3: The meter side reports the received transaction ID and the preset state to the master station side as a preset reply.

[0008] S4: At the master station side, if the preset state is ready, it is recorded that the meter has been successfully preset and waits for the arrival of the effective timestamp; if the preset state is failure, it is recorded that the meter preset fails and a retransmission instruction is generated.

[0009] S5: The meter side compares the current system time with the stored effective timestamp to obtain an activation state, and reports the transaction ID and the activation state to the master station side.

[0010] S6: After determining that the activation state is activated, the master station side performs activation state proof with the meter side using a random challenge number to obtain an activation state proof result.

[0011] According to another aspect of the present application, a single-phase fee control intelligent electric energy meter system is provided, which comprises a master station side and a meter side.

[0012] The master station side comprises a transaction data packet acquisition module for performing transaction initialization and parameter set packaging based on a target meter ID and a new rate strategy to obtain a transaction data packet.

[0013] A preset state judgment module is configured to record that the meter has been successfully preset and waits for the arrival of the effective timestamp if the preset state is ready, and record that the meter preset fails and generate a retransmission instruction if the preset state is failure.

[0014] An activation state proof module is configured to perform activation state proof with the meter side using a random challenge number to obtain an activation state proof result after determining that the activation state is activated.

[0015] The meter side comprises a transaction data packet checking module for performing parameter set presetting and checking on the transaction data packet to obtain a preset state after receiving the transaction data packet.

[0016] A transaction ID and preset state reporting module is configured to report the received transaction ID and the preset state to the master station side as a preset reply.

[0017] An activation state generation module is configured to compare the current system time with the stored effective timestamp to obtain an activation state, and report the transaction ID and the activation state to the master station side.

[0018] Compared with the prior art, the single-phase fee control intelligent electric energy meter and the method thereof provided by the application aim to solve the non-atomic problem of rate strategy update caused by unreliable communication and limited device resources. A lightweight pre-activation two-stage transaction mechanism is introduced. Instead of issuing scattered instructions, the complete new rate strategy is packaged into a transaction data packet for overall transmission. After receiving, the meter side first performs pre-setting and integrity checking on the entire data packet, and only after confirming that there is no error, it enters the ready state, thereby avoiding data inconsistency caused by update interruption. The activation of the new strategy is triggered by a unified effective timestamp, ensuring the synchronization of activation. Finally, through a set of activation state proof mechanism based on random challenge numbers, the master station can remotely verify that the meter is running under the correct new strategy, ensuring the atomicity, accuracy and traceability of the entire fee control process. BRIEF DESCRIPTION OF DRAWINGS

[0019] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description of embodiments of the present application taken in conjunction with the accompanying drawings.

[0020] Figure 1 A flowchart of the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application.

[0021] Figure 2 A data flow diagram of the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application.

[0022] Figure 3 A flowchart of step S1 in the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application.

[0023] Figure 4 A flowchart of step S2 in the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application.

[0024] Figure 5 A block diagram of the single-phase fee control intelligent electric energy meter system according to the embodiment of the present application. DETAILED DESCRIPTION

[0025] Embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. It should be understood that the accompanying drawings and embodiments of the present disclosure are only for exemplary purposes, and are not intended to limit the protection scope of the present disclosure.

[0026] Based on the above, the present application proposes a method for a single-phase fee control intelligent electric energy meter to solve the non-atomic problem of rate strategy update caused by unreliable communication and limited device resources. Figure 1 A flowchart of the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application. Figure 2 A data flow diagram of the method for the single-phase fee control intelligent electric energy meter according to the embodiment of the present application. As shown in FIG. 2, the method comprises the following steps:Figure 1 and Figure 2 As shown, the method for a single-phase prepaid smart meter according to an embodiment of this application includes: S1: The master station performs transaction initialization and parameter set encapsulation based on the target meter ID and a new rate strategy to obtain a transaction data packet; S2: After receiving the transaction data packet, the meter performs parameter set preset and verification on the transaction data packet to obtain a preset state; S3: The meter reports the received transaction ID and preset state as a preset receipt to the master station; S4: On the master station, if the preset state is ready, it records that the meter has been successfully preset and waits for the arrival of the effective timestamp; if the preset state is failed, it records that the meter preset failed and generates a retransmission instruction; S5: The meter compares the current system time with the stored effective timestamp to obtain an activation state, and reports the transaction ID and activation state to the master station; S6: After determining that the activation state is activated, the master station performs activation state proof with the meter through a random challenge number to obtain the activation state proof result.

[0027] In step S1, the master station initializes the transaction and encapsulates the parameter set based on the target meter ID and the new rate policy to obtain a transaction data packet. It should be understood that in remote fee control management of smart grids, due to the unreliability of communication channels, the traditional method of issuing parameter commands one by one is prone to incomplete rate policy updates due to transmission interruptions, resulting in inconsistent data states within the electricity meter and consequently, billing errors. To fundamentally solve this problem, a mechanism needs to be introduced to integrate the scattered parameter commands into an indivisible whole for processing. Therefore, the master station initializes the transaction and encapsulates the parameter set based on the target meter ID and the new rate policy to obtain a transaction data packet. The purpose is to define the entire rate policy update operation as an atomic transaction. By pre-encapsulating all relevant parameters into an independent, self-contained data packet, it is ensured that the meter side either receives and processes a complete and correct new policy or completely rejects a damaged or incomplete policy packet, thereby completely eliminating intermediate states caused by successful updates of only some parameters and ensuring the atomicity and data consistency of the fee control operation.

[0028] Figure 3 This is a flowchart of step S1 in a method for using a single-phase prepaid smart energy meter according to an embodiment of this application. For example, as shown... Figure 3 As shown, in a specific implementation, step S1 includes: S11, formatting and serializing the new rate strategy to obtain a new serialized parameter set; S12, inputting the new serialized parameter set into a cryptographically secure hash function to obtain an integrity hash; S13, encapsulating the transaction ID, integrity hash, effective timestamp, and serialized parameter set into a transaction data packet to obtain a transaction data packet.

[0029] In the above embodiment, the step S1 procedure is implemented as follows: first, step S11 is performed. The target meter ID is a unique identity of the electric energy meter, for example, a device asset number 330123123456 composed of twelve digits. The new rate strategy is a structured business data object which internally defines in detail the electric price rules to be executed. For example, a new time-of-use rate strategy can contain the following content: the start time of the peak period is 10:00, the peak period rate is 1.2 yuan / degree; the start time of the peak period is 14:00, the peak period rate is 1.0 yuan / degree; the start time of the flat period is 18:00, the flat period rate is 0.6 yuan / degree; the start time of the valley period is 22:00, the valley period rate is 0.3 yuan / degree. The purpose of formatting and serialization is to convert this human-readable strategy object into a compact, clear and suitable binary byte stream for transmission in the network and embedded device parsing, that is, to serialize the new parameter set. The process first performs a normalized sorting. In order to ensure that the same rate strategy always generates a completely consistent binary sequence at any time, thereby ensuring the determinacy of subsequent hash check, it is necessary to uniformly sort all parameter fields in the strategy according to the pre-defined protocol specification. The protocol specification can assign a unique label ID to each parameter field and arrange them in ascending order of label ID. For example, the label ID of the valley period rate can be preset as 101, the valley period start time as 102, the flat period rate as 201, the flat period start time as 202, the peak period rate as 301, the peak period start time as 302, the peak period rate as 401, and the peak period start time as 402. In this way, the logical order of the elements in the aforementioned rate strategy object after normalized sorting will be adjusted to: the valley period rate, the valley period start time, the flat period rate, the flat period start time, the peak period rate, the peak period start time, the peak period rate, and the peak period start time. Next, the encoding conversion is performed to convert the sorted parameter values from their high-level data types to a standard binary format. The conversion rule is based on the agreed protocol between the two parties, for example, the encoding format of label-length-value (TLV). For time type data such as 10:00, it can be converted into a 2-byte unsigned integer, indicating the number of minutes from midnight, that is, 600. For rate, which is a floating-point number, in order to avoid precision problems, it can be multiplied by a fixed multiple such as 10000 and converted into a 4-byte integer, for example, 1.2 yuan / degree is converted into an integer 12000. Taking the valley period rate: 0.3 yuan / degree as an example, the label ID is 101, the converted value is 3000, and the data length is 4 bytes. The encoded binary TLV structure can be: label [1 byte, value 101], length [1 byte, value 4], value [4 bytes, value 3000]. This encoding conversion process will be applied to each parameter in the sorted list. Finally, the splicing generation operation is performed.The binary TLV data blocks of all parameters obtained after encoding and conversion are concatenated together end-to-end in strict accordance with the order determined by normalization, forming a continuous, unseparated binary data stream, i.e., a serialized new parameter set. This set not only completely carries all the information of the new rate policy, but also has a compact structure, efficient parsing, and deterministic content. For example, this serialized new parameter set can be a 30-byte data block whose content is the result of sequentially concatenating the labels, lengths, and values ​​of eight parameter fields, from the valley period rate and valley period start time to the peak period start time.

[0030] Then, step S12 is executed. The tool used here is a cryptographically secure hash function. This is a public, standard mathematical algorithm that can map input data of arbitrary length into a fixed-length output digest through a series of complex, irreversible calculations. Its key characteristics are: first, determinism—the same input will always produce the exact same output; second, the avalanche effect—any tiny change in the input (even changing only one bit) will cause the output hash value to change drastically and irregularly; and finally, collision resistance—finding two different inputs that can produce the same hash value is computationally infeasible. In this embodiment, the hash function selected is SHA-256, the 256-bit version of the secure hash algorithm. This function was chosen based on its recognized security and standardization, and it has been widely used in various security fields such as digital signatures and data integrity verification. In the communication protocol of the smart grid, SHA-256 is pre-specified to ensure that all master stations and meter devices use a unified verification standard. The specific implementation process is that the master station calls the built-in SHA-256 algorithm module. The serialized parameter set is input directly into the SHA-256 algorithm module as a whole message. This module initializes an internal state, then blocks and fills the input data stream, performing multiple rounds of iterative computation through its core compression function. Each round involves complex bitwise operations, logical functions, and modular addition, mixing the current data block with the result of the previous round to progressively update the internal state. This process is fully automated, a standard procedure solidified by the algorithm logic, and involves no learned or adjusted weights, biases, or other parameters. After processing all input data, the SHA-256 algorithm module finally outputs a 256-bit binary value. This value is the integrity hash. For ease of transmission and recording, this 256-bit value is represented as a 64-character hexadecimal string. For example, the calculated integrity hash might be 5A9A3E2E...C8F4B21A (example here). This hash value is a highly condensed and unique digital fingerprint of the original rate policy data packet.

[0031] Next, proceed to step S13. Before proceeding to this step, two key metadata items need to be generated or obtained: a transaction ID and an effective timestamp. The transaction ID is a globally unique identifier assigned to this rate policy update operation. It uniquely marks this task throughout the entire rate control interaction lifecycle, ensuring that all related communications between the master station and the meter, such as pre-set receipts and activation reports, can be accurately associated with this specific update operation, thereby achieving precise status tracking and management. The generation of the transaction ID must adhere to a strict uniqueness principle. One feasible generation method is to design it as a 16-byte composite identifier. For example, its structure can be defined as follows: the first 4 bytes are the master station's unique network identifier, the middle 8 bytes are the UTC timestamp accurate to milliseconds when the current operation was initiated, and the last 4 bytes are a cyclically incrementing sequence number maintained by the master station within that millisecond. For example, if a master station identifier is 0x00010002, and a timestamp generated at a specific time is 0x018B47E8A1B2C3D4 with a sequence number of 0x0000000A, then the resulting transaction ID after concatenation is 00010002018B47E8A1B2C3D40000000A. The effective timestamp defines the precise moment when a new rate policy should be officially activated within the electricity meter and begin to be used for electricity billing. This timestamp originates from the power company's business layer decision; for example, the power company stipulates that the summer electricity price for all users will be officially activated at 00:00:00 on June 1, 2025. When the master station initiates this fee control task, it will obtain this time from the business configuration. To avoid time zone confusion, this time must be converted to a standard, geographically independent absolute time representation. In this embodiment, a 4-byte timestamp representing the number of seconds counted from 00:00:00 UTC on January 1, 1970 is used, which is the standard Unix timestamp. For example, the timestamp integer value corresponding to the target effective time "June 1, 2025 00:00:00 UTC" is 1748736000, and its hexadecimal representation is 0x683D7000.

[0032] The goal of the encapsulation process is to assemble four independent data elements of different types and lengths into a single, contiguous binary data block, namely a transaction data packet, according to a predefined, mutually agreed-upon data packet format. The encapsulation process follows a well-defined structured protocol. This protocol defines the order, data type, and byte length of each field in the data packet to ensure unambiguous parsing by the receiver. In this embodiment, the transaction data packet is defined as consisting of a fixed-length header and a variable-length data body. The header sequentially contains the transaction ID, effective timestamp, integrity hash, and parameter set length; the data body is the actual serialized new parameter set. Specific field definitions are as follows: 1. Transaction ID: 16 bytes, directly using the previously generated unique identifier. 2. Effective Timestamp: 4 bytes, unsigned integer, big-endian, storing the previously generated Unix timestamp. 3. Integrity Hash: 32 bytes, directly using the output of the aforementioned SHA-256 algorithm. 4. Parameter Set Length: 2 bytes, unsigned integer, big-endian, its value representing the actual byte length of the subsequent serialized new parameter set. This field is crucial, as it informs the parser where the boundaries of the data body lie. 5. Serialization Parameter Set: Variable length, specified by the length field of the previous parameter set. The specific encapsulation operation is performed in a memory buffer. First, the master station calculation module obtains the byte length of the new serialized parameter set, which is 30 bytes in this example, or 0x001E in hexadecimal. Then, the module writes each data element into the buffer sequentially: first, it writes the 16-byte transaction ID 00010002018B47E8A1B2C3D40000000A; then, it writes the 4-byte effective timestamp 683D7000; then, it writes the 32-byte integrity hash 5A9A...21A; then, it writes the 2-byte parameter set length 001E; finally, it appends the complete 30-byte binary data stream of the new serialized parameter set to the end. After the above concatenation operation, the final generated transaction data packet is a continuous binary data block with a total length of 16+4+32+2+30=84 bytes. This data packet is compact and comprehensive, encapsulating all the instructions, data, and metadata required for a rate update operation.

[0033] In step S2, after receiving the transaction data packet, the meter side performs parameter set presetting and verification on the transaction data packet to obtain a preset state. Correspondingly, after the master station encapsulates the complete rate policy into a transaction data packet and sends it out, the electricity meter, as the receiving and executing terminal, faces the primary task: how to safely and reliably receive and verify this instruction packet with its limited resources, while preparing for subsequent accurate activation. Directly overwriting the currently running parameters carries a huge risk; if an error occurs midway, the electricity meter will be in an uncertain billing state. Therefore, in this application, after receiving the transaction data packet, the meter side performs parameter set presetting and verification on the transaction data packet to obtain a preset state, thus establishing a preprocessing safety buffer. That is, by first writing the new policy into a temporary, non-activated storage area and performing strict integrity verification, it is ensured that the state is set to ready only when the data is 100% correct, thereby isolating potential risks outside the formal activation process and laying the foundation for achieving atomic presetting-activation two-stage updates.

[0034] Figure 4 This is a flowchart of step S2 in the method for using a single-phase prepaid smart energy meter according to an embodiment of this application. For example, as shown... Figure 4 As shown, in a specific implementation, step S2 includes: S21, parsing the transaction data packet and extracting metadata to obtain the received transaction ID, the received effective timestamp, the received parameter set, and the received integrity hash; S22, performing parameter set preset writing and readback verification on the received parameter set to obtain the written parameter set and the write status; S23, in response to a successful write status, inputting the written parameter set into the built-in SHA-256 algorithm module to obtain the calculated hash; S24, performing integrity comparison and status decision on the calculated hash and the received integrity hash to obtain the preset status.

[0035] In the above implementation scheme, step S2 is executed as follows: First, step S21 is executed. The transaction data packet is the continuous binary data block with a total length of 84 bytes generated in the preceding step S13. After receiving this data stream, the energy meter stores it completely in a temporary receive buffer, ready for parsing. The parsing is based on the transaction data packet structured protocol pre-installed in the energy meter firmware, which is completely consistent with the master station side. This protocol clearly specifies the precise position, byte length, and data type of each field in the data packet, making the parsing process a deterministic, step-by-step operation. The parsing operation is executed by the energy meter's microcontroller (MCU). First, the MCU starts from the beginning of the receive buffer and extracts data field by field according to the protocol format. The first field is the transaction ID, which the protocol specifies as 16 bytes in length. Therefore, the MCU reads the first 16 bytes of the buffer, obtaining 00010002018B47E8A1B2C3D40000000A. The MCU treats these 16 bytes of data as a whole and stores them in a temporary variable specifically for identifying this operation; this variable is the received transaction ID. This ID will be used in subsequent processes to report the processing status upwards, ensuring the master station can associate the receipt information with the correct task. Next, the MCU moves its read pointer 16 bytes forward to the 17th byte and begins parsing the second field, the effective timestamp. The protocol specifies it as a 4-byte big-endian unsigned integer. The MCU reads these 4 bytes from the 17th to the 20th byte, obtaining the hexadecimal data 683D7000. The MCU parses this into a standard Unix timestamp integer value 1748736000 and stores it in another temporary variable, the received effective timestamp. This timestamp defines the future activation time of the new policy; the energy meter will compare it with its own real-time clock to determine when to perform the activation operation. Then, the MCU moves its pointer forward another 4 bytes to the 21st byte and parses the third field, the integrity hash. The protocol specifies its length as 32 bytes. The MCU reads 32 bytes from bytes 21 to 52, obtaining a SHA-256 hash value, such as 5A9A...21A. This hash value is the digital fingerprint calculated by the master station on the original parameter set, and the MCU stores it in the received integrity hash variable. Next, the MCU pointer moves forward 32 bytes to byte 53, parsing the fourth field, the parameter set length. The protocol specifies it as a 2-byte big-endian unsigned integer. The MCU reads bytes 53 and 54, obtaining the hexadecimal data 001E, and parses it into the integer value 30. This length value is crucial; it explicitly tells the MCU that the following data body, the actual rate parameter set, has a length of 30 bytes. Finally, based on the just-parsed length value, the MCU moves the pointer forward 2 bytes, starting from byte 55, and reads 30 bytes consecutively.This 30-byte binary data stream is the new rate strategy itself after serialization and encoding. The MCU stores this data in the received parameter set variables. In this way, the originally single, opaque 84-byte transaction data packet is successfully decomposed into four independent data units with clear business meanings, and stored in the memory of the electricity meter respectively.

[0036] Then, step S22 is executed. First, the microcontroller (MCU) of the electricity meter designates a specific storage area for this operation; this area is called the parameter preset storage area. This area is located in the electricity meter's non-volatile memory, such as a flash memory chip with a high erase / write cycle life, and its size is designed to accommodate a complete set of rate parameters, such as reserving 64 bytes of space. Crucially, this area is independent of the currently active parameter activation storage area. At any given time, the electricity meter's billing program only reads rates from the active parameter storage area, so any operation on the parameter preset storage area will not affect the current normal billing. The parameter set preset write operation begins. The MCU calls the underlying flash driver to execute the write command. The target address of this command is the starting address of the parameter preset storage area, and the source data is the 30 bytes of parameter set received in the RAM receive buffer. The flash driver may first perform a block erase operation to clear the target area, and then write these 30 bytes of data byte by byte into the physical cells of the flash memory. During the write process, the flash controller's own error correction code (ECC) mechanism also operates to ensure basic write reliability. The preset write phase ends when the driver reports the write operation is complete. Immediately afterwards, to absolutely confirm the physical fidelity of the write, a readback verification operation is triggered. The MCU designates a new memory region, different from the original receive buffer, called the readback verification buffer. Then, the MCU calls the flash driver to execute a read command. The source address of this command is exactly the same as during the write, i.e., the starting address of the parameter preset storage area, and the read length is also 30 bytes. The flash driver reads the data from the physical storage unit and stores it in the RAM readback verification buffer. At this point, the contents of the readback verification buffer are the written parameter set, representing the data currently existing on the physical storage medium. Finally, the MCU performs the core verification comparison. It starts a memory comparison program to compare the data byte-by-byte between two memory regions: one is the receive buffer storing the original data, and the other is the readback verification buffer storing the readback data. The comparison starts from the first byte and continues until the 30th byte. If a byte mismatch is found at any position during the comparison process—for example, the 10th byte in the receive buffer is 0x5F, while the corresponding byte in the readback check buffer is 0x5E—the MCU immediately stops the comparison and sets an internal status flag to failure. If all 30 bytes are compared and every byte is identical, the MCU sets the write status to success. Thus, this step outputs two things: one is the written parameter set, consisting of 30 bytes of data stored in the readback check buffer, and the other is the write status, a boolean or enumerated value indicating success or failure.

[0037] Next, step S23 is executed. This step is triggered only when the write status is successful. If the write status fails, the entire preset process will be aborted, and no hash calculation will be performed. In this embodiment, the previous step has confirmed that the write was successful, so the process can continue. The written parameter set is currently stored in the readback verification buffer of the electricity meter's memory (RAM), and its content is a 30-byte binary data stream that has just been completely read from the parameter preset storage area of ​​non-volatile memory. Choosing this readback data instead of the initially received data as the calculation input is a key design for security, because it ensures that the source of the hash calculation is data that has been physically solidified and actually exists on the storage medium, rather than just a transient copy in memory. The core of processing this input is the SHA-256 algorithm module built into the electricity meter. In resource-constrained embedded devices, this module can be implemented in two ways: one is a pure software implementation, that is, a highly optimized firmware code library that follows standards; the other is a hardware implementation, that is, integrating a dedicated cryptographic calculation coprocessor inside the electricity meter's microcontroller (MCU) chip. Hardware implementation offers higher computational efficiency and lower power consumption. Regardless of its form, the module functions as a deterministic black box, performing a standard SHA-256 hash operation on given input data. Exemplarily, in one specific implementation, step S23, in response to a successful write status, inputs the written parameter set into the built-in SHA-256 algorithm module to obtain the calculated hash, including: the built-in SHA-256 algorithm module processes the written parameter set using the following formula to obtain the calculated hash: ;in, For the parameter set that has already been written, It uses the SHA-256 algorithm. To calculate the hash, the MCU of the electricity meter first calls its built-in SHA-256 algorithm module and initiates a new hash calculation session. Then, the MCU passes the written parameter set—the 30 bytes of data in the readback verification buffer—as input to the SHA-256 module. Upon receiving this 30-byte parameter set, the SHA-256 module performs a series of standardized internal processes. First, it pads the input data, appending specific bits and length information to ensure its total length is a multiple of 512 bits (64 bytes). Then, using a predefined set of initial hash values ​​(IVs) as the starting point for its internal state, the module iteratively compresses the padded data block. Each iteration involves complex bit rotations, XOR, AND, NOT, and modulo operations, mixing the current data block with the internal state of the previous iteration to generate a new internal state. This process is completely deterministic and irreversible. After processing all data blocks, the SHA-256 module outputs its final internal state value. This value is a 256-bit (32-byte) binary number; it is the calculated hash. The MCU retrieves this 32-byte hash value from the module's output register or function return value and stores it in a dedicated temporary variable for use in the next step. For example, if the 30 bytes of data read back are completely consistent with the original data sent by the master station, then the calculated hash generated by the local SHA-256 module of the energy meter will be exactly equal to the integrity hash encapsulated in the transaction data packet sent by the master station, i.e., 5A9A...21A. Conversely, even if only one bit in the written parameter set is flipped for some reason, due to the avalanche effect of the SHA-256 algorithm, the final calculated hash will be a completely new value that is entirely different from the original hash value and has no relation to it.

[0038] Finally, step S24 is executed. The integrity comparison operation is performed by the microcontroller (MCU) of the electricity meter. This is a computationally efficient operation, essentially a deterministic comparison of memory data blocks. The MCU calls a built-in memory comparison function, which receives two pointers to memory addresses (one pointing to a variable storing the calculated hash, and the other pointing to a variable storing the received integrity hash) and a parameter indicating the comparison length (32 bytes in this case). The function compares byte by byte, starting from the beginning of the two addresses, until all 32 bytes have been compared. The state decision is a logical judgment process based on the comparison result. The electricity meter's firmware predefines two final preset states: one is ready, which can be represented by a specific enumeration value or bytecode such as 0x01; the other is failed, which can be represented by the bytecode 0xFF. The MCU determines which state to set based on the return value of the memory comparison function.

[0039] The specific implementation process is divided into two scenarios: Scenario 1: Comparison successful. After comparing all 32 bytes, the memory comparison function finds that the two hash values ​​are exactly the same. This means that the entire data link, from the main station, through network transmission, to being received, parsed, written to non-volatile memory by the energy meter, and then read back, is completely authentic and error-free. Based on this, the MCU determines that the preset operation was successful. Therefore, the MCU sets an internal status variable, namely the preset state, to ready, i.e., assigns it a value of 0x01. At the same time, the MCU marks the data in the parameter preset storage area as valid and in an activation-pending state, and retains the received effective timestamp and received transaction ID extracted in S21 for subsequent activation and reporting.

[0040] Scenario 2: Comparison Failure. If, during the comparison process, the memory comparison function finds a mismatch at any byte position—for example, the 20th byte of the hash calculation is 0xA8, while the corresponding byte of the received integrity hash is 0xA9—the function will immediately abort and return a result indicating inequality. This clearly indicates that the data currently physically stored in the electricity meter deviates from the original data at the master station. Regardless of whether this deviation is due to transmission errors, write errors, or malicious tampering, the data must be considered untrustworthy. Based on this, the MCU determines that the current preset operation has failed. Therefore, the MCU sets the preset status variable to failure, i.e., assigns it a value of 0xFF. Simultaneously, for safety reasons, the MCU will immediately mark the data in the parameter preset storage area as invalid or directly erase it to prevent accidental activation. All temporary data related to this transaction (such as effective timestamps) is also discarded.

[0041] In step S3, the meter side reports the received transaction ID and preset status as a preset receipt to the master station. It is understandable that after the master station sends the transaction data packet, its internal processing status at the meter side is unknown, and the entire cost control process is in an open-loop state. Without a clear feedback mechanism, the master station cannot distinguish which meters have been successfully preset and which have failed for some reason, thus hindering effective status management, failure retransmission, or subsequent activation scheduling. This is unacceptable in batch update scenarios involving massive numbers of meters. Therefore, in this application, the meter side reports the received transaction ID and preset status as a preset receipt to the master station to establish a closed-loop, reliable status confirmation channel. Through this reporting action, the meter proactively notifies the master station of its local preset and verification results, enabling the master station to accurately and in real-time grasp the progress of each update transaction, providing crucial information for subsequent macro-control and decision-making.

[0042] For example, in one specific implementation, step S3 is implemented as follows: This step involves constructing and sending a reporting data packet named "Preset Receipt". The structure of this data packet is predefined by the communication protocol to be concise and efficient, clearly conveying the necessary information. In this embodiment, the format of the preset receipt data packet is defined as a fixed-length 17-byte data frame, with the following structure: 1. Transaction ID: 16 bytes, used to indicate which specific task this receipt responds to. 2. Preset Status: 1 byte, used to clearly inform the master station of the preset and verification results.

[0043] The specific implementation process is scheduled and executed by the microcontroller (MCU) of the electricity meter. The MCU first allocates a 17-byte buffer in its memory for transmission. Then, it performs data encapsulation. The MCU copies the received transaction ID (00010002018B47E8A1B2C3D40000000A) stored in a temporary variable completely to the first 16 bytes of the transmission buffer. Next, the MCU reads the value of the preset status variable and writes it to the 17th byte of the transmission buffer. The content written here depends on the decision result of step S24: if the conclusion of the preceding step S24 is that the preset was successful, the value of the preset status variable is 0x01 (ready). The MCU then writes byte 0x01 to the last byte of the buffer. At this point, the content in the transmission buffer is a complete preset receipt indicating success. If the conclusion of the preceding step S24 is that the preset failed, such as due to a hash check mismatch, the value of the preset status variable is 0xFF (failure). The MCU then writes byte 0xFF to the last byte of the buffer. At this point, the content in the send buffer is a complete, pre-set receipt indicating failure.

[0044] After the 17-byte pre-configured acknowledgment data packet is assembled in memory, the MCU calls its communication interface controller. It sends a transmission command to the communication module (e.g., a power line carrier PLC module or a wireless RF module) using the start address of the transmit buffer and the data length (17 bytes) as parameters. Upon receiving the command, the communication module handles the details of the physical layer and data link layer, including adding necessary protocol headers and trailers before and after the 17-byte core payload data. The header contains routing information such as the destination address (i.e., the master station address) and the source address (local meter ID), while the trailer may contain a Cyclic Redundancy Check (CRC) code to verify the integrity of the transmitted frame. Finally, the 17-byte core payload data is transmitted via power line or radio waves, with the destination address being the master station's address.

[0045] In step S4, on the master station side, if the preset status is "ready," it records that the meter has been successfully preset and is waiting for the effective timestamp; if the preset status is "failed," it records that the meter preset failed and generates a retransmission instruction. It should be understood that after the electricity meter completes local preset and verification and reports the result, control of the entire fee control transaction returns to the master station side. At this time, the master station, as a centralized management node, cannot simply passively receive data; it must analyze and process the asynchronous feedback information from thousands of terminals and make intelligent and differentiated subsequent processing decisions accordingly. Without this step, the entire process would lack macro-control and anomaly handling capabilities, and the final success rate of large-scale update tasks could not be guaranteed. Therefore, the master station's recording and decision-making based on the preset status aims to achieve centralized status management and process control over the entire fee control transaction lifecycle. By providing an authoritative final interpretation of the receipt information, the transaction status of each meter is persistently recorded, and the corresponding subsequent processes are automatically triggered, whether it is entering a silent waiting activation phase or starting the necessary fault recovery procedures, thereby ensuring the controllability, reliability and eventual consistency of the entire update task.

[0046] For example, in one specific implementation, step S4 is implemented as follows: After receiving the pre-set receipt data packet, the communication service of the main station will first perform data link layer processing, such as CRC check to confirm that the transmission is error-free, and then pass the 17-byte core payload data to the upper-layer business application logic for processing.

[0047] The business application logic on the main station side first parses these 17 bytes of data. According to the predefined protocol format, it reads the first 16 bytes to obtain the transaction ID contained in the receipt, such as 00010002018B47E8A1B2C3D40000000A; then it reads the 17th byte to obtain the preset status code.

[0048] Next, the core processing logic of the main station will use the parsed transaction ID as a key index to query its backend fee control transaction management database. When the task is initiated in step S1, this database has already created a unique transaction record for this operation sent to the target meter, such as ID 330123123456. This record contains at least the transaction ID, meter ID, initial issuance time, preset effective timestamp, the complete original text of the issued transaction data packet, a field indicating the current status (e.g., initially "issued"), and a retry counter field for retransmission control, with an initial value of 0.

[0049] After successfully locating the database record corresponding to the received transaction ID, the master station executes conditional branch logic based on the parsed preset status code: Case 1: Preset status is ready. If the parsed 17th byte status code is 0x01, the master station determines that the meter has successfully completed parameter preset and the data verification is correct. At this time, the master station performs the following sequence of operations: First, it updates the status field of the corresponding transaction record in the database, changing it from "issued" to "preset successfully". Simultaneously, it may add an additional preset success timestamp field to the record to record the current time for subsequent auditing and analysis. This database update operation completes the task of recording that the meter has been successfully preset. After completing the recording, the master station's current task for this transaction of the meter is finished, and no further active operation is required. Instead, it enters a silent monitoring phase waiting for the effective timestamp to arrive. A background scheduling service on the master station side periodically scans the database to find all transactions in the preset successful state whose effective timestamps are about to expire, so as to prepare to execute the subsequent activation status confirmation process near the activation time.

[0050] Scenario 2: Preset Status is Failed. If the parsed 17th byte status code is 0xFF, the master station determines that the meter encountered a problem during the presetting process (e.g., hash verification failed). In this case, the master station executes a predefined fault recovery and retransmission logic: First, it updates the status field of the corresponding transaction record in the database, changing it to preset failure, and records the time of failure. This completes the task of recording the meter's presetting failure. Next, the master station needs to generate a retransmission command. This follows a more robust retransmission strategy. The master station reads the value of the retry counter field in the transaction record and increments it. Then, it checks whether this new count exceeds the preset maximum number of retries (e.g., a maximum of 3 retries). This preset maximum number of retries is a strategic parameter pre-configured by maintenance personnel based on the historical statistical reliability of the communication channel, the urgency of service updates, and to prevent unnecessary resource consumption on permanently faulty equipment. If the limit is not exceeded, the master station calculates the delay time for the next retransmission based on a preset backoff algorithm such as exponential backoff. For example, waiting 1 minute after the first failure and 5 minutes after the second failure. Then, the master station adds a retransmission task to the task scheduling queue. This task contains the original transaction ID and the calculated delay time. When the delay time is reached, the scheduler triggers the task. The task logic retrieves the original, complete 84-byte transaction data packet from the database based on the transaction ID and resends it to the target meter. If the retry counter has reached its limit, the master station updates the transaction status to permanent failure and may trigger an alarm to notify maintenance personnel for manual intervention.

[0051] In step S5, the meter side compares the current system time with the stored effective timestamp to obtain the activation status, and reports the transaction ID and activation status to the master station. Correspondingly, after the electricity meter successfully presets the new rate policy and receives confirmation from the master station, the entire update transaction enters a silent standby phase. Although the new policy data has been securely stored, it has not yet taken effect. At this point, the core challenge becomes how to ensure that all relevant electricity meters can accurately and synchronously switch from the old policy to the new policy at the scheduled business time. Relying on the master station to issue broadcast commands at the activation time is not feasible, as this would reintroduce the risk of unreliable communication and may lead to fragmented activation times due to network congestion. Therefore, this application performs time comparison and status reporting on the meter side to establish an autonomous, accurate, time-based internal activation triggering mechanism and constructs a post-confirmation communication handshake. This completely decouples the critical activation operation from unstable external communication, ensuring the atomicity and time accuracy of activation, and through post-reporting, allows the master station to promptly learn of the activation event, thereby continuing to drive the entire transaction process.

[0052] For example, in one specific implementation, step S5 is executed as follows: The execution of this embodiment begins after the electricity meter completes step S2 and reports the preset receipt from S3. At this time, the electricity meter has persistently stored the following key information: the transaction ID received from S21 and the received effective timestamp; and a new 30-byte rate parameter set written to the parameter preset storage area and successfully verified in S22. The internal transaction status of the electricity meter is preset successful, awaiting activation.

[0053] An internal time monitoring and comparison logic exists within the electricity meter. Exemplarily, in one specific implementation, step S5 includes: in response to the current system time being greater than or equal to a stored effective timestamp, setting the activation state value to "activated". The electricity meter's microcontroller (MCU) initiates a high-frequency timed task, for example, executing once per second. This task acquires the current system time provided by the electricity meter's internal high-precision real-time clock (RTC) module and compares it with the stored received effective timestamp. To ensure the accuracy of the activation, the electricity meter's RTC must maintain strict synchronization with the time reference on the master station side through periodic Network Time Protocol (NTP) synchronization or receiving broadcast time signals.

[0054] Before the effective timestamp arrives, for example, at 23:59:59 UTC on May 31, 2025, the scheduled task will retrieve the current system time less than 1748736000 each time it executes. The comparison result is false, so no action is triggered. The electricity meter's billing procedure will continue to read from its parameter activation storage and execute the old rate policy, and everything will operate as usual.

[0055] When the current system time advances to 00:00:00 UTC on June 1, 2025, the scheduled task executes again. At this time, the Unix timestamp value of the acquired current system time becomes 1748736000. The MCU performs a comparison operation and finds that the current system time is greater than or equal to the stored effective timestamp, thus the condition is met for the first time. This is the activation trigger signal.

[0056] In response to this trigger signal, the MCU immediately executes a series of predefined atomic activation operations. First, it sets the value of an internal state variable to "activated," as represented by bytecode 0x01. Next, the MCU performs the crucial parameter switching. This is not accomplished through time-consuming and potentially interruptible data copying, but rather by modifying an internal pointer to the current rate parameter. Previously, this pointer pointed to the parameter activation memory storing the old policy. At the moment of triggering, the MCU, in an uninterruptible instruction cycle, changes the address of this pointer to point to the parameter preset memory storing the new policy. This pointer switching operation is computationally instantaneous, ensuring the atomicity of the rate policy switch. From this moment on, the electricity meter's billing engine will automatically read rate data from the new storage address when calculating electricity charges, and the new rate policy takes effect immediately. The original parameter activation memory is marked as obsolete and can be erased in subsequent maintenance cycles.

[0057] After completing the internal state transition and parameter pointer redirection, the MCU immediately prepares to report the activation status. It needs to construct an activation status reporting data packet to notify the master station that local activation has been successfully completed on time. The structure of this data packet is similar to the preset receipt, also adhering to the principle of simplicity. For example, a 17-byte data frame: 1. Transaction ID: 16 bytes. 2. Activation status: 1 byte. The MCU assembles this data packet in its memory's transmit buffer. It copies the previously stored 16 bytes of the received transaction ID to the first 16 bytes of the buffer. Then, it writes the activation status code, just set to activated 0x01, into the 17th byte.

[0058] After the data packet is assembled, the MCU sends out this 17-byte activation status report data packet through its communication interface controller. The communication module is responsible for the necessary low-level protocol encapsulation and ultimately sends the report information to the master station via power line or wireless channel.

[0059] In step S6, after determining that the activation status is active, the master station uses a random challenge number to verify the activation status with the meter to obtain the activation status proof result. That is, the activation status reported by the meter is merely a unilateral declaration, indicating that the meter believes it has successfully switched to the new policy. However, in the core business of billing, the master station cannot solely rely on this declaration to determine the final success of the task. This is because there may be extreme cases, such as internal software logic errors in the meter, causing it to report activation but actually still running the old policy, or running a corrupted version of the policy. To establish an absolutely reliable, post-event final verification mechanism, an irrefutable on-site inspection of the meter's actual operating status is required. Therefore, the master station uses a random challenge number to verify the activation status with the meter, aiming to initiate a dynamic, cryptographically secure challenge to obtain irrefutable evidence of the rate parameter set currently being used by the meter. This ensures that the final confirmation from the main station is based on factual evidence, rather than just a status report, thus bringing the entire expense control process to a final conclusion.

[0060] For example, in one specific implementation, step S6 includes: S61, after determining that the activation state is activated, generating and sending a random challenge number to the meter side; S62, the meter side reads the currently effective parameter set and generates an activation state certificate based on the currently effective parameter set and the random challenge number; S63, the meter side reports the activation state certificate to the master station side; S64, the master station side generates an expected certificate based on the serialized new parameter set and the random challenge number; S65, the master station side determines whether the expected certificate and the activation state certificate are consistent. If they are consistent, it confirms that the meter is operating correctly under the new strategy; if they are inconsistent, it marks an anomaly.

[0061] In the above implementation scheme, step S6 is implemented as follows: First, step S61 is executed. After receiving and parsing the data packet, the business application logic of the master station first executes the confirmation process to determine that the activation status is activated. It uses the transaction ID in the data packet to find the corresponding transaction record in its expense control transaction management database. The master station will verify whether the current status of the record is preset successful. Only when the status matches and the received activation status code is indeed 0x01, the master station confirms the validity of the activation event and updates the status of the transaction in the database to "activated and reported, pending proof". After completing the status confirmation, the master station immediately starts the process of generating and issuing random challenge numbers. The first step is to generate random challenge numbers. This is a one-time, unpredictable random number, the purpose of which is to ensure that each activation proof is brand new and cannot be reused or forged. The master station will call a cryptographically secure pseudo-random number generator, which is a standard, rigorously designed algorithm module that can generate statistically unbiased random sequences that cannot predict future outputs from past outputs. The master station instructs the module to generate a random byte string of a predetermined length, such as 16 bytes. The generated result, such as E8A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5, is the random challenge number used in this challenge. Next, the master station needs to send this newly generated random challenge number to the electricity meter. To ensure the electricity meter can associate this challenge number with the correct transaction, it needs to be encapsulated along with the transaction ID. The master station constructs a new data packet called the activation proof challenge packet. This packet can be defined as a 32-byte data frame: 1. Transaction ID: 16 bytes. 2. Random challenge number: 16 bytes. The master station assembles this packet in its memory's send buffer. It copies the current transaction ID, 00010002018B47E8A1B2C3D40000000A, to the first 16 bytes of the buffer. Then, the newly generated 16-byte random challenge number, E8A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5, is copied to the last 16 bytes of the buffer. After the data packet is encapsulated, the master station sends this 32-byte activation proof challenge data packet to the target energy meter through its communication module, after necessary underlying protocol processing.

[0062] Then, step S62 is executed. After receiving the activation proof challenge data packet, the microcontroller (MCU) of the electricity meter first parses it, extracting the first 16 bytes of the transaction ID and the last 16 bytes of the random challenge number, i.e., E8A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5. The MCU first compares the received transaction ID with its own stored current transaction ID to ensure that the challenge is for this rate update task. After successful verification, the 16-byte random challenge number is stored in a temporary variable. Next, the MCU reads the currently effective parameter set. This is not read from any storage location, but must be read from the unique parameter source currently being used by the billing engine. During activation in step S5, the internal current rate parameter pointer has been redirected to the original parameter preset storage area. Therefore, the MCU will read all the rate parameter data completely from this effective storage area according to the current pointer's direction. In this embodiment, this is the 30-byte binary data stream. The MCU stores this 30-byte data, representing the actual billing basis of the electricity meter at this moment, into another temporary variable. After obtaining the two core elements of the current effective parameter set and the random challenge number, the MCU begins to generate an activation status certificate. For example, in one specific implementation, step S62, the meter side reads the current effective parameter set and generates an activation status certificate based on the current effective parameter set and the random challenge number, including: generating the activation status certificate based on the current effective parameter set and the random challenge number using the following formula: ;in, The number of challenges is random. For the currently effective parameter set, For splicing operations, For hash calculation function, This serves as proof of activation. (Here) The hash calculation function, as before, is the SHA-256 algorithm module built into the electricity meter. The specific generation process is as follows: The MCU allocates a new contiguous buffer of 46 bytes (30 bytes + 16 bytes) in memory. Then, it performs a concatenation operation: First, it copies the 30-byte current effective parameter set from its temporary variable completely to the first 30 bytes of this new buffer. Next, it copies the 16-byte random challenge number from its temporary variable to the position starting at the 31st byte of the buffer, immediately following the parameter set data. After concatenation, this 46-byte buffer contains a unique data block composed of the current effective strategy and the one-time challenge number. Finally, the MCU calls its built-in SHA-256 algorithm module, using this 46-byte concatenated data block as the sole input message for hash calculation. After its standard, deterministic internal operations, the SHA-256 module outputs a 32-byte hash digest. This 32-byte output value is the activation status proof. For example, the calculated result might be C1B2A3D4...F5E6D7C8. This activation state proves that it is simultaneously bound to the effective parameter set and the random number. A change in either one will lead to a significant change in the final hash value.

[0063] Next, step S63 is executed. This step involves constructing and sending an activation certificate receipt data packet. To ensure that the master station can associate the received certificate with the correct transaction and challenge, this data packet must contain the transaction ID and the activation status certificate itself. According to the predefined communication protocol, the format of this data packet can be designed as a fixed-length 48-byte data frame, with the following structure: 1. Transaction ID: 16 bytes, used to uniquely identify this cost control task. 2. Activation status certificate: 32 bytes, i.e., the cryptographic credential generated locally by the energy meter. The specific implementation process is initiated immediately after the energy meter's microcontroller (MCU) completes the calculation in S62. First, the MCU prepares a 48-byte send buffer in its memory. Then, it performs a data encapsulation operation. The MCU completely copies the stored 16-byte transaction ID corresponding to the current transaction, 00010002018B47E8A1B2C3D40000000A, into the first 16 bytes of the send buffer. Next, the MCU copies the 32-byte activation status certificate calculated in step S62 from its temporary storage variable to the last 32 bytes of the send buffer, immediately following the transaction ID. At this point, a complete 48-byte activation certificate receipt data packet is ready in memory. Finally, the MCU calls its communication interface controller, using the start address of the send buffer and the data length (48 bytes) as parameters, to issue a send command. Upon receiving the command, the communication module, such as the PLC or RF module, handles all the underlying communication protocol processing, including adding the necessary frame header (containing the master station address) and frame trailer (containing the CRC checksum) to the 48-byte payload data, then performing channel coding and modulation on the complete data frame, and finally sending the receipt data packet via power line or radio wave.

[0064] Next, step S64 is executed. The master station needs to prepare the benchmark data for comparison. The master station's business application logic first parses the 16-byte transaction ID from the received 48-byte activation proof receipt. Then, it uses this transaction ID as the primary key to query and retrieve two key raw data related to this fee control task from its database: 1. Serialized new parameter set: This is a 30-byte binary data stream generated in step S11, representing the entire content of this rate update. The master station has bound it to the transaction ID and persisted it before issuing it. 2. Random challenge number: This is a 16-byte one-time random number E8A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5 specifically generated in step S61 for this activation proof challenge. The master station associates it with the transaction ID and temporarily stores it while issuing it. After successfully obtaining these two authoritative raw data, the master station begins to execute the exact same calculation process as the electricity meter in S62 to generate the expected proof. This process also follows the formula in S62. The specific generation process is as follows: The main station's computing module allocates a contiguous 46-byte (30 bytes + 16 bytes) buffer in memory. Next, it performs a concatenation operation: First, it copies the 30-byte serialized new parameter set retrieved from the database completely to the first 30 bytes of the buffer. Then, it copies the 16-byte random challenge number, also retrieved from the database or cache, immediately afterward, to bytes 31 to 46 of the buffer. After this operation, the contents of this 46-byte memory block precisely represent the input data used to generate the proof if the electricity meter is functioning correctly. Finally, the main station calls its built-in SHA-256 cryptographic computation service, which is equivalent to the electricity meter standard, to perform a hash operation on this 46-byte concatenated data block as input. After a series of deterministic internal calculations, the service outputs a 32-byte hash digest. This digest is the final output of this step, the expected proof. Since the input data (original parameter set and original challenge number) used by the master station is exactly the same as the input data used by a correctly operating electricity meter, the calculated expected proof must also be completely consistent with the correct activation status proof reported by the electricity meter, and its value is also C1B2A3D4...F5E6D7C8.

[0065] Finally, step S65 is executed. The core operation for determining whether the expected proof and the activation state proof are consistent is an efficient and deterministic binary data comparison. The main site's business application logic calls a memory comparison function, passing the memory address storing the activation state proof and the memory address storing the expected proof, as well as the comparison length (32 bytes), as parameters. This function performs a strict byte-by-byte equality comparison starting from the beginning of the two addresses.

[0066] Based on the result returned by the comparison function, the master station executes the final state decision and record. The specific implementation process involves two distinct paths: Scenario 1: Completely identical. After comparing all 32 bytes, the memory comparison function finds no differences and returns an equal result. This irrefutably proves cryptographically that the parameter set currently used for billing by the electricity meter is exactly the same as the original parameter set initially issued by the master station. Based on this, the master station determines that the entire rate update transaction has been successfully completed. Subsequently, the master station executes the final database update operation. It uses the current transaction ID as an index to update the status field of the corresponding record in the fee control transaction management database from "activated and reported, awaiting proof" to the final successful status, such as "confirmed to be running normally." Simultaneously, it may record the timestamp of this successful confirmation. At this point, all processes of the transaction are complete, the status is permanently fixed as successful, and no further operations are required.

[0067] Scenario 2: Inconsistency. If the memory comparison function finds a byte difference at any point during the comparison process, it will immediately stop and return an unequal result. This situation reveals a serious problem: although the electricity meter reported activation, the parameter set used to generate the proof deviates from the original version on the master station. This could stem from extremely rare hardware failures, memory bit flips, or even malicious attacks. Based on this, the master station determines that the activation proof has failed, and the electricity meter is in an abnormal and untrusted working state. At this time, the master station will immediately execute the anomaly marking process. It also uses the transaction ID to update the database, updating the status field of the corresponding record to the final failure status, such as activation proof anomaly. This is not just a simple record; it will immediately trigger a high-priority alarm event. This alarm will be pushed to the operation and maintenance monitoring platform and generate detailed logs, including the transaction ID, meter ID, the specific values ​​of the expected proof and the received proof, etc., so that operation and maintenance personnel can perform emergency manual intervention, troubleshooting, and remote diagnosis.

[0068] Specifically, in the final confirmation stage of cost control transactions, if the proof of activation status heavily relies on the master station initiating communication to issue a one-time random number, it introduces an additional synchronous network interaction round trip. This request-response model, especially in large-scale deployment scenarios with a massive number of electricity meters, significantly lengthens the final confirmation time for a single transaction and exacerbates the already valuable network channel communication burden. To eliminate this dependence on real-time communication and improve the efficiency and robustness of the entire process, it is desirable for the electricity meter to autonomously and asynchronously generate a self-contained and verifiable proof of activation status after successful activation. Therefore, in this step, the electricity meter autonomously proves its status based on the calculated hash and activation timestamp written into the parameter set. The core purpose is to replace the externally injected random number with an intrinsic, unpredictable dynamic value (i.e., the precise activation timestamp) uniquely related to the activation event, thereby optimizing the synchronous challenge-response mechanism into an asynchronous, event-driven proof and reporting mechanism. This optimization utilizes two key characteristics of cryptographic hash functions. First, there's the deterministic fingerprint characteristic: the hash value of a large data block (such as a complete set of rate parameters) can serve as an equivalent, compact weight representation in cryptographic computation. Second, there's the avalanche effect: rehashing this weight representation with an unpredictable dynamic value (activation timestamp) yields a similarly unpredictable and unique result, entirely dependent on the two original inputs, thus providing a solid foundation for independent verification by the master station. This not only significantly saves computational and I / O resources for the electricity meter but also substantially reduces transaction confirmation latency and the risk of failure due to network timeouts by eliminating network round trips.

[0069] Based on this, in a preferred embodiment, step S6 includes: S6-1, after determining that the activation state is activated, the meter side generates an activation state certificate by performing autonomous timestamp proof based on the calculated hash of the written parameter set and the activation timestamp; S6-2, the meter side reports the activation state certificate to the master station side; S6-3, the master station side generates an expected certificate based on the serialized new parameter set and the activation timestamp; S6-4, the master station side determines whether the expected certificate and the activation state certificate are consistent. If they are consistent, it is confirmed that the meter is operating correctly under the new strategy; if they are inconsistent, an anomaly is marked.

[0070] In detail, in step S6-1, firstly, the precise activation timestamp is captured. The purpose of this step is to obtain a dynamic factor that can uniquely identify this activation event and has unpredictability, to replace the externally issued random number. This completely decouples the generation of the proof from external real-time communication and strongly binds the proof to a real, traceable physical event time point, effectively preventing replay attacks. Specifically, in step S5, the moment the microcontroller (MCU) of the electricity meter completes the atomic operation of rate parameter switching (e.g., redirecting the internal current rate parameter pointer from the old parameter area to the new parameter area), the MCU immediately reads the current, most accurate system time from its internal high-precision real-time clock (RTC) module. This timestamp needs to contain sufficient precision to ensure its uniqueness, for example, an 8-byte UTC timestamp accurate to milliseconds. For example, the captured timestamp integer value is 1748736000123, representing June 1, 2025, 00:00:00.123 UTC. This value is recorded as the activation timestamp of this transaction. The hash of the parameter set is then stored in a temporary variable. Next, the calculated hash of the parameter set is retrieved to efficiently obtain the cryptographic fingerprint representing all the information of the new rate policy, avoiding the reading and processing of the large original parameter set. Using the calculated hash based on the written parameter set instead of the currently effective parameter set is a key performance optimization. This is because the currently effective parameter set may be hundreds or even thousands of bytes, while the calculated hash is a fixed-length value (e.g., SHA-256 results in 32 bytes). Furthermore, since reading the entire parameter set is a relatively slow and energy-intensive I / O operation, directly reading the 32-byte hash value stored in the transaction status table, usually adjacent to information such as status flags, is extremely efficient and significantly reduces I / O overhead. In practice, the MCU does not read the complete 30-byte parameter set from the effective storage area. Instead, it directly reads the calculated hash generated and stored in step S23 of step S2 from its internally maintained rate control transaction status table. This hash value is usually stored adjacent to information such as the transaction ID and transaction status, resulting in extremely high read efficiency. For example, the 32-byte SHA-256 hash value retrieved by the MCU is 5A9A...21A. This value is recorded as the calculated hash of the written parameter set. Next, the calculated hash representing the static identity of the parameter set is cryptographically bound to the activation timestamp representing the dynamic uniqueness of the activation event, generating final, irrefutable evidence. This produces a single, highly concentrated, and secure hash value that simultaneously verifies what was activated and when it was activated. Specifically, the MCU strictly follows the following formula to generate the proof: ;in, It's the activation timestamp. This involves calculating the hash of the already written parameter set. First, the MCU prepares a contiguous 40-byte buffer (32-byte hash + 8-byte timestamp) in memory. Then, a concatenation operation is performed: the 32-byte hash is concatenated... (5A9A...21A) is copied to the first 32 bytes of the buffer; then, 8 bytes are copied... (The binary representation of 1748736000123) is copied to the last 8 bytes of the buffer. Finally, the MCU calls its built-in SHA-256 algorithm module ( The module takes this 40-byte concatenated data block as input and performs a hash calculation. After the module's operation, it outputs a 32-byte hash digest. This digest is the proof of the activation state, for example... Its value is F3E4D5...A1B2C3. This proof, along with the activation timestamp it used, will be reported to the main site.

[0071] In step S6-2, after successfully generating the activation status certificate on the electricity meter side, the core task of this step is to proactively report this crucial cryptographic credential, along with the activation timestamp upon which its generation depends, as a complete, self-contained activation receipt to the master station. This completes the event-driven closed-loop communication, securely and efficiently transmitting all evidence proving the current true operating status of the electricity meter back to the master station for final verification without additional interaction. The specific implementation process is initiated immediately after the electricity meter's microcontroller (MCU) completes the calculations in S6-1. First, the MCU needs to construct an activation receipt data packet. To ensure that the master station can uniquely associate the received certificate with the correct transaction and obtain all the dynamic information required for verification, this data packet must contain a transaction ID, activation timestamp, and activation status certificate. According to the predefined communication protocol, the format of this data packet can be designed as a fixed-length 56-byte data frame, with the following structure: 1. Transaction ID: 16 bytes, used to uniquely identify this cost control task. 2. Activation timestamp: 8 bytes, used to transmit the precise time of the activation event. 3. Activation Status Proof: 32 bytes, i.e., the cryptographic credential generated locally by the electricity meter. The MCU prepares a 56-byte transmit buffer in its memory and performs data encapsulation operations. It completely copies the stored 16-byte transaction ID corresponding to the current transaction to the first 16 bytes of the transmit buffer. Next, the MCU copies the binary representation of the 8-byte activation timestamp with a value of 1748736000123, captured and used for calculation in the previous step S6-1, to bytes 17 to 24 of the transmit buffer. Finally, the MCU completely copies the 32-byte activation status proof "F3E4D5...A1B2C3" calculated in S6-1 from its temporary storage variable to the last 32 bytes of the transmit buffer, i.e., bytes 25 to 56. In this way, a complete 56-byte activation receipt data packet is ready in memory. The MCU then calls its communication interface controller, using the starting address of the transmit buffer and the data length (56 bytes) as parameters, and issues a transmit command. The communication module (such as a PLC or RF module) is responsible for all the underlying communication protocol processing, including adding the necessary frame header (containing the master station address) and frame trailer (containing the CRC check code) to the 56-byte payload data, then performing channel coding and modulation on the complete data frame, and finally sending the acknowledgment data packet out via power line or radio wave.

[0072] In steps S6-3 and S6-4, the master station's business application logic first parses the received data packet, extracting three key pieces of information: a 16-byte transaction ID, an 8-byte activation timestamp, and a 32-byte activation status certificate. The master station uses the transaction ID as a key index to find the corresponding transaction record in its expense control transaction management database. Step 1: Time validity verification. Although the master station does not pre-issue the activation timestamp, it knows the planned effective time of the policy. Thus, when the master station receives the activation timestamp reported by the meter, it can perform a time window verification to verify whether the activation timestamp falls within a reasonable time interval of the planned effective time. Through this verification, the master station can be certain that the received activation timestamp is legitimate and a true timestamp related to this transaction. The master station retrieves the preset planned effective time from the database for this transaction record. In this embodiment, this value is June 1, 2025, 00:00:00.000 UTC, and its corresponding millisecond-level timestamp is 1748736000000. The master station compares the received activation timestamp 1748736000123 with the planned effective time to determine if it falls within a pre-defined acceptable time window. This time window is a configurable system parameter, for example, set to ±5 seconds (5000 milliseconds) of the planned effective time. Therefore, the master station determines whether 1748736000123 is within the range [1748736000000-5000, 1748736000000+5000]. Since the value is within this range, the time validity verification passes. If the received timestamp exceeds this window, the master station directly rejects the proof, immediately marks the transaction as abnormal, and records a detailed error log; subsequent cryptographic verification will not be performed. Step Two: Cryptographic Consistency Verification (covering S6-3 and S6-4). After the time validity verification passes, the master station continues with this step to finally confirm whether the parameter set operating internally by the energy meter is correct.

[0073] Implementation of S6-3: The master station generates the expected proof based on the serialized new parameter set and the activation timestamp. The master station retrieves the original 30-byte serialized new parameter set generated for this transaction in step S1 from the database. Then, the master station executes a calculation process completely equivalent to that in S6-1 for the electricity meter to generate the expected proof. First, the master station calls its built-in SHA-256 algorithm module to perform a hash calculation on this 30-byte serialized new parameter set, obtaining a 32-byte expected calculation hash. Next, the master station concatenates this expected calculation hash with the 8-byte activation timestamp received from the electricity meter in the first step, forming a 40-byte contiguous data block. Finally, the master station again calls the SHA-256 algorithm module to perform a hash calculation on this 40-byte concatenated data block. The 32-byte output result is the expected proof. Since all input data and calculation methods are completely consistent with a correctly functioning electricity meter, the generated expected proof has the value F3E4D5...A1B2C3.

[0074] S6-4 Implementation: The master station determines whether the expected proof and the activation status proof are consistent and makes a decision, which is the final decision point for the entire cost control transaction. The master station performs a strict, byte-by-byte memory comparison between the 32-byte expected proof F3E4D5...A1B2C3 just generated in S6-3 and the 32-byte activation status proof F3E4D5...A1B2C3 parsed from the activation receipt. If the comparison results are completely consistent, it indicates that both verification steps have passed. Based on this, the master station finally confirms that the policy update transaction for the electricity meter has been successfully completed and that the electricity meter is operating accurately under the correct new policy. The master station updates the status of the transaction record in the database to the final success status, confirming normal operation and recording the confirmation time. If the comparison results are inconsistent, it indicates that although the activation time is valid, there is a problem with the parameter set inside the electricity meter. The master station determines that the transaction has failed, updates the record status in the database to the final failure status, and if the activation proof is abnormal, immediately triggers a high-priority alarm to notify the operation and maintenance personnel for manual intervention. Therefore, by eliminating network round trips, the network latency for transaction confirmation can be significantly reduced. Furthermore, the final proof is generated and proactively reported immediately after the meter is activated, without waiting for the main station to poll or issue instructions. This allows the backend system of the main station to be designed in an event-driven mode, greatly improving the system's scalability and throughput.

[0075] In summary, the method for single-phase prepaid smart meters based on the embodiments of this application has been clarified, aiming to solve the non-atomicity problem of rate policy updates caused by unreliable communication and limited equipment resources. A lightweight two-phase transaction mechanism of pre-setting and activation is introduced. This scheme no longer uses scattered instruction issuance, but encapsulates the complete new rate policy into a transaction data packet for overall transmission. After receiving the packet, the meter first performs pre-setting and integrity verification on the entire data packet, and only enters the ready state after confirming that it is correct, thereby avoiding data inconsistency caused by update interruption. The activation of the new policy is precisely triggered by a unified effective timestamp, ensuring the synchronization of activation. Finally, through an activation status proof mechanism based on random challenge numbers, the master station can remotely verify that the meter is operating under the correct new policy, ensuring the atomicity, accuracy, and traceability of the entire prepaid process.

[0076] Figure 5 This is a block diagram of a single-phase prepaid smart energy meter system according to an embodiment of this application. Figure 5 As shown, the single-phase prepaid smart energy meter system 100 according to an embodiment of this application includes: a master station side 110 and a meter side 120; wherein, the master station side 110 includes: a transaction data packet acquisition module 111, used to perform transaction initialization and parameter set encapsulation based on the target meter ID and a new rate strategy to obtain a transaction data packet; a preset state judgment module 112, used to record that the meter has been successfully preset and wait for the arrival of the effective timestamp if the preset state is ready; if the preset state is failed, record that the meter preset has failed and generate a retransmission instruction; and an activation state proof module 113, used to use the master station side to determine the activation state. Once the active state is confirmed as activated, the activation status is verified by a random challenge number with the meter side to obtain the activation status verification result. The meter side 120 includes: a transaction data packet verification module 121, which performs parameter set preset and verification on the transaction data packet after receiving it to obtain a preset status; a transaction ID preset status reporting module 122, which reports the received transaction ID and preset status as a preset receipt to the master station side; and an activation status generation module 123, which compares the current system time with the stored effective timestamp to obtain the activation status, and reports the transaction ID and activation status to the master station side.

[0077] Those skilled in the art will understand that the specific operations of each step in the above-described single-phase prepaid smart energy meter system have been referenced above. Figures 1 to 4 The method for single-phase prepaid smart energy meters has been described in detail, and therefore, its repeated description will be omitted.

Claims

1. A method for a single-phase prepaid smart energy meter, characterized in that, include: S1: The master station performs transaction initialization and parameter set encapsulation based on the target meter ID and the new rate strategy to obtain the transaction data packet; S2: After receiving the transaction data packet, the meter side performs parameter set preset and verification on the transaction data packet to obtain the preset state; S3: The meter side will report the received transaction ID and preset status as a preset receipt to the master station side; S4: On the main station side, if the preset status is ready, record that the meter has been successfully preset and is waiting for the effective timestamp to arrive; If the preset state fails, record the meter preset failure and generate a retransmission instruction; S5: The meter side compares the current system time with the stored effective timestamp to obtain the activation state, and reports the transaction ID and activation state to the master station side; S6: After determining that the activation state is activated, the master station side performs activation state proof with the meter side through a random challenge number to obtain the activation state proof result; wherein, step S6 includes: after determining that the activation state is activated, generating and sending a random challenge number to the meter side; the meter side reads the current effective parameter set and generates an activation state proof based on the current effective parameter set and the random challenge number; the meter side reports the activation state proof to the master station side; the master station side generates an expected proof based on the serialized new parameter set and the random challenge number; the master station side judges whether the expected proof and the activation state proof are consistent. If they are consistent, it is confirmed that the meter is running correctly under the new strategy; if they are inconsistent, it is marked as abnormal.

2. The method for a single-phase prepaid smart energy meter according to claim 1, characterized in that, Step S1 includes: formatting and serializing the new rate strategy to obtain a new serialized parameter set; inputting the new serialized parameter set into a cryptographically secure hash function to obtain an integrity hash; and encapsulating the transaction ID, integrity hash, effective timestamp, and serialized parameter set into a transaction data packet to obtain a transaction data packet.

3. The method for a single-phase prepaid smart energy meter according to claim 2, characterized in that, Step S2 includes: parsing the transaction data packet and extracting metadata to obtain the received transaction ID, the received effective timestamp, the received parameter set, and the received integrity hash; performing parameter set preset writing and readback verification on the received parameter set to obtain the written parameter set and the write status; in response to a successful write status, inputting the written parameter set into the built-in SHA-256 algorithm module to obtain the calculated hash; and performing integrity comparison and status decision on the calculated hash and the received integrity hash to obtain the preset status.

4. The method for a single-phase prepaid smart energy meter according to claim 3, characterized in that, In response to a successful write status, the written parameter set is input into the built-in SHA-256 algorithm module to obtain the calculated hash. This includes: the built-in SHA-256 algorithm module processes the written parameter set using the following formula to obtain the calculated hash: ,in, For the parameter set that has already been written, It uses the SHA-256 algorithm. To calculate the hash.

5. The method for a single-phase prepaid smart energy meter according to claim 1, characterized in that, Step S5 includes: in response to the current system time being greater than or equal to the stored effective timestamp, setting the value of the activation state to activated.

6. The method for a single-phase prepaid smart energy meter according to claim 1, characterized in that, The meter reads the currently effective parameter set and generates an activation status certificate based on the current effective parameter set and the random challenge number, including: generating the activation status certificate based on the current effective parameter set and the random challenge number using the following formula, where the formula is: ,in, The number of challenges is random. For the currently effective parameter set, For splicing operations, For hash calculation function, This serves as proof of activation.

7. A single-phase prepaid smart energy meter system, characterized in that, include: The system comprises a master station side and a meter side; the master station side includes: a transaction data packet acquisition module, used to initialize transactions and encapsulate parameter sets based on the target meter ID and a new rate strategy to obtain transaction data packets; a preset status judgment module, used to record that the meter has been successfully preset and wait for the effective timestamp if the preset status is ready; if the preset status is failed, it records that the meter preset has failed and generates a retransmission instruction; an activation status proof module, used by the master station side to prove the activation status with the meter side through a random challenge number after determining that the activation status is activated, to obtain the activation status proof result; the meter side includes: a transaction data packet verification module, used to preset and verify the parameter set of the transaction data packet after receiving it to obtain the preset status; and a transaction ID preset status reporting module. The module is used to report the received transaction ID and preset status as a preset receipt to the master station. The activation status generation module is used to compare the current system time with the stored effective timestamp to obtain the activation status, and report the transaction ID and activation status to the master station. The activation status generation module includes: after determining that the activation status is activated, generating and issuing a random challenge number to the meter side; the meter side reads the current effective parameter set and generates an activation status proof based on the current effective parameter set and the random challenge number; the meter side reports the activation status proof to the master station; the master station generates an expected proof based on the serialized new parameter set and the random challenge number; the master station judges whether the expected proof and the activation status proof are consistent. If they are consistent, it confirms that the meter is operating correctly under the new strategy; if they are inconsistent, it marks an anomaly.

Images