ACS6124 Multisensor and Decision Systems
Part II – Decision Systems for Engineering Design Lecture 1: Introduction
1 1.1
1.2
Module overview 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.
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
University of Sheffield Spring Semester 2019/2020
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield
1.3 Syllabus
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.
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, So ́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
3
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.
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.
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:
3.1
Part II – Decision Systems for Engineering Design 3 Lecture 1: Introduction
Prof. Robin Purshouse 1.
2.
3.
ACS6124 Multisensor and Decision Systems University of Sheffield
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).
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.
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.
3.2 Parameters
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.
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. Physicalconstants–empiricalvaluesidentifiedasbeingimportanttothephysics 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
3.3.1 Constraints
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.
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.
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.
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
3.3.2 Objectives
3.3.3 Preferences
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
x
subject to
f(x,p)
g(x,p)≤0
h(x, p) = 0
x∈D
p←P (1)
6
Part II – Decision Systems for Engineering Design 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) 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.
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
4
4.1
4.1.1 Overview
Aerospace systems architecture design
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: (1) the number of smart interface units,
(2) the bus interconnection topology,
(3) the mix of dumb/smart sensors/actuators.
6. ASTOVL system optimisation
Fig. 5 shows the approach adopted for systems archi-
initially have 13 &on-engine’ smart units which can be connected via di!erent bus topologies. In practice, the use of 13 smart units is unlikely, given the weight limita- 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- tions are automatically rewired to the new combined unit. This allows the system architecture to range from
a totally centralised system to a system with thirteen
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield tecture optimisation. At the heart of the optimisation distributed smart units.
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
4.1.5
Example decision system
Fig. 6. Positioning for 13 smart units with ring, star, horizontal and vertical databuses.
4.2
4.2.1 Overview
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.
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. The work reported by Thompson and
in terms of the number of databuses required and the to be a key parameter in previous work investigating
colleagues contains a good illustration of an overall decision system, which is repro-
topolopy was “rst considered. A graphical interactive system weight.)
positiodnuincgetdooinl wFaisgduervelo2p.edOwvheirchthaellocwosmsminargt ulencittsures, wFeauwltiltlobleeranloceokoifnegacihntodpeotlaoiglyawtiathsprespcetsctotof fail-
to be placed at speci”c points on the engine. A local ures that could be accommodated by the system was also the decision system relating to the so-called ‘MOGA’ block at the heart of the diagram.
optimisation is then performed to connect the units via
a star network, a ring network, a horizontal databus
considered (Fig. 7). For the ASTOVL system, ring archi- tectures were found to be a signi”cant advantage when considering weight and fault tolerance. In particular, for survival of two failures, a duplex ring architecture or a simplex combination of star and ring networks pro- vided the same level of fault tolerance for nearly the same
weight. Interestingly, horizontal or vertical databuses
running the length of the engine and a vertical databus
Automotive battery design
running around the circumference of the engine, as shown in Fig. 6. The interconnects required to connect the main smart units in terms of the weight of the wire,
connectors, clips and brackets required to secure the
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 primarily without those features in mind. The
simplex, duplex and triplex databuses. (The fastening of tectures tended to perform poorly with respect to both
Part II – Decision Systems for Engineering Design 9 Lecture 1: Introduction
Prof. Robin Purshouse
Xq
hq :1⁄4 hiðfðxÞÞ
i1⁄41
and formulate the multi-objective problem
min1⁄2h1ðfðxÞÞ; …; hmðfðxÞÞ x2X
ACS6124 Multisensor and Decision Systems
(5)
University of Sheffield
ef. [15] states that a feasible design of problem (4) ient for problem (4) if and only if it is Pareto effi- (5). Thus, a solvable formulation for problem (5)
tain 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
min 1⁄2z1; …; zm x;zq ;tq ;dq;k
subject to
when the optimal design of Eq. (9) is uniquely obtained, it is a
the wider vehicle) is a good example of a hardware design problem. An example is
Xm k1⁄41
(6)
zq 1⁄4 qtq þ
fkðxÞ; dq;k 0; for k1⁄41;…;m
m
dq;k ; tq free;
fkðxÞ0; dq;k 0; q;k1⁄41;…;m
x2X
q þ
q 1⁄4 1; …; m; (7) to the formulation (via Eq. (7)) of problem (5) when one equitable k1⁄41 Thedesigndveasriganbliesspxreifnertrheidstporothbelermanagreeo:fequitabledesignsavailableby
dq;k
nd zq are new auxiliary variables aiding in the hqðfðxÞÞ. The variables tq, dq;k, and zq have no ontext of problem (4). Note that x is a fixed con-
(6). The construction of linear program (6) and minimum objective value is h is developed and
The relationship between the layout designs at the bat-
8].
Fig. 5
k Figure 3: Batetrteyraynhdavredhwicalreeledveslsign problem for a hybrid electric vehicle. Taken from
timal objective value of problem (6) to evaluate
hybrid electric vehicle battery, 2013
blem (5) for q1⁄41;…;m, problem (7) may be
applied to problem (5), one may see that an optimal design of
] can therefore be used to compute equitable effi-
nation of optimal vehicle layouts is an optimization problem in which position of the battery is one of the design variables. In this
Dandurand et al.’s Equitable multi-objective optimization applied to the design of a
Eq. (9) corresponds to the single-objective optimization problem
valent reformulation of problem (5) [15]. of minimizing h since, by definition, h 1⁄4 P D . Therefore,
m m k2Kk
choice of battery hardware and configuration (including its structural connections to
Pareto efficient design of Eq. (5) (with fk 1⁄4 Dk ; x 1⁄4 pcell and
shown in Figure 3 for a Lithium-ion battery pack in a mid-sized saloon hybrid vehicle.
X 1⁄4 ð1:0; 2:0) and thus equitable for Eq. (3).
Due to the relative ease of formulating a min–max or min-sum
problem, the formulation of either problem (8) or (9) is preferred X 4.2.2 Design variables and parameters
solving problem (5). However, the battery layout design problem
•Battermyacyelblesnheafiptef;romtheavailablerangeofequitabledesignsobtain-
able by solving problem (5). The battery layout design is subject • Cell size;
to some feasibility constraints related to the arrangement of the
the identification fk 1⁄4 Dk ; k 1⁄4 1; …; m; x 1⁄4 pcell , battery itself and other components inside of the vehicle. Determi- • Cell layout;
problem (3).
tion of this theory, we revisit the mentioned earlier
ation of the battery design problem (2) given as
Part II – Decision Systems for EnbgainttereyrinasgpDecetsriagtnio obtained by either the min–max or min-sum 10
• Spacing between cells.
context, the battery is also a morphable component because its as-
min maxfDk ðpcell Þg (8) pcell2ð1:0;2:0 k2KLecture 1: Introduction
tifications fk 1⁄4 Dk;k 1⁄4 1;…;m;x 1⁄4 pcell, and
lied to problem (5), one may see that an optimal ) corresponds to the single-objective optimization mizing h1 since h1 is by definition the maximum ponents Dk ; k 2 K. In this manner, one sees that l design of Eq. (8) is unique, it is also Pareto effi-
formulation may be in conflict with some geometric constraints and space availability at the vehicle level. With the availability of a range of equitable designs, the designer has the possibility to choose a battery layout that is more suitable for the vehicle-level layout. The relationship between the layout designs at the battery and vehicle levels is represented in Fig. 5.
3 Optimization
pect ratio is optimized to improve its performance. The optimal
m
R c m
b
k
a
c m
1
i
t k
h 0
l
n p
i m
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).
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 (40oC 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.
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.
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
4.2.3
4.2.4
4.3
4.3.1 Overview
Power generation controller design
h
BS−1DTC )T
2. These genotypic representations are converted to the
corresponding phenotypes or decision variables.
3. The performance of each member of the popula- tion is assessed in turn using a prescribed objective
function [6].
ACS6124 Multisensor and Decision Systems University of Sheffield
=0 (9) Prof. Robin Purshouse
respect to coprime factor
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
Fig. 4 Loop-shaping controller structure
Figure 4: H-infinity robust control system for a power generation application with
weighting function matrices W and W . Taken from Griffin et al.’s Multi-objective
12
I05300 © IMechE 2000
Prof. Robin Purshouse ACS6124 Multisensor and Decision Systems University of Sheffield
4.3.4
5
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.
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