Making Smart Energy Less Exceptional

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.

A Microgrid of One

The target of smart grid communications, particularly in collaborative energy space, should always be the microgrid. Some microgrids may contain a single home, or commercial building, or and industrial site—those are irrelevant details. Microgrids have a number of systems inside them that must work within the economic environment of that microgrid—and I am thinking of old economics, before the distinction of economics and ecosystem arose. Some microgrids may have a single entity inside, say a legacy BAS (Building Automation System), but the unitary microgrid is merely an artifact of the way we have always done it. The energy services interface is the gateway to a microgrid.

Microgrids contain collections of systems that may not share common technology. Some of these systems are small, self contained, and serve special purposes, such as appliances. Some are large and complex and span significant space, such as HVAC or an industrial line. Some look alike, are built from the same components, but have different missions; the laboratory fume hood and the air conditioning system are run for different purposes and have different constraints. Some may rely on different energy markets to do the same work; heat may come from electricity, gas, or solar thermal in the same building. Some systems may store generate energy used by other systems. All of these coexist in the ecosystem of the microgrid.

Diversity is the source of resilience in the economy and ecosystem. Monocultures fail badly in either. The diversity of systems in a microgrid is a source of stability. This is as true of the microgrid spans a campus or spans a high-rise. One source of diversity is diversity of response, which is tied to diversity of business service provided. A unitary system all too often has too few response options. Without expensive and non-standard integration, these simple systems are unable to expose nuanced and diverse services for manipulation by the humans, and human processes, they serve.

Diversity within kind (read Darwin for a definition) in building systems can come from multiple technologies (hard to maintain), or from multiple systems programmed quite differently (expensive to integrate) or from identical systems responding to different users. Diverse systems can be much more agile, just as individuals can be more agile than a committee. I posit that a collection agile systems is better able to respond to heterogeneity of environment, including unpredictability of power supply, than is a single committee of systems.

Diversity of services can provide new assets to the commercial building owner. Green leases seek to tie technology, capital, and performance together to please the tenant. Green leases require separate metering and operations for each tenant to be credible. Green leases in a high rise might work best with a number of identical systems, one for each tenant, rather than a monolithic system that responds only to all. Diversity is an amenity that enhances tenant service and leas ability.

How do we distinguish a microgrid from a grid? The external interface should be the same. Inside, microgrids are more intimate, they are the safe neighborhood the kids can go out and play in. Alternately, they may be more dangerous, the prison society in which no inmate must reveal anything. A microgrid defines a security context and a security posture. Intimacy and sharing and collaboration are all a part of some contexts—and not of others.

To me, the most interesting question of the week is what information do the systems within a microgrid need to share as they support their divers purposes and work within their mutual constraints. I know it starts energy usage, and predictions of energy usage, because that is the common resource they share within their environment, the basis of their economy and their ecosystem. I suspect they need currency, to negotiate their access to resources within the constraints of the microgrid—although I am not sure that currency is always expressed in legal tender. Some systems may only be able to buy at certain stores, or sell to certain buyers.

I’m not sure what else they share.