School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Beijing 100081, China
School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Beijing 100081, China
School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Beijing 100081, China
Jitesh H. Panchal
School of Mechanical Engineering,
West Lafayette, IN 47907
Chung Hyun Goh
Department of Mechanical Engineering,
The University of Texas at Tyler,
Tyler, TX 75799
Janet K. Allen
School of Industrial and Systems Engineering,
University of Oklahoma,
Norman, OK 73019
School of Aerospace and Mechanical
University of Oklahoma,
Norman, OK 73019
of Design Decision Hierarchies
The design of complex engineering systems requires that the problem is decomposed into
subproblems of manageable size. From the perspective of decision-based design (DBD),
typically this results in a set of hierarchical decisions. It is critically important for com-
putational frameworks for engineering system design to be able to capture and document
this hierarchical decision-making knowledge for reuse. Ontology is a formal knowledge
modeling scheme that provides a means to structure engineering knowledge in a retrieva-
ble, computer-interpretable, and reusable manner. In our earlier work, we have created
ontologies to represent individual design decisions (selection and compromise). Here, we
extend the selection and compromise decision ontologies to an ontology for hierarchical
decisions. This can be used to represent workﬂows with multiple decisions coupling
together. The core of the proposed ontology includes the coupled decision support prob-
lem (DSP) construct, and two key classes, namely, Process that represents the basic hier-
archy building blocks wherein the DSPs are embedded, and Interface to represent the
DSP information ﬂows that link different Processes to a hierarchy. The efﬁcacy of the
ontology is demonstrated using a portal frame design example. Advantages of this ontol-
ogy are that it is decomposable and ﬂexible enough to accommodate the dynamic evolu-
tion of a process along the design timeline. [DOI: 10.1115/1.4037934]
1 Frame of Reference
Engineering systems are, by deﬁnition, made up of inter-related
subsystems . 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 ﬁrst by decomposing
the system into subsystems . Existing hierarchical decomposi-
tion approaches are anchored in two perspectives: physical
structure (or function)-based perspective and the decision-based
perspective, which deﬁnes the design process. The former is
focused on decomposing the design problem according to the sys-
tem’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 try-
ing to reduce computational costs; this approach lays the founda-
tion 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 engi-
neering systems involves making a series of decisions that are typ-
ically 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
, and the coupled compromised decision support problem pro-
posed to solve hierarchical problems in structural design
Another factor that is also critical is the computational frame-
work 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  from the National Aeronautics and Space
Contributed by the Computers and Information Division of ASME for publication
in the JOURNAL OF COMPUTING AND INFORMATION SCIENCE IN ENGINEERING. Manuscript
received August 11, 2016; ﬁnal manuscript received August 29, 2017; published
online November 13, 2017. Assoc. Editor: Yan Wang.
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-1
C2018 by ASME
Administration recognize the need for such a framework and iden-
tiﬁed requirements for its development. Key requirements include
architecture design, problem formulation, problem execution, and
the ability to handle a large amount of information. Many com-
mercially available and research-based software frameworks such
as MODELCENTER , ISIGHT , and MODEFRONTIER  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  suggest
that although signiﬁcant effort has been invested to address issues
associated with integration, execution, and communication, more
needs to be done to provide sufﬁcient information/knowledge
management capabilities: A structured representation and infor-
mation 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, justi-
ﬁed beliefs, perspectives, judgment, etc. , is of critical value
for enhancing humans’ ability to solve practical problems. Com-
putational 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 com-
plex system design, we are designing a knowledge-based plat-
form for decision support in the design of engineering systems
(PDSIDES). The core of PDSIDES is an ontology (speciﬁcation
of a conceptualization ) that is used to organize design
knowledge from a decision-based perspective. In our earlier
work, we have developed two ontologies for formally represent-
ing knowledge related to two primary types of decisions, namely,
selection  and compromise . These two ontologies enable
PDSIDES to capture and document individual decision-related
knowledge at a computational level. As mentioned earlier, com-
plex system design usually involves a series of decisions coupled
in a hierarchy. Therefore, there is a need for a scheme to repre-
sent the workﬂow among the individual decisions. In this paper,
we address this need by extending the existing selection and com-
promise decision ontology to capture the workﬂow 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 require-
ments. In Sec. 5, we illustrate the efﬁcacy of the created ontol-
ogy. In Sec. 6, we offer some remarks and suggest future research
2.1 Decision Support Problems and Decision Hierarchies.
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 . We
note that DBD has been implemented in several ways. Our imple-
mentation 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) 
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 modiﬁcation 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 , there are two classes of decision hier-
archies, namely, multilevel hierarchy and coupled hierarchy,as
shown in Fig. 1. The ﬁrst 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 deci-
sions in this approach is relatively low because the dependency
among decisions is weak with either no information ﬂow or a one-
way ﬂow. 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 hier-
archical 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 . 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,Xand Ydenote the variables of two decisions. System
constraints and goals (e.g., MF(Y)X, g(X, Y), and A(X, Y)) that
involve both Xand Yrepresent the lateral interactions among
member decisions in a hierarchy. Vertical interactions (not shown
in the ﬁgure) can also be modeled with system goals as X¼X(Y)
where Xrepresents the parent decision variables and Ythe
subdecision variables; for details, see Refs. [2,11], and .
Coupled DSPs are generally multi-objective, nonlinear, mixed
discrete–continuous problems. A tailored computational environ-
ment known as DSIDES  incorporating the adaptive linear
programming algorithm  has been created to solve such
2.2 Ontology-Based Knowledge Modeling. Ontology is
deﬁned as a speciﬁcation of a conceptualization ; it provides a
common vocabulary for the representation of domain-speciﬁc
knowledge. As mentioned earlier, the two key elements of an
ontology are concepts and relationships. Concepts are physical or
logical objects in a domain  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, inﬁnite numbers of
Instances can be populated using speciﬁc information.
Although the research on ontology has its roots in computer sci-
ence, 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 under-
standing 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 build-
ing a reference network for retrieval. In knowledge
Fig. 1 Hierarchical decision-making in design 
011001-2 / Vol. 18, MARCH 2018 Transactions of the ASME
documentation, ontology is used for populating Instances,
which represent domain-speciﬁc 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 , a design for manu-
facturing ontology , a design for additive manufacturing
ontology , a functional design ontology , and a product
family design ontology . 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.  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.  are limited to representing individual (or single) deci-
sions while they fail to represent decision workﬂows 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 exe-
cute 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
workﬂows. Before the development of the ontology, requirements
are identiﬁed and discussed in Sec. 3.
3 Requirements for the Computational Decision
Support Problem Hierarchy Model
A general four-level representation for a hierarchical system is
proposed by Sobieszczanski-Sobieski , as shown in Fig. 2. The
nature of the hierarchy is a two-dimensional, horizontal and verti-
cal 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 lat-
eral, depending on whether they cross levels. In the vertical direc-
tion, the root node, e.g., node “1.1” in Fig. 2, is progressively
decomposed into multiple levels, and each level may have multi-
ple nodes. Every two levels in the neighborhood are intercon-
nected by a vertical dependency between the nodes corresponding
to a “parent–child” relationship of the two levels; thus, the net-
work 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 interac-
tion between two nodes. In the context of the platform PDSIDES,
the DSP network is modeled computationally to facilitate the for-
mulation of a decision hierarchy in keeping with the solution pro-
cedures for hierarchical system design, and the needs of
designers. PDSIDES and the DSP technique are then used to solve
Fig. 2 A general four-level hierarchical system 
Table 1 Mathematical formulation of the coupled selection–
Rij normalized rating of alternative iwith respect to attribute j
Ijrelative importance of attribute j
MFimerit function for the ith alternative where
j¼1IjRij (i¼1,… , M)
nnumber of system variables
pnumber of equality system constraints
qnumber of inequality system constraints
pþqtotal number of system constraints
mnumber of system goals (selection plus compromise)
m1number of coupled compromise system goals
giðX;YÞcompromise constraint function
AiðX;YÞcompromise achievement function
Gitarget of compromise goal
i(i¼1,… , M)
Yi(i¼1,… , n)
i(i¼1,… , m)
Selection system constraint:
Selection system goals:
Compromise system constraints:
Compromise system goals:
i0 and e
i0 and d
The deviation function (preemptive form):
iÞ or ½f1ðe
Fig. 3 Concept of Class Process
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-3
problems. The requirements for the computational DSP hierarchy
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 solv-
able using available computational power. Further, a model
should support dynamic decomposition as the design
Flexibility: The evolution of knowledge about a system being
designed at different design stages requires the model to be
ﬂexible enough to support reconﬁguration. 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 for-
ward, knowledge increases and the original model must be
reconﬁgured to incorporate this knowledge.
Reusability: The pursuit of design efﬁciency 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 modiﬁcations, to support the design.
Executability: The model needs to be executable on a com-
puter. Encoding the linguistic and/or mathematical formula-
tion 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 hier-
archy 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 subsys-
tems. Therefore, the computational model should support the
Fig. 4 Concept of Class Interface
Table 2 Slots of Class Process
Slot name Definition Type
name Name of the Process. String
description Description of the Process. String
IsRoot Indicator of whether the Process is the root (i.e., no parent) of the hierarchy. Two allowable
values—“yes (1)” or “no (0).”
IsLeaf Indicator of whether the Process is the leaf (i.e., no subsystems) of the hierarchy. Two allowable
values—yes (1) or no (0).
Decision Decision corresponding to the Process. Two allowable Classes, namely, cDSP template (see
Ref. ) and sDSP template (see Ref. ). One Processes Instance can have only one corresponding
decision, selection, or compromise.
DecisionType Indicator of the type of the corresponding decision. Two allowable values—“compromise” or
LateralDependency Lateral dependencies of the Process. It is associated with Class Interface introduced in Sec. 4.2.
One Processes Instance can have multiple lateral dependencies.
VerticalDependency_Parent Parent dependency of the Process. It is associated with Class Interface introduced in Sec. 4.2.
One Processes Instance can have only one parent dependency.
VerticalDependency_Subsystem Subsystem dependency of the Process. It is associated with Class Interface introduced in Sec. 4.2.
One Processes Instance can have multiple subsystem dependencies.
Table 3 Slots of Class Interface
Slot name Definition Type
name Name of the Interface. String
description Description of the Interface. String
interface type Indicator of the type of the Interface. Two allowable values—“vertical” or “lateral.” Symbol
strength Indicator of the strength of the coupling. Two allowable values—“weak” or “strong.” Symbol
originalProcess The original Process that is linked by the Interface. It is associated with Class Process. Instance
counterpartProcess The counterpart Process that is linked by the Interface. It is associated with Class Process. Symbol
originalCounterpartFlow Information ﬂow from the original Process to its counterpart. It is associated with Class Function (see
Ref.  for detailed deﬁnition). One Interface Instance can have multiple ﬂows from 1 to 2.
counterpartOriginalFlow Information ﬂow from the counterpart Process to the original Process. The deﬁnition is similar as Slot
Note: The information ﬂow through the Interface is strong when both of Slots originalCounterpartFlow and counterpartOriginalFlow are populated with
speciﬁc values, and is weak when either of the Slots is null.
011001-4 / Vol. 18, MARCH 2018 Transactions of the ASME
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 deﬁned. 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 reconﬁguration,
resulting in model inconsistency. Therefore, the computa-
tional model should support consistency checking and main-
4 Ontology Development for Decision Support
In this section, we present an ontology as a computational
model that meets the requirements identiﬁed in Sec. 3. In our ear-
lier work [21,22], we illustrate the use of an ontology for facilitat-
ing the reuse, execution, and consistency maintenance of DSP
templates. In particular, the reuse of the DSP templates is facili-
tated with a common vocabulary embodied in the ontology for
generating different speciﬁc Instances.This can easily be
adapted for new scenarios by modiﬁcation 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 meet-
ing the decomposability, ﬂexibility, and visualization require-
ments 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 identiﬁca-
tion of a concept from a higher level than the DSPs alone. This
is a general representation of a hierarchy that not only incorpo-
rates 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 deﬁned as an ontology
Class in Sec. 4.1. The ﬂexibility of the DSP hierarchy is
embodied in reconﬁguration, 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 reconﬁgu-
ration is needed. In this paper, the links are modeled as Interfa-
ces as discussed in Sec. 4.2. Visualization is implemented with
an ontology editing tool, which is introduced in Sec. 4.3.Itis
recognized that the Process Speciﬁcation Language ontology
 is a generic model for ﬂow management; the ontology cre-
ated in this paper can link to it by mapping Classes Process,
and Interface to the concept of Activity in Process Speciﬁcation
Fig. 5 User interfaces of the DSP hierarchy ontology
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-5
4.1 Definition of Class Process. The Class Process is a
general representation of the building blocks in a hierarchy, which
incorporates one DSP and its associated dependency. For exam-
ple, 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 repre-
sents an information processing unit based on a decision-making
mechanism, sDSP or cDSP, and the associated interactions, (infor-
mation ﬂows) with other units. The concept of the Class Process
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 depend-
encies. A hierarchy is built by assembling a series of different
Processes. In the ontological context, the Slots of Class Pro-
cess are deﬁned in Table 2.
4.2 Definition of Class Interface. The Class Interface 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 ﬁgure, 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 ﬂow, which is represented by the solid
line between the two Processes. Based on the strength, the infor-
mation ﬂow is of two types, namely, (a) weak ﬂow and (b) strong
ﬂow. The weak ﬂow is a one-way ﬂow (“1 to 2” or “2 to 1”),
which means that one Process has parameters that must be input
from the counterpart. A strong ﬂow is a two-way ﬂow, which
means that both of the Processes have parameters that need to be
input from the counterpart.
Based on the direction of ﬂow, information is categorized into
two types, namely, (i) lateral ﬂow and (ii) vertical ﬂow. Lateral
ﬂow links Processes at the same level in a hierarchy. Vertical
ﬂow links Processes at different, neighboring levels in a hierar-
chy. Since the Processes are embedded with DSPs, the informa-
tion ﬂow must be modeled to be consistent with the coupled DSP
construct introduced in Sec. 2.1. Using the interface shown in
Fig. 4as an example, the characteristics of the information ﬂow in
the context of coupled DSP construct are modeled as follows.
(Here, we assume X1represents the variable vector of the DSP in
Process 1 and X2the DSP in Process 2.)
Vertical: Vertical information ﬂow is usually two-way and
occurs between cDSPs in a hierarchy. Assuming Process 1is
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 func-
tion that maps X2to X1.
Lateral: In this type, the coupling is divided into the follow-
ing six subtypes.
—sDSP$sDSP: Two-way ﬂow between two sDSPs. This
can be embodied in three ways: dependent attributes,
dependent alternatives, and dependent alternatives as
well as attributes; see Ref.  for more detail. Mathe-
matically, the interdependency is modeled as a system
goal of a coupled cDSP.
—sDSP!cDSP: One-way ﬂow from sDSP to cDSP.
Assuming that Process 1 is modeled with an sDSP and
Process 2 with a cDSP, then the information ﬂow is
modeled by the (Boolean) variable vector X1of the
sDSP that constitutes the parameters of the cDSP’s sys-
tem constraints as represented as gðX1;X2Þ, and/or sys-
tem goals represented as AðX1;X2Þ.
—cDSP!sDSP: One-way ﬂow from cDSP to sDSP.
Assuming that Process 1 is modeled with a cDSP and
Process 2 with an sDSP, then the information ﬂow is
modeled by the variable vector X1of the cDSP that con-
stitutes the parameters of the sDSP’s merit function rep-
resented as MFðX1ÞX2, which is a system goal in a
coupled cDSP. In this case, X2is Boolean.
—sDSP$cDSP: Two-way ﬂow between an sDSP and a
cDSP. This is modeled by the combination of the preced-
ing two types.
—cDSP!cDSP: One-way ﬂow 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.
—cDSP$cDSP: Two-way ﬂow between two cDSPs. This
is modeled by the variable vectors of both of the two
cDSPs that constitute the system constraints and goals of
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 inte-
grated 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
deﬁne the Slots of Class Interface in Table 3.
4.3 Building DSP Hierarchies Using Processes and
Interfaces. The deﬁnition of Class Process,Class Interface,
as well as the associated Slots, is facilitated by using the PROT
3.5 tool , which provides an environment for creating and
editing ontologies as well as populating Instances based on
ontologies. Three typical user-interfaces of PROT
Ein terms of
Fig. 6 Design of a portal frame 
011001-6 / Vol. 18, MARCH 2018 Transactions of the ASME
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. ), Classes of the sDSP ontology (repre-
sented by “SO,” see Ref. ), and the two Classes (high-
lighted in the box) identiﬁed in this paper for building DSP
hierarchies are listed. The window marked “›” is the Instance
editor for the Process Classes, where the Slots are created
using the deﬁnitions in Sec. 4.1 and are populated with speciﬁc
problem information. The window marked with “ﬁ” is the
Instance editor for the Interface Instances, where the Slots
are created using the deﬁnitions in Sec. 4.2 and are populated
using speciﬁc problem information.
In our ontology, building DSP hierarchies is facilitated with the
egraph widget , a graphical tool for visual editing the
Instance and relationships among Instances. The PROT
graph widget is especially suitable for building the DSP hierarchy
as the hierarchy is a network of Process Instances and Inter-
face Instance. A screenshot of the widget customized for
building the hierarchy is shown in Figs. 6–8in Sec. 5.
5 A Test Example for the Decision Support Problem
In this section, a portal frame design problem is used as an
example to illustrate the use of the ontology presented in Sec. 4.
Fig. 7 Speciﬁcation of the comprehensive model
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-7
The example is an extension of the problem considered by
Sobieszczanski-Sobieski  to demonstrate the decomposition
method in solving hierarchical design problems. The correctness
of the ontology is tested along with a reﬁnement process of the
decision model (DSP) for the portal frame design.
5.1 Creation of a Baseline Model With Limited
Information. A portal frame represents a simple hierarchical sys-
tem, 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 Pand 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 Aand Istand for each member’s cross-
sectional area and moment of inertia, respectively. Subsystem
variables are the dimensions, namely, b1,b2,h,t1,t2,t3of each
subsystem. Videnotes the vertical interactions between the parent
system and each of its subsystems. Lij represents the lateral inter-
actions between subsystems.
In the early stages of design, designers usually face the chal-
lenge 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 hfor
each beam, and does not make use of the parent variables Aand I.
In the ontological context, a Process Instance, 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 Interface Instance is created. Speciﬁcation of the
Process Instance is presented in window ‹of Fig. 9and the
information of required for the cDSP template in the Instance is
presented in window ›. It is not difﬁcult to imagine that because
of the lack of consideration of interactions among the three mem-
bers (subsystems) of the portal frame, there would be some differ-
ences among the resulting dimensions of the members. Using the
baseline model as the starting point, it is assumed that designers
will gradually reﬁne the model by considering lateral and vertical
interactions. The performance of the ontology in terms of facilitat-
ing the creation of a DSP hierarchy to support this reﬁnement is
tested in the Secs. 5.2 and 5.3. In Sec. 5.2, designers reﬁne the
baseline model by ﬁrst decomposing the model into sub-DSPs
then linking the sub-DSPs using lateral interaction information. In
Sec. 5.3, designers further reﬁne the model with the lateral inter-
actions by the incorporation of vertical interactions with a parent
DSP that supports the decision-making related to the parent sys-
tem. The model presented in Sec. 5.3 is a comprehensive model
with both lateral and vertical interactions. In Sec. 5.4, we show-
case how designers can retrieve decisions from the knowledge
base using the ontology.
5.2 Refinement of the Model With Lateral Interactions.
Based on the baseline model formulated in Sec. 5.1, designers are
able to reﬁne 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 decom-
posed into three DSPs, and the associated dependency needs to be
modeled. The model can be decomposed by separation of the
cDSP formulation in Fig. 9into three independent cDSPs based
on the dimensions of the three subsystems. The (lateral) depend-
encies 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
In our ontology, system goals are captured and used to populate
two Interface Instances, namely, “L12” and “L23,” as shown
in the canvas of Fig. 10. The three separated cDSPs are used to
Fig. 8 Query results by SQWRL
011001-8 / Vol. 18, MARCH 2018 Transactions of the ASME
instantiate three Process Instances, “M1,” “M2,” and “M3,”
which are linked by L12 and L23. Both L12 and L23 represent
strong coupling with two-way information ﬂow. The information
ﬂows are embodied in the Slots, “originalCounterpartFlow”
and “counterpartOriginalFlow,” as shown in the window under
the canvas in Fig. 10 in which the speciﬁcs 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 devia-
tion 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 Process Instances (in this case
is M1). At a computational level, all the information of the
Process and Interface Instances 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 tolera-
5.3 A Comprehensive Model With Lateral Interactions
and Vertical Interactions. In this section, the vertical interac-
tions between the parent system and subsystems, namely, V1,V2,
and V3, in Fig. 6are known and designers are assumed to further
reﬁne 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 Aiand Ii
(i¼1, 2, 3), constraints, and goals. The vertical interactions
necessitate the inclusion of constraints that match the parent
system design variables (Aand I) and the subsystem variables
Fig. 9 Speciﬁcation of the model with no interaction included
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-9
(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 Interface Instances, 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 Process Instance,
“Parent,” which is linked to the three existing subsystem level
Process Instances, M1, M2 and M3 by V1, V2, and V3,
respectively. Also, the lateral interactions, V1, V2, and V3, rep-
resent strong coupling with two-way information ﬂows. The
speciﬁcation of V1 is shown in the window under the canvas of
Fig. 7. Details of the information ﬂows are in Slots original-
CounterpartFlow and counterpartOriginalFlow. Deviation varia-
bles 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. Speciﬁca-
tion 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 difﬁcult to expect that the subsystem dimensions will
match each other very well, as in Sec. 5.2 because lateral interac-
tions are included in the model. Meanwhile, the values of the
parent system level variables will also match those of the subsys-
tem level variables (e.g., cross-sectional value of Amatches the
value of Aðb;t;hÞ) because of the consideration of vertical
5.4 Semantic Knowledge Retrieval Based on the DSP
Hierarchy Ontology. 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 work-
ﬂows as the design process evolves, as demonstrated by the fol-
lowing: (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 ﬂexible enough to incorporate
Fig. 10 Speciﬁcation of the model with only lateral interactions included
011001-10 / Vol. 18, MARCH 2018 Transactions of the ASME
new knowledge, e.g., the subsystem-level design variables, verti-
cal 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 workﬂow during the design process.
By Classes Process,Interfaces that link the Classes asso-
ciated with the selection and compromise DSPs as developed in
our previous work, we have created a comprehensive terminol-
ogy 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 knowl-
edge 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 engi-
neered systems involve the design of parent systems and depend-
ent subsystems. In decision-based design, this results in decision
network hierarchies. To support designers making such net-
worked, hierarchical decisions, capturing and representing the
associated knowledge is of critical importance. In this paper, we
propose an ontology for capturing and representing the hierarchi-
cal 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, ﬁrst, we identify the requirements for a
model that computationally represents the DSP hierarchy. Second,
based on these requirements, we formally deﬁne 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 ﬂows that
link different Processes to a hierarchy. Finally, the efﬁcacy 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 ﬂows among the decision hierarchy. In the world
of practice, when the subsystem design tasks are assigned to dif-
ferent 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 dis-
tributed to all the stakeholders. Future research opportunities lie
in the study of how decisions are made regarding distributed infor-
mation control, and how the ontology created in this paper is
adjustable in order to capture the associated decision knowledge.
Farrokh Mistree gratefully acknowledges ﬁnancial 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 Repub-
lic 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).
 Kuppuraju, N., Ganesan, S., Mistree, F., and Sobieski, J. S., 1985, “Hierarchical
Decision Making in System-Design,” Eng. Optim.,8(3), pp. 223–252.
 Shupe, J. A., Mistree, F., and Sobiesk i, J. S., 1987, “Compromise—An Effec-
tive Approach for the Hierarchical Design of Structural Systems,” Comput.
Struct.,26(6), pp. 1027–1037.
 Sobieszczanski-Sobieski, J., James, B. B., and Riley, M. F., 1987, “Structural
Sizing by Generalized, Multilevel Optimization,” AIAA J.,25(1), pp. 139–145.
 Sobieszczanski-Sobieski, J., James, B. B., and Dovi, A. R., 1985, “Structural
Optimization by Multilevel Decomposition,” AIAA J.,23(11), pp. 1775–1782.
 Sobieszczanski-Sobieski, J., 1982, “A Linear Decomposition Method for Large
Optimization Problems. Blueprint for Development,” NASA Langley Research
Center, Hampton, VA, Report No. NASA-TM-83248.
 Ahlqvist, A., Nayfeh, J. F., Kodiyalam, S., and Zarda, P. R., 2000, “Object Ori-
ented Multidisciplinary Design Optimization,” AIAA Paper No. 2000-4784.
 Li, M., and Azarm, S., 2008, “Multiobjective Collaborative Robust Optimiza-
tion With Interval Uncertainty and Interdisciplinary Uncertainty Propagation,”
ASME J. Mech. Des.,130(8), p. 081402.
 Lu, S., and Kim, H. M., 2010, “A Regularized Inexact Penalty Decomposition
Algorithm for Multidisciplinary Design Optimization Problems With Comple-
mentarity Constraints,” ASME J. Mech. Des.,132(4), p. 041005.
 Reverdy, P., Reddy, A., Martinelli, L., and Leonard, N. E., 2014, “Integrating a
Human Designer’s Preferences in Multidisciplinary Design Optimization,”
AIAA Paper No. 2014-2167.
 Bascaran, E., Bannerot, R. B., and Mistree, F., 1989, “Hierarchical Selection
Decision Support Problems in Conceptual Design,” Eng. Optim.,14(3), pp.
 Allen, J. K., Krishnamachari, R. S., Masetta, J., Pearce, D., Rigby, D., and Mis-
tree, F., 1992, “Fuzzy Compromise—An Effective Way to Solve Hierarchical
Design-Problems,” Struct. Optim.,4(2), pp. 115–120.
 Vadde, S., Allen, J. K., and Mistree, F., 1994, “The Bayesian Compromise
Decision-Support Problem for Multilevel Design Involving Uncertainty,”
ASME J. Mech. Des.,116(2), pp. 388–395.
 Vadde, S., Allen, J. K., and Mistree, F., 1994, “Compromise Decision-Support
Problems for Hierarchical Design Involving Uncertainty,” Comput. Struct.,
52(4), pp. 645–658.
 Salas, A., and Townsend, J., 1998, “Framework Requirements for MDO Appli-
cation Development,” AIAA Paper No. 98-4740.
 Phoenix Integration, 2016, “ModelCenter
,” Phoenix Integration, Blacksburg,
VA, accessed Aug. 11, 2016, http://www.phoenix-int.com/
 DASSAULT SYST
EMES, 2016, “iSIGHT & the SIMULIA Execution Engine,”
Dassault Syste`mes, V
elizy-Villacoublay, France, accessed Aug. 11, 2016, http://
 ESTECO, 2016, “modeFRONTIER,” ESTECO, Trieste, Italy, accessed Aug.
11, 2016, http://www.esteco.com/
 Hiriyannaiah, S., and Mocko, G. M., 2008, “Information Management Capabil-
ities of MDO Frameworks,” ASME Paper No. DETC2008-49934.
 Nonaka, I., and Takeu chi, H., 1995, The Knowledge-Creating Company: How
Japanese Companies Create the Dynamics of Innovation, Oxford University
Press, New York.
 Gruber, T. R., 1993, “A Translation Approach to Portable Ontology Speciﬁca-
tions,” Knowl. Acquis.,5(2), pp. 199–220.
 Ming, Z., Yan, Y., Wang, G., Santo, D. J., Allen, J. K., and Mistree, F., 2017,
“An Ontology for Reusable and Executable Decision Templates,” ASME J.
Comput. Inf. Sci. Eng.,17(3), p. 031008.
 Ming, Z., Yan, Y., Wang, G., Panchal, J. H., Goh, C. H., Allen, J. K., and
Mistree, F., 2016, “Ontology-Based Executable Design Decision Template
Representation and Reuse,” Artif. Intell. Eng. Des., Anal. Manuf.,30(04), pp.
 Lewis, K. E., Chen, W., and Schmidt, L. C., 2006, Decision Making in Engi-
neering Design, ASME Press, New York.
 Hazelrigg, G. A., 1998, “A Framework for Decision-Based Engineering
Design,” ASME J. Mech. Des.,120(4), pp. 653–658.
Table 4 SQWRL query statement for subdecisions of process Parent
Process(?p) Ùname(?p, "parent") ÙverticalDependency_Subsystem(?p,?s) ÙcounterpartProcess(?s,?sp) Ùdecision(?sp,?d) Ùname(?d,?subDecision)
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-11
 Thurston, D. L., 1991, “A Formal Method for Subjective Design Evaluatio n
With Multiple Attributes,” Res. Eng. Des.,3(2), pp. 105–122.
 Mistree, F., Smith, W. F., Bras, B. A., Allen, J. K., and Muster, D., 1990,
“Decision-Based Design: A Contemporary Paradigm for Ship Design,” Soc.
Nav. Arch. Mar. Eng., Trans.,98, pp. 565–597.
 Mistree, F., Smith, W. F., Kamal, S. Z., and Bras, B. A., 1991, “Designing
Decisions: Axioms, Models and Marine Applications,” Fourth International
Marine Systems Design Conference, Kobe, Japan, May 26–30.
 Mistree, F., Smith, W. F., and Bras, B. A., 1993, “A Decision-Based Approach
to Concurrent Engineering,” Handbook of Concurrent Engineering, H. R. Par-
saei and W. Sullivan, eds., Chapman & Hall, New York, pp. 127–158.
 Fernandez, M. G., Seepersad, C. C., Rosen, D. W., Allen, J. K., and Mistree, F.,
2005, “Decision Support in Concurrent Engineering—The Utility-Based
Selection Decision Support Problem,” Concurrent Eng. Res. A,13(1), pp.
 Bascaran, E., Mistree, F., and Bannerot, R. B., 1987, “Compromise: An Effec-
tive Approach for Solving Multiobjective Thermal Design Problems,” Eng.
Optim.,12(3), pp. 175–189.
 Mistree, F., Hughes, O. F., and Bras, B. A., 1993, “The Compromise Decision
Support Problem and the Adaptive Linear Programming Algorithm,” Structural
Optimization: Status and Promise, M. P. Kamat ed., AIAA, Washington, DC,
 Mistree, F., and Allen, J. K., 1997, “Position Paper Optimization in Decision-
Based Design,” Optimization in Industry, Palm Coast, FL, Mar. 23–27.
 Smith, W. F., 1985, “The Development of AUSEVAL: An Automated Ship
Evaluation System,” MS thesis, University of Houston, Houston, TX.
 Shupe, J. A., Allen, J. K., and Mistree, F., 1987, “Compromise: An Effective
Approach for the Design of Damage Tolerant Structures,” Comput. Struct.,
27(3), pp. 407–415.
 Bascaran, E., Bannerot, R., and Mistree, F., 1987, “The Conceptual Develop-
ment of a Method for Solving Multi-Objective Hierarchical Thermal Design
Problems,” ASME Paper No. 87-HT-62.
 Reddy, R., Smith, W., Mistree, F., Bras, B., Chen, W., Malhotra, A., Badhri-
nath, K., Lautenschlager, U., Pakala, R., and Vadde, S., 1996, “DSIDES User
Manual,” Systems Realization Laboratory, Woodruff School of Mechanical
Engineering, Georgia Institute of Technology, Atlanta, GA.
 Noy, N. F., and McGuinness, D. L., 2001, “Ontology Development 101: A Guide
to Creating Your First Ontology,” Knowledge Systems Laboratory, Stanford
University, Stanford, CA, accessed Aug. 16, 2016, https://protege.stanford.edu/
 Barbau, R., Krima, S., Rachuri, S., Narayanan, A., Fiorentini, X., Foufou, S.,
and Sriram, R. D., 2012, “OntoSTEP: Enriching Product Model Data Using
Ontologies,” Comput. Aided Des.,44(6), pp. 575–590.
 Lu, W. L., Qin, Y. C., Liu, X. J., Huang, M. F., Zhou, L. P., and Jiang, X. Q.,
2015, “Enriching the Semantics of Variational Geometric Constraint Data With
Ontology,” Comput. Aided Des.,63, pp. 72–85.
 Li, Z., Raskin, V., and Ramani, K., 2008, “Developing Engineering Ontology
for Information Retrieval,” ASME J. Comput. Inf. Sci. Eng.,8(1), p. 011003.
 Liu, Y., Lim, S. C. J., and Lee, W. B., 2013, “Product Family Design Through
Ontology-Based Faceted Component Analysis, Selection, and Optimization,”
ASME J. Mech. Des.,135(8), p. 081007.
 Rockw ell, J. A., Grosse, I. R., Krishnamurty, S., and Wileden, J. C., 2010, “A
Semantic Information Model for Capturing and Communicating Design Deci-
sions,” ASME J. Comput. Inf. Sci. Eng.,10(3), p. 031008.
 Witherell, P., Krishnamurty, S., and Gross e, I. R., 2007, “Ontologies for Sup-
porting Engineering Design Optimization,” ASME J. Comput. Inf. Sci. Eng.,
7(2), pp. 141–150.
 Chang, X. M., Rai, R., and Terpenny, J., 2010, “Development and Utilization
of Ontologies in Design for Manufacturing,” ASME J. Mech. Des.,132(2), p.
 Dinar, M., and Rosen, D. W., 2017, “A Design for Additive Manufacturing
Ontology,” ASME J. Comput. Inf. Sci. Eng.,17(2), p. 021013.
 Yang, S.-C., Patil, L., and Dutta, D., 2010, “Function Semantic Representation
(FSR): A Rule-Based Ontology for Product Functions,” ASME J. Comput. Inf.
Sci. Eng.,10(3), p. 031001.
 Bock, C., and Gruninger, M., 2005, “PSL: A Semantic Domain for Flow Mod-
els,” Software Syst. Model.,4(2), pp. 209–231.
 Karandikar, H. M., 1989, “Hierarchical Decision Making for the Integration of
Information from Design and Manufacturing Processes in Concurrent Engineer-
ing,” Ph.D. thesis, University of Houston, Houston, TX.
 Stanford University, 2016, “Prot
e 3.5 Release,” Stanford University, Stanford,
CA, accessed Aug. 11, 2016, http://protegewiki.stanford.edu/wiki/Protege_3.5_
 Stanford University, 2016, “Graph Widget of Prot
e,” Stanford University,
Stanford, CA, accessed Aug. 11, 2016, http://protegewiki.stanford.edu/wiki/
011001-12 / Vol. 18, MARCH 2018 Transactions of the ASME