A Distributed Multi-Disciplinary Optimisation of a Blended Wing Body UAV using a Multi-Agent Task Environment.

Transcription

1 A Distributed Multi-Disciplinary Optimisation of a Blended Wing Body UAV using a Multi-Agent Task Environment. J.P.T.J. BerendsF*, M.J.L. van ToorenF and D.N.V. BeloF Delft University of Technology, Faculty of Aerospace Engineering, Kluyverweg 1, 2629 HS Delft, The Netherlands, The Multi-Disciplinary Design and Optimisation process of products can be supported by automation of analysis and optimisation steps. A Design and Engineering Engine (DEE) is a useful concept to structure this automation. Within the DEE, a product is parametrically defined using a Knowledge Based Engineering approach. The analysis of a particular instantiation of the parametric model is performed by discipline analysis tools. By defining design variables and fixing parameters, an optimisation on these design variables can be performed against an objective function. The focus of the benchmark in this article is on developing a multi-objective distributed optimisation capability for the DEE using an optimisation problem of a blended wing body (BWB) unmanned aerial vehicle (UAV) aircraft, as a study object. The multi-objective nature of the optimisation asks for a high number of evaluations of the objective and (in)equality constraint functions. The term distributed indicate that the calculation of these objective and constraint functions of the optimisation does not necessarily takes place within a single computer and a single optimisation program, instead these calculations are physically distributed over multiple processes and computers. A prototype capable of supporting such distributed MDO analysis, using the concept of a DEE, is the "TeamMate" Multi-Agent Task Environment. Using the unique data-pull features of the TeamMate agent system, the user denominated as Operator can select which analysis of the product model should take place and which not by selecting the various constraints and objective functions to be included in the optimisation. If the Operator includes a certain constraint function, all data needed to evaluate the constraint will be automatically generated. The Operator can, in this case, 'shape' the analysis process by deliberately selecting (or de-selecting) certain analysis to be carried out. Results from two separate optimisation cases are reported and discussed. Nomenclature α = angle of attack [º] δ = flap deflection angle [º] c, c eq = in-equality, equality constraint functions C D = drag coefficient [-] C Dα = drag coefficient due to angle of attack change [-] C Dδ = drag coefficient due to flap deflection [-] C L = lift coefficient [-] C Lα = lift coefficient due to angle of attack change [-] C Lδ = lift coefficient due to flap deflection [-] C L0 = lift coefficient at zero angle of attack, measured at main root chord [-] C m = moment coefficient [-] C mα = moment coefficient due to angle of attack change [-] C mδ = moment coefficient due to flap deflection [-] * Ph.D. Thesis Student, Faculty of Aerospace Engineering, J.P.T.J.Berends@tudelft.nl, AIAA Member Professor, Faculty of Aerospace Engineering, M.J.L.vanTooren@tudelft.nl, AIAA MDO TC Member M.Sc. Thesis Student, Faculty of Aerospace Engineering 1 of 22

2 C m0 = moment coefficient at zero angle of attack, measured at main root chord [-] C / δ = mac variation of moment coefficient at aerodynamic centre due to flap deflection [-] E = endurance [h] f = generic function h = non dimensional centre of gravity position [-] h n = non dimensional neutral point position [-] R = range [km] V = cruise speed [m/s] w j = weighting factor [-] W = weight or mass [kg] Wto = take off weight [kg] Wfuel = fuel weight x, x = design vector I. Introduction ESIGNING AIRCRAFT is an intrinsically complicated process and engineers need a technology that will D enable them to virtually access their ideas, model the multidisciplinary aspect of a product, manipulate geometry and the related knowledge, and investigate multiple what-ifs about their design. To achieve this in a reasonable time and with confidence in the reliability of the results, the concept of a Design and Engineering Engine 1,2,3,4 (DEE) is proposed to motor the multi-disciplinary design and optimisation (MDO) of aircraft design. In the heart of the DEE a parameterised aircraft product model is implemented in a multi-model generator (MMG). This modelling tool, using Knowledge Based Engineering (KBE) methods, is able to generate many different aircraft configurations and variants, using combinations of specifically developed classes of objects, called High Level Primitives (HLP) 3. The HLPs provide designers with a powerful medium to capture and re-use not only the geometric aspect of design, but also rules for automatic creation of analysis models for various disciplines. The focus of this article is on developing a multi-objective distributed optimisation capability for the DEE (Fig.1.) using as a study object a known multi-disciplinary optimisation problem of a BWB, based on work by Carpentieri 5, and adapt it for application to UAVs. The multi-objective nature of the optimisation asks for a high number of evaluations of the objective and (in)equality constraint functions. The term distributed indicates that the calculation of the objective and constraint functions of the optimisation does not necessarily takes place within a single computer and a single optimisation program. A prototype framework capable of supporting such distributed MDO analysis, using the concept of a DEE, is the TeamMate Multi-Agent Task Environment. This framework is under development and a prototype has been implemented in a pilot DEE project. The pilot DEE performs a what-if study of a tail-plane design being subject to dynamic loads 2. The project is set up in close collaboration with aerospace industry. The next step for this true multi-disciplinary problem is to optimise the tail design in a closed loop using the developed distributed optimisation capability described in this paper. In order to perform such integrated and multi-disciplinary analysis and optimisation, the framework needs to be capable of handling an optimisation by which the evaluation of objective and constraint functions are not performed locally within the optimisation program, but distributed throughout the framework. In this case, the evaluation of the several constraint and objective functions can be performed by numerous analysis tools; running on systems inside the local area network (LAN), off-site networks or even on different computer architectures. To perform such optimisation a new discipline tool should be developed which contains an optimisation algorithm and has as tasks to control the evaluation of the objective and constraint functions by generating new sets of values of the design variables, and maintain knowledge on the convergence of the optimisation. 2 of 22

3 Figure 1, The generic DEE paradigm 3, using the KBE-based Multi-Model Generator, in order to perform MDO analysis. The distributed optimisation capability that is developed is located in the converger and evaluator block. Several optimisation algorithms are under investigation to be implemented in the framework. For the contents of this article the Sequential Quadratic Optimisation (SQP) algorithm is used. II. Blended Wing Body as a subject for Distributed Optimisation The Blended Wing Body (BWB) is a concept that receives considerable renewed attention from the aircraft industry in the last decade. It is believed that the BWB is a major step forward in civil air transport being one of the most promising concepts. The BWB has been derived from the flying wing and can be thought of as a conceptual ideal configuration. It avoids extra parasite and interference drags as all functions that are not there to generate lift is hosted inside the wing itself. The BWB concept is not only innovative because of its shape, but also because of its strong integration between its parts. The approach used to design a so called conventional Kansas City type aircraft 6 is an evolutionary one, based on (statistical) data collected during many years of experience. This approach worked well for many years, without applying any kind of MDO methods and results are still apparent today. The integrated nature of the BWB does not allow the use of the same evolutionary methods. Parts cannot be studied, as they were to work alone, because interference is not of secondary importance. Statistical data is not available and so an evolutionary approach cannot be considered. Thus developing the BWB concept represents a big challenge in terms of design and the need of a different methodology, based on first principles, is apparent. Another reason to select the BWB concept as test case and study object, for the research of distributed optimisation within the multi-agent task environment is the experience gained with this aircraft in the pan-european MOB project 7 on Multi-Disciplinary Optimisation of Blended Wing Body aircraft. This experience is combined with the work on the optimisation of a BWB carried out by Carpentieri 5. All in all the BWB is an ideal test subject to apply MDO methods. III. The Multi-Agent Task Environment Earlier generation design support frameworks address the automation of MDO problems often as a top-down execution of a string of individual discipline analysis tools. These strings are executed one-way and can be branched 3 of 22

4 and merged when computer resources and data dependencies demand this. These support frameworks are often implicitly created and need heavy adapting when a new MDO problem is addressed making these frameworks very inflexible. Moreover when errors in a particular discipline analysis tool emerge, the highly coupled nature of an execution string often leave no other possibility than to re-execute all or parts of the tool chain, even when this is not always necessary. In theory, only those tools that are dependent on output data from the discipline tools that produced an error needs to be executed. Re-executing the whole string is waste resources in the form of CPU time. Figure 2, Three Levels of aggregation (disciplinary tools, helper agents, DEEs) and four human actors (Specialist, Integrator, Operator, Maintainer) within the Multi-Agent Task Environment can be identified. To overcome these identified obstacles a multi-agent task environment is developed that addresses the aforementioned problems in a structured and consistent way: decoupling the knowledge of the product from the process and that is able to handle a family of design problems (objective 1). Moreover, the framework should prevent waste of resources when partial re-execution of tools is needed (objective 2) and should avoid channelling all data through a single bottleneck (objective 3). Moreover, instead of depicting up-front to each tool its address and freezing this in the chain definition, the problem is communicated to the framework and each agent and tool combination is using its communication skills and knowledge of the problem to request information through a specified, but not tool and address specific, request (objective 4). Entities in the virtual team of agents and tools become Knowledge Workers 8 : respecting their own responsibility for data handling and acquisition within and between disciplines. Finally, when working in a multidisciplinary problem domain a language should be used to facilitate the clear communication, avoiding domain specific language. Domain specific language is acceptable for internal communication, but engineering language is mandated whenever inter-disciplinary communication is concerned. Process algebra language like Chi 9,10 (χ) is preferred when high level language formalisation is concerned 11 (objective 5). The multi-agent task environment (Fig.2) addresses these five primary objectives by including theories from the field of artificial intelligence, social group theories and management. A multi-agentf system is using software agents An intelligent agent is one that is capable of flexible autonomous action in order to meet its design objective, where flexibility mean a) reactivity to ones environment, b) pro-active in fulfilling its goal (goal-directed behaviour) and c) social ability to communicate with other agents or humans of 22

5 wrapping the individual analysis tool and adding extra functionality to make the agent and tool combination a full team player. Four main functions are identified for the framework. A resource management function (1) manages the entry, registration and exit of tools and their capabilities (resources) to the Framework. A resource interfacing function (2) supplies a standard for resource wrapping and inter-resource communication. Moreover it provides ways to communicate between the human actors and the agent and tool combination. The process execution support function (3) controls the execution of the wrapped tools and finally an information flow control function (4) supplies the DEE framework with a controlled data space. Within the framework and DEE, four classes of actors (Fig. 2) are working together in a Design and Built Team (DBT) to solve the given design problem. A DBT is characterised by discipline specialists being responsible for their individual knowledge domains and the whole team being responsible for meeting the team objectives and deliverables. Using the DEE concept as a baseline for solving MDO problems, the process flow (Fig 3a) followed in a DEE is translated into a framework layout (Fig. 3b) in which each major element of a DEE is translated into a discipline tool, embedded and interconnected by a helper agent (Fig. 3). In this layout, the discipline tool is owner and responsible for the specific specialist domain, governed by a human discipline specialist. Looking at all human specialists it is obvious they form a human DBT, while the combination of tools and agents can be seen as virtual participants in the DBT. (a) (b) Figure 3, (a) DEE process flow for support of MDO. (b) DEE translated into a DBT team layout using a multiagent system to integrate various tools. IV. Distributed Multi Disciplinary Optimisation The most practical way of applying optimisation routines in mathematical languages such as Matlab, Fortan, C or Python is that all evaluations of the objective and constraint functions are executed within a single instantiation of the code. When more complicated analysis tools are used to evaluate such objective and constraint functions, this approach cannot be applied, as these tools are designed to work independent and should be supplied with a discipline specific analysis model. 5 of 22

6 The multi-model generator within a DEE is capable of generating such tailored analysis models, using as input a set of parameters and design variables. A clear distinction is made between design parameters and design variables. Projecting optimisation theory on aircraft design the design variables specify limited differences within a product configuration while parameters relate to variations between configurations. Distributed optimisation signifies that the calculation of the objective and constraint functions does not necessarily take place within a single computer and a single optimisation program. The calculation is in case of the distributed optimisation performed by tools, which are not embedded in the optimisation program but running externally and possibly spread over multiple computers within a network. Figure 4 presents such distributed optimisation. A multi-model generator outside the optimisation routine is fed a set of values for the design variables and design parameters, and different analysis models are created for the different disciplines. Each discipline evaluates these models and the results are generated. The evaluation of the results is performed by submitting them to several constraint and objective functions. The objective functions value the performance of the product designed using the current values of the design variables and the constraints determine the feasibility of the product. The human actor Operator, in charge of the optimisation, can choose which constraints and objectives are to be active and included in the optimisation. The optimisation routine determines whether or not a new set of design variables is issued for evaluation or when the optimised design vector is found. In order to obtain the results from the external objective and constraint functions the multi-agent task environment is used to transport these knowledge elements. Each discipline tool, the Multi-model generator and the several constraints and objective functions are wrapped with an agent. An aggregation function inside the optimisation function collects the outcome of the constraint and objective functions and feeds these into the evaluation to see whether the design vector needs adapting or the design vector reached it optimum value. When a new design vector is issued the path is retraced from the top. The optimisation is performed by Matlab 13 using the Optimisation Toolbox 14. The optimiser is a Sequential Quadratic Programming (SQP) algorithm implemented in the fmincon Matlab function. The objective and the constraint function files are used in a way to signal the launch of the models generation, the aerodynamic and structural analysis and calculation of all separate objective and constraints subfunctions. Once these external functions have performed their calculation, the results are imported into Matlab and fed to the optimiser loop. 6 of 22

7 7 of 22 Description of the BWB UAV optimisation problem The optimisation problem is stated as follows: = = = = k j j j j k j j x w w x f w x f , ) ( ) ( min subject to: ], [ 0 ) ( 0 ) ( b a x x c x c eq = (1) where x is the vector of design variables, f is the objective function and c are the constraint functions respectively. The BWB UAV design variables are described in Table 1. Figure 4, Optimisation with the use of an external model generator and external discipline analysis tools; producing results used by several Matlab objective and constraint functions. All external elements (see legend) are

8 X 1 Fuselage span [m] X 8 Outer wing base chord length [m] X 2 Fuselage chord length [m] X 9 Outer wing tip chord length [m] X 3 Fuselage Wing LE sweep [º] X 10 Outer wing LE sweep [º] X 4 Inner wing span [m] X 11 Fuselage Twist [º] X 5 Inner wing base chord length [m] X 12 Inner wing twist [º] X 6 Inner wing LE sweep [º] X 13 Outer wing twist [º] X 7 Outer wing span [m] X 14 Airspeed [m/s] Table 1. Description of the design variables of the Blended Wing Body model used in the optimisation. The parametric geometric model, from which each instantiation of the BWB model is generated, receives as input 14 design variables and gives as output several analysis models that can be used directly by the aerodynamic solver, stability, control, performance and mass modules. The design variables are presented in Table 1 and a schematic representation of the model is presented in Fig.5. Figure 5, Geometric description of the design variables of the Blended Wing Body half-model used in the optimisation The performance of the aircraft model, instantiated by a design variable vector is analysed using a set of tools. This set includes tools from several aerospace engineering disciplines. The results from this analysis provide a set of data from which constraints can be calculated. The values of the constraints designate whether or not the UAV aircraft is a feasible design or not. Constraints that can be derived from the analysis results and chosen to be active are presented in Table 2. 8 of 22

9 Constraint name Constraint class c 1 Maximum total span geometric constraint c 2 Trailing edge flap can deflect geometric constraint c 3 Minimum stallspeed performance constraint c 4 Maximum angle of attack performance constraint c 5 Minimum angle of attack performance constraint c 6 Maximum deflection of bodyflap performance constraint c 7 Minimum deflection of bodyflap performance constraint c 8 Maximum static stability margin performance constraint c 9 Minimum static stability margin performance constraint c 10 Minimum fuel volume geometric constraint c 11 Minimum internal volume to fit payload geometric constraint c 12 Fuselage geometry is straight or tapered geometric constraint c 13 Inner wing geometry is straight or tapered geometric constraint c 14 Outer wing geometry is straight or tapered geometric constraint c 15 Maximum Take Off Weight mass constraint c 16 Minimum Endurance performance constraint c 17 Minimum Range performance constraint Table 2, Description of the constraint functions of the UAV Blended Wing Body model used in the optimisation. Layout of the BWB UAV Design Engine The basic layout of the UAV Design Engine contains several elements found in all DEEs (Fig 1.). An optimiser element powers the automation of the evaluation of design variable vectors and eventually evaluates the objective and constraint functions. A multi-model generator prepares several analysis models that are analysed by several analysis tools in the analysis block. Inside the analysis block a converger loop element is present to ensure that the initial guessed coupling variables are converged before the final analysis results are made available for valuation. The final layout is presented in Fig. 6. BWB Multi-Model Generator The Multi-Model Generator assumes an important role in the MDO problem as it provides quick generation of models that will be used by the various discipline tools. It is composed by a mapping, aircraft design tree, aerodynamic and mass model generators (Fig. 7). The mapping function will provide the capability to make a correlation between the design variables used by the optimisation and the aircraft design tree, a structure that can be identified as a set containing the high level primitives from which the aircraft is built. Depending on the variables used, the mapping can be considered direct, if the element exists in the aircraft design tree or a transformation might be needed. Two create a model using the MMG, two modules were implemented, one aerodynamic, the other a mass module, being the first one responsible for the creation of models to be used in Tornado 15 and the latter for the weight estimation, systems positioning, landing gear sizing and engine selection. These two modules will provide the essential basis for the creation of various aircraft model configurations. In the aerodynamic module, the structure to be accepted by Tornado is prepared namely its geometric shape and flight state, while on the Mass Module historical and information available in literature for conceptual design 16,17 was used. The aerodynamic model creation module allows for complex shapes using different wing trunks that will make up the final configuration 9 of 22

10 Figure 6, The analysis framework is resembling the layout of a traditional DEE. Various constraint and objective functions can be chosen to be included in the optimisation. 10 of 22

11 In the latter module were systems positioning and engine selection were needed a basic set of rules was made so that a feasible model could be achieved, allowing for the creation of an UAV Model at conceptual design level. Figure 7, The multi-model generator (MMG) of the BWB UAV optimisation is capable of exporting multiple model based on a single parametric UAV description. Analysis Tools The tools are divided into two main analysis blocks. The first block is a aerodynamic coefficient initiator that initiated the first values of the aerodynamic coefficients, which are used by the second analysis block. This second analysis block is a linear string of tools which consists of four analysis groups: an aerodynamic analysis group, a mass model analysis group, a stability and control analysis group and a performance analysis group (Fig. 6). This latter block of analysis tools is wrapped in a converger, which checks convergence between several consecutive runs of the four analysis groups. At the heart of the aerodynamic analysis group lie two software programs: a vortex lattice method, implemented in the software tool Tornado 15, and the program Xfoil 18. Both are used to provide estimates of the basic aerodynamic coefficients, namely C L, C m, C D, C Lα, C mα, C Dα, C Lδ, C mδ and C Dδ. Xfoil is used in the first analysis block (Fig. 5.) to generate a database with the basic 2D aerodynamic coefficients of the selected airfoil. These coefficients are used to obtain estimates for viscous drag of the entire wing and moment coefficients at zero lift through integration along the span. In these calculations, the 3D wing effects are neglected. The estimation for the drag coefficient and moment coefficient of the 3D wing are in accordance to theoretical values found in Raymer 16 or Roskam 17. The results obtained from Xfoil are combined with those obtained from Tornado to have a full set which determines the aerodynamic characteristic of the aircraft in this design phase. Tornado uses a finite difference scheme to calculate the different stability derivatives, which will be used in the calculation of the various aerodynamic forces and moments. The classical assumption of linear aerodynamic theory proposed by Brian 19 is used: C = C α + C α C δ + C δ... (2) L Lα 2 L 2 L 2 + α δ L δ 2 Equation (2) is simplified by neglecting all higher order terms and nonlinear effects, thus, only using first order terms. Trading accuracy for simplicity, while still providing pertinent information at the conceptual design stage. The mass model analysis group (Fig. 6) provides centre of gravity calculation and landing gear sizing. Mass model estimations are based on historical UAV values 20 and from aircraft design literature like Roskam and Raymer. The sizing of the landing gear is based on theory found in Raymer and modified to fit UAV class of aircraft. The performance analysis group assures that the propulsion system satisfies the necessary performance constraints by a selecting a capable engine from a UAV engine database. These constraints are presented in Table of 22

12 take off and landing distance < 400 m climb rate > 3.4 m/s Table 3 Performance constraints for UAVs. power available > 1.2 times power required at cruise sustained turn at 2 G with an airspeed of 30 m/s The stability and control analysis group is responsible for the calculation of the angle of attack in order to generate sufficient lift and flap deflection necessary to trim the UAV. Moreover it calculates the influence of the change of the center of gravity in the following stability derivatives 19 : C m = C α Lα ( h h ) n (3) Cm ac Cm = + CL δ δ δ ( h h ) n (4) The values for the angle of attack and flap deflection is then calculated by solving the system of equations: C C Lα mα C C Lδ mδ α CL = δ C trim m 0 (5) Case Studies To test the framework, two different optimisation cases are designed. The first optimisation problem is defined to verify the configuration that would minimise the take-off weight while maximising the endurance of the UAV for a fixed mission fuel fraction. It is a representative case to validate the optimisation framework without any intention of providing a feasible final design. The second optimisation case is designed to increase the performance of the aircraft using an optimisation strategy and a multi-objective function. The optimisation strategy is applied by running two optimisation runs, using the results of the first run as input for the consecutive one. The second case starts of with a primary minimisation of mass and to lesser extend a maximisation of range. The results from this optimisation are used as a starting point for a minimisation of angle of attack, flap deflection, weight and maximisation of endurance. This approach is suggested by Carpentieri 5 and resembles the way a human engineer would design an aircraft. An off-optimum starting point was chosen for both test cases. The optimisation for the first case is then defined as: W E TO ref min f ( x) = (6) x W E with reference values from Table 4 and with respect to constraint function c 1 through c 14 (Table 2) and using all design variables (Table 1) except the mission fuel fraction. The initial start design vector and bounds for all the design variables is presented in Table 5. Wto,re E ref 85kg 18h Table 4, Reference value for the first optimisation case. TOref 12 of 22

13 Design Variables Lower Bound Upper Bound Starting Point X 1 Fuselage span [m] X 2 Fuselage chord length [m] X 3 Fuselage Wing LE sweep [º] X 4 Inner wing span [m] X 5 Inner wing base chord length [m] X 6 Inner wing LE sweep [º] X 7 Outer wing span [m] X 8 Outer wing base chord length [m] X 9 Outer wing tip chord length [m] X 10 Outer wing LE sweep [º] X 11 Fuselage Twist [º] X 12 Inner wing twist [º] X 13 Outer wing twist [º] X 14 Speed [m/s] Table 5, Values of the start design variables and bounds for both design cases. Endurance [h] Range [km] Speed [km/h] α trim [º] δ trim [º] W to [kg] W fuel [kg] C L C D Drag [N] C L C m C Lα [rad -1 ] C mα [rad -1 ] C Lδ [rad -1 ] C mδ [rad -1 ] Figure 8, Both optimisation cases start with a initial UAV design as start vector. The figure is taken from the VLM model coming out of the MMG. Using the multi model generator the start vector from Table 5 can be translated into geometry. To visualise this geometry the output to the VLM model is presented in Figure 8. The second test case involves an optimisation strategy, using multi-objective functions and altering the weight factor in separate runs as a normal engineer would do. The intended aircraft should be able to sustain high speed endurance for an UAV of its weight and size. The strategy is to have two consecutive optimisation runs with firstly a maximisation of range and minimisation of take off weight. Secondly a minimisation of angle of attack, flap trim angle and takeoff weight plus maximisation of endurance was effectuated. The objective function for the first series of runs is the following: W R TO ref min f ( x) = (7) x W R TOref 13 of 22

14 All design variables are active and all constraints are active except the takeoff weight (c 15 ), endurance constraint (c 16 ) and angle of attack and flap deflection constraints(c 4 through c 8 ). The reference values in the objective function are presented in Table 6. All design variables are active (Table 1) and the initial design variable vector and bounds that serves as input of the optimisation is the same for the first case (Table 5 and Fig. 8). W TO,ref R ref 85 kg 1200 km Table 6, Reference values for the second optimisation case, first run of the strategy. The objective function for the second run is: α δ W E TO min f ( x) = x α δ W E ref ref TOref ref (8) For this second run, fewer design variables were used. Comparing to the previous run, variables concerning the fuselage (X 1 -X 3 ) and the inner wing root chord (X 5 ) were fixed and the optimisation was run with only 9 variables. All constraints are active, except the constraints dealing with the angle of attack and flap deflection (c 4 through c 8 ), the endurance constraint (c 16 ), takeoff weight constraint (c 3 ). The values for the reference variables in the objective function are presented in Table 7. The initial design vector for the start of the optimisation is the optimised design from the first run. The bounds for the optimisation are the same for the first series of runs (Table 5). α,ref 3.59º δ ref -2.24º W TOref kg E ref 5.89 h Table 7, Reference values for the second optimisation case, second run of the strategy. Design Variables Lower Bound Upper Bound Start Point X 1 Fuselage span [m] X 2 Fuselage chord length [m] X 3 Fuselage Wing LE sweep [º] X 4 Inner wing span [m] X 5 Inner wing base chord length [m] X 6 Inner wing LE sweep [º] X 7 Outer wing span [m] X 8 Outer wing base chord length [m] X 9 Outer wing tip chord length [m] X 10 Outer wing LE sweep [º] X 11 Fuselage twist [º] X 12 Inner wing twist [º] X 13 Outer wing twist [º] X 14 Speed [m/s] Table 8, Bounds and starting values for the second optimisation case, second run of the strategy. The changes with respect to the other starting vectors are printed in bold case. 14 of 22

15 V. Discussion of Results The results of both optimisation cases are obtained using a Windows based PC, having a 2.8 GHz Pentium IV or equivalent processor. The following results are presented for each optimisation run: A final geometric representation, the values of the design variables and objective functions, complemented with figures showing the progress of the objective and constraint functions during the course of the optimisation. A. Results from the first optimisation case Endurance [h] Range [km] Speed [km/h] 72.0 α trim [º] δ trim [º] W to [kg] W fuel [kg] C L C D Drag [N] C L C m C Lα [rad -1 ] C mα [rad -1 ] C Lδ [rad -1 ] C mδ [rad -1 ] Figure 9, Geometric representation of the result of the first optimisation case. Variable Name Starting Point End Point Lower Bound Upper Bound X 1 Fuselage span [m] X 2 Fuselage chord length [m] X 3 Fuselage Wing LE sweep [º] X 4 Inner wing span [m] X 5 Inner wing base chord length [m] X 6 Inner wing LE sweep [º] X 7 Outer wing span [m] X 8 Outer wing base chord length [m] X 9 Outer wing tip chord length [m] X 10 Outer wing LE sweep [º] X 11 Fuselage Twist [º] X 12 Inner wing twist [º] X 13 Outer wing twist [º] X 14 Speed Table 9, Values of the design variables and objective function for the starting point and results of the first optimisation case. 15 of 22

16 (a) Objective value (b) Angle of Attack constraints (c) Flap deflection constraints (d) Stall speed constraint (e) Static margin constraints (f) Geometric constraints Figure 10, Objectives and constraints diagrams of the first optimisation case. 16 of 22

17 B. Results from the second optimisation case, first run Endurance [h] Range [km] Speed [km/h] α trim [º] δ trim [º] W to [kg] W fuel [kg] C L C D Drag [N] C L C m C Lα [rad -1 ] C mα [rad -1 ] C Lδ [rad -1 ] C mδ [rad -1 ] Figure 11, run Geometric representation of the result of the second optimisation case, first Variable Name Starting Point End Point Lower Bound Upper Bound X 1 Fuselage span [m] X 2 Fuselage chord length [m] X 3 Fuselage Wing LE sweep [º] X 4 Inner wing span [m] X 5 Inner wing base chord length [m] X 6 Inner wing LE sweep [º] X 7 Outer wing span [m] X 8 Outer wing base chord length [m] X 9 Outer wing tip chord length [m] X 10 Outer wing LE sweep [º] X 11 Fuselage Twist [º] X 12 Inner wing twist [º] X 13 Outer wing twist [º] X 14 Speed Table 10, Values of the design variables and objective function for the starting point and results of the optimisation. 17 of 22

18 (a) Objective value (b) Stall speed constraints (c) Static margin constraints (d) Geometric constraints Figure 12, Objectives and constraints diagrams of the second optimisation case, first run. 18 of 22

19 C. Results from the second optimisation case, second run Figure 13, run Endurance [h] Range [km] Speed [km/h] α trim [º] δ trim [º] W to [kg] W fuel [kg] C L C D Drag [N] C L C m C Lα [rad -1 ] C mα [rad -1 ] C Lδ [rad -1 ] C mδ [rad -1 ] Geometric representation of the result of the second optimisation case, second Variable Name Starting Point End Point Lower Bound Upper Bound X 1 Fuselage span [m] X 2 Fuselage chord length [m] X 3 Fuselage Wing LE sweep [º] X 4 Inner wing span [m] X 5 Inner wing base chord length [m] X 6 Inner wing LE sweep [º] X 7 Outer wing span [m] X 8 Outer wing base chord length [m] X 9 Outer wing tip chord length [m] X 10 Outer wing LE sweep [º] X 11 Fuselage Twist [º] X 12 Inner wing twist [º] X 13 Outer wing twist [º] X 14 Speed Table 11, Values of the design variables and objective function for the starting point and results of the second optimisation case, second run. Bold faced entries are bounds that are changed in this run with respect to other runs. 19 of 22

20 (a) Objective value (b) Stall speed constraints (c) Static margin constraints Figure 14, Objectives and constraints diagrams of the second optimisation case, second run. Figure 15, Comparison of the second optimization case results. The lighter coloured geometry is results of the first run, the dark coloured one result of the second run 20 of 22

21 VI. Discussion and Recommendations From the first optimisation results (Fig. 10) it is seen, that the optimisation achieved a lower value for the chosen objective function. The chosen gradient based optimisation algorithm SQP proved reliable for usage in this type of problems. It can be observed from the results of both cases, that changes made in one aspect of the design, affects other aspects of the design as expected to happen when doing aircraft design. As example it is seen in Fig. 15, that a higher speed design compared with a maximum range design has an increased aspect ratio wing. Moreover, although the total value of the objective function of the second optimisation case (Fig. 14a) does not change radically, the optimisation has proved successful trying to optimize c.g. position, aerodynamic performance and geometric shape to the new requested objective of maximum endurance. From the second optimisation case it can also be concluded that a clearly defined objective function with correct weighting factors can be used to drive the design quickly to a better design. Inappropriate constraints as well as inappropriate objective functions might still provide a feasible optimisation solution but unrealistic design. Much care must be taken in setting the constraints and altering the boundaries of the optimisation problem. Because each analysis tool has a certain domain of accepted input, for which it produces feasible results, these bounds must be carefully controlled. Else the optimisation results are useless and unfeasible. The agent framework, especially the filtering functions in the agents, are a good tool to monitor these input domain restrictions. This filtering function capability is scheduled to be improved in the next generation agents, and this feature of controlling the input domain bounds should be included. The result of an optimisation is a function of the analytical models used, the initial start point, the optimisation algorithm, the setup of the objective and the constraints function. Therefore, mathematics alone is not going to solve any optimisation problem or create an automated aircraft design tool. Although both optimisations resulted in a mathematically optimised UAV design, the realism of the design concept can be questioned. The analysis models that are used are fairly simple and lack analysis tools for longitudinal stability and structural design at this point. Although the analysis tools are showing expected behaviour, the analysis tools require more in-depth validation. The assumptions made in the initial aerodynamic analysis considering all stability derivatives linear, decoupled and non dependent on flight condition will introduce in the design unwanted characteristics or unfeasible design solutions. Furthermore, the aerodynamic models are still incomplete which provide as an end result a low drag estimation, which in turn will have a positive impact in the desired performance. Due to the inherent characteristics of the Blended Wing Body configuration a highly integrated design must be accomplished which at this time has not been fully achieved, neglecting for instance airfoil design capability and the implementation of a simple structural model, increasing the fidelity of the final results. From the DEE point of view, this implementation achieved expected results, with the necessary flexibility to implement new optimisation algorithms, objective functions, constraints and change design variables and parameters. It was also implemented in such a way that the models can be easily improved or complemented with higher order ones. The distributed optimisation, using the network of agents, produces the same results as the local optimisation, performed solely in Matlab. An expected observation is that the distributed optimisation takes considerably more time compared to the optimisation performed inside a single execution of Matlab. An extra overhead time for each function evaluation of around 25 seconds is observed. This amount is 50% of the total calculation time for each objective function evaluation. Ways to decrease this overhead time should be investigated to make the agent framework more attractive for operators and specialists to use. Important to note is that, in any case where multiple disciplines are involved, the ownership of the discipline specific knowledge should remain with the discipline specialists. Specialists have intimate knowledge of the technical limitations of the used analysis tools and can value the analysis results for sanity. Together with the automatic regarding of the agents for the input domains, which need to be configured by the Specialist in the end, they form a good virtual design team for solving future multidisciplinary aircraft design and optimisation problems. 21 of 22

22 References 1 Tooren M.J.L. van, M. Nawijn, J.P.T.J. Berends and E.J. Schut, Aircraft Design Support using Knowledge Engineering and Optimisation Techniques, 46 th AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, Austin, Texas, USA, Cerulli, C, J.P.T.J. Berends, M.J.L. van Tooren and J.W. Hofstee, Parametric Modelling for Structural Dynamics Investigations in Preliminary Design, 2005 CEAS/AIAA/DGLR International Forum on Aeroelasticity and Structural Dynamics, Munich, Germany, La Rocca, G and M.J.L. van Tooren, Development of Knowledge Based Engineering Techniques to Support Aircraft Design and Multidisciplinary Analysys AIAA Journal of Aircraft (under review) 4 La Rocca, G and M.J.L. van Tooren, Development of Design and Engineering Engines to Support Multidisciplinary Design and Analysis of Aircraft, Design Research in The Netherlands 2005, Eindhoven, The Netherlands, Carpentieri, G, M. van Tooren, G. Bernardini and L. Morino, Sequential Multi-Disciplinary Optimisation for the Conceptual Design of a Blended-Wing-Body Aircraft, ICCES 04, Madeira, Portugal, Green, J.E., Civil Aviation and the environment challenge, The Aeronautical Journal, 107(1072), June Morris, A.J. MOB, A European Distributed Multi-disciplinary Design and Optimisation Project, Proceedings of the 9th AIAA/ISSMO Symposium on MDO, Atlanta, Georgia, USA, Drucker, P.F., Management Challenges for the 21st Century, Butterworth-Heinemann, Oxford, 1999, Chap 1- III. 9 Hofkamp, A.T. and J.E. Rooda, χ (Chi) Language Reference Manual, Eindhoven University of Technology, 2002, URL: [cited 4 Jan 2006] 10 Baeten, J.C.M., D.A. van Beeka and J.E. Rooda, Process Algebra, Handbook on Dynamic System Modeling; edited by: Paul Fishwick, CRC Press LLC, 2006 (to be published) 11 J.P.T.J. Berends and M.J.L van Tooren, An Agent System Co-operating as a Design Built Team in a Multi-disciplinary Design Environment, 44 th AIAA Aerospace Sciences Meeting and Exhibit, Reno, Nevada, USA, Weiss, Gerhard, Multiagent systems, a modern approach to Distributed Artificial Intelligence, MIT press, Cambridge, Massachusetts, USA, Matlab, Software Package, Version Release 14, The Mathworks, Nathic, MA, USA, Matlab Optimisation Toolbox, Software Package, Version Release 14, The Mathworks, Nathic, MA, USA, HMelin, T, Tornado VLM, Software Package, Version 128 Beta, KTH, Department of Aeronautical and Vehicle Engineering, URL: Hhttp:// [cited 3 April 2006] 16 Raymer, Daniel P., Aircraft Design, AIAA, Reston, USA, Roskam J, Airplane design. Pt.I-VI, DAR Corporation, Lawrence, Kansas, USA, Drela M., Xfoil, URL: 19 Etkins B., Dynamics of flight, stability and control, John Wiley, New York, USA, Unmanned Vehicles, Handbook 2005, Shephard Group, United Kingdom, of 22