Optimizing Controller for Distributed Energy Resources

A decentralized control system for DERs using nested MPC optimization loops addresses scalability and complexity issues in centralized systems, enhancing resilience and efficiency by enabling local decision-making and reduced computational load.

JP7620712B2Active Publication Date: 2025-01-23HEILA TECHNOLOGIES INC
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2023538990
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-12-30
Filing Date
2021-12-30
Publication Date
2025-01-23
Estimated Expiration
2041-12-30

AI Technical Summary

Technical Problem

Centralized control systems for distributed energy resources (DERs) face scalability issues, complexity, and vulnerability due to increased variables and nodes, leading to inefficiencies and potential system-wide disruptions.

Method used

A decentralized control approach using model predictive control (MPC) with nested optimization loops, allowing each DER to make local decisions based on shared information, optimizing both short-term and long-term system dynamics while reducing computational load.

Benefits of technology

The decentralized system enhances scalability, resilience, and efficiency by enabling quick responses to local conditions, maintaining optimal system balance, and reducing computational complexity, thus improving overall grid performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007620712000005
    Figure 0007620712000005
  • Figure 0007620712000006
    Figure 0007620712000006
  • Figure 0007620712000007
    Figure 0007620712000007
Patent Text Reader

Abstract

An asset manager controls the distribution of power in an aggregated distributed energy resource system. The asset manager solves a given asset model that models real assets. The asset controller optimizes set points of the assets by determining a first trajectory over the course of a first prediction horizon and a second trajectory over the course of a second prediction horizon that is shorter in time than the first prediction horizon. The trajectories are determined by minimizing a cost function associated with a DER model or a DER system model. The first prediction horizon has a first time length and a number of first set points. The second prediction horizon has a second time length and a number of second set points. The asset controller constrains the second trajectory based on the number of first set points.
Need to check novelty before this filing date? Find Prior Art

Description

Detailed Description of the Invention

[0001] [Priority] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 131,968, filed December 30, 2020, entitled "DECENTRALIZED ALGORITHMS FOR DER COORDINATION," and naming Jorge Elizondo Martinez, Seth Calbert, Trudie Wang, and Shuyang Li as inventors, the disclosure of which is incorporated herein by reference in its entirety.

[0002] [Field of the Invention] FIELD OF THE DISCLOSURE Exemplary embodiments of the present invention relate generally to controlling distributed energy resources in an electrical power distribution network. More particularly, various embodiments of the present invention relate to a method for optimizing power exchanges within a distributed energy resource system.

[0003] [Background of the invention] The electric grid connects homes, businesses, and other buildings to a central power source. This interconnectivity requires centralized control and planning. As a result, grid vulnerabilities can quickly propagate throughout the network. To mitigate these risks, aggregated distributed energy resource (DER) systems (DER systems), such as microgrids, are becoming a popular solution. Microgrids include controlled clusters of generating and storage devices. They also provide coordinated response to utility needs and include loads that can operate disconnected from the main grid. This improves the efficiency and reliability of the power system.

[0004] The U.S. Department of Energy provides a formal definition of a microgrid as "a group of interconnected assets, including loads and distributed energy resources, with clearly defined electrical boundaries that function as a single controllable entity to the grid." Often, microgrids have renewable resources, such as solar panels or wind turbines, along with distributed generators (e.g., diesel generators, gas turbines, etc.) and batteries.

[0005] [Overview of Various Embodiments] According to one embodiment of the invention, a method controls a distributed energy resource. The method obtains a model of the distributed energy resource or a system of distributed energy resources. The method determines a first trajectory of a desired power output or state of the distributed energy resource in a first prediction horizon by minimizing a cost function associated with the DER model. The first horizon has a first time length and a first number of set points. The method determines a second trajectory of a desired power output or state of the distributed energy resource in a second prediction horizon by minimizing a cost function associated with the DER model. The second prediction horizon has a second time length and a second number of set points. The method constrains the second trajectory as a function of the first number of set points or states. The first time length is greater than the second time length. A time interval between sampling times in the first trajectory is greater than a time interval between sampling times in the second trajectory.

[0006] Also, in some embodiments, the method determines a third trajectory of a desired power output of a distributed energy resource over a third prediction horizon by minimizing a cost function associated with the DER model. The third prediction horizon has a third time length and a third number of set points. The method may constrain the third trajectory based on the first number of set points and the second number of set points. The second time length may be greater than the third time length. A time interval between sampling time points in the second trajectory may be greater than a time interval between sampling time points in the third trajectory.

[0007] In various embodiments, multiple asset managers can independently solve their own optimization trajectories in a distributed and decentralized manner. Model predictive control routines can be used to recalculate the first trajectory, the second trajectory, and / or the third trajectory.

[0008] For example, the distributed energy resource may be part of an HVAC system. In some embodiments, the distributed energy resource may be a battery.

[0009] According to another embodiment, a method controls distributed energy resources. The method receives a request for power from a distributed energy resource system. The method uses a model predictive control routine and a resource model to calculate a first predicted operating trajectory as a function of current operating conditions of the distributed energy resources. At least one predicted operating trajectory has a first prediction horizon and a number of time slots along the prediction horizon. At the prediction horizon, the model is solved and optimized. The method also uses an MPC routine asset model to calculate a second predicted operating trajectory as a function of current operating conditions of the distributed energy resources. The second predicted operating trajectory has a second prediction horizon that is shorter in time than the first prediction horizon. The second predicted operating trajectory has a second number of second time slots along the second prediction horizon. At the second prediction horizon, the model is solved and optimized. A time interval between the time slots in the second predicted operating trajectory is shorter in time than a time interval between the time slots in the first predicted operating trajectory.

[0010] According to yet another embodiment, an asset manager is configured to control the distribution of power in an aggregated distributed energy resource system (DER system) having a plurality of assets. The asset manager is configured to solve a given asset model. The asset manager includes an asset model configured to model real assets and an interface configured to communicate with at least one other asset manager and / or a central controller in the DER system. The interface is configured to receive asset information regarding the real assets. The asset controller is configured to optimize a set point of the asset by determining a first trajectory in a first prediction horizon and a second trajectory in a second prediction horizon. The trajectory is determined by minimizing a cost function associated with the DER model or the DER system model. The first prediction horizon has a first time length and a plurality of first set points. Similarly, the second prediction horizon has a second time length and a plurality of second set points. The asset controller is configured to constrain the second trajectory based on the plurality of first set points. The first time length is greater than the second time length. A time interval between the sampling times in the first trajectory is greater than a time interval between the sampling times in the second trajectory. The asset manager is further configured to control the real assets according to the set points determined by the optimization.

[0011] Exemplary embodiments of the present invention are implemented as a computer program product having a computer usable medium containing computer readable program code which can be read and utilized by a computer system in accordance with conventional processes.

[0012] [Brief description of the drawings] Those skilled in the art will be able to more fully appreciate the advantages of various embodiments of the present invention from the following "Description of Exemplary Embodiments," which is described with reference to the drawings, summarized below.

[0013] FIG. 1A illustrates a schematic of a DER system including an asset manager used to optimize the operation of multiple distributed energy resources and loads to meet system-wide objectives (goals) in accordance with an exemplary embodiment of the present invention.

[0014] FIG. 1B illustrates a schematic diagram of two DER networks according to an exemplary embodiment of the present invention.

[0015] FIG. 1C illustrates a schematic process for performing a decentralization algorithm according to an exemplary embodiment of the present invention.

[0016] FIG. 2 illustrates a schematic of the asset manager of FIG. 1 configured in accordance with an exemplary embodiment of the present invention.

[0017] 3A-3C show schematic diagrams of three different schemes for optimization of a DER system.

[0018] FIG. 4 illustrates a schematic representation of a prediction horizon according to an exemplary embodiment of the present invention.

[0019] FIG. 5 illustrates a schematic representation of a control trajectory at a given prediction horizon according to an exemplary embodiment of the present invention.

[0020] FIG. 6 illustrates a schematic diagram of an alternative control trajectory in the same prediction horizon as FIG. 5, according to an exemplary embodiment.

[0021] FIG. 7 illustrates, in accordance with an exemplary embodiment, a schematic diagram of an alternative control trajectory in the same prediction horizon as FIGS.

[0022] FIG. 8A illustrates a schematic diagram of nested control trajectories in the same prediction horizon as FIGS. 5-7, according to an exemplary embodiment.

[0023] FIG. 8B illustrates a schematic diagram of a second trajectory after executing a second MPC optimization loop according to an exemplary embodiment of the present invention.

[0024] Figure 9 shows a schematic of the trajectory of the optimization function observing the system dynamics on an hourly basis.

[0025] FIG. 10 illustrates diagrammatically the next steps in the optimization function according to an exemplary embodiment of the present invention.

[0026] FIG. 11 illustrates a schematic diagram of MPC optimization at different times according to an exemplary embodiment of the present invention.

[0027] FIG. 12 illustrates a generalization of nesting of MPC routines according to an exemplary embodiment.

[0028] FIG. 13 illustrates a schematic diagram of a nested MPC routine according to an exemplary embodiment.

[0029] FIG. 14 illustrates generally a process for optimizing a DER system using a distributed asset manager according to an exemplary embodiment of the present invention.

[0030] 15A-15C illustrate generally another example of a nested optimization routine according to an exemplary embodiment of the present invention.

[0031] It should be noted that the figures described above and the elements shown therein are not necessarily drawn to consistent scale or to any scale. Like elements are designated by like numerals unless the context suggests otherwise. The figures are primarily for illustrative purposes and are not intended to limit the scope of the inventive subject matter described herein.

[0032] Description of Exemplary Embodiments In an exemplary embodiment, a distributed energy resource system has one or more controllers that cooperate to control the input and output of power to one or more assets. The control of various assets is based on an optimization algorithm that addresses both fast and slow system dynamics. There, the controller receives a mathematical model that provides realistic and real-time results for one or more simulated asset models in an aggregated distributed energy resource system (DER system). Each asset model has an underlying mathematical representation for the behavior of a given real asset and / or DER system. The controller executes a model predictive control (MPC) routine to execute an optimization algorithm according to the slow system dynamics. The points (e.g., end points) determined by the MPC according to the slow system dynamics are nested as constraints in an optimization algorithm (which may be an MPC routine) according to the faster system dynamics. In various embodiments, each of the one or more asset managers solves its own asset model and controls the corresponding asset according to the optimization. The assets are then driven according to the set points determined by the optimization. The following describes the details of the exemplary embodiment.

[0033] 1A illustrates a schematic diagram of a distributed energy resource (DER) system 100 including an asset manager 16 used to optimize the operation of multiple DERs 14 and loads 15 to meet overall system objectives according to an exemplary embodiment of the present invention. As known to those skilled in the art, the DERs 14 exchange real and reactive power with the power network. In contrast, the loads 15 typically consume or use real and reactive power. The DERs 14 may be solar, microturbines, cells, fuel cells, electrolysers, etc., among others. Although a distinction is made between the loads 15 and the DERs 14, both the loads and the DERs may be referred to as assets 14.

[0034] In some embodiments, each of the assets 14 may be controlled by a given asset manager 16 (asset manager 16 described in more detail in FIG. 2). Additionally or alternatively, multiple DERs 14 may be controlled by a single asset manager 16. However, in some embodiments, one or more of the DERs 14 and / or loads 15 may not be connected to the asset manager 16. In an exemplary embodiment, each asset manager 16 also includes an asset model 18 configured to simulate a real asset. The asset model 18 may be referred to as a virtual asset 18. However, it should be understood that an exemplary embodiment may have one or more asset managers 16 connected to the network 100, and each manager 18 may have one or more asset models 18. Furthermore, each asset model 18 may model a different type of asset (e.g., a battery, a solar panel, a wind turbine, etc.). Although not shown, an exemplary embodiment may include one or more real assets connected to the network 12 in addition to the models 18.

[0035] FIG. 1B illustrates two DER networks 100A and 100B. Each of the networks 100A and 100B has a common connection branch 12A and 12B. A common connection virtual branch may be calculated for the two independent DER systems 100A and 100B according to an exemplary embodiment of the present invention. The common connection virtual branch is formed by combining meter information from the common connection branches 12 (e.g., 12A and 12B) of the two or more independent aggregated DER systems 100A and 100B. For example, the active power at the common connection virtual branch is the active power measured by meter 1 at the common connection branch 12A and the active power measured by meter 2 at the common connection branch 12B. Therefore, unless the context requires otherwise, any description related to the common connection branch 12 applies to the common connection virtual branch.

[0036] As described below, in various embodiments, one or more of DER systems 100A and 100B may be controlled using a distributed approach. In other embodiments, the DER systems may be controlled using a centralized approach.

[0037] DER systems 100 (e.g., microgrids) are being deployed around the world to modernize, sustain, resilient, and efficient power systems. Various embodiments provide a distributed architecture where all consumers can become producers and actively participate in the procurement, utilization, and dispatch of electricity. With the increasing number of stakeholders in the energy infrastructure, problems arise in determining how to handle (i) the role of utilities and (ii) the tradeoffs between individual and collective objectives of the grid.

[0038] The illustrative embodiments provide an end-to-end solution that transforms DERs into multiple intelligent agents that interact to produce a system with emergent behavioral characteristics that meet the collective needs of the system 100. The illustrative embodiments achieve this by using local control and decentralized optimization techniques that leverage concepts from game theory, distributed optimization techniques, and machine learning.

[0039] The illustrative embodiment builds system 100 from the ground up by allowing DERs 14 to be the building blocks of the grid and have DERs 14 interact and cooperate. DER system 100 is built organically and scales as the needs of system 100 change. This provides resilience and flexibility to handle inevitable changes such as the addition of intermittent renewable generation, the electrification of transportation with EVs, and the introduction of new storage technologies.

[0040] There are generally two approaches to managing the DER system 100:

[0041] Centralized Top-Down Approach: A single controller, typically located remotely from the DERs, collects information and data from all assets in the system. The centralized controller processes this information and data and calculates optimal dispatch strategies for each DER 14 to achieve a common goal.

[0042] Decentralized bottom-up approach: Control is tied to each DER 14 to provide decision-making capabilities for each DER. This results in the goals of the DER system 100 being achieved through collaboration between the different DERs 14 and the loads 15. A distributed / decentralized system allows assets 14 to share data and resources more efficiently by exchanging less overall information and limiting the scope of objectives and constraints.

[0043] Centralized approaches require complex data to be moved up and down the system hierarchy, and have a single point of data processing and decision making. With an increasing number of variables and nodes, the problem becomes overly complex. Furthermore, the associated latency and delays caused by the communication network can affect the performance of the DER14 in the exemplary embodiment. These limitations result in a large number of "pilot projects" that cannot be scaled beyond niche applications and typically involve high costs.

[0044] In contrast, the inventors have determined that decentralized control over assets 14 is inherently more easily scalable and represents a more natural way to structure a DER system 100. Advantages of a decentralized approach include:

[0045] 1) Intelligence that grows as the system grows. Each time an agent (DER or controllable device) is installed on the grid, a new point of data processing and decision-making is added. As a result, system performance improves over time.

[0046] 2) Simple message exchange. Because decision making is local to each agent, the messages that need to be communicated are much simpler and can be communicated peer-to-peer. For example, no single agent 16 needs to have information about the energy available in all batteries in the system 100.

[0047] 3) System architecture agnostic: More DERs and stakeholders bring more diversity of settings that need to be accommodated, and decentralized algorithms can easily adapt since local decisions are only indirectly influenced by other agents or their location.

[0048] 4) Rapid Response: Autonomous DERs can respond quickly and efficiently to local conditions that affect the larger grid, thus helping to balance the system before a problem escalates into a larger system-wide event that requires a response by the system operator (e.g., ISO).

[0049] 5) It is technology independent. The agents can hide the complexity of the underlying DERs, thus creating a level playing field for any type of energy storage, generation, or load control.

[0050] To illustrate the inherent scalable nature of the distributed approach, consider a system with N DERs 14, where an algorithm determines which DERs 14 should be operational and which should be on standby for performance optimization. This problem is typically faced in systems where the DERs 14 need to receive start or stop commands to be in the appropriate state. This is a classic mixed integer linear programming optimization problem.

[0051] In a centralized approach, a single control agent (e.g., a central controller) obtains information from all DER14s and N The decision is made among a set of system configurations. This problem scales exponentially with the number of DERs. This means that even if an algorithm can work well in a small system with 2-3 DERs, it may not work well in a larger fleet system with 10 assets or even thousands of assets.

[0052] In various embodiments, a distributed algorithm addresses this problem by allowing each DER 14 to make decisions between only two states, on or off, based on its own local information and a small number of variables shared within the system. The complexity of the problem does not increase significantly with the number of DERs, because each additional DER automatically adds another decision maker.

[0053] The inventors have identified that, despite the theoretical desirability of distributed and decentralized control algorithms, there are significant challenges to making distributed control algorithms practical. The inventors have developed a method for widespread DER adoption that simultaneously meets the needs of individual users' unique physical and economic circumstances while also meeting the needs of the larger grid.

[0054] In various embodiments, the method includes predicting an operating trajectory of the DER 14 using a receding horizon control routine in the form of a model predictive control (MPC) routine. The control trajectory is calculated based on the actual state of the DER 14 using an MPC algorithm. The MPC algorithm directly takes into account constraints on the system variables. As such, the MPC algorithm may be advantageously used to find optimal operating trajectories, within safe operating limits, not only for current control set points, but also for future set points. Thus, a schedule of set points may be formed.

[0055] Specifically, the controller executes an MPC routine that receives current operating conditions of the DER 14 (e.g., a microturbine). One or more predicted operating trajectories, including at least one predicted operating trajectory that may include a power output setpoint, are calculated based on the current operating conditions of the DER 14.

[0056] Model predictive control is a control method that utilizes a model of the process to derive control signals by minimizing an objective function (e.g., a cost function) over a finite receding horizon. In various embodiments, a process model is used to predict future DER states and outputs based on past and present values ​​and proposed optimal future control actions. These actions are calculated by a controller, taking into account the cost function, states, and constraints. In other words, the controller generates control signals that minimize the cost function over the forecast horizon. Unfortunately, the computational burden on the controller increases rapidly with increasing forecast horizons, increasing sampling rates, and increasing the number of DERs being modeled.

[0057] As described in more detail below, the inventors have determined that one or more DERs may be optimized while reducing the extensive computational burden by nesting two or more optimization functions.

[0058] FIG. 1C is a schematic diagram of a process for performing a decentralized algorithm according to an exemplary embodiment of the present invention. It should be noted that this method is significantly simplified from a more lengthy process that may be typically used. Thus, the method shown in FIG. 1C may have many other steps that may be used by one skilled in the art. In addition, some of the steps may be performed in a different order than the illustrated example, or may be performed in parallel. Furthermore, some of these steps may be optional in some embodiments. Thus, the process is merely an example of one process according to an exemplary embodiment of the present invention. Thus, one skilled in the art may modify the process as needed.

[0059] The process starts with step 101 of setting the objectives of the DER system 100. Each asset 14 may be behind its own meter. Each asset 14 may be associated with a corresponding asset manager that tracks various details of the asset. Each asset 14 may be tailored to provide a specific function to the local utility according to its local cost function. Thus, each asset may receive a local optimization cost function and an overall system optimization cost function. Optimizing the operation of each asset 14 is a complex problem since each DER must satisfy local objectives and constraints, for example:

[0060] · Minimizing electricity costs subject to local rates and export constraints.

[0061] Extending the life of equipment depending on the technology used.

[0062] · Consider local and resilient needs according to consumer expectations.

[0063] In various embodiments, each asset 14 locally optimizes its own objective. Each asset 14 is then incentivized to deviate from its local optimization so that the system 100 can satisfy requests from the utility. This scheme applies whether there are many participants in the system 100 or few participants, by varying the amount of incentive.

[0064] The process proceeds to step 103, which defines limits for the operation of each asset 14. The decentralized interaction between multiple assets 14 results in an environment where assets 14 are free to modify their outputs to meet their own objectives and the objectives of the global system. However, for safe operation in a real project, various embodiments set boundary limits within that freedom given by physical and regulatory constraints.

[0065] Exemplary embodiments provide algorithms that command individual assets to protect themselves first, maintaining a first layer of protection locally, and global constraints are easily implemented as soft limits based on incentives. The global constraints are implemented as hard limits with simple adjustments to area constraints only when necessary.

[0066] This division of responsibility allows the system 100 to effectively and quickly prepare for and recover from energy oversupply or shortages, thereby enabling a fleet of DERs to collectively observe protection and recovery modes smoothly and automatically.

[0067] The process then proceeds to step 105, which uses MPC combined with distributed control and optimization to create a market for trading power and energy. The exemplary embodiment provides an algorithm that simultaneously manages both short-term, e.g., second-by-second, and longer-term (e.g., daily and weekly) variations in load or generation. The interaction between multiple DERs is similar to a market where a commodity of interest has a price. Each DER decides how much to supply (or take) depending on its own unique characteristics. The two markets resulting from fast and slow system dynamics are fundamentally different:

[0068] · Electricity Markets (seconds): Interactions in response to fast intermittencies result in a market where the commodity of interest is electricity. For example, if there is a sudden connection or disconnection of a large load, DERs are incentivized to respond quickly by providing the requested power. After a few seconds, the system is again in equilibrium at the desired operating point.

[0069] Energy markets (hours to days): Interactions that respond to slower fluctuations make the commodity of interest the unit of electric energy. For example, on days when consumption increases significantly, the energy market incentivizes storage devices to prepare by charging in advance and incentivizes generation resources to come online.

[0070] In both markets, incentives are used to achieve goals, rather than the typical commands found in traditional control and optimization systems. By having each DER make its own decisions and balancing between the two markets, the operational goals of the DER system 100 can be achieved seamlessly without the need for a centralized dispatch authority.

[0071] The two markets are interrelated to produce a unique system response. In the energy market, the DER system 100 builds a consensus on the optimal energy allocation over one or more days. This results in a schedule for each DER's energy import or export, as well as schedules for key state variables (e.g., battery state of charge).

[0072] After the schedule is established from the energy market, it is sent to the power market to communicate and realize the combined optimal resource usage strategy. DERs in the power market bid with small data payloads on a per second basis. The power market keeps the system on an optimal course between the scheduled energy points, allowing for rapid response to events and maintaining optimal balance and operation of the system. In this way, the power market ensures optimal operation within limits and realizes fine-grained DER life extension techniques.

[0073] The process then proceeds to step 107, which distributes the internal market to the various controllers 16. In a typical implementation of a distributed algorithm, the internal market requires a central agent that acts as a "coordinator" or "market operator." The task of the coordinator or market operator is to calculate the price of the commodity by monitoring whether a shortage or surplus occurs. Even if the central agent does not make any dispatching decisions, the scheme has several drawbacks because it (a) requires an authority to define who the central agent is, (b) requires all other central agents to trust the central agent, and (c) has a single point of failure and vulnerability.

[0074] Exemplary embodiments provide multiple ways to make the above market function without the need for a coordinator. This allows for complete symmetry among all agents, i.e. no agent performs a task that is not performed by all other agents. Details of the four algorithms can be found in co-owned patent application "Distributed and Decentralized DER System Optimizations," published as US20200175617A1, the entirety of which is incorporated herein by reference. Certain steps of the price calculation can be split among multiple agents, after which consensus is reached in a matter of seconds. This adds reliability and modularity to the market itself.

[0075] The process then proceeds to step 109, which is to improve the response. In an exemplary embodiment, for market operations, the DER 14 must respond appropriately to incentives. The exemplary embodiment leverages historical operating data to adjust learned parameters and improve the response of the DER over time. In an exemplary embodiment, there are four ways to use this data to improve the DER response:

[0076] · Forecasting: Accurate forecasting is essential in any system with renewable resources and energy storage capabilities, since the value of energy and electricity changes over time. Coming to a consensus on schedules (energy markets) and actual dispatch signals (power markets) should consider not only current commodity prices, but also future expectations. Energy markets use forecasts to plan resource allocation in advance. Meanwhile, power markets prepare response seconds in advance to compensate for DER response times, ramp rates, and start-up delays. This foresight allows power markets to ensure that constraints such as transformer rating limits and non-export regulations are met while at the same time optimizing resource usage.

[0077] Efficiency calculations: Knowing the true operating efficiency of DERs enables robust energy optimization. By using data collected during operation, both electricity and energy markets can leverage knowledge about which operating points are better under which conditions for a given DER.

[0078] Response characteristics: Knowledge of the DER output response to a given set point is used to manage the system operating point through expected and unexpected changes in power flow. Exemplary embodiments learn and incorporate characteristics including response time, overshoot, ramp rate, rise time, settling time, and any delays caused by start-up or shutdown procedures. Examples of measured response characteristics for two different DERs are shown in the following figures.

[0079] Degradation Estimation: By understanding the degradation behavior of DER usage at different operating points, electricity and energy markets can face the right balance between (i) using the resource for economic gain and (ii) degrading that resource, which reduces its operational life. For example, in the case of a battery storage asset, optimal operation not only depends on (i) knowing the current State of health (SoH) of the battery, but also on (ii) the effect of cycling, power output level, state of charge (SoC) level, and temperature on SoH.

[0080] Various embodiments use model predictive control (MPC) to control the output of each asset while satisfying a set of constraints imposed on the asset. The main advantage of MPC is that it can optimize the current time slot while keeping future time slots in mind. This is achieved by optimizing over a finite time horizon. MPC is different from a linear-quadratic regulator (LQR) because it only uses the current time slot and then iteratively optimizes again. MPC also has the ability to predict future events and can take control action accordingly.

[0081] In effect, MPC provides a schedule of what a state variable (e.g., the state of charge of a battery) should do now and in the future within a certain time horizon.

[0082] MPC is a control policy used to implement several different optimization methods in the real world. MPC makes optimization more robust and dynamic since it continuously re-evaluates the estimated results within the time horizon and adjusts the schedule accordingly. For example, when a notification of a future event is received, it is added to the prediction of the state in the receding horizon in order to prepare an appropriate response over time.

[0083] The process then comes to an end.

[0084] FIG. 2 is a schematic diagram of the asset manager 16 of FIG. 1 configured in accordance with an exemplary embodiment of the present invention. As shown, the asset manager 16 of FIG. 2 has multiple components that together perform some of its functions. Each of these components is operatively connected by any conventional interconnect mechanism. FIG. 2 simply illustrates a bus that communicates with each of the components. Those skilled in the art should understand that this generalized representation may be modified to include other conventional direct or indirect connections. Thus, the description of the bus is not intended to limit the various embodiments. The asset manager 16 of the present disclosure may include some or all of the components in the asset manager 16 described in U.S. Patent Nos. 10,903,650 and 10,971,931. The entirety of each of these patents is incorporated herein by reference.

[0085] Indeed, it should be noted that FIG. 2 only illustrates each of these components in a schematic manner. Those skilled in the art will appreciate that, as with one or more other functional components, each of these components may be implemented in a variety of conventional manners, such as by using hardware, software, or a combination of hardware and software. For example, the controller may be implemented using multiple microprocessors running firmware. As another example, the controller may be implemented using one or more application specific integrated circuits (i.e., ASICs) and associated software, or a combination of multiple ASICs, discrete electronic components (e.g., transistors), and microprocessors. Thus, the representation of the controller and other components in a single box in FIG. 2 is for simplicity only. Indeed, in some embodiments, the controllers in FIG. 2 are distributed across multiple different machines, not necessarily located in the same housing or chassis.

[0086] The asset manager 16 includes an MPC controller 21. The MPC controller 21 manages the operation of the asset(s) 14 using, for example, a local cost function to determine an operating point. For example, the operating branch of the asset 14 may be a combination of the active and reactive power that the asset 14 is providing to the system 100. The operating point may also include all internal states of the asset 14 (e.g., temperature, stored energy, voltage, etc.).

[0087] The MPC controller 21 may be distributed to each asset 14. In some other embodiments, the MPC controller 21 may act as a central controller. Nevertheless, the MPC controller performs an MPC optimization over a forecast horizon. In various embodiments, as described further below, the MPC controller beneficially performs two or more MPC optimizations nested together.

[0088] The asset manager 16 also includes an interface 18 for communicating with other assets 14 and / or other devices. For example, the interface 18 is configured to communicate with other asset managers 16 (e.g., to send and / or receive prices calculated by a price calculation engine 20, described below). Additionally, the interface 18 is configured to accept system-wide objectives. In an exemplary embodiment, the system-wide objectives may instruct the system 100 to provide a predetermined amount of active and / or reactive power to the utility 5 (e.g., the total output power of all of the assets 14 in the DER system 100 should be 10 kilowatts). Thus, compliance with the system-wide objectives may be tracked by measuring the power at the branches of the common connection 12.

[0089] The asset manager 16 also includes a price calculation engine 20. The price calculation engine 20 calculates prices that are sent to other asset managers 16. For clarity, in some embodiments of the present invention, a "price" or "price signal" is a signal generated within the cooperative DER system 100. The value of the signal increases when there is more demand for energy than supply, and decreases when there is more supply than demand. For example, the demand for electricity may come from the loads 15 and / or the utility 5. Furthermore, the supply may come from the assets 14 and / or the utility 5. These may also depend on other variables such as reactive power and system losses. In some embodiments, the following cost function:

number

[0090] p i (k) is a price vector (or scalar) at time "k". i is the price calculation function. y out is the value of the output variable being tracked. sp is the set point for the variable.

[0091] Similarly, in some embodiments of the present invention, a "response" is a determination of the active and reactive power output of a DER asset 14, obtained by minimizing a cost function for one or more of the power-related variables. In some exemplary embodiments, the cost function is:

number

[0092] P i * is the calculated optimal output power vector. i is the cost function. Pi is the output power variable to be optimized. i is the price signal mentioned above. x i is a vector of one or more asset states and key variables. Θ is a vector of external variables that affect performance.

[0093] For further discussion of cost functions and pricing, see U.S. Patent Application Serial Nos. 16 / 054,377 and 16 / 683,148, both of which are incorporated herein by reference in their entireties.

[0094] The asset manager 16 may also include (i) a memory 22 for storing data for the assets 14, (ii) a function generator for generating local cost functions, and (iii) asset models used to emulate the behavior of any asset (e.g., diesel generators, gas turbines, batteries, solar panels, wind turbines, loads, etc.). The interface 18 may communicate with the assets 14 using a protocol that may be specific to each asset 14. Preferably, the interface 18 communicates with a central controller and / or other asset managers 16 and / or other agents, both internal and external to the DER system 100, using communication protocols commonly found in the DER system 100. Each of these and other components cooperate to perform the various functions described.

[0095] It should be reiterated that the representation in Figure 2 is a greatly simplified representation of an actual asset manager 16. Those skilled in the art will appreciate that such a device may have many other physical and functional components, such as central processing units, communication modules, protocol translators, sensors, meters, etc. Thus, nothing herein should be construed as implying that Figure 2 represents all elements of an asset manager 16.

[0096] In addition to the components described herein, the asset manager 16 may include other modules such as a voltage meter, a topography engine, a physical property analysis engine, etc., as described in U.S. application Ser. Nos. 16 / 054,377, 16 / 054,967, and / or 16 / 683,148, all of which are incorporated herein by reference in their entireties.

[0097] 3A-3C show three different schemes for optimization of the DER system 100. In both FIG. 3A and FIG. 3B, the central controller 25 calculates the prices and / or setpoints of the assets. FIG. 3A shows a single centralized approach. In the example of FIG. 3A, all calculations, such as calculation of setpoints, are performed by the central controller 21 (also referred to as the central agent 25). FIG. 3B shows a distributed approach. In the example of FIG. 3B, optimization is achieved through the execution of a dual decomposition method or some other distributed optimization approach. For the DER system 100, the distributed approach is more scalable, modular, secure, and reliable than the fully centralized approach shown in FIG. 3A. However, the distributed approach of FIG. 3B relies on a central agent to act as a coordinator and perform multiple tasks, such as calculating the dual variables, also known as prices. Thus, in a distributed system, one or more nodes distribute work to subnodes.

[0098] The inventors have recognized that the dual resolution shown in FIG. 3B has several drawbacks:

[0099] -Requires Central Agent 25.

[0100] The example of FIG. 3B has a single point of failure since it only works if the central controller 25 is functional. For example, if the central controller 25 is down, the optimization of the system 100 will not work. Furthermore, if the central controller 25 fails, the prices sent to each asset will fail.

[0101] Requires all assets to trust the central agent 25. For example, if the DER system 100 spans a neighborhood where all assets 14 include different homeowners, it can be difficult to determine which homeowner should be the authority.

[0102] 3C illustrates a schematic of a system 100 in which prices are calculated by one or more of the assets 14, according to an exemplary embodiment of the present invention. A dedicated central agent 25 is not required. Thus, in various embodiments of the present innovation, the need for a dedicated central agent is eliminated. In some embodiments, a decentralized system has nodes (e.g., assets 14 and / or asset manager 16) that communicate directly with other peers (e.g., instead of via a node / subnode distributed configuration).

[0103] 4 is a schematic diagram of a prediction horizon 102 according to an exemplary embodiment of the present invention. As shown, the prediction horizon 102 includes a number of sampling instants 106 (e.g., t0 to t 10 The MPC optimization algorithm may have eleven sampling time points 106 (up to eleven sampling time points 106). In various embodiments, the sampling time points 106 may be referred to as time slots 106. A time interval 104 may exist between each time slot 106. The time interval 104 may be referred to as a sampling period 104. As shown in Figures 6-11, the MPC optimization algorithm may be represented as a trajectory 140 of the measurement variables for a number of discrete time slots 106.

[0104] FIG. 5 illustrates a schematic of a control trajectory 140 for a given forecast horizon 102 according to an exemplary embodiment of the present invention. For example, the optimization variable may be the output power P of the distributed energy resource 14 (e.g., a battery). Thus, in this example, the trajectory 140 illustrates a schedule of power set points 108 of the DER 14. However, it should be understood that a variety of different state variables may be used (e.g., the state of charge of a battery over 10 hours to control the output temperature of a smart thermostat, etc., the heat flow Q in an HVAC system, etc.) from which output variable set points may be calculated. For example, from the state of charge of a battery, the input power and the output power may be calculated. The trajectory 140 is a timeline of the optimization variables for a current time slot t0 and a number of future time slots t1-t. 10 1 shows the prediction for the control variable P (also called the prediction horizon 102).

[0105] The control trajectory 140 is obtained by implementing an optimization technique (e.g., MPC) to find the value of x that minimizes the cost function J over all time slots 106. Thus, the cost function for any given DER 14 is:

number

[0106] J t0 represents the cost function at time slot t0. t1 Let x denote the cost function for time slot t1, and so on. All these cost functions depend on the variable x. Various embodiments may use distributed optimization techniques. Each of the cost functions for the time slots may be distributed to each DER 14 in the system 100.

[0107] Optimization techniques are used to find the value of x that minimizes the cost function at all time points. Thus, the trajectory plotted is

number

[0108] 5 represents the output of solving the optimization equation and minimizing the cost function over a set of multiple time slots 106. In this example, the control trajectory 140 is a function of the time slots 102 (i.e., t0 through t 11 Optimization is performed over a forecast horizon having a time period (up to t0). Beneficially, a relatively small number of time slots 106 reduces the computational load on the controller. However, the inventors have determined that a forecast horizon 102 with a small number of time slots may undesirably fail to account for system dynamics that lie outside of the time period of the forecast horizon 102 (e.g., long-term dynamics). Furthermore, the inventors have determined that a small number of time slots may undesirably fail to account for rapidly changing system dynamics (e.g., short-term dynamics). For example, the system dynamics may change quickly. In this case, changes occur within the time interval 104 between successive time slots 106 (e.g., between t0 and t1). Alternatively, the system dynamics may be slower. In this case, a given interval may view the dynamics as approximately constant, whereas in reality, the dynamics may affect the endpoint for optimal performance.

[0109] 6 illustrates a schematic diagram of an alternative control trajectory 140 for the same prediction horizon 102 as in FIG. 5, in accordance with an exemplary embodiment. However, in FIG. 6, the control trajectory 140 has a much shorter-term sampling rate; that is, a larger number of control set points 108 are calculated for the same time horizon 102. Each sampled point includes a time series (t0 to t NIn comparison to FIG. 6, the sampling instants 104 are significantly reduced in FIG. 6 because there are a larger number of time slots. It should be appreciated that a higher sampling frequency advantageously provides improved results by taking into account shorter-term system dynamics (e.g., intermittent cloud cover versus solar DER 14). However, those skilled in the art will also appreciate that such a higher sampling frequency undesirably incurs larger computational requirements. Specifically, as known to those skilled in the art, MPC is an iterative process that recalculates an entirely new set of set points 108 for the entire forecast horizon 102 at each sampling instant (i.e., the total number of set points 108 calculated by the controller typically remains the same at each new sampling instant).

[0110] FIG. 7 illustrates, in accordance with an exemplary embodiment, an alternative control trajectory 140 in the same prediction horizon 102 as in FIGS. 5 and 6. However, in contrast to FIG. 5, in FIG. 7, the resolution 110 is reduced. In other words, the MPC routine has (i) a decreasing fast sampling rate (e.g., a fast sampling rate near t0 (e.g., from t0 to t8)) and (ii) a slower sampling rate from t8 to the end of the horizon. Beneficially, the sampling rate illustrated in FIG. 7 takes into account both short-term and long-term system dynamics. Moreover, the sampling rate illustrated by the MPC trajectory in FIG. 7 requires significantly less computational performance than the equivalent sampling rate illustrated by the MPC trajectory in FIG. 6.

[0111] Figures 6 and 7 show trajectories with the same initial sampling frequency (meaning that the setpoint calculations are at the same frequency), but the overall computational complexity in Figure 7 is significantly reduced (e.g., 21 setpoints versus 80 setpoints). Thus, the example in Figure 7 provides a significant computational complexity reduction.

[0112] In the MPC routine shown in FIG. 7, the total number of set points 108 that need to be calculated is smaller. However, the increased resolution (e.g., as shown by the many points from t0 to t1) in the MPC routine forces the controller to run the optimization algorithm at a higher sampling frequency because the MPC routine requires solving the optimization algorithm for each sampling point. For example, the trajectory shown in FIG. 7 has the same initial sampling rate as the trajectory shown in FIG. 6. Therefore, the optimization algorithm represented by the trajectory 140 in FIG. 6 and FIG. 7 runs at the same frequency, even though the trajectory in FIG. 7 has fewer points to solve. Thus, in various embodiments, an algorithm with a reduced resolution may be an undesirable computational burden, especially for application to a DER 14 having a complex model to solve.

[0113] FIG. 8A illustrates, in accordance with an exemplary embodiment, nested control trajectories 140A and 140B in the same forecast horizon 102 as in FIGS. 5-7. The inventors have found that using two separate optimization loops advantageously provides optimization that uses both slow and fast system dynamics while substantially reducing the computational burden compared to other proposed methods. Thus, the DER 14 may be controlled by an optimal approach. Furthermore, by distributing the optimization solution to each DER 14 or its controller 16, the exemplary embodiment provides a DER system 100 that is robust and operates quickly without requiring excessive computational performance (e.g., compared to a single centralized controller).

[0114] The pairwise MPC optimization solves the cost function for a first optimized trajectory 140A having a low resolution in the time horizon 102. In FIG. 8A, this first optimized trajectory 140A is denoted t (1) Using the first optimized trajectory 140A, the set point 108A of the DER 14 is adjusted over a number of sampling times 106:t0 (1) ,t1 (1) ,t2 (1) ,…,t10 (1) 100B). Although a total of eleven points 108A are shown, it should be understood that various embodiments may use longer or shorter prediction horizons 102 with a greater (or lesser) number of sampling instants 106. These various set points 108A take into account the long-term dynamics that affect the DER 100. Thus, the optimization algorithm has a longer horizon 102 (compared to trajectory 140B). However, because the resolution is lower, the long-term MPC algorithm does not need to be solved by the controller at high frequency, and the computational load is low.

[0115] Pair-based MPC optimization (also referred to as nested optimization) solves a cost function of the same-dimensional model or a lower-dimensional (i.e., simpler) model for a second optimization trajectory 140B with fast resolution in the time horizon 102B. In various embodiments, the second optimization trajectory 140B has a short-term prediction horizon 102B. In FIG. 8A, the second optimization trajectory 140B is denoted t (0) By using the second optimized trajectory 140B, the set point 108B of the DER 14 is (0) ,t1 (0) ,…,t 10 (0) However, the set point 108A from the first trajectory 140A acts as a constraint on the second trajectory 140B. In this example, the set point 108A from the first trajectory 140A acts as a constraint on the second trajectory 140B. (1) The set value 108A1 and sample t1 are derived from (1) The set point 108A2 derived from the sample t0 acts as a constraint on the nested optimization trajectory 140B. (1) The set point 108A1 derived from the sample t0 in the trajectory 140B (0) Similarly, the set point 108B1 derived from sample t1 (1) The set point 108A2 derived from sample t in trajectory 140B 10 (0)The setpoint 108B9 derived from the setpoint 108B is the same as the setpoint 108B9 derived from the setpoint 108B. Thus, in various embodiments, the end points of the nested optimization function 140B may be constraints (at least for multiple cycles of the optimization trajectory 140B) derived from the parent optimization function 140A.

[0116] The inventors have found that by making control decisions between setpoints 108A1 and 108A2, the second optimization trajectory 140B can advantageously take into account the short-term dynamics of the DER 140. Because the prediction horizon 102B is short, the short-term MPC algorithm does not solve a large number of points (despite the high frequency), and so the computational load is low. In some embodiments, lower-order models (i.e., simplified models) may be used to speed up the MPC. As known to those skilled in the art, the MPC optimization proceeds one time interval 104 at a time (e.g., subsequent cycles change control setpoints 108B2 to 108B3). 10 (up to 100%) and a recalculation is made for the second cycle, after which the process is repeated again.

[0117] 8B shows a schematic diagram of a second trajectory 140B after executing a second MPC optimization loop according to an exemplary embodiment of the present invention. The MPC is executed at the initial sampling frequency. Point 108B1 is the previous point and is shown for illustrative purposes only. As can be seen from FIG. 8B, the algorithm optimizes the trajectory from points 108B2 to 108B3. 10 (In this case, the previous trajectory 140B has previously been run from points 108B1 to 108B9.) In this example, the constraint given by the parent or top MPC is still point 108B9, but that point is no longer an end point.

[0118] Figures 8A-13 show schematic diagrams of nested function behavior according to exemplary embodiments of the present invention. In the example of Figures 8A-16, three optimization algorithms 140A-140C are nested together. Multiple example optimization set points (i.e., trajectories 140A-140C) are shown for each of the various optimizations.

[0119] Figures 9-11 show another example of nested optimization routines. In this example, three optimizations are nested using MPC routines. Figure 9 shows diagrammatically a trajectory 140A for an optimization function observing the system dynamics every hour. Thus, two constraints 108A1 and 108A2 are obtained for the state variables (e.g. power output at a given time).

[0120] The second optimized trajectory 140B observes the system dynamics every 12 minutes, except that the second optimized trajectory 140B is constrained by the end points 108A1 and 108A2 obtained from the slower trajectory 140A.

[0121] The third optimization trajectory 140C observes the system dynamics every 6 minutes. The third optimization trajectory 140C is constrained by the points defined by trajectories 140A and 140B. Thus, the solutions to the optimization problems of both 140B and 140C at time T=0:00 must be equal to the solution obtained from the parent trajectory 140A (e.g., 108B1 and 108C1 are the same as 108A1). Similarly, the third trajectory 140C is bounded by the second trajectory (e.g., 108B2 is the same as 108C3).

[0122] 10 shows diagrammatically the next step of the optimization function after time t=0:00. Since the prediction horizon of the third trajectory 140C is 18 minutes, a third point 108C5 is determined by the function, however, 108C5 is already constrained by the previously calculated point 108B3.

[0123] FIG. 11 shows a schematic of the MPC optimization at time t=0:12. At this time, the second optimization trajectory 140B is executed again. This defines points 108B2, 108B3, and 108B4. If the system dynamics have changed, the previously calculated output points may change. For example, point 108B3 may now have a value of 50 (instead of the value 100 shown in FIG. 10). Thus, the output of trajectory 140C is changed to match the change in constraints from parent trajectory 140B. It is worth noting that the routine may also change the unconstrained points when the optimization is re-run for each iteration. For example, when the optimization algorithm is executed at time T=0:12 (FIG. 11), it may find that the set point 108C4 should be adjusted compared to when it was calculated at time T=0:06 (FIG. 10).

[0124] 12 is a schematic diagram of a generalization of nesting multiple MPC loops according to an exemplary embodiment. For notational purposes, the top function 140A is the parent function (original function) of the second function 140B and the grandparent function (original original function) of the third optimized trajectory 140C. Similarly, the third trajectory 140C is the child of the second trajectory and the grandchild of the first trajectory. Although only three nested functions are shown in this example, it should be understood that more than two functions (e.g., three, four, five, six, etc.) may be nested.

[0125] FIG. 13 shows a schematic of a nested MPC routine according to an exemplary embodiment. In the example of FIG. 13, the DER 14 is the battery 14. Two MPC loops are used with different forecast horizons. An energy optimization is performed with a forecast horizon of 24 hours with 96 time slots and a time interval of 15 minutes. First, the energy optimization generates a schedule of the battery's state of charge in the next 24 hours. Then, the two first points (65% and 30%) are used as end point constraints for a faster power optimization. The power optimization is performed for 15 minutes with 20 second intervals. The optimization result gives a 20 second schedule for the first 15 minutes. Then, the state of charge schedule can be applied to obtain a power set point schedule by calculating how much power needs to be given or taken by the battery. As mentioned above, the constraints from the parent schedule are applied to the child schedule.

[0126] The advantage of nesting these two MPCs is that the energy optimization (top MPC) can solve the problem 24 hours ahead without worrying about fast transients such as clouds passing a solar panel or individual load connections. The power optimization (bottom MPC) then solves and responds to those fast transients without requiring changes to the energy schedule.

[0127] The example shown in Figure 13 can be extended beyond a single DER 14. For example, consider the case where the battery is also connected to a long-term storage component (e.g., a hydrogen system that aims to capture excess solar power generation in the summer to produce hydrogen and use the hydrogen in the winter). In this case, an example embodiment may add long-term energy optimization and generate three forecast horizons. By way of example, these forecast horizons may be as follows:

[0128] Long-term energy: 180-day forecast horizon with 180 time slots and 1-day interval Short-term Energy: 24-hour forecast horizon with 96 time slots and 15-minute time intervals · Power: 15 minute forecast horizon with 45 time slots and 20 second time interval.

[0129] In an exemplary embodiment, the long-term energy MPC is first solved to obtain a daily schedule for the hydrogen mass in the hydrogen tank. The first two values ​​are then used as the end points of the short-term energy MPC, which gives the schedule for the amount of hydrogen and the SoC of the battery every 15 minutes. Finally, a power loop is run using the first two points of this MPC to obtain the short-term schedule for the amount of hydrogen in the tank and the SoC (state of charge) of the battery. In this way, the power setpoints for the battery and the hydrogen production facility can be obtained.

[0130] Various embodiments may also work with other control systems, such as HVAC load control. Consider the case of a load control that controls an HVAC system to manage the temperature inside a room. The room exchanges heat by conduction through its walls and windows, and the outdoor ambient temperature has a daily cycle (e.g., from day to night). However, there are also some heat sources inside that are turned on and off fairly rapidly (e.g., an oven opening and closing due to some industrial process).

[0131] To properly control the temperature, two nested MPC loops may be defined:

[0132] Daily Cycle MPC: Generates temperature schedules and uses corresponding HVAC according to user demand (e.g., minimizing energy consumption).

[0133] · Short-Term MPC: Follows the above schedule, but generates HVAC actions to compensate for rapid heat injection.

[0134] Additionally, an exemplary embodiment may include a third MPC loop on top of the daily cycle that creates an annual schedule with weekly or monthly time slots to account for temperature fluctuations from summer to winter. Note that creating the annual schedule in this example is much less complex since it does not require the MPC to handle either short-term dynamics (handled by the short-term MPC) or the daily cycle (handled by the daily cycle MPC).

[0135] As yet another example, consider the case of a single-owner fleet of electric vehicles charging from the grid through a single meter with time-of-use and demand charges. MPC is used to create an evolving weekly schedule that maximizes vehicle usage while minimizing utility charges. The schedule shows the state of charge of each vehicle at the end of each shift (e.g., 8 hours). However, faster MPC loops may be used to adapt to changes within the first 8 hour interval. This can account for, for example, traffic that slows down some vehicles, or roadwork that causes some vehicles to take longer routes.

[0136] Each of the nested MPC loops described above may use either a centralized or a decentralized optimization scheme. In some embodiments, the distributed optimization technique uses a dual decomposition or alternating direction method of multipliers (ADMM) technique. In a distributed optimization scheme, optimization involves the interaction of multiple agents in a kind of virtual market where commodities are traded. In the example of FIG. 13 above, the commodity being traded is electricity for the short-term decentralized MPC and energy for the daily decentralized MPC. Thus, there is an electricity market and an energy market, each of which has a price for the commodity. The agents then respond to that price.

[0137] FIG. 14 is a schematic diagram of a process 1400 for optimizing a DER system 100 using nested MPC loops 16 according to an exemplary embodiment of the present invention. It should be noted that this method is significantly simplified from a longer process that may be typically used. Thus, the method shown in FIG. 14 may have many other steps that may be used by one skilled in the art. In addition, some of the steps may be performed in a different order than shown, or even in parallel. Furthermore, some of these steps may be optional in some embodiments. Finally, although this process shows steps for only one MPC, the same process may be performed for all nested MPCs. Step 1406 is the connection between them. Thus, the process 1400 is merely an example of one process according to an exemplary embodiment of the present invention. Thus, one skilled in the art may modify the process as needed.

[0138] The process begins at step 1402, which configures one or more asset managers 16 as MPC controllers 21 that calculate prices. As described above, the MPC controllers 21 are one or more asset managers that calculate prices using system-level and / or local DER cost functions. In some embodiments, when distributed optimization is used, multiple asset managers 16 calculate respective prices (e.g., reserve prices) that are used to determine a system-level price. The MPC controllers 21 also relay the prices to other asset managers 16 to control the output power of assets 14 in the system 100. The one or more asset managers 16 that function as MPC controllers 21 are trusted by the other asset managers 16. In some embodiments, a first asset manager 16 is the MPC controller 21 at a first time (first point in time). Then, a second asset manager 16 is the MPC controller 21 at a second time (second point in time). In some other embodiments, multiple asset managers 16 can be authorities at the same time. 6A-3C below generally illustrate various schemes for one or more asset managers 16 to act as an authority for determining system level prices.

[0139] Returning to FIG. 14 , process 1400 proceeds to step 1404, which sets objectives for DER system 100. Objective setter 30 and meters 32 transmit information to one or more asset managers 16 in accordance with an exemplary embodiment of the present invention. In some embodiments, the objective setter is an entity that determines how cooperative DER system 100 behaves. For example, objective setter 30 may set objectives such as maintaining power flow at a certain level, frequency support, etc. The objectives may be received from an external source or a user.

[0140] In some embodiments, the goal setter is a centralized agent, such as a utility 5, a Supervisory Control and Data Acquisition (SCADA) system, or a Building Management System (BMS). Alternatively, the goal setter may be one or more asset managers 16 (e.g., as a modification in FIG. 2). In other embodiments, one or more objectives may be programmed into multiple asset managers 16. This can eliminate the need for a single goal setter (e.g., in cases where the system 100 maintains the power flow of the common node 12 at zero or some other predetermined level).

[0141] As mentioned above, the objective may be a desired total power output from all of the assets 14 (including the loads 15) in the system 100. In an exemplary embodiment, the objective setter 30 determines the objectives of the DER system 100. For example, the objective setter 30 may be a utility company or a person as an operator. In an exemplary embodiment, the objectives are set based on conditions external and / or internal to the system 100. An external condition may be, for example, that a certain amount of power needs to be provided to the grid 14. An internal condition may be, for example, that the charge on a battery load in the system 100 is too low and that the battery needs to be charged. The objectives are received by one or more asset managers 16. In some embodiments, the asset managers 16 are configured to actively seek information about the objectives. In some embodiments, the objective setter 30 may broadcast the objectives to all asset managers 16. Alternatively, the variables may be sent to only a subset of the asset managers 16.

[0142] For example, an objective may define a predetermined power output of the system 100 at a first time (e.g., daytime) and a different predetermined power output of the system 100 at a second time (e.g., nighttime). Additionally or alternatively, the objective may be an instantaneous power output at a current time. In some embodiments, the power output of the system 100 may be measured at a common connection point 12 through which power from all of the assets 14 in the system 100 passes.

[0143] In step 1406, the MPC defines constraints from the parent MPC at the end points or any other time slots, as appropriate. This is described, for example, in the section above with respect to Figure 13. Note that for the highest level (e.g., trajectory 140A), step 1406 is skipped and the process proceeds directly to step 1408.

[0144] In step 1408, the process obtains parameters, conditions, and prices that affect the objective. For example, the meter of FIG. 5 monitors and / or measures parameters that affect the objective. The meter may be, for example, a voltage meter and / or a current meter. The meter may be connected to or part of one or more of the asset managers 16. The measured parameters are received by one or more asset managers. In some embodiments, the asset managers 16 are configured to actively seek information about the parameters measured by the meter. In some embodiments, the meter may monitor variables that affect the objective (e.g., measured variables) and broadcast the variables to all of the asset managers 16. Alternatively, the variables may be sent to only a subset of the asset managers 16. Prices can be obtained via an interface 18 of FIG. 2 that enables communication between the asset managers.

[0145] In some embodiments, the meter monitors and informs the asset manager 16 what the current status of the system 100 is. This information may be used as a comparison point for system purposes. In an exemplary embodiment, the meter measures the power flow at the common connection point 12. In some other embodiments, one or more devices may be used exclusively as meters, while in other embodiments, one or more of the asset managers 16 may be meters. For example, during off-grid operation, when the DER is the "master" or "grid forming," the asset manager 16 may be the meter.

[0146] In step 1410, the controller predicts the parameters, conditions, and prices at each time slot of the time horizon using any prediction technique. In some embodiments, the prediction may be performed using historical data. In other embodiments, the prediction may be performed using external inputs, such as weather services.

[0147] In step 1412, the MPC controller 21 uses the objectives, measured parameters, status and price, forecast parameters, status and price information, and the model for the particular DER 14 or DER system 100 to calculate a cost function for all time slots of the time horizon 102 according to the MPC routine. For example, the asset manager 16 may receive the relevant objectives and meter information via the interface 18, which may be stored in the memory 22. Additionally, as described above, in some embodiments, the price calculation engine 20 may calculate the price required to perform the distributed optimization.

[0148] As mentioned above, preferably the first MPC time horizon 102 takes into account long term system dynamics. For example, as shown in FIG. 13, the first MPC trajectory 140A has a 24 hour horizon. Furthermore, preferably the first optimized trajectory has a longer time interval 104 than the second optimized trajectory (e.g., 15 minutes versus 20 seconds as shown in FIG. 13). In step 1408, two initial constraints are obtained (e.g., 65% battery at 0 minutes and 30% battery at 15 minutes).

[0149] The process proceeds to step 1414. In step 1414, the controller 21 minimizes a cost function and calculates a schedule of values ​​of the state variables or output power for each time slot.

[0150] In step 1416, if necessary, the output power set point is calculated from the state variable schedule.

[0151] The process then proceeds to step 1418, which asks whether a new cycle of MPC optimization should be performed at a new time horizon, one step forward. As shown in FIG. 13, the second optimization trajectory 140B is recalculated every selected time interval (e.g., every 20 seconds in FIG. 13), as known to those skilled in the art. Similarly, the first optimization trajectory is recalculated every 15 minutes in FIG. 13. Thus, when it is time to recalculate the optimization trajectory at the new time horizon, for example, in trajectory 140A, instead of horizon 102 from 0 minutes to 24 hours, the new horizon is moved from 15 minutes to 24 hours and 15 minutes. As mentioned above, constraints (including change constraints) from the higher level parent optimization are applied to the child optimization.

[0152] Once the optimization algorithm is complete, the process 1400 reaches its end.

[0153] In some embodiments, the price signal of each MPC loop is shared among the assets. The price signal is one of the parameters that affect the cost function. In step 1408, the price is obtained. Thus, process 1400 can be applied to centralized, distributed, or decentralized optimization techniques without modification.

[0154] 15A-15C show schematic diagrams of another example of a nested optimization routine according to an exemplary embodiment of the present invention. In FIG 15A, three trajectories 140A-140C are calculated at time t=0. The third trajectory 140C is recalculated in FIG 15B. The second trajectory 140B and the third trajectory 140C are recalculated in FIG 15C.

[0155] 15A-15C are similar to FIGS. 9-11. However, the prediction horizon 102 of the second trajectory 140B is completely bounded between the first set of end points 108A1 and 108A2 of the first trajectory 140A. In other words, the prediction horizon of the second trajectory extends from the first end point 108A1 to the second end point 108A2. Similarly, the prediction horizon of the third trajectory 140C is completely bounded by the two set points 108B1 and 108B2 of the second trajectory 140B. This is true, at least initially, at the beginning of the routine.

[0156] As shown in FIG. 15B, the third trajectory 140C has advanced one time position (i.e., six minutes) toward position 108C4 so that the third trajectory is no longer completely bounded within the original setpoint range.

[0157] In Fig. 15C it can be seen that the optimization has reached time T = 0:12. At this point, the second point 108B2 on the second trajectory 140B is reached. This causes the controller 21 to recalculate the second optimized trajectory 140B according to the MPC routine. In this example, it can be determined that the setpoint 108B3 has changed (e.g. due to changes in system dynamics) while the remainder of the trajectory 140B has not changed.

[0158] FIG. 15C shows the trajectories 140A-140C in the next time interval. In this time interval (e.g., T=0:12), the third setpoint 108C3 of the third trajectory 140C is used to control the output of the DER 14. Furthermore, the controller 21 recalculates the third trajectory 140C in the prediction horizon according to the MPC routine. Note that the process recalculates the various setpoints in the prediction horizon to take into account the latest changes in the system dynamics. Changes in the system dynamics and / or changes in objectives may cause changes in the setpoints. For example, the setpoint 108C4 has changed from the example of FIG. 15B to the example of FIG. 15C. The setpoint 108C5 has also changed because it is constrained by the second trajectory. In this way, when 108B3 changes, 108C5 always changes as well.

[0159] Various embodiments of the invention may be implemented, at least in part, in any conventional computer programming language. For example, some embodiments may be implemented in a procedural programming language (e.g., C), in a visual programming process, or in an object-oriented programming language (e.g., C++). Other embodiments of the invention may be implemented as pre-configured, stand-alone hardware elements and / or as pre-programmed hardware elements (e.g., application specific integrated circuits, FPGAs, and digital signal processors) or other related components.

[0160] In alternative embodiments, the apparatus and methods disclosed (e.g., in any of the methods, flowcharts, or logic flows described above) may be implemented as a computer program product for use with a computer system. Such embodiments may include a set of computer instructions fixed on any tangible, non-transitory medium, such as a computer-readable medium (e.g., a diskette, a CD-ROM, a ROM, or a fixed disk). The set of computer instructions may embody all or a portion of the functionality described herein above with respect to the system.

[0161] Those skilled in the art will appreciate that the computer instructions can be written in many programming languages ​​for use with many computer architectures or operating systems. Furthermore, the instructions may be stored in any memory device, such as a tangible and non-transitory semiconductor memory device, a magnetic memory device, an optical memory device, or other memory device. The instructions may be transmitted using any suitable medium, such as any communication technology, such as wired (e.g., wire, coaxial cable, fiber optic cable, etc.) or wireless (e.g., through air or space), optical, infrared, RF / microwave, or other communication technologies.

[0162] For example, the computer program product may be distributed on a removable medium with accompanying printed or electronic documentation (e.g., shrink-wrapped software), may be preloaded by a computer system (e.g., on a system ROM or fixed disk), or may be distributed from a server or bulletin board over a network (e.g., the Internet or the World Wide Web). Indeed, some embodiments may be implemented as a software-as-a-service (SAAS) model or a cloud computing model. Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., computer program products) and hardware. Still other embodiments of the invention are implemented entirely as hardware or entirely as software.

[0163] Computer program logic implementing all or part of the functionality described herein above may run at different times (e.g., simultaneously) on a single processor, or on multiple processors at the same or different times, or under a single operating system process / thread, or under different operating system processes / threads. Thus, the term "computer process" refers generally to executing a set of computer program instructions, regardless of whether different computer processes run on the same processor or on different processors, and regardless of whether different computer processes run under the same operating system process / thread or under different operating system processes / threads. Software systems may be implemented using a variety of architectures, such as a monolithic architecture or a microservices architecture.

[0164] Exemplary embodiments of the invention may use conventional components such as conventional computers (e.g., off-the-shelf PCs, mainframes, microprocessors), conventional programmable logic devices (e.g., off-the-shelf FPGAs or PLDs), or conventional hardware components (e.g., off-the-shelf ASICs or discrete hardware components), which, when programmed or configured to perform the non-conventional methods described herein, result in a non-conventional device or system. Thus, even when embodiments are embodied using conventional components, the invention described herein is not conventional in any way, since the resulting devices and systems are necessarily non-conventional, without the presence of special programs or configurations, since the conventional components would not be able to perform the non-conventional functions described in the first place.

[0165] Although various embodiments of the present invention have been described and illustrated herein, those skilled in the art will readily envision various other means and / or configurations for performing the functions and / or obtaining the results and / or one or more advantages described herein. Each such variation and / or modification is deemed to be within the scope of the embodiments of the present invention described herein. More generally, those skilled in the art will readily recognize that (i) all parameters, dimensions, materials, and configurations described herein are intended to be exemplary, and (ii) the actual parameters, dimensions, materials, and / or configurations may depend on the specific application or applications for which the teachings of the present invention are used. Those skilled in the art will recognize or be able to ascertain, using no more than routine experimentation, many equivalents to the specific inventive embodiments described herein. Thus, the foregoing embodiments are presented by way of example only, and it should be understood that within the scope of the appended claims and their equivalents, the inventive embodiments may be realized otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to the individual configurations, systems, products, materials, kits, and / or methods described herein. Additionally, any combination of two or more of the compositions, systems, products, materials, kits, and / or methods, which are not mutually inconsistent, is within the creative scope of the present disclosure.

[0166] The various inventive concepts may be embodied as one or more of the methods that have been illustrated. The acts performed as part of the method may be ordered in any suitable manner. Thus, embodiments may be constructed in which acts are performed in an order different from that shown. Even exemplary embodiments shown as sequential acts may include steps in which multiple acts are performed simultaneously. While the above description discloses various exemplary embodiments of the present invention, it will be apparent to one skilled in the art that various modifications may be made that achieve some of the advantages of the present invention without departing from the true scope of the invention. [Brief description of the drawings]

[0167] [Figure 1A] 1 illustrates a schematic diagram of a DER system including an asset manager used to optimize operation of multiple distributed energy resources and loads to meet overall system objectives according to an exemplary embodiment of the present invention. [Figure 1B] 1 illustrates a schematic diagram of two DER networks according to an exemplary embodiment of the present invention; [Figure 1C] 4 illustrates a schematic diagram of a process for performing a decentralization algorithm according to an exemplary embodiment of the present invention. [Diagram 2] 2 illustrates a schematic diagram of the asset manager of FIG. 1 configured in accordance with an exemplary embodiment of the present invention; [Figure 3A] Three different schemes for the optimization of DER systems are shown briefly. [Figure 3B] Three different schemes for the optimization of DER systems are shown briefly. [Figure 3C] Three different schemes for the optimization of DER systems are shown briefly. [Figure 4] 2 illustrates a schematic diagram of a prediction horizon according to an exemplary embodiment of the present invention; [Diagram 5] 4 illustrates a schematic diagram of a control trajectory at a given prediction horizon according to an exemplary embodiment of the present invention; [Figure 6] 6 illustrates a schematic diagram of an alternative control trajectory in the same prediction horizon as FIG. 5, according to an exemplary embodiment. [Figure 7] 7A and 7B illustrate schematic diagrams of alternative control trajectories in the same prediction horizon as FIGS. 5 and 6, according to an exemplary embodiment. [Figure 8A] 8A-8C are schematic diagrams illustrating nested control trajectories at the same prediction horizon as in FIGS. 5-7, according to an exemplary embodiment. [Figure 8B] 13 illustrates a schematic diagram of a second trajectory after executing a second MPC optimization loop according to an exemplary embodiment of the present invention. [Figure 9]The trajectory of the optimization function observing the system dynamics on an hourly basis is shown diagrammatically. [Figure 10] 4 illustrates diagrammatically the next steps in an optimization function according to an exemplary embodiment of the present invention; [Figure 11] 4 illustrates a schematic diagram of MPC optimization at different times according to an exemplary embodiment of the present invention; [Figure 12] 1 illustrates a schematic diagram of a generalization of nesting of MPC routines according to an exemplary embodiment; [Figure 13] 1 illustrates a schematic diagram of a nested MPC routine according to an exemplary embodiment; [Figure 14] 1 illustrates a schematic diagram of a process for optimizing a DER system using a distributed asset manager according to an exemplary embodiment of the present invention. [Figure 15A] 4 illustrates a schematic diagram of another example of a nested optimization routine according to an exemplary embodiment of the present invention; [Figure 15B] 4 illustrates a schematic diagram of another example of a nested optimization routine according to an exemplary embodiment of the present invention; [Figure 15C] 4 illustrates a schematic diagram of another example of a nested optimization routine according to an exemplary embodiment of the present invention;

Claims

1. 1. A method for controlling distributed energy resources, comprising: obtaining a model of a distributed energy resource or a system of distributed energy resources; determining a first trajectory of a desired power output or state of the distributed energy resource over the course of a first prediction horizon having a first length of time and a plurality of first set points by minimizing a cost function associated with the model; determining a second trajectory of a desired power output or state of the distributed energy resource over the course of a second prediction horizon having a second length of time and a second plurality of set points by minimizing a cost function associated with the model; constraining the second trajectory as a function of a plurality of the first set points; the first length of time is greater than the second length of time; a time interval between sampling times in the first orbit is longer than a time interval between sampling times in the second orbit; the first and second orbits are nested together; A method wherein an end set point of the second plurality of set points is the same as a corresponding set point of the first plurality of set points.

2. 2. The method of claim 1, further comprising determining a third trajectory of a desired power output of the distributed energy resource over the course of a third prediction horizon having a third time length and a plurality of third set points by minimizing a cost function associated with the model.

3. constraining the third trajectory based on a plurality of the first set points and a plurality of the second set points; the second length of time is greater than the third length of time; The method of claim 2 , wherein the time interval between sampling times in the second trajectory is greater than the time interval between sampling times in the third trajectory.

4. 2. The method of claim 1, wherein a plurality of asset managers independently solve their own first and second trajectories in a distributed and decentralized manner.

5. The method of claim 1 , wherein a model predictive control routine is used to recalculate the first trajectory.

6. The method of claim 2 , wherein a model predictive control routine is used to recalculate the second trajectory.

7. The method of claim 1 , wherein the distributed energy resource is part of an HVAC system.

8. The method of claim 1 , wherein the distributed energy resource is a battery.

9. 1. A computer program product for use in a computer system to distribute power from an aggregated distributed energy resource system (DER system) having a plurality of assets, the computer program product comprising: the computer program product includes a tangible, non-transitory computer usable medium having computer readable program code; The computer readable program code comprises: program code for determining a first trajectory of a desired power output or state of the distributed energy resource system over the course of a first horizon having a first length of time and a plurality of first set points by minimizing a cost function associated with a DER model or a DER system model; program code for determining a second trajectory of a desired power output or state of the distributed energy resource system over the course of a second horizon having a second length of time and a plurality of second set points by minimizing a cost function associated with the DER model; and program code for determining to constrain the second trajectory as a function of a plurality of the first set points; the first length of time is greater than the second length of time; a time interval between sampling times in the first orbit is longer than a time interval between sampling times in the second orbit; the first and second orbits are nested together; an end set point of the second plurality of set points is the same as a corresponding set point of the first plurality of set points.

10. 10. The computer program product of claim 9, further comprising program code for determining a third trajectory of a desired power output of the distributed energy resource system over the course of a third prediction horizon having a third time length and a plurality of third set points by minimizing a cost function associated with the DER model.

11. further comprising program code for constraining the third trajectory based on a plurality of the first set points and a plurality of the second set points; the second length of time is greater than the third length of time; 11. The computer program product of claim 10, wherein a time interval between sampling times in the second trajectory is greater than a time interval between sampling times in the third trajectory.

12. 10. The computer program product of claim 9, wherein the program code is distributed to a plurality of asset managers that independently solve their own first and second trajectories in a distributed and decentralized manner.

13. 1. A method for controlling distributed energy resources, comprising: receiving a request for power from a distributed energy resource system; using a model predictive control routine and an asset model to (i) calculate a first predictive operating trajectory as a function of current operating conditions of the distributed energy resource, and (ii) calculate a second predictive operating trajectory as a function of current operating conditions of the distributed energy resource; the first predicted operating trajectory having a first prediction horizon, a first number of set points, and a first number of time slots along the first prediction horizon over which the asset model is solved and optimized; the second prediction trajectory has a second prediction horizon that is shorter in time than the first prediction horizon; the second forecast operating trajectory having a second number of set points and a second number of time slots along the second forecast horizon over which the asset model is solved and optimized; a time interval of the time slots in the second predicted motion trajectory is shorter in time than a time interval of the time slots in the first predicted motion trajectory; the first predicted motion trajectory and the second predicted motion trajectory are nested together; A method wherein an end set point of the second plurality of set points is the same as a corresponding set point of the first plurality of set points.

14. 1. An asset manager for controlling distribution of power in an aggregated distributed energy resource system (DER system) having a plurality of assets, comprising: The asset manager solves a given asset model; The asset manager: Asset models that model real assets, an interface for communicating with at least one other asset manager and / or a central controller in the DER system to receive asset information regarding the real assets; an asset controller that optimizes set points of the asset by (i) determining a first trajectory over the course of a first prediction horizon having a first length of time and a first number of first set points by minimizing a cost function associated with a DER model or a DER system model, and (ii) determining a second trajectory over the course of a second prediction horizon having a second length of time and a second number of second set points by minimizing a cost function associated with the DER model or the DER system model; The asset controller constrains the second trajectory based on a plurality of the first set points; the first length of time is greater than the second length of time; The interval between sampling times in the first trajectory is longer than the interval between sampling times in the second trajectory; the asset manager controls the real assets according to the set points determined by optimization; the first and second orbits are nested together; An end set point of the second plurality of set points is the same as a corresponding set point of the first plurality of set points.

15. 15. The asset manager of claim 14, wherein the asset manager determines a third trajectory over the course of a third forecast horizon having a third time length and a plurality of third set points to optimize the set points by minimizing a cost function associated with the DER model or the DER system model.

16. the asset manager constraining the third trajectory based on a plurality of the first set points and a plurality of the second set points; the second length of time is greater than the third length of time; 16. The asset manager of claim 15, wherein a time interval between sampling times in the second trajectory is greater than a time interval between sampling times in the third trajectory.

17. The asset manager of claim 14 , wherein the asset manager solves its own optimization trajectory in a distributed and decentralized manner.

18. The asset manager of claim 14 , wherein a model predictive control routine is used to recalculate the first trajectory.

19. The asset manager of claim 15 , wherein a model predictive control routine is used to recalculate the second trajectory.

20. The asset manager of claim 14 , wherein the asset manager controls an HVAC system.

Citation Information

Patent Citations

  • Power supply system

    JP2016111871A

  • Building energy system with stochastic model predictive control and demand charge incorporation

    JP2019054718A

  • Method and system for providing flexible reserve power for power grid

    US20190033801A1

  • Methods and systems for secure scheduling and dispatching synthetic regulation reserve from distributed energy resources

    US20190173286A1

  • Building control systems with optimization of equipment life cycle economic value while participating in IBDR and PBDR programs

    US20190195526A1