A dynamic pricing and user management system for an electricity retail market

Abstract

The application discloses a kind of electric power retail market dynamic pricing and user management system, it is related to intelligent electric power system technical field, including: data acquisition module, real-time acquisition includes grid line load, node voltage, frequency deviation multivariate state data, and multivariate state data is gathered into grid state vector;Instruction generation module, if at least one index in state vector is judged to exceed preset safety threshold, automatically trigger to generate original electricity price control instruction containing control target, effective time, price floating coefficient;The electric power retail market dynamic pricing and user management system, realize grid state real-time monitoring, instruction standardization transmission and transparent settlement, improve grid operation efficiency and user trust.

Description

Technical Field

[0001] This invention relates to the field of smart power system technology, specifically to a dynamic pricing and user management system for the electricity retail market. Background Technology

[0002] In the grand blueprint of building a new power system, the intelligent transformation of the electricity retail market is the cornerstone for achieving efficient energy allocation and a virtuous cycle of supply and demand. Currently, although the various systems in the electricity retail sector are closely interconnected in terms of business processes—for example, electricity price adjustments need to be based on the grid status, and user payments rely on the electricity consumption data of smart meters—their technical implementation generally adopts isolated and customized docking methods, lacking a unified interaction framework.

[0003] This fragmentation in technological implementation directly leads to the "drift" of data semantics and the "misalignment" of interaction timing between systems. The core challenge lies in the inherent heterogeneity of data structures and communication protocols between different systems. This is not only a difference in format but also a gap in understanding business logic. For example, when the power grid dispatching system issues an emergency high-price instruction due to excessive line load, the dynamic pricing system needs to respond immediately. However, due to the non-standardization of interface protocols, this instruction may experience delays or parsing errors when transmitted to smart meters for metering rule switching. This directly results in a "timestamp" level discrepancy between the user's actual electricity consumption behavior and the billing strategy. That is, the user's electricity consumption at a certain time period cannot be accurately attributed to the corresponding electricity price range by the third-party payment platform, thus triggering billing disputes and a crisis of user trust. Summary of the Invention

[0004] The purpose of this invention is to provide a dynamic pricing and user management system for the electricity retail market, design a unified set of interaction contracts and data specifications, eliminate semantic gaps and timing conflicts caused by system heterogeneity, and ensure that instructions and data flows from grid status perception to accurate billing on the user side can be transmitted seamlessly and reliably.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a dynamic pricing and user management system for the electricity retail market, comprising a data acquisition module that collects multi-dimensional state data, including grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network, and aggregates the multi-dimensional state data into a structured grid state vector; an instruction generation module that analyzes the structured grid state vector according to a pre-established grid safety operation rule library, and automatically triggers the generation of an original electricity price control instruction, including a control target, effective time, and price fluctuation coefficient, if at least one indicator in the state vector exceeds a preset safety threshold; a terminology standardization module that uses a semantic mapping algorithm based on domain ontology to match non-standardized business terms in the original electricity price control instruction with standard data elements in a predefined unified interaction contract, and converts them into a standardized electricity price instruction that follows a unified data specification; a timestamp and encapsulation module that calls a trusted timestamp service to attach a timestamp to the standardized electricity price instruction and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event; and an event broadcasting module that broadcasts the encrypted trusted control event to the dynamic pricing system and smart metering terminal management platform in the electricity retail market. The system connects to a third-party payment gateway, decrypts trusted control events, verifies their integrity and timeliness, and obtains standardized electricity price instructions to be executed. The instruction issuance module, based on the parsed standardized electricity price instructions, sends metering rule update commands to smart meters within a specified range. The smart meters switch their billing rates at the effective time of the instruction and generate a local execution log record including rates before and after the switch, and the execution timestamp. The electricity data acquisition module, upon the arrival of the settlement cycle, batch-retrieves the stored user electricity data sequences, including electricity consumption and timestamps, from the smart meters. The metering terminal management platform retrieves all relevant local execution log records within the settlement period; the data matching module uses a time series alignment algorithm to associate and match the user's electricity consumption data sequence with the local execution log record set, attributing each electricity consumption data point to the billing rule interval corresponding to the time of electricity consumption, thus obtaining a segmented billing data set; the bill generation module, based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption within each billing interval, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to a third-party payment platform for final settlement.

[0006] Preferably, the data acquisition module collects multi-dimensional state data, including power grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network, and aggregates the multi-dimensional state data into a structured power grid state vector. This includes acquiring real-time data on line load, node voltage, and frequency deviation through a distributed sensor network to obtain a multi-dimensional state dataset; cleaning and standardizing the multi-dimensional state dataset using data stream processing to obtain structured state data; if any attribute in the structured state data exceeds a preset threshold, extracting abnormal data fragments using a sliding window algorithm to obtain an abnormal state vector; classifying the abnormal data using a K-means clustering algorithm based on the abnormal state vector to determine an abnormal type set; performing feature matching on the abnormal type set using a pre-established power grid state mapping model to obtain a power grid state assessment result; predicting the trend of the power grid state assessment result using time series analysis to obtain a state change trend; and optimizing the state vector using an adaptive filtering algorithm based on the state change trend to obtain an optimized power grid state description.

[0007] Preferably, the instruction generation module analyzes the structured power grid state vector based on a pre-established power grid safety operation rule base. If at least one indicator in the state vector exceeds a preset safety threshold, it automatically triggers the generation of an original electricity price control instruction including a control target, effective time, and price fluctuation coefficient. This includes: if at least one power grid indicator in the structured vector exceeds the safety threshold, obtaining the set of indicators exceeding the threshold through threshold judgment to determine the abnormal indicator set; based on the abnormal indicator set, performing rule matching using a pre-established operation rule base to obtain a matched rule subset; generating an electricity price control instruction including a control target, effective time, and price coefficient using the matched rule subset to obtain the original control instruction; dynamically adjusting the price coefficient in the original control instruction using time series analysis to obtain an optimized control instruction; transmitting the instruction to the power grid dispatch system through instruction distribution to obtain instruction execution confirmation; if the instruction execution confirmation is not received within a preset time, obtaining the reason for non-execution through log analysis and generating an adjusted control instruction; and redistributing the instruction to the dispatch system using encrypted transmission based on the adjusted control instruction to obtain the final execution status.

[0008] Preferably, the terminology standardization module employs a semantic mapping algorithm based on domain ontology to match non-standardized business terms in the original electricity price control instruction with standard data elements in a predefined unified interaction contract, thereby generating a standardized electricity price instruction that conforms to unified data specifications. This includes extracting non-standardized terms from the original control instruction through semantic parsing to obtain a terminology set; using the terminology set, searching for matching items in a business terminology library using a semantic mapping algorithm to determine the corresponding standard data elements; if at least one non-standardized term successfully matches a standard data element, generating a mapping relationship from terms to data elements through terminology matching rules to obtain a data element mapping table; using the data element mapping table, replacing the non-standardized terms in the original control instruction with standard data elements through an instruction conversion process to generate a standardized electricity price instruction; performing format verification on the standardized electricity price instruction through data specification standards to determine whether it conforms to the requirements of the unified interaction contract, obtaining a verification result; if the verification result shows that the format does not meet the requirements, readjusting the mapping relationship through semantic parsing to obtain an updated data element mapping table; and re-executing the instruction conversion process based on the updated data element mapping table to generate the final standardized electricity price instruction.

[0009] Preferably, the timestamp and encapsulation module calls a trusted timestamp service to attach a timestamp to the standardized electricity price instruction, and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event. This includes parsing key fields from the standardized electricity price instruction through data extraction to obtain a field set; generating a unique identifier using a hash algorithm based on the field set to obtain an event identifier; obtaining millisecond-level timestamps through the trusted timestamp service to obtain timestamp data; if the timestamp data matches the format of the field set of the standardized electricity price instruction, then using the AES encryption algorithm to encapsulate the field set, timestamp data, and event identifier to obtain an encrypted control event; verifying the integrity of the encrypted control event through verification to determine whether it conforms to the trusted event specification and obtaining a verification result; if the verification result shows a format mismatch, then re-parsing the key fields through data extraction to obtain an updated field set; re-executing the hash algorithm to generate a new event identifier based on the updated field set; and encapsulating the field set, timestamp data, and new event identifier using the AES encryption algorithm to obtain the final encrypted trusted control event.

[0010] Preferably, the event broadcasting module broadcasts the encrypted and trusted control event to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market. Then, it decrypts the trusted control event and verifies its integrity and timeliness to obtain the standardized electricity price instruction to be executed. This includes transmitting the encrypted control event to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway via a broadcast distribution mechanism to obtain a distribution confirmation signal. If the distribution confirmation signal meets the preset configuration, the dynamic pricing system uses a decryption algorithm to parse the encrypted control event, extract the event content, and obtain preliminary instruction data. The preliminary instruction data is then verified through integrity verification. If the verification result... If the data matches the preset configuration, it is confirmed that the instruction data has not been tampered with, thus obtaining reliable instruction data. A timeliness verification method is used to compare the timestamp of the reliable instruction data. If the timestamp is within a preset time range, the instruction data is deemed timeliness qualified, and an instruction to be executed is obtained. Based on the instruction to be executed, the dynamic pricing system generates a standardized electricity price instruction and transmits it to the smart metering terminal management platform, obtaining instruction reception confirmation. Through a third-party payment gateway, the standardized electricity price instruction is verified using a preset configuration. If the verification result conforms to preset rules, transaction confirmation data is generated. Based on the transaction confirmation data, the smart metering terminal management platform updates the electricity price execution status, obtaining the final execution record.

[0011] Preferably, in the instruction issuing module, the smart metering terminal management platform issues a metering rule update command to smart meters within a specified range based on the parsed standardized electricity price instruction content. The smart meters switch their billing rates at the instruction's effective time and generate a local execution log record including the rates before and after the switch and the execution timestamp. This includes the smart metering terminal management platform parsing the standardized electricity price instruction, extracting electricity price data and time constraints, and generating first metering rule data. If the time constraint of the first metering rule data conforms to a preset time range, the first metering rule data is converted into an update command through rule generation to obtain a first update command. The first update command is transmitted to the specified smart meters through command issuing, and the command reception returned by the smart meters is obtained. The system confirms the completion of command transmission by sending a confirmation signal. The smart meter receives the first update command and, within the effective time, switches the current billing rate to the target billing rate in the first update command via rate switching, generating a first rate switching record. Based on the first rate switching record, local log data containing the billing rates before and after the switch, as well as the execution timestamp, is generated and stored in the smart meter's local log library, resulting in a first log record. Log verification compares the timestamp of the first log record with the time constraint of the first update command. If the comparison results match, the first log record is deemed valid, and log verification data is generated. Based on the log verification data, the smart meter's electricity price execution status is updated to "executed" via status update, generating a final status record.

[0012] Preferably, when the settlement period arrives, the electricity data acquisition module batch-acquires the stored user electricity data sequence, including electricity consumption and timestamps, from the smart meter. Simultaneously, it retrieves all relevant local execution log records within the settlement period from the smart metering terminal management platform. This includes both the batch-acquired user electricity data set and the log data set from the smart meter. Data verification compares the timestamps in the user electricity data set with the execution timestamps in the log data set to obtain a timestamp matching result. If the timestamp matching result matches, data integration associates the user electricity data set and the log data set by timestamp to generate an integrated dataset. The process involves: 1) categorizing and statistically analyzing electricity consumption data within the integrated data set to generate electricity consumption statistics; 2) calculating the periodic cost for each user based on the electricity consumption statistics and the billing rates in the log data set; 3) identifying abnormal cost records by anomaly detection to generate an abnormal data set; 4) storing the cost calculation results and the abnormal data set in the management platform's settlement database to generate settlement data records; and 5) generating user settlement notification data based on the settlement data records, transmitting it to the user's terminal, and receiving notification transmission confirmation.

[0013] Preferably, the data matching module employs a time series alignment algorithm to correlate and match the user's electricity consumption data sequence with the local execution log record set, attributing each electricity consumption data point to the billing rule interval corresponding to the time of electricity consumption, thus obtaining a segmented billing data set. This includes processing the user's electricity consumption data sequence and the local execution log record set using the time series alignment algorithm to generate the segmented billing data set; using the segmented billing data set, combined with a preset billing rule interval, determining the billing rule affiliation for each electricity consumption data point, thus obtaining a rule affiliation data set; if the billing rule in the rule affiliation data set is consistent with the billing parameters in the execution log, then through data... Based on the verification and comparison timestamps, data consistency is determined, resulting in a verified data set. Using this verified data set, the cost for each electricity consumption data point is calculated according to the billing rule intervals, resulting in a cost calculation data set. Anomaly detection compares the cost values ​​in the cost calculation data set with preset thresholds; if a cost value exceeds the threshold, an anomaly record is marked, resulting in an anomaly-marked data set. The cost calculation data set and the anomaly-marked data set are stored in the settlement database using a data storage method, generating settlement data records. Based on the settlement data records, a notification generation module generates user cost notification data, transmits it to the user terminal, and generates notification transmission confirmation data.

[0014] Preferably, the bill generation module, based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption within each billing interval, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to a third-party payment platform for final settlement. This includes obtaining the electricity consumption and corresponding electricity price for each billing interval from the segmented billing data set, calculating the cost for each interval using multiplication, obtaining an interval cost data set; generating a traceability record containing electricity consumption, electricity price, and cost calculation formula for each billing interval based on the interval cost data set, obtaining a billing traceability path set; and encrypting the records in the billing traceability path set using a hash algorithm to generate a unique identifier, which is then appended to each traceability record to obtain a verifiable electronic bill. If the unique identifier in the verifiable electronic bill matches the preset format standard, the data verification module compares the cost value in the bill with the range cost data set to determine data consistency and obtain a set of verified bills. Based on the set of verified bills, the verifiable electronic bill is transmitted to a third-party payment platform via data transmission, and the platform returns a receipt confirmation data set, resulting in a bill transmission data set. Based on the bill transmission data set, anomaly detection compares the status code in the receipt confirmation data with a preset threshold. If the status code exceeds the threshold, it is marked as a transmission anomaly record, resulting in an anomaly-marked data set. Based on the anomaly-marked data set, the verifiable electronic bill and the anomaly-marked data set are stored in the settlement database via data storage, resulting in the final settlement data set.

[0015] As can be seen from the above technical solution, the present invention has the following beneficial effects:

[0016] This dynamic pricing and user management system for the electricity retail market collects multi-dimensional power grid state data in real time through a distributed sensor network and generates structured state vectors. Combined with a pre-set security rule base, it analyzes the data to trigger standardized electricity price control commands, solving the problems of low operational efficiency and lack of trust in traditional power grids caused by data dispersion, non-standardized control commands, and insufficient settlement transparency. This invention uses a semantic mapping algorithm to convert raw commands into standardized commands with unified data specifications, adds a trusted timestamp, generates encrypted and trusted control events, and broadcasts them to the dynamic pricing system and smart meters, ensuring the integrity and timeliness of the commands. Smart meters update billing rules according to the commands and record execution logs. A time series alignment algorithm accurately matches user electricity consumption data with billing rules, generating verifiable electronic bills with traceable paths. This invention achieves real-time monitoring of power grid status, standardized command transmission, and transparent settlement, improving power grid operational efficiency and user trust. Attached Figure Description

[0017] Figure 1 This is a system connection diagram of the present invention. Detailed Implementation

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

[0019] like Figure 1 As shown, this invention provides a technical solution: a dynamic pricing and user management system for the electricity retail market, including a data acquisition module that collects multi-dimensional state data, including grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network, and aggregates the multi-dimensional state data into a structured grid state vector; an instruction generation module that analyzes the structured grid state vector according to a pre-established grid safety operation rule library, and automatically triggers the generation of an original electricity price control instruction, including a control target, effective time, and price fluctuation coefficient, if at least one indicator in the state vector exceeds a preset safety threshold; a terminology standardization module that uses a semantic mapping algorithm based on domain ontology to match non-standardized business terms in the original electricity price control instruction with standard data elements in a predefined unified interaction contract, and converts them into a standardized electricity price instruction that follows a unified data specification; a timestamp and encapsulation module that calls a trusted timestamp service to attach a timestamp to the standardized electricity price instruction and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event; and an event broadcast module. The module broadcasts encrypted and trusted control events to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market. It then decrypts the trusted control events and verifies their integrity and timeliness to obtain standardized electricity price instructions to be executed. The instruction issuance module, based on the parsed standardized electricity price instructions, sends metering rule update commands to smart meters within a specified range. The smart meters switch their billing rates at the effective time of the instruction and generate a local execution log record including the rates before and after the switch, and the execution timestamp. The electricity data acquisition module, upon the arrival of the settlement period, batch-retrieves user electricity consumption data sequences, including electricity consumption and timestamps, from the smart meters. Simultaneously, it retrieves all relevant local execution log records within the settlement period from the smart metering terminal management platform. The data matching module uses a time series alignment algorithm to correlate and match user electricity consumption data sequences with the local execution log record set, attributing each electricity data point to the corresponding billing rule interval at the time of electricity consumption, resulting in a segmented billing data set.

[0020] The billing generation module calculates and generates a verifiable electronic bill with detailed billing traceability based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption in each billing interval, and transmits the electronic bill to a third-party payment platform for final settlement.

[0021] This implementation method achieves automation, transparency, and verifiability in electricity price control by constructing an integrated dynamic pricing and user management system. The system first collects multi-dimensional state data of the power grid operation in real time through a distributed sensor network, forming a structured state vector. Based on a power grid safety operation rule base, the system continuously analyzes key indicators of the state vector. If an anomaly is detected, it immediately generates an original electricity price control instruction containing control targets and floating parameters. This instruction is converted into a standard data format through a terminology standardization module and encapsulated into a reliable control event with timestamp service assurance before being broadcast to relevant systems. Upon receiving the instruction, the dynamic pricing system and terminal platform parse and execute it, and smart meters switch rates as required and record operation logs. During settlement, a time series alignment algorithm is used to accurately match electricity consumption data with logs, achieving high-precision attribution of electricity prices and consumption, ultimately generating a detailed and auditable electronic bill that supports payment and regulatory verification.

[0022] This system enables closed-loop management of the entire process, from power grid operation monitoring to electricity price regulation and user billing, and offers the following advantages: First, it improves the efficiency of power system regulation and response, ensuring safe operation; second, it standardizes terminology through semantic mapping, enhancing system interoperability; third, it ensures the credibility and traceability of command execution through timestamps and encryption mechanisms; furthermore, it combines time alignment algorithms for high-precision segmented billing, improving billing accuracy and user trust; finally, it generates verifiable electronic bills, helping users clearly understand the source of their billing and facilitating settlement and supervision by third-party platforms, thus enhancing market transparency.

[0023] The data acquisition module collects multi-dimensional state data, including power grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network. This multi-dimensional state data is then aggregated into a structured power grid state vector. The process includes: acquiring real-time data on line load, node voltage, and frequency deviation through the distributed sensor network to obtain a multi-dimensional state dataset; cleaning and standardizing the dataset using data stream processing to obtain structured state data; extracting abnormal data fragments using a sliding window algorithm if any attribute in the structured state data exceeds a preset threshold to obtain an abnormal state vector; classifying the abnormal data using a K-means clustering algorithm based on the abnormal state vector to determine an anomaly type set; performing feature matching on the anomaly type set using a pre-established power grid state mapping model to obtain a power grid state assessment result; predicting the trend of the power grid state assessment result using time series analysis to obtain the state change trend; and optimizing the state vector using an adaptive filtering algorithm based on the state change trend to obtain an optimized power grid state description.

[0024] The data acquisition module deploys fixed acquisition terminals at substation outgoing busbars, main grid line intersections, and high-voltage transmission line terminal nodes in the power system. Each terminal embeds current transformers, voltage transformers, and frequency detection circuits. Each terminal acquires raw values ​​of current, voltage, and frequency once per second. The current value is used to calculate the line load by multiplying the real-time current value by the line's rated voltage to obtain the current active power value, which is then used as the line load value. The voltage value is directly used as the node voltage value. The frequency value is set by the system to count zero-crossing voltage events per second, ideally 50 times. If the actual detection count is 49 times, the deviation is -1 Hz, and so on. These three parameters form a set of three-dimensional data at each time point, continuously recorded to form a multivariate state dataset, collecting a total of 60 sets of data per minute.

[0025] The dataset is input into the data stream processing module for cleaning and standardization. Data cleaning is performed in three steps: First, deduplication, which involves comparing the timestamps of two adjacent data sets to see if they are exactly the same; if so, the set that appears first is retained. Second, missing data completion, where linear interpolation is used to fill in missing values ​​in a single data set, averaging the values ​​of the two valid data points before and after the missing value. Third, anomaly removal, where any field in a data set deviates from its average value within 5 seconds by more than twice the standard deviation, and is replaced with a moving average value with a window length of 5 seconds. The moving average is calculated by adding the data for that field within 2 seconds before and 2 seconds after the current time and dividing by 5; the result is used as the current value of that field. The cleaned data is then standardized using range normalization. Taking the line load as an example, let its historical minimum value be 100 kW and its maximum value be 1000 kW. If the current value is 550 kW, then the standardized value is (550 minus 100) divided by (1000 minus 100), and the result is 0.5. The node voltage and frequency deviation values ​​are also standardized to the range of 0 to 1 in the same way.

[0026] Threshold judgments are performed on structured data. The line load threshold is 90% of the line's design capacity; for example, if the design capacity is 1000 kW, the threshold is 900 kW. The node voltage upper and lower limit thresholds are 90% and 110% of the nominal voltage, respectively; for example, if the nominal voltage is 220 V, the upper limit is 242 V and the lower limit is 198 V. The frequency deviation threshold is fixed at ±0.2 Hz, set according to the national power system safety operation standards. If any field exceeds its corresponding threshold, the system initiates an anomaly detection process. The first step of the anomaly detection process is to extract anomaly data segments using a sliding window. The extraction method is as follows: taking the current time point exceeding the threshold as the center, taking 10 seconds forward and 10 seconds backward, for a total of 20 seconds of data, one set per second, extracting a total of 20 sets of data to form an anomaly data segment.

[0027] A sliding window algorithm is applied to anomalous data segments. The window size is set to 5 seconds, with a step size of 1 second, meaning each window contains 5 sets of data. These windows slide sequentially from the beginning of the segment, forming 16 windows. Within each window, the variances of line load, node voltage, and frequency deviation are calculated. This is done by subtracting the square of the average value from each field's value, summing the results, and then dividing by the number of data points. If the variance of a field exceeds three times its historical average variance in normal data, the window is considered anomalous. All windows meeting the criteria are merged into an anomalous state vector, preserving their chronological order, and marked as an anomalous event instance.

[0028] After collecting multiple instances of anomalous events, the system inputs them into the K-means clustering module for anomaly type classification. The K value is set to 5, and the optimal number of classifications is determined based on the historical anomaly event clustering profile coefficient evaluation results. The initial step involves randomly selecting 5 groups as initial centroids from all anomaly state vectors; then, for each remaining anomaly state vector, the Euclidean distance to the 5 centroids is calculated, defining each sample as belonging to the category represented by its nearest centroid; subsequently, the average vector of all samples in each category is calculated as the new centroid; this process is repeated until the change in centroids for each category is less than a preset threshold, set to 0.001, indicating that the change in each dimension of the vector should not exceed 0.001. After clustering, the system obtains a set of 5 anomaly types.

[0029] Each anomaly type is input into the power grid state mapping model for feature matching. The model employs a rule-based matching method. Each rule defines several field threshold combinations; for example, a line load higher than 0.9 and an absolute frequency deviation higher than 0.1 constitute a "load surge" state. Representative vectors from the clustering results are compared with all rules one by one to calculate the matching degree. The matching degree is calculated as follows: 1 point is added for each field in the rule that satisfies the condition, and the total score is divided by the number of rule fields to obtain the matching degree. A matching degree of 0.8 or higher is considered a successful match. After comparison, the power grid state name corresponding to each anomaly is obtained, such as "overload operation" or "frequency fluctuation."

[0030] The power grid condition assessment results are input into the time series analysis module for trend prediction. The prediction method is a simple moving average, with a time window of 30 seconds. This involves classifying and statistically analyzing the condition assessment results generated every second within the past 30 seconds, counting the frequency of each condition. If a condition occurs more than 15 times within the window (more than 50% of the total occurrences), it is predicted to continue occurring within the next 30 seconds; if it occurs less than 10 times, it is predicted to disappear; and if it occurs between 10 and 15 times, it is predicted to be a fluctuating condition.

[0031] Finally, the system optimizes the power grid state vector based on the prediction results. The optimization algorithm employs adaptive filtering. The calculation process is as follows: if the difference between any field value in the current vector and the previous value of the same field does not exceed 0.05, the current value is directly retained as the optimized value; if the difference exceeds 0.05, a weighted average method is used, where the current value has a weight of 0.3 and the previous value has a weight of 0.7, and the sum of the two is the optimized field value. After all fields are processed in this way, the final optimized state vector is formed, serving as a stable description of the power grid state, and is provided to the next stage for dynamic electricity price control decisions.

[0032] The instruction generation module analyzes the structured power grid state vector based on a pre-established power grid safety operation rule base. If at least one indicator in the state vector exceeds a preset safety threshold, it automatically triggers the generation of an original electricity price control instruction, including the control target, effective time, and price fluctuation coefficient. If at least one power grid indicator in the structured vector exceeds the safety threshold, the module uses threshold judgment to obtain the set of indicators exceeding the threshold, identifying an abnormal indicator set. Based on the abnormal indicator set, it performs rule matching using a pre-established operation rule base to obtain a matched rule subset. Using the matched rule subset, it generates an electricity price control instruction containing the control target, effective time, and price coefficient, obtaining the original control instruction. Using time series analysis, it dynamically adjusts the price coefficient in the original control instruction to obtain an optimized control instruction. Based on the optimized control instruction, it distributes the instruction to the power grid dispatch system to obtain instruction execution confirmation. If the instruction execution confirmation is not received within a preset time, it uses log analysis to obtain the reason for non-execution and generates an adjusted control instruction. Based on the adjusted control instruction, it uses encrypted transmission to redistribute the instruction to the dispatch system, obtaining the final execution status.

[0033] The instruction generation module monitors the latest power grid state vector received from the power grid state vector processing module in real time during system operation. This state vector is a standardized three-dimensional numerical vector containing the current operating values ​​of three indicators: line load, node voltage, and frequency deviation. Each indicator ranges from 0 to 1, representing its relative position within the historical operating range. The module first judges the state vector based on a pre-set safety threshold. The safety threshold for line load is set to 90% of the line's design capacity. For example, for a line with a design capacity of 1000 kW, the corresponding safety threshold is 900 kW. During standardization, this threshold is calculated based on the range between the historical minimum and maximum values ​​of the line load indicator. If the historical minimum is 100 kW and the maximum is 1000 kW, then the standardized value of 900 kW is 900 minus 100, then divided by 900, which is 0.888. The safe range for node voltage is set between 90% and 110% of the nominal voltage. For example, if the nominal value is 220 volts, the lower limit is 198 volts and the upper limit is 242 volts. The standardization process uses the same method. The frequency deviation threshold is an absolute value not exceeding 0.2 Hz. During the standardization process, the frequency variation range is set from -1 Hz to +1 Hz. This range is mapped to 0 to 1, so 0 Hz is mapped to 0.5, +0.2 Hz to 0.6, and -0.2 Hz to 0.4. Through the above conversion, all thresholds are uniformly expressed as standardized values.

[0034] When the system detects that one or more items in the current state vector exceed the corresponding safety threshold, the module immediately records the name of the exceeding indicator and its standardized value, forming an abnormal indicator set. This abnormal indicator set serves as input to a predefined rule base for rule matching. The rule base is a structured data collection; each rule contains one or more condition combinations. Each condition is "indicator name, logical relationship, and threshold," such as "line load greater than 0.88, frequency deviation greater than 0.6," and is bound to a set of output parameters, including the control target, effective time, and electricity price fluctuation coefficient. The module sequentially reads each rule in the rule base and matches its conditions one by one with the data in the abnormal indicator set. The matching method is: for each indicator, if the standardized value of the abnormal indicator is greater than the threshold in the rule, the condition is considered satisfied. Only when all conditions in a rule are satisfied is the rule considered a successful match, and the system adds it to the matching rule subset.

[0035] Once the subset of matching rules is determined, the system selects one rule according to priority to generate the original control instruction. This original control instruction includes three parts: the control target, the effective time, and the electricity price fluctuation coefficient. The control target is the percentage of power restriction, typically set at 10%, 20%, and 30%. The effective time is the point in time after a fixed delay from the current system time. The delay time is determined according to the control level; for example, a 5-minute delay for a 10% target, a 10-minute delay for 20%, and a 15-minute delay for 30%. The electricity price fluctuation coefficient is the current benchmark electricity price multiplied by a coefficient, typically set to 1.05, 1.10, or 1.20, corresponding to control levels from light to heavy.

[0036] After the instruction is generated, the price fluctuation coefficient optimization process begins. This process is based on time-series statistics of historical response records over the past 30 days. Each record includes three data points: control conditions, electricity price coefficient, and user response rate. The user response rate is defined as the reduction in total load of all target users within one hour after the control is implemented, divided by the control target load value. For example, if the control target load is 100 kW and the actual reduction is 80 kW, the response rate is 80%. The module filters all control records consistent with the current abnormal indicator set from the historical data, summarizes their response rates, and calculates the average. If the average response rate is less than 60%, it indicates insufficient electricity price incentives under the same conditions in the past, and the module increases the current fluctuation coefficient by 0.05; if the response rate is greater than 85%, it indicates excessive incentives, and the module decreases the coefficient by 0.05; if it is between 60% and 85%, it remains unchanged. After adjustment, the electricity price fluctuation coefficient replaces the original value in the original instruction, forming an optimized control instruction.

[0037] The optimized control commands are sent to the power grid dispatch system via a communication interface based on a structured message protocol, including fields such as command ID, timestamp, control target, electricity price coefficient, and effective time. The system records the command sending time and is set to receive a confirmation response from the dispatch system within 10 seconds. If no confirmation is received within the specified time, the module initiates a log analysis process. Log analysis first retrieves log files from the dispatch system interface module for the most recent 3 minutes, generating one log file per second, for a maximum of 180 log files. Each log record includes fields for command ID, return code, response time, and error information. The module parses each log file sequentially by time. If a record matching the current command ID is found, its return code is extracted. If the return code indicates a communication timeout, the failure reason is recorded as a network fault; if it indicates authentication failure, it is recorded as a key error; if it indicates a parameter error, it indicates an incorrect command format. Based on different error types, the module generates adjusted control commands. For example, if it is a network fault, the effective time is extended by 5 minutes; if it is an authentication failure, the key is regenerated and the communication token is replaced; if it is a parameter error, the command format is reconstructed and the field integrity is verified.

[0038] After the adjusted instructions are completed, the system enters the encryption phase. Encryption uses a symmetric key algorithm. The key is automatically generated daily by the system, is 256 bits long, and is stored in the security key management module. The module uses the current key to encrypt the instruction fields sequentially, forming a ciphertext structure. After encryption, the instructions are retransmitted to the power grid dispatch system via a backup communication link. This backup link is physically isolated from the main communication link, supporting redundant forwarding in case of network failure. The system restarts a 10-second confirmation timer. If a successful response is received, the final status is recorded as "executed." Otherwise, the system generates an exception report containing a failure log, fault type, number of retries, and final status, and stores it in the instruction audit log table.

[0039] The term standardization module adopts a semantic mapping algorithm based on domain ontology to match the non-standard business terms in the original electricity price regulation instruction with the standard data elements in the predefined unified interaction contract, and converts and generates a standardized electricity price instruction that follows the unified data specification. This includes extracting non-standard terms from the original regulation instruction through semantic parsing to obtain a term set; according to the term set, using the semantic mapping algorithm to search for matching items in the business term library to determine the corresponding standard data elements; if at least one non-standard term matches successfully with the standard data element, then through the term matching rule, generating a mapping relationship from the term to the data element to obtain a data element mapping table; according to the data element mapping table, using the instruction conversion process to replace the non-standard terms in the original regulation instruction with the standard data elements to generate a standardized electricity price instruction; through the data specification standard, performing a format check on the standardized electricity price instruction to determine whether it meets the requirements of the unified interaction contract to obtain a verification result; if the verification result shows that the format does not meet the requirements, then readjust the mapping relationship through semantic parsing to obtain an updated data element mapping table; according to the updated data element mapping table, re-execute the instruction conversion process to generate the final standardized electricity price instruction.

[0040] After receiving the original electricity price regulation instruction, the term standardization module first performs a term extraction operation. The original regulation instruction usually consists of several fields, each field including a field name and a field value, and the field name may use non-standard expressions, such as "activation time", "activation rate", "peak segment price", etc. The module sequentially reads each group of fields from the entire instruction and uses the field name text as the input to execute the semantic parsing process. This process includes three steps. The first step is rule-based word segmentation processing, which divides the Chinese character string into single words according to the existing dictionary. For example, "activation rate" is divided into three parts: "activation", "rate". The second step is keyword identification, which compares the word segmentation result with the local non-standard term vocabulary to identify the phrases that match the existing non-standard terms. The third step is term identification. If the matching rate of a certain field name with the entries in the non-standard term dictionary exceeds 0.7, it is considered a non-standard term. The matching rate is calculated as the length of the longest common subsequence of the original term and the dictionary entry divided by the total length of the entry. For example, if the original term is "activation fee" and there is "activation rate" in the dictionary, the longest common subsequence is "activation fee" with a length of 2, and the total length of the entry is 4, so the matching rate is 0.5, which is lower than 0.7, so it is not determined to be a match; while the matching rate of "activation rate" and "activation rate" is 0.75, so it is considered a successful match.

[0041] All identified non-standard terms are grouped into a term set, which serves as input for the next semantic mapping step. The mapping process first compares each term in the term set with each standard term in the standard metadata library. The similarity is calculated using the edit distance algorithm. Edit distance is the minimum number of single-character operations required to convert one string to another. Let the original term be "activation time," the standard term be "effective time," and the edit distance be 3. The standard term length is 4, and the similarity is calculated as 1 minus 3 divided by 4, resulting in 0.25. The system sets a similarity threshold of 0.8, derived from empirical statistical analysis to ensure that the misidentification rate in the training corpus does not exceed 5%. Only when the similarity is greater than or equal to 0.8 is the standard term considered a candidate mapping item for the current non-standard term. If multiple candidates exist, the system selects the one with the highest similarity. All established term mapping relationships form a metadata mapping table, with each record including the original term, the target standard term, the similarity value, and conversion instructions. This table serves as the key basis for instruction conversion.

[0042] After the mapping table is constructed, the module enters the instruction conversion stage. This stage processes the original control instructions in field order. For each field identified as a non-standard term, the system consults the mapping table to find the corresponding standard data element name and replaces the original field name with the standard field name. The replacement process includes field name replacement, field value format conversion, and unit normalization. Field value format conversion refers to standardizing the expression, such as converting "twenty percent" to "0.2"; unit normalization means, for example, standardizing "5 minutes" to "300 seconds," which is derived by multiplying 5 by 60. After all fields are replaced, a preliminary standardized electricity price instruction is generated.

[0043] Subsequently, the module inputs the standardized electricity price instruction into the format verification module. The format verification performs four checks in the following order: First, field name validity check: the current field name is compared one by one with the field list of the unified interaction contract; if a field is not found in the list, it is deemed invalid. Second, field value type check: each field has specific data type requirements; for example, the price coefficient field is a floating-point number, and the time field is a timestamp integer. The system parses the field values ​​sequentially and verifies whether their data types match. Third, field completeness check: the unified interaction contract defines all required fields, such as "control target," "effective time," and "price coefficient"; the absence of any field results in a failed verification. Fourth, structural consistency check: the overall structure of the instruction is analyzed hierarchically, such as whether it is a correct nested format and whether the field order conforms to the standard structural specifications. Successful verification of all checks indicates successful standardization.

[0044] If unqualified items are found during the verification process, the module immediately records the failure type and enters the re-mapping phase. First, it re-checks the mapping source terms and their mapping relationships according to the field where the failure item is located. If the similarity is lower than 0.85, the system automatically enables the term with the second highest similarity in the candidate list for replacement and regenerates the data element mapping table. If the field value format is incorrect, for example, it should be a floating-point type but the current value is the Chinese description "twenty point zero", the system calls the format normalization module to convert it to "20.0"; if the field is missing, the system fills in the default value according to the rule template. For example, if the price coefficient is not provided, the default setting is 1.00. After all problem items are corrected, the instruction conversion and format verification process is executed again.

[0045] The timestamp and encapsulation module calls the trusted timestamp service to append a timestamp to the standardized electricity price instruction and encapsulate the standardized electricity price instruction and the timestamp into an encrypted trusted control event, including parsing the keyword fields from the standardized electricity price instruction through data extraction to obtain a field set; generating a unique identifier using the hash algorithm based on the field set to obtain an event identifier; obtaining the millisecond-level timestamp through the trusted timestamp service to obtain the timestamp data; if the timestamp data matches the format of the field set of the standardized electricity price instruction, using the AES encryption algorithm to encapsulate the field set, the timestamp data, and the event identifier to obtain the encrypted control event; performing integrity verification on the encrypted control event through verification to determine whether it conforms to the trusted event specification to obtain the verification result; if the verification result shows a format mismatch, re-parsing the keyword fields through data extraction to obtain an updated field set; based on the updated field set, re-executing the hash algorithm to generate a new event identifier, and using the AES encryption algorithm to encapsulate the field set, the timestamp data, and the new event identifier to obtain the final encrypted trusted control event.

[0046] After the timestamp and encapsulation module is started, its first processing step is to extract the keyword fields from the electricity price control instruction that has completed the standardization process as the basic content for generating the event identifier and encryption encapsulation. The standardized electricity price instruction is in a structured data format, usually an ordered JSON structure in the form of key-value pairs. The field extraction rules set by the module clearly state that the keyword fields to be extracted include the control target field, the effective time field, the price floating coefficient field, the instruction number field, the dispatching area field, and the data source identifier field, a total of 6 items. The names of these fields have been standardized in the unified interaction contract. The system traverses all the fields of the JSON structure in turn through the field name matching function and selects the 6 completely consistent fields to form a field set. The field set is stored in a list structure within the system, with the key and value maintaining the key-value pair form, where the key is a string and the value may be an integer, a floating-point number, or a date type. For example, "price_factor" is "1.2" and "start_time" is "1691653200".

[0047] After the field set is generated, the module uses it as input to a hash algorithm to generate a unique event identifier. The hash algorithm used by the system is SHA256, which is characterized by compressing an input string of arbitrary length into 256 bits of binary data according to fixed rules. To ensure input uniqueness and format consistency, the module first concatenates the field set into a continuous string in sequence, with the concatenation format "key_name=key_value", and multiple fields are separated by a vertical bar "|". For example, if the field set contains three fields: "target=load_reduction", "price_factor=1.2", and "start_time=1691653200", the combined string is "target=load_reduction|price_factor=1.2|start_time=1691653200". This string is then input into the SHA256 hash function to calculate the hash value. The hash function returns a string of 64 hexadecimal characters, such as "c54d7f8bc2e4a613...". This string is the event identifier, used for subsequent data indexing and encrypted encapsulation binding. The uniqueness of this identifier is determined by the values ​​of each field in the field set. Any change in any field will result in a change in the hash value, thus ensuring that each event record is globally unique.

[0048] Next, the module sends a time request to the trusted timestamp service. This service is a trusted, authenticated time source service that provides time data accurate to milliseconds. The module constructs a request message containing the current local time, the local device identifier, and the request sequence number, and sends it to the timestamp service via a secure transmission protocol. The server responds with a timestamp value, which is the cumulative number of milliseconds since January 1, 1970, 00:00:00. It is a 13-bit unsigned integer, such as "1754332805123". The module stores this timestamp value as a string, serving as the time authentication information for this control command.

[0049] Subsequently, the module performs a structure matching verification between the timestamp value and the effective time field in the field set. This verification process ensures that the time field format is consistent, preventing encapsulation failure due to format conflicts. The system's standard time format is a Unix timestamp integer, meaning the time field must be an integer value greater than or equal to 10 digits and less than or equal to 13 digits. If the field value is "1691653200", it is a 10-digit second-level timestamp and is considered compliant. If the time field is a non-numeric or non-integer type, such as "August 1, 2025, 08:00", the system will determine it as non-compliant and require conversion to the Unix timestamp format.

[0050] After the time format verification is successful, the module integrates the field set, event identifier, and timestamp data into a unified structure. The three elements in the structure are labeled with fixed keys: "field_set", "event_id", and "timestamp". The key-value pairs of each field are encapsulated in a nested structure using JSON format, ensuring that each item is independently parsable. If the generated structure is not a multiple of 16 bytes, it enters the padding stage. The system uses PKCS7 padding, padded to a multiple of 16 bytes at the end of the structure in 16-byte blocks. The padding value is the number of missing bytes; for example, if 5 bytes are missing, 5 bytes with a value of 5 are added.

[0051] After the structure is constructed, the module performs AES encryption. The encryption algorithm uses the AES-256 standard, with a key length of 256 bits and CBC symmetric encryption mode. The initialization vector is generated daily by the system, and the key is automatically generated by the security module at 00:00 each day and stored in encrypted form in the key storage module. It can only be decrypted and accessed after authorized authentication. The encryption operation takes the padded structure as plaintext input and returns an encrypted data block after encryption. The ciphertext length is an integer multiple of the plaintext length. For example, if the plaintext structure length is 128 bytes, the encrypted ciphertext will also be 128 bytes.

[0052] After encryption, the module performs integrity verification on the encrypted result. Integrity verification consists of two steps: the first step is to decrypt the ciphertext, calling the same AES decryption function as the encryption, and using the same key and initialization vector to restore the ciphertext; the second step is to compare the decryption result with the original plaintext structure. The comparison fields include each key and value of the field set, the content of the event identifier, the timestamp value, and the structural order of the three. If any field is missing, the value is inconsistent, or the order is scrambled, the system will record the current event as "verification failed" and proceed to the regeneration process.

[0053] In the regeneration process, the module re-extracts the field set from the standardized instructions, repeats the hash calculation to generate a new event identifier, retains the original timestamp value, reconstructs the structure, and performs AES encryption and integrity verification. If it fails again, the system generates a failure log, recording detailed information about the failed fields, failure type, and execution environment, for manual intervention by the system administrator. If the retry is successful, the final encrypted trusted control event is output, marked with the status "encapsulation complete," and the event is pushed to the downstream event broadcast module.

[0054] The event broadcast module broadcasts encrypted and trusted control events to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market. It then decrypts the trusted control events and verifies their integrity and timeliness to obtain standardized electricity price instructions to be executed. This includes transmitting the encrypted control events to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway via broadcast using a distribution mechanism, obtaining a distribution confirmation signal. If the distribution confirmation signal conforms to the preset configuration, the dynamic pricing system uses a decryption algorithm to parse the encrypted control events, extract the event content, and obtain preliminary instruction data. The preliminary instruction data is then verified through integrity verification. If the verification result matches the preset... Configuration matching confirms the command data is tamper-proof, resulting in trusted command data. A timeliness verification method compares the timestamps of the trusted command data; if the timestamps are within a preset time range, the command data is deemed time-sensitive and an execution command is obtained. Based on the execution command, the dynamic pricing system generates a standardized electricity price command, transmits it to the smart metering terminal management platform, and receives command reception confirmation. Through a third-party payment gateway, the standardized electricity price command is verified using preset configurations; if the verification result conforms to preset rules, transaction confirmation data is generated. Based on the transaction confirmation data, the smart metering terminal management platform updates the electricity price execution status, obtaining the final execution record.

[0055] After the event broadcast module starts, it first executes the broadcast initialization process. The system reads the target node list defined in the configuration file, which includes three targets: the dynamic pricing system, the smart metering terminal management platform, and the third-party payment gateway. Each node is configured with a unique node identifier, receiving address, communication protocol type, and interface key. The system verifies the correctness of the address format and establishes a connection. After each successful connection, it returns a TCP handshake completion flag. Subsequently, the system concurrently and asynchronously packages the generated encrypted trusted control events as encrypted messages, according to the protocols of each node, and sends them. The packaging format is a JSON structure, with the top-level field being "payload," and the value being the encrypted event data of type string.

[0056] After transmission is complete, the system starts a listening program, waiting for three nodes to return reception confirmation signals. The confirmation signal is a structured response with fields including "status_code", "receive_time", and "node_id". The system is configured to consider successful reception if all nodes return a "status_code" value of 200, where 200 is the industry-standard HTTP success code. If a node returns a value other than 200, such as 400 or 500, an exception is logged and a retransmission mechanism is triggered. The retransmission mechanism executes a maximum of three times, with each retransmission occurring at 5-second intervals. If more than three retransmissions are performed, the broadcast is marked as failed.

[0057] Upon receiving an encrypted message, the dynamic pricing system invokes its local decryption module to perform AES-256 decryption using the currently valid key. The decryption key is generated daily at midnight and stored in the encryption security module; access requires authorization before it can be invoked. The decryption function takes a base64-encoded ciphertext string as input and outputs a plaintext structure containing three fields: "field_set" (the set of fields including the control target, price coefficient, and effective time); "event_id" (a 64-bit hexadecimal string representing the event identifier); and "timestamp" (a 13-bit Unix millisecond timestamp). The system sequentially reads the content of each field using a field matching function and generates preliminary instruction data.

[0058] To ensure the instruction data has not been tampered with, the system performs integrity verification on the initial instruction data. Specifically, all fields are extracted from the "field_set" field, concatenated sequentially into a string in the format "key1=value1|key2=value2|key3=value3", and then input into the SHA256 hash function to calculate the digest value. This digest value is a 64-bit hexadecimal string, which is compared character-by-character with the value of the "event_id" field. The comparison logic is to compare each character sequentially from the first to the last; if any character differs, the verification fails. If all 64 bits match, the data is considered complete and marked as trustworthy instruction data.

[0059] After acquiring trusted instruction data, the system immediately performs timeliness verification. The maximum allowable time error threshold is set at 300,000 milliseconds, or 5 minutes, based on the dynamic adjustment of electricity prices to ensure that control instructions are executed within their validity period. The system obtains the current server timestamp, accurate to milliseconds, by calling the system time function, for example, the current timestamp is 1754333100000. Subtracting the "timestamp" field value from the current timestamp, for example, subtracting 1754332800000, yields a time difference of 300,000 milliseconds. If the difference is less than or equal to 300,000, the timeliness is deemed "qualified"; if it is greater than 300,000, it is deemed "expired," not executed, and written to the system operation log.

[0060] If the instruction data passes the integrity and timeliness verification, the system marks it as "pending execution" and enters the electricity price instruction generation process. The system calls the template filling function to fill the three fields "target", "start_time", and "price_factor" into the predefined format template. For example, filling the fields generates a standard structure of "{'price_type':'TOU','start_time':'1754332800','price_factor':'1.2'}", which conforms to the unified interaction contract requirements. After generation, the encrypted communication module is called to push the standardized electricity price instruction to the smart metering terminal management platform via the HTTPS protocol, and waits for the platform to return a receipt confirmation. The confirmation format is a structured message containing two fields: "code" and "received_at", where a code of 200 is considered a successful reception.

[0061] Simultaneously, the system sends the same standardized electricity price instruction to a third-party payment gateway, which verifies the transaction. Verification consists of three stages. The first stage is field name validity verification. The system compares all field names in the instruction with the payment gateway's preset field list; if any field names do not match, verification fails. The second stage is electricity price factor range verification. The system is configured to allow a price fluctuation factor range of 1.00 to 1.50. The value of the "price_factor" field in the instruction is read and converted to a floating-point number. For example, if the value is 1.20, it falls within the range and is considered valid. The third stage is digital signature comparison verification. The system concatenates the field contents into a string in a specified order, generates a digest, and decrypts the signature field using the platform's public key. If a match is found, verification passes. These three stages generate transaction confirmation data, whose structure includes "confirmation_id", "verified_at", and "result".

[0062] Finally, the smart metering terminal management platform locates the original instruction record based on the received transaction confirmation data, updates its status field to "executed", and records parameters such as "confirmation_id", "execution time", and "float coefficient", merging them to form a complete final electricity price execution record, which is stored in the local database and subsequently called by the electricity billing settlement platform.

[0063] The instruction issuance module, based on the parsed standardized electricity price instruction, sends metering rule update commands to smart meters within a specified range. The smart meters switch their billing rates at the instruction's effective time and generate a local execution log record including rates before and after the switch, and an execution timestamp. The smart metering terminal management platform parses the standardized electricity price instruction, extracts electricity price data and time constraints, and generates first metering rule data. If the time constraint of the first metering rule data conforms to a preset time range, the first metering rule data is converted into an update command through rule generation, resulting in the first update command. The first update command is then transmitted to the designated smart meters via command issuance, and a command reception confirmation is received from the smart meters. The system confirms the completion of command transmission; the smart meter receives the first update command and, within the effective time, switches the current billing rate to the target billing rate in the first update command via rate switching, obtaining the first rate switching record; based on the first rate switching record, local log data containing the billing rates before and after the switch and the execution timestamp is generated and stored in the smart meter's local log library, obtaining the first log record; log verification compares the timestamp of the first log record with the time constraint of the first update command. If the comparison results are consistent, the first log record is determined to be valid, and log verification data is generated; based on the log verification data, the smart meter's electricity price execution status is updated to "executed" via status update, generating the final status record.

[0064] Upon receiving a standardized electricity price instruction, the smart metering terminal management platform immediately initiates the instruction parsing process. This process is completed by a structured instruction parsing program. The program first identifies and extracts key fields from the instruction message. These fields include: "price_type" indicating the electricity price type, such as "time-of-use pricing"; "target_rate" indicating the target billing rate, expressed as a floating-point number, such as 1.20 yuan per kilowatt-hour; "effective_time" indicating the effective time of the rate, expressed as a 13-digit Unix timestamp, such as 1754336400000; and "region_code" indicating the applicable region, encoded as a string, such as "North China Region 1". After parsing, these fields are assembled into a first set of metering rule data, which is in key-value pair format and used for subsequent command generation.

[0065] Subsequently, the system initiates a time constraint judgment process. The purpose of this process is to ensure that the effective time set in the electricity price instruction is reasonable. The system's current time is obtained through an internal time function; for example, the current value is 1754334600000, in milliseconds. Subtracting the current timestamp from the "effective_time" field value yields the time difference, which is 1800000 milliseconds, equal to 30 minutes. The system's time constraint range is 300 seconds to 86400 seconds, meaning the instruction's effective time must be at least 15 minutes earlier than the current time and no more than 24 hours later. Converting 1800000 milliseconds to seconds yields 1800 seconds, falling within this range, and the judgment passes.

[0066] After the time verification is successful, the platform invokes the metering rule conversion module. This module reads the first metering rule data and fills its fields into a standard command template to form the first update command. The template structure includes "meter_id" as the target meter number, "rate_type" as the billing type, "new_rate" as the target rate, "activation_time" as the command's effective time, and "cmd_id" as a unique command number generated by the platform. The platform performs area matching for the meter devices in each target area to obtain a list of device numbers, such as "M10001" and "M10002", with each number corresponding to one meter. The system generates an update command for each number, encapsulates the above structure into JSON format, and sends it to the corresponding meter's communication address via the MQTT protocol.

[0067] After receiving the update command, the meter device stores the command message in the command cache queue through the command processor, setting the trigger condition to the time point represented by the activation_time field when the system clock reaches that time. The internal clock of the meter is configured in seconds, triggering a check program every second to compare the current time with the target effective time and whether it is later than that value. If the current time is 1754336400 seconds, which matches the value of the activation_time field, the execution program is triggered.

[0068] The program first reads the current electricity price setting, for example, the current rate is 0.75 yuan per kilowatt-hour, which is recorded as the old rate. Then, it writes the value in the "new_rate" field, which is 1.20 yuan per kilowatt-hour, into the meter's billing register, completing the rate switching operation. The system records this switching behavior, forming a first rate switching record, which includes "old_rate" as 0.75, "new_rate" as 1.20, "exec_time" as 1754336400000 milliseconds, and "meter_id" as "M10001".

[0069] Next, the meter calls the log generation module to encapsulate the switch record into a log structure. The log fields include "pre_rate", "post_rate", "exec_timestamp", and "meter_identifier", with each field value being the data obtained from the aforementioned record. The log structure is stored in the meter's built-in log storage area, which is a flash partition that supports time-sorted indexing to support subsequent verification and querying.

[0070] To ensure the switchover action is executed correctly, the system initiates a log verification process. The verification process reads the "activation_time" value from the first update command and compares it with the "exec_timestamp" field in the log. The difference between the two must not exceed the system's allowed deviation threshold, which is preset to 5000 milliseconds. Currently, both exec_timestamp and activation_time are 1754336400000 and 1754336400000, respectively, resulting in a difference of 0, thus meeting the consistency requirement. The system records that the verification passed and generates a log verification data structure containing "match" as true and "delta" as 0.

[0071] Finally, the system calls the status update program to update the status field of this electricity price instruction from "Pending Execution" to "Executed" in the meter status record database. Simultaneously, it adds the fields "verify_time" as the current timestamp, "result" as "success," and "applied_rate" as 1.20. This status record is used for subsequent settlement and regulatory auditing.

[0072] The electricity data acquisition module, upon the arrival of the settlement period, batch-retrieves stored user electricity consumption data sequences, including electricity consumption and timestamps, from smart meters. Simultaneously, it retrieves all relevant local execution log records for the settlement period from the smart metering terminal management platform. After batch-retrieving the user electricity consumption data set and the log data set from the smart meters, it compares the timestamps in the user electricity consumption data set with the execution timestamps in the log data set through data verification to obtain a timestamp matching result. If the timestamp matching result matches, it integrates the user electricity consumption data set and the log data set by timestamp to generate an integrated data set. Data analysis categorizes and statistically analyzes the electricity consumption data in the integrated dataset, generating electricity consumption statistics. Based on these statistics, the periodic cost for each user is calculated using a combination of cost calculation and billing rates from the log dataset, yielding a cost calculation result. If the cost value in the calculation exceeds a preset threshold, abnormal cost records are flagged through anomaly detection, generating an abnormal data set. The cost calculation result and the abnormal data set are stored in the settlement database of the management platform, generating settlement data records. Based on these records, user settlement notification data is generated, transmitted to the user terminal, and notification transmission confirmation is obtained.

[0073] In the dynamic pricing and user management system for the electricity retail market, when the preset settlement period arrives, the system triggers a data collection command through the task scheduler. This settlement period is a fixed time period set by the system, generally once every 30 days, with the start and end times set by platform parameters, such as from 00:00 on the 1st of each month to 23:59 on the last day of the month. The electricity data collection module first sends a data request command to all registered smart meters, requesting the return of all user electricity consumption data and execution log data within the settlement period. After receiving the request, each smart meter filters records from its local storage by start and end time. User electricity consumption data is indexed by timestamps, and each record contains the fields "timestamp" and "energy_used". The former is in milliseconds, recording the precise time the data occurred, and the latter is in kilowatt-hours, using a floating-point format to represent the single-point electricity consumption, such as 2.15. In the log dataset, each record contains the fields "exec_time" and "billing_rate," representing the time when the electricity pricing policy takes effect and the electricity price at that time, respectively, in yuan per kilowatt-hour, and are also floating-point numbers, such as 1.20. After data collection, the platform enters the timestamp comparison stage, using a sequential traversal method. For each "timestamp" field value in the user data, it searches the log dataset for the closest "exec_time" record that is no later than that time. This is achieved by setting two pointers in the log dataset to point to the current and previous records, comparing each record one by one, calculating the time difference, and selecting the record with the smallest time difference as the match. For example, if an electricity consumption data time is 1757000100000 milliseconds, then the matching log record with "exec_time" is 1757000000000 milliseconds, the difference is 100000 milliseconds, and the match is considered successful. If the difference exceeds the system's maximum error threshold, for example, 600,000 milliseconds (10 minutes), it is marked as a mismatch, and the record enters the exception record queue. All successfully matched electricity consumption data are bound to the corresponding log records and integrated into structured records. Each record contains four fields: data timestamp, electricity consumption, effective electricity price time, and applicable electricity price, forming an integrated data set.

[0074] After data integration is complete, the system activates the statistics module to cluster all integrated records according to the "billing_rate" field. This involves summing up the electricity consumption under the same price to form statistical groups based on electricity price. For example, at a price of 1.20 yuan per kilowatt-hour, the accumulated consumption is 35.4 kilowatt-hours, and at a price of 0.80 yuan per kilowatt-hour, it is 42.7 kilowatt-hours. The clustering algorithm is a hash table-based categorical accumulation algorithm, where each electricity price is used as a key. The integrated data set is processed one by one. If the price key exists, its "energy_used" field is accumulated; otherwise, a new key is created and initialized. After statistics are completed, the system enters the cost calculation stage. The system calls the billing module to perform multiplication operations on each price group, multiplying the total electricity consumption of the group by the corresponding electricity price to obtain the itemized cost. For example, 35.4 multiplied by 1.20 equals 42.48 yuan, and 42.7 multiplied by 0.80 equals 34.16 yuan. Adding all the cost items together gives the user's total electricity cost for the billing cycle. Here, it is 42.48 plus 34.16 equals 76.64 yuan. Keep two decimal places as the final cost value.

[0075] After the billing calculation is completed, the anomaly detection procedure begins. The system presets a single-cycle billing threshold of 300.00 yuan, which is obtained by the statistical analysis module by multiplying the average user billing over the past 12 cycles by 2.5, ensuring the identification of large bills that deviate from the norm. If a user's billing amount exceeds this threshold, it is marked as an anomaly. For anomaly records, the system generates an anomaly data structure, including the user ID, cycle range, calculated cost, amount exceeding the threshold, and a description of the reason for the anomaly. All billing calculation results and anomaly records are stored in the settlement database through transactional write operations. The database structure includes tables "billing_result" and "billing_exception," the former used to record all normal user settlement data, and the latter used to record anomaly records for backend review.

[0076] After the data is written, the system generates a settlement notification, which includes fields such as the period range, total electricity consumption, total cost, and details of the electricity price structure. The format is rendered according to a unified template. After rendering, the system sends the notification to the user's registered terminal push service through the interface. The notification is pushed to the user's terminal using the HTTPS protocol. The terminal returns a status code of 200 to indicate successful reception. The platform records the status of this notification and updates the notification log to the confirmed status, thus completing the entire period settlement process.

[0077] The data matching module employs a time-series alignment algorithm to correlate and match user electricity consumption data sequences with local execution log records. It assigns each electricity consumption data point to the corresponding billing rule interval at the time of electricity consumption, resulting in a segmented billing data set. This includes processing user electricity consumption data sequences and local execution log records using the time-series alignment algorithm to generate the segmented billing data set; using the segmented billing data set, combined with preset billing rule intervals, determining the billing rule affiliation for each electricity consumption data point, resulting in a rule affiliation data set; if the billing rules in the rule affiliation data set match the billing parameters in the execution log, then data verification is successful. The system compares timestamps to determine data consistency, resulting in a verified data set. Based on this set, the cost for each electricity consumption data point is calculated according to the billing rule interval, resulting in a cost calculation data set. Anomaly detection compares the cost values ​​in the cost calculation data set with preset thresholds; if a cost value exceeds the threshold, an anomaly record is marked, resulting in an anomaly-marked data set. The cost calculation data set and the anomaly-marked data set are stored in the settlement database using a data storage method, generating settlement data records. Based on the settlement data records, a notification generation module generates user cost notification data, transmits it to the user terminal, and generates notification transmission confirmation data.

[0078] In the dynamic pricing and user management system for the electricity retail market, the data matching module precisely matches the user electricity consumption data sequence provided by the smart meter with the local execution log record set generated by the meter within the corresponding settlement period, and completes the billing processing under the segmented pricing conditions. First, the system reads the electricity consumption data sequence, already sorted in ascending time order, from the smart meter. The data format includes "timestamp" (millisecond-level timestamp) and "energy_used" (unit: kilowatt-hour). Simultaneously, it reads the recorded electricity pricing strategy change information from the smart meter log database. The log format includes "exec_timestamp" (electricity pricing strategy effective time, unit: milliseconds) and "billing_rate" (unit: yuan per kilowatt-hour). The system uses a pointer-synchronized time series alignment algorithm. While traversing the electricity consumption data records one by one, it maps them to the last "exec_timestamp" log record no later than the specified timestamp, thus constructing a matching pair. For each timestamp field value, the system uses an internal binary search algorithm to locate the largest `exec_timestamp` value in the log record set that is less than or equal to that timestamp as the matching object, and uses its `billing_rate` as the electricity price attribute for that data point. If a timestamp is earlier than any `exec_timestamp`, it means that the data record was generated before the electricity price policy took effect, and it is recorded according to the default electricity price and marked as "default". If the time difference between a timestamp and an `exec_timestamp` exceeds the system-defined maximum matching error range of 600,000 milliseconds (i.e., 10 minutes), the system marks the record as a failed match and it will not participate in subsequent segmented billing. This error threshold is determined based on the national smart meter synchronization error standard and the upper limit of the response delay for electricity price adjustment instructions, ensuring data legality and rigorous electricity price application logic.

[0079] After matching is complete, the system generates a segmented billing data set. Each record includes successfully matched timestamp, energy_used, exec_timestamp, and billing_rate fields. The system then matches the billing_rate field value with the platform's preset billing rule ranges. These ranges are specified by the operational strategy, for example, RMB 1.50 per kilowatt-hour during peak hours, RMB 1.20 per kilowatt-hour during off-peak hours, RMB 1.00 per kilowatt-hour during normal hours, and RMB 0.80 per kilowatt-hour during off-peak hours, and are bound to specific time periods, such as peak hours from 08:00 to 11:00 and 18:00 to 21:00 daily. The system maps the timestamp field value to the corresponding time period and verifies whether the billing_rate field matches the standard electricity price for that period. If they match, a rule-assigned data record is generated, including time, electricity consumption, electricity price period type, and electricity value. If the match is inconsistent, the record is removed from the current round of statistics queue and written to the system log for manual review by the backend to determine if it's a mismatch caused by policy version differences.

[0080] After the rule-assigned data set is confirmed, the system initiates the billing process. For each record, the system multiplies the energy_used value by the billing_rate value to calculate the cost for that data point. For example, if the electricity consumption is 0.62 kWh and the electricity price is 1.20 yuan per kWh, the cost is 0.62 multiplied by 1.20, which equals 0.744 yuan, rounded to two decimal places. The system accumulates the cost values ​​of all data points one by one to form a periodic segmented summary cost list. Next, the system performs an anomaly detection process. The system presets a maximum cost of 5.00 yuan per point. This threshold is extrapolated by the platform based on historical statistical data distributed at the 95th percentile to identify unexpected high power consumption or high electricity price mismatches. If a cost record exceeds this threshold, it is marked as an anomaly, and an anomaly marker record is generated. The record includes the timestamp, energy_used, billing_rate, calculated_fee of the anomaly data, and the anomaly reason field (such as "single point overcharge").

[0081] All calculation results are written to the settlement database after final confirmation. The cost calculation data set is stored in the "segment_fee_detail" table, and the exception marker data set is written to the "segment_fee_exception" table. All database fields are structured data, indexed by user ID, meter ID, and cycle ID. The system then activates the notification generation module, retrieving the total cycle cost and segmented electricity price statistics for each user from the settlement database, and generating a settlement notification data package conforming to the platform's notification template. Fields include the settlement cycle, total electricity consumption, electricity consumption and price for each time period, itemized costs, total cost, and number of exception records. This notification is sent to the user's registered terminal via the platform's push service using the HTTPS protocol. The user's terminal returns a status code 200 to indicate receipt, and the platform updates the notification status to "sent successfully."

[0082] The billing generation module, based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption within each billing interval, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to a third-party payment platform for final settlement. This includes obtaining the electricity consumption and corresponding electricity price for each billing interval from the segmented billing data set, calculating the cost for each interval using multiplication, obtaining an interval cost data set; based on the interval cost data set, generating traceability records containing electricity consumption, electricity price, and cost calculation formulas for each billing interval, obtaining a billing traceability path set; and encrypting the records in the billing traceability path set using a hash algorithm to generate a unique identifier, which is then appended to each traceability record to obtain a verifiable electronic bill. If the unique identifier in the verifiable electronic bill matches the preset format standard, the data verification module compares the cost value in the bill with the range cost data set to determine data consistency, resulting in a verified bill set. Based on the verified bill set, the verifiable electronic bill is transmitted to a third-party payment platform via data transmission, and the platform returns a receipt confirmation data set, resulting in a bill transmission data set. Based on the bill transmission data set, anomaly detection compares the status code in the receipt confirmation data with a preset threshold. If the status code exceeds the threshold, it is marked as a transmission anomaly record, resulting in an anomaly-marked data set. Based on the anomaly-marked data set, the verifiable electronic bill and the anomaly-marked data set are stored in the settlement database via data storage, resulting in the final settlement data set.

[0083] The specific implementation process of the bill generation module is as follows: The system first receives the input "segmented billing data set". Each data entry includes a "billing interval identifier", "electricity consumption value", and "corresponding electricity value". The system reads each data entry sequentially from the set. For each data entry, the system performs basic multiplication, multiplying the "electricity consumption value" by the "corresponding electricity value" to obtain the "interval fee" for that billing interval. For example, in a certain record, the "electricity consumption value" is 15.67 and the "corresponding electricity value" is 1.30. The interval fee is calculated as 15.67 multiplied by 1.30, resulting in 20.371. The system rounds the result to two decimal places, ultimately obtaining 20.37. The sum of all interval fees is the user's total electricity fee for this billing cycle. If the user has four intervals, namely 20.37, 5.84, 3.45, and 0.96, the total fee is 30.62 yuan.

[0084] After calculating the fees for all intervals, the system generates traceability data for each record. The traceability data includes fields such as: original electricity consumption, original electricity price, and a description of the calculation formula (presented in text format as "Electricity Consumption × Electricity Price = Fee"). The system automatically generates corresponding traceability records based on the interval data. For example, "15.67 × 1.30 = 20.37". Subsequently, the system converts the traceability record into a string and encrypts the string using a hash algorithm (SHA256) to generate a unique identifier. Each traceability record generates a 64-character hexadecimal identifier, which is then linked to that record, forming a verifiable electronic bill.

[0085] After generating an electronic invoice, the system immediately validates its contents. First, it performs format validation, checking that the unique identifier for each traceability record meets the length requirement of 64 characters and is a valid hexadecimal string. Second, the system compares each range of charges in the invoice with the original calculation results. If any discrepancy is found, the system marks that record as abnormal and excludes it from further processing. All validated invoices are then consolidated into a "validated invoice set."

[0086] The system then performs data transmission, sending the "verified bill set" to the third-party payment platform via encrypted communication. The transmission uses an HTTPS secure channel, and the bill content is encapsulated in symmetric encryption. Upon receiving the data, the platform returns a set of confirmation data, including a "status code" and a "receive timestamp." The status code indicates whether the data transmission was successful; a value of 0 indicates success, and a non-zero value indicates failure. The receive timestamp records the specific time the platform received the data.

[0087] If the "status code" in the confirmation data received by the system is non-zero, it indicates that the transmission failed. In this case, the system extracts the failed bill records and generates an anomaly marker data set. Each record in this set contains the failure status code, a description of the failure reason, and the corresponding bill number. Finally, the system writes all "verified bill sets" and "anomaly marker data sets" into the settlement database. The settlement database contains two logical tables: one table is dedicated to storing bill records and their traceability information, and the other table records abnormal transmission events and their corresponding status codes.

[0088] The parameters in this implementation are described as follows: the electricity consumption value comes from the actual electricity consumption data collected periodically by the user's smart meter; the electricity value is generated based on the standardized electricity price instructions issued by the power dispatch system; the status code is set according to the specifications provided by the third-party payment platform, where 0 indicates success, 1 indicates timeout, 2 indicates incomplete data, and 3 indicates signature error, etc.; the fee calculation uses multiplication, and the result is rounded to two decimal places; the hash function uses SHA256, and the output is a fixed 64-bit string, requiring no external setting; the threshold is only used to identify the status code, and its value is set to 0, with all non-zero values ​​being abnormal; all formula calculations are processed with standard numerical precision, with no floating error.

[0089] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A dynamic pricing and user management system for the electricity retail market, characterized in that, include: The data acquisition module collects multi-dimensional state data, including power grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network, and aggregates the multi-dimensional state data into a structured power grid state vector. The instruction generation module analyzes the structured power grid state vector based on a pre-established power grid safety operation rule library. If at least one indicator in the state vector exceeds a preset safety threshold, it automatically triggers the generation of an original electricity price control instruction that includes the control target, effective time, and price fluctuation coefficient. The terminology standardization module uses a semantic mapping algorithm based on domain ontology to match non-standard business terms in the original electricity price control instructions with standard data elements in the predefined unified interaction contract, and convert them into a standardized electricity price instruction that follows the unified data specification. The timestamp and encapsulation module calls the trusted timestamp service to attach a timestamp to the standardized electricity price instruction and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event; The event broadcasting module broadcasts encrypted and trusted control events to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market. Then, it decrypts the trusted control events and verifies their integrity and timeliness to obtain standardized electricity price instructions to be executed. The instruction issuance module, based on the parsed standardized electricity price instruction content, sends metering rule update commands to smart meters within a specified range. The smart meters switch the billing rate at the effective time of the instruction and generate a local execution log record including the rates before and after the switch and the execution timestamp. When the settlement period arrives, the electricity data acquisition module retrieves the stored user electricity data sequence, including electricity consumption and timestamps, from the smart meter in batches, and at the same time retrieves the set of all relevant local execution log records within the settlement period from the smart metering terminal management platform. The data matching module uses a time series alignment algorithm to associate and match the user's electricity consumption data sequence with the local execution log record set, and assigns each electricity consumption data point to the billing rule interval corresponding to the time when the electricity consumption occurred, thus obtaining a segmented billing data set. The billing generation module calculates and generates a verifiable electronic bill with detailed billing traceability based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption in each billing interval, and transmits the electronic bill to a third-party payment platform for final settlement.

2. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The data acquisition module collects multi-dimensional state data, including power grid line load, node voltage, and frequency deviation, in real time through a distributed sensor network, and aggregates the multi-dimensional state data into a structured power grid state vector, including: A multi-state dataset is obtained by acquiring real-time data including line load, node voltage, and frequency deviation through a distributed sensor network. Data stream processing is used to clean and standardize the multivariate state dataset to obtain structured state data; If any attribute in the structured state data exceeds a preset threshold, an abnormal data fragment is extracted using a sliding window algorithm to obtain an abnormal state vector. Based on the abnormal state vector, the K-means clustering algorithm is used to classify the abnormal data and determine the set of abnormal types; By using a pre-established power grid state mapping model, feature matching is performed on the set of anomaly types to obtain power grid state assessment results; Time series analysis is used to predict the trend of power grid state assessment results and obtain the state change trend. Based on the trend of state changes, the state vector is optimized using an adaptive filtering algorithm to obtain an optimized power grid state description.

3. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The instruction generation module analyzes the structured power grid state vector based on a pre-established power grid safety operation rule base. If at least one indicator in the state vector exceeds a preset safety threshold, it automatically triggers the generation of an original electricity price control instruction, including the control target, effective time, and price fluctuation coefficient. If at least one power grid indicator in the structured vector exceeds the safety threshold, the set of indicators exceeding the threshold is obtained by threshold judgment, and the abnormal indicator set is determined. Based on the set of abnormal indicators, a pre-established rule base is used to perform rule matching to obtain a subset of matching rules; By matching a subset of rules, an electricity price control instruction containing the control target, effective time, and price coefficient is generated, thus obtaining the original control instruction; By employing time series analysis, the price coefficients in the original control orders are dynamically adjusted to obtain optimized control orders. Based on the optimized control instructions, the instructions are transmitted to the power grid dispatch system through instruction distribution to obtain instruction execution confirmation; If the instruction execution confirmation is not received within the preset time, the reason for non-execution is obtained through log analysis, and an adjusted control instruction is generated. According to the adjusted control instructions, the instructions are redistributed to the scheduling system using encrypted transmission to obtain the final execution status.

4. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The terminology standardization module employs a semantic mapping algorithm based on domain ontology to match non-standardized business terms in the original electricity price control instructions with standard data elements in a predefined unified interaction contract, thereby generating a standardized electricity price instruction that conforms to unified data specifications. Non-standardized terms are extracted from the original control instructions through semantic parsing to obtain a term set; Based on the terminology set, a semantic mapping algorithm is used to search for matching items in the business terminology database and determine the corresponding standard data elements; If at least one non-standard term successfully matches a standard data element, then the term-to-data-element mapping relationship is generated through the term matching rules, and a data element mapping table is obtained. Based on the data element mapping table, the non-standardized terms in the original control instructions are replaced with standard data elements using the instruction conversion process to generate standardized electricity price instructions. By using data specification standards, the standardized electricity price instructions are format-verified to determine whether they comply with the requirements of the unified interactive contract, and the verification results are obtained. If the verification result shows a format that does not meet the requirements, the mapping relationship is readjusted through semantic parsing to obtain the updated data element mapping table; Based on the updated data element mapping table, the instruction conversion process is re-executed to generate the final standardized electricity price instruction.

5. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The timestamp and encapsulation module calls a trusted timestamp service to attach a timestamp to the standardized electricity price instruction, and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event, including: By extracting key fields from standardized electricity price directives through data extraction, a set of fields is obtained; Based on the set of fields, a unique identifier is generated using a hash algorithm to obtain the event identifier; By using a trusted timestamp service, millisecond-level timestamps can be obtained to acquire timestamp data. If the timestamp data matches the field set format of the standardized electricity price instruction, the AES encryption algorithm is used to encapsulate the field set, timestamp data, and event identifier to obtain the encrypted control event. The integrity of the encrypted control event is verified by checking whether it conforms to the trusted event specification, and the verification result is obtained. If the validation result shows a format mismatch, the key fields are re-parsed through data extraction to obtain the updated field set; Based on the updated field set, the hash algorithm is re-executed to generate a new event identifier. The field set, timestamp data, and new event identifier are then encapsulated using the AES encryption algorithm to obtain the final encrypted and trusted control event.

6. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The event broadcasting module broadcasts encrypted and trusted control events to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market. It then decrypts the trusted control events and verifies their integrity and timeliness to obtain standardized electricity price instructions to be executed, including: The encrypted control events are transmitted to the dynamic pricing system, the smart metering terminal management platform, and the third-party payment gateway via broadcasting and a distribution mechanism to obtain a distribution confirmation signal. If the distribution confirmation signal meets the preset configuration, the dynamic pricing system uses a decryption algorithm to parse the encrypted control event, extract the event content, and obtain preliminary instruction data. The initial instruction data is verified through integrity verification. If the verification result matches the preset configuration, it is determined that the instruction data has not been tampered with, and trusted instruction data is obtained. A timeliness verification method is adopted to compare the timestamps of trusted instruction data. If the timestamps are within the preset time range, the timeliness of the instruction data is judged to be qualified, and the instruction to be executed is obtained. Based on the instruction to be executed, the dynamic pricing system generates a standardized electricity price instruction, which is then transmitted to the smart metering terminal management platform to receive instruction confirmation. The standardized electricity price instruction is verified through a third-party payment gateway using a preset configuration. If the verification result meets the preset rules, transaction confirmation data is generated. Based on the transaction confirmation data, the smart metering terminal management platform updates the electricity price execution status and obtains the final execution record.

7. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The instruction issuing module, based on the parsed standardized electricity price instruction content, sends a metering rule update command to smart meters within a specified range. The smart meters switch their billing rates at the instruction's effective time and generate a local execution log record including the rates before and after the switch, and the execution timestamp. The intelligent metering terminal management platform parses standardized electricity price instructions, extracts electricity price data and time constraints, and generates the first metering rule data. If the time constraint of the first measurement rule data conforms to the preset time range, the first measurement rule data is converted into an update command through rule generation to obtain the first update command; The command is sent to the designated smart meter to transmit the first update command, and the command reception confirmation signal returned by the smart meter is obtained to confirm that the command transmission is complete. The smart meter receives the first update command and, at the effective time, switches the current billing rate to the target billing rate in the first update command through rate switching, thus obtaining the first rate switching record. Based on the first rate switching record, local log data containing the billing rates before and after the switch and the execution timestamp is generated and stored in the local log library of the smart meter to obtain the first log record. Log verification is used to compare the timestamp of the first log record with the time constraint of the first update command. If the comparison results are consistent, the first log record is determined to be valid, and log verification data is generated. Based on the log verification data, the electricity price execution status of the smart meter is updated to "executed" through status updates, generating the final status record.

8. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: When the settlement period arrives, the electricity data acquisition module batch-retrieves the stored user electricity data sequence, including electricity consumption and timestamps, from the smart meter. Simultaneously, it retrieves a set of all relevant local execution log records for the settlement period from the smart metering terminal management platform, including: After obtaining user electricity consumption data sets and log data sets in batches from smart meters, the timestamps in the user electricity consumption data sets are compared with the execution timestamps in the log data sets through data verification to obtain timestamp matching results; If the timestamp matching results are consistent, the user electricity consumption data set and the log data set are associated by timestamp through data integration to generate an integrated data set; By analyzing data, the electricity consumption data in the integrated dataset is classified and statistically analyzed to generate electricity consumption statistics. Based on the electricity consumption statistics, the periodic cost for each user is calculated by combining the billing rate in the log data set with the cost calculation, and the cost calculation result is obtained. If the cost value in the cost calculation result exceeds the preset threshold, abnormal cost records are marked through anomaly detection, and an abnormal data set is generated. The cost calculation results and abnormal data sets are stored in the settlement database of the management platform through data storage, generating settlement data records; Based on the settlement data records, user settlement notification data is generated, transmitted to the user terminal, and notification transmission confirmation is received.

9. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The data matching module employs a time series alignment algorithm to correlate and match user electricity consumption data sequences with local execution log records, attributing each electricity consumption data point to the corresponding billing rule interval at the time of electricity consumption, resulting in a segmented billing data set including: The user's electricity consumption data sequence and the local execution log record set are processed by a time series alignment algorithm to generate a segmented billing data set. By using segmented billing data sets and combining them with preset billing rule intervals, the billing rule affiliation of each electricity data point is determined, resulting in a rule affiliation data set. If the billing rules in the rule set are consistent with the billing parameters in the execution log, then the data consistency is determined by comparing the timestamps through data verification, and the verification-passed data set is obtained. Based on the verified data set, the cost of each electricity consumption data point is calculated according to the billing rule range to obtain the cost calculation data set; Anomaly detection compares the cost values ​​in the cost calculation dataset with a preset threshold. If the cost value exceeds the threshold, an anomaly record is marked, resulting in an anomaly-marked dataset. A data storage method is used to store the cost calculation dataset and the anomaly marker dataset in the settlement database to generate settlement data records; Based on the settlement data records, the notification generation module generates user fee notification data, transmits it to the user terminal, and receives notification transmission confirmation data.

10. The dynamic pricing and user management system for the electricity retail market according to claim 1, characterized in that: The billing generation module, based on the segmented billing data set, applies the corresponding electricity price to the electricity consumption within each billing interval, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to a third-party payment platform for final settlement, including: Based on the segmented billing data set, the electricity consumption and corresponding electricity price for each billing interval are obtained. Multiplication is used to calculate the cost for each interval, resulting in the interval cost data set. Based on the interval cost data set, for each billing interval, a traceability record containing electricity consumption, electricity price and cost calculation formula is generated to obtain a set of billing traceability paths; A hash algorithm is used to encrypt the records in the billing traceability path set, generate a unique identifier, and attach it to each traceability record to obtain a verifiable electronic bill. If the unique identifier in the electronic bill can be verified to be consistent with the preset format standard, the data verification module compares the cost value in the bill with the range cost data set to determine the data consistency and obtain the set of bills that have passed verification. Based on the verified bill set, the verifiable electronic bills are transmitted to the third-party payment platform via data transmission. The platform then returns confirmation data, resulting in the bill transmission data set. Based on the bill transmission data set, the status code in the received confirmation data is compared with a preset threshold through anomaly detection. If the status code exceeds the threshold, it is marked as a transmission anomaly record, and an anomaly marked data set is obtained. Based on the set of anomaly markers, the verifiable electronic invoices and the set of anomaly markers are stored in the settlement database to obtain the final settlement data set.

Images