Towards a Uni ed Framework using CPACS ... - agile- · PDF fileTowards a Uni ed Framework using CPACS for Geometry Management in Aircraft Design A. Rizzi 1, M. Zhang , B. Nagel 2,

Towards a Unified Framework using CPACS for

Geometry Management in Aircraft Design

A. Rizzi1, M. Zhang1, B. Nagel2, D. Boehnke2 and P. Saquet1

1Royal Institute of Technology (KTH), 10044 Stockholm, Sweden2German Aerospace Center (DLR), 21079 Hamburg, Germany

The performance requirements for the next generations of airliners are stringent andrequire invention and design of unconventional configurations departing from the classicalCayley functional decomposition. The break with tradition calls for higher fidelity physics-based predictions of performance early on in the project. The paper makes the case for aunified, open, data-centric software environment for aircraft design and describes the mergeof the CEASIOM conceptual design software package, developed by a number of partnersincluding KTH, with the CPACS formalized data management system developed at DLR.The system provides multi-fidelity and multi-disciplinary analysis capabilities for concur-rent design by geographically distributed expert teams. The data-centric architecture usesthe CPACS schema and access mechanisms for management of design data across all dis-ciplines and fidelity levels. This makes the system extensible and mitigates the problemsencountered in handing over the model to later design phases. The concepts have beentested by interfacing external modules to CEASIOM/CPACS through a graphical CPACSXML editor, the ACbuilder gateway. Results of comparative analyses on models importedin this way from the RDS and VAMPzero conceptual design packages are reported here.CPACS will be released to the general public in spring ’12. The CEASIOM team expe-rience of joining forces via CPACS with DLR is altogether positive and further in-housedevelopment of software for aircraft performance prediction and design by the CEASIOMteam will use the CPACS system.

I. Introduction & Overview

A. Classical Conceptual-Preliminary Design

Present trends in aircraft design towards lighter more flexible airframes flying expanded flight envelopes withaugmented stability call for more tightly-coupled multi-disciplinary design procedures to efficiently evaluatethe flying qualities of the aero-servo-elastic aircraft. Numerous textbooks1–4 explain in detail how the entireaircraft design process can be categorized into three distinct phases, each with its own distinct objectivesand tasks: (1) conceptual definition at the aircraft level; (2) preliminary definition of its components; and(3), detailed definition for flight. The tools and how they are used, and even the people using them, usuallychange between the phases.

Conceptual design is primarily a search process to formulate a set of design variable quantities, which,according to appropriate modeling principles, define a vehicle that fulfills a set of minimum requirements de-termined by its mission. The tools for the search are provided by mathematical modeling (usually empiricallybased) to find a quantified description of the aircraft concept and its size, weight, and performance. The firststep sizes the aircraft, i.e calculates the aircraft takeoff gross weight, empty weight and fuel weight so that itachieves the range called for in the design specification. This results in a quantification of design parametersthat determine the aircraft configuration involving fuselage shape, wing and tail geometry, engine locations,payload etc. Once quantified, the aerodynamics, weights and propulsion models predict the dependent vari-ables which then determine the capabilities of the design and compare them to the design requirements. Thisprocess can be repeated with an increasing level of detail involving trade studies to evolve the design towardsits final configuration layout. There are many established conceptual-design codes that carry this out, e.g.Raymer1 and Roskam.2 This layout is then handed off to preliminary design where disciplines of structures,

1 of 20

American Institute of Aeronautics and Astronautics

weights, thermodynamics, and aerodynamics must be traded with each other in order to produce a balanceddesign candidate, which conforms to airworthiness and operational requirements. Because the analysis donehere is physics-based, it requires computational grids for CFD and for finite-element structural analysis(CSM). The hand-off process is notoriously manual and error-prone involving much re-working of data andmodels, and it is primarily uni-directional. Not least is the mismatch in the geometry description. Loftedsurfaces normally describes the geometry in conceptual design which are not trimmed nor even contiguous,so re-working and repair are necessary before gridding the geometry. Introducing more concurrency intothis process, allowing two-way flow up and down the conceptual-preliminary phases enabled by automaticgeometry repair/meshing, and making the design process more agile are all ways to improve its efficiency.

B. Increasing Efficiency & Agility

Nickol63 has drawn a table with six columns of disciplines (aerodynamics, structural analysis and weightestimations, noise, emissions, stability & control and geometry generation), each with three rows of fidelityfrom low to high, roughly corresponding to the three design phases mentioned above, as a means to clarifythis complex activity of aircraft design. For each entry point in the table there are one or more diverseanalysis (computational) tools suitable for its discipline. As the design work proceeds, data must travelacross the disciplines and upwards to the increasing fidelity levels. Nichol has identified ‘gaps’ between thetools used at different fidelity levels that hinder this information flow, and thus the efficiency of the designprocess. The dis-connect in the geometry description mentioned above is one example, which he calls the gapbetween lofting at the low level and ‘big iron’ CAD at the high level. Rizzi et al.27 describe how a ‘customCAD’ solution with automatic meshing can fill that gap, and the Nickol table has been edited to indicatethis, see Fig 1, changes in red text. The output at the high-fidelity level has been changed from ‘big iron’CAD to meshable models and grids for CFD and CSM because the aerodynamic and structures tools at thislevel require grids to carry out their physics-based analysis. Other researchers have found other solutionsto filling the gap. Amadori et al.59–61 has developed templates that work with CATIA from the start, andHaimes and Drela21 use openCASCADE in a similar way. Providing the connection between lofting andCFD or CSM grids improves both the dataflow and the workflow, and hence the efficiency and agility of thedesign process.

Figure 1. Table of analysis disciplines (tools) versus their fidelity for aircraft design according to Nickol63

The work by Rizzi et al.27 and Zhang28 on coupling parametric aircraft lofting to CFD and CSM gridgenerations was carried out in the CEASIOM design environment. The CEASIOM software system developedin the EU-funded collaborative research project SimSAC5 generates stability and control data for preliminaryaircraft design using a choice of numerical methods of varying fidelity. The system aims at automation ofthe computation of tables of forces and moments for the rigid or elastic aircraft with control surfaces. In

2 of 20


order to obtain this data, the aircraft geometry must be defined, computational meshes for (ComputationalFluid Dynamics) and Computational Structural Mechanics analyses need to be created and finally, thesolver parameter settings must be adapted to reliably perform multiple solutions from which the tablesare compiled. CEASIOM thus is a design environment that addresses the discipline columns: geometry,aeroelastics and flight dynamics (S&C) in Nichol’s table (Fig 1).

The design process implies not only a dataflow but also a workflow, and to carry this out an engineeringframework software is needed to link together the diverse analytical tools in Nichol’s table and launch themfrom an efficient system-level interface. The toolset in CEASIOM is integrated under control by a Matlab‘HUB’ routine with information flow through a XML dataset all of which has been cobbled together in aworking but rather ad hoc fashion. However, when Rizzi et al.27 extended its functionality by interfacingCEASIOM with Raymer’s RDS software,26 it became evident that the ad hoc XML dataset was not suffi-ciently general and not well enough structured to offer the extensibility of the system desired for continueddevelopment.

The knowledge for aircraft design in DLR is spread over different institutes and sites. Nevertheless,overall aircraft design is an important topic within DLR and hence it is a key task to collaborate as effi-ciently as possible independently from physical barriers. Since 2005 DLR is developing a network of analysiscapabilities. The strategy is to connect disciplinary experts and their respective analysis modules to createdesign processes. The analysis modules coded as computer programs on various platforms remain withinthe domain of the disciplinary experts. Two core technologies enable this collaboration within DLR. TheRemote Component Environment (RCE) is an integration framework that handles network communicationand data exchange among analysis modules as well as process control. The data is exchanged in the form ofthe Common Parametric Aircraft Configuration Schema (CPACS). In this data-centric setup the number ofinterfaces decreases and effective communication can be established. CPACS is based on XML technologiesmaking it human readable and computer processable. It is designed to accommodate data for numerousdisciplines involved in the conceptual as well as preliminary design phase and is seeing application even inhigh-fidelity analysis. It is comprehensive and covers all the disciplines in Nickol’s table and even additionalones added by Price et al.64

This paper describes how CEASIOM is adopting the CPACS data-centric XML standard, and presentsseveral analysis exercises that demonstrate the benefits in efficiency and agility that accrue from its use,particularly for interfacing with external tools. The paper begins with a general description of a unified designenvironment and explains how CEASIOM is one such example of a system consisting of a data-structure, atoolset and software to control the design process and to carry out the workflow. An explanation followson how the CPACS data structure provides a more unified geometry management in CEASIOM. A detaileddescription is given how its geometry module ACbuilder has been re-constructed to incorporate the CPACSdata structure, and in effect has become an XML-editor to the CPACS data. Then another section looksat the benefits that accrue from this unified management, namely how it eases the integration of externalcomponents into CEASIOM, namely the RDS software and the VAMPzero36 software. Two example processesare worked through and illustrate the path from low to high fidelity geometry. These examples demonstratethat the gap in the Nichol table for geometry has in fact been filled and that the central dataset CPACSfurther unifies CEASIOM and facilitates extension of the toolset. The paper concludes with some thoughtsfor future developments with the DLR software packages becoming open source, similar to the openMDAOnetwork.

II. Anatomy of Unified Design Environment

A design environment enables engineers to cooperate by means of structured and mostly autonomousexchange of information. This exchange is mainly comprised by interfaces between analysis modules but alsoencompasses process and optimization knowledge.

For a single domain expert boundary conditions in his discipline become dynamic while connecting toa design environment, as for example structural engineers obtain access to various aerodynamic analysismodules. It should be noted that a design environment also needs to feature the exchange of informationbetween designers as fully automatic design processes remain utopia. Efficient methods for collaborativedesign and debugging are a necessity.

Although many valuable design tools exist in the various disciplines, it turns out that bringing themtogether is a difficult and demanding process. Design environments need to define a common namespace

3 of 20


Figure 2. A generic design environment consists of three distinct components: 1) a common namespace (i.e.language), 2) analysis modules and 3) an integration framework

and design codes need to adopt this to their own code. Model driven architectures are known from softwareengineering and Reichwein, et al.41 link this expression to engineering design. The elementary idea remainsunchanged, as all design models need to be deduced from the central model (common namespace). Multidis-ciplinary frameworks to be named include the Design Engineering Engine (DEE) from TU Delft42 as well asthe Multidisciplinary Design Optimization System (MDOPT).43 The PASS module is coupled with modulesfor environmental analyses in the Collaborative Application Framework for Engineering (CAFFE) as shownby Antoine, et al.44 In their study Alonso, et al.45 present a framework for high-fidelity applications codedin Python.

A design environment as depicted in Figure 2 an as proposed in this paper consists of three key items.First of all it is necessary that a common namespace or language definition is available. Communicationcan only be effective if a common language is spoken. Secondly, as the design environment is distributed anintegration framework is necessary. The integration framework enables designers to couple several analysismodules, the third item of the design environment, whereas all analysis modules are linked to the samecommon namespace.

The integration framework consists of two parts: Firstly, the editor and visual environment for thecreation, modification and access control of analysis tool chains. This graphical user interface provides somekind of workspace and enables process designers to interact with analysis modules. This encompasses couplingof modules as well as interactions with central model representations, regardless of whether textual, structuralor geometric. Secondly, there is the core logic that provides data transfer between remote components,management of intermediate and resulting data sets, extraction and merging of partial data with the centraldata model. Further duties that the framework supports are convergence control and optimization.

Due to the fact that in efficient data exchange the number of interfaces is the critical factor for theflexibility of a design environment, a central information model is a key feature.

The design environment must use legacy analysis modules. They can be any form of coded analysisroutine but should preferably be able to run in batch mode. Their inputs and outputs are usually linked tothe common namespace via wrapper components that handle the translation. In this way also proprietaryand closed source analysis codes can be coupled to the design environment. Along with an analysis module adetailed documentation and a domain expert should be available that help in interpreting results and errors.

In the following sections an example setup for a design environment is shown. The common namespace isestablished by using the Common Parametric Aircraft Configuration Schema (CPACS). A Framework that isin use at DLR together with CPACS is the Remote Component Environment(RCE). Several analysis modulesfrom Computerised Environment for Aircraft Synthesis and Integrated Optimisation Methods (CEASIOM)are now linked via CPACS and elaborated in more detail.

A. Common Namespace - CPACS

Since 2005 the Common Parametric Aircraft Configuration Schema (CPACS) is developed by DLR for theexchange of information on the level of preliminary design. The system is in operational use at all aeronauticalinstitutes of DLR and has been extended for civil and military aircraft, rotorcraft, jet engines and entire airtransportation systems.

The data-format is based on XML technology. An assessment of alternatives for modeling languages forpreliminary aircraft design is reported in Boehnke et al.38 Ongoing works include the documentation of theschema that described the syntactic definition on CPACS. Additionally, some getting started documents arebeing prepared. Some supportive libraries handling XML and geometric data are available and are describedin more detail in the following section as they are included in the Chameleon@RCE framework.

4 of 20


Applications in aircraft design and optimization are shown by Liersch13 and Zill.35,47 An approach tomulti-fidelity using CPACS is outlined by Boehnke.37 Pfeiffer46 implemented a chain of analysis modulesthat coupled works of TU Delft, KTH Stockholm and DLR.

CPACS holds detailed interpretable type definitions for semantic entities from the air transportationsystem. Precise definitions for geometric elements like aircraft, wings, sections, elements, profiles, points,and transformations are given. Additional elements can be defined which are out of the scope of this paper.Figure 3 indicates the rich feature-tree hierarchy of the CPACS language. CPACS not only holds information

Figure 3. Root structure of the CPACS data format.

on the objects but also data for the connected analysis modules. Such tool-specific data is transferred alongwith the dataset and carries further information, such as parameters for numerical methods, to the analysismodules. In this way, analyses involving sequences of modules can be defined.

(a) (b)

Figure 4. CPACS advantage of unified data management in a multi-code framework: a) without unified dataN to N interfaces , b) with unified data (red pentagon) N to 1 interfaces.

B. Frameworks

1. Chameleon@RCE

In preliminary aircraft design multi-disciplinary cooperation plays a key role. In DLR automated processchains containing tools of various disciplines are used for global optimization in the preliminary designphase. Such process chains make sure that the involved tools are executed automatically in considerationof their dependencies. Required user interaction is reduced. The fact that DLR is spread over several sitesand institutes requires a distributed design environment. Not only different software architectures but alsoavailability of computational power are issues to address.

To meet the requirements of preliminary aircraft design in DLR we devised an integration concept calledChameleon. It includes a standardized data format (CPACS29) used to describe aircrafts, a set of helping

5 of 20


tools, and reusable interface libraries (TIXI,31 TIGL32) for that data format. We built the Chameleon con-cept on top of the open-source, distributed software framework Remote Component Environment (RCE,3348).Hereby, it provides components like a process chain engine, a data management, or appropriate user inter-faces as depicted in Figure 5. Chameleon in conjunction with RCE forms DLR’s simulation framework forpreliminary aircraft design.

Figure 5. Screenshot of Chamelon@RCE

2. The OpenMDAO Framework

The OpenMDAO is an open source framework for performing Multidisciplinary Analysis and Optimization(MDAO).24 It is being developed to meet NASA’s need to encapsulate more advanced MDAO processes andthe need to allow the integration of higher-fidelity tools into the design process (see http://OpenMDAO.org).It focuses on definition, execution, and monitoring of computational chains with a mission to advance scienceby promoting collaboration and cooperation among industry, government, and academia through the use ofopen source tools.

An overview of the hierarchy of software elements is given here. In OpenMDAO, a computational taskis represented by a system of objects called Components with inputs and outputs. A Component performsa calculation when executed, and the output of one Component can be passed as input to another. NativePython Components are very easy to construct and provide rapid implementation of new analysis tools.Other Components may consist of a Python wrapper for a code written in another language, such as Fortran,C, or C++. Legacy engineering tools are integrated into OpenMDAO as Components by wrapping.

OpenMDAO uses Drivers as process controllers to perform iterative tasks like optimization, convergence,and design of experiments (DOE). Thus, an analysis will usually be built into an Assembly from a set ofComponents controlled by a Driver. Since both the Assembly and Driver classes are sub-classes of Compo-nent, they can have their own inputs and outputs and can be included in models with other Componentsto build ever more complex Components. This capability allows e.g. a turbine engine simulation in an As-sembly which is used as a Component in an aircraft simulation. substituted to modify the function providea place where users additional calculations. Even more intricate processes can be implemented by Work-Flows, objects in the iteration hierarchy that can dynamically determine the execution order for a group ofComponents.

Data is passed between Components using I/O-traits, i.e. variables to hold the output of one Componentwhen required as an input to another Component. Python is a weakly typed language, so the EnthoughtTraits package was used to create a set of strongly typed variable classes to provide more stringent type andunit checking between Components.

3. The CEASIOM Hub

The CEASIOM framework functions are performed by the Hub with its main GUI shown in Fig. 7. Theprocess chains are executed by the engineer with automation built into the generation of aero-data tables bysmart sampling schemes provided by the Aerodata ModelBuilder part of the hub. The focus is on obtaining

6 of 20


early predictions of stability and handling qualities, and the structural design was supported/emulated withthe optimization scheme for structural sizing in the NeoCASS aero-elastic simulation module. Therefore,the computational chains would follow some subset of the loop in Fig. 6. Experiments with optimizationloops from geometry to aero-data have been carried out (ciet Berard Cavagns 2007 or so) such as selectingwing planform and twist distribution for minimizing wave drag or drag due to lift. However, the currentframework does not provide for definition of new computational chains and therefore is less well suited forgeneral MDO processes.

Figure 6. Computational chains in CEASIOM

C. Analysis Modules - CEASIOM

CEASIOM, the Computerised Environment for Aircraft Synthesis and Integrated Optimisation Methods,developed within the European 6th Framework Programme SimSAC (Simulating Aircraft Stability AndControl Characteristics for Use in Conceptual Design), is a framework tool for conceptual aircraft designthat integrates discipline-specific tools like: CAD & mesh generation, CFD, stability & control analysis,etc., all for the purpose of early preliminary design.5 CEASIOM is an ad hoc framework. The CEASIOMframework offers possible ways to increase the concurrency and agility of the classical conceptual-preliminaryprocess. Figure 7 presents an illustration of the CEASIOM software, showing aspects of its four core functions:geometry & meshing, CFD, aeroelastics and S&C (flight dynamics).

Significant features developed and integrated in CEASIOM as modules are:

1. Geometry module ACbuilde-sumo6

A customized geometry construction system coupled to surface and volume grid generators; Port toCAD via IGES

2. Aerodynamic module AMB-CFD8

A replacement of current handbook aerodynamic methods with new adaptable-fidelity modules referredto as tier I (a. and b.) and tier II (c.):

a. Steady and unsteady TORNADO vortex-lattice code (VLM) for low-speed aerodynamics andaero-elasticity

b. Inviscid EDGE CFD code for high-speed aerodynamics and aero-elasticity

c. RANS (Reynolds Averaged Navier-Stokes) flow simulator for high-fidelity analysis of extremeflight conditions

3. Stability and Control module S&C9

A simulation and dynamic stability and control analyzer and flying-quality assessor. Test flights withsix Degrees of Freedom flight simulation, and performance prediction, also includes human pilot model,

7 of 20


Figure 7. Core modules ACbuilder-sumo, AMB-CFD, NeoCASS and S&C (SDSA, J2 and FCSDT) in theCEASIOM software

Stability Augmentation System (SAS) and a LQR based flight control system (FCS) package are amongthe major functionalities of this module.

4. Aeroelastic module NeoCASS7

Quasi-analytical structural analysis methods that support aero-elastic problem formulation and solu-tion

5. Flight Control System design module FCSDT10

A designer toolkit for flight control-law formulation, simulation and technical decision support, permit-ting flight control system design philosophy and architecture to be coupled in early in the conceptualdesign phase

CEASIOM is meant to support engineers in the conceptual design process of the aircraft, with emphasison the improved prediction of stability and control properties achieved by higher-fidelity methods thanfound in contemporary aircraft design tools. Moreover CEASIOM integrates into one application the maindesign disciplines, aerodynamics, structures, and flight dynamics, impacting on the aircraft’s performance.It is thus a tri-disciplinary analysis brought to bear on the design of the aero-servo-elastic aircraft.11,12

CEASIOM however does not carry out the initial sizing of a baseline configuration.

1. Unified Geometry Management by CPACS and ACbuilder

The aircraft design framework consists of the set of computational modules, unified by the central dataexchange by a common format, and extended to a design system by having a set of defined computationalchains to be used for sizing and optimization. The data format must support also definition of the chainas well as module-specific meta-data such as tolerances, method selectors, etc. Automatic execution of thecomputational chains requires that the modules can run without engineer intervention.

8 of 20


2. Extension of CEASIOM geometry

The development of the CEASIOM system has established the feasibility of a multi-disciplinary, multi-fidelitysoftware tool for aircraft design including aero-elasticity and stability and control assessments. CEASIOMrequires as input an initial layout as baseline configuration sized to the mission profiles by specification ofthe O(10) parameters used in the pre-design process. Then it refines this design in the concept design stageand outputs a revised layout for consideration in the down-select process preceding the detailed design.The process generates significant knowledge about the design and the candidate configurations through theCEASIOM analysis and simulation modules, and increases the fidelity of the predictions. The informationgenerated suffices for six degree of freedom engineering flight simulation. It is also sufficient to construct awind-tunnel model, comparable in quality to what would be designed in the traditional approach to stabilityand control design. Multi-module software for collaborative working needs a common data format, and thesystem components are integrated by the CEASIOM XML file exchange. The CEASIOM geometry definitionis hierarchical, but somewhat ad hoc and limited, e.g., by not allowing indexed instantiation of componentsand this hampers further development. Flow prediction by Euler flow models, necessary for transonic aero-force prediction, requires detailed representation of both lifting surfaces and fuselage shapes. For instance,the wing shape definition is currently too coarse to account for the finely tuned camber, thickness, and twistvariations of modern transonic wings. Similarly, unconventional configurations such as blended wing-bodiescannot be modeled accurately, as will be shown in the examples below.

3. CPACS Import and Export

Adoption of CPACS, as indicated above and described below, as unifying data format will resolve theseissues. The CPACS data format manages all geometrical configurations, enables the development of multi-fidelity structural analysis modules, and enables loosely coupled optimization procedures to be applied toproblems which exercise several analysis modules combined into computational chains. The XML / XSDtechnology which provides validation of data files mitigates the risk of creating inconsistent data sets byinadequate or inadvertent manual manipulation of the files; indeed, no manual editing is foreseen.

In anticipation of installation of the new geometry data management, links between CEASIOM and theconceptual design packages RDS1and VAMPzero36 have been established to shed light on issues of geometrytranslation, see Fig 8. RDS and VAMPzero both belong to the ”Non-meshable” geometry modeler category,see Fig 15(a). RDS and VAMPzero are linked to CEASIOM by translators for the geometry information. Ingeneral, such translation between different formats is a tolerance driven, constrained approximation problem.However, for the systems considered here, the problem is easy. For RDS, because it defines shapes by pointson cross-sections just like sumo, and for VAMPzero because it already uses CPACS. The RDS link was usedto re-visit the Airbus A320 look-alike studied in26 and with respect to trim and drag divergence in28 and.27

The VAMPzero link gives experience of geometry translation and investigates the further development ofthe CEASIOM ACbuilder to an interactive, graphical editor for CPACS XML files.

4. Export to generic CAD

Automatic Euler mesh generation and flow prediction via sumo is of immediate interest. This functionalityis offered also by generic ”full-scale” CAD systems linked to high-end commercial mesh generators, suchas CATIA plus ICEM-CFD.58 As discussed in? and27 we have chosen to work with customized in-houseand open source software instead. Although the link to generic CAD systems has not been explored inthe experiments reported here, CEASIOM models can be handed over to later design phases as IGES files.This export format currently supports the external shape, as needed for higher-fidelity CFD and possiblystructural analysis and sizing, using tools like those developed by DLR. The CEASIOM model actually coversalso internal geometry such as spar and fuel tank location, payload compartment, and aero-force tables forflight simulation, which should also be exported. CPACS is designed to support also this kind of data, andcould provide the unified data format for export to complete ”Product Life-Cycle Management” software.

5. The ACbuilder Gateway

The ACbuilder module is the gateway for model import, creation, and management. As an interactivegeometry editor with graphical feed-back, it supports import from RDS and VAMPZero and the CAD repair

9 of 20


Figure 8. Linking conceptual design codes to preliminary design codes via CPACS.

as necessary, and also creation of meshable geometry models from scratch. The latter function uses a master-model concept where components from a library are selected, given their correct shapes, and subsequentlyput together to form a water-tight meshable surface model, fig. hierarchic. The obvious alternative is tostart from a base-line which already exists as CEASIOM model.

The CAD repair in ACbuilder is manual and proceeds by inspection of the rendered model for flaws likeoverlapping surfaces with undesired almost flush intersections, or gaps between components. As an example,the original VAMPZero A320 look-alike model had a small gap between vertical tail and fuselage which wasclosed by pushing the tail a fraction of an inch down. It should be noted that sumo performs automaticCAD repair by closing wingtips and fuselage noses and tails, as necessary. Such functions are enabled bythe customization to aircraft geometry: sumo knows about wings with sharp trailing edges, etc.

III. ACbuilder - a XML-editor for CPACS

To adapt the ACbuilder as a geometric pre-processor to CPACS it must follow the geometric definitionswithin the format. A short overview on the modeling of outer geometries is given in this section. The innergeometry (e.g. spars and ribs) is defined accordingly, so that it follows parametric changes of the model.

The geometry description in CPACS is parametric to ease changes in the geometry and hence optimizationloops. The conversion from the parametric model to a full CAD model is done by the geometric libraryTIGL.32 TIGL is based on the openCascade kernel and offers functions related to CPACS, e.g. find x,y,zcoordinates on a wing from span and chordwise coordinates. Additionally, TIGL offers export functionalitiesto other formats such as IGES and STL.

Figure 9 displays the conversion process from the parametric CPACS model to the wing geometry. Theprocess is similar for fuselage geometries. Profiles are defined as a list of points. Each element can carrya single link to a profile. Multiple elements can be located in one section for the definition of split wings.An arbitrary number of sections defines a wing. Each wing, section and element can be transformed viascaling, rotation and translation. Finally, sections can be positioned relative to each other via positionings.Geometric information can be stored in several ways using this decomposition. This is due to the factthat different use-cases exist. On the one hand information might be available as 3D coordinates from the

10 of 20


Figure 9. Parametric Wing Model in CPACS

measurement of a wind tunnel model. In this case only wing airfoils would be defined and linked in themodel. On the other hand a use-case might focus more on parametric studies where the full parametricmodel is exploited. TIGL will interpret the information accordingly. As analysis modules couple to CPACSvia TIGL, no additional routines for the import are needed.

A. Functionalities of the new ACbuilder.

In the ACbuilder module, all the calculations are carried out in Matlab whereas rendering is done by a Javacode offering faster graphics. As a consequence, the software can be extended by engineers who are not Javaexperts, because the connection between the two parts is uni-directional: all the data go from Matlab toJava, see Fig. 10. The graphical interface of ACbuilder is separated into two windows to support assembly of

Figure 10. Basic structure of the new ACbuilder

components and detailed sizing by editing of parameters. One is the editor proper, a Matlab window, andone is the renderer, the Java window, see Fig. 11. The Matlab window contains the different menus (project,geometry, weights and balance, technology, help), list boxes and edit fields for parameters correspondingto the chosen menu, and also functions to manipulate the rendering window . The Java window servesonly to render the component surfaces which make up the configuration, and provides highlighting, color,transparency, and zoom and pan manipulation tools.

11 of 20


Figure 11. Geometric definitions in ACbuilder

This module supports step by step compilation of the different parts of the models: definition of externaland internal geometry, fuel tanks, weights breakdown and balance, technology definition, etc.. The restrictionon the order of assembly is inherited from the model hierarchy. Components on the same level of the hierarchycan be assembled and sized in any order, but child components only after their parents.

B. Object Oriented Modeling

In the following, an instantiation of a component is referred to as an element. An aircraft can be built fromscratch, element by element, (Fig 12) by loading predefined templates for each element from the library. The

Figure 12. Building from scratch in ACbuilder with templates and elements

user can start a new project by loading an aircraft template, an existing whole aircraft, or just an element.Only the elements really used to build a model will be loaded. For example, the aircraft under constructionin Fig. 12, a Horizon 1100, is made of a fuselage, a wing, a horizontal tail, a vertical tail, and a pair of openpusher-fan engines. There is no canard, ventral fin or tail booms.

12 of 20


Figure 10 shows export/import functions. Import XML and Export XML copies the model from/toCPACS files, and the Export grid points sends geometry data to sumo for mesh generation, etc..

For easy parametric geometry input the user must be aware of the coordinate system. The configurationis a tree structure and one option is to let child components inherit global coordinates from parents, and besized relative to their dimensions. This is very natural for e.g. control surfaces which are children of a liftingsurface. Another option is to size the components absolutely and position them in the global coordinatesystem. This makes components more independent and supports generation/deletion in any order. Therefore,ACbuilder employs the global method, with a few obvious exceptions. Figure 11 shows the positioning of thehighlighted component, a fuselage.

When a template, complete aircraft, or element has been imported, its Matlab struct is compiled. Whenthe user changes parameters or adds elements, the struct is updated and the right method corresponding tothis change is activated. This function also creates the surface as a 2-D array of (x, y, z)-coordinates andtransfers the coordinate array to the Java renderer to update the view. Using the parent/child relations, theprogram can determine which elements are affected by the change and will execute only those necessary.

C. Internal structure and control surfaces

The structural and aeroelastic module, see Fig. 7 can estimate an equivalent beam model from the externalgeometry alone. For higher fidelity structural models, such as in Fig. 13(a), key spar and rib locations mustbe supplied Fig. 13(b). Also fuel tank locations must be provided to allow precise balance prediction asnecessary for trim calculations in flight simulation.

(a) Wing structure FE model (b) Spar and rib definitions

Figure 13. Wing structure model in ACbuilder

Once the wing surfaces are generated, the control surfaces are computed. The current definition positionsthem on the wing planform, see Fig. 14 but does not consider details of hinges, gaps, or flap tracks althoughsuch data can be provided in the CPACS file.

Currently, the various CFD solvers use the control surface definitions in different ways. The CEASIOMvortex lattice module physically deflects the part of the wing planform marked as control surfaces. The Eulersolver uses the transpiration approximation and does not change the mesh in response to deflection but onlythe affected surface normals.

IV. External Design Tools Interfaced to CEASIOM

This section gives an overview of the two external tools that have been interfaced to CEASIOM, namelythe VAMPzero conceptual design code for initial sizing and the RDS Integrated Aircraft Design and Analysiscode.

13 of 20


(a) Control surface definition (b) A320-look-alike with control surfaces

Figure 14. Control surfaces in ACbuilder

A. VAMPzero Interface

The conceptual design module VAMPzero36 is developed to support DLR’s multi-disciplinary design en-vironment.35 It is based on well known handbook methods1,2 with some adaption to newer technologies,especially mass estimations.

VAMPzero is based on an object-oriented structure making it more flexible than conventional approachesfollowing a procedural calculation process. Giving feedback about the calculation to the user is one of thekey features of VAMPzero. It tracks and displays the dependencies between parameters, e.g. wing areais a function of aspect-ratio and span. Furthermore, it is capable of determining the sensitivities of thesedependencies via complex step derivative approximation.39

As VAMPzero is a supportive analysis module for CPACS, it has to handle two tasks: initializationand integration. Obviously, a design process needs to go through requirements definition and conceptualdesign before preliminary methods can be applied. VAMPzero handles the conceptual design stage but alsoinitializes the CPACS data set so that higher level analysis modules can be triggered. It creates geometriesfollowing a knowledge-based engineering approach and writes necessary process data like for example tool-specific settings. An example of a CPACS geometry generated by VAMPzero can be seen in Figure 15(a).Notice that the geometry generated is not meshable, e.g. the vertical tail does not intersect the fuselage.

Additionally, once preliminary design modules have analyzed the concept all the updated properties needto be integrated into the overall aircraft design. VAMPzero can interpret higher level results from CPACS(e.g. engine performance, aerodynamic performance, mass breakdowns) and base a new calculation on theseresults. The process of initialization and integration is depicted in Figure15(b).

(a) VAMPzero 3-view of A320 (b) Multi-Fidelity Design Process

Figure 15. Conceptual Design Module VAMPzero

14 of 20


B. RDS Interface

RDS features a CAD module for the rapid development of an initial aircraft concept and its subsequentrapid evolution to a preferred baseline,27 but it does not support production-quality lofting, so its modelcannot be meshed without additional refinement. The key to early computational analysis is a rapid-meshingprocedure which can take such a rough CAD model and quickly create a usable computational grid, termeda “meshable” or “solid” model. The CAD model might not qualify as a “solid model”, may have componentintersections which are ill-defined or worse, might have gaps in the surfaces, and quite likely is not evenmathematically “watertight”. RDS stores design geometry in its own unique format27 as a collection ofcomponents represented as surfaces. Each component has its own axis system, and a variety of airplane -specific mirroring schemes and replication / modification operators are embedded. Figure 16(bottom) showsthe RDS rendering of the A320-look-alike.

V. Two Examples: Conceptual-Preliminary Design Handoff

Two example cases are selected to demonstrate the handoff from geometry creation in conceptual design toa meshable model and a grid for CFD computations and a structural model for flutter analysis in preliminarydesign.

The inter-disciplinary couplings to CEASIOM via ”wrapping” translates the geometrical information. Thefirst one, a conventional A320-like configuration, is an easy test of the wrapper because the mapping of theCEASIOM XML to CPACS XML is good. The second one, an unconventional blended-wing-body (BWB50), isharder because of the CEASIOM XML limitations in fuselage and wing sections. The RDS A320-look-alikeis analyzed for drag divergence at transonic speed, and the VAMPzero A320 is tested for flutter. TheCEASIOM BWB model lacks in geometry fidelity, as explained above, and Euler flow calculations on themodel translated from the (accurate) VAMPzero model highlight the consequences for flow patterns.

A. RDS-CEASIOM Data/Workflow: A320 Lofts to Grids, CFD & CSM

sumo? can import geometry from a variety of sources, and make automatic surface mesh generation. Thevolume mesh is generated with the tetrahedral mesh generator TetGen. The CEASIOM translator reads theDSN file and writes the sumo SMX file. Since the RDS ‘universe’ of shapes is quite close to the sumo one,no serious approximation problems were encountered, but implementation of the replication/modificationfeatures in the DSN definition was a significant hurdle. Figure 16 shows the VAMPZero and RDS-sumo-CEASIOM path to the sumo CFD meshable model and NeoCASS aero-elastic structural model. We assess

Figure 16. Rapid creation of meshable models from CPACS (VAMPzero) and RDS accomplished the handofffrom conceptual to preliminary design. Top, VAMPZero blended wing-body, and bottom, RDS A320-look-alike.

cruise efficiency by calculating the transonic wave-drag by Euler flow simulation running the EDGE code

15 of 20


with zero viscosity. Rough estimates for control surfaces were made and the surfaces added in the sumomodel to check that elevator trim angles were reasonable. The trim angles of attack are small, and liftand drag coefficients were calculated for M∞ from 0.1 to 0.9, as well as the transonic cruise efficiencyindicator ML/D, see Figure 19(a). Drag divergence onset is for lower Mach-number than expected, and thisdiscrepancy with reality was traced to the airfoil shape. The chosen airfoil, see Fig 19(b), is sub-optimal fortransonic operation. No airfoil is needed in the RDS analysis because it is empirical, but an airfoil must bespecified to generate the surface mesh. A need like this for more data is one aspect of the handoff problem.

B. VAMPzero-CEASIOM Data/Workflow: A320 and BWB Lofts to Grids, CFD & CSM

1. VAMPzero-sumo Handoff

The demonstration performed here is to take the CPACS XML file created by VAMPzero and input it intothe ACbuilder, which via the wrapper can read and work with it. Figure 17(a) shows that ACbuilder correctlydescribes the geometry for the A320-like configuration, so it passes the ‘easy’ test. VAMPzero does notmodel control surfaces so they were added in the ACbuilder. However, because the ACbuilder does not do aswell for the BWB configuration because of the limitations on wing and fuselage sections in the CEASIOMXML, the CPACS XML file was passed directly to sumo which produced Fig 17(b).

(a) (b)

Figure 17. Examples of two CPACS-data described aircraft: a)A320-like conventional configuration , b) BWBconfiguration.

2. sumo-CFD & CSM Analysis

The previous demonstration determined that CEASIOM has interpreted the CPACS XML correctly for theA320. So the next check proceeds with this configuration to sumo to generate a mesh around it and carryout an Euler-solution analysis for transonic cruise at M∞ = 0.8, as shown in Fig 18(a). The third testanalyzes its flutter characteristics, Fig 18(b). The final check repeats the above calculations for the BWBconfiguration. sumo generates a mesh around the BWB and then an Euler-solution analysis for transoniccruise at M∞ = 0.85, as shown in Fig 20. Notice that the transonic cruise efficiency indicator here is very low,under 10, whereas for the A320 it is just above that. In both cases this means poor transonic performance,and it points to the handoff from conceptual to preliminary design. The RDS empirical analysis knows theperformance that can be obtained for a conventional configuration, and designs accordingly. But there areno equivalent empiricisms for a BWB, hence the handoff problem is larger for unconventional configurations.The low-order analysis on which this BWB design is based ignored the base-flow drag at the rear of the bodywhere the engines would be installed. In this case the conceptual design should have used higher-fidelityanalysis already from the start.51

VI. Conclusions: Collaborative Aircraft Design Enabled by OpenData-Centric Design Environments

The future of aircraft design will most likely see a paradigm change towards unconventional configurations.The current re-engining programs in commercial aviation have postponed the entry into service for new single

16 of 20


(a) (b)

Figure 18. Physics-based aero-structural analysis using computational grids created in sumo for A320-likeconfiguration: a)Cp distribution computed in Euler solution, M∞ = 0.8, α = −2◦ , b) Unstable in-planebending, flutter mode 11, 6.38hz

(a) (b)

Figure 19. CEASIOM prediction of RDS A320 look-a-like cruise efficiency: a) wave drag computed in Eulersolution , b) RDS A320 look-a-like airfoil, NACA 65(216)-415, a laminar-flow airfoil.

aisle configurations because the current technology gap is not wide enough for manufacturers to justify newdesigns.

Unconventional concepts usually require integrated designs. The classical functional decomposition ofwing-body-tail where wing generates lift, body accommodates payload, and tail ensures stability & controlwill no longer be valid. The most obvious example is a blended wing body. As the decomposition dissolves,the interaction between the disciplines involved increases. Therefore enhanced means of communicationbetween engineers as well as software tools are necessary in future design environments.

As proposed by Kroo,49 a third generation framework for multidisciplinary analysis and design consistsof not only a distributed network of tools but also of a network of design teams. In this scenario no superusers exist. The knowledge to handle the system is distributed among designers. Nevertheless, the designersremain the holders of core capabilities in certain disciplines.

To face these challenges we propose an open data centric design environment consisting of the three keycomponents already mentioned in this paper: a common namespace for effective communication, analysismodules coupled to this namespace, and an integration framework for process control. Three key argumentsfor a central data model can be outlined: the number of interfaces, compliance, and exchangeability.

17 of 20


(a) (b)

Figure 20. CEASIOM prediction of RDS A320 look-a-like cruise efficiency: a) wave drag computed in Eulersolution , b) RDS A320 look-a-like airfoil, NACA 65(216)-415, a laminar-flow airfoil.

As there are more interactions the number of interfaces should be decreased to a minimum. In this waycommunication between experts can be as efficient as possible and is not concentrated on transforming datafrom one format to another.

Additionally, data handling should ensure that data that is passed from one analysis module to anotheris interpreted in a similar way. The compliance of data minimizes the chance of misinterpretation. Witha central data model like CPACS29 the first step towards compliance is an extended documentation. Allparameters are described in more detail in the central documentation. Furthermore, overall libraries arebeing developed for CPACS that aid in the interpretation and hence ensure further compliance. TIXI31 isa general XML interface that is based on libxml2 and extended to interpret for example arrays and othercomplex data structures in CPACS. TIGL32 is a library that handles the geometric data in CPACS. Ittransfers the parametric description to a full CAD model (in OpenCascade) and gives detailed informationon this geometry.

Finally, different design problems relate to different levels of fidelity. This tradeoff between computationalcost and level of detail in the analysis is an ongoing issue even though computational power is ever increasing.For example in aerodynamics, at some points in the design a CFD simulation is desirable whereas at anotherpoint vortex-lattice methods are sufficient. A central model ensures simple exchangeability of analysismodules. Due to the fact that CPACS is based on a hierarchic structure it is also possible to define differentlevels of fidelity. The more detail, the deeper the information is stored in the hierarchy.

Proprietary codes are not likely to open their interfaces and connect to a data-centric environment. Inour opinion an open-source approach is the only one suitable for a future design environment. As can beseen from Gray et al.,34 the openMDAO framework follows a similar approach. Note that such a data-centric open framework with documented data format is open also also to proprietary analysis modules andprocess control software such as ModelCenter, ISight, etc. The framework allows even processes which usedata which is visible only to a certain analysis module, but hidden from general view, and can supportalso business models relying on non-disclosure of certain data. Research is the key task for the frameworktherefore anyone should be able to implement adaptations to design problems. Additionally, cost should notbe an impediment factor in collaborative aircraft design.

We believe a strong case can be made for the data-centric model with documented data formats. CEA-SIOM was the first freely available tool-suite for aircraft design following a distributed approach. Our currentresearch combines CPACS and CEASIOM. CPACS in combination with the supporting libraries and DLR’sintegration framework RCE33 will be officially released to the public on the 15th of March in 2012. Addi-tionally, the conceptual design tool VAMPzero is also available under open source license. Our own futuredevelopment will be incorporated in this open environment.

18 of 20


References

1Raymer, D. Aircraft Design: A Conceptual Approach, 4th ed., AIAA Education Series (2006).2Roskam, J. Airplane Design. DARCorporation I-VII (1989).3Torenbeek, E., Synthesis of Subsonic Airplane Design, Delft Univ Press, 1982.4Kundu, A. K. Aircraft Design. Cambridge Aerospace Series (2010).5Rizzi, A.: Modeling and simulating aircraft stability and controlThe SimSAC project, Prog Aerospace Sci, Vol 47, 2011,

pp.573-588. see also www.ceasiom.com (Date 15.12.2011)6Tomac, M. and Eller, D.: From geometry to CFD gridsAn automated approach for conceptual design, Prog Aerospace

Sci, Vol 47, 2011, pp.5895967Cavagna, L., Ricci., and Travaglini, L.: NeoCASS: An integrated tool for structural sizing, aeroelastic analysis and MDO

at conceptual design level, Prog Aerospace Sci, Vol 47, 2011, pp.6216358Da Ronch, A., Ghoreyshi, M and Badcock, K.J.: On the generation of flight dynamics aerodynamic tables by computa-

tional fluid dynamics, Prog Aerospace Sci, Vol 47, 2011, pp.5976209Goetzendorf-Grabowski, T., Mieszalski, D. and Marcinkiewicz, E.: Stability analysis using SDSA tool, Prog Aerospace

Sci, Vol 47, 2011, pp.636646.10Richardson, T.S, Beaverstock, C., Isikveren, A., Meheri, A., Badcock, K.J. and Da Ronch, A.: Analysis of the Boeing

747-100 using CEASIOM, Prog Aerospace Sci, Vol 47, 2011, pp.660673.11Rizzi, A., Eliasson, P., Goetzendorf-Grabowski, T., Vos, J.B., Zhang, M. and Richardson, T.S., Design of a canard

configured TransCruiser using CEASIOM, Prog Aerospace Sci, Vol 47, 2011, pp.695705.12Richardson, T.S, McFarlane, C., Isikveren, A., Badcock, K.J. and Da Ronch, A.: Analysis of conventional and asymmetric

aircraft configurations using CEASIOM Prog Aerospace Sci, Vol 47, 2011, pp.647659.13Liersch, C.M. and Hepperle, M.: A Distributed Toolbox for Multidisciplinary Preliminary Aircraft Design, CEAS Aero-

nautical Journal, Vol 2, No1-4, 2011, Pages 57-6814Raymer, D.P. Enhancing Aircraft Conceptual Design Using Multi-Disciplinary Optimization, Doctoral Thesis, KTH,

Stockholm 2002.15Rizzi, A., Oppelstrup, J., Zhang, M. and Tomac, M.: Coupling Parametric Aircraft Lofting to CFD & CSM Grid

Generation for Conceptual Design, AIAA Paper-No 2011-160, 2011.16Zhang, M.: Application and Development of the CEASIOM-SUMO-EDGE Suite for Rapid AeroData Assessment of

Aircraft Flying Qualitites, Licentiate Thesis, KTH, Stockholm, 2011.17Amadori, K., ”On Aircraft Conceptual Design - A Framework for Knowledge Based Engineering and Design Optimiza-

tion”, Licentiate Thesis No 1366, Linkping University, Sweden, 200818Amadori, K., Jouannet, C. and Krus, P., A Framework for Aerodynamic and Structural Optimization in Conceptual

Design, June 2007, 25th AIAA Applied Aerodynamics Conference, Miami, FL, USA19Amadori, K., Johansson, B. and Krus, P., Using CAD-Tools and Aerodynamic Codes in a Distributed Conceptual Design

Framework, Jan. 2007, 45th AIAA Aerospace Sciences Meeting and Exhibit, Reno, NV, USA20Nickol, C., Conceptual Design Shop, Presentation to Conceptual Aircraft Design Working Group (CADWG21), Sept.

2004.21Haimes, R. and Drela, M.: On the Construction of Aircraft Conceptual Geometry for High-Fidelity Analysis and Design,

AIAA ASM Conf, Nashville, 2012.22Price, M., Mawhinney, P., Curran, R., Armstrong, C., Murphy, A., A Geometry Centered Process in Airframe Design,

AIAA 5th Aviation, Technology, Integration, and Operations Conference, Sept. 2005, Arlington, VA, USA23Eller, D., Mesh Generation Using sumo and Tetgen, KTH SimSAC Report D2.3-5, Stockholm, 200924Gray, J., Moorey, K.T. and Naylor, B.A.: OpenMDAO: An Open Source Framework for Multidisciplinary Analysis and

Optimization, AIAA Paper 2010-9101, 2010.25Cavagna,L., Riccobene,L., Ricci,S., Berard, A. and Rizzi, A.: A Fast MDO tool for Aeroelastic Optimization in Aircraft

Conceptual Design, AIAA Paper 2008-5911, 2008.26Raymer, D.P. Enhancing Aircraft Conceptual Design Using Multi-Disciplinary Optimization, Doctoral Thesis, KTH,

Stockholm 2002.27Rizzi, A., Oppelstrup, J., Zhang, M. and Tomac, M.: Coupling Parametric Aircraft Lofting to CFD & CSM Grid

Generation for Conceptual Design, AIAA Paper-No 2011-160, 2011.28Zhang, M.: Application and Development of the CEASIOM-SUMO-EDGE Suite for Rapid AeroData Assessment of

Aircraft Flying Qualitites, Licentiate Thesis, KTH, Stockholm, 2011.29Bohnke, D.: Common Parametric Aircraft Configuration Schema CPACS, v1.7, http://software.dlr.de/p/cpacs/home/

(2011).30Bohnke, D.: VAMPzero Conceptual Design for the Needs of MDO, v0.4, http://software.dlr.de/p/vampzero/home/

(2011).31Litz, M., Bachmann, A., Kunde, M.: TIVA XML Interface TIXI, v1.0, http://software.dlr.de/p/tixi/home/ (2011).32Litz, M., Bachmann, A., Kunde, M.: TIVA Geometric Library TIGL, v1.0, http://software.dlr.de/p/tigl/home/ (2011).33Seider, D., Litz, M., Bachmann, A., Kunde, M.: Remote Component Environment,

http://software.dlr.de/p/rcenvironment/home/ (2011).34Gray, J., Moore, K.T., Naylor, B.A.: OpenMDAO: An Open Source Framework for Multidisciplinary Analysis and

Optimization, AIAA/ISSMO Multidisciplinary Analysis Optimization Conference, (2010).35Zill, T., Bohnke, D., Nagel, B., Gollnick, V.: Preliminary Aircraft Design in a Collaborative Multidisciplinary Design

Environment, AIAA Aviation Technology, Integration and Operations Conference, (2011).

19 of 20


36Bohnke, D., Nagel, B., Gollnick, V.: An Approach to Multi-Fidelity in Conceptual Aircraft Design in Distributed DesignEnvironments, IEEE Aerospace Conference, (2011).

37Bohnke, D., Jepsen, J., Pfeiffer, T., Nagel, B., Gollnick, V., Liersch, C.: An Integrated Method for Determiniation of theOswald Factor in a Multi-Fidelity Design Environment, 3rd CEAS Air & Space Conference , (2011).

38Bohnke, D., Reichwein, A., and Rudolph, S., Design Language for Airplane Geometries using the Unified Modeling Lan-guage. ASME Int. Design Engineering Technical Conferences (IDETC) & Computers and Information in Engineering Conference(CIE), (2009).

39Martins, J.R.R.A., Sturdza, P., Alonso, J.J.: The Complex-Step Derivative Approximation, ACM Transactions on Math-ematical Software, (2003)

40Seider, D., Litz, M., Schreiber, A., Fischer, P. M., Gerndt, A.: Open Source Software Framework for Applications inAeronautics and Space, accepted for IEEE Aerospace Conference, (2012)

41Reichwein, A., and Hertkorn, P.: On a model driven approach to engineering design, International Conference on Engi-neering Design, (2007).

42La Rocca, G., and van Tooren, M.: Knowledge-based engineering to support aircraft multidisciplinary design and opti-mization, Journal of Aerospace Engineering 224 pp. 1041-1055, (2010).

43LeDoux, S., Herling, W., Fatta, G. J., and Ratcliff, R.: MDOPT- A Multidisciplinary Design Optimization System UsingHigher order Analysis Codes, AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, (2004).

44Antoine, N., Kroo, I., Wilcox, K., and Barter, G.: A Framework for Aircraft Conceptual Design and EnvironmentalPerformance Studies, 10th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, (2004).

45Alonso, J., LeGresley, P., van der Weide, E., Martins, J., and Reuther, J.: pyMDO: A Framework for High-FidelityMulti-Disciplinary Optimisation, 10th AIAA / ISSMO Multidisciplinary Analysis and Optimization Conference,(2004).

46Pfeiffer, T., Nagel, T., Bhnke, D., Rizzi, A., Voskuijl, M.: Implementation of a Heterogeneous, Variable-Fidelity Frame-work for Flight Mechanics Analysis in Preliminary Aircraft Design, DGLR Congress, (2011)

47Zill, T., Ciampa,P.D. , Nagel, B.: Multidisciplinary Design Optimization in a Collaborative Distributed Aircraft DesignSystem, accepted for AIAA Aerospace Science Meeting, (2012)

48Seider, D., Litz, M., Schreiber, A., Fischer, P. M., Gerndt, A.: Open Source Software Framework for Applications inAeronautics and Space, accepted for IEEE Aerospace Conference, (2012)

49Kroo, I., Multidisciplinary Design Architectures: History and Status, Multidisciplinary Design Consortium, StanfordUniversity, 2006

50Smith, H., and Yarf-Abbasi, A., The MOB Blended Body ReferencAircraft, Multidisciplinary Optimisation for BlendedWing Body Project Technical Rept. MOB/4/CU/Treport/No4, Cranfield Univ., March 2001.

51Qin, N., Vavalle, A. and Le Moigne, A., Spanwise Lift Distribution for Blended Wing Body Aircraft, J. Aircraft, Vol. 42,No. 2, Mar-Apr 2005, pp. 356-365.

52Digital DATCOM. http://www.pdas.com/datcom.htm53Melin, T., TORNADO a Vortex-Lattice MATLAB Implementation for Linear Aerodynamic Wing Applications, Masters

Thesis, Royal Institute of Technology (KTH), Department of Aeronautics, Sweden, December 2000.54dwftools : Potential flow solver, pre- and postprocessing. http://fdl8.flyg.kth.se/dwf/index.html55Eliasson P. A Navier-Stokes Solver for Unstructured Grids., FOI/FFA report FOI-R-0298-SE, FOI, Stockholm, Sweden,

2001. www.foi.se/edge56David Eller, Mesh generation using sumo and tetgen. KTH SimSAC Report D2.3-5, 200957IGES (ANS US PRO/IPO-100-1996) Initial Graphics Exchange Specification IGES 5.3. http://www.uspro.org/

documents/IGES5-3forDownload.pdf58ANSYS ICEM CFD. http://www.ansys.com/products/icemcfd.asp59Amadori, K., ”On Aircraft Conceptual Design - A Framework for Knowledge Based Engineering and Design Optimiza-

tion”, Licentiate Thesis No 1366, Linkping University, Sweden, 200860Amadori, K., Jouannet, C. and Krus, P., A Framework for Aerodynamic and Structural Optimization in Conceptual

Design, June 2007, 25th AIAA Applied Aerodynamics Conference, Miami, FL, USA61Amadori, K., Johansson, B. and Krus, P., Using CAD-Tools and Aerodynamic Codes in a Distributed Conceptual Design

Framework, Jan. 2007, 45th AIAA Aerospace Sciences Meeting and Exhibit, Reno, NV, USA62Tsalgatidou A. and Pilioura T., ”An Overview of Standards and Related Technology in Web Services”, Distributed and

Parallel Databases, 12, 200263Nickol, C., Conceptual Design Shop, Presentation to Conceptual Aircraft Design Working Group (CADWG21), Sept.

2004.64Price, M., Mawhinney, P., Curran, R., Armstrong, C., Murphy, A., A Geometry Centered Process in Airframe Design,

AIAA 5th Aviation, Technology, Integration, and Operations Conference, Sept. 2005, Arlington, VA, USA

20 of 20


Towards a Uni ed Framework using CPACS ... - agile- · PDF fileTowards a Uni ed Framework using CPACS for Geometry Management in Aircraft Design A. Rizzi 1, M. Zhang , B. Nagel 2,

Documents