U
NIVERSITÀ DI
P
ISA
DIPARTIMENTO DI INGEGNERIA CIVILE E INDUSTRIALE
TESI DI LAUREA MAGISTRALE
INGEGNERIA AEROSPAZIALE
Integration of Multi-physic models of
All Electric Aircraft on board systems
Relatori:
Prof. Eugenio Denti Ing. Francesco Schettini
Candidato:
Giuseppe Nocera
i
Contents
List of figures ... iii
List of tables ... v
Acronyms ... 1
Abstract ... 2
Introduction ... 3
1 Shared Simulation Environment ... 6
2 Mission Profile ... 9
3 Environmental Control System ... 12
3.1 Model inputs ... 13 3.2 Model outputs ... 13 3.3 System parameters ... 14 3.4 Data list ... 14 3.4.1 Standard quantities ... 14 3.4.2 Component parameters ... 15
4 Global Thermal A/C Architecture ... 17
4.1 AMESim model ... 17
4.2 Linear Analysis of the model ... 19
5 Simulation Analysis ... 20
5.1 Simulation Parameters in Simulink ... 20
6 Cabin Thermal Model: Closed Loop Analysis ... 22
6.1 Temperature controller ... 22
7 IPS: Ice Protection System ... 24
7.1 Description of the IPS model ... 24
ii
7.3 Editing the IPS model ... 30
7.4 Dymola – Simulink Interface ... 31
7.5 Simulink input and output of the IPS model ... 34
7.6 The Second order filter ... 36
8 Utilities and Avionic loads ... 38
8.1 Analysis of the Utilities and Avionic loads ... 38
9 Energy Management System ... 40
9.1 Description of the EMS model ... 40
9.2 EMS Dymola-Simulink interface ... 44
9.3 Analysis of EMS behavior in a critical condition ... 45
10 Simulation Run and Results ... 46
10.1 Initial trim procedure ... 46
10.2 “Dummy” input data ... 49
10.3 “Dummy” simulation results ... 51
10.4 “Flight history” input data ... 59
10.5 “Flight history” simulation results ... 65
Conclusions ... 74
iii
List of figures
Figure 1.1 SSE Prototype ... 8
Figure 2.1 From Workspace block ... 9
Figure 3.1 Standard quantities ... 14
Figure 4.1 Thermal Architecture Model ... 18
Figure 5.1 Thermal Architecture Model ... 21
Figure 6.1 Temperature controller retroaction-scheme ... 22
Figure 7.1 Architectural level IPS model ... 24
Figure 7.2 IPS power absorption ... 25
Figure 7.3 Power consumption profile for type 1 deicers ... 26
Figure 7.4 Power consumption profile for type 2 deicers ... 26
Figure 7.5 Power consumption profile for type 3 deicers ... 27
Figure 7.6 Electrical unit model Dymola mask ... 28
Figure 7.7 Modified IPS model ... 30
Figure 7.8 Dymola-Simulink interface Block and Mask ... 32
Figure 7.9 Compiled Dymola-Simulink interface mask ... 33
Figure 7.10 Simulink IPS model ... 34
Figure 7.11 Simulink IPS Sequencer ... 35
Figure 7.12 Unit delay block ... 35
Figure 7.14 and details IPS power absorption ... 37
Figure 9.1 Flight history results (530 s-550 s)–Voltages, Power Absorbed ... 41
Figure 9.2 EMS model (Encrypted) ... 43
Figure 9.3 EMS Simulink-Dymola interface ... 44
Figure 10.1 Model of enabling sequence for starting ... 47
Figure 10.2 Bus Selector ... 47
Figure 10.3 Time range added to evaluate the trim condition via dynamic simulation ... 48
Figure 10.4 “Dummy” input data – ECS Command and Cabin reference Temperature ... 49
Figure 10.5 “Dummy” input data – Control Surfaces Deflection ... 50
Figure 10.6 LGS and IPS activation signals... 50
iv
Figure 10.8 “Dummy” results – Flap Deflection ... 52
Figure 10.9 “Dummy” results – LG Extraction/Retraction ... 53
Figure 10.10 “Dummy” results – EPGS Voltage, Current and flags ... 54
Figure 10.11 “Dummy” results – ECS Outlet Temperature and Mass flow ... 55
Figure 10.12 “Dummy” results – CT Temperature & Pressure ... 56
Figure 10.13 “Dummy” results – Voltages, Currents and El. Power Absorbed – ECS flags . 57 Figure 10.14 Detail: “Dummy” results – Voltages, Currents and El. Power Absorbed ... 58
Figure 10.15 Flight history input data – Mach, Altitude ... 59
Figure 10.16 Flight history input data – Aerodynamic Angles ... 60
Figure 10.17 Flight history input data – Linear Accelerations ... 60
Figure 10.18 Flight history input data – Euler Angles ... 61
Figure 10.19 Flight history input data – Angular Velocities ... 61
Figure 10.20 Flight history input data – Angular Accelerations ... 62
Figure 10.21 Flight history input data – Engine ... 62
Figure 10.22 Flight history input data – ECS command and Cabin refer. temperature ... 63
Figure 10.23 Flight history input data – Control Surfaces Deflection ... 64
Figure 10.24 Flight history input data - LGS and IPS activation signals ... 64
Figure 10.25 Flight history results - Control Surfaces Deflection ... 65
Figure 10.26 Flight history results – Flap Deflection ... 66
Figure 10.27 Flight history results – LG Extraction/Retraction ... 67
Figure 10.28 Flight history results – EPGS Voltage, Current and flags ... 68
Figure 10.29 Flight history results – ECS Outlet Temperature and Mass flow ... 69
Figure 10.30 Flight history results – CT Temperature & Pressure ... 70
Figure 10.31 Flight history results – Voltages, Currents, Power Abs. and ECS flags ... 71
Figure 10.32 Detail: Flight history results (500s-850s)–Voltages, Currents, Power Abs. .... 72
v
List of tables
Table 3.1 ECS model characteristics ... 12
Table 3.2 Turbomachines parameters ... 15
Table 3.3 Heat Exchanger parameters ... 15
Table 3.4 Valves parameters ... 16
Table 3.5 Sensors parameters ... 16
Table 7.1 State-integer value correspondence ... 29
1
Acronyms
A/C Aircraft
CCS Commercial Cabin Systems CT Global Thermal A/C Architecture ECS Environmental Control System
EPDS/EMS Energy Management System
EPGS Electrical Power Generation System FCS Flight Control System
GRA Green Regional Aircraft
IPS Ice Protection System
LGS Landing Gear System
2
Abstract
This thesis presents a numerical tool named Shared Simulation Environment (SSE) developed at the University of Pisa within the Clean Sky GRA AEA European project. This tool aims at the dynamic simulation of the electrical energy absorption of the various on-board systems during the manoeuvres of the new all-electric Green Regional Aircraft (GRA).
In the GRA an appropriate management of the electrical power available aboard is required to avoid generator overloads or temporary lack of energy due to an engine failure for powering safety-critical systems.
The SSE is developed in order to permit the design and the validation of the electrical Energy Management Logics under development within the project.
The thesis describes the methodologies used to develop the SSE by integrating models coming from different simulation environments (Matlab Simulink, AMESim, Dymola Modelica).
It also depicts the architecture of the first prototype of the SSE implemented at the University of Pisa.
3
Introduction
This work is performed within the Clean Sky European project – Green Regional Aircraft (GRA) platform – All Electric Aircraft (AEA) domain. The goal of Clean Sky is to achieve significant improvements in the environmental impact of aviation. In this direction, the recent trend aims at the electrification of all aircraft systems, even if challenging issues about the management of the on-board power arise in this approach. The AEA concept is based on the removal of the sources of pneumatic power (from the engine) and hydraulic power, replacing them with the electrical one. This objective can be only achieved by properly monitoring and managing the power requests (e.g. by temporarily reducing the power supplied to some systems during those flight phases in which the total request of electrical power could overcome the maximum available).
In this work, a numerical tool, able to support the design of the electrical power generation and distribution system will be developed. This particular tool is a simulation software, named Shared Simulation Environment (SSE) that can support the design and the validation of the electrical energy management strategies to be implemented aboard an all-electric GRA. The SSE integrates simulation models realized according to the All-Electric concept and able to reproduce the functions and the main performances of on-board systems, with particular attention to the power absorption issues. These models are developed by dividing the work among the Clean Sky partners (Alenia Aermacchi, EADS CASA, Liebherr-Aerospace Toulouse SAS, Thales A.E.S. – France, Airgreen cluster), according to three levels of increasing complexity: Architectural, Functional and Behavioural:
Level 1: Architectural level - Simple, non-dynamic models for the preliminary energy consumption assessment
Level 2: Functional level - Combination of steady-state and simple dynamic models for the preliminary analysis of energy management strategies, in the different operative modes
Level 3: Behavioural level - Detailed models for the study of the electrical power quality, energy consumption and electrical network stability.
4
can be useful for a preliminary assessment of the electrical energy absorbed by the systems and for a rough estimation of systems operating parameters, but these models are in general not suitable to be integrated in the SSE context. This is because, by disregarding the dynamic dependencies between inputs and outputs, the architectural level models lead to algebraic loops in the whole system. The solution of these algebraic loops can be difficult and can lead to models of a poor physical meaning. For this reason, architectural level models are not integrated into the SSE, except for some systems that, from the point of view of energy absorption, are to be modeled in a very simple way, as pure resistive loads.
As for the behavioural level models, the first experience about SSE integration showed that the computation time is the most important issue for the SSE and the use of behavioural level models, which are the most time-consuming ones, should be limited to the cases of real need. So, not all models will be integrated at level 3. In addition, the level 3 models will be always accompanied by the corresponding level 2 ones, to give the SSE user the possibility of choosing between models of level 2 (for simulations of longer A/C manoeuvres) and level 3 (for shorter simulations, carried out to investigate some phenomena in more detail). This will improve the efficacy of SSE.
These models are developed using three different software: - AMESim (ver11.2.0 / Rev11 SL2)
- Dymola (ver2013)
- MATLAB/Simulink (verR011b/7.8)
The first two are Object Oriented Software, differently by the last one, i.e. they give the user the possibility to access to a set of library (mechanical, electrical, pneumatic, hydraulic, etc...) and to find a set of already built components (but even to create new ones), where one can modify all the parameters useful for a simulation. The great benefit is to create a system just assembling the elements it is composed by, and, on the other side, to simulate the dynamic behaviour among various systems, which belong to different physic domain. In Simulink, instead, the user has to develop all the equations of each system, which often are not linear differential equations.
MATLAB/Simulink was chosen as main simulation environment because the major part of the models was developed using this software, the synthesis of the control laws is easier and it has not given particular problem during the simulation tests.
5
The first chapter is a panoramic view of the SSE with a brief explanation of the role of each block.
From Chapter 2 to Chapter 9, with the exception of Chapter 5, the following models involved in the construction of the SSE are analysed: the mission profile, the Environmental Control System (ECS), the Global Thermal A/C Architecture (CT) model, the closed loop between the CT and the ECS, the Ice Protection System (IPS), moreover the attention is put on the interface between Dymola and Simulink.
In chapter 8 and 9 then, we can find the description of the Avionic and Utilities loads and their interaction with the Energy Management System (EMS),
Finally, in chapter 10 are presented two different simulation tests with their results, and the procedure to “trim” the entire model because the SSE is designed to simulate a flight mission starting from steady state conditions. This goal has been achieved via dynamic simulation.
6
1 Shared Simulation Environment
The SSE prototype (Figure 1.1) is a scheme that includes all the models of the on board aircraft systems. It is developed in Simulink and contains the interfaces with AMESim and Dymola to exchange data throughout a simulation run.
It is composed by several blocks: - Mission Profile
- Engine
- Electrical Power Generation System
- Energy Management System
- Flight Control System
- Landing Gear System
- Ice Protection System
- Environmental Control System
- Other Systems
- Global Thermal A/C Architecture
- Temperature Controller
- Simulation time
- Output Storage
The Mission Profile block provides the input simulation data and will be briefly described in the next chapter.
The Engine block provides information about the aircraft engine where the only information consist of the RPM.
The Electrical Power Generation System contains the electric generator dynamic model and it is directly connected to the EMS.
The FCS block describes the dynamic behavior and the deflection of all control surfaces (ailerons, rudder, elevators, inboard and outboard flaps, inboard and outboard spoilers). It is developed in a previous thesis of University of Pisa, ref [1].
7
developed in a previous thesis of University of Pisa, ref [2].
The ECS, the Global Thermal A/C Architecture and their interaction has been already described in two other thesis of University of Pisa, ref [4] and ref [5]; however the models will be briefly described in chapter 3, 4 and 6 as correlated to the subject of this thesis. Chapter 5 deal with the simulation analysis, in particular with the solver used in the SSE.
IPS block is fully described in chapter 7with all the procedure to permit the
communication within Simulink and Dymola, whereas Other Systems block regards all secondary systems such as Avionic and Utilities loads and are developed in chapter 8 The Simulation Time block is useful see the time and to decide when enable every single system
The last three blocks have the function to organize each variable to plot and the other one is a display to control the time of the running simulation.
8
9
2 Mission Profile
As said in the previous chapter, this “subsystem”, so called in the MATLAB/Simulink ambient, provides the data input for a generic simulation run.
From the Simulink library, in particular in the Sources section, one can select the block
From Workspace which gives the user the possibility to load data in a matrix form and
then split them into different signals with a Bus selector block.
It is very important that the first column of the matrix data is dedicated to the time, so the software can evaluate each variable at each moment. Between two generic integration steps, a linear interpolation is performed.
Figure 2.1 From Workspace block
As shown in the previous figure the block refers to a .txt file; indeed even a file of this type, with data written as a matrix, can be read, loaded and used for the simulation. A simple MATLAB script (.m file called Input Generation) is used to create and save these data as .txt; the user can define simplified constant data just to test each model, or load the entire mission data, that come from a flight simulator developed in another thesis of
10
the Aerospace Engineering Department of University of Pisa, ref [3].
The MATLAB script generates two different .txt file, the first one contains the numeric values (Input_time_history.txt) and the second one the explanation and the measurement unit of each variable (Input_time_history_explain.txt).
Once the data are loaded and split, they are organized into three different sections: - Environmental Conditions
- A/C Flight Data - Pilot Commands The first section contains:
- Altitude, “h”
- Air Density, “rho” - Air Temperature, “T” - Air Pressure, “P” - Mach number,
All the atmospheric conditions are calculated using an ISA Model implemented into a Simulink block, which is located in the Aerospace Blockset section.
The second section contains the flight data related to the aircraft: - Speed, “Speed”
- Angle of attack, “alpha” - Angle of sideslip, “beta” - Load factor x, “nx”
- Load factor y, “ny” - Load factor z, “nz” - Roll angle, “phi” - Pitch angle, “theta” - Yaw angle, “psi” - Roll rate p, “p” - Pitch rate q, “q” - Yaw rate r, “r” - Roll acceleration, ̇
11 - Pitch acceleration, ̇
- Yaw acceleration, ̇
Finally the last section includes the various commands: - Ailerons command, “da”
- Rudder command, “dr” - Elevators command, “de” - Flaps command, “df” - Spoilers command, “dsp” - Landing gear command, “dlg” - Throttle command, “thrust” - ECS activation,
- Cabin Reference Temperature, - IPS command, “dIPS”
12
3 Environmental Control System
In this chapter we will give few details about the ECS model, which is encrypted and was developed in Simulink by Liebherr-Aerospace, ref [6].
It simulates the dynamic behavior in closed loop conditions together with the control laws and the cabin model. It includes the transient modeling of ECS components through estimated transfer functions to describe the main dynamic effects (actuators behavior, component inertia, sensor time responses). Moreover the model includes a simplified modeling of ECS static performances. The table below provides the main characteristics of the model:
13
3.1 Model inputs
The ECS model receives from the SSE the following set of information and data:
Ambient conditions:
- Mach number - Altitude [ ] - OAT [ ] A/C conditions (flight phases) Ram-Air interface conditions:
- RAM Inlet Recovery Pressure [ ] - RAM Inlet Recovery Temperature [ ] - RAM Outlet Recovery Pressure [ ] - RAM Outlet Recovery Temperature [ ] Electrical Power Available [ ]
Cabin environment data:
- current cabin temperature [ ] - current cabin pressure [ ]
ECS system targets (for A/C System Controls Coupling)
- Set-point for ECS Mass Flow provided to Cabin Control System [ ]
- Set-point for ECS Temperature provided to Cabin Control System [ ]
3.2 Model outputs
The ECS model provides the SSE with the following set of information and data: ECS cooling performances (for A/C System Environment Coupling)
- Actual Mass Flow provided to Cabin Control System [ ] - Actual Temperature provided to Cabin Control System [ ] ECS electrical power consumption [ ]
14
3.3 System parameters
The ECS model will have the following system parameters:
Flow schedule as a function of A/C altitude and/or A/C flight phases
3.4 Data list
This section is dedicated to the definition of available data for an ECS simulation.
3.4.1 Standard quantities
The standard quantities are depicted on Figure 4-1. For each component, inlet and outlet quantities are available (pressure, temperature, enthalpy).
Figure 3.1 Standard quantities
The mass flow passing through the component and component parameters are also available. Moreover it is included for each dynamic component a set of relationships to reproduce the transient phenomena (inertia, transfer functions, settling times) and another set of control laws in order to regulate the ECS temperature as required through ECS system targets within the limit of available Electrical Power.
15
3.4.2 Component parameters
For the ECS system, the main performance components are turbomachines, heat exchangers, valves, sensors: they have a set of parameters (numerical values are encrypted), described as follows:
Turbomachine
The turbomachines represents components likes compressor, turbine or fan. The following table describes the main performance parameters of these components. The inertia ( ) will limit the rotating speed accelerations and decelerations as identified through real tests performed similar components.
Table 3.2 Turbomachines parameters
Heat Exchanger
The heat exchangers are mainly defined by their efficiency and their response time:
16 Valves
The valves are defined by their efficient area when fully open and their maximum angular speed during the transient phase:
Table 3.4 Valves parameters
Sensors
The time responses of temperature sensors will be simulated in order to reproduce the dynamic behavior of the system. On contrary, the time responses of pressure sensors are not still included.
17
4 Global Thermal A/C Architecture
4.1 AMESim model
The model is developed using the Gas Mixture, Signals and Controls, Mechanical, Thermal, Moist Air libraries, ref [7]; its architecture is composed by the following sub-models, each one of them identifying a particular zone of the aircraft:
Flight deck Avionics bay Passenger cabin Cargo compartment Under-floor Galley Lavatory
Each zone is modeled considering two aspects: the air volume enclosed and the walls effects. The first one is responsible for the computation of the hygroscopic-thermal balance, the second one for the computation of heat transport through the A/C compartment walls (both opaque and transparent walls). Finally, the model needs information about the external ambient conditions to work properly; so there is included another sub-model, which provides the necessary parameters (temperature, pressure, humidity, solar radiation) depending on A/C flight phase (velocity, altitude) and weather data (ISA day). As shown in the following figure each zone model is linked with:
other zone models ambient model ECS model
18
19
4.2 Linear Analysis of the model
The Simulink tool called Linear Analysis gives the possibility to linearize a complex model around an equilibrium point (Operating point). The goal is to found the behavior, and so the transfer function, between the cabin temperature and the temperature target to send to the ECS, in order to develop the correct control law, as described in chapter 7. Further information can be found in another thesis developed also at University of Pisa, ref [5].
The exchanged heat flow between the two systems can be written as follows:
̇ ( ) ( ) Where the term indicates the heat flow coming from other CT utilities (e.g. avionics, galley and other sources visible on the AMESim model). The cabin temperature is directly proportional to this quantity, integrated in a certain temporal interval. So, if we work in the Laplace domain and ignore the term to simplify the problem, we obtain a first order system, i.e.:
( ) ∫ ( ) ( ) ( ) ̇ ( ) ( ) ( ) ( ) ( ) ( )
20
5 Simulation Analysis
5.1 Simulation Parameters in Simulink
Co-Simulation is found to be the best way to operate with two (or more) software, the choice of the right solver and the setting of the other parameters is essential to obtain both good results and good computational time. We have to say that when it is necessary to simulate a large engineering system, it is normal to reduce any partial differential equations to ordinary differential equations. This leads to models with either ordinary differential equations (ODEs) or differential algebraic equations (DAEs). A generic solver is a tool that applies a numerical method to solve this set of ordinary differential equations that represent the model; it also satisfies the accuracy required by the user.
Simulink, ref [11] gives the possibility to choice between two types of solvers: - fixed-step solver
- variable-step solver
The chosen solver is the ode23t and the obtained computational times (using an HP Z800 Workstation, dual-processor, 64 bit, six-core system), that will be kept even in the complete SSE, are about five seconds for one second of mission.
It is a variable-step solver and it can be included in the category of one-step solvers: the Simulink solver library indeed, provides both one-step and multistep type. The first one estimate ( ) using the solution at the immediately preceding time point ( ), and the values of the derivative at a number of points between and . These points are minor steps. The multistep solvers use instead the results at several preceding time steps to compute the current solution.
Some considerations must now to be done about the accuracy for a solver of this kind, so we have to introduce the concept of error and tolerance. About the first one, in particular a local error, the variable-step solvers use standard control techniques to monitor it at each time step. During each time step, the solvers compute the state values at the end of the step and determine the local error; it is the estimated error of these state values ( ).
21
Then the local error is compared to the acceptable error, which is a function of both the relative tolerance ( ) and the absolute tolerance ( ). If the local error is greater than the acceptable error for any one state, the solver reduces the step size and tries again. The relative tolerance measures the error relative to the size of each state; it represents a percentage of the state value. The default value is set to 0.001. The absolute tolerance is instead a threshold error value and it represents the acceptable error as the value of the measured state approaches zero. It is applied to all states in a model.
The solvers require the error for a generic state, to satisfy: ( | | )
The following Figure 5.1 shows a plot of a state and the regions in which the relative tolerance and the absolute tolerance determine the acceptable error.
Figure 5.1 Thermal Architecture Model
Simulink sets the absolute tolerance for each state to 1 as default value. As the simulation progresses, the absolute tolerance for each state resets to the maximum value that the state has assumed so far, measures the relative tolerance for that state. Thus, if a state changes from 0 to 1 and is 1 , then by the end of the simulation, becomes 1 also. If a state goes from 0 to 1000, then changes to 1.
A too low value for absolute tolerance causes the solver to take too many steps in the vicinity of near-zero state values, so the simulation is slower. On the other hand, a too high can be inaccurate as one or more continuous states in your model approach zero. So once the simulation is complete, the user can verify the accuracy of the results by reducing the absolute tolerance and running the simulation again. If the results of these two simulations are satisfactorily close, then he can feel confident about their accuracy.
22
6 Cabin Thermal Model: Closed Loop Analysis
While the A/C is performing its mission it is important to guarantee optimal conditions for the passengers in the cabin in terms of temperature and pressure.
So, for this reason, it is necessary to put the model in closed loop to obtain preset values of these two magnitudes.
6.1 Temperature controller
To better understand we can consider the following “retroaction-scheme”:
Where is the required temperature value in the cabin and its difference with the actual cabin temperature ( ) is processed by the controller. The magnitude comes out from this block is the target temperature for the ECS system, obtained by the relation:
( ) ( ) Where k is the generic controller gain. Depending on the value of the ECS target, the
system regulates the air temperature that must be sent into the cabin.
Analyzing more in detail the block called “CONTROLLER” we can find a proportional integrative controller (PI) as the best solution. In formal way we have:
( ) ( ) - +
CONTROLLER ECS CABIN THERMAL
23
{ ∫ } ( )
In the Laplace domain it becomes:
{ } ( )
The various values of gains, zeros, and poles were founded observing different tests done on the global model. About the proportional gain we can say that if i.e. the actual cabin temperature is minor than the target value, the ECS must provide a “hotter” quantity of air to the cabin, so must be greater than zero. The same line of reasoning can be used if . Concerning the integrative part of the controller, it is used to reduce the error when the system operates at full speed; on the other side there is no need to use a derivative part because of the lack of overshoot and the presence of a good damping of the system.
The gain values used for the controller are: -
-
In a formal way, the transfer function controller can be written as:
(
) ( ) Using the SISO Matlab tool is possible to see the root locus when this controller is applied to the transfer function ( ) ( ), which is a first order, as it was been described in chapter 5. The entire transfer function ( ) is:
( )
(
) ( )
Where there is an electronic pole settled into the origin and one zero, with value:
24
7 IPS: Ice Protection System
7.1 Description of the IPS model
The IPS model was developed by Zodiac Aerospace, ref [10] currently only at an Architectural level using the Dymola Modelica modeling language, ref [12] and was delivered with the only possibility to run autonomously in Dymola due to the lack of an interface panel to communicate with the Matlab Simulink environment.
25
IPS was supplied with a pre-set activation sequence to simulate a test to evaluate the power absorbed
Figure 7.2 IPS power absorption
In this model, the IPS mean power consumption has been calculated using pre-defined blocks, which are based on estimations of the typical power densities for both Electro-Thermal and Electro-Mechanical deicers.
26
The level 1 model included models for three different types of deicing units: the first type is an Electro-thermal deicer used in anti-ice mode.
It operates by heating the plane’s sail to a pre-definite temperature, in order to prevent the ice from forming on the surface. The power consumption profile for this type of deicer looks like the following:
ET
d
ei
cer
Time
The second one is an electro-thermal deicer used in deice-mode, in this mode, the deicer operates alternating standby phases (power consumption is approximately 0 during these phases), and short pulses of high intensity (equivalent to the intensity of the anti-ice mode). The power consumption profile for this type of deicer looks like the following:
1 2 Time Start ET d ei cer
Figure 7.3 Power consumption profile for type 1 deicers
27
The third type is an Electro-expulse deicer. Its operating mode can be compared to an electrical capacitor. It alternates short reloading periods (the power consumption during these phases are much lower than for type 1 deicers, about 20 times lower) and longer expulse periods (not perceived by the system). The power consumption profile for this type of deicer looks like the following:
1 2 Time Start EE d e ice r
28
7.2 Electrical unit model
The electrical unit model’s function is to read the starting signal send by the sequencer to the slats and converts these signals for each deicer into voltage signals, used in the computation of the power consumption. One electrical unit is used to control 5 deicers. The parameters are set using the following interface:
29
Every deicer was marked with an integer variable which indicated the kind of the deicer and its state as shown in Table 7.1, even if at architectural level there were not differences in the power absorption calculation, due to the fact that all the deicer were modelled as simple resistive loads.
State/Type Value
Off/Error 0
Electro-thermal-anti-Ice 1 Electro-thermal-de-Ice 2
Electro-expulse 3
30
7.3 Editing the IPS model
First of all it has been necessary to modify the IPS model provided collocating input and output interfaces with Simulink, in details as depicted in Figure 7.7: five activation and one voltage signals as input and two power absorption signals as output.
31
7.4 Dymola – Simulink Interface
This interface consists of some .m files which are a set of Matlab utilities and a Simulink block, called DymolaBlock which allows importing a Dymola model once the user has defined inputs and outputs. In order to use all these features the first operation to do is include the following directories in the Matlab path:
Program Files\Dymola 2013 FD01\Mfiles
Program Files\Dymola 2013 FD01\Mfiles\dymtools
Program Files\Dymola 2013 FD01\Mfiles\traj
The user has to pay attention when he uses the Matlab command restoredefaultpath because it restores the original path and removes these previous added ones. Moreover the only compiler who consents to generate the S-function is Microsoft Visual C++ (version 2010 is well-matched with the other software used). Finally note that Matlab R2010bSP1, R2011a, R2011b, and R2012a will give warnings that files in the Program Files\Dymola 2013 FD01\Mfiles folder are generated with an old p-code version. These warnings are uncritical and can be turned off by adding the following line to the Matlab startup script:
warning('off', 'MATLAB:oldPfileVersion')
By double-clicking on the block a graphical user interface is opened to configure everything is necessary for the compilation. As it is visible in the following picture it is important to set the Model name and File name; a fast way is to open the desired model in Dymola, let the program opened and then click on the button Select from
Dymola. The button Edit model allows modifying the IPS Modelica model, Reset Parameters restore parameters and start values to the default in Dymola, Compile model generate the S-function and the other files useful to the Simulink block.
32
Figure 7.8 Dymola-Simulink interface Block and Mask
At the end of the procedure the mask should appear like shown in Figure 7.9
As shown from the figure the mask gives the user the possibility to change every single parameter of the model from the Dymola-Simulink mask interface.
33
34
7.5 Simulink input and output of the IPS model
The new edited IPS model gives the user the possibility to communicate with the Simulink environment; in order to do this five switches and one voltage signals are requested as input and as already said the IPS model supply the power absorbed by the system as output.
35
In order to decide the order of the electrical unit model activation a new sequencer was implemented into the Simulink environment as shown in Figure 7.11
Figure 7.11 Simulink IPS Sequencer
The sequencer has an IPS activation signal as input, which is taken from the
Input_time_history.txt file which activate the first electrical unit model.
The other four units start operating each one with a certain delay set in the
IPS_DATA.m file from the activation of the first unit.
This operation was accomplished using the Unit delay block from the Simulink library shown in Figure 7.12
36
7.6 The Second order filter
As previously reported the IPS model is a Level 1 Architectural model, because developed only with the use of a simple resistive loads and the complete absence of inductive loads cause huge changes of power request in infinitesimal amount of time, developing a poor physical behavior.
The SSE software is integrating models that describe the physical behavior of the systems quite accurately being developed at a Functional level (Level 2), therefore the necessity to have results from the IPS model with a more physical behaviour; in fact using the IPS original model every time we had an instantaneous loss or increase of power the SSE variable-step solver thickened the step of resolution.
This undesirable effect has an enormous impact on this model in particular since the power request periodically change every few seconds, due to the on/off logic of the IPS system.
This implied an exaggerated amount of time needed for the simulation or even its failure.
This has been the main reason for the effort made in the adaptation of the IPS simple model in the SSE.
This led to the introduction of a second order filter:
( )
with a high value of dumping ( ) and pulsation ( ) operating on the output of the system: the power absorption; this way it has been possible eliminating spidery point and instantaneous change of value of the power, which were index of a system developed only at architectural level.The following Figure 7.13 and details display the difference between the two power signals: in yellow the clean signal, in pink after the filter effect.
37
38
8 Utilities and Avionic loads
8.1 Analysis of the Utilities and Avionic loads
In order to simulate critical situations we had to carefully estimate the power absorbed even by secondary systems such as Avionic/Navigation, Lights, Water Waste and Equipment/Furnishing; the last three representing Utilities has been called CCS (Commercial Cabin Systems) as reported in Table 8.1
A detailed description of these systems follows, ref[9]: Avionic / Navigation
The Avionic related to the GRA configuration will be different from that one related to the ATR 72-600 configuration but, nevertheless, the variation in terms of electrical data should be negligible.
Lights
- External Lights (same of ATR 72-600)
- Internal Lights (similar A/C: Sukhoi Superjet 100) in particular: o 54 LED Light Strip
o 98 Passenger LED Reading Lights
o Cabin Interior Light (i.e. lavatory and toilet lighting) o Cockpit Light: instrument and panel light
Water Waste
Power consumption not continuously powered, however comparable to similar A/C
39 Equipment/Furnishing
- One standard and one optional lavatory - Two galley modules composed of:
a. First galley
i. Beverage maker ii. Work light iii. Control panel b. Second galley
i. Beverage maker ii. Two working ovens iii. Control panel iv. Work light - Seats without IFE system - Flight Attendant panel - PSU
These loads have been subject of study regarding their power absorption and from literature referring to a similar aircraft (ATR 72-600 or Sukhoi Superjet 100), due to the fact that a real GRA still not exist and properly proportioned with a factor to a 90-passenger aircraft.
Table 8.1 reports these values for the most critical situation:
Load Power absorbed (kW)
Avionic/Navigation 1
CCS1 Lights 3
CCS3 Water Waste 4
CCS2 Equipment/Furnishing 2
40
9 Energy Management System
9.1 Description of the EMS model
During the A/C mission, a generic extra electrical load can occur; so, it is completely addressed to the overload capacity of the generator. This circumstance can be very dangerous if this load is too high, so, the introduction of the EMS becomes indispensable: it is a set of logics used for the optimal sharing of the total on-board electrical power, indeed, in some mission sections, several loads may be totally shed or temporary reduced, because they are not flight or safe-landing essential. Thus no overload can be found because this set of specific control laws, acting on power electronics and motor controllers, change the supplied power to each system with respect to the requested one.
The EMS optimizes the sharing of the on-board electrical power and limit the power to the non-critical systems, when necessary, in order to give the required power to the critical ones. The EMS model developed by ALA, ref[8] in Dymola-Modelica includes EMS logics, Solid State Power Controllers (SSPCs) and a High Voltage DC Bus-bar (on a single generation channel). EMS logics continuously monitor the EPGS current and its time derivative. When an overload condition is detected, the logics operate before on the SSPCs contactors to obtain a faster power absorption reduction (High frequency action). If the overload persists, the logics require to the ECS a reduction of the power absorbed by the ECS itself (Low frequency action) as shown in the particular Figure 9.1 from 530s to 550s of the Flight history simulation
41
Figure 9.1 Flight history results (530 s-550 s)–Voltages, Power Absorbed
530 532 534 536 538 540 542 544 546 548 550 100 150 200 250 Ele ctr ic al Vo lta ge s (V ) 530 532 534 536 538 540 542 544 546 548 550 2 4 6 8 x 10 4 Po we r (W) EPG ECS CCS 1 C C S 2 C C S 3 AV IPS Ove rlo ad FC S LG S 530 532 534 536 538 540 542 544 546 548 550 0 2000 4000 Po we r (W)
42
The electrical current absorbed by all the systems is fed back to the EPGS in order to evaluate the actual voltage available. On the basis of such a voltage and of the current absorbed, the EMS model applies the energy management strategies and regulates the voltage supplied to the various systems. A particular interface exists between EMS and ECS. Actually, the EMS can ask the ECS for a reduction of the electrical power absorbed by the ECS itself. In its turn, the ECS sends warnings to the EMS when it cannot further reduce the power absorbed, because the cabin temperature can go out from the required range or because there is the risk of a compressor stall (ECS output flags). Figure 9.2 depicts the EMS system with currents from other systems as input and voltages as output.
43
44
9.2 EMS Dymola-Simulink interface
Figure 9.2 represents the Dymola Simulink interface for the EMS, where is possible to set some important parameters of the system in particular the Power threshold, that is the value from which EMS start operating actively.
45
9.3 Analysis of EMS behavior in a critical condition
One of the main purposes of the SSE project is to evaluate the behavior of the EMS in critical conditions, such as the loss of one of the two engines and in addition the failure of one of the two ECS pack.
All the following results refer to this critical situation where a single ECS pack has to be able to supply approximately 250kW of Power in a condition of climb in order to manage and distribute this to all the A/C systems.
This value has been obtained by various researches over literature publications about this topic.
However this is an operative limit for the Power provided, the power threshold value will be set at a lower value (approximately 70kW), so that the EMS logic would be able to operate and deal with any overload request.
46
10 Simulation Run and Results
10.1 Initial trim procedure
Once the SSE is complete in its prototype version, it is possible to obtain the first numerical results. This tool is designed to simulate typical A/C maneuvers starting from assigned initial trim conditions, where the various systems can be characterized by not null currents and by constant values of the internal variables and states. An off-line evaluation (before starting the simulation) of the trim would have been complex, so it is done via a dynamic simulation, made within and additional initial time: a time range of 150 seconds is added at the beginning of the time histories, as schematically described in figure 8-1. In this time range, each input variable is kept constant and equal to its first value in the time history. Moreover, to reduce the computational time during this phase, the various involved models are progressively enabled with the following sequence:
- EPGS, IPS, EPGS/EMS, FCS and LGS start at 1 second - ECS, CT model and its controller at 10 seconds
47
The Simulation Time block has been updated to guarantee a more organized form of the SSE layout as shown in Figure 10.1 with a unique enabling bus signal which was connected to all the systems.
Figure 10.1 Model of enabling sequence for starting
In correspondence of each system a bus selector with a single signal as output was placed in order to choose the correct enabling signal, Figure 10.2.
48
This approach, based on the progressive enabling, drastically reduces also the possibilities of incurring in the divergence of some systems during the trim-search phase.
Figure 10.3 Time range added to evaluate the trim condition via dynamic simulation
At this point the user can choose two different type of flight histories, and therefore two different type of input data:
- “Dummy” input data - “Flight history” input data
input t input t original modified 150 sec
Time range added to let the systems reach the “trim”
49
10.2 “Dummy” input data
The user has to choose between two different input data for the simulation: the first is not a real flight history and it is used to evaluate the dynamic behavior of each system being part of the SSE. Indeed the altitude and the Mach number are set to a constant value (respectively 0 and 0.38), the angle of attack, the angle of sideslip, the Euler Angles, the angular velocities and the angular accelerations are all set to zero. Instead the deflection range of all control surfaces is arbitrary between the minimum and the maximum and the engine is at full operative speed.
The total “flight history” time is , where the first are used to trim the model, in particular the ECS and the Cabin, as said before. There is the activation of the landing gear system few seconds after the trim procedure.
Figure 10.4 “Dummy” input data – ECS Command and Cabin reference Temperature
0 50 100 150 200 250 300 350 400 450 500 0.8 0.9 1 1.1 time [s] EC S ac tiv at ion 0 50 100 150 200 250 300 350 400 450 500 22.5 23 23.5 time [s] C abin ref erenc e t em perat ure [deg]
50
Figure 10.5 “Dummy” input data – Control Surfaces Deflection
Figure 10.6 LGS and IPS activation signals
0 50 100 150 200 250 300 350 400 450 500 0 0.2 0.4 0.6 0.8 1 time [s] LGS ac tiv at ion 0 50 100 150 200 250 300 350 400 450 500 0 0.2 0.4 0.6 0.8 1 time [s] IPS ac tiv at ion
51
10.3 “Dummy” simulation results
Simulation results (43 min CPU time) are summarized in the following pictures:
Figure 10.7 “Dummy” results – Control Surfaces Deflection
0 50 100 150 200 250 300 350 400 450 500
0 10 20
LEFT AILERON Angular Deflection
time [s] [d e g ] Reference Actual 0 50 100 150 200 250 300 350 400 450 500 -20 -10 0
RIGHT AILERON Angular Deflection
time [s] [d e g ] Reference Actual 0 50 100 150 200 250 300 350 400 450 500 -20 0 20
LEFT ELEVATOR Angular Deflection
time [s] [d e g ] Reference Actual 0 50 100 150 200 250 300 350 400 450 500 -20 0 20
RIGHT ELEVATOR Angular Deflection
time [s] [d e g ] Reference Actual 0 50 100 150 200 250 300 350 400 450 500 -20 0 20
RUDDER Angular Deflection
time [s] [d e g ] Reference Actual
52
Figure 10.8 “Dummy” results – Flap Deflection
0
50
100
150
200
250
300
350
400
450
500
0
5
10
L
E
F
T
I
N
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fle
c
ti
o
n
ti
m
e
[
s
]
[d
eg
]
R
e
fe
re
n
c
e
A
c
tu
a
l
0
50
100
150
200
250
300
350
400
450
500
0
5
10
R
IG
H
T
I
N
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fle
c
ti
o
n
ti
m
e
[
s
]
[d
eg
]
R
e
fe
re
n
c
e
A
c
tu
a
l
0
50
100
150
200
250
300
350
400
450
500
0
5
10
L
E
F
T
O
U
T
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fle
c
ti
o
n
ti
m
e
[
s
]
[d
eg
]
R
e
fe
re
n
c
e
A
c
tu
a
l
0
50
100
150
200
250
300
350
400
450
500
0
5
10
R
IG
H
T
O
U
T
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fle
c
ti
o
n
ti
m
e
[
s
]
[d
eg
]
R
e
fe
re
n
c
e
A
c
tu
a
l
53
Figure 10.9 “Dummy” results – LG Extraction/Retraction
0
50
100
150
200
250
300
350
400
450
500
0
0
.5
1
N
o
s
e
E
M
A
r
o
d
p
o
s
it
io
n
ti
m
e
[
s
]
[m
]
A
c
tu
a
l
R
e
fe
re
n
c
e
A
c
ti
va
ti
o
n
0
50
100
150
200
250
300
350
400
450
500
0
0
.5
1
L
e
ft
E
M
A
r
o
d
p
o
s
it
io
n
ti
m
e
[
s
]
[m
]
A
c
tu
a
l
R
e
fe
re
n
c
e
A
c
ti
va
ti
o
n
0
50
100
150
200
250
300
350
400
450
500
0
0
.5
1
R
ig
h
t
E
M
A
r
o
d
p
o
s
it
io
n
ti
m
e
[
s
]
[m
]
A
c
tu
a
l
R
e
fe
re
n
c
e
A
c
ti
va
ti
o
n
54
Figure 10.10 “Dummy” results – EPGS Voltage, Current and flags
0 50 100 150 200 250 300 350 400 450 500 -500 0 500 1000 EP GS tim e [s ] EPGS v oltage (V) 0 50 100 150 200 250 300 350 400 450 500 -1000 -500 0 500 tim e [s ] EPGS c urrent (A) 0 50 100 150 200 250 300 350 400 450 500 0 0. 5 1 tim e [s ] EPGS s ignals Ov er-c urrent U nder-v olt age Ov er-v olt age G-C
55
Figure 10.11 “Dummy” results – ECS Outlet Temperature and Mass flow
0 50 100 150 200 250 300 350 400 450 500 -40 -20 0 20 40 tim e [s ] Pack Out let tem perature (°C ) EC S Ac tual Target 0 50 100 150 200 250 300 350 400 450 500 0 0. 2 0. 4 0. 6 0. 8 1 tim e (s ) Pack Out let mas s f low(k g/s )
56
Figure 10.12 “Dummy” results – CT Temperature & Pressure
0 50 100 150 200 250 300 350 400 450 500 10 20 30 40 tim e [s ] Cabin Tem perature (°C ) CT Ac tual Target 0 50 100 150 200 250 300 350 400 450 500 1 1. 02 1. 04 1. 06 1. 08 1. 1 tim e (s ) Cabin Press ure (bar)
57
Figure 10.13 “Dummy” results – Voltages, Currents and El. Power Absorbed – ECS flags
0 50 100 150 200 250 300 350 400 450 500 0 100 200 300 Electric al Voltages (V) 0 50 100 150 200 250 300 350 400 450 500 0 100 200 300 Current s (A) EPG EC S C C S 1 C C S 2 C C S 3 AV IPS Ove rlo ad F C S LG S 0 50 100 150 200 250 300 350 400 450 500 0 1 2 x 10 5 Power (W) 0 50 100 150 200 250 300 350 400 450 500 0 0. 5 1 tim e (s ) ECS Signals (-) D E C IN C M IN F LO W N O R M F LO W S TA B IL IZ IN G
58
Figure 10.14 Detail: “Dummy” results – Voltages, Currents and El. Power Absorbed
240 245 250 255 260 265 270 100 150 200 250 Electric al Voltages (V) 240 245 250 255 260 265 270 0 100 200 300 Current s (A) EPG EC S C C S 1 C C S 2 C C S 3 AV IPS Ove rl o a d F C S L G S 240 245 250 255 260 265 270 2 4 6 8 x 10 4 Power (W) 240 245 250 255 260 265 270 0 2000 4000 Power (W)
59
10.4 “Flight history” input data
The second option available is to use a real flight history with data generated by a flight simulator, developed in a previous work of thesis, ref[3], as said in the first chapter:
Figure 10.15 Flight history input data – Mach, Altitude
The A/C starts and concludes its mission at the altitude of because in the flight simulator neither take-off nor landing are still analyzed. Mach number is still set to . 0 1000 2000 3000 4000 5000 6000 0 2000 4000 6000 time [s] a lt it u d e [ m ] 0 1000 2000 3000 4000 5000 6000 -1 0 1 2 time [s] M a c h [ m ]
60
Figure 10.16 Flight history input data – Aerodynamic Angles
Figure 10.17 Flight history input data – Linear Accelerations
0 1000 2000 3000 4000 5000 6000 0 5 10 15 time [s] A n g le o f a tt a c k [ d e g ] 0 1000 2000 3000 4000 5000 6000 -2 -1 0 1 time [s] A n g le o f s id e s lip [ d e g ] 0 1000 2000 3000 4000 5000 6000 -5 0 5 time [s] A x [ m /s e c 2] 0 1000 2000 3000 4000 5000 6000 -5 0 5 time [s] A y [ m /s e c 2] 0 1000 2000 3000 4000 5000 6000 -50 0 50 time [s] A y [ m /s e c 2 ]
61
Figure 10.18 Flight history input data – Euler Angles
Figure 10.19 Flight history input data – Angular Velocities
0 1000 2000 3000 4000 5000 6000 -20 0 20 time [s] ro ll [d e g ] 0 1000 2000 3000 4000 5000 6000 -20 0 20 time [s] a tt it u d e [ d e g ] 0 1000 2000 3000 4000 5000 6000 -200 -100 0 time [s] y a w [ d e g ] 0 1000 2000 3000 4000 5000 6000 -10 0 10 time [s] ro ll ra te [ d e g /s e c ] 0 1000 2000 3000 4000 5000 6000 -50 0 50 time [s] a tt it u d e r a te [ d e g /s e c ] 0 1000 2000 3000 4000 5000 6000 -5 0 5 time [s] y a w r a te [ d e g /s e c ]
62
Figure 10.20 Flight history input data – Angular Accelerations
Figure 10.21 Flight history input data – Engine
0 1000 2000 3000 4000 5000 6000 -40 -20 0 20 time [s] ro ll a c c . [d e g /s e c 2] 0 1000 2000 3000 4000 5000 6000 -200 0 200 time [s] a tt it u d e a c c . [d e g /s e c 2 ] 0 1000 2000 3000 4000 5000 6000 -10 -5 0 5 time [s] y a w a c c . [d e g /s e c 2] 0 1000 2000 3000 4000 5000 6000 0 0.5 1 1.5 2 time [s] th ro tt le [ % ] 0 1000 2000 3000 4000 5000 6000 0.9999 1 1 1.0001 1.0001x 10 4 time [s] T h ru s t [N ]
63
Figure 10.22 Flight history input data – ECS command and Cabin refer. temperature
The ECS system is activated after from the beginning of the simulation while the decrease of temperature (a step of ) is underlined in the second (top to bottom) line of the graphic, from .
0 1000 2000 3000 4000 5000 6000 0 0.5 1 1.5 2 time [s] E C S a ctiva ti o n 0 1000 2000 3000 4000 5000 6000 20 21 22 23 time [s] C a b in r e fe re n ce t e m p e ra tu re [ d e g ]
64
Figure 10.23 Flight history input data – Control Surfaces Deflection
Figure 10.24 Flight history input data - LGS and IPS activation signals
0 1000 2000 3000 4000 5000 6000 -20 0 20 time [s] a ile ro n s [ d e g ] 0 1000 2000 3000 4000 5000 6000 -6 -5 -4 time [s] ru d d e r [d e g ] 0 1000 2000 3000 4000 5000 6000 -10 0 10 time [s] e le v a to rs [ d e g ] 0 1000 2000 3000 4000 5000 6000 0 50 100 time [s] fl a p s [ d e g ] 0 1000 2000 3000 4000 5000 6000 -1 0 1 time [s] s p o ile rs [ d e g ] 0 1000 2000 3000 4000 5000 6000 0 0.5 1 time [s] L G S a c ti v a ti o n 0 1000 2000 3000 4000 5000 6000 0 0.5 1 time [s] L G S a ctiva tio n 0 1000 2000 3000 4000 5000 6000 0 0.5 1 time [s] IP S a ctiva tio n
65
10.5 “Flight history” simulation results
Simulation results (8h 42 min CPU time) are summarized in the following pictures:
Figure 10.25 Flight history results - Control Surfaces Deflection
0 1000 2000 3000 4000 5000 6000 -5 0 5 L E F T A IL E R O N A n g u la r D e fl e c ti o n [d eg ] 0 1000 2000 3000 4000 5000 6000 -5 0 5 R IG H T A IL E R O N A n g u la r D e fl e c ti o n [d eg ] 0 1000 2000 3000 4000 5000 6000 2 4 6 L E F T E L E V A T O R A n g u la r D e fl e c ti o n [d eg ] 0 1000 2000 3000 4000 5000 6000 2 4 6 R IG H T E L E V A T O R A n g u la r D e fl e c ti o n [d eg ] 0 1000 2000 3000 4000 5000 6000 -5. 5 -5 -4. 5 R U D D E R A n g u la r D e fl e c ti o n ti m e [ s ] [d eg ]
66
Figure 10.26 Flight history results – Flap Deflection
0 1000 2000 3000 4000 5000 6000 0 20 40
L
E
F
T
I
N
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fl
e
c
ti
o
n
[d
eg
]
0 1000 2000 3000 4000 5000 6000 0 20 40R
IG
H
T
I
N
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fl
e
c
ti
o
n
[d
eg
]
0 1000 2000 3000 4000 5000 6000 0 20 40L
E
F
T
O
U
T
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fl
e
c
ti
o
n
[d
eg
]
0 1000 2000 3000 4000 5000 6000 0 20 40R
IG
H
T
O
U
T
B
O
A
R
D
F
L
A
P
A
n
g
u
la
r
D
e
fl
e
c
ti
o
n
ti
m
e
[
s
]
[d
eg
]
R e fe re n ce A ct u a l67
Figure 10.27 Flight history results – LG Extraction/Retraction
0 1000 2000 3000 4000 5000 6000 0 0. 5 1
N
o
s
e
E
M
A
r
o
d
p
o
s
iti
o
n
[m
]
0 1000 2000 3000 4000 5000 6000 0 0. 5 1L
e
ft
E
M
A
r
o
d
p
o
s
iti
o
n
[m
]
0 1000 2000 3000 4000 5000 6000 0 0. 5 1R
ig
h
t
E
M
A
r
o
d
p
o
s
iti
o
n
tim
e
[
s
]
[m
]
A c tu a l R e fe re n c e A c tiv a tio n68
Figure 10.28 Flight history results – EPGS Voltage, Current and flags
0 1000 2000 3000 4000 5000 6000 -50 0 0 500
E
P
G
S
EP
GS
vo
lta
ge
(V
)
0 1000 2000 3000 4000 5000 6000 -20 00 0 2000EP
GS
cu
rre
nt
(A
)
0 1000 2000 3000 4000 5000 6000 0 0. 5 1 ti m e [ s ]EP
GS
sig
na
ls
O ve r-cu rr e n t U n d e r-vo lta g e O ve r-vo lta g e G -C69
Figure 10.29 Flight history results – ECS Outlet Temperature and Mass flow
0 1000 2000 3000 4000 5000 6000 -40 -20 0 20 40
Pa
ck
O
utl
et
te
mp
era
tu
re
(°C
)
E
C
S
Ac tual T arg et 0 1000 2000 3000 4000 5000 6000 0 0. 5 1ti
m
e
(
s
)
Pa
ck
O
utl
et
ma
ss
fl
ow
(k
g/s
)
70
Figure 10.30 Flight history results – CT Temperature & Pressure
0 1000 2000 3000 4000 5000 6000 15 20 25 30 Ca bin Te mp era tu re (°C ) CT Ac tual T arg et 0 1000 2000 3000 4000 5000 6000 0. 95 1 1. 05 1. 1 1. 15 ti m e ( s ) Ca bin Pre ss ure (b ar)
71
Figure 10.31 Flight history results – Voltages, Currents, Power Abs. and ECS flags
0 1000 2000 3000 4000 5000 6000 100 200 Ele ctr ic al Vo lta ge s (V ) 0 1000 2000 3000 4000 5000 6000 0 100 200 300 Cu rre nts (A ) 0 1000 2000 3000 4000 5000 6000 0 5 x 10 4 Po we r (W) EPG EC S C C S 1 C C S 2 C C S 3 AV IPS Ove rl o a d F C S L G S 0 1000 2000 3000 4000 5000 6000 0 0. 5 1
tim
e
(
s
)
EC S Sig na ls (-) D E C IN C M IN F L O W N O R M F L O W S T A B IL IZ IN G72
Figure 10.32 Detail: Flight history results (500s-850s)–Voltages, Currents, Power Abs.
