Services

Enterprise Interactions for Physical Security

As promised a week ago, here are some scenarios for physical security systems interacting with enterprise systems, and even through the enterprise to other enterprise-enabled buildings systems.Hotels, Customer Service and Energy

Hotels put a lot of effort into their customer relationship management. Building space, if well operated, cost the same in similar cities. Beds are beds, as long as they are clean. Hotels compete for customer loyalty to develop preferences that make the consumer check their hotel chain first rather than merely going to hotels.com.

The vision of Hotel Technology Next Generation (HTNG.org) includes rooms that respond automatically to the customers...

Read More

It’s all too cheap!

Even with today’s rising energy costs, most things do not cost very much. This is a good thing. Food, as a percentage of income, is still at historic lows. In real dollars, gasoline is just where it was at the birth of the modern car in 1908. For most people, switching to a more fuel efficient car will not pay back the initial capital outlay in the next five years. Local energy generation just doesn’t pay back its installation cost quickly enough. A penny saved may be a penny earned, but today, everyone leaves their pennies by the cash register. Gas prices do not
Read More

Service enabling Telecommunications – lessons for Buildings and Grid

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk at the OASIS conference on the challenges facing a company learning to dance in the world of SOA and mash-ups. Nortel, of course, grew up with rigid account control and vertical integration in a regulated environment. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons. Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure ...
Read More

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.