A highly automated electricity retailer bidding system and method

Abstract

The present application relates to the technical field of power market transaction data processing, and particularly relates to a highly automated power selling company bidding system and method thereof. The method comprises: receiving declaration window trigger information, power transaction data, user contract constraint parameters, user side load curve, opponent historical bidding library and market rule configuration, and binding to generate declaration task context; extracting historical bidding data to generate opponent bidding quantity and price prediction results, and converting the user contract constraint parameters and the user side load curve into time period level executable response boundary; aggregating to generate a reportable resource envelope and a candidate bidding quantity and price combination; generating resource occupation locking records and quantity and price declaration forms after rule adaptation and resource occupation conflict verification; generating backboard samples after clearing and updating opponent strategy prediction model version. The present application effectively improves the consistency of bidding declaration data connection, resource occupation record and clearing backboard processing.

Description

Technical Field

[0001] This invention relates to the field of electricity market transaction data processing technology, and in particular to a highly automated bidding system and method for electricity sales companies. Background Technology

[0002] In the field of electricity market transaction data processing technology, existing solutions for electricity sales companies to participate in bidding on electricity trading platforms typically acquire historical data, real-time data, market price changes, cost parameters, and bidding performance through data collection and processing modules. These are then combined with market analysis and forecasting, cost accounting and benefit assessment, risk assessment and optimization, bidding model units, and automatic execution and monitoring modules to generate bidding requests. While such solutions can complete basic processing such as market price forecasting, bidding volume calculation, bidding price generation, and bidding request submission in conventional electricity sales bidding scenarios, they are prone to limitations in scenarios involving demand response users, user contractual constraint parameters, multiple market channels, and the feedback of market clearing results. These limitations include asynchronous contractual constraints and trading periods, inconsistencies between user-controllable load and market rule configurations, and discontinuities in the connection between clearing results and subsequent forecasting model versions.

[0003] Existing solutions largely rely on historical data, real-time data, market price forecasts, cost-benefit calculations, and fixed bidding strategies. User contract constraint parameters are typically used as input factors in compensation calculations or bid volume calculations, while market rule configurations are usually used as format or price limit conditions before bid submission. When the trading period, market type, contract version, market rule version, or user-side load curve changes, there is a lack of trading period-level state continuity between user contract constraint parameters and candidate bid volume-price combinations. Furthermore, the occupancy status of user-controllable load across different market channels is difficult to maintain consistency with the volume-price declaration generation process, easily leading to discontinuities in bid volume source records and difficulty in tracing resource occupancy status.

[0004] Regarding the joint processing of user contract constraint parameters, user-side load curves, competitor historical bid databases, market rule configurations, quantity and price declaration forms, and market clearing results, existing technologies still suffer from common shortcomings in the transaction period binding, rule adaptation, resource occupancy status recording, and clearing result feedback stages. Therefore, it is necessary to address the challenge of effectively linking user contract constraint parameters, user-side load curves, competitor historical bid databases, and market rule configurations to generate quantity and price declaration forms and feedback samples, specifically for the bidding and auction scenarios of electricity sales companies. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a highly automated bidding method for electricity sales companies, comprising:

[0006] S100 receives the application window trigger information, power transaction data, user contract constraint parameters, user-side load curve, counterparty historical bidding database and market rule configuration, and binds them according to transaction period, market type, contract version, market rule version and model version to generate application task context;

[0007] S200. Based on the context of the application task, extract historical bidding data from the competitor's historical bidding database to generate competitor bidding quantity and price prediction results; and convert the interruptible duration, minimum continuous interruption time, maximum daily interruption count, and base load guaranteed electricity in the user contract constraint parameters with the user-side load curve to generate a time-period-level executable response boundary; specifically including:

[0008] Based on the user-side load curve and the base load minimum power, a load reduction limit can be generated;

[0009] A continuous response state is generated based on the interruptible duration and the minimum continuous interruption time.

[0010] The remaining number of interruptions is generated based on the maximum number of interruptions per day;

[0011] The time-level executable response boundary is generated based on the scalable load limit, the continuous response status, and the remaining number of interruptions.

[0012] S300. Based on the time-level executable response boundary, aggregate the user controllable load of multiple demand response users to generate a resource envelope that can be declared, and generate a candidate bid quantity and price combination based on the resource envelope that can be declared and the opponent's bid quantity and price prediction results.

[0013] S400. Based on the declaration time granularity, minimum declaration capacity and continuous response requirements in the market rule configuration, perform rule adaptation and resource occupation conflict verification on the candidate bid quantity-price combination, and generate resource occupation lock record and quantity-price declaration form;

[0014] S500: Send the quantity and price declaration form to the power trading platform, receive the clearing result after market clearing, generate a return sample containing prediction deviation and performance deviation based on the quantity and price declaration form, the clearing result and the resource occupation lock record, and update the counterparty strategy prediction model version based on the return sample.

[0015] Furthermore, the context of the application task includes task identifier, trading day, trading session, market type, data source, contract version, market rule version, counterparty strategy prediction model version, and data validity period;

[0016] The contract version is bound to the user contract constraint parameters, the market rule version is bound to the market rule configuration, and the opponent strategy prediction model version is bound to the opponent historical bid database.

[0017] Furthermore, historical bidding data is extracted from the competitor's historical bidding database to generate competitor bidding volume and price prediction results, including:

[0018] Based on the trading period, market type, historical clearing status, supply and demand status, and identification of similar electricity sellers, historical bidding data is extracted from the counterparty's historical bidding database.

[0019] The historical bid volume, historical bid price, historical clearing price, and historical transaction volume in the historical bidding data are grouped and processed to generate the opponent's bid volume and price prediction results.

[0020] Furthermore, the competitor's bid volume and price prediction results are generated, including:

[0021] The counterparty strategy prediction module reads historical bidding data from the counterparty historical bidding database based on the transaction period, market type, data source, and counterparty strategy prediction model version in the context of the declaration task.

[0022] The historical bidding data includes the identifiers of similar electricity sellers, trading days, trading hours, market types, historical bid volumes, historical bid prices, historical clearing prices, historical transaction volumes, historical clearing status, and supply and demand status.

[0023] The counterparty strategy prediction module groups the data according to trading time, market type, historical clearing status, supply and demand status, and similar electricity seller identifiers. It generates grouped statistical values ​​for historical bid volume, historical bid price, historical clearing price, and historical transaction volume, and writes them into the counterparty bid volume and price prediction results.

[0024] The counterparty bid volume and price prediction results include the trading period, market type, identification of similar electricity sales entities, predicted counterparty bid volume, predicted price range, and historical clearing status reference values.

[0025] When there is no matching trading session record in the opponent's historical bid database, downgrade extraction is performed according to adjacent trading sessions and the same market type, and the sample downgrade status is written into the opponent's bid volume and price prediction results.

[0026] Furthermore, a time-level executable response boundary is generated, including:

[0027] The contract constraint translation module receives user contract constraint parameters, contract version, and user-side load curve;

[0028] First, the load sequence corresponding to the time range is extracted from the user-side load curve based on the transaction period. Then, the load sequence is compared with the base load guarantee power to generate the base load guarantee status.

[0029] When the load value in the load sequence is higher than the base load reserve, the upper limit of the load that can be reduced is generated based on the difference between the load value and the base load reserve.

[0030] When the load value in the load sequence is not higher than the base load reserve, the upper limit of the load that can be reduced is recorded as 0, and the base load reserve status is written as non-reducible.

[0031] The contract constraint translation module reads the duration of the transaction period and the declaration time granularity in the market rule configuration, maps the interruptible duration to the number of time slices that can be covered, and maps the minimum continuous interruption time to the number of consecutive time slices.

[0032] When the number of time slices that can be covered within the current trading session is greater than or equal to the number of consecutive time slices, a continuous response status is generated as responsive.

[0033] When the number of time slices that can be covered in the current trading session is less than the number of consecutive time slices, the continuous response status is generated as unresponsive.

[0034] The contract constraint translation module reads the user identifier and transaction time period from the daily occupied records, calculates the number of interruptions for the corresponding user on that day, and generates the remaining number of interruptions by subtracting the number of interruptions from the maximum number of interruptions per day.

[0035] The time-level executable response boundary includes user identifier, transaction time period, load reduction limit, continuous response status, remaining interruption count, base load guarantee status, and availability status.

[0036] Furthermore, based on the time-level executable response boundary, the user-controllable load of multiple demand response users is aggregated to generate a resource envelope that can be claimed, including:

[0037] Read all available time-level executable response boundaries based on the transaction time period in the task declaration context; aggregate the load reduction limits for each demand response user to generate the declared electricity limit;

[0038] Aggregate the minimum callable power or the minimum response power recorded in the contract for each demand response user to generate a lower limit for the claimable power.

[0039] Match the continuous response status. When all users participating in the aggregation meet the continuous response requirements during the transaction period, generate a continuous response requirement met status.

[0040] When one of the users' continuous response statuses is unresponsive, that user will not be included in this aggregation; the resource envelope generation module also reads the remaining number of interruptions and the base load backup status;

[0041] When a user's remaining interruption attempts are 0, that user will not participate in the aggregation of the claimable power limit;

[0042] When the base load of a demand response user is in a non-reducible state, the user's maximum reduceable load for the current trading session is written as 0.

[0043] The declared resource package includes the transaction period, the upper limit of declared electricity volume, the lower limit of declared electricity volume, the continuous response requirement satisfaction status, and the user availability status.

[0044] Further, the generation of candidate bid quantity-price combinations includes:

[0045] Multiple declared electricity volume records are generated between the lower limit and the upper limit of the declared electricity volume. Then, the predicted bid volume and predicted price range of the opponent are read from the opponent's bid volume and price prediction results. The declared electricity volume records are matched with the corresponding bid price records to form multiple candidate bid volume and price combinations.

[0046] Each candidate bid quantity and price combination includes the trading period, market type, declared electricity volume, declared price, corresponding user identifier set, available resource envelope version, and counterparty bid quantity and price prediction result version;

[0047] When the compensation price field is missing, the resource envelope generation module writes the candidate combination corresponding to the user into the compensation price missing status and excludes the user's controllable load from the current candidate combination.

[0048] Furthermore, the resource occupancy conflict verification includes:

[0049] The user identifier, transaction period, and user controllable load corresponding to the candidate bid quantity and price combination are matched with the user identifier, transaction period, and user controllable load in the generated resource occupancy lock record;

[0050] When a record with a locked status is matched, a resource usage conflict record is generated;

[0051] When no record with a locked status is found, the resource occupancy lock record is generated;

[0052] The resource occupancy lock record includes user ID, transaction time period, target market channel, electricity consumption, lock validity period, occupancy status, and release conditions.

[0053] Furthermore, the return sample includes the trading period, market type, target market channel, order form version, order volume, order price, predicted counterparty bid volume, actual transaction volume, actual transaction price, prediction deviation, performance deviation, resource occupancy status, and model version;

[0054] The prediction deviation is generated by the predicted counterparty bid volume and the actual transaction volume;

[0055] The performance deviation is generated by the resource occupancy status, the declared electricity volume, and the actual transaction volume.

[0056] The opponent strategy prediction model version is updated based on the prediction deviation, the performance deviation, and the model version.

[0057] Furthermore, a highly automated bidding system for electricity sales companies includes: a task declaration context generation module, a prediction and boundary generation module, a resource envelope and combination generation module, a rule adaptation and resource occupancy locking module, a quantity and price declaration form generation module, and a feedback sample and model version update module; the system is used to implement the methods described in any of the above-mentioned embodiments.

[0058] The key innovations of this invention include:

[0059] (1) Bind the application window trigger information, power transaction data, user contract constraint parameters, user-side load curve, counterparty historical bid database and market rule configuration according to the transaction period, market type, contract version, market rule version and model version to form the application task context, and make the subsequent counterparty bid quantity and price prediction, contract constraint conversion processing and market rule adaptation refer to the same task record.

[0060] (2) Based on the context of the application task, extract historical bidding data from the historical bidding database of the opponent and generate the prediction results of the opponent's bidding volume and price; and convert the interruptible duration, minimum continuous interruption time, maximum number of interruptions per day and base load guaranteed power in the user contract constraint parameters with the user-side load curve to form a time period-level executable response boundary, and then aggregate the time period-level executable response boundary to generate the application resource envelope.

[0061] (3) Based on the declaration time granularity, minimum declaration capacity and continuous response requirements in the market rule configuration, the candidate bid quantity and price combination is adapted to the rules and resource occupation conflict is verified to generate resource occupation lock record and quantity and price declaration form; and after market clearing, a return sample containing prediction deviation and performance deviation is generated based on the quantity and price declaration form, the clearing result and the resource occupation lock record, and the opponent strategy prediction model version is updated.

[0062] The following are its main beneficial effects:

[0063] (1) In response to the problem that the contract version, market rule version and model version are easily discontinuous with the transaction period in the existing scheme, the transaction period, market type, contract version, market rule version and model version are bound by the task declaration context, so that the user's contract constraint parameters, market rule configuration and counterparty historical bidding database can be called by subsequent steps under the same task record, forming a traceable data source relationship.

[0064] (2) In view of the problem that the user contract constraint parameters in the existing scheme are usually used as inputs for compensation calculation or bid electricity calculation, making it difficult to form a transaction period-level status record, the interruptible duration, minimum continuous interruption time, maximum number of daily interruptions and base load guarantee electricity are converted with the user-side load curve to form a period-level executable response boundary that includes the upper limit of load reduction, continuous response status, remaining number of interruptions and base load guarantee status, and provides resource-side input for the declared resource envelope and candidate bid quantity and price combination.

[0065] (3) In response to the problem that the occupancy status of user controllable load in multiple market channels is difficult to keep consistent with the quantity and price declaration form generation process in the existing scheme, the candidate bidding quantity and price combination is adapted by configuring market rules, and resource occupancy conflict is verified for user identifier, transaction period and user controllable load to form resource occupancy lock record and quantity and price declaration form; after market clearing, the clearing result is bound with the resource occupancy lock record to generate a return sample, so that the prediction deviation and performance deviation are entered into the counterparty strategy prediction model version update record. Attached Figure Description

[0066] Figure 1 A flowchart illustrating a highly automated bidding method for electricity sales companies, provided as an embodiment of this application;

[0067] Figure 2 This is a structural block diagram of a highly automated bidding system for electricity sales companies, provided as an embodiment of this application. Detailed Implementation

[0068] Example 1: Refer to Figure 1 This is a flowchart illustrating a highly automated bidding method for electricity sales companies provided in an embodiment of the present invention. The process may include at least steps S100-S500:

[0069] S100 receives the application window trigger information, power transaction data, user contract constraint parameters, user-side load curve, counterparty historical bidding database and market rule configuration, and binds them according to transaction period, market type, contract version, market rule version and model version to generate application task context;

[0070] S200. Based on the context of the application task, extract historical bidding data from the competitor's historical bidding database to generate competitor bidding quantity and price prediction results; and convert the interruptible duration, minimum continuous interruption time, maximum number of daily interruptions and base load guaranteed electricity in the user contract constraint parameters with the user-side load curve to generate time-level executable response boundaries.

[0071] S300. Based on the time-level executable response boundary, aggregate the user controllable load of multiple demand response users to generate a resource envelope that can be declared, and generate a candidate bid quantity and price combination based on the resource envelope that can be declared and the opponent's bid quantity and price prediction results.

[0072] S400. Based on the declaration time granularity, minimum declaration capacity and continuous response requirements in the market rule configuration, perform rule adaptation and resource occupation conflict verification on the candidate bid quantity-price combination, and generate resource occupation lock record and quantity-price declaration form;

[0073] S500: Send the quantity and price declaration form to the power trading platform, receive the clearing result after market clearing, generate a return sample containing prediction deviation and performance deviation based on the quantity and price declaration form, the clearing result and the resource occupation lock record, and update the counterparty strategy prediction model version based on the return sample.

[0074] S100 receives the application window trigger information, power transaction data, user contract constraint parameters, user-side load curves, counterparty historical bidding database and market rule configuration, and binds them according to transaction period, market type, contract version, market rule version and model version to generate the application task context.

[0075] In this embodiment, S100 is executed by the application task context generation module, which is deployed in the business processing server of the electricity sales company's bidding system and connected to the power trading platform interface, contract management database, user-side load data interface, counterparty historical bid database, and market rule configuration database. The application window trigger information consists of a trigger record composed of the transaction batch notification issued by the power trading platform, the application window start time, the application window end time, the transaction day, the transaction period, and the market type; the power trading data consists of historical clearing data, historical application volume, historical application price, historical clearing price, historical transaction volume, and transaction receipt records that the electricity sales company can read; the user contract constraint parameters are the interruptible duration, minimum continuous interruption time, maximum number of daily interruptions, base load guaranteed volume, and compensation price recorded in the demand response contract signed with the demand response user; the user-side load curve is the user electricity load sequence recorded according to the sampling time; the market rule configuration includes the application time granularity, minimum application capacity, bid accuracy, price upper and lower limits, continuous response requirements, and deviation assessment rules corresponding to different market channels.

[0076] The declaration window trigger information can be sent by the power trading platform via an interface, or it can be automatically read by the power sales company's bidding system at a preset time based on the transaction calendar and declaration window configuration. The power trading data can come from the power trading platform's historical transaction records or from the power sales company's internal transaction ledger. The user contract constraint parameters can come from the contract management database or the demand response contract ledger. The user-side load curve can come from user-side smart meters, electricity marketing systems, or load aggregation units. The counterparty historical bidding database is used to store the declared electricity volume, declared price, transaction volume, and clearing status of similar power sales entities during historical trading periods. The market rule configuration can be maintained by the market rule configuration database, and a new market rule version can be generated each time the rule version changes.

[0077] Specifically, after receiving the application window trigger information, the application task context generation module first parses the transaction day, transaction period, and market type in the application window trigger information; then, based on the transaction day and transaction period, it reads the power transaction data and user-side load curve within the corresponding time range; then, based on the market type, it reads the corresponding market rule configuration; then, based on the demand response user identifier, it reads the user contract constraint parameters that are within the validity period; finally, it reads the currently callable counterparty strategy prediction model version. After the above reading actions are completed, the application task context generation module writes the transaction day, transaction period, market type, data source, contract version, market rule version, counterparty strategy prediction model version, and data validity period into the same task record, generating the application task context.

[0078] In one implementation, the data version includes a contract version, a market rule version, and a model version. The contract version is bound to the user contract constraint parameters, the market rule version is bound to the market rule configuration, and the model version is bound to the opponent's historical bidding database and opponent strategy prediction model. The binding process includes using a task identifier as the primary key and writing the transaction day, transaction period, market type, data source, contract version, market rule version, opponent strategy prediction model version, and data validity period into the same application task record. After the application task record is generated, subsequent steps S200, S300, S400, and S500 all reference the task identifier to read the same batch of data and rules.

[0079] In another implementation, the application task context generation module compares the validity period of the input data. If the contract version of the user's contract constraint parameters is not within the validity period corresponding to the transaction period, the corresponding demand response user is written to the contract expired state, and the demand response user is marked as not allowed to enter the subsequent application resource envelope; if the market rule version in the market rule configuration does not match the market type, the corresponding market channel is written to the market rule adaptation failure state; if there is a sampling gap in the user-side load curve during the transaction period, the original load field is retained and a data missing state is generated. All of the above states are written into the application task context for use by S200 and S400.

[0080] In one specific implementation process, the electricity sales company's bidding system receives a notification from the power trading platform at 09:30 on trading day D, indicating the application window for the 10:00-11:00 trading period. The application task context generation module reads the day-ahead spot market type corresponding to this trading period, the contract versions and user-side load curves of the three demand response users, and the market rule version corresponding to this market type. If the validity period of the contract version of one of the demand response users covers 10:00-11:00, its user identifier, contract version, base load minimum electricity volume, and interruptible duration are written into the application task context. If the contract version of another demand response user expires at 00:00 on the same day, the contract expiration status is written into the application task context.

[0081] After the task context is generated, its recorded content includes task identifier, trading day, trading period, market type, data source, contract version, market rule version, counterparty strategy prediction model version, and data validity period; the task identifier serves as a data index for subsequent steps; the trading period and market type are used by S200 to extract historical bidding data from the counterparty's historical bidding database; the contract version and user contract constraint parameters are used by S200 to generate time-level executable response boundaries; the market rule version is used by S400 to perform rule adaptation on candidate bid quantity-price combinations; and the model version is used by S500 as a reference field for model version update records after generating return samples.

[0082] S200. Based on the context of the application task, extract historical bidding data from the competitor's historical bidding database to generate competitor bidding quantity and price prediction results; and convert the interruptible duration, minimum continuous interruption time, maximum number of daily interruptions and base load guaranteed electricity in the user contract constraint parameters with the user-side load curve to generate time-period-level executable response boundaries.

[0083] In this embodiment, S200 is jointly executed by the counterparty strategy prediction module and the contract constraint translation module. The counterparty strategy prediction module receives the application task context generated in S100 and reads historical bidding data from the counterparty historical bidding database based on the transaction period, market type, data source, and counterparty strategy prediction model version in the application task context. The contract constraint translation module receives the user contract constraint parameters, contract version, and user-side load curve in the application task context and converts the interruptible duration, minimum continuous interruption time, maximum number of daily interruptions, and base load minimum electricity into the time-level executable response boundary.

[0084] The counterparty historical bid database in this step is a database that stores historical bidding data of similar electricity retailers. This historical bidding data includes the identifier of the similar electricity retailer, trading day, trading period, market type, historical bid volume, historical bid price, historical clearing price, historical transaction volume, historical clearing status, and supply and demand status. The counterparty bid volume and price prediction result is a record formed by grouping the bid volume range, bid price range, and clearing status reference values ​​of similar electricity retailers under the current trading period and market type. This grouping can be performed according to trading period, market type, historical clearing status, supply and demand status, and similar electricity retailer identifier. After grouping, the counterparty strategy prediction module generates grouped statistical values ​​for historical bid volume, historical bid price, historical clearing price, and historical transaction volume, and writes them into the counterparty bid volume and price prediction result.

[0085] In one implementation, the counterparty strategy prediction module reads the transaction period as 10:00-11:00 and the market type as day-ahead spot market from the context of the declaration task. The module extracts historical bidding data with the same market type and transaction period from the counterparty's historical bidding database and filters records whose historical clearing status matches the current supply and demand status. After filtering, the historical declared electricity volume, historical declared price, historical clearing price, and historical transaction volume are grouped to form the counterparty bidding volume and price prediction result. If there is no completely matching transaction period record in the counterparty's historical bidding database, it performs downgraded extraction according to adjacent transaction periods and the same market type, and writes the sample downgraded status into the counterparty bidding volume and price prediction result.

[0086] After receiving the user contract constraint parameters and the user-side load curve, the contract constraint translation module first extracts the load sequence corresponding to the time range from the user-side load curve based on the transaction period; then it compares the load sequence with the base load guarantee power to generate a base load guarantee status; when the load value in the load sequence is higher than the base load guarantee power, the contract constraint translation module generates a load reduction limit based on the difference between the load value and the base load guarantee power; when the load value in the load sequence is not higher than the base load guarantee power, the load reduction limit is recorded as 0, and the base load guarantee status is written as non-reducible.

[0087] The continuous response status is generated by the interruptible duration and the minimum sustained interruption time. Specifically, the contract constraint translation module reads the duration of the transaction period and the reporting time granularity in the market rule configuration, maps the interruptible duration to the number of time slices that can be covered, and then maps the minimum sustained interruption time to the number of consecutive time slices. If the number of time slices that can be covered in the current transaction period is greater than or equal to the number of consecutive time slices, the continuous response status is generated as responsive; if the number of time slices that can be covered in the current transaction period is less than the number of consecutive time slices, the continuous response status is generated as unresponsive. The remaining interruption count is generated by the maximum number of interruptions per day and the resource occupancy lock records generated on the current day. The contract constraint translation module reads the user identifier and transaction period in the daily occupancy records, calculates the number of interruptions for the corresponding user on the current day, and subtracts the number of interruptions from the maximum number of interruptions per day to generate the remaining interruption count.

[0088] In another implementation, the contract constraint translation module also handles the data missing status of the user-side load curve. If there are continuous sampling gaps during the transaction period, the contract constraint translation module retains the original sampling fields and writes the corresponding time slice as a data missing status; if the contract version is marked as expired in the task declaration context, the user's reduceable load limit is not generated, and the user's availability status is written as unavailable; if the maximum number of daily interruptions has been exhausted by the daily occupied records, the remaining number of interruptions is written as 0, the continuous response status retains the original calculation result, but the availability status is written as unavailable.

[0089] In a specific implementation process, the load curve of a user responding to a demand shows a load of 800kW during the 10:00-11:00 trading period. The base load guarantee power corresponding to the load value in the user's contract constraint parameters is 500kW, the interruptible duration is 60min, the minimum continuous interruption time is 30min, the maximum number of interruptions per day is 2, and one resource occupancy lock record has been generated that day. The contract constraint translation module generates a load reduction limit of 300kW, a continuous response status of "responsive", a remaining number of interruptions of 1, a base load guarantee status of "reducible", and an availability status of "available". The above fields are encapsulated as the time-level executable response boundary for this user during the 10:00-11:00 trading period.

[0090] S200 ultimately generates two output objects. One output object is the counterparty bid quantity and price prediction result, which includes the transaction period, market type, similar electricity seller identifiers, predicted counterparty bid quantity, predicted price range, and historical clearing status reference values. The other output object is the time-level executable response boundary, which includes the user identifier, transaction period, maximum load reduction, continuous response status, remaining interruption count, base load guarantee status, and availability status. Both the counterparty bid quantity and price prediction result and the time-level executable response boundary are written under the task identifier corresponding to the declaration task context and used as input for S300 to generate the declareable resource envelope and candidate bid quantity and price combinations.

[0091] S300. Based on the time-level executable response boundary, aggregate the user-controllable load of multiple demand response users to generate a claimable resource envelope, and generate a candidate bid quantity and price combination based on the claimable resource envelope and the opponent's bid quantity and price prediction results.

[0092] In this embodiment, S300 is executed by the resource envelope generation module, which calls the bid quantity-price combination generation processing link. The resource envelope generation module receives the time-level executable response boundaries of multiple demand response users generated in S200, and reads the counterparty bid quantity-price prediction results under the same declaration task context. The time-level executable response boundaries are the resource-side input of this step, and the counterparty bid quantity-price prediction results are the transaction-side input of this step. The resource envelope generation module first aggregates the user-controllable load of multiple demand response users to generate a declareable resource envelope; then, within the power range limited by the declareable resource envelope, it generates candidate bid quantity-price combinations by combining the counterparty bid quantity-price prediction results.

[0093] In this step, the user-controllable load refers to the load that can be reduced or transferred and participate in transaction submissions according to the time-level executable response boundary. The submitable resource envelope is a resource record formed by aggregating the time-level executable response boundaries of multiple demand response users according to the transaction time period. It includes the transaction time period, the upper limit of submitable electricity volume, the lower limit of submitable electricity volume, the continuous response requirement satisfaction status, and the user availability status. The candidate bid quantity-price combination is a combination of multiple submitted electricity volumes and bid prices formed by using the submitable resource envelope as the capacity boundary and the opponent's bid quantity-price prediction results as the transaction reference.

[0094] Specifically, the resource envelope generation module reads all available time-level executable response boundaries according to the transaction time period in the context of the application task; aggregates the load reduction limit for each demand response user to generate the upper limit of the claimable power; aggregates the minimum callable power or the minimum response power recorded in the contract for each demand response user to generate the lower limit of the claimable power; matches the continuous response status, and if all users participating in the aggregation meet the continuous response requirements within the transaction time period, the continuous response requirement is satisfied; if the continuous response status of one user is unresponsive, that user will not enter this aggregation, or in another implementation, it will be retained as unavailable and written into the exception handling record.

[0095] When generating a claimable resource envelope, the resource envelope generation module also reads the remaining interruption count and base load guarantee status generated by S200. If the remaining interruption count of a demand response user is 0, then the user will not participate in the aggregation of the claimable electricity limit; if the base load guarantee status of a demand response user is non-reducible, then the user's reduceable load limit for the current trading period will be written as 0. For users with missing data in their user-side load curve, the resource envelope generation module can generate a substitute load value based on the user's historical electricity consumption data in the same trading period and write the substitute load value into the exception handling record; in another embodiment, the resource envelope generation module does not call the user's controllable load.

[0096] The generation process of the candidate bid quantity-price combination includes the generation of electricity volume combinations and price combinations. The resource envelope generation module first generates multiple bid electricity volume records between the lower limit and the upper limit of the bid electricity volume; then, it reads the predicted counterparty bid volume and predicted price range from the counterparty bid quantity-price prediction results, and pairs the bid electricity records with the corresponding bid price records to form multiple candidate bid quantity-price combinations. Each candidate bid quantity-price combination includes the trading period, market type, bid electricity volume, bid price, corresponding user identifier set, available resource envelope version, and counterparty bid quantity-price prediction result version.

[0097] In one implementation, the resource envelope generation module processes the 10:00-11:00 trading period according to market rules configured with a declaration time granularity of 15 minutes. Three demand response users have load reduction caps of 300kW, 200kW, and 100kW respectively. The third user's continuous response status is unresponsive. The resource envelope generation module then aggregates the first two users to generate a declaration capacity cap of 500kW. If the minimum response capacity recorded in the contract is a total of 100kW, a declaration capacity lower limit of 100kW is generated. Subsequently, combining the predicted competitor bid volume and price range from the competitor bid volume and price prediction results, multiple candidate bid volume and price combinations are generated, and the corresponding user identifier is written into each candidate bid volume and price combination.

[0098] In another implementation, the resource envelope generation module reads the compensation electricity price and user response cost when generating candidate bid quantity-price combinations, but does not output the compensation electricity price and user response cost as independent objects. The compensation electricity price and user response cost can participate in the generation of the declared price record in the candidate bid quantity-price combinations. If the compensation electricity price field is missing, the resource envelope generation module writes the candidate combination corresponding to the user into a compensation electricity price missing status and excludes the user's controllable load from the current candidate combination.

[0099] S300 ultimately outputs the available resource envelope and the candidate bid quantity-price combination. The available resource envelope is used by S400 for continuous response requirement matching and resource occupation conflict verification in market rule adaptation; the candidate bid quantity-price combination is used by S400 for matching with the application time granularity, minimum application capacity, price precision, and price upper and lower limits. Both the available resource envelope and the candidate bid quantity-price combination retain the task identifier, transaction period, and market type from the application task context for reference in subsequent resource occupation lock records and quantity-price application forms.

[0100] S400. Based on the declaration time granularity, minimum declaration capacity and continuous response requirements in the market rule configuration, perform rule adaptation and resource occupation conflict verification on the candidate bid quantity and price combination, and generate resource occupation lock record and quantity and price declaration form.

[0101] In this embodiment, S400 is executed collaboratively by the market rule adaptation module, the resource occupancy locking module, and the quantity-price declaration form generation module. The market rule adaptation module receives the candidate bid quantity-price combinations and the available resource envelope output by S300, and reads the market rule configuration bound by S100; the resource occupancy locking module reads the user identifier, transaction period, and user controllable load from the candidate bid quantity-price combinations, and also reads the generated resource occupancy locking records; after the rule adaptation and resource occupancy conflict verification are completed, the quantity-price declaration form generation module generates a quantity-price declaration form based on the matched candidate bid quantity-price combinations.

[0102] The market rule configuration includes declaration time granularity, minimum declaration capacity, quotation precision, price upper and lower limits, continuous response requirements, and deviation assessment rules. The declaration time granularity is used for time-slice matching of trading periods in candidate bid quantity-price combinations; the minimum declaration capacity is used for capacity matching of declared electricity in candidate bid quantity-price combinations; the quotation precision and price upper and lower limits are used for matching declared prices; the continuous response requirements are used for matching with the continuous response requirement satisfaction status in the available resource envelope; the deviation assessment rules are written into the rule version field of the quantity-price declaration form in this step and are referenced when the S500 generates a return sample.

[0103] Specifically, the market rule adaptation module first matches the transaction period in the candidate bid quantity-price combination with the declaration time granularity. If the transaction period covered by the candidate bid quantity-price combination can be completely divided according to the declaration time granularity, a time granularity matching status is generated; if it cannot be completely divided, the candidate bid quantity-price combination is written to the rule adaptation failure status. Subsequently, the market rule adaptation module compares the declared electricity volume in the candidate bid quantity-price combination with the minimum declared capacity; when the declared electricity volume is less than the minimum declared capacity, the candidate bid quantity-price combination does not enter the resource occupation conflict verification; when the declared electricity volume is greater than or equal to the minimum declared capacity, the declared price matching continues. The declared price matching includes comparing the declared price with the upper and lower price limits, and rounding or splitting the declared price according to the quotation precision.

[0104] The continuous response requirement matching is achieved by the market rule adaptation module reading the continuous response requirement fulfillment status from the available resource envelope. If the continuous response requirement fulfillment status matches the continuous response requirement in the market rule configuration, the corresponding candidate bid quantity-price combination enters the resource occupation conflict verification; if they do not match, a market channel adaptation failure status is generated. For scenarios with multiple market channels, the market rule adaptation module reads the market rule configuration of each market channel and generates market channel adaptation results for the same candidate bid quantity-price combination. The market channel adaptation results include market type, market rule version, time granularity matching status, capacity matching status, price matching status, and continuous response matching status.

[0105] The resource occupancy conflict verification is performed by the resource occupancy locking module. The resource occupancy locking module matches the user identifier, transaction period, and user-controllable load corresponding to the candidate bid quantity-price combination with the user identifier, transaction period, and user-controllable load in the generated resource occupancy locking record. When a record with a locked occupancy status is matched, a resource occupancy conflict record is generated, and the corresponding candidate bid quantity-price combination is written to the "unsubmittable" status. When no record with a locked occupancy status is matched, a resource occupancy locking record is generated. The resource occupancy locking record includes the user identifier, transaction period, target market channel, occupied electricity volume, lock validity period, occupancy status, and release conditions.

[0106] In one implementation, the lockout validity period is jointly generated by the end time of the application window, the market clearing time, and the resource release conditions. If a quantity and price application has been sent but the clearing result has not yet been received, the occupancy status is set to locked. If no transaction is completed after market clearing, the resource occupancy lockout module updates the occupancy status to released according to the release conditions. If a transaction is completed after market clearing, the occupancy status remains locked until the performance period ends or the corresponding settlement data is generated. If the power trading platform returns an application receipt failure status, the resource occupancy lockout module writes the corresponding record to a push failure status and releases the corresponding user-controllable load according to the release conditions.

[0107] In a specific implementation process, the candidate bid quantity and price combination output by S300 includes a bid electricity volume of 500kW, a bid price of P1, a trading period of 10:00-11:00, and two user identifiers. The market rule adaptation module reads the day-ahead spot market rule configuration, where the bid time granularity is 15min, the minimum bid capacity is 100kW, and the continuous response requirement is 60min. The trading period of the candidate bid quantity and price combination can be divided into four 15-minute time slices. If the bid electricity volume is greater than the minimum bid capacity, the continuous response requirement in the bid resource envelope is satisfied. Subsequently, the resource occupancy locking module queries the generated resource occupancy locking records. If no matching lock record with the same user identifier, trading period, and user controllable load is found, a resource occupancy locking record with the target market channel being the day-ahead spot market is generated.

[0108] After receiving the market rule adaptation results and resource occupancy lock records, the quantity and price declaration generation module generates a quantity and price declaration form based on the matched candidate bid quantity and price combinations. The quantity and price declaration form includes a task identifier, trading day, trading period, market type, target market channel, declared electricity volume, declared price, market rule version, resource occupancy lock record identifier, and declaration form version. After generation, the quantity and price declaration form is written into the task record corresponding to the declaration task context and used as input to the power trading platform by the S500; the resource occupancy lock record is used by the S500 to generate the resource occupancy status and performance deviation in the return sample.

[0109] S500: Send the quantity and price declaration form to the power trading platform, receive the clearing result after market clearing, generate a return sample containing prediction deviation and performance deviation based on the quantity and price declaration form, the clearing result and the resource occupation lock record, and update the counterparty strategy prediction model version based on the return sample.

[0110] In this embodiment, S500 is executed by the application push processing link, the return sample generation module, and the model version update module. The application push processing link receives the quantity and price application form generated in S400 and sends it through the power trading platform interface; the return sample generation module receives the clearing result after market clearing and reads the quantity and price application form, the clearing result, the resource occupation lock record, and the counterparty bid quantity and price prediction result generated in S200; the model version update module updates the counterparty strategy prediction model version based on the return sample and writes the model version update record into the application task context.

[0111] The quantity and price declaration form in this step is the object of the declaration sent to the power trading platform. It includes the declaration form version, trading period, market type, target market channel, declared electricity volume, declared price, and resource occupation lock record identifier. The clearing result is the result record returned by the power trading platform after market clearing, which includes the actual transaction volume, actual transaction price, clearing status, declaration receipt status, and settlement identifier. The return sample is a sample record formed by binding the quantity and price declaration form, clearing result, resource occupation lock record, and counterparty bid quantity and price prediction result. It includes the trading period, market type, target market channel, declaration form version, declared electricity volume, declared price, predicted counterparty bid volume, actual transaction volume, actual transaction price, prediction deviation, performance deviation, resource occupation status, and model version.

[0112] Specifically, the application push processing link first reads the target market channel and market rule version from the quantity and price application form, converts the quantity and price application form into the transaction request format required by the power trading platform interface, and then sends it to the power trading platform. When the power trading platform returns an application receipt, the application receipt status is written to the corresponding record of the quantity and price application form. If no application receipt is received before the application window closes, an receipt timeout status is generated and written to the exception handling record. If the application receipt status is failure, the application push processing link writes the failure reason to the quantity and price application form record and updates the occupation status of the resource occupation lock record to release or pending review.

[0113] After market clearing, the return sample generation module receives the clearing result and matches it with the corresponding volume and price declaration based on the declaration form version. Then, based on the resource occupancy lock record identifier, it reads the corresponding user identifier, trading period, target market channel, occupied power, and occupancy status. Next, it reads the predicted counterparty bid volume from the counterparty bid volume and price prediction result generated by S200. Subsequently, it generates prediction deviation and performance deviation. The prediction deviation is generated from the predicted counterparty bid volume and the actual transaction volume; in one embodiment, the prediction deviation is the difference or percentage difference between the predicted counterparty bid volume and the actual transaction volume. The performance deviation is generated from the resource occupancy status, declared power, and actual transaction volume; in one embodiment, when the resource occupancy status is locked and the actual transaction volume is less than the declared power, the performance deviation is the difference between the declared power and the actual transaction volume; when the actual transaction volume is 0, the performance deviation is written as an unexecuted status.

[0114] In another implementation, if the clearing result is missing or the declaration form version cannot be matched, the return sample generation module generates a return sample abnormal state and records the reason for failure; this return sample does not enter the model version update process. If the resource occupation lock record has been released, but the clearing result shows a transaction, the return sample generation module generates a resource occupation status inconsistency record and writes the corresponding quantity and price declaration form and resource occupation lock record into the pending review status. If the predicted counterparty bid volume is null, the return sample retains the actual transaction volume and actual transaction price fields, but does not generate a prediction bias, and writes the sample into the prediction field missing status.

[0115] The model version update module reads the prediction deviation, performance deviation, and model version from the return sample, and writes the prediction deviation, performance deviation, trading session, market type, and target market channel into the sample record of the counterparty strategy prediction model version. If the return sample status is normal, the model version update module generates a new model version update record; if the return sample status is abnormal, the model version update module retains the previous model version and writes the abnormal status into the model version update record. In one embodiment, the model version update record includes the original model version, the new model version, the return sample identifier, the update time, the trading session, the market type, and the sample status.

[0116] In one specific implementation process, the quantity and price declaration form generated by S400 is sent to the power trading platform before 10:00 AM. The declared electricity volume in the declaration form is 500kW, the declared price is P1, and the target market channel is the day-ahead spot market. After market clearing, the power trading platform returns a clearing result with an actual transaction volume of 400kW and an actual transaction price of P2. The return sample generation module reads the predicted counterparty bid volume from S200 and the resource occupation lock-in record from S400, generates prediction deviation and performance deviation, and encapsulates the trading period, market type, target market channel, declaration form version, declared electricity volume, declared price, actual transaction volume, actual transaction price, resource occupation status, and model version into a return sample. The model version update module writes this return sample into the sample record of the counterparty strategy prediction model version.

[0117] The S500 process ultimately generates a return sample and a model version update record. The return sample is stored in the task record corresponding to the declaration task context and maintains a reference relationship with the volume and price declaration form, clearing results, and resource occupancy lock record. The model version update record is written to the model library and is read as a candidate version of the counterparty strategy prediction model when the next S100 generates a declaration task context. If the corresponding resource occupancy lock record meets the release conditions, the resource occupancy lock module updates the occupancy status according to the clearing status received by S500. If the transaction record enters the subsequent settlement statement data generation stage, the resource occupancy status is retained until the end of the corresponding performance period and settlement cycle.

[0118] Example 2: Figure 2 This diagram illustrates a structural block diagram of a highly automated bidding system for electricity sales companies according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0119] The task application context generation module 01 receives application window trigger information, power trading data, user contract constraint parameters, user-side load curves, counterparty historical bidding database, and market rule configurations. It then binds these data according to the trading period, market type, contract version, market rule version, and counterparty strategy prediction model version to generate the application task context. Specifically, the task application context generation module has data interfaces connected to the power trading platform, contract management database, user-side load data interface, counterparty historical bidding database, and market rule configuration database. The application window trigger information comes from the power trading platform or trading calendar configuration; the power trading data comes from the power trading platform or electricity sales company's trading ledger; the user contract constraint parameters come from the contract management database; the user-side load curve comes from the user-side smart meter or electricity marketing system; and the market rule configuration comes from the market rule configuration database. After receiving the application window trigger information, the task application context generation module parses the trading day, trading period, and market type. It reads the corresponding power trading data and user-side load curve according to the trading period, the corresponding market rule configuration according to the market type, the valid user contract constraint parameters according to the demand response user identifier, and the current counterparty strategy prediction model version. The task declaration context includes a task identifier, trading day, trading session, market type, data source, contract version, market rule version, counterparty strategy prediction model version, and data validity period. The contract version is bound to the user contract constraint parameters, the market rule version is bound to the market rule configuration, and the counterparty strategy prediction model version is bound to the counterparty's historical bidding database. When the contract version does not match the trading session, the task declaration context generation module writes a contract expiration status; when the market rule version does not match the market type, a market rule adaptation failure status is written; when there is a sampling gap in the user-side load curve, the original fields are retained and a data missing status is written. The task declaration context generation module outputs the task declaration context to the prediction and boundary generation module and saves the task identifier, trading session, market type, contract version, market rule version, and counterparty strategy prediction model version as fields for subsequent calls.

[0120] The prediction and boundary generation module 02, connected to the application task context generation module, is used to extract historical bidding data from the counterparty's historical bidding database based on the application task context, generate counterparty bidding quantity and price prediction results, and convert the interruptible duration, minimum continuous interruption time, maximum daily interruption count, and base load guaranteed electricity in the user contract constraint parameters with the user-side load curve to generate a time-period-level executable response boundary. Specifically, the prediction and boundary generation module receives the task identifier, transaction period, market type, contract version, counterparty strategy prediction model version, and data validity period from the application task context, and reads the counterparty's historical bidding database and the user contract constraint parameters according to the task identifier. Based on the transaction period, market type, historical clearing status, supply and demand status, and similar electricity sales entity identifiers, the prediction and boundary generation module extracts historical bidding data from the counterparty's historical bidding database, groups the historical declared electricity, historical declared price, historical clearing price, and historical transaction volume in the historical bidding data, and generates counterparty bidding quantity and price prediction results. The prediction and boundary generation module simultaneously extracts the user-side load curve according to the transaction period, compares the user-side load curve with the base load guarantee power, and generates a load reduction limit and a base load guarantee status. It maps the interruptible duration and the minimum continuous interruption time to continuous time slices within the transaction period to generate a continuous response status. It matches the maximum daily interruption count with the resource occupancy lock records registered for the day to generate the remaining interruption count. The prediction and boundary generation module generates a time-period-level executable response boundary based on the load reduction limit, the continuous response status, the remaining interruption count, the base load guarantee status, and the availability status. The time-period-level executable response boundary includes user identifier, transaction period, load reduction limit, continuous response status, remaining interruption count, base load guarantee status, and availability status. When no matching record exists between the historical bidding data and the trading period, the prediction and boundary generation module reads historical bidding data from adjacent trading periods with the same market type and writes a sample downgrade status into the counterparty bidding volume and price prediction result. When the user contract constraint parameter has a contract expiration status, the prediction and boundary generation module writes the availability status of the corresponding demand response user as unavailable. The prediction and boundary generation module outputs the counterparty bidding volume and price prediction result and the time-level executable response boundary to the resource envelope and combination generation module, and saves the task identifier as a correlation field between the two.

[0121] The resource envelope and combination generation module 03, connected to the prediction and boundary generation module, is used to aggregate the controllable loads of multiple demand response users based on the time-level executable response boundary, generate a claimable resource envelope, and generate candidate bid quantity and price combinations based on the claimable resource envelope and the opponent's bid quantity and price prediction results. Specifically, the resource envelope and combination generation module receives the time-level executable response boundary and the opponent's bid quantity and price prediction results output by the prediction and boundary generation module, and reads the corresponding transaction time and market type according to the task identifier. The resource envelope and combination generation module reads the user identifier, transaction time, load reduction limit, continuous response status, remaining interruption count, base load guarantee status, and availability status from the time-level executable response boundaries of multiple demand response users; aggregates the controllable loads of users with an availability status, non-zero remaining interruption count, and base load guarantee status that allow reduction, generating a claimable power limit and a claimable power lower limit; and matches the continuous response status to generate a continuous response requirement satisfaction status. The declared resource envelope includes the trading period, the upper limit of declared electricity volume, the lower limit of declared electricity volume, the continuous response requirement satisfaction status, and the user availability status. The resource envelope and combination generation module generates declared electricity volume records between the upper and lower limits of declared electricity volume, reads the predicted counterparty bid volume, historical bid price groups, and historical clearing price groups from the counterparty bid volume and price prediction results, forms a bid price record corresponding to the declared electricity volume record, and binds the declared electricity volume record and the bid price record as a candidate bid volume and price combination. The candidate bid volume and price combination includes the trading period, market type, declared electricity volume, bid price, corresponding user identifier set, declared resource envelope version, and counterparty bid volume and price prediction result version. When a user-side load curve of a demand response user has missing data, the resource envelope and combination generation module excludes the user's controllable load from this aggregation, or generates a substitute load value based on the user's historical electricity consumption data and writes it into the anomaly handling record. The resource envelope and combination generation module outputs the declareable resource envelope and the candidate bid quantity and price combination to the rule adaptation and resource occupation locking module, and provides the transaction period, market type, declared electricity volume, declared price and user identifier set for subsequent rule adaptation and resource occupation conflict verification.

[0122] The rule adaptation and resource occupancy locking module 04, connected to the resource envelope and combination generation module, is used to perform rule adaptation and resource occupancy conflict verification on the candidate bid quantity-price combinations based on the application time granularity, minimum application capacity, and continuous response requirements in the market rule configuration, and generate a resource occupancy locking record. Specifically, the rule adaptation and resource occupancy locking module receives the candidate bid quantity-price combinations and the available application resource envelope from the resource envelope and combination generation module, and reads the market rule configuration in the application task context according to the task identifier. The rule adaptation and resource occupancy locking module matches the transaction period in the candidate bid quantity-price combinations with the application time granularity, matches the application electricity volume in the candidate bid quantity-price combinations with the minimum application capacity, and matches the continuous response requirement satisfaction status in the available application resource envelope with the continuous response requirement. When the market rule configuration also includes quotation accuracy, price upper and lower limits, and deviation assessment rules, the rule adaptation and resource occupancy locking module matches the application price in the candidate bid quantity-price combinations with the quotation accuracy and the price upper and lower limits, and writes the deviation assessment rules into the rule adaptation result. After successful rule adaptation, the rule adaptation and resource occupancy locking module reads the generated resource occupancy locking record and matches the user identifier, transaction period, and user controllable load corresponding to the candidate bid quantity-price combination with the user identifier, transaction period, and user controllable load in the generated resource occupancy locking record. When a record with a locked occupancy status is matched, a resource occupancy conflict record is generated, and the corresponding candidate bid quantity-price combination is marked as unsuitable for submission. When no record with a locked occupancy status is matched, a resource occupancy locking record is generated. The resource occupancy locking record includes the user identifier, transaction period, target market channel, occupied electricity, lock validity period, occupancy status, and release conditions. When the candidate bid quantity-price combination fails to meet the submission time granularity, minimum submission capacity, or continuous response requirements, the rule adaptation and resource occupancy locking module writes a rule adaptation failure status and retains the task identifier, market type, and failure field of the corresponding candidate bid quantity-price combination. The rule adaptation and resource occupancy locking module outputs the candidate bid quantity-price combination that has passed the resource occupancy conflict verification, the rule adaptation result, and the resource occupancy locking record to the quantity-price submission form generation module.

[0123] The quantity-price declaration form generation module 05, connected to the rule adaptation and resource occupation locking module, is used to generate a quantity-price declaration form based on the candidate bid quantity-price combination and the resource occupation locking record. Specifically, the quantity-price declaration form generation module receives the candidate bid quantity-price combination, rule adaptation result, and resource occupation locking record output by the rule adaptation and resource occupation locking module, and reads the transaction day, transaction period, market type, and market rule version from the declaration task context according to the task identifier. The quantity-price declaration form generation module reads the declared electricity volume, declared price, and user identifier set from the candidate bid quantity-price combination, and reads the target market channel, occupied electricity volume, lock validity period, and occupation status from the resource occupation locking record. It also writes the declaration time granularity, minimum declaration capacity, continuous response requirement, quotation accuracy, and price upper and lower limits from the rule adaptation result into the declaration form rule fields. The quantity-price declaration form includes the task identifier, transaction day, transaction period, market type, target market channel, declared electricity volume, declared price, market rule version, resource occupation locking record identifier, and declaration form version. Before generating the quantity-price declaration form, the quantity-price declaration form generation module reads the occupancy status from the resource occupancy lock record. When the occupancy status is locked, the resource occupancy lock record identifier is written into the quantity-price declaration form. When the occupancy status is a resource occupancy conflict status, no corresponding quantity-price declaration form is generated, and an exception handling record is written. The quantity-price declaration form generation module outputs the quantity-price declaration form to the feedback sample and model version update module, and saves the declaration form version, resource occupancy lock record identifier, declared electricity volume, and declared price as matching fields for subsequent clearing results.

[0124] The return sample and model version update module 06, connected to the quantity-price declaration form generation module, is used to send the quantity-price declaration form to the power trading platform, receive the clearing result after market clearing, generate a return sample containing prediction and performance deviations based on the quantity-price declaration form, the clearing result, and the resource occupation lock-in record, and update the counterparty strategy prediction model version based on the return sample. Specifically, the return sample and model version update module receives the quantity-price declaration form from the quantity-price declaration form generation module, forms a transaction request record according to the target market channel and market rule version in the quantity-price declaration form, and sends it to the power trading platform. The return sample and model version update module receives the declaration receipt returned by the power trading platform and writes the declaration receipt status into the corresponding record of the quantity-price declaration form; after market clearing, it receives the clearing result and matches the clearing result with the quantity-price declaration form based on the declaration form version. The return sample and model version update module reads the declared electricity volume, declared price, trading period, market type, and target market channel from the volume and price declaration form; reads the actual transaction volume, actual transaction price, and clearing status from the clearing result; reads the occupancy status and occupied electricity volume from the resource occupancy lock record; and reads the predicted counterparty bid volume from the counterparty bid volume and price prediction result. The prediction deviation is generated by the predicted counterparty bid volume and the actual transaction volume, and the performance deviation is generated by the resource occupancy status, the declared electricity volume, and the actual transaction volume. The return sample includes the trading period, market type, target market channel, declaration form version, declared electricity volume, declared price, predicted counterparty bid volume, actual transaction volume, actual transaction price, prediction deviation, performance deviation, resource occupancy status, and model version. When the clearing result is missing or the declaration form version cannot be matched, the return sample and model version update module writes the return sample abnormal status and maintains the previous counterparty strategy prediction model version; when the clearing result is inconsistent with the occupancy status in the resource occupancy lock record, a resource occupancy status inconsistency record is written. The return sample and model version update module writes the return sample into the model version update record, and updates the counterparty strategy prediction model version based on the prediction deviation, performance deviation and model version in the return sample; the counterparty strategy prediction model version is returned to the declaration task context generation module as the model version read when generating the declaration task context in the next trading session.

Claims

1. A highly automated bidding method for electricity sales companies, characterized in that, include: S100 receives the application window trigger information, power transaction data, user contract constraint parameters, user-side load curve, counterparty historical bidding database and market rule configuration, and binds them according to transaction period, market type, contract version, market rule version and model version to generate application task context; S200. Based on the context of the application task, extract historical bidding data from the competitor's historical bidding database and generate competitor bidding quantity and price prediction results. The interruptible duration, minimum continuous interruption time, maximum daily interruption count, and base load reserve parameters in the user contract constraints are then converted with the user-side load curve to generate a time-period-level executable response boundary; specifically including: Based on the user-side load curve and the base load minimum power, a load reduction limit can be generated; A continuous response state is generated based on the interruptible duration and the minimum continuous interruption time. The remaining number of interruptions is generated based on the maximum number of interruptions per day; The time-level executable response boundary is generated based on the scalable load limit, the continuous response status, and the remaining number of interruptions. S300. Based on the time-level executable response boundary, aggregate the user controllable load of multiple demand response users to generate a resource envelope that can be declared, and generate a candidate bid quantity and price combination based on the resource envelope that can be declared and the opponent's bid quantity and price prediction results. S400. Based on the declaration time granularity, minimum declaration capacity and continuous response requirements in the market rule configuration, perform rule adaptation and resource occupation conflict verification on the candidate bid quantity-price combination, and generate resource occupation lock record and quantity-price declaration form; S500: Send the quantity and price declaration form to the power trading platform, receive the clearing result after market clearing, generate a return sample containing prediction deviation and performance deviation based on the quantity and price declaration form, the clearing result and the resource occupation lock record, and update the counterparty strategy prediction model version based on the return sample.

2. The method according to claim 1, characterized in that, The context of the application task includes task identifier, trading day, trading session, market type, data source, contract version, market rule version, counterparty strategy prediction model version, and data validity period; The contract version is bound to the user contract constraint parameters, the market rule version is bound to the market rule configuration, and the opponent strategy prediction model version is bound to the opponent historical bid database.

3. The method according to claim 1, characterized in that, Historical bidding data is extracted from the competitor's historical bidding database to generate competitor bidding volume and price prediction results, including: Based on the trading period, market type, historical clearing status, supply and demand status, and identification of similar electricity sellers, historical bidding data is extracted from the counterparty's historical bidding database. The historical bid volume, historical bid price, historical clearing price, and historical transaction volume in the historical bidding data are grouped and processed to generate the opponent's bid volume and price prediction results.

4. The method according to claim 1, characterized in that, Generate competitor bid volume and price prediction results, including: The counterparty strategy prediction module reads historical bidding data from the counterparty historical bidding database based on the transaction period, market type, data source, and counterparty strategy prediction model version in the context of the declaration task. The historical bidding data includes the identifiers of similar electricity sellers, trading days, trading hours, market types, historical bid volumes, historical bid prices, historical clearing prices, historical transaction volumes, historical clearing status, and supply and demand status. The counterparty strategy prediction module groups the data according to trading time, market type, historical clearing status, supply and demand status, and similar electricity seller identifiers. It generates grouped statistical values ​​for historical bid volume, historical bid price, historical clearing price, and historical transaction volume, and writes them into the counterparty bid volume and price prediction results. The counterparty bid volume and price prediction results include the trading period, market type, identification of similar electricity sales entities, predicted counterparty bid volume, predicted price range, and historical clearing status reference values. When there is no matching trading session record in the opponent's historical bid database, downgrade extraction is performed according to adjacent trading sessions and the same market type, and the sample downgrade status is written into the opponent's bid volume and price prediction results.

5. The method according to claim 1, characterized in that, Generate time-level executable response boundaries, including: The contract constraint translation module receives user contract constraint parameters, contract version, and user-side load curve; First, the load sequence corresponding to the time range is extracted from the user-side load curve based on the transaction period. Then, the load sequence is compared with the base load guarantee power to generate the base load guarantee status. When the load value in the load sequence is higher than the base load reserve, the upper limit of the load that can be reduced is generated based on the difference between the load value and the base load reserve. When the load value in the load sequence is not higher than the base load reserve, the upper limit of the load that can be reduced is recorded as 0, and the base load reserve status is written as non-reducible. The contract constraint translation module reads the duration of the transaction period and the declaration time granularity in the market rule configuration, maps the interruptible duration to the number of time slices that can be covered, and maps the minimum continuous interruption time to the number of consecutive time slices. When the number of time slices that can be covered within the current trading session is greater than or equal to the number of consecutive time slices, a continuous response status is generated as responsive. When the number of time slices that can be covered in the current trading session is less than the number of consecutive time slices, the continuous response status is generated as unresponsive. The contract constraint translation module reads the user identifier and transaction time period from the daily occupied records, calculates the number of interruptions for the corresponding user on that day, and generates the remaining number of interruptions by subtracting the number of interruptions from the maximum number of interruptions per day. The time-level executable response boundary includes user identifier, transaction time period, load reduction limit, continuous response status, remaining interruption count, base load guarantee status, and availability status.

6. The method according to claim 1, characterized in that, Based on the aforementioned time-level executable response boundary, the user-controllable load of multiple demand response users is aggregated to generate a resource envelope that can be claimed, including: Read all available time-level executable response boundaries based on the transaction time period in the task declaration context; aggregate the load reduction limits for each demand response user to generate the declared electricity limit; Aggregate the minimum callable power or the minimum response power recorded in the contract for each demand response user to generate a lower limit for the claimable power. Match the continuous response status. When all users participating in the aggregation meet the continuous response requirements during the transaction period, generate a continuous response requirement met status. When one of the users' continuous response statuses is unresponsive, that user will not be included in this aggregation; the resource envelope generation module also reads the remaining number of interruptions and the base load backup status; When a user's remaining interruption attempts are 0, that user will not participate in the aggregation of the claimable power limit; When the base load of a demand response user is in a non-reducible state, the user's maximum reduceable load for the current trading session is written as 0. The declared resource package includes the transaction period, the upper limit of declared electricity volume, the lower limit of declared electricity volume, the continuous response requirement satisfaction status, and the user availability status.

7. The method according to claim 1, characterized in that, The generation of candidate bid quantity-price combinations includes: Multiple declared electricity volume records are generated between the lower limit and the upper limit of the declared electricity volume. Then, the predicted bid volume and predicted price range of the opponent are read from the opponent's bid volume and price prediction results. The declared electricity volume records are matched with the corresponding bid price records to form multiple candidate bid volume and price combinations. Each candidate bid quantity and price combination includes the trading period, market type, declared electricity volume, declared price, corresponding user identifier set, available resource envelope version, and counterparty bid quantity and price prediction result version; When the compensation price field is missing, the resource envelope generation module writes the candidate combination corresponding to the user into the compensation price missing status and excludes the user's controllable load from the current candidate combination.

8. The method according to claim 1, characterized in that, The resource conflict verification includes: The user identifier, transaction period, and user controllable load corresponding to the candidate bid quantity and price combination are matched with the user identifier, transaction period, and user controllable load in the generated resource occupancy lock record; When a record with a locked status is matched, a resource usage conflict record is generated; When no record with a locked status is found, the resource occupancy lock record is generated; The resource occupancy lock record includes user ID, transaction time period, target market channel, electricity consumption, lock validity period, occupancy status, and release conditions.

9. The method according to claim 1, characterized in that, The return sample includes the trading period, market type, target market channel, order form version, order volume, order price, predicted counterparty bid volume, actual transaction volume, actual transaction price, prediction deviation, performance deviation, resource occupancy status, and model version. The prediction deviation is generated by the predicted counterparty bid volume and the actual transaction volume; The performance deviation is generated by the resource occupancy status, the declared electricity volume, and the actual transaction volume. The opponent strategy prediction model version is updated based on the prediction deviation, the performance deviation, and the model version.

10. A highly automated bidding system for electricity sales companies, characterized in that: include: The system comprises a task declaration context generation module, a prediction and boundary generation module, a resource envelope and combination generation module, a rule adaptation and resource occupation locking module, a quantity and price declaration form generation module, and a backlog sample and model version update module; the system is used to implement the method of any one of claims 1-9.

Images