Advanced Building Simulation

Developments in interoperability 193
described solely through their functions, without attempting an intrinsic definition of
things. The first approach attempts to define what things ARE whereas the second
approach things are defined by what FUNCTION they perform. Depending on the
viewpoint of the modeler, different models with different semantic content will result,
but either model may be equally well suited to act as the facilitator of interoperability.
Although the theoretical discussion is interesting (Ekholm and Fridqvist 2000),
the construction of large building representations is such a steep endeavor that pragmatic
choices are unavoidable. The leading IFC development is a good example of
this. It should also be realized that there is no clear-cut evaluation criterion for building
models, except the sobering application of the tautological rule: “if it does what
it was designed for, it works.”
A Building Model is typically developed as an object-oriented data model describing
a building as a set of conceptual entities with attributes and relationships. Real buildings
are stored as populations of this data model. The model should be complete
enough so that applications can derive all their data needs from populations of the
data model. Checks on data completeness by the client applications are an important
part of the development process. The use of thermal building simulation program, for
example, requires the derivation of those data elements that allow the construction of
native geometrical representations and association of space and geometry objects to
those physical properties that are necessary to perform a particular simulation.
Assuming that each application’s input and output data can be mapped onto this
comprehensive Building Model, “full” interoperability can be accomplished. The
next section will show that this statement has to be qualified somewhat, but for now
it is a sufficient requirement for interoperability as implied in Figure 8.1. The figure
indicates that the translation of the output of application C (e.g. a CAD system) to
the neutral form as defined by the Building Model, will allow application A (e.g.
a whole building energy simulation application) to extract the relevant information
and map it to the native model of application A. There are different technologies
that can accomplish this. A growing set of tools that deal exactly with this issue have
de facto defined PDT. Especially the work by the ISO-STEP standardization community
(ISO TC184/SC4 2003) has, apart from its main goal to develop a set of domain
standards, added significantly to PDT. It has produced a set of separate STEP-PART
standards for domain models, languages and exchange formats. The latter parts have
had a major influence on the emergence of commercial toolkits for the development
of interfaces. In spite of several tries (Eastman 1999), the STEP community has not
been able to produce a standard Building Model. That is the reason why the industryled
initiative was launched by the IAI in 1995 with the quest to develop the IFC along
a fast-track approach, avoiding the tedious and time-consuming international standardization
track. After almost eight years of development, it is acknowledged that
there is no such thing as fast track in building standardization (Karlen 1995a,b).
PDT-based solutions achieve interoperability by using a common formal language
to express the semantics of the Building Model and an agreed exchange format for
the syntax of the data transfer. The Building Model is expressed as a data schema
in EXPRESS, which is the PDT modeling language of choice specified in ISO-STEP,
part 11. Interfaces need to be developed for each application to map the local
import/export data to the neutral Building Model. Such interfaces are described as
schema-to-schema mappings and appropriate tools are available from various PDT