Transactive controls

= Controller (Transactive Controller) = The transactive controller is based upon the design used in the Olympic Peninsula Project1. This controller provides price-responsive controls to individual objects, typically appliances, within GridLAB-D. The controller compares the current price signal to the average market price, each delivered by the auction object, and bids the appliance’s current demand as a function of price back into the auction. After the market clears all bids within the system and determines the next market price, the controller modifies the appliance’s set points to reflect operation at the new current price, often related to the standard deviation from the average set point. The set point that is modified depends upon the object to which the controller is modifying. At this time, only devices with continuous temperature set points may be used with the controller object.

Controller Inputs
Table 1: Controller inputs.

Description of Operation
The transactive controller refers broadly to a set of market-based building control systems, originally coined contract nets by Smith2. Consumers participating in the real-time market submit power demand and price bids into a two-way market system. Bids are made for both the controllable and un-controllable loads, where uncontrollable loads are bid at the market maximum price (typically $9999/kWh, or essentially infinite in the market system). The transactive controller should be able to bid either portion of the supply and demand curve, where a negative quantity represents generation.

Transactive Thermostatic Control (ramp)
As implemented now, the transactive controller is specifically designed to control thermostatic set points. By using market inputs, the heating and/or cooling set points can be explicitly controlled by the controller object to fit along the supply and demand curves of the system. While the Olympic Peninsula Project used 24 hour means and standard deviations, with five minute market clearing, within GridLAB-D, these values may be set to any length of time. However, in any designed case, the rolling average price, the rolling standard deviation, and the current market price will be used to determine the operational set point of the controller object. Future implementations should allow for other varieties, and will be described in greater detail later.

As an actual thermostat user, only a few parameters must be set. The first are the range_low and range_high settings, which determines the comfort zone the participant is willing to use. When referring to cooling set points, range_high determines how much higher the participant is willing to allow the temperature to climb before it becomes too hot for comfort, while range_low indicates the amount of pre-cooling allowed. For heating set points, these are reversed. The second setting is the slope of the piece-wise linear function that controls the coupling between the thermostat set points and the price (ramp_low and ramp_high or kT_L and kT_h in the Olympic Peninsula Project documentation). Essentially, this slope describes the participant’s willingness to participate in the market, and how willing they are to adjust their temperature settings as a function of the market price. While this is the background implementation within GridLAB-D, on an actual thermostat this might map onto a more user-friendly system, such as ‘money saver’ versus ‘keep it comfortable’. Figure 1 more fully demonstrates this operation and the operational set points for Figure 1 are shown in Table 2.

Table 2: Settings used in Figure 1.



Figure 1 provides an example of cooling set points with the transactive controller. For heating, the slope would be negative, but operation would be similar. The portion left of the base set point in Figure 1 indicates a pre-cooling state due to low market prices, while the area to the right indicates a condition that allows the temperature to rise slightly due to high prices. It shows that the participant is willing to allow the temperature to climb by 5 degrees during high prices, and pre-cool by -3 degrees during times of low market prices.

The current bid of the controller object is determined by where the current air temperature falls upon the bid curve, and is determined by

$$bid price = avg price + \frac{(T_{current} - T_{desired})*ramp_{high/low}*standard deviation}{|range_{high/low}|}$$. (1)

Average price and standard deviation are determined by the auction object associated with the controller; current temperature is a property of the house object imported by the controller; and ramp_high or ramp_low, range_high or range_low, and base set point are controller inputs. Ramp and range values are determined by which side of the base set point the current temperature presides during the bidding phase. If the current temperature is outside of the maximum or minimum range of the controller, the controller returns an “infinite” bid ($9999/kWh). After the controller object’s bid is determined, it is posted to the auction object, where in conjunction with all other market objects in the system the final cleared price is determined. How this price is determined is described in the auction object.

After the auction object has returned a cleared price, the adjusted thermostatic set point is determined by once again placing it on the bid curve through

$$T_{set} = \begin{cases} T_{desired} + (cleared price-avg price) * \frac{|range_{high/low}|}{ramp_{high/low} * standard deviation}, & \mbox{if }standard deviation\mbox{ is not 0} \\ T_{desired} & \mbox{if }standard deviation\mbox{ is 0} \end{cases} $$(2)

$$T_{set}$$ is now the thermostat’s adjusted set point. If the current temperature is higher than the adjusted set point plus the thermostat’s deadband, then cooling will occur. This will occur every time the controller objects cycles a length of time equal to the period. Future implementations may include adjustments for deadband regions when bidding and responding to price signals, or may instead override one side of a deadband region and force the thermostat to respond when this occurs. This is an area of on-going research, and some of these concerns are addressed in the double_controller object.

In addition to the bid price, the controller object must be able to pass demand and load information back to the auction object, if required. Controllable, and in some cases, uncontrollable load must be accounted for, depending on the settings used within the market system or auction object. These are used by the auction object to resolve the amount of uncontrollable and controllable load on the entire system and then determine the amount of flexibility within the system to reduce or increase the load using a price signal. The uncontrollable load should only pertain to the actual object being controlled. When controlling HVAC, the uncontrollable load would be the continuous base load of the HVAC system that cannot be affected. This might include a circulation fan that is on at all times, or power drawn by the thermostat, but should not include other appliances within the house. The controller must also deliver the controllable load or the demand of the HVAC system if it was to turn on. The total of the controllable and uncontrollable loads of an object should equal the rated capacity of the object; however, in multiple state objects, the sum of the actual used load may be less than rated capacity. Additionally, the controller object needs to pass the current state of the object. For example, with an HVAC system, this may be a simple on/off statement, but with more complex systems, this will need to include auxiliary versus regular heating modes, different fan speed settings, etc., as these affect the amount of power being drawn by the appliance.

Any thermostatic set point should be controllable by this object. This can be applied to the heating or cooling set points within the house, or the tank set point within the water heater. Heating bid curves can be designed by using a negative slope. Future implementations will include the ability to generate more generic control functions, allowing for non-linear functions and functions that are not necessarily dependent upon the average or standard deviations of the system. Additionally, functions for non-thermostatic controls will be included.

Simple settings will also be developed for easy connections to standard objects. This is loosely described as simple_mode in Table 1, and as more objects are added with connections to the transactive controller, additional pre-built connections should be created. Additionally, a simple user interface for the ramp_high, ramp_low, range_high, and range_low settings will be included. This will be based on a simple slider setting that varies between 0% and 100%, where 100% represents maximum participation in the market ("save money"), while 0% represents no participation ("keep my temperature"). Heating and cooling sliders will be set independently, and will default to cooling ranges of -3 to 5 and heating ranges of -5 to 3, unless a simple_mode is chosen which limits those ranges or a range_high or range_low is chosen by the user. The range and ramp settings are given by Table 3.

'''Table 3: Easy to use slider settings. Range_low/high-limit is not a new variable, but is the maximum range defined by the user (or default) if slider were at 100%. '''

Double Control (double_ramp)
Double control attempts to resolve conflicts between heating and cooling set points, and is only designed to work with an HVAC system. When double_ramp is selected, appropriate checks and connections should be made to connect it with the parent house.

There are two specified modes within double_ramp which resolves clashes between the two set points during low price signals. Often, heating and cooling set points are close enough together, that if both pre-cool and pre-heat are allowed during low prices, a conflict may occur where both operations are requested. This is shown in Figure 2. In either operational mode (deadband or sliding), if the pre-cooling set point plus the deadband overlaps the heating set point, or vice versa for the pre-heating set point, a warning should be thrown and the pre-heating or pre-cooling setpoint reduced to a point where it no longer overlaps the user cooling or heating setpoint. This should be done as a real time check, not as an initialization. For example, if the cooling setpoint were 70F and the heating setpoint 67F with a deadband of 2F and a pre-cooling of -3F, the pre-cooling setpoint would try to move to as much as 67F. However, the pre-cooling setpoint should be limited to the heating setpoint + deadband (67F + 2F = 69F).

Deadband operation resolves the set point conflict by taking the average of the base cooling and base heating set points to determine a midpoint and then sets the cooling and heating set points equidistant from the midpoint. The distance from the midpoint is equal to one-half the deadband setting. This operation is shown in Figure 3. This guarantees that there is no overlap of the deadbands between the cooling and heating set points; however, maximum pre-cooling and pre-heating will not be achieved if the set points are too close together, so some benefits are lost. Bids to the auction object are determined by which regime the current air temperature falls within, and follow equations 1 and 2.





Sliding mode tries to maximize the amount of pre-cooling and pre-heating performed, while still resolving the collision. In sliding mode, the previous active mode of the HVAC system is stored. The active modes include heating or cooling, and not on or off. If the previous HVAC mode were to be cooling, then the pre-cooling mode would dominate the pre-heating mode. This assumes that if the HVAC were previously cooling, then the user would desire it to continue cooling and not switch to a heating mode. The pre-cooling region will extend to its defined range, while the pre-heating range will be reduced to the pre-cooling range minus the deadband. This operation is shown in Figure 4. If the previous HVAC mode were to be heating, then the pre-heating range would dominate and pre-cooling range would be reduced. Again, the bid price is determined by the regime in which the current air temperature falls and follows equations 1 and 2. Additionally, a time delay setting should be included. This time delay lets the user specify how long the "last mode" is stored before it re-checks the current operational mode - this only applies when moving between COOL and OFF or HEAT and OFF. If the HVAC system transitions from COOL to HEAT (this may be in the series of COOL to OFF to HEAT), this should reset the time delay. Time delay should default to 0 seconds (no time delay and the controller perfectly tracks the HVAC system mode in real time).



Testing Specifications
Specific tests must be designed to ensure that the operation of the controller is correct. This section will loosely describe the tests that should be designed to ensure proper operation of the controller device. These tests will be implemented as part of the auto-test features within GridLAB-D, and are tested on a continuous basis to ensure continuously proper operation of the objects. These tests are designed only to verify the correct operation of the controller object, not the auction object. Since a controller object cannot operate on its own, it is understood that a number of the tests designed will test not only the operation of the controller object, but also the auction object or house object. However, this list should specify the minimum requirements of the controller object itself.


 * Does the controller object receive the correct values at the correct time? In this case, correct does not imply that the values are correct, as this is the responsibility of the auction or parent object, but that the controller is receiving the signal produced by the objects at the correct time.


 * Design a simple market signal and verify that the controller receives the correct average price and standard deviation signals at the correct time when using an inelastic market (bids back into the market do not affect the price signal). This should be tested for various time periods, including those that do not match with the time period specified in the auction object. If the time periods do not synchronize, then the controller object should still be able to receive the correct signal.
 * Design a simple market signal that is not static, but varies with the bid of the controller. Whether the cleared price or the bid of the controller is correct or not, the controller should still receive the price signals provided by the auction object as it varies with time. Synchronized and unsynchronized periods should be tested.
 * Design a simple system that tests whether the controller appropriately gathers information from the parent object. All objects that are specified as being able to work with a controller should be tested. The gathered information should include demand, controllable and uncontrollable load, current conditions (e.g. air temperature), current state of the object (e.g. on/off), set point and target properties. It should be verified that these signals are being updated at the correct time intervals.


 * Does the controller supply the auction object with the correct bidding information?
 * Design a simple market signal that does not vary over time and is inelastic. Verify with a variety of controller settings (modify ramp high and low, temperature minimum and maximum, base set point, etc.) that bid price is correctly calculated according to equation 1, and that bid quantity accurately represents the controllable load at that price via equation 2. This will be especially important with multi-state objects, as each state will need to be tested individually.
 * Design a simple market signal that varies over time, but is still inelastic. Again verify with a variety of controller settings that bid prices and quantities are being correctly calculated according to equations 1 and 2.


 * Does the controller and parent object correctly respond to the returned market signal? This will be highly dependent upon the parent object of the controller, so only general tests will be described.
 * Design a constant, inflexible market signal. Verify that the controller, attached to all available objects, correctly modifies the object set point. For the transactive and double control modes, this means that equation 2 is correctly calculated, then posted to the parent object. Additionally, for the double control, the resolution of the conflicted region must be correctly handled.

= Passive Controller (non-bidding controller) = This controller is similar to the transactive controller, except without the capability to bid back into the auction object. It is designed as a passive demand response controller, which only receives price signals from the market and responds accordingly. Additionally, it is used as a test bed for future transactive controller strategies, as it is easier to implement a passive response than an active bidding market. This style of controller is more likely to be used with Time-of-Use (TOU) or Critical Peak Price (CPP) market, rather than a Real Time Price (RTP) market. The passive_controller object will be able to attach to either an auction or stubauction object, where the stubauction allows the user to create a market that is not capable of receiving bids and only delivers a taped average and standard deviation. While a number of strategies exist within passive_controller, only the major modes will be defined here and are selected with the variable control_mode.

Ramp
The RAMP control_mode is similar in action to the original Olympic Peninsula transactive controller, minus the ability to bid into the market. It is also a generic version of the transactive controller, allowing the user to control the set point using parameters other than average price or temperature, such as frequency or an artificial demand signal. It uses a piece-wise linear function to adjust the set point as a function of a defined parameter and standard deviation from the defined parameter. Required variables are shown in Table 3.

Table 3: Ramp control mode required parameters.

Probabilistic Off (prob_off)
Probabilistic off is similar in nature to the Olympic Peninsula Project application to the hot water heater. As a typical water heater does not typically have a temperature measurement, implementation of a temperature vs. price signal is difficult. Essentially, the appliance will operate normally during a low or average price event. During a high price event, if the appliance desires to turn on or stay on, then the appliance applies a probabilistic curve to determine if it will shut off or perform as normal. A participation level was determined by the user through a comfort setting. A randomly drawn number from

$$r = k_w * (N(P_{clear}, P_{avg}, P_{std})-0.5), r \ge 0$$ (3)

where

$$N(P_{clear},P_{avg},P_{std}) = \frac{1}{\sqrt{2\pi}P_{std}} \int_{-\infty}^{P_{clear}} e^{-\frac{(P_{avg}-x)^2}{(2P_{std}^2)}}dx\ $$

was chosen. If r <= 0, then the device will operate normally. A cutoff is then chosen from a randomly drawn uniform distribution. If r is greater than the chosen cutoff number, then the water heater is turned off, otherwise it operates normally.

Future implementations of this device should include distributions other than a cumulative normal distribution functions, especially uniform and exponential. Additionally, implementation should include multi-state abilities. For example, the water heater could contain two heating coils, each of 2 kW. At a higher price, there would be a strong possibility of one of the coils cutting out, while the second coil has a much lower probability of cutting out. This is only an example, but the controller object should be built to handle this type of configuration.

Table 4: Probabilistic control mode required parameters.

Additional cumulative distribution functions:

Exponential: $$r = k_w * (1-e^{-\frac{P_{clear}}{P_{avg}}}), r \ge 0 $$. (4)

Uniform: $$r = k_w * ( \frac{P_{clear}-P_{avg}}{P_{avg}}), r \ge 0$$. (5)

Duty Cycle (duty_cycle)
Duty cycle mode will look at modifying the duty cycle as a function of price (or some other control signal). At an average price or below, the duty cycle would be 100% of the appliance’s normal operation (the duty cycle at this time may be 100% or lower, depending on the appliance). As price increases, the duty cycle of the appliance will decrease the overall amount of energy used during the time period by modifying the number of pulses delivered. For example, this could be applied to a drier unit. At the average price or below, the drier heating coil operates normally, say with an 80% duty cycle at 4.5 kW. As price increases, this duty cycle may fall to 60% or 40%, but still maintains the 4.5 kW demand at each pulse. Over a large, diverse population of units, this provides a reduction in demand. This mode will be highly dependent upon the type of appliance it is applied to, but the basic functionality shall be similar to the ramp control using a linear function to control the duty cycle. Additionally, for appliances that have only a limited number of duty cycles available, a discrete version should be created, where the appliance stays at one duty cycle until a cutoff (say of 1.5 standard deviations) is reached, and then it transitions to its next state.

Table 5: Duty cycle control mode required parameters.

ELASTICITY_MODEL
The ELASTICITY_MODEL control mode can be used to analyze the effects different Time of Use (TOU) and/or Critical Peak (CPP) pricing schemes have on certain loads. These loads are the non-HVAC, non-Water heater, price elastic loads like dryers, dishwashers, clothes washers etc. The ELASTICITY_MODEL control mode gives a method to analyze the 'price-elasticity' of these loads given a TOU/CPP pricing scheme. Loads which cannot be controlled without special appliance mechanisms are not to be considered with this model.

The elasticity model in Gridlab-d makes a decision on the 'price elasticity' of the load at a particular instant. For this it takes into account two price elasticity coefficients before making the decision - the Daily Elasticity Coefficient and Substitution Elasticity Coefficient.

The Daily Elasticity Coefficient is the proportionality constant between the log of the daily average energy usage and the log of the daily average price as shown below

$$\log(Q_{ave})=\alpha \log(P_{ave})$$

The Substitution Elasticity Coefficient is the proportionality constant between the log of the ratio of the peak/off-peak average energy usage and the log of the ratio of the peak/off-peak average price as shown below

$$\log(\frac{Q_{ave-Peak}}{Q_{ave-offPeak}})=\sigma \log(\frac{P_{ave-peak}}{P_{ave-offPeak}})$$

It can further be broken down into two different Substitution Elasticity Coefficients. The first relates the ratio of the Critical Peak and Off-Peak Energy to the ratio of the Critical Peak and Off-Peak Price values. The second relates ratio of the Peak and Off Peak Energy to the ratio of the Peak and Off Peak Price.

They are as shown below

$$\log(\frac{Q_{ave-criticalPeak}}{Q_{ave-offpeak}})=\sigma_{criticalPeak/offPeak} \log(\frac{P_{ave-criticalPeak}}{P_{ave-offpeak}})$$

and

$$\log(\frac{Q_{ave-Peak}}{Q_{ave-offpeak}})=\sigma_{Peak/offPeak} \log(\frac{P_{ave-Peak}}{P_{ave-offpeak}})$$

At the present moment, the ELASTICITY_MODEL control mode can only be used with the ZIPload object as the parent of the passive controller. It can handle both 2-tier and 3-tier pricing schemes. It can also handle both Critical (Event Day) Peak Pricing and Non-Event Day pricing schemes.

To use the ELASTICITY_MODEL control mode of the passive controller successfully with ZIPload object, the 'multiplier' property of the ZIPload should be specified as the state_property of the passive controller. The state_property should be specified as shown below.

Testing Specifications
As the controllers are similar, many of these tests will be similar to the tests used in the transactive controller, without the need to bid back into the auction object. In most cases, these tests should be performed using a stubauction object as opposed to an auction object.


 * Does the passive_controller object receive the correct values at the correct time? In this case, correct does not imply that the values are correct, as this is the responsibility of the auction or parent object, but that the controller is receiving the signal produced by the objects at the correct time.
 * Design a simple market signal and verify that the passive_controller receives the correct average price and standard deviation signals at the correct time when using both the auction and stubaction objects. This should be tested for various time periods, including those that do not match with the time period specified in the auction object. If the time periods do not synchronize, then the passive_controller object should still be able to receive the correct signal.
 * Design a simple market signal that is not static, but varies with the bid of another passive_controller. Verify that as the auction object signal changes with the bid of the active controller, the passive_controller is still receiving the correct signal at the correct time. Synchronized and unsynchronized periods should be tested.
 * Design a simple system that tests whether the passive_controller appropriately gathers information from the parent object. All objects that are specified as being able to work with a passive_controller should be tested. It should be verified that these signals are being updated at the correct time intervals.


 * Does the passive_controller and parent object correctly respond to the returned market signal? This will be highly dependent upon the parent object of the passive_controller, so only general tests will be described.
 * Design a constant, inflexible market signal. Verify that the passive_controller, attached to all available objects, correctly modifies the object set point. Test in all modes of operation.

1Hammerstrom, D. J. et. al., "Pacific Northwest GridWiseTM Testbed Demonstration Projects: Part I. Olympic Peninsula Project," Pacific Northwest National Laboratory, Richland, WA, Final Report, PNNL-17167, Oct. 2007.

2Smith, R. G., "The Contract Net Protocol: High-Level Communication and Control in Distributed Problem Solver," IEEE Transactions on Computers, vol. C-29, issue 12, pp. 1104-1113, Dec. 1980.

= See also = Market_User_Guide

Market_module

Market Specifications

Wholesale_Markets