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.

Converging with the Internet of Things

Service integration is coming to the world of Calendars. Calendars are coming to the Internet of Things. These two trends have the potential to open up whole new classes of easy integration in buildings and in personal devices. This integration got its initial acceleration from the needs of smart energy. The long term reach, though, is much farther.

Traditional e-calendars are store, copy, and forward messages. There are five copies of a meeting for five people. Changing a meeting time requires finding and updating those five messages. This is easy if the messages are on a small office LAN on one server. It poses some daunting problems if those messages are spread over two corporate servers, Gmail, a stand-alone PC, and a cell phones. If 50 are attending that meeting, things can get complex. If it is a community schedule, with 5,000 subscribers, it is almost impossible to support the diversity of clients.

Jon Udell (http://blog.jonudell.net/) has long advocated distributed calendars for communities, encouraging people and organizations to be the authoritative sources for their schedules instead of sending a flurry of messages that may soon be out of date. (If you are interested, read all you can on the ElmCity Project.) Jon’s blog introduced me to Mark Surman and the phrase “cities that think like the web” (http://commonspace.wordpress.com/). When we apply these approaches to Smart Energy, we may get “grids that think like the web.”

The way that WS-Calendar has developed since Thanksgiving makes this all easier. Standard REST and SOAP services for calendar communications reduce the barriers to distributed community calendaring. Mike Douglas is testing his SOAP concepts to synchronize dissimilar calendar servers (Exchange and BedeWorks). Community Calendars are about to get much easier to implement.

WS-Calendar, though, was created to support smart energy. Schedules and events for energy shortage and surplus, communicated along with volatile prices.

There is a long history of simple calendar communications for small devices. Older cell phones interacted with iCalendar communications despite extreme resource constraints. Open source and silicon already exists for simple calendar processing. When these services get reduced chips that we can afford to put everywhere some interesting things happen.

Consider a Calendar Service on your smart thermostat. Add a community calendar server to your house. Maybe it’s on the magnetized thin film computer stuck to the front of the refrigerator. Maybe it’s on your wireless router. The home community calendar shares schedule services with the Dad’s Android, with Mom’s Blackberry, and with the Kids iPhones. Maybe, following the Elm City model, the house calendar subscribes to the high school community server, and that of the church as well. The electric car will need this kind of information, and can create charging schedules that are themselves shared. Messages about schedule electricity shortage and abundance come through the Energy Services Interface (ESI).

Then we would have a smart thermostat that thinks like the web, in a house that thinks like the web.

BSI Part 3: The Metadata Problem

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the third of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

Metadata refers to information about data. While control systems for buildings can offer up an impressive amount of data, it takes far too much effort to figure out what it means. In a medium-sized commercial building, tens of thousands of points can take a month to unravel before useful integration with the businesses and lives of the people who occupy those buildings is possible. Throughout all the integrator must understand the technologies in use in that building. At the end, the integrator produces proprietary results himself.

Most of that integration effort is in deciphering what those information points mean. Is that point an internal point, useful only to the HVAC professional, or does it represent a room temperature, or oxygen level, of interest to the building occupants. Do these points describe one air handler or ten? Are all air handlers fed by the same compressor? What space, which means what business services, does each system support? The answers to these questions can be discerned by the trained professional, with the blueprints in one hand, and years of experience in the other. Today, they cannot be reliably determined by machine inspection.

We need a relatively few profiles to pull this off. Or maybe we just need some rules about profiles, and a place to create a repository. Too many profiles could just recreate the chaos we have now, in which metadata is all free-form tags.

There are several existing profiles for communicating with energy meters; we need to get to one. The profile model should be able to indicate what systems are behind it, by reference, to the discoverable catalogue of building systems and spaces. Whether you call it live load, or plug load, circuits and the space they support can be described in PLIie. Everything, of course, should be tied down to the space or spaces it supports.

BIM standards contain standard descriptions for how a space is used. The links to space, offer potential keys into business directories and business schedules.

The place to start collecting this metadata is during commissioning. COBie (Common Operations Building information exchange) defines a family of information models that can be handed over from a construction Building Information Model (BIM). These include a catalogue of building systems and the spaces they support. As retro-commissioning starts to follow commissioning standards, we would begin to get the benefits of the BSI-enabling metadata in existing buildings.

BSI Part 2: What is the Building System Interface?

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the second of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

To be enterprise ready, the BSI must include discovery. Building systems, virtual meters for plug-load, and appliances should be discoverable using WS-Device Discovery. Common system metadata, the same that describes a collection of points as an air handler, must be package-able into WS-Device Profiles. Each device must expose both a system profile and an energy use profile (based on EMIX).

Because system metadata and profiles create business objects, this work creates the rational basis for policy-based security as applied to building systems. It is meaningless to ask if a system is secure unless you define what security means to you. Are you looking for a locked door, or are you looking for business enablement? (/articles/bouncer-or-prison-guard.html). System profiles bring building systems into normal security.

So what are the essential building services? There is energy management, accessible for low integration re-hosting in the clouds. There is performance contracting, also in the clouds. There is energy auditing, which only exists as a business based on near-zero integration costs (because the metadata is already in the BSI). Energy auditing? Well what if we call it a live LEED rating, or perhaps 3rd party verification of the performance of the performance contractors… BIFER (BI for emergency responders) may even come from that mix.

And, of course, there are the enterprise and consumer interactions, based on WS-Calendar. As energy grows more expensive, and its supply less predictable, doing the right things only at the right times becomes more important. The corporate calendar, the smart cell phone, and the school schedule will talk directly to buildings through standards-based service interactions.

Modern service interactions are based on composable interfaces and open specifications. Composable interfaces tend to be small, and to solve a single purpose. They free the developer and the system integrator to create novel interactions, and new value, quickly. We can see what some of them are already.

Some of them start with commissioning. COBie (Common Operations Building information exchange) defines a family of information models that can be handed over from a construction Building Information Model (BIM). These include a catalogue of building systems and the spaces they support. A newly proposed aspect of COBie is Panel Layout information exchange (PLie) which ties electrical circuits to the spaces they support. If we can solve the metadata problem, we open the door to a large competitive market place for software that engages customers in smart energy while improving the service delivered by smart buildings.