As we are approaching the next CPACS release, I would like to present the major enhancements and adjustments we have been discussing over the last months. It should be emphasized that these are not yet final decisions and everyone is invited to participate in the current topics.
The initiators and main contributors to a proposal are identified by a label (e.g., 
). If you would like to contribute to a specific topic you may just contact us and we will arrange an exchange to the responsible persons.
The 
label forwards you to the online documentation. The corresponding GitHub issues are linked as #123 and contain all details of the previous and ongoing discussions. A comprehensive overview of the corresponding GitHub activities is given in the Kanban board:
Release schedule
The typical CPACS release candidate should not contain too many changes. Since we are still working on some details (e.g., linking the mission definition and aircraft configurations or possibly the consideration of modified engine maps), but most of the suggestions are ready for practical use, a beta version will be released towards the end of October. This release will summarize all proposals in one schema file, provide all example files and of course the documentation. On the basis of this beta version, topic-specific community meetings will be scheduled for November. A detailed planning and invitation will be issued in the next days. Here we will jointly discuss the scheduling of the release candidate (depending on how many modifications are still necessary) and the final release, which is roughly scheduled at the end of this year.
In parallel to these developments, we continue the work on system architectures in CPACS which are scheduled for the next release V3.4.
Landing gears
With the previous definition of the landing gear no detailed geometrical assembly could be defined. This proposal replaces the old definition, which now offers the choice between a set of preliminary design parameters and a more detailed assembly. The latter was developed as part of a student research project at Airbus DS and finalized in close cooperation with Bauhaus Luftfahrt.
Geometry and Mass
New profile based structural elements
Following a proposal from Airbus DS, new profile-based structural elements were added. In this context the illustrations were revised. Feedback from DLR-SL was that the profiles T1 and T2 were not really necessary as an addition to the T-profile, because they can still be transformed at a later point, for example when placing the stringers. So far, however, no real counter-argument has been received. If this topic concerns you, please let me know.
New symmetry flags
With the current CPACS version it is not possible to remove symmetry of a component having a parent component with symmetry being set. Corresponding TiGL functions do exist, but cannot be explicitly addressed via CPACS (see DLR-SC/tigl#703). Therefore as an interim solution it is proposed to add none and inherit to the list of possible symmetry types.
Kinks in profiles
TiGL 3.1 provides a new feature that allows kinks in profiles. To support this the pointListXYZVectorType had to be extended by the elements the vectors kinks and parameterMap. Further information about the TiGL implementation can be found at the TiGL homepage.
Rib posts in wing structures
The ribCrossSection element is extended by a ribPost element to represent the connection between wing rib and wing spar.
Parametric fuselage profiles
The definition of fuselage profiles is extended by parametric standard profiles including super ellipses and rectangles with rounded corners.
Additional mass break down elements
The massBreakdown is extended by the mWalls element to account for the mass of the new internal walls as introduced in CPACS 3.1. Furthermore the mMiscellaneous element, which did only exist under mWingStructure, has been added mFuselageStructure, mPowerUnits, mSystems and mFurnishing.
Moments of inertia products becoming optional
In conceptual and pre-design the moments of inertia Jxy, Jxz and Jyz are often not known. Thus, they are set to optional.
Load case analysis
New ground and flight load case definitions
The loadCase definition has been revised. One requirement was that the load distributions could be specified not only for wings and fuselages but also for control surfaces. Therefore the dynamicAircraftModel node is replaced by ../model/analysis/global/loadApplicationPointSets. Each set references a specific component, such as wings, fuselage or control surfaces, via its uID.
New aeroCases
As part of the load case definition (#637) the aeroCase type has been updated as well in order to provide a consistent aerodynamik breakdown with respect to the various aircraft components.
Simplified load envelopes
In the course of the revision of the load case definition (#637), we propose to simplify the load envelope definition. In order to implement it to the final release feedback is required from the stakeholders who need to further process the data.
Addition of flight envelopes
As needed for the new load case definition (#637), a new flightEnvelopes element was added to ../aircraft/model/global
Flight control
Update of mission definition
For the upcoming release there are some minor adjustments/extensions in the definition of missions and point performances. Please note that the proposal includes a re-location of missionDefinition to allow for a clear destinction between missionDefinitions and pointPerformances:
Parameter lapses in mission segments
The proposal includes parameter lapses over the mission segments in order to better control mission simulations. Please have a look at the pro's and con's of this proposal and share your opinion with us.
New elements for controllability requirement analysis
The ../aircraft/model/performanceRequirements (--> new version ../aircraft/model/requirements) as well as the ../analysis/flightDynamics (--> new version: flightDynamics) element have been modified.
Kinematic description of control surface tracks
A revision of the track element serves to describe detailed flap kinematics in CPACS. From the intiative of the Virtual Product House in Bremen especially the description of the joint positions and the illustration of the track types were revised and successfully applied in first control surface FEM analysis.
General CPACS features and bug fixes
New base types
CPACS just provides a stringVectorBaseType. New string restriction patterns allow for a more precise defintion of vector datatypes such as:
- doubleVectorBaseType
- doubleArrayBaseType
- intVectorBaseType
- posIntVectorBaseType
- uIDReferenceVectorBaseType
Introduction of a configuration node
A new node was added to the vehicle description in CPACS: /cpacs/vehicles/../model/global/configurations/configuration, where the configuration settings are provided and linked to through uID's. Required for: weightAndBalance analysis, loadCase definitions, mission and point performance analysis.
Multiple increment maps in aeroLimitsMap
In the current CPACS Version 3.2 the incrementMap element was missing under incrementMaps. This bug is now fixed.
Superfluous attribute mapType set to optional
CPACS users know it well: the vectors and arrays contain the mapType="vector" attribute. This is set to optional and will be removed in future releases, because the schema (and so the documentation) explicitly provide the correct data type (see this tutorial). Tixi was already adopted to read vetors without the mapType attribute (see Tixi#143).
