CPACS root element
The Common Parametric Aircraft Configuration Scheme (CPACS) is an XML-based data format for describing aircraft configurations and their corresponding data.This XML-Schema document provides a description of the CPACS data structure that can be used for automatic validation as well as for documentation purposes. In this Schema, type declarations and element definitions are seperated. This means, there is e.g. a pointType class, containing x, y and z components. This class is then used in different places under different names (e.g. the "translation" node in "transformation" is made of pointType, meaning it has x, y and z subnodes.)
CPACS is an open source project published by the German Aerospace Center (DLR e.V.). For further information please go to http://software.dlr.de/p/cpacs/home/
You can display the text based version of CPACS in every text editor. Further tools are for example www.eclipse.org
Coordinate systems are a regular cause for ambiguous interpretation of data. In CPACS, the reference coordinate system is the CPACS-coordinate system. This coordinate system is used for most of the data. A single exception is made in order to keep aerodynamic data in an aerodynamic coordinate system. The following paragraphs outline the determination to known coordinate systems.
The CPACS coordinate system is the coordinate system identified by TIGL, CPACS's geometric library. It is a right-handed coordinate system. If an aircraft is defined in the CPACS coordinate system it will usually follow the directions listed in the table below.
Therefore, the CPACS coordinate system can be confused with the body-fixed coordinate system. While often the CPACS coordinate system and the body-fixed coordinate system overlap, this must not always be true. Several definitions for body-fixed coordinate systems exist (x-axis through nose and tail, x-axis perpendicular to nose plane). For non-symmetric aircraft, body-fixed coordinate systems become even more complicated. Hence, analysis tools should stick to the CPACS-Coordinate system. It remains to the designer to model the geometry accordingly.
The CPACS coordinate system does not rotate with flow. Hence, aerodynamic calculations do rotate their flow relative to the CPACS-coordinate system. If not stated explicitly different, e.g. for target lift-coefficients, results are returned in the CPACS coordinate system, i.e. the cfx-coefficient is parrallel to the CPACS x-Coordinate, regardless of the way the geometry is defined.
The following table gives an "best-practice" advice on how to locate a geometry within CPACS. Different approaches are, of course, valid as well.
|x||tailwards||from nose to tail|
|y||spanwise||from symmetry plane to the right wingtip|
|z||upwards||from landing gear to tip of vertical tailplane|
The following pictures give an example for a geometry that is defined in alignment with the CPACS coordinate system, i.e. the body coordinate system overlaps with the CPACS coordinate system.
The aerodynamic analysis is relative to the CPACS coordinate system. That is, the angle of attack is represented by the dashed orange line. Results of the aerodynamic calculation are given in the CPACS coordinate system.
The following pictures give an example for a geometry that is not defined in alignment with the CPACS coordinate system. It is a valid CPACS file, but chosen here for demonstrative purposes.
The body axes and the CPACS coordinate system do not align. That is, the origin of the geometry is not at CPACS (0,0,0) but at a point in positive x- and z-direction.
Again, the aerodynamic analysis is relative to the CPACS coordinate system. That is, the angle of attack is represented by the dashed orange line. Results of the aerodynamic calculation are given in the CPACS coordinate system.
There are no explicit attributes describing units in CPACS. The general convention is that all values must be given in the following SI-units:
or in derived units, e.g.:
The only non SI unit used throughout CPACS is the angle in degrees [°]. For the sake of an intuitive use the angles are given in degrees rather than in radian [rad].
To provide a better overview, it is possible to split up a CPACS dataset into several files. This can be done by inserting an <externaldata> node at an arbitrary position into the datatset. This node contains a <path> node with a URI to the external file(s), followed by one or more <filename> nodes, containing each a name of a file to be included at that position. Below, an example of such external data is given:
<?xml version="1.0" encoding="utf-8"?> <cpacs xsi:noNamespaceSchemaLocation="cpacs_schema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <vehicles> <profiles> <wingAirfoils> <externaldata> <path>file:://airfoils</path> <filename>NACA0010.xml</filename> <filename>NACA2412.xml</filename> </externaldata> <airfoil uID="NACA0012"> <name>NACA 0012 Airfoil</name> <pointList>...</pointList> </airfoil> </wingAirfoils> </profiles> </vehicles> <cpacs>
Such an external file would look like:
<?xml version="1.0" encoding="utf-8"?> <airfoil uID="NACA0010"> <name>NACA 0010 Airfoil</name> <pointList>...</pointList> </airfoil>
The file would be included completely, except for its title line <?xml version="1.0" encoding="utf-8"?> . This concept can also be used recursively (external files of external files), then it is important to prevent circle connections (file "A" loading file "B" loading file "C" loading again file "A" ...).
For path URI adresses, the trailing file separator "/" may be omitted. Below, some examples for path URIs are given:
A CPACS dataset with external files, being loaded by a special library like the TIVA XML Interface TIXI, shall collect all its external datafiles and build up a single tree from them. A validation against this schema is only possible for such a single tree file; the <externaldata>nodes are not recognized by it. To preserve the information, necessary to split the file up into external files again later, externaldata information is maintained within three attributes of the former external top node:
The single tree for the example above would look like:
<?xml version="1.0" encoding="utf-8"?> <cpacs xsi:noNamespaceSchemaLocation="cpacs_schema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <vehicles> <profiles> <wingAirfoils> <airfoil uID="NACA0010" externalFileName="NACA0010.xml" externalDataDirectory="file://airfoils" externalDataNodePath="/cpacs/vehicles/profiles/wingAirfoils"> <name>NACA 0010 Airfoil</name> <pointList">...</pointList"> </airfoil> ... <airfoil uID="NACA0012"> <name>NACA 0012 Airfoil</name> <pointList>...</pointList> </airfoil> </wingAirfoils> </profiles> </vehicles> <cpacs>
The CPACS-dataset often uses references between nodes. Typically, these references define connections between parts that are located somewhere else in the dataset (e.g. a wing is connected to a fuselage, a specific engine from the "engines"-section is used, ...). These connections are made, using UID attributes. This means, that a node, that shall be referenced (e.g. an engine type, an airfoil geometry, a mission definition, ...), gets an additional UID attribute, consisting of a unique (in the scope of the whole CPACS dataset) text, like:
<fuselage uID="ATTAS fuselage">...
Such a node with a UID is then typically referred to by a subnode, like:
<wing> <name>ATTAS main wing</name> <parentUID isLink="True">ATTAS fuselage</parentUID> ...
It is absolutely essential to ensure that a UID attribute is unique within the whole dataset, as searching for this name is the only way to resolve the reference!
This is also important for testing. All nodes that refer to an UID like e.g. parentUID carry an additional attribute "isLink". If this attribute is true the dataset can be tested for valid UIDs.
UID can either be named according to their appearance in the hierarchy e.g. uid=""mainWingKinkSection" or by automatically placing identifiers e.g. via processor runtime dates
Sometimes it might be useful to specify a part of the aircraft as symmetric instead of holding all the data twice in nearly identical form in the dataset (e.g. left and right wing are usually identical, except for the sign of the y-coordinate). Hence, some parts offer the option to set a symmetry attribute for them, like:
This attribute explains that the whole part with all its subnodes is symmetric to the given plane. Possible planes are:
All nodes, e.g. parentUID, in CPACS that refer to a component that holds symmetry attribute, e.g. wing, have to carry the symmetry attribute as well.
The symmetry attribute may take three values: symm, def, full:
<wing uID="ATTAS main wing" symmetry="x-z-plane"> ... <segments> <segment uID="ATTAS main wing innersegment"> ...
In the example above, to refer to the "other" side of the wing on must use the definition as such:
<loadcase> ... <segments> <segment> <segmentUID isLink="True" symmetry="symm">ATTAS main wing inner segment</segmentUID> <strip>...
For large data sets (e.g. increments of aerodynamic coefficients due to control surface deflections) it is advantageous to map them via vectors and arrays instead of using single nodes for each data value. The following definition of vectors and arrays, indicated by the mapType attribute, is therefore introduced in CPACS:
The vector is meant as a one-dimensional-array. In such a node, the values are given in a semicolon separated list:
The array is meant for multi-dimensional-arrays. Again, the values are contained in a semicolon separated list. An array is always preceded by a sequence of vectors, containing the dimensions and index values of it:
<altitude mapType="vector">1000.; 2000.; 3000.</altitude> <incrementMaps> <incrementMap uID="incMap_b3ac2"> <controlSurfaceUID>InnerWingFlap</controlSurfaceUID> <controlParameters mapType="vector">-1;-0.5;0;1</controlParameters> <dcl mapType="array">11.; 12.; 13.; 14.; 15.; 21.; 22.; 23.; 24.; 25.; 31.; 32.; 33.; 34.; 35.</dcl>
|Control parameter = -1||Control parameter = -0.5||Control parameter = 0||Control parameter = 1|
|Altitude = 1000m||11.||12.||13.||14.|
|Altitude = 2000m||21.||22.||23.||24.|
|Altitude = 3000m||31.||32.||33.||34.|
Control parameters are abstract parameters, linking a generic floating point value to a certain status of a control device (e.g. control surface, landing gear, suction system, brake parachute, ...). For control surfaces, such a data pair (control parameter and control surface deflection status) is called a <step> and the ordered list of all steps for a control surface forms its deflection <path>.
The control parameter values for each step are arbitrary floating point values. However, it is strongly recommended to use values between -1. and +1., or between 0. And +1. (depending on the type of control surface). The smallest and the largest value implicitly define the maximum deflection limits. It is mandatory, that the value “0.” is within the specified range, as this value is treated as undeflected and used to specify a “clean” aircraft configuration (e.g. used in the clean aero performance map). It is recommended, but not mandatory to specify a <step> with a <controlParameter> of 0. Consequently, no <controlParameter> must be used twice within a single <path> definition. Deflection values between two specified steps are handled by linear interpolation.
The following example shows the usage of control parameters within a control surface deflection path definition:
<controlSurfaces> <trailingEdgeDevices> <trailingEdgeDevice uID="InnerWingFlap"> ... <path> ... <steps> <step> <controlParameter>-1</controlParameter> <hingeLineRotation>-20.</hingeLineRotation> </step> <step> <controlParameter>-0.5</controlParameter> <hingeLineRotation>-10.</hingeLineRotation> </step> <step> <controlParameter>0</controlParameter> <hingeLineRotation>0.</hingeLineRotation> </step> <step> <controlParameter>1</controlParameter> <hingeLineRotation>5.</hingeLineRotation> </step> </steps> ...
At some places in CPACS, an atmosphere has to be selected (e.g. for connecting an altitude with a certain pressure or density). Currently, CPACS does only support a single atmospheric model: The ICAO Standard Atmosphere (ISA) from 1993 (see ICAO Doc 7488/3 'MANUAL OF THE ICAO STANDARD ATMOSPHERE', third edition, 1993) It covers temperature, pressure, density, speed of sound, dynamic viscosity and kinematic viscosity with respect to altitude. In CPACS, 'altitude' means what is called 'geopotential altitude' (H) in the ISA reference document and is given in [m]. For details, see ISA manual, section 2.3, page E-viii f. ISA covers a range from -5000 m to 80000 m.
Temperature offsets are introduced on top of the definitions in the ISA manual (which does not cover such variations). The offset model is based upon the idea that the pressure at a fixed geopotential altitude is independent from temperature offset (pressure altitude). The temperature offset changes only the density (following rho = p / Gas Constant / T) (and viscosity, of course)
Release in August 2019
Release in Jul 2018
Release in Jul 2016
Release in Nov 2015
CPACS 2.3 is the fourth public release of CPACS. Major changes include:
Release in Feb 2015
Release in May 2014
Release in May 2013
Release in Nov 2012
Release in Mar 2012
Release in Jul 2011
Release in Feb 2011
Release in Nov 2010
Release in Aug 2010
Release in May 2010
Release in Feb 2010