Skip to content
Snippets Groups Projects
Commit 8bbc1fc8 authored by gPauls-TUHH's avatar gPauls-TUHH
Browse files

fill up docu

parent 27b4c50b
No related branches found
No related tags found
1 merge request!24mission_analysis initial commit
Pipeline #1606230 waiting for manual action
Stage: build
Stage: deploy
Expand all Show whitespace changes
Inline Side-by-side
Showing
with 348 additions and 188 deletions
docs/documentation/analysis/mission_analysis/getting_started.md
+ 50
− 14
View file @ 8bbc1fc8
......@@ -6,7 +6,7 @@ Tickets :ticket: please: We are about to start! In this guide, we will show you
## Step-by-step
To be able to execute **mission_analysis**, you have to provide the following data beside your `aircraft_exchange_file`:
To be able to execute **mission_analysis**, you have to provide the following data beside your [Aircraft Exchange File](#acxml):
- `mission_data` (e.g. `design_mission.xml`)
- `aero_data` (polar files)
......@@ -23,10 +23,10 @@ To do so, you can either use:
Once your aircraft is ready, you only need to follow these steps to start your calculation:
1. Head over to `mission_analysis_conf` (more details [here](#config_file)). Assuming this file represents the version of the develop branch, edit the following nodes within `control_settings`:
- set `aircraft_exchange_file_name` and `aircraft_exchange_file_directory` to your respective settings,
- set `aircraft exchange file_name` and `aircraft exchange file_directory` to your respective settings,
- set the `plot_output` to false if you don't have `inkscape` or `gnuplot` installed or define `inkscape_path` and `gnuplot_path` if their directories are not registered in your system environments.
2. Open your terminal within the `mission_analysis` folder and run the **mission_analysis** executable.
3. Fasten your seatbelt: We are ready for takeoff!
3. Fasten your seatbelt: We are ready for takeoff! :airplane:
If everything is set up correctly, your first `design_mission` should land a few seconds later :star:
......@@ -35,7 +35,7 @@ If everything is set up correctly, your first `design_mission` should land a few
!!! note
If you are using a pre-calculated aircraft, **mission_analysis** will generate its results using parameters from the previous calculations. Therefore, the behavior for an initial execution can not be observed. Continue with [Further Iterations](#further_iterations).
Due to many dependencies between the [sizing tools](../../sizing/sizing.md), performance data and component parameters are quite off within the first iteration. This can lead to an unstable aircraft configuration that will fail the `design_mission` (e.g. wrongly sized engines can't climb to the initial cruise altitude). To avoid this, the [low-fidelity 3D Standard Mission](methods.md/#lowfi) (`design_mission::breguet`) is triggered if no previous mission calculation can be found. Unlike the ordinary mission calculation, this sub-version of the `design_mission` finishes after a rough estimation of the fuel consumption. Once this method is finished, the `masses_cg_inertia/maximum_takeoff_mass/mass_properties/mass` node is updated and this block is written into the `aircraft_exchange_file`:
Due to many dependencies between the [sizing tools](../../sizing/sizing.md), performance data and component parameters are quite off within the first iteration. This can lead to an unstable aircraft configuration that will fail the `design_mission` (e.g. wrongly sized engines can't climb to the initial cruise altitude). To avoid this, the [low-fidelity 3D Standard Mission](methods.md/#lowfi) (`design_mission::breguet`) is triggered if no previous mission calculation can be found. Unlike the ordinary mission calculation, this sub-version of the `design_mission` finishes after a rough estimation of the fuel consumption. Once this method is finished, the `masses_cg_inertia/maximum_takeoff_mass/mass_properties/mass` node is updated and this block is written into the [Aircraft Exchange File](#acxml):
```xml
<mission description="Mission data" tool_level="0">
......@@ -115,7 +115,7 @@ Due to many dependencies between the [sizing tools](../../sizing/sizing.md), per
## Further iterations {#further_iterations}
After the initial loop, we expect a robuster behavior which we can use to calculate the flight segments with an increased resolution. To achieve this, every segment is split into little time and way increments (only a few seconds/meters per increment) aiming for the trajectory points that were written into the `mission_XML`. In each increment, all relevant parameters are saved into a `mission_profile`. After the calculation is done, said `mission_profile` is exported as a CSV file into the `mission_data` directory. Depending on the amount of engines, used energy carriers and other inputs, the CSV may differ, but the standard look should be something like this:
After the initial loop, we expect a robuster behavior which we can use to calculate the flight segments with an increased resolution. To achieve this, every segment is split into little time and way increments (only a few seconds/meters per increment) aiming for the trajectory points that were written into the `mission file`. In each increment, all relevant parameters are saved into a `mission profile`. After the calculation is done, said `mission profile` is exported as a CSV file into the `mission_data` directory. Depending on the amount of engines, used energy carriers and other inputs, the CSV may differ, but the standard look should be something like this:
```csv
......@@ -123,7 +123,7 @@ Time [s]; Range [m]; Altitude [m]; FL [100 ft]; Mode name [-]; Total mass [kg];
```
Within the `aircraft_exchange_file` the `masses_cg_inertia/maximum_takeoff_mass/mass_properties/mass` node is updated when calculating a `design_mission`; for a `study_mission` it's the `mission/study_mission/takeoff_mass` node (more infos [here](mission_types.md)). Having a higher resolution also increases the amount of data in the `mission` block:
Within the [Aircraft Exchange File](#acxml) the `masses_cg_inertia/maximum_takeoff_mass/mass_properties/mass` node is updated when calculating a `design_mission`; for a `study_mission` it's the `mission/study_mission/takeoff_mass` node. Having a higher resolution also increases the amount of data in the `mission` block:
```xml
......@@ -324,11 +324,49 @@ Within the `aircraft_exchange_file` the `masses_cg_inertia/maximum_takeoff_mass/
## Mission Configuration {#configuration}
Now that we have successfully flown our first mission, let's see how you can tweak its input a little bit :sunglasses:
### Aircraft Exchange File
### Aircraft Exchange File {#acxml}
Within the `requirements_and_specifications` block of the `aircraft_exchange_file`, the following nodes can affect the behavior of **mission_analysis** (descriptions to be found within that file):
```plaintext
requirements_and_specifications
└── mission_files
├── design_mission_file
├── study_mission_file
├── requirements_mission_file
└── design_specification
├── propulsion
├── skinning
│ ├── thickness
├── configuration
│ ├── tank_definition
├── energy_carriers
└── requirements
├── top_level_aircraft_requirements
│ ├── maximum_structrual_payload_mass
│ ├── design_mission
│ ├── study_mission
│ ├── takeoff_distance
│ ├── landing_field_length
│ ├── icao_aerodrome_reference_code (once 4D missions are ready)
│ ├── flight_envelope
│ │ ├── maximum_operating_mach_number
│ │ ├── maximum_operating_velocity
│ │ ├── maximum_approach_speed
│ │ ├── maximum_operating_altitude
│ │ ├── maximum_altitude_one_engine_inoperative
│ │ ├── climb_or_descend_segment_gradient
├── additional_requirements
│ ├── landing_gear
```
The `mission_files` node simply saves the names of said files. Within `design_specification`, we extract everything from the propulsion system (including tanks) in order to analyze fuel consumption and thrust generation. In the `top_level_aircraft_requirements` node, we can find performance maxima and characteristics for `design_mission` and `study_mission`. The later provide nodes for the mission planning (initial cruise altitude and speed, fuel planning etc.). In `additional_requirements`, the `landing_gear` node tells us with which `friction_coefficient` and `braking_coefficient` our aircraft will be slowed down after touchdown.
### Configuration File {#config_file}
The `Control Settings` are standardized in UNICADO and will not be described in detail here. The program settings are structured like this (descriptions are in the `mission_analysis_conf.xml`):
The `control_settings` are standardized in UNICADO and will not be described in detail here. The program settings are structured like this (descriptions are in the `mission_analysis_conf.xml`):
```plaintext
Program Settings
└── Program Specific
......@@ -376,7 +414,6 @@ Program Settings
│ ├── Fidelity Level
│ ├── Mission Type
│ ├── Center Of Gravity Method
│ ├── Use Fuel Estimation Method
├── Rate Of Climb Switch
└── Precision
├── Acceleration Increment
......@@ -387,14 +424,13 @@ Program Settings
```
In the `Program Specific` node, you can specify if the specific air range (SAR) is plotted (when plotting is turned on in the `Control Settings`). In addition, you can allow the tool to exceed the maximum takeoff mass and fuel mass during the design loop. This can be useful when operating at extreme conditions where fluctuation above the maxima shall not trigger an exit immediately.
In the `program_specific` node, you can specify if the specific air range (SAR) is plotted (when plotting is turned on in the `control_Settings`). In addition, you can allow the tool to exceed the maximum takeoff mass and fuel mass during the design loop. This can be useful when operating at extreme conditions where fluctuation above the maxima shall not trigger an exit immediately.
In `General` you can decide how the needed fuel is estimated and you can tell **mission_analysis** in which way it shall behave in different flight segments.
In `general` you can decide how the needed fuel is estimated and you can tell **mission_analysis** in which way it shall behave in different flight segments.
The `Mode` node lets you choose the methods that are applied. Using the keyword `low`/`mid` you will trigger the low-fidelity/mid-fidelity version of the (Standard Mission)[methods.md] method. It also has three sub-methods to differentiate between `design_mission`, `study_mission` and `requirements_mission` which can be selected in the `Mission Type` node. Please mind that the low-fidelity method only accepts the `design_mission`. If you want to know what those missions actually do, head over to [Mission Types](#mission_types).
The `mode` node lets you choose the methods that are applied. Using the keyword `low`/`mid` you will trigger the low-fidelity/mid-fidelity version of the [Standard Mission](methods.md) method. It also has three sub-methods to differentiate between `design_mission`, `study_mission` and `requirements_mission` which can be selected in the `mission_type` node. Please mind that the low-fidelity method only accepts the `design_mission`. The `rate_of_climb_switch` will only affect the [Climb to Ceiling](mission_steps.md/#climb_to_ceiling_subparagraph) step of the `requirements_mission`. With this option, **mission_analysis** calculates the optimum rate of climb towards service ceiling.
Finally, in `Precision` you can set the parameters which will define the before mentioned increments of your mission profile.
Finally, in `precision` you can set the parameters which will define the before mentioned increments of your mission profile.
docs/documentation/analysis/mission_analysis/index.md
+ 15
− 8
View file @ 8bbc1fc8
# Introduction {#mainpage}
**mission_analysis** is an assessment tool that outputs the flown mission profile, saves characteristic parameters within that profile and checks if performance requirements are met. The following missions can be analyzed:
- `design_mission`
- `study_mission` (calculate off-design missions)
- `requirements_mission` (check top-level aircraft requirements and possible maxima like maximum operating altitude)
**mission_analysis** is an assessment tool that outputs the flown mission profile, saves characteristic parameters within that profile and checks if performance requirements are met. The following mission types can be analyzed:
- `design_mission`:
- Defines the mission for which the aircraft shall be optimized
- $MTOM$ is altered during the design process
- Exports the `mission profile` as a CSV file
- Except $MTOM$, all other results for the [Aircraft Exchange File](getting_started.md/#acxml) are saved in the `design_mission` node
- `study_mission`:
- Calculates off-design missions
- Exports a `mission profile` as a CSV file
- All results for the [Aircraft Exchange File](getting_started.md/#acxml) are saved in the `study_mission` node
- `requirements_mission`:
- Checks top-level aircraft requirements and possible maxima (like maximum operating altitude)
- In the [Aircraft Exchange File](getting_started.md/#acxml) only the `requirement_compliance` block is edited
Mentioned parameters include the energy consumptions which has a high impact on how the aircraft is sized. That's the reason why (unlike many other assessment tools) its `design_mission` calculation takes place within the design loop of our [RCE Workflow](../../../workflow.md).
Once your mission is calculated, you can choose from a wide range of profile data which allows you to further investigate what your aircraft actually does. Here's a little example graph which visualizes the engines' total fuelflow during a `design_mission`:
<div align="center">
<img src="figures/mission_profile.png" width="75%" alt="Mission Profile"/>
<img src="figures/mission_profile.png" width="85%" alt="Mission Profile"/>
</div>
......@@ -34,5 +43,3 @@ By now, only a [standard (3D) mission method](methods.md/#midfi) is implemented.
If you want a step-by-step guide to start your first calculation, head over to the [Getting Started](getting_started.md) section. We will show you some basic functionality and how to get your airplane into the air.
Further details about the methods can be found [here](methods.md).
If you want to know what the different mission types are used for and how they work, [click here](mission_types.md).
docs/documentation/analysis/mission_analysis/methods.md
+ 54
− 165
View file @ 8bbc1fc8
This diff is collapsed.
docs/documentation/analysis/mission_analysis/mission_steps.md 0 → 100644
+ 228
− 0
View file @ 8bbc1fc8
# Mission Steps {#mission_steps}
In this section, you will learn how **mission_analysis** interprets the different mission steps from the `mission file`. Beside that, we show you how the taxiing procedures are implemented.
## Mission Step Input Parameters
A mission step can consist of the following nodes:
- `configuration`: Aircraft configuration to identify the right polars for aerodynamic calculations (mandatory)
- `derate`: Thrust derate to (de)throttle the engines during the step (mandatory)
- `mode`: Defines the mode of the step (mandatory)
- `rating`: The engine's thrust rating (mandatory)
- `shaft_power_takeoff_schedule`: Defines the power the engines must provide for the aircraft systems (mandatory)
- `bleed_air_takeoff` Schedule: Defines bleed air offtakes the engines must provide for the aircraft systems (mandatory)
- `altitude`: Altitude at the end of this step.
- `calibrated_airspeed`: Airspeed at the end of this step
- `mach_number`: Mach number at the end of this step
- `rate_of_climb_limit`: Maximum rate of climb during this step
- `flight_management_system`: Indicator if a flight management system is implemented and what its cost index is (`cruise_step` only)
- `round_to_regular_flight_level`: Rounded flight levels to the multiples of 10 (`cruise_step` only)
- `auto_select_optimum_flight_level`: Switch to let **mission_analysis** decide what FL is the best (`cruise_step` only)
- `glide_path`: Angle between glide path and runway (`approach_step` only)
If you need further information about these, please head other to [Create Mission XML](../../sizing/create_mission_xml/index.md).
## Step Modes
In the following paragraphs, we focus on how the steps' `mode` will manipulate the `mission_profile` from start to landing.
### Takeoff {#takeoff_subparagraph}
The `takeoff` is composed of ground run (break release until lift-off) and first climb segment to screen height ($35\,ft$). First, the aircraft is accelerated from $ 0\,\frac{m}{s} $ to the lift-off velocity $ v_{LOF} $ utilizing the `acceleration increments` of the [Configuration File](getting_started.md/#config_file). According to [EASA's CS-25 rules](https://www.easa.europa.eu/en/document-library/easy-access-rules/easy-access-rules-large-aeroplanes-cs-25), $ v_{LOF} $ equals $ 110\,\%$ $v_{MU}$ (minimum unstick speed) for aerodynamically limited aircrafts and $ 108\,\%$ $v_{MU}$ for geometry limited aircrafts. To generalize the $v_{LOF}$ calculation, a more conservative approach has been implemented. Since the climb speed at screen height $v_2$ should always be (moderately) greater than the lift-off speed, the following approximation is used (all velocities are calibrated airspeeds):
$$
v_{LOF} \approx v_2 \geq 1.2 \cdot v_{stall} = 1.2 \cdot 0.94 \cdot v_{stall,\,1g} = 1.128 \cdot v_{stall,\,1g}
$$
The 1-g stall speed $v_{stall,\,1g}$ is the speed where lift $L$ is equal to the aircraft's weight $ m_{aircraft} \cdot g $ when operating at maximum lift coefficient $C_{L,\,max}$:
$$
L = m_{aircraft} \cdot g = \frac{1}{2} \cdot \rho \cdot v_{stall,\,1g}^2 \cdot C_{L,\,max} \cdot S_{ref}
\iff v_{stall,\,1g} = \sqrt{\frac{2 \cdot m_{aircraft} \cdot g}{\rho \cdot C_{L,\,max}\cdot S_{ref}}}
$$
After the aircraft's lift-off, it [climbs with constant speed](#climb_subparagraph) towards screen height to finish this segment.
### Accelerate {#accelerate_subparagraph}
`acceleration` segments activate the _change_speed_at_constant_ROC_ function. This mode is usually used for altitudes below $10\,000\,ft$ where the aircraft's speed is increased while retaining a given rate of climb (departure steps). To do so, the speed gap $\Delta v$ between segment start and end is divided into $n$ smaller steps using the [Configuration File's](getting_started.md/#config_file) `acceleration increment`. Then, for $n$ steps the aircraft's velocity is increased using the `acceleration increment`. For each increment, an iterative loop is initiated in which its end altitude is set like this:
$$
h_{end} = h_{start} + \Delta h = h_{start} + \sin(\frac{\gamma}{2 \cdot \overline{a}} \cdot (v_{start}^2 - v_{end}^2))
$$
before adapting the other _FlightConditions_ using the _set_segment_end_conditions_ function. Once the end altitude within the iteration loop doesn't change anymore, the parameters have converged. Hence, they are saved into the `mission profile` and the next increment will be calculated.
<div align="center">
<img src="figures/acceleration/iteration.gif" width="75%" alt="Acceleration flow chart"/>
</div>
### Change Speed {#change_speed_subparagraph}
See [Accelerate](#accelerate_subparagraph). Unlike `accelerate`, `change_speed` uses a (constant) given glide path angle from the `mission file` to derive a rate of climb. For this reason, it is used for deceleration during approach steps below $10\,000\,ft$ (ATC regulations demand certain glide path angles which can be maintained with this mode).
### Change Speed to CAS {#change_speed_to_CAS_subparagraph}
`change_speed_to_CAS` alters the calibrated airspeed while a given rate of climb from the `mission file` is maintained. It's an adaption of [Accelerate](#accelerate_subparagraph) for altitudes between $10\,000\,ft$ and the transition height $h_{transition}$.
### Change Speed to Mach {#change_speed_to_Mach_subparagraph}
`change_speed_to_Mach` alters the Mach number while a given rate of climb from the `mission file` is maintained. It's an adaption of [Accelerate](#accelerate_subparagraph) for altitudes above the transition height $h_{transition}$.
### Climb {#climb_subparagraph}
The `climb` mode activates the _change_altitude_at_constant_speed_ function.
To ensure that the aircraft maintains an efficient aerodynamic behavior, the calibrated airspeed is kept constant while the aircraft's altitude is increased/decreased by $\Delta h$. To achieve this, $\Delta h$ is split into $n$ steps by dividing it by the [Configuration File's](getting_started.md/#config_file) `altitude increment`. By default, the minimum rate of climb $ROC$ with which the new altitudes are reached is set to $100\,\frac{ft}{min}$. The actual $ROC$ is calculated using the glide path $\gamma$ while maintaining the total available thrust $T$:
$$
\gamma = \arcsin \left(\frac{T-D}{g\cdot m_{aircraft}}\right);
$$
$$
ROC = \sin(\gamma) \cdot v_{TAS};
$$
If no maximum $ROC$ is given by the `mission file`, $ROC$ will be taken from the equation above. Else, it is checked if the given $ROC$ limit is exceeded. If this is the case, $ROC$ is set to the maximum while adapting $\gamma$ and $T$ to it. Analogous to [Change Speed](#change_speed_subparagraph), the increment's _FlightConditions_ are looped until $\gamma$ has converged. Afterwards, they are saved into the `mission profile` and the next increment will be calculated.
### Climb to Cruise {#climb_to_cruise_subparagraph}
The `climb_to_cruise` mode adapts [Climb](#climb_subparagraph) with the difference that its minimum rate of climb is set to $ 0\,\frac{ft}{min}$. While climbing towards the initial cruise altitude, the air becomes thinner and colder which leads to an increasing Mach number. Once the design cruise Mach $M_{cruise}$ number is exceeded, a constant CAS climb would lead to compressibility effects which could worsen the aircraft's performance. Therefore, the Mach number is kept constant as soon as $M_{cruise}$ is reached. Therefore, $M_{cruise} \approx M_{transition}$.
<div align="center">
<img src="figures/transition_altitude.png" width="200px" alt="Transition Altitude"/>
</div>
The altitude at which this occurs is called transition altitude $h_{transition}$ (aka crossover altitude). $h_{transition}$ is defined as the geopotential pressure altitude at which calibrated airspeed and Mach number are representing the same value of true airspeed ($TAS_{Mach} = TAS_{CAS}$). Using the barometric formula, $h_{transition}$ is computed in the following way:
$$
h_{transition} = \frac{T_{h=0}}{\frac{\delta T}{\delta h}} \cdot \left(\frac{p_{transition}}{p_{h=0}}\right)^{\frac{R\cdot \frac{\delta T}{\delta h}}{g} - 1}
$$
$R$ represents the Gas Constant and $g$ the gravitational acceleration. Within the tropopause, the temperature gradient $\frac{\delta T}{\delta h}$ equals $-0.0065\,[K/m]$; above it is defined as $0\,[K/m]$. For $TAS_{Mach}$, you can simply use Mach number $M_{transition}$ and speed if sound $a_{transition}$ which can also be displayed in relation to sea-level conditions:
$$
TAS_{Mach} = M_{transition}\cdot a_{transition} = M_{transition}\cdot a_{z=0} \cdot\sqrt{\frac{T_{transition}}{T_{z=0}}}
$$
$TAS_{CAS}$ is computed using isentropic flow equations:
$$
TAS_{CAS} = a_{h=0} \sqrt{\frac{2}{\kappa - 1} \cdot \frac{\sqrt{T_{transition}}}{T_{h=0}}\cdot\left(\frac{q}{p_{transition}}+1\right)^{\frac{\kappa -1}{\kappa}}-1}
$$
Where the the stagnation pressure $q$ is derived from the calibrated airspeed:
$$
CAS = a_{h=0} \sqrt{\frac{2}{\kappa - 1} \cdot \left(\frac{q}{p_{z=0}}+1\right)^{\frac{\kappa -1}{\kappa}}-1}
$$
Finally, the following statement can be derived for the needed pressure ratio characterizing $h_{transition}$:
$$
\frac{p_{transition}}{p_{h=0}} = \frac{\left(1 + \frac{\kappa-1}{2} \cdot \left(\frac{CAS}{a_{h=0}}\right)^{2} \right)^{\frac{\kappa}{\kappa-1}} - 1}{\left(1 + \frac{\kappa-1}{2} \cdot M_{transition}^{2} \right)^{\frac{\kappa}{\kappa-1}} - 1}
$$
!!! note
To determine the cruise range for the [Cruise](#cruise-cruise_subparagraph) segment, the index on the `mission profile` where the aircraft reaches the `initial_cruise_altitude` is saved for later usage.
### Climb to Ceiling {#climb_to_ceiling_subparagraph}
This mode should only be used for `requirements missions`! This mode contains four segments:
1. [Climb to Cruise](#climb_to_cruise_subparagraph).
2. From there, climb to maximum operating altitude with $ROC = 100\,\frac{ft}{min}$ or with a automated maximum rate of climb by turning on the `rate_of_climb_switch`. Either way, the engines are set to `maximum continuous`.
3. Keep on climbing with $ROC = 100\,\frac{ft}{min}$. Once the engines fail, climb with $ROC = 50\,\frac{ft}{min}$ until they ultimately fail (end altitude = ceiling altitude).
4. Reset to cruise altitude and repeat step 2 with one engine inoperative.
### Change Flight Level {#change_flight_level_constant_ROC_subparagraph}
The `change_flight_level_constant_ROC` segment adapts the [Climb](climb_subparagraph) mode using a minimum rate of climb from the `mission file`. Typically, this option is used in cruise steps to initiate a flight level change. Due to the fact that the cruise altitude usually is way above the transition altitude, the Mach Number is kept constant during this altitude change (see [Climb to Cruise](#climb_to_cruise_subparagraph) for the explanation).
### Cruise {#cruise_subparagraph}
In this segment, the aircraft is moved forward with constant speed and $ROC = 0\,\frac{ft}{min}$. How long this `cruise` segment shall last, is determined by the `relative_segment_length` (`mission_file`) which will be applied to the estimated cruise range. To get the later, the descend range $R_{descend}$ is estimated using the [Breguet method](#lowfi). Then, the afore saved mission segment for reaching `initial_cruise_altitude` (ICA) provides $R_{ICA}$ leading us to the current `cruise` segment's range:
$$
R_{cruise} = R_{descend} - R_{ICA}
$$
To iterate through this range, it is split into $n$ steps using the [Configuration File's](getting_started.md/#config_file) `way_increment`. Analogous to [Change Speed](#change_speed_subparagraph), the increment's _FlightConditions_ are looped until its consumed fuel mass has converged. Afterwards, they are saved into the `mission profile` and the next increment will be calculated.
Even tough this mode is not used to climb, the `auto_select_optimum_flight_level` option (see `cruise_steps` in the `mission file`) can be switched on to alter the flight level during `cruise`. If a better specific air range can be obtained on another flight level, **mission_analysis** will test whether the aircraft would consume less fuel there. If this is the case, [Change Flight Level](#change_flight_level_constant_ROC_subparagraph) will take care of the altitude change. Since for regularity reasons discrete flight levels are mandatory, `round_to_regular_flight_level` assures that only permitted altitudes are applied.
!!! note
Even if the specific air range of another flight lever might be better, a flight level change can cost more fuel than it saves until the end of cruise! Of course, **mission_analysis** is smart enough to take this into account :nerd:
### Descend to Approach {#descend_to_approach_subparagraph}
`descend_to_approach` is used to initiate a descend segment from the current cruise altitude towards approach $(10\,000\,ft)$. It uses the same functions the [Climb](#climb_subparagraph) mode does with the difference that its minimum rate of climb is set to $0\,\frac{ft}{min}$. Like in [Climb to Cruise](#climb-climb_subparagraph), the transition altitude $h_{transition}$ will presumably be crossed in this segment. Therefore, the aircraft first descends with a constant Mach number. When $h_{transition}$ is reached, it continues with a constant CAS climb.
!!! note
Since the calibrated airspeed won't further decrease below $h_{transition}$, the demanded velocity for the segment's end (segment's `calibrated_airspeed` node in the `mission file`) must be reached before that altitude. If this is not the case, the aircraft will be automatically decelerated by activating a [Change Speed](#change_speed_subparagraph) segment in between.
### Descend {#descend_subparagraph}
This mode adapts [Climb](climb_subparagraph) with the difference that its minimum rate of climb is set to $0\,\frac{ft}{min}$ and a glide path angle $\gamma$ is read from the `mission file`. This comes in handy to meet ATC regulations for lower altitudes. Hence, `descend` should be used for approach steps below $10\,000\,ft$.
!!! note
After the last descend segment, **mission_analysis** expects the aircraft to be at threshold crossing height ($50\,ft = 15.24\,m$). Otherwise, [Landing](#landing) might cause problems!
### Glide Slope Interception {#level_glide_slope_interception_subparagraph}
With `level_glide_slope_interception` the final approach slope is initiated by [cruising](#cruise_subparagraph) at glide slope interception altitude ($3000\,ft$) with constant calibrated airspeed. The distance until the aircraft reaches the interception point $\Delta x$ is derived from the landing glide slope $\gamma$ (usually it's about $3°$), total range $R_{total}$ and the aircraft's current position:
$$
\Delta x = R_{total} - \frac{h_{current}}{\tan(-\gamma)} - R_{current}
$$
!!! warning
If $\Delta x$ becomes negative, the interception was overflown. This can happen if e.g. the engine produces too much thrust while decelerating or the drag is too low. Either way, **mission_analysis** will try to land the aircraft, but the result may not be ATC conform.
### Landing {#landing_subparagraph}
Like [Descend](#descend_subparagraph), the `landing` mode changes the altitude using a constant calibrated airspeed while maintaining a given glide path angle. After touchdown, the aircraft is decelerated to the dedicated taxi speed. Beside the aircraft's brakes, you can also turn on the `thrust_reverser` in the [Configuration File](getting_started.md/#config_file). This may shorten the needed runway length drastically, but you must be sure your engines/aircraft configuration is capable of this.
## Taxiing procedures
Unlike the other mission steps, taxi-out and taxi-in are defined in the overall `mission` block within the `mission file`. The taxi fuel consumption for both the origin and destination is determined based on the type of `taxiing_procedure` used. If electric taxiing is used, fuel is only needed for engine warm-up at the origin airport, while no fuel is allocated for taxiing at the destination. The warm-up fuel is calculated using the `engine_warmup_time` $t_{warm\textrm{-}up}$ time and fuelflow rate $\dot{m}_{warm\textrm{-}up}$ which is derived from the [Configuration File's](getting_started.md/#config_file) `fuel_flow_factor_taxiing` which is applied to the engine running in `idle`:
$$
m_{fuel,\,warm\textrm{-}up} = t_{warm\textrm{-}up} \cdot \dot{m}_{warm\textrm{-}up}
$$
If electric taxiing is not used, fuel is needed for both origin and destination taxi operations. In this case, the required fuel mass is based on the taxiing time $t_{taxi}$ at each airport (`taxi_time_origin` & `taxi_time_destination`). Analogous to $\dot{m}_{warm\textrm{-}up}$, we get the taxi fuels:
$$
m_{fuel,\,taxi\textrm{-}out} = t_{taxi\textrm{-}out} \cdot \dot{m}_{taxi\textrm{-}out}
$$
$$
m_{fuel,\,taxi\textrm{-}in} = t_{taxi\textrm{-}in} \cdot \dot{m}_{taxi\textrm{-}in}
$$
!!!node
The fuelflow is computed the same way for the three procedures above. Therefore all of these are equal.
docs/documentation/analysis/mission_analysis/mission_types.md deleted 100644 → 0
+ 0
− 1
View file @ 27b4c50b
# Mission Types {#mission_types}
mkdocs.yml
+ 1
− 0
View file @ 8bbc1fc8
......@@ -279,6 +279,7 @@ nav: # Customizes the main navigation struc
- Introduction: documentation/analysis/mission_analysis/index.md
- Getting Started: documentation/analysis/mission_analysis/getting_started.md
- Mission Methods: documentation/analysis/mission_analysis/methods.md
- Mission Steps: documentation/analysis/mission_analysis/mission_steps.md
- Weight and Balance Analysis:
- Introduction: documentation/analysis/weight_and_balance_analysis/index.md
- Basic Concepts: documentation/analysis/weight_and_balance_analysis/basic-concepts.md
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment