Search Archives
Why New Daedalus?

Daedalus was the mythical great architect and artificer of the classical world. Today, embedded intelligence is enabling the most profound changes in the way we create and use buildings since his day.

Building Intelligence meets the Intelligent Building. The Intelligent Building negotiates with the Intelligent Grid. How will this transform how we interact with the physical world?

More on the Web
Powered by Squarespace
« Smart Buildings, Smart Energy, and the Road Ahead | Working with the Wind in Chicago »

Coordinating Time and Energy

Buildings use 46% of the energy used in North America. Consensus guesses are that buildings could reduce their energy use by a third while improving the amenities they offer, by becoming enterprise-responsive without other change in technology. Clearly the most basic enterprise interaction is what is the schedule for each room, and how many people will be using the room.

The best guesses are that half of the electricity generated each year in the North America is wasted due to poor alignment of generation and consumption. The way to align the behaviors of these two groups, each autonomous, and each with quite different values is price signals. As each price signal, and each energy contract, would include a schedule component, we need a standard way to discuss schedules in web services for power negotiations.

17% of North American generation is used for less than 110 hours per year. Utilities want to manage the consumption patterns using a process they refer to as Demand-Response. Demand Response always has a scheduling component. It would be nice to use the same xml object for buildings, energy markets, and demand response. Add in weather arbitrage for distributed generation and more domains need to share common scheduling information.

So I went looking for a calendar standard for web services I could use. I as surprised not to find one. I am looking for a small "micro-specification" that would not exist on its own, but would be incorporated into other specifications. I call this WS-Calendar. I want to keep WS-Calendar (or whatever) small as I think that we can get it off the ground and completed quickly. oBIX has gotten about half way there, but I fear a component of a control system standard will not be picked up elsewhere (for social reasons).

oBIX needs it because a significant component of enterprise responsiveness is letting building systems easily receive scheduling information from business programs. Most of us regularly invite 7 people and a room to a meeting. If the "room calendar" could inform the building systems to be ready on time, and to ventilate for 8 people, more efficient operations would result. We have all been in conference rooms that are freezing with 4 people in attendance, and sleepy when 15 are in attendance...

There are some remaining issues in such a standard. Do I put my performance contract inside the Calendar (as a meeting is) or outside but within the same payload? Would I refer to one, or several, oBIX contracts from within the Calendar? Could contracts refer to one or several calendar items? It seems to me that the same issues would come up if the calendar was part of a BPEL, or part of OpenADR, or even part of WSDM.

Watch soon for discussion prior to the formation of the WS-Calendar Technical Committee in OASIS. And drop me a line if you want to participate, or if you have other use cases you want to share.


PrintView Printer Friendly Version