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

Merge branch 'feature/add_documentation_virtual_system_strategy' into 'main' 

Add virtual strategy to documentation

See merge request !75
parents 2a229c1c a0f14cc5
No related branches found
No related tags found
1 merge request!75Add virtual strategy to documentation
Pipeline #1642039 passed
Stage: build
Stage: deploy
Hide whitespace changes
Inline Side-by-side
docs/documentation/sizing/systems_design/getting-started.md
+ 141
− 2
View file @ ca436ad1
# Getting Started
This guide will show you how to use **systems_design**.
This guide will show you how to use **systems_design**. The module provides two strategies. One option is to define and specify all of the onboard systems you want to include in your aircraft's system architecture and based on your inputs **systems_design** will design all of these systems, calculate their masses, and determine their power requirements. This is called the ["standard" strategy](#standard-strategy) and is useful for a detailed analysis of the impact of system parameter on the aircraft design. In the other option, you provide the system mass(es) and power requirement(s) as virtual system(s). This is called the ["virtual" strategy](#virtual-strategy) and requires less user inputs. It is useful if you already (roughly) know your on-board systems mass and power requirement and just want to include them in you aircraft design without designing individual systems.
## Step-by-step
......@@ -23,6 +23,27 @@ The following will happen:
## Settings and outputs {#settings-and-outputs}
### Virtual Strategy
Three input files are required for **systems_design** in the virtual strategy:
- the aircraft exchange file (or _acXML_) with values for the following areas:
- paths to mission files
- wing
- fuselage
- the configuration file `systems_design_conf.xml` (or _configXML_) includes
- control settings (e.g. enable/disable generating plots)
- program settings (e.g. define virtual systems and their properties)
- 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!
### Standard Strategy
Three input files are required for **systems_design**:
- the aircraft exchange file (or _acXML_) with values for the following areas:
......@@ -48,9 +69,127 @@ Three input files are required for **systems_design**:
!!! 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.
**systems_design** in the standard strategy has three modes, which are explained [here](software_architecture.md#standard-strategy) 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
### Virtual Strategy
The system architecture is defined in the _configXML_ of systemsDesign in the node `module_configuration_file/program_settings/aircraft_systems`. In the virtual strategy you only need to define one or several virtual systems. These should cover all on-board system masses and power requirements. An example for the definition of a virtual system is given below. You need to input its mass, its center of gravity, and its power requirments (electric, hydraulic, and bleed air). Power requirments can be seperately defined for departure, cruise, and approach.
```xml
<module_configuration_file>
<program_setting>
<aircraft_systems>
<virtual_systems>
<number_of_virtual_systems description="Number of energy systems">
<value>1</value>
<default>0</default>
</number_of_virtual_systems>
<system ID="0">
<system_description description="Type of virtual system">
<value>virtualSystem</value>
</system_description>
<operating_switch description="Switch whether the system is operated. Switch: true (on) / false (off, mass is determined anyway!)">
<value>true</value>
<default>true</default>
</operating_switch>
<mass description="mass of the system">
<value>5000.0</value>
<unit>kg</unit>
<default>0.0</default>
</mass>
<center_of_gravity description="position of mass item to global point of reference">
<x description="Position of reference in x-direction">
<value>12</value>
<unit>m</unit>
</x>
<y description="Position of reference in y-direction">
<value>0</value>
<unit>m</unit>
</y>
<z description="Position of reference in z-direction">
<value>0</value>
<unit>m</unit>
</z>
</center_of_gravity>
<power_demand>
<departure>
<bleed_air description="Bleed air requirement during departure">
<value>3.0</value>
<unit>kg/s</unit>
<default>0.0</default>
</bleed_air>
<hydraulic description="Hydraulic requirements during departure">
<value>10000.0</value>
<unit>W</unit>
<default>0.0</default>
</hydraulic>
<electric description="Electrical requirements during departure">
<value>15000.0</value>
<unit>W</unit>
<default>0.0</default>
</electric>
<heat_load description="Heat emission during departure">
<value>0.0</value>
<unit>W</unit>
<default>0.0</default>
</heat_load>
</departure>
<cruise>
<bleed_air description="Bleed air requirement during departure">
<value>0.5</value>
<unit>kg/s</unit>
<default>0.0</default>
</bleed_air>
<hydraulic description="Hydraulic requirements during departure">
<value>0.0</value>
<unit>W</unit>
<default>0.0</default>
</hydraulic>
<electric description="Electrical requirements during departure">
<value>20000.0</value>
<unit>W</unit>
<default>0.0</default>
</electric>
<heat_load description="Heat emission during departure">
<value>0.0</value>
<unit>W</unit>
<default>0.0</default>
</heat_load>
</cruise>
<approach>
<bleed_air description="Bleed air requirement during departure">
<value>3.5</value>
<unit>kg/s</unit>
<default>0.0</default>
</bleed_air>
<hydraulic description="Hydraulic requirements during departure">
<value>7500.0</value>
<unit>W</unit>
<default>0.0</default>
</hydraulic>
<electric description="Electrical requirements during departure">
<value>18000.0</value>
<unit>W</unit>
<default>0.0</default>
</electric>
<heat_load description="Heat emission during departure">
<value>0.0</value>
<unit>W</unit>
<default>0.0</default>
</heat_load>
</approach>
</power_demand>
</system>
</virtual_systems>
</aircraft_systems>
</program_settings>
</module_configuration_file>
```
### Standard Strategy
![](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.
......
docs/documentation/sizing/systems_design/index.md
+ 3
− 1
View file @ ca436ad1
......@@ -3,7 +3,7 @@ The systems design module calculates the mass and power requirement of the aircr
![](figures/overall_structure.png)
The systems are divided according to the ATA chapters. Models for the following systems exist:
The systems design module offers the option of designing the individual aircraft systems. If this approach is chosen, 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)
......@@ -22,3 +22,5 @@ The systems design module calculates the mass and power requirement of the aircr
* [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).
If you do not want to design the individual onboard systems, you can integrate a known system into your aircraft design via the [virtual strategy](getting-started.md#virtual-strategy-1).
docs/documentation/sizing/systems_design/software_architecture.md
+ 23
− 3
View file @ ca436ad1
......@@ -12,13 +12,33 @@ If you are interested in how **systems_design** performs the system sizing and p
* 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.
Currently **systems_design** has two strategies - the `standard` strategy implemented in `standardSystemsDesign.cpp` and the `virtual` strategy implemented in `virtualSystemsDesign.cpp`.
## Virtual Strategy
In the virtual strategy you give the system mass, center of gravity, and power requirement as an input. Thus, all **systems_design** will do is adding up these values of all of the virtual systems you defined and calculating the operating items.
#### Initialize
Here the inputs in the config file are read as well as the values of the acxml required for calculation of the operator items (fuselage, wing, accommodation). For each virtual system an instance of the class `aircraftSystem` is created to store its mass, center of gravity and the mission dependent power in `powerProfile`.
#### Run
Operator items are calculated. The total mass of all user-defined virtual systems and operator items is calculated by summing their individual masses. The weighted total center of gravity and the total power requirements at each mission step are calculated as well.
#### Post processing
The update and report functions do the same as in the standard strategy except that the plots are reduced to one plot displaying the total required power (electric, hydraulic, bleed air) over the mission.
## Standard Strategy
Here, 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
### 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;"}
......@@ -59,7 +79,7 @@ This mode is used to calculate the power required by the systems during the stud
This mode is used to calculate the power required by the systems during the requirements mission. The methodology is the same as for the sizing mode up until the calculation of system masses, which are skipped. However, the requirement mission file (`requirement_mission.xml`) is used instead of the design mission file (`design_mission.xml`). This means offtakes are written to the requirements mission file but no changes are made to the _acXML_ since the systems are not resized.
### Output
## Output
#### Update
The update section includes all updates to the aircraft exchange file and the mission file. If the sizing mode was run, the system masses in the aircraft exchange file are updated. Since the systems are considered as point masses in UNICADO the moments of inertia are set to zero. The function `systemsIOData::updateMassProperties()` updates the total mass of all systems and the operator items mass. The masses of the individual systems are updated by their classes, which all contain a function `updateXML()`. This way only the systems included in the architecture are written to the aircraft exchange file.
......
docs/documentation/sizing/systems_design/systems.md
+ 2
− 0
View file @ ca436ad1
# Implemented Aircraft System Models
These system models are relevant if you choose to use the [standard strategy](getting-started.md) of systems design.
## ATA 21: Environmental Control System
The environmental control system model implemented is powered by electric power and bleed air from the engines.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment