A method and system for pre-checking spot electricity sales declaration

Abstract

The application relates to the technical field of power sale transaction auxiliary decision-making, and discloses a power sale spot declaration pre-checking method and system. The method comprises the following steps: acquiring multi-source original data; performing credible preprocessing and time alignment on the multi-source original data to obtain a standard time sequence data set and a data quality label; generating a user-level reference load curve and summarizing the reference load curve to obtain a power sale company-level reference load curve; generating an initial declaration curve and a time slice state identifier based on transaction rule template data; performing rolling pre-checking before declaration cutoff, distinguishing between data abnormality type deviation and real load drift type deviation; generating correction declaration data for a time slice to be corrected and generating declaration output data; performing version locking on a final confirmed declaration version after the declaration cutoff and grading and taking over abnormal working conditions; and performing deviation attribution and parameter updating based on actual metering data. The application can improve the consistency of declaration data processing and the risk disposal capacity under abnormal working conditions.

Description

Technical Field

[0001] This invention relates to the field of auxiliary decision-making technology for electricity sales transactions, and more specifically, to a method and system for pre-verification of spot electricity sales declarations. Background Technology

[0002] In regional electricity spot markets, electricity retailers typically need to represent their industrial and commercial customers and submit demand curves for each time period of the operating day before a preset deadline. These demand curves are usually used for transaction support, power purchase plan formation, and subsequent deviation analysis. For electricity retailers, the formation of demand curves does not rely solely on single historical load data, but typically requires the integration of multiple data sources, including time-of-use data from smart meters, time-of-use data from electricity information collection terminals, real-time power data from load management systems, marketing records, user-reported data, weather data, holiday calendar data, and transaction rule template data.

[0003] In existing technologies, one type of solution mainly focuses on user load forecasting, emphasizing improving forecast accuracy through historical electricity consumption curves or meteorological factors; another type focuses on estimating or optimizing declared quantities, emphasizing generating declared values ​​based on prices, risk preferences, or historical deviations; and yet another type is mainly used for settlement analysis or deviation statistics, focusing on post-operational result accounting. While these solutions can address some of the problems, they still have shortcomings in the actual spot market declaration scenarios of electricity sales companies.

[0004] First, existing technologies typically assume that the input data already has good consistency, but they do not adequately consider the inconsistencies in timescales, delayed retransmissions, missing data, conflicts, and differences in statistical standards among multiple source raw data. As a result, when data collection is abnormal or there are inconsistencies in statistical standards across sources, spurious deviations caused by data anomalies can easily be misjudged as actual load changes, thereby affecting the formation and correction of the reporting curve.

[0005] Secondly, existing technologies often process load forecasting, declaration formation, and deviation analysis in a decentralized manner, lacking a rolling pre-verification mechanism for the declaration deadline. They cannot perform multiple rounds of verification on the generated declaration curves based on the latest data before the declaration window closes, nor can they generate executable corrective declaration data for high-risk time slots within a limited time window.

[0006] Secondly, in the enterprise-side system of electricity sales companies, it is generally not appropriate for the internal system to automatically rewrite the already determined application results after the application deadline. Existing technologies lack readily implementable mechanisms for version locking, alternative estimation, anomaly handling records, deviation risk records, and post-event attribution updates to address issues such as data distortion, interface failures, missing user reports, continuous conflicts between multi-source data, and exposure of deviation risks after the application deadline.

[0007] Furthermore, even if existing technologies include an early warning module, they often only output alarm results without further clarifying the classification rules for abnormal operating conditions, the alternative estimation methods corresponding to different abnormal levels, the triggering conditions for manual takeover, and the subsequent parameter update path. This makes it difficult for the solution to form a complete closed loop in actual implementation. Summary of the Invention

[0008] In view of the shortcomings of the existing technology, the purpose of this application is to provide a method and system for pre-verification of spot electricity sales declarations.

[0009] To achieve the above objectives, this application provides the following technical solution:

[0010] A method for pre-verification of spot electricity sales declarations includes the following steps:

[0011] S1, acquire raw data from multiple sources, including user-side electricity consumption data and transaction rule template data;

[0012] S2 performs reliable preprocessing and time alignment on multi-source raw data to obtain a standard time-series dataset and corresponding data quality labels;

[0013] S3 generates user-level baseline load curves based on standard time-series datasets and summarizes them to obtain electricity sales company-level baseline load curves;

[0014] S4 maps the benchmark load curve of the electricity sales company to the transaction rule template data to generate the initial declaration curve, and generates the time slice status identifier of the time slice corresponding to the initial declaration curve based on the current time, the declaration deadline time and the deadline protection duration.

[0015] S5. Before the application deadline, the initial application curve is pre-verified according to the preset rolling cycle. The verification load curve is generated based on the latest updated standard time series dataset. The data anomaly deviation and the actual load drift deviation are distinguished according to the preset criteria, and the set of time slices to be corrected is output.

[0016] S6. For time slices whose status is marked as correctable and are determined to be true load drift type deviations, generate correction application data, perform secondary rule verification on the correction application data, generate application output data based on the secondary rule verification results, and record the corresponding application version information.

[0017] S7, after the application deadline, will set a version lock flag for the final confirmed application version and stop automatic modification processing for the final confirmed application version; it will also take over abnormal operating conditions in a tiered manner and output alternative estimation results, abnormal handling records and version lock records;

[0018] S8, based on the final confirmed declaration version and alternative estimation results, conducts deviation risk assessment and outputs deviation risk records and risk handling prompts;

[0019] S9, based on the actual metering data of the operating day corresponding to the final confirmed declaration version, performs deviation attribution and parameter update to obtain the updated preprocessing parameters, pre-verification parameters and load modeling parameters.

[0020] In a preferred embodiment, in step S1, the multi-source raw data includes smart meter time-of-use electricity data, electricity consumption data from the electricity information collection terminal, real-time power data from the load management system, user industry attribute data from the marketing file, contract capacity data from the marketing file, user reporting data, weather data, holiday calendar data, and transaction rule template data.

[0021] The transaction rule template data includes the declaration granularity, declaration deadline, deadline protection duration, minimum adjustment step size, upper and lower limit constraints for declaration, and message format requirements.

[0022] In a preferred embodiment, step S2 involves performing reliable preprocessing and time alignment on the multi-source raw data, including: establishing a unified timeline based on the declaration granularity in the transaction rule template data; configuring source identifiers, business timestamps, and collection timestamps for each data source; performing missing detection, conflict detection, and reliability calculation on the data in the same time slice; and fusing the data in the same time slice based on the reliability of each data source in the corresponding time slice to obtain a standard time-series dataset.

[0023] Among them, the data quality label is used to characterize the data integrity label, time freshness label, cross-source consistency label, and historical stability label of the corresponding time slice.

[0024] In a preferred embodiment, step S3, generating a user-level baseline load curve, includes: classifying users based on standard time-series datasets, user profile data, and user reporting data; generating the baseline load value for each user in each time slot based on the user classification results, combined with similar daily load, recent load, reporting event correction, and weather correction; and summarizing the baseline load values ​​of each user in the same time slot to obtain the electricity sales company-level baseline load curve.

[0025] In a preferred embodiment, step S4 generates an initial declaration curve and a time slice status identifier, including: performing constraint mapping on the power sales company-level benchmark load curve according to the declaration granularity, minimum adjustment step size, and upper and lower limit constraints in the transaction rule template data to obtain the initial declaration curve;

[0026] When the current time is earlier than the time obtained by subtracting the deadline protection period from the application deadline, the time slice status flag of the corresponding time slice is set to correctable.

[0027] If the current time is not earlier than the time obtained by subtracting the protection period from the application deadline, but is earlier than the application deadline, the time slice status flag of the corresponding time slice will be set to the protected state.

[0028] When the current time reaches the application deadline, or when the final application version is confirmed, the time slice status flag of the corresponding time slice will be set to locked.

[0029] In a preferred embodiment, step S5, the rolling pre-verification includes: calculating the deviation rate between the current declaration version and the verification load curve; calculating the data quality index and load drift trend index for the corresponding time slice;

[0030] When the data quality index is lower than the preset quality threshold, or the missing rate exceeds the preset missing threshold, it is judged as a data anomaly.

[0031] When the data quality index is not lower than the preset quality threshold, the deviation rate continuously meets the preset deviation threshold condition, and any one of the preset trend threshold condition and the user-reported event consistency condition is met, it is determined to be a true load drift type deviation.

[0032] The preset quality threshold, preset missing threshold, preset deviation threshold, and preset trend threshold are configured by the parameter table and updated based on the deviation attribution results.

[0033] In a preferred embodiment, step S6 includes secondary rule verification, which includes verification of the declaration deadline time, verification of the deadline protection duration, verification of the minimum adjustment step size, verification of the upper and lower limits of the declaration, and verification of the message format.

[0034] If the current time has not entered the end protection period, and the correction declaration data passes the secondary rule verification, the correction declaration data will be encapsulated into a correction declaration message and output.

[0035] When the current time has entered the protection period, or when the corrected data fails the secondary rule verification, a review prompt message is generated;

[0036] The review prompts include the time slice to be corrected, the data to be corrected, the items that failed the verification, and the current version of the application.

[0037] In a preferred embodiment, step S7 involves tiered takeover of abnormal operating conditions, including:

[0038] Level 1 anomalies include single data source short-term delay anomalies and single data source short-term missing anomalies. For single data source short-term delay anomalies, local cached values ​​are used for alternative estimation. For single data source short-term missing anomalies, the most recent valid segment is first used for alternative estimation. When the interval between the most recent valid segment and the current time slice exceeds the preset retention time, short-time interpolation is used for alternative estimation.

[0039] Level 2 anomalies include multi-source data persistent conflict anomalies and key reporting field missing anomalies; for multi-source data persistent conflict anomalies, reference estimation results are generated based on typical daily envelopes and similar user group intervals; for key reporting field missing anomalies, reference estimation results are generated based on contract capacity boundaries and typical daily envelopes.

[0040] Level 3 anomalies include transaction interface anomalies, unavailability of the declaration service, unreadable and unwritable critical data tables, and batch data anomalies. For Level 3 anomalies, the final confirmed declaration version remains unchanged, and an anomaly handling record and manual takeover instructions are generated.

[0041] A pre-verification system for electricity spot market declaration includes:

[0042] The data access module is used to acquire raw data from multiple sources;

[0043] The trusted preprocessing module is used to perform trusted preprocessing and time alignment on multi-source raw data to obtain a standard time series dataset and corresponding data quality labels.

[0044] The baseline load modeling module is used to generate user-level baseline load curves based on standard time-series datasets and to summarize them to obtain electricity sales company-level baseline load curves.

[0045] The declaration curve generation module is used to map the benchmark load curve of the electricity sales company to the transaction rule template data, generate the initial declaration curve, and generate the time slice status identifier of the time slice corresponding to the initial declaration curve.

[0046] The rolling pre-verification module is used to perform rolling pre-verification of the initial declaration curve according to a preset rolling cycle before the declaration deadline, generate a verification load curve, distinguish between data anomaly deviation and actual load drift deviation, and output a set of time slices to be corrected.

[0047] The declaration output module is used to generate correction declaration data for time slots whose status is marked as correctable and are determined to be true load drift type deviations, perform secondary rule verification on the correction declaration data, generate declaration output data based on the secondary rule verification results, and record declaration version information.

[0048] The anomaly takeover module is used to set a version lock flag for the final confirmed application version after the application deadline, stop the automatic modification of the final confirmed application version, take over abnormal conditions in a tiered manner, and output alternative estimation results, anomaly handling records, and version lock records.

[0049] The risk assessment and attribution update module is used to conduct deviation risk assessment based on the final confirmed declaration version and alternative estimation results, and to perform deviation attribution and parameter update after obtaining the actual measurement data of the operating day corresponding to the final confirmed declaration version.

[0050] The data access module is connected to the trusted preprocessing module, which in turn is connected to the baseline load modeling module, the rolling pre-verification module, and the anomaly takeover module. The baseline load modeling module is connected to the declaration curve generation module, which is connected to the rolling pre-verification module and the declaration output module. The anomaly takeover module is connected to the risk assessment and attribution update module.

[0051] In a preferred embodiment, it also includes a rule template management module and a data storage module;

[0052] The rule template management module is used to store and distribute transaction rule template data. The transaction rule template data includes the declaration granularity, declaration deadline, deadline protection duration, minimum adjustment step size, upper and lower limit constraints of declaration, and message format requirements.

[0053] The data storage module is used to store raw data, standard time-series data, baseline load data, declaration version records, anomaly handling records, deviation risk records, and parameter configurations generated during system operation.

[0054] The risk assessment and attribution update module is also used to feed back the updated preprocessing parameters, pre-verification parameters, and load modeling parameters to the credible preprocessing module, the baseline load modeling module, and the rolling pre-verification module.

[0055] By adopting the above technical solution, the beneficial effects of the present invention are as follows:

[0056] First, by performing reliable preprocessing and time alignment on multi-source raw data, and combining data completeness, time freshness, cross-source consistency, and historical stability to form data quality labels, we can reduce spurious biases caused by data retransmission, time-lapse, missing data, and inconsistencies in cross-source standards, thereby improving the consistency and usability of standard time-series datasets.

[0057] Second, by performing rolling pre-verification according to a preset rolling cycle before the declaration deadline, and distinguishing between data anomaly deviations and actual load drift deviations, it is possible to generate corrected declaration data for high-risk time slots caused by actual load changes within the time window allowed by the rules, while reducing erroneous corrections and over-corrections caused by low-quality data.

[0058] Third, by generating time slice status identifiers based on the current time, the application deadline, and the protection period, the correction process of the application curve is matched with the application time boundary, avoiding the continued execution of inappropriate automatic modification processes after entering the protection period or after the application deadline, thus improving the timing consistency of the application output process.

[0059] Fourth, by setting a version lock flag for the final confirmed application version after the application deadline and implementing tiered takeover for abnormal operating conditions, the system can perform alternative estimations, record and trace data for data anomalies, interface anomalies, and service anomalies, and provide manual takeover prompts without automatically modifying the final confirmed application version, thereby improving the system's continuous operation capability under abnormal operating conditions.

[0060] Fifth, by conducting deviation risk assessment based on the final confirmed declaration version and alternative estimation results, and performing deviation attribution and parameter updates after obtaining the actual metering data for the corresponding operating day, the operating results can be fed back to the subsequent preprocessing, pre-verification and load modeling processes, forming a repeatable closed-loop update mechanism. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of the method flow according to the first embodiment of this application;

[0062] Figure 2 This is a schematic diagram of the system module structure according to the second embodiment of this application. Detailed Implementation

[0063] In the following description, many technical details are presented to help the reader better understand this application. However, those skilled in the art will understand that the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0065] like Figure 1As shown in the figure, this embodiment provides a method for pre-verification of electricity spot market declarations. The method includes: acquiring multi-source raw data; performing reliable preprocessing and time alignment on the multi-source raw data to obtain a standard time-series dataset and corresponding data quality labels; generating user-level benchmark load curves based on the standard time-series dataset and summarizing them to obtain electricity sales company-level benchmark load curves; mapping the electricity sales company-level benchmark load curves to transaction rule template data to generate initial declaration curves and generate time slice status identifiers for corresponding time slices; performing rolling pre-verification on the initial declaration curves according to a preset rolling cycle before the declaration deadline, distinguishing between data anomaly deviations and actual load drift deviations, and outputting a set of time slices to be corrected; generating corrected declaration data for the time slices to be corrected, generating declaration output data after secondary rule verification, and recording declaration version information; locking the final confirmed declaration version after the declaration deadline, and performing hierarchical takeover for abnormal operating conditions, outputting alternative estimation results, anomaly handling records, and version lock records; conducting deviation risk assessment based on the final confirmed declaration version and alternative estimation results, and outputting deviation risk records and risk handling prompts; performing deviation attribution and parameter updates based on the actual metering data of the operating day corresponding to the final confirmed declaration version, and obtaining updated preprocessing parameters, pre-verification parameters, and load modeling parameters.

[0066] Through the above process, this embodiment forms a closed-loop processing chain: "Multi-source raw data acquisition—reliable preprocessing and time alignment—baseline load curve generation—initial declaration curve generation—rolling pre-verification before the declaration deadline—corrected declaration data generation—anomaly-level takeover after the declaration deadline—deviation risk assessment—deviation attribution and parameter update." Specifically, the rolling pre-verification before the declaration deadline is used to verify and correct the declaration curve within the correctable time window; the anomaly-level takeover after the declaration deadline is used to complete alternative estimations, anomaly tracking, and risk warnings without automatically modifying the final confirmed declaration version, thereby avoiding the enterprise-side system's processing results being mistakenly interpreted as a direct rewrite of the confirmed declaration version.

[0067] In this embodiment, the example of a power sales company acting as an agent for industrial and commercial users to submit day-ahead spot market declarations is used for illustration. Preferably, the declaration granularity is set to minutes, the original data collection cycle is set to 5 minutes, the rolling pre-verification cycle is set to 5 minutes, and the cutoff protection duration is set to 10 minutes. The above parameters are all exemplary parameters, and in actual applications, they can be configured according to the transaction rule template data, data collection frequency, and system processing capabilities.

[0068] In this embodiment, "business timestamp" refers to the actual electricity consumption period corresponding to the original data; "collection timestamp" refers to the moment when the original data is collected or written by the system; "time slice" refers to the time interval divided according to the declaration granularity; "final confirmed declaration version" refers to the declaration version that is finally confirmed and approved before the declaration deadline and used for subsequent risk assessment; "version lock identifier" refers to the data identifier used to indicate that the final confirmed declaration version will no longer enter the automatic modification process.

[0069] The specific steps are as follows:

[0070] S1: Obtain raw data from multiple sources

[0071] This step forms the data input foundation for the pre-verification of spot electricity sales declarations. Specifically, the multi-source raw data includes time-of-use electricity data from smart meters, time-of-use electricity data from electricity information collection terminals, real-time power data from the load management system, user industry attribute data from marketing files, contract capacity data from marketing files, user reporting data, weather data, holiday calendar data, and transaction rule template data.

[0072] The user-reported data includes data on production stoppages, resumptions, maintenance, shift adjustments, and temporary energy consumption plans. The transaction rule template data includes the granularity of the application, the deadline for application, the protection period before the deadline, the minimum adjustment step size, upper and lower limits for application, and message format requirements.

[0073] Furthermore, each piece of raw data is configured with a data source identifier, business timestamp, collection timestamp, and data version number, and all types of raw data are written into the raw data table. By configuring the data source identifier and dual timestamps, the arrival time, business scope, and data version of different data sources within the same electricity consumption period can be distinguished during subsequent preprocessing, avoiding processing based solely on the order of data reception.

[0074] This step outputs multi-source raw data with data source identifier, business timestamp, and collection timestamp, which serves as the input for step S2.

[0075] S2: Reliable preprocessing and time alignment of multi-source raw data

[0076] This step transforms raw data from different sources, with different timestamps, and different data calibers into a standard time-series dataset with a unified reporting granularity. Specifically, a unified time axis is established based on the reporting granularity in the transaction rule template data, and the multi-source raw data is mapped to the corresponding time slices. For electricity-type data, it can be converted into the corresponding power value according to the time slice length; for power-type data, it can be aggregated to the corresponding time slice according to the business timestamp to which the sampling point belongs.

[0077] Furthermore, missing data detection, conflict detection, and confidence calculation are performed on the mapped data. For any data source... In time slice Credibility The following model can be used for calculation:

[0078] in, As a completeness indicator, it represents the time slice. Internal data source The ratio of the number of valid sampling points to the number of sampling points required; As an indicator of freshness; This is a cross-source consistency indicator. This serves as a historical stability indicator. , , , These are the weighting coefficients, and they satisfy... + + =1, preferably, , , , The values ​​are 0.35, 0.25, 0.25, and 0.15 respectively, and can be adjusted according to the quality of the data source and historical results.

[0079] Among them, the time freshness index The following exponential decay model can be used:

[0080]

[0081] in, The time delay between the timestamp and the end of the time slice is measured in minutes. The time decay constant is preferably 15 minutes.

[0082] Cross-source consistency index The following model can be used:

[0083]

[0084] in, For data source In time slice The power value obtained by up-mapping For each available data source in time slice The median reference value above, To prevent extremely small positive numbers with a denominator of zero, 0.01MW is preferred. Optionally, when the calculated... When the value is less than 0, its value is limited to 0 to ensure that the consistency index is within a comparable range.

[0085] Furthermore, the conflict rate between multiple data sources within the same time frame. The following model can be used for calculation:

[0086]

[0087] when Furthermore, if two consecutive time slices occur, the corresponding time slice can be marked as a conflicting time slice. The above 0.2 is only a preferred threshold and can be configured according to the user load fluctuation characteristics and the historical quality of the data source.

[0088] For the available data source set Data from the same time slot can be fused based on the reliability of each data source in the corresponding time slot to obtain a unified power value. :

[0089]

[0090] in:

[0091]

[0092] When a single data source experiences a short-term loss and the loss duration does not exceed two collection cycles, it can be supplemented using the most recent valid fragment retention method or short-term interpolation method. When the loss duration exceeds two collection cycles, the anomaly identifier is retained and passed to the subsequent rolling pre-verification and anomaly classification takeover process, instead of directly deleting the anomaly information.

[0093] This step outputs a standard time-series dataset and its corresponding data quality labels. The data quality labels include labels for data integrity, time freshness, cross-source consistency, and historical stability for each time slice.

[0094] S3: Generate user-level baseline load curves and summarize them to obtain electricity sales company-level baseline load curves.

[0095] This step is used to form a load baseline that can be used to generate the declaration curve based on the standard time-series dataset. Specifically, users are classified according to their characteristics based on the standard time-series dataset, user profile data, and user reporting data. Preferably, users can be divided into stable base load type, temperature-sensitive type, shift production type, intermittent start-stop type, and adjustable type. The above classification is used to select the participation mode of different correction amounts, and does not limit the present invention to only using the above classification methods.

[0096] For any user In time slice On the reference load The following model can be used for calculation:

[0097] in: For users Average load of the same time slice on a set of similar days; For users The weighted average load of several similar time slices is preferred, with the four most recent similar days being the preferred choice. The correction amount is determined based on user-reported events; This is a weather correction amount, which can be used for temperature-sensitive users. , These are the weighting coefficients, and they satisfy... Preferably, Take 0.6, Take 0.4; for production stoppage reporting events, Negative values ​​are acceptable; for plans involving resumption of production or temporary energy use, Positive values ​​are acceptable; for time slices with no valid reported events, 0 is acceptable.

[0098] For temperature-sensitive users, the weather correction can be modeled as follows:

[0099]

[0100] in, For time slices The corresponding ambient temperature, For users Reference temperature, This is the temperature sensitivity coefficient, expressed in MW / ℃; for non-temperature-sensitive users, the preferred value is... .

[0101] Furthermore, by aggregating the baseline load values ​​of all agent users in the same time slot, a baseline load curve at the electricity sales company level is obtained:

[0102]

[0103] in, This refers to the number of proxy users.

[0104] Optionally, to provide a fluctuation reference range for subsequent rolling pre-verification, the confidence range of the baseline load curve can also be calculated:

[0105]

[0106] in, For similar day sets in time slices The standard deviation on The confidence coefficient is 1.28, which is preferred.

[0107] This step outputs the user-level baseline load curve and the electricity sales company-level baseline load curve, which serve as the input for step S4 to generate the initial declaration curve.

[0108] S4: Generate initial declaration curve and time slice status indicators

[0109] This step converts the electricity sales company-level benchmark load curve into an initial declaration object that conforms to the requirements of the transaction rule template data. Specifically, the electricity sales company-level benchmark load curve is mapped to the transaction rule template data to generate the initial declaration curve. The mapping process considers at least the declaration granularity, minimum adjustment step size, upper and lower limit constraints for declaration, and message format requirements.

[0110] For time slices Initial declaration curve The following constraint mapping model can be used to generate it:

[0111]

[0112] in: and These are the upper and lower limits of the time slices given by the rule template or contract boundary, respectively. The minimum adjustment step size is expressed in MW. This indicates rounding to the nearest multiple of the step size.

[0113] Furthermore, based on the current time, the application deadline, and the protection period, a time slice status identifier is generated for the time slice corresponding to the initial application curve. Specifically, when the current time is earlier than the application deadline minus the protection period, the time slice status identifier for the corresponding time slice is set to the correctable state; when the current time is not earlier than the application deadline minus the protection period, but is earlier than the application deadline, the time slice status identifier for the corresponding time slice is set to the protected state; when the current time reaches the application deadline, or when the application version is finally confirmed to have been generated, the time slice status identifier for the corresponding time slice is set to the locked state.

[0114] This step outputs the initial declaration curve and time slice status indicator. The time slice status indicator allows subsequent steps to distinguish between time slices where corrected declaration data can be automatically generated, time slices requiring manual review during protection, and locked time slices that are no longer automatically modified.

[0115] S5: Rolling pre-verification before the application deadline

[0116] This step is used to repeatedly verify the initial application curve using the latest updated standard time-series dataset before the application deadline, in order to identify time slots that need correction. Specifically, the initial application curve is pre-verified on a rolling basis according to a preset rolling cycle before the application deadline. In each round of rolling pre-verification, a verification load curve is generated based on the latest updated standard time-series dataset. ,in Indicates the first Pre-checking.

[0117] Specifically, calculate the current application version. Deviation rate between the calibration load curve and the calibration load curve :

[0118]

[0119] in, For the first Each submitted version in the time slice The declared value on the above To prevent extremely small positive numbers with a denominator of zero.

[0120] Furthermore, the data quality metrics for the corresponding time slices are calculated. and load drift trend indicators Among them, data quality indicators This can be obtained by weighting the reliability of each available data source. Load drift trend indicator. The following model can be used for calculation:

[0121]

[0122] in, This refers to the time length corresponding to a reporting granularity. To distinguish between data anomaly-type deviations and actual load drift-type deviations, this embodiment adopts the following criteria: when the data quality index is lower than the preset quality threshold, or the missing proportion exceeds the preset missing threshold, it is determined to be a data anomaly-type deviation; when the data quality index is not lower than the preset quality threshold, the deviation rate continuously meets the preset deviation threshold condition, and any one of the preset trend threshold condition and the user-reported event consistency condition is met, it is determined to be an actual load drift-type deviation.

[0123] Preferably, the preset quality threshold can be 0.65, the preset missing threshold can be 0.3, the preset deviation threshold condition can be configured such that the deviation rate is not less than 0.08 and meets the requirements for two consecutive rounds of pre-verification, and the preset trend threshold can be 0.05. The above thresholds are exemplary parameters, which can be configured by the parameter table and updated based on subsequent deviation attribution results.

[0124] This step outputs the set of time slices to be corrected, the deviation type identifier, and the rolling pre-verification record, which serve as input for step S6 to generate the correction declaration data.

[0125] S6: Generate revised declaration data and generate declaration output data.

[0126] This step is used to generate correction application data for the time slots to be corrected corresponding to actual load drift type deviations, and to determine the output results through secondary rule verification. Specifically, for time slots whose status is marked as correctable and are determined to be actual load drift type deviations, correction application data is generated.

[0127] For the time slice to be corrected Correcting the submitted data The following model can be used to generate it:

[0128]

[0129] in: The declared value for the current version; For the first The verification load value obtained from the round-checking; This is the event correction amount; The influence coefficient of the current verification curve on the correction result is preferably taken as 0.6 to 0.8, for example, 0.7; This is the event correction factor, preferably between 0.5 and 1.0, for example, 0.8.

[0130] After generating the revised declaration data, a second rule verification is performed on the revised declaration data. The second rule verification includes verification of the declaration deadline, the deadline protection duration, the minimum adjustment step size, the upper and lower limits of the declaration, and the message format.

[0131] If the current time has not yet entered the protection period's expiration and the corrected application data passes the secondary rule verification, the corrected application data will be encapsulated into a corrected application message and output. If the current time has already entered the protection period's expiration, or the corrected application data fails the secondary rule verification, a review prompt message will be generated. The review prompt message includes the time slice to be corrected, the corrected application data, the items that failed verification, and the current application version information.

[0132] Optionally, to reduce version jitter caused by frequent minor changes, a new version reporting record is triggered when two or more consecutive time slices are corrected, or when the total battery offset before and after the correction exceeds a preset battery threshold. Total battery offset It can be calculated using the following formula:

[0133]

[0134] in, This refers to the number of hours corresponding to the reporting granularity, for example, 0.25 hours for minutes. The preset energy threshold is preferably set to 0.5MWh.

[0135] This step outputs the declaration data and records the corresponding declaration version information. The declaration output data can be either a revised declaration message or a review prompt message.

[0136] S7: Abnormal Classification and Takeover After the Reporting Deadline

[0137] This step is used to perform alternative estimations, record anomalies, and provide manual takeover prompts for subsequent abnormal operating conditions after the final confirmed submission version is locked. Specifically, after the submission deadline, a version lock flag will be set for the final confirmed submission version, and automatic modification processing for the final confirmed submission version will be stopped.

[0138] Furthermore, a tiered takeover system is implemented for abnormal operating conditions. Level 1 anomalies include short-term latency anomalies in a single data source and short-term missing data source anomalies. For short-term latency anomalies in a single data source, a local cached value is used for alternative estimation. For short-term missing data source anomalies, the most recent valid segment is initially used for alternative estimation; if the interval between the most recent valid segment and the current time slice exceeds a preset retention duration, short-time interpolation is used for alternative estimation. The preset retention duration can be configured to 10 minutes.

[0139] Level 2 anomalies include persistent multi-source data conflict anomalies and missing key reporting fields anomalies. For persistent multi-source data conflict anomalies, reference estimation results are generated based on typical daily envelopes and similar user group intervals; for missing key reporting fields anomalies, reference estimation results are generated based on contract capacity boundaries and typical daily envelopes.

[0140] Among them, the reference estimation interval It can be represented as:

[0141]

[0142] in, For similar daily average power, For similar daily standard deviations, This is the upper limit of capacity. The coefficient is the interval coefficient, and 1.5 is preferred.

[0143] Level 3 anomalies include transaction interface anomalies, unavailability of the declaration service, inaccessibility of critical data tables, and batch data anomalies. For Level 3 anomalies, the final confirmed declaration version remains unchanged, and an anomaly handling record and manual takeover instructions are generated.

[0144] This step outputs alternative estimation results, exception handling records, and version lock records.

[0145] S8: Deviation Risk Assessment

[0146] This step is used to assess the risk of deviation based on the alternative estimation results without modifying the final confirmed declaration version. Specifically, the deviation risk assessment is performed based on the final confirmed declaration version and the alternative estimation results.

[0147] Use alternative estimates or the latest available verification values ​​as estimated loads. And the final confirmed submission version in the time slice The declared value Calculate the deviation risk value as a benchmark. :

[0148]

[0149] in, The unit deviation risk coefficient is configured by the local rule template or the enterprise-side risk parameter table, and the unit is yuan / MWh; This represents the number of hours corresponding to the time slice.

[0150] when When the risk exceeds a preset risk threshold, or when the cumulative risk value across multiple consecutive time slots exceeds the cumulative risk threshold, a deviation risk record and risk handling prompts are generated. These prompts may include prompts for manual review, communication with key clients, adjustable user verification, and focused verification for next day's reports.

[0151] This step outputs deviation risk records and risk handling prompts.

[0152] S9: Bias Attribution and Parameter Update

[0153] This step is used to classify the causes of deviations based on the actual metering data of the operating day, and to feed the attribution results back to the preprocessing, pre-verification, and load modeling processes of subsequent operating days. Specifically, based on the actual metering data of the operating day corresponding to the final confirmed declaration version, deviation attribution and parameter updates are performed.

[0154] The actual load obtained by converting actual metering data Final confirmation of the submitted version The system compares anomaly handling records, reported version records, and user-reported data to determine the type of deviation attribution. Deviation attribution types can include prediction error, data anomaly, user temporary event, uncorrected window limitation, and interface failure.

[0155] Furthermore, the historical stability parameters of the data source are updated. For the data source... The historical stability parameters can be updated using the following model:

[0156]

[0157] in, For the data source stability parameters before the update, For the updated data source stability parameters, The effective contribution ratio of this data source during the operating day. To update the step size, a value of 0.2 is preferred.

[0158] For the deviation trigger threshold, the following update method can be optionally adopted:

[0159]

[0160] in, The preset deviation threshold before the update; The updated preset deviation threshold; The daily average deviation rate; The target deviation rate; The threshold update coefficient is preferably set to 0.1; and These are the lower and upper limits of the preset deviation threshold, respectively; This means limiting the parameter to a given upper and lower limit range.

[0161] This step outputs updated preprocessing parameters, pre-verification parameters, and load modeling parameters. These updated parameters are used for data reliability preprocessing, rolling pre-verification, and baseline load modeling on subsequent operating days.

[0162] Through the above steps, the steps in this embodiment have clear input, processing, and output relationships. Multi-source raw data, after reliable preprocessing, forms a standard time-series dataset; this dataset is then used for load modeling and rolling pre-verification; the rolling pre-verification results are output for reporting; after the reporting deadline, anomaly classification and takeover, along with deviation risk assessment, lead to deviation attribution and parameter updates; the updated parameters then influence the data preprocessing, load modeling, and pre-verification processes for subsequent operating days. This avoids the problem of simply setting up load forecasting, reporting output, and risk warning in parallel.

[0163] like Figure 2 As shown, this embodiment provides a pre-verification system for spot electricity sales declarations. The system includes a data access module, a rule template management module, a reliable preprocessing module, a baseline load modeling module, a declaration curve generation module, a rolling pre-verification module, a declaration output module, an anomaly takeover module, a risk assessment and attribution update module, and a data storage module.

[0164] Through the above system architecture, the output of the data access module enters the trusted preprocessing module; the output of the trusted preprocessing module enters the baseline load modeling module, the rolling pre-verification module, and the anomaly takeover module, respectively; the output of the baseline load modeling module enters the declaration curve generation module; the output of the declaration curve generation module enters the rolling pre-verification module and the declaration output module; the output of the anomaly takeover module enters the risk assessment and attribution update module; the risk assessment and attribution update module feeds back the updated parameters to the trusted preprocessing module, the baseline load modeling module, and the rolling pre-verification module. Thus, the system forms a closed loop where data flow, control flow, and parameter flow are interconnected, rather than a simple parallel arrangement of multiple functional modules.

[0165] Furthermore, the system can be deployed in the electricity sales company's transaction support environment, preferably including an application server, a time-series database, a relational database, a message queue, and an external interface gateway. The system implements the method of Embodiment 1 by executing program instructions stored in a storage medium through a processor.

[0166] Specifically, the data access module is used to acquire raw data from multiple sources. The data access module can obtain raw data from smart meter acquisition interfaces, electricity information acquisition terminal interfaces, load management system interfaces, marketing file interfaces, user reporting interfaces, weather interfaces, holiday calendar interfaces, and transaction rule interfaces. The data access module writes the acquired data into the data storage module and configures the data source identifier, business timestamp, acquisition timestamp, and data version number.

[0167] The rule template management module is used to store and distribute transaction rule template data. This data includes the granularity of the declaration, the declaration deadline, the protection period, the minimum adjustment step size, upper and lower limits for declarations, and message format requirements. Furthermore, the rule template management module can provide unified rule parameters to the declaration curve generation module, the rolling pre-verification module, the declaration output module, and the risk assessment and attribution update module, enabling all modules to operate within the same rule boundaries.

[0168] The trusted preprocessing module is connected to the data access module and is used to perform trusted preprocessing and time alignment on multi-source raw data to obtain a standard time-series dataset and corresponding data quality labels. Specifically, the trusted preprocessing module performs processing according to the trustworthiness model, conflict rate model, and weighted fusion model in S2 of Example 1, and writes the standard time-series dataset into the data storage module. When the trusted preprocessing module detects missing data, cross-source conflicts, or low-trust data, it passes the corresponding data quality labels to the rolling pre-verification module and the anomaly takeover module.

[0169] The baseline load modeling module is connected to the reliable preprocessing module to generate user-level baseline load curves based on standard time-series datasets and to summarize them to obtain electricity sales company-level baseline load curves. Specifically, the baseline load modeling module combines user profile data, user-reported data, similar daily loads, recent loads, and weather corrections to perform modeling, and writes the modeling results to the data storage module.

[0170] The declaration curve generation module is connected to the benchmark load modeling module and the rule template management module. It is used to map the electricity sales company-level benchmark load curve to the transaction rule template data, generate the initial declaration curve, and generate and associate the time slice status identifier of the time slice corresponding to the initial declaration curve. Furthermore, the declaration curve generation module generates a declaration version record and writes the declaration version record to the data storage module.

[0171] The rolling pre-verification module is connected to the reliable preprocessing module, the baseline load modeling module, and the declaration curve generation module, respectively. It performs rolling pre-verification of the initial declaration curve at a preset rolling cycle before the declaration deadline, generates a verification load curve, distinguishes between data anomaly deviations and actual load drift deviations, and outputs a set of time slices to be corrected. The set of time slices to be corrected output by the rolling pre-verification module is then passed to the declaration output module.

[0172] The declaration output module connects to the rolling pre-verification module and the rule template management module. It generates corrective declaration data for time slots whose status is marked as correctable and determined to be true load drift type deviations. It performs secondary rule verification on the corrective declaration data, generates declaration output data based on the secondary rule verification results, and records the declaration version information. Specifically, when the corrective declaration data passes the secondary rule verification and the current time has not yet entered the cutoff protection period, the declaration output module encapsulates the corrective declaration data into a corrective declaration message; when the corrective declaration data fails the secondary rule verification or the current time has already entered the cutoff protection period, the declaration output module generates a review prompt message. The declaration output module can communicate with the external transaction support interface through an external interface gateway and record the message sending time, interface response result, and version confirmation information.

[0173] The anomaly takeover module connects to the trusted preprocessing module, rolling pre-verification module, declaration output module, and data storage module. After the declaration deadline, it sets a version lock flag on the final confirmed declaration version, stops automatic modification of the final confirmed declaration version, performs tiered takeover of abnormal operating conditions, and outputs alternative estimation results, anomaly handling records, and version lock records. Based on the anomaly level, the anomaly takeover module calls corresponding data from local cache values, the most recent valid fragment, short-time interpolation, typical daily envelope, contract capacity boundaries, and similar user group intervals to generate alternative estimation results or manual takeover instructions.

[0174] The risk assessment and attribution update module is connected to the anomaly takeover module, rule template management module, and data storage module. It is used to conduct deviation risk assessments based on the final confirmed declaration version and alternative estimation results. After obtaining the actual metering data for the operating day corresponding to the final confirmed declaration version, it performs deviation attribution and parameter updates. Specifically, the risk assessment and attribution update module generates deviation risk records and risk handling prompts based on the risk model, and generates updated preprocessing parameters, pre-verification parameters, and load modeling parameters based on the parameter update model.

[0175] The data storage module stores raw data, standard time-series data, baseline load data, application version records, anomaly handling records, deviation risk records, and parameter configurations generated during system operation. Preferably, raw time-series data and standard time-series data are stored in a time-series database, while user profile data, application version records, anomaly handling records, deviation risk records, and parameter configurations are stored in a relational database. By establishing associations between raw data, standard time-series data, and application version records, the system can trace back the source data, processing parameters, verification results, and output results of any application version.

[0176] Through the aforementioned module connections, the data flow proceeds sequentially from the data access module to the trusted preprocessing module, the baseline load modeling module, the declaration curve generation module, the rolling pre-verification module, and the declaration output module. Anomalies after the declaration deadline are handled by the anomaly control module and then enter the risk assessment and attribution update module. The risk assessment and attribution update module feeds back the updated parameters to the trusted preprocessing module, the baseline load modeling module, and the rolling pre-verification module, thus forming a closed loop of data processing, declaration output, anomaly control, and parameter updates.

[0177] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any ordinary changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for pre-verification of spot electricity sales declarations, characterized in that, Includes the following steps: S1, acquire raw data from multiple sources, including user-side electricity consumption data and transaction rule template data; S2 performs reliable preprocessing and time alignment on multi-source raw data to obtain a standard time-series dataset and corresponding data quality labels; S3 generates user-level baseline load curves based on standard time-series datasets and summarizes them to obtain electricity sales company-level baseline load curves; S4 maps the benchmark load curve of the electricity sales company to the transaction rule template data to generate the initial declaration curve, and generates the time slice status identifier of the time slice corresponding to the initial declaration curve based on the current time, the declaration deadline time and the deadline protection duration. S5. Before the application deadline, the initial application curve is pre-verified according to the preset rolling cycle. The verification load curve is generated based on the latest updated standard time series dataset. The data anomaly deviation and the actual load drift deviation are distinguished according to the preset criteria, and the set of time slices to be corrected is output. S6. For time slices whose status is marked as correctable and are determined to be true load drift type deviations, generate correction application data, perform secondary rule verification on the correction application data, generate application output data based on the secondary rule verification results, and record the corresponding application version information. S7. After the application deadline, the final confirmed application version will be locked, and automatic modification processing for the final confirmed application version will be stopped. Implement tiered takeover for abnormal operating conditions, and output alternative estimation results, anomaly handling records, and version lock records; S8, based on the final confirmed declaration version and alternative estimation results, conducts deviation risk assessment and outputs deviation risk records and risk handling prompts; S9, based on the actual metering data of the operating day corresponding to the final confirmed declaration version, performs deviation attribution and parameter update to obtain the updated preprocessing parameters, pre-verification parameters and load modeling parameters.

2. The pre-verification method for spot electricity sales declaration according to claim 1, characterized in that, In step S1, the multi-source raw data includes smart meter time-of-use electricity data, electricity information collection terminal time-of-use electricity data, load management system real-time power data, user industry attribute data in marketing files, contract capacity data in marketing files, user reporting data, weather data, holiday calendar data, and transaction rule template data. The transaction rule template data includes the declaration granularity, declaration deadline, deadline protection duration, minimum adjustment step size, upper and lower limit constraints for declaration, and message format requirements.

3. The pre-verification method for spot electricity sales declaration according to claim 2, characterized in that, In step S2, the multi-source raw data undergoes reliable preprocessing and time alignment, including: establishing a unified timeline based on the declaration granularity in the transaction rule template data; configuring source identifiers, business timestamps, and collection timestamps for each data source; performing missing detection, conflict detection, and reliability calculation on data in the same time slice; and fusing data in the same time slice based on the reliability of each data source in the corresponding time slice to obtain a standard time-series dataset. Among them, the data quality label is used to characterize the data integrity label, time freshness label, cross-source consistency label, and historical stability label of the corresponding time slice.

4. The pre-verification method for spot electricity sales declaration according to claim 3, characterized in that, In step S3, generating a user-level baseline load curve includes: classifying users based on standard time-series datasets, user profile data, and user reporting data; generating the baseline load value for each user in each time slot based on the user classification results, combined with similar daily load, recent load, reporting event correction amount, and weather correction amount; and summarizing the baseline load values ​​of each user in the same time slot to obtain the electricity sales company-level baseline load curve.

5. The pre-verification method for spot electricity sales declaration according to claim 4, characterized in that, In step S4, generating the initial declaration curve and time slice status identifier includes: performing constraint mapping on the power sales company-level benchmark load curve according to the declaration granularity, minimum adjustment step size and declaration upper and lower limit constraints in the transaction rule template data to obtain the initial declaration curve; When the current time is earlier than the time obtained by subtracting the deadline protection period from the application deadline, the time slice status flag of the corresponding time slice is set to correctable. If the current time is not earlier than the time obtained by subtracting the protection period from the application deadline, but is earlier than the application deadline, the time slice status flag of the corresponding time slice will be set to the protected state. When the current time reaches the application deadline, or when the final application version is confirmed, the time slice status flag of the corresponding time slice will be set to locked.

6. The pre-verification method for spot electricity sales declaration according to claim 5, characterized in that, In step S5, the rolling pre-verification includes: calculating the deviation rate between the current submitted version and the verification load curve; and calculating the data quality index and load drift trend index for the corresponding time slice. When the data quality index is lower than the preset quality threshold, or the missing rate exceeds the preset missing threshold, it is judged as a data anomaly. When the data quality index is not lower than the preset quality threshold, the deviation rate continuously meets the preset deviation threshold condition, and any one of the preset trend threshold condition and the user-reported event consistency condition is met, it is determined to be a true load drift type deviation. The preset quality threshold, preset missing threshold, preset deviation threshold, and preset trend threshold are configured by the parameter table and updated based on the deviation attribution results.

7. The pre-verification method for spot electricity sales declaration according to claim 6, characterized in that, In step S6, the secondary rule verification includes verification of the declaration deadline time, verification of the deadline protection duration, verification of the minimum adjustment step size, verification of the upper and lower limits of the declaration, and verification of the message format. If the current time has not entered the end protection period, and the correction declaration data passes the secondary rule verification, the correction declaration data will be encapsulated into a correction declaration message and output. When the current time has entered the protection period, or when the corrected data fails the secondary rule verification, a review prompt message is generated; The review prompts include the time slice to be corrected, the data to be corrected, the items that failed the verification, and the current version of the application.

8. The pre-verification method for spot electricity sales declaration according to claim 7, characterized in that, In step S7, the abnormal operating conditions are handled through graded takeover, including: Level 1 anomalies include single data source short-term delay anomalies and single data source short-term missing anomalies. For single data source short-term delay anomalies, local cached values ​​are used for alternative estimation. For single data source short-term missing anomalies, the most recent valid segment is first used for alternative estimation. When the interval between the most recent valid segment and the current time slice exceeds the preset retention time, short-time interpolation is used for alternative estimation. Level 2 anomalies include multi-source data persistent conflict anomalies and key reporting field missing anomalies; for multi-source data persistent conflict anomalies, reference estimation results are generated based on typical daily envelopes and similar user group intervals; for key reporting field missing anomalies, reference estimation results are generated based on contract capacity boundaries and typical daily envelopes. Level 3 anomalies include transaction interface anomalies, unavailability of the declaration service, unreadable and unwritable critical data tables, and batch data anomalies. For Level 3 anomalies, the final confirmed declaration version remains unchanged, and an anomaly handling record and manual takeover instructions are generated.

9. A pre-verification system for spot electricity sales declaration, characterized in that, include: The data access module is used to acquire raw data from multiple sources; The trusted preprocessing module is used to perform trusted preprocessing and time alignment on multi-source raw data to obtain a standard time series dataset and corresponding data quality labels. The baseline load modeling module is used to generate user-level baseline load curves based on standard time-series datasets and to summarize them to obtain electricity sales company-level baseline load curves. The declaration curve generation module is used to map the benchmark load curve of the electricity sales company to the transaction rule template data, generate the initial declaration curve, and generate the time slice status identifier of the time slice corresponding to the initial declaration curve. The rolling pre-verification module is used to perform rolling pre-verification of the initial declaration curve according to a preset rolling cycle before the declaration deadline, generate a verification load curve, distinguish between data anomaly deviation and actual load drift deviation, and output a set of time slices to be corrected. The declaration output module is used to generate correction declaration data for time slots whose status is marked as correctable and are determined to be true load drift type deviations, perform secondary rule verification on the correction declaration data, generate declaration output data based on the secondary rule verification results, and record declaration version information. The anomaly takeover module is used to set a version lock flag for the final confirmed application version after the application deadline, stop the automatic modification process of the final confirmed application version, take over the abnormal working conditions in a graded manner, and output alternative estimation results, anomaly handling records and version lock records. The risk assessment and attribution update module is used to conduct deviation risk assessment based on the final confirmed declaration version and alternative estimation results, and to perform deviation attribution and parameter update after obtaining the actual measurement data of the operating day corresponding to the final confirmed declaration version. The data access module is connected to the trusted preprocessing module, which in turn is connected to the baseline load modeling module, the rolling pre-verification module, and the anomaly takeover module. The baseline load modeling module is connected to the declaration curve generation module, which is connected to the rolling pre-verification module and the declaration output module. The anomaly takeover module is connected to the risk assessment and attribution update module.

10. The pre-verification system for spot electricity sales declaration according to claim 9, characterized in that, It also includes a rule template management module and a data storage module; The rule template management module is used to store and distribute transaction rule template data. The transaction rule template data includes the declaration granularity, declaration deadline, deadline protection duration, minimum adjustment step size, upper and lower limit constraints of declaration, and message format requirements. The data storage module is used to store raw data, standard time-series data, baseline load data, declaration version records, anomaly handling records, deviation risk records, and parameter configurations generated during system operation. The risk assessment and attribution update module is also used to feed back the updated preprocessing parameters, pre-verification parameters, and load modeling parameters to the credible preprocessing module, the baseline load modeling module, and the rolling pre-verification module.

Images