Power retail market dynamic pricing and user management system

Abstract

The invention discloses an electric power retail market dynamic pricing and user management system, which relates to the technical field of intelligent electric power systems and comprises a data acquisition module for acquiring multivariate state data including power grid line load, node voltage and frequency deviation in real time and converging the multivariate state data into a power grid state vector; the instruction generation module is used for automatically triggering and generating an original electricity price regulation and control instruction containing a regulation and control target, effective time and a price floating coefficient if at least one index in the state vector is judged to exceed a preset safety threshold value; the power retail market dynamic pricing and user management system realizes power grid state real-time monitoring, instruction standardized transmission and transparent settlement, and improves power grid operation efficiency and user trust.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent power systems, and in particular to a dynamic pricing and user management system for a power retail market. Background Art

[0002] In the grand blueprint for building a new power system, the intelligent transformation of the electricity retail market is the cornerstone for achieving efficient energy allocation and a healthy interaction between supply and demand. Currently, although various systems in the electricity retail sector are closely connected in terms of business processes—for example, electricity price adjustments are based on grid status, and user payments rely on electricity usage data from smart meters—technical implementations generally rely on isolated and customized integration methods, lacking a unified interaction framework.

[0003] The fragmentation of this technical implementation directly leads to the "drift" of data semantics and the "misalignment" of interaction timing between systems. The core challenge lies in the natural heterogeneity of data structures and communication protocols between different systems. This is not only a difference in format, but also a gap in business logic understanding. For example, when the power grid dispatching system issues an emergency high electricity price instruction due to excessive line load, the dynamic pricing system needs to respond immediately. However, due to the non-standardization of the interface protocol, the instruction may cause delays or parsing errors when it is transmitted to the smart meter for metering rule switching. This directly leads to a "timestamp" level deviation between the user's actual electricity consumption behavior and the billing strategy. That is, the user's electricity consumption in a certain period of time cannot be accurately attributed to the corresponding electricity price range by the third-party payment platform, thereby causing 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 the semantic gap and timing conflicts caused by system heterogeneity, and ensure that the 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-mentioned objectives, the present invention provides the following technical solutions: a dynamic pricing and user management system for an electricity retail market, comprising a data acquisition module, which collects multivariate state data including grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured grid state vector; an instruction generation module, which 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, an effective time, and a price fluctuation coefficient if at least one indicator in the state vector exceeds a preset safety threshold; a terminology standardization module, which uses a semantic mapping algorithm based on domain ontology to match the non-standardized business terms in the original electricity price control instruction with the standard data elements in the predefined unified interaction contract, and converts and generates a standardized electricity price instruction that complies with the unified data specification; a timestamp and encapsulation module, which calls a trusted timestamp service, adds 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, which broadcasts the encrypted trusted control event to the dynamic pricing system and smart metering terminal management platform in the electricity retail market. and the third-party payment gateway, and then decrypts the trusted control event and verifies the integrity and timeliness to obtain the standardized electricity price instruction to be executed; the instruction issuing module, the smart metering terminal management platform issues a metering rule update command to the smart meter within the specified range according to the parsed standardized electricity price instruction content. The smart meter switches the billing rate at the time the instruction takes effect, and generates a local execution log record including the rates before and after the switch and the execution timestamp; the electricity consumption data collection module, when the settlement period arrives, obtains the stored user electricity consumption data sequence including electricity consumption and timestamp from the smart meter in batches, and The metering terminal management platform retrieves all relevant local execution log record sets within the settlement period; the data matching module uses a time series alignment algorithm to correlate and match the user's electricity consumption data sequence with the local execution log record set, and attributes each electricity consumption data point to the billing rule interval corresponding to the time when the electricity consumption occurred, obtaining a segmented billing data set; the bill generation module applies the corresponding electricity price for the electricity consumption in each billing interval based on the segmented billing data set, 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 multivariate state data including grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured grid state vector, including obtaining real-time data including line load, node voltage, and frequency deviation through a distributed sensor network to obtain a multivariate state data set; using data stream processing to clean and standardize the multivariate state data set to obtain structured state data; if any attribute in the structured state data exceeds a preset threshold, extracting abnormal data fragments through a sliding window algorithm to obtain an abnormal state vector; based on the abnormal state vector, using a K-means clustering algorithm to classify the abnormal data and determine an abnormal type set; using a pre-established grid state mapping model to perform feature matching on the abnormal type set to obtain a grid state assessment result; using a time series analysis method to perform trend prediction on the grid state assessment result to obtain a state change trend; based on the state change trend, optimizing the state vector through an adaptive filtering algorithm to obtain an optimized grid state description.

[0007] Preferably, the instruction generation module analyzes the structured power grid state vector according to a pre-established power grid safety operation rule library, and automatically triggers the generation of an original electricity price control instruction including a control target, an effective time, and a price floating coefficient if at least one indicator in the state vector exceeds a preset safety threshold. If at least one power grid indicator in the structured vector exceeds the safety threshold, a threshold judgment is performed to obtain a set of indicators exceeding the threshold and determine an abnormal indicator set; based on the abnormal indicator set, a pre-established operation rule library is used to perform rule matching to obtain a matching rule subset; based on the matching rule subset, an electricity price control instruction including a control target, an effective time, and a price coefficient is generated to obtain an original control instruction; a time series analysis method is used to dynamically adjust the price coefficient in the original control instruction to obtain an optimized control instruction; based on the optimized control instruction, the instruction is transmitted to the power grid dispatching system through instruction distribution to obtain an instruction execution confirmation; if the instruction execution confirmation is not received within the preset time, the reason for non-execution is obtained through a log analysis method, and an adjusted control instruction is generated; based on the adjusted control instruction, the instruction is redistributed to the dispatching system using encrypted transmission to obtain a final execution state.

[0008] Preferably, the term standardization module uses a semantic mapping algorithm based on domain ontology to match the non-standardized business terms in the original electricity price control instruction with the standard data elements in the predefined unified interaction contract, and converts and generates a standardized electricity price instruction that complies with the unified data specification, including extracting non-standardized terms from the original control instruction through semantic parsing to obtain a term set; using the semantic mapping algorithm to search for matching items in the business term library based on the term set to determine the corresponding standard data elements; if at least one non-standardized term successfully matches the standard data element, then using the term matching rule to generate a mapping relationship from the term to the data element to obtain a data element mapping table; based on the data element mapping table, using the instruction conversion process to replace the non-standardized terms in the original control instruction with standard data elements to generate a standardized electricity price instruction; using the data specification standard to perform format verification on the standardized electricity price instruction to determine whether it meets the requirements of the unified interaction contract and obtain a verification result; if the verification result shows that the format does not meet the requirements, then readjusting the mapping relationship through semantic parsing to obtain an updated data element mapping table; based on the updated data element mapping table, re-executing the instruction conversion process to generate the final standardized electricity price instruction.

[0009] Preferably, the timestamp and encapsulation module calls the trusted timestamp service, adds 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 parsing the key fields from the standardized electricity price instruction through data extraction to obtain a field set; based on the field set, a unique identifier is generated using a hash algorithm to obtain an event identifier; through the trusted timestamp service, a millisecond-level timestamp is obtained to obtain 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 an encrypted control event; the integrity of the encrypted control event is verified through verification to determine whether it complies with the trusted event specification to obtain a verification result; if the verification result shows that the format does not match, the key fields are re-parsed through data extraction to obtain an updated field set; based on the updated field set, the hash algorithm is re-executed to generate a new event identifier, and the AES encryption algorithm is used to encapsulate the field set, timestamp data and new event identifier to obtain the final encrypted trusted control event.

[0010] Preferably, the event broadcast module broadcasts the encrypted trusted control event to the dynamic pricing system, smart metering terminal management platform and third-party payment gateway in the electricity retail market, and then decrypts the trusted control event and verifies the integrity and timeliness, and obtains the standardized electricity price instruction to be executed, including transmitting the encrypted control event to the dynamic pricing system, smart metering terminal management platform and third-party payment gateway through broadcasting using 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 preliminary instruction data is verified through integrity verification, and if the verification result is correct, If it matches the preset configuration, it is determined that the instruction data has not been tampered with and the trusted instruction data is obtained; the timeliness verification method is used to compare the timestamps of the trusted instruction data. If the timestamp is within the preset time range, the timeliness of the instruction data is determined to be qualified and the instruction to be executed is obtained; according to the instruction to be executed, the dynamic pricing system generates a standardized electricity price instruction, transmits it to the smart metering terminal management platform, and obtains confirmation of instruction receipt; through the third-party payment gateway, the preset configuration is used to verify the transaction of the standardized electricity price instruction. If the verification result meets the preset rules, transaction confirmation data is generated; according to the transaction confirmation data, the smart metering terminal management platform updates the electricity price execution status and obtains the final execution record.

[0011] Preferably, the instruction issuing module, the smart metering terminal management platform issues a metering rule update command to the smart meters within the specified range according to the parsed standardized electricity price instruction content, and the smart meters switch the billing rate at the instruction effective time point, and generate a local execution log record including the rates before and after the switching and the execution timestamp. The smart metering terminal management platform parses the standardized electricity price instruction, extracts the electricity price data and time constraints, and generates the first metering rule data; if the time constraint of the first metering rule data meets the preset time range, the first metering rule data is converted into an update command through rule generation to obtain the first update command; the first update command is transmitted to the specified smart meter through command issuance, and the command reception returned by the smart meter is obtained. Confirmation signal, confirming that the command transmission is completed; the smart meter receives the first update command, and switches the current billing rate to the target billing rate in the first update command through rate switching at the effective time, and obtains the first rate switching record; through log generation, based on the first rate switching record, generates local log data containing the billing rates before and after switching and the execution timestamp, and stores it in the local log library of the smart meter to obtain the first log record; uses log verification to compare the timestamp of the first log record with the time constraint of the first update command. If the comparison result is consistent, it is determined that the first log record is 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 update, and a final status record is generated.

[0012] Preferably, the electricity consumption data acquisition module obtains the stored user electricity consumption data sequence including electricity consumption and timestamps from the smart meter in batches when the settlement period arrives, and at the same time retrieves all relevant local execution log record sets within the settlement period from the smart metering terminal management platform, including obtaining the user electricity consumption data set and the log data set in batches from the smart meter, and then compares the timestamp in the user electricity consumption data set with the execution timestamp in the log data set through data verification to obtain a timestamp matching result; if the timestamp matching result is 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 The system integrates the electricity consumption data in the integrated data set and classifies and counts them through data analysis to generate electricity consumption statistics results; based on the electricity consumption statistics results, the periodic fee of each user is calculated by combining the fee calculation with the billing rate in the log data set to obtain the fee calculation results; if the fee value in the fee calculation result exceeds the preset threshold, the abnormal fee record is marked through anomaly detection to generate an abnormal data set; the fee calculation result and the abnormal data set are stored in the settlement database of the management platform through data storage to generate settlement data records; based on the settlement data records, user settlement notification data is generated and transmitted to the user terminal to obtain notification transmission confirmation.

[0013] Preferably, the data matching module uses a time series alignment algorithm to associate and match the user's electricity data sequence with the local execution log record set, and attributes each electricity data point to the billing rule interval corresponding to the time when the electricity consumption occurs, to obtain a segmented billing data set, including processing the user's electricity data sequence and the local execution log record set by the time series alignment algorithm to generate a segmented billing data set; using the segmented billing data set, combined with the preset billing rule interval, to determine the billing rule attribution of each electricity data point to obtain a rule attribution data set; if the billing rule in the rule attribution data set is consistent with the billing parameter in the execution log, then the billing rule is assigned to the data set by the data set. According to the verification and comparison timestamps, the data consistency is judged to obtain the verification data set; based on the verification data set, the cost of each electricity consumption data point is calculated according to the billing rule interval to obtain the cost calculation data set; through anomaly detection, the cost value in the cost calculation data set is compared with the preset threshold. If the cost value exceeds the threshold, the abnormal record is marked to obtain the abnormal marked data set; the cost calculation data set and the abnormal marked data set are stored in the settlement database using the data storage method to generate settlement data records; based on the settlement data records, the notification generation module is used to generate user cost notification data, which is transmitted to the user terminal to obtain notification transmission confirmation data.

[0014] Preferably, the bill generation module applies the corresponding electricity price for the electricity consumption in each billing interval according to the segmented billing data set, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to the third-party payment platform for final settlement. The module includes obtaining the electricity consumption and the corresponding electricity price of each billing interval according to the segmented billing data set, calculating the cost of each interval by multiplication operation, and obtaining the interval cost data set; generating a traceability record containing electricity consumption, electricity price and cost calculation formula for each billing interval according to the interval cost data set, and obtaining a billing traceability path set; using a hash algorithm to encrypt the records in the billing traceability path set, generating a unique identification code, and attaching it to each traceability record to obtain a verifiable electronic bill. single; if the unique identification code in the verifiable electronic bill is consistent with the preset format standard, the fee value in the bill is compared with the interval fee data set through the data verification module to determine the data consistency and obtain the verified bill set; based on the verified bill set, the verifiable electronic bill is transmitted to the third-party payment platform by data transmission, and the receipt confirmation data returned by the platform is obtained to obtain the bill transmission data set; based on the bill transmission data set, the status code in the receipt confirmation data is compared with the preset threshold through anomaly detection. If the status code exceeds the threshold, it is marked as a transmission abnormality record to obtain the abnormality mark data set; based on the abnormality mark data set, the verifiable electronic bill and the abnormality mark data set are stored in the settlement database by data storage to obtain the final settlement data set.

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

[0016] This dynamic pricing and user management system for the electricity retail market collects multivariate state data of the power grid in real time through a distributed sensor network and generates a structured state vector. It combines the analysis with a preset security rule base to trigger standardized electricity price control instructions, solving the problems of low operating efficiency and lack of trust in traditional power grids caused by data dispersion, non-standardization of control instructions, and insufficient transparency in settlement. The present invention converts original instructions into standardized instructions with unified data specifications through a semantic mapping algorithm, and adds a trusted timestamp to generate encrypted trusted control events, which are broadcast to the dynamic pricing system and smart meters to ensure the integrity and timeliness of the instructions. The smart meter updates the billing rules according to the instructions and records the execution log. It accurately matches the user's electricity consumption data with the billing rules through a time series alignment algorithm, and generates a verifiable electronic bill containing a traceability path. The present invention realizes real-time monitoring of the power grid status, standardized instruction transmission and transparent settlement, improving the operating efficiency of the power grid and user trust. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, the present invention provides a technical solution: a dynamic pricing and user management system for the electricity retail market, including a data acquisition module, which collects multivariate state data including grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured grid state vector; an instruction generation module, which 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, an effective time, and a price floating coefficient if at least one indicator in the state vector exceeds a preset safety threshold; a terminology standardization module, which adopts a semantic mapping algorithm based on domain ontology to match the non-standardized business terms in the original electricity price control instruction with the standard data elements in the predefined unified interaction contract, and converts and generates a standardized electricity price instruction that complies with the unified data specification; a timestamp and encapsulation module, which calls a trusted timestamp service, adds a timestamp to the standardized electricity price instruction, and encapsulates the standardized electricity price instruction and the timestamp into an encrypted trusted control event; event broadcast The module broadcasts the encrypted trusted regulation event to the dynamic pricing system, smart metering terminal management platform and third-party payment gateway in the electricity retail market, then decrypts the trusted regulation event and verifies its integrity and timeliness to obtain the standardized electricity price instruction to be executed; the instruction issuance module, the smart metering terminal management platform issues a metering rule update command to the smart meters within the specified range based on the parsed standardized electricity price instruction content. The smart meter switches the billing rate at the time the instruction takes effect and generates a local execution log record including the rates before and after the switch and the execution timestamp; the electricity consumption data collection module, when the settlement period arrives, batch obtains the stored user electricity consumption data sequence including electricity consumption and timestamps from the smart meter, and at the same time retrieves all relevant local execution log record sets 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 electricity consumption data sequence with the local execution log record set, and attributes each electricity consumption data point to the billing rule interval corresponding to the electricity consumption, to obtain a segmented billing data set;

[0020] The bill generation module applies the corresponding electricity price to the electricity consumption in each billing interval based on the segmented billing data set, 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.

[0021] This implementation achieves automation, transparency, and verifiability in electricity price regulation by building an integrated dynamic pricing and user management system. The system first collects multivariate state data on power grid operations in real time through a distributed sensor network, generating a structured state vector. Based on a grid security operation rule base, the system continuously analyzes key indicators in the state vector. If an anomaly is detected, it immediately generates a raw electricity price regulation instruction containing the regulation target and floating parameters. This instruction is converted into a standard data format using a terminology standardization module, encapsulated as a trusted regulation event under a timestamp service, and then broadcast to relevant systems. Upon receiving the instruction, the dynamic pricing system and terminal platform parse and execute it, and the smart meter switches the rate as required and records the operation log. During settlement, a time series alignment algorithm accurately matches electricity consumption data with logs, achieving highly accurate attribution of electricity price and electricity consumption. This ultimately generates a detailed, auditable electronic bill that supports payment and regulatory verification.

[0022] This system can achieve closed-loop management of the entire process, from grid operation monitoring to electricity price regulation to user billing, and has the following advantages: first, it improves the control response efficiency of the power system and ensures safe operation; second, it uses semantic mapping to achieve terminology standardization and enhance system interoperability; third, it ensures the credibility and traceability of instruction execution through timestamps and encryption mechanisms; in addition, it combines time alignment algorithms for high-precision segmented billing, improving billing accuracy and user trust; finally, it can generate verifiable electronic bills, which helps users clearly understand the source of billing, facilitates settlement and supervision by third-party platforms, and improves market transparency.

[0023] The data acquisition module collects multivariate state data including power grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured power grid state vector, including obtaining real-time data including line load, node voltage, and frequency deviation through a distributed sensor network to obtain a multivariate state data set; using data stream processing to clean and standardize the multivariate state data set to obtain structured state data; if any attribute in the structured state data exceeds a preset threshold, the sliding window algorithm is used to extract abnormal data fragments 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 abnormal type set; through a pre-established power grid state mapping model, the abnormal type set is feature matched to obtain a power grid state assessment result; a time series analysis method is used to predict the trend of the power grid state assessment result to obtain a state change trend; based on the state change trend, the state vector is optimized through an adaptive filtering algorithm to obtain an optimized power grid state description.

[0024] The data acquisition module deploys fixed data acquisition terminals at the power system's substation outgoing busbars, grid trunk line intersections, and high-voltage transmission line terminals. These terminals are embedded with current transformers, voltage transformers, and frequency detection circuits. Each terminal collects raw current, voltage, and frequency values ​​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 serves as the line load value. The voltage value is used directly as the node voltage value. The frequency value is set by the system based on the number of voltage zero crossings per second. The ideal value is 50. If the actual number of detections is 49, the deviation is negative 1 Hz, and so on. These three parameters form a set of three-dimensional data at each time point, which is continuously recorded to form a multivariate state data set, with a total of 60 data sets collected per minute.

[0025] This dataset is input into the data stream processing module for cleaning and standardization. Data cleaning is performed in three steps: the first step is deduplication, which involves comparing the timestamps of two adjacent data sets to ensure they are identical. If they are identical, the first data set is retained. The second step is missing field completion. If a field in a single data set is missing, linear interpolation is used to complete the missing value, averaging the values ​​of the two valid data points before and after the field. The third step is outlier removal. If any field in a data set deviates by more than two standard deviations from its mean value within the five seconds before and after, it is considered a sudden change and replaced using a sliding average with a five-second window. The calculation is performed by adding the data for the field within the two seconds before and after the current time and dividing by 5. The result is used as the current value of the field. The cleaned data is then standardized using the range normalization method. Taking the line load as an example, assume that its historical minimum value is 100 kilowatts and the maximum value is 1000 kilowatts. If the current value is 550 kilowatts, the normalized value is (550 minus 100) divided by (1000 minus 100), which is 0.5. The node voltage and frequency deviation values ​​are also normalized to the range of 0 to 1 using this method.

[0026] Thresholds are assessed for structured data. The line load threshold is 90% of the line's design capacity. For a 1000 kW design capacity, the threshold is 900 kW. The node voltage upper and lower thresholds are 90% and 110% of the nominal voltage, respectively. For a 220 volt nominal voltage, the upper limit is 242 volts and the lower limit is 198 volts. The frequency deviation threshold is fixed at ±0.2 Hz, a value set in accordance with national standards for safe operation of power systems. If any field exceeds its corresponding threshold, the system initiates anomaly detection. The first step in the anomaly detection process is to extract anomalous data segments using a sliding window. This extraction method involves extracting 20 seconds of data, one group per second, from the current threshold-exceeding time point.

[0027] A sliding window algorithm is applied to the abnormal data segments. The window size is set to 5 seconds and the step size is 1 second, that is, each window contains 5 sets of data, and 16 windows are formed by sliding sequentially from the beginning of the segment. The variance of the line load, node voltage, and frequency deviation is calculated in each window. The calculation method is to subtract the square of the average value of each field from the square of each value, sum it up and divide it by the number of data points. If the variance of a field exceeds 3 times its historical average variance in normal data, the window is judged to contain an anomaly. All window data that meet the conditions are merged into a set of abnormal state vectors, which are arranged in time order and marked as an abnormal event instance.

[0028] After the system collects multiple abnormal event instances, it inputs them into the K-means clustering module for abnormal type classification. The K value is set to 5, and it is set as the optimal number of classifications based on the evaluation results of the clustering silhouette coefficient of historical abnormal events. The initial step is to randomly select 5 groups from all abnormal state vectors as the initial centroids; then calculate the Euclidean distance from each of the remaining groups of abnormal state vectors to the 5 centroids, and define each sample as belonging to the category represented by the centroid closest to it; then calculate the average vector of all samples in each category as the new centroid; repeat this process until the change in each type of centroid is less than the preset threshold. The threshold is set to 0.001, which means that the change in each dimension of the vector must not exceed 0.001. After clustering is completed, the system obtains a set of 5 abnormal types.

[0029] Each anomaly type is input into the grid state mapping model for feature matching. The model uses a matching method based on a rule table. Each rule defines a combination of several field thresholds. For example, if the line load is higher than 0.9 and the absolute value of the frequency deviation is higher than 0.1, it is a "load shock" state. The representative vectors in the clustering results are compared with all rules one by one to calculate the matching degree. The matching degree is calculated as follows: if each field in the rule is met, 1 point is added, and the total score divided by the number of rule fields is the matching degree. A matching degree of not less than 0.8 is considered a successful match. After comparison, the grid state name corresponding to each anomaly is obtained, such as "overload operation" and "frequency fluctuation".

[0030] The grid state assessment results are fed into the time series analysis module for trend forecasting. The forecasting method uses a simple moving average method with a 30-second time window. This method categorizes and counts the state assessment results generated every second over the past 30 seconds, counting the number of occurrences of each state category. If a state occurs more than 15 times within the window (i.e., 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. If it occurs between 10 and 15 times, it is predicted to be in a fluctuating state.

[0031] Finally, the system optimizes the grid state vector based on the prediction results. The optimization algorithm uses adaptive filtering. The calculation process is as follows: if the difference between the current value of any field in the vector and the previous value is less than 0.05, the current value is retained as the optimized value. If the difference exceeds 0.05, a weighted average method is used: the current value is weighted 0.3, the previous value is weighted 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, which serves as a stable description of the grid state and is provided to the next stage for dynamic electricity pricing control decisions.

[0032] The instruction generation module analyzes the structured power grid state vector according to 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 including a control target, an effective time, and a price floating coefficient. If at least one power grid indicator in the structured vector exceeds the safety threshold, a threshold judgment is performed to obtain a set of indicators exceeding the threshold and determine an abnormal indicator set; based on the abnormal indicator set, a pre-established operation rule library is used to perform rule matching to obtain a matching rule subset; based on the matching rule subset, an electricity price control instruction including a control target, an effective time, and a price coefficient is generated to obtain an original control instruction; a time series analysis method is used to dynamically adjust the price coefficient in the original control instruction to obtain an optimized control instruction; based on the optimized control instruction, the instruction is transmitted to the power grid dispatching system through instruction distribution to obtain an instruction execution confirmation; if the instruction execution confirmation is not received within the preset time, a log analysis method is used to obtain the reason for non-execution and generate an adjusted control instruction; based on the adjusted control instruction, the instruction is redistributed to the dispatching system using encrypted transmission to obtain a final execution state.

[0033] During system operation, the instruction generation module monitors the latest grid state vector (SGSV) transmitted from the SGSV processing module in real time. This SGSV 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 evaluates this SGSV based on a pre-set safety threshold. The safety threshold for line load is set at 90% of the line's design capacity. For example, a line with a design capacity of 1000 kilowatts would have a safety threshold of 900 kilowatts. During normalization, this threshold is calculated based on the range between the historical minimum and maximum values ​​of the line load indicators. If the historical minimum is 100 kilowatts and the historical maximum is 1000 kilowatts, the normalized value of 900 kilowatts is 900 minus 100, divided by 900, which is 0.888. The node voltage safety range 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 between 0 and 1. 0 Hz is mapped to 0.5, +0.2 Hz to 0.6, and -0.2 Hz to 0.4. Through this 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 exceeded indicator and its normalized value, forming an abnormal indicator set. This abnormal indicator set is then fed into a predefined operational rule base for rule matching. The rule base is a structured data set. Each rule contains one or more condition combinations. Each condition consists of "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 against the data in the abnormal indicator set. The matching method is: for each indicator, if the normalized value of the abnormal indicator exceeds the threshold in the rule, the condition is considered met. Only when all conditions in the rule are met is the rule considered a match and the system adds it to the matching rule subset.

[0035] When the matching rule subset is determined, the system selects a rule according to the priority to generate the original control instruction. The original control instruction includes three parts: the control target, the effective time and the electricity price floating coefficient. The control target is the power limit percentage, which is generally set to 10%, 20% and 30%. The effective time is the time point after a fixed delay from the current system time. The delay time is determined according to the control level. For example, when the control target is 10%, the delay is 5 minutes, when it is 20%, the delay is 10 minutes, and when it is 30%, the delay is 15 minutes. The electricity price floating coefficient is a coefficient multiplied by the current benchmark electricity price, which is generally set to 1.05, 1.10 or 1.20, corresponding to the control level from light to heavy.

[0036] After the order is generated, the price fluctuation coefficient optimization process begins. This process is based on time series statistics of historical response records from the past 30 days. Each record includes three data items: control conditions, electricity price coefficient, and user response rate. The user response rate is defined as the total load reduction 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 kilowatts and the actual reduction is 80 kilowatts, the response rate is 80%. The module selects all control records consistent with the current abnormal indicator set from historical data, summarizes their response rates, and calculates the average. If the average response rate is less than 60%, it indicates that the electricity price incentive under the same conditions was insufficient, and the module will increase the current floating coefficient by 0.05. If the response rate is greater than 85%, it indicates that the incentive is too strong, and the module will decrease the coefficient by 0.05. If the response rate is between 60% and 85%, it will remain unchanged. After adjustment, the electricity price fluctuation coefficient replaces the original value in the original order, forming the optimized control order.

[0037] Optimization control commands are sent to the power grid dispatching system via a communication interface based on a structured message protocol. These commands contain fields such as the command ID, timestamp, control target, electricity price coefficient, and effective time. The system records the command sending time and sets a 10-second confirmation response from the dispatching system. If no confirmation is received within the specified time, the module initiates the log analysis process. Log analysis begins by retrieving the log files from the dispatching system interface module within the last three minutes, generating one log entry per second, for a maximum of 180 entries. Each log entry contains the command ID, return code, response time, and error information. The module parses each entry in chronological order. 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 is recorded as a network failure; if it indicates an authentication failure, a key error is recorded; and if it indicates a parameter error, the command format is incorrect. Based on the error type, the module generates an adjusted control command. For example, if it indicates a network failure, the effective time is extended by five minutes; if it indicates an authentication failure, the key is regenerated and the communication token is replaced; if it indicates a parameter error, the command format is reconstructed and the field integrity is verified.

[0038] After completing the adjusted instructions, the system enters the encryption phase. Encryption uses a symmetric key algorithm. The key is automatically generated by the system once a day, is 256 bits long, and is stored in the security key management module. The module uses the current key to encrypt the instruction fields in sequence, and a ciphertext structure is formed after the encryption is completed. After encryption, the instruction is resent to the power grid dispatching system through a backup communication link. This backup link is physically isolated from the main communication link and supports redundant forwarding functions under network failures. The system starts the 10-second confirmation timer again. If a successful response is received, the final status is recorded as "executed". Otherwise, the system will generate an exception report containing the failure log, fault type, number of retries and final status, and store it in the instruction audit record 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 complies with the unified data specification. This includes extracting non-standard terms from the original regulation instruction through semantic parsing to obtain a set of terms; according to the set of terms, 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 format verification 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 period 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 individual phrases 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 a total entry length of 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 form a term set, which serves as input for the next step of semantic mapping. The mapping process begins by comparing each term in the term set with each standard term in the standard data meta-repository. This comparison uses the edit distance algorithm to calculate similarity. The edit distance is the minimum number of single-character operations required to convert one string into another. For example, let's say the original term is "enabling time" and the standard term is "effective time." With an edit distance of 3, the length of the standard term is 4, and the similarity is calculated as 1 minus 3 divided by 4, which equals 0.25. The system sets a similarity threshold of 0.8, derived from empirical statistical analysis to ensure a false positive rate of no more than 5% in the training corpus. Only when the similarity is greater than or equal to 0.8 is the standard term considered a candidate for mapping to the current non-standard term. If multiple candidates exist, the system selects the one with the highest similarity. All established term mappings form a meta-repository mapping table. Each record includes the original term, the target standard term, the similarity value, and the 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, finds 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 unifying the expression into a standard form, such as converting "twenty percent" to "0.2"; unit normalization is to unify "5 minutes" into "300 seconds", and the value is obtained by multiplying 5 by 60. After all fields are replaced, a preliminary standardized electricity price instruction is generated.

[0043] The module then inputs the standardized electricity price instruction into the format verification module. This format verification performs four checks in the following order: First, field name validity checks. This compares the current field names with the field list in the unified interaction contract. Any fields not in the list are deemed invalid. Second, field value type checks. Each field has a specific data type requirement, such as a floating-point number for the price coefficient field and a timestamp integer for the time field. The system parses the field values ​​in turn and verifies whether their data types match. Third, field integrity checks. The unified interaction contract defines all required fields, such as "control target," "effective time," and "price coefficient." Missing any of these fields will result in a verification failure. Fourth, structural consistency checks. This involves a hierarchical analysis of the instruction structure, verifying whether the nesting format is correct and whether the field order conforms to standard structure specifications. Standardization is considered successful if all checks pass.

[0044] If an unqualified item is found during the verification process, the module will immediately record the failure type and enter the remapping stage. First, the mapping source term and its mapping relationship will be rechecked based on the field where the failed item is located. If the similarity is lower than 0.85, the system will automatically enable the second most similar term among the candidate items for replacement and regenerate the data element mapping table. If the field value format is incorrect, such as it should be a floating point type but the current value is the Chinese description "Twenty Point Zero", the system will call the format standardization module to convert it to "20.0"; if the field is missing, the system will fill in the default value according to the rule template. If the price coefficient is not provided, the default setting is 1.00. After all problem items are corrected, re-execute the instruction conversion and format verification process.

[0045] The timestamp and encapsulation module calls the trusted timestamp service, adds 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 parsing the key fields from the standardized electricity price instruction through data extraction to obtain a field set; based on the field set, a unique identifier is generated using a hash algorithm to obtain an event identifier; through the trusted timestamp service, a millisecond timestamp is obtained to obtain 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 an encrypted control event; the integrity of the encrypted control event is verified through verification to determine whether it complies with the trusted event specification and obtain the verification result; if the verification result shows that the format does not match, 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, and the AES encryption algorithm is used to encapsulate the field set, timestamp data and new event identifier to obtain the final encrypted trusted control event.

[0046] After the timestamp and encapsulation module is activated, its first processing step is to extract key fields from the standardized electricity price control instructions. These fields serve as the basis for generating event identifiers and encrypted encapsulation. Standardized electricity price control instructions are structured data, typically in the form of ordered JSON structures with key-value pairs. The module's field extraction rules specify that the key fields to be extracted include the control target, effective time, price fluctuation coefficient, instruction number, scheduling region, and data source identifier, totaling six fields. The names of these fields are standardized in the unified interaction contract. The system uses a field name matching function to traverse all fields in the JSON structure and select the six fields that match exactly, forming a field set. The field set is stored internally in a list structure, with keys and values ​​in the form of key-value pairs. The key is a string, and the value may be an integer, floating point, or date. 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 system uses SHA256, a hash algorithm that compresses an input string of any length into 256-bit binary data using fixed rules. To ensure input uniqueness and format consistency, the module first concatenates the field set into a continuous string in the format "key name = key value," with multiple fields separated by vertical bars (|). For example, if a field set contains three fields: "target=load_reduction," "price_factor=1.2," and "start_time=1691653200," the combined string would be "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, which returns a 64-character hexadecimal string, such as "c54d7f8bc2e4a613..." This string serves as the event identifier, used for subsequent data indexing and encryption encapsulation. The uniqueness of this identifier is determined by the value of each field in the field set. Any change in the field will cause the hash value to change, thus ensuring that each event record is globally unique.

[0048] Next, the module issues a time request to the trusted timestamp service. This service is a trusted, authenticated time source that provides time data accurate to the millisecond. 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 service responds with a timestamp value, which is a 13-bit unsigned integer representing the cumulative number of milliseconds since 00:00:00 on January 1, 1970, such as "1754332805123." The module stores this timestamp value as a string, which serves as the time authentication information for this control instruction.

[0049] The module then performs a structural match check on the timestamp value and the effective time field in the field set. This check ensures the consistency of the time field format and prevents encapsulation failures due to format conflicts. The system's standard time format is a Unix timestamp integer, meaning the time field must be an integer 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 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 is verified, 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 key names: "field_set", "event_id", and "timestamp". The key value content of each field is encapsulated as a nested structure in JSON format to ensure that each content can be independently parsed. If the generated structure does not exceed an integer multiple of 16 bytes in length, it enters the padding phase. The system uses the PKCS7 padding method, and pads the end of the structure to an integer multiple of 16 in a group of 16-byte data 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 completing the structure construction, the module performs AES encryption. The encryption algorithm uses the AES-256 standard, with a 256-bit key length and CBC symmetric encryption mode. The initial vector is generated daily by the system, and the key is automatically generated by the security module at midnight each day and stored in encrypted form in the key storage module. It can only be decrypted and called after passing permission authentication. The encryption operation uses 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 is 128 bytes long, the encrypted ciphertext will still be 128 bytes.

[0052] After encryption is complete, the module performs integrity verification on the encrypted result. This integrity verification is a two-step process. The first step is to decrypt the ciphertext by calling the same AES decryption function used for encryption, using the same key and initialization vector to restore the ciphertext. The second step is to compare the decrypted result with the original plaintext structure. The fields compared include each key name and value in the field set, the content of the event identifier, the timestamp value, and the structural order of these three. If any field is missing, has an inconsistent value, or is out of order, the system will record the current event as "verification failed" and initiate the regeneration process.

[0053] During the regeneration process, the module re-extracts the set of fields from the standardized instructions, repeats the hash calculation to generate a new event identifier while retaining the original timestamp value, reconstructs the structure, and performs AES encryption and integrity verification. If it fails again, the system generates a failure log, detailing 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 as "Encapsulation Completed," and pushed to the downstream event broadcast module.

[0054] The event broadcast module broadcasts the encrypted trusted control event to the dynamic pricing system, smart metering terminal management platform and third-party payment gateway in the power retail market, and then decrypts the trusted control event and verifies the 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 through 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 verified through integrity verification, and if the verification result is consistent with the preset If the configuration matches, it is determined that the instruction data has not been tampered with, and the trusted instruction data is obtained; a timeliness verification method is used to compare the timestamps of the trusted instruction data. If the timestamp is within the preset time range, the timeliness of the instruction data is determined 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, transmits it to the smart metering terminal management platform, and obtains confirmation of instruction receipt; through the third-party payment gateway, the preset configuration is used to verify the transaction of the standardized electricity price instruction. 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.

[0055] After the event broadcast module is started, the broadcast initialization process is first executed. The system reads the target node list defined in the configuration file, which contains three targets: dynamic pricing system, smart metering terminal management platform and third-party payment gateway. Each node is configured with a unique node identification code, 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 packages and sends the generated encrypted trusted control events as encrypted messages in a concurrent asynchronous manner according to the protocols of each node. The packaging format is a JSON structure, the top-level field is "payload", the value is the encrypted event data, and the type is a string.

[0056] After the sending is completed, the system starts the listening program and waits for the three nodes to return a reception confirmation signal. The confirmation signal is a structured response with fields including "status_code", "receive_time" and "node_id". The system sets the judgment condition that all nodes return a "status_code" field value of 200, which is considered a successful reception, where 200 is the HTTP success code in the industry standard. If a node returns a value other than 200, such as 400 or 500, the exception is recorded and the retransmission mechanism is triggered. The retransmission mechanism is executed up to 3 times, with an interval of 5 seconds between each retransmission. If it exceeds 3 times, the broadcast is marked as failed.

[0057] After receiving the encrypted message, the dynamic pricing system calls the local decryption module and uses the currently valid key to perform AES-256 decryption operations. The decryption key is generated by the system at 0:00 every day and stored in the encryption security module. It needs to be verified by permission when called. The input of the decryption function is a base64-encoded ciphertext string, and the output is a plaintext structure. The structure contains 3 fields: "field_set" is a field set, which includes the control target, price coefficient, effective time, etc.; "event_id" is the event identifier, which is a 64-bit hexadecimal string; "timestamp" is a 13-bit Unix millisecond timestamp. The system reads the contents of each field in turn through the field matching function and generates preliminary instruction data.

[0058] To ensure that the instruction data has not been tampered with, the system performs integrity verification on the preliminary instruction data. The specific method is to extract all fields from the "field_set" field, concatenate them into a string in order, in the format of "key1=value1|key2=value2|key3=value3", and then input it into the SHA256 hash function to calculate the digest value. The digest value is a 64-bit hexadecimal string, which is compared character by character with the "event_id" field value. The comparison logic is to compare each character from the first to the last digit. If any digit is different, the verification fails. If all 64 bits are consistent, the data is complete and marked as trusted instruction data.

[0059] After obtaining the trusted instruction data, the system immediately performs timeliness verification. The maximum allowable time error threshold is set to 300,000 milliseconds, or 5 minutes. The business demand setting is dynamically adjusted according to the electricity price to ensure that the control instruction is executed within the validity period. The system obtains the current server timestamp by calling the system time function, accurate to milliseconds. For example, the current timestamp is 1754333100000. Subtract the "timestamp" field value from the current timestamp, for example, subtract 1754332800000, and the time difference is 300,000 milliseconds. If the difference is less than or equal to 300,000, the timeliness is judged as "qualified"; if it is greater than 300,000, it is judged as "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" and enters the electricity price instruction generation process. The system calls the template filling function and fills the three fields "target", "start_time", and "price_factor" into the predefined format template respectively. For example, the standard structure generated by filling in the fields is "{'price_type':'TOU','start_time':'1754332800','price_factor':'1.2'}", and its format complies with the requirements of the unified interaction contract. After the generation is completed, the encrypted communication module is called to push the standardized electricity price instruction to the smart metering terminal management platform through the HTTPS protocol, and wait for the platform to return a receipt confirmation. The confirmation format is a structured message containing two fields: "code" and "received_at". A code of 200 is considered to be successfully received.

[0061] At the same time, the system sends the same standardized electricity price instruction to the third-party payment gateway, which then verifies the transaction. Verification consists of three phases. The first phase involves checking the legitimacy of field names. The system compares all field names in the instruction against the payment gateway's preset field list. If any field name mismatch occurs, verification fails. The second phase involves verifying the electricity price factor range. The system configuration allows for a floating price factor range of 1.00 to 1.50. The "price_factor" field value in the instruction is read and converted to a floating-point value. If it is 1.20, it is within the range and is considered legal. The third phase involves digital signature comparison and verification. The system concatenates the field contents into a string in the specified order, generates a digest, and then decrypts the signature field using the platform's public key. If they match, verification passes. After these three phases, transaction confirmation data is generated, with a structure containing "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 "floating coefficient". It merges them into a complete final electricity price execution record, saves it in the local database, and provides it for subsequent calls by the electricity fee settlement platform.

[0063] Instruction issuing module, the smart metering terminal management platform issues a metering rule update command to the smart meters within the specified range according to the parsed standardized electricity price instruction content. The smart meter switches the billing rate at the time when the instruction takes effect, and generates a local execution log record including the rates before and after the switch and the execution timestamp. The smart metering terminal management platform parses the standardized electricity price instruction, extracts the electricity price data and time constraints, and generates the first metering rule data; if the time constraint of the first metering rule data meets the preset time range, the first metering rule data is converted into an update command through rule generation to obtain the first update command; the first update command is transmitted to the specified smart meter through command issuance, and the command reception confirmation signal returned by the smart meter is obtained. number, confirming that the command transmission is completed; the smart meter receives the first update command, and switches the current billing rate to the target billing rate in the first update command through rate switching at the effective time, and obtains the first rate switching record; generates local log data including the billing rates before and after switching and the execution timestamp according to the first rate switching record through log generation, and stores it in the local log library of the smart meter to obtain the first log record; uses log verification to compare the timestamp of the first log record with the time constraint of the first update command. If the comparison result is consistent, it is determined that the first log record is valid, and log verification data is generated; according to the log verification data, the electricity price execution status of the smart meter is updated to executed through status update, and a final status record is generated.

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

[0065] Subsequently, the system starts the 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 current time of the system is obtained through the internal time function. For example, the current value is 1754334600000, and the unit is milliseconds. The time difference is obtained by subtracting the current timestamp from the "effective_time" field value. The result is 1800000 milliseconds, which is equal to 30 minutes. The time constraint range set by the system is 300 seconds to 86400 seconds, that is, the effective time of the instruction must be 15 minutes earlier than the current time and no more than 24 hours. After converting 1800000 milliseconds to seconds, it is 1800 seconds, which falls within this range, and the judgment is passed.

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

[0067] After receiving the update command, the meter's command processor stores the command message in the command cache queue and sets the trigger condition to when the system clock reaches the time indicated by the activation_time field. The meter's internal clock, configured in seconds, triggers a check every second to compare the current time with the target activation time to see if it is consistent with or later than the target activation time. If the current time is 1754336400 seconds, which matches the value in the activation_time field, the execution of the program is triggered.

[0068] The program first reads the current electricity price setting. For example, if the current rate is 0.75 yuan per kilowatt-hour, it records it as the old rate. It then writes the value in the "new_rate" field, 1.20 yuan per kilowatt-hour, to the meter's billing register, completing the rate switch. The system records this switch, creating a first rate switch record containing "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 switching record into a log structure. The log fields include "pre_rate," "post_rate," "exec_timestamp," and "meter_identifier," each containing the data from the preceding record. The log structure is stored in the meter's built-in log storage area, a flash memory partition that supports time-ordered indexing for subsequent verification and querying.

[0070] To ensure the switchover was actually executed, 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 values ​​must not exceed the system's tolerance threshold, which is preset to 5000 milliseconds. The current exec_timestamp is 1754336400000, and the activation_time is also 1754336400000, with a difference of 0, which meets the consistency requirement. The system records the verification as successful and generates a log verification data structure with "match" set to true and "delta" set to 0.

[0071] Finally, the system calls the status update routine and updates the status field of this price instruction in the meter status record database from "pending" to "executed." It also adds the fields "verify_time" with the current timestamp, "result" with "success," and "applied_rate" with 1.20. This status record is used for subsequent settlement and regulatory audits.

[0072] The electricity consumption data acquisition module obtains the stored user electricity consumption data sequence including electricity consumption and timestamps from the smart meter in batches when the settlement period arrives, and retrieves all relevant local execution log record sets within the settlement period from the smart metering terminal management platform. After obtaining the user electricity consumption data set and the log data set in batches from the smart meter, the timestamp in the user electricity consumption data set is compared with the execution timestamp in the log data set through data verification to obtain the timestamp matching result; if the timestamp matching result is 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; Through data analysis, the electricity consumption data in the integrated data set are classified and counted to generate electricity consumption statistics results; based on the electricity consumption statistics results, the cost calculation is combined with the billing rate in the log data set to calculate the periodic cost of each user to obtain the cost calculation result; if the cost value in the cost calculation result exceeds the preset threshold, the abnormal cost record is marked through anomaly detection to generate an abnormal data set; the cost calculation result and the abnormal data set are stored in the settlement database of the management platform through data storage to generate settlement data records; based on the settlement data records, user settlement notification data is generated and transmitted to the user terminal to obtain notification transmission confirmation.

[0073] In the dynamic pricing and user management system for the electricity retail market, when the preset settlement period arrives, the system triggers data collection instructions through the task scheduler. This settlement period is a fixed period set by the system, generally occurring every 30 days, with the start and end times set by platform parameters, for example, from midnight on the first day of each month to 11:59 PM on the last day of the month. The electricity consumption 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 for the settlement period. After receiving the request, each smart meter filters records from its local storage based on the start and end times. User electricity consumption data is indexed by timestamps, and each record contains the fields "timestamp" and "energy_used." The former records the exact time the data occurred in milliseconds, while the latter represents the single-point electricity consumption in kilowatt-hours using floating-point format, such as 2.15. Each record in the log data set contains the fields "exec_time" and "billing_rate," which represent the time the electricity pricing policy took effect and the electricity price at that time, respectively. These fields are expressed in floating-point units (e.g., 1.20) per kilowatt-hour. After data collection is complete, the platform performs a timestamp comparison. For each "timestamp" field value in the user data, it searches the log data set for the record with the closest "exec_time" that is no later than that time. This is achieved by setting two pointers in the log data set to point to the current and previous records. After comparing each record, the time difference is calculated and the record with the smallest time difference is selected as the match. For example, if a piece of electricity usage data has a time of 1757000100000 milliseconds, the matching log record with an "exec_time" of 1757000000000 milliseconds will have a difference of 100000 milliseconds, indicating a successful match. If the difference is greater than the system's maximum error threshold (for example, 600,000 milliseconds, or 10 minutes), the record is marked as mismatched and placed in the abnormal record queue. All successfully matched electricity usage data is bound to the corresponding log record and integrated into a structured record. Each record contains four fields: data timestamp, electricity usage, effective price time, and applicable price, forming an integrated data set.

[0074] After data integration is complete, the system activates the statistics module, clustering all integrated records by the "billing_rate" field. This aggregates electricity consumption at the same price, forming statistical groups categorized by price. For example, at a price of 1.20 yuan per kilowatt-hour, the accumulated total is 35.4 kWh, while at a price of 0.80 yuan per kilowatt-hour, the accumulated total is 42.7 kWh. The clustering algorithm is a hash table-based classification and accumulation algorithm. Each electricity price is used as a key value, and 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 assigned an initial value. After the statistics are complete, the cost calculation phase begins. The system calls the billing module to perform a multiplication operation on each price group, multiplying the group's total electricity consumption by the corresponding 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. Add up all the fee items to get the user's total electricity cost for the billing period. Here, 42.48 plus 34.16 equals 76.64 yuan. Round to two decimal places as the final cost value.

[0075] After the fee calculation is completed, the anomaly detection program is entered. The system presets a single-cycle fee threshold of 300.00 yuan. This value is obtained by the statistical analysis module by multiplying the average user fee for the past 12 periods by 2.5 to ensure that large bills that deviate from the norm are identified. If the bill amount of a user exceeds this threshold, it is marked as an anomaly. For abnormal records, the system generates an abnormal data structure, which includes the user number, cycle range, calculated fee, amount exceeding the threshold, and a description of the reason for the abnormality. All fee calculation results and abnormal records are stored in the settlement database through transactional write operations. The database structure includes tables "billing_result" and "billing_exception". The former is used to record the normal settlement data of all users, and the latter is used to record abnormal records for background review.

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

[0077] The data matching module uses a time series alignment algorithm to associate and match the user's electricity data sequence with the local execution log record set, and attributes each electricity data point to the billing rule interval corresponding to the electricity consumption, to obtain a segmented billing data set. This includes processing the user's electricity data sequence and the local execution log record set through a time series alignment algorithm to generate a segmented billing data set; using the segmented billing data set, combined with the preset billing rule interval, to determine the billing rule attribution of each electricity data point, and obtain a rule attribution data set; if the billing rule in the rule attribution data set is consistent with the billing parameter in the execution log, then the data is verified. Compare timestamps, determine data consistency, and obtain a verified data set; based on the verified data set, calculate the cost of each electricity consumption data point according to the billing rule interval to obtain a cost calculation data set; compare the cost value in the cost calculation data set with a preset threshold through anomaly detection. If the cost value exceeds the threshold, mark the abnormal record to obtain an abnormal marked data set; use a data storage method to store the cost calculation data set and the abnormal marked data set in a settlement database to generate a settlement data record; based on the settlement data record, use a notification generation module to generate user cost notification data, transmit it to the user terminal, and obtain notification transmission confirmation data.

[0078] In the dynamic pricing and user management system for the retail electricity market, the data matching module accurately matches user electricity usage data sequences provided by smart meters with the set of local execution log records generated by the meter during the corresponding billing cycle, thereby completing billing under segmented electricity pricing. First, the system reads the electricity usage data sequence from the smart meter, sorted in ascending chronological order. The data format includes "timestamp" (millisecond timestamp) and "energy_used" (in kilowatt-hours). Simultaneously, it reads price policy change information from the smart meter log repository. The log format includes "exec_timestamp" (price policy effective time, in milliseconds) and "billing_rate" (in yuan per kilowatt-hour). The system uses a time series alignment algorithm based on pointer synchronization to traverse each electricity usage data record, matching it to the last log record with an exec_timestamp no later than that timestamp, thereby constructing a matching pair. That is, for each timestamp field value, the system will call an internal binary search algorithm to locate the largest exec_timestamp value that is less than or equal to the timestamp from the log record set as the matching object, and use its billing_rate as the electricity price attribute of the data point. If the timestamp is earlier than all exec_timestamps, it means that the data record was generated before the electricity price policy took effect. In this case, the default electricity price record will be used and marked as "default". If the time difference between a timestamp and the exec_timestamp exceeds the system-defined maximum matching error range of 600,000 milliseconds (i.e., 10 minutes), the system will mark the record as a match failure 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 electricity price adjustment instruction response delay to ensure the legitimacy of the data and the strict logic of electricity price application.

[0079] After matching, the system generates a segmented billing data set. Each record includes the matching timestamp, energy_used, exec_timestamp, and billing_rate fields. The system then matches the billing_rate field value against the platform's preset billing rule range. Billing rule ranges are specified by the operational policy, for example, 1.50 yuan per kWh during peak hours, 1.20 yuan per kWh during peak hours, 1.00 yuan per kWh during normal hours, and 0.80 yuan per kWh during off-peak hours. These ranges are tied to time periods, such as 8:00 AM to 11:00 AM and 6:00 PM to 9:00 PM daily. The system maps the timestamp value to the corresponding time period and verifies whether the billing_rate field matches the standard electricity price for that time period. If so, a rule-attributed data record is generated, including the time, electricity usage, price period type, and electricity value. If the match is inconsistent, the record is removed from the current statistics queue and written to the system log for manual backend review to determine if it was a mismatch caused by a policy version discrepancy.

[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 fee for that data point. For example, if electricity consumption is 0.62 kWh and the electricity price is 1.20 yuan per kWh, the fee is 0.62 multiplied by 1.20, which equals 0.744 yuan, rounded to two decimal places. The system then accumulates the fee values ​​for all data points to form a period-by-period summary of the fees. Next, the system performs an anomaly detection process. The system presets a maximum fee of 5.00 yuan for each data point. This threshold is derived from the platform's historical statistical data and extrapolated from the 95th percentile distribution to identify unexpectedly high electricity consumption or high electricity price mismatches. If a fee record exceeds this threshold, it is marked as an anomaly and an anomaly flag record is generated. The record includes the timestamp of the anomaly data, energy_used, billing_rate, calculated_fee, and the reason for the anomaly (such as "single point excess").

[0081] All calculation results are written to the settlement database after final confirmation. The fee calculation data set is stored in the "segment_fee_detail" table, and the exception mark data set is written to the "segment_fee_exception" table. The database fields are all structured data and are indexed and managed by user number, meter number, and cycle number. The system then starts the notification generation module, reads each user's total cycle fee and segmented electricity price statistics from the settlement database, and generates a settlement notification data packet that conforms to the platform notification template. The fields include the settlement cycle, total electricity consumption, electricity consumption and electricity price for each time period, sub-item fees, total fees, number of exception records, etc. The notification is sent to the user's registered terminal by the platform push service via the HTTPS protocol. The user terminal returns a status code 200 to confirm receipt, and the platform updates the record notification status to "successfully sent."

[0082] The bill generation module applies the corresponding electricity price for the electricity consumption in each billing interval according to the segmented billing data set, calculates and generates a verifiable electronic bill including a detailed billing traceability path, and transmits the electronic bill to the third-party payment platform for final settlement. It includes obtaining the electricity consumption and corresponding electricity price of each billing interval according to the segmented billing data set, calculating the cost of each interval by multiplication operation, and obtaining the interval cost data set; generating a traceability record containing electricity consumption, electricity price and cost calculation formula for each billing interval according to the interval cost data set, and obtaining a billing traceability path set; using a hash algorithm to encrypt the records in the billing traceability path set, generate a unique identification code, and attach it to each traceability record to obtain a verifiable electronic bill; if If the unique identification code in the verifiable electronic bill is consistent with the preset format standard, the fee value in the bill is compared with the interval fee data set through the data verification module to determine the data consistency and obtain the verified bill set; based on the verified bill set, the verifiable electronic bill is transmitted to the third-party payment platform by data transmission, and the receipt confirmation data returned by the platform is obtained to obtain the bill transmission data set; based on the bill transmission data set, the status code in the receipt confirmation data is compared with the preset threshold through anomaly detection. If the status code exceeds the threshold, it is marked as a transmission anomaly record to obtain the anomaly mark data set; based on the anomaly mark data set, the verifiable electronic bill and the anomaly mark data set are stored in the settlement database by data storage to obtain 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 item consisting of a "billing interval identifier," "electricity usage value," and "corresponding electricity value." The system then reads each data item from the set in turn. For each data item, the system performs a basic multiplication operation, multiplying the "electricity usage value" by the "corresponding electricity value" to determine the "interval fee" for that billing interval. For example, in a record with an "electricity usage value" of 15.67 and a "corresponding electricity value" of 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 cost for the current billing period. If a user has four intervals of 20.37, 5.84, 3.45, and 0.96, the total fee is 30.62 yuan.

[0084] After calculating all interval charges, the system generates traceability data for each record. This data includes fields such as the original electricity consumption value, the original electricity value, and a calculation formula (written in text format: "Amount of electricity consumed × electricity price = cost"). The system automatically generates a corresponding traceability record based on the interval data. For example, "15.67 × 1.30 = 20.37" is used. The system then converts the traceability record into a string and encrypts it using a hash algorithm (SHA256) to generate a unique identifier. Each traceability record generates a 64-character hexadecimal identifier, which is bound to the record, forming a verifiable electronic bill.

[0085] After generating an electronic invoice, the system immediately verifies its contents. First, it performs a format check to verify that the unique identifier for each traceability record meets the 64-character length requirement and is a valid hexadecimal string. Second, the system compares each interval charge in the invoice with the original calculation result to ensure complete consistency. If any inconsistency is found, the system marks the record as a data anomaly and excludes it from further processing. All invoices that pass verification are consolidated into a "Verified Invoice Set."

[0086] The system then performs a data transmission operation, transmitting the "verified bill collection" to the third-party payment platform via encrypted communication. This transmission utilizes HTTPS, and the bill content is encapsulated using symmetrical encryption. Upon receiving the data, the platform returns a set of confirmation data, including a "status code" and a "receipt timestamp." The status code indicates whether the data was successfully transmitted; a value of 0 indicates success, and a non-zero value indicates failure. The receipt 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 a transmission failure. The system then extracts the failed invoice records and generates an exception marker data set. Each record in this set contains the failure status code, a description of the failure reason, and the corresponding invoice number. Finally, the system writes all "verified invoice sets" and "exception marker data sets" to the settlement database. The settlement database contains two logical tables: one dedicated to storing invoice records and their traceability path information, and the other to recording abnormal transmission events and their corresponding status codes.

[0088] All parameters in this implementation method are described as follows: the electricity consumption value is derived 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 dispatching system; the status code setting is provided by the third-party payment platform, where 0 indicates success, 1 indicates timeout, 2 indicates incomplete data, 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 fixed to a 64-bit string, without the need for external setting; the threshold is only used to identify the status code, and the value is set to 0, and all non-zero values ​​are abnormal; all formula operations are processed with standard numerical precision without floating errors.

[0089] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention 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 multivariate state data including grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured grid state vector; The instruction generation module analyzes the structured grid state vector based on a pre-established 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 including the control target, effective time, and price fluctuation coefficient. The terminology standardization module uses a semantic mapping algorithm based on domain ontology to match the non-standard business terms in the original electricity price regulation instructions with the standard data elements in the predefined unified interaction contract, and converts them into a standardized electricity price instruction that follows the unified data specification; The timestamp and encapsulation module calls the trusted timestamp service, adds 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 broadcast module broadcasts encrypted trusted regulation 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 regulation events and verifies their integrity and timeliness to obtain the standardized electricity price instructions to be executed. Instruction issuing module: The smart metering terminal management platform issues metering rule update commands to smart meters within a specified range based on the parsed standardized electricity price instructions. The smart meters switch the billing rate at the time the instructions take effect and generate a local execution log record that includes the rates before and after the switch and the execution timestamp. The electricity consumption data collection module, when the settlement period arrives, batch-acquires the stored user electricity consumption data sequence including electricity consumption and timestamps from the smart meter, and simultaneously retrieves all relevant local execution log record sets 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 local execution log record sets, attributing each electricity consumption data point to the billing rule interval corresponding to the electricity consumption, and obtaining a segmented billing data set; The bill generation module applies the corresponding electricity price to the electricity consumption in each billing interval based on the segmented billing data set, 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.

2. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The data acquisition module collects multivariate state data including grid line load, node voltage, and frequency deviation in real time through a distributed sensor network, and aggregates the multivariate state data into a structured grid state vector, including: Acquire real-time data including line load, node voltage, and frequency deviation through a distributed sensor network to obtain a multivariate state data set; Data stream processing is used to clean and standardize the multivariate state data set to obtain structured state data; If any attribute in the structured state data exceeds the preset threshold, the abnormal data fragment is extracted through the sliding window algorithm to obtain the abnormal state vector; According to the abnormal state vector, the K-means clustering algorithm is used to classify the abnormal data and determine the abnormal type set; Through the pre-established grid state mapping model, feature matching is performed on the abnormal type set to obtain the grid state assessment result; Use time series analysis method to predict the trend of power grid status assessment results and obtain the status change trend; According to the state change trend, the state vector is optimized through the adaptive filtering algorithm to obtain the optimized power grid state description.

3. The power retail market dynamic pricing and user management system 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 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 including a control target, an effective time, and a price fluctuation coefficient. The original electricity price control instruction includes: If at least one power grid indicator in the structured vector exceeds the safety threshold, the threshold is judged to obtain the indicator set that exceeds the threshold and determine the abnormal indicator set; Based on the abnormal indicator set, a pre-established operational rule library is used to perform rule matching to obtain a matching rule subset; By matching the rule subset, an electricity price control instruction including the control target, effective time, and price coefficient is generated to obtain the original control instruction; Using time series analysis methods, the price coefficients in the original control instructions are dynamically adjusted to obtain optimized control instructions; According to the optimized control instructions, the instructions are transmitted to the power grid dispatching 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 method, 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 power retail market dynamic pricing and user management system according to claim 1, characterized in that: The terminology standardization module uses a semantic mapping algorithm based on domain ontology to match the non-standardized business terms in the original electricity price control instructions with the standard data elements in the predefined unified interaction contract, and converts them into a standardized electricity price instruction that complies with the unified data specification. The module includes: Extracting non-standardized terms from the original regulatory instructions through semantic parsing to obtain a term set; Based on the term set, a semantic mapping algorithm is used to search for matching items in the business term library and determine the corresponding standard data elements; If at least one non-standardized term successfully matches a standard data element, a mapping relationship between the term and the data element is generated through the term matching rule to obtain a data element mapping table; According to the data element mapping table, the instruction conversion process is adopted to replace the non-standardized terms in the original control instructions with standard data elements to generate standardized electricity price instructions; Through data specification standards, the format of the standardized electricity price instructions is verified to determine whether they meet the requirements of the unified interactive contract and obtain the verification results; If the verification result shows that the format does not meet the requirements, the mapping relationship is readjusted through semantic analysis to obtain an updated data element mapping table; According to the updated data element mapping table, the instruction conversion process is re-executed to generate the final standardized electricity price instruction.

5. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The timestamp and encapsulation module calls the trusted timestamp service, adds 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: Parsing key fields from the standardized electricity price instructions through data extraction to obtain a field set; Based on the field set, a hash algorithm is used to generate a unique identifier to obtain an event identifier; Obtain millisecond timestamps and timestamp data through a trusted timestamp service; 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 an encrypted control event; Verify the integrity of the encrypted control event through verification to determine whether it complies with the trusted event specification and obtain the verification result; If the verification result shows that the format does not match, the key fields are re-parsed through data extraction to obtain the updated field set; According to the updated field set, the hash algorithm is re-executed to generate a new event identifier, and the AES encryption algorithm is used to encapsulate the field set, timestamp data and the new event identifier to obtain the final encrypted trusted control event.

6. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The event broadcast module broadcasts the encrypted trusted regulation event to the dynamic pricing system, smart metering terminal management platform, and third-party payment gateway in the electricity retail market, then decrypts the trusted regulation event and verifies its integrity and timeliness to obtain the standardized electricity price instruction to be executed, including: The encrypted control events are transmitted to the dynamic pricing system, smart metering terminal management platform and third-party payment gateway through broadcasting and distribution mechanism to obtain the 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 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 the trusted instruction data is obtained; Adopting the timeliness verification method, the timestamp of the trusted instruction data is compared. If the timestamp is within the preset time range, the instruction data is judged to be timely and the instruction to be executed is obtained; Based on the instructions to be executed, the dynamic pricing system generates a standardized electricity price instruction, transmits it to the smart metering terminal management platform, and obtains confirmation of instruction receipt; Through a third-party payment gateway, the transaction is verified against the standardized electricity price instruction 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 power retail market dynamic pricing and user management system according to claim 1, characterized in that: The instruction issuing module and the smart metering terminal management platform issue a metering rule update command to the smart meters within the specified range based on the parsed standardized electricity price instruction content. The smart meters switch the billing rate at the time the instruction takes effect and generate a local execution log record including the rates before and after the switch and the execution timestamp, including: The smart metering terminal management platform parses the standardized electricity price instructions, extracts the electricity price data and time constraints, and generates the first metering rule data; If the time constraint of the first metering rule data meets the preset time range, converting the first metering rule data into an update command through rule generation to obtain a first update command; Transmitting a first update command to a designated smart meter by issuing a command, obtaining a command reception confirmation signal returned by the smart meter, and confirming that the command transmission is complete; The smart meter receives the first update command, switches the current billing rate to the target billing rate in the first update command through rate switching at the effective time, and obtains a first rate switching record; Generate local log data including the billing rates before and after the switching and the execution timestamp according to the first rate switching record through log generation, and store it in the local log library of the smart meter to obtain a first log record; Using log verification to compare the timestamp of the first log record with the time constraint of the first update command, if the comparison results are consistent, determining that the first log record is valid, and generating log verification data; According to the log verification data, the electricity price execution status of the smart meter is updated to executed through status update, and the final status record is generated.

8. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The electricity consumption data collection module obtains a batch of stored user electricity consumption data sequences including electricity consumption and timestamps from smart meters when a settlement period arrives, and retrieves all relevant local execution log records within the settlement period from the smart metering terminal management platform, including: After obtaining the user electricity consumption data set and the log data set in batches from the smart meter, the timestamp in the user electricity consumption data set is compared with the execution timestamp in the log data set through data verification to obtain the timestamp matching result; If the timestamp matching results are consistent, the user's electricity consumption data set and the log data set are associated by timestamp through data integration to generate an integrated data set; Through data analysis, the electricity consumption data in the integrated data set is classified and counted to generate electricity consumption statistics results; Based on the electricity consumption statistics, the cost calculation is combined with the billing rate in the log data set to calculate the periodic cost of each user and obtain the cost calculation result; If the cost value in the cost calculation result exceeds the preset threshold, the abnormal cost record is marked through anomaly detection to generate an abnormal data set; The fee calculation results and abnormal data sets are stored in the settlement database of the management platform through data storage to generate settlement data records; Based on the settlement data record, user settlement notification data is generated, transmitted to the user terminal, and notification transmission confirmation is obtained.

9. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The data matching module uses a time series alignment algorithm to correlate and match the user's electricity consumption data sequence with the local execution log record set, and attributes each electricity consumption data point to the billing rule interval corresponding to the electricity consumption. The resulting segmented billing data set includes: The user's electricity consumption data sequence and the local execution log record set are processed by the time series alignment algorithm to generate a segmented billing data set; Using the segmented billing data set and combining it with the preset billing rule interval, the billing rule attribution of each electricity consumption data point is determined to obtain the rule attribution data set; If the billing rules in the rule-attribution data set are consistent with the billing parameters in the execution log, the data consistency is determined by comparing the timestamps and obtaining the verified data set; Based on the verified data set, the cost of each electricity consumption data point is calculated according to the billing rule interval to obtain the cost calculation data set; By using anomaly detection, the cost value in the cost calculation data set is compared with the preset threshold. If the cost value exceeds the threshold, the abnormal record is marked to obtain the abnormal marked data set; The data storage method is used to store the fee calculation data set and the abnormality mark data set in the settlement database to generate a settlement data record; According to the settlement data record, the notification generation module is used to generate user fee notification data, transmit it to the user terminal, and obtain notification transmission confirmation data.

10. The power retail market dynamic pricing and user management system according to claim 1, characterized in that: The bill generation module applies the corresponding electricity price for each billing interval based on the segmented billing data set, 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: According to the segmented billing data set, the power consumption and corresponding electricity price of each billing interval are obtained, and the cost of each interval is calculated by multiplication operation to obtain 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 billing traceability path set; A hash algorithm is used to encrypt the records in the billing traceability path set, generate a unique identification code, and attach it to each traceability record to obtain a verifiable electronic bill; If the unique identification code in the electronic bill can be verified to be consistent with the preset format standard, the data verification module compares the fee value in the bill with the interval fee data set to determine the data consistency and obtain the verified bill set; Based on the verified bill set, the verifiable electronic bill is transmitted to the third-party payment platform using data transmission, and the receipt confirmation data returned by the platform is obtained to obtain the bill transmission data set; Based on the bill transmission data set, the status code in the received confirmation data is compared with the preset threshold through anomaly detection. If the status code exceeds the threshold, it is marked as a transmission anomaly record to obtain the anomaly mark data set; According to the abnormal marking data set, the verifiable electronic bill and the abnormal marking data set are stored in the settlement database using data storage to obtain the final settlement data set.

Images