Exchange Model and Exchange Object Concepts

for Implementation of National BIM Standards

C. M. Eastman1; Y.-S. Jeong2; R. Sacks3; and I. Kaner4

Abstract: The industry foundation class 共IFC兲 standard building model schema is a necessary but not sufficient condition for achieving
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.

full interoperability between building information modeling 共BIM兲 tools. Unless each information exchange within construction project
workflows has its specific contents and level of detail defined, the breadth and flexibility of the IFC schema leaves room for errors. The
national BIM standard approach for resolving the ambiguities of information exchange is based on “use cases,” which precisely define the
data required in each information exchange between disciplines in engineering workflows. In this paper, we define specific procedures for
developing information delivery manuals 共IDM兲, which capture the use cases and the precise information to be exchanged. We also
identify some of the data semantics we found problematic that require workflow specification. We further propose details of the infor-
mation capture that allow the IDM to serve as a specification for later implementation and testing. The procedures are illustrated using
examples from an IDM specification developed for the domain of architectural precast concrete.
DOI: 10.1061/共ASCE兲0887-3801共2010兲24:1共25兲
CE Database subject headings: Data communication; Information technology 共IT兲; Precast concrete; Standardization; Three-
dimensional models; Implementation.
Author keywords: Data communication; Information technology 共IT兲; Precast concrete; Standardization; Three-dimensional models.

Introduction tations of existing file-based methods became apparent. Paramet-

The problems of interoperability between engineering software
systems have existed since the introduction of computer-aided
design 共CAD兲 in the 1970s 共Pratt 1993兲. File-based data exchange
methods such as DXF, IGES, and SAT were developed to ex-
change geometric entities between one CAD system and another.
Most CAD systems have similar geometric entities: points, lines,
arcs, planar surfaces, curved surfaces, primitive solids, and so on.
The task in writing a geometry translator was to find the corre-
sponding geometric entity in the exchange file format and export
the CAD system entities to it. If importing, the corresponding task
involved reading the entities from the file format and loading
them into the CAD application’s native file format. These file
formats worked adequately when the objectives were limited to
geometry. However, as CAD systems became more sophisticated
and evolved into parametric and object-based modeling, the limi-
1
Professor, College of Architecture and College of Computing,
Georgia Institute of Technology, Atlanta, GA 30332-0155 共corresponding
author兲. E-mail: chuck.eastman@coa.gatech.edu
2
Postdoctoral Researcher, College of Architecture, Georgia Institute
of Technology, Atlanta, GA 30332-0155. E-mail: yeon-suk.jeong@
gatech.edu
3
Associate Professor, Faculty of Civil and Environmental Engineer-
ing, Technion—Israel Institute of Technology, Haifa 32000, Israel.
E-mail: cvsacks@techunix.technion.ac.il
4
Graduate Student, Faculty of Civil and Environmental Engineering,
Technion—Israel Institute of Technology, Haifa 32000, Israel. E-mail:
israelkaner@gmail.com
Note. This manuscript was submitted on March 14, 2008; approved
on February 9, 2009; published online on December 15, 2009. Discussion
period open until June 1, 2010; separate discussions must be submitted
for individual papers. This paper is part of the Journal of Computing in
Civil Engineering, Vol. 24, No. 1, January 1, 2010. ©ASCE, ISSN
0887-3801/2010/1-25–34/$25.00.
ric modeling involves rules and constraints that define how shapes
are to be generated or modified in various conditions; CAD sys-
tems became object-based and included attributes and relations
between objects as well as geometry 共Light and Gossard 1982兲.
There was no standard way of representing these aspects with
existing geometry exchange standards.
These more complex interoperability issues first arose in
manufacturing in the late 1980s and led to the development of
product model exchange technologies in ISO-STEP 共Standard for
the Exchange of Product model data兲, which is formally called the
ISO 10303 Standard. ISO-STEP provided the EXPRESS lan-
guage 共ISO 1994兲 for data modeling, common libraries of reus-
able structures, and methods for developing a variety of exchange
capabilities based on specialized data schemas 共Schenck and
Wilson 1994; Eastman 1999兲. This technology has enabled the
development of object-based data schemas 共Fowler 1996; ISO
1998兲 in more than 20 different areas of manufacturing and elec-
tronics 共Eastman 1999兲.
The same issues have become critical in the architecture, en-
gineering, and construction 共AEC兲 industries with the widespread
adoption of Building Information Modeling 共BIM兲 in the early
2000s 共Eastman et al. 2008兲. The cost of inadequate interoperabil-
ity for the AEC industries in the United States has been estimated
at over $15 billion 共Gallaher et al. 2004兲. While parametric
modeling of buildings has existed for as long as it existed in
manufacturing, efforts to develop a building product model ex-
change schema based on ISO-STEP technology only began in
the mid-1990s and is ongoing. This effort is the industry founda-
tion classes 共IFCs兲 共IAI 2007兲, promoted by BuildingSMART
共previously called the International Alliance for Interoperability兲
共Young 2005兲.
The manufacturing industries made significant investments in
customizing and tailoring parametric modeling tools for their

JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010 / 25

J. Comput. Civ. Eng. 2010.24:25-34.

 products 共Duvall and Bartholomew 2007兲. They rely on long-term
working relationships between organizations, developing semi-
custom exchange protocols using ISO-STEP as a foundation.
Such practices are not practical in building construction, which
relies on open partnering of small businesses 共in sharp contrast to
the automobile and aerospace industries兲 on projects that com-
monly extend for periods of three years or less. An exchange
capability using open standards is generally recognized to be an
industry need 共Tolman 1999兲.
The IFC model provides a range of means to define building
objects, processes and other information in a publicly available
data schema. It was conceived as a framework model, addressing
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
the broad scope of building design, engineering, construction, and
operation 共Björk 1995兲. It provides an extensive set of generic
building object types 共beam, column, wall, slab, etc.兲 with asso-
ciated attributes and other properties. It offers numerous shape
definition methods and means to depict relations between objects.
The intended role of IFC is to depict all information associated
with a building, from feasibility and design, through construction
and then operation and to support exchanges of this range of
information 共IAI 2007兲. While the intentions of the IFC were
laudable, it has been available for a decade but has not yet had a
significant impact on the broad problems of interoperability in
AEC.
In contrast, another building model data schema, the CIMsteel
Integration Standard 共CIS/2兲, provides capabilities specifically
tailored to the domain associated with fabrication of steel struc-
tures in buildings 共Crowley and Watson 2000兲. CIS/2 has enjoyed
the strong support of the AISC and has become widely deployed
in steel fabrication 共Eastman et al. 2005兲 and supporting inter-
faces with 15 applications. In retrospect, the purpose and appli-
cation of CIS/2 was very different from IFC. CIS/2 has limited
scope of engineering knowledge, restricted geometry, material
properties, and processes 共Crowley and Watson 1997兲. In prac-
tice, the set of applications that deal with steel analysis and fab-
rication allowed intuitive identification of a few primary
workflows and developed specific exchanges for the workflows
between the relevant applications. The primary exchanges were:
共1兲 design to fabrication; 共2兲 design to analysis; 共3兲 fabrication to
analysis; and 共4兲 fabrication to production. These workflows are
broadly supported, implemented in steel fabrication and related
applications, and used today in daily production.
The results of the IFC, on the other hand, have been difficult to
implement and utilize because the use cases in which exchanges
are to be made have not yet been clearly defined. For a building
model framework schema such as IFC, lack of definition of spe-
cific task-oriented exchange content leads to implementation of
translators that may be technically correct, but generate incom-
plete and incompatible data exchanges for specific tasks, because
of lack of coordination regarding what specific information is to
be included in the IFC view.
A proposed solution to these problems is to define the work-
flows used in practice, the specific information exchanges they
require, and define appropriate model views for the exchanges.
This is the focus of the national BIM standard 共NBIMS兲, ad-
ministered by BuildingSMART within the National Institute of
Building Sciences 共NIBS兲 共2007兲. In the NBIMS approach,
groups of people that are expert in some domain of AEC specify
“use cases” in what are called information delivery manuals
共IDMs兲 共Hietanen 2006a兲 for their domain, after which informa-
tion experts prepare implementation-oriented model view defini-
tions 共MVDs兲 共Hietanen 2006b兲 to provide the information
specifications needed to enable software developers to write ap-
26 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010
J. Comput. Civ. Eng. 2010.24:25-34.
propriate export and import translators. Use cases are detailed
descriptions of the context and content of information exchanges
between users and/or software tools.
The recommended process for generating a NBIMS specifica-
tion and implementation is described in NBIMS, Vol. 1, Section 5
共NIBS 2008兲. A general outline of the process is shown in Fig. 1.
The first phase 共program兲 focuses on domain expert input and the
second phase 共design兲 deals with IFC MVD.
This paper presents an early attempt to apply this generic ap-
proach, using the domain of architectural precast facades as a test
bed. At the time of writing, no completed content volumes of the
NBIMS had been published and the applicability of the generic
process was thus untested. The research described here required
learning and testing through design, application, implementation,
and most important, developing further detail for the various steps
involved in development of an IDM. The paper offers detailed
guidelines for the development of BIM standards following the
generic NBIMS approach. The work builds upon earlier efforts to
assess the issues involved in interoperability dealing with archi-
tectural precast 共Sacks et al., 2008; Y.-S Jeong, et al. 2009兲.
Need for Detailed Workflow Analysis
When data are exchanged between BIM tools, it is insufficient to
rely on the visual aspects of objects only. A range of aspects, not
visually apparent on a three-dimensional 共3D兲 computer model,
must be dealt with. As a shorthand, we call these more detailed
aspects of implementation the model’s semantics. Also, it is not
possible for an application data exchange translator to include the
full breadth of entities in the IFC schema; IFC entity classes
represent more information than is supported by any one domain
application. For issues regarding different types of geometry or
attributes, specific use-based targets must be defined.
Object models defined by BIM tools are depicted with five
classes of description of their contents 共Pratt 2004兲. Almost all of
these classes can be supported for IFC object representations, but
until now they have not been adequately specified for robust IFC
model exchanges. The classes are:
• Functional type: 共wall, slab, column, stairway, footing, etc.兲;
that is, an object’s functional identity must be maintained in
any exchange. This identity determines important properties
and relations of the object, i.e., riser and tread of stairs. In
existing translators, a proxy entity of IFC is sometimes used
when the appropriate function-specific type is not identified in
the source BIM tool, violating this condition. Other typical
errors are exchange of steel reinforcing as pipes, spandrels as
walls instead of structural elements, a composition of slabs for
a stairway, etc.
• Geometry: the type of geometry exchanged must be suited to
the intended purpose. Different types of geometry provide dif-
ferent capabilities to meet different functional needs. As
shown in Fig. 2, the different levels of needs are: 共1兲 visual-
ization; 共2兲 use of a shape’s surface geometry for reference or
conflict 共clash兲 checking 共Garcia-Alonso et al. 1994兲; 共3兲 di-
rect editing of simple object geometry; and 共4兲 full parametric
editing of building objects. A good survey of shape and para-
metric modeling can be found in 共Pratt 1993兲. Full exchange
of parametric editable models is not supported in current ISO-
STEP technology today 共Pratt 2004兲 and thus not supported by
IFC. In addition, abstract geometries are needed for structural,
thermal and other types of analyses 共Rezayat 1996兲.
• Attributes: different object properties are needed for different

Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
Fig. 1. Overview of the NBIMS development process; NBIMS,
Vol. 1, Section 5 共NIBS 2008兲
tasks and must be defined with agreed-to interpretable names.
These range from properties related to performance, to cost
codes, to the schedule identifier defining what task will fabri-
cate or place certain building parts during construction. If
JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010 / 27
J. Comput. Civ. Eng. 2010.24:25-34.
needed, additional property sets can be defined for IFC entities
for specific tasks.
• Relations between objects: the relevant set of topological rela-
tions is needed to define operations on configurations of
shapes. For example, structural connections are needed for
structural analyses, and nesting relations between concrete and
reinforcing are needed for spatial conflict testing 共otherwise all
reinforcing will be interpreted as conflicting with the concrete
objects in which they are embedded兲.
• Behavioral rules: the set of rules that determine how the shape
and related properties adjust within an assembly when edited,
based on context; this information is currently not exchange-
able 共Pratt 2004兲. Although the latest version of the EXPRESS
language 共ISO 2004兲 supports constraints to define behaviors
for dynamic entities, this new language version has not been
widely tested or yet used in practice.
Thus a successful exchange can only be achieved when the
exchange incorporates the semantically required subset of each of
the aforementioned classes of description for each object in that
exchange. This subset of constituent IFC entities required for any
given exchange and their needed definitions must be explicitly
defined. The subset is then the basis for translator programming
and a yardstick for measuring the success or failure of any export
or import function. Such IFC subsets are called model views.
An additional issue is that while most object classes for rep-
resenting building components have been defined in IFC, the
great breadth of the construction industry means that some spe-
cialized ones have not. As examples: some aspects of architec-
tural precast, such as the surface mix that defines the material
used on exposed faces, have no explicit representation. Also, weld
objects and specifications needed for structural steel fabrication
modeling are not yet defined. Omissions are being addressed as
the needs for new object classes are identified. Fortunately, IFC
was defined to be extensible and such extensions are usually not
difficult. Interesting errors sometimes occur when objects are not
explicitly defined and the translator writer has made arbitrary
mappings using a proxy element; such as the example shown in
Fig. 3.
Use Case Approach
It has taken several years for AEC researchers and the industry to
reach the above recognition—that without careful definition of all
aspects of each task-specific exchange, they will inevitably con-
tinue to be unreliable and faulty. From this recognition, the de-
velopment of a ”use case” approach to specifying exchanges has
emerged 共Hietanen 2006a兲. The use case approach identifies the
purpose and intent of each exchange, and specifies the necessary
content for the exchange to be successful. The implication is that
there will be many use cases, possibly hundreds, but each one
tuned from the user’s perspective to send and receive the specific
information of interest. The use case approach has been adopted
both in Europe 共BuildingSMART 2008兲 and in the United States,
albeit with slightly different forms. It is the core of what has been
defined in the United States as the NBIMS 共see Fig. 1兲.
In North America, use case definition is expected to be under-
taken by industry organizations or ad hoc groups with shared
business interests in specific areas of interoperability. Interest
groups are expected to form around building systems types, such
as structural steel, RC, curtainwalls, precast concrete, mechanical
systems, external cladding systems, site work, building control
systems, cabinets, and woodwork, etc. Other use cases will define
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
Fig. 2. Four different geometric representations and their varying functional capabilities
exchanges between architects and structural engineers, between
architects and energy consultants, acousticians, lighting consult-
ants, and other parties addressing specific design issues. The do-
main groups, with guidance from NIBS and industry advisors,
will develop the IDM and MVD addressing their priority use
cases.
The IDMs involve direct involvement of industry specialists
who know the workflows and their information flows required for
information technology 共IT兲-level exchange. Industry or univer-
sity research groups can advise and document the specification
developed. It is the responsibility of NIBS and BuildingSMART
to harmonize the different groups and their specifications, so that
they are consistent and not duplicative. The next stage, develop-
ment of MVDs, principally involves the funding of IT experts to
carry out the specification process for the relevant use cases.
These steps will typically be funded by the domain groups having
a business interest in the use cases. It is also the responsibility of
BuildingSMART and NIBS to coordinate the release of MVDs to
software vendors and to coordinate their implementation by the
vendors. Testing and certification of implementations are also an-
ticipated, although these processes have not yet been detailed.
The development of a more strictly specified set of data for
exchange starts with the identification of the purpose of the ex-
change. This is formalized through a process model 共or diagram兲.
NBIMS prescribes use of the business process modeling notation
共BPMN兲 developed by the object management group 共OMG兲, an
international, open membership, not-for-profit computer industry
consortium 共BPMN 2004兲. OMG task forces develop enterprise
Fig. 3. Connection details were not defined in a BIM tool translator
and were arbitrarily mapped to a “plant” object 共Lipman 2006兲
28 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010
J. Comput. Civ. Eng. 2010.24:25-34.
integration standards for a wide range of technologies. BPMN
was a development of such a task force to provide a standard
diagramming language that is widely used to model business pro-
cesses for Web business-to-business implementation 共BPMN
2004兲. BPMN has an associated automated XML implementation
of use case diagrams, facilitating business-to-business interoper-
ability.
A use case defines an exchange scenario between two well-
defined roles for a specific purpose, within a specified phase of a
building’s life cycle. It is both composed of more detailed process
parts and is embedded in a more aggregate process context. A use
case has a set of information that is exchanged within it. The
exchange may be a singular exchange instance, a set of iterated
exchanges, or an initial exchange instance followed by updates.
At the same time, most use cases are parts of larger collabora-
tions, where multiple use cases provide a network of collabora-
tion links with other disciplines. We call this higher level
composition of use cases a process map. Process maps are not
meant to have a fixed structure; use cases may be composed in
multiple ways to achieve the same overall purpose and may be
defined dynamically. Rather, a process map is illustrative and
meant to show where each use case is typically used.
A high-level process map for architectural precast is shown in
Fig. 4. By using BPMN it identifies the relevant life cycle steps in
vertical phases and the roles of the actors in horizontal swim
lanes. The three primary elements defined in the process map are:
• Activities, specified within a role-lifecycle context. These de-
fine the specific tasks that the use cases address.
• Activities are linked by information flows shown as dashed
lines and arrows, indicating the direction of information flow
共solid lines show the precedence relation between activities
within a role兲.
• Information exchanges, represented by exchange model (EM)
definitions on the information flows, identify the information
packet that is used in each exchange.
Activities may be iterated and indicated with an arc and arrow
symbol at the bottom of the activity. They may be high level,
indicating it is an aggregation of more detailed activities and
EMs, which is indicated with a plus sign in a small box in the
activity. A more detailed process map for Activity 1.7 is shown in
Fig. 5. The activities interacting with the decomposed activity are
repeated, to show their interaction with the decomposed activities.
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
Fig. 4. Process map for architectural precast, showing eight use cases
In order to define clearly the intentions of each activity in the
process map, short paragraphs are linked to the activities using an
index. Three examples are shown in Fig. 6. These process maps
were developed with input from representative precast contrac-
tors, consulting engineers and architects. Significant input came
from experimental work on the Rosewood project, which in-
volved careful monitoring and comparison of data exchanges
using both two-dimensional 共2D兲 and 3D representations, carried
out prior to the IDM development 共Sacks et al. 2008兲.
For example, the purpose of the use case between Activity 1.1
and 1.2 is to support collaborative design information exchanges
between an architect and a precast contractor in design-build or
other forms of collaborative development, including construction
manager-at-risk. It supports concept design information exchange,
to address such issues as panelization, structural connections,
casting alternatives, and other issues that can lead to more effi-
cient fabrication level design, without complete redesign of archi-
tectural models. Each activity and each EM is given a unique
identifier.
As IT supports more management functions within the AEC
industries, it is important that various efforts be coordinated. In
order to standardize the terms used in NBIMS use cases and to
provide consistent classification schemes for other information
associated with building models, the Omniclass tables and codes
recently defined by the Construction Specifications Institute 共CSI兲
JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010 / 29
J. Comput. Civ. Eng. 2010.24:25-34.
have been adopted. CSI has worked closely with parallel Euro-
pean efforts to develop standard classifications for many of the
terms used in construction; these are called the Omniclass Tables
共Omniclass 2006兲. There are 15 tables covering various defini-
tional aspects of building elements, processes and actors. For use
cases, the three important Omniclass definitions are for:
• Phases (Table 31) which carries the temporal aspects of activi-
ties, in creating and sustaining the built environment. Phases
include the temporal stages of a building project.
• Disciplines (Table 33) which are the practice areas and spe-
cialties of the actors 共participants兲 that carry out the processes
and procedures that occur during the design-engineering-
construction-operation life cycle.
• Organizational roles (Table 34) which are the functional posi-
tions occupied by the participants, both individuals and
groups, that carry out the processes and procedures which
occur during the life cycle of a construction entity 共Omniclass
2006兲.
These classifications are used in naming project phases and in
identifying the disciplines associating with the activities being
supported. Their purpose is to allow cross referencing between
IDMs, allowing matching and, where appropriate possible
merging.
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.

Fig. 5. Detailed process map for Activity 1.7, precast detailing, from Fig. 4

Information Delivery Manuals „IDMs…
as Specifications
The purpose of an IDM is to capture the knowledge and best
practices regarding workflows and their information contents
from experts in the user domain. Its focus is to identify the infor-
mation needed to guarantee that the targeted electronic workflow
exchanges will be effective. Clearly, a specification of needed
information of the sort “all architectural precast pieces must be
exchanged along with their geometry” is inadequate. Without
knowing the exchange purpose, we cannot determine what type of
geometry is required or what properties or relations of the archi-
tectural precast pieces are needed. The purpose determines the
functionality of the desired information. Initial efforts in defining
IDMs have not addressed the types of variability that are re-
viewed in “Need for Detailed Workflow Analysis.” As a result,
workflow implementation decisions made at the MVD stage will
likely have some amount of arbitrariness and lead to potentially
faulty implementations. A somewhat better scenario is that con-
tinued review by domain experts of the technical details of MVD
specification will be required. We view this as undesirable be-
cause the domain experts are not software experts and will not
generally be interested in software details.
Mapping the issues to their functional implications, as we pro-
pose and have attempted, makes the issues comprehensible. How-
ever, there are also strong advantages to be gained from obtaining
fully detailed functional specification of exchanges within the
IDM itself, defined at the time the workflows are identified. Cre-
ating a full functional specification at this stage has the following
consequences:
1. Representatives of the end user community that use the use
case exchanges—the domain users—can see the functional-
ity of their specification and gain a good understanding of

30 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010

J. Comput. Civ. Eng. 2010.24:25-34.

 [1.1] Concept Design of Precast Facade Type Exchange Model Definition
Name Architectural Precast Concept Stage Exchange Model
Type Activity Identifier EM.1
Name Concept Design of Architectural Precast
Omniclass Code 31-20-10-21 Preliminary design stage Change Log
Documentation Architects or designers use an approved or certified BIM 27-Oct-07 Version 0.5 created, based on Pankow project chuck.eastman@coa.gatech.edu
authoring application to develop a Building Model that will documents developed by Yeon-Suk Jeong and cvsacks@techunix.technion.ac.il
include non-structural precast façade panels. They define the Chuck Eastman of Georgia Tech and Rafael
panel layout, fenestration, and surface patterning. They place Sacks and Israel Kaner at Technion.
structural elements needed to support the precast pieces.
Project Stage 1 Concept design of Precast Façade

They identify elements that are embedded within the precast
Omniclass 31-20-10-00 Preliminary Project Description Stage
or are attached to it. The proposed layout may be made Table 31 2 Design review and Concept Modeling
available for review in sketch and drawings or as a model 31-20-20-00 Design Development Stage
3 Tender Stage Design Development
[1.2] Design Review and Concept Modeling 4 Design Development
31-25-00-00 Construction documents Stage
Type Activity GC Bid Preparation
Name Design Review and Concurrent Modeling 31-30-00-00 Procurement Stage
Omniclass Code 31-20-10-21 Preliminary design stage 6 Precast Bid Preparation
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.

Documentation A precast vendor may be consulted in reviewing candidate 7 Structural Requirements

layouts of architectural precast facades. The fabricator may 8 Precast Detailing
comment on manufacturing, shipping, fragility, lifting and 31-40-30-00 Product Development Phase
9 Construction Coordination
erection and other issues that may affect the design. These
31-40-20-34 Coordination Phase
may be passed as verbal or written comments to the
10 Design Intent Validation
architect. 11 Structural Design Review
12 Precast Fabrication
[1.3] Design Development 31-40-40-14-24 Fabrication Phase
13 Plant Material Tracking
Type Activity 31-40-40-14-11 Erection Phase
Name Design Development
Omniclass Code 31-25-10-21 Fabrication Document Preparation Phase
Documentation The architect refines the architectural precast design and
integrates its layout with other building systems. Surface
finishes, molding, reveals and other decorative features are Disciplines 33-21-11-00 Architecture
defined. The information is prepared as a construction Omniclass Table 31 33-41-14-11 Subcontractor Precast Fabricator
drawing set, or optionally, a construction-level model. 33-41-11-11 Contractor
33-21-31-41 Engineer (precast consultant) --
33-21-31-14 Engineer (Structural)
33-41-14-17 Steel Fabricator -- Iron working
Fig. 6. Few activity definitions for the process map shown in Fig. 4

what it is and is not expected to do. This eliminates surprises
after implementation.
2. The domain experts contribute in a single phase, without
cycles of review at long intervals.
3. The IDM becomes a specification that determines up front
what the MVD should accomplish, providing clear criteria
for later implementation and evaluation.
Because of these benefits, the writers have proposed and
implemented an IDM definition procedure which uses “exchange
objects” 共EOs兲 as building blocks for defining EMs. EOs are en-
capsulated definitions of the information objects that are to be
exchanged, defined in language that is in common use by domain
experts. They are, however, rigorously defined in terms of the
predefined set of functional issues that affect the semantic correct-
ness of an exchange, including the issues described in “Need for
Detailed Workflow Analysis.” All of the functional issues have
been incorporated in an EM template in an easy-to-read form,
which allows domain experts to provide definitive specifications
for EOs, achieving the benefit of functional specification at the
early stage of IDM definition. An example of the use of the EM
template is shown in Fig. 7 共header page兲 and Fig. 8 共detailed
body of the specification兲. The header page identifies the project
stage and actors, defined in both words and with Omniclass table
indices. The stages and actors laid out in the template may vary,
depending upon the targeted scope of the process map. These
should be adjusted as the process map definition is being defined.
Fig. 8 is a page from the body of the EM definition. The page
is taken from the EM definition between “design development”
and “precast detailing” in Fig. 5, labeled EM.4. The template lists
object types relevant for the exchanges defined in the process
map, grouped on the left by their different information class
groupings. The information classes are informal groupings of the
information objects to be exchanged. “EO type” is the class of EO
that may be used in the process map, and which may be any of
physical, complex property or process. These are grouped into
shared sets, defined for the particular use cases being considered.
The columns in the EM template body determine the func-
Fig. 7. Header page of the 关EM.1兴 EM definition
tional properties of the EOs as they are to be used for the EM
being defined. First, only one EO template is defined for each
EM, and not all EOs will be needed in any particular EM defini-
tion; the template allows registration of EOs as not needed, op-
tional or required. Next, the function of the geometry
representation, the type of surface geometry that needs to be sup-
ported, the accuracy of the geometry, the relations and the meta-
data required are all specified for each EO class. Three types of
relationships are noted: nesting 共for objects inside of other objects
but not subtracted from them兲, assemblies, where multiple parts
are composed into a higher-level part 共such as steel parts or a wall
with doors and windows兲, and connections that are a three piece
relation between two parts and their connection objects, which
carries special properties not noted elsewhere. Almost all objects
will have the standard metaproperties of writer, version, and
timestamp, except possibly for complex property objects. Status
data will be associated with certain objects to track progress. Fi-
nally, the EO property sets identify the different types of proper-
ties that are anticipated for the functions of the associated EO
types. There may be several of these for each object, required or
not in different contexts 共Fig. 9兲.
The purpose of the use cases and information exchange docu-
mentation is to provide a functional specification that is adequate
to specify the semantic characteristics of the product data model
entities needed at the view implementation level. Once these se-
mantics have been specified in the IDM, all later aspects of the
implementation specification and the implementation itself can be
validated against the criteria defined within the IDM. In this way,
much of the success or failure of the MVD stage can be deter-
mined by reference back to the IDM.

JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010 / 31

J. Comput. Civ. Eng. 2010.24:25-34.

 Information Exchange Object Type Geometric Meta Properties and
Surface Type Accuracy Relations
Functionality data Property-Sets

Obj Required/ Optional (R/O)

As Cast /Deformed (C/D)

Volume & clash Check

3rd Order Surfaces

Status/approvals
Regular (~ 5mm)

Author, version,
Referenceable

High (< 1mm)

Connections
Low (> 7 mm)

Assemblies
Viewable

Editable
Faceted
Meshed

Splines

Nested
Project/ Project EO_Project
Building Building EO_Building
Building Stories EO_Story
Building(s) Grid Layout EO_Grid
Main structural members: EO_StructuralMember,
EO-Building_System
Columns +
Beams +
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.

Foundations +
Slabs +
Bracing +

Secondary structural members for EO_StructuralMember,

supporting architectural precast panels EO-Building_System
Other façade systems that join with EO-Building_System
architectural precast
Other systems that connect to or are EO-Building_System
supported by architectural precast
Architectural Architectural :
Precast Façade Assemblies EO-Façadel
Elements Walls EO-Precast_Piece
Column Covers EO-Precast_Piece
Spandrels EO-Precast_Spandrel
Copings EO-Concrete_Coping

Fig. 8. Detail page of the 关EM.1兴 EM definition body

Exchange Objects, Exchange Models,

EO_Project and Mappings to Product Model Schema
Functional Semantics
………..
EO_Building
Relations
Functional Semantics The initial task is to define the EMs for all the use case exchanges
EM.1 Concept Model ………..……….. in an IDM 共using templates such as that shown in Fig. 8兲 in terms
EO Class attributes Properties and Properties and P-sets
Relations
…. …. Property-Sets ………..
………..EO_Story of their constituent EOs.
... ... EO_Project Functional
Properties andSemantics
P-sets Note that each EO can have multiple configurations, because
... ... EO_Building ………..
………..
... ... EO_Story
EO_Grid of the different levels of detail needed for different process stages,
Relations
... ... EO_Grid
Functional Semantics
………..
………..
which is expressed through the different EMs. For example, it
... ... EO_StructuralMember Properties and P-sets
Relations may be sufficient to exchange an extruded solid shape for a pre-
... ... EO_Building_System ………..
... ... ...
………..
cast concrete beam at the early stages, while the detailed geomet-
Properties and P-sets
……….. ric features along its length must also be exchanged in later
Functional type, geometry, attribute, relation
project stages. This means that each EO may have more than one
EO schema mappings must meet the
and behavior class values, as defined in requirements set by the EO class attributes mapping, as shown in Fig. 10. However, considerable economy
Section 2 and shown in Fig. 8.
can be achieved if the EOs—including their detailed software
Fig. 9. Characterization of an EM, defining the set of EOs involved mappings into MVD components—can be reused. This is possible
in a particular class of exchange wherever EO definitions are similar, or where they can made to
conform to one another.

EM.2 Contract Model EO_StructuralMember

EO Class attributes Properties and Functional Semantics
…. …. Property-Sets ………..
EM.1 Concept Model
... ... ... Relations
EO_StructuralMember
EO Class attributes Properties and Multiple
………..
... ... Property-Sets
EO_StructuralMember Functional Semantics mappings for an
…. ….
... ... ... Properties and P-sets EO according to
………..
... ... ... ……….. the EM use
... ... EO_StructuralMember Relations cases it serves.
………..
... EM.6 Fabrication
... ...Model EO_StructuralMember Some of these
EO Class attributes Properties and Properties and P-sets can be
Functional Semantics
Property-Sets rationalized to
…. …. ………..………..
reduce their
... ... ... Relations number.
... ... EO_StructuralMember ………..
... ... ... Properties and P-sets
………..

Fig. 10. Different EM views for a particular EO

32 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010

J. Comput. Civ. Eng. 2010.24:25-34.

 In Fig. 10, the different functional needs for a single EO are
shown together, defining what semantic conditions, properties and
relations are needed in the different object model exchanges. This
view is helpful for MVD specification and implementation, be-
cause many of the same EOs are defined in different EMs. Some
exchanges can use a mapping already defined for an EO, while
others have different requirements with regard to geometry, at-
tributes, and relations. The grouping of mappings for an EO can
be compared and harmonized when the data from them is orga-
nized as it is in Fig. 10.
The final determination of how many different mapping varia-
tions must be implemented for an EO will depend on the use
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
cases considered and the judgment of the MVD specifier.
The next step is to define a mapping for each EO to a set of
building product model schema objects, such as a set of IFC
entities, including their relevant properties and the relationships
between them. EOs are also called concepts. These coded map-
pings for the EOs are the basis for the MVDs; an MVD can be
compiled for any EM largely by aggregating the software map-
pings for all of the EOs included in the EM.
Note that each EO can have multiple configurations, because
of the different levels of detail needed for different process stages,
which is expressed through the different EMs. For example, it
may be sufficient to exchange an extruded solid shape for a pre-
cast concrete beam at the early stages, while the detailed geomet-
ric features along its length must also be exchanged in later
project stages. This means that each EO may have more than one
mapping, as shown in Fig. 10. However, considerable economy
can be achieved if the EOs—including their detailed software
mappings into MVD components—can be reused. This is possible
wherever EO definitions are similar, or where they can made to
conform to one another.
In Fig. 10, the different functional needs for a single EO are
shown together, defining what semantic conditions, properties and
relations are needed in the different object model exchanges. This
view is helpful for MVD specification and implementation, be-
cause many of the same EOs are defined in different EMs. Some
exchanges can use a mapping already defined for an EO, while
others have different requirements with regard to geometry, at-
tributes, and relations. The grouping of mappings for an EO can
be compared and harmonized when the data from them is orga-
nized as it is in Fig. 10.
The final determination of how many different mapping varia-
tions must be implemented for an EO will depend on the use
cases considered and the judgment of the MVD specifier. Later,
when a specific MVD for a use case is completed, the organiza-
tion coordinating the NBIMS development—NIBS—is tasked
with presenting and releasing the MVD to the relevant software
community for implementation. These steps are summarized in
Fig. 1. The figure identifies additional activities after implemen-
tation. These include validation testing and the development of a
user BIM guide for the domain covered, that will define how to
properly create a building model capable of being correctly ex-
ported using the use cases specified 共GSA 2007兲.
Conclusions
The IFC standard building model schema provides a basis for
achieving full interoperability between BIM tools. But unless the
specific contents and details are defined for each use case for
construction project workflows, the breadth and flexibility of the
IFC schema leaves room for software vendors to program trans-
JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010 / 33
J. Comput. Civ. Eng. 2010.24:25-34.
lators that do not result in effective exchanges. The NBIMS at-
tempts to resolve the ambiguities of information exchange by
defining use cases with precise workflow specifications.
The basic approach calls for the development of functional
specifications or exchange requirements defined by end users in
an IDM. These are then mapped to MVDs by IT experts. As a
result of our early experience in carrying out the IDM develop-
ment, and anticipating the later MVD specification, we have
added additional levels of specificity to the IDM object-level ex-
change definitions. This has been driven by the need to validate
later steps, at the MVD and translator implementation stages. The
basis for such validation comes from the original user need and
intended use. If these are not captured initially, they will either be
dealt with in ad hoc fashion later, or require iterated reviews by
end-users throughout the MVD definition. Instead, we have de-
veloped methods to capture detailed level information require-
ments from end users at the IDM phase of specification, so that all
later stages may refer to the specifications for guidance.
We have presented examples of the documentation, addressing
the domain of architectural precast concrete. Tables define each
use case within the processes; other tables define the information
exchanges required for the use cases. The writers have developed
more detailed objectives for defining the IDM documentation
for workflow use cases. We believe this detailed level of specifi-
cation will allow precise implementations for complex objects
that are reliable and foolproof that would not be reliably achieved
otherwise.
The expected eventual outcome of the architectural precast use
case study and implementation will be a MVD that fully ad-
dresses the information exchange needs between four primary
actors: architect, precast contractor, general contractor, and struc-
tural engineer, who deal with architectural precast issues. Other
actors, such as rebar and mesh fabricators, concrete mix plants,
and precast erection firms, may be addressed in later use case
efforts. These use cases, specified in the IDMs, will allow speci-
fication of a set of MVDs that are expected to define complete
and robust data exchange requirements that can be implemented
by software vendors whose BIM tools support the representation
of architectural precast products. Our goal is to anticipate issues
of MVD specification early in the IDM so that iterated referral
back to users is minimized. With validation and certification test-
ing, the exchange implementation of software vendors should be
reliable “out of the box” without the need for testing and debug-
ging, allowing reduced exchange cycles and leaner practices to
emerge.
The expectation that there will be many different use cases—
possibly several hundred—has raised concerns. On the user side,
it means that the intention of each use case is easily understood,
within the context of the whole set. The expectation is that IFC
export and import would involve a submenu allowing user selec-
tion from among the supported use cases for that BIM tool. The
NIBS, overseeing the NBIMS effort, has plans to publicly docu-
ment all use cases.
For companies that develop BIM software tools, the existence
of many functionally distinct use cases leads to the potential need
for possibly hundreds of distinct translators. This seems unneces-
sary. At the least, it is expected that the EOs used in the process
described here will overlap with one another at the implementa-
tion level and can be supported by a single set of IFC entities.
Possibly, EOs, as defined here, will provide libraries facilitating
translator implementation. In the longer term, it is expected that
IFC translator implementations will become “tunable,” allowing
export and import of targeted entities only. At least one imple-
 mentation of IFC export has this capability already. This targeting
may have table driven setups, which would tie in directly to use
case specifications.
In the end, robust and correct use case definitions do not guar-
antee success for building information exchanges, unless the
model instances are defined by users in the manner expected by
the object-based translation scheme. The quality of translation
will depend greatly on the naturalness of the methods required to
construct a translatable building model and whether the require-
ments for one use case are consistent, at the building model level,
with others used in the same project. These issues become appar-
ent when the BIM application’s user guides are examined for
Downloaded from ascelibrary.org by USP - Universidade De Sao Paulo on 02/15/15. Copyright ASCE. For personal use only; all rights reserved.
compatibility. These are second order issues that domain interest
groups will have to address.
Acknowledgments
The research reported in this paper was funded by the Charles
Pankow Foundation. Advisory support was also provided by FI-
ATECH and the National Institute of Building Sciences.
References
Björk, B.-C. 共1995兲. “Requirements and information structures for build-
ing product models.” Technical Rep. 245, VTT Technical Research
Centre of Finland, Espoo, Finland.
BPMN. 共2004兲. “Business process modeling notation 共BPMN兲 Version
1.0.” 具http://www.bpmn.org/典 共Oct. 30, 2009兲.
BuildingSMART. 共2008兲. BuildingSMART, 具http://www.iai.no/nor_iai_
projects.htm典 共 Oct. 30, 2009兲.
Crowley, A. J., and Watson, A. S. 共1997兲. “Representing engineering
information for constructional steelwork.” Comput. Aided Civ. Infra-
struct. Eng., 12共1兲, 69–81.
Crowley, A. J., and Watson, A. S. 共2000兲. CIMsteel integration standards
release 2: Overview, Steel Construction Institute, London.
Duvall, M., and Bartholomew, D. 共2007兲. “PLM: Boeing’s dream, Air-
bus’ nightmare.” Baseline: The project management center, 具http://
www.baselinemag.com/c/a/Projects-Processes/PLM-Boeings-Dream-
Airbus-Nightmare/典 共Oct. 30, 2009兲.
Eastman, C. 共1999兲. Building product models: Computer environments
supporting design and construction, CRC, Boca Raton, Fla.
Eastman, C., Teicholz, P., Sacks, R., and Liston, K. 共2008兲. BIM hand-
book: A guide to building information modeling for owners, manag-
ers, designers, engineers and contractors, Wiley, New York.
Eastman, C., Wang, F., You, S.-J., and Yang, D. 共2005兲. “Deployment of
an AEC industry sector product model.” Comput.-Aided Des., 37共11兲,
1214–1228.
Fowler, J. 共1996兲. STEP architecture and methodology, PDT Solutions,
Bentham, U.K.
Gallaher, M. P., O’Connor, A. C., John, L., Dettbarn, J., and Gilday, L. T.
共2004兲. “Cost analysis of inadequate interoperability in the U.S. capi-
tal facilities industry.” Rep. No. NIST GCR 04-867, National Institute
of Standards and Technology, U.S. Dept. of Commerce Technology
Administration, Gaithersburg, Md.
Garcia-Alonso, A. M., Serrano, N., and Flaqueer, J. 共1994兲. “Solving the
collision detection problem.” IEEE Comput. Graphics Appl., 14共3兲,
34 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING © ASCE / JANUARY/FEBRUARY 2010
J. Comput. Civ. Eng. 2010.24:25-34.
36–43.
GSA. 共2007兲. “GSA building information modeling guide series: 02-GSA
BIM guide for spatial program validation.” 具http://www.gsa.gov/bim/典
共Oct. 30, 2009兲.
Hietanen, J. 共2006a兲. Information delivery manual guide to components
and development methods, BuildingSMART, Oslo, Norway.
Hietanen, J. 共2006b兲. IFC model view definition format, International Al-
liance for Interoperability, 具http://www.iai.international.org/software/
MVD_060424/IAI_IFCModelViewDefinitionFormat.pdf典 共Mar. 15,
2009兲.
IAI. 共2007兲. IFC/ifcXML specifications, 具http://www.iai-international.org典
共 Oct. 30, 2009兲.
ISO. 共1994兲. Industrial automation systems and integration—Product
data representation and exchange—Part 11: Description methods: The
EXPRESS language reference manual, ISO TC184/SC4,
具http:websotre.ansi.org/典 共Oct. 30, 2009兲.
ISO. 共1998兲. “Guidelines for the development and approval of STEP
application protocols.” ISO TC184/SC4, 具http://webstore.ansi.org/典
共Oct. 30, 2009兲.
ISO. 共2004兲. “Industrial automation systems and integration—Product
data representation and exchange—Part 11: Description methods: The
EXPRESS language reference manual.” ISO TC184/SC4 具http://
webstore.ansi.org/典 共Oct. 30, 2009兲.
Jeong, Y.-S., Eastman, C., Sacks, R., and Kaner, I. 共2009兲. “Benchmark
tests for BUM data exchanges of precast concrete.” Autom. Constr.
18, 469–484.
Light, R., and Gossard, D. 共1982兲. “Modification of geometric models
through variational geometry.” Comput.-Aided Des., 14共4兲, 209–214.
Lipman, R. 共2006兲. “CIS/2 and IFC for structural steel.” Building SMART
day, presentation, Dec. 7, 2006.
NIBS. 共2007兲. 具http://www.nibs.org/buildingsmart3.html典 共Oct. 30, 2009兲.
NIBS. 共2008兲. United States national building information modeling
standard version 1—Part 1: Overview, principles, and methodologies,
具http://nbimsdoc.opengeospatial.org/典 共Oct. 30, 2009兲.
Omniclass. 共2006兲. Omniclass: A strategy for classifying the built envi-
ronment, introduction, and user guide, 1.0 edition, Construction
Specification Institute, Arlington, Va., 具http://www.omniclass.org/典.
Pratt, M. 共1993兲. “Geometric methods for computer-aided design.” Fun-
damental developments of computer-aided geometric modeling, L.
Piegl, ed., Academic Press, London, 271–320.
Pratt, M. 共2004兲. “Extension of ISO 10303, the STEP standard for the
exchange of procedural shape models.” 2004 Int. Conf. on Shape
Modeling and Applications (SMI 2004), IEEE Computer Society
2004, Genova, Italy.
Rezayat, M. 共1996兲. “Midsurface abstraction from 3D solid models:
General theory and applications.” Comput.-Aided Des., 28共11兲, 905–
915.
Sacks, R., Kaner, I., Eastman, C., and Jeong, Y.-S. 共2008兲. “The Rose-
wood experiment—Building information modeling and interoperabil-
ity for architectural precast facades.” Autom. Constr., in press.
Schenck, D. A., and Wilson, P. R. 共1994兲. Information modeling the
EXPRESS way, Oxford University Press, New York.
Tolman, F. 共1999兲. “Product modeling standards for the building and
construction industry: Past, present, and future.” Autom. Constr., 8共3兲,
227–235.
Young, N. 共2005兲. “Interoperability: A growing understanding and mo-
mentum.” Proc., Interoperability Int. BuildingSmart Conf. 具http://
www.iai.no/2005_buildingSMART_oslo/June 1st/05 Norbert Youbd
Oslo-Interoperability 1 Jun05.pdf典 共Oct. 30, 2009兲.