Patent ID: 12228895

It should be noted that the foregoing figures and the elements depicted therein are not necessarily drawn to consistent scale or to any scale. Unless the context otherwise suggests, like elements are indicated by like numerals. The drawings are primarily for illustrative purposes and are not intended to limit the scope of the inventive subject matter described herein.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In illustrative embodiments, a distributed energy resources system has one or more controllers that work together to control power inputs and outputs into one or more assets. Control of the various assets is based on an optimization algorithm that accounts for both fast and slow system dynamics. To that end, 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 resources system (“DERs system”). Each of the asset models has an underlying mathematical representation of the behavior of a given real asset and/or the DERs system. The controller implements a model predictive control (MPC) routine to run an optimization algorithm for slow system dynamics. The points (e.g., endpoints) determined from the MPC for the slow system dynamics are nested as constraints in an optimization algorithm for faster system dynamics (which may also be an MPC routine). In various embodiments, each of the one or more asset managers solve their respective asset model and control their corresponding asset in accordance with the optimization. The asset is then run in accordance with the setpoint determined by the optimization. Details of illustrative embodiments are discussed below.

FIG.1Aschematically shows a DERs system100including asset managers16that are used to optimize the operation of a plurality of distributed energy resources (DER)14and loads15to fulfill a system-wide objective in accordance with illustrative embodiments of the invention. As known by those of skill in the art, the DER14exchanges real and reactive power with the power network. In contrast, the load15generally consumes or uses real and reactive power. The DER14may be, among other things, solar, micro-turbine, battery, fuel cells, electrolyzer, etc. Although there are distinctions between loads15and DERs14, together both loads and DERs may be referred to as assets14.

In some embodiments, each of the assets14is controllable by a given asset manager16(asset manager16described in additional detail with respect toFIG.2). Additionally, or alternatively, a plurality of the DERs14may be controlled by a single asset manager16. However, in some embodiments, one or more DERs14and/or loads15may not be coupled with the asset manager16. In illustrative embodiments, each asset manager16also contains an asset model18(also referred to as a virtual asset18) configured to simulate the real asset. However, it should be understood that illustrative embodiments may have one or more asset managers16connected to the network100, and each manager18may have one or more asset models18. Furthermore, each asset model18may model a different type of asset (e.g., a battery, solar panels, wind turbine, etc.). Although not shown, illustrative embodiments may include one or more real assets connected to the network12in addition to the model18.

FIG.1Bschematically shows two DERs networks100A and100B. Each of the networks100A and100B has a branch of common coupling12A and12B. A virtual branch of common coupling may be calculated for two independent DERs systems100A and100B in accordance with illustrative embodiments of the invention. The virtual branch of common coupling is formed by combining meter information from the branches of common coupling12of two or more independent aggregated DERs systems100A and100B (e.g.,12A and12B). For example, the real power at the virtual branch of common coupling is the sum of real power measured by meter1at the branch of common coupling12A and the real power measured by meter2at the branch of common coupling12B. Accordingly, any discussion relating to the branch of common coupling12also applies to the virtual branch of common coupling unless the context otherwise requires.

As discussed below, in various embodiments, one or more of the DERs systems100A and100B may be controlled using a decentralized approach. In other embodiments, the DERs systems may be controlled using a centralized approach.

DERs systems100(e.g., microgrids) are deployed across the world in a global effort to modernize power systems and make them more sustainable, resilient and efficient. Various embodiments provide a distributed architecture where every consumer can be a producer and proactively participate in power procurement, utilization and dispatch. As the number of stakeholders in the energy infrastructure increases, a problem arises in determining the role of utilities and how to handle trade-offs between the individual and the collective goals of the grid.

Illustrative embodiments provide an end-to-end solution that converts DERs into intelligent agents that interact and create systems with emergent behavioral properties that meet the collective needs of the system100. Illustrative embodiments achieve this by using local control and decentralized optimization techniques, which leverage concepts from game theory, distributed optimization methods and machine learning.

Illustrative embodiments allow the DERs14to be the fundamental building block of the grid and create systems100from the ground up by having DERs14interact and coordinate. DERs systems100are built organically and scale as the needs of the system100changes, providing resilience and flexibility to accommodate inevitable changes like the addition of intermittent renewable generation, the electrification of transportation with EVs, and the introduction of novel storage technologies.

When it comes to managing the DERs system100, there are two general approaches:Centralized top-down approach: A single controller, typically located away from the DERs, collects information and data from all assets in the system. The centralized controller processes it and calculates the optimal dispatch strategy for each DER14in order to achieve a common goal.Decentralized, bottom-up approach: Control is collocated with each DERs to provide each DER14with decision-making capabilities so that the DERs system100goal can be obtained by the collaboration of the different DERs14and loads15. A distributed/decentralized system enables assets14to share data and resources more efficiently by exchanging less overall information and by limiting the scope of objectives and constraints.

The centralized approach undesirably requires complex data to flow up and down the system hierarchy, and has a single point of data processing and decision-making. As the number of variables and nodes increases, the problem becomes overly complex. Furthermore, the associated latencies and delays caused by the communication network can have an impact on the performance of DERs14of illustrative embodiments. These limitations have led to the abundance of “pilot projects” unable to scale beyond niche applications, and typically with high costs.

In contrast, the inventors have determined that decentralized control of the assets14is inherently easier to scale and represents a more natural way to construct DERs systems100. Advantages of the decentralized approach include:1) Intelligence that grows as the system grows. Every time an agent (DER or controllable device) is installed in the grid, a new point of data processing and decision-making is added, so that the system capabilities increase over time.2) Simple message exchange. Because decisions are local on an agent-by-agent basis, the messages that need to be communicated are much simpler and can be done peer-to-peer. For example, no single agent16needs to have information regarding the energy available in every battery in the system100.3) System architecture agnostic. More DERs and stakeholders lead to a larger diversity of configurations that need to be catered for, something that decentralized algorithms can easily adapt to as the local decisions are only indirectly affected by other agents or their location.4) Rapid response. Autonomous DERs are able to respond rapidly and efficiently to local situations that impact the larger grid, balancing the system before problems escalate to cause larger system-wide events that a system operator (such as an ISO) needs to respond to.5) Technology agnostic. Agents can hide the complexity of their underlying DER, making a level playing field for any type of energy storage, generation or load control.

To illustrate the inherent scalable nature of the decentralized approach, consider a system of N DERs14, in which an algorithm determines which DERs14should be running and which ones should be in standby for optimal performance. This issue is typically encountered in systems as DERs14need to receive a start or a stop command to be in the correct state. This is a typical mixed-integer linear programming optimization problem

In the centralized approach, the unique control agent (e.g., the central controller) takes information from all DERs14and decide between 2{circumflex over ( )}N system configurations. The problem scales exponentially with the number of DERs14, which means that even if an algorithm can perform well in a small system of 2-3 DERs it might not do it in a larger system of 10 assets, much less a large fleet of thousands.

In various embodiments, the decentralized algorithms tackle this problem by allowing each DER14to decide between just two states: on or off, based in its local information and a few 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.

The inventors have determined that despite the theoretical desirability of distributed and decentralized control algorithms, there are significant challenges to bringing the decentralized control algorithms into practice. The inventors developed a method for widespread DER adoption that simultaneously meet the needs of each individual user's unique physical and economic contexts, while also meeting the needs of the larger grid.

In various embodiments, the method involves predicting operational trajectories of the DER14using a receding horizon control routine in the form a model predictive control (MPC) routine. The control trajectory is calculated using an MPC algorithm based on the actual state of the DER14. MPC algorithms take constraints on the system variables directly into account and can thereby advantageously be used to find optimal operational trajectories within safe operational limits, not just for the current control set-points, but also for future set-points, thus forming a schedule of set points.

Specifically, a controller implements an MPC routine that is configured to receiving a current operational state of the DER14(e.g., a micro-turbine). Based on the current operational state of the DER14, one or more predicted operational trajectories are calculated including at least one predicted operational trajectory, which may include a power output set-point.

Model predictive control is a control method that makes use of a model of the process to obtain the control signal by minimizing an objective function (e.g., the cost function) over a finite receding horizon. In various embodiments, the process model is used to predict the future DER states and outputs, based on past and current values and on the proposed optimal future control actions. These actions are calculated by the controller taking into account the cost function, the states and the constraints. In other words, the controller produces a control signal that minimizes the cost function over the prediction horizon. Undesirably, computational burden on the controller grows rapidly with the increases in the prediction horizon, increases in sampling rate, and increases in the number of DERs being modeled.

The inventors determined that one or more DERs may be optimized while reducing large computational burden by nesting two or more optimization functions, as is described in greater detail below.

FIG.1Cschematically shows a process of executing a decentralized algorithm in accordance with illustrative embodiments of the invention. It should be noted that this method is substantially simplified from a longer process that may normally be used. Accordingly, the method shown inFIG.1Cmay have many other steps that those skilled in the art likely would use. In addition, some of the steps may be performed in a different order than that shown, or in parallel. Furthermore, some of these steps may be optional in some embodiments. Accordingly, the process is merely exemplary of one process in accordance with illustrative embodiments of the invention. Those skilled in the art therefore can modify the process as appropriate.

The process begins at step101, which sets objectives for the DERs system100. Each asset14may be behind its own meter. Each asset14may be associated with a corresponding asset manager16that tracks the various details of the asset. In accordance with its local cost function, each asset14may coordinate to provide a certain function to the local utility. Accordingly, each asset may receive a local optimization cost function, and an overall system optimization cost function. Optimizing the operation of each asset14is a complicated problem because each DER has to meet local objectives and constraints, for example:Minimizing the electric bill according to the local rate and export restrictions.Extending the life of the equipment depending for the technology being used.Accounting for local resilience needs that depends on customer expectations.

In various embodiments, each asset14optimizes its own objectives locally and is then incentivized to deviate from that local optimization so that the system100can meet a request from the utility. This scheme adapts to more or less participants in the system100by changing the incentive amount.

The process proceeds to step103, which defines limits on the operation of each asset14. The decentralized interaction between the assets14results in an environment where assets14can change their output freely to meet their own objectives and the global system objectives. However, for a safe operation of actual projects, various embodiments place bounding limits within that freedom, given by physical and regulatory constraints.

Illustrative embodiments provide algorithms that instruct the individual asset to first protect itself, keeping the first layer of protection local. Global constraints are also easily incorporated as soft limits based on incentives, and then, only when necessary, as hard limits by simple adjustments to the restrictions in an area.

Because of this division of responsibility, the system100can effectively and quickly prepare for and recover from over or under-supplies of energy, enabling fleets of DERs to collectively observe protection and recovery modes smoothly and automatically.

The process then proceeds to step105, which creates markets for transacting power and energy using MPC combined with a distributed control and optimization. Illustrative embodiments provide algorithms that simultaneously manage both short-term (e.g., second-by-second) intermittencies, and longer-term (e.g. daily and weekly) variations in load or generation. The interaction between the DERs resembles a market where a commodity of interest has a price and each DER decides how much to supply (or take) depending on its specific characteristics. The two markets that arise from the fast and slow system dynamics are fundamentally different:Power Market: (second-by-second) The interactions to react to fast intermittency leads to a market where the commodity of interest is electric power. For example, if there is a sudden connection or disconnection of a large load, the DERs are incentivized to immediately react by providing the required power, and a few seconds later the system is again in equilibrium at the desired operating point.Energy Market: (hours to days) The interactions to react for slower variations makes the commodity of interest a unit of electric energy. For instance, in a day when consumption is significantly increased, the energy market incentivizes the storage devices to prepare by charging beforehand, and incentivize a generator resource to come online.

In both markets, incentives are used to achieve a goal, rather than the typical command found in traditional control and optimization systems. By letting each DER make its own decision and balance between the two markets, DER system100operational objectives can be achieved seamlessly without the need of a centralized dispatch authority.

The two markets are interrelated to create a unique system response. In the energy market, the DERs system100builds consensus on the optimal energy allocation throughout one or more days, which results in a schedule for each DER energy import or export, plus a schedule for important state variables (for example, state of charge for batteries).

After a schedule from the energy market is established, the schedule is sent to the power market in order to communicate and achieve a combined optimal resource use strategy. DERs in the power market bid together a small data payload second-by-second. The power market maintains the system in the optimal course in between the scheduled energy points, thereby responding immediately to events and keeping the system in optimal balance and operation. In this way, the power market ensures optimal operation within limits and enables fine-granularity life extension techniques for DERs.

The process then proceeds to step107, which distributes the internal markets to various controllers16. In typical implementations of distributed algorithms, the markets require a central agent that acts as a “coordinator” or “market operator” whose task is to calculate the prices of the commodities by monitoring if there is a lack or excess. Even though the central agent makes no dispatch decisions, the scheme has several disadvantages since it (a) requires an authority to define who the central agent is, (b) needs all other agents to trust the central agent, and (c) has a single point of failure and vulnerability.

Illustrative embodiments provide several ways to run the above markets without the need of coordinators, achieving complete symmetry among all the agents. That is, no agent performs a task that is not also performed by all other agents. The details of four of the algorithms can be found in commonly owned patent application “Distributed and Decentralized DER System Optimizations,” published as US20200175617A1, which is incorporated herein by reference in its entirety. Certain steps of the price calculation can be split among the agents and then consensus reached in a matter of seconds, adding reliability and modularity to the market itself.

The process then proceeds to step109, which improves responses. In illustrative embodiments, for market operation, DERs14have to correctly respond to incentives. Illustrative embodiments leverage past operational data to adjust learned parameters and improve those responses over time. There are four ways in which Illustrative embodiments uses this data to improve the DER response:

Forecasting: Accurate forecasts are essential in any system that has renewable resources and energy storage capabilities, as the value of energy and power changes over time. In order to reach consensus for the schedule (energy market) and the actual dispatch signal (power market), the price of the commodity should be considered not only at the present time but also the expected value in the future. The energy market uses forecasting to plan resource allocation ahead of time, while the power market prepares a response seconds in advance to compensate for DERs reaction times, ramp rates and start-up delays. This look-ahead allows the power market to ensure that restrictions such as transformer rated limits and no-export regulations can be met while simultaneously optimizing resource usage.

Efficiency calculation: Understanding the true operational efficiency of DERs allows robust energy optimization. By using data collected during operation, both power and energy markets can leverage knowledge of which operational points are better for a given DER and under what conditions.

Repose characteristic: Knowledge of a DER's output response to a given set-point is used for managing the system operating point through expected and unexpected changes in power flows. Illustrative embodiments learn and incorporate features including reaction time, overshoot, ramp rate, rise time, settling time, and any delays caused by starting up or shutting down procedures. An example of measured response characteristics for two different DERs is shown in the figure below.

Degradation estimation: By understanding the degradation effect of DER usage at different operational points, the power and energy markets can strike the proper balance between using a resource for economic gain and degrading it causing reduced operational life. For example, for a battery storage asset, optimal operation depends not only on understanding the current state of health (SoH) of the battery, but also the effect of cycling, power output level, state of charge (SoC) level and temperature on the SoH.

Various embodiments use model predictive control (MPC) to control the outputs of each asset while satisfying a set of constraints placed on the asset. The main advantage of MPC is that it allows the current timeslot to be optimized, while keeping future timeslots in account. This is achieved by optimizing a finite time-horizon, but only implementing the current timeslot and then optimizing again, repeatedly, thus differing from a linear-quadratic regulator (LQR). Also MPC has the ability to anticipate future events and can take control actions accordingly.

In effect, MPC provides a schedule of what the state variables (e.g., state of charge for batteries) should do right now and in the future within some time horizon.

MPC is a control policy that is used to run different optimization methods in the real world and it helps make optimization more robust and dynamic as it continuously reevaluates the estimations within the time-horizons and adjusts the schedule accordingly. If a notification of a future event is received, for example, that can be added into the forecast of states in the receding horizon to prepare an appropriate response over time.

The process then comes to an end.

FIG.2schematically shows an asset manager16ofFIG.1configured in accordance with illustrative embodiments of the invention. As shown, the asset manager16ofFIG.2has a plurality of components that together perform some of its functions. Each of these components is operatively connected by any conventional interconnect mechanism.FIG.2simply shows a bus communicating with each of the components. Those skilled in the art should understand that this generalized representation can be modified to include other conventional direct or indirect connections. Accordingly, discussion of a bus is not intended to limit various embodiments. The asset manager16of the present disclosure may include some or all of the components in the asset manager16described in U.S. Pat. Nos. 10,903,650, and 10,971,931, each of which is incorporated herein by reference in its entirety.

Indeed, it should be noted thatFIG.2only schematically shows each of these components. Those skilled in the art should understand that each of these components can be implemented in a variety of conventional manners, such as by using hardware, software, or a combination of hardware and software, across one or more other functional components. For example, the controller may be implemented using a plurality of microprocessors executing firmware. As another example, the controller may be implemented using one or more application specific integrated circuits (i.e., “ASICs”) and related software, or a combination of ASICs, discrete electronic components (e.g., transistors), and microprocessors. Accordingly, the representation of the controller and other components in a single box ofFIG.2is for simplicity purposes only. In fact, in some embodiments, the controller ofFIG.2is distributed across a plurality of different machines—not necessarily within the same housing or chassis.

The asset manager16includes an MPC controller21configured to, among other things, use local cost functions to manage operation of its asset(s)14, and determine an operating point. For example, the operating branch of the asset14may be the combination of the real and reactive power that the asset14is injecting into the system100. The operating point may also include all the internal states of the asset14, such as temperatures, stored energy, voltages, etc.

The MPC controller21may be distributed among each asset14. In some other embodiments, the MPC controller21may operate as a central controller. Regardless, the MPC controller performs an MPC optimization over a prediction horizon. In various embodiments, the MPC controller advantageously performs two or more MPC optimizations that are nested together, as discussed further below.

The asset manager16also includes an interface18to communicate with other assets14and/or other devices. For example, the interface18is configured to communicate with other asset managers16(e.g., to send and/or receive the price calculated by a price calculation engine20discussed below). Additionally, the interface18is configured to receive a system-wide objective. In illustrative embodiments, the system-wide objective may instruct the system100to provide a certain amount of real and/or reactive power to the utility5(e.g., the total output power of all of the assets14in the DERs system100should be 10 kWatts). Accordingly, compliance with the system-wide objective can be tracked by measuring the power at the branch of common coupling12.

The asset manager16also includes the price calculation engine20, which calculates the price that is sent to the other asset managers16. For clarity, in some embodiments of the invention, a “price” or “price signal” is a signal generated in a coordinated DERs system100that increases in value when there is more demand than supply of energy and decreases when there is more supply than demand. For example, the demand for power can come from the loads15and/or the utility5. Additionally, the supply can come from the assets14and/or the utility5. It can also be dependent on other variables, such as reactive power and system losses. In some embodiments, the price can be calculated using the following cost function:
pi(k+1)=gi(pi(k),yout,ysp)

Where pi(k)is the price vector (or scalar) at time “k”, giis the price calculation function, youtare the values of the output variables that are being tracked, and yspare the set-points for such variables.

Similarly, in some embodiments of the invention, a “response” is the determination of the real and reactive power outputs of the DER asset14obtained by minimizing a cost function of one or more of its variables with respect to power. In some illustrative embodiments, the cost function can take the form:

Pi★=minPi⁢Ji⁡(Pi,pi,xi,Θ)

Where P*iis the calculated optimal output power vector, Jiis the cost function, Piis the output power variable over which we optimize, piis the price signal described above, xiis a vector of the asset or plurality of asset states and important variables, and Θ is a vector of external variables that affect performance.

Additional discussion of cost functions and the price can be found in U.S. patent application Ser. Nos. 16/054,377, and 16/683,148, which are both incorporated herein by reference in their entireties.

The asset manager16may also include a memory22for storing asset14data, a function generator configured to produce a local cost function, and an asset model used to emulate the behavior of any asset, such as diesel generators, gas turbines, batteries, solar panels, wind turbines, loads, etc. Although the interface18may communicate with the asset14using a protocol that may be proprietary to the respective asset14, it preferably communicates with the central controller and/or other asset managers16and/or other agents inside and outside the DERs system100using a communication protocol commonly found in DERs systems100. Each of these components and other components cooperate to perform the various discussed functions.

It should be reiterated that the representation ofFIG.2is a significantly simplified representation of an actual asset manager16. Those skilled in the art should understand that such a device may have many other physical and functional components, such as central processing units, communication modules, protocol translators, sensors, meters, etc. Accordingly, this discussion is in no way intended to suggest thatFIG.2represents all the elements of an asset manager16.

In addition to the components described herein, the asset manager16may include other modules, such as a voltmeter, topography engine, physical characteristic analysis engine, or others, 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.

FIGS.3A-3Cschematically show three different schemes for optimization of the DERs system100. In bothFIGS.3A and3Ba central controller25calculates the price and/or the set-point for the assets.FIG.3Aschematically shows a single centralized approach, where all the calculations, such as calculating set-points, are performed by the central controller21(also referred to as a central agent25).FIG.3Bschematically shows a distributed approach, where the optimization is achieved through the implementation of the dual-decomposition method or some other distributed optimization approach. For the DERs system100, the distributed approach is more scalable, modular, secure, and reliable than the fully centralized one shown inFIG.3A. However, the distributed approach ofFIG.3Brelies on a central agent to act as a coordinator and perform some tasks such as calculating the dual variables, also known as prices. Thus, in a distributed system, one or more nodes distribute work to sub-nodes.

The inventor recognized that the dual-decomposition shown inFIG.3Bhas a number of disadvantages, namely:Requires a central agent25.It has a single point of failure, as it only works if the central agent25is functional. For example, if the central controller25is down, the optimization of the system100does not function. Additionally, if the central controller25becomes compromised, the price sent to every asset is compromised.Requires that every asset trust the central agent25. For example, if the DERs system100spans a neighborhood where every asset14is with a different homeowner, it is difficult to determine which home owner should be the authority.

FIG.3Cschematically shows the system100where the price is calculated by one or more of the assets14in accordance with illustrative embodiments of the invention. A dedicated central agent25is not required. Thus, in various embodiments of the innovation, the need for a dedicated central agent is removed. In some embodiments, the decentralized system has nodes (e.g., assets14and/or asset managers16) that communicate directly with other peers (e.g., instead of through a node/sub-node distributed arrangement).

FIG.4schematically shows a prediction horizon102in accordance with illustrative embodiments of the invention. As shown, the prediction horizon102has a number of sampling times106(e.g., eleven sampling times106, t0to t10). In various embodiments, the sampling times106may also be referred to as timeslots106. A time interval104may exist between each timeslot106(also referred to as the sampling time104). As shown inFIGS.6-11, the MPC optimization algorithm may be represented as a trajectory140of a measured variable for a number of discrete timeslots106.

FIG.5schematically shows a control trajectory140over a given prediction horizon102in accordance with illustrative embodiments of the invention. For the sake of example, the optimization variable may be output power P for the distributed energy resources14(e.g., a battery). Thus, in this example, the trajectory140shows a schedule of power set points108for the DER14. However, it should be understood that a variety of different state variables may be used (e.g., state of charge of a battery over 10 hours, heat flow Q in HVAC systems, for controlling output temperature of a smart thermostat etc.) from which the output variable set point can be calculated (for example, from a state of charge of a battery, the input and output power can be calculated). The trajectory140shows a prediction for the current timeslot t0, as well as a number of future timeslots t1-t10(also referred to as the prediction horizon102for the control variable P).

The control trajectory140is obtained by running an optimization technique (e.g., MPC) to find the value of x that minimizes the cost function J at all timeslots106. The cost function for any given DER14may thus be represented as:

J=Jt0+Jt1+…+JtN=∑i=0N⁢Jti
where Jt0represents the cost function at timeslot t0, Jt1represents the cost function at timeslot t1, etc. All those cost functions are dependent on the variable x. Various embodiments may use a decentralized optimization technique, wherein each of the cost functions for a timeslot may be distributed for every DER14in the system100.

An optimization technique is used to find the value of x at all times that minimize the cost function. The plotted trajectory therefore may be represented by:

x★=minx⁢(J)

The control trajectory140shown inFIG.5represents the output of solving the optimization equation and minimizing the cost function over a set of timeslots106. In this example, the optimization is run over a prediction horizon with a small number of time slots102(i.e., t0to t11). Advantageously, the relatively small number of timeslots106reduces the computational burden on the controller. However, the inventors have determined that a small number of time slots prediction horizon102may undesirably fail to account for system dynamics that are outside of the prediction horizon102time (e.g., long-term dynamics). Furthermore, the inventors have determined that the small number of time slots may also may undesirably fail to account for rapidly changing system dynamics (e.g. short-term dynamics). For example, system dynamics can change quickly such that the changes occur inside the time interval104between consecutive timeslots106(e.g., between t0and t1). Alternatively, system dynamics can be slower such that the given interval sees the dynamics as almost constant, when in reality the dynamics should impact the end-points for optimal performance.

FIG.6schematically shows an alternative control trajectory140over the same prediction horizon102asFIG.5in accordance with illustrative embodiments. However, inFIG.6the control trajectory140has a much shorter sampling rate (i.e., a greater number of control set points108are calculated over the same time horizon102). Each sampled point is assigned a value (ranging from t0to tN). The sampling time104is substantially reduced inFIG.6so that there are many more time slots as compared toFIG.6. It should be understood that the greater sampling frequency advantageously provides improved outcomes by accounting for shorter term system dynamics (e.g., for a solar DER14, intermittent cloud covering). However, those skilled in the art also understand that such greater sampling frequency undesirably leads to greater computational demands. Specifically, as known by those skilled in the art, MPC is an iterative process that recalculates an entirely new set of setpoints108for the entire prediction horizon102at each sampling time (i.e., the total number of setpoints108calculated by the controller generally stay the same at each new sampling time).

FIG.7schematically shows an alternative control trajectory140over the same prediction horizon102asFIGS.5and6in accordance with illustrative embodiments. However, in contrast withFIG.5,FIG.7has a decreasing resolution110. In other words, the MPC routine has a fast sampling rate that decreases (e.g., fast sampling rate close to t0(e.g., between t0to t8), and slower sampling rate from t8to the end of the horizon. The sampling rate shown inFIG.7advantageously accounts for both short-term system dynamics and long-term system dynamics. Furthermore, the sampling rate shown by the MPC trajectory ofFIG.7requires considerably less computational power than a comparable sampling rate shown in the MPC trajectory ofFIG.6.

AlthoughFIGS.6and7show trajectories with the same initial sampling frequency (meaning the setpoint calculation is at the same frequency), the overall calculation inFIG.7is significantly reduced (e.g., 80 set points as opposed to 21 set points). Accordingly, this results in a large computation reduction.

However, while the MPC routine shown inFIG.7has fewer total set points108that need to be calculated, the increased resolution (e.g., shown by the many points from t0to t1) causes the controller to run the optimization algorithm at the high sampling frequency, because the MPC routine requires resolving the optimization algorithm at every sampling point. For example, the trajectory shown inFIG.7has the same initial sampling rate as the trajectory shown inFIG.6. Therefore, the optimization algorithm represented by the trajectories140inFIG.6andFIG.7are run at the same frequency, despite the trajectory ofFIG.7having fewer points to solve. Thus, in various embodiments, the decreasing resolution algorithm may be undesirably computationally burdensome, particularly with regard to DER14applications having complex models to solve.

FIG.8Aschematically shows nested control trajectories140A and140B over the same prediction horizon102asFIGS.5-7in accordance with illustrative embodiments. The inventors discovered that using two separate optimization loops advantageously provides optimization using both slow and fast system dynamics, while substantially reducing computational burden relative to other proposed methods. Accordingly, the DER14may be controlled in an optimal manner. Furthermore, by distributing the optimization solution to each DER14or a controller16thereof, illustrative embodiments provide a DERs system100that is robust, and that operates quickly and without the need for excessive computational power (e.g., as compared to a single centralized controller).

The paired MPC optimization solves the cost function for a first optimization trajectory140A that has a low-resolution over the time horizon102. InFIG.8A, this first optimization trajectory140A is represented using the nomenclature t(1). Using the first optimization trajectory140A, set points108A for the DER14are obtained at discrete times time for a plurality of sampling times106: t0(1), t1(1), t2(1). . . t10(1). Although eleven total points108A are shown, it should be understood that various embodiments may use a longer or shorter prediction horizon102with more (or fewer) sampling times106. These various set points108A account for long-term dynamics that impact the DER100, and accordingly the optimization algorithm has a longer horizon102(as compared to trajectory140B). However, because the resolution is low, the long-term MPC algorithm does not need to be solved by the controller at a high frequency, and the computational burden is low.

The paired MPC optimization (also referred to as a nested optimization) solves the same or a reduced order model (i.e. simpler) cost function for a second optimization trajectory140B that has a fast-resolution over the time horizon102B. In various embodiments, the second optimization trajectory140B has a short prediction horizon102B. InFIG.8A, the second optimization trajectory140B is represented using the nomenclature) t(0). Using the second optimization trajectory140B, set points108B for the DER14are obtained at time t0(0), t1(0). . . t10(0). However, the set points108A from the first trajectory140A operate as constraints on the second trajectory140B. In this example, the setpoints108A1from sample t0(1)and108A2from sample t1(1)operate as constraints on the nested optimization trajectory140B. Thus, the set point108A1from sample t0(1)is the same as the set point108B1from sample t0(0)in trajectory140B. In a similar manner, the set point108A2from sample t1(1)is the same as the set point108B9from sample t10(0)in trajectory140B. Thus, in various embodiments, the end-points for the nested optimization function140B may be constraints from the parent optimization function140A (at least for some cycles of the optimization trajectory140B).

The inventors discovered that the second optimization trajectory140B advantageously accounts for short-term dynamics of the DER140by making control decisions in between the set points108A1and108A2. Because the prediction horizon102B is short, the short-term MPC algorithm does not solve for a large number of points (despite the high frequency), and the computational burden is low. In some embodiments, a reduced order model (i.e. a simplified model) can be used for the faster MPC. As known by those skilled in the art, the MPC optimization is advanced by one time interval104(e.g., the subsequent cycle determines control setpoints108B2to108B10) and recalculated for the second cycle. This process is then repeated again.

FIG.8Bschematically shows the second trajectory140B after running a second MPC optimization loop in accordance with illustrative embodiments of the invention. MPC is run at the initial sampling frequency. Point108B1is a previous point, and is merely shown for descriptive purposes. As can be seen, the algorithm is rerun for points108B2to108B10(where the previous trajectory140B was run for points108B1to108B9). In this example, the constraint given by the parent or top MPC is still108B9which is no longer an end-point.

FIGS.8A-13schematically show operation of nested functions in accordance with illustrative embodiments of the invention. In the example ofFIGS.8A-16, three optimization algorithms140A-140C are nested together. An example of optimization setpoints (i.e., trajectory140A-140C) is shown for each of the various optimizations.

FIGS.9-11schematically show another example of a nested optimization routine. In this example, three optimizations are nested together using an MPC routine.FIG.9schematically shows a trajectory140A for an optimization function that looks at system dynamics every hour. Accordingly, two constraints108A1and108A2are obtained for state variable (e.g., power output at given time).

A second optimization trajectory140B looks at system dynamics every 12 minutes. However, the second optimization trajectory140B is constrained by the endpoints108A1and108A2obtained from the slower trajectory140A.

A third optimization trajectory140C looks at system dynamics every 6 minutes. The third optimization trajectory140C is constrained by the points determined by trajectory140A and trajectory140B. Thus, the solution to the optimization problem for both140B and140C at time T=0:00 must be equal to the solution obtained from the parent trajectory140A (e.g.,108B1and108C1are the same as108A1). In a similar manner, the third trajectory140C is bounded by the second trajectory (e.g.,108B2is equivalent to108C3).

FIG.10schematically shows the next step in the optimization function, after time t=0:00. Because the prediction horizon for the third trajectory140C is 18-minutes, a third point108C5is determined by the function. However,108C5is already constrained by point108B3, calculated previously.

FIG.11schematically shows the MPC optimization at time t=0:12. At this time, the second optimization trajectory140B is run again. Accordingly, points108B2,108B3, and108B4are determined. If system dynamics have changed, the previously calculated output point may change. For example, point108B3may have a value of 50 now (instead of a value of 100, as shown inFIG.10). Thus, the output of trajectory140C is changed to match the changing of the constraint from the parent trajectory140B. It is also worth noting that the routine may change non-constrained points as the optimization is re-run with every iteration. For example, the optimization algorithm may find that the setpoint108C4should be adjusted when run at time T=0:12 (FIG.11) as compared to when it was calculated at time T=0:06 (FIG.10).

FIG.12schematically shows a generalization of nesting multiple MPC loops in accordance with illustrative embodiments. For nomenclature purposes, the top function140A is considered to be a parent function of the second function140B, and a grandparent function of the third optimization trajectory140C. In a similar manner, the third trajectory140C is a child of the second trajectory and a grandchild of the first trajectory. Although only three nested functions are shown here, it should be understood that two or more functions may be nested (e.g., 3, 4, 5, 6, etc.).

FIG.13schematically shows a nested MPC routine in accordance with illustrative embodiments. In the example ofFIG.13, the DER14is a battery14. Two MPC loops are used at different prediction horizons. An energy optimization is run having a prediction horizon of 24 hours, with 96 timeslots and time intervals of 15 minutes. First the energy optimization creates a schedule for the state of charge of the battery for the next 24 hours. Then the two first points (65% and 30%) are used as the end-point constraints for a faster power optimization. The power optimization runs over 15 minutes with 20 second time intervals. The result of the optimization gives a 20 second schedule for the first 15 minutes. The state of charge schedule can then be applied to obtain a power set point schedule by calculating how much power needs to be given or taken by the battery. As described previously, the constraints from the parent schedule apply to the child schedule.

The advantage of nesting these two MPCs is that the energy optimization (top MPC) solves a problem for 24 hours ahead without worrying about fast transients such as clouds passing by solar panels or individual loads connecting. The power optimization (bottom MPC) then solves for those fast transients and reacts to them without having to change the energy schedule.

The example shown inFIG.13can be expanded beyond a single DER14. For example, consider the case where the battery is also coupled with a long-term storage component (e.g., a hydrogen system that aims to take the overgeneration of solar in the summer, produce hydrogen, and then use it in the winter). Accordingly, illustrative embodiments may thus add a long-term energy optimization, producing three prediction horizons. As an example, these prediction horizons may be as follows:Long-term Energy: Prediction horizon of 180 days, with 180 timeslots and intervals of 1 dayShort-term Energy: Prediction horizon of 24 hours, with 96 timeslots and time intervals of 15 minsPower: Prediction horizon of 15 minutes, with 45 timeslots and time intervals of 20 seconds

In illustrative embodiments, the long-term energy MPC is solved first to obtain a daily schedule for the amount of hydrogen mass in the hydrogen tanks. Then the first two values are used as end-points for the short-term energy MPC that gives a schedule for the amount of hydrogen every 15 mins, and the SoC of batteries. Finally, we use the first two points of this MPC to run the Power loop to obtain a short-term schedule for the amount of hydrogen in the tanks and the SoC (state of charge) of batteries. Power setpoints for the batteries and the hydrogen production facility can be obtained.

Various embodiments may also operate with other control systems, such as HVAC load control. Consider the case of load control where an HVAC systems are controlled to manage temperature inside a room. The room exchanges heat through its walls and windows via conduction, and the outdoor ambient temperature has a daily cycle (day to night for example). However, there are internally also some heat sources that turn on or off quite rapidly (say for example an oven opening and closing due to some industrial process).

To properly control temperature two nested MPC loops may be defined:

Daily Cycle MPC: Create a temperature schedule and the corresponding use of an HVAC depending on user requirements (for example, minimize energy consumption).

Short-term MPC: Follow the above schedule but create actions for the HVAC to compensate for rapid injections of heat.

Furthermore, illustrative embodiments may include a third MPC loop above the daily cycle, one that creates a yearly schedule with weekly or monthly time slots to account for the summer to winter temperature variations. Notice that creating the yearly schedule in this example, does not require the MPC to deal with short-term dynamics (dealt with the short-term MPC) nor the daily cycles (dealt with the Daily Cycle MPC) so that the complexity is rather low.

As yet another example, consider the case of a single-owner fleet of electric vehicle charging from the grid through a single meter that has some time-of-use rates and demand charges. An MPC is used to create an evolving weekly schedule to maximize vehicle use while minimizing the utility bill. The schedule gives the state of charge of every vehicle at the end of each shift (for example 8 hours). However, a faster MPC loop can be used to adjust for changes within the first 8 hour interval to account, for example, for traffic slowing down some vehicles or road work making some vehicles take a longer route.

Each of the nested MPC loops described above can use either a centralized or a distributed optimization scheme. In some embodiments, distributed optimization techniques use dual decomposition or alternating direction method of multipliers (ADMM) techniques. In a distributed optimization scheme, the optimization involves the interaction of multiple agents in a sort of virtual market where a commodity is transacted. In example ofFIG.13above, the commodity being transacted is Power for the short-term distributed MPC, and energy for the daily distributed MPC, so that there is a Power market and an Energy market, each one with a price for the commodity, and agents responses to that price.

FIG.14schematically shows a process1400of optimizing the DERs system100using nested MPC loops16in accordance with illustrative embodiments of the invention. It should be noted that this method is substantially simplified from a longer process that may normally be used. Accordingly, the method shown inFIG.14may have many other steps that those skilled in the art likely would use. In addition, some of the steps may be performed in a different order than that shown, or in parallel. Furthermore, some of these steps may be optional in some embodiments. Finally, this process shows the steps for just one MPC, but the same process could be run for all the MPC that are nested, with step1406being the connection between them. Accordingly, the process1400is merely exemplary of one process in accordance with illustrative embodiments of the invention. Those skilled in the art therefore can modify the process as appropriate.

The process begins at step1402, which sets one or more asset managers16as an MPC controller21that calculates the price. As discussed previously, the MPC controller21is the one or more asset manager(s) that calculate the price using a system-level and/or local DERs cost function. In some embodiments, when distributed optimization is used, a plurality of asset managers16calculate respective prices (e.g., the preliminary price) that are used to determine the system level price. The MPC controller21also relays the price to the other asset managers16so as to control the output power of the assets14in the system100. The one or more asset managers16that function as the MPC controller21are trusted by the other asset managers16. In some embodiments, a first asset manager16is the MPC controller21at a first time. Then, a second asset manager16is the MPC controller21at a second time. In some other embodiments, a plurality of asset managers16may be the authority simultaneously.FIGS.6A-3Cbelow schematically show various schemes of one or more asset managers16functioning as the authority to determine the system level price.

Returning toFIG.14, the process1400proceeds to step1404, which sets an objective for the DERs system100. An objective setter30and a meter32send information to the one or more asset manager16in accordance with illustrative embodiments of the invention. In some embodiments, the objective setter is the entity that determines how the coordinated DERs system100behaves. For example, the objective setter30may set goals such as maintaining power flow at a certain level, frequency support, etc. The objective may also be received from an external source or user.

In some embodiments, the objective setter is a centralized agent, such as a utility5, a Supervisory Control and Data Acquisition (“SCADA”) system or a Building Management System (“BMS”), etc. Alternatively, the objective setter can be one or more asset managers16(e.g., as a modulate inFIG.2). In other embodiments, one or more objectives can be programmed in a plurality of the asset managers16, thereby removing the need for a single objective setter (e.g., where the system100maintains the point of common coupling12power flow at zero or some other pre-determined level).

As described previously, the objective may be a desired total power output from all of the assets14(including loads15) in the system100. In illustrative embodiments, an objective setter30determines the DERs system100objective. For example, the objective setter30may be a utility company, and/a person acting as an operator. In illustrative embodiments, the objective is set based on external and/or internal system100conditions. An external condition may be, for example, that a predefined amount of power needs to be supplied to the grid14. An internal condition may be, for example, that a charge on a battery load in the system100is too low, and that the battery needs to be charged. The objective is received by one or more of the asset managers16. In some embodiments, the asset managers16are configured to actively look for information relating to the objective. In some embodiments, the objective setter30may broadcast the objective to all of the asset managers16. Alternatively, the variables may be forward to only a subset of the asset managers16.

Among other things, the objective may define a predefined power output of the system100during a first time (e.g., during the day), and a different predefined power output of the system100during a second time (e.g., during the night). Additionally, or alternatively, the objective may be an immediate power output at the current time. In some embodiments, the power output of the system100may be measured at the point of common coupling12, through which the power from all of the assets14in the system100passes.

At step1406, the MPC defines constraints from a parent MPC at the end-points or at any other time slot as required. This was described in the sections above, for example with respect toFIG.13. It should be noted that for the highest-level (e.g., trajectory140A), that step1406is skipped, and the process proceeds directly to step1408.

At step1408, the process obtains parameters, states and prices that affect the objective. For example, the meter ofFIG.5monitors and/or measures the parameters that affect the objective. The meter may be, for example, a voltage and/or a current meter. The meter may be coupled with, and/or part of, one or more of the asset managers16. The measured parameters are received by one or more of the asset managers. In some embodiments, the asset managers16are configured to actively look for information relating to the parameters measured by the meter. In some embodiments, the meter may monitor and broadcast the variables (e.g., that are measured) that affect the objective to all of the asset managers16. Alternatively, the variables may be forward to only a subset of the asset managers16. The price may be obtained via the interface18ofFIG.2that allows communication between asset managers.

In some embodiments, the meter monitors and tells the asset managers16what the current status of the system100is. This information may be used as a point of comparison to the system objectives. In illustrative embodiments, the meter measures the power flow at the point of common coupling12. In some other embodiments, one or more devices can be exclusively used as the meter, while in other embodiments, one or more asset managers16can be the meter. For example, when operating off-the-grid and the DER is the “master” or “grid-forming,” the asset manager16maybe the meter.

At step1410the controller forecasts parameters, states and prices at every time slot over the time horizon using any forecasting technique. In some embodiments, this forecasting can be done using historical data, and in others it can be done using external inputs such as weather forecast services.

At step1412, the MPC controller21uses the information relating to the objective, the measured parameters, states and prices, the forecasted parameters, states and prices and a model of a particular DER14or DERs system100to calculate the cost function at every time slot over a time horizon102for an MPC routine For example, the asset manager16may receive the relevant objective and meter information via the interface18. That information may be stored in the memory22. Additionally, as described previously, in some embodiments the price calculation engine20may calculate the price required to perform a distributed optimization.

As discussed previously, preferably the first MPC time horizon102accounts for long-term system dynamics. For example, as shown inFIG.13, the first MPC trajectory140A has a horizon of 24 hours. Furthermore, the first optimization trajectory preferably has an increased time interval104relative to the second optimization trajectory (e.g., 15 minutes as opposed to 20 seconds as shown inFIG.13). Two initial constraints are obtained at step1408(e.g., 65% battery at 0 minutes, and 30% battery at 15 minutes).

The process proceeds to step1414, where the controller21minimizes the cost function to calculate a schedule for the value of a state variable or the output power at every time slot.

At step1416, the output power set point is calculated from a state variable schedule if required.

The process then proceeds to step1418, which asks whether a new cycle of MPC optimization should be run against over a new temporal horizon that has moved one step forward. With reference toFIG.13, and as known by those of skill in the art, the second optimization trajectory140B is recalculated at every selected time interval (E.g., every 20 seconds inFIG.13). In a similar manner, the first optimization trajectory is recalculated every 15 minutes inFIG.13. Accordingly, if the time has come to recalculate the optimization trajectories over a new tome horizon (e.g., in trajectory140A, instead of a horizon102from 0 minutes to 24 hours, the new horizon is moved 15 minutes to 24 hours and 15 minutes). As described previously, the constraints (including changes constraints) from higher level parent optimizations are applied to the child optimization.

When the optimization algorithm is finished, the process1400comes to an end.

In some embodiments, a price signal for every MPC loop is shared among the assets and it is one of the parameters that affect the cost function. The price is obtained in step1408. Therefore, the process1400can be applied with centralized, distributed or decentralized optimization techniques without modification.

FIGS.15A-15Cschematically show another example of a nested optimization routine in accordance with illustrative embodiments of the invention. Three trajectories140A-140C are calculated inFIG.15Aat time t=0. The third trajectory140C is recalculated inFIG.15B. The second and third trajectories140B,140C are recalculated inFIG.15C.

FIGS.15A-15Care similar toFIGS.9-11. However, the prediction horizon102of the second trajectory140B is completely bounded between the first set of endpoints108A1and108A2of the first trajectory140A. In other words, the prediction horizon of the second trajectory stretches from the first end point108A1to the second end point108A2. Similarly, the prediction horizon of the third trajectory140C is completely bounded by the two setpoints108B1and108B2of the second trajectory140B. This is the case at least initially at the onset of the routine.

As shown inFIG.15B, the third trajectory140C is no longer bounded completely within the first set point, as the third trajectory has advanced forward one time position (i.e., 6 minutes) to position108C4.

InFIG.15Cit can be seen that the optimization has reached time T=0:12. At this time, the second point108B2in the second trajectory140B is reached. Accordingly, the controller21recalculates the second optimization trajectory140B in accordance with the MPC routine. It may be determined that the remainder of the trajectory140B does not change, but in this example, setpoint108B3has changed (e.g., because of changes to system dynamics).

FIG.15Cshows the trajectories140A-140C at the next time interval. At this time interval (e.g., T=0:12), the third setpoint108C3of the third trajectory140C is used to control the output of the DER14. Furthermore, the controller21now recalculates the third trajectory140C in accordance with the MPC routine over the prediction horizon. It should be noted that the process recalculates the various setpoints over the prediction horizon to account for the most recent changes in system dynamics. Changes in system dynamics and/or in the objective may cause changes in the setpoints. For example, setpoint108C4changed fromFIG.15BtoFIG.15C. Setpoint108C5has also changed, but because108C5is constrained by the second trajectory. Thus, any time108B3changes,108C5also changes.

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”), as a visual programming process, or in an object-oriented programming language (e.g., “C++”). Other embodiments of the invention may be implemented as a pre-configured, stand-alone hardware element and/or as preprogrammed hardware elements (e.g., application specific integrated circuits, FPGAs, and digital signal processors), or other related components.

In an alternative embodiment, the disclosed apparatus and methods (e.g., as in any methods, flow charts, or logic flows described above) may be implemented as a computer program product for use with a computer system. Such implementation may include a series of computer instructions fixed either on a tangible, non-transitory, non-transient medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk). The series of computer instructions can embody all or part of the functionality previously described herein with respect to the system.

Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as a tangible, non-transitory semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, RF/microwave, or other transmission technologies over any appropriate medium, e.g., wired (e.g., wire, coaxial cable, fiber optic cable, etc.) or wireless (e.g., through air or space).

Among other ways, such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e.g., the Internet or World Wide Web). In fact, some embodiments may be implemented in a software-as-a-service model (“SAAS”) or cloud computing model. Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software.

Computer program logic implementing all or part of the functionality previously described herein may be executed at different times on a single processor (e.g., concurrently) or may be executed at the same or different times on multiple processors and may run under a single operating system process/thread or under different operating system processes/threads. Thus, the term “computer process” refers generally to the execution of a set of computer program instructions regardless of whether different computer processes are executed on the same or different processors and regardless of whether different computer processes run under the same operating system process/thread or different operating system processes/threads. Software systems may be implemented using various architectures such as a monolithic architecture or a microservices architecture.

Illustrative embodiments of the present invention may employ 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, produce non-conventional devices or systems. Thus, there is nothing conventional about the inventions described herein because even when embodiments are implemented using conventional components, the resulting devices and systems are necessarily non-conventional because, absent special programming or configuration, the conventional components do not inherently perform the described non-conventional functions.

While various inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and/or configurations will depend upon the specific application or applications for which the inventive teachings is/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. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and/or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and/or methods, if such features, systems, articles, materials, kits, and/or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.

Various inventive concepts may be embodied as one or more methods, of which examples have been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

Although the above discussion discloses various exemplary embodiments of the invention, it should be apparent that those skilled in the art can make various modifications that will achieve some of the advantages of the invention without departing from the true scope of the invention.