1
DEVELOPMENT OF NATIONAL BIM STANDARD
USE CASES FOR ARCHITECTURAL PRECAST
Eastman C.M*., Jeong Y.-S*., Sacks R**. and Kaner I**.
* College of Architecture, Georgia Institute of Technology, Atlanta, GA.
** Faculty of Civil Engineering, Technion - Israel Institute of Technology, Haifa, Israel
Abstract:
The IFC standard building model schema is a necessary but not a sufficient condition
for achieving full interoperability between building information modeling tools. Unless
the specific contents and level of detail is defined for each exchange case within a
construction project workflow, the breadth and flexibility of the IFC schema leaves
room for errors. The errors occur because software vendors program translators that,
while compliant with the standard, do not export or import the specific data needed
for the targeted exchange. The National BIM Standard approach for resolving the
ambiguities of information exchange is based on ‘use cases’ which are precise
workflow specifications. The paper describes the approach in detail, using examples
from a specification developed for the domain of architectural precast concrete. It
concludes that the approach, starting with formal definition of use cases by industry
interest groups, is an effective method for enabling definition of model views that
narrow the scope and define the detail of IFC objects needed for any given set of
2
specific exchanges. This will allow vendors to provide robust and trustworthy
translators.
Keywords: Building information modeling, BIM, National BIM Standard, NBIMS,
Industry foundation class, IFC, Architectural precast, Data interoperability.
1. Introduction
The problems of data exchange have existed since the introduction of computer-
aided design (CAD) in the 1970s [Pratt, 1993]. File-based exchange methods such
as DXF, IGES and SAT were developed to exchange geometric entities between one
system and another. Most CAD systems have similar geometric entities: lines, arcs,
planar surfaces, curved surfaces, primitive solids, etc. The task in writing a geometry
translator was to find the corresponding geometric entity in the file format and export
the CAD system entities to it, or if importing, reading the entities from the file format.
These file formats worked well when the objectives were limited to geometry.
However, as computer-aided design became more sophisticated and evolved into
parametric modeling, the limitations of file-based methods became apparent.
Parametric modeling involves rules and constraints that define how shapes are to be
generated or modified in various conditions; CAD systems became object-based and
included attributes and relations between objects as well as geometry [Light and
Gossard, 1982].
3
These more complex 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
Working Group. ISO-STEP provided the EXPRESS language [ISO TC184/SC4,
1994] for data modeling, common libraries of re-usable structures, and methods for
developing a variety of exchange capabilities based on data schemas [Eastman,
1999;Chap.5]. This technology has enabled the development of object-based
exchange models in more than 20 different areas of manufacturing and electronics
[Owen, 1993].
Now, these issues have arisen in the construction industry with the advent of
Building Information Modeling (BIM) [Eastman et al., 2008]. The manufacturing
industries made significant investments in customizing and tailoring their parametric
modeling tools for their products [Duvall and Bartholomew, 2007] and rely on long-
term working relationships between organizations, leading to 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 commonly
extend for periods of two years or less. An exchange capability using open standards
is generally recognized to be an industry need.
4
A partial solution has been provided through the development of a building product
model exchange schema based on ISO-STEP technology [ISO TC184/SC4, 1998].
The Industry Foundation Classes (IFC) standard schema, developed by
BuildingSMART (previously called the IAI) provides a range of means to define
building objects, processes and other information in a neutral data schema. It also
provides an extensive set of generic building object types (beam, column, wall, slab,
etc.) with their associated attributes and other properties. It offers numerous shape
definition methods and the means to depict relations between objects. The IFC has
been targeted to depict all information associated with a building, from feasibility and
design, through construction and then operation [IAI, 2007].
Another building standard, the CIMsteel Integration Standard (CIS/2), provides
similar capabilities but is specifically tailored to the narrow domain of steel structures
in buildings [Crowley and Watson, 2000]. Thanks to its limited scope, limited
geometry, material and fabrication processes, and with the strong support of the
American Institute of Steel Construction, CIS/2 has become widely deployed in steel
fabrication [Eastman et al., 2005]. The IFC releases began about the same time as
the CIMSteel standard (the forerunner of CIS/2) [Crowley and Watson 1997], but its
deployment has been less effective. The IFC implements a broad set of building
objects, with a wide range of geometry and attributes for different uses. However, the
results have been difficult to utilize because the use cases in which exchanges are to
be made have not yet been defined. For a broad building model schema, such as
5
IFC, lack of definition of exchange content leads to implementation of translators that
often generate incomplete and erroneous data exchanges, as illustrated by some
small examples below. The result is that IFC has been less effective to date than
CIS/2.
The proposed solution to these problems is the National BIM Standard (NBIMS). In
the NBIMS approach, user representatives specify use-cases in what are called
Information Delivery Manuals (IDM)s, after which experts prepare implementation-
oriented Model View Definitions (MVD) to provide the information specifications
needed to enable software developers to write appropriate export and import
translators. In the following sections, the approach and structure of the National BIM
Standard is outlined and part of its implementation reviewed, using the example of
architectural precast facades.
2. The need for detailed workflow analysis for data exchange
Object models defined by BIM tools are depicted with five classes of description that
define their contents [Pratt, 2004]:
Type: according to their object class (wall, slab, column, footing, etc.); that is, a door
is exchanged as a door, a wall as a wall, or stair as a stair, a spandrel as a spandrel,
rebar as rebar etc.;
Geometry: the correct type of geometry for the intended purpose. Simple geometry
6
for layout and conflict testing; parametric geometry for editable changes with the
equivalent set of relations allowing editing;
Attributes: the needed set of properties defined with agreed-to interpretable names;
Topological relations with other objects: the relevant set of topological relations
that are needed to allow proper editing of configurations of shapes, such as
assemblies;
Behavioral rules: the set of rules that determine how the shape and related
properties adjust within an assembly when edited, based on context.
Thus, when data is exchanged between BIM tools, it is often insufficient to exchange
the obvious aspects of object type and geometry correctly connected to native
objects. A range of additional more subtle aspects, not visually apparent, must also
be dealt with. Even given a full IFC schema definition, a successful exchange will
only be achieved when the exchange incorporates the semantically required subset
of the above classes of description for each object in that exchange. The subset and
the specific contents of its constituent parts required for any given exchange must be
defined explicitly; that subset is then the basis for programming and a yardstick for
measuring the success or failure of any export or import function. Most of these
classes of description have been defined for specific exchanges in CIS/2, as a result
of extensive trial-and-error collaboration between software vendors. That
collaboration and definition has only recently begun in IFC.
7
We review each of these various issues. First, while most classes for representing
building objects have been defined in IFC, the great breadth of the construction
industry means that many specialized ones have not. As examples: architectural
precast façade panels have no prescribed definition in the IFC schema, and neither
have the various parts of architectural precast, such as the surface mix that defines
the material used on exposed faces; also, weld objects are not defined, as needed
for structural steel fabrication modeling. These omissions are being added as the
need for new object classes are identified. Their implementation is usually not
difficult, but it is absolutely necessary that the object classes be explicit and agreed
upon. Interesting errors sometimes occur when objects are not explicitly defined and
the translator writer has made arbitrary mappings using a proxy element; an example
is shown in Figure One.
FIGURE ONE: Connection details were not defined in a BIM tool translator and were
arbitrarily mapped to a ‘plant’ object [Lipman, 2006].
8
Boundary
representation
Constructive solid geometry Cross-section
extrusion
FIGURE TWO: Three different methods that could be used to define the same
geometry.
Second, while IFC is generally effective in the exchange of geometry in some form,
editable geometry has generally not been realized. Translation of editable geometry
is difficult. This can be explained by reference to Figure Two. IFC includes a wide
range of geometric constructs, in order to support the needs of all CAD systems for
different kinds of editing. As a result, even a simple shape can be represented in IFC
in a range of ways. The most basic geometric representation used in most BIM tools
is boundary representation [Braid, 1975] (Figure Two (a)). It is composed of a set of
faces that enclose a volume and is the representation used to display an object, to
carry out volumetric calculations and clash detection [Garcia-Alonso et al., 1994].
While it is general, it is not suitable for editing, because it has no easily editable
9
parameters. In the Constructive Solid Geometry (CSG) representation (Figure Two
(b)), the Boolean operators for shape subtraction and addition allow easy creation
and editing of complex shapes [Braid, 1975]. Boolean operations can be applied to
simple primitives and also to boundary representation shapes and are the principle
way boundary representations can be modified. Shapes represented with the
Boolean operations can be edited by changing the multiple primitive shapes’
parameters or their location and re-executing the sequence of additions and
subtractions. Shape extrusions are the third way to represent shapes (Figure Two
(c)). They sweep a face surface or polygon along a path to create a shape. They are
heavily used in parametric modeling. Sweeps have parameters for the layout of the
generating face surface and the length and path of the extrusion. An extrusion is
typically turned into a boundary representation and can be combined with Boolean
operations.
A parametric shape is some combination of these constructs, meant to facilitate
editing within a given context. In all of these cases, the same shape could be
generated using any of these different geometric representation schemes; however,
what can be done with the shape in terms of parametric manipulation, is different in
each case.
Upon export from a BIM tool to an exchange format, an object’s shape can be
represented in some combination of these ways. Most often it is simply as a
10
boundary representation, which combines the edits of all the others. In fact, this is
almost the universal way parts have been exported in IFC up until now. It is general
but severely limited. The result of course is that the objects imported into a receiving
application are not editable because the basic constructs from which they were
composed, and the logic of their composition, have been lost. Although their whole
shape may possibly be edited using new Boolean operations, if they were originally
generated using constructive solid geometry operations, the shapes used in the
original Boolean operations are no longer available. Only with a careful coordination
of the export that reflects the design intent of the object can a shape be exported in a
format editable within other systems.
The third issue is that there are many places where an attribute or property can be
located within an IFC object. It has many ‘slots’ that can receive attribute data. Also,
attribute names can vary. For example, the number of a room in a building and its
room type or function class can be defined using any mix of the available slots for
Name, Description, and Object Type available in IFC. It is hardly possible to guess
which is which without explicit rules for their assignment. Energy, acoustic and other
properties have similar ambiguities.
The fourth and fifth issues are topological relations and the rules within and between
objects. IFC translators currently pay attention to only a few relations between
objects, such as nesting (e.g. doors and windows nested in a wall) because other
11
relations are not clearly specified in object exchanges. Similarly, standard parametric
rules defining an object’s required behavior when the object’s context has changed
have not been defined within the IFC standard. These issues are very complex
because the different BIM applications have different internal relations and rules. For
example, the logical notion that doors and windows must be embedded in walls and
generate openings in them is well established in architectural applications, but the
same behavior is not preprogrammed into engineering BIM applications.
With such variety, it is not likely that the export translation from one design or
construction tool will match well with those expected from another. Benchmark tests
show that for new object types, a wide range of errors occur, including corruption and
loss of complex geometry, non-equivalent parametric cross-section profiles, and
different object classes, when the mapping is between design and construction
stages. The results are only partially usable without extensive clean-up and
correction [Jeong et al., 2008]. A more detailed level of exchange functionality is
required that specifies these semantic aspects of objects and assemblies.
For all of these reasons, object schemas such as IFCs are a necessary but not a
sufficient condition for achieving robust data exchanges for construction. Standards
that define what subset of the schema is to be exchanged in each context are
required. The National BIM Standard approach [NIBS 2007] for resolving the
ambiguities of information exchange is based on the specification of explicit use
12
cases which are related to work processes.
3. The Use Case Approach of the National BIM Standard
It has taken several years to make the above recognition – that without careful
definition of all aspects of each exchange, they will inevitably continue to be
unreliable and faulty. From this recognition, the development of a ‘Use Case’
approach to specifying exchanges has emerged [Hietanen, 2006]. The Use Case
approach identifies the purpose and intent of each exchange, and specifies the
necessary content for such an 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 and in the US, albeit with slightly
different forms. It is the core of what has been defined as the National BIM Standard
(NBIMS).
The development of a more strictly specified set of data for exchange starts with the
identification of the purpose of the exchange. 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. OMG
task forces develop enterprise integration standards for a wide range of
technologies. BPMN was a development of such a task force to provide a standard
13
diagramming language that is widely used to model business processes for Web b2b
implementation [BPMI.org, 2004]. BPMN has associated automated XML
implementation of Use Case diagrams, facilitating business-to-business
interoperability.
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 has a set of
information associated with it that is documented in a template. The information
identifies the life cycle phase, the roles of the actors, the purpose of the exchange,
the conventional (manual) means to carry it out, the software that might be engaged
in sending or receiving the exchange, the benefits that the exchange offers, and the
level of automation assumed. This last issue distinguishes between file type
exchanges, iterations through a repository, or direct XML exchanges, each of which
will have different granularity. An example template for an architectural precast use
case, between architectural designer and precast fabricator, is shown in Figure
Three.
14
FIGURE THREE: Use Case template for Concept Design of Precast Concrete
The purpose of this particular use case is to support collaborative design information
15
exchanges between an architect and a precast contractor in design-build or other
forms of collaborative development, including construction manager-at-risk [ENR,
2002]. It supports concept design information exchange, to address issues of
panelization, structural connections, casting alternatives and other issues that can
lead to more efficient fabrication level design, without re-design. Each use case is
given a unique identifier. The section of the overall BPMN diagram that outlines the
exchange, shown in Figure Four, defines specific data which should be exchanged
between two processes.
16
FIGURE FOUR: BPMN diagram for Use Case defined in Figure Three.
In order standardize the terms used in NBIMS Uses Cases, and to provide consistent
classification schemes for other information associated with building models, the
tables and codes defined by the Construction Specifications Institute (CSI) are
adopted. CSI has worked closely with parallel European efforts to develop standard
classifications for many of the terms used in construction; these are called the
Omniclass Tables [Omniclass, nd]. There are fifteen tables covering various
definitional aspects of building elements, processes and actors. For use cases, the
two important Omniclass definitions are for:
Disciplines (Table 33), which are the practice areas and specialties of the actors
(participants) that carry out the processes and procedures that occur during the life
cycle of a construction entity.
Organizational Roles (Table 34), which are the functional positions 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, nd].
Associated with each use case is the Process Model describing its information flows
in BPMN. The use case process model for Concept Design of precast concrete is
17
shown in Figure Four. A use case often involves more than one instance of an
information exchange and exchanges may be performed repeatedly where design
demands iteration. The Concept Design of the precast concrete use case has two
information exchanges: one from architect to precast consultant, the other in the
reverse direction. It is at the information exchange level that real data flows are
defined.
Each information exchange has an identifier. It also has a template carrying its
information content. The template for information exchange A-P.10 is shown in
Figure Five.
The Information Exchange template identifies the assumed required pre-conditions
on the data, indicating its status (for example, candidate design, approved design,
suggested revision). Its main content is to identify the range of IFC entities that may
need to be exchanged to support this specific data exchange, in terms defined by
practitioners. The objects are defined at three levels: in terms of their name, data
type (if known), and important attributes. Further detail may need to be identified,
such as the range of geometrical object types, surfaces types and custom data,
possibly using extensible property-sets.
The purpose of the Use Cases and Information Exchange documentation is to
provide a functional specification that is adequate for defining the product data model
18
entities needed at the view implementation level.
As a next step, we review the procedure through which use cases are defined and
explain how they are used to make more robust exchanges. Lastly, the overall
process for developing a BIM standard is described.
19
FIGURE FIVE: The Information Exchange template for A-P.10
20
4. Use Case Development Processes in the NBIM Standard
There have been many instances of researchers developing data exchanges in
anticipation of the development of software applications and user needs [Froese,
1996]. Software companies are often skeptical that there is an end-user need for
exchanges, especially when proposed by research teams. Because of these
experiences, such exchange capabilities should be user-driven. That is, they should
respond to the digital exchange of data between known applications and respond to
the explicit needs of one or more class of user.
There are many contributors to a building model, providing a wide range of actors
throughout the planning, design, construction and operation of buildings or
infrastructure. The Omniclass Table 33 lists about 170 relevant disciplines. There is
also a very wide range of materials and systems that can be used to construct a
building. The Omniclass Table 23 lists approximately 3,600 classes of product types
for use in construction (this includes heavy construction, in addition to buildings).
Thus it is likely that a mature set of use cases will number in the several hundreds
and possibly in the thousands, depending upon their scope and breadth of
application.
The recommended process for generating a national BIM standard specification and
implementation is described in NBIMS, Volume 1, Chapter 5 [NIBS, 2007]. A general
outline of the first two phases of that process (Program and Design) shown in Figure
21
Six, is the following:
Identification or formation of a domain-specific user group with interest in specifying
and supporting the implementation of a set of use cases.
Outlining of a set of exchange requirements by the user group. The set is first
identified in a process model compiled using BPMN.
Identification of the information exchange requirements, in terms of objects,
properties, relations, and the business rules that are applicable. These requirements
can be defined in various ways to maximize their review and readability by the
domain community.
Documentation of the above in the form of an Information Delivery Manual (IDM),
with review and comment; identification of parallel or overlapping efforts.
Definition of the information concepts in a computable language schema, such as
IFC, CIS/2 or other exchange mechanisms, relevant for the use case and definition
of the exchanges in those terms.
Harmonizing of the identified software concepts with similar ones, especially those
representing similar products or materials or information at different stages of the
building lifecycle.
Mapping or binding these object model definitions into an implementation level Model
View Definition (MVD). Definition of a validation test suite that identifies and checks
proper reading (import) of each entity addressed in the MVD; also define a check
model that can validate the proper export of entities to be covered in the MVD.
22
Submission of any needed extensions to the IFC schema identified in the MVD to
Building SMART for its approval process.
Preparation of modeling guidelines associated with authoring BIM tools and validate
data in the BIM model whether the data satisfies MVD or not.
Development of certification guidelines that allow full use assessment of the MVD in
production conditions, for both expert and import.
23
24
FIGURE SIX: Overview of the National BIM standards development process.
Once an MVD for schema-specific model definition is completed, the organization
coordinating the NBIMS development – the National Institute of Building Science
(NIBS) – is tasked with presenting and releasing the MVD to the relevant software
community for implementation. These steps are summarized in Figure Six. The
figure identifies additional activities after implementation, in the deployment box. A
significant one is 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
exported using the use cases specified.
In the research project reported here, in which use cases were defined for the
domain of architectural precast, only the initial steps - 1, 2 and 3 – have been
completed thus far. To date, however, this is one of the most advanced domains,
since no other set of use cases has been fully executed following the NBIMS
procedures. Perhaps the most complete similar definitions, which approximate
aspects of the NBIMS procedures, are the GSA Building Information Modeling Guide
Series: 02 [GSA, 2007].
5. How Use Cases are Defined and Implemented
In North America, use case definition will be undertaken by industry organizations or
25
ad hoc groups with business interests in specific areas of interoperability. A website
is planned to facilitate the structuring of ad hoc groups addressing various use
cases. Interest groups are expected to form around building systems types, such as
structural steel, reinforced concrete, curtainwalls, precast concrete, mechanical
systems, external cladding systems, site work, building control systems, cabinets
and woodwork, etc. Other use cases will define exchanges between architects and
structural engineers, between architects and energy consultants, acousticians,
lighting consultants and other consultants addressing specific design issues. It is the
responsibility of NIBS and BuildingSMART to harmonize the different MVDs
generated so that they are consistent and not duplicative.
The use case groups, with some guidance from NIBS and industry advisors, will
each develop the IDM and MVD addressing their priority use cases. The IDMs will
involve direct involvement of industry specialists, who know the workflows of interest
and the information flows required for IT-level exchange. Industry or university
research groups can advise and document the specification developed. The next
stage, development of MVDs, principally involves funding of IT experts to carry out
the specification process for the relevant 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 vendors with
the user groups. Testing and certification of implementations are also anticipated,
26
although these processes have not yet been published.
6. Interoperability in Architectural Precast
As a pilot project, the use cases for architectural precast identified two alternative
business models requiring slightly different workflows. They were for standard
Design-Bid-Build (D-B-B), and for Design-Build (D-B) or similar collaborative
processes. The overall IDM process is described in Figures Seven and Eight.
The following assumptions can be read from the D-B-B process model in Figure
Seven: (1) there may be early consultation between architect and a precast
contractor, even in a design-bid build procurement process (the precaster consulted
may or may not be the one to whom the work is eventually awarded); (2) at the
contracting stage, arrangement drawings are provided for bidding, with indication of
associated structural members to support the precast façade panels; the general
contractor coordinates the precast contractor’s information flows with the architect;
some technical input may be involved during bidding with the prefabricator’s
structural engineer; (3) the precast contractor’s detailed models are coordinated with
both the architect for intent and with the general contractor (GC) for clash detection
and system coordination; the structural engineer provides connection details to the
precast contractor.
27
FIGURE SEVEN: The IDM process model for Design-Bid-Build for architectural
precast.
These flows are enriched in the D-B, collaborative process shown in Figure Eight,
with: (1) more detailed collaboration between precast contractor and architect
regarding intent; early cost estimation and construction method reviews, possibly
early erection scheduling, early structural review on structural element design and
28
positioning during schematic and development level of the project; (2) continued cost
tracking during bidding; (3) continued structural coordination as fabrication-level
precast detailing is undertaken; continued coordination with architect and GC.
These process maps were developed with input from representative precast
contractors and architects. Significant input came from experimental work on the
Rosewood project, which involved careful monitoring and comparison of data
exchanges using both 2D and 3D representations, carried out prior to the IDM
development [Sacks et al., 2008]. Further review is planned as the IDM to MVD
activities are undertaken.
29
FIGURE EIGHT: The IDM process model for Design-Build and other collaborative
processes for architectural precast.
The two IDM process flows represent best practice today. The D-B process proposes
best practice involving building procurement methods that only recently have been
30
adopted in construction. It incorporates significantly higher levels of exchange, all
along the process, in comparison to D-B-B, greatly enhancing collaboration. While
many more information exchanges are identified in the D-B process, their contents
often involve the same entity sets as other information exchanges. It is only in a few
special cases where unique information is needed, for example the need for approval
and markup notations in the later reviews.
6. Conclusions
The IFC standard building model schema is a necessary but not a sufficient condition
for achieving full interoperability between building information modeling tools. Unless
the specific contents and level of detail is defined for each exchange type in the wide
variety of construction project workflows, the breadth and flexibility of the IFC
schema leaves room for software vendors to program translators that, while
compliant with the standard, do not result in effective exchanges.
The National BIM Standard approach for resolving the ambiguities of information
exchange is based on ‘use cases’ with precise workflow specifications. The basic
approach has been tested in development of an Information Delivery Manual (IDM)
for the domain of architectural precast concrete, which comprised two detailed
BPMN maps of design-bid-build and design-build processes, tables defining each
use case within the processes, and tables defining the information exchanges that
31
are required for the use cases.
The expected eventual outcome of the architectural precast use case study and
implementation will be a Model View Definition that fully addresses the information
exchange needs between four primary actors: architect, precast contractor, general
contractor and structural engineer, that deal with architectural precast issues. Other
actors, such as rebar and mesh fabricators, concrete mix plants, precast erection
firms, may be addressed in later use case efforts. These use cases will define a set
of MVDs that will identify complete and robust data exchange requirements that can
be implemented by software vendors that support the representation of architectural
precast products. With validation and certification testing, the exchange
implementation of software vendors should be reliable “out of the box” without the
need for testing and debugging, 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 selection from
among the supported use cases for that BIM tool. The National Institute of Building
Science, overseeing the NBIMS effort, has plans to publicly document all use cases.
On the implementer side, the existence of so many functionally distinct use cases
32
leads to the potential need for hundreds of translators. This is not necessary. At the
least, it is expected that many use cases, will overlap at the implementation level and
can be supported by a single set of IFC entities. 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 implementation of IFC expert 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 exchanges do not guarantee success for
exchanges, unless the models are constructed 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 requirements for one use case are consistent, at the model building
level, with others used in the same project. These issues become apparent when the
BIM application’s user guides are examined for compatibility. These are second
order issues that domain interest groups will have to address.
Acknowledgment
The research reported in this paper was funded by the Charles Pankow Foundation.
Advisory support was also provided by FIATECH and the National Institute of
Building Sciences.
33
References
BPMI.org (2004) Business Process Modeling Notation (BPMN) Version 1.0.
http://www.bpmn.org/
Braid, I.C. (1975) The Synthesis of Solids Bounded by Many Faces,
Communications of the ACM, Vol. 18, No. 4, pp. 209-216.
Crowley, A.J. and Watson, A.S. (1997) Representing Engineering Information for
Constructional Steelwork, Computer-Aided Civil and Infrastructure Engineering,
12(1) 69-81.
Crowley, A.J. and Watson, A.S. (2000) CIMsteel Integration Standards Release 2:
Overview, Steel Construction Institute.
Duvall, M. and Bartholomew, D. (2007) PLM: Boeing's Dream, Airbus' Nightmare,
Baseline: The Project Management Center, February 5, 2007
Eastman, C., Wang, F., You, S.-J. and Yang, D. (2005) Deployment of an AEC
Industry Sector Product Model, Computer-Aided Design, Vol. 37, No. 11, pp. 1214–
1228.
34
Eastman, C. (1999) Building Product Models: Computer environments supporting
design and construction, CRC Press.
Eastman, C., Teicholz, P., Sacks, R. and Liston, K. (2008) BIM Handbook: A Guide
to Building Information Modeling for Owners, Managers, Designers, Engineers and
Contractors, John Wiley & Sons, Inc., New Jersey.
ENR (2002) Owners' Risk-Shifting Boosts CM-at-Risk Firms,
http://www.construction.com/NewsCenter/Headlines/ENR/20020617e.asp
Froese, T.M. (1996) Models of Construction Process Information. ASCE Computing
in Civil Engineering, Vol. 10, No. 3, pp. 183-193.
Garcia-Alonso, A.M., Serrano, N. and Flaqueer, J. (1994) Solving the collision
detection problem, IEEE Computer Graphics and Applications, Vol. 14, No. 3, pp. 36-
43.
GSA (2007) GSA Building Information Modeling Guide Series: 02 – GSA BIM Guide
for Spatial Program Validation, available at: http://www.gsa.gov/bim/
Hietanen, J. (2006) Information Delivery Manual Guide to Components and
35
Development Methods, BuildingSMART, Norway, 28 March, 2006.
IAI (2007) IFC/ifcXML Specifications, http://www.iai-international.org.
Jeong, Y.-S., Eastman, C.M., Sacks, R. and Kaner, I. (2008) Benchmark Tests of
Neutral Data Exchanges for Precast Concrete. (working draft)
ISO TC184/SC4 (1994) Industrial automation systems and integration -- Product
data representation and exchange -- Part 11: Description methods: The EXPRESS
language reference manual, ISO Central Secretariat.
ISO TC184/SC4 (1998) Guidelines for the Development and Approval of STEP
Application Protocols, NIST SC4 Secretariat.
Light, R and Gossard D. (1982) Modification of geometric models through variational
geometry, Computer-Aided Design, Vol. 14, No. 4, pp. 209-214.
Lipman, R. (2006) CIS/2 and IFC for Structural Steel, Building SMART Day,
Washington DC, Nov. 1, 2006.
NIBS (2007) United States National Building Information Modeling Standard Version
1 - Part 1: Overview, Principles, and Methodologies.
36
Omniclass, (nd), http://www.omniclass.org/
Owen, J. (1993) STEP an Introduction, Information Geometers Ltd.
Pratt, M. (1993) Geometric Methods for Computer-Aided Design, in Piegl L, editor,
Fundamental Developments of Computer-Aided Geometric Modeling, Academic
Press, 1993.
Pratt, M. (2004) Extension of ISO 10303, the STEP Standard for the Exchange of
Procedural Shape Models, Proc. Shape Modeling International 2004 (SMI’04) IEEE.
Sacks, R., Kaner, I., Eastman, C. and Jeong, Y.-S. (2008) The Rosewood
Experiment – Building Information Modeling and Interoperability for Architectural
Precast Facades, Automation in Construction (in press).