Finalization performanceRequirements & missionDefinitions

[ErwinMoerland]

I have finalized creating the extensive performanceCases node for 5 missions of the Diabolo project.

Some issues arose, in my opinion small enough to be considered finetuning the CPACS v3.3-RC towards the official release.

Concerning flightPerformanceRequirements

• the differences in node-naming for the performanceRequirements seems confusing.
  current: /cpacs/.../performanceRequirements/flightPerformanceReqs/flightPerformanceReq
  suggest to rename to: /cpacs/.../performanceRequirements/flightPerformanceRequirements/flightPerformanceRequirement
• /cpacs/.../performanceMaps/.../specificPerformanceMap does not need attribute uID (both the engine and aerodynamic performanceMaps)

Concerning missionDefinitions

• When adding child missionDefinitions, can the order of the obligatory children be pre-set to missions, segmentBlocks, segments (currently inserts: segments, missions, segmentBlocks)
• /cpacs/../missionDefinitions/missions/mission/startCondition/positionXYZ is added without children. Force ../X, ../Y, ../Z to be defined?

Concerning segmentBlocks

For XPATH: /cpacs/../missionDefinitions/segmentBlocks/segmentBlock/variableSegments/variableSegment:

• no uID attribute needed (no need to link to this node)
• how to link to endConditions that have children, e.g. use: range or range/x or x?

Concerning segments

• /cpacs/.../missionDefinitions/segments/segment/segmentType xsd:restriction needs following additions:

<xsd:enumeration value="warmUp"/>
<xsd:enumeration value="loiter"/>
<xsd:enumeration value="massFraction"/>
<xsd:enumeration value="mass"/>

(loiter is considered different than holding, which is representing a 1min-1min-1min-1min sequence)

• segmentType "storeRelease" needs an endCondition stating which stores are released. Proposed structure:

<endCondition>
    <releasedStores>
    	<releasedStore>
    		<uID>storeUID_1</uID>
    		<quantity>1</quantity>
    	</releasedStore>
    	<releasedStore>
    		<uID>storeUID_2</uID>
    		<quantity>3</quantity>
    	</releasedStore>
    </releasedStores>
   </endCondition>

• Credit distance Y/N cannot be set yet. Suggest to add optional node to /cpacs/.../missionDefinitions/segments/segment:

<creditDistance>

type: boolean
occurrence: 0..1
documentation: indicates whether the distance flown during the segment is to be taken into account in the segmentBlock's distance calculation

• In /cpacs/../segment/constraints/constraint, the node <continuity> is only needed in case parameterLapses are present. Consider making optional

• How do tools not considering parameterLapses within the modelling approach cope with constraints defined as parameterLapses? Should we somehow indicate the 'nominal value' of the constraint?

• Segments without <environment> OR <endCondition> OR <mass> OR <massFraction> can exist. Suggest setting minOccurs to 0 for this choice

• /../segments/segment/mass -> mass should not be obligatory. Suggest setting minOccurs to 0 for this choice

• /../segments/segment/endCondition/duration expects a time in HH:MM:SS. This is good! Adjust in documentation (now states duration in [s]

• /../segments/segment: <massFraction> could be renamed to <fuelMassFraction> for clarity, <mass> could be renamed to <fuelMass> for clarity

• In /../segments/segment/endCondition/: endCondition has <positionXYZ/Z> to set the altitude, constraints has <altitude>. This seems inconsistent.

[CarstenChristmann]

Thank you @ErwinMoerland for sharing the issues and suggestions. Concerning the performanceRequirements node, release bfa7c91 provides the following node definition:

/cpacs/.../performanceRequirements/flightPerformanceReqs

This issue should be discussed in connection with #714.

[ErwinMoerland]

Thank you @ErwinMoerland for sharing the issues and suggestions. Concerning the performanceRequirements node, release bfa7c91 provides the following node definition:

/cpacs/.../performanceRequirements/flightPerformanceReqs

This issue should be discussed in connection with #714.

@CarstenChristmann : thanks for the feedback! The node names were correct in the nodes within the CPACS file (the schema made me do it right ;)), but wrongly formulated in the Issue above. I have updated using the correct naming (i.e.: updated performanceReqs to flightPerformanceReqs, etc.).

[ErwinMoerland]

Now added the pointPerformanceDefinitions from @CarstenChristmann in the data deck for Diabolo as well, following issues arose:

Concerning pointPerformanceDefinitions

• /cpacs/.../pointPerformanceDefinition/typeOfPointPerformance xsd:restriction needs following additions:

<xsd:enumeration value="level flight"/>

Concerning PerformanceRequirements

concerning /cpacs/vehicles/aircraft/model/performanceRequirements/controllabilityReqs/controllabilityReq/performanceMaps/.../specificPerformanceMap

• does not need attribute uID (both the engine and aerodynamic performanceMaps)

• for a given /../specificPerformanceMaps/specificPerformanceMap, next to the obligatory performanceMapUID, either segmentUIDs or pointPerformanceUIDs MUST be given

• suggest to allow multiple pointPerformanceUIDs per controllabilityReq to avoid unnessecary repetition (i.e.: multiple pointPerformanceDefinitions for a single requirement set having the same weightAndBalance and configuration settings):
  from /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUID to /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUIDs/uID

<pointPerformanceUIDs>
   <uID>Roll_Authorities_Req_01</uID>
   <uID>Roll_Authorities_Req_02</uID>
   <uID>Roll_Authorities_Req_03</uID>
</pointPerformanceUIDs>

[MarAlder]

the differences in node-naming for the performanceRequirements seems confusing.
current: /cpacs/.../performanceRequirements/flightPerformanceReqs/flightPerformanceReq
suggest to rename to: /cpacs/.../performanceRequirements/flightPerformanceRequirements/flightPerformanceRequirement

I gree and changed it accordingly.

/cpacs/.../performanceMaps/.../specificPerformanceMap does not need attribute uID (both the engine and aerodynamic performanceMaps)

Ok, uID has been removed.

When adding child missionDefinitions, can the order of the obligatory children be pre-set to missions, segmentBlocks, segments (currently inserts: segments, missions, segmentBlocks)

I have adjusted the order. But since the elements are combined in one `xsd:all element, where the order is arbitrary, it is just schema cosmetics.

/cpacs/../missionDefinitions/missions/mission/startCondition/positionXYZ is added without children. Force ../X, ../Y, ../Z to be defined?

A bit more restricted (56e418b). Please evaluate if these values can always be provided in this context:

For XPATH: /cpacs/../missionDefinitions/segmentBlocks/segmentBlock/variableSegments/variableSegment

• uID removed
• range/x|range/y|range/z added as valid variableConditions (d9293fd)

/cpacs/.../missionDefinitions/segments/segment/segmentType xsd:restriction needs following additions

Restrictions added. Interesting: 4min holdings just apply for FL140 and below wrt. PANS-OPS (see here).

Credit distance Y/N cannot be set yet. Suggest to add optional node to /cpacs/.../missionDefinitions/segments/segment

Added (4c6ed73).

segmentType "storeRelease" needs an endCondition stating which stores are released. Proposed structure

Implemented like this:

In /cpacs/../segment/constraints/constraint, the node <continuity> is only needed in case parameterLapses are present. Consider making optional

Done

Segments without <environment> OR <endCondition> OR <mass> OR <massFraction> can exist. Suggest setting minOccurs to 0 for this choice

Done (20246a3)

/../segments/segment/mass -> mass should not be obligatory. Suggest setting minOccurs to 0 for this choice

Should be resolved with the above change (20246a3). Or should we reorder the complete choice?

/../segments/segment/endCondition/duration expects a time in HH:MM:SS. This is good! Adjust in documentation (now states duration in [s]

Well observed (21d7ecc).

/../segments/segment: <massFraction> could be renamed to <fuelMassFraction> for clarity, <mass> could be renamed to <fuelMass> for clarity

Sounds good. Changed.

In /../segments/segment/endCondition/: endCondition has <positionXYZ/Z> to set the altitude, constraints has <altitude>. This seems inconsistent.

Well, you can provide endCondition/positionGeo/altitude, right?

/cpacs/.../pointPerformanceDefinition/typeOfPointPerformance xsd:restriction needs following additions

Yep

PerformanceRequirements [...] does not need attribute uID (both the engine and aerodynamic performanceMaps)

Fixed

suggest to allow multiple pointPerformanceUIDs per controllabilityReq to avoid unnessecary repetition (i.e.: multiple pointPerformanceDefinitions for a single requirement set having the same weightAndBalance and configuration settings):
from /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUID to /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUIDs/uID

Implemented in develop, but I want to consider @CarstenChristmann's opinion.

Further changes

• In @ErwinMoerland's example file I noticed that the choice between segmentUID, massFraction and fuelFraction is not always required. So I set it optional.

• Also following @ErwinMoerland's example file I noticed that the configurationUID is not consistent between the three performanceRequirements. Thus, I adopted the version from flightPerformanceRequirements to controllabilityRequirements and trimRequirements:

old:

new:

[MarAlder]

for a given /../specificPerformanceMaps/specificPerformanceMap, next to the obligatory performanceMapUID, either segmentUIDs or pointPerformanceUIDs MUST be given

This can be achieved by the following XSD structure:

However, this costs us the xsd:all element, i.e. the sequence is fixed with xsd:sequence. You also have to dig a little deeper into the meaning of the structure before you get it. If it is worth it, we can do it.

Edit: The above solution allows segmentUIDs and pointPerformanceUIDs at the same time, whereas at least one of the two must be given. It this was not the intention, an obligatory choice between segmentUIDs and pointPerformanceUIDs is of course possible as well - still need to go with xsd:sequence, though.

[ErwinMoerland]

Hi @MarAlder, thanks for all the swift implementations!

Here my comments to the open points:

When adding child missionDefinitions, can the order of the obligatory children be pre-set to missions, segmentBlocks, segments (currently inserts: segments, missions, segmentBlocks)

I have adjusted the order. But since the elements are combined in one `xsd:all element, where the order is arbitrary, it is just schema cosmetics.

I understand it is in fact only a cosmetic act. When working with the Schema to set-up a mission definition it might help in understanding the structure if the respective nodes are inserted 'in order'.

/cpacs/../missionDefinitions/missions/mission/startCondition/positionXYZ is added without children. Force ../X, ../Y, ../Z to be defined?

A bit more restricted (56e418b). Please evaluate if these values can always be provided in this context:

• The positionGeo probably needs latitude, longitude and altitude as obligatory. This is however something @HHOPs has a better view on.
• I'd say: for the endCondition positionXYZ can also have X and Z as obligatory. Range I would completely leave open (i.e.: x, y, z all optional), since a range/z would reflect a delta_altitude for a segment (i.e.: no range/x needed)

For XPATH: /cpacs/../missionDefinitions/segmentBlocks/segmentBlock/variableSegments/variableSegment
* range/x|range/y|range/z added as valid variableConditions (d9293fd)

That's a great solution. To make the list complete, also positionXYZ/x, positionXYZ/y, positionXYz/z, positionGeo/latitude, positionGeo/longitude, positionGeo/altitude should be added (e.g. positionXYZ/z reflects the absolute altitude, which might be a variable condition)

Segments without <environment> OR <endCondition> OR <mass> OR <massFraction> can exist. Suggest setting minOccurs to 0 for this choice

Done (20246a3)

/../segments/segment/mass -> mass should not be obligatory. Suggest setting minOccurs to 0 for this choice

Should be resolved with the above change (20246a3). Or should we reorder the complete choice?

I guess you're right and it has been resolved already. So no reordering needed!

In /../segments/segment/endCondition/: endCondition has <positionXYZ/Z> to set the altitude, constraints has <altitude>. This seems inconsistent.

Well, you can provide endCondition/positionGeo/altitude, right?

right! Problem solved 👍🏼

suggest to allow multiple pointPerformanceUIDs per controllabilityReq to avoid unnessecary repetition (i.e.: multiple pointPerformanceDefinitions for a single requirement set having the same weightAndBalance and configuration settings):
from /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUID to /cpacs/.../controllabilityReqs/controllabilityReq/pointPerformanceUIDs/uID

Implemented in develop, but I want to consider @CarstenChristmann's opinion.

@CarstenChristmann it's your call :)

Further changes

* [ ]  In @ErwinMoerland's example file I noticed that the choice between segmentUID, massFraction and fuelFraction is not always required. So I set it optional.

I have found one pointPerformanceDefinition where the fuelFractionwas missing. This is probably caused by a copy-paste error. I'd say this choice should always be required. Suggest to roll-back ;).

* [ ]  Also following @ErwinMoerland's example file I noticed that the configurationUID is not consistent between the three performanceRequirements. Thus, I adopted the version from `flightPerformanceRequirements` to `controllabilityRequirements` and `trimRequirements`:

old:

new:

Well-observed. I believe it makes sense to consistently add the configuration settings like you've proposed.

[ErwinMoerland]

for a given /../specificPerformanceMaps/specificPerformanceMap, next to the obligatory performanceMapUID, either segmentUIDs or pointPerformanceUIDs MUST be given

This can be achieved by the following XSD structure:

However, this costs us the xsd:all element, i.e. the sequence is fixed with xsd:sequence. You also have to dig a little deeper into the meaning of the structure before you get it. If it is worth it, we can do it.

Edit: The above solution allows segmentUIDs and pointPerformanceUIDs at the same time, whereas at least one of the two must be given. It this was not the intention, an obligatory choice between segmentUIDs and pointPerformanceUIDs is of course possible as well - still need to go with xsd:sequence, though.

although quite complex at first sight, it seems like a working solution to me. The schema thereby completely reflects the intention of how specific performanceMaps can be given for a (set of) segmentUIDs or pointPerformanceUIDs. Some proper documentation has to be added though (note to self ;))

[MarAlder]

Thanks for all the feedback. I see a lot of checkmarks ✔️

@CarstenChristmann, @HHOPs, @ErwinMoerland: some final remarks? I'll otherwise try to release tomorrow.

• XSD file
• Online documentations (chm file download)

[ErwinMoerland]

I just checked some parts related to the final comment in this Issue within the latest XSD. Looks good to me!

So if @CarstenChristmann and @HHOPs are ok as well, for me you're good to go :).

[HHOPs]

Dear @ErwinMoerland and @MarAlder,
from my point of view the mission definition has reached a good state - Thanks! Never the less I would like to leave some remarks here:

1. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/ should contain optional values for machNumber and calibratedAirSpeed

2. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/ should contain optional values for subsequent positional nodes (selection of local positions or fully geo-referenced defintions)...

3. The "Mission Start" definition (/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ and /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionGeo should be less optional in my view, as this is a dedicated point in space. Therefore x, y and lon, lat should be obligatory here. z and alt in these nodes should be optional, as they could be derived from a terrain model via initialization or trim routine... I personally prefer to use the /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/runway node (contains a rwy heading)...

4. Same remark as in 2. for the /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/runway/runwayStartPosition node. Furthermore I would propose a "distance" parameter (and eventually a lateral offset) - as we are placed on the runway centerline - which would be in a relative offset to the airport reference point or rwy threshold...

5. At a later stage the node /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ should state in which frame it is defined (NED, ...). This is especially crucial, as in subsequent uses of .../positionXYZ it is unclear, if these coordinates refer to a runway heading system or a global frame... Btw. the question of using a "flat earth" or a "geodetic reference" (WGS84, ...) has to be resolved in subsequent releases - as well as further environmental matters (EGM, WMM, ...).

6. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/constraints/constraint/ should contain optional elements as they are oposed parameters (heading angle vs. rotation angle counter)

7. The node .../prioritySetting should contain two optional strings: "speed" and "trajectory" - required for the flight control law to define its priorities...

8. Within /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition the following remarks:

9. The parameters .../calibratedAirSpeed and .../machNumber should be placed within a switch and optional - similar to point 1 in this listing... Optional is also a essential, as we derive a priorization - as in 7. of this list

10. .../positionXYZ and .../positionGeo should only contain optional values - as it is crucial to define "lines"/ "layers" to be crossed rather than a dedicated position (which is defined as "waypoint"). Therefore it is possible to define a segment to end in a cartesian distance or when first crossing over a geodetic position...

11. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition/heading should only take optional values as they are counteracting: .../heading vs. .../turnAngle - similar point 7. in this listing

12. The "range" node (/cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition/range) is an interesting addition to the segment definition as it allows an integration of the flown trajectory. Therefore I would like to propose it to be fully non-directional (not covered by x/y/z) - defined by a parameter "r" or similar. Then it is destinctive and a really good addition to .../positionXYZ.

Finally a question: The newly issued segments in /cpacs/vehicles/aircraft/model/performanceRequirements/flightPerformanceRequirements/flightPerformanceRequirement/configurations/specificConfigurationUIDs/specificConfigurationsUID/segments/segment directly reference the "Mission segments" - correct?

Best regards,

Richard

[MarAlder]

Well, at least my job is secured by you guys... 😏

Good idea numbering the (sub-)issues, so we can directly refert to it.

• 1. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/ should contain optional values for machNumber and calibratedAirSpeed

Ok, I can make the whole choice element optional. Note: this will enable users to provide data sets without a complete set of velocity and position.

• 2. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/ should contain optional values for subsequent positional nodes (selection of local positions or fully geo-referenced defintions)...

So, if I understand correctly: startCondition/positionsXYZ/positionXYZ and startCondition/positionsGeo/positionGeo?

• 3. The "Mission Start" definition (/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ and /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionGeo should be less optional in my view, as this is a dedicated point in space. Therefore x, y and lon, lat should be obligatory here. z and alt in these nodes should be optional, as they could be derived from a terrain model via initialization or trim routine... I personally prefer to use the /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/runway node (contains a rwy heading)...

Ok. Does this also apply to less detailed mission definitions in conceptual design, @ErwinMoerland?

• 4. Same remark as in 2. for the /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/runway/runwayStartPosition node. Furthermore I would propose a "distance" parameter (and eventually a lateral offset) - as we are placed on the runway centerline - which would be in a relative offset to the airport reference point or rwy threshold...

I can do that as an alternative choice to xyz. So either the sequence x,y,z or the sequence distance, lateralOffset. As this is an additional node we can also add this in a later release if you feel unsure.

• 5. At a later stage the node /cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ should state in which frame it is defined (NED, ...). This is especially crucial, as in subsequent uses of .../positionXYZ it is unclear, if these coordinates refer to a runway heading system or a global frame... Btw. the question of using a "flat earth" or a "geodetic reference" (WGS84, ...) has to be resolved in subsequent releases - as well as further environmental matters (EGM, WMM, ...).

Good point. Do we have a default for the reference system? Also something for the next release?

• 6. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/constraints/constraint/ should contain optional elements as they are oposed parameters (heading angle vs. rotation angle counter)

So making the choice element, which is the only obligatory element, optional, right?

• 7. The node .../prioritySetting should contain two optional strings: "speed" and "trajectory" - required for the flight control law to define its priorities...

currently implemented: velocity and flightPath. Is there a difference between speed and velocity as well as trajectory and flightPath?

• 8. Within /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition the following remarks:

• 9. The parameters .../calibratedAirSpeed and .../machNumber should be placed within a switch and optional - similar to point 1 in this listing... Optional is also a essential, as we derive a priorization - as in 7. of this list

right

• 10. .../positionXYZ and .../positionGeo should only contain optional values - as it is crucial to define "lines"/ "layers" to be crossed rather than a dedicated position (which is defined as "waypoint"). Therefore it is possible to define a segment to end in a cartesian distance or when first crossing over a geodetic position...

ok, contrary to the startCondition?

• 11. The switch in /cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition/heading should only take optional values as they are counteracting: .../heading vs. .../turnAngle - similar point 7. in this listing

I don't get it. You have the optional choice between heading and turnAngle. Therefore, both elements at the same time is not possible.

• 12. The "range" node (/cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition/range) is an interesting addition to the segment definition as it allows an integration of the flown trajectory. Therefore I would like to propose it to be fully non-directional (not covered by x/y/z) - defined by a parameter "r" or similar. Then it is destinctive and a really good addition to .../positionXYZ.

Good idea. So range could directly contain a double element, right?

• Finally a question: The newly issued segments in /cpacs/vehicles/aircraft/model/performanceRequirements/flightPerformanceRequirements/flightPerformanceRequirement/configurations/specificConfigurationUIDs/specificConfigurationsUID/segments/segment directly reference the "Mission segments" - correct?

Hmm, good observation. Was the plan not to reference the segments from the configuration itself, @ErwinMoerland and @HHOPs?

[ErwinMoerland]

Thanks @HHOPs!

Well, at least my job is secured by you guys... 😏

check :)

* [ ]  3. The "Mission Start" definition (`/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ` and `/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionGeo` should be less optional in my view, as this is a dedicated point in space. Therefore x, y and lon, lat should be obligatory here. z and alt in these nodes should be optional, as they could be derived from a terrain model via initialization or trim routine... I personally prefer to use the `/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/runway` node (contains a rwy heading)...

Ok. Does this also apply to less detailed mission definitions in conceptual design, @ErwinMoerland?

yes, fits. Little issue might be having to set the Y-coordinate in positionXYZ, when only 2D missions are flown (i.e. within the x-z plane). We could provide y=0.0 in those cases ;)

* [ ]  5. At a later stage the node `/cpacs/vehicles/performanceCases/missionDefinitions/missions/mission/startCondition/positionXYZ` should state in which frame it is defined (NED, ...). This is especially crucial, as in subsequent uses of `.../positionXYZ` it is unclear, if these coordinates refer to a runway heading system or a global frame... Btw. the question of using a "flat earth" or a "geodetic reference" (WGS84, ...) has to be resolved in subsequent releases - as well as further environmental matters (EGM, WMM, ...).

Good point. Do we have a default for the reference system? Also something for the next release?

yup, we might even start a general discussion on reference frames. For now, for conceptual design, the coordinates refer to a general "flat earth" mission with respect to the global frame within the mission definitions.

* [ ]  10. `.../positionXYZ` and `.../positionGeo` should only contain optional values - as it is crucial to define "lines"/ "layers" to be crossed rather than a dedicated position (which is defined as "waypoint"). Therefore it is possible to define a segment to end in a cartesian distance or when first crossing over a geodetic position...

ok, contrary to the startCondition?

yes makes sense.

* [ ]  12. The "range" node (`/cpacs/vehicles/performanceCases/missionDefinitions/segments/segment/endCondition/range`) is an interesting addition to the segment definition as it allows an integration of the flown trajectory. Therefore I would like to propose it to be fully non-directional (not covered by x/y/z) - defined by a parameter "r" or similar. Then it is destinctive and a really good addition to `.../positionXYZ`.

Good idea. So range could directly contain a double element, right?

Agreed!

* [ ]  Finally a question: The newly issued segments in `/cpacs/vehicles/aircraft/model/performanceRequirements/flightPerformanceRequirements/flightPerformanceRequirement/configurations/specificConfigurationUIDs/specificConfigurationsUID/segments/segment` directly reference the "Mission segments" - correct?

Hmm, good observation. Was the plan not to reference the segments from the configuration itself, @ErwinMoerland and @HHOPs?

yes, here the segments for which a spedificConfigurationUID holds can be listed.

The idea is to define configurations with in the configurations node under /cpacs/vehicles/../model/configurations/configuration[@uID]. Within the flightPerformanceRequirements node then one of these is chosen as default using the defaultConfigurationUID and - if wanted - optionally specific configurations (e.g.: takeoff/landing configuration, having external tanks attached, etc.) then be assigned to the respective individual segments using the XPATH above.

[MarAlder]

Remarks to Richard's sub-issues:

1. Let's follow this strategy: for now we continue to enforce the combination of velocity+position by mandatory choice elements, taking into account that the velocity values can be specified as 0. We then put this into practice and see if cases arise where specifying the velocity actually leads to problems. In this case, we can still set the velocity choice element to optional, thus maintaining backward compatibility of the data sets.
2. I think this was a misunderstanding
3. Ok, x,y and z obligatory for position as conceptual designers are ok with providing a 0 😏. For latitude, longitude and altitude I see different demands in the fidelity levels. Low-fi analyses usually only need the altitude information; high-fi analyses need lat and long information and derive the exact altitude from an altitude model. Therefore my decision now: all elements optional for the time being, so that all requirements are met. Make sure your tools can handle missing data at this point.
4. Ok, I don't want to remove the RC-version (x,y,z in cartesian coordinates) so short before release. So you get both, xyz and distance+lateralOffset as a choice.
5. see remarks above
6. It turned out to be a misunderstanding. Everything kept as it is.
7. Already implemented and approved by @HHOPs
8. nothing to do
9. done
10. done
11. The current schema already covers this. Nothing to do.
12. done
13. Nothing to do (see comment from @ErwinMoerland)

[MarAlder]

We found good solutions for the remaining issues concerning the missionDefinitions and performanceRequirements. Thanks @ErwinMoerland, @HHOPs and @CarstenChristmann for your efforts.