RECENT ADVANCES IN ESTABLISHING A COMMON LANGUAGE FORAIRCRAFT DESIGN WITH CPACS

Marko Alder(1) and Erwin Moerland(2) and Jonas Jepsen(3) and Bjorn Nagel(4)

(1),(2),(3),(4)Institute of System Architectures in Aeronautics, German Aerospace Center (DLR)Hein-Saß-Weg 22, 21129 Hamburg (Germany)

(1)marko.alder@dlr.de, (2)erwin.moerland@dlr.de, (3)jonas.jepsen@dlr.de, (4)bjoern.nagel@dlr.de

ABSTRACT

Today’s aircraft design projects are characterized by in-terdisciplinary collaboration between a large amount ofheterogeneous disciplines. Each discipline contributeswith specialized knowledge and software tools which areintegrated in automated simulation workflows. The uti-lization of a common data model significantly reduces thenumber of possible interconnections between the mod-ules and ensures a consistent source of information. Thispaper presents the Common Parametric Aircraft Config-uration Schema (CPACS) and discusses the progress ofestablishing it as a common language for aircraft, space-craft and rotorcraft design. With increased flexibility ofthe aerodynamic performance maps, a reformulation ofthe wing component segments for defining the wing inter-nal structure, a new definition for engine nacelles and py-lons and the possibility to include individual tool-specificschemas, the current enhancements and the correspond-ing development process of the latest CPACS release arepresented. The paper concludes by showing that publish-ing CPACS and its corresponding libraries under an open-source license has been the enabler for a wide adoption ofthe data format in the aeronautical research and industry.

1. INTRODUCTION

An increasing number of aircraft design projects ap-ply Multidisciplinary Design Optimization (MDO) tech-niques in decentralized and heterogeneous teams [7].Aiming at advancing the interdisciplinary collaborationbetween the various disciplines and realizing decentral-ized MDO architectures, about a decade ago researchershave postulated that the process efficiency within sucha collaborative environment can be enhanced by anopen, central data model that serves as a common lan-guage [22]. This hypothesis has been proven by apply-ing the Common Parametric Aircraft Configuration Sche-ma (CPACS) [22] in advanced preliminary aircraft designtasks including MDO.

Motivated by these results, subsequent aircraft designprojects, such as IDEaliSM [20, 25] or AGILE [7], havedriven further development of CPACS and successfullyapplied the data model within international collaborationenvironments involving partners from various universi-

ties, research establishments and industries. This paperpresents the results of this development and addresses thequestion whether the use of a common language has in-deed linked the aircraft design process more closely.

2. DATA MODELING IN AIRCRAFT DE-SIGN

In this chapter, the challenges on data modeling withinstate-of-the-art aircraft design processes are discussed.Existing data models aiming to cope with these chal-lenges cover a wide range of aviation disciplines andare all based on standardized data modeling languages,such as the Extensible Markup Language (XML), theUnified Modeling Language (UML) and its derivativesor the Web Ontology Language (OWL). It is not the in-tention of this paper to provide a thorough overview ofavailable modeling languages and their properties, ratherto present the specific implementation of CPACS usingXML. For an overview of the properties of modeling lan-guages other than XML, the reader is kindly referred tothe extensively available documentation on this topic.

2.1 Challenges on data modeling in collab-orative design

As indicated in Sec. 1, today’s aircraft design projectsmust account for the interaction of various disciplinessuch as structural mechanics, aerodynamics or flight me-chanics. One possibility to consider this interaction is tointegrate the required sub-disciplines in a monolithic soft-ware architecture used to synthesize an aircraft on con-ceptual and design level by applying sequential iterationmethods [32]. From a developer’s point of view, the inter-nal data exchange between analysis modules within themonolithic system is advantageous concerning the easi-ness of resolving data and model inconsistencies. Due tothe increased complexity of the design considerations al-ready in early aircraft design stages nowadays however,the process cannot be handled by a single person any-more. Furthermore, if the developer of the monolithicsystem is not available anymore, a large amount of im-plicit knowledge required to correctly operate the sys-tem is lost. Therefore, today’s research on collabora-tive MDO is often based on tool integration frameworks

1

which allow to integrate analysis modules in decentral-ized workflows [7] enabling engineering departments atdifferent sites to be involved in the design process. Theopen-source software RCE [4, 5] (Remote ComponentEnvironment) is an example of such a process integrationframework. It enables the connection of analysis modulesvia a server-client based network infrastructure. Uponworkflow execution, the execution of individual moduleshosted on their respective server instances is triggeredwhen required and the required data is automatically ex-changed. In this construct, only input and output data isexchanged while the tool itself remains under control ofthe tool owner. A challenge arising within this approachis that the stakeholders might use different data modelsand vocabulary resulting in N(N −1) possible directionsof data exchange between N tools. Within such a simu-lation process, the consistency among the multiple disci-plinary models and different levels of details of the simu-lations needs to be guaranteed. One solution to this chal-lenge is obtained by introducing a central data exchangeformat based on common semantics for the whole systemto be designed (e.g., full parametrization of an aircraft)which is easy to read and interpret by human. As depictedin Fig. 1, by using this single source of truth the amountof connections reduces to 2N. This is the main motiva-tion for the development of common aviation data mod-els, from which a selection of the most important ones ispresented in the following section.

N(N-1) 2N

Figure 1: The possible amount of data interfaces reducesfrom N(N −1) to 2N by using a central data format

2.2 Overview of existing aircraft and avia-tion data models

DAVE-ML is a flight dynamic model exchange formatpublished by a standards working group of the Ameri-can Institute of Aeronautics and Astronautics (AIAA) [1].Inspired by the input-files used for the flight dynam-ics model software library JSBSim [3], DAVE-MLis an XML based markup language. Both DAVE-ML and JSBSim have a strong focus on mathemati-cal modeling, which is achieved by defining individ-ual mathematical operators (JSBSim) or by implement-ing MathML (DAVE-ML). A higher level of multidisci-plinarity is covered by the Aircraft Design Markup Lan-

guage (ADML) [8]. Developed at the Virginia Poly-technic Institute & State University ADML is as wellbased on XML and rather represents generic systems bydescribing its components on a detailed level using ab-stract mathematical models (this bottom-up approach isexplained in Sec. 3.2). In this way ADML primarily aimsat modeling unconventional aircraft [8].

Various standards exist for data exchange models cov-ering aircraft operations. Keller [16] summarizes themost widely-used standards, for example the Flight In-formation Exchange Model (FIXM), the Aeronautical In-formation Exchange Model (AIXM), the Weather Infor-mation Exchange Model (WXXM) or the MaintenanceManagement Exchange Model (MMIXM) [16]. All ofthese based on UML.

First attempts to model aviation data using OWL areinvestigated by Ast et al. [2] focusing on the design ofan aircraft system and Keller [16] with respect to generalaviation data. However, both are still on a research leveland did not yet establish as a widely-used common stan-dard.

3. AN INTRODUCTION TO CPACS

To adequately meet the challenges of collaborative de-sign projects listed in Sec. 2.1, the data model CPACS hasbeen introduced and developed at the German AerospaceCenter (DLR) since 2005. The strengths of XML as mod-eling language will be explained in more detail. On thisbasis, the modeling approach is presented with regard toa general representation of an aircraft ontology and thecorresponding implementation in XML. Finally, the as-sociated software libraries are briefly outlined.

3.1 The strengths of XML as modeling lan-guage

XML is an open standard, which is officially coordinatedand documented by the Wold Wide Web Consortium(W3C) and nowadays globally accepted in the field ofinformation technology [28]. In contrast to other markuplanguages, such as HTML with a fixed list of tags, XMLhas a very generic character and can therefore serve asa computer-processable meta-language [28] enabling thedevelopment of an aviation ontology as a markup lan-guage itself. Another strength of XML is the separationof the data structure from the actual content. This allowsfor the definition of complex structural and semantic rulesin a separate XML Schema Definition (XSD) file, whileusers can independently describe data using an exchangeformat that is easy to read by just using a text editor. Inthis context Bohnke et al. [6] compare XML with othermodeling languages, such as the STandard for the Ex-change of Product model data (STEP) or UML, and point

2

out the importance of the extensibility and simplicity ofXML in collaborative design environments.

Relying on an open standard furthermore offers theadvantage of choosing from a wide range of more ad-vanced editors and APIs, which are often made availableby a large open-source community. Another advantageis that XML is increasingly used to model process in-formation and application configurations [28]. With re-gard to CPACS, this allows to consistently combine anaviation-specific ontology with tool-specific and process-specific data. Finally, the XML language family com-prises a number of additional standards, such as XSL[30], XPath [31] or XLink [29] which can be used to fur-ther extend the capabilities of the markup language.

3.2 The applied data modeling approach

cpacs

header

vehicles

aircraft

model

wings

fuselages

engines

analyses

...

rotorcraft

engines

profiles

materials

...

missionDefinitions

airports

flights

airlines

studies

toolspecifics

Figure 2: Extract of the hierarchical structure of CPACS

Making use of the hierarchical representation of data inXML the structure of CPACS mainly follows a top-downapproach which decomposes a generic concept (e.g., anaircraft) into a more detailed description of its compo-nents (see Fig. 2). This originates from the conceptualand preliminary design of aircraft, where the level of de-tail is initially low and continues to increase as the de-sign process progresses. The hierarchical structure fur-thermore promotes the simplicity of the exchange formatwhich is required in collaborative design environments(Sec. 2.1) so that the various stakeholders can easily ap-pend their results. Fig. 2 shows that CPACS offers a sim-ilar approach for other areal vehicles such as helicoptersand also for information on aircraft operations such ason airports and airlines, missions and flights as well asprocess-specific data used for studies and analysis mod-ules. A deeper insight into this structure is given by Lier-sch and Hepperle [19] and is extensively described withinthe CPACS documentation [10]. The geometric inter-pretation of the wing parameterization is furthermore ex-plained in Sec. 3.4 to serve as illustrative example.

For some concepts within CPACS, however, a bottom-up approach is applied where the components are first de-fined in detail and then linked to each other to formulatea higher-level concept. This is similar to the principlesapplied within ADML (see Sec. 2.2) and is advantageouswhen used multiple times within complex systems, suchas engines, which only have to be defined once in orderto be referenced several times on the aircraft. The com-bination of these two methodologies is known as middle-out approach and enables the goal to fully parametrizeaeronautical systems. In the development of CPACS en-hancements the challenge is always to find an appropriatecompromise between the very flexible bottom-down ap-proach and the rigid but semantically more meaningfultop-down approach.

3.3 XML implementationTo implement the hierarchical structure presented inSec. 3.2, the majority of CPACS definitions is basedon XML standards specified by W3C and implementedas schema in XSD. Simple data types (string, double,boolean, ...) as well as complex data types (containingpre-defined child-elements) are extended by attributes tomodel recurring meta-data, such as parameters for uncer-tainty quantification or pointers to external data. Thesetypes are introduced as CPACS base-types. Each ele-ment in CPACS first inherits the properties from thesebase-types and extends it with information-specific child-elements and attributes or restricts the allowed content byintroducing enumerations of simple values.

Additional base-types provide the means to representvectors and arrays in a more compact form than specifiedby the official W3C standard. In aircraft design, largecoefficient-based data sets might occur - especially in the

3

x

yz

1 st section

2 nd section

3 rd section

sweep

dihedral

2nd element1st element

positioning vector

2nd segment

1st segment

Figure 3: Geometric representation of a wing

field of aerodynamic analyses (e.g. aerodynamic coeffi-cients and their derivatives depending on Mach number,altitude, angle of attack and angle of yaw) and engineperformance (e.g. thrust, fuel usage and emission valuesas function of Mach number, altitude, engine rating, en-gine condition, shaft speed and power offtake). Withinthe official standard, vectors are defined as a sequence ofelements and multidimensional arrays as a nested list ofelement sequences. When using this standard to save thecoefficient-based data, most of the XML content wouldconsist of tags (XML nodes written in angle brackets).This would be at the expense of clarity and introducean unnecessary large file size which would slow downthe network-based simulation approach. For this reason,CPACS-specific vector and array types are introduced,inheriting from the string type and allowing semicolon-separated vector representations within single tags.

The definitions and conventions used in CPACS areprovided by the corresponding documentation written in-side the XSD file. This forces consistency between thedefinitions and its documentation, since these are pro-vided at the same location within the schema. Fromthe documentation entries available within the schema,a HTML-based documentation is derived using an open-source plug-in for the Sandcastle Help File Builder [18].Using the HTML-based documentation, the user cansearch through the CPACS hierarchy and obtain the re-spective information on each tag within the data format.

3.4 Example: parametrization of a wingAn example shall illustrate the geometric representationof aircraft geometries in CPACS. For this purpose, theparametrization of a wing is demonstrated as used forboth aircraft and helicopters.

A wing consists of at least two sections, where eachsection represents a local coordinate system in Cartesiancoordinates. Fig. 3 illustrates a wing composed of threesections. CPACS offers two approaches to specify the

position of a section in space: (1) by using a position-ing vector defined by a length, sweep angle and dihe-dral angle as well as (2) a transformation through rotationaround all three axes and a three-dimensional translationand scaling. As shown in Fig. 3 both approaches can besuperimposed. While the first section is only defined by apositioning vector (i.e., the axes are still parallel to eachother) the second section is additionally rotated aroundthe z-axis and the third section, representing the wing tip,is rotated around the x-axis.

Each section contains one or more elements which areused to specify the location of two-dimensional airfoils.The elements are again defined as local coordinate sys-tem within a section which can be transformed throughrotation, translation and scaling. Two elements can beplaced in the same section to model a discontinuous jumpin span-wise direction as shown in Fig. 3 and explainedin more detail by Siggel et al. [24].

Finally, a wing segment is defined as volumetric extru-sion connecting two elements of adjacent sections. Theoptional specification of guide curves furthermore allowsto realize curved leading and trailing edges.

This example underlines the potential of XSD to spec-ify repeating properties as complex types that can be usedfor multiple elements (see Sec. 3.3). It allows in this caseto use the same type of wing definition for both aircraftand helicopters or the same type of transformation for theparent coordinate system of the wing, its sections and el-ements. Furthermore does the use of unique XML identi-fiers (uIDs) allow airfoils from the profile database to berepeatedly referenced (see <profiles> node in Fig. 2).

3.5 Program interfaces and librariesTo support the integration of tools in collaborative designenvironments (see Sec. 2.1) the XML interface libraryTiXI [9] has been developed at DLR. TiXI is based onLibxml2 [27] and is extended by methods to understandCPACS specific conventions, i.e. reading and writing the

4

Figure 4: CPACS-Creator GUI showing a CPACS modelnext to an input deck to adjust the corresponding param-eters.

vectors and arrays introduced in Sec. 3.3. The librarycan be used from applications written in C, C++, Fortran,Java, Matlab and Python [9].

Furthermore, both a Python library generated from theXSD file via generateDS [17] as well as a Java libraryare delivered with each CPACS release. These librariesprovide classes which support the in-memory handlingof CPACS data sets. In this context, the hierarchicalstructure of CPACS proves to be advantageous when usedwithin object-oriented programming languages.

The geometry library TiGL [24] translates the parame-tric description of aircraft and helicopters to three-dimensional shapes, which various disciplines requireespecially in the preliminary and higher-fidelity designphases. For this, the open-source CAD kernel OpenCAS-CADE [23] is used and extended by various geometricmodeling features, for example a detailed surface mod-eling generator using curve network interpolation on thebasis of Gordon [13]. This increases the quality (smooth-ness) of surfaces to a level which is required for high fi-delity analysis, such as Computational Fluid Dynamics.The TiGL aircraft component module can create both ex-ternal aircraft components - such as wings, flaps, fuse-lages, engines - and internal structures - such as ribs,spars and cutouts [24]. TiGL is written in C++ and pro-vides interfaces for C, C++, Python, Java and MATLAB.In addition, the TiGL Viewer visualizes CPACS data setsin a graphical user interface (GUI) based on 3D OpenGLand allows visualization tasks to be automated by script-ing in a console.

Next to the TiGL geometry viewer, a CPACS-Creatorhas been released. Developed by CFS Engineering, thiseditor is based on TiGL and allows the parametric modi-fication of aircraft geometries as well as its creation fromscratch. CPACS-Creator is published as open-sourcesoftware as well and its functions can be directly calledby analysis modules by using the high-level functions ofthe corresponding C++ library. A GUI directly integratesin the TiGL Viewer and allows for the synthesis and mod-ification of CPACS data (see Fig. 4).

4. RECENT ENHANCEMENTS OF THEDATA FORMAT AND EXPERIENCESIN ITS UTILIZATION WITHIN COL-LABORATIVE DEVELOPMENTPROCESSES

4.1 Major enhancements introduced inCPACS 3

The third major-release version of CPACS was publishedin July 2018. Some of the experiences gained from previ-ous projects were used to improve and add new elementsand types. The most important enhancements introducedin CPACS 3 (including minor releases up to version 3.2)are outlined in more detail below.

Enhanced aerodynamic data sets

One of the modifications concerns the definition ofaerodynamic data sets. In previous CPACS releasesthese so-called aero performance maps consisted of four-dimensional arrays containing the aerodynamic force andmoment coefficients as well as damping derivatives of anaircraft depending on Mach number, Reynolds number,angle of yaw and angle of sideslip. It turned out that sucha full-factorial representation of aerodynamic data lacksphysical relevance, since many combinations of the in-dependent variables describing the aircrafts’ state do notrepresent realistic flight conditions. To allow for a moreflexible definition of the aero performance maps, the co-efficients and derivatives are now stored as vectors of thesame length, whereby entries having the same index to-gether represent a single flight state. Furthermore, theaerodynamic data representation is transformed from thebody-fixed into the aerodynamic coordinate system. Thisallows quick judgments of the correctness of the pro-vided values by the aerodynamic specialists, since theyoften bring experience in the expected magnitude of co-efficients expressed in this coordinate system. Additionalelements are added to the performance maps to specifyboundary conditions, including atmospheric data as wellas settings of movable devices (e.g., landing gear status,control surface deflections, etc.). Operational limits cannow be specified in terms of angle of sideslip and angleof attack limitations for a given set of Mach and Reynoldsnumbers. Maps with delta values of aerodynamic coeffi-cients for incremental control surface deflections are stilldefined as a CPACS array type as introduced in Sec. 3.3.However, due to the aforementioned reformulation of thebasic aerodynamic coefficients these arrays are only two-dimensional and not five-dimensional as in previous ver-sions of the data format. An additional element referenc-ing the state of the flight control system allows to specifythe change in aerodynamic characteristics due to simulta-neous control surface deflections.

5

Lessons learned from the development of the aerody-namic coefficients representation is that it requires a largeeffort to find the right balance between the simplicityof the chosen representation strived for versus the gen-eral applicability to all identified use-cases, often requir-ing complex constructs. With the current representation,the development team believes to have obtained the leastcomplex representation covering all use-cases identified:as simple as possible, as complex as necessary. Next tothis - even when the syntax of the representation is fullyunderstood by all users - the semantically correct inter-pretation of the provided data by engineers from disci-plines other than aerodynamics is experienced to not betrivial. To make a first step towards a better alignmentof data provision and interpretation among the engineersof different disciplines, an interpolation library will beestablished and provided next to the TiXI and TiGL li-braries described in Sec. 3.5.

Modeling of component segments for defining wing in-ternal structures

Another major modification affects the geometric mod-eling of component segments within the wing defini-tion. Component segments are areas between certainwing sections containing the wing structure, control sur-faces or wing tanks defined in the normalized coordi-nates ξ (chordwise direction) and η (spanwise direction).In CPACS 3 these coordinates changed from rectangularto body fitted coordinates to prevent the possible defini-tion of points between 0 and 1 being outside the wing.This required significant adaptions of the geometry li-brary TiGL, which is, after the release of TiGL 3, nolonger backward compatible to previous CPACS releases.

The possibility to define structural components actu-ally (partly) being outside the wing became apparentwhen using CPACS to define non-conventional aircraftsuch as box-wing configurations and by considering moreadvanced geometric considerations such as aeroelasticdeformation of wings and analyzing the correspondingeffect on the wing internal structure in detail. CPACShas developed into the current version by testing its ap-plicability within many projects considering a multitudeof different configurations. Introducing a major nonbackward-compatible change provides a large effort - es-pecially if the corresponding libraries need to be over-hauled as well. The new release however allows the evenmore flexible definition of all kinds of aircraft configura-tions.

Addition of a parametric model of engine nacelles

A parametric description of engine nacelles and py-lons, of which a prototype was introduced in the pre-vious release, is now fully implemented in CPACS 3.Fig. 5 shows a nacelle geometry TiGL derived from

Figure 5: Engine nacelle displayed in TiGL viewer.

the new parametrization. The center, core and fancowl are defined by radial sections in flow direction(two-dimensional profiles in cylindrical coordinates) andguide curves to control the extrusion of these profiles.A comprehensive description of the nacelle and pylonparametrization and its implementation in TiGL is givenby Siggel et al. [24].

Inclusion of a generally applicable mission definition

From applications of previous CPACS versions withinaircraft design and analysis tasks, the need arose to in-clude an extensive and generally applicable mission def-inition within the data format. Next to coping with therelatively straightforward mission definitions used for thedesign of transport aircraft, the more flexible definitionintroduced in CPACS 3 can cope with detailed flightpaths (flying actual waypoints, applying step-climb pro-files, etc.) and with missions for non transport aircraftsuch as military jets or UAV’s and rotorcraft. The new<missionDefinitions> node is positioned directly at theroot CPACS-node (see Fig.2), so a multitude of missionsfor which an aircraft or rotorcraft has to be designed canbe defined. Within each vehicle definition, a correspond-ing <performanceRequirements> node is introduced, inwhich the link to the respective mission definition(s) tobe fulfilled is established. A mission is built up of asequence of segments - optionally grouped in segment-Blocks - in which the respective constraints and end con-ditions on the mission profile can be defined. Further-more, point performance requirements - such as a ser-vice ceiling or sustained turns - can be defined and linkedto specific mission segments. Creating the mission def-inition has been a largely iterative process in which theopinion of multiple DLR internal and external special-

6

ists in mission simulation and flight performance analy-ses have been involved. The major challenge has beenfinding the right balance between the provided flexibilityand simplicity of the definition.

Possibility to include individual toolspecific schemas

Fig. 2 shows that CPACS provides a node called <tool-specifics> which contains tool-specific process param-eters for a given list of tools that can automaticallybe executed in decentralized workflow environments(see Sec. 2.1). An example is given by Liersch andHepperle [19] for the aerodynamic analysis tool LIFT-ING LINE. Having these parameters together with theaircraft or helicopter model in a consistent data set signif-icantly supports the workflow integration. However, theapplication of this feature in multidisciplinary projectslike IDEaliSM [20] or AGILE [7] revealed that main-taining this part of the XML schema is quite challeng-ing since the development speed of tools usually dif-fers from the CPACS release cycles. To avoid releasinga new CPACS version just for tool-specific updates orslowing down tool development since no direct releaseof CPACS is planned, it was decided to include thesenodes in the schema while using separate namespaces.This is achieved by the XSD <any> element. It allowsto include an individual namespace but requires a corre-sponding XML Schema Definition to validate data. Thecreation and maintainance of this separate schema will bein the responsibility of the tool owner. Thus, the releasecycles of the tool-specific schemes can be adapted to thedevelopment speed of the corresponding tools, whilst en-suring the validation of all provided input data is possible.

4.2 Establishing a collaborative develop-ment process

The CPACS development is coordinated by DLR’s In-stitute of System Architectures in Aeronautics and regu-larly released under the Apache 2.0 open-source license.It is maintained via the software development platformGitHub, which allows to document the development anddiscussions in a transparent way using a variety of man-agement methods. Problems are discussed via an issueforum and the status of these issues is tracked in Kanbanboards. This provides developers and users an overviewof the changes and extensions planned for a certain re-lease and provides the means to keep track of the devel-opment process. It also facilitates to involve new stake-holders during the development process and to documentpossible decisions for future reference.

To ensure acceptance of the proposed updates through-out the entire community, all changes are implementedin a release candidate which is announced at least fourweeks before an official release is planned. This an-nouncement is made via a CPACS mailing list and a

blog entry on the CPACS homepage [10]. The homepagefurthermore provides an online documentation of all re-lease versions including the next release candidate andprovides links to the corresponding XSD documents forvalidation of CPACS data sets. In CPACS 3.2 examplefiles have been added and a unit testing method is imple-mented to ensure that the examples are always valid withthe current schema. Feedback from the community showsthat such examples are extremely helpful when learninghow to use CPACS.

In addition to passive notifications via GitHub, e-mailand homepage, the authors consider requesting activeconfirmation or rejection of major changes, so that pos-sible inconsistencies can be discovered well in advanceof a planned release. For this purpose, representatives ofthe participating institutions and disciplines could eithermake such decisions in the name of their discipline orpass on current developments to the persons concerned.

A very important aspect in the development process isto align CPACS modifications and new features with thelibrary development. As outlined in Sec. 3.5 the geom-etry library TiGL has become a comprehensive and veryimportant software for the CPACS community, not onlybecause it translates the CPACS parameters into a three-dimensional geometry, also because it is a collection ofmethods that the community has agreed on in terms ofhow to interpret the geometry parametrization. Whenall partners involved in the design process use TiXI andTiGL to wrap their analysis modules, next to the syntacti-cal, also the semantically correct interpretation is guaran-teed. Regular online meetings between the correspondingdevelopers help to avoid incompatibilities between TiXI,TiGL and CPACS.

Extensive discussions and agreements take place in theform of regular developer meetings targeted to be heldtwo times per year. Experience has shown that due tothe wide range of aspects covered by CPACS, the topicsfor discussion must be limited. Nonetheless, the on-siteexchange is very helpful in accelerating the developmentprocess and promotes community building.

4.3 Application of CPACS in collaborativedesign projects

To provide an insight in the application range of CPACS,the current section lists an overview of some of theprojects in which the data format has been applied and ex-tended until the time of writing this paper. In fact, mostextensions of the data format are driven by needs fromthese projects, focusing on the utilization of collaborativedesign methods to perform complex product design exer-cises.

7

(a) (b) (c)

(d) (e) (f)

Figure 6: Aircraft configurations investigated in the FrEACs (configurations c and e) and AGILE (all configurations)project.

FrEACs

As fourth in a series of projects focused on buildingup a design environment for the collaborative and dis-tributed analysis of aircraft configurations within DLR,the Future Enhanced Aircraft Configurations (FrEACs)focused on applying the established tools and methodolo-gies to the design of non-conventional aircraft configura-tions (Fig. 6(c) and (e)). Within an automatic simulationworkflow spanning multiple levels of analysis fidelity,the potential of a strut-braced wing configuration as fu-ture short- to medium-range aircraft was successfully in-vestigated [21]. Furthermore, the flight mechanical andhandling qualities of a blended-wing-body configurationwere investigated and tested within DLR’s AVES flightsimulator [15]. During the project, the team progres-sively built up and utilized CPACS-based workflows forboth configurations including over 24 analysis modulesfrom 11 different DLR institutes. The introduction of de-sign camps - special meetings focused on conducting aspecific task, e.g. the downselection of possible designconcepts - proved to be a very useful addition to the de-sign process within the project. During the final designcamps, the built-up simulation workflow spanning multifidelity levels was utilized to perform designs of experi-ments. Focus during these design camps was on compar-ing results on the three involved fidelity levels and col-laborative result interpretation, in which combining theknowledge of all participating team members is of invalu-able importance.

ATLAs

Within the Advanced Technology Long-range AircraftConcepts (ATLAs) project, which was successfully com-pleted in December 2019, CPACS served as common lan-

guage in a collaborative aircraft design project involving13 DLR institutes. In ATLAs, advanced assessment pro-cedures were employed to evaluate the impact of mod-ern technologies, such as hybrid laminar flow control ora CO2 management system for cabins - on future aircraftconfigurations in a more holistic way [14]. The underly-ing use-case for these studies is the design of an advancedmid-range aircraft. The various disciplines and technolo-gies shown in Fig. 8 underline the importance of not onlyconsidering the aircraft itself, but also modeling opera-tional aspects in CPACS, e.g. to assess the climate impactof new designs. Within the ATLAs project, the paramet-ric logic of CPACS has proved to be an enabler for per-forming technology evaluation studies combining multi-ple promising technologies in a single configuration.

AVACON

Figure 7: Over-wing nacelle configuration studied in theAVACON project.

Similar to ATLAs the research project AVACON fo-cuses on advanced technologies in collaborative designwithin a consortium of nine partners from industry, re-

8

Figure 8: Functional breakdown of disciplines involved in the ATLAs project [14].

search entities and universities funded by the nationalaeronautic research program LuFo V-3. Starting from thesame baseline configuration, the target aircraft configura-tions and selected technologies differ from ATLAs. Forexample, a central study within AVACON focuses on theimpact of an over-wing engine integration as sketched inFig. 7 [14]. Within the project, the parametric definitionof engines, nacelles, wings and fuselages in CPACS en-abled performing aircraft-engine integration studies.

IDEaliSM

Within the project Integrated and Distributed Engineer-ing Services framework for MDO (IDEaliSM), a formal-ized framework for the creation of a service-orientedproduct development process has been established andsuccessfully utilized to connect an aircraft OEM witha tier-1 and tier-2 supplier for aircraft structural com-ponents. The formalized framework serves as basis toperform front-loading of the design process by creatingand combining engineering services and connecting theseboth within and across company borders using automatedbusiness and simulation workflows [26]. Upon comple-tion of a conceptual aircraft design task - involving analy-sis modules progressively adding information to CPACS- its resulting CPACS data deck is uploaded to a cen-tral data server within a neutral IT domain [20]. Af-ter the Tier-1 supplier receives the corresponding requestfor proposal - in this case for the design of a verticaltailplane, - the CPACS data deck is downloaded and itsgeometry definition is automatically converted to the dataformat natively used at the supplier. The same holds true

for the subsequent connection between the tier-1 and tier-2 supplier, the latter providing a single structural compo-nent for the structural assembly. The resulting structuralassembly and its properties are added to the CPACS datadeck and re-uploaded to the central data server. In thisway, the aircraft OEM has the ability to take detailed con-siderations into account already in relatively early designstages. In the described application, the data consistencybetween the parties involved is ensured by automatingdata exchange through the central data server and throughadoption of common data formats such as CPACS. Boththe automation and integration of the design processeslead to a significant reduction in overall process lead time[25], which at its turn allows for executing an increasedamount of design iterations.

Agile

The Horizon 2020 project Aircraft 3rd Generation MDOfor Innovative Collaboration of Heterogeneous Teamsof Experts (AGILE) was conducted from 2015 to 2018addressing multidisciplinary optimization based on dis-tributed analysis frameworks (demonstrated with RCE,see Sec. 2.1). The consortium composed of 19 interna-tional partners from EU, Russia and Canada has provena speed up of 40% in solving realistic MDO problemsfor conventional, strut-braced, box-wing and BWB con-figurations (see Fig. 6) compared to today’s state-of-the-art approaches in overall aircraft design [7]. Basedon CPACS as central data exchange model it has beendemonstrated that its current development status allowsto model a variety of unconventional aircraft configura-

9

tions including the corresponding analysis results.

VicToria

The DLR internal research project VicToria (Virtual Air-craft Technology Integration Platform) aims at a compre-hensive digital description and development of aircraftincluding flight-physical effects on a high-fidelity level.This is achieved by the development of a distributedcollaborative MDO environment which combines high-fidelity analysis for aerodynamics and structures withconceptual aircraft design methods [12]. The use ofCPACS in the consortium of 12 DLR institutes and facili-ties helps to reduce the gap between low and high-fidelitymodeling. One of the results is the detailed parametriza-tion of engine pylons and nacelles presented in Sec. 4.1.For selected disciplines, the bridge to use CPACS as ini-tial basis for consecutively performing high-fidelity anal-yses is established.

TRIAD

A DLR project called Technologies for Rotorcraft in Inte-grated and Advanced Design (TRIAD) has been initiatedin January 2018 to investigate the impact of new tech-nologies (e.g., electric propulsion or the design of fiberreinforced materials for fuselage cells using Finite Ele-ment Methods) on the overall rotorcraft design consid-ering different rotor, wing and propeller configurations.Five DLR institutes are involved exchanging geometryand aerodynamic performance data using CPACS in asimulation workflow. The application of the helicopternode in such projects ensures consistency between theaircraft and rotorcraft ontology, especially when new orupdated definitions - such as the aerodynamic perfor-mance map described in Sec. 4.1 - shall be used for bothvehicle types.

IFAR-X Challenge

The ”IFAR-X Challenge” is a voluntary framework foryoung engineers and scientists from over 20 countries tocollaborate in developing a multi-disciplinary aircraft de-sign process. The common goal is to assess and inte-grate green technologies in future aircraft. Organized bythe Russian Central Aerohydrodynamic Institute (TsAGI)and DLR, both CPACS and other tools focused on col-laboration were introduced in a three-day seminar. Suchan opportunity allows CPACS developers to understandhow the technology can be most efficiently explainedto new users. In this context, additional training mate-rial (e.g., example files, tutorials) was created and madefreely available to the community. Furthermore, the in-clusion of new users is a good way of identifying in-herent weaknesses in the definitions within the data for-mat which are sometimes overseen by experienced users -

within the IFAR-X challenge, certain data interpretationswere taken for granted by the experienced users and couldhave revealed the possible cause of inconsistencies. TheIFAR-X challenge significantly contributes to the expan-sion of the community and the establishment of a com-mon language in aircraft design. Within the challenge,CPACS enables the quick integration of technologies andideas from research establishments across the globe.

HOLISHIP

The H2020 European Research Project HOLISHIP(Holistic Optimisation of Ship Design and Operation LifeCycle; 2016-2020) project gives CPACS developers theopportunity to think outside the box by using the model-ing approach described in Sec. 3.2 to support the develop-ment of the data exchange format Holispec [11]. Duringa workshop in Alesund, Norway, a first data hierarchy forthe design process of vessels was developed combiningCPACS with previous work from the Maritime ResearchInstitute Netherlands (MARIN). Just as the aforemen-tioned TRIAD project, HOLISHIP shows that the princi-ples of CPACS can be applied to all kinds of collaborativeproduct design initiatives.

5. CURRENT STATUS OF ESTABLISH-ING CPACS AS A COMMON LAN-GUAGE IN AIRCRAFT DESIGN

As mentioned in Sec. 3, the development of CPACSstarted in 2005. Seven years later Nagel et al. [22] evalu-ated the data model with respect to its application in var-ious collaborative projects asking whether and how it ispossible to establish a common language in aircraft de-sign. In this context, CPACS has been used to demon-strate that a standardized data model can have a signif-icant impact on the efficiency of collaborative researchand design efforts. The authors also derive a list of re-quirements which are crucial for the implementation of astandard for communication in aircraft design.

As a summary of the experiences discussed in thepresent paper a brief up-to-date overview of with respectto the most important requirements is provided below.

Public availability of all technical information

By using GitHub, all adaptations to the XML schemaare publicly accessible. Technical reports about currentchanges have contributed to focus the discussions. Al-though using the software development platform is help-ful in keeping track of all issues and modifications, manyfeatures are hesitantly accepted by the community dueto the complexity of GitHub. Therefore, the importanceof providing a user-friendly homepage that informs users

10

and provides access to technical details has been recog-nized. The combination of a development (GitHub) andinformation platform (Homepage) finally increased thedistribution of technical information in the communityand in turn decreased maintenance effort for developers.

Availability of training material, training courses andtechnical help

The automatic generation of documentation based on Mi-crosoft Compiled HTML Help significantly reduced thedevelopment effort of CPACS. The compiled CHM filesare delivered with every release, but are reluctant to beused by the community due to the less intuitive user inter-face and, in part, platform-dependent visualization prob-lems. To solve this problem, the documentation is addi-tionally integrated in the CPACS homepage and can beviewed directly in the browser. This feature is used inten-sively by the community, even though useful extensionssuch as a search function or a navigation bar are still miss-ing.

Experience has also shown that example files such asdescribed in Sec. 4.2 are the most efficient way to supportthe introduction to CPACS and to accelerate the integra-tion of own software in CPACS-based workflows. Thus,this aspect will be considered more thoroughly in futurereleases.

Additional training material was created as part of theIFAR-X design challenge (see Sec. 4.3) and made pub-licly available on GitHub. It has been observed that acertain momentum has emerged in the community, whereusers have supported each other and contributed with ex-ample programs and tutorials on GitHub.

Finally, it should be mentioned that training coursescan contribute significantly to a fast understandingof CPACS. First experiences were gained, for exam-ple, with an introduction for doctoral students at TU-Braunschweig or for the participants of the IFAR-X de-sign challenge. The training material for these courses isagain freely available on GitHub.

Effort for learning the standard significantly lowercompared to the technical problem to be solved

It has been shown that a basic introduction to CPACS viaseminars takes about two to three days. Since CPACS isbased on XML and thus on an open standard, the compre-hensive documentation reduces the additional workloadto a few hours (mainly to implement XML processors andAPIs), which is usually less than the solution of techni-cal problems addressed in aircraft design. The autodidac-tic training period is furthermore reduced by sample filesprovided since CPACS 3.2.

Possibility to use the model without charge

Due to a lack of experience with the usage of proprietarystandards, the influence of this factor can only be assessedhypothetically. However, it can be assumed that the ac-ceptance for CPACS would be significantly lower if theuse of the file format or the associated software librarieswere subject to paid licenses.

Continuity of conventions

In some cases, this aspect is difficult to assess. On the onehand, CPACS is used as a de-facto standard in aircraft de-sign and therefore changes should not be introduced toofrequently. On the other hand, a fast development processis often necessary, especially when new definitions are re-quired for upcoming projects. Therefore, two approachesare followed: First, changes are introduced more dynam-ically when a major release has just been released, as ex-perience has shown that many tools require time to adaptto new CPACS versions. Furthermore, project-specificXML schemas are used in some cases, in which changesare introduced and tested only within a limited number ofusers before they are incorporated into the public release.

Structured development process with predictable re-lease cycles

A structured development process has been introduced asdescribed in Sec. 4.2 which contributes to the establish-ment of CPACS as an exchange format. Feedback fromthe community revealed that predictable release cyclesare important.

Establishing a steering committee coordinating thedevelopment process

There is a strong interest from DLR to involve Univer-sities and Industry in forming a common steering com-mittee. Exemplary for this are the procedures of W3Cin establishing web standards. The framework for theimplementation of such a committee are currently beingelaborated.

High propagation of the standard through an ecosys-tem of libraries and applications

CPACS has established as a de-facto standard for DLRinternal aircraft design projects and is increasingly usedby a large number of national and international researchinstitutions and industrial partners (see Sec. 4.3). Thestraightforward and proper application of the definitionswithin CPACS is enabled by the open-source develop-ment and availability of the corresponding software li-braries TiXI and TiGL. Together with the Remote Com-ponent Environment (RCE) as open-source process inte-gration framework, CPACS, TiXi and TiGL form an ad-

11

vanced ecosystem in support of collaborative aircraft de-sign.

6. CONCLUSION

The present paper highlights that collaborative aircraftdesign projects involving heterogeneous disciplines maysignificantly benefit from using a common language fordata exchange. It not only supports the integration of de-centralized workflows, but also assures that all partnersare correctly interpreting the data and working with con-sistent models. Next to other aviation data models for var-ious disciplines, CPACS provides an extensive parametricontology for fixed-wing aircraft and rotocraft. Based onthe XML Schema Definition CPACS is flexibly expand-able and both human readable and computer processable.

Recent enhancements of CPACS include a detailed pa-rametrization of engine nacelles and pylons, more flexi-ble aerodynamic performance maps, body-fitted coordi-nates for wing component segments and the possibilityto include individual tool-specific data. These modifi-cations result from a collaborative development processbased on GitHub and on-site meetings with the respec-tive users and developers.

Publishing CPACS and its corresponding libraries un-der an open source license and applying it in various de-centralized aircraft design projects promoted its use inheterogeneous teams and led to a significant communitygrowth. Thus an important step towards a standard for acommon language in aircraft design has been achieved.In the course of projects like AGILE or IDEaliSM ithas been quantitatively proven that collaborative designtasks based on CPACS can significantly increase in per-formance and quality. This positively answers the ques-tion from Sec. 1 whether the use of a common languagehas linked the aircraft design process more closely.

Upcoming challenges include a detailed representationof aircraft systems to meet the requirements of variousresearch projects on the climate impact of aviation andthe design of sustainable aircraft. To enable the increasedcomplexity and heterogeneity of these projects while en-suring a clear semantic interpretation of data, future re-search will also focus on combining advanced data mod-eling methodologies from the field of Semantic Web withstate-of-the-art approaches in aircraft design (e.g., ModelBased Systems Engineering).

REFERENCES

[1] American Institute of Aeronautics and Astronau-tics. Flight Dynamics Model Exchange Standard.Technical Report ANSI/AIAA S-119-2011(2016),American National Standard, 2011.

[2] Markus Ast, Martin Glas, and Tobias Roehm.Creating an Ontology for Aircraft Design. InDeutscher Luft- und Raumfahrtkongress 2013.Deutsche Gesellschaft fur Luft- und Raumfahrt -Lilienthal-Oberth e.V., 2013.

[3] Jon S. Berndt. JSBSim, an open source platformindependent flight dynamics model in C++. JSBSimReference Manual v1.0, 2011.

[4] Brigitte Boden, Jan Flink, Robert Mischke, Schaf-fert Kathrin, Alexander Weinert, Annika Wohlan,and Andreas Schreiber. RCE: An Integra-tion Environment for Engineering and Science.arXiv:1908.03461, 2019.

[5] Brigitte Boden, Jan Flink, Robert Mischke, KathrinSchaffert, Alexander Weinert, Annika Wohlan,Caslav Ilic, Tobias Wunderlich, Carsten M. Lier-sch, Stefan Goertz, Pier Davide Ciampa, and ErwinMoerland. Distributed Multidisciplinary Optimiza-tion and Collaborative Process Development UsingRCE. In AIAA Aviation 2019 Forum. American In-stitute of Aeronautics and Astronautics, June 2019.

[6] D. Bohnke, M. Litz, Bjorn Nagel, and S. Rudolph.Evaluation of Modeling Languages for Prelimi-nary Airplane Design in Multidisciplinary DesignEnvironments. In Deutscher Luft- und Raum-fahrtkongress 2010. Deutsche Gesellschaft fur Luft-und Raumfahrt - Lilienthal-Oberth e.V., 2010.

[7] P. D. Ciampa and Bjorn Nagel. AGILE the NextGeneration of Collaborative MDO: Achievementsand Open Challenges. In 2018 MultidisciplinaryAnalysis and Optimization Conference. AmericanInstitute of Aeronautics and Astronautics, 2018.

[8] Shubhangi Deshpandea, Layne T. Watsona,Nathan J. Lovec, Robert A. Canfield, and Ray-mond M. Kolonay. ADML: Aircraft DesignMarkup Language for Multidisciplinary AircraftDesign and Analysis. Technical Report TR-13-07,Computer Science Technical Reports, 2013.

[9] DLR Institute for Simulation and Software Tech-nology. Tixi: fast and simple xml inter-face library. http://tixi.sourceforge.net/

Doc/index.html, 2019. [Online; accessed 12-November-2019].

[10] DLR Institute for System Architectures in Aeronau-tics. CPACS: Common Language For Aircraft De-sign. www.cpacs.de, 2019. [Online; accessed 13-November-2019].

[11] Marteen Flikkema, Martin van Hees, Timo Ver-woest, and Arno Bons. HOLISPEC/RCE: Virtual

12

Vessel Simulations. In Apostolos Papanikolaou, ed-itor, A Holistic Approach to Ship Design, volume 1,chapter 15, pages 465–485. Springer, 2019.

[12] Stefan Goertz, Caslav Ilic, Jonas Jepsen, MartinLeitner, Matthias Schulze, Andreas Schuster, JulianScherer, Richard Becker, Sascha Zur, and MichaelPetsch. Multi-level MDO of a long-range trans-port aircraft using a distributed analysis frame-work. In 18th AIAA/ISSMO Multidisciplinary Anal-ysis and Optimization Conference. American Insti-tute of Aeronautics and Astronautics, June 2017.

[13] William J. Gordon. Spline-Blended Surface In-terpolation Through Curve Networks . Journalof Mathematics and Mechanics, 18(10):931–952,1969.

[14] Johannes Hartmann, Till Pfiffer, Berit Breymann,Daniel Silberhorn, Erwin Moerland, Marco Weiss,and Bjor Nagel. Collaborative Conceptual Designof a Mid-Range Aircraft Under Consideration ofAdvanced Methods for Technology Assessment. In31th Congress of the International Council of theAeronautical Sciences. International Council of theAeronautical Sciences, 2018.

[15] Yasim J. Hasan, Jan Flink, Sebastian Freund,Thomas Klimmek, Richard Kuchar, Carsten M.Liersch, Gertjan Looye, Erwin Moerland, Till Pfeif-fer, Mario Schrader, and Sebastian Zenkner. Sta-bility and Control Investigations in Early Stages ofAircraft Design. In 2018 Applied AerodynamicsConference. American Institute of Aeronautics andAstronautics, June 2018.

[16] Richard M. Keller. Ontologies for Aviation DataManagement. In 35th Digital Avionics SystemsConference (DASC). IEEE Aerospace & ElectronicSystems Society, 2016.

[17] Kuhlmann Kuhlman. generateDS – Gen-erate Data Structures from XML Schema.www.davekuhlman.org/generateDS.html,2019. [Online; accessed 01-January-2020].

[18] Immo Landwerth. XML Schema documentationplug-in for Sandcastle Help File Builder (SHFB)— GitHub. https://github.com/terrajobst/xsddoc, 2016. [Online; accessed 4-December-2019].

[19] Carsten M. Liersch and Martin Hepperle. A dis-tributed toolbox for multidisciplinary preliminaryaircraft design. CEAS Aeronautical Journal, 2(1-4):57–68, 2011.

[20] Erwin Moerland, Sebatian Deinert, Daoud Fernaß,Jochen Dornwald, and Bjorn Nagel. Collaborative

aircraft design using an integrated and distributedmultidisciplinary product development process. In30th Congress of the International Council of theAeronautical Sciences. International Council of theAeronautical Sciences, 2016.

[21] Erwin Moerland, Till Pfeiffer, Daniel Bohnke,Jonas Jepsen, Sebastian Freund, Carsten M. Lier-sch, Gabriel Pinho Chiozzotto, Carsten Klein, Ju-lian Scherer, Yasim J. Hasan, and Jan Flink. On theDesign of a Strut-Braced Wing Configuration in aCollaborative Design Environment. In 17th AIAAAviation Technology, Integration, and OperationsConference. American Institute of Aeronautics andAstronautics, June 2017.

[22] Bjorn Nagel, Daniel Bohnke, Volker Gollnick,P. Schmollgruber, A. Rizzi, G. La Rocca, andJ. J. Alonso. Communication in Aircraft Design:Can We Establish a Common Language? In28th Congress of the International Council of theAeronautical Sciences. International Council of theAeronautical Sciences, 2012.

[23] Open Cascade SAS. OPEN CASCADE part ofCapgemini. www.opencascade.com, 2019. [On-line; accessed 11-December-2019].

[24] Martin Siggel, Jan Kleinert, Tobias Stollenwerk,and Reinhold Maierl. TiGL: An Open Source Com-putational Geometry Library for Parametric AircraftDesign. Mathematics in Computer Science, 7(1):23,2019.

[25] Tobie van den Berg, Bastiaan Beijer, and Erwin Mo-erland. Application of an integrated and distributedmultidisciplinary product development frameworkto a multi-tier aircraft design case. In AIAA Aviation2019 Forum. American Institute of Aeronautics andAstronautics, June 2019.

[26] Stefan van der Elst, Erwin Moerland, Johnny vanLugtenburg, Luc Hootsmans, Sebastian Deinert,Martin Motzer, and Cristina Fernandez. Industrialservice-oriented process methodology. TechnicalReport D2.3, V. 1.0, ITEA 3, 2017.

[27] Daniel Veillard. Release of libxml2-2.9.9.http://mail.gnome.org/archives/xml/

2019-January/msg00000.html, 2019. [Online;accessed 11-December-2019].

[28] Helmut Vonhoegen. Einstieg in XML: Grundlagen,Praxis, Referenz. Rheinwerk Computing. Rhein-werk Verlag GmbH, Bonn, 8., aktualisierte auflageedition, 2015.

[29] W3C. XML Linking Language (XLink) Version1.1. www.w3.org/TR/xlink, 2010. [Online; ac-cessed 4-December-2019].

13

[30] W3C. The Extensible Stylesheet Language Family(XSL). www.w3.org/Style/XSL, 2017. [Online;accessed 4-December-2019].

[31] W3C. XML Path Language (XPath) 3.1. www.

w3.org/TR/xpath-31, 2017. [Online; accessed 4-December-2019].

[32] T. Zill, P. D. Ciampa, and B. Nagel. Multidis-ciplinary Design Optimization in a CollaborativeDistributed Aircraft Design System. In 50th AIAAAerospace Sciences Meeting. American Institute ofAeronautics and Astronautics, 2012.

14