Tail Optimization and Redesign in a Multi Agent Task Environment (TailORMATE) C. Cerulli*, E.J. Schut† , J.P.T.J. Berends‡ and M.J.L. van Tooren § Delft University of Technology, Faculty of Aerospace Engineering, Kluyverweg 1, 2629 HS Delft, The Netherlands, www.dar.lr.tudelft.nl
Performing what-if studies in preliminary design involves some specific demands. Usually, when it comes to loads calculation, an aeroelastic model of a certain level of fidelity is required, while when it comes to sizing, a structural model is needed. Such models, in a parametric way, are usually not available, or cannot be built up in a sufficiently short period of time. The use of Knowledge Based Engineering as solution is discussed. It will be shown that a proper combination of object oriented programming, rule based instantiation of objects and a geometry engine enhance parametric modelling in the preliminary design phase. The principle of High Level Primitives (HLPs) in a so-called Multi Model Generator (MMG) is considered as a proper approach to the problem of parametric modelling of a family of aircraft. The overall process of redesigning the vertical tail of a passenger aircraft is described in this work. Moreover, parametric studies on the outer geometry of the tail are also performed. In order to automate the process, a dedicated Design and Engineering Engine (DEE) is developed together with an automated software environment.
I.
Introduction
D
ESIGNING aircraft is an intrinsically complicated process and engineers need a technology that will enable them to skip all the repetitive work in order to better concentrate on developing new ideas. While in the conceptual design phase, new concepts are considered; in the preliminary design phase the focus is mainly on investigating parametric changes on previously defined concepts. To achieve this in a reasonable time, with confidence in the reliability of the results and with a minor effort, the concept of Design and Engineering Engine1,2,3,4 (DEE) is proposed. It was shown that Knowledge Based Engineering (KBE)1, which is a proper combination of object oriented programming, rule based instantiation of objects and a geometry engine, is very helpful for the designer in the preliminary design phase. The KBE application, known as Multi-Model Generator, able to generate a family of product, by combining specifically developed classes of objects, called High Level Primitives (HLPs)1 is the core of the DEE. The MMG provides designers with a powerful means to capture and re-use the geometric aspect of design, but also rules for automatic creation of analysis models for various disciplines. This paper describes the instantiation of a dedicated DEE for performing what-if studies on the vertical tail of a passenger aircraft. In order to do that, different type of analyses have to be performed. First, an advanced tool able to calculate critical loads for the aircraft due to turbulence, manoeuvres, ground impact and/or failures is needed (see Section III.E). Then, an initiator/sizing tool is also required for giving a good estimation of the local stiffness and mass of the tail structure (see Section III.F). These tools have to be fed with consistent parametric models, i.e. aeroelastic for loads and structural for sizing, at a certain level of fidelity. Most commonly, these models are not available in preliminary design when what-if studies are requested. In this case, the parametric models to feed the disciplines tools are provided by a dedicated MMG able to reproduce a complete family of aircrafts (see Section *
PhD student, Faculty of Aerospace Engineering/Faculty of Mechanical Engineering,
[email protected]. PhD student, Faculty of Aerospace Engineering,
[email protected]. ‡ PhD student, Faculty of Aerospace Engineering,
[email protected]. § Professor, Faculty of Aerospace Engineering,
[email protected], MDO TC Member . †
1 American Institute of Aeronautics and Astronautics
III.A). All the tools required for performing the redesign of the vertical tail are coupled in the DEE as in a Design and Build Team (DBT) 4 and made them communicate between each other by using a design supportive framework (see Section III.G).
II.
An overview of the DEE concept
A Design and Engineering Engine (DEE) is defined1 as an advanced design environment, where the design process of complex products is supported and accelerated through the automation of non-creative and repetitive
Figure 1, The Concept of a DEE to support MDO analysis; left the main design process flow; right the Multi-model generator and the analysis tools. design activities. Figure 1 shows the concept of the DEE. The main components of the DEE are: Initiator: Responsible for providing feasible starting values for the instantiation of the (parametric) product model. Multi-Model-Generator (MMG): Responsible for instantiation of the product model and extracting different views on the model in the form of report files to facilitate the discipline specialist tools. Analysis (Expert) tools: Responsible for evaluating one or several aspects of the design in their domain of discipline (e.g. structural response, aerodynamic performance or manufacturability). Converger & Evaluator: Responsible for checking convergence of the design solution and compliance of the product’s properties with the design requirements. These elements use loops in order to function. The definition of the product, i.e. the problem to be solved by the DEE, is based on High Level Primitives (HLPs). These are functional building blocks, which allow the user of the DEE to define a product in a certain product family, which encompasses a structured set of HLPs. These functional blocks are basically sets of rules that use parameters to initiate objects that represent (part of) the product under consideration or to apply an engineering process to the initiated object. The object oriented approach allows the representation of the product and engineering process structure. The KBE environment gives access to a parametric geometric modeller. This allows the rule base to perform all geometric operations normally available in a CAD program. This paper presents a dedicated DEE, denoted TailORMATE (Tail Optimization and Redesign in a Multi Agent Task Environment) developed for supporting loads and aeroelastics investigations in the preliminary design phase, in which parametric studies and the redesign of the vertical tail of a passenger aircraft family is considered. 2 American Institute of Aeronautics and Astronautics
III.
Dedicated DEE for Tail Redesign and Optimization (TailORMATE) – step by step
As a case study, an existing vertical tail of a long range passenger aircraft is replaced by a new vertical tail, of composite material obtained from the overall process. The remaining components are represented by the baseline model. At first, the attempt is to reproduce the original configuration, and then parametric studies on the tail are performed. A DEE representing the specific process has been depicted in Figure 2.
Figure 2, The DEE process for optimisation and redesign of a tail All the steps are performed automatically with the help of a DEE Framework4,5 and they are run on a mixed architecture (Linux and Windows) with an average processor power of Pentium IV 2.5GHz. As validation of the process, a converger checks the differences between each loop and terminates new loops when the change in vertical tail weight is less than a criterion of 1 %. An operator actor is asking the converger for an output and as the converger can only determine a change after 2 full loops processed, this is the minimum amount of loops that the framework is handling. In this section, the process depicted in Figure 2 is described step-by-step in all his features and tools.
A. Multi Model Generator (MMG) The MMG is a KBE application currently implemented in the ICAD system, capable to generate different views (models) on a family of products. The specific MMG used in this application is called ACPAM (Airbus Conventional Passenger Aircraft Model)6 and has the capability of modelling a complete family of conventional passenger aircrafts (see Figure 3). The parameters used inside the code to generate the aircraft model are combined in engineering rules that are specific for the mentioned aircraft families. The numerical values needed to build up a specific aircraft model are univocally assigned in an input file. The input data can either be interactively defined by the user or automatically modified as part of an optimizer inside the DEE. For building up the ACPAM, an objectoriented approach has been used. As mentioned in the previous section, specific High-Level Primitives (HLPs) are defined and are used to build up the complete aircraft. The HLPs used in this specific case are the wing trunk, the fuselage Figure 3, Family of aircrafts. trunk, the engine module, the connection elements and the end cap module. Each HLP includes 3 American Institute of Aeronautics and Astronautics
geometrical information about the outer surface and the inner structure of the primitive, plus additional information used later to build up the finite elements model. Since the focus of this test case is on the vertical tail, a special MMG module performs the scanning of the product tree, collects all the segmented surface patches belonging to the specific component and translate them into IGES files (Initial Graphics Exchange Standard), ready to be imported in the FE environment. Moreover, by virtue of the specific ACPAM “capability modules”, additional information can be also exported; i.e. information about the finite elements properties and about the condensation points. The first capability is achieved with the so-called FEM-tables, i.e., look-up tables in text format including a first estimation of the thickness, the material, the membership identification to a design variable area, the list of the non-structural mass items to be attached at that surface, and other relevant properties such as ‘ISO-meshability’, number of edges, Cartesian coordinates of the corner nodes, etc. One FEM-table is generated for each IGES file. Moreover, to perform condensation in a later stage, definition and evaluation of the position of a set of condensation points has to be done. In case of lifting surfaces, the condensation points are defined as the intersection between the condensation line and the ribs. The condensation line is defined in the ACPAM input file by the position of its starting and ending point expressed in percentage of the root and the tip chord in each wing trunk. Since the condensation points may move depending on the design change, the definition of the condensation points is carried out by implementing the mentioned engineering rules directly inside ACPAM.
B. From the MMG to Patran The geometric model of the vertical tail (external surfaces and internal structure) is exported from ACPAM to the structural analysis tool in IGES format. The IGES format has been chosen because it is designed to be independent of all CAD systems and it is readable by the most frequently used analysis tools. In this work, the authors decided to use the Patran/Nastran environment as structural analysis tool. As mentioned before, in order to reduce the time dedicated to the meshing process, the segmentation is already performed inside ACPAM. Thus, each IGES file already contains a set of meshable patches. To each surface patch, an identification tag is applied. In order to fully describe the finite element model, non-geometrical information, i.e. material and elements properties, are transmitted to Patran via FEM-table mentioned in the previous section. A proper routine has been developed to map the contents of the FEM-tables directly into the Patran database. The co-ordinates of the nodes of each surface patch are the bi-univocal link between each surface coded in the IGES file and its representation in the Patran environment. Since a reduced structural model is needed as result, additional geometrical entities are transmitted from ACPAM to Patran, i.e., the condensation points. The condensation points are exported to Patran via IGES files and FEM tables, as every other part of the structure. Since they do not belong to the meshed surfaces, a special module has been developed in Patran Command Language (PCL) in order to automatically create rigid elements (RBE3) 7 to connect the condensation points to the corner points of the ribs they lie on. Additional condensation points are added to the previously mentioned ones, i.e. a set of points at the root of the vertical tail needed in a later stage to re-attach the new fin to the baseline fuselage. An additional module in the PCL code has been created to translate the IDs of all the condensation points into the Nastran format identifying a special set of degrees of freedom (SET1) 7 where to perform model reduction. A Patran session file has been programmed in PCL in order to perform automatically all the actions described in this section. The Patran session file produces as output a Nastran analysis deck for performing normal modes analysis and obtaining the reduced structural model.
C. Reduced Structural and Mass Model Stiffness reduction is performed automatically inside Nastran Normal Modes Solution (SOL 103)7. This kind of static reduction is the well-known Guyan reduction8. The standard matrix equation to be reduced is:
Ku = P
Where: u vector of the displacement of the complete set of grid points in the FEM; K stiffness matrix; P vector of the applied loads. 4 American Institute of Aeronautics and Astronautics
The previous system can be partitioned as follows:
K aa K oa
K ao u a Pa = K oo u o Po
Where: ua vector of the displacement of the analysis (a) set, to be retained; uo vector of the displacement of the omitted (o) set, to be eliminated; K stiffness matrices. By assuming that the loads applied on the o-set are very small, it is possible to find a correlation between the aset displacement and o-set displacement, as follows:
I u a = u a = Ta u a −1 u o − K oo K oa The resulting reduced stiffness matrix is then
K R = TaT K aa Ta Which represents the reduced structural model. The reduced stiffness matrix is used in a later stage for representing the structure of the vertical tail and to connect it with the structural model of the rest of the aircraft. In order to evaluate the structural masses, the mass matrix of the vertical tail is considered. During the previously mentioned Nastran calculation, the mass matrix (MGG)7 associated with the complete set of DOF (G-set)7 is calculated. Additional non-structural masses can be defined as lumped masses directly inside ACPAM and are then exported via FEM tables. In this case, they will be automatically included in MGG. The values of the masses on the diagonal of the matrix are then modelled as lumped masses connected to the grid points belonging to the g-set. The result is a cloud of lumped masses in each node of the structural mesh. Using an in-house tool developed in Matlab, each mass is geometrically condensed in the closest condensation point. It has to be mentioned that in this case we consider as condensation points only the points lying on the condensation axis. The connection points between the vertical tail and the fuselage are excluded since lumped masses in these points are not desirable. Output of this procedure is a Nastran input file, including the CONM2 cards representing the new lumped masses attached at the condensation points. The described mass model, together with the reduced structural model previously described, are coupled in order to create the elastic&inertia model of the vertical tail. Afterwards, the reduced structural and mass models of the vertical tail are assembled with the reduced model of the rest of the aircraft, and another Nastran modal analysis is performed in order to obtain the modes of the complete structure. D. Aerodynamic Model Depending on the type of loads calculation the user intends to perform, model for steady vortex lattice or unsteady doublet lattice can be exported from ACPAM. In principle, also the 3D geometrical information required for CFD calculations can be exported from ACPAM, but this option is presently not used for the loads analysis of the present test case, where computing time is predominant. In the test cases presented in this work and in previous papers9, the aerodynamic loads on the vertical tail are calculated using the Vortex Lattice Method (VLM). In the VLM the velocity potential equations are solved and the Aerodynamic Influence Coefficient (AIC) matrix is calculated. The VLM used for the test case calculation requires as input 2D flat panels representing the plan form of the vertical tail. Since the plan form may change with every design change, the flats panels are provided directly by ACPAM in the format of Nastran CAERO cards.
E. Loads Calculation VarLoads2,10 is a flexible loads analysis tool intended for special investigations, with applications ranging from preliminary design to investigation of in-service incidents. To this effect, major characteristics of the tool are: capability to handle aircraft models from variable sources and with variable level of refinement; an integrated 5 American Institute of Aeronautics and Astronautics
aircraft model and unified simulation environment for manoeuvre and dynamic response, extendable to flight dynamic and aeroelastic analyses. Since VarLoads is a library based software, a high modularity is given. The above characteristics allow for easy linking with the action boxes into the TailorMate DEE. Specifically, the aeroelastic model is built up from the MMG only once, and can afterwards be used for all steady manoeuvre and dynamic response calculations. VarLoads realizes the classical aeroservoelastic simulation loop in a Matlab/Simulink environment (see Fig. X). The aeroelastic properties are collected in the aircraft block. Starting from a trimmed initial condition, typically the aircraft is either excited by a change in its environment (e.g., an atmospheric disturbance defined in FAR25), or by some given input (e.g., a checked manoeuvre defined in FAR25). In the test case presented in this paper, a dynamic yawing manoeuvre is performed. Sensor, controls and pilot sub-systems are needed to close the loop. The postprocessing sub-system computes the desired dynamic loads, e.g. shear, bending and torsion at pre-defined monitoring stations.
Figure 4, Loads analysis tool, VarLoads
F. The Tail sizing tool The vertical tail is seen as a set of boxes, obtained by slicing the structure, as shown in Figure 5. The slices are made using the rib positions as cutting planes. The boxes are bounded by the most front and most rear spars, two ribs and naturally covered by the skin panels. Each box itself is built up from three types of components; skin panels, ribs and spar panels. Each of these three components is assumed to consist of a blade stiffened panel, i.e. the Low Level Primitive to be sized using optimization techniques. Each panel is assumed to be rectangular and flat, creating a two dimensional problem that encompasses the most prominent material and structural failure modes.
6 American Institute of Aeronautics and Astronautics
Figure 5, Structural breakdown of a lifting surface’s load carrying structure into slices to accommodate the optimisation process
The composite elementary blade stiffened panel used for this example was described by Van Tooren3. The failure criteria taken into account are strength and stability. No stiffness constraint is taken into account. The generic panel concept is illustrated Fig.6. The blade-stiffened panel concept is based on two elements, skins and stiffener. The feasilisation of the panels is the first step to feasilisation of the tail structure.
Figure 6, Generic panel concept VarLoads uses a structural model build up from beams and condensed masses to analyze the aircraft loads taking into account the flexibility of the structure. The loads on the masses are used as an input for the sizing of the vertical tail. These loads have to be translated into internal loads at the required locations. The loads are integrated along the condensation line; the resulting loads are then transposed to the internal load point in the local axes system. The internal loads are translated to load intensities, using some basic assumptions on the load paths in the structure, Fig. 7. The torsion moment My is introduced to both spar and skin. The force Fy is introduced in the skin and spars, combined with the moment Mx it determines the level of tension and compression in the upper and lower skins, and combined with the moment Mz it determines the level of tension and compression in the spars. Fx together with My determine the level of shear in the skins, and Fz together with My determine the level of shear in the spars. The rib is subjected to a crushing load due to wing deformation and to shear due to My.
7 American Institute of Aeronautics and Astronautics
Figure 7, Internal loads on the box and crushing load on a rib
Except for the crushing load, all the load intensities are calculated before the actual sizing. The crushing load, Fig. 7, is determined during sizing with a formula from Rothwell12. In Table 1, the optimization variables, parameters and bounds are shown. The design parameters are fixed during the sizing process and formalize design decisions (e.g. material choice, panel dimension). The design variables define the design space and they directly related to the decisions normally made by the human designer in the sizing process. The design variable vector used for feasilisation is a set of the design variables and is predetermined by the human designer. Table 1. Optimization variables, parameters, and bounds Design variables
Design parameters
Bounds
b h n0 n45 n90 ns0 ns45 ns90 L W material p.pxt p.pxc p.pyt p.pyc p.pxy lb ub
Stiffener spacing Stiffener height Number of plies in the 0° layer of the skin Number of plies in the ±45° layer of the skin Number of plies in the 90° layer of the skin Number of plies in the 0° layer of the stiffener Number of plies in the ±45° layer of the stiffener Number of plies in the 90° layer of the stiffener Panel length Panel width Toray T700 CF Tension load intensity in fibre direction Compression load intensity in fibre direction Tension load intensity perpendicular to the fibre direction Compression load intensity perpendicular to the fibre direction Shear load intensity Lower bound: [50 10 1 1 1 1 1 1 200] Upper bound: [100 60 80 80 80 80 80 80 900]
The designer normally uses schematic models, e.g. from handbooks, to verify his design choices. In case of the composite blade stiffened panels the choices to be made are expressed by the design variables. Verification is against failure modes, both strength and stability. In our case three buckling modes are important with a half wavelength of stiffener height, stiffener spacing to rib spacing (see Figure 8). According to Rothwell12, in shear only the skin will buckle, so no shear buckling constraints are defined for the stiffener.
8 American Institute of Aeronautics and Astronautics
Figure 8, Buckling modes of a blade-stiffened panel in compression, respectively skin, stiffener, and panel buckling, and panel buckling in shear G. DEE Framework In the previous sections, it was explained from which tools the TailorMate DEE for loads calculation is composed. To build such a DEE, these tools have to be connected to each other and communication between the tools has to be enabled. This section explains in general terms how this can be achieved in practice using a newly developed agent based software framework. The first generation of DEE Frameworks (DEEF) focused on top-down execution of a string of tools. This can be seen as a data-push scenario in which output data of a process is pushed into a consecutive process. The main problems with this type of top-down execution are flexibility and re-execution when faults in a sub process emerge. As learnt from European Multi-Disciplinary Optimisation of Blended Wing Bodies (MOB) project13,14, re-execution of parts of the tool chain, after the error solving, can be time-consuming and should not be necessary as tools in the preceding part of the execution string already produced acceptable results. In order to solve these problems, a data-pull framework scenario is proposed. The implementation of the framework is done by including in the process autonomous helper programs, called agents. These agents communicate with each other in order to exchange data to their wrapped discipline tools. At least three levels of aggregation within the framework can be identified: disciplinary tools, helper agents and Design and Engineering Engines4. For each aggregation level, an actor can be identified. A Specialist is responsible for the development and enhancement of the discipline tool. He has in depth knowledge of his or her field of expertise. An Integrator is responsible for development of the agent framework. The role of this actor is to integrate and communicate with Specialists and come to interface agreements. Specialists are treated as users of the framework without in-depth knowledge of the implementation. Then there is an Operator who is responsible for solving technical problems by operation of the DEE. This actor is using the discipline tools arranged in a DEE as a user. Finally a Maintainer is responsible for operation of the DEEF. This role is facility oriented. This actor is responsible for correct operation of the specialist tools, network hardware and operating systems on which the DEEF is implemented. The philosophy to address the objectives is inspired on Design and Build Teams (DBTs). Such teams are characterised by discipline specialists being responsible for their individual knowledge domains and the whole team being responsible for meeting the (management) team objectives and deliverables. Using the DEE as a baseline for solving MDO problems, the process flow followed in a DEE is translated into a framework layout in which each major element of a DEE is translated into a discipline tool, embedded in and interconnected by a helper agent (Fig. 9.). In this layout, the discipline tool is owner of and responsible for the specific specialist domain, governed by a human discipline specialist.
9 American Institute of Aeronautics and Astronautics
(b
(a
Figure 9, (a) DEE process flow for support of MDO. (b) DEE translated into a DBT team layout using a multi-agent system to integrate various tools. In order for the framework to operate in a MDO environment where different tools are combined, it is important that the converger and evaluation functions can be fulfilled. The characteristics of a converger and evaluator are that both functions rely on a loop in order to work. For example, a converger determines if the residue between results of two consecutive runs is lower than a certain criterion before it determines if a solution is converged. Figure 10 describes the basic process that a loop follows using the agent framework. Three parallel process streams are shown, the left being the main level stream. In here a tool is present, like a converger, which uses a loop in order to function properly. The components of the chain (agents) that exist inside the loop are on a sub level process stream. Request to this sub-level process stream contain an extra element determining the loop number in order to distinguish between the data patterns (which are the same for all elements) between each loop. When a tool in a sublevel requires data from an agent in a higher level process stream, this loop number is omitted from the request, and the request is broadcasted to the network. Due to the nature of the request system, this data pattern is automatically picked up by the agent in the higher level loop and served to the agent requested. The main change to the normal agent and tool operation is that the tool wrapped by an agent contains the loop logic. If a converger is taken as an example, the converger code needs to communicate with the agent in order to command the agent to get results from a lower level loop for which a convergence needs to be checked. Moreover, the agent needs to signal the tool that results from a loop is available in its input zone for the tool to check convergence on. For this reason a bi-directional communication system is needed between the tool and the agent. Interaction between the actors and the agent is primarily performed using a web interface. The web interface (Fig. 11) as it has been developed at present is an example of how communication with a certain focus group or actor can be performed, rather than trying to communication in once own language. In Fig. 11 the status page of one agent is presented, on which the status of all independent agents are collocated. The web interface is used for two-way communication. The agent present pattern data sets, status and error information, and the actor is able to command the agent.
10 American Institute of Aeronautics and Astronautics
There is no single central server entity in the agent framework. There is, however, one appointed master agent that distributes framework-level information to the connected agents. It also checks consistently if all agents are still connected and ready to receive messages. When an agent disconnects, it is observed by the master entity after a while, removed from the contact lists and announced to the still available agents. When the master agent itself fails, this is after a certain amount of time noticed by other agents and, based on seniority (age) in the framework, the master functions are taken over. This watch-dog and self-healing principles is only applied to the inter-agent communication. The design activities on top of the agent framework can be impeded by disappearance of agents resulting in a halted process flow. Human interaction is then necessary to jump-start the process.
Figure 10, Design loops on multiple levels can be handled using the flexible request system.
IV.
Results
As case study, the vertical tail of an existing long range passenger aircraft is replaced by a vertical tail obtained from the process described in the previous sections. The remaining components of the aircraft are represented by a validated baseline model. At first, the attempt is to reproduce the original configuration. The input file for ACPAM is prepared according to the baseline aircraft measures. From the MMG, only the report files for the vertical tail are requested and exported into the Patran/Nastran environment. Afterwards, the reduced structural and mass models of the fin are assembled with the reduced model of the rest of the aircraft. Loads due to a yawing manoeuvre which is critical for vertical tail sizing, are calculated. The loads are then delivered to the sizing tool, which estimates the thickness of the fin box shell elements. All the steps are performed automatically with Figure 11, Each agent is equipped with its own web server the help of the DEE Framework, previously to provide actors a method of interaction. 11 American Institute of Aeronautics and Astronautics
described (see Section III.G). The tools are run on a mixed architecture (Linux and Windows) with a processor power of Pentium IV 2.5GHz, or equivalent. In Table 2, the calculation time for each process is depicted and the total calculation time per configuration is calculated. It has to be mentioned that multiple configurations can run in parallel, i.e. the calculation time for a certain number of configurations will be slightly higher than the total calculation time per configuration due to heavy load on the processor.
Baseline Span+5% Span+10% Span-10% Span–5% Figure 12, Baseline configuration and new configurations with change in the span - side view
As a validation of the flexibility of the overall process, parametric studies on the geometry of the vertical tail are performed. In addition to the baseline version, four configurations with ±5% and ±10% span value and other four configurations with ±5% and ±10% sweep angle are evaluated (see Figures 12 and 13). The complete process can be carried out automatically. One process loop requires less then 45 minutes. The first loop requires an extra 2 minutes for the instantiation of the initial aircraft model by the MMG. For details about the time needed for each process, the reader can refer to Table 2. After this loop is completed each new loop does not need to have the MMG geometric models created, as they are already available in the output buffer of the MMG. A converger checks the differences between each loop and terminates new loops when de change in fin weight is less than a criterion of 1%. To reach the criterion, around 5–7 loops are run before the converger finds convergence and terminates the loop. In Fig. 14, the values of the weight per area of each panel belonging to spar and ribs (a) and skin (b) are shown.
Table 2. Overall average Calculation Times; averaged and based on mixed computers with average speed of an Intel Pentium IV 2.5 GHz processor or comparable PROCESS ACPAM – Multi Model Generator Patran - Mesher Nastran – Stiffness Condensation Matlab – Mass Condensation Nastran – Assembly VarLoads Sizing tool Framework - Overhead *
In Loop * No Yes Yes Yes Yes Yes Yes N.A.
CALCULATION TIME per configuration 120sec 180 sec 30 sec 180 sec 60 sec 420 sec 1620 sec 240 sec TOTAL TIME 2850 sec first Loop, 2730 sec consecutive Loops
ACPAM is only executed the first run of the DEE and not included in the loop
Verification of the robust communication framework was very successful. A hybrid, multi-platform (inter)network was used for these tests. Several weeks of load testing have no impact on the integrity of the P2P communication network. It was also shown that network disconnects and (dis-)appearances of agents where not damaging the to integrity of the framework.
12 American Institute of Aeronautics and Astronautics
Figure 13, Base line configuration and new configurations with change in the sweep angle
V.
Conclusions and recommendations
It is shown that the implementation of a dedicated DEE helps and speeds-up designers’ job, when it comes to parametric studies on aircraft components. The use of a parametric Multi-Model Generator (MMG) and flexible analysis tools (i.e. loads and sizing) representing specialists work, glued together with an agent-based framework, makes what-if studies possible in a limited amount of time. The test case presented in this paper regards the re-design and optimization of the vertical tail of a passenger aircraft. At first, the attempt to reproduce the baseline configuration is made. Then, it is shown that parametric changes to the external geometry of the tail (e.g. span length and sweep angle value) can be performed. The overall process (e.g. disciplines tools, framework) is able to handle the evaluation of all these configurations. The overall process is now in the validation phase. The new framework includes the possibility of having a converger checking for the end point of the design. The framework is able to automatically handle the analysis of various configurations. Moreover, the possibility of implementing loops (e.g. optimization loops, convergence loops) is available. Validation of the discipline tools is performed in a bottom-up approach, by investigating consistence and correctness of results of each individual discipline tool. This validation is done by the Discipline Specialists on his/her own tool, as he/she has the most intimate knowledge on the tool. Future work is focused not only on validation, but also on introducing extra-features needed for a more detailed (i.e. exact) evaluation of the structure (e.g. non-structural masses, rudder modelling).
Figure 14, Relative weight per area of the tail panels
13 American Institute of Aeronautics and Astronautics
References 1
La Rocca G., and M.J.L. van Tooren, “Development of Knowledge Based Engineering Techniques to Support Aircraft Design and Multidisciplinary Analysis and Optimization” AIAA Journal of Aircraft (under review). 2 Cerulli C., J.P.T.J. Berends, M.J.L. van Tooren and J.W. Hofstee, “Parametric Modeling for Structural Dynamics Investigations in Preliminary Design”, 2005 CEAS/AIAA/DGLR International Forum on Aeroelasticity and Structural Dynamics, Munich, Germany, 2005. 3 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”, 46th AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, Austin, Texas, USA, 2005. 4 Berends J.P.T.J., and M.J.L van Tooren, “An Agent System Co-operating as a Design Build Team in a Multidisciplinary Design Environment”, 44th AIAA Aerospace Sciences Meeting and Exhibit, Reno, Nevada, United States, 2006 5 Berends J.P.T.J., “Development of a Multi-Agent Task Environment for a Design and Engineering Engine”, M.Sc. Thesis, Delft University of Technology, Faculty of Aerospace Engineering, Delft, The Netherlands, 2005. 6 Cerulli C., P. Meijer, M.J.L. van Tooren, J. Hofstee, “Parametric modeling of aircraft families for load calculation support”, th 45 AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and material Conference, Palm Springs, California, 2004. 7 Basic Dynamic Analysis User’s Guide, MSC Nastran. 8 Guyan R.J., American Institute of aeronautics and Astronautics Journal, 3(2), 380, 1965. 9 Kier T., G. Looye and J. Hofstee, “Development of aircraft flight loads analysis models and uncertainties for pre-design studies”, 2005 CEAS/AIAA/DGLR International Forum on Aeroelasticity and Structural Dynamics, Munich, Germany, 2005. 10 Hofstee, J., T. Kier, C. Cerulli and, G. Looye, “A Variable, Fully Flexible Dynamic Response Tool for Special Investigations (VarLoads)”, 2003 CEAS/AIAA/NVvL International Forum on Aeroelasticity and Structural Dynamics, Amsterdam, The Netherlands, 2003. 11 Tooren M.J.L. van, E.J. Schut and J.P.T.J. Berends, “Design ‘Feasilisation’ using Knowledge Based Engineering and Optimisation Techniques”, 44th AIAA Aerospace Sciences Meeting and Exhibit, Reno, Nevada, USA, 2006. 12 Rothwell, A., “Structural Design and Optimisation II”, faculty of Aerospace Engineering, Delft University of Technology, TU Delft, 1999 13 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, 2002 14 La Rocca G., L. Krakers and M.J.L. van Tooren, “Development of an ICAD Generative Model for Blended Wing Body Aircraft Design”, Proceedings of the 9th AIAA/ISSMO Symposium on MDO, Atlanta, Georgia, USA, 2002.
14 American Institute of Aeronautics and Astronautics
