CIFE Center for Integrated Facility Engineering •Stanford University
CIFE Seed Proposal Summary Page
2008-2009 Projects
Proposal Title: Communicating, and Integrating, and Visualizing Multi-Disciplinary Design Processes
Principal Investigator(s): John Haymaker, Vladlen Koltun
Research Staff: Reid Senescu, Forest Flager, Ben Welle
Proposal Number: (Assigned by CIFE):
Total Funds Requested: $120,000
First Submission?
/Yes
/If extension, project URL:
Abstract (up to 150 words):
Despite advances in Building Information Modelling (BIM) and building simulations, ineffective communication and integration of process limits industry’s ability to improve design. Current projects at CIFE are refining the characteristics and metrics for effective communication and integration of processes by reviewing literature in process modelling and human computer interaction, and observing and measuring current practice. In this seed project, we propose to create and test an open-source tool called PIP (Process Information Platform) that aims to help distributed and collocated multidisciplinary teams to iteratively define, manage, share, and their interoperable design processes. We use a hypothetical Narrative to demonstrate the characteristics and metrics of PIP. We propose to implement PIP, and to measure its effectiveness in helping multidisciplinary design teams communicate, integrate, and visualize the results of their design processes, resulting in faster and more sustainable buildings.
Despite the influx of Building Information Modeling (BIM) and advanced building simulations, ineffective information exchange still limits the building industry’s ability to improve design processes. We propose creating a methodology and tool called Process for Continuous Improvement of Process (P-cip) that aims to improve the development and sharing of interoperable design processes. First, we will research characteristics for effective development and sharing of processes. Next, we will choose metrics to evaluate process development and sharing, and we will use these metrics to measure current practice. We will leverage research in information visualization and human computer interaction to develop new methods for recording and visualizing the evolution of project information. Finally, we will create a prototype user interface for P-cip. In this proposal, we use a hypothetical narrative to demonstrate the steps of the research and explain the characteristics of P-cip.
1 Introduction: If BIM is arevolutionizes the pProcess, wWhere is BIM?the revolution?
To some, BIM is a process (Eastman 2007). To many others, BIM at the very least changes the design process (Autodesk; Government Services Agency 2007). The association of BIM with process change pervades Architecture, Engineering and Construction (AEC). Yet, little commercial development of BIM is process-centric, and the major BIM-authoring tools do not provide explicit support for defining and sharing processes. Parametric capabilities offer one possible exception as they formalize a new process, but parametric tools still lack transparency, limiting broader process change. Despite the rhetoric that BIM fundamentally shifts design processes, the industry generally still plug the new tools into a process that predates computers. While the capabilities of simulation and modeling and simulation tools expand, order of magnitude increases in design process efficiency and effectiveness remain elusive.
This proposal uses an example from current practice to demonstrate how current limitations in interoperability the way teams communicate and manage processes limit BIM’s promise to drastically improve design process efficiency and effectiveness.[1] Rather than propose specific interoperability[2] solutions, the proposal reviews why previous efforts at a single solution have been unsuccessful. The proposal then uses a Narrative (Haymaker 2006) to describe the characteristics of a tool, Called Process Process Integration Platform for Continuous Improvement to Process (P-cipIP). We outline research tasks including literature review and observation of industry to coalesce information on the state of the art in process modeling, development of a prototype tool that embodies these characteristics, and chatrette and field testing of the tool to evaluate the extent to which the tool help s teams better communicate and integrate these design processes, and to visualize the results.
2 Observed Problems: Communication, Integration, an Visualization of Multidisciplinary Processes
2.1 OCommunicating Design Processes
For the design of the Stanfordn the Stanford Graduate School of Business campus projectGraduate School of Business campus, stakeholders used MACDADI (Haymaker and Chachere 2006) to communicate the importance of material responsibility when choosing structural systems. The Arup engineer created schematic Revit Structure models of steel and concrete structural options. Many tools (e.g. Athena, BEES, LCADesign) aim at assisting designers in making environmentally sustainable material decisions. Jen Tobias, A CIFE studentresearcher at CIFE had even , used an IFC Revit model and LCADesign software to assess the environmental impacts of another project on campus project in Germany (Tobias and Haymaker 2007). However, gGiven the time and budget constraints, the Arup engineer was not able to find Jen’s this model-based process nor create a new process that would allow the team to effectively use the BIM model to further inform the team’s structural system decision with environmental impact data. Project teams have difficulty communicating design processes across projects.
2.2 Exchanging Project Information (FF)
On the same project, a lighting engineer needed to perform a daylight analysis to decide which skylight configuration provided the best quality of light. The engineers’ process for constructing this day lighting model from the Revit model involved over 15 distinct steps and 30 hours to reformulate the model constructed by the architect to appropriately meet the requirements of his Radiance day lighting analysis routine. Significant improvements in this process were possible, but the designer and architect lacked the clarity of each other’s process to assure the right information was contained in the architects’ model to eliminate many of these steps. A recent survey (Flager & Haymaker, 2007) reinforces this observation, where respondents stated that they spend nearly two thirds of their time managing information during concept design. Project teams have difficulty integrating their processes among disciplines.
In both cases the designers produce performance feedback on a particular design option, but do not have effective tools/methods to manage a range of options (design space) or to quickly assess and visualize multidisciplinary system performance over that range. This made it challenging for them to know what aspects of their designs had the greatest impact on building performance, or to decide which designs provided the best value, and to understand which design variables they should focus on moving forward to further improve the design. Project teams have difficulty visualizing the results of their multidisciplinary design processes.Advancements in computer-based product modeling and analysis make it possible for AEC professionals to accurately simulate product performance in an increasing number of areas (architecture, structure, energy, lighting, cost, etc.). However, the potential of these tools to inform early stage design decisions has been limited by the time required to create and exchange information between tools. Arup survey results: majority of time spent managing information
Data Schema
Interoperability evokes the possibility of a single database of building information organized in a single data schema (IAI). Researchers continue to develop improved methods for developing standards for specific applications (Lee et al. 2007). These standards are powerful, but other strategies such as Application Programming Interface (API), customized commercial software links, and simple user-written mapping scripts will continue to be a vital part of AEC interoperability efforts. Many of these efforts lack an explicit representation of process, and methods to dynamically generate and share these processes.
2.3 Understanding Multidisciplinary Performance Trade-offs (FF)
Current practice, designers are given performance feedback on a particular design option, but do not have effective tools/methods to define a range of options (design space) or to quickly assess system performance over that range. Moreover, AEC professionals lack common metrics to compare performance across multiple disciplines or conduct and visualize trade studies between among systems.
3 Intuition: A Process Integration Platform
Current BIM tools provide an opportunity to improve the efficiency and effectiveness of the design process. To date, designers have not fully capitalized on this opportunity. In order to better communicate, integrate, and optimize visualize design processes, we propose practitioners require a web-based Process Integration Platform (PIP) (see Figure 2) with the following characteristics:
Transparent:
A transparent design process is quickly and accurately understood by those not involved in the design.
Usable:
Most engineers lack the extra time to write codes document and to improve their design process. Features, such as drag and drop, drop down menus, and a familiar graphical user interface allow new users to utilize PIP with no training.
Sharable:
For effective communication of processes, sharing must be embedded in the design process, so that engineers share their work by default. Still, engineers must be able to control access privileges, allowing processes to be accessed by the public, by the project team, or only to internal to the company.
Incentivized:
The first users of PIP must be incentivized to embed the tool in their design process. In addition, users must be incentivized to improve their processes. PIP must provide mechanism that encourages this use by tracking and rewarding user input.
Searchable:
The structural engineer uses multiple search fields to find the process for which he is looking. He can Designers need to filter the searches and browse through the results in numerous ways. They need algorithms arethat are intelligent and learn from their users. A structural engineer in San Francisco, for example, is more likely to be looking for a process created by a structural engineer in Los Angeles for finding the environmental impact of concrete than a plumbing engineer in Thailand looking at the environmental benefits of bamboo.
Modular:
The structural engineer demonstrated modular byDesigners should be able to use old processes as the basis of new processes – assembling multidisciplinary design processes by combining several parts of other processes into his own process. P-cip is modular in the sense that interoperability links can be copied and pasted into new processes. This modularity does not suggest a specific data schema or software standard, but rather recognizes that such standards will probably never exist.
Modularity can also be viewed as the ability to use old processes as the basis of new processes. The development of new design processes is a creative design process in itself. Thus, organizational scientists would view modularity as important, because, “creative solutions are built from the recombination of existing ideas” (Hargadon and Bechky 2006).
Scalable:
Designers need to use these processes at different levels of process and product detail. For example, they may want to The structural engineer selects Library from the drop down menu, because he only wants to perform an analysis on the library, not the entire graduate school of business campus. This filtering of the total project deliverable, the product, is product scalable. He could have analysedanalyze just a particular room in the library, the entire librarybuilding, or the entire GSB project, or even the entire Stanford campus. Similarly, they may want to model a Some processes would apply regardless of scale and others are very dependent on product scale“Structural Material Responsibility Analysis” node that lies within a process containing other analysis nodes such as “Structural Analysis” and “Lighting Analysis.” This level of detail falls beneath an even higher level node called simply “Analysis.”
Integratable.
The structural engineer creates a “Structural Material Responsibility Analysis” node that lies on a process containing other analysis nodes such as “Structural Analysis” and “Lighting Analysis.” This level of detail falls beneath an even higher level node called simply “Analysis.” This “Analysis” node is described by Haymaker and Chachere (2006) and forms part of the MACDADI framework along with nodes labelled Goals, Preferences, Options, and Decisions. Double clicking on the “Structural Material Responsibility Analysis” node brings up the more detailed process shown in Error! Reference source not found..
Designers choose how to scale their products and processes. For example, a structural engineer may perform one process on concrete beam section, a different process on the concrete beam, and an entirely different process on the entire building.
Computable: Designers need to be able to use these process models to drive the automation of their processes.
Support VisualizeDesign Space Exploration : Designers need to be able to view the results of several iterations through these process models, to help them understand the solutions spaces they have generated and analyzed to help them further refine their design processes, and to choose the best designs.
4 Points of Departure
The example in Section 2 1.1 demonstrates how the lack of interoperability solution development and sharing fundamentally limit BIM’s impact on AEC. Section 3 intuits several characteristics of a Process Integration Platform that can address these limitations. We propose these deficiencies stem largely from the absence of a process modeling tool with the characteristics we will list in Section 5.2. Before proposing such a tool, we review related work in defining and sharing design process information and assess the extent to which it helps address these characteristics..
Integrated Project Delivery is a design, procurement, and construction approach that integratesintegrate people, systems, business structures and practices (AIA, 2007). They specify design process milestones and people included in each process, but do not formalize the information flow and tools needed to ensure effective interoperable processes.
Lee et al. (2007) use Process Models to improve product data models – a formal and structured definition of product information such as IFC’s. Lee identified several drawbacks to the ISO STEP product modeling method, including: they are built as single generic models to represent idealized industry-wide processes preventing local variations; are thus high-level and lacking in detail; are defined more as archives of data instead of as support for strategic workflow processes; and do not well support the developmental and evolutionary aspects of product development. They argue that product models must have a closer linkage with workflow and that mapping between processes and the product model data should become an explicit part of the definition activity. Lee et al. seek to use process models to develop future product data models. That is, software developers, not designers, use the process models, and they are thereof not intended to be transparent, usable, and sharable by project teams..
Information Delivery Manuals (IDMs) are an integral component of the International Alliance for Interoperability’s (IAI) buildingSMART initiative and Industry Foundation Classes (IFC) development effort. The purpose of IDMs is to provide a human-readable integrated reference identifying “best practice” design processes and the data schemas and information flows necessary to execute effective model-based design analyses.