Upload
vuongtuyen
View
225
Download
0
Embed Size (px)
Citation preview
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776 761
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776762
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776 763
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776764
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776 765
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776766
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
G. Lee et al. / Automation in Construction 15 (2006) 758–776 767
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776768
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776 769
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776770
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776 771
(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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776772
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
G. Lee et al. / Automation in Construction 15 (2006) 758–776 773
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)
G. Lee et al. / Automation in Construction 15 (2006) 758–776774
Arc / Circle Curve Surface
G. Lee et al. / Automation in Construction 15 (2006) 758–776 775
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.
G. Lee et al. / Automation in Construction 15 (2006) 758–776776
[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,
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.