ArticlePDF Available

# Ontology-Based Representation of Design Decision Hierarchies

Authors:

## Abstract and Figures

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 computational 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 retrievable, 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 workflows with multiple decisions coupling together. The core of the proposed ontology includes the coupled decision support problem (DSP) construct, and two key classes, namely, Process that represents the basic hierarchy building blocks wherein the DSPs are embedded, and Interface to represent the DSP information flows that link different Processes to a hierarchy. The efficacy of the ontology is demonstrated using a portal frame design example. Advantages of this ontology are that it is decomposable and flexible enough to accommodate the dynamic evolution of a process along the design timeline.
Content may be subject to copyright.
Zhenjun Ming
School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Haidian District,
Beijing 100081, China
Guoxin Wang
1
School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Haidian District,
Beijing 100081, China
e-mail: wangguoxin@bit.edu.cn
Yan Yan
School of Mechanical Engineering,
Beijing Institute of Technology,
No. 5 Zhongguancun South Street,
Haidian District,
Beijing 100081, China
Jitesh H. Panchal
School of Mechanical Engineering,
Purdue University,
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
Farrokh Mistree
School of Aerospace and Mechanical
Engineering,
University of Oklahoma,
Norman, OK 73019
Ontology-Based Representation
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 [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 ﬁrst by decomposing
the system into subsystems [2]. 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 [35] 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. [69]). 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
[10], and the coupled compromised decision support problem pro-
posed to solve hierarchical problems in structural design
[1,2,1113].
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 [14] from the National Aeronautics and Space
1
Corresponding author.
Contributed by the Computers and Information Division of ASME for publication
in the JOURNAL OF COMPUTING AND INFORMATION SCIENCE IN ENGINEERING. Manuscript
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 [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 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. [19], 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 [20]) 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 [21] and compromise [22]. 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
opportunities.
2 Background
2.1 Decision Support Problems and Decision Hierarchies.
Engineering design is increasingly recognized as a decision-
making process [2326]. 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 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 [2628]. 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) [3032] 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 [33], 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 [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,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 [12].
Coupled DSPs are generally multi-objective, nonlinear, mixed
discrete–continuous problems. A tailored computational environ-
ment known as DSIDES [36] incorporating the adaptive linear
programming algorithm [31] has been created to solve such
problems.
2.2 Ontology-Based Knowledge Modeling. Ontology is
deﬁned as a speciﬁcation of a conceptualization [20]; 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 [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, 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 [33]
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 [43], a design for manu-
facturing 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) 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 [5], 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 [5]
Table 1 Mathematical formulation of the coupled selection–
compromise DSP
Given
Selection
Malternatives
Nattributes
Rij normalized rating of alternative iwith respect to attribute j
Ijrelative importance of attribute j
MFimerit function for the ith alternative where
MFi¼PN
j¼1IjRij (i¼1,… , M)
Compromise
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
Find
Selection variables
Xi;e
i;eþ
i(i¼1,… , M)
Compromise variables
Yi(i¼1,… , n)
d
i;dþ
i(i¼1,… , m)
Satisfy
Selection system constraint:
PN
i¼1Xi¼1
Selection system goals:
MFiXiþe
ieþ
i¼1(i¼1,…, M)
Compromise system constraints:
giðX;YÞ¼0(i¼1,…, p)
giðX;YÞ0(i¼pþ1,…, pþq)
Compromise system goals:
Coupled goals
AiðX;YÞþd
idþ
i¼Gi(i¼1,…, m1)
Independent goals
AiðYÞþd
idþ
i¼Gi(i¼m1þ1,…, m)
Bounds
0Xi1(i¼1,…, M)
Ymin
jYjYmax
j(j¼1,…, n)
e
i;eþ
i0 and e
ieþ
i¼0(i¼1,…, M)
d
i;dþ
i0 and d
idþ
i¼0(i¼1,…, m)
Minimize
The deviation function (preemptive form):
Z¼½fqðd
i;dþ
iÞ;;f1ðe
i;eþ
iÞ or ½f1ðe
i;eþ
iÞ;;fqðd
i;dþ
iÞ
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
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 solv-
able 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
ﬂ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).”
Boolean
IsLeaf Indicator of whether the Process is the leaf (i.e., no subsystems) of the hierarchy. Two allowable
values—yes (1) or no (0).
Boolean
Decision Decision corresponding to the Process. Two allowable Classes, namely, cDSP template (see
Ref. [22]) and sDSP template (see Ref. [21]). One Processes Instance can have only one corresponding
decision, selection, or compromise.
Instance
DecisionType Indicator of the type of the corresponding decision. Two allowable values—“compromise” or
“selection.”
Symbol
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.
Instance
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.
Instance
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.
Instance
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. [22] for detailed deﬁnition). One Interface Instance can have multiple ﬂows from 1 to 2.
Instance
counterpartOriginalFlow Information ﬂow from the counterpart Process to the original Process. The deﬁnition is similar as Slot
originalCounterpartFlow.
Instance
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-
tain consistency.
4 Ontology Development for Decision Support
Problem Hierarchy
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
[47] 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
Language.
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. [48] 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
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 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
eG
e
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
EG
Ein terms of
Fig. 6 Design of a portal frame [5]
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. [22]), Classes of the sDSP ontology (repre-
sented by “SO,” see Ref. [21]), 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
PROT
eG
egraph widget [50], a graphical tool for visual editing the
Instance and relationships among Instances. The PROT
eG
e
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. 68in Sec. 5.
5 A Test Example for the Decision Support Problem
Hierarchy Ontology
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 [5] 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
cDSP.
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-
ble extent.
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
interactions.
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
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.
6 Closure
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.
Acknowledgment
Farrokh Mistree gratefully acknowledges ﬁnancial support
from the L.A. Comp Chair at the University of Oklahoma.
Funding Data
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).
References
[1] Kuppuraju, N., Ganesan, S., Mistree, F., and Sobieski, J. S., 1985, “Hierarchical
Decision Making in System-Design,” Eng. Optim.,8(3), pp. 223–252.
[2] 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.
[3] Sobieszczanski-Sobieski, J., James, B. B., and Riley, M. F., 1987, “Structural
Sizing by Generalized, Multilevel Optimization,” AIAA J.,25(1), pp. 139–145.
[4] Sobieszczanski-Sobieski, J., James, B. B., and Dovi, A. R., 1985, “Structural
Optimization by Multilevel Decomposition,” AIAA J.,23(11), pp. 1775–1782.
[5] 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.
[6] Ahlqvist, A., Nayfeh, J. F., Kodiyalam, S., and Zarda, P. R., 2000, “Object Ori-
ented Multidisciplinary Design Optimization,” AIAA Paper No. 2000-4784.
[7] 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.
[8] 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.
[9] 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.
[10] Bascaran, E., Bannerot, R. B., and Mistree, F., 1989, “Hierarchical Selection
Decision Support Problems in Conceptual Design,” Eng. Optim.,14(3), pp.
207–238.
[11] 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.
[12] Vadde, S., Allen, J. K., and Mistree, F., 1994, “The Bayesian Compromise
ASME J. Mech. Des.,116(2), pp. 388–395.
[13] Vadde, S., Allen, J. K., and Mistree, F., 1994, “Compromise Decision-Support
52(4), pp. 645–658.
[14] Salas, A., and Townsend, J., 1998, “Framework Requirements for MDO Appli-
cation Development,” AIAA Paper No. 98-4740.
[15] Phoenix Integration, 2016, “ModelCenter
V
R
,” Phoenix Integration, Blacksburg,
VA, accessed Aug. 11, 2016, http://www.phoenix-int.com/
[16] DASSAULT SYST
EMES, 2016, “iSIGHT & the SIMULIA Execution Engine,”
Dassault Syste`mes, V
elizy-Villacoublay, France, accessed Aug. 11, 2016, http://
www.3ds.com/products-services/simulia/products/isight-simulia-execution-engine/
[17] ESTECO, 2016, “modeFRONTIER,” ESTECO, Trieste, Italy, accessed Aug.
11, 2016, http://www.esteco.com/
[18] Hiriyannaiah, S., and Mocko, G. M., 2008, “Information Management Capabil-
ities of MDO Frameworks,” ASME Paper No. DETC2008-49934.
[19] Nonaka, I., and Takeu chi, H., 1995, The Knowledge-Creating Company: How
Japanese Companies Create the Dynamics of Innovation, Oxford University
Press, New York.
[20] Gruber, T. R., 1993, “A Translation Approach to Portable Ontology Speciﬁca-
tions,” Knowl. Acquis.,5(2), pp. 199–220.
[21] 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.
[22] 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.
390–405.
[23] Lewis, K. E., Chen, W., and Schmidt, L. C., 2006, Decision Making in Engi-
neering Design, ASME Press, New York.
[24] 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)
!
sqwrl:select(?p,?subDecision)
Journal of Computing and Information Science in Engineering MARCH 2018, Vol. 18 / 011001-11
[25] Thurston, D. L., 1991, “A Formal Method for Subjective Design Evaluatio n
With Multiple Attributes,” Res. Eng. Des.,3(2), pp. 105–122.
[26] 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.
[27] 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.
[28] 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.
[29] 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.
13–27.
[30] 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.
[31] 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,
pp. 247–286.
[32] Mistree, F., and Allen, J. K., 1997, “Position Paper Optimization in Decision-
Based Design,” Optimization in Industry, Palm Coast, FL, Mar. 23–27.
[33] Smith, W. F., 1985, “The Development of AUSEVAL: An Automated Ship
Evaluation System,” MS thesis, University of Houston, Houston, TX.
[34] 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.
[35] 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.
[36] 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.
[37] 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/
publications/ontology_development/ontology101.pdf
[38] 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.
[39] 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.
[40] Li, Z., Raskin, V., and Ramani, K., 2008, “Developing Engineering Ontology
for Information Retrieval,” ASME J. Comput. Inf. Sci. Eng.,8(1), p. 011003.
[41] 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.
[42] 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.
[43] 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.
[44] 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.
021009.
[45] Dinar, M., and Rosen, D. W., 2017, “A Design for Additive Manufacturing
Ontology,” ASME J. Comput. Inf. Sci. Eng.,17(2), p. 021013.
[46] 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.
[47] Bock, C., and Gruninger, M., 2005, “PSL: A Semantic Domain for Flow Mod-
els,” Software Syst. Model.,4(2), pp. 209–231.
[48] 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.
[49] Stanford University, 2016, “Prot
eg
e 3.5 Release,” Stanford University, Stanford,
CA, accessed Aug. 11, 2016, http://protegewiki.stanford.edu/wiki/Protege_3.5_
Release_Notes
[50] Stanford University, 2016, “Graph Widget of Prot
eg
e,” Stanford University,
Stanford, CA, accessed Aug. 11, 2016, http://protegewiki.stanford.edu/wiki/
Graph_Widget_Tutorial_OWL
011001-12 / Vol. 18, MARCH 2018 Transactions of the ASME
... For example, MBSE ontologies have been developed to formalize domain-specific concepts and their interrelationships using different languages [17], [18]. Some researchers have provided ontology-based approaches to facilitate the design automation for complex systems [19]. In addition, ontology and formalisms are developed for systems engineering. ...
... They are expected to provide potential solutions for combining systems engineering approaches and AI technologies. Some researchers have provided an ontologybased approach facilitating the design automation for complex systems [19], [25]. Hao et al. [26] proposed an ontology-based method to support knowledge management. ...
Article
Full-text available
Model-based systems engineering (MBSE) provides an important capability for managing the complexities of system development. MBSE empowers the formalism of system architectures for supporting model-based requirement elicitation, specification, design, development, testing, fielding, etc. However, the modeling languages and techniques are heterogeneous, even within the same enterprise system, which leads to difficulties for data interoperability. The discrepancies among data structures and language syntaxes make information exchange among MBSE models more difficult, resulting in considerable information deviations when connecting data flows across the enterprise. Therefore, this article presents an ontology based upon graphs, objects, points, properties, roles, and relationships with extensions (GOPPRRE), providing metamodels that support the various MBSE formalisms across lifecycle stages. In particular, knowledge graph models are developed to support unified model representations to further implement ontological data integration based on GOPPRRE throughout the entire lifecycle. The applicability of the MBSE formalism is verified using quantitative and qualitative approaches. Moreover, the GOPPRRE ontologies are used to create the MBSE formalisms in a domain-specific modeling tool, MetaGraph, for evaluating its availability. The results demonstrate that the proposed ontology supports the formal structures and descriptive logic of the systems engineering lifecycle.
... A. Literature review Some researchers have provided ontology-based approaches to facilitating design automation for complex systems ( [4], [5]). MBSE supports complex systems engineering and development efforts [6] by formalizing development processes, system architectures, and operational interrelationships. ...
... It is further expected to provide potential solutions for combining systems engineering approaches and AI technologies. Some researchers provide an ontology-based approach facilitating design automation for complex systems ( [4], [5]). Hao et al. proposed an ontology-based method to support knowledge management [17]. ...
Preprint
Full-text available
Model-based systems engineering (MBSE) provides an important capability for managing the complexities of system development. MBSE empowers the formalisms of system architectures for supporting model-based requirement elicitation, specification, design, development, testing, fielding, etc. However, the modeling languages and techniques are quite heterogeneous, even within the same enterprise system, which creates difficulties for data interoperability. The discrepancies among data structures and language syntaxes make information exchange among MBSE models even more difficult, resulting in considerable information deviations when connecting data flows across the enterprise. For this reason, this paper presents an ontology based upon graphs, objects, points, properties, roles, and relationships with entensions (GOPPRRE), providing meta models that support the various lifecycle stages of MBSE formalisms. In particular, knowledge-graph models are developed to support unified model representations to further implement ontological data integration based on GOPPRRE throughout the entire lifecycle. The applicability of the MBSE formalism is verified using quantitative and qualitative approaches. Moreover, the GOPPRRE ontologies are generated from the MBSE language formalisms in a domain-specific modeling tool, \textit{MetaGraph} in order to evaluate its availiablity. The results demonstrate that the proposed ontology supports both formal structures and the descriptive logic of the systems engineering lifecycle.
... This information, when gathered concurrently during the design phase of products and incorporating AI and machine learning algorithms, can assist in making judicious downstream decisions such as manufacturing, assembly, and testing [95]. For example, ontologies are well known for design knowledge modeling by representation and integration of knowledge related to decision-based design of both products and their designing processes, enabling a knowledge-based platform for decision support in the design of engineered systems [96,97]. ...
... This information, when gathered concurrently during the design phase of products and incorporating AI and machine learning algorithms, can assist in making judicious downstream decisions such as manufacturing, assembly, and testing [95]. For example, ontologies are well known for design knowledge modeling by representation and integration of knowledge related to decision-based design of both products and their designing processes, enabling a knowledge-based platform for decision support in the design of engineered systems [96,97]. ...
Article
Full-text available
Industry 4.0 is based on the digitization of manufacturing industries and has raised the prospect for substantial improvements in productivity, quality, and customer satisfaction. This digital transformation not only affects the way products are manufactured, but also creates new opportunities for the design of products, processes, services, and systems. Unlike traditional design practices based on system-centric concepts, design for these new opportunities requires a holistic view of the human (stakeholder), artefact (product) and process (realization) dimensions of the design problem. This paper envisions a ‘human-cyber-physical view of the systems realization ecosystem’, termed as ‘Design Engineering 4.0’, to reconceptualize how cyber and physical technologies can be seamlessly integrated to identify and fulfil customer needs and garner the benefits of Industry 4.0. In this paper, we review the evolution of design engineering in response to advances in several strategic areas including smart and connected products, end-to-end digital integration, customization and personalization, data-driven design, digital twins and intelligent design automation, extended supply chains and agile collaboration networks, open innovation, co-creation and crowdsourcing, product servitization, anything-as-a-service, and platformization for the sharing economy. We postulate that Design Engineering 4.0 will account for drivers such as Internet of Things, Internet of People, Internet of Services, and Internet of Commerce to deliver on the promise of Industry 4.0. Further, we identify key issues to be addressed in Design Engineering 4.0 and engage the Design Community on the challenges of the future.
... GP [27,28] is a branch of multiobjective optimization, which in turn is a branch of multi-criteria decision analysis (also known as multiple-criteria decision making). GP allows several objectives to be considered simultaneously in a problem for choosing the most satisfactory solution within a set of feasible solutions. ...
Article
Full-text available
This paper addresses the multiobjective optimization of a brake end beam of a bogie frame with consideration of three elements: the stress, fatigue, and weight. A finite-element analysis (FEA) is performed to obtain the stress distribution of the component, and the stress-life method and fatigue notch factor are used for fatigue-life assessment based on the FEA results. Subsequently, the multiobjective optimization problem in the form of mathematical functions, which considers three objectives, is handled using the design of experiments, approximation technique, analysis of variance, multiobjective algorithm, and Pareto-optimal solution. Finally, the FEA is validated according to the optimal result to verify the accuracy of the optimization. The results of this study indicate that the proposed approach is very available and has potential for the optimal design of the components of the bogie frame and/or the bogie itself.
... System. There are a large number of knowledge-based systems [3,[32][33][34][35][36] available for different engineering design problems, and mostly they are domainspecific. Ming et al. [3] developed a knowledge-based Platform for Decision Support in the Design of Engineering Systems (PDSIDES) using ontology to perform original design, adaptive design, and variant design, respectively. ...
Article
Full-text available
The designer generates a variant product by applying several design suggestions that fulfilled a variety of customer requirements. These design suggestions rely on multiple domains of expert knowledge, which are unstructured and implicit. Moreover, these design suggestions have an impact on assembly joint information (liaison), which makes the variant design a complex problem. To effectively support the designers, this work presents a knowledge-based decision support system for assembly variant design using ontology. First, a knowledge base is built by the development of an ontology to formally represent the taxonomy, properties, and causal relationships of/among core concepts involved in the variant design. Second, a five-step sequential procedure is established to facilitate the utilization of this knowledge base for decision making in variant design. The procedure takes the extracted liaison information from the CAD model of an existing product as the input and further used for generating a set of variant design decisions as the output through SWRL rule-based reasoning. The inferred outputs by the process of reasoning are the design suggestions, the variant design type required for each design suggestion, and its effect on joint information. Based on the evaluation of the ontology, the precision, recall, and F-measure obtained are 79.3%, 82.1%, and 80.67%, respectively. Finally, the efficacy of the knowledge-based decision support system is evaluated using case studies from the aerospace and automotive domain.
Chapter
In this chapter, we present methods for evaluating many solution concepts generated in Chapter 5 and choosing one to move to the next phases of prototyping and testing. Initial screening can sometimes be achieved when viewing a concept in a medical context and by applying physical principles. Sketching of solution concepts, creating a storyboard and simple prototypes are good techniques for visualization, actualization, and communication, likely raising questions about the design that were not previously realized. There are dozens of formal methods for comparing solution concepts with performance criteria (i.e., specifications); these criteria should be prioritized (weighted) in order of importance. The Decision Support and House of Quality methods are readily adaptable to biomedical engineering design and ensure a quality design process. Nontechnical factors—stakeholder resistance, economic considerations, regulatory concerns, standards compliance, and patentability—may play a role in decision-making at this stage. Feedback from healthcare providers in particular is worth seeking at this stage for guidance and to ensure the team’s understanding of the medical context is correct. Documenting this part of the process in the team’s Design History File , specifically concept selection including design rationale, sketches or drawings or both, simple prototypes and storyboards are critical for continuing work, passing on the work to another team or entity, and is mandatory for regulatory approval to commercialize a medical product.
Chapter
Achieving integrated materials and product design in the digitized world necessitates facilitating a network of participants (material scientists, systems designers, software developers, end customers) to share material/product/manufacturing process/market data, information, knowledge, and resources instantly and in an integrated fashion, and thereby collaborate so as to facilitate a cost-effective co-creation of value supporting open innovation. In this monograph, we define this as the capability to carry out co-design. New product development models like cloud-based design and cloud-based manufacturing that form part of the current digital manufacturing and design innovation (DMDI) paradigm supports people/stakeholders involved in the value chain to perform co-design for realizing materials, products, and manufacturing processes. In this chapter, we present the architecture and functionalities of a cloud-based computational platform anchored in the decision-based design paradigm to facilitate mass collaboration and open innovation, thereby supporting integrated materials and product realization. We begin the chapter by checking if the objectives planned for the monograph are addressed. We carry out a self-reflection of what has been achieved in past chapters and identify enabling technologies that require advancements to further develop the vision of the integrated design of materials, products, and processes as required by the field of integrated computational materials engineering (ICME) in the digital age. In that context, we recognize the value of a platform for facilitating integrated materials, products, and manufacturing process design in the digital age and present PDSIDES and cloud-based PDSIDES as examples to achieve the same. We illustrate the efficacy of the cloud-based platform using the hot rolling example problem to produce a steel rod, see Chap. 6 for details on the example problem. Using this example, we illustrate the utility of the cloud-based platform in carrying out seamless, yet controllable, information, knowledge, and resource sharing, thereby supporting the integrated design of materials, products, and manufacturing processes. In Table 8.1, we summarize the elements discussed, reviewed, and tested in this chapter.
Article
Full-text available
Multilevel hierarchical systems are commonplace in engineering design applications. “Optimal” design of multilevel systems is important and leads to cost effective designs. In this paper, a general overview of multilevel systems is presented. A step by step outline for optimal design of such systems and the sensitivity analysis of the resulting designs are presented. A simple example that illustrates the procedure is also included.
Article
Full-text available
In Decision Based Design (DBD) the principal role of a designer is to make decisions. Decision support is crucial to augment this role. In this paper we present a template-based ontological method that integrates the decision making mechanism with problem specific information, thus can provide design decision support from both the “construct” and the “information” perspectives. The “construct”, namely, decision making mechanism, is the utility-based Decision Support Problem (u-sDSP) which is a rigorous mathematical model that facilitates designers making multi-attribute selection decisions under uncertainty. While the information for decision making is archived as u-sDSP templates and represented using frame-based ontology to facilitate reuse, execution and consistency-maintaining. The unique advantage of this ontology is that it captures both the declarative and procedural knowledge of the selection decision and represents them separately, thus facilitates designers reusing, executing previous documented decision knowledge to effect new decisions. The efficacy of ontology is demonstrated using a Rapid Prototyping (RP) resource selection example.
Article
Full-text available
A semantic information model to improve reuse and communication of engineering design knowledge is presented in this paper We consider design to be a process involving a sequence of decisions informed by the current state of information. As such, the information model developed is structured to reflect the conceptualizations of engineering design decisions with a particular emphasis on semantically capturing design rationale. Through the approach presented, knowledge reuse is achieved by communicating design rationale. A case study is presented to illustrate two key features of the approach: (I) seamless integration of separate modular domain ontologies and instance knowledge related to engineering design that are needed to support decision making and (2) the explicit documentation of design rationale through design decisions. [DOI: 10.1115/1.3462926]
Article
Design for additive manufacturing (DFAM) gives designers new freedoms to create complex geometries and combine parts into one. However, it has its own limitations, and more importantly, requires a shift in thinking from traditional design for subtractive manufacturing. There is a lack of formal and structured guidelines, especially for novice designers. To formalize knowledge of DFAM, we have developed an ontology using formal web ontology language (OWL)/resource description framework (RDF) representations in the Protéegée tool. The description logic formalism facilitates expressing domain knowledge as well as capturing information from benchmark studies. This is demonstrated in a case study with three design features: revolute joint, threaded assembly (screw connection), and slider-crank. How multiple instances (build events) are stored and retrieved in the knowledge base is discussed in light of modeling requirements for the DFAM knowledge base: knowledge capture and reuse, supporting a tutoring system, integration into CAD tools. A set of competency questions are described to evaluate knowledge retrieval. Examples are given with SPARQL queries. Reasoning with semantic web rule language (SWRL) is exemplified for manufacturability analysis. Knowledge documentation is the main objective of the current ontology. However, description logic creates multiple opportunities for future work, including representing and reasoning about DFAM rules in a structured modular hierarchy, discovering new rules with induction, and recognizing patterns with classification, e.g., what leads to "successful" versus "unsuccessful" fabrications.
Article
In decision-based design, the principal role of a designer is to make decisions. Decision support is crucial to augment this role. In this paper, we present an ontology that provides decision support from both the “construct” and the “information” perspectives that address the gap that existing research focus on these two perspectives separately and cannot provide effective decision support. The decision support construct in the ontology is the compromise decision support problem (cDSP) that is used to make multiobjective design decisions. The information for decision making is archived as cDSP templates and represented using frame-based ontology for facilitating reuse, consistency maintaining, and rapid execution. In order to facilitate designers’ effective reuse of the populated cDSP templates ontology instances, we identified three types of modification that can be made when design consideration evolves. In our earlier work, part of the utilization (consistency checking) of the ontology has been demonstrated through a thin-walled pressure vessel redesign example. In this paper, we comprehensively present the ontology utilization including consistency checking, trade-off analysis, and design space visualization based on the pressure vessel example.
Article
Product family design (PFD) is a widely adopted strategy for product realization, especially when design requirements are diversified and multi-faceted. Due to ever-changing customer needs and the increasingly complex and integrated product design structure, PFD and its optimization have been concerned more about a rapid and contextual product analysis and variant derivation based on a multi-objective optimization scheme subject to design concerns, which are often cross disciplinary, such as product service, carbon footprint, user experience, esthetics, etc. Existing PFD modeling approaches, which are primarily structured using component attributes and assembly relationships, possess notable limitations in representing complex component and design relationships. Hence, it has restricted comprehensive PFD analysis in an agile and contextual manner. Previously, we have studied and demonstrated the feasibility of using ontology for product family modeling and have suggested a framework of faceted information search and retrieval for product family design. In this paper, several new perspectives towards PFD based on ontology modeling are presented. Firstly, new metrics of ontology-based commonality that better reveal conceptual similarity under various design perspectives are formed. Secondly, faceted concept ranking is proposed as a new ranking approach for ontology-based component search under complex and heterogeneous design requirements. Thirdly, using these ranked results, a platform selection approach that considers a maximum aggregated ranking with a minimal platform modification among various platform choices is researched. From the selected platform and the newly proposed metrics, a modified multi-objective evolutionary algorithm with an embedded feature of configuration incompatibility check is studied and deployed for the optimal selection of components. A case study of PFD using four laptop computer families is reported as our first attempt to showcase how faceted component analysis, selection, and optimization can be accomplished based on the proposed family ontology.
Article
Decisions are an important part of Concurrent Engineering and engineering design in general. Accordingly, more attention should be paid to the means and methods for making these decisions. In this article, a utility-based decision support method for the selection of an engineering design is presented. The utility-based selection decision support problem (u-sDSP) is a synthesized construct that facilitates selection decisions involving trade-offs among multiple, conflicting attributes and mitigation of risk associated with uncertain performance with respect to the attributes considered. The negative impact of unnecessary iterations on the product development cycle is reduced via the assurance of preference-consistent outcomes. Specifically, utility theory provides a mathematically rigorous means of clarifying and capturing designer preferences as well as identifying a preferred alternative in the context of stochastic uncertainty, while the selection decision support problem (DSP) – the construct within which utility theory is employed – facilitates the effective use of engineering judgment for (1) formulating and bounding decisions and (2) establishing a proper context. Application of the u-sDSP is illustrated with an example from rapid prototyping (RP), in which the goal is to select the appropriate technology and material combinations for testing the snap-fit design of a light switch cover plate assembly.
Article
Defining or understanding a product in terms of its functions facilitates a wide variety of tasks such as design synthesis, modeling, and analysis. However, the lack of a semantically correct formal representation of product functions creates a barrier to their effective capture, exchange, and reuse. This paper presents Function Semantics Representation, a rule-based ontological formalism that is consistent with the Semantic Web standards to capture different components of a product function. In particular, the Semantic Web Rule Language is used to overcome limitations in using the basic Web Ontology Language ontology to explicitly capture advanced semantics essential to completely represent product functions. This enables support for an effective reasoning mechanism to develop and validate the product function (or functional model). We present examples that demonstrate consistency checking and the ability to retrieve functionally similar products from a repository. [DOI: 10.1115/1.3462927]
Conference Paper
Multidisciplinary Design Optimization (MDO) will be applied as a decision support tool to a large-scale industrial system. The multidisciplinary system will be modeled in an object-oriented language, Adaptive Modeling Language (AML). As it is specifically designed to model concurrent engineering systems, it will be used to capture the knowledge of the overall system including the geometry and the optimization process. This paper will discuss the advantages of modeling large-scale systems in an object-oriented language.