1

PhD Research Proposal: Goal driven parametric modeling for improved conceptual high-rise design Victor Gane Center for Integrated Facility Engineering, Construction Engineering and Management, Civil and Environmental Engineering, Stanford University vgane@stanford.edu

Abstract World population is expected to become preponderantly urban and grow by 1/3 in the next few decades. High-rises will become an increasingly important building type that can help address population growth and the resulting sprawl. However, most high-rises have a poor life-cycle performance. The cause lies in the current conceptual design methods used by the Architecture, Engineering, and Construction (AEC) industry. Few design options are generally developed without a deep understanding of their multi-attribute performance. Requirements engineering can help define and manage building design criteria for guiding the process of generating design options. Parametric modeling can help efficiently generate geometric options. However, the AEC industry still lacks a method to translate defined requirements into flexible parametric models for use in high-rise conceptual design. This thesis seeks to establish such a method, and validate it experimentally in industry case studies. 1. Introduction the need for effective conceptual high-rise design processes The twentieth century experienced an unprecedented demographic shift. The world population more than doubled in the last 40 years. A United Nations report [1] predicts that by 2050 the world population is expected to exceed 9 billion. Furthermore, by 2010 worlds urban population will surpass rural. In many parts of the world urban sprawl is the solution to the constantly increasing population due to the traditionally preferred low-density developments. There is a growing consensus among the scientific community [2, 3] that urban sprawl has significant negative social, economic and environmental implications. 4 billion additional people will need housing and work places in just a few decades. A way to address the population growth concerns is to adapt cities to support much higher densities. As populations grow and urbanize, high-rises will become an increasingly important building type. A simple calculation shows that housing 4 billion people in typical 40 storey high buildings with 350 units and a total of 1050 people will require constructing close to 4 million new high-rises. For the past century high-rises have successfully responded to population growth issues in parts of the United States and Asia, where accelerated urbanization was under way. Yet, the majority of worlds high-rises perform poorly in terms of their life cycle cost. According to Yeang [4] in a 50-year life-cycle of a high-rise, energy costs contribute 34% of the total cost. Close to 50% of energy use in high-rises comes from artificial illumination [5]. Kaplan [6] indicates that a typical high-rise building is generally comprised of poor quality materials and mundane esthetic design.Successful high-rise designs need to use a minimum of nonrenewable energy, produce limited pollution, and minimize their carbon footprint without diminishing the comfort, health, and safety of the people who inhabit them. The requirements and technology used in designing and operating tall buildings will only increase in complexity. A principle cause of this underperformance lies in the design methods employed in the AEC industry today. The market economy requires us to design quickly and cheaply; however, as Sutton [7] points out, research on creative output shows that we can't tell which new ideas will succeed and which will fail at the outset, and that successful design is largely a function of sheer quantity. Gane & Haymaker [8] show that with current methods design teams are only able to explore a few potential designs without a deep understanding of their multi-attribute performance. To achieve the goal of significantly improved high-rise buildings, the AEC industry needs to revise the traditional design and analysis methods.

2

Understanding and efficiently managing requirements early in the design process is a major challenge in high-rise conceptual design processes today. So is translating these requirements into a wide range of design options that designers can quickly analyze and choose from. Several points of departure partially address these issues. Requirements engineering can help design teams define and manage their building design criteria in terms of formally structured goals and constraints. Process modeling can help represent and measure goal-driven processes. Parametric modeling can help efficiently generate geometric options [9]. Even with these methods, the AEC industry still lacks a method to efficiently translate defined constraints and prioritized goals into geometrically flexible parametric models for use in high-rise concept design. This thesis seeks to establish such a method, and to test its impact on conceptual high-rise design processes. My research method consists of three phases. First, involves embedded observations on current practice to develop detailed process models and establish metrics quantifying current practice in terms of: 1) design team size and composition; 2) goal clarity; 3) No. of generated design options; 4) performed model-based analysis; 5) time investment per discipline; 6) conceptual design duration. Second, involves developing a framework for translating high-rise design criteria and explicit goals into parametric CAD models. The framework will be tested against the following metrics: 1) completeness of goal decomposition; 2) CAD models geometric flexibility; 3) CAD models failure probability. Third, involves validating the framework on industry case studies. Metrics results from Phase 1 will be compared with: a) metrics results of a process using parametric modeling with the proposed framework; b) metrics results of a process using parametric modeling without the proposed framework. 2. Points of departure: Design Theory, Process Modeling, Requirements Engineering, Parametric Modeling, and High-rise Design Methods In this section I describe the fundamental points of departure for my research. I look to Design Theory for a fundamental definition of high-rise design processes; to Process Modeling for a method to describe and measure these processes; to Requirements Engineering for methods to efficiently define and manage goals and constraints; to Parametric Modeling for methods to generate geometric options; and High-Rise Design Methods for the specific requirements pertaining to high-rises.

2.1 Design theory Akn [10] formulates conceptual design in terms of a process consisting of five steps: 1) identifying a set of requirements; 2) prioritizing among these requirements; 3) developing preliminary solutions; 4) evaluating solutions; 5) establishing final design requirements, preferences and evaluation criteria. Haymaker and Chachere [11] further formalize the design process in the MACDADI framework. The thesis builds on this framework to describe and analyze conceptual design in terms of: 1) Organizations the project managers, stakeholders, designers; 2) Goals the organizations constraints and preferences; 3) Options the design options considered, including how these were generated; 4) Analyses the analyses performed, including how these were generated; 5) Decisions the choices made, including the criteria used. In order to develop feasible options, designers normally first establish a design space. Krishnamurti [12] defines a design space as the sum of the problem space, solution space, and design process. A problem space includes only the candidate solutions that satisfy the established design requirements.A solution space includes all candidate solutions for a given design problem. A design process consists of methods used to develop candidate solutions from requirements. The extent of the design space is highly dependent on the designers interpretation of the design problem, the choice of design criteria (project goals and constraints), and the employed design process. Building design is a social, multidisciplinary collaborative process, which requires careful coordination of design criteria to achieve feasible solutions

3

[13]. Coordinating complex design criteria is a challenging process that makes effective search through the whole design space difficult. As a result, two prevailing strategies emerge to describe the design process: breadth first, depth next or depth first, little breadth. Simon [14] in his behavioral theory of bounded rationality describes people as only partially rational when making decisions because of computational limitations in gathering and processing information. Woodbury and Burrow [15] also argue that designers typically consider a very small number of alternatives in their work as a result of cognitive limits. Therefore, designers are forced to make decisions that are not optimal but only satisfactory according to a pre-set aspiration level. Goldschmidt [16] argues in favor of the depth versus breadth strategy, in which both known architects and novice students deliberately choose a limited design space to conduct their exploration. The goal is refining and enriching a strong idea supported by well developed design rationale. In contrast, Akn [10] argues that in solving problems expert designers prefer the breadth first, depth next strategy. As a result, multiple alternatives help reveal new directions for further exploration that the designer wouldnt have thought of otherwise. Each strategy has significant implications on the way design teams communicate and manage their processes. Currently there is no consensus on which strategy performs best and the debate in the academia indicates the importance of a more in-depth analysis into the subject. In the context of this thesis, conceptual design is the process of narrowing a design space to a solution space by applying the breadth first strategy.

2.2 Process modeling Design theory helps us understand the general process of design, however it does not help us understand how specifically to represent and measure high-rise design processes. Such understanding can help quantify and compare the performance of existing and proposed processes, as well as provide the tools that help organizations to adopt the proposed processes. A widely accepted implementation method is process modeling. Generally, there are three applications for process models: a) descriptive for describing what happens during a process; b) prescriptive for describing a desired process; c) explanatory for describing the rationale of a process [17]. Froese [18] presents a comprehensive overview of AEC specific process models. He distinguishes between core process models and application models. Core models are high-level models that provide a foundation for more detailed application models constructed on top of them. Core models (IRMA Information Reference Model for AEC, BPM - Building Project Model, ICON Information / Integration for Construction, GRM Generic Reference Model, etc) are used for exchanging information between different application areas and unlike application models are not intended to represent actual data. Most of the models surveyed by Froese are based on EXPRESS-G modeling language [19]. Among other significant process models are IDEF0 [20] used to model decisions, actions, and activities of an organization or system, the Narratives [21] that provide a means to model information and the sources, nature, and status of the dependencies between information, and Value Stream Mapping [22] used to illustrate and analyze the flow of actors, activities, and information that produce value in a given process in order to assist in process re-engineering. Despite the wealth of existing process modeling methods, an important need specific to this thesis is not met a representation formalism for capturing and communicating the structure of parametric models and their multiple levels of information dependencies.

2.3 Requirements engineering

The field of Requirements Engineering (RE) is a fundamental point of departure. It can help formalize the process of developing requirements for building parametric models responsive to a chosen design space. Originating in systems and software engineering, RE is used as a means to overcome the drawback of

4

traditional software development methods, in which the developed systems are often technically good but unable to respond to the needs of users in an appropriate manner [23]. Several case studies show that poor definition or misunderstandings of requirements are major causes of system failure [23]. In my personal experience of building AEC concept design parametric models I observed similar drawbacks. The more limiting the set of explicit requirements used in establishing a design space, the greater the failure probability of a parametric model to produce design alternatives outside the range of the original design space. For example, a parametric model developed only to generate variations of a rectangular building will not support generating a circular building without pre-rationalizing such a requirement. According to Ross and Schoman [24] RE must say why a system is needed, based on current and foreseen conditions, what features the system will satisfy, and how the system is to be constructed. Lamsweerde [25] expands the RE definition as concerned with the identification of goals to be achieved by the envisioned system, the operationalisation of such goals into services and constraints, and the assignment of responsibilities of resulting requirements to agents as humans, devices, and software. Comprehensive goal definition is at the core of RE. According to Lamsweerde [26] a goal corresponds to an objective the system should achieve. Goals refer to intended properties of envisioned system or of its environment. They are expressions of intent and thus declarative with a prescriptive nature, as opposed to descriptive statements [27] which describe real facts. RE establishes goal taxonomies [23] as well as the roles that goals play in establishing requirements. Rolland [23] identifies several such roles: - Eliciting requirements: the task of communicating with project stakeholders to determine what their

requirements are. Goal identification is not a trivial task. In AEC industry sometimes they are explicitly stated by stakeholders but most often they are implicit. Therefore, the established goal taxonomy will help in eliciting goals according to their types.

- Analyzing requirements: goals provide a criterion to determine the requirements completeness. The requirements specification is complete if the requirements are sufficient to achieve the goal they refine.

- Requirements negotiation: goal ranking techniques to help choose among the stakeholders prevalent requirements. Goals have also been recognized to help in the detection of conflicts and their resolution [28]. Reasoning with goals can also help resolve conflicts among stakeholders [23]. For example, it is important to capture the fact that one goal can prevent another from being satisfied.

In his magic RE triangle Lamsweerde [29] introduces the concepts of agent and scenario which are complementary to goals. Goals are declarative whereas scenarios are procedural. Intentions are made explicit by goals whereas they are implicit in scenarios. Scenarios contain information on how goals can be achieved. Therefore, there is a unidirectional relationship between goals and scenarios, in which a new scenario can be developed each time a new goal is proposed. To develop better scenarios designers need to understand how goals relate to each other as well as to other elements in the requirements model. Such understanding will support the goal refinement process. In Artificial Intelligence [26] AND/OR graphs are used to capture goal refinement links. AND-refinement links relate a goal to a set of subgoals. Satisfying all subgoals is required for satisfying the parent goal. With OR-refinement links satisfying one of the subgoals is sufficient for satisfying the parent goal. In other words, an OR node represents a choice between possible decompositions. An AND node represents a required decomposition. In this framework, a conflict link between two goals is introduced when the satisfaction of one of them may prevent the other from being satisfied. In the AEC industry MACDADI [11] and PREMISS [30] are examples of methodologies for eliciting, analyzing and choosing requirements.

5

2.4 Parametric modeling

Parametric computer-aided design (CAD) is a design methodology used to create and manage geometric dependencies within a model. Also called constraint based, associative modeling, parametric modeling can enable designers to shift from creators of single designs to designers of systems of inputs and outputs that generate design spaces. A parametric representation of a design is one where selected values within the design model are variable, usually in terms of a dimensional variation. But any other attribute like color, scale, orientation could be varied parametrically, through a parameter. To design parametrically means to design a parametric system that sets up a design space which can be explored through the variations of the parameters [31]. Parametrics can provide for a powerful conception of architectural form by describing a range of possibilities, replacing in the process stable with variable, singularity with multiplicity. Using parametrics, designers could create an infinite number of similar objects, geometric manifestations of a previously articulated schema of variable dimensional, relational or operative dependencies. When those variables are assigned specific values, particular instances are created from a potentially infinite range of possibilities [9]. Parametric modelers are enabled by several important concepts not present in traditional CAD tools. Variables are the primary drivers of geometric variations. An independent variable is a user defined numeric input whose value can actively be controlled and changed (i.e. triangle height) while the dependent variable is the output whose value changes as a result (i.e. triangle area). Variables can also be global or local depending on how these have been attributed to geometric elements. For example, by attributing a variable to the radii of all columns in a building one would establish a global variable, since modifying its value will propagate globally to all the columns. In contrast, a local variable will always affect only a single geometric element to which it is attributed. Constraints are inputs used to establish relations that limit the geometrys behavior. Numeric constraints are used to define geometric elements (i.e. angle, length) and are equivalent to the above defined variables, in which an attributed numeric value acts as a constraint until it is modified. Geometric constraints are used to establish relationships between geometric elements (i.e. parallelism, tangency). A careful consideration of the choice of constraints is required in order to avoid generating an under-constrained (i.e. missing constraints) or over-constrained (i.e. conflicting parameters) parametric model. The use of constraints allows creating dynamic models versus the static models in traditional CAD. The extent to which parametric tools have been used to support conceptual AEC design has been limited. Constructing parametric models requires a thorough pre-rationalization of its transformations. This, in turn, requires a comprehensive list of project goals to be explicitly defined in order to establish a clear design space, something that the AEC industry currently lacks.

2.5 High-rise design methods The importance of this point of departure is to categorize the types of high-rises and elicit a list of design criteria and performance metrics that each category entails. Understanding and translating these requirements into quantifiable goals is important in the process of building parametric models. A detailed overview of high-rise classification and key design criteria is given by Gane & Haymaker [8]. Designing high-rise buildings is a complex process. Many disciplines participate in harmonizing the design criteria into a successful design. However, concurrent coordination of all these requirements is a daunting task with the current design paradigm discussed in chapter 4. As a result, many prototypes have been developed both in the academia and practice to address aspects of the design processes as heuristic rules with the ultimate goal of automating these processes. Danaher [32] argues that by not being well

6

defined the conceptual design is reserved only to senior, experienced designers. He proposes the use of knowledge based expert systems in facilitating the access of junior designers to expert knowledge, in which the system guides them towards good solutions. Several such systems surveyed by Danaher are Hi-Rise [33], Tallex [34], Conceptual [35], Predes [36], and Archie-II [37]. Ongoing research efforts address various aspects of conceptual high-rise design in practice. Baker [38], for example, explores the use of custom computational tools based on evolutionary structural optimization, genetic algorithms, etc. in generating topological structural studies of high-rises. Whitehead [39] develops custom parametric tools to facilitate the design space exploration. All these prototypes manage only a limited, discipline specific set of requirements in high-rise design and do not address a comprehensive list of goals needed to design a successful high-rise building. Furthermore, they do not give a proper guidance in the transformation of metrics into parametric models. 3. Research Questions

What is a method of generating conceptual parametric models of high-rises from explicit constraints

and ranked goals? How can this method be represented, managed and communicated? 4. Research Methods

4.1 Phase 1 - Documenting Current Conceptual Design Process

In Gane & Haymaker [8] I describe detailed observations of current practice using four case studies. I then validated the field observations and metrics describing the conceptual design process of high-rises through a survey of 20 senior architects, structural and mechanical engineers from several leading AEC practices [8, 40]. I described the case study concept design process in a process model. My process modeling language builds on modeling notation of IDEF0 and Narratives. A typical process node shown in Fig. 1 captures the actor(s) that performs the action (project manager, architect, structural engineer, etc), the tool or method used to generate information or make a decision (CAD, team meeting, etc), indication whether the action was automated or manually performed (shown pictorially), the abbreviated description of the performed action, the time range to perform the action, and finally the input information needed to perform the action and the resulting output information. If several actors are involved in implementing parts of the same process, the time tab indicates a cumulative value. The arrows to the input or from the output nodes indicate information dependency.

Fig. 1 models used to describe processes in this thesis use the above node notation

I use this notation to describe conceptual design in terms of a process model shown in Fig. 2. My background as designer for several projects in a leading architectural / engineering practice enabled my detailed understanding of how current projects are managed and designed.

7

Fig. 2 Process model describing the conceptual design used in the Tyrol tower case study. Nodes A & B

describe the early stages, in which decisions about team size, composition, duration, and deliverables were made by the design firm owner, project manager and senior designer. Nodes C, D, & E describe the process in which the design team evaluated the project context and requirements and proposed the first

design concepts in a design charrette. Nodes F, G, H, & I describe the process in which the design team developed 2D working drawings to calculate whether area and building efficiency requirements were met and a 3D model for visual evaluation of the design. Designers repeated the process several times before

these requirements were met. Nodes J, K, L & M show that only after the senior designer accepted a design option for final development were the mechanical engineers involved, the geometry prepared for physical model prototyping, and the conceptual design package assembled. Mechanical engineers post-

rationalized the design rather than participate from the beginning in decision making. Note: for large resolution image see attached JPG named Fig. 2

A selection of metrics describing current conceptual design process is illustrated in Fig. 3. The results include both value adding and non value adding tasks.

Fig. 3 Selection of metrics describing current conceptual design. A multidisciplinary team averaging 12

people can normally produce only 3 design options during a design process that lasts on average 5 weeks. Most of this time is spent by architects on generating and presenting a small number of design

8

options. Little time is dedicated to establishing / understanding project goals and running multidisciplinary analysis. These analyses are inconsistent and primarily governed by architectural

criteria.

The field observations and the survey [8] helped elicit the following conclusions: Goals The current goal definition model leads to significant inefficiencies in the overall conceptual design process. Goals are often ambiguous and defined without the participation of all AEC disciplines. Both the client (stakeholders) and architects may lack specialized knowledge to solely allow them to establish project goals. Furthermore, architects often clarify project goals during the design process. This may lead to non-systematic shifts within the design space due to important guidelines being omitted early in the design process. A lack of initial goal clarity leads to starting the design process with broad design spaces that are hard to efficiently explore. As a result few options are generated and analyzed in depth. In addition, verbal communication of established goals may lead to further omissions and misinterpretations especially among the junior representatives of the design team. To a lesser extent, graphically defined goals may have similar results. A junior designer, for example, may have difficulties interpreting hand sketches illustrated in the case study [8]. Options With current methods a multidisciplinary team averaging 12 people can normally produce only 3 design options in 5 weeks - a poor result. Most of this time is spent by architects on generating and presenting the design options. 2 days are dedicated to establishing / understanding project goals and another 2 days to running multidisciplinary analysis. Among possible causes are the goal definition clarity and the tools the AEC industry is using. Current tools support developing only single, static solutions. The dependencies among design criteria are hard to establish, manage and resolve with these tools, making design corrections hard to coordinate real time. This explains why there is no significant difference in the time needed to develop new design options. Analyses Current inability to efficiently perform multidisciplinary model-based analysis resulting in quantifiable metrics is in part motivated by the nature of the AEC tools. The design and analysis tools are not well integrated and require substantial time investment in structuring the information for discipline specific needs. For example, the architect generated geometry is generally unusable by structural engineers, who need to reconstruct it in a suitable format (i.e. wireframe). Furthermore, the current design model does not support efficiently calculating even rudimentary model based analyses such as cost or area, which in turn discourages exploring a larger segment of the design space. Finally, engineers are normally engaged after architects decide on a design option, which leads to inconsistencies in the types of analyses performed on each generated option. Decisions Designers tend to use only a limited selection of high-rise design criteria when making early design decisions. Simons bound rationality theory is a possible explanation. Concurrent consideration of multiple criteria with current design methods simply overwhelms designers, who instead break down the problem into sub problems leading according to Goldschmidt [16] to partial interconnected solutions. As a result, during conceptual design architects generally favor guidelines that help establish the overall building characteristics such as Floor-Area-Ratio (FAR), lease span, aesthetics, aspect ratio, load bearing system, and budget. These are synthesized into adequate design solutions through multiple consecutive manual corrections as illustrated in the case study. The notion of adequacy, however, is often subjective given that most early design decisions are taken by a single discipline.

9

An important impediment in making well informed decisions at the concept development stage is the lack of a comprehensive and systematic method of choosing among design options and the criteria used to generate and analyze them. I demonstrated that in current practice such criteria vary greatly. Furthermore, it is difficult to understand how well each design option performs from a multidisciplinary standpoint given that architectural design criteria are prevalent.

4.2 Phase 2 - Develop framework for translating goals and high-rise design criteria into parametric models and a method to represent and communicate the logic of these models.

In Phase 1 of this thesis I identified a series of important shortcoming in the current conceptual design process. To help address these shortcomings I propose a framework (Fig. 4) to: a) systematize project requirements; b) translate goals into parametric models to generate multiple design options; c) perform qualitative and quantitative analysis of preferred design options; d) formalize decision making by measuring design options in terms of value functions. I will focus my research on the first four process nodes.

Fig. 4 Proposed conceptual design process: a) systematize project requirements; b) translate goals into parametric models to generate multiple design options; c) perform qualitative and quantitative analysis of preferred design options; d) formalize decision making by measuring design options in terms of value

functions. Note: for large resolution image see attached JPG named Fig. 4

In Requirements Engineering goal definition is an essential component in the process of developing a software system. In the context of my research a system will refer to a parametric model. The first research task at this phase is to determine the classification of goals normally considered in high-rise design. I will build on the formal goal taxonomy established by the field of Requirements Engineering [23]. Determining types of goals can help formulate goals and define heuristics for goal acquisition, goal refinement, developing goal requirements, and checking goals for consistency and completeness. I will use the following structure to classify goals: o Objective goals refer to services that will be provided by the system. Provide 50% of the building

interior with daylight is an example of an objective goal. o Adverbial goals refer to ways of achieving objective goals. These could be technical concerns on

precise outcomes that a system component should help to reach such as introducing shading devices or lightshelves, etc.

o Soft goals refer to goals whose satisfaction cannot be established through quantifiable verification techniques. The proposed design should use modern design language is an example of a soft goal.

o Hard goals refer to goals whose satisfaction can be established through verification techniques. Calculate window cost can be quantitatively verified.

10

Following is an early illustration of the proposed framework used to construct goal-driven parametric models. For illustration purposes I use a simplified, hypothetical design problem. The framework is described in terms of several process steps, in which the design team incrementally develops four complementary submodels: (1) the goal model, (2) the design scenario, (3) the process model, (4) the operation (parametric) model. Step 1 goal model: representatives of all disciplines (architect, structural, mechanical engineers, and project manager) jointly meet the project stakeholder(s) to elicit a preliminary set of high-level, objective goals that will normally include hard and soft goals. The stakeholders are thus exposed to multidisciplinary design criteria for more informed early decision making. The design team then asks the stakeholder(s) to rank the goals according to their level of importance. The result of such meeting can be the following spreadsheet:

Goal Established by Stakeholder ranked goal

importance (1 lowest, 10 highest)

50,000 m2 hotel Client 8 Maximize the use of daylight in

50% building interior Mechanical engineer 9

Modern design language Architect 5 $50m budget Client 10

Step 2 design scenario: Once a preliminary set of objective goals is obtained and validated with stakeholders, the design team groups these goals according to their type and refines the goals by asking HOW these can be implemented in a parametric model. As a result, a pictorially represented design scenario is developed as shown in Fig. 5. The design scenario describes the means of achieving goals in a parametric system and serves as a means to formally define a desired design space. First, the goals are organized into Hard (i.e. maximize use of daylight in 50% of interior space, building the design should cost $50m or less, provide 50,000 sq m of hotel area) and Soft (i.e. use modern design language). These are ranked according to the goals model in order to help designers develop solutions according to stakeholder preferences. By asking the HOW question designers develop adverbial goals for each hard or soft goal. To address goal decomposition / granularity and illustrate the links among goals I propose using the AND/OR formalism. For example, in order to provide daylight in 50% of the building interior designers need the ability to a) control the building orientation; AND b) control the lease span; OR c) introduce shading devices; OR d) introduce light shelves; AND e) control window configuration. All adverbial goals with AND links are required to satisfy a hard or soft goal, whereas an OR link illustrates a choice of action. Adverbial goals are developed collaboratively by multidisciplinary design teams in joined meetings. The last level of granularity in a design scenario includes the means to translate adverbial goals into a parametric model. Here designers need to pre-rationalize the number and types of parameters required to achieve a given goal. A similar AND/OR formalism applies. For example, to introduce shading devices a designer must create a depth parameter of length type AND an inclination parameter of angle type after anticipating the need to adjust the shading devices geometry in response to the provide daylight in 50% of interior goal. Controlling the shaders depth and inclination parametrically offers efficient means to refine the geometry after a formal daylight analysis in a specialty tool is performed.

11

All adverbial goals elicited to address hard goals result in quantifiable parameters. However, this is not true for the soft goals. For example, for the make prevalently glass exterior goal designers can propose a) butt glazing, OR b) expressed mullions system, OR c) a hybrid of cladding and glazing. These are possible design strategies. Design scenarios offer several important benefits. First, determining the objective goals in the goal model process step may not reveal potential conflicts among goals. These, however, can be identified when adverbial goals are determined. For example, meeting the $50m budget can potentially conflict with the make prevalently glass exterior adverbial goal given the high cost of glass. A design scenario will show conflict links among goals (Fig. 5 magenta arrows). Knowing that meeting the $50m budget is the most important goal to the stakeholders and use modern design language is the least, which includes the make prevalently glass exterior adverbial goal, designers can justify the choice of cladding and glazing strategy as the least expensive. Second, a formal definition of parameters and design strategies can help determine interdependencies that can accelerate the parametric modeling process. For example, the choice of an exterior wall system will impact the glass cost parameter, which in turn will impact the mullions cost parameter and the cladding cost parameter (Fig. 5 red arrows).

Fig. 5 a design scenario includes objective goals organized into Hard and Soft goals ranked according to the stakeholders preferences. Adverbial goals are then elicited to develop means of translating objective goals into a parametric model. Potential conflicts among goals are determined. AND/OR

formalism is used to address goal decomposition. Note: for large resolution image see attached PDF named Fig. 5

Step 3 the process model: I propose developing and using Parametric Process Maps (PPMs) to illustrate: a) the technical implementation of a design scenario in a parametric model; b) various levels of information dependencies. A PPM (Fig. 6) consists of 1) components (i.e. ground footprint) made of geometric and / or construction elements (i.e. points, lines, arcs, BSplines, planes); 2) PowerCopies (PoC) made of components that are grouped and intended to be used in a context; 3) PoC definition input variables allow a PoC to be instantiated according to the context into which it is pasted; 4) input numeric variables (local or global) used to define geometry (i.e. line length, arc radius, etc); 5) output numeric

12

variables derived from geometric elements (i.e. measure surface area) or defined formulaically (i.e. X + Y); 6) geometric constraints (i.e. tangency, parallelism, coincidence, etc) used to establish relationships among geometric elements; 7) constrained parameters (i.e. parameter values are not varied); 8) numeric variable or geometric constraint dependency (i.e. light-shelve dependent on the depth variable, etc); 9) component dependency (i.e. component B dependent on component A); 8) visual previews of components.

a) b)

Fig. 6 a) parametric process map (PPM) representation formalism; b) notation legend Fig. 7 illustrates a PPM for the design scenario described in Step 2. Each component that has a visual preview is numbered. The input variables and geometric constraints for each component are lettered and their location is shown in the component preview. Given the list of adverbial goals, designers must determine the goals that affect the starting point of a parametric model building process. For example, the simplify volume goal has two possibilities curved or rectilinear geometry. This means that the model should support change in geometric topology. Therefore, the ground footprint (1) (component (1), Fig. 7) should be made of geometric elements supporting such transformation. A BSpline of order 2 is the best choice. Being a linear BSpline it can either be a line or a curve depending on how it is geometrically constrained to other elements. The choice of geometry will determine the types of input variables controlling the component as well as the geometric constraints. For example, building length (B) variable controls the length between the BSpline endpoints, which use a concentric (E) and tangency (F) constraint to a skeleton of construction (dashed) lines. Tangentially constraining the BSpline endpoints to the construction lines will change the geometrys topology. The construction lines endpoints are coincidentally (C) constrained to establish a pin connection. The lines use a perpendicular constraint (D) to avoid arbitrary rotation. In response to control building orientation goal the rotation angle (A) parameter is introduced by constraining the angle between the construction line end point and the chosen axis of the user coordinate system. Having established the ground footprint allows the dependent components to be constructed. For example, building core footprint (2) is constrained through lease span (A) variable to the ground footprint (1) BSplines, thus establishing a component dependency. Changes in the footprint will impact the core unless the lease span variable is adjusted to compensate the increase or decrease in the building length variable. The other components are similarly established, allowing designers to formally rationalize the information flow in a parametric model and the models structure in terms of inputs and outputs.

13

Fig. 7 a Parametric Process Map (PPM) helps technically implement a design scenario in a parametric model. A PPM consists of components, construction elements, parameters, constraints, and information

dependencies. Note: for large resolution image see attached JPG named Fig. 7

Step 4 the operation model: The last step is translating the PPM into a parametric model. The PPM offers designers a clear choice of components and geometric elements for constructing components, as well as the types and definition process of input and output parameters and constraints to be used. Fig. 8 illustrates a set of parametric variations generated in response to the adverbial goals from the design scenario.

14

a) b) c) d) e)

Fig. 8 constant net sealable area of 50,000m2 a) building height = 200m, building length = 36m, lease span = 10m, No floors = 50, fl height = 4m,

light-shelves depth = 2m, window width = 1.5m; b) building height = 150m, building length = 43m, lease span = 11m; No floors = 37, fl height = 4m,

light-shelves depth = 2m, window width = 1.8m; c) building height = 150m, building length = 45m, lease span = 12m; No floors = 31, fl height = 4.8m,

light-shelves depth = 1m, window width = 2m d) building height = 150m, building length = 45m, lease span = 12m; No floors = 31, fl height = 4.8m,

light-shelves depth = 1m, window width = 1.8m e) building height = 200m, building length = 45m, lease span = 12m; No floors = 41, fl height = 4.8m,

light-shelves depth = 2m, window width = 1.8m 4.3 Phase 3 - Validation

Performance metrics describing the current concept design process discussed in Section 4 (Phase 1) of this thesis will be compared with:

o Performance metrics of a process using parametric modeling without the framework described in Section 4.3 (Phase 2) of this proposal. This comparison will be done retrospectively on the three completed case studies: Infinity tower, Dubai; Jinta Tower, China; Transbay tower, San Francisco. Preliminary findings indicate the need to construct multiple parametric models for the same design problem in absence of an explicit design scenario (Fig. 9).

a) b) c)

Fig. 9 Transbay tower 3 of 6 models constructed during conceptual design without a design scenario

15

o Performance metrics of a process using parametric modeling with the proposed framework. This comparison will be done prospectively on 3-5 industry case studies.

5. Expected contributions

Most of my research will focus at the intersection of two fields requirements engineering and parametric modeling (Fig. 10).

Fig. 10 Venn diagram of relevant research fields

The anticipated scientific contributions of this research are: 1) methodology for building parametric models from high-rise design criteria and ranked project goals; 2) formal understanding of the impact of parametric modeling on the design process in terms of quantifiable metrics. The anticipated contributions on a practical level are: framework to: 1) facilitate the adoption of parametric methods by the AEC industry; 2) formalize design decisions based on goal-driven design scenarios.

6. Research schedule

Task No. Research Task

% completed

Completion date

1. Observe current practice (Phase 1) 100% -

2. Establish metrics describing current practice & build process model (Phase 1) 100% -

3. Conduct survey to support observations & established metrics (Phase 1) 100% -

4. Write Benchmarking Current Practice paper (Phase 1) 80% 10-08

5. Classify types of goals generally considered in high-rise design & strategies for implementing them (Phase 2) 20% 03-09

6. Develop the goal model formalism (Phase 2) 30% 01-09 7. Develop the design scenario formalism (Phase 2) 30% 04-09 8. Develop the parametric process map formalism (Phase 2) 80% 02-09

9. Write Goal driven parametric modeling for improved conceptual high-rise design framework paper (Phase 2) 0% 08-09

10. Validate framework on 3-5 industry case studies (Phase 3) 10% 06-10 11. Write case studies (validation) paper (Phase 3) 0% 09-10 12. PhD defense 0% 12-10

16

References 1. United Nations, (2004). World population to grow from 6.5 billion to 9.1 billion by 2050. Accessed at

http://www.un.org/esa/population/publications/WPP2004/2004_Revision_press_release_Final.pdf 2. McElfish, J. (2007). Ten Things Wrong With Sprawl. Environmental Law Institute report. 3. Kienast, F. Jaeger, J. (2006). Degree of urban sprawl in Switzerland: Quantitative analysis 1940

2002 and implications for regional planning. Swiss Federal Institute of Forest, Snow and Landscape Research; ETH.

4. Yeang, K. (1996). The Skyscraper Bioclimatically Considered a design primer. Academy Editions. 5. Alread, J., Leslie, T., (2007). Design-Tech. Building Science for Architects. Architectural Press. 6. Kaplan, D., (2004). High Performance High-Rise Residential Buildings. AIA Center for Building

Performance. Symposium on Building Performance. 7. Sutton, R. (2002). Weird Ideas that Work - 11.5 practices for promoting, managing, and sustaining

innovation. The Free Press, New York, NY. 8. Gane, V., Haymaker, J., (2008). Benchmarking Conceptual High-rise Design Processes. Stanford

Center for Integrated Facility Engineering working paper. 9. Kolarevic, B. (ed), (2003). Architecture in the Digital Age: Design and Manufacturing. Taylor &

Francis. 10. Akn, . (2001). Variants of design cognition. Design Knowing and Learning: Cognition in Design

Education. Eastman, C., Newstetter, W., & McCracken, M., Eds., pp. 105124. New York: Elsevier. 11. Haymaker, J., Chachere, J., (2007). Coordinating goals, preferences, options, and analyses for the

Stanford Living Laboratory feasibility study. Conference paper. 12. Krishnamurti, R. (2006), 20, 95-103, Explicit design space? Artificial Intelligence for Engineering

Design, Analysis and Manufacturing. 13. American Institute of Architects (AIA), (2007). Integrated Project Delivery: A Guide. 14. Simon, H. (1991). Bounded Rationality and Organizational Learning, Organization Science 2(1):

125-134. 15. Woodbury, R., Burrow, A., (2006), 20, 63-82, Whither Design Space?, Artificial Intelligence for

Engineering Design, Analysis and Manufacturing 16. Goldschmidt, G., (2006), 20, 105-111, Quo vadis, design space explorer?, Artificial Intelligence for

Engineering Design, Analysis and Manufacturing 17. Rolland, C.; Pernici, C. (1998). A Comprehensive View of Process Engineering. Proceedings of the

10th International Conference CAiSE'98, B. Lecture Notes in Computer Science 1413. Pisa, Italy: Springer.

18. Froese, T. (1996). Models of Construction Process Information. pp. 183-193. Journal of Computing in Civil Engineering.

19. International Alliance for Interoperability, Data Modelling Using EXPRESS-G for IFC Development, Accesses at http://www.iai-international.org/Model/documentation/Data_Modelling_Using_EXPRESS-G_for_IFC_Development.pdf

20. Integrated Definition Methods. Accessed at http://www.idef.com/idef0.html 21. Haymaker, J. et. al. (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. 22. Tapping, D., Shuker, T. (2002). Value Stream Management. Productivity Press. 23. Rolland, C., Salinesi, C. (2005). Modeling Goals and Reasoning with Them. Engineering and

Managing Software Requirements. 24. Ross, D., Schoman, E. (1977). Structured Analysis for Requirements Definition. IEEE Transactions

on Software Engineering, Vol. SE-3, No. 1.

17

25. Lamsweerde A (2000). Requirements engineering in the year 2000: A research perspective. In: Proceedings of 22nd International Conference on Software Engineering, (ICSE2000): Limerick, Ireland, Invited Paper, ACM Press, pp. 519.

26. Lamsweerde A (2001). Goal-Oriented Requirements Engineering: A Guided Tour. Proceedings RE01, 5th IEEE International Symposium on Requirements Engineering, Toronto, 249-263.

27. Jackson, M. (1995). Software requirements & specifications a lexicon of practice. Principles and Prejudices, ACM Press, Addison-Wesley.

28. Lamsweerde, A, Letier E. (2000). Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, Special Issue on Exception Handling, 26(10): 978.1005.

29. Lamsweerde, A. (2004). Goal-oriented requirements engineering: A roundtrip from research to practice. Proceedings of 12th IEEE International Symposium on Requirements Engineering, Kyoto, Japan

30. Kiviniemi, A., Fischer, M., Bazjanac, V., Paulson, B. (2004). PREMISS - Requirements Management Interface to Building Product Models: Problem Definition and Research Issues. CIFE working paper.

31. Kilian, Axel. PhD Scholar, MIT. From an interview conducted in March, 2004. 32. Danaher, M. (2000). Expert Systems A Design Application. Proceedings, 22nd International

Conference, Information Technology Interfaces, Pula, Croatia. 33. Maher, M.L., Fenves, S.J. (1985). Hi-Rise: A Knowledge-Based Expert System for the Preliminary

Structural Design of High Rise Buildings. Department of Civil Engineering, Carnegie-Mellon University, Pittsburgh, USA.

34. Sabouni, A.R., AI-Mourad, O.M. (1997). Quantitative knowledge based approach for preliminary design of tall buildings, Artificial Intelligence in Engineering, 11.

35. Haber, D., Karshenas, S. (1990). Conceptual; An expert system for conceptual structural design. Microcomputers in Civil Engineering, 5,2, pp 119-125.

36. Fleming, J., Elghadamsi, E., Tanik, M. (1990). A knowledge-based approach to preliminary design of structures. Journal of Energy Resources Technology, ASME, Vol 1 12, 4, pp. 213 - 219.

37. Domeshek, E., Kolodner, J. (1992). A case-based design aid for architecture. Artificial Intelligence in Design 92, J. S.Gero, Ed., Kluwer Academic Publishers, The Netherlands, pp. 497-516.

38. Baker, W. F. (2008). Extending Structure and Architecture - Studies in Structural Topology. The John A. Blume Distinguished Lecture Series, Stanford University. April 17, 2008.

39. Whitehead, H. (2003). Laws of Form. Architecture in the Digital Age: Design and Manufacturing. Taylor & Francis.

40. Survey conducted between January May, 2008. 20 participants from the following firms: Skidmore, Owings & Merrill LLP (SOM), Kohn Pedersen Fox Architects (KPF), Adrian Smith + Gordon Gill Architecture, Hellmuth, Obatta, Kassabaum (HOK), HWI Architects, Atkins, Arquitectonica.