Addition of configuration node to describe aircraft and payload configurations

[ErwinMoerland]

It is suggested to add a node to the vehicle description in CPACS: /cpacs/vehicles/.../model/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

Within this node the following should be described:

• payload configuration
• aircraft configuration, controlling the following elements:
  • high lift devices + controlDistributors
  • landing gear, brakes, airbrakes
  • mass case transitions

[MarAlder]

A first implementation (21547a0) includes the needs from the loadCase working group (#637):

Control devices include all controllable elements, such as high lift devices, landing gear, brakes, airbrakes (and maybe afterburner as well).

In this context we also consided how we want to continue with the aircraft/model/global node. Maybe put the configuration node in there as well?

[MarAlder]

A current example from @HHOPs includes a configuration within the mission definition:

<configuration>
    <flaps relationalOperator="eq">0.0</flaps>
    <gear relationalOperator="eq">0.0</gear>
    <brake relationalOperator="eq">0.0</brake>
</configuration>

Is the relational operator required here or just used because it was defined like this in the schema at this point in time?

Furthermore, please check the completeness of the aircraft/analyses/trajectories/trajectory/ node. It looks like a powerful way to combine the general mission definition with aircraft specific information, such as configuration settings, atmospheric conditions or engine conditions.

[HHOPs]

I used the relational operator, as it was obligatory - would propose to set it optional, as a need can probably arise, when eventually introducing lapses for configuration changes (e.g. brake activation etc.)...

[MarAlder]

Ok, thanks for the clearification. I opened a dedicated brach for this issue where I propose the following:

In a first step I would try to avoid relational parameters as it has to be discussed how to deal with it when used by, e.g., aerodynamic analysis.

The mission definition (#634), load cases (#637) and maybe in future releases the aeroMaps (#505) could refer to this node by its uID.

[MarAlder]

Addition of control distributors as used in aeroMaps:

[MarAlder]

A configurationType has been added with #660 which can be used for aeroMaps, aeroCases etc. Here an example of the aeroMap:

It is furthermore implemented in the aeroCase element.

[MarAlder]

Since I was told that the aircraft/model/global node was originally intended for overall analysis results at the aircraft level, I set the configurations node back to aircraft/model (d989ece), as suggested at the very beginning.

Perhaps the systems node would be a possible location for the configurations element as well. However, since this node may be subject to possible adjustments in the course of the system definition for CPACS 3.4, the current proposal is to leave it under aircraft/model for the time being.

[elPlaneador]

Good structure so far!

Would it make sence to insert an array of segmentTypes, along which flight segmentType each configuration can be flown? Needed for Trajectory Analysis for Noise Assessment.

Would be great in CPACS V3.3

Could be look like: Clean configuration: aircraft/model/configurations/configuration[1]/<segmentTypes>descent;cruise;climb;taxi</segmentTypes>

Full Flaps + Slats configuration: aircraft/model/configurations/configuration[2]/<segmentTypes>descent;approach</segmentTypes>

Intermediate Flaps + Slats [1] configuration: aircraft/model/configurations/configuration[3]/<segmentTypes>descent;takeOff;climb;acceleration</segmentTypes>

Intermediate Flaps + Slats [2] configuration: aircraft/model/configurations/configuration[4]/<segmentTypes>descent;takeOff;climb</segmentTypes>

Intermediate Flaps + Slats [3] configuration: aircraft/model/configurations/configuration[5]/<segmentTypes>descent;takeOff;landing</segmentTypes>

The information, which flap setting has been intended for which segmentType is required to automize trajectory and procedure creation for the Noise Analysis. We need to know which flap and slat settings are intended to be used along approach and departure, even if any configuration could be used for both. Usually they are designated for specific flight phases.

[ErwinMoerland]

@elPlaneador thanks for the proposal! This kind of information linking should indeed be included.

Within linked Issue #634, this comment in specific, an initial suggestion for linking configuration settings to the mission segments is proposed. In this case, the cpacs/vehicles/../model/requirements/flightPerformanceCases/flightPerformanceCase node enables the requested assignment of configurations to specific segments of the referenced mission.

This mechanism allows the configurations node to stay mission-independent.

The <flightPerformanceCases> node within the <requirements>-definition on vehicle level intends to link all required information on mission/pointPerformance level:

• mission and point performance definitions,
• weightAndBalance cases,
• configuration settings,
• performanceMap settings.

The <requirements> node thereby forms the bridge between vehicle-specific information (weightAndBalance, configurations, performanceMaps) and flightPerformanceCases/controllabilityCases/trimCases (where the flightPerformanceCases include missions and pointPerformance definitions).

Is this a viable solution for the intended trajectory analyses?

[ErwinMoerland]

Forwarded todo from #635:

• [ ] check if the implementation of parameter lapses within the segments of the missionDefinition can hold 1:1 for providing configurational changes within the aircraft-specific node

[MarAlder]

Will be closed for v3.3. Last comment from @ErwinMoerland will be referenced in a new issue for upcoming releases.