As mentioned in last weeks post (https://www.lovebuildingenergy.com/post/essentials-considerations-of-a-grid-interactive-efficient-building-geb) there are a number of items to consider for a #GEB. This week I’m going to delve into control hierarchy.
In most C&I buildings today the level of control mostly takes place at the individual device level i.e. lights controlled via switches, HVAC controlled via thermostats etc. Some buildings have taken gone a step further and integrated these indivudal device level controllers via Building Management System (#BMS) or Energy Management Systems (EMS). These software tools take in a swathe of inputs such as building sensors, meters, outside weather conditions, forecast, building occupancy etc., and compute all the inputs along with setpoints, boundary conditions, optimization functions etc. to determine and control the devices in some harmonious way. This creates some level of centralized control, however BMS aren’t all that common and typically aren't standardized.
Now let’s take it up a level higher. Per the GEB definition from last weeks post, a GEB should be able to provide grid services and in order to do that there likely needs to be some level of control interaction between the grid and the GEB. Of course this isn’t necessarily a new thing, as we have had utility #demandresponse programs around for years. Whereby the utility provides a notification for example via email and the building an aggregated group of buildings respond to the request by reducing load. This approach works great for generalized and non-localized system peak load reductions, but according to #DOE the GEB should be able to provide other grid services too such as for contingencies and frequency regulation etc., by shaping, shaving, shifting and shimmying the building net load. To achieve this, its likely an email won’t suffice, as such what level of control is required and where does it reside?
To answer this question we need to consider a few factors such as latency requirements, device capabilities, bulk grid and/or local grid services, risk of non-performance etc. With regards to grid services such frequency regulation that requires a fast response, it’s likely a device that’s capable of shimmying fast such as an EV charger, will need to see a direct signal from the bulk grid operator, by-passing any intermediate management software such as BMS and local utility system. Whereas for targeted local load relief under normal conditions where more advanced notice can be provided, it’s likely the utility would send the control signal directly to the GEB BMS or via an aggregator where the BMS can then disaggregate the command to the right devices available at the time that have minimal impact on operations. In this example their are 3-4 tiers (4 with aggregator) of control with disaggregations occurring as you move down to the device level. Now with #FERC #Order2222, this gets a little more complicated where coordination of control is required between bulk and local grid needs and constraints but more to come on this subject in a future post.
Lastly, as mentioned earlier many buildings don’t have BMS and nor are they standardized. Fortunately, recent developments such as #VOLTTRON (not the transformer) has developed an open source solution to help fill this gap.
David Lovelady
Founder of LovEnergy
Comments