Mission definition update

[ErwinMoerland]

After gaining experience with the major update of the missionDefinition node introduced in CPACS 3.0, several minor updates are proposed to:
a) simplify the mission definition where possible,
b) create more clarity in the definition,
c) extend the coverage of the mission definition for all kinds of airborne missions, and
d) extend the definition with pointPerformanceDefinitions

Attached is the proposal in an Excel overview, changes are marked red.

20200512 - proposal performanceCases CPACS 3.3.xlsx

According to the proposal, the missionDefinition will be re-located slightly to allow for a clear distinction between missionDefinitions and pointPerformances in cpacs:
/cpacs/performanceCases/missionDefinitions
/cpacs/performanceCases/pointPerformanceDefinitions

Thanks to: @HHOPs, Jacopo Zamboni, Carsten Christmann and Daniel Silberhorn for their valuable input.

#635 is a linked issue for discussions on whether to allow parameter lapses within the missionSegments or not

[ErwinMoerland]

Could somebody with experience in fuel budgets for aircraft missions comment on the following:

Within the node "/cpacs/performanceCases/missionDefinition/segmentBlocks/segmentBlock/fuelPlanningType", the following fuel types for fuel planning can be indicated:
designFuel: the fuel of the segmentBlock is part of the design mission
reserveFuel: fuel of the segmentBlock is part of the reserve mission
additionalFuel: fuel of this segmentBlock should be added to the designFuel, i.e. taxiIn fuel

Then the following holds: blockFuel = designFuel + additionalFuel. Total fuel requirement = blockFuel + reserveFuel.

Does this make sense?

[MarAlder]

First version of new missionDefinition implemented in dd128bd.

Small changes from me are highlighted in red again:
20200617 - proposal performanceCases CPACS 3.3.xlsx

Little question to line 127/128 in the excel document @ErwinMoerland @HHOPs: is this sequence part of the previous choice? Or a choice itself? Or really a sequence between the choice elements?

• XSD diagram

Point performance difinitions and performanceCases follow soon.

[MarAlder]

CPACSization of your proposals accomplished in missionDefinition branch

Next steps:

• Examine remaining questions highlighted in red: 20200617 - proposal performanceCases CPACS 3.3.xlsx
• Adjust example from @HHOPs to the new schema
• carefully check all modifications
• open new issue/discussion on a global flight case node

[ErwinMoerland]

After working on one of the implemented mission definitions, I would like to share following thoughts/comments:

1. the definition of under /cpacs/performanceCases/missionDefinitions/missions/mission
   in the current schema is not according to the proposal in excel format.

Schema:

<segmentBlockUIDs>
	<uID>DRA_TO</uID>
	<uID>DRA_climb_1</uID>
	<uID>DRA_cruise_1</uID>
	<uID>DRA_descent_1</uID>
	[...]
</segmentBlockUIDs>

Proposal:

<segmentUIDSequence mapType="vector">DRA_TO;DRA_climb_1;DRA_cruise_1;DRA_descent_1, [...] </segmentUIDSequence>

1.1) I would like to suggest renaming the main node to segmentUIDSequence, since currently both segmentBlock and segment references are allowed in the sequence.

1.2) Although I slightly prefer the vector version, using a list of multiple uID nodes or a single vector containing the uID references does not seem to make a big difference

2. Should we enforce the usage of segmentBlocks to at least have a clear method for reading-in the mission (i.e.: at least one segmentBlock should be defined)?

3. A proper linkage of the configuration settings within Issue Addition of configuration node to describe aircraft and payload configurations #636 to the segments within the mission definition is required. In the configuration settings, lapses of e.g. flap/slat settings, gear extension/retraction, usage of mixed propulsion techniques (combining multiple enginePerformanceMaps) etc. should be defineable. This should use a similar approach as within the missionDefinition (cf. Issue Mission definition - Parameter lapses within segment definitions #635).

[MarAlder]

I suggest to apply the proposal that is implemented in the schema. The uID-vectors will not be too long and following the official XML approach allows each preprocessor to check whether the uID really exists (using the W3C xsd:IDREF type). This increases the machine readability and may assist the tool developer since he must not care about checking for broken references (e.g., due to typos etc.). However, I agree with 1.1.

<segmentUIDSequence>
	<uID>DRA_TO</uID>
	<uID>DRA_climb_1</uID>
	<uID>DRA_cruise_1</uID>
	<uID>DRA_descent_1</uID>
	[...]
</segmentUIDSequence>

I leave the decision about point 2 to the users :) Point 3 needs indeed to be solved.

[ErwinMoerland]

I suggest to apply the proposal that is implemented in the schema. The uID-vectors will not be too long and following the official XML approach allows each preprocessor to check whether the uID really exists (using the W3C xsd:IDREF type). This increases the machine readability and may assist the tool developer since he must not care about checking for broken references (e.g., due to typos etc.). However, I agree with 1.1.

<segmentUIDSequence>
	<uID>DRA_TO</uID>
	<uID>DRA_climb_1</uID>
	<uID>DRA_cruise_1</uID>
	<uID>DRA_descent_1</uID>
	[...]
</segmentUIDSequence>

Ok, clearly reasoned. Agree!

[MarAlder]

An alternative is to consistently use the uIDReferenceVectorBaseType introduced in #641 (comment). It will not check the existence of the specified uIDs, but it checks at least for the correct spelling of IDs as specified in xs:NCName and the baseType makes quite clear what to expect from the data provider.

Thus:

• uID sequence:
  • (+) more XML-like
  • (+) preprocessor checks existence of uIDs
  • (-) more tags in data file (the sequence could become quite long)
  • (-) no consistent use in CPACS (sometimes vectors, sometimes the sequence)
• uIDReferenceVectorBaseType:
  • (+) consistent to our vector approach in CPACS
  • (+) more compact approach
  • (+) checks at least correct spelling of uIDs
  • (-) user could specify uIDs which do not exist in the data set, but the data set will be correctly validated

[ErwinMoerland]

An alternative is to consistently use the uIDReferenceVectorBaseType introduced in #641 (comment). It will not check the existence of the specified uIDs, but it checks at least for the correct spelling of IDs as specified in xs:NCName and the baseType makes quite clear what to expect from the data provider.

Thus:

* uID sequence:
  
  * (+) more XML-like
  * (+) preprocessor checks existence of uIDs
  * (-) more tags in data file (the sequence could become quite long)
  * (-) no consistent use in CPACS (sometimes vectors, sometimes the sequence)

* uIDReferenceVectorBaseType:
  
  * (+) consistent to our vector approach in CPACS
  * (+) more compact approach
  * (+) checks at least correct spelling of uIDs
  * (-) user could specify uIDs which do not exist in the data set, but the data set will be correctly validated

[ErwinMoerland]

An alternative is to consistently use the uIDReferenceVectorBaseType introduced in #641 (comment). It will not check the existence of the specified uIDs, but it checks at least for the correct spelling of IDs as specified in xs:NCName and the baseType makes quite clear what to expect from the data provider.
Thus:

* uID sequence:
  
  * (+) more XML-like
  * (+) preprocessor checks existence of uIDs
  * (-) more tags in data file (the sequence could become quite long)
  * (-) no consistent use in CPACS (sometimes vectors, sometimes the sequence)

* uIDReferenceVectorBaseType:
  
  * (+) consistent to our vector approach in CPACS
  * (+) more compact approach
  * (+) checks at least correct spelling of uIDs
  * (-) user could specify uIDs which do not exist in the data set, but the data set will be correctly validated

After discussion between @MarAlder and @ErwinMoerland, the uID sequence option is still preferenced due to the XML-like approach and the possibility of uID existence checks.

[ErwinMoerland]

Dear all,

I have improvised all open-ends concerning the finalization of the mission definition update for CPACS3.3 and provide my input to these below. Please let me know if I've missed anything.

Any suggestions or comments are highly appreciated!

1) I went over the latest definition of the schema and Excel-based overview. Added some additions and proposals for final adjustments in the following version of the table:

20201105 - proposal performanceCases CPACS 3.3

• highlighed green: implemented changes compared to the previous version of the table (20200716 from this comment)
• highlighted red: adjustments proposed compared to the current version 0f7fe45.

2) fuelPlanningType

Within the node "/cpacs/performanceCases/missionDefinition/segmentBlocks/segmentBlock/fuelPlanningType", the following fuel types for fuel planning can be indicated:
designFuel: the fuel of the segmentBlock is part of the design mission
reserveFuel: fuel of the segmentBlock is part of the reserve mission
additionalFuel: fuel of this segmentBlock should be added to the designFuel, i.e. taxiIn fuel

Then the following holds: blockFuel = designFuel + additionalFuel. Total fuel requirement = blockFuel + reserveFuel.

no reactions thus far, suggest to implement as suggested.

3) Superfluous nodes in the proposal (indicated by C. Liersch, DLR)

Nodes like <acceleration> and <deceleration> were present in the proposal. In the current proposal the seemingly superfluous nodes have been removed, e.g.: a deceleration is indicated as negative acceleration.

4) Observations arising from implementation test case of @MarAlder

Why choice between e.g. Mach and CAS? Can not both be constraining in the same segment?
Since both are velocity indications, these were 'linked' using a choice element. Especially in case of constraints (think climb profiles that are partly CAS and machNumber determined), it seems to make sense to remove the choice indeed. Other choices are already removed from the definition due to merging of related parameters such as and into a single setting, so no action needed anymore.

Should endCondition, mass and massFraction be obligatory to avoid empty segment definitions?
Yes they should be obligatory (1..1), good observation. Adjusted in the attached excel table.

endConditionRatio is probably often ranging from [0 .. endCondition]. Is 0 always an absolut value, or the endCondition of the previous segment? And what if, in the latter case, the endCondition type is different?
This is more extensively answered in 635.

• 0.0 reflects the start of the segment, so it must equal the state of the previous segment's end.
• 1.0 reflects the end of the segment, this state is used at the start of the following segment

Typical problem we are already discussing, I guess: If we have endConditionRatio = [0.0;0.1;0.8;1.0] and rateOfClimb = [10;30;30;10], what would be the value for endConditionRatio=0.9?
Suggestion to add information concerning the continuity of the constraint parameterisation (see also 635):
<continuitySetting> node having enum: {discrete, linear} as option. Provides information on how to interpret the parameter lapses within the segment: discrete steps (C0 continuity) or linear interpolation (C1 continuity).

• Example of C0: gears are retracted after a specific altitude is achieved. In fact this represents a discrete event
• Example of C1: the rateOfClimb is continuously reduced towards the end of a climb segment to reduce the amount of overshoot when the following segment (e.g.: cruise) is started

aircraft/model/requirements: following elements obligatory?: controllabilityCases, flightPerformanceCases, requiredPerformanceCases and trimCases

• flightPerformanceCases, controllabilityCases, trimCases not --> 0..1 (although a definition where none of the three are provided is senseless)
• requiredPerformanceCases yes --> 1..1

See also the attached updated excel-based overview of the performanceCases definition

[MarAlder]

Latest version of 20200617 - proposal performanceCases CPACS 3.3.xlsx including the changes due to the the above comments.

All changes are also tracket in the missionDefinition branch.