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.

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.

Lessening the Integration Barrier to Smart Energy

We do not have a problem of knowing what to do to make buildings participants in smart energy. We do not have a problem that the technology is too expensive. We do have a problem that it takes too long to integrate systems. High integration costs lead to vendor lock-in. High integration costs lead to long sales cycles for replacements and upgrades. High integration costs will continue to slow the adoption of distributed energy resources. High integration costs lead to islands of automation, unable to participate in smart energy and demand response.

In design and in construction, today’s best practice is to use a BIM (Building Information Model) to deliver better buildings on-time and under budget. BIM trades higher design costs for much lower construction costs and reduced risk. We use BIM to generate energy models, essential to green certifications for buildings. Until recently, BIM hasn’t had much to do with the operations of a building, or with systems inside a building. This month, I am writing about how this is starting to change.

In traditional CAD, we have used libraries of templates supplied by product vendors for years. Suppliers of plumbing and lighting equipment have wanted it to be easy to design with their products, and they have wanted their products to look good in design renderings. Specifiers Property information exchange (SPie) is a project that encourages this approach applied to the more detailed requirements of BIM. SPie objects are cross-referenced with Omniclass and can include hookup and connection information. The National Electrical Manufacturing Association (NEMA) and is one of the associations participating. SPie brings the things we install in buildings into BIM.

Two technologies dominate the generation of building energy models. GBXML has wide support not only in energy modeling, but also in the design of HVAC and control systems. Information built on GBXML has had no path pack into BIM. EnergyPlus is purported to generate more accurate energy models, and has a well-defined model view for re-entry into BIM. ENERGie, (the ie is again for information exchange) is an effort to merge the two to provide a single model coordinating system design with building design and supporting full system detail. It is likely that ENERGie will soon be required for General Service Administration (GSA) and Department of Defense (DOD ) work. GSA and DOD are the two biggest landlords in North America, so their wants can drive the industry.

In information technology, we again and again see the technology we develop for the most advanced systems flowing down through normal business and all the way to the consumer. ISO 15926 is an information framework developed to express the relations between systems and components in the largest chemical processing plants. Today, ISO 15926 being adapted for a variety of tasks, from the esoteric mapping between ontologies to the automated mapping between form and function to operate smaller systems. ELie is a project to hand over the Equipment Layout in buildings to the owner by mapping from BIM to ISO 15926. ELie connects a static design to a runnable model.

Management of live electrical load in buildings is the largest challenge in smart energy. Plug load is almost unknowable in any automatic way. It will be some time before smart energy-communicating systems will outnumber legacy dumb-load equipment. Smart electrical panels that expose energy use per circuit have not found wide use; they follow no standards, and it is unclear what space they support. PLie standardizes the description of Panel Layout and brings it into the BIM of electrical wiring. PLie can provide automate the mapping of building wiring into the spaces and equipment it supports.

The EIS Alliance is developing models to support autonomous load management and shaping in buildings. One of their concepts is that the buildings electrical meter should be an information appliance for the building EMS. New building equipment and appliances could support the same interface to report their own energy use. Web services (WS) aware electrical panels could use the same interface to standardize their load reporting. Combining this interface and PLie brings the buildings dumb load under management with minimal integration.

Everything above is talking about plans and designs. New systems present ongoing integration costs. WS-DD and WS-DP are new standards to enable the automatic discovery of systems. These standards enhance the value of the energy information appliances by describing what each meter is tracking.

This laundry list of energy-related specifications are the answer to high integration costs and provide a path to sustained re-integration of systems. The flow of information through Model Views into smart energy is the key to continued understanding of building performance. These specifications will move the markets in energy management systems into improved interfaces, for users, for enterprises, and for energy marketeers.