Ready for the BSI

I want to get back to buildings soon. Smart grids are engaging, but I think our goals for the future will be met by buildings.

For months, all my writing has been about smart grids. More particularly, for November, it has all been about smart grid standards.

As I write this, the essential market interfaces of the grid are in review. A common communication of schedule and interval, suitable for sharing schedules between grid and enterprise and building and finance finished public review last Tuesday. We have nearly 80 comments to settle, but soon we will be ready to discuss using ws-calendar not only in smart grids, but in buildings.

Energy Market Information (EMIX), the critical description of energy product and price has two more weeks for public review. Energy prices always have a schedule, and EMIX uses WS-Calendar. EMIX supports demand response, but more importantly, full participation of buildings in all energy markets. EMIX is in review until the 17^th.

Energy Interop was released for public review last Saturday. EI (as we call it) defines the essential e-commerce framework for interactions between grids and aggregators and utilities and, yes, buildings. EI is locked for review until December 27.

Now, I am reeling from a week at Grid-Interop, at which I have spoken 5 times, sat In two meetings of the Smart Grid Architectural Committee, and practiced politics (difficult for me) in numerous other meetings. In October and November I put three of the four market interfaces of the smart grid out for public review. Light, loose, market oriented, interfaces that transfer incentives for participation to the buildings. Now I am longing to talk of buildings again.

Today, at Grid-Interop, the focus shifted to buildings as microgrids, each responsible for managing energy use, generation conversion, storage, and, only as a last resort, market operations to make up the difference. This is what I wanted to accomplish when I got started on Smart Energy. No grid control, which would strangle in-building innovation. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

Now I turn back to the building, Now I want to think of the Building Systems Interface (BSI), the abstract interface to building systems. Some of it is building services as in BAS, abstracted with system metadata, and associated with the space it supports, the space that the tenants recognize. Some of it is simple appliances, and the way the communicate in homes. Some of it is the live or plug load, perhaps discover able, perhaps mappable to space using PLie.

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 must be based upon the 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 3^rd party verification of the performance of the performance contractors… BIFER (BI for emergency responders) may even come from that mix.

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.

This needs some standards to fly, to be cheap enough to let these cloud-based services flourish. PLie needs to be advanced to a standard. oBIX trends for energy management must be accessible form self-metering systems and from switch panels, and be able to support the NAESB Energy Usage Information standards. There must be a light-weight BIM, my vote is for GBXML, able to act as the spatial lens through which to view energy use.

I want to define the BSI…

But now, rest, and sleep.

Coming to Terms with EMIX

Another of the essential inter-domain standards for smart energy is being released for formal public review this week. Schedule, price & product descriptions, market interactions, and usage reporting are the standards to enable arms-length interactions between participants in smart energy. When these are stable, products that need them can come out of the labs, accelerated by common communication standards across the country. The miracle of software, silicon, and scale can begin to work its magic to balance energy supply and demand, in a world where both are more volatile than today.

EMIX, or Energy Market Information Exchange, supports market communications concerning energy. At first glance, this would appear to be a simple commodity market, with a simple product, power. Energy, however, is the most volatile commodity. Pork-bellies and wheat can be stored. Fresh produce must be used in season. Energy must be used when available, its shelf life is moments, and its cycle of seasons is completed every day. This need to coordinate precise delivery and availability times makes traditional market communications inadequate.

Energy surpluses and shortages are known in advance, at least as much as they are for other commodities. The periods are much tighter. Commodity markets price produce based upon weather during the long growing season. Secondary weather markets let investors hedge against rain during, say, soybean harvest week in Indiana. Alternative energy markets will compress the same business processes into a single day. Timing is everything in energy.

Energy use does not exist in a vacuum; it intersects with the businesses and lives that inhabit buildings and venues, and those are managed by on-line calendars. Business meetings, weddings, soccer games, and concerts are all schedules using iCalendar-based communications. WS-Calendar extends iCalendar interactions to support the needs service oriented inter-process communications.

EMIX calls the application or product definitions to schedules “Terms”. EMIX uses WS-Calendar to express schedule based information as part of product definitions. The complexity of operations schedules, and weather predictions, and market availability are reduced to schedules and prices. Whether a market is closely regulated with invariant tariffs or whether a market is dynamic and vital, the software and equipment in those markets will receive the same messages, the EMIX Terms.

Terms may be incomplete during indications of interest and tenders, may be firmed up by purchases or executing options, and may be only completed during specific calls for performance. EMIX does not pre-judge how Terms are completed, nor create market rules for their elaboration. EMIX does not dictate market rules. EMIX terms express the results of market operations and market rules, and the schedules of energy supply and demand, and the schedules that they create.

In all markets, there is more variety of appetites and needs then there are of contracts. In Real Estate, initial indications of interest may specify neighborhoods, or the number of bathrooms, or even cities with specific demographics. Over time, the deal becomes focused, the specifics become concrete, and the actual closing, even in a creative transaction, is expressed in a mundane manner.

In an analogous way, EMIX can express resource capabilities for buyers with specific needs, or for sellers seeking to find a market. The Terms of offers can be made as expressions of capabilities and requirements, applied to the schedule of how those vary over time. Other offer terms may be as specific as the final performance call.

EMIX supports more than Power markets. By describing ancillary services, it can help distributed resources find more markets in which to sell. It describes transport charges, which might enable consumers to select their energy supplier. EMIX provides the means for warrants of energy source and environmental cost to travel with the transaction. That, however, is a longer story.

Doing things at the right time

I have been writing too much elsewhere to write as much as I’d like here recently. WS-Calendar, EMIX, and EnergyInterop all have drafts out for comments this week. Standards specifications require a lot of coordination to get into publication.

Last Sunday, the WS-Calendar Technical Committee released a draft for comments. This is a small component among standards, but one that can help integrate building systems into the businesses that inhabit them. Already there are early attempts to integrate this specification into energy, into the enterprise, as well as into building operations.

I couldn’t make it through a week without using the IETF standards iCalendar and its supporting communications tools iMIP, iTIP, and calDAV. I am thankful for the many hours they save me every week. I think you may feel the same way, too.

What, you say? You don’t think about these standards? Well, that’s because they are ubiquitous, they work, and are therefore invisible. You use them to schedule meetings, and webinars, to remember plane travel and hotels reservations. They are everywhere, they work, and so we don’t talk about them.

WS-Calendar builds upon these specifications to bring schedules and synchronization to web services and inter-process communications. We created WS-Calendar to create, share, invoke, adjust, and track coordinated response between domains and organizations. By domains, I mean different groups that speak different languages. WS-Calendar will see use in financial instruments and building systems, in energy markets and in enterprise systems, in PDAs and electric cars.

Of most interest to automated buildings readers is how it affects building systems, and what new opportunities it opens up there. Years ago, when became chair of the oBIX TC (Technical Committee), I observed that the BAS needed to know the schedule of the conference room. My corporate calendar already knows when meetings begin each day, when they end each day, and how many people are in each meeting.

There is already a rough draft to incorporate WS-Calendar into oBIX, the OASIS web services standard for communicating with building systems. I have discussed use of WS-Calendar with many members of the BACnet community. It is likely that both communities will soon be able to use this specification to communicate with their respective building systems.

We can expect that enterprise systems will soon support this information sharing. Apple, Microsoft, and Oracle all participated in the WS-Calendar process. I have heard of a trial use of WS-Calendar directly from a Microsoft Exchange server. The makers of registrar’s office software, used to schedule college classes, are looking to communicate class schedules, and the number of students in each class, directly with the building systems.

Smart grids and demand response are everywhere in the news today. Smart grids communicate energy shortages and surpluses to the end nodes of the grid: buildings, homes, and industries. New standards for energy market communications include WS-Calendar. Through WS-Calendar, Energy, Enterprise, and Buildings communicate in a common language to discuss when and how to perform.

WS-Calendar is based on a suite of documents, all currently seeking comments. xCal defines a standard way to render iCalendar information in XML. CalWS is a web service standardizing the API for Calendaring & Scheduling functions on any platform supporting calendaring. WS-Calendar is the component for inter-domain communications.

Comments on WS-Calendar can be posted using the comments link at http://www.oasis-open.org/committees/ws-calendar/

Its almost here – and time to start planning how to use it.

Standards for energy engagement and autonomous response (3b of 3)

The fourth of three planned posts on revisiting the smart grid priority action plans ran over long. The first post discussed semantic issues. The next addressed the conflict between the business models for Managed and Collaborative Energy. In this one, I discuss the architecturally significant interfaces of the smart grid, updating my earlier musing on SGIX. The third (3A) discussed the 4 key standards for coordinating energy use and supply. This one discusses standards for feedback and planning on the customer side.

SG Energy Usage

Energy use has traditionally been summed over a month and then received by the client weeks later, far too late to affect behavior. Recent high profile efforts by Google Energy and Microsoft Hohm have demonstrated the power of granting consumers access to near real time dynamic data about energy usage. Makers of building automation systems (BAS), particularly makers of heating and cooling systems, have long wanted direct access to current meter information. Two quite different standards efforts from two quite different trade associations are taking one standards for sharing energy usage information.

OpenADE

The UCA International user’s group (UCAIug) is developing OpenADE (Automated Data Exchange) to more readily share information through existing utility infrastructure. It begins with sharing day old interval data with customers and third parties, and will then strive to become more current. OpenADE leverages the standards of Managed Energy (described in my previous post). Although the long term plan is cloudy, surely the utilities are well poised to include demand response (DR) and other grid and market events with usage information.

EISA

The Energy Information Standards Alliance (EISA) is a new consortium considering energy usage from the perspective of the end node. EISA foresees much more frequent and timely information not only from the meter, but also from each intelligent system and appliance throughout the building. Each system will provide a type of energy metadata on systems that consume power. Think of the Google Energy demonstrations, think again of certain contributors to the energy profile able to report and to identify their own use.

One part of the EISA vision that appeals to me is the idea that autonomous building systems would compare energy profiles and smooth the overall load profiles; no two systems would produce energy spikes at the same time. Autonomous load shaping is important not only for the short term grid, but is also an important enabler of site-based energy, and even net zero strategies. Some members of EISA see it as a suite of standard oBIX contracts.

Standards Ancillary to Energy but useful to Smart Grids

Many of the benefits of smart grids come from improved situation awareness. The standards used within the grid itself, which I do not concern myself with, are largely to improve awareness of grid operations. Where I do concern myself, with the end nodes of the grid, those situations and that awareness reach beyond the grid itself.

UnitsML and SensorML

There are many things to be measured and sensed in industrial facilities and commercial buildings. Sensors may be part of systems or isolated. (I have some use cases that demand incorporating ancillary sensors into central energy management.) It would be good to use standards that describe the measurements unambiguously in ways that can be shared by multiple systems.

UnitsML offers an unambiguous way to describe all physical measurements, and an unambiguous ability for a computer to look up the translation of any units of measure to any other units. UnitsML is an existing OASIS technical committee with NIST backing which will need wider participation to complete.

SensorML is a standard from the Open Geospatial Consortium that can describe the geometric, dynamic, and observational characteristics of sensors and sensor systems. There are many different sensor types, from simple visual thermometers to complex electron microscopes and earth observing satellites. SensorML can describe them all.

Digital Weather Markup Language (DWML)

Knowledge of the future is important to all markets; knowledge of future weather is important to energy markets. All weather is local. Local weather awareness includes not only weather predictions, but also knowledge about the actual weather at my location following previous predictions.

DWML is an existing specification developed by the National Oceanic and Atmospheric Administration (NOAA). NOAA offers access to their National Digital Forecast Database (NDFD) using DWML. DWML is a little quirky, and a little hard to use. Smart energy would benefit from its further development. We need to define a DWML profile for reporting as well as forecasting, to enable the exchange of actual conditions as well as forecasts. Such a profile would be used when querying local weather stations and even personal weather systems.

WS-DD and WS-DP

Device discovery and device profiles have been used in computer networking for some time. These specifications for the web services implementation are going to a standards vote in May. A major manufacturer of electrical equipment has already announced that they will include WS-DD and WS DP for all the equipment it sells. There are open source implementations for small devices (https://forge.soa4d.org/). I think they will have a big role in the future world of distributed generation and Net Zero Energy facilities.

SG CyberSecurity

Cyber security is drawing more attention and concern every day. Today’s grid cybersecurity is concerned primarily with defending the isolated system with relatively static interactions. Tomorrow’s cybersecurity will apply to systems interacting with others owned by many different people, of uncertain skill and diligence in securing their own systems. Security issues need to be integrated within every smart grid standard from the beginning. We need a separate security toolkit/framework, perhaps a profile from current fine-grained security standards, key management, and related areas. Broader integration of physical security, fine-grained networking and commercial security, and situation awareness technologies need to be part of the mix.