Research in Engineering Design, (2004), Vol.15, No. 4
COLLABORATIVE MULTIDISCIPLINARY DECISION MAKING USING GAME THEORY AND DESIGN CAPABILITY INDICES Angran Xiao a *, Sai Zeng b †, Janet K. Allen a ‡, David W. Rosen a § and Farrokh Mistree a ** a b
Systems Realization Laboratory
Engineering Information System Laboratory
George W. Woodruff School of Mechanical Engineering Georgia Institute of Technology, Atlanta, GA 30332-0405, USA
Word Count 9,695
* Graduate Research Assistant. Currently Postdoctoral Fellow, Virtual Reality Application Center, Iowa State University, Ames, Iowa 50014. email:
[email protected] † Graduate Research Assistant. Currently IBM research staff member. IBM T. J. Watson Research Center, Hawthorne, NY 10532. email:
[email protected] ‡ Senior Research Scientist. e-mail:
[email protected] § Associate Professor. e-mail:
[email protected] ** Professor. Corresponding Author. Phone/Fax: 404-894-8412/9342; e-mail:
[email protected]
1
ABSTRACT The complexity of modern product realization processes requires collaborative work of engineering teams from different disciplines. We apply principles from game theory to model the relationships between engineering teams and facilitate collaborative decision making. In order to maintain design freedom in the early stages of product realization so that engineering teams in the later stages can adjust their decisions while still maintaining feasibility, we postulate the use of design capability indices to facilitate the teams making a ranged set of decisions, instead of specific ones. The effect of game theoretic principles and design capability indices on design freedom and therefore on the design solutions is also investigated. An electronic package design and analysis scenario is used to demonstrate the efficacy of the proposed method.
Keywords: Multidisciplinary Design, Collaboration, Game Theory, Design Capability Indices, and Design Freedom
1. COLLABORATIVE DECISION MAKING The complexity of the product realization process requires the collaboration of engineering teams from multiple disciplines. In this section we provide an overview of the issues involved; for a detailed discussion see [Xiao 2003].
1.1 Single-Level and Bi-Level Approaches The most widely practiced approach to handle the increased computing burden and organization difficulties [Sobieszczanski-Sobieski et al. 1997] in collaborative and multidisciplinary decision making is to integrate all the decision making responsibilities into a single system-level team, usually the design team. The design team handles communication and interdisciplinary interactions, and develops a product to meet the requirements. providing disciplinary analyses when requested.
The other teams are only responsible for
The philosophy underlying this approach is
Integrated Product and Process Design, but it becomes infeasible for complex multidisciplinary problems such as aircraft design in which thousands of design variables are required [Berkes 1990]. Two in-depth surveys of single-level approaches and their variants are presented by Sobieski and
2
coauthors [Balling et al. 1996, Sobieszczanski-Sobieski et al. 1997].
In the following we
summarize our findings. Although being effective when a few disciplines are involved, single level approaches are not effective for multidisciplinary product realization because: (1) All these approaches require interdisciplinary iterations in order to achieve reasonably accurate multidisciplinary feasibility; this incurs massive computing costs in processes involving many disciplines. (2) All these approaches require the solution of a system level decision problem encompassing at least all the coupling variables; this soon becomes too complex to be solvable. (3) These approaches add additional requirements to the compatibility of discipline dependent software, and (4) Engineering teams prefer to make decisions within their own disciplines.
Multidisciplinary product realization problems have to be addressed by decomposing them into simpler and more manageable sub-problems, and assigning greater autonomy to the disciplinary teams [Balling et al. 2000]. Consequently, the organizational difficulties must be confronted.
These organization difficulties are addressed using coordination technologies.
Coordination
technology is defined as the high level concept of system representation, planning, scheduling, and control of product realization processes with respect to time, task, resources and design requirements [Duffy et al. 1993]. When using coordination technologies, a product realization process is decomposed across the boundary between disciplines into activities and organized accordingly.
Bi-level decision making approaches have been developed which decomposed the multidisciplinary problem into a set of discipline level sub-problems and one system level problem. Disciplinary teams are assigned the authority to make local decisions as well as perform analysis. In Concurrent Sub-Space Optimization (CSSO), discipline teams solve sub-problems concurrently while the system level team coordinates, removes conflicts, and achieves multidiscipline feasibility [Sobieszczanski-Sobieski 1988].
Wujek and coauthors develop CSSO using response surface
3
methodology, allowing variable sharing among sub-problems [Wujek et al. 1996]. Kroo and Braun present Collaborative Optimization (CO) in which auxiliary variables are introduced to replace the coupled variables in each sub-problem so that the sub-problems can be solved concurrently [Braun et al. 1997, Kroo et al. 1994]. Sobieski and Kroo improve CO using response surface methodology [Sobieski et al. 2000]. CO has attracted research attention because it can capture interdisciplinary interactions.
For example, Gu and coauthors apply CO to separate business decisions and
engineering decisions in product realization [Gu et al. 2002]. However, because of the iterations between discipline and system levels, “theoretical convergence of this approach remains an open question” [Burgee et al. 1996]. Bi-level Integrated System Synthesis (BLSS) has been recently introduced by Sobieski and colleagues, in which the system level problem is formulated using only coupled variables.
Optimization results are obtained by alternating between the system level
problem and discipline level sub-problems, which are linked by the “derivatives of the state variable with respect to coupled variables and Lagrange multipliers of the constraints obtained at the solution of sub-problems” [Kodiyalam et al. 2000, Sobieszczanski-Sobieski et al. 2000]. Unfortunately, all these bi-level approaches suffer from the so-called “curse of dimensionality”.
We find that although they should be two continuous steps in product realization, there is an obvious gap between coordination technologies that model and manage product realization activities and the decision making approaches that facilitate engineering teams solving optimization problems and accomplishing these activities.
Accordingly, we suggest that the following questions are
germane: What is the appropriate way to model the interactions between engineering teams? How can a disciplinary team make decisions that are superior from the perspective of all disciplines in the product realization process, especially at the early stages of product realization?
1.2 Approaches Based on Game Theory The success of game theory in economics has inspired researchers to apply game theory to solve conflicts among engineering teams in multidisciplinary product realization.
In the context of
product realization, a game is a decision making process between multiple teams each of which controls a subset of design variables and seeks to minimize its cost function subject to individual
4
constraints [Lewis et al. 1998]. That is, engineering teams act like players in a game; they cooperate to achieve a set of overall goals.
In this paper, we consider three game protocols: cooperative, noncooperative, and leader/follower; each protocol models a game construct that represents one type of interaction between engineering teams. Rao successfully applies a cooperative protocol in multi-objective structural optimization [Rao 1987] and control structure integrated design [Rao et al. 1988]. Rao and Dhingra combine a cooperative protocol and fuzzy theory to handle preliminary product design in which some objective functions and constraints are not yet fully specified [Dhingra et al. 1995]. Badhrinath and Rao present multiple player games and use leader/follower protocols to represent the relationship between product design and manufacturing [Badhrinath et al. 1996].
Chen and Li further
investigate interaction between product design and manufacturing using all three game protocols [Chen et al. 2002]. Lewis and Mistree illustrate the use of the principles of game theory to model the interactions among engineering teams in decision making, and systematically study all three protocols [Lewis et al. 1998].
These game protocols have been shown to be effective in
representing interactions between engineering teams and facilitate each team making decisions from the overall perspective [Lewis et al. 1997, Lewis et al. 1998]. Xiao and coauthors test the efficacy of these protocols between design and manufacturing teams in a rapid prototyping scenario, and postulate that game theoretic principles can help reduce iterations among engineering teams; help a team quantitatively predict other teams’ responses to its decisions; and help to limit the size of any decision making problem in a product realization process [Xiao et al. 2002].
It is noted that the very fundamental difference between game based approaches and those introduced before is that single- and bi-level approaches use only one cost function, or objective function, as the evaluation of a single result; while in the game-based approach, each team holds its cost function.
These teams make decisions independently like a group of game players; this
satisfies the assumption made in coordination technologies. By removing the system level team and assigning autonomy to disciplinary teams, the burden of disciplinary analysis and decision making is distributed to each team, and coordination technologies can be easily used to handle the organization difficulties. Hence, we contend that game based approaches bridge the gap between
5
coordination technologies and decision making approaches. In this paper, we improve the game based approach to better solve multidisciplinary product realization problems by introducing ranged solution into game theoretical principles to maintain design freedom in the early stages of product realization.
Design freedom is the extent to which a system can be adjusted while still meeting its design requirements [Simpson et al. 1998]. Simpson and coauthors present the curves showing design freedom changes along a design timeline, Fig. 1. In a typical product realization process, the solid curve, design freedom declines rapidly in the early stages as specific decisions are made. The dashed curve represents the ideal situation in which engineering teams maintain design freedom by making a ranged set of decisions so that “better decisions can be made before the freedom to make these decisions is eliminated” [Simpson et al. 1998]. Therefore, an upstream team should present a ranged set of solutions (value of each design variable) in which any specific point in the range meets the design requirements in its discipline; downstream teams can specify (or shrink) the ranged solutions based on new design requirements and constraints in other disciplines without jeopardizing their feasibility of the upstream discipline.
The idea of making a ranged set of
decisions enables an engineering team to make decisions to satisfy not only the disciplinary requirements, but also unforeseen requirements from other disciplines.
100%
Design Freedom
Maintain Freedom
Reduce Product Lead Time
Time-Line
Fig. 1 Change of Design Freedom Along a Design Timeline [Simpson et al. 1998]
The key point in this approach is to decide the ranged design solutions that, when combined, can satisfy the design requirements as well as possible. In this paper, we use Design Capability Indices
6
for this purpose. We note that this notion has been shown to work in [Chen et al. 1999a] and [Kalsi et al. 2001]; we build on material presented in both.
2. FRAME OF REFERENCE Our collaborative decision making method consists of four steps: (1) representing the product realization activities in compromise DSPs and instantiating these compromises DSPs into decision templates, (2) using game protocols to represent interactions between teams and solve the product realization problem, (3) measuring design freedom in product realization using the metrics presented in [Simpson et al. 1998], and (4) increasing design freedom by formulating compromising DSPs using design capability indices. In this section we present material that is needed to understand the foundational elements of the proposed method.
2.1 Decision Templates A compromise DSP is a multi-objective decision model which is a hybrid formulation based on mathematical programming and goal programming in which the objective is to satisfy a set of constraints while achieving a set of conflicting goals as well as possible [Mistree et al. 1990]. The mathematical formulation of the compromise DSP is given in Fig. 2. Because of its standardized format, a compromise DSP can be used to model the decision making activities of all of the engineering teams.
The compromise DSP formulated in the most elementary entities, e.g.,
mathematical formulations or computer codes, which are easy to understand by engineering teams and implementable on computer, is called a decision template. Decision templates are used as information communication entities between teams. The information communication capability of the decision template extends beyond that of other media, such as STEP, STL, and IGES, because it can transfer design requirements, product model(s), design freedom, and information about capability and constraints of product realization activities [Rosen et al. 2000].
In a product
realization process, decision templates that represent an engineering team’s activities are coupled by shared design variables and state variables that represent interdisciplinary interaction relationships.
7
Game theoretic principles are used to model this interaction and solve the coupled compromise DSPs.
Given An alternative to be improved Target values for goals, Gi, i = 1,…,n Relative importances of goals, wi Find System Variables: xj ∈ X, j = 1,…,m – + Deviation Variables: di , di Satisfy Goals: Ai(X)+ di– − di+ = Gi, Constraints: Ck(X) ≤ 0, k = 1,…,p di– ⋅ di+ = 0, di–, di+ ≥ 0 Bounds: lbj ≤ Xj ≤ ubj Minimize Deviation Function: Z = Σwi ⋅ di+ + Σwi ⋅ di–,
Fig. 2 Mathematical Formulation of the Compromise DSP [Mistree et al. 1993]
2.2 Game Constructs To distinguish a game based approach from other decision making approaches, when solving problems using the principles of game theory, we use the term “player” to represent a disciplinary engineering team with its associated computer-based analysis and synthesis tools (decision templates).
Pareto or Cooperative Solution The ideal scenario for collaboration is full cooperation between two players†† in which both players have full access to information about each other’s decision making process, including their decision templates and associated engineering tools.
Assuming coupled compromise DSPs, A and B
respectively represent the decision making activities of player A and B, a full cooperation scenario
†† For games between more than two players see Marston, 1997.
8
is solved by combining all players’ DSPs, hence all goals, constraints, etc. in DSPs A and B are satisfied in one DSP, as shown in Fig. 3. Mathematically this is:
minimize Z = wA Z A ( x A ) + wB Z B ( xB )
(1)
Full cooperation rarely occurs in practice because it is difficult to access all the decision making information of another player, especially in a distributed environment. The player who seeks full cooperation must be able to combine two decision templates. It is not reasonable for a player to operate the engineering tools associated with other players because they are usually in different disciplines and demand some specialized knowledge.
From the computing perspective, full
cooperation protocol equals to the single level decision making approaches, a product realization process may has many design variables that cannot be solved in a single compromise DSP. A more practical scenario is approximate cooperation introduced in [Lewis et al. 1998]. Here, cooperative game is solved solely for the purpose of comparison.
Given x A, s A, ( xB , sB ) Find x A , d i- , d i+ Satisfy GA ( x A, s A, xB , sB ) + d i- - di+ = 0 C A ( x A, s A, xB , sB ) ≤ 0 Minimize Z A ( xA )
Solution
⊕
Given x B , s B , ( x A, s A ) Find xB , di- , di+ Satisfy GB ( xB , sB , xA, s A ) + d i- - di+ = 0 CB ( xB , sB , xA, s A ) ≤ 0 Minimize Z B ( xB )
Given x A, s A, xB , sB Find x A , xB , di- , di+ Satisfy GA ( x A, s A, xB , sB ) + d i- - di+ = 0 GB ( x A, s A, xB , sB ) + d i- - di+ = 0 C A ( x A, s A, xB , sB ) ≤ 0 C B ( xA, s A, xB , sB ) ≤ 0 Minimize Z = wA Z A ( xA ) + wB Z B ( xB )
Fig. 3 Solution of Cooperative Game
Nash or Noncooperative Solution At the other extreme of collaboration is noncooperation, in which game players cannot receive information about each other’s decision making activity. Therefore each player must make a set of decisions that is rational to him/her by assuming the other players’ reactions, their Best Reply Correspondence, BRC. If there is an overlap between these players’ BRCs, the result can be selected from the intersection. For instance, in Fig. 4, XA and XB are respectively the design variable
9
sets in players’ A and B’s compromise DSPs. xA is a subset of XA which must be determined using information from player B’s compromise DSP. Then these two player’s BRCs are respectively represented as xA = f(xB) and xB = f(xA). The intersection of these BRCs can be found by solving those equations. Design of Experiment techniques and Response Surface Methodology can be used to construct the players’ BRCs. Using xAN ( xB ) to represent the Nash solution of xA, the mathematics is:
xAN ( xB ):={x AN ∈ X A : Z A ( xAN , xB )= min Z A ( xA , xB )} x A ∈X A
xBN ( xA ):={xBN ∈ X B : Z B ( xA , xBN )= min Z B ( x A , xB )} xB ∈ X B
(2)
( x AN , xBN ) ∈ x AN ( xB ) ⊗ xBN ( x A ) Given x A, s A, ( xB, sB ) Find x A , di- , di+ Satisfy GA ( xA, s A, xB , sB ) + di- - di+ = 0 C A ( xA, s A, xB , sB ) ≤ 0 Minimize Z A ( xA )
Given xB , sB , ( xA , s A ) Find xB , di- , di+ Satisfy GB ( xB , sB , x A, s A ) + di- - d i+ = 0 CB ( xB , sB , x A, s A ) ≤ 0 Minimize Z B ( xB )
A&B 's Best Reply Correspondence
A's Solution Space
B's Solution Space Solution
Fig. 4 Solution of a Noncooperative Game
Stackelberg or Leader/Follower Solution A leader-follower protocol is well suited to a situation in which one player dominates the decisionmaking process, or the “influence of a certain domain on another is strongly unidirectional” [Lewis et al. 1998]. A leader/follower protocol is a special instance of a noncooperative protocol, in which the follower constructs his/her BRC by assuming the leader’s decision, then the leader makes a decision using this BRC in his/her compromise DSP.
Assuming player A is the leader, the
mathematics is:
minimize Z A ( x A , xB ) satisfying
xB ∈ xBN ( x A )
10
(3)
These three game protocols represent the possible collaboration styles between two game players. A player can make a decision while considering other players’ reactions by applying the other player’s BRCs in his/her compromise DSP.
2.3 A Metric for Measuring Design Freedom Simpson and coauthors present a metric to quantify design freedom of a system by measuring the overlap between the target ranges for the system performance (decided by design requirements) and the achievable performance ranges of the system [Simpson et al. 1998]. DF =
1 n Overlapi 1 n TRi ∩ PRi = ∑ ∑ n i =1 PRi ,initial n i =1 PRi ,initial
(4)
where n is the number of performance measures of the system. For the ith performance, TRi is the target range, PRi is the feasible performance range, and PRi,initial is the initial feasible performance range. At the beginning of a traditional product realization process, when little is known about the product, engineering teams assign a large adjustable range to each design variable based on their experience, this is represented as bounds in the compromise DSPs, Fig. 2. While knowledge about the product gradually increases, the range of each design variable is gradually decreased because engineering teams are more confident that the final result can be found within this more specific area of design space. The ranged values of design variables will finally be shrunk into point values in the final stages of product realization, when design freedom equals 0, meaning that the product design cannot be changed.
In order to maintain design freedom in a product realization process, engineering teams present ranged set of solutions (ranges of design variables). For simplicity, in this paper, the range of each design variable is assigned a value of ±10% of its bounds; hence the performance measures of a design solution are also ranged values. Since each initial feasible performance range, PRi,initial, is determined at the beginning of the product realization process, the larger the overlap between TRi and PRi, the greater the design freedom. The problem then becomes deciding how the ranged values of the design variables can be determined to ensure that the overlap between TRi and PRi is as great as possible?
11
2.4 Design Capability Indices Chen and coauthors present design capability indices to evaluate performance variations caused by a range of design solutions, and determine whether the design solutions are capable of satisfying a ranged set of design requirements [Chen et al. 1999b].
In Fig. 5, system performance is
approximated by a distribution with mean µ and standard deviation σ.
URL and LRL are
respectively the upper requirement limit and lower requirement limit that form the target range of the performance. In the case in which larger is preferred, all possible design solutions meet design requirements when µ−LRL>3σ. In the case in which the design performance goal is required to be as small as possible, all possible design results fall into the target range of design requirements when URL−µ >3σ. In these two cases, the design capability index Cdk is calculated using Cdl and Cdu in Eq. (5) respectively, and design solutions with Cdk ≥ 1 are capable of satisfying design requirements. In the case in which nominal is preferred, all possible design results fall into the range between URL and LRL, and the target value is the midpoint between these two limits. Hence Cdk is the smaller value of Cdl and Cdu. In all cases, Cdk0, d− = 0; a positive deviation value means under-achievement, d− >0, d+ = 0.
Table 2 Nominal Values of Game Solutions Solutions C (mm)
Trial/E Coop. Non-coop Experiment 1: Without Using Cdk 0.6434 0.7785 0.6434
20
L/F 0.6434
D (mm) S (MPa) T (oC) Deviation C (mm) D (mm) S (MPa) T (oC) Deviation C (mm) D (mm) S (MPa) T (oC) Deviation
0.0700 0.0700 0.0700 183.63 160.90 183.63 66.77 69.27 66.77 −0.0398 −0.0818 −0.0398 Experiment 2: Using only CdT 0.6434 0.7774 0.6622 0.0700 0.0700 0.0700 183.63 161.01 179.36 66.77 69.23 66.82 −0.0398 −0.0818 −0.0507 Experiment 3: Using CdS and CdT 0.6622 0.7568 0.6622 0.0700 0.0700 0.0700 179.36 163.31 179.36 66.82 68.53 66.82 −0.0507 −0.0807 −0.0507
0.0700 183.63 66.77 −0.0398 0.6434 0.0700 183.63 66.77 −0.0398 0.6622 0.0700 179.36 66.82 −0.0507
4.1 Engineering Significance of Design Solutions An understanding of the engineering significance of these cases can be obtained by analyzing the design results. As shown in Table 2, the die attach thickness D always equals to its upper bound, 0.07mm. This is caused by the CTE (Coefficient of Thermal Expansion) mismatch between the materials of the die attach and chip. Since the die attach connects the chip and heat spreader, a temperature rise causes the chip and die attach to expand at different rates and generates thermal stress along their interface. The die attach then deforms under the thermal stress and serves as a buffer that decreases the stress transferred to the chip. Hence, the thicker the die attach, the lower the thermal stress along the interface. The values of the die attach thickness in the design solutions are pushed to the upper bound because of the stress goal, 190MPa. On the other hand, since the thermal conductivity of the die attach is lower than that of the heat spreader, the thicker the die attach, the higher the temperature on the chip. Therefore, in future designs, it is advisable to replace the material of the die attach with one having higher thermal conductivity, lower Young’s modulus, and similar CTE to the chip.
The chip thickness, C, is another important parameter in package design as heat generation in a chip is proportional to its volume. By studying the results in Table 2, we find that large chip thickness increases the temperature and slightly decreases the stress along the interface of chip and die attach. This occurs because a thicker chip has larger space to expand, which causes stress redistribution and
21
hence reduces the maximum stress along the interface. By comparing the resulting temperature and stress with corresponding values of C and D, we conclude that, in this scenario, chip thickness is more significant than attach thickness in temperature design, and the die attach thickness is more significant in stress design.
4.2 Efficacy of Design Capability Indices Design capability indices are embedded in compromise DSPs to satisfy ranged design goals. At the same time, as the final design solution is a specific solution selected within the ranged solution, we do not want to sacrifice the target achievement of the final solution. The target achievements of the design solutions are evaluated using their overall deviations from targets, 190MPa in stress design and 70oC in temperature design. For ranged values, the nominal value is used to calculate the deviations.
Overall Deviation from Target Values Tria l/Erro r
Coo p
No n-C o o p
L/F
0 -0.01 -0.02 -0.03 -0.04 7
-0.05 -0.06 -0.07 -0.08 -0.09
Exp. 1(No Cdk)
Exp. 2 (CdT)
Exp. 3 (CdT, CdS)
Fig. 10 Deviations from Target Values
The overall deviations of these design solutions are presented in Table 2 and shown in Fig. 10. Again, all these overall deviation values are negative, meaning that any solution in Table 2 overachieves the design targets from the overall perspective. We also observe that the deviations in the same type of games do not increase substantially by embedding Cdk in the DSPs. For instance, the deviation values in the cooperative game increase slightly from Experiment 1 to Experiment 3, from –0.0818 to –0.0807. This means that the target achievement is only slightly impaired because of the use of design capability indices. This is acceptable since satisfying ranged targets is the major concern, and the overlap between the range of performances and the range of target is more critical
22
than the deviation of performance itself. On the other hand, in trial and error, noncooperative and leader/follower games, using Cdk may even improve the target achievements of the solutions, as shown by the same or smaller deviations in Experiments 2 and 3 in Fig. 10. Therefore, when formulating compromise DSP using Cdk, the target achievement of the solution does not have to be sacrificed. Design capability indices facilitate obtaining superior point solutions as well as ranged ones.
Table 3 Design Capabilities with 1/10 Deviation Goals S (MPa) T (oC) Deviation S (MPa) T (oC) Deviation S (MPa) T (oC) Deviation
Trial/E Cooperative Non-coop Experiment 1: Without Using Cdk 0.6561 5.1123 0.6561 2.6492 0.4471 2.6492 0.1719 0.2765 0.1719 Experiment 2: Using only CdT 0.6561 5.0740 1.1757 2.6492 0.4745 2.7320 0.1719 0.2627 0 Experiment 3: Using CdS and CdT 1.1757 4.3320 1.1757 2.7320 1.0023 2.7320 0 0 0
L/F 0.6561 2.6492 0.1719 0.6561 2.6492 0.1719 1.1757 2.7320 0
In order to demonstrate that formulating DSPs using Cdk increases the design capabilities of the solutions, we calculate the Cdk values of the solutions as well as their deviation from the ranged design goal, Cdk = 1, Table 3. The Cdk values of the solutions are calculated as follows: CdS =
190 − S 70 − T , CdT = ∆S ∆T
(18)
S and T are the nominal value of the performances in Table 2. The deviations, ∆S and ∆T, are respectively calculated using Eq. (13) and (14), in which ∆C = 0.04mm and ∆D = 0.004mm. Solutions from Experiment 1 are specific values. To simulate the situation in which game players arbitrarily assign a deviation after solving the specific solutions, we calculate their Cdk by assigning
∆C and ∆D as 10% of their bounds.
23
Design Capabilty of Stress
6 5 4 3 2 1 0 Tria l/Erro r
Exp. 1(No Cdk) 6
C o o p.
No nco
Exp. 2 (CdT)
L/F
Exp. 3 (CdT, CdS)
Design Capability of Temperature
5 4 3 2 1 0 Tria l/Erro r
Exp. 1(Cdk)
C o o p.
No nc o
Exp. 2 (CdT)
L/F
Exp. 3 (CdT, CdS)
Fig. 11 Values of Design Capability
The Cdk values of stress and temperature in the three experiments are shown in Fig. 11. A larger Cdk value represents greater overlap between the ranged performance and design targets, and Cdk≥1 means the entire performance range satisfies the design target. In each game, from Experiments 1 to 3, the Cdk values of stress and temperature both increase, Fig. 11. In Experiment 1, we cannot ensure the performance ranges fall within the target range because ∆C and ∆D are assigned subsequently. For instance, in the leader/follower game of Experiment 1, the Cdk value of stress is 0.6561, meaning only a section of the ranged stress falls into the target range. In Experiment 3, the Cdk values of the performance are greater than 1, hence deviations from target value Cdk = 1 are 0 in all games and every point within the ranged solutions satisfies the design targets. Therefore design capability indices facilitate determining satisficing (not the best, but good enough [Simon 1996]) ranged solutions while obtaining superior point ones.
The robustness of the solutions is also increased if DSPs are formulated using Cdk. Using the cooperative game as an example, the solution for Experiment 1 has the lowest deviation, −0.0818. The nominal value of the ranged solution of Experiment 3 has a deviation value of –0.0807. In Fig. 12, the contour plot of T vs. C and D is shown. From the perspective of target achievement, both the solution of Experiment 1 and the nominal value of the solution of Experiment 3 achieve the 24
temperature target.
However, given deviation ∆C and ∆D, the shaded square represents the
resulting temperature range around the solution of Experiment 1, which exceeds the limit of 70oC; another square represents the temperature range around the nominal value of the solution of Experiment 3, still lying within the limit. Although the point solution in Experiment 1 is superior at target achievement, given the same deviations in the design variables, the ranged set of performance fails to remain so. Therefore, we conclude that the robustness of a solution cannot be ensured if DSPs are formulated without using design capability indices.
70.000 0.080
Experiment 3 C = 0.7568 D = 0.07
68.750
Die Attach (D)
0.075
67.500 0.070
66.250 0.065
Experiment 1 C = 0.7785 D = 0.07
65.000
0.060 .65
.70
.75 Chip (C)
.80
.85
Fig. 12 Robustness of Design Solutions
4.3 Efficacy of Using Design Capability Indices and Game Protocols In this section, we illustrate the combination of design capability indices and game protocols. The target achievements of the solutions are shown in Fig. 10. Regardless of whether Cdk is used to formulate the DSPs, the game protocol is still the main factor affecting the overall deviations. In Experiment 1, the specific solution of the cooperative game also has the best target achievement, – 0.0818; the solutions of noncooperative and leader/follower games are the same as those obtained using the trial and error approach, with a deviation of −0.0398.
Therefore when DSPs are
formulated without using Cdk, game protocols facilitate making satisficing decisions. In Experiment 2 in which a temperature DSP is formulated to make a ranged set of decisions, the cooperative game still achieves the most favorable solution with a deviation of –0.0818. 25
The solution of the
noncooperative game has a greater deviation value, −0.0507. The solutions for the trial and error approach and the leader/follower game have deviations of −0.0398. In Experiment 3, the target achievements of these solutions show a similar pattern. That is, a cooperative protocol always identifies the most favorable solution.
Leader/follower protocols identify acceptable solutions
compared to the traditional trial and error approach. Noncooperative protocols usually cannot guarantee satisficing solutions, but in this case, they work well. Therefore, regardless of whether the design capability indices are used to formulate DSPs game protocols help maintain satisficing target achievements.
The efficacy of design capability indices is illustrated from the solutions’ deviation values from the target, Cdk = 1; the larger the deviation, the smaller portion of the stress and temperature ranges achieve the design targets. For any game, e.g., the cooperative game, the deviation values decrease from Experiments 1 through 3, as shown in Table 3. From Experiments 1 and 2, the deviations change from 0.2765 to 0.2627. In Experiment 3, when both DSPs are formulated using Cdk, the deviation is reduced to 0, meaning that the entire ranged sets of S and T fall within the target ranges. Therefore, regardless of which game protocol is used, design capability indices help determine superior ranged solutions.
The combination of game protocols and design capability indices does not produce the expected results in every experiment. The exception is Experiment 2, in which leader/follower protocol obtains the same solution as the trial and error approach, and the noncooperative protocol identifies an even better one. However, the cooperative protocol fails to identify the most favorable solution as it does in the other two experiments. This is because in Experiment 2, the temperature DSP is formulated as a ranged set of decisions and stress DSP is formulated as a specific decision. Then when combining the two DSPs, mixing two types of design goals within one DSP (cooperative game) will yield a poor Cdk value because solution robustness is not considered when formulating the stress DSP.
On the other hand, the DSPs are solved separately in noncooperative and
leader/follower games. Although the design goals in the DSPs are formulated differently, the noncooperative and leader/follower protocols can still reach a solution to satisfy the unique design goal of each player. This demonstrates the fundamental difference between the single- and bi-level
26
decision making approach and the game based ones. The leader/follower protocol is an effective tool to facilitate game players making decisions collaboratively even if participating players formulate their DSPs in different ways. Therefore the methodology of combining design capability indices and game protocols is effective in facilitating game players making satisficing decisions, either from the perspective of target achievement or the ranged solutions. Moreover, game based approaches help increase the autonomy of the disciplinary teams’ decision making activity.
4.4 The Change in Design Freedom Since the Cdk value of a solution measures the overlap between performance range and the target range, in this section, we study the design freedom change in the product realization process. In Table 4, the solutions of a set of leader/follower games are shown, as well as the corresponding design freedom at each step of the games. Design freedom is calculated using Eq.(8).
It is interesting to study the initial design performance ranges, which in this case show the bounds of system performance.
At the beginning of the package design process, the bounds of design
variables are C∈[0.5, 0.9]mm and D∈[0.03, 0.07]mm. Accordingly the performance ranges are T∈[53.20, 75.78]oC and S∈[155.9, 265.6]MPa. The initial design freedom calculated using Eq. (8) is 0.5274, Table 4. That is, design freedom in this case never reaches the maximum value 1. This result is different from that shown in Fig. 1 because the couplings between the compromise DSPs decrease the achievable ranges of S and T, and therefore decrease the design freedom of the package design process.
When solving the package design problem using the traditional trial and error approach, design freedom decreases rapidly. If the trial and error procedure starts with the stress design team making a specific decision, e.g., D = 0.07mm, C is still a ranged value [0.5, 0.9]mm at this point in time. The system performances are S = 191.86±35.97MPa and T = 71.28±4.50oC. Design freedom of the package design process is then 0.2269. On the other hand, if the trial and error procedure begins with temperature design team making a specific decision, i.e. C = 0.64mm, the performances are S = 211.91±28.28MPa, T = 61.37±5.4oC, and the design freedom is 0.2682. Thus the stress design team controls more design freedom than the temperature design team. Should this be one of the criteria
27
for selecting the leader in leader/follower games? This is an interesting question for future research. Regardless of which team makes the first decision, the design freedom is 0 after the second step because another ranged design variable is then specified. The trial and error procedure must proceed although the collaborating teams do not have any freedom to adjust their solution.
Table 4 Goal Achievements and Design Freedom Trial &Error
Initial 0.70 ± 0.20 0.05 ± 0.02 210.75 ± 54.85 64.49 ± 11.29 0.5274 Step 1
Start from Stress Design 0.70 ± 0.20 0.07 191.86 ± 35.97 71.28 ± 4.50 0.2269 Step 2
Start from Temp. Design 0.64 0.05 ± 0.02 211.91 ± 28.28 61.37 ± 5.40 0.2682 Step 3
C (mm) D (mm) S (MPa) T (oC) Freedom Experiment 1 L/F (no Cdk) C (mm) D (mm) S (MPa) T (oC) Freedom Experiment 2 L/F (CdT) C (mm) D (mm) S (MPa) T (oC) Freedom Experiment 3 L/F (CdT,CdS) C (mm) D (mm) S (MPa) T (oC) Freedom
0.70 ± 0.20 0.07 191.86 ± 35.97 71.28 ± 4.51 0.2269 Step 1
0.64 0.07 183.63 66.77 0 Step 2
0.64 0.07 183.63 66.77 0 Step 3
0.70 ± 0.20 0.07 191.86 ± 35.97 71.28 ± 4.51 0.2269 Step 1
0.64 ± 0.04 0.07 184.43 ± 9.45 66.88 ± 0.11 0.0733 Step 2
0.64 ± 0.04 0.07 184.43 ± 9.45 66.88 ± 0.11 0.0733 Step 3
0.70 ± 0.20 0.068 ± 0.002 192.22 ± 36.33 70.66 ± 5.12 0.2524
0.66 ± 0.04 0.068 ± 0.002 180.42 ± 9.71 66.43 ± 0.89 0.1273
0.66 ± 0.04 0.068 ± 0.002 180.42 ± 9.71 66.43 ± 0.89 0.1273
Design freedom change in a game is depicted using the decision making activities to mark the design timeline. That is, the design freedom is calculated each time a decision is made. For instance, when solving a leader/follower game, the decision making process consists of three steps. In Step 1, the follower’s BRC is constructed by solving a set of follower’s DSPs. In Step 2, the leader makes decisions using this BRC in leader’s DSP. In Step 3, the follower resolves his/her
28
DSP based on the leader’s decision. In Experiment 1, BRCS is constructed at Step 1, which is D =f(C) =0.07. ∆D is calculated using Eq. (6).
∆D = (
dBRCS 2 2 ) ∆C , C ∈ [0.5, 0.9]mm dC
(19)
Only C varies within its bounds and the design freedom is 0.2269. It is worth noting that if BRCS is a function of C which it usually is, the design freedom at step 1 will be larger than in the trial and error case because ∆D is larger than 0. In Step 2, the leader (temperature player) solves the DSP using the BRCS and finds C = 0.64mm. The design freedom is 0. At Step 3, the specific design solution is obtained, C = 0.64mm and D = 0.07mm and the design freedom is still 0. If the DSPs are not formulated using design capability indices, the leader/follower protocol helps to maintain design freedom only within the game. Downstream engineering teams cannot enjoy any freedom to adjust the C and D values because the solution is specified.
Design Freedom
0.6
S[171,190]MPa T[65.5,67.3]oC
0.5
S[175,194]MPa T[66.8,67.0]oC
0.4 0.3
S=183.6 MPa T=66.8 oC
0.2 0.1
Time Line
0 0
1
T/E &L/F(No Cdk)
2
3
L/F (T-Cdk)
4
5
L/F (S, T- Cdk)
Fig. 13 Design Freedom Change
In Experiment 2, the temperature design DSP is formulated using Cdk. At Step 1, BRCS, D = f(C) = 0.07, is constructed, which is the same in Experiment 1. The design freedom is therefore also 0.2269, Table 4. In Step 2, the solution of temperature design DSP is a ranged value, C∈[0.6, 0.68]mm, and the design freedom calculated using Eq. (8) is 0.0733. Finally in Step 3, the follower (stress player) specifies D = 0.07mm, and the design freedom is 0.0733. After solving this package design game, following engineering teams can still adjust C within its range without jeopardizing the satisfaction of T ≤ 70oC. Since the solutions are C∈[0.6, 0.68]mm and D = 0.07mm, the final performances are bounded within S ∈ [175, 194]MPa and T∈ [66.77, 66.99]oC, Table 4. The target
29
S ≤ 190MPa may not be satisfied but T ≤ 70oC will be achieved. In Experiment 3, both C and D are ranged values and the design freedom is further increased, Table 4. The performance of the designed package is S∈[170, 190]MPa and T∈[66.5, 67.3]oC. The design freedom change of these games is shown in Fig. 13; the starting point of these curves is the initial freedom, 0.5274.
0.07
1
2 3
Die Attach (D) 0.05
0.06
Temp
S < 190MPa
T-R
Stress
0.04
R < 8 ×10−9
0.03
T < 70o C .50
.60
.70
.80
.90
Chip (C)
Fig. 14 Design Freedom Available to the Aging Analysis Team
Obviously, the design freedom maintained after the package design stage leaves a “space” for the following engineering teams to find superior results by determining the final values of C and D from the perspectives of other disciplines. In this scenario, an isothermal aging analysis team calculates the growth rate of grain boundary voids of interconnects in the chip using Eq. (10), as discussed in Section 3 and Equation 10, where R ≤ 8.0×10–9 is considered acceptable. If R > 8.0×10–9, the aging analysis team must request a redesign. The design space for this scenario is shown in Fig. 14, in which the curves represent the design targets, and arrows show the directions to achieve these targets. In Experiment 1, the specific solution consisting of C = 0.64mm, D = 0.07mm, and T = 66.8oC, etc., is as point 1 in the figure. From Eq. (10), the result of aging analysis is R = 8.19×10–9. It is shown in Fig. 14 that point 1 falls outside the space formed by these three curves. Since the aging analysis team has no freedom to change the value of C and D, the design result is unacceptable and redesign is required to reduce the temperature. The solution of Experiment 2 is 30
represented as line 2 because D is a ranged value. Obviously, redesign is necessary because line 2 also falls outside the “space of acceptable designs”. However in Experiment 3, the design solution consists of C∈[0.62, 0.70]mm, D∈[0.066, 0.070] mm, and T∈[65.5, 67.3]oC, etc. Aging analysis result of this solution yields R∈[7.57×10–9, 8.44×10–9], and R equals to 8.0×10–9 when temperature reaches 66.4oC. In Fig. 14, the solution of Experiment 3 is represented as square 3, part of which falls into the “acceptable space”. That is, the aging analysis team has the freedom to select any point in square 3 that not only achieves stress and temperature targets, but also satisfies the requirement that R ≤ 8.0×10–9, for example, C = 0.66mm and D = 0.07mm. Hence, maintaining design freedom helps reduce or even eliminate iterations in the product realization process. Isothermal aging analysis team can determine the ranged values of C and D which renders T∈ [65.5, 66.4]oC. Again this maintains design freedom for other downstream teams, such as the manufacturing team. Therefore, in this case the methodology of combining game protocols and design capability indices is effective at handling collaborative decision making while maintaining design freedom in the early stages of product realization process.
5. CLOSURE The complexity of modern product realization processes requires multidisciplinary collaboration. We use principles from game theory to model the relationships between engineering teams and facilitate collaborative decision making, and use design capability indices to help maintain design freedom. Based on our observations we summarize some of our findings vis a vis single and bilevel approaches and our game based approach:
Interdisciplinary iterations are eliminated, which can greatly reduce the computing cost in multidisciplinary product realization.
Since the system level team does not exist, in the noncooperative and leader/follower games, the amount of design variables or coupling variables is no longer a concern.
Since each team (player) holds its own cost function and makes decisions in its own discipline, the game based approach greatly increases the autonomy and independence of the disciplinary teams and enables higher parallelism. This satisfies the assumptions of the coordination techniques and enables their combination with decision making approaches. In addition, the game theoretical protocols are appropriate to model the relationships between engineering
31
teams, and enable collaborative decision making based on the cooperation styles between teams. This is our response to the first question raised in Section 1.1.
Most importantly, the method introduced in this paper can be applied to complex product realization problems. Upstream teams make decisions that remain superior even though the requirements of the downstream teams are yet unknown. Downstream teams can specify final solutions without jeopardizing the satisfaction of the design requirements in upstream activities. Hence, engineering teams can keep the product realization problem open in the early stages of product realization, and make decisions that are superior from the perspective of all disciplines. This is our response to the second question raised in Section 1.1.
The curve for the change in design freedom as presented in Fig. 1, is appropriate, except that the starting point should be determined by the initial feasible value of design freedom, which is less than 1, Fig. 13.
In closing, we note that compared to other approaches our method does not necessarily lead to a better design. We do suggest that our method is more practical in the design of complex engineered systems. Yet more remains to be done.
ACKNOWLEDGMENTS We gratefully acknowledge NSF grant DMI-0085136.
The cost of computer time has been
underwritten by the Systems Realization Laboratory at Georgia Tech.
REFERENCE Badhrinath, K. and Rao, J.R.J., (1996), “Modeling for concurrent design using game theory formulations,” Concurrent Engineering-Research and Applications, 4 (4): pp. 389-399. Balling, R. and Rawlings, M.R., (2000), “Collaborative optimization with disciplinary conceptual design,” Structural and Multidisciplinary Optimization, 20 (3): pp. 232-241. Balling, R.J. and SobieszczanskiSobieski, J., (1996), “Optimization of coupled systems: A critical overview of approaches,” AIAA Journal, 34 (1): pp. 6-17. Berkes, U.L., (1990), “Efficient Optimization of Aircraft Structures with a Large Number of Design Variables,” Journal of Aircraft, 27 (12): pp. 1073-1078. Braun, R.D., Moore, A.A., and Kroo, I.M., (1997), “Collaborative approach to launch vehicle design,” Journal of Spacecraft and Rockets, 34 (4): pp. 478-486. Burgee, S., Giunta, A.A., Balabanov, V., Grossman, B., Mason, W.H., Narducci, R., Haftka, R.T., and Watson, L.T., (1996), “A coarse-grained parallel variable-complexity multidisciplinary optimization paradigm,” International Journal of Supercomputer Applications and High Performance Computing, 10 (4): pp. 269-299. 32
Chen, L. and Li, S., (2002), “A computerized team approach for concurrent product and process design optimization,” Computer-Aided Design, 34 (1): pp. 57-69. Chen, W. and Lewis, K., (1999a), “A Robust Design Approach for Achieving Flexibility in Multidisciplinary Design,” AIAA Journal, 37 (8): pp. 982-989. Chen, W., Simpson, T.W., Allen, J.K., and Mistree, F., (1999b), “Satisfying Ranged Sets of Design Requirements Using Design Capability Indices as Metrics,” Engineering Optimization, 31: pp. 615-639. Dhingra, A.K. and Rao, S.S., (1995), “A Cooperative Fuzzy Game-Theoretic Approach to MultipleObjective Design Optimization,” European Journal of Operational Research, 83 (3): pp. 547567. Duffy, A.H.B., Andreasen, M.M., MacCallum, K.J., and Reijers, L.N., (1993), “Design coordination for concurrent engineering,” Journal of Engineering Design, 4: pp. 251-256. Gu, X.Y., Renaud, J.E., Ashe, L.M., Batill, S.M., Budhiraja, A.S., and Krajewski, L.J., (2002), “Decision-Based Collaborative Optimization,” Journal of Mechanical Design, 124 (1): pp. 1-13. Kalsi, M., Hacker, K., and Lewis, K., (2001), “A comprehensive robust design approach for decision trade-offs in complex systems design,” Journal of Mechanical Design, 123 (1): pp. 110. Kodiyalam, S. and Sobieszczanski-Sobieski, J., (2000), “Bilevel integrated system synthesis with response surfaces,” AIAA Journal, 38 (8): pp. 1479-1485. Kroo, I.M., Altus, S., Gage, P., Braun, R., and Sobieski, I., (1994), "Multidisciplinary Optimization Methods for Aircraft Preliminary Design," 5th AIAA/USAF/NASA/OAI Symposium on Multidisciplinary Analysis and Optimization, Panama City, FL. Paper Number: AIAA 94-4325. Lau, J.H., (1993), Thermal Stress and Strain in Microelectronics Packaging, Van Nostrand Reinhold, New York. Lewis, K. and Mistree, F., (1997), “Modeling Interactions in Multidisciplinary Design: A Game Theoretic Approach,” AIAA Journal, 35 (8): pp. 1387-1392. Lewis, K. and Mistree, F., (1998), “Collaborative, Sequential and Isolated Decisions in Design,” ASME Journal of Mechanical Engineering, 120 (4): pp. 643-652. Marston, M., (1997), Marston, “Game-Based Design: A Game Theory Based Approach to Engineering Design,” Ph.D. Dissertation, GWW School of Mechanical Engineering, Georgia Institute of Technology, Atlanta.
Mistree, F., Hughes, O.F., and Bras, B.A., (1993), "The Compromise Decision Support Problem and the Adaptive Linear Programming Algorithm," Structural Optimization: Status and Promise, AIAA, pp. 249-289, Washington, D. C. Mistree, F., Smith, W.F., Bras, B., Allen, J.K., and Muster, D., (1990), “Decision-Based Design: A Contemporary Paradigm for Ship Design,” Society of Naval Architects and Marine Engineers, 98: pp. 565-597. Rao, S.S., (1987), “Game-Theory Approach for Multiobjective Structural Optimization,” Computers & Structures, 25 (1): pp. 119-127. Rao, S.S., Venkayya, V.B., and Khot, N.S., (1988), “Game-Theory Approach for the Integrated Design of Structures and Controls,” AIAA Journal, 26 (4): pp. 463-469. Rosen, D., Chen, Y., Gerhard, J., Allen, J.K., and Mistree, F., (2000), "Design Decision Templates and Their Implementation for Distributed Design and Solid Freeform Fabrication," ASME Design Engineering Technical Conference, 20th Computers and Information in Engineering Conference, Baltimore, Maryland. Paper Number: DETC2000/DAC-14293. Simon, H.A., (1996), The Sciences of the Artificial, 3rd Edition, The MIT Press, Cambridge, MA.
33
Simpson, T.W., Rosen, D., Allen, J.K., and Mistree, F., (1998), “Metrics for Assessing Design Freedom and Information Certainty in the Early Stages of Design,” ASME Journal of Mechanical Design, 120 (4): pp. 628-635. Sobieski, I.P. and Kroo, I.M., (2000), “Collaborative optimization using response surface estimation,” AIAA Journal, 38 (10): pp. 1931-1938. Sobieszczanski-Sobieski, J., (1988), "Optimization by Decomposition: A Step from Hierarchic to Non-hierarchic Systems," Second NASA/Air Force Symposium on Recent Advances in Multidisciplinary Analysis and Optimization, Hampton, VA. Paper Number: NASA CP 3031. Sobieszczanski-Sobieski, J., Agte, J.S., and Sandusky, R.R., (2000), “Bilevel integrated system synthesis,” AIAA Journal, 38 (1): pp. 164-172. Sobieszczanski-Sobieski, J. and Haftka, R.T., (1997), “Multidisciplinary aerospace design optimization: survey of recent developments,” Structural Optimization, 14 (1): pp. 1-23. Wujek, B.A., Renaud, J.E., Batill, S.M., and Brockman, J.B., (1996), “Concurrent subspace optimization using design variable sharing in a distributed computing environment,” Concurrent Engineering-Research and Applications, 4 (4): pp. 361-377. Xiao, A. (2003). "Collaborative Multidisciplinary Decision Making in a Distributed Environment," Ph.D. Dissertation, The G.W. Woodruff School of Mechanical Engineering, Georgia Tech., Atlanta, GA. Xiao, A., Choi, H.J., Allen, J.K., Rosen, D., and Mistree, F., (2002), "Collaborative Decision Making Across Digital Interfaces," ASME Design Engineering Technical Conference, 28th Advances in Design Automation, Montreal, Canada. Paper Number: DETC2002/DAC-34073.
34
