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.

BSI Part 1: 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 first of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

In my smart grid work, I began describing each end node as a microgrid. A microgrid is a self-contained entity responsible for managing its own energy use, generation, storage, conversion, and as a last resort, market operations. This model eliminates direct grid control of buildings. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

The ESI is the external face of the participants in smart energy. The ESI facilitates the communications among the entities that produce and distribute electricity and the entities that manage the consumption of electricity. An ESI may be in front of one system or several, one building or several, or even in front of a microgrid. In keeping with service integration principles, there is no direct interaction across the ESI.

Today, an ESI is most often on the outside of a building system. The leaders in commercial energy management, companies like Target, put the business between the ESI and the building systems. Target evaluates energy use, and changes in energy use as normal business decisions, and building systems respond to business operations. Target though, is unusually aware of its decision processes, has many nearly identical buildings, and has strict commissioning standards. For the rest of us to be like Target, we need a Building Systems Interface (BSI).

The BSI must expose several services. New systems will certainly incorporate the market-oriented interfaces of smart energy, for use inside the building microgrid. Other services will interact with the business, linking corporate calendars to building operations. Another will request and consume weather information; if nothing else, a data center should take advantage of a cold winter such as this to limit cooling loads.

Systems must tie their information to the space that the enterprise inhabits. It is not enough for points to self-describe themselves as an air handler—that air handler must describe itself in terms of the service it provides to a particular space. Space is what the building systems support, space is what the tenants recognize.

There is an enterprise service that links between the occupants and their activities and the BAS and its performance. It communicates to support business activities while using the common schedule communications developed for smart grids. It is aware of the market conditions and deals made with the grid though the ESI. It knows whether the volatile energy of the renewables-based grid is scarce or abundant. It can report back to the enterprise how and where energy is being used right now.

Even live-load, or plug-load, must be able to describe itself in relation to space. Panel sub-metering and BIM-based circuit tracing (PLie – panel layout information exchange) put even the coffee pot and copier as part of the BIM model for energy use. Even home appliances must be participants.

Understanding Inheritance in WS-Calendar

Traditional service communications have assumed near real time response. Traditional schedule ahead markets have been similar to the informally communicated “allow two weeks for shipping”. Smart energy markets demand we do better, scheduling delivery of services, now and in the future, within 15 minute windows or even within 4 second intervals. Prices, and delivery and consumption will all swing every hour of every day. Real opportunities will arise for those who can help the consumer in the home or commercial property buy low, sell high, and buffer their internal needs in between.

This requires clear communication of time and schedule, whether we are talking price, or product, or service. WS-Calendar is a new specification that will be at the center of new market communications. WS-Calendar extends enterprise standards used for personal and business schedules to service communications and markets. WS-Calendar defines the Interval, and relationships between Intervals to create the Sequence. The power of WS-Calendar comes from remotely referencing Sequences and in influencing Sequences that are incomplete to define actionable services.

Sequences are composed of intervals for which a set of temporal relations have been defined. ICalendar has long defined relationships between calendar components, intervals are just another calendar component. In WS-Calendar, we reference a sequence by defining a “parent” relationship with any single interval in the sequence. We refer to the interval within a sequence that has this relationship as the Designated Interval.

Wherever there is “missing” information in the Designated Interval, it can be inherited is inherited from the referring component; we use the “parent” relationship to reference the designated interval. These references may be local or remote. Some, but not all, of the information can be inherited by the other intervals in the sequence. Adding additional references can further specify information in the sequence through inheritance; these additional references created by specifying an additional component that has a parent relation to the previous referring component. In this way, we can create a grand-parent and a great grand-parent.

Each parent bequeaths information to its child. A child inherits this information in accord with the inheritance rules. If the child is itself a parent, it bequeaths its information, the bound result of its internal information and its inheritance, to its child. Information to complete the specification of a sequence flows in this way from parent to child, from the outer reference to the inner sequence.

Inheritance by the designated interval is governed by slightly different inheritance rules than the other intervals in the sequence. In particular, only the designated interval can inherit the start date and time from its parent. The starting date and times if other intervals in a sequence are computed using the temporal relationships within the sequence. Other information can be inherited by all intervals in a sequence. Other specifications that incorporate WS-Calendar must define how inheritnace will work with their payloads.

The referring components are called Gluons. In physics, gluons are particles that affect the exchanges of force between quarks, but are not themselves quarks. By analogy, WS-Calendar Gluons affect the referencing and binding of intervals in a sequence, but are not themselves intervals or part of sequences. Because intervals can inherit almost any property from a Gluon, Gluons must contain most of the same information elements as Intervals. Because Intervals can contain information payloads for specifications that use WS-Calendar, and these payloads can inherit information from gluons in the same way intervals do, Gluons must be able to contain information payloads from those specifications as well.

Gluons are essentially pretty simple. They can be incorporated as part of a larger communication, whether e-commerce or building controls (oBIX). This gluon can invoke a sequence, or modify it, or both with a single call.

BSI and a blast from the past

Every now and then I run across an old email that I have long forgotten, but speaks to my current activities. I think that this comment, written long ago in the oBIX forum speaks to something I need to return to. Jon recently gave me and WS-Calendar and EMIX some excellent advice on on creating standards for re-use and extension.

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
Sent: Wednesday, January 05, 2005 6:36 AM
To: 'jon.bosak@sun.com'
Cc: 'Grobler, Francois ERDC-CERL-IL'
Subject: RE: oBIX Guiding Principles

There are parts of Control Systems that are very business oriented. If an embedded control system detects that it needs maintenance, and can submit a maintenance request to an identified partner, clearly that work order looks like a normal business transaction.

Meeting and occupancy schedules might look like UBL (room will be occupied tomorrow from 2-4; use oBIX to inform HVAC, Access Control, Intrusion Detection, A/V management control systems. Read the Electric Meter before and after the meeting). Does the UBL standard extend the ICAL standard, or subsume it or...? Clearly, there is a benefit for scheduling functions to re-use commonly implemented scheduling requests.

These functions are in the future. What oBIX has to start with doing is exposing the event driven world of controls to the enterprise. For the most part, this starts with state. What are all the room temperatures on the 3rd and 4th floors? For how many hours did the compressors run today?Which areas of the building are currently secured? Some of this information is creeping into QOS agreements in real estate, and so intersects with the work of OSCRE (Open Systems for Commercial Real Estate). To my knowledge, UBL does not really include the nomenclatures for this because this is outside of the normal business functions. Am I wrong? Can you refer me to any relevant portions of UBL?

I think an early use for oBIX will be to provide a platform on which GRIDWISE (www.gridwise.org) type applications are built. That may be the first place where standard UBL functions hit, as price incentives are offered to buildings on the spot market to forefend brown-outs and the like. That feels more like bid/delivery/request rebate.

The construction industry has long had a separate open standard for construction documents, known as the IFC (Industry Foundation Classes) developed by the International Association for Interoperability (http://www.iai-international.org/iai_international/) and already required in many international construction projects. The IFC space includes construction documents, spatial data, spatial modeling, etc. The EU, in particular, leans heavily on this ISO specification, particularly in the Nordic countries. The largest landlord in the world, the GSA, has mandated that all transmittals for the design, construction, and acceptance of buildings. The closely related GBXML (Green Building XML) is a lightweight variant of IFCXML focused more on performance issues. GB Modeling, using GBXML for transferring building performance data, is required for those projects that wish to be designated as compliant with programs using words such as "sustainable" and "LEEDS". We have long considered that IFCML and the closely related GBXML were our most important shared spaces. Is there a defined interface/mapping between IFCXML and UBL?

Thanks for your comments

tc

-----Original Message-----
From: jon.bosak@sun.com
Sent: Tuesday, January 04, 2005 9:20 PM
To: Considine, Toby (Facilities Technology Office)
Subject: Re: oBIX Guiding Principles

| G) If, as seem likely, this document is adopted as an OASIS standard,
| I recommend that we steal freely from this document, reusing as much
| as we can in our rules for developing subsidiary oBIX services as well
| as in the core document. It is well written and defends its decison
| in a language that is focused and apropriate for the enterprise
| developer.

Since UBL is probably going to become the dominant standard for international trade documents, why don't you just adopt the UBL schemas and have done with it? After all, UBL is based on a pretty widely adopted specification (xCBL 3.0) that was developed specifically for electronic marketplaces. If there are any data elements missing from UBL 1.0 that are needed for oBIX, we can probably include them in UBL 1.1.

Jon