Patent Grant
11468460
This application relates generally to the field of power grid management and control.
Disclosed below are representative embodiments of methods, apparatus, and systems for facilitating operation and control of a resource distribution system (such as a power grid). For example, embodiments of the disclosed technology can be used to improve the resiliency of a power grid and to allow for improved consumption of renewable resources. Further, certain implementations facilitate a degree of decentralized operations not available elsewhere.
“Transactive control and coordination” features market-like mechanisms for the selection of resources and demand-side assets in an electric power grid. The disclosed technology concerns new embodiments of transactive control and coordination. Such embodiments allow for transactive control and coordination where: (1) the system is implemented over large geographic areas; (2) the system is implemented across multiple grid regulation and/or business boundaries; (3) a large diversity of participating resources and loads are to be coordinated; and/or (4) the system desirably functions at multiple scales (e.g., both large areas of the transmission region and at individual devices).
Locations on the electric power grid that perform one or more of the disclosed techniques of are sometimes referred to herein as “transactive nodes.” Further, embodiments of the disclosed technology are described in terms of an “algorithmic framework,” where the highest-level responsibilities that are to be conducted at a transactive node are discussed. In certain embodiments, two functional blocks within the algorithmic framework allow for the further incorporation of (1) “toolkit resource functions” and/or (2) “toolkit load functions.” For example, depending on the unique features extant at a given transactive node (e.g., certain types of generation resources, inelastic electrical loads, other loads that might be responsive to a price-like signal in a demand-responsive way), one or more toolkit functions and their unique functionality may be incorporated. These toolkit functions can respectively modify the formulation of the price-like signal by the framework, or modify the amount of load that is to be generated or consumed by assets at this grid location. The functions can also advise the control of responsive assets.
Embodiments of the disclosed technology can be used to realize the fully distributed coordination of electrical power grids. In certain embodiments, such coordination can be accomplished by having nearest circuit neighbors exchange transactive signals. Desirably, these signals include not only price and quantity signals for an imminent time interval, but also predicted signals for future time intervals. In certain implementations, at least two subclasses of transactive signal are used—one price-like and the other representing power. The transactive signal that represents power (the TFS) is usefully aggregated where the power is also combined in a circuit and represents the power flow between circuit neighbors; a price-like signal (the TIS) may fairly represent costs of multiple resources and incentives if such costs are proportionately added where the resources are injected into and where the incentives occur in the electrical circuit.
In certain implementations, and in contrast to system utilizing explicit bilateral markets, some of the disclosed systems use planned energy consumption as the feedback.
Also disclosed herein are tools and techniques for computing distributed relative power flow. For example, a distributed relative power flow method is formulated for electrical power systems. In certain embodiments, a node is allowed to allocate its generation or load changes among the power flows with its neighbors without the global knowledge of the power system. Further, in some embodiments, decisions are made independently at distributed locations to respond to incentive signals from distributed transactive control. The impacts of these decisions on power flow are desirably predicted, which is presently challenging to do with conventional power flow formulations. In certain embodiments, parallel computation is an inherent feature of the disclosed formulation.
Conventional power flow solvers, usually located at a central location, rely on the global knowledge of the power system to predict the impacts of generation or load changes on the power flow. However, it is challenging to predict the power flow by using such solvers at distributed locations, where only information from neighbor nodes may be available. This is not the case with embodiments of the disclosed distributed relative power flow formulations.
Embodiments of the disclosed power flow formulation can be used in a variety of environments. For example, such implementations can be used as part of a “smart grid” system, which heavily relies on two-way communication and transactive control.
Decisions to respond to incentive signals from transactive control cause power flow changes, which can be predicted in parallel at distributed locations, without knowledge of the entire power system.
Details of exemplary non-limiting embodiments of the disclosed technology are disclosed and illustrated in the sections below. Any one or more of the features, aspects, and/or functions described in any of the sections below or above can be used alone or in any combination or sub-combination with one another.
Embodiments of the disclosed methods can be performed using computing hardware, such as a computer processor or an integrated circuit. For example, embodiments of the disclosed methods can be performed by software stored on one or more non-transitory computer-readable media (e.g., one or more optical media discs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory or storage components (such as hard drives)). Such software can be executed on a single computer or on a networked computer (e.g., via the Internet, a wide-area network, a local-area network, a client-server network, a cloud-based network, or other such network). Embodiments of the disclosed methods can also be performed by specialized computing hardware (e.g., one or more application specific integrated circuits (“ASICs”) or programmable logic devices (such as field programmable gate arrays (“FPGAs”)) configured to perform any of the disclosed methods). Additionally, any intermediate or final result created or modified using any of the disclosed methods can be stored on a non-transitory storage medium (e.g., one or more optical media discs, volatile memory or storage components (such as DRAM or SRAM), or nonvolatile memory or storage components (such as hard drives)) and are considered to be within the scope of this disclosure. Furthermore, any of the software embodiments (comprising, for example, computer-executable instructions which when executed by a computer cause the computer to perform any of the disclosed methods), intermediate results, or final results created or modified by the disclosed methods can be transmitted, received, or accessed through a suitable communication means.
The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.
Disclosed below are representative embodiments of methods, apparatus, and systems for facilitating operation and control of a resource distribution system (such as a power grid). The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with one another. Furthermore, any one or more features or aspects of the disclosed embodiments can be used in various combinations and subcombinations with one another. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods. Additionally, the description sometimes uses terms like “determine” and “generate” to describe the disclosed methods. These terms are high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms may vary depending on the particular implementation and are readily discernible by one of ordinary skill in the art. Furthermore, as used herein, the term “and/or” means any one item or combination of items in the phrase.
Any of the disclosed methods can be implemented using computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as hard drives)) and executed by a processor in a computing device (e.g., a computer, such as any commercially available computer). Any of the computer-executable instructions for implementing the disclosed techniques as well as any intermediate or final data created and used during implementation of the disclosed systems can be stored on one or more computer-readable media (e.g., non-transitory computer-readable media). The computer-executable instructions can be part of, for example, a dedicated software application or as part of a software agent's transport payload that is accessed or downloaded via a network (e.g., a local-area network, a wide-area network, a client-server network, or other such network).
Such software can be executed on a single computer (e.g., a computer embedded in or electrically coupled to a sensor, controller, or other device in the power grid) or in a network environment. For example, the software can be executed by a computer embedded in or communicatively coupled to a sensor for measuring electrical parameters of a power line or electrical device, a synchrophasor sensor, a smart meter, a control unit for a home or household appliance or system (e.g., an air-conditioning unit; heating unit; heating, ventilation, and air conditioning (“HVAC”) system; hot water heater; refrigerator; dish washer; washing machine; dryer; oven; microwave oven; pump; home lighting system; electrical charger; electric vehicle charger; home electrical system; or any other electrical system having variable performance states), a control unit for a distributed generator (e.g., photovoltaic arrays, wind turbines, or electric battery charging systems), a control unit for controlling the distribution or generation of power along the power grid (e.g., a transformer, switch, circuit breaker, generator, resource provider, or any other device on the power grid configured to perform a control action), and the like. Further, any of the control units can also include or receive information from one or more sensors. Any of the transactive nodes described herein can be formed by such sensors, meters, control units, and/or other such units.
For clarity, only certain selected aspects of the software-based embodiments are described. Other details that are well known in the art are omitted. For example, it should be understood that the software-based embodiments are not limited to any specific computer language or program. For instance, embodiments of the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, Python, JINI, .NET, Lua or any other suitable programming language. Likewise, embodiments of the disclosed technology are not limited to any particular computer or type of hardware. Details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure. Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions which when executed by a computer cause the computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
The disclosed methods can also be implemented by specialized computing hardware that is configured to perform any of the disclosed methods. For example, the disclosed methods can be implemented by a computing device comprising an integrated circuit (e.g., an application specific integrated circuit (“ASIC”) or programmable logic device (“PLD”), such as a field programmable gate array (“FPGA”)). The integrated circuit or specialized computing hardware can be embedded in or directly coupled to a sensor, control unit, or other device in the power grid. For example, the integrated circuit can be embedded in or otherwise coupled to a synchrophasor sensor, smart meter, control unit for a home or household appliance or system, a control unit for a distributed generator, a control unit for controlling power distribution on the grid, or other such device.
With reference to
The computing environment can have additional features. For example, the computing environment 100 includes storage 140, one or more input devices 150, one or more output devices 160, and one or more communication connections 170. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 100. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 100, and coordinates activities of the components of the computing environment 100.
The storage 140 can be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other tangible storage medium which can be used to store information in a non-transitory manner and which can be accessed within the computing environment 100. The storage 140 can also store instructions for the software 180 implementing any of the described techniques, systems, or environments. The input device(s) 150 can be a touch input device such as a keyboard, mouse, touch screen, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment 100. The output device(s) 160 can be a display, touch screen, printer, speaker, or another device that provides output from the computing environment 100.
The communication connection(s) 170 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, an agent transport payload, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
The various methods, systems, and interfaces disclosed herein can be described in the general context of computer-executable instructions stored on one or more computer-readable media. Computer-readable media are any available media that can be accessed within or by a computing environment but do not encompass transitory signals or carrier waves. By way of example, and not limitation, with the computing environment 100, computer-readable media include tangible non-transitory computer-readable media, such as memory 120 and storage 140.
The various methods, systems, and interfaces disclosed herein can also be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments.
Computer-executable instructions for program modules may be executed within a local or distributed computing environment. As noted, the disclosed technology is implemented at least part using a network of computing devices (e.g., any of the computing device examples described above). The network can be implemented at least in part as a Local Area Network (“LAN”) using wired networking (e.g., the Ethernet IEEE standard 802.3 or other appropriate standard) or wireless networking (e.g. one of the IEEE standards 802.11a, 802.11b, 802.11g, or 802.11n or other appropriate standard). Furthermore, at least part of the network can be the Internet or a similar public network.
This disclosure sometimes makes reference to the following acronyms:
This disclosure will sometimes make reference to the following terms, whose non-limiting definitions are provided below. These definitions do not necessarily apply in all instances and may vary depending on the context.
This section introduces some of the basic concepts of the disclosed transactive control and coordination technology.
At any point in the topology where one can affect the flow of power, operational objectives may be taken into account. In the transactive control technique of the disclosed technology, these objectives can be monetized and included in a signal referred to as the “transactive incentive signal” (TIS). If at a given point, one should reduce load below that point, then the monetization computations will result in altering (e.g., raising) the value of the TIS. If, on the other hand, it is beneficial to add load below that point, then the computations will alter (e.g., lower) the value of the TIS in the opposite direction. In other words, by using embodiments of the disclosed transactive system, one can represent operational objectives to responsive elements of the system and incentivize them to change their behavior in response to the monetized objectives. In
The responsive elements of the system also play an active role through making information available about their planned consumption of electric power. This is represented by the arrow from left-to-right labeled “status and opportunities.” In embodiments of the disclosed technology, information about the future forecast of the plans for generation resources and constraints associated with the flow of power through the system interact with temporally aligned information about the planned behavior or loads or other responsive resources. Local storage systems are an example of another type of responsive resource that may be thought of as being a positive, neutral (not consuming), or negative load.
With this general background, the following additional features of the transactive control and coordination system will now be introduced.
The basic operational unit of embodiments of the illustrated transactive control technique is the transactive control node. In certain implementations, the transactive control node responds to system conditions as represented by incoming Transactive Incentive Signals and Transactive Feedback Signals through (a) incorporation of local asset status and other local information; (b) decisions about behavior of local assets; and/or (c) updating both transactive incentive and feedback signals. Inputs are used by the node to compute incentive and feedback signals. Further, in some embodiments, each signal is a sequence of forecasts for a time-series, so inputs will also be sequences of future (forecast/planned) values
Transactive control nodes may be implemented any place in the power system topology, preferably where it is possible to affect the flow of power in the system. This is true in both the bulk power system and carries through into the distribution system down to the end-use level. For example, embodiments of the disclosed technology can be used in a large region of the power grid (e.g., a large interconnected region of the transmission grid, sometimes referred to as a transmission zone), a distribution utility service territory, or for any other sized region, area, or space (e.g., at the substation level, at the feeder level, at a building level, or even at the household level. Transactive control nodes may be implemented down to the level of individual devices. One may also implement transactive control nodes that manage a collection of devices as an aggregated responsive asset or asset system.
At the utility level, the utility has the opportunity to introduce local information and operational objectives. For example, the utility may wish to avoid demand charges associated with peak loads. The financial impact of peak loads can be used in calculating TIS values to incentivize load shifting.
In the example, there are also renewable generation assets local to the utility. The utility may also incentivize consumption of energy from these assets through the TIS. On the right hand side of
Missing from this example is the transactive feedback signal representing the behavior of the responsive assets. A feature of certain embodiments of the transactive control technique is that this signal and the transactive incentive signal are both used at a transactive control node to make decisions about the behavior of responsive assets controlled at that node or to be incentivized by that node. This interaction between the TIS and TFS takes place based on the forecast of cost of power delivered and the behavior of responsive assets. Through this interaction, a form of closed loop control is achieved. The decision logic and algorithmic functions of the transactive control node are desirably constructed in such a manner as to have convergence and to avoid oscillation.
One can better understand this interaction between the TIS and TFS through a simple qualitative example. Consider the following scenario. On a distribution feeder, imagine a pole top transformer feeding three houses. Each home has an electric vehicle. For this example, assume that each of the vehicle owners will want to fast charge their vehicle. With the normal base load for the three houses, all three vehicles fast charging will overload the pole top transformer.
In this example, the pole top transformer is receiving a TIS from upstream (presumably from the substation) and a TFS from each of the houses. The TFS from each house includes information about the planned charging activity for the corresponding electric vehicle. The transformer desirably makes decisions about whether to change the value of the TIS based on the current and future load as represented by aggregating the TFS from each house. It also may take into account other information, such as the ambient air temperature, weather forecasts, operating history, and so forth.
The three electric vehicles in this example, EV1, EV2, and EV3, each have different charging strategies. EV1 is capable of flexible charging, meaning that the rate of charge can be varied. EV2 charges at any cost. EV3 is a bargain hunter and will schedule charging when cost is low.
For this example, assume the following: EV1 desires to charge at 5 PM, EV2 wishes to charge at 6 PM and EV3 wishes to charge at 7 PM. Assume as well that there is a typical diurnal load curve for the three houses seen in this example as the combined load at the transformer. The pole-top transformer has a load rating of 40 kW. As long as the load is below 40 kW, the service life of the transformer is not being degraded. If the load is above 40 kW, then the service life of the transformer is reduced depending on factors including the load, the duration of load above the 40-kW limit, ambient air temperature and possibly other factors. The operating principle for the transformer's update to the TIS is a computation in which the monetary impact of load is computed based on the forecasted duration above the limit and the other factors mentioned. This computation can be performed with information about the cost to replace the transformer, the rated service life, and if desired, economic factors such as the cost of money. The point is that the impact of overloading the transformer is monetized and the result used to change the forecast value of the TIS.
The electric vehicle smart chargers may then respond to the change in TIS value (e.g., increased for overloading) and adjust their plans accordingly. A back and forth exchange, a negotiation if you will, takes place through the exchange of TIS and TFS updates. When the negotiation settles, then the “agreed” solution to consumption should be stable barring other perturbations.
A key challenge in this negotiation is to avoid oscillation. The algorithms and decision logic for both the smart charger and the transformer desirably have appropriate damping factors to drive the negotiation to a stable, non-oscillatory result. In this simple example, a qualitative result is presented to illustrate the nature of the interaction.
In the figure, the broad dashed line represents the forecast total load. Notice that between hours 16 and 17, it simply tracks the normal diurnal load pattern. When the charging plans of the EV's are revealed through the TFS sent to the pole-top tranformer's transactive control node the forecast total load remains below the transformer's load limit until the time that EV2 proposes to start charging. Note that, in this example, all vehicles are proposing a level-2 fast charge initially.
When EV2 proposes to begin charging at hour 18, the forecast total load goes above the load limit. The TIS correspondingly increases above the TIS that is associated with the normal diurnal load. EV3's proposal to begin charging at hour 19 pushes the forecast load even higher. If all three vehicles are level-2 charging, the load approaches 10 kW above the load limit. With the three proposed charging times revealed, the TIS is adjusted and the vehicles respond. For this example, the result is simplified by showing the final result. In practice several iterations would typically be used to achieve the final, stable result.
The final result, as illustrated in
This simple example illustrated the basic principle of the transactive control technique. The technique can be applied at any point in the power system and can coordinate monetized energy impacts and the behaviors of responsive loads where such devices and opportunities exist. Consider, for example, a battery storage system at a distribution substation. The associated transactive control node would be making decisions about whether to charge, discharge, or do nothing with the battery system based on the incoming TISs, the incoming TFSs, local conditions such as the state of the battery system, and updating the TIS and TFS it sends to neighboring transactive control nodes accordingly. Transactive control nodes can be deployed throughout the power system from generation resources, through the transmission system, and in the distribution system down to end uses. The technique can be applied within end use points including residential, commercial and industrial uses to manage the behavior of responsive systems and devices.
The example above showed the use of the transactive control technique at end-use points within a distribution system. In this section, a further example of the transactive control and coordination system is considered. This example further illustrates the use of the technique to use local responsive assets to help facilitate the integration of intermittent renewable energy resources.
In order to facilitate discussion of this example, first consider the formalization of the transactive control technique. This allows the use of standard way of referring to the functional elements of an implemented transactive control and coordination system.
For embodiments of the disclosed technology, consider a formal model of the functionality of transactive control nodes. A transactive control node object state model has been defined and is the basis for implementing a transactive node object model (TNOM). This approach is scalable, algorithmic and supports explicit consideration of interoperability through the formal specification of both the syntax and semantics of the transactive incentive signal and transactive feedback signal. The “responsibilities” of a transactive control node summarized earlier are formally represented in the object model.
For embodiments of the disclosed technology, a standardized approach to implementation is made possible through the design and implementation of a “toolkit.” The toolkit includes well-defined interfaces to utility responsive asset systems and simple, common algorithms for updating transactive signals and determining “control” signals to responsive asset systems.
In designing the toolkit, functions for resources and loads can be defined. The resource functions are primarily defined for the bulk power system and represent systems that supply power. At the utility level, functions associated with local resources or utility concerns such as avoiding demand charges are defined. Load functions can be defined that are associated with the different classes of loads or with local resources such as battery storage systems that may have load or resource behaviors (which are treated as negative loads.)
In embodiments of the disclosed technology, the resource functions include functions from a wide variety of categories. For example, in certain embodiments, the resource functions include one or more of:
In embodiments of the disclosed technology, the load functions include one or more functions from the following categories: (1) inelastic, (2) elastic with limited numbers of discrete events available, (3) elastic with daily events available, or (4) elastic with a continuum or near continuum of responses available. There can then exist a matrix of these four categories, with specific loads that fit into one or more of these categories. For example purposes only, the following is a list of example load functions that should not be construed as limiting in any manner. For instance, load functions can be created for a wide variety of assets or asset systems that that can be used in embodiments of the disclosed technology (e.g., for a residence, there may be functions for a variety of different assets and/or asset systems, such as responsive water heaters, thermostats, clothes dryers, web portals, in-home displays, or other such assets and asset systems).
It should be understood that in embodiments of the disclosed technology, a transactive node may host multiple toolkit functions, including any combination of multiple resource and incentive functions, multiple load functions, or combinations of both resource and incentive and load functions. For instance, the resource and/or incentive functions used at a transactive node will typically depend on the location of the transactive node in a power grid topology, and on the one or more resources and/or loads for which the transactive node is responsible. This ability to “mix and match” resource and incentive functions while still maintaining a common transactive signal communication structure gives embodiments of the disclosed technology wide flexibility and scalability for implementing a transactive control system.
For this example, consider the following general conditions and objectives: (a) the predicted transactive incentive signal increases when wind energy decreases and visa versa; (b) the transactive incentive signal is communicated and mixed between transactive nodes; and/or (c) assets respond to improve consumption of wind when wind energy is available or near where wind is available.
For purposes of this example, also consider the simple topology 500 illustrated in
Consider now the toolkit load functions associated with the resources shown in the left hand side of illustration 600 in
For conventional generation, toolkit resource function #2 shown in
The other example of wind power, toolkit resource function #1, is more complicated. In this case, assume a cost of power that is inversely proportional to the power output of the system. Thus, when there is low wind and low production the cost per unit of power is high. On the other hand, when there is high wind and corresponding high power output the cost is low. It should be noted that there are many possible ways to construct the resource functions. The underlying question is how to assign cost—to monetize the activity of the resource asset. In embodiments of the disclosed technology, one should assign cost in a way that incentivizes desired outcomes. In this example, the resource function defined for the wind resource has lowest cost when there is an abundance of wind power thus incentivizing consumption of wind power when it is available. Another consideration when evaluating potential resource functions is that candidate resource functions for a given asset should ensure the same total cost over relatively long periods of time.
Having defined resource functions allows one to look at their behavior over time.
With this forecast of power production in mind, consider the forecast of cost of power from these two resources both with current approaches and with the transactive control approach using embodiments of the resources functions disclosed herein.
In this example, short-term power trading on spot or even day-ahead markets is ignored. In this case, the cost of power will be an aggregated value based on the fixed rate associated with each of the two resources. From the point of view of today's consumer, the cost of power is at a fixed rate—thus there is no incentive to change consumption behavior associated with the cost of power.
Embodiments of the disclosed technology provide a scheme that incentivizes the desired behavior—preferentially to consume wind power. But what about the long-term cost objective? Let us compare how costs accumulate over time.
Integrating the hourly costs allows one to check the long-term criteria—that costs should be the same over the long term for transactive versus the non-transactive approaches.
Now that the formulation of toolkit resource functions have been considered, example differences between conventional approaches and embodiments of the transactive approach can be summarized. For instance, the resource functions for generation assets of the disclosed technology create a transactive incentive signal as depicted in graph 1100 of
Attention can be shifted to the consumption, or load, side of the computation. From a behavioral or responsiveness point of view, loads will be mixed. Some will be controllable; in other words, the loads will have the potential to respond to an incentive signal. Still further, in some instances, some loads will also be capable of acting as a load or a generation resource. For example, a battery system may have either behavior, and decisions about the battery may be made about when to charge, discharge, and/or at what rates. In this respect, a battery load may be highly responsive. For any given class of load assets, one may construct one or more load toolkit functions. These functions desirably take into account the load functions for other distribution system assets, and are discussed in more detail below.
Embodiments of the disclosed technology implement a distributed system for engaging responsive assets within the power system to manage constraints and support the integration of elastic energy resource (e.g., wind power and/or other intermittent renewable energy resources).
In particular implementations, the technique primarily uses two signals—the transactive incentive signal and the transactive feedback signal—representing the cost of power delivered to a given point in the system and the load at a given point in the system respectively. In particular embodiments, both signals are forward forecasts. The use of these representations reduces communications capacity requirements but relies on the development of algorithms for monetizing operational objectives. This was illustrated through a simple electric vehicle charging example and an extended example for wind power integration.
The transactive control and coordination system (TCS) of the disclosed technology can be implemented primarily using two classes of transactive signals: transactive incentive signals (TIS) and transactive feedback signals (TFS). These signals are exchanged between distributed system sites. The purpose of these signals is to coordinate supply and load in the near future, from a few minutes to several days out.
Some might compare the TCS with locational marginal pricing (LMP), in which energy prices are differentiated by time and by circuit location to address the economics of resource availability and to help mitigate transmission system congestion. A TCS shares certain goals with LMP. Like an LMP price signal, a TIS is a price-like signal that may represent the value of energy resources while taking into account the location, the time, transmission congestion, and transmission losses. Unlike an LMP signal, however, a transactive signal has been generalized to represent other additional impacts that can be monetized. Furthermore, a TCS facilitates fully distributed, not centralized, formulations of transactive signals. Because the calculations may be fully distributed, a TCS system is scalable throughout transmission systems, distribution systems, customer premises, and/or device levels.
An LMP represents the cost of the marginal energy resource and is therefore useful for coordinating the dispatch of energy resources. An implication is that dispatch decisions for supply-side or demand-side resources are based solely on comparison against the current marginal resource. By contrast, embodiments of the TIS are preferably formulated to represent energy cost as a function of time and location so that it may coordinate multiple supply-side and demand-side resources, not just the marginal ones. (This distinction is increasingly of interest as must-run renewable resources become a significant fraction of system resources. Economic dispatch and marginal energy price are currently based largely on fuel expenses. Renewable resources, which consume no fuel, displace fueled resources. Therefore, the marginal price, which is determined by the marginal fueled resource, incurs downward pressure. If the resulting marginal price is used to calculate revenues, then revenues also experience downward pressure, even though the must-run renewable resources may have generated relatively expensive energy.) The economic usefulness of many resources is determined during planning stages, not as they operate. Once the resource has been built, it should be called upon anytime it is useful, not only when it competes well with the current marginal resource.
A TCS and its transactive signals, in principle, may thereby unify some decision processes that are conventionally addressed separately or sequentially—the using the dispatch of must-run resources and economic dispatch, for example, or the testing of economic power flow against permissible constrained power flow.
While quantity of energy is most certainly used during the calculations of LMP signals, there is seldom a need for those signals to be communicated outside the location of the central solver. In embodiments of the disclosed technology, however, the TFS, which represents a quantity of power, accompanies the price-like TIS. For example, distributed formulations can be used with signals that represent both the paired price and the quantity of power for time intervals. In particular, transactive signals can enable the coordination of the TCS, where each transactive node has a responsibility to perform its share of what is presently a very centralized calculation. The standardization of a TCS and its transactive signals can permit new implementers to join a TCS.
Now that some general characteristics of a TCS have been introduced, largely through a comparison between TCS and LMP systems (see, e.g., Table 1), further details and qualities of the TCS will be introduced. For example, the sections below describe the component parts of a TCS, including its transactive signals, and how each of the two subclasses of transactive signal are influenced and formulated.
An exemplary embodiment of the TCS may be understood by its components and their behaviors. In particular implementations, its principal components comprise one or more of the following:
In embodiments of the disclosed technology, transactive nodes are points in the topology of a TCS. In particular embodiments, transactive nodes periodically exchange transactive signals with their neighbors (e.g., their nearest neighbors) with which they can exchange electrical energy. For instance, transactive signals are exchanged between neighboring transactive nodes that share an electrical conductor. (This is true in the sense that two transactive nodes that exchange power also communicate. The actual pathway and communication media between transactive nodes can vary from implementation to implementation.) The resulting interconnection topology can, in some embodiments, be hierarchical. Transactive nodes can be established at any hierarchical point in the topology (e.g., at any point of the utility-side topology, such as a sub-station, feeder, transformer, or the loke) or at any point of the load-side topology, a feeder, transformer, household control unit, electric vehicle charger, or any control unit at the household or other load control unit).
Transactive signals can be represented as a series of data. For instance, in particular implementations, the transactive signals are a series of triplets. Each triplet is comprised of a time interval, a value, and a confidence level that qualifies the value. In other implementations, the transactive signals comprise a series of value pairs, where each value pair comprises any combination of a time interval, a value, or a confidence level. In still other implementations, the transactive signals comprise one or more of a time interval, a value, and/or a confidence level. In particular implementations, there are two subclasses of transactive signals:
In particular embodiments, the transactive signals are forecasts. The forecasts refer to an imminent time interval (e.g., the time interval that will start next) and a number of additional future intervals thereafter. The future intervals are defined by their starting times and durations. Once stated, an interval remains fixed in time, and a future interval moves closer with the passing of time. The intervals in a transactive signal are successive in one particular embodiment of the disclosed technology (e.g., they do not overlap).
A subsequent transactive signal updates the values and confidence levels for many or all of the previous transactive signal's time intervals. New intervals may also be created to push the forecast even farther into the future.
In one particular embodiment of the disclosed technology, termed “the demonstration”, 56 successive intervals ranging in duration from 5 minutes to 1 day were elected. Refer, for instance, to Table 2. It should be understood, however, that any number of intervals of any duration can be used to implement embodiments of the disclosed technology. In Table 2, the term “ISTn” refers to the time at which the nth interval begins—the interval start time. The durations of the thirteenth, thirty-third, fifty-first, and fifty-fifth interval may change from one transactive signal to the next; this was done in the illustrated embodiment to make sure that the intervals remain aligned with major 15-minute, 1-hour, 6-hour, and 1-day transitions.
The shortest interval could be any duration. For instance, the duration might be limited by the sum of the system's calculation and communication latencies. If the system were to use relatively short intervals (e.g., five minutes or less), it could respond to many dynamic issues, even area control errors, which are typically managed on 4-second intervals.
In one embodiment, intervals were defined with increasingly longer durations into the future because more distant future values may only be meaningfully and accurately forecasted in a statistical, averaged sense. For example, if one knows the accurate status of a thermostat and the building temperature that the thermostat manages, one may accurately predict quite precisely when this system will begin or end its current heating or cooling cycle. For tomorrow, however, one cannot predict precisely when each cycle will begin and end, but one can quite accurately predict the fraction of time that the system will be actively cooling or heating. (In other embodiments, longer intervals (such as over 1 hour) are avoided. It has been observed, for example, that intervals longer than 1 hour tend to destroy important boundaries that have been defined at the boundaries between hours. For example, some utility billing practices presently distinguish “heavy load hours” that occur from 6:00 a.m. to 10:00 p.m. Pacific.)
The 56 intervals used in the example embodiment discussed herein extend more than 3 days into the future, but could extend to any desired time period. The total number of intervals and durations of the longest intervals in the example embodiment were influenced by the desire to allow the system to be unattended for at least three days—the duration of a long holiday weekend.
In Table 2, the 57th IST was used to define the end of the 56th interval, which is the final interval in a transactive signal of the example embodiment.
Published future intervals remain valid and may be used, in principle, until they are overcome by time. This means that a transactive signal's Friday forecast for a Monday morning interval can be used even if the system fails to calculate any new transactive signals through the weekend. In this capability, the system is resilient to temporary failures of individual system components. If, however, a part of the system fails, the signals that had been predicted much earlier become increasingly dated and inaccurate. The system also loses its ability to recognize and respond to change while new signals are absent. Also, because later intervals have longer duration, signal dynamics diminish as the system relies on progressively longer prior predictions. In one embodiment, the confidence attribute is degraded (e.g., indicates diminished confidence) over time as signals become stale, unupdated.
Although any suitable time standard can be used, embodiments of the disclosed technology use the Coordinated Universal Time (UTC) standard (ISO/IEC 2004). The UTC can be used, for example, to enforce a consistent and standardized representation of time across time zones. UTC times are unchanged across time zones and across transitions into and out of daylight savings periods. In certain embodiments, and in order to avoid problems with aligning time zones ad contractual obligations that may exist, the use of intervals longer than one hour is avoided.
In some embodiments, transactive signals also include a confidence attribute that is specified to qualify the values in the transactive signals. In particular implementations, the confidence attribute estimates the relative positive root-mean-square (RMS) accuracy of each value that is published in a transactive signal. In many cases, this interpretation is quite naturally incorporated. For example, forecasts for renewable energy resources are already qualified in a way comparable to an RMS error.
Some events or conditions are not as naturally represented using the metric relative RMS error. For example, one might have diminished confidence if a signal has been delayed or if some component information to be used in a calculation has become stale. Other examples might include startup conditions while only limited information has been received, suspect status of computational equipment that hosts a calculation, or calculated values that are simply outside a normally accepted range for unknown reasons. Nevertheless, these conditions can be functionally represented by relative RMS error.
The recipient of a value that is accompanied by a high relative RMS error may use such information in many ways. The local practices and policies may differ at each transactive node. The possible responses include, for example, the publication of error or warning flags, performing alternative calculations that are more conservative, resorting to safe default values, using statistical algorithms that optimize outcomes or minimize risk, or no action at all.
In particular embodiments, a transactive node has one TIS for any given time interval and any given calculation result. No differentiation of TIS value is allowed across a transactive node. If for any reason electrical energy should be valued differently across a transactive node, the transactive node should be divided into more than one node at the feature that causes different valuation.
In one particular implementation, the TIS is calculated by summing the incurred costs and dividing the sum by the energy to which the costs refer. The total energy may be thought of as either entire load (including exported energy), or as the entire supply (including imported energy), at the transactive node. The transactive node can assume that total supply is equal to total load. It has been found that it is more natural to work from the supply side during the formulation of TIS. It is the costs of the various mixes of supply resources that directly affect the TIS.
The input parameters of the TIS formula in Table 3 create a useful interoperability boundary. The parameters represent various costs (“C”) and power (“P”), where the subscripts refer to terms for energy (“E”), generation (“G”), capacity (“C”), infrastructure (“I”), or other (“O”). Further, subscript n is the interval number and Δtn is that interval's duration. Members of a TCS may be invited to generate their own functional algorithms that in turn influence the TIS by simply designing algorithms that assign values to these various parameters. The parameters are distinguished by their units. Implementers may select and use the parameters that most naturally represent the forecasted cost impacts. It should be understood that these parameters are not limiting or even required for a particular component. In certain embodiments of the disclosed technology, the functions that generate these parameters are called toolkit resource and incentive functions. Resource functions model energy supply resources. Incentive functions affect the TIS, but they do not represent any energy resource. Example resource and incentive functions are described in more detail below, including Appendices B and C.
In other embodiments, infrastructure costs are among the numerator terms. However, in such embodiments, an undesirable inverse relationship between TIS and total power demand may result. In Table 3, infrastructure costs can be included among the “offset costs”.
The TFS is calculated readily for a radial distribution circuit branch. The transactive node on a radial distribution branch simply sums its predicted inelastic and elastic loads. The upstream transactive node is the only resource available to supply the load at this system location, so the TFS is identical to the predicted load for the branch.
The TFS is not as easily predicted between transactive nodes that are not on a radial distribution branch and have more than one transactive neighbor. Their network system connections may be meshed. Desirably, power flow is allocated among multiple TFS in a way that would be fully consistent with a proper power flow calculation.
In a fully deployed TCS, economic dispatch decisions would be made at each transactive node to balance load. To the degree that energy can be imported from the transactive node's neighbors, the neighbors' energy competes with local resources. Any mismatch is desirably allocated among the TFSs.
In certain embodiments, each member of a pair of transactive neighbors estimates a TFS for the interface that they share. (The general case of meshed networks and bidirectional power flow desirably uses each transactive neighbor to publish and receive paired cost (TIS) and quantity (TFS) signals.) The convergence of the two estimates is a metric that can be used to determine whether the two neighbors have concluded their negotiated solution or not.
In certain embodiments, the formal model of the transactive node class and its behavior has been specified by the transactive node object model.
An example model of the algorithmic responsibilities of a transactive node is introduced below in Appendix B. The details of this model can be used to implement exemplary transactive nodes (e.g., using Standard ISO/IEC 18012 (ISO/IEC 2004) or using a unified object-oriented modeling language such as UML-2 (OMG 2013)). The algorithmic framework has proven to be applicable across many different types of transactive nodes.
A particular implementation of the function “3. Formulate TIS” is disclosed in Appendix B. This function receives information about intervals, costs of various resources and incentives, and the sum of imported and generated energy to which the cost information is relevant.
The model states that both the input information and resulting TIS values are stored in a data buffer. These buffer contents may be mined for data by those who have permission to do so. But the greater importance of the buffered data is that such stored information makes the system resilient to imperfect communications: the input values from a prior series of forecast intervals remain this transactive node's best prediction of the input interval values until updated information can be received. This is especially useful when the information is delayed or when a communication link becomes temporarily severed.
The impacts of energy supply and incentives (or disincentives) at a given transactive node are received through toolkit resource and incentive functions, a modular library of functions that model the costs and energy supplied by energy resources and other cost incentives or disincentives at a given transactive node. An example implementation of the function “8. Calculate Applicable Toolkit Resources and Incentives” (near the top center of
A particular implementation of the function “4. Formulate TFS” (at the bottom right of
In certain embodiments, the load forecast has two threads. The first forecasts the inelastic load. This is the base case that is unaffected by the TIS. The second thread is the elastic load—the change in load that may be attributed to the TIS and events that are generated in light of the TIS. The separation of these threads is practical and it helps measure and verify system responses. The sum of the inelastic and elastic load forecast components accurately forecasts the actual load.
The model of a single asset system may forecast both inelastic and elastic load components. For example, the thermostatic building asset model forecasts both its normal building load and the changes in load caused by temperature setback events. In certain embodiments of the disclosed technology, a single feeder model forecasted bulk inelastic load that in effect included many inelastic components of responsive assets. Provided that the components are properly summed for the given transactive node and not double-counted, it will not matter that the thermostat model did not model its own inelastic load component.
More information about the toolkit resource and incentive and toolkit load functions are discussed below as well as in Appendices B and C.
In certain embodiments, the transactive node object model includes functionality and attributes that control the times at which transactive signals are transmitted to transactive neighbors. An exemplary timing model is discussed in this section, but is not to be construed as limiting, as any number of intervals having other durations can be used. The example timing model was designed to allow propagation of information about disturbances (e.g., of the electric transmission grid) across the TCS system while reducing unfruitful chatter and calculations. As noted, the example timing model is not necessarily one that should be standardized or used in implementations of the systems.
A transactive node should normally not publish transactive signals for which any interval starting time has already passed. This expectation creates a useful framework for the calibration of system clocks. The error between clocks at different system locations should desirably be small compared to the shortest intervals-5 minutes for the example timing model. Tight tolerances are, in principle, achievable for transactive nodes that are internet connected.
In the example timing model, each transactive node, at the beginning of a 5-minute interval, publishes transactive signals that address the interval that begins 5 minutes from now and into the future.
Various timers were implemented to avoid unnecessary chatter. One timer begins when a transactive signal is received. Another timer begins after a transactive signal is transmitted. No transactive signal of the same type may be transmitted again until after these timers expire.
In one embodiment, the time model is event-based. For example, the timing model can be adapted to become more responsive to status or condition events and less reliant upon clock-based events (e.g., hold-down timers, interval timers). New signals and additional calculations can be generated only after significant changes occur to schedules and forecasts, either locally or at remote system locations. As long as forecasts remain accurate, the system should be unperturbed.
Further, sets of prediction intervals that are nested rather than sequential can be used. That is, an understanding that the next 5 minutes are a subset of an hour-long interval that is a subset of the day that is a subset of a month, and so on, can be adopted.
Still further, in some instances, a relaxation criterion against which forecast changes may be compared can be used. The criterion can state a weighting of errors for each interval. For example, if the sum of the errors exceeds the overall threshold for a transactive signal, then the signal is updated and republished; otherwise, no signals should be transmitted because the changes are deemed to be insignificant. This criterion can be used in an event-based model wherein imminent and future intervals are rapidly iterated (e.g., on an asynchronous basis) until they resolve according to this criterion.
In some embodiments, a transactive data collection system layer is also defined and used in implementations of the transactive nodes. For example, this system layer automatically retrieves toolkit function outputs from resource, incentive, and toolkit load functions; gathers resulting TIS and TFS signals that are generated at each node from its toolkit function inputs; and records various system management events and statuses. Because the system is distributed both in time and space, it is desirable to keep track of data provenance, including locations of nodes from which the data originates, times at which signals are generated, and time intervals to which predictive signals refer.
One advantage of a TCS is that the transactive signals, while revealing an aggregated cost and quantity of energy, do not necessarily reveal any sensitive or private data. The model used to store and collect information about local resources and loads at a transactive node can be useful, but such information would normally be shared only with the owner of a set of transactive nodes, who is entitled to receive such privileged information. Desirably, little or no sensitive information is shared by neighboring transactive nodes.
“Non-transactive” data can also be defined and collected. Non-transactive data is factual data that is collected from system meters and which can be used during analysis to assess the success with which the predictive TCS has influenced system loads and its consumption of various energy resources. Non-transactive data can also include weather data at each distributed site.
This section addresses the formulation and interpretation of the TIS.
In some embodiments, while each TIS states a value for each future interval, each said value may be composed of a plurality of various resource and incentive cost components. This concept is demonstrated by diagram 1400 in
Observe that influences are inherited from neighboring transactive nodes that supply this transactive node. For example, if 8% of a TIS value is from the costs of fossil energy resources, and if this transactive node is supplied another 10% of its resources by a neighbor for which 10% of this neighbor's TIS value is from fossil resources, then the total impact of fossil energy on the TIS at this transactive node would be 8%+10%×10%=9%. Therefore, one can look to propagated resource mixes one, two, or even more neighbors distant to accurately assess the resource supply mix at this transactive node.
As discussed, in certain embodiments, delivered cost of energy is used as the metric for TIS magnitude. This metric is useful because (1) it provides a straight path to using the signal for revenue, if other implementations choose to do so, and (2) comparable calibration standards exist at some locations within a TCS for this metric.
In a distributed system, checks and balances are desirable to make sure that the TIS, which is collaboratively formulated, is meaningful and fair. The first step toward accomplishing this was to establish a common semantic understanding of the TIS as, for one embodiment, the delivered cost of energy at a location. The second step is the comparison of the TIS and its components against comparable calibration standards. For example, existing and historical contracts define the average unit cost of energy among many suppliers and recipients of electrical energy. Distribution utilities can accurately state how much they paid for a unit of energy during the past year. Therefore, the TIS and any other valid representation of the delivered cost of energy at a system location should be comparable over long periods of time.
Adequate energy resources are desirably received into or dispatched at a transactive node to balance system load. The mix of dispatched energy resources can be determined in a distributed manner (though it is also possible to use a central determination for smaller scale implementations).
In certain embodiments, resource toolkit functions from a library of functions are the functions that calculate the quantity of energy and its cost impacts toward the formulation of the TIS at a transactive node. The resource toolkit functions can reside at any of the transactive nodes (e.g., transmission zone nodes, which each represent large regions of a region's generation and transmission systems). One or more of the following functions can be used to represent groups of (or individual) energy resources:
Incentive functions are similar to resource functions, but they are not tied to energy supply. One or more of the following exemplary incentive functions can be used in implementations of the disclosed technology:
A TFS represents the power flowing between a transactive node and its transactive neighbor during the imminent and future intervals. The majority of the power flow is usually inelastic: it is unaffected by the predicted unit cost of the energy—the TIS. If the transactive node hosts responsive asset systems, these systems might observe the TIS and change their forecast of how much energy they will consume during a future interval—they are elastic. The transactive node state model keeps track of the changes in load that are anticipated from these elastic asset systems.
Responsive asset systems that curtail load reduce load at a transactive node and therefore tend to reduce the energy that is generated at or imported into the transactive node.
Demand-side generators have the same impact when they generate energy and displace load at the transactive node.
Even more useful are responsive asset systems that can increase their energy consumption (or equivalently, reduce their demand-side generation). These asset systems thereby increase system load at their transactive nodes and increase the energy that is either generated at or imported into the transactive node. This response is increasingly useful in power grids that experience excessive generation, as now occurs in regions that have high wind-power penetration.
A straightforward comparison standard exists for TFS values at many system locations. Because the TFS represents forecasted power flow, the accuracy of the forecasted power-flow values in a TFS may be compared against actual metered power at that point in the power grid. For example, the electricity supplied to a distribution by its electricity supplier is accurately metered.
Inelastic load functions forecast baseline load that is unaffected by the TIS. Inelastic load functions can be defined for each residential, commercial, and industrial load type. The load from these models can be scaled by the numbers of each customer type. Alternatively, a parametric model can be used that can be trained by historical data. The model appears to perform similarly for all of the different load types. The forecast model creates a correlation to forecasted weather information—including at least ambient temperature. If available, the model can also incorporate recent measurement data to improve the forecast.
Elastic toolkit load functions in conjunction with asset models model how responsive asset systems are influenced by the TIS. In certain embodiments, these functions have two principal responsibilities: First, the toolkit load function predicts when events may occur and how long they will last. Second, an asset model forecasts the change in load that will occur during an event for the given asset system.
Elastic toolkit load functions can be categorized as follows based on the nature of their forecasted events:
An asset model then models the change in load during the above event types. It has been found that many possible pairings exist between event types and asset model types. For example, a water heater asset model may be used with either event-driven or daily event types. In principle, water heaters could be manufactured to have continuous responses.
By way of example, one or more of the following exemplary asset models can be applied in an implementation of the disclosed technology:
Table 5 summarizes the potential pairings of the listed exemplary asset models with appropriate event types. Examples for some of these pairings are described in the appendices below. Implementations for other pairings can be developed by those skilled in the art in view of this disclosure.
In a fully deployed TCS, regional transmission and generation owners formulate TIS signals by stating the temporal and locational value of resources at many transmission and generation sites in the region, and the TFS, a feedback signal, influences their resource dispatch decisions at these distributed locations.
Further, as household devices become more intelligent, there will eventually exist vast populations of flexible, responsive assets that would be active in a TCS. These assets will be available to modify their consumption at each update interval. A TCS invites the demand side to participate in the system objectives on equal footing with supply.
Implementations of the disclosed technology can be standardized, if desired. Standardization efforts may be at a variety of different levels. For instance, the TCS can be defined at the organization and informational level. In this regard,
Certain implementers can choose to define additional implementation details beyond those in the standard. The implementations might, for example, further specify the syntactical levels of interoperability. These implementations should abide by and make reference to the main standard. However, the new implementations may themselves become standards, or they may be recognized as reference implementations of TCS.
Further, implementers may desire to keep their particular code (e.g., code for a toolkit function) confidential. Such a scenario is feasible so long as the resulting signals are conformant.
Embodiments of the disclosed technology can be integrated with academic distributed control approaches. For instance, the specification of transactive signals can be harmonized with signal characteristics specified in simulation studies. An outcome of such harmonization will be that the transactive signal that represents power flow will be a complex representation. (This use of complex here is mathematical. A complex number has real and imaginary components. The real component represents real power; the imaginary component represents the flow of reactive electrical power.)
Embodiments of the disclosed technology can be harmonized with LMP approaches. For instance, the practices of LMP and TCS can be harmonized, potentially allowing the TCS approach to compete with, supplement, or gain equal footing with LMP practices.
Embodiments of the disclosed technology can also be harmonized with other TCS approaches. For example, the price-like signal used in embodiments of the TCS approach may be modeled after cost, price, or competitive bids.
In this section, additional details concerning the overall design for embodiments of a transactive control and coordination system according to the disclosed technology will be introduced. The discussion below also provides a supplemental discussion of the transactive control signals themselves. This discussion may, in some instances, be repetitive to the discussion above but is included herein for the sake of completeness.
The architecture of an installed system is more diverse than for typical computer network designs. For instance, an installed system comprises generation, responsive assets, the electricity transmission and distribution systems, and digital communication and intelligence. The system therefore should consider:
These components are interdependent, and a close correlation will typically exist and be maintained between them.
The physical, geographical system architecture captures the physical locations of each piece of the installed system. Physical location can be influential to transactive control because local attributes (e.g., weather) affect the behaviors of equipment, end users, and responsive assets. One tenet of transactive control is that the value of supplied electrical energy is location-dependent. Physical, geographical architecture is easily captured on a conventional map.
The electrical connectivity system architecture captures the flow of electrical energy through the installed system. One tenet of transactive control is that the communication of value and operational opportunities (e.g., the transactive signals) in a transactive control and coordination system should logically follow the pathways of electrical energy flow. Existing and future power capacity constraints are highly path-dependent.
In certain embodiments, the electrical connectivity within an installed transactive control and coordination system forms a hierarchy of nodes. Here, the word hierarchy refers to a flow direction of electrical power and is not necessarily a static assignment. Electrical transmission systems are typically mesh (not radial) systems, meaning that parallel paths in the transmission system compete to supply load. The direction of electrical power in the transmission system may change. Some of this complexity will not be discussed in detail herein because embodiments of the disclosed technology can be adapted for such complexities using software tools that properly model meshed transmission power flow.
The information flow design captures the flow of data and information within an installed system. An information flow architecture also indicates where manual and automated decisions are made. The information flow architecture can include, for example,
The information flow architecture can also capture details about the communication channels and signals, including communication media, protocols, bandwidth, formats, software tools, exemplary functional computations, and security attributes and practices.
This section introduces embodiments of hierarchical transactive control that can be used in an installed system. Prior to recent efforts to build a smarter grid, most all opportunities to manage and control electrical power have been managed quite centrally from the supply side—bulk electrical generation and transmission. The role of the power grid has been simply to satisfy electrical demand—the energy consumption patterns of all the end users. Embodiments of the smart grid according to the disclosed technology will engage end users and responsive assets throughout the grid, resulting in a cooperative, more distributed approach. Transactive control can facilitate this migration to a smarter grid.
Transactive control is a bidirectionally negotiated system behavior. Market-like principles facilitate the negotiation; however, the signals need not be used to account for any monetary or revenue exchanges. In theory, the “winning” behaviors are optimal in some sense, having competed successfully in a “market” against alternative actions that could have been taken.
One or more of the following are characteristics that can be exhibited in embodiments of a transactive control and coordination system according to the disclosed technology:
The transactive control technique of this disclosure can be compared to other approaches to transactive control, specifically the GridWise® Olympic Peninsula Project. Table 6 summarizes the major differences between the transactive control approach used during the Olympic Peninsula Project and embodiments of the disclosed transactive control approach.
Exemplary components of embodiments of the transactive control and coordination system include one or more of:
Responsive and enabling assets are more thoroughly discussed below.
This section describes example transactive signals and their use by the demonstration.
In certain embodiments of the disclosed technology, there are two transactive signals at each transactive node:
Each of the two signals is a time series, meaning that each is a vector of numbers, one for the present time interval and others for each future time interval (e.g., at least a day into the future). The time interval and horizon into the future can vary from embodiment to embodiment. In some embodiments, the time interval is five minutes. Shorter intervals than this would permit the demonstration system to provide additional ancillary services. Further, in some embodiments, shorter intervals are used for the near term and longer intervals into the signals' future. The signals' time horizon desirably extends at least to the future time when resource dispatch decisions are being made for the region.
The transactive signals at time t0 can have the forms:
TIS={TIS(t0),TIS(t0+Δt),TIS(t0+2Δt),TIS(t0+3Δt), . . . ,TIS(tf−Δt)}
TFS={TFS(t0),TFS(t0+Δt),TFS(t0+2Δt),TFS(t0+3Δt), . . . ,TFS(tf−Δt)},
where TIS and TFS are the transactive incentive and feedback signals, respectively, Δt is the selected time interval, and tf is the end of the prediction time horizon. The given time signal series can be updated next at time t0+Δt.
The time-series elements of these two transactive signals are paired for each future time interval. This pairing between transactive incentive signal and transactive feedback signal is illustrated in block diagram 1600 of
During the application of transactive signals, sensibility checks and default behaviors are desirably planned. For example, the nodes can be provided some independence to recognize and discount nonsensical signals that are believed to be erroneous. When no signals are received by transactive nodes, as may be the case when there has been a problem or equipment failure somewhere in the system, the nodes should again have the independence to revert to safe, bounded behaviors.
In particular embodiments of the disclosed technology, the transactive incentive time series is the main transactive signal. Each transactive node will typically have a unique blend of energy suppliers, upstream transmission pathways and distances, operational practices, local infrastructure, and/or downstream customers. Therefore, the values of the transactive incentive signal can be unique at a transactive node in the system.
In certain implementations, the basis for the transactive signal series at any node is a weighted sum of the transactive incentive signals received by that transactive node from immediately upstream transactive nodes that supply it electrical energy. The default approach, for example, can be to weigh the transactive signals according to the relative fraction of the node's power that is supplied from each upstream source as described below.
Each transactive node can also modify the transactive incentive signal that it relays downstream. At each transactive node, local conditions are analyzed and the incentive signal modified (or left unchanged) based on the local conditions. Modification of the incentive signal is for the purpose of influencing the behavior of responsive assets downstream from the node. The basic action at any node can be simply represented as:
TISoutput(t)=Weighted average(TISinput(t))+New incentives(t)
TISoutput(t)=Weighted average(TISinput(t))+New incentives(t).
Examples of how and why a transactive node will modify its transactive incentive signal include:
The formulation of the transactive incentive signal can, but need not directly, incorporate actual allocations and financial metrics used by utilities and other business entities; the transactive incentive signal can instead be formulated to allocate expenses in a way that will induce useful responses for the entity that owns a transactive node. However, a faithful transactive incentive signal formulation should approach the same overall value as for actual expense reporting over long periods of time. There is nothing that would prevent the transactive control and coordination system from supporting markets and revenue accounting in other formulations.
The incentive signal can have a variety of forms or units, but in some embodiments uses units of $/MWhr (or other equivalent, such as a number or value that is proportional (linearly or otherwise) to this unit). Thus, the signal need not be an actual price, but can be representative of a price or economic unit. One tenet of embodiments of the disclosed transactive control scheme is that items that are valued at a location in the system should be combined into one shared signal, and that can be achieved only after there is consensus about a common metric unit to be used by the signal. This principle will help enforce that business entities' operational objectives should fairly compete.
Corresponding to a transactive incentive signal time interval is a transactive load feedback signal (e.g., in the kW or other equivalent or representative unit). This transactive feedback signal time series includes the present and future electrical load that is predicted to be supplied through the transactive node during each time interval. In some embodiments, the signal is the sum of the unresponsive electric load that is not affected by the transactive signal and the responsive electric load that can monitor and respond to the transactive incentive signal.
TFSoutput(t)=ΣTFSunresponsive,input(t)+ΣTFSresponsive,input(t,TISoutput(t))
The transactive feedback signal is not a “load forecast” of the type that some utilities prepare as they plan resource commitments. There are no direct penalties to be incurred by subprojects when their transactive feedback signals prove inaccurate. The transactive control approach might diminish the importance of load forecasts in the future if the flexibility provided by transactive control can be shown to displace some of the need for predictive accuracy. Interestingly, the accuracy of a node's transactive feedback signal prediction may always be tested against the true consumption that is measured eventually at the transactive node. In some embodiments, the intelligence at a transactive node can “learn” over time to improve its own predictions. Neighboring transactive nodes learn also from an adjacent transactive node's inaccuracies and may choose to alter or suspect that transactive node's outputs.
In some embodiments, the inputs to the transactive feedback signal at a transactive node include any one or more of the following types of inputs:
As has been stated, the transactive incentive signal is not intended to account for monetary exchanges or revenue between regional entities. However, the transactive incentive signal could become the foundation for regional exchanges or revenues. The transactive incentive signal may also be used as a basis for customer incentives if the subprojects can establish workable shadow accounts for these customers.
Any of the physical locations in the electrical connectivity architecture of a power system can be transactive nodes. A node is a location or piece of equipment that electrical power flows through. The term “hierarchy” is used to describe a set of transactive nodes that may extend all the way upstream to bulk generators and all the way downstream to electrical loads.
In certain embodiments, a location or piece of equipment in the electrical connectivity architecture is described as a transactive node if it performs one or both of the following:
A transactive node can also: modify the output transactive incentive signal to address any local operational objective that exists at the transactive node; and/or predict the responsive electric load from any responsive assets that are being controlled from the location of the transactive node.
These responsibilities of a transactive node are summarized by block diagram 1700 of
Any one or more of the following functional behaviors can be carried out by transactive nodes:
These general functional behaviors help form the basis for a basic building-block model of a transactive node, whose models may be linked together to model the behaviors of the transactive nodes in a completed nodal hierarchy. Each of these functional behaviors is discussed in more detail below.
This section addresses the most basic functions that a point in the electrical connectivity architecture (hierarchy) performs as part of its role as a transactive node. First, a transactive node desirably is able to receive at least one transactive signal and “blend” the signals into a single transactive signal output to be sent downstream through the hierarchy. For purposes of this discussion, this basic function is termed the incentive blending function and is illustrated in block diagram 1800 in
As a starting point for the design, the default incentive blending function can be assigned as a weighted average of the transactive incentive signals that are received at the transactive node from upstream, where the weighting is performed according to the energy received from each source during the interval. For instance, this weighted average can be formulated as:
It is noteworthy that the relative electrical energy to be received from multiple source inputs to a transactive node during a time interval cannot be directly controlled by the transactive node and may only be predicted imperfectly from the transactive node's limited view of the system. This might not be problematic (or even evident) for transactive nodes that exist within largely radial distribution systems, but may become more evident for transactive nodes within highly redundant transmission pathways and near dispatchable generators. This observation results from the more distributed nature of the disclosed transactive control and coordination system and can be contrasted with systems where transmission system conditions are predicted by load flow calculation methods that assume nearly complete system visibility and use simultaneous solution of the entire system's status.
The load aggregation function is conceptually simple, but complexities potentially arise from the breadth of downstream electrical load types and conditions. In principle, the purpose of the load aggregation function is simply to receive or measure electrical load that is supplied through the transactive node and to convert these measurements and this information into the transactive feedback signal, including a prediction of the entire electrical load to be supplied through the transactive node for each time interval. The transactive node can implement this functionality according to one or more of the following cases:
Case 1.
If there are transactive nodes immediately downstream from the given transactive node, then the transactive feedback signals that are received from them is already in the right format and should simply be added.
Case 2.
The electric load that is not from responsive assets and is not supplied by another downstream node is predicted and converted into the format of the transactive feedback signal. This prediction might rely on an active model of the behaviors of the supplied load or its components. These unresponsive asset behaviors might be influenced by weather, day of week, customer habits, and/or many other conditions, but they are not affected by the transactive incentive signal.
Case 3.
A third case is similar to case 2 above but further includes responsiveness to the transactive node's transactive incentive output signal.
A transactive node that manages an electrically constrained piece of equipment at the transactive node additionally may modify its output transactive incentive signal to manage this constraint. This additional function is shown in diagram 1900 of
In summary, the transactive incentive signal can be made responsive to the constraint, and the downstream responsive assets can be made to reduce or curtail their consumption when the transactive incentive signal becomes high.
In contrast to a transactive approach where price is determined by a two-way clearing of a market, embodiments of the disclosed technology base the magnitude of the transactive incentive signal on actual risks and expenses. The transactive incentive signal is therefore not a marginal price but is instead a transparent accumulation of incurred expenses. This approach responds to the criticism received by marginal pricing that it results in more, not less, expense to customers.
If a constraint is to be addressed, the transactive node can be associated with the constrained piece of equipment. This practice can help in situations where it is desirable to have only one output transactive incentive signal be necessary from the perspective of the transactive node.
In some instances, local situation information can also be received from this function, which may generate useful alerts, for example, for system operators. That is, the prediction of constrained operation at a transactive node is reflected in both the transactive incentive and feedback signals at that node, and useful notifications may be generated if thresholds are exceeded in these signals.
This transactive node function addresses a node associated with a load asset and builds on the structure of a basic node. In diagram 2000 of
Smaller distributed generation can be addressed by using the load transactive node functions. Distributed generators can make their decisions to run or not based on the transactive incentive signal which is provided by the load transactive node functions. When the small generator operates, it effectively reduces downstream electrical load.
The transactive node further uses its version of the transactive incentive signal to functionally control its responsive assets via a toolkit load function selected from a library of such available functions. The output of this function to the responsive assets can depend upon the control method the utility has established for that responsive asset:
These responses are shown conceptually in graph 2100 of
A supply transactive node function is shown in diagram 2200 of
This transactive node function is targeted mostly to bulk generation nodes. At these transactive nodes, the base foundation for transactive incentive signals is established. At a supply node, there may be no upstream nodes from which input transactive incentive signals could be received. The function in the path of the output transactive incentive signal is then the initial formulation of the base transactive incentive signal.
Local situational information can be generated or received by this transactive node. The supply transactive node can apply supply control (or a recommendation) if such supply generation is provided at this transactive node. Local information can also be used to inform what fuel expense and other operational expenses should be included into the initial transactive incentive signal at this location.
The incentive signal and the actual expenses of the supply desirably agree over long periods of time, but the function can (while adhering to this stated guideline) address the value of electrical generation in a way that instills useful responses by the region's responsive assets. For example, when this supply transactive node function is applied at wind farms, the created transactive incentive signal can induce the region's responsive assets to consume more of its energy while and near where the wind energy is produced.
A set of transactive node functions has been introduced. These functions can be generalized as shown in diagram 2300 of
In particular implementations of the transactive system, the output transactive incentive signal becomes an input transactive incentive signal to a transactive node that is immediately downstream; the output transactive feedback signal from a transactive node becomes the input for a transactive node immediately upstream.
Block diagram 200 in
Having introduced the disclosed technology in the sections, this section presents general methods and systems for performing aspects of the disclosed transactive control approach. The embodiments below should not be construed as limiting and can be performed alone or in combination with any other feature or aspect disclosed herein.
At 2410, incentive signal data is computed. The incentive signal data can comprise data indicative of a cost of electric energy at the transactive node at a current time interval and data indicative of a forecasted cost of electric energy at the transactive node at one or more future time intervals. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive node will operate.
At 2412, feedback signal data is computed. The feedback signal data can comprise data indicative of an electric load at the transactive node at the current time interval and data indicative of a forecasted load for electric energy at the transactive node at the one or more future time intervals. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive node will operate
At 2414, the incentive signal data and the feedback signal data is transmitted. For example, the incentive signal data and feedback signal can be transmitted separately or together from one transactive node to each of its neighboring transactive nodes.
In certain embodiments, the data indicative of the cost of electric energy comprises data indicative of a cost of real electrical energy, reactive electrical energy, or a combination of both real and reactive electrical energies at the transactive node at the current time interval. Further, the data indicative of the forecasted cost of electric energy can comprise data indicative of a forecasted cost of real electrical energy, reactive electrical energy, or a combination of both real and reactive electrical energies at the transactive node at the one or more future time intervals. In some embodiments, the data indicative of the electric load comprises data indicative of a real electrical load, reactive electrical load, or a combination of both real and reactive electrical loads at the transactive node at the current time interval. Further, the data indicative of the forecasted load for electric energy can comprise data indicative of a forecasted load of real electrical load, reactive electrical load, or a combination of both real and reactive electrical loads at the transactive node at the one or more future time intervals.
In some embodiments, the incentive signal data further comprises data indicating a confidence level that the data indicative of the cost of electric energy at the transactive node at the current time interval is reliable (e.g., a confidence level for each time interval), and data indicating a confidence level that the data indicative of the forecasted cost of electric energy at the transactive node at the one or more future time intervals is accurate (e.g., a confidence level for each time interval). Further, in certain embodiments, the feedback signal data further comprises data indicating a confidence level that the data indicative of the electric load at the transactive node at the current time interval is accurate, and data indicating a confidence level that the data indicative of the forecasted load for electric energy at the transactive node at the one or more future time intervals is accurate.
In certain embodiments, the method further comprises receiving incentive signal data and feedback signal data from one or more neighboring transactive nodes. In such embodiments, the computation of the incentive signal data can be based at least in part on the received incentive signal data, and/or the computation of the feedback signal data can be based at least in part on the received feedback signal data.
At 2510, incentive signal data is received at the transactive node from two or more neighboring transactive nodes. The incentive signal data from the two or more neighboring transactive nodes can comprise data indicative of at least a cost of electric energy at a current time interval. In certain embodiments, the incentive signal data comprises data indicative of the cost of electric energy at the current time interval (e.g., the delivered unit cost of the energy at that node) and data indicative of a forecasted cost of electric energy at one or more future time intervals. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive node will operate
At 2512, aggregated incentive signal data is computed based at least in part on the incentive signal data from the two or more neighboring transactive nodes. In some embodiments, the aggregated incentive signal data comprises data indicative of the aggregated cost of electric energy at the current time interval and data indicative of a forecasted aggregated cost of electric energy at one or more future time intervals. Further, in some embodiments, the aggregated incentive signal data comprises a weighted sum of the incentive signal data from the two or more neighboring transactive nodes. In certain embodiments, the aggregated incentive signal data is further modified to provide an incentive or disincentive to the further transactive node based on local conditions at the transactive node. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive node will operate
At 2514, the aggregated incentive signal data is transmitted to a further transactive node (e.g., a neighboring transactive node).
In some embodiments, the received incentive signal data and the transmitted aggregated incentive signal data comprise data indicative of a cost of real electrical energy, reactive electrical energy, or a combination of both real and reactive electrical energies. In certain embodiments, the received incentive signal data further includes data indicating a confidence level of the received incentive signal data (e.g., a confidence level for each time interval). And in some embodiments, the transmitted incentive signal data further includes data indicating a confidence level of the transmitted incentive signal data (e.g., a confidence level for each time interval).
In some embodiments, the method further comprises receiving feedback signal data at the transactive node from the two or more neighboring transactive nodes, the feedback signal data from the two or more neighboring transactive nodes comprising data indicative of at least an electric load for electric energy at a current time interval; computing aggregated feedback signal data based at least in part on the feedback signal data from the two or more neighboring transactive nodes; and transmitting the aggregated feedback signal data to the further transactive node. In such embodiments, the received feedback signal data can comprise data indicative of the electric load for electric energy at the current time interval and data indicative of a forecasted load of electric energy at the one or more future time intervals, and the aggregated feedback signal data can comprise data indicative of the aggregated load of electric energy at the current time interval and data indicative of a forecasted aggregated load of electric energy at one or more future time intervals.
At 2610, feedback signal data is received at a transactive node from two or more neighboring transactive nodes. The feedback signal data from the two or more neighboring transactive nodes can comprise data indicative of at least an electric load for electric energy at a current time interval. In certain embodiments, the received feedback signal data comprises data indicative of the electric load of electric energy at the current time interval and data indicative of a forecasted load of electric energy at one or more future time intervals. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive node will operate
At 2612, aggregated feedback signal data is computed based at least in part on the feedback signal data from the two or more neighboring transactive nodes. In certain embodiments, the aggregated feedback signal data comprises data indicative of the aggregated load of electric energy at the current time interval and data indicative of a forecasted aggregated load of electric energy at the one or more future time intervals.
At 2614, the aggregated feedback signal data is transmitted to a further transactive node.
In certain embodiments, the received feedback signal data and the transmitted aggregated feedback signal data comprise data indicative of a real electrical load, reactive electrical load, or a combination of both real and reactive electrical loads. In some embodiments, the received feedback signal data further includes data indicating a confidence level of the received feedback signal data (e.g., a confidence level for each time interval). And in certain embodiments, the transmitted feedback signal data further includes data indicating a confidence level of the transmitted feedback signal data (e.g., a confidence level for each time interval).
In some embodiments, the method further comprises receiving incentive signal data at the transactive node from the two or more neighboring transactive nodes, the incentive signal data from the two or more neighboring transactive nodes comprising data indicative of at least a cost of electric energy at the current time interval; computing aggregated incentive signal data based at least in part on the incentive signal data from the two or more neighboring transactive nodes; and transmitting the aggregated incentive signal data to the further transactive node. In such embodiments, the received incentive signal data can comprise data indicative of the cost of electric energy at the current time interval and data indicative of a forecasted cost of electric energy at the one or more future time intervals, and the aggregated incentive signal data can comprise data indicative of the aggregated cost of electric energy at the current time interval and data indicative of a forecasted aggregated cost of electric energy at one or more future time intervals.
At 2710, one or more functions from a library of functions are selected. The selection can be based at least in part on the type of one or more electric resources or electric loads associated with the transactive node. In certain embodiments, the selected one or more functions are adapted for the type of electrical load or electrical supply associated with the transactive node. In some embodiments, the configuring comprises causing computing hardware used to implement the transactive node to execute a software program for performing computations using the selected one or more functions. In certain embodiments, the selected one or more functions include a function that computes data representing one or more of energy, an energy cost, or an incentive for one or more electric resources associated with the transactive node. In some embodiments, the selected one or more functions include a function that computes data representing one or more of a predicted inelastic load or changes in elastic load for one or more electric loads associated with the transactive node
At 2712, the transactive node is configured to compute transactive signals using the selected one or more functions.
In some embodiments, the method can comprise accessing a database storing the library of functions (e.g., a locally stored database or a database remotely located from the transactive node).
Further, the library of functions can be an extensible library. For example, the library can be expanded to include newly formulated functions. Further, in some implementations, existing functions may be selected from the library, edited by a relevant party (e.g., a utility or system administrator), and returned to the library as a newly available function with modified features and capabilities. The parties that have access to editing and adding library functions can vary from implementation to implementation, and can encompass a wide variety of parties involved in the power transmission infrastructure. In some instances, the parties who can edit and/or add functions is limited to some selected group (e.g., system regulators or to a single utility).
Also disclosed herein are several embodiments for systems for distributing electricity. One of the disclosed systems is a system for distributing electricity, comprising: a plurality of transactive nodes, each transactive node being associated with one or more electric resources, one or more electric loads, or a combination of one or more electric resources and loads; and a network connected to the transactive nodes to facilitate communication between the transactive nodes. In these embodiments, the transactive nodes are configured to exchange incentive and feedback signals with one another in order to determine an electrical demand in the system for a current time interval and to provide an electrical supply sufficient to meet the electrical demand for the current time interval. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive nodes will operate
In certain embodiments, the transactive nodes are further configured to exchange incentive and feedback signals for two or more future time intervals in addition to the incentive and feedback signals for the current time interval. In some embodiments, the two or more future time intervals have increasingly coarser granularity. In certain embodiments, at least one of the transactive nodes modifies one or both of its incentive or feedback signals in response to previously received incentive and feedback signals. In some embodiments, the at least one of the transactive nodes is associated with an elastic load, and wherein the modified incentive or feedback signals corresponds to a predicted change in the elastic load. In certain embodiments, the at least one of the transactive nodes is associated with an electrical resource, and the modified incentive or feedback signals corresponds to a change in the electrical resource. In further embodiments, the at least one of the transactive nodes is associated with an electrical resource, and the modified incentive signals correspond to a change in local conditions.
In certain embodiments, one or more of the transactive nodes compute their respective incentive and feedback signals using functions selected from a library of functions. Still further, in some embodiments, the incentive and feedback signals further include confidence level data indicating a respective reliability of the incentive and feedback signals.
Another system disclosed herein is a system for distributing electricity, comprising: a plurality of transactive nodes, each transactive node being associated with one or more electric resources, one or more electric loads, or a combination of one or more electric resources and loads; and a network connected to the transactive nodes and facilitating communication between the transactive nodes. In these embodiments, the transactive nodes are configured to exchange sets of signals with one another in order to determine an electrical demand in the system for a current time interval and to provide an electrical supply sufficient to meet the electrical demand for the current time interval. Each set of signals includes signals for determining the electric loads and supplies for the current time interval as well as signals for determining the electric loads and supplies for two or more future time intervals. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive nodes will operate
In some embodiments, the future time intervals have increasingly longer durations as the time intervals are farther into the future relative to the current time interval. In other embodiments, the transactive nodes are configured to update the values of the sets of signals at an update frequency, the update frequency corresponding to a duration of the current time interval. In some embodiments, the transactive nodes are configured to exchange the set of signals with one another iteratively over time such that the signals for a respective time interval stabilize as the respective time interval approaches the current time interval.
In certain embodiments, the transactive nodes are configured to exchange the set of signals with one another on an asynchronous event-driven basis or a clock-driven basis. In some embodiments, a respective set of the transactive nodes are configured to iteratively exchange a set of signals with one another until the exchanged set of signals converges to within an acceptable degree of tolerance. In certain embodiments, a transactive node in the respective set of the transactive nodes is further configured to transmit an updated set of signals when local conditions at the transactive node cause the updated set of signals to deviate from a previously transmitted set of signals beyond a relaxation criterion. In some embodiments, the sets of signals further include confidence level data indicating a respective reliability of the exchanged signals (e.g., a confidence level for each time interval).
Another system disclosed herein is a system for distributing electricity, comprising: a plurality of transactive nodes, each transactive node being associated with one or more electric supplies, one or more electric loads, or a combination of one or more electric supplies and loads; and a network connected to the transactive nodes and facilitating communication between the transactive nodes. In these embodiments, the transactive nodes are configured to exchange sets of signals with one another in order to determine an electrical demand in the system for a current time interval and to provide an electrical supply sufficient to meet the electrical demand for the current time interval, a respective one of the transactive nodes being configured to compute its incentive and feedback signals using one or more functions selected from a library of functions. In certain embodiments, the current time interval refers to the imminent (or next-to-occur) interval in which the transactive nodes will operate
In certain embodiments, the one or more functions selected from the library of functions are selected based on the type and number of electrical supplies and electrical loads with which the respective transactive node is associated. The one or more functions can be selected from a group of resource functions comprising one or more of: (a) a resource function adapted to account for imported electrical energy, (b) a resource function adapted to account for a renewable energy resource, (c) a resource function adapted to account for fossil fuel generation, (d) a resource function adapted to account for general infrastructure cost, (e) a resource function adapted to account for system constraints, (f) a resource function adapted to account for system energy losses, (g) a resource function adapted to account for demand charges, and (h) a resource function adapted to account for market impacts. The one or more functions can also be selected from a group of load functions comprising one or more of: (a) a load function adapted to account for a bulk inelastic load, (b) a load function adapted to account for an event-driven demand response, (c) a load function adapted to account for a time-of-use demand response, and (d) a load function adapted to account for a real-time continuum demand response.
In some embodiments, the respective one of the transactive nodes controls one or more elastic loads and adjusts the one or more elastic loads in response to the feedback and incentive signals received at the respective one of the transactive nodes. In certain embodiments, the one or more functions are implemented by individual software modules that can be combined with one another to implement the desired transactor behavior for the respective one of the transactive nodes.
In certain embodiments, through the use of the one or more functions, the respective one of the transactive nodes computes a control signal selected from a set of signed whole numbers and communicates the computed control signal to one or more loads, resources, or loads and resources associated with the respective one of the transactive nodes. The computed control signal can be interpreted by an electrical generator or set of electrical generators as a fraction of the generator's or generators' rated generation capacity. The computed control signal is interpreted by an electrical load or set of electrical loads as a fraction of the load's or loads' rated power.
It should be understood that in embodiments of the disclosed technology, a transactive node may host multiple toolkit functions, including any combination of multiple resource and incentive functions, multiple load functions, or combinations of both resource and incentive and load functions. For instance, the resource and/or incentive functions used at a transactive node will typically depend on the location of the transactive node in a power grid topology, and on the one or more resources and/or loads for which the transactive node is responsible. This ability to “mix and match” resource and incentive functions while still maintaining a common transactive signal communication structure gives embodiments of the disclosed technology wide flexibility and scalability for implementing a transactive control system.
Having introduced the disclosed technology, this section includes four supplemental Appendices that provide additional details and configurations that can be used in implementations of the technology. The specific implementations disclosed below should not be construed as limiting. Further, any one or more of the features or aspects disclosed below can be used alone or in conjunction with any other feature or aspect of the disclosed technology discussed herein. Some portions of the appendices may, in some instances, be repetitive to other portions of this application, but such portions are included for the sake of completeness.
A transactive control and coordination system is a network of loosely connected, interacting transactive nodes. This appendix states a high-level state model for a transactive node and types of connections that a transactive node desirably manages. This appendix should provide valuable guidance to system designers who are implementing a transactive control and coordination system from the perspective of a transactive node.
This appendix defines and discusses
In some embodiments, a transactive node manages its own set of attributes and additionally manages additional types of connection. In certain implementations the transactive node manages four types of connections—connections to transactive neighbors, system managers, assets, and local input information. All four connection types can share a set of connection attributes in common in order to manage connections between this transactive node and each transactive neighbor, system manager, asset, or local input information. An example of this structure has been laid out in diagram 2800 in
In certain embodiments, a transactive node has five states available to it as shown in the state transition diagram 2900 of
The identifying numbers that have been applied to the functions and events in
Each connection has four allowed states as shown in diagram 3000 of
Again, the identifying numbers and letters that prepend the functions and events in
Table 7 is a dictionary of example attributes that can be used to define the state of a transactive node. Later in this appendix, attribute dictionaries will be presented to address attributes of the four types of connections. The meanings of the columns in these dictionary tables are as follows.
The transactive node attribute group contains those attributes that stand alone and refer to one transactive node and its transactive node state model. An example attribute dictionary is shown in Table 7.
Table 8 that follows is a summary of which of these attributes can be added, checked, or modified by the set of commands and events that occur within the state transition table (Table 7), as were introduced in the state transition diagram 2900 of
Run Node Executable(Filename) Command
Configure( )(Node Attributes) Command—a flexible command that is applicable to the transactive node as well as to the other connections that a transactive node manages. An important concept in the use of this command is that the connection's identifier should be stated before any of its attributes may be modified. Because this section is addressing only the transactive node state model, the only attributes that will be addressed in this section are transactive node attributes for this transactive node.
Configuration Test( )—this is neither a system management command nor an event, but it is a test of the present configuration that should be conducted automatically by a transactive node after a successful Configure( ) command. It is permissible that the test may be run more often, but the outcome should not be expected to change unless a successful Configure( ) command occurs.
Connection Test( )—this is neither a system management command nor an event, but it is a test of the completeness of the connections that should be completed between this transactive node and its connections. A Connection Test should be conducted automatically by a transactive node after a successful Configure( ) command and after any connection changes its connection state. A transactive node should have passed a Configuration Test before a Connection Test may be passed.
Operate( ) Command
Handle Fatal Operational Event/Handle Non-Fatal Operational Event
Halt Operations( ) Command
Terminate Node( ) Command
In the table below, the numbering convention used for these functions and events are concatenations of the prior and end states. Where multiple functions and events have identical prior and end states, letters have been appended. For example, “54b” is the number applied to the second of two transitions from state number 5 to state number 4.
Connection attributes have been identified and are ascribable in common to the four types of connections. This set of attributes refers to a single connection between this transactive node and a transactive neighbor, system manager, asset system, or source of local information. The connection attributes are indispensible for keeping track of the state of any type of connection. It is never adequate to reference these attributes apart from a specific example of attribute 27—Connection ID.
Connection attributes are important for navigating the connection state transition diagram 3000 in
Refer to Table 11 for the anticipated ways in which the connection attributes may be affected by the commands and events of the connection state model.
In the connection state model (see
In certain embodiments, transactive node define at least one connection to a transactive neighbor. The connection may be observed and maintained using the union of connection attributes and transactive node attributes (see
At least for some of the connections that are being made to transactive neighbors, it may be desired that experimenters and testing entities have the means to redirect the inputs received from the transactive neighbors so that these inputs may be received instead from selected alternative sources of such information. It is likewise important that one may redirect the output from these connection partners to one or more alternative locations. For the special type of connection partners called transactive neighbors, the means to redirect inputs and outputs has been accomplished with attributes 10-13, which attributes define the sources and targets of transactive signals. The sources and targets are not necessarily the transactive neighbor itself. Using these attributes, simulations and “what-if” scenarios may be designed and tested in the production or test system environments. (So far, attributes #10-13 only apply to transactive neighbors and their connections. It is conceivable that the attributes could be generalized and renamed to apply to any connection type, not only transactive neighbors.)
In certain embodiments, a single attribute can define a connection to a system manager.
Note that in certain implementations, transactive nodes establish and maintain a connection to the global system manager. Therefore, attribute 52 System Manager ID includes the ID of this global system manager for the transactive nodes.
This group of Asset attributes are meaningful only in respect to a given connection to an asset, which can be an energy resource, an incentive, or a load. Each resource or incentive has a corresponding toolkit resource and incentive function that defines how its behavior and effects may be modeled or predicted for the formulation of the transactive signals according to the toolkit framework. Each load similarly should have a corresponding toolkit load function that describes its effect on the formulation of the TFS. Often these “assets” will, in fact, be rather complex systems of assets.
An asset connection may list a set of local information connections that should be established via its 38—List of Local Information. Each member of this list creates an expectation that a local information connection will become established.
An asset connection should have its 2—Asset ID, 6—Toolkit Function, and 6—Asset Type configured before it is able to enter into the connection state 2—Configured
To support future simulations and testing, the connection state model includes an ability to redirect the output of these asset connections. Some of the assets will be responsive to the transactive control and coordination system and an output “control” signal is sent to these asset systems by this transactive node. Attribute 25—Asset Output Targets allows the targets of these “control” signals to be sent to the asset system, to another entity, or to both the asset system the other entity.
List the local information inputs that are anticipated by an asset system and the toolkit function that predicts its behaviors. These streams of input information that are at time referred to as “other local conditions” should additionally become listed as attributes 48—Local Information ID so that the continuity of the data stream may be monitored and so the input can become redirected, thus allowing alternative scenarios to be simulated with alternative input information.
Table 17 lists the asset attributes and indicates how these attributes may be affected by the system management commands and events that are part of the connection state model.
The Assets in the Asset Table of Table 16 are closely aligned with several of the interim data storage areas (“buffers”) that have been defined in the toolkit framework and with appear also in the state mode. For an asset connection there should be corresponding entries in one or more of the buffer (storage) areas that have been defined in the toolkit framework:
A transactive node may possess many assets, and each asset may invoke multiple input information streams. Therefore, the local information connections should be carefully defined in the connection state model, and two attributes have been grouped as local information connection attributes.
A local information connection is an input that is invoked by and used by a toolkit function. Experimenters and testing personnel may wish to intentionally insert other alternative input information into the toolkit functions via this local information to simulate alternative scenarios that would be unlikely to occur under normal operations. Attribute 48 has been provided for this purpose, with which the source of the local information may be received from either the normal information provider or from an alternative source like an input file.
Table 19 lists which of the state model's commands and events are expected to modify the two Other Local Condition Attributes.
Configure( ) (Connection Attributes) Command—the same flexible command that was applied to the transactive node may also be used for configuring the connections that a transactive node manages. Only the new parameters that should be used for connections will be presented; most parameters that were used for the transactive node state model will not be repeated. This command is used with connection attributes by first referring to the respective connection identifier (e.g., contents of attributes 52, 2, 53, or 48) and setting or modifying that connection's remaining attributes.
Connection Configuration Test( )—a simple test of a given connection's attributes to determine if the connection may transition into or remain in its 2—Configured state. A connection in either its 3—Connected or 4—Lost Connection state has, by definition passed its Connection Configuration Test. If a connection passes its Connection Configuration Test, it should be in state 2—Configured; if it fails, it should be in state 1—Listed.
A Connection Configuration Test is not a system command. It should be initiated by the logic of the transactive node and by the transactive node itself. It should be run for a given connection anytime that the Configure( ) command has run successfully and might have therefore modified the configuration of the connection.
Connect( ) Command—directs a configured connections to be completed between this transactive node and one of its connection partners.
Disconnect( ) Command—system management command by which a transactive node is asked to disconnect a connection between this transactive node and one of its connection partners.
Loss of Connection Event( )—a diagnostic process at this transactive node observes the health and activity of each connection. If the connection should fail, the diagnostic process initiates a Loss of Connection Event. This event transitions the respective connection into a temporary Lost Connection state, from which the ramifications of the event may be addressed and handled. This transactive node is permitted to remain in its Operational state in the meantime, according to the logic of the present state model.
Re-Establish Connection Event( )—a diagnostic process recognizes that a connection has become restored for a connection that was in its Lost Connection state. The connection reverts to its Connected state.
Table 20 is the state transition table for the four types of connections that are to be managed by a transactive node. Refer to the diagrammatic representation of the connection state transitions in
The state transition tables in this section have consistently indicated outputs to a log table. It will be good practice to create a log entry record for each command and event that is encountered by the transactive node and its connections. Instead of defining each log entry at the point that it was introduced in the state transition tables, it may be preferred to establish practices for the contents of these records based on their types and by whether they affect the transactive state model or that of the transactive node's connections:
The table below represents that state transitions of a transactive node that has been configured, connected and is now in the overall operational state and status. Note that there is no start or final state in this table. All states may be intermediary. Refer to the toolkit framework for the algorithmic framework facilitated by this part of the state model.
Transactive control signals (transactive incentive signal and transactive feedback signal) carry information related to electrical power supply and demand over a wide area network. The signals traverse a network of transactive control nodes to elicit a desired control action from responsive assets in a timely manner. The end-to-end (from generation to end-user customer) transmission time should be less than 3 minutes assuming a transactive control hierarchy of 15 levels spanning a 1000 mile radius. This translates to roughly 12 seconds (180/15) per hop time budget including the link transit time. Note that the transactive incentive signals will start at the bulk generators and continue to end-user customers. The transactive feedback signal will start at the end-use customer and will travel through the transactive control hierarchy towards bulk generation. While the TIS and the TFS are decoupled temporally and loosely coupled functionally in the sense that a TFS generation does not have to get triggered by the arrival of a TIS, the two signals still influence each other since the computation of TIS and TFS considers the forecasted values for each signal.
The timing model can be purely clock-driven or more asynchronously event-driven. For example, in some embodiments, a set of neighboring transactive nodes are configured to exchange transactive values with one another until the transactive values converge with one another to an acceptable degree (e.g., within a designated percentage of one another (such as 5%, 2%, 1%, or any other desired degree of tolerance)). Further, in such even-driven systems, when a change occurs within a transactive node (e.g., due to a change in local conditions), the transactive node can be configured to transmit an updated set of transactive signals when its local transactive signals deviate from the previously transmitted signals by more than a relaxation criterion.
If the system becomes highly synchronized, bursts of signals might tax the system infrastructure. If the system becomes too loosely event-driven and asynchronous, it becomes more difficult to confirm that signals will have been conveyed. There is probably some flexibility allowable between these extremes, and the design in this appendix facilitates some flexibility. Regardless, the timing model should recognize that the “conversation” of these signals necessarily changes during the transition from one update interval to the next because the set of future intervals change during this transition.
A set of ten (and in some embodiments, mandatory), configurable attributes B1-B10 are defined below in Table 22.
The timers and the operation for an example TIS embodiment are illustrated in diagram 3200 of
In summary, the following desired behavior is expressed in pseudo code format.
Upon node startup:
Upon receiving a TIS:
Upon receiving a TFS:
Upon expiration of TIS_TIMER:
Upon expiration of TFS_TIMER:
Upon expiration of TIS_HOLD_DOWN_TIMER:
Upon expiration of TFS_HOLD_DOWN_TIMER:
Upon expiration of the WATCHDOG_TIMER:
In certain embodiments, transactive nodes periodically send their transactive signals to their neighbors. The timing of this responsibility has recently been specified and will become included in reference code implementations of the transactive node model algorithm (TNMA). The timing specification references a relaxation stop criterion based upon changes observed between the present signal and the most recent prior signal that has been calculated and sent by this transactive node. If the signals are found to have not changed much, this transactive node should not send its calculated signal again during the present update interval.
The purpose of this section is to state the criterion by which a transactive node may discern whether it should continue to send out its calculated transactive signals or not during the present update interval.
A relaxation stop criterion can be used under the following assumptions:
For each future interval s, define error εs as the absolute difference between the present estimate of the value Vs(k) and the prior estimate of the value Vs(k−1).
εs=|Vs(k)−Vs(k−1)| (Eq. C1)
The criterion should be applied consistently to either the value itself or to a relative representation of the value, which further results in dividing the result in Eq. C1 by the absolute value of Vs(k).
Each error εs should be factored by a corresponding weighting factor Ws to account for the impacts of the duration of each future interval s and the number of iterations that may be reasonably performed on the prediction.
In Eq. C2, Ds is the time duration of interval s, and γ is a constant [1,2+) that represents the effectiveness of each iteration, as was described in bullet #2 above. The term (ts−t0)/D represents the number of iterations that could reasonably be completed if iterations are conducted after every D constant time interval between the start of the predicted interval ts and the present time t0. For example, the system can update its calculations every 5 minutes, so one might naturally expect over 12 opportunities for the solution to iteratively converge every hour.
The overall relaxation stop criterion may then be stated as a constant E that is proportional to the sum of all the weighting factors. The proportionality constant K represents a conservative “typical” error εs that would be deemed acceptable. Some trial and error may occur to select the proportionality constant K that will result in an acceptable number of iterations.
The time series has been iterated adequately when the weighted sum of errors are less than the constant E, in which case iterations should be halted. If, however, the weighted sum of errors is greater than or equal to the constant E, then additional iteration should be conducted until errors satisfy the criterion.
The complete criterion is stated in Eq. C4.
An example has been worked through in Appendix A using three different values of constant γ. The example uses a set of intervals from the Demonstration of the type that will be used for its transactive signals. The weighting factors for the series of intervals and at the three example values of constant γ have been plotted in graph 3400 of
Large gamma (e.g. γ=2.0) is shown to discount the importance of error in future predictions more than small values of gamma (e.g., γ=1.0625). The jagged curve reflects that long interval durations are weighted more than short ones, which is relevant for the Demonstrations intervals that become successively longer after the 12th, 32nd, 50th, and 54th intervals. The impact of distant future weightings may become negligibly small.
Table 24 specifies four additional transactive node attributes that can be used if a transactive node is to employ the relaxation stop criterion as it has been introduced in this appendix. These attributes can be assumed to be assignable at the transactive-node level. It is conceivable that this criterion (or another) and its attributes may in the future be configured differently for each transactive neighbor connection.
This section will sometimes make reference to the following terms, whose nonlimiting definitions are also given below. These definitions do not necessarily apply in all instances and may vary depending on the context.
A transactive node represents a predetermined component or region within an electric power grid at which electrical energy may be generated, consumed, imported, or exported. In principle, the transactive node construct will be scalable and similarly applicable to from small, end-use equipment (e.g., a distribution transformer, residential thermostats) to large regions (e.g., the boundary of an electric utility). A transactive node includes an agent of sorts (e.g., a computer and its software applications) that orchestrates each transactive node's responsibilities to:
1. economically balance energy
2. incentivize energy consumption or generation
3. activate its own responsive generation and load resources
4. exchange both transactive incentive signals (TIS) and transactive feedback signals (TFS) with each of its neighboring transactive nodes.
The two transactive signals—the transactive incentive signal (TIS) and transactive feedback signal (TFS)—reveal the predicted local delivered cost of electric energy and the predicted use of a TN to exchange electrical energy with its neighbors, given the value of the TIS and other predicted local conditions. (While this document refers often to pairs of TIS and TFS signals, the two signals need not necessarily always be received and sent together and simultaneously. Instead, the signals can be decoupled so that they may be sent and received separately.)
These functional behaviors should be designed into the transactive control and coordination system. Depending on its complexity, memberships, and location in its power grid, a transactive node may assume all, some, or practically none of the responsibilities to be described in this document. The toolkit function library construct is one way to organize and teach the responsibilities of a TN to those who would wish to define a transactive node and have their transactive node enter into an existing transactive control and coordination system. The toolkit library should not only hasten the adoption and implementation of transactive control, but it should also standardize implementations of transactive control so that the building blocks components will be more interoperable. The toolkit library should be available to implementers who may choose from and learn from others' experiences and practices. The template for toolkit library functions anticipates providing reference implementation code with which implementers may jump start their instantiation of similar functions.
The functional responsibilities of a transactive node will be described at two levels of the toolkit:
1. Toolkit framework—the high-level computational structure that provides basic transactive control functionality of transactive nodes and that calls upon specific toolkit library functions to enact the functionality of specific incentives and assets.
2. Toolkit library functions—the specific functions that account for resource, enact incentives and plan asset responses at transactive nodes where these specific functions have been implemented and are relevant. Applicable toolkit library functions are called upon and acted upon within the toolkit framework.
The toolkit framework is a high-level structure for the inputs, functions, processes, and outputs that define transactive control functionality at a transactive node. The toolkit framework will probably be found to encompass the high-level functional responsibilities of the transactive node model algorithm (TNMA) module.
(This document primarily addresses the algorithmic functionality of a transactive node and its responsibilities toward management of electrical energy. This document may facilitate, but does not intend to specify, functionality toward system management, timing, and data collection that are better addressed within the transactive node's object model.)
The flow of information in
Information buffers appear in several of the information flow paths. These buffers are available to be mined by data collection processes and might be made accessible to the system management level. (These buffers, if defined as part of a standard transactive node definition, can be used as a point of observability for testing. In addition, the option of preloading the buffers may be useful for testing (especially if only the 5-minute update frequency is available).) The buffers also provide recent information that may be used if any prior function or process should fail to promptly complete its responsibilities or provide its output information. The flow in this diagram has been greatly simplified by the assumption that any buffered historical information is available to be used by any other function or process at this transactive node.
As part of its data collection design for transactive data, a number of buffers can be used. For example, in the illustrated embodiment in
The following processes and functions are referenced in
1. Receive Transactive Signals
1.1. Read TIS and TFS from Transactive neighbor
1.2. Check Authentication and Security
1.2.1. Interact with System Management (Security)
1.3. Check Validity of Transactive Signals
1.3.1. Interact with System Management (Validity)
1.4. Update Input Transactive Signal Buffer for this Transactive neighbor
2. Calculate New Transactive Signal Intervals
2.1. Read Present Time
2.2. Calculate First Interval Start Time IST0
2.3. Calculate 5-Minute Interval Start Times
2.4. Calculate 15-Minute Interval Start Times
2.5. Calculate 1-Hour Interval Start Times
2.6. Calculate 6-Hour Interval Start Times
2.7. Calculate 1-Day Interval Start Times
2.8. Calculate Interval Durations from Interval Start Times
3. Formulate TIS
3.1. Refresh Default Output TIS
3.2. Calculate Total Costs of Non-Transactive Energy Generation and Imports
3.3. Calculate Total Cost of Energy Imported from Transactive nodes
3.4. Calculate Total Capacity Cost/Incentives
3.5. Calculate Total Infrastructure Cost/Incentive
3.6. Calculate Total Other Cost/Incentive
3.7. Calculate Output TIS
3.8. Calibrate/Normalize TIS
3.9. Interpolate Intervals Service Functions
4. Formulate TFS
4.1. Interpolate Intervals Service Functions
4.2. Predict Net Resource Surplus or Shortage
4.3. Disaggregate Net Resource Surplus or Shortage
4.4. Refresh Default Output TFS
5. Sum Total Predicted Load
5.1. Interpolate Intervals Service Functions
5.2. Sum Inelastic Load
5.3. Sum Change in Elastic Load
5.4. Sum Total Inelastic and Change in Elastic Load
5.5. Refresh Predicted Total Inelastic and Elastic Load
6. Calculate Applicable Toolkit Load Functions
6.1. Interpolate Intervals Service Functions
6.2m Toolkit Load Function
6.3 Refresh Predicted Inelastic and Elastic Loads
7. Send Transactive Signals (Defined only functionally at a high level)
8. Calculate Applicable Toolkit Resource and Incentive Functions
9. Control Responsive Asset Systems (Defined only functionally at a high level)
10. Sum Total Predicted Resources
10.1. Interpolate Intervals Service Functions
10.2. Sum Total Predicted Resource
10.3. Refresh Predicted Total Resource
11. Control Responsive Resource
The next sections will describe examples of the functions in the above list. The sections below are demarcated by the function numbers set forth in the list above, and are not to be confused with the section numbering used outside of this appendix.
1. Receive Transactive Signals
Purpose:—
Transactive signals are signals to be communicated between transactive nodes in a transactive control and coordination system. It is through transactive signals that transactive nodes share their temporal and locational costs and thirsts for electrical energy. Transactive incentive signals (TIS) and transactive feedback signals (TFS) should be received from the transactive node neighbors at the update frequency, which happens to be once every 5 minutes for the Demonstration.
This function includes technical validation of received signals to ensure that they were properly formed and that their values are within acceptable norms. Validation is not yet a high priority, and validation processes probably do not need to be standardized across all transactive nodes. If an invalid signal is detected, it should be flagged. Additional actions may be taken to notify or alert targeted system operators and reduce the impacts from potentially misleading signals.
Applicability:
This function should be completed by a transactive node at least once during an update interval. If this function fails, functions and processes of the toolkit framework that use an input transactive signal should revert to buffered historical signals.
Sub-Functions and Sub-Processes:
The following sub-functions are iteratively completed until the input transactive signals from transactive neighbors have been received.
1.1 Read TIS and TFS from a Transactive neighbor—Function by which the TIS and TFS from a transactive neighbor is to be received. Most generally, the implementation details by which this sub-function is to be accomplished should be negotiated by pairs of transactive neighbors that will exchange transactive signals.
1.2 Check Authentication and Security—Functional block (or blocks) for signals like transactive signals that are to be conveyed through the transactive control and coordination system. The actual functional implementation details for security functions may differ from one implementation to another, but general descriptions for this block should be documented if they are applicable to any transactive node.
1.2.1 Interact with System Management (Security)—Actions that are to be taken if Check Authentication and Security function fails to authenticate a transactive signal or detects an insecurity. The input transactive signals are terminated if they cannot be authenticated or if security violations are suspected. Actions may include notifications and alerts that are to be conveyed by the system management layer. Specific actions of this function may differ by implementation.
1.3 Check Validity of Transactive Signals—Functional block (or blocks) by which the structure or contents of a transactive signal may be tested against expected and reasonable structure and content. Examples of checks on the structure of the signals could include verification of adherence to an XML schema, an expected number of future intervals, or the ordering of a series within the signal. An example of a content check would be verification that a signal's values are between stated maximum and minimum values.
1.3.1 Interact with System Management (Validity)—Actions that are to be taken if the Check Validity function fails validate transactive signals. The input transactive signals are terminated and not used or stored if they cannot be validated. Actions may include notifications and alerts that are to be conveyed by the system management layer. Specific actions of this function may differ by implementation. General functional aspects for this function that should apply to transactive nodes should be documented and implemented. More sophisticated actions may be taken, including reducing the Quality attribute of signals that have questionable validity.
1.4 Update Input Transactive Signal Buffer for this Transactive neighbor—Received transactive signals are saved into the Input Transactive Signal Buffer. The buffer may be as simple as a running (or circular) list of transactive signal pairs that have been received from transactive neighbors. The most recently received pairs or transactive signals from each transactive neighbor are most relevant within this buffered data. A much longer buffered history may be used at transactive nodes that use trending to predict transactive neighbors' responses (e.g., elasticity) or to improve the accuracy of their transactive signal predictions over time.
Inputs:
Outputs:
Dependencies:
Notes:
2. Calculate New Transactive Signal Intervals
Purpose:
Calculate the new interval start time (IST) time series that are attributes of the two transactive signal object types that are to be formulated and conveyed throughout the transactive control and coordination system. See SubAppendix A: Interval Start Time Series Definition for details about an example IST time series and how the series is calculated.
Applicability:
This function should be completed by transactive nodes at the update frequency. In particular implementations, an update frequency of once every 5 minutes is used, though other intervals can be used.
Sub-Functions and Sub-Processes:
The sub-function steps will be described along with this introduction to the sub-functions. Refer to SubAppendix A for additional details and examples.
2.1 Read Present Time—the present time is locally maintained at each transactive node and should be read near the beginning of each iteration. The present time and representations of time are to be maintained using the UTS standard.
2.2 Calculate First Interval Start Time IST0—to calculate IST0, round the present time up to the nearest 5-minute interval.
2.3 Calculate 5-Minute Intervals Start Times—to calculate IST2 through IST11, add 5 minutes to the prior IST.
2.4 Calculate 15-Minute Interval Start Times—to calculate IST12, add 15 minutes to the prior IST11, and round down to a 15-minute interval. To calculate the remaining 15-minute intervals IST13 through IST31, add 15 minutes to the prior IST.
2.5 Calculate 1-Hour Interval Start Times—to calculate IST32, add 1 hour to the prior IST31, and round down to a 1-hour interval. To calculate the remaining 1-hour intervals IST33 through IST49, add 1 hour to the prior IST.
2.6 Calculate 6-Hour Interval Start Times—to calculate IST50, add 6 hours to the prior IST49, and round down to a 6-hour interval. To calculate the remaining 6-hour intervals IST51 through IST53, add 6 hours to the prior IST.
2.7 Calculate 1-Day Interval Start Times—to calculate IST54, add 1 day to the prior IST53, and round down to a 1-day interval. To calculate the remaining 1-day interval IST55, add 1 day to the prior IST54. In certain embodiments, a final IST56 can be appended that will unambiguously define the duration of the final interval. (The final IST does not define a new interval, it simply states the end of the last interval.)
2.8 Calculate Interval Durations from Interval Start Times—the function by which IST interval durations may be discerned from an IST time series is as follows:
2.8.1 Calculate Δt0—Subtract IST1—IST0 to learn the duration of interval Δt0 that starts at IST0.
2.8.2 Tentatively Assign Remaining Δtn—successively subtract ISTn−ISTn−1 to tentatively assign durations Δtn. The duration of Δt55 has been made unambiguous by appending IST56, which is the end of the last interval.
2.8.3 Perform Checks—certain checks may be possible on the structure of the tentative set of IST intervals. In this formulation, both the IST times and interval durations should increase or stay the same as one progresses through the series. The tentative set of intervals should be corrected if it does not pass these local checks. The system management layer may be employed to flag, alert, or announce failed checks, but it is the each local node's responsibility alone to produce and use a correct and accurate set of IST intervals.
Inputs:
Outputs:
Function/Process:
The process steps were described above as the sub-functions were being introduced. Refer to SubAppendix A for further details, pseudo code, and examples.
Dependencies:
Notes:
3. Formulate TIS
Purpose:
Process by which the TIS, one of the two transactive signals, is to be formulated at a transactive node. From its predecessors, this process receives parametric information that is used to determine how energy, capacity, infrastructure, and other influences are to be valued during formulation of the output TIS at this transactive node.
Applicability:
This process should be completed at the update frequency by transactive nodes. Some of the sub-functions and sub-processes within this process may be trivial or empty at transactive nodes where the sub-functions or sub-processes are not needed.
Sub-Functions and Sub-Processes:
3.1 Refresh Default Output TIS—simply retrieve the most recent output TIS from the Output TIS Buffer at this transactive node and refresh its time intervals by submitting it to function 3.10 Interpolate Intervals Service Functions. The resulting output TIS then returned to the Output TIS Buffer to be used by default if for any reason this transactive node does not compute a more current output TIS by the time it is used. This sub-function should be completed early during each duration. This potentially creates a race condition in software unless the update status of the buffer is maintained. Thus, in some embodiments, this should be used as a default value
3.2 Calculate Total Cost of Non-transactive Energy Generation and Imports—for each IST interval, sum the cost of imported and generated energy from sources that are not transactive neighbors at this transactive node. Examples include the costs of energy that is imported into the region from Canada, California, or other entities that are not participating in transactive control. Another example would be bulk generation from a gas generator that is dispatched in ways that are not affected by the region's transactive control and coordination system. The data that feed into this function will come from resource schedules and Incentive Toolkit Functions that are employed at this transactive node. This function becomes trivial and should not be used at transactive nodes that have neither non-transactive imports nor bulk generation.
The output from this function is the sum of products of pairs of energy costs CE,a,n (units: cost per energy) and average generated or imported power {circumflex over (P)}G,a,n (units: average power), weighted by the corresponding IST interval duration Δtn (units: time).
3.3 Calculate Total Cost of Energy Imported from Transactive nodes—for each IST interval, sum the cost of energy that is predicted to be imported from transactive neighbors. At times when energy is to be imported from transactive neighbors, the TIS & TFS from those transactive neighbors should be treated as special cases of imported energy and treated similarly to non-transactive imported energy (e.g., they result in (CE, PG) pairs). The cost of energy from a transactive neighbor is that neighbor's TIS. The predicted energy to be imported from that neighbor is the neighbor's TFS at the boundary between that and this transactive node. Exported energy to transactive neighbors should be disregarded in the calculation of the TIS. (In some embodiments, information about exported energy is found in the Resource Schedules and Cost Buffer. In such embodiments, Functions 3.2 and 3.3 can filter the buffer contents to address only imported energy, in which case the Resource Schedules and Cost Buffer is a complete rich source of information for data collection concerning the outputs of Toolkit Resource and Incentive Functions that are being employed at this transactive node.) It is conceivable that a transactive node could import no energy from its transactive neighbors, but the TFS shared with the neighbors should be checked nonetheless. (The prediction of energy to be exchanged to or from a transactive neighbor can be predicted by both neighbors, by one of the neighbors, or some other combination.)
As for sub-function 3.2, the output from this function will continue the sum of products of pairs of energy costs CE,a,n (TIS) (units: cost per energy) and average generated or imported power {circumflex over (P)}G,a,n (TFS) (units: average power), weighted by the corresponding IST interval duration Δtn (units: time).
3.4 Calculate Total Capacity Cost/Incentive—for each IST interval, sum the costs that are functions of a capacity. Constraints and demand charges are examples. These are expected to be very non-linear, but they will nonetheless be represented by a capacity cost and the capacity to which they apply. This function may be trivial or empty at transactive nodes where no capacity costs or incentives are to be included in the output TIS.
The output from this sub-function is the sum of products of pairs of capacity costs CC,b,n (units: cost per power capacity) and average power capacity {circumflex over (P)}C,b,n (units: average power) for each respective IST interval n.
3.5 Calculate Total Infrastructure Cost/Incentive—for each IST interval, sum the infrastructure (e.g., time-based) costs that should be applied during the interval. This function may be trivial or empty at transactive nodes where no infrastructure costs or incentives are to be included in the output TIS.
The output from this sub-function is the sum of products of pairs of infrastructure costs CI,c,n (units: cost per time) and the respective interval duration Δtn (units: time).
3.6 Calculate Total Other Cost/Incentive—for each IST interval, sum those influences that cannot be described by the energy, capacity, and infrastructure functions. (Other Cost/Incentive functions are desirably used infrequently for influences that cannot be described with the other functions. The representation of cost by this function should still be a defensible cost of delivered energy and will be subject to comparison against other cost accountings over relatively long time periods.) This function may be trivial or empty at transactive nodes where no other costs or incentives are to be included in the Output TIS.
The output from this sub-function is the sum of “Other” costs CO,d,n (units: cost).
3.7 Calculate Output TIS—a simple parametric function that combines outputs from above functions to complete calculation of the Output TIS for this transactive node. The sums completed by five other sub-functions appear in this sub-function. Details about this function are expanded upon in the Section 3.7 Details about the Calculate Output TIS Function.
3.8 Calibrate/Normalize TIS—algorithm by which the output TIS are to be compared against and perhaps made to track other cost accounting methods. If the calculation of a TIS is meaningful as the delivered cost of electrical energy, it should track other reasonable accountings of the delivered cost of electrical energy over relatively long periods of time. In some embodiments, this is a general requirement on the TIS. This general requirement may be enforced by a bias input that will force the TIS to track other less dynamic accountings and thereby correct the TIS.
3.9 Interpolate Intervals Service Functions—parse energy and costs from coarse intervals into multiple sub-intervals. This function is necessary because the set of IST intervals to be used by the output TIS will have divided some prior intervals into sub-intervals. This function is a service function that is called as often as it is desired. The objects TIS and TFS may simply be replicated for each sub-interval. (While many complex methods may evolve to interpolate and assign costs and average power to sub-intervals, in certain embodiments of the disclosed technology, the cost and average power from an interval are assigned to its sub-intervals.)
Inputs:
Interim Calculation Products:
Outputs:
Function/Process:
Each of the sub-functions/sub-processes should be defined, but sub-function 3.8 Calculate Output TIS defines the parametric calculation of the output TIS from the energy, capacity, infrastructure, and other parameters and how the parameters are to be applied. The implementer who understands sub-function 3.8 Calculate Output TIS will have the insight to formulate toolkit functions and will have considerable flexibility in the way such toolkit functions are formulated.
Dependencies:
Notes:
Details about the Function 3.7 Calculate Output TIS
Purpose:
Describes the final parametric calculation of the output TIS. This sub-function consists of a simply stated function of the sum products of other sub-functions 3.2 through 3.7. This sub-function creates a level of standardization that will help ensure that the TIS at distributed points in a transactive control and coordination system are defensible representations of the “delivered cost of energy.”
Applicability:
A sub-function of 3. Formulate TIS Process that should be calculated at the update frequency at transactive nodes.
Sub-Functions and Sub-Processes:
None. This is a simple arithmetic function of sums that have been calculated by sub-functions 3.2 through 3.7.
Inputs:
from sub-functions 3.2 Calculate Total Cost of Non-Transactive Energy Generation and Imports and 3.3 Calculate Total Cost of Energy Imported from Transactive nodes
from sub-function 3.4 Calculate Total Capacity Cost/Incentive
from sub-function 3.5 Calculate Total Infrastructure Cost/Incentive
from sub-function 3.6 Calculate Total Other Cost/Incentive
that is predicted to be imported and/or generated at this transactive node as has been calculated in function 10. Sum Total Predicted Resource.
Outputs:
Function/Process:
This sub-function simply adds the individual cost summations from sub-functions 3.2, 3.3, 3.4, 3.5, and 3.6 and divides that sum by the total energy that is imported into or generated within the boundaries of this transactive node as was summed by sub-function 3.7:
The function shown above for interval n should be performed for all intervals that are to be used by the Demonstration for its transactive signals.
Dependencies:
Notes:
4. Formulate TFS
Purpose:
Formulate one current transactive feedback signal (TFS) for the electrical interface between this transactive node and each of its transactive neighbors.
Applicability:
This process should be completed at the update frequency by transactive nodes.
Sub-Functions and Sub-Processes:
4.1 Interpolate Intervals Service Functions—function, or set of functions, by which the inputs to this process may be restated using the current interval start time (IST) series. If input time series are found to use dated time intervals or any other representation of future intervals other than the current IST series, this function should be called until the dissimilarities are resolved. This function should also be called early during an update interval iteration to create updated, default versions of a recent prior transactive feedback signals (TFS) that may be used if, for any reason, this transactive node fails to formulate a TFS by the time it is used.
4.2 Predict Net Resource Surplus or Shortage—take the difference between total resource from A resources and total load supplied by this transactive node to determine the net surplus or shortage for each future interval n. The net surplus or shortage is the average power over an interval that should be sent to or received from transactive neighbors during that interval—an imbalance anticipated to occur at this transactive node. Therefore, the net surplus or shortage should equal the sum of all changes to the TFS for each interval at this transactive node.
Total average load at each interval Σ{circumflex over (L)}n is a calculated input that should be retrievable from the Predicted Inelastic and Elastic Load Buffer. The total resource
is a calculation available from the Total Predicted Resource Buffer, a product of 10. Sum Total Predicted Resource. (Desirably, there is a connection between this calculated imbalance and resource planning.)
4.3 Disaggregate Net Resource Surplus or Shortage—allocate the net resource surplus or shortage among this transactive node's transactive neighbors by formulating or modifying the TFS for each such interface. The newly formatted TFS are then stored into the Output TFS Buffer.
Today, this prediction would rely on centralized power-flow solvers. In a fully distributed system, however, new prediction tools can be used.
This transactive node object should supply to this sub-function the current list of transactive neighbors for which TFS should be calculated. It may also provide simple ratios or detailed topological information that can be used eventually to predict load flow between this transactive node and its transactive neighbors, e.g., TFS series. Current information about the transactive node object is assumed to be available from a Node State and Status Buffer.
4.4 Refresh Default Output TFS—early during each IST update interval, this process should refresh the last calculated versions of TFS found in the Output TFS Buffer and restate them using the current IST series. Thereafter, the restated, refreshed TFS may be returned to the buffer and used as default values if, for any reason, this transactive node should fail to formulate the current TFS by the time they are used.
Inputs:
at each future interval n of the current IST series. (This is now calculated by a sub-function of this process, but it can be made available from a common buffer of the toolkit framework.) This input should be available from the Total Predicted Resource Buffer.
Outputs:
Function/Process:
Refer to the descriptions of the sub-functions above as the sub-functions were being introduced.
Dependencies:
Notes:
5. Sum Total Predicted Load
Purpose:
Process to add the total inelastic (non-transactive) and elastic (transactive) electrical load components being supplied within the boundaries of this transactive node. (In the illustrated embodiment, electrical energy that is to be exported outside the boundaries of a transactive node is not part of this sum.)
Applicability:
This function applies to transactive nodes and should be updated at the update frequency; however, this process becomes trivial for transactive nodes that supply no elastic electric load, no inelastic electric load, or neither elastic nor inelastic electric load within the boundaries of the transactive node.
Sub-Functions and Sub-Processes:
5.1 Interpolate Intervals Service Functions—suite of functions that may be called upon should any inputs to this function note yet exist using the current set of interval start times that should be available from the Current IST Series Buffer.
5.2 Sum Inelastic Load—sums the entries in the Inelastic Load Prediction Buffer that are relevant to the current update interval iteration.
The Inelastic Load Prediction Buffer may (or may not) have a multiplicity of relevant entries that should be summed. For example the buffer might possess a bulk load prediction that is simply based on historical trends over the past week, the inelastic prediction for a large water heater responsive asset system, and the inelastic prediction for a voltage-response asset. (In certain embodiments, care should be taken not to double count any of the load as this sum is taken.) For each of this component addends k, the buffer should possess a relatively current entry Linelastic,k. Each entry should state average load (unit: average power) to be consumed (or generated) by it during each of a series of intervals.
If an entry from the buffer is found to have intervals other than those in the current IST series, function 5.1 Interpolate Interval Service Functions should be called upon to resolve the discrepancy and restate the entry contents using the current IST interval set.
Ideally, all current, relevant contents of the buffer will be evident from the entries' interval start time IST0 time. Preferably, the buffer contents that are to found and summed by this sub-function for each iteration should be attributes of this transactive node, knowable from the contents of the Node State and Status Buffer.
The output product of this sub-function is a single time series ΣLinelastic,n that has summed components k.
5.3 Sum Change in Elastic Load—sums the entries in the Toolkit Response Function Output Buffer that are relevant to the current update interval iteration. If toolkit functions have been employed for responsive asset systems at this transactive node, one or more entries will be found in the buffer to be summed in this sub-function. Note that only the change in elastic load is to be found in the buffer and summed for each interval start time interval by this sub-function. For each of this component addends j, the buffer should possess a relatively current entry ΔLelastic,j. Each entry should state the change in average load (unit: average power) it predicted to be consumed (or generated) by it during each of a series of intervals.
If an entry from the buffer is found to have intervals other than those in the current IST series, function 5.1 Interpolate Interval Service Functions should be called upon to resolve the discrepancy and restate the entry contents using the current IST interval set.
As was the case for sub-function 5.3 above, the contents of the buffer that are to found and summed by this sub-function for each iteration should be an attribute of this transactive node, knowable from the contents of the Node State and Status Buffer.
The output product from this sub-function is a single time series ΣΔLelestic,n that has summed components j.
5.4 Sum Total Inelastic and Change in Elastic Load—function by which total inelastic load predictions and predicted changes in elastic load are finally summed to calculate a total to be placed into the Predicted Total Inelastic and Elastic Load Buffer. This function completes the simple arithmetic sum
ΣLtotal,n=ΣLinelastic,n+ΣΔLelestic,n, (Function 5.)
where ΣLtotal,n is the sum of total inelastic load ΣLinelastic,n and total change in elastic load ΣΔLelastic,n for IST interval n at this transactive node.
5.5 Refresh Predicted Total Inelastic and Elastic Load—succeeding calculations will expect that the predicted total inelastic and elastic load will be available according to current IST intervals. Therefore, early in each update interval interation, the most current representation of that sum should be located within the Predicted Total Inelastic and Elastic Load Buffer and subjected to function 5.1 Interpolate Intervals Service Functions to recast the buffer contents into a default buffer entry that uses the current set of interval start times (IST). If for any reason this transactive node fails to later update its prediction of the sum into the buffer, the default value may be used instead.
Inputs:
Outputs:
Function/Process:
The steps of this process were stated above with the introductions of sub-functions. Overall, the process completes the simple arithmetic sum
ΣLtotal,n=ΣLinelastic,n+ΣΔLelestic,n, (Function 5)
where ΣLtotal,n is the sum of total inelastic load ΣLinelastic,n and total change in elastic load ΣΔLelastic,n for IST interval n at this transactive node.
Dependencies:
Notes:
6. Calculate Applicable Toolkit Load Functions
Purpose:
This process block represents from zero to many specific toolkit library functions that may be incorporated into the toolkit framework here. The toolkit functions that become instantiated at this location should represent and predict elastic and inelastic loads and should result in a reasonably complete and accurate prediction of the entire load that is supplied within the boundaries of this transactive node during each IST interval.
Most generally, these toolkit functions may be characterized by their inputs and outputs and by their generalized functional responsibilities within the toolkit framework. A template is developed for the specification of toolkit functions (see SubAppendix B). Owners of transactive nodes, who represent the unique perspective under which this transactive node should be managed, should select and/or help create specific toolkit function(s) that model the responsive asset systems and inelastic loads that they have or plan to implement. See Table 25 for an example list of toolkit load functions.
Modular toolkit functions may be implemented and shared via combinations of their functional descriptions, pseudo code implementations, and reference code, all of which are recommended components of the recommended toolkit function template.
The location of this block within the toolkit framework is intended for toolkit functions that predict the behaviors of two different types of loads:
Of interest are those responsive asset systems that can be applied to the transactive control and coordination system. (In certain embodiments, responsive asset systems have been defined to be applied within reliability or conservation and efficiency test cases as well. Not all responsive asset systems are being used in the transactive control and coordination system test cases.) A toolkit function should be defined for each unique implementation of each major type of responsive asset system. Each toolkit function should first calculate the inelastic load Lm, which predicts when and how much energy the responsive asset system would consume if it were not influenced by the output TIS. The prediction of inelastic load component is placed into the Inelastic Load Prediction Buffer. The toolkit function should then predict the change in elastic load ΔLm that is caused by the condition of the output TIS. The prediction of elastic load component is placed into the Elastic Load Prediction Buffer. It is acceptable that the elastic load components may be zero during intervals when the responsive asset system is not predicted to be engaged by the output TIS.
Another output from a toolkit function should be a representation of the planned control action by which the responsive asset system will be induced to change its energy consumption in light of the state of the output TIS for each interval. For example, some responsive asset systems may be either active or curtailed (e.g., populations of water heaters), in which case a binary indicator might be used for each interval. Other systems are able to enter any of multiple discrete levels of response (e.g., GE smart appliances), in which case one of several discrete levels should be specified for each interval. Still other systems may provide a continuum of possible responses and use a representation of percentage. (An interesting example of this continuum of responses will occur where customers are provided a means to view the output TIS itself on an in-home display and respond correspondingly with a continuum of behavioral responses.) Eventually, as time marches toward the interval of interest and the interval becomes that of IST0, the responsive asset system should be expected to take the predicted, prescribed action. The implementations of responsive asset systems will be diverse, but it is in the representation of these predicted, planned control actions where standardization may be particularly useful.
An example would probably be useful concerning the portion of predicted load that should be included in this process from elastic loads, including responsive asset systems. Electrical consumption by a set of electric water heaters may be predicted quite well from measured trends and models of the water heaters and their owners' behaviors. The input information or parameters that influence such trends and models might include time of day, day of week, occupancy, outdoor temperature, and average outdoor temperature, for examples. In the toolkit framework, these pieces of information or parameters are referred to as other local conditions that should be available inputs if the transactive node is to accurately predict the load consumed by the water heaters. These predictions are to be completed within this process 6. Predict Applicable Toolkit Load Functions. The predicted load should be recorded for each such system in the Inelastic Load Prediction Buffer. If upon receipt of the current output TIS the water heaters would reduce their load, the change (e.g., only the change) would be predicted in a parallel calculation path and would be stored into the Elastic Load Prediction Buffer.
Toolkit functions can used to describe behaviors of individual devices. But the responsive asset systems of the Demonstration are primarily used for populations of devices. It is the statistical behavior of the populations, not individual devices that should be predicted.
Inelastic load components are similarly incorporated via their toolkit functions; however, no elastic load component should be created by these functions. Candidate inelastic load predictions might include feeders of residential customers, where the load of the population could be predicted from the time of day, average home square footage, average house age, outdoor temperature, and perhaps still other local conditions.
Regardless of whether a given toolkit function describes an elastic or an inelastic load, a load should never appear on both the resource and load sides of the toolkit framework formulation for any single interval n. Responsive asset systems may be either electrical loads or resources. Regardless, the toolkit functions whose influence is to be inserted at this location will affect the formulation of the TFS but will not directly influence the formulation of the output TIS. Responsive asset systems that should affect the delivered cost of energy (e.g., the TIS) at this transactive node should be inserted at location 8. Calculate Applicable Toolkit Resource Functions instead.
Using the above-stated criterion, the average power from a customer's renewable generator should probably be treated as a “negative” load (e.g., its toolkit function should be incorporated here) if it will never result in net metering. But if the utility at any time pays the customer net-metering payments for surplus energy that is produced by the resource, the resource should be included instead among resources, not loads, so that the net-metering charges may influence the formulation of the TIS (e.g., a toolkit function should be included for this system in the process 8. Calculate Applicable Toolkit Resource Functions).
Using the same reasoning, the present process should not predict bulk generation resources that are scheduled at this transactive node because costs should almost certainly be applied to the energy from such bulk resources.
The influences of elastic and inelastic load components should never be double counted. The influence of a load should appear only once if an accurate prediction of total load is to be formulated by this transactive node.
Toolkit functions may include learning algorithms and other means to improve the accuracy of their load predictions over time, but such complexities should be weighed against the Demonstration's desire to create and teach and implement these toolkit functions with its participants and within a tight development schedule.
See Table 25 for a list of example toolkit load functions.
Applicability:
Any toolkit functions to be called upon in this process block should be called at the update frequency. It is conceivable but unlikely that a transactive node may have neither inelastic nor elastic load components that necessitate any toolkit functions be called within this process block.
Sub-Functions and Sub-Processes:
6.1 Interpolate Intervals Service Functions—a suite of service functions that may be called upon as they are desired to restate dated time series in terms of the current IST intervals. (These functions might be defined and used throughout the entire toolkit framework instead of uniquely defined for each process, as has been shown here.)
6.2m Toolkit Load Function—from zero to many individual toolkit functions from a toolkit function library that predict inelastic load and change in elastic load for each interval of the current IST series. Enough such toolkit functions should be incorporated and called upon to predict the entire load at this transactive node. Individual toolkit functions may be created or selected from a toolkit function library predict the behaviors of a responsive asset system; the behaviors of a group of inelastic loads; generation from small distributed generation resources that do not directly influence the formulation of the TIS; or large nebulous groups of ill-defined loads that can only be characterized by their historical trends.
It should be assumed that the list of M relevant toolkit functions are identified and known by this transactive node object and is available from the Node State and Status Buffer. Furthermore, the buffer should identify the sets of other local conditions inputs expected to be available to the M toolkit functions from the Toolkit Load Function Input Buffer.
A toolkit function should output its prediction of inelastic load into the Inelastic Load Prediction Buffer for the load being described and for a current IST interval. (The inputs expected by toolkit functions will be varied and may be dynamic.) If the function models and helps control responsive, elastic loads, the function should also create and output the planned control for the responsive load. A standardized advisory control signal to be sent to the responsive asset systems has been formulated and is available in SubAppendix C.
6.3 Refresh Predicted Inelastic Elastic Loads—early each update interval iteration, the most current contents of the Inelastic Load Prediction Buffer and Elastic Load Prediction Buffer should be retrieved by this sub-function and restated using 6.1 Interpolate Intervals Service Functions in terms of the current IST interval set. These updated buffer contents are then available to be used by default should this transactive node fail for any reason to calculate its load for the current iteration.
Inputs:
Outputs:
Function/Process:
Sub-functions 6.1 and 6.3 were described as they were being introduced in the text above. This document has stated functional responsibilities and an input/output model for the multiplicity of toolkit functions 6.2m Toolkit Load Function that are to be called upon during this process. Each toolkit function should use the provided template and should describe for itself what it is meant to accomplish within the functional responsibilities, inputs, and outputs that have been generally described here.
Dependencies:
Notes:
7. Send Transactive Signals
Purpose: Method by which output transactive signals are conveyed from this transactive node to each one of its transactive neighbors. Most generally, there will be no single approach to completing this process because transactive is tied to no single communication technology, medium, or protocol. Transactive neighbor pairs should negotiate and agree upon these details. On the other hand, the Demonstration has elected to convey transactive signals almost exclusively via secure Internet.
Applicability:
An process that should be completed at the update frequency by a transactive node.
Sub-Functions and Sub-Processes:
The following high-level responsibilities should be addressed, regardless of the platforms on which it is designed:
Inputs:
Outputs:
Dependencies:
Notes:
This function or process is also useful from a cyber-security perspective. Both the senders and recipients of transactive signals should be satisfied that their systems will remain safe from attack.
8. Calculate Applicable Toolkit Resource and Incentive Functions
Purpose:
A multiplicity of toolkit functions may be applied at this location within the toolkit framework to address resources and incentives. Toolkit functions should be created or selected from a toolkit library to represent the energy resources and incentives that are be applied at this transactive node during each IST interval. The costs that are calculated by the toolkit functions in turn may incentivize or disincentivize consumption and generation of electricity through their effects on the transactive incentive signal.
See Table 25 for a list of example toolkit resource and incentive functions. Refer to SubAppendix B for a template that may be used to specify additional toolkit resource and incentive functions as they are developed.
Applicability:
A transactive node should calculate at least one toolkit function at the update frequency.
Sub-Functions and Sub-Processes:
8.1 Interpolate Intervals Service Functions—a suite of service functions that can accept stale, dated data and restate the data in terms of the current IST interval series. (These functions might be defined and used throughout the entire toolkit framework instead of uniquely defined for each process, as has been shown here.)
8.2 Refresh Predicted Resources and Incentives—Early during each update interval, this sub-function retrieves the most recent entries from the Resource Schedules and Cost Buffer and restates the records in terms of the current IST series. If for any reason this transactive node fails to complete the present process by the time its outputs are used, the restated records may be used as default records.
8.3 Assign Energy Cost and Average Power—a sub-function of a toolkit resource and incentive function in which cost CE,a,n (units: cost per energy) is assigned to each component a of energy {circumflex over (P)}G,a,n (units: average power) that is either imported into or generated within the boundaries of this transactive node. In particular embodiments, one responsibility of a toolkit resource and incentive function is to calculate and report one of each of these two quantities for each current IST interval n. Either of the calculated quantities may be zero. The calculated values will differ depending on selected toolkit function and the resource or effect that is being modeled by the selected toolkit function.
Example energy costs and energies that that should be captured using this sub-function include
The values CE,a,n should be defensible representations of the delivered costs of energy {circumflex over (P)}G,a,n.
The sum of {circumflex over (P)}G,a,n should represent the energy that is generated within or imported into this transactive node during IST interval n.
This sub-function may call upon various defined other local conditions that should be available as inputs from the Resource and incentive Input Buffer. The list of other local conditions that are expected by a give toolkit function should be known by the transactive node object and available from the Node State and Status Buffer.
Refer to sub-function 3.7 Calculate Output TIS to fully understand how the two outputs from the present sub-function will become incorporated into the formulation of TIS within the toolkit framework.
8.4 Assign Capacity Cost and Capacity—a sub-function of a toolkit resource and incentive function in which cost CC,b,n (units: cost per power) is assigned to capacity limitations and costs that are triggered by capacities. The sub-function also captures the capacity {circumflex over (P)}C,b,n (units: average power) to which the cost applies. In certain embodiments, one responsibility of a toolkit resource and incentive function is to calculate one of each of these two quantities for each current IST interval n. Either of the calculated quantities may be zero. The calculated values will differ depending on selected toolkit function and the resource or effect that is being modeled by the selected toolkit function.
Example capacity costs that should be included through this sub-function include
Cost CC,b,n should be defensible as cost that will be incurred upon a corresponding capacity {circumflex over (P)}C,b,n that is predicted to occur during IST interval n.
This sub-function may call upon various defined other local conditions that should be available as inputs from the Resource and incentive Input Buffer. The list of other local conditions that are expected by a give toolkit function should be known by the transactive node object and available from the Node State and Status Buffer.
Refer to sub-function 3.7 Calculate Output TIS to fully understand how the two outputs from the present sub-function will become incorporated into the formulation of TIS within the toolkit framework.
8.5 Assign Infrastructure Cost—a sub-function of a toolkit resource and incentive function in which cost CI,c,n (units: cost per time) is assigned to the provision of infrastructure at this transactive node, which costs are usually spread over quite long periods of time. In certain embodiments, one responsibility of toolkit resource and incentive function is to calculate and report one infrastructure cost output for each current IST interval n. Its value may be zero. The calculated value will differ depending on selected toolkit function and the resource or effect that is being modeled by the selected toolkit function.
Example infrastructure costs that may be used through this sub-function include
Refer to sub-function 3.7 Calculate Output TIS to fully understand how the output from the present sub-function will become incorporated into the formulation of TIS within the toolkit framework.
8.6 Assign Other Costs—a sub-function of a toolkit resource and incentive function in which other costs (units: cost) that cannot be represented by the other sub-functions are applied at this transactive node. In certain embodiments, one responsibility of a toolkit resource and incentive function is to calculate and report one such other cost output for each current IST interval n. Its value may be zero. The calculated value will differ depending on selected toolkit function and the resource or effect that is being modeled by the selected toolkit function.
This sub-function should not be used to bypass the other three sub-functions 8.3, 8.4, and 8.5. The other cost that is assigned by this sub-function should be a defensible component of the delivered cost of energy (e.g., the TIS) that will be formulated by process 3. Formulate TIS.
Refer to sub-function 3.7 Calculate Output TIS to fully understand how the output from the present sub-function will become incorporated into the formulation of TIS within the toolkit framework.
Inputs:
Outputs:
Function/Process:
The sub-functions were described above as they were being introduced. Sub-functions 8.3, 8.4, 8.5, and 8.6 are components of toolkit functions and may not be generically defined except through the characterization of their inputs and outputs.
Dependencies:
Notes:
9. Control Responsive Asset Systems
Purpose:
Advise responsive asset systems of the actions that they should take during the present update interval in accordance with their planned responses for the current interval start time IST0.
Applicability:
This process should be completed at the update frequency by a transactive node that has at least one responsive asset system installed and responsive to the transactive control and coordination system.
Some transactive node owners will impose constraints on the dynamics with which their responsive asset systems may act, in which case this process may be completed less frequently than the update frequency. For example, certain responsive asset systems may be engaged only at the top of an hour and may remain engaged for minimum durations after that. Still others should be scheduled some time prior and are therefore not responsive to the update frequency. (The capabilities of various responsive asset systems are desirably addressed in the selected toolkit library functions 6.2m Toolkit Load Function.)
Sub-Functions and Sub-Processes:
None. This process may be only described at a functional level due to the diversity of the responsive asset system that is to be controlled. Most of the actual control activities take place within the responsive asset systems themselves and according to the preferred practices of this transactive node's owner.
Inputs:
Outputs:
Function/Process:
The process by which the advisory output found within the Elastic Load Prediction Buffer is to be converted into control actions for the present update interval will be quite unique to the responsive asset system and will take place within the system according to practices of this transactive node's owner.
Dependencies:
If this transactive node possesses any responsive asset systems, then
Notes:
State and Status Buffer.
10. Sum Total Predicted Resources
Purpose:
Sum the total energy resources entering the boundaries of this transactive node. The transactive node that has A resources
The sum produced by this process is used for two purposes in the toolkit framework: First, it is the divisor in process 3. Formulate TIS. Second, during process 4. Formulate TFS it is compared against the total load that is calculated by process 5. Sum Total Predicted Load, resulting in the net surplus or shortage of energy that should be allocated among the TFS of of transactive neighbors.
Applicability:
This process should be completed at the update frequency by a transactive node.
Sub-Functions and Sub-Processes:
10.1 Interpolate Intervals Service Functions—a suite of service functions that may be called upon as they are desired to restate dated time series in terms of the current IST intervals. (These functions might be defined and used throughout the entire toolkit framework instead of uniquely defined for each process, as has been shown here.)
10.2 Sum Total Predicted Resource—sum of the A resources {circumflex over (P)}G,a,n (units: average power) for each IST interval n. This sub-function should find a current representation of each summand from within the Resource Schedules and Cost Buffer. The expected set of summands should be known to this transactive node object and available from the Node State and Status Buffer. The sum should include electrical energy that is either generated within or imported into the boundaries of this transactive node during each IST interval n. Each of the summands should be found paired with an energy cost parameter CE in the Resource Schedules and Cost Buffer.
Summands {circumflex over (P)}G,a,n should include and represent
The output product from this sub-function is a single time series (units: average power) placed into the Total Predicted Resource Buffer each update interval.
10.3 Refresh Predicted Total Resource—early each update interval iteration, the most current contents of the Total Predicted Resource Buffer should be retrieved by this sub-function and restated using 10.1 Interpolate Intervals Service Functions in terms of the current IST interval set. These updated buffer contents are then available to be used by default should this transactive node fail for any reason to calculate total resource for the current iteration.
Inputs:
Outputs:
(units: average power) stored into the Total Predicted Resource Buffer. This output is a series of values, one for each IST interval.
Function/Process:
The purpose of this process is to perform a mathematical sum, which has been described above as the sub-functions were being introduced.
Dependencies:
Notes:
This process was originally considered as a sub-function within both processes 3 and 4. Because both processes performed the identical function, the function was elevated to a process at the toolkit-framework level so that the same sum may be used by both processes 3 and 4.
11. Control Responsive Resource
Purpose:
Advise responsive resources of the actions that they should take during the present update interval in accordance with their planned responses for the current interval start time IST0.
Applicability:
This process should be completed at the update frequency by a transactive node that has at least one responsive resource. This process will be used infrequently until resources like bulk generators become responsive to a dynamic transactive control and coordination system.
Some resource owners will impose constraints on the dynamics with which their resources may act, in which case this process may be completed less frequently than the update frequency.
Sub-Functions and Sub-Processes:
None. This process may be only described at a functional level due to the diversity of the resources that are to be controlled. Most of the responsibilities to engage resources lie with the resource systems themselves and not with processes of the toolkit framework.
Inputs:
Outputs:
Function/Process:
The process by which the advisory output found within the Resource Schedules and Cost Buffer is to be converted into control actions for the present update interval will be quite unique to the responsive resource system and will take place within the system according to practices of the resource and transactive node owners.
Dependencies:
If this transactive node possesses any responsive resource systems, then
Notes:
This section recommends a specific set of 57 Interval Start Times (IST) for use in example embodiments of the disclosed technology, including the Demonstration. The intervals range in duration from 5 minutes to 1 day. In this embodiment, the 57 ISTs define 56 intervals of varying duration, though other numbers of IST and different durations can be used.
The first interval in a set of Interval Start Times is IST0. While a transactive signal is being formulated, IST0 is the next future time at which the minute hand of a clock will be at one of the 12 major divisions of an hour (e.g., on the hour, 5 minutes after the hour, 10 minutes after the hour, etc.).
The series of time intervals to be used by transactive signals during the Demonstration are as defined in Table 26. This set of 56 intervals is easily specified, creates the same numbers of intervals, exhibits increasing coarseness into the future, and will align well with dynamic market signals that are up to 1 hour in duration. Note that a 57th IST (e.g., IST56) has been added to unambiguously define the duration of the final, 56th interval.
One variable-length interval resides at the boundary between sets of intervals having different durations. That is, there is a variable-length interval between 5- and 15-minute intervals, between 15-minute and 1-hour intervals, between 1- and 6-hour intervals, and between 6-hour and 1-day intervals. The duration of each variable-length interval varies between the durations of the two bounding intervals, inclusive. No intervals overlap in the resulting representation of the future.
Five-minute intervals are to be used 1 hour into the future; 15-minute intervals, 6 hours into the future; 1-hour intervals, 1 day into the future; 6-hour time intervals, 2 days into the future, and 1-day intervals, 3 to 4 days into the future.
The intervals of several time series that adhere to this recommendation are shown in Table 27 for several example values of IST0.
The following formula guides the calculation of the IST series according to the specification in Table 26. The interval start times use the notation
ISTn[ddn,hhn,mmn], (A1)
where “dd” is days, “hh” is hours, and “mm” is minutes. The value n refers to the sequential, ordered number of the IST in its series. The total number of intervals in the series is N=56, where N is the last n.
IST≐{IST0,IST1,IST2, . . . ,ISTn, . . . ,ISTN} (A2)
The following steps and pseudo code should help standardize calculation of the members of an IST time series. The function “truncate( )” indicates that the decimal parts of the result in the parentheses should be discarded.
(1) Calculate first element IST0:
Read present time t
Set IST0=t+0:05
Set mm0=5*truncate (mm0/5)
(2) Calculate the IST series for remaining 5-minute intervals:
For n=1 to 11
(3) Calculate the IST series for 15-minute intervals:
Set IST12=IST11+0:15
Set mm12=15*truncate(mm12/15)
For n=13 to 31
(4) Calculate the IST series for 1-hour intervals:
Set IST32=IST31+1:00
Set mm32=0
For n=33 to 49
(5) Calculate the IST series for 6-hour intervals:
Set IST50=IST45+6:00
Set hh50=6*truncate(hh50/6)
For n=51 to 53
(6) Calculate the IST series for 1-day intervals:
Set IST54=IST53+1:00:00
Set hh54=0
Set IST55=IST54+1:00:00
(7) Append the final IST that indicates the end of the last 1-day interval:
Set IST56=IST55+1:00:00
Table 27 lists the 57 IST time series elements for 13 example values of IST0. The number of intervals (56 for the Demonstration) and total described time duration, listed at the bottom of Table 27 for these examples, have been adopted as additional elements of the XML schema that has been designed for the Demonstration's transactive signals.
This example template can be completed for each toolkit function and can be posted to a common library. The following template items are used in this template:
Each toolkit function that models a system of responsive assets is responsible to advise the system of assets when and to what degree it should respond. Each such toolkit function should therefore calculate a time series that states a degree of response for each current interval start time (IST). The recommendation has been summarized in
The following advisory signal format can be used as a standard for toolkit functions. This method accommodates advisory responses from binary (curtailed vs. normal) to several discrete levels (e.g., response level #1, response level #2, . . . ) to a continuum of possible responses (e.g., generate at 56% of nameplate capacity for the specified interval).
The advisory signal has been defined as a signed value to allow its application to responsive loads, responsive generation, and energy storage resources. Positive values are used when the recommended control action should increase the availability of energy by either increasing generation or by reducing load; a negative number is used when the recommended control actions should reduce generation or increase load.
The signal is quite intentionally defined in respect to a byte representation. The three most significant bits have been highlighted in
1. A signed byte value is assumed (e.g., a signed 8-bit representation [−127, 127]). (For symmetry, the value −128 has not assigned. In gate logic, the use of one's complement interpretation of negative numbers accomplishes this symmetry and may be advantageous especially for controlling very simple, small assets.)
2. Positive values refer to generation [0, 127]; negative values refer to load [−0, −127].
3. The toolkit function is responsible to state a response level for each future interval, consistent with its modeled influences on transactive signals. If the asset system's number of available response levels is known with certainty at the time the toolkit function is selected, the toolkit function may prescribe a representation for each response level.
4. The asset system, or alternatively “glue” code between the toolkit function and the asset system, is responsible to interpret the advisory signal. Interpretation of the advisory signal should be made by first dividing the respective generation or load range by the number of response levels that are available from the responsive asset system. Then the asset system may determine into which of its available levels the advisory signal belongs. If a continuum of available responses exists for this asset system, the full range of the continuum should be meaningfully applied to the full nameplate rating or total population, such that the signal range is applied to the entire available resource or load range.
Suppose toolkit load function TKLF_1.4 has been selected to model the behavior of a set of wind turbines. The behaviors of these wind turbines are not elastic and would therefore not be expected to change their operations in respect to transactive control. This toolkit function should not calculate and send any advisory control signal to the set of wind turbines. The set of wind turbines should not expect to receive any advisory control signals.
A toolkit load function is being designed to model a system of demand responsive water heaters. The system of water heaters should be curtailed as a group. One of the outputs from the toolkit load function is designed to be a time series of advisory signals selected from the domain {0, 127}, which members represent normal and curtailed operation, respectively, for this load. (In certain implementations, and as discussed herein, a series of 56 intervals can be used, where each interval is defined by its interval start time (IST). See, e.g., Subappendix A.) The selection of the extreme advisory signals for a load having only two levels is wise because the signals will prescribe a reasonable binary response regardless of the capabilities of the asset system to which the signal is sent. The curtailable water heater system looks for signals in the ranges [0, 63] (normal operation) or [64, 127] (curtailed operation). The range [−0, −127] should be ignored (e.g., normal operation) by this responsive asset system because it can only curtail its load; it cannot increase its load in response to transactive control signals.
A toolkit load function is created for a small residential battery storage system that has only three available response levels—fully charging, resting, and fully discharging. The function should state a time series of advisory signals to the battery system, perhaps specifying from among a set of three outputs in the set {−127, 0, 127}, which represent the three states fully charging, resting, and fully discharging, respectively. The battery system should be configured to expect one of three ranges of advisory signals [−127, −64] (charging), [−63, 63] (resting), or [64, 127] discharging.
Another toolkit load function is created to model a battery storage system, but this function expects to be paired with a battery system that can operate through a continuum of responses from fully charging to fully discharging. The function creates advisory signals accordingly at any integer value in the range [−127, 127]. The battery system converts these numbers into percentages of its range of charge and discharge rates, which is done easily by dividing through by the integer 127. For example, the advisory signal value 26 is converted to 26/127, or 20.5% of its full available discharge rate.
The small battery system of Example #3 is paired with the toolkit load function of Example #4. Even though the toolkit function calculates a continuum of responses, the battery system that has only three available response levels may nonetheless respond sensibly to the advisory signal that it receives. However, because the asset's responses do not match the responses that will have been modeled by the toolkit function, the toolkit function will not correctly predict the load (and generation) that will be supplied by this battery system.
This subappendix lists and describes example toolkit functions that can be implemented in embodiments of the disclosed technology. Two types of toolkit functions have been defined:
(1) Resource and incentive toolkit functions—used to capture the influences of energy resources and other influences upon the transactive control and coordination system's incentive signal (e.g., the TIS)
(2) Load functions—used to capture the influence of both elastic (e.g., “responsive”) and inelastic loads on the transactive control and coordination system's feedback signal (e.g., the TFS).
SubAppendix B provides a template by which the toolkit functions themselves and specific reference implementations of the toolkit functions should be documented. Thereafter, these toolkit functions may be selected from a “library” of such available toolkit functions and applied at any applicable transactive nodes.
The outputs of toolkit functions constitute an interoperability boundary as the project strives to standardize the information that flows from the toolkit functions into the toolkit framework at many levels of an interoperability information stack.
The example resource and incentive toolkit functions listed in Table 28 are defined and represent as instantiations of 8. Calculate Applicable Toolkit Resource and Incentive Functions within the toolkit framework. Toolkit functions having the same name and number should share a common purpose and same general approach and should promise the same set of outputs into the toolkit framework. Versioning may be used for variants of these functions that differ slightly in approach, in complexity, or by the nature of expected inputs.
In Table 28, an attempt was made to organize the functions by type and level. Following this enumeration, Function 1.1.1 would be a special implementation of Function 1.1, which is a special implementation of Function 1.0.
Each toolkit function should be defined by appropriate documentation following the template in SubAppendix B.
Load toolkit functions are instantiated as 6. Calculate Applicable Toolkit Load Functions within the toolkit framework. The load being described by these functions may be either elastic (responsive to the TIS) or inelastic (not responsive to the TIS). These functions should not have direct influence and effect on the calculation of TIS as this transactive node; functions that will affect the formulation of TIS should be stated as resource or incentive toolkit functions.
The Demonstration attempts to define and use a minimum adequate set of load toolkit functions. Therefore, implementers should select and apply the most general function that can describe the expected behaviors. In Table 29, an attempt was made to organize the functions by type and level. Following this enumeration, Function 1.1.1 would be a special implementation of Function 1.1, which is a special implementation of Function 1.0. Function 1.0 is more general that is the Function 1.1 under it.
The most general functions have been stated as
1. Bulk inelastic load—large sets of load that is not affected by the TIS
2. General event-driven demand response (DR)—sets of asset systems that are infrequently affected by the TIS. These asset systems are affected in a binary, on/off way or occasionally provide a limited number of discrete response levels. Specific examples may include distribution voltage control, water heater programs, smart appliance programs, and distributed generation.
3. General time-of-use (TOU) DR—sets of asset system that are affected by the TIS according to a daily cycle. These asset systems are affected in a binary, on/off way or occasionally provide a limited number of discrete response levels. Examples may include distribution voltage control, water heater programs, smart appliance programs, and battery storage.
General real-time (RT) DR—sets of asset systems that are affected by the TIS and employ a continuum of possible responses. Examples may include energy portals and battery storage.
This section introduces a variety of exemplary load and incentive functions, any one or more of which can be used in embodiments of the disclosed technology (e.g., in a toolkit library).
The functions described below should not be construed as limiting in any way, and are example implementations of functions that can be used in a transactive control and coordination system. Further, the equations, tables, and subappendices in the function descriptions below will have their own independent numbering and labeling conventions. Still further, in some instances, some information may be omitted from certain functions but could be implemented by those skilled in the art.
Description:
The following is the foundation of an alternative toolkit function to 1.0 Bulk Inelastic Load. However, this functional specification can be implemented with initial measurements over only two prior days, expects less mathematical knowledge by implementers, is easily documented down to requisite steps, and, for these reasons, may be more amenable to implementation by some utility implementers.
The basic approach is as follows: For a given circuit location, pairs of electrical load and ambient temperature are measured each hour. Data from the same hour-of-day and from a comparable day type, for a window of a chosen number of days, are used to compute the coefficients of a linear model. This model is then used to predict electrical load at this location for the same future day type and hour-of-day based on the forecasted ambient temperature for the future hour.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
This formulation is based on a first-order polynomial (linear) model of power {circumflex over (P)} as a function of temperature T, as shown in equation A1. This model's coefficients a0, and a1 are determined via a least-squares error fit to pairs of measured power and temperature. The coefficients may be used thereafter to predict power given forecasted temperatures.
{circumflex over (P)}=a0+a1·T (A1)
The optimal coefficients are determined by minimization of the cost function J shown in equation A2. This wisely chosen cost function happens to be the statistical variance of the difference between actual measured electrical load and load that is modeled by the linear model during N days of a given type (weekdays, or weekends/holidays). The standard deviation is the square root of the variance. The variance and standard deviation are potentially useful indicators of the accuracy of and one's confidence in the predictions that result from this function.
The optimal coefficients are found by setting the partial derivatives of the cost function with respect to the two coefficients to zero, as shown in equation A3.
Equation A3 can be written in matrix form, as in equation A4.
The matrix is seen to be identical to its transpose. The simplified representation given in equation A5 will prove useful in referring to the various vector and matrix elements of equation A4.
This is in the form Ax=b, the solution of which can be found by x=A−1b, as long as matrix A is invertible or nonsingular. Formulas exist for the inversion of a 2×2 matrix, so each coefficient may be explicitly solved for as in equation A6. This explicit representation is advantageous because it alleviates any expectation that the computational infrastructure being relied upon to conduct this function necessarily possesses any matrix solvers.
This method should not require a large set of training data, but some startup issues may be encountered. There is no reasonable way to predict electrical load before any comparable measurement has been made. The coefficients cannot be uniquely determined until at least two non-identical temperature measurements have been taken for a given hour of the day.
In this example, real power (load) P and temperature T measurements during fourteen weekdays—given in Table 30 and Table 31, respectively—are used to compute {circumflex over (P)}, following the procedure outlined in the Pseudo Code Implementation section. N=10. The resulting {circumflex over (P)} is given in Table 32, and plotted along with ±1 standard deviation (e.g. ±√{square root over (J)}) and P in the set 4700 of graphs shown in
Description:
The following is the foundation of an alternative to the Bulk Inelastic Load toolkit functions 1.0 and 1.01. However, this functional specification can be implemented with measurements over only two prior days, expects less mathematical knowledge by implementers, is easily documented down to requisite steps, and for, these reasons, may be more amenable to implementation by some utility implementers. Furthermore, unlike toolkit function 1.01 that uses a moving window of a chosen number of days, this function 1.01a is formulated as a purely recursive algorithm.
The basic approach is as follows: For a given circuit location, pairs of electrical load and ambient temperature are measured each hour. Data from the same hour-of-day and from a comparable day type are used to recursively update the coefficients of a linear model. This model is then used to predict electrical load at this location for the same future day type and hour-of-day based on the forecasted ambient temperature for the future hour.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
This formulation is based on a first-order polynomial (linear) model of power {circumflex over (P)} as a function of temperature T, as shown in equation A1. This model's coefficients a0, and a1 are determined via a least-squares error fit to pairs of measured power and temperature. The coefficients may be used thereafter to predict power given forecasted temperatures.
{circumflex over (P)}=a0+a1·T (A1)
The optimal coefficients are determined by minimization of the cost function J shown in equation A2. This wisely chosen cost function happens to be the statistical variance of the difference between actual measured electrical load and load that is modeled by the linear model during N days of a given type (weekdays, or weekends/holidays). The standard deviation is the square root of the variance. The variance and standard deviation are potentially useful indicators of the accuracy of and one's confidence in the predictions that result from this function.
The optimal coefficients are found by setting the partial derivatives of the cost function with respect to the two coefficients to zero, as shown in equation A3.
Equation A3 can be written in matrix form, as in equation A4.
The matrix is seen to be identical to its transpose. The simplified representation given in equation A5 will prove useful in referring to the various vector and matrix elements of equation A4.
This is in the form Ax=b, the solution of which can be found by x=A−1b, as long as matrix A is invertible or nonsingular. Formulas exist for the inversion of a 2×2 matrix, so each coefficient may be explicitly solved for as in equation A6. This explicit representation is advantageous because it alleviates any expectation that the computational infrastructure being relied upon to conduct this function necessarily possesses any matrix solvers.
This method should not require a large set of training data, but some startup issues may be encountered. There is no reasonable way to predict electrical load before any comparable measurement has been made. If used non-recursively according to the formulation so far, the coefficients cannot be uniquely determined until at least two non-identical measurement pairs have been taken. Exceptions would be used to apply the method until N>2.
After two non-identical measurements, the problem becomes over-determined, and the power of least-squares error fit comes into play. The question then becomes how many samples N to maintain and use. If a moving window is used, then one should store a cache of N data pairs. Furthermore, the cache should be maintained for all of the more than 24×2 sets of hours and day types that are to be modeled. The moving window approach may not be especially efficient from a computational and storage standpoint and should be avoided. A recursive approach is preferred.
In a recursive formulation, one can keep a cache of only the four most recently calculated unique vector and matrix elements (A01, A11, b1, and b1) for each day type and its hours. Each of these elements is presumed to have already been influenced by at least N prior measurements. When a new measurement pair (PN+1, TN+1) becomes available for this hour and hour type, one may recursively update elements as exemplified in A7 for vector element b1. The effect of this recursive formula is that the old vector element is replaced by a new term that is a weighted sum of the old element and a new term that uses the new measurements. If N is large, the new measurements have less impact than they would if N were small.
Equation A8 more simply and generally shows how the old vector element b*1 becomes replaced by the new one b1. The two weighting factors are (N−1)/N and 1/N, which sums to unity.
Nothing prevents the application of recursive formulas of the type exemplified by A7 and A8 after the elements have been initialized. The first predictions may be wild and unreliable until more measurements can become incorporated into the model.
In this example, real power (load) P and temperature T measurements during fourteen weekdays—given in Table 33 and Table 34, respectively—are used to compute {circumflex over (P)}, following the procedure outlined in the Pseudo Code Implementation section. The resulting {circumflex over (P)} is given in Table 35, and plotted along with ±1 standard deviation (e.g. ±√{square root over (J)}) and Pin the set 5100 of graphs in
Description:
Converts transactive signals from transactive neighbors into framework parameter outputs that are expected by the toolkit framework.
Application: A transactive node typically should restate the transactive signals that it receives in terms of toolkit framework parameters.
This toolkit function is so basic that it may be treated as part of the toolkit framework.
Block Input/Output Function Model:
Inputs:
Current IST time series.
Transactive incentive signals (TIS) from each transactive neighbor.
Transactive feedback signals (TFS) from each transactive neighbor.
Outputs:
TIS restated as energy terms CE.
TFS restated as energy terms PG for the intervals during which the TFS represents imported energy.
Description:
This function is to predict the power to be produced by small wind energy resources. This function is preferred where a relatively small amount of wind renewable generation offsets load at a location.
If the energy from a wind energy resource should directly affect the transactive incentive signal (TIS) at this location and electrically downstream locations, the energy from this resource should be incorporated with the Wind Energy resource and incentive toolkit function instead.
This function applies to locations that host relatively small wind generators or wind sites that primarily offset a larger electrical load.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Output:
Pseudo Code Implementation:
The information in Table 36 is plotted in graph 5500 of
Description:
This function is to predict the power to be produced by small solar energy resources. This function is preferred where a relatively small amount of solar renewable generation offsets load at a location.
If the energy from a solar energy resource should directly affect the transactive incentive signal (TIS) at this location and electrically downstream locations, the energy from this resource should be incorporated with the Solar Energy resource and incentive toolkit function instead.
This function applies to locations that host relatively small solar generators or solar sites that primarily offset a larger electrical load.
Block Input/Output Function Model:
Inputs:
Interim Calculation Product:
Output:
Pseudo Code Implementation:
Description:
This is a very general function for predicting the behaviors of responsive load assets that only infrequently respond to events that may be identified from an incentive signal. When these assets respond, they transition to a limited number of available response levels. This general function may serve as a template for functions that are more narrowly targeted to specific responsive asset systems. This function has been written at such a high level that it will not likely be referenced and used for any asset system. But this function description will be valuable guidance to those who design more specific functions for more specific asset systems.
This function can respond to absolute or relative TIS as desired by an application.
This function applies to many responsive asset systems that conduct traditional demand response several times a month. Response may additionally define a “critical” response level for extreme conditions.
Block Input/Output Function Model:
Inputs:
Current IST time series.
TIS time series. Recent history (e.g., 1 day to 1 week) of TIS that may be used if relative TIS is to be tracked in a statistical sense.
Numbers of assets in this asset system population that may be used to scale this function.
Typical daily or weekly inelastic load profile for the asset systems that are being predicted by this function. This profile is a starting point for predicting the inelastic load component.
Outputs:
Predicted inelastic load at for each IST interval.
Predicted change in elastic load for each IST interval.
Predicted advisory control signal for this asset system.
Pseudo Code Implementation:
Inelastic load component.
This algorithm will not predict an inelastic load component. Inelastic load components are better addressed by inelastic load functions that have been defined.
Elastic Load Component.
This algorithm will calculate (1) predicted change in electrical load in response to the incentive signal (e.g., the asset's elasticity), (2) “events” during which an asset is predicted to respond, and (3) the predicted advisory control signal that will be sent to this elastic asset system.
Predicted Change in Electrical Load in Response to the Incentive Signal.
To predict a change in energy that can result from this asset system during events, this function should model the consumption (or generation) of energy by this asset system. At least two approaches can be accommodated: (1) An explicit time-series load shape may be used to represent the responsive load (or generation) from this asset system. Alternatively, (2) A dynamic model of this asset system may be simulated to predict the effect that an event will have on the asset system. These approaches will be compared by discussing how each one could be used to predict the change in electrical load that could be had from a set of residential tank water heaters.
Explicit Time-Series Load Shape.
The average electrical load consumed during each hour of a day by a residential 40-gallon tank electric water heater may be obtained. In some cases, regional and seasonal variations may be found. See (Hammerstrom 2007,
Dynamic Asset System Model.
The same population of electric water heaters may be more rigorously modeled using a physics-based model of a water heater. In this case, one could input typical residential hot water consumption instead of an electrical load curve. As water is consumed, hot water leaves the water tank, cold water enters the water tank, and the temperature of the water in the tank decreases. The modeled thermostat turns on the electrical heating element and heats the water at a rate that is determined by the power rating of a heating element. If the model being used is accurate, the resulting electrical load curve would also be accurate on a “typical” day.
However, if a curtailment is predicted, the response of the dynamic water heater model can predict secondary effects that could not have been modeled otherwise. After a period of electrical curtailment, the water in the tank will have become relatively cold. When the curtailment period ends, additional energy is then used to reheat the cool, stored water to the desired temperature. A rebound effect is thereby predicted at the conclusion of the curtailment event.
Events During which this Asset is Predicted to Respond.
The capabilities and availability of the modeled asset system determine a set of incentive thresholds that should be managed by this function. A threshold may be a function of time. An asset system that has only two modes of operation (e.g., normal and curtailed) will define only one threshold. Generally, an asset system that has m modes of operation should define m−1 thresholds. The resulting thresholds, in turn, define m−1 levels of response for an asset system. (The “Normal” mode of operation is indeed a mode of operation, but it is usually not considered a response level.) “Events” occur any time that the predicted incentive signal exceeds a defined threshold to invoke one of the levels of response that is a feature of this asset system.
The availability of asset systems that are responsive either on an event-based or time-of-use basis may be predicted if limitations on the numbers and durations of events are stated. For example, a utility might have contracted with its customers that a responsive asset will not become curtailed by the utility more often than four times per calendar month and that none of these curtailments will not endure for more than 2 hours.
Over time, statistical distributions and correlations emerge from the dynamic behaviors of the incentive signal. This function may incorporate the behaviors of past historical incentive signals and the predicted incentive signals as these statistics are being compiled. This function may thereafter refer to such statistics to evaluate and predict where a threshold should be placed to initiate just fewer than the allowed number of events and just less than the allowed duration of events. Automated event-driven demand response will be attempting to identify events within monthlong durations, so these functions should use the actual incentive signal (not its statistical average), or it should track the statistical average of the incentive signal quite slowly in comparison with that duration.
Predicted Advisory Control Signal.
Once events have been predicted, the predicted advisory control signal may be stated, aligned in time with the predicted events, according to the standardized method described in the appendix entitled “Standard Advisory Output Control Signal”. In the referenced method, the capabilities of this asset system and, in some cases, the severity of an event determine which integer member of a signed byte signal will be sent to the asset system. (The domain of relevant advisory control signals will be relatively small for functions that are formulated for specific asset systems.)
Description:
This function addresses wind power generation and is to be applied at transactive nodes which have and represent wind farm energy that is produced within or near their electrical boundaries to encourage the use of wind energy when and near where it is generated. This function is applicable to energy produced by a wind farm or may be applied to aggregated output from multiple wind farms.
The cost of supplying the wind energy generated is applied as an infrastructure cost, in units of cost per time, consistent with the Transactive Node Framework. For simplicity, the infrastructure cost will use the $2155/kW capacity-weighted average installed cost for a wind farm. The infrastructure cost of a wind farm can thus be estimated if its capacity is known. This cost shall then be spread over the lifetime T of the wind farm.
Note that this calculation typically yields an infrastructure cost near $0.010/kW/h ($10/MW/h) if a 25-year lifetime is assumed. It is permissible for the implementer of this function to assume that T=2.19×105 hours (25 years) if better estimates are unavailable for the lifetime of the wind farm installation.
After a wind farm exceeds its planned lifetime, a decision should be made. Thereafter, the infrastructure cost may be (a) zeroed out, (b) replaced by ongoing maintenance costs, or (c) continued as before as an ongoing replacement cost. This function should be revisited and refined when this situation will be encountered.
This function should also predict the electrical power that will be produced by the wind resource during each future interval. An explicit algorithm could be created to convert predicted weather conditions (like wind speed and direction) into electrical power output. This function will assume that experts satisfy this goal by predicting electrical power output from meteorological data that is available to them.
Block Input/Output Function Model:
Inputs:
P—Wind farm capacity/power rating.
T—Lifetime of wind farm.
ISTn—Present time series interval start times used by an example toolkit framework, where n=0, 1, . . . , 56. (There is no prediction to correspond with ISTn for n=56. This last IST is simply used to make it clear when the final interval concludes.)
Meteorological data—Predicted wind speed, wind direction, relative humidity and perhaps other weather data that experts may use to predict electrical power production for wind farms.
Outputs:
CI,n—Time series of infrastructure cost terms expected by the Transactive Node Framework (unit: $/h); series members correspond to ISTn. Infrastructure costs are not expected to be dynamic, but it is specified as a time series for consistency with the Transactive Node Framework.
PG,n—Time series of predicted electrical power generated by wind farm (unit: average kW); series members correspond to ISTn.
CE,n—Time series of energy cost terms (unit: cost per energy). Since the cost of supplying the wind energy generated is applied purely as an infrastructure cost, these energy cost terms should simply be set to zero. Note that these terms go in pair with the PG,n terms and are used by the Transactive Node Framework.
Pseudo Code Implementation:
Description:
This function addresses solar power generation and is to be applied at transactive nodes which have and represent solar farm energy that is produced within or near their electrical boundaries to encourage the use of solar energy when and near where it is generated. This function is applicable to energy produced by a solar farm or may be applied to aggregated output from multiple solar farms.
The cost of supplying the solar energy generated is applied as an infrastructure cost, in units of cost per time, consistent with the Transactive Node Framework. For simplicity, the infrastructure cost will use the $7.5/W capacity-weighted average installed cost for a solar farm. The infrastructure cost of a solar farm can thus be estimated if its capacity is known. This cost shall then be spread over the lifetime T of the solar farm.
Note that this calculation typically yields an infrastructure cost near $0.034/kW/h ($34/MW/h) if a 25-year lifetime is assumed. It is permissible for the implementer of this function to assume that T=2.19×105 hours (25 years) if better estimates are unavailable for the lifetime of the solar farm installation.
After a solar farm exceeds its planned lifetime, a decision should be made. Thereafter, the infrastructure cost may be (a) zeroed out, (b) replaced by ongoing maintenance costs, or (c) continued as before as an ongoing replacement cost. This function should be revisited and refined when this situation will be encountered.
This function should also predict the electrical power that will be produced by the solar resource during each future interval. An explicit algorithm could be created to convert predicted weather conditions (like solar irradiance and temperature) into electrical power output. This function will assume that experts satisfy this goal by predicting electrical power output from meteorological data that is available to them.
Block Input/Output Function Model:
Inputs:
P—Solar farm capacity/power rating.
T—Lifetime of solar farm.
ISTn—Present time series interval start times used by the toolkit framework, where n=0, 1, . . . , 56. (There is no prediction to correspond with ISTn for n=56. This last IST is simply used to make it clear when the final interval concludes.)
Meteorological data—Solar irradiance, temperature, and perhaps other weather data that experts may use to predict electrical power production for solar farms.
Outputs:
CI,n—Time series of infrastructure cost terms expected by the Transactive Node Framework (unit: $/h); series members correspond to ISTn. Infrastructure costs are not expected to be dynamic, but it is specified as a time series for consistency with the Transactive Node Framework.
PG,n—Time series of predicted electrical power generated by solar site (unit: average kW); series members correspond to ISTn.
CE,n—Time series of energy cost terms (unit: cost per energy). Since the cost of supplying the solar energy generated is applied purely as an infrastructure cost, these energy cost terms should simply be set to zero. Note that these terms go in pair with the PG,n terms and are used by the Transactive Node Framework.
Pseudo Code Implementation:
Description:
This function is to predict the amount and cost of hydroelectric energy when and near where it is generated. It should at least represent federal hydropower of the region, but should strive to represent all regional hydropower. This function applies to transactive nodes that own or represent hydropower generation within their electrical boundaries. At least transmission zones 4, 5, 6, 7, 8, 10, 11, 12, and 14 are within the Columbia River Basin and would be expected to host federal hydropower. Based on the predicted generated powers of non-hydro sources at a transactive node and their associated costs of energy, and historical electricity market prices, this function predicts the weighted-average cost of energy of hydropower generation.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Description:
This toolkit function addresses systems of residential demand-response equipment that will be expected to respond relatively infrequently (e.g., perhaps several times per month) to events that will be indicated via the transactive control and coordination system's incentive signal (TIS).
This toolkit function addresses systems that control any combination of (1) residential space heating, (2) residential electric tank water heaters, or (3) smart appliances. Two or more different types of equipment from this list may be grouped into a single asset system and may consequently be described by a single instantiation of this toolkit function. This function allows for multiple response levels. A single asset system uses one single set of thresholds and response levels. If different sets of thresholds (e.g., different demand-response events) should be defined for different types or populations of equipment, then additional functions should be instantiated for each such type or population.
Refer to toolkit load function 2.0 General Event-Driven Demand Response for general guidance and principles that were used during the formulation of this function. The section Pseudo Code Implementation below (and the detailed pseudo code in Subappendix F) lays out the specific calculation strategy and steps of this function.
Block Input/Output Function Model
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
A skilled implementer may choose to fit the normalized cumulative distribution ϕ(TIS0) column of Table 40 to a monotonic function that could be used hereafter instead of this lookup table.
Further Alternatives:
Input parameters: Bres, Bcom
Inputs that should be obtained automatically by function (e.g., by internet): Iave, tsr, tss
The following approach will produce reasonable dynamics to represent the effect of solar insolation on building populations, but it does not rely on actual predicted insolation nor on actual building data and building construction properties. As time permits, this approach may be improved to better predict building performance.
An example profile 6100 of PS(t) is shown in
Input parameters: Tcenter, K1, t1, K2, t2
Input variable: t
The occupancy set point temperature TOSP reflects a representative change in the target interior temperature set point that is induced by building occupants as they schedule or manually change their thermostatic set points for periods of the day. The following approach produces a smooth function of time-of-day while using only a few supplied input parameters.
The example input parameters of Table 42 are based on expert opinion and should suffice until data is found to refine these parameters. (It is also acceptable to simply use a constant value Tcenter, similar to what has been recommended in Table 42 for summer and fall periods.)
There are several terms of equation (9) that are useful toward the understanding of relationships between the model parameters.
Thermal Losses
If the effects of space conditioning and solar insolation were eliminated, the relationship of equation D1 would remain and would describe the asymptotic migration of the representative temperature Ti toward the ambient outdoor temperature To that is characterized by the relationship between thermal losses U and thermal mass C.
An insight available from equation D1 is that it defines a relaxation time constant as the ratio C/U. The time constant is the time that it would take for the two temperatures to come within about 37% of the starting difference between the two temperatures. For example, if the interior temperature begins at 20° C. and the outside temperature remains constant at 0° C., the time constant would be the time it takes for the interior temperature to drop to 7.4° C. If that amount of time is estimated to be 8 hours, then the magnitude of parameter C should be 8 times as great as the magnitude of U. Therefore, if the value of C is estimated to be 0.17 kWh/° C. for a residential building, then the value of U should be approximately 0.021 kW/° C., which is the recommended default value for this parameter.
Space Conditioner Size and Responsiveness
If the effects of solar insolation and thermal losses may be temporarily ignored, equation D2 may be derived from equation 9 to represent the rate at which the representative heating or cooling equipment would correct the representative interior temperature Ti toward its set point, which is the sum TOSP+ΔTDRSP.
In the normal case, KDRP is unity.
Equation D2 is characterized by a time constant as the ratio C/KP. Space conditioning equipment is usually sized to correct the interior temperature in a relatively short time. If, for example, buildings heaters were to heat a residential building and its contents from 10° C. to 20° C., it might take about 40 minutes to heat those contents fully to 16.3° C. Therefore, the magnitude of C should be about 0.67 that of KP. If C is 0. 17 kWh/° C. for a residential building, then the representative magnitude of KP should be about 0.25 kW/° C., which is the recommended default value for this parameter.
Average Electrical Power for Space Conditioning
Another insight may be obtained if one calculated the final, constant condition of how much power it would take to maintain a thermostatic set point for a given outdoor temperature To. One may calculate a final interior temperature Ti using equation 9. Then this interior temperature may be used in equations 10 and 11 to predict that resulting electrical power Pe that would be consumed.
Ignoring the effects of solar insolation and setting KDRP to unity, the steady-state electrical power is given by equation D3.
For present purposes, equation D3 should be used to test the reasonableness of the set of parameters. Given the sets of default parameters recommended so far for a residential building, and assuming efficiency η of the electrical conversion and ΔTDRSP are unity, it would take about 190 average watts to maintain a constant 10° C. difference between the set point and ambient outdoor temperatures in this structure.
In the pseudocode, a set of lower boundaries of bins used to build up TIS0 distribution.
It is acceptable to use a standard averaging window during initialization. This may be helpful if the initial TIS0 distribution is to be shared among several load toolkit function implementations at the same transactive node and/or used for response levels L within the same implementation. Note that m is used as an iteration index, so that m−1 refers to the previous update interval. During a relaxation instance, IST0 remains unchanged. Averaging TIS0 may have little effect on updating the TIS0 distribution. If that is the case, the implementer may choose not to do the averaging. This may then allow the update of TIS0 distribution to be done outside of any single toolkit function implementation to be shared among several toolkit function implementations at the same transactive node and/or used for response levels L within the same implementation. Devent is a new variable introduced to keep track of the duration of an event. change(x, t1, t2)” represents a function to determine whether calendar period x has changed between t1 and t2, inclusive.
%% TKLD_2.4 MATLAB Simulation—Version E (matches pseudo code above)
% This script is to simulate the performance of load toolkit function TKLD_2.4 using actual TIS data queried from the Netezza database
%
%% Clear everything to start new simulation:
clear all; close all; clc; tic
%% Subproject Configuration:
timezone=‘Pacific’; % ‘Pacific’ or ‘Mountain’
N_WH=800; % number of water heaters
K_L=1; % number of control levels
% K_L=2; % FOR TESTING (comment out above line)
subplot(2+K_L,1,K_L+2); stairs(IST_num(m,:),[Delta_Load(m,:) Delta_Load(m,56)]);
ylabel(“\DeltaL [kW]”);
x_tick_label=datestr(x_tick,‘mm/dd/yy HH:MM’);
set(gca,‘XTick’,x_tick,‘XTickLabel’,x_tick_label)
xlabel(‘IST_n’)
%% Simulation time in minutes:
sim_time=toc/60;
Running the above MATLAB code, with KL=1, Dmin,1=15 min, Dthis day,1=240 min, Nthis month,1=5, Dthis month,1=5×240 min=1200 min, results in the plots 6800, 6900, 7000, 7100, 7200 of
Running the above MATLAB code, with
The load profiles in Table 43 are derived from normalized profiles in single-family detached house models found at [H1] and yearly energy consumed by each load computed from equations given in [H2]. Note that 2400 ft2 and 4 bedrooms were used to represent a “typical” single-family detached house. In Table 43, MEL refers to miscellaneous electric loads.
[H1] U.S. Department of Energy, Building Energy Codes Program, Residential Prototype Building Models: http://www.energycodes.gov/development/residential/iecc_models
[H2] U.S. Department of Energy, Building Technologies Program, Building America House Simulation Protocols, by R. Hendrom and C. Engbrecht (National Renewable Energy Laboratory), Available at http://www.nrel.gov/docs/fy11osti/49246.pdf.
Plots of load profiles given in Table 43 are shown in
Description:
This is a function for predicting the responses of distributed generators that only infrequently respond to events that may be identified from an incentive signal. When these assets respond, they transition to a limited number of available response levels, which in this case are limited to two levels—standing idle or generating. This function was adapted quite directly from function 2.4 Residential Event-Driven Demand Response), which includes certain details not repeated here. Also refer to function 2.0 General Event-Driven Demand Response for general guidance about event-driven toolkit functions.
It is assumed that the distributed generator is normally idle, so its inelastic load prediction is zero. If this is not the case, or if the generator is used for objectives other than transactive control, then this toolkit function should be augmented to keep track of its inelastic load as a baseline to its generation under transactive control. Implementers may elect to also keep track of generator availability and scheduled testing periods, which conditions are not being tracked in this function.
This function can respond to absolute or relative TIS as desired by an application. In Version 0.4, a new parameter is recommended to state the effective cost of generation by this distributed generation resource. Because the TIS represents an economic signal, distributed generators that are more expensive than the TIS should not be operated, regardless of how the event periods have been determined.
This function was originally drafted for distributed diesel generators that are operated by UW under the control of operators who (we hope) are responsive to this function's advisory control signal. Having a human in the control loop will affect the reliability of and confidence in the generators' responses, but having a human in the control loop in no other way affected the way that this function was designed. The human operator will introduce uncertainty in the likelihood that advised control actions will be heeded, and this uncertainty may be addressed in future drafts of this function. This function should be useable for most event-driven distributed generators responses.
Block Input/Output Function Model:
Inputs:
Inputs for this function are identical to those defined in 2.4 Residential Event-Driven Demand Response with several exceptions listed below. The baseline, inelastic generation is assumed to be the idle state with no power being produced. Therefore, no generation pattern is tracked by this function. If the generator is found to be scheduled for other objectives, the times at which the generators are to be activated should be tracked as a baseline and subtracted from predicted event behaviors.
Interim Calculation Products:
Outputs:
Pseudo Code Implementation: The algorithm by which infrequent events are to be determined from the incentive signal are identical to what was described elsewhere in this application.
This appendix offers some insights about additional considerations, steps, and calculations that should be conducted if a distributed generation resource is found to use ramp-up and/or ramp-down periods that are comparable to, or longer than, the duration of the update interval.
One additional set of inputs is used to indicate whether ramp-up and ramp-down periods are being modeled and their durations:
The formulation uses additional sub-steps given the various possible relationships between tron, troff, and the ISTn times. In certain embodiments, ISTn* is defined as the ISTn at which an event and tron are initiated. In some embodiments, ISTn** is defined as the ISTn that immediately follows the event. If it were not for troff, no power would be generated in the interval that starts at ISTn**.
The approach will be to define generation power pn at each time ISTn. Then, the average power may be determined from these points and knowledge of the ramp rates.
Description:
This function provides the predict fossil generation and its cost aggregated for each transmission zone.
The cost for generating fossil energy includes a fixed infrastructure cost and a variable production cost. The infrastructure cost will be based on estimated amortized fossil generation plant infrastructure expense; while the variable production cost is mainly based on fuel cost.
Fossil generators include the following types:
For simplicity, the infrastructure cost will be calculated for each of the above categories of generation based on the average capital cost provided in Subappendix B in (kaplan 2008).
The infrastructure cost of a fossil generating unit can thus be estimated if its capacity is known. This cost shall then be spread over the lifetime T of the generating unit.
It is permissible for the implementer of this function to assume that T=8760 (h/year)*40 (years)*0.9 (utilization factor)=315360 (hours) if better estimates are unavailable for the lifetime of fossil generating unit.
It is unlikely that any of the fossil units will surpass their stated lifetime in the short-time. However, after a generating unit exceeds its planned lifetime, a decision should be made. Thereafter, the infrastructure cost may be (a) zeroed out, (b) replaced by ongoing maintenance costs, or (c) continued as before as an ongoing replacement cost. This function should be revisited and refined when this situation will be encountered.
The generating units available to meet system load are “dispatched” (put on-line) in order of lowest variable cost. This is referred to as the “economic dispatch” of a power system's plants. For a plant that uses combustible fuels (such as coal or natural gas) a key driver of variable costs is the efficiency with which the plant converts fuel to electricity, as measured by the plant's “heat rate.” This is the fuel input in British Thermal Units (btus) used to produce one kilowatt-hour of electricity output. A lower heat rate equates with greater efficiency and lower variable costs.
A Unit Commitment and Dispatch Engine is used to produce generation MW, that can meet BPA load forecast. Generation cost is calculated based on the heat rate curves and fuel prices.
Inputs:
Outputs:
Pseudo Code Implementation:
where t is covers the majority portion of an IST interval
where t is covers the majority portion of an IST interval
Description:
This function predicts the response from an automated residential demand-response system that will respond approximately daily to help mitigate peak conditions that are evident in an incentive signal. The peak period will be based on response constraints and the TIS incentive signal. (Note that this approach is more dynamic than typical time-of-use (TOU) demand response, in which daily peak and off-peak intervals remain immutable. The peak and off-peak periods recommended by this function may be assigned differently each day according to events that will have affected the predicted TIS incentive signals.) It may be applied where programmable, communicating thermostats; smart appliances, demand-response switch units, or other assets are installed in residences and where programs are designed to have these systems respond to daily peak periods.
In some cases, this function will be used by the asset systems IF-04 (water heater control), IF-08 (thermostat load control), and LV-02 (water heater demand-response units). (This document may be useful for the determination of appropriate daily intervals, but a unique function may be used to predict the changes in elastic load from such a diverse and changing population of responsive assets.)
A first objective of this function is to establish the time periods during which the response level(s) should be called, based upon the numbers and durations and preferred durations of these periods that are permitted for each response level. The daily events and their durations are positioned to best align with the levels of the TIS incentive signal that has been predicted for the day.
The function should then predict the change in load that will result from these events having been planned. This toolkit function addresses systems that control any combination of (1) residential space heating, (2) residential electric tank water heaters, or (3) smart appliances. Relatively simple models of populations of these devices are used to predict the changed load that they will consume as they respond to these various peak periods.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Further Alternatives:
There might exist a preferable way to organize toolkit load functions according to (1) the way events are related to the TIS time series and (2) the asset system models. The present organization, in which these two elements have been combined into each toolkit function, is inefficient and uses multiple cross references and duplications.
The means by which TOU periods are specified from the TIS proved, while conceptually easy, to be relatively difficult to describe and specify. This function should be further refined as implementers learn ways to mathematically represent the process that has been described herein.
While the pseudo code in the function's specification remains largely correct, the interpretation of selecting the event interval having the “maximum average TIS” was open to interpretation. If strictly followed, the algorithm would select only the events having minimum duration. The following general strategy proved useful.
The following general steps were
Description:
This toolkit load function is similar to Toolkit Function 2.2 Event-Driven Distribution System Voltage Control, except voltage is controlled in this function according to daily on- and off-peak time-of-use periods. (“Time-of-use,” as used here is more dynamic than time-of-use demand response is currently practiced. This function dynamically determines appropriate peak and off-peak periods based on the condition of a relatively dynamic incentive signal.) This toolkit function is applicable where voltage is to be controlled at two or more levels according to the value of the TIS and constraints input by utilities and where responses of the asset have been designed to occur according to daily on- and off-peak periods.
During the strategic design of toolkit load functions, it has been observed that the functions that share time-of-use objectives are very similar, and functions that control the same type of asset system are also similar. This present function makes efficient use of this observation and incorporates similar toolkit load function objectives and text by reference.
Block Input/Output Function Model:
Inputs:
Include by reference the list of inputs in Toolkit Load Function 3.4 Residential Time-of-Use Demand Response.
Interim Calculation Products:
Same.
Outputs:
Same.
Pseudo Code Implementation:
Description:
This toolkit load function is based on Load Toolkit Function 3.5 Time-of-Use Distribution System Voltage Control, but includes the effect of concurrent shedding of customer loads (e.g. water heaters, thermostatic space conditioning, etc.) that use augmented conservation regulation. For example, this function should be used by Milton-Freewater's test case MF-02-1.2, in which time-of-use voltage reduction both earns conservation from circuit loads and triggers Grid Friendly™ water heaters to turn off.
This function relies on the approach that was formulated in toolkit functions 3.4 Residential Time-of-Use Demand Response and 3.5 Time-of-Use Distribution System Voltage Control.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Description:
This function predicts the response from a non-renewable distributed generator demand-response system that will respond approximately daily to help mitigate peak conditions that are evident in an incentive signal. The peak period will be based on response constraints and the TIS incentive signal. (Note that this approach is more dynamic than typical time-of-use (TOU) demand response, in which daily peak and off-peak intervals remain immutable. The peak and off-peak periods recommended by this function may be assigned differently each day according to events that will have affected the predicted TIS incentive signals.) This function relies on the approach that was formulated in toolkit function 3.4 Residential Time-of-Use Demand Response.
A first objective of this function is to establish the time periods during which the response level(s) should occur, based upon the numbers and durations and preferred durations of these periods that are permitted for each response level. The daily events and their durations are positioned to best align with the levels of the TIS incentive signal that has been predicted for the day.
The function should then predict the change in load that will result from these events. Specifically, what additional energy will be generated at each prescribed response level.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Steps 2-7 (and perhaps 1, too) should be iterated each update interval.
Further Alternatives:
Description:
Where transactive control is applied at the device level, each device would have the opportunity to inject the impact of hardware costs (e.g., its infrastructure costs). However, where transactive control has been applied to large aggregate regions, the owner of the large aggregate transactive node may be unable or unwilling to accurately represent the impact of infrastructure costs on the delivered cost of energy. The purpose of this function, therefore, is to represent the influence of bulk infrastructure costs on the delivered cost of electrical energy where it might be impracticable to track the costs of individual infrastructure components.
The effect of this function should be to apply an offset to the calculation of the delivered cost of energy (e.g., the transactive incentive signal (TIS)). It is assumed by this function that the difference between the sum of existing resource costs and incentives, which are otherwise already represented in the TIS, and an accepted delivered cost of energy is attributable to infrastructure costs. (This assumption may be somewhat imperfect due to profit, labor costs, taxes and other impacts.)
This toolkit function may be applied at any of the transactive nodes, but it is desirable that transmission zone transactive nodes use this function to represent the bulk impact of generation and transmission infrastructure costs that might not have otherwise been included.
Negative CI parameter outputs are to be disallowed in order to halt most occurrences of negative calculated TIS in the system.
Block Input/Output Function Model:
Inputs:
TIS0(n)—[cost/energy: default: $/kWh]—(series of real floating)—time series of the transactive control signal (TIS) at interval start time zero (IST0) at each of a series of update intervals n. (The update interval may be 5 minutes. In certain embodiments, a TIS is calculated and transmitted at least once by this transactive node at each update interval. Of the interval values within each TIS, only the first, TIS0, that refers to the nearest 5-minute interval is to be used by this function.)
TISavg—[cost/energy: default: $/kWh]—(real floating scalar)—typical, or long-term average, value of TIS0(n). This value should be observed from or analyzed from calculated TIS values at this transactive node. This value is used only during initialization of the infrastructure cost parameter CI. The default value $0.04/kWh may be used, but doing so may introduce an initialization error that can take months to fully eliminate.
TIStarget—[cost/energy: default: $/kWh]—(real floating scalar)—accepted reference baseline for what the long-term delivered average cost of energy (e.g., the TIS) should be at this transactive node. In some cases, acceptable target TIS values have been found among energy supply costs in utilities' annual reports. Alternatively, the lowest customer costs that a utility passes along to its customers, too, might be an acceptable surrogate for the target TIS. Default: $0.05/kWh.
ΣPG—[power: default: kW]—(real floating scalar)—long-term average of the sum of power imported into and generated within the boundaries of this transactive node. This parameter is a long-term average of the denominator of the Update TIS framework function. This parameter is mostly static, but it may be updated quarterly or yearly by the owner of the transactive node. This parameter affects that rate at which the function's proportional controller tracks the infrastructure cost parameter CI. The accuracy of this parameter is not critical. The default value 1 GW should be used only as a last resort for this parameter. This default value will virtually disable this function for most transactive nodes so that the infrastructure cost will not be tracked.
α—[dimensionless]—(real floating scalar)—factor used in the proportional controller to affect the rate at which the infrastructure cost parameter should track the TIS. Default value: 0.0001, assuming that updates occur every 5 minutes.
Outputs:
CI—[cost/time: default units: $/h]—Parameter defined and used in Transactive Node and Toolkit Functions and Transactive Control System Data Collection. Time series of cost per time duration to be applied at defined future time intervals. In this function, this output is a correction that approximates the amortized costs of infrastructure over time. A remedial action was initiated to disallow this output parameter from becoming negative.
Pseudo Code Implementation:
This appendix takes one through formulations on which the initialization and updating of the infrastructure cost parameter CI output of this function is based.
Refer to the framework function by which the TIS for an interval is calculated at a transactive node, copied here as Equation A1. The numerator is a total cost, and the denominator is the sum of electrical energy that is imported into or generated within this transactive node during interval n. The resulting division yields a unit cost of energy, the TIS, which represents the delivered cost of energy at this location in the system.
We assume that the costs in the numerator prior to applying this function can be lumped together as shown in Equation A2. These costs will neither affect nor be affected by this formulation.
A term is added to both sides of Equation A2 to represent an infrastructure cost offset that had not been represented in the prior formulation. See Equation A3. The new TIStarget may be thought of a corrected version of the TIS and may be independently assigned based on long-term-average energy supply costs or other representations of the delivered cost of energy at this system location. An infrastructure term CI was selected for this function because the new infrastructure costs will be modeled as being amortized evenly over time.
Equation A4 is found by subtracting Equation A2 from Equation A3. Equation A4 states a relationship between the independent reference TIStarget, calculated TIS values, the new infrastructure cost parameter CI, and the sum of imported and generated power at this transactive node.
We rearrange Equation A4 to solve for the new infrastructure cost parameter, as shown in Equation A5.
Equation A5 gives us insights about how to initialize the infrastructure cost parameter: Because the infrastructure cost parameter and target TIS are relatively constant, they should be compared to long-term averaged representations of the old TIS and sum of imported and generated power. Ideally, this node would be allowed to operate for months before this function is implemented so that these “typical” values could be learned. Realistically, one may have little or no prior TIS and power values to average. Some off-line analysis can be performed. Regardless, any errors during initialization will eventually be erased by the operation of the function's proportional controller.
Equation A5 is also the basis for the formulation of a proportional controller by which the estimated value of CI may be gradually improved. Equation A7 suggests how CI may be updated from a prior version of itself and an approximation of the value from Equation A5. This is also illustrated in diagram 9000 of
Equation A7 can be modified to disallow negative CI output parameter.
It is presumed that recent calculations of the TIS (e.g., TISn−1) will be available to this function at this node. However, it is recommended that the constant, “typical,” value for the sum of imported and generated power should be used because access to this sum may not be readily available and is not warranted by the precision used by this function.
Description:
This function is applicable to battery storage systems that respond very dynamically to the TIS and other local conditions and provide also a continuum of charge and discharge levels. (If the battery system has only a few levels of response available to it (e.g. full charge, full discharge, and inactive) then the implementer should select a time-of-use function to model the battery system's behavior.) The function will recommend the appropriate charge and discharge rate based on the system's power capacity, state-of-charge, and historical and predicted incentive signals. The implementer is able to limit the responsiveness of his system using additional preferences.
All of the load or generation by a battery system is considered elastic; none is inelastic.
An assumption is made in this present formulation that battery system inefficiency (e.g., losses and auxiliary loads) may be ignored.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Further Alternatives:
Description:
This function is to predict the MW flow and the cost of a transmission flowgate for each interval start times {ISTn} (e.g., n=0, 1, . . . , 56) used by the toolkit framework. A transmission flowgate is potentially congested transmission corridor defined between two transmission zones. A flowgate may consists of one of more than more transmission devices, such as high voltage AC/DC overhead lines and/or transformers.
With a given network topology, generation shift factors (SF) to a specific flowgate can be calculated by a network analysis application. Flowgates are modeled as linear inequality constraints using these shift factors in the Economic Dispatch (ED) Linear Programming problem. When a flowgate constraint is binding at its reliability flow limit, generators can be be redispatched “out-of-merit” according to their shift factors to the flowgate, in order to relieve the congestion. Such redispatch will lead to non-zero operational cost to a binding flowgate (aka shadow price of a constraint in Linear Programming). The physical meaning of the cost of a flowgate is the cost saving with one addition MW added to the limit of flowgate, which will increase one MW generation (cheaper) from the sending end of the flowgate and decrease one MW generation (more expensive) from the receiving end of the flowgate.
Inputs:
Outputs:
Pseudo Code Implementation:
Description:
Discourage consumption of energy downstream from constrained distribution equipment, including distribution lines.
Applies to transactive nodes that are in a position to mitigate their constraints by increasing the delivered cost of energy to downstream transactive nodes.
Intended to be used where constraints may be correlated to specific equipment. Does not apply to transmission flowgates.
Block Input/Output Function Model:
Inputs:
Predicted capacity to which this function applies.
Function which estimates the cost impacts of exceeding the capacity constraint.
Outputs:
Predicted capacity cost time series CC and corresponding capacity time series PC.
Description:
This function predicts the impact of demand charges that the Bonneville Power Administration (BPA) will apply to its customer utilities according to interpretation of its intricate Tiered Rate Methodology (TRM). The TRM explains how BPA's demand charges are to be allocated to its customer utilities at the conclusion of each month. However, since the transactive control and coordination system is predictive, the demand charge impacts of the methodology should be predicted instead. This function can, at best, estimate the demand charge impacts from the TRM.
Many components of the TRM duplicate energy costs that will already be represented in the transactive incentive signal (TIS) by electrically upstream locations. Generally, transactive control applies energy costs at the points where electrical energy is generated and fed into the electrical power grid. These influences should not be duplicated or double-counted. Therefore, this function should only insert the unique demand charge impacts from the TRM that apply specifically to the utilities. This may be achieved by applying upward pressure to the TIS—by adding, to the TIS computation, the product of the pair of capacity cost CC and average power capacity PC—during and around a time interval when the transactive feedback signal (TFS) predicts the occurrence of a peak that exceeds the highest peak that has already been recorded during the time elapsed for the calendar month prior to the start time (e.g., IST0) of the TFS. If the increased TIS, in turn, applies enough downward pressure on the TFS, the predicted peak may be lowered enough to prevent any additional demand charge.
Normally, an electric utility would be the entity to apply this function. This function applies to a “utility” transactive node or to the transactive node that represents the perspective of an electric utility.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Exaggerated Example for One Iteration at a Given Time:
Description:
An evaluation of prior function 7.1 BPA Demand Charges was carried out. This evaluation determined that the function was not recognizing meaningful events in the presence of real load data (precisely, transactive feedback signals (TFS) data). While the inputs specified for this present function 7.1.1 have not changed from those in function 7.1, the pseudo code algorithm has been significantly simplified and has been shown through simulation to properly identify new demand peaks and their cost impacts.
This function predicts the impact of demand charges that the Bonneville Power Administration (BPA) will apply to its customer utilities according to interpretation of its intricate Tiered Rate Methodology (TRM). The TRM explains how BPA's demand charges are to be allocated to its customer utilities at the conclusion of each month. However, since the transactive control and coordination system is predictive, the demand charge impacts of the methodology should be predicted instead. This function can, at best, estimate the demand charge impacts from the TRM.
Many components of the TRM duplicate energy costs that will already be represented in the transactive incentive signal (TIS) by electrically upstream locations. Generally, transactive control applies energy costs at the points where electrical energy is generated and fed into the electrical power grid. These influences should not be duplicated or double-counted. Therefore, this function should only insert the unique demand charge impacts from the TRM that apply specifically to the utilities. This may be achieved by applying upward pressure to the TIS—by adding, to the TIS computation, the product of the pair of capacity cost CC and incremental demand PC—as the transactive feedback signal (TFS) predicts the occurrence of a peak that exceeds the highest peak that has already been recorded during the present calendar month prior to the start time (e.g., IST0) of the TFS. If the increased TIS, in turn, induces responsive assets to curtail load, the predicted peak may be lowered enough to prevent any additional demand charge.
Normally, an electric utility would be the entity to apply this function. This function applies to a “utility” transactive node or to the transactive node that represents the perspective of an electric utility.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Description:
This function predicts the impacts of energy and demand charges that the Seattle City Light (SCL) will apply to the University of Washington (UW). SCL supplies the UW with most of its electricity.
This function applies the impact of its energy charges to the weighted cost for the total energy imported into UW's energy territory from the TZ02 (West Washington) transmission zone transactive node. This is achieved through the addition of an “other” cost component CO to the numerator of the TIS computation at UW's transactive node.
Although the SCL's demand charges are to be allocated at the conclusion of each month, since the transactive control and coordination system is predictive, the demand charge impacts should be predicted instead. This function can, at best, estimate the demand charge impacts. UW expects to minimize its monthly SCL demand changes by using this function to apply upward pressure to its TIS when its transactive feedback signal (TFS) predicts the occurrence of a peak in its load. This is achieved by adding the product of the pair of capacity cost CC and average power capacity PC to the numerator of its TIS computation whenever its TFS exceeds the highest peak that has already been recorded during the time elapsed for the calendar month prior to the start time (e.g., IST0). The product CC·PC thus represents the incremental demand charge that UW would incur if a new peak were to happen. If the increased TIS, in turn, applies enough downward pressure on the TFS (e.g. through load curtailment), the predicted peak may be lowered enough to prevent any additional demand charge. It should be noted that, because the SCL demand charges apply to the maximum demand during the month, the charges can only be minimized and not completely eliminated. This function is to be applied at UW's transactive node.
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
∀n,CO,n=(x·δpeak+y·δoffpeak)·TFSTZ02,n·Δtn (4)
where
x=portion/fraction of n lying within peak
y=portion/fraction of n lying within offpeak, (5)
and
Δtn=ISTn+1−ISTn (6)
For the next iteration, Pmax_peak=36000 kW and Pmax_offpeak=36000 kW.
In the above table, TFSTZ02=TFS, but some mismatch should be expected in reality. TISTZ02 is not required as an input to this function. It is simply being used in this example for the computation of TIS. It is shown as constant here, but is more like to have some variation in reality. TIS is neither an output of or input to this function, but is given in this example to show the impacts of both SCL energy and demand charges. In certain embodiments, TIS can be computed as follows:
Description:
This function is to be used by a utility that wishes to mitigate the impacts that it will likely incur in spot markets. This function modifies the transactive incentive signal so that the utility's resources may help the utility respond to its participation in the spot market.
Refer to
Base load—large blocks of constant capacity that will have been procured far in advance of the day on which it will be used.
Term trading—procurement of coarsely shaped energy supply far in advance of the day on which it will be used.
Pre-scheduled trading—procurement of well-shaped energy supply that should be settled no later than the morning before the day on which the energy will be used.
Spot market trading—procurement of “real-time” energy needs that should be settled just shortly before the beginning of the hour in which the energy will be used. The purpose of this trading is to obtain an accurate, final balance between forecasted load and energy resources. The energy traded on a spot market is among the most expensive energy resources in a utility's resource mix. Surplus energy may be sold in the spot market. A spot market usually addresses hourly periods, but a trend has begun to shorten the intervals to 30 minutes or even shorter.
The transactive signals calculated at a transactive node will have incorporated the costs and energy from base load, term, and some of pre-scheduled energy resources that will be known from published schedules. However, the resources procured from “real-time” spot market trading may not be predictable far in advance. Furthermore, the strategies and trades may not be revealed by traders due to regulations and the business sensitivity of this information.
This function specifies two mechanisms by which the impacts of spot market trading should influence the transactive incentive signal:
Block Input/Output Function Model:
Inputs:
Interim Calculation Products:
Outputs:
Pseudo Code Implementation:
Description:
This function addresses the importation of electrical energy from outside a transactive node from entities that are not themselves transactive nodes—are not participants in this transactive control and coordination system. This function should be applied at transactive nodes that are scheduled to receive bulk electrical energy from outside the boundaries of the transactive control and coordination system. The California-Oregon Intertie is an example of such a connection that could potentially import energy into a transactive control and coordination system.
It is challenging to generalize this function because the non-transactive sources of imported energy are diverse. However, the energy predicted to flow to or from sources will typically have been scheduled by balancing authorities and other entities that are responsible to negotiate the flow of electrical power to and from the sources. Usually, wholesale market forces determine the cost of the scheduled energy, although such costs may not be promptly known from indices or other records and should therefore be predicted from past trends. Therefore, this function is simply represented as a translation of the scheduled energy and its corresponding predicted energy costs into the parameters of the toolkit framework.
Pseudo Code Implementation:
PG—Series of average power energy terms expected by the toolkit framework (example units: average kW). Series members correspond to IST intervals.
CE—Series of energy cost terms expected by the toolkit framework (example units: $/kWh). Series members correspond to IST intervals.
Total energy—Interim calculation of total energy that is exchanged over the duration of a given IST interval (example units: kWh).
Included duration—The fractional part of a schedule interval that also lies within a given IST interval (example units: seconds).
IST duration—The duration of a given IST interval (example units: seconds). In some embodiments, IST intervals are 5 minutes, 15 minutes, 1 hour, 6 hours, or 1 day long.
Scheduled cost—The index or market price that corresponds to the energy exchanged during a given scheduled interval (example units: $/kWh). This cost may be obtained through an informed simulation based on historical data and trends.
Scheduled power—The average power scheduled to be exchanged during a given schedule interval (example units: kW).
Introduction
Distributed control typically uses tools to assess effects of actions by distributed calculation. The challenge has been to predict power flow to and from neighbor nodes. When generation or loads change at the present node, it may be impossible to allocate such change among the power flow to and from neighbors without global knowledge.
Additionally, embodiments discussed herein might have ramifications for even centralized solvers as possible solution accelerator. Further, parallel calculations are enabled and global management of power angle becomes unnecessary.
Further, some embodiments exhibit iterative improvement of the solution occurs over time.
Discussion
The example method introduced below is formulated for distributed transactive control, where decisions are made independently at distributed locations to respond to an incentive signal. The impacts of these decisions on power flow are desirably predicted, which is presently challenging to do with conventional power flow formulations.
The example method is “relative” in that the objective of a node is to locate itself among neighbor nodes while assuming that the vector positions of those nodes do not change during an iteration. In this example, each node considers its own vector state location to be its system reference.
A node does not necessarily have to know its neighbor's state. In fact, there is not necessarily any system reference by which a node could make such an assessment. The relative vector state of a neighbor may be adequately inferred by receiving from that neighbor its anticipated complex power flow between it and the present node. It is not necessary even that the neighbors perfectly agree on the impedance of the transmission corridor between them.
A node's performance using this example method may be configured to improve over time with learning. Eventually, a node is able to test its prediction as the predicted time (or interval) occurs and passes.
The method is an embodiment of a Newton-Raphson relaxation method. The number of iterations of this method versus conventional power flow approaches will vary from implementation to implementation. Overrelaxation and other acceleration methods may be applicable. The power error can be used to assess status of the solution, or can assess ongoing dynamic system flux where the process is allowed to track updates to predicted states in “real time.”
The approach can be demonstrated using a simple example where a node interacts with only two neighbors and must assess its relative power flow state from information reported by these two neighbors. Let this node have no real or reactive generation or load. One possible flow state having small power error is shown in diagram 9800 of
In step 1, assume that a perturbation has occurred at node 2 and it reports 1.2+j1.0 should now be leaving the center node. Node 1 reports an unchanged complex power flow of 1.0+j1.0.
In step 2, the new power error is calculated to be −0.2 because there now appears to be 0.2 more real power leaving this node than entering it.
In step 3, the voltage and angle of node 2 is corrected to match the complex power that is reported to the present node by node 2. This is illustrated in diagram 9900 of
In step 4, the present variability of power is assessed based on the state determined in step 3.
In step 5, solve for the corresponding changes of this node's voltage and angle that will help resolve the power error. The voltage and angle of this node are updated accordingly.
Δδ0=−0.0100 radians=0.573° ΔV0=0.001
In step 6, real and reactive power to be exchanged with neighbor nodes is recalculated using the new voltage and angle for the present node. The implications of this calculation are shown in diagram 10000 of
Interestingly, the result of fast decoupled calculations at this node would have been resulted in about the same result.
1. Real and reactive power flow between this and neighbor node:
Apparent power:
Voltage at this node is defined as V0·ejδ
where a common practice has been adopted of representing the impedance between the nodes by the reactance component only.
By substitution of these values into Eq. AI.,
Real power leaving this node to node n is the real part of the apparent power:
Reactive power leaving this node to node n is the imaginary component of the apparent power:
2. Given power and reactive power, calculate neighbor's voltage and relative angle.
The reactive power equation can be used to solve for neighbor's voltage and relative angle. First solve Eq. A4 for Vn with respect to the relative angle.
By substitution of Vn into Eq. A3, the relative angle may be calculated in terms of known variables.
And by substitution of the relative angle of Eq. A6 into Eq. A5,one can solve for Vn also in terms of known variables:
3. Jacobian sensitivities of power at this node to changes in this node's voltage and relative angles:
Differentiate Eq. A3 for every neighbor node n with respect to V0 and with respect to the relative power angle δ0−δn to get Eq. A8 and Eq. A9:
This formulation will assume that δn remains constant through this iteration. Solving with respect to this node's angle,
4. Jacobian sensitivities of reactive power at this node to changes in this node's voltage and relative angles:
Similar to what was done above, differentiate Eq. A4 for every neighbor node n with respect to V0 and with respect to the relative power angle δ0−δn to get Eq. A11 and Eq. A12:
Remembering that δn remains constant through this iteration and solving with respect to this node's angle,
5. Power and reactive power error definitions:
6. Calculate voltage and angle of this node.
In a traditional power flow calculation, linear expansion would be completed about all power angle and voltage states. For example,
In the present, relative formulation, assume δn and Vn are constant through each iteration at this node. Eq. A16 can be simplified to
Remembering Eq. A8 and Eq. A1D, by substitution,
Similarly, for Q, a traditional linearization might result in
In the present, relative formulation, assume δn and Vn are constant through each iteration at this node. Eq. A19 can be simplified to
Remembering Eq. A1l and Eq. A13, by substitution,
Having illustrated and described the principles of the disclosed technology, it will be apparent to those skilled in the art that the disclosed embodiments can be modified in arrangement and detail without departing from such principles. For example, any one or more aspects of the disclosed technology can be applied in other embodiments. In view of the many possible embodiments to which the principles of the disclosed technologies can be applied, it should be recognized that the illustrated embodiments are only preferred examples of the technologies and should not be taken as limiting the scope of the invention.
This application is a divisional of U.S. application Ser. No. 14/108,078, filed on Dec. 16, 2013, now U.S. Pat. No. 10,740,775, which claims the benefit of U.S. Provisional Application 61/737,726 filed on Dec. 14, 2012, and entitled “TRANSACTIVE CONTROL FRAMEWORK AND TOOLKIT FUNCTIONS”, both of which are hereby incorporated herein by reference.
This invention was made with government support under DE-OE0000190 awarded by the Department of Energy. The government has certain rights in the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 2042187 | Powers et al. | May 1936 | A |
| 4010614 | Arthur | Mar 1977 | A |
| 4482814 | Daniels | Nov 1984 | A |
| 5572438 | Ehlers et al. | Nov 1996 | A |
| 5684710 | Ehlers et al. | Nov 1997 | A |
| 5696695 | Ehlers et al. | Dec 1997 | A |
| 5924486 | Ehlers et al. | Jul 1999 | A |
| 6021402 | Takriti | Feb 2000 | A |
| 6047274 | Johnson et al. | Apr 2000 | A |
| 6216956 | Ehlers et al. | Apr 2001 | B1 |
| 6343277 | Gaus et al. | Jan 2002 | B1 |
| 6633823 | Bartone et al. | Oct 2003 | B2 |
| 6681156 | Weiss | Jan 2004 | B1 |
| 6895325 | Munson, Jr. | May 2005 | B1 |
| 6963854 | Boyd et al. | Nov 2005 | B1 |
| 6970714 | D'Souza et al. | Nov 2005 | B2 |
| 7043380 | Rodenberg et al. | May 2006 | B2 |
| 7085739 | Winter et al. | Aug 2006 | B1 |
| 7130719 | Ehlers et al. | Oct 2006 | B2 |
| 7135956 | Bartone et al. | Nov 2006 | B2 |
| 7141321 | McArthur et al. | Nov 2006 | B2 |
| 7243044 | McCalla | Jul 2007 | B2 |
| 7249169 | Blouin et al. | Jul 2007 | B2 |
| 7343226 | Ehlers et al. | Mar 2008 | B2 |
| 7343360 | Ristanovic et al. | Mar 2008 | B1 |
| 7379997 | Ehlers et al. | May 2008 | B2 |
| 7395252 | Anderson et al. | Jul 2008 | B2 |
| 7418428 | Ehlers et al. | Aug 2008 | B2 |
| 7516106 | Ehlers et al. | Apr 2009 | B2 |
| 7587330 | Shan | Sep 2009 | B1 |
| 7599866 | Yan et al. | Oct 2009 | B2 |
| 7716101 | Sandholm et al. | May 2010 | B2 |
| 7953519 | Hamilton, II et al. | May 2011 | B2 |
| 7996296 | Lange | Aug 2011 | B2 |
| 8126794 | Lange et al. | Feb 2012 | B2 |
| 8271345 | Milgrom et al. | Sep 2012 | B1 |
| 8504463 | Johnson et al. | Aug 2013 | B2 |
| 8527389 | Johnson et al. | Sep 2013 | B2 |
| 8577778 | Lange et al. | Nov 2013 | B2 |
| 8639392 | Chassin | Jan 2014 | B2 |
| 9395707 | Anderson et al. | Jul 2016 | B2 |
| 20010032029 | Kauffman | Oct 2001 | A1 |
| 20020002414 | Hsiung | Jan 2002 | A1 |
| 20020038279 | Samuelson et al. | Mar 2002 | A1 |
| 20020091626 | Johnson et al. | Jul 2002 | A1 |
| 20020103745 | Lof et al. | Aug 2002 | A1 |
| 20020128747 | Mima | Sep 2002 | A1 |
| 20020132144 | McArthur et al. | Sep 2002 | A1 |
| 20020178047 | Or et al. | Nov 2002 | A1 |
| 20030014379 | Saias et al. | Jan 2003 | A1 |
| 20030023540 | Johnson et al. | Jan 2003 | A2 |
| 20030036820 | Yellepeddy | Feb 2003 | A1 |
| 20030040844 | Spool et al. | Feb 2003 | A1 |
| 20030040845 | Spool et al. | Feb 2003 | A1 |
| 20030041002 | Hao et al. | Feb 2003 | A1 |
| 20030041016 | Spool et al. | Feb 2003 | A1 |
| 20030041017 | Spool et al. | Feb 2003 | A1 |
| 20030055774 | Ginsberg | Mar 2003 | A1 |
| 20030078797 | Kanbara et al. | Apr 2003 | A1 |
| 20030093332 | Spool et al. | May 2003 | A1 |
| 20030093357 | Guler et al. | May 2003 | A1 |
| 20030139939 | Spool et al. | Jul 2003 | A1 |
| 20030144864 | Mazzarella | Jul 2003 | A1 |
| 20030149672 | Laskoski | Aug 2003 | A1 |
| 20030171851 | Brickfield et al. | Sep 2003 | A1 |
| 20030210658 | Hernandez et al. | Nov 2003 | A1 |
| 20030216971 | Sick et al. | Nov 2003 | A1 |
| 20040010478 | Peljto et al. | Jan 2004 | A1 |
| 20040015428 | Johnson et al. | Jan 2004 | A2 |
| 20040024483 | Holcombe | Feb 2004 | A1 |
| 20040128266 | Yellepeddy et al. | Jul 2004 | A1 |
| 20040133529 | Munster | Jul 2004 | A1 |
| 20040140908 | Gladwin et al. | Jul 2004 | A1 |
| 20040153330 | Miller et al. | Aug 2004 | A1 |
| 20040225649 | Yeo et al. | Nov 2004 | A1 |
| 20040254688 | Chassin et al. | Dec 2004 | A1 |
| 20050015283 | Iino et al. | Jan 2005 | A1 |
| 20050027636 | Gilbert et al. | Feb 2005 | A1 |
| 20050065867 | Aisu et al. | Mar 2005 | A1 |
| 20050114255 | Shields et al. | May 2005 | A1 |
| 20050125243 | Villalobos | Jun 2005 | A1 |
| 20050137959 | Yan et al. | Jun 2005 | A1 |
| 20050197875 | Kauffman | Sep 2005 | A1 |
| 20050228553 | Tryon | Oct 2005 | A1 |
| 20060036357 | Isono et al. | Feb 2006 | A1 |
| 20060195229 | Bell et al. | Aug 2006 | A1 |
| 20060241951 | Cynamom et al. | Oct 2006 | A1 |
| 20060259199 | Gjerde et al. | Nov 2006 | A1 |
| 20060293980 | Corby et al. | Dec 2006 | A1 |
| 20070005192 | Schoettle et al. | Jan 2007 | A1 |
| 20070011080 | Jain et al. | Jan 2007 | A1 |
| 20070038335 | McIntyre et al. | Feb 2007 | A1 |
| 20070061248 | Shavit et al. | Mar 2007 | A1 |
| 20070087756 | Hoffberg | Apr 2007 | A1 |
| 20070124026 | Troxell et al. | May 2007 | A1 |
| 20080021628 | Tryon | Jan 2008 | A1 |
| 20080027639 | Tryon | Jan 2008 | A1 |
| 20080039980 | Pollack et al. | Feb 2008 | A1 |
| 20080046387 | Gopal et al. | Feb 2008 | A1 |
| 20080051977 | Tryon | Feb 2008 | A1 |
| 20080243664 | Shavit et al. | Oct 2008 | A1 |
| 20080243682 | Shavit et al. | Oct 2008 | A1 |
| 20080243719 | Shavit et al. | Oct 2008 | A1 |
| 20080281663 | Hakim | Nov 2008 | A1 |
| 20080297113 | Saeki et al. | Dec 2008 | A1 |
| 20080300907 | Musier et al. | Dec 2008 | A1 |
| 20080300935 | Musier et al. | Dec 2008 | A1 |
| 20080306801 | Musier et al. | Dec 2008 | A1 |
| 20080307399 | Zhou et al. | Dec 2008 | A1 |
| 20080319893 | Mashinsky et al. | Dec 2008 | A1 |
| 20090063228 | Forbes | Mar 2009 | A1 |
| 20090132360 | Arfin et al. | May 2009 | A1 |
| 20090177591 | Thorpe et al. | Jul 2009 | A1 |
| 20090195349 | Frader-Thompson et al. | Aug 2009 | A1 |
| 20090228151 | Wang et al. | Sep 2009 | A1 |
| 20090292402 | Cruickshank, III | Nov 2009 | A1 |
| 20090307059 | Young et al. | Dec 2009 | A1 |
| 20090313174 | Hafner et al. | Dec 2009 | A1 |
| 20100010939 | Arfin et al. | Jan 2010 | A1 |
| 20100049371 | Martin | Feb 2010 | A1 |
| 20100057625 | Boss et al. | Mar 2010 | A1 |
| 20100106332 | Chassin et al. | Apr 2010 | A1 |
| 20100106641 | Chassin et al. | Apr 2010 | A1 |
| 20100107173 | Chassin | Apr 2010 | A1 |
| 20100114387 | Chassin | May 2010 | A1 |
| 20100121700 | Wigder et al. | May 2010 | A1 |
| 20100138363 | Batterberry et al. | Jun 2010 | A1 |
| 20100179704 | Ozog | Jul 2010 | A1 |
| 20100179862 | Pratt et al. | Jul 2010 | A1 |
| 20100216545 | Lange et al. | Aug 2010 | A1 |
| 20100217550 | Crabtree et al. | Aug 2010 | A1 |
| 20100218108 | Crabtree et al. | Aug 2010 | A1 |
| 20100256999 | Ghani et al. | Oct 2010 | A1 |
| 20100332373 | Crabtree et al. | Dec 2010 | A1 |
| 20110015801 | Mazzarella | Jan 2011 | A1 |
| 20110016055 | Mazzarella | Jan 2011 | A1 |
| 20110018704 | Burrows | Jan 2011 | A1 |
| 20110029465 | Ito et al. | Feb 2011 | A1 |
| 20110081955 | Lange et al. | Apr 2011 | A1 |
| 20110137835 | Ito et al. | Jun 2011 | A1 |
| 20110301964 | Conwell | Dec 2011 | A1 |
| 20110316480 | Mills-Price et al. | Dec 2011 | A1 |
| 20120022700 | Drees et al. | Jan 2012 | A1 |
| 20120022995 | Lange | Jan 2012 | A1 |
| 20120053011 | Onomura et al. | Mar 2012 | A1 |
| 20120072039 | Anderson et al. | Mar 2012 | A1 |
| 20120072141 | Hidai et al. | Mar 2012 | A1 |
| 20120083930 | Ilic et al. | Apr 2012 | A1 |
| 20120143385 | Goldsmith | Jun 2012 | A1 |
| 20120278220 | Chassin et al. | Nov 2012 | A1 |
| 20130110304 | Shiga et al. | May 2013 | A1 |
| 20130268131 | Venayagamoorthy et al. | Oct 2013 | A1 |
| 20130325691 | Chassin et al. | Dec 2013 | A1 |
| 20130325692 | Chassin et al. | Dec 2013 | A1 |
| 20140188689 | Kalsi et al. | Jul 2014 | A1 |
| 20150111591 | Hoffberg | Apr 2015 | A1 |
| 20150214738 | Covic et al. | Jul 2015 | A1 |
| 20150379542 | Lian et al. | Dec 2015 | A1 |
| 20160141873 | Ellice-Flint et al. | May 2016 | A1 |
| 20160195866 | Tumey et al. | Jul 2016 | A1 |
| 20160248260 | Kulyk et al. | Aug 2016 | A1 |
| 20180196456 | EIBsat | Jul 2018 | A1 |
| 20180314220 | Kumar | Nov 2018 | A1 |
| 20180356770 | EIBsat et al. | Dec 2018 | A1 |
| 20180356782 | EIBsat et al. | Dec 2018 | A1 |
| 20180357577 | EIBsat et al. | Dec 2018 | A1 |
| 20190206000 | EIBsat et al. | Jul 2019 | A1 |
| 20200139842 | Logvinov et al. | May 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2678828 | Mar 2010 | CA |
| 1242932 | Sep 2002 | EP |
| 2911098 | Aug 2015 | EP |
| 2008-204073 | Sep 2008 | JP |
| WO 9901822 | Jan 1999 | WO |
| WO 0223693 | Mar 2002 | WO |
| WO 2007065135 | Jun 2007 | WO |
| Entry |
|---|
| Colson, C.M. and Nehrir, M.H., “Algorithms for Distributed Decision-Making for Multi-Agent Microgrid Power Management”, Jul. 24-28, 2011, IEEE Power and Energy Society General Meeting, DOI: 10.1109/PES.2011.6039764. (Year: 2011). |
| Zheng et al., “Stochastic Optimization for Unit Commitment: A Review,” IEEE Trans. on Power Systems, 30(4):1913-1924 (Jul. 2015). |
| Chua Liang Su, “Optimal Demand-Side Participation in Day-Ahead Electricity Markets,” The University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences (Jul. 2007). |
| Jiankang Wang, “A Demand Responsive Bidding Mechanism with Price Elasticity Matrix in Wholesale Electricity Pools,” MIT Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Science (May 21, 2009). |
| Larsen et al., “The Cobweb Effect in Balancing Markets with Demand Response,” European Commission through the project EcoGrid EU (grant ENER/FP7/268199) and by Mogens Balslev's Foundation (Jan. 29, 2016). |
| Richard Cowart, “Efficient Reliability, the Critical Role of Demand-Side Resources in Power Systems and Markets,” The National Association of Regulatory Utility Commissioners (Jun. 2001). |
| AEP gridSmart demonstration project, Available: http://www.gridsmartohio.com/, Aug. 2013, 1 page. (Feb. 2013). |
| AEP Ohio power company standard tariff, available at: https://www.aepohio.com/account/bills/rates/AEPOhioRatesTariffsOH.aspx, Issued: Aug. 28, 2015, 187 pages. (Feb. 2013). |
| Allcott, “Real Time Pricing and Electricity Markets,” Harvard University, Feb. 5, 2009, 77 pages. (Feb. 2013). |
| ANSI/CEA Standard, “Modular Communications Interface for Energy Management,” ANSI/CEA-2045, ISO/IEC JTC 1/SC 25 N2152, 98 pp. (Feb. 2013). |
| Basso, “IEEE 1547 and 2030 Standards for Distributed Energy Resources Interconnection and Interoperability with the Electricity Grid,” a Technical Report published by the National Renewable Energy Laboratory Dec. 2014, 22 pp. |
| Bergen et al., “A Structure Preserving Model for Power System Stability Analysis,” IEEE Trans. on Power Apparatus and Systems, pp. 25-35 (Jan. 1981). |
| Boch, “PJM Interconnection OPENADR 2.0 Advanced Technology Resource Pilot,” 5 pp. (Dec. 2014). |
| Borenstein et al., “Diagnosing Market Power in California's Deregulated Wholesale Electricity Market,” University of California Energy Institute, Power, PWP-064, 54 pp. (Aug. 2000). |
| Borenstein et al., “Diagnosing Market Power in California's Deregulated Wholesale Electricity Market,” University of California Energy Institute, Power, PWP-064, 52 pp. (Mar. 2000). |
| Boyd et al., “Load Reduction, Demand Response, and Energy Efficient Technologies and Strategies,” Pacific Northwest National Laboratory PNNL-18111, 44 pp. (Nov. 2008). |
| Brambley, “Thinking Ahead: Autonomic Buildings,” ACEEE Summer Study on the Energy Efficiency in Buildings, vol. 7, pp. 73-86 (2002). |
| Brooks et al., “Demand Dispatch,” IEEE Power and Energy Magazine, vol. 8, No. 3, pp. 20-29 (May 2010). |
| Callaway et al., “Achieving Controllability of Electric Loads,” Proc. IEEE, vol. 99, No. 1, pp. 184-199 (Jan. 2011). |
| Callaway, “Tapping the Energy Storage Potential in Electric Loads to Deliver Load Following and Regulation, with Application to Wind Energy,” Energy Conversion and Management, vol. 50, No. 5, pp. 1389-1400 (May 2009). |
| Chandley, “How RTOs Set Spot Market Prices (And How It Helps Keep the Lights On),” PJM Interconnection, 23 pp. (Sep. 2007). |
| Chao, “Price-Responsive Demand Management for a Smart Grid World,” Electr. J., vol. 23, No. 1, pp. 7-20 (2010). |
| Chassin et al., “Decentralized Coordination through Digital Technology, Dynamic Pricing, and Customer-Driven Control: The GridWise Testbed Demonstration Project,” The Electricity Journal, vol. 21, pp. 51-59 (Oct. 2008). |
| Chassin et al., “Gauss-Seidel Accelerated: Implementing Flow Solvers on Field Programmable Gate Arrays,” IEEE Power Engineering Society General Meeting, 5 pp. (Jun. 2006). |
| Chassin et al., “GridLAB-D: An open-source power systems modeling and simulation environment,” IEEE, 5 pp. (Apr. 2008). |
| Chassin, “GridLAB-D Technical Support Document: Tape Modules Version 1.0,” Pacific Northwest National Laboratory PNNL-17614, 8 pp. (May 2008). |
| Chassin, “GridLAB-D Technical Support Document: Commercial Modules Version 1.0,” Pacific Northwest National Laboratory PNNL-17615, 8 pp. (May 2008). |
| Chassin, “GridLAB-D Technical Support Document: Network Module Version 1.0,” Pacific Northwest National Laboratory PNNL-17616, 10 pp. (May 2008). |
| Chassin et al., “Load Modeling and Calibration Techniques for Power System Studies,” North American Power Symp., 7 pp. (Aug. 2011). |
| Chassin et al., “Modeling Power Systems as Complex Adaptive Systems,” Pacific Northwest National Laboratory PNNL-14987, 151 pp. (Dec. 2004). |
| Chassin et al., “Project 2.6—Enhancement of the Whole-Building Diagnostician,” Pacific Northwest National Laboratory PNNL-14383, 17 pp. (Aug. 2003). |
| Chassin, “The Abstract Machine Model for Transaction-based System Control,” Pacific Northwest National Laboratory PNNL-14082, 28 pp. (Nov. 2002). |
| Chassin, “Statistical Mechanics: A Possible Model for Market-based Electric Power Control”, Proc. of the 37th Hawaii Int'l Conf. on System Sciences, 10 pp. (Jan. 2004). |
| Chassin et al., “The pacific northwest demand response market demonstration,” IEEE, 6 pp. (Jul. 2008). |
| Chen et al., “The Influence of Topology Changes on Inter-area Oscillation Modes and Mode Shapes,” IEEE Power and Energy Society General Meeting, 7 pp. (Jul. 2011). |
| Chow et al., “A Toolbox for Power System Dynamics and Control Engineering Education and Research,” IEEE Trans. on Power Systems, vol. 7, No. 4, pp. 1559-1564 (Nov. 1992). |
| Chow et al., “Power System Toolbox, Version 3.0,” 123 pp. (2008). |
| Clearwater et al., “Thermal Markets for Controlling Building Environments,” Energy Engineering, vol. 91, No. 3, pp. 26-56 (1994). |
| Daily et al., “Framework for Network Co-Simulation,” Workshop on Next-Generation Analytics for the Future Power Grid, PowerPoint presentation, 20 pp. (Jul. 2014). |
| Denholm et al., “An Evaluation of Utility System Impacts and Benefits of Optimally Dispatched Plug-In Hybrid Electric Vehicles,” NREL Technical Report NREL/TP-620-40293, 30 pp. (Oct. 2006). |
| Denton et al., “Spot Market Mechanism Design and Competitivity Issues in Electric Power”, Proc. of the 31st Hawaii International Conference on System Sciences, vol. 3, pp. 48-56 (Jan. 1998). |
| Diao et al., “Deriving Optimal Operational Rules for Mitigating Inter-area Oscillations,” IEEE/PES Power Systems Conference & Exposition, 8 pp. (Mar. 2011). |
| Diao et al., “Electric Water Heater Modeling and Control Strategies for Demand Response,” Power and Energy Society General Meeting, 8 pp. (Jul. 2012). |
| Donnelly et al., “Autonomous Demand Response for Primary Frequency Regulation,” PNNL-21152, 69 pp. (Jan. 2012). |
| Dorfler et al., “Synchronization in Complex Oscillator Networks: A Survey,” Automatica, vol. 50, No. 6, pp. 1539-1564 (Jun. 2014). |
| Electric Power Research Institute, “IntelliGrid—Program 161,” 2014 Research Portfolio, 23 pp. (downloaded Dec. 2014). |
| Electric Reliability Council of Texas, Inc., “Glossary,” 59 pp. (document not dated—downloaded on Jul. 10, 2015). |
| Ellison et al., “Project Report: A Survey of Operating Reserve Markets in U.S. ISO/RTO-managed Electric Energy Regions,” SAND2012-1000, Sandia National Laboratories, 44 pp. (Sep. 2012). |
| Energy Star, “Energy Star® Program Requirements—Product Specification for Residential Refrigerators and Freezers, Eligibility Criteria,” Version 5.0, 10 pp. (Sep. 2014). |
| Fernandez et al., “Self Correcting HVAC Controls: Algorithms for Sensors and Dampers in Air-Handling Units,” Pacific Northwest Laboratory PNNL-19104, 49 pp. (Dec. 2009). |
| Fuller et al., “Analysis of Residential Demand Response and Double-Auction Markets,” IEEE Power and Energy Society General Meeting, 7 pp. (Jul. 2011). |
| Fuller et al., “Communication Simulations for Power System Applications,” Modeling and Simulation of Cyber-Physical Energy Systems Workshop, 6 pp. (May 2013). |
| Fuller et al., “Evaluation of Representative Smart Grid Investment Grant Project Technologies: Demand Response,” Pacific Northwest National Laboratory PNNL-20772, 349 pp. (Feb. 2012). |
| Fuller et al., “Modeling of GE Appliances: Cost Benefit Study of Smart Appliances in Wholesale Energy, Frequency Regulation, and Spinning Reserve Markets,” PNNL-22128, 64 pp. (Dec. 2012). |
| Fuller et al., “Modeling of GE Appliances in GridLAB-D: Peak Demand Reduction,” Pacific Northwest National Laboratory PNNL-21358, 157 pp. (Apr. 2012). |
| Gatterbauer, “Interdependencies of Electricity Market Characteristics and Bidding Strategies of Power Producers,” Master's Thesis, Massachusetts Institute of Technology, 33 pp. (May 2002). |
| GE Energy Consulting, “PSLF—Get It Done Faster with PSLF!,” downloaded from the World Wide Web, 2 pp. (2013). |
| Georgilakis, “Market Clearing Price Forecasting in Deregulated Electricity Markets Using Adaptively Trained Neural Networks,” Hellenic Conference on Artificial Intelligence, vol. 3955, pp. 56-66 (2006). |
| Gjerstad et al., “Price Formation in Double Auctions,” Games and Economic Behavior, vol. 22, article No. GA970576, pp. 1-29 (1998). (Document marked as Received Nov. 30, 1995). |
| Goldberg et al., “Measurement and Verification for Demand Response,” 123 pp. (Feb. 2013). |
| Green Car Congress, “PG&E and Tesla to Research Smart Recharging Vehicle-to-Grid Technology,” downloaded from http://www.greencarcongress.com/2007/09/pge-and-tesla-t.html, 3 pp. (Sep. 12, 2007). |
| Gridwise Architecture Council, “Transactive Energy Workshop Proceedings,” PNNL-SA-86105, 24 pp. (May 2011). |
| Guttromson et al., “Residential energy resource models for distribution feeder simulation,” IEEE, vol. 1, pp. 108-113 (Jul. 2003). |
| Hammerstrom et al., “Pacific Northwest GridWise Testbed Demonstration Projects: Part I. Olympic Peninsula Project,” Pacific Northwest National Laboratory PNNL-17167, 157 pp. (Oct. 2007). |
| Hammerstrom et al., “Pacific Northwest GridWise Testbed demonstration Projects: Part II. Grid Friendly Appliance Project,” Pacific Northwest National Laboratory PNNL-17079, 123 pp. (Oct. 2007). |
| Hammerstrom et al., “Standardization of a Hierarchical Transactive Control System,” Grid Interop Conf., 7 pp. (Nov. 2009). |
| Hammerstrom et al., “Standardization of a Hierarchical Transactive Control System,” Grid Interop Conf., PowerPoint presentation slides, 19 pp. (Nov. 2009). |
| Hao et al., “How Demand Response from Commercial Buildings Will Provide the Regulation Needs of the Grid,” 50th Annual Allerton Conf., 6 pp. (Oct. 2012). |
| Hatley et al., “Energy Management and Control System: Desired Capabilities and Functionality,” Pacific Northwest National Laboratory PNNL-15074, 46 pp. (Apr. 2005). |
| Hill et al., “Stability Analysis of Multimachine Power Networks with Linear Frequency Dependent Loads,” IEEE Trans. on Circuits and Systems, vol. 29, No. 12, pp. 840-848 (Dec. 1982). |
| Hô et al., “Econophysical Dynamics of Market-Based Electric Power Distribution Systems,” IEEE, pp. 1-6 (Jan. 2006). |
| Holmes, “Using AMI Data for DR M&V Webcast,” EPRI Powerpoint presentation, 21 pp. (May 2013). |
| Huang et al., “Analytics and Transactive Control Design for the Pacific Northwest Smart Grid Demonstration Project,” IEEE Int'l Conf. on Smart Grid Communications, pp. 449-454 (Oct. 2010). |
| Huang et al., “MANGO—Modal Analysis for Grid Operation: A Method for Damping Improvement through Operating Point Adjustment,” Pacific Northwest National Laboratory PNNL-19890, 92 pp. (Oct. 2010). |
| Huang et al., “Transforming Power Grid Operations,” Scientific Computing, vol. 45, No. 5, pp. 22-27 (Apr. 2007). |
| “IEEE P1547.8 Recommended Practice for Establishing Methods and Procedures that Provide Supplemental Support for Implementation Strategies for Expanded Use of IEEE Standard 1547,” retrieved Feb. 11, 2019 from http://grouper.ieee.org/groups/scc21/1547.8/1547.8_index.html, 1 p. |
| Kalsi et al., “Distributed Smart Grid Asset Control Strategies for Providing Ancillary Services,” PNNL-22875, 46 pp. (Sep. 2013). |
| Kalsi et al., “Loads as a Resource: Frequency Responsive Demand,” PNNL SA-23764, 49 pp. (Sep. 2014). |
| Kannberg et al., “GridWise: The Benefits of a Transformed Energy System,” Pacific Northwest National Laboratory PNNL-14396, 48 pp. (Sep. 2003). |
| Katipamula et al., “Evaluation of Residential HVAC Control Strategies for Demand Response Programs,” ASHRAE Trans., Symp. on Demand Response Strategies for Building Systems, 12 pp (Jan. 2006). |
| Katipamula et al., “Transactive Controls: A Market-Based GridWise Controls for Building Systems,” Pacific Northwest National Laboratory PNNL-15921, 14 pp. (Jul. 2006). |
| Kiesling, “Retail Electricity Deregulation: Prospects and Challenges for Dynamic Pricing and Enabling Technologies,” The Searle Center Annual Review of Regulation, 44 pp. (May 2007). |
| Kintner-Meyer et al., “Final Report for the Energy Efficient and Affordable Small Commercial and Residential Buildings Research Program—Project 3.3—Smart Load Control and Grid Friendly Appliances,” Pacific Northwest National Laboratory PNNL-14342, 147 pp. (Jul. 2003). |
| Koch et al., “Modeling and Control of Aggregated Heterogeneous Thermostatically Controlled Loads for Ancillary Services,” Proc. Power Systems Computation Conference, 8 pp. (Aug. 2011). |
| Kok et al., “Agent-based Electricity Balancing with Distributed Energy Resources, A Multiperspective Case Study,” Proc. Hawaii Int'l Conf. on System Sciences, 10 pp. (Jan. 2008). |
| Kok et al., “PowerMatcher: Multiagent Control in the Electricity Infrastructure,” AAMAS, 8 pp. (Jul. 2005). |
| Kundu et al., “Modeling and Control of Thermostatically Controlled Loads,” Power Systems Computation Conference, 7 pp. (Aug. 2011). |
| LeMay et al., “An Integrated Architecture for Demand Response Communications and Control,” Hawaii Int'l Conf. on System Sciences, 10 pp. (Jan. 2008). |
| Lian et al., “Distributed Hierarchical Control of Multi-area Power Systems with Improved Primary Frequency Regulation,” IEEE Annual Conf. on Decision and Control, pp. 444-449 (Dec. 2012). |
| Lu et al., “A State-Queueing Model of Thermostatically Controlled Appliances,” IEEE Trans. on Power Systems, vol. 19, No. 3, pp. 1666-1673 (Aug. 2004). |
| Lu et al., “Control Strategies of Thermostatically Controlled Appliances in a Competitive Electricity Market,” IEEE Proc. Power Engineering Society General Meeting, pp. 202-207 (Jun. 2005). |
| Lu et al., “Design Considerations for Frequency Responsive Grid Friendly Appliances,” IEEE PES Trans. and Distribution Conference and Exhibition, 6 pp. (May 2006). |
| Lu et al., “Grid Friendly Device Model Development and Simulation,” Pacific Northwest National Laboratory PNNL-18998, 52 pp. (Nov. 2009). |
| Lu et al., “Modeling Uncertainties in Aggregated Thermostatically Controlled Loads Using a State Queueing Model,” IEEE Trans. on Power Systems, vol. 20, No. 2, pp. 725-733 (May 2005). |
| Lu et al., “Reputation-Aware Transaction Mechanisms in Grid Resource Market,” IEEE Sixth Int'l Conf. on Grid and Cooperative Computing, 6 pp. (Aug. 2007). |
| Lu et al., “Simulating Price Responsive Distributed Resources,” IEEE, vol. 3, pp. 1538-1543 (Oct. 2004). |
| Lundstrom “An Advanced Platform for Development and Evaluation of Grid Interconnection Systems Using Hardware-In-The-Loop”, © Blake R. Lundstrom, 2013, 149 pp. |
| Ma, et al., “Dynamics of electricity markets with unknown utility functions: An extremum seeking control approach,” in 2014 11th IEEE International Conference on Control & Automation (ICCA), 2014, pp. 302-307. |
| Marinovici et al., “Distributed Hierarchical Control Architecture for Transient Dynamics Improvement in Power Systems,” IEEE Trans. on Power Systems, vol. 28, No. 3, pp. 3065-3074 (2013). |
| Mathieu et al., “State Estimation and Control of Electric Loads to Manage Real-Time Energy Imbalance,” IEEE Trans. on Power Systems, vol. 28, No. 1, pp. 430-440 (Feb. 2013). |
| Melton, “A Transactive Control Approach to Engaging Responsive Assets,” Connectivity Week, PowerPoint presentation slides, 14 pp. (May 2010). |
| Melton et al., “Transactive Control: An Approach for Widespread Coordination of Responsive Smart Grid Assets,” Pacitic Northwest Smart Grid Demonstration Project PowerPoint presentation slides, 19 pp. (May 2010). |
| Melton, “Transactive Control in Electricity Delivery,” Grid-Interop 2010, Pacific Northwest Smart Grid Demonstration Project, PowerPoint presentation slides, 15 pp. (Nov. 2010). |
| Melton, “Using Transactive Control to Engage Distributed Energy Resources,” Connectivity Week, PowerPoint presentation slides, 10 pp. (May 2011). |
| Molina-Garcia et al., “Decentralized Demand-side Contribution to Primary Frequency Control,” IEEE Trans. on Power Systems, vol. 26, No. 1, pp. 411-419 (2011). |
| Moya et al., “A Hierarchical Framework for Demand-Side Frequency Control,” American Control Conference, pp. 52-57 (Jun. 2014). |
| Moya et al., “A Hierarchical Framework for Demand-Side Frequency Control,” American Control Conference, PowerPoint presentation, 65 pp. (Jun. 2014). |
| Nanduri et al., “A Methodology for Evaluating Auction Based Pricing Strategies in Deregulated Energy Markets,” Working Paper, 12 pp. (2005). |
| Nanduri, et al., “A Reinforcement Learning Model to Assess Market Power Under Auction-Based Energy Pricing,” IEEE Trans. on Power Systems, vol. 22, No. 1, pp. 85-95 (Feb. 2007). |
| Narang et al., “IEEE Smart Grid Tutorial”, an IEEE Presentation dated Jan. 18, 2018, 31 pp. |
| Nicolaisen et al., “Market Power and Efficiency in a Computational Electricity Market With Discriminatory Double-Auction Pricing,” ISU Economic Report No. 52, 26 pp. (Aug. 27, 2000; revised Aug. 24, 2001). |
| Ns-3 Network Simulator, ns-3 Manual, Release ns-3.16, 126 pp. (Dec. 2012). |
| Pacific Northwest National Laboratory, “GridLAB-D—A Unique Tool to Design the Smart Grid,” PNNL-SA-92325, 4 pp. (Nov. 2012). |
| PJM Interconnection, “Description of Regulation Signals,” downloaded from the World Wide Web, 1 p. (document not dated—downloaded on Jul. 14, 2015). |
| PJM Interconnection, “Markets & Operations,” downloaded from the World Wide Web, 3 pp. (document not dated—downloaded on Jul. 14, 2015). |
| PJM Interconnection, Regulation Performance Senior Task Force, “Performance Based Regulation: Year One Analysis,” 22 pp. (Oct. 2013). |
| Plott et al., “Instability of Equilibria in Experimental Markets: Upward-sloping Demands, Externalities, and Fad-like Incentives,” Southern Economic Journal, vol. 65 (3), 23 pp. (Jan. 1999). |
| Pourebrahimi et al., “Market-based Resource Allocation in Grids,” IEEE Int'l Conf. on e-Science and Grid Computing, 8 pp. (2006). |
| Power World Corporation, “Simulator Version 14, User's Guide,” 1517 pp. (2009). |
| Pratt et al., “Potential Impacts of High Penetration of Plug-in Hybrid Vehicles on the U.S. Power Grid,” DOE/EERE PHEV Stakeholder Workshop, 14 pp. (Jun. 2007). |
| Satayapiwat et al., “A Utility-based Double Auction Mechanism for Efficient Grid Resource Allocation,” Int'l Symp. on Parallel and Distributed Processing with Applications (ISPA '08), pp. 252-260 (Dec. 10-12, 2008). |
| Schneider et al., “A Taxonomy of North American Radial Distribution Feeders,” IEEE Power & Energy Society General Meeting, 6 pp. (Jul. 2009). |
| Schneider et al., “Analysis of Distribution Level Residential Demand Response,” IEEE/PES Power System Conference and Exposition, 6 pp. (Mar. 2011). |
| Schneider et al., “Detailed End Use Load Modeling for Distribution System Analysis,” IEEE Power and Energy Society General Meeting, 7 pp. (Jul. 2010). |
| Schneider et al., “Distribution Power Flow for Smart Grid Technologies,” IEEE/PES Power System Conference and Exhibition, 7 pp. (Mar. 2009). |
| Schneider et al., “Evaluation of Conservation Voltage Reduction (CVR) on a National Level,” Pacific Northwest National Laboratory PNNL-19596, 114 pp. (Jul. 2010). |
| Schneider et al., “Modern Grid Strategy: Enhanced GridLAB-D Capabilities Final Report,” Pacific Northwest National Laboratory PNNL-18864, 30 pp. (Sep. 2009). |
| Schneider et al., “Multi-State Load Models for Distribution System Analysis,” IEEE Trans. on Power Systems, vol. 26, No. 4, pp. 2425-2433 (Nov. 2011). |
| Schneider et al., “Voltage Control Devices on the IEEE 8500 Node Test Feeder,” IEEE PES Transmission & Distribution Conference & Exposition, 6 pp. (Apr. 2010). |
| Shu et al., “Dynamic Incentive Strategy for Voluntary Demand Response Based on TDP Scheme,” Proc. IEEE Asia-Pacific Signal & Information Processing Association Annual Summit Conf., 6 pp. (Dec. 2012). |
| Siemens, “Power Transmission System Planning Software,” downloaded from the World Wide Web, 8 pp. (downloaded on Oct. 27, 2016). |
| Siljak et al., “Robust Decentralized Turbine/Govemor Control Using Linear Matrix Inequalities,” IEEE Trans. on Power Systems, vol. 17, No. 3, pp. 715-722 (Aug. 2002). |
| Siljak et al., “Robust Stabilization of Nonlinear Systems: The Lmi Approach,” Mathematical Problems in Engineering, vol. 6, No. 5, pp. 461-493 (Jun. 2000). |
| Singh et al., “Effects of Distributed Energy Resources on Conservation Voltage Reduction (CVR),” IEEE Power and Energy Society General Meeting, 7 pp. (Jul. 2011). |
| Subbarao et al., “Transactive Control and Coordination of Distributed Assets for Ancillary Services,” PNNL-22942, 56 pp. (Sep. 2013). |
| Taylor et al., “GridLAB-D Technical Support Document: Residential End-Use Module Version 1.0,” Pacific Northwest National Laboratory PNNL-17694, 30 pp. (Jul. 2008). |
| Trudnowski et al., “Overview of Algorithms for Estimating Swing Modes from Measured Responses,” Power Energy Society General Meeting, 8 pp. (Jul. 2009). |
| Varaiya et al., “Direct Methods for Transient Stability Analysis of Power Systems: Recent Results,” Proc. IEEE, vol. 73, No. 12, pp. 1703-1715 (1985). |
| Widergren et al., “AEP Ohio gridSMART® Demonstration Project: Real-Time Pricing Demonstration Analysis,” PNNL-23192, 92 pp. (Feb. 2014). |
| Widergren et al., “Residential Real-time Price Response Simulation,” IEEE Power and Energy Society General Meeting, pp. 3074-3078 (Jul. 2011). |
| Wikipedia, “Spec:Market—Market Module Overview,” downloaded from the World Wide Web, 19 pp. (last modified Jan. 2013). |
| Yin et al., “A Novel Double Auction Mechanism for Electronic Commerce: Theory and Implementation,” IEEE Proc. of the Third Int'l Conf. on Machine Learning and Cybernetics, pp. 53-58 (Aug. 2004). |
| Zhang et al., “Aggregated Modeling and Control of Air Conditioning Loads for Demand Response,” IEEE Trans. on Power Systems, vol. 28, No. 4, pp. 4655-4664 (Nov. 2013). |
| Zhao et al., “Fast Load Control with Stochastic Frequency Measurement,” IEEE Power and Energy Society General Meeting, 8 pp. (2012). |
| Zhao et al., “Frequency-based Load Control in Power Systems,” American Control Conf., pp. 4423-4430 (2012). |
| Zhao et al., “Swing Dynamics as Primal-dual Algorithm for Optimal Load Control,” IEEE Int'l Conf. on Smart Grid Comm., pp. 570-575 (2012). |
| Zimmerman et al., “A ‘SuperOPF’ Framework,” FERC Technical Conf. on Enhanced Optimal Power Flow Models, PowerPoint presentation, 39 pp. (Jun. 2010). |
| Number | Date | Country | |
|---|---|---|---|
| 20210097560 A1 | Apr 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61737726 | Dec 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14108078 | Dec 2013 | US |
| Child | 16795118 | US |
