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.

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