Mission definition - Parameter lapses within segment definitions

[ErwinMoerland]

@HHOPs suggested to enable parameter lapses within a segment through vectorization of the constraint variables.

For this, within the segment definition of the missionDefinition node, two nodes should be added:

uID of the endCondition to which a profile of constraintSettings is provided
vector indicating the ratios of the constraintSettings profile with respect to the provided referenceEndCondition, ranging from 0 to 1.

If the vector is defined, the provided constraintSettings are expected to be vectors with the same length providing ratio-value pairs.

Example: for referenceEndCondition '' (i.e.: flown distance in z direction of the segment), a vector of and is provided to define a climb profile within a single segment.

pro:

no separation between segments needed to describe e.g. a start or climbProfile -> less "bulky" mission definition

con:

enabling the usage of vectors leads to multiple ways to define similar mission definitions and thereby significantly complicates wrapping mission analysis tools to CPACS. Use segmentBlocks combining segments instead?

• work out both options (vectorization or using multiple segments combined in a segmentBlock)
• compare and discuss options, decide on whether to introduce vectorization or not

#634 is a linked issue

[ErwinMoerland]

Input from CPACS systems ontology workshop relevant for this issue:

for performing detailed onboard systems analyses, configurational changes need to be controllable within segments (flaps setting, landing gear up/down, airbrakes, etc.). Although these settings are mainly aircraft specific and might probably become part of the node (cf. issue #636), a procedure should be added enabling these kind of settings.

[MarAlder]

Thank you @HHOPs for providing an example data set. Let us first work out the vectorization proposal before continuing with the block definition approach.

One segment constraint setting @HHOPs provides reads for example:

<constraints>
      <machNumber relationalOperator="le" mapType="vector">0.0;0.85;0.5;0.75;1.0;0.75</machNumber>
      <rateOfDescent relationalOperator="ge" mapType="vector">0.0;10.0;0.2;100.0;0.8;100.0;1.0;10.0</rateOfDescent>
      <rateOfTurn relationalOperator="eq">0.0</rateOfTurn>
      <prioritySetting>flightPath</prioritySetting>
</constraints>

This way of defining a sequence of ratios and corresponding values in the same vector would be new to CPACS. Maybe we can use one of the existing concepts, like using vectors of the same length. Therefore, I was thinking about adding some kind of <constraintRatios mapType="vector"> or so. Would it be too restrictive if we specified that at least all vectors must have the same length (option 1.1)? Otherwise, we would have to alternatively introduce a ratio vector for each variable (option 1.2).
1.1:

<constraints>
    <constraintRatios mapType="vector">0.;0.2;0.5;0.8;1.</constraintRatios>
    <machNumber relationalOperator="le" mapType="vector">0.85;0.8;0.75;0.75;0.75</machNumber>
    <rateOfDescent relationalOperator="ge" mapType="vector">10.0;100.0;100.0;100.0;10.0</rateOfDescent>
    <rateOfTurn relationalOperator="eq" mapType="vector">0.;0.;0.;0.;0.</rateOfTurn>
    <prioritySetting>flightPath</prioritySetting>
</constraints>

1.2:

<constraints>
    <machNumberRatios mapType="vector">0.;0.5;1.</machNumberRatios>
    <machNumber relationalOperator="le" mapType="vector">0.85;0.75;0.75</machNumber>
    <rateOfCescentRatios mapType="vector">0.0;0.2;0.8;1.0</rateOfCescentRatios>
    <rateOfDescent relationalOperator="ge" mapType="vector">10.0;100.0;100.0;10.0</rateOfDescent>
    <rateOfTurn relationalOperator="eq">0.0</rateOfTurn>
    <prioritySetting>flightPath</prioritySetting>
</constraints>

@HHOPs, thinking of the various use-cases possible for aircraft, military aircraft or even helicopters, what would be in this vectorized approach a good compromise between compactness (each variable must be processed by tools) and flexibility? My feeling is that option 1.1 could be more stable when it comes to a reconstruction of variables, because option 1.2 requires interpolation if the ratio vectors are of different lengths, right?

[HHOPs]

I think version 1.1 would be the more generic and simpler approach - which I would prefer. It is possible to refine for all entries - or in the opposite, enter constant values, if not needed for various entries...

[ErwinMoerland]

I'd also opt for version 1.1, due to its clarity and usage of existing CPACS concepts.

I have three comments to the proposed implementation though:

1. In the Excel file, already a placeholder for the constraintRatios vector is provided. The corresponding proposal would look like this:

<constraints>
    <referenceEndCondition>altitudeUID</referenceEndCondition>
    <endConditionRatio mapType="vector">0.;0.2;0.5;0.8;1.</endConditionRatio>
    <machNumber relationalOperator="le" mapType="vector">0.85;0.8;0.75;0.75;0.75</machNumber>
    <rateOfDescent relationalOperator="ge" mapType="vector">10.0;100.0;100.0;100.0;10.0</rateOfDescent>
    <rateOfTurn relationalOperator="eq" mapType="vector">0.;0.;0.;0.;0.</rateOfTurn>
    <prioritySetting>flightPath</prioritySetting>
</constraints>

so the vectors base on a fraction of the endCondition having uID="altitudeUID" (should logicallly be part of the current segment / segmentBlock). This implies: when parameter lapses are allowed, these have to be in relation to (one of) the endCondition(s) of the segment.

2. We should also make clear linear interpolation is expected for in-between ratio values encountered during the mission simulation (i.e.: at an altitude of 0.9 * the altitude in the referenceEndCondition, the targeted rateOfDescent should be:

rateOfDescent(altitude=0.9 * altitude_referenceEndCondition) = 100.0 + ( (10.0-100.0) / (1.-0.8) ) * (0.9-0.8) = 55.0

3. It seems to not make sense to provide constraint settings for an endConditionRatio value = 0.0. This might lead to discrepancies in connecting the segments. I suggest to describe in the documentation not to use 0.0 as first endConditionRatio value (numerically, any value > 0.0 will do), since actually the end state of the previous segment should be used at the start of the current segment. If the connection needs to be explicitly forced, the entry should be explicitly added to the previous segment at referenceEndCondition = 1.0:

add to previous segment:

<constraints>
    <referenceEndCondition>someUID</referenceEndCondition>
    <endConditionRatio mapType="vector">1.</endConditionRatio>
    <machNumber relationalOperator="le" mapType="vector">0.85</machNumber>
    <rateOfDescent relationalOperator="ge" mapType="vector">10.0</rateOfDescent>
    <rateOfTurn relationalOperator="eq" mapType="vector">0</rateOfTurn>
    <prioritySetting>flightPath</prioritySetting>
</constraints>

current segment:

<constraints>
    <referenceEndCondition>altitudeUID</referenceEndCondition>
    <endConditionRatio mapType="vector">0.2;0.5;0.8;1.</endConditionRatio>
    <machNumber relationalOperator="le" mapType="vector">0.8;0.75;0.75;0.75</machNumber>
    <rateOfDescent relationalOperator="ge" mapType="vector">100.0;100.0;100.0;10.0</rateOfDescent>
    <rateOfTurn relationalOperator="eq" mapType="vector">0.;0.;0.;0.</rateOfTurn>
    <prioritySetting>flightPath</prioritySetting>
</constraints>

looking forward to your comments

[ErwinMoerland]

I will work out the segmentBlock - segments alternative soon and post the result in this issue

[ErwinMoerland]

I have taken the climb segment of the DRA reference mission and created the two options for parameter lapses for comparison:

Option 1 - using vectors within the constraint settings of a segment

• pro: clean, straightforward method for specifying constraint lapses within a segment
• con: multiple ways to define changing constraints available: 1) using a combination of segments and 2) using vector notation within segments. This requires proper (and more complex) preprocessing, to avoid semantically different interpretations between tools/users (*).

(*) Compare to multiple ways of defining geometry: 1) using engineering parameters (length, sweep, dihedral) and 2) using absolute coordinates (x, y, z), this also requires a proper geometric interpretation library to avoid semantically different interpretations.

<cpacs>	
	<performanceCases>
		<missionDefinitions>
			<missions>
				<mission uID="DRA_eval_mission">
					<description>DRA evaluation mission</description>
					<name>DRA_evaluation_mission</name>
					<segmentUIDSequence mapType="vector">DRA_takeOffFlyOutbound;DRA_deploy;DRA_flyInboundAndLand;DRA_reserves</segmentUIDSequence>
				</mission>
			</missions>
			<segmentBlocks>
				<segmentBlock uID="DRA_takeOffFlyOutbound">
					<name>DRA_TO_and_flyOutbound_segment</name>
					<segmentDirection>outbound</segmentDirection>
					<segmentUIDSequence>DRA_TO;DRA_climb_1;DRA_cruise_1;DRA_descent_1</segmentUIDSequence>
					<fuelPlanningType>designFuel</fuelPlanningType>
				</segmentBlock>
				<segmentBlock uID="DRA_deploy">
					[...]
				</segmentBlock>
				<segmentBlock uID="DRA_flyInboundAndLand">
					[...]
				</segmentBlock>
				<segmentBlock uID="DRA_reserves">
					[...]
				</segmentBlock>
			</segmentBlocks>
			<segments>
				<segment uID="DRA_TO">
					[...]
				</segment>
				<segment uID="DRA_climb_1">
					<name>DRA_climb_1_segment</name>
					<description>Climb after Take-off</description>
					<segmentType>climb</segmentType>
					<endCondition>
						<positionGeo>
							<altitude relationalOperator="ge" uID="altClimb">11000.0</altitude>
						</positionGeo>
					</endCondition>
					<constraints>
						<referenceEndCondition>altClimb</referenceEndCondition>
						<endConditionRatio mapType="vector">0.1;0.8;1.0</endConditionRatio>
						<machNumber relationalOperator="le" mapType="vector">0.8;0.8;0.8</machNumber>
						<rateOfClimb relationalOperator="eq" mapType="vector">30.0;30.0;10.0</rateOfClimb>
						<rateOfTurn relationalOperator="eq" mapType="vector">0.0;0.0;0.0</rateOfTurn>
						<prioritySetting>flightPath</prioritySetting>
					</constraints>
				</segment>
				<segment uID="DRA_cruise_1">
					[...]
				</segment>
				[...]
			</segments>
		</missionDefinitions>
		[...]
	<performanceCases>
<cpacs>	

Option 2 - using segmentBlocks to provide the parameter lapse during a segment

• pro: only a single method available to define changes in constraints, no vector read-in required within segments
• con: gets a bit bulky due to the extra segments and segmentBlocks to be defined, adds extra dimension: a segmentBlock will contain segmentBlocks combining segments

<cpacs>	
	<performanceCases>
		<missionDefinitions>
			<missions>
				<mission uID="DRA_eval_mission">
					<description>DRA evaluation mission</description>
					<name>DRA_evaluation_mission</name>
					<segmentUIDSequence mapType="vector">DRA_takeOffFlyOutbound;DRA_deploy;DRA_flyInboundAndLand;DRA_reserves</segmentUIDSequence>
				</mission>
			</missions>
			<segmentBlocks>
				<segmentBlock uID="DRA_takeOffFlyOutbound">
					<name>DRA_TO_and_flyOutbound_segment</name>
					<segmentDirection>outbound</segmentDirection>
					<segmentUIDSequence>DRA_TO;DRA_climb_1;DRA_cruise_1;DRA_descent_1</segmentUIDSequence>
					<fuelPlanningType>designFuel</fuelPlanningType>
				</segmentBlock>
				<segmentBlock uID="DRA_deploy">
					[...]
				</segmentBlock>
				<segmentBlock uID="DRA_flyInboundAndLand">
					[...]
				</segmentBlock>
				<segmentBlock uID="DRA_reserves">
					[...]
				</segmentBlock>
				<!-- the following segmentBlock is added -->
				<segmentBlock uID="DRA_climb_1">
					<name>DRA_climb_1_segment</name>
					<description>combines all segments representing the climb schedule for the climb_1 segment</description>
					<segmentUIDSequence>DRA_climb_1_1;DRA_climb_1_2;DRA_climb_1_3</segmentUIDSequence>
					<fuelPlanningType>designFuel</fuelPlanningType>
				</segmentBlock>
			</segmentBlocks>
			<segments>
				<segment uID="DRA_TO">
					[...]
				</segment>
				<!-- the vector entries are split over multiple segments, will be combined in segmentBlock with uID "DRA_climb_1"-->
				<segment uID="DRA_climb_1_1">
					<name>DRA_climb_1_segment</name>
					<segmentType>climb</segmentType>
					<endCondition>
						<positionGeo>
							<!-- [EM] represents the 0.1 * segmentBlock endCondition case -->
							<altitude relationalOperator="ge">1100.0</altitude>
						</positionGeo>
					</endCondition>
					<constraints>
						<machNumber relationalOperator="le">0.8</machNumber>
						<rateOfClimb relationalOperator="eq">30.0</rateOfClimb>
						<rateOfTurn relationalOperator="eq">0.0</rateOfTurn>
						<prioritySetting>flightPath</prioritySetting>
					</constraints>
				</segment>
				<segment uID="DRA_climb_1_2">
					<name>DRA_climb_1_segment</name>
					<segmentType>climb</segmentType>
					<endCondition>
						<positionGeo>
							<!-- [EM] represents the 0.8 * segmentBlock endCondition case -->
							<altitude relationalOperator="ge">8800.0</altitude>
						</positionGeo>
					</endCondition>
					<constraints>
						<machNumber relationalOperator="le">0.8</machNumber>
						<rateOfClimb relationalOperator="eq">30.0</rateOfClimb>
						<rateOfTurn relationalOperator="eq">0.0</rateOfTurn>
						<prioritySetting>flightPath</prioritySetting>
					</constraints>
				</segment>
				<segment uID="DRA_climb_1_3">
					<name>DRA_climb_1_segment</name>
					<segmentType>climb</segmentType>
					<endCondition>
						<positionGeo>
							<!-- [EM] represents the 1.0 * segmentBlock endCondition case -->
							<altitude relationalOperator="ge">11000.0</altitude>
						</positionGeo>
					</endCondition>
					<constraints>
						<machNumber relationalOperator="le">0.8</machNumber>
						<rateOfClimb relationalOperator="eq">10.0</rateOfClimb>
						<rateOfTurn relationalOperator="eq">0.0</rateOfTurn>
						<prioritySetting>flightPath</prioritySetting>
					</constraints>
				</segment>
				<segment uID="DRA_cruise_1">
					[...]
				</segment>
				[...]
			</segments>
		</missionDefinitions>
		[...]
	<performanceCases>
<cpacs>	

please provide your comments on which version you prefer, looking forward to your response!

[ErwinMoerland]

still to be determined: how to define the req'd method for interpolation between the vector entries (option 1) OR between the segments within a segmentBlock (option 2) - should a "continuity setting" be added (step change, linear, ...)?

[HHOPs]

Dear @ErwinMoerland, thanks a lot for working out both proposals in a compareable way! Basically, both options fullfill the basic task of providing sufficient parameter lapses over a stretch of the flown trajectory. Nevertheless Option 1 is still the "way to go" for me - as it describes the basic idea behind it (paramter lapses over a segment) - in the most intuitive way. Using Option 2 would also be potentially more error prone, as the segments are linked together via a separate list - instead of the vector version, where the respective values stand side-by-side... Furthermore Option 1 seems to be far more compact, thus better readable - from my impression...

Is there general differences in the use of the mission definition between the tools: E.g. we use the mission as a "command set" / aka "virtual pilot" - for the utilization of the auto-pilot features within flightSim. Therefore we are never going to precisely fly the defined mission. E.g. at start and end of the mission we try to minimise deviations of the effective trajectory wrt. to the defined mission. During the mission we might end up with bigger deviations - due to the respective physical capabilities of the analyzed aircraft.

The continuity issue is from my perspective hardy solveable, as each segment can have vastly separate conditions that have to be monitored: Consider a climb segment with a defined/commanded "ClimbRate". The mission designer might tend to keep that rate always at bit above 0, in order to assure, that the endCondition is safely met - or even reached. Therefore it is quite likely that the mission aircraft is still in climb, when it hits this endCondition (e.g. altitude). As this would usually trigger a cruise segment, there is quite likly a constant flight level commanded - which would contradict the overshoot, the aircraft is still performing at the begin of this segment... I think we would need a different strategy in order to assure a "transient free" mission - e.g. going over pre-, current- and post-segments - allowing a constant, smooth command signal. This topic definitely needs more discussion! Up until now, we handle these topics tool-internal...

[ErwinMoerland]

Thanks @HHOPs for the clear considerations.

All in all, it seems the best way for implementation is enabling parameter lapses within segments of the mission definition through vectorizing the respective constraint settings of a segment: option 1. Although it increases the pre-processing overhead, since an extra layer is added to the hierarchy, it indeed provides the most intuitive buildup mechanism for (complex) missions.

When this is implemented, it should be made clear how the mission is build up hierarchically and what kind of lapses are expected.

The mission definition contains:

1. the <mission> node, containing the <startCondition> and a sequence of <segmentBlockUIDs>.
2. the <segmentBlocks> node, grouping multiple <segments> and providing overall information concerning the block of segments: 1) constraints in the form of an endCondition or given flightPath, 2) variableSegments and the corresponding variableConditions in case a segment should be adjusted such to meet the segmentBlock's endCondition, 3) fuelPlanningType (designFuel, reserveFuel, additionalFuel), 4) segmentDirection and numberOfRepetitions.
3. the <segments> node, containing the detailed information per segment: 1) segmentType, 2) endConditions, 3) constraints, 4) environmentalConditions OR massFraction OR mass.
4. (optional) the specification of <constraint> lapses within <segments> using the newly defined doubleVectorConstraintBaseTypes, in relation to a parameter within the <endCondition> definition within the segment.

An example excerpt showing how it would look like within the mission definition:

<segment uID="DRA_climb_1">
	<name>DRA_climb_1_segment</name>
	<description>Climb after Take-off</description>
	<segmentType>climb</segmentType>
	<endCondition>
		<positionGeo>
			<altitude relationalOperator="ge" uID="altClimb">11000.0</altitude>
		</positionGeo>
	</endCondition>
	<constraints>
		<constraint>
			<referenceEndConditionUID>altClimb</referenceEndConditionUID>
			<endConditionRatio>0.1;0.8;1.0</endConditionRatio>
			<continuitySetting>linear</continuitySetting>
			<machNumber relationalOperator="le">0.8;0.8;0.8</machNumber>
			<rateOfClimb relationalOperator="eq">30.0;30.0;10.0</rateOfClimb>
			<rateOfTurn relationalOperator="eq">0.0;0.0;0.0</rateOfTurn>
			<prioritySetting>flightPath</prioritySetting>
		</constraint>

	</constraints>
</segment>

so the <referenceEndConditionUID> directs to the altitude endCondition of 11000.0 [m]
the endConditionRatio ranges from 0 to 1, where 0 reflects the altitude at the start of the segment (inherited from the previous segment) and 1 reflects the value of the endCondition referred to. Now if we assume the altitude at the start of the segment to be 0 [m], the vectorized constraint lapse resolves into:

altitude = 1100.0;8800.0;11000.0
machNumber = 0.8;0.8;0.8
rateOfClimb = 30.0;30.0;10.0
rateOfTurn = 0.0;0.0;0.0

I hope the proposed approach can be directly used within the <configuration> node (cf. Issue #636) as well:

• to provide discrete events or lapses of configurational changes (e.g.: flaps/gear/brake settings) for the respective segments
• maybe even to provide different performanceMap settings within a segment (?), e.g.: to allow for adding electrical power for specific parts of the segment when hybrid electric propulsion is considered.

Todo's:

• since the node <referenceEndCondition> provides a uID-based reference to a parameter within the list of <endConditions>, the <doubleVectorConstraintBaseTypes> require an optional uID as attribute.
• decision on and corresponding addition of the <continuitySetting> node with enum: discrete, linear. Provides information on how to interpret the parameter lapses within the segment: discrete steps (C0 continuity) or linear interpolation (C1 continuity).
• providing a value of the endConditionRatio = 0 seems to make no sense if continuitySetting = linear. This can probably only be solved by using common sense, the vectors should have start value > 0.0 in that case. Any other ideas?
• addition of an extra "in-between" node <constraint>, such that multiple sets of constraints depending on different endConditions/ratios can be provided.
• check if the implementation can hold 1:1 for providing configurational changes within the aircraft-specific <configurations> node

[ErwinMoerland]

One more thing :)

The definition of a climb profile basing on CAS and machNumber is now straightforward and can be done within the segment.

Example basing on 250 kt / 300 kt / M 0.78 climb profile (see here for a corresponding graphic and explanation):

<endCondition>
	<positionGeo>
		<altitude relationalOperator="ge" uID="altClimb">10058.4</altitude> <!-- FL330 -->
	</positionGeo>
</endCondition>
<constraint>
	<referenceEndConditionUID>altClimb</referenceEndConditionUID>
	<endConditionRatio>0.0;0.303</endConditionRatio> <!-- FL0, FL100 -->
	<continuitySetting>discrete</continuitySetting>
	<CAS relationalOperator="le">128.61;154.33</CAS><!-- 250 [kt], 300 [kt]-->
	<machNumber relationalOperator="le">0.78;0.78</machNumber>
	<prioritySetting>velocity</prioritySetting>
</constraint>

-> from FL0 until FL100, the vehicle should fly at a velocity less than or equal to CAS = 250 kt or M = 0.78. In this first segment at low altitudes, the constraint on CAS is triggered.
-> from FL100 until FL330, the aircraft should fly at a velocity less than or equal to CAS = 300 kt or M = 0.78. In this second segment, the vehicle starts by increasing velocity until 300 kt, the constraint on maximum machNumber triggers from the crossover altitude onwards