COMMUNICATING, INTEGRATING AND IMPROVING MULTIDISCIPLINARY DESIGN AND ANALYSIS NARRATIVES JOHN HAYMAKER, AIA, PHD Assistant Professor, Center for Facilities Integrated Engineering (CIFE), Department of Civil and Environmental Engineering, Stanford University, Building 550 Room 553G, Stanford, California,
[email protected]
BEN SUTER Research Engineer, Center for Facilities Integrated Engineering (CIFE), Department of Civil and Environmental Engineering, Stanford University, Building 550 Room 553 Stanford, California,
[email protected]
Abstract. AEC practitioners commonly use discipline-specific computer-based information modeling and analysis processes today. However, these practitioners lack simple, flexible, formal frameworks to communicate and integrate these processes and information amongst multiple disciplines. They therefore struggle to quickly and accurately achieve balanced and near-optimal multidisciplinary designs. To address these difficulties, we are designing and testing Narratives: formal, visual descriptions of the design process that include representations, reasoning, and their interrelationships. This paper presents several Narratives, and discusses how they can help AEC practitioners and students better communicate and integrate their design processes and information and thus potentially improve their designs.
1 Introduction: Existing methods do not adequately support the narrative nature of AEC Designing and constructing successful buildings is becoming increasing complex. Projects must achieve an increasing number of economy, ecology, and equity goals, and must therefore involve multidisciplinary design and analysis (MDA). MDA demands that Architecture, Engineering, and Construction (AEC) practitioners understand the interdependencies and
2
HAYMAKER & SUTER
make tradeoffs between their discipline-specific goals and the goals of other disciplines.
To achieve their goals, AEC practitioners produce tremendous amounts of information describing everything from existing conditions to project goals, design options, design analyses, construction documentation, fabrication and installation information, as-built, operation and demolition information. When constructing this information, they often consult other information produced by other practitioners and in other project phases, disciplines, or industries. AEC projects are iterative; AEC practitioners need to maintain the integrity of the information as the project evolves. AEC practitioners develop what one might 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.” We conceptualize an AEC narrative as a collection of information representations with explicit dependencies amongst them.
We observe that these narratives are often not adequately represented or managed today. AEC practitioners usually represent their information in either paper-based or electronic documents, but the dependencies between the information are not formally represented but rather stored in the heads of the practitioners. This way of constructing, communicating, and managing
NARRATIVES
3
multidisciplinary project information and processes is proving to be timeconsuming and error-prone.
We propose the AEC industry could benefit from theory and methods that enable practitioners to more easily yet formally communicate and integrate their narratives to meet a project’s unique social, cultural, economic, technical, environmental, and other goals and methods. Building on and extending prior work on representing, reasoning about, and managing engineering information and on frameworks to organize the design process, we are designing and implementing a generic, formal, expressive, simple, visual language and framework, called Narratives, for constructing and managing information representations and dependencies between these representations.
This
paper
briefly
summarizes
prior
observations
about
the
multidisciplinary, constructive, iterative, and unique character of AEC projects, and the difficulty AEC practitioners have communicating, integrating and improving their multidisciplinary processes and information on these projects. Next, the paper reviews the formalization of Narratives that we are designing to address this need, and discusses the AEC profession and related research with respect to representing and interrelating multidisciplinary project information. The paper then presents several implemented Narratives and discusses their ability to enable students and
4
HAYMAKER & SUTER
researchers to more quickly and accurately communicate and integrate MDA. Finally, the paper speculates on the ability of Narratives to help practitioners improve their designs, and discusses future work towards this goal.
2 Summary of case studies illustrating the narrative structure of AEC projects This section briefly reviews two case studies that illustrate the implicit narrative structure of AEC projects. Both projects are internationally recognized for their state-of–the-art use of technology; however, we illustrate that due to a lack of formal support for the narrative nature of the design process, the practitioners on these projects struggled to communicate and integrate, and thus to improve and balance their designs. 2.1 COST BENEFIT ANALYSIS FOR AN ATRIUM IN AN OFFICE BUILDING
In Haymaker et al 2006, we describe and diagram cases that detail the design process a project team including architects, mechanical engineers, construction managers and other consultants performed to determine the costs and benefits of employing different design strategies in the schematic design phase of a headquarters office building. In one example, the team wanted to know what the costs and benefits of employing skylights and an atrium would be. They studied industry data that 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
NARRATIVES
5
traditional, artificially illuminated space. 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. An implicit narrative of interrelated design and analysis representations were constructed to explore and answer these questions.
While the representations were explicit, the dependencies
between these representations were not formally described or managed. 2.2 DESIGN AND FABRICATION OF DECK ATTACHMENTS FOR A CONCERT HALL
In Haymaker et al 2004, we describe how a design and construction team detailed and fabricated the structural system for a concert hall during the construction phase. The architect constructed and integrated a representation describing the boundary of each concrete slab on the project. From this and other representations, the structural engineer constructed a representation describing the centerline of each steel member required for the frame of the building. Using this information, the steel detailer constructed a
6
HAYMAKER & SUTER
representation describing the boundary of each steel member and its fasteners. The metal decking detailer then constructed a representation describing where to install deck attachments to connect the metal decking for concrete floor slabs to the structural beams. The steel fabricator fabricated the beams, welding the required deck attachments to the respective beams in the shop. Again, while these representations were explicit, the dependencies between these representations were kept and managed only in the heads of these practitioners. 2.3 OBSERVATION: AEC PRACTITIONERS STRUGGLE TO COMMUNICATE, INTEGRATE THIER NARRATIVES, AND THUS BALANCE AND OPTIMIZE THEIR DESIGNS
In the cases, we observed that AEC practitioners had difficulty quickly and accurately: Communicating these design processes and information: No diagram or other formal description of these processes existed for either project. Rather, both processes existed only in the heads of the involved disciplines. These teams produced a series of design and analysis documents such as CAD models, spreadsheets, and text files, but they did not formally describe the dependencies between them.
The ability to formally represent the
dependencies between representations in the computer may have enabled the design teams to more quickly and accurately communicate their design processes to the other project participants. Integrating these design processes and information: On the concert hall, constructing and integrating the deck attachments representation cost the
NARRATIVES
7
decking detailer over 140 hours and required over $160,000 worth of field welding that might have been avoided with better integration. On the office building, the design team also found it difficult to maintain the integration of all of the various analysis representations. For example, to explore a variation on an atrium option required several weeks, and errors and inconsistencies between representations occurred along the way. Improving these design processes and information:
Both projects had
difficulty optimizing their multidisciplinary designs. For example, they could not communicate and integrate this process quickly enough to iteratively modify the slab and beam designs and minimize the size and number of deck attachment, and many deck attachments required more costly, time-consuming, and less safe field welding. On the office building the design team was 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 observed the narrative structure to these design processes and proposed requirements for a framework that would enable an AEC practitioner to be able to formalize and mange them. 2.4 REQUIREMENTS: TO FORMALIZE AND MANAGE NARRATIVES
We proposed that AEC practitioners could have addressed the difficulties listed above by better formalizing and controlling their design processes and information. For practitioners to work in this way the methods must yield
8
HAYMAKER & SUTER
benefits that warrant the added cost of documenting and managing this dependency information. To help keep the cost of these methods low and the benefits high, such methods should be adequately: Generic: To apply across many different AEC disciplines. Expressive: To describe the many types of information and dependencies practitioners need. Formal: To enable communication to other AEC practitioners and to be implemented in a computer. Simple: To enable broad understanding, acceptance, and use by engineers, and to enable revision as the project unfolds and new information and dependencies emerge. Visual: To engage spatial thinking and engender collaboration.
We proposed methods to construct information and specify its dependency on other information and methods to control the integration of this information as the project progresses. A formal Narrative can emerge as AEC practitioners iteratively apply these methods. We proposed the following
methods,
categorized
as
representation,
reasoning,
and
management methods: Representation: AEC practitioners need methods to represent their taskspecific information. There is a wealth of representations already developed by existing standards bodies (i.e., STEP, IFC, etc.) and private companies (i.e., AutoCad, Microsoft, etc.). However, these practitioners also need methods to represent the dependencies between the information. While acknowledging that the dependencies between information can often be cyclical--for example, the architect may revise the location of slabs or beams based on the number and size of deck attachments--this research investigates
NARRATIVES
9
the conceptual simplicity of formalizing a project model as a directed acyclic graph (DAG) of information and dependencies. From observations on the test cases, the majority of the information dependencies are one directional; in the spirit of simplicity we believed directed dependencies are worth exploring. AEC practitioners can manually manage the cycles in the dependencies.
We proposed the following relationships and attributes to represent the dependency between information and its source information: Sources: The source information on which dependent information depends. For example, the Deck Attachments representation depends on the Steel Framing and Concrete Slabs representations. Status: The integration status of the information with respect to its source information. For example, when a Steel Framing or Concrete Slabs representation is modified, the Deck Attachments representation’s status becomes Not_Integrated. Nature: The reasoning method (automated or manual) that constructs the dependent information from source information. For example, the decking detailer uses reasoning to construct the Deck Attachments representation from the Steel Framing and Concrete Slabs representations. Today, much of this reasoning is implicit, happening only in the heads of the AEC practitioners.
Figure 1A diagrams our formalization of the dependency of dependent information on source information(s). Figure 1B shows how a formal Narrative can emerge from the iterative application of this method. In a Narrative, we often call the information a “Perspective”, and the reasoning a “Perspector” to differentiate them from other representation and reasoning that are not interrelated in this way.
10
HAYMAKER & SUTER
Reasoning (automated)
B.
A.
Reasoning (manual) Information Reasoning Information Information
Nature of dependency Status of dependency Sources of dependency
Information
Source Information
Dependent Information
Narrative
Using Which Tool? Using Which Source Information? What Does It Look Like?
Figure 1: Formalizing the dependency between task-specific information. A. Formalizing the sources, nature, and status of the dependency of dependent information on source information. B. A Narrative emerges from the repeated application of the formalism described in A. C. We currently display Narratives according to this convention. D. A Narrative to describe part of the process in Section 2.2.
Reasoning: AEC practitioners could benefit from methods to define the nature of the dependency. In many cases computer algorithms already exist that help AEC practitioners construct useful dependent information. For example, today it is possible to use software that automatically constructs 2D plans and sections, and other software that performs energy, daylight, or structural analyses from 3D models. AEC practitioners should be able to easily associate these “off-the-shelf” reasoning tools into Narratives.
NARRATIVES
11
In other cases, due to the unique nature of AEC projects, no such automated reasoning exists. For example, no algorithm exists for constructing a Deck Attachments representation from Slabs and Beams representations, or for constructing an atrium design from site and requirements information and then analyzing that design for project specific goals. AEC practitioners should be able to easily define project-specific automated reasoning where possible.
In other cases, it is not possible, desirable, or economically feasible to define automated reasoning. Therefore AEC practitioners should be able to specify that the nature of the reasoning is manual. In these cases, they it should be possible to specify that a computer tool (such as a CAD program) or data format (such as .dwg) should be used to construct the dependent information. Figure 1B shows that a Narrative can contain a mixture of manual (denoted by a human icon) or automated (denoted by a gears icon) reasoning.
Management: Engineers could use methods to manage the integration of these information and processes, so that they can iteratively construct their information and receive notification when the information on which they depend has been reconstructed.
12
HAYMAKER & SUTER
For example, the engineer responsible for the deck attachments representation should be able to easily construct the dependencies on the steel framing and concrete slabs representations, receive notification when these source representations are modified, and be able to (re)construct the deck attachments representation. Other engineers should be able to construct and
control
dependent
representations
of
the
deck
attachments
representation.
3 Points of departure: Approaches to building information modeling This section discusses related efforts in research and practice in the area of representing, reasoning about, and managing building information, and in communicating design processes. 3.1 REPRESENTATION
There are numerous ways to represent AEC information. Most AEC projects today rely on proprietary and task-specific information formats. This can result in serious interoperability difficulties when different project participants adopt different proprietary and task-specific solutions. To address these difficulties, industry and government have initiated major efforts in the area of engineering data standards, including STEP (Standard for the Exchange of Product data (ISO, 1994)) and IFC (Industry Foundation Classes (IAI, 2006)). However, the cases suggest that engineers need to represent the sources, status, and nature of the dependencies between information. As currently formalized, these standard representation
NARRATIVES
13
languages do not contain a simple, formal, explicit, generic, and visual way to represent these attributes of dependencies. 3.2 REASONING
AEC practitioners are using computer programs that automatically construct useful task-specific dependent information from source information in practice today. They are performing daylight analysis, energy analysis, structural analysis, and cost estimating, among other uses. Considerable research is devoted to improve on and extend these suites of pre-defined task-specific, automated design, and analysis programs. Generally, in such systems, a computer programmer with engineering knowledge programs task-specific reasoning that transforms source information into task-specific dependent information that is limited to the concepts formalized by the programmers. Other approaches to constructing task-specific representations of project information are more generic. Query languagess (i.e., Date and Darwen 1993, Hakim and Garrett 1997) enable the automatic selection or limited transformation of information in a model into a view. Feature Recognition (Dixon and Poli 1995) identifies and formally represents instances of feature classes in a geometric model. Lou et al 2003 investigates generic CAD query languages that enable engineers to query a model for geometric features. XSL (W3C 2005) is a language with which to transform XML representations into other XML representations. However, existing task-specific reasoning tools and generic query languages are not fully leveraged in AEC practice today. This may be in part because these projects
14
HAYMAKER & SUTER
have lacked a simple, generic, formal, expressive, visual framework that enables engineers to quickly and accurately interrelate their task-specific representations and reasoning by their dependencies and control their integration as the project progresses. 3.3 MANAGEMENT
An increasing number of researchers and industry practitioners are recognizing the need to formalize management approaches that support evolving information and processes for AEC projects. Some of these approaches (i.e., Eastman and Jeng 1999, Haymaker et al 2000, Sacks et al 2004) develop reasoning and management that constructs and controls dependencies of information as views of a central model. This system architecture is finding its way into commercial applications (i.e., IES 2005). Others (Khedro and Genesereth 1994, Rosenman and Gero 1996, Mackellar and Peckham 1998, Sriram 2002, develop similar reasoning and management approaches that construct and control dependencies between information in a federation of predefined task-specific views. This system architecture is also finding its way into commercial applications. In both these central and federated model approaches, system programmers are generally required to construct the nature of the dependencies, and the narratives are thus predetermined.
Parametric techniques (Shah and Mäntyla, 1995) enable practitioners to define sets of related numeric or symbolic equations that can be solved to
NARRATIVES
15
realize feasible geometric designs. Commercially available parametric modelers, such as CATIA, provide tools to assist engineers in generating 2D sketches from which 3D form features are parametrically generated and in specifying the assemblies 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 Tekla Xsteel, Autodesk Revit, Bentley’s Generative Components,
and
Onuma’s
Object
Genome
System,
and
Gehry
Technology’s Digital Project (itself a derivative of CATIA). These systems allow designers to parametrically define most often geometric objects such as walls, windows, doors, and other geometric objects in terms of their properties and relations to other objects. While some successes are being reported within the context of single domains, parametric techniques are not being widely used in the AEC industry to integrate the work of multiple disciplines. This may be in part because, as currently formalized, these techniques
have
not
adequately
supported
the
multidisciplinary,
constructive, iterative, and unique nature of AEC projects: They do not enable practitioners to easily and formally construct new representations from information in other practitioners’ representations, and to control the integration of these representations as the project progresses. It may also be in part because they have lacked intuitive user-interfaces to communicate the dependencies between the information.
16
HAYMAKER & SUTER
Project scheduling systems, such as Primavera are task-focused, graph-based representations of a project. They represent precedence dependencies among tasks and are used to calculate issues such as project duration and critical paths. 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 management frameworks do not provide adequately simple, formal, generic, expressive, visual methods that AEC practitioners need to construct and control their MDA narratives. Instead practitioners are utilizing a hodgepodge of AEC systems without explicit connections, complicating the communication and integration of multidisciplinary information and processes. 3.4 FORMAL DESIGN DOCUMENTATION METHODS
Issue-based information systems (Kunz and Rittel, 1970) aim to enable designers to model and communicate their design rationale by recording the issues addressed, options considered, and the arguments both pro and con. These systems have used graph or tree based representations to structure and communicate these arguments. These concepts have been extended to, for example, enable information representations to be stored with each element in these graphs (Bracewell et al 2004), however, to our knowledge, these systems have not yet emphasized the formal nature and status of the
NARRATIVES
17
dependencies between these representations, and have not provided management processes to automatically manage these dependencies.
Design Structure Matrix (DSM) (Eppinger et al 1990, Steward, 1981, Austin et al, 2001) is a compact, matrix representation of a system or project. The matrix contains a list of constituent activities and the corresponding information exchange and dependency patterns. Most DSM’s contain a list of tasks, and a formalization of the existence of an information dependency between the tasks. However, these representations do not contain a link to the actual information contained and processed at each task, nor do they represent the nature and the status of the dependencies between this information. Interestingly, the DSM was developed as an alternative to graph-based views of the project, in part because these researchers found the graph view non-communicative. Perhaps today’s better graph visualizations toolkits and larger display capabilities make graph-based visualizations of these dependencies worth reinvestigating.
Building Stories (Martin et al, 2005) capture design processes through an activity-artifact model, where activities embody the actions performed and the artifacts embody the information they create. Building stories are generally intended to capture the design process for use in explaining design rationale, and to be retrieved for use on subsequent projects. Building Stories do not contain a formal representation of the status and nature of the
18
HAYMAKER & SUTER
dependencies between information, and the authors have not emphasized their use as an active design integration tool.
4 Formalizing and implementing MDA Narratives This section presents several Narratives and discusses the potential communication, integration and design improvement benefits. 4.1 COMMUNICATION
Figure 2 presents a Narrative to formalize the cost-benefit analysis of the office building described in Section 2.1. The connections between representations are formally described. While the figure is perhaps daunting at first, we have found that once understood, this notation (Figure 1 is all there is to learn) simply and generically communicates important information about the dependencies between representations (the sources, status, and nature). As the figure shows, any reasoning node in this Narrative can itself be decomposed into a Narrative. Such decomposition aids in the thought process when constructing a Narrative, as well as the communicative ability of a composed Narrative.
NARRATIVES
Light Windows Contribution Atrium
Skylights Compare Light Consistency
Daylight Analysis No Skylights Atrium
Daylight Analysis And Comparison Analyze and Compare Day Light
0.12 Light 0.1 Distribution 0.08
sensor 4
Light Shelf
sensor 1 Compare Illuminance Values inside
Daylight Analysis Skylights No Atrium
0.06 0.04 0.02 0 outs ide
Parameters No Skylights For Daylight Atrium Analysis
0.14
Daylight Factor
Analyze Daylight
Enter Parameters
Summarize
Light Shelf Illuminance Comparison
ins ide
Analyze Daylight
outs ide
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
19
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.
10000
No Skylights No Atrium
lx
8000
Daylight Analysis No Skylights No Atrium
6000 4000
0
1 1251.9 16667 1671.1 66667
NS/A Summer
2021.75
NS/A Winter
1873.25
S/A Summer
2024.1 66667
S/A Winter
2513.1 66667
2
3
1936.833333 2512
4
2432.833 333
673.6666667
5 1015.416667
6
606.75
822
1 274.25
2468.2 5
2252.083333
1554.833333
1511 .916667
2810.583 333
11221.08333
2248.75
3191
5823.916667
2481.666667
5 284.25
2554.166 667
11458.66667
2686.083333
2355 .666667
1954.583333 2798 .25
Analyze and Compare Constructability
1331 .583333
2850.2 5
1934 .25 1971.166667
2305.5
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
State Client Requirements
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
Summarize Cost-Benefits Analysis
Summary of Cost-Benefit
Value Proposition – Senior Executive Perspective
Design Skylights
Skylights Atrium Design Raised Floor HVAC
Summary Of Skylights Atriums Analyses Comparison
First Cost Analyses And Comparison
Structural Analyses and Comparison
Design Grass Roof No Skylights Atrium
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
1st Floor(1-3) 2nd Floor(4-6) Atrium(1/4) Central(2/5) Perimeter/Windows(3/6)
Document Regulatory Requirements
Analyze and Compare Life-Cycle Cost
Energy Analyses And Comparison
Average Lux Values in a Sustainable Office Building
14000
12000
Typical base-building cost: $100/sf Area per person (MIS): approx. 200 sf
Skylights Atrium Grass Roof
Analyze Roofs
CapEx/person: $20,000 Green cost premium: 10% or $2,000 “Cost of green”: +/- $400 year/person Annual employee cost: $100,000
Grass Roof Cost-Benefits
Green Roof
Provides High Thermal Resistance
Provides Acoustic Insulation: attenuates sounds transmission by up to 50 Db (nearby airport)
Value of 1% productivity increase: $1,000/person/yr 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.
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
HVAC Delivery Analysis
•Total “churn” flexibility
Figure 2: A Narrative to formalize a cost-benefit analysis of the atrium and skylights on an office building. The author composed this Narrative using PowerPoint
In Stanford CEE 111: 3D Multidisciplinary Design and Analysis, students are asked to form teams and devise a project that uses at least two computer
20
HAYMAKER & SUTER
analyses tools to answer a question about a real world problem. This year, we asked groups of students to describe the processes and information they are using for their project in terms of Narratives. We found the Narratives help very clearly communicate the planned process to team members, to the remainder of the class, and to the professor. Figure 3 shows one Narrative.
The Narrative describes how, starting with an architect’s initial rough sketch for a project, the students explored 2 different hallway configurations for their daylight, ventilation, and energy impacts. The students then took the results of these analyses, and compared the designs for their integrated performance. Each Perspective in this Narrative has associated with it, a sub Narrative describing each student’s processes, accessed by clicking on the hyperlinked text. The students created these Narratives in PowerPoint.
NARRATIVES
21 Devin Analyze Energy Use Using eQuest
Baseline Hallway Energy Use Charts Charlie Analyze Ventilation Using IES MicroFlo Engin Model Hallway Using IES Model IT
Engin Design Hallway Using Revit
Baseline Hallway 3D Model
Baseline Hallway Ventilation Distribution Charts Engin Analyze Daylight Using IES Radiance
EnginCharlieDevin Compare Designs Using Excel
Baseline Hallway Daylight Distribution Charts
Baseline Hallway Plan
Cost Benefit Analysi Hallway Designs
Engin Analyze Daylight Using IES Radiance
EHDD Design Layout Using AutoCAD Charlie Design Hallway Schematic Plans UsingSketchUp Of Green Dorm’s Improved Hallway Plan
CharlieEngin Model Hallway Using IES Model IT
Improved Hallway Daylight Distribution Charts Charlie Analyze Ventilation Using IES MicroFlo
Improved Hallway 3D Model Improved Hallway Ventilation Devin Distribution ChartsAnalyze Energy Use Using eQuest
Improved Hallway Energy Charts
Figure 3: A Narrative designed by a group of students in Stanford University’s CEE 111: Multidisciplinary Design and Analyses class, to describe their class project.
Figure 4, shows an implemented Narrator, a tool for constructing Narratives. Written in Java, this desktop application is designed to help quickly and visually compose Narratives. It enables a practitioner to construct new Narratives, add Perspectives, modify the titles and previews of Perspectives and Perspectors, and link to content.
22
HAYMAKER & SUTER
Figure 4: The Narrator, which was implemented to enable AEC practitioners to diagram and communicate Narratives. In this Narrative, a research student is describing a model based Life Cycle Impact Analysis comparing a Steel and Wood design for a dormitory project. As shown, clicking on a particular preview will enlarge it to give a better view of the information contained in that Perspective.
4.2 INTEGRATION
In Haymaker et al 2004b & c, we introduced the Geometric Narrator as a framework in which AEC practitioners can automate Narratives of geometric representations and reasoning. We showed how the deck attachments representation (described in Section 2.1) can be constructed from the Concrete Slabs and Steel Framing representations by constructing a Narrative that analyzes the beams and slabs to generate the deck attachments.
Figure 5 diagrams this Narrative. Figure 6A shows the
Geometric Narrator with the Find Deck Attachments Narrative, and Figure 6B&C show another Narrative that automatically analyzes a concert hall
NARRATIVES
23
ceiling for structural cantilever conditions. This implementation runs on a single windows machine and handles only geometric representations and reasoning.
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 Perspective. 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 5: Applying Narratives to the Deck Attachment test case.
A.
B.
C.
Figure 6: Our initial prototype for a Narrator that enables engineers to quickly connect reasoning and representations into Narratives. A. The framework used on the deck attachment test case. B. The framework was also used on a Narrative that analyzed the concert hall ceiling system for cantilevered conditions before integrating the Narrative, and C. after integrating the Narrative, cantilever conditions are automatically identified.
24
HAYMAKER & SUTER
When source information such as concrete slabs, steel beams, ceiling panels, or ceiling panel supports representations are modified the framework notifies dependent representations that they are no longer integrated. The engineer can then automatically re-integrate the dependent representation by reconstructing the deck attachments. Figure 7 provides some evidence for the ability of these Narratives to improve the accuracy of integration. Figure 8 provides some evidence for the ability of these Narratives to improve the speed of integration.
Accuracy Correctly Identified False Positives False Negatives Completeness Amount of detail
WDCH Perspectors 86 Deck Attachments Required 0 84 0 28 86 2
Significant improvement over current practice is possible. Further improvement possible with additional Perspectors. Automation could make creating more useful additional detail costeffective.
Figure 7: Evidence for accuracy of integration: The left drawing shows the as-built Deck Attachments on a portion of the concert hall. AEC practitioners failed to shop weld any of these deck attachments due to integration difficulties. The right drawing shows that we were able to automatically identify and design over 98 % of the required deck attachments, making shop welding far more likely. The false positives were because the Narrative designed deck attachments on “stiffener beams” which have short spans, and do not require deck attachments. The Deck Attachment Narrative could be improved to eliminate the stiffener beams automatically, or the designer could remove the stiffener beams manually.
T im e (h o u rs:m in u tes)
NARRATIVES
25
Manually Constructed by Students using AutoCAD
4:19:12 3:50:24 3:21:36 2:52:48 2:24:00 1:55:12 1:26:24 0:57:36 0:28:48 0:00:00
Automatically Constructed by Students using Geometric Narrator
0
5
10
15 20
25
30
35
40
45
50
55
60 65
70
75
80
Number of deck attachments designed
Figure 8: Evidence for speed of integration: Students of varying CAD skills were asked to manually design deck attachments for the steel and concrete designs using AutoCAD. Students were then asked to design deck attachments automatically, using the Narrator and the predefined Find Deck Attachments Narrative. The graph illustrates significant time advantages are possible using the Narrator.
4.3 IMPROVING DESIGNS
According to the architects in the office building case study described in Section 2.1, the project should “combine aesthetic rhyme with architectural reason, environmental sensitivity with operational efficiency, the diverse needs of individual employees with the scale and flexibility required by a growing company” (Bay Area Council 2000). The question remains: to what extent did they achieve these goals? Figure 9 shows a Narrative to measure these overall goals on six axes of a spider diagram. Each goal is measured by an interrelated collection of Narratives. For example, this architect describes environmental sensitivity in terms of several sub goals related to: access to fresh air, indoor air quality, integration with surroundings, energy, site, material flows, water, and access to light. Further sub Narratives would measure each of these sub goals. For example, the architect describes energy
26
HAYMAKER & SUTER
efficiency in terms of: embedded energy in materials, building energy use, people and transit, renewable resources, and construction processes. Ultimately, these Narratives interweave other types of representation and reasoning, such as CAD drawings describing design options, analysis data describing energy calculations, and other types of representations. Ideally, the connections between these representations could all be formal. Modifications to any information could propagate through the Narrative, reflecting any changes to the overview of the six goals of the project. This could enable far more options to be explored and analyses to be performed. When formal, automated connections are not possible, AEC practitioners could continue their current practice of using manual connections, but with help from the computer for communicating and integrating these Narratives and the status of their integration. For example the Narrative in Figure 9, shows that the measurement of aesthetics could simply involve asking four human design critics for their opinions.
Our intuition, although not yet tested, is that Narratives can help designers collaboratively explore and analyze more options more quickly, and this will lead to improved designs.
NARRATIVES
27
Sustainable balance?
What does it look like?
Sustainable balance
Building design
9 8 7.5 8
Environmental sensitivity
Energy Consumption
MWh
Cooling Heating
M
A
M
J
J
A
S
O
N
D
Month
M Fl ate ow ria s l Site
Embedded Energy In Materials n ctio stru s Con oce sse Pr
Fan
En B u e r ildi gy ng Us e le ab e s w c ne ur Re e so R
gy
Building energy use
Integration With Surroundings er En
Energy
Pe o p T ranle & sit
Water
How much energy?
F
ss t ce igh Ac o L T
How effective with energy ?
J
Architectural Reason
Access To Fresh Air Ai In r Q do ua or lit y
Daylight analysis
Op Eff e rat ici ion e n al cy
Critic 1 Critic 2 Critic 3 Critic 4
Diverse Needs Of Individuals
How environmentally sensitive?
l nta me y on iv it v ir sit En Se n
Aesthetic analysis Aesthetic Score How does daylight enter?
Ae s Rh the t ym ic e
y ilit h xib wt Fler Gro Fo
How aesthetic?
Legend Perspector dependency Perspective
Figure 9: A Narrative to measure a project in terms of high level goals.
5 Ongoing Work We are currently extending the research in the following ways:
Enable distributed representation and reasoning: AEC projects are distributed, often globally. Connecting the geographically distributed representations and reasoning of many disciplines is an important benefit that the federated architecture of Narratives can provide. We are investigating web-based technologies to allow Narratives that can be distributed over the web.
Incorporate any data types and reasoning: The test cases show that the types of representation and reasoning required on AEC projects are very
28
HAYMAKER & SUTER
diverse. Narratives must be able to integrate these diverse methods of representing and reasoning about AEC information in a simple, generic, expressive, yet formal framework. We are investigating ways to build a framework that is agnostic to types of representation and reasoning beyond the simple formalization of dependency described in this paper.
User Interface and immersive information environments: Narratives contain a great deal of information. Enabling AEC practitioners to visualize and interact with the representations and the dependencies in a fluid manner is critical to enabling practitioners to understand and make informed MDA decisions. We are working on more intuitive graph-based interfaces, and deploying the framework in interactive workspaces to enable improved user interaction with the Narratives. Figure 10 mocks up a proposed Narrator in the CIFE I-Room. Users iteratively view and construct the dependencies of the Narrative on the center screen, while they modify and view source and dependent representations on the other screens. The figure shows a scenario where different practitioners iteratively modify the building geometry and automatically receive feedback as to the design performance based on their multidisciplinary goals of the project.
NARRATIVES
29
Figure 10: A mock-up of the Narrator in the I-Room. In this scenario, the team is iteratively modifying a design of the building (the left screen) as they attempt to achieve and exceed their project goals (right screen). The Narrative (center screen) describes and manages the dependencies of several task-specific design and analysis data models.
6 Conclusion Today’s methods for multidisciplinary design and analysis are not working as effectively as they must to enable optimal integrated multidisciplinary design. AEC practitioners need a toolset with which to more effectively communicate and integrate their information and processes. Given the multidisciplinary, constructive, iterative, and unique nature of AEC projects, this proposed toolset will need to be flexible to adapt to changing conditions during projects, and to evolve with practice and technology from one project to the next. This paper reports on ongoing work to formulate and validate a framework and language called Narratives that we hope can provide this power and flexibility, and discusses the benefits of Narratives for communicating, integrating and improving multidisciplinary design and analysis processes.
30
HAYMAKER & SUTER
Ideally, many of the connections in Narratives could be formal and automated. Modifications to any representation could rapidly propagate through the Narrative, reflecting any changes as impacts on the goals of a project. When formal, automated connections are not possible, AEC practitioners could continue their current practice of using manual connections. The transition to formalized and supported Narratives can be evolutionary and helpful, incorporating today’s AEC computer tools; they are not meant to provide constraining meta-solutions that replace individual know-how and creativity. They are intended to integrate our greatest advances in information technology with the collaborative and creative human process of design and innovation.
Acknowledgements Martin Fischer, John Kunz, Engin Ayaz, Jen Tobias, William McDonough Partners, MA. Mortenson Company, and many other firms and individuals from the Center for Integrated Facilities Engineering have contributed greatly to this work.
Responses To Questions posed at DCC ‘06 Question: Is the idea that you can reuse these narratives in future building stories and then you can find them and adapt them in a case-based method? Question Asked By: Mark D Gross, Carnegie Mellon University
NARRATIVES
31
It would be very interesting to have Narratives auto-complete as you construct them. Narratives could be retrieved using Narrative meta-data, graph content and topology, and individual Perspective information. More research is needed to determine the requirements for the repository, search algorithms and user interface that can enable such search. --------------------------Question: Trying to collect design information in the past failed frequently because explicit expression of that was not an integral part of the process or workflow. It is an additional task that nobody wants to handle. In particular, there exists fear in the legal community about too much information. How can this be overcome? Question Asked By: Volker Mueller, NBBJ Ultimately the benefits must outweigh the costs. We attempted to formulate our requirements to tip the balance. Our intuition is that with very simple, visual, flexible, generic, formal tools the process of collecting this information can decrease while the benefits of communicating, integrating and automating it can increase.
In response to the legal aspect of the question, Narratives try to support the current work processes of AEC teams by enabling different disciplines to construct and control their own task specific information. They add support to explicitly describe and maintain the dependencies between information. We find that the Narrative formalism helps represent this information fairly unambiguously. Perhaps this could lead to more straightforward social and legal, as well as technical interoperability. ----------------Question: What happens when you have a real narrative - all of these horrible things that go wrong on a real construction site. What do you do with these stories which could be captured as text or audio which are rich and difficult to capture and index? Question Asked By: Claudia Eckert, University of Cambridge One might try to capture text, images, or audio by adding it as source or dependent Perspectives in a Narrative, Alternatively, one might explore new ways to associate this information with a Narrative. Narratives, like any model, are only partial descriptions of the design process. Some types of information may be best captured and displayed in other ways. In Haymaker et al 2006, we explored integrating the Narrative methodology, which captures and manages dependencies, with two other CIFE methodologies:
32
HAYMAKER & SUTER
the Decision Dashboard, which captures and analyzes design alternatives, and POP Modeling, which classifies information. Similar research might investigate integrating Narratives with unstructured information that occurs as a project unfolds. For example, below is a figure that shows how we overlaid a Narrative on top of a time-line to create a class schedule by adding the explicit notion of time.
Figure 11: A Narrative overlaid on a timeline.
References Austin S, Steele J, Macmillan S, Kirby P and Spence R, (2001), ‘Mapping the conceptual design activity of interdisciplinary teams’, Design Studies, Vol. 22, No. 3, pp 211-32 Bay Area Council, (2000), “Environmental Building Design, (901 Cherry Offices) at Gap Inc.”, Best Practices, Bay Area Council, http://bacqube.bayareacouncil.org/bp/bestpractices/bp185.html Bracewell, R.H., Ahmed, S. And Wallace, K.M. (2004), 'DRed and design folders: a way of caputuring, storing and passing on - knowledge generated during design projects' in Design Automation Conference, ASME, Salt Lake City, Utah, USA, Date, C. J., and Darwen, H. (1993). A Guide to the SQL Standard, Third Edition, AddisonWesley Publishing Company, Inc. Dixon J., and Poli, C. (1995). Engineering Design and Design for Manufacturing, Field Stone Publishers, MA. Eastman, C. and Jeng, T-S. (1999). “A Database Supporting Evolutionary Product Model Development for Design.” Automation in Construction, 8 (3), 305-33. Eppinger, S., Whitney, D., Smith, R.. and Gebala, D., (1990), "Organizing the Tasks in Complex Design Projects," ASME Conference on Design Theory and Methodology, Chicago, IL, September, pp. 39-46. Fischer, Martin, and Froese, Thomas (1996). "Examples and Characteristics of Shared Project Models." Journal of Computing in Civil Engineering, ASCE, 10(3), 174-182. Hakim, M. M. and Garrett Jr., J. H (1997). “An Object-Centered Approach for Modeling Engineering Design Products: Combining Description Logic and Object-Oriented Models," Journal of AI in Engineering Design and Manufacturing (AI EDAM), Vol. 11, 187-98. 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,
NARRATIVES
33
Haymaker J, Fischer M, Kunz J and Suter B (2004). “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, Ayaz E, Fischer M, Kam C, Kunz J, Ramsey M, Suter B and Toledo M (2006) Managing and communicating information on the Stanford Living Laboratory feasibility study, ITcon Vol. 11, Special Issue Process Modelling, Process Management and Collaboration , pg. 607-626, http://www.itcon.org/2006/42 Hollings J. (2004), A Managed Environment for Plants, Bentley Systems, Incorporated, ftp://ftp.bentley.com/pub/outgoing/Bentley_Plant_Managed_Environment_White_Paperp dfhi.pdf IAI (2006). Industry Foundation Classes, Version 2X2, International Alliance for Operability http://www.iai-international.org/ IES (2005) . Integrated Environment Solutions, http://www.iesve.com/ 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. Kunz, W., & Rittel H. (1970). Issues as elements of information systems. Working Paper No. 131, Institute of Urban and Regional Development, University of California at Berkeley, Berkeley, California, 1970. 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. MacKellar, B. and Peckam, J. (1998). “Multiple Perspectives of Design Objects,” Artificial Intelligence in Design, eds. John Gero and Fay Sudweeks, Klewer Academic Publishers, 87-106. Martin, M., Heylighen, A., Cavallin, H. (2005), “The right story at the right time”, AI & Society, Volume 19, Number 1, January, 34-47 Rosenman, M. A. and Gero, J. S. (1996). “Modeling Multiple Views of Design Objects in a Collaborative CAD Environment,” CAD, Special Issue on AI in Design, 28(3), 207-21. Shah, J. and Mäntyla, M. (1995). Parametric and Feature-Based CAD/CAM, Wiley & Sons Inc., New York, NY. Sriram D. R. (2002). Distributed & Integrated Collaborative Engineering Design, Sarven Publishers. Steward, Donald V., (1981), "The Design Structure System: A Method for Managing the Design of Complex Systems" IEEE Transactions on Engineering Management, vol. 28, pp. 71-74. W3C (2005). Extensible Markup Language, http://www.w3.org/XML/
