Specifying parametric building object behavior (BOB) …big.yonsei.ac.kr/pdf/Publications_Patents/1....

lsevier.com/locate/autcon

Automation in Construction

Specifying parametric building object behavior (BOB) for a building

information modeling system

Ghang Lee a,*, Rafael Sacks b, Charles M. Eastman a

a Georgia Institute of Technology, Atlanta, GA, USAb Technion-Israel Institute of Technology, Haifa, Israel

Accepted 28 September 2005

Abstract

Parametric modeling has been proposed as an effective means to embed domain expertise in models of buildings. As information technology

becomes more powerful in terms of the ability to manipulate large parametric models, the potential grows to build increasingly sophisticated

functional systems for designing, modeling and fabricating buildings. Implementing more powerful systems implies greater functional

specificity, which requires elicitation and capture of increasingly detailed and complex domain-specific semantics and knowledge. This paper

explores the extent to which design and engineering knowledge can be practically embedded in production software for building information

modeling (BIM). It focuses on a building object behavior (BOB) description notation and method, developed as a shorthand protocol for

designing, validating and sharing the design intent of parametric objects. Examples are drawn from an advanced BIM system development

project for precast concrete.

D 2005 Elsevier B.V. All rights reserved.

Keywords: Parametric modeling; Building object behavior; Expert knowledge

1. Introduction

The term ‘‘building information modeling (BIM)’’ was

recently coined to distinguish the next generation of informa-

tion technology (IT) and computer-aided design (CAD) for

buildings from traditional CADD (computer-aided drafting and

design), which focused on drawing production. In this paper,

we use CAD as a generic term to represent the concept initially

conceived by Steven Coons and Ivan Sutherland—‘‘a design

approach that can maximize the creativity and economic

benefits using the computing power’’ [12,56]. BIM is the

‘‘process’’ of generating and managing building information in

an interoperable and reusable way. A BIM system is a system or

a set of systems that ‘‘enables’’ users to integrate and reuse

building information and domain knowledge through the

lifecycle of a building. Among various types of BIM enabling

systems (e.g., enterprise resource planning systems, energy

analysis packages, etc.), 3D knowledge-rich parametric mod-

0926-5805/$ - see front matter D 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.autcon.2005.09.009

* Corresponding author.

E-mail address: [email protected] (G. Lee).

eling systems are central to BIM and in the lifecycle of building

information. The several main reasons are as follows:

& A building is composed of geometric components and the

geometric information is substantial for BIM.

& Parametric modeling provides mechanisms to translate and

embed domain expertise as explicit geometric expressions

that can automate generation of the building information—

especially geometric information, and that can facilitate the

generation of a rich building model.

& Maintenance of the validity of information generated is

crucial for revision and reuse of building information. The

semantic integrity of a building model can be maintained

based on the imposed geometric constraints and rules, as a

building model is being revised [51].

An extensive body of research proposes that such advanced

design and engineering systems be object-based, use three-

dimensional solid geometry, have knowledge-based routines

and employ an integrated (centralized or federated) data

repository [1,3,5,14,16,17,22,30,53]. In the architecture, engi-

neering and construction (AEC) area, examples of 3D knowl-

15 (2006) 758 – 776

www.e

G. Lee et al. / Automation in Construction 15 (2006) 758–776 759

edge-rich parametric modeling systems include ArchiCAD,

Bentley Architecture and Structure, Revit Building and Revit

Structure, Tekla Structures, Digital Project (CATIA-based) and

StructureWorks (Solidworks-based). This paper focuses on a

specific aspect of BIM–how to specify and embed design and

engineering knowledge and intent in a parametric modeling

system as building object behaviors–and introduces a notation

developed for helping domain experts capture and describe their

domain knowledge as parametric building object behavior.

Domain knowledge (or domain expertise) includes a broad

range of issues. In architecture, engineering and construction

(AEC), the examples include principles based on material and

fabrication properties, safety factors, available production

machinery, good design practice, aesthetics, generative rules,

construction sequences, non-geometric properties of building

objects, etc. Many, although not all, are expressed geometrically

and embedded in the final building design. Such geometrically

interpreted domain knowledge can be embedded in a parametric

modeling system as geometric rules or constraints.

Embedding domain expertise requires that parametric

modeling systems have domain-specific objects and that those

objects display intelligent behavior that is particular to their

application domain. By behavior, building object behavior

(BOB) and intelligence, we mean:

& behavior: the ability of an object to respond to internal or

external stimuli (i.e., change its form in response to changes

in its context). Notice that this is a different form of behavior

than is considered in ‘‘structure–function–behavior’’ (SFB)

[4,10,11,24] approaches to design.

& building object behavior (BOB): the behavior of a building

object (e.g., beams, columns, walls) or assembly (e.g.,

floors, stairwells, facades).

& intelligence: the property of a parametric modeling system

that measures the degree to which its objects’ behavior

mimics the logical design intent consistent with domain-

specific expertise, or ‘‘the ability (of a parametric modeling

system) to respond to stimuli according to specific expertise

[19]’’.

For example, parametric modeling systems for building

systems provide building objects such as walls, beams,

columns and spaces; similarly, comparable systems for

mechanical engineering provide mechanical objects, such as

bolts, nuts, pipes and valves. Not only are the objects different,

but the functionality needed for manipulating them is also

different: building design requires functional intelligence such

as walls that are automatically embedded by doors and

windows, beams that require supports, reinforcement that must

be contained within concrete elements, etc.; mechanical design

requires unfolding sheet metal ducts, piping systems that

maintain connection integrity, etc.

Since 2001, the authors have worked with the North

American precast concrete industry (in the Precast Concrete

Software Consortium PCSC project [46]), which aimed to

develop a 3D parametric modeling system that could automate

the precast concrete detailing and engineering process.

Although 3D parametric modeling systems existed for struc-

tural steel construction, the needs of precast construction are

quite different. Steel design relies on standard profiles available

from multiple plants; precast concrete piece geometries differ

by project and by company. Unlike steel structure members,

precast concrete pieces have nested objects such as rebar

reinforcing, prestress strands and other embeds. This increases

the number of possible combinations of detailing options

geometrically, negating any possibility of a-priori hard-coding

of design detailing options. Enabling users to create custom-

ized components and to define their detailing rules using

parametric objects and constraints was essential. In the PCSC

project, a library of broadly applicable parametric objects and

connections was identified as the only way to provide the

desired levels of productivity. However, the depth of domain

knowledge required, the range of permutations with which

different member companies used precast pieces and connec-

tions, and the multitude of sources of that knowledge, made it

essential to develop efficient and effective methods for

collaboration in defining design intent. The result was the

‘‘building object behavior (BOB) notation and description’’

method, which is intended to help domain experts define their

knowledge and design intent as parametric definitions and

geometric behaviors for a parametric modeling system.

The BOB notation is a shorthand script and a protocol for

describing parametric definitions and behavior of building

objects in a sharable and reusable format. Although parametric

modeling is an effective, extensible and flexible means to

embed expert knowledge and domain semantics in a parametric

modeling system, parametric modeling is not easy. Some

parametric models with simple geometry and simple parametric

behavior (e.g., simple parametric doors or windows without

frame details) can be built without a carefully pre-planned

parametric modeling process. But parametric models of many

building sub-assemblies (e.g., steel/precast concrete connec-

tions and curved facade panels) often require over a hundred

parameters and parametric relations between them (several

examples are provided in Section 3). Embedding expert

knowledge in large and complex parametric modeling systems

for building projects demands a well thought-out and formal

way to design and model parametric building objects,

especially when the parametric objects are built to be shared

and used by multiple parties.

This paper first briefly reviews the history and character-

istics of parametric modeling and discusses the limitations and

difficulties of parametric modeling. It then introduces a

building object behavior (BOB) notation and description

method and illustrates several examples. While the examples

are drawn from a collaborative parametric precast-concrete-

connection modeling project, application of the proposed

notation need not be limited to collaborative projects or to

precast concrete details.

2. Parametric modeling as a knowledge embedding method

Various ways of embedding domain expertise into design

and engineering systems have been studied [8,9,20,23,40,42–

G. Lee et al. / Automation in Construction 15 (2006) 758–776760

44,52]. However, until parametric and feature-based modeling

technology became available, traditional CAD systems were

very restricted in the ways in which they could implement

design intent. The initial strategies used both in academia and

in industry were restricted to:

& development of local stand-alone CAD systems with hard-

coded knowledge

& customization of existing CAD systems or automation of

routines through an application programming interface

(API) (e.g., add-ons, plug-ins, macros)

& development of separate knowledge management and

design data processing systems, linked to CAD systems

for visualization, design coordination, enterprise resource

planning, etc.

Parametric modeling was initially developed as a ‘‘solution

for reuse of existing designs [55]’’. The early solution was to

add an explicit ‘‘dimension’’ object as a ‘‘user-defined

parameter’’ and also as a ‘‘geometric constraint’’ at the same

time [25–27,37,38,48]. Such early solutions were not called

parametric modeling when they were first introduced, but

rather dimension-driven modeling. The early CAD tools that

incorporated features similar to dimension-driven modeling

included PADL-1 [48], Kimura’s GEOMAP-III in 1986 [55]

and MCAE [26]. Through these studies and efforts, the role of

parameters in geometric modeling (i.e., constraining geometry)

became emphasized beyond its literal definition. Parameteri-

zation became understood as ‘‘the imposition of constrained

relationships on the shape of objects [29]’’ rather than as

simply ‘‘defining parameters’’. One of the earliest papers

associating dimension-driven modeling and parametric model-

ing across assemblies was Eastman’s ‘‘Design of Assemblies’’

[15]. Another was Roller’s ‘‘An Approach to Computer-Aided

Parametric Design’’ [49].

Over time, the definition and functions of parametric

modeling have been expanded and elaborated. Numerical

equations (e.g., ACIS’ LAWS feature [13]) and declarative

expressions (e.g., parallel, horizontal and coincidental) as well

as nominal values can be assigned to parameters to define

relations between any two different geometric entities. Exam-

ples of standard geometric constraints for parametric modeling

can be found in [6]. ProEngineerR is generally accepted as the

first commercial parametric CAD system [28,55].

Parametric modeling should not be confused with the

computer graphics concept of geometric equation parameteri-

zation (e.g., Bezier Curve, B-spline, parametric surfaces).

Equation parameterization is a method of mathematically

defining geometric surfaces and operations (see Chapter 11

of [21] for examples).

Parametric modeling can be implemented in various ways.

Parameters and geometric constraints can be evaluated

simultaneously or procedurally. At an implementation level,

the former is called variant modeling and the latter is called

parametric modeling (see Chapters 5.2 and 8 of [55] for

details). However, by introduction of various hybrid methods

and expanded use of the term ‘‘parametric modeling’’ both in

industry and academia, the distinction between parametric and

variant modeling has been blurred [2,41,55].

Some existing systems (e.g., 3D VizR, Form-ZR) providepre-defined parametric objects. A new instance of an object

can be created through a user-interface by assigning new values

to a set of pre-defined parameters. For example, a system can

have a pre-built staircase object with many parameters, and

users can create a new staircase design by assigning new values

to the parameters of the pre-built staircase object. However, in

those systems, users cannot create new parametric objects with

attributes and parameters of their choice unless the objects are

created through an application programming interface (API)

and supported by the underlying object model. Most CAD

systems today have such pre-built objects and APIs, but not all

of them are categorized as parametric modeling systems. In this

paper, we do not regard CAD systems with only pre-

programmed parametric objects as parametric modeling sys-

tems. The following characteristics distinguish parametric

modeling systems from other existing CAD systems and

provide mechanisms to translate domain expertise into geo-

metric expressions:

(1) Users can create shapes and define and add new

parametric relations and constraints to geometric

objects through the user interface. The created shape

can be manipulated by changing the values and relations

of the user-defined parameters.

(2) Users can impose constraints between different paramet-

ric objects (e.g., a wall and a window) in the system.

(3) Parameters in objects are exposed, so that a parameter in

one object can be used to derive the parameters in other

spatially related objects.

(4) Imposed constraints should be automatically maintained.

Shape instances are modified not only by direct change

of explicit parameter values, but also by system

maintenance of parametric constraints. In many CAD

systems, users can create geometry using generational

rules (e.g., draw a perpendicular line by imposing a

Fperpendicular_ constraint between two lines), but the

constraint is not maintained (e.g., when either of the lines

were edited). Those systems cannot be considered

parametric modeling CAD systems because they do not

maintain the constraint.

(5) It should be a 3D solid modeler. 2D shapes, 3D surfaces

and 3D solids are all often required to be managed by

parametric rules in building design and construction.

(6) It should be object- and feature-based (note that we

distinguish ‘‘object-based modeling’’ from ‘‘object-ori-

ented programming’’). Users can group and define

geometric objects (and assemblies) and also partial

shapes called features, and can describe semantic

relations (dependencies and variations) between them.

These characteristics of parametric modeling have made the

paradigm attractive to many researchers and numerous efforts

have been devoted both by industry and academia to improving

parametric modeling technology [2,6,28,36,41,42,47,50,53].

8

A

B

C

D

E

F

G

Reaming Boring Drilling

Drilling

Tapping

Counter Sink

Boring

1

4 3 2

5

7

Fig. 1. Reproduction of a state transition diagram for sequencing a machining procedure [45].

Fig. 2. A beam and a double tee.


Some studies have been conducted in translating and imple-

menting expert knowledge in parametric modeling systems in

the form of geometric constraints [6,7,36]; however, the focus

of most studies has been primarily on representing, solving and

optimizing geometric constraints rather than on capturing and

describing domain knowledge in the form of explicit geometric

relations in the first place.

One of the rare studies in capturing domain knowledge in a

form of explicit geometric relation in the early modeling stage

is [45]. Sang K. Park [45] proposed a method to represent a

process plan for hole-making in mechanical engineering using

a state transition diagram (Fig. 1) based on a three-phase

modeling methodology consisting of an object model, a

functional model and a dynamic model. The method is suitable

for describing a procedure of applying various features in

creating a complex shape. However, it is insufficient to

describe complex building-object behaviors, which yield

different reactions depending on the prevailing conditions.

3. Limitations and difficulties of parametric modeling

Parametric modeling is a powerful method to model

intelligent objects and their intended design behaviors.

However, capturing and embedding tacit knowledge in

parametric models requires a careful and well thought-out

modeling plan because of the ambiguity and complexity of

parametric modeling.

First, parametric modeling is ambiguous: i.e., it can be

implemented in various ways depending on design intent. By

ambiguity, we refer to a condition similar to the ambiguity

inherent in constructive solid geometry (CSG): i.e., there are

usually multiple ways to generate a CSG model; in parametric

modeling, there is usually more than one way to implement the

same building object behavior (BOB) pattern. In such cases,

one way of selecting one set over the others is to compare the

computational efficiency. Another way of selecting one set

over the others is to consider other design criteria. Depending

on additional design intent, one will be more appropriate than

the others.

Another hindrance that makes parametric modeling difficult

is its complexity. When multiple sets of object-behavior

patterns are considered, the number and the complexity of

parameters and geometric constraints grows exponentially. For

example, Fig. 2 shows a precast concrete floor panel called a

double-tee connected to a beam using a pocket-type connec-

tion. An expected behavior pattern of the connection is that the

pockets in the beam should be adjusted to the locations and the

sizes of the stems (the bottom part of a double-tee). When the

stems are too deep for the beam, they are Fdapped_ (cut back)over part of their height, leaving only the undapped parts to rest

in the pockets.

In order to define a pocket on a beam, at least five parameters

are required: i.e., pocket_depth, pocket_width, pocket_height,

horizontal_location and vertical_location (Fig. 3) (assuming the

beam and double-tees are horizontal—if not, a rotation would

also be necessary). However, pocket width, depth, height and

location are usually defined not by absolute values as illustrated

in Fig. 3, but by relative values defined by load conditions, the

shear strengths of the beam and of the stems, local shear

strength below the pocket, the angle of the stem and so on. The

number of independent parameters can be very large.

Fig. 3. Parameters of a pocket on a beam.


Fig. 4 illustrates a more elaborate example. Fig. 4a shows a

typical connection between a precast column and a beam. All

the components (pockets, bolts, nuts, joints, the haunch and the

bearing pads) are designed to automatically adjust to any

Fig. 4. A parametric connect

change to the beam or column cross-sections, orientations or

locations. Even this relatively simple geometric shape requires

more than 160 parameters and relations between its constituent

objects to maintain semantic integrity when adjacent objects

are modified (Fig. 4b). (These parameters were defined by the

engineering domain experts.)

Another issue, that of performance (or computational

efficiency), is directly related to the complexity issue briefly

mentioned above. Selection among different strategies that

achieve the same results is influenced by consideration of the

efficiency of the regeneration process. With large numbers of

parameters, there is no one ‘‘right answer’’ (the ambiguity of

parametric modeling) and so parametric modeling becomes a

technical skill in its own right.

Anderl and Mendgen [2] found similar results from their test

cases. They provided examples of a parametrically designed

gearbox, which could vary by torque and transmission ratio,

and of a mechanical shaft with integrated dimensioning

ion with 165 parameters.

Capture object behavior

Optimize parameters andgeometric constraints

Does thecreated

parametricobjectbehave

correctly?

invalid

Valid

• Knowledge ElicitationPhase (PreliminaryDesign Phase)

• Implementation Phase

• Validation Phase

Interprete object behavior interms of geometric relations

Define parameters andrelations between them.

• Design Phase

Implement parameters andrelations between them.

feedback

Fig. 5. A parametric object design process.


calculations driven by forces, torques and bending moments.

The gearbox was composed of 665 features, 1363 parameters

and 1291 geometric constrains between features. The me-

chanical shaft included 80 features, 1217 parameters and 412

geometric constraints. These test cases showed that the

overwhelming number and complexity of parameters and

geometric constraints often crashed a model when the

modeler modified or removed a parameter improperly and

eventually made it practically impossible to modify a

parametric model in a real project, which negated the primary

goal (i.e., reuse of data) of parametric modeling. Such

performance issues may eventually be overcome in the long

run as the computing power of machines increases, but the

cognitive burden to manage the complexity of a parametric

model will remain. Also, the ambiguity of parametric models

will be an obstacle to sharing of parametric models by

different users. Considering both the complexity and the

ambiguity of parametric objects and the potential need to

communicate and assess their behavior, a method to rapidly

and abstractly capture and represent such behaviors and to

pre-tune and guide parametric object design would be a

valuable contribution.

In order to help users manage parameters more easily, some

systems provide graphic user interfaces, which can show a

matrix of parameters and constraints between features, parts

and assemblies. Also, several strategies for optimizing

parameters and geometric constraints have been proposed

[2,36]. However, parametric modeling still requires an

algorithmic and mathematical thinking (or programming)

process even though it does not require hard-coding. To date,

proposed interfaces and methods focus mostly on the

implementation phase, and little focus has been given to

description methods of parametric object behavior in the

knowledge elicitation phase and the early parametric model

design phase. For small parametric modeling exercises, it may

not be necessary to have any means to pre-tune or guide the

implementation of parametric behavior. However, for relative-

ly large and complex parametric modeling activities (espe-

cially when they are collaborative ones), it is critical to have a

formal way to communicate, design and model parametric

objects.

4. A formal parametric modeling process and the BOB

notation

In this section, we propose to formalize a parametric

modeling process with four phases (Fig. 5): the knowledge

elicitation phase, the design phase, the implementation phase

and the (design) validation phase.

In the knowledge elicitation phase, modelers should clarify

design intent and identify expected object behavior. The

identified object behavior in this phase is a description based

on domain expertise and should be used as a guideline for

verifying an implemented parametric object and its behavior in

the validation phase. In this phase, the expected object behavior

can be described declaratively and does not need to be

expressed in terms of parameters and geometric constraints:

e.g., the doors of a public building should open to the outside

(to enable rapid egress in case of fire); the nuts on different

sides of a bicycle wheel should be threaded in opposite

directions both in the bicycle’s moving direction (so that they

do not loosen when the bicycle stops).

In the design phase, modelers express object behavior in

terms of explicit parameters and geometric constraints. The

resulting parametric objects will often be hierarchical assem-

blies, with a main object controlling the geometry of

constituent objects. The assembly may be self-contained

(i.e., all of the relationships are internal, with the overall

geometry driving the geometry of constituent objects), or they

may be dependent on (one or more) other objects (such as a

window inserted in a wall adjusting to the thickness of the

wall). Parametric relations basically act as constraints on a

model and control the degree of freedom of models.

Parametric models may be under-, fully or over-defined. For

example, when the minimum number of dimensions required

for fully defining a shape is provided, the state of the shape is

called fully defined.

In the implementation phase, the translated object behavior

is implemented in a CAD system as a parametric model. If a

CAD system provides a good design interface, the design phase

and the implementation phase can be done iteratively.

In the validation phase, the implemented parameters and

geometric constraints should be checked against the descrip-

tions of initial design intent and should be optimized. The

semantic validity of a model can only be judged by domain

expertise. Incorrect (or Fabsurd_) design situations are obvious

to a human viewer, but are amorphous and thus very difficult to

identify algorithmically. For example, if the distance between a

window and the edge of a wall (D1 in Fig. 6) exceeds a certain

Fig. 6. A nonsensical window location.


limit and, as a result, the window protrudes beyond the end of

the wall (Fig. 6b), it may not be a valid design. However, a

system may not be able to automatically interpret design intent

and anticipate such a ‘‘design yield point’’ based on the limited

input.

The building object behavior (BOB) notation is proposed to

support these four parametric phases. Earlier, we claimed that

it is critical to have an easily deployable method to describe

and document design intent of parametric models especially

when parametric models are intended to be shared between

different parties. In the course of preparing parametric models

of connections (Fig. 7) in the PCSC project, it became clear

that modelers had great difficulty in defining the behavior

required, in communicating the behavior to their peers and to

modeling experts and in documenting the resulting parametric

connections that were created. Simple textual descriptions or

labels for parameters were insufficient tools for describing the

complex behaviors. As a result, the authors identified the need

Fig. 7. Various types

for a common and formal textual and graphic notation that

could:

& represent complex building object behavior for detailed

requirements specification,

& enable domain experts from different locations and practices

to collaborate in defining parametric modeling objects,

& facilitate use of the resulting user-defined parametric

objects by other users by providing clear and concise

documentation,

& support the design, implementation and validation phases of

parametric modeling.

The building object behavior (BOB) notation was developed

in response to these needs. It enables modelers to define a set of

parameters and the relationships that define a building object

and its behavior. It is essentially a graphical shorthand for

sharing the descriptions among different writers and readers.

The next section specifies the BOB notation.

5. Specification of building object behaviors

The BOB notation describes object behavior as a set of pairs

of causes (stimuli) and corresponding results (reactions). In this

sense, BOB notation clauses have a dichotomy similar to that

of if– then clauses in computer programming. In addition, BOB

can be also used to describe the default (or initial) state of a

parametric object with part names, parameters, their default

values and relations with other neighboring parts.

BOB notation can be described in 2D or 3D. 2D

representations often reduce the complexity of a representation,

but either 2D or 3D representations, whichever are more

of connections.

B

A

Column C1 Column C2Beam B1

(a) Room A and Room B (b) Two columns and one beam

Fig. 8. Labeling shapes.


intelligible, can be used. At a very fundamental level, the BOB

notation allows the definition of relations between any

geometric entity in Euclidean geometry including:

– point

– line

– surface

Each shape can be labeled as a real-world object (e.g., a

room, a wall, a column and so on) with a unique identifier

(Fig. 8).

The notation follows the conventions of engineering

drawing. For example, a dotted line represents hidden edges

or guidelines (Table 1, Fig. 9). A cut, a gap or tolerance

between objects can be represented by hatches. A thin line and

a thick line respectively represent an inner edge and a boundary

of an object (the definition of Fthin_ and Fthick_ is relative

within any diagram).

The efficiency and the clarity of describing design intent are

critical criteria in the BOB notation, but the accuracy of a

representation is less a concern. The intent of the sketch is to

depict relevant topology. For example, one may intend to draw

a cube, but the cube need not be ‘‘accurately’’ drawn (i.e., the

height, width and depth may not be the same), provided that

readers can understand that the shape represents a cube by a

label or other cues.

In addition to basic symbols for representing a shape, the

BOB notation includes symbols to represent design behavior of

able 1

ines

ymbol Description Usage

A dotted line Hidden lines, guidelines

A thin line Inner edges

A thick line Boundaries

A dashed line A trace of previous shape

Hatches A cut, a gap, space or tolerance between objects

A

a 3D View of Object A

a bottom View of Object A

A

A

enlarged object A

A

B

A

chamfered object A

a gab between objects A and B

Fig. 9. Examples of using lines.

T

L

S

building objects. Pivot and connection points represent an axis

(point) of a rotation in 2D and 3D (Table 2). A pivot point

represents a rotation axis (line) of a single object whereas a

connection point represents a connection axis or point between

at least two objects.

The BOB notation includes three primitive types of object

behavior: namely FIX, ROTATE, TRANSLATE and RE-

SHAPE.

– FIX: fixes the position of a geometric element or a shape.

Fixed shapes or elements cannot be moved or changed.

– ROTATE: changes the angle of a building object along an

axis.

– TRANSLATE: changes the position of a building object.

– RESHAPE: changes the shape of an object. It includes

skew, scale (expand, shrink), chamfer, fillet, warp and

more.

There are two types of arrows to represent such dynamics of

objects: rotational and directional arrows (Table 3). Rotational

arrows represent the direction and the degree of rotation of an

object. Directional arrows represent the direction and the

distance of translation of an object. Dimensions and the

following constraint descriptors (declarative geometric con-

straints) can be used together with arrows to describe object

behavior:

Max; Min; > ; < ; ¼ ; þ ; � ; =; 4; ; AND; OR

See Appendix B for other possible geometric constraints.

Table 2

Pivot and connection points

2D symbol 3D symbol Name Usage

(top)

(side)

Pivot

point

A pivot line for rotating

an object: a pivot point

can be placed only on a

single object or on a single

object and a reference

geometry.

(top)

(side)

Connection

point

A connection point between

objects, with reference to

intersection of principle axes

of each object: a connection

point must be placed

between at least two objects.

40 Deg

A

(a) Rotate Object A counter-clockwise about a pivot point.

A

B

(b) Rotate B 40 degree either CCW orCW from parallel.

ABMax 4"

(c) Object A can be translated to theright 4" at maximum from current

location

Fig. 10. Examples of using several BOB symbols.


Fig. 10 illustrates examples of object behavior described

using a pivot point, a connection point and constraint

descriptors.

Fig. 11 shows several other declarative geometric con-

straints defined in the BOB notation (Fig. 11), although they

are neither the minimal set nor the complete set of possible

geometric constraints. (See Betting and Shah’s paper [6] for a

standard set of geometric constraints.)

The normal constraint in Fig. 11 restricts an angle between

two lines (or surfaces) to a right angle. However, the normal

constraint can be viewed as a special case of the angular

constraint, whose angle is restricted to a right angle. The

vertical constraint in Fig. 11 can be viewed as a special case of

a normal constraint, which restricts either one of two lines

(surfaces) to an axis of a coordinate system (e.g., the X-axis of

the XY plane). The main goal of this set of declarative

constraints is to provide a rich and intuitive way to express

geometric constraints, not to provide a minimal set of

geometric constraints for implementation.

In most cases, it is likely to be too cumbersome and time-

consuming to generate BOB diagrams for every possible

building object behavior. BOB notation is also not intended to

be used as the sole means to define building object behavior.

For example, Table 4 is a summary of a Parametric Object

(Modeling) Planner [39], which can be used as a template for

defining parametric object behavior. It was developed during

the PCSC project and was used in developing parametric

connection objects. A partial example of a Parametric Object

Planner is provided in Table 5 in the next section.

The BOB notation has been experimented with in two

parametric modeling projects: parametric connection modeling

Table 3

Arrows: rotational and directional changes

Rotational arrows Directional arrows

Unidirectional change

Bidirectional change

Counter clock wise rotation

Clock wise rotation

Free rotation

Unidirectional change

and parametric stairwell specification (see Section 6 for

examples). The experience gained suggests that its use would

be more effective if it were implemented in a software tool that

could translate its diagrams directly into constraints between

objects in a CAD system.

6. PCSC implementation examples

The parametric modeling process (proposed in Section 4)

and the BOB notation (described in Section 5) were developed

and used in the PCSC project, which aimed to develop a

knowledge-rich parametric BIM system for the North Amer-

ican precast concrete industry [18,53]. The project team

consists of a consortium (a.k.a. the PCSC) of 15 major precast

concrete producers and 17 engineering consultant companies in

North America. The authors were the technical advisors of this

project.

In order to understand and capture the possible use cases,

domain semantics and objects, and the other requirements for

the targeted BIM system, a new process modeling method to

capture information flow and detailed functional requirements

was developed and deployed before the parametric modeling

activity began. The method is called GTPPM [31,34,35].

Based on 14 GTPPM models produced by precast concrete

companies, a request for proposal (RFP) with high-level

functional requirements was developed. Twelve CAD vendors

from all over the world responded to the proposal; after a

thorough evaluation process, Tekla StructuresR (previously

known as Xsteel) was selected to serve as the base system

platform. The RFP was then elaborated and expanded to 31

detailed requirement specification documents through an

alignment constraint =

equal spacing, evendistribution, equaldimension

A

horizontal constraintH V vertical constraint

parallel constraint normal constraint

conincidental constraint

P

C* colinear constraint

Fig. 11. More declarative geometric constraints.

Table 4

The parametric object (modeling) planner

Section Items

1. Identification Object name

Version number

Modeled by

Affiliation

First created date

Last modified date

2. Object definition Description (brief description)

Neighboring objects

Planned use (initial goals for functionality)

Known limitations/rules

3. Parameters Index number

Variable name

Label/variable in dialog box

Abbreviation

Default value

Visibility (show/hide)

Descriptor

Comments

4. BOB descriptions Stimuli

Behavior


intensive domain knowledge capturing and specification

process, during which 1655 files (drawings, reports, tables

and BOB diagrams) were collected. Further details on the

platform system selection process and the domain knowledge

specification process are available in several publications

[18,19,33,54].

In this project, user-defined parametric objects were built in

two ways—from scratch and from pre-defined abstract objects.

An example of each approach is provided below respectively in

(Figs. 13, 14 and 16). Using the improved parametric modeling

tools and the BOB notation, precast concrete detailers and

engineers have also defined and built parametric object

libraries, which include the most commonly used precast

concrete pieces and connections. Fig. 12 is a screenshot of the

Connection Libraries section of the PCSC website, where the

Table 5

An example of the object definition section of the parametric object planner

Object definitionDescription ( brief description of connection ) : dowel splice connection utilizing (2) 24” grout

Neighboring objects: ( up to 10 secondary parts allowed )

Main part (type) Secondary part 1 Secondary part 2

Top of lite wall Horizontal lite wall

Lite wall (upper) Lite wall (lower)

Shear wall (upper) Shear wall (lower)

Planned use (initial goals for functionality):1. Create (2) 6”x6” shims with parametric thickness depending on joint size, a2. Simple (2) #7 dowel splice connections that can be moved distances from th

within the grout tube shall also move with each individual splice. In this caconnection is engineered.

Known limitations/rules:Detailing (industry usage):

1. The top piece must be chosen as the main part. Lower piece as 2. Thickness of the pieces is irrelevant, as long as the user change

3. The main part can be as tall as it wants to, but the secondary pa

PCSC members post and share parametric connections and

their Parametric Object Planners described at the end of

Section 5. Table 5 is an example of the Object Definition

section of the Parametric Object Planner specified for wall-to-

wall array connection shown in Fig. 7(b).

Fig. 13 illustrates the behavior of a wall-to-wall array

connection. A connection connects two or more concrete

pieces. The geometric properties of a connection are defined by

the relationship between the connected pieces and the

connection. In order to enable users to build such parametric

connections, a system must support the second and the third

parametric modeling capabilities described in Section 2—the

capabilities to define the parametric relations between

different objects and to use parameters in other objects. For

example, a wall-to-wall array connection connects two walls

vertically.

On each end of a wall-to-wall array connection, there is a

pad, whose thickness depends (PT in Fig. 13) on the joint

thickness (JT) between the two walls. For accuracy and

efficiency of modeling, it is important to set the default

parameter values to the industry default value if possible. In

case of the end pads (the joint between the two walls, D1

and D2 in Fig. 13), the default thickness is 3/4 inches

(1.905 cm) as illustrated in Fig. 13. When the lengths of

supporting and supported walls increase, the number of

connection points (n) increases. The lengths of the two

connected walls (WL1 and WL2) are usually the same.

However, if only one of the walls is extended, the length of

a shorter wall should be regarded as the length of the

connection array as shown in Fig. 13. There are various

ways to calculate the number of connection points between

the two walls and the distance between the connections. A

common practice is to divide the wall length by the default

spacing between connections (3 ft 4 in., 101.6 cm) and to

distribute the remainder to the spacing between connections

as shown in Fig. 13 or to the distance between the wall end

and the end connection.

tubes, (2) #7 DBSAE, (2) #7 dowel inserts, and (2) 3/4”x6”x6” steel shims.

Secondary part 3 Secondary part 4

llowing for movement from the soffit of the piece and its insertion end.e soffit of the piece as well as distances from its insertion end. The respective cutse, the connection is made up of standard imbeds used only in instances where a #7

the secondary part.s the distance from the soffit to suit.

rt cannot be taller than 7’-3” due to magnetic plane sizes.

Fig. 12. The Connection Library section of the PCSC website.


Fig. 14 illustrates another BOB diagram example—a

Fpocket_ connection, similar to that shown in Figs. 2 and

3, in which the stem of a double tee is Fdapped_ (cut back)

to be inserted into a recess in a spandrel beam. The double

tee may be sloped longitudinally, translated vertically and

rotated laterally (in a parking garage ramp, for example, or

where a bay of double tees in a slab is warped to allow for

drainage) (Fig. 13(a)). The location, orientation and other

geometric properties of the pocket connections are deter-

mined by the shape of the connected double tee slab. For

example, the minimum concrete thickness below the pocket

(D1 in Fig. 14) is restricted by the allowable shear stress on

the concrete section below the pocket (disregarding rein-

forcement) (Fig. 13(b)). If the building geometry requires

that the double tee be moved further down than this limit,

then this connection becomes invalid and should be

replaced by a different type of connection, such as a button

corbel. The two alternatives c.1 and c.2 in Fig. 14(c)

showing lateral rotation respectively show examples of

correct, practical behavior (c.1) and impractical behavior

(c.2); in production, it is difficult and costly to generate a

non-standard pocket shape as shown in alternative c.2. This

BOB example shows the use of parametric constraints

applied to lines, between lines, between points and lines,

and between dimensions, including the use of formulaic

restrictions on dimensions.

Even with a clear guide map, parametric modeling can still

be a very complex and time-consuming activity. In order to

overcome the complexity and effort required for creating user-

defined parametric objects without surrendering its flexibility

and extensibility, the second approach we took was to enable

users to build custom parametric objects from a pre-built

abstract object, which can transfer behavior patterns between

different objects and itself to its instances as well as attributes,

instead of building all of them from scratch [17,33,53]. Figs.

15 and 16 are examples of BOB descriptions used in

development of the parametric stairwell assembly object in

the PCSC project. A stairwell consists of three parametric

staircase objects: the first floor staircase, the typical floor

staircase and the top floor staircase. Each staircase unit is

composed of stairs, landings, wall pieces with openings,

connections between them and reinforcement in them. Each of

them can be replaced with pre-defined or user-defined paramet-

ric objects.

WP1: Primary wall panel (supporting)

WP2: Secondary wall panel (supported)

WWC:Wall-to-

wall arrayconnection

Extended

Extended

Stimulus Behavior

Extend

Extend

JT: J

oint

Thi

ckne

ss

PT

: Pad

Thi

ckne

ss(D

efau

lt: 3 /

4”)

=

D1 (Default: 2") D2(D2 = D1)

S3(S3 = S1)

n: number ofconnection

points

S2: spacing between connections

WL2

S1 S2 S3S2

D2(D2 = D1)

D1 (Default: 2")

=

WP2

WP1

WL: Wall Length

S1(Default: 3'-4")

S2(Default: 3'-4")

Whe

n th

e w

all p

anel

s ar

e ex

tend

ed

IF WL1 >= WL2 THEN WL = WL2IF WL1 < WL2 THEN WL = WL1n = INT((WL - S1 *2) / 3'-4") + 1Adjusted S2 = (WL - S1 *2) / (n -1)

WL1WL1

n

Fig. 13. An example of a wall-to-wall array connection behavior.


Fig. 15 shows parameters, their default values and part

names of a stair. One of the basic behaviors of a stairwell is

floor height change. In order to maintain the validity of a

stairwell, if a floor height changes, either the riser height or the

number of risers (steps) should be updated. However, it is not

common practice in the North American precast industry to

change the riser height because a precast stair piece is usually

produced using a metal stair form, whose riser height can be

changed only within a minor range of tolerance. Thus, in such

cases, the number of steps should be modified. Fig. 17 shows

an incorrectly implemented stairwell object. In Fig. 16, the

correct behavior of a parametric staircase object when the

middle landing is pushed down, or the first stair is dragged to

the right, is illustrated using the BOB notation.

In the above two examples, only one possible behavior of a

parametric object is exemplified. However, an object is

expected to express different behaviors depending on different

circumstances (e.g., different company practices, different

neighboring objects and different construction methods). It is

impractical to embed all possible expected behaviors and

different scenarios in one pre-built or user-defined parametric

object even if they could be exhaustively defined using

multiple BOB diagrams. Sometimes, the different behavior

patterns of the same objects may conflict with one another

depending on the situation. An object with such conflicting

behavior patterns should be developed as two or more separate

parametric objects.

As the demand for highly automated (intelligent) systems

increase in the future, the importance of user-defined paramet-

ric objects will also increase. The BOB notation and

description method can be used as a protocol to design,

validate and share the design intent of parametric objects

between parametric modeling system users, software devel-

opers and domain experts.

7. Summary and discussion

An intelligent CAD system that can generate and provide

consistent and valid information to other systems is a core

enabler of building information modeling. It is expected that

individual companies will embed aspects of the company’s

expertise or intellectual property into such systems. Ad-

vanced parametric modeling technology provides AEC

software users and developers with an effective means to

embed such domain knowledge in a system without hard-

coding.

However, parametric modeling is still challenging and has

limitations. First of all, it is not easy to capture tacit

knowledge and interpret it into explicit geometric and other

relationships, which a system can understand (e.g., numerical

equations or specific declarative expressions). Also, as more

and more design and engineering processes are automated,

the risk of propagating errors increases. A parametric

modeling system will require careful engineering judgment

and responsibilities in setting up the input and reviewing the

output and a method to specify the requirements in an

unambiguous way. Another problem of parametric modeling

is significant performance degradation, which occurs when

large numbers of parameters and geometric constraints are

added to a model. Also, since parametric modeling allows

Fig. 14. An example of pocket connection behavior.


anyone to develop and add parametric objects to a model (or

to a system), it becomes important to have a common

method to describe the design intent in order to share and

reuse the user-defined parametric objects at least within the

same community or between collaborators. There isn’t one

panacea that can completely solve all these parametric

modeling problems. However, such ambiguity, complexity

and incommunicability problems can be reduced to a certain

degree with a clear guide map and a step-by-step modeling

process for translating design and engineering knowledge

Obstacle

Other Parameters

- Number of Steps (usually driven value)- Tread Width (= Flight Width = Stair Width)

Stringer Thickness(Landing Thickness = 8" or 203mm)

(=La

ndin

gT

hick

ness

)

D3(=D1)

D4 (=D2)

Land

ing

Thi

ckne

ss(8

")

D1

D2 Tile space (thickness) can be subtracted from theLanding Thickness afterwards if tiles are added as afinish:cf. See Unistress's staircase details.

*Values in the parenthesis are default values.

Tot

al R

ise

(=H

alf F

loor

Hei

ght)

[Riser Height & Number of StepsCalculation]

RH = Riser HeightNS = Number of StepsHFL = Half Floor Height

RH = 7.5" (or 190mm)NS = Integer( HFL / RH) + 1NewRH = HFL / NS

*The maximum rise: BOCA: 7" (178mm) IBC: 7" (178mm) Industry practice: 7.5" (or 190mm)

subtractedfinish (tile,CIP...) space

1: First Tread

2

3

4

5

6

Total Run: from 1st tread nosing to the lasttread nosing

0

Last Tread Depth orUpper Landing Length(= Tread Depth)

Overall Stair Length

Zero Tread Depth orLower Landing Depth(= Tread Depth)

Ove

rall

Sta

ir H

eigh

t

Hea

droo

m

Fig. 15. Parameters and parts of a precast concrete stair.

1211

109

87

Pushdown

3

2

45

6

This landing is fixed to afloor.

This landing has beenautomaticallygenerated in the middleof a staircase. It is notfixed.

3

2

45

6

1211

109

87

Drag

Stimulus

Behavior

3

2

1211

109

87

65

4

1

3

2

45

6

1 1

If a flight is selected, the selected flight will be highlighted and its control handles (or points) will be shown. If a landing is pushed down or the first stair is dragged,

1) Nothing will happen (or a system will alert users foran illegal action) if the middle landing is fixed to anexisting building structure.2) If the middle landing is free, the number of stairs inthe first flight will be decreased while the number ofstairs in the second flight will be increase to maintainthe floor-to-floor height.3) The landing on the moved side will be decreaseduntil its length reaches its minimum length (= stairwaywidth). The user will then be alerted that the landinghas reached its minimum allowable size. This isespecially necessary where the stairway envelope isfixed. The user would then have the option to: i)return the landing to its original position (orsomewhere in between) or ii) extend the envelopesize (and its components).4) The landing on the other side will be adjusted tosuit, depending on user response i) or ii).1

Fig. 16. An example of staircase behavior.


(a) initial state (b) after changing the floor-to-floor height –Note the change in the riser height.

Fig. 17. An incorrectly implemented parametric staircase.


into explicit geometric rules and embedding them into a

system.

As one possible approach to overcome these problems, this

paper proposes the BOB notation and description method, and

describes how the proposed method can be used in the four

parametric modeling phases with examples drawn from an

industry-wide parametric model library development effort.

The four parametric modeling phases are the knowledge

elicitation phase, the design phase, the implementation phase

and the validation phase. The BOB notation and description

method is proposed as a shorthand script and a protocol for

describing parametric definitions and behavior of building

objects in a sharable and reusable format. Clarity and

efficiency are the two primary criteria of the BOB notation.

Dimensional accuracy and completeness of the diagrams are

less of a concern in the early knowledge elicitation phase

because they can be incrementally elaborated and enhanced

through other parametric modeling phases including the

design phase. The BOB diagrams can be used as a guide

map to implement parametric objects, to build user-defined

parametric models and to check them in the implementation

and validation phases.

The BOB notation is not intended to automate encoding of

object behavior definitions. As such, no attempt has been made

to develop algorithms to automatically translate a set of BOB

diagrams with high-level object behavior definitions (fix,

rotate, translate, reshape, etc.) into a single parametric model

with low-level parametric definitions (equal dimension, angular

constraint, etc.). If this direction were pursued in future

research, then validation rules would be needed to check the

conformity of the resultant models.

While the BOB notation was developed within the domain

of precast concrete construction, it is likely to be useful for

buildings in general and possibly for other industries (albeit

with addition and modification). The role of advanced

parametric modeling systems in BIM is likely to grow in

importance. Clear communication and collaboration between

domain experts, consultants and software developers are

essential for the success of any advanced parametric modeling

system development project. The BOB notation and descrip-

tion method, or similar tools, can play a key role in facilitating

this aspect of BIM development.

Acknowledgement

This work was funded in part by the North American

Precast Concrete Software Consortium (PCSC) under grants

to Georgia Institute of Technology and the Technion-Israel

Institute of Technology. We thank PCSC members, particu-

larly Dave Mahaffy, Skip Wolodkewitsch, David Fiedler,

Amado Malonjao, Chris Carasone, Wayne Kassian and Paul

Smoot, for allowing us to publish their parametric connection

examples. We also thank Tekla Corporation for kindly sharing

examples.

EXAMPLE


Appendix A. Building object behavior (BOB) notation

SYMBOL NAME USAGE

Basic entities

pivot pointconnection point

counter-clock wise rotation

clock wise rotation

free rotation

unidirectional change

bidirectional direction

hidden lines, guidelines

inner edges

boundaries

a trace of previous shape

a cut, a gap tolerance

object identifier

A pivot point of an objectA connection point of objects. Aconnection point must be placed more tha two objects

Rotate Object A counter clock wisealong a pivot point

B40 Deg

Rotate B 40 degree either CCW or CW

Object A can be translated to the right 4”at maximum

a 3D View of Object A

a bottom View of Object A

enlarged object A champered object A

B

(continued on next page)

Max, Min,>, <

tolerance, range descriptors AB

8" Max 2" D = H / 2

The maximum gap betweenobjects A and B is 2".

H

alignment constraintThis symbol can only apply to linearelements (e.g., joints, linear edges ofbuilding objects)

= equal spacing, evendistribution,equal dimension

Constraint descriptors

=,+, - , /, *

^

AND, OR

mathematical operators

logic operators

AB

AB

== =

even distribution

AB

=

AB

another way of definingeven distribution

C

A

BMax 20 Deg

0 Deg < x < 30 Deg

x

A

A

A

horizontal constraintH This symbol denotes an elementhorizontal to the ground.

V vertical constraint This symbol denotes an element verticalto the ground.

parallel constraintThis symbol denotes an element parallelto another element.

normal constraint This symbol denotes an element normalto another element.

P

AV

H

A B

P

A another way of defininga NORAML relation

SYMBOL NAME USAGE EXAMPLE

Appendix A (continued)


Arc / Circle Curve Surface


Appendix B. Other possible geometric constraints

Entity 1 Point Line

Entity 2

Referential points (origin, control points)

Offset Offset ConcentricTangentialoffset

Tangential offset

Offset Centroid

Referential lines (grid lines, axes)

Offset Offset

HorizontalVerticalAngular

Tangential

offset

Tangential

offset

Offset (Parallel)

HorizontalVerticalAngular

Referential planes Offset Offset Tangentialoffset

Offset OffsetNormal

Point Offset Offset ConcentricTangential offset

Concentric offset

Offset Centroid offset

Line OffsetPerpendicularEqual lengthAngular

Tangential offset

Tangential offset

Offset (Parallel)NormalAngular

Arc / Circle ConcentricEqual radius(diameter)Equal angleEqual arclength

Offset (Parallel) Tangential offset

Curve OffsetSurface Offset (Parallel)

PerpendicularAngular

(Parallel)

(Parallel)

References

[1] R. Amor, Misconceptions about integrated project databases, ITcon 6

(2001) 57–68.

[2] R. Anderl, R. Mendgen, Analyzing and optimizing constraint-structures

in complex parametric CAD models, in: B. Bruderlin, D. Roller (Eds.),

Geometric Constraint Solving and Applications, Springer, Berlin,

Germany, 1998, pp. 58–81.

[3] Autodesk, Building Information Modeling, Vol. Volume, Autodesk, Inc.,

San Rafael, CA, 2003, p. 7.

[4] M.E. Balazs, D.C. Brown, The Use of Function, Structure, and Behavior

in Design, in: Workshop on Representing Function in Design, AID-94, AI

in Design Conference (1994).

[5] K. Bentley, B. Workman, Does the Building Industry Really Need to

Start Over? A Response From Bentley to Autodesk’s BIM/Revit

Proposal for the Future, Vol. Volume, Bentley Systems, Incorporated,

2003, p. 10.

[6] B. Bettig, J. Shah, Derivation of a standard set of geometric constraints

for parametric modeling and data exchange, Computer-Aided Design 33

(2001) 17–33.

[7] B. Bruderlin, D. Roller (Eds.), Geometric Constraint Solving and

Applications, Springer, Berlin, Germany, 1998.

[8] G. Carrara, Y.E. Kalay, G. Novembri, Knowledge-based computational

support for architectural design, in: G. Carrara, Y.E. Kalay (Eds.),

Knowledge-Based Computer-Aided Architectural Design, Elsevier, 1994.

[9] S. Caselli, C. Papaconstantinou, K.L. Doty, S.B. Navathe, A structure–

function–control paradigm for knowledge-based modeling of manufac-

turing workcells, Intelligent Manufacturing 3 (1992).

[10] B. Chandrasekaran, Functional representations: a brief historical perspec-

tive, Applied Artificial Intelligence 8 (1994) 173–197.

[11] B. Chandrasekaran, J.R. Josephson, Function in device representation,

Engineering with Computers 16 (2000) 162–177.

[12] S. Coons, An outline of the requirements for a computer-aided design

system, AFIPS Spring Joint Computer Conference, 1963, pp. 299–304.

[13] J. Corney, T. Lim, 3D Modeling with ACIS, Saxe-Corburg, Stirling, UK,

2001.

[14] Cyon Research Corporation, The Building Information Model: A look at

Graphisoft’s Virtual Building Concept, Vol. Volume, Cyon Research

Corporation, Bethesda, MD, 2003, p. 10.

[15] C.M. Eastman, The design of assemblies, Society of Automotive

Engineers (SAE) Conference1981Society of Automotive Engineers,

Inc., Cobo Hall, Detroit, MI, 2004.

[16] C.M. Eastman, T.S. Jeng, A database supporting evolutionary product

model development for design, Automation in Construction 8 (1999)

305–323.

[17] C.M. Eastman, G. Lee, R. Sacks, Development of a knowledge-rich CAD

system for the North American precast concrete industry, in: K. Klinger

(Ed.), Proceedings of the 2003 Annual Conference of the Association for

Computer Aided Design in Architecture (ACADIA 22), Indianapolis, IN,

2003, pp. 208–215.

[18] C.M. Eastman, R. Sacks, G. Lee, The development and implementation

of an advanced IT strategy for the North American precast concrete

industry, ITcon International Journal of IT in Construction 8 (2003)

247–262.

[19] C.M. Eastman, R. Sacks, G. Lee, Functional modeling in parametric

CAD systems, in: O. Akin (Ed.), Generative CAD (G-CAD) conference,

Carnegie Mellon University, Pittsburgh, PA, 2004.

[20] U. Flemming, Case-based design in the SEED system, in: G. Carrara,

Y.E. Kalay (Eds.), Knowledge-Based Computer-Aided Architectural

Design, Elsevier, 1994.

[21] J. Foley, A. van Dam, S. Feiner, J. Hughes, Computer Graphics:

Principles and Practice, Addison Wesley, 1995.

[22] P. Galle, Towards integrated, intelligent, and compliant computer

modeling of buildings, Automation in Construction 4 (1995)

189–211.


[23] J. Gero, A locus for knowledge-based systems in CAAD education, in: M.

McCullough, W. Mitchell, P. Purcell (Eds.), The Electronic Design Studio:

Architectural Knowledge and Media in the Computer Era, MIT Press,

Cambridge, MA, 1990, pp. 49–60.

[24] J. Gero, T. McNeill, An approach to the analysis of design protocols,

Design Studies 19 (1997) 21–61.

[25] A.M. Gopin, Development of a dimension-based data structure for two-

dimensional computer graphics, Master’s thesis, MIT, 1987.

[26] D. Gossard, R. Zuffante, Representing dimensions, tolerances, and

features in MCAE systems, IEEE Computer Graphics and Applications

8 (1988) 51–59.

[27] R.C. Hillyard, I.C. Braid, Analysis of dimensions and tolerances in

computer-aided mechanical design, Computer-Aided Design 10 (1978)

161–166.

[28] C.M. Hoffman, K.-J. Kim, Towards valid parametric CAD models,

Computer-Aided Design 33 (2001) 81–90.

[29] Y. Kalay, Modeling Objects and Environments, John Wiley & Sons, New

York, NY, 1989.

[30] J. Laiserin, The BIM page: building information modeling—the great de-

bate: http://www.laiserin.com/features/bim/index.php, http://www.laiserin.

com/features/bim/index.php (2003).

[31] G. Lee, A new and formal process to product modeling (PPM) method and

its application to the precast concrete industry, PhD dissertation, College

of Architecture, Georgia Institute of Technology, 2004.

[33] G. Lee, C.M. Eastman, R. Sacks, R. Wessman, Development of an

intelligent 3D parametric modeling system for the North American

precast concrete industry: phase II, ISARC-21st International Symposium

on Automation and Robotics in Construction, NIST, Jeju, Korea, 2004,

pp. 700–705.

[34] G. Lee, R. Sacks, C.M. Eastman, Dynamic information consistency

checking in the requirements analysis phase of data modeling

(Keynote), in: Z. Turk, R. Scherer (Eds.), European Conference for

Process and Product Modeling (ECPPM), A.A. Balkema, Slovenia,

2002, pp. 285–291.

[35] G. Lee, R. Sacks, C.M. Eastman, A Process Modeling Tool for Product

Modeling: GT PPM, Qualifying Paper, College of Architecture, Georgia

Institute of Technology, Atlanta GA, USA, 2002.

[36] J.Y. Lee, K. Kim, Geometric reasoning for knowledge-based parametric

design using graph representation, Computer-Aided Design 28 (1996)

831–841.

[37] R.A. Light, A dimension based 2-D shape editing feature for computer-

aided drafting systems, Bachelor’s thesis, MIT, June 1979.

[38] V.C. Lin, Three dimensional variational geometry in computer-aided

design, Master’s thesis, MIT, May 1981.

[39] D. Mahaffy, G. Lee, The Parametric Object (modeling) Planner, Vol.

Volume, Precast Concrete Software Consortium, Denver, PA, 2004.

[40] W. Mitchell, R. Liggett, M. Tan, Top-down knowledge-based design, in:

M. McCullough, W. Mitchell, P. Purcell (Eds.), The Electronic Design

Studio: Architectural Knowledge and Media in the Computer Era, MIT

Press, Cambridge, MA, 1990, pp. 137–148.

[41] J. Monedero, Parametric design: a review and some experiences,

Automation in Construction 9 (2000) 369–377.

[42] S. Myung, S. Han, Knowledge-based parametric design of mechanical

products based on configuration design method, Expert Systems with

Applications 21 (2001) 99–107.

[43] T. Oksala, KAAD: evolutionary and cognitive aspects, in: G. Carrara, Y.E.

Kalay (Eds.), Knowledge-Based Computer-Aided Architectural Design,

Elsevier, 1994.

[44] R.E. Oxman, Case-based reasoning in knowledge-based design, in: B.

Bezelga (Ed.), European Symposium on Management, Quality and

Economics in Housing and other Building Sectors, Lisbon, Portugal,

E&FN Spon, London, 1991, pp. 1516–1525.

[45] S.C. Park, Knowledge capturing methodology in process planning,


[46] PCSC, The Precast Concrete Software Consortium (PCSC) website,

http://dcom.arch.gatech.edu/pci2. (2000).

[47] M.J. Pratt, B.D. Anderson, A shape modelling applications programming

interface for the STEP standard, Computer-Aided Design 33 (2001)

531–543.

[48] A.A.G. Requicha, Part and Assembly Description Language: Dimension-

ing and Tolerancing (Production Automation Project), Vol. Volume,

University of Rochester, 1977.

[49] D. Roller, An approach to computer-aided parametric design, Computer-

Aided Design 23 (1991) 385–391.

[50] D. Roller, I. Kreuz, Selecting and parameterising components using

knowledge based configuration and a heuristic that learns and forgets,


[51] R. Rundell, Revit: parametric building modeling: Part 2. Why parametric

building modeling matters, Cadalyst, 2005, (http://aec.cadalyst.com/aec/

article/articleDetail.jsp?id=150779).

[52] J.H. Rutherford, T.W. Maver, Knowledge-based design support, in: G.

Carrara, Y.E. Kalay (Eds.), Knowledge-Based Computer-Aided Architec-

tural Design, Elsevier, 1994.

[53] R. Sacks, C.M. Eastman, G. Lee, Parametric 3D modeling in building

construction with examples from precast concrete, Automation in

Construction 13 (2004) 291–312.

[54] R. Sacks, C.M. Eastman, G. Lee, Process model perspectives on

management and engineering procedures in the North American pre-

cast/prestressed concrete industry, The ASCE Journal of Construction

Engineering and Management 130 (2004) 206–215.

[55] J.J. Shah, M. Mantyla, Parametric and Feature-Based CAD/CAM:

Concepts, Techniques, and Applications, John Wiley and Sons, New

York, 1995.

[56] I.E. Sutherland, Sketchpad: a man–machine graphical communication

system, AFIPS Spring Joint Computer Conference, 1963, pp. 329–346

Detroit, MI.

http://www.laiserin.com/features/bim/index.php

http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=150779

http://www.laiserin.com/features/bim/index.php

http://dcom.arch.gatech.edu/pci2

Specifying parametric building object behavior (BOB) …big.yonsei.ac.kr/pdf/Publications_Patents/1....

Documents

Transcript of Specifying parametric building object behavior (BOB) …big.yonsei.ac.kr/pdf/Publications_Patents/1....