Towards a Unified Framework using CPACS for

Transcription

Towards a Unified Framework using CPACS for
Geometry Management in Aircraft Design
A. Rizzi1 , M. Zhang1 , B. Nagel2 , D. Boehnke2 and P. Saquet1
1
Royal Institute of Technology (KTH), 10044 Stockholm, Sweden
2
German Aerospace Center (DLR), 21079 Hamburg, Germany
The performance requirements for the next generations of airliners are stringent and
require invention and design of unconventional configurations departing from the classical
Cayley functional decomposition. The break with tradition calls for higher fidelity physicsbased predictions of performance early on in the project. The paper makes the case for a
unified, open, data-centric software environment for aircraft design and describes the merge
of the CEASIOM conceptual design software package, developed by a number of partners
including KTH, with the CPACS formalized data management system developed at DLR.
The system provides multi-fidelity and multi-disciplinary analysis capabilities for concurrent design by geographically distributed expert teams. The data-centric architecture uses
the CPACS schema and access mechanisms for management of design data across all disciplines and fidelity levels. This makes the system extensible and mitigates the problems
encountered in handing over the model to later design phases. The concepts have been
tested by interfacing external modules to CEASIOM/CPACS through a graphical CPACS
XML editor, the ACbuilder gateway. Results of comparative analyses on models imported
in 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 experience of joining forces via CPACS with DLR is altogether positive and further in-house
development of software for aircraft performance prediction and design by the CEASIOM
team will use the CPACS system.
I.
A.
Introduction & Overview
Classical Conceptual-Preliminary Design
Present trends in aircraft design towards lighter more flexible airframes flying expanded flight envelopes with
augmented stability call for more tightly-coupled multi-disciplinary design procedures to efficiently evaluate
the flying qualities of the aero-servo-elastic aircraft. Numerous textbooks1–4 explain in detail how the entire
aircraft design process can be categorized into three distinct phases, each with its own distinct objectives
and 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, usually
change 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 determined by its mission. The tools for the search are provided by mathematical modeling (usually empirically
based) to find a quantified description of the aircraft concept and its size, weight, and performance. The first
step sizes the aircraft, i.e calculates the aircraft takeoff gross weight, empty weight and fuel weight so that it
achieves the range called for in the design specification. This results in a quantification of design parameters
that 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 variables which then determine the capabilities of the design and compare them to the design requirements. This
process can be repeated with an increasing level of detail involving trade studies to evolve the design towards
its 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 balanced
design candidate, which conforms to airworthiness and operational requirements. Because the analysis done
here 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 and
models, and it is primarily uni-directional. Not least is the mismatch in the geometry description. Lofted
surfaces 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 into
this process, allowing two-way flow up and down the conceptual-preliminary phases enabled by automatic
geometry 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 weight
estimations, noise, emissions, stability & control and geometry generation), each with three rows of fidelity
from low to high, roughly corresponding to the three design phases mentioned above, as a means to clarify
this complex activity of aircraft design. For each entry point in the table there are one or more diverse
analysis (computational) tools suitable for its discipline. As the design work proceeds, data must travel
across the disciplines and upwards to the increasing fidelity levels. Nichol has identified ‘gaps’ between the
tools used at different fidelity levels that hinder this information flow, and thus the efficiency of the design
process. The dis-connect in the geometry description mentioned above is one example, which he calls the gap
between lofting at the low level and ‘big iron’ CAD at the high level. Rizzi et al.27 describe how a ‘custom
CAD’ solution with automatic meshing can fill that gap, and the Nickol table has been edited to indicate
this, 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 this
level require grids to carry out their physics-based analysis. Other researchers have found other solutions
to filling the gap. Amadori et al.59–61 has developed templates that work with CATIA from the start, and
Haimes and Drela21 use openCASCADE in a similar way. Providing the connection between lofting and
CFD or CSM grids improves both the dataflow and the workflow, and hence the efficiency and agility of the
design 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 grid
generations was carried out in the CEASIOM design environment. The CEASIOM software system developed
in the EU-funded collaborative research project SimSAC5 generates stability and control data for preliminary
aircraft design using a choice of numerical methods of varying fidelity. The system aims at automation of
the 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 (Computational
Fluid Dynamics) and Computational Structural Mechanics analyses need to be created and finally, the
solver parameter settings must be adapted to reliably perform multiple solutions from which the tables
are 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 engineering
framework software is needed to link together the diverse analytical tools in Nichol’s table and launch them
from 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 a
working but rather ad hoc fashion. However, when Rizzi et al.27 extended its functionality by interfacing
CEASIOM with Raymer’s RDS software,26 it became evident that the ad hoc XML dataset was not sufficiently general and not well enough structured to offer the extensibility of the system desired for continued
development.
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 efficiently as possible independently from physical barriers. Since 2005 DLR is developing a network of analysis
capabilities. The strategy is to connect disciplinary experts and their respective analysis modules to create
design processes. The analysis modules coded as computer programs on various platforms remain within
the domain of the disciplinary experts. Two core technologies enable this collaboration within DLR. The
Remote Component Environment (RCE) is an integration framework that handles network communication
and data exchange among analysis modules as well as process control. The data is exchanged in the form of
the Common Parametric Aircraft Configuration Schema (CPACS). In this data-centric setup the number of
interfaces decreases and effective communication can be established. CPACS is based on XML technologies
making it human readable and computer processable. It is designed to accommodate data for numerous
disciplines involved in the conceptual as well as preliminary design phase and is seeing application even in
high-fidelity analysis. It is comprehensive and covers all the disciplines in Nickol’s table and even additional
ones added by Price et al.64
This paper describes how CEASIOM is adopting the CPACS data-centric XML standard, and presents
several 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 design
environment and explains how CEASIOM is one such example of a system consisting of a data-structure, a
toolset and software to control the design process and to carry out the workflow. An explanation follows
on how the CPACS data structure provides a more unified geometry management in CEASIOM. A detailed
description is given how its geometry module ACbuilder has been re-constructed to incorporate the CPACS
data structure, and in effect has become an XML-editor to the CPACS data. Then another section looks
at the benefits that accrue from this unified management, namely how it eases the integration of external
components into CEASIOM, namely the RDS software and the VAMPzero36 software. Two example processes
are worked through and illustrate the path from low to high fidelity geometry. These examples demonstrate
that the gap in the Nichol table for geometry has in fact been filled and that the central dataset CPACS
further unifies CEASIOM and facilitates extension of the toolset. The paper concludes with some thoughts
for future developments with the DLR software packages becoming open source, similar to the openMDAO
network.
II.
Anatomy of Unified Design Environment
A design environment enables engineers to cooperate by means of structured and mostly autonomous
exchange of information. This exchange is mainly comprised by interfaces between analysis modules but also
encompasses process and optimization knowledge.
For a single domain expert boundary conditions in his discipline become dynamic while connecting to
a design environment, as for example structural engineers obtain access to various aerodynamic analysis
modules. It should be noted that a design environment also needs to feature the exchange of information
between designers as fully automatic design processes remain utopia. Efficient methods for collaborative
design and debugging are a necessity.
Although many valuable design tools exist in the various disciplines, it turns out that bringing them
together 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 software
engineering and Reichwein, et al.41 link this expression to engineering design. The elementary idea remains
unchanged, as all design models need to be deduced from the central model (common namespace). Multidisciplinary frameworks to be named include the Design Engineering Engine (DEE) from TU Delft42 as well as
the Multidisciplinary Design Optimization System (MDOPT).43 The PASS module is coupled with modules
for environmental analyses in the Collaborative Application Framework for Engineering (CAFFE) as shown
by Antoine, et al.44 In their study Alonso, et al.45 present a framework for high-fidelity applications coded
in 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. Communication
can only be effective if a common language is spoken. Secondly, as the design environment is distributed an
integration framework is necessary. The integration framework enables designers to couple several analysis
modules, the third item of the design environment, whereas all analysis modules are linked to the same
common namespace.
The integration framework consists of two parts: Firstly, the editor and visual environment for the
creation, modification and access control of analysis tool chains. This graphical user interface provides some
kind of workspace and enables process designers to interact with analysis modules. This encompasses coupling
of modules as well as interactions with central model representations, regardless of whether textual, structural
or 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 central
data 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 the
flexibility 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 analysis
routine but should preferably be able to run in batch mode. Their inputs and outputs are usually linked to
the common namespace via wrapper components that handle the translation. In this way also proprietary
and closed source analysis codes can be coupled to the design environment. Along with an analysis module a
detailed 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 is
established by using the Common Parametric Aircraft Configuration Schema (CPACS). A Framework that is
in use at DLR together with CPACS is the Remote Component Environment(RCE). Several analysis modules
from 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 the
exchange of information on the level of preliminary design. The system is in operational use at all aeronautical
institutes of DLR and has been extended for civil and military aircraft, rotorcraft, jet engines and entire air
transportation systems.
The data-format is based on XML technology. An assessment of alternatives for modeling languages for
preliminary aircraft design is reported in Boehnke et al.38 Ongoing works include the documentation of the
schema that described the syntactic definition on CPACS. Additionally, some getting started documents are
being prepared. Some supportive libraries handling XML and geometric data are available and are described
in 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 to
multi-fidelity using CPACS is outlined by Boehnke.37 Pfeiffer46 implemented a chain of analysis modules
that coupled works of TU Delft, KTH Stockholm and DLR.
CPACS holds detailed interpretable type definitions for semantic entities from the air transportation
system. 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 along
with the dataset and carries further information, such as parameters for numerical methods, to the analysis
modules. 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 data
N to N interfaces , b) with unified data (red pentagon) N to 1 interfaces.
B.
1.
Frameworks
Chameleon@RCE
In preliminary aircraft design multi-disciplinary cooperation plays a key role. In DLR automated process
chains containing tools of various disciplines are used for global optimization in the preliminary design
phase. Such process chains make sure that the involved tools are executed automatically in consideration
of their dependencies. Required user interaction is reduced. The fact that DLR is spread over several sites
and institutes requires a distributed design environment. Not only different software architectures but also
availability of computational power are issues to address.
To meet the requirements of preliminary aircraft design in DLR we devised an integration concept called
Chameleon. 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 concept 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 interfaces as depicted in Figure 5. Chameleon in conjunction with RCE forms DLR’s simulation framework for
preliminary 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 and
the 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 science
by promoting collaboration and cooperation among industry, government, and academia through the use of
open source tools.
An overview of the hierarchy of software elements is given here. In OpenMDAO, a computational task
is represented by a system of objects called Components with inputs and outputs. A Component performs
a calculation when executed, and the output of one Component can be passed as input to another. Native
Python 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 of
Components controlled by a Driver. Since both the Assembly and Driver classes are sub-classes of Component, they can have their own inputs and outputs and can be included in models with other Components
to build ever more complex Components. This capability allows e.g. a turbine engine simulation in an Assembly which is used as a Component in an aircraft simulation. substituted to modify the function provide
a place where users additional calculations. Even more intricate processes can be implemented by WorkFlows, objects in the iteration hierarchy that can dynamically determine the execution order for a group of
Components.
Data is passed between Components using I/O-traits, i.e. variables to hold the output of one Component
when required as an input to another Component. Python is a weakly typed language, so the Enthought
Traits package was used to create a set of strongly typed variable classes to provide more stringent type and
unit checking between Components.
3.
The CEASIOM Hub
The CEASIOM framework functions are performed by the Hub with its main GUI shown in Fig. 7. The
process chains are executed by the engineer with automation built into the generation of aero-data tables by
smart 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 with
the 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 optimization
loops from geometry to aero-data have been carried out (ciet Berard Cavagns 2007 or so) such as selecting
wing planform and twist distribution for minimizing wave drag or drag due to lift. However, the current
framework does not provide for definition of new computational chains and therefore is less well suited for
general 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 And
Control Characteristics for Use in Conceptual Design), is a framework tool for conceptual aircraft design
that 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 CEASIOM
framework offers possible ways to increase the concurrency and agility of the classical conceptual-preliminary
process. 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 to
CAD via IGES
2. Aerodynamic module AMB-CFD8
A replacement of current handbook aerodynamic methods with new adaptable-fidelity modules referred
to as tier I (a. and b.) and tier II (c.):
a. Steady and unsteady TORNADO vortex-lattice code (VLM) for low-speed aerodynamics and
aero-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 extreme
flight conditions
3. Stability and Control module S&C9
A simulation and dynamic stability and control analyzer and flying-quality assessor. Test flights with
six 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 the
CEASIOM software
Stability Augmentation System (SAS) and a LQR based flight control system (FCS) package are among
the major functionalities of this module.
4. Aeroelastic module NeoCASS7
Quasi-analytical structural analysis methods that support aero-elastic problem formulation and solution
5. Flight Control System design module FCSDT10
A designer toolkit for flight control-law formulation, simulation and technical decision support, permitting flight control system design philosophy and architecture to be coupled in early in the conceptual
design phase
CEASIOM is meant to support engineers in the conceptual design process of the aircraft, with emphasis
on the improved prediction of stability and control properties achieved by higher-fidelity methods than
found in contemporary aircraft design tools. Moreover CEASIOM integrates into one application the main
design 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 data
exchange by a common format, and extended to a design system by having a set of defined computational
chains to be used for sizing and optimization. The data format must support also definition of the chain
as well as module-specific meta-data such as tolerances, method selectors, etc. Automatic execution of the
computational 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-fidelity
software tool for aircraft design including aero-elasticity and stability and control assessments. CEASIOM
requires as input an initial layout as baseline configuration sized to the mission profiles by specification of
the O(10) parameters used in the pre-design process. Then it refines this design in the concept design stage
and 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 the
CEASIOM analysis and simulation modules, and increases the fidelity of the predictions. The information
generated suffices for six degree of freedom engineering flight simulation. It is also sufficient to construct a
wind-tunnel model, comparable in quality to what would be designed in the traditional approach to stability
and control design. Multi-module software for collaborative working needs a common data format, and the
system components are integrated by the CEASIOM XML file exchange. The CEASIOM geometry definition
is hierarchical, but somewhat ad hoc and limited, e.g., by not allowing indexed instantiation of components
and this hampers further development. Flow prediction by Euler flow models, necessary for transonic aeroforce 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 twist
variations of modern transonic wings. Similarly, unconventional configurations such as blended wing-bodies
cannot 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 these
issues. The CPACS data format manages all geometrical configurations, enables the development of multifidelity structural analysis modules, and enables loosely coupled optimization procedures to be applied to
problems which exercise several analysis modules combined into computational chains. The XML / XSD
technology which provides validation of data files mitigates the risk of creating inconsistent data sets by
inadequate 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 the
conceptual design packages RDS1 and VAMPzero36 have been established to shed light on issues of geometry
translation, 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. In
general, 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 points
on cross-sections just like sumo, and for VAMPzero because it already uses CPACS. The RDS link was used
to 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 of
the 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 functionality
is offered also by generic ”full-scale” CAD systems linked to high-end commercial mesh generators, such
as CATIA plus ICEM-CFD.58 As discussed in? and27 we have chosen to work with customized in-house
and open source software instead. Although the link to generic CAD systems has not been explored in
the 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 possibly
structural analysis and sizing, using tools like those developed by DLR. The CEASIOM model actually covers
also internal geometry such as spar and fuel tank location, payload compartment, and aero-force tables for
flight simulation, which should also be exported. CPACS is designed to support also this kind of data, and
could 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 interactive
geometry 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 mastermodel concept where components from a library are selected, given their correct shapes, and subsequently
put together to form a water-tight meshable surface model, fig. hierarchic. The obvious alternative is to
start 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 like
overlapping 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 was
closed by pushing the tail a fraction of an inch down. It should be noted that sumo performs automatic
CAD repair by closing wingtips and fuselage noses and tails, as necessary. Such functions are enabled by
the 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 definitions
within the format. A short overview on the modeling of outer geometries is given in this section. The inner
geometry (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 optimization
loops. The conversion from the parametric model to a full CAD model is done by the geometric library
TIGL.32 TIGL is based on the openCascade kernel and offers functions related to CPACS, e.g. find x,y,z
coordinates on a wing from span and chordwise coordinates. Additionally, TIGL offers export functionalities
to other formats such as IGES and STL.
Figure 9 displays the conversion process from the parametric CPACS model to the wing geometry. The
process is similar for fuselage geometries. Profiles are defined as a list of points. Each element can carry
a 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 via
scaling, 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 fact
that 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 the
model. On the other hand a use-case might focus more on parametric studies where the full parametric
model is exploited. TIGL will interpret the information accordingly. As analysis modules couple to CPACS
via 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 Java
code offering faster graphics. As a consequence, the software can be extended by engineers who are not Java
experts, because the connection between the two parts is uni-directional: all the data go from Matlab to
Java, 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, and
one 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 corresponding
to the chosen menu, and also functions to manipulate the rendering window . The Java window serves
only 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 external
and internal geometry, fuel tanks, weights breakdown and balance, technology definition, etc.. The restriction
on the order of assembly is inherited from the model hierarchy. Components on the same level of the hierarchy
can 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 from
scratch, 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 construction
in Fig. 12, a Horizon 1100, is made of a fuselage, a wing, a horizontal tail, a vertical tail, and a pair of open
pusher-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/to
CPACS 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 configuration
is a tree structure and one option is to let child components inherit global coordinates from parents, and be
sized relative to their dimensions. This is very natural for e.g. control surfaces which are children of a lifting
surface. Another option is to size the components absolutely and position them in the global coordinate
system. 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 the
highlighted component, a fuselage.
When a template, complete aircraft, or element has been imported, its Matlab struct is compiled. When
the user changes parameters or adds elements, the struct is updated and the right method corresponding to
this change is activated. This function also creates the surface as a 2-D array of (x, y, z)-coordinates and
transfers the coordinate array to the Java renderer to update the view. Using the parent/child relations, the
program 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 external
geometry alone. For higher fidelity structural models, such as in Fig. 13(a), key spar and rib locations must
be supplied Fig. 13(b). Also fuel tank locations must be provided to allow precise balance prediction as
necessary 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 positions
them on the wing planform, see Fig. 14 but does not consider details of hinges, gaps, or flap tracks although
such data can be provided in the CPACS file.
Currently, the various CFD solvers use the control surface definitions in different ways. The CEASIOM
vortex lattice module physically deflects the part of the wing planform marked as control surfaces. The Euler
solver uses the transpiration approximation and does not change the mesh in response to deflection but only
the 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, namely
the VAMPzero conceptual design code for initial sizing and the RDS Integrated Aircraft Design and Analysis
code.
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 environment.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 approaches
following a procedural calculation process. Giving feedback about the calculation to the user is one of the
key features of VAMPzero. It tracks and displays the dependencies between parameters, e.g. wing area
is a function of aspect-ratio and span. Furthermore, it is capable of determining the sensitivities of these
dependencies via complex step derivative approximation.39
As VAMPzero is a supportive analysis module for CPACS, it has to handle two tasks: initialization
and integration. Obviously, a design process needs to go through requirements definition and conceptual
design before preliminary methods can be applied. VAMPzero handles the conceptual design stage but also
initializes the CPACS data set so that higher level analysis modules can be triggered. It creates geometries
following a knowledge-based engineering approach and writes necessary process data like for example toolspecific 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 need
to 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 these
results. 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 subsequent
rapid evolution to a preferred baseline,27 but it does not support production-quality lofting, so its model
cannot be meshed without additional refinement. The key to early computational analysis is a rapid-meshing
procedure which can take such a rough CAD model and quickly create a usable computational grid, termed
a “meshable” or “solid” model. The CAD model might not qualify as a “solid model”, may have component
intersections which are ill-defined or worse, might have gaps in the surfaces, and quite likely is not even
mathematically “watertight”. RDS stores design geometry in its own unique format27 as a collection of
components 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) shows
the 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 to
a meshable model and a grid for CFD computations and a structural model for flutter analysis in preliminary
design.
The inter-disciplinary couplings to CEASIOM via ”wrapping” translates the geometrical information. The
first one, a conventional A320-like configuration, is an easy test of the wrapper because the mapping of the
CEASIOM XML to CPACS XML is good. The second one, an unconventional blended-wing-body (BWB50 ), is
harder because of the CEASIOM XML limitations in fuselage and wing sections. The RDS A320-look-alike
is analyzed for drag divergence at transonic speed, and the VAMPzero A320 is tested for flutter. The
CEASIOM BWB model lacks in geometry fidelity, as explained above, and Euler flow calculations on the
model 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. The
volume mesh is generated with the tetrahedral mesh generator TetGen. The CEASIOM translator reads the
DSN 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/modification
features in the DSN definition was a significant hurdle. Figure 16 shows the VAMPZero and RDS-sumoCEASIOM 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 handoff
from conceptual to preliminary design. Top, VAMPZero blended wing-body, and bottom, RDS A320-lookalike.
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 sumo
model to check that elevator trim angles were reasonable. The trim angles of attack are small, and lift
and drag coefficients were calculated for M∞ from 0.1 to 0.9, as well as the transonic cruise efficiency
indicator M L/D, see Figure 19(a). Drag divergence onset is for lower Mach-number than expected, and this
discrepancy with reality was traced to the airfoil shape. The chosen airfoil, see Fig 19(b), is sub-optimal for
transonic operation. No airfoil is needed in the RDS analysis because it is empirical, but an airfoil must be
specified to generate the surface mesh. A need like this for more data is one aspect of the handoff problem.
B.
1.
VAMPzero-CEASIOM Data/Workflow: A320 and BWB Lofts to Grids, CFD & CSM
VAMPzero-sumo Handoff
The demonstration performed here is to take the CPACS XML file created by VAMPzero and input it into
the ACbuilder, which via the wrapper can read and work with it. Figure 17(a) shows that ACbuilder correctly
describes the geometry for the A320-like configuration, so it passes the ‘easy’ test. VAMPzero does not
model control surfaces so they were added in the ACbuilder. However, because the ACbuilder does not do as
well for the BWB configuration because of the limitations on wing and fuselage sections in the CEASIOM
XML, 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) BWB
configuration.
2.
sumo-CFD & CSM Analysis
The previous demonstration determined that CEASIOM has interpreted the CPACS XML correctly for the
A320. So the next check proceeds with this configuration to sumo to generate a mesh around it and carry
out an Euler-solution analysis for transonic cruise at M∞ = 0.8, as shown in Fig 18(a). The third test
analyzes its flutter characteristics, Fig 18(b). The final check repeats the above calculations for the BWB
configuration. sumo generates a mesh around the BWB and then an Euler-solution analysis for transonic
cruise 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 the
performance that can be obtained for a conventional configuration, and designs accordingly. But there are
no 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 body
where the engines would be installed. In this case the conceptual design should have used higher-fidelity
analysis already from the start.51
VI.
Conclusions: Collaborative Aircraft Design Enabled by Open
Data-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-like
configuration: a)Cp distribution computed in Euler solution, M∞ = 0.8, α = −2◦ , b) Unstable in-plane
bending, flutter mode 11, 6.38hz
(a)
(b)
Figure 19. CEASIOM prediction of RDS A320 look-a-like cruise efficiency: a) wave drag computed in Euler
solution , 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 new
designs.
Unconventional concepts usually require integrated designs. The classical functional decomposition of
wing-body-tail where wing generates lift, body accommodates payload, and tail ensures stability & control
will 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 communication
between 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 consists
of not only a distributed network of tools but also of a network of design teams. In this scenario no super
users exist. The knowledge to handle the system is distributed among designers. Nevertheless, the designers
remain the holders of core capabilities in certain disciplines.
To face these challenges we propose an open data centric design environment consisting of the three key
components already mentioned in this paper: a common namespace for effective communication, analysis
modules coupled to this namespace, and an integration framework for process control. Three key arguments
for 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 Euler
solution , 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 way
communication between experts can be as efficient as possible and is not concentrated on transforming data
from one format to another.
Additionally, data handling should ensure that data that is passed from one analysis module to another
is interpreted in a similar way. The compliance of data minimizes the chance of misinterpretation. With
a central data model like CPACS29 the first step towards compliance is an extended documentation. All
parameters are described in more detail in the central documentation. Furthermore, overall libraries are
being developed for CPACS that aid in the interpretation and hence ensure further compliance. TIXI31 is
a general XML interface that is based on libxml2 and extended to interpret for example arrays and other
complex data structures in CPACS. TIGL32 is a library that handles the geometric data in CPACS. It
transfers the parametric description to a full CAD model (in OpenCascade) and gives detailed information
on this geometry.
Finally, different design problems relate to different levels of fidelity. This tradeoff between computational
cost 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 another
point vortex-lattice methods are sufficient. A central model ensures simple exchangeability of analysis
modules. Due to the fact that CPACS is based on a hierarchic structure it is also possible to define different
levels 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. In
our opinion an open-source approach is the only one suitable for a future design environment. As can be
seen from Gray et al.,34 the openMDAO framework follows a similar approach. Note that such a datacentric open framework with documented data format is open also also to proprietary analysis modules and
process control software such as ModelCenter, ISight, etc. The framework allows even processes which use
data which is visible only to a certain analysis module, but hidden from general view, and can support
also business models relying on non-disclosure of certain data. Research is the key task for the framework
therefore anyone should be able to implement adaptations to design problems. Additionally, cost should not
be an impediment factor in collaborative aircraft design.
We believe a strong case can be made for the data-centric model with documented data formats. CEASIOM was the first freely available tool-suite for aircraft design following a distributed approach. Our current
research combines CPACS and CEASIOM. CPACS in combination with the supporting libraries and DLR’s
integration framework RCE33 will be officially released to the public on the 15th of March in 2012. Additionally, the conceptual design tool VAMPzero is also available under open source license. Our own future
development will be incorporated in this open environment.
18 of 20
References
1 Raymer,
D. Aircraft Design: A Conceptual Approach, 4th ed., AIAA Education Series (2006).
J. Airplane Design. DARCorporation I-VII (1989).
3 Torenbeek, E., Synthesis of Subsonic Airplane Design, Delft Univ Press, 1982.
4 Kundu, A. K. Aircraft Design. Cambridge Aerospace Series (2010).
5 Rizzi, 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)
6 Tomac, M. and Eller, D.: From geometry to CFD gridsAn automated approach for conceptual design, Prog Aerospace
Sci, Vol 47, 2011, pp.589596
7 Cavagna, 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.621635
8 Da Ronch, A., Ghoreyshi, M and Badcock, K.J.: On the generation of flight dynamics aerodynamic tables by computational fluid dynamics, Prog Aerospace Sci, Vol 47, 2011, pp.597620
9 Goetzendorf-Grabowski, T., Mieszalski, D. and Marcinkiewicz, E.: Stability analysis using SDSA tool, Prog Aerospace
Sci, Vol 47, 2011, pp.636646.
10 Richardson, 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.
11 Rizzi, 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.
12 Richardson, 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.
13 Liersch, C.M. and Hepperle, M.: A Distributed Toolbox for Multidisciplinary Preliminary Aircraft Design, CEAS Aeronautical Journal, Vol 2, No1-4, 2011, Pages 57-68
14 Raymer, D.P. Enhancing Aircraft Conceptual Design Using Multi-Disciplinary Optimization, Doctoral Thesis, KTH,
Stockholm 2002.
15 Rizzi, 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.
16 Zhang, M.: Application and Development of the CEASIOM-SUMO-EDGE Suite for Rapid AeroData Assessment of
Aircraft Flying Qualitites, Licentiate Thesis, KTH, Stockholm, 2011.
17 Amadori, K., ”On Aircraft Conceptual Design - A Framework for Knowledge Based Engineering and Design Optimization”, Licentiate Thesis No 1366, Linkping University, Sweden, 2008
18 Amadori, 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, USA
19 Amadori, 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, USA
20 Nickol, C., Conceptual Design Shop, Presentation to Conceptual Aircraft Design Working Group (CADWG21), Sept.
2004.
21 Haimes, R. and Drela, M.: On the Construction of Aircraft Conceptual Geometry for High-Fidelity Analysis and Design,
AIAA ASM Conf, Nashville, 2012.
22 Price, 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
23 Eller, D., Mesh Generation Using sumo and Tetgen, KTH SimSAC Report D2.3-5, Stockholm, 2009
24 Gray, J., Moorey, K.T. and Naylor, B.A.: OpenMDAO: An Open Source Framework for Multidisciplinary Analysis and
Optimization, AIAA Paper 2010-9101, 2010.
25 Cavagna,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.
26 Raymer, D.P. Enhancing Aircraft Conceptual Design Using Multi-Disciplinary Optimization, Doctoral Thesis, KTH,
Stockholm 2002.
27 Rizzi, 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.
28 Zhang, M.: Application and Development of the CEASIOM-SUMO-EDGE Suite for Rapid AeroData Assessment of
Aircraft Flying Qualitites, Licentiate Thesis, KTH, Stockholm, 2011.
29 Böhnke, D.: Common Parametric Aircraft Configuration Schema CPACS, v1.7, http://software.dlr.de/p/cpacs/home/
(2011).
30 Böhnke, D.: VAMPzero Conceptual Design for the Needs of MDO, v0.4, http://software.dlr.de/p/vampzero/home/
(2011).
31 Litz, M., Bachmann, A., Kunde, M.: TIVA XML Interface TIXI, v1.0, http://software.dlr.de/p/tixi/home/ (2011).
32 Litz, M., Bachmann, A., Kunde, M.: TIVA Geometric Library TIGL, v1.0, http://software.dlr.de/p/tigl/home/ (2011).
33 Seider,
D.,
Litz,
M.,
Bachmann,
A.,
Kunde,
M.:
Remote
Component
Environment,
http://software.dlr.de/p/rcenvironment/home/ (2011).
34 Gray, J., Moore, K.T., Naylor, B.A.: OpenMDAO: An Open Source Framework for Multidisciplinary Analysis and
Optimization, AIAA/ISSMO Multidisciplinary Analysis Optimization Conference, (2010).
35 Zill, T., Böhnke, D., Nagel, B., Gollnick, V.: Preliminary Aircraft Design in a Collaborative Multidisciplinary Design
Environment, AIAA Aviation Technology, Integration and Operations Conference, (2011).
2 Roskam,
19 of 20
36 Böhnke, D., Nagel, B., Gollnick, V.: An Approach to Multi-Fidelity in Conceptual Aircraft Design in Distributed Design
Environments, IEEE Aerospace Conference, (2011).
37 Böhnke, D., Jepsen, J., Pfeiffer, T., Nagel, B., Gollnick, V., Liersch, C.: An Integrated Method for Determiniation of the
Oswald Factor in a Multi-Fidelity Design Environment, 3rd CEAS Air & Space Conference , (2011).
38 Böhnke, D., Reichwein, A., and Rudolph, S., Design Language for Airplane Geometries using the Unified Modeling Language. ASME Int. Design Engineering Technical Conferences (IDETC) & Computers and Information in Engineering Conference
(CIE), (2009).
39 Martins, J.R.R.A., Sturdza, P., Alonso, J.J.: The Complex-Step Derivative Approximation, ACM Transactions on Mathematical Software, (2003)
40 Seider, D., Litz, M., Schreiber, A., Fischer, P. M., Gerndt, A.: Open Source Software Framework for Applications in
Aeronautics and Space, accepted for IEEE Aerospace Conference, (2012)
41 Reichwein, A., and Hertkorn, P.: On a model driven approach to engineering design, International Conference on Engineering Design, (2007).
42 La Rocca, G., and van Tooren, M.: Knowledge-based engineering to support aircraft multidisciplinary design and optimization, Journal of Aerospace Engineering 224 pp. 1041-1055, (2010).
43 LeDoux, S., Herling, W., Fatta, G. J., and Ratcliff, R.: MDOPT- A Multidisciplinary Design Optimization System Using
Higher order Analysis Codes, AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, (2004).
44 Antoine, N., Kroo, I., Wilcox, K., and Barter, G.: A Framework for Aircraft Conceptual Design and Environmental
Performance Studies, 10th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, (2004).
45 Alonso, J., LeGresley, P., van der Weide, E., Martins, J., and Reuther, J.: pyMDO: A Framework for High-Fidelity
Multi-Disciplinary Optimisation, 10th AIAA / ISSMO Multidisciplinary Analysis and Optimization Conference,(2004).
46 Pfeiffer, T., Nagel, T., Bhnke, D., Rizzi, A., Voskuijl, M.: Implementation of a Heterogeneous, Variable-Fidelity Framework for Flight Mechanics Analysis in Preliminary Aircraft Design, DGLR Congress, (2011)
47 Zill, T., Ciampa,P.D. , Nagel, B.: Multidisciplinary Design Optimization in a Collaborative Distributed Aircraft Design
System, accepted for AIAA Aerospace Science Meeting, (2012)
48 Seider, D., Litz, M., Schreiber, A., Fischer, P. M., Gerndt, A.: Open Source Software Framework for Applications in
Aeronautics and Space, accepted for IEEE Aerospace Conference, (2012)
49 Kroo, I., Multidisciplinary Design Architectures: History and Status, Multidisciplinary Design Consortium, Stanford
University, 2006
50 Smith, H., and Yarf-Abbasi, A., The MOB Blended Body ReferencAircraft, Multidisciplinary Optimisation for Blended
Wing Body Project Technical Rept. MOB/4/CU/Treport/No4, Cranfield Univ., March 2001.
51 Qin, 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.
52 Digital DATCOM. http://www.pdas.com/datcom.htm
53 Melin, 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.
54 dwftools : Potential flow solver, pre- and postprocessing. http://fdl8.flyg.kth.se/dwf/index.html
55 Eliasson P. A Navier-Stokes Solver for Unstructured Grids., FOI/FFA report FOI-R-0298-SE, FOI, Stockholm, Sweden,
2001. www.foi.se/edge
56 David Eller, Mesh generation using sumo and tetgen. KTH SimSAC Report D2.3-5, 2009
57 IGES (ANS US PRO/IPO-100-1996) Initial Graphics Exchange Specification IGES 5.3. http://www.uspro.org/
documents/IGES5-3forDownload.pdf
58 ANSYS ICEM CFD. http://www.ansys.com/products/icemcfd.asp
59 Amadori, K., ”On Aircraft Conceptual Design - A Framework for Knowledge Based Engineering and Design Optimization”, Licentiate Thesis No 1366, Linkping University, Sweden, 2008
60 Amadori, 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, USA
61 Amadori, 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, USA
62 Tsalgatidou A. and Pilioura T., ”An Overview of Standards and Related Technology in Web Services”, Distributed and
Parallel Databases, 12, 2002
63 Nickol, C., Conceptual Design Shop, Presentation to Conceptual Aircraft Design Working Group (CADWG21), Sept.
2004.
64 Price, 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 Unified Framework using CPACS for

Transcription

Similar documents

Wherever you are. Whenever you need it.

CPACS Flier and full Program

proudly offers FOR SALE 1976 Beechcraft Baron 58

North Atlantic MNPS Airspace Map

Fokker DRI Tri-plane - Airdrome Aeroplanes

McDonnell Douglas (Boeing) F-15C Eagle s/n 80-014

Krzysztof Piwek

KING AIR C90GTx - Beechcraft

NEW GLASS COCKPIT FOR SF 260 AIRCRAFT

the tellurometer mrd1 system

1965 American Champion – 7ECA Citabria