See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/228731196

Specifying parametric building object behavior

(BOB) for building information modeling
system

Article in Automation in Construction November 2006

DOI: 10.1016/j.autcon.2005.09.009

CITATIONS READS

137 294

3 authors:

Ghang Lee Rafael Sacks

Yonsei University Technion - Israel Institute of Technology
109 PUBLICATIONS 902 CITATIONS 146 PUBLICATIONS 3,255 CITATIONS

SEE PROFILE SEE PROFILE

Charles M. Eastman
Georgia Institute of Technology
178 PUBLICATIONS 3,516 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Building Quake & People a serious game platform for informing life saving strategies View project

BIM Handbook, 3rd edition View project

All content following this page was uploaded by Ghang Lee on 23 April 2014.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
 Automation in Construction 15 (2006) 758 776
www.elsevier.com/locate/autcon

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, USA
b
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 Sutherlanda 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-
* Corresponding author.
E-mail address: ghang.lee@arch.gatech.edu (G. Lee).
0926-5805/$ - see front matter D 2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.autcon.2005.09.009
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-
 G. Lee et al. / Automation in Construction 15 (2006) 758 776
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.
759
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
760 G. Lee et al. / Automation in Construction 15 (2006) 758 776
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], Kimuras 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 Eastmans Design of Assemblies
[15]. Another was Rollers 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) provide
pre-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].
 G. Lee et al. / Automation in Construction 15 (2006) 758 776 761

8
G Counter Sink

7
F Tapping

E 5
Boring
D

C 1
Drilling
B

4 3 2
A Reaming Boring Drilling

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

Some studies have been conducted in translating and imple- Another hindrance that makes parametric modeling difficult
menting expert knowledge in parametric modeling systems in is its complexity. When multiple sets of object-behavior
the form of geometric constraints [6,7,36]; however, the focus patterns are considered, the number and the complexity of
of most studies has been primarily on representing, solving and parameters and geometric constraints grows exponentially. For
optimizing geometric constraints rather than on capturing and example, Fig. 2 shows a precast concrete floor panel called a
describing domain knowledge in the form of explicit geometric double-tee connected to a beam using a pocket-type connec-
relations in the first place. tion. An expected behavior pattern of the connection is that the
One of the rare studies in capturing domain knowledge in a pockets in the beam should be adjusted to the locations and the
form of explicit geometric relation in the early modeling stage sizes of the stems (the bottom part of a double-tee). When the
is [45]. Sang K. Park [45] proposed a method to represent a stems are too deep for the beam, they are Fdapped_ (cut back)
process plan for hole-making in mechanical engineering using over part of their height, leaving only the undapped parts to rest
a state transition diagram (Fig. 1) based on a three-phase in the pockets.
modeling methodology consisting of an object model, a In order to define a pocket on a beam, at least five parameters
functional model and a dynamic model. The method is suitable are required: i.e., pocket_depth, pocket_width, pocket_height,
for describing a procedure of applying various features in horizontal_location and vertical_location (Fig. 3) (assuming the
creating a complex shape. However, it is insufficient to beam and double-tees are horizontalif not, a rotation would
describe complex building-object behaviors, which yield also be necessary). However, pocket width, depth, height and
different reactions depending on the prevailing conditions. location are usually defined not by absolute values as illustrated
in Fig. 3, but by relative values defined by load conditions, the
3. Limitations and difficulties of parametric modeling shear strengths of the beam and of the stems, local shear
strength below the pocket, the angle of the stem and so on. The
Parametric modeling is a powerful method to model number of independent parameters can be very large.
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. Fig. 2. A beam and a double tee.
762 G. Lee et al. / Automation in Construction 15 (2006) 758 776
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 connection with 165 parameters.
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
 G. Lee et al. / Automation in Construction 15 (2006) 758 776
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:
763
Knowledge Elicitation
Phase (Preliminary
Design Phase) Capture object behavior
Interprete object behavior in
terms of geometric relations
Design Phase
Define parameters and
relations between them.
feedback
Optimize parameters and
geometric constraints
Implementation Phase
Implement parameters and
relations between them.
invalid
Does the
created
parametric
object
behave
Validation Phase correctly?
Valid
Fig. 5. A parametric object design process.
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 bicycles 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
764 G. Lee et al. / Automation in Construction 15 (2006) 758 776
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 of connections.
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
 G. Lee et al. / Automation in Construction 15 (2006) 758 776
(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
Table 1
Lines
Symbol 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
765
Column C1 Beam B1
Column C2
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.
A
A A
a 3D View of Object A enlarged object A chamfered object A
A
B A
a bottom View of Object A a gab between objects A and B
Fig. 9. Examples of using lines.
766 G. Lee et al. / Automation in Construction 15 (2006) 758 776

Table 2
A
Pivot and connection points A
2D symbol 3D symbol Name Usage B 40 Deg

(top) Pivot A pivot line for rotating

point an object: a pivot point (a) Rotate Object A counter-clock (b) Rotate B 40 degree either CCW or
wise about a pivot point. CW from parallel.
can be placed only on a
(side) single object or on a single
object and a reference
Max 4" B
geometry.
A
(top) Connection A connection point between
point objects, with reference to (c) Object A can be translated to the
intersection of principle axes right 4" at maximum from current
(side)
of each object: a connection location
point must be placed
Fig. 10. Examples of using several BOB symbols.
between at least two objects.

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 Shahs 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
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

Table 3 equal spacing, even

Arrows: rotational and directional changes A alignment constraint = distribution, equal
dimension
Rotational arrows Directional arrows
Counter clock wise rotation Unidirectional change
H horizontal constraint V vertical constraint

P parallel constraint normal constraint

Clock wise rotation Unidirectional change

Free rotation Bidirectional change conincidental constraint C* colinear constraint

Fig. 11. More declarative geometric constraints.

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

Table 4 PCSC members post and share parametric connections and

The parametric object (modeling) planner their Parametric Object Planners described at the end of
Section Items Section 5. Table 5 is an example of the Object Definition
1. Identification Object name section of the Parametric Object Planner specified for wall-to-
Version number wall array connection shown in Fig. 7(b).
Modeled by
Fig. 13 illustrates the behavior of a wall-to-wall array
Affiliation
First created date connection. A connection connects two or more concrete
Last modified date pieces. The geometric properties of a connection are defined by
2. Object definition Description (brief description) the relationship between the connected pieces and the
Neighboring objects connection. In order to enable users to build such parametric
Planned use (initial goals for functionality)
connections, a system must support the second and the third
Known limitations/rules
3. Parameters Index number parametric modeling capabilities described in Section 2the
Variable name capabilities to define the parametric relations between
Label/variable in dialog box different objects and to use parameters in other objects. For
Abbreviation example, a wall-to-wall array connection connects two walls
Default value
vertically.
Visibility (show/hide)
Descriptor On each end of a wall-to-wall array connection, there is a
Comments pad, whose thickness depends (PT in Fig. 13) on the joint
4. BOB descriptions Stimuli thickness (JT) between the two walls. For accuracy and
Behavior 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
intensive domain knowledge capturing and specification and D2 in Fig. 13), the default thickness is 3/4 inches
process, during which 1655 files (drawings, reports, tables (1.905 cm) as illustrated in Fig. 13. When the lengths of
and BOB diagrams) were collected. Further details on the supporting and supported walls increase, the number of
platform system selection process and the domain knowledge connection points (n) increases. The lengths of the two
specification process are available in several publications connected walls (WL1 and WL2) are usually the same.
[18,19,33,54]. However, if only one of the walls is extended, the length of
In this project, user-defined parametric objects were built in a shorter wall should be regarded as the length of the
two waysfrom scratch and from pre-defined abstract objects. connection array as shown in Fig. 13. There are various
An example of each approach is provided below respectively in ways to calculate the number of connection points between
(Figs. 13, 14 and 16). Using the improved parametric modeling the two walls and the distance between the connections. A
tools and the BOB notation, precast concrete detailers and common practice is to divide the wall length by the default
engineers have also defined and built parametric object spacing between connections (3 ft 4 in., 101.6 cm) and to
libraries, which include the most commonly used precast distribute the remainder to the spacing between connections
concrete pieces and connections. Fig. 12 is a screenshot of the as shown in Fig. 13 or to the distance between the wall end
Connection Libraries section of the PCSC website, where the and the end connection.

Table 5
An example of the object definition section of the parametric object planner
Object definition
Description ( brief description of connection ) : dowel splice connection utilizing (2) 24 grout tubes, (2) #7 DBSAE, (2) #7 dowel inserts, and (2) 3/4x6x6 steel shims.
Neighboring objects: ( up to 10 secondary parts allowed )
Main part (type) Secondary part 1 Secondary part 2 Secondary part 3 Secondary part 4
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) 6x6 shims with parametric thickness depending on joint size, allowing for movement from the soffit of the piece and its insertion end.
2. Simple (2) #7 dowel splice connections that can be moved distances from the soffit of the piece as well as distances from its insertion end. The respective cut
within the grout tube shall also move with each individual splice. In this case, the connection is made up of standard imbeds used only in instances where a #7
connection is engineered.
Known limitations/rules:
Detailing (industry usage):
1. The top piece must be chosen as the main part. Lower piece as the secondary part.
2. Thickness of the pieces is irrelevant, as long as the user changes the distance from the soffit to suit.
3. The main part can be as tall as it wants to, but the secondary part cannot be taller than 7-3 due to magnetic plane sizes.
768 G. Lee et al. / Automation in Construction 15 (2006) 758 776
Fig. 12. The Connection Library section of the PCSC website.
Fig. 14 illustrates another BOB diagram examplea
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.
 G. Lee et al. / Automation in Construction 15 (2006) 758 776 769

Stimulus Behavior

WL: Wall Length

WL2
S1 S2 S3 =
(Default: 3'-4") (Default: 3'-4") (S3 = S1) S3
S1 S2 S2

WP2: Secondary wall panel (supported) WP2

Extended
When the wall panels are extended

D1 (Default: 2") D2
(D2 = D1) D1 (Default: 2") D2
WWC:
Extend (D2 = D1)
Wall-to-
wall array
connection
PT: Pad Thickness
JT: Joint Thickness

(Default: 3/4)

n: number of n
= connection
points
Extended
Extend
WP1: Primary wall panel (supporting) WP1

WL1 WL1

IF WL1 >= WL2 THEN WL = WL2

S2: spacing between connections IF WL1 < WL2 THEN WL = WL1
n = INT((WL - S1 *2) / 3'-4") + 1
Adjusted S2 = (WL - S1 *2) / (n -1)

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

Fig. 15 shows parameters, their default values and part description method can be used as a protocol to design,
names of a stair. One of the basic behaviors of a stairwell is validate and share the design intent of parametric objects
floor height change. In order to maintain the validity of a between parametric modeling system users, software devel-
stairwell, if a floor height changes, either the riser height or the opers and domain experts.
number of risers (steps) should be updated. However, it is not
common practice in the North American precast industry to 7. Summary and discussion
change the riser height because a precast stair piece is usually
produced using a metal stair form, whose riser height can be An intelligent CAD system that can generate and provide
changed only within a minor range of tolerance. Thus, in such consistent and valid information to other systems is a core
cases, the number of steps should be modified. Fig. 17 shows enabler of building information modeling. It is expected that
an incorrectly implemented stairwell object. In Fig. 16, the individual companies will embed aspects of the companys
correct behavior of a parametric staircase object when the expertise or intellectual property into such systems. Ad-
middle landing is pushed down, or the first stair is dragged to vanced parametric modeling technology provides AEC
the right, is illustrated using the BOB notation. software users and developers with an effective means to
In the above two examples, only one possible behavior of a embed such domain knowledge in a system without hard-
parametric object is exemplified. However, an object is coding.
expected to express different behaviors depending on different However, parametric modeling is still challenging and has
circumstances (e.g., different company practices, different limitations. First of all, it is not easy to capture tacit
neighboring objects and different construction methods). It is knowledge and interpret it into explicit geometric and other
impractical to embed all possible expected behaviors and relationships, which a system can understand (e.g., numerical
different scenarios in one pre-built or user-defined parametric equations or specific declarative expressions). Also, as more
object even if they could be exhaustively defined using and more design and engineering processes are automated,
multiple BOB diagrams. Sometimes, the different behavior the risk of propagating errors increases. A parametric
patterns of the same objects may conflict with one another modeling system will require careful engineering judgment
depending on the situation. An object with such conflicting and responsibilities in setting up the input and reviewing the
behavior patterns should be developed as two or more separate output and a method to specify the requirements in an
parametric objects. unambiguous way. Another problem of parametric modeling
As the demand for highly automated (intelligent) systems is significant performance degradation, which occurs when
increase in the future, the importance of user-defined paramet- large numbers of parameters and geometric constraints are
ric objects will also increase. The BOB notation and added to a model. Also, since parametric modeling allows
770 G. Lee et al. / Automation in Construction 15 (2006) 758 776

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 isnt 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
 G. Lee et al. / Automation in Construction 15 (2006) 758 776 771

*Values in the parenthesis are default values.

Overall Stair Length
Last Tread Depth or
Upper Landing Length
Total Run: from 1st tread nosing to the last (= Tread Depth)
tread nosing [Riser Height & Number of Steps
Calculation]

Thickness)
(=Landing
Obstacle
6
D3 RH = Riser Height
(=D1) NS = Number of Steps
5
HFL = Half Floor Height
(=Half Floor Height)

Headroom
D4 (=D2)
4 RH = 7.5" (or 190mm)
Overall Stair Height

Total Rise

NS = Integer( HFL / RH) + 1

Zero Tread Depth or 3
NewRH = HFL / NS
Lower Landing Depth Other Parameters
(= Tread Depth) *The maximum rise:
2 - Number of Steps (usually driven value)
- Tread Width (= Flight Width = Stair Width) BOCA: 7" (178mm)
IBC: 7" (178mm)
1: First Tread Industry practice: 7.5" (or 190mm)
Stringer Thickness
Thickness
Landing

0 (Landing Thickness = 8" or 203mm)

(8")

subtracted
D1
finish (tile,
CIP...) space
D2 Tile space (thickness) can be subtracted from the
Landing Thickness afterwards if tiles are added as a
finish:
cf. See Unistress's staircase details.

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

Stimulus
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,

This landing is fixed to a

floor.

12 Push 12
11 down 11
10 10
9 9
8 8
7 7
6 6
5 5
This landing has been
4 automatically 4
3 generated in the middle 3
2 of a staircase. It is not 2 Drag
1 fixed. 1

Behavior
1) Nothing will happen (or a system will alert users for
an illegal action) if the middle landing is fixed to an
existing building structure.
2) If the middle landing is free, the number of stairs in
the first flight will be decreased while the number of
stairs in the second flight will be increase to maintain
the floor-to-floor height.
3) The landing on the moved side will be decreased
12 until its length reaches its minimum length (= stairway
11
width). The user will then be alerted that the landing
10
9 has reached its minimum allowable size. This is
8 especially necessary where the stairway envelope is
7 fixed. The user would then have the option to: i)
6 6
5
return the landing to its original position (or
5
4 4 somewhere in between) or ii) extend the envelope
3 3 size (and its components).
2 2 4) The landing on the other side will be adjusted to
1 1
suit, depending on user response i) or ii).

Fig. 16. An example of staircase behavior.

772 G. Lee et al. / Automation in Construction 15 (2006) 758 776
(a) initial state
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
(b) after changing the floor-to-floor height
Note the change in the riser height.
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.
 G. Lee et al. / Automation in Construction 15 (2006) 758 776 773

Appendix A. Building object behavior (BOB) notation

SYMBOL NAME USAGE EXAMPLE

Basic entities
pivot point A pivot point of an object
connection point A connection point of objects. Aconnection point must
be placed more tha two objects
Rotate Object A counter clock wise
along a pivot point

counter-clock wise rotation

40 Deg
clock wise rotation B

Rotate B 40 degree either CCW or CW

free rotation

B
unidirectional change

Object A can be translated to the right 4

bidirectional direction at maximum

hidden lines, guidelines

inner edges

boundaries

a 3D View of Object A

a bottom View of Object A

a trace of previous shape

enlarged object A champered object A

a cut, a gap tolerance

object identifier

(continued on next page)

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

Appendix A (continued)

SYMBOL NAME USAGE EXAMPLE

Constraint descriptors
8" Max 2" D = H / 2

tolerance, range descriptors B A H

Max, Min,
>, < The maximum gap between
objects A and B is 2".
=, mathematical operators
+, - , /, * B
^ A Max 20 Deg

AND, OR logic operators 0 Deg < x < 30 Deg

A
This symbol can only apply to linear
A alignment constraint elements (e.g., joints, linear edges of
building objects) B A
A

equal spacing, even = = =

=
distribution,
equal dimension B A B A

another way of defining

even distribution
even distribution
=

B
A

This symbol denotes an element H

H horizontal constraint
horizontal to the ground.
V
A
V vertical constraint This symbol denotes an element vertical
to the ground.

P
This symbol denotes an element parallel
parallel constraint P
to another element.
A B
normal constraint This symbol denotes an element normal
to another element.

A another way of defining

a NORAML relation
 G. Lee et al. / Automation in Construction 15 (2006) 758 776 775

Appendix B. Other possible geometric constraints

Entity 1 Point Line Arc / Circle Curve Surface

Entity 2
Referential points Offset Offset (Parallel) Concentric Tangential Offset
(origin, control Tangential offset Centroid
points) offset
Referential lines Offset Offset Tangential Tangential Offset (Parallel)
(grid lines, axes) Horizontal offset offset Horizontal
Vertical Vertical
Angular Angular
Referential planes Offset Offset Tangential Offset Offset
offset Normal
Point Offset Offset Concentric Concentric Offset
Tangential offset Centroid offset
offset
Line Offset (Parallel) Tangential Tangential Offset (Parallel)
Perpendicular offset offset Normal
Equal length Angular
Angular
Arc / Circle Concentric Offset (Parallel)
Equal radius Tangential offset
(diameter)
Equal angle
Equal arc
length
Curve Offset
Surface Offset (Parallel)
Perpendicular
Angular

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

[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 Autodesks 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.
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
Graphisofts 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.
776 G. Lee et al. / Automation in Construction 15 (2006) 758 776
[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, Masters 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 modelingthe 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, Bachelors thesis, MIT, June 1979.
[38] V.C. Lin, Three dimensional variational geometry in computer-aided
design, Masters 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
View publication stats
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,
Computer-Aided Design 35 (2003) 1109 1117.
[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,
Computer-Aided Design 35 (2003) 1085 1098.
[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.