search

DLR-SL / CPACS

CPACS - Common Parametric Aircraft Configuration Schema
http://dlr-sl.github.io/CPACS/
Apache License 2.0
78 stars 38 forks source link

configurationDefinitions: changes for v3.5 release version #825

Closed MarAlder closed 9 months ago

MarAlder commented 10 months ago

Result of last stakeholder meeting: The configurationDefinitions node needs to be revised from what was presented in the v3.5-beta release.

What was presented: grafik grafik grafik grafik

MarAlder commented 10 months ago

Remark: In the following, I just want to give some initial ideas on how to revise the latest proposal. It may be subject to further changes and will be further discussed in a working group on 6 November. The latest implementation of the development branch can always be found at dlr-sl.github.io/CPACS/.

I suggest going back to the old definition (as implemented in CPACS v3.4) and just extending the configurationDefinition node with some new requirements: grafik

We can, as before, create one or more configurationDefinition elements that serve as base configurations, so to speak.

Note: We decided to rename the node from configuration to configurationDefinition to make it clear that this describes a possible configuration, not the IS state of the aircraft. This is consistent with missionDefinition or pointPerformanceDefinition.

ControlElements

grafik

The controlElements continue to serve as a compilation of all components that can be set/adjusted/switched on/off on the aircraft. These include controlSurfaces, landingGears, engines (in progress), systemArchitectures (new in v3.5). Each of these components requires a node that translates the abstract controlParameter into a physical state variable. In the new systemArchitecture node this could be called controlDevices (or controlFunctions as in the chassis? Is that confusing?) to either enable/disable the whole system or just some connections. For the systems, I assume that multiple controlDevices/controlFunctions will be needed in the future, so I chose a controlDevices container that currently only contains a state function (open for renaming). This node gets a uID which can be referenced directly as a controlDevice or indirectly via a controlDistributor (see above).

grafik

The analysis nodes then reference a base configuration via the configurationDefinitionUID and directly the controlDevice or controlDistributor elements of the respective components. E.g: grafik

So, basically, everything remains as it was before when it comes to the controlElements 😌 (just the renaming of configuration -> configurationDefinition).

@ChristianHesse, I'm not shure how we deal with cabinPressure. Has this node ever been used? Could it also be realized via a controlParameter in the compartment node or so?

EnergyCarriers

grafik

Additionally, we should include energyCarriers which are not defined by the controlParameter. These are things that can be absorbed/refueled by liquids, gases or chemicals. Basic idea: Reference to a tank, reference to a predefined energyCarrier and information about the fill level/charge status.

Payload

Third point: payload. This summarises everything that the aircraft can be equipped with, e.g. passengers, cargo, medical equipment, military equipment, etc. This node is still a work in progress (see #725) and will probably not be ready for v3.5.

@ErwinMoerland, @HHOPs, @CLiersch, @rmaierl, @sdeinert, @jbussemaker, @marcengelmann, ...

MarAlder commented 9 months ago

This revision was approved at a dedicated developer meeting on this topic. It will therefore be implemented in v3.5.