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).