Ontology-Based Representation of Design Decision Hierarchies

Engineering systems are, by definition, made up of inter-related subsystems [1]. The analysis and synthesis of these systems are generally too complex to be handled as a single problem, and this necessitates the design of the overall system first by decomposing the system into subsystems [2]. Existing hierarchical decomposition approaches are anchored in two perspectives: physical structure (or function)-based perspective and the decision-based perspective, which defines the design process. The former is focused on decomposing the design problem according to the system's interconnected structures or coupled functions (which may need various types of disciplinary expertise to design them). A well-known representative of this perspective is Sobieszczanski-Sobieski's [3–5] multilevel decomposition and coordination method for handling large, multidisciplinary problems while trying to reduce computational costs; this approach lays the foundation for many multidisciplinary design optimization approaches (for example, Refs. [6–9]). In this perspective, design is viewed as a decision-making process in which the design of complex engineering systems involves making a series of decisions that are typically hierarchical. Based on this decision-based perspective, many hierarchical decomposition methods have been proposed and tested in limited situations. Examples include the hierarchical selection decision support problem (DSP) for conceptual design [10], and the coupled compromised decision support problem proposed to solve hierarchical problems in structural design [1,2,11–13].

Another factor that is also critical is the computational framework that provides the infrastructure for the execution of the decomposed problem modules (represented as simulation or analysis codes) and the overall optimization model. Salas and Townsend [14] from the National Aeronautics and Space Administration recognize the need for such a framework and identified requirements for its development. Key requirements include architecture design, problem formulation, problem execution, and the ability to handle a large amount of information. Many commercially available and research-based software frameworks such as modelcenter [15], isight [16], and modefrontier [17] have been developed based on these requirements in order to enable the coupling of disciplinary analysis codes, geometric design models, and optimization routines. Hiriyannaiah and Mocko [18] suggest that although significant effort has been invested to address issues associated with integration, execution, and communication, more needs to be done to provide sufficient information/knowledge management capabilities: A structured representation and information model is needed to capture information so that designers can easily store, organize, and retrieve previous knowledge for reuse. Knowledge, which is sometimes referred to as truths, justified beliefs, perspectives, judgment, etc. [19], is of critical value for enhancing humans' ability to solve practical problems. Computational frameworks should have the capability of retaining the knowledge (including many know-whys and know-hows such as design rules and decisions) generated during the process of design and organizing it in a manner that facilitates the re-application of this knowledge in solving new problems.

To accommodate the need for knowledge management in complex system design, we are designing a knowledge-based platform for decision support in the design of engineering systems (PDSIDES). The core of PDSIDES is an ontology (specification of a conceptualization [20]) that is used to organize design knowledge from a decision-based perspective. In our earlier work, we have developed two ontologies for formally representing knowledge related to two primary types of decisions, namely, selection [21] and compromise [22]. These two ontologies enable PDSIDES to capture and document individual decision-related knowledge at a computational level. As mentioned earlier, complex system design usually involves a series of decisions coupled in a hierarchy. Therefore, there is a need for a scheme to represent the workflow among the individual decisions. In this paper, we address this need by extending the existing selection and compromise decision ontology to capture the workflow in design decision hierarchies, which enables PDSIDES to deal with more complex design processes. The rest of the paper is organized as follows: In Sec. 2, we discuss the background of this work, which includes both hierarchical decision-making in design and ontology-based knowledge modeling. In Sec. 3, we identify the requirements for a computational model that represents the DSP hierarchy. In Sec. 4, we describe the ontology to meet the requirements. In Sec. 5, we illustrate the efficacy of the created ontology. In Sec. 6, we offer some remarks and suggest future research opportunities.

Engineering design is increasingly recognized as a decision-making process [23–26]. Decision-based design (DBD) is one of the several constructs for designing complex systems [23]. We note that DBD has been implemented in several ways. Our implementation is anchored in the DSP technique. The key to the DSP technique is the concept that there are two types of decisions (namely, selection and compromise) and that a complex design can be represented by modeling a network of compromise and selection decisions [26–28]. The selection DSP (sDSP) [29] involves making a choice among a number of alternatives taking into account a number of measures of merits or attributes while the compromise DSP (cDSP) [30–32] involves the improvement of a feasible alternative through modification by making trade-offs among multiple design objectives. The design of complex systems may require the formulation and resolution of a series of coupled decisions in which case, the hierarchical DSP construct offers a feasible alternative.

According to Smith [33], there are two classes of decision hierarchies, namely, multilevel hierarchy and coupled hierarchy, as shown in Fig. 1. The first class is modeled as separate decisions that are made at different levels of the hierarchy at which they occur. The decisions are separable and can, therefore, be made concurrently or sequentially. The interaction among these decisions in this approach is relatively low because the dependency among decisions is weak with either no information flow or a one-way flow. The second class, the coupled hierarchy, is modeled as coupled DSPs. In this class, the entire hierarchy is formulated as a single DSP. Hence, the interactions among the decisions are strong, creating a tight bond among subsystems. Coupled hierarchical decisions require simultaneous solution of one or more DSPs as a single coupled problem. In this paper, we focus on coupled hierarchical decisions.

A coupled hierarchical decision involves the solution of any combination of selection and/or compromise DSPs simultaneously by reformulating all the DSPs into a single cDSP. Publications on coupled DSPs include coupled compromise–compromise DSPs [1,2], coupled selection–compromise DSPs [34,35] and coupled selection–selection DSPs [10]. The mathematical formulation of the coupled selection–compromise DSP is shown in Table 1; the other two types of coupling can be formulated similarly. In Table 1, X and Y denote the variables of two decisions. System constraints and goals (e.g., MF(Y)X, g(X, Y), and A(X, Y)) that involve both X and Y represent the lateral interactions among member decisions in a hierarchy. Vertical interactions (not shown in the figure) can also be modeled with system goals as X = X(Y) where X represents the parent decision variables and Y the subdecision variables; for details, see Refs. [2,11], and [12]. Coupled DSPs are generally multi-objective, nonlinear, mixed discrete–continuous problems. A tailored computational environment known as DSIDES [36] incorporating the adaptive linear programming algorithm [31] has been created to solve such problems.

Ontology is defined as a specification of a conceptualization [20]; it provides a common vocabulary for the representation of domain-specific knowledge. As mentioned earlier, the two key elements of an ontology are concepts and relationships. Concepts are physical or logical objects in a domain [37] and are represented by Classes. Relationships describe the network among the concepts and are represented by Properties or Slots of the Classes. Based on the abstract structure of an ontology, infinite numbers of Instances can be populated using specific information.

Although the research on ontology has its roots in computer science, ontologies have often been used for knowledge modeling in the engineering domain. Applications are typically categorized as follows: knowledge sharing [38,39], knowledge retrieval [40,41], and knowledge documentation [42,43]. In knowledge sharing, the functionality of ontologies in representing a common understanding of a domain is emphasized and is used for sharing and exchanging information among applications. In knowledge retrieval, the emphasis is an ontology's usefulness in representing complex relations among concepts, which are essential for building a reference network for retrieval. In knowledge documentation, ontology is used for populating Instances, which represent domain-specific knowledge. In this paper, we focus on the application of ontology in knowledge documentation. It is recognized that several ontologies have been developed for documenting knowledge in the domain of engineering design, such as a design optimization ontology [43], a design for manufacturing ontology [44], a design for additive manufacturing ontology [45], a functional design ontology [46], and a product family design ontology [41]. In engineering design, decisions determine how design resources are allocated and how design objectives are achieved, which are critical, and this knowledge should also be documented for reuse. Along this line, Rockwell et al. [42] created ontologies for capturing and communicating design decisions. However, the focus of their work is on archiving design rationale to help designers understand previous designs. The knowledge so captured cannot be rapidly reused to create new designs since the computational procedures for decision-making are not captured. Furthermore, the ontologies proposed in Ref. [42] are limited to representing individual (or single) decisions while they fail to represent decision workflows that typically involve multiple decisions interconnected in the design processes.

In our earlier work [21,22], we have developed ontologies for representing individual decisions, including selection and compromise decisions, in which the decision-making procedures are computationally modeled with templates and are ready to execute to generate new results in the platform PDSIDES. In this paper, we take a step further to extend the existing selection and compromise ontologies to representing hierarchically decision workflows. Before the development of the ontology, requirements are identified and discussed in Sec. 3.

A general four-level representation for a hierarchical system is proposed by Sobieszczanski-Sobieski [5], as shown in Fig. 2. The nature of the hierarchy is a two-dimensional, horizontal and vertical network structure. The nodes represent the integral parts of the system that can be parent systems or subsystems depending on their relative positions in the hierarchy. The links represent dependencies between two nodes, which can be vertical and lateral, depending on whether they cross levels. In the vertical direction, the root node, e.g., node “1.1” in Fig. 2, is progressively decomposed into multiple levels, and each level may have multiple nodes. Every two levels in the neighborhood are interconnected by a vertical dependency between the nodes corresponding to a “parent–child” relationship of the two levels; thus, the network is vertically integrated. In the horizontal direction, nodes of the same (e.g., nodes “3.1” and “3.2”) or different (e.g., nodes “3.2” and “3.3”) parent(s) at the same level may be connected by lateral dependencies and thus the network is laterally integrated.

From the decision-based design perspective, the design of such hierarchical systems is supported by the DSP networks in which each node embodies a DSP that supports a design decision about the related system elements and each link embodies the interaction between two nodes. In the context of the platform PDSIDES, the DSP network is modeled computationally to facilitate the formulation of a decision hierarchy in keeping with the solution procedures for hierarchical system design, and the needs of designers. PDSIDES and the DSP technique are then used to solve problems. The requirements for the computational DSP hierarchy model are:

• Decomposability: The multilevel or multiscale characteristic of hierarchical systems requires a model to be decomposable to capture the complexity of the physical system and be solvable using available computational power. Further, a model should support dynamic decomposition as the design evolves.

• Flexibility: The evolution of knowledge about a system being designed at different design stages requires the model to be flexible enough to support reconfiguration. For example, in early design stages, the system is not decomposed into very detailed levels and much of the dependency is ignored because of the lack of knowledge. As the time moves forward, knowledge increases and the original model must be reconfigured to incorporate this knowledge.

• Reusability: The pursuit of design efficiency requires that the model is reused. In practice, many product or system designs fall into the category of variant or adaptive designs where a large part of the information of the underlying design model can be reused and there is no need to recreate it from scratch. For example, in an adaptive design scenario, where only one part (e.g., node “4.5” in Fig. 2) is changed while the others remain the same, the original design model could be easily reused, with small modifications, to support the design.

• Executability: The model needs to be executable on a computer. Encoding the linguistic and/or mathematical formulation of the problem as a computational model is a feasible way to obtain executability. However, the disadvantage is that the codes are incomprehensible to designers who are not programmers. There is a need for a computational model to be executable and at the same time, easily understandable to designers. To do this, the rich semantics in the decision hierarchy must be captured in the model.

• Visualization: A comprehensive understanding of a design problem requires that the model is visualized. A hierarchical system is a system of parent systems and interacting subsystems. Therefore, the computational model should support the visualization of the hierarchical structure so that designers can have an intuitive understanding of the problem they are dealing with and can edit the model effectively.

• Consistency maintainability: The mathematical rigor of the decision formulation requires the computational model to be consistent with what is defined. For example, the initial value of a variable in a cDSP should lie between a lower bound and an upper bound, the sum of the weights of the goals on the same level should equal 1, etc. These are the rules for the mathematical model to maintain consistency; however, these rules may not remain valid during model reconfiguration, resulting in model inconsistency. Therefore, the computational model should support consistency checking and maintain consistency.

In this section, we present an ontology as a computational model that meets the requirements identified in Sec. 3. In our earlier work [21,22], we illustrate the use of an ontology for facilitating the reuse, execution, and consistency maintenance of DSP templates. In particular, the reuse of the DSP templates is facilitated with a common vocabulary embodied in the ontology for generating different specific Instances. This can easily be adapted for new scenarios by modification of the associated Slots. The execution of the DSP templates is facilitated with web ontology language—a standard and computer-interpretable modeling language underlying the ontology—which supports the parsing by other applications through, for example, Java function calls. The consistency of the DSP templates is maintained by the incorporation of reasoning mechanisms for consistency checking within the ontology. In this paper, the ontology is extended to model a hierarchical DSP network with emphasis placed on meeting the decomposability, flexibility, and visualization requirements listed in Sec. 3.

In a computational environment, the decomposability of a model means that it can be further divided or broken down into smaller components. In a DSP hierarchy, this involves vertical integration of dependent sub-DSPs. This calls for the identification of a concept from a higher level than the DSPs alone. This is a general representation of a hierarchy that not only incorporates the DSPs but also captures the associated links so that newly derived sub-DSPs can be linked to an existing hierarchy when decomposition or reassembly is needed. Here, the concept is named Process, which is formally defined as an ontology Class in Sec. 4.1. The flexibility of the DSP hierarchy is embodied in reconfiguration, which principally includes: (i) dynamic decomposition of decisions and (ii) incorporation of evolving dependencies (or links) among decisions. This requires the links in the hierarchy to be separately modeled so that they can be dynamically added, edited, and removed when reconfiguration is needed. In this paper, the links are modeled as Interfaces as discussed in Sec. 4.2. Visualization is implemented with an ontology editing tool, which is introduced in Sec. 4.3. It is recognized that the Process Specification Language ontology [47] is a generic model for flow management; the ontology created in this paper can link to it by mapping ClassesProcess, and Interface to the concept of Activity in Process Specification Language.

The ClassProcess is a general representation of the building blocks in a hierarchy, which incorporates one DSP and its associated dependency. For example, in Fig. 2, the collection of node 2.2 and its associated links on the top, bottom, left-hand side, and right-hand side can be called an Instance of a Process. It is called Process because it represents an information processing unit based on a decision-making mechanism, sDSP or cDSP, and the associated interactions, (information flows) with other units. The concept of the ClassProcess is shown in Fig. 3. It represents a standard, scalable hierarchy building block of which the solid box (or shell) stands for the information processing unit with a DSP (the dashed box) plugged in, and lines represent the associated vertical and lateral dependencies. A hierarchy is built by assembling a series of different Processes. In the ontological context, the Slots of ClassProcess are defined in Table 2.

The ClassInterface is a representation of the vertical or lateral dependency between two different Processes. For example, in Fig. 2, the link between nodes 2.2 and 3.3 is an instance of an Interface. It is called an Interface because it captures the communication between the two processes. Interfaces are critical in building a DSP hierarchy because they constitute the medium that connects the individual building blocks, namely, Processes, to an integrated whole. The concept of Interface is shown in Fig. 4. As shown in the figure, an Interface consists of two elements: (1) the references (or indices) of two linked Processes, which are represented by dashed boxes, and (2) the information flow, which is represented by the solid line between the two Processes. Based on the strength, the information flow is of two types, namely, (a) weak flow and (b) strong flow. The weak flow is a one-way flow (“1 to 2” or “2 to 1”), which means that one Process has parameters that must be input from the counterpart. A strong flow is a two-way flow, which means that both of the Processes have parameters that need to be input from the counterpart.

Based on the direction of flow, information is categorized into two types, namely, (i) lateral flow and (ii) vertical flow. Lateral flow links Processes at the same level in a hierarchy. Vertical flow links Processes at different, neighboring levels in a hierarchy. Since the Processes are embedded with DSPs, the information flow must be modeled to be consistent with the coupled DSP construct introduced in Sec. 2.1. Using the interface shown in Fig. 4 as an example, the characteristics of the information flow in the context of coupled DSP construct are modeled as follows. (Here, we assume $X1$ represents the variable vector of the DSP in Process 1 and $X2$ the DSP in Process 2.)

• Vertical: Vertical information flow is usually two-way and occurs between cDSPs in a hierarchy. Assuming Process 1 is the parent system and Process 2 the subsystem, the coupling is modeled as a system goal of a coupled cDSP, formulated as $A(X1,X2)=(X1/(X1(X2)))−1$ where $X1(X2)$ is a function that maps $X2$ to $X1$⁠.

• Lateral: In this type, the coupling is divided into the following six subtypes.

  1. —

     sDSP↔sDSP: Two-way flow between two sDSPs. This can be embodied in three ways: dependent attributes, dependent alternatives, and dependent alternatives as well as attributes; see Ref. [48] for more detail. Mathematically, the interdependency is modeled as a system goal of a coupled cDSP.

  2. —

     sDSP→cDSP: One-way flow from sDSP to cDSP. Assuming that Process 1 is modeled with an sDSP and Process 2 with a cDSP, then the information flow is modeled by the (Boolean) variable vector $X1$ of the sDSP that constitutes the parameters of the cDSP's system constraints as represented as $g(X1, X2)$⁠, and/or system goals represented as $A(X1, X2)$⁠.

  3. —

     cDSP→sDSP: One-way flow from cDSP to sDSP. Assuming that Process 1 is modeled with a cDSP and Process 2 with an sDSP, then the information flow is modeled by the variable vector $X1$ of the cDSP that constitutes the parameters of the sDSP's merit function represented as $MF(X1)⋅X2$⁠, which is a system goal in a coupled cDSP. In this case, $X2$ is Boolean.

  4. —

     sDSP↔cDSP: Two-way flow between an sDSP and a cDSP. This is modeled by the combination of the preceding two types.

  5. —

     cDSP→cDSP: One-way flow between two cDSPs. This is modeled by the variable vector of the antecedent cDSP that constitutes the system constraints and goals of the subsequent cDSP.

  6. —

     cDSP↔cDSP: Two-way flow between two cDSPs. This is modeled by the variable vectors of both of the two cDSPs that constitute the system constraints and goals of the counterparts.

As mentioned in Sec. 2.1, the resolution of a coupled DSP involves reformulating all the DSPs into a single cDSP. In this paper, since the Interface constitutes the dependent part (coupled system constraints and goals) of the DSPs, it should then be integrated with the independent parts (which are embedded in the Processes) to compose a single cDSP. In our ontology, in order to represent these dependencies in a hierarchy, we identify and define the Slots of ClassInterface in Table 3.

The definition of ClassProcess, ClassInterface, as well as the associated Slots, is facilitated by using the protégé 3.5 tool [49], which provides an environment for creating and editing ontologies as well as populating Instances based on ontologies. Three typical user-interfaces of protÉgÉ in terms of the DSP hierarchy ontology are shown in Fig. 5. In Fig. 5, the panel marked with “①” is the class browser where the ontology Classes including Classes of the cDSP ontology (represented as “CO,” see Ref. [22]), Classes of the sDSP ontology (represented by “SO,” see Ref. [21]), and the two Classes (highlighted in the box) identified in this paper for building DSP hierarchies are listed. The window marked “②” is the Instance editor for the ProcessClasses, where the Slots are created using the definitions in Sec. 4.1 and are populated with specific problem information. The window marked with “③” is the Instance editor for the InterfaceInstances, where the Slots are created using the definitions in Sec. 4.2 and are populated using specific problem information.

In our ontology, building DSP hierarchies is facilitated with the protégé graph widget [50], a graphical tool for visual editing the Instance and relationships among Instances. The protégé graph widget is especially suitable for building the DSP hierarchy as the hierarchy is a network of ProcessInstances and InterfaceInstance. A screenshot of the widget customized for building the hierarchy is shown in Figs. 6–8 in Sec. 5.

In this section, a portal frame design problem is used as an example to illustrate the use of the ontology presented in Sec. 4. The example is an extension of the problem considered by Sobieszczanski-Sobieski [5] to demonstrate the decomposition method in solving hierarchical design problems. The correctness of the ontology is tested along with a refinement process of the decision model (DSP) for the portal frame design.

A portal frame represents a simple hierarchical system, as shown in Fig. 6. The integrated frame represents the parent system while the three I-beams are the subsystems. The design objective is to minimize the overall mass of the frame. The frame is subject to two kinds of constraints: external constraints and internal constraints. The former includes static loads $P$ and $M$ while the latter includes normal stress, bending stress, shear stress, and buckling in each member. Design variables are categorized into parent system variables and subsystem variables. Parent system design variables $A$ and $I$ stand for each member's cross-sectional area and moment of inertia, respectively. Subsystem variables are the dimensions, namely, $b1$⁠, $b2$⁠, $h$⁠, $t1$⁠, $t2$⁠, $t3$ of each subsystem. $Vi$ denotes the vertical interactions between the parent system and each of its subsystems. $Lij$ represents the lateral interactions between subsystems.

In the early stages of design, designers usually face the challenge of having limited information for modeling the problem. In the design of the portal frame, we assume that information related to the vertical interactions, $Vi$⁠, and the lateral interactions, $Lij$⁠, are unknown to designers. Designers are required to create a baseline model to design the portal frame with limited information. The baseline model is a single cDSP in which all the constraints are in terms of the design variables at the subsystem level. In the context of Fig. 6, this involves only subsystem variables $b$⁠, $t$⁠, and $h$ for each beam, and does not make use of the parent variables $A$ and $I$⁠. In the ontological context, a ProcessInstance, the “Portal Frame Design,” as shown in Fig. 9, is created using the available information. Since the vertical and lateral interactions are not modeled, no InterfaceInstance is created. Specification of the Process Instance is presented in window ① of Fig. 9 and the information of required for the cDSP template in the Instance is presented in window ②. It is not difficult to imagine that because of the lack of consideration of interactions among the three members (subsystems) of the portal frame, there would be some differences among the resulting dimensions of the members. Using the baseline model as the starting point, it is assumed that designers will gradually refine the model by considering lateral and vertical interactions. The performance of the ontology in terms of facilitating the creation of a DSP hierarchy to support this refinement is tested in the Secs. 5.2 and 5.3. In Sec. 5.2, designers refine the baseline model by first decomposing the model into sub-DSPs then linking the sub-DSPs using lateral interaction information. In Sec. 5.3, designers further refine the model with the lateral interactions by the incorporation of vertical interactions with a parent DSP that supports the decision-making related to the parent system. The model presented in Sec. 5.3 is a comprehensive model with both lateral and vertical interactions. In Sec. 5.4, we showcase how designers can retrieve decisions from the knowledge base using the ontology.

Based on the baseline model formulated in Sec. 5.1, designers are able to refine the model with known lateral interactions between member 1 and member 2, and the lateral interactions between member 2 and member 3, namely, $L12$ and $L23$ in Fig. 6. This means that the baseline model created in Sec. 5.1 must be decomposed into three DSPs, and the associated dependency needs to be modeled. The model can be decomposed by separation of the cDSP formulation in Fig. 9 into three independent cDSPs based on the dimensions of the three subsystems. The (lateral) dependencies necessitate the inclusion of constraints that connect the subsystem variables to their counterparts in the other subsystems. This connection is modeled mathematically with system goals in a cDSP.

In our ontology, system goals are captured and used to populate two InterfaceInstances, namely, “L12” and “L23,” as shown in the canvas of Fig. 10. The three separated cDSPs are used to instantiate three ProcessInstances, “M1,” “M2,” and “M3,” which are linked by L12 and L23. Both L12 and L23 represent strong coupling with two-way information flow. The information flows are embodied in the Slots, “originalCounterpartFlow” and “counterpartOriginalFlow,” as shown in the window under the canvas in Fig. 10 in which the specifics of L12 are shown. The deviation variables associated with the interaction system goals, together with the deviation associated with the mass goal, are formulated in a preemptive form in the overall deviation function, where the interaction system goals have a higher priority than the mass goal. The overall deviation function is captured in one of the three ProcessInstances (in this case is M1). At a computational level, all the information of the Process and InterfaceInstances is integrated as a coupled cDSP and sent to DSIDES for computation. The results are not shown in this paper but because of the inclusion of the lateral interactions, which match the tree subsystems, the difference between the subsystem dimensions will be reduced to a tolerable extent.

In this section, the vertical interactions between the parent system and subsystems, namely, $V1$⁠, $V2$⁠, and $V3$⁠, in Fig. 6 are known and designers are assumed to further refine the model from Sec. 5.2, using this information. Since the vertical interactions are known, a new cDSP corresponding to the parent system is created so that the existing subsystem DSPs are connected to it through the vertical interactions. The new parent cDSP involves parent system level design variables $Ai$ and $Ii$ (⁠$i$ = 1, 2, 3), constraints, and goals. The vertical interactions necessitate the inclusion of constraints that match the parent system design variables (⁠$A$ and $I$⁠) and the subsystem variables (⁠$b$⁠, $t$⁠, $h$⁠). Similarly to the lateral interactions, this “matching” is modeled mathematically by system goals in a cDSP.

In our ontology, vertical interactions are captured and used to populated InterfaceInstances, namely, “V1,” “V2,” and “V3,” as shown in Fig. 7. The information of the cDSP corresponding to the parent system is used to instantiate a ProcessInstance, “Parent,” which is linked to the three existing subsystem level ProcessInstances, M1, M2 and M3 by V1, V2, and V3, respectively. Also, the lateral interactions, V1, V2, and V3, represent strong coupling with two-way information flows. The specification of V1 is shown in the window under the canvas of Fig. 7. Details of the information flows are in Slots originalCounterpartFlow and counterpartOriginalFlow. Deviation variables related to the interaction system goals are incorporated in the deviation function in a preemptive form, where the vertical interaction goals are of the highest priority, the lateral interaction goals, the second priority, and the mass goal, the third. Specification of the deviation function is assigned to the “root” node of the hierarchy, namely, Parent in Fig. 7, as the overall control for the model. At a computational level, all the information of the hierarchy is integrated as a coupled cDSP and computed with DSIDES. The computed results are not shown in this paper. But it is not difficult to expect that the subsystem dimensions will match each other very well, as in Sec. 5.2 because lateral interactions are included in the model. Meanwhile, the values of the parent system level variables will also match those of the subsystem level variables (e.g., cross-sectional value of $A$ matches the value of $A(b,t,h)$⁠) because of the consideration of vertical interactions.

In the portal frame design example, it can be seen that the ontology created in this paper has the capability to represent the decision hierarchy and capture decision workflows as the design process evolves, as demonstrated by the following: (1) The ontology is decomposable to allow a baseline decision model to be broken down into subdecisions as the design process evolves; (2) the ontology is flexible enough to incorporate new knowledge, e.g., the subsystem-level design variables, vertical and lateral dependencies in the example, when knowledge increases; and (3) the ontology provides a visualized environment for designers so that they can edit and understand the hierarchical decision workflow during the design process.

By ClassesProcess, Interfaces that link the Classes associated with the selection and compromise DSPs as developed in our previous work, we have created a comprehensive terminology box based on which a decision-based design knowledge base is constructed. The terminology box is product- and process-independent; thus, it can easily extend to different products and design processes, and populate many Instances of various degrees of complexity. The Instances comprise the assertion box of the ontology from which designers can query the decision-related knowledge using semantic languages such as Semantic Query-enhanced Web Rule Language (SQWRL). This is another key advantage of the ontology in addition to knowledge documentation. For example, if a designer wants to know all the subdecisions in the parent decision in the portal frame design example, the SQWRL query statement shown in Table 4 may be used.

The knowledge base will respond with “Decision of Member 1,” “Decision of Member 2,” and “Decision of Member 3” in a table format, as shown in Fig. 8. The retrieval feature enhances the usefulness of the DSP hierarchy ontology to decision support platforms, such as PDSIDES.

Hierarchies that arise naturally in the design of complex engineered systems involve the design of parent systems and dependent subsystems. In decision-based design, this results in decision network hierarchies. To support designers making such networked, hierarchical decisions, capturing and representing the associated knowledge is of critical importance. In this paper, we propose an ontology for capturing and representing the hierarchical decision knowledge for the DSP construct. Foundational to the ontology introduced in this paper is the coupled, hierarchical DSP construct, which provides a means for designers to model the dependent selection and/or compromise decisions. In order to develop the ontology, first, we identify the requirements for a model that computationally represents the DSP hierarchy. Second, based on these requirements, we formally define two key classes, namely, Process which represents the basic hierarchy building blocks where selection or compromise DSPs are modeled and Interface, which represents the DSP information flows that link different Processes to a hierarchy. Finally, the efficacy of the ontology is demonstrated using a portal frame design example.

One premise of this paper is that designers have full control of the information flows among the decision hierarchy. In the world of practice, when the subsystem design tasks are assigned to different design teams or geographically distributed companies who have their own goals to satisfy, full information control may not be possible for a single team or company. This control may be distributed to all the stakeholders. Future research opportunities lie in the study of how decisions are made regarding distributed information control, and how the ontology created in this paper is adjustable in order to capture the associated decision knowledge.

Farrokh Mistree gratefully acknowledges financial support from the L.A. Comp Chair at the University of Oklahoma.

• China Scholarship Council (Grant No. 201406030014).

• Ministry of Science and Technology of the People's Republic of China (Grant No. 2015BAF18B01).

• National Natural Science Foundation of China (Grant Nos. 51375049 and 515050).

• National Science Foundation (Grant No. CMMI-1440457).

• University of Oklahoma (the John and Mary Moore Chair).