Versioning control method, device and equipment of energy storage polymerization state and storage medium

Abstract

The application relates to a version control method, device and equipment of an energy storage aggregation state and a storage medium. The method comprises the following steps: constructing a convex feasible region of an energy storage device, generating a versioned constraint certificate, and calculating a current aggregation parameter based on the certificate; in response to a dynamic event of the energy storage device, calculating an aggregation parameter difference, and determining an operation point dependency relationship according to a comparison result of an aggregation version number saved by the operation point and an aggregation version submitted before the dynamic event; jointly checking the certificate, the difference and the operation point, and if the checking is passed, atomically submitting to form a new aggregation version, and if the checking is not passed or is interrupted, rolling back as a whole to keep the old version unchanged; and generating a power setting value and corresponding version information based on a currently submitted aggregation version and delivering the power setting value and the corresponding version information to an energy storage device controller. The method can guarantee that the aggregation parameter, the certificate and the operation point are synchronously switched when the dynamic event occurs, avoid a half-updated state from entering actual control, and ensure consistency of device-side instruction versions.

Description

Technical Field

[0001] This application relates to the field of energy storage technology, and in particular to a versioned control method, apparatus, computer equipment, computer-readable storage medium, and computer program product for energy storage aggregation state. Background Technology

[0002] With the development of energy storage technology, static aggregation technology has emerged. This technology represents the adjustable capability of each energy storage device in a control time domain as a convex feasible domain, and then obtains a low-dimensional aggregated feasible domain by clustering and approximating within a common prototype. The scaling and translation parameters of the common prototype can be added together, and the instructions in the aggregated inner domain are mapped back to the individual devices, thereby enabling a large number of heterogeneous energy storage devices to participate in grid ancillary services such as frequency regulation, backup, or peak shaving and valley filling.

[0003] However, current traditional methods cannot guarantee the synchronous switching of aggregation parameters, certificates, and operation points during dynamic event processing, which may result in the control side reading an invalid aggregation state composed of spliced ​​old and new data. Summary of the Invention

[0004] Based on this, it is necessary to provide a versioned control method, device, computer equipment, computer-readable storage medium, and computer program product that can ensure the synchronous switching of aggregation parameters, certificates, and operating points when dynamic events occur, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a versioned control method for energy storage aggregation state, including:

[0006] Obtain the aggregated versions of the device's convex feasible region and dynamic events that have been submitted before; the device's convex feasible region is formed by the power boundary and the energy state or state of charge boundary;

[0007] A versioned constraint certificate is generated based on the device's convex feasible region. The versioned constraint certificate includes at least the device identifier, device status version, cluster identifier, cluster prototype version, and the scaling and translation amount used to make the cluster prototype contained within the device's convex feasible region after scaling and translation.

[0008] Calculate the current aggregate parameters of the energy storage device based on versioned constraint certificates;

[0009] In response to dynamic events of energy storage devices, the aggregate parameter difference is calculated based on the versioned constraint certificate corresponding to the dynamic event; based on the comparison between the aggregate version number saved at the operation point and the aggregate version submitted before the dynamic event, the operation point that depends on the aggregate version submitted before the dynamic event is determined.

[0010] Perform joint verification of versioned constraint certificates, aggregate parameter differences, and operation points;

[0011] If the joint verification passes, the versioned constraint certificate, the sum of the current aggregate parameters and the difference between the aggregate parameters, and the operation point are atomically committed as the same transaction to form a new currently committed aggregate version; if the joint verification fails or the transaction is interrupted, the entire process is rolled back while maintaining the aggregate version committed before the dynamic event.

[0012] Based on the currently submitted aggregate version, generate the power setting value and its corresponding aggregate version, device status version and certificate identifier, and send it to the energy storage device controller.

[0013] In one embodiment, calculating the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event includes:

[0014] When energy storage devices are connected, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are added as positive difference to the current aggregation parameters.

[0015] When an energy storage device exits, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are deducted from the current aggregation parameters as a negative difference.

[0016] When the capacity of energy storage devices decreases, the scaling difference and translation difference of the versioned constraint certificate corresponding to the dynamic event are used as replacement differences to update the current aggregation parameters.

[0017] In one embodiment, joint verification is performed on the versioned constraint certificate, aggregate parameter difference, and operation point, including:

[0018] Verify whether the scaling and translation of the versioned constraint certificate satisfy the inclusion relationship;

[0019] Verify that the device status version matches the clustering prototype version;

[0020] Verify whether the sum of the current aggregation parameter and the difference between the aggregation parameters is consistent with the result of summing all versioned constraint certificates again;

[0021] Verify the validity of the operation point or whether the cluster corresponding to the cluster identifier is in a non-empty state.

[0022] In one embodiment, the method further includes:

[0023] When creating a new currently committed aggregate version, the operation point of the aggregate version that was committed before the dynamic event will be deleted;

[0024] The remaining operation points are revalidated within the convex feasible region corresponding to the current aggregation parameter and then updated to the current aggregation version.

[0025] Secondly, this application provides a versioned control method for energy storage aggregation state, including:

[0026] Receive power settings and their corresponding device status version and certificate identifier;

[0027] Compare the received device status version with the local device status version to see if they are consistent, verify whether the power setting value meets the local device constraints, and check whether the certificate identifier is valid.

[0028] If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller will execute the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller will refuse to execute the power setting value.

[0029] In one embodiment, if the version is inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to execute the power setpoint, including:

[0030] Freeze local certificate-based control, disable the corresponding operation point, and switch to a conservative control strategy;

[0031] Conservative control strategies include at least one of maintaining the most recent safety setting, switching to a preset baseline, zero power control, or exiting aggregate control.

[0032] Thirdly, this application also provides a versioned control system for energy storage aggregation status, including:

[0033] The energy storage aggregation control platform obtains the device convex feasible region and the aggregated version submitted before dynamic events of the energy storage device; the device convex feasible region is formed by the power boundary and the energy state or state of charge boundary;

[0034] The energy storage aggregation control platform generates versioned constraint certificates based on the convex feasible domain of the device. The versioned constraint certificate includes at least the device identifier, device status version, cluster identifier, cluster prototype version, and the scaling and translation amount used to make the cluster prototype included in the convex feasible domain of the device after scaling and translation.

[0035] The energy storage aggregation control platform calculates the current aggregation parameters of energy storage devices based on versioned constraint certificates;

[0036] The energy storage aggregation control platform responds to dynamic events of energy storage devices and calculates aggregation parameter differences based on the versioned constraint certificates corresponding to the dynamic events. Based on the comparison results between the dependency version number saved at the operation point and the aggregation version submitted before the dynamic event, it determines the operation point that depends on the aggregation version submitted before the dynamic event.

[0037] The energy storage aggregation control platform performs joint verification of versioned constraint certificates, aggregation parameter differences, and operation points;

[0038] If the joint verification passes, the energy storage aggregation control platform will atomically commit the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process will be rolled back while maintaining the aggregation version committed before the dynamic event.

[0039] The energy storage aggregation control platform generates power setpoints and their corresponding device status versions and certificate identifiers based on the currently submitted aggregation versions, and then distributes them to the energy storage device controllers.

[0040] The energy storage device controller receives the power setpoint and its corresponding device status version and certificate identifier;

[0041] The energy storage device controller compares the received device status version with the local device status version to check whether the power setting value meets the local device constraints and whether the certificate identifier is valid.

[0042] If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller will execute the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller will refuse to execute the power setting value.

[0043] Fourthly, this application also provides a computer device including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps performed by any possible implementation of any of the first to third aspects.

[0044] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps performed by any possible implementation of any of the first to third aspects.

[0045] Sixthly, this application also provides a computer program product. The computer program product includes a computer program, which, when executed by a processor, performs the steps of any possible implementation of any of the first to third aspects.

[0046] The aforementioned versioned control method, apparatus, computer equipment, computer-readable storage medium, and computer program product for energy storage aggregation states first construct a convex feasible region for the energy storage device. This convex feasible region is formed by the power boundary and the energy state boundary or charge state boundary. Based on this, a versioned constraint certificate is generated, containing a device identifier, device state version, cluster identifier, cluster prototype version, and scaling and translation amounts. The scaling and translation amounts ensure that the cluster prototype is completely contained within the device's convex feasible region after scaling and translation. Subsequently, the current aggregation parameters of the energy storage device are calculated based on the versioned constraint certificate. Furthermore, when a dynamic event occurs in the energy storage device, the aggregation parameters are calculated based on the versioned constraint certificate corresponding to that event. The system first calculates the difference in aggregate parameters and then compares the aggregate version number saved at the operation point with the aggregate version committed before the dynamic event to determine the dependency relationship between the operation point and the previous aggregate version. Next, it performs a joint verification of the versioning constraint certificate, the aggregate parameter difference, and the operation point. If the verification passes, the versioning constraint certificate, the sum of the current aggregate parameters and the aggregate parameter difference, and the operation point are atomically committed as a single transaction to form a new currently committed aggregate version. If the verification fails or the transaction is interrupted, the entire process is rolled back while maintaining the aggregate version before the dynamic event. Finally, based on the currently committed aggregate version, the system generates a power setting value and its corresponding aggregate version, device status version, and certificate identifier, and sends this information to the energy storage device controller. By introducing versioned constraint certificates and atomic transaction commit mechanisms, the strong consistency and traceability of the energy storage aggregation state under dynamic event disturbances are ensured, avoiding data inconsistency issues caused by concurrent operations or abnormal interruptions. The joint verification and overall rollback strategy significantly improves the system's fault tolerance to parameter conflicts and abnormal events. At the same time, the version number-based dependency judgment ensures the correctness of operation point calculation, thereby enhancing the robustness of aggregation control. In addition, the standardized certificate expression and power setpoint distribution method reduce the coordination complexity between devices, which is conducive to achieving efficient, safe scheduling and flexible expansion of large-scale energy storage systems. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is an application environment diagram of a versioned control method for energy storage aggregation state in one embodiment;

[0049] Figure 2 This is a flowchart illustrating a version control method for energy storage aggregation state in one embodiment;

[0050] Figure 3 This is a flowchart illustrating the steps of a version control method for energy storage aggregation state in one embodiment;

[0051] Figure 4 This is a clustering result diagram of the geometric features of the support function in another embodiment;

[0052] Figure 5 This is a comparison chart of the complete method under dynamic events and ablation without version binding in another embodiment;

[0053] Figure 6 This is a diagram showing the results of re-verification of the old operating point after capacity reduction in another embodiment;

[0054] Figure 7 This is a diagram showing the result of abnormal branch coverage in another embodiment;

[0055] Figure 8 Here is a timeline diagram for ledger maintenance under different certificate record sizes in another embodiment;

[0056] Figure 9 This is a structural block diagram of a versioned control device for energy storage aggregation state in one embodiment;

[0057] Figure 10 This is a structural block diagram of a versioned control device for energy storage aggregation state in another embodiment;

[0058] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0060] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0061] The versioned control method for energy storage aggregation status provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, the energy storage device controller 102 communicates with the energy storage aggregation control platform 104 via a network. The data storage system can store the data that the energy storage aggregation control platform 104 needs to process. The data storage system can be integrated onto the energy storage aggregation control platform 104 or placed on the cloud or other network servers. First, a convex feasible region of the energy storage device is constructed. This convex feasible region is formed by the power boundary and the energy state boundary or charge state boundary. Based on this, a versioned constraint certificate containing device identifier, device state version, cluster identifier, cluster prototype version, and scaling and translation amounts is generated. The scaling and translation amounts are used to ensure that the cluster prototype is completely contained within the device's convex feasible region after scaling and translation. Then, the current aggregation parameters of the energy storage device are calculated based on the versioned constraint certificate. When a dynamic event occurs in the energy storage device, the aggregation parameter difference is calculated based on the versioned constraint certificate corresponding to the event. Simultaneously, the aggregation version number and dynamic data stored at the operation point are considered. The comparison results of the aggregated versions committed before the event determine the dependency of the operation point on the previous aggregated version. Then, the versioned constraint certificate, the difference in aggregate parameters, and the operation point are jointly verified. If the verification passes, the versioned constraint certificate, the sum of the current aggregate parameters and the difference in aggregate parameters, and the operation point are atomically committed as the same transaction to form a new currently committed aggregated version. If the verification fails or the transaction is interrupted, the entire process is rolled back while keeping the aggregated version before the dynamic event unchanged. Finally, based on the currently committed aggregated version, the power setting value and its corresponding aggregated version, device status version, and certificate identifier are generated, and this information is sent to the energy storage device controller.

[0062] The energy storage device controller 102 may be, but is not limited to, at least one of a battery management system (BMS), a local energy management system (Local EMS), an energy storage converter controller (PCS Controller), or a local control unit integrated into the energy storage device. The energy storage aggregation control platform 104 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0063] In one exemplary embodiment, such as Figure 2 As shown, a versioned control method for energy storage aggregation state is provided, which can be applied to... Figure 1 The following steps are used as an example to illustrate the process of energy storage aggregation control platform 104, including steps 202 to 214. Wherein:

[0064] Step 202: Obtain the device convex feasible region and the aggregated version submitted before dynamic events for the energy storage device; the device convex feasible region is formed by the power boundary and the energy state or state of charge boundary.

[0065] The convex feasible region of a device refers to the set of all feasible operating points in the parameter space composed of power and energy or state of charge, which is jointly defined by power boundary constraints and energy or state of charge boundary constraints. This set is convex, meaning that any linear combination between any two points in the set still lies within the set. The aggregate version committed before the dynamic event refers to the latest aggregate state record that has been confirmed and persisted before the current dynamic event is triggered, after a complete atomic commit process. This record contains aggregate parameter values ​​and their corresponding version identification information.

[0066] Step 204: Generate a versioned constraint certificate based on the device's convex feasible region. The versioned constraint certificate includes at least the device identifier, device status version, cluster identifier, cluster prototype version, and the scaling and translation amount used to make the cluster prototype included in the device's convex feasible region after scaling and translation.

[0067] The scaling amount is used to scale the geometric dimensions of the cluster prototype proportionally or non-proportionally, and the translation amount is used to move the scaled cluster prototype in the parameter space. The scaling and translation operations are used together to ensure that the cluster prototype falls completely within the range defined by the convex feasible region of the device geometrically. The certificate identifier is used to uniquely identify the versioned constraint certificate to support certificate query, verification and traceability.

[0068] For example, the device identifier and current device status version are obtained, the cluster identifier and the latest cluster prototype version corresponding to the cluster to which the device belongs are queried, the optimal scaling and translation amount required to include the cluster prototype in the convex feasible region of the device is calculated by the optimization algorithm, and the above information is assembled into a versioned constraint certificate according to the certificate data structure.

[0069] Step 206: Calculate the current aggregate parameters of the energy storage device based on the versioned constraint certificate;

[0070] Among them, the current aggregation parameter refers to the equivalent operating parameter required for the energy storage device to participate in aggregation scheduling at the current moment. This parameter is used to characterize the actual external characteristics of the device after scaling and translation adjustment based on the cluster prototype. The specific form of the aggregation parameter includes, but is not limited to, the vertex coordinates of the power-energy feasible region, the coefficients of the fitting polynomial, or key values ​​describing the external characteristics of the device.

[0071] For example, the cluster prototype version, scaling amount, and translation amount are parsed from the versioned constraint certificate. The corresponding baseline cluster prototype data is obtained according to the cluster prototype version. The baseline cluster prototype data is scaled using the scaling amount, and then the scaled data is translated using the translation amount. The processing result is used as the current aggregation parameter of the energy storage device. The current aggregation parameters of each energy storage device in the same cluster are accumulated to obtain the current aggregation parameter of the cluster.

[0072] Step 208: In response to dynamic events of the energy storage device, calculate the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event; and determine the operation point that depends on the aggregate version submitted before the dynamic event based on the comparison between the aggregate version number saved at the operation point and the aggregate version submitted before the dynamic event.

[0073] For example, when a dynamic event is detected in an energy storage device, the versioned constraint certificate corresponding to the dynamic event is obtained. The scaling and translation values ​​are parsed from the certificate, and the aggregation parameters corresponding to the dynamic event are calculated in combination with the corresponding clustering prototype data. According to the type of the dynamic event, the calculated aggregation parameters are compared with the aggregation parameters submitted before the dynamic event to obtain the aggregation parameter difference. Specifically, if the dynamic event is an access event, the aggregation parameters corresponding to the newly added certificate are directly used as a positive difference; if it is an exit event, the aggregation parameters corresponding to the valid certificate before the event are used as a negative difference; if it is a capacity degradation event, the difference between the aggregation parameters of the replaced certificate and the certificate before replacement is calculated as the replacement difference. At the same time, the aggregation version number saved at the operation point is read and compared with the version number of the aggregation version submitted before the dynamic event. If the two are consistent, it is determined that the operation point depends on the aggregation version submitted before the dynamic event.

[0074] Step 210: Perform joint verification of the versioned constraint certificate, aggregate parameter difference, and operation point;

[0075] Joint verification refers to the process of comprehensively verifying the validity of versioned constraint certificates, the rationality of aggregate parameter differences, and the legality of operation points.

[0076] For example, the versioned constraint certificate is parsed, the certificate identifier is verified to be valid and not revoked, and it is confirmed that the device status version and the cluster prototype version both match the current status; the difference in aggregation parameters is verified to be within the preset allowable range; the operation point is verified to be within the feasible domain corresponding to the aggregation version submitted before the dynamic event; if all items pass, the joint verification passes, otherwise it fails.

[0077] Step 212: If the joint verification passes, the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point are atomically committed as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process is rolled back while maintaining the aggregation version committed before the dynamic event.

[0078] Atomic commit refers to executing the update operations of multiple data items as an indivisible whole, where all updates either all succeed or all fail; overall rollback refers to undoing all temporary update operations when a transaction fails or is interrupted, restoring the system state to the state before the transaction began.

[0079] For example, after confirming that all joint verifications have passed, the energy storage aggregation control platform initiates an atomic commit transaction, writing the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point as an atomic transaction. This updates the certificate record, aggregation parameters, and operation point status all at once, and a new currently committed aggregation version is formed upon successful commit. If the joint verification fails or the transaction is interrupted, an overall rollback is triggered, discarding temporary data and keeping the aggregation version committed before the dynamic event unchanged.

[0080] Step 214: Generate power setting values ​​and their corresponding aggregation versions, device status versions, and certificate identifiers based on the currently submitted aggregation versions, and send them to the energy storage device controller.

[0081] The power setpoint refers to the target charging and discharging power that the energy storage device should perform, calculated based on the currently submitted aggregate version.

[0082] For example, the aggregation parameters are extracted from the currently submitted aggregation version, the aggregation parameters are input into the power calculation model to calculate the power setpoint, and the aggregation version number, device status version and certificate identifier corresponding to the aggregation version are obtained. The power setpoint is associated with the above version information, packaged and sent to the energy storage device controller through the communication network.

[0083] In the aforementioned versioned control method for energy storage aggregation states, the first step is to construct the convex feasible region of the energy storage device. This convex feasible region is formed by the power boundary and the energy state boundary or charge state boundary. Based on this, a versioned constraint certificate is generated, which includes the device identifier, device state version, cluster identifier, cluster prototype version, and scaling and translation amounts. The scaling and translation amounts are used to ensure that the cluster prototype is completely contained within the device's convex feasible region after scaling and translation. Subsequently, the current aggregation parameters of the energy storage device are calculated based on the versioned constraint certificate. When a dynamic event occurs in the energy storage device, the aggregation parameter difference is calculated based on the versioned constraint certificate corresponding to the event. Simultaneously, the operation point is saved. The dependency of the operation point on the previous aggregation version is determined by comparing the aggregation version number with the aggregation version committed before the dynamic event. Then, the versioning constraint certificate, aggregation parameter difference, and operation point are jointly verified. If the verification passes, the versioning constraint certificate, the sum of the current aggregation parameter and the aggregation parameter difference, and the operation point are atomically committed as the same transaction to form a new currently committed aggregation version. If the verification fails or the transaction is interrupted, the entire process is rolled back while keeping the aggregation version before the dynamic event unchanged. Finally, based on the currently committed aggregation version, the power setting value and its corresponding aggregation version, device status version, and certificate identifier are generated and this information is sent to the energy storage device controller. By introducing versioned constraint certificates and atomic transaction commit mechanisms, the strong consistency and traceability of the energy storage aggregation state under dynamic event disturbances are ensured, avoiding data inconsistency issues caused by concurrent operations or abnormal interruptions. The joint verification and overall rollback strategy significantly improves the system's fault tolerance to parameter conflicts and abnormal events. At the same time, the version number-based dependency judgment ensures the correctness of operation point calculation, thereby enhancing the robustness of aggregation control. In addition, the standardized certificate expression and power setpoint distribution method reduce the coordination complexity between devices, which is conducive to achieving efficient, safe scheduling and flexible expansion of large-scale energy storage systems.

[0084] In one embodiment, calculating the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event includes:

[0085] When energy storage devices are connected, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are added as positive difference to the current aggregation parameters.

[0086] When an energy storage device exits, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are deducted from the current aggregation parameters as a negative difference.

[0087] When the capacity of energy storage devices decreases, the scaling difference and translation difference of the versioned constraint certificate corresponding to the dynamic event are used as replacement differences to update the current aggregation parameters.

[0088] Specifically, the energy storage aggregation control platform responds to dynamic events of energy storage devices and calculates aggregation parameter differences in different ways according to the type of dynamic event: If it is a device access, it obtains the newly added versioned constraint certificate of the device, adds its scaling and translation as positive differences to the current aggregation parameters, and marks the certificate as valid; if it is a device exit, it obtains the versioned constraint certificate of the device that was valid before the event, deducts its scaling and translation as negative differences from the current aggregation parameters, and marks the certificate as invalid; if it is a device capacity degradation, it obtains the versioned constraint certificates before and after the replacement, calculates the scaling and translation differences between the replacement certificate and the original certificate as replacement differences, updates the current aggregation parameters, and marks the original certificate as invalid and the replacement certificate as valid.

[0089] In the above embodiments, by adopting differentiated processing strategies of adding positive differentials, deducting negative differentials, and updating differentials by replacing differentials for three typical dynamic events of energy storage device access, exit, and capacity degradation, the aggregate parameters are accurately adjusted incrementally when the device state changes. This avoids the computational overhead and communication burden caused by re-performing a complete aggregation calculation after each dynamic event, significantly improving the real-time performance and computational efficiency of the aggregate parameters update. At the same time, the differential calculation method based on versioned constraint certificates ensures that each adjustment is based on evidence and version controllable, effectively preventing the accumulation of errors and state drift problems in the parameter update process, and enhancing the dynamic response capability and robustness of the aggregation control system in scenarios of frequent large-scale device access and exit and capacity fluctuations.

[0090] In one embodiment, joint verification is performed on the versioned constraint certificate, aggregate parameter difference, and operation point, including:

[0091] Verify whether the scaling and translation of the versioned constraint certificate satisfy the inclusion relationship;

[0092] Verify that the device status version matches the clustering prototype version;

[0093] Verify whether the sum of the current aggregation parameter and the difference between the aggregation parameters is consistent with the result of summing all versioned constraint certificates again;

[0094] Verify the validity of the operation point or whether the cluster corresponding to the cluster identifier is in a non-empty state.

[0095] Specifically, when the energy storage aggregation control platform performs joint verification of versioned constraint certificates, aggregation parameter differences, and operation points, it must perform the following four verifications: First, verify whether the scaling and translation of the certificate satisfy the relationship that the cluster prototype is contained within the convex feasible region of the device after scaling and translation; second, verify whether the device state version bound in the certificate matches the cluster prototype version; third, verify whether the sum of the current aggregation parameter and the aggregation parameter difference is consistent with the result of resuming all versioned constraint certificates to verify the correctness of the difference calculation; finally, verify the validity of the operation point or whether the cluster is empty to ensure that the operation point is not incorrectly retained or used when the cluster has no members. Only when all four verifications pass will the energy storage aggregation control platform allow the atomic commit to be performed; otherwise, a full rollback will be triggered.

[0096] In the above embodiments, a comprehensive verification system is constructed, encompassing certificate legality, version compatibility, data consistency, and operation point feasibility. This is achieved by verifying the inclusion relationship of versioned constraint certificates, the matching between device status versions and cluster prototype versions, the consistency between the aggregation parameter accumulation result and the full resuming result, and the validity of operation points and the non-empty state of clusters. The four verification mechanisms work together to effectively identify and intercept abnormal updates caused by certificate tampering, version mismatch, parameter accumulation errors, or cluster failures. This ensures that all data is accurate at both the mathematical logic and physical constraint levels before atomic submission, thereby significantly improving the reliability and data integrity of aggregation version updates and reducing the risk of device over-limit operation or scheduling deviations caused by erroneous parameter submissions.

[0097] In one embodiment, the method further includes:

[0098] When creating a new currently committed aggregate version, the operation point of the aggregate version that was committed before the dynamic event will be deleted;

[0099] The remaining operation points are revalidated within the convex feasible region corresponding to the current aggregation parameter and then updated to the current aggregation version.

[0100] Specifically, when the energy storage aggregation control platform generates a new currently submitted aggregation version, it processes the operation points as follows: it compares the aggregation version number saved by the operation point with the aggregation version submitted before the dynamic event. If they match, it determines that the operation point depends on the old version and deletes it. For the remaining operation points, it re-verifies them within the convex feasible region corresponding to the current aggregation parameters. If the verification is successful, it updates them to the current aggregation version. Operation points that fail the verification do not enter the subsequent aggregation optimization.

[0101] In the above embodiments, by deleting operation points that depend on the old version when forming a new aggregate version, and re-verifying the remaining operation points within the convex feasible region corresponding to the current aggregate parameters and updating their version affiliation, the version mismatch or physical limit violation problem between operation points and the current aggregate parameters caused by the aggregate version change is effectively avoided. The timely cleanup of old dependent operation points prevents the expiration state from interfering with subsequent control decisions, while the re-verification and version update of the remaining operation points ensure the smooth migration and continuous availability of valid operation points during the version evolution process. Thus, while ensuring the data consistency and physical feasibility of the entire system after the aggregate version update, the effective information of existing operation points is preserved to the maximum extent, and the repeated calculations and scheduling disturbances caused by version switching are reduced.

[0102] In one exemplary embodiment, such as Figure 3 As shown, steps 302 to 306 are included. Wherein:

[0103] Step 302: Receive the power setting value and its corresponding device status version and certificate identifier;

[0104] For example, the energy storage device controller receives the power setpoint and its corresponding device status version and certificate identifier from the energy storage aggregation control platform through its communication interface, stores the received data in the local cache, and parses out the power setpoint, device status version and certificate identifier.

[0105] Step 304: Compare the received device status version with the local device status version to see if they are consistent, verify whether the power setting value meets the local device constraints, and verify whether the certificate identifier is valid.

[0106] For example, the energy storage device controller compares the received device status version with the local device status version, verifies whether the certificate identifier is valid, and determines whether the power setting value meets the local device constraints; thus obtaining three verification results: whether the versions are consistent, whether the certificate is valid, and whether the power setting value meets the local device constraints.

[0107] Step 306: If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller executes the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to execute the power setting value.

[0108] For example, after the energy storage device controller passes the verification, it sends the power setting value to the power conversion unit of the energy storage device for execution; if the version is inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to send the power setting value, maintains the current operating state, and returns the reason for rejection and the local device status version to the energy storage aggregation control platform.

[0109] In the aforementioned versioned control method for energy storage aggregation status, a triple mechanism of version consistency verification, local device constraint verification, and certificate validity verification is introduced on the device side. This ensures that the issued power settings meet the execution conditions in three dimensions: version matching, physical feasibility, and authorization legality. This effectively prevents control deviations caused by version mismatch, equipment safety risks caused by power exceeding limits, and potential risks of illegal control command execution caused by certificate expiration. The strict control of the triple verification significantly improves the security, reliability, and error prevention capabilities of energy storage devices in executing control commands. At the same time, the device-side autonomous verification and decision-making execution method reduces the real-time dependence on the cloud or scheduling end, enhancing the system's local autonomy and rapid response capabilities.

[0110] In one embodiment, if the version is inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to execute the power setpoint, including:

[0111] Freeze local certificate-based control, disable the corresponding operation point, and switch to a conservative control strategy;

[0112] Conservative control strategies include at least one of maintaining the most recent safety setting, switching to a preset baseline, zero power control, or exiting aggregate control.

[0113] Specifically, if the version is inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller will refuse to execute the power setpoint, freeze local certificate-based control, disable the corresponding operating point, and switch to a conservative control strategy. The conservative control strategy includes at least one of the following: maintaining the most recent safe setpoint, switching to a preset baseline, zero-power control, or exiting aggregation control. Furthermore, the energy storage device controller returns the reason for rejection and the local device status version to the energy storage aggregation control platform. Upon receiving the return information, the energy storage aggregation control platform freezes the certificate-based control of the device, suspends the issuance of new power setpoints to the device, and triggers the invalidation of the relevant operating point. Normal control of the device is restored after the device status is re-registered, the version is consistent, and a new certificate is generated and submitted.

[0114] In the above embodiments, by actively freezing local certificate-based control and invalidating the corresponding operation point when the power setpoint is rejected, and simultaneously switching to a conservative control strategy that includes maintaining the most recent safety setpoint, switching to a preset baseline, zero power control, or exiting aggregation control, a clear and reliable safety fallback mechanism is provided for energy storage devices in abnormal scenarios such as version mismatch, certificate expiration, or constraint overrun. The diverse selection of conservative control strategies allows the device to flexibly choose the most appropriate emergency response method according to the actual operating conditions and risk level, which not only ensures the safety of the device itself, but also avoids unpredictable disturbances to the power grid caused by being in an uncontrolled state after refusing to execute instructions. This significantly improves the fault tolerance and operational safety of the energy storage system under abnormal operating conditions such as communication anomalies, data tampering, or version management failures.

[0115] In one embodiment, a versioning control method for the energy storage aggregation state in a specific embodiment includes:

[0116] S1: Construction of the Convex Feasible Region. The energy storage aggregation control platform receives registration information and status data of energy storage devices. Based on the received device registration information and status data, it establishes a convex feasible region for each energy storage device under the current device status version and obtains the aggregation version submitted before dynamic events. A device, and its power or power-energy variable within a control time domain, are denoted as... The device status version is recorded as Then the convex feasible region of the device is represented as:

[0117] (1)

[0118] Among them, matrix sum vector It is generated by rated charge / discharge power, state of charge, charge / discharge efficiency, ramping capability, duration, and available time period. Measurement error, prediction error, and communication delay are constrained by inward contraction at the right end, with the contraction amount not less than the upper bound of the corresponding error in the normal direction of each half-space.

[0119] Dynamic events refer to the access, disconnection, or capacity degradation of energy storage devices. Capacity degradation includes a reduction in power or energy output capacity due to factors such as exceeding SOC limits, abnormal temperatures, and equipment aging. The aggregated version submitted before the dynamic event refers to the aggregated version number that has been submitted and is effective and visible to the control side, used to identify the current aggregation status of the energy storage aggregation control platform before the dynamic event occurs.

[0120] S2: Versioned constraint certificate generation. The support function of the convex feasible region of each device is calculated in a preset direction, using the geometric center. and scale The geometric features that are independent of absolute capacity are formed, as shown in the following formula:

[0121] (2)

[0122] in, For the first The device in the Normalized geometric eigenvalues ​​in a preset direction, For the convex feasible domain of the device In direction Support function on, For the first A preset direction vector.

[0123] Perform on geometric features Mean, hierarchical clustering, or online nearest prototype assignment are used. Each cluster selects a representative polygon of its member-normalized feasible region as the prototype. Save cluster identifiers and prototype version Geometric clustering is used to reduce the internal approximation loss under the same prototype; version consistency does not depend on a specific clustering algorithm. The clustering results of the supporting function geometric features are as follows: Figure 4 As shown.

[0124] Energy storage aggregation control platform for the first Clustering devices Calculate the scaling amount Horizontal displacement This makes the clustering prototype Scaling Double and translate The convex feasible region subsequently included in the device Specifically, regarding the equipment... One and a half space constraints, making As prototype The support value in the normal direction of this half-space, with a robust threshold. Tighten the constraints and solve the following equation:

[0125] (3)

[0126] in, For the convex feasible domain of the device Normal vectors of half-space constraints For the convex feasible domain of the device Boundary values ​​of a half-space constraint.

[0127] In equation (3), the certificate generation stage retains... The safety margin is determined by a scaling factor that avoids the contradiction of scaling to the equipment boundary with a near-zero safety margin, while simultaneously requiring a safety margin greater than a positive threshold. After solving, the minimum remaining amount is calculated based on the original equipment constraints and used as the safety margin. As shown in equation (4):

[0128] (4)

[0129] The solution results are encapsulated into a versioned constraint certificate. The valid start and end versions in the certificate are used to revoke old certificates, and the inverse decomposition index is used to locate the clustering instructions to the device control interface. Its logical structure is shown in equation (5):

[0130] (5)

[0131] in, For equipment identification, For a valid range of integers, This is the inverse decomposition index.

[0132] S3: Aggregation Parameter Calculation. The energy storage aggregation control platform calculates the current aggregation parameters of the energy storage devices based on the generated versioned constraint certificates. For the first... The sum of the current valid certificates for each cluster is calculated separately to obtain the sum of the scaling factors. The sum of translations and authentication aggregation internal domain :

[0133] (6)

[0134] in, For the first The set of devices corresponding to all currently valid certificates in each cluster.

[0135] Because each certificate meets It is contained within the corresponding device's convex feasible region. The Minkowski sums contained within the real feasible domains of each device in this cluster are such that... Internal aggregate instructions can be broken down into individual feasible instructions for each device.

[0136] S4: Dynamic Event Response and Data Calculation. When a dynamic event occurs in the energy storage device, the energy storage aggregation control platform responds to the dynamic event by calculating the aggregation parameter difference based on the versioned constraint certificate corresponding to the dynamic event, and determining the operation point that depends on the aggregation version submitted before the dynamic event.

[0137] The calculation of the aggregation parameter difference varies depending on the type of dynamic event, as shown in equation (7):

[0138] (7)

[0139] When connecting energy storage devices, scale the newly added versioned constraint certificate of the device. Horizontal displacement As a positive difference, it is added to the aggregation parameter of the corresponding cluster; when the energy storage device exits, the scaling factor of the versioned constraint certificate that was valid before the event of the device is applied. Horizontal displacement As a negative difference, it is subtracted from the aggregation parameters of the corresponding cluster; when the capacity of the energy storage device decreases, the scaling difference between the replacement certificate and the original certificate is used. Translational difference The aggregation parameters of the corresponding cluster are updated as replacement differentials.

[0140] The energy storage aggregation control platform stores the aggregation version number, cluster prototype version, and member certificate set digest that each feasible domain vertex, optimized hot start point, and control point to be issued depends on. When a dynamic event occurs, the energy storage aggregation control platform obtains the aggregation version number stored by each operation point, compares it with the aggregation version submitted before the dynamic event, and determines the operation point whose aggregation version number matches the aggregation version submitted before the dynamic event as the operation point that depends on the old aggregation version.

[0141] Before submitting transaction data, the energy storage aggregation control platform performs a joint verification of the versioning constraint certificate, aggregation parameter differences, and operation points. The joint verification includes the following four checks, all of which must pass before submission: inclusion relationship verification, and verification of the scaling amount in the versioning constraint certificate. Horizontal displacement Does it meet the requirements? Contained within the convex feasible region of the device That is, the constraint condition of equation (3) still holds after the certificate is generated. Version matching verification verifies the device status version bound in the certificate. Compared with the clustering prototype version Matching, i.e., whether the current state of the device is consistent with the prototype version of the cluster to which the device belongs. Differential summation consistency check, verifying the current aggregation parameters. Difference from aggregation parameters The sum is checked against the result of a full recalculation of all versioned constraint certificates. This check ensures the correctness of the differential update method—if the differential calculation is correct, the results obtained by the two calculation methods (differential update and full recalculation) should be the same. Operation point and cluster status checks verify the validity of operation points—that is, whether operation points dependent on aggregate versions submitted before dynamic events have been correctly identified and processed; and whether the cluster to which the energy storage device belongs is non-empty, i.e., whether there are still member devices in the cluster.

[0142] When all joint verifications pass, the energy storage aggregation control platform will commit the versioned constraint certificates involved in the dynamic event, the sum of the current aggregation parameters and the difference between the aggregation parameters (i.e., the updated aggregation parameters), and the operation point as the same transaction atomically. When the verification result J is 1, the temporary state is committed; when it is 0 or the transaction is interrupted, the state before the event is maintained, as shown in equation (8):

[0143] (8)

[0144] The energy storage aggregation control platform updates the certificate record, clustering aggregation parameters, and operation point status all at once at the transaction commit point. After the commit is completed, the new aggregation version is visible to the control side, and all subsequent aggregation optimization and decomposition operations on the control side are performed based on this new version. When any joint verification fails or the transaction is interrupted, as shown in the case of J=0 in equation (8), the energy storage aggregation control platform rolls back the transaction data as a whole, that is, discards all uncommitted data, keeps the aggregation version committed before the dynamic event unchanged, and the old version continues to be visible to the control side. Atomic commit ensures that the certificate, aggregation parameters, and operation point status are switched in the same transaction, avoiding the occurrence of half-update states such as "the certificate has been changed but the aggregation parameters have not been updated" or "the aggregation parameters have been updated but the operation point is still in the old state".

[0145] The energy storage aggregation control platform generates aggregated power commands based solely on the currently submitted aggregation version and decomposes these commands into power setpoints for each energy storage device. The platform reads the certified aggregation domain corresponding to the currently submitted aggregation version and generates aggregated power commands for each cluster within that domain. For the first A non-empty cluster, when At that time, based on the current translation amount of the cluster. Sum of scaling Calculate the common prototype coordinates according to formula (9) :

[0146] (9)

[0147] Then, the scaling is determined according to the scaling amount in the currently valid version constraint certificate for each device. Horizontal displacement The clustering instruction is decomposed into the power setting value of each energy storage device according to formula (10). :

[0148] (10)

[0149] Depend on Based on the cluster prototype and certificate inclusion relationship, the power setting value for each device can be obtained. All belong to the convex feasible region of the devices. The sum of the settings of each device equals the clustering instruction:

[0150] (11)

[0151] Finally, the energy storage aggregation control platform sends each power setting value and its corresponding aggregation version, device status version, and certificate identifier to the energy storage device controller.

[0152] After receiving the power setpoint and its corresponding device status version and certificate identifier, the energy storage device controller performs a triple verification before execution, as shown in equation (12):

[0153] (12)

[0154] The system compares the received device status version with the local device status version, verifies the validity of the certificate identifier, and checks whether the power setting value meets the local device constraints. The power setting value is executed only if all three verifications pass; if any one fails, execution is rejected, and the rejection reason and the local device status version are returned to the energy storage aggregation control platform.

[0155] After receiving the feedback from the device controller, the energy storage aggregation control platform continuously compares the issued version, the device feedback version, the actual power, and the state of charge. When the versions are inconsistent, the actual power deviation exceeds the limit, or the device constraint exceeds the limit, the certificate-based control of the affected device is frozen, the relevant operation points are disabled, and a conservative control strategy is switched to—including maintaining the most recent safety setpoint, switching to a preset baseline, zero power control, or exiting aggregation control at least one of the following: closed-loop control is restored after the device status is re-registered and the version is consistent.

[0156] S5: Abnormal Branch Handling. There are defined processing paths for various abnormal branches: When certificate resolution fails, the energy storage aggregation control platform discards temporary data and retains the old aggregation version; when a transaction is interrupted or times out, it recovers based on the aggregation version and transaction log committed before the dynamic event, with only versions marked with commits available for aggregation optimization; when the last member exits, the corresponding cluster, its certified aggregation domain, and dependent operation points are deleted, and inverse decomposition by division by zero is not performed; when a device cannot obtain a certificate that meets the robustness threshold under the existing prototype, prototype reconstruction is triggered, a new prototype version is generated, and certificates are regenerated for all members of the cluster before a complete switch, with the old certificates uniformly expiring; after the device controller rejects the old version instruction, the platform freezes the relevant certificate-based control accordingly; after feedback of mismatch, the freeze is lifted and closed-loop control is restored only after the device status is re-registered, a new certificate is generated, and an atomic commit is completed.

[0157] Reproducible comparative simulation experiments: A two-dimensional synthetic convex feasible region was generated using a fixed random seed 20260726. The runtime environment was Python 3.13.9, NumPy 2.3.5, SciPy 1.16.3, scikit-learn 1.7.2, pandas 2.3.3, and Matplotlib 3.10.6. Supporting function features were obtained through actual... Mean clustering is used, and the cluster prototype is generated by normalizing the feasible region of the representative members. The certificate is solved by the linear programming corresponding to equation (3). All scripts, cell-by-cell execution notebooks, CSV, JSON and figures are saved with this implementation.

[0158] The comparison includes three types of methods: the first type is an independent static full reconstruction implementation based on the publicly available geometric clustering and prototype maximum inner approximation ideas, where each checkpoint re-clusters the current device and recalculates all certificates; the second type is an ablation method that only maintains access, does not revoke exits or capability degradation, and is not version-bound; the third type is the proposed technical solution. The synthetic simulation experiment settings are shown in Table 1.

[0159] Table 1 Synthetic Simulation Experiment Setup

[0160]

[0161] Static tests compared the certified aggregated inner domain with the two-dimensional exact Minkowski sum of the convex feasible domains of all devices. In six repetitions, the average proportion of the certified inner domain area to the exact aggregated domain was 92.83%, ranging from 92.45% to 93.24%; the number of failures was 0, and the minimum certificate margin was 0.010000, consistent with the preset ρ=0.010 within the numerical tolerance.

[0162] In the dynamic test, all 60 normal events were successfully submitted. The error between the aggregation parameters of this invention and the maximum support value resuming the current valid certificates is 5.684e-14; the ablation without deletion and without version binding was overestimated by 28.05% after the last event. This invention touches an average of 1.00 certificate records per event, and the static full reconstruction checkpoint recalculates an average of 99.83 records, with a median reconstruction time of 0.0936 seconds. Comparison of the complete method and the ablation without version binding under dynamic events: Figure 5 As shown.

[0163] The old operation point experiment sampled 3000 points in the pre-event authentication domain, followed by the exit of 4 devices and capacity reduction of 4 devices. After re-verification in the current version, 531 points became invalid and were deleted, while 2469 points passed re-verification, resulting in a failure rate of 17.70%. This experiment verifies the handling of version-dependent points and does not use the statistical distribution of old points as the actual operational distribution of devices. The re-verification results of old operation points after capacity reduction are as follows: Figure 6 As shown.

[0164] The reverse decomposition experiment generated 4,000 aggregation instructions and examined 96,000 device settings. The maximum absolute error between the sum of device settings and the clustering instructions was 2.842e-14, exceeding... The tolerance limit for individual out-of-bounds errors is 0; the acceptance limit for 100 attempts at older command versions is 0.

[0165] There are 7 types of exception branches: certificate resolution failure rollback, transaction interruption rollback, empty cluster deletion, old point revalidation, old version command rejection, feedback mismatch rollback, and state consistency recovery. 7 types passed and 0 types failed. The hashes of committed states remained consistent before and after certificate failure and transaction interruption. The exception branch coverage results are as follows: Figure 7 As shown.

[0166] The runtime test only compared aggregated certificate ledger maintenance, excluding communication, clustering, certificate linear programming, and device execution. With 20,000 certificate records, the median time per event for differential maintenance was 1.66 microseconds, while the median time for full ledger recalculation was 104.68 microseconds, a measured ratio of 63.22. Ledger maintenance times for different certificate record sizes are shown below. Figure 8 As shown.

[0167] The main results of the synthetic simulation experiment are shown in Table 2.

[0168] Table 2. Main Results of Synthetic Simulation Experiment

[0169]

[0170] The experimental results above support the following limited conclusions: given a two-dimensional synthetic convex feasible region, robustness threshold, and numerical tolerance, the versioned certificate difference is consistent with the sum of all currently valid certificates; instructions in the authentication aggregate inner domain can be decomposed into individual feasible instructions; abnormal transactions do not change the committed state; and old version instructions are rejected. Communication latency, converter dynamics, SOC estimation error, distribution network power flow, actual frequency regulation benefits, and hardware-in-the-loop performance are not verified.

[0171] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0172] Based on the same inventive concept, embodiments of this application also provide a versioned control system for implementing the above-mentioned energy storage aggregation state, comprising:

[0173] The energy storage aggregation control platform obtains the device convex feasible region and the aggregated version submitted before dynamic events of the energy storage device; the device convex feasible region is formed by the power boundary and the energy state or state of charge boundary;

[0174] The energy storage aggregation control platform generates versioned constraint certificates based on the convex feasible domain of the device. The versioned constraint certificate includes at least the device identifier, device status version, cluster identifier, cluster prototype version, and the scaling and translation amount used to make the cluster prototype included in the convex feasible domain of the device after scaling and translation.

[0175] The energy storage aggregation control platform calculates the current aggregation parameters of energy storage devices based on versioned constraint certificates;

[0176] The energy storage aggregation control platform responds to dynamic events of energy storage devices and calculates aggregation parameter differences based on the versioned constraint certificates corresponding to the dynamic events. Based on the comparison results between the dependency version number saved at the operation point and the aggregation version submitted before the dynamic event, it determines the operation point that depends on the aggregation version submitted before the dynamic event.

[0177] The energy storage aggregation control platform performs joint verification of versioned constraint certificates, aggregation parameter differences, and operation points;

[0178] If the joint verification passes, the energy storage aggregation control platform will atomically commit the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process will be rolled back while maintaining the aggregation version committed before the dynamic event.

[0179] The energy storage aggregation control platform generates power setpoints and their corresponding device status versions and certificate identifiers based on the currently submitted aggregation versions, and then distributes them to the energy storage device controllers.

[0180] The energy storage device controller receives the power setpoint and its corresponding device status version and certificate identifier;

[0181] The energy storage device controller compares the received device status version with the local device status version to check whether the power setting value meets the local device constraints and whether the certificate identifier is valid.

[0182] If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller will execute the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller will refuse to execute the power setting value.

[0183] Based on the same inventive concept, this application also provides a versioned control device for energy storage aggregation states to implement the versioned control method for energy storage aggregation states described above. The solution provided by this device is similar to the implementation scheme described in the above method. Therefore, the specific limitations in one or more embodiments of the versioned control device for energy storage aggregation states provided below can be found in the limitations of the versioned control method for energy storage aggregation states described above, and will not be repeated here.

[0184] In one exemplary embodiment, such as Figure 9 As shown, a versioned control device for energy storage aggregation status is provided, comprising: an acquisition module 902, a generation module 904, a calculation module 906, a verification module 908, and a distribution module 910, wherein:

[0185] The acquisition module 902 is used to acquire the device convex feasible region and the aggregated version submitted before dynamic events of the energy storage device; the device convex feasible region is formed by the power boundary and the energy state or charge state boundary;

[0186] The generation module 904 is used to generate a versioned constraint certificate based on the convex feasible region of the device. The versioned constraint certificate includes at least the device identifier, the device status version, the cluster identifier, the cluster prototype version, and the scaling and translation amount used to make the cluster prototype included in the convex feasible region of the device after scaling and translation.

[0187] Calculation module 906 is used to calculate the current aggregate parameters of the energy storage device based on the versioned constraint certificate;

[0188] The calculation module 906 is also used to respond to dynamic events of the energy storage device, calculate the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event, and determine the operation point that depends on the aggregate version submitted before the dynamic event based on the comparison result between the aggregate version number saved at the operation point and the aggregate version submitted before the dynamic event.

[0189] Verification module 908 is used to perform joint verification of versioned constraint certificates, aggregate parameter differences, and operation points;

[0190] The verification module 908 is also used to, if the joint verification passes, atomically commit the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process is rolled back and the aggregation version committed before the dynamic event is maintained.

[0191] The distribution module 910 is used to generate power setting values ​​and their corresponding aggregation versions, device status versions and certificate identifiers based on the currently submitted aggregation versions, and distribute them to the energy storage device controller.

[0192] In one embodiment, the calculation module 906 is further configured to calculate the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event, including:

[0193] When energy storage devices are connected, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are added as positive difference to the current aggregation parameters.

[0194] When an energy storage device exits, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are deducted from the current aggregation parameters as a negative difference.

[0195] When the capacity of energy storage devices decreases, the scaling difference and translation difference of the versioned constraint certificate corresponding to the dynamic event are used as replacement differences to update the current aggregation parameters.

[0196] In one embodiment, the verification module 908 is used to perform joint verification of the versioned constraint certificate, aggregate parameter difference, and operation point, including:

[0197] Verify whether the scaling and translation of the versioned constraint certificate satisfy the inclusion relationship;

[0198] Verify that the device status version matches the clustering prototype version;

[0199] Verify whether the sum of the current aggregation parameter and the difference between the aggregation parameters is consistent with the result of summing all versioned constraint certificates again;

[0200] Verify the validity of the operation point or whether the cluster corresponding to the cluster identifier is in a non-empty state.

[0201] In one embodiment, the method further includes:

[0202] When creating a new currently committed aggregate version, the operation point of the aggregate version that was committed before the dynamic event will be deleted;

[0203] The remaining operation points are revalidated within the convex feasible region corresponding to the current aggregation parameter and then updated to the current aggregation version.

[0204] In one exemplary embodiment, such as Figure 10 As shown, a versioned control device for energy storage aggregation status is provided, comprising: a receiving module 1002, a comparison module 1004, and an execution module 1006, wherein:

[0205] The receiving module 1002 is used to receive the power setting value and its corresponding device status version and certificate identifier;

[0206] The comparison module 1004 is used to compare whether the received device status version is consistent with the local device status version, verify whether the power setting value meets the local device constraints, and verify whether the certificate identifier is valid.

[0207] The execution module 1006 is used to execute the power setting value if the version is consistent, the certificate is valid and the local device constraints are met; if the version is inconsistent, the certificate is invalid or the local device constraints are not met, the energy storage device controller refuses to execute the power setting value.

[0208] In one embodiment, the execution module 1006 is configured to refuse to execute the power setpoint if the version is inconsistent, the certificate is invalid, or the local device constraints are not met, including:

[0209] Freeze local certificate-based control, disable the corresponding operation point, and switch to a conservative control strategy;

[0210] Conservative control strategies include at least one of maintaining the most recent safety setting, switching to a preset baseline, zero power control, or exiting aggregate control.

[0211] Each module in the aforementioned versioned control device for energy storage aggregation can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0212] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a versioned control method for energy storage aggregation states. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0213] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0214] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0215] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0216] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0217] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0218] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0219] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0220] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A versioned control method for energy storage aggregation state, characterized in that, The method is applied to an energy storage aggregation control platform, and the method includes: Obtain the aggregated version of the device's convex feasible region and dynamic events that have been submitted before; the device's convex feasible region is formed by power boundaries and energy state or state of charge boundaries. A versioned constraint certificate is generated based on the device's convex feasible region. The versioned constraint certificate includes at least a device identifier, a device status version, a cluster identifier, a cluster prototype version, and a scaling and translation amount used to make the cluster prototype, after scaling and translation, contain the device's convex feasible region. Calculate the current aggregation parameters of the energy storage device based on the versioned constraint certificate; In response to a dynamic event of the energy storage device, the aggregation parameter difference is calculated based on the versioned constraint certificate corresponding to the dynamic event; based on the comparison between the aggregation version number saved at the operation point and the aggregation version submitted before the dynamic event, the operation point that depends on the aggregation version submitted before the dynamic event is determined. The versioned constraint certificate, the aggregation parameter difference, and the operation point are jointly verified. If the joint verification passes, the versioned constraint certificate, the sum of the current aggregation parameter and the difference between the aggregation parameters, and the operation point are committed atomically as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process is rolled back while maintaining the aggregation version committed before the dynamic event. Based on the currently submitted aggregated version, a power setting value is generated, along with its corresponding aggregated version, device status version, and certificate identifier, and then sent to the energy storage device controller.

2. The method according to claim 1, characterized in that, The calculation of the aggregate parameter difference based on the versioned constraint certificate corresponding to the dynamic event includes: When the energy storage device is connected, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are added as positive difference to the current aggregation parameter. When the energy storage device exits, the scaling and translation of the versioned constraint certificate corresponding to the dynamic event are deducted from the current aggregation parameters as a negative difference. When the energy storage device's capacity decreases, the scaling difference and translation difference of the versioned constraint certificate corresponding to the dynamic event are used as replacement differences to update the current aggregation parameters.

3. The method according to claim 1, characterized in that, The joint verification of the versioned constraint certificate, the aggregate parameter difference, and the operation point includes: Verify whether the scaling and translation of the versioned constraint certificate satisfy the inclusion relationship; Verify whether the device status version matches the clustering prototype version; Verify whether the sum of the difference between the current aggregation parameter and the aggregation parameter is consistent with the result of summing all versioned constraint certificates again; Verify the validity of the operation point or whether the cluster corresponding to the cluster identifier is in a non-empty state.

4. The method according to claim 1, characterized in that, The method further includes: When a new currently committed aggregate version is formed, the operation point of the aggregate version that was committed before the dynamic event will be deleted; The remaining operation points are revalidated within the convex feasible region corresponding to the current aggregation parameter and then updated to the current aggregation version.

5. A versioned control method for energy storage aggregation state, characterized in that, The method is applied to an energy storage device controller, and the method includes: Receive power settings and their corresponding device status version and certificate identifier; Compare the received device status version with the local device status version to see if they are consistent, verify whether the power setting value meets the local device constraints, and verify whether the certificate identifier is valid. If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller executes the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to execute the power setting value.

6. The method according to claim 5, characterized in that, If the version is inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller will refuse to execute the power setting value, including: Freeze local certificate-based control, disable the corresponding operation point, and switch to a conservative control strategy; The conservative control strategy includes at least one of maintaining the most recent safety setting, switching to a preset baseline, zero power control, or exiting aggregate control.

7. A versioned control system for energy storage aggregation state, characterized in that, The system includes: The energy storage aggregation control platform acquires the device convex feasible region and the aggregated version submitted before dynamic events of the energy storage device; the device convex feasible region is formed by power boundaries and energy state or state of charge boundaries; The energy storage aggregation control platform generates a versioned constraint certificate based on the convex feasible region of the device; the versioned constraint certificate includes at least the device identifier, the device status version, the cluster identifier, the cluster prototype version, and the scaling and translation amount used to make the cluster prototype included in the convex feasible region of the device after scaling and translation. The energy storage aggregation control platform calculates the current aggregation parameters of the energy storage device based on the versioned constraint certificate; The energy storage aggregation control platform responds to dynamic events of the energy storage device, calculates aggregation parameter differences based on the versioned constraint certificate corresponding to the dynamic event, and determines the operation point that depends on the aggregation version submitted before the dynamic event based on the comparison result between the dependency version number saved at the operation point and the aggregation version submitted before the dynamic event. The energy storage aggregation control platform performs joint verification on the versioned constraint certificate, the aggregation parameter difference, and the operation point; If the joint verification passes, the energy storage aggregation control platform will atomically commit the versioned constraint certificate, the sum of the current aggregation parameters and the difference between the aggregation parameters, and the operation point as the same transaction to form a new currently committed aggregation version; if the joint verification fails or the transaction is interrupted, the entire process will be rolled back while maintaining the aggregation version committed before the dynamic event. The energy storage aggregation control platform generates power setting values ​​and their corresponding device status versions and certificate identifiers based on the currently submitted aggregation version, and sends them to the energy storage device controller. The energy storage device controller receives the power setting value and its corresponding device status version and certificate identifier; The energy storage device controller compares the received device status version with the local device status version to check whether the power setting value meets the local device constraints and whether the certificate identifier is valid. If the versions are consistent, the certificate is valid, and the local device constraints are met, the energy storage device controller executes the power setting value; if the versions are inconsistent, the certificate is invalid, or the local device constraints are not met, the energy storage device controller refuses to execute the power setting value.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images