Engineering design is increasingly recognized as a decision making process. Providing decision support is crucial to augment designers' decision-making capability in this process. In this paper, we present a template-based ontological method that integrates the decision-making mechanism with problem-specific information; thus, it can provide design decision support from both the “construct” and the “information” perspectives. The “construct,” namely, decision-making mechanism, is the utility-based Decision Support Problem (u-sDSP), which is a rigorous mathematical model that facilitates designers making multi-attribute selection decisions under uncertainty, while the information for decision making is archived as u-sDSP templates and represented using frame-based ontology to facilitate reuse, execution, and consistency-maintaining. This paper is an extension of our earlier work on the ontological modeling of the compromise decisions. The unique advantage of this ontology is that it captures both the declarative and procedural knowledge of selection decisions and represents them separately, thus facilitating designers reusing, executing previous documented decision knowledge to effect new decisions. The efficacy of ontology is demonstrated using a rapid prototyping (RP) resource selection example.
Frame of Reference
Engineering design is increasingly recognized as a decision making process [1–4]. The principal role of a designer, as pointed out by Mistree et al. [3], is to make decisions. The complexity of the product itself and many design-related issues such as user preference [5,6], uncertainty [5,7], distributed design [8,9], etc. make the decision making process very complex and difficult to handle. In such situations, the ability of a designer to make rationale decision is critical for the generation of quality designs, while this ability may be limited due to facts such as the availability of information, the ill structure of the problem, and the knowledge and experience of a designer, etc. It is necessary to provide appropriate decision support in the light of the limitation.
In engineering design, decision support can be contributed from two perspectives: the “construct” and “information” perspectives. The former emphasizes providing analytical methods in which decisions are mathematically formulated and rationally made given certain inputs. Typical types of decision formulation include the utility-based decision making [1,4], which is based on objective rationality and seeks the best solution, and decision support problem (DSP) Technique [3,10], which is based on bounded rationality and seeks the “satisficing” (good enough) solutions. Based on these two types of decision formulations, researchers have developed a variety of approaches to deal with the aforementioned issues (preference, uncertainty, distributed design, etc.) and strengthen human designers' decision-making ability. It should be noted that most of these decision-making approaches rely on sufficient information as inputs, such as alternatives, attributes, constraints, etc., which inevitably necessitates decision support from the latter perspective, namely, the “information” perspective. In many cases, much of the information needed in current decision making can be found from previous decisions, especially in those redesign (adaptive or variant) cases [11]. Therefore, effectively organizing and reusing previous design decision knowledge is very important. Ontologies—explicit formal specifications of terms and relations among them [12]—are increasingly used for knowledge management in engineering design. In recent years, many ontologies have been created for storing, retrieval, and sharing engineering knowledge in design [13–17]. These ontology-based methods do provide some degree of information-related support in decision making; however, the retrieved or instantiated information of the ontology is not computationally formulated and thus is usually used as references which cannot be directly used to execute and generate a solution. There is a need for an ontology that captures information for decision making at the computational level that can be executed rapidly and facilitates designers efficiently reusing previous knowledge in decision making.
To address the need, we are developing a knowledge-based platform for decision support in the design of engineering systems (PDSIDES) [18]. This platform is supported by ontologies that incorporate both “constructs” and “information” for providing decision support. The “constructs” used in the platform include two mathematical decision models (identified according to the assertion that in engineering design there are only two primary types of decisions: compromise and selection [19]), namely, the compromise decision support problem (cDSP), and the selection decision support problem (sDSP), specifically the utility-based sDSP which will be discussed in Sec. 2.1. The “information” is categorized into two types, namely, procedural and declarative information. The former is the meta-information representing how the information is processed to reach out to the decision, while the latter is the domain-specific information that varies across problems. In our earlier work [18,20], an ontology for the cDSP has been developed and its usefulness has been demonstrated. In this paper, we extend the idea to the development of the sDSP ontology. The remainder of this paper is organized as follows. First, the foundations of this paper are discussed in Sec. 2. Then in Sec. 3, we propose a method for computationally modeling the selection DSP, which includes the template-based scheme of the u-sDSP construct and the definition of four automatic procedures. In Sec. 4, we describe the ontology that represents the underlying knowledge related to the utility-based sDSP template. This includes the definition of the classes, slots, and consistency rules. In Sec. 5, we illustrate the efficacy of what we propose using an example associated with rapid prototyping and we end with some closing remarks in Sec. 6.
Foundations
In this section, foundations of this paper are presented, which include (a) the utility-based sDSP used as the “construct” for decision support and (b) an ontology that serves as the representation scheme for organizing the information of the “construct.”
Our Decision Model: The Utility-Based Selection DSP.
Selection is endemic all along a design time-line. For example, the concept for further improvement is selected at the end of the conceptual design stage and the material or process for manufacturing (or prototyping) is selected at the detailed design stage, etc. In specific selection scenarios, designers often face decisions about selecting one among a set of feasible alternatives characterized by multiple conflicting attributes. The challenge in making such decisions is attributed to several factors including: (1) numerous choices, (2) design alternative complexity due to the number of attributes required to adequately characterize them, (3) measurement of attributes of different scales, (4) uncertainty with respect to attribute values, and (5) attribute trade-offs. To address the challenge, providing decision support is of critical importance. The utility-based selection DSP (u-sDSP) proposed by Fernandez and coauthors [5] is a construct for supporting multi-attribute selection decisions under uncertainty, and is used as our fundamental decision model in this paper. The u-sDSP construct is an augmented version of the selection DSP (sDSP) [21], which combines the strength of von Neumann and Morgenstern's utility theory [22] in offering mathematical rigor of decision making, and the strength of sDSP [21,23] in providing the context and structure for formulating and bounding design decisions. The utility theory in the u-sDSP overcomes the shortcomings of many multicriterion decision-making approaches (i.e., Pugh method [24], Analytic Hierarchy Process [25], etc.) in generating misleading or inconsistent results because of the lack of a theoretical foundation [26], and the sDSP construct enhances the capability of utility theory in solving practical engineering problems by providing context. Therefore, it is an effective tool for providing decision support, to a human designer, in the world of practice.
The word formulation of the u-sDSP is shown in Fig. 1. Steps for formulating and solving the u-sDSP are summarized in Fig. 2. For detailed instantiation of the steps, see Ref. [5]. As shown in Figs. 2 and 3, much knowledge regarding the selection of decision process is embodied in the key words (Given, Identify, Assess, Evaluate, Rank) of the word formulation and the steps for effecting a solution. The knowledge includes declarative knowledge such as “alternative” and “attributes,” etc., and procedural knowledge such as “assess” and “evaluate,” etc., both of which will be captured and represented in this paper.
Ontology-Based Knowledge Modeling.
Ontology is a knowledge modeling scheme that provides a common vocabulary for representation of domain knowledge. The two key elements of an ontology are concepts and relationship. Concepts stand for the abstractive components of a domain and are typically represented by classes. While relationship is the linkage between different concepts (or between concepts and end data) and is typically represented by properties or slots of the classes. Based on the abstractive structure of an ontology, infinite Instances can be populated using specific information. Due to the explicit specification of a conceptualization, ontology has many obvious advantages such as sharing information, integrating different applications, implementing interoperability, and reuse knowledge [27].
Although the research on ontology has its root in computer science, it has been often used for knowledge (or information) modeling in the engineering domain. Applications are typically categorized as follows: (1) Knowledge sharing. Ontology is used for sharing and communicating information among different applications since it has the capability to represent common understanding of a domain. For example, Lu et al. [28] use ontology for capturing geometric constraint specifications to facilitate data exchange between different product development systems, Barbu et al. [29] describe “OntoSTEP”—an ontology for transforming digital models with geometric information into semantically rich models that include function and behavior to facilitate manufacturing. (2) Knowledge retrieval. Ontology is used to build the reference network for retrieval since it has the capability to represent complex relations among concepts. For example, as mentioned in Sec. 1, Li et al. [13] and Liu et al. [14] develop ontologies to facilitate designers retrieving the product information during the design process. Li and coauthors [30,31] describe an ontology-based system that supports designers querying design rationale using natural language. (3) Knowledge documentation and reuse. Ontology is used to capture and document specific engineering information since it provides an Instance generation (documentation) mechanism. For example, Witherell et al. [17] develop an ontology for documenting engineering design optimization knowledge, Rockwell et al. [32] describe an ontology for archiving design rationale, Chang et al. [33] introduce a ontology that captures the knowledge in design for manufacturing.
In this paper, we focus on the third aspect, namely, exploring ontology's capability in documenting and reuse of the knowledge embedded in selection decisions. We recognize that there exists an ontology (see Ref. [32]) for documenting selection decisions. However, the focus of that work is on the archival of design rationale that helps designers understand previous designs. The knowledge captured cannot be rapidly reused to effect new designs since the computational procedures for decision making are not captured. The ontology proposed in this paper addresses this limitation by documenting the selection process at a computational level that enables the execution of the populated selection decision Instances. This is described in the context of the u-sDSP construct in Sec. 3.
Modeling the Selection Decision Making Process
As previously discussed, the reusability and executability of the documented decision Instances are of critical value for decision support in the computational environment. In this section, we discuss how these two capabilities are achieved through modeling the selection decision making process, and this model is used as the basis for the development of the ontology.
Reusability—Modular Decision Template.
Design knowledge is reused in order to maximize customer satisfaction with minimal resources and cost and with minimal effort by the reuse of successful past designs, in part or in whole [34]. There are many examples of design reuse in product architectures where modular, standardized components are designed once and reused in assemblies across products. Analogously to product architectures, Panchal et al. [35] extend the reusability to the decision-centric design process (specifically the compromise decision making process) by proposing the concept of modular decision templates. The concept is adopted here to model the selection decision making process using the u-sDSP construct, as shown in Fig. 3. The modeling strategy is analogous to the architecture of a printed wiring board with a number of electronic components. The key feature is the separation of declarative and procedural knowledge: the former stands for the elements (modules) of the u-sDSP such as alternative, attributes, etc., and is represented by “chips” in the figure; the latter stands for problem-solving procedures and is represented by the “breadboard.”
By separation of the above two types of knowledge, the reusability of the selection decision making process is achieved in three ways: (1) reuse of the “breadboard.” The standard selection procedure corresponding to the “breadboard” is reused in the instantiation of any problem by populating specific information on the board; (2) reuse of the “chips.” Specific information (e.g., an attribute) corresponding to the “chips” is reused in a different decision instantiation; (3) reuse of the assembly. The assembly that combines “breadboard” and “chips” represents a selection Instance which can be reused in new scenarios, where some “chips” (e.g., utility functions) are modified whereas others stay unchanged. In this paper, the “chips,” namely, the template modules, which represent the declarative knowledge, are formally defined as ontology classes as discussed in Sec. 4. The “breadboard,” which captures the procedural knowledge, is modeled as several automatic procedures with clearly defined inputs and outputs as shown in Sec. 3.2.
Executability—Definition of Automatic Procedures.
In this section, four automatic procedures are identified according to the u-sDSP construct, which facilitate the executability of the u-sDSP template in a computational environment. Most of the computational work in the selection decision making process (as shown in Fig. 2) is involved in these procedures, while the problem formulation work is left to the designers who are the decision-makers. The procedures represent the procedural knowledge archived in the u-sDSP template and are encoded using Java function calls (which are not the focus of this paper) in the ontological environment.
Individual Utility Function Construction.
The utility function that accurately reflects the decision-maker's preference with respect to a particular attribute must be constructed; it maps to Step 4 shown in Fig. 2. In Step 4, the decision-maker is required to identify several levels of attribute values indicating particular utility values by answering lottery questions [36]; then these identified attribute values are fitted to a function form, which is deemed to be the decision-maker's utility function for that attribute. In our method, curve fitting is an automated procedure that transforms the answers to a series of lottery questions to individual utility functions. Specific information of the procedure is shown in Fig. 4. Numbers , and denote five levels of attribute values, where the subscripts represent the utility value and superscripts indicate whether they are left-hand side and right-hand side of the target. For the nonmonotonic (target-based) attributes, both of the left-hand side and right-hand side attribute values are needed as inputs, while for the monotonic attributes, either left-hand side (for monotonically increasing attributes) or right-hand side (for monotonically decreasing attributes) is needed. The outputs of the procedure are the coefficients of the left-hand side utility function and (or) right-hand side utility function (Here, the utility function is assumed to take a general form of where , and are the coefficients.).
Multi-Attribute Utility Function Construction.
This procedure is aimed at identifying the multi-attribute utility function that reflects the decision-maker's preference with respect to a combination of multiple conflicting attributes; it maps to Step 5 shown in Fig. 2. The key idea is that the scaling constants () [5,36] of the multi-attribute utility function can be determined by solving the system of equations, which includes linear equations, as shown in Fig. 5. In Fig. 5, , , , and are different levels of attribute , where stands for the worst level with the utility 0, and are two levels that conform to (here we assume that maps to utility value 0.55 and maps to utility value 0.45; thus, is preferred to ), is a level specified by the decision-maker to create equivalent attribute combinations such as with which the decision-maker is indifferent and thus have the same utility. When both the multiutility independence and the additive independence properties [36] are held, the multiutility function conforms to the additive form . Based on the additive utility function form and the equivalent attribute combinations, multiple linear equations can be set up to represent the corresponding same utilities. These equations constitute an n-variable equation system based on which the k-values are determined. In the equation system, n-1 equations are set up based on the equivalent attribution combinations specified by the decision-maker; the remaining one is represented by , which indicates the condition that the k-values must sum to one. Here, the solving of the equation system is identified as an automatic procedure which transfers the specifications of some attributes levels to the multi-attribute function. The inputs of it are specified levels of n-1 attributes, and the outputs are the scaling constants .
Expected Utility Calculation.
This procedure is aimed at evaluating the expected utility of each alternative so as to identify the ranking of preferences; it maps to Step 6 shown in Fig. 2. The expected utility of a particular alternative is evaluated by first calculating the expected utility with respect to each attribute using individual utility functions, then calculating the overall expected utility using the multi-attribute utility function, as shown in Fig. 6. For individual utility calculation, the expected utility of an alternative with respect to a target-based nonmonotonic attribute is used as an example in the figure. In the example, the range of the alternative in terms of the attribute is assumed to be within the range defined by the attribute's left-hand side acceptable value and right-hand side acceptable value , and the distribution is assumed to be uniform of which the probability density is defined as where and denote the lower and upper bounds of the alternative's attribute, respectively. Based on the equation , the individual expected utility can be deducted to be , where denotes the length of the alternative's attribute range, denotes the length measured form to , denotes the length measured from to , and denote, respectively, the left-hand side and right-hand side areas bounded by the x-axis, bounds of the attribute value and the utility function curves. This equation is critical to generate variations in the postsolution analysis which will be introduced in detail Sec. 3.2.4. The results of individual expected utility calculation are used as input to the equation for the generation of the alternative's overall expected utility. Here, the calculation procedure is identified as an automatic activity. The inputs include: (i) the acceptable ( and ) and ideal () levels of the attributes, (ii) the bounds ( and ) of the alternative's attribute value, and (iii) the k-values. The outputs include the individual expected utility values and the overall expected utility .
Postsolution Sensitivity Analysis.
This procedure is aimed at testing whether the result is sensitive to some potential parameter variations and enhances the confidence of the decision-maker to select the most promising alternative; it maps to Step 8 shown in Fig. 2. The key idea is first to select the top two (or more if their expected utilities are very close to each other) alternatives, then test whether the corresponding changes in the overall expected utilities are large enough to influence the ranking of the two alternatives when taking some parameter variations into consideration. From the expected utility calculation procedure shown in Fig. 6, it is seen that parameter variation can and only can occur in two equations, namely, which is used to calculate the overall expected utility and which is used to calculate the individual expected utility. As to the former, the parameter variation is represented by , while the latter is represented by and as shown in Fig. 7. In Fig. 7, denotes the variation of the scaling constants; it influences the overall expected utilities of all the alternatives. denotes the variation (toward the target value, means the alternative is more risk-prone while moving away from the target value means being more risk-averse) of the individual utility function; it influences the individual expected utilities of all the alternatives. denotes the variation (reducing or enlarging) range for the attribute value of an particular alternative; it only influences the individual expected utilities of that alternative. To perform sensitivity analysis, the decision-maker can prepare several scenarios with a constant increment or decrement (i.e., 5%) of , , and , then recalculate and to obtain the responding expected utility values of the top two alternatives, and display the changes in the ranking of the two alternatives with respect to the scenarios using visualization tools (i.e., line chart shown in Fig. 7). Here, the postsolution analysis is identified as an automatic procedure which transfers the decision-maker's specification of parameter variations to the sensitivity in the ranking of alternatives. Specifically, the inputs include (i) the top two alternatives (, ), (ii) parameter variation (, , and ), and (iii) number of scenarios (), the output are the corresponding sensitivity graphs.
Ontology Development for the Selection DSP Template
In this section, we deal with the knowledge representation, namely, development of an ontology based on the u-sDSP template built in Sec. 3. There are two popular ontology development diagrams—web ontology language (OWL) and Frame [37]. We choose the Frame diagram because it is based on a closed-world assumption where everything is prohibited unless it is permitted, which is suitable for representing the mathematically rigorous u-sDSP template. In this section, the classes, slots, and consistency rules that constitute a frame-based ontology are formally defined in keeping with the u-sDSP template model, and an overview of the structure with the integration of the classes and slots is presented. Based on the developed ontology, a comprehensive instance is presented in Sec. 5.
Class Definition.
The six “chips” shown in Fig. 3 are the key concepts that constitute the main structure of the u-sDSP template ontology and are explicitly defined as classes in this section. In addition to them, seven additional classes referred as U-SDSPTemplate, MUtilityFunction, IUtilityFunction, IAttributeAssessment, MAssessment, UtilityCalculation, and Coefficient are identified to capture the knowledge that adds to the semantic richness and integrity of the ontology. The definitions of the classes are shown in Table 1.
Class | Definition |
---|---|
U-SDSPTemplate | A formulation of a selection decision problem with multiple conflicting attributes under uncertainty. Integration of all the template modules and the associated information. |
Alternative | A feasible option considered to fulfill some certain requirements. |
Attribute | A quality or feature regarded as a characteristic part of an alternative. |
UtilityFunction | A function used to indicate the decision-maker's preference with respect to attribute(s). |
MUtilityFunction | A subclass of UtilityFunction, whose function values indicate the decision-maker's preference with respect to the combination of these attributes. |
IutilityFunction | A subclass of UtilityFunction, whose function values indicate the decision-maker's preference with respect to that single attribute. |
Evaluation | The making of judgments about the utility values of the alternatives. Including the information captured by classes IattributeAssessment, Massessment, and UtilityCalculation. |
IAttributeAssessment | The assessment of the decision-maker's preference with respect to a single attribute. Capturing the information of the inputs shown in Figure 4. |
MAttributeAssessment | The assessment of the decision-maker's preference with respect to multiple attribute. Capturing the information of the inputs shown in Figure 5. |
Coefficient | The coefficient in the utility function of the form . |
UtilityCalculation | The calculation of the expected utility of each alternative with respect to each attribute. This is used to capture the information of the inputs shown in Figure 6. |
Ranking | The order of the decision-maker's preferences with respect to the alternatives. |
PSAnalysis | The analysis of the sensitivity of the decision-maker's preferences with respect to the alternatives considering some type(s) of parameter variation. |
Class | Definition |
---|---|
U-SDSPTemplate | A formulation of a selection decision problem with multiple conflicting attributes under uncertainty. Integration of all the template modules and the associated information. |
Alternative | A feasible option considered to fulfill some certain requirements. |
Attribute | A quality or feature regarded as a characteristic part of an alternative. |
UtilityFunction | A function used to indicate the decision-maker's preference with respect to attribute(s). |
MUtilityFunction | A subclass of UtilityFunction, whose function values indicate the decision-maker's preference with respect to the combination of these attributes. |
IutilityFunction | A subclass of UtilityFunction, whose function values indicate the decision-maker's preference with respect to that single attribute. |
Evaluation | The making of judgments about the utility values of the alternatives. Including the information captured by classes IattributeAssessment, Massessment, and UtilityCalculation. |
IAttributeAssessment | The assessment of the decision-maker's preference with respect to a single attribute. Capturing the information of the inputs shown in Figure 4. |
MAttributeAssessment | The assessment of the decision-maker's preference with respect to multiple attribute. Capturing the information of the inputs shown in Figure 5. |
Coefficient | The coefficient in the utility function of the form . |
UtilityCalculation | The calculation of the expected utility of each alternative with respect to each attribute. This is used to capture the information of the inputs shown in Figure 6. |
Ranking | The order of the decision-maker's preferences with respect to the alternatives. |
PSAnalysis | The analysis of the sensitivity of the decision-maker's preferences with respect to the alternatives considering some type(s) of parameter variation. |
Slot Definition.
The semantic relationships between classes are captured using slots in a frame-based ontology. Generally, there are two types of slots—data slots and object slots. Data slots are used to link classes to end data (e.g., link the class Attribute to a target value with the type of Float) while object slots are used to link classes to other classes (e.g., link the class Attribute to the class Alternative) or to themselves. Based on u-sDSP construct and the u-sDSP template structure, the data slots and object slots of the u-sDSP template ontology are defined as shown in Table 2 and Table 3, respectively.
Slot name | Definition | Type |
---|---|---|
Name | Name of an instance | String |
description | Description of an instance | String |
problemStatement | A statement of a selection problem | String |
acronym | An acronym of an attribute or alternative | String |
interest | Whether an attribute is of interest for the selection or not (“yes” or “no”) | Symbol |
Reason | The reason why an attribute is considered or not | String |
Risk | The decision-maker's attitude about risk toward an attribute (“aversion,” “proneness” or “none”) | Symbol |
monotonicity | The monotonicity of the decision-maker's preference about an attribute (“target,” “increasing,” or “decreasing”) | Symbol |
Scale | The scale of an attribute (“ratio” or “interval”) | Symbol |
Unit | The unit of an attribute's measurement | String |
lowerBound | The lower bound of a general attribute or an alternative's attribute | Float |
upperBound | The upper bound of a general attribute or an alternative's attribute | Float |
targetValue | The ideal value of an attribute | Float |
attributeLevel | A level of an attribute (“0,” “0.25,” “0.5,” “0.75,” or “1”) | Symbol |
Side | The side of the target (“left-hand-side” or “right-hand-side”) | Symbol |
Value | The value of an attribute or utility | Float |
specifiedAttriValue | An attribute value specified by the decision-maker in creating an equivalence | Float |
k-value | The scaling constant associated to an individual utility function | Float |
position | The position of an efficient in (“a,” “b,” “c,” or “d”) | Symbol |
distribution | The distribution of the attribute value (“uniform,” “normal,” etc., default is uniform) | Symbol |
Rank | The rank of a particular alternative | Integer |
overallUtility | The overall utility of an alternative with respect to all the attributes | Float |
variationType | The type of variation in postsolution analysis (“Δk,” “Δx,” or “ΔL”) | Symbol |
variationDirection | The direction of variation (“increment” or “decrement”) | Symbol |
variationExtent | The extent of variation (the unit is “%”) | Float |
Image | The (path of) graph that captures the responding sensitivity | String |
interpretation | The interpretation of a sensitivity graph | String |
Slot name | Definition | Type |
---|---|---|
Name | Name of an instance | String |
description | Description of an instance | String |
problemStatement | A statement of a selection problem | String |
acronym | An acronym of an attribute or alternative | String |
interest | Whether an attribute is of interest for the selection or not (“yes” or “no”) | Symbol |
Reason | The reason why an attribute is considered or not | String |
Risk | The decision-maker's attitude about risk toward an attribute (“aversion,” “proneness” or “none”) | Symbol |
monotonicity | The monotonicity of the decision-maker's preference about an attribute (“target,” “increasing,” or “decreasing”) | Symbol |
Scale | The scale of an attribute (“ratio” or “interval”) | Symbol |
Unit | The unit of an attribute's measurement | String |
lowerBound | The lower bound of a general attribute or an alternative's attribute | Float |
upperBound | The upper bound of a general attribute or an alternative's attribute | Float |
targetValue | The ideal value of an attribute | Float |
attributeLevel | A level of an attribute (“0,” “0.25,” “0.5,” “0.75,” or “1”) | Symbol |
Side | The side of the target (“left-hand-side” or “right-hand-side”) | Symbol |
Value | The value of an attribute or utility | Float |
specifiedAttriValue | An attribute value specified by the decision-maker in creating an equivalence | Float |
k-value | The scaling constant associated to an individual utility function | Float |
position | The position of an efficient in (“a,” “b,” “c,” or “d”) | Symbol |
distribution | The distribution of the attribute value (“uniform,” “normal,” etc., default is uniform) | Symbol |
Rank | The rank of a particular alternative | Integer |
overallUtility | The overall utility of an alternative with respect to all the attributes | Float |
variationType | The type of variation in postsolution analysis (“Δk,” “Δx,” or “ΔL”) | Symbol |
variationDirection | The direction of variation (“increment” or “decrement”) | Symbol |
variationExtent | The extent of variation (the unit is “%”) | Float |
Image | The (path of) graph that captures the responding sensitivity | String |
interpretation | The interpretation of a sensitivity graph | String |
Slot name | Definition | Type |
---|---|---|
hasAlternatives | Link a U-SDSPTemplate to a set of Alternatives. | Alternative |
hasAttributes | Link a U-SDSPTemplate to a set of Attributes. | Attribute |
hasUtilityFunction | Link a U-SDSPTemplate to an UtilityFunction. | UtilityFunction |
hasEvaluation | Link a U-SDSPTemplate to an Evaluation. | Evaluation |
hasRanking | Link a U-SDSPTemplate to a Ranking. | Ranking |
hasPSAnalysis | Link a U-SDSPTemplate to a PSAnalysis. | PSAnalysis |
associatedTo | Interrelate two different classes. | Instance |
HasCoefficients | Link an IutilityFunction to a set of Coefficients. | Coefficient |
hasIFunctions | Link a MutilityFunction to a set of IUtilityFunctions. | IUtilityFunction |
iAttributeAssessment | Link an Evaluation to a set of IAttributeAssessment. | IAttributeAssessment |
mAttributeAssessment | Link an Evaluation to a set of MAttributeAssessment. | MAttributeAssessment |
utilityCalculation | Link an Evaluation to a set of UtilityCalculations. | UtilityCalculation |
attribute | Link a MAttributeAssessment, IAttributeAssessment, or UtilityCalculation to a (set of) Attribute(s). | Attribute |
alternative | Link an UtilityCalculation or a Ranking to an Alternative. | Alternative |
Slot name | Definition | Type |
---|---|---|
hasAlternatives | Link a U-SDSPTemplate to a set of Alternatives. | Alternative |
hasAttributes | Link a U-SDSPTemplate to a set of Attributes. | Attribute |
hasUtilityFunction | Link a U-SDSPTemplate to an UtilityFunction. | UtilityFunction |
hasEvaluation | Link a U-SDSPTemplate to an Evaluation. | Evaluation |
hasRanking | Link a U-SDSPTemplate to a Ranking. | Ranking |
hasPSAnalysis | Link a U-SDSPTemplate to a PSAnalysis. | PSAnalysis |
associatedTo | Interrelate two different classes. | Instance |
HasCoefficients | Link an IutilityFunction to a set of Coefficients. | Coefficient |
hasIFunctions | Link a MutilityFunction to a set of IUtilityFunctions. | IUtilityFunction |
iAttributeAssessment | Link an Evaluation to a set of IAttributeAssessment. | IAttributeAssessment |
mAttributeAssessment | Link an Evaluation to a set of MAttributeAssessment. | MAttributeAssessment |
utilityCalculation | Link an Evaluation to a set of UtilityCalculations. | UtilityCalculation |
attribute | Link a MAttributeAssessment, IAttributeAssessment, or UtilityCalculation to a (set of) Attribute(s). | Attribute |
alternative | Link an UtilityCalculation or a Ranking to an Alternative. | Alternative |
Consistency Rule Definition.
It is of critical importance for an ontology to restrict the populated Instances in the manner as they are defined to be, that is to keep consistency. Inconsistency often happens in the instantiation process when the ontology is populated using specific data and in the modification process when the original instances are modified. To avoid inconsistency, detecting it and informing designers to fix it is very important. Rule-based reasoning is the method used for consistency checking in ontologies. The rules for maintaining consistency in the u-sDSP template ontology are identified as shown in Table 4. Java Expert System Shell (JESS) [38], 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 2 as an example):
Rule 1 | Every instance of “Attribute” should comply to: lowerBound ≤ targetValue ≤ upperBound. |
Rule 2 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 0 & side = Left-hand-side) = > (value = attribute.lowerBound). |
Rule 3 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 1) => (value = attribute.lowerBound). |
Rule 4 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 0 & side = Right-hand-side) => (value = attribute.upperBound). |
Rule 5 | Every instance of “IUtilityFunctions” should comply to: k-value . |
Rule 6 | Every instance of “IUtilityFunctions” should comply to: . |
Rule 7 | The number of instances in the slot “utilityCalculation” should be equal to: alternatives × attributes. |
Rule 8 | Every instance of “UtilityCalculation” should comply to: lowerBound < upperBound. |
Rule 1 | Every instance of “Attribute” should comply to: lowerBound ≤ targetValue ≤ upperBound. |
Rule 2 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 0 & side = Left-hand-side) = > (value = attribute.lowerBound). |
Rule 3 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 1) => (value = attribute.lowerBound). |
Rule 4 | Every instance of “IAttributeAssessment” should comply to: (attributeLevel = 0 & side = Right-hand-side) => (value = attribute.upperBound). |
Rule 5 | Every instance of “IUtilityFunctions” should comply to: k-value . |
Rule 6 | Every instance of “IUtilityFunctions” should comply to: . |
Rule 7 | The number of instances in the slot “utilityCalculation” should be equal to: alternatives × attributes. |
Rule 8 | Every instance of “UtilityCalculation” should comply to: lowerBound < upperBound. |
(defrule MAIN::rule_2 (object (is-a: IAttributeAssessment) (:attributeLevel 0) (:side Left-hand-side) (:value?x) (:attribute?a))
=>
(if (neq?x (slot-get?a lowerBound)) then (printout t WARNING_2 crlf)))
This means that if any Instance of “IAttributeAssessment” violates Rule 2, the reasoner will send a message (referred as “WARNING_2”) about the inconsistency to the designer who is working on that u-sDSP template.
Overview of the Ontology.
The u-sDSP template ontology structure with the integration of concepts and relations is shown in Fig. 8. It is a network structure in which the nodes represent the classes and the end data. Different classes and data are linked by slots (including object slots and data slots) which are represented as lines with text (the slot names) in the middle. The node in the center is the core class of the ontology, which represents the information entry of the template. The six nodes directly linked to the center are the key components of the ontology, which represents the “chips” of the template (see Fig. 3). The ontology modeling process is facilitated using Protégé tool [39] developed by Stanford University, Stanford, CA which provides an environment for creating, editing ontologies, as well as populating Instances based on ontologies. The interface of Protégé and a u-sDSP template Instance example are shown in Fig. 9. Protégé also enables the development of plugins as extension to the function of ontology. JessTab [40] is a plugin that attaches JESS to Protégé and is used for consistency checking in this paper. To facilitate the execution (procedures identified in Sec. 3.2) of the populated u-sDSP template Instances, we also developed a plugin that implements the computing work using Java function calls.
Example
In this section, a rapid prototyping (RP) resource selection problem is used as an example to illustrate the utility of the u-sDSP template ontology in terms of facilitating reuse and execution of knowledge embedded in the DSP. The example is an extension of the problem considered by Fernández et al. [5] who use it to illustrate the process of formulating and solving a specific u-sDSP. First, an Instance is created using the original selection information in Sec. 5.1, then three knowledge-reuse scenarios are presented in Sec. 5.2. Finally, a summary and discussion are given in Sec. 5.3.
Populating an Original Selection Instance.
Rapid Prototyping is a technology that offers significant potential for reducing cost and time to market for the development of new, redesigned, and customized products. The selection of proper resource (e.g., materials and manufacturing processes) is an important aspect of RP technology. The example used to illustrate the method involves the selection of material-process combinations to make a light switch cover plate assembly (as shown in Fig. 10) using RP technology [5]. The primary objectives of the resulting prototype, in decreasing order of importance, are (1) function product validation, particularly with respect to the snap-fitting of components as circled in Fig. 10, (2) determining the closeness of fit or tolerance of the two interfacing components, (3) obtaining a feel for the product, (4) visual and physical confirmation of 3D interface integrity. To achieve the preceding objectives, four alternatives and five attributes are considered as shown in Table 5. The alternatives are four material-process combinations, for details see Ref. [5]. The five attributes are a mixture of ratio and interval scales—Tensile Strength, Young's Modulus, and Flexural Strength are measured by ratio scales, and Detail Capability and Accuracy are measured by interval scales. The designers' preferences toward these attributes are a mixture of monotonicity and nonmonotonicity, for example, Accuracy is an attribute with a monotonically decreasing preference characteristic while Tensile Strength is an attribute with a nonmonotonic, target-based (e.g., “65 MPa” refers to the target for Tensile Strength as shown in Table 5) preference characteristic. Attribute values of the alternatives are uncertain and represented by ranges with a lower bound and an upper bound, for example, “44-69 MPa” refers to the value range of attribute Tensile Strength for alternative SLA250-DSM7110. All the attribute values are assumed to be subjected to Uniform distribution. Given the data presented in Table 5, the designer is required to select the most promising alternative.
Attribute | Ratio | Interval | ||||
---|---|---|---|---|---|---|
Alternativeprocess | Material | Tensile strength (50-65-75) MPa | Young's modulus (1500-2137-2600) MPa | Flexural strength (70-95-120) MPa | Detail capability (0.4–0.9) mm | Accuracy (0.02–0.1) |
SLA250 | DSM7110 | 44–69 | 1758–2413 | 59–110 | 0.45–0.55 | 0.04–0.05 |
SLA3500 | DSM8120 | 23–29 | 633–773 | 23–29 | 0.45–0.55 | 0.04–0.05 |
FDM1650 | P400 | 31–37 | 2234–2730 | 58–72 | 0.45–0.55 | 0.12–0.14 |
MJM2100 | TJ75 | 9–11 | 90–110 | 9–11 | 0.67–0.83 | 0.12–0.14 |
Distribution: uniform |
Attribute | Ratio | Interval | ||||
---|---|---|---|---|---|---|
Alternativeprocess | Material | Tensile strength (50-65-75) MPa | Young's modulus (1500-2137-2600) MPa | Flexural strength (70-95-120) MPa | Detail capability (0.4–0.9) mm | Accuracy (0.02–0.1) |
SLA250 | DSM7110 | 44–69 | 1758–2413 | 59–110 | 0.45–0.55 | 0.04–0.05 |
SLA3500 | DSM8120 | 23–29 | 633–773 | 23–29 | 0.45–0.55 | 0.04–0.05 |
FDM1650 | P400 | 31–37 | 2234–2730 | 58–72 | 0.45–0.55 | 0.12–0.14 |
MJM2100 | TJ75 | 9–11 | 90–110 | 9–11 | 0.67–0.83 | 0.12–0.14 |
Distribution: uniform |
We assume that the designer has correctly formulated the problem using the u-sDSP construct shown in Fig. 1 and following the steps listed in Fig. 2. Based on the formulation, a u-sDSP template Instance for RP resource selection is populated in Protégé as shown in Fig. 9. In Fig. 9, 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 to 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., “problemStatement,” “has Alternative,” “has Attributes,” etc.) of the RP resource selection Instance are created according to the ontology developed in Sec. 4 and the problem data itself. It is noted that because of the identification of the automated procedures in Sec. 3.2, the values of some slots (e.g., slot “k-value”), which represent the outputs of these procedures (e.g., multi-attribute utility function construction), are automatically generated by Java function calls according to the encoded logic. The result of selection is the ranking with an increasing order: SLA250-DSM7110, FDM1650-P400, SLA3500-DSM8120, MJM2100-TJ75. The overall utility of the top alternative SLA250-DSM7110 is 0.69, as shown in the front window in Fig. 9.
Knowledge Reuse—Modification of the Original Instance
Scenario 1: Introduction of New Alternatives.
In this scenario, a new combination of the process SLA3500 provided by 3D Systems and the material SL7510 provided by Vantico AG needs to be considered as an alternative for prototyping the switch cover plate assembly. Specification of the new alternative SLA3500-SL7510 is presented in Table 6. The problem transfers from a four-alternative problem to a five-alternative problem and the designer needs to formulate the new problem and do the selection again. In the ontological context, since much of the knowledge needed for the current decision such as attributes, individual utility functions, and the multi-attribute utility function, etc. is well documented in the original selection decision template Instance, selection can be made based on this knowledge with some necessary modifications. The inconsistency brought by the modification is managed using a rule-based consistency checking mechanism introduced in Sec. 4.3, for a detailed example see Ref. [20]. Here, the key modification is adding a new alternative using the specific information presented in Table 6 and then updating the ranking, as shown in Fig. 11. Specific steps are as follows:
Attribute | Ratio | Interval | ||||
---|---|---|---|---|---|---|
Alternative process | Material | Tensile strength (50-65-75) MPa | Young’s modulus (1500-2137-2600) MPa | Flexural strength (70-95-120) MPa | Detail capability (0.4–0.9) mm | Accuracy (0.02–0.1) |
SLA3500 | SL7510 | 42.3–55.46 | 1877–2869 | 78–96 | 0.45–0.55 | 0.04–0.05 |
Distribution: uniform |
Attribute | Ratio | Interval | ||||
---|---|---|---|---|---|---|
Alternative process | Material | Tensile strength (50-65-75) MPa | Young’s modulus (1500-2137-2600) MPa | Flexural strength (70-95-120) MPa | Detail capability (0.4–0.9) mm | Accuracy (0.02–0.1) |
SLA3500 | SL7510 | 42.3–55.46 | 1877–2869 | 78–96 | 0.45–0.55 | 0.04–0.05 |
Distribution: uniform |
- (1)
Specify the general information—provide information in slots “acronym,” “description,” and “image” to instantiate a new alternative.
- (2)
Specify attribute value ranges—Provide information in slots “lowerBound,” “upperBound,” and “distribution” with respect to a particular attribute. Here, we only show the specification in terms of attribute “Tensile Strength,” other attribute value ranges can be specified in the same way.
- (3)
Plug the new alternative in the slot “has Alternatives.”
- (4)
Update the ranking—After all necessary information is input and the ranking is automatically updated. It is shown that the lately introduced alternative has the overall utility of 0.56 and ranks at the second place, thus is not the most promising alternative.
Scenario 2: Introduction of New Attributes.
In this scenario, a new attribute Flexural Modulus, which is a measure of the modulus of flexural stiffness of the material, needs to be considered to evaluate the five alternatives. It must be considered because it is very important for validation of stiffness requirements of the snap-fit design. Specification of this attribute includes four facets as shown in Table 7: (I) general information such as units, scales, target (ideal value), lower and upper unacceptable values; (II) the assessment of left-hand and right-hand side utility, which is necessary for the construction of the utility function of the attribute; (III) the attribute levels for creation of equivalences (see Sec. 3.2.2) to redetermine the “k-values” of the attributes; (IV) the Flexural Modulus value ranges of each alternative, which are used to evaluate the expected utility with respect to this attribute. With the specification presented in Table 7, a designer needs to formulate a new six-attribute problem and do the selection again. As mentioned in Sec. 5.2.1, much of the documented knowledge can be reused with some necessary modifications. In the ontological context, the key modification is instantiating a new attribute and then updating the ranking, as shown in Fig. 12. Specific steps are as follows (the input of the steps comes from Table 7):
I | Units | Scale | Lower unacceptable | Ideal | Upper unacceptable | ||||
MPa | Ratio | 1800 | 2344 | 2800 | |||||
II | Left-hand side utility (MPa) | Right-hand side utility (MPa) | |||||||
0 | 0.25 | 0.5 | 0.75 | 1 | 0.75 | 0.5 | 0.25 | 0 | |
1800 | 1861.34 | 1995.45 | 2111.50 | 2344 | 2505.46 | 2623.34 | 2723.31 | 2800 | |
III | TS | YM | FS | FM | DC | ||||
62 MPa | 2030 MPa | 90 MPa | 2227 MPa | 0.42 mm | |||||
IV | DSM7110 | SL7510 | DSM8120 | P400 | TJ75 | ||||
1710–2668 MPa | 2374–2902 MPa | 621–759 MPa | 2358–2882 MPa | 90–110 MPa |
I | Units | Scale | Lower unacceptable | Ideal | Upper unacceptable | ||||
MPa | Ratio | 1800 | 2344 | 2800 | |||||
II | Left-hand side utility (MPa) | Right-hand side utility (MPa) | |||||||
0 | 0.25 | 0.5 | 0.75 | 1 | 0.75 | 0.5 | 0.25 | 0 | |
1800 | 1861.34 | 1995.45 | 2111.50 | 2344 | 2505.46 | 2623.34 | 2723.31 | 2800 | |
III | TS | YM | FS | FM | DC | ||||
62 MPa | 2030 MPa | 90 MPa | 2227 MPa | 0.42 mm | |||||
IV | DSM7110 | SL7510 | DSM8120 | P400 | TJ75 | ||||
1710–2668 MPa | 2374–2902 MPa | 621–759 MPa | 2358–2882 MPa | 90–110 MPa |
- (1)
Specify the general information—provide information in slots “name,” “acronym,” “description,” etc., to instantiate a new attribute.
- (2)
Specify information for individual attribute utility assessment—specify attribute values for the nine levels of utility. Window ② shown in Fig. 12 is the specification of level 0.25.
- (3)
Specify information for k-value assessment—specify attribute values for creating equivalences and determining the k-values of the multi-attribute utility function. Window ③ shown in Fig. 12 is the specification for attribute Flexural Modulus.
- (4)
Specify the attribute ranges for each alternative—the lower and upper bounds of the attribute with respect to each alternative is specified, as the range for alternative SLA3500-SL7510 shown in window ④ in Fig. 12.
- (5)
Plug in the new attribute and update the ranking—the newly specified attribute Flexural Modulus is plugged in the slot “hasAttribute” and the ranking is automatically updated. It is shown that the top two alternatives are SLA250-DSM7110 and SLA3500-SL7510, with overall utility 0.7 and 0.56, respectively.
Scenario 3: Parameter Variation.
In this scenario, some potential parameter variation needs to be considered to test the robustness (or sensitivity) of the selection and strengthen the designers' confidence in selecting the most promising alternative SLA250-DSM7110 to prototype the assembly. It can be seen in Sec. 5.2.2 that the utility of the alternative ranked at the second place (SLA3500-SL7510, 0.56) is close to that (0.7) of the top alternative. Here, we consider some parameter variations and examine whether the ranking is changed due to variation. Since postsolution sensitivity analysis is modeled as a module of the u-sDSP template, it can be performed independently by invoking the necessary information of other modules. In the ontological context, what needs to be done is simply instantiating an instance of the class “PSAnalysis” then plugging in the slot “hasPSAnalysis,” information in other slots are unchanged. The instantiation of the “PSAnalysis” includes the specification of the slots “alternative,” “attribute,” “variationType,” “variation Direction,” “variationExtent,” and “numberOfScenarios,” etc. (see the definitions in Table 2). Slot “image” of the Instance captures the graph that is automatically generated according to the preceding specification and is used to visualize the change of ranking due the variation. The designer can interpret the result according to the image, populate the slot “interpretation,” and document the Instance. In Sec. 3.2.4, we identified three types of parameter variation, i.e., Δk, Δx, and ΔL. Here, we take ΔL, namely, the variation of attribute value range as an example. In the example, the original range (1877–2869) of the attribute Young's Modulus for alternative SLA3500-SL7510 is gradually reduced (i.e., the uncertainty of this attribute is reduced) to test the responses of the alternative's overall utility and the relative ranking compared to the top one, as shown in Fig. 13. It can be seen in Fig. 13 that seven scenarios are scheduled for the testing and the attribute range is reduced by 5% in each scenario. The automatically generated image indicates that the overall utility of the alternative SLA3500-SL7510 increases from 0.56 to 0.6 when the attribute range is reduced to 80% (represented by the forth scenario in the image), then is stable at 0.6 even if the range is furtherly reduced. In the whole process, alternative SLA3500-SL7510 always ranks in the second place. Therefore, it can be concluded that the ranking is insensitive to the reduction of uncertainty of attribute Young's Modulus for alternative SLA3500-SL7510, and it is safe to select the most promising one—SLA250-DSM7110—even if the designer is quite certain about the Young's Modulus of SLA3500-SL7510.
Summary and Discussion.
Using the light switch cover plate assembly RP resource selection example, we (1) instantiate a u-sDSP template instance using the original selection problem information, (2) modify the existing u-sDSP template Instance and effect a new decision when new alternatives are introduced, (3) modify the existing u-sDSP template Instance and effect a new decision when new attributes are introduced, (4) perform postsolution sensitivity analysis when some parameter variation is considered. The reusability of the ontology is verified by facilitating the modification of a previously created Instance, and the executability is verified by the automatic update of the ranking after a set of modification and the automatic generation of result when performing postsolution analysis. The scenarios presented in this section map to the third way of reusing the selection decision making process knowledge identified in Sec. 3.1, namely, reusing the assembly of the “breadboard” and the “chips” (here, the assembly is the documented ontology Instance). It should be noted that the ontology also enables reusability in the other two ways (i.e., independent reuse of the “breadboard” and the “chips”) due to the modular, standardized template-based structure. For example, the ontology can be reused to document another material selection problem, and the already documented attribute Instance Flexural Modulus can be reused in that problem without change.
Closure
Engineering design is increasingly recognized as a decision making process and the principal role of a designer is to make decisions. To augment this role of a decision-maker, providing relevant decision support is very important. In this paper, we propose an ontological template-based method that provides decision support by integrating the decision “construct” and the relevant decision-making “information.” With respect to the “construct,” u-sDSP acts as mathematical tool for making multi-attribute selection decisions under uncertainty. With respect to the “information,” the u-sDSP template ontology offers a means for archiving the critical decision-making information in an executable, reusable, and consistency-maintainable manner that facilitates rapid decision making. Particularly, in this paper, the reusability of the u-sDSP template is achieved through the separation of declarative and procedural knowledge, and the executability is achieved through the identification and definition of four automatic procedures. By an RP resource selection example, the efficacy of the approach proposed in this paper is demonstrated. It is shown that the ontology not only captures and documents a selection rationale that helps the designer understand about how and why previous decisions are made, but also facilitates the designer reusing (by modification) previous information to effect new decisions when requirements change.
According to Mistree et al. [19], there are two types of decisions (namely, selection and compromise) and any complex design can be represented through modeling a network of selection and compromise. By this paper, the selection DSP ontology is created for representation of the selection decisions. Future research opportunities lie in the combination of the selection DSP ontology and the compromise DSP ontology [20] to represent complex design processes and providing relevant decision support along the design processes, which are the goals that our decision support platform PDSIDES is targeting.
Acknowledgment
Zhenjun Ming acknowledges the support from China Scholarship Council Grant No. 201406030014 for visiting the System Realization Laboratory at the University of Oklahoma and carrying out this research. Yan Yan and Guoxin Wang acknowledge the support from National Natural Science Foundation of China Grant No. 51375049. Janet K. Allen and Farrokh Mistree gratefully acknowledge NSF Grant No. CMMI-1440457.