Wednesday, May 30, 2018

Six DoF Nonlinear Aircraft Model: Challenges in Software Development


Recently I wrote an article where I needed an aircraft model to simulate the phenomenon I was trying to describe. I’ve used a six-degrees-of-freedom (6 DoF) nonlinear model of an F-16 provided by the book Aircraft Control and Simulation (Stevens & Lewis, 2003). The codes were in Fortran and I translated them to Scilab scripts doing a little bit of software engineering and turn all of them into a small project at GitHub named McFlight. Through the next lines I will detail what is supposed to be a six-degrees-of-freedom nonlinear aircraft model, using the structure at McFlight as an example. And also I will try to assess how far (or close) such model is from the ones used by aerospace industry.

What is a 6 DoF Nonlinear Aircraft Model?


A very good approach to make science is to find a mathematical model to represent the piece of world you are interested in. Once your model is validated, you are able to make good predictions on that specific field. However, the beauty of a model is that you focus your spyglass on the relevant details of the observed phenomenon. For example, if I am studying the aerodynamics of wings, I would certainly be interested to model the flow detachment developing throughout the wing surface. But in a flight mechanics model I just need to know how aerodynamic forces change due to variables like angle-of-attack, Mach number, angle-of-sideslip, control surfaces deflections, regardless of how the flow detachment or any other specific aerodynamic phenomenon happens.

So we have an aircraft model to study the flight mechanics. This model is a set of ordinary differential equations and we may represent it as shown in Figure 1.

Figure 1. Differential equation for dynamic system model.

Basically we have a variable called state (X), a vector with the variables which describe the dynamics of our system, in this case, for example, we would have angle-of-attack, airspeed, pitch angle, rolling angle, sideslip angle, etc. And a variable called control (U) which represents the inputs in our system, in this case, the deflection of the aerodynamic surfaces (elevator, rudder, aileron, flaps, etc), engine setting or any other control input. Our model is the solution of the differential equations system shown in Figure 1. It is important to note that the input variables must be independent, otherwise it will be a state or output variable. The identification of the inputs is not always straightforward such that we have to be careful in order to avoid ending up with an incorrectly determined system of equations.

In mathematics, we say that a system is nonlinear when the output is not necessarily proportional to the input. For example, we cannot say that when we deflect the elevators, the lift force will increase by the same amount, differing only by a multiplication factor or that if we deflect the elevators in 5°, the increase in the lift force will correspond to the ones equivalent to 3° plus 2° deflections. In other words, the system will not necessarily respect the mathematical properties of linearity, which are:

  • Additivity: f(a+b) = f(a) + f(b)
  • Homogeneity: f(a*x) = a*f(x)

Nonlinear systems are much more representative of physical phenomena than linear systems. However, we have strong mathematical tools to work out on linear systems, including some of the most used design techniques for automatic control. Fortunately, we can link these two modeling approaches finding a linear approximation of a nonlinear model in the surroundings of an equilibrium point. Then we can make use of the linear mathematical tools, always paying attention to the assumptions taken on linearization process.

Finally, when we say six-degrees-of-freedom (or 6 DoF) we mean that our model is considering 3 translational and 3 rotational directions of movement as shown in the Figure 2 borrowed from this other article in which I discuss the “Aircraft diving before climbing or NMP zero in load factor response”.

Figure 2. Six degrees of freedom. The straight lines mean translational movements of back and forth following the arrows directions; the arches mean rotational movements clockwise and counter-clockwise around the center of gravity of the aircraft (assumed to be in the circle with the cross in the pictures). (Embraer super-tucano three views were found here).

Software requirements for the implementation


The main objective of the model we are describing here is to assess the flight mechanics and eventually to support the design of automatic flight controls. Then let us follow briefly a typical cycle for flight controls system (FCS) development so that we can tackle the main needs from a software engineering perspective.

Considering a classical approach, as stated by Rauw, the very first stage would be running (guess what) a 6 DoF nonlinear aircraft model starting from different trim conditions (equilibrium points, as explained below), mainly to get the feeling about the plant dynamics and aircraft mechanics as a whole. Also this nonlinear model will be the input for the linearization process which, in turn, will provide the linearized models for the controller design. Notice that both linearization and simulation operations will require a trim condition (provided by a trimming operation), but they are not related to each other. In other words, the linearization of the nonlinear model does not depend on the simulation of this model.

Breaking down the operations in further details:

  • We need to trim the aircraft model. This means we have to find the inputs and states values to “balance” the plant, such that the states derivatives are equal to zero. Finding these equilibrium conditions can be done by building a cost function whose minimal value gives us a trim condition as a solution (this is a possible approach and the one we are using here);
  • We need to run the model. This means solving numerically the differential equation representing the model (Figure 1), using the trim conditions found above to initialize the model;
  • We need to linearize the model for different trim conditions. This means finding a first order approximation for the model function in the surrounding of a given equilibrium point. This will support the controller design (assuming we are using a linear design approach).

Trimming and running the model enable us to simulate (off-line, which means here that is not real time simulation as Rauw called) many conditions and maneuvers throughout the flight envelope, helping even to clarify the requirements for the controller itself. Also we will need to assess how to discretize the flight envelope for the controller design, which means choosing the points to linearize the model. But what we are interested to highlight here is that the activities listed above (mainly trimming and running), which use the nonlinear aircraft model, will be executed very often, so it is desirable that they can perform computationally as fast as possible. We don’t want to wait minutes to trim the model or that 1 second of off-line simulations run in 1 or more real second.

Once we finished the linear design of the controller (using linear analysis with robustness, comfort and some performance criteria) we have to keep going with the development adding the controller in the full nonlinear aircraft model “to ensure that the design works in this domain” (as shown in this GARTEUR book). Notice that we will have to take our designed linear controller to the nonlinear (more representative) full model, doing the necessary adaptations. And as taught by master McRuer, the next step “usually involves a series of increasingly realistic tests that attempt to thoroughly analyze the system in both normal and abnormal operating conditions”. This may imply the use of different test environments: from the real FCS software plugged into the nonlinear aircraft model to the “Iron bird” tests. We have to assure the equivalence between each test/development environment such that, in a final extent, we can be confident that the FCS eventually flying is the same designed on ground.

The development of an aircraft model is the result of a team work. We have propulsion data, aerodynamic data, mass distribution data, eventually we have to be aware about the sensors, the actuators and the dynamic modes of the structure, and any further data from other disciplines involved in the process. During the development these data will be iteratively updated. We have to be able to isolate these categories of data in our aircraft model such that we can quickly update each part separately and possibly add new parts.

Now hopefully we have a more clear picture of the main concerns when implementing our model:

  • Performance. A software that runs quickly is always very welcomed. Throughout our design cycle we will need to run and re-run the model many times both in off-line or real time simulations, possibly in many different environments. But we have to be careful in how much performance we really need. We may waste too much time and efforts trying to improve code performance beyond our needs, risking to end up spoiling some other important code properties, such as readability. Although it is very difficult to figure out how much performance we will need in early stages of development, we can modularize the model so that we can improve the performance bottlenecks in later stages if it is necessary. Also, we can use different models in different environments (not all of them requires the same level of performance and mutability), but in this case we must have strong procedures to assure the equivalence between the models or, for example, trusted qualified tools to translate from one model to the others;
  • Modularization. In software engineering history, we have an extensive list of reasons why you should modularize your code. In this specific case we can point out few but very strong justifications for doing so. We will have many people working in the same model at the same time, merging their work can be easier if they are changing separated modules. We will have parts of our model coming from other teams (possibly using different software tools) and we will also have to provide parts of our model to other teams; again, if we have well defined modules, this will be more efficiently done. And finally, as we stated in the previous item, if, for example, we find necessary to improve performance, this will be easier to change if we tackle specific modules of our model. Notice that most of the advantages of modularization comes from a very well defined interface between the modules, this means an interface that is very unlikely to change. For example, no matter how the aerodynamicists change their data and calculations internally, we will have our integrated model still working as long as their module keeps receiving alpha, beta, Mach, etc, as inputs, and providing the aerodynamic forces and coefficients as outputs;
  • Readability. Once again, an aircraft model is a work of many hands. When caring about the readability, we reduce the amount of time required for the understanding of a given piece of code, even for the author of that code when looking at it again in the future. This also reduces the possibility of coding errors, making changes faster and safer. We talked so far about coding, but it is important to say that the widespread approach in industry for dynamic systems modeling is the model-based design which relies on its visual method to improve readability.

Implementation: McFlight architecture


As we explained previously, our McFlight is a possible implementation of the model provided by Stevens and Lewis. For further details about their model, please refer to the section 3.5 (Aircraft models for simulation) of the second edition (2003). Details about the equations will be found in the chapter 2 of this book. The implementation of the 6 DoF nonlinear F16 model is given by the authors using structured programming in Fortran, according to the following set of functions:
  • Subroutine F: is the actual dynamic model containing the equations of motion, equivalent to the mathematical function f at Figure 1. This subroutine makes use of all the other functions below;
  • Subroutine ADC: meaning airdata computer and responsible for the atmospheric calculations (mach, dynamic pressure, etc);
  • Functions TGEAR, PDOT, RTAU and THRUST: responsible for the engine calculations;
  • Functions for aerodynamic data: a set of functions representing the aerodynamic coefficients and forces.
  • A cost function for trimming.
It is also provided some numerical algorithms for trimming, differential equation solving and linearizing.

Our (re)implementation of this model will try to pursuit the requirements described in the previous section. The high-level description is illustrated by the UML (Unified Modeling Language) diagram of components shown in Figure 3. For those not familiar with UML, this diagram aims to focus on the interfaces between the different parts of the software, each of these parts with a very well-defined concern (a component). The components are represented by a square with two small other squares on the left. The dotted-line arrow indicates a relation of dependency between the components, meaning that the origin depends on the destination. We also enclosed some components with similar concerns in what UML calls package (the square with an upper small square with a label). Notice that we are able to replace a component for another one with a different internal implementation but providing the same services to their dependent components, and keeping the whole system still working. In other words, as long as we keep the contract assumed between two components (the interface), they are transparently interchangeable by other ones implementing and using the same interfaces.

Figure 3. UML component diagram of McFlight.
We used Scilab scripts for the implementation and despite of not coding a canonical description of component (how it would be in Java, for example) our modules try to follow the same concept. In the following items we link the diagram at Figure 3 to the code at GitHub.
  • Atmosphere (atmosphere/atmosphere.sci): model of the International Standard Atmosphere, providing temperature, pressure and density data based on altitude;
  • Aerodata (eqm/aerodata_f16.sci): functions providing aerodynamic forces and coefficients data based on aircraft angles and control surfaces deflections;
  • Engine (eqm/engine_f16.sci): functions providing engine thrust and dynamics based on throttle setting;
  • Params (eqm/params_f16.sci): function returning geometric and mass properties of the aircraft;
  • EQM (eqm/eqm.sci): actual implementation of the equations of motion of the aircraft, i.e., the function f represented in Figure 1. It requires the implementation of all components enclosed in the aircraft and nature packages shown in Figure 3.
  • Trimmer (trim/trim_f16.sci): algorithms and functions for trimming the dynamic system represented by EQM;
  • Simulator (sim/sim_f16.sci): algorithms and functions to solve the dynamic system represented by EQM, i.e., to run the flight simulation;
  • Linearizer (sim/lin_f16.sci): algorithms and functions to find a linear model in a given trim condition.
I am not an advanced user of Scilab (yet) but I used two approaches to decouple the dependency between the modules (note: by “decoupling” here, we mean that the dependency relies on the well-defined interfaces as much as possible): (1) calling different .sci files which implement the functions with the same signature expected by the script (for example, in order to change the engine, wherever a file is executing engine_f16.sci on top, I could replace by, let’s say, engine_delorean.sci); or (2) passing a struct as a function parameter, assuring that it follows the expected data structure (for example, the parameter params in eqm.sci). If we succeeded in decoupling the modules implementations, we would be able to do things like, for example:
  • Replace the module Aerodata for a newer version of aerodynamic data;
  • Change the internal algorithms used by Trimmer, Simulator or Linearizer;
  • Few changes enhancing the model to include sensors, actuators and a feedback controller;
  • Replace the whole package Nature for other planet atmospheric model (and also gravity model which is currently tangled inside eqm and then not enough decoupled) enabling us to simulate our aircraft somewhere else in the universe;
As we said before, an alternative approach to implement dynamic models (and actually the de facto standard in aerospace industry) is the model-based design. We just want to make clear that it is possible to use this approach still keeping the decoupling philosophy behind the diagram at Figure 3. Indeed we are starting the equivalent implementation using Scilab Xcos.

To finish this section I would like to share a strategy in the methodology I followed when writing the scripts. For each module I developed, I tried to build a piece of automatic test. For example, for the atmospheric model, I wrote a CSV file with some data directly extracted from the NASA document of the standard atmosphere, and made a script to automatically compare each line of this CSV with the values returned by the implemented function (check the folder called tests). This reminds me what I heard from a senior engineer once: prior to any assigned task, figure out how you are going to validate it.

How far are we from the real world of the industry?


Imagine that you have decided to spend your fortune of billions of dollars developing an aircraft by your own or at least the FCS of an existing one. Would it be possible of doing so with the very simple application described above? Well, certainly our model would have to be enhanced. Let us infer what else we need when it comes to the real world of the industry.
  • The data available would be massive. For example, the aerodynamic data would include the contribution of each surface in each different configuration of the aircraft, possibly in ice condition, throughout the whole flight envelope. One possible way to implement the nonlinear effects is using lookup tables and this certainly would give us thousand of tables to be interpolated. This means that we would have at least to include many other inputs to our aerodata module and be able to handle quickly the lookups in the tables;
  • Care about the architecture trade-offs wisely. It is very beautiful to have a decoupled and componentized architecture but do not overengineer it. For example why would we isolate the codes related to atmosphere and gravity to the extreme if our aircraft surely will never fly in outer space? This can even compromise the software performance.
  • Care about the software performance and ways to improve it when it is necessary. Being very specific, we shall always have means to compile our model or at least parts of it to make it faster, for example. As I said before, remember that we have to linearize around several points of the flight envelope and simulate before that, to check in what regions we should increase the number of points (transonic region, for instance) to improve our design.
  • Eventually we will have to mix discrete and continuous time simulations. This means we would have to face all sort of problems with sampling, for example. The model-based design approach makes it easier.
  • Have a robust version and configuration control of each module, or artifact. Eventually we will have to reproduce some simulation environments with different versions of engine, aerodata, mass properties, etc, for example. Having a rigorous tracking framework for our artifacts changes, helps us avoiding and fixing problems. Additionally this would make our lives easier when we need to talk to the aeronautics certification authorities.
Bad news (or good news) are that you won’t be able to make it by yourself. The pieces of information in each of the blocks in Figure 3 would be the result of many hours of work of many engineers. In the real world, the cherry on top of our challenge here would be the management effort to keep all the teams working synergically to achieve what was planned, constrained by the predicted time and budget. Piece of cake!

References


Magni, J.F., Bennani, S., Terlouw, J. (Eds.): Robust Flight Control: A Design
Challenge. Lecture Notes in Control and Information Services 224, Springer Ver-
lag, 1997.

McRuer, D., Ashkenas, I., Graham, D.: Aircraft Dynamics and Automatic Con-
trol. Princeton University Press, Princeton, New Jersey, USA, 1973.

Rauw, M. FDC 1.4 - A Simulink Toolbox for Flight Dynamics and Control Analysis.

Stevens, B.L., Lewis, F.L.: Aircraft Control and Simulation. John Wiley & Sons
Inc., 2003.

No comments:

Post a Comment