2.1 Set-based design

Engineering design can be described as a process to devise a system in order to satisfy a set of predefined requirements (Ertas and Jones Reference Ertas and Jones1996; Cross Reference Cross2008). The process varies considerably from one approach to the other. Howard, Culley and Dekoninck (Reference Howard, Culley and Dekoninck2008) compared more than twenty different engineering design processes and outlined how they differ in each step. Choosing the appropriate process is a critical factor for a successful design as Khandani (Reference Khandani2005) states. Regardless of the approach used, the process aims to provide a framework that makes the process efficient, clarifies the problem, drives innovation, manages complexity, and promotes collaboration (Holston Reference Holston2011).

The process can be split into two main approaches. The first, the iterative process, which is also known as point-based approach or point-based design. In this case, only one initial design is selected from a pool of candidate solutions. The design is then refined and reworked in an iterative process until the final desirable version emerges. Variations of the point-based approach have been proposed by Pugh (Reference Pugh1991), French (Reference French1998), Ullman (Reference Ullman2002), and Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2006), amongst others.

In contrast to the iterative approach, the second one is the convergent approach. In this case, a number of potential solutions are selected, which are then matured and evaluated in parallel. Whereas the iteration in point-based approaches is for redesigning and refining the solution, the iterations in a convergent approach primarily aim to discard undesirable, infeasible, or non-robust solutions. The remaining desirable ones, will then undergo further development. Convergent approaches include the Method of Controlled Convergence (MCC) by Pugh (Reference Pugh1991), the Design-Build-Test (DBT) cycle by Wheelwright (Reference Wheelwright2011), and the SBD (Ward and Liker Reference Ward and Liker1994).

Arising from the Toyota Product Development System (TPDS), set-based design (also referred to as set-based concurrent engineering) allows parallel evaluation of multiple alternative configurations in the early stages of design by using sets of possible solutions (Ward and Liker Reference Ward and Liker1994; Singer, Doerry and Buckley Reference Singer, Doerry and Buckley2009).

The procedure, as described by Sobek, Ward and Liker (Reference Sobek, Ward and Liker1999), starts by mapping the design space and defining the feasible regions while exploring the trade-offs by designing different alternatives. A number of feasible concepts are developed based on sets that are fully functional across all disciplines and looks for possible intersections between those feasible sets. Finally, the sets are narrowed down and increase the detail of the designs; given that the narrowing down is done consensually amongst multidisciplinary teams, therefore creating commitment from each of the disciplines.

When dealing with physical systems that have discrete design parameters (i.e. subsystem options or components), generating the configurations is straight forward. The first step is to identify the design parameters of the system and tabulate their respective possible options. Different combinations of options generate a set of competing configurations. The configurations are then evaluated against predefined performance metrics, and the non-robust or undesirable ones are discarded; the rational for discarding is recorded as information for future use. The remaining configurations are then matured, and the evaluation process is repeated until the desirable configurations emerge. Figure 1 shows the outline of the process.

Figure 1. Set-based design approach.

The SBD approach offers a number of advantages over traditional development processes; it has been well documented with some authors even claiming that the approach (and related Lean practices) can be up to four times more productive (Morgan and Liker Reference Morgan and Liker2006; Ward and Sobek Reference Ward and Sobek2014; Raudberget Reference Raudberget2015).

Delaying critical design decisions, in order to fully understand the customer specifications and requirements, can reduce the possibility of design changes later on, which otherwise could have been costly (Ward et al. Reference Ward, Liker, Cristiano and Sobek1995; Kennedy, Sobek and Kennedy Reference Kennedy, Sobek and Kennedy2014).

The approach has also been shown to have positive effects on the resulting product and the development process itself. Not only does it avoid costly reworks, the risk of failure is also reduced (due to other feasible solutions being available at all stages). It also promotes innovative thinking and creativity along with organisational knowledge and learning (Khan et al. Reference Khan, Al-Ashaab, Doultsinou, Shehab, Ewers and Sulowski2011, Reference Khan, Al-Ashaab, Shehab, Haque, Ewers, Sorli and Sopelana2013).

The topic of SBD is an active area of research and, though limited, industrial applications of SBD have been documented (Malak, Aughenbaugh and Paredis Reference Malak, Aughenbaugh and Paredis2009). Ward et al. (Reference Ward, Liker, Cristiano and Sobek1995) and Sobek et al. (Reference Sobek, Ward and Liker1999) argued that SBD was a key to Toyota’s and TPDS success. Raudberget (Reference Raudberget2010) and Raudberget et al. (Reference Raudberget, Levandowski, Isaksson, Kipouros, Johannesson and Clarkson2015) investigated how SBD can be implemented in existing product development companies through industrial case studies, while Mebane et al. (Reference Mebane, Carlson, Dowd, Singer and Buckley2011) applied the SBD approach to the design of a Ship to Shore Connector.

Set-based concurrent engineering has also been the main enabler of the large European project, LeanPPD, which aimed to address the need of European manufacturing companies for a new lean model beyond just manufacturing (Al-Ashaab et al. Reference Al-Ashaab, Golob, Attia, Khan, Parsons, Andino, Perez, Guzman, Onecha, Kesavamoorthy, Martinez, Shehab, Berkes, Haque, Soril and Sopelana2013; Khan et al. Reference Khan, Al-Ashaab, Shehab, Haque, Ewers, Sorli and Sopelana2013). Furthermore, Guenov et al. (Reference Guenov, Nunez, Molina-Cristobal, Datta and Riaz2014) developed an interactive computational tool that facilitates a SBD workflow and applied it to the design of a conceptual aircraft.

Where the set-based approach considers a lot of design options both at system level and subsystem level, and eventually narrows down to one, point-based deals with just one design configuration from the beginning. This main difference means that both approaches have their benefits and drawbacks when compared against each other (Al-Ashaab et al. Reference Al-Ashaab, Golob, Attia, Khan, Parsons, Andino, Perez, Guzman, Onecha, Kesavamoorthy, Martinez, Shehab, Berkes, Haque, Soril and Sopelana2013).

With the ability to consider many alternative options simultaneously, the set-based approach offers a lot more flexibility. This is particularly true in multidisciplinary cases where, due to the modularity of the approach, it offers a significant advantage over the point-based approach. However that flexibility brings uncertainty into the process when compared to an iterative approach where only one option is considered. The flexibility and consideration of multiple options means that there is a delay in the decision-making process in order to converge to the final chosen design configuration; unless the narrowing is done aggressively. As a result, it can make it a more resource demanding process, especially in early stages due to front-loading.

Even though the initial costs might be higher for SBD, the availability of alternative solutions at any point in the design process, reduces the impact of a possible design change. Such a feature is not provided by a point-based approach, increasing the cost of a potential design change or design failure.

Due to the knowledge generation that SBD provides, future implementations of it in similar projects can reduce the development time because the information is readily available. In an iterative process, the knowledge generated is very limited because of the confined and constrained design space such an approach takes place in.

It is the authors’ opinion, that in the case of complex systems such as an aircraft, SBD is the better suited option. This is due to the fact that an aircraft design is a long, costly, and complex process that involves many disciplines. This creates a multidimensional design space that a point-based approach would struggle to explore thoroughly. Furthermore, due to the high possibility of changes in initial design and requirements, flexibility in the initial stages is essential, as design changes occurring in later stages using a point-based approach could yield prohibitively high costs. Adding to that, aircraft manufacturers tend to provide different configurations for each aircraft (aircraft families), something that SBD and platform-based design can accomplish (Levandowski, Raudberget and Johannesson Reference Levandowski, Raudberget and Johannesson2014; Landahl et al. Reference Landahl, Levandowski, Johannesson and Isaksson2016; Levandowski, Muller and Isaksson Reference Levandowski, Muller and Isaksson2016; Riaz, Guenov and Molina-Cristobal Reference Riaz, Guenov and Molina-Cristobal2017).

2.2 Optimisation

Optimisation methods aim to reach an optimum or a non-dominated solution by minimising or maximising an objective function $f(\mathbf{x})$ . The function is dependent on a number of design variables that form the design vector $[\mathbf{x}]$ , which can be bound by constraints (Nocedal and Wright Reference Nocedal and Wright2006).

(1) $$\begin{eqnarray}\text{min}f(\mathbf{x})\end{eqnarray}$$

subject to:

$$\begin{eqnarray}{x_{i}\!}_{L}<x_{i}<{x_{i}\!}_{U}\quad x_{i}=1,2,3\ldots n\end{eqnarray}$$

where ${x_{i}\!}_{L}$ and ${x_{i}\!}_{U}$ are the lower and upper bounds of each design variable, respectively.

Optimisation has been an active field of research in the aerospace industry for many years with applications ranging from aerodynamic and aeroelasticity optimisation (Ebrahimi and Jahangirian Reference Ebrahimi and Jahangirian2014; Wunderlich Reference Wunderlich2015), to structures, weight and manufacturability (Toropov et al. Reference Toropov, Jones, Willment and Funnell2005; Oktay, Akay and Merttopcuoglu Reference Oktay, Akay and Merttopcuoglu2011).

When designing complex systems such as an aircraft, the optimisation process needs to take into consideration the different disciplines involved, such as structures, aerodynamics, aeroelasticity and costs. Optimisation methods that aim to address and take into consideration more than one discipline are known as MDO methods. Sobieski and Haftka (Reference Sobieski and Haftka1997) defined MDO as ‘a methodology for the design of systems in which strong interaction between disciplines motivates designers to simultaneously manipulate variables in several disciplines’. However, the term has evolved to encompass any kind of optimisation process that involves more than one discipline (Sobieski and Haftka Reference Sobieski and Haftka1997) or strongly coupled elements (Guenov et al. Reference Guenov, Fantini, Balachandran, Maginot, Padulo and Nunez2010).

Most real-world problems, especially in MDO, involve more than just one objective. Multiobjective optimisation (sometimes referred to as multicriterion) deals with two or more objective functions:

(2) $$\begin{eqnarray}\min [f_{1}(\mathbf{x}),f_{2}(\mathbf{x})\ldots f_{n}(\mathbf{x})].\end{eqnarray}$$

In such cases, there is usually a trade-off between objectives; therefore, there is no unique optimum solution but a range of non-dominated solutions. That is, solutions that perform better at one objective but worse towards others.

When dealing with biobjective optimisation (two objective functions), a common method to visualise the non-dominated solutions is the Pareto front shown in Figure 2.

Figure 2. Pareto graph for a 2-objective optimisation (minimisation) problem.

The Pareto front method is useful for visualising the trade-offs between two objectives. From there on however it is limited in the sense that the respective variables for each solution are not visualised and the graph cannot be applied in optimisation problems with more than two objectives.

For this reason, parallel coordinates are employed to help visualise the different solutions for more than three objectives along with their respective variables. This not only allows for multidimensional data visualisation, but it also assists in identifying positive and negative relationships between objectives and variables (Inselberg Reference Inselberg2009). This makes parallel coordinates a very powerful tool in visualising multidimensional data especially in engineering design (Kipouros et al. Reference Kipouros, Inselberg, Parks and Savill2013), but also driving optimisation processes (Hettenhausen, Lewis and Kipouros Reference Hettenhausen, Lewis and Kipouros2014).

Parallel coordinates consist of parallel axes that each represents the objective functions and any other parameters that are of interest. Polylines are then being used, passing through all of the axes, with each line representing a solution. Figure 3 illustrates a simple example of how three random 3-Dimensional points in a scatter (stem) plot can be converted to parallel coordinates. Each point has three values, one for each dimension, and those values are connected with a polyline between the axes. There are only three axes since there are three dimensions. Each polyline represents one point in a multidimensional space. Each additional dimension requires an additional parallel coordinate axis to be introduced.

Figure 3. Stem plot for three points and the respective parallel coordinates visualisation.

2.3 Set-based design and MDO tools

In order to identify the strengths of the two areas that this work is concerned with it is useful to compare and contrast the two. The most important difference between them is that SBD is an approach to designing systems, whereas MDO is used as methodology to fine-tune the engineering characteristics of a system. Set-based design is primarily used in early stages of design where the design space is large and not as constrained as it will be at later stages. A number of different options are available for each domain and subsystems, and a combination of those, forms a number of configurations that are used as initial designs. Those designs will then be assessed and evaluated in order to remove the infeasible, non-robust, or less desirable ones. The assessment, evaluation, and discardment process is repeated until a final desirable design emerges. At each iteration, the configurations that have not been discarded are matured and assessed against new performance metrics and criteria.

On the other hand, MDO tools are employed at a different stage of the design process and for different reasons. It is primarily used to fine-tune engineering characteristics in order to achieve predefined performance objectives while meeting the required constraints and parameters. As a result, a tool like this is used at later stages of the design process where an overall configuration has been selected. The aim in this case is to find the optimum and non-dominated variations of that design as opposed to the set-based approach where the aim is to eliminate infeasible and undesirable ones.

There are a number of previous research publications that attempted to bring together the two areas of SBD and optimisation. Hannapel and Vlahopoulos (Reference Hannapel and Vlahopoulos2014) introduced principles of SBD in MDO where a new algorithm was developed that studies the design variables in terms of sets. Veenhuis (Reference Veenhuis2008) modified the particle swarm optimisation (PSO) algorithm by replacing the position and velocity vectors of the particles with sets.

However the aforementioned researches only use principles of SBD for developing novel optimisation methods and algorithms. In other words, they integrated a set-based approach in an MDO algorithm. The framework developed as part of this project aims to address what no previous research attempted to do; to integrate MDO tools in an SBD approach. This will bring the two areas together in a unified framework that exploits the benefits of both.

3.1 Stage 1

Stage 1 deals with the decomposition of the system and the generation of configurations. Initially, only instances of the configurations are created before gradually moving to more complete computational models of each one. The instances describe how each configuration is synthesised; including the dimensions and options from each design parameter. The stage is also concerned with converting the continuous parameters to discrete and handling the initial infeasibility and undesirability constraints, which leads to the transformation of the design space as previously described. Figure 5 shows the flow diagram of the first stage.

Figure 5. ADOPT framework Stage 1.

The first step is to identify the levels, the disciplines or the areas that form the system. In this case the system is partitioned into two levels: the high level, which considers external parameters that affect the system but are not within the system itself, and the low level which includes the subsystems and components of the system being designed. Additional intermediate levels of the system can be added where appropriate.

Following the process of the SBD, as presented in Figure 1, each level is further elaborated into its design parameters. Each design parameter has a number of possible options, be it discrete ones in the case of the low level subsystems and components, or continuous ones in the form of ranges in the case of high-level dimensions. Before proceeding to generate the configurations, the continuous parameters need to be converted to discrete. This is done in order to generate a finite number of possible combinations amongst all options of each design parameter. Continuous parameters would not allow such combinations because an infinite number of values exists between any range of continuous values.

The most straightforward approach to discretising a continuous range is to split the range into smaller ranges and assign a linguistic term to each range such as ‘High’, ‘Medium’, or ‘Low’. Combining options afterwards becomes easier and straightforward; for example, a ‘High’ option for one design parameter with a ‘Medium’ option for another design parameter. The linguistic term used for the variables, depends on the type of design parameter being described. A simple example of a range being discretised is shown in Figure 6.

Figure 6. Example of discretising a continuous range.

The discrete values will be converted back to their respective ranges in the second stage of the framework for optimisation purposes.

Completing the identification of the levels and their respective design parameters, and after the continuous parameters have been discretised, the process of generating the configurations begins. By taking one option for each design parameter the configurations are formed. Initially, the combination of options happens at each level independently; meaning that the combinations of high-level parameters are independent from the low level ones. This is to allow better handling of the configurations and for performing infeasibility checks.

Introducing infeasibility and undesirability constraints, allows the elimination and discardment of configurations before moving to the second stage. Discarding configurations, directly translates to rejecting areas in the fragmented design space. Allowing the optimisers in the second stage to skip areas in the design space, eliminates the unnecessary use of computational power and time that would have been used to evaluate configurations that violate constraints. After the infeasibility checks take place at each level and the infeasible configurations are discarded, the high-level combinations are combined with the low level ones to form the full design architectures.

The combined configurations are then filtered through new infeasibility constraints before assessing them against undesirability constraints. The difference between the two is that the undesirable configurations are the ones that are currently not of interest, not feasible or not desirable due to limitations in technology or otherwise, but could become feasible in the future. For this reason the undesirable configurations are stored in a separate database to be re-evaluated at a future stage. The infeasible ones are the ones that are practically or otherwise impossible to implement and are discarded completely.

The inclusion of constraints this early is very important, due to the large number of configurations the first stage of the framework can generate which can be in the thousands even for simple systems. Discarding a portion of those configurations can make the second stage of the framework faster, and enable the allocation of people and resources to the feasible and desirable ones. All the configurations that have passed the infeasibility and undesirability constraints are stored and proceed to Stage 2 of the framework for further evaluation.

3.2 Stage 2

The second stage follows an iterative and converging process, where at each iteration the undesirable configurations are eliminated, hence progressively narrowing the design space. The process of the second stage of ADOPT is presented in Figure 7.

Figure 7. ADOPT framework Stage 2.

The first step of the second stage is to transform the discretised parameters of each configuration, back to their respective continuous ranges. Using Figure 6 as an example, the discrete values can be reverted back to their ranges in a straightforward way; a ‘High’ option will revert to a range of 20–30 and so on. The ranges of continuous parameters now become the constraints for the optimisation process. The ranges of each parameter become the upper and lower boundaries for the design space of each configuration. This creates a more confined space, in which the optimiser seeks non-dominated solutions.

The configurations are then passed through to the iterative stage of the framework where each one is optimised against a set of predefined objectives. However, in many cases, not every design parameter will affect the optimisation objective(s). Therefore two competing configurations that only differ in a design parameter that does not affect the objective (a ‘Dormant’ parameter), will yield the same optimisation results. Identifying the ‘active’ and ‘dormant’ parameters for optimisation is crucial as it can vastly reduce the optimisation time due to eliminating duplicate optimisation runs.

Configurations that differ only in dormant parameters options will yield the same optimisation results and are therefore placed in the same optimisation cluster. Only one configuration from each cluster needs to go through the optimisation process and the results will be shared with the remaining configurations within that cluster.

A simple and straightforward approach in identifying the active and dormant parameters would be to use a Design Structure Matrix (DSM) to visualise the connections between design parameters and optimisation objectives. DSMs are widely used as compact network modelling tools in engineering design to decompose and visualise system architectures (Browning Reference Browning2001; Eppinger and Browning Reference Eppinger and Browning2012). It provides the ability to visualise the connections and dependencies between the different elements of a system. They have also been used in predicting how design changes can propagate through a system (Clarkson, Simons and Eckert Reference Clarkson, Simons and Eckert2004), as well as the associated propagation costs (Georgiades et al. Reference Georgiades, Sharma, Kipouros and Savill2017). This enables the same DSM representation to be utilised for multiple purposes; as opposed to using a different tool for each purpose.

Figure 8. Example of a DSM for identifying active and dormant parameters.

Figure 8 presents a simple DSM example of a system with four design parameters and one optimisation objective. At this stage, the interdependencies between the design parameters are not being consider, instead only the parameters that directly affect the objective are considered. It becomes immediately apparent that only the first three design parameters are affecting the optimisation objective and not the 4th one. This makes the first three parameters active and the last one dormant.

This means that configurations that share the same options for the first three design parameters will yield the same optimisation results. Any variation in the 4th parameter will not alter the outcome of the optimisation process. It is worth noting however that even though the 4th parameter is dormant for this specific objective, it might affect the system in other ways, such as performance or optimisation objectives in future iterations.

In the case of multiobjective optimisation a number of non-dominated solutions will emerge for each configuration, thus expanding the design space around each one, but also providing alternatives for each configuration. In the case where a selected configuration has to undergo design changes at a later stage due to a change in requirements, there are alternative solutions to select from. This can reduce or even eliminate the need for major redesigns and subsequently the cost of the rework.

Further simulations can take place for each configuration, to obtain performance metrics for the value drivers at each iteration. A value driver is anything that adds value to the final product or system and tends to be a measurable objective (Isaksson et al. Reference Isaksson, Kossmann, Bertoni, Eres, Monceaux, Bertoni, Wiseall and Zhang2013). A useful measurement of performance is the use of penalty weights for each option. Depending on the system in consideration, each option can have penalties with regards to complexity, cost, or weight. Penalties are usually assigned on a range from 1 to 10, with 10 being the highest, and are primarily knowledge-based. Adding up the penalties for the selected options of each subsystem that make up the configuration, will give a metric of how costly (for example) that configuration would be compared to others. Such an approach will benefit the early stages of design decision-making for use in trade studies where a fast approach is required due to the large number of configurations being considered.

After the set of feasible and desirable configurations has been narrowed down, the computational power can be transferred to the remaining active configurations where it can now be utilised for a more detailed evaluation of them. This allows for new performance metrics to be introduced and more detailed simulations to take place.

The iterative step is performed repeatedly until the desirable number of configurations have remained, which by this stage will have been matured enough and evaluated thoroughly against the other options. At each iteration new objectives, performance metrics, and value drivers are introduced. The process of the second stage assists in selecting configurations that are optimised, potentially more robust, and have available alternatives in case of a change in requirements.

5.1 Design parameters

5.1.1 Aircraft level parameters

The high-level system considered here is concerned with the geometry, material, and engines of the aircraft. For continuous parameters, the ranges are knowledge-based and obtained from historical data (Ardema et al. Reference Ardema, Chambers, Patron, Hahn, Miura and Moore1996; Jenkinson Reference Jenkinson1999). Table 1 presents the design parameters of the aircraft level.

Table 1. Aircraft level design parameters

Out of the seven continuous parameters, three of them (taper ratio and thickness/cord ratios) will not be discretised in order to generate the configurations. Instead, all the configurations will share the same ranges for those three parameters and consequently will have the same bounds for optimisation. This is due to their small range and small effect on the result, compared to the rest.

5.1.2 System level parameters

As opposed to the aircraft level that comprised of both continuous and discrete parameters, the fuel system level is entirely comprised of discrete parameters. The parameters are primarily with regards to the fuel tanks configuration and subsystem options. Table 2 shows the design parameters of the level with their respective options.

Table 2. Fuel system level design parameters

The venting system is a mandatory subsystem but has no options, which is the reason why it is not included in the table. It is also a subsystem that is defined and sized according to the rest of the design parameters.

5.2 Matrix view of the system

To create a model of the system network, the connections and design dependencies need to be visualised within and between the different levels of the system. Matrix methods can be employed to achieve that. Figure 10 presents a DSM representation of the overall system and the interconnections between the design parameters.

Figure 10. DSM view of the system.

It is important to notice that some of the connections represent design dependencies while others represent constraints that involve the two connected elements. For example the connections with the wing tank cells element, are both design dependencies, since the number of tank cells are dependent on the length of the span and the material of the wing. On the other hand, the mirrored connections between span and aspect ratio, represent a constraint between the two elements. The constraints considered for this case study are further explained at a later section.

The DSM can assist in identifying elements that have a large design impact on the rest of the system, but can also identify elements that are highly dependent on others. This can assist in the case of sequential design, where for example, the design of the transfer system is affected by six other elements, but only has an impact on the design of the jettison system since they usually share the same pipelines.

5.3 Generation of configurations

After the system has been elaborated down to its design parameters and elements, and the options for each one have been identified, the concept generation begins. In order to generate a finite number of all possible configurations, all the continuous parameters need to be discretised into ranges and assign a linguistic term to each one. The number of ranges that each continuous parameter is split into, depends on a number of factors including the type of parameter and the size of the range. Table 3 presents how the continuous parameters are discretised for the current case study.

Table 3. Discretisation of continuous parameters (LB: Lower Bound; UB: Upper Bound)

5.4 Stage 1 Constraints

5.5 Identification of configurations

In order to manage and identify the configurations easily, a configuration ID is assigned to each one. The IDs comprise the initials of the options for each design parameter, forming a string of characters. Table 4 shows the initials corresponding to each option.

Table 4. Initials for configuration IDs

Following the table above, the unique identification number (configuration ID), can be synthesised for each configuration. In the case of a (L)ow aspect ratio, (S)hort span, (L)ow sweep angle, (N)arrow body, (A)luminium wings, (2) Engines, (1) wing tank cell, (Y)es to a centre tank, (0) ACTs, (N)o Trim tank, (Y)es to an inerting system, (B)oth a gravity and pressure transfer system, and (N)o Jettison system would yield the configuration ID LSLNA21Y0NYBN. A schematic representation of the above configuration and a configuration of the other extreme (high aspect ratio, long span, etc.) is shown diagrammatically in Figure 11.

Figure 11. Scaled representation of the LSLNA21Y0NYBN and HLHWA23Y0NYBN configurations.

The approach used here with the initials of each option, is useful for this application area where a relatively small number of parameters is considered. Larger and more complex systems would require an alternative approach, such as a machine-readable ID, rather than a human-readable one which is used in this example.

5.6 Optimisation

The most important step of the second stage of the framework is the optimisation process. The step aims to explore the confined design-space areas for each configuration and find the optimum or the non-dominated solutions for each one. In this case study, two objectives are considered to demonstrate the trade-off in multiobjective optimisation when considering competing objectives.

Before the optimisation process takes place, the design parameters that were previously discretised, need to be reverted back to their continuous ranges. Those ranges become the optimisation constraints for each continuous parameter. Following the discretisation in Table 3 each configuration defines its constraints using the ranges previously selected. In this case, a low aspect ratio configuration, will have its Lower Bound (LB) at 7 and its Upper Bound (UB) at 8.5 for the aspect ratio variable. Any value above 8.5 would violate the constraints since it falls into the high aspect ratio area where other configurations lie.

5.6.1 Wingbox volume calculation

One of the objectives for optimisation is to maximise the volume of the wingbox. The larger the volume, the more fuel can be stored in the wing. To calculate the volume, an analytical approach is used as presented in the NASA technical memorandum by Ardema et al. (Reference Ardema, Chambers, Patron, Hahn, Miura and Moore1996).

(3) $$\begin{eqnarray}\displaystyle V_{W} & = & \displaystyle \frac{b_{S}(1-C_{S_{1}}-C_{S_{2}})\cos (\unicode[STIX]{x1D6EC}_{S})}{3}\nonumber\\ \displaystyle & & \displaystyle \times \,[R_{t_{R}}C_{R}(2C_{R}+C_{T})+R_{t_{T}}C_{T}(C_{R}+2C_{T})]^{\phantom{\frac{1}{2}}}\nonumber\\ \displaystyle & & \displaystyle \nonumber\\ \displaystyle & & \displaystyle \underbrace{+(1-C_{S_{1}}-C_{S_{2}})R_{t_{R}}C_{R}^{2}w_{C}}_{\text{Carrythrough Structure}}\end{eqnarray}$$

$$\begin{eqnarray}\begin{array}{@{}rcll@{}}A\,\, & =\,\, & {\displaystyle \frac{b^{2}}{AR}}\quad & b_{S}={\displaystyle \frac{b-w_{C}}{2\cos (\unicode[STIX]{x1D6EC})}}\\ C_{R}^{\prime }\,\, & =\,\, & {\displaystyle \frac{2A}{b(1+TR)}}\quad & C_{T}=TR\times C_{R}^{\prime }\\ C_{R}\,\, & =\,\, & C_{R}^{\prime }-{\displaystyle \frac{w_{C}}{b}}(C_{R}^{\prime }-C_{T})\quad & \end{array}\end{eqnarray}$$

where $V_{W}$ is the wingbox volume, $b_{S}$ is the structural semispan of the wing, $C_{S_{1}}$ is the unusable part of the leading edge as a percentage of the chord, $C_{S_{2}}$ is the unusable part of the trailing edge as a percentage of the chord, $\unicode[STIX]{x1D6EC}_{S}$ is the sweep angle of the structural span at quarter-chord line, $R_{t_{R}}$ is the thickness-to-chord ratio at root, $R_{t_{T}}$ is the thickness-to-chord ratio at tip, $C_{R}$ is the root chord of wing at fuselage intersection, $C_{T}$ is the tip chord, $w_{C}$ is the width of the carrythrough structure of the wing, $A$ is the area of the wing, $AR$ is the aspect ratio, $b$ is the span if the wing, $C_{R}^{\prime }$ is the theoretical root chord and $TR$ is the taper ratio. Some of the aforementioned parameters are shown in Figure 12.

Figure 12. Structural wingbox and carrythrough structure.

We consider the centre tank volume equal to the volume of the carrythrough structure. Therefore, the second part of the equation for the carrythrough, becomes zero for the configurations where no centre tank is present.

Each configuration has different bounds for the aspect ratio, wing span, sweep and the fuselage width, which are defined in the first stage during the generation of the configurations. In order to calculate the wingbox volume using the formula presented above, a number of other variables are required, the bounds of which are shared between all configurations. The three parameters that have the same range are the taper ratio and the thickness/chord ratio for both the tip and the root chord. Furthermore, the unusable parts of the leading and trailing edges, $C_{S_{1}}$ and $C_{S_{2}}$ , are constant at 0.14 and 0.2, respectively; as a percentage of the chord.

5.6.2 Surge tank volume calculation

The second objective of the optimisation process is to minimise the volume of the surge tank; it is assumed to be three times the volume of the vent pipe for each wing. For simplification purposes, we assume that the length of the vent pipe is equal to the structural semispan of the wing plus $10\%$ of the width of the carrythrough structure and the vent pipe has a constant radius of 0.05 m.

(4) $$\begin{eqnarray}V_{S}=3(b_{S}\times \unicode[STIX]{x1D70B}r^{2})+\underbrace{3(0.1w_{C}\times \unicode[STIX]{x1D70B}r^{2})}_{\text{Centre Tank section}}.\end{eqnarray}$$

For cases where a centre tank is not present the second part of the equation becomes zero.

5.7 Identification of active and dormant parameters

A DSM is employed to map the dependencies between the design parameters and the optimisation objectives. Using the DSM in Figure 10, two additional elements are added to represent the two objectives. From there on the dependencies can be mapped; using the objective functions and identifying the variables that affect them. Figure 13 shows the expanded DSM.

Figure 13. Identification of active parameters for optimisation.

Using Figure 13 the active parameters become clear. For example, any competing configurations that only differ in the number of engines, or the number of ACTs, will have similar optimisation results. The active parameters that do affect the optimisation are:

1. (i) Span

2. (ii) Aspect Ratio

3. (iii) Sweep Angle

4. (iv) Fuselage width

5. (v) Taper Ratio (however this is a shared range between all configurations)

6. (vi) Centre Tank

7. (vii) Venting System

5.8 Complexity and weight penalties

Following the optimisation process outlined in the previous section, a configuration with a long span, will result in a larger wingbox volume when compared to a configuration with a short span; given that all other design parameters remain the same. However, the long span configuration will result in a heavier structure, amongst other possible drawbacks. Table 5 shows the associated weight and complexity penalties for all options.

Table 5. Penalties for each design parameter option

At this stage, two different penalties are considered: weight and complexity. Complexity includes difficulties in design, manufacturing, and maintenance. The penalties are assigned on a range from 0 to 10, with 10 being the most heavy/complex option. The lightest or simplest option of each design parameter always has a zero value for that penalty; for example, a short span wing has a zero weight penalty since it is the lightest of the three options (Short, Medium, Long). When all the configurations have been generated, their total weight and complexity penalties can be calculated; this is done by summing up the penalties of the options that form the configuration. Using this approach provides a fast way to introduce an additional metric with which the configurations can be further assessed.