www.elsevier.com/locate/autcon

Automation in Construction 13 (2004) 291–312

Parametric 3D modeling in building construction with examples

from precast concrete

Rafael Sacks*, Charles M. Eastman, Ghang Lee

College of Architecture, Georgia Institute of Technology, Atlanta, GA 30332-0155, USA

Accepted 12 May 2003

Abstract

Buildings are complex products containing relatively large numbers of distinct parts that are collected in multiple assemblies

for different design, analysis and production purposes. Modeling buildings in fully parametric 3D computer-aided design

(CAD) systems offers numerous benefits in terms of productivity, the ability to rapidly generate design alternatives at different

levels and elimination of errors that result from the disparity between different drawings in current practice. However, full

realization of these benefits requires specialized functionality, including top-down modeling, objects with functional behavior,

the ability to embed contextual design intent, automation of layout and detailing and appropriate management of similar objects.

An effective system must provide such functionality while maintaining adequate response times. The requirements, features and

performance have been examined as part of specification of a new 3D parametric CAD platform for the North American Precast

Concrete Software Consortium (PCSC). They are described and discussed after a review of solid and parametric modeling, with

examples from the domain of precast concrete construction.

D 2004 Published by Elsevier B.V.

Keywords: Parametric building modeling; Computer-integrated construction; Design automation; Precast concrete

1. Introduction

The theoretical benefits of computer-integrated

construction—lower engineering costs due to auto-

mated analysis and drafting, lower production costs

due to reduced error rates and data integration sup-

porting management functions and automated fabri-

0926-5805/03/$ - see front matter D 2004 Published by Elsevier B.V.

doi:10.1016/S0926-5805(03)00043-8

* Corresponding author. Department of Civil and Environ-

mental Engineering, The Technion-IIT, Room 840 Rabin Building,

Technion City, Haifa 3200, Israel. Tel.: +972-4-8293190; fax: +972-

4-8323433.

E-mail addresses: rafael.sacks@arch.gatech.edu,

cvsacks@technion.ac.il (R. Sacks).

cation—have been widely stated [6,34]. Practice,

however, lags far behind theory. Computer-aided

design and drafting (CADD)1 has been widely adop-

ted by precast concrete design and fabrication com-

panies, as it generally has by the rest of the

construction industry. A survey of North American

precast concrete producers found that 96.3% use

CADD in-house; the remainder outsource their design

work to consultants, whom the survey found to be

100% CADD users [23]. However, electronic drafting

has not resulted in any change in the process work-

1 Note: The term ‘CADD’ (computer-aided design and

drafting) is deliberately used rather than ‘CAD’ (computer-aided

design) to emphasize the drafting aspect of the technology.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312292

flows. In CADD, computers are used to generate

drawings, which are the medium of communication

during the production and erection stages of the

precast process. CADD drawings are only readable

as graphics, so that information transfers for process

activities such as structural analysis, bills of material,

coordination between building systems, quality con-

trol, rebar fabrication and piece production, must be

done by people. For many of these activities, the labor

cost of translating data from CADD to some automa-

tion application negates the economic viability of the

automation; manual data entry is also prone to human

error. In practice, little of the design and production

automation potential inherent in information technol-

ogy is exploited with CADD; in terms of the business,

design and production process, CADD has simply

replaced physical drawing boards with electronic

ones.

In many manufacturing industries, on the other

hand, drafting has been replaced by computer-aided

design based on 3D solid modeling. Solid modeling

supports a wide range of automation and quality

control applications that utilize the information gen-

erated. In the field of building design and construc-

tion, the parallel potential benefits include the use of

knowledge-based design tools, automated detailing

and drawing production, automated interfaces to

structural, thermal, vibration and other analyses and

quality improvements. The impacts are not limited to

design and engineering—automatic fabrication and

assembly is also possible (e.g., Refs. [20,22]).

With few exceptions (most notably Frank Gehry’s

use of CATIA and Xsteel for the Walt Disney Concert

Hall [16]), parametric solid modeling software has not

been applied in the architecture, engineering and

construction (AEC) industry. The primary reason is

the additional human effort required to build a geo-

metrically and topologically accurate solid model of a

building and the corresponding absence of economic

incentive for building designers to undertake that

effort [9]. However, a new generation of 3D paramet-

ric modeling tools is now becoming available (e.g.,

Autodesk Revit, Graphisoft ArchiCAD, Bentley Tri-

forma, Design Data SDS/2, Tekla Xsteel). These hold

the potential to make modeling of buildings and their

subsystems, such as precast concrete structures, cost

effective, thus opening the door to many additional

design, production and erection benefits.

This paper surveys technical issues associated with

the use of parametric solid modeling to design build-

ings at construction levels of detail. It begins with a

review of solid and parametric modeling concepts and

software, describing their essential features as they

apply to the building industry. Several examples are

reviewed. We then detail a range of issues that must

be considered in any implementation of parametric

modeling software for building design and construc-

tion. The issues focus on the specific characteristics of

building design. The first set is applicable to computer

modeling of buildings in general; the second set

relates specifically to parametric modeling. An exam-

ple of a parametric model of a small precast concrete

assembly is presented to illustrate some of the issues

discussed. The work is based upon the authors’

involvement with the North American Precast Con-

crete Software Consortium’s (PCSC) specification of

a software system for integration and automation of its

engineering design procedures [8]. Although the

examples are drawn from the realm of precast con-

crete, the discussion applies in principle to other

sectors of the construction industry.

2. Solid and parametric modeling

2.1. Early solid modeling

The manufacturing and aerospace industries began

using three-dimensional computer-aided design

(CAD) systems based on surface modeling in the

early 1970s. These industries recognized that accurate

representation of a part’s geometry could lead to

automatic analysis of the part’s behavior (structural,

thermal, acoustic, etc.) and support its automated

fabrication. However, defining the 3D shape of a

mechanical part was very complicated, tedious and

error prone, requiring cutting and trimming of each

individual surface to match with the others it inter-

sected. In the mid-1970s, the work of Braid [3],

Requicha and Voelcker [26] and others led to the

development of solid modeling. Solid modeling pro-

vided for the representation of volume-enclosing sets

of surfaces and powerful editing operations that

allowed single operations for gluing shapes together

or subtracting one shape from another, while preserv-

ing volume-enclosing properties [1,18]. Solid model-

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 293

ing operations combined with curved surface editing

of the solid’s faces (their bounded surfaces) allowed

easy definition of any 3D shape on a computer and

enabled assembly of multiple shapes. Solid modeling

allowed many of the original goals of 3D CAD to be

realized: accurate representation of a three-dimension-

al shape; automatic derivation of any shape measure-

ment, including volume and surface areas; cutting of

sections, including automatic derivation of section

properties; automatic drawing generation of parts or

assemblies, with automatic dimensioning. Solid mod-

eling also allowed automatic checking of spatial

interferences between assemblies, and with fully de-

fined shapes, sufficient information was available to

support numerical control machining or other fabrica-

tion processes.

Early solid modeling CAD systems were brought

to the AEC market in the 1980s (RUCAPS, Calma,

TriCad, PDMS) but were generally unsuccessful.

They were highly complex, required an approach to

design quite different to that to which designers were

accustomed, were unreliable and required expensive

hardware. They suffered a number of drawbacks from

the point of view of building design:

– While solid modeling intuitively supported defi-

nition of an accurate geometric model of a part, it

was not obvious how it should be used to design

large assemblies, as required in buildings.

– Revising a solid model could be tedious; moving

an opening in a wall required filling in the existing

opening (with an addition operation) and subtract-

ing a new opening in a second operation.

– Defining 3D solid shapes required significantly

more effort than defining equivalent 2D drawing

representations using simpler and cheaper systems.

As a result, even though 3D modeling systems

were developed during the same period as early

CADD systems, CADD was the technology adopted

for building design and construction.

2.2. Development of parametric modeling systems

One of the approaches to solid modeling was based

on the representation of shapes as algebraic formula-

tions of solid primitives (e.g., cylinder, box, wedge).

The primitives could be combined using the set

operations of union, intersection and subtraction in

an algebraic expression. Evaluating the expression

generated a temporary solid model in memory, but it

was not stored. This representation was very compact

and easily edited [25], but could not support some

operations, such as taking any arbitrary measurement.

It was called constructive solid geometry (CSG), as

distinguished from classical solid modeling of the

bounded surfaces, which was called boundary repre-

sentation or B-rep.

Developers of B-rep systems realized that they too

could benefit by recording the operations carried out

to create a solid model. Instead of editing the model

directly, some operations were more easily imple-

mented by editing the operations on a history log

and then recreating the object. The CSG expression

was called the unevaluated model, and the boundary

representation generated from it was called the eval-

uated model [26]. Later, the ability to explicitly

reference parameters that defined earlier operations

from within subsequent operations was added, leading

to the development of what are now called parametric

solid modeling systems [14].

The concept of parametric modeling was not new;

some of these capabilities were embedded in the very

first CAD system, Sketchpad [33]. However, exploi-

tation of the power of this capability has evolved

slowly, as knowledge of desired CAD system behav-

ior has grown, and as the significant computing power

required for the complex computations necessary to

derive assemblies of shapes automatically has become

more readily available. In order to define assemblies

of shapes, people utilized additional capabilities: in

addition to solid shapes, they relied on 2-D shapes for

grid lines, dimensions and other construction elements

[7]. Grid lines allowed definition of the location of

solids relative to them (on or offset from grid inter-

sections). Dimensions provided controls for varying

the shapes of the primitives that that were added and

subtracted to construct a solid model.

Parametrics greatly expanded the ease of use of

solid modeling. Rules that could act as design con-

straints were added to early parametric solid modelers

to guide the regeneration of a design in light of

different local conditions. For example, a rule could

be defined and applied to insure that a hole intended

for a bolt would be resized correctly if the diameter of

the bolt itself was changed. For building design, this

R. Sacks et al. / Automation in Construction 13 (2004) 291–312294

means that instead of composing a building assembly

as a collection of instances of typical parts with fixed

geometry, the geometry of each part can be derived

from the spatial relationships between it, its neighbors

and the building grid. In this way, changes to any of

the parameters defining grids or spacing can be

propagated to all the parts automatically.

Fig. 1a illustrates the principle—the beam is auto-

matically sized to fit between the columns, and the

corbel supports are automatically sized to fit the beam

span. Any change made to any of the independent

dimensions (lAB, w1, w2 or c) will result in propaga-

tion of the change to the beam and to the supports. In

addition, if the beam is removed, the supports are

automatically removed (recognition of connections

between pieces as a separate logical entity is crucial

to enabling this behavior).

Fig. 1. Parametric model of a be

Note that in parametric CAD systems, shapes are

not only initially generated based on operations and

constraints; the constraints are also maintained as an

integral part of the model geometry during editing.

This allows expression of the intended dynamic

design behavior of the objects. In this context, we

define ‘‘behavior’’ as ‘‘automatic system actions that

maintain the topological and geometrical consistency

to the relationships within and between model

objects.’’ In Fig. 1b, if the column is rotated (a user

action), then the system will automatically reposition,

reshape and resize the beam (a system reaction) to

restore conformance to constraints 1 and 2. In non-

parametric systems, rules may be imposed when

shapes are generated, but are not applied once the

shape is inserted. (For example, in AutoCADR [Auto-

desk], a nonparametric modeler, a line can be drawn

am between two columns.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 295

perpendicular to another line, but the relationship

between the two lines is not maintained by the system

in the event that either line’s orientation is changed.)

Parametric modeling enables modelers to build and

refine complex model assemblies with ease. The

operations on solids typically apply to two shapes at

a time (‘‘intersect shape A and shape B’’), and these

are considered topologically related. Other operations

are unary (‘‘chamfer this edge’’). Rules between

variables and shapes define additional topological

relations; for example, the equations in Fig. 1 relate

the columns to the grid, the beam to the column and

the grid and the corbels (beam supports) to the beam,

the column and the grid. An important issue is that

when certain solid modeling operations are applied

between shapes, the relations among the surfaces

making up the shapes may change. Shah and Mantyla

[32] describe the evaluation procedure, from the point

of view of implementation, including definition of

topology, definition and application of constraints and

evaluation of the model. Evaluating a model can be

complex in situations where constraints conflict with

one another (the model is termed ‘over-defined’), or

where they do not define a unique result (the model is

termed ‘under-defined’). Most systems alert the user

to such conditions, requesting resolution before the

model is fully evaluated (e.g., SolidworksR).Parametric modeling makes a significant contribu-

tion to design in that, along with solid modeling, it

allows modelers to generate computer representations

of physical objects not only as they look, but also to

define semantic relationships between the objects’

representations, allowing them to be easily created

and edited. The relationships define necessary topo-

logical relations among the objects making up a

system, defining a graph of relations expressing how

the different parts of an assembly ought to be derived.

In parametric modeling, the graph is a depiction of

design intent. For example, the simple model in Fig. 1

specifies the intent regarding the size of the haunches

the beam sits on, and that the spacing between column

and beam is to be generated by shortening the length

of the beam, rather than notching the column.

In these ways, parametric modeling software appli-

cations dedicated to specific design domains define

relations and constraints to express the logic of design

conditions. Using this technology, assembly relations

can be defined, which enable rapid definition of

complex assemblies and their quick and effective

revision. This structure releases the designer from

the onerous task of maintaining the logic of the design

intent and the resulting integrity of the model. Para-

metric modelers therefore contribute greatly to mak-

ing entry and maintenance of solid models of complex

assemblies, such as buildings, a realistic endeavor.

Today, a growing number of parametric modeling

systems exist in the architectural market that capitalize

on these benefits (among them, Bentley Triforma,

Graphisoft ArchiCad and Autodesk Revit).

3. General considerations for computer modeling

of buildings

The following characteristics apply not only to

parametric modeling; they are desirable for any prac-

tical building modeling system. In the case of para-

metric modelers, however, they are essential condi-

tions for realization of the benefits that can be achieved

by implementing the functionality outlined in the

previous section.

3.1. Maintaining a ‘single-source’ model

The driving principle behind modeling buildings

rather than representing them in drawings is the

opportunity to represent all design and fabrication

information in a single integrated source. Irrespective

of the view in which a user edits the model, the

changes are propagated to the single source and are

accurately reflected in all other possible views. In this

sense, assembly and detail drawings, bills of material

and other production documents are relegated to the

status of reports. These reports are all guaranteed to be

consistent, and cross-checking across all data is easy

and can potentially be automated. They are not stores

of the information as they are in traditional CADD.

This principle is maintained in most parametric solid

modeling systems and is considered essential for

eliminating coordination errors.

Insuring that a single source will be maintained

implies that the system must provide automated rou-

tines to generate the production documents, including

plans, elevations, sections, details and reports. If prep-

aration of documents is not automated and remains a

time-consuming task, users will prefer to make changes

R. Sacks et al. / Automation in Construction 13 (2004) 291–312296

directly on drawings rather than editing the model and

redrawing all of the documents. This invalidates the

model, as it is not updated. A common issue, in this

regard, is the current ease of revising a drawing or any

other report locally without adding the change to the

central model. Some systems support such capabilities,

but the effect is that the changes are made without any

form of auditing or permanent record.

3.2. Scope

For any construction domain, the goal of replacing

paper drawings with digital models requires that the

application used to instantiate and modify the design

information must completely cover the scope of

assemblies and components used in the building

being modeled within a particular organization. If

any element cannot be modeled, users are forced to

add the missing data on paper printouts, thus violat-

ing the principle of maintaining one repository for the

data. On the other hand, no single application can be

expected to provide all of the diverse design, analy-

sis, detailing and other functionality that might be

needed to develop meaningful models of real build-

ings for all types of companies, in regions with

different climatic and code requirements. In the

precast development, this is one of the reasons for

the concept of a precast parametric platform with

independently provided plug-in applications, as op-

posed to a comprehensive precast parametric appli-

cation. The platform architecture proposed for the

Fig. 2. Software system architecture for prec

PCSC (see Fig. 2) is designed to support plug-in

software modules to be developed by independent

software providers. The basic requirement for the

parametric platform is that its data structures and

types and its geometric operations must support the

full scope of real-life objects that are incorporated in

a precast concrete building.

4. Special considerations for parametric modeling

of buildings

In building design, priority is given to integra-

tion across different systems and assemblies; in

mechanical design, priority is often placed on

optimization of individual components for mass

production. This influences the functional and per-

formance requirements of parametric CAD systems

for building design, when compared with the design

of mechanical parts. Firstly, buildings are composed

of very large numbers of distinct parts, arranged in

various functional and production-specific assem-

blies, all of which must be modeled if the integrity

of a design is to be maintained. Many of the parts

are identical to other parts and used repetitively,

although minor variations between specific instan-

ces are common. Secondly, certain relations be-

tween building components hold true in the

general case for all buildings (e.g., doors must be

set within walls) and can be embedded in a

parametric building modeler. These are typically

ast concrete design and production [8].

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 297

different to the relations that are emphasized in

tools for mechanical design. This section details

specific technical considerations for successful imple-

mentation of parametric modeling software for build-

ings in general and for precast concrete construction in

particular.

4.1. Top-down vs. bottom-up modeling

Parametric solid modeling can be structured to

support top-down or bottom-up modeling. In this

context, we use the following definitions:

– Bottom-up modeling starts with explicit representa-

tion of distinct parts, with parametric relations

defining the details and components of those parts,

followed by successive association of the parts to

form aggregated assemblies.

– Top-down modeling is the explicit definition of a

total product, and then refinement of the product

design by iteratively replacing objects that repre-

sent whole assemblies with successively finer

grained parts until the level of detail required for

production is achieved.

In most engineering disciplines, such as the aero-

space and automotive industries, the performance

limitations of parametric systems and the complexity

of individual pieces traditionally restrict their use to

bottom-up modeling, rather than for modeling com-

plete assemblies. The computer systems and modeling

software used for the overall product and for detailing

the parts are typically quite different. Although the

overall shape and configuration of the product is

designed conceptually (i.e., top-down) and the perfor-

mance of the airplane or automobile is tuned at this

level, the individual pieces that make up the compo-

nents of the assembly are modeled separately, albeit

parametrically. Representation of all the individual

parts in one large aircraft assembly model, which is

not commonly done, required an array of mainframe

computers [2].

Building design benefits from both top-down and

bottom-up approaches in different contexts and at

different stages. Most buildings are one of a kind,

custom designed. During conceptual design, the

overall form and size of the building are set, design

progresses as functional systems are defined, and

lastly, individual components can be detailed. The

local geometry of each component is set to satisfy

the form and functional constraints imposed by its

position and role in the assembly of which it is a

part. In this case, the whole (or major aspects) of the

overall parametric model need to be related, allowing

revision and potential regeneration. This requires that

software support a top-down modeling approach.

Top-down parametric modeling of buildings imposes

corollary requirements—in terms of performance and

embedded behavior—that, given current hardware

capabilities, cannot be practically met by current

parametric mechanical computer-aided design sys-

tems (this is discussed in detail in Section 4.8

below).

In all areas of design, considerations of economy

make the use of standard ‘‘off-the-shelf’’ compo-

nents important. This is especially true of buildings.

For standard parts, the assembly must be adapted to

accommodate them, requiring bottom-up functional-

ity. Careful consideration of the rules and con-

straints must be given wherever such functionality

is required within an essentially top-down modeling

system. For example, if the corbel in Fig. 1 were

only available in standard widths (values of wc), the

rules would have to be redefined not only to enable

discrete selection of an appropriate corbel for each

location, but to rationalize the selection of multiple

corbels. While bottom-up design is more common

at the detailed design level, some industrialized

building systems are based entirely on bottom-up

design at the scale of the complete structure [35]. It

is worth noting that most artifacts, including build-

ings, are eventually produced and/or assembled

bottom up.

An intensive investigation of design and produc-

tion processes carried out by the PCSC [27–29] has

shown that the generic design process for precast

concrete projects can be broken down into three main

stages: assembly layout, assembly detail and piece

detailing (Fig. 3). The first two stages require top-

down modeling functionality; first, the overall layout

is defined, and the assemblies are fitted to the con-

ceptual layout; next, the assemblies are broken out

into individual pieces, and their shapes are defined to

fit all neighboring pieces. In the final stage, bottom-up

modeling is necessary, as standard components such

as lifting hooks, prestressing strands, connection

Fig. 3. The process of precast design.

2 Building walls in architectural design systems are a well-

understood example of such functional objects (e.g., Ref. [36]). The

walls grow or shrink in response to the movement of connecting

walls, floors and ceilings. Windows and doors inserted into the walls

are also updated automatically and attempt to maintain the intent of

their original location—a fixed distance from a sidewall, axial

symmetry, etc. Such behavior, in slightly varying forms, is embedded

in most current generation architectural parametric solid modelers.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312298

plates and reinforcing bars are detailed to fit in the

concrete pieces.

4.2. Modeling function

Parametric solid modeling allows representation of

functional relations between parts as well as geomet-

ric relations. The functional properties of building

parts include structural, thermal, acoustic, safety and

other well-defined criteria (potentially including aes-

thetic criteria). Parametric behavior, implemented

with attributes and topological relations, defines the

way in which parts will interact with one another in

support of their function. For example, the function

of a structural spanning element is to accept loads

and transfer them to columns, walls or to higher order

spanning parts; its parametric behavior must insure

that it always be supported by at least two supports

(or one fixed support for a cantilever.) Fig. 1 reflects

this behavior. A window-to-wall joint is another

example: its function is to insulate the joint against

transfer of heat, moisture and sound and to provide

structural rigidity to the window. As such, its para-

metric behavior must insure that it is always

connected to both a wall and a window and extend

through the full perimeter of their contact. In each of

these examples, different specific solutions, with

different geometric details, may be developed to

satisfy the same functional requirements. Beams

may be of different materials, cross-sections, etc.;

window-to-wall joints will involve different techno-

logical solutions depending on the window and wall

materials and their geometry. Despite the variation in

possible solutions, the same functional behavior is

required.

How to satisfy these relations between objects in

response to one or more functions is an important kind

of design expertise. Functional knowledge of this

nature can be embedded in parametric solid modeling

software.2 The resulting software can select, apply and

adjust object relations in response to various condi-

tions, either as an initial layout, or later when the

design is revised. It also allows the capture of best

practice and systematic refinement of those practices.

Thus, functional behavior in objects enables users to

assemble 3D building models quickly and accurately,

greatly expediting design development and revisions.

It also enables automated matching of analysis meth-

ods to building assemblies, and the functional require-

ments against which analysis results must be com-

pared can be stored. When alternative technical

solutions to any part or assembly are sought, the

parametric objects determine the scope of alternatives

that can be applied.

Additional examples of functional behaviors that

could be programmed into objects include

� the ‘external envelope’ of a building with thermal

transfer, self-shading and enclosure; parametric

behavior insures that the envelope encloses a space

completely, and the object carries properties

necessary for energy analysis;� piping systems that have given flow requirements;

they resize themselves in response to routing

changes and detail themselves in response to given

connections;� stairways, which connect building floors with runs

and landings, where a run is a sequence of risers

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 299

and treads; risers, treads and landings must adjust

to code and good practice requirements.

Since the behavior can be defined parametrically,

that is, as variable rather than fixed values, many

details can be user controlled, such as spacing, sizes,

etc. For example, the size of a door and its offset from

the end of the wall in which it is located can be easily

varied. However, if the range of solutions that can be

generated excludes a specific case that a designer

wants, or the object itself is to be a new case, these

capabilities become a limitation, rather than a help.

Users trying to customize such parametric details find

they are fighting the system, rather than working with

it. It must be possible to override such object behav-

ior. More generally, it should be possible to customize

such object behavior and extend it.

4.3. Abstract functional objects

In order to make such functional behavior open-

ended, the behavior can be abstracted and represented

separately from the objects whose behavior they

define. This allows the behavior to be applied to

new object geometry and, when desired, to revise

the behavior. We call the objects that carry the

functional behavior alone abstract functional objects

(AFOs). AFOs represent, store and implement the

functional properties of building assemblies and parts

and carry their fundamental parametric behavior and

design intent. Similar constructs have been proposed

for use in contexts other than parametric modeling,

such as building product modeling [12], automated

development of early design alternatives [11] and

automated structural assembly layout [31]. The ‘con-

tainer spaces and functional features’ defined by

Csabai et al. [5] for top-down 3D layout design in

mechanical engineering reflect similar intent.

AFOs can be provided to users in parametric

modeling systems as abstract classes from which parts

with geometric form inherit function and behavior. In

most cases, predefined generic or specific parts may

be laid out in a design, with the parts carrying the

functional and physical definitions together. However,

if a custom part or means to realize some function is

desired, then the AFO provides an open-ended way to

realize that function within a new object class. AFOs

are expressed in the model as objects with attributes

and methods that define or can check their function;

they must also encapsulate the behavior of any new

object class they define, so that objects of the new

class will ‘know’ how to lay themselves out and

update themselves whenever their parameter values

are changed.

In a sense, we propose that 3D parametric building

modeling systems be viewed as collections of pre-

defined abstract functional objects, with embedded

analytical capabilities, that include an initial library of

the common physical objects that embody them.

Sophisticated users should be able to define new

physical objects that incorporate the functionality of

existing functional objects by using the AFOs to

define new objects and behavior (as new subclasses

with new or refined methods).

We distinguish between AFOs and abstract anal-

ysis objects (AAOs), which are often used to represent

real objects for engineering analysis, such as ‘stick-

and-node’ representations [4,15,19]. AFOs express

the function and design intent of physical objects that

have structure; AAOs are simply convenient ideal-

izations of real-world systems that are required by

specific analysis techniques. In general, AAOs are not

manipulated directly by users, but are generated—and

deleted—within analysis software modules. Examples

of AAOs include idealized diaphragms and shear

walls for structural analysis, space boundaries and

mass concentrations for thermal analysis and finite

and boundary elements for various analyses.

The difficulties inherent in separating the function-

al and physical aspects of objects representing build-

ing parts are apparent in the example of structural

connections between precast concrete pieces. They

could be modeled simply as relationships between

structural elements [15,24], although a more useful

representation is achieved by objectifying the rela-

tionship such that connections are modeled as distinct

objects. If a connection object inherits the functional

behavior of a ‘structural connection AFO,’ then when

first instantiated, it can apply topological relationships

between the pieces it connects and model structural

behavior for analysis. Once reactions are calculated, it

can be detailed in terms of distinct physical compo-

nents (the steel plates and other components with

which they are fabricated) and in terms of the geo-

metric relationships between its components and the

pieces they connect. It is worthwhile noting that

Fig. 5. Parametric dimensions of a spandrel beam.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312300

connections per se are not built as distinct physical

objects, but rather have their components embedded

in the pieces that they connect, as shown in Fig. 4.

4.4. Embedding contextual design intent

The ability to constrain the shape, size, composi-

tion, location and orientation of pieces and connec-

tions enables designers to embed their intent in

parametric building models. The first level of design

intent is the explicit function of the objects them-

selves, as described above. A second, higher order

level can be defined for situations in which a semantic

relationship between building parts can be inferred

from their spatial context. Minimum headroom be-

tween a floor and any object overhead, minimum

corridor widths for egress and maximum slope for a

floor required to serve as a ramp are examples of

these. Software should enable designers to apply this

type of design intent in terms of dimensional con-

straints driven by equations or in terms of offset

mating relationships between elements. Consider, for

example, the spandrel beam in Fig. 5: if the designer

intends that the spandrel function as a railing above

the slab, then the full depth of the spandrel could be

constrained using an equation (note that the transverse

beam is assumed to be functionally constrained to rest

on the spandrel ledge):

d1 ¼ rmin þ d2 þ d3 ð1Þ

where d1 = spandrel depth, d2 = ledge depth, d3 = beam

depth and rmin =minimum railing height.

Fig. 4. Precast corbel connection: (a) a

Any change in the depth of either the ledge or the

beam would cause the spandrel to be updated such

that the railing height is kept constant at its minimum

allowed value. Similarly, constraints can be used to

ensure axial loading conditions between pieces and

within connections, e.g., the axis of a beam along its

base might be constrained to be collinear with the

centers of the bearing pads of the corbels on which it

rests.

However, design intent may vary from one project

to another, even for similar design situations. Thus,

careful consideration must be given to selecting con-

straints for automated insertion by design software.

An additional problem is that in certain cases, design

intents may conflict with one another—attempts to

model conflicting constraints will result in an over-

defined parametric model. In such situations, design-

ers must select which constraints to apply and which

to release. The spandrel beam in Fig. 5 provides an

example. The construction plane defining the second

s designed and (b) as fabricated.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 301

floor has been set at a height of H ( = L1� L0) above

the ground, and the depths of the beam (d3) and the

ledge (d2) are set according to strength or stiffness

requirements; the clear height between the ground and

the base of the spandrel beam (hc) is therefore a

derived value. In this situation, a minimum clear

height requirement cannot be implemented as a para-

metric constraint.

An alternative is to use specialized error-check-

ing functions to detect such problems as clear

height for vehicles, minimum headroom in stair-

cases, sufficient sloping for drainage, etc. Post hoc

functional evaluation is appropriate for handling

effects that span multiple assemblies, including

nonadjacent and potentially nonstandard parts and

arrangements, but it requires that any evaluation

software be able to recognize the parts relevant to

it. On the other hand, it has shortcomings: the

functions must be preprogrammed, and they are

prone to human error because the operator must

call them. Resolving conflicts of this nature will

often require adaptive change and not simply di-

mensional change; if the floor-to-floor height in Fig.

5 cannot be increased, an alternative (shallower)

mechanism must be found for supporting the beam

on the spandrel.

Care must be taken in setting up constraints that

implement either functional behavior or design in-

tent. In most cases, there is more than one way in

which a parametric constraint can be responded to.

However, a software designer embedding intent

through rule-based or other automated routines can-

not predict a priori all of the possible design config-

urations that could arise in practice. Selecting the

correct constraints to implement demands careful

analysis of the relationships between parts and the

ways in which the relationships change in different

design contexts. A trade-off exists between the

necessity to automate insertion of constraints be-

tween parts as far as possible on the one hand, and

on the other, the need to leave final control in the

hands of the user for situations in which nonstandard

design solutions are appropriate. For example, a

common situation in precast design arises when

pieces intersect spatially as they are placed in an

assembly. In practice, one must be cut away (in fact,

it must be defined with a block out to effect the cut)

to accommodate the other. Applying a cutting profile

to the cut piece is one possibility, but in fact, the

cutting profile is dependent on the location and shape

of the full piece and must be positioned at a specified

clearance distance from it. A straightforward solution

is to generate an ‘envelope’ around each piece and

then apply cuts from that envelope to any intersect-

ing piece according to a set of priority rules (e.g., a

column would always ‘cut’ a hole in a double tee).

While the default solution would be applied in

accordance with a rule set, the user must be able to

override that solution and apply a different one in

certain situations.

4.5. Design automation

A parametric building modeling system, as out-

lined up to this point, would provide all the func-

tionality needed to quickly define a building design.

For example, in the case of a precast concrete

structure, a designer could establish a grid, select

and insert building elements relative to the grid, size

all the pieces, select and place connections, set

reinforcing parameters for each part, layout external

systems that intersect with precast pieces and so

forth. The model can then be adjusted by changing

parameter values at any level—any geometric adap-

tation required to maintain integrity is handled auto-

matically by the system. This facilitates exploration

of design alternatives, potentially enhancing the qual-

ity of the resulting design. Drawing production can

also be almost entirely automated. Together with

automatic maintenance of integrity, this can contrib-

ute to significant reductions in engineering and draft-

ing hours and in human error related to production

drafting [28].

However, much more automation is possible. Con-

sider three levels of building design, in order of

increasing degrees of sophistication.

4.5.1. Piece and connection design

Standard engineering analysis and design calcula-

tion methods exist for a wide variety of building

components. These are typically encoded in building

regulations and design handbooks, and software mod-

ules are available for many of them; for example,

there are multiple existing applications to calculate the

prestress strand required for various cross-sections

under user-defined loading conditions. Such applica-

R. Sacks et al. / Automation in Con302

tions can easily be linked to read and write parameter

values to a precast piece object, allowing the piece to

‘design itself’ automatically. In a more integrated

solution, using AFOs as a basis, these existing soft-

ware modules can be adapted to function directly as

methods of the objects. For example, a corbel con-

nection object, as typified in Fig. 6, has well-defined

structural analysis procedures that could be invoked to

set its dimensions and its rebar and steel plate com-

ponents automatically, based on the loads it must

carry. Libraries of such objects can be maintained at

the operational level of individual projects, across a

company, or at the level of an entire sector of the

building industry. Because building parts and assem-

blies may differ from company to company or from

region to region, parametric modeling software must

allow for efficient definition of new products, con-

nections and features.

4.5.2. Assembly level engineering analysis

If loads and loading conditions are applied directly

to the building model, the input for structural (and

other) analysis can be prepared and transferred auto-

matically. The resulting reactions can then be sent

back to the parametric model, where they form the

basis for automated refinement of the design param-

eters of the individual pieces and connections. This

greatly reduces the amount of engineering work

required. This practice has already been implemented

in structural steel packages (e.g., Tekla Xsteel and

Design Data SDS/2).

Fig. 6. Library representation of a corb

4.5.3. Knowledge-based assembly layout

For repetitive and rule-driven design work, a floor

system, a building core, or even in some cases an

entire building could be laid out automatically, from

only a few simple parameters. For example, a typical

all-precast parking garage can be specified based on

building site perimeter, maximum number of levels

and the desired number of parking spaces (other

parameters, such as parking bay size, traffic clearan-

ces, minimum headroom requirements, etc., are all

driven by building regulations that can be encoded).

Automated high-level layout and analysis of this

nature has long been a goal of computer-integrated

construction research. Prototype implementations such

as HI-RISE [17], IBDE [10], SEED [11] and ABS [30]

all explored automated building design. The lack of a

parametric building modeling platform to build upon,

together with the limited performance of earlier hard-

ware generations, were major impediments to com-

mercializing these efforts. The recent development of

fully parametric 3D building modeling platforms and

the recent increases in hardware performance may

therefore open the way to production implementation

of high-level design automation. Some aspects will of

course require further research, as discussed in the next

section.

4.6. Limits on parametric dependencies

We are proposing parametric solid models of

buildings that have deeper chains of recomputation

struction 13 (2004) 291–312

el connection (Tekla Xengineer).

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 303

dependencies than have generally been applied to

date. These have the computational cost implications

already discussed, but they also have definitional

complexities. There are logical limits to the extent to

which automated design and embedded design intent

can be imposed using parametric dependencies.

Three distinct techniques can be applied to change

a design model [21]: parametric adaptation, substitu-

tion of a part and topological adaptation. The first

level of change, parametric adaptation, is straightfor-

ward: for example, a precast concrete slab section

could have its depth set to a mathematical function

dependent on other geometrical parameters, such as its

clear span (as shown in Figs. 1 and 3). Substitution of

a part requires more sophisticated rules, but can also

be implemented, e.g., a specific connection used to

connect the slab to a supporting wall could be

replaced with a different connection when the load

to be transferred exceeds a certain value. Topological

adaptation, on the other hand, cannot be implemented

using the first two methods and requires replacement

of a module (incorporating one topology) with a

different module (incorporating another topology),

which requires human intervention. The intended

design behavior for a double tee support illustrates

this limitation.

The two stems of a double tee floor sections are

commonly supported in ‘pocket connections’ recessed

into a spandrel beam. As the stem depth increases, the

pocket depth must increase. At some point, the

stresses in the beam preclude cutting away for the

pocket, and so a ‘corbel connection’ (a support which

protrudes from the supporting member, as in Fig. 6) is

often substituted to support the extreme stem of a field

of double tees. However, should the load that must be

transferred increase more, engineers often decide to

shift the double tee (or enlarge the column), in order

to support the double tee stem directly on the adjacent

column, instead of transferring the load through

the beam first. This is a topological change, with

implications beyond the local scope of the elements

involved.

Topological changes can be automated if the rules

for selecting and changing between different topolog-

ical structures can be specified. Engineers learn about

the boundary conditions defining the limits within

which a particular calculation is appropriate; similarly,

a parametric model has boundary conditions, which

have to be included within any modeling structure.

Thus, a building model could be broken into a large

set of layout modules, each of which includes AFOs

and their physical design subtypes, with each module

able to maintain its own integrity. Small adjustments

can be automatically recomputed, but larger changes

will require human judgment to deal with part substi-

tution within a module or with the effects of topolog-

ical change between modules. However, the expertise

regarding rules for parametric boundary conditions is

not widely available and will become a growing area

of research. Progress in this area will require resolu-

tion of a number of open issues:

– What is the optimum nature of layout modules?

They may simply be assemblies of parts with sets

of topological relations embedded by inheritance

from AFOs, or they may be abstract assembly

constructs with different AFOs assigned to them,

and to which physical objects that correspond to

the AFOs can be assigned.

– What are the appropriate breakpoints between

layout modules? Breakpoints define the ways in

which building parts should be grouped in

assembly layout modules, such that integrity of

the design can be maintained through wide ranges

of parameter values.

– What techniques can be used to deal with the

boundary conditions at the breakpoints and to

include them in the parametric behavior? At

breakpoints, simple parametric adaptation can no

longer maintain integrity—part substitution or

topological change is necessary. The techniques

may include context-specific algorithmic or rule-

based approaches or more sophisticated AI

techniques.

– What topological relations need to be established

between the AFO-based objects across breakpoints

between layout modules, and how can their

integrity be maintained?

4.7. Identity, collections and change propagation

The use of multiple identical or near-identical parts

in any given building, such as doors, windows,

structural elements, stairs and many others, is com-

mon. Similarity tends to reduce design, production

and maintenance unit costs. Thus, a design tool must

R. Sacks et al. / Automation in Construction 13 (2004) 291–312304

enable management and tracking of series of parts.

The way in which collections of identical parts are

modeled in CAD systems has bearing on the size of

the data store, as well as on the functionality the

system provides. In precast concrete, groups of iden-

tical pieces are termed ‘piece-marks.’3 At least four

strategies are possible for managing identical or nearly

identical parts:

1. All parts retain their own identity and can

therefore be edited independently. The disadvantages

of this strategy are that any edits common to a group

of identical parts must be made separately to each

instance, and the maximum amount of memory is

required. Identical objects must be identified and

collected after design is complete.

2. A single definition is stored in a non-displayed

section of the model for all identical parts in a

collection. Each instance is an exact copy of the

original with its own geometric transformation. Geo-

metric variation of an individual part can only be

achieved by disassociating the instance from its orig-

inal. The user explicitly groups the original unit

definitions.

3. As in strategy 2, a single definition is stored and

original units are pre-grouped, but three improve-

ments are incorporated: (a) parametric variations of

any of an original unit’s defining dimensions are

allowed, (b) the general part model is defined as a

set of features and (c) each part instance references

the set of features it includes and its particular pa-

rameters (sometimes called a configuration of the

original unit). In this context, features are ‘semanti-

cally significant and distinct entities’ [32] and can

express both geometry and nongeometric attributes

(such as material). Each configuration can set features

to be present or absent and can apply independent

values to any subset of the parameters of the original

unit.

4. Every displayed object is independent, but each

is a composite of one or more instanced parametric

3 ‘Piece-marks’ are groups of identical precast concrete pieces.

The term is derived from the annotation that is commonly ‘marked

on the piece.’ Two levels are possible—pieces with only minor

variations in geometry can be grouped for production runs, while

only identical pieces are interchangeable in terms of the locations

they can occupy in the building. The product type is often also

encoded in the piece-mark text.

features. Unlike in strategies 2 and 3, there is no pre-

grouping of original units. The features are instanced

in the non-displayed part of the data model and

incorporated in composite objects in the assembly.

Individual objects in a model are grouped by asso-

ciation with identical features, not with identical

parts. For example, a set of beams may all have

identical cross-section, but some may have holes in

them and others not. Any change to the cross-section

is automatically propagated to all members of the

collection; on the other hand, holes could be added

to each independently. Changes to a composite

object may involve changes to one or more of its

instanced features. If any change results in a new

instance of a feature that is identical to an existing

feature instance, the new instance is not created;

instead, the change is made by redirecting the

reference from the composite object to the existing

feature instance.

The first strategy is rarely used. The second

strategy is common in nonparametric CAD systems

(as defined above). The third and fourth are relevant

for parametric systems for modeling buildings. They

differ in (a) the ways in which similar parts of a

building can be edited within the context of an

assembly, including the functionality they enable

for editing parts and propagating edits to similar

parts and (b) in how they enable grouping of parts

for design and prefabrication or production on site.

In systems of the third type, the user is responsible

for initiating and maintaining collections of parts.

When inserting a new instance of a product in an

assembly, the user can choose to create an entirely

new part, a new configuration of an existing part, or

to simply add a new instance by reference. The

resulting structure directly determines the grouping

of identical parts for production. This can be oner-

ous: when a local change is made to a part, that part

must be separated from its group, and a new indi-

vidual part must be generated. Edits to any part are

automatically propagated to all instances of that part

in a building assembly. This has advantages and

disadvantages. Propagation of changes is efficient,

assuming it is desired; however, it can be argued that

editing at the part level, with automatic propagation

of changes to all identical parts, can result in

nonsensical designs because while making changes

to the ‘master’ part, the user is unaware of the impact

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 305

of the change in the context of each part in the

assembly.

In systems employing the fourth strategy, most

editing is performed at the assembly level. Collection

of parts into production groups can be delayed until

design is essentially complete. Automated functions

based on user-defined rules can identify all identical

parts and assign them the same production identifier

(in precast concrete construction, a ‘piece-mark’). In

general, production groups will include all parts that

reference a subset of identical feature instances (i.e.,

they are identical in all respects significant for pro-

duction, while they may vary in minor ways that can

be effected after mass production). For example, all

columns of the same cross-section and length could be

grouped for production, despite the fact that only

some of them have corbels added to support beams.

Because parts are defined as collections of parametric

features, the memory requirements for this method

can be very compact. This is similar to the approach

explored by Hakim and Garrett [13] using description

logic.

While the last two strategies for maintaining group-

ings of similar parts are both effective in dealing with

building components during design and production,

each has a quite different style of use.

4.8. Performance

The complexity of buildings, both in terms of the

sheer number of individual parts and the multitude

of constraints and dependencies between them,

makes performance a key concern for viable para-

metric 3D modeling of buildings with top-down

functionality (see Section 4.1). Each time a change

is made to any dimension or feature of a parametric

model, the software must reevaluate all of the

affected constraints and relations in order to update

the properties and the geometric form of the model

to a newly consistent state. The computational

intensity of reevaluation grows geometrically with

the growth in the numbers of constituent parts and

relational constraints in a parametric model. This has

been a limiting factor in the past, and some systems

delay reevaluation until the user explicitly initiates

reevaluation.

In the authors’ review of the proposals of candidate

CAD platforms to serve as a platform for a precast

concrete parametric modeling system, a test was

prepared to benchmark the performance of different

systems. In preparation for the benchmark test, a

precast concrete parking garage structure was ana-

lyzed in detail in order to determine the full number of

distinct parts it contains. The building has four floors

with a total of 18,161 m2 floor space and contains 497

precast pieces. It is relatively simple in that it has no

interior partitioning, no finishes and no window or

door details. The total number of distinct parts—

precast pieces, connection plates, reinforcing bars,

prestress strands, bearing pads, etc. in this building

is 33,182.

The test required modeling of a typical bay of a

hypothetical precast garage (similar in configuration

to the building described above), with four floors of

double tee pieces supported on inverted tee beams,

which rested on corbels on four corner columns (Fig.

7). The test specification required that the structural

connections be modeled with parametric relations,

such that changes in column locations would be

propagated to change the beams and double tees

appropriately. This bay was then replicated 1,000

times, resulting in a structure with 21,601 pieces

(the large number of precast pieces compensates for

the fact that no internal detail was required for any of

them). At each stage, local changes to pieces were

prescribed, such as cutting holes through them, mov-

ing one row of columns, moving an individual column

and cutting a block shape out of an arbitrary portion of

the structure, while maintaining the integrity of the

relationships between the pieces. Of the five commer-

cial CAD platforms tested (Bentley Structural Tri-

forma, Autodesk AutoCAD, Solidworks, Nemetschek

Allplan and Tekla Xengineer), three did not exhibit

parametric behavior as defined above. Although they

provide parametric behavior on part definition and

insertion, they did not maintain parametric relation-

ships between objects and did not reevaluate in

response to changes.

The two remaining systems, which fulfilled all of

the functional requirements, were evaluated for per-

formance. The time required to reevaluate the model

and return control to the user after each prescribed

change, at each stage of replication of the building’s

bays and floors, was measured. Only one—a system

developed especially for building modeling—was

able to maintain response times of less than 1 min

Fig. 7. Performance benchmark test building.

Fig. 8. Assembly layout with construction planes.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312306

throughout the predetermined test sequence; the test

continued beyond the prescribed 21,601 pieces, until

86,404 pieces were modeled in the assembly. The

performance of the other system—a generic paramet-

ric modeling system—degraded in relation to the

number of pieces in the assembly, reaching response

times in excess of 3 min at 21,601 pieces, despite

running on a high-end PC computing platform.

This test highlights the significance of performance

for parametric systems intended for modeling build-

ings. Building models differ from models of mechan-

ical parts in that they must incorporate large numbers

of parts in an assembly. We hypothesize that the basic

structure of the parametric data, as implemented in

each system, determines its ability to deliver the

performance required for a designer to work effec-

Fig. 9. Schematic structure topology.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 307

tively. Where the relationships between the objects are

restricted to those that model structural behavior only

(beams, columns, etc.) the sequence of reevaluation in

response to parametric change is predetermined. In a

generic system, the sequence of reevaluation must

first be established algorithmically, and this degrades

performance as the number of related objects within

the same assembly increases.

5. Precast modeling example

The following simple test structure (Fig. 8) illus-

trates the complex parametric behavior required to

support the typical operations a precast designer must

perform in order to build and maintain a 3D model of

a building. The structure consists of one bay of a

building, defined by two sets of parallel grid lines

(denoted A, B, 1 and 2). Two columns, positioned

relative to the intersections of axes A-1 and A-2,

Fig. 10. Connection detailing—columns, inverted tee beam and corbel co

support a spandrel beam at the level of the first-floor

construction plane. The connections between the

spandrel beam and the columns are formed by creat-

ing pockets in the columns, with the constraint that the

exterior faces of the columns and the spandrel beam

remain collinear. Two more columns, located relative

to the intersections of axes B-1 and B-2, support an

inverted tee beam at the same floor level. The con-

nections in this case are corbels. A field of double-tee

sections rests on the ledge of the inverted tee beam; on

their opposite ends, the double tees have extended

stems which rest within pockets in the spandrel.

In the first stage—assembly layout—the designer

begins by establishing a layout for the building as a

whole (this may be copied or translated from an

architect’s design, or in the case of design-build,

originate with the precast designer). The layout con-

sists of vertical construction planes (designated Axis

A, Axis B, Axis 1 and Axis 2 in Fig. 8—these are

termed ‘building axes’ in plan drawings) and primary

nnections. Equivalent stick and node representation is shown inset.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312308

floor levels (horizontal planes—Plane 1 and Plane 2).

The locations and sizes of all the pieces in the

building will be derived directly or indirectly from

these planes.

Next, the designer selects precast products and

inserts instances of them into the assembly to repre-

sent precast pieces. The first pieces are positioned by

relating them to one another and/or to the construc-

tion planes (Fig. 8). The columns are located with x

and y offsets from vertical plane intersections. Their

top and bottom levels are fixed relative to horizontal

Fig. 11. User changes to piece geometry with cor

planes. At this stage, they are simply rectangular

prisms. The other pieces are placed relative to the

columns; in placing them in the assembly, the user

establishes their topological relationships to the pieces

already in the assembly. The beams are constrained to

lie such that their axes span between connection

points whose location is constrained relative to the

columns; the field of double tees is defined as lying

between the beams and between construction planes

‘Axis 1’ and ‘Axis 2.’ The resulting topological

dependencies are shown schematically in Fig. 9 (in

responding system updates of the assembly.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 309

the figure, dependencies are from right to left). Note

that although at this stage the connections have no

explicit geometry, they exist as logical entities with

location.

In the second stage—assembly detail—specific

connection types are selected from a library and

detailed for each existing connection object in the

model. In the example, recessed connections are

assigned to connections 1 and 2 (Fig. 9), corbels to

3 and 4, pockets to 5a and 5b and ledge bearings to 6a

and 6b. The connections now have internal geometry

(see Fig. 10). Aspects of their geometry can also be

constrained by the geometry of the pieces they con-

nect; for example, the width of a corbel may be

constrained to be equal to the width of the column

with which it is cast. Wherever necessary, the pieces

themselves are now cut out to accommodate the

pieces they are connected to and the connection

hardware (e.g., recesses in columns A1 and A2 to

accommodate the spandrel beam).

The practical result is that the designer may move

construction planes, move or rotate pieces, change the

proportions of the pieces (parametric adjustments to

their defining dimensions, such as their cross-sectional

dimensions), change the cross-sectional shapes of the

pieces, change connection types, etc (Fig. 11), and in

each case, the systemmaintains the overall geometry of

the assembly. A case of special interest is provided by

lowering one corbel supporting the inverted tee: as a

result, the field of double tees becomes warped (Fig.

11c). This is done routinely in precast buildings where

the slab must provide slopes for drainage. While each

double tee is warped in the assembly, they are cast

straight—thus, the piece production drawing for these

pieces must show them flat. Notice also that prestress-

ing induces both camber and elastic shortening in the

double tees, which further complicates the geometry of

their end connections. These are important capabilities

for any production 3D parametric modeling system for

precast engineering.

In the third stage—piece detailing–the designer

details each piece. This stage can be highly automat-

ed: load results from structural assembly analysis are

applied to each piece, the reinforcement and prestress

strands are calculated and detailed and embeds are

inserted. Before generating assembly and piece draw-

ings, the system identifies and collects identical pieces

into piece-mark groups. The components of each

precast piece are also related parametrically to the

concrete envelope geometry of that piece. Thus, once

piece detailing has been completed, changes at the

assembly level should be propagated to the reinforce-

ment and embeds of each piece. This is relatively

straightforward when the change to the piece geom-

etry is purely dimensional; it is far more complex

when the change is topological (e.g., change of cross-

section type). In such cases, detailing of the piece

from scratch may be necessary.

6. Conclusions

In the first CAD revolution in the AEC industry,

designers moved from manual drafting to computer-

aided drafting. This revolution is largely complete, as

most architectural and engineering practices have now

adopted the technology. New releases of commercial-

ly available software deliver gradually decreasing

levels of functional enhancements over their prede-

cessors. The second CAD revolution in the AEC

industry, introducing 3D parametric solid modeling,

has begun; research and development efforts are now

being focused on providing the appropriate function-

ality to be embedded in next-generation building

design software packages. Certain sectors of the

AEC industry, such as structural steel, already have

3D modeling systems, with extensive parametric ca-

pability. Others, such as the precast concrete industry,

are moving rapidly in that direction. The potential

benefits are both direct (reduced design and drafting

costs, enabling production automation, etc.) and indi-

rect (reduced error rates in construction, enhanced

ability to consider design alternatives, etc.).

The basic criteria for 3D parametric modeling

software for design and engineering of buildings can

be summarized as follows:

(a) Effective support must be provided not only for

bottom-up assembly of components, but for top-down

modeling as well. To support initial design develop-

ment, to enable replacement of alternate functional

solutions at later design stages and to allow definition

of new objects that satisfy functional criteria, the

modeling constructs should include abstract function-

al objects.

(b) The software must support designers by

providing objects that model building function.

R. Sacks et al. / Automation in Construction 13 (2004) 291–312310

These should automatically insert the parametric

and topological relations and constraints between

parts, so that they behave correctly in all design

contexts. This is a challenging requirement, requir-

ing careful definition of each possible context and

the parameters that define it. Proper implementation

allows automatic maintenance of the geometric and

topological consistency of the design as changes

are made, within the limitations imposed by the

different natures of parametric versus topological

change.

(c) The semantics of functional objects imply that a

parametric building modeling system will have a

specific functional domain (i.e., it will incorporate

attributes and behavior to address functional consid-

erations such as structural, energy, fire code, acoustic

and others). If the object definitions are not open-

ended, a system may restrict the range of possible

design. Abstract functional objects offer a solution to

this requirement.

(d) Design and detailing tasks should be automat-

ed, through definition of sets of parametric objects

with embedded behavior for automated layout and

editing. The behavior can be based on functional

criteria expressed in structural design codes, industry

best practice and company policies. The development

of such automation, on top of the interactive capa-

bilities of parametric modeling, enhances the prod-

uctivity of the technology. The design of such

automation for building objects is likely to become

a major development undertaking over the next

decade.

(e) To date, one of the barriers to implementation

of building-level automated design modules has been

the lack of a parametric building modeling platform.

Development of a platform as described here may

facilitate the development of sophisticated tools of the

kind that have been envisaged by researchers. It is

likely that comprehensive tools will be composed of

assembly-level modules; research will be required to

establish the limits of such modules and appropriate

interactions between them.

(f) The data structure should provide users flexible

control over how changes are propagated among

identical or near-identical parts. A strategy in which

each individual part in a building model has inde-

pendent identity, but is modeled as a composite of

lower level features that are concentrated in sets of

unique objects, can best support the functionality

required.

(g) The software performance, in terms of re-

sponse time to user actions that require reevaluation

of the model, must be adequate to enable uninter-

rupted use. This requires that the strategy employed

for reevaluating a model, and its underlying data

structure, support assemblies with tens of thousands

of parts.

Additionally, with parametric 3D modeling, the

computer can be a true partner in managing a specific

set of functional criteria within a building design. A

designer using the system will not only oversee the

computer’s detailing, but must also be responsible for

adapting the design to functions or requirements not

embedded in the software. The flexibility to maintain

control of the design is an absolute necessity for the

acceptance of such software.

In theory, there are three alternative strategies for

development of specialized building modeling appli-

cations: (a) directly on a generic, general purpose

parametric CAD platform, which does not restrict

the range of possible parametric relationships be-

tween parts, (b) on the basis of a platform specif-

ically designed to support building modeling, or (c)

from scratch, without a generic platform, as stand-

alone software. The results of the performance

benchmark test indicate that option (a) is currently

unrealistic—only the system in which the functional

behavior of the parts was embedded at a low level

within the software data model succeeded in pass-

ing the test. To date, most commercial developers

of parametric modeling software for the AEC

industry have adopted the third alternative. They

have implicitly assumed that the parametric behav-

ior of specific building systems or types must be

embedded in special-purpose software. For example,

doors and windows are constrained to be located in

walls in architectural packages; steel detailing pack-

ages restrict connections to meeting points of steel

members, etc. They do not enable users to model

higher order arbitrary constraints between building

elements. Some of these behaviors are fairly

straightforward and have already been implemented

in software systems. Others will require much

specification, implementation, testing and refine-

ment before robust solutions become available.

These modelers will become increasingly special-

R. Sacks et al. / Automation in Construction 13 (2004) 291–312 311

ized, reflecting the expert knowledge that they

embed.

An alternative, broader approach would be to

provide a parametric building modeling platform with

functional building objects, but to add a basic set of

possible (and unrestricted) higher order parametric

relationships that can be applied between user-defined

entity types. Such a platform, if provided with an open

application programming interface (API), would en-

able third-party software developers to build specific

AEC automation applications with the possible desir-

able result that diverse building systems could be

modeled on a common platform. Clearly, providing

additional generic capabilities involves a nontrivial

increase in required computing power. The exact

nature of the trade-off between the generality of

applicability on the one hand, and performance on

the other, has yet to be established.

The next generation of CAD, using 3D parametric

building modeling, with embedded assembly, piece

and component function and behavior provides a new

level of support for building design automation.

References

[1] A. Baer, C.M. Eastman, M. Henrion, Geometric modeling: a

survey, Computer-Aided Design 11 (1979) 253–272.

[2] Boeing, vol. 2002, 1999.

[3] I.C. Braid, Designing with Volumes, Cantab Press, Cambridge

University, Cambridge, UK, 1973.

[4] C.K. Choi, E.D. Kim, Top-down geometric modeling of

buildings on network database, Computer-Aided Design 25

(1993) 468–478 (Butterworth-Heinemann).

[5] A. Csabai, I. Stroud, P.C. Xirouchakis, Container spaces and

functional features for top-down 3D layout design, Computer-

Aided Design 34 (2002) 1011–1035 (Elsevier).

[6] C.M. Eastman, Building Product Models, CRC Press, Boca

Raton, FL, USA, 1999.

[7] C.M. Eastman, Design of assemblies, SAE Congress (Detroit

MI, paper no. 81097) 1981.

[8] C.M. Eastman, R. Sacks, G. Lee, Software Specification for a

Precast Concrete Design and Engineering Software Platform,

Georgia Institute of Technology, Atlanta, GA, USA, 2001.

[9] C.M. Eastman, R. Sacks, G. Lee, in: W. Stone (Ed.), Strategies

for Realizing the Benefits of 3D Integrated Modeling of

Buildings for the AEC Industry, ISARC-19th International

Symposium on Automation and Robotics in Construction,

vol. SP 989, NIST, Washington, DC, 2002, pp. 9–14.

[10] S.J. Fenves, U. Flemming, C. Hendrickson, M.L. Maher, G.

Schmitt, Integrated software environment for building design

and construction, Computer-Aided Design 22 (1990) 27–36.

[11] U. Flemming, R. Woodbury, Software Environment to Support

Early Phases in Building Design (SEED): overview, ASCE

Journal of Architectural Engineering 1 (1995) 147–152.

[12] W. Gielingh, General AEC Reference Model ISO TC 184/

SC4/WG1 Doc. 3.2.2.1 (TNO, 1988).

[13] M. Hakim, J.J.H. Garrett, Using description logic for repre-

senting Engineering design standards, Journal of Engineering

with Computers 9 (1993) 108–124.

[14] Y. Kalay, Modeling Objects and Environments, Wiley, New

York, NY, 1989.

[15] K.H. Law, T. Barsalou, G. Wiederhold, Management of Com-

plex Structural Engineering Objects in a Relational Frame-

work, Engineering with Computers, vol. 6, Springer-Verlag,

New York, 1990, pp. 81–92.

[16] B. Lindsey, Digital Gehry, Princeton Architectural Press, New

York, NY, 2001.

[17] M.L. Maher, S.J. Fenves, HI-RISE—an expert system for the

preliminary structural design of high rise buildings, in: J.S.

Gero (Ed.), Knowledge Engineering in Computer-Aided De-

sign, North-Holland, Amsterdam, 1985, pp. 125–135.

[18] M. Mantyla, An Introduction to Solid Modeling, Computer

Science Press, College Park, MD, 1988.

[19] K. Martini, G.H. Powell, Geomteric Modeling Requirements

for Structural Design, Engineering with Computers, vol. 6,

Springer-Verlag, New York, 1990, pp. 93–102.

[20] R. Navon, Y. Rubinovitz, M. Coffler, Development of a fully

automated rebar-manufacturing machine, Automation in Con-

struction 4 (1995) 239–253.

[21] R.E. Oxman, Case-based reasoning in knowledge-based de-

sign, European Symposium on Management, Quality and Eco-

nomics in Housing and other Building Sectors (Lisbon,

Portugal), 1991.

[22] J.M. Pastor, C. Balaguer, F.J. Rodriquez, Computer-aided ar-

chitectural design oriented to robotized facade panels manu-

facturing, Computer-Aided Civil and Infrastructure Engineer-

ing 16 (2001) 216–227.

[23] PCI, PCI and CPCI Software Survey, Precast/Prestressed Con-

crete Institute, Chicago, 2001.

[24] G.H. Powell, H. An-Nashif, Automated Modeling for Struc-

tural Analysis, Engineering with Computers, vol. 4, Springer-

Verlag, New York, 1988, pp. 173–183.

[25] A.A.G. Requicha, Representations of rigid solids: theory,

methods and systems, ACM Computer Survey 12 (1980)

437–466.

[26] A.A.G. Requicha, H.B. Voelcker, Solid modelling: current

status and research directions, IEEE Computer Graphics and

Applications 3 (1983) 25–37.

[27] R. Sacks, C.M. Eastman, G. Lee, Information and process

flow in models of precast concrete design and construction,

in: I.D. Tommelein (Ed.), CEC02 Concurrent Engineering

Conference, UC Berkeley, Berkeley, CA, 2002, pp. 51–63.

[28] R. Sacks, C.M. Eastman, G. Lee, Process improvements in

precast concrete construction, Journal of the Precast/Pre-

stressed Concrete Institute 48 (3) (2003) 46–55.

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

on management and engineering procedures in the North

American precast/prestressed concrete industry, ASCE Jour-

R. Sacks et al. / Automation in Construction 13 (2004) 291–312312

nal of Construction Engineering and Management (2003)

(in press).

[30] R. Sacks, A. Warszawski, A project model for an automated

building system; design and planning phases, Automation in

Construction 7 (1997) 21–34 (Elsevier).

[31] R. Sacks, A. Warszawski, U. Kirsch, Structural design in an

automated building system, Automation in Construction 10

(2000) 181–197 (Elsevier).

[32] J.J. Shah, M. Mantyla, Parametric and Feature-Based CAD/

CAM: Concepts, Techniques, And Applications, Wiley, New

York, 1995.

[33] I.E. Sutherland, Sketchpad, a man–machine graphical com-

munication system, Spring Joint Computer Conference,

1963.

[34] P. Teicholz, M. Fischer, Strategy for computer integrated con-

struction technology, ASCE Journal of Construction Engineer-

ing and Management 120 (1994) 117–131.

[35] A. Warszawski, Industrialization and Robotics in Building,

Harper and Row, New York, NY, 1990.

[36] Y. Yaski, A consistent database for an integrated CAADsystem,

PhD Dissertation, Architecture, Carnegie Mellon University,

1981.