search

DLR-SL / CPACS

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

Finalization performanceRequirements & missionDefinitions #716

Closed ErwinMoerland closed 3 years ago

ErwinMoerland commented 3 years ago

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

Concerning missionDefinitions

Concerning segmentBlocks

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

Concerning segments

CarstenChristmann commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Concerning pointPerformanceDefinitions

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

<pointPerformanceUIDs>
   <uID>Roll_Authorities_Req_01</uID>
   <uID>Roll_Authorities_Req_02</uID>
   <uID>Roll_Authorities_Req_03</uID>
</pointPerformanceUIDs>
MarAlder commented 3 years ago

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: grafik grafik

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

/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: grafik

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? grafik

/../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

grafik

old: grafik

new: grafik

MarAlder commented 3 years ago

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: grafik

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 commented 3 years ago

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: grafik grafik

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.

grafik

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: grafik

new: grafik

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

ErwinMoerland commented 3 years ago

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: grafik

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 commented 3 years ago

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

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

ErwinMoerland commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

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

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.

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

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

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.

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

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

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

right

ok, contrary to the startCondition?

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

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

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

ErwinMoerland commented 3 years ago

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? grafik

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 commented 3 years ago

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 :smirk:. 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 commented 3 years ago

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