A virtual power plant data security protection method, system and electronic device
By performing cluster analysis on the recorded data of the virtual power plant API interface and dynamically adjusting the rate limiting strategy, the problem of low data security in existing virtual power plant technologies is solved, and more efficient and accurate data security protection is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- QINGDAO KEYAN INNOVATION TECH CO LTD
- Filing Date
- 2025-12-04
- Publication Date
- 2026-07-21
AI Technical Summary
Existing API rate limiting technologies are ill-suited to the dynamic changes in the scale of distributed resource access in virtual power plants, leading to delays in response to control commands or the accidental blocking of legitimate requests, thus threatening the data security of virtual power plants.
By acquiring API interface record data, performing cluster analysis, determining the transmission and call characteristics of API clusters, dynamically adjusting the rate limiting mechanism, and generating personalized rate limiting strategies, including normal, warning, and emergency modes.
It significantly reduces the false alarm rate of virtual power plant data security protection, improves data security and protection efficiency, and can detect abnormal call behavior in a timely manner to prevent data tampering and DDoS attacks.
Smart Images
Figure CN121637535B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data protection technology, specifically to a method, system, and electronic device for data security protection of a virtual power plant. Background Technology
[0002] A virtual power plant (VPS) is a digital energy management system that integrates and optimizes various distributed energy resources to form a unified energy management platform, enabling efficient energy utilization and dispatch. Therefore, VPS typically communicates with numerous third-party platforms via APIs, collecting real-time operational data by connecting to distributed power sources, energy storage systems, and adjustable loads, thus achieving cross-platform resource aggregation. During communication, VPS systems need to process massive amounts of device data in real time. API rate limiting technology is typically used to prevent malicious requests from exhausting server resources, ensuring timely responses to critical control commands and avoiding data loss or tampering due to service interruptions.
[0003] Existing API rate limiting technologies mostly use fixed thresholds, such as 100 requests per second. These technologies are difficult to adapt to the dynamic changes in the scale of distributed resource access in virtual power plants, leading to delays in the response to sudden control commands or the accidental blocking of legitimate requests, causing abnormal power grid operation data and threatening the data security of virtual power plants. Summary of the Invention
[0004] To address the technical problem of low data security in virtual power plants caused by existing fixed API rate limiting mechanisms, the present invention aims to provide a method, system, and electronic device for protecting virtual power plant data security. The specific technical solution adopted is as follows: One embodiment of the present invention provides a method for data security protection of a virtual power plant, the method comprising the following steps: Obtain the record data for each API interface in the API library of the virtual power plant during the current time period; the record data includes at least call record data and transmission record data between the API interface and the user entity; The transmission parameters and call parameters of each API interface are determined based on the recorded data of each API interface; all API interfaces are clustered in the feature space constructed by the transmission parameters and call parameters to obtain several API clusters. Analyze the API call behavior of each API interface in the same API cluster to determine the basic call coefficient of each API cluster. Based on the basic call coefficient of each API cluster, analyze the abnormal call situation of the API cluster relative to other API clusters, and determine the call abnormality of each API interface in each API cluster. A rate-limiting mechanism is generated for each API interface based on the call anomaly rate of each API interface.
[0005] Furthermore, determining the transmission parameters and call parameters of each API interface based on the recorded data of each API interface includes: Extract the average daily data throughput and the allowed data volume per request for each API interface from the transmission record data between each API interface and the user entity; determine the transmission parameters for each API interface based on the average daily data throughput and the allowed data volume per request. Extract the peak QPS and P99 latency of each API interface from the call record data of each API interface; determine the call parameters of each API interface based on the peak QPS and P99 latency of each API interface.
[0006] Furthermore, the step of analyzing the API interface call behavior within the same API cluster based on the recorded data of each API interface to determine the basic call coefficient for each API cluster includes: For each API cluster, extract the transmission data and real-time transmission volume of each API interface in each transmission from the transmission record data between each API interface and the user entity in the API cluster; determine the transmission characteristic value of the API cluster based on the transmission data and real-time transmission volume of each API interface in each transmission. From the call record data of each API interface in the API cluster, extract the error rate of each API interface and the number of call requests for each type of resource; based on the peak QPS, P99 latency, error rate and the number of call requests for each type of resource of each API interface in the API cluster, determine the call characteristic value of the API cluster. Data fusion processing is performed on the transmission characteristic values and call characteristic values of API clusters to obtain the basic call coefficients of API clusters.
[0007] Furthermore, determining the transmission characteristic value of the API cluster based on the amount of data transmitted and the real-time transmission volume of each API interface in each transmission includes: Based on the data transmitted by each API interface in the API cluster during each transmission, the sensitivity coefficient of each API interface in the API cluster during each transmission is determined; the sensitivity coefficient is determined by identifying the classification results of the transmitted data through a neural network. Obtain the historical data volume of each API interface in the API cluster during each transmission under the historical baseline period; The transmission characteristic value of the API cluster is determined based on the real-time data transmission volume of each API interface in the API cluster during each transmission, the historical data transmission volume, and the sensitivity coefficient.
[0008] Furthermore, the formula for calculating the transmission characteristic value of the API cluster is as follows: In the formula, This represents the transmission characteristic value of the API cluster, where I represents the number of data transmissions of the API interface within the current time period. This represents the average sensitivity coefficient of each API interface in the API cluster during the i-th transmission. This represents the cumulative value of the real-time data transmission volume for each API interface in the API cluster during the i-th transmission. This represents the cumulative amount of real-time data transmitted by each API interface in the API cluster during each transmission. Let represent the logarithmic function with base 2. Indicates hyperparameters, This represents the cumulative value of the historical data transmission volume of each API interface in the API cluster during the i-th transmission under the historical baseline period.
[0009] Furthermore, determining the call characteristic values of the API cluster based on the peak QPS, P99 latency, error rate, and the number of call requests for each resource type for each API interface in the API cluster includes: The first characteristic factor of the API cluster is determined based on the peak QPS of each API interface in the API cluster. The second characteristic factor of the API cluster class is determined based on the P99 latency of each API interface in the API cluster class. The third characteristic factor of the API cluster is determined based on the error rate of each API interface in the API cluster. The weight coefficient of each undetermined feature factor of the API cluster is determined based on the number of call requests for each type of resource received by each API interface in the API cluster; the undetermined feature factors include the first, second and third feature factors. The corresponding undetermined feature factors of the API cluster class are weighted and fused using the weight coefficient of each undetermined feature factor to obtain the call feature value of the API cluster class.
[0010] Further, determining the weight coefficient of each undetermined feature factor of the API cluster class based on the number of call requests for each type of resource received by each API interface in the API cluster class includes: Obtain the total number of call requests for each type of resource received by each API interface in the API cluster, and calculate the frequency ratio of the total number of call requests for each type of resource corresponding to the API cluster in all call requests, as the request rate of the corresponding type of resource; the resources include energy scheduling, equipment monitoring and user electricity consumption; Based on the request rate of each type of resource, determine the weight coefficient of each undetermined feature factor of the API cluster class.
[0011] Further, determining the weight coefficient of each undetermined feature factor of the API cluster class based on the request rate of each type of resource includes: If the energy dispatch request rate is maximized, then the weight coefficient of the first feature factor is equal to the energy dispatch request rate, and the weight coefficients of the second and third feature factors are equal to... , Indicates the energy dispatch request rate; If the request rate for device monitoring is the highest, then the weight coefficient of the second feature factor is equal to the request rate for device monitoring, and the weight coefficients of the first and third feature factors are equal to... , This indicates the request rate for device monitoring; If the user's electricity request rate is the highest, then the weight coefficient of the third feature factor is equal to the user's electricity request rate, and the weight coefficients of the second and third feature factors are equal to... , This indicates the user's electricity request rate.
[0012] Furthermore, the step of analyzing the abnormal call situation of each API cluster relative to other API clusters based on the basic call coefficient of each API cluster, and determining the call abnormality degree of each API interface in each API cluster, includes: Calculate the average of the base call coefficients for all API clusters as the comparison call coefficients; Based on the difference between the base call coefficient and the comparative call coefficient for each API cluster, the call anomaly degree of each API interface in each API cluster is determined.
[0013] Furthermore, the method of generating a corresponding rate-limiting mechanism for each API interface based on the call anomaly rate of each API interface includes: For each API interface, if the call anomaly rate of the API interface is less than or equal to the first anomaly threshold, the API interface rate limiting mechanism is determined to be in normal mode, and the normal mode is not rate-limited. If the API call anomaly is greater than the first anomaly threshold and less than or equal to the second anomaly threshold, the API rate limiting mechanism is determined to be in warning mode, and the warning mode is dynamic rate limiting. If the API call anomaly level is greater than the second anomaly threshold, the API rate limiting mechanism is determined to be in emergency mode, which is strict rate limiting; the second anomaly threshold is greater than the first anomaly threshold.
[0014] Furthermore, the expression for the dynamic speed limit is: In the formula, This indicates the adjustment of the request rate for the API interface. Indicates the upper limit baseline value. Indicates the degree of exception in API call; The expression for a strict speed limit is: .
[0015] Another embodiment of the present invention provides a virtual power plant data security protection system, comprising: The data acquisition module is used to acquire the record data of each API interface in the API library of the virtual power plant during the current time period; the record data includes call record data and transmission record data between the API interface and the user entity; The interface clustering module is used to determine the transmission parameters and calling parameters of each API interface based on the recorded data of each API interface; and to cluster all API interfaces in the feature space constructed by the transmission parameters and calling parameters to obtain several API clusters. The first determining module is used to analyze the API interface call situation in the API cluster based on the record data of each API interface in the same API cluster, and determine the basic call coefficient of each API cluster. The second determination module is used to analyze the abnormal call situation of each API cluster class relative to other API cluster classes based on the basic call coefficient of each API cluster class, and to determine the call abnormality degree of each API interface in each API cluster class. The rate limiting generation module is used to generate a corresponding rate limiting mechanism for each API interface based on the call anomaly rate of each API interface.
[0016] Another embodiment of the present invention provides an electronic device including a processor and a memory, the processor being used to process instructions stored in the memory to implement a virtual power plant data security protection method.
[0017] The present invention has the following beneficial effects: This invention provides a method, system, and electronic device for data security protection of virtual power plants. First, the acquired record data includes call record data and transmission record data, which facilitates the evaluation of API interface call anomalies from two aspects, overcoming the limitations of traditional single-indicator methods and helping to generate more suitable rate-limiting mechanisms for each API interface. By determining transmission and call parameters, the API interfaces in the virtual power plant API library are clustered to obtain several API clusters. This facilitates subsequent calculation of call anomaly degrees based on the clustering results, distinguishing between normal business fluctuations and real security threats in different API clusters, significantly reducing false alarm rates, and also mitigating the impact on the number of virtual power plant calls. Based on the computational efficiency of security protection, the implementation efficiency of data security protection in virtual power plants is improved. Analyzing from two perspectives—API interface call status within API clusters and abnormal call status between API clusters—a more valuable call anomaly score can be determined for each API interface within each API cluster. This enhances the objectivity and accuracy of the assessment, enabling dynamic adjustment of rate limiting strategies based on real-time calculated call anomaly scores, rather than relying on fixed static thresholds. Calculating API interface call anomaly scores facilitates the timely detection of abnormal call behaviors, such as DDoS attacks, forged scheduling instructions, and data tampering, thereby improving data security in the virtual power plant system. Attached Figure Description
[0018] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart illustrating the implementation of a virtual power plant data security protection method according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the API interface of the virtual power plant system in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the implementation of determining the transmission parameters and call parameters of each API interface based on the recorded data of each API interface in an embodiment of the present invention. Figure 4 This is a schematic diagram of the feature space of the API interface in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the implementation of step S3 in an embodiment of the present invention; Figure 6 This is a schematic diagram of API rate limiting combined with call anomaly in an embodiment of the present invention. Detailed Implementation
[0020] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the specific implementation methods, structures, features, and effects of the technical solution proposed according to the present invention are described in detail below with reference to the accompanying drawings and preferred embodiments. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.
[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.
[0022] The application scenarios corresponding to this invention can be: Virtual power plants use API rate limiting to prevent malicious requests from exhausting server resources, ensuring timely responses to critical control commands (such as frequency regulation commands) and avoiding abnormal grid operation data due to delays. However, current rate limiting technologies mostly use fixed rate limits, which are difficult to adapt to the dynamically changing scale of distributed resource access in virtual power plants. This can lead to delays in responding to sudden control commands or the accidental blocking of legitimate requests, further compromising the data security of virtual power plants.
[0023] One embodiment of the present invention provides a method for data security protection of a virtual power plant, such as... Figure 1 As shown, it includes the following steps: S1: Retrieve the record data of each API interface in the API library of the virtual power plant for the current time period.
[0024] Here, the API interface record data includes at least call record data and transmission record data between the API interface and the user subject.
[0025] The API of a virtual power plant is primarily used to coordinate the monitoring, scheduling, and optimization of distributed energy resources. It typically relies on multiple types of databases to store different data and records API call details and data transmission between the API interface and different user entities during each scheduling process through call logs. A schematic diagram of the API interface of a virtual power plant system is shown below. Figure 2 As shown, Figure 2 In this context, K represents the total number of API interfaces.
[0026] Typically, a virtual power plant system contains several API interfaces. Multiple user entities interact through these API interfaces, making calls and transmitting data. Each user entity communicates with different API interfaces of the virtual power plant system according to its own needs. The goal is to retrieve the record data for each API interface in the virtual power plant's API library for the current time period, including: The first step is to collect call record data for each API interface in the API library of the virtual power plant during the current time period through the log system. This typically includes: peak QPS, P99 latency, error rate, number of call requests for each type of resource, API request time, response time, and caller identity, etc.
[0027] The second step is to record the transmission data between the virtual power plant's API interface and the user entity during the current time period. This typically includes: average daily data throughput, data allowed per request, data transmitted by the API interface during each transmission, real-time data transmission volume, equipment operation data, equipment metadata, equipment control and scheduling instructions, and meteorological data.
[0028] The current time period can be set by the implementer according to the specific actual situation, without specific limitations. In this embodiment, the current time period is set to 24 hours.
[0029] Thus, this embodiment has obtained the record data of each API interface in the API library of the virtual power plant during the current time period.
[0030] The data received by a virtual power plant during operation typically includes equipment operating data (such as power, voltage, current, and temperature), energy market data (such as time-of-use pricing and real-time pricing), dispatch instructions, meteorological and environmental data, and user electricity consumption data. Most of this data needs to be transmitted via API interfaces. However, malicious requests to certain API interfaces can exhaust server resources. Therefore, this embodiment uses big data analysis of API data transmission and call patterns to identify risky API interfaces within the virtual power plant, facilitating subsequent rate limiting of these risky interfaces.
[0031] S2, determine the transmission parameters and call parameters of each API interface based on the recorded data of each API interface; cluster all API interfaces in the feature space constructed by the transmission parameters and call parameters to obtain several API clusters.
[0032] Because virtual power plants (VPS) connect to entities across multiple stages of energy production, consumption, trading, and regulation via API interfaces, forming a complex ecosystem, the data transmission and invocation behavior of various VPS API interfaces depends on the actual situation of the entities corresponding to those API interfaces. Different API interfaces exhibit heterogeneity; therefore, it is necessary to segment the API interfaces between each entity and the VPS based on the relative characteristics of different entities to avoid unreasonable situations when applying rate limiting to API interfaces later.
[0033] As an exemplary implementation, the transmission parameters and call parameters of each API interface are determined based on the recorded data of each API interface, such as... Figure 3 As shown, it includes: S21. Extract the average daily data throughput and the allowed data volume per request for each API interface from the transmission record data between each API interface and the user entity; determine the transmission parameters for each API interface based on the average daily data throughput and the allowed data volume per request for each API interface.
[0034] Here, the transmission parameters are used at least to characterize the abnormality of the transmission behavior of the API interface.
[0035] Specifically, by linearly superimposing throughput load risk and single request data volume risk, and using equal weights, we can ensure that the two risk dimensions are fairly assessed.
[0036] In one embodiment, the formula for calculating the transmission parameters of the nth API interface can be: In the formula, This represents the transmission parameters for each API interface. This represents the average daily data throughput of the nth API interface. This represents the maximum allowed throughput of the nth API interface configured in the virtual power plant system. This represents the amount of data allowed in a single request for the nth API interface. This represents the maximum allowed data volume for a single request to the nth API interface set in the virtual power plant system.
[0037] Formulas for calculating transmission parameters, and The data load of the nth API interface was comprehensively quantified. The closer a value is to 1, the more likely the nth API interface is to have high throughput. The closer the value is to 1, the larger the data volume of a single request for the nth API interface. High throughput and large single request data volumes increase the risk of resource consumption in the virtual power plant system, and the more significant the abnormal transmission behavior of the nth API interface becomes. and It can normalize the average daily data throughput and the amount of data allowed per request, limiting the value range of the two calculation parts to between 0 and 1, which helps to eliminate the influence of different types of data dimensions during the calculation process.
[0038] Referring to the calculation process of the transmission parameters of the nth API interface above, the transmission parameters of each API interface can be obtained.
[0039] It should be noted that the transmission parameters determined in this embodiment can comprehensively evaluate the overall load of the interface in terms of both throughput and single request data volume, which is beneficial for comparing the resource consumption risks of API interfaces with different characteristics and scales.
[0040] S22, extract the peak QPS and P99 latency of each API interface from the call record data of each API interface; determine the call parameters of each API interface based on the peak QPS and P99 latency of each API interface.
[0041] Here, the calling parameters are used at least to characterize the abnormality of the API interface calling behavior.
[0042] Specifically, a dual-dimensional detection mechanism of traffic anomalies and performance anomalies is adopted, which is reflected by the QPS (Queries Per Second) ratio and latency ratio respectively. This embodiment combines the two dimensions to achieve comprehensive call anomaly monitoring from the outside to the inside.
[0043] In one embodiment, the formula for calculating the call parameters of the nth API interface can be: In the formula, This represents the call parameters for the nth API interface. This represents the average of all peak QPS for the nth API interface; This represents the baseline QPS of the nth API interface. The baseline QPS refers to the average QPS over a historical period, such as the average daily QPS over the past 30 days. This represents the P99 latency time for the nth API interface, in milliseconds, meaning that 99% of request response times do not exceed this time. This indicates the maximum allowable delay, which is set by the virtual power plant system, i.e., preset by humans.
[0044] In the calculation formula for the called parameters, It can reflect the relative magnitude of burst traffic at the nth API interface, and can be used to detect sudden anomalies at the traffic level. The larger the value, the greater the relative size of the burst traffic, indicating that the virtual power plant system may be under DDoS attack. It can reflect the relative latency of the nth API interface and is used to detect service-level performance anomalies. The larger the value, the closer the latency of most requests to the nth API interface is to the maximum allowable latency, which means that the nth API interface has experienced service degradation or potential failure.
[0045] Specifically, it uses historical benchmarks instead of fixed thresholds to ensure that the evaluation results reflect the degree of deviation from the normal level of the interface, thus possessing adaptability to business scenarios; it selects P99 latency instead of average latency to focus on the long-tail distribution of slow service requests, which is beneficial for sensitively capturing early signs of service degradation; two components and All of these are dimensionless ratios, which avoids direct numerical comparisons of different physical quantities, helps ensure the rationality of mathematical operations and the comparability of results, and makes all API interface call parameters have the same mathematical properties and interpretation standards.
[0046] Referring to the calculation process of the call parameters for the nth API interface above, the call parameters for each API interface can be obtained.
[0047] It should be noted that the calling parameters determined in this embodiment can issue early warning signals in the early stages of DDoS attacks or service failures, making it easier to distinguish between abnormal traffic and abnormal service performance, providing a clear direction for troubleshooting, and adapting to the differences in business characteristics and access patterns of different API interfaces.
[0048] As an exemplary implementation, all API interfaces are clustered in the feature space constructed from transmission parameters and invocation parameters, resulting in several API clusters, including: The first step is to combine the transmission parameters and call parameters of each API interface to obtain the type component parameters for each API interface. Then, the two-dimensional space formed by the type component parameters of all API interfaces is used as the feature space of the API interface.
[0049] In this embodiment, the feature space diagram of the API interface is as follows: Figure 4 As shown, in Figure 4 In this system, the transmission parameters are used as the horizontal axis of a two-dimensional Cartesian coordinate system, and the calling parameters are used as the vertical axis of a two-dimensional Cartesian coordinate system.
[0050] It should be noted that, due to the different functions of various API interfaces, a single entity typically requires multiple API interfaces to transmit data with the virtual power plant. Furthermore, the data types, transmission frequencies, and access control strengths differ among these API interfaces. To further enhance the effective segmentation of API interfaces, this embodiment establishes a feature space for each API interface. This facilitates subsequent effective flow control restrictions on different API interfaces, thereby improving the security of related data when accessing the virtual power plant through API interfaces.
[0051] The second step is to use the DBSCAN clustering algorithm in the feature space to cluster the API interfaces between each entity and the virtual power plant, resulting in several API clusters.
[0052] In this embodiment, firstly, the Euclidean distance between the type component parameters of different API interfaces in the feature space is used as the metric distance for the DBSCAN (Density-Based Spatial Clustering of Applications with Noise) clustering algorithm. Then, the DBSCAN clustering algorithm is used to cluster the API interfaces in the feature space, resulting in several API clusters. The implementation process of the DBSCAN clustering algorithm is existing technology and will not be described in detail here.
[0053] Thus, this embodiment clusters API interfaces, grouping those with similar transmission behavior into one category. This allows for differentiated rate limiting for different API interfaces based on their actual transmission needs and impact on data security.
[0054] S3. Analyze the API interface call situation in the API cluster based on the record data of each API interface in the same API cluster, and determine the basic call coefficient of each API cluster.
[0055] After clustering the API interfaces, API interfaces that are similar in terms of data transmission and call requests are grouped together. Since API interfaces in different clusters have different functions in the virtual power plant, they will receive call requests from multiple entities and have data transmission relationships with these entities. Therefore, this embodiment chooses to further analyze the call request and data transmission behavior of the numerous API interfaces of the virtual power plant, specifically analyzing the call request and data transmission behavior characteristics of the same type of API interface within its respective cluster, thereby obtaining the call anomaly degree of each API interface. First, the basic call coefficient used to quantify the call anomaly degree is determined.
[0056] Here, the basic call coefficient is used to characterize the overall call behavior abnormality of API interfaces in the API cluster. The larger the basic call coefficient, the higher the overall call behavior abnormality of the API interfaces in the corresponding API cluster. More stringent rate limiting measures are needed for the API interfaces in the API cluster to avoid system cascading failures or data security risks caused by abnormal call behavior of API interfaces in the corresponding API cluster.
[0057] As an exemplary implementation, step S3 described above can be achieved through... Figure 5 The steps shown are as follows: S31, for each API cluster, extract the transmission data and real-time transmission data volume of each API interface in each transmission from the transmission record data between each API interface and the user subject in the API cluster; determine the transmission characteristic value of the API cluster based on the transmission data and real-time transmission data volume of each API interface in each transmission.
[0058] As an exemplary implementation, the transmission characteristic values of the API cluster are determined based on the amount of data transmitted and the real-time transmission volume of each API interface in each transmission, including: The first step is to determine the sensitivity coefficient of each API interface in the API cluster during each transmission based on the data transmitted by each API interface in each transmission.
[0059] Here, the sensitivity coefficient can be determined by the classification results of the transmitted data identified by the neural network. The larger the sensitivity coefficient, the higher the sensitivity of the corresponding transmitted data and the greater the abnormality of the API interface call used for transmitting data.
[0060] In one embodiment, for each API interface in the API cluster, the transmitted data in each transmission is first identified using a neural network as highly sensitive, moderately sensitive, and low-sensitivity data. Then, sensitivity coefficients for different levels of sensitivity are preset based on experience. For example, the sensitivity coefficient for highly sensitive data is set to 1, the sensitivity coefficient for moderately sensitive data is set to 0.5, and the sensitivity coefficient for low-sensitivity data is set to 0.1.
[0061] Furthermore, when the transmitted data contains multiple sensitive data types simultaneously, the corresponding sensitivity coefficients are added together. For example, if a transmission contains both highly sensitive and low-sensitivity data, the sensitivity coefficient for that transmission is 1.1; if a transmission contains both highly sensitive and moderately sensitive data, the sensitivity coefficient for that transmission is 1.5. This process can be repeated to obtain the sensitivity coefficient for any number of transmissions.
[0062] The second step is to obtain the historical data volume of each API interface in the API cluster during each transmission under the historical baseline period.
[0063] In one embodiment, the duration of the historical reference period is the same as the duration of the current period, which is 24 hours, and the number of data transmissions can also be kept the same. If the number of data transmissions in the historical reference period is different from the number of data transmissions in the current period, in order to facilitate the analysis of the differences in the amount of data transmitted in the same transmission, the minimum number of transmissions is used in the subsequent calculation process of the transmission characteristic value.
[0064] The third step is to determine the transmission characteristic value of the API cluster based on the real-time transmission data volume, historical transmission data volume, and sensitivity coefficient of each API interface in each transmission.
[0065] Here, the calculation of transmission characteristic value consists of two parts. One is a comprehensive index of the intensity of sensitive data transmission in the current period, which reflects the real-time security status of API clusters at the data transmission level. The other is the degree of abnormal deviation relative to the historical normal pattern, which can detect hidden abnormal transmission patterns. By combining the transmission characteristic value determined by the two parts, multi-dimensional risk quantification and dynamic anomaly amplification can be reflected.
[0066] In one embodiment, the formula for calculating the transmission characteristic value of an API cluster can be: In the formula, This represents the transmission characteristic value of the API cluster, where I represents the number of data transmissions of the API interface within the current time period. This represents the average sensitivity coefficient of each API interface in the API cluster during the i-th transmission. This represents the cumulative value of the real-time data transmission volume for each API interface in the API cluster during the i-th transmission. This represents the cumulative amount of real-time data transmitted by each API interface in the API cluster during each transmission; that is, the total amount of real-time data transmitted by all API interfaces in the API cluster across all transmissions. Let represent the logarithmic function with base 2. This represents a hyperparameter, with an empirical value of 1. This represents the cumulative value of the historical data transmission volume of each API interface in the API cluster during the i-th transmission under the historical baseline period.
[0067] In the formula for calculating the transmission characteristic value, This can characterize the weighted proportion of data with different levels of sensitivity transmitted within the API cluster when data is transmitted to the virtual power plant via the API interface, within the current time period. The weighted proportion is calculated to determine the percentage of sensitive data; a higher proportion of highly weighted sensitive data indicates a higher percentage of sensitive data. The higher the value, the more sensitive data the API interfaces in the API cluster have transmitted within the current time period. It can characterize the comparison between the sensitive situation in the transmitted data in the current period and the sensitive situation in the historical benchmark data. If the amount of sensitive data suddenly increases, the feature value is amplified by a logarithmic function with a base of 2.
[0068] Furthermore, Mean of sensitivity coefficient Classifying the importance of each transmission reflects the differentiation of data security levels. This refers to converting the amount of a single transmission into a relative proportion, which eliminates the scaling effect of absolute values. The summation operation can achieve linear accumulation and aggregation of all transmission risks within the current time period. In Used to calculate the sensitive weighted deviation between the current and historical values, its summation is divided by the historical baseline weighted sum. It can calculate the relative rate of change. There is no possibility that the value will be zero. If an extreme case exists, a non-zero constant, such as 0.01, can be added to the denominator of the fraction. The logarithmic function can handle abnormal rates of change. Compressive amplification is employed, meaning that when the rate of change is small, the logarithm grows slowly to avoid oversensitivity, while when the rate of change is large, the logarithm continues to grow, but at a slower rate to prevent numerical explosion. Using a base of 2 facilitates threshold setting and interpretation under binary thinking, mapping potentially large change rates to a reasonable numerical range; hyperparameters It can guarantee the logarithmic function The parameter is always positive to avoid undefined calculation problems caused by negative or zero fraction values. It can also be used to control the degree to which the transmission characteristic value responds to abnormal changes. The value makes the variation of eigenvalues smoother, and a smaller value makes the variation more even. The value makes the feature value more sensitive to anomalies.
[0069] S32, extract the error rate of each API interface and the number of calls to each type of resource from the call record data of each API interface in the API cluster; determine the call characteristic value of the API cluster based on the peak QPS, P99 latency, error rate and the number of calls to each type of resource of each API interface in the API cluster.
[0070] Here, the call characteristic value is used to characterize, at least in the context of the current time period, the degree to which call exceptions exist when API interfaces in different clusters of virtual power plant API interfaces receive different call requests. The larger the call characteristic value, the greater the degree of call request exceptions in the corresponding API cluster.
[0071] In distributed system monitoring, a single metric may not be sufficient to capture complex anomaly patterns. By combining QPS, P99 latency, and error rate, the main risk dimensions of API calls are essentially covered, making the numerical reliability of the quantified call characteristic values more reliable and facilitating the generation of a more accurate rate-limiting mechanism for each API interface.
[0072] As an exemplary implementation, the call characteristic values of the API cluster are determined based on the peak QPS, P99 latency, error rate, and the number of call requests for each type of resource for each API interface in the API cluster, including: The first step is to determine the first characteristic factor of the API cluster based on the peak QPS of each API interface in the API cluster.
[0073] The second step is to determine the second characteristic factor of the API cluster class based on the P99 latency of each API interface in the API cluster class.
[0074] The third step is to determine the third characteristic factor of the API cluster class based on the error rate of each API interface in the API cluster class.
[0075] The fourth step is to determine the weight coefficient of each undetermined feature factor of the API cluster class based on the number of call requests for each type of resource received by each API interface in the API cluster class.
[0076] As an exemplary implementation, determining the weight coefficient of each undetermined feature factor of the API cluster class includes: The first sub-step is to obtain the total number of calls to each type of resource received by each API interface in the API cluster, and calculate the frequency ratio of the total number of calls to each type of resource corresponding to the API cluster in all calls, which is used as the request rate of the corresponding type of resource.
[0077] In one embodiment, firstly, the call requests received by the API interface are divided into energy scheduling requests, equipment monitoring requests, and user electricity consumption requests to obtain the call request status of each type of resource; then, the frequency ratio of the total number of call requests for each type of resource received by all interfaces in the API cluster in the current time period is obtained as the request rate of the corresponding type of resource, that is, the request rates of energy scheduling, equipment monitoring, and user electricity consumption corresponding to the API cluster are obtained.
[0078] The second sub-step involves determining the weight coefficient of each undetermined feature factor of the API cluster class based on the request rate of each type of resource.
[0079] When the energy dispatch request rate is at its maximum, it indicates that the probability of an energy dispatch request in the API cluster is relatively high. At this time, each API interface in the API cluster needs to be able to respond quickly to sudden traffic risks, such as attacks that forge dispatch instructions. The larger the first characteristic factor determined by the peak QPS, the more likely the API interface has a sudden traffic risk in the current period, and there may be DDoS attacks, such as malicious forging of energy trading requests. Therefore, the maximum energy dispatch request rate is used as the weight coefficient of the first characteristic factor.
[0080] When the device monitoring request rate is at its maximum, it indicates that the probability of device monitoring requests occurring in the API cluster is relatively high. Delay anomalies directly affect the reliability of device control. The larger the second characteristic factor determined by the P99 delay time, the greater the possibility of delay anomalies, such as malicious requests occupying the computing resources of the virtual power plant system. Therefore, the maximum device monitoring request rate is used as the weight coefficient of the second characteristic factor.
[0081] When the user electricity demand rate is at its maximum, it indicates that the API cluster is more likely to have access requests to user data. Therefore, the performance indicator error rate of the API interface is greater than the historical baseline error rate of the API interface within the API cluster. In other words, the third characteristic factor determined by the error rate is larger, indicating that the data in the virtual power plant is at greater risk of being tampered with or accessed without authorization. Therefore, the maximum user electricity demand rate is used as the weight coefficient of the third characteristic factor.
[0082] In one embodiment, the undetermined feature factors include a first, second, and third feature factor. Determining the weight coefficient of each undetermined feature factor for the API cluster class includes: If the energy dispatch request rate is the highest, then the weight coefficient of the first feature factor is equal to the energy dispatch request rate, and the weight coefficients of the second and third feature factors are equal to... , This represents the energy dispatch request rate; here, the weight coefficient of the first feature factor is equal to... The weight coefficient of the second characteristic factor is equal to The weight coefficient of the third feature factor is also equal to .
[0083] If the request rate for device monitoring is the highest, then the weight coefficient of the second feature factor is equal to the request rate for device monitoring, and the weight coefficients of the first and third feature factors are equal to... , This indicates the request rate for device monitoring.
[0084] If the user's electricity request rate is the highest, then the weight coefficient of the third feature factor is equal to the user's electricity request rate, and the weight coefficients of the second and third feature factors are equal to... , This indicates the user's electricity request rate.
[0085] The fifth step involves using the weight coefficients of each undetermined feature factor to perform weighted fusion processing on the corresponding undetermined feature factors of the API cluster class, thereby obtaining the call feature value of the API cluster class.
[0086] In one embodiment, the formula for calculating the call characteristic value of an API cluster class can be: In the formula, This represents the call characteristic value of the API cluster class. This represents the weight coefficient of the first feature factor. This represents the average peak QPS of all API interfaces in the API cluster. This represents the baseline QPS mean of all API interfaces in the API cluster. Represents the first characteristic factor of the API cluster class. This represents the weighting coefficient of the second characteristic factor. This represents the average P99 latency of all API interfaces in the API cluster. This indicates the maximum allowed latency for the API interface. The second characteristic factor representing the API cluster class, The weight coefficient of the third characteristic factor. This represents the average error rate of all API interfaces within the API cluster class. This represents the historical baseline error rate of API interfaces within an API cluster, specifically the average error rate of API interfaces within the same cluster over the past 30 days. This represents the third characteristic factor of the API cluster class.
[0087] In the calculation formula for the feature value, each undetermined feature factor uses the ratio of the current value to the baseline value, which eliminates the scale differences between different API interfaces and makes the evaluation results more comparable; all feature factors are in the form of dimensionless ratios, which allows indicators with different dimensions (i.e., QPS, latency, error rate) to be added directly, avoiding numerical distortion caused by inconsistent units; the three feature factors are linearly weighted and summed through weight coefficients, and the weights allow the importance of each feature factor to be adjusted according to business priorities.
[0088] S33, perform data fusion processing on the transmission characteristic value and call characteristic value of the API cluster class to obtain the basic call coefficient of the API cluster class.
[0089] In one embodiment, the transmission characteristic value and the call characteristic value of the API cluster are multiplied, and the resulting product is linearly normalized. The normalized value is then used as the basic call coefficient of the API cluster.
[0090] The formula for calculating the base call coefficient of the API cluster class can be: In the formula, The norm represents the base call coefficient of the API cluster class, and norm represents the linear normalization function. This represents the transmission characteristic value of the API cluster class. This represents the call characteristic value of the API cluster class.
[0091] By referring to the calculation process of the basic call coefficients of the API clusters mentioned above, the basic call coefficients of each API cluster can be obtained.
[0092] S4. Analyze the abnormal call situation of each API cluster class relative to other API cluster classes based on the basic call coefficient of each API cluster class, and determine the call abnormality of each API interface in each API cluster class.
[0093] Here, the call anomaly score describes the degree of anomalies in call requests and data transmission between the corresponding API cluster and other API clusters. When there are a large number of abnormal and malicious requests in the API call data, it indicates that the API may have vulnerabilities that could lead to data leakage or tampering in the virtual power plant, threatening data security. In such cases, the call anomaly score will be higher. A higher call anomaly score reflects a greater degree of abnormal or malicious requests in the API calls within the corresponding API cluster. Therefore, the corresponding API needs to be rate-limited more effectively to protect the virtual power plant data.
[0094] As an exemplary implementation, step S4 above can be achieved through the following steps: The first step is to calculate the average of the base call coefficients for all API clusters as a comparison call coefficient.
[0095] The second step is to determine the call anomaly degree of each API interface in each API cluster based on the difference between the base call coefficient and the comparison call coefficient for each API cluster.
[0096] In one embodiment, the formula for calculating the call anomaly degree of each API interface in the j-th API cluster class can be: In the formula, This represents the call anomaly degree of each API interface in the j-th API cluster class. This represents the base call coefficient for the j-th API cluster class. This represents the base call coefficient of the k-th API cluster class. This represents the comparison call coefficient, which is the average of the base call coefficients for all API clusters. This represents the maximum absolute deviation of the base call coefficients of all API clusters from the average value.
[0097] In the formula for calculating call anomaly score, the call anomaly score is the same for each API interface within the same API cluster. This represents the difference between the base call coefficient and the comparison call coefficient of the j-th API cluster class, which can be positive, negative, or zero. Used to achieve quantization The proportion of the maximum absolute deviation eliminates the influence of absolute values, allowing API clusters of different sizes to be compared with each other, and limiting the range of call anomaly values to between -1 and 1.
[0098] By referring to the calculation process of the call anomaly degree of each API interface in the j-th API cluster class, the call anomaly degree of each API interface in each API cluster class can be obtained.
[0099] S5 generates a corresponding rate-limiting mechanism for each API interface based on the call anomaly rate of each API interface.
[0100] Here, the request rate of the API interface is adjusted and limited by the API interface call anomaly rate.
[0101] As an exemplary implementation, a rate-limiting mechanism is generated for each API interface based on the call anomaly rate of each API interface, including: For each API interface, if the API interface call anomaly rate is less than or equal to the first anomaly threshold, the API interface rate limiting mechanism is determined to be in normal mode, and there is no rate limiting in normal mode.
[0102] In one embodiment, the API interface in normal mode allows the set QPS upper limit baseline value to be reached.
[0103] If the API call anomaly level is greater than the first anomaly threshold but less than or equal to the second anomaly threshold, the API rate limiting mechanism is determined to be in warning mode, and the warning mode is dynamic rate limiting.
[0104] As an exemplary implementation, the expression for dynamic speed limiting is: In the formula, This indicates the adjustment of the request rate for the API interface, i.e., the rate limit value. Indicates the upper limit baseline value. This indicates the degree of exception in API call.
[0105] If the API call anomaly level exceeds the second anomaly threshold, the API rate limiting mechanism is determined to be in emergency mode, which is a strict rate limiting mechanism.
[0106] As an exemplary implementation, the expression for strict speed limiting is: .
[0107] In this embodiment, the second abnormal threshold is greater than the first abnormal threshold. The first abnormal threshold can be taken as an empirical value of 0, and the second abnormal threshold can be taken as an empirical value of 0.5. The second abnormal threshold and the first abnormal threshold can be set by the implementer according to the specific actual situation, and no specific limitation is made here.
[0108] Furthermore, configure rate-limiting plugins for different API clusters in Kong or Apigee, and combine the rate-limiting value with the corresponding API interface to apply rate limiting. A diagram illustrating API rate limiting based on call anomaly is shown below. Figure 6 As shown.
[0109] Kong and Apigee are existing API gateways that can provide management functions for API interfaces, including request routing, access control, monitoring, and analysis.
[0110] Thus, this embodiment achieves data security protection for the virtual power plant through API interface rate limiting.
[0111] Another embodiment of the present invention provides a virtual power plant data security protection system, comprising: The data acquisition module is used to acquire the record data of each API interface in the API library of the virtual power plant during the current time period; the record data includes call record data and transmission record data between the API interface and the user entity; The interface clustering module is used to determine the transmission parameters and calling parameters of each API interface based on the recorded data of each API interface; and to cluster all API interfaces in the feature space constructed by the transmission parameters and calling parameters to obtain several API clusters. The first determining module is used to analyze the API interface call situation in the API cluster based on the record data of each API interface in the same API cluster, and determine the basic call coefficient of each API cluster. The second determination module is used to analyze the abnormal call situation of each API cluster class relative to other API cluster classes based on the basic call coefficient of each API cluster class, and to determine the call abnormality degree of each API interface in each API cluster class. The rate limiting generation module is used to generate a corresponding rate limiting mechanism for each API interface based on the call anomaly rate of each API interface.
[0112] Another embodiment of the present invention provides an electronic device including a processor and a memory, the processor being used to process instructions stored in the memory to implement a virtual power plant data security protection method.
[0113] This invention provides a method, system, and electronic device for protecting data security in virtual power plants. By determining the call anomaly level for each API cluster, it can adaptively generate corresponding rate limiting mechanisms for API interfaces. This not only protects highly sensitive interfaces and ensures real-time data channels, but also improves data security when API interfaces access virtual power plant data, while also optimizing resource allocation to a certain extent.
[0114] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A method for data security protection in a virtual power plant, characterized in that, Includes the following steps: Obtain the record data for each API interface in the API library of the virtual power plant during the current time period; the record data includes at least call record data and transmission record data between the API interface and the user entity; The transmission parameters and call parameters of each API interface are determined based on the recorded data of each API interface; all API interfaces are clustered in the feature space constructed by the transmission parameters and call parameters to obtain several API clusters. Analyze the API call behavior of each API interface in the same API cluster to determine the basic call coefficient of each API cluster. Based on the basic call coefficient of each API cluster, analyze the abnormal call situation of the API cluster relative to other API clusters, and determine the call abnormality of each API interface in each API cluster. A corresponding rate-limiting mechanism is generated for each API interface based on the call anomaly rate of each API interface; The process of determining the transmission parameters and call parameters of each API interface based on the recorded data of each API interface includes: Extract the average daily data throughput and the allowed data volume per request for each API interface from the transmission record data between each API interface and the user entity; determine the transmission parameters for each API interface based on the average daily data throughput and the allowed data volume per request. Extract the peak QPS and P99 latency of each API interface from the call record data of each API interface; determine the call parameters of each API interface based on the peak QPS and P99 latency of each API interface. The step of analyzing the API interface call behavior within an API cluster based on the recorded data of each API interface in the same API cluster, and determining the basic call coefficient for each API cluster, includes: For each API cluster, extract the transmission data and real-time transmission volume of each API interface in each transmission from the transmission record data between each API interface and the user entity in the API cluster; determine the transmission characteristic value of the API cluster based on the transmission data and real-time transmission volume of each API interface in each transmission. From the call record data of each API interface in the API cluster, extract the error rate of each API interface and the number of call requests for each type of resource; based on the peak QPS, P99 latency, error rate and the number of call requests for each type of resource of each API interface in the API cluster, determine the call characteristic value of the API cluster. Data fusion processing is performed on the transmission characteristic values and call characteristic values of API clusters to obtain the basic call coefficients of API clusters.
2. The method for data security protection of a virtual power plant according to claim 1, characterized in that, The step of determining the transmission characteristic value of the API cluster based on the amount of data transmitted and the amount of real-time data transmitted by each API interface in each transmission includes: Based on the data transmitted by each API interface in the API cluster during each transmission, the sensitivity coefficient of each API interface in the API cluster during each transmission is determined; the sensitivity coefficient is determined by identifying the classification results of the transmitted data through a neural network. Obtain the historical data volume of each API interface in the API cluster during each transmission under the historical baseline period; The transmission characteristic value of the API cluster is determined based on the real-time data transmission volume of each API interface in the API cluster during each transmission, the historical data transmission volume, and the sensitivity coefficient.
3. The method for data security protection of a virtual power plant according to claim 2, characterized in that, The formula for calculating the transmission characteristic value of the API cluster is as follows: In the formula, This represents the transmission characteristic value of the API cluster, where I represents the number of data transmissions of the API interface within the current time period. This represents the average sensitivity coefficient of each API interface in the API cluster during the i-th transmission. This represents the cumulative value of the real-time data transmission volume for each API interface in the API cluster during the i-th transmission. This represents the cumulative amount of real-time data transmitted by each API interface in the API cluster during each transmission. Let represent the logarithmic function with base 2. Indicates hyperparameters, This represents the cumulative value of the historical data transmission volume of each API interface in the API cluster during the i-th transmission under the historical baseline period.
4. The method for data security protection of a virtual power plant according to claim 1, characterized in that, The process of determining the call characteristic values of an API cluster based on the peak QPS, P99 latency, error rate, and the number of call requests for each resource type for each API interface within the API cluster includes: The first characteristic factor of the API cluster is determined based on the peak QPS of each API interface in the API cluster. The second characteristic factor of the API cluster class is determined based on the P99 latency of each API interface in the API cluster class. The third characteristic factor of the API cluster is determined based on the error rate of each API interface in the API cluster. The weight coefficient of each undetermined feature factor of the API cluster is determined based on the number of call requests for each type of resource received by each API interface in the API cluster; the undetermined feature factors include the first, second and third feature factors. The corresponding undetermined feature factors of the API cluster are weighted and fused using the weight coefficient of each undetermined feature factor to obtain the call feature value of the API cluster.
5. The method for data security protection of a virtual power plant according to claim 4, characterized in that, The step of determining the weight coefficient of each undetermined feature factor of the API cluster class based on the number of call requests for each type of resource received by each API interface in the API cluster class includes: Obtain the total number of call requests for each type of resource received by each API interface in the API cluster, and calculate the frequency ratio of the total number of call requests for each type of resource corresponding to the API cluster in all call requests, as the request rate of the corresponding type of resource; the resources include energy scheduling, equipment monitoring and user electricity consumption; Based on the request rate of each type of resource, determine the weight coefficient of each undetermined feature factor of the API cluster.
6. The method for data security protection of a virtual power plant according to claim 5, characterized in that, The step of determining the weight coefficient of each undetermined feature factor of the API cluster class based on the request rate of each type of resource includes: If the energy dispatch request rate is maximized, then the weight coefficient of the first feature factor is equal to the energy dispatch request rate, and the weight coefficients of the second and third feature factors are equal to... , Indicates the energy dispatch request rate; If the request rate for device monitoring is the highest, then the weight coefficient of the second feature factor is equal to the request rate for device monitoring, and the weight coefficients of the first and third feature factors are equal to... , This indicates the request rate for device monitoring; If the user's electricity request rate is the highest, then the weight coefficient of the third feature factor is equal to the user's electricity request rate, and the weight coefficients of the second and third feature factors are equal to... , This indicates the user's electricity request rate.
7. A virtual power plant data security protection system, characterized in that, include: The data acquisition module is used to acquire the record data of each API interface in the API library of the virtual power plant during the current time period; the record data includes call record data and transmission record data between the API interface and the user entity; The interface clustering module is used to determine the transmission parameters and calling parameters of each API interface based on the recorded data of each API interface; and to cluster all API interfaces in the feature space constructed by the transmission parameters and calling parameters to obtain several API clusters. The first determining module is used to analyze the API interface call situation in the API cluster based on the record data of each API interface in the same API cluster, and determine the basic call coefficient of each API cluster. The second determination module is used to analyze the abnormal call situation of each API cluster relative to other API clusters based on the basic call coefficient of each API cluster, and to determine the call abnormality of each API interface in each API cluster. The rate limit generation module is used to generate a corresponding rate limit mechanism for each API interface based on the call anomaly rate of each API interface. The process of determining the transmission parameters and call parameters of each API interface based on the recorded data of each API interface includes: Extract the average daily data throughput and the allowed data volume per request for each API interface from the transmission record data between each API interface and the user entity; determine the transmission parameters for each API interface based on the average daily data throughput and the allowed data volume per request. Extract the peak QPS and P99 latency of each API interface from the call record data of each API interface; determine the call parameters of each API interface based on the peak QPS and P99 latency of each API interface. The step of analyzing the API interface call behavior within an API cluster based on the recorded data of each API interface in the same API cluster, and determining the basic call coefficient for each API cluster, includes: For each API cluster, extract the transmission data and real-time transmission volume of each API interface in each transmission from the transmission record data between each API interface and the user entity in the API cluster; determine the transmission characteristic value of the API cluster based on the transmission data and real-time transmission volume of each API interface in each transmission. From the call record data of each API interface in the API cluster, extract the error rate of each API interface and the number of call requests for each type of resource; based on the peak QPS, P99 latency, error rate and the number of call requests for each type of resource of each API interface in the API cluster, determine the call characteristic value of the API cluster. Data fusion processing is performed on the transmission characteristic values and call characteristic values of API clusters to obtain the basic call coefficients of API clusters.
8. An electronic device, characterized in that, It includes a processor and a memory, the processor being used to process instructions stored in the memory to implement a virtual power plant data security protection method as described in any one of claims 1-6.