Skip to content
Snippets Groups Projects
Commit a7d860ff authored by Ellen Seabrooke's avatar Ellen Seabrooke
Browse files

Merge branch 'documentation/systems_addition' into 'develop'

Update systems design documentation

See merge request !25
parents bb24c492 39b2c9b2
Branches
No related tags found
3 merge requests!76Draft: Updated Python code example,!73Initial open source version,!25Update systems design documentation
Pipeline #1604987 passed
Showing
with 173 additions and 90 deletions
docs/documentation/sizing/systems_design/figures/architecture_definition.png

131 B

docs/documentation/sizing/systems_design/figures/flow-chart.jpg

131 B

docs/documentation/sizing/systems_design/figures/flow-chart.png

131 B

docs/documentation/sizing/systems_design/figures/mission-power-ATA70.png

130 B

docs/documentation/sizing/systems_design/figures/overall_structure.png

130 B

docs/documentation/sizing/systems_design/figures/power_summation.png

130 B

docs/documentation/sizing/systems_design/figures/system-masses.png

130 B

docs/documentation/sizing/systems_design/figures/system_class.png

130 B

# Getting Started
This guide will show you how to use **systems_design**, which requires you to define a [system architecture](\ref defining_architecture) and to define [specific parameters for each system](systems.md) in the the configuration file `systems_design_conf.xml` (also _configXML_). Since the required power of the systems is calculated for each mission step, **systems_design** requires a mission file (e.g. `design_mission.xml`). Additionally, input parameters from the aircraft exchange file (or _acXML_) from the following areas are required:
* paths to mission files
* overall masses (MTOM, OME, MME, wing loading)
* performance data (maximum operating velocity, maximum operating mach number, maximum operating altitude, design range)
* landing gear
* wing
* empennage
* fuselage
* nacelles
* tank
* propulsion
* number of flight and cabin crew
**systems_design** has three modes, which are explained [here](\ref modes) in more detail. The mode can be selected in `module_configuration_file/program_settings/mission_mode` and defines which mission file is used for the calculation of the required power (design, study or requirement mission). For the design mission the systems are also sized, i.e. their masses are calculated.
\anchor defining_architecture
This guide will show you how to use **systems_design**.
## Step-by-step
It is assumed that you have the `UNICADO Package` installed including the executables and the engine database. In case you are a developer, you need to build the tool first (see [build instructions on UNICADO website](../../../get-involved/build/cpp/)).
1. Create a dummy `aircraft_exchange_file` (minimal required input see [here](#settings-and-outputs-settingsandoutputs))
2. Fill out the configuration file - change at least:
- in `control_settings`
- `aircraft_exchange_file_name` and `aircraft_exchange_file_directory` to your respective settings
- `console_output` at least to `mode_1`
- `plot_output` to false or make sure gnuplot can be found (`gnuplot_path`)
3. Open terminal and run **systems_design**
The following will happen:
- you see output in the console window
- a HTML report is created in the directory of `aircraft_exchange_file_directory` (no plots if they are turned off)
- results are saved in the _acXML_ file
## Settings and outputs
Three input files are required for **systems_design**:
- the aircraft exchange file (or _acXML_) with values for the following areas:
- paths to mission files
- overall masses (MTOM, OME, MME, wing loading)
- performance data (maximum operating velocity, maximum operating mach number, maximum operating altitude, design range)
- landing gear
- wing
- empennage
- fuselage
- nacelles
- tank
- propulsion
- number of flight and cabin crew
- the configuration file `initial_sizing_conf.xml` (or _configXML_) includes
- control settings (e.g. enable/disable generating plots)
- program settings (e.g. define system architecture, set parameters for individual systems)
- the mission file (`design_mission.xml`, `study_mission.xml` or `requirement_mission.xml`) is required since **systems_design** calculates the required system power for each mission step.
!!! note
When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
!!! note
_acXML_ is an exchange file - we agreed on that only data will be saved as output which is needed by another tool!
**systems_design** has three modes, which are explained [here](software_architecture.md#run) in more detail. The mode can be selected in `module_configuration_file/program_settings/mission_mode` and defines which mission file is used for the calculation of the required power (design, study or requirement mission). For the design mission the systems are also sized, i.e. their masses are calculated.
## Defining the System Architecture
![](figures/architecture_definition.png)
The system architecture is defined in the _configXML_ of systemsDesign in the node `module_configuration_file/program_settings/aircraft_systems`. Here the systems are grouped into consumer (or sink) systems, conducting systems, and source systems. (This grouping is also used during calculation.) Energy sinks are systems that consume energy. The environmental control system is considered separately to iterate between the heat created by the systems and the sizing of the environmental control system. Energy sources provide energy. Energy conductors conduct electric or hydraulic energy or bleed air. Virtual systems are used for adding systems that will not be designed (for example if there are no sizing methods implemented for this system). For each group the number of systems in the group is defined, followed by the individual system description. A minimal example of the architecture definition is given below.
```xml
......@@ -93,24 +127,25 @@ The system architecture is defined in the _configXML_ of systemsDesign in the no
```
By including or excluding these systems, you can choose which systems are implemented. By default the following systems are included in the architecture (name for configXML given in brackets):
* energy sinks:
* [conventional furnishing system](\ref ATA25-furnishing) (conventionalFurnishing)
* [conventional fuel system](\ref ATA28-fuel) (conventionalFuel)
* [conventional ice and rain protection system](\ref ATA30-ice-conventional) (conventionalIceRainProtection)
* [conventional lighting system](\ref ATA33-lighting) (conventionalLighting)
* [conventional fire protection system](\ref ATA26-fire) (conventionalFireProtection)
* [conventional oxygen system](\ref ATA35-oxygen) (conventionalOxygenSystem)
* [conventional landing gear system](\ref ATA32-gear) (conventionalGear)
* [conventional flight control system](\ref ATA27-flight-control) (conventionalFlightControl)
* [remaining consumer systems](\ref ATAXX-remaining) (reminingConsumers)
* [environmental control system](\ref ATA21-ECS) (conventionalECS)
* energy sources:
* [conventional propulsion](\ref ATA70-engine) (conventionalPropulsion)
* [conventional APU](\ref ATA49-APU) (conventionalAPU)
* energy conductors:
* [bleed air system](\ref ATA36-bleed) (BleedAirSystem)
* [hydraulic system](\ref ATA29-hydraulic) (HydraulicSystem)
* [electric system](\ref ATA24-electric) (ElectricSystem)
- energy sinks:
- [conventional furnishing system](systems.md#ata-25-furnishing-system) (conventionalFurnishing)
- [conventional fuel system](systems.md#ata-28-fuel-system) (conventionalFuel)
- [conventional ice and rain protection system](systems.md#ata-30-ice-and-rain-protection-system) (conventionalIceRainProtection)
- [conventional lighting system](systems.md#ata-33-lighting-system) (conventionalLighting)
- [conventional fire protection system](systems.md#ata-26-fire-protectrion-system) (conventionalFireProtection)
- [conventional oxygen system](systems.md#ata-35-oxygen-system) (conventionalOxygenSystem)
- [conventional landing gear system](systems.md#ata-32-landing-gear-system) (conventionalGear)
- [conventional flight control system](systems.md#ata-27-flight-control-system) (conventionalFlightControl)
- [remaining consumer systems](systems.md#ata-xx-remaining-consumers) (reminingConsumers)
- [environmental control system](systems.md#ata-21-environmental-control-system) (conventionalECS)
- energy sources:
- [conventional propulsion](systems.md#ata-70-engine) (conventionalPropulsion)
- [conventional APU](systems.md#ata-49-auxiliary-power-unit-apu) (conventionalAPU)
- energy conductors:
- [bleed air system](systems.md#ata-36-bleed-air-system) (BleedAirSystem)
- [hydraulic system](systems.md#ata-29-hydraulic-system) (HydraulicSystem)
- [electric system](systems.md#ata-24-electric-system) (ElectricSystem)
Some systems have several implementations (e.g. ATA30 has a conventional and an electric implementation). Which one is used is specified by the node `system_description`. Sticking to the ATA30 example, the conventional implementation would be set like this:
```xml
......@@ -152,3 +187,14 @@ Additionally, [system-specific parameters](systems.md) can be set in the node `<
## Output
**systems_design** will generate a report containing system masses (if run in sizing mode) and the electric, hydraulic and bleed air power profile over the mission for each system. Additionally, the section `systems` of the component design in the _acXML_ is updated (if **systems_design** was run in design mode) and the bleed air and shaft power offtakes from the engine for each mission step are written to the mission file (for any mode).
Here are some examples of what you can expect to see in the report:
![](figures/system-masses.png){width=500}
The mission power shown here is for the propulsion unit. It is negative since the propulsion unit provides power instead of requiring it. Additionally to the plots displayed in the report, csv-files with the plot data can be found in the project folder: `reporting/plots/csv_files`.
![](figures/mission-power-ATA70.png)
!!! note
Some systems will not show anything in these graphs. That means they do not require power (e.g. [oxygen system](systems.md#ata-35-oxygen-system)). The graph of the [APU](systems.md#ata-49-auxiliary-power-unit-apu) is also empty because it is only sized for ground operations and those are not considered in the mission shown in these graphs.
\ No newline at end of file
# Introduction {#mainpage}
The systems design module calculates the mass and power requirement of the aircraft onboard systems. The systems are divided according to the ATA chapters. Models for the following systems exist:
The systems design module calculates the mass and power requirement of the aircraft onboard systems. The current version supports a conventional power supply architecture shown in the picture below. An update that will allow other power sources is on its way :construction:.
* [ATA 21: Environmental Control System](\ref ATA21-ECS)
* [ATA 24: Electric System](\ref ATA24-electric)
* [ATA 25: Furnishing System](\ref ATA25-furnishing)
* [ATA 26: Fire Protectrion System](\ref ATA26-fire)
* [ATA 27: Flight Control System](\ref ATA27-flight-control)
* [ATA 28: Fuel System](\ref ATA28-fuel)
* [ATA 29: Hydraulic System](\ref ATA29-hydraulic)
* [ATA 30: Ice and Rain Protection System](\ref ATA30-ice-conventional)
* [ATA 32: Landing Gear System](\ref ATA32-gear)
* [ATA 33: Lighting System](\ref ATA33-lighting)
* [ATA 35: Oxygen System](\ref ATA35-oxygen)
* [ATA 36: Bleed Air System](\ref ATA36-bleed)
* [ATA 49: Auxiliary Power Unit (APU)](\ref ATA49-APU)
* [ATA 70: Engine (only used to account for power extraction efficiencies of the engine)](\ref ATA70-engine)
* [ATA XX: Remaining Consumers](\ref ATAXX-remaining)
![](figures/overall_structure.png)
The systems are divided according to the ATA chapters. Models for the following systems exist:
* [ATA 21: Environmental Control System](systems.md#ata-21-environmental-control-system)
* [ATA 24: Electric System](systems.md#ata-24-electric-system)
* [ATA 25: Furnishing System](systems.md#ata-25-furnishing-system)
* [ATA 26: Fire Protectrion System](systems.md#ata-26-fire-protectrion-system)
* [ATA 27: Flight Control System](systems.md#ata-27-flight-control-system)
* [ATA 28: Fuel System](systems.md#ata-28-fuel-system)
* [ATA 29: Hydraulic System](systems.md#ata-29-hydraulic-system)
* [ATA 30: Ice and Rain Protection System](systems.md#ata-30-ice-and-rain-protection-system)
* [ATA 32: Landing Gear System](systems.md#ata-32-landing-gear-system)
* [ATA 33: Lighting System](systems.md#ata-33-lighting-system)
* [ATA 35: Oxygen System](systems.md#ata-35-oxygen-system)
* [ATA 36: Bleed Air System](systems.md#ata-36-bleed-air-system)
* [ATA 49: Auxiliary Power Unit (APU)](systems.md#ata-49-auxiliary-power-unit-apu)
* [ATA 70: Engine (only used to account for power extraction efficiencies of the engine)](systems.md#ata-70-engine)
* [ATA XX: Remaining Consumers](systems.md#ata-xx-remaining-consumers)
[Getting Started](getting_started.md) will show you how to define the system architecture. The settings and calculation methods for the individual aircraft systems are explained in [Systems](systems.md) or you can follow one of the links above directly to the system. If you want to know how the systems design module works have a look at the [Software Architecture](software_architecture.md).
# Systems Design Software Architecture
If you are interested in how **systems_design** performs the system sizing and power requirment calculation, this page will give you an overview.
If you are interested in how **systems_design** performs the system sizing and power requirment calculation, this page will give you an overview. The following UNICADO libraries are used:
* atmosphere: determines atmospheric conditions at given altitudes
* engine: access to engine data (max. available bleed air and shaft power)
* aircraftGeometry2: used for geometry measurements
* energyCarriers: accessing energy carrier information (e.g. densities)
* aixml: handling of xml
* moduleBasics: used for basic program functions
* runtimeInfo: terminal outputs
* unitConversion: converting units
* standardFiles: file handling
## Module Structure
Currently **systems_design** only has one strategy - the `STANDARD` strategy implemented in `standardSystemsDesign.cpp`. In **systems_design** each system is represented by an instance of the class `aircraftSystem`. Its properties include the point mass and CoG of the system, the required power, and the heat load emitted by the system. Each aircraftSystem has functions for calculating these properties. The power of a system is not constant throughout the mission but calculated for each mission step. These values are stored in objects of the class `powerProfile`. This class stores the design power, used for system sizing, and the mission power. The mission power is further divided into the base load during this mission step and potential peak loads, e.g. resulting from the retraction or extension of the landing gear. Heat loads occurring due to energy losses in the systems are also calculated for each mission step and stored in a powerProfile.
![](figures/system_class.png){width=500 style="display: block; margin: auto;"}
If a new aircraftSystem is implemented, its header file has to be included in `standardSystemsDesign.cpp` and an else-if-statement calling its constructor according to the system name has to be added to `standardSystemsDesign::initializeSystems()`.
## Calculation
The calculation methodology is shown in this flow chart and explained in detail below.
![](figures/flow-chart.png){width=400 style="display: block; margin: auto;"}
#### Initialize
The system design module starts with `standardSystemsDesign::initialize()` by initializing all aircraft systems using the user-provided data from the configuration file. The config file is read when the `data_` object is created. Additionally, required aircraft parameters from the aircraft exchange file are read. This includes geometry data (fuselage, nacelles, wing, empennage), propulsion data, mass and performance and accomodation data. This data are required for the power and mass calculations of specific systems. However, all data are read centrally by the `systemsIOData` class during initialization. Lastly checks for the user input and the geometry from the acxml are performed.
**systems_design** considers the temperature offset to the International Standard Atmosphere (ISA) defined in the _acXML_. The resulting temperature changes in the atmospheric conditions are applied to the mission steps and affect the power demand and thus the mass properties of systems depending on atmospheric conditions ([environmental control system](\ref ATA21-ECS), [flight control system](\ref ATA27-flight-control), [ice and rain protection system](\ref ATA30-ice-conventional)).
!!! note
**systems_design** considers the temperature offset to the International Standard Atmosphere (ISA) defined in the _acXML_. The resulting temperature changes in the atmospheric conditions are applied to the mission steps and affect the power demand and thus the mass properties of systems depending on atmospheric conditions ([environmental control system](systems.md#ata-21-environmental-control-system), [flight control system](systems.md#ata-27-flight-control-system), [ice and rain protection system](systems.md#ata-30-ice-and-rain-protection-system)).
#### Run
\anchor modes
The strategy standard systems design contains three modes, which can be selected in the configuration file. The sizing mode calculates the required system power and based on that the system masses. The study and requirment mode can be used to calculate the required system power for different missions (either the study or requirments mission) and do not resize the systems (i.e., no mass calculation is performed).
**Sizing Mode**
First, the module calculates the performance profile of each system (with the function `standardSystemsDesign::calculatePerformanceProfile()`). This involves calling the respective power calculation function for each system in a specific order: consumer systems, the environmental control system (ECS), conducting systems, and source systems. The calculation order is crucial because the power requirements of consumer systems are necessary to calculate the conducting and source power. At first, the power profiles of all consumer systems are calculated (`standardSystemsDesign::getSinkEnergyConsumption()`) except for the ECS. It is treated separately because its power requirement depends on the heat loads generated by other systems, including conducting systems. Therefore, it is calculated later in the process.
After each consumer system power calculation, the power is accumulated in a global power profile that stores the combined power requirement and heat loads of all consumer systems. Conductor systems can provide power to other conducting systems, e.g. through the conversion of electrical power to hydraulic power. The power used for these conversions is calculated next (with `transferElec2HydPower` (electric driven hydraulic pumps) and `transferHyd2ElecPower` (only for failure cases)) and stored in the global sink power profile.
After each consumer system power calculation, the power is accumulated in a global power profile that stores the combined power requirement and heat loads of all consumer systems.
![](figures/power_summation.png){width=400 style="display: block; margin: auto;"}
Conductor systems can provide power to other conducting systems, e.g. through the conversion of electrical power to hydraulic power. The power used for these conversions is calculated next (with `transferElec2HydPower` (electric driven hydraulic pumps) and `transferHyd2ElecPower` (only for failure cases)) and stored in the global sink power profile.
Next, an iteration loop is required because the ECS power requirement depends on the heat load of the sinks and conductors and the conducting power depends on the power requirement of the ECS. At the beginning of each loop the power profiles `data_->data.ECSConsumption` and `data_->data.conductorConsumption` are cleared from the values of the previous iteration loop and the global power profiles of the conductors are initialized (`data_->Systems.energyConductor`). In each iteration loop, the ECS power is calculated (`standardSystemsDesign::getECSEnergyConsumption()`) based on the heat loads of the consumer systems stored in the global sink power profile. The power requirements for conducting systems are then calculated or updated (`standardSystemsDesign::getConductorEnergyConsumption()`) to reflect the new ECS consumption, including any power transfers, such as from hydraulic to electrical power. The iteration continues until the average bleed load of the ECS converges. The convergence criterion is set to a difference of less than 10<sup>-4</sup> between iterations.
......@@ -27,7 +48,8 @@ After achieving convergence, the module calculates the power the sources (`stand
Finally, with the power profiles established, the module calculates the mass of each system (`standardSystemsDesign::getSystemsMass()`) based on the design power requirements and specific characteristics of each system by calling the mass calculation method of each system. For virtual systems no method is called, rather the user definded values are copied from the configuration file. After the individual system masses are calculated, the function `weightsAndCGs::getWeights()` calculates the masses and CGs of system groups and the mass of some operator items. In UNICADO only the residual oil and fuel as well as water and toilet chemicals are considered part of the systems. Other operator items are calculated in fuselage design and mission analysis.
**Note**: The currently implemented methods for the operator items (Torenbeek) do not calculate the residual oil mass!
!!! note
The currently implemented methods for the operator items (Torenbeek) do not calculate the residual oil mass!
**Study Mode**
......@@ -45,4 +67,4 @@ The function `systemsIOData::updateMissionXML()` updates all values calculated w
#### Report
This section is used to create the plots and html and tex report of the module.
Plots are generated using matplot++. Additionally, csv files with the plot data are written.
Plots are generated using matplot++. Additionally, csv files with the plot data are written. More information on the outputs can be found [here](getting-started.md#output).
# Implemented Aircraft System Models
\anchor ATA21-ECS
## ATA 21: Environmental Control System
The environmental control system model implemented is powered by electric power and bleed air from the engines.
......@@ -8,7 +7,7 @@ The environmental control system model implemented is powered by electric power
The power required by the environmental control system is calculated based on the heat loads of all systems, the heat from the sun and from the passengers. The ECO-Mode allows to reduce the required bleed air by 25%. Air conditioning is switched off during takeoff.
The mass of the ECS depends on the bleed air mass flow in the design point. Calculation method from LTH and Howe. The mass is broken down into the components ducts, air conditioning pack, outlet, ram inlet, vents, and misc. according to factors determined by Koeppen.
The mass of the ECS depends on the bleed air mass flow in the design point. Calculation method from LTH and Howe. The mass is broken down into the components ducts, air conditioning pack, outlet, ram inlet, vents, and misc. according to factors determined by Koeppen[^1].
The CoG of the ECS is determined with the assumption that its located in the belly fairing.
......@@ -27,7 +26,6 @@ The CoG of the ECS is determined with the assumption that its located in the bel
* Off Take Off: Switch to turn of ACP during take off
* ECO Mode: Switch for ECO Mode reduces bleed air requirement by 25%
\anchor ATA24-electric
## ATA 24: Electric System
**Methods**
......@@ -53,7 +51,6 @@ The mass calculation method from Steinke is based on the maximum required electr
* efficiency
* operation factor (share of total power in normal operation)
\anchor ATA25-furnishing
## ATA 25: Furnishing System
Furnishing system includes the power required for the galleys and the inflight entertainment system (IFE). The mass of all furnishing is calculated in fuselage design and read from the aircraft exchange file.
......@@ -65,22 +62,24 @@ Power calculation is done based on user inputs.
**Required Input Parameters**
* Galley Load Fraction during Takeoff [-]:
Electric Load Analysis for A320 suggest a value of 0.2 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 0.2[^1]
[^1]: Source documents are available in German and can be requested from the RWTH Aachen.
* Galley Load Fraction during Cruise [-]:
Electric Load Analysis for A320 suggest a value of 0.7 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 0.7[^1]
* Galley Load Fraction during Descent [-]:
Electric Load Analysis for A320 suggest a value of 0.2 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 0.2[^1]
* Galley Location [m]
* Non Personal IFE Power [W]: General power for IFE
* Personal IFE Power [W]: Power for IFE per PAX
* Personal IFE Load Fraction Climb [-]:
Electric Load Analysis for A320 suggest a value of 0.58 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 0.58[^1]
* Personal IFE Load Fraction Cruise [-]:
Electric Load Analysis for A320 suggest a value of 1 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 1[^1]
* Personal IFE Load Fraction Descent [-]:
Electric Load Analysis for A320 suggest a value of 0.5 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 0.5[^1]
\anchor ATA26-fire
## ATA 26: Fire Protectrion System
Does not require power!
......@@ -93,7 +92,6 @@ Mass calculation is based on propulsion type and MTOM (Torenbeek Tab. 8-12).
None.
\anchor ATA27-flight-control
## ATA 27: Flight Control System
The flight control system is modeled in great detail down to the individual actuators of the control surfaces. The calculation is devided into segments according to the control surfaces:
......@@ -160,7 +158,6 @@ Acceptable control surface names are:
**Note**: not all of these devices are implemented. If they aren't implemented a default will be used and a warning issued.
\anchor ATA28-fuel
## ATA 28: Fuel System
**The fuel system does not contain the tank mass!**
......@@ -177,7 +174,6 @@ The CoG is assumed to be the same as that of the wing.
None
\anchor ATA29-hydraulic
## ATA 29: Hydraulic System
**Methods**
......@@ -186,7 +182,7 @@ None
The required power of the hydraulic system is the power lost through inefficiencies. The efficiency factor for the hydraulic system and for the pumps are considered.
The mass calculation method from [Steinke](\ref additional_sources) is based on the maximum required hydraulic power, the OME, the fluid mass and the ducting length. The ducting length is composed of the lengths from the engines to the belly fairing, the front gear to the back gear, 2 * the length of the wing trailing edge, 2 * the trailing edges of the horizontal and vertical tail plane. The total length is then doubled to account for the backflow.
The mass calculation method from Steinke[^1] is based on the maximum required hydraulic power, the OME, the fluid mass and the ducting length. The ducting length is composed of the lengths from the engines to the belly fairing, the front gear to the back gear, 2 * the length of the wing trailing edge, 2 * the trailing edges of the horizontal and vertical tail plane. The total length is then doubled to account for the backflow.
**Required Input Parameters**
......@@ -210,7 +206,6 @@ The mass calculation method from [Steinke](\ref additional_sources) is based on
There are two implemented models for the ice and rain protection system - a conventional one powered by bleed air and an electric one.
\anchor ATA30-ice-conventional
### Conventional ATA 30
**Methods**
......@@ -230,7 +225,6 @@ Anti-Icing is typically applied from the kink of the wing and ends at the outer
* Drop Diameter [micro meter]
* Mass Percentage of OME [-]
\anchor ATA30-ice-electric
### Electric ATA 30
Mass is calculated as a percentage of the OME defined by the user.
......@@ -244,16 +238,15 @@ Same calculation for the external heat flux. From there the required electric po
Same as for conventional +
* Electric Power Consumption Departure [W]:
Electric Load Analysis for A320 suggest a value of 14026.9 W [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 14026.9 W[^1]
* Electric Power Consumption Cruise [W]:
Electric Load Analysis for A320 suggest a value of 13070.9 W [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 13070.9 W[^1]
* Electric Power Consumption Approach [W]:
Electric Load Analysis for A320 suggest a value of 14026.9 W [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 14026.9 W[^1]
* Electric Power Consumption Land [W]
Electric Load Analysis for A320 suggest a value of 7192.9 W [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 7192.9 W[^1]
* Efficiency Electro Thermic Anti-Icing [-]
\anchor ATA32-gear
## ATA 32: Landing Gear System
**Methods**
......@@ -269,7 +262,6 @@ The retraction and extension power are calculated based on the mass of the landi
* Extension Time [s]
* Power Source(s)
\anchor ATA33-lighting
## ATA 33: Lighting System
**Methods**
......@@ -297,14 +289,13 @@ The design electric power is calculated assuming all lights are on. For the miss
* Logo Light Power [W]
* Strobe Light Power [W]
* Specific Emergency Light Power [W/m^3]
Electric Load Analysis for A320 suggest a value of 1.46 W/m^3 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 1.46 W/m^3[^1]
* Specific Cabin Light Power [W/m^3]
Electric Load Analysis for A320 suggest a value of 18.04 W/m^3 [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 18.04 W/m^3[^1]
* Flight Deck Light Power [W]
Electric Load Analysis for A320 suggest a value of 904.4 W [[1]](\ref additional_sources)
Electric Load Analysis for A320 suggest a value of 904.4 W[^1]
* Power Sources
\anchor ATA35-oxygen
## ATA 35: Oxygen System
The oxygen system does not require power.
......@@ -317,7 +308,6 @@ The mass is calculated according to Torenbeek based on the number of PAX and dep
None.
\anchor ATA36-bleed
## ATA 36: Bleed Air System
**Methods**
......@@ -334,7 +324,6 @@ Bleed air required by the bleed air system is based on the efficiency losses in
* Efficiency Factor [-]
* Specific Ducting Mass [kg/m]
\anchor ATA49-APU
## ATA 49: Auxiliary Power Unit (APU)
The APU is the only power source sized within systems design. However, it is only operated on ground. Ground operations are not included in the mission analysis in UNICADO, thus, the kerosene required by the APU is neglected.
......@@ -355,7 +344,6 @@ The power provided by the APU is calculated with the user defined percentages an
* Installation factor for attached parts such as fire protection, noise protection, etc. [-]
* Percentages of power provided by APU for design case (bleed air, electric power, hydraulic power) [-]
\anchor ATA70-engine
## ATA 70: Engine
This model is only used to account for power extraction efficiencies of the engine. The engine is sized in the engine design module. The powere required by the systems from the engine is checked against the maximum power the engine can provide before updating the xml files. If at power peaks more power is required than available the less power over a longer amount of time will be written to the xml.
......@@ -371,7 +359,6 @@ The efficiency factors for the shaft power extraction (electric + hydraulic powe
* Percentage of hydraulic power provided by the engine [-]
* Efficiency factor for the bleed air extraction [-]
\anchor ATAXX-remaining
## ATA XX: Remaining Consumers
The remaining consumers are the avionics and their power requirement is derived as a percentage of the power required by all other sink systems.
......@@ -394,6 +381,5 @@ The CoG is calculated assuming the instruments are placed at the end of the cock
* Mass percentage of ATA XX for navigation [-]
* Mass percentage of ATA XX for communication [-]
\anchor additional_sources
### Additional Sources
[1] Source documents are available in German and can be requested from the RWTH Aachen.
\ No newline at end of file
[^1] Source documents are available in German and can be requested from the RWTH Aachen.
\ No newline at end of file
......@@ -24,6 +24,7 @@ markdown_extensions:
- attr_list # Allows adding HTML attributes to Markdown elements (like classes).
- admonition # Enables note/warning/admonition boxes with custom styling.
- md_in_html # Allows writing Markdown inside HTML tags for flexibility.
- footnotes # Allows footnotes
- pymdownx.tabbed: # Enables tabbed content blocks, allowing content to be organized in tabs.
alternate_style: true # Uses an alternate style for tabbed blocks.
- pymdownx.emoji: # Adds support for emojis using the Material theme’s emoji set.
......@@ -268,7 +269,7 @@ nav: # Customizes the main navigation struc
- Systems Design:
- Introduction: documentation/sizing/systems_design/index.md
- Getting Started: documentation/sizing/systems_design/getting-started.md
- Implemented Models: documentation/sizing/systems_design/systems.md
- System Models: documentation/sizing/systems_design/systems.md
- Software Architecture: documentation/sizing/systems_design/software_architecture.md
- API Reference:
- systems_design/classes.md
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment