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 b

Georgia Institute of Technology, Atlanta, GA, USA 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 information 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-

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 threedimensional 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, engineering and construction (AEC) area, examples of 3D knowl-

* 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

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 domainspecific 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 structural 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 customized 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 connections, 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 connections and curved fac ade 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 characteristics 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-concreteconnection 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 hardcoded 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. Parameterization 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 modeling 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. Examples 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 parameterization (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 preprogrammed parametric objects as parametric modeling systems. The following characteristics distinguish parametric modeling systems from other existing CAD systems and provide mechanisms to translate domain expertise into geometric 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 parametric 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-oriented 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 D C Drilling B Boring

4
A Reaming
Boring

3
Drilling

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

Some studies have been conducted in translating and implementing 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 connection. 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 horizontalif 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. 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

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

Fig. 4. A parametric connection with 165 parameters.

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 mechanical 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 relatively large and complex parametric modeling activities (especially 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:

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

Validation Phase

Does the created parametric object behave 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 assemblies, 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 descriptions 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

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

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

Fig. 7. Various types of connections.

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

765

(a) Room A and Room B (b) Two columns and one beam
Column C1 B A Beam B1 Column C2

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

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 RESHAPE. 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 constraints) can be used together with arrows to describe object behavior: Max; Min; > ; < ; ; ; ; =; 4; ; AND; OR See Appendix B for other possible geometric constraints.

Table 1 Lines Symbol Description A dotted line Usage Hidden lines, guidelines

A A A

A thin line

Inner edges
a 3D View of Object A enlarged object A chamfered object A

A thick line

Boundaries

A
A dashed line A trace of previous shape

Hatches

A cut, a gap, space or tolerance between objects

a bottom View of Object A

a gab between objects A and B

Fig. 9. Examples of using lines.

766 Table 2 Pivot and connection points 2D symbol

(top) (side)

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

A
Name Pivot point Usage 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. 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.

A B
40 Deg

3D symbol

(a) Rotate Object A counter-clock

wise about a pivot point.

(b) Rotate B 40 degree either CCW or

CW from parallel.

Max 4"

(top) (side)

Connection point

(c) Object A can be translated to the

right 4" at maximum from current location

Fig. 10. Examples of using several BOB symbols.

Fig. 10 illustrates examples of object behavior described using a pivot point, a connection point and constraint descriptors. Fig. 11 shows several other declarative geometric constraints 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 timeconsuming 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

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

Rotational arrows Counter clock wise rotation Clock wise rotation Free rotation

Directional arrows Unidirectional change Unidirectional change Bidirectional change

H

equal spacing, even distribution, equal dimension vertical constraint normal constraint

horizontal constraint parallel constraint conincidental constraint

C*

colinear constraint

Fig. 11. More declarative geometric constraints.

G. Lee et al. / Automation in Construction 15 (2006) 758 776 Table 4 The parametric object (modeling) planner Section 1. Identification Items Object name Version number Modeled by Affiliation First created date Last modified date Description (brief description) Neighboring objects Planned use (initial goals for functionality) Known limitations/rules Index number Variable name Label/variable in dialog box Abbreviation Default value Visibility (show/hide) Descriptor Comments Stimuli Behavior

767

2. Object definition

3. Parameters

4. BOB descriptions

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

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-towall 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 2the 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.

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) Top of lite wall Lite wall (upper) Shear wall (upper) Secondary part 1 Horizontal lite wall Lite wall (lower) Shear wall (lower) Secondary part 2 Secondary part 3 Secondary part 4

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 determined 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 reinforcement) (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 userdefined 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 parametric objects.

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

769

Stimulus
WL: Wall Length S1 S2 (Default: 3'-4") (Default: 3'-4") S3 (S3 = S1)

Behavior
WL2 = S1 S2 S2 S3

WP2: Secondary wall panel (supported) When the wall panels are extended

WP2 Extended D2 (D2 = D1)

D1 (Default: 2") WWC: Wall-towall array connection JT: Joint Thickness PT: Pad Thickness (Default: 3/4)

D2 (D2 = D1) Extend

D1 (Default: 2")

n: number of connection points Extend WP1

Extended

WP1: Primary wall panel (supporting) WL1

WL1

S2: spacing between connections

IF WL1 >= WL2 THEN WL = WL2 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 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 parametric 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 developers 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 companys expertise or intellectual property into such systems. Advanced parametric modeling technology provides AEC software users and developers with an effective means to embed such domain knowledge in a system without hardcoding. 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

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

*Values in the parenthesis are default values.
Overall Stair Length Last Tread Depth or Upper Landing Length (= Tread Depth) (=Landing Thickness)

771

Total Run: from 1st tread nosing to the last tread nosing Obstacle

[Riser Height & Number of Steps Calculation] RH = Riser Height NS = Number of Steps HFL = Half Floor Height RH = 7.5" (or 190mm) NS = Integer( HFL / RH) + 1 NewRH = HFL / NS *The maximum rise: BOCA: 7" (178mm) IBC: 7" (178mm) Industry practice: 7.5" (or 190mm)

6 5

D3 (=D1)

Total Rise (=Half Floor Height)

Headroom

Overall Stair Height

4 3 2

D4 (=D2)

Zero Tread Depth or Lower Landing Depth (= Tread Depth)

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

1: First Tread Landing Thickness (8") 0 D1 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. Stringer Thickness (Landing Thickness = 8" or 203mm) subtracted finish (tile, CIP...) space

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 11 10 9 8 7 6 5 4 3 2 1 This landing has been automatically generated in the middle of a staircase. It is not fixed. 5 4 3 2 1

Push down

12 11 10 9 8 7 6

Drag

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 until its length reaches its minimum length (= stairway width). The user will then be alerted that the landing has reached its minimum allowable size. This is especially necessary where the stairway envelope is fixed. The user would then have the option to: i) return the landing to its original position (or somewhere in between) or ii) extend the envelope size (and its components). 4) The landing on the other side will be adjusted to suit, depending on user response i) or ii).

12 11 10 9 8 7 6 5 4 3 2 1 1 2 6 5 4 3

Fig. 16. An example of staircase behavior.

772

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

(a) initial state

(b) after changing the floor-to-floor height Note the change in the riser height.

Fig. 17. An incorrectly implemented parametric staircase.

into explicit geometric rules and embedding them into a system. As one possible approach to overcome these problems, this paper proposes the BOB notation and description method, and describes how the proposed method can be used in the four parametric modeling phases with examples drawn from an industry-wide parametric model library development effort. The four parametric modeling phases are the knowledge elicitation phase, the design phase, the implementation phase and the validation phase. The BOB notation and description method is proposed as a shorthand script and a protocol for describing parametric definitions and behavior of building objects in a sharable and reusable format. Clarity and efficiency are the two primary criteria of the BOB notation. Dimensional accuracy and completeness of the diagrams are less of a concern in the early knowledge elicitation phase because they can be incrementally elaborated and enhanced through other parametric modeling phases including the design phase. The BOB diagrams can be used as a guide map to implement parametric objects, to build user-defined parametric models and to check them in the implementation and validation phases. The BOB notation is not intended to automate encoding of object behavior definitions. As such, no attempt has been made to develop algorithms to automatically translate a set of BOB diagrams with high-level object behavior definitions (fix, rotate, translate, reshape, etc.) into a single parametric model

with low-level parametric definitions (equal dimension, angular constraint, etc.). If this direction were pursued in future research, then validation rules would be needed to check the conformity of the resultant models. While the BOB notation was developed within the domain of precast concrete construction, it is likely to be useful for buildings in general and possibly for other industries (albeit with addition and modification). The role of advanced parametric modeling systems in BIM is likely to grow in importance. Clear communication and collaboration between domain experts, consultants and software developers are essential for the success of any advanced parametric modeling system development project. The BOB notation and description 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, particularly 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 connection point A pivot point of an object 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 free rotation unidirectional change

B Rotate B 40 degree either CCW or CW

bidirectional direction hidden lines, guidelines inner edges boundaries

Object A can be translated to the right 4 at maximum

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" tolerance, range descriptors Max, Min, >, < =, +, - , /, * ^ Max 2" D = H / 2 B A H

The maximum gap between objects A and B is 2". mathematical operators A

Max 20 Deg

B x

AND, OR

logic operators

0 Deg < x < 30 Deg

A A

alignment constraint

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

equal spacing, even distribution, equal dimension

= B

= A B

= A

even distribution
= B

another way of defining even distribution

horizontal constraint vertical constraint

This symbol denotes an element horizontal to the ground. This symbol denotes an element vertical to the ground. This symbol denotes an element parallel to another element.

H V

parallel constraint normal constraint

P A B

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 Entity 2 Referential points (origin, control points) Referential lines (grid lines, axes) Offset Offset (Parallel) Concentric Tangential offset Tangential offset Tangential offset Tangential offset Offset Centroid Offset (Parallel) Horizontal Vertical Angular Offset Normal Offset Centroid offset Offset (Parallel) Normal Angular Offset (Parallel) Tangential offset Point Line Arc / Circle Curve Surface

Offset

Referential planes Point

Offset Offset

Offset Horizontal Vertical Angular Offset Offset

Line

Offset (Parallel) Perpendicular Equal length Angular

Tangential offset Concentric Tangential offset Tangential offset

Offset Concentric offset Tangential offset

Arc / Circle

Concentric Equal radius (diameter) Equal angle Equal arc length

Curve Surface

Offset Offset (Parallel) Perpendicular Angular

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 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 manufacturing workcells, Intelligent Manufacturing 3 (1992). [10] B. Chandrasekaran, Functional representations: a brief historical perspective, 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 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 Studio: Architectural Knowledge and Media in the Computer Era, MIT Press, Cambridge, MA, 1990, pp. 137 148. J. Monedero, Parametric design: a review and some experiences, Automation in Construction 9 (2000) 369 377. S. Myung, S. Han, Knowledge-based parametric design of mechanical products based on configuration design method, Expert Systems with Applications 21 (2001) 99 107. T. Oksala, KAAD: evolutionary and cognitive aspects, in: G. Carrara, Y.E. Kalay (Eds.), Knowledge-Based Computer-Aided Architectural Design, Elsevier, 1994. 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. S.C. Park, Knowledge capturing methodology in process planning, Computer-Aided Design 35 (2003) 1109 1117. PCSC, The Precast Concrete Software Consortium (PCSC) website, http://dcom.arch.gatech.edu/pci2. (2000). M.J. Pratt, B.D. Anderson, A shape modelling applications programming interface for the STEP standard, Computer-Aided Design 33 (2001) 531 543. A.A.G. Requicha, Part and Assembly Description Language: Dimensioning and Tolerancing (Production Automation Project), Vol. Volume, University of Rochester, 1977. D. Roller, An approach to computer-aided parametric design, ComputerAided Design 23 (1991) 385 391. 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. 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). J.H. Rutherford, T.W. Maver, Knowledge-based design support, in: G. Carrara, Y.E. Kalay (Eds.), Knowledge-Based Computer-Aided Architectural Design, Elsevier, 1994. 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. R. Sacks, C.M. Eastman, G. Lee, Process model perspectives on management and engineering procedures in the North American precast/prestressed concrete industry, The ASCE Journal of Construction Engineering and Management 130 (2004) 206 215. J.J. Shah, M. Mantyla, Parametric and Feature-Based CAD/CAM: Concepts, Techniques, and Applications, John Wiley and Sons, New York, 1995. I.E. Sutherland, Sketchpad: a man machine graphical communication system, AFIPS Spring Joint Computer Conference, 1963, pp. 329 346 Detroit, MI.

[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 twodimensional 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 debate: 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 computeraided 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

[41] [42]

[43]

[44]

[45] [46] [47]

[48]

[49] [50]

[51]

[52]

[53]

[54]

[55]

[56]