Controllable capacity - Pyosch/powertac-server GitHub Wiki

up

Definition

Controllable capacity (called "demand management" in much of the literature) can represent production or consumption. Controllable devices in general are of two types: (1) their use is discretionary, or can be carried out over some range of time (running a dishwasher, for example), or (2) they incorporate some amount of (thermal or electrical) storage. Controllable devices can behave on a spectrum from fully-discretionary to fully-shiftable. Customers with controllable capacities may choose tariffs specifically designed for controllable capacities, or they may choose more general tariffs that do not provide for control. A tariff designed for controllable capacity may not be used for non-controllable loads.

  • Discretionary capacity is energy that can be used or produced if available/needed, otherwise not. A common example is a heat pump with a gas furnace as a backup. Another example might be a water pump that could be run using an electric motor or a diesel engine (or perhaps a windmill).
  • Shiftable capacity is capacity that can be shifted to a later timeslot, but total energy use over some time horizon is a function of customer needs and activities (and possibly weather). Batteries, either installed primarily for energy storage or as part of an electric vehicle, are shiftable, because they must be re-charged after being discharged. A solar array with auxiliary battery storage is an example of shiftable production capacity.

Many shiftable capacities are at least partially discretionary, since a water heater uses less energy overall if the temperature of the water drops, partly because less heat is lost through insulation, and in some cases because at least some of the water it delivers is at a lower temperature (although in many cases more is used to compensate). In the real world, shiftable capacities also vary in the time interval over which the shifted capacity is re-introduced, and in the maximum allowable interruption interval. Brokers should assume that controllable capacity is virtually all shiftable.

At any given time, a controllable device is characterized by three quantities: The rate at which it desires to use energy, the maximum possible rate, and the minimum acceptable rate. In the simulation, this translates to the desired energy usage in kWh in a given timeslot, the maximum usage, and the minimum usage.

Example

The figure below should help ground these ideas. At time start, an electric vehicle customer arrives home and plugs in the vehicle, which has some remaining charge level in its battery labeled as incoming. The customer requires at least outgoing charge in the battery by time end. The battery has a maximum charge rate, and a maximum discharge rate. The green region shows the allowable state of charge starting at time start and ending whenever the customer unplugs the vehicle. The battery capacity can be controlled as long as its state of charge remains within the feasible region, and as long as the maximum charge and discharge rates are respected.

figures/ev-charge-envelope.png

If the maximum charge rate is 5 kW, the maximum discharge rate is -5kW, and the nominal rate is 3kW, then as long as the constraints at the bottom, top, and right sides of this diagram do not apply, the model would announce its usage as {3 kWh, 5 kWh, -5 kWh}. This would allow for up-regulation by 8 kWh (discharging at the maximum rate rather than charging at the nominal rate) and down-regulation by 2 kWh (charging at the maximum rate).

Roles

Three roles interact in order to expose, operate, evaluate, and control controllable capacities: Customers, Brokers, and the Distribution Utility.

Customers

Customers have loads and sources that may be controllable, and they have preferences over convenience and energy prices that will affect their evaluations of tariff offerings that propose to exercise controls.

Within each customer model, each type of power capacity that might ever be subscribed to a separate tariff must be separately metered and reported. Therefore, a household customer with an interruptible water heater will have two meters and must essentially behave as two customers, even when both are subscribed to the same tariff, although those two "virtual" customers may of course share other properties, such as preferences. This means that such a customer will always produce two TariffTransactions for energy usage in each timeslot.

Brokers

Brokers are motivated to offer tariffs for controllable capacity for two reasons:

  • to avoid balancing charges, a broker may authorize the DU to exercise controls just in case doing so would be beneficial to the broker. Such controls are called balancing controls.
  • to reduce wholesale power costs, a broker may directly exercise controls for a specific timeslot. These controls are called economic controls. An economic control for timeslot n must be received by a customer before the customer model runs in timeslot n. Since the customer models run very close to the start of a timeslot, the broker should communicate economic controls before the end of timeslot n-1.

Of course, brokers must also factor in the future cost of customer inconvenience resulting from service interruptions.

###The Distribution Utility In the real world, the Distribution Utility would most likely be responsible for actually exercising capacity controls, because it controls the physical infrastructure. Balancing controls are exercised after the customer models run, which means that the DU must communicate the control message to the affected brokers as well as to the customers, which in turn will need to process them during the following timeslot. It must also issue additional tariff transactions for each affected tariff subscription, to correct for over or under-reporting in the original transactions. This is primarily done through the tariff subscription API.

##Representation and behavior To support these features, some representational and behavioral issues must be addressed.

###Power types CustomerInfo currently holds a PowerType instance, selected from a set of pre-defined static instances so that they are nearly indistinguishable from enumerations. There are interruptible PowerTypes, but no way currently to communicate to the broker anything about the extent to which an interruption would be shifted.

  1. We could enhance PowerType to carry such information, but that would break code that depends on testing equality of PowerType instances.
  2. We could restrict ourselves to strictly shiftable and strictly discretionary interruptible power types, but that would double the number of controllable power types.
  3. We could create a new type that wraps the controllable power types and adds a property for shiftable proportion.
  4. We could ask customerInfo to carry two additional pieces of information: the maximum up-regulation capacity per member (most customer models represent populations, not individual customers), in kWh/timeslot, and the maximum down-regulation capacity per member. Up-regulation would be expressed as a positive value, down-regulation as a negative number.

We adopt the last approach, by adding information to the CustomerInfo type.

###Control events A new domain type ControlEvent is defined, with subtypes EconomicControlEvent and BalancingControlEvent. These specify a tariff. In addition,

  • an EconomicControlEvent specifies a proportional adjustment to controllable consumption or production capacity in the following timeslot against the specified tariff. It is issued by a Broker, and received by the tariff market to be applied in the subsequent timeslot by the customers subscribed to that tariff. These customers would be obliged to apply the specified capacity adjustment to what they would have otherwise produced or consumed in that timeslot in the absence of the control. The allowable range of adjustment depends on the characteristics of the load or source. For a thermal storage device such as a water heater or refrigeration system, values between 0 and 1 specify up-regulation (curtailment): 0 means full curtailment for the specified timeslot, 1 means no curtailment. Values between 1 and 2 specify down-regulation: a value of 2 means full down-regulation for the specified timeslot, with the consequence that additional thermal energy is stored beyond the customer's immediate needs. For battery storage, values between 0 and -1 call for up-regulation -- discharging the battery into the grid within the constraints imposed by the model.
  • a BalancingControlEvent specifies a quantity of energy in kWh (positive for production capacity, negative for consumption capacity) to be adjusted in the current timeslot, after the model has run. This is originated by the DU, applied to tariff subscriptions, and sent to the broker. The reduction is distributed over the subscribed customers in proportion to their actual usage during the current timeslot. Additional tariff transactions are needed to account for the change. The per-customer reductions would then be communicated to customers through their subscriptions.

Customers must implement the necessary logic to pick up and process the regulation controls at the beginning of each timeslot. Because these events are all associated with tariff subscriptions, the queue of pending control events is kept on the tariff subscription rather than forcing the customer models to build and manage the queue.

###Balancing orders Before the DU can exercise balancing controls, it is necessary for brokers to specify how much capacity they are willing to contribute to balancing, and place a value on that capacity. This way, the DU can exercise it just in case it is more advantageous than alternative ways of achieving balance.

To accomplish this, Brokers can issue BalancingOrder instances, giving a tariff, a maximum exercise ratio (for example, by saying that up to 50% of the consumption or production on this tariff can be curtailed), and a price/kWh. A positive price would require the DU to pay the broker, but only to the extent that the control is exercised for the benefit of other brokers. These orders will be retained by the DU and exercised as needed as long as they are not overridden by the broker. A broker can modify or cancel a balancing order by issuing one with a different (possibly zero) exercise ratio.

###Tariff and Subscription representation A tariff for controllable capacity needs to say something about the maximum amount of interruption a customer should expect, and perhaps the maximum duration of an interruption. However, it's not clear how a population model would interpret such a specification. Better, perhaps, to simply specify the maximum percentage of curtailment that is allowed under the tariff. Customers would presumably prefer tariffs that specify a lower percentage, but presumably prices would be lower for higher percentages.

A tariff is defined by a TariffSpecification and a collection of Rate instances. In order to allow some flexibility in tariff construction, it makes sense to represent the possibility of external control in the Rate structure, so for example a tariff might say that interruptions would only happen between 15:00 and 21:00, or only after 10 kWh was used in any particular day.

Note that a tiered curtailment scheme might not produce exactly the expected results in population models, because individual customers are not directly represented. If a broker specified 100% curtailment after 1 kWh, the average usage among a set of individual customers would necessarily be lower than in a statistical model of the same population, unless the statistical model somehow does the extra math to determine the aggregate usage for the situation in which no individual can exceed 1 kwh.

Design: In addition to the two new event types, Rate will have two additional fields maxUpRegulation that specifies the maximum percentage curtailment in a given timeslot, and maxDownRegulation. This assumes external control can happen without notice. Also, a new version of TariffSubscription.usePower() will take two additional arguments: the minimum and maximum energy that could have been used or produced. These numbers are positive for energy flowing toward the customer, so if an EV model wants to use 3 kW, but could take as much as 5 kWh or could deliver 5 kWh, the values would be (3, -5, 5).

Server processing details

Below are sequence diagrams for the two types of capacity controls. If the broker wishes to exercise economic control, it issues an EconomicControlEvent, specifying the tariff, the timeslot, and the proportion of control it wishes to exercise. This proportion is constrained by the maximum regulation in the tariff specification, or more precisely in the Rate that applies during the specified timeslot. The control is communicated to the subscriptions for that tariff during Phase 1, and applied to the usage by modifying the amounts computed by usePower(). The actual adjustment quantity is then saved until the next timeslot. The customer must retrieve the adjustment amount from its subscription when it is activated during the server's subsequent Phase 2 stage, and do whatever it needs to do internally to respond to the adjustment. Note that the Customer must retrieve the adjustment quantity before calling usePower(), because it will be cleared in the call to getRegulation().

figures/economic-control-seq.png

If a broker wishes to offer some of its contracted controllable capacity to the DU for balancing purposes, it issues a BalancingOrder, specifying a tariff, a maximum proportion of adjustable load or supply that can be managed under the terms of the offer (so a value of 1.0 for a consumption tariff tells the DU that it can curtail all that remains curtailable), and a price/kwh for exercising the control. A positive price represents a credit to the broker. See Market-based-balancing-story for details on how this is supposed to work.

During Phase 3 processing, the BalancingMarket computes the total imbalance, then determines the price for that imbalance by clearing the appropriate set of orders (down-regulation to clear a surplus, up-regulation to clear a deficit) consisting of the submitted balancing orders and the current prices on the wholesale regulating market. For any balancing orders that are cleared, the "trade" (in the case of up-regulation) consists of calling capacityControl.getRegulationCapacity() and multiplying by the ratio in the BalancingOrder to determine how much adjustment is possible, calling capacityControl.exerciseBalancingControl() to actually make the adjustment, and then issuing a BalancingTransaction through accounting. The capacity control service will look up the tariff and allocate the regulation across its subscriptions in proportion to their respective maxRegulationCapacity values. The subscriptions will in turn generate the proper TariffTransaction instances to represent the change in usage (to compensate for the TariffTransaction instances already created by the customer in Phase 2). These transactions may have the opposite "sense" from the ones originally issued; for example, if the customer originally consumed some power and issued a CONSUMPTION transaction, and up-regulation is exercised, then the compensating transaction will be a PRODUCTION transaction. Finally, a BalancingControlEvent is issued to the Broker and the tariff posts balancing control notifications on its subscriptions to notify customers of the action.

figures/balancing-control-seq.png

Because the customer always sees adjustments in the timeslot following their occurrence, it does not need to distinguish between balancing and economic controls. Instead, all it sees is a quantity in kWh that was adjusted in the previous timeslot.