ACS6124 Multisensor and Decision Systems

Part II – Decision Systems for Engineering Design

Lecture 1: Introduction

Prof. Robin Purshouse

University of Sheffield

Spring Semester 2019/2020

1 Module overview
1.1 Module aims
In Part II of ACS6124 Multisensor and Decision Systems, students will develop an in
depth knowledge and understanding of decision systems and the underlying math-
ematics and algorithms. Students will develop their confidence in solving complex
problems requiring the application of decision techniques to a wide variety of applica-
tions.

1.2 Intended learning outcomes

After successful completion of Part II of the module, students will be able to:

1. Explain the importance of and need for decision systems in a wide range of
industrial and research applications, and explain the relative merits and limi-
tations of adopting such systems compared to other state-of-the-art solutions
[SM1fl, SM3fl];
2. Describe and explain the main components, architectures and design issues in
decision systems, and future technological challenges and opportunities [EA1fl];
3. Select and use appropriate architectures, and algorithmic, computational and
experimental tools (including those from the research literature) to provide in-
novative solutions to complex, unfamiliar, open-ended decisions subject to a
variety of technological constraints [EA3fl, D1fl];
4. Demonstrate creative and critical thinking in providing and evaluating solutions
to complex decisions and effectively communicate and analyse such solutions
[EP3m,D2f1,D7m];
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

5. Effectively present appropriate design methodology, analysis and critical evalua-

tion of solutions and any limitations and constraints of such solutions in the form
of a technical report to a standard that a suitably qualified person could follow
and use to obtain similar findings [D6m].

The codes in square brackets refer to IET Learning Outcomes – see https://www.
theiet.org/academics/accreditation/policy-guidance/ahepguide.cfm?type=pdf
for further details.

1.3 Syllabus
A high-level overview of the syllabus for Part II of the module is shown below:

• Introduction to decision systems for engineering design;

• Sampling plans and visualisation methods;

• Multi-criterion search and optimization methods;

• Interactive design optimization;
• Multi-disciplinary design optimization.

1.4 Recommended reading

Some elements of the course draw on topics and material from Forrester, Sóbester &
Keane’s Engineering Design via Surrogate Modelling (Wiley, ISBN 978-0-470-06068-
1). A sequence of recommended journal paper readings will also be made available
via MOLE during Part II of the module. Students are also recommended to read
Pirsig’s Zen and the Art of Motorcycle Maintenance for interesting perspectives on
engineered products and their role in societies – this is not compulsory for the module,
but good preparation for anyone considering a future career in analysis and design.

1.5 Module pre-requisites

This module assumes that students have a basic understanding of calculus, linear
algebra, and statistics. Students should also have some familiarisation with program-
ming in Matlab.

Part II – Decision Systems for Engineering Design 2

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

2 Lecture overview
This lecture introduces the fundamental elements of an engineering design problem
and motivates the need for a decision systems approach. Several real-world engi-
neering design examples are included that illustrate these fundamental elements.

3 Elements of an engineering design problem

Consider a complex engineered product, such as a powertrain platform for use across
a range of vehicle models. The engineering design for such a product is a com-
plex process involving multiple engineering design teams, often working to different
timescales and operating in different locations.
The design teams specialise in different areas – for a powertrain platform, this
would be areas such as the engine system, the aftertreatment system and the trans-
mission system – with each team responsible for a different aspect of the design and,
potentially, different aspects of the overall performance of the product.
Through a carefully specified engineering design process, the design teams work
together over time, expending their available resources, to realise an overall coherent
design for the product – hopefully one that satisfies both customer and regulatory
requirements. However, often the physics of the system is such that conflict naturally
occurs between different aspects of performance (e.g. between fuel economy and
emissions) making it difficult to find a single design that will satisfy all requirements
simultaneously.
Decision systems place an important role in the design of a complex engineered
product. They help the design engineers to:

1. Clarify the specifics of the design problem at hand;

2. Use resources efficiently in identifying promising candidate designs;
3. Understand the relationships between aspects of design and aspects of perfor-
mance;

4. Communicate the designs and understandings to other teams and the Chief
Engineer with overall responsibility for the product.

This second part of ACS6124 is about introducing these decision systems. But,
before we get to the systems, let’s think in slightly more formal terms about the engi-
neering design problem they seek to address.

3.1 Design variables

The design variables are the parts of the engineering problem that are under the
control (or at least partial control) of the design engineer. For complex engineered
products, design variables typically exist at one of the following hierarchical levels:

Part II – Decision Systems for Engineering Design 3

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

1. Architecture – variables that define the overall concept for the architecture of the
system. For a powertrain, these would be variables such as choice of power
system technology (e.g. presence or absence of an exhaust gas recirculation
system).
2. Component – variables that define the specific hardware aspects of components
within a given architecture. Again, for a powertrain, this might be items such as
the detailed geometry of the aftertreatment block or choice of precious metals
within the catalyst.
3. Calibration – variables that can be defined after the hardware design has been
realised, e.g. specification of injection timings in the engine, or choice of con-
troller gains in the engine control system.

In what follows, we will denote a design variable using the conventional notation
xi , where i refers to the ith design variable in the problem. We refer to a set of
design variables using vector notation, i.e. x. We subscript vectors of design variables,
xo , to indicate variables under the control of the oth design team within the overall
engineering design organisation. In this module, we won’t distinguish between design
variables at different levels in the design hierarchy.

3.2 Parameters
Parameters are factors that can affect the performance of a design that are not under
the control of the design engineer. Parameters can be categorised as follows:

1. Environmental conditions – factors that vary with the anticipated operating envi-
ronment of the product, such as the ambient temperatures and pressures in the
environment within which a powertrain could be operating.

2. Physical constants – empirical values identified as being important to the physics

of the problem, e.g. the gravitational constant, g, or other empirically-derived re-
lationships encoded in mathematical models of the system.
3. Linking variables – factors either directly or indirectly under the control of other
design teams, e.g. from the perspective of the aftertreatment design team, the
characteristics of the emissions generated by the engine.

Parameters are often characterised by uncertainty – arising from manufacturing

tolerances, unknown operating conditions, errors in representing the physics of the
system, or yet-to-be-determined choices (and their consequences) from other design
teams.
In the module, we will denote a parameter using the conventional notation pj ,
where j refers to the jth parameter in the problem. We refer to a set of parame-
ters using vector notation, i.e. p. We subscript vectors of parameters, po , to indicate
uncontrollable variables faced by the oth design team within the overall engineering
design organisation.

Part II – Decision Systems for Engineering Design 4

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

3.3 Performance criteria

The performance criteria are the dimensions by which a candidate design is as-
sessed. The criteria are closely related to the requirements for the product; however
since requirements for a single product usually number in the tens of thousands and
are organised in a hierarchy, performance criteria typically represent only the high-
level requirements or overall attributes that the design is aiming to meet. A com-
plex engineered product might typically have around 20 performance criteria (e.g. for
a powertrain these would include attributes such as efficiency, performance, noise,
durability, weight and cost).
Performance criteria are normally denoted using the notation zk , where zk refers to
the kth criterion in the problem. We refer to a set of criteria using vector notation, i.e. z.
We subscript vectors of parameters, zo , to indicate criteria that are the responsibility
of the oth design team within the overall engineering design organisation.

3.3.1 Constraints
Constraints are performance criteria for which a defined level of performance is nec-
essary: either the criterion must be met exactly (an equality constraint) or a minimum
level of performance must be achieved (an inequality constraint). The latter are the
most common type of constraints found in engineering design problems (e.g. a max-
imum quantity of nitrogen oxide that can be released as part of a regulatory drive
cycle).
Inequality constraints are usually expressed as zk = gk (x, p), although the func-
tional form gk (.) may be implicit. In a similar fashion, equality constraints are ex-
pressed using zk = hk (x, p). Sometimes the z component of the notation is dropped
for convenience.

3.3.2 Objectives
Objectives are criteria for which a desired direction of performance is expressed, but
where constraints on the absolute level of performance do not exist – so objectives
are either to be maximised or minimised – usually the latter convention in adopted
for convenience (without loss of generality since minimisation of zk is equivalent to
maximisation of −1 · zk . In a typical design problem, cost and weight are criteria to be
minimised.
Objectives are usually expressed as zk = fk (z, p), although the functional form
f (.) may be implicit. Again, sometimes the z part of the notation is dropped for con-
venience.

3.3.3 Preferences
Preferences relate to the desires of the decision-maker (e.g. the design engineer
or the product Chief Engineer) for achieving particular levels of performance. Con-
straints, unless they relate to true physical bounds, can be considered a hard form

Part II – Decision Systems for Engineering Design 5

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

of preference that must be met. There may also be soft forms of preference such as
desirable but not essential levels of performance against the criteria.
Common forms of preference elicited directly with respect to the criteria include:
• Goals – preferred levels of performance against the criteria, e.g. “90g CO2 per
km”. A design can be said to be satisficing if it meets the goals of the decision-
maker. Goals are also sometimes known as targets.
• Priorities – some kind of ordering expressed over the criteria, e.g. “minimize
weight first, then minimize cost”
• Weights – relative strengths of preference for performance against the criteria,
e.g. “minimizing weight is twice as important as minimizing cost”.
Preferences can also be expressed by direct comparisons between designs (where
performance is implicit), e.g. “I prefer design A to design B”. These types of prefer-
ences then need to be converted into expressions like the above that explicitly relate
to performance against the criteria.

3.4 Evaluation functions

An important aspect of engineering design is to be able to actually estimate the perfor-
mance of a candidate design. Formally, this is a mapping from the design variables x
and parameters p to the performance criteria z – i.e. the fk (.), gk (.) and hk (.) functions
discussed above. Evaluations come in the form of physical experiments, mathematical
models, and expert opinion. Mathematical models have long played a part in evalu-
ating designs, with modern companies attempting to virtualise as much evaluation as
possible in order to reduce design costs and timelines. Such models may be compu-
tationally fast to evaluate (e.g. controller design models based on ordinary differential
equations) but may also be computationally expensive (e.g. crash simulations based
on partial differential equations). Very often the models are sufficiently complex that
the fk (.), gk (.) and hk (.) functions cannot be written down and the simulation model
acts as a ‘black-box’ in a way similar to a physical experiment.

3.5 Putting it all together

Bringing all the aspects in this section together, the notion of decision systems for
engineering design can be formally expressed as a constrained multi-objective op-
timization problem:

minimise f (x, p)
x
subject to g(x, p) ≤ 0
h(x, p) = 0
x∈D
p←P (1)

Part II – Decision Systems for Engineering Design 6

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

where D is the space of design variables and P is the space of parameters. Here
we have assumed the problem is solved across D for a single realisation from P (i.e. a
nominal parameterisation of the problem), but other formulations are possible in which
the full parameter space is considered.
If a utility function that encapsulates the decision-maker preferences, U (.), is avail-
able Equation 1 can be re-expressed as:

maximise U (f (x, p)) (2)

4 Examples of engineering design problems

In this final section of the lecture, three engineering design problems are introduced,
covering decision-making at architecture, component and calibration level. The sci-
entific papers relating to these problems are included as an accompaniment to the
lecture notes on MOLE.

4.1 Aerospace systems architecture design

4.1.1 Overview
As an example of an architecture-level problem, we consider the design of the over-
all control systems architecture for an aircraft. Over the past two decades, in the
aerospace sector, there has been a move from traditional, centralised control boxes
to more distributed control systems, featuring a network of sensors, actuators and
‘smart’ signal processing modules. Increasing moves toward electrification are also
challenging existing hardwired architectures for aircraft control. A key question is how
to design the overall architecture so that the functional requirements of the various
control systems are met.

4.1.2 Design variables and parameters

A schematic for a generic distributed aircraft control systems architecture is shown in
Figure 1. The main design variables x are:

• The number of signal processing modules in the system;

• The topology of the databus (ring, star, vertical, horizontal, and hybrid) and the
level of redundancy (simplex, duplex or triplex);
• The types and corresponding numbers of sensors and actuators, together with
their levels of redundancy (simplex, duplex or triplex).

Part II – Decision Systems for Engineering Design 7

Lecture 1: Introduction
 which can be simplex, duplex, triplex, smart or dumb. were de"ned. From Fig. 4 the architecture was de"ned to
Overall the optimisation process needs to consider: initially have 13 &on-engine' smart units which can be
(1) the number of smart interface units, connected via di!erent bus topologies. In practice, the
(2) the bus interconnection topology, use of 13 smart units is unlikely, given the weight limita-
(3) the mix of dumb/smart sensors/actuators. tions of current technology. It is therefore necessary to
cluster functionality into fewer units to meet require-
ments. If clustered, the sensor and actuator interconnec-
6. ASTOVL system optimisation tions are automatically rewired to the new combined
unit. This allows the system architecture to range from
Fig. 5 shows the approach adopted for systems archi- a totally centralised system to a system with thirteen
Prof. Robin Purshouse ACS6124 Multisensor and Decision
tecture optimisation. At the heart of the optimisation
Systems
distributed smart units.
University of Sheffield

Fig. 4. Conceptual ASTOVL aircraft design and baseline distributed control system.

Figure 1: Schematic of a generic distributed control systems architecture for aircraft

applications. Taken from Thompson et al.’s Distributed aero-engine control systems
architecture selection using multi-objective optimisation, 1999

4.1.3 Performance criteria

The performance criteria z against which each possible architecture design is as-
sessed are:

• Weight;
• Cost;

• Diagnostic capability;
• Risk;
• Maintenance.

Each criterion is treated as an objective, so there are no constraints in the prob-

lem formulation (this is common in conceptual design problems that are not directly
assessing the detailed requirements specification of a product). Note that each cri-
terion is itself a composite measure that combines, via a mathematical function, sev-
eral aspects relating to the associated theme. For example, the diagnostic capability
metric takes into account five distinct aspects of performance: local compensation,
self-diagnosis, remote diagnosis, reconfiguration of failure and time-limited dispatch.

4.1.4 Evaluation of a candidate design

Since conceptual design problems address the performance of a system in its totality,
it is often the case that there are few, if any, detailed physics models that can be har-
nessed to help with evaluating a design. Instead, high-level models are used, which

Part II – Decision Systems for Engineering Design 8

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield
H.A. Thompson et al. / Control Engineering Practice 7 (1999) 655}664 659

Fig. 5. Multiobjective optimisation of system architectures.

Figure 2: Components of a decision system. Taken from Thompson et al.’s Distributed

aero-engine control systems architecture selection using multi-objective optimisation,
1999

typically integrate expert opinion concerning the performance of building blocks of the
architecture (e.g. the ability of a smart sensor to self-diagnose might have been cap-
tured by an expert expressing the judgement on scale from 1 to 5, where 1 represents
“no capability”, and 5 indicates “excellent capability”). These models will contain crude
simplifications but are often regarded as ‘good enough’ for use in comparing different
architectures. An advantage of these models is that they are of low computational
complexity and can be used to evaluate many thousands of candidate designs within
typical resource budgets.

4.1.5 Example decision system

Fig. 6. Positioning for 13 smart units with ring, star, horizontal and vertical databuses.

The Rolls-Royce University Technology Centre (UTC) in Control & Monitoring Sys-
tems Engineering housed in ACSE has been developing decision systems for sys-
The interconnection architecture between smart units the databuses was found (Thompson and Fleming, 1995)
tems architecture design for over 20 years.to The
in terms of the number of databuses required and the
work reported by Thompson and
be a key parameter in previous work investigating
colleagues contains a good illustration
topolopy was "rst considered. A graphical interactive of an overall decision system, which is repro-
system weight.)
positioning
duced tool
inwas developed
Figure whichthe
2. Over allows smart units
coming lectures, weFault
willtolerance of each
be looking intopology
detail atwith respect of
aspects to fail-
to be the
placed at speci"c
decision pointsrelating
system on the engine.
to the Aso-called
local ures that could
‘MOGA’ blockbeat
accommodated
the heart ofbythe
the diagram.
system was also
optimisation is then performed to connect the units via considered (Fig. 7). For the ASTOVL system, ring archi-
a star network, a ring network, a horizontal databus tectures were found to be a signi"cant advantage when
4.2 running
Automotive the length of
battery design the engine and a vertical databus considering weight and fault tolerance. In particular, for
running around the circumference of the engine, as survival of two failures, a duplex ring architecture or
4.2.1 Overviewshown in Fig. 6. The interconnects required to connect a simplex combination of star and ring networks pro-
the main smart units in terms of the weight of the wire, vided the same level of fault tolerance for nearly the same
connectors, clips and brackets required to secure the weight. Interestingly, horizontal or vertical databuses
Hybrid vehicle engineers face particular challenges in how to package electric power
databuses from vibration is automatically calculated for performed poorly with respect to weight, and star archi-
technologies inside vehicles developed
simplex, duplex and triplex databuses. (The fastening of primarily
tectures tended those
without features
to perform poorly in mind.
with The
respect to both

Part II – Decision Systems for Engineering Design 9

Lecture 1: Introduction
 Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

q
X
h!q :¼ hi ðfðxÞÞ
i¼1

m and formulate the multi-objective problem

min½h!1 ðfðxÞÞ; …; h!m ðfðxÞÞ& (5)

x2X

Ref. [15] states that a feasible design of problem (4)

cient for problem (4) if and only if it is Pareto effi-
m (5). Thus, a solvable formulation for problem (5)
btain the equitable efficient designs of problem (4).
fðxÞÞ is known to coincide with the optimal objec-
following linear program:

min zq
zq ;tq ;dq;k

subject to
X
m (6)
zq ¼ qtq þ dq;k
k¼1

k ( fk ðxÞ; dq;k ( 0; for k ¼ 1; …; m

and zq are new auxiliary variables aiding in the

h!q ðfðxÞÞ. The variables tq, dq;k , and zq have no
context of problem (4). Note that x is a fixed con-
m (6). The construction of linear program (6) and Fig. 5 The relationship between the layout designs at the bat-
minimum objective value is h!k is developed Figureand
3: Battery
tery and hardware design problem for a hybrid electric vehicle. Taken from
vehicle levels
18]. Dandurand et al.’s Equitable multi-objective optimization applied to the design of a
timal objective value of problem (6) tohybrid evaluate
electric vehicle battery, 2013
blem (5) for q ¼ 1; …; m, problem (7) may be applied to problem (5), one may see that an optimal design of
ivalent reformulation of problem (5) [15]. Eq. (9) corresponds to the single-objective optimization
P problem
of minimizing h!m since, by definition, h!m ¼ k2K Dk . Therefore,
choice of battery hardware and configuration (including its structural connections to
min ½z1 ; …; zm & when the optimal design of Eq. (9) is uniquely obtained, it is a
the wider vehicle)
Pareto is a gooddesign
example of a (5)
hardware
(with fdesign problem. An example is
x;zq ;tq ;dq;k efficient of Eq. k ¼ Dk ; x ¼ pcell and
shown in Figure 3 for a Lithium-ion battery pack in
X ¼ ð1:0; 2:0&) and thus equitable for Eq. (3). a mid-sized saloon hybrid vehicle.
subject to
Due to the relative ease of formulating a min–max or min-sum
X m 4.2.2 Design variables and problem, the formulation of either problem (8) or (9) is preferred
parameters
(7)
tq þ dq;k ; tq free; q ¼ 1; …; m; to the formulation (via Eq. (7)) of problem (5) when one equitable
k¼1 The design design
variablesis preferred
x in this to the range
problem are:of equitable designs available by
k ) f k ðxÞ ( 0; d q;k ( 0; q; k ¼ 1; …; m solving problem (5). However, the battery layout design problem
• Batterymaycellbenefit
shape;from the available range of equitable designs obtain-
x2X able by solving problem (5). The battery layout design is subject
• Cell size;
to some feasibility constraints related to the arrangement of the
h the identification fk ¼ Dk ; k ¼ 1; …; m; x ¼ pcell , battery itself and other components inside of the vehicle. Determi-
0] can therefore be used to compute equitable• effi- Cell layout;
nation of optimal vehicle layouts is an optimization problem in
problem (3). which position of the battery is one of the design variables. In this
• Spacing between cells.
tion of this theory, we revisit the mentioned earlier context, the battery is also a morphable component because its as-
lation of the battery design problem (2) given as pect ratio is optimized to improve its performance. The optimal
battery aspect
Part II – Decision Systems for Engineering ratio obtained by either the min–max or min-sum
Design 10
min maxLecture fDk ðpcell1:ÞgIntroduction (8) formulation may be in conflict with some geometric constraints
pcell 2ð1:0;2:0& k2K
and space availability at the vehicle level. With the availability of
a range of equitable designs, the designer has the possibility to
ntifications fk ¼ Dk ; k ¼ 1; …; m; x ¼ pcell , and choose a battery layout that is more suitable for the vehicle-level
plied to problem (5), one may see that an optimal layout. The relationship between the layout designs at the battery
) corresponds to the single-objective optimization and vehicle levels is represented in Fig. 5.
imizing h!1 since h!1 is by definition the maximum
mponents Dk ; k 2 K. In this manner, one sees that
l design of Eq. (8) is unique, it is also Pareto effi-
3 Optimization
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

The problem features parameters p relating to heat flow coefficients in the vehicle
– these are not directly under the control of the battery design engineer but could
be regarded as linking variables (that are affected by other packaging choices in the
wider vehicle).

4.2.3 Performance criteria

As usual, weight and cost are important objectives to be minimized. Other objectives
specific to the battery problem are:

• Deviation in cell temperature from a target value (40o C in this example);

• Evenness of the temperatures across cells.

In the problem formulation as presented by Dandurand and colleagues (working at

BMW’s research centre in Clemson University), there is a temperature deviation ob-
jective for every column of cells in the battery pack. No constraints were formulated,
although we might imagine that these temperature criteria have hard limits, beyond
which the battery will be thermally compromised. Note also the higher level of de-
tail between these two objectives and those specified for the previous architecture
example.

4.2.4 Evaluation of a candidate design

Designs are evaluated using a lumped-parameter physics model of the battery pack
implemented in Simulink. The relatively low fidelity of this model, in comparison to
a distributed-parameter model, has implications for how accurately the performance
of each candidate design can be evaluated – this is why Dandurand’s team evaluate
temperatures for columns of cells rather than for individual cells. Note that the lumped-
parameter model has a benefit though, in that its function evaluations will be several
orders of magnitude faster than the equivalent distributed-parameter model.

4.3 Power generation controller design

4.3.1 Overview
Integrated gasification combined cycle (IGCC) power plants combine a gas and steam
cycle to help provide cleaner and more efficient power from coal sources. The gasifier
in the power plant converts a mix of pulverised coal and limestone, air and steam into a
fuel gas. The gasification process is a challenging control problem and was promoted
as an open benchmark problem by the company ALSTOM in the early 2000s. Griffin
and colleagues in ACSE’s Rolls-Royce UTC developed an H-infinity controller for the
gasifier, using decision system technologies to help tune the controller gains.

Part II – Decision Systems for Engineering Design 11

Lecture 1: Introduction
BS−1DTC )T 2. These genotypic representations are converted to the
corresponding phenotypes or decision variables.
=0 (9) 3. The performance of each member of the popula-
tion is assessed in turn using a prescribed objective
function [6 ].
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

h respect to coprime factor

Fig. 4 Loop-shaping controller structure
Figure 4: H-infinity robust control system for a power generation application with
weighting function matrices W1 and W2 . Taken from Griffin et al.’s
I05300 Multi-objective
© IMechE 2000
optimization approach to the ALSTOM gasifier problem, 2000

4.3.2 Design variables and parameters

A high-level schematic of the H-infinity control system is shown in Figure 4. The design
variables x are:
• The first order lags in the pre-plant diagonal matrix W1 (8 variables in total);
• The gains in the post-plant diagonal matrix W2 (4 variables in total).
From the perspective of the weighting function problem, parameters p relate to the
coefficients in the plant model G and the realised state-space controller K.

4.3.3 Performance criteria

The performance criteria z relate to the response of the system to a pressure distur-
bance and comprise four objectives to be minimised (all integrals of absolute error
(IAE) of the response over 300 seconds) and four constraints to be satisfied (all peak
fluctuations from the operating point):
• IAE of fuel gas calorific value;
• IAE of gasifier bed mass;
• IAE of fuel gas pressure;
• IAE of fuel gas temperature;
• Peak fluctuation of fuel gas calorific value;
• Peak fluctuation of gasifier bed mass;
• Peak fluctuation of fuel gas pressure;
• Peak fluctuation of fuel gas temperature.

Part II – Decision Systems for Engineering Design 12

Lecture 1: Introduction
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield

4.3.4 Evaluation of a candidate design

Evaluation of a candidate pair of weighting function matrices W1 and W2 is performed
using three linear state-space models that were developed through linearisation of a
non-linear gasifier model at three distinct operating points. The models are imple-
mented in Simulink and are fast to compute.

5 Further reading
1. Thompson H.A., Chipperfield A.J., Fleming P.J., Legge C. Distributed aero-
engine control systems architecture selection using multi-objective optimisation.
Control Engineering Practice 1999;7:655–664.

2. Dandurand B., Guarneri P., Fadel G., Wiecek M.M., Equitable Multi-Objective
Optimization Applied to the Design of a Hybrid Electric Vehicle Battery. Journal
of Mechanical Design 2013;135:(041004):1–8
3. Griffin, I.A., Schroder P., Chipperfield A.J., Fleming P.J. Multi-objective optimiza-
tion approach to the ALSTOM gasifier problem. Proceedings of the Institution
of Mechanical Engineers, Part I: Journal of Systems and Control Engineering
2000;214:453–468.

Part II – Decision Systems for Engineering Design 13

Lecture 1: Introduction