Distinguishing Building Service Semantics from Ontologies

Building service performance is not handled well during building design because there is currently no accepted way for owners and designers to discuss the services desired and the performance expected for each service in simple general terms. Construction processes deliver diverse technical systems each discussed using concrete physical attributes whose effects are understood through a deep domain knowledge not often common to either owner or designer, or even to different contractors. This leads to specifying materials and processes rather than results, is ineffective in defining success after commissioning into long term operations and maintenance.

New demands that buildings interact dynamically with entities other than the owner and operator will soon require that provisioning of services be managed over the lifecycle of the building rather than merely for procedural completeness at building turnover. These external entities include power provision and emergency management. The transacted power grid will expect buildings to negotiate with remote, local, and internal energy suppliers to meet the needs of the occupants. Emergency Management will expect buildings to respond to environmental alerts, i.e., tornado warnings, to provide situational awareness after an event.

Over at ONTOLOG, several of us are formalizing new semantics to enable discussion of building services and their quality. These words will provide a common basis for discussing service between all actors over the life of the building. They will also provide the groundwork for buildings to interact with actors external to themselves.

If we do this right, these semantics will become the basis for interacting with BIM. Each area of knowledge and practice within the Building Information Model (BIM) has a formal interface to other areas of the BIM. This interface allows information to flow both ways. Information flows into an area to define goals and constraints. Information flows out of an area to provide results and requirements. This allows for multiple processes within each area. During design, the goal is to let the owner participate in decision earlier in the process. Imagine the following scenario.

During design, a six story building is designated as commercial space on the ground floor, a restaurant on the second, and office space for the next 4 floors. Quality indicators for all three types of space rely on the Effective Ventilation Index (EVI). Commercial Comfort Index is defined based upon room temperature, humidity, occupancy, and EVI. The standard for a strip mall is 1.0. The lessee, a high end store, requests that a CCI of 1.2 be provided, and documented by the underlying systems, and that it be done at a watts/square foot no worse than industry standard. The restaurant is divided into seating area, which uses the standard CCI and the catering area, in which a higher EVI is required by regulation. In the seating, the CCI must take into account the higher density of sitting customers as compared to the retail space downstairs. Office space is quite competitive and the local market has high vacancy rates. The owner wishes to promise Office Worker Alertness index greater if 0.8 (prevailing standard is 0.64) to achieve reduced vacancy in the prevailing market.

I shared this vision with Bo, a seasoned real estate professional who remains one of my more skeptical audiences. He vigorously objected. To Bo, a developer might choose to distinguish itself though having many more air turns per hour than the competition. They would still want to discuss the value in the same terms, but would not wish to be held to the same engineered standard of comfort. Bo vigorously objected to a mathematical standard for the comfort index….

This threw me for a loop. Then I recalled some spirited discussions from the Business Process Execution Language (BPEL) groups. BPEL is the language for passing a work flow or business process around using web services. There have been spirited discussions about BPEL, including conversations that claim that BPEL is not useful because business process is the proprietary advantage of any business, and so therefore real business process will never be passed around. This seemed to align with Bo’s comments.

Let me reprise semantics and ontology how I use these words. Semantics are the words used to describe things. When similar things get the same name, we are making semantic decisions. As people, semantics let us discuss the services provided by a system, and to compare and contrast how well those services are provided. To systems, semantics create a basis for interoperability and the creation of Services. Ontology, or meaning, is a way to discuss a value of the services; ontologies are variable. Crudely, accounting is a semantic system; cost accounting and financial accounting are different ontologies built upon common accounting semantics.

If we take this model, than I agree with Bo. The concrete basis for value in building services require a common semantic framework. At the highest level of abstraction, these services slide into ontology, where the building operator defines value. The building operator, or even the building designer, must be able to define value, to define the construction of the top level semantics.

And that is the swing between building service semantics and building service ontology.

Busy day on the Standards Front

Today was consumed with what is either standards minutia or very big stuff. I am too tired to write of anything else, so let me explain what’s afoot.

Scheduling

Building system schedules today are too involved, and require too much process information. If I want to meet at 9:30 tomorrow morning, I want the room air-conditioned and ready to go by 9:30. I don’t want to learn about heat times, cool times, warm-up times. Be ready. By 9:30.

The enterprise standard for scheduling was developed years ago for use in email and its name is vCalendar or vCal. vCAL can not only schedule that meeting tomorrow, but can schedule it every two weeks, or on the second Thursday of every month, or even every two weeks except in a month that has three Tuesdays. vCAL has all the flexibility one could want.

vCAL was refreshed for internet transmission and stand-alone download into the internet calendar standard, or iCalendar. When you book airline tickets and it says “click here to add to your calendar”, you are using iCalendar. Apple muddied the water by writing the program iCal to use ICAL, but it us really the stand-alone version of vCal.

In early 2001, an attempt was begun to define iCalendar in XML, xCalender. As far as I can tell this project stalled out in 2002. oBIX has been meeting for some months to integrate xCal into scheduling system scheduling.

Today, I received the suggestion that I look at hCAL instead. hCalendar (short for HTML iCalendar) is a Microformat standard for displaying a semantic (X)HTML representation of iCalendar-format calendar information about an event. hCAL is designed for display, but it has a socket in which to nestle additional XML information. This seems nicely pre-adapted for oBIX, as well as DR (demand response) events. hCal was designed to allow parsing tools to extract the details of the event, and display them using some other website, index or search them, or to load them into a calendar or diary program.

Today, I am trying to get oBIX to make decisions as to how to use viCal, to share that decision with OpenADR, and to move on.

Whatever happened to oBIX?

I was asked this week “Whatever happened to oBIX?” I paused. I knew I was using it. I know I get phone calls about it regularly. Still, aside from the recent Frost & Sullivan report on oBIX and the enterprise, matters related to oBIX have been quiet since the ratification of version 1.0. There are two types of reasons that you don’t hear about oBIX.

The first is that as in a long running add by a chemical company, you don’t buy oBIX, oBIX just makes the things you buy, better. oBIX is a small protocol among the many small protocols in the enterprise. oBIX enterprise-enables control systems. oBIX lets you build new kinds of applications. If you did buy oBIX, you bought it as part of an application.

The second is that those people who know oBIX best have been going out and doing things with oBIX. Many of these projects are large, and may take years to complete. We’ve been busy.

So today, I’m pulling together some of the projects that I have some, even if often just a very little, knowledge of.

• The Enterprise Building Management System (EBMS) at UNC that operates more than 100 buildings of all brands and technologies. All external interactions with buildings are by web services. Sixty-six of these buildings are operated by oBIX. An iLON controller with full oBIX support would probably become are preferred platform for future integration. If you are interested in EBMS, simply search for it in the archives.
• The Dubai Airport. Dubai has become known for leadership and innovation in construction and sustainability in capital projects. I do not have a contact for this, but would be very happy to know more. If hear the Dubai airport integration is based on product from Tridium. oBIX is a key component of the newest NIAGARA integration platform from Tridium. Tridium’s NIAGARA is used to integrate many complex systems. oBIX even provides the integration layer between their current product (R3) and their previous product (R2) ( http://www.tridium.com/cs/products_/_services/niagaraax )
• Building systems in the Olympic Stadium, the Olympic Village, and all outdoor lighting in the Olympic District in Beijing. This work was, if I am informed correctly, based upon a variant of the 0.7 draft of the specification. As stated above, these projects take years to complete, and decisions get locked in long before construction completion.
• I hear some reports that the Olympic variant of oBIX is used for energy management of whole city districts of mixed use new buildings in Chinese cities.
• Powernab’s YouTility service is integrating in-house services, weather conditions, and solar monitoring for end-user. If I am correct, Powernab uses oBIX interfaces developed by Controlco. ( www.powernab.com , www.controlco.com )
• Hawkesbury provides oBIX-based energy monitoring in a lot of interesting scenarios. ( www.esightenergy.com ).
• NTT in Tokyo is developing oBIX drivers, but I know little more than that.

I would really like to hear from anyone who knows more about these projects, or about more projects I should know of. Please feel free to post them here or write to me at Toby.Considine@gmail.com.