Yesterday, I presented the NIST B2G (Building to Grid) group with a proposal to simplify integration within buildings and between buildings and the grid by relaying on existing well-defined, and well known web services standards. The feedback was surprisingly positive. Now I have to consider how to get it into the Energy Interoperation specification.
Energy Interoperation was conceived of as the market and situation awareness gateway for the premises. As energy markets change more during each day, the home, the commercial building, and the industrial site (the premises) must become aware of these changes, and the premises-based systems must be able to respond. A significant early profile of Energy Interoperation will be OpenADR 2.0 (Automated Demand Response). OpenADR 2.0 will serve as a gateway to more rational energy markets, better able to accept intermittent energy sources (wind, solar) and distributed energy resources (on premises, storage, etc.). We call the external interface of premises-based systems the Energy Services Interface (ESI).
OpenADR 1.0 terms each premise a resource, able to provide services to the grid. These resources are tied to the “nega-watt” concept, wherein finding a MW of reduced energy use is as good as finding a MW of increased generation. The bulk of Energy Interoperation is defining the market transactions needed to support a variety of market structures and tariffs.
If we had mature markets, each premise would be responsible for absolute energy use. Many industrial sites operate in this mode already. Absolute results, though, are considered beyond the abilities of today’s commercial buildings, and more importantly for today’s homes. If the family arrives home during a DR event and starts cooking, their energy use will go up even as though their thermostat was automatically turned down. To assess performance in today’s markets, market makers want to see some of what’s behind the ESI.
To support this need, Energy Interoperation needs to support some level of not-quite-direct control of systems or devices inside a Resource, or perhaps merely some level of monitoring. We call these exposed systems and devices Assets. It is important to think of an Asset as a virtual device, one them may represent a smart toaster, a water heater, or an entire production line in a factory. What matters is that a contract allows it to be exposed and its function “directly” monitored.
Distributed Energy Resources (DER) are a particularly interesting class of Assets. A home solar panel, or a roof-top wind turbine, or a grid integrated thermal storage system might all be Assets. In any case, Assets need only a constrained set of interactions (On, off, half speed, set thermostat to 76, is it running now, charge up, discharge, how much electricity is it generating now…). Limited metadata is expected as well, largely to let Transmission operators deal with covarying Assets. 500 solar panels on the south side of town are covarying Assets as the same clouds might take them all out at the same time. Today’s Assets are covered by Tariffs, and this is all closely regulated. In the future, Assets may be offered to the market as tenders, contracted, and exposed.
Yesterday’s proposal was that we use the Managed Discovery Interface defined by the Web Services Discovery and Web Services Devices Profile (WS-DD). WS-DD is already used in many networks to discover services such as printers and faxes. WS-DD is supplemented by Device Profiles (DPWS) to ascertain the capabilities of each device. For example, you may want to find only printers that support color and two-sided printing. Discovery only works local, as the internet is built to prevent printer searches consuming all bandwidth. The Managed Discovery interface offers a secure way to ask a remote system to share the results of local discovery. You can imagine that corporate headquarters allows remote employees to print at only a few designated printers. We can use the same approach to share Assets with grid operators.
To do this, we need to define Standard metadata compliant with the Device Profile, including a list of available services and their WSDL description. This standard metadata would be extended to define profiles of interest to energy interactions, while excluding detailed interactions that would increase complexity while reducing interoperation. We discussed whether devices would expose separate services beyond those needed for energy interactions.
Fortunately, ASHRAE SPC 201 has been hard at work for months, working with NEMA to define what the energy interactions for premises based systems are. For some systems, these are quite simple. A thermostat might expose a method to turn it up for a period of time, and a method to verify its current setting. For now, these services could be registered by hand though the system that hold the ESI. In the future, such systems may be able to autodiscover systems, and ask the [owner] which ones to share with the energy market.
Assets need some concept of Events, that is, a way of notifying remote systems of things that change locally. WS-DD prescribes the use of WS-Eventing. This specification defines how to support supports the simplest levels of interfaces for notification producers and consumers for a distributed event management system. WS-Eventing is a W3C recommendation that is widely implemented in the enterprise.
We can use these specifications to solve critical needs for Energy Interoperation without delaying its final completion. This approach will also support re-deployment of these services and events to support applications that today we do not imagine.