1. CPACS - Common Parametric Aircraft Configuration Schema
Daniel Böhnke
Air Transportation Systems
German Aerospace Center, (DLR)

2. software.dlr.de

3. Integrated Aircraft Design
Requirements,
Targets
Optimization
Parameterization
Analysis 1
Database
CPACS
Database
Analysis 1
Meta-Modeling
Iteration
Analysis 2
Analysis 2
Analysis n
Performance,
Properties
Analysis n
Sensitivities
Distributed system
Tools of specialists are wrapped
Coupling via central data model CPACS
software.dlr.de

4. Central Model Architecture
Lifting Line
Panel code
Functional Parametrization
Euler
CPACS
Different models with different geometric representations can be
derived from the global CPACS model using the software libraries.
software.dlr.de

5. Common Namespace Reduce No. of interfaces Standardize ► n(n-1)
Product and process
information
Human readable
► n(n-1)
► 2n
software.dlr.de

6. Holism ? Exchange relevant information Intersections of disciplines
Exchange relevant meta-information
Dynamic or static ?
Start with the Requirements
Again we will focus on some key aspects
Only picked the most important requirements
Task 1: Identify relevant information that must be exchanged
Aerodynamic guy is only interested in wing bending
Structure guy is interested in pressure distribution
This is a standard two discipline problem, multidisciplinary projects tend to connect partners that do not know about their interaction
Task 2: If information is exchanged it must be transperent. Meta information should be exchanged as well, you need to know if another discipline has an influence on you model. This can either be:
Static: Mark elements in the model that might be affected
Dynamic: Observe the model and highlight toool interaction with the model. A tool may react dynamically to a model
from: Dream Airplanes, C.W. Miller
software.dlr.de

7. Accessibility Information is always converted
Interaction of discipline and modeling experts
One of the key factors!
Who exchanges information in the central model, who is responible for the interfaces?
There are two kinds of engineers involved: Single Domain Experts, Modeling Experts
Single Domain Experts can benefit from dynamic boundary conditions for his calculations as well as parametric description of his models
Modeling Experts are interested defining common definition for the system, in this respect the aircraft
Design Expert must connect his tool to the model known by the modeling expert, usually conversions, changes of programming languages and ambigouity occur.
Example implicit geometry information. Library must be available to read the data to make sure data is valid
from: Dream Airplanes, C.W. Miller
software.dlr.de

8. Re-usability {…} Automatic model generation Reduce erroneous
Design Loop
Automatic model generation
Reduce erroneous
Generation of derivatives
There is not much sense in setting up a central model and then generate it by hand
Many parts of the model may be generated by analysis tools, but a startup solution is eminently important
As people are setting up parts of the model in disciplines they are no experts for, sources for errors occur easily
from: Dream Airplanes, C.W. Miller
software.dlr.de

9. Abstraction Methods Classification Association Generalization
Distinguish between content and metamodel
Partial-hierarchical models
Complex mechanisms hamper comprehension
Structure in Modeling Languages is generated by Abstraction Methods. These are usually similar to those that can be found in object oriented programming.
Important features to name are Classification, Generalization and Association
It is important to always distinguish between the syntax defined in the meta model and the explicit semantically interpretable content model
All of the models in this work are partial-hierarchical system descriptions
As always simpler systems are desired. Don‘t overdo it
software.dlr.de

10. Common Parametric Aircraft Configuration Schema
MDO aircraft design
Distributed simulation
Collaborative development
software.dlr.de

11. CPACS DLR intern standard based on XML / XSD development in ~2005
specific libraries
Applications in DLR Projects:
Aircraft design
Helicopter design
Engine design
Climate impact
software.dlr.de

12. TIXI – XML Interface Handle CPACS Basic XML functions
Advanced CPACS functions
Arrays
Unique Identifiers …
software.dlr.de

13. TIGL – Geometry Library
Visualization
Calculation
Area
Intersections
Inner <> Outer
Export
STL
IGES
software.dlr.de

14. RCE - Remote Computing Environment
Framework
Integrated Capabilities
Distributed
software.dlr.de

15. References
T. Zill, D. Böhnke, B. Nagel, V. Gollnick, Preliminary Aircraft Design in a Collaborative Multidisciplinary Design Environment, AIAA Aviation Technology, Integration and Operations Conference, 2011
D. Böhnke, B. Nagel, V. Gollnick, An Approach to Multi-Fidelity in Conceptual Aircraft Design in Distributed Design Environments, IEEE Aerospace Conference, 2011
D. Böhnke, M. Litz, B. Nagel, S. Rudolph, Evaluation of Modeling Languages for Preliminary Airplane Design in Multidisciplinary Design Environments, DGLR Congress, 2010
C. Liersch, M. Hepperle, A Unified Approach for Multidisciplinary Aircraft Design, CEAS European Air and Space Conference, 2009
A. Koch, B. Nagel, V. Gollnick, K. Dahlmann, V. Grewe, B. Kärcher, U. Schumann, Integrated analysis and design environment for a climate compatible air transport system, AIAA Aviation Technology, Integration and Operations Conference, 2009
software.dlr.de

16. „All models are wrong, but some are useful.“ George E.P. Box
software.dlr.de

17. Collaborating DLR Institutes
AE Aeroelasticity
AS Aerodynamics and Flow Technology
AT Propulsion Technology
BK Structures and Design
FA Composite Structures and Adaptive Systems
FL Flight Guidance
FT Flight Systems
FW Air Transport and Airport Research
HR Microwaves and Radar
LY Air Transportation Systems
ME Aerospace Medicine
MF Remote Sensing Technology
PA Atmospheric Physics
RM Robotics and Mechatronics
RY Space Systems
SC Simulation and Software Technology
software.dlr.de