Narratives: Composing and controlling persistent assistants to
communicate, integrate, and automate multidisciplinary design and
analysis
John Haymaker, Ben Suter, John Kunz, Martin Fischer
Stanford University, Department of Civil and Environmental Engineering,
Center for Integrated Facility Engineering, Building 550, Room 553H, Stanford, CA 94305
haymaker@stanford.edu. suter@stanford.edu, kunz@stanford.edu, fischer@stanford.edu
Abstract
We discuss an approach in which engineers formally and
iteratively construct information representations, called
Perspectives, from information in other Perspectives using
personal computational assistants, called Perspectors.
Engineers can select from predefined, reusable, Perspectors,
or program new Perspectors, and compose them into
directed acyclic graph structures, called Narratives, to
quickly and accurately construct useful dependent
Perspectives. The approach also formalizes simple
management processes with which professionals can control
the integration of their Perspectives with respect to the
Perspectives on which they depend. The result is an
evolving, distributed, multi-disciplinary and integrated
project model. We describe one conceptual Narrative that
formalizes a multidisciplinary cost-benefit analysis to help
designers choose amongst sustainable strategies. We
describe one implemented Narrative that automatically
generates a metal decking contractor’s connection details
that are needed to connect concrete slabs that are described
in an architect’s model and steel beams that are described in
a steel detailers model. We discuss how these Narratives
could have enabled engineers to better design,
communicate, integrate, and automate their design processes
than is possible on a recent state-of-the-art AEC projects.
Narratives are intended to enable engineers from multiple
disciplines to engage in novel, automated, and integrated
design and analysis by easily yet formally constructing and
integrating Perspectives from other Perspectives.
Introduction
Architecture, Engineering and Construction (AEC) projects
are multidisciplinary, constructive, iterative, and unique
processes. On these projects, AEC professionals, such as
architects, consultants, contractors, detailers, and
fabricators use task-specific representations to design, plan,
and execute a project. These representations contain
information that is ideally structured for their specific task,
describing everything from existing conditions, to project
requirements, to design options, to design analyses, to
construction documentation, to fabrication, to installation
and as-built information AEC Professionals often construct
the information in these representations based on
information in other engineers’ representations, Dependent
representations often become source representations of
other dependent representations: A network of
dependencies
between
distributed,
task-specific
representations emerges as the design progresses. When
source
representations
are
modified,
dependent
representations often must be integrated.
That is, AEC professionals develop what we call narratives
for their own work and interweave them with narratives of
other engineers. The Oxford English Dictionary defines a
narrative as “An account of a series of events, facts, etc.,
…with the establishing of connections between them.” In
AEC practice, narratives help professionals expose crossdisciplinary impacts and integrate their work with the work
of other project stakeholders; however, currently these
narratives are not formally represented or managed.
Surprisingly, the connections between different disciplines
information, in this case the dependencies, are not
generically represented but rather stored locally, or in the
heads of the professionals.
This way of constructing, organizing, and communicating
project information is proving to be time-consuming, errorprone, and expensive. AEC professionals would benefit
from computational assistance in constructing and
integrating their project specific engineering narratives.
However, AEC projects are unique, formalizing the
dependencies between their representations a priori has
proven very difficult. This paper describes the need for,
and a proposed way toward, enabling AEC professionals to
define their own formal MDA Narratives. These Narratives
consist of a collection of design and analysis
representations, “connected” by dependencies.
We first describe industry test cases that illustrate the
multidisciplinary, constructive, iterative, and unique
character of AEC projects. The test cases show that these
projects can be structured as MDA Narratives, that it is
difficult today to predetermine the specific content of these
narratives, and that therefore engineers could benefit from
methods that enable them to more easily and formally
construct and control their own project specific MDA
Narratives. We then review the knowledge base of the
AEC profession with respect to representing and
interrelating multidisciplinary project information and
propose professionals need a simple, formal, generic,
expressive collection of generic representation, reasoning,
and management methods that enable AEC professionals to
collaboratively construct and control MDA Narratives.
These methods should be persistent, in order to control the
integration of Narratives. We describe our ongoing efforts
to implement such methods, examples of one implemented
and one conceptual Narrative, and ongoing efforts to
validate the benefits of Narratives with respect to how they
enable AEC professionals to better communicate, integrate,
and automate their MDA design processes.
Test Cases: the narrative structure of AEC
projects
This section briefly describes two test cases that illustrate
the implicit narrative structure of AEC projects, the
difficulties professionals have executing these projects, and
the benefits that could be derived by formalizing the
narrative structure of these projects.
Cost benefit analysis for skylights and atria
On each project, Cradle-to-Cradle (C2C) designers like
William McDonough Partners (WMP) study local and
global conditions and work to define and exceed project
specific economy, ecology, equity, and elegance goals.
William McDonough says that C2C designers work toward
these goals by asking and answering many questions
(McDonough 2004). Yet in order to answer their questions,
C2C designers often need to ask other related questions: an
implicit narrative of interconnected questions (reasoning)
and answers (representations) emerges as the project
progresses. This test case describes a narrative of questions
and answers that WMP raised regarding the costs and
benefits of employing various design strategies such as an
atrium and skylights.
Figure 1 describes and diagrams the narrative of questions
WMP and their consultants asked, the answers they
constructed for these questions, and the information
dependencies between these questions and answers. The
lines are dashed because the dependencies, or connections,
between representations were not formalized in the
computer.
WMP knows that atria and skylights can be effective ways
to take advantage of natural light, reduce building energy
consumption, and improve the quality of the work
environment. However, both skylights and atria cost
money, can cause uncomfortable glare conditions, and have
constructability and maintenance issues; and atria generally
result in a bigger building footprint. Therefore WMP
wanted an answer to the question: What are the costs and
benefits of skylights and an atrium on this project?
This building was to house some of the client’s most valued
and talented employees. Were the added daylight from the
skylights and atrium to appreciably improve the
productivity and reliability of their workforce, this would
be a strong argument for including these features. WMP
studied industry data that has measured the improved
productivity and reliability of the workforce in similar
environments, and constructed a reasonable estimate for the
expected productivity gain and absenteeism improvement
in a strategically day lit space compared to a more
traditional, artificially illuminated space. As a business,
they needed to weigh this expected productivity gain
against the expected lifecycle cost of constructing and
operating the building. To calculate this cost, they asked
what the added construction cost and potential energy
savings (due to the reduction in artificial light) would be. In
order to answer these questions, they needed to ask how
much natural light would enter the building should different
combinations of skylights and atria be employed. In order
to answer these questions, they needed to ask what a
building with and without atria and skylight might look
like. In order to answer these questions, they asked about
the client’s requirements, the prevailing regulatory
requirements, and the characteristics of the site.
No diagram or other formal description of such a narrative
existed for this project. WMP provided a series of
Microsoft Word™ documents, containing over one
hundred pages, in which they described the process they
executed to determine the costs and benefits of the
skylights and atrium. Because of the time and resource
constraints, WMP was not able to fully explore this
narrative. For example, they were unable to sufficiently
explore many configurations of skylight and atria layout to
determine the optimal layout for the energy, daylight, cost,
and productivity criteria they determined were important.
We believe the ability to formally represent this narrative in
the computer would have enabled WMP to more
effectively communicate their design logic to the owner
and other project participants, more effectively integrate
and automate their design representations for the
exploration of more options, and achieve more optimal
design solutions.
Design and fabrication of deck attachments
Figure 2 describes a portion of the design and construction
of the Walt Disney Concert Hall’s steel and concrete frame.
The lines are dashed because on this project the
connections between representations were not formalized
in the computer; the project engineers maintained them in
an ad-hoc and manual manner. The architect (see Figure
2A) constructed and integrated a Concrete Slabs
representation describing the boundary of each concrete
slab on the project. From this and other representations, the
structural engineer (see Figure 2B) constructed a Framing
Center Lines representation describing the centerline of
each steel member required for the frame of the building.
The steel detailer (see Figure 2C) constructed a Steel
required (see Figure 2G). The steel fabricator (see Figure
2E) fabricated the beams, welding the required deck
attachments to the respective beams in the shop. The design
process was iterative. Changes in the design of the concrete
slabs needed to propagate through the narrative, requiring
modifications to the steel design and therefore to the deck
attachment design.
Framing representation describing the boundary of each
steel member and its fasteners. The metal decking detailer
(see Figure 2D) constructed a Deck Attachments
representation describing where to install attachments to
connect the metal decking for concrete floor slabs to the
structural beams (see Figure 2F). The metal decking
detailer constructed this representation by drawing a line
along the edge of each beam where an attachment was
What are the
characteristics of
the site?
How much
day light enters
each design?
What would a
building with an atrium
and skylights be like?
Average Illuminance
Footcandles (FC)
December
9AM / 3PM
Noon
September / March
9AM / 3PM
Noon
Near Atrium
50 - 60
100 - 110
125 - 140
190 - 210
Center
Near Perimeter
45 - 55
45 - 55
70 - 80
90 - 100
95 - 105
100 - 120
150 - 160
160 - 180
320 - 340
250 - 270
150 - 170
275 - 295
Average Illuminance
Footcandles (FC)
December
9AM / 3PM
Noon
September / March
9AM / 3PM
Noon
June
9AM / 3PM
Noon
Near Atrium
30 - 40
55 - 65
70 - 80
110 - 120
95 - 115
180 - 200
Center
Near Perimeter
40 - 50
70 - 80
80 - 90
130 - 140
90 - 110
150 - 170
140 - 160
235 - 255
130 - 150
220 - 240
210 - 230
380 - 420
Daylighting
Reduced Energy Loads:
approx. 70% of lighting energy is
saved in areas where daylighting
is employed. In addition, electric
lamp replacement and cooling
loads are reduced.
Estimated Likely Illuminance in FootCandles for Lower Level on Overcast Day
Increased Productivity: Worker
productivity has increased
How much
energy would each
building consume?
Simple Payback: 5.9 years
Lighting
Energy Cost Lighting
No
Fraction
Daylighting Saved
What are the
regulatory
requirements?
What are the costs
and benefits of the
skylights and atrium?
June
9AM / 3PM
Noon
180 - 200
140 - 150
Estimated Likely Illuminance in FootCandles for Upper Level on Overcast Day
1st Floor @
70,000 SF
2nd Floor @
61,000 SF
Combined
131000 SF
What would a
building with just an
atrium be like?
Lighting
Energy Cost
W/
Daylighting
14,700
58%
8,526
12,858
82%
10,544
20,280
69%
19,070
How much would
each building cost
To light and heat?
Lighting
Energy Cost Lighting
No
Fraction
Daylighting Saved
1st Floor @
70,000 SF
2nd Floor @
61,000 SF
Combined
131000 SF
What would a
building with just
skylights be like?
What are the
client’s
requirements?
Lighting
Energy Cost Reduced
W/
Maint.
Daylighting Cost
Reduced
HVAC
Costs
Net Cost
Savings
14,700
58%
8,526
635
910
12,858
82%
10,544
760
1,125
9,495
20,280
69%
19,070
1,395
2,035
22,500
7,925
How productive and
reliable would the
employees be?
Daylighting
What would a
building without an atrium
or skylights be like?
Reduced absenteeism:
Workers remain more alert, and
are absent less, under natural
lighting conditions.
Most Likely
Productivity % Absenteeism Cost Benefit 1
Improved
% Improved
$
4
9
1,581,000
What do existing
studies say about the
effects of daylight?
Figure 1: A narrative of questions (reasoning) and answers (representations) that WMP used to understand the cost
benefit of using an atrium and configuration. The arrows between answers and subsequent questions are shown as dashed
because the dependencies are not formally represented in a computer.
Fig. 2: A portion of the narrative the AEC professionals used to design and construct the Walt Disney Concert Hall. AEC
professionals (humans shown in boxes) construct task-specific representations (shown as database barrels) from other
representations. The arrows are shown as dotted, because the connections between these representations remained
implicit; the engineers did not formalize them either in their documentation or in a computer model.
Observations from test cases
The test cases illustrate (Haymaker et al 2004a) that AEC
projects are multidisciplinary: AEC professionals on these
projects construct discipline-specific representations of the
project to do their work. AEC projects are constructive:
these professionals construct representations from
information in other representations. AEC projects are
iterative: When source representations are modified,
dependent representations must be integrated. AEC
projects are unique: Atria and deck attachments are an
issue on some, but not all projects. Finally, as practiced
today, AEC projects are error prone, time-consuming and
difficult.
In Haymaker et al 2004 a, we proposed that AEC
professionals could have addressed many of these
difficulties by formalizing their MDA Narratives. More
specifically, we propose that MDA processes could be
augmented by, if not founded on, simple formal, generic,
expressive methods to construct information by formalizing
its dependency on other disciplines’ information and by
controlling the integration of this information as the project
progresses. A formal MDA Narrative could emerge as AEC
professionals iteratively apply and manage such methods.
application of this representation method. It also shows that
the Perspectors are generic, and can therefore specify either
human or automated, off-the-shelf or user defined
reasoning.
The Perspective Approach also formalizes Management
Processes to help AEC professionals control the integration
of these Narratives in which Perspectives are persistently
notified when source Perspectives are modified.
Perspectors can be persistently run, to reintegrate these
Perspectives automatically, or, can wait for user requests to
integrate.
(automated)
Narrative
(manual)
relationship
Formalization:
In Haymaker et al 2004 b we proposed formalization for
Narratives. Called the Perspective Approach this
formalization enables AEC professionals to specify the
sources, status and nature of the dependency of their
representation, called a Perspective, on other Perspectives.
· Sources: The source information on which dependent
information depends.
· Status: Integration status of the information with respect
to its source information.
· Nature: The reasoning method (automated or manual)
that constructs the dependent information from source
information. We call this reasoning method a Perspector.
Perspective
Perspector
Perspective
Perspective
Perspective
Nature of
dependency
Status of
dependency
Sources of
dependency
Dependent Perspectives
Source Perspectives
Figure 3: Formalizing the sources, nature, and status
of the dependency of a dependent view on source
views.
Fig. 3 diagrams this formalization of the dependency of
dependent information on source information(s). Fig. 4
shows that a formal Narrative can emerge form the iterative
Figure 4: A Narrative emerges from the repeated
application of the formalism described in A.
POD: Approaches to building information
modeling
In this section we discuss related efforts in research and
practice in the area of representing, reasoning about, and
managing building information models. We first discuss
efforts to formally represent building information. We then
discuss efforts to develop reasoning algorithms to automate
the construction and analysis of this information. Finally,
we discuss efforts to integrate representation and reasoning
into project model frameworks for AEC. We conclude that
while the representation and reasoning work serves as
excellent building blocks for Narratives, efforts to integrate
AEC project information, which primarily relies on
predefined, centralized project models, do not adequately
address the multidisciplinary, constructive, iterative, and
unique nature of AEC processes.
Representation: Most AEC projects today rely on
proprietary information formats, resulting in serious
interoperability difficulties when multiple project
stakeholders adopt different proprietary solutions. To
address these difficulties, industry and government have
initiated major efforts in the area of generic engineering
data standards, including STEP (Standard for the Exchange
of Product data (ISO, 1994)) and IFC (Industry Foundation
Classes (IAI, 2004)). For example, the schema defined in
IFC 2.X enables an engineer to represent Ifcbeam features
and Ifcslab features. As currently formalized, these
standard representation languages do not contain an
explicit mechanism for representing the existence, status,
and nature of the dependencies between information from
different disciplines.
Reasoning: Computer programs that automatically
construct useful task-specific dependent information from
source information are increasingly used in practice today.
AEC professionals are using programs for daylight analysis
(Radiance 2004), energy analysis (DOE2 2004), structural
analysis (SAP2000 2004), cost estimating (Timberline
2004), and automated steel detailing (Tekla, 2004), among
other uses. Considerable research is devoted to improve on
and extend these suites of task-specific, automated design
and analysis programs. We discuss many of these efforts in
Haymaker et al 2004c.
Other
approaches
to
constructing
task-specific
representations of project information are more generic.
Query languages (Date and Darwen 1993) enable the
automatic selection or limited transformation of
information in a model into a view. Feature Recognition
(Dixon and Poli 1995) identifies instances of feature
classes in a geometric model. Recent approaches in
mechanical engineering (Lou et al 2003) investigate
generic CAD query languages that enable engineers to
query a model for geometric features. Generally, today
there is a wealth of task-specific and generic reasoning
tools, but what is needed is a general, simple framework to
integrate these methods.
Project Model Frameworks: To address this need, some
(i.e., Eastman and Jeng 1999, Haymaker et al 2000,
Autodesk 2003, Sacks et al 2004) develop reasoning and
management that constructs and controls dependencies of
information in a predefined central model. For example,
Eastman and Jeng 1999 formalize a system, called EDM-2,
in which applications construct task-specific views of a
central model and write information back into the model.
Other applications then reconstruct their task-specific view
of this modified central model. Others (Khedro and
Genesereth 1994, Sriram 2002, Bentley 2003) develop
similar reasoning and management approaches that
construct and control dependencies between information in
a federation of predefined task-specific views. In both these
central and federated model approaches, system
programmers are generally required to define the nature of
the dependencies.
Parametric techniques (Shah and Mäntyla [35]) enable
professionals to define sets of related numeric or symbolic
equations that can be solved to realize feasible designs.
Commercially available parametric modelers, such as
CATIA, provide tools to assist engineers both in generating
2D sketches from which 3D form features are
parametrically generated and also in specifying the
assembly of these form features parametrically with respect
to the positions of other form features. Some systems
employing parametric techniques are being commercially
introduced specifically for the AEC industry, such as
XSteel (Tekla 2003), Revit (Autodesk 2003), Object
Genome System (Onuma 2004), and Generative
Components (Bentley 2004). While some successes are
being reported within the context of single domains (Sacks
2004), parametric techniques are not being widely used in
the AEC industry to integrate the work of multiple
disciplines. This is because, as currently formalized, these
techniques have not adequately supported the
multidisciplinary, constructive, iterative, and unique nature
of AEC projects: They do not enable professionals to easily
and formally construct new representations from
information in other professionals’ representations, and
control the integration of these representations as the
project progresses.
Project management systems, such as Primavera (2004),
are task-focused representations of a project. They
represent precedence dependencies among tasks and are
used to calculate issues such as project duration. They do
not contain an explicit representation of task-specific
information, nor do they represent or manage the nature
and status of the dependencies between this information.
Current project modeling frameworks do not provide
adequately simple, formal, generic, expressive methods that
AEC professionals need to construct and control their
MDA Narratives. Instead professionals are utilizing a
hodgepodge of AEC systems that in many ways complicate
the streamlining and integration of information and
communication.
ONGOING WORK: FORMALIZING AND
IMPLEMENTING MDA NARRATIVES
This section describes ongoing work in which we are
gathering and formalizing test cases; building frameworks
in which to implement the test cases, and validating
Narratives in terms of their ability to improve
communication, integration, and automation, and by
extension, design.
Gather and formalize test cases
Figure 5 diagrams and describes a formal MDA Narrative
for the cost-benefit analysis test case. The figure shows that
any Perspector can itself be decomposed into a subNarrative. Such decomposition aids the thought process
when constructing a Narrative, and enhances the readability
of a composite Narrative.
Decomposition of Perspectors into sub-Narratives can
conceptually extend to a very low level. In Haymaker et al
2004b & c, we compose a sub-Narrative of geometric
selection, reformulation and generation Perspectors that
together automatically construct the Deck Attachments
Perspective from the Concrete Slabs and Steel Framing
Perspectives. See Figure 6. In these papers, we also show
that these Perspectors can be reused in different Narratives,
suggesting that a generic language of low-level Perspectors
can be defined and reused, significantly reducing or
eliminating the need to write computer code.
Light
Windows
Contribution
Atrium
Skylights
Compare
Light
Consistency
Daylight Analysis
No Skylights
Atrium
Daylight
Analysis And
Comparison
Analyze and
Compare
Day Light
sensor 4
Light Shelf
sensor 1
Compare
Illuminance
Values
inside
Daylight Analysis
Skylights
No Atrium
0.06
0.04
0.02
0
outside
Parameters
No Skylights
For Daylight
Atrium
Analysis
0.14
0.12
Light
0.1
Distribution
0.08
Daylight Factor
Analyze
Daylight
Enter
Parameters
Summarize
Light Shelf Illuminance Comparison
inside
Analyze
Daylight
outside
Daylight Analysis
Skylights
Atrium
Skylights
Atrium
A sub-Narrative that analyzes the
addition of skylights and atrium in
terms of daylight and compares
the results of these analyses in
terms of light contribution,
distribution, and adequacy.
Compare
Relative
Light Contribution
Analyze
Daylight
Analyze and
Compare
Energy
No Light Shelf
Day Light
Analyses And
Comparison
Analyze
Daylight
Light
Adequacy
Skylights
No Atrium
A sub-Narrative that analyzes the addition of skylights
and atrium in terms of several criteria, including
daylight, energy consumption, structural stability,
constructability, and first and lifecycle costs, and that
compares the results of these analyses.
14000
12000
10000
No Skylights
No Atrium
lx
8000
Daylight Analysis
No Skylights
No Atrium
6000
4000
0
NS/A Winter
1
1251.916667
1671.166667
2021.75
1873.25
2024.166667
2513.166667
2
3
1936.833333
2432.833333
2512
1934.25
4
673.6666667
5
1015.416667
6
Analyze and
Compare
Constructability
1331.583333
2850.25
606.75
822
1274.25
2468.25
2252.083333
1554.833333
1511.916667
1971.166667
1954.583333
2810.583333
3191
11221.08333
5823.916667
2248.75
2481.666667
2305.5
5284.25
2798.25
2554.166667
11458.66667
2686.083333
2355.666667
1st Floor(1-3) 2nd Floor(4-6)
Atrium(1/4) Central(2/5) Perimeter/Windows(3/6)
Skylights
Atrium
A Narrative that starts with representations of the site, the
client’s requirements, and regulatory requirements, and first
designs building layouts with and without atrium. The Narrative
then elaborates on these initial layouts to generate different
alternatives, including designs with and without skylights, a
grass roof, and a raised floor. The Narrative then analyzes and
compares the atrium, skylight, grass roof, and raised floor
alternatives with respect to the more traditional strategies,
formalizes the costs and benefits of each of these strategies,
and finally develops a summary of the cost and benefits of
each strategy.
No Skylights
No Atrium
No Skylights
Atrium
Design
Enclosure
No Skylights
Atrium
Clients
Requirements
Design
Atrium
Massing
No Skylights
No Atrium
Analyze
Skylights
and Atrium
Design
Skylights
Skylights
and Atrium
Analyses
Skylights
No Atrium
Atrium
Raised Floor
HVAC Delivery
Construct
Site Model
Design
Traditional
HVAC Delivery
Assess
Costs-Benefits
Of Skylights
And Atrium
Skylights
And Atrium
Cost-Benefits
Daylighting
Reduced Energy Loads:
approx. 70% of lighting energy is
saved in areas where daylighting
is employed. In addition, electric
lamp replacement and cooling
loads are reduced.
Increased Productivity: Worker
productivity has increased
Simple Payback: 5.9 years
Reduced absenteeism:
Workers remain more alert, and
are absent less, under natural
lighting conditions.
Assess
Cost-Benefits
Of Grass Roof
Summary of
Cost-Benefit
Typical base-building cost: $100/sf
Area per person (MIS): approx. 200 sf
CapEx/person: $20,000
Green cost premium: 10% or $2,000
“Cost of green”: +/- $400 year/person
Skylights
Atrium
Grass Roof
Analyze
Roofs
Annual employee cost: $100,000
Value of 1% productivity increase:
$1,000/person/yr
Grass Roof
Cost-Benefits
Green Roof
Provides High Thermal
Resistance
Provides Acoustic Insulation:
attenuates sounds transmission
by up to 50 Db (nearby airport)
Increases Roof Life
Expectancy: roof membrane is
protected from mechanical
puncture, temperature
extremes and UV degradation
Design
Metal
Roof
Simple Payback: 8.8 years
Roofing
Analyses
Saves Energy: cooling effect
of roof assembly lowers the
cost of heating and cooling the
building
Creates Habitat: native plant
nursery
Cost-Benefits
Of Raised Floor
Skylights
Atrium
Metal Roof
Analyze
HVAC
Delivery
Raised Floor
Cost-Benefits
Indoor Air Quality – Raised Floor
Under floor HVAC System:
•Maintains temperature at
occupant level, reducing
cooling load 20%.
•Provides direct, superior
ventilation, total economizer
cycle
Site
Model
•Workers have complete
control of their environments
Simple Payback: 3.5 years
(2.6 for Plenum)
Operable Windows:
•Allows additional user
control as well as possible
“free cooling” from
ventilation during much of
the year.
Traditional
HVAC Delivery
Summarize
Cost-Benefits
Analysis
Value Proposition – Senior Executive Perspective
Design
Skylights
Skylights
Atrium
Design
Raised Floor
HVAC
First Cost
Analyses And
Comparison
Structural
Analyses and
Comparison
Design
Grass Roof
State Client
Requirements
Analyze and
Compare
First Cost
Analyze and
Compare
Structural
Skylights
No Atrium
Regulatory
Requirements
No Atrium
Summarize
and Compare
Analyses
Constructability
Analyses And
Comparison
Design
Enclosure
Design
Traditional
Massing
Life Cycle Cost
Analyses And
Comparison
2000
NS/NA Summer
NS/NA Winter
NS/A Summer
S/A Summer
S/A Winter
Document
Regulatory
Requirements
Analyze and
Compare
Life-Cycle Cost
Energy
Analyses And
Comparison
Average Lux Values in a Sustainable Office Building
HVAC Delivery
Analysis
Figure 5: A conceptual Narrative to formalize a cost-benefit analysis
•Total “churn” flexibility
1% of workday: 5 min.
CapEx payback: 1,000/400 = 2 ½ min.
1 day absentee: $50/hr. x 8 = $400
Reduce Contingent Liability -esp. IAQ
Depending on program, available data show
productivity gains of 4 -16%, particularly in the
MIS and clerical sectors.
Summary Of
Skylights Atriums
Analyses
Comparison
Find Deck Attachments Perspector
The Find Deck Attachments Perspector analyzes the Slabs
Perspective (produced by the Architect) and the Steel Framing
Perspective (produced by the Steel Detailer) to automatically
construct the Deck Attachments Perspecti ve. The Find Deck
Attachments Perspector also relates each deck attachment with
their associated slab and beams. This Perspector can be
decomposed into a sub Narrative that reformulates slabs and
beams then performs geometrical analyses and generates deck
attachments where they are required. A rendering of a typical
feature is shown under each representation.
Figure 6: Applying Narratives to the Deck Attachment test case.
A
B
Figure 7: Implementations of a Narrator that enables engineers to quickly connect reasoning and representations into
MDA Narratives. A. Our initial software, which implemented the deck attachment test case. B. A future implementation
of the Narrator mocked-up for the I-Room. In this scenario, the team is iteratively modifying a design of the building (the
left screen) as they work to achieve their project goals (right screen). The Narrative is on the center screen.
Design and Build a Framework:
Validation:
Figure 7A shows an initial framework, described in
Haymaker et al 2004b in which AEC professionals can
quickly construct and relate representation and reasoning
into MDA Narratives. The current implementation runs on
a single machine and handles only geometric
representations and reasoning. We are currently working
to construct a new implementation, called the Narrator
that addresses these limitations. Specifically, the Narrator
will be deployed in an I-Room setting, and enable
distributed and arbitrary representation and reasoning. See
Figure 7B.
Enabling project teams to define, communicate, integrate,
and automate their design processes better than current
methods allow. As illustrated in Figures 5 and 6, we find
the Narrative diagrams to be effective ways to define and
communicate a design process. Future work will use the
DEEPAND system (Garcia et al 2003) developed for
measuring meeting effectiveness. This approach measures
the time spent in a meeting Describing, Explaining,
Evaluating, Predicting, Analyzing, Negotiating, and
Deciding. The main hypothesis for measuring meetings in
this way is that certain activities (i.e., Describing,
Explaining) are less value adding than others, (i.e.,
Predicting, Analyzing).
The deck attachment case provides evidence that it is
possible to better control the integration of information
from multiple disciplines than was possible on a state-ofthe-art-project (Haymaker et al 2004 b & c). Future work
will measure the latency from the time a change occurs in
a source representation; to the time the corresponding
dependent representations are integrated. In Haymaker et
al 2004 c we showed that we were able to effectively
automate the design of 84 of the 86 deck attachments that
were required, but were field welded, in an area of the
WDCH project. Future work will measure the number of
design alternatives explored, the amount of time required
per alternative, and the accuracy and completeness of
automated representations compared to current practice.
CONCLUSION: A POWERFUL AND
GENERAL MODEL FOR MDA
AEC professionals need a simple, formal, expressive,
generic set of methods to help them communicate,
integrate, and automate their design processes; they must
be flexible enough to evolve with practice, yet powerful
enough to provide them with the information they need.
We propose that Narratives can provide this power and
flexibility. With adequate adoption and support,
Narratives could transform the way the AEC industry
practices design and construction. We seek methods that
will enable AEC professionals to weave together
Narratives that quickly, accurately, and where desired
persistently, communicate, integrate, and automate their
MDA processes.
REFERENCES
Autodesk (2004). Autodesk Revit, www.autodesk.com.
Bentley (2004). Microstation, www.microstation.com.
Date, C. J., and Darwen, H. (1993). A Guide to the SQL
Standard, Third Edition, Addison-Wesley Publishing
Company, Inc.
Dixon J., and Poli, C. (1995). Engineering Design and
Design for Manufacturing, Field Stone Publishers, MA.
DOE2, Department of Energy, http://www.doe2.com/.
Eastman, C. and Jeng, T-S. (1999). “A Database
Supporting Evolutionary Product Model Development
for Design.” Automation in Construction, 8 (3), 305-33.
Garcia et AL 2003 Meeting Details: Methods to
instrument meetings and use agenda voting to make them
more effective, Technical Report Nr. 147, Center For
Integrated Facility Engineering, Stanford University.
Haymaker, J., Ackermann, E.; and Fischer, M. (2000).
“Meaning Mediating Mechanism: A Prototype for
Constructing and Negotiating Meaning in Collaborative
Design,” Sixth International Conference on Artificial
Intelligence in Design, Kluwer Academic Publishers,
Dordrecht, The Netherlands, 691-715.
Haymaker J, Fischer M, Kunz J and Suter B (2004a).
“Engineering test cases to motivate the formalization of
an AEC project model as a directed acyclic graph of
views and dependencies,” ITcon Vol. 9, pg. 419-41,
http://www.itcon.org/2004/30
Haymaker J., Suter, B., Fischer, M., and Kunz, J. (2003b).
“The Perspective Approach: Enabling Engineers to
Construct and Integrate Geometric Views and Generate
an Evolving Project Model,” Working Paper Nr 081,
Center For Integrated Facility Engineering, Stanford
University.
Haymaker J., Kunz, J., Suter, B., and Fischer, M. (2004c).
“Perspectors: composable, reusable reasoning modules to
construct an engineering view from other engineering
views,” Advanced Engineering Informatics, Vol 18/1 pp
49-67
IAI (2003). Industry Foundation Classes, Version 2X2,
International Alliance for Operability http://www.iaiinternational.org/
ISO (1994) 10303-1: Industrial automation systems and
integration - Product data representation and exchange Part 1: Overview and fundamental principles.
Khedro, T., and Genesereth, M. R. (1994). “The
Federation Architecture for Interoperable Agent-Based
Concurrent Engineering Systems,” International Journal
on Concurrent Engineering,Research and Applications,
2:125-131.
Korman, T. M., and Tatum C. B. (2001). “Development
of a Knowledge-Based System to Improve Mechanical,
Electrical, and Plumbing Coordination," Technical
Report Nr 129, CIFE, Stanford University.
Lou, K., Subramaniam, J., Iyer, N., Kalyanaraman, Y.,
Prabhakar, S., Ramani, K. (2003). “A Reconfigurable,
Intelligent 3D Engineering Shape Search System Part II:
Database Indexing, Retrieval, and Clustering,” ASME
DETC 2003 Computers and Information in Engineering
(CIE) Conference, Chicago, Illinois.
Primavera
(2004).
Primavera
Engineering
and
Construction, http://www.primavera.com/
Onuma, K. (2002), Object Genome System, see
http://www.cif.org/nom2004/nom25_04.pdf
Radiance 2004, Lawrence Berkeley Laboratories,
http://radsite.lbl.gov/radiance/
Sacks, R., Eastman, C. M., and Lee, G. (2004).
“Parametric 3D modeling in building construction with
examples from precast concrete,” Automation in
Construction, 13(3), 291-312.
SAP2000,
CSIBerkely,
2004,
http://www.csiberkeley.com/products_SAP.html
Shah, J. and Mäntyla, M. (1995). Parametric and FeatureBased CAD/CAM, Wiley & Sons Inc., New York, NY.
Sriram D. R. (2002). Distributed & Integrated
Collaborative Engineering Design, Sarven Publishers.
Tekla (2003). XSteel, www.xsteel.xom.
Timberline
2004,
Timberline
Office,
http://www.timberline.com/