Virtual power plant multi-level real-time data aggregation and protocol adaptive method

Abstract

The application discloses a kind of virtual power plant multilevel real-time data aggregation and protocol adaptive method, the present application relates to power system automation and industrial internet of things data interaction technical field, the measuring point identifier of all terminal equipment in virtual power plant jurisdiction is pre-written into distributed cache system according to four levels of global level, resource type level, user level and user resource type level, forming four-level hierarchical cache structure, according to four-level hierarchical cache structure, global total power, each resource type classification power, each user total power and each user each resource type power are calculated in stages, power generation channel and power consumption channel are independently calculated in each level aggregation, the present application stores four-level hierarchical measuring point identifier using distributed cache system in advance, and each level aggregation query is changed from each database traversal to cache batch direct reading, so that the aggregation calculation delay under the scale of thousands of terminals is greatly reduced from seconds to milliseconds, to meet the real-time requirement of minute-level push cycle.

Description

Technical Field

[0001] This invention relates to the field of power system automation and industrial Internet of Things data interaction technology, specifically a method for multi-level real-time data aggregation and protocol adaptation in a virtual power plant. Background Technology

[0002] Virtual Power Plants (VPPs) use software platforms to aggregate and manage geographically dispersed distributed energy resources in a unified manner. The types of resources accessed include thermal power generating units, distributed photovoltaic power generation devices, wind power generation equipment, distributed energy storage systems, and controllable industrial loads. The VPP platform needs to aggregate real-time power data from all terminal devices within its jurisdiction at a frequency of minutes and push it to the power grid dispatch center so that the dispatch center can obtain the real-time operating status of distributed resources, supporting electricity market clearing and grid dispatch response. As the scale of VPP access continues to expand, the number of terminal devices has rapidly increased from tens to hundreds or even thousands. Existing technologies face the following five technical challenges in large-scale engineering practices in the above scenarios: First, there is the problem of low efficiency in polling point by point. Before each data push, the existing system needs to traverse all measuring points in the jurisdiction and send query requests to the database or remote terminal equipment one by one to obtain the current power value of each measuring point. When the number of virtual power plant access terminals reaches hundreds or thousands, the cumulative delay of querying one by one increases linearly with the total number of measuring points, which can easily exceed the time limit allowed by the one-minute push cycle, resulting in data push timeout or even loss. The system's real-time performance is seriously insufficient and cannot meet the requirements of the power grid dispatch center for data timeliness.

[0003] Secondly, there is the problem of limited aggregation granularity. Existing technologies typically only support the unified push of the total power of all terminal devices within the jurisdiction. They cannot classify and push real-time power data of various resources according to resource type (such as thermal power units, photovoltaic power generation, energy storage devices, etc.), nor can they push the total power and power of each resource type within a user separately for each sub-user under the aggregator. As a result, the power grid dispatch center cannot obtain refined information on the distribution of distributed resource response capabilities, making it difficult to support refined dispatch decisions and precise load control.

[0004] Third, there is the problem of high protocol coupling. Power grid dispatch interfaces usually require the use of specific XML message formats for data transmission. However, the XML messages of different types of push interfaces differ significantly in terms of field definitions and nested hierarchical structures: some interfaces use a flat column field structure, while others require a multi-layered nested category data list structure. The existing implementation hardcodes the message template separately for each dispatch interface, and the amount of code expands linearly with the number of interfaces. Adding a new dispatch interface requires rebuilding the complete data processing and message sending link, making the system interface expansion cost extremely high.

[0005] Fourth, the large amount of data leads to storage expansion. The virtual power plant platform continuously writes aggregated power data at all levels at a frequency of minutes. If all historical data is stored in a single data table, the amount of data in a single table will rapidly expand to more than ten million records as the operating time accumulates. As a result, the database query performance will drop sharply, which will affect the stable operation of the system and the data query response speed.

[0006] Fifth, there is the problem of unreliable communication and lack of fault tolerance. The communication link between the power grid dispatch center and the virtual power plant platform is affected by network conditions, and occasional unreachability is inevitable. The power grid system may also return a service failure response due to its own load problems. Existing technology lacks an automatic retry mechanism for the above-mentioned abnormal situations. Once a single transmission fails, the push is directly abandoned, resulting in a break in the dispatch data, affecting data integrity and system reliability. Moreover, it is impossible to trace the specific push content and the cause of the abnormality afterward.

[0007] To address the above five issues, existing technologies lack a complete solution that can simultaneously meet the five constraints of efficient aggregation query, multi-level fine-grained classification, protocol decoupling and expansion, elastic storage expansion, and communication fault tolerance. There is an urgent need to propose a systematic and comprehensive technical solution to address these problems. Summary of the Invention

[0008] The purpose of this invention is to provide a method for multi-level real-time data aggregation and protocol adaptation in virtual power plants, in order to solve the technical problems existing in the prior art, such as low efficiency of point-by-point polling, single aggregation granularity, high protocol coupling, expansion of storage data volume, and lack of communication fault tolerance mechanism, so as to realize the efficient aggregation and reliable push of multi-level real-time power data of distributed energy resources within the jurisdiction of the virtual power plant platform.

[0009] This invention provides a method for multi-level real-time data aggregation and protocol adaptation in a virtual power plant, comprising the following steps: The measurement point identifiers of all terminal devices within the virtual power plant domain are pre-written into the distributed cache system at four levels: global level, resource type level, user level, and user resource type level, forming a four-level hierarchical cache structure. When the measurement point configuration changes, the corresponding cache entries affected are updated synchronously. The accuracy of the aggregation calculation is ensured by verifying the consistency between the cache and the database measurement points. Based on the aforementioned four-level hierarchical caching structure, the global total power, the power of each resource type, the total power of each user, and the power of each user for each resource type are calculated hierarchically. The power generation channel and the power consumption channel are calculated independently in each level of aggregation. A three-layer interface model consisting of method identifier, method type, and method parameters is adopted. XML format messages conforming to the power grid dispatch interface specification are dynamically embedded as method parameter field values ​​into JSON format envelopes and sent to the power grid dispatch center via HTTP protocol. Based on the current year and month suffix, the aggregation results are routed to the corresponding month's table. If the table does not exist, the table creation operation is automatically performed before writing the data. The system detects the service status identifier returned by the power grid dispatch center. If the service status is failed, it is resent after a preset time interval. If the number of retries reaches a preset limit, the system marks the service as failed and records the log. Write the original request message and corresponding response message sent each time into the log record table.

[0010] This invention also provides a multi-level real-time data aggregation and protocol adaptation system for virtual power plants, comprising: The cache pre-construction module is used to pre-write the measurement point identifiers of all terminal devices within the virtual power plant domain into the distributed cache system at four levels: global level, resource type level, user level, and user resource type level, forming a four-level hierarchical cache structure, and synchronously update the corresponding affected cache entries when the measurement point configuration changes. The aggregation calculation module is used to read the real-time power values ​​corresponding to the measurement point identifiers at each level in a batch query manner according to the four-level hierarchical cache structure, and calculate the global total power, the power of each resource type, the total power of each user, and the power of each user for each resource type in a hierarchical manner. The power generation channel and the power consumption channel are calculated independently in each level of aggregation. The protocol adaptation module is used to dynamically embed XML format messages conforming to the power grid dispatch interface specification as method parameter field values ​​into JSON format envelopes using a three-layer interface model of method identifier, method type, and method parameters, and send them to the power grid dispatch center via HTTP protocol. The partitioned storage module is used to route the aggregation results to the corresponding month partition based on the current month and year suffix. If the partition does not exist, it will automatically perform a table creation operation and then write the data. The fault-tolerant retry module is used to parse the service status identifier value in the response message returned by the power grid dispatch center. When the service status identifier value indicates that the service processing has failed, it will resend after a preset time interval. After the number of retries reaches the preset limit, it will be marked as a failure and recorded in the log. The transaction log module is used to write the original request message and corresponding response message sent each time, along with the push execution timestamp, interface method identifier, and processing status identifier, into a transaction log table stored in monthly partitions. Beneficial effects

[0011] The present invention has the following beneficial effects: 1. This invention uses a distributed caching system to pre-store four-level hierarchical measurement point identifiers, transforming the aggregation query at each level from traversing the database line by line to batch direct reading from the cache. This significantly reduces the aggregation calculation latency at the scale of thousands of terminals from the second level to the millisecond level, meeting the real-time requirements of the minute-level push cycle.

[0012] 2. This invention independently performs dual-channel aggregation calculations of power generation channels and power consumption channels at four levels: global, resource type, user, and user resource type. The power grid dispatch center can obtain refined power distribution data of the power generation side and power consumption side at each level, meeting the requirements for independent monitoring of both source and load sides and supporting refined dispatch decisions.

[0013] 3. This invention uses a three-layer interface model of method identifier, method type, and method parameters to dynamically embed XML messages into JSON envelopes for unified sending. The sending framework code is completely decoupled from the XML message structure of each interface. When adding a new scheduling interface, only the new method identifier and corresponding XML message template need to be configured, without modifying the message sending framework, which significantly reduces the development and maintenance costs of interface extension.

[0014] 4. This invention achieves horizontal table partitioning of aggregated data by month by automatically routing the table based on the month and year suffix and automatically creating the table when the partition does not exist. This avoids the performance degradation of queries caused by the accumulation of all data in a single data table. At the same time, no manual intervention is required throughout the process, which significantly reduces the workload of database operation and maintenance.

[0015] 5. The three-level fault-tolerant retry mechanism of this invention ensures the continuity of pushed data. When the power grid dispatch center is momentarily unreachable, the push is automatically restored to avoid data interruption. The complete communication pipeline recording mechanism retains the original request and response messages of each push, supports retrospective auditing of any push event afterward, and improves the reliability and maintainability of the system. Attached Figure Description

[0016] Figure 1 is a flowchart of the construction and synchronization process of the four-level hierarchical cache for measurement points according to the present invention; Figure 2 is a flowchart of the four-level dual-channel power aggregation calculation of the present invention; Figure 3 is a flowchart of the hybrid protocol message assembly and three-level fault-tolerant retry push of the present invention; Figure 4 is a flowchart of the automatic monthly table entry and communication log recording process of the present invention. Detailed Implementation

[0017] The following is in conjunction with the appendix Figures 1-4 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0018] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0019] I. Four-level hierarchical pre-caching of measurement point identifiers During system initialization and when the configuration of measurement points changes, the virtual power plant platform pre-writes the measurement point identifiers (hereinafter referred to as measurement point IDs) of all terminal devices within its jurisdiction into a distributed cache system (in this embodiment, Redis is used as the distributed cache system, hereinafter referred to as the cache system) according to a four-level hierarchical structure, forming a four-level hierarchical cache structure in the cache system. In other embodiments, the distributed cache system may also be other distributed cache systems that support key-value storage and batch read operations, such as Memcached. The key name design rules, data organization methods, and cache synchronization logic of its four-level hierarchical cache structure are the same as those in this embodiment. This invention is not limited to the specific implementation of Redis.

[0020] The first level is a global cache, which stores a list of all generator-side measurement point IDs with a predefined fixed key name and a list of all consumer-side measurement point IDs with another fixed key name. The global cache is used to read all relevant measurement point IDs within the jurisdiction at once when calculating the total global power, for batch querying.

[0021] The second level is a resource type-level cache, which uses the resource type identifier of each resource type as the key prefix. For each resource type, two cache entries are stored: a list of all generation-side measurement point IDs under this resource type and a list of all power consumption-side measurement point IDs under this resource type. Additionally, a set of all generation-side resource type identifiers and a set of all power consumption-side resource type identifiers are stored with predefined fixed key names for use when traversing each resource type.

[0022] The third level is the user-level cache, which uses the aggregated user ID as the key prefix. It stores two cache entries for each user: a list of all generator-side measurement point IDs under that user name and a list of all power-side measurement point IDs under that user name. It also stores a list of all user IDs with a predefined fixed key name for use when traversing each user.

[0023] The fourth level is the user resource type level cache, which uses the combined string of user account number and resource type identifier as the key name. For each resource type under each user, it stores a list of all measurement point IDs for that user and that resource type. In addition, it uses each user account number as the key name prefix to store the list of power generation side resource types and the list of power consumption side resource types owned by that user, for use when traversing each resource type under each user.

[0024] In the above four-level cache, each list-type cache entry is organized using a list data structure, supporting atomic batch read operations; Each set-type cache entry is organized using a set data structure, which supports efficient member traversal operations. When changes such as adding, deleting, or modifying measurement point configurations occur, the system synchronously updates the corresponding affected cache entries in the cache system to ensure that the cached data is always consistent with the measurement point configuration records in the database, preventing calculation deviations caused by reading expired measurement point IDs during push operations.

[0025] By pre-storing the measurement point IDs in the caching system, the database is not traversed and queried every time a push is made. The data preparation stage of the aggregation calculation is changed from a query mode that is limited by the performance of database input and output to a cache batch reading mode. This fundamentally breaks through the performance bottleneck of polling point by point. When the number of connected devices in the jurisdiction reaches thousands, the aggregation latency can be reduced from the second level to the millisecond level.

[0026] When the system detects that the distributed cache system is unavailable (such as network interruption, Redis service failure, etc.) when the push task is triggered, the system automatically degrades to directly reading all the measurement point configuration information from the database, temporarily building a memory structure according to the four-level hierarchy, and then performing aggregation calculations to ensure that basic data push functions can still be maintained during cache failure. At the same time, the system continuously monitors the availability status of the distributed cache system, and immediately triggers a complete four-level cache reconstruction process after it is restored to availability. After the reconstruction is completed, the cache batch read mode is restored, and no manual intervention is required throughout the entire process.

[0027] Level 2 and Level 4 power aggregation calculation pipeline Each time a push task is triggered (triggered at a minute-level frequency as a scheduled task), the system sequentially executes the following four levels of aggregation calculations. The results of each level of calculation are temporarily stored in memory for use in the subsequent message assembly stage.

[0028] Level 1: Global total power addition calculation. The system reads the list of all generator-side measuring point IDs and the list of all power-consuming-side measuring point IDs from the cache system at once. After merging all measuring point IDs in the two lists, it requests the current power value of the corresponding measuring point from the real-time data interface of the measuring point in a batch query mode. This avoids making a separate query request for each measuring point ID one by one. After obtaining the current power value of all measuring points in batch, the power values ​​of all measuring points on the generator side are summed to obtain the global total power addition. The power values ​​of all measuring points on the power consumption side are summed to obtain the total power consumption. The total power generation and the total power consumption are temporarily stored as independent values ​​and do not interfere with each other.

[0029] Level 2: Resource type classification power calculation. The system reads the complete set of all generation-side resource type identifiers from the cache system. For each resource type identifier in the set, it reads the list of generation-side measurement point IDs corresponding to that resource type identifier, queries the real-time power values ​​of the corresponding measurement points in batches, and sums them to obtain the generation classification power of that resource type. The resource type identifier and the corresponding generation classification power are assembled into a generation type power record and appended to the current generation resource type power record list. The same operation is performed on the complete set of power consumption-side resource type identifiers to obtain the classification power of each power consumption resource type and the corresponding power consumption type power record list. When assembling the message node, all power records at this level are distinguished by the energy type field to differentiate between generation channels and power consumption channels: the energy type field of the power generation channel power record takes the first preset type code value, and the energy type field of the power consumption channel power record takes the second preset type code value. In this embodiment, the first preset type encoding value is the string "GEN" (representing the generation side), and the second preset type encoding value is the string "CON" (representing the consumption side). The above encoding values ​​are pre-defined according to the power grid dispatch interface specification and are injected through configuration items during system deployment. They are not modified during system operation.

[0030] The power recording node lists for the two channels are assembled independently and stored separately.

[0031] Level 3: Calculation of total power added by the user. The system reads the list of all user accounts from the cache system. For each user account in the list, it reads the list of generator-side measurement point IDs and the list of power consumption-side measurement point IDs corresponding to that user account. After batch querying the real-time power values, the system sums them up to obtain the total power added by the user's generator and power consumption. The total power added by the generator and power consumption of each user are recorded as independent user power entries for subsequent message assembly. The generator and power consumption data are also stored and packaged independently at the user level.

[0032] Level 4: User resource type power calculation. For each user account number traversed in Level 3, the system further reads the power generation side resource type list and the power consumption side resource type list of the user from the cache system. For each resource type identifier in the power generation side resource type list, the system reads the measurement point ID list corresponding to the user's resource type, queries the real-time power values ​​in batches, and then sums them up to obtain the power generation power of the user's resource type. Perform the same operation on each resource type in the list of electricity consumption resource types to obtain the power value of each electricity consumption resource type. The power generation and power consumption of each user for each resource type are recorded as independent user resource type power entries, and the dual channels are also kept independently organized.

[0033] After all four levels of calculation are completed, the system memory holds eight categories of aggregated result data, including the total global power generation, the total global power consumption, power generation by resource type, power consumption by resource type, total power generation by user, total power consumption by user, power generation by user and power consumption by user and resource type. These data cover all aggregation dimensions of the four levels and dual channels, and are available for use in subsequent message assembly stages.

[0034] III. Hybrid Protocol Message Assembly and Transmission This invention adopts a three-layer interface model of method identifier, method type and method parameters to uniformly manage all push interfaces to the power grid dispatch center, and realizes complete decoupling between the sending logic and the specific XML message structure of each interface.

[0035] The field definitions for the three-tier interface model are as follows: Method Identifier Field: Takes a string value that uniquely identifies the type of power grid dispatch interface corresponding to this call. Different dispatch push interfaces have their own exclusive method identifier values. The global total power push interface, resource type classification power push interface, user total power push interface, and user resource type power push interface each have different method identifier values. Different method identifiers correspond to different XML message templates.

[0036] Method type field: Takes a string value to identify the type of communication service used in this call. In this embodiment, the Web service communication type is used uniformly, and the method type field of all interface calls takes the preset Web service type encoding value.

[0037] Method parameter field: Takes a string type value, which stores the XML format message string dynamically assembled according to the power grid dispatch interface specification format. This field is the carrier of the differences in message structure between various interfaces, while the outer assembly framework remains unchanged.

[0038] During message assembly, the system first determines the corresponding XML message template based on the method identifier of this call, and then fills the four-level aggregation calculation results temporarily stored in memory into the XML message string according to the field positions defined in the template, dynamically generating a complete XML format message. The XML message structures of different scheduling interfaces are significantly different: the XML message of the global total power interface adopts a flat column field structure, directly listing each data column under the root node; The XML message of the resource type classification power interface adopts a three-level nested structure, which includes a category data list node, a category detail data list node, and a data row node in sequence. The nesting relationship of each level is predefined by the XML message template. Although the XML message structure of each interface is significantly different, the dynamically generated XML message string is embedded as the field value of the method parameter field in the same JSON format envelope, together with the method identifier field value and the method type field value, to form the JSON format request body.

[0039] The HTTP request header always carries a pre-defined channel identifier field, which indicates that the data source of this request is the virtual power plant system. The power grid dispatch center identifies the request source and performs access authentication. The system sends the above JSON format request body to the corresponding interface address of the power grid dispatch center via HTTP POST.

[0040] Since the combination framework of the three-layer field of method identifier, method type and method parameter remains unchanged in all interface calls, the sending framework code can generalize the request sending process of all interfaces without writing sending logic separately for each interface. When adding a new scheduling interface, it is only necessary to register the new method identifier in the system and configure the corresponding XML message template to reuse the existing sending framework to complete the data push of the new interface without making any modifications to the sending framework code, thus realizing low-cost horizontal expansion of the protocol interface.

[0041] IV. Three-level fault-tolerant retry mechanism After each message is sent, the system parses the response message returned by the power grid dispatch center and extracts the business result status identifier field value. This status identifier field is defined by the power grid dispatch center according to the interface specification: when the field value indicates that the business processing is successful, the system records the success status of this push and enters the log recording step. When a field value indicates that the business process has failed, the system enters a retry process.

[0042] The retry process is as follows: After detecting a service failure, the system waits for a preset retry interval (set to 2 seconds in this embodiment) and then resends the same JSON format request message. The waiting interval is introduced to avoid exacerbating the load pressure on the power grid dispatch center by continuously sending requests when it is momentarily congested or temporarily unavailable. If the service status identifier returned after the first retry is still a failure, the system waits for the same interval again and performs a second retry. If the service status identifier returned after the second retry is still a failure, the system performs a third send. If the service status identifier is still a failure after the third send, the number of retries has reached the preset limit (set to 3 times in this embodiment). The system marks this push as a failure, records a detailed failure log (including failure timestamp, interface method identifier, and failure response message content), and terminates this push process. If the service status identifier returned by the power grid dispatch center after any of the above sends or retryes indicates that the service processing was successful, the system immediately terminates the retry, records the success status, and enters the log recording step.

[0043] Through a three-level fault-tolerant retry mechanism, this invention can automatically resume push when a brief communication anomaly occurs on the power grid side, effectively ensuring the continuity of data transmission and controlling the impact of occasional communication anomalies on data integrity within an acceptable range.

[0044] V. Automatic routing and table creation by monthly table partitioning When aggregated data at all levels is written to the database, the system uses a monthly table partitioning strategy to store the data in horizontal tables in order to control the amount of data in a single table and maintain query performance.

[0045] Before the write operation is executed, the system extracts the year and month combination string of the current system time (the format is a continuous concatenation of four-digit year numbers and two-digit month numbers), and appends this suffix string to the table name prefix of the corresponding business type to form the complete target table name. In this embodiment, four types of table name prefixes are predefined: global total data table prefix, which is used to store the global total power generation and global total power consumption pushed each time. The resource classification data table prefix is ​​used to store the power generation and power consumption of each resource type in each push; The user total power addition table prefix is ​​used to store the total power generation and total power consumption of each user in each push; The user resource classification data table prefix is ​​used to store the power generation and power consumption of each user and resource type in each push.

[0046] After the target table name is determined, the system checks whether the target table already exists in the current database instance through the database metadata query interface. If the target table does not exist (usually when the first write occurs at the beginning of each month), the system retrieves the table creation statement template corresponding to the business type from the pre-stored table creation statement template set, replaces the table name placeholder in the template with the actual table name according to the target table name, and then performs the table creation operation to create the table in the database. After the table creation operation is completed, the system will write the aggregation calculation results to the newly created sub-table. If the target sub-table already exists, the system will directly write the aggregation calculation results to the existing target sub-table without performing the table creation operation.

[0047] Through the above-mentioned automatic routing and table creation mechanism based on monthly table partitioning, the aggregated data for each month is distributed and stored in its respective monthly partition table. The data volume of a single table is kept within a reasonable range, avoiding the query performance degradation caused by the long-term accumulation of all data in a single table. All table creation and data routing operations are completed automatically by the program, without the need for database administrators to manually create partition tables, thus realizing automated horizontal scaling and maintenance-free management at the storage level.

[0048] VI. Complete Communication Log Record After each push process is completed, regardless of whether the push is in a successful state or a failed state after retries are exhausted, the system will write all relevant information of the push into the communication log table. Each log record contains the following information: push execution timestamp, the interface method identifier corresponding to the push, the complete original JSON format request message string actually sent by the system (including the embedded complete XML format message), the complete response message string returned by the power grid dispatch center, and the processing status identifier of the push.

[0049] The communication log table also uses a monthly table partitioning strategy for storage, consistent with the table partitioning method of aggregated data at all levels, which facilitates querying by time range and regular archiving management.

[0050] By retaining the complete original request and response messages for each push, operations and maintenance personnel can retrospectively audit specific push records at any point in time, reconstructing the push content and grid-side response at that time, accurately locating the specific message segment where data anomalies occurred, effectively supporting the reliability analysis and troubleshooting of communication links. This mechanism also meets the power industry's compliance audit requirements for dispatch data communication, providing technical support for the legal validity of data transmission.

[0051] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for multi-level real-time data aggregation and protocol adaptation in a virtual power plant, characterized in that, include: The measurement point identifiers of all terminal devices within the virtual power plant domain are pre-written into the distributed cache system at four levels: global level, resource type level, user level, and user resource type level, forming a four-level hierarchical cache structure. When the measurement point configuration changes, the corresponding cache entries affected are updated synchronously. The accuracy of the aggregation calculation is ensured by verifying the consistency between the cache and the database measurement points. Based on the aforementioned four-level hierarchical caching structure, the global total power, the power of each resource type, the total power of each user, and the power of each user for each resource type are calculated hierarchically. The power generation channel and the power consumption channel are calculated independently in each level of aggregation. A three-layer interface model consisting of method identifier, method type, and method parameters is adopted. XML format messages conforming to the power grid dispatch interface specification are dynamically embedded as method parameter field values ​​into JSON format envelopes and sent to the power grid dispatch center via HTTP protocol. Based on the current year and month suffix, the aggregation results are routed to the corresponding month's table. If the table does not exist, the table creation operation is automatically performed before writing the data. The response message returned by the power grid dispatch center is parsed, and the business status identifier value of the predefined field in the response message is extracted. The business status identifier value is determined by the power grid dispatch center according to the interface specification and takes one of two states: indicating successful business processing or indicating business processing failure. When the business status identifier value indicates business processing failure, the same request message is resent after a preset time interval. After the number of retries reaches the preset limit, this push is marked as a failure and a detailed failure log containing the failure timestamp, interface method identifier and failure response message content is recorded. Write the original request message and corresponding response message sent each time into the log record table.

2. The method according to claim 1, characterized in that, The four-level hierarchical cache structure is specifically as follows: The global-level cache stores the list of all generator-side measurement point identifiers and the list of all consumer-side measurement point identifiers using fixed key names respectively. The resource type-level cache uses the resource type identifier as the key name prefix to store the list of generation-side measurement point identifiers and the list of power consumption-side measurement point identifiers for that resource type, and uses independent key names to store the set of all generation-side resource type identifiers and the set of all power consumption-side resource type identifiers. The user-level cache uses the user's account number as the key name prefix to store the list of all generator-side test point identifiers and the list of all consumer-side test point identifiers for that user, and stores the list of all user account numbers with an independent key name. The user resource type level cache uses a combination of user ID and resource type identifier as the key to store a list of all measurement point identifiers for that user and resource type, and stores the power generation side resource type list and power consumption side resource type list for each user respectively.

3. The method according to claim 1, characterized in that, The power generation channel and power consumption channel are calculated independently in each level of aggregation, specifically including: During aggregation calculations at all levels, the list of measurement point identifiers read from the distributed cache system is queried in batches, requesting the current power values ​​of all corresponding measurement points from the real-time data interface of the measurement points at once. The aggregated power generation is obtained by summing the power values ​​at the power generation side measurement points, and the aggregated power consumption is obtained by summing the power values ​​at the power consumption side measurement points. The aggregated power generation and aggregated power consumption are stored independently. When assembling message nodes, the power generation channel and the power consumption channel are distinguished by the energy type field. The energy type field of the power generation channel power record takes the first preset type code value, and the energy type field of the power consumption channel power record takes the second preset type code value. The power record node lists of the two channels are assembled independently.

4. The method according to claim 1, characterized in that, The step of dynamically embedding an XML format message conforming to the power grid dispatch interface specification as a method parameter field value into a JSON format envelope includes: The corresponding XML message template is determined based on the method identifier used in this call; Based on the current aggregation calculation results, the aggregation power values ​​at each level are filled into the corresponding field positions of the XML message template to dynamically generate a complete XML format message string; The XML format message string is used as the field value of the method parameter field, and together with the method identifier field value and the method type field value, they are assembled into a JSON format request body; The HTTP request header includes a preset channel identifier field, and the JSON format request body is sent to the power grid dispatch center via HTTP POST.

5. The method according to claim 1, characterized in that, The preset maximum number of retries is 3, and the preset time is 2 seconds; After detecting a service failure, wait 2 seconds and resend. If the resend still fails, wait 2 seconds again and send again. If the cumulative number of sends reaches 3 and the push still fails, mark the push as a failure and terminate the push process. If the service status is successful after any transmission, the retry should be terminated immediately.

6. The method according to claim 1, characterized in that, The steps for automatic routing and table creation based on the current year and month suffix include: When writing, extract the year and month string of the current system time, and concatenate it to the table name prefix to form the target table name. The table name prefix includes the global total data table prefix, the resource category data table prefix, the user total data table prefix, and the user resource category data table prefix. Before writing, the database metadata query interface is used to check if the target partitioned table exists. If it does not exist, the table creation operation is performed according to the pre-stored table creation statement template, and then the aggregation result is written to the target partitioned table.

7. The method according to claim 1, characterized in that, It also includes a cache synchronization step: When the measurement point configuration changes, the measurement point configuration change notification is received asynchronously through a message queue / event listener mechanism. Depending on the type of change, a cache entry is appended for newly added measurement points, a cache entry is removed for deleted measurement points, and a cache entry is replaced for modified measurement points. After the above cache entry append, cache entry removal, and cache entry replacement operations are completed, a consistency check with the database is performed on the affected cache entries. If the check fails, a full reconstruction operation is triggered for the cache entry to ensure that the measurement point identifier in the cache is always consistent with the measurement point configuration record in the database.

8. The method according to claim 1, characterized in that, Each transaction record in the transaction record table includes: The push execution timestamp, interface method identifier, complete original request message string sent, complete response message string returned by the power grid dispatch center, and processing status identifier of this push; The transaction record table is stored in separate tables according to the year and month suffix.

9. The method according to claim 2, characterized in that, The distributed caching system is a Redis caching system; In the four-level hierarchical cache structure, each list-type cache entry is organized using a list data structure, and each set-type cache entry is organized using a set data structure, both supporting atomic batch read operations.

10. A multi-level real-time data aggregation and protocol adaptive system for a virtual power plant, characterized in that, include: The cache pre-construction module is used to pre-write the measurement point identifiers of all terminal devices within the virtual power plant domain into the distributed cache system at four levels: global level, resource type level, user level, and user resource type level, forming a four-level hierarchical cache structure, and synchronously update the corresponding affected cache entries when the measurement point configuration changes. The aggregation calculation module is used to read the real-time power values ​​corresponding to the measurement point identifiers at each level in a batch query manner according to the four-level hierarchical cache structure, and calculate the global total power, the power of each resource type, the total power of each user, and the power of each user for each resource type in a hierarchical manner. The power generation channel and the power consumption channel are calculated independently in each level of aggregation. The protocol adaptation module is used to dynamically embed XML format messages conforming to the power grid dispatch interface specification as method parameter field values ​​into JSON format envelopes using a three-layer interface model of method identifier, method type, and method parameters, and send them to the power grid dispatch center via HTTP protocol. The partitioned storage module is used to route the aggregation results to the corresponding month partition based on the current month and year suffix. If the partition does not exist, it will automatically perform a table creation operation and then write the data. The fault-tolerant retry module is used to parse the service status identifier value in the response message returned by the power grid dispatch center. When the service status identifier value indicates that the service processing has failed, it will resend after a preset time interval. After the number of retries reaches the preset limit, it will be marked as a failure and recorded in the log. The transaction log module is used to write the original request message and corresponding response message sent each time, along with the push execution timestamp, interface method identifier, and processing status identifier, into a transaction log table stored in monthly partitions.

Images