2.1. Our fundamental decision model

In order to achieve rationality and obtain quality designs in decision making, decisions needs to be rigorously formulated. In this paper we adopt the DSP technique (Muster & Mistree, Reference Muster and Mistree1988) as the formalism to formulate decisions encountered in engineering design. The DSP technique seeks the bounded rationality and “satisficing” (good enough; Simon, Reference Simon1976) solutions. In the DSP technique, two types of DSPs are identified: selection and compromise DSPs. Selection DSP deals with making a choice among a number of possibilities taking into account a number of measures of merit or attributes (Fernandez et al., Reference Fernandez, Seepersad, Rosen, Allen and Mistree2005). cDSP deals with the determination of the “right” values (or combination) of design variables to describe the best satisficing system design with respect to constraints and multiple goals (Mistree et al., Reference Mistree, Hughes, Bras and Kamat1993). The cDSP has been adopted for solving many system design problems such as ships (Mistree et al., Reference Mistree, Smith, Bras, Allen and Muster1990), aircraft (Lewis & Mistree, Reference Lewis and Mistree1995), materials (Seepersad et al., Reference Seepersad, Allen, McDowell and Mistree2008), and so on. In this paper, we use the cDSP as our fundamental decision model for making decisions among multiple conflicting goals considering constraints.

The mathematical formulation of the cDSP is shown in Figure 1a. The system descriptors, namely, design and deviation variables, system constraints, system goals, bounds, and the deviation function, are described in detail in Mistree et al. (Reference Mistree, Hughes, Bras and Kamat1993) and are therefore not repeated here. A two-dimensional problem shown in Figure 1b is used as an example to illustrate the features of the cDSP solution space. In the design space defined by variables (x ₁ and x ₂), feasible designs are confined in the feasible design space bounded by linear (C ₁ and C ₂), nonlinear (C ₃) constraints, and the bounds ( $x_1^{{\rm lower}} $ , etc.) on variables. Designers’ task is to explore the feasible design space and find those designs that satisfy the multiple goals (G ₁ − G ₄) as much as possible, that is, to minimize the deviation (e.g., $d_1^ + $ , $d_1^ - $ referring to the over- and underdeviation of the goal G ₁) of the goals. In practical engineering design, the goals are usually conflicting (e.g., minimizing the weight and maximizing the volume of a container), which leads to the formation of the aspiration space (see the inner area framed by G ₁ − G ₄ where $d_1^ + $ , $\; d_2^ - $ , $\; d_3^ - $ , and $d_4^ - $ are preferred). When there is no overlap between the aspiration space and the feasible design space, designers need to compromise, that is, to find the shortest distance (represented by the deviation function Z) between the two spaces. The adaptive linear programing algorithm (Mistree et al., Reference Mistree, Hughes, Bras and Kamat1993), which has been implemented in the decision software DSIDES (Reddy et al., Reference Reddy, Smith, Mistree, Bras, Chen, Malhotra, Badhrinath, Lautenschlager, Pakala and Vadde1996), is used to solve cDSPs.

Fig. 1.

Mathematical form and a two-dimensional illustration of a compromise decision support problem.

2.2. Decision template

Design reuse, aiming at maximizing customer satisfaction with minimal resources and cost and with minimal effort by the reuse of successful past designs, in part and in whole (Sivaloganathan & Shahin, Reference Sivaloganathan and Shahin1999), has been well adopted in industry. Examples can be found in many product architectures where the modular, standardized components are designed once and reused in assemblies across products. Analogously to product architectures, Panchal et al. (Reference Panchal, Fernández, Paredis and Mistree2004) extend the reusability to the design process by proposing the concept of a modular, executable decision template from a decision-centric perspective. The key idea is that in a computational environment, design processes are composed by a series of templates representing decisions that can be instantiated with product-specific information and executed. Due to the modularity, these templates can be easily reused in similar product designs or product redesigns. The template is modeled based on the cDSP construct and analogous to the architecture of a printed wiring board with a number of electronic components, as shown in Figure 2. The key feature is the separation of “declarative” and “procedural” information: the former stands for the elements of the cDSP, such as variables, parameters, and constraints, and is represented by “chips” in the figure; the latter stands for the algorithm that solves the cDSP and is represented by the “wiring” and the “board.” The reusability of the template extends to both the “declarative” and the “procedural” information.

Fig. 2.

Compromise decision support problem template (Panchal et al., Reference Panchal, Fernández, Paredis and Mistree2004).

Although the implementation by Panchal et al. (Reference Panchal, Fernández, Paredis and Mistree2004) enables greater reusability of information across design problems, the use of the extensible markup language (XML) as its underlying representation scheme limits the application of the cDSP template maintaining consistency. In many redesign cases, partial modification of the design model (cDSP template) is needed to reflect the evolution in the design consideration, which often leads to inconsistency in the modified model. These inconsistencies are even severe when the model is highly complex (e.g., tens of variables, constraints or goals) and the model modifier is not the original creator who has the full knowledge about the model. XML fails to avoid inconsistency because of the loose definition of items of the template and the lack of reasoning mechanism to support consistency checking; thus, XML is not suitable for representing the highly constrained cDSP model. In this paper, we adopt the idea of modeling cDSPs as executable template, rerepresent the templates using ontology, and demonstrate its consistency maintaining ability when the templates are modified.

2.3. Ontology

Ontology, known as explicit specification of a conceptualization, has many obvious advantages such as sharing information, integrating different applications, implementing interoperability, and reusing knowledge (Yang et al., Reference Yang, Dong and Miao2008). Although the research on ontologies has its root in computer science, ontologies have been widely used for information modeling in engineering. Lee et al. (Reference Lee, Fenves, Bock, Suh, Rachuri, Fiorentini and Sriram2012) proposed an ontology-based multilevel product-modeling framework, which is based on the Core Product Model 2 (Fenves et al., Reference Fenves, Foufou, Bock and Sriram2008) proposed by the National Institute of Standards and Technology (NIST), to address the requirement of semantic richness from different stakeholders across the product lifecycle. Lu et al. (Reference Lu, Qin, Liu, Huang, Zhou and Jiang2015) used ontology for capturing geometric constraint specifications to facilitate data exchange between different product development systems. Barbu et al. (Reference Barbau, Krima, Rachuri, Narayanan, Fiorentini, Foufou and Sriram2012) created OntoSTEP based on an ontology that can transform digital models with geometric information into semantically rich models that include function and behavior to facilitate manufacturing. Many other ontologies have been created by researchers and engineers based on their domain of interest. To systematically evaluate these ontologies, Chandrasegaran et al. (Reference Chandrasegaran, Ramani, Sriram, Horvath, Bernard, Harik and Gao2013) recommended the establishment of a Global Center for Engineering Ontologies, similar to the National Center for Biomedical Ontologies (http://www.bioontology.org/) in the United States.

A foreseeable consequence of the creating of these ontologies is that a huge amount of product- or problem-specific, semantically rich information will be populated as instances and accumulated in the associated knowledge bases. From the perspective of design guidance, the primary requirement is the availability of critical information when it is needed. This need motivates a group of researchers to work on ontology-based knowledge archival (Witherell et al., Reference Witherell, Krishnamurty and Grosse2007) and retrieval (Li et al., Reference Li, Raskin and Ramani2008; Liu et al., Reference Liu, Lim and Lee2013), as mentioned in Section 1. However, from the decision support point of view, the retrieved information still cannot be effectively and efficiently reused for quality decision making because there is a lack of decision-making mechanism (construct) to utilize the information and generate a solution. In this paper, we create an ontology based on the cDSP construct and archive the information for decision making as templates that are executable and reusable. In terms of the ontology formalism, two popular paradigms exist: Web Ontology Language and Frame (Wang et al., Reference Wang, Noy, Rector, Musen, Redmond, Rubin, Tu, Tudorache, Drummond and Horridge2006). We choose the Frame paradigm here because it is based on a closed-world assumption where everything is prohibited until it is permitted, which is suitable for modeling the highly constrained cDSP (Ming et al., Reference Ming, Yan, Wang, Panchal, Goh, Allen and Mistree2015). In the following section, the development of the frame-based ontology for decisions is presented.

3.1. Concept identification

Concepts of a domain are often described by a vocabulary of terms. Panchal et al. (Reference Panchal, Fernández, Paredis and Mistree2004) have identified a set of terms for modeling the cDSP template, which include Constraint, Goal, Parameter, Variable, Preference, Analysis, Driver, and Response. These terms are adopted and reused here by explicitly defining them as classes. Six additional classes, referred as Problem, cDSPTemplate, Behavior, History, Function, and Quantity, are introduced to capture the information that adds to the semantic richness and integrity of the ontology. The definitions of the classes are shown in Table 1.

Table 1.

Classes of the cDSP template ontology

^aSee the information captured by ternary plot and scatterplot in Section 5.

3.2. Relation definition

The semantical relations among concepts are captured using slots in an ontology. Generally, there are two types of slots: data slots and object slots. Data slots are used to link concepts to nonobject data of which the types include String, Float, Integer, Symbol, and so on. For example, concept Goal may need a data slot to link itself to a target value with the type of Float. Objects slots are used to link concepts to object data of which the type is restricted to Class instance. For example, concept Function may need an object slot to link itself to a list of Variable instances. Based on the mathematical formulation of cDSP shown in Figure 1, the data slots and object slots of the cDSP ontology are defined as shown in Table 2 and Table 3, respectively.

Table 2.

Data slots of the cDSP template ontology

Table 3.

Object slots of the cDSP template ontology

3.3. Maintaining consistency

It is of critical importance for an ontology to restrict the populated instance in the manner as they are defined to be, that is, to keep consistency. As mentioned in Section 2.2, inconsistency is prone to occur when design consideration evolves, and the original cDSP template needs to be modified; for example, some parameters, goals, or constraints are added or removed (which is introduced in Section 4). Thus, detecting the inconsistency and informing designers to fix the inconsistency is very important. Rule-based reasoning is the method used for consistency checking in ontologies. In this paper, the rules for maintaining consistency in the cDSP template ontology are identified as shown in Table 4. Java Expert System Shell (Jess; Sandia National Laboratories, n.d.), a rule engine for the Java platform, is adopted as the reasoner. In order to be compatible with Jess, the rules are defined as the following (taking Rule 6 as an example):

$$\eqalign{&(defrule MAIN::rule\_6 \cr &\quad \times (object (is - a cDSPTemplate ) (OBJECT ?y ) ) \cr &\quad = \gt (foreach ?x (slot - get ?y hasParameter ) \cr &\quad \times (if (neq (slot - get ?x lowerBound ) \cr &\quad \times (slot - get ?x upperBound)) then \cr &\quad \times (printout t WARNING\_6 crlf))))}$$

Table 4.

Consistency rules of the cDSP template ontology

It means that if any instance in the slot “hasParameter” has unequal values in terms of lower bound and upper bound, the reasoner will send a message about the inconsistency to the designer who is working on that cDSP template.

3.4. The complete structure of the ontology

The complete structure of the cDSP template ontology is shown in Figure 3. It is a network structure in which the gray nodes represent the classes and the black nodes represent the data. Different classes are linked by object slots that are represented by the dashed-line arrows, and the classes are linked to real data by data slots, which are solid-line arrows. Hierarchical relations (e.g., the relation between classes Constraint and Function) among concepts are represented by arc arrows. The ontology modeling process is facilitated using the Protégé tool, developed by Stanford University (2013), which provides an environment for creating and editing ontologies as well as populating instances based on ontologies. The interface of Protégé and a cDSP template instance example are shown in a later section. Protégé also enables the development of plugins as extensions to the function of ontology. JessTab (Eriksson, Reference Eriksson2008) is a plugin that attaches Jess to Protégé and is used for consistency checking in this paper. To facilitate the execution of the populated cDSP template instances, we also developed a plugin that link DSIDES to Protégé using Java function call for generating design solutions, which is not the main focus of this paper and thus not described in detail here.

Fig. 3.

Overview of the complete structure for the compromise decision support problem template ontology.

5.1. Populating an original design instance

The pressure vessel design variables are the radius R, the length L, and the thickness T , as shown in Figure 5. It is to withstand a specified internal pressure P, and the material is also specified. There are two objectives: to minimize the weight and to maximize the volume of the cylinder, both subject to stress and geometry constraints. The nomenclature for is example is presented in Table 5. The cDSP formulation is shown below:

1. 1. Given

2. 2. • Weight: $W\lpar {R{\rm,} T{\rm,} L} \rpar = {\rm \rho} \left[ \displaystyle{4 \over 3}{\rm \pi} \lpar {R + T} \rpar^3 + {\rm \pi} \lpar {R + T} \rpar^2 L \right.$

   $\left.- \left( \displaystyle{4 \over 3}{\rm \pi} R^3 + {\rm \pi} R^2 L \right) \right]$

3. 3. • Volume: $V\lpar {R{\rm\comma} \,L} \rpar = \displaystyle{4 \over 3}{\rm \pi} R^3 + {\rm \pi} R^2 L$

4. 4. Find

5. 5. • System variables: thickness T, radius, R, and length, L

6. 6. • Overachievement deviation variable associated with weight goal, $d_{\rm w} ^ + $

7. 7. • Underachievement deviation variable associated with volume goal, $d_{\rm v} ^ - $

8. 8. Satisfy

9. 9. • Stress constraint: $c_1 :{\rm \sigma} _{{\rm circ}} = \displaystyle{{\hbox{PR}} \over T} \le S_{\rm t} $

10. 10. • Geometric constraints: c ₂ : 5T − R ≤ 0

11. 11.

    $$c_3:R + T - 40 \le 0$

12. 12.

    $$c_4 :L + 2R + 2T - 150 \le 0$

13. 13. • Bounds: T _l  ≤ T ≤ T _u

14. 14. R _l ≤ R ≤ R _u

15. 15.

    $$L_{\rm l} \le L \le L_{\rm u} $

16. 16. • Weight goal: $\; W - d_{\rm w} ^ + = W_{{\rm TV}} $

17. 17. • Volume goal: $\; V + d_{\rm v} ^ - = V_{{\rm TV}} $

18. 18. Minimize

19. 19. $W_{{\rm VOL}} d_{\rm v} ^ - + W_{{\rm WGT}} d_{\rm w} ^ + $

The specific input data for this problem is given in Table 6. Based on all the prepared information, a cDSP template instance for the design of the pressure vessel is instantiated in Protégé as shown in Figure 6. In Figure 6, the panel on the left-hand side is the class browser with all the classes listed, the panel in the middle is the instance browser listing all the instances associated with a selected class, and the panel on the right-hand side is the instance editor where a specific instance can be created and edited. In this case, all the slots (including data and object slots, e.g., “name,” “hasParameter,” “hasVariable”) of the pressure vessel instance are created according to the structure defined in Section 4 and the data of the problem itself. When the instance is correctly created, the result is calculated using JAVA function calls that communicate with the problem solver DSIDES. The result is (R, T, L) = (36, 4, 70), (Weight, Volume) = (39457 lb., 480385 in.³) as shown in the front window in Figure 6.

Fig. 5.

Thin-walled pressure vessel with hemispherical ends.

Fig. 6.

Screenshot of the pressure vessel design compromise decision support problem template instance in Protégé ontology editor.

Table 5.

Nomenclature for the pressure vessel example

Table 6.

Pressure vessel input

5.2. Facilitating decision making in redesign scenarios

5.2.1. Consistency checking

In this scenario, the original design variable R is assumed to be fixed to 20 in. due to manufacturing limitations, and thus modifications are required from the existing design to reflect the revised condition. The problem is closely related to the suitable choice of L and  ; it transforms from a three-dimensional (L − R − T) problem to a two-dimensional (L − T) problem as shown in Figure 7. In Figure 7, the previous feasible set is a solid vertical box in the positive orthant. One end of this vertical box is the polygon AJIH in the L = 0 plane, and the other end is formed by the inclined plane passing through the points marked EFG. When the new limitation is introduced, the previous feasible solution space is sliced by a plane vertical to the R axis at R = 20, and the cross section marked DBCK forms the new feasible solution space. Facing the problem, designers need to properly adjust the original decision model to make a new decision. It is easy to recognize that the adjustment maps to modification Type I described in Section 4. In the ontology context, this adjustment is facilitated by a consistency mechanism shown in Figure 8. Specific steps of the process are as follows:

1. 1. Convert a variable to a parameter: Move the previous variable “vessel radius” from the slot “hasVariable” to slot “hasParameter.”

2. 2. Check consistency: Check the consistency of the modified cDSP template instance using the JESS rule engine. A message pops up showing “Rule 6 is violated!—Parameter ‘vessel radius’ has unequal lower and upper bounds!”

3. 3. Reconfigure the parameter: Reconfigure the parameter instance “vessel radius” as lower bound = value = upper bound = 20 in.

4. 4. Obtain the result: Problem solver DSIDES will calculate and return the result according to the newly specified cDSP template configuration. The result is (T, L) = (0.5, 53.9), (Weight, Volume) = (1698.7 lb., 101191.7 in.³), which will be documented as a new instance.

Fig. 7.

Design space dimension change.

Fig. 8.

Decision model adjustment facilitated by consistency checking.

5.2.2. Trade-off analysis

In this scenario, a new goal aimed at minimizing the cost is assumed to be considered in the design of the pressure vessel. The cost equation is derived from Sandgren (Reference Sandgren1990) as C(R, L, T) = 0.6224RTL + 1.7881R²T + 3.1611T²L + 19.8621RT², and the target cost is set to $0.1. In the new problem adjustment needs to be made to the original decision model in in terms of adding a new goal and modifying the value assigned to the weights of the goals, which is the combination of modification Type II and III. We assume that this adjustment is well facilitated by the consistency-checking mechanism discussed in the previous section and focus on how trade-off analysis is facilitated under the ontological context in this section. Here trade-off analysis means analyzing the effects of different distribution of goal priorities on the actual performance of goals, which helps designers understand about the rationality of their decisions. A ternary plot (see Kulkarni et al., Reference Kulkarni, Gautham, Zagade, Panchal, Allen and Mistree2015; Shukla et al., Reference Shukla, Kulkarni, Gautham, Singh, Mistree, Allen and Panchal2015) has been used as a trade-off analysis tool for the three-goal cDSPs. The key idea is that the sample of the weighted value sets for the goals is generated, then based on the value sets the performance (represented as normalized deviation) of each goal is calculated, and finally, the relationship between the performance and the value sets is shown using a triangle with a color-bar as shown in Figure 9. The scales on the edges refer to the weights assigned to goals, the points within the triangle stand for different sets of weights [e.g., point S stands for set (0.2, 0.4, 0.4)], the color denotes the deviation of the associated points, and the corresponding values are indicated by the color bar. To perform trade-off analysis, designers need to prepare a large enough number of sample sets and run computing codes in DSIDES using each of the sample sets to generate the result, and then all the sample sets and the associated results are input to MATLAB to generate a ternary plot. This is usually a time-consuming process and calls for automation- or platform-related support in order to improve the efficiency.

Fig. 9.

Ternary plot for trade-off analysis.

In the ontology framework, the trade-off analysis includes three procedures: sample generation, communication to DSDIES for computing, and ternary plot generation. These three procedurals are all supported by Java function calls provided by Protégé. Sample generation plays a critical role for generating quality ternary plots. In the ontology, the sampling procedural is controlled by the data slot “numberOfSamples” (see Table 2), which defines the number of scales for the weight of each goal. At the computational level, it is implemented by a Java function that combines the scales to weight sets under the rule that the sum of scales in each set is 1, as shown in Figure 10a. The columns refer to goals, the numbers attached to the points in each column refer to scales of weights, and the colored lines that link the points stand for the weight sets. Here the slot “numberOfSamples” is set to three, and six sample sets are generated (“numberOfSamples” can be set to a larger number to generate more sets). Each sample set in Figure 10 is automatically sent to DSIDES to compute a result. Based on the sample sets and results, the ternary plot for the new goal “cost” is automatically generated and captured by the object slot “hasBehavior,” as shown in Figure 10b. The blue area of the ternary plot in the figure means the preferred weight sets for minimizing the “cost” goal. Plots for the other two goals (the “weight” goal and the “volume” goal) are also captured for designers’ reference.

Fig. 10.

Trade-off analysis in the ontology.

5.2.3. Design space visualization

The assumptions used in the previous section are followed in this section to illustrate design space visualization. In the previous section, the ternary plot offers designers a means to analyze the trade-off among different goals by showing the relationship between the weight sets and the deviation of the goals. Trade-off analysis can lead designers to rational decisions, but the resulting designs may not necessarily be acceptable. For example, set point (W _VOL = 0, W _WGT = 0, W _COS = 1), which refers to preference for “cost” goal only, is located in the blue area in the ternary plot for the “cost” goal. Designers may choose it as the priority set for making the decision. However, the corresponding design $\lpar {R = 2.5,\; T = 0.5,\; L = 0.16} \rpar $ may be unacceptable due to the small size and the obviously small volume. Therefore, informing designers about associated designs under certain priority sets is also very important for facilitating decision making. We implement this using scatterplots as shown in Figure 11. The three axes correspond to the three variables of the problem, points refer to sample design specifications generated in the feasible design space, and the color of a point denotes the deviation of the objective function (see Fig. 1) for the associated design. Points in blue mean lower deviation, and therefore are the superior designs desired by designers. By the plot, designers can have an intuitive view of the “outline” of superior designs based on where the blue points locate. For example, in Figure 11, superior designs under set point $\lpar {W_{\rm VOL} = 0.33,W_{\rm WGT} = 0.33,W_{\rm COS} = 0.33} \rpar $ , which is an acceptable set in the ternary plot, are locating where the associated size seems large and more acceptable. Based on visualization of the design space, designers will have more confidence in the decisions they make.

Fig. 11.

Scatterplot.

In the ontology context, design space visualization is implemented through Java function calls provided by Protégé. The function collects information in slots “hasVariable,” “hasParameter,” “hasConstraints,” “hasGoals,” and “hasPreference,” and generates a scatter plot using samples in the feasible design space. The plot is finally captured as a behavior in the slot “hasBehavior” of a cDSP template instance for designers’ reference, as the plot under priority set (0,0,1) shown in Figure 12. Plots under other priority sets such as (1,0,0), (0,1,0), and (.33,.33,.33) are also captured by the slot “hasBehavior,” which are not shown in this paper.

Fig. 12.

Design space visualization in the ontology.

5.3. Summary and discussion

Using the thin-walled pressure vessel example, we instantiated a cDSP template instance using the original design decision information, modified the number of design variables based on existing template instance for making new decisions, modified the number of goals and the value assigned to parameters (weights to goals) for making new decisions, performed trade-off analysis to facilitate decision making, and performed design space visualization to facilitate decision making. The reusability of the ontology-based cDSP template is verified by the reuse and modification of previously created instance, and the executability is verified by consistency checking, automatic generation of results, performing trade-off analysis, and design space visualization. From the results, we see that designers’ decision making is facilitated in terms of

• • editing the decision model (cDSP template instance) with consistency ensured,

• • making rapid decisions with the help of automatic execution, and

• • making rational decision supported by insightful information displaying (ternary and scatterplots).