I was discussing the
issues of this forum with several large commercial owners, this weekend. I got
some very strong feedback as to what should be in, what should be out, and what
should be left not completely pinned down…
I wrote about it in my
blog
tc
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.
"There are a thousand hacking at the branches of evil
to one who is striking at the root." -- David Thoreau
|
Toby Considine
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
|
|
Email: Toby.Considine@
unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
http://www.NewDaedalus.com
|