An Ontology for Representing Knowledge of Decision Interactions in Decision-Based Design

Computers in Industry 114 (2020) 103145

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

An Ontology for Representing Knowledge of Decision Interactions in Decision-Based Design Zhenjun Ming a,b , Gehendra Sharma a , Janet K. Allen a,∗ , Farrokh Mistree a a b

Systems Realization Laboratory, The University of Oklahoma, Room 219-C, 202 W. Boyd Street, Norman, Oklahoma, 73019, USA Institute for Industrial Engineering, Beijing Institute of Technology, 5 S. Zhongguancun St., Bejing, 100081, China

a r t i c l e

i n f o

Article history: Received 8 June 2019 Received in revised form 7 October 2019 Accepted 12 October 2019 Keywords: Decision Interaction Decision-Based Design Decision Workflow Ontology Knowledge Representation

a b s t r a c t Design processes for complex engineered systems are inherently complex due to the dependencies among subsystems at the same level and between levels of a partitioned hierarchy. In decision-based design, this results in interactions among sets of design decisions. Representing and capturing the knowledge related to the decision interactions is critical for designing decision-based design processes. Two key challenges in modeling the interactions are:

• there are different types of decisions, and • these decisions are made at different levels. To address these challenges, in this paper we identify nine basic interaction patterns among decisions and propose an ontology to define the knowledge associated with these interaction patterns. Key advantages of the ontology include that we can capture both the vertical and horizontal interactions between decisions in a decision-based design process, and we can design flexible, reusable, and executable decision workflows for designing complex systems using the ontology. The utility of the ontology is illustrated via a one[HYPHEN]stage reduction gearbox design example, a hot rod rolling process design example and a composite structure design example. © 2019 Elsevier B.V. All rights reserved.

1. Frame of Reference We approach design from a decision-based perspective wherein the principal (but not only) role of a designer is to make decisions (Mistree et al., 1990). In complex engineered systems such as an automobile, the design decisions are typically made by design groups organized by discipline. Partitioning of complex engineered systems into smaller more manageable problems is a common approach but is limited to situations wherein the interactions among sub-problems can be clearly defined (Kusiak and Larson, 1995). Interactions among decisions are inevitable due to relationships in the structure and knowledge of complex engineered systems. Interactions embody the dependency (or interdependence) among different decisions. It occurs as two decisions influence one another. Two typical examples are the one-way (weak) interactions and the two-way (strong) inter-

∗ Corresponding author. E-mail addresses: [email protected] (Z. Ming), [email protected] (G. Sharma), [email protected] (J.K. Allen), [email protected] (F. Mistree). https://doi.org/10.1016/j.compind.2019.103145 0166-3615/© 2019 Elsevier B.V. All rights reserved.

actions. One-way interactions result when the output of one decision impacts another decision. Two-way interactions result when each decision impacts the other. Decision interaction is the “glue” to connect different decisions and reach the shared, desired design output. Modeling these interactions is critical to enable the planning of flexible design processes and to explore the design space. One of the challenges in modeling decision interactions is that one must account for different decision types. For example, in engineering design, a decision may involve a choice among multiple alternatives such as design concepts, structures, and materials, etc., or necessitate the determination of the values for a set of design variables that satisfy a set of constraints and to achieve a specified objective. The former type of decisions are formally defined as selection and the later are defined as compromise (Mistree et al., 1990). In selection decisions, designers deal with multiple conflicting attributes; and in compromise decisions, they make a tradeoff among multiple conflicting objectives. Due to the existence of different decision types, the interaction between two decisions may form different patterns such as “selection-selection” (e.g., the selection of a heat exchanger concept and the selection

2

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

2. Literature Review 2.1. Coupling and Decomposition in Engineering Design

Fig. 1. A partition hierarchy of a complex system

of a cooling fluid for a specific application (Bascaran et al., 1989), “selection-compromise” (e.g, the selection of a barge arrangement and the design of the dimensions of the barge (Smith et al., 1987), “compromise-compromise” (e.g., design of the beam and columns of a portal frame structure (Vadde et al., 1994). In different decision interaction patterns, the direction, content, and strength of information flow are different, which increases the difficulty in modeling the interactions. Another challenge in modeling decision interactions is the multilevel feature of the design processes for complex engineered systems. Due to the fact that solving an “all-in-one” design problem is computationally prohibitive, a system is usually partitioned into many subsystems and sub-sub-systems that are connected at multiple levels in a hierarchy (Sobieszczanski-Sobieski, 1982), as shown in Fig. 1. From a decision-based design perspective, the associated design process includes a set of decisions that are made at different levels. There are both horizontal and vertical interactions between these decisions. The former refers to interactions that happen at the same level of the hierarchy (e.g., the interaction between Nodes 2.1 and 2.2 in Fig. 1), and the latter refers to interactions that happen across levels (e.g., the interaction between Nodes 1.1 and 2.2). Although patterns such as “selection-selection”, “selection-compromise”, and “compromisecompromise” can be used to explain the horizontal interactions, they are not expressive enough to describe the vertical interaction between decisions at different levels. There is a need to represent and capture such vertical interactions within a hierarchy. Ontology, referred to as an explicit specification of a conceptualization (Gruber, 1993), is increasingly used in modeling and managing engineering knowledge. Key advantages of an ontology include its superiority in the representation of complex relationships in a domain, unambiguous definition of terms to facilitate communication, data interoperability, information sharing, and reuse. In our earlier papers, we describe ontologies to represent knowledge related to selection decisions (Ming et al., 2017), compromise decisions (Ming et al., 2016). In this paper, we focus on modeling the interactions among decisions, that facilitate flexibility in the design of decision-based design processes. The rest of the paper is organized as follows. In Section 2, we present a review of relevant past work. In Section 3, we propose a scheme for identifying horizontal and vertical interaction patterns. In Section 4, we present an ontology to represent interactions among decisions in a decision-based design process. In Section 5, we test the efficacy of the proposed ontology using a gearbox design problem as an example and offer closing remarks in. Section 6.

Coupling is an intrinsic feature in the design of complex systems because complex systems typically involve many sub systems and the cause of the system performance is due to multisdiciplinary coupling. Reasons for considering coupling in design include the motivation to build high-fidelity predictive models for system performance and to achieve an overall superior design by incorporating the interactions among multiple parts and multiple physical effects. For example, Penning and coauthors (Penning et al., 2005) propose a fluid-structure coupled model to improve the prediction effectiveness of porous material vibroacoustic behavior. Dinc¸er and coauthors (Dinc¸er et al., 2019) develop a finite element method for analyzing fluid-structure interaction problems with large deflections. In order to effectively decrease the temperature, Zhu and coauthors (Zhu et al., 2019) consider the thermo-mechanical coupling in the topology design of the cooling system of a battery package. Shang and coauthors (Shang and Zhao, 2016) propose an acoustic–structural coupled optimization model in the topology design of bi-materials in order to minimize the sound pressure level in an interior acoustic medium. Larbi and coauthors (Larbi et al., 2008) propose finite element formulations for structural-acoustic interior problems with dissipative interfaces. The consideration of coupling in design, on the one hand, has the potential to bring superior and accurate solutions to designers, on the other hand, it may also lead to the increase of consumption of computing power and time as the problem size increases and too many details are incorporated (English et al., 2001). Decomposing coupled problems into subproblems is typically used as a means to handle the computation difficulties due to coupling (Alyaqout et al., 2011; Steward, 1981; Gebala and Eppinger, 1991; Wagner and Papalambros, 1993) propose the functional dependence table (PDT, also referred as the design incidence matrix) to assist in model-based decomposition of design problems. Designers can use DSM, PDT, and other matrix-based tools (e.g., the matrix-based decomposition tools proposed by Li and coauthors (Chen and Li, 2004; Li, 2010; Kusiak and Larson, 1995) review decomposition methods in design and summarize them into three categories: 1) product decomposition, 2) process decomposition, and 3) problem decomposition. With respect to first two categories, due to the clear structure in products and clear activities in processes, it is not difficult to decompose the products and processes. But when it comes to problem decomposition, it heavily depends on designers’ expertise and whether the interactions among sub-problems can be clearly defined. In this paper, we come from a decision-based design perspective. One assumption in this paper is that the decision decomposition structure in the design of an engineered system is already known (e.g., created by designers or learned from the literature), we start from this decomposition structure and capture the knowledge related to the decisions as well as the interactions among them using ontology. In Sections 2.2 and 2.3, we discuss decision-based design and ontology respectively. 2.2. Decision-Based Design and Decision Support Problems Hazelrigg (Hazelrigg, 1998) anchors his framework in utility theory and seeks to maximize the value (utility) of a designed artifact. The utility-based DBD framework provides a theoretical foundation for research efforts such as enterprise-driven engineering design (Chen et al., 2013), the discrete choice analysis in demand modeling (Wassenaar and Chen, 2003), etc. The main drawback that limits the Hazelrigg DBD framework from being used is that it is anchored in objective rationality, that is, the models (including

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

3

Fig. 2. Word formulations of the selection and compromise DSPs

the objective fucntion) are perfect, accurate and complete (Marston et al., 2000). This is rarely the case in engineering design practice. Since in practice models are usually incomplete and inaccurate, it is difficult (if not impossible) to generate a utility function which results in the best or optimum solution. Our implementation of DBD is the Decision Support Problem Technique (DSPT) (Mistree et al., 1990) that is based on bounded rationality (Simon, 1976). In implementing the DSPT, we seek “satisficing” (good enough) solutions. We believe that fundamentally there are only two types of decisions: selection and compromise, and we have shown that we can model a design process as a network of selection and compromise decisions (Bras and Mistree, 1991). Selection involves a choice amongst a number of possibilities taking into account a number of measures of merit of attributes. Compromise involves determining the “right” values of design variables to describe the best satisficing solution with respect to constraints and multiple goals. The word formulations of the selection DSP (sDSP) and compromise DSP (cDSP) are shown in Fig. 2; for the mathematical forms see (Mistree et al., 1990). The Selection and compromise DSP constructs have been used to formulate coupled decision-making problems in design, including “selection-selection” couling (Bascaran et al., 1989), “selection-compromise” coupling (Smith et al., 1987), and “compromise-compromise” coupling (Vadde et al., 1994). In a decomposition context where a complex design is partitioned into multiple levels consisting of a set of sub decisions, it is important to identify and capture the interactions among different decisions (and sub decisions) since they are the critical knowledge for designers to understand how the overall design is achieved. In Section 2.3, we discuss the ontology-based methods for capturing and modeling this knowledge. 2.3. Ontology-Based Knowledge Modeling in Engineering Design Designing is a knowledge-intensive process, capturing and reusing previous knowledge can speed up the design process and reduce the cost. Ontology is increasingly used for knowledge mod-

eling knowledge in the engineering domain. For example, Fenves and coauthors (Fenves et al., 2008) propose an ontology of a core product model (CPM) to support a broad range of information relevant to product lifecycle management. The function, form, and behavior of a product are represented as a UML class diagram in the CPM model. Lee and coauthors (Lee et al., 2012) propose a multilevel semantic model to represent product-related information and enable different stakeholder viewpoints across the product lifecycle. Panetto and coauthors (Panetto et al., 2012) define a product-centric ontology that integrates data from different information systems including enterprise resource planning, computer-aided design, product data management, and manufacturing execution system. Sim and coauthors (Sim and Duffy, 2003) propose an ontology for representing design processes from an activity-based perspective where they classify a set of activities referred to as design definition activities, design evaluation activities, and design management activities. Hatchuel and coauthors (Hatchuel et al., 2013) propose an ontology to define design as a generative based process and model design as a dual expansion where concepts and knowledge are interacting to expand. In the literature, there are some efforts in developing ontologies for representing decisions in engineering design. For example, Rockwell and coauthors (Rockwell et al., 2019) develop an ontology to facilitate decision making and support the communication of information among multiple stakeholders in the collaborative design of complex products. Core concepts in the ontology include design issues, alternatives, evaluation, criteria, and preferences. Chen and coauthors (Chen et al., 2016) propose an ontology to support the decision-making process in the disassembly of mechanical products. The key idea is the representation of assembly relationships as rules and application of rule-based reasoning in the ontological context. In order to facilitate the execution of decisions and the reuse of decision-related knowledge, in our earlier work, we create ontologies to model the elements in selection (Ming et al., 2017) and compromise (Ming et al., 2016) decisions.

4

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

2.4. Research Gaps and Contributions Based on the review and the detailed discussion of the related literature in Sections 2.1–2.3, we suggest that challenges in representing the knowledge of decision interactions in decision-based design are not well addressed, for the following reasons: 1) Lack of a method for capturing the semantics of interactions among decisions. Many matrix-based representation tools have been proposed to capture the dependencies among components (decisions in the context of DBD), however, the semantic details about interactions are not captured in these tools. For example, in a DSM-based representation, the strength of interaction between two components is represented using numeric values in a matrix. Detailed semantic information such the pattern in this interaction, the content of the information flow, are there parameters, variables, or equations, etc, which are not captured in the matrix. This semantic information is very important in decision-based design. 2) Lack of a model for horizontal and vertical integration of individual decision knowledge in a hierarchical decision workflow. Many existing semantic models such as the selection decision ontology (Ming et al., 2017), compromise decision ontology (Ming et al., 2016), and Rockwell’s decision-making ontology (Rockwell et al., 2019) focus on representing the semantics in the context of individual decisions. They are not able to capture knowledge such as horizontal dependencies and vertical dependencies, which are anchored in the interactions among individual decisions in a hierarchy. The interaction knowledge is very important for integrating multiple individual decisions in the design of complex systems. To address the aforementioned gaps, we propose an ontology for representing the knowledge of interactions in decision-based design. The new contributions are summarized as follows: • We identify and classify the basic decision interaction patterns in the design of complex engineered systems. The patterns include two vertical patterns that represent the partition and synthesis relationships among decisions at different levels of a hierarchy, and seven horizontal patterns that represent the coupling relationships between selection and compromise decisions. These patterns are the links that integrate different decisions in a hierarchy. • We describe an ontology to explicitly represent the semantic relationships embedded in different decision interactions. Using classes and properties in the ontology, we formalize the semantic knowledge about decision interactions. Ontological representation of the decision interactions facilitates knowledge retrieval, reuse, visualization. 3. Identification of Decision Interaction Patterns 3.1. Vertical Interactions Vertical interaction between decisions denotes working relationships between designers who are designing different levels of the systems (e.g., a gearbox and a gear). Typically, vertical interaction is a closed loop and includes two types of patterns: top-down partition and bottom-up synthesis, as shown in Fig. 3. The former is to partion the decision (or task) on a relatively high level (Level 1) of the system and distribute it to several sub-decisions at a low level (Level 2) of the system. The latter is in the opposite direction, namely, to integrate the results of low-level sub-decisions and synthesize them as the output of the high-level decisions. To

keep consistent with the definition of a level-by-level partitioned hierarchy (as shown in Fig. 1), in this paper we capture vertical interactions between every two neighbouring levels, e.g., Level 1 and Level 2. Decisions across levels, e.g., Levels 1 and 3, can have indirect interactions in a hierarchy by pasing their influences level by level, i.e., from Level 1 to Level 2 then to Level 3. We don’t model direct interaction across levels because otherwise the decision hierarchy will become a flat and disordered network, which is not the focus of this paper. In top-down partition, the relationship between the high-level decision and the low-level decisions is represented using a function mapping written as X = fp (X1 , . . ., Xn )

(1)

where X is the input of of the high-level decision, X1 , . . ., Xn are the inputs of the low-level decisions, fp is the partioning function which captures how X is partitioned into multiple sublevel parameters. For example, suppose the thickness of a three-layer composite beam is the input (variable) of a high-level decision, then it can be partitioned into three sublevel variables – thickness of the top, middle, and the bottom layers of the composite beam, which are distributed to three design groups. In bottom-up synthesis, similarly, the relationship between the low-level decisions and the high-level decision can be represented as Y = fs (Y1 , . . ., Yn )

(2)

where Y is the output of the high-level decision, Y1 , . . ., Yn are the outputs of the low-level decisions, fs is the synthesizing function that captures how the behavior of subsystems give rise to the behavior of the parent system. In the three-layer composite beam example, the outputs of the low-level decisions are the performance measures such as the modulus of the three different layers of material, and the output of the high-level decisions are the mudulus of the beam. Top-down partition and bottom-up synthesis are two fundamental interaction patterns that are repeated between every two levels along the vertical direction of the system partition hierarchy. These two patterns convey the design information flow from the top to the bottom, and from the bottom to the top. 3.2. Horizontal Interaction Horizontal interactions among decisions denote, for example, the working relationships among designers who are concurrently designing multiple subsystems (e.g., the material of a gear and the dimension of a gear) at the same level of the hierarchy. The patterns of horizontal interaction are classified using two dimensions: decision coupling and interaction strength, as shown in Fig. 4. The horizontal axis represents the interaction strength which is classified into three discrete states: no interaction, one-way interaction, and two-way interaction. The vertical axis represents the decision coupling (according to decision types, namely, the selection DSP and the compromise DSP) that is classified into three categories: selection-compromise, selection-selection, and compromise-compromise. The two axes form a 3 × 3 matrix which represents nine different interaction patterns, each pattern has a specific type of coupling and a level of interaction strength. It is noted that there is no interaction in the three patterns of the first column of the matrix (P1–P3), which means no information flow between decisions and is not the focus of this paper. The other six patterns (P4-P9) have at least one information flow between deci  sions, represented as Y1 or Y2 in Fig. 4, which denotes that a subset of the output of one decision feeds into its counterpart in the coupling. This captures the link between two groups of designers at   the same level. The content of Y1 and Y2 depends on the type of the exporter decision and are categorized as:

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

5

Fig. 3. Vertical interaction between decisions at two level

Fig. 4. Horizontal interaction between decisions

• Attribute values, if the exporter decision is a selection decision. • Variable and/or goal values, if the exporter decision is a compromise decision. Mathematically, decisions with one-way and two-way interactions are formulated in a combined compromise DSP (selection DSPs are transformed to compromise DSPs with Boolean variables) format and solved concurrently (Smith et al., 1987). For example, the two-way selection-compromise interaction pattern (P9 in Fig. 4) is mathematically formulated in a form shown in Fig. 5. DSP 1 and DSP 2 are strongly coupled because the constraints, goals, and merits of the alternatives are a function of the variables from both DSP 1 and DSP 2. As indicated by the red rectangles in the figure, the interaction between the two DSPs is two-way: the value of selection variable S has impacts on DSP 1, and meanwhile, the value of compromise variable X has impacts on DSP 2. In the DSP Technique, coupled DSPs are solved concurrently by minimizing the preemptive deviation function lexicographically (Ahmed et al., 2014). In the preemptive formulation, the goals are ranked lexicographically and an attempt is made to achieve a more important goal (at a higher level) before other goals are considered. The entired solv-

ing process is acheved using the lexicographic minimization of the deviation function with m levels where m is defined by the user. Lexicographic minimization involves minimization of the highese levels fist and minimizing the lower levels only if the higher levels can be kept constant. It should be noted that interactions (or dependencies) are only defined among decisions in a decision hierarchy instead of inside individual decisions. Within each individual decisions, all the decision vriables, i.e., the X’s, must be independent so as to support the exploration of the solution space independently. This is to keep in accordance with the definition of variables in DSPs. Parameters that are dependent on X’s can be defined as variables, constraints, or goals that are controled by other decisions of vertical or horizontal relationships with the current decision. 3.3. Classification of Decision Interaction Patterns The classification scheme used in Table 1 is three-dimensional, namely, decision types (selection and compromise), directionality (vertical and horizontal), and strength (weak and strong). The first two patterns (Partition and Synthesis) are vertical interactions, the

6

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

Table 1 Classification of decision interaction patterns No.

Interaction Pattern

Direction

Information Flow Content

Description Partition of the high-level decisions into low-level decisions in a top-down direction: distributing the variables and alternatives. Synthesis of results of low-level decisions as the output of high-level decisions. The attributes of sDSP2 depend on a subset of the attributes of sDSP1. The goal and constraint functions of cDSP2 depend on a subset of the variables and/or goals of cDSP1. The goal and constraint functions of the cDSP depend on a subset of the attributes of the sDSP. The attributes of the sDSP depend on a subset of the variables and/or goals of the cDSP. Two sDSPs have shared attributes. Two cDSPs have shared variables.

1

Partition

Vertical

Variables, alternatives

2

Synthesis

Vertical

Variable values, selected alternatives

3

Weak Selection-Selection

Horizontal

Attribute values

4

Weak Compromise-Compromise

Horizontal

Variable and/or goal values

5

Weak Selection-Compromise

Horizontal

Attribute values

6

Weak Compromise-Selection

Horizontal

Variable and/or goal values

7 8

Strong Selection-Selection Strong Compromise-Compromise Strong Selection-Compromise

Horizontal Horizontal

Attribute values Variable and/or goal values

Horizontal

Attribute values, variable and/or goal values

9

Fig. 5. Mathematical formulation of the two-way selection-compromise interaction pattern (Sharma et al., 2019)

remaining seven patterns are horizontal interactions. The strength of interaction is defined by whether it is one-way, two-way, or no interaction. When there is no interaction the strength is zero, one-way interaction is defined as weak interaction and two-way is

The goal and constraint functions of the cDSP depend on a subset of the attributes of the sDSP; The attributes of the sDSP depend on a subset of the variables and/or goals of the cDSP.

defined as strong interaction (Smith et al., 1987). The weak interaction between selection and compromise decisions (P6) is classified into two patterns (No. 5 and No. 6 in Table 1) because the content of the information flow from the selection to the compromise (sDSP2 to cDSP1) is different from the information flow in a reverse way (cDSP1 to sDSP2). In Table 1, we specify the name, direction, and information flow of each pattern. The content of information flow varies from pattern to pattern due to the difference in coupling, interaction strength, and interaction direction between patterns. For example, in the (either weak or strong) selectionselection interaction pattern, the information flows between two decisions are purely the attribute values because attributes are the key input of the merit function of alternatives in selection (DSPs). In the (either weak or strong) compromise-compromise interaction pattern the information flows between two decisions are purely the variable and/or goal values because variables and goals are the key input of the constraint and goal function in compromise DSPs. In the strong selection-compromise interaction pattern, the information flows are a mix of attribute values, variable, and goal values because the interaction is one-way and the flow exporters include both selection and compromise DSPs. In the weak selection-compromise interaction pattern, the information flows are attribute values because the interaction is one-way and the flow exporter is the selection DSP. In the weak compromise-selection interaction pattern, the information flows are variable and/or goal values because the interaction is one-way and the flow exporter is the compromise DSP. In the partition interaction pattern, the information flows are variables and/or alternatives (represented by a set of vectors of attributes) because the high-level decision can be a hybrid format of compromise and selection DSP. Same information flows in the synthesis interaction pattern because the low-level decisions may include both selection and compromise DSPs. These nine patterns represent the basic links that connect a set of decisions in the design of complex engineered systems and can be used to describe the channels by which different groups of designers are communicating with each other. In Section 4, we present an ontology to formally define the interaction patterns in the context of decision networks.

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

4. Ontology for Modeling of Decision Interactions To formalize knowledge of decision interaction, we develop a decision interaction ontology (DIO) using formal web ontology language (OWL)/resource description framework (RDF) representations in the Protégé tool (Musen, 2015). OWL/RDF ontology has superior performance in terms of expressiveness (richer model) over the structure of relational databases, that is geared towards improving performance in data retrieval. The Protégé tool provides a graphical user interface for creating OWL/RDF ontologies which includes defining the classes and class hierarchy (the concepts of a domain), object properties (relationships among concepts), data properties (numeric attributes of concepts), populating instances of the classes, knowledge query, and semantic rule-based reasoning. In this paper, we utilize the ontology definition, population, and query functionalities of the Protégé tool. DIO is defined as an ontology because of its following features: • Interoperability. the DIO ontology we propose in this paper is an information model for a Knowledge-Based Platform for Decision Support in the Design of Engineering Systems (PDSIDES) (Ming et al., 2018). We define an engineering system as a combination of components that work in synergy to collectively perform a useful function. Engineering systems require inputs from several of the traditional disciplines of engineering, rather than just one discipline. The three terms (at the top level) – Process, Link, and Node (see Fig. 6-a) are defined in a common sense for representing processes, networks, and workflows, which facilitates data interoperation between PDSIDES and other CAD, CAM, CAPP systems. • Explication. Nine interaction patterns are identified in the DIO ontology to make it explicit for the knowledge related to decision interactions. • Formalization. The terminology related to decision interactions is formally defined as classes and properties in the DIO ontology. • Integration with other ontologies. The DIO ontology is tightly integrated with the selection and compromise decision ontologies (Ming et al., 2017; Ming et al., 2016) for representing decision-based design processes. All the terms of the selection and compromise decision ontologies are reused in the DIO ontology. The DIO ontology can also be integrated with the Process Specification Language (PSL) ontology proposed by the National Institute of Standards and Technology (NIST) (Grüninger, 2004), by mapping Class Decision in DIO to Class Activity in PSL. 4.1. Definition of Classes and Properties The DIO ontology is developed with a set of (both high- and low-level) entities which are enumerated based on the important knowledge that is expressed in the context of a general decision network. In the Protégé tool, these entities are represented as a hierarchy of classes, as shown in Fig. 6-a. The class on the top is Process, which stands for a decision-based design process which may involve a network of decisions. Class Process has two subclasses – Link and Node, which are the building blocks (elements) of a network. Node represents the decisions made in a design process, and Link represents the dependencies between decisions. Detailed information of the Node class in the context of the DSP Technique is documented in (Ming et al., 2017; Ming et al., 2016) and thus not repeated in this paper. Our focus is on the Link class and its subclasses, as shown within the rectangle in red. Interaction and Flow are the two subclasses of Link. Flow captures the information that flows from one node to another over a link. Interaction captures the interacting patterns between two coupling nodes. According to the classification in Table 1, the Interaction class is divided in two subclasses – Horizontal and Vertical, which are further divided

7

into seven specific horizontal interaction patterns and two specific vertical interaction patterns, respectively. The relationship diagram of the core classes is shown in Fig. 6b. At the top of the figure is a hierarchical decision network to be represented, and at the bottom are the classes and the relationships among them for representing the decision network. The whole decision network is abstracted as Class Process, and its two basic elements are abstracted as Classes Link and Node. The Process class is related to its elements by object properties hasLink and hasNode. To link to other nodes and create a hierarchical decision network, the Node class is referred to itself by three object properties – hasChild hasParent, and hasSibling, wherein the first two are essential for vertical interactions and the third is essential for horizontal interactions. Class Link is related to Class Node by two object properties – hasImporter and hasExporter, which capture the direction of information flow on a specific link. Class Interaction (a subclass of Link) inherits the properties of hasImporter and hasExporter, and is related to the Flow class by object property hasFlow. By property isSubsetOf, the Flow class is related to the Input and Output classes (which are properties of the Decision class). This is consistent with the fact that a portion of (critical, not all) information is flowing from one decision to another in coupled design scenarios. The formal definition of the core classes is shown in Table 2. The formal definition of the object and data properties is shown in Table 3. For conciseness, only the data properties of the Flow class are presented. The relationships represented by the object properties in Table 2 are classified into three types: “one-toone”, “one-to-many”, and “one-to-X”. “one-to-one” means that an instance can link to only one instance by that property, “one-tomany” means that it can link to multiple instances, and “one-to-X” means that it can link X (a certain number) of instances. For example, Property hasParent represents “one-to-one” relationship because a decision (or node) is defined to have only one parent decision (or node) in synthesis interaction pattern. Property hasChild represents “one-to-many” relationship because a decision is defined to have multiple (one or more than one) sub-decisions in the partition interaction pattern. Properties hasImporter and hasExporter represent “one-to-X” relationship because in an interaction pattern an information flow can have at most two (X means two in this case) importer or exporter decisions. Data properties contentType, unit, and value are used to represent the specific information flows in an interaction pattern. 4.2. Instantiation and Population of Data To illustrate how knowledge is captured in the decision interaction ontology, assertions about instances in the knowledge base are shown in Fig. 7. The classes and their associated properties form a structure for storing knowledge in the knowledge base. Based on the structure, instances of classes are populated. Fig. 7 is an example of the instantiation of the weak selection-compromise interaction pattern that happens between the gear material design team and gear dimension design team. Since it is a weak interaction, the information flow is one-way, namely, from the material design team to the dimension design team. This knowledge (semantic relationship) is captured by two properties hasExporter and hasImporter that point to the two decision instances – GearMaterial and GearDimension, respectively. The contents of the flow are captured by property “hasFlow” that point to the specific Flow instances: Strength and Density, which are the attributes of the gear material alternatives and also the parameters for gear dimension design. Each Flow instance stores its data origin by property isSubsetOf and the specific data by properties contentType, unit, and value. For example, Density is a subset of the attributes of material alternative AISI4140, and the numeric value that “imports” to the material dimension design team is 7850.0 Kg/m3 . By this interaction instance,

8

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

Fig. 6. Class hierarchy and relationship diagram of the core classes

Table 2 Definition of classes Classes

Definition

Process

An abstraction of a set of activities that interact to produce a result. In the DBD context, a process represents a set of decisions that interact to produce a shared design specification. An abstraction of the activities in a process. In the DBD context, a node represents a decision to be made. An abstraction of the interactions between activities. In the DBD context, a link representes the interaction between two decisions. A dependency or interdependency relationship between two decisions. Detailed definition of the interaction patterns is given in Table 1. An activity in which designers make judgements about design. A decision made to determine the “right” values of design variables to describe the best satisficing solution with respect to constraints and multiple goals. A decision made to make a choice amongst a number of possibilities taking into account a number of measures of merit of attributes. An abstraction of the information communicated from a decision to another decision. An abstraction of the information in-taken by a decision to produce a result. An abstraction of the resulting information produced by a decision.

Node Link Interaction Decision Compromise Selection Flow Input Output

the channel of the communication between the two teams and information they communicate are captured. 4.3. Linkage of Decision and Interaction Instances Once decisions and the associated interactions are populated as instances using specific data based on the definition of the ontology, all the instances are linked in a RDF network which provides the paths for knowledge retrieval. In Fig. 8, we show a RDF graph for the weak coupling between the design of gear materials and dimensions. GearMaterial and GearDimension are two decisions. The former is a selection decision and the latter is a compromise deci-

sion. The interaction between them is captured by WeakCoupling, which belongs to a weak selection-compromise pattern. GearMaterial and GearDimension are interacting in a way that the output of the former comprises the input of the latter. Two attributes – Density and Strength of the selected alternative (e.g., AISI8620) in GearMaterial influence GearDimension since Density and Strength are two parameters for calculating the constraints and goals (e.g., weight, torque, bending stress and contact stress) of GearDimension. The interaction is a weak (one-way) interaction because only the influence of GearMaterial to GearDimension is considered, while the influence of GearDimension to GearMaterial is not considered. In Fig. 8, we limit the level of detail of the RDF graph to the instances

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

9

Table 3 Definition of the object and data properties Object Properties

Definition

A process has multiple members of the Node class by the “hasNode” property Has node A process has multiple members of the Link class by the “hasLink” property Has link Has child A node has multiple members of the Node class by the “hasChild” property Has parent A node has only one member of the Node class by the “hasParent” property A node has multiple members of the Node class by the “hasSibling” property Has sibling Has input A node has only one member of the Input class by the “hasInput” property A node has only one member of the Output class by the “hasOutput” property Has output A link has one or two members of the Node class by the “hasImporter” property Has importer A link has one or two members of the Node class by the “hasImporter” property Has exporter Has flow An interaction has multiple members of the Flow class by the “hasFlow” property A flow has only one member of the Input class by the “isSubsetOf” property Is subset of For object properties of the selection and compromise decisions, see (Ming et al., 2017; Ming et al., 2016). Data Properties Definition String. Captures the type of content in the flow. ContentType Unit String. Captures the unit of the flow. Value Double. Captures the numeric value of the flow. For data properties of the selection and compromise decisions, see (Ming et al., 2017; Ming et al., 2016).

Fig. 7. Storing semantic and parametric data with assertions

Fig. 8. RDF graph for the weak coupling between the design of gear materials and dimensions

of alternatives, variables, constraints, and goals. Detailed information of these instances are not shown due to the space of figure. Knowledge represented in an ontological RDF graph facilitates the understanding of how decisions influence on another.

5. Example: Capturing the Decision Interaction Knowledge in the Design of a Gearbox Gearboxes are power transmitting units that are widely used in industrial applications such as automobiles, machine tools, convey-

10

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

Fig. 9. One-stage reduction gearbox

ors, and elevators, etc. The working principle of a gearbox is that a series of gears are integrated within a housing (box) to achieve a gear ratio between the driver and driven shaft so as to increase torque while reducing speed. A gearbox can be partitioned into subsystems – gears and shafts by which the speed reducing (or torque increasing) function is realized. Gears and shafts, again, are partitioned into their materials and dimensions by which the power transmitting function is realized. A gearbox can have multiple gears and shafts integrated in the box. For simplification and ease of explanation, we focus on a one-stage reduction gearbox within which two gears are mounted and are connected to an input shaft and output shaft, as shown in Fig. 9. In this section, we test the utility of the proposed ontology in capturing, retrieving, and visualizing the decision interaction knowledge by a gearbox design example. First, in Section 5.1 we analyze the decisions and their interaction patterns. Then in Section 5.2, we show how these decisions and interaction patterns are captured and retrieved in the ontological context. Finally, in Section 5.3 we implement the ontology in PDSIDES and demonstrate the visualization of the knowledge related to the decisions and interactions in the design of the gearbox. 5.1. Formulation of DSPs and Analysis of Decision Interactions The design of a gearbox (first-level decision) can be partitioned into a set of second-level decisions (e.g., the design of a gear and the design of a shaft) and third-level decisions (e.g., the design of the gear material and the design of the gear dimension). Due to the dependencies among components in the gearbox structure, there are interactions among the decisions in the design process, including both vertical and horizontal interactions. We formulate seven DSPs which represent the decisions to be made at different levels, as shown in Fig. 10. The selection decisions are formulated in a cDSP format to facilitate integration. At Level 1 (DSP ), 1 designers explore high-level variables including overall weight, overall height, output torque of the gearbox, and the materials of the gear and shaft. The objective is to minimize the distance between these variable values and the overall targets. At Level 2, high-level design variables are distributed to gears and shafts separately. For example, the weight variable is separated into weight of gears and weight of shafts, which are explored in the gear DSP (DSP ) 2 and shaft DSP (DSP ) 3 respectively. At Level 3, second-level variables are further distributed to the dimensions and materials of gears and shafts (DSPs – 4 ). 7 For example, the weight of gears is distributed to the module, face width, number of teeth which are variables of DSP , 4 and to gear material alternative which is a variable of DSP . 5 The seven DSPs are supposed to be solved

Fig. 10. Formulation of DSPs in the design of a gearbox

concurrently, therefore their deviation variables are formulated in one deviation function in a preemptive way to be minimized lexicographically. There are both vertical and horizontal interactions among the seven DSPs formulated in Fig. 10. To capture the knowledge of the interactions and populate them as ontology instances, we identify the interactions as follows: • Partition 1: DSP  1 is partitioned into DSPs  2 and . 3 Specifically, Variable W is partitioned into Variables WG and WS ; Variable T

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

•

•

•

•

•

•

•

•

is partitioned into Variables TG and TS . Variables X, Y, and H are passed down without change. Partition 2: DSP  2 is partitioned into DSPs  4 and . 5 Specifically, Variables WG , TG , and H are partitioned into Variables m, b, and z; Variable X is passed down without change. Partition 3: DSP  3 is partitioned into DSPs  6 and . 7 Specifically, Variables Ws and Ts are partitioned into Variable D (diameters) of the shafts. Variable Y is passed down without change. Synthesis 1: DSPs  2 and  1 Specif3 are synthesized into DSP . ically, Variables WG and WS are integrated to Variable W by system goal: WG + WS + dw - - dw + = W; Variables TG and TS are integrated to Variable T by system goal: TG + dGT - - dGT + = T. Synthesis 2: DSPs  2 Specif4 and  5 are synthesized into DSP . ically, the calculated weight, torque, and height of gears are matched to the targets by three compromise goal equations; the calculated (normalized) merits of the gear material alternatives are matched to 1 by the gear material selection goal equation. Synthesis 3: DSPs  6 and  3 Specifi7 are synthesized into DSP . cally, the calculated weight, torque of shafts are matched to the targets by two compromise goal equations; the calculated (normalized) merits of the shaft material alternatives are matched to 1 by the shaft material selection goal equation. Strongly coupled compromise-compromise: compromise DSPs  2 and  3 are strongly coupled. Specifically, the torque of gears TG and the torque of shafts TS depend on each other and are matched by system goal equation: TG + dT - - dT + = Ts. Strongly coupled selection-compromise 1: compromise DSP  4 and selection DSP  5 are strongly coupled. Specifically, properties density, strength, and Young’s modulus of the selected gear material alternative have effects on the calculation of bending stress, contact stress, weight, and torque in the gear dimension compromise decision; the system goal – weight of the gear dimension compromise decision has effects on the cost (attribute) of the gear material selection decision. Strongly coupled selection-compromise 2: compromise DSP  6 and selection DSP  7 are strongly coupled. Specifically, properties density, strength, and Young’s modulus of the selected gear material alternative have effects on the calculation of shear stress, weight, and torque in the shaft dimension compromise decision; the system goal – weight of the shaft dimension compromise decision has effects on the cost (attribute) of the shaft material selection decision.

5.2. Capturing and Retrieving Knowledge Using Ontology Based on the DSPs formulated in Section 5.1 and the associated interactions, specific instances (individuals) of Class Decision and Interaction are populated according to the ontology structure defined in Section 4.1. An ontology graph of the relationships among the populated instances is shown in Fig. 11. The graph is a three-level hierarchical network where the blocks stand for the instances (including Decision, Interaction and Flow), and the directed arcs stand for the relationship between instances (including hasExporter, hasImporter, and hasFlow). Knowledge about a decision’s own properties such as system variables, constraints, goals, attributes, alternatives, etc. is captured in the Decision instances (e.g., “Gear DSP”). Knowledge about the dependency among decisions is captured in the Interaction instances (e.g., “strong compromise compromise”) where the content, origin, and destination of the information flow are represented by properties hasFlow, hasImporter, and hasExporter, respectively. Specific data of the information flow is stored in the Flow instances. In Figures 10, 11 and 12, Level 1 is the gearbox DSP, Level 2 are the gear DSP and the shaft DSP, Level 3 are the gear dimension cDSP, gear material sDSP, shaft dimension cDSP, and the shaft material sDSP. DSPs between levels interact vertically by patterns Partition

11

and Synthesis. For example, the gearbox DSP interacts with the gear DSP and the shaft DSP through “partition 1”. DSPs at the same level interact horizontally by the coupling of selection and compromise decisions. For example, the gear dimension cDSP interacts with the gear material sDSP through “strong selection-compromise 1”, the exchanging data includes Density, Strength, and Young’s modulus from the gear material sDSP, and the weight from the gear dimension cDSP. The ontology graph in Fig. 11 represents the semantic relationships among the instances, which facilitates retrieving the knowledge stored in the ontological knowledge base using semantic-based languages such as the Semantic Query-Enhanced Web Rule Language (SQWRL) (O’Connor and Das, 2009). SQWRL supports reasoning with ontologies and is represented by a conjunction of predicates in the antecedent that leads to the consequent. The predicates are represented in the form of Predicate(?x1,?x2,. . .), where Predicate stands for the classes or the object properties of an ontology, and? x1,? x2 are the instance variables related to Predicate. For example, in the DIO ontology context, Decision(?d) means any instance of the Decision class with a variable name? d; and hasImporter (?d1,?d2) means any instance of property hasImporter with a subject named? d1 and an object named? d2. Based on predicates in the antecedent, the consequent is to show query results by using conjunction of SQWRL operators. For example, given the rule of hasImporter(?d1,?d2)> sqwrl:select(?d1,?d2) the reasoner will return all the decision instance pairs that are matched by property hasImporter. Since the gearbox design knowledge (both decisions and interactions) are captured in DIO ontology, designers can query the knowledge that they are interested in using SQWRL rules. Equation (3) is an SQWRL rule for retrieving all the vertical interaction patterns in the design of a gearbox.

The results obtained by executing Equation (3) in Protégé SQWRL Tab is shown in Fig. 12. The second column of the table represents the vertical interaction instances (including partition and synthesis). The first and third columns represent the decision instances (DSPs) that interact vertically, and are marked as “importer” and “exporter” respectively in terms of information flow. In Fig. 12, the vertical decision interactions are presented in a structured way, in which we can see two DSPs are vertically interacting by Pattern partition or Pattern synthesis. For example, the interpretation of the first two rows is: the gearbox DSP is partitioned into shaft DSP and gear DSP. The interpretation of the third and fourth rows is: the gear DSP is partitioned into gear material sDSP and gear dimension cDSP. If the predicate Vertical in Equation (3) is replaced with Horizontal, it can be used to retrieve all the horizontal interaction patterns in the design of a gearbox. Since the parametric interaction data is captured in the DIO ontology, designers can also retrieve this data using SQWRL rules. Equation (4) is the rule for query of the specific data that flows between the gear dimension cDSP and the gear material sDSP.

The results obtained by executing Equation (4) is shown in Fig. 13. The fist column stands for the names of the retrieved flow instances, the second to the forth column stand for the content types, units and values of the flow instances respectively. We see in the first column that there are four parameters that flow between the gear dimension cDSP and the gear material sDSP, namely, Den-

12

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

Fig. 11. Ontology graph of DSP and interaction instances for gearbox design

Fig. 12. Query results of the vertical patterns

Fig. 13. Query results of the flow data

sity, Strength, Weight and Young’s Modulus. Density, Strength, and Young’s Modulus are type of “AttributeValue” which means they are flowing from the gear material sDSP to the gear dimension cDSP. Weight is type of “GoalValue” which means it is flowing in the reverse way. Since the formulated DSPs are not yet executed, the values of the four parameters are assigned to 0. The values will change after the DSPs are executed.

5.3. Visualization of the Decisions and Interaction Knowledge in PDSIDES The DIO ontology is implemented in PDSIDES to facilitate designers designing decision workflows in a visual and intuitive way, as shown in the screenshot of Fig. 14. PDSIDES is anchored in a web-based client-server architecture, designers can get access to it by internet. Designing decision workflows in PDSIDES is enabled

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

13

Fig. 14. Visualization of the Interaction Knowledge in PDSIDES

by: 1) two core icons – Selection and Compromise (i.e., the two subclasses of Decision in the DIO ontology) that represent the nodes in a decision workflow, 2) two types of arrows – the horizontal arrow (in red, corresponding to the class of Horizontal in the DIO ontology) that represents horizontal interactions and the vertical arrow (in black, corresponding to the class of Vertical in the DIO ontology) that represents vertical interactions between decisions in a decision workflow, and 3) a canvas where designers can draw a graph using the icons and arrows to represent the overall structure of the decision workflow. When designers drag an icon or an arrow to the canvas, a new decision or interaction instance is instantiated. To specify the new instances, designers are provided with templates. The panels on the right-hand side of Fig. 14 are the template structures for the specifications of selection decisions (Panel “”), 1 horizontal interactions (Panel “”, 2 similar to the vertical interactions), and compromise decisions (Panel “”). 3 In the context of the gearbox design example, the knowledge related to the selection of gear materials such alternatives, attributes, and preferences etc. is displayed in Panel “”, 1 the knowledge related to the compromise decision for gear dimension design such as variables, parameters, constraints, goals, and preferences etc. is displayed in Panel “”, 3 the knowledge of the interaction between the gear material decision and gear dimension decision such as importer, exporter, and information flows etc. is displayed in Panel “”. 2 The knowledge related to other nodes in the gearbox design decision workflow can be displayed using the same templates. In PDSIDES, designers can also retrieve the archived knowledge using an advanced search tool without writing query languages, as shown in Fig. 15. In the advanced search tool, designers first choose the data scope from three options – decision, interaction, and workflow. Then they can indicate the information they want to query within that data scope by configuring the query conditions in the table on the right of the tool. PDSIDES will translate their configurations into query languages (in this paper is SQWRL), retrieve the wanted data, and return the data to designers. What is shown in Fig. 15 is an example of querying all the horizontal dependencies of Decision “G Di DSP” (the gear dimensions design DSP) in the gearbox design hierarchy.

Fig. 15. Advanced Search in PDSIDES

Since the icon-based decision workflow is anchored in the DIO ontology, it has (but is not limited to) the following three salient features: • Flexibility. Using the icons and templates, designers can draw various decision workflows based on their own expertise to accommodate design requirements. This flexibility is embodied in two levels – workflow structure level and node/link level. On the workflow structure level, designers can configure/reconfigure the topology of the decision workflow using different combinations of decisions and interactions. For example, the decision workflow for the design of a gearbox depends on the partitioning method, and the decision workflow will change if the partitioning method changes. Designers can rapidly reconfigure the decision workflow to accommodate the changes in the partitioning method. On the node/link level, designers can add/delete/modify information associated to the decisions and interactions by editing the templates. For example, if weight is no longer considered in the gear dimension decision, then designers can delete a goal from the compromise template and delete a flow from the interaction template.

14

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

• Reusability. Since the classes (terms) and properties are formally and explicitly defined in the DIO ontology and are organized using templates, the archived knowledge of the decisions and interactions are reusable in variant design scenarios. Same as flexibility, reusability is also embodied in both workflow structure level and node/link level. When the requirements change, designer don’t need to design the associated decision workflow from scratch, they can retrieve similar existing decision workflows from the knowledge base, build a variant decision workflow by reusing the structures and/or nodes and links of existing decision workflows. • Executability. Since the DIO ontology is represented using OWL/RDF schema which is computer interpretable, the decision workflows drawn by designers are executable to generate solutions. This is realized by integrating the DIO ontology to a problem solver DSIDES (Reddy et al., 1996) for Decision Support Problems. The executability of decision workflows enables designers to explore the design space in early design stages, which is very important for them to compare and identify appropriate decision workflows that might lead to satisficing solutions. 6. Industry Applications In this section, we apply the ontological method developed in this paper to solve industry problems. We present two industry examples, namely, the hot rod rolling process chain design example which is an extension of the problem considered by Nellippallil and coauthors (Nellippallil et al., 2018; Nellippallil et al., 2017), and the composite structure design example which is an extension of the problem considered by Pathan and coauthors (Pathan et al., 2019). The rationale for selecting the former is that it represents one-level, sequential decision-based design problems, and the rationale for selecting the latter is that it represents multilevel, hierarchical decision-based design problems. Both of them are real industry problems contributed by our industrial partner – the Tata Consultancy Services in India. In Sections 6.1 and 6.2, we briefly discuss how the interaction knowledge as well as the decisions workflows in these two problems are captured using the DIO ontology and visualized using icon-based graphical diagrams in the PDSIDES platform. 6.1. Hot Rod Rolling Process Design From the raw material to the final gear product, the material goes through multiple unit operations. A round rod is produced after passing the raw steel through several manufacturing processes such as casting, reheating, rolling, and cooling. This round rod forms the input material for gear production. The chemical composition of the steel including the segregation of alloying elements, the deformation history during rolling, the cooling after rolling, and the microstructure generated define the end properties of the rolled product. The presence of large numbers of design variables, constraints and bounds, conflicting goals, and sequential information/material flow during material processing makes the steel rod making process chain highly complex. In PDSIDES, we capture the design of the hot rod rolling process chain as a goal oriented, sequential, inverse design decision workflow, as shown in Fig. 16. Designers start with the end goals that need to be realized for the product as well as process and then design the preceding stages to satisfy these end goals as closely as possible by exploring the design space. In this case the end goals are the mechanical properties of the rod, e.g., maximizing yield strength and tensile strength, and these goals are determined by parameters such as ferrite grain size, phase fractions and composition, etc., which are the output parameters after cooling. Similarly, the output parameters after cooling are determined by parameters

such as austenite grain size and composition that are the output parameters after rolling. Designers formulate cDSP to represent the decision at each pass of the process chain, and connect the decisions in a sequential and inverse manner (rod → cooling → rolling → reheating → castering) using decision interactions. In this case all the interactions are weak compromise-compromise interactions since there is only one-way information flow between decisions at every two passes. The information flows are captured by the arrowed links in Fig. 16, which represent that the design variables of the preceding cDSP become the goals of the succeeding cDSP.

6.2. Composite Structure Design Composite materials are used to fulfil the functional (e.g. mechanical, physical properties) as well as nonfunctional (e.g. chemical, biological, environmental properties) requirements of the products. Composite materials are combination of two or more materials combined using various manufacturing techniques to produce superior performance. Large number of material alternatives and multiple manufacturing processes coupled with the complex relationships among the different selection parameters often make material selection and sizing of composites a difficult task. Another challenge in the design of composite structures is that they are multiscale in nature, their mechanical properties depend on the microstructure, the constituents and their arrangements. For example, a sandwich composite beam consists of a light weight soft core sandwiched between two rigid skin, as shown in Fig. 17. Functional requirements of the sandwich are fulfilled by having stiff skin and soft core. Skin carries bending stresses, while the core carries shear stresses. Typically, skins are made up of thin metallic sheets or fiber reinforced composites which offer excellent in plane properties. Cores are usually made up of honeycomb, open and closed cell foams which offer high specific shear stiffness. In PDSIDES, we capture the design of a sandwich composite beam as a multilevel coupled decision workflow. On the top level is the holistic cDSP the represent the overall decision of the specification of the composite beam. The top-level decision is then partitioned into three second-level decisions, namely, selection of the skin material, selection of the core material, and the sizing of the overall structure. Selection of the skin material is to choose a combination of fiber and matrix from a material pool, which is further coupled with a third-level decision – the determination of the ratio for mixing fibers and matrix. Selection of the core material is coupled with a third-level decision, that is, the determination of the dimensions of the honeycomb which is the micro unit of the core material. There are six key decisions in the design of the composite beam, which are represented using cDSP and sDSP constructs. The dependencies (information flows) among these decisions are captured by the arrowed links in Fig. 17. Since the decision workflow is multilevel and both selections and compromise decisions are involved, the interaction patterns include top-down partitioning, bottom-up synthesis, strong selection-compromise coupling. Therefore it is highly coupled hierarchical design problem.

6.3. Discussion In Sections 6.1 and 6.2, we showcase two industry applications, namely, the design of a hot rod rolling chain and the design of a composite structure (sandwich composite beam) to demonstrate the value of the DIO ontology to industry. It is shown that designers are able capture knowledge related to both sequential and multilevel decision workflows in the design of complex products and systems. In this section, we discuss three other aspects regarding to the application of DIO ontology in industry as follows.

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

15

Fig. 16. Capturing the Decision Workflow for the Design of Hot Rod Rolling Process Chain

Fig. 17. Capturing the Decision Workflow for the Design of a Sandwich Composite Cantilever Beam

• Complexity assessment. It is seen a growing complexity in today’s manufactured products, which will result in more complexity in the decision workflows for designing them. It is important to have a means to assess the complexity in decision workflows so as to support the decision of whether to simplify them or not. In the context of the DIO ontology, complexity assessment is supported by the calculation of the numbers of: 1) levels, 2) nodes (decisions), 3) links (interactions), 4) two-way strong links, as well as the percentage of two-way strong links in a decision workflow. Since the DIO ontology is represented using OWL, it is convenient to calculate those numbers and percentages. In terms of the decision of workflow decoupling and simplification, it is recommended to use the value-of-information

based indice proposed by Panchal and coauthors (Panchal et al., 2009). • Decision workflow execution. After the decision workflow is captured, it is important to execute the workflow, solve the decision problems in the workflow, and generate solution results so as to facilitate exploring satisficing designs of the products or systems. In the DIO context, the solution of DSPs is supported by a tailored solver DSIDES which is based on the Adaptive Linear Programming Algorithm (Mistree et al., 1993). Since there may be multiple DSPs in a workflow, the solution strategy is dependent on the coupling strength between DSPs, which is described as follows: 1) if there is no interaction, then the DSPs are solved independently; 2) if the interaction is one-way, then the succeeding

16

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145

DSP must be solved considering the equations that governs the influence from the preceding DSP; 3) if the interaction is two-way, then the DSPs must be integrated as one and solved concurrently. • New product design. The application of the DIO ontology to new product heavily depends on designers’ expertise on partitioning the top system requirements and decisions into multilevel decisions. In new product design the partition hierarchy of design decisions is usually unknown, however, expert designers can identify the hierarchy by repetitively performing the Patterns of Top-down Partition and Bottom-up Synthesis (which are discussed in Section 3.1) until the high-level parameters cannot be furthered partitioned and the hierarchy is good for decision making. Once the decision hierarchy is clearly structured, designers can capture that expert knowledge in the PDSIDES platform using the DIO ontology for future reuse.

7. Closure Design of complex engineered systems usually involves a set of decisions to be made in terms of the systems themselves and their subsystems in a hierarchy. Due to the dependencies in the hierarchy, there are both vertical and horizontal interactions among decisions. Decision interactions are the links that connect different decisions in a hierarchical decision-based design process. Representing and capturing the knowledge related to these links are very important for designing decision-based design processes. In this paper, we identify nine interaction patterns and propose an ontology – DIO to formalize the knowledge related to these patterns in the decision-based design context. The identified interaction patterns include two vertical patterns that represent the partition and synthesis relationships among decisions at different levels of the hierarchy, and seven horizontal patterns that represent the coupling relationships between two basic types of decisions – selection and compromise (formulated as sDSP and cDSP) at the same level of the hierarchy. The DIO ontology is an integrated knowledge model with a formal representation of both decisions and their associated interactions using OWL/RDF scheme. The utility of the DIO ontology is illustrated through a one-stage reduction gearbox design example. We observe from the results that the DIO ontology can be used to:

i) facilitate the capture of the interactions in a multi-level hierarchical decision network, ii) facilitate the retrieval of knowledge about the interactions and the associated information flows, iii) support the designing of decision workflows for complex systems with its flexibility, reusability, and executability when implemented in the PDSIDES platform.

Since the DIO ontology is a general model, it can extend to represent the interactions in a decision network for designing any complex engineered system. Future research opportunities include the information sharing strategies adopt by different stakeholders in distributed and collaborative design network where information is preserved by the stakeholders, and the security assurance mechanism to allow stakeholders to share information without leaking the private part of it. Declaration of Competing Interest None of the authors of the paper, “An Ontology for Representing Knowledge of Decision Interactions in Decision-Based Design,” have any conflict of interest with the paper’s content.

Acknowledgements Zhenjun Ming and Gehendra Sharma acknowledge funding from L.A. Comp Chair at the University of Oklahoma. Janet K. Allen and Farrokh Mistree gratefully acknowledge the funding from the John and Mary Moore Chair and L.A. Comp Chair at the University of Oklahoma respectively. The authors acknowledge Dr. B. P. Gautham from Tata Consultancy Services Research, Pune, India, for suggesting the gearbox design problem.

References Ahmed, S., Goh, C.H., Gautham, B., Zagade, P., Allen, J., Mistree, F., 2014. Design Space Exploration with the Preemptive and Archimedean Formulations of the Compromise Decision Support Problem. International Journal of Advanced Manufacturing 15, 41–63. Alyaqout, S.F., Peters, D.L., Papalambros, P.Y., Ulsoy, A.G., 2011. Generalized Coupling Management in Complex Engineering Systems Optimization. J Mech Design 133 (9). Bascaran, E., Bannerot, R.B., Mistree, F., 1989. Hierarchical Selection Decision Support Problems in Conceptual Design. Engineering Optimization 14 (3), 207–238. ¨ Bras, B., Mistree, F., 1991. Designing Design Processes in Decision-Based Concur¨ Transactions. Journal of Materials & Manufacturing 100, rent Engineering,SAE 451–458. Chen, L., Li, S., 2004. Analysis of Decomposability and Complexity for Design Problems in the Context of Decomposition. J Mech Design 127 (4), 545–557. Chen, W., Hoyle, C., Wassenaar, H.J., 2013. Decision-Based Design: An Approach for Enterprise-Driven Engineering Design. In: Decision-Based Design. Springer, pp. 3–11. Chen, S., Yi, J., Jiang, H., Zhu, X., 2016. Ontology and CBR Based Automated DecisionMaking Method for the Disassembly of Mechanical Products. Adv Eng Inform 30 (3), 564–584. Dinc¸er, A.E., Demir, A., Bozkus¸, Z., Tijsseling, A.S., 2019. Fully Coupled Smoothed Particle Hydrodynamics-Finite Element Method Approach for Fluid–Structure Interaction Problems With Large Deflections. Journal of Fluids Engineering 141 (8). English, K., Bloebaum, C.L., Miller, E., 2001. Development of multiple cycle coupling suspension in the optimization of complex systems. Struct. Multidiscip. Optim. 22 (4), 268–283. Fenves, S.J., Foufou, S., Bock, C., Sriram, R.D., 2008. CPM2: A Core Model for Product Data. J Comput Inf Sci Eng 8 (1), pp. 014501-014501-014506. Gebala, D.A., Eppinger, S.D., 1991. Methods for analyzing design procedures. The 3rd International Conference on Design Theory and Methodology. Gruber, T.R., 1993. A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition 5 (2), 199–220. Grüninger, M., 2004. Ontology of the Process Specification Language. In: Handbook on ontologies. Springer, pp. 575–592. Hatchuel, A., Weil, B., Le Masson, P., 2013. Towards an Ontology of Design: Lessons from C–K Design Theory and Forcing. Research in Engineering Design 24 (2), 147–163. Hazelrigg, G.A., 1998. A Framework for Decision-Based Engineering Design. J Mech Design 120 (4), 653–658. Kusiak, A., Larson, N., 1995. Decomposition and Representation Methods in Mechanical Design. J Mech Design 117 (B), 17–24. Larbi, W., Deü, J.-F., Ohayon, R., 2008. Absorbing interfaces in structural-acoustic coupled problems. European Journal of Computational Mechanics/Revue Européenne de Mécanique Numérique 17 (5-7), 677–688. Lee, J.H., Fenves, S.J., Bock, C., Suh, H., Rachuri, S., Fiorentini, X., Sriram, R.D., 2012. A Semantic Product Modeling Framework and Its Application to Behavior Evaluation. Ieee T Autom Sci Eng 9 (1), 110–123. Li, S., 2010. Methodical Extensions for Decomposition of Matrix-Based Design Problems. J Mech Design 132 (6). Marston, M., Allen, J.K., Mistree, F., 2000. The Decision Support Problem Technique: Integrating Descriptive and Normative Approaches in Decision Based Design Engineering Valuation & Cost Analysis. Special Issue on Decision-Based Design: Status and Promise 3 (2), 107–129. Ming, Z., Wang, G., Yan, Y., Dal Santo, J., Allen, J.K., Mistree, F., 2017. An Ontology for Reusable and Executable Decision Templates. J Comput Inf Sci Eng 17 (3), 031008–031021. Ming, Z., Yan, Y., Wang, G., Panchal, J.H., Goh, C.-H., Allen, J.K., Mistree, F., 2016. Ontology-Based Executable Design Decision Template Representation and Reuse. Ai Edam 30 (4), 390–405. Ming, Z., Nellippallil, A.B., Yan, Y., Wang, G., Goh, C.H., Allen, J.K., Mistree, F., 2018. PDSIDES—A Knowledge-Based Platform for Decision Support in the Design of Engineering Systems. J Comput Inf Sci Eng 18 (4), pp. 041001-041001-041014. Mistree, F., Smith, W.F., Bras, B.A., Allen, J.K., Muster, D., 1990. Decision-Based Design: a Contemporary Paradigm for Ship Design. Transactions of the Society of Naval Architects and Marine Engineers 98, 565–597. Mistree, F., Hughes, O.F., Bras, B.A., 1993. The Compromise Decision Support Problem and the Adaptive Linear Programming Algorithm. In: Kamat, M.P. (Ed.), Structural Optimization: Status and Promise. AIAA, Washington, DC, pp. 247–286.

Z. Ming, G. Sharma, J.K. Allen et al. / Computers in Industry 114 (2020) 103145 Musen, M.A., 2015. The Protégé Project: a Look Back and a Look Forward. AI matters 1 (4), 4–12. Nellippallil, A.B., Rangaraj, V., Gautham, B.P., Singh, A.K., Allen, J.K., Mistree, F., 2018. An Inverse, Decision-Based Design Method for Integrated Design Exploration of Materials, Products, and Manufacturing Processes. J Mech Design 140 (11). Nellippallil, A.B., Song, K.N., Goh, C.-H., Zagade, P., Gautham, B.P., Allen, J.K., Mistree, F., 2017. A Goal-Oriented, Sequential, Inverse Design Method for the Horizontal Integration of a Multistage Hot Rod Rolling System. J Mech Design 139 (3). O’Connor, M.J., Das, A.K., 2009. SQWRL: A Query Language for OWL. The 6th International Conference on OWL: Experiences and Directions (OWLED’09), 208–215. Panchal, J.H., Paredis, C.J.J., Allen, J.K., Mistree, F., 2009. Managing Design-Process Complexity: A Value-of-Information Based Approach for Scale and Decision Decoupling. J Comput Inf Sci Eng 9 (2), pp. 021005-021005-021012. Panetto, H., Dassisti, M., Tursi, A., 2012. ONTO-PDM: Product-driven ONTOlogy for Product Data Management Interoperability within Manufacturing Process Environment. Adv Eng Inform 26 (2), 334–348. Pathan, R.K., Beemaraj, S.B., Salvi, A., Sharma, G., Allen, J.K., Mistree, F., 2019. Design of Composite Structures through Decision Support Problem and Multiscale Design Approach. In: ASME 2019 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, August 18-21, 2019, Anaheim, CA, USA, Paper No. IDETC2019-97894. Penning, P., Ohayon, R., Kehr-Candille, V.r., Proc. ASME 2005. Modal Synthesis Method for Poroelastic Fluid-Structure Coupled Problems Including Structural Damping. International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, 2541–2551. Reddy, R., Smith, W., Mistree, F., Bras, B., Chen, W., Malhotra, A., Badhrinath, K., ¨ ¨ User Manual,Systems RealLautenschlager, U., Pakala, R., Vadde, S., 1996. DSIDES ization Laboratory, Woodruff School of Mechanical Engineering. Georgia Institue of Technology, Atlanta, Georgia. Rockwell, J., Grosse, I.R., Krishnamurty, S., Wileden, J.C., 2019. A Decision Support Ontology for Collaborative Decision Making in Engineering Design. In: Proc. 2009 International Symposium on Collaborative Technologies and Systems., pp. 1–9. Shang, L., Zhao, G., 2016. Optimality criteria-based topology optimization of a bi-material model for acoustic–structural coupled systems. Engineering Optimization 48 (6), 1060–1079. Sharma, G., Allen, J.K., Mistree, F., 2019. Classification and Execution of Coupled Decision Problems In Engineering Design for Exploration of Robust Design Solutions. In: ASME Design Automation Conference, Hilton Anaheim, Anaheim, CA. Paper Number DETC2019-97372. Sim, S.K., Duffy, A.H.B., 2003. Towards an Ontology of Generic Engineering Design Activities. Research in Engineering Design 14 (4), 200–223.

17

Simon, H.A., 1976. Administrative Behavior: A Study of Decision-Making Processes in Administrative Organization. Free Press, New York. Smith, W.F., Kamal, S., Mistree, F., 1987. The Influence of Hierarchical Decisions on Ship Design. Marine Technology 24 (2), 131–142. Sobieszczanski-Sobieski, J., 1982. A Linear Decomposition Method for Large Optimization Problems. In: Blueprint for Development - NASA-TM-83248. Sponsoring Organization: NASA Langley Research Center. Steward, D.V., 1981. Systems analysis and management: structure, strategy, and design. In: Petrocelli books. Vadde, S., Allen, J.K., Mistree, F., 1994. Compromise Decision Support Problems for Hierarchical Design Involving Uncertainty. Comput Struct 52 (4), 645–658. Wagner, T.C., Papalambros, P.Y., 1993. Implementation of decomposition analysis in optimal design. The 19th ASME Design Automation Conference, 327–335. Wassenaar, H.J., Chen, W., 2003. An Approach to Decision-Based Design with Discrete Choice Analysis for Demand Modeling. J Mech Design 125 (3), 490–497. Zhu, X., Zhao, C., Wang, X., Zhou, Y., Hu, P., Ma, Z.-D., 2019. Temperature-constrained topology optimization of thermo-mechanical coupled problems. Engineering Optimization, 1–23.

Glossary Decision-Based Design (DBD): An approach to engineering design that recognizes the substantial role that decisions play in design. Decision Support Problem Technique (DSPT): An implementation of DecisionBased Design. Selection Decision Support Problem (sDSP): a primary DSP about making a choice among several possibilities considering several measures of merit or attributes. Compromise Decision Support Problem (cDSP): a primary DSP about 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. Decision Network (Workflow): A representation of design processes using a set of decisions interacting one another in a network. Decision Interaction: A form of relationship that embodies the dependency (or interdependence) among different decisions. Vertical Interaction: an interaction that happens among decisions across levels in a hierarchy Horizontal Interaction: an interaction that happens among decisions at the same level of the hierarchy Information Flow: The information flow between two decisions when they are interacting