Process Integration Platform: Applied to Multi-Disciplinary Building Design
Reid R. Senescu (rsenescu@stanford.edu)
Center for Integrated Facility Engineering, Stanford University, Y2E2 Building, 473 Via Ortega, Room 292
Stanford, CA 94305-4020 USA
John Haymaker (haymaker@stanford.edu)
Center for Integrated Facility Engineering, Stanford University, Y2E2 Building, 473 Via Ortega, Room 292
Stanford, CA 94305-4020 USA
Abstract
Despite the influx of building information modeling and
advanced building simulations, design processes remain
similar to the pre-computer era. We propose that interactive
process models improve design process effectiveness and
efficiency through integrating and sharing of successful
design processes. We present examples of shortcomings in
practice, summarize a survey of practicing engineers, and
review points of departure. Based on this research we develop
a theoretical framework for a web-based collaborative and
interactive process modeling platform. We use a hypothetical
narrative to explain its use and establish a method for
evaluating the platform.
Keywords: design process; interoperability; knowledge
sharing; BIM
Introduction
To some, Building Information Modeling (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 the Architecture, Engineering and
Construction (AEC) industry. Yet, little commercial
development of BIM is process-centric, and none of the
major BIM tools provide explicit support for defining and
sharing processes. Despite the rhetoric that BIM is a
fundamental shift in the design process, the industry
generally still plugs in the new tools into a design process
that predates computers.
While the capabilities of simulation and modeling tools
expand, order of magnitude increases in design process
efficiency and effectiveness remain elusive. This paper uses
two examples from current practice to demonstrate how
current limitations in interoperability limit BIM’s promise
to drastically improve design process efficiency and
effectiveness.1 The paper then summarizes results from a
survey of engineers. The survey and a literature review lay
the foundation for the theoretical framework of the Process
Integration Platform (P.I.P.). The paper uses a Narrative
(Haymaker, 2006) to describe the characteristics of P.I.P.
While the potential impact of P.I.P. on current design
1
This paper uses the International Alliance for Interoperability
definition of interoperability: “the exchange of information among
project participants throughout the lifecycle of a facility by direct
communication between software application” (Barrett and
Grobler 2000).
practices is broad, the paper focuses on how the proposed
platform catalyses continuous improvements to the design
process through incentivizing the development and sharing
of improved design processes. The paper closes with a
method to evaluate the platform’s success.
BIM Opportunities Lost
Designing Louvers for Optimal Day Lighting
With the goal of informing the design team’s decision
regarding the quantity and size of louvers on the south
façade of the new Stanford Graduate School of Business
Library, engineers at Arup’s San Francisco office created
video simulations of sunlight moving across a space.
Looking to improve the realism of the output, the lighting
engineers used the architect’s Revit model as the basis for
their geometry. The engineers were confident in the science
behind their analysis tool, Radiance, and did not have the
time to learn and validate other programs. Through trial and
error, they discovered they could use Revit Architecture,
AutoCAD, 3D Studio Max and Radiance to create an
improved day lighting simulation. The process required
much manual manipulation of geometry and materials to
reformat the information so that each new software package
could interpret the data representing the building. Though
not explicitly defined prior to an interview with the first
author, the process is shown in Table 1.
The engineers run these processes several times per
month. The process described in Table 1 takes about 24
man-hours to provide feedback to the architects. About 16
man-hours are spent on non-value added tasks, such as
cleaning up geometry or reassigning materials in AutoCAD
layers that were already differentiated in Revit. The
engineers felt that elimination of the 16 hours of non-value
added time would either increase the number of options that
the architect could consider or increase the company’s
profit. The engineers believed that with improved
efficiency, the design space could be further explored, and a
better solution discovered. At some point, the return from
expanding the options considered would diminish, and
engineers would just spend less time producing the same
quality design, improving company profit. Despite the
obvious benefit of an improved process with improved
interoperability between Revit and Radiance, no solution
was being developed to meet the needs of the engineers.
Table 1: The steps taken to produce day lighting videos.
The steps in the process and time for each step were not
documented until the authors intervened
Time
(hrs)
Task
Software
1. Create Revit Model
Revit Architecture N/A
2. Import 3d .dwg with 3d shapes AutoCAD 2007
0.3
3. Clean up geometry
AutoCAD 2007
4-6
4. Set layers to match materials
AutoCAD 2007
1.5
5. Import 3d .dwg with 2d surfaces
and layers
AutoCAD 2005
0.2
6. Identify holes
Radiance
2-3
7. Import 3d .dwg
3D Studio Max
1-2
8. Remesh geometry
3D Studio Max
0.2
9. Import 3DS Rendering
AutoCAD 2005
0.5
10. Import 3d .dwg
Radiance
1-2
11. Set sunlight properties, material
reflectivity, etc.
Radiance
4
12. Create video
QuickTime
8
13. Discuss with architect
Discussion
2-3
The first author attempted to find an improved solution.
Asking for an improved process on Arup’s forum revealed
suggestions for similar processes, but no solutions that
matched the project’s given input and desired output. An
internet search of blogs and forums reveal that other
companies had similar problems trying to go from Revit to
Radiance (Toast, 2004; McGrew), but no one had posted an
improved solution. An interview with Revit’s developers
revealed they are interested in improving links between their
object oriented 3d building software and analysis programs,
but development toward improving the direct link between
Revit and Radiance was not planned. One potential
alternative is to go from Revit to IES to Radiance, but the
lighting engineers were once disappointed with this option
and did not have the time to try it again. The lighting
engineers were simply too busy to invest time in improving
their process. Their supervisors, software developers, and
their clients had no methods for understanding how an
improved process could increase profits or design quality.
The first author intervened by approaching some
principals in the firm to explain the inefficiency of the
current process, and they committed funds to improving the
process. With about 16 hours of research, the first author cut
step 3 and 4 to a few minutes, eliminating six hours of
tedious, non-value adding time from the process. With an
investment of roughly $2400, we estimate $32,400 of added
value annually, assuming 6 hours x 3 iterations/month x 12
months x $150/hour. Three other documented case studies at
the firm suggest that this opportunity for improving process
efficiency is prolific across disciplines.
In summary, the current tools provide an opportunity to
improve the efficiency and effectiveness of the lighting
design process. Yet, designers do not capitalize on this
opportunity. The individual engineers are not incentivized to
invest their time in improving the process. Their tools do
not track their process (and the resulting inefficiency), place
them in a small peer community to improve the process
together, nor provide transparent access to other processes
that could form the basis for improvements. Also, managers
lack a transparent method for understanding the inefficiency
and therefore, lack a monetary justification for encouraging
development of alternatives.
Designing with Sustainable Materials
For the design of the Stanford Graduate School of Business
campus, stakeholders explicitly communicated the
importance of material responsibility when choosing
structural systems. The first author, while working as an
engineer for Arup, created schematic Revit Structure models
of steel and concrete options for one building on the project.
The model was used to support a visual understanding of the
two systems, as well as some structural and cost analysis.
Arup San Francisco had recently purchased Athena,
software that uses a database to output the environmental
impact of building materials. Despite a 3d object oriented
model (containing a database of structural materials and
quantities), a database of the environmental impacts of those
materials, and a clear desire by the stakeholders for the
designers to consider material responsibility in their design
recommendations, the author did not conduct a formal
environmental impact analysis comparing the concrete and
steel options. Given the time and budget constraints, the
first author was not able to find or create a process that
would allow the team to effectively use the information
available to further inform the team’s structural system
decision with information on material responsibility.
As was the case with the lighting design, there is a clear
demand for an improved process. Unlike the lighting
example where an improved process was non-existent, the
first author recently discovered similar processes being
employed internal to Arup and externally at the time of the
structural design (Tobias & Haymaker, 2007). However,
there was no simple mechanism to quickly search for
existing processes and build on them to develop new
processes. These cases illustrate that designers need a
platform that enables them to more easily collaboratively
improve and share interoperable design processes.
Survey Affirms Generality of Case Studies
The authors conducted a survey of 74 engineers from a
global engineering firm that belonged to a group interested
in virtual design.
Half of respondents felt they should increase the amount
of virtual design information that they disseminate to others.
The top three barriers to sharing information were “Lack of
Time”, “Not knowing where information was kept”, and
“Lack of communication.” We then asked respondents to
describe desirable characteristics of an intranet site for
sharing information about virtual design. We coded the
responses with 43 adjectives each with its own definition.
The top five responses were:
1. User-Friendly: No time to understand, easy to
navigate, easy to find, intuitive, good GUI
2. Crowd-Sourcing: No time to understand, easy to
navigate, easy to find, intuitive, good GUI
3. Information Referencing: Reference other sites,
linking to other already existing things.
4. Broad: Appeal to everyone at all positions, expertise,
or all disciplines, comprehensive
5. Searchable: Ability to enter in text and find the right
information
82% of respondents thought that “absolutely” the site
should be “A repository of project information relevant to
virtual design (software used, processes, people involved,
etc.).”
The survey reveals that designers want better ways of
sharing information and to capture process knowledge
learned from other projects, but that knowledge sharing
methods must not take up user time. Broad, CrowdSourcing, and Information Referencing suggest that
engineers do not want a system dependent on rigorous
management, nor do they want details. Rather, they want a
tool that allows everyone to participate in the exchange of
information mostly by referencing information that already
exists, but is not necessarily widely available.
Process Integration Platform Characteristics
The case studies demonstrate how a lack of interoperability
process development and sharing impact the efficiency and
effectiveness of the design process. Motivated by the cases
and the survey, we intuit several characteristics for a webbased collaborative and interactive Process Integration
Platform.
A transparent design process is quickly and accurately
understood by those not involved in the design. In the first
case, the lighting engineers’ process is hidden from software
companies, managers, architects, and other lighting
engineers. No individual fully understands the opportunities
for improving the process and so, no one works together to
improve the process. For the structural engineer, even if a
search revealed that others in the company wanted to use a
building model for environmental impact analysis, no
formal documentation of that process exists, and so, it
would be very time consuming for the engineer to find the
appropriate interoperability solution for his needs.
Most engineers do not have the time to extensively
document their design processes. They rarely have time to
learn how to use new tools. The user-interface for process
modeling and searching must be user-friendly.
For interoperability solutions to be successful, they must
be sharable. Sharing must be embedded in the design
process. Users must be able to restrict sharing to within their
company or to particular users.
Designers must be incentivized to use process modeling
and to develop interoperability solutions. These incentives
may be embedded in the tool, and/or in the company
organization. To be successful, the first user of P.I.P. must
find value in its use even when no other processes or
interoperability links exist. Once in use, P.I.P. also
incentivizes the development of interoperability solutions.
P.I.P. must be searchable by processes under multiple
criteria, and the searching algorithms must be intelligent
enough to understand multi-discipline and multi-cultural
users and their context.
The solution must allow users to combine modular parts
of other processes into a new process. It should also allow
geographically separated engineers to work on different
parts of an interoperability solution and then combine their
work.
Designers must be able to 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. The process
modeling must permit interoperability solutions developed
that are scalable.
The platform must be computable, so designers can
automate processes and drive processes from P.I.P.
Points of Departure
The case studies above demonstrate how the lack of
interoperability solution development and sharing
fundamentally limit BIM’s impact on AEC. We propose
these deficiencies stem largely from the absence of a
process modeling tool with all of the characteristics listed
above. Before explaining such a tool, we first review related
work in defining and sharing design information.
Lee et al. (2007) use Process Models to improve product
data models. 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.
Information Delivery Manuals (IDMs) provide a humanreadable integrated reference identifying “best practice”
design processes and the data schemas and information
flows necessary to execute effective model-based design
analyses (IAI).
However, current process modeling
approaches are formulated at an abstract level to define
general data exchanges, processes, and design team
requirements, and have limited value as a project-specific
design guidance and management tool. That is, software
developers, not designers, use these process models, and
they are therefore not intended to be transparent, usable, and
sharable tools used by project teams.
Design Rationale research develops methods for better
understanding the design process and ideas for improving its
current state by representing the reasons behind the creation
of a particular artifact (Moran & Carroll, 1996). Conklin
and Yakemovic use Issue-Based Information Systems
(IBIS) and process tracking to better understand and track
reasons behind design decisions (1991). Professionals rarely
implement Design Rationale systems, because they are not
incentivized & computable - designers thus struggle to
perform the extra step to document their rationale
concurrently to performing design.
Several CIFE methods have advanced the design of
process models for use by AEC professionals. Geometric
Narrator (Haymaker, 2006), enables a designer to build a
scalable, computable process from automated sub processes,
but lacks an intuitive visual interface and mechanisms to
easily collaborate. Narratives are formal, visual
descriptions of the design process (Haymaker 2006).
MACDADI (Haymaker & Chachere, 2006) further
communicates the people, tools, goals, preferences, options,
analyses, and decisions associated in design, and contains
some mechanisms for collaborative modeling, however,
MACDADI and Narratives are not well integrated into
software, limiting their computable power.
Knowledge Sharing research explains a “project memory
system” to explicitly define informal knowledge and make it
available to others. However, Conklin (1996) generally
applies this system to capturing knowledge from meetings,
whereas we focus on capturing design process information.
Software, media, internet companies, and academia open up
their domains and turn to the crowd to tackle huge
challenges in their industries. These Crowd-Sourcing
Open
Source
movements
transcend
traditional
organizational science explanation for why people innovate.
Hippel and Krogh (2003) proposes that to contribute,
participants must learn from the experience, should profit
from networking effects of sharing or at least, not lose any
money by sharing, and must receive “selective incentives,”
such as a sense of ownership or enjoyment of the process.
A Narrative for a Solution
We have given two examples of current challenges faced by
engineers and validated the generality of these examples
with a survey. We proposed eight characteristics for a
successful P.I.P. and explained previous attempts at
improving design processes. Now, we use a narrative to
further describe the eight characteristics of the P.I.P.:
Transparent, Usable, Sharable, Incentivized, Searchable,
Modular, Scalable, and Computable.
It is early Scheme Design for a new library on the
Stanford Graduate School of Business. Through the use of
MACDADI, the stakeholders have communicated their
relative preference for, among other goals, good lighting
and reduced energy consumption. The design team is
considering two geometric options for the library atrium.
A meeting between the architect and the engineering
team produced some sketches for an atrium option that
extends in part to the basement and one that stops at the
ground floor. The architect creates a Revit Architecture
model and has just saved the model as a node in the webbased process model shown in Figure 1 (a). The engineers
begin using that model as the basis for their individual
analysis. The lighting engineer wants to create a video of
Figure 1: (a) Lighting consultant adds Day Light node to analysis process to the library project. (b) Designer searches for
appropriate Day Light analysis processes.
Figure 2. (a) Designer browses search results; (b) looks at process info; finds two appropriate processes. (c) Working
with the user community, (d) he automates one process.
the daylight moving across the space, so the architect can
see the different aesthetics of the two atrium options. He
also wants to calculate the total energy required to light the
basement for the two options, so that the mechanical
engineer can use this information for an energy analysis.
The lighting engineer opens P.I.P. in his internet
browser. He searches for “Input: Revit Architecture,”
“Output: Lighting Energy Use”. The search results display
various projects that meet these criteria. He sees in the
Process Info window (Figure 2 (b) ) that the process for the
E Cubed Laboratory project has just been used twice, but
that various links in the process have been copied into other
projects 31 times. On average the process takes 22 hours to
complete. Thinking that the process could easily be more
efficient, the lighting engineer asks the community of users
(Figure 2 (c) ) whether they want to pool resources and
invest in automating the process (indicated by the green
arrows). The lighting engineer selects the process from a
previous project (Figure 2) and copies just the process (not
the information) into the Stanford GSB project (not shown).
The lighting engineer finds another process used on a
different project to produce day lighting movies, but does
not attempt to automate it. He selects the applicable
modules of the process and again copies it into the Stanford
GSB project (Figure 2).
He then connects the new processes to the existing
Revit Architecture model. The P.I.P. automatically runs
software on the desktop computer to produce lighting
energy output, which is used by the mechanical engineer for
energy analysis simulations. The video making process is
not automated and so, the engineer goes through each step
in the process using the appropriate software. While not
automated, the information created is saved to the process
map, so it is easily accessible (if security privileges are
granted) and understood by the entire project team.
Results (not shown) are directly linked to the processes
that produced them, so users can quickly compare options
and understand the processes producing the results.
Method for Evaluating P.I.P.
This section explains our method for evaluating whether
designers use more efficient and effective processes with
P.I.P. In Phase 1, we observe current design processes. In
Phase 2, we introduce P.I.P. to the same group of students
or designers and again observe design processes.
Based on observations of several student and
professional design processes we categorized design
processes into the following tasks:
1. Find the process to follow
2.
3.
4.
5.
6.
Attain the tools or references required
Strategize the modeling approach
Translate information from other sources
Simplify or filter translated information
Generate new information (geometric, material, loads,
etc.).
7. Verify that the results are reasonable or correct.
8. Troubleshoot the model.
9. Fix errors in the model.
10. Track process or results with no intent of
communicating information to others.
11. Report or document results with the intent of
communicating information to others.
12. Decide on a design option
We ask designers to track their design processes and
categorize their tasks according to this list. We then
determine the percentage of time spent on non-value added
tasks (e.g. Finding, Attaining, and Translating), which
permits the measurement of process efficiency, defined as:
Efficiency = Non-Value Added Time / Total Process Time.
From this equation, we compare the relative efficiency of
various processes currently in practice.
The effectiveness of the process is more difficult to
measure. We take three approaches.
1. Design Options Considered: We presume wider
exploration of the design space increases the
likelihood of finding a better design solution.
2. Designer Review: We interview designers about the
quality of the results produced by the processes they
follow.
3. MACDADI: Effective processes result in designs that
better meet the goals of the designers. We will use
MACDADI to score the quality of the designs.
By combining these three measurements, we can determine
the relative effectiveness of processes with similar input and
output, but different information flows.
Conclusion
We explained case studies where engineers are not
drastically improving the efficiency and effectiveness of
their design process despite the availability of a 3d objectoriented model. The lighting engineer did not develop an
improved interoperability solution and the structural
engineer did not find an interoperability solution. To
increase the development and sharing of interoperability
solutions, we explain a Process Integration Platform (P.I.P.).
Because P.I.P. is Transparent, Usable, Sharable,
Incentivized, Searchable, Modular, Scalable, and
Computable, AEC can better develop and share design
process solutions.
References
Autodesk, Revit Building Information Modeling:
Transitioning
to
BIM.
Available
Online:
http://images.autodesk.com/adsk/files/transitioning-tobim_jan07_1_.pdf.
Barrett, D., & Grobler, F. (2000). Understanding the
different purposes of ifcs and aecxml in achieving
interoperability. Available Online: http://www.iaina.org/technical/faqs.php
Conklin, E. J., & Yakemovic, K. C. B. (1991). A processoriented approach to design rationale. HumanComputer Interaction, 6, 357-391.
Conklin, E. J. (1996). Designing organizational memory:
preserving intellectual assets in a knowledge economy.
CogNexus
Institute,
Available
Online:
http://cognexus.org/dom.pdf
Eastman, C. (2007). Building information modeling, What is
BIM? Georgia Tech, AEC Integration Laboratory.
Available
Online:
http://bim.arch.gatech.edu/content_view.asp?id=402
Government Services Agency (2007). GSA BIM guide
overview. Available Online: http://www.gsa.gov
Haymaker, J. (2006). Communicating, integrating and
improving multidisciplinary design narratives. Second
International Conference on Design Computing and
Cognition (pp. 635-653). Technical University of
Eindhoven, The Netherlands.
Haymaker, J., & Chachere, J. (2006). MACDADI: A
methodology for systematically & transparently achieving
breakthrough quality (Tech. Rep. 10-1-2006). Stanford,
CA. Stanford University, Center for Integrated Facility
Engineering.
Hippel, E., & Krogh, G. (2003). Open source software and
the “private-collective” innovation model: issues for
organization science. Organization Science, 14(2), 209223.
International Alliance for Interoperability. Available Online:
http://www.iai-international.org/
Lee, G., Eastman, C. M., & Sacks, R. (2007). Eliciting
information for product modeling using process
modeling. Data & Knowledge Engineering, 62(2), 292307.
McGrew, J. Revit to Radiance (via an expensive
translator...), because we can. Available Online:
http://www.becausewecan.org/node/190
Moran, T. P., & Carroll, J. M. (1996). Design Rationale:
Concepts, Techniques, and Use. Lawrence Erlbaum
Associates
Toast (2004). Questions about dxf import code for a Revitto-Blender
tool.
Available
Online:
http://blenderartists.org/forum/showthread.php?t=30227
Tobias, J., & Haymaker, J. (2007). Model-based LCA on
Stanford's green dorm. International Life Cycle
Assessment Conference. Portland, Oregon.