applied

sciences
Article
Optimization Workflows for Linking Model-Based Systems
Engineering (MBSE) and Multidisciplinary Analysis and
Optimization (MDAO)
Christian Habermehl * , Gregor Höpfner , Jörg Berroth , Stephan Neumann and Georg Jacobs

Institute for Machine Elements and Systems Engineering, RWTH Aachen University, Schinkelstraße 10,
52062 Aachen, Germany; [email protected] (G.H.); [email protected] (J.B.);
[email protected] (S.N.); [email protected] (G.J.)
* Correspondence: [email protected]; Tel.: +49-241-80-95606

Abstract: Developing modern products involves numerous domains (controlling, production, en-
gineering, etc.) and disciplines (mechanics, electronics, software, etc.). The products have become
increasingly complex while their time to market has decreased. These challenges can be over-
come by Model-Based Systems Engineering (MBSE), where all development data (requirements,
architecture, etc.) is stored and linked in a system model. In an MBSE system model, product require-
ments at the system level can lead to numerous technical variants with conflicting objectives at the
parameter level. To determine the best technical variants or tradeoffs, Multidisciplinary Analysis and
Optimization (MDAO) is already being used today. Linking MBSE and MDAO allows for mutually
Citation: Habermehl, C.; Höpfner, G.;
beneficial synergies to be expected that have not yet been fully exploited. In this paper, a new
Berroth, J.; Neumann, S.; Jacobs, G.
approach to link MBSE and MDAO is proposed. The novelty compared to existing approaches is
Optimization Workflows for Linking
the reuse of existing MBSE system model data. Models developed during upstream design and
Model-Based Systems Engineering
test activities already linked to the MBSE system model were integrated into an MDAO problem.
(MBSE) and Multidisciplinary
Analysis and Optimization (MDAO).
Benefits are reduced initial and reconfiguration efforts and the resolution of the MDAO black-box
Appl. Sci. 2022, 12, 5316. https:// behavior. For the first time, the MDAO problem was modeled as a workflow using activity diagrams
doi.org/10.3390/app12115316 in the MBSE system model. For a given system architecture, this workflow finds the design variable
values that allow for the best tradeoff of objectives. The structure and behavior of the workflow
Academic Editors: Erika Ottaviano,
were formally described in the MBSE system model with SysML. The presented approach for linking
Jose Machado, Katarzyna Antosz,
Dariusz Mazurkiewicz, Yi Ren,
MBSE and MDAO is demonstrated using an example of an electric coolant pump.
Pierluigi Rea, Rochdi El Abdi,
Marina Ranga, Vijaya Keywords: model-based systems engineering; mbse; multidisciplinary analysis and optimization;
Kumar Manupati and Emilia Villani mdao; centrifugal pump; automotive coolant pump; development; design; test; optimization

Received: 7 May 2022

Accepted: 20 May 2022
Published: 24 May 2022
1. Introduction
Publisher’s Note: MDPI stays neutral 1.1. Motivation
with regard to jurisdictional claims in
Boundary conditions such as increasingly stringent emissions legislation and advanc-
published maps and institutional affil-
ing urbanization pose technological challenges for the automotive industry. In addition,
iations.
stakeholder requirements regarding functionality, quality, and cost-efficiency are increas-
ing [1]. These challenges are increasingly being met by four key trends [2]: electrification,
autonomous driving, connected vehicles, and shared mobility. All these trends require
Copyright: © 2022 by the authors.
the use of mechanical, electronic, and software systems onboard the automobile. Because
Licensee MDPI, Basel, Switzerland. of the progressive integration of these systems, modern vehicles can be understood as
This article is an open access article cyber-physical systems (CPS) [3]. A key characteristic of CPS is their complexity [4,5]. The
distributed under the terms and increasing implementation of the aforementioned trends leads to an increasing system
conditions of the Creative Commons complexity of vehicles and their systems, which must be managed in development [6].
Attribution (CC BY) license (https:// Furthermore, the rapid development and innovation of technologies lead to ever-increasing
creativecommons.org/licenses/by/ technological change [7]. To remain competitive in the market, automotive original equip-
4.0/). ment manufacturers (OEMs) and suppliers must not only continuously innovate but also

Appl. Sci. 2022, 12, 5316. https://doi.org/10.3390/app12115316 https://www.mdpi.com/journal/applsci

Appl. Sci. 2022, 12, 5316 2 of 24

keep the time to market short despite increasing complexity [8]. Cost, schedule, and scope
overruns of projects are often attributed to unmanaged complexity [9]. Overall, companies
are under pressure to develop innovative, complex products in ever shorter timeframes.
The well-known development approach of Model-Based Systems Engineering (MBSE)
offers the potential to make complexity manageable during the development of automotive
products [10]. In MBSE, development data is continuously linked in a central MBSE system
model compared to document-based, classical development approaches. In this case, “a
system model is a representation of the target system or one or more of its subsystems” [11].
It combines domain-specific and domain-independent parts (simulation models), structures
(architectures), and artifacts [11]. Development projects using MBSE are characterized,
among other things, by improved traceability and consistency in a rigorous MBSE system
model and the reuse of development data and models [12]. As a result, MBSE can help to
reduce development time and cost [13–15]. System modeling with MBSE is mostly realized
in the universal, graphical modeling language SysML. SysML thereby emphasizes aspects
of system architecting [16] but lacks in providing analytical and numerical methods. Such
methods are provided by using additional tools and toolchains [17]. These methods include
sensitivity analyses, searching design spaces for optimal solutions, and trade studies [18],
among others [19]. This lack of integration leads to a gap between system architecting
and system analysis [16]. A similar gap persists between system architecting in MBSE and
system analysis using domain-specific simulation models [20].
If requirements are formulated at the system level, with system design it is possible
to identify numerous technical variants that differ in their design variables. Fulfilling the
requirements of these technical variants can be conflicting, and a conflict of objectives can
arise that must be resolved appropriately. Since MBSE methods are usually employed
to design a small number of variants, only a few variants may be found that meet the
requirements. Accordingly, the best possible objective values are unknown, and the conflict
of objectives cannot be resolved in the best possible way. To identify technical variants with
the best possible objective values, Multidisciplinary Analysis and Optimization (MDAO)
methods are already being used today [21]. MDAO is an engineering discipline that uses
numerical optimization to design multidisciplinary systems [22]. It can examine large
areas of the design variable space. With MDAO, technical variants with optimal objective
values can be found, and the conflict of objectives can be resolved with a suitable tradeoff.
MDAO is considered in the literature to be both a method [23] and a tool [24] in developing
complex products. MDAO requires a high initial effort, which for example, in aviation, can
take 60–80% of the project time [25]. When MDAO is used in the development process, the
implementation [22] and the principles considered are often only partially formalized [25].
MDAO is then a black box on which changes such as extensions, detailing, and maintenance
are time-consuming to implement.
To solve this problem, MBSE can be used in conjunction with MDAO, and this linking
has many advantages. By formalizing an MDAO problem in the MBSE system model, its
black box behavior can be resolved. The formalization simplifies changes to the MDAO
problem, such as extensions, detailing, and maintenance, thus reducing the reconfiguration
effort. The initial effort of implementing an MDAO problem can also be reduced as
development data and models already available in the MBSE system model can be reused.

1.2. Problem Statement

Deploying MDAO in system development allows to explore large parts of the design
space, identify technical variants with the best objective values and resolve conflicting
objectives appropriately. However, several challenges arise in classical document-centered
system development approaches (Figure 1, left). These include for MDAO:
• high initial efforts due to distributed data
• high reconfiguration efforts
• black box behavior due to lack of formalization
 space, identify technical variants with the best objective values and resolve conflicting
objectives appropriately. However, several challenges arise in classical document-
centered system development approaches (Figure 1, left). These include for MDAO:
• high initial efforts due to distributed data
Appl. Sci. 2022, 12, 5316 • high reconfiguration efforts 3 of 24
• black box behavior due to lack of formalization

Figure
Figure1.1.(Left):
(Left):MDAO
MDAOinindocument-centered
document-centereddevelopment.
development.Scattered
Scattereddata
dataand
andblack
blackbox
boxbehavior.
behavior.
(Right): MDAO ininmodel-based
(Right): MDAO model-based development.
development. Single
Single source
source of and
of data dataresolved
and resolved black
black box box
behavior.
behavior.
The high initial effort arises in the setup of MDAO. Various development data of the
Theare
system high initial effort
required arises in
for MDAO. theincludes,
This setup of MDAO. Variousrequirements,
among others, developmentmodels data of and
the
system
parameterare sets.
required
This for MDAO. This
development data includes, among
is usually others,among
distributed requirements,
differentmodels
sourcesand
and
parameter
participants sets. This
in the development
project and mustdata is usually
be gathered distributed
costly. among different
Once executed, the results sources and
of MDAO
participants
must be distributedin the project
accordingly and tomust
eachbe gathered costly.
development Once with
data source executed, the results
corresponding of
effort.
MDAO must be distributed accordingly to each development data source with
Which development data and system aspects are ultimately included in MDAO and how
corresponding
they are linked effort. is oftenWhich development
not formalized, data exhibits
so MDAO and system blackaspects are ultimately
box behavior. The high
reconfiguration effort arises because changes to development
included in MDAO and how they are linked is often not formalized, so MDAO exhibits data are communicated via
several different paths. The lack of formalization makes
black box behavior. The high reconfiguration effort arises because changes to it difficult to implement changes.
The linking
development dataofare
MDAO and MBSE
communicated viaisseveral
shown different
in Figurepaths.
1, right.
TheInlack
thisofcase, the MBSE
formalization
systemitmodel
makes difficult actsto as a single source
implement changes. of truth (SSO) for MDAO, as all data (requirements,
models,
The linking of MDAO and MBSE isproduct
. . . ) related to the developed shown are centrally
in Figure stored.
1, right. The case,
In this initialtheeffort
MBSEfor
MDAO is reduced because the required development data exists
system model acts as a single source of truth (SSO) for MDAO, as all data (requirements, in the MBSE system model
in parts or completely [26]. Results of MDAO are systematically transferred to the linked
models, …) related to the developed product are centrally stored. The initial effort for
model elements of the system architecture. The formalization of MDAO in the MBSE
MDAO is reduced because the required development data exists in the MBSE system
system model resolves its black box behavior. Therefore, which and how development
model in parts or completely [26]. Results of MDAO are systematically transferred to the
data are considered in MDAO is always traceable. Changes to the development data have
linked model elements of the system architecture. The formalization of MDAO in the
an immediate effect on MDAO, so that the reconfiguration effort of the MDAO problem
MBSE system model resolves its black box behavior. Therefore, which and how
is reduced. Due to these benefits, numerous research engages with methods for linking
development data are considered in MDAO is always traceable. Changes to the
MBSE and MDAO.
development data have an immediate effect on MDAO, so that the reconfiguration effort
of theContribution
1.3. MDAO problem is reduced. Due to these benefits, numerous research engages with
methods for linking MBSE and MDAO.
Section 5 provides a review of previous research linking MBSE and MDAO. However,
existing approaches insufficiently address development data (e.g., models) reused from
1.3. Contribution
system development activities. As a result, existing potentials to reduce the initial imple-
Sectioneffort
mentation 5 provides
of MDAO a remain
review untapped.
of previous researchthelinking
Therefore, followingMBSE and question
research MDAO.
However, existing approaches
shall be answered in this paper: insufficiently address development data (e.g., models)
reused from
How system
to link MDAO development activities.
to MBSE system Astaking
models a result, existing
advantage of potentials to reduce the
existing models?
initialThe
implementation
following maineffort of MDAO
contributions remainto untapped.
are made answer the Therefore, the following
research question:
research
• question
A novel shall be
approach answered
(Section 2) isindeveloped
this paper:to link MDAO in MBSE system models.
How
The novelty lies in reusing existingmodels
to link MDAO to MBSE system taking advantage
development data. Forofthis,
existing
data models?
from the system
The following main contributions are made to answer
specification and models from design (Section 2.2.1) and test activities the research question:
(Section 2.2.2)
are reused. Utilizing an analogy (Section 2.2.3), design and test activities are mapped
to system optimization (Section 2.3). Reusing development data from design and test
activities reduces the initial effort of MDAO.
• For the first time, the MDAO problem is formalized in the MBSE system model as an
optimization workflow. The purpose is to resolve the MDAO black box behavior and
reduce the reconfiguration effort (Sections 3.1–3.3).
The approach is applied to the optimal design of an electric coolant pump, and
exemplary numerical results are presented (Section 3.4).
 optimization workflow. The purpose is to resolve the MDAO black box behavior and
reduce the reconfiguration effort (Sections 3.1–3.3).
The approach is applied to the optimal design of an electric coolant pump, and
exemplary numerical results are presented (Section 3.4).
Appl. Sci. 2022, 12, 5316 4 of 24

2. Materials and Methods

The methodological approach of this paper is shown in Figure 2. The main goal is to
2. Materials and Methods
identify an optimal parameter set for a given system architecture of an MBSE system
modelTheby methodological
reusing existing approach of this paper
development datais shown
in model in Figure
form. 2.The
Thefirst
main goalisisa system
step
to identify an optimal parameter set for a given system architecture of an MBSE system
specification in which requirements and a suitable system architecture are defined. In the
model by reusing existing development data in model form. The first step is a system
next step ofinsystem
specification design, parameters
which requirements of thesystem
and a suitable system architecture
architecture are identified.
are defined. In the In the
next step of system design, parameters of the system architecture are identified. In the meet
system test, it is verified that the system with the previously identified parameters
the defined
system test, it requirements. System
is verified that the systemdesign and
with the systemidentified
previously tests make use of models.
parameters meets theThe resul
of performing
defined system
requirements. design
System andand
design testsystem
workflows is a suitable
tests make set ofThe
use of models. parameters
result of for the
system architecture.
performing system design Based on workflows
and test the system is aspecification
suitable set ofand the models
parameters for theused
systemin system
design and Based
architecture. test, aonsystem optimization
the system problem
specification and the(MDAO) is formulated.
models used The execution
in system design and o
test, a system optimization problem (MDAO) is formulated. The
the system optimization and solution of the MDAO problem identifies an optimaexecution of the system
optimization and solution of the MDAO problem identifies an optimal parameter set for
parameter set for the system architecture. System design, system test, and the executable
the system architecture. System design, system test, and the executable part of the system
part of the system
optimization optimization
are executable are executable workflows.
workflows.

Figure2.2.Approach
Figure Approachof of
thisthis paper.
paper. Numbers
Numbers indicate
indicate manuscript
manuscript sections.
sections.

System Design and System Test are modeled as workflows in the MBSE system model.
SystemisDesign
A workflow andofSystem
a sequence Testactions
executable are modeled as workflows
(e.g., implemented in guidelines,
models, the MBSE system
standards) for a specific purpose [27]. A design workflow generates a parameter set that models
model. A workflow is a sequence of executable actions (e.g., implemented
guidelines, standards)
parameterizes the system for a specific
architecture purpose
based [27]. Arules
on calculation design
fromworkflow generates a
a set of design
parameterThese
variables. set that parameterizes
parameters thefor
describe, system architecture
example, geometricbased on calculation
dimensions and systemrules from
a set of design variables. These parameters describe, for example, geometric dimension
behavior. A test workflow is used to test the parameterized system architecture in defined
and and
cases system
checkbehavior. A test
the fulfillment workflow isIf requirements
of requirements. used to testarethenot parameterized
met, the design system
variables are adjusted, and design and test workflows are executed again.
architecture in defined cases and check the fulfillment of requirements. If requirement
With increasing system complexity, it is difficult to estimate which design variable
are not met, the design variables are adjusted, and design and test workflows are executed
changes are suitable for finding a good technical variant or any technical variant. Fur-
again. a conflict of objectives can arise that cannot be resolved appropriately by a
thermore,
manual iteration in the design and test workflows. In this case, an optimization workflow
is formulated and executed from existing models of the design and test workflows. The
result of the optimization workflow is an optimal parameter set of the system architecture.
In this paper, we proposed formalizing the optimization workflow by three modeling
approaches: workflow architecture, internal behavior, and executable behavior. The main
purposes of the formalization are the resolution of the MDAO black box behavior and the
provision of a means to parameterize the system architecture with an optimal parameter set.
The workflow architecture captures the hierarchical relationships between the workflow
elements. In the internal behavior, the black box character of the underlying MDAO of
 Appl. Sci. 2022, 12, 5316 5 of 24

the optimization workflow is resolved by formalizing the utilized models, their interfaces,
and execution orders. From this formalization, the MDAO problem is implemented in an
external tool. The executable behavior triggers the solution of the MDAO problem from
the MBSE system model. The results are fed back to the MBSE system model and provide
an optimal parameter set for the system architecture.

2.1. System Specification

For example, the optimum design of an electric coolant pump in a vehicle is considered
regarding the objectives of electric energy consumption and installation space. For this,
five design variables are considered: rotational speed, flow rate, and head (i.e., pressure
difference between pump intake and outlet) in the best efficiency design point, as well as
the impeller vane exit angle and number of impeller blades. The speed of conventional
belt-driven coolant pumps is fixed to the speed of the internal combustion engine. This
means that the flow rate cannot be supplied as required. The flow rate is therefore adapted
by throttling or bypassing, and as a result, energy losses occur. In contrast, electric coolant
pumps can provide volume flows as required by adjusting the pump speed, thus helping
to reduce energy consumption and ultimately achieve CO2 targets [28]. The optimal design
is discussed in the literature [29–32].
The main function of an electric coolant pump is to generate a flow rate. To do this,
electrical energy is converted to mechanical energy, and this mechanical energy is then
applied to the coolant. The amount of electrical energy that can be supplied to the system
is controlled to match the provided flow rate to the demand. This relationship is described
in Figure 3. The functional architecture of the generate flow rate function is modeled using
Koller’s approaches [33]. The described functions represent elementary functions that are
realized by principle solutions. In this way, functions and the physical product are linked.
The language profile SysML4FMArch was used for the modeling [3]. This approach is
Appl. Sci. 2022, 12, 5316 particularly suitable because products in the automotive industry are increasingly being 6 of 25
developed on a function-oriented basis instead of on a component-oriented basis, as has
been the case to date [34].

Figure3.3.Functional
Figure Functional architecture
architecture of main
of the the main function
function generate
generate flow
flow rate rateelectric
of the of the coolant
electricpump.
coolant pump

Principle
For solutions
linking function consist
and physicalofproduct
a physical effectengineering,
in systems that acts inalternatives
a set of active
exist in surfaces
the literature, such as the contact and channel approach (C&C-A) [35].
consisting of materials. The principle solution for the function apply mechanical energy to
Principle solutions consist of a physical effect that acts in a set of active surfaces
fluid is a hydrodynamic pump and shown as an example in Figure 4. The physical effec
consisting of materials. The principle solution for the function apply mechanical energy to
usedisina this
fluid case is hydrodynamics.
hydrodynamic pump and shown Theasactive surfaceinset
an example is formed
Figure 4. The by an impeller
physical effect and its
pump
used housing.
in this Multiple parameters
case is hydrodynamics. describe
The active theis active
surface set formed surface set, nine
by an impeller and itsof which
ultimately define the physical behavior, i.e., the physical effect of the
pump housing. Multiple parameters describe the active surface set, nine of which ultimately hydrodynamic
pump.the
define For the given
physical parameters
behavior, i.e., the and provided
physical effect ofinterface pressure and
the hydrodynamic pump. speed inputs, the
For the
physical effect calculates the acting torque and provided flow rate of the pump. The choice
of parameters is therefore decisive for whether and to what extent requirements (e.g., flow
rate) are satisfied. The parameter values are determined by an appropriate developmen
process.
 Principle solutions consist of a physical effect that acts in a set of active surfaces
consisting of materials. The principle solution for the function apply mechanical energy to
fluid is a hydrodynamic pump and shown as an example in Figure 4. The physical effect
used in this case is hydrodynamics. The active surface set is formed by an impeller and its
pump housing. Multiple parameters describe the active surface set, nine of which
Appl. Sci. 2022, 12, 5316 6 of 24
ultimately define the physical behavior, i.e., the physical effect of the hydrodynamic
pump. For the given parameters and provided interface pressure and speed inputs, the
physical effect calculates the acting torque and provided flow rate of the pump. The choice
given parameters and provided interface pressure and speed inputs, the physical effect
of parameters
calculates theisacting
therefore decisive
torque for whether
and provided and
flow rate ofto
thewhat extent
pump. requirements
The choice (e.g., flow
of parameters
rate) are satisfied. The parameter values are determined by an appropriate development
is therefore decisive for whether and to what extent requirements (e.g., flow rate) are
process.
satisfied. The parameter values are determined by an appropriate development process.

Figure 4. 4.
Figure Architecture
Architectureofofthethe hydrodynamic pumpasasa principle
hydrodynamic pump a principle solution
solution of function
of the apply apply
the function
mechanical energy
mechanical energytotofluid.
fluid.

2.2. System Design and Test

2.2.1. Design Workflow
Design workflows can identify suitable parameter values of the solution architec-
ture [27]. A design workflow model established procedures for design, such as those given
in norms, standards, and guidelines in an executable form in the MBSE system model. The
design workflow is modeled as an activity diagram for this purpose. The design workflow
of a pump impeller is shown as an example in Figure 5. It is divided into three sections: get,
calculate and set.
The design of the pump impeller requires the selected values of the design variables to
perform calculations. Actions in the get section, therefore, read the associated values from
the MBSE system model and make them available for further actions. The following five
design variables (cf. get section Figure 5) are set by the systems engineer and read from the
MBSE system model:
• Rotational speed nOpt , flow rate QOpt and head Hopt in the best efficiency design point
indexed as Opt
• Impeller vane exit angle β 2
• Number of impeller blades zU
The calculate section contains actions that use methods to calculate parameter values
of the principle solution. These actions can represent simple analytical relationships (as in
calculatePumpInstallationSpace) or trigger extensive calculations stored in external tools (as
in calculatePumpDimensions). Although the design of the pump is based on principles of
hydrodynamics, the calculation in calculatePumpDimensions differs from the model of the
 Appl. Sci. 2022, 12, 5316 7 of 24

physical effect in Figure 4. The physical effect models the in- (rotational speed and pressure
Appl. Sci. 2022, 12, 5316 difference) and output (torque and flow rate) behavior of the pump. In contrast, the design7 of 25
workflow determines the necessary parameters of the physical effect. After the calculations
in the workflow, the parameter values must be transferred back to the MBSE system model.
The values can be used by further calculations or checked for requirement satisfaction. The
2.2. System Design and Test
following eleven parameter values (cf. set section in Figure 5) are calculated from the five
2.2.1. Design
design Workflow
variables and written back to the MBSE system model:
• Design workflows
Parameter can
values of theidentify suitable parameter
pump characteristic curve a, values
b, c, d of the solution architecture
[27].
• A Head
design workflow
coefficient ψThmodel established procedures for design, such as those given in
•
norms, standards, and guidelines
Impeller diameter D2 and widthin ban
2 executable form in the MBSE system model. The
• Pump installation space VPump
design workflow is modeled as an activity diagram for this purpose. The design workflow
• Shaft power at zero net flow rate P0
of a pump impeller is shown as an example in Figure 5. It is divided into three sections:
• Exchange flow rate at zero net flow rate Q a
get,• calculate and set.
Characteristic pump rotational speed nq

Figure 5. 5.
Figure Design
Designworkflow
workflow for
for the designofofa apump
the design pump impeller.
impeller.

2.2.2. Test Workflow

The design of the pump impeller requires the selected values of the design variables
to perform calculations.
Design workflows Actions
determineinparameter
the get section,
values therefore,
of principleread the associated
solutions for definedvalues
design scenarios. With this determined parameter value set, a technical variant is created.
from the MBSE system model and make them available for further actions. The following
In contrast to design workflows, test workflows check whether the developed technical
five design variables (cf. get section Figure 5) are set by the systems engineer and read
variant meets all requirements. This is necessary because not all boundary conditions and
from the MBSEare
requirements system model:
generally considered in the design. For example, hydrodynamic pumps
• areRotational speed
designed for , flow rate
𝑛𝑛𝑂𝑂𝑂𝑂𝑂𝑂efficiency
the best 𝑄𝑄𝑂𝑂𝑂𝑂𝑂𝑂
point and head
consisting 𝐻𝐻𝑜𝑜𝑜𝑜𝑜𝑜 in the
of rotational bestflow
speed, efficiency design
rate, and
point indexed as Opt
head (pressure difference between pump intake and output). During operation, however,
• theImpeller
speed isvane
varied to angle
exit adapt 𝛽𝛽 the flow rate to the heat dissipation requirements in the
2
cooling circuit. The pump is then operated off the best efficiency point. The resulting
• Number of impeller blades 𝑧𝑧𝑈𝑈
energy consumption in operation is, therefore, a quantity that is not captured by the design
The calculate
workflow sectionin
but calculated contains
the test actions
workflow.that use methods
Identifying to calculate
the most suitable parameter
design pointvalues
of the principle
considering thesolution. These is
later operation actions can represent
an engineering simple analytical relationships (as in
challenge.
calculatePumpInstallationSpace)
In this paper, the exemplaryor requirements
trigger extensive
for thecalculations stored
electric coolant in external
pump, as showntools
in (as
calculatePumpDimensions).
in Figure 6 will be considered forAlthough the design of the pump is based on principles of
the test workflow.
hydrodynamics, the calculation in calculatePumpDimensions differs from the model of the
physical effect in Figure 4. The physical effect models the in- (rotational speed and
pressure difference) and output (torque and flow rate) behavior of the pump. In contrast,
the design workflow determines the necessary parameters of the physical effect. After the
 cooling circuit. The pump is then operated off the best efficiency point. The resulting
energy consumption in operation is, therefore, a quantity that is not captured by the
design workflow but calculated in the test workflow. Identifying the most suitable design
point considering the later operation is an engineering challenge.
In this paper, the exemplary requirements for the electric coolant pump, as shown in 8 of 24
Appl. Sci. 2022, 12, 5316

Figure 6 will be considered for the test workflow.

Figure 6. Requirements
Figureof
6. the electric coolant
Requirements pump.coolant pump.
of the electric

From the higher-level

From therequirements for high efficiency,
higher-level requirements low installation
for high efficiency, space, space,
low installation and and
stable operation, a range of values are derived for the head coefficient. The head coefficient
stable operation,is aa characteristic
range of values are derived for the head coefficient. The head
value calculated from the physical quantities of a pump and characterizes
its operating behavior [36]. The head coefficient should be as high as possible for compact
and efficient pumps [37]. A lower bound of ψTh,min = 1.0 is therefore selected. However,
a head coefficient that is too high can lead to unstable flow rate behavior and vibration
excitations in the cooling circuit [38]. The value of the head coefficient is therefore limited to
ψTh,max = 1.3 using a practical value according to [39]. The installation space requirement
is further refined in maximum impeller diameter and width. These limits depend on the
application and are here set to D2,max = 150 mm and b2,max = 30 mm. Additionally, the
1
pump shall be operated at a maximum speed of nmax = 2500 min for noise and material
strength reasons. Further requirements weigh the importance of installation space and
efficiency of the pump. The so defined weights can be used to compare different technical
variants. The WLTC is used as the design cycle. The pump must provide enough flow rate
to dissipate the heat generated by the engine in the cycle. The requirements are checked
utilizing constraint elements in the MBSE system model. For brevity, only one such element
is shown in Figure 6 for the upper limit of the head coefficient. These constraints are later
reused identically in MDAO.
A test workflow is modeled similarly to the design workflow in an activity diagram
(Figure 7). It consists of the sections get, calculate, and set. In the present example, two
successive tests in the form of simulations are performed: A mechanical (calculateMech-
Power) and an electrical (calculateElEnergy) performance test. The implementations of
 Appl. Sci. 2022, 12, 5316 9 of 24

calculateMechPower and calculateElEnergy are described in detail in Section 3.4. For the
mechanical performance test, the previously determined pump impeller design variable
values and the flow rate cycle are loaded using get actions. The mechanical performance
test determines the time histories of the mechanical pump torque and rotational speed,
as well as the maximum required pump speed ncycle,max in the flow rate cycle. For the
electrical performance test, parameter values of the electric motor are loaded by means of
get actions. This test receives the additional time histories of torque and speed and calcu-
lates the consumed electrical energy EEl in the flow rate cycle. The design of the electric
motor is not considered in this paper. Therefore, the parameter values of the electric motor
remain constant. After the electrical performance test, the results of the test workflow are
transferred back to the MBSE system model using set actions, that is, the parameter values
of ncycle,max and EEl . There, it is checked to see whether the specified requirements are met.
For example, the permitted maximum speed is compared to the calculated quantitative
Appl. Sci. 2022, 12, 5316 value. The consumption of electrical energy is not further specified in the requirements; 10 of 25
thus, it could be compared to benchmarks and technical variants. If requirements are not
met, a new and suitable technical variant must be found.

Figure 7. 7.
Figure Test
Testworkflow
workflowfor
for the electriccoolant
the electric coolantpump.
pump. The The implementations
implementations of calculateMechPower
of calculateMechPower
calculateElEnergy
andand calculateElEnergyare
aredescribed indetail
described in detailininSection
Section3.4.3.4.

2.2.3. Design
2.2.3. and
Design andTest
TestProcess
Process
The process of executing the design and test workflows is shown in Figure 8. This
The process of executing the design and test workflows is shown in Figure 8. This
manual process is characterized by decisions at each stage based on intuition or experi-
manual process is characterized by decisions at each stage based on intuition or
ence [40].
experience
First,[40].
in Figure 8, the system is specified in the MBSE system model. The system
specification includes the collection and definition of requirements and the derivation of
a suitable functional and solution architecture. From this, simulation models are derived
and linked in design and test workflows. The design workflow uses these models and
other calculations (norms, standards, and guidelines) to determine the parameters of the
solution architecture. In the test workflow, parameter values are calculated and checked
for requirement satisfaction. If requirements are not met, the design variables are changed,
and the design and test workflows are executed again. If the requirements are met, the
design can be approved and detailed. There may arise the case that no technical variant
 Figure 7. Test workflow for the electric coolant pump. The implementations of calculateMechPower
and calculateElEnergy are described in detail in Section 3.4.
Appl. Sci. 2022, 12, 5316 10 of 24

2.2.3. Design and Test Process

canThe
fulfillprocess of executing
the requirements. the
Then design andcan
requirements test
be workflows is shown
relaxed, or they can be in Figureto8. This
returned
manual process is characterized by decisions at each stage based on
a previous development phase to adapt the system architecture. These two cases are intuition
not or
experience
considered[40].
in this paper.

Figure 8. Manual iteration using design and test workflows.

Figure 8. Manual iteration using design and test workflows.

First,
In thein Figure
case of the 8, the system
electric is specified
coolant pump, inany
there are thenumber
MBSEofsystem model.
technical variantsThe
thatsystem
specification includes
meet the exemplary the collection
requirements and
(Figure 6).definition of requirements
However, during the design andandtest
theactivities,
derivation of
a the
suitable
pumpfunctional
installation and
spacesolution architecture.
and electric From this,arise
energy consumption simulation models
as conflicting are derived
objectives.
This means that the requirements for the highest efficiency and smallest
and linked in design and test workflows. The design workflow uses these models installation space and
are met to varying degrees by different technical variants.
other calculations (norms, standards, and guidelines) to determine the parameters of the
With increasing system complexity, it is difficult to estimate which design variable
solution
changesarchitecture. Infinding
are suitable for the test workflow,
a good variantparameter
or any variant values
at all.are calculated itand
Furthermore, checked
is un-
for requirement
clear which design satisfaction. Ifparticularly
variables are requirements are not
suitable met, the design
for responding variableschanges.
to requirement are changed,
and the design and test workflows are executed again. If the requirements are met, the
design can be
2.3. System approved and detailed. There may arise the case that no technical variant
Optimization
can fulfill the requirements.
To avoid a costly manual Then requirements
iteration, an analogy canofbetherelaxed,
design and or they can be returned
test process with to
a previous development phase to adapt the system architecture. These two cases
a general MDAO process (Figure 9) is considered. Similar to the manual iteration, theare not
considered in this
process starts withpaper.
a system specification. In addition, the optimization problem must
be formulated. If the optimization algorithm needs starting values, an initial system
In the case of the electric coolant pump, there are any number of technical variants
design is provided. The optimization itself is divided into two parts: analysis and the
that meet the exemplary requirements (Figure 6). However, during the design and test
optimization algorithm. In the analysis, objective and constraint functions are evaluated.
In the manual iteration, this corresponds to the execution of the test workflow as well
as the requirement verification. In the case of optimization, quantifiable requirements
are formulated as constraint functions and evaluated automatically by the optimization
algorithm. The contents of the analysis can be selected freely. If the execution of the
test workflow requires a previous execution of the design workflow, it can be placed in
the analysis. The optimization algorithm receives the evaluated objective and constraint
function values and uses defined criteria to decide whether optimality has been achieved.
If not, the design variables are updated and supplied to the analysis. This iteration is
performed until optimality is reached. If optimality is reached, the optimization outputs
one or more optimal technical system variants. If several optimal technical system variants
are available (e.g., in the case of multiobjective optimization), a selection of the best tradeoff
must then be made by the system engineer based on preferences [41].
Compared to the manual iteration (Figure 8), the variation of design variables is per-
formed systematically. Requirement changes can be met by reformulating the constraints.
To make use of the MDAO process in the MBSE system model an optimization work-
flow is proposed.
 function values and uses defined criteria to decide whether optimality has been achieved.
If not, the design variables are updated and supplied to the analysis. This iteration is
performed until optimality is reached. If optimality is reached, the optimization outputs
one or more optimal technical system variants. If several optimal technical system variants
Appl. Sci. 2022, 12, 5316 11 of 24
are available (e.g., in the case of multiobjective optimization), a selection of the best
tradeoff must then be made by the system engineer based on preferences [41].

Figure
Figure9.9.Optimization-based iteration.
Optimization-based iteration.

Compared
3. Results: to the manual
Optimization Workflowiteration (Figure 8), the variation of design variables is
performed systematically. Requirement changes can be met by reformulating the
3.1. Workflow Architecture
Appl. Sci. 2022, 12, 5316
The architecture of the optimization workflow describes the hierarchical relationships 12 of 2
constraints.
Toelements
of its make use of therefore,
and is, the MDAO process
part of in the MBSE
the formalization system
process model
in Figure 2. Theanworkflow
optimization
architecture is
workflow is proposed.modeled as a block definition diagram (bdd) and is shown in Figure 10.
of the sections
Similar get,and
to the design calculate and set. Calculate
test workflows, consists
the optimization of the parts
workflow optimize
consists and select. The
of the sections
get, calculate and set. Calculate consists of the parts optimize and select. The block select is
3. block
Results:select is used to select
Optimization the most suitable tradeoff if multiple optimal variants are
Workflow
used to select the most suitable tradeoff if multiple optimal variants are available. Optimize
available.
3.1. Workflow Optimize consists of an analysis and an optimization algorithm (corresponding
consists of anArchitecture
analysis and an optimization algorithm (corresponding Figure 9). [In the analy-
Figure 9). [In
andthe analysis, objectives, and constraints (implemented as functions) are
sis, The architecture
objectives, of (implemented
constraints the optimization workflow
as functions) describes
are evaluated. The the hierarchical
optimization
evaluated. The optimization algorithm
algorithm performs the optimization task. performs the optimization task.
relationships of its elements and is, therefore, part of the formalization process in Figure
2. The workflow architecture is modeled as a block definition diagram (bdd) and is shown
in Figure 10. Similar to the design and test workflows, the optimization workflow consists

Figure10.
Figure 10.Architecture
Architecture of the
of the Optimization
Optimization Workflow.
Workflow.

3.2. Internal Behavior

3.2. Internal Behavior
The internal behavior describes the sequence and execution order of the optimization
The internal
workflow elements.behavior describes
It includes the sequence
the definition and execution
of used models, order of
the exchanged the optimization
parameters
workflow
at elements.
interfaces, It includes
and considered the requirements
system definition of in
used models,
MDAO. It isthe
alsoexchanged parameter
the workflow
at interfaces, and considered system requirements in MDAO. It is also the
architecture part of the formalization process in Figure 2. The internal behavior of the workflow
architecture part of the formalization process in Figure 2. The internal behavior of the
optimize block (Figure 11) describes the exchange of design variables as well as evaluated
objective functions 𝑓𝑓 and constraint functions 𝑔𝑔 between the optimization algorithm and
the analysis (cf. Figure 9).
 3.2. Internal Behavior
The internal behavior describes the sequence and execution order of the optimization
workflow elements. It includes the definition of used models, the exchanged parameter
at interfaces, and considered system requirements in MDAO. It is also the workflow
Appl. Sci. 2022, 12, 5316 12 of 24

architecture part of the formalization process in Figure 2. The internal behavior of the
optimize block (Figure 11) describes the exchange of design variables as well as evaluated
optimize block (Figure 11) describes the exchange of design variables as well as evaluated
objective functions 𝑓𝑓 and constraint functions 𝑔𝑔 between the optimization algorithm and
objective functions f and constraint functions g between the optimization algorithm and the
the analysis
analysis (cf. Figure
(cf. Figure 9). 9).

Figure11.
Figure 11.Internal
Internal behavior
behavior of the
of the workflow
workflow element
element optimize.
optimize.

The internal behavior of the objectives block is shown in Figure 12. In this depiction,
The internal behavior of the objectives block is shown in Figure 12. In this depiction
Appl. Sci. 2022, 12, 5316 the design variables and the objectives are defined. For example, all design variables 13 of of
25
the design variables and the objectives are defined. For example, all design variables o
the design workflow were adopted (cf. Figure 5). The objectives were defined based on
theidentified
the design workflow
conflict of were adopted
objectives in the(cf. Figure
manual 5). The(pump
iteration objectives were space
installation defined
andbased on
the identified
electrical energy
electrical conflict of objectives
energy consumption). Model in
consumption). Model
the manual
elements
elements of
iteration
the design
of the (pump installation space and
design (calculatePumpDimensions,
(calculatePumpDimensions,
calculatePumpInstallationSpace) and test (calculateMechPower, calculateElEnergy) workflows
calculatePumpInstallationSpace) and test (calculateMechPower, calculateElEnergy) workflows
were reused
were reused in
in the
the description
description of
of the
the internal
internal behavior
behavior (cf.
(cf. Figures
Figures 55 and
and 7).
7).

Figure 12.
Figure 12. Calculation
Calculation of
ofobjectives.
objectives.Definition
Definitionofofdesign
design variables
variables at at
thethe
toptop
leftleft
andand objectives
objectives at
at the
the top right.
top right.

The activity diagram for calculating the constraints is given in Figure 13. On the input
side, the calculation receives the current values of the design variables. On the output side,
the values of the constraint functions (𝑔𝑔1 … 𝑔𝑔5 ) are returned. The values of the constraints
result in the execution of actions of the design (calculatePumpDimensions) and test
(calculateMechPower) workflows. The actions for checking the requirements use the same
Appl. Sci. 2022, 12, 5316 13 of 24

The activity diagram for calculating the constraints is given in Figure 13. On the
input side, the calculation receives the current values of the design variables. On the
output side, the values of the constraint functions (g1 . . . g5 ) are returned. The values of
14 of 25
the constraints result in the execution of actions of the design (calculatePumpDimensions)
and test (calculateMechPower) workflows. The actions for checking the requirements use the
same constraints that refine the requirements (cf. Figure 6).

Figure 13. Activity diagram

Figure 13.for the constraint
Activity calculation.
diagram for the constraint calculation.

3.3. Executable Behavior

3.3. Executable Behavior The executable behavior of the optimization workflow triggers the solution of the
The executableMDAO
behavior
problem ofinthe optimization
an external workflow
tool. The executable triggers
behavior the solution
of the optimization of the
workflow
is modeled in an activity diagram (Figure 14). In the get section, necessary parameters
MDAO problem in an external tool. The executable behavior of the optimization
such as the flow rate cycle are read out from the MBSE system model and provided to
workflow is modeled in an section.
the calculate activityThe diagram
upper and(Figure 14). In
lower variation the get
bounds of thesection, necessary
design variables are
parameters such as the flow rate cycle are read out from the MBSE system model and
loaded collectively in the Boundaries action. These limits can be based on empirical values
or physical limits. Furthermore, the parameter values of the requirements (B2max, D2max,
provided to the calculate section. The upper and lower variation bounds of the design
PsiThmax, PsiThmin, Nmax) are loaded, and thus the constraints of the optimization are
variables are loaded collectively
parameterized. in the
In this Boundaries
paper, action.isThese
a genetic algorithm used forlimits can beTherefore,
optimization. based on a
empirical values or physical limits. Furthermore, the parameter values of the
hyperparameter of the population size is loaded. The two weights, WVPump and WEel, are
used to select the technical variant with the best tradeoff between installation space and
requirements (B2max, D2max, PsiThmax, PsiThmin, Nmax) are loaded, and thus the
electrical energy consumption from the resulting pareto front. The numerical values of the
constraints of the optimization
weights are defined arein parameterized.
the requirements (cf.In this6).paper, a genetic algorithm is
Figure
used for optimization. The
Therefore, a hyperparameter
calculate section of the
consists of an optimize andpopulation
a select action.size is loaded.
Optimize The
calculates a
matrix of non-dominating technical variants (pareto front) by solving the optimization prob-
two weights, WVPump and WEel, are used to select the technical variant with the best
lem. The optimize action is implemented in an external tool reusing the predefined models
tradeoff between installation
in the internalspace
behavior and electrical
description. energy
This consumption
corresponds from the process
to the implementation resulting
in
pareto front. The numerical values of the weights are defined in the requirements (cf.
Figure 2. The select action weights the technical variants on the pareto front to determine
Figure 6).
The calculate section consists of an optimize and a select action. Optimize calculates a
matrix of non-dominating technical variants (pareto front) by solving the optimization
Appl. Sci. 2022, 12, 5316 14 of 24

Appl. Sci. 2022, 12, 5316 15 of 25

the best tradeoff. In the set section, the design variable values of the selected tradeoff are
transferred to the MBSE system model to be checked for requirement satisfaction.

Figure 14. Executable optimization workflow.

Figure 14. Executable optimization workflow.

New
In therequirements,
MBSE systemother model,objectives, and design
the optimize action variables, as well
exhibits black asbehavior,
box new calculation
which
steps, represent changes to the internal behavior of the optimization workflow.
is resolved with the help of the workflow architecture (Figure 10) and internal behavior These
changes 11
(Figures must
andbe12).
specified in the internal behavior by the systems engineer and, on this
basis,Changes
reimplemented in new executable
in the requirement valuesbehavior.
(maximum diameter, flow rate cycle, etc.) can
directly be considered in the optimization execution. For this purpose, the values linked to
3.4. Numerical Results
the requirements are automatically transferred to the optimize action by the corresponding
Executing
actions the optimization
(D2max, FlowRateCycle, etc.)workflow (cf.Likewise,
in Figure 14. Figure 2) theproduces numerical
variation limits of theresults,
design
which arecan
variables presented below.
be changed viaThe
the visualization of theThis
defined interfaces. resulting
reducesMDAO problem is given
the reconfiguration as
effort
an extended
of the MDAOdesign structure matrix (XDSM) in Figure 15. A Matlab implementation of
problem.
the genetic algorithm NSGA-II
New requirements, is used asand
other objectives, the design
optimization algorithm,
variables, which
as well as new can handle
calculation
discrete and real-valued design variables and consider constraints and multiple
steps, represent changes to the internal behavior of the optimization workflow. These
objectives. The algorithm is suitable for optimizing various engineering problems ranging
changes must be specified in the internal behavior by the systems engineer and, on this
from gearboxes [42,43] to wind farms [44,45].
basis, reimplemented in new executable behavior.

3.4. Numerical Results

Executing the optimization workflow (cf. Figure 2) produces numerical results, which
are presented below. The visualization of the resulting MDAO problem is given as an
extended design structure matrix (XDSM) in Figure 15. A Matlab implementation of
the genetic algorithm NSGA-II is used as the optimization algorithm, which can handle
discrete and real-valued design variables and consider constraints and multiple objec-
tives. The algorithm is suitable for optimizing various engineering problems ranging from
gearboxes [42,43] to wind farms [44,45].
A pump is designed based on five design variables. With this design, a mechanical
shaft power must be provided to the pump for a given flow rate cycle. The connected
electrical motor provides this shaft power and consumes an amount of electrical energy
in the process. Four variables (head coefficient ψTh , maximum rotational speed nmax ,
maximum impeller width b2 and diameter D2 ) are constrained by five nonlinear constraints
 3.4. Numerical Results
Executing the optimization workflow (cf. Figure 2) produces numerical resul
which are presented below. The visualization of the resulting MDAO problem is given
Appl. Sci. 2022, 12, 5316 an extended design structure matrix (XDSM) in Figure 15. A Matlab implementation
15 of 24
the genetic algorithm NSGA-II is used as the optimization algorithm, which can hand
discrete and real-valued design variables and consider constraints and multip
objectives. The algorithm is suitable for optimizing various engineering problems rangi
(g), which are given by the system requirements (Figure 6). The installation space of the
from gearboxes [42,43] to wind farms [44,45].
pump VPump ( f 1 ) and the required amount of electrical energy EEl ( f 2 ) are objectives.

Figure 15. XDSM of the optimization problem.

The design of the electric coolant pump is based on the procedure in [39]. The design
determines the flow characteristics (described by the pump characteristic curve), efficiency,
and spatial dimensions of the pump. In the design process under consideration, five design
variables are available for this purpose: pump rotational speed nOpt , flow rate QOpt and
head Hopt in the best efficiency point as well as impeller vane exit angle β 2 and number
of impeller blades zU . The mathematical optimization problem is formulated as follows
(Equation (1)):

minimize f ( x ) = VPump , EEl

by varying x = nOpt , QOpt , Hopt , β 2 , zU
subject to g1 ( x ) = D2 − D2,max < 0
g2 ( x ) = b2 − b2,max < 0 (1)
g3 ( x ) = ncycle,max − nmax < 0
g4 ( x ) = ψTh − ψTh,max < 0
g5 ( x ) = ψTh,min − ψTh < 0
The pump characteristic curve (Equation (2)) defines the head H and flow rate Q
behavior of the pump at constant rotational speed. The coefficients a, b, c, and d are
functions of ψTh , QOpt , HOpt and nq and determined using the design workflow.

H = a · Q3 + b · Q2 + c · Q + d (2)

The system characteristic curve describes the head and flow rate behavior of the
cooling circuit. An operating point consisting of head and flow rate is set as the intersection
of the pump characteristic curve and the system characteristic curve. In the considered
pump application, the necessary flow rate depends on the amount of heat to be dissipated
by the cooling circuit. The operating point is therefore changed by adjusting the pump
rotational speed. This operating point shift is modeled by scaling the pump characteristic
curve according to the affinity laws in Equations (3) and (4). Index I indicates the unscaled,
and index II the scaled operating point. The system characteristic curve remains constant.
 
QI I nI I
= (3)
QI nI
 2
HI I nI I
= (4)
HI nI
 Appl. Sci. 2022, 12, 5316 16 of 24

Appl. Sci. 2022, 12, 5316 1

These relationships are shown in Figure 16. Changing the pump speed to adjust the
flow rate to the demand generally results in a decrease in pump efficiency η.

Figure 16. Pump characteristic and system head curves as well as pump efficiency curves.
Figure 16. Pump characteristic and system head curves as well as pump efficiency curves.
In this paper, the coolant flow rate requirement of an internal combustion engine for a
In this
mid-size paper,
vehicle the
in the coolant flow
Worldwide rate requirement
harmonized of an Test
Light-duty vehicles internal
Cycle combustion
(WLTC) is eng
considered. In the driving cycle, the engine power and, therefore, heat generation varies
aover
mid-size vehicle in the Worldwide harmonized Light-duty vehicles Test Cycle (W
time. This results in a varying coolant flow rate. Due to the varying flow rate, the
ispump
considered. In the driving
is not operated cycle,
continuously thebest
at its engine power
efficiency and,
point. therefore,
The resulting heat generation
operating
over
rangetime.
of theThis
pump results in a varying
in the WLTC is given incoolant
Table 1.flow rate. Due
For efficient to theitvarying
operation, is crucialflow ra
pump is not operated continuously at its best efficiency point. The resulting
to appropriately select the best efficiency point of the pump along with the number of ope
impeller blades and impeller vane exit angle.
range of the pump in the WLTC is given in Table 1. For efficient operation, it is cru
appropriately
Table 1. Maximumselect the best
and minimum flow efficiency
rate and headpoint
values inofthethe pump along with the num
WLTC.
impeller blades and impeller vane exit angle.
Variable Q H
Lower limit l 4.9 kPa
30 min
Table 1. Maximum and minimum flow rate and
l head values in the WLTC.
Upper limit 363.4 min 30 kPa

Variable 𝑸𝑸 𝑯𝑯
The installation space of the pump impeller ( f 1 in𝑙𝑙 Figure 15) is calculated from its diam-
Lowerwhich
eter and width, limitare provided by the pump 30 dimensioning. The pump dimensioning 4.9 kPa
𝑚𝑚𝑚𝑚𝑚𝑚
𝑙𝑙
provides aUpper
total oflimit
nine quantities for calculating363.4
the mechanical shaft power (Figure 30 15).
kPa
The mechanical shaft power of the pump Psha𝑚𝑚𝑚𝑚𝑚𝑚 ft is composed of four components
(Equation (5)). Ph is the hydrodynamic power and takes into account power for conveying
Theflow
the net installation
rate and thespace of the
occurring gappump impeller
loss flows. The disk (𝑓𝑓1friction
in Figure
power 15)
PR is calculated fr
includes
diameter and by
all losses caused width, whichonare
fluid friction provided
rotating components by wetted
the pump dimensioning.
by the pumped coolant. The
The mechanical power Pm includes all losses that occur at the bearings and dynamic seals.
dimensioning provides a total of nine quantities for calculating the mechanica
Exchange losses Pa occur mainly when the pump is operated at a significantly lower flow
power
rate than(Figure
the best15).
efficiency point. The pump is then in partial load operation, characterized
The mechanical
by turbulence behind theshaft
pumppower
impeller.ofBackflows
the pump occur, which is
𝑃𝑃𝑠𝑠ℎ𝑎𝑎𝑎𝑎𝑎𝑎 actcomposed of four comp
back on the impeller
(Equation (5)). 𝑃𝑃ℎ is the hydrodynamic
and are captured in the additional power Pa . power and takes into account pow
conveying the net flow ratePand =the occurring gap loss flows. The disk friction
Ph + PR + Pm + Pa (5)
pow
sha f t
includes all losses caused by fluid friction on rotating components wetted by the pu
coolant.
The The
lossesmechanical
of the electric power
motor Pel,𝑃𝑃𝑚𝑚lossincludes all by
are described losses that occur
the analytical at the bearing
approximate
Equation (6) [46]. The torque T and the angular velocity ω correspond to the operating
dynamic seals. Exchange losses 𝑃𝑃𝑎𝑎 occur mainly when the pump is operate
point of the electric motor and are determined by the calculation step of the mechanical
significantly lower flow rate than the best efficiency point. The pump is then in
load operation, characterized by turbulence behind the pump impeller. Backflows
which act back on the impeller and are captured in the additional power 𝑃𝑃𝑎𝑎 .
𝑃𝑃𝑠𝑠ℎ𝑎𝑎𝑎𝑎𝑎𝑎 = 𝑃𝑃ℎ + 𝑃𝑃𝑅𝑅 + 𝑃𝑃𝑚𝑚 + 𝑃𝑃𝑎𝑎
The losses of the electric motor 𝑃𝑃𝑒𝑒𝑒𝑒,𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 are described by the analytical appro
Appl. Appl.
Sci. 2022, 12,12,
Sci. 2022, 5316
5316 17 of 24

power demand (Figure 15). The parameters k c , k i , k ω , and C were determined by numerical
fitting of the efficiency map of the known and unvaried electric motor.
𝐸𝐸𝑒𝑒𝑒𝑒 = � 𝑃𝑃𝑠𝑠ℎ𝑎𝑎𝑎𝑎𝑎𝑎 + 𝑃𝑃𝑒𝑒𝑒𝑒,𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑑𝑑𝑑𝑑
Pel, loss = k c · T 2 + k i · ω + k ω · ω 3 + C (6)
The design variables are varied within the limits specified in Table 2. The
𝑛𝑛𝑂𝑂𝑂𝑂𝑂𝑂 , 𝑄𝑄consumption
The
𝑂𝑂𝑂𝑂𝑂𝑂 and 𝐻𝐻𝑜𝑜𝑜𝑜𝑜𝑜 are selected based on trial executions. The limits of the nu
of electrical energy ( f 2 in Figure 15) is determined by time integration
of the mechanical power and electrical power loss (Equation (7)).
impeller blades and impeller vane exit angle 𝛽𝛽2 are selected based on empirica
according to the literature E[39].
Z
el= P sha f t +P dt
el,loss (7)

Table
The2.design
Variation limitsare
variables of varied
the design variables.
within the limits specified in Table 2. The limits of
nOpt , QOpt and Hopt are selected based on trial executions. The limits of the number of
Design Variable 𝒏𝒏𝑶𝑶𝑶𝑶𝑶𝑶 blades and impeller
impeller 𝑸𝑸𝑶𝑶𝑶𝑶𝑶𝑶vane exit angle β2𝑯𝑯are
𝑶𝑶𝑶𝑶𝑶𝑶selected based on 𝜷𝜷𝟐𝟐
empirical values 𝒛𝒛𝑼𝑼
1 𝑙𝑙
Lower limit 1500
according to the 60
literature [39]. 12 kPa 25° 7
𝑚𝑚𝑚𝑚𝑚𝑚 𝑚𝑚𝑚𝑚𝑚𝑚
1 𝑙𝑙
Upper limit 30002. Variation limits of 600
Table the design variables. 30 kPa 35° 9
𝑚𝑚𝑚𝑚𝑚𝑚 𝑚𝑚𝑚𝑚𝑚𝑚
Design Variable nOpt QOpt HOpt β2 zU
In this
Lower paper, we1500
limit present 1 the results l
60 min of the multiobjective
12 kPa 25◦ optimization
7 usin
min
fronts. A pareto
Upper limit front 3000
contains 1
min all variants
600 min which
l
do not dominate
30 kPa 35 ◦
each
9 other with
to their objectives. If two variants are compared on the pareto front, one varian
better in one
In this paper,objective and
we present theworse
results in themultiobjective
of the other [40]. optimization using pareto
fronts. A pareto front contains all variants which do not dominate each other with respect
The pareto front of the optimization problem regarding the constraints is s
to their objectives. If two variants are compared on the pareto front, one variant will be
Figure
better 17. objective
in one It can beand
seen
worse thatinspatially compact pumps have a higher energy consu
the other [40].
Efficient
The pareto front of the optimization problem up
pumps, on the other hand, take a larger
regarding the installation
constraints is space. The infl
shown in
the design
Figure 17. It canparameter 𝑂𝑂𝑂𝑂𝑂𝑂 of the best efficiency point is shown as an exampl
be seen that 𝑛𝑛spatially compact pumps have a higher energy consumption.
Efficient pumps, on the other hand, take up a larger installation space. The influence of the
higher rotational speeds in the best efficiency point lead to more compact but less
design parameter nOpt of the best efficiency point is shown as an example. Here, higher
pumps. speeds in the best efficiency point lead to more compact but less efficient pumps.
rotational

Figure
Figure 17.17. Pareto
Pareto frontfront
of theof the technical
technical variants
variants of of the
the coolant coolant
pump. pump.

In this paper, the best tradeoff (cf. select in Figure 14) is selected by a weighted rating
In this paper, the best tradeoff (cf. select in Figure 14) is selected by a weighte
of the two objectives (Equation (8)). For this purpose, the objective values EEl and VPump
ofeach
of the technical
two objectives
variant on(Equation
the pareto (8)).
front For thisscored.
are first purpose, the objective
An objective with thevalues
lowest 𝐸𝐸𝐸𝐸𝐸𝐸 an
of each
value technical
is assigned variant
the score S of on theobjective
10, an paretowithfronttheare firstvalue
highest scored. An objective
is assigned the scorewith th
Svalue is assigned
of 1. Objective theinscore
values between of 10,
𝑆𝑆 are an objective
assigned with the highest
a linear interpolated value1 is assig
score between
score 𝑆𝑆 of 1. Objective values in between are assigned a linear interpolated score
1 and 10. A variant on the pareto front is thus assigned two scores between 1 an
specifying two weights 𝑤𝑤 , both variant scores are reduced to one. The two
describe the importance of the objectives to the systems engineer. The technica
 Appl. Sci. 2022, 12, 5316 18 of 24

and 10. A variant on the pareto front is thus assigned two scores between 1 and 10. By
Appl. Sci. 2022, 12, 5316 specifying two weights w, both variant scores are reduced to one. The two weights describe
the importance of the objectives to the systems engineer. The technical variant with the
highest total score Stot corresponds to the most preferred variant. A similar approach is
used in [47].
The selection of the Stotmost
= wEElsuitable
· SEEl + wvariant
VPump · SVis
Pumpshown as an example (8) in Figure
pumpTheinstallation space
selection of the mostwas weighted
suitable variant at 80% (𝑤𝑤
is shown = 0.8)inand
as𝑉𝑉 an example
𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
the18.
Figure energy
The consu
pump installation space was weighted at 80% (wVPump = 0.8) and the energy consumption
of 20% (𝑤𝑤 𝐸𝐸𝐸𝐸 = 0.2) importance (cf. Figure 6).
of 20% (wEEl 𝐸𝐸= 0.2) importance (cf. Figure 6).

Figure
Figure 18.18. Selection
Selection of theofmost
the suitable
most suitable tradeoff
tradeoff (red) from (red)
Figurefrom Figure
17. Circle size 17. Circle size
corresponds correspon
to the
totalscore
total score
of aofvariant.
a variant.

The values of the selected technical variant are summarized in Table 3. It represents
the bestThe values
variant of context
in the the selected technical
of system variant
preference arelimits
[41]. The summarized in Table
of the variables nOpt 3. It re
the Qbest
and variant in the context of system preference [41]. The limits of the variab
Opt are not exploited by the optimization algorithm. For the variables Hopt , β 2 and
zand
U it 𝑄𝑄
can are that
𝑂𝑂𝑂𝑂𝑂𝑂 seen
be not the
exploited
variationby theare
limits optimization
reached. algorithm. For the variables 𝐻𝐻𝑜𝑜𝑜𝑜𝑜𝑜 ,
𝑧𝑧 it can be seen that the variation limits are reached.
𝑈𝑈 3. Numerical values of the selected technical variant in Figure 18.
Table

Table 3. Numerical values of the selected technical variant in Figure

Design Variables 18.
Objectives
nOpt QOpt Hopt β2 zU EEl VPump
Design
1635Variables
1
min
l
150 min 12.11 kPa 34.95◦ 9 123.53 kJ Objectives
47203 mm3
𝑛𝑛𝑂𝑂𝑂𝑂𝑂𝑂 𝑄𝑄𝑂𝑂𝑂𝑂𝑂𝑂 𝐻𝐻𝑜𝑜𝑜𝑜𝑜𝑜 𝛽𝛽2 𝑧𝑧𝑈𝑈 𝐸𝐸𝐸𝐸𝐸𝐸 𝑉𝑉𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
1 l
1635 150 12.11 kPa 34.95° 9 123.53 kJ 47203 mm
In principle, other decision-making techniques are also applicable. In the literature,
min min FUZZY, LINMAP [48], and TOPSIS [49] are used, among others.
The results from Table 3 are transferred to the MBSE system model and represent an
Inset
optimal principle, other
of parameters decision-making
of the techniques
system architecture are also applicable. In the li
(cf. Figure 2).
FUZZY, LINMAP [48], and TOPSIS [49] are used, among others.
4. Discussion
The results from Table 3 are transferred to the MBSE system model and repr
The developed approach for linking MDAO with an MBSE system model enables
optimal set
extending the of parameters
analytical of theinsystem
possibilities MBSE. architecture
Large areas of(cf.
the Figure 2).
design variable and
the resulting solution space can be explored. As a result, technical variants with the best
4. Discussion
objectives are identified, and conflicting objectives are resolved with an appropriate tradeoff.
The formal description of the MDAO problem in the MBSE system model resolves its black
The developed approach for linking MDAO with an MBSE system model
box behavior. Necessary changes in case of new requirements or new available models
extending
become the analytical
transparent, possibilities
which reduces in MBSE. Large
the reconfiguration areas
effort. If of the
a conflict design variable
of objectives
resulting solution space can be explored. As a result, technical variants with
objectives are identified, and conflicting objectives are resolved with an app
tradeoff. The formal description of the MDAO problem in the MBSE system
resolves its black box behavior. Necessary changes in case of new requirements
Appl. Sci. 2022, 12, 5316 19 of 24

is identified based on an existing design and test workflows, the presented approach can
be used to formulate an MDAO problem. By reusing models from existing design and
test workflows, the initial implementation effort of the MDAO problem is reduced. The
formalization of MDAO is carried out employing architecture and internal behavior. These
descriptions are transferred to the executable behavior of the workflow, which triggers the
execution and solution of the MDAO problem.

Limitations
The transfer of the internal behavior to the executable behavior is done manually at
the current time. For the purpose of automatability, a model-to-model transformation of
the internal behavior into the executable behavior should be investigated in future work.
Additionally, the get and set functions must be implemented manually for each parame-
ter. One solution might be combining multiple get or set functions into one overarching
function, as presented in Figure 14. However, this reduces flexibility.
The developed approach was only applied to one MDAO architecture (Figure 15).
In the future, its usefulness for other MDAO architectures must be examined. Although
the approach can be used in the early stages of development, it assumes that models
and workflows are already in place and that a conflict of objectives has been identified.
This limits the applicability for deviating boundary conditions. Another limitation of the
approach is that MDAO, which considers many parameters, would lead to crowded acitvity
diagrams.

5. Related Work
Chaudemar et al. conduct a literature review on the joint use of MBSE and MDAO in
the early stages of development [26]. They come to three conclusions: First, there is a lack of
confidence that the MDAO problem correctly represents the MBSE system model. Second,
the MDAO formulation takes a non-negligible amount of time. At the same time, necessary
information is already available in the MBSE system model. Third, MDAO solutions are
rarely implemented in the MBSE system model. As reasons, the lack of expressiveness of
the MBSE languages and high manual effort are indicated.
Aiello et al. [50] link MDAO and MBSE using the three branches of approach, type,
and tool for refining requirements. Thus MDAO is to be used already in the early phases of
the requirement formulation. The approach stands for the fact that the MBSE triggers the
MDAO execution and the MDAO results enrich the MBSE system model. The type describes
a coupling of language and methodical level. On the language level, the description in the
MBSE system model is extended by new stereotypes for requirements used for the MDAO
formulation (e.g., solver, model accuracy, etc.). Methodically, five steps are proposed
to read out these requirements from the MBSE system model and enrich them through
MDAO. Papyrus and OpenMDAO are used as tools. The use case is the dimensioning
of a drone battery. Reuse of models is not addressed, and the MDAO problem remains
a black box for the system engineer. A further work [51] focuses on the refinement of
requirements in MBSE by linking them to MDAO. For this purpose, tool interfaces between
TTool, OpenMDAO, and UPPAAL-SMC are implemented.
Jeyaraj et al. [52] describe a framework for the joint use of MBSE and MDAO. The
MBSE system model contains all the system specification information. MDAO is used to
evaluate individual architectures. In the presented example, the MBSE system specification
is enriched with MDAO input parameters, and these parameters are extracted and finally
evaluated in MDAO. Finally, the MDAO results are fed back into the MBSE system model.
The procedure is demonstrated in an aircraft application. The MDAO problem remains a
black box in the MBSE system model.
Ciampa et al. [24] describe a linking of MBSE and MDAO using an architectural frame-
work. In this context, the concept of a development system and a system of interest (SoI) is
introduced. A development system is one of the supporting systems (simulation, MDAO,
etc.) for the development of the SoI in different phases. It is proposed to use MBSE for the
Appl. Sci. 2022, 12, 5316 20 of 24

development of MDAO systems and thus accelerate the development of SoI. The MDAO
system is formally described in structure and behavior by an MDAO system architecture.
The MDAO system architecture is developed using an architectural framework consisting
of ontology (nomenclature and terminology) and viewpoints (organizational, architectural,
lifecycle, process, requirements). In this way, the so-called upstream engineering phases
(system identification, specification, architecting), which are formalized by the MBSE, are
linked to the downstream engineering phases (system synthesis and exploration), including
MDAO. The definition of MDAO as an individual system establishes a vertical integra-
tion into the development of complex systems. So far, only high-level elements of this
MBSE-driven approach to developing MDAO systems have been published. The reuse of
existing development data and models of the system of interest was not described. It is not
addressed how MDAO is executed and how the parameterization of the system of interest
architecture is accomplished.
Min et al. [53] describe the integration of SysML and the process integration and
design optimization framework (PIDO) of the ModelCenter software. The integration
allows to model analyses in SysML and to transfer and execute them one-to-one in the
analysis environment. For this purpose, a tool-specific profile is presented, in which the
considered models have to be embedded. The goal of the integration is the representation
of knowledge and traceability of the analyses. A drawback is that the description of the
analysis context is specific to a commercial tool.
Leserf et al. [54] describe a method and implementation to formulate optimization
problems from SysML descriptions and solve them in the PyOpt environment. For this
purpose, new stereotypes are defined in SysML to describe a Multi-Domain Optimization
(MDO) context. The MDO context is formulated problem-specifically in a parametric
diagram. From this description, a constraint satisfaction multicriteria optimization problem
(CSMOP) is generated and solved in an optimization framework. This approach requires
that the optimization problem can be described in parametric diagrams. Integration and
execution of more extensive calculation approaches, as required in developing mechatronic
systems (e.g., simulation models), were not described.

6. Summary and Future Work

In this paper, a means of linking MDAO and an MBSE system model while reusing
development data from the MBSE system model components was described. Starting from
a system specification, solutions were identified for the system functions to fulfill. The solu-
tions had parameters that determined their physical behavior and requirement satisfaction.
Appropriate parameters of the solutions were determined using design workflows. Test
workflows were then executed to test the requirements fulfillment of the selected param-
eters. If requirements were not met, the design variables were changed, and design and
test workflows were manually executed again. In this sequence, it remained unclear which
design variables had to be changed, and how, to obtain the best possible technical variant.
To avoid the manual iteration of sequentially executing design and test workflows, an
optimization workflow is proposed. It is formalized in the MBSE system model utilizing
three model approaches: workflow architecture, internal behavior, and executable behavior.
In the workflow architecture, the elements of the optimization workflow are described
hierarchically. In the internal behavior, the internal structure, including interfaces and the
execution order of the elements, are defined. Existing MBSE system model components are
reused to describe the internal behavior. With the help of the model approaches of workflow
architecture and internal behavior, the executable behavior of the optimization workflow
is implemented. The executable behavior is provided as an action in the activity diagram.
The execution takes place in an external tool, but always remains transparent concerning
the models used and the principles and the requirements considered. Changes in the
requirement values can directly be considered in the execution of the optimization. The
optimization workflow approach is demonstrated using the example of the optimization of
an electric coolant pump. A conflict of objectives arises between pump installation space
Appl. Sci. 2022, 12, 5316 21 of 24

and electrical energy consumption requirements, so that spatially compact pumps are
less efficient.
Currently, the executable behavior must be implemented manually from the MBSE
system model in an external tool. Future work will focus on an automatic model trans-
formation from internal to executable behavior. Furthermore, the transferability of the
approach to other MDAO architectures will be investigated.

Author Contributions: Conceptualization, C.H., G.H., S.N. and J.B.; methodology, C.H., G.H., J.B.,
S.N. and G.J.; formal analysis, C.H.; writing—original draft preparation, C.H.; writing—review and
editing, S.N., J.B. and G.J.; supervision, G.J. All authors have read and agreed to the published version
of the manuscript.
Funding: This research received no external funding.
Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.
Data Availability Statement: Not applicable.
Conflicts of Interest: The authors declare no conflict of interest.

Nomenclature

β2 Impeller vane exit angle

η Pump efficiency
ψTh Head coefficient
ψTh,min Minimum head coefficient specified by requirements
ψTh,max Maximum head coefficient specified by requirements
ω Angular velocity of the pump impeller
a Parameter of the pump characteristic curve
b Parameter of the pump characteristic curve
b2 Impeller width
b2,max Maximum impeller width specified by requirements
c Parameter of the pump characteristic curve
C Electric motor loss coefficient
C&C-A Contact and channel approach
CPS Cyber-physical system
CSMOP Constraint satisfaction multicriteria optimization problem
d Parameter of the pump characteristic curve
D2 Impeller diameter
D2,max Maximum impeller diameter specified by requirements
EEl Consumed electrical energy in the flow rate cycle
f Objective function
g Constraint function
H Head
HOpt Head in the best efficiency design point
kc Electric motor loss coefficient
ki Electric motor loss coefficient
kω Electric motor loss coefficient
MBSE Model-Based Systems Engineering
MDAO Multidisciplinary Analysis and Optimization
ncycle,max Maximum required pump speed in the flow rate cycle
nmax Maximum pump speed specified by requirements
nOpt Rotational speed in the best efficiency design point
nq Characteristic pump rotational speed
OEM Original equipment manufacturer
P0 Shaft power at zero net flow rate
Pa Exchange power losses of the pump
Appl. Sci. 2022, 12, 5316 22 of 24

Pel,loss Losses of the electric motor

Ph Hydrodynamic power of the pump
Pm Mechanical power losses of the pump
PR Disk friction power losses of the pump
Psha f t Pump total shaft power
PIDO Process integration and design optimization
Q Flow rate
Qa Exchange flow rate at zero net flow rate
QOpt Flow rate in the best efficiency design point
SEEl Score of electric energy consumption
Stot Total score
SVPump Score of pump installation space
SoI System of interest
SSO Single source of truth
SysML Systems modeling language
T Pump shaft torque
VPump Pump installation space
wEEl Weight of electric energy consumption
wVPump Weight of pump installation space
x Design variable
zU Number of impeller blades

References
1. Fahl, J.; Hirschter, T.; Wöhrle, G.; Albers, A. Proposing a Specification Structure for Complex Products in Model-based Systems
Engineering (MBSE). Proc. Des. Soc. 2021, 1, 2481–2490. [CrossRef]
2. Grebe, U.D.; Hick, H.; Rothbart, M.; von Helmolt, R.; Armengaud, E.; Bajzek, M.; Kranabitl, P. Challenges for Future Automotive
Mobility. In Systems Engineering for Automotive Powertrain Development, 1st ed.; Hick, H., Küpper, K., Sorger, H., Eds.; Springer
International Publishing, Imprint Springer: Cham, Switzerland, 2021; pp. 3–30. ISBN 978-3-31999-629-5.
3. Drave, I.; Rumpe, B.; Wortmann, A.; Berroth, J.; Hoepfner, G.; Jacobs, G.; Spuetz, K.; Zerwas, T.; Guist, C.; Kohl, J. Modeling
mechanical functional architectures in SysML. In Proceedings of the 23rd ACM/IEEE International Conference on Model Driven
Engineering Languages and Systems, Virtual Event, Canada, 16–23 October 2020; pp. 79–89. [CrossRef]
4. Gunes, V.; Peter, S.; Givargis, T.; Vahid, F. A Survey on Concepts, Applications, and Challenges in Cyber-Physical Systems. KSII
TIIS 2014, 8, 4242–4268. [CrossRef]
5. Chen, H. Applications of Cyber-Physical System: A Literature Review. J. Ind. Intg. Mgmt. 2017, 2, 1750012. [CrossRef]
6. Hammer, M.; Maschotta, R.; Zimmermann, A. Model-Driven Application Development for Evaluation and optimization of
Automotive E/E-Architectures. In Proceedings of the 2021 IEEE International Conference on Recent Advances in Systems Science
and Engineering, Shanghai, China, 12–14 December 2021; pp. 1–8, ISBN 978-1-66543-441-6.
7. Charette, R.N. How Software is Eating the Car. Available online: https://spectrum.ieee.org/software-eating-car (accessed on
4 May 2022).
8. Fakih, M.; Klemp, O.; Puch, S.; Grüttner, K. A modeling methodology for collaborative evaluation of future automotive
innovations. Softw. Syst. Model. 2021, 20, 1587–1608. [CrossRef]
9. Hennig, A.; Topcu, T.G.; Szajnfarber, Z. So You Think Your System Is Complex?: Why and How Existing Complexity Measures
Rarely Agree. J. Mech. Des. 2022, 144, 041401. [CrossRef]
10. D’Ambrosio, J.; Soremekun, G. Systems engineering challenges and MBSE opportunities for automotive system design. In
Proceedings of the 2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Banff, AB, Canada, 5–8 October
2017; pp. 2075–2080.
11. Schmidt, M.M.; Zimmermann, T.C.; Stark, R. Systematic Literature Review of System Models for Technical System Development.
Appl. Sci. 2021, 11, 3014. [CrossRef]
12. Henderson, K.; Salado, A. Value and benefits of model-based systems engineering (MBSE): Evidence from the literature. Syst.
Eng. 2021, 24, 51–66. [CrossRef]
13. Obstbaum, M.; Wurstbauer, U.; König, C.; Wagner, T.; Kübler, C.; Fäßler, V. From a Graph to a Development Cycle: MBSE as
an Approach to reduce Development Efforts. In 66. Deutscher Luft- Und Raumfahrtkongress; Deutsche Gesellschaft für Luft-und
Raumfahrt-Lilienthal-Oberth eV: München, Germany, 2017.
14. Eigner, M.; Huwig, C.; Dickopf, T. Cost-Benefit Analysis in Model-Based Systems Engineering: State of the Art and Future
Potentials. In Product Modularisation, Product Architecture, Systems Engineering, Product Service Systems; Weber, C., Husung, S.,
Cascini, G., Cantamessa, M., Marjanovic, D., Rotini, F., Eds.; Design Society: Glasgow, UK, 2015; ISBN 978-1-90467-070-4.
15. Madni, A.; Purohit, S. Economic Analysis of Model-Based Systems Engineering. Systems 2019, 7, 12. [CrossRef]
Appl. Sci. 2022, 12, 5316 23 of 24

16. Kim, H.; Fried, D.; Menegay, P. Connecting SysML Models with Engineering Analyses to Support Multidisciplinary System
Development. In Aviation Technology, Integration, and Operations (ATIO) Conferences, Proceedings of the 12th AIAA Aviation
Technology, Integration, and Operations (ATIO) Conference and 14th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference,
Indianapolis, Indiana, 17–19 September 2012; American Institute of Aeronautics and Astronautics: Washington, DC, USA, 2012;
ISBN 978-1-60086-930-3.
17. Ma, J.; Wang, G.; Lu, J.; Vangheluwe, H.; Kiritsis, D.; Yan, Y. Systematic Literature Review of MBSE Tool-Chains. Appl. Sci. 2022,
12, 3431. [CrossRef]
18. Rojas, J.A.M.; Fernández, J.L.; Montero, R.S.; Espí, P.L.L.; Diez-Jimenez, E. Model-Based Systems Engineering Applied to Trade-Off
Analysis of Wireless Power Transfer Technologies for Implanted Biomedical Microdevices. Sensors 2021, 21, 3201. [CrossRef]
19. Spyropoulos, D.; Baras, J.S. Extending Design Capabilities of SysML with Trade-off Analysis: Electrical Microgrid Case Study.
Procedia Comput. Sci. 2013, 16, 108–117. [CrossRef]
20. Zhang, Y.; Hoepfner, G.; Berroth, J.; Pasch, G.; Jacobs, G. Towards Holistic System Models Including Domain-Specific Simulation
Models Based on SysML. Systems 2021, 9, 76. [CrossRef]
21. Simpson, T.W.; Martins, J.R.R.A. Multidisciplinary Design Optimization for Complex Engineered Systems: Report From a
National Science Foundation Workshop. J. Mech. Des. 2011, 133, 101002. [CrossRef]
22. Martins, J.R.R.A.; Lambe, A.B. Multidisciplinary Design Optimization: A Survey of Architectures. AIAA J. 2013, 51, 2049–2075.
[CrossRef]
23. Papageorgiou, A.; Ölvander, J. The role of multidisciplinary design optimization (MDO) in the development process of complex
engineering products. In DS 87-4 Proceedings of the 21st International Conference on Engineering Design (ICED 17) Vol 4: Design
Methods and Tools, Vancouver, Canada, 21–25 August 2017; The Design Society: Copenhagen, Denmark, 2017; pp. 109–118.
ISBN 978-1-90467-092-6.
24. Ciampa, P.D.; La Rocca, G.; Nagel, B. A MBSE Approach to MDAO Systems for the Development of Complex Products. In Model
Based Systems Engineering (MBSE) Integration with MDO I, Proceedings of the AIAA Aviation Forum, Virtual Event, 15–19 June 2020;
American Institute of Aeronautics and Astronautics: Reston, VA, USA, 2020; ISBN 978-1-62410-598-2.
25. Ciampa, P.D.; Nagel, B. Towards the 3rd generation MDO collaborative environment. In Proceedings of the 30th International
Council of the Aeronautical Sciences Congress 2016 (30th ICAS 2016), Daejeon, Korea, 25–30 September 2016; Deutsche Gesellschaft Für
Luft-Und Raumfahrt e.V: Bonn, Germany, 2016; pp. 1–12. ISBN 978-3-93218-285-3.
26. Chaudemar, J.-C.; de Saqui-Sannes, P. MBSE and MDAO for Early Validation of Design Decisions: A Bibliography Survey. In
Proceedings of the IEEE International Systems Conference (SysCon), Vancouver, BC, Canada, 15 April–15 May 2021; IEEE: New York, NY,
USA, 2021; pp. 1–8. ISBN 978-1-66544-439-2.
27. Höpfner, G.; Jacobs, G.; Zerwas, T.; Drave, I.; Berroth, J.; Guist, C.; Rumpe, B.; Kohl, J. Model-Based Design Workflows for
Cyber-Physical Systems Applied to an Electric-Mechanical Coolant Pump. IOP Conf. Ser. Mater. Sci. Eng. 2021, 1097, 12004.
[CrossRef]
28. Haghighat, A.K.; Roumi, S.; Madani, N.; Bahmanpour, D.; Olsen, M.G. An intelligent cooling system and control model for
improved engine thermal management. Appl. Therm. Eng. 2018, 128, 253–263. [CrossRef]
29. Sen-Chun, M.; Hong-Biao, Z.; Ting-Ting, W.; Xiao-Hui, W.; Feng-Xia, S. Optimal design of blade in pump as turbine based on
multidisciplinary feasible method. Sci. Prog. 2020, 103, 36850420982105. [CrossRef]
30. Mariani, L.; Di Bartolomeo, M.; Di Battista, D.; Cipollone, R.; Fremondi, F.; Roveglia, R. Experimental and numerical analyses to
improve the design of engine coolant pumps. In Proceedings of the 75th National ATI Congress, Rome, Italy, 15–16 September 2020;
EDP Sciences: Les Ulis, France, 2020; p. 6017. ISBN 978-1-71381-916-5.
31. Fernández, S.; Jiménez, M.; Porras, J.; Romero, L.; Espinosa, M.M.; Domínguez, M. Additive Manufacturing and Performance of
Functional Hydraulic Pump Impellers in Fused Deposition Modeling Technology. J. Mech. Des. 2016, 138, 024501. [CrossRef]
32. Si, Q.; Lu, R.; Shen, C.; Xia, S.; Sheng, G.; Yuan, J. An Intelligent CFD-Based Optimization System for Fluid Machinery: Automotive
Electronic Pump Case Application. Appl. Sci. 2020, 10, 366. [CrossRef]
33. Koller, R.; Kastrup, N. Prinziplösungen Zur Konstruktion Technischer Produkte; Springer: Berlin/Heidelberg, Germany, 1998;
ISBN 978-3-642-63712-4.
34. Schmidt, S.; Schlager, B.; Muckenhuber, S.; Stark, R. Configurable Sensor Model Architecture for the Development of Automated
Driving Systems. Sensors 2021, 21, 4687. [CrossRef]
35. Albers, A.; Braun, A.; Sadowski, E.; Wynn, D.C.; Wyatt, D.F.; Clarkson, P.J. System Architecture Modeling in a Software Tool
Based on the Contact and Channel Approach (C&C-A). J. Mech. Des. 2011, 133, 101006. [CrossRef]
36. Holzenberger, K.; Jung, K. Centrifugal Pump Lexicon. Available online: https://www.ksb.com/en-global/centrifugal-pump-
lexicon/article/head-coefficient-1116552 (accessed on 5 May 2022).
37. Yedidiah, S. Centrifugal Pump User’s Guidebook; Springer US: Boston, MA, USA, 1996; ISBN 978-1-46128-516-8.
38. Pumps, S. Centrifugal Pump Handbook, 3rd ed.; Elsevier Butterworth-Heinemann: Amsterdam, The Netherlands, 2010;
ISBN 978-0-75068-612-9.
39. Wesche, W. Radiale Kreiselpumpen; Springer: Berlin/Heidelberg, Germany, 2016; ISBN 978-3-66248-911-6.
40. Martins, J.R.R.A.; Ning, A. Engineering Design Optimization; Cambridge University Press: Cambridge, UK, 2022; ISBN 978-1-10898-064-7.
41. Hazelrigg, G.A.; Saari, D.G. Toward a Theory of Systems Engineering. J. Mech. Des. 2022, 144, 011402. [CrossRef]
Appl. Sci. 2022, 12, 5316 24 of 24

42. Huang, W.; Huang, J.; Yin, C. Optimal Design and Control of a Two-Speed Planetary Gear Automatic Transmission for Electric
Vehicle. Appl. Sci. 2020, 10, 6612. [CrossRef]
43. Deb, K.; Jain, S. Multi-Speed Gearbox Design Using Multi-Objective Evolutionary Algorithms. J. Mech. Des. 2003, 125, 609–619.
[CrossRef]
44. Manikowski, P.L.; Walker, D.J.; Craven, M.J. Multi-Objective Optimisation of the Benchmark Wind Farm Layout Problem. JMSE
2021, 9, 1376. [CrossRef]
45. Kwong, W.Y.; Zhang, P.Y.; Romero, D.; Moran, J.; Morgenroth, M.; Amon, C. Multi-Objective Wind Farm Layout Optimization
Considering Energy Generation and Noise Propagation With NSGA-II. J. Mech. Des. 2014, 136, 091010. [CrossRef]
46. Larminie, J.; Lowry, J. Electric Vehicle Technology Explained, 2nd ed.; Wiley a John Wiley & Sons Ltd. Publication: Chichester, UK,
2012; ISBN 978-1-11994-273-3.
47. Docimo, D.J.; Kang, Z.; James, K.A.; Alleyne, A.G. A Novel Framework for Simultaneous Topology and Sizing Optimization of
Complex, Multi-Domain Systems-of-Systems. J. Mech. Des. 2020, 142, 091701. [CrossRef]
48. Maputi, E.S.; Arora, R. Multi-objective optimization of a 2-stage spur gearbox using NSGA-II and decision-making methods. J.
Braz. Soc. Mech. Sci. Eng. 2020, 42, 477. [CrossRef]
49. Alizadeh, M.; Esfahani, M.N.; Tian, W.; Ma, J. Data-Driven Energy Efficiency and Part Geometric Accuracy Modeling and
Optimization of Green Fused Filament Fabrication Processes. J. Mech. Des. 2020, 142, 041701. [CrossRef]
50. Aiello, O. Sizing a Drone Battery by coupling MBSE and MDAO. In Proceedings of the 11th European Congress Embedded Real
Time Systems, Toulouse, France, 1–2 June 2022.
51. Aiello, O.; Del Kandel, D.S.R.; Chaudemar, J.-C.; Poitou, O.; de Saqui-Sannes, P. Populating MBSE Models from MDAO Analysis.
In Proceedings of the IEEE International Symposium on Systems Engineering (ISSE), Vienna, Austria, 13 September–13 October 2021;
IEEE: New York, NY, USA, 2021; pp. 1–8. ISBN 978-1-66543-168-2.
52. Jeyaraj, A.K.; Tabesh, N.; Liscouet-Hanke, S. Connecting Model-based Systems Engineering and Multidisciplinary Design
Analysis and Optimization for Aircraft Systems Architecting. In MBSE Integration with MDO II, AIAA Aviation Forum, Virtual
Event, 2–6 August 2021; American Institute of Aeronautics and Astronautics: Reston, VA, USA, 2021; ISBN 978-1-62410-610-1.
53. Min, B.I.; Kerzhner, A.A.; Paredis, C.J.J. Process Integration and Design Optimization for Model-Based Systems Engineering With
SysML. In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Presented
at ASME 2011 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference,
Washington, DC, USA, 28–31 August 2011; ASME: New York, NY, USA, 2012; pp. 1361–1369. ISBN 978-0-79185-479-2.
54. Leserf, P.; de Saqui-Sannes, P.; Hugues, J. Multi domain optimization with SysML modeling. In Proceedings of the 2015 IEEE
20th Conference on Emerging Technologies & Factory Automation (ETFA), City of Luxembourg, Luxembourg, 8–11 September 2015; IEEE:
Piscataway, NJ, USA, 2015; pp. 1–8. ISBN 978-1-46737-930-4.